orchestration decisions

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)] <!-- optional -->
+* Status: accepted
-* Deciders: [list everyone involved in the decision] <!-- optional -->
+* Deciders: philipp
-* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->
+* Date: 2021
 
 Technical Story: [description | ticket/issue URL] <!-- optional -->
 
 ## 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 <!-- optional -->
 
-* [driver 1, e.g., a force, facing concern, …]
+* Freie Software
-* [driver 2, e.g., a force, facing concern, …]
+* Einarbeitungszeit
-* … <!-- numbers of drivers can vary -->
+* Geringe Komplexität
+* Geringer Wartungsaufwand für Konfigurationen
+* Nachhaltig, Langlebig
+* Separierung (Security)
+* Modularität (Unabhängigkeit)
+
 
 ## Considered Options
 
-* [option 1]
+* YunoHost
-* [option 2]
+* Cloudron
-* [option 3]
+* Stackspin (Kubernetes)
-* … <!-- numbers of options can vary -->
+* 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 <!-- optional -->
 
-* [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 <!-- optional -->
 
-* [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 <!-- optional -->
 
-### [option 1]
+### Ansible
 
-[example | description | pointer to more information | …] <!-- optional -->
+* :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]
+### Yunohost
-* Good, because [argument b]
-* Bad, because [argument c]
-* … <!-- numbers of pros and cons can vary -->
 
-### [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 | …] <!-- optional -->
+### Stackspin 
 
-* Good, because [argument a]
+* :heavy_plus_sign:  Mehr orchestrierungsfeatures von k8s
-* Good, because [argument b]
+* :heavy_plus_sign:  Skalierbarkeit? (bisher nur single-node)
-* Bad, because [argument c]
+* :heavy_plus_sign:  SSO bereits automatsiert als k8s configs
-* … <!-- numbers of pros and cons can vary -->
+* :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 | …] <!-- optional -->
-
-* Good, because [argument a]
-* Good, because [argument b]
-* Bad, because [argument c]
-* … <!-- numbers of pros and cons can vary -->
 
 ## Links <!-- optional -->