Meta repo for operation, issues, suggestions, and feedback.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

2.8 KiB

Kubernetes / GKE

This Gitea instance is currently hosted on Google Kubernetes Engine.

Apply changes to resources

kubectl apply -f gitea-db.yaml
kubectl apply -f gitea-server.yaml

Write the secrets to the local filesystem


It writes the secrets (currently the app.ini file, as well as auto-generated TLS certificates that are only used when no Let's Encrypt cert is available) to the kubernetes/config/ folder. These files are not in Git because they contain credentials.

Once you have edited them locally, you need to delete the secrets stored on Kubernetes before uploading them again. This is done by this script:


Reuse a released persistent volume:

When you delete a PVC, corresponding PV becomes Released. This PV can contain sensitive data (say credit card numbers) and therefore nobody can ever bind to it, even if it is a PVC with the same name and in the same namespace as the previous one - who knows who's trying to steal the data!

Admin intervention is required here. He has two options:

* Make the PV available to everybody - delete `PV.Spec.ClaimRef`, Such PV can bound to any PVC (assuming that capacity, access mode and selectors match)

* Make the PV available to a specific PVC - pre-fill `PV.Spec.ClaimRef` with a pointer to a PVC. Leave the `PV.Spec.ClaimRef,UID` empty, as the PVC does not to need exist at this point and you don't know PVC's UID. This PV can be bound only to the specified PVC.

@whitecolor, in your case you should be fine by clearing PV.Spec.ClaimRef.UID in the PV. Only the re-created PVC (with any UID) can then use the PV. And it's your responsibility that only the right person can craft appropriate PVC so nobody can steal your data.

Update Gitea

Released version

Change the image for the gitea-server container (kubernetes/gitea-server.yaml) to gitea/gitea:TAG, for example: gitea/gitea:1.7.0-rc2

Unreleased version

This is useful to deploy features that are in master but not yet in a release.

$ docker pull gitea/gitea
$ docker tag gitea/gitea:latest kosmosorg/gitea:production
$ docker push kosmosorg/gitea

Set the image for the gitea-server container to kosmosorg/gitea:latest, or run this command to force a deployment if it is already set to it

$ kubectl patch deployment gitea-server -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"

Build our own image

At the root of the [](gitea repo)

$ DOCKER_TAG=production DOCKER_IMAGE=kosmosorg/gitea make docker # builds and tags kosmosorg/gitea:production locally
$ docker push kosmosorg/gitea