8 ms·

I don't get docker... I get it for things of scale... but the everyday stuff ? Maybe i'm still old !

nothrabannosir 8y ago
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
vultour 8y ago
I like to keep my servers free of garbage. Installing bajillion dependencies for every application you run kind of violates that. Bonus points for Python module management.
cabraca 8y ago
containers keep all that junk away from my system. how many apps need node.js or ruby and stuff just to preprocess their css? ever managed some legacy php app? instead of putting that junk directly on my machine i just put it in a container. dont need it anymore? cool - docker rmi that shit
- johnchristopher 8y ago
  Yeah well maybe but some docker config file imply that you know how to configure the postgress, redis, node package manager, nginx and the SSL chain that live in the container by the means of a yaml config file that is in the end another custom layer of abstraction over the original config files. Of course some docker based projects are better than others.
hardwaresofton 8y ago
Remember that docker = lxd/lxc =~ bsd jails/solaris zones =~~ enhanced sandboxing/isolation for processes (containerization). When thinking about it that way, it's the pre-docker world that seems unnecessarily dangerous -- Why would you just let some random process run on your system with all it's dependencies and possibly cause havoc without containerizing it?
- zaarn 8y ago
  lxd/lxc containers are a tad more flexible than docker in my experience, notably because you tend to run a full distro in there instead of just a single app.
  - hardwaresofton 8y ago
    I agree -- I'm personally super excited to try my hand at using LXD[0] on Ubuntu, in particular I want to see just how awesome/well-isolated system images are. If everything I'm reading is right, lxd/lxc system containers are going to make running VMs seem outdated. Unfortunately it's a little bit annoying because the lxd docs don't make it easy to find what they define as a "system image" -- do you have some links to more more good layouts? I actually found a good talk from DebConf '17[1]. [0]: https://help.ubuntu.com/lts/serverguide/lxd.html https://help.ubuntu.com/lts/serverguide/lxd.html [1]: https://debconf17.debconf.org/talks/53/ https://debconf17.debconf.org/talks/53/
    - zaarn 8y ago
      I mostly rely on system images from Proxmox, they're fairly okayish to run even without PM. I still need VMs for some things, especially when the kernel of the host is too old or missing modules I need or when I need to mount things via FUSE (or similar ops).
jarfil 8y ago
You don't need docker to run a single program on a single computer... but the moment you either want to run multiple copies, or distribute it to multiple computers, particularly if they're not your computers, then being able to encapsulate stuff and reduce the number of dependencies is a huge benefit. For example, it lets you run software on your computer without worrying about installing stuff that might affect other software, and without even having any interactions with other software aside from what you allow it.
zmmmmm 8y ago
Old timer to old timer: it's how the rest of the computing ecosystem re-invented Java after it got uncool to use Java. Just slam all your dependencies into an image and it can run anywhere [-] [-] Until it has an external dependency and then it breaks, which is where docker turns out to be rather fragile by comparison.
- anyzen 8y ago
  Old timer to 2 other old timers: Docker does solve a problem, and this is quite close to it... We had a solution that we needed to install on servers for multiple clients. Before Docker, we had to make sure the libraries were correct (on CentOS, Debian, Ubuntu,... you name it), which was a nightmare. We were literally debugging on customers' installations to see why it broke there. Docker solves this nicely. Apart from the kernel you take all dependencies with you. In this case, it provides an easy installation of all the dependencies in a single command, while still allowing for customizations, and all in a standard way. Not to mention that certificates and similar are all solved. Forget about hype and just try Docker. It's a tool like any other. It can be abused, sure, but it's useful too and it's here to stay. EDIT: difference between Java and Docker is that containers depend on kernel capabilities, not on some 3rd party JAR maintainers. In my experience Docker simply works unless you are doing something really weird.
  - zmmmmm 8y ago
    I've been using Docker for lots of things. To be honest, the dependency part has been helpful but still weak: we inevitably end up finding that our containers are built from things that go stale (apt-get sources, pip, broken URLs, stale SSL certs, etc). I guess there is a skill to doing it well so that this doesn't happen, but there you are - it didn't really solve the problem it's now an extra skill we need to have to solve a problem we had already mostly solved. What has really sold me is more the orchestration side, with docker-compose allowing us to easily launch a whole fleet of independent services. I assume swarm and kubernetes etc., make this even better. It's really this that lets us decompose our software into finer grained independent components which has a number of other benefits. I don't think we could manage it otherwise.
