8 ms·

Docker, Containers, and the Future of Application Delivery

143 points by bdon 13y ago

tlrobinson 13y ago
Today I found out about a similar-ish project called TestLab, "A toolkit for building virtual computer labs" https://github.com/zpatten/testlab https://github.com/zpatten/testlab
jwheeler79 13y ago
I still don't get it.
- general_failure 13y ago
  Same here. Why can't people talk with concrete examples instead of this high level vague stuff. This thing is for do devs - explain it like so. The analogies are pointless, they don't convey anything to me.
  - nickstinemates 13y ago
    All I can do is point to my real, practical experience in using Docker. http://tryrethink.info http://tryrethink.info - over 3,000 happy customers (unique, sandboxed instances) served in 24 hours. With about a day of effort total. http://nick.stinemat.es http://nick.stinemat.es - my blog, which is pretty Docker focused because that's what I've been working on since I decided to start improving writing. This covers basic continuous integration and deployment of an application to pretty non-trivial volume.
    - jwheeler79 13y ago
      Would you say it's one of those things you feel the warm fuzzy feeling with after using it? I've been wanting to give it a try with all the hype surrounding it, but I don't see what it's going to do that provisioning a $10 Digital Ocean server wouldn't (albeit with a little bit of hassle).
      - nickstinemates 13y ago
        I could literally type for days about the benefits of docker over a $10 digital ocean server, but no one would read it. What I will say is this. If you're writing a trivial application that you and only you will ever need to work with, in an environment completely controlled by you, and you have a recipe that works - you're right, Docker probably isn't for you. If you, like me, work with a huge product suite with many buildtime and runtime dependencies (services and applications), with many different runtime configurations, where even automated installation can take up to 15-20 minutes because of the sheer amount of work that's going on, there's a massive massive amount of efficiency to be gained in the dev/test/release/packaging process, let alone the massive amount of efficiency to be gained by the ops team in working in foreign environments. There are certainly lots of other use cases (PaaS/SaaS are easy,) and those are valuable business building tools, but less interesting to me personally.
        pbsdp 13y ago
        I'd your architecture is that complicated, you might be architecting your systems poorly.
      - sthatipamala 13y ago
        Docker and Digital Ocean servers are different things that can be used together. Docker allows you to distribute applications that come bundled with their own OS-level packages/configuration. Imagine you wanted to run Wordpress on your DO server. Instead of configuring a LAMP stack and setting up Wordpress on it, you could download and run a Wordpress docker container that came bundled with its own LAMP stack. It would be as simple for you as calling "docker run wordpress".Most importantly, its configuration would be completely isolated from that of the host machine.
        ninetax 13y ago
        But that's not quite true is it? You would still have to open up ports on your host, configure security, and somehow do the meta-config for the dockerfile to make sure that if the host goes down, `docker run wordpress` is called on startup right? I really want to get excited about docker, but I guess I just don't understand it. Any links to more specific use cases?
  - recuter 13y ago
    http://en.wikipedia.org/wiki/Dependency_hell http://en.wikipedia.org/wiki/Dependency_hell Stuff like apt-get works great until it doesn't. You've run into this no doubt. Jails/LXC abstract dependencies away in an attempt to avoid this class of problems. In other words: this helps to avoid mutating your system state with every command you run from the shell. :)
  - derefr 13y ago
    Imagine if these were real commands: $ docker download-install-and-run-my-customized-build-of-postgres $ docker start-up-a-wordpress-instance-from-some-online-build-template $ # edit some config files, add some plugins $ docker pack-that-wordpress-instance-into-a-container $ ansible all -a docker download-and-run-your-wordpress-instance-on-all-your-app-nodes That's basically what docker does; the syntax is only slightly more mundane, and is actually less verbose than that.
