Docker cons

Published: Fri 31 October 2014
By Sirex

In Linux.

I believe docker is a really great tech, and it'll really change things, but i see nothing but hype on the blog-o-sphere... So here's some brief notes about some of the lesser spoken about aspects of docker - the cons.

  • Shared state outside the container is an issue where upgrades are done via new image + container culling. You don't for instance get the opportunity at 'upgrade' time to upgrade any data to work with the new version of packages on the image. This may be an issue for things which alter their stored formats over time and would historically have migrated the data in place at upgrade (database schema for instance).
  • There needs to be a proxy layer in the network stack between container and host to achieve long running container based network services, i.e: gantryd or something as-yet-unexisting using HA proxy to drain network connections off the old container before migrating over. This also implies multiple containers will be running doing the task for a while, so it needs to support some degree of parallelism.
  • While virtual machines abstract the entire platform, docker only abstracts the process (or role of related processes). This means that while virtual machines can be managed in the same way as a physical machine, containers need a different level of granularity to manage them. This is commonly called 'image sprawl' - currently there is a lot of work on this issue, but no real solutions just yet.
  • Inter-host networking is still in its infancy. Its not well defined how to migrate containers either live, or in a HA failover capacity. Things like weave look promising here.

Taking all that into account, it's my view that at this time containers are best used where there is a discrete unit of work (cron jobs, continuous integration testing) or as a quick dev environment. There needs to solutions to most / all of the above before I'd consider using it in a more widespread fashion

blogroll

social