Getting Started with Docker
I saw that people were looking for better getting started docs for Docker, so I put together the post I wish I found on Docker when I was digging into it.
This skips over the hard part: managing docker containers. Poking a hole directly to the container is a leaky abstraction. A reverse proxy like HAProxy or Varnish should be sitting in front of the container.
Once you have the reverse proxy setup the next problem that arises is routing to containers based on the domain. Now your HAProxy or Varnish config is going to get bloated and every time you deploy a container the config needs to be modified and reloaded. By this time you might be looking at chef or puppet for automating the config generation.
Chef and puppet are not simple to learn. They have their own set of quirks (like unreliable tooling support on Windows). I'm in the process of conquering this, but I hope one day there will be a simpler way.
For non-Paas use cases (for example, a development server with a bunch of projects) I find schroot (1) simpler and more productive. For example, you can use the normal `service stop / service start` instead of writing manually init scripts, and you don't get stuck with sharing directories, which I found extremely tricky with Docker (for example, I couldn't start correctly mysql with supervisor sharing the mysql db directory). But Docker is in early development, so I think it will become easier in the future.
CoreOS experience designer here. I'm looking for testers to check out the general platform and test some of our new features. All skill levels are fine – new to docker & CoreOS, new to CoreOS only, etc. I'm happy to work with your schedule and make it as quick or involved as you're comfortable with. Anything from emailing a few thoughts to Skype to hanging out in our office in SF for the day.
Email: rob.szumski@coreos.com
I've been using docker for a couple of months, but we have only just begun experimenting with actual deployment in a test environment on ec2. Right now we use it primarily as configuration/dependency management. We're a small team and it seems to make setup easier, at least so far. Two examples: the first is a log sink container, in which we run redis + logstash. The container exposes the redis and es/kibana ports, and the run command maps these to the host instance. Setting up a new log server means launching an instance, and then pulling and starting the container. The second example is elasticsearch. We have a container set up to have cluster and host data injected into it by the run command, so we pull the container, start it, and it joins the designated cluster. The thing I like about this is the declarative specification of the dependencies, and the ease of spinning up a new instance. As I say, just experimenting so far, and I don't know how optimal all of this is yet, so would love any feedback.
One last quick thought on internal discovery. A method we're playing with on ec2 is to use tags. On startup a container can use a python script and boto to pull the list of running instances within a region that have certain tags and tag values. So we can tag an instance as an es cluster member, for example, and our indexer script can find all the running es nodes and choose one to connect to. We can use other tags to specify exposed ports and other information. Again, just messing around and still not sure of the optimal approach for our small group, but these are some interesting possibilities.
This is a copy and improvement of the article I wrote last month, even down to the breakdown of "What's that command doing?" with `docker run -t -i ubuntu /bin/bash`.
Glad it was useful enough to spur an improved article, at least.
http://tonyhb.com/unsuck-your-vagrant-developing-in-one-vm-w...
Can someone tell me what's the point of this? (I seriously love to know, not criticizing it.) Why would I need to have docker containers to install stuff on them instead of just installing stuff directly on host?
Let's say I develop a new web app, I would install NodeJS, PostgreSQL and such on my machine. Before I deploy the app for the first time, I'll install them in the necessary servers. Now, it looks like I would need to do the same, except adding the step of building Docker containers.
I think I must miss something important here because the number of GitHub stars for Docker is impressive and this is usually a good indication of the usefulness of the project.
> with Macintosh's kernel
I misread that as "Microsoft's..." and got excited since I run a build farm that's 70% windows and wish I could use docker but it's not worth having two systems (Container and VMs).
Also isn't that complete wrong? Macintosh is not an OS or company. It was one of Apple's product lines, long ago.
VM CAN share binaries/libs/etc (otherwise called files)
also, VMs CAN "share" memory. ie VMs can dedup memory between themselves. On Linux at least.
Not saying docker/lxc and all things namespaces are bad at all - but setting things straight. VMs can do this:)
Checkout KSM for memory "sharing" and any overlay-style file system that is mounted by VMs (this one works exactly the same as when you use namespaces/docker/lxc in fact)
Shouldn't "setting up a correct init process" be part of every "getting started with docker?" http://phusion.github.io/baseimage-docker/
I wish that people would stop writing tutorials on "getting started" with Docker, and actually start writing up examples of how to work with multiple containers, hosts, and linking.
That's the part that I (and I'm sure other beginners) get totally stuck on. Anyone can do docker commit/pull.
this is the first time I have heard of coreOS - seems to be custom built for containers like docker. are there downsides to doing system updates this way and not having a package manager, just relying on containers for everything? Seems great in concept.
Well good morning hackers.. This has been around for ages...
undefined
Would it be better to use FreeBSD and their Jails mechanism for all of this?