Dezember 21, 2025
15 Min. Lesezeit

Junior Site Reliability Engineer: Die ultimative Interview-Fragen-Anleitung

interview
career-advice
job-search
entry-level
Junior Site Reliability Engineer: Die ultimative Interview-Fragen-Anleitung
Milad Bonakdar

Milad Bonakdar

Autor

Meistern Sie die Grundlagen von SRE mit umfassenden Interviewfragen zu Monitoring, Incident Response, SLOs, Automatisierung, Linux-Fehlerbehebung und Zuverlässigkeitspraktiken für Junior SRE-Positionen.


Einführung

Site Reliability Engineering (SRE) kombiniert Softwareentwicklung und Systemadministration, um umfangreiche, zuverlässige Systeme zu erstellen und zu betreiben. Als Junior SRE konzentrierst du dich auf Überwachung, Reaktion auf Vorfälle, Automatisierung und das Erlernen von Zuverlässigkeitspraktiken, die dafür sorgen, dass Dienste reibungslos laufen.

Dieser Leitfaden behandelt wichtige Fragen für Vorstellungsgespräche für Junior SREs, die nach Themen geordnet sind, um dir bei der effektiven Vorbereitung zu helfen. Jede Frage enthält detaillierte Antworten, praktische Beispiele und Hands-on-Szenarien.


SRE-Grundlagen

1. Was ist Site Reliability Engineering und wie unterscheidet es sich von DevOps?

Antwort: SRE ist Googles Ansatz, Produktionssysteme zuverlässig und in großem Umfang zu betreiben.

Hauptprinzipien:

  • Behandlung des Betriebs als Softwareproblem
  • Maximal 50 % der Zeit für operative Tätigkeiten (Toil)
  • Fehlerbudgets zum Ausgleich von Zuverlässigkeit und Geschwindigkeit
  • Fehlerfreie Postmortems
  • Stufenweise Rollouts und automatisierte Rollbacks

SRE vs. DevOps:

AspektSREDevOps
FokusZuverlässigkeit und SkalierbarkeitZusammenarbeit und Automatisierung
MetrikenSLIs, SLOs, FehlerbudgetsHäufigkeit der Bereitstellung, Durchlaufzeit
AnsatzPräskriptiv (spezifische Praktiken)Philosophie (kulturelle Bewegung)
ToilExplizit auf 50 % begrenztNicht spezifisch definiert

SRE implementiert DevOps-Prinzipien mit spezifischen Praktiken und Metriken.

Seltenheit: Sehr häufig Schwierigkeit: Leicht


2. Erkläre SLIs, SLOs und Fehlerbudgets.

Antwort: Dies sind zentrale SRE-Konzepte zur Messung und zum Management der Zuverlässigkeit:

SLI (Service Level Indicator):

  • Quantitative Messung des Servicelevels
  • Beispiele: Latenz, Verfügbarkeit, Fehlerrate

SLO (Service Level Objective):

  • Zielwert für einen SLI
  • Beispiel: "99,9 % der Anfragen sind erfolgreich"

Fehlerbudget:

  • Zulässige Fehlerrate (100 % - SLO)
  • Wird verwendet, um Zuverlässigkeit und Feature-Geschwindigkeit auszugleichen
# Beispiel SLI/SLO-Berechnung
def calculate_error_budget(total_requests, failed_requests, slo_target=0.999):
    """
    Berechnung des Verbrauchs des Fehlerbudgets
    
    SLO: 99,9 % Erfolgsrate
    Fehlerbudget: 0,1 % zulässige Fehler
    """
    success_rate = (total_requests - failed_requests) / total_requests
    error_rate = failed_requests / total_requests
    
    # Fehlerbudget: wie viel der zulässigen 0,1 % wir verbraucht haben
    allowed_errors = total_requests * (1 - slo_target)
    budget_consumed = (failed_requests / allowed_errors) * 100
    
    return {
        'success_rate': success_rate,
        'error_rate': error_rate,
        'slo_target': slo_target,
        'slo_met': success_rate >= slo_target,
        'error_budget_consumed': budget_consumed,
        'remaining_budget': max(0, 100 - budget_consumed)
    }

