Der Blog ist aufgeteilt in drei Themen:

1. Installations-Pitfalls: In der /mid Week haben wir OpenShift 4.2 sowohl auf einem VMware vSphere Cluster wie auch bei AWS, GCP und Azure installiert. Wir berichten über die Probleme, die dabei aufgetaucht sind.

2. Networking: Je nach Cloud Plattform gibt es logischerweise Unterschiede (z.B. Load Balancer). Wir haben aber auch Unterschiede zwischen OpenShift 3.11 und 4.2 festgestellt.

3. Storage: Jeder Cloud Provider bietet diverse Typen von Storage zur Integration in OpenShift an. Wir zeigen euch, was es für Möglichkeiten gibt.

Wenn du in diesem Blog nach einer Anleitung suchst, wie OpenShift 4.2 installiert wird, bist du leider falsch. Für die Installationen haben auch wir die offiziellen Anleitungen von RedHat verwendet.

Vorneweg: Die Installation wird mit OpenShift Version 4.2 deutlich einfacher und schneller als mit 3.11. Generell - egal für welche Zielplattform - haben wir Folgendes festgestellt:

Die Installation eines Clusters dauert je nach Plattform unterschiedlich lang:

VMware vSphere

Einige Bemerkungen zur VMware vSphere Installation:

GCP

Damit die Installation auf GCP funktioniert, müssen die folgenden APIs aktiviert sein:

Weiter muss die Disksize Limit von 500GB auf 750 GB erhöht werden (640GB benutzt nach der Installation). Das Definieren im install-config.yaml File des OpenShift Installer funktioniert leider nicht:

platform:
   gcp:
      rootVolume:
      iops: 4000
      size: 50
      type: io1
   type: n1-standard-4

Azure

Einige Bemerkungen zur Installation auf Azure:

AWS

Die Installation auf AWS war am einfachsten. Das liegt wohl daran, dass bereits Openshift 4.0 darauf ausgelegt war.

Load Balancing

Für eine RedHat OpenShift 4.2 Installation werden zwei Load Balancer vor dem Cluster benötigt:

Auf den drei Cloud Provider konnten wir dafür jeweils den Load Balancer Service des Providers verwenden. Dieser wird mit dem OpenShift Installer automatisch konfiguriert. Auf VMware vSphere mussten wir dafür selber einen Load Balancer konfigurieren. Wir haben dafür eine CentOS VM mit HAProxy verwendet. Für die hohe Verfügbarkeit kann z.B. keepalived verwendet werden.

Für den Client Access Load Balancer kann auf die Cloud Provider Integration von Kubernetes zurückgegriffen werden. Damit werden mit Hilfe eines Kubernetes Services vom Typ Load Balancer automatisch ein Load Balancer auf der entsprechenden Cloud Plattform provisioniert.

Bei der on-premise Installation mit VMware vSphere muss der Load Balancer selber implementiert werden, welcher den Netzwork Traffic auf die Ingress Controller weiterleitet. Das automatische Erstellen des Load Balancers via Kubernetes Service funktioniert hier leider nicht.

Egress Traffic & NetworkPolicy

Abschliessend schauen wir uns noch die diversen Storage Integrationen für OpenShift 4.2 an. Wir teilen Storage in drei Kategorien ein: Block Storage, File Storage und Object Storage.

Black Storage

Erfreulicherweise hatten wir mit keinem Provider (onpremise wie auch Cloud) Probleme. Nach der Installation gemäss Anleitung konnten wir Block Storage von allen Cloud Providern beziehen. Alle Infos dazu sind in der entsprechenden Dokumentation von RedHat zu finden.

File Storage

Als File Storage bezeichnen wir solchen, der insbesondere shared bezogen werden kann (ReadWriteMany - RWX).

AWS

Auf AWS steht uns EWS zur Verfügung, dabei haben wir jedoch Folgendes festgestellt:

Weiter kann auch Netapp Trident verwendet werden. In unserer /mid Week haben wir dies jedoch nicht angeschaut (auch nicht auf den anderen Cloud Provider Plattformen). Dafür wird ein AWS Account mit konfiguriertem NetApp CVS (1TB / 100$ / Monat) benötigt. Infos dazu in der Netapp Trident Dokumentation.

Azure

Microsoft bietet mit Azure File die Möglichkeit, dynamisch File Storage zu beziehen. Die folgenden Features werden dabei aber nicht supported.

Alle Informationen dazu sind in der RedHat OpenShift Dokumentation zu finden. Auch auf Azure kann Netapp Trident verwendet werden.

GCP

Auf GCP stehen mehrere Möglichkeiten zur Verfügung.

Für Cloud File Store kann der nfs-client-provisioner verwendet weren. Auch hier können Quotas nicht forciert werden. Weiter gibt es einen nicht offiziell supporteten CSI Treiber, den wir aber nicht wirklich zum Laufen gebracht haben.

Weiter kann auch hier NetApp Cloud Volumes mit Trident verwendet werden. Wir haben hierzu aber keine Dokumentation gefunden. Dies sollte aber ähnlich wie bei AWS seine. Weitere Infos dazu sind hier zu finden.

Eine weitere Möglichkeit ist die Verwendung von Elastifile oder Quoabyte. Diese müssen aber alle lizenziert werden. Elastifile ist nur für einen eingeschränkten Kundenkreis verfügbar. Quoabyte sieht zur Zeit noch nicht wirklich Enterprise-like aus.

VMware vSphere

In einer on-premise VMware vSphere Umgebung muss einen File Storage Service selbst aufgebaut werden (z.B. mit RedHat Contrainer Storage basierend auf rook.io).

Object Storage

Auch Object Storage wird von den drei Cloud Provider angeboten. Dieser wird aber in der Regeln nicht als PV in einen Pod gemounted, sondern direkt aus einer Applikation bezogen. Der Vollständigkeit halber hier eine Auflistung der Object Storage Services.

In einer on-premise VMware vSphere Umgebung muss ein Object Storage Service selbst aufgebaut werden.

Create a Quarkus Project

The easiest starting point to create a Quarkus project is the website https://code.quarkus.io. The same concept is already known from Spring Boot https://start.spring.io. This makes it easy to create a project with the needed libraries.

For this example choose the extensions RESTEasy JAX-RS and SmallRye Health. RESTEasy JAX-RS, which is included as default, is used for REST web services and SmallRye Health is an extension that helps to integrate health checks.

