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
{productname} is an enterprise-quality container registry. Use {productname} to build and store container images, then make them available to deploy across your enterprise.
8
-
9
-
The {productname} Operator provides a simple method to deploy and manage {productname} on an OpenShift cluster.
This document guides you through the process of deploying and configuring {productname} in your environment using the {productname} Operator. The Operator simplifies the installation, configuration, and maintenance of your registry, ensuring you have a production-ready container image repository for your enterprise.
To deploy the {productname} registry after installing the Operator, you must create an instance based on the `QuayRegistry` custom resource (CR), which can be done using the {ocp} web console or the `oc cli` (command-line interface). For the registry to deploy successfully, you must have, or configure, an object storage provider.
6
+
7
+
The following sections provide you with the information necessary to configure managed or unmanaged object storage, and then deploy the {productname} registry.
8
+
9
+
[NOTE]
10
+
====
11
+
The following procedures show you how to create a basic {productname} registry in all namespaces of the {ocp} deployment. Depending on your needs, advanced configuration might be necessary. For example, you might need to configure SSL/TLS for your deployment or disable certain components. Advanced configuration practices are covered in later chapters of this guide.
{productname} requires object storage to store all container image layer blobs. You have two options for providing this storage: managed (automated by the Operator) or unmanaged (using an existing external service).
Copy file name to clipboardExpand all lines: modules/operator-components-intro.adoc
+1-7Lines changed: 1 addition & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,4 @@
2
2
[id="operator-components-intro"]
3
3
= {productname-ocp} configuration overview
4
4
5
-
When deploying {productname} using the Operator on {ocp}, configuration is managed declaratively through the `QuayRegistry` custom resource (CR). This model allows cluster administrators to define the desired state of the {productname} deployment, including which components are enabled, storage backends, SSL/TLS configuration, and other core features.
6
-
7
-
After deploying {productname-ocp} with the Operator, administrators can further customize their registry by updating the `config.yaml` file and referencing it in a Kubernetes secret. This configuration bundle is linked to the `QuayRegistry` CR through the `configBundleSecret` field.
8
-
9
-
The Operator reconciles the state defined in the `QuayRegistry` CR and its associated configuration, automatically deploying or updating registry components as needed.
10
-
11
-
This guide covers the basic concepts behind the `QuayRegistry` CR and modifying your `config.yaml` file on {productname-ocp} deployments. More advanced topics, such as using unmanaged components within the `QuayRegistry` CR, can be found in link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index[Deploying {productname} Operator on {ocp}].
5
+
When deploying {productname-ocp}, the registry configuration is managed declaratively through two primary mechanisms: the `QuayRegistry` custom resource (CR) and the `configBundleSecret` resource.
Copy file name to clipboardExpand all lines: modules/operator-components-managed.adoc
-2Lines changed: 0 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,6 @@
4
4
5
5
By default, the Operator handles all required configuration and installation needed for {productname}'s managed components.
6
6
7
-
If the opinionated deployment performed by the {productname} Operator is unsuitable for your environment, you can provide the {productname} Operator with `unmanaged` resources, or overrides, as described in link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#operator-components-managed[Using unmanaged components].
Copy file name to clipboardExpand all lines: modules/operator-components-unmanaged.adoc
+2-16Lines changed: 2 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,25 +2,11 @@
2
2
[id="operator-components-unmanaged"]
3
3
= Using unmanaged components for dependencies
4
4
5
-
If you have existing components such as PostgreSQL, Redis, or object storage that you want to use with {productname}, you first configure them within the {productname} configuration bundle, or the `config.yaml` file. Then, they must be referenced in your `QuayRegistry` bundle as a Kubernetes `Secret` while indicating which components are unmanaged.
6
-
7
-
//Might be used in a note, however I have removed due to the removal of the config editor on OCP deployments.
8
-
9
-
//The {productname} config editor can also be used to create or modify an existing config bundle and simplifies the process of updating the Kubernetes `Secret`, especially for multiple changes. When {productname}'s configuration is changed by the config editor and sent to the {productname} Operator, the deployment is updated to reflect the new configuration.
10
-
5
+
Although the {productname} Operator provides an opinionated deployment by automatically managing all required dependencies, this approach may not be suitable for every environment. If you need to integrate existing infrastructure or require specific configurations, you can leverage the Operator to use external, or _unmanaged_, resources instead. An unmanaged component is any core dependency—such as PostgreSQL, Redis, or object storage—that you deploy and maintain outside of the Operator's control.
11
6
12
7
[NOTE]
13
8
====
14
9
If you are using an unmanaged PostgreSQL database, and the version is PostgreSQL 10, it is highly recommended that you upgrade to PostgreSQL 13. PostgreSQL 10 had its final release on November 10, 2022 and is no longer supported. For more information, see the link:https://www.postgresql.org/support/versioning/[PostgreSQL Versioning Policy].
15
10
====
16
11
17
-
See the following sections for configuring unmanaged components:
18
-
19
-
* xref:operator-unmanaged-postgres[Using an existing PostgreSQL database]
20
-
* xref:operator-unmanaged-hpa[Using unmanaged Horizontal Pod Autoscalers]
Copy file name to clipboardExpand all lines: modules/operator-concepts.adoc
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,16 +2,16 @@
2
2
[id="operator-concepts"]
3
3
= Introduction to the {productname} Operator
4
4
5
-
Use the content in this chapter to execute the following:
5
+
The {productname} Operator is designed to simplify the installation, deployment, and management of the {productname} container registry on {ocp}. By leveraging the Operator framework, you can treat Quay as a native {ocp} application, automating common tasks and managing its full lifecycle.
6
6
7
-
* Install {productname-ocp} using the {productname} Operator
7
+
This chapter provides a conceptual overview of the {productname} Operator's architecture and configuration model. It covers the following information:
8
8
9
-
* Configure managed, or unmanaged, object storage
9
+
* A configuration overview of {productname} when deployed on {ocp}.
10
10
11
-
* Configure unmanaged components, such as the database, Redis, routes, TLS, and so on
11
+
* How the Operator manages Quay's components, or _managed components_.
12
12
13
-
* Deploy the {productname} registry on {ocp} using the {productname} Operator
13
+
* When and why to use external, or _unmanaged_, components for dependencies like the database and object storage.
14
14
15
-
* Use advanced features supported by {productname}
15
+
* The function and structure of the `configBundleSecret`, which handles Quay's configuration.
16
16
17
-
* Upgrade the {productname} registry by using the {productname} Operator
Copy file name to clipboardExpand all lines: modules/operator-config-bundle-secret.adoc
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,6 +21,8 @@ The `configBundleSecret` stores the `config.yaml` file. {productname} administra
21
21
22
22
If this field is omitted, the {productname} Operator automatically generates a configuration secret based on default values and managed component settings. If the field is provided, the contents of the `config.yaml` are used as the base configuration and are merged with values from managed components to form the final configuration, which is mounted into the `quay` application pods.
23
23
24
+
ifeval::["{context}" == "quay-configuration"]
25
+
24
26
How the `QuayRegistry` CR is configured determines which fields must be included in the `configBundleSecret`'s `config.yaml` file for {productname-ocp}. The following example shows you a default `config.yaml` file when all components are managed by the Operator. Note that this example looks different depending on whether components are managed or unmanaged (`managed: false`).
25
27
26
28
.Example YAML with all components managed by the Operator
@@ -69,4 +71,5 @@ DISTRIBUTED_STORAGE_CONFIG:
69
71
# ...
70
72
----
71
73
72
-
Similarly, if you are managing the `horizontalpodautoscaler` component, you must create an accompanying link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#operator-disabling-hpa[`HorizontalPodAutoscaler` custom resource].
74
+
Similarly, if you are managing the `horizontalpodautoscaler` component, you must create an accompanying link:https://docs.redhat.com/en/documentation/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#operator-disabling-hpa[`HorizontalPodAutoscaler` custom resource].
. Create a `QuayRegistry` custom resource in a file called `quayregistry.yaml`
22
+
.. If the `objectstorage` component is set to `managed: true`, complete the following steps:
28
23
29
-
.. For a minimal deployment, using all the defaults:
24
+
... Create the `QuayRegistry` CR by entering the following command:
30
25
+
31
-
.quayregistry.yaml:
32
-
[source,yaml]
26
+
[source,terminal]
33
27
----
28
+
$ cat <<EOF | oc create -n quay-enterprise -f -
34
29
apiVersion: quay.redhat.com/v1
35
30
kind: QuayRegistry
36
31
metadata:
37
32
name: example-registry
38
33
namespace: quay-enterprise
34
+
EOF
39
35
----
40
36
41
-
.. Optional. If you want to have some components unmanaged, add this information in the `spec` field. A minimal deployment might look like the following example:
42
-
+
43
-
.Example quayregistry.yaml with unmanaged components
37
+
.. If the `objectstorage` component is set to `managed: false`, complete the following steps:
38
+
39
+
... Create the a minimal `config.yaml` file for {productname} by entering the following command. You must include the information required for your backend storage provider. For example:
* For more information about how to track the progress of your {productname} deployment, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#operator-monitor-deploy-cli[Monitoring and debugging the deployment process].
113
+
114
+
////
79
115
.. Optional. If you have a proxy configured, you can add the information using overrides for {productname}, Clair, and mirroring:
80
116
+
81
117
.Example quayregistry.yaml with proxy configured
@@ -129,21 +165,4 @@ spec:
129
165
- name: HTTPS_PROXY
130
166
value: quayproxy.qe.devcluster.openshift.com:3128
131
167
----
132
-
133
-
. Create the `QuayRegistry` in the specified namespace by entering the following command:
. Enter the following command to see when the `status.registryEndpoint` is populated:
141
-
+
142
-
[source,terminal]
143
-
----
144
-
$ oc get quayregistry -n quay-enterprise example-registry -o jsonpath="{.status.registryEndpoint}" -w
145
-
----
146
-
147
-
.Additional resources
148
-
149
-
* For more information about how to track the progress of your {productname} deployment, see link:https://access.redhat.com/documentation/en-us/red_hat_quay/{producty}/html-single/deploying_the_red_hat_quay_operator_on_openshift_container_platform/index#operator-monitor-deploy-cli[Monitoring and debugging the deployment process].
0 commit comments