mirror of
https://github.com/containers/podman.git
synced 2025-06-24 03:08:13 +08:00
Merge pull request #1982 from cevich/ci_docs_link
Cirrus: Add/fix documentation links
This commit is contained in:
OpenShift Merge Robot
39
README.md
39
README.md
@ -1,15 +1,15 @@
|
||||
|
||||
# libpod - library for running OCI-based containers in Pods
|
||||
|
||||
### Latest Version: 0.12.1
|
||||
### Status: Active Development
|
||||
# Library and tool for running OCI-based containers in Pods
|
||||
|
||||
### Continuous Integration: [](https://cirrus-ci.com/github/containers/libpod)
|
||||
Libpod provides a library for applications looking to use the Container Pod concept,
|
||||
popularized by Kubernetes. libpod also contains the `podman` tool, for managing
|
||||
Pods, Containers, and Container Images.
|
||||
|
||||
## What is the scope of this project?
|
||||
* [Latest Version: 0.12.1](https://github.com/containers/libpod/releases/latest)
|
||||
* [Continuous Integration:](contrib/cirrus/README.md) [](https://cirrus-ci.com/github/containers/libpod/master)
|
||||
|
||||
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.
|
||||
## Overview and scope
|
||||
|
||||
At a high level, the scope of libpod and podman is the following:
|
||||
|
||||
@ -19,11 +19,22 @@ At a high level, the scope of libpod and podman is the following:
|
||||
* Full management of container lifecycle
|
||||
* Support for pods to manage groups of containers together
|
||||
* Resource isolation of containers and pods.
|
||||
* Integration with CRI-O to share containers and backend code.
|
||||
|
||||
## What is not in scope for this project?
|
||||
## Roadmap
|
||||
|
||||
* Signing and pushing images to various image storages. See [Skopeo](https://github.com/containers/skopeo/).
|
||||
* Container Runtimes daemons for working with Kubernetes CRIs. See [CRI-O](https://github.com/kubernetes-sigs/cri-o). We are working to integrate libpod into CRI-O to share containers and backend code with Podman.
|
||||
1. Python frontend for Varlink API
|
||||
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
|
||||
1. In-memory locking to replace file locks
|
||||
|
||||
## Out of scope
|
||||
|
||||
* Signing and pushing images to various image storages.
|
||||
See [Skopeo](https://github.com/containers/skopeo/).
|
||||
* Container Runtimes daemons for working with Kubernetes CRIs.
|
||||
See [CRI-O](https://github.com/kubernetes-sigs/cri-o).
|
||||
|
||||
## OCI Projects Plans
|
||||
|
||||
@ -68,14 +79,6 @@ Release notes for recent Podman versions
|
||||
**[Contributing](CONTRIBUTING.md)**
|
||||
Information about contributing to this project.
|
||||
|
||||
## Current Roadmap
|
||||
|
||||
1. Python frontend for Varlink API
|
||||
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
|
||||
1. In-memory locking to replace file locks
|
||||
|
||||
[spec-hooks]: https://github.com/opencontainers/runtime-spec/blob/v2.0.1/config.md#posix-platform-hooks
|
||||
|
||||
## Buildah and Podman relationship
|
||||
|
||||
@ -66,6 +66,18 @@ task (pass or fail) is set based on the exit status of the last script to execut
|
||||
|
||||
### ``cache_images`` Task
|
||||
|
||||
Modifying the contents of cache-images is done by making changes to
|
||||
one or more of the ``./contrib/cirrus/packer/*_setup.sh`` files. Testing
|
||||
those changes currently requires adding a temporary commit to a PR that
|
||||
updates ``.cirrus.yml``:
|
||||
|
||||
* Remove all task sections except ``cache_images_task``.
|
||||
* Remove the ``only_if`` condition and ``depends_on`` dependencies
|
||||
|
||||
The new image names will be displayed at the end of output, assuming the build
|
||||
is successful, at that point the temporary commit may be removed. Finally,
|
||||
the new names may be used as ``image_name`` values in ``.cirrus.yml``.
|
||||
|
||||
***N/B: Steps below are performed by automation***
|
||||
|
||||
1. When a PR is merged (``$CIRRUS_BRANCH`` == ``master``), run another
|
||||
@ -90,12 +102,6 @@ task (pass or fail) is set based on the exit status of the last script to execut
|
||||
3. If successful, shut down each VM and create a new GCE Image
|
||||
named with the base image, and the commit sha of the merge.
|
||||
|
||||
***Note:*** The ``.cirrus.yml`` file must be manually updated with the new
|
||||
images names, then the change sent in via a secondary pull-request. This
|
||||
ensures that all the ``integration_testing`` tasks can pass with the new images,
|
||||
before subjecting all future PRs to them. A workflow to automate this
|
||||
process is described in comments at the end of the ``.cirrus.yml`` file.
|
||||
|
||||
### Base-images
|
||||
|
||||
Base-images are VM disk-images specially prepared for executing as GCE VMs.
|
||||
@ -120,27 +126,27 @@ as the standard 'cloud-init' services.
|
||||
To produce new base-images, including an `image-builder-image` (used by
|
||||
the ``cache_images`` Task) some input parameters are required:
|
||||
|
||||
* ``GCP_PROJECT_ID``: The complete GCP project ID string e.g. foobar-12345
|
||||
identifying where the images will be stored.
|
||||
* ``GCP_PROJECT_ID``: The complete GCP project ID string e.g. foobar-12345
|
||||
identifying where the images will be stored.
|
||||
|
||||
* ``GOOGLE_APPLICATION_CREDENTIALS``: A *JSON* file containing
|
||||
credentials for a GCE service account. This can be [a service
|
||||
account](https://cloud.google.com/docs/authentication/production#obtaining_and_providing_service_account_credentials_manually)
|
||||
or [end-user
|
||||
credentials](https://cloud.google.com/docs/authentication/end-user#creating_your_client_credentials]
|
||||
* ``GOOGLE_APPLICATION_CREDENTIALS``: A *JSON* file containing
|
||||
credentials for a GCE service account. This can be [a service
|
||||
account](https://cloud.google.com/docs/authentication/production#obtaining_and_providing_service_account_credentials_manually)
|
||||
or [end-user
|
||||
credentials](https://cloud.google.com/docs/authentication/end-user#creating_your_client_credentials)
|
||||
|
||||
* ``RHEL_IMAGE_FILE`` and ``RHEL_CSUM_FILE`` complete paths
|
||||
to a `rhel-server-ec2-*.raw.xz` and it's cooresponding
|
||||
checksum file. These must be supplied manually because
|
||||
they're not available directly via URL like other images.
|
||||
* ``RHEL_IMAGE_FILE`` and ``RHEL_CSUM_FILE`` complete paths
|
||||
to a `rhel-server-ec2-*.raw.xz` and it's cooresponding
|
||||
checksum file. These must be supplied manually because
|
||||
they're not available directly via URL like other images.
|
||||
|
||||
* ``RHSM_COMMAND`` contains the complete string needed to register
|
||||
the VM for installing package dependencies. The VM will be de-registered
|
||||
upon completion.
|
||||
* ``RHSM_COMMAND`` contains the complete string needed to register
|
||||
the VM for installing package dependencies. The VM will be de-registered
|
||||
upon completion.
|
||||
|
||||
* Optionally, CSV's may be specified to ``PACKER_BUILDS``
|
||||
to limit the base-images produced. For example,
|
||||
``PACKER_BUILDS=fedora,image-builder-image``.
|
||||
* Optionally, CSV's may be specified to ``PACKER_BUILDS``
|
||||
to limit the base-images produced. For example,
|
||||
``PACKER_BUILDS=fedora,image-builder-image``.
|
||||
|
||||
If there is an existing 'image-builder-image' within GCE, it may be utilized
|
||||
to produce base-images (in addition to cache-images). However it must be
|
||||
|
||||
Reference in New Issue
Block a user