Newly deployed cloud servers usually require some steps to setup. Everyone has their own list of things to go through from adding new user accounts to running updates and installing common applications. With Initialization scripts you can automate the tasks you would otherwise perform again and again when booting up a new host.

Initalization scripts management list

Adding scripts

You can manage your scripts with the Initialization scripts feature at your UpCloud Control Panel under the Servers menu. Click the New initialization script button at the top of the page to open the editor window.

Script edit window

Copy any pre-existing script you might have into the Content text field, or write a new script straight in the browser. Name your scripts so that you can easily distinguish between them. Once you are done, click the Accept button at the bottom to save the changes.

Deploying with a script

The Initialization scripts are supported by all of the public Linux templates, after selecting your distribution and any SSH keys you may wish to use, open the Miscellaneous Server Settings by clicking the Show button. At the bottom of the section, you can find an option to select between your previously saved init scripts.

Selecting a script at deployment

Selecting one of your stored scripts will bring it to the edit field below. You can make any last-minute changes to the script still before deployment, or you can write a completely new script right on the spot. Once you are done making changes, click the Deploy server button as usual. The server will perform the actions dictated by the script during the first boot up saving your considerable time and effort.

Testing new initialization scripts is also easy thanks to the extremely fast deployment to any of the UpCloud availability zones. If your script didn’t perform as expected, you can always delete the server and deploy it again. Iterating your scripts will let you fine tune the tasks at boot up and be running again within seconds.

Writing scripts

Initialization scripts support anything a regular Linux shell script would.  Depending on your choice of distribution, the default shell might use different implementations, but the principles remain the same. Below is an example of how to have the server automatically run the update and upgrade routines as also seen in the picture above.

#!/bin/bash
# Run the commands in a noninteractive mode
export DEBIAN_FRONTEND=noninteractive
# Update source list and log the output to file
apt-get update > /tmp/init-script.log
# Upgrade available software packages with default options when available
apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" -y upgrade >> /temp/init-script.log

CoreOS has its own initialization script format using a setup file cloud-config. A program called coreos-cloudinit reads the config file at boot, which allows a new node to e.g. be automatically discovered and connected to a cluster.

#cloud-config
coreos:
  etcd2:
    # generate a new token for each new cluster from https://discovery.etcd.io/new?size=3
    discovery: "https://discovery.etcd.io/<token>"
    # multi-region and multi-cloud deployments need to use $public_ipv4
    advertise-client-urls: "http://$public_ipv4:2379"
    initial-advertise-peer-urls: "http://$private_ipv4:2380"
    # listen on both the official ports and the legacy ports
    # legacy ports can be omitted if your application doesn't depend on them
    listen-client-urls: "http://0.0.0.0:2379,http://0.0.0.0:4001"
    listen-peer-urls: "http://$private_ipv4:2380,http://$private_ipv4:7001"
  fleet:
    public-ip: $public_ipv4"
    metadata: region=fi"
users:
  - name: "elroy"
    passwd: "$6$5s2u6/jR$un0AvWnqilcgaNB3Mkxd5yYv6mTlWfOoCYHZmfi3LDKVltj.E8XNKEcwWm..."
    groups:
      - "sudo"
      - "docker"
    ssh-authorized-keys:
      - "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0g+ZTxC7weoIJLUafOgrm+h..."

It is also possible to enter a URL in an initialization script. If the script contains an address, the deployment process will attempt to fetch a file and use it instead. This allows greater flexibility including dynamically updating the initialization script between deployments.