Blog

2020
Jan
30

RedHat OpenShift 4.2 – Installations Pitfalls, king und Storage

OpenShift 4.2
Puzzle ITC, einer der Gründerfirmen von APPUiO, hat eine Woche genutzt, um ihr Wissen rund um OpenShift 4.2 zu vertiefen. In der sogenannten /mid Week erzielten die Members spannende Erkenntnisse bei der Installation, Networking und Storage.

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.

1. Installation Pitfalls

Pitfalls

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:

  • Kleinere Umgebungen als 3 Master / 3 Node (Standardvorgabe) sollten nicht gewählt werden. Es wird sehr langsam oder die Installation schlägt teilweise sogar fehl.
  • Für den OpenShift Installer wird ein install-config.yaml File erstellt. Dies sollte vor Beginn der Installation gesichert werden, da der Installer dieses anschliessend löscht.
  • Weiter sollten auch alle Terraform Output Files gesichert werden, damit später der Cluster einfach gelöscht werden kann. Achtung, beim Löschen des Cluster erfolgt keine zusätzliche Bestätigung!
  • Je nach Plattform haben wir unterschiedliche Grössen der Standard-VM festgestellt.
  • Wenn während der Installation kein SSH-Keyfile angegeben wurde, kann anschliessend nicht auf die VM's per SSH zugegriffen werden.
  • Die Installation eines Clusters dauert je nach Plattform unterschiedlich lang:

    Installationsdauer

    VMware vSphere

    Einige Bemerkungen zur VMware vSphere Installation:

  • Die Dokumentation zur Installation war sehr gut und wir konnten dieser Schritt für Schritt folgen.
  • Während der (ersten) Installation mussten wir feststellen, dass Reverse DNS Einträge zwingend notwendig sind. Die Installation war blockiert und wir mussten von neuem beginnen.
  • Kleine Fehler in den Ignition (JSON) Files führen zu Fehler, die leider sehr schwer zu finden sind, da keine sinnvolle Fehlermeldung vorhanden ist. So hat uns z.B. ein fehlendes Komma etwa eine Stunde Zeit gekostet. Ignition Files können hier validiert werden.
  • Für die Installation muss ein Load Balancer (z.B. HAproxy) erstellt werden. Siehe auch unten im Teil zu Networking.
  • Infrastructur MachineSets für vSphere sind noch nicht implementiert. Daher ist die Installation auf VMware vSphere auch eine User Provisioned Infrastructure (UPI) Installation.
  • GCP

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

  • Identity and Access Management(IAM)
  • Cloud Resource Manager API
  • 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:

  • Free Tier Subscription reicht nicht aus für eine OpenShift Installation.
  • Es müssen Anpassungen an den default Azure Account Limits gemacht werden.
  • Zürich befindet sich z.Z. nicht unter den supported Azure Regions.
  • Die Dokumentation ist falsch bzgl. Azure account limits & Creating a service principal.
  • AWS

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

    2. Networking

    networking

    Load Balancing

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

  • API Load Balancer: Für eine Hochverfügbarkeit der Kubernetes-API (welche auf dem Master läuft), müssen alle API Calls an diese Master Nodes verteilt werden.
  • 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.

  • Client Access Load Balancer: Für den Zugriff auf den Applikation Workload wird ein Load Balancer benötigt, der die Ingress Controller weiterleitet.
  • 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

  • NetworkPolicy:Die Kubernetes v1 NetworkPolicy Features sind in OpenShift 4.2 verfügbar
  • Egress IP: Identisch zu OpenShift 3.11. (Referenz)
  • EngressNetworkPolicy wir auf OpenShift 4.2 nicht unterstützt
  • EgressRouter wird auf OpenShift 4.2 nicht unterstützt
  • 3. Storage

    storage

    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.

  • GCP
  • Azure
  • AWS
  • vSphere
  • 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:

  • Auf EFS sind alle Volumes nur Subfolder des Root Volume.
  • Quotas können nicht forciert werden.
  • Keine Usage Metrics
  • size in einem PVC wird nicht berücksichtigt.
  • RedHat sagt zu EFS: "Elastic File System is a Technology Preview feature only.[...]" Openshift doc on EFS
  • upstream efs-provisioner: detailed doc & code
  • 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.

  • Symlinks
  • Hard links
  • Extended attributes
  • Sparse files
  • Named pipes
  • 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.

  • GCP mit Google Cloud Storage
  • AWS mit S3
  • Azure mit Azure Object Storage
  • In einer on-premise VMware vSphere Umgebung muss ein Object Storage Service selbst aufgebaut werden.

    weiterlesen
    2019
    Dez
    09

    Quarkus on APPUiO

    Quarkus on APPUiO With the release of Quarkus 1.0.0, Java has once again become attractive for microservices. In this blog post I show you how to run native applications on APPUiO using Quarkus. This is a guest article by Michael Gerber form nxt Engineering GmbH.

    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.

    Quarkus APPUiO 1

    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.

    Quarkus on APPUiO 3

    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.

    weiterlesen
    Sept
    17

    Red Hat Forum 2019

    Red Hat Forum 2019 Vor gut einer Woche fand das 8. Red Hat Forum in Zürich Oerlikon statt. Auch dieses Jahr war APPUiO als Sponsor mit einem Stand vertreten. Über 800 Teilnehmer warteten gespannt auf einen intensiven und spannenden Tag.

    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.

    Red Hat Forum

    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.

    APPUiO Retro

    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.

    APPUiO beerup

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

    APPUiO goldenticket

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

    Euer APPUiO-Team

    weiterlesen
    Aug
    29

    OpenShift 4 Blogpost

    OpenShift4 Seit Juni dieses Jahres ist OpenShift 4.1 verfügbar, der erste öffentlich zugängliche Release von Red Hat (Version 4.0 war ein rein interner Release). Wir möchten dir mit einer Blogpost-Serie Informationen, Erfahrungsberichte, Empfehlungen sowie Tipps und Tricks weitergeben, damit du frühzeitig über die nötigen Informationen verfügst. Zusätzlich werden wir verschiedene Events wie beerups oder Techtalks organisieren, damit du detailliertere und technischere Berichte erhältst. Falls du in deinem Unternehmen Unterstützung benötigst oder wir dir mögliche Wege zu OpenShift 4 aufzeigen sollen, darfst du dich gerne bei uns melden. Starten wir mit ein paar Grundlagen zu OpenShift 4.

    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:

  • Helm ist sehr einfach zu schreiben, da kein Code geschrieben werden muss. Zudem wird auch kein Tiller mehr benötigt.
  • Ansible ist für Betreiber die erste Wahl, da meist bereits Ansible-Know How vorhanden ist.
  • Go stellt zwar die vermutlich herausforderndste, dafür, aufgrund seiner vollwertigen Programmiersprache, aber auch die mächtigste und flexibelste Variante dar.
  • Der sog. Capability Level dieser Varianten wird in folgender Abbildung aufgezeigt. Der Capability Level veranschaulicht, welche Phasen unterstützt werden.

    Capability level

    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.

    weiterlesen
    Aug
    26

    10 wissenswerte Fakten zu Kubernetes und OpenShift

    Kubernetes und OpenShift Bei APPUiO setzen wir auf OpenShift von Red Hat. OpenShift ist eine Kubernetes Distribution. Kubernetes ist eine Plattform zur Orchestrierung von Container-Systemen. Alles klar? Bist du noch dabei? :-) Wenn ja, dann lies weiter und erfahre im folgenden Blogpost, was Kubernetes, eine Kubernetes Distribution und OpenShift ist und warum wir APPUiO auf den Grundlagen von Kubernetes und OpenShift aufgebaut haben.

    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:

    Installations- und Upgrademechanismus: Für eine automatisierte Installation aller involvierten Komponenten.
    SDN (Software Defined Network): Pods müssen untereinander kommunizieren können, egal wo sie laufen. Dies stellt das SDN sicher.
    Ingress Controller: Damit der Benutzerzugriff auf die auf dem Cluster laufende Applikationen möglich ist.
    Authentication: Eine zentrale Benutzer- und Gruppendatenbank stellt den authentisierten und autorisierten Zugriff zur Verfügung.
    Security: Kubernetes führt Container via Docker oder CRI-O aus. Die Sicherheit auf dem Hostsystem muss entsprechend gewährleistet sein.
    Persistent Storage: Stateful Applikationen wie Datenbanken benötigen persistenten Storage.
    Monitoring: Ständige Überwachung aller Clusterkomponenten und Applikationen.
    Backup: Sicherung der Clusterkomponenten und persistenten Daten.

    Optional werden weitere Komponente empfohlen:

    ▸ Zentrales Logging mit grafischer Aufbereitung und Suchfunktion
    ▸ Applikations- und Cluster Metrics inkl. Alerting

    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:

    Operations Tools: Ein offizieller Weg via Ansible ermöglicht es, den gesamten Lifecycle von OpenShift durchzuführen. Dazu gehört die automatisierte Installation, wie auch Upgrades auf neuere Versionen von OpenShift. Mit OpenShift 4 beginnt eine neue Ära mit einem neuen Installations- und Operationsprozess, basierend auf Kubernetes Operators.
    Router: Der OpenShift Router (Ingress Controller) - basierend auf HAProxy - sorgt dafür, dass der Zugriff auf Applikationen innerhalb des Clusters über HTTP(S) ermöglicht wird.
    Multi-Tenancy: Die im Kern eingebaute Multi-Tenancy über OpenShift Projekte, RBAC und weiteren Konzepten ermöglicht die Benutzung der Plattform durch verschiedene Tenants (Kunden).
    Authentication: Es werden die unterschiedlichsten Authentication Backends unterstützt, allen voran LDAP, ActiveDirectory und viele mehr.
    Metrics: Die mitgelieferte Metrics Komponente sammelt alle verfügbaren Messwerte (RAM, CPU, Netzwerk) der auf dem Cluster laufenden Applikationen und visualisiert diese in der Webkonsole.
    Central Logging: Alle von der Applikation auf stdout geloggten Zeilen werden automatisch von der zentralen Logging Komponente gesammelt und über die Webkonsole dem Benutzer zur Verfügung gestellt.
    Security: Die Plattform ist auf höchste Sicherheit ausgelegt. So sorgen z.B. Sicherheitsmassnahmen im Kernel von Red Hat Enterprise Linux wie SELinux dafür, dass die Sicherheit der Container gewährleistet ist. Weitere Massnahmen wie "Security Context Constraints" (SCC) und das Verhindern von Root Containern sorgen für weitere Sicherheit.
    Builds und Pipelines: Direkt im Cluster integrierte Build- und Pipeline-Funktionalitäten ermöglichen einen komplett integrierten CI/CD Workflow.
    Webkonsole: Alle Vorgänge auf dem Cluster werden für den Anwender der Plattform in einer Webkonsole graphisch dargestellt und ermöglichen einen einfachen und schnellen Einstieg in die Benutzung von Kubernetes.
    SDN: Das mitgelieferte Software Defined Networking sorgt für die Konnektivität zwischen den auf der Plattform laufenden Pods und für eine angemessene Netzwerksicherheit mit Network Policies.
    Container Registry: Docker / Container Images werden in der mitgelieferten Registry gespeichert und zum Deployment auf die Worker Nodes benutzt.

    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:

    Cloud Vendor Kubernetes:Die grossen Clouds bieten ihre eigenen Kubernetes Distributionen als Service an. Diese sind auf die jeweiligen Clouds zugeschnitten und werden von den Anbietern gepflegt. Eine Installation auf der eigenen Private Cloud oder auf anderen Public Clouds ist nicht möglich.
    Rancher:Seit der Version 2.0 fokussiert sich Rancher zu 100% auf Kubernetes und bietet als grosse Stärke eine Multi-Cluster Verwaltungsfunktion. So können mit Rancher Kubernetes Cluster in der Cloud (z.B. auf Amazon oder Google) zentral verwaltet werden, wie auch Kubernetes Cluster mit der "Rancher Kubernetes Engine" auf eigene VMs. Mit dem Webinterface gestaltet sich das Aufsetzen eines neuen Clusters sehr einfach und Applikationsdeployments mittels Helm sind auch direkt verfügbar.
    Canonical / Ubuntu Kubernetes (Charmed Kubernetes): Plattform basierend auf Ubuntu, welches Juju als Installationstool verwendet. In Partnerschaft mit Google und Rancher wird in Zukunft eine Hybrid-Cloud-Lösung angeboten.
    SUSE CaaS-Plattform: Eine neue Plattform, basierend auf SUSE MicroOS. Mittels Salt wird die Konfigurationsverwaltung sichergestellt. Unter folgendem Link kann am Beta Programm teilgenommen werden: SUSE CaaS Platform Beta.

    Weitere Kubernetes Distributionen aufgelistet:

    ▸ Und noch mehr aus der Kubernetes Dokumentation: Getting started

    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!

    weiterlesen
    Jul
    31

    Neu: OpenShift Dev Schulung

    DevSchulung Ab sofort bietet APPUiO OpenShift Dev Schulungen an. Wir zeigen dir, wie du deine Business Applikationen auf der OpenShift Plattform entwickeln, betreiben und monitoren kannst.

    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:

    Agenda – day 1
    1. Introduction Linux Container / OpenShift Plattform
    2. Application Architecture / Cloud Native / 12 Factor Apps / Service Broker
    3. Introduction to develop an Application on OpenShift
    4. Hands-on: Build Strategies on OpenShift (s2i, binary, docker)
    5. Application Configuration / Service Discovery
    6. Hands-on: Build applications with different runtimes & deploy them on Openshift
    7. Share & Discuss exercise results / Wrapup

    Agenda – day 2
    1. Recap day 1
    2. Troubleshooting & Debugging
    3. Hands-on - Troubleshooting & Debugging
    4. Backup / restore for Applications
    5. CI/CD Pipelines Introduction and Concepts
    6. Q&A for compamy specific usecases

    Zusätzliche Themen auf Anfrage
    1. Coolstore Example (Microservice application showing different concepts and languages)
    2. Operator Framework
    3. Application Monitoring with Prometheus
    ▸ Deploy Prometheus and Grafana
    ▸ Monitoring of a Spring Boot application

    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.

    Ort: Dediziert bei dir (oder an unseren Standorten in Bern/Zürich)
    Kosten: auf Anfrage
    Kontakt für Rückfragen: hello@appuio.ch, Anna Pfeifhofer
    weiterlesen
    Apr
    11

    Ein kurzer Rückblick auf das erste beerup von APPUiO

    Beerup Am 28. März fand das erste beerup von APPUiO in der Rüsterei in Zürich statt. Dabei durften wir von den Inputs und Ideen unserer APPUiO Community profitieren und das Beisammensein bei einem Bier geniessen.

    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.

    Roundtable Beerup1 Doch wie geht es nun weiter?

    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!

    Du hast noch einen Input oder eine Idee aber konntest diese nicht mitteilen?
    Wir sind jederzeit glücklich über euer Feedback. Schreib uns einfach und lass es uns wissen.

    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!

    weiterlesen
    2018
    August
    3

    Backup Service auf APPUiO - Beta Version

    Der Backup Service auf APPUiO geht in die Beta Version.

    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.

    weiterlesen
    Mai
    16

    APPUiO an den DevOpsDays 2018

    APPUiO and den DevOpsDays Zürich 2018 "Als Teil der weltweiten DevOps-Bewegung werden die DevOpsDays regelmässig in verschiedenen Ländern durchgeführt. Am 2. und 3. Mai 2018 fand die Konferenz bereits zum zweiten mal in der Schweiz statt und APPUiO präsentierte vor Ort an einem Stand die Weltneuheit \"APPUiOli\"."

    "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!

    APPUiO and den DevOpsDays Zürich 2018 APPUiO and den DevOpsDays Zürich 2018
    weiterlesen
    Mai
    1

    Amazee.io und APPUiO

    Amazee.io "Amazee.io bietet in über 16 Ländern basierend auf APPUiO eine Drupal-Webhosting-Plattform mit Microservices an. Die Zusammenarbeit seit der ersten Stunde basiert auf gemeinsamen Werten und hohen technologischen Ansprüchen."

    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

    weiterlesen
    Apr
    6

    Adcubum’s success story with APPUiO

    Adcubum "Adcubum, the leading Swiss producer of standard software for the insurance industry, began offering its adcubum SYRIUS software in 1997. Now, 20 years later, the software is being transferred to Red Hat’s OpenShift with the help of APPUiO."

    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

    weiterlesen
    Mar
    14

    APPUiO an den Voxxed Days 2018

    APPUiO and den Voxxeddays in Zürich 2018 "Am 8. März 2018 trafen sich rund 400 Entwickler an den Voxxed Days in Zürich. APPUiO unterstützt die Konferenz seit Beginn und empfing die Teilnehmenden dieses Jahr mit einem Photobooth."

    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!

    APPUiO and den Voxxeddays in Zürich 2018 APPUiO and den Voxxeddays in Zürich 2018
    weiterlesen
    Feb
    28

    Neu bei APPUiO: Betreibe jegliche Art von Service

    Von Beginn an unterstützt APPUiO dank OpenShift jegliche Art von Applikationen. Neu ist sogar der Zugriff vom Internet via TCP oder UDP auf die Services möglich.

    „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.

    weiterlesen
    2017
    Okt
    4

    APPUiO is proud to be mentioned in the ebook "The State of the Kubernetes Ecosystem"

    Kubernetes emerged from a need to run cloud-native applications on a massively scaled network. APPUiO includes Kubernetes as a distribution and is therefore mentioned in the ebook "The state of the Kubernetes Ecosystem".

    APPUiO as Kubernetes Distributor

    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.

    weiterlesen
    Aug
    17

    Introduction to OpenShift on Exoscale

    OpenShift is to Kubernetes similar to what a Linux distribution is to the kernel. In this blogpost we show how to integrate OpenShift on Exoscale

    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:

    continuous process

    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
          APPUiO PHP Demo
      
    • 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.

    weiterlesen
    Jul
    14

    One Year of Techlabs in Retrospect

    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)

    APPUiO OpenShift S2I Deployment Pipeline

    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

    weiterlesen
    Feb
    27

    2-Day-Training: From Zero to Hero with Microservices

    March 22 and March 23 2017 at VSHN AG, Neugasse 10, Zürich

    From Zero to Hero with Microservices

    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

    weiterlesen
    Feb
    13

    Mini Techlabs at the Voxxed Days

    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/

    weiterlesen
    Jan
    13

    New APPUiO Pricing

    Good news for 2017.

    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

    weiterlesen
    2016
    Nov
    1

    APPUiO Launch Event

    Wir feiern den Launch unserer Enterprise Container Platform. Kommen Sie vorbei, um mehr über APPUiO zu erfahren oder auch gleich live zu testen.

    APPUiO Launch Party

    Zusammen mit unserem Partner VSHN laden wir zum APPUiO Launch Event ein. Feiern Sie mit uns am 23. November 2016 den Start der Schweizer Enterprise Container Plattform.

    Agenda

    • 17:30 – Empfang
    • 18:00 – Was ist/kann APPUiO und wer steckt dahinter?
      • Joint Venture Puzzle & VSHN
      • Was ist APPUiO?
      • Deep dive OpenShift, Docker, Kubernetes
      • APPUiO aus Business-Sicht
    • 19:00 – Apéro riche

    Location & Anmeldung

    Der Anlass findet im Office Business Center an der Europaallee 41 in Zürich statt. Wir bitten um Ihre Anmeldung und freuen uns, mit Ihnen zu feiern.

    weiterlesen
    Sep
    13

    APPUiO goes live

    The Swiss container platform APPUiO is set to launch three new offers. Aside from Public PaaS, the platform will also be operated as a private Cloud or integrated into the client?s infrastructure. APPUiO is based on modern open source concepts such as Docker and Kubernetes and is operated via ISO-certified and FINMA-audited data centers in Switzerland.

    After a three-month beta phase APPUiO is now available to all developers and companies. With APPUiO, applications can be developed quickly and Container workloads can be run. Puzzle ITC and VSHN DevOps experts are two of the driving forces behind APPUiO, who help their clients to successfully realize concepts such as Continous Integration and support deployment.p>

    Headed to DevOps

    On the basis of proven Open Source concepts such as Docker and Kubernetes APPUiO allows for applications with standardized components to be developed and run in scalable maner. With this platform IT processes are automated and delivery of IT services is streamlined. Applications can be operated both in the Public Cloud, internally, or also in a hybrid Cloud environment. The use of Docker-concepts opens up new perspectives for the development and operation towards DevOps

    Start with Tech Labs

    Those interested can gain initial experience with this platform in free Tech Labs. In a hands-on manner you will learn first steps, how applications are brought to Cloud, and how to deploy and operate applications into PaaS. Anyone who registers for the platform by the end of November will also be able to profit from a special promotion

    weiterlesen
    Sep
    12

    APPUiO & OpenShift Tech Labs in Bern and Zürich

    Platform as a Service (PaaS) changes the way we develop software. Puzzle presents OpenShift V3 - the Container Platform by Red Hat - in a Tech Lab.

    Participants will learn key steps in a hands-on manner, learning how applications are deployed to the cloud, as well as how a container on a PaaS can be deployed und operated. additional information and registration

    weiterlesen