Added support for override command directive when conductor is building image

[balll]

ISSUE TYPE

• Feature Pull Request
• Docs Pull Request

SUMMARY

Added support for override command directive when conductor is building image with systemd as pid 1. (feature idea #399)

Default command conductor use to run docker when building image is

sh -c "while true; do sleep 1; done

This PR will allow user to override it with build_command in each service.

from container.yml

version: 2

settings:
  project_name: test
  conductor:
    base: centos:7

services:
  grafana:
    from: centos/systemd
    roles:
      - grafana
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro
    stop_signal: SIGRTMIN+3
    cap_add: ["SYS_ADMIN"]
    command: /usr/sbin/init
    tty: true
    build_command: /usr/sbin/init

Then user can install and manage services the same way he do on a normal server.

from roles/grafana/tasks/main.yml

- name: Install Grafana
  package:
    name: grafana
    state: latest

- name: Ensure Grafana enabled at boot
  service:
    name: grafana-server
    state: started
    enabled: yes

[chouseknecht]

@balll

Thank you for taking the time to work on this. We always appreciate feedback and contribution, so a big "Thank You!"

If we decide to accept this, I suspect it needs a bit more documentation, including an example. We may also want to adjust how it's implemented.

I would like to discuss this on Monday at the next Container WG meeting. I'll put it on the agenda. I think the meeting time is 11:00 PM in Thailand, so there is no expectation that you attend. I believe you have provided sufficient detail for the group to discuss and decide next steps.

Thanks, again!

[balll]

@chouseknecht Thank you for your response. I've updated an example in the first comment.

[chouseknecht]

@balll

The container working group decided the following:

1. Your use case is sound, and it's one we should support
2. Rather than build_command as a new directive, we would prefer build_overrides
3. The new build_overrides directive will be similar to dev_overrides, except it will apply to build rather than run. Any settings in build_overrides will take precedence when the build command is invoked.
4. If no build_overrides is present in container.yml, then build will function just as it does today, overriding command with sh -c "while true; do sleep 1; done.

Using this new approach, your example container.yml from above would become the following:

version: 2

settings:
  project_name: test
  conductor:
    base: centos:7

services:
  grafana:
    from: centos/systemd
    roles:
      - grafana
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro
    stop_signal: SIGRTMIN+3
    cap_add: ["SYS_ADMIN"]
    command: /usr/sbin/init
    tty: true
    build_overrides:
      command: /usr/sbin/init

Please let me know, if you have any questions, comments, or need help making this change.

[balll]

@chouseknecht I've pushed changes reflexed container working group decision.

[chouseknecht]

I think this actually belongs in config.py, and it should be handled as part of the set_env method on the host side. That method would then accept a new env value of build, and return the appropriate configuration.

[danielkza]

Is this till being worked on? Being able to build systemd containers is fundamental for me to start using ansible-container. Any development/testing help needed?

[balll]

@danielkza When I have some free time, will work on it. Or submitting your own PR is fine.

[KernelPryanic]

@chouseknecht Sorry, I'm new here, but why do we need separate env for this functionality?

[sambanks]

Has this been abandoned? We also need this functionality to use the tool and would be happy to lend a hand.

[Voronenko]

@sambanks You can try to issue PR based on current develop

[sambanks]

Thanks @Voronenko but I have a workaround (manually linking into etc/systemd/system/multi-user.target.wants/) which has kept us moving for now.

[Voronenko]

Well, if you know solution, perhaps formulate it into some article (saying medium) and refer here. We might add some KB articles to Wiki than.

Idea of the opensource products are - if you can improve, improved locally, etc - return your commitment to community.

[sambanks]

It's not a solution, it's just a workaround for our specific use case. If you manually link the service file, as I shared in the previous message, it will start on the next boot, but it's very far from proper systemd support.

[haneul]

it would be really nice if it's supported.