Compare commits

...
This repository has been archived on 2023-03-30. You can view files and clone it, but cannot push or open issues or pull requests.

66 Commits

Author SHA1 Message Date
Râu Cao 91755e8744 Merge branch 'chore/update_gitea' of kosmos/gitea.kosmos.org into master 2020-03-08 00:00:47 +00:00
Basti ee6ec82157
Upgrade gitea.kosmos.org to Gitea 1.11.2 2020-03-07 18:39:10 -05:00
Râu Cao fa11c50687 Merge branch 'chore/update_gitea' of kosmos/gitea.kosmos.org into master 2020-02-15 16:10:34 +00:00
Basti 21e158737d
Update Gitea to 1.11.0
https://blog.gitea.io/2020/02/gitea-1.11.0-is-released/
2020-02-15 11:08:49 -05:00
Râu Cao 515b4a4483 Merge branch 'chore/upgrade_gitea' of kosmos/gitea.kosmos.org into master 2020-01-28 17:38:54 +00:00
Basti a3c1b2d1f7
Upgrade Gitea to 1.10.3 2020-01-28 12:33:00 -05:00
Râu Cao 2ab0db6c2a Merge branch 'chore/update_gitea' of kosmos/gitea.kosmos.org into master 2019-12-19 13:10:13 +00:00
Basti d6d70af0ad
Upgrade Gitea to 1.10.1 2019-12-19 14:09:35 +01:00
Râu Cao 75881c4c3f Merge branch 'chore/update_gitea' of kosmos/gitea.kosmos.org into master 2019-11-24 12:17:10 +00:00
Basti 3cd4b3102c
Update Gitea to 1.10.0 2019-11-24 13:13:12 +01:00
Râu Cao 11ae884dea Merge branch 'chore/update_gitea' of kosmos/gitea.kosmos.org into master 2019-10-31 11:58:21 +00:00
Basti 6785287227
Update Gitea to 1.9.5 2019-10-31 12:57:25 +01:00
Râu Cao d4784e9787 Merge branch 'chore/update_gitea' of kosmos/gitea.kosmos.org into master 2019-10-13 11:45:42 +00:00
Basti da278556ed
Adapt CPU resource request and limit
After the new pod wasn't able to be scheduled due to insufficient CPU
resources, I checked the current usage and it was well below the
requested amount. Lowering request and limit fixed the deployment issue.
2019-10-13 13:42:34 +02:00
Basti 4dd0f4b844
Update Gitea to 1.9.4 2019-10-13 13:42:24 +02:00
Basti b6894598a6
Update Gitea to 1.9.2 2019-08-31 12:01:16 +02:00
Râu Cao 972bbedb87 Improve customizations documentation (#35) 2019-08-16 09:26:00 +00:00
Râu Cao db396d6ee1 Merge branch 'chore/update_gitea' of kosmos/gitea.kosmos.org into master 2019-08-15 15:33:48 +00:00
Basti d821e02dec
Update Gitea to 1.9.1 2019-08-15 17:32:38 +02:00
Râu Cao 2f02ddb79d Merge branch 'docs_label' of kosmos/gitea.kosmos.org into master 2019-08-12 11:38:11 +00:00
Greg 90cb219d79 Change the color for the docs label to ead746 2019-08-12 13:27:41 +02:00
Greg 9c36ebeb14 Add the docs label to the Kosmos label set 2019-08-09 16:06:01 +02:00
gregkare 5f3b80ab9e Merge branch 'deployment_api_version' of kosmos/gitea.kosmos.org into master 2019-08-07 09:20:50 +00:00
Basti b00931352f
Improve README 2019-08-06 13:16:07 +02:00
Greg f8d964f8d2 Bump the api version for the Deployment resource to apps/v1
It was previously set to extensions/v1beta1. I have discovered that when
the Deployment is created as a extensions/v1beta1, it causes the
existing pod to be killed immediately when doing a rolling update. When
the Deployment was created as apps/v1, a rolling update behaves as
expected: a new pod is created, and the old one is only terminated once
the new pod is ready to serve traffic.

The existing Deployment resource will need to be deleted and recreated:

    kubectl delete deployment gitea-server
    kubectl apply -f gitea-server.yaml

Applying the file without deleting it first will not fix the issue with
rolling updates. It will cause a short downtime
2019-08-06 12:44:57 +02:00
Râu Cao 810482c755 Merge branch 'chore/30-update_1.9.0' of kosmos/gitea.kosmos.org into master 2019-08-02 15:59:38 +00:00
Greg 4e225ab1af Update Gitea to 1.9.0
Closes #30
2019-08-02 17:34:28 +02:00
Râu Cao 1f6e0b7d57 Merge branch 'feature/ark_to_velero' of kosmos/gitea.kosmos.org into master 2019-06-22 12:26:30 +00:00
Greg a3fa72bb56 Update the documentation, Ark is now Velero
Refs #27
2019-06-19 18:33:44 +02:00
gregkare 9f4a5b452c Merge branch 'chore/gitea_181' of kosmos/gitea.kosmos.org into master 2019-05-23 14:31:55 +00:00
Basti 12fc74d8ff
Upgrade Gitea to 1.8.1 2019-05-21 15:15:04 +02:00
gregkare 1d69fad451 Merge branch 'upgrade/22-gitea' of kosmos/gitea.kosmos.org into master 2019-05-02 15:36:14 +00:00
Greg f73c58d7ee Merge branch 'master' into upgrade/22-gitea 2019-05-02 17:35:52 +02:00
gregkare 68771a8e61 Merge branch 'feature/4-label_sets' of kosmos/gitea.kosmos.org into master 2019-05-02 15:27:31 +00:00
gregkare e3de3af82f Merge branch 'chore/resource_config' of kosmos/gitea.kosmos.org into master 2019-05-02 15:25:13 +00:00
Basti 490248909b
Update Gitea to 1.8.0 2019-05-02 15:34:12 +01:00
Greg e0741b4438 Ship the customizations as a Docker image
The Docker image is used in the initialization process, to copy
everything in the custom folder to the Gitea data dir (mounted as a
persistent volume). It is built using Packer and is based on the busybox
image, so we can use its minimalist shell system to copy files and set
permissions
2019-04-01 17:01:16 +02:00
Greg 8050126d2d Merge branch 'master' into feature/4-label_sets 2019-03-29 15:14:15 +01:00
Greg b5bbc5fa34 Update Gitea to 1.7.5
Running on GKE

Closes #21
2019-03-29 15:04:23 +01:00
Basti 915fd7db8a
Add resource requests and limits for Gitea
Based on recent usage stats. If these are not set, the scheduler's
capacity check doesn't work and it will place new pods on nodes that are
actually not free enough for them.
2019-03-04 13:48:20 +07:00
Greg bbfa3f2964 Add a script to copy the content of the custom folder to a running pod
For now it is only labels, but adding anything supported will work
(robots.txt, public files, templates, etc)

The content will be copied to the /data/gitea/ folder that is a mounted
persistent volume

https://docs.gitea.io/en-us/customizing-gitea/
2019-02-27 17:47:48 +01:00
Greg 0a60d8831c Merge branch 'master' into feature/4-label_sets 2019-02-27 12:43:45 +01:00
Greg cc6f31b4b9 Update Gitea to 1.7.2
Closes #18
2019-02-25 16:54:59 +01:00
Greg 069502d056 Bump the gitea data storage to 20GB 2019-02-25 13:29:09 +01:00
Greg 278e6a9cd7 Use a 10GB persistent storage volume for gitea data 2019-02-25 13:18:45 +01:00
Greg eba722992f Copy the labels to the persistent data volume
Move the custom label definitions to a custom folder in the kubernetes
folder, as well as the config files
2019-02-05 20:29:08 +01:00
Greg 871d47fff8 Merge branch 'master' into feature/4-label_sets 2019-02-05 20:16:27 +01:00
Râu Cao 9ef15325cc Merge branch 'chore/upgrade_gitea' of kosmos/gitea.kosmos.org into master 2019-02-03 05:29:39 +00:00
Basti 526f4b9035 Upgrade Gitea to 1.7.1 2019-02-03 12:28:21 +07:00
Râu Cao 43ad6f842b Merge branch 'docs/update' of kosmos/gitea.kosmos.org into master 2019-01-28 22:42:17 +00:00
Basti 21238a032d Add default and Kosmos label sets
Adds custom label set configs, overriding the default set and adding a
new one for Kosmos (that includes kredits labels).

closes #4
2019-01-27 16:19:19 +08:00
Greg 34068bc7ac Add docs about building our own images 2019-01-25 16:52:17 +01:00
Basti 28b73f88a8 Use 1.7 release of Gitea 2019-01-09 07:55:13 +08:00
Greg 8a2d491e45 Add documentation about updating Gitea 2019-01-08 12:14:41 +01:00
gregkare 8073861775 Merge branch 'feature/5-backups' of kosmos/gitea.kosmos.org into master 2019-01-07 11:02:37 +00:00
Greg 78bccff685 Use the git submodule update command with the --init flag in the docs 2019-01-07 12:01:49 +01:00
Basti cef013a40a Update backup docs 2019-01-05 11:23:17 +08:00
Basti 3692204ce4 Add app label for all Gitea resources
This way one can address them all at once, like e.g. for Ark backups.
2019-01-05 11:09:25 +08:00
Basti a16143a3f4 Add docs for Ark dependency 2019-01-05 10:22:48 +08:00
Basti c3bf234cba Add Ark as submodule
Heptio Ark is a Kubernetes backup solution. See docs.
2019-01-05 10:14:49 +08:00
Basti 9e8370f577 Add backup doc 2019-01-02 12:50:14 +08:00
Râu Cao 8496b19ec5 Update 'doc/kubernetes.md' 2019-01-02 04:20:49 +00:00
Râu Cao 4a43305a35 Merge branch 'docs/kubernetes' of kosmos/gitea.kosmos.org into master 2018-12-24 08:05:03 +00:00
gregkare 8bb6bddb00 Merge branch 'feature/6-remove_init_env_vars' of kosmos/gitea.kosmos.org into master 2018-12-17 10:36:45 +00:00
Greg bf62157f26 Remove the init environment variables
They were never used since we create an ini config file before starting
the container

Refs #6
2018-12-17 11:34:15 +01:00
Basti 0cf7ba527e Move Kubernetes docs out of README 2018-12-14 18:12:39 +00:00
10 changed files with 226 additions and 72 deletions

View File

@ -1,40 +1,9 @@
# gitea.kosmos.org
This repository contains configuration files and other assets, that are used to
deploy and operate this Gitea instance.
deploy and operate this Gitea instance. Feel free to [open
issues](https://gitea.kosmos.org/kosmos/gitea.kosmos.org/issues) for questions,
suggestions, bugs, to-do items, and whatever else you want to discuss or
resolve.
Feel free to [open issues] for questions, suggestions, bugs, to-do items, and
whatever else you want to discuss or resolve.
[open issues]: https://gitea.kosmos.org/kosmos/gitea.kosmos.org/issues
## Kubernetes
### 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:
https://github.com/kubernetes/kubernetes/issues/48609#issuecomment-314066616
See `doc/` folder for some technical info.

View File

@ -0,0 +1,11 @@
#db231d bug ; Something is not working
#76db1d enhancement ; Improving existing functionality
#1d76db feature ; New functionality
#db1d76 idea ; Something to consider
#db1d76 question ; Looking for an answer
#fbca04 security ; All your base are belong to us
#1dd5db ui/ux ; User interface, process design, etc.
#333333 dev environment ; Config, builds, CI, deployment, etc.
#cccccc duplicate ; This issue or pull request already exists
#cccccc invalid ; Not a bug
#cccccc wontfix ; This won't be fixed

View File

@ -0,0 +1,15 @@
#db231d bug ; Something is not working
#ead746 docs ; Documentation
#76db1d enhancement ; Improving existing functionality
#1d76db feature ; New functionality
#db1d76 idea ; Something to consider
#db1d76 question ; Looking for an answer
#fbca04 security ; All your base are belong to us
#1dd5db ui/ux ; User interface, process design, etc.
#333333 dev environment ; Config, builds, CI, deployment, etc.
#008080 kredits-1 ; Small contribution
#008080 kredits-2 ; Medium contribution
#008080 kredits-3 ; Large contribution
#cccccc duplicate ; This issue or pull request already exists
#cccccc invalid ; Not a bug
#cccccc wontfix ; This won't be fixed

28
doc/backup-and-restore.md Normal file
View File

@ -0,0 +1,28 @@
# Backups
We're using [Velero][1] (formerly Ark) for backing up Kubernetes config and GKE
resources. It is available as a compiled binary for your platform [on GitHub][2]
The Velero service is running on the Sidamo cluster and was set up using the
[official docs' GCP instructions][3]. There's a daily backup
schedule in effect for Gitea (using the label `app=gitea`).
Please refer to Velero's [ Getting Started ][4] doc for all backup and restore
commands.
## Backup location
Cluster configuration (including all live resources) is backed up to [a Google
Cloud Storage container][5].
## Persistent volumes
Persistent volumes are just GCE disks. Thus, with the current config, Velero
creates volume snapshots as native [GCE disk snapshots][6].
[1]: https://velero.io/docs/v1.0.0
[2]: https://github.com/heptio/velero/releases/tag/v1.0.0
[3]: https://velero.io/docs/v1.0.0/gcp-config/
[4]: https://velero.io/docs/v1.0.0/about/
[5]: https://console.cloud.google.com/storage/browser/sidamo-backups-new?project=fluted-magpie-218106&organizationId=772167872692
[6]: https://console.cloud.google.com/compute/snapshots?organizationId=772167872692&project=fluted-magpie-218106&tab=snapshots&snapshotssize=50

View File

@ -0,0 +1,20 @@
## Customizations image
### Build
To create a new Docker image containing our Gitea customizations (label sets,
styles, page content, etc.):
Edit `packer/custom.json` to increment the tag, then run this script (needs
[Packer](https://www.packer.io/) in your path)
./script/build_customizations_image
### Deploy
Edit `kubernetes/gitea-server.yaml` to use the new tag
(`image: eu.gcr.io/fluted-magpie-218106/gitea_custom:$VERSION`) and apply the
change:
cd kubernetes
kubectl apply -f gitea-server.yaml

71
doc/kubernetes.md Normal file
View File

@ -0,0 +1,71 @@
# 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

View File

@ -2,6 +2,8 @@ apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: gitea-db
labels:
app: gitea
spec:
replicas: 1
strategy:
@ -10,6 +12,7 @@ spec:
metadata:
labels:
name: gitea-db
app: gitea
spec:
containers:
- env:
@ -29,13 +32,19 @@ spec:
value: gitea
image: mariadb:10.3.10
name: gitea-db
resources: {}
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- mountPath: /var/lib/mysql
name: gitea-db-data
resources:
requests:
cpu: 250m
memory: 150Mi
limits:
cpu: 500m
memory: 300Mi
restartPolicy: Always
volumes:
- name: gitea-db-data
@ -48,6 +57,7 @@ metadata:
name: gitea-db-data
labels:
name: gitea-db-data
app: gitea
spec:
accessModes:
- ReadWriteOnce
@ -61,6 +71,7 @@ metadata:
name: gitea-db
labels:
service: gitea-db
app: gitea
spec:
selector:
name: gitea-db

View File

@ -1,62 +1,52 @@
apiVersion: extensions/v1beta1
apiVersion: apps/v1
kind: Deployment
metadata:
name: gitea-server
labels:
app: gitea
spec:
replicas: 1
selector:
matchLabels:
app: gitea
template:
metadata:
labels:
name: gitea-server
app: gitea
spec:
initContainers:
- name: init-config
image: busybox
command: ['sh', '-c', 'mkdir -p /data/gitea/conf && mkdir -p /data/gitea/https && cp /root/conf/app.ini /data/gitea/conf/app.ini && chown 1000:1000 /data/gitea/conf/app.ini && chmod 660 /data/gitea/conf/app.ini && cp /root/conf/*.pem /data/gitea/https && chmod 600 /data/gitea/https/*.pem && chown -R 1000:1000 /data/gitea']
# This is a busybox image with our gitea customizations saved to
# /custom, built using ./script/build_customizations_image from the
# root of the repo
image: eu.gcr.io/fluted-magpie-218106/gitea_custom:0.1.2
command: [
'sh', '-c',
'mkdir -p /data/gitea/conf && mkdir -p /data/gitea/https && cp /root/conf/app.ini /data/gitea/conf/app.ini && chown 1000:1000 /data/gitea/conf/app.ini && chmod 660 /data/gitea/conf/app.ini && cp /root/conf/*.pem /data/gitea/https && chmod 600 /data/gitea/https/*.pem && cp -R /custom/* /data/gitea && chown -R 1000:1000 /data/gitea'
]
volumeMounts:
- mountPath: /data
name: gitea-server-data
- mountPath: /root/conf
name: config
containers:
# This is only used for the initial setup, it does nothing once a app.ini
# file exists in the conf/ directory of the data directory
# (/data/gitea/conf in our case)
- env:
- name: DB_HOST
value: gitea-db:3306
- name: DB_NAME
value: gitea
- name: DB_PASSWD
valueFrom:
secretKeyRef:
name: gitea-mysql-pass
key: password
- name: DB_TYPE
value: mysql
- name: DB_USER
value: gitea
- name: ROOT_URL
value: https://gitea.kosmos.org
- name: RUN_MODE
value: prod
- name: SECRET_KEY
valueFrom:
secretKeyRef:
name: gitea-secret-key
key: password
- name: SSH_DOMAIN
value: gitea.kosmos.org
image: 5apps/gitea:latest
name: gitea-server
- name: gitea-server
image: gitea/gitea:1.11.2
ports:
- containerPort: 3000
- containerPort: 3001
- containerPort: 22
resources: {}
volumeMounts:
- mountPath: /data
name: gitea-server-data
resources:
requests:
cpu: 150m
memory: 256Mi
limits:
cpu: 250m
memory: 512Mi
restartPolicy: Always
volumes:
- name: gitea-server-data
@ -80,12 +70,14 @@ apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gitea-server-data
labels:
app: gitea
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storage: 20Gi
---
apiVersion: v1
kind: Service
@ -93,6 +85,7 @@ metadata:
name: gitea-server
labels:
name: gitea-server
app: gitea
spec:
type: LoadBalancer
# preserves the client source IP

29
packer/custom.json Normal file
View File

@ -0,0 +1,29 @@
{
"builders": [{
"type": "docker",
"image": "busybox",
"run_command": ["-d", "-i", "-t", "{{.Image}}", "/bin/sh"],
"commit": true
}],
"provisioners": [
{
"inline": ["mkdir /custom"],
"type": "shell"
},
{
"type": "file",
"source": "../custom/",
"destination": "/custom"
}
],
"post-processors": [
[
{
"type": "docker-tag",
"repository": "eu.gcr.io/fluted-magpie-218106/gitea_custom",
"tag": "0.1.2"
},
"docker-push"
]
]
}

View File

@ -0,0 +1,7 @@
#!/usr/bin/env bash
# fail fast
set -e
cd packer/
packer build custom.json
cd -