Container Linux is designed to be updated automatically with different schedules per channel. You can disable this feature, although we don't recommend it. Read the release notes for specific features and bug fixes.
The Exoscale Container Linux image is built officially and each instance deployment is a unique fresh instance. By default, only the stable channel is deployed on Exoscale, you can easily switch to Beta or Alpha channel.
Unlike other providers, all Exoscale instances are protected by default on inbound traffic. In order to be able to work in a Container Linux cluster you should add the following rules in either your default security group or a security group of your choice and tag all Container Linux instances with it:
Container Linux allows you to configure machine parameters, launch systemd units on startup, and more via cloud-config. Jump over to the docs to learn about the supported features. Cloud-config is intended to bring up a cluster of machines into a minimal useful state and ideally shouldn't be used to configure anything that isn't standard across many hosts. Once the machine is created, cloud-config cannot be modified.
You can provide raw cloud-config data to Container Linux via the Exoscale portal or via the Exoscale compute API.
In order to leverage Container Linux unique automation attributes, a standard CoreOS cloud-config on Exoscale could be configured with:
#cloud-config coreos: etcd2: # generate a new token for each unique cluster from https://discovery.etcd.io/new?size=3 # specify the initial size of your cluster with ?size=X discovery: https://discovery.etcd.io/<token> advertise-client-urls: http://$public_ipv4:2379,http://$private_ipv4:4001 initial-advertise-peer-urls: http://$public_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://$public_ipv4:2380 units: - name: etcd2.service command: start - name: fleet.service command: start
To add more instances to the cluster, just launch more with the same cloud-config adjusting the FQDN or removing the statement. New instances will join the cluster regardless of location provided that security groups are correctly configured.
It is possible to modify the cloud-config contents during the lifetime of an instance. In order to modify the contents, you need to use the API command
updateVirtualMachine with the machine in a stopped state.
cs stopVirtualMachine id=<UUID of instance> cs updateVirtualMachine id=<UUID of instance> userData=<base64 encoded value of your cloud-config> cs startVirtualMachine id=<UUID of instance>
note: switch the request type from GET to POST if the userData payload is longer than 2KB.
Container Linux does not allow root connection to the instance. By default, it uses the
core user instead of
root and doesn't use a password for authentication. You'll need to add an SSH key(s) via the web console or add keys/passwords via your cloud-config in order to log in.
To log in to a Container Linux instance after it's created click on its IP address or run:
ssh core@<ip address>
Install and configure the command line client (Python required) with your API details.
pip install cs vi $HOME/.cloudstack.ini [cloudstack] endpoint = https://api.exoscale.ch/compute key = api key secret = secret
To launch a Small 2GB instance with the current Stable Container Linux image:
note: template ids are available on the Exoscale website.
cs deployVirtualMachine templateId=2a196b89-0c50-4400-9d42-ef43bcc0fa99 serviceOfferingId=21624abb-764e-4def-81d7-9fc54b5957fb zoneId=1128bd56-b4d9-4ac6-a7b9-c715b187ce11 keyPair=[keypair name]
Unlike other Exoscale images where the root password is randomly set at startup, Container Linux does not have password logon activated. You will need to configure your public key with Exoscale in order to login to the Container Linux instances or to specify external keys using cloud-config.