@ -9,7 +9,7 @@ Containerfile(Dockerfile) - automate the steps of creating a container image
The **Containerfile** is a configuration file that automates the steps of creating a container image. It is similar to a Makefile. Container engines (Podman, Buildah, Docker) read instructions from the **Containerfile** to automate the steps otherwise performed manually to create an image. To build an image, create a file called **Containerfile**.
The **Containerfile** is a configuration file that automates the steps of creating a container image. It is similar to a Makefile. Container engines (Podman, Buildah, Docker) read instructions from the **Containerfile** to automate the steps otherwise performed manually to create an image. To build an image, create a file called **Containerfile**.
The **Containerfile** describes the steps taken to assemble the image. When the
The **Containerfile** describes the steps taken to assemble the image. When the
**Containerfile** has been created, call the `buildah bud`, `podman build`, `docker build` command,
**Containerfile** has been created, call the `buildah build`, `podman build`, `docker build` command,
using the path of context directory that contains **Containerfile** as the argument. Podman and Buildah default to **Containerfile** and will fall back to **Dockerfile**. Docker only will search for **Dockerfile** in the context directory.
using the path of context directory that contains **Containerfile** as the argument. Podman and Buildah default to **Containerfile** and will fall back to **Dockerfile**. Docker only will search for **Dockerfile** in the context directory.
@ -31,7 +31,7 @@ A Containerfile is similar to a Makefile.
# USAGE
# USAGE
```
```
buildah bud .
buildah build .
podman build .
podman build .
```
```
@ -40,7 +40,7 @@ A Containerfile is similar to a Makefile.
build.
build.
```
```
buildah bud -t repository/tag .
buildah build -t repository/tag .
podman build -t repository/tag .
podman build -t repository/tag .
```
```
@ -61,7 +61,7 @@ A Containerfile is similar to a Makefile.
`FROM image@digest [AS <name>]`
`FROM image@digest [AS <name>]`
-- The **FROM** instruction sets the base image for subsequent instructions. A
-- The **FROM** instruction sets the base image for subsequent instructions. A
valid Containerfile must have either **ARG** or *FROM** as its first instruction.
valid Containerfile must have either **ARG** or **FROM** as its first instruction.
If **FROM** is not the first instruction in the file, it may only be preceded by
If **FROM** is not the first instruction in the file, it may only be preceded by
one or more ARG instructions, which declare arguments that are used in the next FROM line in the Containerfile.
one or more ARG instructions, which declare arguments that are used in the next FROM line in the Containerfile.
The image can be any valid image. It is easy to start by pulling an image from the public
The image can be any valid image. It is easy to start by pulling an image from the public
@ -109,7 +109,7 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
@ -131,6 +131,18 @@ Current supported mount TYPES are bind, cache, secret and tmpfs.
· from: stage or image name for the root of the source. Defaults to the build context.
· from: stage or image name for the root of the source. Defaults to the build context.
· relabel=shared, z: Relabels src content with a shared label.
. relabel=private, Z: Relabels src content with a private label.
Labeling systems like SELinux require proper labels on the bind mounted content mounted into a container. Without a label, the security system might prevent the processes running in side the container from using the content. By default, container engines do not change the labels set by the OS. The relabel flag tells the engine to relabel file objects on the shared mountz.
The relabel=shared and z options tell the engine that two or more containers will share the mount content. The engine labels the content with a shared content label.
The relabel=private and Z options tell the engine to label the content with a private unshared label. Only the current container can use a private mount.
Relabeling walks the file system under the mount and changes the label on each file, if the mount has thousands of inodes, this process takes a long time, delaying the start of the container.
· rw, read-write: allows writes on the mount.
· rw, read-write: allows writes on the mount.
Options specific to tmpfs:
Options specific to tmpfs:
@ -207,7 +219,7 @@ Container engines pass secret the secret file into the build using the `--secret
- `id` is the identifier for the secret passed into the `buildah bud --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
- `id` is the identifier for the secret passed into the `buildah build --secret` or `podman build --secret`. This identifier is associated with the RUN --mount identifier to use in the Containerfile.
- `dst`|`target`|`destination` rename the secret file to a specific file in the Containerfile RUN command to use.
- `dst`|`target`|`destination` rename the secret file to a specific file in the Containerfile RUN command to use.
@ -224,7 +236,7 @@ RUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar
The secret needs to be passed to the build using the --secret flag. The final image built does not container the secret file:
The secret needs to be passed to the build using the --secret flag. The final image built does not container the secret file:
Exactly one of `keyPath`, `keyData` and `fulcio` must be present.
Exactly one of `keyPath`, `keyPaths`, `keyData`, `keyDatas` and `fulcio` must be present.
If `keyPath` or `keyData` is present, it contains a sigstore public key.
If `keyPath` or `keyData` is present, it contains a sigstore public key.
Only signatures made by this key are accepted.
Only signatures made by this key are accepted.
If `keyPaths` or `keyDatas` is present, it contains sigstore public keys.
Only signatures made by any key in the list are accepted.
If `fulcio` is present, the signature must be based on a Fulcio-issued certificate.
If `fulcio` is present, the signature must be based on a Fulcio-issued certificate.
One of `caPath` and `caData` must be specified, containing the public key of the Fulcio instance.
One of `caPath` and `caData` must be specified, containing the public key of the Fulcio instance.
Both `oidcIssuer` and `subjectEmail` are mandatory,
Both `oidcIssuer` and `subjectEmail` are mandatory,
exactly specifying the expected identity provider,
exactly specifying the expected identity provider,
and the identity of the user obtaining the Fulcio certificate.
and the identity of the user obtaining the Fulcio certificate.
At most one of `rekorPublicKeyPath` and `rekorPublicKeyData` can be present;
At most one of `rekorPublicKeyPath`, `rekorPublicKeyPaths`, `rekorPublicKeyData` and `rekorPublicKeyDatas` can be present;
it is mandatory if `fulcio` is specified.
it is mandatory if `fulcio` is specified.
If a Rekor public key is specified,
If a Rekor public key is specified,
the signature must have been uploaded to a Rekor server
the signature must have been uploaded to a Rekor server
and the signature must contain an (offline-verifiable) “signed entry timestamp”
and the signature must contain an (offline-verifiable) “signed entry timestamp”
proving the existence of the Rekor log record,
proving the existence of the Rekor log record,
signed by the provided public key.
signed by one of the provided public keys.
The `signedIdentity` field has the same semantics as in the `signedBy` requirement described above.
The `signedIdentity` field has the same semantics as in the `signedBy` requirement described above.
Note that `cosign`-created signatures only contain a repository, so only `matchRepository` and `exactRepository` can be used to accept them (and that does not protect against substitution of a signed image with an unexpected tag).
Note that `cosign`-created signatures only contain a repository, so only `matchRepository` and `exactRepository` can be used to accept them (and that does not protect against substitution of a signed image with an unexpected tag).
@ -19,6 +19,12 @@ Container engines will use the `$HOME/.config/containers/registries.conf` if it
`credential-helpers`
`credential-helpers`
: An array of default credential helpers used as external credential stores. Note that "containers-auth.json" is a reserved value to use auth files as specified in containers-auth.json(5). The credential helpers are set to `["containers-auth.json"]` if none are specified.
: An array of default credential helpers used as external credential stores. Note that "containers-auth.json" is a reserved value to use auth files as specified in containers-auth.json(5). The credential helpers are set to `["containers-auth.json"]` if none are specified.
`additional-layer-store-auth-helper`
: A string containing the helper binary name. This enables passing registry credentials to an
Additional Layer Store every time an image is read using the `docker://`
transport so that it can access private registries. See the 'Enabling Additional Layer Store to access to private registries' section below for
more details.
### NAMESPACED `[[registry]]` SETTINGS
### NAMESPACED `[[registry]]` SETTINGS
The bulk of the configuration is represented as an array of `[[registry]]`
The bulk of the configuration is represented as an array of `[[registry]]`
@ -254,6 +260,30 @@ in order, and use the first one that exists.
Note that a mirror is associated only with the current `[[registry]]` TOML table. If using the example above, pulling the image `registry.com/image:latest` will hence only reach out to `mirror.registry.com`, and the mirrors associated with `example.com/foo` will not be considered.
Note that a mirror is associated only with the current `[[registry]]` TOML table. If using the example above, pulling the image `registry.com/image:latest` will hence only reach out to `mirror.registry.com`, and the mirrors associated with `example.com/foo` will not be considered.
### Enabling Additional Layer Store to access to private registries
The `additional-layer-store-auth-helper` option enables passing registry
credentials to an Additional Layer Store so that it can access private registries.
When accessing a private registry via an Additional Layer Store, a helper binary needs to be provided. This helper binary is
registered via the `additional-layer-store-auth-helper` option. Every time an image
is read using the `docker://` transport, the specified helper binary is executed
and receives registry credentials from stdin in the following format.
```json
{
"$image_reference": {
"username": "$username",
"password": "$password",
"identityToken": "$identityToken"
}
}
```
The format of `$image_reference` is `$repo{:$tag|@$digest}`.
Additional Layer Stores can use this helper binary to access the private registry.
## VERSION 1 FORMAT - DEPRECATED
## VERSION 1 FORMAT - DEPRECATED
VERSION 1 format is still supported but it does not support
VERSION 1 format is still supported but it does not support
using registry mirrors, longest-prefix matches, or location rewriting.
using registry mirrors, longest-prefix matches, or location rewriting.
@ -27,7 +27,7 @@ No bare options are used. The format of TOML can be simplified to:
The `storage` table supports the following options:
The `storage` table supports the following options:
**driver**=""
**driver**=""
Copy On Write (COW) container storage driver. Valid drivers are "overlay", "vfs", "devmapper", "aufs", "btrfs", and "zfs". Some drivers (for example, "zfs", "btrfs", and "aufs") may not work if your kernel lacks support for the filesystem.
Copy On Write (COW) container storage driver. Valid drivers are "overlay", "vfs", "aufs", "btrfs", and "zfs". Some drivers (for example, "zfs", "btrfs", and "aufs") may not work if your kernel lacks support for the filesystem.
This field is required to guarantee proper operation.
This field is required to guarantee proper operation.
Valid rootless drivers are "btrfs", "overlay", and "vfs".
Valid rootless drivers are "btrfs", "overlay", and "vfs".
Rootless users default to the driver defined in the system configuration when possible.
Rootless users default to the driver defined in the system configuration when possible.
@ -84,7 +84,7 @@ The `storage.options` table supports the following options:
**additionalimagestores**=[]
**additionalimagestores**=[]
Paths to additional container image stores. Usually these are read/only and stored on remote network shares.
Paths to additional container image stores. Usually these are read/only and stored on remote network shares.
Allows specification of how storage is populated when pulling images. This
Allows specification of how storage is populated when pulling images. This
option can speed the pulling process of images compressed with format zstd:chunked. Containers/storage looks
option can speed the pulling process of images compressed with format zstd:chunked. Containers/storage looks
@ -95,7 +95,7 @@ container registry. These options can deduplicate pulling of content, disk
storage of content and can allow the kernel to use less memory when running
storage of content and can allow the kernel to use less memory when running
containers.
containers.
containers/storage supports three keys
containers/storage supports four keys
* enable_partial_images="true" | "false"
* enable_partial_images="true" | "false"
Tells containers/storage to look for files previously pulled in storage
Tells containers/storage to look for files previously pulled in storage
rather then always pulling them from the container registry.
rather then always pulling them from the container registry.
@ -107,28 +107,10 @@ containers/storage supports three keys
previously pulled content which can be used when attempting to avoid
previously pulled content which can be used when attempting to avoid
pulling content from the container registry
pulling content from the container registry
* convert_images = "false" | "true"
* convert_images = "false" | "true"
If set to true, containers/storage will convert images to the a format compatible with
If set to true, containers/storage will convert images to a format compatible with
partial pulls in order to take advantage of local deduplication and hardlinking. It is an
partial pulls in order to take advantage of local deduplication and hardlinking. It is an
expensive operation so it is not enabled by default.
expensive operation so it is not enabled by default.
**remap-uids=**""
**remap-gids=**""
Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of a container, to the UIDs/GIDs outside of the container, and the length of the range of UIDs/GIDs. Additional mapped sets can be listed and will be heeded by libraries, but there are limits to the number of mappings which the kernel will allow when you later attempt to run a container.
Example
remap-uids = "0:1668442479:65536"
remap-gids = "0:1668442479:65536"
These mappings tell the container engines to map UID 0 inside of the container to UID 1668442479 outside. UID 1 will be mapped to 1668442480. UID 2 will be mapped to 1668442481, etc, for the next 65533 UIDs in succession.
**remap-user**=""
**remap-group**=""
Remap-User/Group is a user name which can be used to look up one or more UID/GID ranges in the /etc/subuid or /etc/subgid file. Mappings are set up starting with an in-container ID of 0 and then a host-level ID taken from the lowest range that matches the specified name, and using the length of that range. Additional ranges are then assigned, using the ranges which specify the lowest host-level IDs first, to the lowest not-yet-mapped in-container ID, until all of the entries have been used for maps. This setting overrides the Remap-UIDs/GIDs setting.
Example
remap-user = "containers"
remap-group = "containers"
**root-auto-userns-user**=""
**root-auto-userns-user**=""
Root-auto-userns-user is a user name which can be used to look up one or more UID/GID ranges in the /etc/subuid and /etc/subgid file. These ranges will be partitioned to containers configured to create automatically a user namespace. Containers configured to automatically create a user namespace can still overlap with containers having an explicit mapping set. This setting is ignored when running as rootless.
Root-auto-userns-user is a user name which can be used to look up one or more UID/GID ranges in the /etc/subuid and /etc/subgid file. These ranges will be partitioned to containers configured to create automatically a user namespace. Containers configured to automatically create a user namespace can still overlap with containers having an explicit mapping set. This setting is ignored when running as rootless.
@ -158,66 +140,6 @@ The `storage.options.btrfs` table supports the following options:
**size**=""
**size**=""
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
### STORAGE OPTIONS FOR THINPOOL (devicemapper) TABLE
The `storage.options.thinpool` table supports the following options for the `devicemapper` driver:
**autoextend_percent**=""
Tells the thinpool driver the amount by which the thinpool needs to be grown. This is specified in terms of % of pool size. So a value of 20 means that when threshold is hit, pool will be grown by 20% of existing pool size. (default: 20%)
**autoextend_threshold**=""
Tells the driver the thinpool extension threshold in terms of percentage of pool size. For example, if threshold is 60, that means when pool is 60% full, threshold has been hit. (default: 80%)
**basesize**=""
Specifies the size to use when creating the base device, which limits the size of images and containers. (default: 10g)
**blocksize**=""
Specifies a custom blocksize to use for the thin pool. (default: 64k)
**directlvm_device**=""
Specifies a custom block storage device to use for the thin pool. Required for using graphdriver `devicemapper`.
**directlvm_device_force**=""
Tells driver to wipe device (directlvm_device) even if device already has a filesystem. (default: false)
**fs**="xfs"
Specifies the filesystem type to use for the base device. (default: xfs)
**log_level**=""
Sets the log level of devicemapper.
0: LogLevelSuppress 0 (default)
2: LogLevelFatal
3: LogLevelErr
4: LogLevelWarn
5: LogLevelNotice
6: LogLevelInfo
7: LogLevelDebug
**metadata_size**=""
metadata_size is used to set the `pvcreate --metadatasize` options when creating thin devices. (Default 128k)
**min_free_space**=""
Specifies the min free space percent in a thin pool required for new device creation to succeed. Valid values are from 0% - 99%. Value 0% disables. (default: 10%)
**mkfsarg**=""
Specifies extra mkfs arguments to be used when creating the base device.
**mountopt**=""
Comma separated list of default options to be used to mount container images. Suggested value "nodev". Mount options are documented in the mount(8) man page.
**size**=""
Maximum size of a container image. This flag can be used to set quota on the size of container images. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
**use_deferred_deletion**=""
Marks thinpool device for deferred deletion. If the thinpool is in use when the driver attempts to delete it, the driver will attempt to delete device every 30 seconds until successful, or when it restarts. Deferred deletion permanently deletes the device and all data stored in the device will be lost. (default: true).
**use_deferred_removal**=""
Marks devicemapper block device for deferred removal. If the device is in use when its driver attempts to remove it, the driver tells the kernel to remove the device as soon as possible. Note this does not free up the disk space, use deferred deletion to fully remove the thinpool. (default: true).
**xfs_nospace_max_retries**=""
Specifies the maximum number of retries XFS should attempt to complete IO when ENOSPC (no space) error is returned by underlying storage device. (default: 0, which means to try continuously.)
### STORAGE OPTIONS FOR OVERLAY TABLE
### STORAGE OPTIONS FOR OVERLAY TABLE
The `storage.options.overlay` table supports the following options:
The `storage.options.overlay` table supports the following options:
@ -278,6 +200,9 @@ based file systems.
**size**=""
**size**=""
Maximum size of a read/write layer. This flag can be used to set quota on the size of a read/write layer of a container. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
Maximum size of a read/write layer. This flag can be used to set quota on the size of a read/write layer of a container. (format: <number>[<unit>], where unit = b (bytes), k (kilobytes), m (megabytes), or g (gigabytes))
**use_composefs** = "false"
Use ComposeFS to mount the data layers image. ComposeFS support is experimental and not recommended for production use. (default: false)
### STORAGE OPTIONS FOR VFS TABLE
### STORAGE OPTIONS FOR VFS TABLE
The `storage.options.vfs` table supports the following options:
The `storage.options.vfs` table supports the following options:
@ -9,7 +9,7 @@ containers-transports - description of supported transports for copying and stor
## DESCRIPTION
## DESCRIPTION
Tools which use the containers/image library, including skopeo(1), buildah(1), podman(1), all share a common syntax for referring to container images in various locations.
Tools which use the containers/image library, including skopeo(1), buildah(1), podman(1), all share a common syntax for referring to container images in various locations.
The general form of the syntax is _transport:details_, where details are dependent on the specified transport, which are documented below.
The general form of the syntax is _transport_`:`_details_, where details are dependent on the specified transport, which are documented below.
The semantics of the image names ultimately depend on the environment where
The semantics of the image names ultimately depend on the environment where
they are evaluated. For example: if evaluated on a remote server, image names
they are evaluated. For example: if evaluated on a remote server, image names
@ -18,14 +18,14 @@ directory of the image consumer.
<!-- atomic: is deprecated and not documented here. -->
<!-- atomic: is deprecated and not documented here. -->
The format of _docker-reference_ is described in detail in the **docker** transport.
The format of _docker-reference_ is described in detail in the **docker** transport.
The _storage-specifier_ allows for referencing storage locations on the file system and has the format `[[driver@]root[+run-root][:options]]` where the optional `driver` refers to the storage driver (e.g., overlay or btrfs) and where `root` is an absolute path to the storage's root directory.
The _storage-specifier_ allows for referencing storage locations on the file system and has the format `[`[_driver_`@`]_root_[`+`_run-root_][`:`_options_]`]` where the optional _driver_ refers to the storage driver (e.g., `overlay` or `btrfs`) and where _root_ is an absolute path to the storage's root directory.
The optional `run-root` can be used to specify the run directory of the storage where all temporary writable content is stored.
The optional _run-root_ can be used to specify the run directory of the storage where all temporary writable content is stored.
The optional `options` are a comma-separated list of driver-specific options.
The optional _options_ are a comma-separated list of driver-specific options.
Please refer to containers-storage.conf(5) for further information on the drivers and supported options.
Please refer to containers-storage.conf(5) for further information on the drivers and supported options.
### **dir:**_path_
### **dir:**_path_
@ -40,34 +40,38 @@ By default, uses the authorization state in `$XDG_RUNTIME_DIR/containers/auth.js
If the authorization state is not found there, `$HOME/.docker/config.json` is checked, which is set using docker-login(1).
If the authorization state is not found there, `$HOME/.docker/config.json` is checked, which is set using docker-login(1).
The containers-registries.conf(5) further allows for configuring various settings of a registry.
The containers-registries.conf(5) further allows for configuring various settings of a registry.
Note that a _docker-reference_ has the following format: _name_[**:**_tag_ | **@**_digest_].
Note that a _docker-reference_ has the following format: _name_[`:`_tag_ | `@`_digest_].
While the docker transport does not support both a tag and a digest at the same time some formats like containers-storage do.
While the docker transport does not support both a tag and a digest at the same time some formats like containers-storage do.
Digests can also be used in an image destination as long as the manifest matches the provided digest.
Digests can also be used in an image destination as long as the manifest matches the provided digest.
The docker transport supports pushing images without a tag or digest to a registry when the image name is suffixed with **@@unknown-digest@@**. The _name_**@@unknown-digest@@** reference format cannot be used with a reference that has a tag or digest.
The docker transport supports pushing images without a tag or digest to a registry when the image name is suffixed with `@@unknown-digest@@`. The _name_`@@unknown-digest@@` reference format cannot be used with a reference that has a tag or digest.
The digest of images can be explored with skopeo-inspect(1).
The digest of images can be explored with skopeo-inspect(1).
If `name` does not contain a slash, it is treated as `docker.io/library/name`.
If _name_ does not contain a slash, it is treated as `docker.io/library/`_name_.
Otherwise, the component before the first slash is checked if it is recognized as a `hostname[:port]` (i.e., it contains either a . or a :, or the component is exactly localhost).
Otherwise, the component before the first slash is checked if it is recognized as a _hostname_[`:`_port_] (i.e., it contains either a `.` or a `:`, or the component is exactly `localhost`).
If the first component of name is not recognized as a `hostname[:port]`, `name` is treated as `docker.io/name`.
If the first component of name is not recognized as a _hostname_[`:`_port_], _name_ is treated as `docker.io/`_name_.
Files in those locations are not loaded by default but only on-demand. They are loaded after all system and user configuration files but before `CONTAINERS_CONF_OVERRIDE` hence allowing for overriding system and user configs.
Files in those locations are not loaded by default but only on-demand. They are loaded after all system and user configuration files but before `CONTAINERS_CONF_OVERRIDE` hence allowing for overriding system and user configs.
Modules are currently supported by podman(1). The `podman --module` flag allows for loading a module and can be specified multiple times. If the specified value is an absolute path, the config file will be loaded directly. Relative paths are resolved relative to the three module directories mentioned above and in the specified order such that modules in `$HOME` allow for overriding those in `/etc` and `/usr/share`. Modules in `$HOME` (or `$XDG_CONFIG_HOME` if specified) are only used for rootless users.
Modules are currently supported by podman(1). The `podman --module` flag allows for loading a module and can be specified multiple times. If the specified value is an absolute path, the config file will be loaded directly. Relative paths are resolved relative to the three module directories mentioned above and in the specified order such that modules in `$XDG_CONFIG_HOME/$HOME` allow for overriding those in `/etc` and `/usr/share`.
## APPENDING TO STRING ARRAYS
## APPENDING TO STRING ARRAYS
@ -59,7 +58,7 @@ Consider the following example:
modules1.conf: env=["1=true"]
modules1.conf: env=["1=true"]
modules2.conf: env=["2=true"]
modules2.conf: env=["2=true"]
modules3.conf: env=["3=true", {append=true}]
modules3.conf: env=["3=true", {append=true}]
modules3.conf: env=["4=true"]
modules4.conf: env=["4=true"]
```
```
After loading the files in the given order, the final contents are `env=["2=true", "3=true", "4=true"]`. If modules4.conf would set `{append=false}`, the final contents would be `env=["4=true"]`.
After loading the files in the given order, the final contents are `env=["2=true", "3=true", "4=true"]`. If modules4.conf would set `{append=false}`, the final contents would be `env=["4=true"]`.
@ -118,7 +117,7 @@ Options are:
**cgroupns**="private"
**cgroupns**="private"
Default way to to create a cgroup namespace for the container.
Default way to create a cgroup namespace for the container.
Options are:
Options are:
`private` Create private Cgroup Namespace for the container.
`private` Create private Cgroup Namespace for the container.
`host` Share host Cgroup Namespace with the container.
`host` Share host Cgroup Namespace with the container.
@ -227,9 +226,16 @@ Path to the container-init binary, which forwards signals and reaps processes
within containers. Note that the container-init binary will only be used when
within containers. Note that the container-init binary will only be used when
the `--init` for podman-create and podman-run is set.
the `--init` for podman-create and podman-run is set.
**interface_name**=""
Default way to set interface names inside containers. Defaults to legacy pattern
of ethX, where X is an integer, when left undefined.
Options are:
`device` Uses the network_interface name from the network config as interface name. Falls back to the ethX pattern if the network_interface is not set.
**ipcns**="shareable"
**ipcns**="shareable"
Default way to to create a IPC namespace for the container.
Default way to create a IPC namespace for the container.
Options are:
Options are:
`host` Share host IPC Namespace with the container.
`host` Share host IPC Namespace with the container.
`none` Create shareable IPC Namespace for the container without a private /dev/shm.
`none` Create shareable IPC Namespace for the container without a private /dev/shm.
A is a list of directories which are used to search for helper binaries.
A is a list of directories which are used to search for helper binaries.
@ -630,6 +654,10 @@ The default path on Windows is:
Path to the OCI hooks directories for automatically executed hooks.
Path to the OCI hooks directories for automatically executed hooks.
**cdi_spec_dirs**=["/etc/cdi", ...]
Directories to scan for CDI Spec files.
**image_default_format**="oci"|"v2s2"|"v2s1"
**image_default_format**="oci"|"v2s2"|"v2s1"
Manifest Type (oci, v2s2, or v2s1) to use when pulling, pushing, building
Manifest Type (oci, v2s2, or v2s1) to use when pulling, pushing, building
@ -722,10 +750,11 @@ Whether to use chroot instead of pivot_root in the runtime.
**num_locks**=2048
**num_locks**=2048
Number of locks available for containers and pods. Each created container or
Number of locks available for containers, pods, and volumes.
pod consumes one lock. The default number available is 2048. If this is
Each created container, pod, or volume consumes one lock.
changed, a lock renumbering must be performed, using the
Locks are recycled and can be reused after the associated container, pod, or volume is removed.
`podman system renumber` command.
The default number available is 2048.
If this is changed, a lock renumbering must be performed, using the `podman system renumber` command.
**pod_exit_policy**="continue"
**pod_exit_policy**="continue"
@ -749,13 +778,21 @@ Pull image before running or creating a container. The default is **missing**.
Indicates whether the application should be running in remote mode. This flag modifies the
Indicates whether the application should be running in remote mode. This flag modifies the
--remote option on container engines. Setting the flag to true will default `podman --remote=true` for access to the remote Podman service.
--remote option on container engines. Setting the flag to true will default `podman --remote=true` for access to the remote Podman service.
**retry** = 3
Number of times to retry pulling/pushing images in case of failure.
**retry_delay** = ""
Delay between retries in case pulling/pushing image fails. If set, container engines will retry at the set interval, otherwise they delay 2 seconds and then exponentially back off.
**runtime**=""
**runtime**=""
Default OCI specific runtime in runtimes that will be used by default. Must
Default OCI specific runtime in runtimes that will be used by default. Must
refer to a member of the runtimes table. Default runtime will be searched for
refer to a member of the runtimes table. Default runtime will be searched for
on the system using the priority: "crun", "runc", "kata".
on the system using the priority: "crun", "runc", "runj", "kata", "runsc", "ocijail"
The list of OCI runtimes that support running containers without CGroups.
The list of OCI runtimes that support running containers without CGroups.
@ -814,7 +851,10 @@ the primary uid/gid of the container.
**compression_format**="gzip"
**compression_format**="gzip"
Specifies the compression format to use when pushing an image. Supported values are: `gzip`, `zstd` and `zstd:chunked`.
Specifies the compression format to use when pushing an image. Supported values
are: `gzip`, `zstd` and `zstd:chunked`. This field is ignored when pushing
images to the docker-daemon and docker-archive formats. It is also ignored
when the manifest format is set to v2s2.
**compression_level**="5"
**compression_level**="5"
@ -823,10 +863,6 @@ depend on the compression format used. For gzip, valid options are
1-9, with a default of 5. For zstd, valid options are 1-20, with a
1-9, with a default of 5. For zstd, valid options are 1-20, with a
default of 3.
default of 3.
**podmansh_timeout**=30
Number of seconds to wait for podmansh logins.
## SERVICE DESTINATION TABLE
## SERVICE DESTINATION TABLE
The `engine.service_destinations` table contains configuration options used to set up remote connections to the podman service for the podman API.
The `engine.service_destinations` table contains configuration options used to set up remote connections to the podman service for the podman API.
@ -883,13 +919,13 @@ The size of the disk in GB created when init-ing a podman-machine VM
**image**=""
**image**=""
Default image URI when creating a new VM using `podman machine init`.
Image used when creating a new VM using `podman machine init`.
Options: On Linux/Mac, `testing`, `stable`, `next`. On Windows, the major
Can be specified as a registry with a bootable OCI artifact, download URL, or a local path.
version of the OS (e.g `36`) for Fedora 36. For all platforms you can
Registry target must be in the form of `docker://registry/repo/image:version`.
alternatively specify a custom download URL to an image. Container engines
Container engines translate URIs $OS and $ARCH to the native OS and ARCH.
translate URIs $OS and $ARCH to the native OS and ARCH. URI "https://example.com/$OS/$ARCH/foobar.ami" would become "https://example.com/linux/amd64/foobar.ami" on a Linux AMD machine.
URI "https://example.com/$OS/$ARCH/foobar.ami" would become
The default value
"https://example.com/linux/amd64/foobar.ami" on a Linux AMD machine.
is `testing` on Linux/Mac, and on Windows.
If unspecified, the default Podman machine image will be used.
**memory**=2048
**memory**=2048
@ -917,6 +953,11 @@ Virtualization provider to be used for running a podman-machine VM. Empty value
is interpreted as the default provider for the current host OS. On Linux/Mac
is interpreted as the default provider for the current host OS. On Linux/Mac
default is `QEMU` and on Windows it is `WSL`.
default is `QEMU` and on Windows it is `WSL`.
**rosetta**="true"
Rosetta supports running x86_64 Linux binaries on a Podman machine on Apple silicon.
The default value is `true`. Supported on AppleHV(arm64) machines only.
## FARMS TABLE
## FARMS TABLE
The `farms` table contains configuration options used to group up remote connections into farms that will be used when sending out builds to different machines in a farm via `podman buildfarm`.
The `farms` table contains configuration options used to group up remote connections into farms that will be used when sending out builds to different machines in a farm via `podman buildfarm`.
@ -928,6 +969,25 @@ The default farm to use when farming out builds.
Map of farms created where the key is the farm name and the value is the list of system connections.
Map of farms created where the key is the farm name and the value is the list of system connections.
## PODMANSH TABLE
The `podmansh` table contains configuration options used by podmansh.
**shell**="/bin/sh"
The shell to spawn in the container.
The default value is `/bin/sh`.
**container**="podmansh"
Name of the container that podmansh joins.
The default value is `podmansh`.
**timeout**=0
Number of seconds to wait for podmansh logins. This value if favoured over the deprecated field `engine.podmansh_timeout` if set.
The default value is 30.
# FILES
# FILES
**containers.conf**
**containers.conf**
@ -937,8 +997,8 @@ provide a default configuration. Administrators can override fields in this
file by creating __/etc/containers/containers.conf__ to specify their own
file by creating __/etc/containers/containers.conf__ to specify their own
configuration. They may also drop `.conf` files in
configuration. They may also drop `.conf` files in
__/etc/containers/containers.conf.d__ which will be loaded in alphanumeric order.
__/etc/containers/containers.conf.d__ which will be loaded in alphanumeric order.
Rootless users can further override fields in the config by creating a config
For user specific configuration it reads __\$XDG_CONFIG_HOME/containers/containers.conf__ and
file stored in the __$HOME/.config/containers/containers.conf__ file or __.conf__ files in __$HOME/.config/containers/containers.conf.d__.
__\$XDG_CONFIG_HOME/containers/containers.conf.d/\*.conf__ files. When `$XDG_CONFIG_HOME` is not set it falls back to using `$HOME/.config` instead.
Fields specified in a containers.conf file override the default options, as
Fields specified in a containers.conf file override the default options, as
well as options in previously loaded containers.conf files.
well as options in previously loaded containers.conf files.