Start the Application

To start Quarkus locally you just need to have Java 8 installed. With the command ./mvnw compile quarkus:dev you can start the application in development mode. Changes in the Java code are applied directly in the running application via hot deployment. Thus, a time-consuming application restart is not necessary 😃.

Create a REST Web Service

As an example application, we develop a REST web service that calculates a specific number in the Fibonacci sequence. The sequence is named after Leonardo Fibonacci, who described the growth of a rabbit population in 1202. The Fibonacci sequence can be calculated recursively as well as iteratively. To push the CPU a little bit, I use the recursive variant.

package nxt;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/fibonacci")
public class FibonacciResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    @Path("{number}")
    public int fibonacci(@PathParam("number") Integer number) {
        if (number == 0) {
                return 0;
        }
        if (number == 1) {
                return 1;
        }
        return fibonacci(number - 2) + fibonacci(number - 1);
    }
}

The application can be tested with curl as follows:

curl http://0.0.0.0:8080/fibonacci/10

Test a REST Web Service

Quarkus uses the well-known library REST-assured for REST web service tests. The web service created earlier can be tested with the following code:

package nxt;

import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Test;

import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.is;

@QuarkusTest
public class FibonacciResourceTest {

    @Test
    public void testEndpoint() {
       testFibonacci(0, 0);
       testFibonacci(1, 1);
       testFibonacci(2, 1);
       testFibonacci(3, 2);
       testFibonacci(4, 3);
       testFibonacci(5, 5);
       testFibonacci(6, 8);
    }
    private void testFibonacci(int number, int fibonacci) {
       given()
          .when().get("/fibonacci/"+ number)
          .then()
            .statusCode(200)
            .body(is(String.valueOf(fibonacci)));
    }
}

The test can be executed with the command ./mvnw test.

Build Application on APPUiO

For the application to run on APPUiO, a Swiss OpenShift platform, it must first be built. The Quarkus team provides an OpenShift Source-to-Image (S2I) build.

With the following command you can create a new build on OpenShift and start it automatically:

oc new-build quay.io/quarkus/ubi-quarkus-native-s2i:19.2.1~https://gitlab.com/nxt/public/quarkus-fibonacci.git \
  --name=quarkus-fibonacci-build

The GraalVM, which creates a native image from the Java code, needs a lot of computing power. In order for the build on APPUiO to acquire the needed resources, it has to be configured appropriately.

oc patch bc/quarkus-fibonacci-build \
  -p '{"spec":{"resources":{"requests":{"cpu":"0.5", "memory":"2Gi"},"limits":{"cpu":"4", "memory":"4Gi"}}}}'

The above command sets the build job limit to 4 CPUs and 4 gigabytes of RAM.

The great thing about APPUiO is that the resources needed for the build are not pulled from the project’s own resources. So you can push your own project to the limit and still run builds on OpenShift 😎.

The disadvantage of this approach is that the resulting docker image has a size of 600 MB 🤔. This is because the docker image contains the entire GraalVM. A Docker multistage build can solve this problem nicely.

The following docker file contains a multistage build where the native image is built first with GraalVM and after that a minimal docker image based on ubi-minimal is built.

## Stage 1 : build with maven builder image with native capabilities
FROM quay.io/quarkus/centos-quarkus-maven:19.2.1
COPY src /usr/src/app/src
COPY pom.xml /usr/src/app
USER root
RUN chown -R 1001 /usr/src/app
USER 1001
RUN mvn -f /usr/src/app/pom.xml package -Pnative -e -B -DskipTests -Dmaven.javadoc.skip=true -Dmaven.site.skip=true -Dmaven.source.skip=true -Djacoco.skip=true -Dcheckstyle.skip=true -Dfindbugs.skip=true -Dpmd.skip=true -Dfabric8.skip=true -Dquarkus.native.enable-server=true

