CODEWITHSUNDEEP
dockerdocker-compose
user2519184
user2519184

Reputation: 67

docker-compose up on exiting docker-compose

i have simple docker-copose.yml which builds 4 containers. The containers run's on EC2. docker-compose change ~ twice a day on master branch, and each change we need to deploy the new containers on production

this is what i'm doing:

docker-compose down --rmi all
git pull origin master
docker-compose build -d

i'm removing images to avoid conflicts so that once i'm starting the service i have fresh images

This process takes me around ~ 1 minutes, what is the best practice to spin up docker-compose, any suggestion to improve this ?

Upvotes: 2

Views: 253

Answers (1)

David Maze
David Maze

Reputation: 158647

You can do the set of commands you show natively in Docker, without using git or another source-control tool as part of the deployment process.

Whenever you have a change to your source tree, build a new Docker image and push it to a Docker repository. This can be Docker Hub, or if you're on AWS already, Amazon ECR. Each build should have a unique image tag, such as a source control commit ID or a time stamp. You can set up a continuous-integration tool to do all of this for you automatically.

Once you have this, your docker-compose.yml file needs to be updated with the version number to deploy. If you only have a single image you're deploying, you can straightforwardly use Compose variable substitution to fill it in

image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myimage:${TAG:-latest}

If you have multiple images you can set multiple environment variables or produce an updated docker-compose.yml file with the values filled in, but you will need to know all of the image versions together at deployment time.

Now when you go to deploy it you only need to run

TAG=20200317.0412 docker-compose up -d

to set the environment variable and trigger Compose. Compose will see that the image you're trying to run for that container is different from what's already running, pull the updated image, and replace the container for you. You don't need to manually remove the old containers or stop the entire stack.

If git is part of your workflow now, it's probably because you're mounting application code into your container. You will also need to delete any volumes: that overwrite the content in the image. Also make sure you make this change in your CI system (so you're testing the actual image you're deploying to production) and in development (similarly).

This particular task becomes slightly easier with a cluster-management system like Kubernetes (or Amazon EKS), though it brings many other complexities elsewhere. In Kubernetes you need to send an updated Deployment spec to the Kubernetes API server, but you can do this without direct ssh access to the target system and only needing to know the specific version of the one image you're updating, and with multiple replicas you can get a zero-downtime upgrade. Both using a Docker repository and using a unique image tag per build are basically required in this setup: images are the only way code gets into the cluster, and changing the image tag string is what triggers code to be redeployed.

Upvotes: 1

Related Questions