2018-05-15 14:51:56 +00:00
![PODMAN logo ](logo/podman-logo-source.svg )
2017-11-01 19:30:09 +00:00
2018-12-11 17:55:19 +00:00
# Library and tool for running OCI-based containers in Pods
2017-11-01 19:30:09 +00:00
2018-12-11 17:55:19 +00:00
Libpod provides a library for applications looking to use the Container Pod concept,
2019-01-31 09:05:17 +00:00
popularized by Kubernetes. Libpod also contains the Pod Manager tool `(Podman)` . Podman manages pods, containers, container images, and container volumes.
2018-11-14 15:15:14 +00:00
2019-06-13 16:47:57 +00:00
* [Latest Version: 1.4.0 ](https://github.com/containers/libpod/releases/latest )
2018-12-11 17:55:19 +00:00
* [Continuous Integration: ](contrib/cirrus/README.md ) [![Build Status ](https://api.cirrus-ci.com/github/containers/libpod.svg )](https://cirrus-ci.com/github/containers/libpod/master)
2017-11-01 19:30:09 +00:00
2018-12-11 17:55:19 +00:00
## Overview and scope
2017-11-01 19:30:09 +00:00
2019-05-15 18:05:20 +00:00
At a high level, the scope of libpod and Podman is the following:
2017-11-01 19:30:09 +00:00
2019-03-16 10:46:35 +00:00
* Support multiple image formats including the OCI and Docker image formats.
2018-01-18 20:37:42 +00:00
* Support for multiple means to download images including trust & image verification.
* Container image management (managing image layers, overlay filesystems, etc).
2018-05-11 14:37:35 +00:00
* Full management of container lifecycle
* Support for pods to manage groups of containers together
* Resource isolation of containers and pods.
2019-05-31 15:59:50 +00:00
* Support for a Docker-compatible CLI interface through Podman.
2018-12-11 17:55:19 +00:00
* Integration with CRI-O to share containers and backend code.
2017-11-01 19:30:09 +00:00
2019-01-29 22:35:23 +00:00
This project tests all builds against each supported version of Fedora, the latest released version of Red Hat Enterprise Linux, and the latest Ubuntu Long Term Support release. The community has also reported success with other Linux flavors.
2018-12-11 17:55:19 +00:00
## Roadmap
2017-11-01 19:30:09 +00:00
2019-01-10 16:49:12 +00:00
1. Allow the Podman CLI to use a Varlink backend to connect to remote Podman instances
2018-12-11 17:55:19 +00:00
1. Integrate libpod into CRI-O to replace its existing container management backend
1. Further work on the podman pod command
1. Further improvements on rootless containers
2019-04-29 16:56:33 +00:00
## Rootless
Podman can be easily run as a normal user, without requiring a setuid binary.
When run without root, Podman containers use user namespaces to set root in the container to the user running Podman.
Rootless Podman runs locked-down containers with no privileges that the user running the container does not have.
Some of these restrictions can be lifted (via `--privileged` , for example), but rootless containers will never have more privileges than the user that launched them.
If you run Podman as your user and mount in `/etc/passwd` from the host, you still won't be able to change it, since your user doesn't have permission to do so.
Almost all normal Podman functionality is available, though there are some [shortcomings ](https://github.com/containers/libpod/blob/master/rootless.md ).
Any recent Podman release should be able to run rootless without any additional configuration, though your operating system may require some additional configuration detailed in the [install guide ](https://github.com/containers/libpod/blob/master/install.md ).
2019-03-31 14:49:21 +00:00
2018-12-11 17:55:19 +00:00
## Out of scope
2019-02-25 14:08:02 +00:00
* Specializing in signing and pushing images to various storage backends.
See [Skopeo ](https://github.com/containers/skopeo/ ) for those tasks.
* Container runtimes daemons for working with the Kubernetes CRI interface.
2019-05-17 15:08:14 +00:00
[CRI-O ](https://github.com/cri-o/cri-o ) specializes in that.
2019-02-25 14:08:02 +00:00
* Supporting `docker-compose` . We believe that Kubernetes is the defacto
2019-02-26 13:48:44 +00:00
standard for composing Pods and for orchestrating containers, making
Kubernetes YAML a defacto standard file format. Hence, Podman allows the
creation and execution of Pods from a Kubernetes YAML file (see
[podman-play-kube ](https://github.com/containers/libpod/blob/master/docs/podman-play-kube.1.md )).
Podman can also generate Kubernetes YAML based on a container or Pod (see
[podman-generate-kube ](https://github.com/containers/libpod/blob/master/docs/podman-generate-kube.1.md )),
which allows for an easy transition from a local development environment
2019-04-21 12:53:37 +00:00
to a production Kubernetes cluster. If Kubernetes does not fit your requirements,
there are other third-party tools that support the docker-compose format such as
[kompose ](https://github.com/kubernetes/kompose/ ) and
[podman-compose ](https://github.com/muayyad-alsadi/podman-compose )
that might be appropriate for your environment.
2017-11-01 19:30:09 +00:00
2018-01-18 20:37:42 +00:00
## OCI Projects Plans
2017-11-01 19:30:09 +00:00
The plan is to use OCI projects and best of breed libraries for different aspects:
2019-01-10 16:49:12 +00:00
- Runtime: [runc ](https://github.com/opencontainers/runc ) (or any OCI compliant runtime) and [OCI runtime tools ](https://github.com/opencontainers/runtime-tools ) to generate the spec
2017-11-01 19:30:09 +00:00
- Images: Image management using [containers/image ](https://github.com/containers/image )
2018-05-11 14:37:35 +00:00
- Storage: Container and image storage is managed by [containers/storage ](https://github.com/containers/storage )
2017-11-01 19:30:09 +00:00
- Networking: Networking support through use of [CNI ](https://github.com/containernetworking/cni )
2018-09-18 19:31:54 +00:00
- Builds: Builds are supported via [Buildah ](https://github.com/containers/buildah ).
2019-05-17 22:02:29 +00:00
- Conmon: [Conmon ](https://github.com/containers/conmon ) is a tool for monitoring OCI runtimes.
2017-11-01 19:30:09 +00:00
2018-01-16 00:26:42 +00:00
## Podman Information for Developers
2018-09-29 17:04:16 +00:00
For blogs, release announcements and more, please checkout the [podman.io ](https://podman.io ) website!
2018-05-17 15:18:01 +00:00
**[Installation notes](install.md)**
2018-01-16 00:26:42 +00:00
Information on how to install Podman in your environment.
pkg/hooks: Version the hook structure and add 1.0.0 hooks
This shifts the matching logic out of libpod/container_internal and
into the hook package, where we can reuse it after vendoring into
CRI-O. It also adds unit tests with almost-complete coverage. Now
libpod is even more isolated from the hook internals, which makes it
fairly straightforward to bump the hook config file to 1.0.0. I've
dubbed the old format 0.1.0, although it doesn't specify an explicit
version. Motivation for some of my changes with 1.0.0:
* Add an explicit version field. This will make any future JSON
structure migrations more straightforward by avoiding the need for
version-guessing heuristics.
* Collect the matching properties in a new When sub-structure. This
makes the root Hook structure easier to understand, because you
don't have to read over all the matching properties when wrapping
your head around Hook.
* Replace the old 'hook' and 'arguments' with a direct embedding of
the runtime-spec's hook structure. This provides access to
additional upstream properties (args[0], env, and timeout) and
avoids the complication of a CRI-O-specific analog structure.
* Add a 'when.always' property. You can usually accomplish this
effect in another way (e.g. when.commands = [".*"]), but having a
boolean explicitly for this use-case makes for easier reading and
writing.
* Replace the previous annotations array with an annotations map. The
0.1.0 approach matched only the values regardless of key, and that
seems unreliable.
* Replace 'cmds' with 'when.commands', because while there are a few
ways to abbreviate "commands", there's only one way to write it out
in full ;). This gives folks one less thing to remember when
writing hook JSON.
* Replace the old "inject if any specified condition matches" with
"inject if all specified conditions match". This allows for more
precise targeting. Users that need more generous targeting can
recover the previous behavior by creating a separate 1.0.0 hook file
for each specified 0.1.0 condition.
I've added doc-compat support for the various pluralizations of the
0.1.0 properties. Previously, the docs and code were not in
agreement. More on this particular facet in [1].
I've updated the docs to point out that the annotations being matched
are the OCI config annotations. This differs from CRI-O, where the
annotations used are the Kubernetes-supplied annotations [2,3]. For
example, io.kubernetes.cri-o.Volumes [4] is part of CRI-O's runtime
config annotations [5], but not part of the Kubernetes-supplied
annotations CRI-O uses for matching hooks.
The Monitor method supports the CRI-O use-case [6]. podman doesn't
need it directly, but CRI-O will need it when we vendor this package
there.
I've used nvidia-container-runtime-hook for the annotation examples
because Dan mentioned the Nvidia folks as the motivation behind
annotation matching. The environment variables are documented in [7].
The 0.1.0 hook config, which does not allow for environment variables,
only works because runc currently leaks the host environment into the
hooks [8]. I haven't been able to find documentation for their usual
annotation trigger or hook-install path, so I'm just guessing there.
[1]: https://github.com/kubernetes-incubator/cri-o/pull/1235
[2]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L760
[3]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L772
[4]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/pkg/annotations/annotations.go#L97-L98
[5]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.0/server/container_create.go#L830-L834
[6]: https://github.com/kubernetes-incubator/cri-o/pull/1345/
[7]: https://github.com/NVIDIA/nvidia-container-runtime/tree/v1.3.0-1#environment-variables-oci-spec
[8]: https://github.com/opencontainers/runc/pull/1738
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #686
Approved by: mheon
2018-04-27 17:35:32 +00:00
**[OCI Hooks Support](pkg/hooks/README.md)**
Information on how Podman configures [OCI Hooks][spec-hooks] to run when launching a container.
2018-01-16 00:26:42 +00:00
2018-05-17 15:18:01 +00:00
**[Podman API](API.md)**
Documentation on the Podman API using [Varlink ](https://www.varlink.org/ ).
**[Podman Commands](commands.md)**
2018-01-18 20:37:42 +00:00
A list of the Podman commands with links to their man pages and in many cases videos
showing the commands in use.
2018-01-16 00:26:42 +00:00
2018-05-17 15:18:01 +00:00
**[Podman Troubleshooting Guide](troubleshooting.md)**
A list of common issues and solutions for Podman.
**[Podman Usage Transfer](transfer.md)**
2018-01-18 20:37:42 +00:00
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.
2018-01-16 00:26:42 +00:00
2018-02-15 12:31:46 +00:00
**[Tutorials](docs/tutorials)**
2018-05-11 14:37:35 +00:00
Tutorials on using Podman.
2018-01-16 00:26:42 +00:00
2019-02-25 15:48:24 +00:00
**[Remote Client](remote_client.md)**
A brief how-to on using the Podman remote-client.
2018-08-24 21:08:53 +00:00
**[Release Notes](RELEASE_NOTES.md)**
Release notes for recent Podman versions
2018-04-27 18:58:18 +00:00
**[Contributing](CONTRIBUTING.md)**
Information about contributing to this project.
2017-11-01 19:30:09 +00:00
2018-09-13 23:08:43 +00:00
[spec-hooks]: https://github.com/opencontainers/runtime-spec/blob/v2.0.1/config.md#posix-platform-hooks
## Buildah and Podman relationship
2019-02-25 10:38:23 +00:00
Buildah and Podman are two complementary open-source projects that are
available on most Linux platforms and both projects reside at
[GitHub.com ](https://github.com ) with Buildah
[here ](https://github.com/containers/buildah ) and Podman
[here ](https://github.com/containers/libpod ). Both, Buildah and Podman are
command line tools that work on Open Container Initiative (OCI) images and
containers. The two projects differentiate in their specialization.
2018-09-13 23:08:43 +00:00
Buildah specializes in building OCI images. Buildah's commands replicate all
2019-02-25 10:38:23 +00:00
of the commands that are found in a Dockerfile. This allows building images
with and without Dockerfiles while not requiring any root privileges.
Buildah’ s ultimate goal is to provide a lower-level coreutils interface to
build images. The flexibility of building images without Dockerfiles allows
for the integration of other scripting languages into the build process.
Buildah follows a simple fork-exec model and does not run as a daemon
but it is based on a comprehensive API in golang, which can be vendored
into other tools.
2018-09-13 23:08:43 +00:00
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
2019-02-25 10:38:23 +00:00
to be added back to the container image. An easy way to think of it is the
2018-09-13 23:08:43 +00:00
`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
2019-02-25 10:38:23 +00:00
storage differences, you can not see Podman containers from within Buildah or vice versa.
2018-09-13 23:08:43 +00:00
2019-02-25 10:38:23 +00:00
In short, Buildah is an efficient way to create OCI images while Podman allows
2018-09-13 23:08:43 +00:00
you to manage and maintain those images and containers in a production environment using
2018-09-14 14:58:52 +00:00
familiar container cli commands. For more details, see the
2018-09-18 19:31:54 +00:00
[Container Tools Guide ](https://github.com/containers/buildah/tree/master/docs/containertools ).