Today we’re announcing the official release of cloud-init deployed on our On-Prem virtual appliances.
The entire setup is fully Open Source under the permissive MIT license, and can be used/tweaked by anyone as they see fit.
For those unfamiliar with cloud-init, it’s a tool installed on the appliance which allows it to be configured with certain settings on boot. The settings are not pre-baked into the VM, but rather fetched from the VM’s host (ex: EC2, VMware, Proxmox, MaaS, etc). They can be obtained in the form of a removable drive (ex: /dev/sr0), or from a “Metadata URL” such as http://169.254.169.254/.
Pre-configured settings are fine for defaults, but there has always been a need to provide additional settings such as NTP, network, DNS, storage, apitoken, before the VM is first booted. That’s where cloud-init comes in. It allows a true zero-touch deployment of On-Prem appliances on various on-prem AND cloud providers.
Unfortunately with TinyCore Linux and an immutable OS, that “feature” has always been impossible to implement, until now.
The changes we’ve implemented for cloud-init to work on our appliances only add a few MB (~3.8MiB) to the size of the appliance, and require an ugrade from Python v2.7 to Python v3.
We add a system overlay into the TinyCore Linux rootfs, along with 3 new extensions (and their dependencies) which are loaded on boot:
The /opt/bootsync.sh will run cloud-init and then try to setup networking through /opt/network.sh, which is simply calling cloud-init once more with different arguments. The reason for this is to provide backward compatibility for existing On-Prem TinyCore deployments.
Note: If there is no usage of the network.tcz, jidoteki-admin.tcz, or jidoteki-admin-api.tcz extensions, /opt/network.sh can be removed from /opt/bootsync.sh and replaced with:
/usr/local/bin/cloud-init modules --mode config
Each step in the cloud-init runs can be found in /etc/cloud/cloud.cfg.
The config modules are bootcmd which are the actual Shell scripts found in /etc/cloud/scripts.
Customizations can and should be added to custom.sh and custom-once.sh. If it’s not immediately obvious, the once.sh and custom-once.sh scripts will only run once per boot. Unlike typical cloud-init installations, the once scripts will run again on reboot (because the OS is immutable).
The Shell scripts provided for this cloud-init deployment will read settings from various files on the system, including any userdata or vendordata provided to the system.
The order of precendence for reading configuration values are:
/opt/.filetool.lst/var/lib/cloud/instance/user-data.txt/var/lib/cloud/seed/nocloud-net/vendor-dataNote: Metadata is only currently used by cloud-init to configure SSH public-keys. All other metadata is ignored, but still accessible to applications running on the TinyCore Linux appliance.
Userdata
Tested with EC2, Proxmox, and NoCloud, the userdata will be discovered by cloud-init and read directly from /var/lib/cloud/instance/user-data.txt. From testing, it appears cloud-init handles Base64 decoding of userdata automatically provided by EC2.
Note: Userdata is not parsed by cloud-init, but rather read manually by various Shell scripts. This means it is not possible for userdata to overwrite values from /etc/cloud/cloud.cfg, and it is not possible to provide userdata which contains a shell script or other malicious features. Userdata should only contain key: value pairs.
Vendordata
The vendor-data is added to the /var/lib/cloud/seed/nocloud-net/ directory on the rootfs. It is also possible to add a network-config (v1 config) to that directory for pre-configuring the network.
Note: Similar to userdata, the vendor-data is not parsed by cloud-init and should only contain key: value pairs (except for network-config, which is parsed by cloud-init’s net-convert tool).
For more information, please see the README.md from our Open Soure repository.
We’re hoping to add cloud-init to all our customer appliances in the coming month, so all their customers can benefit from the advantages cloud-init provides.
As usual, feel free to contact us and let us know your requirements. We’ll be more than happy to help modernize existing apps by deploying them as part of a well-designed on-premises virtual appliance (OVA).