Docker-Compose Tutorials

Docker-compose is a powerful tool but simple to use. It runs multiple containers by being a single service. For instance, suppose there is a requirement of Nginx for your application as a web server and a PostgreSQL for database service. By using Docker compose, it is easy to create one single file as docker-compose.yml. It acts as a single service for both containers. In this way, there won't be any need to create two containers separately.

Can We Use Docker Compose for Production?

Docker-compose is used for handling and configuring the docker containers. Using the simple plain docker commands in your environment is possible and can enable Docker to compose usage. This docker-compose has a separate section that allows the docker-compose usage in the production. There are some assumptions on using docker-compose for output. Let's check these pointers now.

What are these Hidden Assumptions?

There are many people involved in the production, and everyone has their own opinion. It can be like 'this is not suited for production' or 'production is ready.' There is no way you can start believing these aspects without questioning them.

The person making assumptions may have some strong opinions about the production environment. Like the environment needs multiple machines for completing a procedure, and even the containers need to be distributed similarly to the devices dynamically.

Using just a docker-compose is not enough; docker swarm, Kubernetes, and any other reliable orchestrator need to be used. These tools will never spoil the production environment. It won't be necessary to distribute the containers dynamically across the numerous machines.

Any Example of a Valid Use Case?

Are you deploying to a single computer and wishing to utilize docker-compose to create your containers? Docker Compose is nothing more than a program that reads the configuration file you provide it and then communicates with the Docker daemon using those settings. You will be alright as long as the containers are used on a single machine.

You can choose the correct architecture to handle load balancing and redundancy by having numerous identical servers behind a load balancer if you need high availability. This design doesn't care how each machine is configured or what software is installed on it as long as the load balancer can send traffic to them.

You can provide an environment using docker-compose, essential Docker, or more traditional methods. Each machine's workload is separate from its siblings, so there's no need to orchestrate containers among them.

What do you say now? Can it be used?

If you're working on a single system and don't need to spread containers over numerous interconnected machines, docker-compose is good. You can use docker-compose if you're okay with just using Docker. It's a valuable tool for managing container configuration and numerous related containers.

The statement "don't use docker-compose in production" is based on hidden assumptions that aren't necessarily true for everyone, and it's spread by ambiguous communication. After all, what manufacturing means to one person may not represent the same thing to another.

Whether you use docker-compose or not, make sure you're careful with Docker, that your images are well-built, that you're following best practices, and that your servers are well-maintained.

Now, why not use docker stack instead of docker-compose? What makes it different from the docker stack? Let's talk about it and eliminate the confusion.

What Makes Docker Compose Different from Docker Stack?

A few things have transpired in the Docker world in recent versions. Swarm mode was added to the Docker Engine in version 1.12, bringing a few additional tools. Without installing Docker Compose, you can use docker-compose.yml files to bring up stacks of Docker containers.

These are almost similar to each other. They both work up to all the services, volumes, networks, and other things mentioned explicitly in the docker-compose.yml file.

What's the Difference?

The Docker stack isn't following the "build" instructions. The stack commands do not allow you to create new pictures. It necessitates the existence of pre-built images. As a result, docker-compose is more appropriate for development scenarios.

There are some elements of the compose-file specification that docker-compose and the stack command disregard. (Search that page for the term "ignore" for more information.)

Docker Compose is written in Python. Initially, a Python project called fig was used to parse fig.yml files and generate. Everyone liked it, especially the Docker people; therefore, it was renamed docker-compose to align with the product. But it was still written in Python and ran on the Docker Engine.

Internally, it makes use of the Docker API to start containers according to a set of rules. To utilize docker-compose with Docker on your machine, you'll need to install it separately.

The Docker engine comes with the Docker Stack feature. It is not necessary to install any additional packages to utilize it. Swarm mode includes the deployment of docker stacks. It supports the same types of compose files as the Docker Engine, but the handling is done in Go code. It would be best if you additionally built a one-machine "swarm" before using the stack command, but this isn't a significant issue.

Docker-compose.yml files written according to the version 2 specification are not supported by the Docker stack. It must be the most recent version, which is currently three at the time of writing. However, Docker Compose can still handle versions 2 and 3 without issue.

Conclusion:

Docker stack performs nearly all of the functions of Docker compose. If you wish to use Docker Swarm for container orchestration, give it a shot and see how it goes. You may need to upgrade your Docker compose files from version 2 to 3.

You can safely remain with docker-compose if you only require a tool to make it easier to manage running several containers at once. It fulfills all of your requirements, and you can always switch to Docker Stack later.