A key component of a proper devops setup is Infrastructure as Code. This is the concept that you deploy your infrastructure using a series of config files, and track changes using a version control system.
In this section, we will:
Let’s create a new subdomain for this service. I will call it git...
The first step for any moderately complex setup is getting our environment variables sorted. While we can deploy environment variables directly in the deployment, it’s better practice to store variables as a secret. We will do so now:
USER_UID: 1000 USER_GID: 1000 GITEA__database__DB_TYPE: postgres GITEA__database__HOST: 127.0.0.1:5432 GITEA__database__NAME: gitea GITEA__database__USER: gitea GITEA__database__PASSWD: CHANGEME-Claw3-Unfair-Drab GITEA__server__ROOT_URL: https://git.mydomain.com.au GITEA__service__DISABLE_REGISTRATION: true
You can paste YAML formatted environment data directly into rancher. You will get an error about the UI not supporting the data, but if you save and return the UI will sort itself out.
You may notice that we are connecting to the database host on 127.0.0.1. This is because we will be deploying gitea as a pod, and pods can communicate over localhost (or 127.0.0.1)
In a production setup, you would deploy stateful containers (like postgres) as a StatefulSet. StatefulSets require more configuration and can break easier, but allow scaling in a way that maintains volume→container pairings. For simplicity, we are sticking to normal Deployments (which is fine as we don’t plan to scale beyond a single replica).
we don’t use postgres:latest because changing major versions of postgres (typically) require a manual migration step
It is good practice to set up a startup check on any container you plan to permanently deploy. This allows for an easy check to see when containers are failing (like after an update), and allow for automatic restarts. You can also optionally set readiness/liveness checks for ongoing health checks.
By recreating the pod on update, we experience a small downtime on upgrade. However, this prevents two deployments sharing the same volume, potentially corrupting it.
Postgres doesn’t like being in the root of a volume, which is why we created a subfolder inside the volume for Postgres.
We’re only halfway there yet. We got postgres going, but not gitea. Let’s go back and edit the deployment.
If all goes well, the gitea deployment should update and become active. If there are problems, you can check the log of either container by navigating to the deployment (or using pods in the sidebar), and using the dropdown to view logs.
Almost there! Under Service Discovery→Ingresses, Create a new Ingress
If you used the http01 let’s encrypt method, you will need to go into certificates and clone your helloworld certificate, cloning it for the git subdomain
If all has gone well, you can now access your source control on https://git.yourdomain.com.au! All of the fields should be prepopulated except for your admin user. Create an admin user and install gitea.
Well first off, congratulations! You have now deployed a complex app with a separate database and multiple secrets, with a valid let’s encrypt certificate.
That said, there sure was a ton of pointing and clicking involved with that. This goes against our ethos of Infrastructure as Code. Let’s learn how to create reproducible kubernetes deployments with kubernetes manifests.