It is not possible to override the 'command' directive to start the container with (ex: systemd as PID1) #399
Comments
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 |
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/ |
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? |
@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.
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. |
As I experienced same issue and really want to build systemd based docker image, so I submit a PR #719 |
ISSUE TYPE
container.yml
main.yml
OS / ENVIRONMENT
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.The text was updated successfully, but these errors were encountered: