12 ms·

Docker: Git for deployment

318 points by itsderek23 13y ago

bryanlarsen 13y ago
Did you look at vagrant-lxc? If you already have a vagrant setup it's very easy to switch to and works very well.
patrickaljord 13y ago
If you're around Paris, we're doing a Docker meetup in October http://www.meetup.com/Docker-Paris/events/136924002/ http://www.meetup.com/Docker-Paris/events/136924002/
deleted 13y ago
[deleted]
megaman821 13y ago
How does Docker mesh with something like continuous deployment? How many layers until the AUFS falls down?
- shykes 13y ago
  > How does Docker mesh with something like continuous deployment? Very well. Because any source repository with a Dockerfile can be built into a container with no other out-of-band information, it is very easy to compose your ideal delivery pipeline with docker as the "lego" brick. Docker+Jenkins and Docker+buildbot are popular combinations. > How many layers until the AUFS falls down? The hardcoded limit is 42 layers. But future versions of docker will store a container's history separately from the aufs layers, so you can have an arbitrary number of build steps.
amjith 13y ago
I don't think there is a way to rollback an image to the previous commit. Is there?
- nickstinemates 13y ago
  Absolutely. Provided you haven't deleted the old container, it's just a matter of using `docker tag <previous commit id> amjith/imagetorollback` Problem solved.
mitchellh 13y ago
Disclaimer: Vagrant creator/maintainer guy. It is unfortunate that so many people compare Vagrant and Docker. While there is overlap, Docker is mostly not viable as a dev environment tool alone, so it isn't a fair comparison. The main reason is because you have to be using Linux (and a recent Linux) as your main dev system, and in practice this is very rare. Move beyond indie developers and for all intents and purposes Linux desktops are non-existent (Vagrant is in use by companies like BBC, Expedia, Intuit, etc. and I can tell you most devs don't know how to use Linux let alone run it as their primary dev platform). BUT, I agree that putting your dev environment in a Docker container is absolutely _amazing_, and there is a KILLER Vagrant/Docker combo. The killer combo is actually running Vagrant to spin up Docker-ready VMs, then using Docker inside that to develop. This lets people use Docker on Windows, Mac, and Linux. You get the fast iteration time because all your state is actually in a container, so you just docker kill and run as usual. In fact, an upcoming version of Vagrant is adding Docker as a provisioner, so you can `docker pull` containers down as part of `vagrant up`. And I published Packer[1] templates to build Docker-ready VirtualBox/VMware/AWS images that are Vagrant-ready: https://github.com/mitchellh/packer-ubuntu-12.04-docker https://github.com/mitchellh/packer-ubuntu-12.04-docker [1]: www.packer.io
- dpritchett 13y ago
  As a dev whose 2010 MBP doesn't do so hot spinning up multiple Vagrants, I've been strongly contemplating Linux for my next laptop just so I can run containers natively. Docker-on-linux-on-vagrant is a nice compromise though.
  - mitchellh 13y ago
    If you're just using Vagrant as a harness to run Docker-ready VMs, you only need to spin up one VM to host multiple Docker containers, so it works decently on earlier (definitely 2010!) laptops.
    - contingencies 13y ago
      Yes, just to confirm I run loads of stuff on a 2010 MBP... not docker but similar and heavier workloads. With caching as advertised in the linked article, you should see no issues. Just be sure to fork over adequate memory to your VM to stop it swapping over a seriously slow, paravirtualized block device with parallel applications causing host OS contention.
