7 ms·

Example : this company had part of their site built by some abstruse static site generator with a million dependencies written in a language that no one at the

Example : this company had part of their site built by some abstruse static site generator with a million dependencies written in a language that no one at the company had installed by default, nor knew (I think it was Ruby). We put it all in Docker, and the README changed from 10 lines of install x, y, z version foo to /random, to just “run docker build, then docker run.” Most of the people working on those docs didn’t need to know about ruby or gems or lock files or any of that. A year later I overheard someone say thank god that thing was dockerized because I was absolutely not looking forward to installing all those dependencies just for a typo fix. That’s one of the areas where docker shines: app delivery.

simongr3dal 8y ago
I get that docker makes this simpler but it’s not really a feat only docker could accomplish, a makefile or bash script could have accomplished the same thing.
- johnchristopher 8y ago
  You could also move bits with a magnet over the circuits but it's more error prone /s.
- louiskottmann 8y ago
  A bash script would be nowhere near as practical. First of all it would be much more complicated to deal with various environments, and in practice, docker run/docker stop is much easier to upgrade.
- jarfil 8y ago
  A bash script would have to automatically install all the dependencies. Over time, there is a growing chance that some of the versions required will conflict with whatever is already installed on the machine, and someone will have to go in and fix them... then fix them in a way that it works on everybody's machines. With docker, you can just ignore all that. As long as there is a single person capable of updating the dependencies on a single machine with docker, it'll work the same everywhere, always.
- v_lisivka 8y ago
  If everybody in your team uses same distribution of Linux (say latest Fedora, for example), then all dependencies can be packaged into RPM or installed from system repository. RPM and docker are very similar in general idea: they are both image of result of installation of a program(RPM)/system(Docker). Every member of team will need to run same version of Fedora directly or in Vagrant or in (ta-da) docker container. From my experience, it turned out that for small Dockerfile's, RPM packages are unnecessary burden, so usually I just start with just docker. But later, when Dockerfile growths, it much harder to track dependencies and installation instructions, when they are interleaved, so it much easier to return to individually packaged programs and replace almost whole content of Dockerfile with single "dnf install meta-package" command.
bpizzi 8y ago
Or to say it differently: "that's one of the areas where interpreted languages' ecosystems stinks: app delivery".
- dbdjfjrjvebd 8y ago
  The OP says app delivery but they actually talk about development builds. Dev builds are another area where Docker/containerisation helps. Dev builds are just as annoying with Golang as Ruby or Python. In fact build awkwardness is orthogonal to static vs dynamic typing.
  - bpizzi 8y ago
    > Dev builds are just as annoying with Golang as Ruby or Python. Hm, I'm pretty sure I can take any Go project out there and build it in a matter of minutes on my current OS (depending on the build time of course). Just a matter of setting the environment on the right compiler binary and retrieving dependencies (which just came better 2 weeks ago with 1.11's modules). I'm pretty sure too I'll very quickly run into dependencies hell by picking randoms ruby/python programs. Just take a look at that SO question: https://stackoverflow.com/questions/2812471/is-there-a-python-equivalent-of-rubys-rvm https://stackoverflow.com/questions/2812471/is-there-a-pytho.... Interpreted languages have their uses, of course, but there's a clear difference in both ease of deployment and development between the realms of interpreted languages (Ruby/Python/PHP/etc.), VM/IL/JIT based languages (JVM/.NET/etc.) and 'plain old' compiler based languages (C/C++/Rust/Go/etc.). > In fact build awkwardness is orthogonal to static vs dynamic typing. I said "interpreted languages' ecosystems", not "dynamically typed languages". I think you're mixing concepts here (or just maybe you're adding info not directly related to my comment).
    - dbdjfjrjvebd 8y ago
      I can build any python project in 10 mimutes (and not pollute my global environment). I can't do that with Go or C or C++ or Ruby or php. I can if they are dockerised.
Fredej 8y ago
I'm also still not on the docker-wagon and would like to know what I'm missing out on. Most of my stuff is python. Why is docker better than virtualenv with a requirements.txt file? From this description it seems to solve the same issue. I could imagine something like environment variables, but on the other hand that's something I've learned not to keep in version control, and putting it in docker would be exactly that, no?
- cvakiitho 8y ago
  not every dependency is written in python.
- anyzen 8y ago
  > Why is docker better than virtualenv with a requirements.txt file? It's not, it solves a different issue. If you only have Python as dependency, requirements.txt are fine (well, user needs to install correct version of Python, pip and virtualenv / pipenv, but that's doable). But as soon as your app is actually composed of nginx / apache, python, some background process in Rust, bash scripts for cron jobs,... then you have a problem with app delivery, which Docker solves nicely. Just package eveything in a Dockerfile and distribute the image. Bonus point: you can now test it locally, with the same installation. I jumped on Docker wagon very early for this exact reason. I don't care about hype, but it does solve these kinds of problems.
  - deleted 8y ago
    [deleted]
- SteveLTN 8y ago
  > Why is docker better than virtualenv with a requirements.txt file? You can't put postgres, memcached, imagemagick in requirement.txt, can you?
- Ralfp 8y ago
  I'm also python dev and I'm embracing docker for delivering my app to users. > Why is docker better than virtualenv with a requirements.txt file One of issues that `docker-compose build` solves better is that venv is superconfusing to your non-python users. I've had people: - skip it and do `python setup.py install` instead - skip it and install requirements globally `pip install -r requirements.txt` because thats how it worked for them last time they used python - version control their `venv` directory - backup and upload their `venv` directory on new server when moving Now they just do `./appctl setup` that asks them for few things, writes `setup.env` file for docker-compose, and then runs `docker-compose build` But this is only beginning. Thanks to `docker-compose` that `build` step also installs: - PostgreSQL database - Redis for caching and message queue - UWSGI - Celery - Nginx proxy

