search

containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.33k stars 2.38k forks source link

podman generate systemd service files fail for rootless pods #5002

Closed nimbius closed 4 years ago

nimbius commented 4 years ago

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Steps to reproduce the issue:

  1. create nginx pod named 'nginx', port maps 80 and 443 to rootless ports

  2. run nginx in pod

  3. podman generate systemd --name nginx --files

  4. copy these to /etc/systemd/system && daemon reload

  5. systemctl start services, auth as user, errors will report no such container.

Describe the results you received: no such container with infra id no such pod with id

Describe the results you expected: pod starts

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version: Version: 1.7.0 RemoteAPI Version: 1 Go Version: go1.13.5 Git Commit: b7ce1157b00af09f4a09e39b377aa3abff46ee05-dirty Built: Sat Jan 11 04:49:39 2020 OS/Arch: linux/amd64

(paste your output here)

Output of podman info --debug: debug: compiler: gc git commit: b7ce1157b00af09f4a09e39b377aa3abff46ee05-dirty go version: go1.13.5 podman version: 1.7.0 host: BuildahVersion: 1.12.0 CgroupVersion: v1 Conmon: package: Unknown path: /usr/bin/conmon version: 'conmon version 2.0.9, commit: 60b42f20f222df9da07a01ee444327348b9f54ee' Distribution: distribution: arch version: unknown IDMappings: gidmap:

(paste your output here)

Package info (e.g. output of rpm -q podman or apt list podman): Arch package

(paste your output here)

Additional environment details (AWS, VirtualBox, physical, etc.): physical desktop, AMD.

rhatdan commented 4 years ago

Could you try this with the --new flag. podman generate systemd currently defaults to only starting/stopping the originally created container. --new creates and destroys the container on each service start.

@vrothberg Perhaps we should change default on --new to true.

nimbius commented 4 years ago

--new doesnt appear to be a flag. podman generate systemd --help Generate a systemd unit file for a Podman container

Description: Command generates a systemd unit file for a Podman container

Usage: podman generate systemd [flags] CONTAINER | POD

Examples: podman generate systemd ctrID

Flags: -f, --files generate files instead of printing to stdout -n, --name use the container/pod name instead of ID --restart-policy string applicable systemd restart-policy (default "on-failure") -t, --timeout int stop timeout override (default -1)

mheon commented 4 years ago

That's because it's not present in 1.7.0 (or, for that matter, any released version) - it's too new for that.

mheon commented 4 years ago

(It will probably solve your issue once it works its way into a release - I want to cut a fresh release by end of this week)

nimbius commented 4 years ago

Works for me. I'll reopen if the issue persists.

Thanks!

vrothberg commented 4 years ago

I don't think the issue should be closed. It seems that the generated service files for the pod do not work which is unrelated to the --new flag.

vrothberg commented 4 years ago

I can't reproduce it. It works on my machine but I copy the service files to $HOME/.config/systemd/user.

no such container with infra id
no such pod with id

... gives me the impression we're mixing root and rootless. The pod and the infra container must be present unless they have been removed.

vrothberg commented 4 years ago

@nimbius, can you check if the pod and its containers are still present (e..g, podman-pod-ps and podman-ps)?

nimbius commented 4 years ago

podman pod ps shows the pod still available. podman ps shows the container is not running.

vrothberg commented 4 years ago

Can you verify that both, the pods&containers as well as the systemd service, are rootless? For instance, I usually copy user-specific services to $HOME/.config/systemd/user

nimbius commented 4 years ago

pods and containers under the user are present. as youve requested I moved the service files to the local user's unit directory and to no avail. 

[cicero@malt ~]$ ls -lah .config/systemd/user/
total 12K
drwxr-xr-x 2 cicero cicero 115 Feb  3 06:41 .
drwxr-xr-x 3 cicero cicero  18 Feb  3 06:39 ..
-rw-r--r-- 1 cicero cicero 632 Feb  3 06:41 container-interesting_gagarin.service
-rw-r--r-- 1 cicero cicero 608 Feb  3 06:41 container-nice_brattain.service
-rw-r--r-- 1 cicero cicero 653 Feb  3 06:41 pod-nginx.service

results in a slightly different error?

[cicero@malt ~]$ systemctl start pod-nginx
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to start 'pod-nginx.service'.
Authenticating as: cicero
Password:
==== AUTHENTICATION COMPLETE ====
Failed to start pod-nginx.service: Unit pod-nginx.service not found.
vrothberg commented 4 years ago

results in a slightly different error?

Do a systemctl --user daemon-reload before. Also note that we need to pass --user to systemctl.

nimbius commented 4 years ago

Eureka! Thanks for your help and patience. targets are found and the pod starts and operates normally.

vrothberg commented 4 years ago

Awesome! Thanks for reaching out!

nimbius commented 4 years ago

it should be noted that this type of service file generation doesnt create a systemd target that spawns as the user during boot. podman generate still requires a user to login first.

rhatdan commented 4 years ago

Is there a way in systemd to get user services to start automatically? I would figure this requires admin support.

nimbius commented 4 years ago

@rhatdan ideally the proper method is using user= and group= in a systemd target.
https://github.com/containers/libpod/blob/master/docs/tutorials/rootless_tutorial.md

specifically...

[Unit]
Description=nginx
Requires=user@1001.service
After=user@1001.service
[Service]
Type=simple
KillMode=none
MemoryMax=200M
ExecStartPre=-/usr/bin/podman rm -f nginx
ExecStartPre=/usr/bin/podman pull nginx
ExecStart=/usr/bin/podman run --name=nginx -p 8080:80 -v /home/nginx/html:/usr/share/nginx/html:Z nginx
ExecStop=/usr/bin/podman stop nginx
Restart=always
User=nginx
Group=nginx
[Install]
WantedBy=multi-user.target

however this configuration would need to be loaded from /etc/systemd/system, not the user path for --user level targets. 'podman generate' currently does not create this type of target file. perhaps it warrants some discussion?

A big achievement of rootless containers is an improved security model. the benefit of the current functionality of podman generate is isolated to the developer. the service targets generated by the command will not function unless the user logs in. Conversely, the only meaningful alternative to running your containerized services under systemd is probably openshift, however many shops either dont need that kind of power, or choose to implement kubernetes/orchestrator style scalability through things like gunicorn/wsgi or triggering an ansible playbook to control scaling as a reaction to or function of service level monitoring say, in prometheus or netdata or something similar.

improving 'podman generate' so that it could create such system level targets would certainly be helpful to the ops side of devops, however systemd templating for services could certainly exist outside podmans ability to create the targets itself (jinja or ansible come to mind.)