The magic of micro-services (part 2.)

The magic of micro-services (part 2.)

Yesterday we started a first look at microservices as a powerful basic technology behind applications in on-prem or cloud environments. We looked at the idea to replace older legacy systems with new solutions based on a modern microservices technology stack.

Whenever it comes to a discussion about these scenarios like cloud, micro-services, etc. there is always the term “container” included. But what are containers doing, what is behind this and what magic is needed to build and deploy containers?

In the context of software deployment, a container is a lightweight and portable unit of software that encapsulates an application and all its dependencies. Containers provide a consistent and isolated runtime environment that can be easily moved between different computing environments, such as development, testing, and production.

Containers are typically made using containerization software, such as Docker or Kubernetes. These tools use a combination of features in the host operating system, such as namespaces and cgroups, to create an isolated environment for the application to run in. The containerization software also creates a container image, which is a lightweight, standalone package that contains the application, all its dependencies, and the configuration required to run the application.

To create a container image, developers typically start with a base image, which is a pre-built image of an operating system or runtime environment, such as Ubuntu or Python. They then add their application code and any required dependencies to the image, using a series of commands defined in a Dockerfile or similar configuration file. Once the image is complete, it can be stored in a container registry, such as Docker Hub or Google Container Registry, and deployed to any environment that supports containerization.

If the containers are defined and tested, they need to be deployed and maintained, which of course should be automated to keep costs low. Here another magic tool comes in handy.

Helm is a package manager for Kubernetes that helps to simplify the deployment and management of containerized applications. Helm uses "charts" to define the applications to be deployed, their dependencies, and their configurations. A Helm chart is a collection of YAML files that describe Kubernetes resources and how they are configured.

A typical Helm chart for deploying a containerized application on Kubernetes would include several Kubernetes manifests, such as:

  1. Deployment: A Kubernetes resource that manages a set of replica pods for a containerized application. It specifies the container image to use, the number of replicas, and other deployment settings.
  2. Service: A Kubernetes resource that exposes the deployed application to other services within the Kubernetes cluster. It defines the port on which the application is exposed and how the service can be accessed.
  3. ConfigMap/Secret: A Kubernetes resource that holds configuration data or secrets that are needed by the deployed application. ConfigMaps are used for non-sensitive configuration data, while Secrets are used for sensitive data like passwords, certificates, and API keys.
  4. Ingress: A Kubernetes resource that defines rules for routing external traffic to the deployed application.

Each of these manifests is defined in YAML format, and they are organized into folders within the Helm chart. The chart also includes a values.yaml file that defines variables for the chart, such as the image tag to use, the number of replicas, and other configurable settings. When the Helm chart is installed, these variables are replaced with the values defined in the installation command.

Overall, Helm charts provide a convenient way to package and deploy containerized applications on Kubernetes, while also providing flexibility and customization through configurable variables.

So whenever you are thinking about cloud and related areas, you now have at least a little idea of the magic behind it.


#request_for_comment #docker #kubernetes #helm #deployment

To view or add a comment, sign in

More articles by Olaf Holst

Others also viewed

Explore content categories