First, I saw this dicuss, but I’m not happy with the final solution: Dockerfile inconsistent build vs local
My problem is: when I run the latest builded docker container, I see the database.yml configured with test parameters (from the circleci build), so my app doesn’t work.
I really think that cloning or pulling the project again to another dir and make some “hand made tricks” is not the right way to build the app in docker.
What is the right way to put the right database.yml configuration from my project into the docker container?
Here’s my database.yml:
database: <%= ENV[‘DATABASE_NAME’] %>
port: <%= ENV[‘DATABASE_PORT’] %>
pool: <%= ENV[‘POOL’] %>
username: <%= ENV[‘DATABASE_USERNAME’] %>
password: <%= ENV[‘DATABASE_PASSWORD’] %>
host: <%= ENV[‘DATABASE_HOST’] %>
Here’s the deployment session in my circle.yml:
- docker build -t $DOCKER_REGISTRY/$CIRCLE_PROJECT_REPONAME:$CIRCLE_SHA1 .
- docker tag $DOCKER_REGISTRY/$CIRCLE_PROJECT_REPONAME:$CIRCLE_SHA1 $DOCKER_REGISTRY/$CIRCLE_PROJECT_REPONAME:latest
- docker push $DOCKER_REGISTRY/$CIRCLE_PROJECT_REPONAME:$CIRCLE_SHA1
- docker push $DOCKER_REGISTRY/$CIRCLE_PROJECT_REPONAME:latest
Author of the post you linked to here! Agreed it was a really hackish thing we did. I found a slightly nicer way to do this by running a git reset --hard on the folder. This also fixed the race condition of sorts that if someone else commited to dev between the test running and the second git clone, the newer (untested) code would be pulled. It is still some what of a hack but cleaner
- git reset --hard && rm -rf vendor && rm -rf log/* && cd _deploy && ./deploy.sh Dockerfile.template
If you want you can remove the && and just run each command individually now as we are no longer leaving the top line directory
- git reset --hard
- rm -rf vendor
- rm -rf log/*
- ./_depoly/deploy.sh Dockerfile.template
Note for us we rm -rf’d the vendor and log folder as they ballooned the size of the docker image by 500mb. Our .gitignore ignores the vendor and logfile so we had to rm it as git reset --hard didn’t ignore it. The reset should revert your database file correctly.
Again not the best by far but a step forward from my last post :).