20161102 - RFC-Docker - Versionsgeschichte

Bfritz0815 am 12. Dezember 2023 um 21:56 Uhr

2023-12-12T21:56:56Z

← Nächstältere Version		Version vom 12. Dezember 2023, 21:56 Uhr
Zeile 16:		Zeile 16:
	** Q: Jetzt weiß zwar jeder was läuft und warum und die base ist atkuell aber trotzdem wird da ein Zoo wachsen.		** 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!!"		** 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!!"

			[[Kategorie:Wiki_Cleanup/ToDo]]

Docsteel am 3. November 2016 um 10:45 Uhr

2016-11-03T10:45:40Z

← Nächstältere Version		Version vom 3. November 2016, 10:45 Uhr
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:

Docsteel am 2. November 2016 um 22:50 Uhr

2016-11-02T22:50:36Z

← Nächstältere Version		Version vom 2. November 2016, 22:50 Uhr
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:

S1lvester: Die Seite wurde neu angelegt: „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…“

2016-11-02T19:48:59Z

Die Seite wurde neu angelegt: „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…“

Neue Seite

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:
# Das NOC betreibt eine VM als dockerhost (beispielsweise RancherOS oder CoreOS) (Hostnahme "rzlocker")
# Es gibt ein zentrales github-Repo von dem der rzlocker seine dockerfiles pulled, baut und deployed.
# Dort liegt ein Template-File das verwendet werden muss
# $member forkt das Repo baut aus dem Template sein Dockerfile zusammen, mach einen PR.
# 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!!"