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 file
meta/container.yml in it, containing a sane default service configuration for adding
the container to
ansible/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 your
ansible/requirements.yml and modify your
ansible/main.yml to build and run the service 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 an
ansible/ directory, complete with
requirements.yml. It may even bundle its own roles in
refer to container-enabled roles on Galaxy using
requirements.yml. It can also include source code
files useful for developing your specific project, like a
Gulpfile.js or a
Container apps are best used by, in an empty project directory, running ansible-container init, adding the reference to the Galaxy-hosted container app you wish to 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.