Deploying SUSE Linux Micro in Public Clouds
- WHAT?
This article provides details about the SUSE Linux Micro images intended for deployment in public clouds. On top of that, it also provides information on creating new users of the system.
- WHY?
You want to learn about the specifics of the SUSE Linux Micro images for public clouds.
- EFFORT
It takes up to 10 minute to read the article.
1 About SUSE Linux Micro in public clouds #
SUSE Linux Micro is a lightweight and secure operating system that can be deployed into clouds of several vendors (for example, AWS, Microsoft Azure, Google Cloud).
The generic information about public cloud images is provided in the Public Cloud Guide. There you can find subscription plans, image lifecycle, information regarding support, and so on.
SUSE Linux Micro creates its own internal snapshots that are not related nor can interfere with the external snapshots of the disk. External snapshots can be created using the cloud framework tools for backup purposes or for making new images. For details about SUSE Linux Micro snapshots, refer to SUSE Linux Micro snapshotting.
2 Deployment of SUSE Linux Micro images to public clouds #
2.1 Required and recommended disk size #
The root volume is set to the size specified by the cloud vendors, for example, 10 GB in AWS and GCE and 30 GB in Azure.
The recommended size for SUSE Linux Micro is 12 GB. However, the size depends on the number and size of workloads you intend to run.
As with almost each change of the root file system, a new snapshot is created. Keep in mind that these snapshots also take up some size, even though Btrfs snapshots are space-efficient.
The root volume automatically grows as you change the size of the underlying disk. When you are running low on disk space, you can always stop your instance and increase the size of the system disk, up to the limitation of individual disk sizes in each cloud framework.
2.2 Deploying SUSE Linux Micro images into public clouds #
The following procedure summarizes the deployment and post-deployment of the SUSE Linux Micro image.
Deploy the image to the public cloud. The specific procedure differs depending on particular cloud vendors. Refer to the particular documentation for details.
The image comes with a default initial configuration that might not suit your needs. For example, you want to add another user on top of the default user. To change this configuration, proceed as described in Section 2.2.1, “Modifying the default configuration”.
Register the system as described in Section 2.2.2, “Registration”.
You may want to create different users from the running system. For a procedure of doing so, refer to Section 2.3, “Adding users with the
useradd
command”.
2.2.1 Modifying the default configuration #
The default configuration is stored in
/usr/lib/ignition/base.d/base.ign
that is a part of
the read-only file system. Therefore, direct changes to this file are not
allowed. To modify this file, perform the following steps:
Remove the flag file
/boot/writable/firstboot_happened
.Run the following command:
#
transactional-update shell
Edit the
/usr/lib/ignition/base.d/base.ign
file to suit your needs. Here you can also add other users of the system, repartition the system and so on.The file is read by Ignition during the next boot. Ignition reconfigures the system according to the instructions in the file. For details about the Ignition configuration, refer to Ignition configuration examples.
Exit the
transactional-update
shell by enteringexit
.As Ignition runs in the
initramfs
, you need to rebuild it by running the command:#
transactional-update initrd
To grant the newly created user access rights using the SSH key provided by the cloud framework, ensure that the following
systemd
service is started:#
systemctl start afterburn-sshkeys@USER_NAME
Reboot the system.
Keep in mind that the SSH key that is used to start the SUSE Linux Micro instance and passed using the instance metadata service will be set up for the default user suse.
2.2.2 Registration #
After you deploy the image, you need to register the system. In newer
images, you can use the registercloudguest
command to
register the system. For details, refer to the
Public
Cloud Guide.
Alternatively, you can register your system as described in SUSE Linux Micro registration.
2.2.3 Tools involved in initializing SUSE Linux Micro in public clouds #
SUSE Linux Micro images use tools that run on the first boot. The tools (Ignition or Combustion) configure the system according to a provided set of instructions. However, in the SUSE Linux Micro images for public cloud deployment, there is only Ignition by default. That said, you may use Combustion too, but you need to proceed as described in Section 2.2.3.1, “Using Combustion in deployment in public clouds”. Additionally, Afterburn is also used when deploying SUSE Linux Micro in public clouds.
In the default Ignition configuration, Ignition is responsible for
creating the default user: suse
. Ignition interacts
with the instance metadata service of the cloud provider only to get the
so-called user data. Other data, like the user specified in Azure or the
SSH key from the GCE, are not parsed from this metadata service.
Afterburn writes the SSH key to the suse
home directory
using the instance metadata service (IMDS). To transfer the SSH key from
the IMDS, the afterburn-sshkeys@suse
is used. The
service is started automatically by systemd
.
Ignition runs on the first boot only. To distinguish the first boot from
succeeding boots, the flag file
/boot/writable/firstboot_happened
is created. Whenever
you want to trigger Ignition again, you need to remove this file.
The default Ignition configuration is stored in the configuration file:
/usr/lib/ignition/base.d/base.ign
. You can modify this
file to perform configuration changes. For details, refer to
Section 2.2.1, “Modifying the default configuration”.
2.2.3.1 Using Combustion in deployment in public clouds #
To configure your instance with Combustion, you need to create a separate disk in the cloud framework. The disk must have the required directory structure as described here. Then you need to create an instance with this configuration disk attached. If the use of Combustion is needed for integration into your environment, you can build your own images using keg and keg-recipes. The keg-recipes project contains the image description used by SUSE to build the images we publish. For details, refer to keg-recipes.
2.3 Adding users with the useradd
command #
You can use the useradd
command to add users to an
already running system. However, as SUSE Linux Micro is Btrfs-based, the
/home
directory is mounted as a subvolume. Therefore,
you must use the useradd
command accordingly.
To add a regular user without sudo
privileges, proceed
as described below:
Run the
useradd
command as follows:#
useradd --btrfs-subvolume-home --create-home USER_NAME
The
--btrfs-subvolume-home
option denotes that the/home
directory is mounted as a subvolume. The--create-home
option creates the/home
under the particular subvolume. If you omit these options, the/home
directory for the particular user will not be created.Set a password for the new user:
#
passwd USER_NAME
To give the new user sudo
privileges, add the user to
the wheel
group:
#
usermod -aG wheel USER_NAME
3 Legal Notice #
Copyright© 2006–2024 SUSE LLC and contributors. All rights reserved.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”.
For SUSE trademarks, see https://www.suse.com/company/legal/. All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its affiliates. Asterisks (*) denote third-party trademarks.
All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors, nor the translators shall be held liable for possible errors or the consequences thereof.