Abstract
| Goal | Configure and deploy a typical multitier cloud application stack, defined as an architected template of scalable VM instances, including per-instance launch customizations. |
| Objectives |
|
| Sections |
|
| Lab |
Automating a Customized Cloud Application Launch |
After completing this section, you should be able to configure an instance with run time customizations performed at launch.
Cloud-init is software that handles the early initialization of an instance. It is included in the rhel-guest-image RPM package, which is the base image provided by Red Hat. Administrators can use cloud-init to perform a range of tasks, some of which are described below.
Setting a default locale. This can be dynamic rather than being preconfigured into the image.
Updating the instance host name.
Generating or injecting SSH private keys to allow passwordless login.
Setting up ephemeral mount points. Shared storage is a common requirement for horizontally scaled applications.
You can invoke cloud-init with user-data, which is data provided by the user when an instance is launched. The provided instructions are read and parsed by cloud-init in order to customize the instance. OpenStack also implements instance management via cloud-init. Users can launch an instance in the Dashboard and use the tab to specify the customization to apply.
OpenStack converts the information into a format that cloud-init can read. The following chart shows the user-data flow, starting with the initial configuration to the resulting instance customization.
Cloud-init contains support for several data formats, making it more flexible.
user-data scripts are a convenient way for domain operators to send a set of instructions to the instance upon its creation. The script is invoked at the rc.local level, which is last in the boot process. The following example changes the message of the day, using a Bash script:
#!/bin/bash echo "This instance has been customized by cloud-init at $(date -R)!" >> /etc/motd
As an alternative to using customization scripts, domain operators can specify customization in cloud-config syntax, which provides instructions in a human-friendly format. These instructions include:
Updating the system using yum on first boot, which prevents the exposure of an instance that may not have the latest security updates installed.
Adding a new Yum repository allows access to different packages depending on the role of the instance.
Importing SSH keys, which removes the requirement for password-based logins and prevents brute-force attacks from succeeding.
Creating users, which may be required for third-party agents, such as backup or monitoring.
The file must be a valid YAML file for it to be parsed and executed by cloud-init.
The following example shows how to customize the system by adding a group that includes users, adding a new user, and running a set of commands.
#cloud-config
groups:
- cloud-users: [john,doe]
users:
- default
- name: operator
gecos: Domain Operator
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users, admin
ssh-import-id: None
lock-passwd: true
ssh-authorized-keys:
- <SSH public key>
runcmd:
- [ wget, "http://materials.example.com", -O, /tmp/index.html ]
- [ sh, -xc, "echo $(date) ': hello world!'" ]After the instances have been spawned, administrators can ensure the cloud-init instructions were successfully executed. Customization can include:
Installing a package.
Removing a package.
Updating the system.
Creating users or groups.
Retrieving a file.
For example, review /var/log/cloud-init.log to confirm that cloud-init ran.
[user@demo ~]$sudo less /var/log/cloud-init.log... Jul 19 01:53:05 host-192-168-1-5 cloud-init: Cloud-init v. 0.7.6finishedat Sun, 19 Jul 2020 06:53:05 +0000. Datasource DataSourceOpenStack [net,ver=2]. Up 88.48 seconds
In the /etc/passwd file, verify that the nagios user was created.
[user@demo ~]$ grep nagios /etc/passwd
...
nagios:x:903:903::/home/nagios:/bin/bashUse ps -ef to ensure that the httpd services are running.
[user@demo ~]$ ps -ef | grep httpd
root 1204 1 0 04:38 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1205 1204 0 04:38 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1206 1204 0 04:38 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1207 1204 0 04:38 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1208 1204 0 04:38 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 1209 1204 0 04:38 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
cloud-u+ 1258 1237 0 04:40 pts/0 00:00:00 grep --color=auto httpdUse the systemctl command to ensure that the httpd service is active and enabled.
[user@demo ~]$systemctl status httpd.service● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service;enabled; vendor preset: disabled) Active:active(running) since Sun 2020-07-19 04:38:38 EDT; 2min 26s ago Docs: man:httpd(8) man:apachectl(8) Main PID: 1204 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─1204 /usr/sbin/httpd -DFOREGROUND ├─1205 /usr/sbin/httpd -DFOREGROUND ├─1206 /usr/sbin/httpd -DFOREGROUND ├─1207 /usr/sbin/httpd -DFOREGROUND ├─1208 /usr/sbin/httpd -DFOREGROUND └─1209 /usr/sbin/httpd -DFOREGROUND ...output omitted...
Further information on cloud-init is available at https://cloudinit.readthedocs.io