• Play 2 Framework

    Play 2 ist ein modernes Open-Source Webframework. Play 2 ist für die Umsetzung von hochverfügbaren Webapplikationen von Lightbend entwickelt worden. Unternehmen wie Zalando, LinkedIn, TheGuardian, Wallmart oder Twitter nutzen diese Webtechnologie für den Betrieb ihrer Online-Plattformen. 

    In durchgeführten Studien zur Performance und anderen Faktoren für unsere Kunden, konnte sich das Framework klar gegen Konkurrenten aus dem .NET, Node.JS und Java EE Umfeld durchsetzen.

    Da Play in Scala, einer modernen JVM Sprache, programmiert worden ist, kann es in neueren Versionen auch mit der Programmiersprache Java verwendet werden. Mithilfe des Play 2 Frameworks lassen sich Applikationen leicht und ohne große Konfigurationen entwickeln. 

     

  • Im Rahmen eines Kundenprojektes besuchte Tobias vergangene Woche die Scaladays in Kopenhagen. Zusätzlich besuchte er ein Meet-Up von Lightbend zum Thema Fast Data Plattform und die Typelevel Summits, die unmittelbar nach den Scaladays stattgefunden haben. In Zahlen konnte Tobias 25 verschiedene Talks von Speakern aus der ganzen Welt sehen. Insgesamt also sehr viel neuer Input in den Bereichen Scala, akka, play und co. 

    Neben vielen Themen in den Bereichen von Streaming Data (akka streaming, fast data plattform) und Microservices (CQRS, Datenvalidation mit Cats) war auch der neue Scala Compiler Dotty ein großes Thema der Konferenz. Die angesprochenen Verbesserungen sind alle sehr vielversprechend. Neben mehr Geschwindigkeit bei der Compilezeit wird die Sprache Scala an sich klarer und in unseren Augen weiter stark verbessert. 

    Ein für unser noch eher neues, aber dennoch sehr interessantes Framework ist scala meta. Das scala meta Livecoding in Form einer Erweiterung für REST APIs, war ein tolles Beispiel von Pathikrit Bhowmick. Der beste Talk der Konferenz kam in unseren Augen von Gabriele Petronella („Monad transformers down to earth“). Eine ähnlich gute Erklärung zu Monaden ist uns in Scala bisher nicht bekannt gewesen. 

    Für unser Projekt croGoDeal von großem Interesse waren auch die Talks von IBM zu Spark, sowie von Salesforce zu deren Plattform Einstein und der Spark Erweiterung namens Optimus Prime. Wir hoffen, dass diese typsichere Erweiterung von Spark in absehbarer Zeit als Open-Source Projekt veröffentlicht wird, sodass man dieses hervorragende Tool auch außerhalb von Salesforce benutzen kann.

    Alle Talks der Konferenz findet man auf dem YouTube Channel der ScalaDays.

     

     

     

     

  • Der nachfolgende Blogbeitrag soll den Einstieg in die DevOps Welt mit Amazon Web Services vereinfachen. Wir werden alle notwendigen Schritte anhand von Screenshots in der AWS Konsole durchgehen und eine Pipeline mit AWS CodePipeline aufbauen. Die Pipeline soll mit einem GitHub Repostiory beginnen, mit CodeBuild gebuildet werden und über CodeDeploy im Echtbetrieb in einer Elastic Beanstalk Umgebung enden. Als Referenzprojekt für eine Microservice kann unser giter8 Template für akka-http oder akka-graphql verwendet werden. Bei beiden müssen allerdings kleine Änderungen vorgenommen werden. Die Pipeline soll akka Microservices, die das Buildtool sbt verwenden, in den Betrieb überführen. Für Java Server, wie Payara Micro oder Wildfly Swarm, können nur ein paar Schritte verwendet werden. Vor allem die Vorbereitung des Projektes auf GitHub unterscheidet sich von einem Scala/Java akka Projekt.


    Bevor wir mit den Anpassungen unserer Dateien in unserem GitHub Repository beginnen, müssen wir zuerst ein Docker Repository anlegen. Dazu wechseln wir in die Elastic Container Service Oberfläche und klicken auf „Create Repository“. Wir vergeben hier lediglich den Namen unseres Projektes (innfactory-akka-http-ci-test) und schreiben uns die Repository URI auf. Mehr müssen wir in diesem Dienst nicht machen.

    EC2 Container Registry


    Als nächstes benötigen wir eine neue Datei Dockerrun.aws.json für AWS CodeDeploy. Die Werte bei Image – Name müssen entsprechend unseres ECR Repositorys angepasst werden. In diesem Beispiel pushen wir unserer Docker Container immer auf latest. Für mehrere Branches in github sind weitere Anpassungen notwendig.

      "AWSEBDockerrunVersion": "1",
      "Image": {
        "Name": "149805022439.dkr.ecr.eu-central-1.amazonaws.com/innfactory-akka-http-ci:latest",
        "Update": "true"
      },
      "Ports": [
        {
          "ContainerPort": "8080"
        }
      ]
    }
    

    Für den Buildprozess mit AWS CodeBuild benötigen wir nun noch eine buildspec.yml Datei die wie folgt aussehen kann. Die Variablen bleiben leer, denn sie werden später mithilfe von Umgebungsvariablen von AWS ersetzt. Unsere giter8 Templates sind für Docker vorbereitet, somit können die benötigten Parameter beim sbt docker:publish Aufruf übergeben werden. 

    version: 0.2
    
    env:
      variables: 
        STAGE: "dev"
        SQLURL: ""
        SQLUSER: ""
        SQLPASSWORD: ""
    
    phases:
      install:
        commands:
          - echo "continuous delivery for stage[$STAGE]"
          - echo "selected db=$SQLURL"
          - echo "$(lsb_release -cs)"
          - apt-get update -y
          - apt-get install -y apt-transport-https ca-certificates software-properties-common
          - add-apt-repository -y ppa:openjdk-r/ppa
          - sudo apt-get update -y
          - apt-get install -y openjdk-8-jdk
          - echo "deb https://dl.bintray.com/sbt/debian /" | sudo tee -a /etc/apt/sources.list.d/sbt.list
          - apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
          - apt-get update -y
          - apt-get install -y sbt
          - pip install --upgrade awscli
      pre_build:
        commands:
          - $(aws ecr get-login --no-include-email --region eu-central-1) 
      build:
        commands:
          - sbt test
          - sbt -DSTAGE=$STAGE -DSQL_URL=$SQLURL -DSQL_USER=$SQLUSER -DSQL_PASSWORD=$SQLPASSWORD docker:publish
      post_build:
        commands:
          - echo Build completed on `date`
    artifacts:
      files:
        - Dockerrun.aws.json 

    Einrichtung einer Elastic Beanstalk Umgebung

    Bevor wir mit der Continuous Delivery Pipeline beginnen, starten wir zuerst eine neue Elastic Beanstalk Umgebung, da diese ein paar Minuten zum Start benötigt. 

    Hierzu wechseln wir in der AWS Konsole zum Dienst Elastic Benastalk und erstellen eine neue Applikation.

    Create new Elastic Beanstalk application

    In dieser Applikation erstellen wir wiederum eine neue Umgebung (Web server environment) und konfigurieren diese als Docker Platform und lassen erst einmal die Sample Application von Amazon darauf laufen. 

    Beanstalk Environment Tier wählen

    Wir müssen keine weiteren Anpassungen mehr vornehmen und können die Umgebung mit einem Klick auf „Create environment“ erstellen. Alle nicht vorhandenen, aber benötigten, Informationen werden von AWS automatisch ergänzt. 

    AWS Beanstalk Environment Einstellungen

    Sollten wir weitere Anpassungen vornehmen wollen, können wir dies unter „Configure more options“ tun. Hier können wir unter anderem die zu startenden Instanzengrößen wählen, die Load Balancer mit https konfigurieren, das Monitoring anpassen, das richtige VPC Netzwerk auswählen, eine RDS Datenbank hinzufügen und noch vieles mehr. Als Hinweis dazu sei erwähnt, dass man niemals eine RDS Datenbank für den produktiven Betrieb in Beanstalk konfigurieren sollte. Diese hängt sonst an der Umgebung und wird gegebenenfalls zusammen mit der Umgebung gelöscht. 

    Nach ein paar Minuten sollte unsere Elastic Benastalk Umgebung mit der Sample Application von AWS gestartet sein.

    Elastic Beanstalk Übersicht


    Erstellung der Pipeline mit AWS CodePipeline

    Beginnen wir mit der eigentlichen Pipeline. Zuerst müssen wir einen Namen vergeben. Dieser kann später nicht mehr verändert werden und sollte er sinnvoll gewählt werden. 

    AWS CodePipeline anlegen

    Als nächstes müssen wir die Quelle unserer Pipeline auswählen. Sollte unser Projekt in AWS CodeCommit gehostet sein, kann dies ebenso verwendet werden wie GitHub. Wir verwenden in diesem Beispiel unsere GitHub Organisation innFactory und ein beliebiges akka sbt Projekt. Unter Advanced müssen wir keine Einstellungen vornehmen und wir können die Pipeline automatisch bei einem neuen git push auf den master starten lassen.

    Code Pipeline Quelle (CodeCommit oder GitHub)

    Für die Buildphase nutzen wir CodeBuild von AWS. Hierzu wählen wir „Create a new build project“ und konfigurieren die Einstellungen wie auf den nachfolgenden Screenshots zu sehen. Wir können beliebige Umgebungsvariablen hinzufügen, die in der buildspec.yml Datei aufgelöst werden. Wir haben dies bereits für unsere Datenbankparameter verwendet und die Konfiguration unseres akka Projektes wird, wenn es als Docker Instanz läuft, mit diesen Variablen überschrieben. Für produktive Systeme sollten die Passwörter nicht als Plaintext übergeben werden, sondern ein EC2 Parameter Store verwendet werden.

    AWS CodeBuild konfiguration

    AWS CodeBuild Umgebungsvariablen für RDS Datenbank

    Auf der Seite für das Deployment können wir unsere Elastic Beanstalk Application und unsere Umgebung mit der Sample Application verwenden.

    CodePipeline Deployment zu Elastic Beanstalk

    Zum Schluss müssen wir noch noch eine Rolle für die Pipeline anlegen und alle bisher definierten Rollen über AWS IAM anpassen. Wichtig ist, dass unsere verwendeten Rollen Zugriff auf das Docker Repository und auf Beanstalk haben. Sollte dies nicht konfiguriert worden sein, wird die Pipeline mit entsprechender Meldung fehlschlagen.

    CodePipeline Service Rolle


    Nachdem wir die Pipeline nun vollständig konfiguriert haben, startet diese automatisch. Haben wir alles richtig gemacht und alle Berechtigungen richtig vergeben sollte das Ergebnis wie folgt aussehen und die Sample Application in Elastic Beanstalk durch unseren neuen Docker Container ersetzt worden sein. 

    AWS akka CodePipline Erfolgreicher Deploy