Configuring and managing cloud-init for RHEL

• Flexible and fine-grained allocation of resources

  A cloud instance of RHEL runs as a VM on a cloud platform, which means a cluster of remote servers maintained by the cloud service provider. Therefore, on the software level, allocating hardware resources to the instance is easily customizable, such as a specific type of CPU or storage.

  In comparison to a local RHEL system, you are also not limited by the capabilities of physical host. Instead, you can choose from a variety of features, based on selections offered by the cloud provider.

• Space and cost efficiency

  You do not need to own any on-premise servers to host cloud workloads. This avoids the space, power, and maintenance requirements associated with physical hardware.

  Instead, on public cloud platforms, you pay the cloud provider directly for using a cloud instance. The cost is typically based on the hardware allocated to the instance and the time you spend using it. Therefore, you can optimize your costs based on your requirements.

• Software-controlled configurations

  The entire configuration of a cloud instance is saved as data on the cloud platform, and is controlled by software. Therefore, you can easily create, remove, clone, or migrate the instance. A cloud instance is also operated remotely in a cloud provider console and is connected to remote storage by default.

  In addition, you can back up the current state of a cloud instance as a snapshot at any time. Afterwards, you can load the snapshot to restore the instance to the saved state.

• Separation from the host and software compatibility

  Similarly to a local VM, the RHEL guest operating system on a cloud instance runs on a virtualized kernel. This kernel is separate from the host operating system and from the client system that you use to connect to the instance.

  Therefore, any operating system can be installed on the cloud instance. This means that on a RHEL public cloud instance, you can run RHEL-specific applications that cannot be used on your local operating system.

  In addition, even if the operating system of the instance becomes unstable or is compromised, your client system is not affected in any way.

• Deploying public cloud instances is very effective for flexibly increasing and decreasing the active computing power of your deployments, also known as scaling up and scaling down. Therefore, using RHEL on public cloud is recommended in the following scenarios:

  • Clusters with high peak workloads and low general performance requirements. Scaling up and down based on your demands can be highly efficient in terms of resource costs.
  • Quickly setting up or expanding your clusters. This avoids high upfront costs of setting up local servers.
• Cloud instances are not affected by what happens in your local environment. Therefore, you can use them for backup and disaster recovery.

• You are running an existing environment that cannot be adjusted. Customizing a cloud instance to fit the specific needs of an existing deployment may not be cost-effective in comparison with your current host platform.
• You are operating with a hard limit on your budget. Maintaining your deployment in a local data center typically provides less flexibility but more control over the maximum resource costs than the public cloud does.

Next steps

• Obtaining RHEL for public cloud deployments

• Instead of private orchestration interfaces, public cloud instances use provider-specific console interfaces for managing your cloud resources.
• Certain features, such as nested virtualization, may not work correctly. If a specific feature is critical for your deployment, check the feature’s compatibility in advance with your chosen public cloud provider.

• Your public cloud provider is responsible for the security of the cloud hypervisor
• Red Hat provides the security features of the RHEL guest operating systems in your instances
• You manage the specific security settings and practices in your cloud infrastructure

• To create the system image, you can use the RHEL image builder or you can build the image manually.
• This method uses your existing RHEL subscription, and is also referred to as bring your own subscription (BYOS).
• You pre-pay a yearly subscription, and you can use your Red Hat customer discount.
• Your customer service is provided by Red Hat.
• For creating multiple images effectively, you can use the cloud-init tool.

• You post-pay an hourly rate for using the service. Therefore, this method is also referred to as pay as you go (PAYG).
• Your customer service is provided by the cloud platform provider.

• The cloud.cfg file includes directives for various system configurations, such as user access, authentication, and system information.

  The file also includes default and optional modules for cloud-init. These modules execute in order in the following phases: .. The cloud-init initialization phase .. The configuration phase .. The final phase.

  + In the cloud.cfg file, the modules for the three phases are listed under cloud_init_modules, cloud_config_modules, and cloud_final_modules respectively.

• You can add additional directives for cloud-init in the cloud.cfg.d directory. When adding directives to the cloud.cfg.d directory, you need to add them to a custom file named *.cfg, and always include #cloud-config at the top of the file.

• Per instance means that the module runs on first boot of an instance. For example, if you clone an instance or create a new instance from a saved image, the modules designated as per instance run again.
• Per once means that the module runs only once. For example, if you clone an instance or create a new instance from a saved image, the modules designated per once do not run again on those instances.
• Per always means the module runs on every boot.

• User data includes directives you specify in the cloud.cfg file and in the cloud.cfg.d directory, for example, user data can include files to run, packages to install, and shell scripts. Refer to the cloud-init Documentation section User-Data Formats for information about the types of user data that cloud-init allows.
• Metadata includes data associated with a specific datasource, for example, metadata can include a server name and instance ID. If you are using a specific cloud platform, the platform determines where your instances find user data and metadata. Your platform may require that you add metadata and user data to an HTTP service; in this case, when cloud-init runs it consumes metadata and user data from the HTTP service.

• Vendor data is optionally provided by the organization (for example, a cloud provider) and includes information that can customize the image to better fit the environment where the image runs. cloud-init acts upon optional vendor data and user data after it reads any metadata and initializes the system. By default, vendor data runs on the first boot. You can disable vendor data execution.

  Refer to the cloud-init Documentation section Instance Metadata for a description of metadata; Datasources for a list of datasources; and Vendor Data for more information about vendor data.