4 ms·

> This universal container system goes out the window the first minute you have to start modifying everything to fit edge cases, which is always going to happen

by shykes 13y ago

> This universal container system goes out the window the first minute you have to start modifying everything to fit edge cases, which is always going to happen. This is why the Dockerfile is so important. I would never use an opaque binary container as part of my production app. But I definitely would use said container if I could point to its exact source repository, modify it to my liking, and rebuild it in a repeatable way. That is possible with the docker build system :)

peterwwillis 13y ago
The Dockerfile, as it currently exists, is a wrapper for shell commands, that does less than the shell does. There's no reason to use it over a plain old Bash script or Makefile.
- shykes 13y ago
  That's not accurate. The syntax is irrelevant - if you compare it to a shell script you are missing the purpose of the dockerfile. The purpose is to make an otherwise inert source checkout runnable. Point me to a shell script that does the same thing. You will no doubt point me to some script you wrote as a sysadmin. I wrote similar scripts as a sysadmin. They are unusable to anyone outside your immediate team of sysadmins - you can't use my scripts, and I can't use yours. That's because they're ambiguous. They assume that other things are already present on the system, and don't specify how to make sure that's true. There's a README next to them explaining what they require, how to bootstrap a build and so on. Dockerfiles don't require a readme. They are not ambiguous. That's why they're useful. They also specify where to drop source files in a container, which allows you to get rid of your custom scp + flip-a-symlink ghetto deployment script.
  - peterwwillis 13y ago
    What you describe is the exact purpose behind Automake and Autoconf, which, while horrifying to use, are basically just shell scripts that make an app work on any platform. Please don't pretend that a Dockerfile is some new paradigm shift in how to deploy an app on a remote host. And really, who gives a shit about "custom" vs "standardized" argument passing? And what's with the ghetto references? You do realize under the hood your Dockerfile and my 'ghetto script' are calling the same syscalls, making the same network connections, doing the same i/o, right? Who gives a shit if my 'script' is 'ghetto' if it's ten times more user accessible, portable and backwards compatible than your proprietary format? A developer isn't going to spend more than 5 minutes looking at what the assholes in ops have given them to do their job; they learn it, they use it, they move on with writing and testing their code. Docker doesn't improve anything or provide anything you couldn't already do before. It just creates a new niche. Your whole argument for the use of Docker seems to be "we are superior, because our operations are fancier, and we have created a gold standard." Face it: it doesn't matter how the sausage gets made. Docker just prescribes one way for how the meat is ground, vs all the others that work just as well.
    - jpetazzo 13y ago
      The Dockerfile provides caching. When you tweak a few things, you don't have to re-run the whole script, which is great if there are some expansive steps (e.g. downloading and installing Java, compiling a big library, etc.) Of course, you can achieve something similar with shell scripts, e.g. "if Java is not installed, install it, otherwise go to the next step". But if you get it wrong, or if there is some side-effect, the end result (after running the script multiple times) won't be exactly the same. The Dockerfile (with snapshots at each step) ensures consistency. It's not a big deal if you are a shell expert and write that kind of script for breakfast, but it's not the case for everyone :)

by shykes 13y ago

peterwwillis 13y ago

The Dockerfile, as it currently exists, is a wrapper for shell commands, that does less than the shell does. There's no reason to use it over a plain old Bash script or Makefile.

shykes 13y ago
That's not accurate. The syntax is irrelevant - if you compare it to a shell script you are missing the purpose of the dockerfile. The purpose is to make an otherwise inert source checkout runnable. Point me to a shell script that does the same thing. You will no doubt point me to some script you wrote as a sysadmin. I wrote similar scripts as a sysadmin. They are unusable to anyone outside your immediate team of sysadmins - you can't use my scripts, and I can't use yours. That's because they're ambiguous. They assume that other things are already present on the system, and don't specify how to make sure that's true. There's a README next to them explaining what they require, how to bootstrap a build and so on. Dockerfiles don't require a readme. They are not ambiguous. That's why they're useful. They also specify where to drop source files in a container, which allows you to get rid of your custom scp + flip-a-symlink ghetto deployment script.
- peterwwillis 13y ago
  What you describe is the exact purpose behind Automake and Autoconf, which, while horrifying to use, are basically just shell scripts that make an app work on any platform. Please don't pretend that a Dockerfile is some new paradigm shift in how to deploy an app on a remote host. And really, who gives a shit about "custom" vs "standardized" argument passing? And what's with the ghetto references? You do realize under the hood your Dockerfile and my 'ghetto script' are calling the same syscalls, making the same network connections, doing the same i/o, right? Who gives a shit if my 'script' is 'ghetto' if it's ten times more user accessible, portable and backwards compatible than your proprietary format? A developer isn't going to spend more than 5 minutes looking at what the assholes in ops have given them to do their job; they learn it, they use it, they move on with writing and testing their code. Docker doesn't improve anything or provide anything you couldn't already do before. It just creates a new niche. Your whole argument for the use of Docker seems to be "we are superior, because our operations are fancier, and we have created a gold standard." Face it: it doesn't matter how the sausage gets made. Docker just prescribes one way for how the meat is ground, vs all the others that work just as well.
  - jpetazzo 13y ago
    The Dockerfile provides caching. When you tweak a few things, you don't have to re-run the whole script, which is great if there are some expansive steps (e.g. downloading and installing Java, compiling a big library, etc.) Of course, you can achieve something similar with shell scripts, e.g. "if Java is not installed, install it, otherwise go to the next step". But if you get it wrong, or if there is some side-effect, the end result (after running the script multiple times) won't be exactly the same. The Dockerfile (with snapshots at each step) ensures consistency. It's not a big deal if you are a shell expert and write that kind of script for breakfast, but it's not the case for everyone :)