During this workshop you’ll install and use a good number of software components. The first one is OpenShift Data Foundation
for providing storage. We’ll start with it because the install takes a fair amount of time. Number two is Gitea
for providing Git services in your cluster with more to follow in subsequent chapters.
But fear not, all are managed by Kubernetes Operators on OpenShift.
Let’s install OpenShift Data Foundation which you might know under the old name OpenShift Container Storage
. It is engineered as the data and storage services platform for OpenShift and provides software-defined storage for containers.
OpenShift Data Foundation
operator
After the operator has been installed it will inform you to install a StorageSystem
. From the operator overview page click Create StorageSystem
with the following settings:
Deployment Type
Full deployment
and for Backing storage type
make sure gp2
is selected.Requested capacity
as is (2 TiB) and select all nodes.Default (SDN)
You’ll see a review of your settings, hit Create StorageSystem
. Don’t worry if you see a temporary 404 Page. Just releod the browser page once and you will see the System Overview
As mentioned already this takes some time, so go ahead and install the other prerequisites. We’ll come back later.
You will be asked to run oc
(the OpenShift commandline tool) commands a couple of times. We will do this by using the OpenShift Web Terminal. This is the easiest way because you don’t have to install oc
or an SSH client.
To extend OpenShift with the Web Terminal option, install the Web Terminal operator:
This will take some time and installs another operator as a dependency.
After the operator has installed, reload the OCP Web Console browser window. You will now have a new button (>_) in the upper right. Click it to start a new web terminal. From here you can run the oc
commands when the lab guide requests it (copy/paste might depend on your laptop OS and browser settings, e.g. try Ctrl-Shift-V
for pasting).
The terminal is not persistent, so if it was closed for any reason anything you did in the terminal is gone after re-opening.
If for any reason you can’t use the webterminal, your options are:
oc
on your laptopoc
without login.TODO: Change yaml applies to direct git download
We’ll need Git repository services to keep our app and infrastructure source code, so let’s just install trusted Gitea
using an operator:
Gitea is an OpenSource Git Server similar to GitHub. A team at Red Hat was so nice to create an Operator for it. This is a good example of how you can integrate an operator into your catalog that is not part of the default OperatorHub already.
To integrate the Gitea
operator into your Operator catalog you need to access your cluster with the oc
client. You can do this in two ways:
oc
command you copied above, you may need to add –insecure-skip-tls-verify at the end of the lineOr, if working on a Red Hat RHPDS environment:
lab-user
you will be able to run oc
commands without additional login.Now using oc
add the Gitea Operator to your OpenShift OperatorHub catalog:
oc apply -f https://raw.githubusercontent.com/rhpds/gitea-operator/ded5474ee40515c07211a192f35fb32974a2adf9/catalog_source.yaml
Gitea
(You may need to disable search filters)Gitea Operator
with default settingsgit
with the Project selection menu at the top
TODO : Screenshotgit
project via the top Project selection menu !git
)TODO : Replace Screenshot
spec
values :spec:
giteaAdminUser: gitea
giteaAdminPassword: "gitea"
giteaAdminEmail: opentlc-mgr@redhat.com
After creation has finished:
Gitea
with user gitea
and password gitea
Now we will clone a git repository of a sample application into our Gitea, so we have some code to works with
In the cloned repository you’ll find a devfile.yaml
. We will need the URL to the file soon, so keep the tab open.
In later chapters we will need a second repository to hold your GitOps yaml resources. Let’s create this now as well
Gitea
create a New Migration and clone the Config GitOps Repo which will be the repository that contains our GitOps infrastructure components and stateNow it’s time to check if the StorageSystem
deployment from ODF completed succesfully. In the openShift web console:
Your container storage is ready to go, explore the information on the overview pages if you’d like.
The image that we have just deployed was pushed to the internal OpenShift Registry which is a great starting point for your cloud native journey. But if you require more control over you image repos, a graphical GUI, scalability, internal security scanning and the like you may want to upgrade to Red Hat Quay. So as a next step we want to replace the internal registry with Quay.
Quay installation is done through an operator, too:
Quay
quay
at the top Project selection menuquay
go to Administration->LimitRanges and delete the quay-core-resource-limits
quay
projectquay
True
Now that the Registry is installed you have to configure a superuser:
quay
Projectquay-quay
)quayadmin
, a (fake) email address and and quayadmin
as password.quay-config-editor-credentials-...
, open the secret and copy the values, you’ll need them in a second.quay-quay-config-editor
routequayadmin
Reconfiguring Quay takes some time. The easiest way to determine if it’s been finished is to open the Quay portal (using the quay-quay
Route). At the upper right you’ll see the username (quayadmin
), if you click the username the drop-down should show a link Super User Admin Panel. When it shows up you can proceed.
To synchronize the internal default OpenShift Registry with the Quay Registry, Quay Bridge is used.
Now we finally create an Quay Bridge instance. :
quay
namespace)quay
token
https://
) and paste it into the Quay Hostname fieldtrue