You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
are lightweight mechanisms for isolating running processes so that they are
10
-
limited to interacting with only their designated resources. The word
11
-
container is defined as a specific running or paused instance of a container
12
-
image.
7
+
The basic units of {product-title} applications are called containers. link:https://access.redhat.com/articles/1353593[Linux container technologies] are lightweight mechanisms for isolating running processes so that they are limited to interacting with only their designated resources. The word container is defined as a specific running or paused instance of a container image.
13
8
14
-
Many application instances can be running in containers on a single host without
15
-
visibility into each others' processes, files, network, and so on. Typically,
16
-
each container provides a single service, often called a micro-service, such
17
-
as a web server or a database, though containers can be used for arbitrary
18
-
workloads.
9
+
Many application instances can be running in containers on a single host without visibility into each others' processes, files, network, and so on. Typically, each container provides a single service, often called a micro-service, such as a web server or a database, though containers can be used for arbitrary workloads.
19
10
20
-
The Linux kernel has been incorporating capabilities for container technologies
21
-
for years. The Docker project developed a convenient management interface for
22
-
Linux containers on a host. More recently, the
23
-
link:https://github.com/opencontainers/[Open Container Initiative] has developed
24
-
open standards for container formats and container runtimes. {product-title} and
25
-
Kubernetes add the ability to orchestrate OCI- and Docker-formatted containers
26
-
across multi-host installations.
11
+
The Linux kernel has been incorporating capabilities for container technologies for years. The Docker project developed a convenient management interface for Linux containers on a host. More recently, the link:https://github.com/opencontainers/[Open Container Initiative] has developed open standards for container formats and container runtimes. {product-title} and Kubernetes add the ability to orchestrate OCI- and Docker-formatted containers across multi-host installations.
27
12
28
-
Though you do not directly interact with container runtimes when using
29
-
{product-title}, understanding their capabilities and terminology is
30
-
important for understanding their role in {product-title} and how your
31
-
applications function inside of containers.
13
+
Though you do not directly interact with container runtimes when using {product-title}, understanding their capabilities and terminology is important for understanding their role in {product-title} and how your applications function inside of containers.
can be used to replace `docker` command-line tools for running and managing
36
-
containers directly. Using `podman`, you can experiment with containers
37
-
separately from {product-title}.
15
+
Tools such as link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/managing_containers/#using_podman_to_work_with_containers[podman] can be used to replace `docker` command-line tools for running and managing containers directly. Using `podman`, you can experiment with containers separately from {product-title}.
Copy file name to clipboardExpand all lines: modules/images-about.adoc
+4-19Lines changed: 4 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,25 +4,10 @@
4
4
[id="images-about_{context}"]
5
5
= Images
6
6
7
-
Containers in {product-title} are based on OCI- or
8
-
Docker-formatted container _images_. An image is a
9
-
binary that includes all of the requirements for running a single
10
-
container, as well as metadata describing its needs and capabilities.
7
+
Containers in {product-title} are based on OCI- or Docker-formatted container _images_. An image is a binary that includes all of the requirements for running a single container, as well as metadata describing its needs and capabilities.
11
8
12
-
You can think of it as a packaging technology. Containers only have access to
13
-
resources defined in the image unless you give the container additional access
14
-
when creating it. By deploying the same image in multiple containers across
15
-
multiple hosts and load balancing between them, {product-title} can provide
16
-
redundancy and horizontal scaling for a service packaged into an image.
9
+
You can think of it as a packaging technology. Containers only have access to resources defined in the image unless you give the container additional access when creating it. By deploying the same image in multiple containers across multiple hosts and load balancing between them, {product-title} can provide redundancy and horizontal scaling for a service packaged into an image.
or `docker` CLI directly to build images, but {product-title} also supplies
21
-
builder images that assist with creating new images by adding your code or
22
-
configuration to existing images.
11
+
You can use the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/managing_containers/#using_podman_to_work_with_containers[podman] or `docker` CLI directly to build images, but {product-title} also supplies builder images that assist with creating new images by adding your code or configuration to existing images.
23
12
24
-
Because applications develop over time, a single image name can actually
25
-
refer to many different versions of the same image. Each different
26
-
image is referred to uniquely by its hash (a long hexadecimal number
27
-
e.g., `fd44297e2ddb050ec4f...`) which is usually shortened to 12
28
-
characters (e.g., `fd44297e2ddb`).
13
+
Because applications develop over time, a single image name can actually refer to many different versions of the same image. Each different image is referred to uniquely by its hash, a long hexadecimal number such as `fd44297e2ddb050ec4f...`, which is usually shortened to 12 characters, such as `fd44297e2ddb`.
Copy file name to clipboardExpand all lines: modules/images-add-tags-to-imagestreams.adoc
+11-30Lines changed: 11 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,42 +2,33 @@
2
2
// * openshift_images/tagging-images
3
3
4
4
[id="images-add-tags-to-imagestreams_{context}"]
5
-
= Adding tags to imagestreams
5
+
= Adding tags to image streams
6
6
7
-
An imagestream in {product-title} comprises zero or more container images
8
-
identified by tags.
7
+
An image stream in {product-title} comprises zero or more container images identified by tags.
9
8
10
-
There are different types of tags available. The default behavior uses a
11
-
_permanent_ tag, which points to a specific image in time. If the _permanent_tag
12
-
is in use and the source changes, the tag does not change for the destination.
9
+
There are different types of tags available. The default behavior uses a `permanent` tag, which points to a specific image in time. If the `permanent` tag is in use and the source changes, the tag does not change for the destination.
13
10
14
-
A _tracking_ tag means the destination tag's metadata is updated during the import
15
-
of the source tag.
11
+
A `tracking` tag means the destination tag's metadata is updated during the import of the source tag.
16
12
17
13
.Procedure
18
14
19
-
* You can add tags to an imagestream using the `oc tag` command:
15
+
* You can add tags to an image stream using the `oc tag` command:
20
16
+
21
17
[source,terminal]
22
18
----
23
19
$ oc tag <source> <destination>
24
20
----
25
21
+
26
-
For example, to configure the `ruby` imagestreams `static-2.0` tag to always
27
-
refer to the current image for the `ruby` imagestreams `2.0` tag:
22
+
For example, to configure the `ruby` image stream `static-2.0` tag to always refer to the current image for the `ruby` image stream `2.0` tag:
28
23
+
29
24
[source,terminal]
30
25
----
31
26
$ oc tag ruby:2.0 ruby:static-2.0
32
27
----
33
28
+
34
-
This creates a new imagestreamtag named `static-2.0` in the `ruby` imagestream.
35
-
The new tag directly references the image id that the `ruby:2.0`
36
-
imagestreamtag pointed to at the time `oc tag` was run, and the image it points
37
-
to never changes.
29
+
This creates a new image stream tag named `static-2.0` in the `ruby` image stream. The new tag directly references the image id that the `ruby:2.0` image stream tag pointed to at the time `oc tag` was run, and the image it points to never changes.
38
30
39
-
* To ensure the destination tag is updated whenever the source tag changes, use
40
-
the `--alias=true` flag:
31
+
* To ensure the destination tag is updated when the source tag changes, use the `--alias=true` flag:
41
32
+
42
33
[source,terminal]
43
34
----
@@ -46,23 +37,13 @@ $ oc tag --alias=true <source> <destination>
46
37
47
38
[NOTE]
48
39
====
49
-
Use a _tracking_ tag for creating permanent aliases, for example, `latest` or
50
-
`stable`. The tag only works correctly within a single imagestream. Trying
51
-
to create a cross-imagestream alias produces an error.
40
+
Use a tracking tag for creating permanent aliases, for example, `latest` or `stable`. The tag only works correctly within a single image stream. Trying to create a cross-image stream alias produces an error.
52
41
====
53
42
54
43
* You can also add the `--scheduled=true` flag to have the destination tag be
55
44
refreshed, or re-imported, periodically. The period is configured globally at
56
45
the system level.
57
46
58
-
* The `--reference` flag creates an imagestreamtag that is not imported. The
59
-
tag points to the source location, permanently.
47
+
* The `--reference` flag creates an image stream tag that is not imported. The tag points to the source location, permanently.
60
48
+
61
-
If you want to instruct OpenShift to always fetch the tagged image from the
62
-
integrated registry, use `--reference-policy=local`. The registry uses the
63
-
pull-through feature to serve the image to the client. By default, the image
64
-
blobs are mirrored locally by the registry. As a result, they can be pulled more
65
-
quickly the next time they are needed. The flag also allows for pulling from
66
-
insecure registries without a need to supply `--insecure-registry` to the container
67
-
runtime as long as the imagestream has an insecure annotation or the tag has an
68
-
insecure import policy.
49
+
If you want to instruct {product-title} to always fetch the tagged image from the integrated registry, use `--reference-policy=local`. The registry uses the pull-through feature to serve the image to the client. By default, the image blobs are mirrored locally by the registry. As a result, they can be pulled more quickly the next time they are needed. The flag also allows for pulling from insecure registries without a need to supply `--insecure-registry` to the container runtime as long as the image stream has an insecure annotation or the tag has an insecure import policy.
= Allowing pods to reference images across projects
6
6
7
-
When using the internal registry, to allow pods in `project-a` to reference
8
-
images in `project-b`, a service account in `project-a` must be bound to the
9
-
`system:image-puller` role in `project-b`.
7
+
When using the internal registry, to allow pods in `project-a` to reference images in `project-b`, a service account in `project-a` must be bound to the `system:image-puller` role in `project-b`.
10
8
11
9
.Procedure
12
10
13
-
. To allow pods in `project-a` to reference images in `project-b`, bind a service
14
-
account in `project-a` to the `system:image-puller` role in `project-b`:
11
+
. To allow pods in `project-a` to reference images in `project-b`, bind a service account in `project-a` to the `system:image-puller` role in `project-b`:
15
12
+
16
13
[source,terminal]
17
14
----
@@ -20,8 +17,7 @@ $ oc policy add-role-to-user \
20
17
--namespace=project-b
21
18
----
22
19
+
23
-
After adding that role, the pods in `project-a` that reference the default
24
-
service account are able to pull images from `project-b`.
20
+
After adding that role, the pods in `project-a` that reference the default service account are able to pull images from `project-b`.
25
21
26
22
. To allow access for any service account in `project-a`, use the group:
= Allowing pods to reference images from other secured registries
8
8
9
-
The `.dockercfg` `$HOME/.docker/config.json` file for Docker clients is a
10
-
Docker credentials file that stores your authentication information if you have
11
-
previously logged into a secured or insecure registry.
9
+
The `.dockercfg` `$HOME/.docker/config.json` file for Docker clients is a Docker credentials file that stores your authentication information if you have previously logged into a secured or insecure registry.
12
10
13
-
To pull a secured container image that is not from {product-title}'s internal
14
-
registry, you must create a pull secret from your Docker credentials and add
15
-
it to your service account.
11
+
To pull a secured container image that is not from {product-title}'s internal registry, you must create a pull secret from your Docker credentials and add it to your service account.
16
12
17
13
.Procedure
18
14
19
-
* If you already have a `.dockercfg` file for the secured registry, you can create
20
-
a secret from that file by running:
15
+
* If you already have a `.dockercfg` file for the secured registry, you can create a secret from that file by running:
* To use a secret for pulling images for pods, you must add the secret to your
51
-
service account. The name of the service account in this example should match
52
-
the name of the service account the pod uses. `default` is the default
53
-
service account:
44
+
* To use a secret for pulling images for pods, you must add the secret to your service account. The name of the service account in this example should match the name of the service account the pod uses. The default service account is `default`:
Copy file name to clipboardExpand all lines: modules/images-configuration-cas.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,13 +10,13 @@
10
10
The `image.config.openshift.io/cluster` custom resource can contain a reference to a config map that contains additional certificate authorities to be trusted during image registry access.
11
11
12
12
.Prerequisites
13
-
* The CAs must be PEM-encoded.
13
+
* The certificate authorities (CA) must be PEM-encoded.
14
14
15
15
.Procedure
16
16
17
17
You can create a config map in the `openshift-config` namespace and use its name in `AdditionalTrustedCA` in the `image.config.openshift.io` custom resource to provide additional CAs that should be trusted when contacting external registries.
18
18
19
-
The ConfigMap key is the host name of a registry with the port for which this CA is to be trusted, and the base64-encoded certificate is the value, for each additional registry CA to trust.
19
+
The config map key is the host name of a registry with the port for which this CA is to be trusted, and the base64-encoded certificate is the value, for each additional registry CA to trust.
Copy file name to clipboardExpand all lines: modules/images-configuration-file.adoc
+6-26Lines changed: 6 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,11 +6,7 @@
6
6
[id="images-configuration-file_{context}"]
7
7
= Configuring image settings
8
8
9
-
You can configure image registry settings by editing the
10
-
`image.config.openshift.io/cluster` custom resource (CR). The
11
-
Machine Config Operator (MCO) watches the
12
-
`image.config.openshift.io/cluster` CR for any changes
13
-
to the registries and reboots the nodes when it detects changes.
9
+
You can configure image registry settings by editing the `image.config.openshift.io/cluster` custom resource (CR). The Machine Config Operator (MCO) watches the `image.config.openshift.io/cluster` CR for any changes to the registries and reboots the nodes when it detects changes.
<1> `Image`: Holds cluster-wide information about how to handle images. The
56
-
canonical, and only valid name is `cluster`.
57
-
<2> `allowedRegistriesForImport`: Limits the container image registries from which
58
-
normal users may import images. Set this list to the registries that you trust
59
-
to contain valid images, and that you want applications to be able to
60
-
import from. Users with permission to create images or `ImageStreamMappings`
61
-
from the API are not affected by this policy. Typically only cluster
62
-
administrators will have the appropriate permissions.
63
-
<3> `additionalTrustedCA`: A reference to a ConfigMap containing additional CAs that
64
-
should be trusted during `ImageStream import`, `pod image pull`,
65
-
`openshift-image-registry pullthrough`, and builds. The namespace for this ConfigMap is
66
-
`openshift-config`. The format of the ConfigMap is to use the registry hostname
67
-
as the key, and the PEM certificate as the value, for each additional registry CA to
68
-
trust.
69
-
<4> `registrySources`: Contains configuration that determines how the container
70
-
runtime should treat individual registries when accessing images for builds and
71
-
pods. For instance, whether or not to allow insecure access. It does not contain
72
-
configuration for the internal cluster registry. This example lists `allowedRegistries`,
73
-
which defines the registries that are allowed to be used. One of the registries listed
74
-
is insecure.
51
+
<1> `Image`: Holds cluster-wide information about how to handle images. The canonical, and only valid name is `cluster`.
52
+
<2> `allowedRegistriesForImport`: Limits the container image registries from which normal users may import images. Set this list to the registries that you trust to contain valid images, and that you want applications to be able to import from. Users with permission to create images or `ImageStreamMappings` from the API are not affected by this policy. Typically only cluster administrators have the appropriate permissions.
53
+
<3> `additionalTrustedCA`: A reference to a config map containing additional certificate authorities (CA) that are trusted during image stream import, pod image pull, `openshift-image-registry` pullthrough, and builds. The namespace for this config map is `openshift-config`. The format of the config map is to use the registry hostname as the key, and the PEM certificate as the value, for each additional registry CA to trust.
54
+
<4> `registrySources`: Contains configuration that determines how the container runtime should treat individual registries when accessing images for builds and pods. For instance, whether or not to allow insecure access. It does not contain configuration for the internal cluster registry. This example lists `allowedRegistries`, which defines the registries that are allowed to be used. One of the registries listed is insecure.
75
55
+
76
56
[NOTE]
77
57
====
78
-
When using the `allowedRegistries`, `blockedRegistries`, or `insecureRegistries` parameter, you can specify an individual repository within a registry. For example: `reg1.io/myrepo/myapp:latest`.
58
+
When using the `allowedRegistries`, `blockedRegistries`, or `insecureRegistries` parameter, you can specify an individual repository within a registry. For example: `reg1.io/myrepo/myapp:latest`.
79
59
====
80
60
81
61
. To check that the changes are applied, list your nodes:
0 commit comments