Red Hat OpenShift Quay | OpenShift, 4 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Batteries-Included Quay Install on Red Hat OpenShift

Description

A key feature of Red Hat Quay 3.4 is a 'batteries included' install that gets you up and running with a complete Quay deployment in minutes, including a database, object storage, and security scanning.
This demo will show how to quickly deploy Red Hat Quay 3.4 onto an Red Hat OpenShift cluster using the Quay Operator.

Learn more at openshift.com

A

In this demo, we will showcase how to deploy a quay container registry on openshift using the quay operator.

A

By leveraging the kubernetes operator pattern, quay can be deployed and managed in a cloud provider-like experience. This demo takes place on a freshly provisioned ocp 4.6 cluster quay requires a cloud-based object, storage solution. In order to persist container blob layers by default, the quay operator will consume the object bucket claim resource, which is a kubernetes api extension behaving similar to the native persistent volume claim api on openshift. The object bucket claim api is provided by the openshift container storage operator. So we need to ensure this operator is.

A

A

After the ocs operator is installed, we create a nuba instance which initializes an object: storage service for archway to.

A

A

Ensure that the nuba instance is in the ready phase before continuing, let's create a new namespace for the operator to be installed in we'll call ours quay.

A

Enterprise, that's the last of our prerequisite steps. Now we can install the quay operator from the operator hub, ui, search for quay and select the option to install in your quay enterprise namespace. Once the operator is installed, we can proceed to the detail.

A

A

The quay operator, like all operators, extends the kubernetes api using custom resource definitions to give users the ability to create, manage and delete full quay deployments as a service similar to the experience you would have when using a cloud provider. In the case of the quay operator, it only has a single api resource called quay registry.

A

A clay registry corresponds one to one with a full quay deployment. Let's create one now by default, you can create a quay registry with a completely empty spec block, which the operator will interpret as an intention to create a quay installation with all components, managed.

A

We can monitor the deployment status by looking at the status block of the quay registry. This will show a couple different conditions and, when completed, give us the url of our container registry, so that we can use the ui and begin pushing and pulling images among the other features of quay.

A

After a few minutes, the quay operator has successfully reconciled our quay registry instance, and the application is ready to be used. We can access the quay ui using the registry endpoint field in the status.

A

Block quay starts up with no users, so we'll need to create.

A

A

Now that we've created a user, let's log in using our docker client note that I've already added this registry host to the docker daemons configurations, insecure registries, because it is using self-signed tls certificates. So you will need to either do that for yourself or ensure your system trusts the certificates that are being used by quay.

A

Let's push a simple image to our registry: to confirm that everything is.

A

A

Now we can check the quay ui and see that a new repository has been created and our container image has been.

A

Pushed we can also see that the clear security scanner we included as a managed component of quay has successfully scanned the image and reported no known.

A

Vulnerabilities.

A

This has been a quick look at deploying a fully managed quay container registry on openshift using the new quay operator in other videos. We will demonstrate how to configure quay to use externally managed components like an existing database as well as common day. Two operations like modifying quas configuration thanks for watching.