Ansible Galaxy is the public commons for Ansible roles, and it now includes support for container-enabled roles and container app skeletons.
Since container best-practices center around one process/service per container, and since Ansible roles generally encompass a single function, there’s a natural harmony between them. Container-enabled roles are normal Ansible roles that integrate easily with an Ansible Container project.
A container-enabled role is one that defines a containerizable service. It contains a files
meta/container.yml in it, containing a sane default service configuration for adding the container to a project’s
container.yml. While these files are named the same, the
container.yml in a container-enabled role only contains the service definition, not the rest of a complete
container.yml, much the same way that other files in an Ansible role are a subset of a complete playbook.
Container-enabled roles are best added to your project using the ansible-container install command, which will add the role to the project’s
requirements.yml, and modify
container.yml to include the service defined by the role.
While container-enabled roles work well for bolt-on services, they do not work well for multi-container orchestration; a role can only truly define a single container service.
Ansible Galaxy also hosts container apps, which are skeletons of complete Ansible Container projects, useful for bootstrapping new projects. For example, a single web-page application talking to a JBoss backend would need a node.js server to compile static assets, a JBoss application server, and one or more databases like MySQL or MongoDB - at least three containers, orchestrated together. A container app provides the skeleton to get started with these sorts of stacks.
A container app is not a role. It contains a
container.yml, and may even bundle its own roles in
roles/, or refer to container-enabled roles on Galaxy using
requirements.yml. It can also include source code file useful for developing your specific project, like a
Gulpfile.js or a
Container apps are best used in an empty project directory by running ansible-container init, and adding the reference to the Galaxy-hosted container app you wish to download and use.
Not all roles are container-enabled roles, but that doesn’t mean you can’t use them with Ansible Container. If a role provides configuration and tuning (for example SELinux configuration, firewall configuration, etc.), it can be used with Ansible Container all the same. However non-container-enabled roles that configure services will likely need modification before being useful with Ansible Container, as containerized services require a fundamentally different approach versus hardware virtualization or bare-metal services.
To make retrofitting existing roles into the container build process easier, Ansible Container sets
ANSIBLE_CONTAINER=1 in the environment of the Conductor and the target service container during
build. Use this to add conditional checks on tasks that should not be executed in the context of a container.