Blog

2019
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

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 NooBaa übernehmen. Gründe für diesen Wechsel seien insbesondere das beachtliche Momentum hinter der Entwicklung von Rook sowie der aus Sicht Red Hat zunehmende Fokus auf Object Storage, welcher von NooBaa in Form einer S3-kompatiblen API abgedeckt wird. Wie auch schon bei Version 3 werden ein Independent sowie ein Converged Mode angeboten. OCS kann also als externer Storage Cluster oder aber direkt auf OpenShift selbst installiert werden. Anders als beim Gluster-Heketi-Stack soll neu der Storage via CSI (Container Storage Interface) angebunden werden können.

    Geplant ist, OpenShift Container Storage 4 mit OCP Version 4.2 zu veröffentlichen, welches wiederum in Q3 2019 geplant ist. OpenShift Container Storage 3.X soll noch bis Juni 2022, gleich wie OpenShift Container Platform 3.X, 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 Delivery 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
    Mai
    23

    Was Arcades, gelbe Socken und Container gemeinsam haben

    DevOps Am 14. und 15. Mai 2019 fanden die DevOpsDays 2019 in Spreitenbach statt. APPUiO war als Platin-Sponsor und einem eigenen Stand vertreten. Aber was hat das alles nun mit Arcades, gelben Socken und Container zu tun? Erfahrt mehr in diesem Blogpost.

    Montag, 13. Mai, mittags
    Der Bus («Danke YOKKO») ist bereit, die Reise nach Spreitenbach in die Umweltarena anzutreten. Das Ziel: Die DevOpsDays 2019. Bepackt mit lauter gelben Sachen trifft sich das APPUiO-Team in Zürich. Nun heisst es: anpacken, aufbauen und schlussendlich...sich freuen.

    DevOps1

    Montag, 13. Mai, abends
    «Yes it's done» - Unser APPUiO-Stand steht bereit für die nächsten zwei Tage. Alle halfen mit viel Fleiss und Liebe zum Detail den Stand zu schmücken und für die Teilnehmenden interessant zu gestalten. Das buntgemischte APPUiO-Team aus VSHNers und Puzzlers gibt dem Stand wahrscheinlich das gewisse Etwas. Das Ergebnis lässt sich jedenfalls zeigen.

    DevOps2

    Dienstag, 14. Mai, morgens
    Das Team wartet gespannt auf die Gäste und verleiht dem Stand den letzten Schliff, damit die Teilnehmenden ein optimales APPUiO-Erlebnis geniessen können. Zwei Arcades stehen für die anstehenden Battles bereit. Im Gewinner-Pot liegen Vouchers von APPUiO und cloudscale.ch und eine Lego Saturn V Rakete. Weiteres Spielvergnügen bietet der Retro-Rohrfernseher mit der angeschlossenen Nintendo 64. Auf der gemütlichen Sofaecke lässt es sich verweilen, sich austauschen oder die Präsentationen verfolgen.

    Bereits vor den ersten Präsentationen wagen sich einige Teilnehmenden in die Höhle der Arcade-Löwen und wollen den Highscore erreichen. Begeisterung zeigen die Besucher auch für unser APPUiOli. In Gesprächen erfahren sie zudem mehr über APPUiO, die nächsten Etappen und Ziele.

    DevOps3 DevOps4 DevOps5

    Dienstag, 14. Mai, abends
    Der erste Tag ist geschafft! Bei einem Bier, einem super Apéro und tollen Gesprächen lässt sich der Tag wunderbar ausklingen. Das Team durfte viele neue Kontakte knüpfen und freut sich über das grosse Interesse an APPUiO. Auch unsere Community war stolz vertreten, viele der Community-Mitglieder besuchte APPUiO am Stand. Dabei merken wir, wie gross die Community von APPUiO bereits geworden ist. Dies lässt auf weitere gemeinsame Innovationen und coole Events hoffen. Wir freuen uns, auf das, was kommt!

    DevOps6

    Mittwoch, 15. Mai, mittags
    Neuer Tag, neues Glück? Das denken sich wahrscheinlich auch einige der Besucher und wagen erneut ein Arcade-Battle. Für die APPUiO-Sockenträger unter den Besuchern gibt es eine kleine Überraschung: Als Merci für ihre Treue erhalten sie ein Mandelbärchen. ...und wer nicht Süsses mag, kann auch Saures haben… Die Gummibärchen im APPUiO-Style helfen nicht nur bei den Spielbattles als Nervennahrung, sondern auch unserem Markus Speth. Der APPUiO-Marketingexperte darf am Nachmittag in einem Pitch APPUiO vorstellen.

    DevOps7

    Mittwoch, 15. Mai, abends
    Auch dieser Tag geht langsam zu Ende. Als Krönung werden die drei Gewinner des Arcade-Wettbewerbs - Alvise Dorigo, Michael Gerber und Carlo Speranza - geehrt. Müde aber zufrieden verabschiedet das APPUiO-Team die letzten Besucher. Nach der kurzen aber intensiven Aufräumaktion finden dann auch die «APPUiOler» den Weg nach Hause. Wir bedanken uns ganz herzlich für die tollen Bekanntschaften, spannenden Gesprächen und für euren Besuch an unserem Stand. Es hat uns einen Riesenspass gemacht! Und wir freuen uns, wenn es wieder heisst: DevOpsDays 2020!

    DevOps8 DevOps9

    Und falls du Nervennahrung brauchst, kalte Füsse hast oder deinen Laptop in APPUiO-Style aufpimpen willst, dann meld dich bei uns. #APPUiOGummibärchen #APPUiOSocken #Stickers ;-)

    Bis dann!

    DevOps10
    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 der Community bieten? Wie können wir noch mehr voneinander profitieren? Denn ihr wisst: Zusammen sind wir stärker, können Grosses in der IT-Welt erreichen und gemeinsam macht es einfach mehr Spass :-)

    Das erste beerup hat am 28. März im Anschluss an dem OpenShift RoundTable 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 das Feedback 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 jetzt schon über die weitere Entwicklung von APPUiO freuen!
    Du hast noch einen Input oder eine Idee aber konntest diese nicht mitteilen?
    Wir freuen uns jederzeit über euer Feedback. Schreib uns einfach und teile uns mit, wie wir APPUiO weiter verbessern können.

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

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

    weiterlesen
    2018
    Nov
    13

    OpenShift Betriebsschulung

    APPUiO Schulung zum Betrieb von OpenShift Neu: APPUiO bietet Schulungen zum Betrieb von OpenShift an. Sie ist für Betreiber einer Openshift Plattform gedacht, die sich praktische Inputs und Erfahrungsberichte in Sache Betrieb wünschen.

    Der Hype um OpenShift ist aktuell sehr gross und die Vorteile einer solchen Plattform kennen mittlerweile die meisten ITler - schneller am Markt, einheitlich und offen, fördert die Collaboration und vereinfacht den Softwareentwicklungsprozess. Doch eine neue Plattform bringt auch neue Herausforderungen und die Integration in ein Unternehmen (Prozesse und Kultur) ist nicht immer so einfach. Eine neue Technologie verlangt auch nach zusätzlichem Know-How auf Seiten der Infrastruktur Betreiber/Engineers und der Entwickler.

    Wir nutzen seit 4 Jahren OpenShift und konnten dabei viele Erfahrungen in diesem Bereich sammeln.
    Ganz nach dem Motto unserer ganzen Community «Wissen ist am besten, wenn es geteilt wird» möchten wir unsere Erfahrungen und Best practices nicht nur an Meetups sondern neu auch in Form einer Schulung weitergeben. Denn gemeinsam sind wir stärker und können mehr bewegen!

    In einem ersten Schritt bieten wir eine zweitägige Schulung für den Betrieb einer OpenShift Plattform an. Dabei lernen die Teilnehmer hands-on, auf einer eigenen AWS Testplattform, praktische Tricks und mögliche Lösungen für Probleme im Alltag. Zusätzlich gehen wir auf die Spezialitäten der eigenen Plattform ein.

    "Die Schulung war genau auf unsere Bedürfnisse angepasst und die Bespiele waren gut verständlich. Gefallen hat uns vor allem, dass es eher in einer Art Workshop abgelaufen ist und der Teacher auf unsere Fragen eingegangen ist und diese auch beantworten konnten. Wir können die Schulung jedem empfehlen, der eine OpenShift Plattform betreiben will." - Matthias Summer, Teilnehmer einer vergangenen OpenShift Betriebsschulung.

    Die APPUiO-Schulung gilt als Ergänzung zur Red Hat Schulung. Wir setzen unseren Fokus auf die praktische Anwendung im Daily Business (Updates, Konfigurationen, Problemumgang, Monitoring etc.).

    Der Inhalt der Schulung

    1. Warmup, Kennenlernen der Testumgebung
    2. OpenShift Installation, wie wird/wurde installiert
    3. Daily Business, u.a.
    • manage Users
    • Update Hosts
    • Persistent Storage
    • Renew Certificates
    • Add New OpenShift Node and Master
    4. Configuration Best Practices
    5. Backup and Restore
    6. Monitoring and Troubleshooting
    7. OpenShift Upgrade, OpenShift und OS gefahrlos auf den neusten Stand bringen

    Die Schulung ist für Betreiber einer Openshift Plattform gedacht, die sich praktische Inputs und Erfahrungsberichte in Sachen Betrieb wünschen. In naher Zukunft werden wir auch Schulungen für OpenShift Entwickler anbieten, wobei Themen wie CI/CD, 12 Factor Apps etc. im Zentrum stehen. Weitere Infos folgen.

    Die OpenShift Betriebsschulung wird bis max. 8 Teilnehmer durchgeführt. Auf Anfrage ist eine Durchführung auch für ganze Gruppen dediziert und bei dir am Standort möglich.

    Ort: Dediziert bei dir (oder an unseren Standorten in Bern/Zürich)
    Kosten: auf Anfrage
    Kontakt für Rückfragen: hello@appuio.ch, Tobias Tröhler

    Wir freuen uns auf deine Kontaktaufnahme!

    weiterlesen
    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 und APPUiO

    Adcubum Seit 1997 bietet Adcubum als führender Schweizer Hersteller von Standardsoftware für die Versicherungswirtschaft die Software adcubum SYRIUS an. Rund 20 Jahre später wird die Software nun mit Hilfe von APPUiO auf OpenShift von Red Hat transferiert.

    Unflexibilität, hohe Koordination und technische Herausforderungen: „2016 merkten wir, dass die Konfiguration von mehreren Applikationen in der damaligen Umgebung sehr komplex war“, erklärt Matthias Summer, Senior System Engineer bei Adcubum. Nach intensiver Recherche nach Lösungen stand fest: „Wir wollen OpenShift von Red Hat nutzen“. Mit APPUiO habe man sogar einen Partner gefunden, der noch viel mehr bietet. „Erfahrene Experten, die sich tagtäglich mit OpenShift auseinandersetzen, haben die Plattform hier bei uns im Haus aufgebaut und uns geschult”, so Summer. Gemeinsam mit seinem Team von insgesamt fünf System Engineers betreibt Summer rund 500 Testinstallationen von adcubum SYRIUS. „Dank APPUiO können wir nun auf Knopfdruck Testumgebungen deployen“, sagt Summer.

    Bis Ende 2018 möchte Adcubum 95 Prozent der Entwicklungs- und Testinstanzen auf OpenShift zum Laufen bringen. Die Herausforderung liegt dabei darin, eine 20 Jahre alte Applikation mit mehreren Millionen Zeilen Code für die neue Container Plattform aufzubereiten. Obwohl der Aufwand gross ist, sieht Summer nur Vorteile: „Da wir in Zukunft auf einer einzigen Plattform arbeiten, verbessert sich die Zusammenarbeit zwischen Entwicklung und Betrieb massiv. Zudem werden wir effizienter.“ Profitieren können auch die Kunden wie beispielsweise Helsana, Concordia, Visana und SUVA. Sie könnten zukünftig (frühestens ab 2019) adcubum SYRIUS auch in Form von Containern erhalten und diese auf ihrer eigenen OpenShift Installation betreiben. “Die Entwicklungsplattform der Kunden ist dann identisch mit unserer. Dadurch können Updates automatisch und viel häufiger durchgeführt werden”, erklärt Summer.

    Seit Ende 2017 läuft adcubum SYRIUS auf der OpenShift Container Plattform APPUiO. „Nun möchten wir auch unsere Kunden von OpenShift begeistern“. Dabei setzt Adcubum auf die enge Partnerschaft mit 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
    Dez
    13

    Happy Birthday, APPUiO!

    Rund 80 geladene Gäste feierten Ende November das einjährige Jubiläum von APPUiO im Bogen F in Zürich. Nebst spannenden Kundencases blickten wir auf ein bewegtes erste Jahr zurück und enthüllten die neusten Features der Container Plattform. Abgerundet wurde der Nachmittag mit einer heissen Suppe passend zum Schneegestöber vor der Tür, einer süssen Geburtstagstorte und dem einen oder anderen Bier.

    „In kurzer Zeit haben wir viele verschiedene Unternehmen aus unterschiedlichen Branchen für APPUiO begeistert. Wir sind sehr zufrieden mit dieser Entwicklung und sehen weiterhin grosses Potenzial“, sagt Thomas Philipona, Gründungsvater von APPUiO, vor den geladenen Gästen am Jubiläumsevent in Zürich. Das Angebot von APPUiO wurde im vergangenen Jahr optimiert. So gibt es attraktive Angebote für Entwickler, die kurzfristig standardisierte Entwicklungsumgebungen in der Cloud suchen, aber auch für Kunden, die eine eigene OpenShift-Plattform nutzen und dabei nichts mit dem Setup und dem Betrieb zu tun haben wollen. „Hier stehen wir gerne als OpenShift-Experten mit unserem Know How zur Verfügung.“

    Neue Features

    Im vergangenen Jahr wurden diverse neue Features entwickelt. Es wurde beispielsweise ein Self Service Portal lanciert, über das die Projekte auf Knopfdruck angelegt, vergrössert, gelöscht und verwaltet werden können. Die Kosten der Public Platform werden stündlich berechnet und man bezahlt nur, was auch effektiv genutzt wurde. Zudem wurde eine hybride Cloud mit Cluster auf AWS integriert und verschiedene Managed Services wie 3Scale ins Angebot aufgenommen. Der Austausch in der Community wird mit diversen Events unter Gleichgesinnten sowie einem direkten Draht zum APPUiO-Team über den Community Chat gefördert.

    Die Container Plattform wird auch in Zukunft stetig weiterentwickelt: Das Bezahlen mit Kreditkarte, TCP (non-HTTP) Services, Database as a Service, Two-Factor Authentication, Hybrid Migrationen des Workloads, Monitoring as a Service, Backup as a Service, ein Start-up-Pricing sowie weitere interessante Features sind geplant und können in der Roadmap aktiv mitgestaltet werden.

    Spannende Kundencases

    Praxisnah und an konkreten Beispielen orientiert, präsentierten HRM Systems AG, Adcubum AG und Amazee.io, wie sie APPUiO in ihrem Unternehmen einsetzen. Alle Präsentationen des Nachmittags können hier angeschaut werden.

    Einblick in den spannenden Nachmittag gibt es auch hier: Fotos, Video

    weiterlesen
    Okt
    13

    Continuous Delivery Pipelines auf APPUiO

    "The only thing we know about the future is that it will be different." - Peter Drucker

    Continuous Integration, Continuous Deployment und Continuous Delivery sind sehr populäre Begriffe in Zeiten von DevOps, der agilen Software Entwicklung und der Digitalisierung. Die genaue Bedeutung und Definition werden immer noch im Internet diskutiert. Mit diesem Blogpost möchten wir euch den Begriff Continuous Delivery näher bringen und euch aufzeigen, wie wir zusammen mit verschiedenen Kunden auf APPUiO den ganzen Prozess komplett automatisiert haben. Die Kunden sind nun in der Lage ihren Code, ihre Features und Bugfixes innerhalb von kürzester Zeit automatisch zu testen und in die Produktion zu deployen.

    "Early and continuous delivery" von wertbringender Software - so definierte das Agile Manifesto (eine Verkündung der 12 Prinzipien der iterativen Softwareentwicklung) bereits 2001 die Zufriedenstellung des Kundens. Der Begriff Continuous Delivery steht für einen komplexen Ablauf, welcher voll automatisiert und auf Wunsch per Knopfdruck ausgeführt werden soll. Continuous Delivery soll helfen, neue Features, Konfigurationen oder Bugfixes schnell und sicher in die Produktion zu bringen. Dies erlaubt ein frühes Feedback vom Kunden und dadurch eine schnelle Reaktion auf veränderte Marktanforderungen. Der komplette Releaseprozess soll automatisiert ablaufen und dadurch reproduzierbar und auditierbar werden. Automatisierte Tests sollen dabei helfen, Fehler früh zu erkennen und zu beheben. Continuous Delivery heisst also schneller am Markt zu sein, Inhalte eines Releases zu verkleinern und dadurch das Risiko zu reduzieren. Höhere Qualität, weniger Kosten, ein besseres Produkt und glücklichere Teams sind das Resultat.

    Continuous Delivery hat folgende Eigenschaften:

    • Vollständige Automatisierung der gesamten Pipeline vom Auschecken des Codes bis zum Deployment in die Produktion, um alle Arten von Changes, Features, Bugs, Configuration Changes etc. zuverlässig, sicher und schnell den Benutzern zur Verfügung zu stellen. Einzig die Freigabe für die Produktion wird manuell gemacht zwecks zusätzlicher Kontrolle.
    • Jeder Commit der die CI-/CD-Pipeline erfolgreich durchläuft ist ein potentieller Release.
    • Im Gegensatz zu Continuous Deployment wird der Schritt vom Deployment in die Produktion manuell per Knopfdruck ausgelöst. So kann aus fachlicher oder technischer Sicht entschieden werden, welcher Release wann in Produktion geht. Im Rahmen von Continuous Deployment werden sämtliche potentielle Releases direkt und vollautomatisch in Produktion überführt. Konzepte wie Canary Releasing, Rolling Update, Blue-Green Deployment müssen in hochverfügbaren Umgebungen umgesetzt werden.
    • Möglichst identische Umgebungen für Entwicklung, Testing, Integration und Produktion.
    Weiterführende Informationen findet ihr im Buch von Jez Humble “Continuous Delivery” oder auf seiner WebPage continuousdelivery.com.

    Vorteile von Continuous Delivery

    Weniger manuelle Tasks, geringere Kosten: Durch die Automatisierung des Releaseprozesses braucht es nicht mehr Stunden, um Code zu paketieren, in die Stages du deployen und manuell zu testen. Diese Schritte werden auf Knopfdruck ausgeführt und reduzieren den Aufwand massiv.

    Kürzere Reaktionszeiten/Time-to-Market (schnelleres Feedback, "Fail-fast"): Continuous Delivery (CD) bietet uns die Möglichkeit, täglich Features bis in die Produktion einzuspielen. Daher müssen wir nicht mehr auf ein Wartungsfenster in ferner Zukunft warten. Wir sind mit Neuigkeiten schnell am Markt, schaffen uns einen Marktvorteil, erkennen Fehler viel früher und erhalten zeitnah Rückmeldung von unseren Kunden.

    Risikominimierung durch kleinere Releases und automatisierte Tests: Wie z.B. der DevOps Report von Puppet empirisch nachweist, sind die Risiken durch Continuous Delivery massiv kleiner. Kleine, mehrmals täglich ausgerollte Releases, die Möglichkeit, schnell auf Probleme reagieren zu können sowie die gut dokumentierten Änderungen minimieren das Risiko drastisch. Früh erkannte Fehler sind schneller zu beheben und daher oft weniger schmerzhaft.

    Reproduzierbarkeit dank Infrastructure as Code: Durch die Automatisierung ist jede Änderung dokumentiert und kann zu jederzeit rückgängig gemacht werden. Die Infrastruktur, der Code, wird aus einem Repository gebuildet und ist daher versioniert.

    Kundenzufriedenheit steigt: Weil bereits kleinste Änderungen dem Kunden zur Verfügung gestellt werden können, kann sein Feedback kontinuierlich in die Entwicklung einfliessen. Daher erhält dieser zum Schluss auch wirklich sein gewünschtes Produkt.

    Collaboration: Die Automatisierung des Release-Prozesses ist essentiell und die Probleme bei der Auslieferung von Features haben einen wesentlichen Beitrag zur Entstehung des DevOps-Modells geliefert. Die teamübergreifende Zusammenarbeit kann wesentlich verbessert werden, was Reibungspunkte in Firmen reduziert.

    Mehr Qualität, weil Bugs frühzeitig erkannt werden: Durch die automatisierten Tests (Integration, Acceptance etc.) können Fehler früher erkannt und noch bevor diese in der Produktion ankommen behoben werden. Dadurch sinkt das Risiko und die Qualität steigt.

    Umgebungen können einfach zusammengeschlossen werden: Wie im folgenden Beispiel gezeigt wird, können auf APPUiO die verschiedenen Stages sehr einfach zusammengeschlossen werden. Neue Features und Bugfixes müssen nicht mehr aufwendig auf die verschiedenen Umgebungen manuell kopiert werden.


    Wie wird es gemacht? Beispiele anhand von APPUiO

    Um eine Continuous Delivery Pipeline aufzusetzen und von diesen Vorteilen zu profitieren bietet APPUiO einige Werkzeuge. Mit der OpenShift Container Platform Version 3.4 wurden integrierte Build und Delivery Pipelines eingeführt. Diese technische Neuerung erlaubt es uns, Build- und Delivery-Pipelines direkt in APPUiO zu integrieren und so die volle Flexibilität und Power einer auf Jenkins basierenden Build-Infrastruktur per Knopfdruck - quasi as-a-Service - zu beziehen. Im Gegensatz zum Source to Image (S2I)-Buildverfahren, bei dem der Applikationssourcecode im Rahmen eines einzigen Steps in ein Docker Image verpackt wird, haben wir mit Pipelines die Möglichkeit, deutlich komplexere Abläufe, wie sie in der Realität oft vorkommen, zu implementieren.

    So beinhaltet bei uns eine typische Pipeline die folgenden Schritte:


    • Source Code kompilieren, Codeanalyse und Unit-Tests

    • Integrationstests und Paketierung (Docker Image, Java Archive)

    • Deployment auf eine Dev-Umgebung

    • Automatisierte Tests gegen dieses Deployment

    • Deployment auf Test-Umgebung

    • Systemtest

    • Deployment auf Produktion

    • Smoketests

    Konkret werden sogenannte Jenkins Pipelines als Teil des Source Codes resp. direkt als Teil der Buildconfig der Pipeline als sogenanntes Jenkinsfile konfiguriert. Beim Erstellen eines solchen Pipeline Builds startet OpenShift dynamisch einen Jenkins und führt die Pipeline darin aus. Benötigte Buildnodes (bspw. Nodejs, Maven, Ruby,...) können dynamisch als Buildnodes in der Pipeline angegeben werden. Sie werden direkt via Jenkins bei Bedarf über den Imagestream referenziert, als Pod deployed und als Step ausgeführt. Die Integration der Pipeline direkt in APPUiO sieht dann wie folgt aus:


    continuous process

    Und die analoge Ansicht im integrierten Jenkins:


    continuous process

    Auch hier sind die Vorteile vielfältig:

    • Sehr gut integriert, Frontend und Backend, Pipelines können auf OpenShift-Ebene direkt kommunizieren.

    • Buildnodes als Imagestream im OpenShift-Projekt

    • Secrets werden direkt übernommen, Berechtigungen um Builds und Deployments auf OpenShift auszuführen sind vorkonfiguriert.

    • Möglichkeit Pipelines stateless zu implementieren, also keine komplexen Buildjobs auf dem Jenkins Master einrichten

    • Volle Flexibilität von Jenkins Pipelines, beliebige Workflows implementierbar

    In einem technischen Blogpost werden wir zu einem späteren Zeitpunkt konkret aufzeigen, wie Pipelines in APPUiO integriert werden. Unter https://github.com/appuio/simple-openshift-pipeline-example haben wir eine simple Beispiel-Pipeline abgelegt.

    Herausforderungen von Continous Delivery

    Organisation und Kultur: APPUiO bietet ein Tooling für die Automatisierung des Releaseprozesses und ist ein wichtiger Teil in dieser schnelllebigen IT-Welt. Eine solche Veränderung hat aber auch Einfluss auf eine Organisation in einem Unternehmen und auf dessen Kultur. Jahrelang wurden Firmen nach Silos aufgeteilt und jeder Mitarbeiter hatte seine spezifische Aufgabe. Nun ist die teamübergreifende Zusammenarbeit gefragt, T-Shaped Engineers, Infrastructure-as-Code usw. Der Mensch ist ein Gewohnheitstier und hat Mühe mit Veränderungen. Daher muss bei einer solchen Umstellung auch ein spezielles Augenmerk auf die Kultur gelegt werden. Ein kultureller Wandel benötigt Zeit.

    ISO-Standards, standardisierte Prozesse und Compliance sind wichtige Themen in einem Unternehmen. Dadurch sind auch der Release- und Change-Prozess betroffen. Wie soll es möglich sein, täglich Releases in der Produktion einzuspielen, wenn deren Freigabe Tage dauert? Prozesse und deren Abläufe müssen, wie der Rollout selber, automatisiert und vereinfacht werden.

    Technische Umsetzung (CI/CD ToolChain, Software Architektur): Die sogenannte CI-/CD-Toolchain wird mit APPUiO mitgeliefert. Doch die technische Umsetzung betrifft auch die Applikation, welche auf APPUiO deployed werden soll. Eine Legacy Software, die nur manuell updatet werden kann, eignet sich wohl eher weniger für ein Continuous Delivery. Das 12 Factor App Manifest kann hier helfen die wichtigsten Punkte für die Entwicklung einer cloudfähigen Applikation zu berücksichtigen.

    Automatisierte Tests können den manuellen Aufwand massiv reduzieren und die Qualität steigern. Doch Integration und End-to-End Tests zu automatisieren kann aufwendig sein und sie müssen, zum Teil, mit den Änderungen am Code angepasst werden. Die Frage stellt sich auch immer, wie kann ich diese Tests automatisieren und habe ich an alle Test Cases gedacht.

    Fazit

    Wie bereits Peter Drucker erläutert hat, ist die einzige Konstante in der Zukunft die Veränderung. Die heutige Zeit verlangt nach Agilität und schnellem Feedback. Auf Marktveränderungen muss in kurzer Zeit reagiert werden können. Für die IT ist es deshalb wichtig, Anpassungen und neue Features in kurzer Zeit in die Produktion bringen zu können - ohne dass die Qualität darunter leidet.

    Durch Continuous Delivery werden nicht alle Problemfelder beseitigt, die benötigt werden, um mit der Geschwindigkeit der heutigen Zeit standhalten zu können. Ein wichtiger Teil ist auch die Kultur in einem Unternehmen, die Zusammenarbeit und die Architektur der Software. Wir unterstützen euch gerne bei der Integration von Pipelines auf APPUiO oder bei der Automatisierung und Standardisierung eures Entwicklungsprozesses. Auch im Bereich Kultur, DevOps, der Zusammenarbeit in einem Unternehmen oder der Software Architektur haben wir über die Jahre viel Erfahrung gesammelt und geben diese sehr gerne weiter.

    weiterlesen
    Okt
    10

    Serverless Computing / Functions as a Service mit APPUiO und Snafu

    Was ist Serverless, auch FaaS (Function as a Service) genannt?

    Die Begriffe "Serverless" und "FaaS (Function as a Service)" werden in jüngerer Zeit immer öfter in Artikeln erwähnt. Um was geht es eigentlich bei diesem Thema? Unter "FaaS" versteht man die Möglichkeit, eine Programmfunktion "in der Cloud" zu betreiben. Dabei speichert der Entwickler die gewünschte Funktion (egal in welcher Programmiersprache abgefasst, so lange vom Anbieter unterstützt) im FaaS Service der Wahl und ruft diese z.B. über HTTP oder einen Servicebus auf. Dabei muss der Benutzer der Funktion sich weder um die Ausführungsumgebung, Skalierung noch die Konfigurationsdetails eines Applikationsservers kümmern. Daher kommt auch der Begriff "Serverless", welcher sagen möchte, dass die Funktion "einfach läuft", sozusagen ohne Server. Eine Funktion kann eine einfache "Eingabe-Verarbeitung-Ausgabe" Funktion sein, komplexe Berechnungen durchführen oder Daten aus anderen externen Diensten beziehen, verarbeiten und speichern.

    Der Einsatz von FaaS macht vor allem dann Sinn, wenn es sich um eine spezialisierte Funktion handelt, welche von diversen Microservices verwendet wird. Auch ökonomisch lässt sich der Einsatz von Funktionen in der Cloud gut begründen: Bezahlt wird für der einzelne Funktionsaufruf (je nach Anbieter). Wird die Funktion nicht genutzt, fallen auch keine Kosten an. Dies ist ein "echtes" Cloud Modell, ganz im Sinne von "Pay per Use".

    Unser Beitrag mit APPUiO und ZHAW SPLab

    Zusammen mit dem ZHAW Service Prototyping Lab (SPLab) arbeiten wir im Rahmen eines KTI (Kommission für Technologie und Innovation) Projekts unter dem Namen "MOSAIC" an Lösungen rund ums Thema FaaS auf APPUiO. Neben einigen Papers (verlinkt im Blogpost von SPLab "Snafu – The Swiss Army Knife of Serverless Computing") entstand auch ein neues Open Source Projekt: snafu - Snake Functions. The Swiss Army Knife of Serverless Computing. Das Projekt bietet nebst einer lokale Entwicklungsumgebung auch eine Ausführungsumgebung, um Funktionen auf APPUiO zu betreiben. Dabei lassen sich auch Funktionen z.B. von AWS Lambda, Google Cloud Functions oder OpenWhisk importieren und exportieren. So hilft das Tool sowohl beim Entwickeln von Funktionen für die Cloud als auch bei deren Betrieb.

    Serverless Tools

    Natürlich gibt es nicht nur Snafu. Es sind mittlerweile eine ganze Reihe von Kandidaten am Markt:

    Erst vor kurzem hat sich Red Hat für Apache OpenWhisk entschieden, wie sie in einem Blogpost darlegen: Red Hat and Apache OpenWhisk. Der Plan ist, OpenWhisk als Bestandteil von OpenShift zu integrieren. Es bleibt definitv spannend auf dem Markt, welchen wir sehr nahe verfolgen. Unser Ziel ist es, Funktionen in der Cloud auf APPUiO anbieten zu können und das mit dem passenden Werkzeug.

    Snafu - Swiss Army Knife of Serverless Computing

    Snafu kann einerseits als lokale Entwicklungsumgebung dienen, andrerseits aber auch zum Betrieb von Funktionen auf OpenShift. Eine Besonderheit von Snafu ist die Unterstützung des Im- und Exports von Funktionen anderer Anbieter und Tools, wie z.B. AWS Lambda, Google Cloud Functions oder OpenWhisk. Es kann auch dazu benutzt werden, Funktionen zwischen verschiedenen Umgebungen zu migrieren.

    Architekturdiagramm von Snafu:

    continuous process

    Und so bekommt man Snafu auf die lokale Entwicklungsumgebung (Anleitung für Linux oder MacOS):

    1 Code clonen

    git clone https://github.com/serviceprototypinglab/snafu.git
    cd snafu
    

    2 Python Virtualenv erstellen

    python -m venv --prompt snafu pyvenv
    . pyvenv/bin/activate
    

    3 Dependencies installieren

    pip install pyesprima flask
    

    4 Snafu benutzen

    % ./snafu [-h]
    % ./snafu --executor <e> --logger <l> --convention <c>
    

    Am Beispiel der mitgelieferten Hello World Funktion:

    ./snafu --executor=inmemory --logger=csv --connector=cli functions/helloworld.py
    » module: functions/helloworld.py
      function: helloworld.helloworld
    + logger: csv
    + executor: java
    + executor: c
    + executor: javascript
    + executor: inmemory
    + connector: cli
    Function name:helloworld.helloworld
    [1503929132.298][140259308811456][function:helloworld.helloworld]
    [1503929132.298][140259308811456][response:helloworld.helloworld/[]]
    [1503929132.298][140259308811456][result:Hello, .]
    [1503929132.298][140259308811456][time:0.003ms]
    [1503929132.298][140259308811456][overalltime:0.011ms]
    Hello, .
    Function name:^C
    Terminated.
    

    In diesem Beispiel wird die Funktion helloworld.helloworld interaktiv ausgeführt und die Ausgabe nach stdout geschrieben. Die Datei snafu.csv beinhaltet nun eine Information über den Aufruf der Funktion für eine spätere Auswertung, wie z.B. zur Verrechnung.

    Snafu auf OpenShift / APPUiO

    Snafu kann in verschiedenen Modi betrieben werden. Einer davon ist die direkte Ausführung von Funktionen, welche im Filesystem gespeichert sind. Das erste Beispiel demonstriert diesen Modus, wobei die auszuführende Funktion in einer ConfigMap (Kubernetes Objekt zur Speicherung der Applikationskonfiguration) gespeichert und Snafu über einen Volume Mount zur Verfügung gestellt wird. Die Speicherung von Funktionen in einer ConfigMap ist als Proof-of-Concept zu verstehen, für einen produktiven Betrieb sind in diesem Beispiel wichtige Themen wie Source Code in Git, CI/CD Rollback, etc. nicht berücksichtigt.

    Mit folgenden zwei Schritten wird eine einfache Hello World Funktion auf OpenShift deployed:

    1 Neues OpenShift Projekt erstellen oder bei APPUiO bestellen
    2 OpenShift Template initialisieren:

    PROJECT=<myproject>
    oc -n $PROJECT process -f https://raw.githubusercontent.com/serviceprototypinglab/snafu/master/openshift/snafu-template.yaml | oc -n $PROJECT create -f -
    

    Damit ist Snafu installiert und läuft. Das Beispiel startet die Funktion helloworld.helloworld aus der ConfigMap "functions" und stellt sie auf APPUiO unter http://snafu-$PROJECT.appuioapp.ch/invoke/helloworld.helloworld zur Verfügung. Um nun eigene Funktionen zu installieren, editiert man die ConfigMap "functions" und startet den Pod neu, z.B. durch Löschen oder Auslösen eines neuen Deployments. Snafu selbst ist in der ConfigMap "config" konfiguriert.

    Ein weiterer Modus ist der sogenannte "Control Mode". In diesem verhält sich Snafu wie z.B. ein Amazon Lambda Backend und kann entsprechend mit den AWS Tools benutzt werden. Das folgende Beispiel zeigt, wie Snafu als AWS Lambda-kompatibler Dienst auf OpenShift deployed werden kann:

    1 Neues OpenShift Projekt erstellen oder bei APPUiO bestellen
    2 OpenShift Template initialisieren:

    PROJECT=<myproject>
    oc -n $PROJECT process -f https://raw.githubusercontent.com/serviceprototypinglab/snafu/master/openshift/snafu-control-template.yaml | oc -n $PROJECT create -f -
    

    3 AWS CLI verwenden

    aws configure
    # AWS Access Key ID [None]: mykey
    # AWS Secret Access Key [None]: myaccesskey
    # Default region name [None]: invalid
    # Default output format [None]:
    alias aws="aws --endpoint-url http://snafu-control-$PROJECT.appuioapp.ch"
    aws lambda list-functions
    aws lambda invoke --function-name lambda.lambda_handler --payload '{"event": "test"}' ./test.out
    cat test.out
    Hello from Lambda
    

    Weiterführende Informationen

    Hat dieser Beitrag Ihr Interesse an Serverless / Functions as a Service geweckt? Gerne beantworten wir Ihre Fragen und helfen bei der Implementation: hello@appuio.ch oder info@vshn.ch.

    Weitere Informationen zu Snafu können hier gefunden werden:



    weiterlesen
    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

    Ein Jahr Techlabs – ein Rückblick

    In 15 Techlabs konnten wir über 120 Interessierte von OpenShift begeistern.

    Seit meinem ersten Rückblick auf ein APPUiO & OpenShift Techlab sind unterdessen ein Jahr und 14 weitere Techlabs vergangen. Und wie das so ist, verändert sich in einer so langen Zeit immer ziemlich viel: OpenShift liegt mittlerweile in Version 3.5 vor und weist im Vergleich zu der damaligen Version 3.1 ein weitaus mächtigeres und intuitiveres Webinterface auf. Einiges ist in dieser Zeit aber auch gleich geblieben, unter anderem das Interesse an unseren Techlabs.

    Durch das Update von OpenShift auf die Version 3.4 hat sich bei APPUiO viel verändert. Dank des intuitiveren Webinterface ist nun vieles via Mausklick machbar. Dies setzt insbesondere die Einstiegshürde für Entwickler etwas tiefer. Dass diese Einstiegshürde aber dennoch relativ hoch ist, zeigt die Anzahl Teilnehmende und das Interesse an unseren APPUiO & OpenShift-Techlabs in Bern und Zürich. Die Entwickler besuchen unsere Techlabs nach wie vor rege und lernen dort hands-on die wichtigsten Schritte, wie eine Applikation in die Cloud gebracht wird.

    Andere Dinge sind seit einem Jahr gleich geblieben: so beispielsweise die Container-Grundkonzepte. Oder auch meine Freude, zu sehen, wie die Teilnehmenden immer wieder von Neuem über die technischen Möglichkeiten von OpdenShift begeistert sind. Auch gewisse Fragen tauchen im Rahmen der Techlabs immer wieder auf. Eine der häufigsten ist es, wie denn nun die eigens geschriebene Applikation auf OpenShift deployed werden kann. Hierfür gibt es grundsätzlich drei Möglichkeiten:

    • OpenShift erstellt mithilfe des integrierten Source-to-Image-Frameworks den Applikations-Pod aus dem reinen Sourcecode. Dabei wird automatisch erkannt, um welche Sprache es sich handelt.
    • OpenShift baut den Applikations-Pod mithilfe eines zur Verfügung gestellten Dockerfiles. Dabei wird das Docker Image zuerst gebuildet, in die interne Registry gepusht und anschliessend deployt.
    • OpenShift schnappt sich ein bereits gebuildetes Docker Image und deployt dieses. (siehe auch reference architecture)

    APPUiO OpenShift S2I Deployment Pipeline

    Beispiel eines eigens gestrickten S2I-Deployments mit vorhergehendem Build in Jenkins. Die einfachere Variante ist natürlich, ein bereits bestehendes S2I-Script zu verwenden.

    Eine ebenfalls häufig gestellte Frage ist, wie lange unsere Labs im Anschluss an den Nachmittag ausprobiert werden können: lange, sehr lange. Unsere Labs sind auf GitHub zu finden und eines unserer zusätzlichen Labs beschreibt das Einrichten einer eigenen OpenShift-Entwicklungsumgebung. Dem Ausprobieren zu Hause oder am eigenen Arbeitsplatz steht also nichts im Weg. Und natürlich freuen wir uns auch über Contributions oder Issues, damit wir das Techlab weiter verbessern können.

    Die nächsten Techlabs finden im August und September statt. Wir freuen uns über viele Teilnehmende und sind gespannt auf neue, lehrreiche Erfahrungen!

    Eckdaten Techlabs:

    APPUiO & OpenShift Techlab Bern:
    Wann: Donnerstag, 24. August 2017 ab 14:00 Uhr (Ende ca. 17:30 Uhr)
    Wo: Belpstrasse 37, 3007 Bern (3. Stock)
    Anmeldung

    APPUiO & OpenShift Techlab Zürich:
    Wann: Donnerstag, 28. September 2017 ab 14:00 Uhr (Ende ca. 17:30 Uhr)
    Wo: Neugasse 10, 8005 Zürich
    Anmeldung

    weiterlesen
    Feb
    27

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

    22. und 23. März 2017 bei VSHN AG, Neugasse 10, Zürich

    From Zero to Hero with Microservices

    In diesem Training wirst du eine voll funktionsfähige E-Commerce-Anwendung mit Microservices, Weave Net und Scope, Docker-Container und als Orchestrator APPUiO's Red Hat OpenShift v3 basiert PaaS bauen.

    Dieses Training ist eine ideale Ergänzung zu den kostenlosen APPUiO TechLabs mit mehr Zeit für fundierte Kenntnisse und Zugang zu den Top-Experten.

    Registration

    weiterlesen
    Feb
    13

    Mini Techlabs an den Voxxed Days 2017

    Die Voxxed Days Zürich kommen am 23. Februar 2017 zurück ins Sihlcity Cinema. Die gesamte Entwickler-Community trifft sich und erfährt das Neuste von inspirierenden Speaker aus der Branche.

    APPUiO ist vor Ort mit einem Stand vertreten. In Mini Techlabs zeigen wir den Teilnehmenden hands-on die wichtigsten Schritte, wie eine Applikation in die Cloud gebracht wird und wie Container auf einer PaaS deployed und betrieben werden können.

    Mehr Infos finden Sie unter voxxeddays.com/zurich/

    weiterlesen
    Jan
    13

    Neues Pricing bei APPUiO

    Gute Neuigkeiten zum Jahresauftakt

    Neu können Sie die Schweizer Container Plattform APPUiO monatlich abonnieren. Für das Public-Angebot bezahlen Sie je nach Paket zwischen 49 Franken und 340 Franken pro Monat. Beim Abschluss eines Jahresvertrags schenken wir Ihnen zwei Monate.

    Mehr Infos finden Sie hier

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

    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 geht live

    Die Schweizer Container Plattform “APPUiO” geht mit drei Angeboten an den Start. Neben der Public PaaS wird die Plattform auch als private Cloud betrieben oder in die Infrastruktur der Kunden integriert. APPUiO basiert auf modernen Open Source Konzepten wie Docker und Kubernetes und wird in ISO-zertifizierten und FINMA- auditierten Rechenzentren in der Schweiz betrieben.

    Nach einer dreimonatigen Betaphase steht APPUiO ab heute allen Entwicklern und Firmen zur Verfügung. Mit APPUiO lassen sich Applikationen einfach und schnell entwickeln oder Container Workload betreiben. Hinter APPUiO stehen mit Puzzle ITC und VSHN zwei DevOps Experten, welche ihre Kunden bei der erfolgreichen Umsetzung von Konzepten wie Continuous Integration und -Deployment unterstützen.

    Auf in Richtung DevOps

    Auf der Basis bewährter Open Source Konzepte wie Docker und Kubernetes lassen sich auf APPUiO Applikationen mit standardisierten Komponenten entwickeln und skalierbar betreiben. Mit der Plattform werden IT-Prozesse automatisiert und die Bereitstellung von IT-Services gestrafft. Applikationen können dabei sowohl in der Public Cloud, intern oder auch in einer hybriden Cloud betrieben werden. Die Anwendung der Docker-Konzepte eröffnet neue Aussichten für die Entwicklung und den Betrieb in Richtung DevOps.

    Start mit Tech Labs

    Interessierte können in kostenlosen Tech Labs erste Erfahrungen mit der Plattform sammeln. Dabei lernen sie Hands-on die wichtigsten Schritte, wie eine Applikation in die Cloud gebracht wird und wie Container auf einer PaaS deployed und betrieben werden können. Wer sich bis Ende November für die Plattform registriert, kommt zudem in den Genuss einer Promo-Aktion.

    weiterlesen
    Sep
    12

    APPUiO & OpenShift Tech Labs in Bern und Zürich

    Mit einer Platform as a Service (PaaS) ändert sich die Art, wie wir Software entwickeln. Puzzle stellt OpenShift V3 - die Container Plattform von Red Hat - in einem Tech Lab vor.

    Die Teilnehmer lernen dabei hands-on die wichtigsten Schritte, wie eine Applikation in die Cloud gebracht wird und wie Container auf einer PaaS deployed und betrieben werden können. weitere Infos und Anmeldung

    weiterlesen