How to Cluster Applications Using CoreOS, Docker, etcd & confd (multipart series)
Without spending too much time on the reasoning inherent, replicating applications in the cloud is the devops thing of the time. Doing so requires intelligent packaging, some automated deployment and service discovery.
The concepts and technologies are simple in themselves, but their consequences are often overlooked. So, the “yet another framework in two easy clicks” syndrome leads to procedural tutorials which fail to bring the crucial operative point across.
In the following posts I hope to redress parts of that situation. I will not spare you the theories behind. Stumbling along workflow-driven tutorials rather obscures the point. I hope that clustering applications in cloud settings will become more clear by mixing theory with practice in that process.
The aim will be to have cluster of operating systems, to deploy applications thereon and to auto-discover apps in a load-balancing mechanism.
Setting Up a CoreOS Cluster
In the first post I will explain how to use CoreOS and etcd to setup an arbitrary number of (virtualized) CoreOS instances. These computers form a cluster, i.e., they know about their cluster membership and communicate their own state using a shared key-value store dedicated to storing cluster state.
Extensive tutorials already exist. Besides their lamentable lack of theory, they aim to procedurally guide the reader to build something “workable” too soon and mix separate concepts in that process. They thus unnecessarily loose clarity, which will nastily bite many users later on.
Provisioning Applications on CoreOS Clusters
The second post will focus on how to package applications so that they are usable with CoreOS built-ins. Again, tutorials are extensive, but focus only on the special case of using publicly available package repositories, which may bite users as the advance later on.
Service auto-discovery or conversely service auto-registration is most often delegated to special case tutorials - it is integral IMHO and must not be left for later. This is (again IMHO) the weakest point in existing documentation. Therefore, I did not defer that to an (initially planned) third post.
Suggestions for Building, Packaging and Continuous Deployment (WIP)
When dealing with a setup as above sketched, certain principles in the chain of building, packaging and deploying a preferable to others as I will detail in my last post .