simongr3dal 8y ago

I get that docker makes this simpler but it’s not really a feat only docker could accomplish, a makefile or bash script could have accomplished the same thing.

johnchristopher 8y ago
You could also move bits with a magnet over the circuits but it's more error prone /s.
louiskottmann 8y ago
A bash script would be nowhere near as practical. First of all it would be much more complicated to deal with various environments, and in practice, docker run/docker stop is much easier to upgrade.
jarfil 8y ago
A bash script would have to automatically install all the dependencies. Over time, there is a growing chance that some of the versions required will conflict with whatever is already installed on the machine, and someone will have to go in and fix them... then fix them in a way that it works on everybody's machines. With docker, you can just ignore all that. As long as there is a single person capable of updating the dependencies on a single machine with docker, it'll work the same everywhere, always.
v_lisivka 8y ago
If everybody in your team uses same distribution of Linux (say latest Fedora, for example), then all dependencies can be packaged into RPM or installed from system repository. RPM and docker are very similar in general idea: they are both image of result of installation of a program(RPM)/system(Docker). Every member of team will need to run same version of Fedora directly or in Vagrant or in (ta-da) docker container. From my experience, it turned out that for small Dockerfile's, RPM packages are unnecessary burden, so usually I just start with just docker. But later, when Dockerfile growths, it much harder to track dependencies and installation instructions, when they are interleaved, so it much easier to return to individually packaged programs and replace almost whole content of Dockerfile with single "dnf install meta-package" command.

bpizzi 8y ago

Or to say it differently: "that's one of the areas where interpreted languages' ecosystems stinks: app delivery".

dbdjfjrjvebd 8y ago
The OP says app delivery but they actually talk about development builds. Dev builds are another area where Docker/containerisation helps. Dev builds are just as annoying with Golang as Ruby or Python. In fact build awkwardness is orthogonal to static vs dynamic typing.
- bpizzi 8y ago
  > Dev builds are just as annoying with Golang as Ruby or Python. Hm, I'm pretty sure I can take any Go project out there and build it in a matter of minutes on my current OS (depending on the build time of course). Just a matter of setting the environment on the right compiler binary and retrieving dependencies (which just came better 2 weeks ago with 1.11's modules). I'm pretty sure too I'll very quickly run into dependencies hell by picking randoms ruby/python programs. Just take a look at that SO question: https://stackoverflow.com/questions/2812471/is-there-a-python-equivalent-of-rubys-rvm https://stackoverflow.com/questions/2812471/is-there-a-pytho.... Interpreted languages have their uses, of course, but there's a clear difference in both ease of deployment and development between the realms of interpreted languages (Ruby/Python/PHP/etc.), VM/IL/JIT based languages (JVM/.NET/etc.) and 'plain old' compiler based languages (C/C++/Rust/Go/etc.). > In fact build awkwardness is orthogonal to static vs dynamic typing. I said "interpreted languages' ecosystems", not "dynamically typed languages". I think you're mixing concepts here (or just maybe you're adding info not directly related to my comment).
  - dbdjfjrjvebd 8y ago
    I can build any python project in 10 mimutes (and not pollute my global environment). I can't do that with Go or C or C++ or Ruby or php. I can if they are dockerised.

Fredej 8y ago

I'm also still not on the docker-wagon and would like to know what I'm missing out on. Most of my stuff is python. Why is docker better than virtualenv with a requirements.txt file? From this description it seems to solve the same issue. I could imagine something like environment variables, but on the other hand that's something I've learned not to keep in version control, and putting it in docker would be exactly that, no?

cvakiitho 8y ago
not every dependency is written in python.
anyzen 8y ago
> Why is docker better than virtualenv with a requirements.txt file? It's not, it solves a different issue. If you only have Python as dependency, requirements.txt are fine (well, user needs to install correct version of Python, pip and virtualenv / pipenv, but that's doable). But as soon as your app is actually composed of nginx / apache, python, some background process in Rust, bash scripts for cron jobs,... then you have a problem with app delivery, which Docker solves nicely. Just package eveything in a Dockerfile and distribute the image. Bonus point: you can now test it locally, with the same installation. I jumped on Docker wagon very early for this exact reason. I don't care about hype, but it does solve these kinds of problems.
- deleted 8y ago
  [deleted]
SteveLTN 8y ago
> Why is docker better than virtualenv with a requirements.txt file? You can't put postgres, memcached, imagemagick in requirement.txt, can you?
Ralfp 8y ago
I'm also python dev and I'm embracing docker for delivering my app to users. > Why is docker better than virtualenv with a requirements.txt file One of issues that `docker-compose build` solves better is that venv is superconfusing to your non-python users. I've had people: - skip it and do `python setup.py install` instead - skip it and install requirements globally `pip install -r requirements.txt` because thats how it worked for them last time they used python - version control their `venv` directory - backup and upload their `venv` directory on new server when moving Now they just do `./appctl setup` that asks them for few things, writes `setup.env` file for docker-compose, and then runs `docker-compose build` But this is only beginning. Thanks to `docker-compose` that `build` step also installs: - PostgreSQL database - Redis for caching and message queue - UWSGI - Celery - Nginx proxy