Wiki workshop · Γερμανικά

Vagrant Workshop – Übersicht

Dieser Workshop führt von Grundlagen bis zu reproduzierbaren Team-Labs, Provider-Betrieb, Provisioning, Security-Review und Incident Re…

Παραδείγματα workshop σε ZIP
Πρόοδος μάθησης στη web app

Σημειώστε κεφάλαια ως αναγνωσμένα, δείτε την πρόοδο ανάγνωσης και ολοκληρώστε πρακτικές ενότητες αφού ενεργοποιήσετε την προαιρετική web app. Η πρόοδος του workshop υπολογίζεται από τα κεφάλαια όλων των σελίδων τεκμηρίωσης. Οι επιλογές μένουν σε αυτή τη συσκευή· δεν υπάρχει λογαριασμός ή συγχρονισμός με server. Δεν απαιτείται εγκατάσταση. Η ανάκληση στις Ρυθμίσεις απορρήτου διαγράφει την πρόοδο.

Πρόοδος ανάγνωσης0%
0%
0 / 11 κεφάλαια που διαβάστηκαν
Άλλη γλωσσική έκδοσηΑγγλικά ↗Ελληνικά ↗

Vagrant Workshop – Übersicht

Überblick

Dieser Workshop führt von Grundlagen bis zu reproduzierbaren Team-Labs, Provider-Betrieb, Provisioning, Security-Review und Incident Response.

Der Fokus liegt auf:

  • Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen
  • Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen
  • Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt
  • Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben
  • Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten
  • Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren
  • Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen
  • Plugins als Code-Lieferkette behandeln und Versionen dokumentieren
  • Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden
  • Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen
01 / 11

Quickstart

bash
# Workshop content is provided through the Orthevs Academy.
chmod +x scripts/provision_vagrant.sh
./scripts/provision_vagrant.sh --dry-run
./examples/00-lab-skeleton/run.sh
02 / 11

Zielgruppe

Developer, DevOps Engineers, Platform Engineers, SREs, Administratoren, Security Engineers und Tech Leads, die lokale oder teamweite Entwicklungsumgebungen mit Vagrant standardisieren wollen.

03 / 11

Lernpfad

Level Schwerpunkt Ergebnis
Grundlagen Vagrant CLI, Vagrantfile, Boxen, Single-VM-Workflow und sichere Lab-Bedienung Du kannst Vagrant-Umgebungen erklären, reviewen, lokal validieren und sicher betreiben.
Intermediate Provider, Netzwerke, synced folders, Provisioner und Multi-Machine-Topologien Du kannst Vagrant-Umgebungen erklären, reviewen, lokal validieren und sicher betreiben.
Professional Team-Standards, Box-Lifecycle, CI-Validierung, Registry-Nutzung und reproduzierbare Umgebungen Du kannst Vagrant-Umgebungen erklären, reviewen, lokal validieren und sicher betreiben.
Advanced Security Trust-Modell, Box-Provenienz, SSH, Secrets, Plugins, Netzwerkexposition und Incident Response Du kannst Vagrant-Umgebungen erklären, reviewen, lokal validieren und sicher betreiben.
04 / 11

Aufbau

05 / 11

Workshop-Aufbau

text
.
├── assessments/
├── docs/
├── examples/
├── exercises/
├── media/
├── scripts/
├── workshops/
├── LICENSE.md
└── README-DE.md
06 / 11

Voraussetzungen

  • Linux, macOS oder Windows mit einem unterstützten Provider
  • Vagrant
  • ein Provider wie VirtualBox, Hyper-V, Docker, VMware oder libvirt
  • Bash und Git für die lokalen Beispielprüfungen
  • optional Ansible, cloud-init und provider-spezifische Tools
07 / 11

Sicherheitsmodell

  • Beispiele starten keine VM automatisch und schreiben nur unter work/.
  • Produktive Hosts, Secrets und Kundendaten gehören nicht in Labs.
  • Boxen, Plugins und Provisioner sind Teil der Lieferkette und brauchen Review.
  • Öffentliche Netzwerke und geteilte Ordner sind explizite Risikoentscheidungen.
08 / 11

Offizielle Dokumentation

09 / 11

Arbeitsweise

  • Änderungen an Vagrantfile und Provisionern über Pull Requests reviewen.
  • Vagrantfiles mit vagrant validate und statischen Checks prüfen.
  • Provider-spezifische Abweichungen dokumentieren, statt sie im Team stillschweigend vorauszusetzen.
  • Rollback immer vor vagrant destroy, Box-Update oder Plugin-Update klären.
