Blog

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

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:



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.

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.

Jul
14

Ein Jahr Techlabs – ein Rückblick

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

Jun
30

APPUiO bringt Abacus-Applikationen in die Cloud

Schneller, exakter und sicherer: Beim Deployment von Applikationen setzt das Softwareunternehmen Abacus Research AG neu auf die Schweizer Container Plattform „APPUiO“. Innerhalb weniger Monate wurden damit knapp zehn Applikationen in die Cloud gebracht – das sind drei Mal so viele wie mit den bestehenden, klassischen Prozessen in der gleichen Zeit möglich gewesen wären.

Das Schweizer Softwareunternehmen Abacus Research AG hat sich bei der Entwicklung neuer, innovativer und mobiler Anwendungen für einen neuen Business-Prozess entschieden: Applikationen werden seit diesem Jahr von Beginn an auf einer containerbasierten Plattform in der Cloud realisiert. „Dies entlastet die interne IT und die Softwareentwickler können sich auf ihre Kernaufgabe konzentrieren“, so Freddy Kaiser, Head of Architecture & Engineering bei Abacus Research AG.

Der Übergang in eine Cloud sei bei Abacus schon länger Thema gewesen. „Letztes Jahr standen wir dann vor der Wahl: Entweder wir bauen intern eine eigene Lösung oder wir geben den kompletten Betrieb extern“, sagt Kaiser. Aufgrund des engen Zeitplans hat sich Abacus für die zweite Option entschieden und liess sich von der Schweizer Container Plattform „APPUiO“ eine Private Cloud aufbauen. „Mit „APPUiO“ haben wir einen kompetenten und hilfsbereiten Partner gefunden, der gut zu uns passt und unsere hohen Anforderungen erfüllt“, so Kaiser. Wegen der Arbeit mit besonders schützenswerten Daten kam für Abacus von Beginn an nur der Betrieb auf Datenservern innerhalb der Schweiz bei einem schweizerischen Cloud Service Provider in Frage. Mit Exoscale wurde ein passender Infrastrukturanbieter gefunden.

Nach der Evaluation und dem Aufbau im Herbst, wurde im Dezember 2016 mit AbaNinja die erste Applikation in die Cloud deployed. „Weil alles reibungslos funktionierte, kamen sehr schnell zusätzliche Dienste dazu“, sagt Kaiser. Mittlerweile werden rund zehn Applikationen in der Cloud betrieben. Dank dem containerbasierten Deployment seien die Prozesse schneller, exakter und einfacher geworden. Auch die Nachvollziehbarkeit sei erheblich gestiegen. Vom Code bis zum Testsystem und dem eigentlichen Deployment wurde alles automatisiert. „Wir sind diesbezüglich drei Mal effizienter geworden“, betont Kaiser.

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

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/

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

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.

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.

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