opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-08-06 03:19:52 +08:00
Code Issues Packages Projects Releases Wiki Activity

[CI:DOCS] Cleanup some man pages to display options with line breaks

Browse Source 
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
This commit is contained in:
Daniel J Walsh
2023-02-08 14:46:41 -05:00
parent 84c4281c8d
commit ec4ab08c8b
3 changed files with 29 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/source/markdown/podman-kube-play.1.md.in
View File

@ -8,12 +8,16 @@ podman-kube-play - Create containers, pods and volumes based on Kubernetes YAML
## DESCRIPTION
**podman kube play** will read in a structured file of Kubernetes YAML. It will then recreate the containers, pods or volumes described in the YAML. Containers within a pod are then started and the ID of the new Pod or the name of the new Volume is output. If the yaml file is specified as "-" then `podman kube play` will read the YAML file from stdin.
Using the `--down` command line option, it is also capable of tearing down the pods created by a previous run of `podman kube play`.
Using the `--replace` command line option, it will tear down the pods(if any) created by a previous run of `podman kube play` and recreate the pods with the Kubernetes YAML file.
Ideally the input file would be one created by Podman (see podman-kube-generate(1)). This would guarantee a smooth import and expected results.
The input can also be a URL that points to a YAML file such as https://podman.io/demo.yml. `podman kube play` will read the YAML from the URL and create pods and containers from it.
Using the `--down` command line option, it is also capable of tearing down the pods created by a previous run of `podman kube play`.
Using the `--replace` command line option, it will tear down the pods(if any) created by a previous run of `podman kube play` and recreate the pods with the Kubernetes YAML file.
Ideally the input file would be one created by Podman (see podman-kube-generate(1)). This would guarantee a smooth import and expected results.
Currently, the supported Kubernetes kinds are:
- Pod
- Deployment
- PersistentVolumeClaim
@ -21,7 +25,11 @@ Currently, the supported Kubernetes kinds are:
`Kubernetes Pods or Deployments`
Only three volume types are supported by kube play, the *hostPath*, *emptyDir*, and *persistentVolumeClaim* volume types. For the *hostPath* volume type, only the *default (empty)*, *DirectoryOrCreate*, *Directory*, *FileOrCreate*, *File*, *Socket*, *CharDevice* and *BlockDevice* subtypes are supported. Podman interprets the value of *hostPath* *path* as a file path when it contains at least one forward slash, otherwise Podman treats the value as the name of a named volume. When using a *persistentVolumeClaim*, the value for *claimName* is the name for the Podman named volume. When using an *emptyDir* volume, podman creates an anonymous volume that is attached the containers running inside the pod and is deleted once the pod is removed.
Only three volume types are supported by kube play, the *hostPath*, *emptyDir*, and *persistentVolumeClaim* volume types.
- When using the *hostPath* volume type, only the *default (empty)*, *DirectoryOrCreate*, *Directory*, *FileOrCreate*, *File*, *Socket*, *CharDevice* and *BlockDevice* subtypes are supported. Podman interprets the value of *hostPath* *path* as a file path when it contains at least one forward slash, otherwise Podman treats the value as the name of a named volume.
- When using a *persistentVolumeClaim*, the value for *claimName* is the name for the Podman named volume.
- When using an *emptyDir* volume, Podman creates an anonymous volume that is attached the containers running inside the pod and is deleted once the pod is removed.
Note: The default restart policy for containers is `always`. You can change the default by setting the `restartPolicy` field in the spec.

11
docs/source/markdown/podman-network-create.1.md
View File

@ -34,6 +34,7 @@ Driver to manage the network. Currently `bridge`, `macvlan` and `ipvlan` are sup
As rootless the `macvlan` and `ipvlan` driver have no access to the host network interfaces because rootless networking requires a separate network namespace.
Special considerations for the *netavark* backend:
- The `macvlan` driver requires the `--subnet` option, DHCP is currently not supported.
- The `ipvlan` driver is not currently supported.
@ -61,9 +62,12 @@ The argument order of the **--subnet**, **--gateway** and **--ip-range** options
#### **--ipam-driver**=*driver*
Set the ipam driver (IP Address Management Driver) for the network. When unset podman will choose an
ipam driver automatically based on the network driver. Valid values are:
- `host-local`: IP addresses are assigned locally.
ipam driver automatically based on the network driver.
Valid values are:
- `dhcp`: IP addresses are assigned from a dhcp server on the network. This driver is not yet supported with netavark. For CNI the *dhcp* plugin needs to be activated before.
- `host-local`: IP addresses are assigned locally.
- `none`: No ip addresses are assigned to the interfaces.
View the driver in the **podman network inspect** output under the `ipam_options` field.
@ -81,14 +85,17 @@ Set metadata for a network (e.g., --label mykey=value).
Set driver specific options.
All drivers accept the `mtu` and `metric` options.
- `mtu`: Sets the Maximum Transmission Unit (MTU) and takes an integer value.
- `metric` Sets the Route Metric for the default route created in every container joined to this network. Accepts a positive integer value. Can only be used with the Netavark network backend.
Additionally the `bridge` driver supports the following options:
- `vlan`: This option assign VLAN tag and enables vlan\_filtering. Defaults to none.
- `isolate`: This option isolates networks by blocking traffic between those that have this option enabled.
The `macvlan` and `ipvlan` driver support the following options:
- `parent`: The host device which should be used for the macvlan interface. Defaults to the default route interface.
- `mode`: This option sets the specified ip/macvlan mode on the interface.
- Supported values for `macvlan` are `bridge`, `private`, `vepa`, `passthru`. Defaults to `bridge`.

11
docs/source/markdown/podman-volume-create.1.md
View File

@ -19,9 +19,12 @@ driver options can be set using the **--opt** flag.
Specify the volume driver name (default **local**).
There are two drivers supported by Podman itself: **local** and **image**.
The **local** driver uses a directory on disk as the backend by default, but can also use the **mount(8)** command to mount a filesystem as the volume if **--opt** is specified.
The **image** driver uses an image as the backing store of for the volume.
An overlay filesystem will be created, which allows changes to the volume to be committed as a new layer on top of the image.
Using a value other than **local** or **image**, Podman will attempt to create the volume using a volume plugin with the given name.
Such plugins must be defined in the **volume_plugins** section of the **[containers.conf(5)](https://github.com/containers/common/blob/main/docs/containers.conf.5.md)** configuration file.
@ -41,10 +44,12 @@ Set metadata for a volume (e.g., --label mykey=value).
Set driver specific options.
For the default driver, **local**, this allows a volume to be configured to mount a filesystem on the host.
For the `local` driver the following options are supported: `type`, `device`, `o`, and `[no]copy`.
The `type` option sets the type of the filesystem to be mounted, and is equivalent to the `-t` flag to **mount(8)**.
The `device` option sets the device to be mounted, and is equivalent to the `device` argument to **mount(8)**.
The `copy` option enables copying files from the container image path where the mount is created to the newly created volume on the first run. `copy` is the default.
- The `type` option sets the type of the filesystem to be mounted, and is equivalent to the `-t` flag to **mount(8)**.
- The `device` option sets the device to be mounted, and is equivalent to the `device` argument to **mount(8)**.
- The `copy` option enables copying files from the container image path where the mount is created to the newly created volume on the first run. `copy` is the default.
The `o` option sets options for the mount, and is equivalent to the filesystem
options (also `-o`) passed to **mount(8)** with the following exceptions: