I almost never start production docker images on my machine, but it is true that it is a pain to start them and I usually end up like an ape passing the env variables before docker command 
.
D4no0
1
coen.bakker
I heard arguments for using Docker and Docker Compose for development, not just production.
For example here:
I don’t get the impression this is a common practice, however. Any idea why? Simply because it is extra effort for little gain?
0
sodapopcan
I say “probably” because I tend to avoid Docker myself. I don’t have anything against it, I just spent a few years entirely disinterested in anything ops-related. That’s changing, however, so I will probably reacquaint myself. At a past job we used Docker for development (I just didn’t do any of the setup). I actually have no idea why anyone would think it’s a bad idea as it went quite smoothly for us. The only thing I can think of is that it’s memory intensive on macos so maybe with larger apps that becomes more of a thing. I have yet to watch the video you shared but I’ll add it to my queue.
1
D4no0
Why would you do that? Maintaining a readme of what should be installed and configuration is much more time efficient than losing time on recompilation, storage space and ram.
0
sodapopcan
No idea. You’d have to ask the ops team at that job who mandated that 
I didn’t notice recomp times to be too bad but the whole thing was a Rube Goldberg Machine anyway so I always chalked up the slight slowness to that, but it wasn’t so bad. It can definitely make sense for people working on multiple projects using different version of Postgres, for example, though I’m never in that situation myself. But ya, it certainly didn’t feel necessary working on a company machine dedicated to working on one project.
1
coen.bakker
I heard the argument that using Docker in development can prevent bugs that are caused by differences in OS. And more generally the argument that the closer the development environment is to the production environment, the smaller the potential for issues when pushing to production.
I don’t really have an opinion about that argument myself. But I’m interested in the topic. Do these arguments make sense and are they valid in practice?
0
D4no0
Usually if you have a dockerized prod, your CI that will run tests will be in docker containers too, so as long as those tests run successfully on CI, there should be absolute no problems.
I don’t think so, as long as your setup is to create a release, and you are using the same versions of elixir and OTP on prod as well as dev, everything will work the same.
The only real benefit I see is the fact that you can preinstall and configure some settings in a repeatable way, literally the fact why docker is useful in the first place, however in practice I’ve never had projects requiring anything more than installation of some local dependencies.
I did have some ecto bugs on the last project I worked on, setting up sandbox for testing. Those surfaced only in the docker image on CI, no idea what that was about, a possible explanation would be that we were using a old version of exqlite.
2
coen.bakker
woylie
You can either run a Docker container with Elixir installed in the docker compose setup and share the project folder as a volume. In that case, you just run mix phx.server within the Docker container instead of locally on your machine (probably with an entrypoint script). So you don’t have to rebuild the image all the time.
But nowadays, I usually just have a docker compose setup for Postgres, Minio, or whatever services I need for development, and run the Phoenix server locally. That’s a bit less of a hassle.
If you need secrets in your local environment and you use a password manager with a CLI (like 1password or bitwarden), you can use that to set the environment variables. This has the advantage that you can just add a shell script to set those variables, and the script can safely be committed. Then you just have to make sure every team member has access to the shared vault.
3
sodapopcan
Ah, this exposes my ignorance re: Docker. My old with was clearly doing something like this, in that we were running rails and no locally. Thanks for the explanation!
0