davedx 8y ago
Another old timer here. I'm a front end dev, and at my latest contract I wanted to help out our back end developers with some .NET stuff. Can you imagine trying to setup a full .NET stack on a Macbook a few years ago? This time what I had to do was: * install Docker * install Visual Studio Community and .NET Core * run docker-compose ... up Then I had their entire .NET software stack up and running, including MSSQL, ElasticSearch, Kibana, redis, all with one command. I don't like doing DevOps personally, but I definitely appreciate how Docker helps me in situations like this!
ckocagil 8y ago
Have you used a Windows program that comes with all its dependencies (e.g dlls)? Have you used OS level isolation to deny some resources to some processes?
SteveLTN 8y ago
Docker is surely not for everyone. If you don't get why you want to use Docker, chances are you don't need it. Differently people use Docker differently, I see Docker could be useful for several purposes: 1) scalability This is the main advertisement point for Docker I guess. Well it enables your stateless application to scale automatically. 2) being able to deploy without caring about dependencies There are times we want to deploy something into customers' servers. We have no control over their machines' environments. But with Docker, the only thing I need to make sure is that they have it installed. 3) Infrastructure as code All our source code is checked in git and version controlled nicely. When we need to run it again, just clone from git. How nice! But our infrastructure, meaning server formation and service relationship? Not so much. Before using Docker, we basically need to ssh into servers and install dependencies according to the documents. It was not only slow, but unreliable because we all know how documents can lie. With Docker and docker-compose, the infrastructure can be written in code and checked in git. Most importantly, code doesn't lie. You can surely use other tools to achieve those. I'm not saying Docker is the only way. But I believe it's a good tool to consider when you have those needs.
- pvg 8y ago
  Before using Docker, we basically need to ssh into servers and install dependencies according to the documents. There's an entire cottage industry of not-docker tools for that. Not to take anything from docker but the options aren't 'docker' and 'the pre-docker dark ages where you ssh'ed into servers one by one and carefully typed commands from a faded printout'.
  - SteveLTN 8y ago
    Yes, I know. I just personally didn't learn to use Chef or Ansible, etc. back then. Now I use Ansible as well as Docker. Like it so far.
  - mmt 8y ago
    > There's an entire cottage industry of not-docker tools for that. Not the least of which are the distros own packaging systems (e.g. rpm/yum or dpkg/apt). Full investment in the complexity of the ecosystem isn't even necessary for basic dependency handling.
martin-adams 8y ago
I was like that and ignored Docker for a number of years. The app I'm working on has one database, one queue, one API server and one web front end. Some of these will scale when in production, but for eveloperment it's quite simple. I used to just run them at the command line and get on with development. But using docker has been an eye-opener. I can now get my front end developer to have a fully working database, queue, API server running with a simple `npm run docker`. They are free to develop the UI without having to worry about the underlying stack. I am free to change that stack without having to worry about telling them what commands to run on their laptop to get it up to date. As we add more services, such as email sending, image processing, video compression, it wont require anything special to configure from the front end perspective. We're now moving it into the cloud and are now seeing the benefits of Kubernetes with our docker containers to deploy, have a blue/green deployment, not worry so much about what the servers are doing but focusing on deployments. This is very clever stuff and will reduce our hosting cost without having to duplicate infrastructure. So yeah, I didn't get docker for a long time. It does depend on the types of apps your building though. My use case fits it perfectly.
locusm 8y ago
I wish lxc/lxd got more love. I think a machine container makes more sense for non scale stuff.
- stephenr 8y ago
  With 'built-in' imaging in LXD I think a lot of the use-cases LXC isn't quite as fluid for will become more realistic. (i.e. just download this image and run it) For local dev environments I still think Vagrant (and pick whatever underlying provider you want) is a better solution.
- unilynx 8y ago
  docker is basically a reproducible lxc/lxd, but you can get very close to actually running lxc-like machines with docker for me, docker actually solves the problem that lxc/openvz were trying to solve in a better way. we already had the data on separate volumes, and docker is a much nicer interface than bootstrapping and then updating a chroot for lxc
amaccuish 8y ago
Ye I don't use it for scale. It's great just to have a declarative file which is easy to read and understand. I guess I use it like people use Puppet and Ansible, I just find it better for my use case. And I don't always have to rely on what's in the package manager for my OS. So I get a nice stable core OS, and up to date apps.

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

