72 lines
2.8 KiB
Markdown
72 lines
2.8 KiB
Markdown
# 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
|