gitea.kosmos.org/doc/kubernetes.md

# 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

```
./script/get_secrets
```

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:

```
./script/replace_secrets
```

## 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.

https://github.com/kubernetes/kubernetes/issues/48609#issuecomment-314066616

## 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 [https://github.com/go-gitea/gitea](gitea repo)

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