This is just a coding style thing because bash gets all worked up
if we reuse these variable names in functions as local
example:
func() {
local VAR="value" # does not work even if this is local since VAR is readonly
echo "${VAR}"
}
readonly VAR="deal"
func
tar --list --verbose --file=box.tar now shows:
drwxr-xr-x girishra/staff 0 2015-01-17 16:57 ./
Without this change, mktemp was creating directories have no r,x for
others and group. This meant that nginx which was running www-user
was unable to access the website inside box code.
It takes arguments --image <image_id> or --code <source_code_url>
image_id is generated using scripts/createDigitalOceanImage.sh
source_code_url is generated using scripts/createSourceTarball.sh
The install server is now always started by the init script.
When started up, it determines it's mode based on the exitence
of box srcdir. If it does not exist, it starts an external
listening provision/restore server. Once the appstore, provisions
the box, it switches to update mode.
If the box srcdir does exist, the installer starts out in update mode.
In update mode, the server listens on localhost:2020. In this
mode, the web interface can ask it to update the box.
Fixes#115
* The base image contains only installer code. Installer code
can only be changed with a base image change
* The box code is download from s3 instead of git. The s3 tarball
consists of node dependancies already
Part of #115
This reuses the 'regions' argument to transfer the
new image to the list specified. The first entry is the
region, where the temporary droplet is being created.
eg. --regions="ams3 ny2 sfo1"
The image droplet is created in Amsterdam.
The script currently does not wait for all images to be
fully transferred, yet.
getopts - bash built-in that supports only short form
getopt - separate program and there are two variants - GNU and BSD. The BSD one
does not support long options.
The installer is run in provision-mode in the init script
The installer is run as update-mode by supervisor by postinstall
Previously, we used to run the *same* installer code, which was
part of the base image, in both modes. However, after a reboot,
the old installer code is 'gone' and thus we start running the
newer installer code. This distinction is very subtle and this change
makes it more obvious.
If we want the same installer code to run in both modes, then we
really need to split out installer into a separate repository. This
can be done if required later.
This also makes it clear that announce is a feature of the provision
mode.
The only reason not to use the metadata completely for provisioning
is because many VPS providers do not provide it.
If we rely on a metadata API, we can pretty much remove the installer
server
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
postinstall script is run automatically after npm install ends.
This create unnecessary confusion and we want to have more
control over when exactly the migration happens
The docker data as well as user (yellowtent) home is now btrfs.
This will greatly help us in backups. We simply take a btrfs
snapshot and back that up. This way we don't need to stop all
containers and simulates the same thing as a power outage.
Part of #108
Girish Ramakrishnan