3 ms·
I certainly have. And there is often a Dockerfile or a docker-compose file. And the docs will say "just run docker-compose up, and you should be good to go." A
by toastercat 4y ago
I certainly have. And there is often a Dockerfile or a docker-compose file. And the docs will say "just run docker-compose up, and you should be good to go."
And 50% of the time it actually works. The other 50% of the time, it doesn't, and I spend a week talking to other engineers and ops trying to figure out why.
Not a jab at Docker, btw.
- brundolf 4y agoAnd to borrow from the classic regex saying: "Now you have two problems"
- jayd16 4y agoWhat are some common error cases you see this way?
- tomhallett 4y agoThe thing I've been trying - instead of the docs saying "just run docker-compose up" (and a few other commands), put all of those commands in a bash script. That single bootstrap command should: docker compose down, docker compose build, docker login, [install gems/npm modules], rake db:reset (delete + create), docker compose up, rake generate_development_data. This way each developer can/should tear down and rebuild their entire development environment on a semi-frequent basis. That way you know it works way more than 50% of the time. (Stretch goal: put this in CI.... :) The other side benefit: if you reset/restore your development database frequently, you are incentived/forced to add any necessary dev/test data into the "rake generate_development_data", which benefits all team members. (I have thought about a "generate_development_data.local.rb" approach where each dev could extend the generation if they shouldn't commit those upstream, but haven't done that by anymeans....)