Server, die man nie patchen kann: Goldene Bilder mit Packer

Es gibt eine alte Art, Server zu betreiben, mit der viele von uns aufgewachsen sind. Man baut eine Maschine auf, installiert die Software und hält sie dann jahrelang am Leben. Sie reparieren, schneiden, reparieren sie von Hand, wenn etwas kaputt geht. Im Laufe der Zeit wird jeder Server etwas anders, und niemand weiß genau, was auf ihnen ist. Die Leute nennen diese Server "Haustiere".

Man wechselt nie einen laufenden Server. Wenn sich etwas ändern muss, bauen Sie ein neues Bild, starten neue Server daraus und werfen die alten weg.

Haustiere gegen Rinder, erneut besucht

Die berühmte Analogie:

• Tiere Sie haben Namen, sind einzigartig und werden gesund behandelt, wenn sie krank sind.
• Rinder Sie haben Nummern, sind identisch und werden ersetzt, wenn sie krank sind.

Die Container machten das Rindermodell für Anwendungen normal. Aber viele Workloads laufen immer noch auf virtuellen Maschinen: Kubernetes-Knoten selbst, Datenbanken, alte Apps, CI-Laufwerke, Appliances. Goldene Bilder bringen die gleiche Idee zu VMs.

Was ist ein goldenes Bild

Ein goldenes Bild ist ein vorgefertigtes Maschinenabbild (ein AMI auf AWS, ein verwaltetes Bild auf Azure, ein benutzerdefiniertes Bild auf Google Cloud, eine Vorlage auf VMware oder Proxmox), das bereits Folgendes enthält:

• Ein modernes, ausgeklügeltes Betriebssystem
• Ihre Überwachungs- und Logging-Mitarbeiter
• Sicherheitswerkzeuge und Konfiguration
• Manchmal ist es die Anwendung selbst.

Ein neuer Server startet in Sekunden, bereits konfiguriert. Keine langen Setup-Skripte beim Booten, kein Drift zwischen den Maschinen.

Wenn ein Server repariert werden muss, repariere ihn nicht. Beheben Sie das Bild und ersetzen Sie den Server.

Bilder mit Packer bauen

Packer, von HashiCorp, ist das gängigste Werkzeug für die Erstellung von Bildern. Sie beschreiben das Bild in HCL, und Packer startet eine temporäre Maschine, führt die Einrichtungsschritte aus und speichert das Ergebnis als Bild.

packer {
  required_plugins {
    amazon = {
      source  = "github.com/hashicorp/amazon"
      version = "~> 1.3"
    }
  }
}

source "amazon-ebs" "base" {
  region        = "eu-central-1"
  instance_type = "t3.small"
  ssh_username  = "ubuntu"
  ami_name      = "acme-base-{{timestamp}}"

  source_ami_filter {
    filters = {
      name                = "ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"
      virtualization-type = "hvm"
    }
    owners      = ["099720109477"] # Canonical
    most_recent = true
  }
}

build {
  sources = ["source.amazon-ebs.base"]

  provisioner "shell" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get -y upgrade",
      "sudo apt-get -y install unattended-upgrades auditd"
    ]
  }

  provisioner "ansible" {
    playbook_file = "./playbooks/harden.yml"
  }
}

Die gleiche Vorlage kann Bilder für mehrere Wolken gleichzeitig erstellen. Provider können Shell-Skripte, Ansible-Playbooks oder andere Tools sein.

Bildpipelines

Bilder von Hand zu bauen, verhindert den Zweck. - Wir müssen es in eine Pipeline bringen.

1. Bauen das Bild in einem Zeitplan (wöchentlich ist üblich) und wann immer sich die Vorlage ändert.
2. Prüfung es: Ein Beispiel starten, Prüfungen durchführen (Dienste laufen, Ports geschlossen, Harding angewendet). Tools wie Goss oder InSpec helfen.
3. Scannen Es ist für Schwachstellen.
4. Veröffentlichen Sie werden mit einer Version und einem Datum gekennzeichnet und mit den Konten geteilt, die sie benötigen.
5. - Schieben Sie es raus. Sie können die Bildkennung in Ihrem Infrastrukturcode aktualisieren.
6. Sauber machen. alte Bilder nach einer Aufbewahrungszeit.

Cloud-Anbieter bieten auch verwaltete Dienste an, wie EC2 Bildentwickler auf AWS und Azure VM-Bild-Ersteller.

Wie oft ich wieder aufbaue

Sicherheits-Patches werden ständig freigegeben. Bei unveränderlicher Infrastruktur bedeutet Patching, das Bild neu zu bauen und Server zu ersetzen.

Eine wöchentliche Neugestaltung hält die Bilder aktuell. Für kritische Schwachstellen, starten Sie sofort eine zusätzliche Build. Das Schöne an diesem Modell: Das Patchen ist die gleiche Routine wie jeder andere Wechsel, voll automatisiert und getestet, anstelle einer stressigen manuellen Patch-Nacht.

Kopplung mit Autoscaling

Goldene Bilder funktionieren am besten mit Autoscaling-Gruppen (oder VM-Skala-Sets oder verwalteten Instanzgruppen):

1. Bauen Sie sich ein neues Image.
2. Aktualisieren Sie die Startschablone mit der neuen Bild-ID.
3. Auslöser a Rollende Instanz aktualisieren: die Gruppe ersetzt alte Fälle durch neue, einige nach dem anderen, und wartet auf die Gesundheitsprüfung.
4. Wenn etwas nicht stimmt, rollen Sie zurück zur vorherigen Version der Startvorlage.

Kubernetes-Node-Pools funktionieren ähnlich: verwaltete Knotengruppen können mit einem rollenden Ersatz auf ein neues Bild aktualisiert werden. Werkzeuge wie Schreiner Sie gehen noch weiter und ersetzen die Knoten regelmäßig, um sie frisch zu halten.

Was man beachten sollte

• Verwandeln Sie keine Geheimnisse in Bilder. Holen Sie sie bei einem Geheimmanager.
• Umgebungsspezifische Konfiguration aus Das ist auch das Bild. Verwenden Sie Instanz-Metadaten, Tags oder einen Konfigurationsdienst beim Starten.
• Daten über die Lage Sie müssen auf getrennten Volumes oder Diensten leben, also verliert man nichts, wenn man einen Server ersetzt.
• Bildverbreitung: eine Aufbewahrungsrichtlinie festlegen und alte Bilder regelmäßig aufrufen.

Also, ist es das wert?

Für jede Flotte von VMs, die Sie länger als ein paar Wochen betreiben, ja. Weniger Überraschungen, schnelleres Skalieren, einfacher zu patchen, und Sie wissen immer genau, was läuft.

Ich sage: Hör auf, Server zu pflegen. Baue sie einmal richtig, ersetze sie oft und lass das Bild das Wissen tragen.

Desly