what can I install on the host CoreOS that will survive an update?

Question

In it's alpha state, CoreOS, will periodically update itself. If I'm installing apps and tools on the CoreOS host OS ... updating the /etc/ folder and so on. What can I expect after the next upgrade?

It might be better to ask what is the idiomatic way to install apps and tools on the CoreOS host OS so that they survive an update?

Another example: There are some tools I might like to install on the host like 'gear' or 'docker-yen'. Both are available in source form and so I'd need to compile them. I suppose a Dockerfile would be the ideal way to go in order to compile and export. But is it?

Answer 1

I'll answer the easiest part first: If you want to install tools like 'gear' or 'docker-yen' you would do that by creating docker images for these tools and deploying them as containers. You would probably want to create systemd unit files that describe how to start and stop these containers. Also, if you want the tools to always be available the best option is to define these systemd units in a cloud config meta-data file that is loaded when each coreos instance boots up. But yes, you are correct that creating a Dockerfile is probably the starting point if docker images do not yet exist for 'gear' or 'docker-yen'.

As far as updating /etc. I believe this recently changed. /etc is no longer read-only and therefore you are safe to modify any files in this path. They will persist across reboots since coreos auto updates only affect the read-only partitions (as far as I know). So for example, all the docker stuff which is stored in /var/lib/docker will survive auto updates. I generally deploy everything as docker containers to survive auto updates.

As far as configuration data goes, the best way to ensure it survives updates is to setup your cluster to use the etcd key/value store. This is included in the example cloud config file by default. Coreos also includes a tool called fleet that uses etcd in this way. You can use fleet to schedule systemd unit deployments. This allows your services to be available when machines go down for auto updating since another machine will pickup the scheduling job as defined in etcd.