Proposal: Support Both entrypoint and command with Simplified Default

Proposal: Support Both entrypoint and command with Simplified Default

Author: Wong Hoi Sing Edison <@hswong3i>

Date: 2020-02-29

• Status: New
• Proposal type: core design, schema changes
• Estimated time to implement: DONE (see #2591)

Motivation

For docker and podman driver, by default we only handle the command overwrite with sleep infinity.

Problems

In case base image have both ENTRYPOINT and CMD specified, our sleep infinity may not functioning correctly.

Solution proposal

• Add entrypoint for ENTRYPOINT support, with default ''
  • '' means enforce rollback to docker’s build-in default ENTRYPOINT with /bin/sh
  • NOT setting it as /bin/sh else it will be replaced into exec /bin/sh which not works
  • See https://docs.docker.com/engine/reference/run/#entrypoint-default-command-to-execute-at-runtime#entrypoint-default-command-to-execute-at-runtime
• Update command with new default bash -c "sleep infinity"
• Remove override_command for simplify logic

For simple test case which we are NOT care about the base image original ENTRYPOINT and CMD, with this patch we will default it with '' and bash -c "sleep infinity" therefore generally working for Molecule:

platforms:
  - name: instance
    image: centos:7
    entrypoint: ''
    command: 'bash -c "sleep infinity"'

In case we ARE caring about the base image origin ENTRYPOINT and CMD (e.g. mariadb:10.4), just simply set them as ~ in order to resume the original behavior:

platforms:
  - name: instance
    image: mariadb:10.4
    entrypoint: ~
    command: ~

When combine with systemd based container we could specify ENTRYPOINT and CMD as init and bash -c "sleep infinity", therefore much similar as real world production use cases:

platforms:
  - name: instance
    image: centos:7
    privileged: true
    volumes:
      - "/sys/fs/cgroup:/sys/fs/cgroup:rw"
    entrypoint: init
    command: 'bash -c "sleep infinity"'
    tty: True
    environment:
      container: docker

Dependencies (optional)

N/A

Testing (optional)

Corresponding test cases updated (see #2591; moreover, CI passed)

Documentation (optional)

Corresponding documentation updated (see #2591)

Anything else?

Ultimately, if we docker commit the result container as a static image with original base image’s ENTRYPOINT and CMD during verify.yml, we could therefore push this brewed image hub.docker.com as an alternative of ansible-bender project with standard Ansible supporting.

[hswong3i]

Can we make molecule working for both without forcing the user to add special configuration options to the molecule file?

@ssbarnea Yes, this is now confirmed to be functioning, see https://github.com/ansible-community/molecule/issues/2593#issuecomment-592954898

[ssbarnea]

Closing as this is something container/driver specific and we no longer keep these drivers in core molecule.