npm (Node Package Manager) und pip sind die Paketverwaltungen der beiden populärsten Programmier-Ökosysteme: npm für JavaScript/Node.js, pip für Python. Beide installieren fertige Bibliotheken, verwalten Abhängigkeiten und halten Projekte reproduzierbar.

npm: JavaScript-Bibliotheken installieren

npm init -y
npm install express

npm init erzeugt die package.json (Projektbeschreibung + Abhängigkeiten). npm install <paket> lädt das Paket in node_modules und trägt es in die package.json ein.

• npm install — installiert alle in package.json gelisteten Abhängigkeiten (im frisch geklonten Projekt)
• npm install -g <paket> — global installieren (z.B. CLI-Werkzeuge)
• npm uninstall <paket> — Paket entfernen
• npm run <skript> — Skript aus package.json ausführen (z.B. npm run dev)
• npm audit — Sicherheitslücken in Abhängigkeiten melden

pip: Python-Bibliotheken installieren

pip install requests
pip install -r requirements.txt

Die requirements.txt listet alle Abhängigkeiten eines Python-Projekts — mit pip install -r werden sie komplett installiert. Das Gegenstück zu package.json.

• pip install --upgrade <paket> — Paket aktualisieren
• pip uninstall <paket> — Paket entfernen
• pip freeze — alle installierten Pakete mit Versionsnummern anzeigen
• pip list — installierte Pakete auflisten
• pip show <paket> — Details zu einem Paket (Version, Abhängigkeiten, Homepage)

Virtuelle Umgebungen: Der saubere Weg in Python

python3 -m venv .venv
source .venv/bin/activate

Pip installiert standardmäßig systemweit — auf modernen Systemen (PEP 668) oft blockiert. Eine virtuelle Umgebung kapselt die Pakete pro Projekt: python3 -m venv .venv anlegen, dann aktivieren. Node.js löst dasselbe Problem projektlokal mit node_modules und package-lock.json (exakte Versionen).

Praxis-Tipp

Immer die Lock-Dateien versionieren (package-lock.json, alternativ pip freeze > requirements.txt), damit alle Teammitglieder exakt dieselben Versionen bekommen. Vor dem Deployment npm audit bzw. pip list --outdated laufen lassen.

Verwandte Grundlagen: git: Versionierung und Teamarbeit und YAML, TOML und JSON.

kubectl ist das Kommandozeilen-Werkzeug für Kubernetes (K8s), die Plattform zur Verwaltung von Container-Anwendungen im Cluster. Mit kubectl startet man Pods, skaliert Dienste, prüft Logs und behebt Probleme — alles über die Kubernetes-API.

Grundlagen: Cluster und Pods anzeigen

kubectl get nodes
kubectl get pods

kubectl get nodes listet die Maschinen (Nodes) des Clusters, kubectl get pods die laufenden Pods im aktuellen Namespace. Mit kubectl get all sieht man Pods, Dienste und Deployments auf einen Blick.

• kubectl get pods -A — Pods in allen Namespaces
• kubectl get services — die Dienste (Service) mit ihren Cluster-IPs
• kubectl get deployments — die Deployments (gewünschter Zustand der Anwendung)

Arbeit mit Deployments

kubectl create deployment nginx --image=nginx
kubectl scale deployment nginx --replicas=3

kubectl create deployment legt ein Deployment an — Kubernetes hält daraufhin immer die gewünschte Anzahl Replicas am Leben. kubectl scale erhöht oder verringert die Anzahl der Pods.

• kubectl rollout status deployment/nginx — Fortschritt eines Updates (Rollout) anzeigen
• kubectl rollout undo deployment/nginx — zum letzten funktionierenden Stand zurück
• kubectl set image deployment/nginx nginx=nginx:1.27 — Image eines Deployments aktualisieren

Mit Manifesten arbeiten (empfohlen)

kubectl apply -f deployment.yaml
kubectl delete -f deployment.yaml

Statt Befehle zu tippen, beschreibt man den gewünschten Zustand in einer YAML-Datei und übergibt sie an kubectl apply — genau wie bei terraform wird der Soll-Zustand deklarativ festgelegt. kubectl delete -f entfernt alle in der Datei beschriebenen Ressourcen.

Diagnose: Logs, Shell und Ports

kubectl logs <pod>
kubectl exec -it <pod> -- bash
kubectl port-forward <pod> 8080:80

• kubectl logs <pod> — die Ausgabe des Containers (Logs) anzeigen
• kubectl exec -it <pod> -- bash — eine Shell im laufenden Container öffnen (ähnlich docker exec)
• kubectl describe pod <pod> — Details und Ereignisse zu einem Pod, wichtig beim Debuggen
• kubectl port-forward <pod> 8080:80 — einen lokalen Port auf den Container weiterleiten

Context und Konfiguration

kubectl config get-contexts
kubectl config use-context mein-cluster

Ein Context bündelt Cluster, Benutzer und Namespace. Mit kubectl config use-context wechselt man zwischen mehreren Clustern (z.B. Entwicklung und Produktion).

Praxis-Tipp

Für die tägliche Arbeit: kubectl get pods -w beobachtet Pods live, kubectl delete pod <pod> startet einen Pod neu (das Deployment erzeugt automatisch einen neuen). Kubernetes-Ressourcen gehören in Git versioniert — dazu passen git-Befehle und die Grundlagen zu docker.