# Beispiel
result = calculate_error_budget(
    total_requests=1000000,
    failed_requests=500,  # 0,05 % Fehlerrate
    slo_target=0.999
)

print(f"Erfolgsrate: {result['success_rate']:.4%}")
print(f"SLO erfüllt: {result['slo_met']}")
print(f"Verbrauchtes Fehlerbudget: {result['error_budget_consumed']:.1f}%")

Seltenheit: Sehr häufig Schwierigkeit: Mittel


3. Was ist Toil und wie reduzierst du es?

Antwort: Toil ist repetitive, manuelle operative Arbeit, die:

  • Manuell ist (erfordert menschliches Handeln)
  • Repetitiv ist
  • Automatisiert werden kann
  • Keinen bleibenden Wert hat
  • Linear mit dem Service-Wachstum wächst

Beispiele für Toil:

  • Manuelles Neustarten von Diensten
  • Kopieren von Dateien zwischen Servern
  • Manuelles Skalieren von Ressourcen
  • Wiederholte Ticketantworten

Strategien zur Toil-Reduzierung:

# Beispiel: Automatisieren des Neustarts von Diensten
#!/bin/bash
# auto-restart-service.sh

SERVICE_NAME="myapp"
MAX_RETRIES=3
RETRY_DELAY=5

check_service() {
    systemctl is-active --quiet $SERVICE_NAME
    return $?
}

restart_service() {
    echo "$(date): Neustarten von $SERVICE_NAME"
    systemctl restart $SERVICE_NAME
    
    # Warten, bis sich der Dienst stabilisiert hat
    sleep $RETRY_DELAY
    
    if check_service; then
        echo "$(date): $SERVICE_NAME erfolgreich neu gestartet"
        # Benachrichtigung senden
        curl -X POST https://alerts.company.com/webhook \
          -d "{\"message\": \"$SERVICE_NAME automatisch neu gestartet\"}"
        return 0
    else
        return 1
    fi
}

# Hauptlogik
if ! check_service; then
    echo "$(date): $SERVICE_NAME ist ausgefallen"
    
    for i in $(seq 1 $MAX_RETRIES); do
        echo "Versuch $i von $MAX_RETRIES"
        if restart_service; then
            exit 0
        fi
        sleep $RETRY_DELAY
    done
    
    # Alle Wiederholungsversuche fehlgeschlagen - eskalieren
    echo "$(date): Neustart von $SERVICE_NAME nach $MAX_RETRIES Versuchen fehlgeschlagen"
    curl -X POST https://pagerduty.com/api/incidents \
      -d "{\"service\": \"$SERVICE_NAME\", \"severity\": \"critical\"}"
    exit 1
fi

SRE-Ziel: Toil unter 50 % der Zeit halten, den Rest automatisieren.

Seltenheit: Sehr häufig Schwierigkeit: Leicht-Mittel


Überwachung und Observability

4. Was ist der Unterschied zwischen Monitoring und Observability?

Antwort: Monitoring: Sammeln vordefinierter Metriken und Warnungen

  • Known-Unknowns: Du weißt, worauf du achten musst
  • Dashboards, Warnungen, Metriken
  • Beispiele: CPU, Speicher, Anfragerate

Observability: Verstehen des Systemzustands anhand von Ausgaben

  • Unknown-Unknowns: Debuggen von Problemen, die du nicht erwartet hast
  • Protokolle, Metriken, Traces kombiniert
  • Kann beliebige Fragen beantworten
Loading diagram...

Drei Säulen der Observability:

  1. Metriken: Aggregierte Zahlen (CPU, Latenz)
  2. Protokolle: Diskrete Ereignisse
  3. Traces: Anfragefluss durch das System

Beispiel: Prometheus + Grafana + Loki

# Prometheus Scrape-Konfiguration
scrape_configs:
  - job_name: 'api-server'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: '/metrics'
    scrape_interval: 15s

Seltenheit: Häufig Schwierigkeit: Mittel


5. Wie richtest du effektive Warnungen ein?

Antwort: Gute Warnungen sind umsetzbar, aussagekräftig und verursachen keine Ermüdung.

Best Practices für Warnungen:

1. Warne bei Symptomen, nicht bei Ursachen:

