Ozznotes

This is a blog with random OpenStack and Linux related notes so I don't forget things. If you find something inaccurate or that could be fixed, please file a bug report here.

View on GitHub

Back to home

28 August 2018

Dissecting TripleO service templates (part 3)

by Juan Antonio Osorio Robles

In this series of blog posts, I’ve been covering all the different sections of the service templates for TripleO.

To recap:

This covers the sections that allow you to write a containerized service for TripleO.

Containerized services brought a big change to TripleO. From packaging puppet manifests and relying on them for configuration, we now have to package containers, make sure the configuration ends up in the container somehow, then run the containers. Here I won’t describe the whole workflow of how we containerized OpenStack services, but instead I’ll describe what you need to know to deploy a containerized service with TripleO.

Lets take a look at an example. Here’s the output section of the containerized etcd template in t-h-t:

outputs:
  role_data:
    description: Role data for the etcd role.
    value:
      service_name: {get_attr: [EtcdPuppetBase, role_data, service_name]}
      ...
      config_settings:
        map_merge:
          - {get_attr: [EtcdPuppetBase, role_data, config_settings]}
          - etcd::manage_service: false
      # BEGIN DOCKER SETTINGS
      puppet_config:
        config_volume: etcd
        config_image: &etcd_config_image {get_param: DockerEtcdConfigImage}
        step_config:
          list_join:
            - "\n"
            - - "['Etcd_key'].each |String $val| { noop_resource($val) }"
              - get_attr: [EtcdPuppetBase, role_data, step_config]
      kolla_config:
        /var/lib/kolla/config_files/etcd.json:
          command: /usr/bin/etcd --config-file /etc/etcd/etcd.yml
          config_files:
            - source: "/var/lib/kolla/config_files/src/*"
              dest: "/"
              merge: true
              preserve_properties: true
          permissions:
            - path: /var/lib/etcd
              owner: etcd:etcd
              recurse: true
      docker_config:
        step_2:
          etcd:
            image: {get_param: DockerEtcdImage}
            net: host
            privileged: false
            restart: always
            healthcheck:
              test: /openstack/healthcheck
            volumes:
              - /var/lib/etcd:/var/lib/etcd
              - /etc/localtime:/etc/localtime:ro
              - /var/lib/kolla/config_files/etcd.json:/var/lib/kolla/config_files/config.json:ro
              - /var/lib/config-data/puppet-generated/etcd/:/var/lib/kolla/config_files/src:ro
            environment:
              - KOLLA_CONFIG_STRATEGY=COPY_ALWAYS
      docker_puppet_tasks:
        # Etcd keys initialization occurs only on single node
        step_2:
          config_volume: 'etcd_init_tasks'
          puppet_tags: 'etcd_key'
          step_config:
            get_attr: [EtcdPuppetBase, role_data, step_config]
          config_image: *etcd_config_image
          volumes:
            - /var/lib/config-data/etcd/etc/etcd/:/etc/etcd:ro
            - /var/lib/etcd:/var/lib/etcd:ro
...

Here, we can already see some familiar sections:

After these, the rest are container-only sections. So lets describe them in more detail

puppet_config section

As I mentioned in a previous blog post, before getting into the steps where TripleO starts running services and containers, there is a step where puppet is ran in containers and all the needed configurations are created. The puppet_config section controls this step.

There are several options we can pass here:

One important thing to note is that, if you’re creating a containerized service, you don’t need to output a step_config section from the roles_data output. TripleO figured out if you’re creating a containerized service by checking for the existence of the docker_config section in the roles_data output.

kolla_config section

As you might know, TripleO uses kolla to build the container images. Kolla, however, not only provides the container definitions, but provides a rich framework to extend and configure your containers. Part of this is the fact that it provides an entry point that receives a configuration file, with which you can modify several things from the container on start-up. We take advantage of this in TripleO, and it’s exactly what the kolla_config represents.

For each container we create, we have a relevant kolla_config entry, with a mapping key that has the following format:

/var/lib/kolla/config_files/<container name>.json

This, contains YAML that represents how to map config files into the container. In the container, this typically ends up mapped as /var/lib/kolla/config_files/config.json which kolla will end up reading.

The typical configuration settings we use with this setting are the following:

docker_config section

This is the section where we tell TripleO what containers to start. Here, we explicitly write on which step to start which container. Steps are set as keys with the step_<step number> format. Inside these, we should set up keys with the specific container names. In our example, we’re running only the etcd container, so we use a key called etcd to give it such a name. A tool called paunch will read these parameters, and start the containers with those settings.

In our example, this is the container definition:

step_2:
  etcd:
    image: {get_param: DockerEtcdImage}
    net: host
    privileged: false
    restart: always
    healthcheck:
      test: /openstack/healthcheck
    volumes:
      - /var/lib/etcd:/var/lib/etcd
      - /etc/localtime:/etc/localtime:ro
      - /var/lib/kolla/config_files/etcd.json:/var/lib/kolla/config_files/config.json:ro
      - /var/lib/config-data/puppet-generated/etcd/:/var/lib/kolla/config_files/src:ro
    environment:
      - KOLLA_CONFIG_STRATEGY=COPY_ALWAYS

This is what we’re telling TripleO to do:

docker_puppet_tasks section

These are containerized puppet executions that are meant as bootstrapping tasks. They typically run on a “bootstrap node”, meaning, they only run on one relevant node in the cluster. And are meant for actions that you should only execute once. Examples of this are: creating keystone endpoints, creating keystone domains, creating the database users, etc.

The format for this is quite similar to the one described in puppet_config section, except for the fact that you can set several of these, and they also run as part of the steps (you can specify several of these, divided by the step_<step number> keys).

Conclusion

With these sections you can create service templates for your containerized services. If you plan to develop a containerized service, I suggest you also read the guide on the containerized deployment from the TripleO documentation.

With this, we have covered all the need-to-know sections for you to be effective with TripleO templates. There are still several other sections which you can take use of. I’ll cover the rest in a subsequent blog post.

tags: tripleo - openstack

Back to home