Docker Compose: Simplifying development and testing in lower environments

Docker Compose is a tool for defining and running multi-container applications. It is the key to unlocking a streamlined and efficient development and deployment experience. Even though compose works best in both lower and production environments, but is best suited for lower environments for development and testing purposes. It simplifies the process of configuring and managing multiple containers that work together, such as a web server, a database, and other services, by using a single YAML file (docker-compose.yml) to define all configurations. It can be installed on a single machine and doesn't require a complex cluster setup.

Why Docker Compose?

-?????? Simplifies containers management in a comprehensible YAML configuration file.

-?????? Gives consistency across environments.

-?????? Provides extensive command line utilities to manage lifecycle of containers.

-?????? Allows easy scaling of services.

-?????? Each service definition can be versioned and is easily reusable.

Docker Compose File Structure

With Docker Compose you use a YAML configuration file, known as the Compose file, to configure your application’s services, and then you create and start all the services from your configuration with the Compose CLI.

Lets suppose we have a web application hosted behind a nginx load balancer and the data is being cached in Reddis. On every failure application must restart and nginx server should only get started when the web applications are up and running. There would be two services created for the web app, one running on port 82 and another on port 83 and will get load balanced by Nginx. Structure of docker-compose YML would require:

-?????? Definition of services

-?????? Commands and instructions to build images

-?????? Port exposed for Service

-?????? Service Dependencies

services:                             // definition of all the services that needs to be deployed
  redis:                              // service name
    image: 'redislabs/redismod'                      //image to be used for running container
    ports:
      - '6379:6379'              // service would be exposed on port 6379
  web1:                                            // web application service to be hosted on port 82
restart: on-failure                                     // service would auto restart on every failure
    build:                       // herein we are not defining the image, but building the image
	context: ./web                      // context is the directory where Dockerfile is present
      	target: builder                         // target here specifies the build stage in Dockerfile
    hostname: web1                 // hostname of the service which we are going to deploy
    ports:
      - '82:5000'                       // web app would be exposed on port 82
  web2:
    restart: on-failure                       // service would auto restart on every failure
    build:                       // herein we are not defining the image, but building the image
	context: ./web                     // context is the directory where Dockerfile is present
      	target: builder                       // target here specifies the build stage in Dockerfile
    hostname: web2               // hostname of the service which we are going to deploy
    ports:
      - '83:5000'                                                  // web app would be hosted on port 83
  nginx:                                                           // definition of nginx service starts here
    build: ./nginx                    // specification of directory wherein Dockerfile is present
   
 // ./data directory on the host machine is mounted into the container at /usr/share/nginx/html. Any changes to ./data on the host will reflect inside the container.
    volumes: 
    - ./data:/usr/share/nginx/html             
    ports:
    - '80:80'                                                           // service port exposed is 80

// defines certain pre requisites before deploying the service. Herein, nginx service would get started only when web1 and web2 services are up and running.
    depends_on:              
    - web1                     
    - web2
        

In this way one can define the structure of docker-compose.yml and multiple references for defining an efficient docker-compose.yml can be drawn from https://github.com/docker/awesome-compose/tree/master.

Basic Docker Compose commands:

To start services:

docker compose up  
// starts containers and creates new in case containers or any other service such as volumes or networks does not exists        

To stop and remove the running services:

docker compose down        

To start existing services:

docker compose start               // it starts existing containers and does not create new containers        

To stop running services:

docker compose stop        

To stop a particular service:

docker compose stop <service-name>        

To execute command in a running container

docker-compose exec <service_name> <command>        

To copy files from local machine to container

docker-compose cp <service-name>:<SRC_PATH> <DEST_PATH>
//SRC_PATH- could be either on container or host machine

//DEST_PATH- could be either on container or host machine        

To fetch logs

docker compose log // gives log for all the services deployed        

docker compose logs <service-name> // gives logs for a specific container service        

To rebuild services

docker-compose up –build         // it rebuilds existing services with new configurations        

To scale a service

docker-compose up --scale <service-name>=3        

To view and validate configuration

docker-compose config  // shows configuration with enviornment variables and external files        

Docker Swarm vs Docker Compose

One may wonder why to use Docker compose when Docker Swarm and Kubernetes can provide better container orchestration and scalability. Container orchestration tool like Docker Swarm works at a larger scale. It allows you to deploy, manage, and scale Docker containers across multiple hosts in a production environment. Swarm provides features like load balancing, service discovery, and high availability. On the other hand docker compose is primarily used for defining and running multi-container applications in local development environments which makes applications easy to develop and test.

Conclusion

Docker Compose significantly simplifies the process of managing multi-container applications, particularly in lower environments used for development and testing. By allowing developers to define and manage the configuration of all necessary services in a single YAML file, Docker Compose ensures consistency across different environments and accelerates the setup of complex application stacks. It provides a streamlined experience for building, running, and scaling services, with powerful commands for managing containers' lifecycle. Its ease of use, portability, and flexibility make it an essential tool for developers, enabling faster development cycles and more efficient testing workflows. With its robust features and simplicity, Docker Compose is a game-changer for managing containerized applications in lower environments.