tecRacer Amazon AWS Blog Infos rund um das Thema Amazon Web Services von den tecRacer Cloud Experten 2018-05-19T18:11:38Z http://www.aws-blog.de/feed/atom/ WordPress Gernot Glawe <![CDATA[Lass uns Freunde sein: AWS Neptune als Graphdatenbank]]> http://www.aws-blog.de/?p=2714 2018-03-23T15:44:35Z 2018-03-23T13:40:38Z Lass uns Freunde sein: Neptune als Graphdatenbank Der Graphendatenbankservice Neptune ist jetzt in der Preview Phase. Wir konnten erste Erfahrungen mit dem Service sammeln. Neptune unterstützt SPARQL und Apache TinkerPop Gremlin. Ich zeige hier eine […]

Der Beitrag Lass uns Freunde sein: AWS Neptune als Graphdatenbank erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Lass uns Freunde sein: Neptune als Graphdatenbank
Der Graphendatenbankservice Neptune ist jetzt in der Preview Phase. Wir konnten erste Erfahrungen mit dem Service sammeln. Neptune unterstützt SPARQL und Apache TinkerPop Gremlin. Ich zeige hier eine Verwendung mit Gremlin.

Der Service läuft erst einmal nur in Virgina. Die Installation benötigt ein VPC und eine Security Group. Das kann auch beides durch den Wizard erstellt werden.

Der Zugriff ist nur im VPC möglich. Installiert man einen Bastion Host, kann man mit einem Tunnel lokal arbeiten. In den Security Groups des Neptune Servers muss Port 8182 vom Bastion Host aus möglich sein. Auf dem Bastion Host muss dann ssh und 8182 offen sein.

Der Endpunkt der Neptune Datenbank, z.B. demo-us-east-1b.cygc21hikgg.us-east-1-beta.rds.amazonaws.com (das ist kein echter Endpunkt) muss dann z.B. in die ssh config eingetragen werden.
Zusätzlich braucht man noch die öffentliche IP des Bastion hosts, z.B. 1.2.3.5.

Dann wäre das Setting in der ssh Config:

Host neptunedemo
 User ec2-user
 Hostname 1.2.3.5
 IdentityFile ~/.ssh/key-des-bastion-hosts.pem
 LocalForward 8182 demo-us-east-1b.cygc21hikgg.us-east-1-beta.rds.amazonaws.com:8182

Nun kann den Tunnel starten mit:

 ssh -f -N neptunedemo

Danach kann man local auf Port 8182 auf die Graphdatenbank zugreifen.

Für den Zugriff kann man die Gremlin Console verwenden.

Installation der Gremlin console

Gremlin benötigt Java.

Auf der Projektseite lädt man die Gremlin Console: Apache TinkerPop

Das Zip Archiv wird entpackt, und dann kann man die Console starten:

 ./apache-tinkerpop-gremlin-console-3.3.1/bin/gremlin.sh

Zugriff mit Gremlin Console

./apache-tinkerpop-gremlin-console-3.3.1/bin/gremlin.sh

\,,,/
(o o)
-----oOOo-(3)-oOOo-----
plugin activated: tinkerpop.server
plugin activated: tinkerpop.utilities
plugin activated: tinkerpop.tinkergraph
gremlin>

Verbindung mit dem Server, also localhost ist in conf/remote.yaml vorkonfiguriert:

 gremlin> :remote connect tinkerpop.server conf/remote.yaml
 ==>Configured localhost/127.0.0.1:8182

Alle Eingaben sollen an dern Remote Server gesendet werden:

 gremlin> :remote console
 ==>All scripts will now be sent to Gremlin Server - [localhost/127.0.0.1:8182] - type ':remote console' to return to local mode

Die Datenbank ist leer. In V befinden sich alle Knoten, genannt Vertex. In E befinden sich alle Kanten, gennant Edge

Wenn jetzt alle Knoten abgefragt werden, sind sie leer:

 gremlin> g.V()
 gremlin>

Jetzt fügen wir einen Vertex mit zwei Labels hinzu:

 gremlin> g.addV("Label1::Label2::Label3")
 ==>v[4ab0f092-7746-9e3b-7c7b-e3cc1a606975]

Als Ausgabe wird die ID angezeigt. Die IDs sind in neptune reine Strings, es gibt keine numerische ID.

Anzeige des neuen Knotens:

 gremlin> g.V("4ab0f092-7746-9e3b-7c7b-e3cc1a606975")
 ==>v[4ab0f092-7746-9e3b-7c7b-e3cc1a606975]

Eingabe des AWS Beispiels

In der AWS Anleitung wird folgende Beispiel eines Graphen gegeben:

Anlegen der Personen

gremlin> g.addV("person").property("name","Anna")
 ==>v[c0b0f096-2906-2f3a-1881-4714a41dbd47]
 gremlin> g.addV("person").property("name","Justin")
 ==>v[cab0f096-5b3e-c0fe-2ec3-d8af1c26776e]
 gremlin> g.addV("person").property("name","Alana")
 ==>v[3eb0f096-5d9e-26c7-25f2-74eaeccff004]

Jetzt verbinden wir Justin und Anna freundschaftlich:

 g.V().has("name","Justin").next().addEdge("Friend", g.V().has("name","Anna").next())

Und haben damit einen Edge (Kante):

 gremlin> g.E()
 ==>e[30b0f099-ffe1-f774-f03c-7ea1c078b9e1][cab0f096-5b3e-c0fe-2ec3-d8af1c26776e-Friend->c0b0f096-2906-2f3a-1881-4714a41dbd47]

