Frage Lebenszyklen, FreeBSD als Server

mod3

Well-Known Member
Hallo zusammen,

mir gefällt FreeBSD recht gut. Ich überlege insbesondere, es auf dem ein oder anderen Dateiserver einzusetzen.
Hauptsächlich deshalb, weil mir die native ZFS-Unterstützung sehr zusagt.

Nun werden die einzelnen Releases ja nur recht kurz mit Updates versorgt und das wirft bei mir folgende Frage auf:
Wie handhabt ihr das im Unternehmen?
Ich kann manche Server schon allein wegen der Wartungsfenster nicht jedes Jahr oder alle 2 Jahre neu aufsetzen.
Gleichzeitig möchte ich natürlich auch keine Systeme laufen lassen, die schon EOL sind.
Bei manchen Linux-Distributionen bekomme ich hingegen bis zu 10 Jahre Update-Support...

Wie macht ihr das so?
 
Also: FreeBSD hat derzeit 5 Jahre Support für Hauptreleases, das reicht für die meisten Einsatzzwecke aus. Die einzelnen Subreleases haben ca. 15 Monate Support, dann muss man halt mal auf ein neues Subrelease gehen. Genauso wie man auch sein Debian und sein Red Hat ab und an mal auf das aktuelle Subrelease heben muss.

Wir machen in der Firma bereits seit Jahren keine Updates mehr. Updates sind zeitraubende, fehleranfällige Handarbeit. Stattdessen gibt es zu jedem System ein Ansible-Playbook und jedes System ist so aufgebaut, dass persistente Daten unter /data liegen. Jede Änderung, egal ob neue Konfiguration, Update eines Pakets, Update auf ein neues FreeBSD oder einfach eine Änderung an unser Software ist immer Redeployment. Das läuft grob so ab:
  1. Generiere per Script ein neues Jail oder eine neue VM.
  2. Konfiguriere den neuen Host per Ansible.
  3. Beende den alten Host.
  4. Hebe /data von dem alten Host in den neuen Host.
  5. Starte den neuen Host.
Damit hat man Downtimes im Bereich von unter einer Minute. Wenn die Minute nicht drin ist, ist der Host sowieso zu wichtig und da müssen ganz andere Geschütze aufgefahren werden, um die Verfügbarkeit sicherzustellen. Da mir bisher und wahrscheinlich auch in Zukunft der Masochismus für K8S fehlte, ist der ganze Prozess händisch mit ein paar Shellscripten zusammengeklebt.
 
Die große unhandliche Businesssoftware die 10 Jahre+ läuft ist meist ohnehin nur für RHEL oder SLES zertifiziert da steht sich also die Frage nicht wirklich. Bei allem anderen sind die 5 Jahre idr. ausreichend lange. Minor upgrades sind auf FreeBSD auch sehr einfach zu handhaben.

Bei neueren Systemen haben wir haber auch einen Prozess ähnlich wie ihn Yamagi beschrieben hat, denke auch die Zukunft wird sich immer mehr dahin entwicklen.
 
Da mir bisher und wahrscheinlich auch in Zukunft der Masochismus für K8S fehlte, ist der ganze Prozess händisch mit ein paar Shellscripten zusammengeklebt.

Kubernetes hochverfügbar zu betreiben ist auch (noch) eine Mammutaufgabe, die man gerne auslagert. Mit Kubernetes werden aber unterbrechungsfreie Updates und Upgrades auf breiter Front unglaublich trivial.

Bei neueren Systemen haben wir haber auch einen Prozess ähnlich wie ihn Yamagi beschrieben hat, denke auch die Zukunft wird sich immer mehr dahin entwicklen.

Auch in technologisch eher konservativen Unternehmen ist inzwischen Infrastructure as Code Standard. Natürlich gibt es trotzdem noch genug Stellen, an denen händisch gearbeitet wird, die werden aber zum Glück immer weniger. Wenn man diesen Schritt gemacht hat, ist es auch zu Immutable Infrastructure nicht mehr weit.

Als Admin ohne Kenntnis von Infrastructure as Code wird man sich (zu Recht) selbst beim momentanen IT-Arbeitsmarkt schwer tun, einen neuen Job zu finden.
 
@Yamagi Wird das OS auch per Ansible installiert? Könntest du mir/uns mal ein kleines Beispiel Playbook zeigen oder gute Ressourcen verlinken? Gerade das Thema Basisinstallation (openntpd, ssmtp, "default configs" etc) von FreeBSD mit Ansible finde ich interessant, nur hatte ich bisher keine Zeit dafür :(
 
Vielen Dank für eure Antworten :-)

Ich habe das wohl schlicht missverstanden...
5 Jahre genügen mir jedenfalls völlig!
 
Zurück
Oben