8 ms·

So many gotchas like this in dockerfiles. I think the issue stems from it being such a leaky abstraction. To use it correctly you need to know how docker works

So many gotchas like this in dockerfiles. I think the issue stems from it being such a leaky abstraction. To use it correctly you need to know how docker works internally inside and out, as well as Linux inside and out. The default choices are baffling in docker, it really is a worse-is-better kind of tool. Has anyone worked on a replacement for dockerfiles? I know buildah is an alternative to docker build, but it just uses the same file format

fenollp 5y ago
https://github.com/moby/buildkit https://github.com/moby/buildkit
viraptor 5y ago
You can also use buildah commands without the whole dockerfile abstraction. As a structured alternative there's also an option to build container images from nix expressions.
Too 5y ago
Never tried myself but this is the most serious attempt I’ve seen on alternative docker syntax https://earthly.dev/ https://earthly.dev/ You also have mockerfiles, being more of a proof of concept if I understand correctly https://matt-rickard.com/building-a-new-dockerfile-frontend/ https://matt-rickard.com/building-a-new-dockerfile-frontend/
- adamgordonbell 5y ago
  Earthly is great (disclosure: work on it) But also checkout out IckFiles, an Intercal frontend for moby buildkit: https://github.com/adamgordonbell/compiling-containers/tree/main/ickfile https://github.com/adamgordonbell/compiling-containers/tree/...
xinnixxinix 5y ago
Sure, there are, but they all have enough of a learning curve that they don't seem to take hold with the masses. Nix, Guix, Bazel, Habit, and others, all solve this problem more elegantly. There are some big folks out there, quiet quietly using Nix to solve: * reproducible builds * shared remote/CI builds * trivial cross-arch support * minimal container images * complete knowledge of all SW dependencies and what-is-live-where * "image" signing and verification I know docker and k8s well and it's kind of silly how much simpler the stack could be made if even 1% of the effort spent working around Docker were spent by folks investing in tools that are principally sound instead of just looking easy at first glance. Miss me with the complaints about syntax. It's just like Rust. Any pain of learning is very quickly forgotten by the unbridled pace at which you can move. And besides, it's nothing compared to (looks at calendar) 5 years of "Top 10 Docker Pitfalls!" as everyone tries to pretend the teetering pile of Go is making their tech debt go away. I never thought I'd come around to being someone wary of the word "container", as someone who sorta made it betting on them. There is so little care for actually managing and understanding the depth of one's software stack, well, we have this. (Pouring one out for yet another Dockerfile with apt-get commands in it.)
- rtpg 5y ago
  Docker provides a solution for balls of mud. You now have a more reproducible ball of mud! Bazel and company require you to clean up your ball of mud first. So your payoff is further away (and can sometimes be theoretical) Ultimately it’s less about Docker and more about tooling supporting reproducibility (apt but with version pinning please), but in the meantime Docker does get you somewhere and solve real problems without having to mess around with stuff too much. And of course the “now you have a single file that you can run stuff with after building the image ”. I don’t believe stuff like Nix offers that
  - ParetoOptimal 5y ago
    > And of course the “now you have a single file that you can run stuff with after building the image ”. I don’t believe stuff like Nix offers that Yes it does? Also, any nix expression can trivially be built into a much more space efficient docker container.
    - rtpg 5y ago
      Can you generate a tar file that you can “just run“ (or something to that effect)? My impression was that Nix works more like a package installer, but deterministic
      - rekado 5y ago
        `guix pack` (with its various options) can produce an archive that you could run after unpacking anywhere.
      - henrydark 5y ago
        There might be quicker ways to do this, but with one extra line a derivation exports a docker image which can in turn be turned to a tar with one more line. Nix's image building is pretty neat. You can control how many layers you want, which I currently maximize so that docker pulls from AWS ECR are a lot faster
      - 5y ago