Jetzt können wir abfragen welche Freunde Anna hat. Die Freundschaft ist nur einseitig – das kommt manchmal vor. Deswegen frage ich die eingehenden Kanten ab:

 gremlin> g.V().has("name","Anna").inE("Friend")
 ==>e[30b0f099-ffe1-f774-f03c-7ea1c078b9e1][cab0f096-5b3e-c0fe-2ec3-d8af1c26776e-Friend->c0b0f096-2906-2f3a-1881-4714a41dbd47]

Um jetzt den Namen von Annas Freund zu bekommen, müssen wir von der Kante (Edge) zu dem Knoten (Vertex) navigieren und den Namen ausgeben:

 gremlin> g.V().has("name","Anna").inE("Friend").outV().values("name")
 ==>Justin

Erstes Fazit

Die Installation von Neptune geht um ein Vielfaches schneller und einfacher als z.B. das Aufsetzen von JanusGraph (JanusGraph: Distributed graph database). Für bestimmte Anwendungfälle ist eine Graphdatenbank besser geeignet als eine SQL oder auch eine NoSQL Datenbank.
Mit Neptune ist das auch als gehosteter Service einfach verwendbar.

Weitere Dokumentation

Die TinkerPop/gremlin Dokumentation findet sich auf der Projektsite: TinkerPop3 Documentation.

Es gibt einige Unterschiede in der Implementierung von AWS. Siehe dazu: Neptune Gremlin Implementation Differences – Amazon Neptune

Der Beitrag Lass uns Freunde sein: AWS Neptune als Graphdatenbank erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[AWSome Day Roadshow 2018]]> http://www.aws-blog.de/?p=2710 2018-03-12T11:24:26Z 2018-03-12T11:24:26Z Auch in 2018 ist tecRacer wieder Sponsor und Speaker der AWSome Roadshow. Termine in Deutschland sind: 10.04. Köln 11.04. Berlin 12.04. Karlsruhe 12.06. Hamburg 13.06. Stuttgart 14.06. München Anmeldung und weitere Infos hier:https://aws.amazon.com/de/events/awsomeday-dach-2018/  

Der Beitrag AWSome Day Roadshow 2018 erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Auch in 2018 ist tecRacer wieder Sponsor und Speaker der AWSome Roadshow.

Termine in Deutschland sind:

10.04. Köln
11.04. Berlin
12.04. Karlsruhe

12.06. Hamburg
13.06. Stuttgart
14.06. München

Anmeldung und weitere Infos hier:https://aws.amazon.com/de/events/awsomeday-dach-2018/

 

Der Beitrag AWSome Day Roadshow 2018 erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Thomas Heinen <![CDATA[Link Local-Addressen bei AWS]]> http://www.aws-blog.de/?p=2703 2018-02-15T13:12:15Z 2018-02-22T09:00:52Z Im sogenannten APIPA/Link Local-Bereich (siehe RFC 3927) sind auf AWS EC2-Instanzen mehrere Dienste erreichbar, von denen der Metadata Service mit Abstand der Bekannteste und Wichtigste ist. Allerdings gibt es dort auch andere Services (siehe Post […]

Der Beitrag Link Local-Addressen bei AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Im sogenannten APIPA/Link Local-Bereich (siehe RFC 3927) sind auf AWS EC2-Instanzen mehrere Dienste erreichbar, von denen der Metadata Service mit Abstand der Bekannteste und Wichtigste ist. Allerdings gibt es dort auch andere Services (siehe Post „Default DNS-Server in AWS VPCs“), die in der Dokumentation teils recht versteckt sind:

169.254.169.123              AWS eigener NTP-Server seit 2017
169.254.169.250/251      Microsoft KMS-Server zum Check von Windowslizenzen
169.254.169.253              DNS Endpunkt, falls DNS Support im VPC aktiv ist
169.254.169.254              Metadataservice auf Port 80

Die IPs mit 169er Prefix sind übrigens von Security Groups völlig unabhängig, da sie auf Hypervisorebene direkt verarbeitet werden. Deswegen findet sich auch kein „Metadata-Agent“ auf den Instanzen und die Route für den 169.254er Bereich zeigt auf das normale Netzwerkinterface. Der Zugriff kann aufgrund dieser Implementation nur auf der OS-Ebene eingeschränkt werden – was aber nicht ratsam ist, da damit auch EC2 Rollen nicht mehr funktionieren.

Durch die Verwendung des RFC 3927 Addressbereichs umgeht AWS elegant Routingprobleme, die bei der Nutzung von RFC1918-Addressen in Hybridumgebungen sonst entstehen könnten. Dasselbe Prinzip wird übrigens auch bei den Default-Transfernetzen bei VPN-Verbindungen angewandt, die aus dem 169.254er Bereich ausgewählt werden.

Der Beitrag Link Local-Addressen bei AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Thomas Heinen <![CDATA[Default DNS-Server in AWS VPCs]]> http://www.aws-blog.de/?p=2700 2018-02-15T13:34:06Z 2018-02-15T13:08:13Z AWS reserviert in jedem Subnetz die dritte IP (bei einer 24er Maske also die x.x.x.2) für Ihren DNS-Server. Sobald man mit Network ACLs arbeitet, geht man daher davon aus, dass die DNS-Queries innerhalb des Subnetzes […]

