How Instance images are made

If you are a Scaleway user, you are probably familiar with this selection box on the console:

This is where you select which Operating System image you will be using to start your Instance. You will find a similar selection for our InstantApps:

This article explains the lifecycle of images and how they are built and tested.

Our build process is based upon standard Scaleway features. You will find the high level technical steps used to create our images in the document How to create an image from a snapshot.

Building an Operating System Image

In building an Operating System (OS) image, our goal is to stay as close as possible to official distributions. All our images are built using the official cloud images to achieve this. Some of our sources of official images are:

• ArchLinux: https://mirror.pkgbuild.com/images/latest/
• Ubuntu: https://cloud-images.ubuntu.com/
• Debian: https://cloud.debian.org/images/cloud/
• Centos: https://cloud.centos.org/centos/8/x86\_64/images/

The Qemu Copy-On-Write 2 (QCOW2) image is fetched from those websites, and a few minimal modifications are made to comply with specific Scaleway requirements. For instance, the CentOS 8 image is not natively booted with the UEFI bootloader, so the image is modified to add this functionality. Previously, images were built using an extract from official Docker images. But this proved to be problematic, container images are not identical to official cloud images, and modifications are made by Docker that do not apply in a QEMU/KVM virtualization context. So we changed our approach, and decided to use the official image from the distributions.
These official images are only slightly modified to make them work on Scaleway. For instance, we add a custom package called scaleway-ecosystem that brings most of the Scaleway specific customizations on all images. This package is updated from time to time to get new features when required by product launches. This was the case when our VPC product was released.

The content of this package is publicly available at those locations:

• Debian based package: https://launchpad.net/~scaleway/+archive/ubuntu/stable
• RPM-based package: https://github.com/scaleway/scaleway-packages/releases

To keep a new image that has never been booted, we use a library called libguestfs which gives us an extensive set of commands to modify the official image. Since the image is not booted, a no-log file or boot artifact is present upon its first boot.

Other modifications of the image may include:

• Kernel upgrades to enable features not natively available (Secure Encrypted Virtualization SEV)
• SELinux relabeling
• Cloud-init version upgrades

Once the customization of the QCOW2 file is completed, it is uploaded to the Scaleway infrastructure as a new image.

Building an InstantApp image

The InstantApp building process is quite similar to building an OS image. Most of the time, it uses the building process of the Ubuntu Focal image as a basis.

Then, additional steps are added to customize the image for its specific purpose. For a WordPress image, the additional steps are:

• Install additional packages required to run WordPress
• Download and install the latest WordPress sources
• Run WordPress database initialization
• Add systemd units to start the WordPress stack
• Add the boot time WordPress configuration scripts

The customization of the OpenVPN image is even more straightforward, it is only a matter of installing:

• Openvpn
• Easy-RSA
• Iptables
• Curl
• Scaleway specific OpenVPN scripts

The rest of the build process remains the same.

Testing the new image

Once the image is available in the Scaleway infrastructure, it can run a set of basic tests to confirm that the image may be usable. Our test set is in constant evolution, but currently, our basic set of tests for O/S image are:

• Archive
• Backup
• Block volume
• Cold snapshot
• DNS
• Hot snapshot
• Network
• Reboot
• Rescue
• Security group
• Stop in place
• Basic Private Networks functionalities

After completing all of those tests, we are pretty confident that the new image will be usable by our customers. This set of tests is done for each new image in every Availability Zone (AZ).

Releasing new images

Our goal at Scaleway is to release updated images every three months for the complete set of images. This represents the most extensive time interval between two updates possible as, often, other elements may trigger image updates, such as:

• The release of a new product that requires updated images
• A security vulnerability mitigation
• The release of new upstream OS images
• A new Availability Zone

Images lifecycle

Our OS images remain available and supported under the same terms with the upstream distributors. Once they become end-of-life upstream, they will also be deprecated on the Scaleway platform after a predefined grace period. Deprecation of those images is announced to our customers via email.

Once deprecated, images will no longer be available to start new Instances. Existing Instances will continue to work even if an image is no longer available.

Request your own feature

The Instances image ecosystem is constantly evolving, and we are working hard to stay up to date with the latest version of existing images, to keep adding new releases for the list of existing distributions, and to enlarge our portfolio of available images. If you have suggestions for new images or InstantApp, please add them to our feature request list.