From 2b0b4e189e9a0cd355d992ac5984bed4df6976c3 Mon Sep 17 00:00:00 2001 From: Moritz Date: Wed, 14 Dec 2022 13:35:31 +0100 Subject: [PATCH] orchestration decisions --- .../Infrastructure/orchestration.md | 106 ++++++++++++------ 1 file changed, 69 insertions(+), 37 deletions(-) diff --git a/docs/organisation/entscheidungen/Infrastructure/orchestration.md b/docs/organisation/entscheidungen/Infrastructure/orchestration.md index 4e45494..5af1fdc 100644 --- a/docs/organisation/entscheidungen/Infrastructure/orchestration.md +++ b/docs/organisation/entscheidungen/Infrastructure/orchestration.md @@ -1,72 +1,104 @@ [Source](https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-madr/index.md) -# [short title of solved problem and solution] +# Wie orchestrieren wir unsere Container -* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] -* Deciders: [list everyone involved in the decision] -* Date: [YYYY-MM-DD when the decision was last updated] +* Status: accepted +* Deciders: philipp +* Date: 2021 Technical Story: [description | ticket/issue URL] ## Context and Problem Statement -[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.] +Betrieb von freier Software Webdienste (z.B. Nextcloud). + +Wie können wir Dienste in einem einheitlichen best-practice setup automatisiert deployen? Dabei sollen aber pro Instanz Konfigurationen möglichst flexibel bleiben. + +Außerdem Routineaufgaben sollten leicht zu erledigen sein + * Aufsetzen neuer Dienste + * Versions Upgrade + * Konfigurationsänderungen + * Backup u. Restore ## Decision Drivers -* [driver 1, e.g., a force, facing concern, …] -* [driver 2, e.g., a force, facing concern, …] -* … +* Freie Software +* Einarbeitungszeit +* Geringe Komplexität +* Geringer Wartungsaufwand für Konfigurationen +* Nachhaltig, Langlebig +* Separierung (Security) +* Modularität (Unabhängigkeit) + ## Considered Options -* [option 1] -* [option 2] -* [option 3] -* … +* YunoHost +* Cloudron +* Stackspin (Kubernetes) +* docker-swarm +* ansible +* pyinfra +* coop-cloud + abra +* ## Decision Outcome -Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. +Coop-Cloud und Abra, wegen geringer Einarbeitungszeit und Komplexität, weil viele Architekturentscheidungen (Reverseproxy, Netzwerk, Conventions) schon vorgegeben sind. App deployments (Recipes) werden gemeinschaftlich entwickelt, es wird soweit möglich die upstream container verwendet, das verringert den Wartungsaufwand. Die Container ermöglichen eine Separierung und Modularität zwischen Diensten. + +Wir gehen davon aus, dass Docker-Swarm bestehen bleibt oder von der Community weiterentwickelt wird. +Selbst wenn Coop-Cloud nicht fortgeführt wird, ist mit Docker-Swarm soweit Rückwärts kompatibel, dass wir damit weitermachen könnten. + ### Positive Consequences -* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] -* … +* Wir können dran weiterentwickeln +* Welcoming Community +* Recipes können auch ohne abra weiterverwendet werden +* Viel Gestaltungsfreiraum +* Einfacher Zugriff auf Logs ### Negative Consequences -* [e.g., compromising quality attribute, follow-up decisions required, …] -* … +* Abra noch in Beta, viele Bugs! +* CLI nicht so zugänglich wie z.B. Yunohost, Cloudron +* Pro-Instanz Anpassungen sind durch .env nicht so flexibel ## Pros and Cons of the Options -### [option 1] +### Ansible -[example | description | pointer to more information | …] +* :heavy_plus_sign: Roles für die meisten Apps vorhanden +* :heavy_plus_sign: große Community, weit verbeitet +* :heavy_plus_sign: host konfiguration +* :heavy_minus_sign: Schwieriger zu lernen +* :heavy_minus_sign: nur für un-/deployment geeignet, z.B. kein docker ps? + isolation, backup, upgrades +* :heavy_minus_sign: versionierung? -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* … +### Yunohost -### [option 2] +* :heavy_plus_sign: Administraion UI +* :heavy_plus_sign: Viele Apps supported +* :heavy_plus_sign: Integrierter Mail Server +* :heavy_plus_sign: LDAP Anbindung +* :heavy_plus_sign: Backup, Deploy, CI, Testing +* :heavy_minus_sign: Kein SSO +* :heavy_minus_sign: Keiner Containerisierung +* :heavy_minus_sign: Schwierig mehrere Instanzen zu verwalten +* :heavy_minus_sign: Einrichten pro Instanz über UI +* :heavy_minus_sign: Mehr als Selfhosting gedacht -[example | description | pointer to more information | …] +### Stackspin -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* … +* :heavy_plus_sign: Mehr orchestrierungsfeatures von k8s +* :heavy_plus_sign: Skalierbarkeit? (bisher nur single-node) +* :heavy_plus_sign: SSO bereits automatsiert als k8s configs +* :heavy_minus_sign: Usermgmt Oberfläche fehlen noch viele Features +* :heavy_minus_sign: hoher Ressourcenverbrauch durch k8s +* :heavy_minus_sign: Erstellen neuer Recipes komplex +* :heavy_minus_sign: Installation noch recht komplex -### [option 3] - -[example | description | pointer to more information | …] - -* Good, because [argument a] -* Good, because [argument b] -* Bad, because [argument c] -* … ## Links