vultour 8y ago

I like to keep my servers free of garbage. Installing bajillion dependencies for every application you run kind of violates that. Bonus points for Python module management.

cabraca 8y ago

containers keep all that junk away from my system. how many apps need node.js or ruby and stuff just to preprocess their css? ever managed some legacy php app? instead of putting that junk directly on my machine i just put it in a container. dont need it anymore? cool - docker rmi that shit

johnchristopher 8y ago
Yeah well maybe but some docker config file imply that you know how to configure the postgress, redis, node package manager, nginx and the SSL chain that live in the container by the means of a yaml config file that is in the end another custom layer of abstraction over the original config files. Of course some docker based projects are better than others.

hardwaresofton 8y ago

Remember that docker = lxd/lxc =~ bsd jails/solaris zones =~~ enhanced sandboxing/isolation for processes (containerization). When thinking about it that way, it's the pre-docker world that seems unnecessarily dangerous -- Why would you just let some random process run on your system with all it's dependencies and possibly cause havoc without containerizing it?

zaarn 8y ago
lxd/lxc containers are a tad more flexible than docker in my experience, notably because you tend to run a full distro in there instead of just a single app.
- hardwaresofton 8y ago
  I agree -- I'm personally super excited to try my hand at using LXD[0] on Ubuntu, in particular I want to see just how awesome/well-isolated system images are. If everything I'm reading is right, lxd/lxc system containers are going to make running VMs seem outdated. Unfortunately it's a little bit annoying because the lxd docs don't make it easy to find what they define as a "system image" -- do you have some links to more more good layouts? I actually found a good talk from DebConf '17[1]. [0]: https://help.ubuntu.com/lts/serverguide/lxd.html https://help.ubuntu.com/lts/serverguide/lxd.html [1]: https://debconf17.debconf.org/talks/53/ https://debconf17.debconf.org/talks/53/
  - zaarn 8y ago
    I mostly rely on system images from Proxmox, they're fairly okayish to run even without PM. I still need VMs for some things, especially when the kernel of the host is too old or missing modules I need or when I need to mount things via FUSE (or similar ops).

jarfil 8y ago

You don't need docker to run a single program on a single computer... but the moment you either want to run multiple copies, or distribute it to multiple computers, particularly if they're not your computers, then being able to encapsulate stuff and reduce the number of dependencies is a huge benefit. For example, it lets you run software on your computer without worrying about installing stuff that might affect other software, and without even having any interactions with other software aside from what you allow it.

zmmmmm 8y ago

Old timer to old timer: it's how the rest of the computing ecosystem re-invented Java after it got uncool to use Java. Just slam all your dependencies into an image and it can run anywhere [-] [-] Until it has an external dependency and then it breaks, which is where docker turns out to be rather fragile by comparison.

anyzen 8y ago
Old timer to 2 other old timers: Docker does solve a problem, and this is quite close to it... We had a solution that we needed to install on servers for multiple clients. Before Docker, we had to make sure the libraries were correct (on CentOS, Debian, Ubuntu,... you name it), which was a nightmare. We were literally debugging on customers' installations to see why it broke there. Docker solves this nicely. Apart from the kernel you take all dependencies with you. In this case, it provides an easy installation of all the dependencies in a single command, while still allowing for customizations, and all in a standard way. Not to mention that certificates and similar are all solved. Forget about hype and just try Docker. It's a tool like any other. It can be abused, sure, but it's useful too and it's here to stay. EDIT: difference between Java and Docker is that containers depend on kernel capabilities, not on some 3rd party JAR maintainers. In my experience Docker simply works unless you are doing something really weird.
- zmmmmm 8y ago
  I've been using Docker for lots of things. To be honest, the dependency part has been helpful but still weak: we inevitably end up finding that our containers are built from things that go stale (apt-get sources, pip, broken URLs, stale SSL certs, etc). I guess there is a skill to doing it well so that this doesn't happen, but there you are - it didn't really solve the problem it's now an extra skill we need to have to solve a problem we had already mostly solved. What has really sold me is more the orchestration side, with docker-compose allowing us to easily launch a whole fleet of independent services. I assume swarm and kubernetes etc., make this even better. It's really this that lets us decompose our software into finer grained independent components which has a number of other benefits. I don't think we could manage it otherwise.