Der Beitrag Default DNS-Server in AWS VPCs erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
AWS reserviert in jedem Subnetz die dritte IP (bei einer 24er Maske also die x.x.x.2) für Ihren DNS-Server. Sobald man mit Network ACLs arbeitet, geht man daher davon aus, dass die DNS-Queries innerhalb des Subnetzes der Instanz stattfinden. Allerdings findet sich versteckt in den Dokumentationen der Hinweis, dass es sich bei „Subnetz+2“ nur um eine Reservierung handelt, der DNS aber eigentlich auf „VPC+2“ liegt – selbst wenn dort überhaupt kein Subnetz konfiguriert ist.

Dieses Problem kann man elegant umgehen, indem der DNS Endpunkt auf dem lokalen Interface genutzt wird. Während die Existenz des Metadata-Services auf der 169.254.169.254 weithin bekannt ist, ist nämlich der DNS auf 169.254.169.253 eher unbekannt.

Bei Security Groups findet sich eine weitere Besonderheit im Zusammenhang mit DNS: Sofern man ausgehende Regeln explizit konfiguriert hat, ist der default DNS-Server implizit auch freigegeben – selbst wenn udp/53 nicht in den erlaubten Regeln vorhanden ist. Ein externer DNS Server, der z.B. im on-Premise Netzwerk steht, braucht allerdings eine explizite Freigabe.

 

Der Beitrag Default DNS-Server in AWS VPCs erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Gernot Glawe <![CDATA[Anpassen von Konfigurationsdateien mit Ausgabewerten von CloudFormation Stacks]]> http://www.aws-blog.de/?p=2670 2018-01-21T19:04:35Z 2018-01-21T19:04:35Z Bei der Migration von Anwendungen auf AWS müssen auch die Konfigurationsdateien der Anwendungen angepasst werden.  Auch dabei gilt der Grundsatz „Automatisiere alles“. Doch wie kommen die Daten aus der neu auf AWS provisionierten Infrastruktur auf […]

Der Beitrag Anpassen von Konfigurationsdateien mit Ausgabewerten von CloudFormation Stacks erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Bei der Migration von Anwendungen auf AWS müssen auch die Konfigurationsdateien der Anwendungen angepasst werden.  Auch dabei gilt der Grundsatz „Automatisiere alles“. Doch wie kommen die Daten aus der neu auf AWS provisionierten Infrastruktur auf die Server? Hierzu ein paar Tipps zu CloudFormation und Anpassung von Konfigurationsdateien mit Shell Skripten.

Den Inhalt habe ich in drei Teile aufgeteilt:

Daten aus Cloudformation Exports auslesen

Wie kommen die Daten aus durch CloudFormation generierten Infrastrukturkomponenten in ein Script?

Anpassen von Property Konfigurationsdateien 

Wie ersetze ich automatisiert die Parameter der AWS Infrastruktur in Property Dateien

Anpassen von XML Dateien

Per ssh auf 10 Maschinen und händisch Scripte ausführen? Nein, Automate everything, auch wenn es nur 10 Instanzen sind.

Daten aus Cloudformation Exports auslesen

Um Attribute von mit CloudFormation erzeugten Resourcen auslesen zu können, muss man im Template diese Werte auslesen und dann exportieren.

Die Werte kann ich aus den CloudFormation Ressourcen mit „Fn::GetAtt“ auslesen.

Hier sind alle unterstützen Attribute gelistet. Für den Typ „AWS::RDS::DBInstance“ kann ich z.B. Endpoint.Address und Endpoint.Port auslesen, woraus ich mit die Verbindungsstring zur Datenbank zusammenbauen kann.

Wenn ich im CloudFormation Template nur mit „Ref“ zugreife, bekomme ich die eindeutige ID der Resource. Beim VPC z.B. die VPC ID, beim S3 Bucket den Bucketnamen.

Hier ein Beispiel in CloudFormation für „Outputs“ um die ID eines VPCs zu exportieren (in YAML):

Outputs: 
    VPC: 
        Description: A reference to the created VPC
        Value: !Ref VPC
        Export: 
            Name: VpcId

Dazu wird die „Outputs“ Abteilung im Template angelegt. Durch den Extra Eintrag „Export“ lässt sich die Variable mit „Fn::ImportValue“ auch durch andere Templates importieren. Auch in serverless lässt sich so ein Wert einfach importieren.

Wie kann ich diesen Wert dann in Bash Scripten verwenden? Das geht durch die AWS cli.

aws cloudformation list-exports --query 'Exports[?Name==`VpcId`].Value' --output text

Ergibt bei mir im Beispiel die Ausgabe „vpc-ac16c2c7″.

Im Detail betrachtet:

  • cloudformation list-exports ist der Befehl der AWS cli zum Anzeigen der Variablen der Templates
  • Der query Teil selektiert den Teil der JSON Ausgabe, der wir hier haben wollen
  • output text ergibt als Standardausgabe statt JSON Text. Interessant für Übersichten ist auch die Ausgabe „table“

Diesen Wert kann ich in einer Umgebungsvariable speichern:

export vpcid=$(aws cloudformation list-exports --query 'Exports[?Name==`VpcId`].Value' --output text)

Damit kann ich jetzt die VPCId im Shell Skript weiter verwenden. Das kann ich jetzt auf alle Resourcen anwenden, z.B. auch RDS Datenbanken. Diese Ausgaben kann ich jetzt an die passenden Stellen in Konfigurationsdateien einfügen. Nachdem wir jetzt Werte haben, schauen wir uns an, wie ich die Werte in Konfigurationsdateien einsetze.

Anpassen von Property Konfigurationsdateien 

In property Dateien sind die Werte als „parameter=wert“ kodiert.

Wenn z.B. Zugangsdaten oder wie im Beispiel der Link zu einer Datenbank in Konfigurationsdateien hinterlegt sind, so kann man diese mit Shell Scripten anpassen. Wichtig ist, es die Ersetzung von Daten mehrfach zu testen. Der Aufwand ist für eine reibungslose Migration dann gut investiert. Die Daten können  aus CloudFormation Stacks mit Exports ausgelesen werden (siehe oben).

Ein eleganter Weg ist das Programm ’sed‘. Die Kunst ist es, die Parameter richtig zu setzen. Dies geschieht mit Hilfe von regular Expressions.

Patchen mit sed auf der Kommandozeile geht so:

Ersetzen von Attributwerten hinter dem Gleichheitszeichen

Im Beispiel ist die neue Datenbank unter ‚jdbc:funnysql://rds.amazonaws‘ erreichbar. Die Konfiguration steht in der Datei „konfiguration.properties“. Eine Zeile davon ist „jdbc.url=irgendwas“. Diese Zeile wollen wir verändern. Dies passiert mit diesem Skriptbeispiel.

#!/bin/bash
file=konfiguration.properties
newprop='jdbc:funnysql://rds.amazonaws'
myprop='jdbc.url'
sed -i '' "s#$myprop=[^ ]*#$myprop=$newprop#" $file

Vorher steht in der Konfigurationsdatei „jdbc.url=irgendwas“, nach dem Ausführen des Scripts wird die Zeile ersetzt durch „jdbc.url=jdbc:funnysql://rds.amazonaws“.

Im Detail betrachtet:

  • „-i“ steht für ein In-Place reeplacement, die Datei wird also direkt verändert
  • „s#alt#neu#“ ersetz den alten Ausdruck durch den neuen. Häufig wird auch „/“ als Trenner verwendet. Dann darf aber das Zeichen „/“ nicht im Ausdruck selber vorkommen
  • mit „[^ ]*“ findet man alle Zeichen bis zum ersten Leerzeichen
  • Damit wird die ganz Zeile ersetzt

Verändern von XML Dateien

Viele Programme, gerade Java Programme, verwenden XML Dateien zur Konfiguration. In zwei Sätzen: XML ist so ähnlich wie HTML, das bekannt sein sollte. Elemente werden in <> gesetzt. Sie müssen geöffnet <Element> und geschlossen </Element> werden. Informationen können im Element kodiert sein wie: <Element>Datum</Element>.
Sie können aber auch als Attribute des Elements kodiert werden: <Element id=’Datum‘>….

Nun könnte man diese XML Dateien auch mit den Unix Tools wie sed oder awk, oder perl bearbeiten. Das ist aber generell etwas kompliziert. Ich kann davon nur abraten. XML kann variabel aufgebaut werden und dennoch die gleichen Informationen enthalten.

Daher verwenden wir hier ein kleines Tool, welches XML kennt und einfach auf Amazon Linux Instanzen installiert werden kann xmlstar:

Auf Amazon Linux kann das Programm einfach installiert werden:

yum -y install xmlstarlet

Z.B. Confluence arbeitet wie viele Java Programme mit XML Konfigrationsdateien. Bekommt man jetzt eine neue Datenbank, so kann man mit xmlstar und so einem Script die Werte anpassen.

Dabei kann man den Pfad oder auch Attribute selektieren. Die newurl baue ich mir mit den Endpoint.Address und Port aus dem CloudFormation Stack zusammen.

#!/bin/bash
file="/pfad/confluence.cfg.xml"
newurl="newurl"
xmlstarlet ed -P -u "/confluence-configuration/properties/property[@name='hibernate.connection.url']" -v "$newurl" $file >$tmp
mv -f $tmp $file


Zusammenfassung

Damit habe ich das Handwerkszeug zusammen, um mit CloudFormation Resourcen automatisiert aufzubauen und die Attribute der Ressourcen aus dem CloudFormation Stack auszulesen. Damit kann man der Automatisierung wieder einen Schritt näher kommen.

Der Beitrag Anpassen von Konfigurationsdateien mit Ausgabewerten von CloudFormation Stacks erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[AWS Re:Invent 2017 Sessions Slideshare List]]> http://www.aws-blog.de/?p=2673 2017-12-11T15:28:13Z 2017-12-11T15:28:13Z Re:Invent 2017 Sessions available on Slideshare (Status Dec 11, 2017) in an Excel-File for Download. AWS-Re-Invent2017-Slideshare-Sessions

Der Beitrag AWS Re:Invent 2017 Sessions Slideshare List erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Re:Invent 2017 Sessions available on Slideshare (Status Dec 11, 2017) in an Excel-File for Download.

AWS-Re-Invent2017-Slideshare-Sessions

Der Beitrag AWS Re:Invent 2017 Sessions Slideshare List erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[50 Mitarbeiter Zertifizierungen für AWS]]> http://www.aws-blog.de/?p=2666 2017-09-17T13:10:41Z 2017-09-17T13:10:41Z   Seit vielen Jahren haben darauf hin gearbeitet … jetzt die Marke von 50 Mitarbeiter Zertifizierungen für die Amazon Web Services Cloud erreicht. Insider wissen, wie schwer diese Zertifizierungen sind, so dass sich unsere Kunden […]

