@cnck1387 ah ok, thx! Nice to know. Never ran into an issue like that before.
otijhuis
cnck1387
I have on occasion. In one of my earlier Docker courses I didn’t do that step and I distributed a zip file to folks who signed up. Certain unzip utilities stripped the executable bit from all files, so a number of people ended up running into that problem.
1
otijhuis
Annoying when things like that happen. Have had my fair share of trouble with docker and docker-compose, especially on windows. Only using linux or linux vm’s now. Saves me a lot of headaches.
0
JovaniPink
otijhuis
@cnck1387 was tweaking the dockerfile a little more and was thinking about what you said about chmod. Did you mean providing the people with the source code and have them build the docker image locally? If so then I understand the issue with losing the execute bit and I’ve had those issues before. In this particular case the release (including the executable) gets built inside the dockerfile though and doesn’t get copied from outside.
0
cnck1387
Yeah, that’s what I did in that case.
How does the bin/ directory make its way into the image?
0
otijhuis
Ah, then I know all about the issue you ran into. I run into it with git at times where I have to add the execute bit later on. I was confused at first considering it’s the mix release command that actually creates/bundles all the files that end up in the app folder. They are created in the release stage inside the dockerfile and are copied into the final image with COPY --from=release. So nothing from the outside actually gets copied into the final image.
0
qhwa
Good job! Thanks to you, I’m improving my old projects, inspired by this awesome Dockerfile.
I think there is still an opportunity to make it even better. I mean we can add a compile stage, where we run mix compile. This stage will be running in parallel with npm run deploy, and makes next mix phx.digest and mix release very fast.
Here’s what I’ve got so far, and it works pretty well~
A lot of new technologies learned from this thread. Thank you!
1
otijhuis
It can definitely be improved 
. Still tweaking it myself. I removed the node image and just added node and such to the elixir base image. Saves another image download. In other frontend projects I want a bit more control over the used node version but here it doesn’t matter as much. I also created a separate RUN command for installing hex/rebar. Then they won’t be reinstalled every time a dependency changes.
I checked your dockerfile and there are a few things I noticed:
It’s recommended to use COPY instead of ADD unless you need specific functionality that ADD provides.
ADD . . will copy the whole context. This means if a single file changes, even if you don’t care about it in that stage, the layer cache will be invalidated and everything that depends on it will have to run again. Try to copy only the files you need for that stage.
Even though some stages can run in parallel like you mentioned, by doing so you’re invalidating the docker layer cache more frequently. You’re doing an ADD . . before the compile. Even if you only copy the lib/deps folders it would still do a full compile if you change a single line. So compilation that’s only needed for phx.digest would run again as well.
The trick with dockerfiles is not to optimise for a single build but making sure you’re invalidating the layer cache as little as possible. And making sure the final image size is as small as possible of course. Try changing a single elixir file and run the build again and then do the same when you change a css file for instance. Check the output to see what’s being cached and what isn’t. Right now a rebuild after changing a single line of elixir code takes 5 seconds in my project. I have a feeling it will take quite a bit longer in your case.
1