## Stage 2 : create the docker final image
FROM registry.access.redhat.com/ubi8/ubi-minimal
WORKDIR /work/
COPY --from=0 /usr/src/app/target/*-runner /work/application
RUN chmod 775 /work
EXPOSE 8080
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]

On OpenShift, you can run multistage docker builds. The first of the following two commands creates the image stream for the new lean docker image and the second one creates the docker build.

oc create is quarkus-fibonacci
oc create -f - | << EOF
{
    "apiVersion": "build.openshift.io/v1",
    "kind": "BuildConfig",
    "metadata": {
        "labels": {
             "build": "quarkus-fibonacci-build"
        },
        "name": "quarkus-fibonacci-build"
    },
    "spec": {
        "output": {
            "to": {
                "kind": "ImageStreamTag",
                "name": "quarkus-fibonacci:latest"
            }
        },
        "resources": {
            "limits": {
                 "cpu": "4",
                 "memory": "4Gi"
             },
             "requests": {
                 "cpu": "500m",
                 "memory": "2Gi"
             }
        },
        "source": {
             "git": {
                 "uri": "https://gitlab.com/nxt/public/quarkus-fibonacci.git"
             },
             "type": "Git"
        },
        "strategy": {
             "type": "Docker"
        }
    }
}
EOF

Publish Application to APPUiO

The previously built application can be published on APPUiO with the following two commands:

oc new-app --image-stream=quarkus-fibonacci:latest
oc expose svc quarkus-fibonacci

The first command creates a deployment with a Pod and a corresponding service. The second command creates a route for the given service that makes the microservice available to the public.

The command below allows you to test the newly deployed application:

curl http://$(oc get route | grep quarkus-fibonacci | awk '{print $2}')/fibonacci/1

Set up Health Checks

Quarkus has an extension that offers health checks out of the box. If the extension has not yet been added to the project, it can be added with the command ./mvnw quarkus:add-extension -Dextensions="health". Quarkus will then automatically create health check endpoints that can be called via the URL /health/live and /health/ready.

In OpenShift the health checks can be added with the following command:

oc set probe dc/quarkus-fibonacci --liveness --get-url=http://:8080/health/live --initial-delay-seconds=1
oc set probe dc/quarkus-fibonacci --readiness --get-url=http://:8080/health/ready --initial-delay-seconds=1

Autoscaling

Quarkus applications can be started extremely quickly. This feature is especially useful when using the autoscaling feature. This allows you to start and stop pod’s dynamically when needed.

oc autoscale dc/quarkus-fibonacci --min 1 --max 2 --cpu-percent=80

The command above adds autoscaling, which starts a second Pod when needed. As soon as the load decreases again, the additional Pod is automatically shut down again.

Autoscaling can be tested with the ApacheBench tool from Apache.

ab -n 5000 -c2 http://$(oc get route | grep quarkus-fibonacci | awk '{print $2}')/fibonacci/30

This command sends 5000 parallel requests to the microservice. After a few seconds OpenShift will start the second Pod, which will be ready to use immediately.

Conclusion

With Quarkus you can quickly and easily build a microservice with Java, which meets all requirements to be operated efficiently in an OpenShift or Kubernetes.

You can study the complete code on in GitLab repository.

Red Hat und IBM

Die Übernahme von Red Hat durch IBM war neben den Open Source-, DevOps-, Microservices- und Container-Themen ein zentraler Schwerpunkt. Nach Meinungen des Managements wie auch der einzelnen Mitarbeitern, sei IBM eine grosse Chance und ein «Shareholder sowie Partner gleichzeitig». Es sei eine Gelegenheit, die neue Türen öffnet. Von der Beständigkeit Red Hat's wie sie heute ist, sind sie dennoch überzeugt.

APPUiO am Red Hat Forum

APPUiO war mit einem eigenen Stand vor Ort vertreten. Mit dabei natürlich: Ein gelber Container und das APPUiO-Team. Für das Team stand der Austausch mit den Besuchern im Vordergrund. Nicht nur neue Kontakte konnten geknüpft werden, hin und da besuchte ein bekanntes Gesicht den APPUiO-Stand. Spannende Keynotes und Breakout-Sessions liessen den tollen Tag abrunden.

Unser neuestes Gemeinschaftsprojekt. APPUiO on Philips. ;-)

APPUiO beerup

Was wäre ein solch gelungener Tag bereits schon zu Ende? Das dachte sich APPUiO auch. Deshalb lud APPUiO die Besucher zu einem beerup in die Giesserei ein. Der Besucherdrang war noch grösser als beim ersten beerup im Sihlcity – ein richtiger Erfolg. In ungezwungener Atmosphäre wurde ein Bierchen getrunken, über dies und jenes gesprochen und den Tag ausgeklungen.

Aber nur wer in Besitz eines Golden-Tickets war, wurde von der strengen Einlasskontrolle hereingelassen.:-)

Wir freuen uns schon auf das nächste Treffen, bis dahin: Macht's gut!

Euer APPUiO-Team

Entwickler-Tools

Mit OpenShift 4 ändert sich viel und doch nicht, zumindest aus Entwicklersicht. Die Verwendung von OpenShift 4 wird nichts bis fast nichts ändern. Um das Leben eines Entwicklers zu vereinfachen, hat Red Hat ein Tool odo entwickelt, welches nur die für Entwickler relevanten oc-Befehle enthalten wird. Ausserdem wird mit dem Red Hat CodeReady Workspaces eine "Kubernetes-native developer workspace server and IDE" zur Verfügung gestellt, um das Entwickeln von auf OpenShift lauffähigen Applikationen zu vereinfachen.

Installation

Die Installation von OpenShift 4 wurde stark vereinfacht. Mit dem einfachen Befehl openshift-install create cluster kann der Installationsassistent gestartet werden. Ohne weiteres Zutun fragt dieser die benötigten Konfigurationsparameter ab, die er nicht selbst herausfinden kann. Für alles andere werden vernünftige Defaults verwendet und so automatisch die Referenzarchitektur eingehalten.

Die Control Plane Hosts werden immer mit Red Hat CoreOS (RHCOS) aufgesetzt, bei den restlichen besteht die Wahl zwischen RHCOS und klassischem RHEL. Der Vorteil der Verwendung von RHCOS besteht darin, dass OpenShift das Betriebssystem selbst verwalten und somit auch automatisch aktualisieren kann.

Auf unterstützten Plattformen ist der Installer in der Lage, die gesamte zugrundeliegende Infrastruktur selbst zu provisionieren. Diese Art von Installation wird mit IPI (Installer Provisioned Infrastructure) bezeichnet und stellt die empfohlene Installationsvariante dar. Bei der anderen Art von Installation, UPI (User Provisioned Infrastructure), wird die Infrastruktur, wie es der Name bereits andeutet, selbst aufgebaut und dem Installer zur Verfügung gestellt.

Updates können neu über die Web Console durchgeführt werden, wobei zwischen drei Channels (stable, pre-release, nightly) ausgewählt werden kann.

Schaut man unter die Haube von OpenShift 4, fällt auf, dass nebst der Kernkomponente Kubernetes die Container Engine ausgewechselt wurde. Anstelle von Docker kommt neu CRI-O zum Einsatz. CRI-O verwendet als darunter liegende Container Runtime runc, wie dies auch Docker tut, und ist komplett OCI-compliant. Beispielsweise können mit Docker gebaute Images auch mit CRI-O problemlos gestartet werden - also kein Grund zur Sorge in dieser Hinsicht. Einer der Gründe für diesen Wechsel war, den monolithischen Docker-Daemon in einzelne Tools mit jeweils einem bestimmten Zweck aufzuteilen, ganz gemäss der Unix-Philosophie. So wurden nebst CRI-O die Container Tools buildah, Podman und skopeo ins Leben gerufen und sind schon seit einiger Zeit verfügbar.

Update von OpenShift 3 auf 4

Das Wichtigste vorweg: Es wird kein Update-Pfad von OpenShift 3 auf 4 geben. Red Hat stellt aber ein Migrations-Tool zur Verfügung, welches nicht nur die Kubernetes Ressourcen, sondern sogar die Daten von Persistent Volumes migrieren kann. Dabei wird S3 Storage als Zwischenspeicher verwendet. Das Migrations-Tool unterstützt neben Migrationen von Version 3 auf 4 auch Migrationen zwischen unterschiedlichen v4 Clustern.

Operators

Dass Operators ein wesentlicher Bestandteil von OpenShift 4 sein werden, ist bereits weitherum bekannt. Was Operators aber genau sind, wohl noch weniger: Ein Operator ist eine Methode für die Paketierung, das Deployment sowie die Verwaltung von Kubernetes-nativen Applikationen. Eine Kubernetes-native Applikation ist eine Applikation, welche sowohl auf Kubernetes deployt wie auch über die Kubernetes API verwaltet werden kann.

Ein Operator ist grundsätzlich ein Custom Controller, wobei der Controller zu den Kernkonzepten von Kubernetes gehört. Er vergleicht regelmässig den gewünschten mit dem effektiven Zustand einer oder mehrerer Ressourcen auf dem Cluster und korrigiert diesen falls nötig. Ähnlich wie dies auch Puppet tut. Ein Operator selbst läuft als Pod auf dem Cluster.

Operators übernehmen in OpenShift 4 eine zentrale Rolle. Sie sind für die Steuerung und Überwachung von so ziemlich jeder einzelnen Komponente verantwortlich, darunter auch kritische Netzwerk- und Credential-Dienste. Wiederum ein Operator übernimmt die Verwaltung aller dieser Operators, der sog. Cluster Version Operator. Nebst diesen vom Cluster Version Operator verwalteten Plattform-Operators können auch Applikationen Gebrauch vom Operator Framework machen. Sie werden allerdings nicht vom Cluster Version Operator, sondern vom Operator Lifecycle Manager (OLM) verwaltet. Eine Übersicht verfügbarer Operators ist auf OperatorHub.io ersichtlich. Analog zu bspw. dem in Rancher integrierten App Catalog für Helm Charts, ist auch der OperatorHub in OpenShift 4 integriert und ermöglicht eine einfache, grafische Installation über die Web Console.

Operator Framework

Operators können aber auch selbst geschrieben werden, bspw. mithilfe des Operator Frameworks. Das Framework unterstützt Helm, Ansible sowie Go, wobei jede Variante natürlich seine eigenen Vor- und Nachteile hat:

Der sog. Capability Level dieser Varianten wird in folgender Abbildung aufgezeigt. Der Capability Level veranschaulicht, welche Phasen unterstützt werden.

OpenShift Container Storage

Red Hat beschreibt den OpenShift Container Storage, oder kurz RHOCS oder OCS, als "Add-On for OpenShift for running stateful apps". Während OCS unter OpenShift 3 noch aus Gluster und Heketi bestand, um dynamisch Persistent Volumes zu allozieren, soll diese Aufgabe die Kombination aus Rook, Ceph und supportet sein. Wie bereits bei OpenShift 3 wird RHOCS auch auf v4 durch die OpenShift Storage Addon-Subscription abgedeckt. Wer also bereits im Besitz einer solchen ist, ist mit OpenShift 4 bereits abgedeckt.

Service Mesh

Das OpenShift Service Mesh besteht nicht nur, wie häufig angenommen, aus Istio, sondern zudem aus Kiali, Jaeger sowie Envoy Proxy. Das Service Mesh ermöglicht besseres Tracking und Management der Kommunikation zwischen Services und Pods, indem ein Envoy Proxy als Sidecar-Container in die Pods hinzugefügt wird. Envoy stellt dabei die Data Plane innerhalb des Service Mesh dar. Die Control Plane (nicht zu verwechseln mit der OpenShift Control Plane) ist verantwortlich für die Verwaltung und Konfiguration der Envoy Proxies um den Traffic zu routen wie auch Policies anzuwenden. Diese Konstellation ergibt ein Netzwerk von Services mit Load Balancing, Service-zu-Service-Authentifizierung, Monitoring und mehr. Code-Änderungen an der Applikation sind dabei keine bis nur wenige notwendig.

Pipelines

OpenShift Pipelines setzt auf Tekton, welches vorher unter dem Namen Knative Build-Pipeline bekannt war. Die Idee dahinter ist, cloud-native CI/CD unter Kubernetes zur Verfügung zu stellen. Dabei werden die verschiedenen für eine Pipeline benötigten Komponenten (wie auch die Pipeline selbst) als Custom Resources angelegt und können so via kubectl/oc administriert werden. Gem. Roadmap soll mit Version 4.2 ein Tech Preview und mit 4.3 die GA-Version erhältlich sein.

Serverless

Auch "serverless" darf natürlich nicht fehlen, welches mit Knative realisiert wird. Gemäss Roadmap soll mit Version 4.2 ein Tech Preview und mit 4.3 die GA-Version erhältlich sein. Was FaaS bedeutet kannst du im Blogpost von Tobru nachlesen.

Schlusswort

Die aufgeführten Neuerungen sind natürlich nicht abschliessend, daher kann sich ein Blick in die Release Notes von OpenShift 4.1 oder in einen der vielen anderen Artikel, Blogposts etc. lohnen. Mit OpenShift 4.2 wird der wohl erste Release veröffentlicht, der die meistgefragten Features und Unterstützungen mitbringt. Ein kurzer Blick lohnt sich also auf alle Fälle. Wir von APPUiO werden weiter Erfahrung mit dem brandneuen OpenShift-Release, auch in Zusammenarbeit mit unseren Kunden, sammeln und in eine bestmögliche Unterstützung umsetzen.

1. Was ist Kubernetes?

Kubernetes ist die Plattform zur Orchestrierung von Container-Systemen. Kubernetes automatisiert das Einrichten, Betreiben und auch das Skalieren von containerisierten Anwendungen. Die Open Source Plattform wird auch mit "K8s" abgekürzt und das Wort Kubernetes kann mit "Steuermann" übersetzt werden.

Zu den Funktionen von Kubernetes zählen unter anderem die Automatisierung von Containern und des Software Rollouts, die Optimierung der eingesetzten Ressourcen, Persistent Storage, Service Discovery, Autoscaling und HA. Im Vergleich zu anderen Orchestrierungsplattformen, wie bspw. Docker Swarm, unterstützt Kubernetes auch andere containerbasierte Virtualisierungssysteme.

Die offizielle Beschreibung von Kubernetes lautet:

Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.

Für das Verständnis dieses Beitrags ist es wichtig zu verstehen, dass es sich bei Kubernetes um eine Plattform handelt und nicht um ein fixfertiges Produkt ab der Stange.

2. Wer steckt hinter Kubernetes und wer entwickelt es weiter?

Kubernetes wurde ursprünglich von Google entwickelt, um die benötigte riesige Infrastruktur für die Suchmaschine bereitzustellen und zu optimieren. Durch den Einsatz von Virtualisierung von Hardware, Cloud Computing, Site Reliability Engineering und Container-Technologien führte die Lösung dazu, dass die bestehende Infrastruktur viel besser ausgelastet wurde. Dies führte zu wesentlich geringeren Kosten der Infrastruktur-Landschaft. Zum Durchbruch verhalf Google Kubernetes aber dadurch, dass Kubernetes als Open Source Lösung zur Verfügung gestellt und an die Cloud Native Computing Foundation (CNCF) gesoendet wurde.

Heute zählt Kubernetes zu den aktivsten Open Source Projekten weltweit und die Partner-Landschaft liest sich wie das Who-is-Who der IT-Welt.

3. Was ist eine Kubernetes Distribution?

Um die Unterschiede von Kubernetes und OpenShift zu verstehen, muss zuerst der Begriff "Kubernetes Distribution" geklärt werden. Wird Kubernetes direkt aus dem Open Source Kubernetes Projekt installiert, erhält man "nur" die Kernkomponenten (API Server, Controller Manager, Scheduler, Kubelet, kube-proxy). Damit Kubernetes aber auch wirklich nutzbar wird, werden viele weitere Komponenten wie etcd, Ingress Controller, Logging Server, Metrics Collector (z.B. Prometheus), Software Defined Network (SDN) usw. benötigt. Dies ist gut vergleichbar mit Linux: Der Linux Kernel alleine bringt noch nicht viel. Es braucht eine ganze Linux Distribution, die eine Shell, das Paketmanagement, den Bootprozess und vieles mehr zur Verfügung stellt.

OpenShift ist eine Kubernetes Distribution und macht aus Kubernetes ein Produkt.

Eine "Minimum Viable Kubernetes Distribution" benötigt folgende zusätzliche Komponenten und Tools für einen produktiven Betrieb:

Optional werden weitere Komponente empfohlen:

4. OpenShift als Kubernetes Distribution

Im Kern basiert OpenShift zu 100% auf Kubernetes, bringt aber als Kubernetes Distribution alles mit, was zur Benutzung eines Kubernetes Clusters benötigt wird. Um nur die wichtigsten Funktionen zu nennen:

Alle diese von Haus aus mitgelieferten Funktionalitäten lassen sich zu jedem Kubernetes Cluster hinzufügen, was jedoch mit einem hohen Aufwand verbunden ist. Dies ist vergleichbar mit dem Bau einer eigenen Linux Distribution, wie z.B. das "Linux From Scratch" veranschaulicht. Für Kubernetes existiert eine ähnliche Anleitung, genannt "Kubernetes The Hard Way".

5. OpenShift als PaaS

Die Stärke von Kubernetes liegt in der Container Orchestrierung. Zusätzlich dazu bietet OpenShift klassische Platform-as-a-Service (PaaS) Funktionen. Eine davon ist das automatische Builden und Deployen von Applikationscode direkt ab einem Git Repository. Trotzdem hat man als Anwender der Plattform dank der grossen Flexibilität immer die Wahl, ob man die integrierten Buildfunktionen nutzen oder doch lieber ausserhalb des Clusters builden möchte. Dies lässt sich für jedes Deployment entscheiden. So können auf einem Cluster beide Arten verwendet werden.

6. OpenShift als Upstream zu Kubernetes

Viele Entwicklungen in Kubernetes stammen ursprünglich aus OpenShift. Als bestes Beispiel lässt sich RBAC (Role Based Access Control) nennen. Dieses Feature ist seit der ersten OpenShift-Version Bestandteil und wurde sukzessive in Kubernetes eingebaut. RBAC ist seit Kubernetes Version 1.6 fester Bestandteil von Kubernetes. Auch das OpenShift "Route"- oder das "DeploymentConfiguration"-Objekt hat die heutigen Objekte "Ingress" bzw. "Deployment" in Kubernetes massgeblich mitgeprägt.

Da OpenShift zu 100% auf Kubernetes basiert, werden auch alle Kubernetes Native Workloads unterstützt, wie z.B. das "Deployment"- oder das "Ingress"-Objekt.

Schaut man etwas genauer auf die Contributor-Statistiken, dann stellt man fest, dass Red Hat die Nummer 2 der Contributor-Firmen ist (nur Google ist noch weiter vorn). Somit ist Red Hat massgeblich an der Entwicklung von Kubernetes beteiligt. Mit dem Kauf der Firma CoreOS hat sich Red Hat geballtes Kubernetes Know-how angeeignet. Das Ergebnis der CoreOS Integration in Red Hat ist die Verschmelzung von OpenShift und Tectonic zu OpenShift Version 4.

7. Alternativen zu OpenShift

OpenShift ist nicht die einzige Kubernetes Distribution auf dem Markt. Ein kurzer Vergleich zeigt die Unterschiede:

Weitere Kubernetes Distributionen aufgelistet:

8. Vendor Lock-ins

Ein sehr wichtiger zu beachtender Aspekt ist der Cloud- und/oder Vendor-Lock-In. Viele der Kubernetes Distributionen haben ihre eigene Eigenschaften, die unter Umständen nicht miteinander kompatibel sind. Am Beispiel der "Cloud-Vendor"-Distributionen: Diese können nur in der entsprechenden Cloud benutzt werden. Möchte man jedoch einen Hybrid-Cloud-Ansatz verfolgen, ist dies durch den Lock-In nicht möglich. Im Gegenzug ermöglicht eine selbst installierbare Distribution wie OpenShift diese Option.

Reine Open Source Distributionen ohne Herstellersupport sind für produktive Umgebungen nicht zu empfehlen.

9. APPUiO - Swiss Container Platform

Dem aufmerksamen Leser ist bestimmt aufgefallen, dass zwischen der "Minimum Viable Kubernetes Distribution" und OpenShift gewisse Diskrepanzen bestehen. Genau dort setzt APPUiO an: Wir veredeln OpenShift zu einer vollständigen, production-ready Kubernetes Distribution, indem wir Managed Services anbieten. Wir überwachen und sichern den Clusterstatus automatisch, kümmern uns um regelmässige Updates, beheben Fehler, stellen Persistent Storage zur Verfügung und helfen mit unserem Know-how das Beste aus der Plattform herauszuholen. Durch unsere Erfahrung im Setup und Betrieb von OpenShift Clustern rund um die Welt, bieten wir Managed OpenShift Cluster auf nahezu jeder Public, Private oder On-Premise Cloud an. APPUiO hilft gerne bei der Evaluation, Integration und Betrieb und unterstützt mit ihrer langjährigen Kubernetes und OpenShift Erfahrung.

10. Wo kann ich mehr erfahren?

Am Cloud Native Meetup vom 28. August 2018 haben wir übers Thema Kubernetes Distribution berichtet. Die Slides dazu sind auf Speaker Deck zu finden. Ein empfehlenswerter Blogpost zum Thema Kubernetes Distributionen (auf Englisch) findet ihr hier: 10 most important differences between OpenShift and Kubernetes.

Wenn du mehr über OpenShift erfahren willst, besuche uns an unserem Stand am Red Hat Forum Zürich am 10. September 2019 - 8:00 bis 18:00 im StageOne Zürich-Oerlikon.

Das gesamte APPUiO-Team freut sich auf deinen Besuch!

Um unser langjähriges Wissen im Bereich der Software Entwicklung, Automatisierung und Betrieb von Cloud Native Applikationen auf OpenShift Container Plattformen weiterzugeben, haben wir die zweitägige OpenShift Dev Schulung erarbeitet. Sie baut das Know-How der Teilnehmer in einer guten Mischung aus Theorie und Hands-on Lab auf.

Die Schulung beinhaltet folgende Themen, kann aber je nach Bedürfnissen angepasst werden:

Die Schulung wird von Christoph Raaflaub, unserem Software Architect & Middleware Engineer, durchgeführt. Christoph ist unser Spezialist in Sache automatisierte Software Entwicklung und teilt gerne seine langjährige Erfahrung mit euch.

Die OpenShift Dev Schulung wird bis max. 8 Teilnehmer durchgeführt. Auf Anfrage ist eine Durchführung auch für ganze Gruppen möglich, dediziert oder bei dir am Standort. Die Schulung ist in Deutsch oder Englisch möglich.

Ist das etwas für dich und deine Mitarbeiter? Gerne senden wir dir das Angebot zur OpenShift Dev Schulung zu und freuen uns auf deine Kontaktaufnahme.

Der Begriff beerup ist mit dem Ziel entstanden, die Community von APPUiO in ungezwungener Atmosphäre zu vereinen und dabei über die Bedürfnisse der Community zum Thema Container und OpenShift zu sprechen. Was könnte APPUiO ihrer Community bieten? Wobei können wir noch mehr voneinander profitieren? Denn ihr wisst: Zusammen sind wir stärker, können Grosses in der IT-Welt erreichen und es macht einfach mehr Spass :-)

Das erste beerup hat am 28. März im Anschluss des RoundTable's von Red Hat stattgefunden. Dabei durften wir rund 75 Gäste in der Rüsterei in Zürich empfangen. Unsere Community konnte sich bei einem Apéro verpflegen und sich über dies und jenes austauschen. In den vielen tollen Gesprächen stiess das APPUiO-Team auf verschiedenste Ideen und Bedürfnisse der Community. Durch den Einsatz jedes Einzelnen durften wir eine grosse Anzahl an Inputs aufnehmen. Dafür bedanken wir uns noch einmal herzlich bei euch und bei Red Hat für die Unterstützung.

Das APPUiO-Team wird sich einen Überblick über eure Ideen verschaffen und versuchen, sie baldmöglichst zu realisieren. Du kannst dich also über Zukünftiges freuen!

Wir haben uns gefreut, eine eine grosse Anzahl an Leuten aus unterschiedlichsten Branchen und unterschiedlichsten Kantonen bei uns am beerup begrüssen zu dürfen. Es hat Spass gemacht mit euch zu plaudern und euch näher kennenzulernen.

Wir wünschen euch eine gute Zeit und bis zum nächsten Mal!

Ab sofort bieten wir auf APPUiO einen voll integrierten Backup Service an. Der Backup Service speichert die Daten eines persistenten Volumes (PVC) regelmässig auf einen S3-Objektspeicher der Wahl. Als Anwender der Plattform definiert man selber, wo (Cloud-Anbieter und geographisch) die Daten gespeichert werden sollen. Wir empfehlen den Object Storage von cloudscale.ch.

Technisch basiert der Backup Service auf Restic und wird über einen Backup Operator gesteuert.

In der Beta Version wird noch kein aktives Monitoring der Backups gemacht und es fallen keine zusätzlichen Kosten zum Backup Storage an. Sobald der Backup Service die Beta Version beendet hat informieren wir über das Preismodell.

Aktuell werden automatisch alle "ReadWriteMany" PVCs im Backup gespeichert. Geplant ist, dass auch andere Volumes wie Datenbanken konsistent ins Backup aufgenommen werden können.

Die Dokumentation ist unter docs.appuio.ch zu finden. Über ein Feedback unter support@appuio.ch freuen wir uns.

"APPUiOli ist ein Hobbyprojekt, um APPUiO "anfassbar" zu machen", erklärt Tobias Brunner, Mitgründer von APPUiO und Initiant von APPUiOli. Das Projekt umfasst sechs OrangePi Win Plus Boards mit je 2 GB RAM und einem A64 Quad-core Cortex-A53 64 bit Prozessor. Davon ist ein Board der Kubernetes Master, die anderen fünf sind die Kubernetes Nodes. Als Betriebssystem kommt Armbian zum Einsatz.

1 RayperryPi Board dient als Kontrollsystem und beinhaltet folgendes:

- Pi-hole DNS Resolver

- NAT Gateway

- VLAN Tagging

- Ansible

- DHCP Server

- LCD Screen

Nebst der Präsentation von APPUiOli konnten wir an den DevOpsDays spannende Talks verfolgen und führten interessante Gespräche. Wir freuen uns schon jetzt auf nächstes Jahr!

Im Sommer 2017 lancierte Amazee.io ein neues Produkt: Lagoon. Die Open Source Drupal Hosting Plattform nimmt den Programmcode von Entwicklern, bildet damit Docker Images, überträgt diese in OpenShift/Kubernetes und überwacht gleichzeitig die Deployments. Dieser gesamte Prozess läuft auf APPUiO. „Der Entscheid für APPUiO kam nicht von ungefähr: Mit den Initianten der Container Plattform verbindet uns eine jahrelange professionelle Zusammenarbeit im Betrieb“, so Bastian Widmer, System Engineer bei Amazee.io. Zudem teile man die selben Werte und setze konsequent auf OpenSource. “Der gesamte Sourcecode von Lagoon ist als Opensource Projekt veröffentlicht”, erklärt Widmer. Bereits in der Betaphase wurden die ersten Projekte auf APPUiO umgesetzt. Schnell wurde die Zusammenarbeit ausgebaut. „Lagoon ist gemeinsam mit APPUiO gewachsen“, so Widmer.

Die Vorteile von APPUiO sieht der Systemtechniker in der Unterstützung, OpenShift zu verstehen. Um OpenShift unabhängig zu betreiben, bräuchte man viel Wissen und müsste sich stetig auf dem Laufenden halten. “Im Rahmen von Managed Private APPUiO wird uns dies abgenommen. Denn Updates und der Betrieb werden automatisch von den Experten durchgeführt”, erklärt Widmer.

Die Zusammenarbeit zwischen den Partnern erfolgt meistens in Projekten. „Wir sehen uns dabei als Experten für das Drupal-Hosting, APPUiO ist der Spezialist in Sachen OpenShift.“ Die Leistungen von APPUiO reichen von der Beratung über den Aufbau bis hin zum Betrieb. „Regelmässig führen wir gemeinsame Stand-ups durch“, so Widmer. In naher Zukunft will Amazee.io mit Lagoon zusätzliche Länder erschliessen – mit APPUiO als starkem OpenShift-Partner an seiner Seite.

www.amazee.io

Lack of flexibility, technical challenges and extensive coordination: ‘In 2016, we realised that the configuration of various applications in the landscape was extremely complex,’ explains Matthias Summer, Senior System Engineer at Adcubum. Following intensive research into solutions, Adcubum decided to switch to Red Hat’s OpenShift. And in APPUiO, it found a partner that offered even more advantages: ‘Experienced experts who work with OpenShift every day set up the platform for us in-house and trained us to use it,’ says Summer. Together with his team of five system engineers, Summer operates around 500 adcubum SYRIUS test installations. ‘Thanks to APPUiO, we can now deploy test environments at the touch of a button,’ he says.

Adcubum aims to transfer 95% of its development and test instances to OpenShift by the end of 2018. The challenge here is to prepare a 20-year-old application with several million lines of code for the new container platform. Although this requires significant effort, Summer expects the results to be wholly positive: ‘As we will be working on a single platform in future, collaboration between development and operations will improve greatly, and we’ll also become more efficient.’ Customers such as Helsana, Concordia, Visana and SUVA will also benefit. In future (from 2019 at the earliest), they will be able to access adcubum SYRIUS in container form and run it on their own OpenShift installations. ‘Customers will then be using the same development platform as us, which means that updates can be carried out automatically and far more frequently,’ explains Summer.

adcubum SYRIUS has been running on the OpenShift container platform APPUiO since the end of 2017. ‘Now we want to get our customers excited about OpenShift as well.’ To do so, Adcubum is working in close collaboration with APPUiO.

www.adcubum.com

Bereits zum dritten Mal traf sich Anfang März die Entwickler-Community an den Voxxed Days in Zürich. Spannende Talks zu Themengebieten wie Java, Big Data, Cloud oder Serverless standen auf dem Programm. Für uns vom APPUiO-Team stand der Austausch mit den Entwicklern im Vordergrund.

Ebenfalls spannend waren für uns folgende Expertentalks:

Real world serverless - architecture, patterns and lessons learned: Lessons learned wie eine Applikation mit AWS Lamba betrieben werden kann.

Troubleshooting & Debugging Production Applications in Kubernetes: Einblick in ein Toolset um debugging aufs nächste Level zu bringen.

One does not simply log in! - SSO for Web APIs: Keycloak, OAuth2, OpenID Connect und JSON Web Tokens (JWT) waren hier das Thema.

Introduction to Apache Kafka as Event-Driven Open Source Streaming Platform: Einführung in Apache Kafka.

Alle Talks der Voxxed Days können auf YouTube nachgeschaut werden: YouTube playlist

Nächstes Jahr finden die Voxxed Days am 21. März 2019 wiederum im Sihlcity Cinema in Zürich statt. Wir freuen uns darauf!

„Durch die Containertechnologie ist es möglich, nahezu jede Applikation auf APPUiO zu deployen. Die grösste Einschränkung war bis jetzt, dass der Zugriff vom Internet aus nur über HTTP oder HTTPS möglich war. Das ist ab sofort anders! Wir unterstützen neu den Zugriff vom Internet via TCP oder UDP auf jede Art von Applikation, die auf APPUiO läuft.“

Und so funktioniert es

Da sich Services im Moment noch nicht über das OpenShift Webinterface erstellen lassen, muss dies über den Command Line Client oc gemacht werden. Dies ist aber ganz einfach:

1. Anmelden an APPUiO

oc login console.appuio.ch

2. Service erstellen (Beispiel mit TCP)

oc -n MYPROJECT create service loadbalancer mytcpservice --tcp=587:587

Hinweis: Dieser so erstellte Service selektiert automatisch alle Pods mit dem Label app=mytcpservice

3. Zugewiesene externe IP Adresse abrufen

oc -n MYPROJECT describe service mytcpservice

Die IP Adresse findet man im Feld "External IPs".

Nun ist der Service, der in den vom Service selektierten Pods läuft, über die automatisch zugewiesene externe IP-Adresse und dem definierten Port erreichbar.

Die offizielle Dokumentation zu diesem Feature ist unter docs.appuio.ch zu finden. Ein solcher Service mit einer öffentlichen IP-Adresse kostet CHF 0.35 pro Tag. Bei Fragen stehen wir jederzeit unter support@appuio.ch zur Verfügung. Wir helfen auch gerne bei der Implementation Ihres Services auf APPUiO.

APPUiO allows you to orchestrate and manage containers with Kubernetes. You define how many of your application instances should run in parallel and Kubernetes then takes care of scaling, load balancing and stability.

The concept of Kubernetes is described in the ebook „The state of the Kubernetes Ecosystem“. It serves as a primer for both newcomers, assessors and implementers who are looking to make the most of the ecosystem of products and services emerging around Kubernetes.

We are proud to be mentioned with APPUiO among big international brands in this ebook. It motivates to go on working with Kubernetes and bring each day more services to the cloud.

You can get the ebook here.

The world is talking about the Kubernetes Project - but did you hear about OpenShift? It’s an open source product based on the open source projects Kubernetes and Docker plus a container builder/registry, and a Web GUI to manage it all. This blog post will introduce you to OpenShift and give some hints why to use it, how to get started, and where you can get professional support and managed services.

What is OpenShift and why should you use it?

It describes itself as “the industry’s most secure and comprehensive enterprise-grade container platform based on industry standards, Docker and Kubernetes”. It’s much more than that - it gives you a complete Kubernetes cluster with many cool features: integrated build pipelines, Docker Registry, Application router (for getting traffic into the cluster), security based on RBAC and SELinux, Web Console for easy access, central logging of all Pod output, Metrics to measure Pod performance, Installation and upgrade using Ansible Playbooks, Source-to-Image builds, and much much more.

As a Linux distribution acts to the Linux Kernel, OpenShift is a Kubernetes distribution with all the needed tools and tricks to make full use of it.

OpenShift comes in two flavors:

• OpenShift Container Platform: Software product to install in your data center and get support by Red Hat.
• OpenShift Origin: The open source upstream project with a very active GitHub repository.

OpenShift enables you to develop faster - after committing your changes in GIT it solves container image build, storage, deploy, scaling, monitoring, and logging for you so you don’t have to do it. The integrated build and deployment processes help you get the developed application to the customer as fast as possible. It enables you to deploy hourly or even faster, and scale computing resources per project automatically with your user base.

How to get started?

There are many many ways to get started, here are a few hints and examples:

• Install your own OpenShift cluster for example on Exoscale with the official Ansible Playbooks. By using these playbooks you learn to customize every inch of the installation and configuration, and they also help you upgrade from one version to another. Documentation about these playbooks can be found inside the Git repository or on the documentation page.
• Start a local OpenShift cluster on your workstation with Minishift (based on Minikube) or with the fancy command oc cluster up. Just download the client binary from the GitHub releases page, unpack it, and then run the oc cluster up command. This will launch a complete OpenShift instance on your local Docker Engine:

% oc cluster up
Starting OpenShift using openshift/origin:v3.6.0 ...
Pulling image openshift/origin:v3.6.0
Pulled 1/4 layers, 28% complete
Pulled 2/4 layers, 83% complete
Pulled 3/4 layers, 88% complete
Pulled 4/4 layers, 100% complete
Extracting
Image pull complete
OpenShift server started.

The server is accessible via web console at:
    https://127.0.0.1:8443

You are logged in as:
    User: developer
    Password: <any value>

To login as administrator:
    oc login -u system:admin
% oc new-app https://github.com/appuio/example-php-sti-helloworld.git
[...]
% oc expose svc example-php-sti-helloworld
[...]
% curl -s http://example-php-sti-helloworld-myproject.127.0.0.1.nip.io/ | grep title
    

• Have a look at the APPUiO Techlabs on GitHub which is a free step-by-step introduction to get started. We offer free half-day workshops.
• The APPUiO Microservices Example documentation gives some insight for developers on how a Microservice application can be built and deployed on OpenShift, describing tools like Gitlab CI and Jenkins for the build pipelines.

There is a lot of documentation available from upstream. It’s a great source to read about every little detail. You’ll find documentation for both the OpenShift Container Platform and OpenShift Origin. APPUiO also provides a community-driven documentation.

This blog post was originally published on the Exoscale blog.

It has been a year since my first retrospection onto an APPUiO & OpenShift Techlab; a year and fourteen additional techlabs. And as it's common in such a long time, a lot of things have changed: OpenShift has meanwhile graduated to version 3.5 and its webinterface, compared to version 3.1 back then, has become a lot more powerful and intuitive. But then there are things that remained constant as well, not least among them the lively interest in our Techlabs.

When we updated OpenShift to version 3.4 a lot of things changed for APPUiO. Due to the more intuitive webinterface many operations are now accomplishable by the click of a mouse. This helps new developers to get acquainted. Nevertheless, it’s obvious that there still are quite a few challenges for starting with APPUiO, as demonstrated by the sheer number of participants and the unbroken interest in our Techlabs in both Berne and Zurich. Developers are still participating in large numbers and learning the most important steps to deploying applications into the cloud hands-on.

Other things have stayed tried-and-true, among them the basic concepts of containers. But also my happiness seeing participants getting excited about the technical possibilities they’re offered by OpenShift. And then there are some matters that keep coming up during the Techlabs. One of the questions raised most often is how to to deploy your specifically coded applications onto OpenShift. There are three fundamental ways to do that:

• OpenShift compiles the application-pod from the pure source-code, using the integrated Source-to-Image-Framework. During this process, it automatically identifies the language in question.
• OpenShift builds the application-pod using a provided Docker-file. To do that, the Docker image is built, pushed into the internal registry and finally deployed.
• OpenShift simply uses a pre-built Docker image and deploys it. (see also: reference architecture)

Example of a specifically built S2I-Deployment, including the preceding build in Jenkins. The more frugal way is of course to use an already existing S2I script.

Another question posed often is for just how long our labs are available after the lab. The answer to that one is simple: For as long as you need them. Our labs are downloadable from GitHub and one of our additional labs describes in-depth how to establish your own OpenShift application development environment. This should remove all obstacles to give it a try at home or at work. And of course, in true Open-Source-fashion we’re glad to receive contributions and issues in order to keep improving our Techlabs.

Piqued your interest? The next Techlabs will take place in August and September. We’re looking forward to many participants and are excited for new, informative experiences.

Key Data Techlabs:

APPUiO & OpenShift Techlab Berne:
When: Thursday, August 24th, 14:00 (lasting until ca. 17:30)
Where: Belpstrasse 37, 3007 Bern, 3rd storey (or 4th floor for our American friends)
Registration

APPUiO & OpenShift Techlab Zurich:
When: Thursday, September 28th, 14:00 (lasting until ca. 17:30)
Where: Neugasse 10, 8005 Zurich
Registration

In this training, you will build a fully functional E-Commerce application, using microservices, Weave Net and Scope, Docker containers and as an orchestrator APPUiO's Red Hat OpenShift v3 based PaaS.

This training is an ideal addition to the free half-day APPUiO TechLabs with more time to provide in-depth knowledge and access to the top experts.

Register here

Voxxed Days Zürich returns to Sihlcity Cinema on February 23rd, 2017. The entire developer community can meet and hear from some of the most inspiring speakers in our sector.

Also APPUiO will be present. In our Mini Techlabs participants learn hands-on the key steps how applications are deployed to the cloud and how a container can be deployed und operated.

voxxeddays.com/zurich/

It’s now possible to pay a monthly fee for APPUiO, the Swiss Container Platform. The price for the public service is between CHF 49.- and CHF 340.- per month. If you decide to pay a full year in advance we’ll give you two months for free.

Read more