Der Beitrag 50 Mitarbeiter Zertifizierungen für AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
 

Seit vielen Jahren haben darauf hin gearbeitet … jetzt die Marke von 50 Mitarbeiter Zertifizierungen für die Amazon Web Services Cloud erreicht.

Insider wissen, wie schwer diese Zertifizierungen sind, so dass sich unsere Kunden darauf verlassen können, das unsere Mitarbeiter richtig Ahnung davon haben …

Der Beitrag 50 Mitarbeiter Zertifizierungen für AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Gernot Glawe <![CDATA[Clouds – einfaches Management von CloudFormation Templates]]> http://www.aws-blog.de/?p=2634 2017-07-21T13:59:27Z 2017-07-21T13:54:43Z Infrastruktur als Code ist eine (Heraus)Forderung von DevOps. Die Infrastrukturbeschreibungssprache von AWS heißt CloudFormation. Hat man sich erstmal eingearbeitet, greift man immer häufiger zum Texteditor statt zur Console, um AWS Ressourcen zu erstellen. Und eh […]

Der Beitrag Clouds – einfaches Management von CloudFormation Templates erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Infrastruktur als Code ist eine (Heraus)Forderung von DevOps. Die Infrastrukturbeschreibungssprache von AWS heißt CloudFormation. Hat man sich erstmal eingearbeitet, greift man immer häufiger zum Texteditor statt zur Console, um AWS Ressourcen zu erstellen. Und eh man es sich versieht, hat man eine unüberschaubare Anzahl von Cloudformation Templates. Und dann steht man vor der Aufgabe, diese zu verwalten. Hier wollen wir ein paar Möglichkeiten dafür vorstellen.

Verwaltung mit der AWS Console

Die WebGui von AWS ist zu Anfang der schnellste und einfachste Weg für die Verwaltung. Wie bei den meisten AWS Diensten wird eine einfache Liste angezeigt.

Umständlich wird es, wenn man viele Stacks hat. Hier im Beispiel sieht man nicht alle 12 Templates, man muss runterscrollen. Hilfreich ist es, den angezeigten Listenbereich zu maximieren. Dazu gibt es rechts in der Mitte die Symbole zur Größenanpassung des LIstenbereichs:

. Mit dem linken Symbol vergrößert sich der Listenbereich.

Arbeiten in verschiedenen Regionen – Resource Groups

Hier sieht man immer nur die Stacks in einer Region. Versieht man jedoch alle Templates mit Tags, z.B. „Project = Cloudformation“ so kann man überregional in den „Resource Groups“ Templates verschiedener Regionen ansehen:

Beim Erstellen der Resource Group sind folgende Attribute zu befüllen:

  1. Group Name: Ein sprechender Gruppenname, hier „Cloudformation Templates“
  2. Die Tags, die man sammeln will. Hier werden nur bereits vorhandene Tags zur Auswahl angezeigt. Im Beispiel „Project“
  3. Der Inhalt des Tags, im Beispiel „Cloudformation“
  4. Unter Regionen gibt man an, ob man über alle Regionen zusammenfassen will.
  5. Unter Resource Types gibt man nun Cloudformation Stacks an.

 

 

Als Ergebnis sieht man alle Ressourcen, die in diesem Fall den Tag „Project“ gleich „Cloudformation“ haben. Ich habe hier zwei Stacks in unterschiedlichen Regionen angelegt und kann diese hier zentral sehen:

 

Für Profis – Verwaltung mit der Kommandozeile CLI

Will man weiter automatisieren, so kommt man an der aws cli (command line interface) nicht vorbei. Die Beispiele sind – soweit nicht anders angegeben- mit der bash Shell erstellt.
Hier kann ich mir mit einem einfache Befehl alle Stacks der aktuellen Region anzeigen lassen:

aws cloudformation list-stacks

Angezeigt wird jeweils ein vollen Datensatz der Stacks.

{

            "StackId": "arn:aws:cloudformation:eu-central-1:123453403305:stack/MOBILEHUB-1663486314-Development/2b3f8290-1075-11e7-80a2-500c52a6ce62", 
            "StackName": "MOBILEHUB-1663486314-Development", 
            "CreationTime": "2017-03-24T09:35:08.096Z", 
            "DeletionTime": "2017-03-31T08:52:47.891Z", 
            "StackStatus": "DELETE_COMPLETE"
 }

Um nur eine Liste der Namen zu bekommen, kann man die query Funktion der AWS Kommandozeile nutzen:

aws cloudformation list-stacks --query "StackSummaries[*].StackName"

Mitunter werden hier mehr Stacks angezeigt, als eigentlich aktiv sind. Das liegt daran, dass auch Stacks mit Status gelöscht enthalten sind:

"StackStatus": "DELETE_COMPLETE", 

Filtern der cli Ausgabe

Die Ausgabe kann ich mit einem Filter bereinigen:

aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE']" 

Um auch hier wieder nur eine Liste der Namen zu bekommen, gebe ich die gewünschten Ausgabeattribute mit an:

aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE'].{Name:StackName}" 

Ganz rund wird es dann, wenn ich noch das Ausgabeformat anpasse:

aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE'].{Name:StackName}" --output table

Mögliche Formate sind:

  • text
  • Json
  • Table

Das sieht dann in etwa so aus:

Hier sind noch ein paar Stacks von der Vorbereitung auf das AWS Usergroup Treffen Hannover enthalten. Es ging wie man sehen kann um Codestar, Lambda und codebuild. 

Alle Stacks – Alle Regionen

