IONOS SE as part of United Internet Group has the approach to anchoring their own services provided by IONOS more deeply in the company. One aspect of that approach is the usage of their own Cloud provider “IONOS Cloud”. YOTRON supports the BI/BigDate-department in the usage of the Cloud for their services. YOTRON supports the advent of DevOps, Cloud and Kubernetes Goal of the usage of Kubernetes and IONOS Cloud is the seamless integration into the IONOS network.

YOTRON launched a new free to use service KubeAuth.io for Kubernetes which allows the authentication of your customer without the need of coding, only per configuration. Goal of KubeAuth.io Almost all application running in Kubernetes needs a mechanism to authenticate users which are using the application. The form for authentication which is mostly used based on OAuth 2.0 and OpenID Connect which are known for using tokens instead of simple Name and Password when a users want to authenticate themselves.

Setup S3-Bucket Create a local Helm Repo Package all of your Helm projects locally Indexing of the Helm repository locally Deploy the Helm packages Add your Repo (This table of content was done with Markdownmenu) I want to show how you can use an ordinary S3-Bucket of AWS as a qualified Helm Repository. This is a cheap alternative and is completely serverless. This Helm Repo is not a fully functional Helm Repository like the Chartmuseum.

Mit dem Projekt Access 4.0 der Deutschen Telekom AG (DTAG) wird ein neuer Weg beschritten um den Zugang der Kunden der DTAG zu deren Gigabit-Produkte wie Telefon, Internet oder MagentaTV zu ermöglichen. Statt wie bisher auf monolithische Systeme zu setzen wird die Zugangsplattform mit normalen Standardkomponenten wie Switches und Server sowie einem breiten Softwareeinsatz ermöglicht das ausschließlich auf OpenSource-Produkte setzt. Automation und hochmoderner Softwareeinsatz Ziel des Projektes ist es mehrere hundert Standorte automatisiert mit aller relevanten Software und fachlichen Informationen zu bestücken und auch den Aktualisierungsprozess über moderne CI/CD Prozesse zu steuern ohne manuell eingreifen zu müssen (“Zero-Touch-Provisioning”).

Soll die Azure eigene Docker registry (Service Container registry) genutzt werden, macht es wenig Sinn für jede Umgebung (dev, test, prod), jedes Team oder nach Applikationen/Systeme getrennt diese zu betreiben. Hierbei handelt es sich um ein Shared Service innerhalb eines Unternehmens, dass sich mehrere Teams teilen können. Inhalt Container registry als Shared Service Docker Registry Erzeugen einer neuen Container registry Authentifizierung an der Container registry Aktivierung des admin-Nutzers Testlogin in die Container registry