OpenStack Docs: Role - tripleo_container

Role Documentation¶

Welcome to the “tripleo_container_manage” role documentation.

Role Defaults¶

This section highlights all of the defaults and variables set within the “tripleo_container_manage” role.

# All variables intended for modification should place placed in this file.
tripleo_container_manage_hide_sensitive_logs: '{{ hide_sensitive_logs | default(true)
  }}'
tripleo_container_manage_debug: '{{ ((ansible_verbosity | int) >= 2) | bool }}'
tripleo_container_manage_clean_orphans: true

# All variables within this role should have a prefix of "tripleo_container_manage"
tripleo_container_manage_check_puppet_config: false
tripleo_container_manage_cli: podman
tripleo_container_manage_concurrency: 1
tripleo_container_manage_config: /var/lib/tripleo-config/
tripleo_container_manage_config_id: tripleo
tripleo_container_manage_config_overrides: {}
tripleo_container_manage_config_patterns: '*.json'
# Some containers where Puppet is run, can take up to 10 minutes to finish
# in slow environments.
tripleo_container_manage_create_retries: 120
# Default delay is 5s so 120 retries makes a timeout of 10 minutes which is
# what we have observed a necessary value for nova and neutron db-sync execs.
tripleo_container_manage_exec_retries: 120
tripleo_container_manage_healthcheck_disabled: false
tripleo_container_manage_log_path: /var/log/containers/stdouts
tripleo_container_manage_systemd_order: false
tripleo_container_manage_systemd_teardown: true
tripleo_container_manage_valid_exit_code: []

Molecule Scenarios¶

Molecule is being used to test the “tripleo_container_manage” role. The following section highlights the drivers in service and provides an example playbook showing how the role is leveraged.

Driver: delegated

Usage¶

Note that right now, only Podman is supported by this role. Docker support is in the roadmap though.

This Ansible role allows to do the following tasks:

Collect container configs data, generated by TripleO Heat Templates. This data is used as a source of truth on which configuration we expect to apply with this role. It means that if a container is already managed by this role, no matter its state now, the configs data will reconfigure the container if needed.
Manage systemd shutdown files. It takes care of cleaning up the Paunch services and files and create the TripleO Container systemd service, required for service ordering when it comes to shutdown or start a node. It also manages the netns-placeholder service.
Delete containers that aren’t needed anymore or that will need to be re-configured. It uses a custom filter, named needs_delete() which has a set of rules which allow to determine if whether or not the container needs to be deleted. These reasons will make the containers not deleted:
- The container is not managed by tripleo_ansible.
- The container config_id doesn’t match with the one in input.
Once the previous conditions checked, then these reasons will make the containers deleted:
- The container has no config_data.
- The container has a config_data which doesn’t match the one in input.
Note that when a container is removed, the role also disable and remove the systemd services and healtchecks if present.
Create containers in a specific order defined by start_order container config, where default is 0.
- If the container is an exec, we’ll run a dedicated playbook for execs, using async so multiple execs can be run at the same time.
- Otherwise, the podman_container is used, in async, to create the containers. If the container has a restart policy, we’ll configure the systemd service. If the container has a healthcheck script, we’ll configure the systemd healthcheck service.
Note: tripleo_container_manage_concurrency parameter is set to 1 by default, and putting higher value than 2 can be expose issue with Podman locks. If a container is meant to exit after running a script (defined in EntryPoint), we can check its return code and fail if the code isn’t expected. It can be done with tripleo_container_manage_valid_exit_code. If defined to a list of integers, the role will wait for the container to be exited and then checks the return code.

Here is an example of a playbook:

- name: Manage step_1 containers using tripleo-ansible
  block:
    - name: "Manage containers for step 1 with tripleo-ansible"
      include_role:
        name: tripleo_container_manage
      vars:
        tripleo_container_manage_systemd_order: true
        tripleo_container_manage_config: "/var/lib/tripleo-config/container-startup-config/step_1"
        tripleo_container_manage_config_id: "tripleo_step1"

Roles variables¶

