Dockerfiles are useful, but many of the actions performed inside of Dockerfiles could be completed with Ansible instead. Ansible can be used to launch a container using a base image, then interact with that container using the docker connection method to complete the configuration. Let's demonstrate this by repeating the previous example, but without the need for a Dockerfile. Instead, all of the work will be handled by an entirely new playbook named docker-all.yaml. The first part of this playbook starts a container from a preexisting image of Fedora 29 from Docker Hub, and adds the resulting container details to Ansible's in-memory inventory by using add_host:

---
- name: build an image
  hosts: localhost
  gather_facts: false

  tasks:
    - name: start the container
      docker_container:
        name: playbook-container
        image: docker.io/fedora:29
        ports: 8080:80
        state: started
        command: sleep 500

    - name: make a host
      add_host:
        name: playbook-container
        ansible_connection: docker
        ansible_ssh_user: root

Then, using this newly added inventory host, we define a second play that runs Ansible tasks within the container that was just launched, configuring our cowsay service like before, but without the need for a Dockerfile:

- name: do things
  hosts: playbook-container
  gather_facts: false

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

    - 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

    - name: run nginx
      shell: nginx &

The playbook consists of two plays. The first play creates the container from the base Fedora 29 image. The docker_container task is given a sleep command to keep the container running for a period of time, as the docker connection plugin only works with active containers (unconfigured operating system images from Docker Hub generally exit immediately when they are run, as they have no default actions to perform). The second task of the first play creates a runtime inventory entry for the container. The inventory hostname must match the container name. The connection method is set to docker as well.

The second play targets the newly created host, and the first task uses the raw module to get the python-dnf package in place (which will bring the rest of python in), so that we can use the dnf module in the next task. The dnf module is then used to install the desired packages, namely, nginx and cowsay. Then, the lineinfile module is used to add a new line to the nginx configuration. A shell task uses cowsay to create content for nginx to serve. Finally, nginx itself is started as a background process.

Before running the playbook, let's remove any running containers from the previous example:

With the running container removed, we can now run our new playbook to recreate the container, bypassing the image build step:

We see tasks from the first play execute on the localhost, and then the second play executes on the playbook-container. Once it's complete, we can test the web service and list the running containers to verify our work. Note the different filter this time; our container was build and run directly from the fedora image, without the intermediate step of creating the fedora-moo image:

This method of using Ansible to configure the running container has some advantages. First, you can reuse existing roles to set up an application, easily switching from cloud virtual machine targets to containers, and even to bare metal resources, if desired. Secondly, you can easily review all configuration that goes into an application, simply by reviewing the playbook content.

Another use case for this method of interaction is to use Docker containers to simulate multiple hosts, in order to verify playbook execution across multiple hosts. A container can be started with an init system as the running process, allowing for additional services to be started as if they were on a full operating system. This use case is valuable within a continuous integration environment, to validate changes to playbook content quickly and efficiently.