brigandish 5y ago
I've been using Packer with the Docker post-processor. I’ve had to give up multi-stage builds but being able to ditch Dockerfiles and simply write a shell script without a thousand &&\’s is more than enough reason to keep me using it.
- fivea 5y ago
  > I’ve had to give up multi-stage builds but being able to ditch Dockerfiles and simply write a shell script without a thousand &&\’s is more than enough reason to keep me using it. I don't understand your point. If all you want to do is set a container image by running a shell script, why don't you just run the shell script in your Dockerfile? Or better yet, prepare your artifacts before, and then build the Docker image by just copying your files. It sounds like you decided to take the scenic route of Docker instead of just taking the happy path.
  - brigandish 5y ago
    I’m glad you were able to infer so much from so little, but what it actually sounds like is that you don’t know how helpful it is to build with a system like Packer. As others have pointed out, Dockerfiles are full of gotchas, the incomprehensible mess that they become due to the limited format and the need for workarounds is only half the reason I use packer now. If you think Dockerfiles produce a “happy” path, then good for you, but you might first fix the COPY command and make sure it works for multiple files, with args, and ONBUILD, or any of the other warts sitting around in the issue list. We’re all waiting. Meanwhile, I write packer files in HCL - a saner language and a saner format - without worrying about the way files are copied. Of course, it’s not perfect but I’d choose any of the other suggestions here before going back to Dockerfiles based on your optimism and the knowledge - that I already had but virtually every author of a Dockerfile ignores - that I can RUN a script. Thanks, but no thanks.
silisili 5y ago
Agreed, but not sure the answer. I run Linux as I always have. Building and running are super simple. I feel like Docker was created more or less to let Mac devs do Linux things. Wastefully. And without a lot of reason, tbh. And of course, they don't generally even understand Linux.
- dimitrios1 5y ago
  Why would a technology built on top of cgroups, a feature only available in the linux kernel, be created to "let mac devs do linux things"? In fact, running docker on Mac was painful in the early days with boot2docker.
  - silisili 5y ago
    Just my experience on my team. The Linux guys were already building and running things locally. So the sales pitch so to speak from our team were the Mac guys saying 'hey, now we can build and test locally!', whereas the Linux guys just kinda found it a slight annoyance. Things have certainly changed with the rise of kube, ecr, and the such. But in the time of doing standard deploys into static vms, it didn't make a ton of sense.
    - dimitrios1 5y ago
      I encourage you to investigate where docker came from, and the rise of containerization in general. The notion that you have is rather misinformed and anachronistic. Competing against standard deploys onto VMS, especially using proprietary software is exactly why containerization gained a foothold. Whatever this anecdote your team told you about Mac guys, this just has nothing to do with docker's, and containers in general, rise to fame. It wouldn't be until much later when Mac users were starting to rely on tools like Vagrant for development environments where docker was seen as an alternative to that. If your team were real linux guys, they probably would have already known about lxc, as well as all the other technologies that lead up to it: jails, solaris containers, and vserver, so seeing this as "some annoying mac thing" is especially puzzling to me.

fenollp 5y ago

https://github.com/moby/buildkit https://github.com/moby/buildkit

viraptor 5y ago

You can also use buildah commands without the whole dockerfile abstraction. As a structured alternative there's also an option to build container images from nix expressions.

Too 5y ago

Never tried myself but this is the most serious attempt I’ve seen on alternative docker syntax https://earthly.dev/ https://earthly.dev/ You also have mockerfiles, being more of a proof of concept if I understand correctly https://matt-rickard.com/building-a-new-dockerfile-frontend/ https://matt-rickard.com/building-a-new-dockerfile-frontend/

adamgordonbell 5y ago
Earthly is great (disclosure: work on it) But also checkout out IckFiles, an Intercal frontend for moby buildkit: https://github.com/adamgordonbell/compiling-containers/tree/main/ickfile https://github.com/adamgordonbell/compiling-containers/tree/...

xinnixxinix 5y ago

Sure, there are, but they all have enough of a learning curve that they don't seem to take hold with the masses. Nix, Guix, Bazel, Habit, and others, all solve this problem more elegantly. There are some big folks out there, quiet quietly using Nix to solve: * reproducible builds * shared remote/CI builds * trivial cross-arch support * minimal container images * complete knowledge of all SW dependencies and what-is-live-where * "image" signing and verification I know docker and k8s well and it's kind of silly how much simpler the stack could be made if even 1% of the effort spent working around Docker were spent by folks investing in tools that are principally sound instead of just looking easy at first glance. Miss me with the complaints about syntax. It's just like Rust. Any pain of learning is very quickly forgotten by the unbridled pace at which you can move. And besides, it's nothing compared to (looks at calendar) 5 years of "Top 10 Docker Pitfalls!" as everyone tries to pretend the teetering pile of Go is making their tech debt go away. I never thought I'd come around to being someone wary of the word "container", as someone who sorta made it betting on them. There is so little care for actually managing and understanding the depth of one's software stack, well, we have this. (Pouring one out for yet another Dockerfile with apt-get commands in it.)

