By Piotr Wachowicz | July 05, 2016 |
Our blog smackdown between containerization and virtualization is rolling along. Today’s post looks at image formats.
If you’re a new reader, join us for our “wrestling match” – a friendly contest between Taras Shapovalov, (team container) Piotr Wachowicz (team VM). The battle royal includes:
Taras – Let’s begin today with a discussion of image formats. Nowadays, container images all follow the same standardized format developed by Docker Inc. and The Open Container Initiative participants. This single format means that a container image created once can be used anywhere – making container images extremely portable.
Let’s contrast that with virtual machine (VM) images, which have many formats, including RAW, ISO, QCOW2, VDI, QED, and VMDK, among others. This plethora of image formats confuses users and makes it much more difficult to distribute and run the same image in different places.
Piotr – That is true, but then again OpenStack doesn’t really care which image format you use. Everything about OpenStack is pretty much modular, in the sense that there’s one OpenStack, which can be plugged with a whole variety of different drivers.
The same cannot be said of the container world right now. Should you go with Docker or Singularity image format? Which storage driver you should use for Docker containers? What about using Docker .dab files (Distributed Application Bundles are introduced in Docker 1.12)? CoreOS and Rocket? Or maybe LXD, or systemd-nspawn? Once you start betting on which containers to go with, you also have to decide which (often incompatible), container system to place your bet on. The choice is important for many reasons, but specifically because each of those container solutions has its own ideas on what a proper container networking model should look like. In fact, you would not be far off if you said that the only thing all the container systems have in common is that none has figured out how to properly solve the networking problem!
Taras – I beg to differ with you on container incompatibility. I believe the issue was partially solved with the founding of the Open Container Initiative organization
under the auspices of the Linux Foundation. The Open Container Initiative’s goal is to develop a set of open industry standards around container formats and runtime. The initiative is supported by many well-known world IT organizations. Docker is donating its container format and runtime, so some standards are based on the Docker technologies (and are compatible with them). If we consider networking requirements, then I would say this is not a big problem, because there are a lot of tools to create virtual networks that can also be used in the virtualization world.
Piotr – OpenStack clouds, on the other hand, are pretty mature, and will be equally happy to work with any VM image format, and even with multiple different hypervisors within the same cloud. That makes it easy to consolidate your existing cloud environments into OpenStack. The VM networking layer was solved a few years ago, with the advent of OpenStack Neutron, which offers a self-service group of elaborate networking constructs, like virtual routers, virtual firewalls, and virtual load balancers, and of course virtual (isolated) IPv4 and IPv6 subnets. This empowers the users to create complex networking environments.
Last, but not least, OpenStack can also deploy Docker containers, using the Magnum OpenStack component. It is true that Magnum is still in the midst of solving the networking piece of the container puzzle, but once solved in OpenStack, Magnum will provide/offer seamless integration with the already existing, above-mentioned, networking constructs like routers, firewalls and virtual networks. This will make OpenStack an amazing environment for containers to thrive in, as well as interact and integrate with VMs and the rest of the infrastructure.
Personally, I would like to see the container community join forces with the OpenStack community. Docker, sooner or later, will need to to (re-)invent solutions for the same usual sets of the problem: a GUI dashboard, authorization/authentication, image store, storage drivers for different vendors, and networking, among many others. It makes perfect sense to team up and make use of what OpenStack is already offering in those areas. I think of it as coding on the shoulders of giants. In fact, I was pleased to see last year’s announcement about Google, the major force behind Kubernetes, heavily contributing to OpenStack Magnum.
Taras – In fact, Docker developers have already started to create a GUI dashboard, which they call Docker Universal Control Plane, although it does not look as powerful as OpenStack Horizon, at least for now. Authorization/authentication in such tools as Docker and Kubernetes is good enough, but of course without built-in multi-tenancy and user roles, they lose the competition compared to tools like OpenStack.
Image storage, storage drivers and networking are solved with 3rd party software like Ceph (as a backend for Docker Registry, which we integrate with since Bright Cluster Manager 7.3) or OVS. But I agree that OpenStack services can replace orchestration tools like Docker, Kubernetes, or Swarm in the future.
Right now, I’d say that OpenStack works on a higher level than either Kubernetes or Swarm. OpenStack Magnum allows you to run containerized clusters, but it does so by using one of the orchestration tools, rather than managing containers by itself. While this does allow you to create container-plus-OpenStack integration relatively quickly, it also adds a new layer of complexity and dependency. On balance I am not sure that the Magnum approach is the best choice.
I will agree with one point you made: that one day OpenStack may become a standard orchestration tool for containers. I agree that the containerization community should be working more closely with the OpenStack community.
Join us again soon for Round 5 – Application sharing