20161102 - RFC-Docker: Unterschied zwischen den Versionen

Aus RaumZeitLabor Wiki
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
Die Diskussion im NOC-Team hat wohl gezeigt: Docker ist doof fürs NOC, wir machen Ansible. Gut und Schön aber: "Mal eben nen Service hochziehen" (Infoscreen usw.) der keinen relevanten State braucht - bzw. seinen state auf einen zentralen, vom NOC verwalteten, DB-Host bzw. Object-Storage speichert ist einfach mit docker wesentlich einfacher für eine Organisation wie einen Hackerspace wo vielleicht nicht jeder Root auf den Servern ist und wir ja offensichtlich nicht für jeden Member ne vm machen können (Meine Anfrage für ne VM ist seit Januar pending)
Die Diskussion im NOC-Team hat wohl gezeigt: Docker ist doof fürs NOC, wir machen Ansible. Gut und Schön aber: "Mal eben nen Service hochziehen" (Infoscreen usw.) der keinen relevanten State braucht - bzw. seinen state auf einen zentralen, vom NOC verwalteten, DB-Host bzw. Object-Storage speichert ist einfach mit docker wesentlich einfacher für eine Organisation wie einen Hackerspace wo vielleicht nicht jeder Root auf den Servern ist und wir ja offensichtlich nicht für jeden Member ne vm machen können (Meine Anfrage für ne VM ist seit Januar pending)
      --Grade mal auf die NOC ML geschaut: da gibt es keine Anfrage bezüglich einer VM. --[[Benutzer:Docsteel|Docsteel]] ([[Benutzer Diskussion:Docsteel|Diskussion]]) 23:50, 2. Nov. 2016 (CET)


Also folgender Vorschlag:
Also folgender Vorschlag:

Version vom 3. November 2016, 10:45 Uhr

Die Diskussion im NOC-Team hat wohl gezeigt: Docker ist doof fürs NOC, wir machen Ansible. Gut und Schön aber: "Mal eben nen Service hochziehen" (Infoscreen usw.) der keinen relevanten State braucht - bzw. seinen state auf einen zentralen, vom NOC verwalteten, DB-Host bzw. Object-Storage speichert ist einfach mit docker wesentlich einfacher für eine Organisation wie einen Hackerspace wo vielleicht nicht jeder Root auf den Servern ist und wir ja offensichtlich nicht für jeden Member ne vm machen können (Meine Anfrage für ne VM ist seit Januar pending)

Also folgender Vorschlag:

  1. Das NOC betreibt eine VM als dockerhost (beispielsweise RancherOS oder CoreOS) (Hostnahme "rzlocker")
  2. Es gibt ein zentrales github-Repo von dem der rzlocker seine dockerfiles pulled, baut und deployed.
  3. Dort liegt ein Template-File das verwendet werden muss
  4. $member forkt das Repo baut aus dem Template sein Dockerfile zusammen, mach einen PR.
  5. PR wird nach review gemerged --> goto 2.
    • Q: Aber dann haben wir immer noch alte Baseimages ohne security-fixes!!!
    • A: Wir legen im Template fest, dass nur official-base-images mit release-tag verwendet werden dürfen. Die werden jeweils kurzfristig vom distibution-team selbst geupdated (s. https://hub.docker.com/explore/). durch das Flag `--pull` zieht sich der docker-prozess beim bauen des containers jeweils ein akutelles base-image. Jetzt noch ein systemd-service, der um 03:00 alle kontainer neu baut - fertig.
    • Q: Und nach sechs Monaten haben wir 1000 docker-container laufen von denen niemand weiß was sie tun...
    • A: Durch unser github-repo sieht jeder, jederzeit was läuft. Unser PR-Template enthält ferner Dinge wie "was tut es und warum" und "welche Ports braucht es und warum"
    • Q: Jetzt weiß zwar jeder was läuft und warum und die base ist atkuell aber trotzdem wird da ein Zoo wachsen.
    • A: Wir könnten einfach(tm) ein Verfallsdatum für die Container definieren. À la: Service läuft einmal täglich und checkt: Letzte Änderung am dockerfile ist älter als $monate? --> Nachricht an Maintainer: "Mach was damit oder ich schmeiß das Ding in $tagen weg!!"