[CI:DOCS] Fix typos and improve language
Signed-off-by: Erik Sjölund <erik.sjolund@gmail.com>
This commit is contained in:
Erik Sjölund
parent
350a835a0f
commit
76e9dbf8a6
|
|
@ -58,7 +58,7 @@ var (
|
|||
|
||||
// buildah source pull
|
||||
sourcePullOptions = source.PullOptions{}
|
||||
sourcePullDescription = ` Pull a source image from a registry to a specified path. The pull operation will fail if the image does not comply with a source-image OCI rartifact.
|
||||
sourcePullDescription = ` Pull a source image from a registry to a specified path. The pull operation will fail if the image does not comply with a source-image OCI artifact.
|
||||
|
||||
Note that the buildah-source command and all its subcommands are experimental and may be subject to future changes.
|
||||
`
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ Container engines pass secret the secret file into the build using the `--secret
|
|||
|
||||
**--mount**=*type=secret,TYPE-SPECIFIC-OPTION[,...]*
|
||||
|
||||
- `id` is the identifier to 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 bud --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.
|
||||
|
||||
|
|
@ -190,7 +190,7 @@ The secret needs to be passed to the build using the --secret flag. The final im
|
|||
it possible to **RUN** commands using a base image that does not contain `/bin/sh`.
|
||||
|
||||
Note that the exec form is parsed as a JSON array, which means that you must
|
||||
use double-quotes (") around words not single-quotes (').
|
||||
use double-quotes (") around words, not single-quotes (').
|
||||
|
||||
**CMD**
|
||||
-- **CMD** has three forms:
|
||||
|
|
@ -216,7 +216,7 @@ The secret needs to be passed to the build using the --secret flag. The final im
|
|||
If you use the shell form of the **CMD**, the `<command>` executes in `/bin/sh -c`:
|
||||
|
||||
Note that the exec form is parsed as a JSON array, which means that you must
|
||||
use double-quotes (") around words not single-quotes (').
|
||||
use double-quotes (") around words, not single-quotes (').
|
||||
|
||||
```
|
||||
FROM ubuntu
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ src
|
|||
```
|
||||
|
||||
`*/*.c`
|
||||
Excludes files and directories whose names ends with .c in any top level subdirectory. For example, the source file include/rootless.c.
|
||||
Excludes files and directories whose names end with .c in any top level subdirectory. For example, the source file include/rootless.c.
|
||||
|
||||
`**/output*`
|
||||
Excludes files and directories starting with `output` from any directory.
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Set the ARCH of the image to be built, and that of the base image to be pulled,
|
|||
|
||||
**--authfile** *path*
|
||||
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using using `buildah login`.
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using `buildah login`.
|
||||
|
||||
If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using `docker login`.
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-con
|
|||
Limit the CPU CFS (Completely Fair Scheduler) quota
|
||||
|
||||
Limit the container's CPU usage. By default, containers run with the full
|
||||
CPU resource. This flag tell the kernel to restrict the container's CPU usage
|
||||
CPU resource. This flag tells the kernel to restrict the container's CPU usage
|
||||
to the quota you specify.
|
||||
|
||||
On some systems, changing the CPU limits may not be allowed for non-root
|
||||
|
|
@ -328,7 +328,7 @@ no limit on the number of jobs that run in parallel.
|
|||
Add an image *label* (e.g. label=*value*) to the image metadata. Can be used multiple times.
|
||||
|
||||
Users can set a special LABEL **io.containers.capabilities=CAP1,CAP2,CAP3** in
|
||||
a Containerfile that specified the list of Linux capabilities required for the
|
||||
a Containerfile that specifies the list of Linux capabilities required for the
|
||||
container to run properly. This label specified in a container image tells
|
||||
container engines, like Podman, to run the container with just these
|
||||
capabilities. The container engine launches the container with just the specified
|
||||
|
|
@ -531,7 +531,7 @@ To later use the ssh agent, use the --mount flag in a `RUN` instruction within a
|
|||
|
||||
**--stdin**
|
||||
|
||||
Pass stdin into the RUN containers. Sometime commands being RUN within a Containerfile
|
||||
Pass stdin into the RUN containers. Sometimes commands being RUN within a Containerfile
|
||||
want to request information from the user. For example apt asking for a confirmation for install.
|
||||
Use --stdin to be able to interact from the terminal during the build.
|
||||
|
||||
|
|
@ -626,7 +626,7 @@ Users can specify the maps directly using `--userns-gid-map` described in the bu
|
|||
|
||||
**--uts** *how*
|
||||
|
||||
Sets the configuration for UTS namespaces when the handling `RUN` instructions.
|
||||
Sets the configuration for UTS namespaces when handling `RUN` instructions.
|
||||
The configured value can be "" (the empty string) or "container" to indicate
|
||||
that a new UTS namespace should be created, or it can be "host" to indicate
|
||||
that the UTS namespace in which `buildah` itself is being run should be reused,
|
||||
|
|
@ -688,14 +688,14 @@ Only the current container can use a private volume.
|
|||
|
||||
The `:O` flag tells Buildah to mount the directory from the host as a temporary storage using the Overlay file system. The `RUN` command containers are allowed to modify contents within the mountpoint and are stored in the container storage in a separate directory. In Overlay FS terms the source directory will be the lower, and the container storage directory will be the upper. Modifications to the mount point are destroyed when the `RUN` command finishes executing, similar to a tmpfs mount point.
|
||||
|
||||
Any subsequent execution of `RUN` commands sees the original source directory content, any changes from previous RUN commands no longer exists.
|
||||
Any subsequent execution of `RUN` commands sees the original source directory content, any changes from previous RUN commands no longer exist.
|
||||
|
||||
One use case of the `overlay` mount is sharing the package cache from the host into the container to allow speeding up builds.
|
||||
|
||||
Note:
|
||||
|
||||
- The `O` flag is not allowed to be specified with the `Z` or `z` flags. Content mounted into the container is labeled with the private label.
|
||||
On SELinux systems, labels in the source directory needs to be readable by the container label. If not, SELinux container separation must be disabled for the container to work.
|
||||
On SELinux systems, labels in the source directory need to be readable by the container label. If not, SELinux container separation must be disabled for the container to work.
|
||||
- Modification of the directory volume mounted into the container with an overlay mount can cause unexpected failures. It is recommended that you do not modify the directory until the container finishes running.
|
||||
|
||||
By default bind mounted volumes are `private`. That means any mounts done
|
||||
|
|
@ -872,7 +872,7 @@ src
|
|||
```
|
||||
|
||||
`*/*.c`
|
||||
Excludes files and directories whose names ends with .c in any top level subdirectory. For example, the source file include/rootless.c.
|
||||
Excludes files and directories whose names end with .c in any top level subdirectory. For example, the source file include/rootless.c.
|
||||
|
||||
`**/output*`
|
||||
Excludes files and directories starting with `output` from any directory.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ The image ID of the image that was created. On error, 1 is returned and errno i
|
|||
|
||||
**--authfile** *path*
|
||||
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using using `buildah login`.
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using `buildah login`.
|
||||
|
||||
If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using `docker login`.
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Note: this setting is not present in the OCIv1 image format, so it is discarded
|
|||
|
||||
Set the *entry point* for containers based on any images which will be built
|
||||
using the specified container. buildah supports two formats for entrypoint. It
|
||||
can be specified as a simple string, or as a array of commands.
|
||||
can be specified as a simple string, or as an array of commands.
|
||||
|
||||
Note: When the entrypoint is specified as a string, container runtimes will
|
||||
ignore the `cmd` value of the container image. However if you use the array
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Sets the user and group ownership of the destination content.
|
|||
**--contextdir** *directory*
|
||||
|
||||
Build context directory. Specifying a context directory causes Buildah to
|
||||
chroot into a the context directory. This means copying files pointed at
|
||||
chroot into the context directory. This means copying files pointed at
|
||||
by symbolic links outside of the chroot will fail.
|
||||
|
||||
**--from** *containerOrImage*
|
||||
|
|
@ -96,7 +96,7 @@ src
|
|||
```
|
||||
|
||||
`*/*.c`
|
||||
Excludes files and directories whose names ends with .c in any top level subdirectory. For example, the source file include/rootless.c.
|
||||
Excludes files and directories whose names end with .c in any top level subdirectory. For example, the source file include/rootless.c.
|
||||
|
||||
`**/output*`
|
||||
Excludes files and directories starting with `output` from any directory.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Set the ARCH of the image to be pulled to the provided value instead of using th
|
|||
|
||||
**--authfile** *path*
|
||||
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using using `buildah login`.
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using `buildah login`.
|
||||
|
||||
If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using `docker login`.
|
||||
|
||||
|
|
@ -107,14 +107,14 @@ Write the container ID to the file.
|
|||
|
||||
Limit the CPU CFS (Completely Fair Scheduler) period
|
||||
|
||||
Limit the container's CPU usage. This flag tell the kernel to restrict the container's CPU usage to the period you specify.
|
||||
Limit the container's CPU usage. This flag tells the kernel to restrict the container's CPU usage to the period you specify.
|
||||
|
||||
**--cpu-quota**=*0*
|
||||
|
||||
Limit the CPU CFS (Completely Fair Scheduler) quota
|
||||
|
||||
Limit the container's CPU usage. By default, containers run with the full
|
||||
CPU resource. This flag tell the kernel to restrict the container's CPU usage
|
||||
CPU resource. This flag tells the kernel to restrict the container's CPU usage
|
||||
to the quota you specify.
|
||||
|
||||
**--cpu-shares**, **-c**=*0*
|
||||
|
|
@ -527,14 +527,14 @@ Only the current container can use a private volume.
|
|||
|
||||
The `:O` flag tells Buildah to mount the directory from the host as a temporary storage using the Overlay file system. The `RUN` command containers are allowed to modify contents within the mountpoint and are stored in the container storage in a separate directory. In Overlay FS terms the source directory will be the lower, and the container storage directory will be the upper. Modifications to the mount point are destroyed when the `RUN` command finishes executing, similar to a tmpfs mount point.
|
||||
|
||||
Any subsequent execution of `RUN` commands sees the original source directory content, any changes from previous RUN commands no longer exists.
|
||||
Any subsequent execution of `RUN` commands sees the original source directory content, any changes from previous RUN commands no longer exist.
|
||||
|
||||
One use case of the `overlay` mount is sharing the package cache from the host into the container to allow speeding up builds.
|
||||
|
||||
Note:
|
||||
|
||||
- The `O` flag is not allowed to be specified with the `Z` or `z` flags. Content mounted into the container is labeled with the private label.
|
||||
On SELinux systems, labels in the source directory needs to be readable by the container label. If not, SELinux container separation must be disabled for the container to work.
|
||||
On SELinux systems, labels in the source directory need to be readable by the container label. If not, SELinux container separation must be disabled for the container to work.
|
||||
- Modification of the directory volume mounted into the container with an overlay mount can cause unexpected failures. It is recommended that you do not modify the directory until the container finishes running.
|
||||
|
||||
By default bind mounted volumes are `private`. That means any mounts done
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ is not set, the default is /run/containers/$UID/auth.json.
|
|||
|
||||
**--authfile**
|
||||
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using using `buildah login`.
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using `buildah login`.
|
||||
|
||||
Note: You can also override the default path of the authentication file by setting the REGISTRY\_AUTH\_FILE
|
||||
environment variable. `export REGISTRY_AUTH_FILE=path`
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ retrieved from the image's configuration information.
|
|||
|
||||
**--authfile** *path*
|
||||
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using using `buildah login`.
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using `buildah login`.
|
||||
|
||||
If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using `docker login`.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Set the ARCH of the image to be pulled to the provided value instead of using th
|
|||
|
||||
**--authfile** *path*
|
||||
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using using `buildah login`.
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using `buildah login`.
|
||||
|
||||
If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using `docker login`.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ the list or index itself.
|
|||
|
||||
**--authfile** *path*
|
||||
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using using `buildah login`.
|
||||
Path of the authentication file. Default is ${XDG_\RUNTIME\_DIR}/containers/auth.json. If XDG_RUNTIME_DIR is not set, the default is /run/containers/$UID/auth.json. This file is created using `buildah login`.
|
||||
|
||||
If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using `docker login`.
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ Don't copy signatures when pushing images.
|
|||
|
||||
**--rm**
|
||||
|
||||
When pushing a the manifest list or image index, delete them from local storage if pushing succeeds.
|
||||
When pushing a manifest list or image index, delete them from local storage if pushing succeeds.
|
||||
|
||||
**--sign-by** *fingerprint*
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ This example pushes the image specified by the imageID to a private container re
|
|||
|
||||
`# buildah push --authfile /tmp/auths/myauths.json imageID docker://registry.example.com/repository:tag`
|
||||
|
||||
This example pushes the image specified by the imageID and puts into the local docker container store.
|
||||
This example pushes the image specified by the imageID and puts it into the local docker container store.
|
||||
|
||||
`# buildah push imageID docker-daemon:image:tag`
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ buildah\-source\-pull - Pull a source image from a registry to a specified path
|
|||
|
||||
## DESCRIPTION
|
||||
Pull a source image from a registry to a specified path. The pull operation
|
||||
will fail if the image does not comply with a source-image OCI rartifact.
|
||||
will fail if the image does not comply with a source-image OCI artifact.
|
||||
|
||||
Note that the buildah-source command and all its subcommands are experimental
|
||||
and may be subject to future changes.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ help of the *newuidmap(1)* and *newgidmap(1)* helpers.
|
|||
buildah unshare is useful for troubleshooting unprivileged operations and for
|
||||
manually clearing storage and other data related to images and containers.
|
||||
|
||||
It is also useful if you want to use the `buildah mount` command. If an unprivileged users wants to mount and work with a container, then they need to execute
|
||||
It is also useful if you want to use the `buildah mount` command. If an unprivileged user wants to mount and work with a container, then they need to execute
|
||||
buildah unshare. Executing `buildah mount` fails for unprivileged users unless the user is running inside a `buildah unshare` session.
|
||||
|
||||
## OPTIONS
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
# INTRODUCTION
|
||||
|
||||
Before container engines build image, they look for a file named .containerignore or .dockerignore in the root
|
||||
Before container engines build an image, they look for a file named .containerignore or .dockerignore in the root
|
||||
context directory. If one of these file exists, the CLI modifies the context to exclude files and
|
||||
directories that match patterns specified in the file. This avoids adding them to images using the ADD or COPY
|
||||
instruction.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ We can also see that there are also no containers by running:
|
|||
|
||||
## Examples
|
||||
|
||||
The two examples that will be shown are relatively simple, but they illustrate how a command or a number of commands can be setup in a master image such that they will be added to a secondary container image that is created from it. This is extremely useful if you need to setup an environment where your containers have 75% of the same content, but need a few individual tweaks. This can be helpful in setting up a environment for maven or java development containers for instance. In this way you can create a single Dockerfile with all the common setup steps as ONBUILD commands and then really minimize the buildah commands or instructions in a second Dockerfile that would be necessary to complete the creation of the container image.
|
||||
The two examples that will be shown are relatively simple, but they illustrate how a command or a number of commands can be setup in a master image such that they will be added to a secondary container image that is created from it. This is extremely useful if you need to setup an environment where your containers have 75% of the same content, but need a few individual tweaks. This can be helpful in setting up an environment for maven or java development containers for instance. In this way you can create a single Dockerfile with all the common setup steps as ONBUILD commands and then really minimize the buildah commands or instructions in a second Dockerfile that would be necessary to complete the creation of the container image.
|
||||
|
||||
NOTE: In the examples below the option `--format=docker` is used in several places. If you wanted to omit that, you could define the `BUILDAH_FORMAT` environment variable and set it to 'docker'. On Fedora that command would be `export BUILDAH_FORMAT=docker`.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue