Ein Helm-Chart Repository besteht lediglich aus den per tar archivierten und mit gzip komprimierten Charts, einer sogenannten Provenienz-Datei pro Chart und einer index.yaml. Die Struktur eines Helm-Chart Repositories sieht üblicherweise wie folgt aus: /path/to/chart/folder/ | |- index.yaml | |- chart-a-1.0.0.tgz | |- chart-a-1.0.0.tgz.prov | |- chart-b-1.0.0.tgz | |- chart-b-1.0.0.tgz.prov Die Provenienz-Dateien werden während der Archivierung eines Charts erzeugt. Mehr Detailinformationen zur Provienenz und Integrität von Helm-Charts gibt es unter https://helm.sh/docs/topics/provenance/.

Transport-Layer Verschlüsselung per Secure Sockets Layer (SSL) bzw. Transport Layer Security (TLS) ist ‘state of the art’. Kaum eine Webseite kommt mehr ohne Verschlüsselung auf Transportprotokoll-Ebene aus. Zum Glück ist es seit es Let’s Encrypt gibt, kaum mehr ein Problem, an ein gültiges TLS-Zertifikat zu kommen, dass von einer Zertifizierungstelle signiert wurde, die die meisten Browser und Betriebssysteme als vertrauenwürdig einstufen. Mit cert-manager gibt es eine komfortable Lösung zur Verwaltung von SSL-Zertifikaten im Kubernetes-Cluster.

Wir sind inzwischen in der Lage, Webanwendungen in unser Kubernetes zu deployen, und können per kubectl port-forward von unserem lokale Rechner auf die Anwendungen zugreifen. Im letzten Blogpost GitOps haben wir einen Ingresscontroller per GitOps installiert und können nun per Ingress, Services aus dem Internet erreichbar machen. Dieser Blogpost erläutert einige Hintergründe zum Setup. In einer klassischen IT-Architektur übernimmt häufig ein sogenannter Reverse-Proxy diese Aufgabe. Er leitet auf verschiedenen Webseiten direkt auf dem Webserver oder auch auf andere Server hinter der Firewall weiter.

Configuration as Code (CasC) ist weit verbreitet. Dabei wird CasC auf verschiedenen Ebenen eingesetzt. Beispiele sind Puppet und Ansible auf Softwareebene, aber auch Infrastructure as Code (IaC) ist inzwischen bereits State-of-the-Art oder zumindest auf dem Weg dorthin. Bei CasC wird der Soll-Zustand eines Software-Systems in Code beschrieben und in einem Repository abgelegt. Das jeweilige Tool gleicht dann den Ist-Zustand und den Soll-Zusstand ab und versucht, den Sollzustand herzustellen. GitOps setzt dieses Prinzip auf Clusterebene um.