davedx 8y ago

Another old timer here. I'm a front end dev, and at my latest contract I wanted to help out our back end developers with some .NET stuff. Can you imagine trying to setup a full .NET stack on a Macbook a few years ago? This time what I had to do was: * install Docker * install Visual Studio Community and .NET Core * run docker-compose ... up Then I had their entire .NET software stack up and running, including MSSQL, ElasticSearch, Kibana, redis, all with one command. I don't like doing DevOps personally, but I definitely appreciate how Docker helps me in situations like this!

ckocagil 8y ago

Have you used a Windows program that comes with all its dependencies (e.g dlls)? Have you used OS level isolation to deny some resources to some processes?

SteveLTN 8y ago

Docker is surely not for everyone. If you don't get why you want to use Docker, chances are you don't need it. Differently people use Docker differently, I see Docker could be useful for several purposes: 1) scalability This is the main advertisement point for Docker I guess. Well it enables your stateless application to scale automatically. 2) being able to deploy without caring about dependencies There are times we want to deploy something into customers' servers. We have no control over their machines' environments. But with Docker, the only thing I need to make sure is that they have it installed. 3) Infrastructure as code All our source code is checked in git and version controlled nicely. When we need to run it again, just clone from git. How nice! But our infrastructure, meaning server formation and service relationship? Not so much. Before using Docker, we basically need to ssh into servers and install dependencies according to the documents. It was not only slow, but unreliable because we all know how documents can lie. With Docker and docker-compose, the infrastructure can be written in code and checked in git. Most importantly, code doesn't lie. You can surely use other tools to achieve those. I'm not saying Docker is the only way. But I believe it's a good tool to consider when you have those needs.

pvg 8y ago
Before using Docker, we basically need to ssh into servers and install dependencies according to the documents. There's an entire cottage industry of not-docker tools for that. Not to take anything from docker but the options aren't 'docker' and 'the pre-docker dark ages where you ssh'ed into servers one by one and carefully typed commands from a faded printout'.
- SteveLTN 8y ago
  Yes, I know. I just personally didn't learn to use Chef or Ansible, etc. back then. Now I use Ansible as well as Docker. Like it so far.
- mmt 8y ago
  > There's an entire cottage industry of not-docker tools for that. Not the least of which are the distros own packaging systems (e.g. rpm/yum or dpkg/apt). Full investment in the complexity of the ecosystem isn't even necessary for basic dependency handling.

martin-adams 8y ago

I was like that and ignored Docker for a number of years. The app I'm working on has one database, one queue, one API server and one web front end. Some of these will scale when in production, but for eveloperment it's quite simple. I used to just run them at the command line and get on with development. But using docker has been an eye-opener. I can now get my front end developer to have a fully working database, queue, API server running with a simple `npm run docker`. They are free to develop the UI without having to worry about the underlying stack. I am free to change that stack without having to worry about telling them what commands to run on their laptop to get it up to date. As we add more services, such as email sending, image processing, video compression, it wont require anything special to configure from the front end perspective. We're now moving it into the cloud and are now seeing the benefits of Kubernetes with our docker containers to deploy, have a blue/green deployment, not worry so much about what the servers are doing but focusing on deployments. This is very clever stuff and will reduce our hosting cost without having to duplicate infrastructure. So yeah, I didn't get docker for a long time. It does depend on the types of apps your building though. My use case fits it perfectly.

locusm 8y ago

I wish lxc/lxd got more love. I think a machine container makes more sense for non scale stuff.

stephenr 8y ago
With 'built-in' imaging in LXD I think a lot of the use-cases LXC isn't quite as fluid for will become more realistic. (i.e. just download this image and run it) For local dev environments I still think Vagrant (and pick whatever underlying provider you want) is a better solution.
unilynx 8y ago
docker is basically a reproducible lxc/lxd, but you can get very close to actually running lxc-like machines with docker for me, docker actually solves the problem that lxc/openvz were trying to solve in a better way. we already had the data on separate volumes, and docker is a much nicer interface than bootstrapping and then updating a chroot for lxc

amaccuish 8y ago

Ye I don't use it for scale. It's great just to have a declarative file which is easy to read and understand. I guess I use it like people use Puppet and Ansible, I just find it better for my use case. And I don't always have to rely on what's in the package manager for my OS. So I get a nice stable core OS, and up to date apps.