# Schlecht: Warnung bei hoher CPU-Auslastung
- alert: HighCPU
  expr: cpu_usage > 80
  
# Gut: Warnung bei Auswirkungen auf den Benutzer
- alert: HighLatency
  expr: http_request_duration_seconds{quantile="0.95"} > 1
  for: 5m
  annotations:
    summary: "API-Latenz ist hoch"
    description: "95. Perzentil der Latenz beträgt {{ $value }}s"

2. Füge Runbook-Links hinzu:

- alert: DatabaseConnectionPoolExhausted
  expr: db_connection_pool_active / db_connection_pool_max > 0.9
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Datenbank-Verbindungspool fast erschöpft"
    runbook: "https://wiki.company.com/runbooks/db-connections"

3. Verwende geeignete Schweregrade:

# Page-würdig (weckt jemanden auf)
- alert: ServiceDown
  expr: up{job="api"} == 0
  for: 1m
  labels:
    severity: critical
    
# Ticket-würdig (während der Geschäftszeiten bearbeiten)
- alert: DiskSpaceWarning
  expr: disk_free_percent < 20
  for: 30m
  labels:
    severity: warning

4. Vermeide Alarmmüdigkeit:

  • Verwende for:, um Flattern zu vermeiden
  • Gruppiere verwandte Warnungen
  • Lege geeignete Schwellenwerte fest
  • Überprüfe und optimiere regelmäßig

Seltenheit: Sehr häufig Schwierigkeit: Mittel


Reaktion auf Vorfälle

6. Beschreibe deinen Prozess zur Reaktion auf Vorfälle.

Antwort: Eine strukturierte Reaktion auf Vorfälle minimiert die Auswirkungen und die Wiederherstellungszeit:

Schritte zur Reaktion auf Vorfälle:

Loading diagram...

1. Erkennung:

  • Warnung wird ausgelöst oder Benutzer meldet ein Problem
  • Warnung bestätigen
  • Vorfall-Kanal erstellen

2. Triage:

# Checkliste für die schnelle Bewertung
- Was sind die Auswirkungen auf den Benutzer?
- Wie viele Benutzer sind betroffen?
- Welche Dienste sind betroffen?
- Wird es schlimmer?

3. Entschärfung:

# Häufige Entschärfungsstrategien
- Rollback der letzten Bereitstellung
- Skalieren der Ressourcen
- Deaktivieren problematischer Funktionen
- Failover auf das Backup-System
- Ratenbegrenzung des Datenverkehrs

4. Behebung:

  • Behebung der Ursache
  • Überprüfen, ob die Metriken wieder normal sind
  • Überwachen auf Wiederauftreten

5. Postmortem (Blameless):

# Vorfall-Postmortem-Vorlage

## Zusammenfassung
Kurze Beschreibung dessen, was passiert ist

## Auswirkungen
- Dauer: 2024-11-25 10:00 - 10:45 UTC (45 Minuten)
- Betroffene Benutzer: ~10.000 (5 % der Gesamtzahl)
- Betroffene Dienste: API, Web Frontend

## Ursache
Datenbank-Verbindungspool aufgrund langsamer Abfragen erschöpft

## Zeitachse
- 10:00: Warnung für hohe API-Latenz ausgelöst
- 10:05: Bereitschaftsingenieur bestätigt
- 10:10: Datenbank als Engpass identifiziert
- 10:15: Größe des Verbindungspools erhöht (Entschärfung)
- 10:30: Langsame Abfragen identifiziert und beendet
- 10:45: Dienst vollständig wiederhergestellt

## Behebung
- Sofort: Verbindungspool von 100 auf 200 erhöht
- Kurzfristig: Abfragetimeout (30 Sekunden) hinzugefügt
- Langfristig: Langsame Abfragen optimieren, Abfrageüberwachung hinzufügen

## Maßnahmen
- [ ] Warnung für langsame Abfragen hinzufügen (Verantwortlicher: Alice, Fällig: 2024-12-01)
- [ ] Abfragetimeout in der Anwendung implementieren (Verantwortlicher: Bob, Fällig: 2024-12-05)
- [ ] Die 10 langsamsten Abfragen überprüfen und optimieren (Verantwortlicher: Charlie, Fällig: 2024-12-10)

