Ansible Container relies on a directory tree of content, which is created with the init sub-command. This content is what will be made available inside of the container used to run Ansible itself:

For this example, we'll create an ansible/ directory and run the init sub-command in it:

First, to define our services, we'll need to edit the container.yml file within the newly created ansible/ directory. Our example only has a single service, which we'll name cowsay. We'll want to use the docker.io/fedora:29 image. 

As a part of the build process, ansible-container makes use of a container called the conductor—essentially, this is a prebuilt container image from which our target container can be built, deployed, and run. It contains, among other important things, the Ansible runtimes, associated libraries, and a Python environment, as required by Ansible. It is important that, if possible, this container matches the operating system that you are building as closely as possible; otherwise, the differing versions of Python or other libraries could cause problems. Thus, we have defined a Fedora 29-based conductor container by using the conductor_base parameter. 

The build process expects container.yml to reference at least one role for the build process; we will create this role shortly, and we'll call it cowsay. This time, we'll expose port 8081, just to differentiate it from previous examples. We'll set the command for this service to nginx:

version: "2"
services:
  cowsay:
    from: docker.io/fedora:29
    conductor_base: fedora:29
    roles:
      - cowsay
    ports:
      - "8081:80"
    command: ['nginx']

With the service established, we need to write the plays to configure the base image to our needs. First, we will create a skeletal role directory:

mkdir -p roles/cowsay/tasks/

Then, we will create the roles/cowsay/tasks/main.yml file. The tasks in this file should match the tasks that we used in a previous example, with one exception—a new set_fact task. When ansible-container builds our new container, the Python environment from the previously mentioned conductor container is mounted in /_usr in the target container, and is used for all tasks. This is fine until we come to using the dnf module, which will not run from this mounted Python environment, as it is not installed in there! To get around this, we will use set_fact to define the ansible_python_interpreter host variable, and point it at the Python environment that we installed in the first task:

---
- name: install things
  raw: dnf install -y python-dnf

- name: use local python
  set_fact:
    ansible_python_interpreter: /usr/bin/python

- name: install things
  dnf:
    name: ['nginx', 'cowsay']

- name: configure nginx
  lineinfile:
    line: "daemon off;"
    dest: /etc/nginx/nginx.conf

- name: boop
  shell: cowsay boop > /usr/share/nginx/html/index.html

Unlike in the previous example, we do not need to add a task to run nginx; that will happen when the container is started.