[chubot]

Just curious, how are people building Docker images these days? Doesn't it only run on 64-bit Linux? I have a 32 bit Linux desktop and a Mac and haven't gotten around to installing Docker. At work I have a 64 bit Linux desktop and it seemed to be extremely picky about the kernel version so I gave up.

Are people running Linux VMs on their Macs to build containers?

I like the idea of this service. But both the client side and the server side have to be easy. Unless I'm missing something it seems like they made the server side really easy, but the client side is still annoying.

[Lazare]

Yes. Emerging best practices seems to be to use Vagrant to create a great development environment, then use docker containers inside that for isolation. The two work together quite well. There's a comment from the Vagrant creator here about that: https://news.ycombinator.com/item?id=6291549

In short, yes, just run a VM.

[chubot]

So I already use Linux almost exclusively for development, and VMs are not in my workflow at all. It seems bizarre to build a VM to build a container! Like too many levels of yak shaving.

[Lazare]

> It seems bizarre to build a VM to build a container! Like too many levels of yak shaving.

Perhaps, but you just said:

> I have a 32 bit Linux desktop and a Mac and haven't gotten around to installing Docker. At work I have a 64 bit Linux desktop and it seemed to be extremely picky about the kernel version so I gave up.

Precisely. Hence VMs, because Vagrant makes it trivial to spin up an instance configured however you like.

You're basically saying "I have a problem installing Docker, but I don't need a VM because I don't have any problems a VM would solve", but this is nonsense because this is the precise problem development VMs are meant to solve.

[chubot]

I can see where you're coming from, but my issue is that Docker itself is LESS portable than the applications it's containerizing! It's creating the very problem it's trying to solve. The task I care about isn't to build and deploy a Docker container. It's to build and deploy my app.

I have a beef with build/deploy systems that have bootstrapping problems. For example I'm hearing from people using Chef that they have to freeze the version of Chef, its dependencies, and the Ruby interpreter (or maybe it was Puppet, I don't use either). To me that is just crazy. My code isn't that picky about the versions it needs, and to introduce a deployment tool like that makes things less stable, not more.

Take for example Python -- in my experience it's almost entirely portable because Linux and Mac. And I imagine the same is with node.js, Ruby, PHP, etc. Almost all C libraries you need are portable too. So in my ideal world you would only use a VM when you actually need it for the OS/CPU architecture. I suspect for a lot of people that would be 50-90% the time without a VM, depending on how you like to develop.

I'm working on a chroot-based build system, which in theory will work on Mac and Linux (but not Windows). It does need to solve a versioning problem. Because stuff isn't as portable between Python 2.6 and Python 2.7 on the same OS as it is between Python 2.7 on two different architectures/OSes.

[Lazare]

I think it might depend on what sort of problem you're trying to solve.

If you have, let's say, a django app, and you want to be able to run it all sorts of places, Docker is very much the wrong tool; it doesn't run at all most places, and it's finicky to get working. You're better off just getting that one app to run when and where you want. And if you run into any issues, virtualenv will solve it, no big deal.

If you have a bunch of apps you want to get running (or perhaps a bunch of interlocking pieces of a single stack, or the different elements of a SOA), then Docker suddenly starts to look very attractive. And then you might go to the trouble to get a single gold server image with docker installed and working (or an Ansible playbook, or a Chef cookbook, or a Digitalocean snapshot, or an EC2 AMI, or whatever), and you know you can just spin up a server and deploy any app you want to it. And once you start thinking about testing, CI, orchestration, automatic scaling, etc., it all becomes that much more attractive; you've got these generic docker servers, on the one hand, and these generic docker containers on the other, and you can mix and match them however you like. When you start having more than 1 server and 1 app, that's amazing. Very much worth the cost of entry of having to install docker everywhere...if you need that kind of thing.

You're focusing on portability between operating systems, but that's not the point of docker; as you say docker isn't portable at all (which should be a strong hint that isn't the problem it solves). But docker containers are portable between servers with docker on it, and with some architectures (or at a certain scale), you will suddenly realise just how useful that is.

If it helps, consider Heroku (and the other PaaS outfits like dotCloud, etc.). A lot of startups outsource big chunks of their infrastructure to Heroku, and Heroku uses a very docker-like architecture. If you were to shift that back in house, in many cases that same architecture makes sense (largely depending on just what you were outsourcing to Heroku...). ...and sometimes it doesn't. But if it does, docker is probably a core part of any attempt at implementing your own in-house PaaS. And if you need that kind of thing, you aren't going to stop because "well, it doesn't run on OSX"; nobody (well, nearly) is using OSX is production. :)

[TheMakeA]

All of my projects now include a Vagrantfile. It makes managing dependencies and creating repeatable environments simple.

The work flow is:

  $ vagrant up
  $ vagrant ssh

Editing and committing changes take place on the host. Running servers, tests, building Docker containers, etc, takes place on the guest.

You can get a new device ready for hacking on a project in minutes. Just git clone, vagrant up, grab a quick coffee.

I would definitely recommend putting VMs in your work flow.

[shykes]

The dominant workflow in docker-land is to ditch the Vagrantfile, use a Dockerfile instead, and sometimes use Vagrant when it helps you get a VM up and running with docker on it (but that Vagrantfile is typically the same across all projects requiring docker).

[cryptolect]

I don't get the need for Vagrant? Are you suggesting to use Vagrant solely for those not developing on a host capable of running Docker? If my host _can_ run Docker, what value do I get from running it inside Vagrant instead?

[shykes]

We recommend using vagrant as a simple vm management tool, to quickly get a simple VM on your machine.

If your host can already run docker containers, you don't need vagrant.

[Lazare]

Vagrant is a useful way to very quickly get a Docker capable host. You wouldn't use it for production, no.

For development, if you're running on OS X or Windows (in which case, my condolences), you basically have to use a VM. If developing on Linux, it's a tossup; the complexity and overhead of Vagrant versus the pain and annoyance of fooling around with kernels and dependencies.

I use a Mac for day-to-day development, so a simple Vagrant VM is a no-brainer. :)

[dekz]

I'm building docker images on 64-bit linux (ubuntu) and maintaining a repo of Dockerfiles, instead of uploading to the docker repository.

You need a recent version of the linux kernel that supports Linux Containers. It's best if you can run Ubuntu 13 somewhere.

> Are people running Linux VMs on their Macs to build containers?

FreeBSD supports jails which are similar to linux containers in a way, but OSX does not. So unfortunately you're going to have to run a VM, checkout vagrant and docker though. [1]

[1]: http://docs.docker.io/en/latest/installation/vagrant/

[TheMakeA]

OSX has seatbelts[1], which is similar to jails. They are just clunky and not documented. Chrome uses them for sandboxing browser processes[2].

[1] https://developer.apple.com/library/mac/documentation/Darwin...

[2] http://www.chromium.org/developers/design-documents/sandbox/...

[wmf]

No amount of jails or seatbelts is going to allow you to run a Linux executable on a Darwin kernel, though.