Name	Default Value	Description
tripleo_container_manage_cli	podman	Container CLI
tripleo_container_manage_concurrency	1	Number of containers managed at same time
tripleo_container_manage_config	/var/lib/tripleo-config/	Container config path
tripleo_container_manage_config_id	tripleo	Config ID
tripleo_container_manage_config_patterns	*.json	Bash REGEX to find configs
tripleo_container_manage_debug	false	Debug toggle
tripleo_container_manage_healthcheck_disable	false	Allow to disable Healthchecks
tripleo_container_manage_log_path	/var/log/containers/stdouts	Containers stdouts path
tripleo_container_manage_systemd_order	false	Manage systemd shutdown ordering
tripleo_container_manage_config_overrides	{}	Allows to override any container configuration
tripleo_container_manage_clean_orphans	true	Option to clean orphans
tripleo_container_manage_valid_exit_code	[]	Allow to check if a container returned the exit code in parameter. Must be a list. e.g. [0,3]

Healthchecks¶

Previously, the container healthcheck was implemented by a systemd timer which would run podman exec to determine if a given container was healthy.. Now, we are using the native healthcheck interface in Podman; which is easier to integrate and consume.

We are now using the native healthcheck interface in Podman; which is easier to integrate with and consume.

To check if a container (e.g. keystone) is healthy, run the following command:

$ sudo podman healthcheck run keystone

The return code should be 0 and “healthy” should be printed as the output. One can also use the podman inspect keystone output to figure out that the healthcheck is periodically running and healthy:

"Healthcheck": {
    "Status": "healthy",
    "FailingStreak": 0,
    "Log": [
        {
            "Start": "2020-04-14T18:48:57.272180578Z",
            "End": "2020-04-14T18:48:57.806659104Z",
            "ExitCode": 0,
            "Output": ""
        },
        (...)
    ]
}

Debug¶

The role allows you to perform specific actions on a given container. This can be used to:

Run a container with a specific one-off configuration.
Output the container commands that are run to to manage containers lifecycle.
Output the changes that would have been made on containers by Ansible.

Note

To manage a single container, you need to know 2 things:

At which step the container is deployed.
The name of the generated JSON file for container config.

Here is an example of a playbook to manage HAproxy container at step 1 which overrides the image setting in one-off.

- hosts: localhost
  become: true
  tasks:
    - name: Manage step_1 containers using tripleo-ansible
      block:
        - name: "Manage HAproxy container at step 1 with tripleo-ansible"
          include_role:
            name: tripleo_container_manage
          vars:
            tripleo_container_manage_systemd_order: true
            tripleo_container_manage_config_patterns: 'haproxy.json'
            tripleo_container_manage_config: "/var/lib/tripleo-config/container-startup-config/step_1"
            tripleo_container_manage_config_id: "tripleo_step1"
            tripleo_container_manage_clean_orphans: false
            tripleo_container_manage_config_overrides:
              haproxy:
                image: docker.io/tripleomaster/centos-binary-haproxy:hotfix

If Ansible is run in check mode, no container will be removed nor created, however at the end of the playbook a list of commands will be displayed to show what would have been run. This is useful for debug purposes, as it was something that one could do with paunch debug command.

$ ansible-playbook haproxy.yaml --check

Adding the diff mode will output the changes what would have been made on containers by Ansible.

$ ansible-playbook haproxy.yaml --check --diff

The tripleo_container_manage_clean_orphans parameter is optional and can be set to false to not clean orphaned containers for a config_id. It can be used to manage a single container without impacting other running containers with same config_id.

The tripleo_container_manage_config_overrides parameter is optional and can be used to override a specific container attribute like the image or the container user. The parameter takes a dictionary where each key is the container name and its parameters that we want to override. These parameters have to exist and are the ones that define the container configuration in TripleO Heat Templates. Note that it doesn’t write down the overrides in the JSON file so if an update / upgrade is executed, the container will be re-configured with the configuration that is in the JSON file.

Role - tripleo_container_manage

Role - tripleo_container_manage¶

Role Documentation¶

Role Defaults¶

Molecule Scenarios¶

Scenario: default¶

Molecule Options¶

Molecule Inventory¶

Example default playbook¶

Usage¶

Roles variables¶

Healthchecks¶

Debug¶

tripleo-ansible 2.4.1.dev24

Page Contents