Managing software in different environments is a challenge. Your application typically has various dependencies, which may include libraries, interpreters, packages, configurations, etc. Each of these elements also has a tendency to perform differently in different environments. In order to make all dependencies work, the environment should not change, and this is where containers come into the picture.
Nowadays, running an application in a low-cost abstraction container saves the days of managing software dependencies. There are multiple solutions on the market for packing your applications to containers, Docker being one of the most popular. Due to the switch to containerized application, now you have loads of different containers running on servers. This means containers must somehow be tracked, scaled, managed, and configured consistently and programmatically — meet Kubernetes, the open-source container orchestration system founded by Google in 2014.
Since then, it has become the standard for managing containers. Kubernetes has its specifics of handling resources, such as clusters, nodes, pods, services, objects, etc. This blog post won’t dive into the details of Kubernetes here, so if you want to learn more, feel free to explore their documentation.
Helm to the rescue
Configuring Kubernetes involves a series of YAML files that define all Kubernetes resources. The YAML files usually involve a bunch of boilerplate configurations that are useful to different users. Suppose multiple users want to deploy Memgraph in the Kubernetes cluster. In that case, it is likely they will do it very similarly, and YAML files will be very analogous, except for a few configuration changes. On top of that, you do not need to investigate how to do it, but you should spend time configuring a service or a product to your needs. Hence, you probably want preconfigured YAML files in a packed manner, and this is where Helm comes to the rescue.
Helm is a package manager for Kubernetes that allows developers to package, configure, and deploy applications and services onto Kubernetes clusters with minimal effort. Helm will help you install, upgrade, configure, and fetch all resources for deploying products and services in Kubernetes. Essentially, Helm provides charts defining how different containers should be deployed. Helm and Kubernetes are separate rabbit holes to dive into. For now, let’s see what Memgraph has to offer.
Meet Memgraph Helm chart repository 🚢
Helm chart for deploying Memgraph to Kubernetes is one of the most requested things by our community. You asked — we listened! Introducing our brand new Helm chart repository. This should ease the way of deploying Memgraph to a set of simple Helm commands. Currently, it holds the standalone MemgraphDB chart that you can use to deploy MemgraphDB inside Kubernetes.
The prerequisite is that you have a Helm installed and a place to deploy your Kubernetes cluster. That could be any cloud environment such as AWS, GCP, or MS Azure, just to name a few. For the sake of local testing, you can also use Minikube, which is great for prototyping and learning Kubernetes.
To deploy Memgraph, first you need to add the Memgraph Helm chart repository to your local Helm setup by running the following command:
helm repo add memgraph https://memgraph.github.io/helm-charts
After you have a local Helm chart repository from Memgraph, you can install Memgraph to Kubernetes via the following command:
helm install my-release memgraph/memgraph
You can replace my-release with a name of your choice for the release. This will install Memgraph in the Kubernetes cluster with default values specified inside the values.yaml. That includes MemgraphDB with appropriate volumes for storage and logs. At this point, you should be able to connect to your Memgraph instance via Memgraph Lab and mgconsole if the appropriate IP address and port are specified (this will depend on your deployment environment).
The default configuration can be overridden during the install process:
helm install <resource-name> memgraph/memgraph --set <flag1>=<value1>,<flag2>=<value2>,...
For more details on what can be configured further, take a look at the Memgraph Helm chart documentation.
Future work
The current release of Memgraph Helm repo is in the early stages of development. There is a lot of work to be done to make Memgraph more approachable to the Kubernetes environment, but it is a continuous development process.
Future work will involve making Memgraph MAGE and Memgraph platform charts for easier deployment to Kubernetes, making the process more flexible. To keep up with our next release follow the repository milestones.
On top of that, it is always nice to have a helping hand if you notice that something is not working for you or you wish to contribute a chart you have created for Memgraph. So feel free to open a pull request or an issue on our new repository and definitely throw us a star there! ⭐️
Top comments (0)