The previous provisioning scheme had issues with updates. Because,
configuration was already part of the base bootstrap, providing an
update meant creating a new image.
The key insight in this new provisioning scheme is to treat config
files used by our code as something that can always be regenerated
on demand. Every update kills the config and recreates it all over.
Current flow is thus:
1. bootstrap init code starts up install/server.js. This server merely
listens for provision and restore calls.
2. The installer calls install.sh. This script simply checks out the
requested revision. Note that the installer is from what is in the
base image. Changing the installer requires a new base image. If a
restore url is provided, this downloads the restore data.
3. The install.sh calls postinstall.sh of the requested revision.
It setups the code calling npm install, migrates any data and creates
configs - collectd, graphite, nginx etc. This also creates cloudron.conf.
Because postinstall.sh is from requested revision, all the data, configs
are all based on the requested revision.
Note that installation of new packages should be done at base image creation
time.
The changes also provide separation of announce and hearbeat calls:
- announce is for cloudron coming up and installer running
- heartbeat is for box server running
TODO:
appstore url is only part of image becase installer needs to announce.
This can be fixed by moving to user metadata
Fixes#110
Girish Ramakrishnan
779c9c1392