It is not possible to override the 'command' directive to start the container with (ex: systemd as PID1)

[dmsimard]

ISSUE TYPE

• Bug Report

container.yml

version: "2"
services:
  test:
    image: jrei/systemd-centos:latest
    command: /usr/sbin/init
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro

main.yml

- hosts: test
  gather_facts: false
  tasks:
    - command: systemctl daemon-reload

OS / ENVIRONMENT

$ ansible-container --debug version
Ansible Container, version 0.2.0
Linux, hostname, 4.9.13-200.fc25.x86_64, #1 SMP Mon Feb 27 16:48:42 UTC 2017, x86_64
2.7.13 (default, Jan 12 2017, 17:59:37) 
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] /tmp/ansible-container/bin/python
No DOCKER_HOST environment variable found. Assuming UNIX socket at /var/run/docker.sock
{u'Architecture': u'x86_64',
 u'BridgeNfIp6tables': True,
 u'BridgeNfIptables': True,
 u'CPUSet': True,
 u'CPUShares': True,
 u'CgroupDriver': u'cgroupfs',
 u'ClusterAdvertise': u'',
 u'ClusterStore': u'',
 u'Containers': 2,
 u'ContainersPaused': 0,
 u'ContainersRunning': 0,
 u'ContainersStopped': 2,
 u'CpuCfsPeriod': True,
 u'CpuCfsQuota': True,
 u'Debug': False,
 u'DefaultRuntime': u'runc',
 u'DockerRootDir': u'/var/lib/docker',
 u'Driver': u'devicemapper',
 u'DriverStatus': [[u'Pool Name', u'docker-253:0-1445263-pool'],
                   [u'Pool Blocksize', u'65.54 kB'],
                   [u'Base Device Size', u'10.74 GB'],
                   [u'Backing Filesystem', u'xfs'],
                   [u'Data file', u'/dev/loop0'],
                   [u'Metadata file', u'/dev/loop1'],
                   [u'Data Space Used', u'3.66 GB'],
                   [u'Data Space Total', u'107.4 GB'],
                   [u'Data Space Available', u'23.97 GB'],
                   [u'Metadata Space Used', u'5.308 MB'],
                   [u'Metadata Space Total', u'2.147 GB'],
                   [u'Metadata Space Available', u'2.142 GB'],
                   [u'Thin Pool Minimum Free Space', u'10.74 GB'],
                   [u'Udev Sync Supported', u'true'],
                   [u'Deferred Removal Enabled', u'false'],
                   [u'Deferred Deletion Enabled', u'false'],
                   [u'Deferred Deleted Device Count', u'0'],
                   [u'Data loop file',
                    u'/var/lib/docker/devicemapper/devicemapper/data'],
                   [u'Metadata loop file',
                    u'/var/lib/docker/devicemapper/devicemapper/metadata'],
                   [u'Library Version', u'1.02.136 (2016-11-05)']],
 u'ExecutionDriver': u'',
 u'ExperimentalBuild': False,
 u'HttpProxy': u'',
 u'HttpsProxy': u'',
 u'ID': u'LFNX:TDHP:WEUG:G3UA:XCGQ:GTK5:6SL2:O6GC:ICSN:RC66:HNDG:PKJC',
 u'IPv4Forwarding': True,
 u'Images': 18,
 u'IndexServerAddress': u'https://index.docker.io/v1/',
 u'KernelMemory': True,
 u'KernelVersion': u'4.9.13-200.fc25.x86_64',
 u'Labels': None,
 u'LiveRestoreEnabled': False,
 u'LoggingDriver': u'json-file',
 u'MemTotal': 16438763520,
 u'MemoryLimit': True,
 u'NCPU': 8,
 u'NEventsListener': 0,
 u'NFd': 19,
 u'NGoroutines': 29,
 u'Name': u'hostname',
 u'NoProxy': u'',
 u'OSType': u'linux',
 u'OomKillDisable': True,
 u'OperatingSystem': u'Fedora 25 (Workstation Edition)',
 u'Plugins': {u'Authorization': None,
              u'Network': [u'null', u'host', u'bridge', u'overlay'],
              u'Volume': [u'local']},
 u'RegistryConfig': {u'IndexConfigs': {u'docker.io': {u'Mirrors': None,
                                                      u'Name': u'docker.io',
                                                      u'Official': True,
                                                      u'Secure': True}},
                     u'InsecureRegistryCIDRs': [u'127.0.0.0/8'],
                     u'Mirrors': None},
 u'Runtimes': {u'runc': {u'path': u'docker-runc'}},
 u'SecurityOptions': [u'seccomp'],
 u'ServerVersion': u'1.12.3',
 u'SwapLimit': True,
 u'Swarm': {u'Cluster': {u'CreatedAt': u'0001-01-01T00:00:00Z',
                         u'ID': u'',
                         u'Spec': {u'CAConfig': {},
                                   u'Dispatcher': {},
                                   u'Orchestration': {},
                                   u'Raft': {},
                                   u'TaskDefaults': {}},
                         u'UpdatedAt': u'0001-01-01T00:00:00Z',
                         u'Version': {}},
            u'ControlAvailable': False,
            u'Error': u'',
            u'LocalNodeState': u'inactive',
            u'Managers': 0,
            u'NodeAddr': u'',
            u'NodeID': u'',
            u'Nodes': 0,
            u'RemoteManagers': None},
 u'SystemStatus': None,
 u'SystemTime': u'2017-03-16T11:50:42.769455925-04:00'}
{u'ApiVersion': u'1.24',
 u'Arch': u'amd64',
 u'GitCommit': u'6b644ec',
 u'GoVersion': u'go1.6.3',
 u'KernelVersion': u'4.9.13-200.fc25.x86_64',
 u'Os': u'linux',
 u'Version': u'1.12.3'}

