[KaiserPro]

docker and openVZ aim to do the same thing.

docker is a glorified chroot and cgroup wrapper.

There is also a library of prebuilt docker images (think of it as a tar of a chroot) and a library of automated build instructions.

The library is the most compelling part of docker. everything else is basically a question of preference.

You will hear a lot about build once, deploy anywhere. whilst true in theory, your mileage will vary.

what docker is currently good for:

o micro-services that talk on a messaging queue

o supporting a dev environment

o build system hosts

However if you wish to assign ip addresses to each service, docker is not really mature enough for that. Yes its possible, but not very nice. You're better off looking at KVM or vmware.

There is also no easy hot migration. So there is no real solution for HA clustering of non-HA images. (once again possible, but not without lots of lifting, Vmware provides it with a couple of clicks.)

Basically docker is an attempt at creating a traditional unix mainframe system (not that this was the intention) A large lump of processors and storage that is controlled by a singular CPU scheduler.

However, true HA clustering isn't easy. Fleet et al force the application to deal with hardware failures, whereas Vmware and KVm handle it in the hypervisor.

[ageofwant]

> docker and openVZ aim to do the same thing.

docker is a process container not a system container.

> docker is a glorified chroot and cgroup wrapper.

that is fairly immaterial, suffice to say that the underlying linux core tech that enables docker has matured enough lately to enable a tool like docker. I built many containers and I never thought about them in terms of the underlying tech.

> There is also a library of prebuilt docker images (think of it as a tar of a chroot)

yes

> and a library of automated build instructions

more accurate to say there is a well defined SDL for defining containers.

> You will hear a lot about build once, deploy anywhere. whilst true in theory, your mileage will vary.

have to agree, this is oversold as most of the config lives in attached volumes and needs to be managed outside of the container.

> However if you wish to assign ip addresses to each service, docker is not really mature enough for that. Yes its possible, but not very nice. You're better off looking at KVM or vmware.

Have to disagree here, primarily because each service should live in each own container, docker is a process container, not a system container. Assemble a system out of several containers, don't mash it all up into one - most people don't seem to get this about docker.

> There is also no easy hot migration. So there is no real solution for HA clustering of non-HA images. (once again possible, but not without lots of lifting, Vmware provides it with a couple of clicks.)

None is required. Containers are ephemeral and generally don't need to be migrated, they are simply destroyed and started where needed. Requiring 'hot migration' in the docker universe generally means you are doing it wrong. Not to say that there is no place for that.

As a final note, all my docker hosts are kvm vm's.

[KaiserPro]

edit this sounds like I'm being petty, I apologise, I'm just typing fast.

> docker is a process container not a system container.

Valid. However the difference between docker image and openVZ images is the inclusion of an init system.

> Have to disagree here, primarily because each service should live in each own container, docker is a process container, not a system container. Assemble a system out of several containers, don't mash it all up into one - most people don't seem to get this about docker.

I understand your point,

I much prefer each service having an IP that is registered to DNS. This means that I can hit up service.datacenter.company.com and get a valid service. (using well tested dns load balancing and health checks to remove or re-order individual nodes)

Its wonderfully transparent and doesn't require a special custom service discovery in both the client and service. because like etcd it has the concept of scope you can find local instances trivially. using DCHP you can say connect servicename and let dhcpd set your scope for you.

> None is required. Containers are ephemeral and generally don't need to be migrated, they are simply destroyed and started where needed. Requiring 'hot migration' in the docker universe generally means you are doing it wrong. Not to say that there is no place for that.

This I have to disagree with you. For front end type applications, ones that hold no state, you are correct.

However for anything that requires shared state, or data its a bad thing. Take your standard database cluster ([no]SQL or whatever) of 5 machines. You are running at 80% capacity, and one of your hosts is starting to get overloaded. You can kill a node, start up a warm node on a fresh machine.

However now you are running at 100% capacity, and you now need to take some bandwidth to bring up a node to get back to 80%. Running extra machines for the purpose of allowing CPU load balancing aggrieves me.

I'm not advocating writing apps that cannot be restarted gracefully. I'm also not arguing against ephemeral containers, its more a case of easy load balancing, and disaster migration. Hot migration means that software is genuinely decoupled from the hardware.

[hosh]

> However the difference between docker image and openVZ images is the inclusion of an init system.

No it isn't. Most people don't use an init system with Docker images. However, one of the top-10 popular images uses one -- the Passenger Phusion base images. They make a pretty compelling argument why you should.

None of these arguments are relevant in the big picture. Where Docker shines is the package management, not the virtualization. As a package management system, it is brilliant -- though incomplete. The package management could be fully content-addressable, and at which point, we'll have something more brilliant than what it is now. But it isn't, and I doubt anyone will try it until after this core concept gets adopted into the mainstream.

Ten years ago in 2005, I've heard these same types of arguments about cloud providers, the Zen hypervisors, and the AWS API. I've seen old mainframe folks rolling their eyes saying the technology is old, and this is hyped up. Of course it's hyped up; but unless you can look past the hype and your contempt, you won't see what's really there. No one is really arguing about cloud technology now, and the hold-outs are outnumbered by the majority.

[dalyons]

> I much prefer each service having an IP that is registered to DNS. This means that I can hit up service.datacenter.company.com and get a valid service. (using well tested dns load balancing and health checks to remove or re-order individual nodes)

There are docker-backed service management tools that will automatically this for you(assign public/private dns per service cluster inc load balancing), like Empire https://github.com/remind101/empire

[rahimnathwani]

"Assemble a system out of several containers, don't mash it all up into one - most people don't seem to get this about docker."

Care to elaborate on this? Do you use the linking system described here? https://docs.docker.com/userguide/dockerlinks/

I mean, your various containers still communicate over IP, right? Just a private IP network within the host, rather than outside?

(Obviously I've never used Docker.)

[juliangregorian]

Yes, except each container has it's own isolated network and explicitly exposes a port that linked containers can listen to. In development I think a lot of people just use --net=host so that all the containers share the host networking stack (at least, I do).

[cpr]

The OP just means don't put everything into one container.

[joesmo]

"However if you wish to assign ip addresses to each service, docker is not really mature enough for that. Yes its possible, but not very nice. You're better off looking at KVM or vmware."

I don't understand. If you can't assign IPs to each service (or it's difficult/unreliable to do so) how can processes talk to each other and the outside world?

[FireBeyond]

Host / port mapping, service discovery via things like docker-discover, docker-register, or Consul, etc.

[geggam]

Its messy

[JustSomeNobody]

On OpenVZ, I can edit /etc/network/interfaces for each CT and can assign a static IP, for one example. Can I not do that for Docker? Sorry if this is naive, I don't know much of anything about Docker.

[mugsie]

no, for many reasons:

You should have no way to login to the docker container

Dockers networking does not allow that for that IP to be visable.

[JustSomeNobody]

Ok, thank you for clearing that up for me.