10 / 11

Praxisanhang: README-Kompetenzkarten

Die folgenden Karten sind als Wiederholungs-, Review- und Coachingmaterial gedacht. Jede Karte hat einen klaren Vagrant-Bezug und kann als kurze Übung, Pairing-Frage oder Pull-Request-Kommentar genutzt werden.

Karte 001: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen

  • Kontext: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant init — erstellt ein initiales Vagrantfile für eine Box.
  • Reviewfrage: Welche Box wird verwendet, wer pflegt sie und welche Version ist freigegeben?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 002: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen

  • Kontext: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant validate — prüft die Vagrantfile-Struktur, ohne eine VM zu starten.
  • Reviewfrage: Welcher Provider wird vorausgesetzt und welche Host-Berechtigungen braucht er?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 003: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt

  • Kontext: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant up — erstellt und startet die konfigurierte Umgebung.
  • Reviewfrage: Welche Ports, privaten Netze oder öffentlichen Netze werden geöffnet?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 004: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben

  • Kontext: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant status — zeigt den lokalen VM-Zustand.
  • Reviewfrage: Welche Dateien werden zwischen Host und Gast synchronisiert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 005: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten

  • Kontext: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant ssh — öffnet eine SSH-Sitzung zum Gast.
  • Reviewfrage: Welche Provisioner laufen mit root-Rechten und sind sie idempotent?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 006: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren

  • Kontext: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant ssh-config — zeigt die konkrete SSH-Konfiguration.
  • Reviewfrage: Welche Plugins sind nötig und wie werden sie versioniert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 007: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen

  • Kontext: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant provision — führt Provisioner erneut aus.
  • Reviewfrage: Welche Host-Ressourcen belegt die Umgebung bei vagrant up?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 008: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren

  • Kontext: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant reload — startet eine VM neu und liest Konfigurationsänderungen.
  • Reviewfrage: Wie sieht der Recovery-Pfad bei beschädigter VM, Box-Regression oder SSH-Fehler aus?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 009: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden

  • Kontext: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant halt — fährt eine VM kontrolliert herunter.
  • Reviewfrage: Welche Box wird verwendet, wer pflegt sie und welche Version ist freigegeben?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 010: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen

  • Kontext: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant destroy — löscht die VM-Ressourcen nach Bestätigung.
  • Reviewfrage: Welcher Provider wird vorausgesetzt und welche Host-Berechtigungen braucht er?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 011: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen

  • Kontext: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant box list — listet lokal installierte Boxen.
  • Reviewfrage: Welche Ports, privaten Netze oder öffentlichen Netze werden geöffnet?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 012: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen

  • Kontext: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant box update — prüft und lädt Box-Updates.
  • Reviewfrage: Welche Dateien werden zwischen Host und Gast synchronisiert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 013: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt

  • Kontext: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant plugin list — zeigt installierte Plugins.
  • Reviewfrage: Welche Provisioner laufen mit root-Rechten und sind sie idempotent?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 014: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben

  • Kontext: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant snapshot save — legt einen Snapshot an, falls der Provider es unterstützt.
  • Reviewfrage: Welche Plugins sind nötig und wie werden sie versioniert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 015: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten

  • Kontext: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant init — erstellt ein initiales Vagrantfile für eine Box.
  • Reviewfrage: Welche Host-Ressourcen belegt die Umgebung bei vagrant up?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 016: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren

  • Kontext: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant validate — prüft die Vagrantfile-Struktur, ohne eine VM zu starten.
  • Reviewfrage: Wie sieht der Recovery-Pfad bei beschädigter VM, Box-Regression oder SSH-Fehler aus?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 017: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen

  • Kontext: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant up — erstellt und startet die konfigurierte Umgebung.
  • Reviewfrage: Welche Box wird verwendet, wer pflegt sie und welche Version ist freigegeben?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 018: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren

  • Kontext: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant status — zeigt den lokalen VM-Zustand.
  • Reviewfrage: Welcher Provider wird vorausgesetzt und welche Host-Berechtigungen braucht er?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 019: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden

  • Kontext: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant ssh — öffnet eine SSH-Sitzung zum Gast.
  • Reviewfrage: Welche Ports, privaten Netze oder öffentlichen Netze werden geöffnet?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 020: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen

  • Kontext: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant ssh-config — zeigt die konkrete SSH-Konfiguration.
  • Reviewfrage: Welche Dateien werden zwischen Host und Gast synchronisiert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 021: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen

  • Kontext: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant provision — führt Provisioner erneut aus.
  • Reviewfrage: Welche Provisioner laufen mit root-Rechten und sind sie idempotent?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 022: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen

  • Kontext: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant reload — startet eine VM neu und liest Konfigurationsänderungen.
  • Reviewfrage: Welche Plugins sind nötig und wie werden sie versioniert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 023: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt

  • Kontext: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant halt — fährt eine VM kontrolliert herunter.
  • Reviewfrage: Welche Host-Ressourcen belegt die Umgebung bei vagrant up?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 024: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben

  • Kontext: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant destroy — löscht die VM-Ressourcen nach Bestätigung.
  • Reviewfrage: Wie sieht der Recovery-Pfad bei beschädigter VM, Box-Regression oder SSH-Fehler aus?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 025: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten

  • Kontext: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant box list — listet lokal installierte Boxen.
  • Reviewfrage: Welche Box wird verwendet, wer pflegt sie und welche Version ist freigegeben?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 026: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren

  • Kontext: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant box update — prüft und lädt Box-Updates.
  • Reviewfrage: Welcher Provider wird vorausgesetzt und welche Host-Berechtigungen braucht er?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 027: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen

  • Kontext: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant plugin list — zeigt installierte Plugins.
  • Reviewfrage: Welche Ports, privaten Netze oder öffentlichen Netze werden geöffnet?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 028: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren

  • Kontext: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant snapshot save — legt einen Snapshot an, falls der Provider es unterstützt.
  • Reviewfrage: Welche Dateien werden zwischen Host und Gast synchronisiert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 029: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden

  • Kontext: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant init — erstellt ein initiales Vagrantfile für eine Box.
  • Reviewfrage: Welche Provisioner laufen mit root-Rechten und sind sie idempotent?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 030: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen

  • Kontext: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant validate — prüft die Vagrantfile-Struktur, ohne eine VM zu starten.
  • Reviewfrage: Welche Plugins sind nötig und wie werden sie versioniert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 031: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen

  • Kontext: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant up — erstellt und startet die konfigurierte Umgebung.
  • Reviewfrage: Welche Host-Ressourcen belegt die Umgebung bei vagrant up?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 032: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen

  • Kontext: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant status — zeigt den lokalen VM-Zustand.
  • Reviewfrage: Wie sieht der Recovery-Pfad bei beschädigter VM, Box-Regression oder SSH-Fehler aus?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 033: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt

  • Kontext: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant ssh — öffnet eine SSH-Sitzung zum Gast.
  • Reviewfrage: Welche Box wird verwendet, wer pflegt sie und welche Version ist freigegeben?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 034: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben

  • Kontext: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant ssh-config — zeigt die konkrete SSH-Konfiguration.
  • Reviewfrage: Welcher Provider wird vorausgesetzt und welche Host-Berechtigungen braucht er?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 035: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten

  • Kontext: Provisioner idempotent schreiben und Paketinstallationen reproduzierbar halten ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant provision — führt Provisioner erneut aus.
  • Reviewfrage: Welche Ports, privaten Netze oder öffentlichen Netze werden geöffnet?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 036: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren

  • Kontext: Synced folders auf minimale Pfade begrenzen und keine Secrets synchronisieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant reload — startet eine VM neu und liest Konfigurationsänderungen.
  • Reviewfrage: Welche Dateien werden zwischen Host und Gast synchronisiert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 037: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen

  • Kontext: Box-Updates kontrolliert testen statt ungeprüft in Team-Labs auszurollen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant halt — fährt eine VM kontrolliert herunter.
  • Reviewfrage: Welche Provisioner laufen mit root-Rechten und sind sie idempotent?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 038: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren

  • Kontext: Plugins als Code-Lieferkette behandeln und Versionen dokumentieren ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant destroy — löscht die VM-Ressourcen nach Bestätigung.
  • Reviewfrage: Welche Plugins sind nötig und wie werden sie versioniert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 039: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden

  • Kontext: Snapshots nur als Laborhilfe verstehen und nicht als Backup-Ersatz verwenden ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant box list — listet lokal installierte Boxen.
  • Reviewfrage: Welche Host-Ressourcen belegt die Umgebung bei vagrant up?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 040: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen

  • Kontext: Fehlerbehebung mit vagrant status, ssh-config, port, provision und provider-spezifischen Logs beginnen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant box update — prüft und lädt Box-Updates.
  • Reviewfrage: Wie sieht der Recovery-Pfad bei beschädigter VM, Box-Regression oder SSH-Fehler aus?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 041: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen

  • Kontext: Box-Quelle im HCP Vagrant Registry oder in einer internen Registry prüfen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant plugin list — zeigt installierte Plugins.
  • Reviewfrage: Welche Box wird verwendet, wer pflegt sie und welche Version ist freigegeben?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 042: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen

  • Kontext: Vagrantfile versionieren und Änderungen wie Infrastrukturcode reviewen ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant snapshot save — legt einen Snapshot an, falls der Provider es unterstützt.
  • Reviewfrage: Welcher Provider wird vorausgesetzt und welche Host-Berechtigungen braucht er?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 043: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt

  • Kontext: Provider-Annahmen explizit dokumentieren, besonders VirtualBox, Docker, Hyper-V, VMware und libvirt ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant init — erstellt ein initiales Vagrantfile für eine Box.
  • Reviewfrage: Welche Ports, privaten Netze oder öffentlichen Netze werden geöffnet?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