SUMMARY

ansible-container will /always/ start containers with the command sh -c "while true; do sleep 1; done". This makes it impossible to start an alternative PID1.

In my context, this makes it impossible to use a systemd-based container because systemd must be PID1.

STEPS TO REPRODUCE

Just run the provided container.yaml and main.yaml.

EXPECTED RESULTS

Since I specified a "command" directive at the service level, I expected it to be taken into account and used when launching the container.

ACTUAL RESULTS

The container is launched with sh -c "while true; do sleep 1; done" instead of the command I specified in the command service directive.

[MansM]

This would be very useful for by example creating an ansible tower image in a centos:7 base image. Currently I am using ubuntu:14.04

[dmsimard]

This is only remotely relevant but posting here at least for reference: http://www.projectatomic.io/blog/2017/07/unprivileged-containers-with-bwrap-oci-and-bubblewrap/

[chouseknecht]

Is this still relevant under release 0.9?

Prior to 0.9 we performed an orchestrated build, where all services were started simultaneously, and we executed a single playbook. Now we do a sequential build, where we only start the container being built, and we execute one role at a time, generating a playbook to run the role. The container gets started and stopped with each role, and an image layer is committed for each. The process is similar to Docker's approach to a build.

So given that, is there a use case for overriding the arbitrary command that runs during role execution?

[dmsimard]

@chouseknecht honestly, I take a look at ansible-container every few months to see where things are going and I haven't had the chance to look recently so I can't quite let you know if this is still relevant. Maybe you would know, though.

What I would ultimately like ansible-container to allow me to do is to build and run containers with roles that already work today on virtual machines or bare metal. I can't describe how awesome it would be to suddenly be able to tell people: You know, this application you're deploying with Ansible in your VM, you can now build a container image instead and deploy that with ansible-container.

The problem with that is that people don't want you to be running systemd as PID1. It's the "bad" way of doing things in the container world. They want you to run 20 multi-line bash commands from your Dockerfile and then start whatever process you're interested in in foreground as PID1 (say, httpd or whatever else with dumb-init).

So, ansible-container addresses that Dockerfile bash craziness. Great.

But, if you're not running systemd as pid1 inside your container, it breaks a LOT of assumptions.
For example, something as simple as this wouldn't work:

- name: Enable and start httpd
  service:
    name: "httpd"
    state: "started"
    enabled: "yes"

This is something that has been discussed in many places, for example here.

Don't get me wrong, there are other challenges involved in running systemd that have nothing to do with ansible-container, like requiring you to bind mount some directories and stuff. Obviously this isn't something ansible-container can address, but it would be nice to allow ansible-container to run the PID1 I'm interested in.

[balll]

As I experienced same issue and really want to build systemd based docker image, so I submit a PR #719