How to Cluster Applications Using CoreOS, Docker, etcd & confd (multipart series)
February 8, 2016. 417 words.
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 postSetting Up A CoreOS Cluster. 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 postProvisioning Applications on CoreOS Clusters. 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.
Dealing with Home Lab Special Cases
In addition, it may be helpful to adapt workflows slightly to deal with the usually slow networking conditions of home labs, which I have detailed as an addendumHow to Split Docker Images for Slow Networking Connections. .