4 ms·

well as somebody already pointed out. docker/containers are useless. combine them with a useful system like kubernetes, they can be really useful.

by merb 9y ago

mschuster91 9y ago
> docker/containers are useless. combine them with a useful system like kubernetes, they can be really useful. Not exactly. For example, running your core infrastructure via Docker containers makes "ordinary" maintenance/disaster recovery really easy. We run e.g. JIRA and Confluence in Docker... and it's a breeze to make a consistent backup and restore: stop the application and DB container, rsync delta to Netapp, restart the containers and the Netapp automatically does a snapshot. Daily, fully consistent backups with only 5 minutes of downtime - and because a restoration is as easy as "rsync the data out of the Netapp/LTO and do a (documented) docker run command with appropriate mounts" it's easy to verify that the backup actually works. Prior to using Docker, testing the backup involved setting up a server, copying data around and manually importing it. Needless to say it was not done very often. But now we can apply this policy to all our services, plus we can test version upgrades with minimal effort compared to setting up the software from scratch. Oh, and upgrading the software versions itself is also easy: rsync delta to backup, stop container, quick rsync again to ensure consistency (e.g. lock files, not flushed DB writes), stop & remove old docker container, run new docker container w/ new version, check if upgrade went OK - which it always did so far, but in case it did not, it's a matter of minutes to do a full rollback. The downside, of course, is that we depend on the container author(s) to provide regular new builds which incorporate not only new app versions but also updates for the packages of the "OS" inside the container. For example if the thread vector is something like "PHP/Java does a RCE when passed a certain HTTP header", on an "old school" system I'd do an apt-get update && apt-get upgrade and that's it - with Docker I either depend on the container vendor or have to roll my own docker images with e.g. "FROM <vendorimage>; RUN apt-get update && apt-get dist-upgrade && apt-cache clean"...
eikenberry 9y ago
100% wrong. Containers normalize deployment making the underlying tech stack irrelevant. This is their first and still primary use and they work really well for this. There is nothing wrong with 1 container per system, just like you used to do with standard deployment.
currymj 9y ago
i don't know about "useless". scientific computing, for instance -- you may have a weird set of dependencies for some code that you want to deploy a copy of on 200 slightly heterogeneous nodes, once, and hopefully never again; but, it's vitally important that people in the future have the possibility of replicating your computation. containers are the perfect solution for this. in fact, in my experience they essentially do fix a broken culture around reproducibility of computational experiments.
- deleted 9y ago
  [deleted]
rowyourboat 9y ago
We used them in a web agency that has lots of different projects running on different stacks, and we have to go back to old projects from time to time. Having your dependencies, version, setup and even build tools all referenced in a compose file made it really easy and quick to switch projects or get a new developer set up. Simply git clone, docker-compose up and voilà. No more messing around with installing different and conflicting dependencies on the same machine, and much faster, easier and more stable than the vagrant/ansible-combo we used before that.

well as somebody already pointed out. docker/containers are useless. combine them with a useful system like kubernetes, they can be really useful.

by merb 9y ago

well as somebody already pointed out. docker/containers are useless. combine them with a useful system like kubernetes, they can be really useful.

mschuster91 9y ago

> docker/containers are useless. combine them with a useful system like kubernetes, they can be really useful. Not exactly. For example, running your core infrastructure via Docker containers makes "ordinary" maintenance/disaster recovery really easy. We run e.g. JIRA and Confluence in Docker... and it's a breeze to make a consistent backup and restore: stop the application and DB container, rsync delta to Netapp, restart the containers and the Netapp automatically does a snapshot. Daily, fully consistent backups with only 5 minutes of downtime - and because a restoration is as easy as "rsync the data out of the Netapp/LTO and do a (documented) docker run command with appropriate mounts" it's easy to verify that the backup actually works. Prior to using Docker, testing the backup involved setting up a server, copying data around and manually importing it. Needless to say it was not done very often. But now we can apply this policy to all our services, plus we can test version upgrades with minimal effort compared to setting up the software from scratch. Oh, and upgrading the software versions itself is also easy: rsync delta to backup, stop container, quick rsync again to ensure consistency (e.g. lock files, not flushed DB writes), stop & remove old docker container, run new docker container w/ new version, check if upgrade went OK - which it always did so far, but in case it did not, it's a matter of minutes to do a full rollback. The downside, of course, is that we depend on the container author(s) to provide regular new builds which incorporate not only new app versions but also updates for the packages of the "OS" inside the container. For example if the thread vector is something like "PHP/Java does a RCE when passed a certain HTTP header", on an "old school" system I'd do an apt-get update && apt-get upgrade and that's it - with Docker I either depend on the container vendor or have to roll my own docker images with e.g. "FROM <vendorimage>; RUN apt-get update && apt-get dist-upgrade && apt-cache clean"...

eikenberry 9y ago

100% wrong. Containers normalize deployment making the underlying tech stack irrelevant. This is their first and still primary use and they work really well for this. There is nothing wrong with 1 container per system, just like you used to do with standard deployment.

currymj 9y ago

i don't know about "useless". scientific computing, for instance -- you may have a weird set of dependencies for some code that you want to deploy a copy of on 200 slightly heterogeneous nodes, once, and hopefully never again; but, it's vitally important that people in the future have the possibility of replicating your computation. containers are the perfect solution for this. in fact, in my experience they essentially do fix a broken culture around reproducibility of computational experiments.

deleted 9y ago
[deleted]

rowyourboat 9y ago

We used them in a web agency that has lots of different projects running on different stacks, and we have to go back to old projects from time to time. Having your dependencies, version, setup and even build tools all referenced in a compose file made it really easy and quick to switch projects or get a new developer set up. Simply git clone, docker-compose up and voilà. No more messing around with installing different and conflicting dependencies on the same machine, and much faster, easier and more stable than the vagrant/ansible-combo we used before that.