Ansible Container 0.2.0 Release

We’re excited to announce the release of Ansible Container 0.2.0. The last few months have been exciting. We’ve been working at a fever pitch to add new features, build examples, and resolve issues, while at the same time we’ve seen the interest level and participation rate of the project steadily grow. It’s been amazing, and we’re grateful to all those that helped by opening issues, contributing code, and spreading the word. Thank you!

Throughout this release cycle we heard from a number of users that being able to reuse existing Ansible content was critical. We focused on that, making Ansible roles a key part of this release. We came up with several enhancements that make it easy to access existing Ansible roles during the container build process. We added a feature to assist in retrofitting existing roles to be ‘container aware' and we looked to the future and imagined new ways roles could enhance the process of building and sharing containers.

Accessing Existing Roles

We heard several times that incorporating existing Ansible roles into the container build process needed to be easier. We solved this by creating a method for accessing roles from the local file system as well as a way to pull roles from your version control system (VCS).

The new --roles-path option for the build command allows mounting a local directory of roles into the build container. It handles the details of mounting the directory and automatically adds the new path to the list of paths Ansible searches when looking for roles.

To access roles from your VCS, add them to the ansible/requirements.yml file. Roles included in this file will be automatically installed into the build container just before the build process starts. For details on adding role to requirements.yml see Installing Multiple Roles from a File.

If you need a more custom solution for accessing existing roles, there is also the new --with-volumes option available on the build command. Use it to mount one or more local directories into the build container, specifying volumes in the format host_path:container_path[:access].

This gives you full control over pathnames and access. You can also set a custom roles_path used to find roles by updating ansible/ansible.cfg.

Retrofitting Existing Roles

Using existing roles is a good idea, but most roles are not ‘container aware’. For example, lots of roles on Ansible Galaxy follow the pattern of installing and configuring a particular service, starting it and adding it to the target host’s init system. That works great when running the role on a virtual machine, but doesn’t quite fit when running inside a container.

Running inside a container is different. The connection method is ‘docker exec’ by way of the Docker connection plugin, and not SSH. There is no init system. Only a single process should run inside a container. There is no need to cache RPMs or packages, and in fact it’s a good idea to aggressively remove unneeded files to reduce the size of the final image. The Ansible synchronize module does not currently work with the Docker connection plugin, and the become methods do not work, as su is disallowed by the Docker connection plugin, and sudo requires a TTY.

Most existing roles would fail, if run with these limitations, and so for a role to be ‘container aware’ it needs to detect these differences and automatically work around them. From the user’s perspective the role should just work without any tweaking or modifications, which means role authors have some work to do. Now with Ansible Container it can be as simple as testing ansible_env.ANSIBLE_CONTAINER. If that tests true, then the role is executing inside a container through the Docker connection plugin and the role can respond accordingly.

Creating New Roles

We addressed the challenge of using existing roles with a number of features that make access easier and retrofitting a snap, but what about new roles? Are there ways we can create new roles that specifically make building, orchestrating and sharing containers easier? Can roles be targeted specifically for containers?

Yes! Roles can now be targeted specifically for containers with the introduction of role types. A role type gives us the ability to target roles at specific use cases by adjusting the content delivered in the role, changing the way the role is installed and even changing the way a role is executed.

Two New Role Types

1. Container Enabled Role

It’s a building block for an Ansible Container project. Projects typically define multiple services that work together to form an application. Rather than building each service from scratch or figuring out how to connect pre-built images, let a container enabled role do the work for you by using the new ansible-container install command.

The role automatically updates the project's container.yml with the new service, updates main.yml with a call to the role and adds the role to requirements.yml. All you have to do is adjust any default settings surfaced in your project's container.yml and main.yml files. No more reading, and no more guess work. Now you can get back to building your app.

2. Container App

With this role you can jump-start the process of building a containerized application. Just download and use it as is, or use it as a starting point to build your next app. The role contains a complete Ansible Container application, everything from the ansible directory to application source code is included. Download it by running the ansible-container init command.

For example:

    $ mkdir example
    $ cd example
    $ ansible-container init <role_name>
    $ ansible-container build
    $ ansible-container run

That's it!

With Ansible Container it's now easier than ever to distribute applications, jump-start projects and get work done! Look for these new role types to appear on the Galaxy web site shortly. You’ll be able to filter by type, see the README and view the container.yml.

Templating in container.yml

Another feature we were asked about several times was to make it possible to share variables between Ansible Container and Ansible Playbook. Imagine being able to store usernames, passwords and other environment information in one place and have it show up in container.yml when container execution starts and in main.yml when the container build process begins. Now it’s possible.

The container.yml file is now treated as a Jinja template file, and Jinja expressions can be added in much the same way as they can be added to an Ansible playbook. Variables can then be passed to Ansible Container as a file with the new --var-file option, or specified within container.yml by adding a top level defaults: section, or passed as ‘AC_’ environment variables.

Getting Started

We’re excited about the new features in this release, and we can’t wait to hear your feedback and to see what you create. The new release is available on PyPi, so installation via pip should be straightforward. For prerequisites and assistance, review the installation guide. For more information about specific features and a command reference, check out the docs site. If you run into problems or need more help, please open an issue on the issue tracker, reach out to us via the mailing list, or find us in the #ansible-container channel on irc.freenode.net.