Karte 044: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben

  • Kontext: Ports standardmäßig an 127.0.0.1 binden und öffentliche Netze separat freigeben ist im Vagrant-Kontext immer Teil eines lokalen Infrastrukturvertrags. Ein Vagrantfile beschreibt nicht nur eine VM, sondern auch Provider-Annahmen, Box-Herkunft, Netzwerke, Synchronisation, Provisioning und den erlaubten Arbeitsbereich auf dem Host. Änderungen müssen deshalb wie Infrastrukturcode bewertet werden: reproduzierbar, reviewbar, rückbaubar und ohne versteckte Secrets.
  • Prüfbefehl: vagrant validate — prüft die Vagrantfile-Struktur, ohne eine VM zu starten.
  • Reviewfrage: Welche Dateien werden zwischen Host und Gast synchronisiert?
  • Nachweis: Halte Vagrantfile-Ausschnitt, erwarteten Zustand, tatsächliche Ausgabe und Rollback-Entscheidung fest.
  • Risiko: Dokumentiere, ob Host-Ressourcen, Netzwerkexposition, Secrets, Box-Vertrauen oder Plugin-Lieferkette betroffen sind.

11 / 11

VAG · Orthevs Academy

31 modules ως ενιαία διαδρομή μάθησης.

Η σειρά παραμένει αμετάβλητη: από τη βασική δομή του lab μέσω τεχνικών θεμελίων και λειτουργικών μοντέλων έως το τελικό troubleshooting. Τα τεχνικά ονόματα καταλόγων διατηρούνται σκόπιμα.

Orthevs – Η μηχανική ως βάση για όσα ακολουθούν.

Το Orthevs ως εφαρμογή

Εγκατάσταση του Orthevs

Η web app του Orthevs μπορεί να εγκατασταθεί σε υποστηριζόμενες κινητές συσκευές και browsers υπολογιστή.

iPhone και iPad

Ανοίξτε το Orthevs στο Safari. Πατήστε Κοινή χρήση και μετά Προσθήκη στην οθόνη αφετηρίας. Ενεργοποιήστε το Άνοιγμα ως web app, αν εμφανίζεται, και πατήστε Προσθήκη.

Android

Για τη web app, ανοίξτε το μενού του browser και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στην αρχική οθόνη. Επιβεβαιώστε την εγκατάσταση.

Browser υπολογιστή

Ανοίξτε το μενού του browser ή το εικονίδιο εγκατάστασης στη γραμμή διευθύνσεων και επιλέξτε Εγκατάσταση εφαρμογής ή Προσθήκη στο Dock.

Η εγκατάσταση της web app εξαρτάται από τον browser. Αν δεν εμφανιστεί διάλογος εγκατάστασης, ακολουθήστε τα βήματα του browser που αναφέρονται παραπάνω.