## Erkenntnisse
- Die Überwachung des Verbindungspools war unzureichend
- Die Verschlechterung der Abfrageleistung blieb unbemerkt

Seltenheit: Sehr häufig Schwierigkeit: Mittel


7. Wie behebst du Probleme mit einem Dienst, der eine hohe Latenz aufweist?

Antwort: Systematischer Debugging-Ansatz:

# 1. Überprüfe das Problem
curl -w "@curl-format.txt" -o /dev/null -s https://api.example.com/health

# curl-format.txt:
#     time_namelookup:  %{time_namelookup}s\n
#        time_connect:  %{time_connect}s\n
#     time_appconnect:  %{time_appconnect}s\n
#    time_pretransfer:  %{time_pretransfer}s\n
#       time_redirect:  %{time_redirect}s\n
#  time_starttransfer:  %{time_starttransfer}s\n
#                     ----------\n
#          time_total:  %{time_total}s\n

# 2. Überprüfe die Anwendungsmetriken
# - Anfragerate (plötzlicher Anstieg?)
# - Fehlerrate (Fehler, die Wiederholungen verursachen?)
# - Ressourcenauslastung (CPU, Speicher)

# 3. Überprüfe Abhängigkeiten
# - Datenbankabfragezeit
# - Externe API-Aufrufe
# - Cache-Trefferrate

# 4. Überprüfe die Infrastruktur
top  # CPU-Auslastung
free -h  # Speicher
iostat  # Festplatten-E/A
netstat -s  # Netzwerkstatistiken

# 5. Überprüfe die Protokolle auf Fehler
tail -f /var/log/app/error.log | grep -i "timeout\|slow\|error"

# 6. Profiliere die Anwendung
# Python-Beispiel
import cProfile
cProfile.run('my_function()')

# 7. Überprüfe die Datenbank
# Protokoll für langsame Abfragen
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

# Aktive Abfragen
SELECT pid, query, state, query_start 
FROM pg_stat_activity 
WHERE state = 'active';

Häufige Ursachen:

  • Langsame Datenbankabfragen
  • Externe API-Timeouts
  • Speicherdruck (GC-Pausen)
  • Netzwerkprobleme
  • Ressourcenerschöpfung
  • Ineffiziente Codepfade

Seltenheit: Sehr häufig Schwierigkeit: Mittel


Automatisierung und Skripterstellung

8. Schreibe ein Skript, um zu überprüfen, ob ein Dienst fehlerfrei ist, und ihn bei Bedarf neu zu starten.

Antwort: Skript zur Überprüfung des Zustands und zur automatischen Behebung:

#!/usr/bin/env python3
"""
Dienst-Zustandsprüfer mit automatischer Neustartfunktion
"""
import requests
import subprocess
import time
import sys
from datetime import datetime

class ServiceMonitor:
    def __init__(self, service_name, health_url, max_retries=3):
        self.service_name = service_name
        self.health_url = health_url
        self.max_retries = max_retries
    
    def check_health(self):
        """Überprüfen, ob der Dienst fehlerfrei ist"""
        try:
            response = requests.get(
                self.health_url,
                timeout=5
            )
            return response.status_code == 200
        except requests.exceptions.RequestException as e:
            print(f"{datetime.now()}: Zustandsprüfung fehlgeschlagen: {e}")
            return False
    
    def restart_service(self):
        """Neustarten des Dienstes mit systemctl"""
        try:
            print(f"{datetime.now()}: Neustarten von {self.service_name}")
            subprocess.run(
                ['systemctl', 'restart', self.service_name],
                check=True,
                capture_output=True
            )
            time.sleep(10)  # Warten, bis der Dienst gestartet ist
            return True
        except subprocess.CalledProcessError as e:
            print(f"{datetime.now()}: Neustart fehlgeschlagen: {e.stderr}")
            return False
    
    def send_alert(self, message, severity='warning'):
        """Senden einer Warnung an das Überwachungssystem"""
        try:
            requests.post(
                'https://alerts.company.com/webhook',
                json={
                    'service': self.service_name,
                    'message': message,
                    'severity': severity,
                    'timestamp': datetime.now().isoformat()
                },
                timeout=5
            )
        except Exception as e:
            print(f"Fehler beim Senden der Warnung: {e}")
    
    def monitor(self):
        """Hauptüberwachungsschleife"""
        if self.check_health():
            print(f"{datetime.now()}: {self.service_name} ist fehlerfrei")
            return 0
        
        print(f"{datetime.now()}: {self.service_name} ist nicht fehlerfrei")
        self.send_alert(f"{self.service_name} ist ausgefallen", severity='warning')
        
        # Neustart versuchen
        for attempt in range(1, self.max_retries + 1):
            print(f"Neustartversuch {attempt}/{self.max_retries}")
            
            if self.restart_service() and self.check_health():
                print(f"{datetime.now()}: Dienst wiederhergestellt")
                self.send_alert(
                    f"{self.service_name} automatisch nach dem Neustart wiederhergestellt",
                    severity='info'
                )
                return 0
            
            time.sleep(5)
        
        # Alle Wiederholungsversuche fehlgeschlagen
        print(f"{datetime.now()}: Fehler beim Wiederherstellen des Dienstes")
        self.send_alert(
            f"{self.service_name} konnte nach {self.max_retries} Versuchen nicht wiederhergestellt werden",
            severity='critical'
        )
        return 1

if __name__ == '__main__':
    monitor = ServiceMonitor(
        service_name='myapp',
        health_url='http://localhost:8080/health'
    )
    sys.exit(monitor.monitor())

Seltenheit: Häufig Schwierigkeit: Mittel


Zuverlässigkeitspraktiken

9. Was ist ein Runbook und warum ist es wichtig?

Antwort: Ein Runbook ist eine dokumentierte Vorgehensweise für die Handhabung operativer Aufgaben und Vorfälle.

Runbook-Struktur:

# Runbook: Hohe API-Latenz

## Symptome
- 95. Perzentil der API-Latenz > 1 Sekunde
- Benutzerbeschwerden über langsame Seitenladevorgänge
- Warnung: "HighAPILatency" wird ausgelöst

## Schweregrad
**Warnung** - Beeinträchtigt die Benutzererfahrung, aber der Dienst ist funktionsfähig

## Untersuchungsschritte

### 1. Aktuelle Metriken überprüfen
```bash
# Latenzverteilung überprüfen
curl -s http://prometheus:9090/api/v1/query?query='histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))'

# Anfragerate überprüfen
curl -s http://prometheus:9090/api/v1/query?query='rate(http_requests_total[5m])'

2. Engpass identifizieren

  • Datenbankabfragezeit überprüfen
  • Externe API-Aufrufe überprüfen
  • Cache-Trefferrate überprüfen
  • Letzte Bereitstellungen überprüfen

3. Abhängigkeiten überprüfen

# Datenbankverbindungen
mysql -e "SHOW PROCESSLIST;"

# Redis-Latenz
redis-cli --latency

# Externe APIs
curl -w "%{time_total}\n" -o /dev/null -s https://external-api.com/health

Maßnahmen zur Entschärfung

Schnelle Korrekturen (< 5 Minuten)

  1. Anwendungsserver hochskalieren
kubectl scale deployment api --replicas=10
  1. Cache-TTL vorübergehend erhöhen
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Wenn das Problem weiterhin besteht

  1. Letzte Bereitstellung zurücksetzen
kubectl rollout undo deployment/api
  1. Ratenbegrenzung aktivieren
kubectl apply -f rate-limit-config.yaml

Behebung

  • Ursache beheben (langsame Abfrage, ineffizienter Code)
  • Korrektur bereitstellen
  • 30 Minuten lang überwachen
  • Zurückskalieren auf normale Kapazität

Eskalation

Wenn die Behebung nicht innerhalb von 30 Minuten möglich ist:

  • Eskalieren an: @backend-team
  • Slack-Kanal: #incidents
  • Bereitschaftsdienst: PagerDuty-Eskalationsrichtlinie verwenden

Verwandte Themen


**Warum Runbooks wichtig sind:**
- Schnellere Reaktion auf Vorfälle
- Konsistente Verfahren
- Wissensaustausch
- Reduzierter Stress bei Vorfällen
- Schulungstool für neue Teammitglieder

**Seltenheit:** Häufig
**Schwierigkeit:** Leicht

---

### 10. Erkläre das Konzept der Graceful Degradation.

**Antwort:**
**Graceful Degradation** bedeutet, dass ein System bei Ausfall von Komponenten mit reduzierter Kapazität weiterarbeitet, anstatt vollständig auszufallen.

**Strategien:**

**1. Feature Flags:**
```python
# Deaktivieren nicht kritischer Funktionen bei hoher Last
class FeatureFlags:
    def __init__(self):
        self.flags = {
            'recommendations': True,
            'analytics': True,
            'search_autocomplete': True
        }
    
    def is_enabled(self, feature):
        # Deaktivieren nicht kritischer Funktionen, wenn das Fehlerbudget niedrig ist
        if self.error_budget_low():
            non_critical = ['analytics', 'search_autocomplete']
            if feature in non_critical:
                return False
        return self.flags.get(feature, False)
    
    def error_budget_low(self):
        # Überprüfen, ob das Fehlerbudget < 20 % ist
        return get_error_budget() < 0.2

# Verwendung
flags = FeatureFlags()
if flags.is_enabled('recommendations'):
    show_recommendations()
else:
    # Graceful Degradation - statischen Inhalt anzeigen
    show_popular_items()

2. Circuit Breaker:

from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"  # Normaler Betrieb
    OPEN = "open"      # Fehlerhaft, Anfragen ablehnen
    HALF_OPEN = "half_open"  # Wiederherstellung testen

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.failures = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
            else:
                # Fallback zurückgeben, anstatt den fehlerhaften Dienst aufzurufen
                return self.fallback()
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            return self.fallback()
    
    def on_success(self):
        self.failures = 0
        self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN
    
    def fallback(self):
        # Zwischengespeicherte Daten oder Standardantwort zurückgeben
        return {"status": "degraded", "data": []}

# Verwendung
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

3. Timeouts und Wiederholungen:

import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry

def create_resilient_session():
    session = requests.Session()
    
    # Wiederholungsstrategie
    retry = Retry(
        total=3,
        backoff_factor=0.3,
        status_forcelist=[500, 502, 503, 504]
    )
    
    adapter = HTTPAdapter(max_retries=retry)
    session.mount('http://', adapter)
    session.mount('https://', adapter)
    
    return session

# Verwendung mit Timeout
session = create_resilient_session()
try:
    response = session.get('https://api.example.com/data', timeout=5)
except requests.exceptions.Timeout:
    # Graceful Degradation - zwischengespeicherte Daten verwenden
    response = get_cached_data()

Seltenheit: Häufig Schwierigkeit: Mittel


Containerisierungsgrundlagen

11. Was ist Docker und wie unterscheidet es sich von virtuellen Maschinen?

Antwort: Docker ist eine Containerisierungsplattform, die Anwendungen mit ihren Abhängigkeiten verpackt.

Container vs. Virtuelle Maschinen:

Loading diagram...

Hauptunterschiede:

FunktionContainerVirtuelle Maschinen
StartzeitSekundenMinuten
GrößeMBsGBs
RessourcenauslastungLeichtgewichtigSchwer
IsolationProzessebeneHardwareebene
BSTeilt sich das Host-BSSeparates BS pro VM

Docker-Grundlagen:

# Image pullen
docker pull nginx:latest

# Container ausführen
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  nginx:latest

# Ausgeführte Container auflisten
docker ps

# Protokolle anzeigen
docker logs my-nginx

# Befehl im Container ausführen
docker exec -it my-nginx bash

# Container stoppen
docker stop my-nginx

# Container entfernen
docker rm my-nginx

Dockerfile-Beispiel:

# Basis-Image
FROM python:3.9-slim

# Arbeitsverzeichnis festlegen
WORKDIR /app

# Anforderungen kopieren
COPY requirements.txt .

# Abhängigkeiten installieren
RUN pip install --no-cache-dir -r requirements.txt

# Anwendungscode kopieren
COPY . .

# Port freigeben
EXPOSE 8000

# Zustandsprüfung
HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8000/health || exit 1

# Anwendung ausführen
CMD ["python", "app.py"]

Erstellen und Ausführen:

# Image erstellen
docker build -t myapp:1.0 .

# Mit Umgebungsvariablen ausführen
docker run -d \
  --name myapp \
  -p 8000:8000 \
  -e DATABASE_URL=postgres://db:5432/mydb \
  -e LOG_LEVEL=info \
  myapp:1.0

# Ressourcenauslastung anzeigen
docker stats myapp

Docker Compose (Multi-Container):

version: '3.8'

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://db:5432/mydb
    depends_on:
      - db
      - redis
    restart: unless-stopped
  
  db:
    image: postgres:14
    environment:
      - POSTGRES_DB=mydb
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data
  
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  postgres_data:

Mit Docker Compose ausführen:

# Alle Dienste starten
docker-compose up -d

# Protokolle anzeigen
docker-compose logs -f web

# Dienst skalieren
docker-compose up -d --scale web=3

# Alle Dienste stoppen
docker-compose down

Best Practices:

  • Offizielle Basis-Images verwenden
  • Anzahl der Ebenen minimieren
  • Nicht als Root ausführen
  • .dockerignore verwenden
  • Images ordnungsgemäß taggen
  • Auf Schwachstellen scannen

Seltenheit: Sehr häufig Schwierigkeit: Leicht-Mittel


Versionskontrolle und Bereitstellung

12. Erkläre Git-Workflows und wie du Bereitstellungen handhabst.

Antwort: Git ist unerlässlich für die Versionskontrolle und die Automatisierung der Bereitstellung.

Häufiger Git-Workflow:

Loading diagram...

Grundlegende Git-Befehle:

# Repository klonen
git clone https://github.com/company/repo.git
cd repo

# Feature-Branch erstellen
git checkout -b feature/add-monitoring

# Änderungen vornehmen und committen
git add .
git commit -m "Prometheus-Überwachung hinzufügen"

# Per Push in den Remote-Branch übertragen
git push origin feature/add-monitoring

# Von Main aktualisieren
git checkout main
git pull origin main
git checkout feature/add-monitoring
git rebase main

# Feature mergen (nach PR-Genehmigung)
git checkout main
git merge feature/add-monitoring
git push origin main

Branching-Strategie:

1. Gitflow:

  • main: Produktionsreifer Code
  • develop: Integrations-Branch
  • feature/*: Neue Funktionen
  • release/*: Vorbereitung der Version
  • hotfix/*: Notfallbehebungen

2. Trunk-Based Development:

# Kurzlebige Feature-Branches
git checkout -b feature/quick-fix
# Weniger als 1 Tag arbeiten
git push origin feature/quick-fix
# Sofort nach der Überprüfung in Main mergen

Bereitstellungs-Workflow:

1. CI/CD-Pipeline (GitHub Actions):

name: In Produktion bereitstellen

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Tests ausführen
        run: |
          npm install
          npm test
      
      - name: Linting ausführen
        run: npm run lint
  
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Docker-Image erstellen
        run: |
          docker build -t myapp:${{ github.sha }} .
          docker tag myapp:${{ github.sha }} myapp:latest
      
      - name: In die Registry pushen
        run: |
          echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
          docker push myapp:${{ github.sha }}
          docker push myapp:latest
  
  deploy:
    needs: build
    runs
Newsletter subscription

Wöchentliche Karrieretipps, die wirklich funktionieren

Erhalten Sie die neuesten Einblicke direkt in Ihr Postfach

Erstellen Sie einen Lebenslauf, der Sie 60% schneller einstellt

Erstellen Sie in wenigen Minuten einen maßgeschneiderten, ATS-freundlichen Lebenslauf, der nachweislich 6-mal mehr Vorstellungsgespräche vermittelt.

Einen besseren Lebenslauf erstellen

Diesen Beitrag teilen

Nutzen Sie Ihre 6 Sekunden Optimal

Recruiter scannen Lebensläufe durchschnittlich nur 6 bis 7 Sekunden. Unsere bewährten Vorlagen sind darauf ausgelegt, sofort Aufmerksamkeit zu erregen und sie weiterlesen zu lassen.