jacques_chester 13y ago
I feel like the long-term architectural implications of virtual machines and now containers haven't quite sunk in. I'm not talking about the administrative advantages, which I think everyone is across these days. I mean the implications for the design of new applications. As far as I am aware, folk aren't really writing distributable applications that target the VM up. You can get preconfigured stacks, or you can get standalone apps that you install in your environment. But nobody's said: "Hey, if we control the app design from the OS up, we can make it much more intelligent, robust and at the same time sweep away a lot of unnecessary inner platform nonsense". In terms of the slides, my approach is to reduce the NxN matrix by eliminating a lot of the choices. Why write your blog engine to support 5 different web servers when you can select and bundle the web server? Repeat for other components. It gets better. Why write a thin, poorly-featured database abstraction layer when you can take serious advantages of a particular database's features? You can't do this if you write under old shared-hosting assumptions. You can do this if you target the VM or container as the unit of design and deployment. Yes, this is one of my bonnet-bees, since at least 2008: http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed-and-i-have-the-graphs-to-prove-it/ http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed...
- beachstartup 13y ago
  i think what you're saying is, eventally, OS/kernel/root gets folded into the "application" context.
  - jacques_chester 13y ago
    Yep. Back when I was preparing to take an honours year, I wrote an circulated several project proposals. One was to explore the argument above with a constructive project -- writing a blog[1]. An example I gave for the inner platform effect was the Wordpress file wp-cron.php. It gets called on every request made to Worpdress because WP has no other way to arrange for scheduled tasks to be carried out. So you get a performance hit and your scheduling relies on stochastic sampling. Oh, and it stops working very well when (as inevitably happens) you slather Wordpress with caching. In an OS-up design, you just delegate this to cron. Or plugins. In a standard current design, these can't be isolated. In an OS-up design, you can can make them standalone programs with separate accounts that can't reach into and interfere with the core code. No more broken sites from a PHP error in a hastily-installed plugin. Similarly, you can control their access into the database (instead of having a shared login that all code running in the application shares). And so on, and so forth. [1] I'm happy to forward copies of the proposal. My email is in my profile.
secstate 13y ago
I lover docker as much as the next pseudo-sysadmin (dev forced to do admin work), but I think the analogy with packing containers is a bit of a stretch. LXC works only on Linux. It's not gonna help you with BSDs, OpenSolaris or Windows. Additionally, a lot of this feels like Docker is taking credit for LXC. Docker is a brilliant abstraction of LXC's obscure native interface, but LXC came before Docker and does most of the heavy lifting.
- stfp 13y ago
  To your second point - I think you're right, but I think that pattern - the productization of existing technology - is a very powerful, positive thing. And picking the right abstraction, so that it feels - as you put it - brilliant (a view I share totally), is not trivial. Also FWIW, on giving credit: https://twitter.com/getdocker/status/357983297114079233 https://twitter.com/getdocker/status/357983297114079233
  - secstate 13y ago
    For sure, I didn't mean to downplay how important tools like Docker are, just that it may not be as revolutionary as the shipping container. I think some other comments above make a better argument about how the full power of containers has yet to be realized.
- icebraining 13y ago
  As far as I now, the idea is that Docker won't be tied to LXC, but able to use different container technologies, like jails and zones.
Aqueous 13y ago
It'd be nice to get a suitable cross-platform container format, that would let you create a deployable container across multiple OSes. Process control groups exist in Darwin/Mac OS X - I wish you could sandbox packages with private network namespaces and filesystems as well.
- est 13y ago
  I don't understand, binary/lib usually doesn't share across platforms.
  - Aqueous 13y ago
    Right. You could have a container which has universal dylibs and static libs for x86_64/i386 compiled for Darwin in one directory and ELF shared objects and static libraries compiled for x86_64/i386 for Linux, logic to detect the platform and the main application binaries compiled for multiple platforms. And why not throw Windows in there too? This would create a universal container, assuming all major OSes acquire facilities for process control groups, namespaces and chroot. Disk space is no longer a consideration. The containers can be as big as we want - why not make them run natively everywhere?
    - vidarh 13y ago
      Why bother? I'd be far simpler, and more resource efficient, to run whatever the user prefers of Xen/Virtualbox/Vmware or "bare" Linux as the base and not have to create monstrous franken-containers.
      - Aqueous 13y ago
        Well, speaking from personal experience, I develop on Mac OS X and deploy to Linux. It would be helpful to be able to run the same container on both for testing purposes.
- justincormack 13y ago
  cgroup type interfaces are not very portable, havent really looked at the interfaces. You could use a tun/tap interface and a userspace network stack (eg NetBSD rump kernel is portable).
jwilliams 13y ago
I like Docker and I use it in dev/sandpit quite a bit lately... but I must admit, I don't quite follow the metaphor being pushed here. Standard workloads don't require containers. You can have standard workloads on your physical or virtualised hardware. The choice between these is going to depend on a bunch of factors. I don't see why they need to be bound together, as appears to be the case with Docker? Plus I don't see how that provides any special leverage (as opposed to having the choice).
- mateuszf 13y ago
  It has great advantages by doing it this way. 1. For developer: - your application works exactly the same way on your development, test and production environment because of using exactly the same os/libs/configuration - very fast snapshot/restore simplifies automatic tests and makes them practical 2. For system admin: - configure your system once in order to make docker work, run any docker image (program) with one, the same command - run many applications which do not influence each other in a quite safe way - download and run application without worrying about its dependencies - very low footprint in terms of disk/memory/cpu usage in comparison with standard virtualization
  - jwilliams 13y ago
    1. Agree that's handy in dev. For development a container is probably a good choice - in other environments virtualization or physical hardware may make sense. "More consistent" dev/test/prod is great, but I don't need nor want identical. My needs in dev are different from production - e.g. Everything from basic settings, URLs, networking, reloading behaviour to performance tuning. My needs for my dev DB are quite different from those in production. 2. Agree, but this isn't unique to containers (which is probably what I was aiming at). Low footprint is somewhat irrelevant to "configure once". You can manage this on physical hardware if needs be. Low footprint is great when you're resource constrained, somewhat irrelevant at scale. Plus a VM gives you other features/tradeoffs in return for that cost. Different circumstances will tend to favour one over the other. I find Docker useful. Containers and Standardised Workloads are great. I see the utility in both, my argument is I see them as orthogonal. Particularly referring to the "alternatives" at the end of the deck, which seemed unnecessary distinctions for me.
kraemate 13y ago
I dont get the hype. BSD and Solaris have had proper containers for years now. Just because Linux hasn't had any all these years and LXC is maturing only now, it is wrong to think that containers are the next big thing.
- icebraining 13y ago
  Linux has had containers for years, they're called "OpenVZ". But Docker is not a container technology, it's an API over those.
  - zurn 13y ago
    Not in stock Linux - OpenVZ has been a bit like Xen that way, requiring a custom kernel. Which for most people means a dedicated host machine is needed.
    - darkarmani 13y ago
      I'm not sure what you mean by dedicated host machine, because OpenVZ runs on Amazon and Azure instances.
- FooBarWidget 13y ago
  I also think it's strange. FreeBSD jails are essentially the same thing. When I describe Docker, I would call it "FreeBSD jails for Linux" rather than "lightweight virtual machine" or even "iPhone apps-style isolation". But I do get the hype. BSD and Solaris, although they have many interesting benefits, just aren't that popular for a variety of reasons. I won't turn this into a discussion of why they aren't popular, but it's a fact that Linux is much more popular. Most people aren't going to switch even if BSD and Solaris provide more benefits. But now that an important feature has become available for Linux, I can see why people get excited. It's like Node.js. Servers with evented I/O has exited for years, if not decades. But the fact that Node.js is Javascript made it mainstream and that's why there's hype.
  - justincormack 13y ago
GoNB 13y ago
Unrelated: Why are people familiar with Hacker News (e.g. the Docker folks) still using slideshare.net? That site feels like it's stuck around 2005. I thought everyone here knew about http://slid.es http://slid.es by now -- its UX is far superior.
- plainOldText 13y ago
  I think http://speakerdeck.com/ http://speakerdeck.com/ is even better. IMO the UI is very cool and the entire site very easy to navigate; I actually find it hard to believe it's not a very popular slides sharing platform.
  - ludwigvan 13y ago
    Weird, isn't it? Especially considering it was acquired by Github, where almost anyone here has an account. Maybe Github is not advertising it enough.
