Docker: let’s manage containers via orchestration! 🐳

Modern cloud-native apps are a mixture of several services that work together to create a functional application. This design is known as microservices. Numerous small microservice deployments and management might be challenging. The use of docker-compose as a container orchestration solution in this situation is crucial.

Multi-container applications are managed and deployed using Docker compose on single-engine Docker nodes. It enables you to deploy an entire app with all services described in a single configuration file, which gets executed with a single command.

With some commands, you can control the app’s lifespan after deployment. Additionally, we can keep and address the docker-compose configuration file in a version control system.

Source of Compose

In the old beginning days, Fig was a potent tool developed by an industry named Orchard and was the finest way to handle multi-container apps. A Python tool on top of Docker permits the definition of complete multi-container apps in a single YAML file. Using the Fig command-line approach, we can deploy the app and control its lifespan.

In the background, Fig would read the YAML file and utilize Docker to manage and deploy the application through the Docker API.

Later, Docker Inc. obtained Orchard and changed Fig’s name to Docker Compose. The command line tool, which is still an external tool grafted on top of the Docker engine but now goes by the title docker-compose, was formerly known as Fig.

In recent days, Compose is yet another external Python binary installed on a Docker host. Multi-container applications may be defined in YAML files, passed to the docker-compose command line, and then deployed via the Docker API.

Compose files

To specify multi-service applications, Compose employs YAML files. JSON is also an option because it is a subset of YAML.

The file is called docker-compose.yaml by default. However, you may also give a file a custom name, like “application-services.yaml”.

In the example below, a Docker compose file defines a mission application with three microservices (Frontend, Backend, and MySQL).

version: “3.8”    #This defines the version of compose file
services:
  mysql:
    image: “mysql”    #Pull the mysql image from the container repository
    networks:
      - mission-network    #Run mysql container inside mission-network
    volumes:
      - mysql:/var/lib/mysql    #Attaching mysql container to mysql volume
  
  backend:
    build: ./backend    #Build the backend Dockerfile from the backend path 
    ports:
      - “8082:80”    #Expose the running backend service to port 8082
    networks:
      - mission-network    #Run backend container inside mission-network
    volumes:
      - logs:/app/logs    #Application logs will persist in the logs volume
    depends_on:
      - mysql    #This backend service will depend on the mysql service to start
  
  frontend:
    build: ./frontend    #Build the frontend Dockerfile from the frontend path
    ports:
      - “3000:3004”   #Expose the running frontend service to port 3000
    stdin_open: true
    tty: true
    depends_on:
      - backend    #This frontend service will depend on the backend service to start

networks:
  mission-network:    #Create the mission-network

volumes:
  mysql:    #Create the mysql volume
  logs:    #Create the logs volume

The above structure of the docker-compose file provides an overview of how services are built, networks are set up, volumes are formed, and getting the containers up and down.

Every docker-compose file must contain a version key in the first line. It defines the version of the compose file format.

Let’s execute the docker-compose file to create images and instantiate containers. If the compose file has a custom name, specify it using the -f parameter. The below command statement will deploy an application utilizing a compose file.

$ docker-compose up -d

– OR –

$ docker-compose -f application-services.yaml up -d

Here, the same docker-compose is also used to stop and delete the running application. The below command will stop the running application.

$ docker-compose down

After using the docker-compose up command to deploy services, we must consider how to manage the lifespan of containers. You may simplify container lifecycle management by using container orchestration tools. Let’s look at the features that these orchestration tools offer below.

• Recovering from failures, making sure your apps are strong, resilient, and self-healing.
• Container provision and scheduling using predetermined configurations to allocate the necessary resources.
• Adding or deleting containers to scale services.
• Keeping an eye on the host’s and container’s health.
• Exposing services to the public.
• Load balancing traffic across several containers smoothly.

All of above mention points are managed by two popular orchestration tools Docker Swarm & Kubernetes.

Docker Swarm

Managing clusters of Docker nodes as well as deploying and managing cloud-native applications made possible by Docker Swarm. A docker swarm secures a cluster, and any machine connected to a cluster is referred to as a node. It has an orchestration component and a secured clustering component.

Here your apps can be defined in declarative manifest files and deployed to the swarm using native Docker commands. Additionally, scalability, rollbacks, and rolling updates are all possible.

Small to medium-sized businesses and the deployment of applications can benefit from Docker Swarm, which is easier to set up.

An in-depth discussion of Docker Swarm will be covered in another blog post.

Kubernetes

For addressing containerized applications in a clustered environment, Google created Kubernetes, a potent open-source solution. It aims to provide strategies for addressing distributed services and components across diverse infrastructures. It is a platform designed to thoroughly manage the lifespan of containerized applications and services with techniques that offer scalability, predictability, and high availability.

Kubernetes will be thoroughly discussed in a different blog post.

Conclusion

This blog article describes developing a docker-compose configuration file with a list of all the services that must be deployed to manage containers via orchestration. After reading this, we practically comprehend the use of Docker Compose and theoretically understand the functionality offered by the orchestration tools Docker Swarm and Kubernetes. We will go into much more depth regarding orchestration tools in the future blog.

Want to get in touch?

Please reach out to me on LinkedIn.