Dennoch beschränkt sich hier die Ausgabe auf eine Region. Das kann man mit einem kleinen Shell Script lösen:

#!/bin/bash
for R in us-east-1 us-east-2 eu-west-1 eu-central-1 
do
  export AWS_DEFAULT_REGION=$R
  aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE'].{Name:StackName}" --output table
done

Im Beispiel werden für die vier Regionen east1+2, Irland und Frankfurt alle Stacks ausgegeben.

Noch einfacher – Verwaltung mit dem Tool „clouds“

Für eine individuelle Automatisierung kann der manuelle Weg zum Zusammenbau von cli Scripten der beste Weg sein, er ist aber auch steinig. Es gibt bereits verschiedene Tools, die das Leben einfacher machen. Eins davon ist „clouds„.

Das Prinzip des Tools sieht vor, dass alle CloudFormation Stacks lokal auf der Festplatte in einem Unterverzeichnis names „stacks“ liegen. Diese lokalen Kopien synchronisiert man dann mit dem AWS CloudFormation Service. Hier ein Beispiel für die Verwendung:

Installation von clouds

Mit dem pip Installer beschränkt sich die Installation auf:

pip install clouds-aws

Wichtig ist das Setzen der Region Umgebungsvariable, hier für bash. Für Frankfurt dann bitte eu-central-1 statt us-west-1 verwenden.

export AWS_DEFAULT_REGION=us-west-1

Konfiguration

clouds geht von dem Unterverzeichnis „stacks“ aus. Zusätzlich erstellen wir noch zwei Template Verzeichnisse.

mkdir stacks
mkdir stacks/mystack1
mkdir stacks/mystack2

Erstellen von Templates

Jetzt muss ich noch dafür sorgen, dass syntaktisch korrekter Inhalt in den Templates enthalten ist. Man kann dazu vi oder jeden anderen Editor nehmen.

touch  stacks/mystack1/template.json
vi stacks/mystack2/template.json

Ein Beispielstack mit einer EC2 Instanz gibt es im Abschnitt „Basic Amazon EC2 Instance“ auf dieser Seite: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/deploying.applications.html

In diesem Stack wird noch ein Parameter verwendet. Auch damit kann clouds umgehen. Die Parameter werden im selben Verzeichnis wie die Templates in die Datei „parameters.yaml“ geschrieben.

vi stacks/mystack2/parameters.yaml

Ich habe meinen Key „mykeyname-us-west-1“ genannt. Die parameters.yaml enthält also:

KeyName: "mykeyname-us-west-1"

Templateliste

Jetzt habe ich lokale Templates. Dies zeigt clouds mit „list“ an:

Eingabe:

clouds list

Ausgabe:

stack list and stack status:

mystack1 LOCAL-ONLY
mystack2 LOCAL-ONLY

Stack mit lokalem Template erstellen

Um die Template-Erstellung komme ich in keiner Variante – Konsole-cli oder clouds herum. Nach dem Erstellen wird es jetzt mit clouds einfacher. Der Name des Stacks ist durch den Namen des Unterverzeichnisses von „stacks“ festgelegt. Daher kann ich jetzt „mystack2“ einfach erstellen:

clouds update mystack2 -c

Der Befehl „update“ aktualisiert den AWS CloudFormation Stack aus der lokalen Datei. Mit dem Parameter „-c“ (create) wird der Stack angelegt, wenn er noch nicht existiert.

Um zu sehen, wie der Stack angelegt wird und ob es eventuell Probleme gibt, lasse ich mir die Protokolldatei anzeigen:

clouds events -f mystack2

Die Ausgabe sieht dann in etwa so aus:

2017-06-25/09:19:05 CREATE_IN_PROGRESS AWS::CloudFormation::Stack mystack2 User Initiated
2017-06-25/09:19:10 CREATE_IN_PROGRESS AWS::EC2::SecurityGroup WebServerSecurityGroup 
2017-06-25/09:19:11 CREATE_IN_PROGRESS AWS::EC2::SecurityGroup WebServerSecurityGroup Resource creation Initiated
2017-06-25/09:19:12 CREATE_COMPLETE AWS::EC2::SecurityGroup WebServerSecurityGroup 
2017-06-25/09:19:15 CREATE_IN_PROGRESS AWS::EC2::Instance WebServerInstance 
2017-06-25/09:19:16 CREATE_IN_PROGRESS AWS::EC2::Instance WebServerInstance Resource creation Initiated
2017-06-25/09:19:33 CREATE_COMPLETE AWS::EC2::Instance WebServerInstance 
2017-06-25/09:19:36 CREATE_COMPLETE AWS::CloudFormation::Stack mystack2

Mit dem Template arbeiten

Ich kann nun das Template lokal bearbeiten und jeweils mit dem update Befehl als Stackupdate ausführen.

Den aktuellen Status alle Stacks in der aktuellen Region kann ich mir dann mit

clouds list

Anzeigen lassen.

Will ich den Detailstatus eines Stack sehen, z.B. „mystack2“, so ist „describe“ das Kommando:

clouds describe mystack2

Die Ausgabe solle in etwa so aussehen:

Parameters:
 InstanceType: m1.small
 KeyName: mykeyname-us-west-1
 SSHLocation: 0.0.0.0/0
Outputs:
 WebsiteURL: http://ec2-13-56-11-84.us-west-1.compute.amazonaws.com
Resources:
 WebServerInstance: AWS::EC2::Instance (i-056ebb015af809521)
 WebServerSecurityGroup: AWS::EC2::SecurityGroup (mystack2-WebServerSecurityGroup-84E66682CPUR)

Stacks löschen

Das Löschen von Stacks ist dann mit „delete“ möglich. Den „-f“ force switch sollte man mit Bedacht verwenden, da der Stack dann ohne Nachfrage gelöscht wird. Ein kleiner Vertipper könnte da große Folgen haben. Hier verwende ich ihn, um das Beispiel abzuschließen:

clouds delete mystack2 --force

Fazit

Es gibt auch noch weitere Tools wie z.B. „awless„, die einen Teil der Funktionalität abbilden. Clouds bietet meiner Meinung nach einen sehr vielversprechenden Ansatz. Alle Funktionen, die ich bei früheren Projekten selber mit Scripten auf der Kommandozeile gebaut habe, sind enthalten.

Wenn man vor der Grundlagenentscheidung steht, wie Infrastruktur auf aws gebaut wird, sollte man sich auch Terraform und sparkeformation anschauen.

Steht Cloudformation als Basis fest und werden keine umfangreichen Programmierungen von Templates benötigt, ist clouds definitiv eine echte Hilfe!

Der Beitrag Clouds – einfaches Management von CloudFormation Templates erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[Die Deutsche Bahn geht in die AWS-Cloud]]> http://www.aws-blog.de/?p=2624 2017-04-25T13:50:32Z 2017-04-25T13:50:32Z Der IT-Dienstleister der Deutschen Bahn, die DB Systel GmbH, verlagert ihr Rechenzentrum in die Amazon-Cloud … und wir von tecRacer dürfen dabei tatkräftig mit Trainings & Consulting unterstützen. Mehr dazu hier bei Heise / iX.

Der Beitrag Die Deutsche Bahn geht in die AWS-Cloud erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Der IT-Dienstleister der Deutschen Bahn, die DB Systel GmbH, verlagert ihr Rechenzentrum in die Amazon-Cloud … und wir von tecRacer dürfen dabei tatkräftig mit Trainings & Consulting unterstützen.

Mehr dazu hier bei Heise / iX.

Der Beitrag Die Deutsche Bahn geht in die AWS-Cloud erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Gernot Glawe <![CDATA[Call Center Service „Amazon Connect“ mit Lambda Integration – Alles möglich?]]> http://www.aws-blog.de/?p=2593 2017-04-01T15:59:39Z 2017-04-02T08:34:51Z Call Center Service „Amazon Connect“ mit Lambda Integration Connect ist der neue Service von AWS, in dem man einfach in der Cloud ein Call Center mit eigener Rufnummer erstellen kann. Mit einer grafischen Oberfläche kann […]

Der Beitrag Call Center Service „Amazon Connect“ mit Lambda Integration – Alles möglich? erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Call Center Service „Amazon Connect“ mit Lambda Integration

Connect ist der neue Service von AWS, in dem man einfach in der Cloud ein Call Center mit eigener Rufnummer erstellen kann. Mit einer grafischen Oberfläche kann man dann mit wenig Programmierkenntnissen eigene telefonische Abläufe erstellen, Anrufe auf S3 aufzeichnen, Statistik über Cloudwatch machen usw..

Alle telefonischen Agenten können vollständig mit einem Browser und Rechner ohne Telefonanschluss arbeiten. Hier stellen wir im Beispiel, vor wie Connect mit eigenen Lambda Funktionen zusammenarbeitet.

Dabei kann komplett dynamische Abläufe in der Anrufbehandlung erstellen. In Kürze wird dies mit Amazon lex auch mit tatsächlicher natürlicher Sprachsteuerung, also gesprochene Wörter möglich sein. Im Moment muss man immer noch auf Tastendrücke zurückgreifen.

In kurzer Zeit kann man Call Funktionen wie folgende in der Cloud realisieren:

Ein Anrufer mit Basis Support im Beispiel:

 

Contact Flows in Connect

Innerhalb von Connect wird der Anrufen durch Contact Flows geführt. Diese ermöglichen z.B. Zuweisung von Anrufern zu Agenten nach bestimmten Eingaben. Für komplexe Abläufe kann man Eingaben, die der Anrufen über das Telefon macht an Lambda Funktionen weiterleiten. Hier können dann komplexe Abfragen durchgeführt werden.

Anwendungsfall

Im Beispiel gibt der Kunde seine Kontonummer ein. In der Simulation ermittelt lambda aus der Kontonummer den Supportlevel. Der Rückgabewert steuert dann die weiteren Ansagen. In einem echten Szenario könnte man dann den Kunden je nach Support an verschiedene Bearbeiter weiterleiten.

Realisierung in der Übersicht

 

  1. Callcenter mit Connect aufbauen
  2. Deutsche Einwahlnummer claimen
  3. Eigenen Contact Flow erstellen
  4. Lambda Funktion erstellen
  5. Test

Voraussetzung

 

  1. AWS Account – eine Anleitung zu Erstellung eines AWS Account kann man hier finden.
  2. Installiertes node, Node kann über die Node Webseite runtergeladen werden.
  3. Installiertes serverless Framework, siehe Serverless Webseite
  4. AWS Credentials für Serverless einrichten, siehe Serverless Dokumentation

Callcenter mit Connect aufbauen

Connect versteckt sich in der AWS Console unter dem Punkt „Call Center:

Unter der Funktion „Claim a Number“ kann man für DID „Direct Inward Dailing“ einfach eine deusche Einwahlnummer bekommen.

Für diese Einwahlnummer kann man nun Contact Flow verbinden. Wir bauen hier im Beispiel einen eigenen Contact Flow. Zuerst sollte man die Sprache mit Set Voice auf Deutsch stellen. Beide deutschen Stimmen von Amazon Polly stehen zur Verfügung. Auch eine Sprachweiche könnte man dazu erstellen.

Danach kann man eine Ansage in der gewählten Sprache mit Play prompt ausgeben. Jetzt könnte man schon eine Lambda Funktion bauen, die mit der Einwahlrufnummer Berechnungen durchführt. In unserem Beispiel wird zuerst eine vierstellige Kontonummer mit „Store Customer Input“ eingegeben:

Der Input wird auf 4 Ziffern begrenzt, die der Kunde mit der Telefontasten eingibt..

Aufruf der Lambda Funktion

Die Eingabe wird dann in eine Lambda Funktion übergeben. Dazu stellt man unter key ein, wie der Parameter heißt, den Lambda dann als Input bekommt. Im Beispiel wird account innerhalb der Lambda Eingangsdatenstruktur als Parameter übergeben:

 "Parameters": {
            "account": "5678"
        }

In der Funktion ARN wird die ARN der Lambda Funktion eingetragen.

Lambda gibt dann als servicelevel einen „berechneten String zurück:

  if( account == "5678"){
    level = "premium";
  };

  callback(null, { servicelevel : level });
In dem Contact Flow kann dann eine Weiche entsprechend dem Lambda Rückgabewert eingebaut werden:
Im einfachsten Fall verweist man auf verschiedene Ansagen.

Lambda Funktion mit Serverless einfach erstellen

Jetzt muss man noch eine Lambda Funktion erstellen, die die eigentliche Berechnung macht.

Mit den beiden Dateien im Anhang kann die Lambda Funktion mit einer Kommandozeile erzeugt werden:

sls deploy

Dabei ist sls die Abkürzung für Serverless. Die ARN der erzeugten Funktion wird wie oben beschrieben im Connect eingetragen.

'use strict';
module.exports.hello = (event, context, callback) => {
  var account = event.Details.Parameters.account;
  var level = 'none';
  if( account == "1234"){
    level = 'basis';
  };
  if( account == "5678"){
    level = "premium";
  };

  callback(null, { servicelevel : level });

};

Die Lambda Funktion besteht aus wenigen Zeilen:

Aus der Eingabe in event wird die Nummer aus account ausgelesen. Ein „berechneter“ Wert wird dann als servicelevel zurückgegeben. Durch den ersten Parameterwert null im Callback wird die fehlerfreie Ausführung angezeigt. Um zu wissen, welche Struktur die Eingabe Json hat, empfiehlt es sich, zuerst ein console.log(JSON.stringify(event))  einzubauen. Mit der im cloudwatch log ausgegebenen Struktur kann man dann weiter entwickeln.

Serverless Konfiguration

Bei der serverless Konfiguration haben wir ein kleines Henne Ei Problem: Zuerst muss die Lambda Funktion „connect-supportlevel-dev-hello“ erzeugt werden, damit die LambdaInvokePermission keinen Fehler wirft.

Diese lambda function policy ist notwendig, damit der connect service mit dem principal connect.amazonaws.com diese Lambda Funktion aufrufen darf.

Daher muss man die Zeilen 16-24 vor dem ersten sls deploy auskommentieren (mit „#“) , dann wieder einkommentieren und sls deploy erneut ausführen. Das geht natürlich auch noch eleganter.

 

Weitere Einsatzmöglichkeiten

Durch Lambda hat man Zugriff auf alle möglichen Szenarien, auch im Backend. Denkbar sind unter anderem:

  • Sprachausgabe eines Status, z.B. von Bestellungen
  • Ermitteln der Kundendokumente, während der Kunde sich noch ein paar Sätze anhört
  • Runterfahren von EC2 Instanzen sprachbasiert (gesehen auf einem chinesischem Blog!)

Was sind Ihre Ideen für die Einsatzgebiete?

Anhang:

Dateien:

Die Node Funktion: handler

Serverless Konfiguration:

service: connect-supportlevel 

provider:
  name: aws
  runtime: nodejs4.3
  stage: dev
  region: us-east-1
  ## Hier Account ID einsetzen
  account: 12345678

functions:
  hello:
    handler: handler.hello

resources:  
  Resources:
    LambdaInvokePermission: 
      Type: "AWS::Lambda::Permission"
      Properties: 
        FunctionName: "connect-supportlevel-dev-hello"
        Action: "lambda:InvokeFunction"
        Principal: "connect.amazonaws.com"
        SourceAccount: 
          Ref: "AWS::AccountId"

Lambda Funktion Policy:

{
 "Version": "2012-10-17",
 "Id": "default",
 "Statement": [
 {
 "Sid": "connect-supportlevel-dev-LambdaInvokePermission-xxxxxxx",
 "Effect": "Allow",
 "Principal": {
 "Service": "connect.amazonaws.com"
 },
 "Action": "lambda:InvokeFunction",
 "Resource": "arn:aws:lambda:us-east-1:xxxx:function:connect-supportlevel-dev-hello",
 "Condition": {
 "StringEquals": {
 "AWS:SourceAccount": "xxxxxxx"
 }
 }
 }
 ]
}

 

Der Beitrag Call Center Service „Amazon Connect“ mit Lambda Integration – Alles möglich? erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0