Richard Bucker

major cloud-init weakness

Posted at — Sep 30, 2015

Now that you’ve wet your pants it’s not all that bad.I continue to deep dive into CoreOS, RancherOS, and Docker. I’ve also been testing ideas with both Google Compute Engine and Digital Ocean. And a lot of things have been going badly.The most recent hiccup was realizing that any changes to CoreOS’ configuration must be accompanied with a complete refresh of the nodes cloud-config file. While I have no experience with it I’m hoping that the enterprise CoreOS experience is better than my standalone.Doing a complete CoreOS refresh while there is volume sharing etc with the host means that the cloud-init is very complicated. My development machine is configured with both a Bosun and Grafana containers. And then there is my devbox. Since containers have been known to crash from time to time I am sharing a volume with the host. Only some of that is problematic.In some environments you might have multiple admins… and so the admin’s ssh keys would be installed in the cloud-config file. As a result the admin can login a little easier. There is an option to store a password too but that’s pretty much the same thing… The question is; what happens when that person leaves the organization? Is the OPS staff expected to redeploy every node having removed the credentials?This, of course, is not too big of a problem when the target server is behind a firewall such as GCE. But when you use Digital Ocean there is no firewall. You have to create your own iptables or firewall instance. Using a shared admin key is not an option either. Various compliance bodies expect that each user have their own creds.PS: if the preferred method for deploying users is cloud-config then that is the only way. Bypassing cloud-config would not be idempotent.