a4b483c848
Part of the motivation for 800eb863 (Hooks supports two directories, process default and override, 2018-09-17, #1487) was [1]: > We only use this for override. The reason this was caught is people > are trying to get hooks to work with CoreOS. You are not allowed to > write to /usr/share... on CoreOS, so they wanted podman to also look > at /etc, where users and third parties can write. But we'd also been disabling hooks completely for rootless users. And even for root users, the override logic was tricky when folks actually had content in both directories. For example, if you wanted to disable a hook from the default directory, you'd have to add a no-op hook to the override directory. Also, the previous implementation failed to handle the case where there hooks defined in the override directory but the default directory did not exist: $ podman version Version: 0.11.2-dev Go Version: go1.10.3 Git Commit: "6df7409cb5a41c710164c42ed35e33b28f3f7214" Built: Sun Dec 2 21:30:06 2018 OS/Arch: linux/amd64 $ ls -l /etc/containers/oci/hooks.d/test.json -rw-r--r--. 1 root root 184 Dec 2 16:27 /etc/containers/oci/hooks.d/test.json $ podman --log-level=debug run --rm docker.io/library/alpine echo 'successful container' 2>&1 | grep -i hook time="2018-12-02T21:31:19-08:00" level=debug msg="reading hooks from /usr/share/containers/oci/hooks.d" time="2018-12-02T21:31:19-08:00" level=warning msg="failed to load hooks: {}%!(EXTRA *os.PathError=open /usr/share/containers/oci/hooks.d: no such file or directory)" With this commit: $ podman --log-level=debug run --rm docker.io/library/alpine echo 'successful container' 2>&1 | grep -i hook time="2018-12-02T21:33:07-08:00" level=debug msg="reading hooks from /usr/share/containers/oci/hooks.d" time="2018-12-02T21:33:07-08:00" level=debug msg="reading hooks from /etc/containers/oci/hooks.d" time="2018-12-02T21:33:07-08:00" level=debug msg="added hook /etc/containers/oci/hooks.d/test.json" time="2018-12-02T21:33:07-08:00" level=debug msg="hook test.json matched; adding to stages [prestart]" time="2018-12-02T21:33:07-08:00" level=warning msg="implicit hook directories are deprecated; set --hooks-dir="/etc/containers/oci/hooks.d" explicitly to continue to load hooks from this directory" time="2018-12-02T21:33:07-08:00" level=error msg="container create failed: container_linux.go:336: starting container process caused "process_linux.go:399: container init caused \"process_linux.go:382: running prestart hook 0 caused \\\"error running hook: exit status 1, stdout: , stderr: oh, noes!\\\\n\\\"\"" (I'd setup the hook to error out). You can see that it's silenly ignoring the ENOENT for /usr/share/containers/oci/hooks.d and continuing on to load hooks from /etc/containers/oci/hooks.d. When it loads the hook, it also logs a warning-level message suggesting that callers explicitly configure their hook directories. That will help consumers migrate, so we can drop the implicit hook directories in some future release. When folks *do* explicitly configure hook directories (via the newly-public --hooks-dir and hooks_dir options), we error out if they're missing: $ podman --hooks-dir /does/not/exist run --rm docker.io/library/alpine echo 'successful container' error setting up OCI Hooks: open /does/not/exist: no such file or directory I've dropped the trailing "path" from the old, hidden --hooks-dir-path and hooks_dir_path because I think "dir(ectory)" is already enough context for "we expect a path argument". I consider this name change non-breaking because the old forms were undocumented. Coming back to rootless users, I've enabled hooks now. I expect they were previously disabled because users had no way to avoid /usr/share/containers/oci/hooks.d which might contain hooks that required root permissions. But now rootless users will have to explicitly configure hook directories, and since their default config is from ~/.config/containers/libpod.conf, it's a misconfiguration if it contains hooks_dir entries which point at directories with hooks that require root access. We error out so they can fix their libpod.conf. [1]: https://github.com/containers/libpod/pull/1487#discussion_r218149355 Signed-off-by: W. Trevor King <wking@tremily.us>
libpod - library for running OCI-based containers in Pods
Latest Version: 0.11.1.1
Status: Active Development
Continuous Integration: 
What is the scope of this project?
libpod provides a library for applications looking to use the Container Pod concept popularized by Kubernetes. libpod also contains a tool called podman for managing Pods, Containers, and Container Images.
At a high level, the scope of libpod and podman is the following:
- Support multiple image formats including the existing Docker/OCI image formats.
- Support for multiple means to download images including trust & image verification.
- Container image management (managing image layers, overlay filesystems, etc).
- Full management of container lifecycle
- Support for pods to manage groups of containers together
- Resource isolation of containers and pods.
What is not in scope for this project?
- Signing and pushing images to various image storages. See Skopeo.
- Container Runtimes daemons for working with Kubernetes CRIs. See CRI-O. We are working to integrate libpod into CRI-O to share containers and backend code with Podman.
OCI Projects Plans
The plan is to use OCI projects and best of breed libraries for different aspects:
- Runtime: runc (or any OCI compliant runtime) and oci runtime tools to generate the spec
- Images: Image management using containers/image
- Storage: Container and image storage is managed by containers/storage
- Networking: Networking support through use of CNI
- Builds: Builds are supported via Buildah.
- Conmon: Conmon is a tool for monitoring OCI runtimes. It is part of the CRI-O package
Podman Information for Developers
For blogs, release announcements and more, please checkout the podman.io website!
Installation notes Information on how to install Podman in your environment.
OCI Hooks Support Information on how Podman configures OCI Hooks to run when launching a container.
Podman API Documentation on the Podman API using Varlink.
Podman Commands A list of the Podman commands with links to their man pages and in many cases videos showing the commands in use.
Podman Troubleshooting Guide A list of common issues and solutions for Podman.
Podman Usage Transfer Useful information for ops and dev transfer as it relates to infrastructure that utilizes Podman. This page includes tables showing Docker commands and their Podman equivalent commands.
Tutorials Tutorials on using Podman.
Release Notes Release notes for recent Podman versions
Contributing Information about contributing to this project.
Current Roadmap
- Python frontend for Varlink API
- Integrate libpod into CRI-O to replace its existing container management backend
- Further work on the podman pod command
- Further improvements on rootless containers
- In-memory locking to replace file locks
Buildah and Podman relationship
Buildah and Podman are two complementary Open-source projects that are available on most Linux platforms and both projects reside at GitHub.com with Buildah (GitHub) and Podman (GitHub). Both Buildah and Podman are command line tools that work on OCI images and containers. The two projects differentiate in their specialization.
Buildah specializes in building OCI images. Buildah's commands replicate all of the commands that are found in a Dockerfile. Buildah’s goal is also to provide a lower level coreutils interface to build images, allowing people to build containers without requiring a Dockerfile. The intent with Buildah is to allow other scripting languages to build container images, without requiring a daemon.
Podman specializes in all of the commands and functions that help you to maintain and modify OCI images, such as pulling and tagging. It also allows you to create, run, and maintain those containers created from those images.
A major difference between Podman and Buildah is their concept of a container. Podman
allows users to create "traditional containers" where the intent of these containers is
to be long lived. While Buildah containers are really just created to allow content
to be added back to the container image. An easy way to think of it is the
buildah run command emulates the RUN command in a Dockerfile while the podman run
command emulates the docker run command in functionality. Because of this and their underlying
storage differences, you can not see Podman containers from within Buildah or vice versa.
In short Buildah is an efficient way to create OCI images while Podman allows you to manage and maintain those images and containers in a production environment using familiar container cli commands. For more details, see the Container Tools Guide.