Champion

Arek Borucki

Principal SRE Database Engineer

## Introduction to Vector Search in MongoDB Atlas

Vector search engines — also termed as vector databases, semantic search, or cosine search — locate the closest entries to a specified vectorized query. While the conventional search methods hinge on keyword references, lexical match, and the rate of word appearances, vector search engines measure similarity by the distance in the embedding dimension. Finding related data becomes searching for the nearest neighbors of your query. 

Vector embeddings act as the numeric representation of data and its accompanying context, preserved in high-dimensional (dense) vectors. There are various models, both proprietary (like those from OpenAI and Hugging Face) and open-source ones (like FastText), designed to produce these embeddings. These models can be trained on millions of samples to deliver results that are both more pertinent and precise. In certain situations, the numeric data you've gathered or designed to showcase essential characteristics of your documents might serve as embeddings. The crucial part is to have an efficient search mechanism, like MongoDB Atlas.

![Diagram of an efficient search mechanism][1]

MongoDB Atlas is a completely managed cloud database offered on AWS, Azure, and GCP. It has recently incorporated native vector search capabilities for your MongoDB document data. Atlas Vector Search utilizes the Hierarchical Navigable Small Worlds algorithm to execute semantic searches. You can leverage Atlas Vector Search's support for aNN queries to find results analogous to a specific product, conduct image searches, and more.

## $vectorSearch operator

Atlas Vector Search queries take the form of an aggregation pipeline stage and use the new  `$vectorSearch`  operator. The `$vectorSearch`  stage performs an aNN search on a vector in the specified field. The field you intend to search must be indexed with the Atlas Vector Search `vector` type. The `$vectorSearch` must be the first stage of any pipeline where it appears. 

## Introduction to LangChain

LangChain is a framework tailored for simplifying the creation of applications employing large language models (LLMs). It is an open-source framework that aids in developing applications powered by language models, particularly emphasizing large language models. The framework extends beyond standard API calls by being data-aware and agentic, which facilitates connections with various data sources to provide richer and more personalized experiences. 

This feature enhances the application's ability to interact with different datasets and improve its functionality based on the obtained data. For example, a developer could use LangChain to create an application where a user's query is processed by a large language model, which then generates a vector representation of the query. This vector representation could be used to search through vector data stored in MongoDB Atlas using its vector search feature. The results from MongoDB Atlas could then be returned to the user or further processed by the language model to provide more detailed or personalized responses. 

Now, let's consolidate all of these elements in an architectural view.

![Vector embeddings architecture][2]

With the theoretical groundwork laid out, it's time to transition from conceptual understanding to practical application. Let's delve into the implementation process to see how these concepts come to life.

## Setting up the environment 

### Create a search index

