From 63ba3c41f99506a11c42a57b45db72b81bfbc6e5 Mon Sep 17 00:00:00 2001 From: erik Date: Tue, 5 Sep 2023 12:39:59 +0200 Subject: [PATCH] Cleanup readme --- README.md | 83 ------------------------------------------------------- 1 file changed, 83 deletions(-) diff --git a/README.md b/README.md index 7439ad2..8f247c8 100644 --- a/README.md +++ b/README.md @@ -4,89 +4,6 @@ [DeltaChat chat over e-mail](mailto:buero@meissa-gmbh.de?subject=community-chat) | [team@social.meissa-gmbh.de team@social.meissa-gmbh.de](https://social.meissa-gmbh.de/@team) | [taiga & Blog](https://domaindrivenarchitecture.org) -## Configuration Issues - -We currently can no login even after `python manage.py createsuperuser --noinput` in the taiga-back-deployment container. What might help: https://docs.taiga.io/setup-production.html#taiga-back - -Note: taiga-manage,-back und -async verwenden die gleichen docker images mit unterschiedlichen entry-points. - -https://github.com/kaleidos-ventures/taiga-docker -https://community.taiga.io/t/taiga-30min-setup/170 - -### Steps to start and get an admin user - -Philosophy: First create the superuser, then populate the DB. -https://docs.taiga.io/setup-production.html#taiga-back -https://docs.taiga.io/setup-production.html#_configure_an_admin_user -https://github.com/kaleidos-ventures/taiga-back/blob/main/docker/entrypoint.sh - -In the init container we create the super user. Difference between init-container and container: CELERY_ENABLED: false -The init container gets the following command and args: - -```yaml -command: ["/bin/bash"] -args: ["-c", "source /opt/venv/bin/activate && python manage.py createsuperuser --noinput"] -``` - -Thus the dockerfile default entrypoint is ignored. - -#### Option 1: Init container, currently under test - -Create an init container (celery disabled) with the python manage.py command and the taiga-manage createsuperuser args - -#### Option 2: Single container - -Create a single container that has celery disabled at the beginning. -Runs the following cmds: -* python manage.py taiga-manage createsuperuser -* enable celery -* execute entrypoint.sh - -### 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 (DC) -> Kubernetes - -We implemented a deployment and service in kubernetes for each DC Service. -Configmaps and secrets were implemented, to avoid redundancy and readability also to increase security a bit. -For all volumes described in DC we implemented PVCs and volume refs. - -A config.py (used for taiga-back ) was introduced for reference. -A config.json (used for taiga-front ) was introduced for reference. -NB: It might be necessary to actually map both from a config map to their respective locations in taiga-back and taiga-front. Description for that is [here](https://docs.taiga.io/setup-production.html). -A mix of both env-vars and config.py in one container is not possible. - -#### depends_on - -We currently assume, that it will work without explicitly defining a startup order. - -#### DC 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. - -#### Pod to Pod Possible Communications - -Taiga containers that need to reach other taiga containers: -taiga-async -> taiga-async-rabbitmq -taiga-events -> taiga-events-rabbitmq -This is not quite clear, but probably solved with the implementation of services. - -### Deployments - -Separate deployments exist for each of the taiga modules: - -Taiga-back reads many values in config.py from env vars as can be seen in the taiga-back [config.py]( -https://github.com/kaleidos-ventures/taiga-back/blob/main/docker/config.py). These are read from configmaps and secrets in the deployment. - ## Purpose Easily generate a config for a small scale Taiga deployment. Complete with initial super user and configurable values for flexibility.