We use Docker to deploy on Aptible, and this makes our projects entirely self-contained. With a Dockerfile in the project directory, the entire build and runtime environment is now explicitly declared. With "git push aptible", we push the code to the production server, rebuild the project, and run it in one command.
Can you elaborate on the middle bits? How do you go from 'git push aptible' to the actual execution of the docker commands on the production server? (Setting up something similar myself and would love some direction).
What value does Docker add if you are already running a VM? Are the laptops Linux, so Docker provides a lighter alternative to a full vm environment?
Docker also enforces immutability. With a VM there's always the temptation to manually fix any issue that arises, and if you don't have some bulletproof way to document that then you'll have issues when you go to recreate the environment on a new machine. Docker kind of forces you to solve the original problem via the dockerfile, which is what will spawn images for any future installs anyway.
Could you explain this more? I think my confusions stems from where the config comes from. Regardless of whether I have a bit-for-bit image or a vm created from a bunch of script commands, the immutability disappears when I apply the config.
So for my example If I have a role that specifies one instance of a a galera server. I have to config each one with the other servers in the pool. And each config will be dependent on the other server's config. So is Docker the first part (get the galera server instance running) and then there is some 2nd part that does the config so the instances in the cluster work together?
we use docker to run tests, honestly we could deploy the resulting images to our production infrastructure now quite happily however we haven't got round to it yet.
How do you deal with connections that are in progress to the app server? If you just take it down, you're potentially throwing away active connections.
Yes, that's absolutely true and something we're aware of. It would of course be possible to solve, but would increase the complexity by a fair amount. It is also worth mentioning that it is a more back-end heavy service, than front-end heavy. Since each email migration runs isolated in its own Docker container, a given customer can generate 100s of Docker containers. Hence, given the relatively low volume of users on…
ok thanks. I have several app servers and I take them out of nginx server list, stop it gracefully, git pull and configure (slow, I want to get rid of this step), put it back in nginx servers, move onto the next one.
tedious, although my whole deploy-to-all-servers is a single command.
I honestly find it really depressing to see all these folks taking code and applications that would otherwise be entirely portable, and rebuilding their entire deployment and development environment around a hard dependency on Linux.
If Docker becomes sufficiently popular, it's going to put HUGE nails in the coffin of portability and the vibrancy of the UNIX ecosystem.
We use docker for: - running graphite (can't say it was less pain launching it, since Dockerfile was outdated a bit, and I also had to additionally figure out persistency issues, but overall I'm happy it's all virtualized and not living on server itself) - building our haskell projects for specific feature (your run a container per feature, this way you omit pain switching between features when you need to build one)…
In VMware, we use Docker for automated build and test of several of open source efforts as well as for a production IT business management mobile cost analysis SaaS offering we provide.
Docker has demonstrated value in ensuring the app remains consistent across environments.
I'm very interested in feedback from any of you on what VMware can do to make Docker CI and Docker production use easier in general and on vSphere, fusion and vCloud Air.
We are engaged with Docker and the open source projects and would love to hear your feedback.
Please email me at carterm at vmware dot com with any feedback, comments or ideas.
Thanks,
Mark
We actually started using Docker a few months ago and it really sped up our deployment process. It's not only incredibly faster than using virtual machines for testing; it allows you to host multiple apps on one server and to have all versions of your app ready to download and run. More info at http://www.syncano.com/reasons-use-docker/
Yes, that's absolutely true and something we're aware of. It would of course be possible to solve, but would increase the complexity by a fair amount. It is also worth mentioning that it is a more back-end heavy service, than front-end heavy. Since each email migration runs isolated in its own Docker container, a given customer can generate 100s of Docker containers. Hence, given the relatively low volume of users on…
ok thanks. I have several app servers and I take them out of nginx server list, stop it gracefully, git pull and configure (slow, I want to get rid of this step), put it back in nginx servers, move onto the next one. tedious, although my whole deploy-to-all-servers is a single command.
Yeah, that sounds pretty tedious, but I guess it could still be automated (but somewhat tricky).
Once CoreOS becomes more stable, we're looking to move to it. The idea is then to use `etcd` to feed the load balancer (probably Nginx) with the appserver pool. That way you can easily add new servers and decommission old ones.
We're moving all of production in EC2 from an old CentOS 5 image managed by capistrano to CoreOS, with fleet deploying images built by the docker.io build service and private repo. I love it. Every week, we rebuild our base image starting with the latest debian:stable image, apply updates, and then our apps are built off of the latest base image. So distro security updates are automatically included with our next dep…
The biggest problem I have overall is pushing new code. When you push new code to git, do you then stop a container and restart it to get a new container working? (Assuming you do something like git clone in the Dockerfile)