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
Copy file name to clipboardExpand all lines: modules/images-configuration-cas.adoc
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,18 +7,17 @@
7
7
[id="images-configuration-cas_{context}"]
8
8
= Configuring additional trust stores for image registry access
9
9
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.
10
+
[role="_abstract"]
11
+
You can update an `image.config.openshift.io/cluster` custom resource (CR) to include a reference to a config map that includes additional certificate authorities (CAs). You must ensure that these CAs are trusted during image registry access. The config map key is the hostname of a registry with the port for which this CA is to be trusted. The Privacy-Enhanced Mail (PEM) certificate content is the value, for each additional registry CA to trust.
11
12
12
13
.Prerequisites
13
-
* The certificate authorities (CA) must be PEM-encoded.
14
14
15
-
.Procedure
16
-
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.
15
+
* Ensure that a CA is PEM-encoded.
18
16
19
-
The config map key is the hostname of a registry with the port for which this CA is to be trusted, and the PEM certificate content is the value, for each additional registry CA to trust.
17
+
.Procedure
20
18
21
-
.Image registry CA config map example
19
+
. Create a config map in the `openshift-config` namespace. The following example configurations show defined image registry CA that exists in a config map:
20
+
+
22
21
[source,yaml]
23
22
----
24
23
apiVersion: v1
@@ -30,16 +29,17 @@ data:
30
29
-----BEGIN CERTIFICATE-----
31
30
...
32
31
-----END CERTIFICATE-----
33
-
registry-with-port.example.com..5000: | <1>
32
+
registry-with-port.example.com..5000: |
34
33
-----BEGIN CERTIFICATE-----
35
34
...
36
35
-----END CERTIFICATE-----
37
36
----
38
-
<1> If the registry has the port, such as `registry-with-port.example.com:5000`, `:` should be replaced with `..`.
39
-
40
-
You can configure additional CAs with the following procedure.
37
+
+
38
+
where:
39
+
+
40
+
`registry-with-port.example.com..5000`:: If the registry has the port, `:` should be replaced with `..`.
41
41
42
-
* To configure an additional CA:
42
+
. Configure an additional CA. Ensure that you specify the name of the CA in the AdditionalTrustedCA` parameter of the `image.config.openshift.io` CR. You can then provide additional CAs that must be trusted when contacting external registries.
Copy file name to clipboardExpand all lines: modules/pruning-images.adoc
+42-41Lines changed: 42 additions & 41 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,8 @@
6
6
[id="pruning-images_{context}"]
7
7
= Automatically pruning images
8
8
9
-
Images from the {product-registry} that are no longer required by the system due to age, status, or exceed limits are automatically pruned. Cluster administrators can configure the Pruning Custom Resource, or suspend it.
9
+
[role="_abstract"]
10
+
Images from the {product-registry} that are no longer required by the system because of age, status, or exceed limits being automatically pruned. As a cluster administrator, can configure or suspend the pruning Custom Resource (CR).
The behavior of the Image Registry Operator for managing the pruner is independent to the `managementState` specified on the `ClusterOperator` object of the Image Registry Operator. If the Image Registry Operator is not in the `Managed` state, the image pruner can still be configured and managed by the Pruning Custom Resource.
25
+
26
+
However, the `managementState` of the Image Registry Operator alters the behavior of the deployed image pruner job:
27
+
28
+
* `Managed`: the `--prune-registry` flag for the image pruner is set to `true`.
29
+
* `Removed`: the `--prune-registry` flag for the image pruner is set to `false`, meaning it only prunes image metadata in etcd.
30
+
====
31
+
21
32
.Procedure
22
33
23
34
* Verify that the object named `imagepruners.imageregistry.operator.openshift.io/cluster` contains the following `spec` and `status` fields:
<1>`schedule`: `CronJob` formatted schedule. This is an optional field, default is daily at midnight.
59
-
<2>`suspend`: If set to `true`, the `CronJob` running pruning is suspended. This is an optional field, default is `false`. The initial value on new clusters is `false`.
60
-
<3>`keepTagRevisions`: The number of revisions per tag to keep. This is an optional field, default is `3`. The initial value is `3`.
61
-
<4>`keepYoungerThanDuration`: Retain images younger than this duration. This is an optional field. If a value is not specified, either `keepYoungerThan` or the default value `60m` (60 minutes) is used.
62
-
<5>`keepYoungerThan`: Deprecated. The same as `keepYoungerThanDuration`, but the duration is specified as an integer in nanoseconds. This is an optional field. When `keepYoungerThanDuration` is set, this field is ignored.
63
-
<6>`resources`: Standard pod resource requests and limits. This is an optional field.
64
-
<7>`affinity`: Standard pod affinity. This is an optional field.
65
-
<8>`nodeSelector`: Standard pod node selector. This is an optional field.
66
-
<9>`tolerations`: Standard pod tolerations. This is an optional field.
67
-
<10>`successfulJobsHistoryLimit`: The maximum number of successful jobs to retain. Must be `>= 1` to ensure metrics are reported. This is an optional field, default is `3`. The initial value is `3`.
68
-
<11>`failedJobsHistoryLimit`: The maximum number of failed jobs to retain. Must be `>= 1` to ensure metrics are reported. This is an optional field, default is `3`. The initial value is `3`.
69
-
<12>`observedGeneration`: The generation observed by the Operator.
70
-
<13>`conditions`: The standard condition objects with the following types:
71
-
* `Available`: Indicates if the pruning job has been created. Reasons can be Ready or Error.
72
-
* `Scheduled`: Indicates if the next pruning job has been scheduled. Reasons can be Scheduled, Suspended, or Error.
73
-
* `Failed`: Indicates if the most recent pruning job failed.
69
+
*`schedule`: `CronJob` formatted schedule. This is an optional field, default is daily at midnight.
70
+
*`suspend`: If set to `true`, the `CronJob` running pruning is suspended. This is an optional field, default is `false`. The initial value on new clusters is `false`.
71
+
*`keepTagRevisions`: The number of revisions per tag to keep. This is an optional field, default is `3`. The initial value is `3`.
72
+
*`keepYoungerThanDuration`: Retain images younger than this duration. This is an optional field. If a value is not specified, either `keepYoungerThan` or the default value `60m` (60 minutes) is used.
73
+
*`keepYoungerThan`: Deprecated. The same as `keepYoungerThanDuration`, but the duration is specified as an integer in nanoseconds. This is an optional field. When `keepYoungerThanDuration` is set, this field is ignored.
74
+
*`resources`: Standard pod resource requests and limits. This is an optional field.
75
+
*`affinity`: Standard pod affinity. This is an optional field.
76
+
*`nodeSelector`: Standard pod node selector. This is an optional field.
77
+
*`tolerations`: Standard pod tolerations. This is an optional field.
78
+
*`successfulJobsHistoryLimit`: The maximum number of successful jobs to retain. Must be greater than or equal to `1` to ensure metrics are reported. This is an optional field, default is `3`. The initial value is `3`.
79
+
*`failedJobsHistoryLimit`: The maximum number of failed jobs to retain. Must be greater than or equal `1` to ensure metrics are reported. This is an optional field, default is `3`. The initial value is `3`.
80
+
*`observedGeneration`: The generation observed by the Operator.
81
+
*`conditions`: The standard condition objects with the following types:
82
+
**`Available`: Indicates if the pruning job has been created. Reasons can be `Ready` or `Error`.
83
+
**`Scheduled`: Indicates if the next pruning job has been scheduled. Reasons can be `Scheduled`, `Suspended`, or `Error`.
84
+
**`Failed`: Indicates if the most recent pruning job failed.
74
85
75
-
76
-
[IMPORTANT]
77
-
====
78
-
The Image Registry Operator's behavior for managing the pruner is orthogonal to the `managementState` specified on the Image Registry Operator's `ClusterOperator` object. If the Image Registry Operator is not in the `Managed` state, the image pruner can still be configured and managed by the Pruning Custom Resource.
79
-
80
-
However, the `managementState` of the Image Registry Operator alters the behavior of the deployed image pruner job:
81
-
82
-
* `Managed`: the `--prune-registry` flag for the image pruner is set to `true`.
83
-
* `Removed`: the `--prune-registry` flag for the image pruner is set to `false`, meaning it only prunes image metadata in etcd.
Copy file name to clipboardExpand all lines: modules/registry-accessing-directly.adoc
+19-57Lines changed: 19 additions & 57 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,13 +6,12 @@
6
6
[id="registry-accessing-directly_{context}"]
7
7
= Accessing the registry directly from the cluster
8
8
9
-
You can access the registry from inside the cluster.
9
+
[role="_abstract"]
10
+
You can access the registry from inside the cluster by using internal routes.
10
11
11
12
.Procedure
12
13
13
-
Access the registry from the cluster by using internal routes:
14
-
15
-
. Access the node by getting the node's name:
14
+
. Access the node by getting its name:
16
15
+
17
16
[source,terminal]
18
17
----
@@ -24,13 +23,13 @@ $ oc get nodes
24
23
$ oc debug nodes/<node_name>
25
24
----
26
25
27
-
. To enable access to tools such as `oc` and `podman` on the node, change your root directory to `/host`:
26
+
. To enable access to tools such as `oc` and `podman` on the node, change your root directory to `/host`. Successful output on running the commands states `Login Succeeded!`.
28
27
+
29
28
[source,terminal]
30
29
----
31
30
sh-4.2# chroot /host
32
31
----
33
-
+
32
+
34
33
. Log in to the container image registry by using your access token:
You should see a message confirming login, such as:
47
-
+
48
-
[source,terminal]
49
-
----
50
-
Login Succeeded!
51
-
----
52
-
+
53
45
[NOTE]
54
46
====
55
-
You can pass any value for the user name; the token contains all necessary
56
-
information. Passing a user name that contains colons will result in a login
57
-
failure.
47
+
You can pass almost any value for the user name. The token contains all necessary information. Passing a user name that contains colons results in a login failure.
58
48
59
-
Since the Image Registry Operator creates the route, it will likely be similar to
The Image Registry Operator creates the route, such as `default-route-openshift-image-registry.<cluster_name>`.
61
50
====
62
-
+
63
-
. Perform `podman pull` and `podman push` operations against your registry:
64
-
+
65
-
[IMPORTANT]
66
-
====
67
-
You can pull arbitrary images, but if you have the *system:registry* role
68
-
added, you can only push images to the registry in your project.
69
-
====
70
-
+
71
-
In the following examples, use:
72
-
+
73
-
|====
74
-
|Component |Value
75
-
76
-
|*<registry_ip>*
77
-
|`172.30.124.220`
78
-
79
-
|*<port>*
80
-
|`5000`
81
-
82
-
|*<project>*
83
-
|`openshift`
84
-
85
-
|*<image>*
86
-
|`image`
87
-
88
-
|*<tag>*
89
-
| omitted (defaults to `latest`)
90
-
|====
91
51
52
+
. Perform `podman pull` and `podman push` operations against your registry. The following example commands demonstrate these operations.
53
+
+
92
54
.. Pull an arbitrary image:
93
55
+
94
56
[source,terminal]
95
57
----
96
58
sh-4.2# podman pull <name.io>/<image>
97
59
----
98
-
99
-
.. Tag the new image with the form `<registry_ip>:<port>/<project>/<image>`.
100
-
The project name must appear in this pull specification for {product-title} to
101
-
correctly place and later access the image in the registry:
60
+
+
61
+
[IMPORTANT]
62
+
====
63
+
You can pull arbitrary images, but if you have the *system:registry* role added, you can only push images to the registry in your project.
64
+
====
65
+
+
66
+
.. Tag the new image with the form `<registry_ip>:<port>/<project>/<image>`. For example, `172.30.124.220:5000/openshift/image`. The project name must show in the pull specification for {product-title} to correctly place and later access the image in the registry.
102
67
+
103
68
[source,terminal]
104
69
----
@@ -107,12 +72,9 @@ sh-4.2# podman tag <name.io>/<image> image-registry.openshift-image-registry.svc
107
72
+
108
73
[NOTE]
109
74
====
110
-
You must have the `system:image-builder` role for the specified
111
-
project, which allows the user to write or push an image. Otherwise, the
112
-
`podman push` in the next step will fail. To test, you can create a new project
113
-
to push the image.
75
+
You must have the `system:image-builder` role for the specified project, which allows the user to write or push an image. Otherwise, the `podman push` in the next step will fail. To test, you can create a new project to push the image.
When pushing images to the internal registry, the repository name must use the `<project>/<name>` format. Using multiple project levels in the repository name results in an authentication error.
Prometheus is a stand-alone, open source systems monitoring and alerting
12
-
toolkit.
13
-
14
-
The metrics are exposed at the *_/extensions/v2/metrics_* path of the registry
15
-
endpoint.
16
-
17
-
// Recommended link to extended registry configuration assembly.
9
+
[role="_abstract"]
10
+
The OpenShift Container Registry provides an endpoint for link:https://prometheus.io/docs/introduction/overview/[Prometheus metrics]. Prometheus is a stand-alone, open source systems monitoring and alerting toolkit. The metrics get exposed at the *_/extensions/v2/metrics_* path of the registry endpoint. You can access the metrics by running a metrics query that includes a cluster role.
18
11
19
12
.Procedure
20
13
21
-
You can access the metrics by running a metrics query using a cluster role.
22
-
23
-
*Cluster role*
24
-
25
14
. Create a cluster role if you do not already have one to access the metrics:
26
15
+
27
16
[source,terminal]
@@ -41,32 +30,30 @@ rules:
41
30
EOF
42
31
----
43
32
44
-
. Add this role to a user, run the following command:
33
+
. Add the cluster role to a user account by entering the following command:
. Run a metrics query in node or inside a pod, for example:
48
+
. Run a metrics query in node or inside a pod. The following example command and output demonstrate this task.
62
49
+
63
50
[source,terminal]
64
51
----
65
52
$ curl --insecure -s -u <user>:<secret> \ <1>
66
53
https://image-registry.openshift-image-registry.svc:5000/extensions/v2/metrics | grep imageregistry | head -n 20
67
54
----
55
+
* `<user>:<secret>`: The `<user>` object can be arbitrary, but `<secret>` tag must use the user token.
68
56
+
69
-
.Example output
70
57
[source,terminal]
71
58
----
72
59
# HELP imageregistry_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which the image registry was built.
0 commit comments