m_mueller 13y ago
There is one fallacy here: The 'thin' mobile client as being the future. Even though the world has moved towards thin client in the form of web clients, I firmly believe that the tides will turn - either by having the browser becoming a thick client itself (with local storage, lots of local logic) or by reintroducing native clients again - for which Containerization could play an essential role. Imagine if we'd have a standardized container format on top of Linux, the BSDs including OSX and Windows with Cygwin - hello cross platform client applications with a single installer. Apple and Microsoft could integrate container technology in their AppStores and we could submit the same package everywhere.
- kstaken 13y ago
  The browser is already a thick client with local storage and lots of local logic. The difference is that the entire client is shipped to the browser on demand.
  - m_mueller 13y ago
    Ok, that's an interesting point. I'd argue that local storage hasn't really taken hold yet, i.e. the large majority of sites and apps don't work offline, but yeah, it already stretches the notion of a thin client (hence my beef about using this term on where we're headed in the future).
ballard 13y ago
Enterprise people have already moved in on this with opaque application volumes. NDA's so don't bother asking for detail.
eterm 13y ago
About a minute after loading this website a setup.exe downloaded which my antivirus promptly found and got rid of. Anyone else experience this?
boothead 13y ago
I think docker or similar is a great step forward... One question in my mind though: what about the databases? Say you have a web app and a reporting app that use the same database (and probably a communications framework - zmq server rabbitmq etc in the middle there as well). How does docker deal with the following: * The data? I can see postgres, redis or whatever being packaged up into containers, but what about the data that they use? Will there be attachable storage? Will you share some exposed resource on the host? Will the data be another container on top of the database app container? * Routing. How do you tell your reporting/web app containers "this is where your message bus and database live?" * Coordination. I'm used to using something like supervisord to control my processes - what's the equivalent in docker land? Replace the scripts in supervisord with the equivalent dockerized apps? A docker file for the host specifying what to run? How do you know if your app that you've run inside docker has crashed? * Or do you just package the whole lot above up into one container? edit actually that was more than one :-)
- vidarh 13y ago
  > * Coordination. I'm used to using something like supervisord to control my processes - what's the equivalent in docker land? The question doesn't really make sense: The equivalent is supervisord running inside the lxc container. > * Routing. How do you tell your reporting/web app containers "this is where your message bus and database live?" How do you tell them in a cluster? This is a problem anyone who's ever needed to scale a system beyond a single server has already had to deal with, whether or not the application is package up a container, and there's a plethora of solutions, ranging from hardcoding it in config files, to LDAP or DNS based approaches, to things like Zookeeper or Doozer, to keeping all the config data in a database server (and hardcoding the dsn for that), to rsyncing files with all the config data to all the servers, and lots more.
  - johnbellone 13y ago
    I'm not sure there's going to be a bullet-proof solution to this. I believe that Docker is the right step forward, especially for the application containers. What I have been tinkering with is the idea of having smaller, configurable pieces of infrastructure and then providing a simple tool on top of that (e.g. 'heroku' CLI). Once you are past the procurement and provisioning steps you really need a way to describe how to wire everything together. I definitely haven't solved it yet but I sure hope to! :)
dschiptsov 13y ago
over-hyped FreeBSD's jails?)
- kstaken 13y ago
  Yep, jails, containers, solaris zones all the way back to IBM mainframes have been similar core technologies. Docker it self isn't containerization, Docker builds on Linux containers but adds a layer to dramatically simplify the build, distribution and execution of containers and that's what makes it game changing. docker run gtihub.com/some/project That command will clone, build and execute a container based on the contents of a repository by simply dropping a Dockerfile in the root of the project. That's a fundamentally different level of usage beyond any existing container technology.
megaman821 13y ago
How does Docker handle deploying to machines with wildly varying capabilities? Every machine you deploy on may have different configurations and performance tunings. Is there a Docker container that can run a DB well on a EC2 small instance and 16 core 128GB RAM dedicated server?

143 points by bdon 13y ago

Today I found out about a similar-ish project called TestLab, "A toolkit for building virtual computer labs" https://github.com/zpatten/testlab https://github.com/zpatten/testlab

jwheeler79 13y ago

I still don't get it.

general_failure 13y ago
Same here. Why can't people talk with concrete examples instead of this high level vague stuff. This thing is for do devs - explain it like so. The analogies are pointless, they don't convey anything to me.
- nickstinemates 13y ago
  All I can do is point to my real, practical experience in using Docker. http://tryrethink.info http://tryrethink.info - over 3,000 happy customers (unique, sandboxed instances) served in 24 hours. With about a day of effort total. http://nick.stinemat.es http://nick.stinemat.es - my blog, which is pretty Docker focused because that's what I've been working on since I decided to start improving writing. This covers basic continuous integration and deployment of an application to pretty non-trivial volume.
  - jwheeler79 13y ago
    Would you say it's one of those things you feel the warm fuzzy feeling with after using it? I've been wanting to give it a try with all the hype surrounding it, but I don't see what it's going to do that provisioning a $10 Digital Ocean server wouldn't (albeit with a little bit of hassle).
    - nickstinemates 13y ago
      I could literally type for days about the benefits of docker over a $10 digital ocean server, but no one would read it. What I will say is this. If you're writing a trivial application that you and only you will ever need to work with, in an environment completely controlled by you, and you have a recipe that works - you're right, Docker probably isn't for you. If you, like me, work with a huge product suite with many buildtime and runtime dependencies (services and applications), with many different runtime configurations, where even automated installation can take up to 15-20 minutes because of the sheer amount of work that's going on, there's a massive massive amount of efficiency to be gained in the dev/test/release/packaging process, let alone the massive amount of efficiency to be gained by the ops team in working in foreign environments. There are certainly lots of other use cases (PaaS/SaaS are easy,) and those are valuable business building tools, but less interesting to me personally.
      - pbsdp 13y ago
        I'd your architecture is that complicated, you might be architecting your systems poorly.
    - sthatipamala 13y ago
      Docker and Digital Ocean servers are different things that can be used together. Docker allows you to distribute applications that come bundled with their own OS-level packages/configuration. Imagine you wanted to run Wordpress on your DO server. Instead of configuring a LAMP stack and setting up Wordpress on it, you could download and run a Wordpress docker container that came bundled with its own LAMP stack. It would be as simple for you as calling "docker run wordpress".Most importantly, its configuration would be completely isolated from that of the host machine.
      - ninetax 13y ago
        But that's not quite true is it? You would still have to open up ports on your host, configure security, and somehow do the meta-config for the dockerfile to make sure that if the host goes down, `docker run wordpress` is called on startup right? I really want to get excited about docker, but I guess I just don't understand it. Any links to more specific use cases?
- recuter 13y ago
  http://en.wikipedia.org/wiki/Dependency_hell http://en.wikipedia.org/wiki/Dependency_hell Stuff like apt-get works great until it doesn't. You've run into this no doubt. Jails/LXC abstract dependencies away in an attempt to avoid this class of problems. In other words: this helps to avoid mutating your system state with every command you run from the shell. :)
- derefr 13y ago
  Imagine if these were real commands: $ docker download-install-and-run-my-customized-build-of-postgres $ docker start-up-a-wordpress-instance-from-some-online-build-template $ # edit some config files, add some plugins $ docker pack-that-wordpress-instance-into-a-container $ ansible all -a docker download-and-run-your-wordpress-instance-on-all-your-app-nodes That's basically what docker does; the syntax is only slightly more mundane, and is actually less verbose than that.

jacques_chester 13y ago

I feel like the long-term architectural implications of virtual machines and now containers haven't quite sunk in. I'm not talking about the administrative advantages, which I think everyone is across these days. I mean the implications for the design of new applications. As far as I am aware, folk aren't really writing distributable applications that target the VM up. You can get preconfigured stacks, or you can get standalone apps that you install in your environment. But nobody's said: "Hey, if we control the app design from the OS up, we can make it much more intelligent, robust and at the same time sweep away a lot of unnecessary inner platform nonsense". In terms of the slides, my approach is to reduce the NxN matrix by eliminating a lot of the choices. Why write your blog engine to support 5 different web servers when you can select and bundle the web server? Repeat for other components. It gets better. Why write a thin, poorly-featured database abstraction layer when you can take serious advantages of a particular database's features? You can't do this if you write under old shared-hosting assumptions. You can do this if you target the VM or container as the unit of design and deployment. Yes, this is one of my bonnet-bees, since at least 2008: http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed-and-i-have-the-graphs-to-prove-it/ http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed...

beachstartup 13y ago
i think what you're saying is, eventally, OS/kernel/root gets folded into the "application" context.
- jacques_chester 13y ago
  Yep. Back when I was preparing to take an honours year, I wrote an circulated several project proposals. One was to explore the argument above with a constructive project -- writing a blog[1]. An example I gave for the inner platform effect was the Wordpress file wp-cron.php. It gets called on every request made to Worpdress because WP has no other way to arrange for scheduled tasks to be carried out. So you get a performance hit and your scheduling relies on stochastic sampling. Oh, and it stops working very well when (as inevitably happens) you slather Wordpress with caching. In an OS-up design, you just delegate this to cron. Or plugins. In a standard current design, these can't be isolated. In an OS-up design, you can can make them standalone programs with separate accounts that can't reach into and interfere with the core code. No more broken sites from a PHP error in a hastily-installed plugin. Similarly, you can control their access into the database (instead of having a shared login that all code running in the application shares). And so on, and so forth. [1] I'm happy to forward copies of the proposal. My email is in my profile.

secstate 13y ago

I lover docker as much as the next pseudo-sysadmin (dev forced to do admin work), but I think the analogy with packing containers is a bit of a stretch. LXC works only on Linux. It's not gonna help you with BSDs, OpenSolaris or Windows. Additionally, a lot of this feels like Docker is taking credit for LXC. Docker is a brilliant abstraction of LXC's obscure native interface, but LXC came before Docker and does most of the heavy lifting.

stfp 13y ago
To your second point - I think you're right, but I think that pattern - the productization of existing technology - is a very powerful, positive thing. And picking the right abstraction, so that it feels - as you put it - brilliant (a view I share totally), is not trivial. Also FWIW, on giving credit: https://twitter.com/getdocker/status/357983297114079233 https://twitter.com/getdocker/status/357983297114079233
- secstate 13y ago
  For sure, I didn't mean to downplay how important tools like Docker are, just that it may not be as revolutionary as the shipping container. I think some other comments above make a better argument about how the full power of containers has yet to be realized.
icebraining 13y ago
As far as I now, the idea is that Docker won't be tied to LXC, but able to use different container technologies, like jails and zones.

Aqueous 13y ago

It'd be nice to get a suitable cross-platform container format, that would let you create a deployable container across multiple OSes. Process control groups exist in Darwin/Mac OS X - I wish you could sandbox packages with private network namespaces and filesystems as well.

est 13y ago
I don't understand, binary/lib usually doesn't share across platforms.
- Aqueous 13y ago
  Right. You could have a container which has universal dylibs and static libs for x86_64/i386 compiled for Darwin in one directory and ELF shared objects and static libraries compiled for x86_64/i386 for Linux, logic to detect the platform and the main application binaries compiled for multiple platforms. And why not throw Windows in there too? This would create a universal container, assuming all major OSes acquire facilities for process control groups, namespaces and chroot. Disk space is no longer a consideration. The containers can be as big as we want - why not make them run natively everywhere?
  - vidarh 13y ago
    Why bother? I'd be far simpler, and more resource efficient, to run whatever the user prefers of Xen/Virtualbox/Vmware or "bare" Linux as the base and not have to create monstrous franken-containers.
    - Aqueous 13y ago
      Well, speaking from personal experience, I develop on Mac OS X and deploy to Linux. It would be helpful to be able to run the same container on both for testing purposes.
justincormack 13y ago
cgroup type interfaces are not very portable, havent really looked at the interfaces. You could use a tun/tap interface and a userspace network stack (eg NetBSD rump kernel is portable).

jwilliams 13y ago

I like Docker and I use it in dev/sandpit quite a bit lately... but I must admit, I don't quite follow the metaphor being pushed here. Standard workloads don't require containers. You can have standard workloads on your physical or virtualised hardware. The choice between these is going to depend on a bunch of factors. I don't see why they need to be bound together, as appears to be the case with Docker? Plus I don't see how that provides any special leverage (as opposed to having the choice).

mateuszf 13y ago
It has great advantages by doing it this way. 1. For developer: - your application works exactly the same way on your development, test and production environment because of using exactly the same os/libs/configuration - very fast snapshot/restore simplifies automatic tests and makes them practical 2. For system admin: - configure your system once in order to make docker work, run any docker image (program) with one, the same command - run many applications which do not influence each other in a quite safe way - download and run application without worrying about its dependencies - very low footprint in terms of disk/memory/cpu usage in comparison with standard virtualization
- jwilliams 13y ago
  1. Agree that's handy in dev. For development a container is probably a good choice - in other environments virtualization or physical hardware may make sense. "More consistent" dev/test/prod is great, but I don't need nor want identical. My needs in dev are different from production - e.g. Everything from basic settings, URLs, networking, reloading behaviour to performance tuning. My needs for my dev DB are quite different from those in production. 2. Agree, but this isn't unique to containers (which is probably what I was aiming at). Low footprint is somewhat irrelevant to "configure once". You can manage this on physical hardware if needs be. Low footprint is great when you're resource constrained, somewhat irrelevant at scale. Plus a VM gives you other features/tradeoffs in return for that cost. Different circumstances will tend to favour one over the other. I find Docker useful. Containers and Standardised Workloads are great. I see the utility in both, my argument is I see them as orthogonal. Particularly referring to the "alternatives" at the end of the deck, which seemed unnecessary distinctions for me.

kraemate 13y ago

I dont get the hype. BSD and Solaris have had proper containers for years now. Just because Linux hasn't had any all these years and LXC is maturing only now, it is wrong to think that containers are the next big thing.

icebraining 13y ago
Linux has had containers for years, they're called "OpenVZ". But Docker is not a container technology, it's an API over those.
- zurn 13y ago
  Not in stock Linux - OpenVZ has been a bit like Xen that way, requiring a custom kernel. Which for most people means a dedicated host machine is needed.
  - darkarmani 13y ago
    I'm not sure what you mean by dedicated host machine, because OpenVZ runs on Amazon and Azure instances.
FooBarWidget 13y ago
I also think it's strange. FreeBSD jails are essentially the same thing. When I describe Docker, I would call it "FreeBSD jails for Linux" rather than "lightweight virtual machine" or even "iPhone apps-style isolation". But I do get the hype. BSD and Solaris, although they have many interesting benefits, just aren't that popular for a variety of reasons. I won't turn this into a discussion of why they aren't popular, but it's a fact that Linux is much more popular. Most people aren't going to switch even if BSD and Solaris provide more benefits. But now that an important feature has become available for Linux, I can see why people get excited. It's like Node.js. Servers with evented I/O has exited for years, if not decades. But the fact that Node.js is Javascript made it mainstream and that's why there's hype.
- justincormack 13y ago

GoNB 13y ago

Unrelated: Why are people familiar with Hacker News (e.g. the Docker folks) still using slideshare.net? That site feels like it's stuck around 2005. I thought everyone here knew about http://slid.es http://slid.es by now -- its UX is far superior.

plainOldText 13y ago
I think http://speakerdeck.com/ http://speakerdeck.com/ is even better. IMO the UI is very cool and the entire site very easy to navigate; I actually find it hard to believe it's not a very popular slides sharing platform.
- ludwigvan 13y ago
  Weird, isn't it? Especially considering it was acquired by Github, where almost anyone here has an account. Maybe Github is not advertising it enough.

m_mueller 13y ago

There is one fallacy here: The 'thin' mobile client as being the future. Even though the world has moved towards thin client in the form of web clients, I firmly believe that the tides will turn - either by having the browser becoming a thick client itself (with local storage, lots of local logic) or by reintroducing native clients again - for which Containerization could play an essential role. Imagine if we'd have a standardized container format on top of Linux, the BSDs including OSX and Windows with Cygwin - hello cross platform client applications with a single installer. Apple and Microsoft could integrate container technology in their AppStores and we could submit the same package everywhere.

kstaken 13y ago
The browser is already a thick client with local storage and lots of local logic. The difference is that the entire client is shipped to the browser on demand.
- m_mueller 13y ago
  Ok, that's an interesting point. I'd argue that local storage hasn't really taken hold yet, i.e. the large majority of sites and apps don't work offline, but yeah, it already stretches the notion of a thin client (hence my beef about using this term on where we're headed in the future).

ballard 13y ago

Enterprise people have already moved in on this with opaque application volumes. NDA's so don't bother asking for detail.

eterm 13y ago

About a minute after loading this website a setup.exe downloaded which my antivirus promptly found and got rid of. Anyone else experience this?

boothead 13y ago

I think docker or similar is a great step forward... One question in my mind though: what about the databases? Say you have a web app and a reporting app that use the same database (and probably a communications framework - zmq server rabbitmq etc in the middle there as well). How does docker deal with the following: * The data? I can see postgres, redis or whatever being packaged up into containers, but what about the data that they use? Will there be attachable storage? Will you share some exposed resource on the host? Will the data be another container on top of the database app container? * Routing. How do you tell your reporting/web app containers "this is where your message bus and database live?" * Coordination. I'm used to using something like supervisord to control my processes - what's the equivalent in docker land? Replace the scripts in supervisord with the equivalent dockerized apps? A docker file for the host specifying what to run? How do you know if your app that you've run inside docker has crashed? * Or do you just package the whole lot above up into one container? edit actually that was more than one :-)

vidarh 13y ago
> * Coordination. I'm used to using something like supervisord to control my processes - what's the equivalent in docker land? The question doesn't really make sense: The equivalent is supervisord running inside the lxc container. > * Routing. How do you tell your reporting/web app containers "this is where your message bus and database live?" How do you tell them in a cluster? This is a problem anyone who's ever needed to scale a system beyond a single server has already had to deal with, whether or not the application is package up a container, and there's a plethora of solutions, ranging from hardcoding it in config files, to LDAP or DNS based approaches, to things like Zookeeper or Doozer, to keeping all the config data in a database server (and hardcoding the dsn for that), to rsyncing files with all the config data to all the servers, and lots more.
- johnbellone 13y ago
  I'm not sure there's going to be a bullet-proof solution to this. I believe that Docker is the right step forward, especially for the application containers. What I have been tinkering with is the idea of having smaller, configurable pieces of infrastructure and then providing a simple tool on top of that (e.g. 'heroku' CLI). Once you are past the procurement and provisioning steps you really need a way to describe how to wire everything together. I definitely haven't solved it yet but I sure hope to! :)

dschiptsov 13y ago

over-hyped FreeBSD's jails?)

kstaken 13y ago
Yep, jails, containers, solaris zones all the way back to IBM mainframes have been similar core technologies. Docker it self isn't containerization, Docker builds on Linux containers but adds a layer to dramatically simplify the build, distribution and execution of containers and that's what makes it game changing. docker run gtihub.com/some/project That command will clone, build and execute a container based on the contents of a repository by simply dropping a Dockerfile in the root of the project. That's a fundamentally different level of usage beyond any existing container technology.

megaman821 13y ago

How does Docker handle deploying to machines with wildly varying capabilities? Every machine you deploy on may have different configurations and performance tunings. Is there a Docker container that can run a DB well on a EC2 small instance and 16 core 128GB RAM dedicated server?