Kubernetes ConfigMaps Compared To Docker Swarm Configs

This article is part of the series that compare Kubernetes and Docker Swarm features.

The mechanisms behind Kubernetes ConfigMaps and Docker Swarm configs are almost the same. At least, from the functional perspective. Both allow us to store some literal texts in scheduler’s internal data store, and both enable us to add them to containers. The syntax is equally simple and straightforward in both cases. Still, there are a few differences.

Docker Swarm’s Config is immutable. We cannot enter into a container and remove it. We cannot update it. All we can do is read it. Kubernetes will allow us to manipulate injected configuration files, only to revert changes soon after. It is acting like a cleaning lady. You can create any mess you want, she’ll clean it up. Or, maybe, that would be a butler? Not sure… Anyways, Kubernetes ConfigMap mounts are eventually immutable. Such a thing is not a big deal. We just need to understand how it works and to learn never to touch configuration files. Or, even better, we should change the default mount’s permissions to be read-only.

All in all, Docker’s Config is immutable by design. Kubernetes ConfigMap’s mounts are eventually immutable. If only Kubernetes made the default value of defaultMode set to 0444

Docker is good at preventing people from doing silly things (the politically correct version of the word stupid). An example would be an attempt to delete a configuration. It cannot be deleted if there are Docker services with reference to to the configuration. Only after all the services that reference it are removed, we are allowed to remove the configuration source. Kubernetes, on the other hand, will let us delete a ConfigMap object without even a hint about the consequences.

Kubernetes ConfigMap, on the other hand, provides a wider variety of options. While Docker Swarm configuration can be created only from a file or stdin, Kubernetes equivalent can be generated from a file, from a directory, from a literal value, and from files with environment variables. Each of those sources can be used multiple times. We can even combine them. Further on, Kubernetes ConfigMaps can be converted not only to files, but also to environment variables. Flexibility and extra functionalities are available both at the source and the destination end-points.

Docker Swarm wins a user experience point. Kubernetes gains a star for providing more choices. Neither has a significant difference that would warrant a win, so I’m proclaiming it a tie.

There are many more features worthwhile comparing. We’re not yet finished. Stay tuned for more.

The DevOps 2.3 Toolkit: Kubernetes

The article you just read is an extract from The DevOps 2.3 Toolkit: Kubernetes. The book is still under development. If you buy it now from LeanPub.com, you’ll receive updates for each new chapter that is added.

Give the book a try and let me know what you think.

Advertisements

7 thoughts on “Kubernetes ConfigMaps Compared To Docker Swarm Configs

  1. Pingback: Kubernetes Pods, ReplicaSets, And Services Compared To Docker Swarm Stacks | Technology Conversations

  2. Pingback: Kubernetes Deployments Compared To Docker Swarm Stacks | Technology Conversations

  3. Pingback: Kubernetes Ingress Compared To Docker Swarm Equivalent | Technology Conversations

    1. Viktor Farcic Post author

      I did write

      “Kubernetes ConfigMap, on the other hand, provides a wider variety of options. While Docker Swarm configuration can be created only from a file or stdin, Kubernetes equivalent can be generated from a file, from a directory, from a literal value, and from files with environment variables. Each of those sources can be used multiple times. We can even combine them. Further on, Kubernetes ConfigMaps can be converted not only to files, but also to environment variables. Flexibility and extra functionalities are available both at the source and the destination end-points.”

      I didn’t want to add Vault to the mix since the article focuses on what is available “out of the box” or maintained by the community. I’ll probably write about Vault separately.

      Reply
  4. Pingback: Kubernetes Secrets Compared To Docker Swarm Secrets | Technology Conversations

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s