| doc | ||
| infrastructure/c4k-website-build | ||
| public | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| LICENSE | ||
| package.json | ||
| project.clj | ||
| README.md | ||
| shadow-cljs.edn | ||
convention 4 kubernetes: c4k-taiga
chat over e-mail | 
team@social.meissa-gmbh.de | taiga & Blog
Configuration Issues
https://github.com/kaleidos-ventures/taiga-docker https://community.taiga.io/t/taiga-30min-setup/170
Note: taiga-manage,-back und -async verwenden die gleichen docker images mit unterschiedlichen entry-points.
HTTPS
Terminiert am ingress. Wie interagiert das mit taiga? Eventuell wird dies hier relevant: https://github.com/kaleidos-ventures/taiga-docker#session-cookies-in-django-admin
Docker Compose -> Kubernetes
Wir müssen die compose-yamls nach kubernetes resources übersetzen.
Für das init deployment
Es gibt einen Init-Container mit namen taiga-manage im deployment. ToDo: Dieser erstellt einen Admin User mit credentials aus dem taiga-back-secret.
Einen admin-user anlegen:
https://github.com/kaleidos-ventures/taiga-docker#configure-an-admin-user
folglich:
https://docs.djangoproject.com/en/4.2/ref/django-admin/#django-admin-createsuperuser
Also DJANGO_SUPERUSER_TAIGAADMIN und DJANGO_SUPERUSER_PASSWORD sollten für den Container gesetzt sein.
Dann noch ein run befehl mit: python manage.py createsuperuser im init container unterbringen.
deployment
Taiga reads many values in config.py from env vars as can be seen in the taiga-back config.py. These are read from configmaps and secrets in the deployment.
Mounting a configmap with a config.py as described here: https://docs.taiga.io/setup-production.html could be interesting. A mix of both env-vars and config.py in one container is not possible.
An example for a config.py is given here: https://github.com/kaleidos-ventures/taiga-back/blob/main/settings/config.py.prod.example
- taiga-db
- Postgres
- taiga-back
- taiga-async
- taiga-async-rabbitmq
- taiga-front
- taiga-events
- taiga-events-rabbitmq
- taiga-protected
- taiga-gateway
- Nginx???
- ersetzen durch metallb und ingresse
Volume Mounts
- taiga-static-data:
- taiga-media-data:
- taiga-db-data:
- taiga-async-rabbitmq-data:
- taiga-events-rabbitmq-data:
Secrets
- admin user?
- secret-key
- db
- rabbit-mq
Networking
https://github.com/compose-spec/compose-spec/blob/master/spec.md
The hostname KW sets the hostname of a container.
It should have no effect on the discoverability of the container in kubernetes.
The networks KW defines the networks that service containers are attached to, referencing entries under the top-level networks key.
This should be taken care of by our kubernetes installation.
Taiga containers that need to reach other taiga containers: taiga-async -> taiga-async-rabbitmq taiga-events -> taiga-events-rabbitmq
ToDo: How do we direct traffic towards the frontend pod? Do we need to touch the frontend config regarding the default address (localhost:9000) of the API?
Purpose
Status
Try out
Usage
You need:
...
- and a kubernetes cluster provisioned by provs
...
Let c4k-taiga generate your .yaml file.
Apply this file on your cluster with kubectl apply -f yourApp.yaml.
Done.
resource requests and limits
You may want to adjust the resource requests and limits of the build and init containers to your specific scenario.
Development & mirrors
Development happens at: https://repo.prod.meissa.de/meissa/c4k-taiga
Mirrors are:
- https://gitlab.com/domaindrivenarchitecture/c4k-taiga (issues and PR, CI)
- https://github.com/DomainDrivenArchitecture/c4k-taiga
For more details about our repository model see: https://repo.prod.meissa.de/meissa/federate-your-repos
License
Copyright © 2022 meissa GmbH Licensed under the Apache License, Version 2.0 (the "License") Pls. find licenses of our subcomponents here