terraform von HashiCorp ist das Standard-Werkzeug für Infrastructure as Code: Man beschreibt Server, Netzwerke und Cloud-Ressourcen in deklarativen Konfigurationsdateien (HCL) und terraform erstellt, ändert und löscht sie automatisch — reproduzierbar und versionierbar.

Der Arbeitsablauf: init, plan, apply

terraform init
terraform plan
terraform apply

• terraform init — initialisiert das Projekt und lädt die benötigten Provider-Plugins (z.B. AWS, Hetzner, Proxmox)
• terraform plan — zeigt den geplanten Änderungen im Vergleich zum aktuellen Zustand (Dry-Run, ändert nichts)
• terraform apply — führt die geplanten Änderungen aus; nach Rückfrage yes bestätigen

Eine minimale Konfiguration (main.tf) sieht so aus:

resource "local_file" "beispiel" {
  content  = "Hallo Terraform"
  filename = "${path.module}/hallo.txt"
}

Zustand verwalten

terraform state list
terraform show

Terraform führt Buch über jede verwaltete Ressource im State (Datei terraform.tfstate). terraform state list zeigt alle verwalteten Ressourcen, terraform show den kompletten Zustand im Detail. Der State gehört in ein Remote-Backend (z.B. S3 oder GitLab), wenn mehrere Personen arbeiten.

Qualität sichern

terraform fmt
terraform validate

terraform fmt formatiert alle .tf-Dateien einheitlich, terraform validate prüft die Syntax und die interne Konsistenz — beides ideal vor jedem Commit.

Ressourcen entfernen

terraform destroy

terraform destroy entfernt alle in der Konfiguration beschriebenen Ressourcen. Vorsicht: Das löscht echte Server und Daten! terraform plan -destroy zeigt vorher, was entfernt würde.

Praxis-Tipp

Variablen gehören in variables.tf (Werte in terraform.tfvars oder als TF_VAR_<name>-Umgebungsvariablen). Geheime Werte nie im Code ablegen — dafür gibt es ansible-vault oder Secrets-Manager der Cloud. Die deklarative Arbeitsweise (Soll-Zustand beschreiben, Tool gleicht ab) ist dieselbe wie bei kubectl apply.

ansible automatisiert die Konfiguration von Servern — ohne Agent auf den Zielsystemen. Ansible verbindet sich per SSH (unter Windows per WinRM), führt Aufgaben (Tasks) aus und bringt die Systeme in den gewünschten Zustand. Playbooks sind in YAML geschrieben und dadurch leicht lesbar.

Ad-hoc-Befehle: Schnell etwas prüfen

ansible all -m ping
ansible all -m command -a "uptime"

ansible all -m ping testet die Verbindung zu allen Hosts des Inventars. Mit -m command -a "uptime" führt man einen einzelnen Befehl auf allen Servern aus — ohne ein Playbook schreiben zu müssen.

• ansible all -m apt -a "name=nginx state=latest" -b — Pakete installieren (-b = sudo)
• ansible all -m service -a "name=nginx state=restarted" -b — Dienste neu starten

Das Inventar

[webserver]
web1.example.com
web2.example.com

Die Datei hosts (Inventar) gruppiert die Server, auf denen Ansible arbeitet. Gruppen wie [webserver] oder [datenbank] erlauben, Befehle und Playbooks gezielt nur auf bestimmte Maschinen anzuwenden.

Playbooks: Der Standardweg

ansible-playbook playbook.yml

Ein Playbook beschreibt den Soll-Zustand deklarativ — Ansible prüft, was schon erfüllt ist, und ändert nur, was nötig ist (idempotent):

---
- hosts: webserver
  become: yes
  tasks:
    - name: Nginx installieren
      apt:
        name: nginx
        state: present

• ansible-playbook playbook.yml --check — Probelauf, ohne etwas zu ändern
• ansible-playbook playbook.yml --syntax-check — nur Syntax prüfen
• ansible-playbook playbook.yml --limit web1.example.com — nur einen Host ansprechen
• ansible-playbook playbook.yml -v — ausführliche Ausgabe (-vvv für Debugging)

Geheimnisse verschlüsseln: ansible-vault

ansible-vault encrypt group_vars/all.yml
ansible-playbook playbook.yml --ask-vault-pass

ansible-vault encrypt verschlüsselt Dateien mit Passwörtern oder Schlüsseln — damit können Secrets (API-Keys, Zugangsdaten) sicher im Repository liegen. Beim Lauf werden sie per --ask-vault-pass oder Vault-Key-Datei entschlüsselt.

Rollen und Galaxy

ansible-galaxy init meine-rolle
ansible-galaxy install geerlingguy.nginx

Rollen bündeln Tasks, Templates und Variablen zu wiederverwendbaren Bausteinen. ansible-galaxy lädt fertige Rollen aus der Ansible Galaxy Bibliothek — so bekommt man bewährte Konfigurationen für Webserver, Datenbanken und mehr.

Praxis-Tipp

Immer mit --check starten, Host-Variablen in group_vars/ und host_vars/ organisieren und Playbooks versionieren — am besten mit git. Die SSH-Grundlagen dazu stehen im Artikel ssh, scp und rsync, die Konfigurations-Syntax stammt aus YAML.