Running Gitea with PostgreSQL on Kubernetes

spronin

Sergey Pronin

Posted on September 4, 2024

Running Gitea with PostgreSQL on Kubernetes

Gitea - an open source tool for hosting version control using Git as well as other collaborative features like bug tracking, code review, continuous integration and more. It is quite easy to deploy it in Kubernetes - it has a helm chart that will also install Redis and PostgreSQL databases through bitnami helm charts.

But this initial deployment with helm charts is hard to manage and scale for production, as it requires proper database management and day-2 operations. To get there, we will see how somebody can deploy Gitea with Percona Operator for PostgreSQL (this is a follow up for this question on the forum)

Deploy PostgreSQL

To simplify, we will use helm chart to deploy the Operator. See instructions in the documentation.

helm install my-operator percona/pg-operator
Enter fullscreen mode Exit fullscreen mode

Once done, we are ready to deploy the database. But there is a caveat with the user management. Starting with PostgreSQL version 15 CREATE permissions are revoked from all users except database owner from the public (or default) schema (see release notes). This change will cause the problem that the user on the forum is facing:

2024/09/03 16:35:38 cmd/migrate.go:40:runMigrate() [F] Failed to initialize ORM engine: migrate: sync: pq: permission denied for schema public
Gitea migrate might fail due to database connection...This init-container will try again in a few seconds
Enter fullscreen mode Exit fullscreen mode

To fix that, we will need to create a user and also add permissions to this user. To automate permission handling, we can use databaseInitSQL section.

Create an init-sql ConfigMap resource:

% cat init-sql-cm.yaml 
apiVersion: v1
kind: ConfigMap
metadata:
  name: init-sql
data:
  init.sql: |
    \c gitea
    GRANT CREATE ON SCHEMA public TO "gitea";
Enter fullscreen mode Exit fullscreen mode

Create the config map:

kubectl apply -f init-sql-cm.yaml
Enter fullscreen mode Exit fullscreen mode

init.sql will connect to the gitea database and grant the user gitea access to SCHEMA public. Feel free to use any other schema.

Now our values.yaml for the operator is going to look like this:

users:
  - name: gitea
    databases:
      - gitea

databaseInitSQL:
  key: init.sql
  name: init-sql
Enter fullscreen mode Exit fullscreen mode

Create the database:

helm install cluster1 percona/pg-db -f values.yaml
Enter fullscreen mode Exit fullscreen mode

Deploy Gitea

Gitea's helm values.yaml is huge. But to connect to the PostgreSQL cluster deployed with the Operator, we just need to alter the following sections:

# define database
gitea:
  config:
    database:
      DB_TYPE: postgres
      HOST: cluster1-pg-db-pgbouncer.default.svc:5432
      USER: gitea
      NAME: gitea
      SSL_MODE: require
      PASSWD: MYPASSWORD
      SCHEMA: public

# disable built-in postgresql
postgresql:
  enabled: false
postgresql-ha:
  enabled: false
Enter fullscreen mode Exit fullscreen mode

Now follow the installation instructions from the official documentation:

helm repo add gitea-charts https://dl.gitea.com/charts/
helm install gitea gitea-charts/gitea -f values.yaml
Enter fullscreen mode Exit fullscreen mode

What is next

It is important to acknowledge that user management in the Percona Operator for PostgreSQL does not really deliver its end of the bargain. Users are created, but you can't start using them right away, as they don't have permissions to use public schema. This breaks a lot of declarative flows.

In the following release of the Operator we are going to fix it, by automatically creating per-user schemas (similar to what CrunchyData PGO is doing).

The issue is going to be fixed in K8SPG-634.

💖 💪 🙅 🚩
spronin
Sergey Pronin

Posted on September 4, 2024

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related