peterwwillis 13y ago
I don't see the parallels to Git at all. If you just looked at the command line options without understanding what's going on at all it might look similar. > a tool like Puppet or Chef is needed when you have long-running VMs that could become inconsistent over time. Uh, no, Puppet and Chef are designed for configuration management. To manage your configs. They are not designed to replace customization and they don't address package management or service maintenance. (They have options to munge these things, but you still need a human to make them useful and coordinate changes with your environment) Neither does Docker. Docker also doesn't do configuration management. All different things. > You'll be 100% sure what runs locally will run on production. Incorrect; you're using unions to fill in the missing dependency gaps, so there's no guarantee what was on your testing container's host is on your production container's host. Your devs also might be running with container A and B, but in production you're using containers A and C. Not to mention the kernels may be different, providing different functionality. All this assuming A, B and C don't need instances of different configuration. There are no guarantees. You know what else is crazy fast and easy to manage? Packages. There's this new idea where you can have an operating system, run the command 'apt-get install foobar', and BAM all of a sudden foobar is installed. If you need a dependency, it just installs it. And it only downloads what it needs. Also does rollback, transactions, auditing, is multi-platform, extensible, does pre-and-post configuration, etc. Sound a lot like docker? That's because it's a simpler and more effective version of docker [without running everything as a virtualized service]. Deploy using your package manager. Except for slotted services which (AFAIK) no open-source package manager supports, it will do everything you need. And what it doesn't do, you can hack in.
- cjp 13y ago
  Each docker RUN command is like a git commit. See those cache keys? Those are the commit sha1sums. According to the article, you can roll back to a (any?) cache key and branch off into a new direction. I wonder about merges though.
  - peterwwillis 13y ago
    Oh, I found it in their FAQ: > Versioning. > Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to git pull, so new versions of a container can be transferred by only sending diffs. I get it now. They support features which are comparable to features found in Git. Similar to how Apt and RPM are just like Git, because they also have the same features. What I don't see is specifically git-like functionality, which would be incredibly useful for anyone who packages deployments of OSes, applications, configs, etc. For example, with Git you have a workspace that allows you to work with a tree of files, make changes, make specific commit logs for specific changes, merge, compare, search, etc. From what I see of docker, it's all just "how do I move my already-built containers around" functionality, and of course a shell-script (or specfile, or debian rules file) replacement called a Dockerfile. There are lots of deployment solutions out there. What there isn't is a handy way to manage and track the assembling and customization of your various things-to-be-deployed, independent of the platform. A deployment tool that did that would become very popular.
seldo 13y ago
I'm very excited about Docker[1] as both a development environment and deployment solution. However, from my early experiments, it seems there's an important difference between LXC (which is what Docker manages for you) and a full VM, namely that the model revolves around running one process at a time: you can install mySQL on your docker image, but once it's up, it's running mySQL -- you can't then ssh into it as you would a VM to poke around, modify config files, etc.. There are trivial ways to solve this, obviously. You can stop the image, restart it running bash, use that to modify config files, and then restart it again. But it requires a change of mindset: these things are much more than background processes, but they are less than a full VM. As the piece mentions, configuration management for newly-started images seems to be a missing piece of the puzzle right now, and debugging running Docker images can be... strange. [2] Not necessarily difficult, but different from what you're used to, and learning curves are barriers to adoption. As this tech matures I think these things will be quickly solved, and I'm looking forward to the results. [1] Plus Virtualbox, started by Vagrant. See mitchellh's comment. [2] Unless, of course, I'm missing something. Docker-people: how do you configure vanilla server images to work in your environment?
- nickstinemates 13y ago
  Well, the canonical way of running a container is as you mention. However! There's a couple of options if you do not have a config you're completely happy with yet. One is to run a process manager like supervisord as your container process, and start up any arbitrary amount of services you wish (like ssh.) It's my understanding that in the future Docker will allow you to call `init` directly, so it becomes more vm like. The other, assuming a sufficiently modern kernel (I believe 3.8+, which is the minimum supported for Docker) is to use the lxc userland tools, specifically `lxc-attach <containerid>` This will allow you to create a shell in the running container and poke about as needed.
  - seldo 13y ago
    My experiments with lxc-attach always failed; presumably my kernel was wrong in some way (I followed instructions to get to 3.8, but I am sufficiently clueless that I wasn't sure it had worked, or that it was the right flavor of 3.8). But that's only the ad-hoc case: the bigger question is, if you have an image with instructions "RUN apt-get install mysql", you're not even halfway to having a copy of MySQL you can run in production: at a minimum you'll need to install a custom my.cnf to suit your application's operational parameters[1], but really you'll want it to be slightly different every time -- new bind addresses, potentially new master-slave relationship grants, etc.. The way docker images interact with configuration management in a grown-up production environment is still really hazy to me. [1] We are all agreed that running default my.cnf in production is laughable, yes? That information has filtered into the mainstream from the DBA crowd?
j_s 13y ago
Get back in touch with me when Docker can help with Windows deployments. (Is there an issue I can 'star' or otherwise track?) Edit: To say Docker is analogous to Git for deployment fails outside of the Linux server realm (lxc). I'm trying to think of an OS-specific source control system to fix the analogy but can't come up with anything only-Linux... 'TFS for deployment'? :) I plan to check out http://ulteo.com/home/en/download/sourcecode http://ulteo.com/home/en/download/sourcecode as an alternative.
- seldo 13y ago
  Docker is a pretty thin usability wrapper around LXC, which has Linux right in the name, so very unlikely to become useful on Windows (or even OS X, which is BSD) anytime soon.
  - nickstinemates 13y ago
    Not sure I would call it thin, but today Docker uses LXC as a container provider. But in saying so it misses the point of Docker. Keep in mind also, this is all related to the daemon. Full client capabilities are available on any platform today. In a previous blogpost, the Docker team outlined how LXC will become a (albeit native) plugin, just like AUFS. Running Docker on BSD (using Jails as the container provider) is certainly a goal. If you're on OS X, you could use chroot instead of full namespacing capabilities. To be fair, this is not available today. But I don't think it's fair to say that Docker will not be useful anytime soon on those environments.
- tracker1 13y ago
  The underlying technology for Docker is LXC (Linux Containers), which is very tied to an underlying linux system. I would expect Joyent to support enough for Docker to work in SmartOS before MS would/could in Windows.
- emmelaich 13y ago
  The closest thing for Windows that I can think of is Sandboxie. http://www.sandboxie.com/ http://www.sandboxie.com/ It's still quite different.
txutxu 13y ago
Hello, Is there any way to run this on a recommendable way with other platforms than ubuntu? I could love to see it running smoothly with debian and centos to turn immediately into a converted user. Nice work, looks impressive.
- nadaviv 13y ago
  They have official images for Ubuntu, Centos and Busybox, and unofficial ones for many more (Gentoo, Arch, Debian, OpenSUSE, and others). See https://github.com/dotcloud/docker/wiki/Public-docker-images https://github.com/dotcloud/docker/wiki/Public-docker-images and https://index.docker.io/ https://index.docker.io/
  - txutxu 13y ago
    Thanks +1 for the direct pointer.
  - cwoac 13y ago
    Note that that is for containers (i.e. guests). For the host side, only ubuntu is officially supported; many people are using arch quite well, and a few have got it running under fedora and suse that I know of (I'm going to assume gentoo have it as well, knowing them). both require custom kernels however.
infocollector 13y ago
My top wishlist for docker: Native windows support.
- Ixiaus 13y ago
  From my limited knowledge of Windows: that's highly unlikely. You're much more likely to see Docker start supporting FreeBSD jails with ZFS than you are Windows. Then again I know nothing of Windows and any containerization technology it may have...
  - mburns 13y ago
    Solaris Zones support would be awesome. Still a longshot, but more likely than native Windows support, at least.
  - emmelaich 13y ago
    http://www.sandboxie.com/ http://www.sandboxie.com/ ? Or perhaps build something off the Chromium sandboxing. http://www.chromium.org/developers/design-documents/sandbox#TOC-Sandbox-windows-architecture http://www.chromium.org/developers/design-documents/sandbox#...
- tsmith 13y ago
  Unfortunately, that's where the "containers are like VMs, but better!" argument breaks down. Linux Containers, which docker makes use of, are more like creating a "clone" of the currently running operating system with a boxed-in filesystem (and device-space?). You can't run a Windows container on a Linux host; neither can you run a Solaris container on a Linux host; ad nausium. With VMs, you can run whatever you want on whatever you want, assuming the processor architecture is compatible.
  - nickstinemates 13y ago
    > Linux Containers, which docker makes use of, are more like creating a "clone" of the currently running operating system with a boxed-in filesystem (and device-space?). This is not accurate. I am currently running an Ubuntu Docker host, but a CentOS 6.4 based container, a Gentoo container, and a busybox container. As stated elsewhere in this thread, which I encourage you to read, Docker aims to solve problems that exist in container technologies across kernels by taking advantage of their strengths (Docker does not aim to replace libvirt/lxc/jails/zones) but instead to build abstractions on top of them for better building, management, discovery, and scale.
cynusx 13y ago
docker is pretty awesome, at my company we share auxilary server around with docker (message queue system) and it's pretty RAD. I can't wait until they made it rock-solid enough to run systems in production with it.
ivoras 13y ago
OS containers can be very cool. Want to see 1000 instances started on a small machine? http://ivoras.sharanet.org/blog/tree/2009-10-20.the-night-of-1000-jails.html http://ivoras.sharanet.org/blog/tree/2009-10-20.the-night-of...
coherentpony 13y ago
Would it be possible to deploy an email server inside a docker container?
- bacongobbler 13y ago
  possible? yes. The better question you should ask yourself would be "does the use case make sense?" Linux containers are ephemeral, which means that you will lose all data from your email server on a container restart. If you're just setting up a postfix SMTP server in a container, and forwarding the guest's port 25 to the host, I don't see why not. You probaby won't have any app scaling support or the likes, though. I could be wrong about that. I've never attempted to set up a clustered SMTP server configuration before.
  - nickstinemates 13y ago
    Docker containers are not ephemeral. Persistent storage can be easily shared between containers using a VOLUME or bind mount.
    - bacongobbler 13y ago
      TIL. Thanks for the heads up.
based2 13y ago
Another one in progress: https://github.com/arnoo/git-deliver https://github.com/arnoo/git-deliver http://i.reddit.com/r/programming/comments/1j9n8v/gitdeliver_better_software_deployment_with_git/ http://i.reddit.com/r/programming/comments/1j9n8v/gitdeliver...
gtani 13y ago
https://news.ycombinator.com/item?id=6252182 https://news.ycombinator.com/item?id=6252182 (i would give credibility to the docker maintainer)
BHSPitMonkey 13y ago
I spent the entire article wondering how deployment via git was at all relevant, until I read the very last heading. (The title is supposed to be read as "Docker is as powerful for deployment as git is powerful for SCM!". There is no mention of git-based deployment strategies like Heroku's.)
passfree 13y ago
I am still not sure how useful Docker is but we have created a simple example how to run Docker on Vortex which is sort of Vagrant alternative. https://github.com/websecurify/node-vortex/tree/master/doc/examples/docker-helloworld https://github.com/websecurify/node-vortex/tree/master/doc/e...
herpy 13y ago
The title should read: "Docker is Git for deployment" Currently, it implies that Docker is using Git for deployment.

318 points by itsderek23 13y ago

Did you look at vagrant-lxc? If you already have a vagrant setup it's very easy to switch to and works very well.

If you're around Paris, we're doing a Docker meetup in October http://www.meetup.com/Docker-Paris/events/136924002/ http://www.meetup.com/Docker-Paris/events/136924002/

deleted 13y ago

[deleted]

megaman821 13y ago

How does Docker mesh with something like continuous deployment? How many layers until the AUFS falls down?

shykes 13y ago
> How does Docker mesh with something like continuous deployment? Very well. Because any source repository with a Dockerfile can be built into a container with no other out-of-band information, it is very easy to compose your ideal delivery pipeline with docker as the "lego" brick. Docker+Jenkins and Docker+buildbot are popular combinations. > How many layers until the AUFS falls down? The hardcoded limit is 42 layers. But future versions of docker will store a container's history separately from the aufs layers, so you can have an arbitrary number of build steps.

amjith 13y ago

I don't think there is a way to rollback an image to the previous commit. Is there?

nickstinemates 13y ago
Absolutely. Provided you haven't deleted the old container, it's just a matter of using `docker tag <previous commit id> amjith/imagetorollback` Problem solved.

mitchellh 13y ago

Disclaimer: Vagrant creator/maintainer guy. It is unfortunate that so many people compare Vagrant and Docker. While there is overlap, Docker is mostly not viable as a dev environment tool alone, so it isn't a fair comparison. The main reason is because you have to be using Linux (and a recent Linux) as your main dev system, and in practice this is very rare. Move beyond indie developers and for all intents and purposes Linux desktops are non-existent (Vagrant is in use by companies like BBC, Expedia, Intuit, etc. and I can tell you most devs don't know how to use Linux let alone run it as their primary dev platform). BUT, I agree that putting your dev environment in a Docker container is absolutely _amazing_, and there is a KILLER Vagrant/Docker combo. The killer combo is actually running Vagrant to spin up Docker-ready VMs, then using Docker inside that to develop. This lets people use Docker on Windows, Mac, and Linux. You get the fast iteration time because all your state is actually in a container, so you just docker kill and run as usual. In fact, an upcoming version of Vagrant is adding Docker as a provisioner, so you can `docker pull` containers down as part of `vagrant up`. And I published Packer[1] templates to build Docker-ready VirtualBox/VMware/AWS images that are Vagrant-ready: https://github.com/mitchellh/packer-ubuntu-12.04-docker https://github.com/mitchellh/packer-ubuntu-12.04-docker [1]: www.packer.io

dpritchett 13y ago
As a dev whose 2010 MBP doesn't do so hot spinning up multiple Vagrants, I've been strongly contemplating Linux for my next laptop just so I can run containers natively. Docker-on-linux-on-vagrant is a nice compromise though.
- mitchellh 13y ago
  If you're just using Vagrant as a harness to run Docker-ready VMs, you only need to spin up one VM to host multiple Docker containers, so it works decently on earlier (definitely 2010!) laptops.
  - contingencies 13y ago
    Yes, just to confirm I run loads of stuff on a 2010 MBP... not docker but similar and heavier workloads. With caching as advertised in the linked article, you should see no issues. Just be sure to fork over adequate memory to your VM to stop it swapping over a seriously slow, paravirtualized block device with parallel applications causing host OS contention.

peterwwillis 13y ago

I don't see the parallels to Git at all. If you just looked at the command line options without understanding what's going on at all it might look similar. > a tool like Puppet or Chef is needed when you have long-running VMs that could become inconsistent over time. Uh, no, Puppet and Chef are designed for configuration management. To manage your configs. They are not designed to replace customization and they don't address package management or service maintenance. (They have options to munge these things, but you still need a human to make them useful and coordinate changes with your environment) Neither does Docker. Docker also doesn't do configuration management. All different things. > You'll be 100% sure what runs locally will run on production. Incorrect; you're using unions to fill in the missing dependency gaps, so there's no guarantee what was on your testing container's host is on your production container's host. Your devs also might be running with container A and B, but in production you're using containers A and C. Not to mention the kernels may be different, providing different functionality. All this assuming A, B and C don't need instances of different configuration. There are no guarantees. You know what else is crazy fast and easy to manage? Packages. There's this new idea where you can have an operating system, run the command 'apt-get install foobar', and BAM all of a sudden foobar is installed. If you need a dependency, it just installs it. And it only downloads what it needs. Also does rollback, transactions, auditing, is multi-platform, extensible, does pre-and-post configuration, etc. Sound a lot like docker? That's because it's a simpler and more effective version of docker [without running everything as a virtualized service]. Deploy using your package manager. Except for slotted services which (AFAIK) no open-source package manager supports, it will do everything you need. And what it doesn't do, you can hack in.

cjp 13y ago
Each docker RUN command is like a git commit. See those cache keys? Those are the commit sha1sums. According to the article, you can roll back to a (any?) cache key and branch off into a new direction. I wonder about merges though.
- peterwwillis 13y ago
  Oh, I found it in their FAQ: > Versioning. > Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to git pull, so new versions of a container can be transferred by only sending diffs. I get it now. They support features which are comparable to features found in Git. Similar to how Apt and RPM are just like Git, because they also have the same features. What I don't see is specifically git-like functionality, which would be incredibly useful for anyone who packages deployments of OSes, applications, configs, etc. For example, with Git you have a workspace that allows you to work with a tree of files, make changes, make specific commit logs for specific changes, merge, compare, search, etc. From what I see of docker, it's all just "how do I move my already-built containers around" functionality, and of course a shell-script (or specfile, or debian rules file) replacement called a Dockerfile. There are lots of deployment solutions out there. What there isn't is a handy way to manage and track the assembling and customization of your various things-to-be-deployed, independent of the platform. A deployment tool that did that would become very popular.

seldo 13y ago

I'm very excited about Docker[1] as both a development environment and deployment solution. However, from my early experiments, it seems there's an important difference between LXC (which is what Docker manages for you) and a full VM, namely that the model revolves around running one process at a time: you can install mySQL on your docker image, but once it's up, it's running mySQL -- you can't then ssh into it as you would a VM to poke around, modify config files, etc.. There are trivial ways to solve this, obviously. You can stop the image, restart it running bash, use that to modify config files, and then restart it again. But it requires a change of mindset: these things are much more than background processes, but they are less than a full VM. As the piece mentions, configuration management for newly-started images seems to be a missing piece of the puzzle right now, and debugging running Docker images can be... strange. [2] Not necessarily difficult, but different from what you're used to, and learning curves are barriers to adoption. As this tech matures I think these things will be quickly solved, and I'm looking forward to the results. [1] Plus Virtualbox, started by Vagrant. See mitchellh's comment. [2] Unless, of course, I'm missing something. Docker-people: how do you configure vanilla server images to work in your environment?

nickstinemates 13y ago
Well, the canonical way of running a container is as you mention. However! There's a couple of options if you do not have a config you're completely happy with yet. One is to run a process manager like supervisord as your container process, and start up any arbitrary amount of services you wish (like ssh.) It's my understanding that in the future Docker will allow you to call `init` directly, so it becomes more vm like. The other, assuming a sufficiently modern kernel (I believe 3.8+, which is the minimum supported for Docker) is to use the lxc userland tools, specifically `lxc-attach <containerid>` This will allow you to create a shell in the running container and poke about as needed.
- seldo 13y ago
  My experiments with lxc-attach always failed; presumably my kernel was wrong in some way (I followed instructions to get to 3.8, but I am sufficiently clueless that I wasn't sure it had worked, or that it was the right flavor of 3.8). But that's only the ad-hoc case: the bigger question is, if you have an image with instructions "RUN apt-get install mysql", you're not even halfway to having a copy of MySQL you can run in production: at a minimum you'll need to install a custom my.cnf to suit your application's operational parameters[1], but really you'll want it to be slightly different every time -- new bind addresses, potentially new master-slave relationship grants, etc.. The way docker images interact with configuration management in a grown-up production environment is still really hazy to me. [1] We are all agreed that running default my.cnf in production is laughable, yes? That information has filtered into the mainstream from the DBA crowd?

j_s 13y ago

Get back in touch with me when Docker can help with Windows deployments. (Is there an issue I can 'star' or otherwise track?) Edit: To say Docker is analogous to Git for deployment fails outside of the Linux server realm (lxc). I'm trying to think of an OS-specific source control system to fix the analogy but can't come up with anything only-Linux... 'TFS for deployment'? :) I plan to check out http://ulteo.com/home/en/download/sourcecode http://ulteo.com/home/en/download/sourcecode as an alternative.

seldo 13y ago
Docker is a pretty thin usability wrapper around LXC, which has Linux right in the name, so very unlikely to become useful on Windows (or even OS X, which is BSD) anytime soon.
- nickstinemates 13y ago
  Not sure I would call it thin, but today Docker uses LXC as a container provider. But in saying so it misses the point of Docker. Keep in mind also, this is all related to the daemon. Full client capabilities are available on any platform today. In a previous blogpost, the Docker team outlined how LXC will become a (albeit native) plugin, just like AUFS. Running Docker on BSD (using Jails as the container provider) is certainly a goal. If you're on OS X, you could use chroot instead of full namespacing capabilities. To be fair, this is not available today. But I don't think it's fair to say that Docker will not be useful anytime soon on those environments.
tracker1 13y ago
The underlying technology for Docker is LXC (Linux Containers), which is very tied to an underlying linux system. I would expect Joyent to support enough for Docker to work in SmartOS before MS would/could in Windows.
emmelaich 13y ago
The closest thing for Windows that I can think of is Sandboxie. http://www.sandboxie.com/ http://www.sandboxie.com/ It's still quite different.

txutxu 13y ago

Hello, Is there any way to run this on a recommendable way with other platforms than ubuntu? I could love to see it running smoothly with debian and centos to turn immediately into a converted user. Nice work, looks impressive.

nadaviv 13y ago
They have official images for Ubuntu, Centos and Busybox, and unofficial ones for many more (Gentoo, Arch, Debian, OpenSUSE, and others). See https://github.com/dotcloud/docker/wiki/Public-docker-images https://github.com/dotcloud/docker/wiki/Public-docker-images and https://index.docker.io/ https://index.docker.io/
- txutxu 13y ago
  Thanks +1 for the direct pointer.
- cwoac 13y ago
  Note that that is for containers (i.e. guests). For the host side, only ubuntu is officially supported; many people are using arch quite well, and a few have got it running under fedora and suse that I know of (I'm going to assume gentoo have it as well, knowing them). both require custom kernels however.

infocollector 13y ago

My top wishlist for docker: Native windows support.

Ixiaus 13y ago
From my limited knowledge of Windows: that's highly unlikely. You're much more likely to see Docker start supporting FreeBSD jails with ZFS than you are Windows. Then again I know nothing of Windows and any containerization technology it may have...
- mburns 13y ago
  Solaris Zones support would be awesome. Still a longshot, but more likely than native Windows support, at least.
- emmelaich 13y ago
  http://www.sandboxie.com/ http://www.sandboxie.com/ ? Or perhaps build something off the Chromium sandboxing. http://www.chromium.org/developers/design-documents/sandbox#TOC-Sandbox-windows-architecture http://www.chromium.org/developers/design-documents/sandbox#...
tsmith 13y ago
Unfortunately, that's where the "containers are like VMs, but better!" argument breaks down. Linux Containers, which docker makes use of, are more like creating a "clone" of the currently running operating system with a boxed-in filesystem (and device-space?). You can't run a Windows container on a Linux host; neither can you run a Solaris container on a Linux host; ad nausium. With VMs, you can run whatever you want on whatever you want, assuming the processor architecture is compatible.
- nickstinemates 13y ago
  > Linux Containers, which docker makes use of, are more like creating a "clone" of the currently running operating system with a boxed-in filesystem (and device-space?). This is not accurate. I am currently running an Ubuntu Docker host, but a CentOS 6.4 based container, a Gentoo container, and a busybox container. As stated elsewhere in this thread, which I encourage you to read, Docker aims to solve problems that exist in container technologies across kernels by taking advantage of their strengths (Docker does not aim to replace libvirt/lxc/jails/zones) but instead to build abstractions on top of them for better building, management, discovery, and scale.

cynusx 13y ago

docker is pretty awesome, at my company we share auxilary server around with docker (message queue system) and it's pretty RAD. I can't wait until they made it rock-solid enough to run systems in production with it.

ivoras 13y ago

OS containers can be very cool. Want to see 1000 instances started on a small machine? http://ivoras.sharanet.org/blog/tree/2009-10-20.the-night-of-1000-jails.html http://ivoras.sharanet.org/blog/tree/2009-10-20.the-night-of...

coherentpony 13y ago

Would it be possible to deploy an email server inside a docker container?

bacongobbler 13y ago
possible? yes. The better question you should ask yourself would be "does the use case make sense?" Linux containers are ephemeral, which means that you will lose all data from your email server on a container restart. If you're just setting up a postfix SMTP server in a container, and forwarding the guest's port 25 to the host, I don't see why not. You probaby won't have any app scaling support or the likes, though. I could be wrong about that. I've never attempted to set up a clustered SMTP server configuration before.
- nickstinemates 13y ago
  Docker containers are not ephemeral. Persistent storage can be easily shared between containers using a VOLUME or bind mount.
  - bacongobbler 13y ago
    TIL. Thanks for the heads up.

based2 13y ago

Another one in progress: https://github.com/arnoo/git-deliver https://github.com/arnoo/git-deliver http://i.reddit.com/r/programming/comments/1j9n8v/gitdeliver_better_software_deployment_with_git/ http://i.reddit.com/r/programming/comments/1j9n8v/gitdeliver...

gtani 13y ago

https://news.ycombinator.com/item?id=6252182 https://news.ycombinator.com/item?id=6252182 (i would give credibility to the docker maintainer)

BHSPitMonkey 13y ago

I spent the entire article wondering how deployment via git was at all relevant, until I read the very last heading. (The title is supposed to be read as "Docker is as powerful for deployment as git is powerful for SCM!". There is no mention of git-based deployment strategies like Heroku's.)

passfree 13y ago

I am still not sure how useful Docker is but we have created a simple example how to run Docker on Vortex which is sort of Vagrant alternative. https://github.com/websecurify/node-vortex/tree/master/doc/examples/docker-helloworld https://github.com/websecurify/node-vortex/tree/master/doc/e...

herpy 13y ago

The title should read: "Docker is Git for deployment" Currently, it implies that Docker is using Git for deployment.