3 ms·

As others are saying, Docker is a tool for repeatable environments. I have an application with a long, tedious setup process involving dozens of apt dependenci

As others are saying, Docker is a tool for repeatable environments. I have an application with a long, tedious setup process involving dozens of apt dependencies that I don’t maintain. In the past, I’ve had issues with things not updating properly, inconsistencies between versions, spontaneous breakages... Using Docker, I built an image that contains all the dependencies that are unrelated to my code or configuration, then another image relies on this and contains all of my stuff. My deployment process only needs to be concerned with updating this second image and all of the frightening dependencies are guaranteed to be consistent and reliable. This second image is deployed to each box. All of the production systems are identical and if I need a new production box, I can have it ready to go in minutes and be confident that it will work and behave reliably.

aib 8y ago
> [...] I built an image that contains all the dependencies [...] How, may I ask? I've been looking for a good way to do this for a long time; nowadays I'm using a checklist and AMIs on AWS. Ansible is too damn slow, does not know how config files work and clutters the terminal/my home directory/my known_hosts. Dockerfile is a badly written shell script using && instead of errexit.
- sickcodebruh 8y ago
  I'm not sure if mine is a good way of doing it but it's working for me. I took the relevant portion of my own badly written shell script, moved it into its own Dockerfile that has its own CI project and its own private repo on Quay, and I rebuild/republish as needed. The remainder of my original shell script went into the Dockerfile for the project that holds my code. The first line of this Dockerfile just starts with my base image. FROM quay.io/my-acct/my-image:latest
- syntheticcdo 8y ago
  The point of the && in a Dockerfile is because every single RUN directive adds another layer to the final image. Less layers = slimmer images = faster and lighter deploys.
  - aib 8y ago
    Yes. Also, the only thing that survives between RUN directives is the disk image so && saves state: start-daemon && configure-daemon-while-running && stop-daemon The point is, I've seen far more && than RUN directives so the decision was backwards.

aib 8y ago

> [...] I built an image that contains all the dependencies [...] How, may I ask? I've been looking for a good way to do this for a long time; nowadays I'm using a checklist and AMIs on AWS. Ansible is too damn slow, does not know how config files work and clutters the terminal/my home directory/my known_hosts. Dockerfile is a badly written shell script using && instead of errexit.

sickcodebruh 8y ago
I'm not sure if mine is a good way of doing it but it's working for me. I took the relevant portion of my own badly written shell script, moved it into its own Dockerfile that has its own CI project and its own private repo on Quay, and I rebuild/republish as needed. The remainder of my original shell script went into the Dockerfile for the project that holds my code. The first line of this Dockerfile just starts with my base image. FROM quay.io/my-acct/my-image:latest
syntheticcdo 8y ago
The point of the && in a Dockerfile is because every single RUN directive adds another layer to the final image. Less layers = slimmer images = faster and lighter deploys.
- aib 8y ago
  Yes. Also, the only thing that survives between RUN directives is the disk image so && saves state: start-daemon && configure-daemon-while-running && stop-daemon The point is, I've seen far more && than RUN directives so the decision was backwards.