rtpg 5y ago
Docker provides a solution for balls of mud. You now have a more reproducible ball of mud! Bazel and company require you to clean up your ball of mud first. So your payoff is further away (and can sometimes be theoretical) Ultimately it’s less about Docker and more about tooling supporting reproducibility (apt but with version pinning please), but in the meantime Docker does get you somewhere and solve real problems without having to mess around with stuff too much. And of course the “now you have a single file that you can run stuff with after building the image ”. I don’t believe stuff like Nix offers that
- ParetoOptimal 5y ago
  > And of course the “now you have a single file that you can run stuff with after building the image ”. I don’t believe stuff like Nix offers that Yes it does? Also, any nix expression can trivially be built into a much more space efficient docker container.
  - rtpg 5y ago
    Can you generate a tar file that you can “just run“ (or something to that effect)? My impression was that Nix works more like a package installer, but deterministic
    - rekado 5y ago
      `guix pack` (with its various options) can produce an archive that you could run after unpacking anywhere.
    - henrydark 5y ago
      There might be quicker ways to do this, but with one extra line a derivation exports a docker image which can in turn be turned to a tar with one more line. Nix's image building is pretty neat. You can control how many layers you want, which I currently maximize so that docker pulls from AWS ECR are a lot faster
    - 5y ago

brigandish 5y ago

I've been using Packer with the Docker post-processor. I’ve had to give up multi-stage builds but being able to ditch Dockerfiles and simply write a shell script without a thousand &&\’s is more than enough reason to keep me using it.

fivea 5y ago
> I’ve had to give up multi-stage builds but being able to ditch Dockerfiles and simply write a shell script without a thousand &&\’s is more than enough reason to keep me using it. I don't understand your point. If all you want to do is set a container image by running a shell script, why don't you just run the shell script in your Dockerfile? Or better yet, prepare your artifacts before, and then build the Docker image by just copying your files. It sounds like you decided to take the scenic route of Docker instead of just taking the happy path.
- brigandish 5y ago
  I’m glad you were able to infer so much from so little, but what it actually sounds like is that you don’t know how helpful it is to build with a system like Packer. As others have pointed out, Dockerfiles are full of gotchas, the incomprehensible mess that they become due to the limited format and the need for workarounds is only half the reason I use packer now. If you think Dockerfiles produce a “happy” path, then good for you, but you might first fix the COPY command and make sure it works for multiple files, with args, and ONBUILD, or any of the other warts sitting around in the issue list. We’re all waiting. Meanwhile, I write packer files in HCL - a saner language and a saner format - without worrying about the way files are copied. Of course, it’s not perfect but I’d choose any of the other suggestions here before going back to Dockerfiles based on your optimism and the knowledge - that I already had but virtually every author of a Dockerfile ignores - that I can RUN a script. Thanks, but no thanks.

silisili 5y ago

Agreed, but not sure the answer. I run Linux as I always have. Building and running are super simple. I feel like Docker was created more or less to let Mac devs do Linux things. Wastefully. And without a lot of reason, tbh. And of course, they don't generally even understand Linux.

dimitrios1 5y ago
Why would a technology built on top of cgroups, a feature only available in the linux kernel, be created to "let mac devs do linux things"? In fact, running docker on Mac was painful in the early days with boot2docker.
- silisili 5y ago
  Just my experience on my team. The Linux guys were already building and running things locally. So the sales pitch so to speak from our team were the Mac guys saying 'hey, now we can build and test locally!', whereas the Linux guys just kinda found it a slight annoyance. Things have certainly changed with the rise of kube, ecr, and the such. But in the time of doing standard deploys into static vms, it didn't make a ton of sense.
  - dimitrios1 5y ago
    I encourage you to investigate where docker came from, and the rise of containerization in general. The notion that you have is rather misinformed and anachronistic. Competing against standard deploys onto VMS, especially using proprietary software is exactly why containerization gained a foothold. Whatever this anecdote your team told you about Mac guys, this just has nothing to do with docker's, and containers in general, rise to fame. It wouldn't be until much later when Mac users were starting to rely on tools like Vagrant for development environments where docker was seen as an alternative to that. If your team were real linux guys, they probably would have already known about lxc, as well as all the other technologies that lead up to it: jails, solaris containers, and vserver, so seeing this as "some annoying mac thing" is especially puzzling to me.