The first step is creating the vector search index. In the Atlas UI (you can also use Atlas Vector Search with local Atlas deployments that you [create with the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/stable/atlas-cli-deploy-local/)), choose _Search_ and _Create Search Index_. Please also visit the [official MongoDB documentation](https://www.mongodb.com/docs/atlas/atlas-search/field-types/knn-vector/) to learn more.

![MongoDB Atlas dashboard interface showing the search tab][4]

Next, utilize the JSON Editor to configure fields of type ``vector``. I named the field containing the embedding vector ``embedding``.


```
{
  "fields": [
    {
      "type": "vector",
      "path": "embedding",  
      "numDimensions": 1536, 
      "similarity": "cosine"  
    }
  ]
}
```


Specify the namespace (database and collection) on which the vector search index should be created. I chose the namespace  ``langchain.vectorSearch``.

The `similarity` field in the vector definition specifies the function to use for searching the top K-nearest neighbors. The values can be:


* ``euclidean``: Measures vector end-point distance for similarity in varying dimensions.
* ``cosine``: Measures angle-based similarity, independent of magnitude; not suitable for zero-magnitude vectors. For cosine similarity, normalizing vectors and using dotProduct is recommended.
* ``dotProduct``: Similar to cosine but considers vector magnitude, allowing efficient similarity measurement based on both angle and magnitude. Normalize the vector to unit length at index- and query-time for usage.

You can perform semantic searches on your Atlas cluster running MongoDB version 6.0.11 or later. It allows the storage of vector embeddings for any type of data, alongside other data in your collection on the Atlas cluster. Atlas Vector Search accommodates embeddings up to 4096 dimensions.

Now that we have configured Atlas Vector Search, let's move on to configuring LangChain.

### LangChain and OpenAI

In this article, we will utilize OpenAI to generate vector embeddings. Firstly, you will need the OpenAI API Key. Create an account, and then locate your [Secret API key](https://help.openai.com/en/articles/4936850-where-do-i-find-my-secret-api-key) in your user settings.

To install LangChain, you'll first need to update pip for Python or npm for JavaScript, then use the respective install command. Here are the steps:

For Python version, use:


```
pip3 install pip --upgrade
pip3 install langchain
```


We will also need other Python modules, such as ``pymongo`` for communication with MongoDB Atlas, ``openai`` for communication with the OpenAI API, and ``pypdf` `and ``tiktoken``  for other functionalities.


```
pip3 install pymongo openai pypdf tiktoken
```



### Start using Atlas Vector Search 

In our exercise, we utilize a publicly accessible PDF document titled "[MongoDB Atlas Best Practices](https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4HkJP)" as a data source for constructing a text-searchable vector space. The implemented Python script employs several modules to process, vectorize, and index the document's content into a MongoDB Atlas collection.

In order to implement it, let's begin by setting up and exporting the environmental variables. We need the Atlas connection string and the OpenAI API key.


```
export OPENAI_API_KEY="xxxxxxxxxxx"
export ATLAS_CONNECTION_STRING="mongodb+srv://user:passwd@vectorsearch.abc.mongodb.net/?retryWrites=true"
```


Next, we can execute the code provided below. This script retrieves a PDF from a specified URL, segments the text, and indexes it in MongoDB Atlas for text search, leveraging LangChain's embedding and vector search features. The full code is accessible on [GitHub](https://github.com/arekborucki/VectorSearch/blob/main/create-vector.py).


```
import os
from pymongo import MongoClient
from langchain.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain_mongodb import MongoDBAtlasVectorSearch

# Define the URL of the PDF MongoDB Atlas Best Practices document
pdf_url = "https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4HkJP"

# Retrieve environment variables for sensitive information
OPENAI_API_KEY = os.getenv('OPENAI_API_KEY')
if not OPENAI_API_KEY:
    raise ValueError("The OPENAI_API_KEY environment variable is not set.")

ATLAS_CONNECTION_STRING = os.getenv('ATLAS_CONNECTION_STRING')
if not ATLAS_CONNECTION_STRING:
    raise ValueError("The ATLAS_CONNECTION_STRING environment variable is not set.")

# Connect to MongoDB Atlas cluster using the connection string
cluster = MongoClient(ATLAS_CONNECTION_STRING)

# Define the MongoDB database and collection names
DB_NAME = "langchain"
COLLECTION_NAME = "vectorSearch"

# Connect to the specific collection in the database
MONGODB_COLLECTION = cluster[DB_NAME][COLLECTION_NAME]

# Initialize the PDF loader with the defined URL
loader = PyPDFLoader(pdf_url)
data = loader.load()

# Initialize the text splitter
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=150)

# Split the document into manageable segments
docs = text_splitter.split_documents(data)

# Initialize MongoDB Atlas vector search with the document segments
vector_search = MongoDBAtlasVectorSearch.from_documents(
    documents=docs,
    embedding=OpenAIEmbeddings(),
    collection=MONGODB_COLLECTION,
    index_name="default"  # Use a predefined index name
)
# At this point, 'docs' are split and indexed in MongoDB Atlas, enabling text search capabilities.
```


Upon completion of the script, the PDF has been segmented and its vector representations are now stored within the ``langchain.vectorSearch`` namespace in MongoDB Atlas.


![embedding results][5]


### Execute similarities searching query in Atlas Vector Search

"`MongoDB Atlas auditing`"  serves as our search statement for initiating similarity searches. By utilizing the  `<code><em>OpenAIEmbeddings</em></code>` class, we'll generate vector embeddings for this phrase. Following that, a similarity search will be executed to find and extract the three most semantically related documents from our MongoDB Atlas collection that align with our search intent.

In the first step, we need to create a  ``MongoDBAtlasVectorSearch`` object:


```
def create_vector_search():
    """
    Creates a MongoDBAtlasVectorSearch object using the connection string, database, and collection names, along with the OpenAI embeddings and index configuration.

    :return: MongoDBAtlasVectorSearch object
    """
    vector_search = MongoDBAtlasVectorSearch.from_connection_string(
        ATLAS_CONNECTION_STRING,
        f"{DB_NAME}.{COLLECTION_NAME}",
        OpenAIEmbeddings(),
        index_name="default"
    )
    return vector_search
```


Subsequently, we can perform a similarity search.


```
def perform_similarity_search(query, top_k=3):
    """
    This function performs a similarity search within a MongoDB Atlas collection. It leverages the capabilities of the MongoDB Atlas Search, which under the hood, may use the `$vectorSearch` operator, to find and return the top `k` documents that match the provided query semantically.

    :param query: The search query string.
    :param top_k: Number of top matches to return.
    :return: A list of the top `k` matching documents with their similarity scores.
    """

   # Get the MongoDBAtlasVectorSearch object
    vector_search = create_vector_search()
    
    # Execute the similarity search with the given query
    results = vector_search.similarity_search_with_score(
        query=query,
        k=top_k,
    )
    
    return results

# Example of calling the function directly
search_results = perform_similarity_search("MongoDB Atlas auditing")
```


The function returns the most semantically relevant documents from a MongoDB Atlas collection that correspond to a specified search query. When executed, it will provide a list of documents that are most similar to the query "`MongoDB Atlas auditing`".  Each entry in this list includes the document's content that matches the search along with a similarity score, reflecting how closely each document aligns with the intent of the query. The function returns the top k matches, which by default is set to 5 but can be specified for any number of top results desired. Please find the [code on GitHub](https://github.com/arekborucki/VectorSearch/blob/main/similarity-search.py). 

## Summary

MongoDB Atlas Vector Search enhances AI applications by facilitating the embedding of vector data into MongoDB documents. It simplifies the creation of search indices and the execution of KNN searches through the ``$vectorSearch``  MQL stage, utilizing the Hierarchical Navigable Small Worlds algorithm for efficient nearest neighbor searches. The collaboration with LangChain leverages this functionality, contributing to more streamlined and powerful semantic search capabilities​. Harness the potential of MongoDB Atlas Vector Search and LangChain to meet your semantic search needs today!

In the next blog post, we will delve into LangChain Templates, a new feature set to enhance the capabilities of MongoDB Atlas Vector Search. Alongside this, we will examine the role of retrieval-augmented generation (RAG) in semantic search and AI development. Stay tuned for an in-depth exploration in our upcoming article!

Questions? Comments? We’d love to continue the conversation over in the [Developer Community forum](https://www.mongodb.com/community/forums/).


  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blte7a2e75d0a8966e6/6553d385f1467608ae159f75/1.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltdc7192b71b0415f1/6553d74b88cbdaf6aa8571a7/2.png
  [3]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltfd79fc3b47ce4ad8/6553d77b38b52a4917584197/3.png
  [4]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blta6bbbb7c921bb08c/65a1b3ecd2ebff119d6f491d/atlas-search-create-search-index.png
  [5]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt627e7a7dd7b1a208/6553d7b28c5bd6f5f8c993cf/4.png

Discover the integration of MongoDB Atlas Vector Search with LangChain, in Python. Learn how semantic search and embeddings revolutionize data retrieval. 

Leveraging MongoDB Atlas Vector Search With LangChain

In this tutorial, I will show you the simplest way to implement an AI chatbot-style application using MongoDB Atlas Vector Search with LangChain Templates and the retrieval-augmented generation (RAG) pattern for more precise chat responses.

## Retrieval-augmented generation (RAG) pattern

The retrieval-augmented generation (RAG) model enhances LLMs by supplementing them with additional, relevant data, ensuring grounded and precise responses for business purposes. Through vector search, RAG identifies and retrieves pertinent documents from databases, which it uses as context sent to the LLM along with the query, thereby improving the LLM's response quality. This approach decreases inaccuracies by anchoring responses in factual content and ensures responses remain relevant with the most current data. RAG optimizes token use without expanding an LLM's token limit, focusing on the most relevant documents to inform the response process.

![Vector Store Diagram][1]

To elaborate on the implementation: Consider a question-answering system that uses an LLM like OpenAI, operating with the RAG model. It starts with Atlas Vector Search to pinpoint relevant documents or text snippets within a database, providing the necessary context for the question. This context, along with the question, is then processed through OpenAI's API, enabling a more informed and accurate response.

Atlas Vector Search plays a vital role for developers within the retrieval-augmented generation framework. A key technology in funnelling external data into LLMs is LangChain. This framework facilitates the development of applications that integrate LLMs, covering a range of uses that align with the capabilities of language models themselves. These uses encompass tasks like document analysis and summarization, the operation of chatbots, and the scrutiny of code.

MongoDB has streamlined the process for developers to integrate AI into their applications by teaming up with LangChain for the introduction of [LangChain Templates](https://github.com/langchain-ai/langchain/tree/master/templates/rag-mongo). This collaboration has produced a retrieval-augmented generation template that capitalizes on the strengths of MongoDB Atlas Vector Search along with OpenAI's technologies. The template offers a developer-friendly approach to crafting and deploying chatbot applications tailored to specific data sets. The LangChain templates serve as a deployable reference framework, accessible as a REST API via [LangServe](https://github.com/langchain-ai/langserve).

The alliance has also been instrumental in showcasing the latest Atlas Vector Search advancements, notably the `$vectorSearch` aggregation stage, now embedded within LangChain's Python and JavaScript offerings. The joint venture is committed to ongoing development, with plans to unveil more templates. These future additions are intended to further accelerate developers' abilities to realise and launch their creative projects.

## LangChain Templates

LangChain Templates present a selection of reference architectures that are designed for quick deployment, available to any user. These templates introduce an innovative system for the crafting, exchanging, refreshing, acquiring, and tailoring of diverse chains and agents. They are crafted in a uniform format for smooth integration with LangServe, enabling the swift deployment of production-ready APIs. Additionally, these templates provide a free sandbox for experimental and developmental purposes. 

The `rag-mongo` template is specifically designed to perform retrieval-augmented generation utilizing MongoDB and OpenAI technologies. We will take a closer look at the `rag-mongo`   template in the following section of this tutorial.

## Using LangChain RAG templates

To get started, you only need to install the `langchain-cli`.

```
pip3 install -U "langchain-cli[serve]"
```

Use the LangChain CLI to bootstrap a LangServe project quickly. The application will be named `my-blog-article`, and the name of the template must also be specified. I’ll name it `rag-mongo`.

```
langchain app new my-blog-article --package rag-mongo
```

This will create a new directory called my-app with two folders:

* `app`: This is where LangServe code will live.
* `packages`: This is where your chains or agents will live.

Now, it is necessary to modify the  `my-blog-article/app/server.py` file by adding the [following code](https://github.com/arekborucki/VectorSearch/blob/main/server.py):

```
from rag_mongo import chain as rag_mongo_chain
add_routes(app, rag_mongo_chain, path="/rag-mongo")
```

We will need to insert data to MongoDB Atlas. In our exercise, we utilize a publicly accessible PDF document titled "[MongoDB Atlas Best Practices](https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4HkJP)" as a data source for constructing a text-searchable vector space. The data will be ingested into the MongoDB  `langchain.vectorSearch`namespace.

In order to do it, navigate to the directory `my-blog-article/packages/rag-mongo`  and in the file `ingest.py`, change the default names of the MongoDB database and collection. Additionally, modify the URL of the document you wish to use for generating embeddings.


```
cd my-blog-article/packages/rag-mongo 
```


My `ingest.py` is located on [GitHub](https://github.com/arekborucki/VectorSearch/blob/main/ingest.py). Note that if you change the database and collection name in  `ingest.py`, you also need to change it in `rag_mongo`/`chain.py`.  My `chain.py` is also located on [GitHub](https://github.com/arekborucki/VectorSearch/blob/main/chain.py). Next, export your OpenAI API Key and MongoDB Atlas URI.


```
export OPENAI_API_KEY="xxxxxxxxxxx"
export MONGO_URI
="mongodb+srv://user:passwd@vectorsearch.abc.mongodb.net/?retryWrites=true"
```


Creating and inserting embeddings into MongoDB Atlas using LangChain templates is very easy. You just need to run the `ingest.py`script. It will first load a document from a specified URL using the PyPDFLoader. Then, it splits the text into manageable chunks using the `RecursiveCharacterTextSplitter`. Finally, the script uses the OpenAI Embeddings API to generate embeddings for each chunk and inserts them into the MongoDB Atlas `langchain.vectorSearch` namespace.


```
python3 ingest.py
```


Now, it's time to initialize Atlas Vector Search. We will do this through the Atlas UI. In the Atlas UI, choose `Search` and then `Create Search`.  Afterwards, choose the JSON Editor to declare the index parameters as well as the database and collection where the Atlas Vector Search will be established (`langchain.vectorSearch`). Set index name as `default`. The definition of my index is presented below.


```
{
    "type": "vectorSearch",
    "fields": [
        {
            "path": "embedding",
            "dimensions": 1536,
            "similarity": "cosine",
            "type": "vector"
        }
	]
}
```


 A detailed procedure is [available on GitHub](https://github.com/langchain-ai/langchain/tree/master/templates/rag-mongo#mongodb-setup). 

Let's now take a closer look at the central component of the LangChain  `rag-mongo` template: the `chain.py` [script](https://github.com/langchain-ai/langchain/blob/master/templates/rag-mongo/rag_mongo/chain.py). This script utilizes the `MongoDBAtlasVectorSearch` 

class and is used to create an object — `vectorstore` — that interfaces with MongoDB Atlas's vector search capabilities for semantic similarity searches. The `retriever` is then configured from `vectorstore` to perform these searches, specifying the search type as "similarity."  


```
vectorstore = MongoDBAtlasVectorSearch.from_connection_string(
    MONGO_URI,
    DB_NAME + "." + COLLECTION_NAME,
    OpenAIEmbeddings(disallowed_special=()),
    index_name=ATLAS_VECTOR_SEARCH_INDEX_NAME,
)
retriever = vectorstore.as_retriever()
```


This configuration ensures the most contextually relevant document is retrieved from the database. Upon retrieval, the script merges this document with a user's query and leverages the  `ChatOpenAI` class to process the input through OpenAI's GPT models, crafting a coherent answer. To further enhance this process, the ChatOpenAI class is initialized with the `gpt-3.5-turbo-16k-0613` model, chosen for its optimal performance. The temperature is set to 0, promoting consistent, deterministic outputs for a streamlined and precise user experience.


```
model = ChatOpenAI(model_name="gpt-3.5-turbo-16k-0613",temperature=0) 
```


This class permits tailoring API requests, offering control over retry attempts, token limits, and response temperature. It adeptly manages multiple response generations, response caching, and callback operations. Additionally, it facilitates asynchronous tasks to streamline response generation and incorporates metadata and tagging for comprehensive API run tracking.

## LangServe Playground

After successfully creating and storing embeddings in MongoDB Atlas, you can start utilizing the LangServe Playground by executing the `langchain serve` command, which grants you access to your chatbot.


```
langchain serve

INFO:     Will watch for changes in these directories: 
INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
INFO:     Started reloader process [50552] using StatReload
INFO:     Started server process [50557]
INFO:     Waiting for application startup.

LANGSERVE: Playground for chain "/rag-mongo" is live at:
LANGSERVE:  │
LANGSERVE:  └──> /rag-mongo/playground
LANGSERVE:
LANGSERVE: See all available routes at /docs
```


This will start the FastAPI application, with a server running locally at `http://127.0.0.1:8000`. All templates can be viewed at `http://127.0.0.1:8000/docs`, and the playground can be accessed at `http://127.0.0.1:8000/rag-mongo/playground/`.

The chatbot will answer questions about best practices for using MongoDB Atlas with the help of context provided through vector search. Questions on other topics will not be considered by the chatbot.

Go to the following URL:


```
http://127.0.0.1:8000/rag-mongo/playground/
```


And start using your template! You can ask questions related to MongoDB Atlas in the chat.

![LangServe Playground][2]

By expanding the `Intermediate steps` menu, you can trace the entire process of formulating a response to your question. This process encompasses searching for the most pertinent documents related to your query, and forwarding them to the Open AI API to serve as the context for the query. This methodology aligns with the RAG pattern, wherein relevant documents are retrieved to furnish context for generating a well-informed response to a specific inquiry.

We can also use `curl` to interact with `LangServe` REST API and contact endpoints, such as `/rag-mongo/invoke`:


```
curl -X POST "https://127.0.0.1:8000/rag-mongo/invoke" \
     -H "Content-Type: application/json" \
     -d '{"input": "Does MongoDB support transactions?"}'
```



```
{"output":"Yes, MongoDB supports transactions.","callback_events":[],"metadata":{"run_id":"06c70537-8861-4dd2-abcc-04a85a50bcb6"}}
```


We can also send batch requests to the API using the `/rag-mongo/batch` endpoint, for example:


```
curl -X POST "https://127.0.0.1:8000/rag-mongo/batch" \
     -H "Content-Type: application/json" \
     -d '{
           "inputs": [
             "What options do MongoDB Atlas Indexes include?",
             "Explain Atlas Global Cluster",
             "Does MongoDB Atlas provide backups?"
           ],
           "config": {},
           "kwargs": {}
         }'
```



```
{"output":["MongoDB Atlas Indexes include the following options:\n- Compound indexes\n- Geospatial indexes\n- Text search indexes\n- Unique indexes\n- Array indexes\n- TTL indexes\n- Sparse indexes\n- Partial indexes\n- Hash indexes\n- Collated indexes for different languages","Atlas Global Cluster is a feature provided by MongoDB Atlas, a cloud-based database service. It allows users to set up global clusters on various cloud platforms such as Amazon Web Services, Microsoft Azure, and Google Cloud Platform. \n\nWith Atlas Global Cluster, users can easily distribute their data across different regions by just a few clicks in the MongoDB Atlas UI. The deployment and management of infrastructure and database resources required for data replication and distribution are taken care of by MongoDB Atlas. \n\nFor example, if a user has an accounts collection that they want to distribute among their three regions of business, Atlas Global Cluster ensures that the data is written to and read from different regions, providing high availability and low latency access to the data.","Yes, MongoDB Atlas provides backups."],"callback_events":[],"metadata":{"run_ids":["1516ba0f-1889-4688-96a6-d7da8ff78d5e","4cca474f-3e84-4a1a-8afa-e24821fb1ec4","15cd3fba-8969-4a97-839d-34a4aa167c8b"]}}
```


For comprehensive documentation and further details, please visit `http://127.0.0.1:8000/docs`.

## Summary

In this article, we've explored the synergy of MongoDB Atlas Vector Search with LangChain Templates and the RAG pattern to significantly improve chatbot response quality. By implementing these tools, developers can ensure their AI chatbots deliver highly accurate and contextually relevant answers. Step into the future of chatbot technology by applying the insights and instructions provided here. Elevate your AI and engage users like never before. Don't just build chatbots — craft intelligent conversational experiences. [Start now with MongoDB Atlas](https://www.mongodb.com/cloud/atlas/register) and LangChain!


  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltbe1d8daf4783a8a1/6578c9297cf4a90420f5d76a/Boosting_AI_-_1.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt435374678f2a3d2a/6578cb1af2362505ae2f7926/Boosting_AI_-_2.png

Learn how to enhance your AI chatbot's accuracy with MongoDB Atlas Vector Search and LangChain Templates using the RAG pattern in our guide.

Boosting AI: Build Your Chatbot Over Your Data With MongoDB Atlas Vector Search and LangChain Templates Using the RAG Pattern

Learn how to deploy MongoDB across multiple Kubernetes clusters using the operator and the MongoDBMulti CRD.

Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud

Mastering MongoDB Ops Manager on Kubernetes

Deploying MongoDB Across Multiple Kubernetes Clusters With MongoDBMulti

Deploying MongoDB Across Multiple Kubernetes Clusters

This article is part of a three-parts series on deploying MongoDB across multiple Kubernetes clusters using the operators.

-   Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud

-   [Mastering MongoDB Ops Manager](https://www.mongodb.com/developer/products/connectors/mastering-ops-manager)

-   [Deploying MongoDB Across Multiple Kubernetes Clusters With MongoDBMulti](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters)

Deploying and managing MongoDB on Kubernetes can be a daunting task. It requires creating and configuring various Kubernetes resources, such as persistent volumes, services, and deployments, which can be time-consuming and require a deep understanding of both Kubernetes and MongoDB products. Furthermore, tasks such as scaling, backups, and upgrades must be handled manually, which can be complex and error-prone. This can impact the reliability and availability of your MongoDB deployment and may require frequent manual intervention to keep it running smoothly. Additionally, it can be hard to ensure that your MongoDB deployment is running in the desired state and is able to recover automatically from failures.

Fortunately, MongoDB offers operators, which are software extensions to the Kubernetes API that use custom resources to manage applications and their components. The MongoDB Operator translates human knowledge of creating a MongoDB instance into a scalable, repeatable, and standardized method, and leverages Kubernetes features to operate MongoDB for you. This makes it easier to deploy and manage MongoDB on Kubernetes, providing advanced features and functionality for running MongoDB in cloud-native environments.

There are three main Kubernetes operators available for deploying and managing MongoDB smoothly and efficiently in Kubernetes environments:

-   [The MongoDB Community Kubernetes Operator](https://github.com/mongodb/mongodb-kubernetes-operator) is an open-source operator that is available for free and can be used to deploy and manage MongoDB Replica Set on any Kubernetes cluster. It provides basic functionality for deploying and managing MongoDB but does not include some of the more advanced features available in the Enterprise and Atlas operators.

-   [The MongoDB Enterprise Kubernetes Operator ](https://github.com/mongodb/mongodb-enterprise-kubernetes)is a commercial Kubernetes operator included with the MongoDB Enterprise subscription. It allows you to easily deploy and manage any type of MongoDB deployment (standalone, replica set, sharded cluster) on Kubernetes, providing advanced features and functionality for deploying and managing MongoDB in cloud-native environments.

-   [The MongoDB Atlas Kubernetes Operator](https://github.com/mongodb/mongodb-atlas-kubernetes) is an operator that is available as part of the Atlas service. It allows you to quickly deploy and manage MongoDB on the Atlas cloud platform, providing features such as automatic provisioning and scaling of MongoDB clusters, integration with Atlas features and services, and automatic backups and restores. You can learn more about this operator in our blog post on [application deployment in Kubernetes](https://www.mongodb.com/developer/products/atlas/kubernetes-operator-application-deployment/).

This article will focus on the Enterprise Operator. [The MongoDB Enterprise Kubernetes Operator](https://www.mongodb.com/docs/kubernetes-operator/master/) seamlessly integrates with other MongoDB Enterprise features and services, such as MongoDB Ops Manager (which can also run on Kubernetes) and MongoDB Cloud Manager. This allows you to easily monitor, back up, upgrade, and manage your MongoDB deployments from a single, centralized location, and provides access to a range of tools and services for managing, securing, and optimizing your deployment.

## MongoDB Enterprise Kubernetes Operator

The MongoDB Enterprise [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) automates the process of creating and managing MongoDB instances in a scalable, repeatable, and standardized manner. It uses the Kubernetes API and tools to handle the lifecycle events of a MongoDB cluster, including provisioning storage and computing resources, configuring network connections, setting up users, and making changes to these settings as needed. This helps to ease the burden of manually configuring and managing stateful applications, such as databases, within the Kubernetes environment.

![The Kubernetes Operator manages the typical lifecycle events for a MongoDB cluster: provisioning storage and computing power, configuring network connections, setting up users, and changing these settings as needed](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/kubernetes_operator_bakedsvg_1c1a6d427b.svg)

## Kubernetes Custom Resource Definitions

[Kubernetes CRDs](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) (Custom Resource Definitions) is a feature in Kubernetes that allows users to create and manage custom resources in their Kubernetes clusters. [Custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are extensions of the Kubernetes API that allow users to define their own object types and associated behaviors. With CRDs, you can create custom resources that behave like built-in Kubernetes resources, such as StatefulSets, Deployments, Pods, and Services, and manage them using the same tools and interfaces. This allows you to extend the functionality of Kubernetes and tailor it to their specific needs and requirements.

The MongoDB Enterprise Operator currently provides the following custom resources for deploying MongoDB on Kubernetes:

-   [MongoDBOpsManager Custom Resource](https://github.com/mongodb/mongodb-enterprise-kubernetes/tree/master/samples/ops-manager)

-   [MongoDB Custom Resource](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/mdb-resources-arch/#the-mongodb-custom-resource-definition)

    -   Standalone

    -   ReplicaSet

    -   ShardedCluster

-   [MongoDBUser Custom Resource](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/mdb-resources-arch/#reconciling-the-mongodbuser-custom-resource)

-   [MongoDBMulti](https://www.mongodb.com/docs/kubernetes-operator/master/multi-cluster-arch/#deployment-architecture-and-diagram)

![The following diagram describes how the Kubernetes Operator behaves if you make changes to a sharded cluster's](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Mongo_DB_2d08c18419.png)

[Example of Ops Manager and MongoDB Custom Resources on Kubernetes](https://drive.google.com/file/d/1q7dvZ9PT9YU2EtJNyeYyl00DjKvQajl9/view)

## Installing and configuring Enterprise Kubernetes Operator

For this tutorial, we will need the following tools: 

-   [gcloud](https://cloud.google.com/sdk/docs/install)[ ](https://go.dev/dl/)

-   [gke-cloud-auth-plugin](https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke)

-   [Helm](https://helm.sh/docs/intro/install/)

-   [kubectl](https://kubernetes.io/docs/tasks/tools/)

-   [kubectx](https://github.com/ahmetb/kubectx)

-   [Git](https://git-scm.com/downloads)

## GKE Kubernetes cluster creation 

To start, let's create a Kubernetes cluster in a new [project](https://cloud.google.com/resource-manager/docs/creating-managing-projects). We will be using [GKE Kubernetes](https://cloud.google.com/kubernetes-engine). I use this script to create the cluster. The cluster will have four worker nodes and act as Ops Manager and MongoDB Enterprise Operators Kubernetes Cluster.

```bash
CLUSTER_NAME=master-operator
ZONE=us-south1-a
K8S_VERSION=1.23
MACHINE=n2-standard-2
gcloud container clusters create "${CLUSTER_NAME}" \
  --zone "${ZONE}" \
  --machine-type "${MACHINE}" --cluster-version="${K8S_VERSION}" \
  --disk-type=pd-standard --num-nodes 4
```

Now that the cluster has been created, we need to obtain the credentials.

```bash
gcloud container clusters get-credentials "${CLUSTER_NAME}" \
  --zone "${ZONE}"
```


Display the newly created cluster.

```bash
gcloud container clusters list

NAME                LOCATION       MASTER_VERSION    NUM_NODES  STATUS
master-operator     us-south1-a    1.23.14-gke.1800      4      RUNNING
```

We can also display Kubernetes full cluster name using [`kubectx`](https://github.com/ahmetb/kubectx).

```bash
kubectx
```

You should see your cluster listed here. Make sure your context is set to master cluster.

```bash
kubectx $(kubectx | grep "master-operator" | awk '{print $1}')
```


We are able to start MongoDB Kubernetes Operator installation on our newly created Kubernetes cluster! 

## Enterprise Kubernetes Operator 

We can install the MongoDB Enterprise Operator with a single line Helm command. The first step is to  add the [MongoDB Helm Charts for Kubernetes](https://mongodb.github.io/helm-charts/) repository to Helm.

```bash
helm repo add mongodb https://mongodb.github.io/helm-charts
```


I want to create the operator in a separate, dedicated Kubernetes namespace (the operator uses `default` namespace by default). This will allow me to isolate the operator and any resources it creates from other resources in my cluster. The following command will install the CRDs and the Enterprise Operator in the `mongodb-operator`namespace. The operator will be watching only the `mongodb-operator` namespace. You can read more about [setting up the operator to watch more namespaces](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/set-scope-k8s-operator/#operator-uses-a-subset-of-namespaces) in the official MongoDB documentation.

Start by creating the `mongodb-operator`namespace.

```bash
NAMESPACE=mongodb-operator
kubectl create ns "${NAMESPACE}"
```


Install the MongoDB Kubernetes Operator and set it to watch only the `mongodb-operator` namespace.

```bash
HELM_CHART_VERSION=1.16.3
helm install enterprise-operator mongodb/enterprise-operator \
  --namespace "${NAMESPACE}" \
  --version="${HELM_CHART_VERSION}" \
  --set operator.watchNamespace="${NAMESPACE}"
```


The namespace has been created and the operator is running! You can see this by listing the pods in the newly created namespace.

```bash
kubectl get ns

NAME               STATUS   AGE
default            Active   4m9s
kube-node-lease    Active   4m11s
kube-public        Active   4m12s
kube-system        Active   4m12s
mongodb-operator   Active   75s
```

```bash
kubectl get po -n "${NAMESPACE}"

NAME                                    READY   STATUS   RESTARTS   AGE
mongodb-enterprise-operator-649bbdddf5   1/1    Running   0         7m9s
```


You can see that the helm chart is running with this command.

```bash
helm list --namespace "${NAMESPACE}"

NAME                NAMESPACE     REVISION       VERSION
enterprise-operator mongodb-operator 1 deployed enterprise-operator-1.17.2
```

### Verify the installation

You can verify that the installation was successful and is currently running with the following command.

```bash
helm get manifest enterprise-operator --namespace "${NAMESPACE}"
```

Let's display Custom Resource Definitions installed in the step above in the watched namespace.

```bash
kubectl -n "${NAMESPACE}" get crd | grep -E '^(mongo|ops)'

mongodb.mongodb.com                              2022-12-30T16:17:07Z
mongodbmulti.mongodb.com                         2022-12-30T16:17:08Z
mongodbusers.mongodb.com                         2022-12-30T16:17:09Z
opsmanagers.mongodb.com                          2022-12-30T16:17:09Z
```


All required service accounts has been created in watched namespace.

```bash
kubectl -n "${NAMESPACE}" get sa | grep -E '^(mongo)'

mongodb-enterprise-appdb           1         36s
mongodb-enterprise-database-pods   1         36s
mongodb-enterprise-operator        1         36s
mongodb-enterprise-ops-manager     1         36s
```

Validate if the Kubernetes Operator was installed correctly by running the following command and verify the output.

```bash
kubectl describe deployments mongodb-enterprise-operator -n \
  "${NAMESPACE}"
```


Finally, double-check watched namespaces.

```bash
kubectl describe deploy mongodb-enterprise-operator -n "${NAMESPACE}" | grep WATCH

      WATCH_NAMESPACE:               mongodb-operator
```


The MongoDB Enterprise Operator is now running in your GKE cluster.

## MongoDB Atlas Kubernetes Operator

It's worth mentioning another operator here --- a new service that integrates Atlas resources with your Kubernetes cluster. Atlas can be deployed in multi-cloud environments including Google Cloud. The Atlas Kubernetes Operator allows you to deploy and manage cloud-native applications that require data services in a single control plane with secure enterprise platform integration.

This operator is responsible for managing resources in Atlas using Kubernetes custom resources, ensuring that the configurations of projects, database deployments, and database users in Atlas are consistent with each other. The Atlas Kubernetes Operator uses the `AtlasProject`, `AtlasDeployment`, and `AtlasDatabaseUser` Custom Resources that you create in your Kubernetes cluster to manage resources in Atlas.

These custom resources allow you to define and configure the desired state of your projects, database deployments, and database users in Atlas. To learn more, head over to our blog post on [application deployment in Kubernetes](https://www.mongodb.com/developer/products/atlas/kubernetes-operator-application-deployment/) with the MongoDB Atlas Operator.

## Conclusion

Upon the successful installation of the Kubernetes Operator, we are able to use the capabilities of the MongoDB Enterprise Kubernetes Operator to run MongoDB objects on our Kubernetes cluster. The Operator enables easy deploy of the following applications into Kubernetes clusters:

-   MongoDB --- replica sets, sharded clusters, and standalones --- with authentication, TLS, and many more options.

-   Ops Manager --- enterprise management, monitoring, and backup platform for MongoDB. The Operator can install and manage Ops Manager in Kubernetes for you. Ops Manager can manage MongoDB instances both inside and outside Kubernetes. Installing Ops Manager is covered in the [second article](https://www.mongodb.com/developer/products/connectors/mastering-ops-manager) of the series.

-   MongoMulti --- Multi-Kubernetes-cluster deployments allow you to add MongoDB instances in global clusters that span multiple geographic regions for increased availability and global distribution of data. This is covered in the [final part](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters) of this series.

Want to see the MongoDB Enterprise Kubernetes Operator in action and discover all the benefits it can bring to your Kubernetes deployment? Continue reading the [next blog](https://www.mongodb.com/developer/products/connectors/mastering-ops-manager) of this series and we'll show you how to best utilize the Operator for your needs

Learn how to deploy the MongoDB Enterprise Kubernetes Operator in this tutorial.

This article is part of a three-parts series on deploying MongoDB across multiple Kubernetes clusters using the operators.

-   [Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud](https://www.mongodb.com/developer/products/connectors/deploying-kubernetes-operator)

-   Mastering MongoDB Ops Manager

-   [Deploying MongoDB Across Multiple Kubernetes Clusters With MongoDBMulti](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters)

Managing MongoDB deployments can be a rigorous task, particularly when working with large numbers of databases and servers. Without the right tools and processes in place, it can be time-consuming to ensure that these deployments are running smoothly and efficiently. One significant issue in managing MongoDB clusters at scale is the lack of automation, which can lead to time-consuming and error-prone tasks such as backups, recovery, and upgrades. These tasks are crucial for maintaining the availability and performance of your clusters.

Additionally, monitoring and alerting can be a challenge, as it may be difficult to identify and resolve issues with your deployments. To address these problems, it's essential to use software that offers monitoring and alerting capabilities. Optimizing the performance of your deployments also requires guidance and support from the right sources.

Finally, it's critical for your deployments to be secure and compliant with industry standards. To achieve this, you need features that can help you determine if your deployments meet these standards.

[MongoDB Ops Manager](https://www.mongodb.com/products/ops-manager) is a web-based application designed to assist with the management and monitoring of MongoDB deployments. It offers a range of features that make it easier to deploy, manage, and monitor MongoDB databases, such as:

-   [Automated backups and recovery](https://www.mongodb.com/docs/ops-manager/current/application/#backup): Ops Manager can take automated backups of your MongoDB deployments and provide options for recovery in case of failure.

-   [Monitoring and alerting](https://www.mongodb.com/docs/ops-manager/current/application/#monitoring): Ops Manager provides monitoring and alerting capabilities to help identify and resolve issues with your MongoDB deployments.

-   [Performance optimization](https://www.mongodb.com/docs/ops-manager/current/tutorial/performance-advisor/): Ops Manager offers tools and recommendations to optimize the performance of your MongoDB deployments.

-   [Upgrade management](https://www.mongodb.com/docs/ops-manager/current/tutorial/change-mongodb-version/): Ops Manager can help you manage and plan upgrades to your MongoDB deployments, including rolling upgrades and backups to ensure data availability during the upgrade process.

-   [Security and compliance](https://www.mongodb.com/docs/ops-manager/current/tutorial/nav/security/): Ops Manager provides features to help you secure your MongoDB deployments and meet compliance requirements.

However, managing Ops Manager can be a challenging task that requires a thorough understanding of its inner workings and how it interacts with the internal MongoDB databases. It is necessary to have the knowledge and expertise to perform upgrades, monitor it, audit it, and ensure its security. As Ops Manager is a crucial part of managing the operation of your MongoDB databases, its proper management is essential.

Fortunately, the MongoDB Enterprise Kubernetes Operator enables us to run Ops Manager on Kubernetes clusters, using native Kubernetes capabilities to manage Ops Manager for us, which makes it more convenient and efficient.

## Kubernetes: MongoDBOpsManager custom resource

The [MongoDB Enterprise Kubernetes Operator](https://www.mongodb.com/docs/kubernetes-operator/master/) is software that can be used to deploy Ops Manager and MongoDB resources to a Kubernetes cluster, and it's responsible for managing the lifecycle of each of these deployments. It has been developed based on years of experience and expertise, and it's equipped with the necessary knowledge to properly install, upgrade, monitor, manage, and secure MongoDB objects on Kubernetes.

The Kubernetes Operator uses the [MongoDBOpsManager custom resource](https://github.com/mongodb/mongodb-enterprise-kubernetes/tree/master/samples/ops-manager) to manage Ops Manager objects. It constantly monitors the specification of the custom resource for any changes and, when changes are detected, the operator validates them and makes the necessary updates to the resources in the Kubernetes cluster.

MongoDBOpsManager custom resources specification defines the following Ops Manager components:

-   The [Application Database](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/om-arch/#application-database)

-   The [Ops Manager application](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/om-arch/#application)

-   The [Backup Daemon](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/om-arch/#backup-daemon)

![MongoDBOpsManager custom resources specification defines the following Ops Manager components:
the Application Database,
the Ops Manager application, and
the Backup Daemon.](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/meko_arch_a94d843eaa.svg)

When you use the Kubernetes Operator to create an instance of Ops Manager, the Ops Manager MongoDB Application Database will be deployed as a replica set. It's not possible to configure the Application Database as a standalone database or a sharded cluster.

The Kubernetes Operator automatically sets up Ops Manager to monitor the Application Database that powers the Ops Manager Application. It creates a project named  `<ops-manager-deployment-name>-db` to allow you to monitor the Application Database deployment. While Ops Manager monitors the Application Database deployment, it does not manage it.

When you deploy Ops Manager, you need to configure it. This typically involves using the [configuration wizard](https://www.mongodb.com/docs/ops-manager/current/reference/config/ui-settings/). However, you can bypass the configuration wizard if you set certain essential settings in your object specification before deployment. I will demonstrate that in this post.

The Operator automatically enables backup. It deploys a StatefulSet, which consists of a single pod, to host the Backup Daemon Service and creates a Persistent Volume Claim and Persistent Volume for the Backup Daemon's head database. The operator uses the Ops Manager API to enable the Backup Daemon and configure the head database.

## Getting started

Alright, let's get started using the operator and build something! For this tutorial, we will need the following tools: 

-   [gcloud](https://cloud.google.com/sdk/docs/install)[ ](https://go.dev/dl/)

-   [gke-cloud-auth-plugin](https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke)

-   [Helm](https://helm.sh/docs/intro/install/)

-   [kubectl](https://kubernetes.io/docs/tasks/tools/)

-   [kubectx](https://github.com/ahmetb/kubectx)

-   [git](https://git-scm.com/downloads)

To get started, we should first create a Kubernetes cluster and then install the MongoDB Kubernetes Operator on the cluster. [Part 1](https://www.mongodb.com/developer/products/connectors/deploying-kubernetes-operator) of this series provides instructions on how to do so.

> **Note**
> For the sake of simplicity, we are deploying Ops Manager in the same namespace as our MongoDB Operator. In a production environment, you should deploy Ops Manager in its own namespace.

### Environment pre-checks 

Upon successful creation of a cluster and installation of the operator (described in [Part 1](https://www.mongodb.com/developer/products/connectors/deploying-kubernetes-operator)), it's essential to validate their readiness for use.

```bash
gcloud container clusters list

NAME                LOCATION       MASTER_VERSION    NUM_NODES  STATUS\
master-operator     us-south1-a    1.23.14-gke.1800      4      RUNNING
```

Display our new Kubernetes full cluster name using `[kubectx](https://github.com/ahmetb/kubectx)`.

```bash
kubectx
```

You should see your cluster listed here. Make sure your context is set to master cluster.

```bash
kubectx $(kubectx | grep "master-operator" | awk '{print $1}')
```

In order to continue this tutorial, make sure that the operator is in the `running`state.

```bash
kubectl get po -n "${NAMESPACE}"

NAME                                    READY   STATUS   RESTARTS   AGE\
mongodb-enterprise-operator-649bbdddf5   1/1    Running   0         7m9s
```

## Using the MongoDBOpsManager CRD

Create a secret containing the username and password on the master Kubernetes cluster for accessing the Ops Manager user interface after installation.

```bash
kubectl -n "${NAMESPACE}" create secret generic om-admin-secret \
  --from-literal=Username="opsmanager@example.com" \
  --from-literal=Password="p@ssword123" \
  --from-literal=FirstName="Ops" \
  --from-literal=LastName="Manager"
```
​​
### Deploying Ops Manager 

Then, we can [deploy Ops Manger on the master Kubernetes](https://github.com/mongodb/mongodb-enterprise-kubernetes/tree/master/samples/ops-manager) cluster with the help of `opsmanagers`  Custom Resource, creating `MongoDBOpsManager` object, using the following manifest:

```bash
OM_VERSION=6.0.5
APPDB_VERSION=5.0.5-ent
kubectl apply -f - <<EOF
apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: ops-manager
  namespace: "${NAMESPACE}"
spec:
  version: "${OM_VERSION}"
  # the name of the secret containing admin user credentials.
  adminCredentials: om-admin-secret
  externalConnectivity:
    type: LoadBalancer
  configuration:
    mms.ignoreInitialUiSetup: "true"
    automation.versions.source: mongodb
    mms.adminEmailAddr: support@example.com
    mms.fromEmailAddr: support@example.com
    mms.replyToEmailAddr: support@example.com
    mms.mail.hostname: example.com
    mms.mail.port: "465"
    mms.mail.ssl: "false"
    mms.mail.transport: smtp
  # the Replica Set backing Ops Manager.
  applicationDatabase:
    members: 3
    version: "${APPDB_VERSION}"
EOF
```
 
 After a few minutes, we should see our Ops Manager and Ops Manager MongoDB application database pods running.

```​​bash
kubectl -n "${NAMESPACE}" get pods

NAME                                       READY      STATUS     RESTARTS
ops-manager-0                           1/1      Running      0
ops-manager-db-0                        3/3      Running      0
ops-manager-db-1                        3/3      Running      0
ops-manager-db-2                        3/3      Running      0
```

Storage part creation has been orchestrated by the operator. [Persistent Volumes Claims ](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) are created and can be displayed via

```bash
kubectl -n "${NAMESPACE}" get pvc

NAME       STATUS   VOLUME     CAPACITY  ACCESS MODES   STORAGE CLASS   AGE
data-ops-manager-db-0 Bound pvc-d5a1b385-6d1b  15Gi  RWO  standard  59m
data-ops-manager-db-1 Bound pvc-db0e89dc-d73a  15Gi  RWO  standard  58m
data-ops-manager-db-2 Bound pvc-c7e124a2-917   15Gi  RWO  standard  57m
```

[Kubernetes StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) has also been created by the Operator.

```bash
kubectl -n "${NAMESPACE}" get sts

NAME             READY   AGE
ops-manager      1/1     29m31s
ops-manager-db   3/3     30m29s
```

The operator has created all required network services, including a Load Balancer service type for the Ops manager access, so we now have an external IP address and can log into the Ops Manager from outside the Kubernetes cluster. You can verify IPs by viewing the services.

```bash
kubectl -n "${NAMESPACE}" get svc

NAME                  TYPE    CLUSTER-IP    EXTERNAL-IP  PORT(S)
ops-manager-db-svc  ClusterIP    None        <none>      27017/TCP
ops-manager-svc     ClusterIP    None        <none       8080/TCP,25999/TCP
ops-manager-svc-ext LoadBalancer 10.76.10.231 34.174.54.103 8080:32078/TCP ,25999:31961/TCP    
```

The following diagram describes how the Kubernetes Operator reconciles changes to the  MongoDBOpsManager CustomResourceDefinition.

![The following diagram describes how the Kubernetes Operator reconciles changes to the MongoDBOpsManager CustomResourceDefinition](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_objects_5e8862d468.png)

To generate Ops Manager URL address, execute:

```bash
URL=http://$(kubectl -n "${NAMESPACE}" get svc ops-manager-svc-ext -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}')
echo $URL
```

The URL address will look similar to the example provided, but IP address may vary depending on the Kubernetes cluster.

```bash
http://34.174.54.105:8080
```

The final step is to update the Ops Manager Kubernetes manifest to include an external IP address created by Load Balancer in `spec.configuration.mms.centralUrl`  via `kubectl patch`.

```bash
kubectl -n "${NAMESPACE}" patch om ops-manager --type=merge -p "{\"spec\":{\"configuration\":{\"mms.centralUrl\":\"${URL}\"}}}"
```

We should wait a few minutes. The Ops Manager pod must be restarted, so wait until the `ops-manager-0` pod is in the `running` state again.

Using the username and password stored in the `om-admin-secret` (opsmanager@example.com : p@ssword123), we can log in to the Ops Manager User Interface using the address in the `$URL` variable.

![Enter your username and password and click Login](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_c44549fd1e.png)

The Kubernetes Operator was in the Ops Manager `ops-manager-db` organization and the `ops-manager-db` project.

![Select Ops Manager organization](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_UI_834b2820aa.png)

If we click on the project `ops-manager-db`, we will be redirected to the panel where we can see the database pods of the Ops Manager application. Ops Manager monitors this database.

![Manage your MongoDB cluster from Ops Manager](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_App_DB_5f3ae3ae3e.png)

## Basic troubleshooting

If you run through issues during the installation, here are some clues to help you investigate what went wrong.

If you want to display an Ops Manager cluster, use this command. It will show you a general overview of `om` objects, including internal database and Backup Daemon state.

```bash
kubectl -n "${NAMESPACE}" get om

NAME REPLICAS VERSION STATE(OPSMANAGER) STATE(APPDB) STATE (BACKUP)   AGE
ops-manager     6.0.5     Running        Running     Pending          18m  
```
 

You can use `describe` to get a detailed overview.

```bash
kubectl -n "${NAMESPACE}" describe om ops-manager
```

It's always a good idea to check the Ops Manager logs

```bash
kubectl -n "${NAMESPACE}" logs -f po/ops-manager-0
```

or current `events` from the namespace.

```bash
kubectl -n "${NAMESPACE}" get events
```

## Summary

We have just installed Ops Manager on our Kubernetes cluster. This gives us many benefits. The operator has properly installed and configured the Ops Manager instance with the internal database, took care of the storage portion, and created network services, including a Load Balancer. We can now use Ops Manager and easily create any kind of MongoDB database on the Kubernetes cluster following the best practices, monitor instances of our databases, introduce query optimizations with the help of the Ops Manager performance advisor, and provide backup, restore, or rolling upgrades through automation.

In the [next part](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters), I will demonstrate how to run the latest type of MongoDB Kubernetes Custom Resource, a Multi Cluster Replica Set. This replica set will be deployed across three separate Kubernetes clusters located in different regions, providing the ideal solution for critical applications that require continuous availability, even in the event of a Kubernetes cluster failure.
Want to get started with the MongoDB Ops Manager on your own Kubernetes cluster? [Install  it now](https://github.com/mongodb/helm-charts/tree/main/charts/enterprise-operator) and see for yourself how it can simplify your operations. Make sure to visit the [MongoDB community forum](https://www.mongodb.com/community/forums/) for the latest discussions and resources