I'm trying to deploy an app that's built with docker-compose, but it feels like I'm going in completely the wrong direction.
- I have everything working locally—
docker-compose up
brings up my app with the appropriate networks and hosts in place. - I want to be able to run the same configuration of containers and networks on a production machine, just using a different
.env
file.
My current workflow looks something like this:
docker save [web image] [db image] > containers.tar
zip deploy.zip containers.tar docker-compose.yml
rsync deploy.zip user@server
ssh user@server
unzip deploy.zip ./
docker load -i containers.tar
docker-compose up
At this point, I was hoping to be able to run docker-compose up
again when they get there, but that tries to rebuild the containers as per the docker-compose.yml
file.
I'm getting the distinct feeling that I'm missing something. Should I be shipping over my full application then building the images at the server instead? How would you start composed containers if you were storing/loading the images from a registry?
The problem was that I was using the same docker-compose.yml file in development and production.
The app service didn't specify a repository name or tag, so when I ran
docker-compose up
on the server, it just tried to build the Dockerfile in my app's source code directory (which doesn't exist on the server).I ended up solving the problem by adding an explicit image field to my local docker-compose.yml.
Then created an alternative compose file for production:
After running
docker-compose build
locally, the web service image is built with the repository namemy-private-docker-registry
and the taglatest
.Then it's just a case of pushing the image up to the repository.
And running
docker pull
, it's safe to stop and recreate the running containers, with the new images.