This repository contains the code to build a Gitea Operator for Kubernetes, including Red Hat OpenShift Container Platform.

The Operator will create a PostgreSQL database and a Gitea instance connected to the PostgreSQL database.

It is implemented on top of the Red Hat Operator SDK - in particular the Ansible Operator.

There is a script hack/operate.sh which will download the prerequisites (operator-sdk etc.), build the operator artifacts from operator-sdk defaults, package and push the operator container image, deploy the artifacts to a Kubernetes cluster, and create a kind: Gitea CR to deploy an instance. You should use the help page to look at what the various options do, but for the most part if you want to deploy Gitea to a cluster directly from this repo you could run hack/operate.sh -d.

Before running the script make sure to update the location of the container image to a repository you have access to. If you decide to build your own container image for the operator, make sure to update hack/operate.conf with an updated container image location and add the -p flag to operate.sh.

A Gitea instance is deployed by creating a kind: Gitea Custom Resource based on the Gitea Custom Resource Definition. You can see some samples in the samples directory. If you’ve installed the operator from the RedHatGov Operator Catalog Index on an OLM-enabled cluster, Custom Resource creation can be done through the console UI with embedded documentation or a form view.

1. Write the definition to a file (e.g. gitea.yaml) and then create the Gitea instance:

   oc create -f ./gitea.yaml

2. The operator will first create the PostgreSQL database, wait until it is up and running and then create the Gitea pod.

3. Validate that both pods (postgresql and gitea) are running before proceeding.

4. You can validate the existence of your Gitea instance by querying for gitea objects:

   oc get gitea

5. Get the Route for Gitea (the PostgreSQL database is not accessible outside of the project):

   oc get route

6. Use the hostname returned in your Web Browser to open the Gitea UI (the first user created will be an administrator).

Deleting a Gitea instance and its associated resources is as simple as deleting the gitea object. If you created a Gitea Custom Resource with metadata.name of gitea-example it suffices to run the delete command on that resource:

The Operator adds ownerReference fields to all created objects - which means that deleting the Gitea object also deletes all objects that have been created by the Operator.

In case you wish to uninstall the Gitea Operator make sure that there are no more Gitea instances running. Once all Gitea instances have been deleted simply delete the operator and its resources with:

OLM uninstallation for OLM-based operators can be handled through the UI, or by deleting the Subscription.

The Operator SDK makes heavy use of Kustomize for development and installation, but intends bundles to be generated for use in an operator catalog. This enables the Operator Lifecycle Manager, deployed onto your cluster, to install and configure operators with a simple kind: Subscription object, instead of a large collection of manifests.

If you are using a registries.conf change and/or ImageContentSourcePolicy mirror that covers quay.io/redhatgov images, you should not have to change anything.

To change the image sources for all necessary images to deploy the operator without such a policy, you need to have the following images hosted in a container repository on your disconnected network:

1. quay.io/redhatgov/gitea-operator:latest

2. quay.io/redhatgov/gitea:latest

3. Some PostgreSQL 10 image that either behaves like the Red Hat PostgreSQL 10 RHEL 8 image or the docker.io/library/postgres:10 image.

The places where you must update those sources are then, respectively:

1. The kind: Gitea custom resource manifest: spec.gitea.image.src and spec.gitea.image.tag should be updated

2. The kind: Gitea custom resource manifest: spec.postgresql.image.src and spec.postgresql.image.tag should be updated

If you intend on using hack/operate.sh it expects you to be in a development environment. Operator installation from this script therefore expects access to the internet. This comes with one extra concern: If kustomize isn’t in your path, it tries to download it from the internet and save it locally into a .gitignore`d folder. If you intend on using `hack/operate.sh to install the operator, you should also bring kustomize and place it in the $PATH of the user who will be running the script. Additionally, in order to install the operator with hack/operate.sh you’ll need to make the following change:

1. hack/operate.conf: IMG should point to the gitea-operator image in your environment

The operator can mount an additional trust bundle ConfigMap into the Gitea pod. Create your ConfigMap and set the spec.gitea.trustBundleConfigMap parameter to the name of the ConfigMap. The ConfigMap must be in the same namespace as the Gitea custom resource.

The CA bundle must be included under a key named ca-bundle.crt within the ConfigMap. The resulting CA bundle will be mounted at /etc/pki/tls/certs/ca-bundle.crt in the Gitea pod.

Example: