Este contenido no está disponible en el idioma seleccionado.
Chapter 19. Managing containers by using RHEL system roles
With the podman RHEL system role, you can manage Podman configuration, containers, and systemd services that run Podman containers.
19.1. Creating a rootless container with bind mount by using the podman RHEL system role Copiar enlaceEnlace copiado en el portapapeles!
You can use the podman RHEL system role to create rootless containers with bind mount by running an Ansible playbook and with that, manage your application configuration.
The example Ansible playbook starts two Kubernetes pods: one for a database and another for a web application. The database pod configuration is specified in the playbook, while the web application pod is defined in an external YAML file.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them. -
The user and group
webappexist, and must be listed in the/etc/subuidand/etc/subgidfiles on the host.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the example playbook include the following:
run_as_userandrun_as_group- Specify that containers are rootless.
kube_file_contentContains a Kubernetes YAML file defining the first container named
db. You can generate the Kubernetes YAML file by using thepodman kube generatecommand.-
The
dbcontainer is based on thequay.io/db/db:stablecontainer image. -
The
dbbind mount maps the/var/lib/dbdirectory on the host to the/var/lib/dbdirectory in the container. TheZflag labels the content with a private unshared label, therefore, only thedbcontainer can access the content.
-
The
kube_file_src: <path>-
Defines the second container. The content of the
/path/to/webapp.ymlfile on the controller node will be copied to thekube_filefield on the managed node. volumes: <list>-
A YAML list to define the source of the data to provide in one or more containers. For example, a local disk on the host (
hostPath) or other disk device. volumeMounts: <list>- A YAML list to define the destination where the individual container will mount a given volume.
podman_create_host_directories: true-
Creates the directory on the host. This instructs the role to check the kube specification for
hostPathvolumes and create those directories on the host. If you need more control over the ownership and permissions, usepodman_host_directories.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.podman/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
$ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook --ask-vault-pass ~/playbook.yml
$ ansible-playbook --ask-vault-pass ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2. Creating a rootful container with Podman volume by using the podman RHEL system role Copiar enlaceEnlace copiado en el portapapeles!
You can use the podman RHEL system role to create a rootful container with a Podman volume by running an Ansible playbook and with that, manage your application configuration.
The example Ansible playbook deploys a Kubernetes pod named ubi8-httpd running an HTTP server container from the registry.access.redhat.com/ubi8/httpd-24 image. The container’s web content is mounted from a persistent volume named ubi8-html-volume. By default, the podman role creates rootful containers.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them.
Procedure
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The settings specified in the example playbook include the following:
kube_file_contentContains a Kubernetes YAML file defining the first container named
db. You can generate the Kubernetes YAML file by using thepodman kube generatecommand.-
The
ubi8-httpdcontainer is based on theregistry.access.redhat.com/ubi8/httpd-24container image. -
The
ubi8-html-volumemaps the/var/www/htmldirectory on the host to the container. TheZflag labels the content with a private unshared label, therefore, only theubi8-httpdcontainer can access the content. -
The pod mounts the existing persistent volume named
ubi8-html-volumewith the mount path/var/www/html.
-
The
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.podman/README.mdfile on the control node.Validate the playbook syntax:
ansible-playbook --syntax-check ~/playbook.yml
$ ansible-playbook --syntax-check ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook ~/playbook.yml
$ ansible-playbook ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3. Creating a Quadlet application with secrets by using the podman RHEL system role Copiar enlaceEnlace copiado en el portapapeles!
You can use the podman RHEL system role to create a Quadlet application with secrets by running an Ansible playbook.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions on them. -
The certificate and the corresponding private key that the web server in the container should use are stored in the
~/certificate.pemand~/key.pemfiles.
Procedure
Display the contents of the certificate and private key files:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow You require this information in a later step.
Store your sensitive variables in an encrypted file:
Create the vault:
ansible-vault create ~/vault.yml
$ ansible-vault create ~/vault.yml New Vault password: <vault_password> Confirm New Vault password: <vault_password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow After the
ansible-vault createcommand opens an editor, enter the sensitive data in the<key>: <value>format:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ensure that all lines in the
certificateandkeyvariables start with two spaces.- Save the changes, and close the editor. Ansible encrypts the data in the vault.
Create a playbook file, for example,
~/playbook.yml, with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The procedure creates a WordPress content management system paired with a MySQL database. The
podman_quadlet_specs rolevariable defines a set of configurations for the Quadlet, which refers to a group of containers or services that work together in a certain way. It includes the following specifications:-
The Wordpress network is defined by the
quadlet-demonetwork unit. -
The volume configuration for MySQL container is defined by the
file_src: quadlet-demo-mysql.volumefield. -
The
template_src: quadlet-demo-mysql.container.j2field is used to generate a configuration for the MySQL container. -
Two YAML files follow:
file_src: envoy-proxy-configmap.ymlandfile_src: quadlet-demo.yml. Note that .yml is not a valid Quadlet unit type, therefore these files will just be copied and not processed as a Quadlet specification. -
The Wordpress and envoy proxy containers and configuration are defined by the
file_src: quadlet-demo.kubefield. The kube unit refers to the previous YAML files in the[Kube]section asYaml=quadlet-demo.ymlandConfigMap=envoy-proxy-configmap.yml.
-
The Wordpress network is defined by the
Validate the playbook syntax:
ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml
$ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
ansible-playbook --ask-vault-pass ~/playbook.yml
$ ansible-playbook --ask-vault-pass ~/playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow