3 ms·

I can’t live without it. The power of docker compose for the development process is unparalleled. Being able to declare my entire local environment in a single

I can’t live without it. The power of docker compose for the development process is unparalleled. Being able to declare my entire local environment in a single file in a consistent way, create and destroy it with a simple command, and share it with my co-workers eliminates so many issues. Then being able to package my application in way that is repeatable and predictable is great. Then that same artifact is run across multiple environments spanning data centers around the world and on other developers’ machines via their compose files if needed. We test the crap out of all of this as well. Docker helps there to generate ephemeral environments to run the bulk of the integration tests against every time we push to git. Its just so damn powerful compared to what we had before…

stavros 3y ago
Agreed, and the fact that I can launch and develop my web app from seven years ago, no matter how much my environment has changed, is a lifesaver. There's a lot of code I've written that's not deployable any more because the versions of the dependencies it was using don't exist on my OS any more, and are too old to install.
- deleted 3y ago
  [deleted]
- friendzis 3y ago
  As long as you have saved the container image and contents of all mapped volumes somewhere. Which is not much different from snapshotting a VM.
  - imtringued 3y ago
    Snapshotting a VM is a pain in the ass. It takes forever and the tooling sucks. The concept of snapshotting is also completely wrong. Snapshots are tied to a VM with the specific VM being front and center, you know, the thing that is disposable with containers. Also, from my misadventures with Ubuntu VMs I always ran into the problem of them breaking over time.
UniqueUsername0 3y ago
Repeatable, not reproduicible...
- sixstringtheory 3y ago
  Those sound the same to me. Are you drawing a distinction between a repeatable/reproducible process vs result? Like if you run the same command to fetch a dependency, you wind up with different results if the dependency maintainer releases a new update and you aren’t pinning the dependency?
  - thfuran 3y ago
    Reproducible in that context means that repeating will produce exactly the same output every time.
  - robbintt 3y ago
    To use the apt analogy further up in the thread, `sudo apt install git` is repeatable in your dockerfile, but often not reproducible. Later on you will get a different build. Across say 500 packages and 1,000,000 containers (or say 1000 container images if you are deploying images) over even a week this becomes extremely... varied...
    - nerdponx 3y ago
      On smaller scales, this is perfectly fine. How often does Git actually release breaking changes of features that you actually need to use inside your Dockerfile? How often does Debian pull in such a version into their stable OS? And why didn't you just version-pin Git like Hadolint told you to do? Exact reproducibility is nice for two scenarios: 1) academic research, and 2) very large-scale applications and deployments. For regular people writing boring small web apps, choosing a stable base image and pinning dependencies is good enough. Consider also that your preferred programming language will also very likely not provide particularly reproducible package builds.
    - happymellon 3y ago
      Although you can. This just means you don't. Try using `sudo apt install git=1:2.39.2-1ubuntu1` That pins it to a particular version so that it should be reproducible.

stavros 3y ago

Agreed, and the fact that I can launch and develop my web app from seven years ago, no matter how much my environment has changed, is a lifesaver. There's a lot of code I've written that's not deployable any more because the versions of the dependencies it was using don't exist on my OS any more, and are too old to install.

deleted 3y ago
[deleted]
friendzis 3y ago
As long as you have saved the container image and contents of all mapped volumes somewhere. Which is not much different from snapshotting a VM.
- imtringued 3y ago
  Snapshotting a VM is a pain in the ass. It takes forever and the tooling sucks. The concept of snapshotting is also completely wrong. Snapshots are tied to a VM with the specific VM being front and center, you know, the thing that is disposable with containers. Also, from my misadventures with Ubuntu VMs I always ran into the problem of them breaking over time.

UniqueUsername0 3y ago

Repeatable, not reproduicible...

sixstringtheory 3y ago
Those sound the same to me. Are you drawing a distinction between a repeatable/reproducible process vs result? Like if you run the same command to fetch a dependency, you wind up with different results if the dependency maintainer releases a new update and you aren’t pinning the dependency?
- thfuran 3y ago
  Reproducible in that context means that repeating will produce exactly the same output every time.
- robbintt 3y ago
  To use the apt analogy further up in the thread, `sudo apt install git` is repeatable in your dockerfile, but often not reproducible. Later on you will get a different build. Across say 500 packages and 1,000,000 containers (or say 1000 container images if you are deploying images) over even a week this becomes extremely... varied...
  - nerdponx 3y ago
    On smaller scales, this is perfectly fine. How often does Git actually release breaking changes of features that you actually need to use inside your Dockerfile? How often does Debian pull in such a version into their stable OS? And why didn't you just version-pin Git like Hadolint told you to do? Exact reproducibility is nice for two scenarios: 1) academic research, and 2) very large-scale applications and deployments. For regular people writing boring small web apps, choosing a stable base image and pinning dependencies is good enough. Consider also that your preferred programming language will also very likely not provide particularly reproducible package builds.
  - happymellon 3y ago
    Although you can. This just means you don't. Try using `sudo apt install git=1:2.39.2-1ubuntu1` That pins it to a particular version so that it should be reproducible.