Error to 'run' ansible-container #912
Comments
|
Correction - there are no brackets ('{}') after 'Services', I copied from an incorrect copy of .yml file. services: {} |
|
For those who may want to know, it turned out that I need to set up 'dumb-init' to kill the error. |
|
Hey @Ilmn-Ybi , could you explain what you mean by "I need to set up 'dumb-init' to kill the error" |
Voronenko
added
needinfo
stale-communication
|
@Ilmn-Ybi Is issue resolved now? Do you have objections for this issue to be closed? |
|
@Voronenko |
|
@jochenparm In this specific case, I understand that there were no dumb-init installed inside container. |
|
Okay, can you explain to me why I need to install a dumb-init in my container to use Ansible Container with it if it wasn't necessary to do this when using a dockerfile? And if it is needed for compatibility with Ansible Container, is this documented somewhere? |
|
It is not linked to ansible-container, but about unix systems in general (most often used base image in docker ) https://docs.docker.com/v17.09/engine/reference/run/#specify-an-init-process Quoting some article: Why valid init for containers is importantAlthough people say, that proper docker microservice should run single dedicated Why init process is important: running processes can be visualized are ordered But what if parent process terminates (intentionally, or unintentionally)? What And this is where the init process kicks in. It becomes new parent (adopts) What if not? As long as a zombie is not removed from the system via a wait, it More reading on a topic: Upstart, Systemd, SysV usually are too heavy (overkill) to be used inside docker Candidates for container init processAt a time of article writing, most often used init approaches were: Custom written init scriptas per docker documentation, Will work, but really does not guarantee reaping… Let’s examine more robust Dumb-initdumb-init is a simple process supervisor and init system designed to run as PID dumb-init enables you to simply prefix your command with dumb-init. It acts as Project repo: TiniTini advertises itself as a tiny but valid init for containers. Promises:
Shipped as precompiled binary for hugh variety of platforms. Project repo: https://github.com/krallin/tini RunitRunit is a cross-platform Unix init scheme with service supervision, a Project website: http://smarden.org/runit/ S6S6 is project, actually sibling of the RUnit by S6 provides:
My_InitPart of the Phusion baseimage project Provides
Requires: python inside your container. In present form limited to Ubuntu base Supervisord ?This is known process manager usually used with python applications. I often saw Good if you anyway used it with your application earlier. Candidates for running multiple services inside container.From mentioned above and at the same time lightweight, worse to mention: SupervisorDClassic supervisor which does not even require root privileges. Ctl script that RUnitRunit ships with swiss-knife set of utilities, one of them is Typical interaction examples:
S6 (in scope of S6-overlay project)Unlike supervisor, s6 uses a folder structure to control services, similar to Now, each of those run files is an executable that s6 executes to start the Services are controlled by s6-svc binary. It has number of options, but the main s6-overlay comes with a number of built versions, so you can download the one |
ISSUE TYPE
container.yml
OS / ENVIRONMENT
SUMMARY
The container.xml file was original (downloaded from github).
Ansible-container init and build fine.
It can be urn with the 'web' section commented (i.e. no web service).
When 'web' section was uncommented, 'ansible-container run' threw errors
STEPS TO REPRODUCE
EXPECTED RESULTS
Run without error(s)
ACTUAL RESULTS
issues/709Got error. I read through existing related reports, but didn't see clear solution or fix.
The text was updated successfully, but these errors were encountered: