16 OpenShift Sandbox und Playground-Umgebungen

OpenShift Sandbox und Playground-Umgebungen stellen cloudbasierte, vorkonfigurierte OpenShift-Instanzen bereit, die ohne lokale Installation oder Infrastruktur-Setup genutzt werden können. Diese Lösungen ermöglichen es Entwicklern, Systemadministratoren und IT-Entscheidern, OpenShift-Funktionalitäten zu erkunden und zu evaluieren, ohne eigene Ressourcen bereitzustellen.

16.1 Konzept und Architektur

Sandbox-Umgebungen basieren auf dem Prinzip der temporären, isolierten OpenShift-Instanzen, die über Web-Browser zugänglich sind. Diese Umgebungen werden dynamisch provisioniert und nach einem definierten Zeitraum automatisch wieder freigegeben. Die zugrunde liegende Infrastruktur wird vollständig von Red Hat verwaltet und in Public-Cloud-Umgebungen betrieben.

Die technische Realisierung erfolgt über Containerisierung der OpenShift-Instanzen selbst, wodurch eine effiziente Ressourcennutzung und schnelle Provisionierung erreicht wird. Multi-Tenancy wird durch Namespace-Isolation und Resource-Quotas implementiert, wobei Benutzer dedizierte Projekte mit begrenzten CPU-, Speicher- und Storage-Kontingenten erhalten.

16.1.1 Verfügbare Sandbox-Optionen

16.2 Red Hat Developer Sandbox

Die Red Hat Developer Sandbox stellt eine kostenlose, webbasierte OpenShift-Umgebung bereit, die für 30 Tage pro Anmeldung verfügbar ist. Die Architektur basiert auf shared Multi-Node-OpenShift-Clustern, die in Red Hats Cloud-Infrastruktur betrieben werden.

16.2.1 Zugang und Registrierung

Voraussetzungen: - Kostenloser Red Hat Developer Account - Web-Browser mit JavaScript-Unterstützung - Keine Kreditkarte oder Zahlungsinformationen erforderlich

Registrierungsprozess: 1. Account-Erstellung auf developers.redhat.com 2. E-Mail-Verifizierung 3. Automatische Sandbox-Provisionierung 4. Zugang über console.redhat.com/openshift/sandbox

16.2.2 Ressourcen und Limitierungen

Die Sandbox bietet begrenzte, aber für Entwicklung und Evaluation ausreichende Ressourcen:

Resource-Quotas: - CPU-Limit: 2000m (2 CPU-Kerne) - Memory-Limit: 7 GB RAM - Storage: 15 GB persistenter Speicher - Pods: Maximum 60 gleichzeitige Pods - Services: Maximum 30 Services

Zeit-Limitierungen: - Session-Timeout: 12 Stunden Inaktivität - Sandbox-Lebensdauer: 30 Tage nach Aktivierung - Renewal: Nach Ablauf erneute Registrierung möglich

16.2.3 Verfügbare Features

Die Developer Sandbox umfasst nahezu alle Standard-OpenShift-Features:

# CLI-Zugang über Web Terminal oder lokale Installation
oc login --token=<token> --server=https://api.sandbox.x8i5.p1.openshiftapps.com:6443

# Verfügbare Projekte anzeigen
oc projects

# Neue Anwendung aus Git-Repository deployen
oc new-app https://github.com/openshift/nodejs-ex.git

Integrierte Services: - Web-basierte Developer Console - Integrierte Container Registry - Source-to-Image (S2I) Builds - Pipeline-as-Code mit Tekton - Service Mesh (Istio) in begrenztem Umfang - Monitoring mit Prometheus

16.3 Playground- und Learning-Umgebungen

Playground-Umgebungen erweitern das Sandbox-Konzept um strukturierte Lernpfade und geführte Tutorials. Diese Plattformen kombinieren OpenShift-Instanzen mit didaktischem Content und interaktiven Übungen.

16.3.1 Interactive Learning Platform

Red Hat Interactive Learning bietet kuratierte Lernpfade mit verschiedenen Schwierigkeitsgraden:

Verfügbare Kurse: - OpenShift Fundamentals - Container Development - DevOps Pipeline-Entwicklung - Service Mesh mit Istio - Operator-Entwicklung

Learning-Environment-Features: - Browser-basiertes Terminal - Integrierte Code-Editoren - Schritt-für-Schritt-Anleitungen - Automatische Umgebungs-Resets zwischen Lektionen

16.3.2 Hands-on Labs

# Typischer Lab-Workflow
# 1. Neue Anwendung erstellen
oc new-project my-lab-project

# 2. Application aus Sample-Code deployen  
oc new-app --name=sample-app https://github.com/redhat-developer/s2i-dotnetcore-ex

# 3. Service extern zugänglich machen
oc expose service sample-app

# 4. Deployment-Status überwachen
oc status

16.4 Technische Implementierung

Sandbox-Umgebungen nutzen fortschrittliche Container-Orchestrierung, um Hunderte von isolierten OpenShift-Instanzen auf shared Hardware zu betreiben. Kubernetes-basierte Meta-Orchestrierung verwaltet die Sandbox-Instanzen selbst als Workloads.

16.4.1 Resource Management

Resource-Quotas werden auf mehreren Ebenen implementiert, um stabile Performance bei hoher Nutzeranzahl zu gewährleisten:

Multi-Level Resource Control:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: sandbox-quota
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 7Gi
    requests.storage: 15Gi
    pods: "60"
    services: "30"

Automatische Bereinigung: - Inaktive Pods werden nach 12 Stunden gestoppt - Temporäre Dateien werden regelmäßig gelöscht - Resource-Limits werden kontinuierlich überwacht

16.4.2 Storage und Persistierung

Storage-Management erfolgt über ephemere Volumes, die automatisch mit der Sandbox-Instanz erstellt und gelöscht werden:

Storage-Klassen: - Ephemeral Storage: Für temporäre Container-Daten - Persistent Volumes: Für Anwendungsdaten (begrenzt auf 15 GB) - Git Integration: Für Code-Persistierung über Sessions hinweg

16.5 Sicherheit und Isolation

Sandbox-Umgebungen implementieren umfassende Sicherheitsmaßnahmen, um sowohl die Plattform als auch die Nutzer zu schützen.

16.5.1 Security Context Constraints

Standard-SCCs in Sandbox-Umgebungen sind restriktiv konfiguriert:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: sandbox-restricted
allowHostDirVolumePlugin: false
allowPrivilegedContainer: false
runAsUser:
  type: MustRunAsRange
  uidRangeMin: 1000000000
  uidRangeMax: 2000000000

16.5.2 Netzwerk-Isolation

Network Policies isolieren Sandbox-Instanzen auf Netzwerkebene:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sandbox-isolation
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  egress:
  - to: []
    ports:
    - protocol: TCP
      port: 80
    - protocol: TCP  
      port: 443

16.5.3 Audit und Compliance

Audit-Logging erfasst alle API-Operationen: - Benutzer-Authentifizierung und -Autorisierung - Resource-Erstellung und -Modifikation - Netzwerk-Traffic-Patterns - Sicherheitsverstöße und verdächtige Aktivitäten

16.6 Integration in Entwicklungsworkflows

Sandbox-Umgebungen unterstützen moderne Entwicklungspraktiken durch umfassende Tool-Integration.

16.6.1 Git-Integration

# Direktes Deployment aus Git-Repository
oc new-app https://github.com/username/my-nodejs-app

# Webhook für automatische Updates konfigurieren
oc set triggers dc/my-nodejs-app --from-github

# Source-to-Image Build mit Custom Builder
oc new-app nodejs~https://github.com/username/my-app --name=custom-build

16.6.2 CI/CD-Pipeline-Integration

Tekton Pipelines in Sandbox-Umgebungen:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: sandbox-pipeline
spec:
  tasks:
  - name: git-clone
    taskRef:
      name: git-clone
  - name: build-image
    taskRef:
      name: s2i-nodejs
    runAfter: ["git-clone"]
  - name: deploy-app
    taskRef:
      name: openshift-client
    runAfter: ["build-image"]

16.6.3 IDE-Integration

Unterstützte Development-Tools: - Visual Studio Code: OpenShift Connector Extension - IntelliJ IDEA: Kubernetes Plugin mit OpenShift-Support - Web-Terminal: Browser-basierte CLI mit vorinstallierter oc - CodeReady Workspaces: Cloud-basierte IDE-Umgebung

16.7 Limitierungen verstehen

Sandbox-Umgebungen weisen systembedingte Limitierungen auf, die ihre Nutzung auf bestimmte Szenarien beschränken.

16.7.1 Technische Einschränkungen

16.7.2 Nicht verfügbare Features

Cluster-Administrator-Features: - Node-Level-Konfigurationen - Custom Operators Installation (cluster-wide) - System-Service-Modifikationen - Storage-Class-Management - Cluster-weite Security Policies

Advanced Networking: - Custom CNI-Konfigurationen - LoadBalancer-Services (nur NodePort/ClusterIP) - Erweiterte Ingress-Konfigurationen - VPN-Integrationen

16.8 Einsatzszenarien und Best Practices

Sandbox-Umgebungen eignen sich für spezifische Anwendungsfälle, bei denen die Limitierungen akzeptabel sind.

16.8.1 Ideale Anwendungsgebiete

Evaluation und Proof-of-Concept:

# Schnelle Machbarkeitsstudie
oc new-project poc-microservices
oc new-app --name=api-service nodejs~https://github.com/company/api-service
oc new-app --name=frontend react~https://github.com/company/frontend

Learning und Skill Development: - OpenShift-Grundlagen erlernen - Container-Deployment-Patterns üben - CI/CD-Pipeline-Entwicklung - Kubernetes-API-Verständnis entwickeln

Prototyping und Experimentierung: - Neue Framework-Evaluierung - Architecture-Pattern-Tests - Integration-Testing mit externen APIs - Performance-Charakteristik-Analyse (im Rahmen der Limits)

16.8.2 Best Practices für Sandbox-Nutzung

Effiziente Ressourcennutzung:

# Resource-Limits für Container setzen
oc set resources deployment/my-app --requests=cpu=100m,memory=128Mi --limits=cpu=500m,memory=512Mi

# Nicht benötigte Ressourcen regelmäßig löschen
oc delete all --selector app=old-prototype

# Efficient Container-Images verwenden
oc new-app --name=minimal-app registry.access.redhat.com/ubi8/ubi-minimal~https://github.com/app-repo

Daten-Persistierung: - Wichtiger Code in Git-Repositories speichern - Konfigurationen als YAML-Files exportieren - Secrets und ConfigMaps dokumentieren - Pipeline-Definitionen versionieren

Session-Management: - Aktive Sessions regelmäßig überprüfen - Wichtige Arbeiten vor Session-Timeout sichern - Mehrere Browser-Tabs für paralleles Arbeiten nutzen - Web-Terminal für CLI-intensive Aufgaben bevorzugen

Sandbox-Umgebungen bieten einen niedrigschwelligen Einstieg in OpenShift und ermöglichen praktische Erfahrungen ohne Infrastruktur-Investment. Die Limitierungen erfordern jedoch realistische Erwartungen und angepasste Arbeitsweisen.