Martin Mueller's Blog Ger

Souveräne Cloud auf AWS: Wann reicht eu-central-1 — und wann braucht ihr ESC?

Fri, 17 Jul 2026 00:00:00 GMT

Die AWS European Sovereign Cloud (ESC) ist seit Januar 2026 verfügbar — physisch isolierte EU-Infrastruktur, eigene Partition, EU-resident Operations. In DACH diskutieren viele digitale Souveränität: Datenhoheit, Kontrolle über Betrieb, Unabhängigkeit von Drittstaaten-Zugriff.

Die Kernfrage:

Reicht eu-central-1 (EU-Region), oder braucht ihr die souveräne Partition aws-eusc?

Dieser Post ist ein Builder-Guide — keine AWS-Werbung. Ich bin AWS Solutions Architect Professional zertifiziert, AWS Community Builder und unterstütze bei ESC-Migrationen (CDK/Terraform), Souveränitäts-Entscheidungen und Readiness-Checks. Lebenslauf

Warum jetzt?

ESC GA — souveräne AWS-Workloads sind planbar, nicht mehr „irgendwann“
Region eusc-de-east-1 (Brandenburg) — EU-Infrastruktur mit eigener Governance
Referenzkunden (öffentlich): SCHUFA, ITZBund, SAP, EWE, Swiss Life — Organisationen, die Souveränität als Architektur-Entscheidung treffen
Politik & Beschaffung: „souveräne Cloud“, EU-only Operations, keine Drittstaaten-Zugriffe — unabhängig vom konkreten Compliance-Framework

Wenig deutschsprachiger Builder-Content — die meisten Slides verkaufen Souveränität, statt zu erklären was bei Migration technisch bricht.

Was ESC wirklich ist — jenseits von „Server in der EU“

EU-Region ≠ souveräne Partition. Kurz und sachlich:

Aspekt	Standard AWS (eu-central-1)	AWS ESC (aws-eusc)
Partition	`aws`	`aws-eusc`
Physische Isolation	EU-Region	Dedizierte EU-Infra, eigene Partition
Operations	Global AWS Ops	EU-resident, europäische Governance
Datenresidenz	Ja (EU)	Ja (EU) + isolierte Kontroll- und Betriebsebene
Service-Umfang	Voll	~90 Services bei GA — wächst
Typischer Käufer	Die meisten Workloads	Souveränitäts-kritische Daten & öffentlicher Sektor

eu-central-1 liefert Datenresidenz. ESC liefert zusätzlich Partition-Isolation und EU-gesteuerten Betrieb — das ist der Souveränitäts-Sprung, nicht ein weiteres Zertifikat.

Decision Framework: drei Buckets

Zuerst klären: welche Souveränitäts-Anforderung habt ihr? — nicht welcher Anbieter am lautesten wirbt.

Bucket 1 — eu-central-1 reicht

Workloads, bei denen EU-Datenresidenz genügt
Kein vertraglicher Zwang zu isolierter Partition oder EU-only Operations
Ihr wollt AWS-Vollpalette ohne Partition-Split
Die Mehrheit der AWS-Kunden landet hier — und das ist okay

Bucket 2 — ESC für definierte Workloads

Vertraglich oder politisch: souveräne Partition, kein Zugriff aus Drittstaaten
Hochsensible Daten: Gesundheit, Kredit, Bundes-IT, kritische Infrastruktur
Hybrid: Kern auf ESC, Rest auf eu-central-1 — phased, nicht Big Bang

Bucket 3 — Full sovereign stack

ESC allein reicht politisch/rechtlich nicht
Kombination mit On-Prem, BRZ-PaaS (AT), Hetzner, oder dediziertem Hosting
Bewusste Architektur-Entscheidung — kein Default

In der Praxis: Bucket 1 oder 2. Souveränität ist Workload-spezifisch, nicht Org-weit.

Was sich für Builder ändert

Marketing verschweigt die operativen Unterschiede zwischen Partitionen:

Partition & Identität

Eigene IAM-Identitäten — keine 1:1-Übernahme aus aws
ARN-Formate und Account-Struktur neu denken (Landing Zone)

DNS & Netzwerk

Route53-Verhalten und Zonen — häufiger Stolperstein
Cross-Partition-Referenzen planen oder vermeiden

IaC / CDK

Region eusc-de-east-1, Partition aws-eusc
Hardcodierte ARNs aus eu-central-1 brechen
CI/CD: separate Credentials, ggf. separate Pipelines

Service-Verfügbarkeit

Serverless-Stack bei GA — vor Design prüfen
„In eu-central-1 verfügbar“ ≠ „in ESC verfügbar“

Typischer Pfad: Readiness → Landing Zone → Pilot → schrittweise Migration.

Case Studies: Wer setzt auf ESC?

AWS veröffentlicht bei Launch-Kunden meist Quotes und Richtung — selten CDK-Migrationspfade oder Account-Strukturen. Trotzdem lohnt sich ein Blick: warum Organisationen ESC wählen und was öffentlich zum konkreten Einsatz bekannt ist.

Gemeinsames Muster: nicht Org-weiter Big Bang, sondern souveränitäts-kritische Workloads — oft hybrid neben eu-central-1.

SCHUFA — Finance & Kreditdaten

Branche: Finanzdaten / Auskunftei
Warum ESC: 69 Mio. Verbraucher-Datensätze; isolierte EU-Infra, nur EU-Personal, kein Zugriff von außerhalb Europa — Souveränität ohne Innovationsverlust.
Was bekannt ist:

Migration von On-Prem und anderen Cloud-Workloads auf ESC
Neues Credit-Scoring-System mit transparenter Darstellung für Verbraucher (Kriterien + Gewichtung)
CTO Klaus Kolitz: Innovation und Souveränität zusammen, nicht entweder/oder

Quellen: About Amazon — Who's choosing ESC · AWS ESC Customers

Diehl Metering — Smart Meter & kritische Infrastruktur

Branche: Smart Metering (Wasser/Energie), B2B2G
Warum ESC: Öffentliche Kunden (Stadtwerke, Wasserwerke) verlangen EU-Datenhaltung und EU-Betrieb.
Was bekannt ist:

Smart-Metering-Datenplattform auf ESC
Modulare Services: Monitoring, Billing
Zentrales System für Wasser-/Energiedaten kritischer Infrastruktur
Skalierung der Plattform ohne den Aufwand eines komplett eigenen Sovereign-Stacks

Quellen: About Amazon — Who's choosing ESC · The Register (Mai 2026)

Universitätsklinikum Essen — Sovereign AI in der Medizin

Branche: Universitätsmedizin / Forschung
Warum ESC: Health Data at Scale unter deutschen und europäischen Souveränitäts-Erwartungen.
Was bekannt ist:

IKIM (Institut für KI in der Medizin) nutzt ESC als Basis für KI-Forschung
Ziel: medizinische Forschung in die Klinik überführen — mit Patientendaten in souveräner Umgebung
Eher Transformations- und Forschungspfad als dokumentierte Vollmigration eines Klinik-ERP

Quellen: About Amazon — Who's choosing ESC · AWS Public Sector — Healthcare & Sovereignty

Medizinische Universität Lausitz – Carl Thiem — regionales Gesundheitsökosystem

Branche: Gesundheit / Forschung (Brandenburg)
Warum ESC: Souveräne digitale Basis für das „Gesundheitsmodellregion Lausatia“.
Was bekannt ist:

Vernetzung von Krankenhäusern, Forschung, regionalen Partnern
Sichere, souveräne Grundlage für Care, Research, Education
Nähe zur ESC-Region Brandenburg (eusc-de-east-1)

Quelle: AWS ESC Customers

ITZBund — Bundes-IT

Branche: Öffentlicher Sektor
Warum ESC: Zentraler IT-Dienstleister des Bundes — strengste Anforderungen an Schutz und Souveränität.
Was bekannt ist: Commitment zu ESC mit voller AWS-Service-Palette; keine öffentliche Workload-Liste (erwartbar bei Bundes-IT).

Quelle: AWS ESC Customers

EWE AG — Energie

Branche: Energie / Versorger
Warum ESC: Sensible Versorgungsdaten und kritische Infrastruktur; Souveränität als Plattform-Strategie.
Was bekannt ist: ESC als Baustein der Plattform-Strategie — kein einzelnes benanntes Produkt, aber klarer strategischer Einsatz.

Quelle: AWS ESC Customers · AWS Launch Press Release

Eterno Health — Health-SaaS (Hybrid-Denken)

Branche: Ambulante Versorgung / Praxissoftware
Warum ESC: EU-weite Digitalisierung der Ambulanz — Kunden mit expliziten Souveränitäts-Anforderungen.
Was bekannt ist:

Gesamter Stack bisher auf Standard-AWS; ESC als zusätzliche Option für sovereignty-sensitive Deployments
Leni — KI-Agent (Transkription, Zusammenfassung, Patientenakte) in eigenen Test-Kliniken
Muster: SaaS auf AWS, ESC-Partition für Kunden die sie brauchen

Quellen: AWS ESC Customers · AWS Pioneers: ETERNO

Plattform-Partner (keine Endkunden, aber relevant)

Anbieter	Was auf ESC	Souveränitäts-Winkel
SAP	SAP Cloud ERP Private GA	Mission-critical ERP unter EU-Governance
Dedalus	Klinik-Software (540M+ Patienten)	Klinische Workflows mit Residency
Arvato Systems	Health Cloud	Healthcare-Digitalisierung souverän

Quellen: About Amazon — Who's choosing ESC · AWS Healthcare Sovereignty Blog

Was öffentlich fehlt — und wo Readiness-Assessments ansetzen: IAM/Landing-Zone-Design, CDK-Migrationspfade, Timeline, Kosten. Die Lücke zwischen Marketing-Quote und Production-Migration ist groß.

ESC vs. EU-Hosting auf Hetzner

Ich habe Prod auf Hetzner für EU-Kunden beschrieben — Arc Rider Universe mit voller Datenhoheit auf EU-VMs.

	Hetzner / Self-hosted EU	AWS ESC
Souveränitäts-Modell	Du betreibst alles	AWS-native souveräne Partition
Zielgruppe	Neues Produkt, volle Kontrolle	Bestehender AWS-Shop
Ops-Last	Hoch	Niedriger (managed)
Typischer Pfad	SaaS mit EU-Prod-Pflicht	Migration souveränitäts-kritischer AWS-Workloads

Beides kann parallel — Hybrid ist normal. Souveränität ist kein Either/Or.

CLOUD Act & Drittstaaten-Zugriff — ehrlich

Das ist der Souveränitäts-Elefant im Raum. eu-central-1 hostet in der EU, aber die Partition bleibt aws. ESC adressiert genau das:

Physisch isolierte Infrastruktur in der EU
EU-resident Operations — kein globaler Ops-Zugriff aus den USA
Europäische Governance-Struktur

Was ESC nicht ersetzt:

Vertragsprüfung (Unterauftragnehmer, Support-Pfade)
Datenklassifikation — welche Workloads brauchen welches Souveränitäts-Level
Politische Erwartungen vs. technische Realität

Ehrliche Einordnung schlägt Marketing. Souveränität ist Architektur und Vertrag.

Nächster Schritt: ESC Readiness Assessment

Wenn ihr AWS nutzt oder plant und Souveränität klären wollt:

45 Minuten, kein Pitch:

Welcher Bucket (1/2/3) für eure Workloads
CDK/Terraform-Stolpersteine (IAM, Route53, Partition)
Migrations-Fahrplan — Pilot → Rollout, Hybrid wo sinnvoll

Talk auf dem AWS Community Day DACH 2026 (Berlin, 15. Sep.) — AWS European Sovereign Cloud: A Builder's Guide.

Kontakt: office@martinmueller.dev · calendly.com/martinmueller_dev · LinkedIn · Lebenslauf

Betreff: ESC Readiness.

Weiterführend

AWS European Sovereign Cloud (offiziell)
Produktion auf Hetzner (EU) — Souveränität ohne AWS-Partition

OpenClaw drei Monate später: Was wirklich gelandet ist

Tue, 07 Jul 2026 00:00:00 GMT

Im April habe ich über OpenClaw geschrieben — mein selbst gehosteter KI-Agent auf einem Hostinger-VPS, angebunden an Telegram, E-Mail, Kalender und GitHub. Der Post endete mit einer kurzen „What's Next“-Liste. Drei Monate später ist das meiste umgesetzt — und das Setup fühlt sich weniger wie ein Chatbot und mehr wie ein kleines Ops-Team an.

Neu seit April:

Blogposts — Sprachnachricht rein, recherchierter Entwurf raus, auf der Site veröffentlicht
Code aus GitHub-Issues — Agent plant, ich approve, PR kommt
Rechnungen — zweisprachige PDFs für US- und DE-Kunden, Mail-Entwurf fertig
SEO & Compliance — Live-Daten und Reports ohne fünf Tools anklicken
Ein Telegram-Chat, viele Projekte — Topics trennen den Kontext
Konferenz-Vorschläge — Talk-Entwürfe aus Memory, nicht von null

Was sich geändert hat, was kaputtging und was ich wieder so machen würde.

Kurz zusammengefasst

OpenClaw ist ein persistenter Assistent mit Gedächtnis. Ich rede vor allem per Telegram — oft per Sprachnachricht. Er kann Aufgaben ausführen, Repos lesen, E-Mails entwerfen, GitHub prüfen. Versand nur nach meinem OK.

Alles Folgende baut darauf auf.

1. Blogposts — von der Idee bis live

Im April-Post stand: Blogposts entwerfen. Passiert — mehrfach:

Post	Was der Agent gemacht hat
Hetzner-EU-Prod-Serie	Recherche, EN+DE-Entwurf, Bilder
Lovable → Hetzner DACH	Gleiche Formel, echte Kundenstory
SISTRIX-MCP-SEO-Audit	Live-SEO-Daten, Kunden-Code gelesen, Strategie-PDF

Typischer Ablauf: Sprachnachricht → Kontext aus Notizen und Repos → Markdown-Entwurf → ich kürze und prüfe den Ton → veröffentlichen.

Lesson: Stark bei Erstentwürfen mit echten Daten. Mein Job: „Würde ich das unter meinem Namen posten?“

2. GitHub-Issues → Plan → PR

Größtes Upgrade: OpenClaw kann Coding an Cursor im echten Repo abgeben.

Heute:

Neues Issue im Produkt-Repo eines Kunden
Ping auf Telegram
Agent schreibt Implementierungsplan aus dem Code
Plan als GitHub-Kommentar — für das Team sichtbar, nicht im Chat versteckt
Ich approve → Code wird geschrieben → PR

Kleine Checks laufen auf dem günstigen Modell; Planung und Code nur, wenn es sich lohnt.

Lesson: Plan im Repo und auf GitHub halten. Telegram für Pings und Entscheidungen.

3. Rechnungen — die langweilige Arbeit

Rechnungstag war früher: HTML kopieren, Sätze suchen, USt-Formulierung prüfen, PDF, Upload, Begleitmail. Heute öffne ich das richtige Telegram-Topic und sage nächste Rechnung vorbereiten.

Der Agent kennt die Regeln pro Kunde — US vs. deutsch, Währung, MwSt, Layout. Letzte Rechnung als Vorlage, Nummer hoch, Zeitraum und Positionen eintragen, nur nachfragen was fehlt. Ergebnis: PDF in Dropbox, Mail-Entwurf wartet — Versand erst nach meinem OK.

Lesson: Der ROI-stärkste Use Case aus den letzten drei Monaten. Repetitiv, regellastig, fehleranfällig. Genau dafür ein Agent mit Gedächtnis.

4. SEO, WordPress, Compliance — ein Prompt, ein Ergebnis

April: Basis-Gedächtnis und wenige Tools. Juli: Der Agent spricht mit Diensten, die ich wöchentlich brauche — SEO-Daten, Kunden-WordPress, Security-Scan-Reports.

Immer gleiches Muster: eine Telegram-Nachricht, Agent kombiniert Live-Daten + Code-Kontext, ich bekomme ein datiertes Ergebnis (Markdown, PDF oder Issue-Kommentar). Den SEO-Workflow habe ich hier beschrieben.

Lesson: Eine Integration pro Aufgabe, die du monatlich manuell wiederholst. Nicht am ersten Tag alles verdrahten.

5. Telegram-Topics = Projekt-Switcher

Ein Gruppenchat, viele Topics — Blog, US-Kunde, DE-Kunde, Nebenprojekte.

Jedes Topic lädt den passenden Kontext: welches Repo, welcher Ton, welche Regeln. Kein Rechnungsgespräch im Blog-Thread.

Lesson: Wenn der Bot in der Gruppe schweigt — aktuelle OpenClaw-Version prüfen. Forum-Topics hatten einen Reply-Bug, der inzwischen gefixt ist.

6. Konferenz-Talk-Entwürfe

Neben Kundenarbeit reiche ich bei AWS Community Days, AgentCon, CodeMotion, re:Invent ein. Der Agent hält Vorschlags-Entwürfe in einem Ordner und kennt das Submission-Format.

Typischer Ablauf: Talk zu Security-Scanning für Poland Community Day entwerfen → Agent zieht aus früheren Projekten und Talks → Titel, Abstract, Gliederung paste-ready → Kalender-Reminder für die Deadline.

Lesson: CFP = Recherche + Struktur + deine Stimme. Der Agent macht die ersten beiden.

Zahlen (grob, drei Monate)

GitHub: viele Issues triagiert; mehrere Fixes via Agent → Cursor → PR
Blog: 4+ substanzielle Posts mit Agent-Hilfe (EN+DE)
Rechnungen: 5+ US-Sprint-Rechnungen + deutsche Kundenrechnungen — jeweils PDF + Mail-Entwurf
CFP: 10+ Vorschlags-Entwürfe für Polen, DACH, Mailand, re:Invent
Kosten: richtiges Modell pro Aufgabe wichtiger als VPS-Hosting
Pannen: eine Mail zu früh raus → harte „vor Versand fragen“-Regel; Morgen-Briefing einmal nach Update kaputt — mit Versions-Update und günstigerem Cron-Job gefixt

Was als Nächstes kommt

Auto-Implement nach explizitem GitHub-Approve
Infra aus dem Chat (Hetzner in Arbeit)
USt-Voranmeldung aus Rechnungsordner — agent-unterstützt, Steuerberater prüft

Fazit

Vor drei Monaten: E-Mail, Kalender, GitHub-Pings. Heute: Orchestrator — Topics für Kontext, Cursor für Code, Live-Integrationen für Daten, Blog für Content, Rechnungen und Talk-Entwürfe für die Business-Seite.

Weiterhin €10/mo Hostinger Docker.

Wenn du OpenClaw schon nutzt: für mich die größten Hebel — Coding an Cursor abgeben, ein Telegram-Topic pro Kunde/Projekt, eine Integration pro repetitiver manueller Aufgabe.

Links:

Fragen oder Hilfe beim Setup? office@martinmueller.dev oder calendly.com/martinmueller_dev.

Datengetriebenes SEO mit dem SISTRIX MCP: Ein HalloCasa Case Study

Tue, 23 Jun 2026 00:00:00 GMT

Ich habe HalloCasa mitgegründet — ein globales Maklerverzeichnis mit Listings, Profilen, Abos und Kursen. Organische Suche sollte für uns ein wichtiger Kanal sein. Als ich mich hinsetzte, eine SEO-Strategie zu bauen, wollte ich keinen Tag in Dashboards klicken, CSVs exportieren und Screenshots in ein Doc kleben.

Stattdessen habe ich meine KI in Cursor mit dem SISTRIX MCP verbunden und in einer Agent-Session ein vollständiges Audit gefahren: Sichtbarkeits-Baseline über mehrere Märkte, Ranking-URLs, Keyword-Chancen, Wettbewerber-Overlap, Backlink-Profil — abgeglichen mit unserer Next.js-Codebase zu Canonical-Tags, hreflang und Sitemaps. Ergebnis: eine priorisierte Roadmap, kein Bauchgefühl.

Alles begann mit einem Prompt:

Use the SISTRIX MCP to develop a sophisticated SEO strategy for https://hallocasa.com/

Keine Keyword-Spreadsheets, kein ausgefeilter System-Prompt — nur Domain und Tool. Von dort zog der Agent SISTRIX-Daten Markt für Markt, las unser Repo und machte daraus ein Strategie-Dokument mit priorisierten Stufen.

Dieser Post beschreibt den Workflow: was SISTRIX und sein MCP sind, warum MCP für SEO relevant ist, und was die Daten über hallocasa.com erzählt haben.

Was ist SISTRIX?

SISTRIX ist eine deutsche SEO-Plattform, weit verbreitet im DACH-Raum und darüber hinaus. Die Leitmetrik ist der Sichtbarkeitsindex — ein Score aus Ranking-Positionen und Suchvolumen über alle Keywords, für die eine Domain rankt. Dazu kommen Keyword-Rankings, Backlink-Daten, Wettbewerber-Overlap, Suchintention und (neuer) AI-Visibility-Tooling.

Für eine Site wie HalloCasa — globales Maklerverzeichnis, LatAm-lastige Länderliste, deutschsprachiger Expat-Content im Blog — ist SISTRIX nützlich, weil man nach Land slicen kann (de, us, co, es, mx, …) und Märkte in einer Session vergleicht, statt anzunehmen, ein Google-Index passe für alle.

Warum MCP für SEO-Tools?

Das Model Context Protocol (MCP) ist ein offener Standard, mit dem KI-Assistenten externe Tools über eine einheitliche Schnittstelle aufrufen. Ohne MCP raten Chatbots oder halluzinieren Metriken. Mit MCP ziehen sie Live-Daten aus der SEO-Plattform.

Ohne MCP	Mit MCP
Tab-Hopping, manuelle Exports	Agent fragt Live-Daten im Chat ab
Veraltete Screenshots in Strategie-Docs	Reproduzierbare, datierte API-Pulls
SEO-Analyst und Entwickler in getrennten Tools	Agent gleicht Rankings und Repo ab

Unter Cursor → Settings → Tools & MCP verdrahtet man den SISTRIX-Server einmal. Der Agent ruft dann Tools wie domain_visindex oder keyword_domain_seo im normalen Chat auf — wie Dateien lesen oder Terminal-Befehle.

Workflow (Cursor + SISTRIX MCP + Codebase):

Schritt	Du	Agent
1	SEO-Audit deiner Domain anfragen	Ruft SISTRIX-MCP-Tools pro Markt auf
2	Agent auf Repo zeigen	Liest `seo.ts`, `MetaData.tsx`, `robots.txt`, Sitemaps
3	Strategie + Prioritäten anfragen	Synthetisiert Daten + Code-Funde zu actionable Doc

SISTRIX MCP einrichten

SISTRIX liefert einen offiziellen MCP-Server. Docs und Setup-Guides:

Ressource	Link
Haupt-Hub	Connection to AI with MCP
OAuth für alle Pläne (2025+)	SISTRIX MCP Servers Changelog
Technische Referenz	Technical Information MCP
ChatGPT-Setup	Setting up ChatGPT
Claude-Setup	Setting up Claude

Endpoint: https://api.sistrix.com/mcp/

Auth: OAuth funktioniert inzwischen auf allen SISTRIX-Plänen — einloggen, kein API-Key nötig. API-Keys gehen weiter auf Plus+, wenn man will. Laut SISTRIX-Docs verbrauchen MCP-Requests aktuell keine API-Credits (anders als direkte API-Calls). Für Cursor: MCP-Server mit demselben Endpoint plus OAuth oder API-Key in der MCP-Config.

SISTRIX-MCP-Tool-Oberfläche

Der MCP exponiert Dutzende Tools. Im HalloCasa-Audit haben wir diese Gruppen genutzt:

Kategorie	Beispiel-Tools	Was man lernt
Domain-Sichtbarkeit	`domain_visindex`, `domain_kwcount_seo`, `domain_ranking_distribution`	Footprint pro Markt, Page-1-Keyword-Anzahl
Keywords	`keyword_domain_seo`, `domain_opportunities`, `keyword_seo_metrics`	Was rankt, Near-Wins, Volumen und Intent
Wettbewerb	`domain_competitors_seo`, `domain_ideas`	Overlap und Content-Gaps
Links	`links_list`	Toxische vs. legitime Backlinks
AI-Sichtbarkeit	`ai_entity`	AEO-Baseline (unser HalloCasa-Entity-Call lieferte HTTP 500)
Projekte	`project_ranking`, `project_visibilityindex`, …	Laufendes Tracking, sobald ein Projekt existiert

country als ISO-Code übergeben (de, us, co, es, mx, …), um mehrere Märkte in einer Session zu auditieren. So sahen wir: Deutschland hat Historie, Kolumbien und Mexiko praktisch keine Sichtbarkeit.

HalloCasa Case Study: Was die Daten zeigten

Domain: hallocasa.com. Der Agent zog SISTRIX-Daten über unsere Hauptmärkte (DE, US, ES, CO, MX).

Baseline-Snapshot

Deutschland ist der einzige Markt mit relevanter organischer Historie — die Sichtbarkeit ist seit einem Peak vor ein paar Jahren stark gesunken. USA und Spanien zeigen Spuren (meist Blog-Content). Kolumbien und Mexiko haben trotz Kern-Geschäftsgeografie praktisch keinen organischen Footprint.

Diese Diskrepanz zwischen Business-Fokus und Search-Sichtbarkeit war der erste große Insight — sichtbar nur, weil wir pro Land abgefragt haben statt Google als einen globalen Index zu behandeln.

Wo Rankings wirklich liegen

Fast der gesamte SEO-Wert sitzt auf blog.hallocasa.com, meist deutsche Artikel zu LatAm-Immobilien (Chile, Kolumbien, Peru, Argentinien, Mexiko). Das Verzeichnis (www.hallocasa.com) rankt im Vergleich kaum — ein paar Makler-Namen-Profil-Queries, sonst wenig.

Kernbefund: Autorität strandet auf einer Subdomain, fließt nicht zu Makler-Profilen und /brokers. Strukturproblem, kein Content-Gap.

Near-Win-Keywords (schnellster Ranking-Upside)

SISTRIX domain_opportunities zeigte mehrere deutsche Keywords, bei denen wir schon auf Seite 2 ranken — grenzüberschreitende Investment- und Expat-Immobilienthemen mit relativ geringem Wettbewerb. Die auf Seite 1 zu schieben ist weniger Aufwand als neue Head-Terms.

Wettbewerber (DE organischer Overlap)

Die Overlap-Menge mischt große deutsche Immobilienportale, internationale Luxury-Listing-Sites und Nischen-Expat-/Investment-Blogs. Wir konkurrieren nicht um generische deutsche Portal-Head-Terms; unsere Nische ist grenzüberschreitender / Expat-Investor-Content.

Backlinks: meist Rauschen

Das Linkprofil wird von SEO-Verzeichnis- und PBN-Spam dominiert. Legitime Links gibt es, aber spärlich — Partner-Podcasts, Reise-Sites, Konferenz-Medien. GSC-Audit vor Disavow sinnvoll; Google ignoriert offensichtlichen Spam oft von selbst.

Code-Abgleich: Warum das Verzeichnis nicht rankt

Der Agent las unser Next.js-Repo parallel zu SISTRIX-URLs. Technische Punkte, die schwache Verzeichnis-Sichtbarkeit erklären:

i18n via ?lang= im Verzeichnis, aber Canonical-URLs strippen den Query — alle neun Locales kollabieren auf eine indexierbare URL pro Pfad.
Kein hreflang; Blog und Home nutzen Pfad-Locales (/de/, /es/), Apex Query-Locales.
Fragmentierte Architektur: blog., home. und Apex als getrennte Properties; der Blog hält die Rankings.

International SEO fixen und Blog-Autorität auf die Hauptdomain konsolidieren sind Grundlagen, bevor Content in CO/MX skaliert wird.

Priorisierte Roadmap (90-Tage-Perspektive)

Aus dem Audit haben wir Aktionen nach Aufwand vs. Impact gestaffelt:

P0 — zuerst (Wochen 1–4)

Aktion	Warum
GSC-Domain-Property + Baseline-KPIs	Ohne Messung geht nichts
`www`-Canonical + 301 aller Host-Varianten	Stoppt gesplittete Link-Equity
Blog → Verzeichnis-CTAs auf Top-DE-Posts	Rankings da; Verzeichnis bekommt keinen Traffic
Cross-Links Blog ↔ `/brokers` ↔ Profile	Partielle Autoritäts-Übertragung ohne Migration

P1 — höchster SEO-Upside (Wochen 4–16)

Aktion	Warum
Near-Win-DE-Blogposts optimieren	Schnellste Ranking-Wins
Blog → `/blog/`-Subfolder-Konsolidierung	Größter struktureller Lift fürs Verzeichnis
Pfad-Locales + `hreflang` auf Apex	Pflicht vor ES/EN-Skalierung
DE-Pillar-Hub für grenzüberschreitendes Investment	Commercial-Intent-Cluster

P3 — Long Bets

Spanische LatAm-Programmatic-Pages (CO/MX) erst, wenn Makler-Bestand mitspielt — leere City-Templates wären Thin-Content-Risiko.

Workflow replizieren

SISTRIX MCP in Cursor verdrahten — Endpoint https://api.sistrix.com/mcp/, Setup-Docs, OAuth oder API-Key.
Mit klarer Anfrage starten — z. B. Use the SISTRIX MCP to develop a sophisticated SEO strategy for https://hallocasa.com/ (das war mein kompletter Start-Prompt).
Multi-Market-Baseline anfragen — domain_visindex und domain_kwcount_seo pro Land.
Ranking-URLs ziehen — keyword_domain_seo, um zu sehen, welche Subdomain oder welcher Pfad wirklich rankt.
Chancen, Wettbewerber, Backlinks — domain_opportunities, domain_competitors_seo, links_list.
Codebase auditieren — Canonicals, hreflang, robots, Sitemaps, i18n-Patterns.
Synthetisieren — Strategie-Doc mit priorisierten Stufen, kein Data-Dump.

Beispiel-Deliverable: HalloCasa SEO-Strategie (PDF)

Die Agent-Session lieferte ein vollständiges Strategie-Dokument — Baseline pro Markt, Wettbewerber-Overlap, technische Findings aus unserem Next.js-Repo und eine P0–P3-Roadmap. Als PDF für Stakeholder exportiert (pandoc + headless Chrome aus dem Markdown in hallocasa-next/misc/seo).

PDF herunterladen · Markdown-Quelle

Ähnliches für deine Domain? Ich helfe Teams, denselben SISTRIX-MCP- plus Codebase-Audit-Workflow zu fahren und daraus ein priorisiertes Strategie-Dokument zu machen. LinkedIn.

Takeaways für andere Sites

MCP macht SEO von Dashboard-Archäologie zu agent-native Research. Der Agent zieht Live-SISTRIX-Daten, während du im Editor bleibst.
Am besten, wenn der Agent auch dein Repo lesen kann. Rankings sagen was rankt; Code sagt warum Fixes schwer oder leicht sind.
Multi-Subdomain-Setups brauchen eine explizite Architektur-Entscheidung — konsolidieren (z. B. Blog → /blog/) oder stark verlinken; Autorität überträgt sich nicht von selbst.
Near-Win-Keywords priorisieren vor Greenfield-Programmatic-SEO oder Neun-Locale-Übersetzungs-Marathons.
Marktdaten an Business-Fokus anpassen. Kaum Sichtbarkeit in CO/MX trotz LatAm-Kerngeografie — die Diskrepanz sieht man nur bei Abfrage pro Land.

Was als Nächstes bei HalloCasa

Dieser Post geht um die Research-Methode — aber das Audit lieferte eine klare Roadmap, und ich freue mich auf die Umsetzung: P0-Fixes zuerst, dann DE-Near-Win-Posts und Blog-Konsolidierung. SISTRIX bleibt für laufendes Tracking drin, nicht nur diese Session.

Dasselbe MCP-Setup öffnet GEO (Generative Engine Optimization): SISTRIX’ AI-Visibility-Tools (ai_entity und verwandtes Project-Tooling) erlauben eine Baseline, wie HalloCasa in KI-Antworten auftaucht, und Messung des Lifts beim Fixen von Struktur und Content. Unser erster ai_entity-Call lieferte 500 — Retry lohnt sich nach den Grundlagen.

Ich bin Co-Founder von HalloCasa und nutze MCP auch sonst im Stack (siehe Wie ich OpenClaw nutze für einen anderen Blick auf Agent-Tooling). Wer Hilfe beim Verdrahten von SISTRIX MCP in Cursor oder ein ähnliches Audit auf der eigenen Domain will: LinkedIn.

Danke an Benedikt Rudolf von SISTRIX, dass er sich die Zeit genommen hat, mir den MCP vorzustellen — dieses Gespräch hat den Workflow angestoßen.

Mit Lovable gebaut? Prod in Deutschland & DACH auf Hetzner hosten

Mon, 08 Jun 2026 00:00:00 GMT

Du hast mit Lovable gebaut — React-App, Supabase-Auth, Postgres. Es funktioniert. Dann fragt dein erster DACH-Kunde oder Pilot: Wo läuft Prod? Wo liegen Login und Daten? Die Frage kommt in Deutschland, Österreich und der Schweiz im B2B schnell — besonders in HR, Health, Finance und allem, was Procurement oder ein Security-Fragebogen berührt.

Warum „EU reicht“ in DACH oft nicht genug ist

Lovables Standardweg — Netlify (oder ähnlich) plus managed Supabase — ist super zum Bauen. Für Prod, auf das du in einem Buyer-Review zeigen kannst, reicht das nicht immer.

Deutschland — DSGVO, Vendor-Fragebögen, und „EU-Hosting“ heißt oft benennbare EU-Infrastruktur, nicht „wir nutzen irgendwo eine US-Cloud in eu-west-1.“
Österreich — Gleicher DSGVO-Rahmen; viele Käufer spiegeln deutsche Erwartungen zu Datenstandort und Subprozessoren.
Schweiz — Nicht in EU/DSGVO, aber starke Datenschutzerwartungen (revDSG). Hetzner — deutsches Unternehmen, EU-Rechenzentren — ist für viele Schweizer Käufer eine glaubwürdige Antwort, ohne Compliance zu überverkaufen.

Das ist keine Rechtsberatung. Es ist die praktische Reibung, wenn DACH-Kunden eine klare Antwort wollen, wo Prod läuft.

Phased Prod auf Hetzner — Dev bleibt auf Lovable

Du brauchst keine Big-Bang-Migration. In einer kürzlichen Fallstudie mit deutschem Kunden blieb Dev auf Netlify + managed Supabase, während Prod — App, Login, Postgres — live auf Hetzner in der EU ging. Gleiches Muster passt zu Lovable-Stacks: weiter in Lovable bauen; eine DACH-facing Prod-Umgebung auf EU-VMs ergänzen.

Fallstudie:

Produktion auf Hetzner (Teil 1) — phased EU-Prod, OpenTofu, CI-Deploys, self-hosted Supabase
Self-hosted Insights (Teil 2) — Observability, Kosten-Guardrails, EU-Telemetrie

Prod-Nutzer treffen die React-App auf Hetzner. Sign-in und Postgres für Prod bleiben ebenfalls auf Hetzner. Dev nutzt Lovables Stack unverändert weiter.

Open-Source-Stack — kein Black-Box-Prod

DACH-Käufer fragen oft nicht nur wo Daten liegen, sondern welche Software dort läuft. Der Prod-Weg, den wir nutzen, baut auf Open Source, die du benennen, prüfen und selbst betreiben kannst — kein proprietäres PaaS, das du nicht inspizieren kannst.

Layer	Open Source
Infra as Code	OpenTofu (ein Open-Source-Fork von Terraform)
App-Runtime	React (von Lovable), nginx
Auth + API + DB	Supabase (self-hosted), Postgres
Observability	Grafana, Prometheus, Loki, Tempo, OpenTelemetry

Das zählt in Security Reviews: Subprozessoren und Komponenten sind identifizierbar. Du bist für Prod nicht in die Managed-Layer eines einzelnen Vendors eingesperrt. Hetzner liefert VMs; der Stack darauf bleibt portabel und forkbar.

Was ich übernehme vs. was du weiter machst

Du: Features in Lovable weiter shippen.

Ich: OpenTofu (Server, Firewall, DNS), GitHub-Actions-Deploys, self-hosted Open-Source-Supabase auf Prod-VMs und self-hosted Observability (Grafana LGTM, Kosten-Alerts) — die Dokumentation, die DACH-Käufer oft fragen: wo Daten liegen, was dort läuft, wer Prod betreibt, was es kostet.

Ich arbeite mit DACH-Kunden genau auf diesem Pfad. Wenn das dein nächster Schritt klingt, melde dich.

office@martinmueller.dev · calendly.com/martinmueller_dev · LinkedIn

Weiterlesen

Produktion auf Hetzner für einen deutschen Kunden — EU-Hosting (Teil 1)

Fri, 05 Jun 2026 00:00:00 GMT

Teil 2: Self-hosted Insights auf Hetzner

Ein deutscher Kunde brauchte Produktion in der EU auf Hetzner — klare Kontrolle darüber, wo Kundendaten und Login liegen. Das Produkt ist Arc Rider Universe: die SaaS hinter universe.arc-rider.com — Mission: Interface, ein UI-Toolkit für Builder (Tabellen, Kanban, Gantt, Layouts und mehr per JSON statt handgeschriebener UI-Code). Dev lief bereits problemlos auf Netlify und managed Supabase — und tut das weiterhin. Ziel war eine dedizierte Prod-Umgebung auf Hetzner, keine Big-Bang-Migration, die das Team ausbremst.

Warum Hetzner, und warum nicht „alles auf einmal umziehen“

Der Kunde sitzt in Deutschland. Prod musste auf EU-Infrastruktur, auf die er verweisen kann — Hetzner-VMs für App und Datenbank.

Das hieß nicht, Dev anzufassen:

dev.universe.arc-rider.com (Dev) bleibt auf Netlify + managed Supabase.
Prod — App, Login, Postgres — läuft auf Hetzner unter universe.arc-rider.com.

Wenn du Ähnliches planst: EU-Prod auf Hetzner geht an einem Wochenende — ohne Dev umzuplatformen.

Wie Prod aussieht (kurz erklärt)

Prod-Nutzer öffnen die React-App auf Hetzner. Anmeldung und Daten für Prod liegen ebenfalls auf Hetzner. Dev nutzt weiter Netlify und managed Supabase unverändert.

Infra und Deploys sind automatisiert mit OpenTofu (Server, Firewall, DNS) und GitHub Actions (Build, Deploy, kurze Smoke-Checks nach einem Release).

Sobald Prod stabil war, kam self-hosted Observability auf einer dedizierten VM dazu — Metriken, Logs, Traces, Kosten-Wächter und agentenfreundlicher Betrieb. Siehe Teil 2.

Was wir gelernt haben (Kurzfassung)

Phasenweise schlägt Big Bang — Dev blieb auf Netlify + managed Supabase, während Hetzner-Prod live ging.
Self-hosted Login ist kein Copy-Paste aus Cloud-Supabase — Prod-OAuth und Magic Links brauchen prod-spezifische URLs und Config; Dev-Config bleibt getrennt.
Planbare Kosten und EU-Hosting — VMs auf Hetzner für App, Login und Daten.

Prod ist live unter universe.arc-rider.com. Für diese Produktphase hat der Tradeoff gepasst: Kontrolle dort, wo es zählt — auf EU-Infrastruktur, auf die der Kunde verweisen kann.

Hetzner-Migrationen — wie ich helfen kann

Netlify, managed Supabase oder AWS für Dev und Prod in der EU auf Hetzner nötig? Ich helfe bei Planung, OpenTofu, CI-Deploys, self-hosted Supabase auf Prod-VMs und self-hosted Observability (Grafana LGTM, Alloy, Kosten-Wächter, Grafana MCP für agentenfreundlichen Betrieb).

office@martinmueller.dev · calendly.com/martinmueller_dev · LinkedIn

Weiterführende Links

Self-hosted Insights auf Hetzner — Observability, Kosten, KI-Agenten (Teil 2)

Fri, 05 Jun 2026 00:00:00 GMT

Teil 1: EU-Produktion auf Hetzner

Nachdem Prod auf Hetzner live ging — React-App, self-hosted Supabase-Login, Postgres auf EU-VMs; Dev weiter auf Netlify + managed Supabase — kam self-hosted Observability auf einer dedizierten Prod-VM dazu. Metriken, Logs, Traces und Kostendaten bleiben in der EU. Kein APM-SaaS von Drittanbietern. Danach haben wir KI-Agenten angebunden, die Prod über Grafana MCP abfragen — statt SSH-Rätselraten.

Insights ohne die EU zu verlassen

Wir haben self-hosted Observability auf Hetzner ergänzt: OpenTelemetry-Ingest, Grafana LGTM (Prometheus, Loki, Tempo) und Grafana-Alloy-Agenten auf den Static- und Supabase-VMs. Browser-RUM sowie Edge-Function-Traces und -Logs exportieren in denselben Stack — nichts verlässt die EU für die Frage „wie läuft Prod?“

Provisionierte Dashboards (Git → Redeploy):

Dashboard	Was es zeigt
Data health	Fließen Metriken, Logs und Traces?
Prod Overview	Prod-Gesundheit auf einen Blick
Infrastructure USE	CPU, RAM, Disk auf den VMs
nginx RED	Request-Rate, Fehler, Dauer aus JSON-Access-Logs
Supabase Docker	Container-Health auf der API-VM
Postgres	Verbindungen, Query-Stats
Frontend RUM	Browser-Traces (Tempo)
Edge Functions	Edge-Traces + App-Logs in Loki

Warum das für Kunden zählt: Datadog-Klasse Sichtbarkeit, ohne Telemetrie an US-SaaS zu schicken oder per SSH zu raten. Dashboards und Alert-Regeln liegen in Git; Google OAuth schützt die Grafana-UI.

Planbare Kosten, automatisch im Blick

Hetzner-Preise sind transparent — aber drei VMs, Backups, Primary IPs und Volumes summieren sich. Wir haben ein Production Costs-Dashboard angebunden, das live Hetzner-API-Preise in Prometheus zieht (arc_infra_cost_eur_monthly): Aufschlüsselung pro Server, Backup, Volume und Primary IP, plus monatliche und jährliche Projektion.

Ein Grafana-Alert feuert, wenn die geschätzte Infra-Kosten 50 EUR/Monat erreichen — E-Mail an die Ops-Liste, bevor die Rechnung überrascht. Das Gegenteil von undurchsichtigen Cloud-Rechnungen, bei denen man den Spike erst in der Console entdeckt.

KI-Agenten mit echten Tools

Vieles wurde mit KI-Assistenten im Loop designed, debuggt und betrieben (Cursor, Claude Code). Die wichtigste Erkenntnis: Sobald Grafana self-hosted auf Hetzner läuft, kann man Agenten auf Prod selbst zeigen — nicht nur auf Docs und IaC.

Mit Grafana MCP (mcp-grafana via uvx) und einem read-only Viewer-Service-Account-Token kann ein Agent:

PromQL ausführen (Host-CPU, Postgres-Verbindungen, Kosten-Metriken)
LogQL ausführen (nginx-Access-Logs, Edge-Function-Output)
Dashboards suchen und Panels zusammenfassen
Alert-Regeln listen und Firing-Status prüfen

Das machte aus „etwas ist langsam in Prod“ einen Loop: Agent fragt Grafana ab → findet Panel oder Log-Stream → schlägt Fix in Git/CI vor oder wendet ihn an — ohne SSH-Rätselraten. Tool-Freigabe bleibt an in Cursor; Token ist read-only; Infra- und Schema-Änderungen laufen weiter über OpenTofu und CI.

Unter Cursor → Settings → Tools & MCP verdrahtet das Projekt MCP-Server plus die üblichen CLIs:

Tool	Wofür wir es nutzen
hcloud CLI	Server, IPs, Firewalls vom Terminal prüfen
OpenTofu CLI	Infra planen und anwenden (VMs, Firewall, DNS)
OpenTofu MCP (`@opentofu/opentofu-mcp-server` via `npx`)	Provider-Docs im Chat nachschlagen (read-only)
Supabase CLI	Migrationen und Schema-Arbeit in Git
Supabase MCP (offizielles hosted MCP)	Tabellen inspizieren, read-only SQL, Logs und Docs
Grafana MCP (mcp-grafana via `uvx`)	PromQL, LogQL, Dashboards, Alerts auf self-hosted Grafana

{
 "mcpServers": {
  "supabase": {
   "url": "https://mcp.supabase.com/mcp?project_ref=YOUR_REF&read_only=true"
  },
  "opentofu": {
   "command": "npx",
   "args": ["-y", "@opentofu/opentofu-mcp-server"]
  },
  "grafana": {
   "command": "uvx",
   "args": [
    "mcp-grafana",
    "--disable-admin",
    "--disable-oncall",
    "--disable-incident"
   ],
   "env": {
    "GRAFANA_URL": "https://grafana.prod.universe.arc-rider.com",
    "GRAFANA_SERVICE_ACCOUNT_TOKEN": "YOUR_GRAFANA_SERVICE_ACCOUNT_TOKEN"
   }
  }
 }
}

Zusammen mit Runbooks fühlte sich das näher an IaC plus Observability plus CLIs als an „SSH auf einen Pet-Server und hoffen“. Applies laufen weiter über OpenTofu/CI; MCP ist für Lookup, Schema, Logs und Prod-Queries — keine stillen Infra- oder Schema-Writes.

Was wir gelernt haben (Kurzfassung)

Observability auf Hetzner ist ein Produkt-Asset — Metriken, Logs und Traces in der EU, aus Git provisioniert, kein APM-SaaS-Lock-in.
Planbare Kosten und EU-Hosting — Kosten-Dashboard + Budget-Alert, damit Ausgaben sichtbar bleiben, bevor die Rechnung überrascht.
KI-Agenten glänzen auf self-hosted Grafana — Grafana MCP + read-only Token lässt Agenten Prod untersuchen (PromQL, LogQL, Dashboards) statt per SSH zu raten.

Prod ist live unter prod.universe.arc-rider.com. Für diese Produktphase hat der Tradeoff gepasst: Kontrolle dort, wo es zählt — auf EU-Infrastruktur, auf die der Kunde verweisen kann, inklusive wie Prod überwacht wird und was es kostet.

Hetzner-Migrationen — wie ich helfen kann

office@martinmueller.dev · calendly.com/martinmueller_dev · LinkedIn

Weiterführende Links

AI Softwareentwicklung mit Ninox und arcBot

Wed, 14 Feb 2024 00:00:00 GMT

KI beflügelt die Unternehmenslandschaft. Viele einfache und komplexe Prozesse im Unternehmen können durch AI stark vereinfacht oder sogar komplett automatisiert werden. Jakob mein Co-Founder und ich sehen es als spannende Herausforderung, wie wir den Zugang zu AI für kleine und mittelständische Unternehmen vereinfachen können. Wir glauben mit der Low Code Plattform Ninox und unserem AI Chatbot arcBot einen spannenden Ansatz gefunden zu haben. In diesem Blogpost möchte ich euch diesen Ansatz vorstellen.

Ninox.com

Ninox.com ist eine cloudbasierte Low-Code-Plattform zum Bau von Softwarelösungen für kleine und mittelständische Unternehmen. Ninox wurde 2013 in Deutschland von Frank Böhmer gegründet. Hier einige Möglichkeiten, wie Ninox Unternehmen unterstützen kann:

Automatisierung der Geschäftsprozesse: Mit Ninox können Unternehmen ihre täglichen Aufgaben und Prozesse automatisieren und so ihre Effizienz steigern.

Anpassbarkeit: Da Ninox eine Low-Code-Plattform ist, können Unternehmen ihre Anwendungen ohne komplexe Programmierkenntnisse an ihre spezifischen Bedürfnisse anpassen.

Integration: Ninox kann mit einer Vielzahl anderer Tools und Plattformen integriert werden, was einen nahtlosen Datenaustausch zwischen verschiedenen Systemen ermöglicht.

Kosteneffizienz: Verglichen mit der Entwicklung einer benutzerdefinierten Software von Grund auf, kann die Verwendung einer Low-Code-Plattform wie Ninox zu erheblichen Kosteneinsparungen führen.

Schnelle Implementierung: Mit Ninox können Unternehmen ihre Anwendungen schnell erstellen und implementieren, was zu einer schnelleren Markteinführung führt.

Vor einigen Monaten habe ich mit Ninox ein MVP erstellt. Meine gesammelten Erfahrungen können hier nachgelesen werden. Im nächsten Kapitel erkläre ich, wie wir mit arcBot den Build für deine Softwarelösung in ninox vereinfachen.

arcBot

Der arcBot ist eine ChatGPT-ähnliche KI zum schnellen Erstellen und Modifizieren von Ninox-Tabellen. Wir benutzen die AWS Bedrock API um die Ninox Tabellen Antworten zu erstellen. Ein Beispiel Prompt zum erstellen von Ninox Tabellen könnte wie folgt aussehen:

Create customer and product tables in a many to many relationship.

Cool oder? arcBot erstellt viele Tabellen für Kunden und Produkte. Bemerkenswert ist, dass arcBot sogar die ninox-typischen inversen Felder setzen kann. Im nächsten Prompt wollen wir den Last Name zu einem Customer hinzufügen.

Add last name to customer table

Für die Antwort verwendet arcBot das Claude v2.1 model, das über die AWS Bedrock API zur Verfügung gestellt wird.

Wie stellen wir sicher, dass die Qualität der Antworten so hoch wie möglich ist? Wir haben eine Feedbackschleife eingebaut. Der Nutzer kann nach der Antwort Feedback geben. Dieses Feedback wird dann zur Verbesserung von arcBot verwendet.

Ich stehe auch in engem Kontakt mit anderen Gen AI Experten, die mir helfen, die Qualität der arcBot Antworten zu verbessern. An dieser Stelle möchte ich mich bei diesen Experten bedanken. Es sind hauptsächlich AWS Community Mitglieder und AWS Mitarbeiter die mir schon viele wertvolle Tipps gegeben haben. Vielen Dank 🙏

Ninox Connector

Es ist cool, dass wir mit arcBot Ninox Tabellen erstellen können, aber wie können wir die Daten in Ninox weiterverarbeiten? Hier kommt der Ninox Connector ins Spiel. Der Ninox Connector kann Ninox Tabellen lesen und aktualisieren. Das folgende Bild zeigt den Ninox Connector.

Der Ninox Connector benötigt einige Informationen wie die Ninox Url, Team Id, Database Id und den Ninox API Key. Zurzeit is der Ninox Connector nur über den Early Access verfügbar. Dieser ist aber ganz leicht auf https://app.arcbot.de/ zu bekommen.

Discord Community

Werdet Teil unserer Discord Community. Wir haben bereits einige Member welche uns wertvolles Feedback und Feature Wünsche zu dem arcBot mitteilen.

Zusammenfassung

In diesem Blogpost habe ich euch gezeigt, wie wir durch die Kombination von Ninox und arcBot das Erstellen und Aktualisieren von Ninox-Tabellen vereinfachen. Wir freuen uns auf euer Feedback. Vielen Dank fürs Lesen.

Ich liebe es, an Open-Source-Projekten zu arbeiten. Viele Dinge kannst du bereits frei nutzen auf github.com/mmuller88. Wenn du meine Arbeit dort und meine Blog-Posts toll findest, denke doch bitte darüber nach, mich zu unterstützen:

Oder

Und schau doch mal auf meiner Seite vorbei

AWS User Group (UG) Meetups organisieren

Fri, 09 Jun 2023 00:00:00 GMT

AWS UG Meetups sind eine tolle Möglichkeit um sich mit anderen AWS Enthusiasten auszutauschen. Ich zeige dir wie ich das AWS UG Lisbon Meetup organisiert habe.

Vorgeschichte

Anfang 2023 sind wir von Deutschland nach Lissabon in Portugal umgezogen. Mit Entsetzen habe ich festgestellt, dass es keine AWS Meetup Events in Lissabon gibt. Also habe ich mich entschieden die Organisierer des AWS UG Meetup anzuschreiben und meine Hilfe anzubieten. Die wurde dankend angenommen und ich bin seit Anfang des Jahres 2023 ein Co-Organisierer des AWS UG Lisbon Meetup.

Mein erstes Meetup als Organisierer

Ich zeige wie ich das AWS UG Lisbon Meetup organisiert habe
Seit Anfang des Jahres 2023 bin ich ein Co-Organisierer des AWS UG Lisbon Meetup.
Nutze Meetup.com zur Bekanntmachung des Meetup Event. Selbst wenn wir die Speakers noch nicht bestimmt haben.
Nutze Google Forms zum sammeln der Speaker Talks
Meetup Organisierer voten dann welchen Tag sie gerne hören würden

Outlook

Wie können wir die Meetup Erfahrung verbessern

...

Outlook

In one of my next posts, I give you deeper insight into the T3 Stack like how it works. I also show you how to use it to develop a Prototype or MVP.

A huge thanks to the T3 Stack community for their hard work and support. And a special thanks to Theo for creating this amazing stack and thriving it. I love your content on YouTube. Keep up the amazing work!

I hope you enjoyed this post and I look forward to seeing you in the next one.

I love to work on Open Source projects. A lot of my stuff you can already use on https://github.com/mmuller88 . If you like my work there and my blog posts, please consider supporting me on the:

And don't forget to visit my site

Chat Indexieren mit Chatsindex.com

Tue, 21 Mar 2023 00:00:00 GMT

Möchtest du deine Chat Community vergrößern? Chatsindex.com indexiert Chat-Messages und macht diese auffindbar für Suchmaschinen wie Google. Zugegeben es wird das machen weil es zurzeit noch ein Prototype ist! Durch SEO (Search Engine Optimization) wird sichergestellt, dass die Einträge möglichst hoch in den Suchergebnissen erscheinen. So können neue User auf deinen Discord Server gelockt werden.

Nachfolgend siehst du ein Beispiel wie ein Discord Channel und die Suchergebnisse aussehen können:

Die Google Seite ist dabei nur gemocked (Chatsindex.com/search) da es sich noch um einen Prototypen handelt.

Wie funktioniert es?

Ein Discord Bot schreibt die Nachrichten in eine Datenbank. Die Datenbank wird dann von einem NextJS Server abgefragt und in eine Suchmaschinen optimierte Seite (SEO) gerendert. Die Seite wird dann von Google gecrawlt und die Einträge sind dann auffindbar.

Der Prototyp ist mit dem T3 Stack erstellt. Der T3 Stack ist ein NextJS Stack mit TailwindCSS, tRPC und Prisma. Die Datenbank besteht zurzeit noch aus SQLite und wird mit tRPC und Prisma abgefragt. Die Seite wird mit NextJS und TailwindCSS gerendert.

Probanden

Klingt diese Idee interessant für dich? Dann melde dich gerne bei mir https://MartinMueller.dev. Ich suche Probanden mit Discord Servern um die Idee zu testen.

Ausblick

Falls die Idee gut ankommt, möchte ich gerne andere private Chatsysteme wie WhatsApp Gruppen, Telegram Gruppen, Slack, etc. indexieren.

Eine weitere Idee von mir ist eine übergreifende Suche für private Chats wie Discord, WhatsApp Gruppen, Telegram Gruppen und Slack zu implementieren. Mit bestimmten Schlagwörtern oder Kategorien können dann private Chats mit bestimmten Themeninhalten gefunden werden. Zum Beispiel wenn ich mich für finanzielle Bildung interessiere, kann ich dann einfach in der Suche Finanzen eingeben und es werden mir Discord Server, WhatsApp/Telegram Gruppen usw. mit dem Themenschwerpunkt Finanzen vorgestellt. Wenn euch die Idee gefällt, wendet euch gerne an mich.

Fazit

Die Kombination aus SEO und Discord Servern empfinde ich als eine spannende Idee. Jetzt geht es mir erstmal darum die Idee zu testen und zu schauen ob es überhaupt eine Nachfrage gibt. Falls du Interesse hast, melde dich gerne bei mir.

Den T3 Stack zu verwenden hat viel Spaß gemacht und ich habe nur ein Wochenende benötigt für diesen Prototypen. Falls du Hilfe bei deiner Idee oder Projekten braucht, kontaktiere mich gerne.

Oder

Und schau doch mal auf meiner Seite vorbei

Amplify AppSync Permission

Sun, 05 Feb 2023 00:00:00 GMT

Hi,

Mit Amplify AppSync ist es möglich mit deklarativem Code ein AWS AppSync zu konfigurieren. Mit Directives wie @model, @auth oder @function können andere AWS Services wie DynamoDB, Cognito oder Lambda sinnvoll mit AppSync verbunden werden. Das macht es einem mächtigen Werkzeug. Mit nur wenigen Zeilen GraphQL Code kann quasi schon sehr viel in AWS konfiguriert werden.

Nachfolgend siehst du ein Amplify AppSync Beispiel:

type User
  @model
  @key(fields: ["email"])
  @auth(
    rules: [
      { allow: groups, groups: ["Admin"] }
      { allow: private, provider: iam }
      { allow: owner, ownerField: "email", identityClaim: "email" }
    ]
  ) {
  email: String!
  role: Role!
  ...
}

Hier passiert eine ganze Menge! Mit der @model Directive wird automatisch eine DynamoDB Tabelle mit dem Namen User erzeugt welche die User Einträge als DynamoDB Items speichert. Mit @key wird die email als PK (Partition Key) festgelegt. Die Permission, wer also auf die Items zugreifen darf, wird mit @auth definiert. Ein User in der Admin Group darf also alle Items querien, mutieren und subscriben.

Mit { allow: private, provider: iam } darf eine IAM Entität welche die erforderlichen Permissions besitzt ebenfalls die Items querien, mutieren und subscriben. Das verwende ich zum Beispiel bei Lambdas die bestimmte Aufgaben durchführen sollen wie dem Erstellen von neuen Usern in der Tabelle wenn sich diese zum ersten mal via Cognito anmelden.

Zu guter Letzt mit { allow: owner, ownerField: "email", identityClaim: "email" } dürfen Cognito User, welche sich über oauth2 identifiziert haben auf ihre Items zugreifen. Der identity claim email wird dabei über das Cognito JWT Token mitgeliefert und wird anschliessend mit der im Item definierten email abgeglichen.

Ziemlich cool oder? Mir nur diesen wenigen Zeilen Amplify AppSync GraphQL Code bekommen wir sehr viel Funktionalität.

Permission für Shared Items

Die Permission zu definieren mit @auth funktioniert sehr gut für einfache Fälle wie dem hier gezeigtem User Beispiel. Aber was ist wenn auf Items von mehreren Benutzern zugegriffen werden soll? Nun hier gibt es verschiedene Möglichkeiten die ich vorstellen möchte. Aber zuerst stelle ich die Tabelle mit den gemeinsam genutzten Items vor:

type Project
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["Admin"] }
      { allow: private, provider: iam }
    ]
  ){
  id: ID!
  projektNummer: Int!
  ...
}

Ein Project soll für mehrere User zugreifbar sein. Der wohl einfachste Ansatz wäre die User in einer String-List zu speichern.

String-List

Der Code muss dafür nur minimal angepasst werden mit:

type Project
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["Admin"] }
      { allow: private, provider: iam }
      { allow: owner, ownerField: "userEmails", identityClaim: "email" }
    ]
  ){
  id: ID!
  projektNummer: Int!
  userEmails: [String] # <-- User String-List
  ...
}

Die userEmails String-List muss nun einfach nur mit den emails von den Usern, die darauf zugreifen können, aktuell gehalten werden. Das Verwalten der userEmails ist aber aufwendig und erfordert zusätzlichen code und Platz im Item.

Virtuelle Lambda

Wir könnten aber auch eine virtuelle Lambda benutzen welche dynamisch berechnet ob der jeweilige User Zugriff haben soll oder nicht.

type Project
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["Admin"] }
      { allow: private, provider: iam }
      { allow: owner, ownerField: "userEmail", identityClaim: "email" }
    ]
  ){
  id: ID!
  projektNummer: Int!
  userEmail: String @function("userEmailLambda")
  ...
}

Die Lösung besticht durch den reduzierten Platz in der DynamoDB Tabelle. Bei einer grossen Menge an Items würde es aber eine grosse Anzahl an Lambda-Aufrufen bedeuten welche die Kosten in die Höhe treiben. Auch kann der Delay durch den Lambda-Aufruf zu signifikant sein.

JWT Claim

Diese Idee ist wohl die Kreativste. Über den pre-token-generation Trigger Lambda kann ein claim gesetzt werden welcher signalisiert, auf welches Item zugegriffen werden darf. Der Code für Amplify AppSync sieht in etwa so aus:

type Project
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["Admin"] }
      { allow: private, provider: iam }
      { allow: owner, ownerField: "id", identityClaim: "currentProjectId" }
    ]
  ){
  id: ID!
  projektNummer: Int!
  ...
}

Der Identity-Claim currentProjectId wird durch den pre-token-generation Trigger Lambda gesetzt. Diese Methode finde ich am elegantesten und verwende diese in meinen Projekten.

Der Code für die Lambda könnte in etwa so aussehen:

import AppsyncClient from 'appsync-client';
import * as lambda from 'aws-lambda';
import {
  CreateUserDocument,
  GetUserDocument,
  Role,
} from './../../stueli/src/lib/api';

const { APPSYNC_URL } = process.env;

const client = new AppsyncClient({ apiUrl: APPSYNC_URL });

/**
 * https://www.npmjs.com/package/appsync-client
 * @param event
 */
export async function handler(event: lambda.PreTokenGenerationTriggerEvent) {
  console.debug(`event: ${JSON.stringify(event)}`);

  const { getUser } = await client.request({
    query: GetUserDocument,
    variables: {
      email: event.request.userAttributes.email,
    },
  });

  console.debug(`getUser=${JSON.stringify(getUser ?? {})}`);

  event.response.claimsOverrideDetails = {
    claimsToAddOrOverride: {
      ...(getUser?.currentProjectId
        ? { currentProjectId: getUser.currentProjectId }
        : {}),
    },
  };

  console.debug(
    `event.response.claimsOverrideDetails=${JSON.stringify(
      event.response.claimsOverrideDetails,
    )}`,
  );

  return event;
}

Die Lambda ermittelt zuerst auf welches Project der User zugreifen darf mit currentProjectId und dann setzt sie das Claim currentProjectId:1234. Nun muss natürlich noch implementiert werden wie der User die currentProjectId überhaupt wechseln bzw. setzen kann und wie anschliessend das JWT Token neu geladen wird.

Bei mir passiert dass wenn der User über den React Router auf das Project klickt. Zuerst wird der currentProjectId Eintrag in der User Tabelle getätigt und dann wird mittels des JWT Refresh Tokens das JWT Token neu geladen. Wenn ihr das gerne im Detail haben möchtet, dann schreibt mir.

Fazit

Ich habe hier unterschiedliche Methoden vorgestellt wie Permissions mit der Amplify AppSync directive @auth realisiert werden können. Wenn ihr noch andere coole Ideen habt, dann lasst es mich gerne wissen.

Oder

Und schau doch mal auf meiner Seite vorbei

Mit ninox.com zum Prototypen deines SaaS Produkt

Sun, 29 Jan 2023 00:00:00 GMT

Hi,

Es macht mir viel Spaß unser SaaS Produkt zu entwickeln. In der Minimalempires Community habe ich einen tollen CoFounder mit einer tollen Idee gefunden. Mit der Low-Code Plattform ninox.com wollen wir diese Idee validieren und bauen ein Prototypen. Bisher hatte ich noch keine Erfahrungen mit Low-Code und konnte mir auch nicht vorstellen, dass solche nützlich für mich sind, da ich bereits viel Erfahrung mit Frontend und Backend besitze. Ich wurde ganz klar eines besseren belehrt! In den nächsten Absätzen will ich erklären was ninox.com ist und wie es uns hilft einen Prototypen zu entwickeln.

ninox.com

Ninox.com ist eine Cloud-basierte low-code Plattform zum Bauen von Softwarelösungen für kleine und mittelgrosse Unternehmen. Ninox wurde 2013 von Frank Böhmer in Deutschland gegründet. Stand 2021 zählte Ninox mehr als 6.000 Kunden. Erwähnenswert ist auch der YouTube-Kanal von Ninox mit viel Content über Ninox. Sowie auch die wöchentlich stattfinden Open Office Hours in englischer und deutscher Variante. Bei diesen können Kunden ihre Fragen und Probleme über ninox einem ninox Mitarbeiter*innen stellen.

Meine Erfahrung mit ninox.com

Die Entwicklung eines Prototypen geht mit ninox.com super schnell. Die Definition der Tabelle, also welche Spalten und Spaltentypen die jeweilige Tabelle inne hat, dient quasi auch zur Erstellung der UI. Somit kann super schnell ein Datenmodell und eine darauf aufbauende UI entwickelt werden. Ninox.com hat sich echt coole in pfiffige Ideen überlegt wie eine Datenbanken sinnvoll und nativ mit einer konfigurierbaren UI verbunden werden kann.

Auch die bereits vorhandene Userverwaltung funktioniert sehr gut. Damit lassen sich einfache Rollen und Permission Schemata gut abbilden.

Die Community von ninox.com ist sehr aktiv und super hilfsbereit. Diese hat mir immer weitergeholfen wenn ich Probleme bei der Implementierung hatte. Probleme bei der Implementierung hatte ich hauptsächlich nur wenn ich die ninox.com native Programmiersprache verwenden musste. Das war zum Beispiel der Fall wenn die Datenbank queries brauchte und auf diesem bestimmte Berechnungen machen musste.

Mit ninox.com zum vollständigen Produkt?

Nein! Wir stossen wir jetzt schon auf Limitationen die mit herkömmlichen Tech-Stacks wie MERN leichter behebbar wären. Auch das fehlen einer Git-Integration was die Entwicklung schwerer macht, da wichtige Tools wie Versionierung und Pull Requests fehlen.

Fazit

Ninox is super für die schnelle Entwicklung eines Prototypen. Darüber hinaus eignet es sich wahrscheinlich nicht für die Entwicklung eines SaaS Produkts. Das war und ist auch nicht der Use-Case von ninox.com weshalb das auch total ok ist. Trotzdem bin ich super beeindruckt wie gut es sich für unseren Prototypen geeignet hat und bin mehr als bereit ninox.com wiederzuverwenden!

Vielen Dank auch an meinen CoFounder. Es macht mir super viel Spass mit dir zusammen an unserem Produkt, Vision und Zukunft zu arbeiten. Du bist super motiviert und engagiert. Ich freue mich schon wahnsinnig auf unsere weitere Zusammenarbeiten 2023 :)!

Oder

Und schau doch mal auf meiner Seite vorbei

TypeScript Lambda mit cdktf

Sat, 17 Dec 2022 00:00:00 GMT

Hi,

In diesem Blog-Post möchte ich kurz erklären, was cdktf ist und wie man damit eine TypeScript-Lambda erstellen kann. Die Motivation dafür kam durch einen StackOverflow-Beitrag. Zunächst erkläre ich kurz, was cdktf überhaupt ist und wie man es initialisiert. Anschließend zeige ich die Lösung für die TypeScript-Lambda.

Was ist cdktf?

Das Cloud Development Kit for Terraform (cdktf) ist ein Toolkit zum Erstellen und Verwalten von Cloud-Infrastruktur wie AWS oder Azure mit Terraform. Es ermöglicht es dir, die Infrastruktur mithilfe einer Programmiersprache wie TypeScript oder Python zu definieren.

Setup cdktf

Den gesamten Code findest du in meinem Repository hier. Ich beschreibe aber noch kurz, wie das Repository erstellt wurde. Initialisiere dein cdktf-Repo mit:

cdktf init --template="typescript"
cdktf provider add "aws@~>4.0"

Optional kannst du noch Prettier und Linter hinzufügen. In den meisten meiner Projekte verwende ich diese, da sie mir ein schnelles Entwickeln ermöglichen, ohne dass ich mir Gedanken um die Formatierung machen muss.

Ich verwende das Community Terraform Lambda Modul, um die Lambda zu definieren. Es erlaubt mir, in nur wenigen Zeilen eine Lambda zu definieren, die mit einer Rolle konfiguriert wird und auch einfach um Policies erweitert werden kann. Das Coole ist, dass cdktf eine Type-Importierung unterstützt. Dafür muss einfach in der cdktf.json-Datei folgendes Modul hinzugefügt werden:

"terraformModules": [
    {
      "name": "lambda",
      "source": "terraform-aws-modules/lambda/aws",
      "version": "~> 3.0"
    }
  ],

Anschließend wird der Befehl cdktf get ausgeführt:

cdktf get

Nun kann das Modul im cdktf-Code verwendet werden:

import { Lambda } from './../.gen/modules/lambda';
...

Falls die Lambda eigene Dependencies hat, müssen diese noch installiert werden mit:

cd src/lambda
npm install

Deploye den cdktf-Stack mit:

cdktf deploy

Code

Die Lambda kann dann zum Beispiel in die main.ts integriert werden:

import { NodejsFunction } from './constructs/nodejs-function';

class MyStack extends TerraformStack {
  constructor(scope: Construct, name: string) {
    super(scope, name);

    const code = new NodejsFunction(this, 'code', {
      path: path.join(__dirname, 'lambda/filter-aurora.ts'),
    });

    new Lambda(this, 'FilterAuroraEventsLambda', {
      functionName: 'filter-aurora',
      handler: 'filter-aurora.handler',
      runtime: 'nodejs14.x',
      sourcePath: code.bundledPath,
      timeout: 15 * 60,
      attachPolicyStatements: true,
      policyStatements: {
        kms: {
          effect: 'Allow',
          actions: ['*'],
          resources: ['*'],
        },
        s3: {
          effect: 'Allow',
          actions: ['s3:*'],
          resources: ['*'],
        },
      },
    });
  }
}

const app = new App();
new MyStack(app, 'cdktf-lambda');
app.synth();

Ich benutze also das Custom Construct NodejsFunction, um den Code von TypeScript in JavaScript zu bundlen und der Lambda zu zeigen, wo sie den gebundelten JavaScript-Code finden kann. Das NodejsFunction Construct sieht so aus:

import { AssetType, TerraformAsset } from 'cdktf';
import { Construct } from 'constructs';
import { buildSync } from 'esbuild';
import * as path from 'path';

export interface NodejsFunctionProps {
  readonly path: string;
}

const bundle = (workingDirectory: string, entryPoint: string) => {
  buildSync({
    entryPoints: [entryPoint],
    platform: 'node',
    target: 'es2018',
    bundle: true,
    format: 'cjs',
    sourcemap: 'external',
    outdir: 'dist',
    absWorkingDir: workingDirectory,
  });

  return path.join(workingDirectory, 'dist');
};

export class NodejsFunction extends Construct {
  public readonly asset: TerraformAsset;
  public readonly bundledPath: string;

  constructor(scope: Construct, id: string, props: NodejsFunctionProps) {
    super(scope, id);

    const workingDirectory = path.resolve(path.dirname(props.path));
    const distPath = bundle(workingDirectory, path.basename(props.path));

    this.bundledPath = path.join(
      distPath,
      `${path.basename(props.path, '.ts')}.js`,
    );

    this.asset = new TerraformAsset(this, 'lambda-asset', {
      path: distPath,
      type: AssetType.ARCHIVE,
    });
  }
}

Wie zu sehen ist, bundelt esbuild den TypeScript Code zu JavaScript Code jedesmal wenn cdktf deploy ausgeführt wird.

Fazit

TypeScript-Lambdas mit cdktf zu bauen bedarf etwas mehr Aufwand im Vergleich zu aws cdk TypeScript-Lambdas. Trotzdem hält sich dieser Aufwand in Grenzen und ich habe dir hier gezeigt, wie du es machen kannst. Falls du den Beitrag hilfreich fandest, lass es mich bitte wissen!

Oder

Und schau doch mal auf meiner Seite vorbei

Terraform CI/CD Staging Pipeline mit CircleCI

Sat, 01 Oct 2022 00:00:00 GMT

Hi,

Terraform CI/CD Staging Pipelines, wobei das CD für Continuous Deployment steht, erlauben ein sicheres und kontinuierliches Entwickeln von Infrastruktur mit Terraform. Üblicherweise wird durch ein Commit im main Branch die Pipeline gestartet und die gewünschten Änderungen zuerst auf der DEV Stage ausgeführt. Durch ein manuelles Approval können dann die Änderungen auf die QA Stage und anschließend auf die PROD Stage mit der Pipeline ausgerollt werden.

Wie so eine Terraform CI/CD Staging Pipeline mit AWS als Cloud Provider aussehen kann, möchte ich hier gerne vorstellen.

Warum eine CI/CD Staging Pipeline?

Zusammen mit dem Kunden planen und entwickeln wir ein ein komplexes AWS Setup mit Hasura, RDS, ECS und vielen weiteren AWS Services. Dieses Setup soll unter anderem auch mit der existierenden Produktionsumgebung in Salesforce interagieren. Es ist also von größter Wichtigkeit neue Funktionalitäten auf einer DEV und QA Umgebung zu testen.

Diese Umgebungen DEV und QA, sollen sich dabei möglichst ähnlich zur PROD Umgebung verhalten. Darüber hinaus sollen Änderungen schnell auf die PROD Umgebung ausführbar sein mit möglichst wenig benötigten manuellen Schritten. Genau für diese Anforderungen eignet sich eine CI/CD Staging Pipeline.

Multi-Account Setup

Um eine CI/CD Staging Pipelines zu erstellen ist es best practice für jede stage wie DEV, QA oder PROD einen eigenen AWS Account zu verwenden. Das Pipeline Setup muss also in der Lage sein diese Accounts mit Terraform zu bootstrappen bzw. zu initialisieren und anschließend Änderungen auszurollen.

Für das Multi-Account Setup habe ich mir den Artikel Terraform AWS Multi-Account Setup zum Vorbild genommen bei dem mittels Config Files wie accounts/dev/backend.conf und accounts/dev/terraform.tfvars die jeweilige Stage konfiguriert wird. Super cool ist nun, dass damit die gleiche main.tf für alle Staging Umgebungen verwendet werden kann.

Zu oft sehe ich bei Kunden die mit Terraform arbeiten, dass für jede Staging Umgebung eigene TF Files erzeugt werden und Ressourcen hin und her kopiert werden. Das muss aufhören und der hier beschriebene Ansatz kann dabei helfen!

CircleCI Staging Pipeline

CircleCI ist eine continuous integration and continuous delivery Plattform für DevOps Funktionalitäten. Ähnlich wie auch auf anderen DevOps Plattformen wie Travis oder GitHub Actions wird eine Pipeline yaml Definition im Ordner .circleci mit den Namen config.yml angelegt. Sehr toll finde ich, dass CircleCI manuelle Approvals unterstützt und einfach integrierbar macht mit:

workflows:
  version: 2
  plan_approve_apply:
    jobs:
      - dev-plan-apply
      - dev-hold-apply:
          type: approval
          requires:
            - dev-plan-apply
     ...

Somit können die geplanten Infrastruktur-Änderungen erst begutachtet und dann durchgeführt werden. Den vollständigen Code seht ihr hier.

Ausblick

Als nächstes möchte ich CDKTF einführen damit die Infrastruktur mit TypeScript definiert werden kann. Ähnlich wie es für mich auch der Fall mit AWS CDK war, verspreche ich mir dadurch ein schnelleres Entwickeln mit Terraform. Der Typen-Support erlaubt mir fehlende Terraform Properties schon früh zu erkennen. Auch ist die Dokumentation von den Properties sehr angenehm und ich muss somit kaum noch in der Terraform Dokumentation nachsehen.

Danach bin ich auch schon sehr gespannt wie AWS Ressourcen wie Aurora, ECS, VPC und so weiter mit Terraform integriert werden. Das Ganze erweitert mein Set an Tools mit denen ich coole Sachen in AWS bauen kann.

Fazit

Eine CI/CD Staging Pipeline ist ein wichtiges Tool um verlässliche Infrastruktur in AWS zu bauen. Hier in diesem Artikel habe ich euch gezeigt wie ihr es mit Terraform in AWS machen könnt. Da ich noch ein Anfänger in Terraform bin, habe ich eventuell kleine Fehler gemacht. Wenn ihr Verbesserungsvorschläge habt oder einfache coole Projekte mit mir besprechen wollt, schreibt mir gerne an :)!

Ich liebe es an Open Source Projekte zu arbeiten. Vieles kannst du bereits frei nutzen auf github.com/mmuller88 . Wenn du meine dortige Arbeit sowie meine Blog Posts toll findest, denke doch bitte darüber nach, mich zu unterstützen und ein Patreon zu werden:

Oder

AWS CDK und Amplify runtime-config

Sat, 27 Aug 2022 00:00:00 GMT

Ahoi,

Die nahtlose Integration von AWS CDK und Amplify Apps war bisher sehr umständlich! Mit einer runtime-config für die Amplify Frontend React App ist es nun wesentlich einfacher. Hier möchte ich dir gerne die Idee der runtime-config vorstellen.

In meinen Fullstack Projekten nutze ich regelmäßig AWS CDK als Backend. Dabei ist AppSync als GraphQL Implementation die Schnittstelle zwischen dem Frontend und Backend. Das Frontend ist normalerweise eine React SPA (Single Page Application) gehostet in einem S3 Bucket. Zum Verwalten und Authentifizieren der User nutze ich AWS Cognito. Die Frontend React App konfiguriere ich üblicherweise mit AWS Amplify.

Idee runtime-config

Die runtime-config erlaubt die Konfiguration von Amplify nach der Build-Phase zur Runtime. Dabei wird dem dist Folder der SPA einem File z.B. runtime-config.json im public Folder mitgegeben welcher zur Runtime der App ausgelesen wird. Diese kann dan zum Beispiel so aussehen:

{
  "region": "eu-central-1",
  "identityPoolId": "eu-central-1:cda9c404-0e74-439d-b40c-90204a0e1234",
  "userPoolId": "eu-central-1_Uv0E91234",
  "userPoolWebClientId": "1t6jbsr5b7utg6c9urhj51234",
  "appSyncGraphqlEndpoint": "https://wr2cf4zklfbt3pxw26bik12345.appsync-api.eu-central-1.amazonaws.com/graphql"
}

Die runtime-config wird dann dynamisch in der React App geladen via useEffect und fetch:

useEffect(() => {
    fetch('/runtime-config.json')
      .then((response) => response.json())
      .then((runtimeContext) => {
        runtimeContext.region &&
          runtimeContext.userPoolId &&
          runtimeContext.userPoolWebClientId &&
          runtimeContext.identityPoolId &&
          Amplify.configure({
            aws_project_region: runtimeContext.region,
            aws_cognito_identity_pool_id: runtimeContext.identityPoolId,
            aws_cognito_region: runtimeContext.region,
            aws_user_pools_id: runtimeContext.userPoolId,
            aws_user_pools_web_client_id: runtimeContext.userPoolWebClientId,
            aws_appsync_graphqlEndpoint: runtimeContext.appSyncGraphqlEndpoint,
            aws_appsync_region: runtimeContext.region,
            aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS',
            Auth: {
              region: runtimeContext.region,
              userPoolId: runtimeContext.userPoolId,
              userPoolWebClientId: runtimeContext.userPoolWebClientId,
              identityPoolId: runtimeContext.identityPoolId,
            },
          });
      })
      .catch((e) => console.log(e));
  }, []);

Wie du siehst wird ein fetch zum laden der runtime-config.json initial ausgeführt. Danach wird Amplify mit der extrahierten properties konfiguriert.

Es können auch HTML window variablen zum setzen der Amplify Parameter verwendet werden. Allerdings bevorzuge ich die hier vorgestellt fetch Lösung weil damit potentiell besser auf eine fehlende runtime-config.json oder einzeln fehlende Properties reagiert werden kann. Außerdem sollten window Variablen vermieden werden da diese globalen Zugriff auf den DOM bekommen.

Workflows

Der typische Workflow ohne die runtime-config zum builden und deployen der React App lief bisweilen so ab:

curl and store current endpoints like user pool id, AppSynch endpoint and more
build Amplify config file
build react app
cdk deploy react dist folder to S3

Build Pipeline Workflow mit runtime-config:

build react app
cdk deploy react dist folder and runtime config to S3

CDK Beispiel

Der Komplette Code is in meinem GitHub Senjuns Projekt einsehbar.

const userPool = new cognito.UserPool(...)
...
const identityPool = new cognito.CfnIdentityPool(...)
...

const dashboard = new StaticWebsite(this, 'dashboard', {
    build: '../dashboard/build',
    recordName: 'dashboard',
    domainName: props.domainName,
    runtimeOptions: {
        jsonPayload: {
            region: core.Stack.of(this).region,
            identityPoolId: identityPool.ref,
            userPoolId: userPool.userPoolId,
            userPoolWebClientId: userPoolWebClient.userPoolClientId,
            appSyncGraphqlEndpoint: graphqlUrl.stringValue,
        },
    },
});

Die StaticWebsite ist ein simples L3 CDK Construct mit einem S3 static website bucket als Haupt-Ressource. Mehr Details siehst du hier. Die interessanten Details befinden sich aber im runtimeOptions Objekt. Dort werden also die Endpoints für die runtime config für Amplify hinterlegt. Dahinter steckt dann das S3 Bucket Deployment Construct welches die Endpoints via s3deploy.Source.jsonData(...) in die JSON Datei runtime-config.json überführt:

const DEFAULT_RUNTIME_CONFIG_FILENAME = 'runtime-config.json';

...

new s3deploy.BucketDeployment(this, 'BucketDeployment', {
    sources: [
    s3deploy.Source.asset(props.build),
    ...(props.runtimeOptions
        ? [
        s3deploy.Source.jsonData(
            props.runtimeOptions?.jsonFileName ||
                DEFAULT_RUNTIME_CONFIG_FILENAME,
            props.runtimeOptions?.jsonPayload,
        ),
        ]
        : []),
    ],
    distribution,
    destinationBucket: siteBucket,
});

Das ist doch mal ne coole CDK integration :) ! Dem BucketDeployment Construct einfach die zwei Parameter wie dem React dist und der runtime-config mitzugeben ist schon eine ziemlich schlaue Idee.

Workaround mit nested Stack Outputs

Während meiner Arbeit mit der runtime-config bin ich auf ein Problem gestoßen. Es ist nämlich nicht möglich CDK Outputs von einem Nested Stack für die runtime-config zu verwenden. Es gibt aber den Workaround mittels AWS Systems Manager Parameter:

const graphqlUrl = new ssm.StringParameter(this, 'GraphqlUrl', {
    parameterName: 'GraphqlUrl',
    stringValue: appSyncTransformer.appsyncAPI.graphqlUrl,
});

...

const dashboard = new StaticWebsite(this, 'dashboard', {
    build: '../dashboard/build',
    recordName: 'dashboard',
    domainName: props.domainName,
    runtimeOptions: {
    jsonPayload: {
        region: core.Stack.of(this).region,
        identityPoolId: identityPool.ref,
        userPoolId: userPool.userPoolId,
        userPoolWebClientId: userPoolWebClient.userPoolClientId,
        appSyncGraphqlEndpoint: graphqlUrl.stringValue,
    },
    },
});

Cool oder? Der Nested Stack Output wird einfach in einem SSM String Parameter gespeichert und kann dann später ausgelesen werden. Vielen dank an Adrian Dimech für den tollen Workaround 🙏.

Fazit

AWS CDK und Amplify sind eine starke Kombination. Mit der hier vorgestellten runtime-config fühlt sich diese Kombination wesentlich besser an! Ich habe mir diese Lösung vom aws-prototyping-sdk abgeschaut. In diesem Repo werden interessante AWS CDK Constructs entwickelt. Ihr solltet es also definitiv mal auschecken!

Ich hoffe ich konnte auch dir damit einen Anreiz geben mal die runtime-config auszuprobieren. Erzähl mir gerne wie es war.

Oder

Catch AWS Lambda Timeouts

Sun, 10 Jul 2022 00:00:00 GMT

Ahoi,

AWS Lambda ist wohl einer der berühmtesten wenn nicht der berühmteste compute Service von AWS. Tatsächlich ist Lambda auch mein Lieblingsservice von AWS, da es sehr einfach und unkompliziert das Implementieren der Businesslogik ermöglicht. Schon ein paar mal hatte ich allerdings das Problem, dass das Timeout der Lambda zu gering war und somit der Code nicht komplett ausgeführt wurde. Diesen Fehler zu debuggen oder zu catchen war auch oft anstrengend und nervig. Eine gute Lösung für mich war es die Lambda Duration Metrics zu nutzen um einen Alarm zu definieren.

import * as cw from 'aws-cdk-lib/aws-cloudwatch';
import * as lambdajs from 'aws-cdk-lib/aws-lambda-nodejs';
import * as sns from 'aws-cdk-lib/aws-sns';
import * as subscriptions from 'aws-cdk-lib/aws-sns-subscriptions';

const exampleLambda = new lambdajs.NodejsFunction(this, 'ExampleLambda', {
    timeout: core.Duration.seconds(10),
});

new timeoutAlarm - new cw.Alarm(this, 'TimeoutAlarm') {
    metric: exampleLambda.metricDuration({ statistic: 'max' }),
    threshold: exampleLambda.timeout?.toMilliseconds() ?? 1,
    evaluationPeriods: 1,
}

const topic = new sns.Topic(
    this,
    'ErrorTopic',
);
topic.addSubscription(
    new subscriptions.EmailSubscription('alice@bob.com')
);
timeoutAlarm.addAlarmAction(
    new actions.SnsAction(topic)
);

Wie du hier sehen kannst, wird am Anfang eine einfach Lambda JS Function erstellt. Übrigens das NodejsFunction construct Construct unterstützt auch TypeScript. Dann wird der Timeout Alarm definiert der die Duration Metrik und den Timeout Value von der Lambda benutzt zu Konfiguration.

Danach wird eine Error Topic erstellt über die mittels einer EmailSubscription der ausgelöste Alarm per Email weitergeleitet wird.

Vorteile

Der Vorteil der Lösung ist, dass der Code der Lambda nicht extra angepasst werden muss und das Problem somit auf Infrastruktur Level bzw. AWS CDK Level gelöst wird. Diese Lösung lässt sich genauso auf andere Lambda Sprachen wie Python oder Java anwenden.

Fazit

Das catchen von Lambda Timeouts ist nervig. Mit ein wenig AWS CDK Code und der Lambda Duration Metrik ist das Problem schnell gelöst.

Oder

Mach die AWS prod Umgebung super mit Superwerker

Tue, 05 Jul 2022 00:00:00 GMT

Hi Leute.

Ich will mein senjuns project production ready machen. Bisher hatte ich es nur in meinem developer AWS Account deployed. Mein developer Account hate kine AWS Services konfiguriert die für eine Vernünftige Produktionsumgebung benötigt werden. Das sind zum Beispiel AWS SSO, ControlTower, SecurityHub und noch einige mehr. Da kam das Superwerker CFN Template gerade recht. Dieses hat es mir ermöglicht einen neuen AWS Account mit vielen tollen AWS Services fur den Produktionsbetrieb zu konfigurieren. In den folgenden Abschnitten möchte ich gerne darauf eingehen was Superwerker genau ist und wie ich es verwendet habe.

Was ist Superwerker?

Superwerker ist eine Open Source AWS CloudFormation Lösung welches die Einrichtung eines AWS Accounts erleichtert. Dabei folgt es best practices für Security und Effizienz. Entwickelt und Maintained wurde/wird das Projekt von AWS Advanced Partnern kreuzwerker und superluminar. Es hat sogar seine eigene Landingpage[https://superwerker.cloud/] mit tollen Inhalten wie einem kurzen Video und mehr. Kaum zu glauben, dass dies ein kostenloses Produkt ist.

Das Superwerker Deployment hat eine Menge von coolen Features die alle sehr gut in den Docs hier erklärt sind. Sehr gut finde ich, dass es zum Beschreiben der einzelnen Features Architectural Decision Records verwendet. Nachfolgend erkläre ich die Features mit eigenen Worten.

Backup

Backup aktiviert den AWS Backup Service und per default wird jeden Tag ein Backup erzeugt. Dabei werden Backups erzeugt von Datenbanken die auch von AWS Backup unterstützt werden.

Budget

Budget hilft die Kosten in AWS zu überschauen und gibt rechtzeitig eine Warnung falls mehr Kosten als üblich anfallen. Das macht es dadurch, dass der Mittelwert der letzten drei Monate berechnet wird und falls dieser überschritten wird, kommt eine Warnung. Eine echt coole Idee finde ich.

Control Tower

Control Tower vereinfacht das Verwalten von mehreren AWS Accounts mit AWS SSO. Für mich ist das der Hauptgrund warum ich Superwerker verwende. Somit kann ich sehr einfach auf meine verschiedenen AWS Accounts wie build, dev und prod zugreifen. Sehr toll finde ich auch, dass ich mit AWS SSO einfach die AWS Account credentials kopieren und für die AWS CLI verwenden kann.

GuardDuty

GuardDuty ist ein AWS Service zum finden von möglichen Security Gefahren.

Living Documentation

Living Documentation ist ein ziemlich cooles Feature welches eine Documentation via AWS CloudWatch Dashboard erzeugt. Diese gibt dann Informationen über zum Beispiel wie ein SSO setup mit externen Identity Providern wie Google gemacht werden kann und noch vieles mehr. Extrem cool ist wie sich diese Documentation auch selber updated wenn bereits gewisse Konfigurationen vorgenommen wurden. Deswegen heißt es ja auch Living Documentation.

Notifications

Superwerker erstellt OpsItems in OpsCenter wenn wenn Emails vom der RootMail Feature versendet werden. Mit dem Notifications Feature werden dann Emails an die spezifizierte Adressen versendet. Somit muss der User sich nicht manuell in die AWS Console einloggen und OpsCenter überprüfen. Durch die Email hat man somit auch eine zentralisierte Sammelstelle für mehrere Accounts.

RootMail

RootMail erstellt die uniformierten Email Adressen für die vom Control Tower erstellten Accounts audit und log archive. Dafür wird eine eigene Hosted Zone zum Beispiel aws.mycompany.test mit Route53 angelegt und die benötigten Einstellungen mit AWS SES zum Erhalt der Emails vorgenommen.

Security Hub

Das Security Hub Feature aktiviert AWS Security Hub für alle Accounts. Der User muss sich in den Audit Account einloggen um die aggregierte Security Hub View zu betrachten.

Im nächsten Abschnitt möchte ich gerne mehr über meine Experience mit Superwerker berichten.

Superwerker Experience

Die Anweisungen zum Ausführen von Superwerker findest du hier. Für mich ging die Installation recht reibungslos. Eine Ausnahme stellte aber der RootMail Nested Stack da. Ich hatte zuvor meine Domaine senjuns.com und die dazugehörige Hosted Zone aus einem anderen AWS Account importiert. Allerdings habe ich die Name Server von der Domaine nicht ordnungsgemäß in der dafür vorgesehenen Hosted Zone konfiguriert. Durch debuggen der Superwerker Lambdas ist mir dieser Fehler aufgefallen.

Falls du also auch die folgenden Error logs in der RootMailReady Lambda bekommst, musst du einfach mal überprüfen ob du deine Domaine und die Hosted Zone richtig konfiguriert hast.

{
    "level": "info",
    "msg": "verification not yet successful",
    "res": {
        "VerificationAttributes": {
            "aws.senjuns.com": {
                "VerificationStatus": "Pending",
    ...

{
    "level": "info",
    "msg": "DKIM verification not yet successful",
    "res": {
        "DkimAttributes": {
            "aws.senjuns.com": {
                "DkimEnabled": true,
                "DkimVerificationStatus": "Pending",
    ...

Falls jemand auf ein gleiches oder ähnliches Problem stoßen sollte, habe ich ein Pull Request mit Troubleshooting Informationen erstellt.

Fazit

Superwerker is ein tolles CloudFormation QuickStart um eine AWS Produktionsumgebung professionell und einfach aufzusetzen. Viele Verbesserungen und neue Features sind bereits im Superwerker Backlog geplant. Die Superwerker Community sucht noch nach tatkräftiger Unterstützung beim Implementieren von neuen Feature und Verbesserungen. Ich bin schon sehr gespannt das Superwerker Deployment weiterhin in meinem aktuellen Projekt und in meinen zukünftigen Projekten zu verwenden. Vielen Dank dass du dir meinen Artikel durchgelesen hast. Falls du noch Fragen hast, kannst du mir gerne schreiben.

Oder

Was ist Serverless?

Tue, 24 May 2022 00:00:00 GMT

Um gleich ein mögliches Missverständnis aufzuklären! Serverless heißt nicht dass es keine Server mehr gibt! Im Gegenteil! Cloud Provider wie zum Beispiel AWS, die Serverless anbieten, verfügen über sehr viele Server weltweit. Im nachfolgenden Bild könnt ihr die aktuell verfügbaren AWS Regionen sehen. Das bedeutet an all diesen Plätzen auf der Welt hat AWS mindestens zwei Rechenzentren.

So ein Rechenzentrum selbst ist ein riesiges Gebäude mit viel Servertechnik.

Jetzt und im Folgenden möchte ich für die jeweilige Sektion anhand von S3 und Lambda als Beispiel erklären.

S3 ist ein AWS Service der als object storage genutzt werden kann.

Lambda ist ebenfalls ein AWS Service der aber zum compute also zum berechnen verwendet werden kann. Das wird in der Regel dafür benutzt um die Businesslogik von der Cloud Applikation zu implementieren.

Warum Serverless?

Geringere Komplexität. Als Cloud Entwickler muss ich mich nicht mehr um die Verwaltung (Hardware und Software) der Server. Somit kann ich mich direkter auf die Businesslogik meiner Applikation in der Cloud konzentrieren. Mit S3 kann ich als Entwickler einfach und unkompliziert über die S3 API Daten speichern. Bei Lambda kann ich die Businesslogik direkt als Code z.B. TypeScript oder Python definieren und an die Lambda API übergeben. Der AWS Lambda Service übernimmt dann den Rest. Ich brauche mich nicht um irgendwelche Betriebssystem-relevante Sachen wie zum Beispiel bei Ec2 zu kümmern.

Bessere Skalierbarkeit. Serverless Angebote skalieren automatisch per default. So können in S3 beliebig viele Objekte gespeichert werden ohne, dass es der Entwickler das Volumen anpassen muss wie zum Beispiel bei AWS EBS. Auch Lambda kann fast beliebig skalieren. Steigt die Nachfrage zur Ausführung der Businesslogik werden sogar mehrere Lambda Instanzen gestartet um die zeitnahe Abarbeitung zu gewährleisten. Falls keine Ausführung der jeweiligen Businesslogik benötigt wird, werden auch keine Lambda Instanzen gestartet.

Kostenoptimierung. Schon durch den vorherigen Punkt über die bessere Skalierbarkeit lässt sich vermuten dass dadurch Kostenersparnisse zu möglichen Alternativen ergeben können. Dies muss aber nicht immer unbedingt der Fall sein und auch generell Kosten von Serverless mit Alternativen zu vergleichen ist schwierig. Deswegen behandel ich Kostenoptimierungen in diesem Artikel nicht weiter. Nur soviel sei gesagt, dass ich persönlich gerne auf die Serverless Angebote von AWS zugreife da dieses vor allem in der Anfangsphase zu sehr geringe Kosten führt.

Aber wie funktioniert Serverless?

Falls dich die Gründe warum Serverless überzeugt haben, stellst du dir jetzt vielleicht die Frage wie es funktioniert?

Wie alle AWS Service Angebote funktioniert die Kommunikation mit Serverless Services wie S3 und Lambda per HTTP/S API. Das bedeutet per HTTP Requests können Erstellung- und Änderungsanfragen gestellt werden. Die S3 API findest du in der Documentation hier und für die Lambda API hier.

Nun muss sicher der Entwickler aber nicht mit HTTP Requests rumplagen und kann alternativ auch quasi API Wrapper benutzen wie der AWS CLI oder AWS SDK in verschiedenen Programmiersprachen wie TypeScript oder Python. Eine noch bessere und von mir bevorzugte Alternative ist AWS CDK welches m

Was gefällt mir an Serverless?

Das tolle an Serverless ist für mich, dass es eine tolle Abstraktion ist und das Entwickeln in der Cloud super einfach macht. Somit bin ich gezielt in der Lage die Wünsche und Anforderungen meiner Kunden an ihre Cloud Projekt umzusetzen.

Zusammenfassung

In diesem Artikel habe ich euch erklärt was Serverless ist und warum ich es so toll finde. Ich glaube aber fest daran dass Serverless noch nicht das Ende der Cloud-Abstraktionen sind. Kürzlich bin ich der Firma Monada beigetreten die genau das als Ziel verfolgen. Wir wollen eine noch bessere Abstraktion als Serverless schaffen um das Arbeiten mit der Cloud noch toller zu machen. Habt ihr Feedback zu diesem Artikel dann bitte lasst es mich wissen :)! Let's build!

Oder

Programmatisch AWS Accounts erstellen und löschen

Wed, 11 May 2022 00:00:00 GMT

Hi.

In AWS ist es best practice neue Accounts zu erstellen wenn zum Beispiel unterschiedliche Stages wie dev, qa und prod für seine Lösung bereitstellen möchte. Auch ist es üblich sogenannte Sandbox AWS Accounts zu erstellen um diese neuen Mitarbeiter zum Testen von AWS Services bereitzustellen. Es gibt noch viele weitere Gründe warum neue AWS Accounts erstellt werden sollten.

Nun das Erstellen solcher AWS Accounts kann recht aufwendig sein, wenn es manuell gemacht werden muss. Mit AWS Organizations, dem AWS JavaScript SDK und ein wenig TypeScript Kenntnissen kann der Prozess zum Großteil automatisiert werden. In diesem Post stelle ich vor wie das funktioniert. Dafür erkläre ich zuerst was AWS Organizations überhaupt ist und dann stelle ich die zwei TypeScript Scripte die mittels AWS SDK die AWS Sandbox accounts Erstellen und Löschen können.

AWS Organizations

AWS Organizations hilft dabei die AWS Accounts zu verwalten. In sogenannten Organizational Unites (OU) können Accounts zu Gruppen zusammengefasst werden. Darüber hinaus können Security Mechanismen wie Policies Account übergreifend definiert werden. AWS Organizations bietet noch viel viel mehr Funktionalität und ich möchte an dieser Stelle auf die öffentlich Dokumentation hinweisen. Interessant für diesen Beitrag ist, dass es für die AWS Organizations API auch ein JavaScript SDK wrapper gibt den wir in den nächsten Abschnitten benutzen werden um dynamisch Accounts zu erstellen und zu löschen.

createAccount and deleteAccount

Ich habe eine kleine Helfer-Bibliothek in GitHub erstellt um das programmatische Erstellen und Löschen von AWS Accounts zu vereinfachen. Ein AWS SDK Script ließe sich dann so ganz leicht bauen wie zum Beispiel:

import {
 createAccount,
 moveAccountToOU,
 getAccountIdFromName,
} from "aws-accounts"

export async function main(): Promise<void> {
 var args = process.argv.slice(2)

 if (args.length !== 1) {
  usage()
  throw new Error("Wrong number of arguments")
 }

 const accountName = args[0]

 const response = await createAccount(accountName)
 const accountId = await getAccountIdFromName(accountName)
 if (accountId) {
  await moveAccountToOU(accountId, "ou-zblx-w7yw0qge")
 }
}

Der Code ist auch im Repo hier zu sehen.

Die Bibliothek is ein leichter Wrapper um AWS SDK TypeScript v.2 . Mit await createAccount(accountName) wird zuerst der Account erstellt. Anschließend mit await getAccountIdFromName(accountName) und await moveAccountToOU(accountId) wird der Account in die definierte OU (Organizational Unit) verschoben.

Zusammenfassung

In diesem Blog Post habe ich erklärt warum es manchmal erforderlich ist neue AWS Accounts zu erstellen und wie dies gemacht werden kann mit AWS Organizations und dem JavaScript SDK. Dafür habe ich ein createAccount und ein deleteAccount Script erstellt und hier vorgestellt. Fandet ihr den Beitrag hilfreich oder habt ihr Verbesserungsvorschläge? Lasses es mich wissen und schreibt mir :).

Ich liebe es an Content Management Open Source Projekte zu arbeiten. Vieles kannst du bereits frei nutzen auf github.com/mmuller88 . Wenn du meine dortige Arbeit sowie meine Blog Posts toll findest, denke doch bitte darüber nach, mich zu unterstützen:

Oder

AWS Builder Erfahrung bis jetzt

Fri, 29 Apr 2022 00:00:00 GMT

Hi.

Seit März 2022 bin ich ein AWS Community Builder. In diesem Post will ich dir erklären was ein AWS Community Builder ist und wie du einer werden kannst. Darüber hinaus werde ich meine persönliche Motivation, warum ich überhaupt ein AWS Builder werden wollte, preisgeben. Am Schluss erkläre ich was aus meiner Perspektive gut und nicht so gut ist am AWS Community Builder Programm.

Was ist und wie wirst du ein AWS Community Builder?

Die genau Beschreibung des AWS Community Builder findet ihr hier. Kurz zusammengefasst bietet es die Möglichkeit sein AWS zentriertes Netzwerk weiter auszubauen. Ich habe bereits viele spannende Builder kennengelernt. Darüber hinaus helfen sich die Community Mitglieder gegenseitig.

Ein AWS Community Builder wirst du indem du dich in einem bestimmten Zeitfenster. Für mich war dieses Zeitfenster im Januar. Das nächste Zeitfenster wird sich voraussichtlich Mitte 2022 wieder öffnen.

Warum wollte ich ein AWS Builder werden?

In den letzten Jahren habe ich gelernt wie wertvoll und gut es ist sein professionelles Netzwerk auszubauen. Das ermöglicht tolle Gelegenheiten wie zum Beispiel einen neuen tollen Arbeitgeber*in zu finden oder andere interessante Kooperationen einzugehen. Darüber hinaus habe ich in bestimmten Netzwerken wie Slack und auf Meetups viele tolle (AWS) Engineers kennengelernt die mir schon oft geholfen haben oder denen ich helfen durfte.

Was gefällt mir soweit?

Am meisten gefällt mir der Austausch mit anderen AWS Buildern. Der Austausch findet hauptsächlich im AWS Community Builders Slack statt. Viele von ihnen sind sehr passionierte und engagierte Menschen. Auch ziemlich cool ist, dass Builder dort ihre Blogposts teilen die ich meistens mit Spannung lese.

Ein cooler Bonus ist der AWS Community Builder Swag. Es ist quasi eine Überraschungsbox mit Swag. Ich bin schon gespannt was dort drinnen sein wird. Bisher ist die Box noch nicht bei mir angekommen. Sehr wichtig bei der Box und dem Inhalt war mir, dass sie nachhaltig hergestellt und versendet wird. AWS hat versichert, dass das der Fall ist. Also brauche ich hier kein schlechtes Gewissen zu haben :).

Was gefällt mir nicht

Was ich nicht so toll finde ist, dass nur ein relativ geringer Anteil der Bewerbungen zum AWS Community Builder akzeptiert wurden. Es wäre toll sich mit noch mehr Buildern auszutauschen und auch Engineers, die noch nicht so ein hohe Sichtbarkeit haben wie ich, eine Chance zu geben. Allerdings kann ich auch sehr gut verstehen warum AWS die Builder Community nicht zu schnell wachsen lassen sollte.

Zusammenfassung

Hier in diesem Post habe ich meine Gedanken und Gefühle zum AWS Community Builder zusammengefasst. Natürlich bin ich erst seit wenigen Wochen ein Mitglied und kann von daher kein 360 Grad Feedback geben. Von daher werde ich in ein paar Monaten erneut reflektieren und dich daran teilhaben lassen.

Wenn du auch noch nach einer coolen AWS Community suchst kann ich dir wärmsten unsere AWS CDK Slack Community ans Herz legen. Auch sehr toll ist unsere DACH AWS Community.

Werde ein Patreon!

AWS Builder experience so far

Fri, 29 Apr 2022 00:00:00 GMT

Hi.

As of March 2022, I am an AWS Community Builder. In this post, I will explain to you what an AWS Community Builder is and how you can become one. In addition, I will reveal my motivation for why I wanted to become an AWS Builder in the first place. In the end, I will explain what is good and not so good about the AWS Community Builder program from my perspective.

What is and how do you become an AWS Community Builder?

You can find the description of the AWS Community Builder here. In short, it provides the opportunity to expand your AWS-focused network. I have already met many exciting and helpful builders.

You become an AWS Community Builder by applying during a certain time window. For me, that time window was in January. The next time window is expected to open again mid-2022.

Why did I want to become an AWS Builder?

Over the past few years, I have learned how valuable and good it is to build and extend your professional network. This allows for great opportunities such as finding a new great employer or other interesting collaborations. In addition, I have met many great (AWS) engineers in networks like Slack and at meetups who have helped me or whom I can help.

What do I like so far?

What I like most is the exchange with other AWS builders. The exchange mainly takes place in the AWS Community Builders Slack. Many of them are very passionate and dedicated people. Also pretty cool is that builders share their blog posts there which I usually read with excitement.

A cool bonus is the AWS Community Builder swag. It's kind of a surprise box of swag. I can't wait to see what will be in there. So far the box has not arrived to me yet. Very important to me about the box and the contents was that it was sustainably made and shipped. AWS has assured that this is the case. So I don't need to have a guilty conscience here :).

What I don't like

What I don't like is that only a relatively small percentage of applications to the AWS Community Builder were accepted. It would be great to exchange with even more builders and also give a chance to Engineers who don't have as high visibility as me yet. However, I can also very well understand why AWS should not let the Builder Community grow too fast. As that would come very hard to handle like organizing events.

Summary

In this post, I have summarized my thoughts and feelings about the AWS Community Builder. Of course, I've only been a member for a few months and therefore can't give 360 degree feedback. From there, I will reflect again in a few months and let you share.

If you are also looking for a cool AWS community, I highly recommend our AWS CDK Slack Community. Also great is our DACH AWS Community.

I love to work on Open Source projects. A lot from my stuff you can already use on github.com/mmuller88 . If you like my work there and my blog posts, please consider supporting me on:

Werde ein Patreon!

DynamoDB Items nach S3 exportieren

Sun, 03 Apr 2022 00:00:00 GMT

Das Speichern von Daten wie JSON logs in DynamoDB ist eine super Idee da DynamoDB sehr skalierbar ist. Dazu kommt, dass es sehr einfach ist Daten in eine DynamoDB Tabelle zu transferieren mit z.B. Lambda und AWS SDK. Auch macht es das Analysieren der Logs leichter da z.B. die AWS Console tolle Filtermöglichkeiten bietet umd nach bestimmten sogenannten Tabellen Items zu suchen.

Das klingt alles sehr gut aber es gibt einen Harken und zwar die Kosten. Mit steigender Anzahl von Items steigen auch die Kosten. Es wäre also ratsam die DynamoDB Daten nach einer gewissen Zeit z.B. 30 Tagen aus der Tabelle zu löschen und in einem S3 zu importieren. Die Kosten für S3 sind wesentlich geringer und es wäre sogar potentiell möglich diese noch weiter zu reduzieren wenn ihr einen günstigeren S3 Tier wie Glacier verwendet.

Stellt sich jetzt natürlich die Frage wie ihr das am geschicktesten machen könnt? Für mich sehr gut geklappt hat die Kombination DynamoDB Time To Live, DynamoDB streams und Lambda welche dann in ein S3 Bucket schreibt. Im folgenden Abschnitt möchte ich meine Lösung gerne genauer beschreiben.

Solution

Ihr findet den Code natürlich in meinem GitHub repo https://github.com/mmuller88/cdk-ddb-to-s3. Die Architektur die ihr auch im Titelbild sehen könnt, ist recht einfach beschrieben. Es wird per DynamoDB streams eine Lambda getriggert, die die gelöschten Item nach S3 wegschreibt. In meinem Beispiel sind die DynamoDB Items einfach JSON logs mit wenigen properties. In eurem Fall kann das DynamoDB Item komplett anders aussehen. Das Grundkonzept müsste aber trotzdem stimmen!

By the way, if you're curious how I created the AWS Component Architecture Diagram, check it out here.

const table = new ddb.Table(this, "table", {
 partitionKey: { name: "systemId", type: ddb.AttributeType.NUMBER },
 sortKey: { name: "timestamp", type: ddb.AttributeType.NUMBER },
 stream: ddb.StreamViewType.OLD_IMAGE,
 timeToLiveAttribute: "ttl",
})

const ddbArchiveBucket = new s3.Bucket(this, "ddbArchiveBucket")

const ddbArchiveLambda = new lambdajs.NodejsFunction(this, "ddbArchiveLambda", {
 reservedConcurrentExecutions: 1,
 environment: {
  DDB_ARCHIVE_BUCKET_NAME: ddbArchiveBucket.bucketName,
 },
})
table.grantStreamRead(ddbArchiveLambda)
spyderArchiveLogBucket.grantWrite(ddbArchiveLambda)

ddbArchiveBucket.addEventSourceMapping("archivelog", {
 // max json document is 4 mb per file
 batchSize: 10000,
 maxBatchingWindow: core.Duration.minutes(5),
 eventSourceArn: table.tableStreamArn,
 startingPosition: lambda.StartingPosition.TRIM_HORIZON,
 bisectBatchOnError: true,
})

stream: ddb.StreamViewType.OLD_IMAGE ist gesetzt da ich ja nur an den items interessiert bin welche gelöscht worden sind.

Bei der Table Definition wurde ein TimeToLive Attribut mit timeToLiveAttribute: 'ttl' . Es ist dann natürlich wichtig dass eure Komponente welche die Daten nach DynamoDB schreibt das ttl Attribut auch immer setzt. Das ist ein Timestamp der beschreibt wann das Table Item gelöscht werden soll. In meinem Projekt waren das nach 30 Tagen.

In der Regel solltet ihr nur eine laufende Lambda benötigen um die Daten nach S3 wegzuschreiben reservedConcurrentExecutions: 1. Das dient zusätzlich zur Absicherung, dass nicht unerwartet viele Aufrufe von Lambda stattfinden.

Die addEventSourceMapping ist wohl am spannendsten. Was ziemlich cool ist, dass DynamoDB Streams eine Batching-Feature bereitstellt. Die Lambda kann dann die gelöschten Items als Batch verarbeiten und dadurch kann die Anzahl der Lambda-Aufrufe reduziert werden und somit auch die Kosten. Das default DynamoDB default Batching ist aber nicht ganz ideal für unseren Use Case hier deswegen habe ich mittels AWS Console und den Lambda Aufruf Metriken diese optimiert:

batchSize: 10000,
maxBatchingWindow: core.Duration.minutes(5),

Die batchSize mit 10000 und das maxBatchingWindow sind maximal gewählt um eine Lambda wirklich nur alle 5 Minuten aufrufen zu müssen:

Super cool oder? Somit wurde die Anzahl der Lambda Aufrufe massiv reduziert.

Übrigens die batch size mit 10000 zu wählen ist in meinem Fall ok da es ja JSON Items sind und wir unter der maximalen Größe von 4 MB pro File bleiben wenn ich diese nach S3 wegschreibe. In eurem Fall könnte diese batch size zu hoch sein. Das müsst ihr am besten mit Testen mal ausprobieren. Ich habe dafür z.B. einfach mal 300 Log Items auf einmal gelöscht und es wurde trotzdem erfolgreich alles mit einem Lambda Aufruf nach S3 weggeschrieben.

Mit Athena und SQL ähnlichen Queries lassen sich dann die Daten nun im S3 Bucket auch auswerten. Wie genau das funktioniert möchte ich aber hier nicht eingehen. Es gibt tolle Tutorials die erklären wie mittels Athena nach bestimmten Informationen in den S3 Daten wie JSON files gequired werden kann.

Auch noch möchte ich erwähnen, dass ich in manchen Tutorials auch die Verwendung von Kinesis Firehose gesehen habe. Ich glaube aber nicht, dass ihr das benötigt für eure Lösung. DynamoDB Streams hat schon die Möglichkeit zu Batchen. Vielleicht ist es aber auch ein anderer Grund warum Firehose verwendet wurde. Wenn ihr doch einen nützlichen Anwendungsfall für Firehose seht, sagt mir bitte Bescheid.

Zusammenfassung

DynamoDB Items nach S3 wegzuschreiben um Kosten zu sparen ist super cool. Hier habe ich euch erklärt wie ihr es machen könnt. Habt ihr Feedback zu diesem Post oder andere Vorschläge über was ich berichten kann? Dann sagt mir Bescheid!

Ich liebe es an Content Management Open Source Projekte zu arbeiten. Vieles kannst du bereits frei nutzen auf www.github.com/mmuller88 . Wenn du meine dortige Arbeit sowie meine Blog Posts toll findest, denke doch bitte darüber nach, mich zu unterstützen und ein Patreon zu werden:

Werde ein Patreon!

AWS CDK Diagramme mit cdk-dia <3

Thu, 24 Mar 2022 00:00:00 GMT

Hi.

AWS Komponenten Diagramme sind eine tolle Möglichkeit komplexe AWS Architekturen zu visualisieren. Für viele sind solche wesentlich intuitiver verständlich als z.B. CDK code. Ich selber arbeite sehr viel mit AWS Komponenten Diagrammen wenn ich neue AWS System entwickle. Was mich daran aber immer gestört hat ist, dass das Erstellen der Diagramme zeitaufwendig ist und diese regelmäßig angepasst werden müssen wenn sich die Architektur ändert.

Wenn es euch ähnlich geht probiert doch mal cdk-dia aus. In meinen letzten beiden CDK Projekten habe ich es verwendet und die Erfahrung war einfach überwältigend.

Wie funktionierts?

Das Tool cdk-dia erlaubt es mir AWS Komponenten Diagramme automatisch aus meinem CDK code zu erzeugen. Es folgt sogar dabei den CDK Construct Level 1 und 2 Abstraktionen. Das bedeutet, dass z.B. die großen Komponenten Symbole Level 2 Constructs sind und nur die Hauptkomponente, die üblicherweise Resource als ID bekommt. Somit werden nur die wirklich wichtigen AWS Komponenten gerendert. Das wird auch als collapsing bezeichnet.

(collapsed diagram)

Möchtet ihr das collapsing verhindern, also auch wirklich alle unterliegenden Komponenten angezeigt bekommen, könnt ihr einen Decorater im Code definieren. Wie genau das funktioniert seht ihr hier .

(non-collapsed diagram)

Das habe ich z.B. bei meinem private asset bucket Construct benutzt:

...
@DiagramOptions({ collapse: CollapseTypes.FORCE_NON_COLLAPSE })
export class PrivateAssetBucket extends core.Construct {
...

Wenn ihr mehr über mein Prowler Construct wissen wollt schaut hier.

Vergleich mit AWS Console Cloudformation template

Die AWS Console selbst besitzt auch ein Diagram Tool zum visualisieren von CloudFormation Stacks mit Name AWS CloudFormation Designer. Nähere Informationen findet ihr hier. Ich habe also den Designer mit cdk-dia verglichen und ich finde cdk-dia um einiges besser. cdk-dia schafft es durch das collapsing einen wesentlich besseren Abstraktionsgrad zu erlangen. Außerdem sind die Grafiken von cdk-dia wesentlich hübscher.

Im nachfolgenden Abschnitt erkläre ich euch wie ihr in eurem CDK Projekt cdk-dia einbauen könnt.

cdk-dia script

Zum kontinuierlichen updaten der cdk-dia Diagramme würde es sich anbieten ein kleines Helferscript in der package.json zu schreiben. Doch vorher solltet ihr erstmal sichergehen dass cdk-dia im dev dependency scope mit yarn add cdk-dia -D installiert ist.

Erstellt dann noch einen Ordner mit Namen diagrams und fügt diese Script in die package.json.

"scripts": {
    ...
    "dia": "yarn cdk synth && yarn cdk-dia && mv diagram.png diagrams/dashboard.png",
    ...
  },

Das Script synthethisiert erst die aktuellen CloudFormation Templates. cdk-dia braucht diese um überhaupt das Diagram erzeugen zu können. Dann wird mit yarn cdk-dia das Diagram erzeugt und anschließend in den diagrams Ordner verschoben.

yarn cdk-dia erzeugt auch immer eine diagram.dot File. Ich empfehle euch die folgenden zwei files in den .gitignore zu packen:

diagram.dot
diagram.png

Wenn ihr gerne das Diagram in einzelne Bilder aufteilen wollt, könnt ihr auch gezielt nur einzelne CDK Stacks rendern lassen z.B.

"scripts": {
    ...
    "dia": "yarn cdk synth && yarn cdk-dia --stacks DashboardAppStack DashboardBackendStack && mv diagram.png diagrams/dashboard.png && yarn cdk-dia --stacks LandingPageStack && mv diagram.png diagrams/landingpage.png",
    ...
  },

Auch eine gute Idee ist es den cdk-dia command in den cdk synth Prozess zu integrieren. Das habe ich z.B. bei meinem cdk Prowler Construct mit eingebunden. In der package.json findet ihr das folgende Script:

"scripts": {
    ...
    "synth": "yarn cdk synth && yarn cdk-dia && mv diagram.png diagrams/prowler.png",
    ...
  },

Nun wird bei jedem manuell ausgeführten cdk synth auch immer das cdk-dia diagram gerendert. Cool oder? Wenn ihr mehr über mein Prowler Construct wissen wollt schaut hier.

Ideen

Im vorherigen Post habe ich ein kleines Script vorgestellt welches die cdk-dia Diagramme erzeugt. Dieses Script muss leider immer noch manuell ausgeführt werden. Es wäre mega cool wenn sich diese Diagramme quasi selbst updaten. Das sollte möglich sein wenn man Husky pre-commit hooks verwendet. Ich bin das gerade am ausprobieren. Wenn ihr mehr darüber wissen wollt, sagt mir Bescheid.

Leider konnte cdk-dia meine CDK CD Staging Pipeline nicht vernünftig rendern und ich musste diese per Hand in https://draw.io anlegen. Es wäre super cool wenn cdk-dia auch Pipelines abbilden könnte.

Zusammenfassung

Wenn ihr auch gerne mit AWS Komponenten Diagrammen arbeitet probiert cdk-dia mal aus! Hier in dem Post habe ich beschrieben wie toll das Tool ist und wie einfach es geht. Schreibt mir gerne wenn ihr Fragen habt.

Werde ein Patreon!

Private S3 Assets mit Cloudfront, Lambda@Edge und AWS CDK

Sun, 13 Feb 2022 00:00:00 GMT

Moin,

Private S3 Assets wie Bilder oder Videos sind ein oft benötigtes Feature für z.B. Apps. Nachdem sich der User eingeloggt hat, sollen Bilder die nur für ihn verfügbar sind, angezeigt werden. Diese befinden sich typischerweise in einem S3 Bucket. Dieser S3 Bucket darf nicht öffentlich verfügbar sein.

Die bisherige Lösung für so ein Szenario sind presigned URLs. Bei presigned URLs handelt es sich um speziell generierte URLs die dem Besitzer der URL den Zugriff auf das Asset erlauben. Die presigned URL kann dann z.B. so aussehen:

https://presignedurldemo.s3.eu-west-2.amazonaws.com/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJJWZ7B6WCRGMKFGQ%2F20180210%2Feu-west-2%2Fs3%2Faws4_request&X-Amz-Date=20180210T171315Z&X-Amz-Expires=1800&X-Amz-Signature=12b74b0788aa036bc7c3d03b3f20c61f1f91cc9ad8873e3314255dc479a25351&X-Amz-SignedHeaders=host

Mhh wenn ich aber doch schon eine User-Verwaltung z.B. AWS Cognito habe, wäre es dann nicht viel eleganter wenn ich einfach mittels User JWT Token auf solche private Assets zugreifen könnte? Ja absolut! Und um den Programmieraufwand gering zu halten kann dafür Cloudfront und Lambda@Edge benutzt werden.

In diesem Blogpost möchte ich euch erklären wie mit Cloudfront und Lambda@Edge ein Proxy gebaut werden kann, der es authentisierten Usern erlaubt auf S3 Asset Urls wie z.B. https://image.example.com/funny.png zuzugreifen. Wenn der dafür benötigte Token dann auch noch als Cookie gespeichert wird, kann man sogar das HTML img Tag z.B.

<img src="https://image.example.com/funny.png">funny.png</img>

verwenden.

Lösungsansatz

Dieses Diagram beschreibt am besten wie der Cloudfront Proxy funktioniert.

Der Flow zum Zugriff auf das Asset is sehr simpel. Zuerst holt sich der User ein gültiges Cognito Token. Das kann z.B. über die Amplify UI, der hosted Cognito login UI oder einer Lambda passieren. Dann wird auf das Asset mittels GET Request zugegriffen z.B. https://image.example.com/funny.png . Der Request benötigt ein Cookie mit dem Namen token und dem Cognito Token als Value.

Zur Erinnerung das ist notwendig wenn man das HTML img tag verwenden möchte. Das img Tag akzeptiert keine Tokens im Header. Alternativ könnte man das Token wohl noch als URL Parameter codieren. Als curl command würde es in etwa so aussehen:

curl --location --request GET "https://image.example.com/funny.png" --cookie "Cookie: token=ey..."

Zum Testen der URL empfehle ich aber lieber Postman da es auch Bilder im Response vernünftig anzeigen kann.

AWS CDK Custom Construct

Ich habe ein AWS CDK Custom Construct geschrieben um private Assets via Cognito Token einfach zu integrieren. In GitHub auf https://github.com/mmuller88/cdk-private-asset-bucket könnt ihr genau sehen wie das Construct funktioniert. Das Construct hat ein recht einfach Interface:

export interface PrivateAssetBucketProps {
  readonly assetBucketName?: string;
    /**
     * if you want to use an imported bucket instead
     */
  readonly assetBucketNameImport?: string;
  readonly customDomain?: CustomDomain;
  readonly userPoolId: string;
  readonly userPoolClientId: string;
}

export interface CustomDomain {
  readonly zone: route53.IHostedZone;
    /**
     * domainName needs to be part of the hosted zone
     * e.g.: image.example.com
     */
  readonly domainName: string;
}

Mit dem optionalen assetBucketName wird dem erzeugtem Bucket ein Namen vergeben. Lässt man diese Property aus wird der Name vom CDK Naming-Algorithmus bestimmt also eine Zusammensetzung von Stackname, Constructname und zufälligem postfix. Möchte man aber lieber einen existierenden Bucket importieren kann das mit assetBucketNameImport gemacht werden. In diesem Fall wird die vorherige Property ignoriert.

Das customDomain Object mit den Properties zone und domainName erlaubt die Vergabe eines Custom Domain wie z.B. https://mail.example.com . Wichtig hierbei ist, dass die Zone sich in Kontrolle des ausführenden AWS Accounts befindet und das auch der domainName ein Teil der Zone ist. Zu guter Letzt werden die User Pool infos mit userPoolId und userPoolClientId angegeben. Dadurch weiß die Lambda@Edge gegen wohin das Token verifiziert werden muss.

Ausblick

Es wäre cool wenn auch andere Identity Provider außer Cognito wie eventuell Google oder Okta verwendet werden könnten zur Validierung des Tokens.

Was auch noch fehlt sind private User Scope. Das wären quasi Unterverzeichnisse im privaten Bucket auf welcher dann nur der validierte User zugreifen kann. Zurzeit können die validierten User nämlich noch auf alle Assets im Bucket zugreifen.

Auch wäre es super mal zu versuchen inwiefern Cloudfront Function sich eignet anstelle von Lambda@Edge. Cloudfront Functions sind quasi eine abgespeckte Version von Lambda@Edge. Diese haben eine reduzierte Funktionalität und reduzierte Ressourcen. Sind dafür aber günstiger pro Aufruf. Ich bin sehr zuversichtlich, dass Cloudfront Functions ausreichen zum validieren der Tokens.

Falls ihr eines der hier angesprochenen Features bereits benötigt oder andere coole Feature Ideen habt schreibt mir gerne oder erzeugt direkt Issues im Construct Repo https://github.com/mmuller88/cdk-private-asset-bucket . Gerne könnte ihr auch PRs schreiben um euer Feature eingebaut zu bekommen.

Zusammenfassung

Private S3 Assets wie Bilder oder Videos werden fast immer in modernen Apps benötigt. Bisher konnten solche nur per umständlichen presigned URLs private gehalten werden. Diese Lösung scheint aber nicht optimal da sie keine User Tokens verwendet um auf die Assets zuzugreifen. Hier in diesem Blogpost habe ich euch eine Variante vorgestellt bei der man mit Cognito User Tokens seine privaten S3 Assets Verfügbar machen kann. Wenn euch der Beitrag gefällt oder ihr Fragen und Anregungen habt, schreibt mir doch gerne.

Werde ein Patreon!

Private S3 Assets with Cloudfront, Lambda@Edge and AWS CDK

Sun, 13 Feb 2022 00:00:00 GMT

Hi,

Private S3 assets like images or videos are a frequently needed feature for apps. After the user has logged in, those private assets are shown to him. These are typically stored in an S3 bucket. This S3 bucket must not be publicly available.

The common solution for such a scenario are presigned URLs. Presigned URLs are specially generated URLs that allow the owner of that URL to access the asset. A presigned URL could look like this:

https://presignedurldemo.s3.eu-west-2.amazonaws.com/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJJWZ7B6WCRGMKFGQ%2F20180210%2Feu-west-2%2Fs3%2Faws4_request&X-Amz-Date=20180210T171315Z&X-Amz-Expires=1800&X-Amz-Signature=12b74b0788aa036bc7c3d03b3f20c61f1f91cc9ad8873e3314255dc479a25351&X-Amz-SignedHeaders=host

Mhh but if I already have a user management system like AWS Cognito, wouldn't it be more elegant if I could simply access private assets using the user JWT tokens? Yes absolutely! And to keep the programming effort low Cloudfront and Lambda@Edge can be used.

In this blogpost I want to explain how Cloudfront and Lambda@Edge can be used to build a proxy that allows authenticated users to access S3 asset urls such as https://image.example.com/funny.png . If the token needed for this is then also stored as a cookie, you can even use the HTML img tag like:

<img src="https://image.example.com/funny.png">funny.png</img>

Solution Approach

This diagram best describes how the Cloudfront Proxy works.

The flow to access the asset is very simple. First the user gets a valid Cognito token. This can be done via the Amplify UI, the hosted Cognito login UI or a Lambda. Then the asset is accessed via a GET request, for example https://image.example.com/funny.png . The request requires a cookie with the name token and the Cognito token as value.

Remember this is necessary if you want to use the HTML img tag. The img tag does not accept tokens in the header. Alternatively, you could code the token as URL parameter. As a curl command it would look something like this:

curl --location --request GET "https://image.example.com/funny.png" --cookie "Cookie: token=ey..."

For testing the URL, I recommend Postman because it can also display images in the response.

AWS CDK Custom Construct

I wrote an AWS CDK Custom Construct to easily integrate private assets via Cognito Token. You can see exactly how the construct works in GitHub at https://github.com/mmuller88/cdk-private-asset-bucket. The construct has a pretty simple interface:

export interface PrivateAssetBucketProps {
  readonly assetBucketName?: string;
    /**
     * if you want to use an imported bucket instead
     */
  readonly assetBucketNameImport?: string;
  readonly customDomain?: CustomDomain;
  readonly userPoolId: string;
  readonly userPoolClientId: string;
}

export interface CustomDomain {
  readonly zone: route53.IHostedZone;
    /**
     * domainName needs to be part of the hosted zone
     * e.g.: image.example.com
     */
  readonly domainName: string;
}

With the optional assetBucketName a name is assigned to the created bucket. If you omit this property, the name is determined by the CDK naming algorithm, a composition of stackname, constructname and random postfix. If you prefer to import an existing bucket you can do this with assetBucketNameImport. In this case the previous property is ignored.

The customDomain object with the properties zone and domainName allows the assignment of a custom domain like e.g. https://mail.example.com . It is important that the zone is in control of the running AWS account and that the domainName is also part of the zone. Last but not least the user pool infos are specified with userPoolId and userPoolClientId. This way the Lambda@Edge knows against where the token has to be verified.

Outlook

It would be cool if other identity providers besides Cognito like Google or Okta could be used to validate the token.

What is also missing are private user scopes. Those would be basically subdirectories in the private bucket which only the validated user can access. Currently, the validated users can still access all assets in the bucket.

It would also be great to try Cloudfront Function instead of Lambda@Edge. Cloudfront Functions are a slimmed-down version of Lambda@Edge. They have reduced functionality and resources. But they are cheaper in general. I am very confident that Cloudfront Functions will be sufficient to validate the tokens.

If you already need one of the features mentioned here or have other cool feature ideas feel free to write me or create issues directly in the Construct Repo https://github.com/mmuller88/cdk-private-asset-bucket . You can also write PRs to get your feature implemented.

Summary

Private S3 assets like images or videos are almost always needed in modern apps. Until now they could only be kept private via unhandy presigned URLs. But this solution doesn't seem optimal as it doesn't use user tokens to access the assets. Here in this blog post, I presented a variant where you can make your private S3 assets available with Cognito user tokens. If you like this post or if you have any questions or suggestions, feel free to write me.

Thanks to the DeepL translater (free version) for helping with translating to English and saving me tons of time :).

To the wonderful readers of this article, I'm saying that feedback of any kind is welcome. In the future, I will try to include a discussion and comment feature here. In the meantime, please feel free to send me feedback via my social media accounts such as Twitter or FaceBook. Thank you very much :).

I love to work on Content Management Open Source projects. A lot from my stuff you can already use on https://github.com/mmuller88 . If you like my work there and my blog posts, please consider supporting me on Patreon:

Become a Patreon!

Deploy Lambda@Edge mit AWS CDK und TypeScript

Sun, 06 Feb 2022 00:00:00 GMT

Moin,

Lambda@Edge sind Lambdas die in den AWS Cloudfront Locations ausgeführt werden. Somit kann die Performance erhöht und die Latency verringert werden im Vergleich zum normalen Lambda. Cloudfront zusammen mit Lambda@Edge lässt sich aber auch als Proxy für einen private S3 Asset Bucket verwenden.

Ein Token ausgestellt von Cognito dient dann der Lambda@Edge zu Validierung ob der Requester erlaubt ist auf das Asset im S3 Bucket zuzugreifen. Näheres darüber möchte ich im nächsten Blogpost beschreiben. Hier soll es darum gehen wie ein Lambda@Edge mit AWS CDK und Typescript erstellt werden kann.

AWS CDK Lamda@Edge

Lambda@Edge gibt es bereits im CDK cloudfront package https://docs.aws.amazon.com/cdk/api/v1/docs/aws-cloudfront-readme.html . Leider ist es nicht direkt möglich den Lambda Code mit TypeScript zu schreiben und automatisch nach JavaScript zu transformieren so wie wir es bereits von der NodejsFunction kennen.

Tja nicht mit mir! Ich hab mir mal die NodejsFunction und die EdgeFunction genauer angeschaut und die die TypeScript Funktionalität von NodejsFunction auf die EdgeFunction übertragen. Dabei definiere ich einfach ein CDK Construct welches von EdgeFunction extended und übernehme Funktionen und Properties von der NodejsFunction. Und hier ist der Code von meinem nodejs-edge-function.ts Construct:

import * as cloudfront from '@aws-cdk/aws-cloudfront';
import * as core from '@aws-cdk/core';
import * as bundling from '@aws-cdk/aws-lambda-nodejs/lib/bundling';
import * as lambda from '@aws-cdk/aws-lambda';
import * as fs from 'fs';
import * as path from 'path';
import { BundlingOptions } from '@aws-cdk/aws-lambda-nodejs';
import { PackageManager } from '@aws-cdk/aws-lambda-nodejs/lib/package-manager';
import { callsites, findUpMultiple } from '@aws-cdk/aws-lambda-nodejs/lib/util';


/**
 * environment variables are not supported for Lambda@Edge
 */
export interface NodejsEdgeFunctionProps extends Omit<lambda.FunctionOptions, 'environment'> {
    /**
   * Path to the entry file (JavaScript or TypeScript).
   *
   * @default - Derived from the name of the defining file and the construct's id.
   * If the `NodejsFunction` is defined in `stack.ts` with `my-handler` as id
   * (`new NodejsFunction(this, 'my-handler')`), the construct will look at `stack.my-handler.ts`
   * and `stack.my-handler.js`.
   */
    readonly entry?: string;

    /**
     * The name of the exported handler in the entry file.
     *
     * @default handler
     */
    readonly handler?: string;

    /**
     * The runtime environment. Only runtimes of the Node.js family are
     * supported.
     *
     * @default Runtime.NODEJS_14_X
     */
    readonly runtime?: lambda.Runtime;

    /**
 * Whether to automatically reuse TCP connections when working with the AWS
 * SDK for JavaScript.
 *
 * This sets the `AWS_NODEJS_CONNECTION_REUSE_ENABLED` environment variable
 * to `1`.
 *
 * @see https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/node-reusing-connections.html
 *
 * @default true
 */
    readonly awsSdkConnectionReuse?: boolean;

    /**
     * The path to the dependencies lock file (`yarn.lock` or `package-lock.json`).
     *
     * This will be used as the source for the volume mounted in the Docker
     * container.
     *
     * Modules specified in `nodeModules` will be installed using the right
     * installer (`npm` or `yarn`) along with this lock file.
     *
     * @default - the path is found by walking up parent directories searching for
     *   a `yarn.lock` or `package-lock.json` file
     */
    readonly depsLockFilePath?: string;

    /**
     * Bundling options
     *
     * @default - use default bundling options: no minify, no sourcemap, all
     *   modules are bundled.
     */
    readonly bundling?: BundlingOptions;

    /**
     * The path to the directory containing project config files (`package.json` or `tsconfig.json`)
     *
     * @default - the directory containing the `depsLockFilePath`
     */
    readonly projectRoot?: string;

    /**
     * The stack ID of Lambda@Edge function.
     *
     * @default - `edge-lambda-stack-${region}`
     * @stability stable
     */
    readonly stackId?: string;
}

export class NodejsEdgeFunction extends cloudfront.experimental.EdgeFunction {

    constructor(scope: core.Construct, id: string, props: NodejsEdgeFunctionProps) {
        const handler = props.handler ?? 'handler';
        const runtime = props.runtime ?? lambda.Runtime.NODEJS_14_X;
        const entry = path.resolve(findEntry(id, props.entry));
        const architecture = props.architecture ?? lambda.Architecture.X86_64;
        const depsLockFilePath = findLockFile(props.depsLockFilePath);
        const projectRoot = props.projectRoot ?? path.dirname(depsLockFilePath);
        super(scope, id, {
            ...props,
            runtime,
            stackId: props.stackId,
            code: bundling.Bundling.bundle({
                ...props.bundling ?? {},
                architecture,
                runtime,
                depsLockFilePath,
                entry,
                projectRoot,
            }),
            handler: `index.${handler}`,
        });
    }
}

/**
 * Checks given lock file or searches for a lock file
 */
function findLockFile(depsLockFilePath?: string): string {
    if (depsLockFilePath) {
        if (!fs.existsSync(depsLockFilePath)) {
            throw new Error(`Lock file at ${depsLockFilePath} doesn't exist`);
        }

        if (!fs.statSync(depsLockFilePath).isFile()) {
            throw new Error('`depsLockFilePath` should point to a file');
        }

        return path.resolve(depsLockFilePath);
    }

    const lockFiles = findUpMultiple([
        PackageManager.PNPM.lockFile,
        PackageManager.YARN.lockFile,
        PackageManager.NPM.lockFile,
    ]);

    if (lockFiles.length === 0) {
        throw new Error('Cannot find a package lock file (`pnpm-lock.yaml`, `yarn.lock` or `package-lock.json`). Please specify it with `depsFileLockPath`.');
    }
    if (lockFiles.length > 1) {
        throw new Error(`Multiple package lock files found: ${lockFiles.join(', ')}. Please specify the desired one with \`depsFileLockPath\`.`);
    }

    return lockFiles[0];
}

/**
 * Searches for an entry file. Preference order is the following:
 * 1. Given entry file
 * 2. A .ts file named as the defining file with id as suffix (defining-file.id.ts)
 * 3. A .js file name as the defining file with id as suffix (defining-file.id.js)
 * 4. A .mjs file name as the defining file with id as suffix (defining-file.id.mjs)
 */
function findEntry(id: string, entry?: string): string {
    if (entry) {
        if (!/\.(jsx?|tsx?|mjs)$/.test(entry)) {
            throw new Error('Only JavaScript or TypeScript entry files are supported.');
        }
        if (!fs.existsSync(entry)) {
            throw new Error(`Cannot find entry file at ${entry}`);
        }
        return entry;
    }

    const definingFile = findDefiningFile();
    const extname = path.extname(definingFile);

    const tsHandlerFile = definingFile.replace(new RegExp(`${extname}$`), `.${id}.ts`);
    if (fs.existsSync(tsHandlerFile)) {
        return tsHandlerFile;
    }

    const jsHandlerFile = definingFile.replace(new RegExp(`${extname}$`), `.${id}.js`);
    if (fs.existsSync(jsHandlerFile)) {
        return jsHandlerFile;
    }

    const mjsHandlerFile = definingFile.replace(new RegExp(`${extname}$`), `.${id}.mjs`);
    if (fs.existsSync(mjsHandlerFile)) {
        return mjsHandlerFile;
    }

    throw new Error(`Cannot find handler file ${tsHandlerFile}, ${jsHandlerFile} or ${mjsHandlerFile}`);
}

/**
* Finds the name of the file where the `NodejsFunction` is defined
*/
function findDefiningFile(): string {
    let definingIndex;
    const sites = callsites();
    for (const [index, site] of sites.entries()) {
        if (site.getFunctionName() === 'NodejsEdgeFunction') {
            // The next site is the site where the NodejsFunction was created
            definingIndex = index + 1;
            break;
        }
    }

    if (!definingIndex || !sites[definingIndex]) {
        throw new Error('Cannot find defining file.');
    }

    return sites[definingIndex].getFileName();
}

Wie ihr seht habe ich viele private Funktionen aus der NodejsFunction übernommen. Das Construct wird nun folgendermaßen in meinen CDK Stack importiert:

import { NodejsEdgeFunction } from './nodejs-edge-function';

...

const imageAccessFunction = new NodejsEdgeFunction(this, 'edge');

Der Lambda@Edge code verhält sich nun genauso wie wir es gewöhnt sind von der NodejsFunction. Der TypeScript Lambda-Code kann nun im src Folder mit dem Namen STACK.edge.ts angelegt werden. Benötigte third-party Libraries können bequem in der root package.json notiert werden. Webpack als module bundler sorgt dan für eine effiziente Transformierung in das JavaScript Format.

Zusammenfassung

Mega cool oder? Mit ein paar Handgriffen kann ich nun auch wie gewohnt meine Lambda@Edge in TypeScript schreiben. Natürlich plane ich den Code ins aws-cdk Repo zu kontribuierten. Hoffentlich wird mein PR dann baldig akzeptiert und ihr müsst euch nicht die Mühe machen meinen Code hier zu importieren. Findet ihr mein Construct hilfreich? Falls ja schreibt mir!

Werde ein Patreon!

My first days at kreuzwerker

Fri, 21 Jan 2022 00:00:00 GMT

Hi,

I have decided to go back to working with AWS full time. Even though I had a lot of fun diving into the world of Blazer and Dotnet, I just missed working with AWS too much. So I asked around in the German AWS community if anyone else is looking for a remote AWS DevOps position. Immediately kreuzwerker contacted me. In this post, I want to briefly describe the cool experience during the interviews and onboarding with kreuzwerker. But first, a few words about kreuzwerker.

kreuzwerker

kreuzwerker is an AWS consulting company based in Frankfurt am Main, Berlin, Munich, Zurich and Warszawa (Poland). It was founded in 2010 by Bernd, Joern Bathel and Tilmann Eing. The main motivation to found kreuzwerker was to create a better environment for IT consultants. kreuzwerker should become a company where employees have fun at work. And as you will read they have achieved their goal!

Interview

I had the interviews with Oliver and Manuel. The conversations with both of them were super cool and I immediately noticed that the company puts a lot of emphasis on a positive culture. The concept of culture and especially a positive once does not seem to be very widespread in Germany. So I will explain it briefly here. Culture means how is the living environment within the company is. For example how the employees interact with each other.

This is also necessary because as an AWS consulting company, complex problems, such as designing and building technological solutions, have to be solved. And this can only be achieved if a positive culture is created in the company. That guarantees that every employee gives it best and can give.

And that kreuzwerker has such a positive culture, I noticed immediately during the interviews with Oliver and Manuel. I think they also noticed that I fit in well with this culture. Yes, and indeed, appearances have not dimmed. In my first onboarding days, I was able to experience how great kreuzwerker is.

Onboarding

In this section, I would like to tell you about my onboarding days. I had my onboarding in the Berlin kreuzwerker office. The office is very central in Berlin. Since I live a good two hours outside of Berlin and have never worked in Berlin before, I found it very exciting to come into the office.

In the reception, I was greeted very warmly by the office manager and had a small room tour. Since we are still in the middle of the pandemic and it was also the first week in 2022, the office was less staffed. But that made it easier to remember the new names. I think names are very important and I try to keep them in my head.

And then it was off to my first appointment with the IT staff. The IT staff explained the systems I used and handed over my hardware. I found and still find my new MacBook with the M1 chip very exciting. It has been a few years since I used a MacBook. I currently use Ubuntu exclusively. But I immediately felt happy again with the MacBook.

The following days contained usual onboarding stuff. I did online courses about security at work, with data and how to design my workstation ergonomically correct or how to use JIRA. The fancy video animations in the courses made this rather dry part quite entertaining. And actually, I learned one or two interesting things about data security :). I also find it extremely cool that there is a cook who provides us with a delicious and healthy lunch every day.

I already mentioned how important a positive culture is. What fascinated me was that during my days of onboarding, I noticed this positive culture not only among the developers but also among all the other employees. I think it's so great that kreuzwerker manages to get all employees to interact positively with each other.

I have already met two developers from my team. Both are still at the beginning of their career as I am already a few years ahead ^^. We had great conversations. I'm impressed how far both are already in their development as developers. At the end of January, we plan to go to Frankfurt to meet the rest of the team. I'm really looking forward to that.

Summary

The interview and the first days of onboarding at kreuzwerker were fantastic. I have briefly described here what this experience was like. I'm very grateful to be part of the kreuzwerker team and, I'm looking forward to working with our customers to build technical solutions they will love :). If you also want to work for kreuzwerker, feel free to contact me. See you soon :).

Thanks to the DeepL translater (free version) for helping with translating to English and saving me tons of time :).

Become a Patreon!

CDK BitBucket Staging Pipeline Learnings (Teil 2)

Fri, 07 Jan 2022 00:00:00 GMT

Hi CDK folks.

Vor ein paar Monaten berichtete ich euch über mein spannendes Projekt eine voll funktionsfähige CDK BitBucket Staging Pipeline zu bauen. Seit dem ist viel passiert und wir haben die Pipeline weiter entwickelt.

Probleme mit CDK Cross-Stack Referenzen

CDK Cross-Stack Referenzen sind CDK Outputs die einem anderen CDK Stack als Input übergeben werden. Hier ist ein Beispiel:

/**
 * Stack that defines the bucket
 */
class Producer extends cdk.Stack {
  public readonly myBucket: s3.Bucket;

  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const bucket = new s3.Bucket(this, 'MyBucket', {
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });
    this.myBucket = bucket;
  }
}

interface ConsumerProps extends cdk.StackProps {
  userBucket: s3.IBucket;
}

/**
 * Stack that consumes the bucket
 */
class Consumer extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props: ConsumerProps) {
    super(scope, id, props);

    const user = new iam.User(this, 'MyUser');
    props.userBucket.grantReadWrite(user);
  }
}

const producer = new Producer(app, 'ProducerStack');
new Consumer(app, 'ConsumerStack', { userBucket: producer.myBucket });

Das Beispiel ist entnommen von https://docs.aws.amazon.com/cdk/api/v1/docs/aws-s3-readme.html#sharing-buckets-between-stacks . Du siehst hier sehr gut wie im Producer Stack die myBucket Variable erzeugt wird und wie der Consumer Stack darauf zugreift. Das ist eine CDK Cross-Stack Referenz. Und genau solche sind in unserem Projekt problematisch geworden.

Wenn num im Producer Stack etwas geändert wird was z.B. ein Löschen und anschließendes Neuerstellen der myBucket Variable zu folge hätte, würde Cloudformation mit einem Error antworten und ein Rollback veranlassen. Der Grund ist da der Consumer die Cross-Stack Referenz verwendet, kann diese nicht so ohne weiteres gelöscht werden. Solche und weitere Probleme haben uns das Entwickeln schwer gemacht.

Wir denken und hoffen aber nun eine gute Lösung gefunden zu haben. Zu einem haben wir die Anzahl der Stacks reduziert von ungefähr 7 auf 4. Die Neuzuordnung der Services in die 4 Stacks orientiert sich nun am DDD (Domain Driven Design). Das bedeutet alle Services die zu einer Domain gehören wie z.B. der React App werden zu einem Stack gebündelt. Davor war die Aufteilung eher zufällig und orientierte sich Anhand der AWS Services wie der LambdaStack oder der CognitoStack. Nun sind die Stacks nach ihren Domaine zugeordnet und heißen FrontendSiteStack, FrontendBackendStack und MLStack.

Diese neue Aufteilung hat die Anzahl der Cross-Stack Referenzen stark reduziert. So dass quasi nur noch wenige übrig geblieben sind die wir in den CommonStack ausgelagert haben. Der CommonStack dient allerdings als Parent Stack zu den drei anderen. Wenn nun nur Cross-Stack Referenzen zwischen Parent und Children Stacks herrschen, sollte das viel weniger Probleme verursachen als Referenzen zwischen Geschwister Stacks.

Unabhängige Stacks

Die nächste Herausforderung war, dass die Entwickler es gerne möglich hätten die drei neuen Stacks FrontendSiteStack, FrontendBackendStack und MLStack unabhängig voneinander zu deployen. Bisher wurden alle drei immer gleichzeitig deployed.

Um dieses Problem haben wir uns für Custom Variables entschieden. Custom Variables sind Variablen die bei Custom Pipelines beim Ausführen gesetzt werden können. Um nun die Stacks unabhänging voneinander deployen zu können, muss die Custom Pipeline mit den folgenden Variablen ausgeführt werden:

custom:
  cdkDeploy:
    - variables:
        - name: deployFrontendSite
          default: false
        - name: deployFrontendBackend
          default: false
        - name: deployML
          default: false

Startet man die cdkDeploy Pipeline mit der BitBucket UI können die drei Variablen bei bedarf auf true geändert werden. Ein simples Bash Command checkt dann ob die Variable true ist oder nicht:

script:
  - if [ "$deployFrontendSite" != true ]; then exit 0; fi

Somit kann interaktiv über die Ausführung der Custom Pipeline und dem Setzen der Variablen der gewünschte Stack deployed werden. Very cool!

Stage

Das Konzept einer Stage kann den CDK Code wesentlich übersichtlicher machen. Eine Stage fasst alle CDK Stacks zusammen die zu einer Stage we dev oder prod gehören. Hier ist ein Beispiel.

export class Stage {

  /**
     * A stage which is a collection of stacks.
     *
     */
  constructor(scope: core.Construct, props: StageStackProps) {

    const commonStack = new CommonStack(scope, props.stage + '-CommonStack', { stage: props.stage, env: props.env });

    new FrontendBackendStack(scope, props.stage + '-FrontendBackendStack', {
      stage: props.stage,
      domainName: commonStack.domainName,
      zone: commonStack.zone,
      vpc: commonStack.vpc,
      env: props.env,
      userPoolId: props.userPoolId,
    });

    new MLStack(scope, props.stage + '-MLStack', {
      stage: props.stage,
      domainName: commonStack.domainName,
      zone: commonStack.zone,
      vpc: commonStack.vpc,
      env: props.env,
      enableAlarms: props.enableLambdaAlarms,
    });
  }
}

Die Stage wird nun einfach in den main.ts importiert:

new Stage(app, { stage: 'dev', env: devEnv, userPoolId: 'us-west-2_3zgoE123' });

Durch die Verwendung einer Stage Wrapper Klasse haben wir unseren Code wesentlich übersichtlicher und einfacher wartbar gestaltet.

What next?

Eine Staging Pipeline ist schon mal ein guter Anfang um effektiv und schnell neue Features zu entwickeln und in die Produktion zu bringen. Um allerdings noch schneller und vor allem unabhängiger von anderen Entwickler Teams entwickeln zu können, werden ephermal Deployments benötigt.

Ephermal Deployments bedeutet, dass bei jedem neuen Branch potentiell eine eine komplett neues CDK Deployment ausgespielt werden kann welches die Änderungen von dem Branch beinhaltet. Somit müssen sich die Entwickler z.B. die dev Umgebung nicht mehr teilen um neue Features auszuprobieren und zu testen. Ich bin mal gespannt wie wir das machen werden.

Unser React Frontend benötigt zur Buildzeit Backend Informationen die AWS Amplify typisch in einer config File gespeichert werden. Diese müssen mühselig per hand aktuell gehalten werden. Von daher wäre es cool wenn wir ähnlich wie bei der Amplify CLI es ermöglichen können, dass der Config File dynamisch vor dem Build gebaut werden kann. Unsere initiale Idee ist es, das mit AWS Api Gateway zu ermöglichen. Der Endpoint würde uns dann immer die aktuellen Backenddaten übermitteln und wir können diese als Config File speichern.

Zusammenfassung

Es macht mir immer noch Spaß mit BitBucket Pipeline zu arbeiten. Damit lassen sich tolle CDK Deployment Pipelines bauen. In diesem Post habe ich beschrieben welche neuen Herausforderungen wir hatten und wie wir sie gelöst haben. Auch sehr freut mich das mittlerweile der Kunde auch selber in der Lage ist die CDK Pipeline zu benutzen und das auch vermehrt tut.

An die tollen Leser dieses Artikels sei gesagt, dass Feedback jeglicher Art gerne gesehen ist. In Zukunft werde ich versuchen hier eine Diskussionsfunktion einzubauen. Bis dahin sendet mir doch bitte direkten Feedback über meine Sozial Media accounts wie Twitter oder FaceBook. Vielen Dank :).

Werde ein Patreon!

Dankbarkeit 2021

Thu, 30 Dec 2021 00:00:00 GMT

Ein herzliches hallo,

Auch dieses Jahr möchte ich wieder Danke sagen. Für das Jahr 2021 stand die Familie im Mittelpunkt. Natürlich gelten meine Danksagungen von meinen vorherigen Post auch noch! In dieser Danksagung möchte ich speziell für 2021 und dessen Ereignisse Danke sagen.

Gott

Auch dieses Jahr hast du Gott deine schützende Hand über uns gelegt. Du hast uns mit Gesundheit und Liebe gesegnet. Soweit sind wir von Corona verschont geblieben und ich behaupte, dass sich unserer Lebensstil durch Corona dieses Jahr nicht verändert hat. Bitte behüte uns auch in 2022. Amen.

Oma

Wisst ihr wer mein zweit größtes Vorbild ist? Nun mein größtes ist Jesus. Danach kommt meine Oma Katharina Lauck. Sie ist gegen Ende November verstorben. Mit 93 Jahren und 26 Uhrenkelkindern hatte sie ein erfülltes Leben und ist nun bei ihrem Herren.

Sie war immer eine tolle Oma. Allerdings erst zur ihrer Beerdigung habe ich realisiert was für ein toller Mensch sie auch war. Ich habe viele tolle Geschichten aus ihrer Vergangenheit gehört. Sie war wahrlich eine gutmütige Frau. Sie hat die Welt zu einem besseren Ort gemacht und das ist auch mein Ziel. Vielen Dank Oma für Alles. Ruhe in Frieden.

Frau und Tochter

Natürlich danke ich speziell euch beiden auch wieder 2021. Wir sind sehr gesegnet mit einer gesunden Tochter und einer tollen Mami und Ehefrau. Ihr zwei habt 2021 außergewöhnlich gemacht! Durch euch zwei fühle ich mich ununterbrochen stark und bereit alle Alltagsprobleme und berufliche Herausforderungen zu meistern. Vielen lieben Dank ihr zwei.

Meine Mutter

Auch in diesem Jahr möchte ich speziell meiner Mutter danken. Sie ist immer für uns da wenn wir sie brauchen. Auch bin ich ihr sehr dankbar, dass wir uns immer ihr Auto ausleihen können wenn wir es brauchen. Auch wunderschön ist die starke Bindung zwischen ihr und und Rebecca (unserer Tochter). Danke dass du eine so tolle, hilfsbereite und liebenswerte Oma bist <3 .

Sogros (Schwiegereltern)

Mitte Dezember sind meine Schwiegereltern aus Brasilien zu uns gekommen. Ich bin sehr dankbar dass ihr hier seid und uns so toll unterstützt. Ich freue mich auf noch zwei weitere tolle Monate mit euch. Ich hab euch ganz doll lieb :) !

Solarmon

Aus tiefstem Herzen möchte ich Danke sagen zu meinen Ex-Kollegen aus dem Solarmon Projekt. Es war eine sehr aufregende Zeit und es hat mir viel Spaß gemacht neue Features mit Blazor und DotNet zu implementieren. Das Entwicklerteam bestand aus zwei Entwicklern und einem Produktowner.

Die Entwickler waren ein Senior und ein Junior dessen Position ich inne hatte. Vor allem mit dem Senior zusammenzuarbeiten hat mir am meisten Spaß gemacht. Wir hatten tolle professionelle Diskussionen.

Gegen Ende des Jahres 2021 hatte ich dann aber den schweren Entschluss gefasst mich wieder stärker auf AWS zu fokussieren. Vielen vielen Dank für die tolle Zeit und ich wünsche euch viel Erfolg für 2022 mit dem Solarmon Projekt.

Zusammenfassung

2021 war ein tolles Jahr. Auch wenn es noch viel mehr gibt wofür ich Danke sagen sollte, mache ich doch in diesem Post den Anfang. Für was seit ihr 2021 dankbar gewesen?

Werde ein Patreon!

Thankfulness 2021

Thu, 30 Dec 2021 00:00:00 GMT

A warm hello,

Once again this year I would like to say thank you. The center of 2021 of course was my family. Still my thanks from 2021 are still valid! In this post I would like to say thanks specifically for 2021 and its events.

God

This year, too, you God have laid your protective hand over us. You have blessed us with health and love. So far we have been spared from Corona and I our lifestyle has not changed due to Corona this year. Please keep us safe also in 2022. Amen.

Grandma

Do you know who my second biggest role model is? Well my biggest is Jesus. After that comes my grandma Katharina Lauck. She passed away at the end of November. With 93 years old and 26 great grandchildren, she had a full life and is now with her Lord.

She was always a great grandma. However, it wasn't until her funeral that I realized what a great person she was also. I heard many great stories from her past. She was truly a kind-hearted woman. She made the world a better place and that is my goal as well. Thank you grandma for everything. Rest in Peace.

Wife and daughter

Of course, I especially thank you both again 2021. We are very blessed with a healthy daughter and a great mommy and wife. You two have made 2021 extraordinary! Because of you two, I feel continuously strong and ready to face all daily problems and professional challenges. Thank you so much you two.

My mother

Also this year I would like to thank especially my mother. She is always there for us when we need her. I am also very grateful to her that we can always borrow her car when we need it. Also wonderful is the strong bond between her and Rebecca (our daughter). Thank you for being such a great, helpful and loving grandma <3 .

Sogros (Parents in law)

My parents in law from Brazil came to stay with us in the middle of December. I am very grateful that you are here and supporting us so great. I am looking forward to two more great months with you guys. I love you guys so much :) !

Solarmon

From the bottom of my heart I want to say thank you to my ex-colleagues from the Solarmon project. It was a very exciting time and I had a lot of fun implementing new features with Blazor and DotNet. The development team consisted of two developers and a product owner.

The developers were a senior and a junior whose position I held. I especially enjoyed working with the senior the most. We had great professional discussions.

Towards the end of 2021, however, I had made the tough decision to focus more on AWS technologies again. Thank you very much for the great time and I wish you all the best for 2022 with the Solarmon project.

Summary

2021 was a great year. Even though there is a lot more I should say thanks for, I'll make a start in this post. What were you thankful for in 2021?

Thanks to the DeepL translater (free version) for helping with translating to english and saving me tons of time :).

To the wonderful readers of this article I'm saying that feedback of any kind is welcome. In the future I will try to include a discussion and comment feature here. In the meantime, please feel free to send me feedback via my social media accounts such as Twitter or FaceBook. Thank you very much :).

I love to work on Content Management Open Source projects. A lot from my stuff you can already use on www.github.com/mmuller88 . If you like my work there and my blog posts, please consider supporting me on Patreon:

Become a Patreon!

Asynchrone Kommunikation mit AWS CDK EventBridge

Sun, 14 Nov 2021 00:00:00 GMT

Hallo CDK Fans

Für ein Startup soll ich eine Security Plattform bauen. Der grobe Ablauf zur Benutzung der Plattform ist in etwa so. Der Kunde beantwortet ein paar Fragen und bekommt dann eine Security Auswertung angezeigt. Für den Prototypen habe ich mich entschieden AWS EventBridge zu benutzen. Damit erreiche ich eine Entkopplung und asynchrone Verarbeitung der Services zu einander, zu gewährleisten.

Das war das erste mal, dass ich EventBridge verwendet habe und ich bin sehr begeistert. Da es noch nicht all zu viel AWS CDK EventBridge Material im Internet gibt, wollte ich dich gerne an meiner Experience teilhaben lassen.

Nachfolgend beschreibe ich die Security Plattform etwas genauer und wie meine Architektur aussieht.

Security Plattform

Der Nutzer kann mittels Desktop App oder Mobile App einige Fragen beantworten. Die Antworten werden im User-Service gespeichert und asynchron an den Security-Service geschickt. Ist die Verarbeitung im Security-Service fertig, bekommt der Nutzer das Ergebnis als Report präsentiert.

Architektur

Der Prototyp hat drei Module. Diese drei Module sind jeweils mit ihrem eigenen CDK Stack implementiert. Das ist das Frontend, der User-Service und der Security-Service.

Frontend

Das Frontend ist eine ReactTS App welches in S3 via static Webhosting gehosted wird. Die App nutzt Amplify Libraries zum Usermanagement wie Sign up, Password wiederherstellen, Login, Logout. Auch nutze ich Amplifies GraphQl Libraries als typisierten Zugriff auf das AppSync im User-Service. Schau auch gerne in meine anderen Beiträge über Appsync rein.

Der Nutzer soll nach dem Einloggen eine Reihe von Security Fragen beantworten. Die Antworten werden über GraphQL Queries an den User-Service geleitet. Darüber hinaus besitzt das Frontend noch eine Liste von Security Reports welche von dem Security-Service erstellt wurde.

User-Service

Die Antworten werden nun im AppSync verarbeitet und in eine Antworten DynamoDB Tabelle gespeichert. Von dort aus lauscht eine DynamoDB Stream Lambda auf neue oder geänderte Antworten. Die Lambda schreibt dann die Antwort als AntwortEvent in den EventBridge EventBus. Der EventBus leitet das AntwortEvent weiter an den Security-Service.

Nachdem der Security-Service das AntwortEvent verarbeitet hat sendet dieser ein ReportEvent an den User-Service via den EventBus zurück. Eine Report Lambda im User-Service erhält dann das ReportEvent und schreibt den Report via GraphQL Mutation in eine Report DynamoDB Tabelle.

Das Frontend besitzt eine GraphQl Subscription für neu erscheinende Reports und somit wird die Liste der Reports automatisch geupdated sofern ein neuer Report gespeichert wird.

Security-Service

Der Security-Service erhält ein AntwortEvent vom User-Service mittels EventBus von EventBridge. Das AntwortEvent ist ein Wrapper und enthält neben der Antwort selbst noch Eventdaten wie Created, Updated, Status. Eine Report Lambda empfängt dann die Antwort und verarbeitet diese zu einem Report. Anschließend wird der Report in ein ReportEvent gepackt und zurück an den User-Service gesendet.

Noch reicht es für die Erstellung des Reports eine Lambda zu verwenden. Das könnte sich in Zukunft aber auch ändern da der Report komplexer werden soll und z.B. auch third party APIs verwenden soll. Dann könnte ein etwas komplexerer Workflow anstehen. Mit der Verwendung dieser Eventarchitektur sollte das aber kein Problem werden.

EventBridge

Zum senden der Events zwischen dem User-Service und dem Security-Service benutze ich den default EventBus. Das AnswerEvent und ReportEvent sehen so aus:

import { Answer, Report } from '../frontend/src/lib/api';

export interface AnswerEvent {
  answer: Answer;
  state: State;
}

export interface ReportEvent {
  report: Report;
}

Interessant hier ist vielleicht dass ich für die Definition der Events einfach auf die von AppSync generierten GraphQL Wrapper Klassen im Frontend zurückgreife unter ../frontend/src/lib/api.

Nun definiert man noch die Lambdas welche das jeweilige Event in den default EventBus packen. Hier z.B. die Lambda welche das AntwortEvent in den EventBus packt.

import * as AWS from 'aws-sdk';
const EventBridge = new AWS.EventBridge();

export async function handler(event: lambda.DynamoDBStreamEvent) {

  let answer: Answer | null = null;

  // unmarshall DynamoDBStreamEvent
  ...

  const answerEvent: AnswerEvent = {
    answer,
    state: State.new,
  };

  const params: AWS.EventBridge.Types.PutEventsRequest = {
    Entries: [
      {
        Detail: JSON.stringify(answerEvent),
        DetailType: DetailType.AnswerEvent,
        EventBusName: 'default',
        Source: Source.userServiceDdbStream,
        Time: new Date,
      },
    ],
  };
  const result = await EventBridge.putEvents(params).promise();
}

Im EventStack müssen dan noch sogenannte Rules und Targets definiert werden.

const answerRule = new events.Rule(this, 'answerRule', {
  eventPattern: {
    source: [Source.userServiceDdbStream],
  },
});
answerRule.addTarget(new targets.LambdaFunction(props.ratingLambda));

const reportRule = new events.Rule(this, 'reportRule', {
  eventPattern: {
    source: [Source.ratingServiceLambda],
  },
});
reportRule.addTarget(new targets.LambdaFunction(props.getReportEventLambda));

Zusammenfassung

Services asynchron miteinander kommunizieren zu lassen ist mega toll und aufregend. Mit AWS EventBridge und AWS CDK ist es zusätzlich noch eine wundervolle Developer Experience. Ich bin sehr gespannt wo sich die Security Plattform noch hinentwickelt :).

Werde ein Patreon!

Eine CDK BitBucket Staging Pipeline

Sun, 31 Oct 2021 00:00:00 GMT

Seit einiger Zeit arbeite ich für einen Kunden mit sehr aufregenden AWS CDK Aufgaben. Der Kunde ist stark im Atlassian Ecosystem unterwegs. Zum hosten des Codes wird BitBucket verwendet. Nun will der Kunde stärker in den DevOps Bereich vordringen und seine AWS Deployments auch mit AWS CDK managen. Dafür soll die vorhandene AWS Infrastruktur in CDK übersetzt werden. Zusätzlich soll eine Staging Deployment-Pipeline die CDK Apps auf den Stages dev, qa und prod deployen. Gerne helfe ich da weiter :).

Disclaimer

Auch wenn ich bereits sehr viel Erfahrung mit CDK habe (siehe hier), kenne ich mich so noch gar nicht mit BitBucket aus. Von daher weiß ich nicht ob mein Ansatz der ideale ist, aber zum Zeitpunkt des Schreibens dieses Artikels, funktioniert dieser ganz gut :).

Ich schreibe diesen Artikel hauptsächlich da ich keine anderen hilfreichen Posts oder Anweisungen gefunden habe, wie man vernünftig eine CDK Staging Deployment-Pipeline baut mit BitBucket. Falls du also vielleicht eine ähnliche Aufgabe hast, kann ich dir damit den Einstieg eventuell erleichtern.

Welche Pipeline?

Nun stellte sich natürlich die frage wo soll die CDK Staging Deployment-Pipeline denn leben? Zu Auswahl standen AWS CodePipeline oder BitBucket's Pipeline.

Vielleicht AWS CodePipeline?

Der Vorteil von AWS CodePipeline wäre das es dafür schon geniale AWS CDK Staging Pipeline Construct gibt wie z.B. der CDK Pipeline . Damit hätte man fast alles was das DevOps Herz begehrt z.B. eine Synth Action wobei aus CDK das Cloudformation template generiert wird und Deploy Actions die dann zu den jeweiligen Stages deployen. Auch mega genial von der CDK Pipeline sind die optionalen Actions die nach dem Deploy zu einer Stage ausgeführt werden können. Damit können z.B. Integrations Tests nach dem Deploy ausgeführt werden. Auch sehr schön ist, dass die Pipeline in TypeScript definiert ist und z.B. somit eine Dokumentation mitliefert und durch die Types einen gewissen Standard ja bereits schon vorgibt.

Oder BitBucket's Pipeline?

Der Kunde verwendet bereits BitBucket's Pipeline zum Testen, Linten und dem Erstellen von Builds. Von daher wäre es unschön wenn der Kunde gezwungen wäre zwischen den zwei Pipeline Dashboards AWS CodePipeline und BitBucket's Pipeline hin und her zu schalten. Außerdem lassen sich prinzipielle ja alle Funktionen von der AWS CodePipeline und dem CDK Pipeline Construct ja quasi nach programmieren mit BitBucket's Pipeline.

Ein ziemlich cooles Feature welches AWS CodePipeline nicht hat, ist das Skippen von Steps falls das angegebene Subdirectory nicht geändert wurde. Hier ist ein Beispiel:

- step:
    name: Synth CDK app
    condition:
      changesets:
        includePaths:
          - "bitbucket-pipelines.yml"
          - "devops/**"
    script:
      - echo "synth cdk app"
      ...

So ein cooles Feature vermisse ich bei AWS CodePipeline. Auch verwendet der Kunde ein Monorepo. Es sind also alle Projekte in einem BitBucket Repository. Das wäre auch sehr Nachteilig für AWS CodePipeline da dieses ja immer bei jedem Commit einen Pipeline Run auslösen würde.

Unter Berücksichtigung aller Vor- und Nachteile haben wir uns für BitBuckets's Codepipeline als CDK Staging Deployment-Pipeline entschieden.

Ordnerstruktur

Wie bereits gesagt, der Kunde hat ein Monorepo und das möchte dieser natürlich beibehalten. Wir haben uns nun für die folgender Ordnerstruktur entschieden:

devops # Contains AWS CDK dependencies and CDK Apps
devops/${STAGE} # Contains stage specific scripts like bootstrap command
devops/${STAGE}/vpc # VPC CDK App
devops/${STAGE}/cognito # Cognito CDK App
devops/${STAGE}/website # S3 Website CDK App
...

STAGE ist entweder dev, qa oder prod .

Im devops Ordner befinden sich die AWS CDK dependencies. Via package.json werden alle benötigten CDK Libraries geladen z.B. :

  "dependencies": {
    ...
    "@aws-cdk/aws-s3": "1.129.0",
    "@aws-cdk/aws-cloudfront": "1.129.0",
    "@aws-cdk/aws-cloudfront-origins": "1.129.0",
    "@aws-cdk/aws-s3-deployment": "1.129.0",
    ...
  }

Auch beinhaltet die devops/package.json ein Script zum bootstrap des Build AWS Accounts und des Synthetisierens. Der Build AWS Account ist der Account von wo aus die Stages verwaltet werden. Synthetisieren bezeichnet man den Prozess bei der die CDK App in ein oder mehrere Cloudformation Templates überführt wird:

"scripts": {
  ...
  "synth": "yarn build && yarn cdk synth",
  "bootstrap": "yarn build && yarn cdk bootstrap --trust 11111111,222222,3333333 --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess aws://44444444/us-east-1"
},

Der Bootstrap command erzeugt einen CDK Helper Stack im Build Account 44444444 und trusted allen Stages dev = 11111111, qa = 222222, prod = 3333333. Trusted meint hier das der CDK Helper Stack Role eine Cross Account Deploy Erlaubnis hinzugefügt wird. Damit kann der Build Account in die verschiedenen Stage Accounts deployen. Sehr wichtig ist auch, dass jeweils die Stage Accounts einen Bootstrap durchführen müssen. Der Bootstrap command befindet sich dann jeweils in devops/${STAGE}/package.json z.B. für dev:

"scripts": {
  ...
  "bootstrap": "yarn cdk bootstrap --trust 44444444 --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess aws://$11111111/us-east-1"
}

Wie man hier sieht muss auch umgekehrt der Stage Account z.b. dev=11111111 dem Build Account 44444444 trusten. Diese Bootstraps können etwas verwirrend sein, müssen aber zum Glück nicht oft durchgeführt werden. Ich empfehle trotzdem den Bootstrap Prozess gut zu dokumentieren in z.B. der Readme.md . Generell halte ich eine gute Dokumentation für sehr sehr hilfreich :).

Beispiel VPC

In jeder Stage soll es ein VPC geben in der private Infrastruktur wie Postgres DBs deployed werden sollen. Jede Stage beinhaltet also ein VPC subdirectory devops/${STAGE}/vpc . Dort in einer main.ts befindet sich der CDK Code. Ich zeige das hier anhand von der dev Stage:

import * as cdk from '@aws-cdk/core';
import { VpcStack } from '../../components/vpc-stack';
const env = require('../package.json').env;

export const DevVpcStack = (app: cdk.App) => new VpcStack(app, `${env.stage}-VpcStack`, { env });

Da jede Stage einen VPC benötigt, macht es Sinn den gemeinsamen VPC CDK Code in eine shared Componente zu platzieren under dem Ordner devops/components :

export class VpcStack extends cdk.Stack {

  vpc: ec2.Vpc;

  constructor(scope: cdk.Construct, id: string, props: VpcStackProps) {
    super(scope, id, props);

    this.vpc = new ec2.Vpc(this, 'vpc', { maxAzs: 2 });
  }
}

In devops/src/main.ts wird dann das jeweilige VPC geladen:

import * as cdk from '@aws-cdk/core';
import { DevVpcStack } from '../dev/vpc/main';
import { ProdVpcStack } from '../prod/vpc/main';
import { SqaVpcStack } from '../sqa/vpc/main';
import { StagingVpcStack } from '../staging/vpc/main';

const app = new cdk.App();

// vpcs
const devVpc = DevVpcStack(app).vpc;
const sqaVpc = SqaVpcStack(app).vpc;
const stagingVpc = StagingVpcStack(app).vpc;
const prodVpc = ProdVpcStack(app).vpc;

...

Zugegeben die künstliche Aufteilung der Stages in devops/${STAGE}/vpc und anschließendem Zusammenführen in devops/src/main.ts ist etwas komisch und eventuell nicht ideal. Alternativ könnte auch einfach alles in devops/src/main.ts geschrieben werden. Wir erhoffen uns so aber eine bessere Übersichtlichkeit über die "einzelnen" CDK stacks.

Bitbucket Pipeline

Die Bitbucket Pipeline durchläuft nun grob die folgenden Schritte. Zuerst werden parallel Tests durchlaufen und Builds gebaut. Unter den Builds sind z.B. auch verschiedene React Builds für die verschiedenen Stages. Danach wird der CDK synth mittels yarn cdk synth durchgeführt. Beim synth werden Assets wie z.B. die verschiedenen React Builds in S3 geuploaded:

- step:
  name: Synth CDK app
  caches: 
    - node-custom
  condition:
    changesets:
      includePaths:
        - "bitbucket-pipelines.yml"
        - "devops/**"
  script:
    - export AWS_REGION=us-west-2
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_BUILD
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_KEY_BUILD
    - cd devops
    - yarn synth
  artifacts:
    - devops/cdk.out/**

Nach dem synth kann nun die erste Stage dev die per CDK synthetisierten Cloudformation Templates anwenden. Dafür benutze ich z.B. diesen CDK Command:

yarn cdk deploy -a 'cdk.out/' dev-VpcStack --require-approval never

Der cdk.out Ordner wurde vorher beim CDK synth step als Artifact ausgewiesen und wird nun für die jeweiligen Stages (hier dev) und CDK stacks wiederverwendet. Der Pipeline yaml Code sieht folgendermaßen aus:

- parallel:
    - step:
        name: Deploy vpc to dev
        caches: 
          - node-custom
        condition:
          changesets:
            includePaths:
              - "bitbucket-pipelines.yml"
              - "devops/**"
        script:
          - export AWS_REGION=us-west-2
          - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_BUILD
          - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_KEY_BUILD
          - cd devops/dev/vpc && yarn deploy-cdk-stage
          - cd ../hasura && yarn deploy-cdk-stage
    - step:
        name: Diff qa
        caches: 
          - node-custom
        condition:
          changesets:
            includePaths:
              - "bitbucket-pipelines.yml"
              - "devops/**"
        script:
          - export AWS_REGION=us-west-2
          - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_BUILD
          - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_KEY_BUILD
          - cd devops/qa && yarn diff
    - step:
        name: Approval deploy qa
        trigger: manual
        condition:
          changesets:
            includePaths:
              - "bitbucket-pipelines.yml"
              - "devops/**"
              - dashboard/**
        script:
          - echo "Deploy"
  - parallel:
        # qa stage simila looking to dev

Es wird also direkt in die dev Stage deployed. Dabei wird auch parallel ein diff zur nächsten Stage qa erzeugt. Um auch den qa deploy durchzuführen, muss via manual trigger beim Approval deploy qa step zugestimmt werden. Stimmt man zu läuft der ganze Prozess in qa analog zu dev ab.

What next?

Im Sinne der Übersichtlichkeit fehlt uns noch eine Art Dashboard um die wichtigsten CfnOutput URLs anzuzeigen wie z.B. die Cloudfront Urls von den React Apps. Auch will man ja wissen welcher Commit bei dem jeweiligen Deploy verwendet wurde. Dafür würde sich sehr gut ein Dashboard eignen welches per Lambda die aktuellen Deployments sowie deren Commit ID herausfinden und wahrscheinlich auch direkt darstellen kann.

Zusammenfassung

Mit BitBucket als Repository zu arbeiten, war mega cool. Es hat mir viel Spaß gemacht unter diesen Umständen eine CDK Staging Deployment-Pipeline zu bauen. Hier habe ich grob beschrieben wie diese Pipeline aussieht und was unsere Gründe waren diese Pipeline so zu bauen. Ob das gute Entscheidungen waren wird die Zukunft zeigen wenn der Kunde die Pipeline auch tatsächlich benutzt. Glaubst du wir haben etwas übersehen oder du hast Ideen was man besser machen kann? Dann schreibe mir doch bitte :).

Werde ein Patreon!

Security, Best Practice und Hardening Checks mit der Prowler AMI

Fri, 27 Aug 2021 00:00:00 GMT

(Click me :D)

Hi Leute!

Entwickeln in AWS macht Spaß und die Möglichkeiten coole Sachen zu bauen, scheinen unendlich. Aber sind diese tollen Sachen sicher und folgen sie AWS's Best Practices? Mit der Prowler AMI kannst du du mit weit über 180 Checks für viele Services in all deinen Regionen genau das überprüfen. Für nur $1 erstellt dir eine Ec2 Instanz, gestartet mit der Prowler AMI, den cdk-prowler in deinen Account. Dabei wird automatisch ein CodeBuild gestartet der die Checks ausführt. Am Ende erhältst du eine Auswertung der Checks. Die Auswertung enthält Angaben ob der Check erfolgreich war, die Severity, eine Risikobeschreibung und wie Abhilfe geschaffen werden kann.

Im nächsten Abschnitt erkläre ich wie genau Prowler die Checks durchführt.

Prowler Scan

Die Prowler AMI verwendet das Github Prowler Tool. Wenn ihr lokal Prowler mal ausprobieren wollt, verwendet die Anweisungen aus der Readme. Prowler kann dann wahlweise als Script mit ./prowler oder als Docker Container ausgeführt werden. Prinzipiell durchläuft Prowler dann die Checks mit der AWS CLI aus dem check Folder.

Nach dem Durchlauf der Checks wird ein HTML Report in einen S3 Bucket mit Namen prowleraudit-stack-prowlerauditreportbucket gespeichert (siehe Bild von oben). Der HTML Report listet nun alle Findings der durchgeführten Checks auf. Diese können seit kürzlich releasten Prowler Version 2.5.0 nun auch gefiltert werden.

Run Prowler mit AMI

Wie Eingangs erwähnt könnt ihr Prowler mit meiner Prowler AMI in euren Account deployen. In diesen Abschnitt erkläre ich euch wie genau das geht.

Zuerst klickt ihr natürlich auf den Prowler AMI Link und subscribed zu der AMI. Das Subscriben dauert einen kleinen Moment. Nachdem die Subscription abgeschlossen ist klickt auf "Continue to Configure". Wählt dort nun die neueste Prowler Version aus und die Region in der ihr die Prowler Checks durchführen wollt. Anschließend klickt auf "Continue to Launch". Nun ganz wichtig bei "Choose Action" müsst ihr "Launch through Ec2" auswählen. Nun werdet ihr auf Ec2 in der AWS Console weitergeleitet.

Einfach den vorausgewählten Instance Typen auswählen welcher t2.micro sein sollte. Dann auf "Next: Configure Instance Details" klicken. Nun ganz wichtig! Bei der IAM role braucht ihr eine Ec2 Role die Administrator Privilege hat. Falls die Role noch nicht existiert klickt auf "Create new IAM role" und erstellt eine AWS service Role für Ec2 mit der AdministratorAccess Policy. Die Prowler AMI braucht diese Permission um den CDK stack bei euch deployen zu dürfen.

Alternativ könnt ihr Prowler auch direkt über die Ec2 AWS Console aufrufen. Dafür einfach in der AWS Console auf Ec2 wechsel --> Instances --> Launch Instances und sucht dann nach Prowler. Der Rest verhält sich genauso wie im vorherigen Abschnitt beschrieben.

Nun wird der Prowler Cloudformation Stack deployed und der Prowler Check mittels CodeBuild gestartet. Am ende landet der HTML Report im S3 Bucket prowleraudit-stack-prowlerauditreportbucket .

Die Ec2 Instanz wird nur zum deployen des Cloudformation Stacks benötigt und sollte nach Fertigstellung des Stacks terminiert werden um Kosten zu sparen.

Rerun Prowler mit AMI

Um erneut den Prowler Scan durchzuführen, müsst ihr einfach die AMI bzw. die Ec2 Instanz mit der AMI nochmal ausführen. Der Prowler Stack wird somit veranlasst den Scan nochmal durchzuführen.

Zusammenfassung

Prowler ist ein tolles Tool zum überprüfen des AWS Accounts. Mit weiter über 100 Checks gibt es mir nützliches Feedback über Einstellungen die nicht Best Practices entsprechen. Somit erreiche ich eine höhere Sicherheit in meinen AWS Accounts. Mit meiner Prowler AMI ist es dazu noch kinderleicht das Tool im Account auszuführen. Probiert gerne die Prowler AMI aus und berichtet mir eure Erfahrung :).

Werde ein Patreon!

Automatisiertes AWS Security Feedback mit Prowler und AWS CDK

Tue, 17 Aug 2021 00:00:00 GMT

Hi Leute!

Toni De La Fluente hat das super coole AWS Security Tool Prowler entwickelt. Prowler ist ein cli tool für die Durchführung und Beratung von AWS Security Assessment, Auditing, Hardening and Incident Response. Mit mehr als 180 checks bietet Prowler dabei das umfangreichste Security Check Angebot für AWS. Wenn ihr mehr über Prowler wissen wollt besucht die Prowler Github Seite.

Ich benutze Prowler sehr viel und habe mich entschlossen dafür ein AWS CDK Custom Construct zu schreiben. In der Vergangenheit habe ich schon einige Custom Constructs erstellt wie meinem Favoriten der staging pipeline oder der build badge.

Falls ihr Prowler aber einfach nur für euren AWS Account ausführen möchtet und nicht das Custom Construct ausprobieren wollt, habe ich eine gute Nachricht. Für dem AWS Marketplace habe ich eine AMI erstellt welche das cdk-prowler construct automatisch in deinen Account installiert. Die AMI ist erhältlich im AMI Store. Dafür einfach nach Prowler suchen oder ihr nutzt den Prowler AMI Link.

Dann führt Prowler den Security Check durch und ihr findet die Security Findings in einem S3 Bucket mit Namen prowleraudit-stack-prowlerauditreportbucket den HTML Report:

Oder auch in der Codebuild Report group:

Falls ihr irgendwelche Probleme mit der AMI haben solltet, bitte schreibt mir.

Mit dem Kauf der AMI unterstützt ihr auch meine freie Arbeit zur Erstellung solcher frei erhältlichen Produkte wie dem cdk-prowler custom construct und die Arbeit an meinen Blogpost. Vielen herzlichen Dank :)!

In den nächsten Abschnitten erkläre ich warum ich denke, dass ein CDK Custom Construct nützlich ist und und stelle euch das cdk-prowler Custom Construct vor. Vorweg muss ich aber erstmal erklären was AWS CDK überhaupt ist.

AWS CDK

AWS CDK ist ein Open Source Framework zu Erstellung und Verwaltung von AWS Ressourcen. Durch die Verwendung von dem Entwickler vertrauten Sprachen wie TypeScript oder Python wird die Infrastructure as Code beschrieben. Dabei synthetisiert CDK den Code zu AWS Cloudformation Templates und kann diese optional gleich deployen.

AWS CDK erfährt seit 2019 ein stetigen Zuwachs von begeisterten Entwicklern und hat bereits eine starke und hilfsbereite Community die eg. sehr auf Slack aktiv ist. Es gibt natürlich noch viel mehr zu sagen über AWS CDK und ich empfehle euch es zu erforschen. Schreibt mir, wenn ihr Fragen habt.

Motivation

AWS CDK Custom Constructs sind quasi eigene Library zum kapseln von Cloudformation Ressourcen. Diese können auf Registries wie npmjs.com oder pypi.org zum download Angeboten werden. Somit ist es extrem einfach cdk-prowler in seine CDK IDE Umgebung zu integrieren. Auch ist es sehr leicht Änderungen am cdk-prowler code durchzuführen und eine neue Version den jeweiligen Restries bereitzustellen. Vieles von diesen wichtigen aber doch mühseligen Arbeiten wird bereits durch Projen AwsCdkConstructLibrary stark vereinfacht.

Ein weiterer Grund für das Custom Construct ist die Jsii Library. Mit dieser mega coolen Library kann ich das cdk-prowler construct zu verschiedene Sprachen wie Python, Java oder CSharp übersetzen und der Entwickler kann weiterhing in seiner gewohnten CDK Sprache mit cdk-prowler entwickeln.

Beispiel

Das cdk-Prowler Construct ist auf GitHub. Es muss zuerst in der package.json als Dependency eingebunden werden und kann dann im CDK Stack verwendet werden.


import { ProwlerAudit } from 'cdk-prowler';
...

const app = new App();

const stack = new Stack(app, 'ProwlerAudit-stack');

new ProwlerAudit(stack, 'ProwlerAudit');

app.synth();

Der AWS CDK Code zeigt wie leicht cdk-prowler deployed werden kann. Viele Zusatzfunktionen wie einem Scheduler sind bereits erhältlich und über die Properties aktivier- und änderbar . Schaut dafür doch gerne in die API.md.

Ausblick

Viele coole Features für cdk-prowler sind geplant. Die Entwicklung neuer Features geschieht in Zusammenarbeit mit Tony De La Fluente dem Erfinder von Prowler.

Geplant ist Prowler Multiaccount ready zu machen. Somit hat man dann einen zentralisierten Ort für Prowler um alle Accounts überprüfen zu können. Multiaccount soll mit und ohne AWS Organisation funktionieren.

Zukünftig soll der Prowler nicht mehr mit Codebuild sondern mit Fargate ausgeführt werden. Das ermöglicht eine flexiblere Weiterentwicklung von Prowler um z.B. Scans zu parallelisieren. Die Prowler Scans zu parallelisieren ist ein wichtiges und sehr benötigtes Feature da mit über 180 Prowler Tests die sequentiell ausgeführt werden, die Ausführung sehr lange dauern kann.

Auch denken Tony und ich über eine verbessertes UI Analyse Tool mit QuickSight nach. Der Prowler HTML Report ist zwar sehr nützlich aber es ist schwer komplexe Abfragen and den Report zu schicken. Mit QuickSight hat man z.B. die Möglichkeit zur Definition von Filtern, Variablen usw.

Zusammenfassung

Prowler ist mega cool und ich liebe es, dass es mir automatisiert Feedback über Security, Best Practises usw. gibt. Mit AWS CDK lässt sich ProwlerAudit leicht installieren und mit anderen Services verschachteln. Testet das ProwlerAudit Construct und gebt mir Vorschläge um es noch cooler zu machen. Gerne könnt ihr dafür auch PRs in Github erstellen.

Werde ein Patreon!

Wordpress Beiträge automatisieren mit AWS CDK

Sun, 08 Aug 2021 00:00:00 GMT

Hi Leute!

In meinem letzten Post ging es darum wie ich ein Wordpress Deployment mit Docker und ein paar coolen Scripts, DevOps freundlicher gestalten kann. Heute soll es um eine andere spannende Aufgabe gehen. Undzwar möchte der Kunde, dass mittels AWS und beim Hochladen von Videos zu S3, automatisch neue Wordpress Beiträge erzeugt werden. Das klingt nach einer spannenden Aufgabe. In den nächsten Abschnitten beschreibe ich meine Lösung.

Wordpress AWS Lösung

Wie oben beschrieben möchte ich, dass nach dem Video Upload zu S3 ein Wordpress Beitrag erstellt wird. Und natürlich soll das Video dann in dem Post eingefügt sein. Dafür brauche ich hauptsächlich die zwei AWS Services S3 und Lambda. Das Lambda muss dann so eingestellt werden, dass bei einem Upload zu S3 die Lambda Logik ausgeführt wird.

Das Lambda soll sich dann mittels SSH in die Wordpress Umgebung einloggen und per WP CLI einen neuen Beitrag erstellen. Ich finde es ziemlich cool, dass Wordpress eine eigene CLI hat. Mit dieser kann ich dann z.B. einfach neue Beiträge erstellen.

Die Konfiguration der AWS Services mache ich mit AWS CDK. Den kompletten Code findet ihr in meinem Github Repo hier

AWS CDK

Der Wordpress S3 Lambda Stack sieht nun folgendermaßen aus:

import { S3EventSource } from '@aws-cdk/aws-lambda-event-sources';
import * as lambdajs from '@aws-cdk/aws-lambda-nodejs';
import * as s3 from '@aws-cdk/aws-s3';
import * as cdk from '@aws-cdk/core';
import * as statement from 'cdk-iam-floyd';

export interface UploadBucketStackProps extends cdk.StackProps {
  readonly stage: string;
}

export class UploadBucketStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props: UploadBucketStackProps) {
    super(scope, id, props);

    const bucket = new s3.Bucket(this, 'my-videos', {
      bucketName: 'my-videos',
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true,
    });

    const lambda = new lambdajs.NodejsFunction(this, 'upload-trigger', {
      bundling: {
        externalModules: [
          'ssh2',
        ],
        nodeModules: [
          'ssh2',
        ],
      },
    });

    lambda.addToRolePolicy(new statement.Secretsmanager().allow().toGetSecretValue());

    lambda.addEventSource(new S3EventSource(bucket, {
      events: [s3.EventType.OBJECT_CREATED],
    }));
  }
}

Bei der Lambda habe ich mich für das NodeJsFunction Construct entschieden weil es mit vielen Vorteilen kommt wie esbuild als Packagemanager und ich somit keine separate package.json für die Lambda erstellen muss da esbuild sich den benötigten Library Code aus der Haupt package.json zusammensucht.

Das ssh2 Modul für die Lambda muss allerdings als external Modul geladen werden. Das bedeuted einfach, dass esbuild hierfür nicht als packagemanager verwendet wird und das Modul komplett geladen wird.

Der Code für die Lambda Function wird im nächsten Abschnitt gezeigt und erklärt.

Lambda

Die Lambda hat als Event Source den S3 Bucket und wird beim Erstellen von Objekten im S3 Bucket ausgeführt. Dann verbindet sich die Lambda mit dem Wordpress Hoster über SSH und erstellt einen Wordpress Beitrag mittels WP CLI.

import * as lambda from 'aws-lambda';
import * as AWS from 'aws-sdk';
import { NodeSSH } from 'node-ssh';

var secretsmanager = new AWS.SecretsManager();

export async function handler(event: lambda.S3CreateEvent) {
  console.debug(`event: ${JSON.stringify(event)}`);

  const record = event.Records[0];

  const sshKey = await (await secretsmanager.getSecretValue({ SecretId: 'sshkey' }).promise()).SecretString;

  const ssh = new NodeSSH();
  await ssh.connect({
    host: 'mywordpresshoster.com',
    username: 'wp',
    privateKey: sshKey,
  });

  const objectKey = event.Records[0].s3.object.key;
  const videoLink = `https://${record.s3.bucket.name}.s3.${record.awsRegion}.amazonaws.com/${objectKey}`;

  // DateiName: LektionID_KategorieID_Titel
  // eg. 001_41_Das-ist-die-erste-Lektion.mp4
  // Kategorien: 41 - Grundlagen

  const fileName = objectKey.split('.')[0]; // eg. 001_kategorie1_Das-ist-die-erste-Lektion
  const videoFormat = objectKey.split('.')[1]; // eg. mp4
  videoFormat;
  const splittedFilename = fileName.split('_');
  const lection = Number(splittedFilename[0]); // eg. 1
  const category = Number(splittedFilename[1]); // eg. 41
  category;
  const title = splittedFilename[2].replace(/-/g, ' '); // eg. Das ist die erste Lektion


  console.debug(`video info: ${lection} ${category} ${title} ${videoFormat}`);

  const wpContent = `[vc_row][vc_column][vc_column_text]

Lektion ${lection}: ${title}

[/vc_column_text][us_separator][vc_column_text]

Here will be some content ...

<video poster="PATH-TO-STILL-IMAGE" controls="controls" controlsList=”nodownload” width="640" height="360">
    <source src="${videoLink}" type="video/mp4">
</video>

`;

  const wpCommand = `wp post create --post_title='${title}' --post_categories='${category}' --post_content='${wpContent}'`; // category?

  await ssh.execCommand(wpCommand/*, { cwd:'/var/www' }*/).then(result => {
    console.log('STDOUT: ' + result.stdout);
    console.log('STDERR: ' + result.stderr);
  });
};

Wie ihr sehen könnt verwende ich die NodeSSH Klasse vom node-ssh package um mich zu dem wordpress Hoster zu verbinden. Dann pare ich einige Informationen vom S3 Objekt Key wie dem Titel oder die Lektion. Am Schluss erstelle ich einfach mit der WP CLI die wordpress Beiträge.

Zusammenfassung

Die Erstellung von Wordpress Beiträgen mittels AWS Services zu automatisieren ist einfach mega cool. Dafür habe ich einen kleinen AWS CDK Stack gebaut. Ich bin schon sehr gespannt was sich eventuell noch in Wordpress automatisieren lässt :). Habt ihr vielleicht eine Idee? Dann schreibt mir!

Werde ein Patreon!

Wordpress mit Docker

Sat, 03 Jul 2021 00:00:00 GMT

Hi Leute!

Für meinen neusten Kunden habe ich ein tolles AWS Backend mit AWS AppSync und vielen tollen weiteren AWS Services gebaut. Nun stehe ich aber vor der spannende Aufgabe die AppSync bzw. GraphQL API in einem Wordpress Frontend aufrufbar zu machen. Ich habe schon viel über Wordpress gehört aber noch nie damit gearbeitet.

Auch wird dieses Wordpress auf Raidbox.de gehostet was es etwas schwierig macht das Deployment direkt zu verwalten. Kommend aus der DevOps Welt will ich natürlich das Wordpress Deployment so angenehm und automatisiert wie möglich konfigurieren.

Drei Anforderungen wollte ich dabei vom dem Wordpress Deployment erfüllt haben. Erstens soll Wordpress lokal mit minimalem Aufwand ausführbar sein. Zweitens soll das Wordpress mit GitHub versioniert sein. Und drittens soll ein Synchronisation zwischen dem lokalen Wordpress und dem auf Raidbox gehosteten Wordpress stattfinden.

Wordpress

Wordpress ist ein Content Management System (CMS). Es wurde entwickelt zum erstellen von Blogposts. Es hat sich aber stark weiterentwickelt und wird nicht mehr nur für Blogposts benutzt. Über sogenannte Plugins werden neue Feature zu Wordpress hinzugefügt. Solche Features können sein eine Bezahlfunktion. Wir selber verwenden Digimember zum Verwalten eines Abobezahlsystems.

Wordpress mit Docker

Zur Lösung meines ersten Problems, also Wordpress lokal zum Laufen zu bekommen, habe ich mich dafür entschlossen Docker zu benutzen. Zum Glück war ich nicht der erste der das versucht bzw. erfolgreich geschafft hat. Es gibt viele gute Anleitungen im Internet wie ein Wordpress Deployment mit Docker aufsetzen kann. Zur Orchestrierung der Docker Container verwende ich Docker Compose und hier ist der Code:

version: '3.3'

services:
  wordpress:
    depends_on:
      - db
    image: wordpress:5.7.2
    volumes:
      - ./wordpress_files:/var/www/html
    ports:
      - "8080:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpressuser
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_PASSWORD: geheim
      WORDPRESS_HOME: 'http://localhost:8080'
      WORDPRESS_SITEURL: 'http://localhost:8080'

  db:
    image: mysql:5.7
    container_name: db
    volumes:
      - ./db_data:/var/lib/mysql
      - ./wordpress_files/wp-content/mysql-dump/wordpress.sql:/docker-entrypoint-initdb.d/1_wordpress.sql:ro
      - ./scripts/wordpress_replacing.sql:/docker-entrypoint-initdb.d/2_wordpress_replacing.sql:ro
    restart: always
    ports:
      - 3306:3306
    environment:
      MYSQL_ROOT_PASSWORD: geheim
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpressuser
      MYSQL_PASSWORD: geheim

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    container_name: phpmyadmin
    restart: always
    ports:
      - "8081:80"
    environment:
      PMA_HOST: db
      MYSQL_ROOT_PASSWORD: geheim

Der erste Docker Container wordpress ist natürlich für Wordpress. Mit dem volume wordpress_files persistiere ich die wordpress files.

Danach kommt der db Container welche eine MySQL Datenbank deployed. Wordpress verwendet MySQL als Datenbank zum Speichern von Informationen wie Blogposts, Sites, User, Pluginconfigs und noch vielen mehr. Das Volume db persistiert dabei die Datenbank. Die nächsten zwei Volumes speichern SQL Scripte im Container unter /docker-entrypoint-initdb.d :

- ./wordpress_files/wp-content/mysql-dump/wordpress.sql:/docker-entrypoint-initdb.d/1_wordpress.sql:ro
- ./scripts/wordpress_replacing.sql:/docker-entrypoint-initdb.d/2_wordpress_replacing.sql:ro

Dadurch werden die SQL Scripte beim ersten Start ausgeführt. Das erste Script wordpress.sql beinhaltet die kompletten Wordpress MySQL Datenbank welche vorher als Dump exportiert wurde. Das zweite Script macht ein Text Replacing von der Domaine zu localhost:

UPDATE wp_options SET option_value = replace(option_value, 'https://www.example.com', 'http://localhost:8080') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET post_content = replace(post_content, 'https://www.example.com', 'http://localhost:8080');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'https://www.example.com','http://localhost:8080');

Das ist nötig weil ich das Deployment ja lokal zum Laufen bekommen möchte.

Der letzt Container phpmyadmin ist eine graphische Verwaltung für die MySQL DB.

GitHub

Den Code also die Wordpress Files und das Docker Compose File nun zu einem GitHub Repository zu pushen ist ein leichtes. Dafür muss ja einfach nur ein neues GitHub Repository erstellt werden und die Dateien in dieses kopiert und gepusht werden.

Nach Raidbox.de syncen

Wie Eingangs schon erwähnt, Raidbox.de ist unserer Hoster für Wordpress. Um nun die MySQL Datenbank und die Wordpress files dort zu aktualsieren habe ich mich für rsync in Kombination mit ssh entschieden. Dafür habe ich einen Workflow entwickelt:

./scripts/syncWithStaging.sh pushes your local wordpress_files/wp-content, then dumps the staging mydb and than pulls the wordpress/wp-content including the dump. If there are changes now that probably means someone changed something directly over raidbox. Inspect the changes! If they are ok git commit the current status!
run docker-compose down && sudo rm -rf db_data && docker-compose up -d --build and make your changes
run ./scripts/createMySqlDumpExport.sh to export the local DB to mysql-dump-export
apply the mysql-dump-export/wordpress.sql to the wordpress with using raidbox phpmyadmin
run ./scripts/syncWithStaging.sh for syncing / pushing the wp-content folder.

Dieser Sync Workflow wird eventuell noch geändert in Zukunft und die Anzahl der Schritte reduziert. So wie dieser jetzt gestaltet ist, lassen sich immer noch über den normalen, über Raidbox erreichbaren Wordpress Editor, z.B. Blogs hinzufügen. Diese neuen Blogposts gehen dann beim nächsten Sync Workflow nicht verloren. Nachfolgend zeige ich noch die verwendeten Scripts

syncWithStaging.sh

#!/bin/bash

# push to remote
rsync -avzh --no-perms --no-owner --no-group -e "ssh -i ~/.ssh/example" ./wordpress_files/wp-content wp@b9emwoc.myraidbox.de:/home/wp/disk/wordpress

# create sql dump on raidbox.de
ssh -i ~/.ssh/example wp@b9emwoc.myraidbox.de "mkdir -p /home/wp/disk/wordpress/wp-content/mysql-dump && mysqldump -u wordpressuser --no-tablespaces --password=geheim wordpress > /home/wp/disk/wordpress/wp-content/mysql-dump/wordpress.sql"

# pull from remote
rsync -avzh --no-perms --no-owner --no-group -e "ssh -i ~/.ssh/example"  wp@b9emwoc.myraidbox.de:/home/wp/disk/wordpress/wp-content ./wordpress_files

Hier sieht man wie mittels rsync, ssh und einem private key (~/ssh/example) die wordpress files zuerst gepusht und dann gepullt werden. Zusätzlich wird noch die MySQL DB auf Raidbox gedumpt und mitgepullt

createMySqlDumpExport.sh

#!/bin/bash

# mysql export sql
CONTAINER=$(docker ps -aqf "name=db")
docker exec $CONTAINER /usr/bin/mysqldump -u wordpressuser --no-tablespaces --password=geheim wordpress_staging > ./mysql-dump-export/wordpress.sql

# replacing http://localhost:8080 with https://www.example.com in the sql dump
sed -i s#http://localhost:8080#https://www.example.com#g ./mysql-dump-export/wordpress.sql

Dieses Script such nach dem MySQL Docker Container und erstellt einen DB dump. Anschließend werden die urls wieder zu den originalen url Namen umgeschrieben. Dieser Dump kann nun mit dem Wordpress auf Raidbox importiert werden. Üblicherweise passiert das mit PHP Admin in Raidbox.

HTML als Code

Eine Sache die mich bei Wordpress sehr stört ist der Inline Editor für HTML und JavaScript Code. Im Vergleich zu z.B. Visual Studio Code bietet dieser null Funktionalität. Was ich als gerne hätte ist, dass die HTML und JavaScript Codeabschnitte im Wordpress über lokale Files gemacht werden kann.

Diese lokalen Files kann ich dann wie gewohnt mit meinem VS Code Editor bearbeiten und bekomme tolle Hilfestellungen wir Syntaxkorrektur, Syntaxhighlighting und viele mehr. Das habe ich erreicht indem ich das HTML und JavaScript in iFrames, welche auf die Files pointen:

<iframe src="/wp-content/themes/Impreza/get-vms.html">

Ein Problem hat das Ganze aber wahrscheinlich noch. Es ist nicht Skalierbar bzw. Responsive wenn sich die größe des Bildschirms ändert weil man z.B. die Wordpress Seite mit einem Handy besucht.

Zusammenfassung

Wordpress ist eine interessante neue Erfahrung für mich. Ich mag den Wordpresseditor welcher ein graphisches Bauen der Webside ermöglicht. Allerdings habe ich viele out of the box DevOps Techniken vermisst. Macht aber nix mit den hier beschriebenen Ansätzen macht die Entwicklung mit Wordpress wesentlich mehr Spaß.

Werde ein Patreon!

AWS Cloudformation deploying mit Lambda

Mon, 07 Jun 2021 00:00:00 GMT

Hi Leute!

Ich arbeite zurzeit an einem spannenden Projekt bei dem es möglich sein soll flexibel über eine API, Ec2 Instanzen zu erstellen. Diese Instanzen sollen dann dem Kunden zu Übungszwecken zur Verfügung gestellt werden. Die Instanzen sollen dabei für den Kunden angepasst werden, also ein bestimmtes Setting haben wie dem Ec2 Typen, ein paar spezielle Tags und einiges mehr.

Das Deployment der Ec2 Instanzen soll möglichst kostengünstig durch Lambdas geschehen. Vor ca einem Jahr hatte ich schonmal ein ähnliches Projekt gemacht bei dem dynamisch Ec2 Instanzen für ein Alfresco Deployment erzeugt werden. Alfresco Provisioner

Wie sich möglichst dynamisch und auch extrem einfach wartbar die Ec2 Instanzen mit AWS CDK über eine API wie Api Gateway oder Appsync deployen lassen, erkläre ich in den nächsten Abschnitten.

AWS CDK

AWS CDK erfährt seit 2019 ein stetigen Zuwachs von begeisterten Entwicklern und hat bereits eine starke und hilfsbereite Community die z.B. sehr auf Slack aktiv ist. Es gibt natürlich noch viel mehr zu sagen über AWS CDK und ich empfehle euch es zu erforschen. Schreibt mir, wenn ihr Fragen habt.

Im nächsten Abschnitt fasse ich kurz die Anforderungen für das dynamische Ec2 Deploying über eine API zusammen.

Anforderungen

Die Ec2 Instanzen sollen dynamisch über eine API wie AWS ApiGateway, welches ein REST API implementiert oder AWS AppSync, welches ein GraphQL implementiert, deploybar sein. Dabei sollen gewisse Tags wie UserId oder VmType an die Ec2 Instanz geheftet werden. Damit lassen sich die Ec2 Instanzen dann wieder leicht auffinden und z.B. in einem React Frontend anzeigen.

Für die Verwaltung, also Erstellung, Löschung und Update der zur Ec2 Instanz gehörenden Resourcen, soll mit Cloudformation (kurz: CFN) geschehen. Cloudformation ist ein praktischer AWS Service zur Verwaltung von solchen Resourcen. Somit kann der Ec2 Stack einfach erstellt, angepasst oder gelöscht werden. Ein weiterer Vorteil für die Verwendung von CFN ist, dass sich so dieser Teil auch separat von Rest wie der API testen lässt. Ich habe dafür sogar eine eigene Staging Pipeline erstellt Stating Lib.

Für die Erstellung der CFN Templates möchte ich AWS CDK verwenden, da die Verwendung von CDK die Erstellung und Wartung des Ec2 Stacks extrem erleichtert.

Das von CDK synthetisierte Ec2 CFN Template soll durch eine Lambda deployed werden.

Problem

Leider ist AWS CDK alleine nicht für diesen Use Case geschaffen. Das Hauptproblem ist, dass die CFN Parameter nicht flexibel sein können und nach der Synth Phase die Parameter festgeschrieben wurden. Dieser Nachteil könnte umgangen werden indem man immer einen kompletten deploy mit Context Parametern z.B.

cdk deploy -c userId=Alice -c vmType=2

macht. Das ist aber sehr unpraktisch da es sehr viel Build time beansprucht und jedes mal ein neues CFN Template quasi erzeugt wird.

Um dieses Problem zu lösen habe ich mich entschieden Cloudformation direkt zu benutzen. Denn CFN hat das schöne Feature der Parameter. Bei jedem CFN Deployment können also Parameter spezifiziert werden um z.B. den Namen der Ec2 Instanz anzupassen. Genau das wonach ich gesucht habe.

Lösung

Ich verwende also CDK für den Ec2 Stack und dem Lambda welches den Ec2 Stack dynamisch deployen soll. Fangen wir mal mit dem Lambda an:

const cdkSchedulerLambda = new lambdajs.NodejsFunction(this, 'scheduler', {
  entry: `${path.join(__dirname)}/lambda/scheduler.ts`,
  bundling: {
    commandHooks: {
      afterBundling(inputDir: string, outputDir: string): string[] {
        return [`cp ${inputDir}/cfn/ec2-vm-stack.template.json ${outputDir} 2>/dev/null`];
      },
      beforeInstall(_inputDir: string, _outputDir: string): string[] {
        return [];
      },
      beforeBundling(_inputDir: string, _outputDir: string): string[] {
        return [];
      },
    },
  },
  logRetention: logs.RetentionDays.ONE_DAY,
  environment: {},
  timeout: core.Duration.minutes(15),
});

Ich verwende hier die LambdaJS Variante. Diese hat den Vorteil dass ich die Lambda scheduler.ts direct in TypeScript definieren kann und das Construct selbstständig diese in JS convertiert und in AWS hochlädt. Das ist als ein toller Grad von Abstraktion. Und mit dem afterBundling webhook kann ich das CFN Template schonmal in die Lambda hochladen. Somit muss ich nicht kompliziert mit einem anderen Storage wie S3 oder EFS arbeiten.

Als nächstes schauen wir uns mal die scheduler.ts an:

// eslint-disable-next-line import/no-extraneous-dependencies
import { readFileSync } from 'fs';
import * as lambda from 'aws-lambda';

import * as AWS from 'aws-sdk';
import { Ec2 } from './query-ec2';

const cfn = new AWS.CloudFormation();

export async function handler(event: lambda.DynamoDBStreamEvent) {
  console.debug(`event: ${JSON.stringify(event)}`);

  if (event.Records.length !== 1) {
    console.debug('event not valid! Exactly one record allowed!');
    return 'failed';
  }

  let newImage: Ec2 | null = null;
  if (event.Records[0].dynamodb?.NewImage) {
    newImage = AWS.DynamoDB.Converter.unmarshall(event.Records[0].dynamodb.NewImage) as Ec2;
  } else {
    console.debug('no NewImage existing');
  }

  let oldImage: Ec2 | null = null;
  if (event.Records[0].dynamodb?.OldImage) {
    oldImage = AWS.DynamoDB.Converter.unmarshall(event.Records[0].dynamodb.OldImage) as Ec2;
  } else {
    console.debug('no OldImage existing');
  }

  const templateBody = readFileSync('./ec2-vm-stack.template.json', 'utf-8');
  console.debug(`templateBody: ${JSON.stringify(templateBody)}`);

  if (newImage) {
    console.debug('Having NewImage so creating or updating');
    const createStackParams: AWS.CloudFormation.Types.CreateStackInput = {
      StackName: `stack-${newImage.userId ?? 'noUserId'}-${newImage.vmType ?? '-1'}`,
      TemplateBody: templateBody,
      Capabilities: ['CAPABILITY_IAM', 'CAPABILITY_NAMED_IAM'],
      Parameters: [{
        ParameterKey: 'userIdParam',
        ParameterValue: newImage.userId,
      }, {
        ParameterKey: 'vmTypeParam',
        ParameterValue: newImage.vmType.toString(),
      }],
    };
    console.debug(`createStackParams: ${JSON.stringify(createStackParams)}`);
    try {
      const createStackResult = await cfn.createStack(createStackParams).promise();
      console.debug(`createStackResult: ${JSON.stringify(createStackResult)}`);
    } catch (error) {
      console.debug(`Creating failed with this error: ${JSON.stringify(error)}`);
      const updateStackResult = await cfn.updateStack(createStackParams).promise();
      console.debug(`updateStackResult: ${JSON.stringify(updateStackResult)}`);
    }
    return 'success';
  } else {
    if (oldImage) {
      console.debug('Having no NewImage but OldImage so deleting!');
      const deleteStackParams: AWS.CloudFormation.Types.DeleteStackInput = {
        StackName: `stack-${oldImage.userId ?? 'noUserId'}-${oldImage.vmType ?? 'noVmType'}`,
      };
      console.debug(`deleteStackParams: ${JSON.stringify(deleteStackParams)}`);
      const deleteStackResult = await cfn.deleteStack(deleteStackParams).promise();
      console.debug(`deleteStackResult: ${JSON.stringify(deleteStackResult)}`);
      return 'deleted';
    }
  }
  return 'failed';
};

Dadurch dass ich ein DynamoDBStreamEvent als Input verwenden, verkompliziert es etwas den Code. Prinzipiell wichtig sind aber diese Zeilen:

const templateBody = readFileSync('./ec2-vm-stack.template.json', 'utf-8');

const createStackParams: AWS.CloudFormation.Types.CreateStackInput = {
      StackName: `stack-${newImage.userId ?? 'noUserId'}-${newImage.vmType ?? '-1'}`,
      TemplateBody: templateBody,
      Capabilities: ['CAPABILITY_IAM', 'CAPABILITY_NAMED_IAM'],
      Parameters: [{
        ParameterKey: 'userIdParam',
        ParameterValue: newImage.userId,
      }, {
        ParameterKey: 'vmTypeParam',
        ParameterValue: newImage.vmType.toString(),
      }],
    };
    console.debug(`createStackParams: ${JSON.stringify(createStackParams)}`);
    try {
      const createStackResult = await cfn.createStack(createStackParams).promise();
      console.debug(`createStackResult: ${JSON.stringify(createStackResult)}`);

      ...

Hier wird also das CFN Template aus der Datei ec2-vm-stack.template.json geladen und mittels AWS SDK createStack applied.

Bleibt also nur noch die ec2-vm-stack.template.json. Wie erzeuge ich diese? Well es ist wie bereits gesagt auch ein CDK Stack. Allerdings benutzt dieser CFN parameters als Input für userIdParam und vmTypeParam. Und hier ist der code für den Ec2 Stack:

import * as ec2 from '@aws-cdk/aws-ec2';
import * as cdk from '@aws-cdk/core';
import { CustomStack } from 'aws-cdk-staging-pipeline/lib/custom-stack';
import { KeyPair } from 'cdk-ec2-key-pair';
import * as statement from 'cdk-iam-floyd';

export interface Ec2StackProps extends cdk.StackProps {
  readonly stage: string;
}
export class Ec2Stack extends CustomStack {
  constructor(scope: cdk.Construct, id: string, props: Ec2StackProps) {
    super(scope, id, props);

    const vpc = ec2.Vpc.fromLookup(this, 'VPC', {
      isDefault: true,
    });

    const securityGroup = new ec2.SecurityGroup(this, 'sg', {
      vpc: vpc,
    });

    securityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(22));
    securityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(80));

    const userData = ec2.UserData.forLinux();
    userData.addCommands(`
#!/bin/bash
yum update -y
yum install -y httpd.x86_64
systemctl start httpd.service
systemctl enable httpd.service
echo “Hello World” > /var/www/html/index.html
    `);

    const userIdParam = new cdk.CfnParameter(this, 'userIdParam', {
      default: 'noUserId',
    });

    const vmTypeParam = new cdk.CfnParameter(this, 'vmTypeParam', {
      default: '-2',
    });

    const identifier = `${userIdParam.value.toString() ?? 'noUserId'}-${vmTypeParam.value.toString() ?? '-1'}`;

    const instance = new ec2.Instance(this, 'instance', {
      instanceName: `vm-${identifier}`,
      instanceType: new ec2.InstanceType('t2.micro'),
      vpc,
      securityGroup,
      keyName: 'mykey',
      machineImage: ec2.MachineImage.latestAmazonLinux({
        generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2,
      }),
      userData,
    });

    cdk.Tags.of(instance).add('Owner', 'Hacklab');
    cdk.Tags.of(instance).add('UserId', userIdParam.value.toString());
    cdk.Tags.of(instance).add('VmType', vmTypeParam.value.toString());

    instance.addToRolePolicy(new statement.Ec2().allow().toDescribeVolumes().toDetachVolume()
      .toAttachVolume().toCreateTags().toDescribeTags().toTerminateInstances().toDeleteSecurityGroup().toDescribeInstances().toStopInstances());

  }
}

Interessant ist, dass ich die CFN Parameter userIdParam und vmTypeParam verwende für den dynamischen Anteil des Ec2 Stacks. Wird der Stack nun als über die Lambda erzeugt, bekommt z.B. die Ec2 Instanz die beiden Tags UserId und VmType mit den Werten der CFN Parameter.

Zusammenfassung

Ec2 Instanzen mittels CFN und Lambdas zu erzeugen ist ne coole Sache. Mit CDK lässt sich alles also die Lambda, die API und der Ec2 Stack sehr leicht formulieren und erweitern. Super cool ist auch, dass es mit CFN sehr leicht ist andere Ressourcen in Zukunft mit dazuzuholen. So will ich z.B. in Zukunft eventuell auch einen S3 Bucket für das Deployment bereitstellen. Ich hoffe der Beitrag hat euch gefallen und vielleicht sogar geholfen. Habt ihr Fragen? Schreibt mir :) !

Werde ein Patreon!

AWS CDK Custom Construct Versions Checker

Tue, 18 May 2021 00:00:00 GMT

Hi CDK Fans!

Mit Custom Constructs ist es möglich gewisse Features als Level 2 AWS CDK Constructs zu implementieren. Tatsächlich sind viele der bereits verwendeten AWS CDK Construct bereits Level 2 Constructs. Ich habe bereits einige Custom Constructs gebaut. Da wäre die Build Badge und die Staging Pipeline.

Wie wir alle wissen iteriert AWS CDK sehr schnell und es wird quasi wöchentlich eine neue Version released. Bei jedem Release besteht die Gefahr, dass meine Custom Constructs nicht mit der releasten CDK Version kompatibel ist. Von daher habe ich einen GitHub Workflow entwickelt der automatisch die Kompatibilität meiner Custom Constructs gegen die neue Version testet.

In den nächsten Abschnitten möchte ich erklären wie der Kompatibilitätscheck funktioniert und wie ich ihn implementiert habe.

AWS CDK

Im nächsten Abschnitt erkläre ich wie de Kompatibilitätscheck mit der AWS CDK Version funktioniert.

Kompatibilitätscheck

Einmal am Tag curlt ein GitHub Workflow, hier Versionschecker genannt, auf die Seite https://github.com/aws/aws-cdk und extrahiert die letzte releaste CDK Version. Dann erstellt der Versionchecker einen Branch im Namenpattern bump/1.X.X . Als also kürzlichst die Version 1.103.0 releast wurde, erstellte der Versionschecker den Branch bump/1.103.0 . Dann erstellt der Versionchecker einen Pull Request gegen master. Der Pull Request beinhaltet nun die neue CDK Version. Das wird erreicht in dem der Versionschecker ein string Replace macht in der .projenrc.js File. Zum Beispiel wird:

const cdkVersion = '1.97.0';

ersetzt durch

const cdkVersion = '1.103.0';

Nun wird ein normaler Build aber mit neuer CDK Version durchgeführt. Der Build testet zu einem die Kompatibilität der CDK Interfaces bzw. dependencies und zum anderen werden die unit Tests automatisiert durchgeführt. Die Verwendung des Versionschecker bedingt also eine gute Unit Testingstrategie. Daher können getestet werden Lambda Code z.B.:

import * as AWS from '../__mocks__/aws-sdk';
import { handler } from '../src/index.badge';

const codebuild = new AWS.CodeBuild();

describe('test index.badge.ts lambda', () => {
  describe('failure when', () => {
    test('queryStringParameters.projectName is not existing', async () => {
      mockedApiEvent.queryStringParameters.projectName = undefined;
      await handler(mockedApiEvent).catch((reason: any) => {
        console.log(`reason: ${reason}`);
        expect(JSON.stringify(reason)).toContain('projectName in query parameter is not existing or empty!');
      });
    ...

und die zu erwarteten synthetisierten Cloudformation Templates:

import { SynthUtils } from '@aws-cdk/assert';
import * as core from '@aws-cdk/core';
import { BuildBadge } from '../src';
import '@aws-cdk/assert/jest';


describe('Get', () => {
  describe('BuildBadge', () => {
    const app = new core.App();
    const stack = new core.Stack(app, 'testing-stack');

    describe('successful', () => {
      test('with not defined hideAccountID', () => {
        new BuildBadge(stack, 'BuildBadge1');
        expect(stack).toHaveResourceLike('AWS::ApiGateway::Method');
        expect(stack).toHaveResourceLike('AWS::Lambda::Function');
        expect(JSON.stringify(SynthUtils.toCloudFormation(stack))).toContain('\"ACCOUNT\":\"123\"');
      });
      test('with hideAccountID = "no"', () => {
        new BuildBadge(stack, 'BuildBadge2', { hideAccountID: 'no' });
        expect(stack).toHaveResourceLike('AWS::ApiGateway::Method');
        expect(stack).toHaveResourceLike('AWS::Lambda::Function');
        expect(JSON.stringify(SynthUtils.toCloudFormation(stack))).toContain('"ACCOUNT\":{\"Ref\":\"AWS::AccountId\"}');
      });
      ...

Diese Beispiele wurden aus meinem Build Badge Construct kopiert.

Versionschecker - GitHub Workflow

Der Versionschecker ist ein GitHub Workflow und wird täglich um 4 Uhr ausgeführt.

name: cdkversioncheck
on:
  schedule:
    - cron:  '0 4 * * *'
  # push:
  #   branches:
  #     - master

jobs:
  check:
    runs-on: ubuntu-latest
    env:
      CI: "false"
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      # - name: Set CDK version manually
      #   run: |-
      #     echo "CDK_VERSION=1.99.0" >> $GITHUB_ENV
      - name: Fetch CDK version
        run: |-
          echo "CDK_VERSION=$(curl --silent "https://api.github.com/repos/aws/aws-cdk/releases/latest" |
          grep '"tag_name": "v1' |
          sed -E 's/.*"v([^"]+)".*/\1/')" >> $GITHUB_ENV
      - name: Synthesize project files
        continue-on-error: true
        run: |-
          yarn add projen
          echo "${{ env.CDK_VERSION }}"
          sed -i "3s/.*/const cdkVersion = '${{ env.CDK_VERSION }}';/" .projenrc.js
          npx projen
      - name: Set git identity
        run: |-
          git config user.name "Auto-bump"
          git config user.email "github-actions@github.com"
      - name: Push branch
        run: |- 
          git checkout -b bump/${{ env.CDK_VERSION }}
          git diff --exit-code || ((git add package.json yarn.lock .projen/deps.json .projenrc.js) && (git commit -m "Testing CDK version to ${{ env.CDK_VERSION }}" && git push -u origin bump/${{ env.CDK_VERSION }}))
      - name: pull-request
        uses: repo-sync/pull-request@v2
        with:
          source_branch: bump/${{ env.CDK_VERSION }}
          pr_title: Testing CDK version to ${{ env.CDK_VERSION }}
          pr_label: "cdk-version-test"  
          destination_branch: "master"
          github_token: ${{ secrets.PUSHABLE_GITHUB_TOKEN }}
    container:
      image: jsii/superchain

Der curl für die Versionsnummer akzeptiert nur v1.X Tags. v2.X ist per Design nicht kompatibel mit meinen CDK Stacks. Der PR würde also immer fehlschlagen.

Es wäre auch möglich manuel gegen bestimmte Versionen zu testen. Dafür müssen einige Zeilen Code auskommentierten bzw. einkommentiert werden. Z.B. Zum manuellen Triggern muss der push master einkommentiert werden. Aucht muss die Action zum curlen der CDK Version auskommentiert und die darüber liegende CDK Version Action einkommentiert werden.

Getestete Versions Liste

Mir kam dan noch die coole Idee zur Erstellung einer List von den bereits getesteten CDK Versionen. Es werden einfach die erstellten Pull Requests mit dem zuvor erstellten Label cdk-version-test versehen.

- name: pull-request
  uses: repo-sync/pull-request@v2
  with:
    source_branch: bump/${{ env.CDK_VERSION }}
    pr_title: Testing CDK version to ${{ env.CDK_VERSION }}
    pr_label: "cdk-version-test"  
    destination_branch: "master"
    github_token: ${{ secrets.PUSHABLE_GITHUB_TOKEN }}

Dann kann einfach per Link auf einen Filter mit dem Label verwiesen werden wie z.B. https://github.com/mmuller88/aws-cdk-build-badge/pulls?q=is%3Apr+is%3Aopen+label%3Acdk-version-test . Und tada es werden alle PRs zum Versionstest angezeigt.

Zusammenfassung

AWS CDK ist nachwievor das optimale Framework für Infrastructure as Code in AWS. Mit meinen Custom Constructs hoffe ich der Community zurückzugeben. Um nun auch immer die beste Experience zu gewährleisten, habe ich einen Workflow entwickelt, der die CDK Versionskompatibilität überprüft. Den Workflow zu erstellen hat mir riesen Spaß gemacht. Noch toller ist jetzt aber eine PR Liste zu haben wo ich genau sehen kann ob die Versionschecks geklappt haben. Ich habe noch weitere spannende CDK Themen in meinem Forum: https://martinmueller.dev/tags/cdk

Werde ein Patreon!

AWS QuickSight DataSet und DataSource CDK Custom Constructs

Thu, 06 May 2021 00:00:00 GMT

Hi.

In meinen vorherigen Blogposts habe ich bereits viel beschrieben und gezeigt wie man mit Hilfe von AWS QuickSight Analysen aus DynamoDB Tabelle generieren kann. Unglücklicherweise ist QuickSight nur minimal unterstützt von Cloudformation und QuickSight's DataSource und DataSet sind bisher nur auf der Roadmap https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/274 .

Deshalb habe ich AWS CDK Custom Constructs für DataSource und DataSet entwickelt. In diesem Post gehe ich etwas genauer darauf ein was QuickSight DataSources und DataSets sind und wie ich mittels AWS CDK Custom Construct deploybar mache.

AWS CDK

DataSource

Eine QuickSight DataSource definiert die Herkunft der Daten für die Analyse. Welche Datenquellen dabei möglich sind, seht ihr sehr gut in der SDK Dokumentation. Das DataSource Construct benutzt dabei auch die SDK Parameterdefinition als typed Input.

Das konkrete Interface findet ihr hier. Wenn man zum Beispiel Athena als DataSource definieren möchte sieht das so aus:

const users=['martin.mueller'];

const datasource = new DataSource(this, 'DataSource', {
  name: 'cdkdatasource',
  dataSourceParameters: {
    athenaParameters: {
      workGroup: 'ddbworkgroup',
    },
  },
  users,
});

dataSourceParameters ist der getypte Parameter vom SDK. Ich finde es ziemlich cool das wir hier nun Typesupport haben und so auch sehr einfach andere Quellen als DataSource wie Aurora oder RDS definieren können <3 . Die workGroup im Beispiel muss vorher erstellt sein. Das kann man manuell mit der AWS Console in Athena machen oder noch besser mit Athena. Wie genau das geht, habe ich bereits in einem vorherigen Blogpost erklärt.

DataSet

Eine DataSet kann dann verwendet werden um die DataSources zu verfeinern und zu konkretisieren. Dabei können zum Beispiel joins oder transforms definiert werden. Alle Möglichkeiten sehr ihr auch hier in der DataSet SDK Dokumentation. Sehr wichtig zu wissen, es müssen die Permissions für DataSource und DataSet immer richtig gesetzt werden. Das habe ich zum Beispiel in den Constructs schon eingebaut.

Die Implementierung des DataSets ist hier. Nachfolgend schildere ich ein etwas komplexeres Beispiel bei dem logische Tabellen aus der DataSource gejoint werden.

new DataSetConstruct(stack, 'DataSetConstruct', {
  name: 'cdkdataset3',
  users: users,
  physicalTableMap: {
    users: {
      customSql: {
        dataSourceArn: datasource.dataSourceArn,
        name: 'users',
        sqlQuery: 'SELECT primarypractice, dateofbirth FROM "ddbconnector"."martin1"."martin1" WHERE groupid = \'users\' AND firstname is not null',
        columns: [
          { name: 'primarypractice', type: 'STRING' },
          { name: 'dateofbirth', type: 'STRING' },
        ],
      },
    },
    practices: {
      customSql: {
        dataSourceArn: datasource.dataSourceArn,
        name: 'practices',
        sqlQuery: 'SELECT id, name FROM "ddbconnector"."martin1"."martin1" WHERE groupid = \'medical-practices\' AND name is not null',
        columns: [
          { name: 'id', type: 'STRING' },
          { name: 'name', type: 'STRING' },
        ],
      },
    },
  },
  logicalTableMap: {
    'users': {
      alias: 'users',
      source: {
        physicalTableId: 'users',
      },
    },
    'practices': {
      alias: 'practices',
      source: {
        physicalTableId: 'practices',
      },
    },
    'users-practices': {
      alias: 'users-practices',
      source: {
        joinInstruction: {
          leftOperand: 'users',
          rightOperand: 'practices',
          type: 'INNER',
          onClause: 'primarypractice = id',
        },
      },
      dataTransforms: [{
        createColumnsOperation: {
          columns: [{
            columnName: 'age',
            columnId: 'age',
            expression: 'dateDiff(parseDate(dateofbirth, "YYYY-MM-dd\'T\'HH:mm:ssZ"),now(), "YYYY")',
          }],
        },
      }],
    },
  },
});

In diesem Beispiel werden virtuell erst die zwei Tabellen users und practices erzeugt und anschließend miteinander gejoined um herauszufinden zu welcher practice der user zugeordnet ist.

Auch führe ich hier ein Daten Transformation durch. Ich möchte gerne das age der user wissen, allerdings ist in den Daten nur das Geburtsdatum vermerkt. Also führe ich eine Tranformation durch bei der das Alter berechnet wird und als neue Spalte mit Namen age definiert wird.

Zusammenfassung

QuickSight ist ein cooles AWS Tool zum Visualisieren von Data Insights. Da ich ein riesen Fan von Infrastructure as Code bin will ich alle QuickSight Ressourcen in CDK haben. Leider sind die DataSource und DataSet noch nicht von Cloudformation unterstützt. Solange das noch so ist, werde ich und könnt ihr gerne meine CDK Custom Construct als Ersatz verwenden :).

Werde ein Patreon!

AWS DynamoDB Analysen mit QuickSight und AWS CDK - Zu große Tabellen

Wed, 21 Apr 2021 00:00:00 GMT

Hi.

In meinem letzten Blogpost habe ich über spannende Arbeiten mit AWS Athena und AWS QuickSight berichtet. Wenn ihr Analysen von kleinen AWS DynamoDB Tabellen machen wollt, sollte alles reibungslos funktionieren. Mit klein meine ich eine relativ geringe Anzahl von Spalten in der Tabelle.

Mir passierte es nämlich das bei der Verarbeitung der TAKE2 Daten, die benötigte Spalten für QuickSight garnicht angezeigt wurden. Nun ist die Anzahl der Spalten in den TAKE2 Daten mit mehr als 700 alles andere als klein! Wie ich das Problem gelöst habe und sogar mit AWS CDK in Code gießen konnte, erfahrt ihr in den nächsten Abschnitten.

Zuvor möchte ich auch dieses mal den Sponsor TAKE2 für diesen Blogpost danken.

Lösung

Also nochmal kurz zusammengefasst. Die DynamoDB Tabelle ist viel zu groß und der Lambda AthenaDynamoDBConnector ist nicht mehr vernünftig in der Lage alle Spalten zu erkennen. Zum Glück haben die Programmierer des Connectors diesen Fall mitbedacht und eine Möglichkeit eingebaut, gezielt Spalten mit deren Namen und Typen definieren zu können.

Die genauen Anweisungen stehen auch im repo. Kurz gesagt muss eine AWS Glue Table erstellt werden. Der Connector kann dann anhand der dort definierten Spalten die gewünschten Spalten erkennen.

Um es anhand des auch im letzten Post verwendeten AWS Komponentendiagrams zu visualisieren, muss lediglich die Glue Tabelle hinzugefügt werden:

AWS CDK Code

Ich abe die CDK Glue Table Erweiterung in ihren eigenen CDK Stack gepackt. Hier ist der Code:

import * as glue from '@aws-cdk/aws-glue';
import * as cdk from '@aws-cdk/core';

interface GlueStackProps extends cdk.StackProps {
  readonly ddbTableName: string;
}

export class GlueStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props: GlueStackProps) {
    super(scope, id, props);

    const database = new glue.Database(this, 'Database', {
      databaseName: props.ddbTableName,
      locationUri: 'dynamo-db-flag',
    });

    const gluetable = new glue.Table(this, 'GlueTable', {
      tableName: props.ddbTableName,
      database: database,
      columns: [{
        name: 'userid',
        type: glue.Schema.BIG_INT,
      }, {
        name: 'firstname',
        type: glue.Schema.STRING,
      }
      ...
      ],
      dataFormat: glue.DataFormat.JSON,
    });

    const cfngluetable = gluetable.node.defaultChild as glue.CfnTable;
    cfngluetable.addPropertyOverride('TableInput.Parameters.classification', 'dynamodb');
    cfngluetable.addPropertyOverride('TableInput.Parameters.columnMapping', 'userid=userId,firstname=firstName,...');
  }
}

Die zu mappenen DynamoDB Spalten müssen einfach als columns in der Glue Table definiert werden. Hier aufgepasst! Glue Table unterstützt bestimmte Zeichen nicht wie Capslock und andere Sonderzeichen. Deswegen muss eventuell noch ein columnMapping vorgenommen werden!

Nach dem deployen können die in columns definierten Spalten in Athena und QuickSight verwendet werden.

Zusammenfassung

Das Analysieren von großen DynamoDB Tabellen ist nicht ganz so einfach. Mit der Verwendung von AWS Glue Tables kann der Lambda AthenaDynamoDBConnector aber trotzdem zuverlässig die gewünschten Spalten erkennen.

Werde ein Patreon!

AWS DynamoDB Analysen mit QuickSight und AWS CDK

Thu, 08 Apr 2021 00:00:00 GMT

Hi.

AWS DynamoDB ist eine extrem performante und skalierbare NoSQL Datenbank. Durch das fehlen eines Schemas können Daten, in DynamoDb Items genannt, extrem flexibel sein. Das erlaubt auch eine Art evolutionäre Weiterentwicklung der Items indem einfach neue Spalten angelegt werden können.

Das ganze hat aber einen Haken. Dadurch, dass wir uns nicht mehr in der Welt der relationalen Daten befinden, können wir keine relationalen Operationen mehr ausführen wie zum Beispiel Joins oder die üblichen relationalen Operationen wie COUNT, ORDER BY, GROUP by und viele mehr. Nun fragst du dich warum sollte ich zum Beispiel Joins ausführen können, die haben uns doch schon genervt bei den relationalen Datenbanken? Wir können Joins zum Beispiel bei Analysen gebrauchen. Ich versuche das zu erklären anhand eines Shops:

Top X verkauften Produkte im Zeitraum von t1 bis t2 grouped by Geschlecht

In unserem Beispiel befinden sich die User und die verkauften Produkte jeweils in ihrer eigenen DynamoDB Tabelle und sind indirekt über eine userId verbunden. Denkbar wäre aber auch dass sich beide in der gleichen Tabelle, aber in unterschiedlichen Datensätzen bzw. Rows befinden. DynamoDB erlaubt keine Joins und somit können wir keine Beziehung zwischen verkauften Produkten und dem Geschlecht herstellen.

Die Lösung für das Problem ist AWS Athena, QuickSight, Lambda und S3. Mit einer Lambda werden die DynamoDB Items als flache JSON File in ein S3 gespeichert. Dann lassen wir Athena darauf zugreifen. QuickSight benutzt Athena dann als Datenengine um Joins, Analysen und Dashboards zu erstellen. Wie ihr das mit AWS CDK automatisiert und eine Beschreibung der verwendeten AWS Services folgen in den nächsten Abschnitten. Für die Ungeduldigen hier schonmal der Code

Zuvor möchte ich aber noch den Sponsor für diesen Blogpost und dem aufregenden Projekt um Analysen von DynamoDB Tabellen mittels QuickSight durchzuführen. Vielen Dank an TAKE2 dass ich in eurem agilen und motiviertem Team sein darf um so aufregende AWS CDK Aufgaben wie diese arbeiten zu können.

AWS DynamoDB

AWS DynamoDB ist eine gemanagte NoSQL Datenbank mit sehr guter Performance und Skalierung. Durch das managen der Datenbank von AWS entfällen aufwendige Administrative Aufgaben wie Installation oder Wartung. DynamoDB besitzt auch Backup Features wie on demand oder Point-in-Time Recovery.

In DynamoDB müssen die eingefügten Daten keinem festdefiniertem Schema folgen wie in etwa bei relationen Datenbanken. Das ist super flexibel und sehr nützlich, kann aber auch zu Problemen führen wie Unübersichtlichkeit oder Inkonsistenzen bei den Spaltennamen. Von daher empfehle ich nur bestimmte Spalten in der Tabelle zuzulassen. Das kann z.B. erreicht werden durch eine Schemavalidierung im Api Gateway oder der Verwendung eines GraphQL Schema in AWS AppSync.

AWS Athena

AWS Athena erlaubt das Querien von Daten. Zum Zugriff auf die Daten benutzt der Entwickler Standard-SQL als Query Language. Als Datenquelle können verschiedene AWS Services dienen wie S3, RedShift und seit neuestem auch DynamoDB. Der Vorteil an Athena ist, dass es Serverless ist und man sich somit direkt auf die Datenabfrage konzentrieren kann.

Um DynamoDB als Datenquelle für Athena zu setzen braucht man einen Lambda Connector. Der Connector schreibt dabei alle Items aus der Tabelle in einen S3 Bucket. Zum Glück bietet AWS eine SAM Lambda bereits an die den Job übernimmt. Diese Lambda heißt AthenaDynamoDBConnector

AWS QuickSight

AWS QuickSight ist ein Service zum Erstellen und Analysieren von Visualisierungen der Kundendaten. Die Kundendaten können dabei in AWS Services liegen wie S3, RedShift oder wie in unserem Fall in DynamoDB.

QuickSight kann zum jetzigen Zeitpunkt noch nicht direkt Daten von DynamoDB einlesen und es muss ein kleiner Zwischenschritt gemacht werden. Die DynamoDB Daten müssen in einem S3 Bucket z.B. als JSON exportiert werden. Dann kann QuickSight die sich im S3 befindenden Daten einlesen.

Um die Daten in den S3 Bucket zu schieben eignet sich der Ansatz eine AthenaDynamoDBConnector Lambda zu verwenden. Näheres darüber findest du im nächsten Abschnitt.

Quicksight bietet viele coole Funktionen zum Verarbeiten und Visualisieren von Daten die zum Beispiel aus DynamoDB kommen können. Auch lassen sich diese mit CDK als Code definieren.

Ich arbeite daran die erstellen QuickSight Analysen via CDK in Templates zu speichern um sie so cross account mäßig zugreifbar zu machen. Das ermöglicht dann Analysen auf einem dev account zu Erstellen und Testen und diese dann in den prod Account automatisiert zu via CDK zu deployn. Wie genau das alles von statten gehen soll erkläre im nächsten Blogpost.

AWS CDK

Mit AWS CDK habe ich einen hohen Automatisierungsgrad bei der Erstellung und Verwaltung des DynamoDB QuickSight Deployments erreicht. Dabei werden die benötigten AWS Ressourcen und dessen Konfigurationen schön als Code definiert und dann einfach ausgeführt. Und hier seht ihr ein Komponentendiagram:

Den AWS CDK Code für das DynamoDB Athena Deployment findet ihr in meinem Repo. Unbedingt dort auch die Readme ansehen da diese viele wichtige Anweisungen und Informationen enthält. Leider konnte ich nicht alles in AWS CDK verfassen da z.B. die SAM Lambda AthenaDynamoDBConnector lässt sich nicht oder nur schwierig in AWS CDK übersetzen und sie muss bis jetzt noch manuel deployed werden.

Ausblick

Es wäre super cool wenn der AthenaDynamoDBConnector auch in AWS CDK erhältlich wäre. Auch scheinen mir die QuickSight Cloudformation Ressourcen noch sehr unausgereift da manches noch garnicht unterstütz wird wie z.B. das DataSet. Ein GitHub Issue wurde bereits schon erstellt.

Wie schon in der QuickSight Sektion erwähnt, arbeite ich daran die Analysen von QuickSight mittel CDK zu persistieren und dann Cross Account mäßig verfügbar zu machen. Meine Findings werde ich dann im nächsten Blogpost zeigen.

Zusammenfassung

AWS QuickSight ist ein spannendes Analysetool zum Auswerten von Daten in einer DynamoDB Tabelle. Daten sind ja das neue Gold und von daher ist es extrem wichtig Daten aus einer DynamoDB Tabelle verarbeiten zu können. Wenn dabei noch vertraute mechanismen wie SQL Queries, Aggregat Funktionen benutzt werden können ist das super. Auch bietet QuickSight coole graphische Lösungen zum Anzeigen von Analysen und Dashboards. Ich bin schon sehr darauf gespannt mehr damit zu arbeiten.

Vielen Dank auch an Jared Donboch für den extrem hilfreichen BlogPost Using Athena data connectors to visualize DynamoDB data with AWS QuickSight . Basierend darauf konnte ich so viel wie möglich automatisieren indem ich es in einen AWS CDK Stack verfasst habe.

Nochmal vielen Dank an TAKE2 für das Sponsoring dieses Blogposts.

Werde ein Patreon!

Ein sehr coole DevOps AWS CDK Todolist

Tue, 23 Feb 2021 00:00:00 GMT

Hi.

Schon lange träume ich von dem Bau einer Platform mit einer tollen DevOps Experience. Ich möchte so coole sachen darin haben wie:

Infrastructure as Code (IAC)
CI / CD (Continuous Integration / Continuous Deployment)
Ein Staging z.B. dev, qa, prod
automatisierte Tests
das alles mit so wenig TypeScript Code wie nötig

Ich habe das nun gefunden mit der Verwendung der folgenden Technologien. AWS CDK zum managen der Infrastructure as Code. AWS AppSync als Implementierung von GraphQL, AWS Amplify für die Frontend Website und das managen von Usern. Weiterhin AWS CodePipeline erweitert mit meiner library AWS CDK Staging Pipeline.

Anhand meins Todolisten Deployments will ich euch zeigen wie viel Power in meinem Deployment steckt. Aber zunächst werde ich erklären was AWS CDK ist.

AWS CDK

Backend AWS AppSync, AWS DynamoDB and AWS Cognito

Der Code für das Backend ist in GitHub aws-cdk-todolist.

AWS AppSync ist eine GraphQL Api Implementierung. GraphQL ist eine interessante neue API Technologie. Da GraphQL noch neu für mich ist, wage ich keine großen Aussagen jetzt und hier. Was mir aber sehr gut gefällt ist, dass sich die Anbindung an Datenbanken wie AWS DynamoDB sehr nativ anfühlt. Mich haben schon immer die nötigen Lambda Implementierungen bei AWS Api Gateway und das Anlegen neuer Endpoints genervt. Das alles scheint nicht mehr nötig mit der Verwendung von AWS AppSync.

Für das Speichern von Items in der Todoliste verwende ich DynamoDB. Jedes Item bekommt dabei seine eigene ID, welche von dem AppSync Resolver zugewiesen wird. Darüber hinaus besitzt jedes Item einen Body und einen Username.

AWS Cognito ist ein Service für die Userverwaltung und Userauthentifikation über Oauth. Dieser Service macht es sehr einfach einen professionellen und skalierbaren Identity Service mit allem drum und dran zu implementieren.

Eine Deployment Pipeline deployed all diese Ressourcen in AWS Accounts. Die AWS Ressourcen für das Backend und die Deployment Pipeline selbst, werden mit AWS CDK als Infrastructure as Code bereitgestellt.

Frontend React, AWS Amplify, S3 Static Website

Der Code für das Frontend ist in GitHub aws-cdk-todolist-ui.

Der Frontend Stack besteht aus einem React Build mit AWS Amplify UI Erweiterungen wie @aws-amplify/auth @aws-amplify/ui-components @aws-amplify/ui-react. Diese Erweiterungen helfen massiv bei der Userverwaltung. So ist es z.B. einfach möglich über den Loginscreen neue Benutzer anzulegen oder das Passwort zu ändern, falls man es vergessen haben sollte.

Der React Build wird per Deployment Pipeline (siehe nächsten Abschnitt) in einen S3 Bucket kopiert. Der S3 Bucket ist als Static Website konfiguriert. Alle benötigten AWS Ressourcen für den S3 Bucket und der Deployment Pipeline werden ebenfalls mit AWS CDK bereitgestellt.

DevOps Pipelines

Jegliche Deployments heutzutage sollten eine vernünftige Deployment Pipeline besitzen die so coole Features hat wie automatisierte Builds, Deploys, Tests, Linting, Versioning und so weiter. Damit erreicht man einen ungleiblich gute Geschwindigkeit bei der Entwicklung und die Arbeit macht auch viel mehr Spaß weil lästige manuelle Tätigkeiten wie das Deployen zur Produktion oder manuelles Testen, fallen einfach weg.

Mein Todolisten Deployment hat eine solche Deployment Pipeline. Jeweils das Frontend und Backend besitzen ihre eigene Pipeline welche auf AWS CodePipeline und natürlich AWS CDK basiert. Für die Pipeline habe ich ein eigens AWS CDK Custom Construct entwickelt und auch schon darüber in einem vorherigen Post berichtet welchen ihr hier sehen könnt.

Ausblick

Der AppSync Transformer sieht sehr interessant aus. Mit ihm ist es möglich die AWS Amplify GraphQL Transformer einfacher zu nutzen. Somit können viele Zeilen Code gespart werden indem durch so coole labels wie @model @connection ein erweitertes GraphQL Schema generiert wird.

Ich bin gerade auch dabei ein Udemy Kurs über das hier erwähnte Todolist Deployment zu verfassen. Falls ihr einen Gutschein dafür haben wollt, sagt mir bescheid und sobald es fertig ist, bekommt ihr einen.

Zusammenfassung

GraphQL is mega spannend. Ich glaube es ist eine zukunftsweisende API Technologie und ich kann es kaum abwarten mehr im professionellen Umfeld damit zu arbeiten.

Werde ein Patreon!

Scrum und GitHub

Thu, 11 Feb 2021 00:00:00 GMT

Hi.

Unser Entwicklerteam hat ein spannendes Experiment ausprobiert. Wir arbeiten im Scrum und organisieren uns hauptsächlich mit GitHub. In diesem Artikel beschreibe ich wie wir GitHub dafür benutzen.

Auch wenn ich schon seit ungefähr 5 Jahren Erfahrung mit Scrum habe als Entwickler gebe ich hier einen kleinen Disclaimer. Ich habe nie eine Scrum Zertifizierung gemacht. Ich werde also wahrscheinlich Begriffe falsch wiedergeben oder einordnen. Ich würde dann gerne dich bitte mich zu korrigieren.

Auch arbeitet unser Team erst seit gut einem Monat zusammen im Scrum. Das Team ist mit 4 Leuten 3 Fullstack Entwicklern und 1 Product Owner relativ klein. Trotzdem denke ich, dass dieser Beitrag euch dabei helfen kann euren Arbeitsprozess in eurem Team zu verbessern.

Im nächsten Abschnitt erzähle ich mehr über GitHub und wie wir es nutzen um uns in Scrum zu organisieren.

GitHub und Scrum

Mein GitHub Account is aktiv seit 2016. GitHub ist bei weitem meine liebste Git Provider Umgebung. Privat nutze ich GitHub sehr viel. Ich bin sehr froh, dass ich GitHub nun auch für die Arbeit verwenden kann. Unsere Hauptmotivation GitHub zur Organisation zu verwenden sind die geringen Kosten und die Tatsache, dass sich viele Entwickler bereits gut mit GitHub auskennen.

Im nächsten Abschnitt erkläre ich wie wir einige GitHub Funktionen zur bewältigung unserer Scrum Arbeitsweise verwenden.

GitHub Issues als Tickets

Die Issues bei GitHub lassen sich perfekt nutzen als Tickets für Scrum. Über Labels ist es sogar möglich den Tickets eine Size zu geben. Sizen meint in dem Kontext, dass eine Zahl für die Komplexität des Tickets von den Entwicklern vergeben wird. Üblicherweise sind das die Fibonacci Zahlen 1 3 5 8 13 .

Auch können über Labels die Tickets ihrer jeweiligen Komponente zugewiesen werden. Komponente meint dabei eine Art Unterkategorie des Projektes wie z.B. "component: api" oder "component: app" .

GitHub Projects als Scrum Boards

GitHub Projects eigenen sich hervorragend für die Scrum Boards. Wir haben 3 Projects für 3 Boards. Jedes Board repräsentiert dabei seinen eigenen Zeitbereich und Abstraktionsgrad.

Aktuelle Sprint Board

Das wichtigste Board ist dabei natürlich das "Aktuelle Sprint Board" (siehe mittig im Titelbild). Wir machen einen zweiwöchigen Sprint und mit dem "Aktuelle Sprint Board" reflektieren wir die Arbeit bzw. die Tickets an denen wir aktuelle arbeiten und arbeiten wollen. Es besitzt drei Spalten ToDo, In Progress und Done.

Tickets aus dem Backlog Scrum Board, welches im nächsten Abschnitt vorgestellt wird, landen dann hier zuerst in der ToDo Spalte. Zu diesem Zeitpunkt sollten die Tickets verständlich und gesized sein. Am Ende jedes Sprints wird die Done Spalte geleert und die ToDo Spalte wieder aufgefüllt.

Backlog Board

Das Backlog Board (siehe unten im Titelbild) ist Gedacht für Aufgaben in dem Zeitraum von 2 - 6 Wochen und umfasst alle Tickets die noch nicht im Aktuellen Sprint Board sind. Hier werden diese gesammelt und Stück für Stück verfeinert. Dafür existieren die vier Spalten von links nach rechts Backlog, Ready for Sizing, Ready for Sprint und Next Sprint.

In jeder Spalte wird also das Ticket verfeinert z.B. wenn das Ticket von Backlog in Ready for Sizing gelangt muss es für alle Entwickler soweit verständlich sein, dass es gesized werden kann.

Wenn das Ticket in die Ready for Spring Spalte kommt, ist es nun soweit fertig um potentiell in den nächsten Sprint zu gelangen. In der Spalte Next Sprint einigen wir uns darauf welche Tickets wir im nächsten Sprint abfertigen wollen.

Zukunft Board

Das Zukunft Board ist für Ideen / Aufgaben die noch relativ unklar sind und in einem Zeitabstand von ca 6 Wochen bis hin zu einem Jahr sind. Bisher nutzen wir dieses Board noch kaum und haben Ideen in einem separiertem Miro Board.

Zusammenfassung

Ich bin immer noch total geflashed wie gut es mit den Tools auf GitHub es klappt in Scrum zu arbeiten. Die UI von GitHub wirkt sehr ausgeklügelt und erlaubt eine tolle Scrum Experience. Probiert es einfach mal aus :) !

Werde ein Patreon!

Docker Hub release mit Projen

Mon, 01 Feb 2021 00:00:00 GMT

Hi Projen Freunde.

Projen wird immer beliebter. Ich selber nutze es schon ca seit einem halbem Jahr und bin immer noch total begeistert. Kürzlich habe ich es sogar geschafft einen Docker Image Release Cycle nach Docker Hub damit zu bauen. Mein Docker InfluxDB Repo pusht nun automatisch bei jedem release eine Image nach Docker Hub.

Was genau Projen ist und wie ich damit mein Projekt und Image Release Cycle manage, erkläre ich den nächsten Abschnitten.

Projen

Projen erlaubt eine ausgeklügelte Verwaltung von Projektkonfiguration durch Code. Mit nur wenigen Zeilen TypeScript kann ein gesamtes Repository konfiguriert werden. Hierfür ein Beispiel:

const { JsiiProject } = require('projen');

const project = new JsiiProject({
  name: 'alps-unified-ts',
  authorAddress: 'damadden88@googlemail.com',
  authorName: 'Martin Mueller',
});

project.synth();

Diese wenigen Zeilen erzeugen alle GitHub Projektfiles die das Herz begehrt. Darunter die package.json, .gitignore, tsconfig.json und noch viele viele mehr.

Wirklich richtig cool ist das Projen auch mit GitHub Workflows kommt die z.B. neue Versionen publishen können nach Registries wie NPM oder PYPI. Das habe ich in einem anderen Projekt gemacht und hier beschrieben. Für meinen Docker Image Release nach Docker Hub habe ich den Projen GitHub Release Workflow erweitert. Wie genau seht ihr im nächsten Abschnitt.

Projen Setup

Nachfolgend seht ihr meine aktuelles Projen Setup welches in dem File .projenrc.js hinterlegt ist.

const { NodeProject, ProjectType, DockerCompose } = require('projen');

const project = new NodeProject({
  authorAddress: 'damadden88@googlemail.de',
  authorName: 'Martin Mueller',
  name: 'influxdb-s3-backup',
  releaseBranches: 'main',
  projectType: ProjectType.LIB,
});

project.releaseWorkflow.addJobs({
  publish_docker_hub: {
    needs: 'build',
    'runs-on': 'ubuntu-latest',
    env: {
      CI: "true",
    },
    'steps': [
      {
        name: 'Check out the repo',
        uses: 'actions/checkout@v2',
      },
      {
        name: 'Set up QEMU',
        uses: 'docker/setup-qemu-action@v1',
      },
      {
        name: 'Set up Docker Buildx',
        uses: 'docker/setup-buildx-action@v1',
      },
      {
        name: 'Login to DockerHub',
        uses: 'docker/login-action@v1',
        with:{
          username: '${{ secrets.DOCKER_USERNAME }}',
          password: '${{ secrets.DOCKER_PASSWORD }}',
        }
      },
      {
        name: 'get_version',
        id: 'get_version',
        run: [
          'DVERSION=$(jq .version version.json -r)',
          'echo "::set-output name=dversion::$DVERSION"',
          ].join('\n'),
      },
      {
        name: 'Build and push',
        uses: 'docker/build-push-action@v2',
        with: {
          context: '.',
          file: './Dockerfile',
          platforms: 'linux/amd64,linux/arm64',
          push: true,
          tags: 'damadden88/influxdb-s3-backup:${{ steps.get_version.outputs.dversion }},damadden88/influxdb-s3-backup:latest'
        }
      },
    ],
  }
})

project.synth();

NodeProject

Meine Projen Projekt ist vom Typen NodeProject:

const { NodeProject, ProjectType, DockerCompose } = require('projen');

const project = new NodeProject({
  authorAddress: 'damadden88@googlemail.de',
  authorName: 'Martin Mueller',
  name: 'influxdb-s3-backup',
  releaseBranches: 'main',
  projectType: ProjectType.LIB,
});

Das bedeuted, dass es ein typisches node deployment ist, welches nodejs als environment benötigt und zusätzliches Libaries sowie Projektinformationen in der package.json enthält. Dazu kommt noch dass Node Projekte eine Changelog.md, welches alle Änderungen seit dem letzten Release auflisten können, kommt.

Außerdem besitzt es einen GitHub Release Workflow welches mittels GitHub Actions automatisch GitHub releases macht bei commits und dabei die semver befolgt. Ich habe nun eben genau diesen release Workflow erweitert um auch Docker Images nach Docker Hub pushen zu können in der gleichen Tagversion wie sie auch während des GitHub Releases gemacht wird. Um den Release Workflow zu erweitern habe ich das releaseWorkflow Objekt folgendermaßen erweitert:

project.releaseWorkflow.addJobs({
  publish_docker_hub: {
    needs: 'build',
    'runs-on': 'ubuntu-latest',
    env: {
      CI: "true",
    },
    'steps': [
      {
        name: 'Check out the repo',
        uses: 'actions/checkout@v2',
      },
      {
        name: 'Set up QEMU',
        uses: 'docker/setup-qemu-action@v1',
      },
      {
        name: 'Set up Docker Buildx',
        uses: 'docker/setup-buildx-action@v1',
      },
      {
        name: 'Login to DockerHub',
        uses: 'docker/login-action@v1',
        with:{
          username: '${{ secrets.DOCKER_USERNAME }}',
          password: '${{ secrets.DOCKER_PASSWORD }}',
        }
      },
      {
        name: 'get_version',
        id: 'get_version',
        run: [
          'DVERSION=$(jq .version version.json -r)',
          'echo "::set-output name=dversion::$DVERSION"',
          ].join('\n'),
      },
      {
        name: 'Build and push',
        uses: 'docker/build-push-action@v2',
        with: {
          context: '.',
          file: './Dockerfile',
          platforms: 'linux/amd64,linux/arm64',
          push: true,
          tags: 'damadden88/influxdb-s3-backup:${{ steps.get_version.outputs.dversion }},damadden88/influxdb-s3-backup:latest'
        }
      },
    ],
  }
})

Dieser GitHub workflow released also meine Image nach Docker Hub mit der gleichen Tagversion und latest:

tags: 'damadden88/influxdb-s3-backup:${{ steps.get_version.outputs.dversion }},damadden88/influxdb-s3-backup:latest'

Neue releases nach GitHub und Docker Hub werden so nun komplett von Projen gemanaged und bei commits nach master automatisch durchgeführt. Das ist extrem cool und spart mir viel Zeit :).

Zusammenfassung

Ich habe das Projen Framework lieben gelernt, da es eine tolle Abstraktion und Vorgabe für ein Setup von Projekten ist. Ich lege dir ans Herz Projen mal einen Versuch zu geben und sehr bald wirst du die Schönheit dieses Frameworks selber erleben.

Werde ein Patreon!

IOT - Den Gaszähler digital auslesen

Mon, 25 Jan 2021 00:00:00 GMT

Bevor es losgeht. Im Beitrag sind Affiliates bezüglich der IOT Geräte

Hi.

Vor einigen Wochen habe ich bereits hier mein neues IOT Deployment vorgestellt. Es besteht aus einem Raspberry 4 DE US UK, Zigbee Türsensor DE UK und dem Zigbee Empfäger DE UK. Die Software die auf dem Raspberry 4 läuft ist Docker Compose. Mit dem Docker Compose Deployment kommt für das IOT Management NodeRED zum Einsatz. Für die Anzeige in Diagrammen verwende ich Grafana.

Zuerst möchte ich erklären wie ich meinen analogen Gaszähler digital auslesbar gemacht habe und dann wie ich NodeRED und Grafana nutze um die erhaltenen Daten zu transformieren und in Diagramme (siehe Titelbild) anzeigbar gemacht habe.

Gaszähler Erweiterung

Wie im Bild oben rechts zu sehen habe ich einen analogen Gaszähler BK-G4. Wie also daraus einen digitalen Gaszähler der sogar Werte über Zeit speichern kann? Nun der Zähler sendet alle 0,01 qm verbrauchtem Gas einen magnetischen Impuls. Auf dem Bild ist das auch als 1 imp 0,01 qm zu sehen. Wenn also auch du einen Gaszähler mit magnetischen Impuls hast, sollte die Anleitung hier auch bei dir funktionieren.

Den magnetischen Impuls messe ich einfach mit dem kabellosen Zigbee Türsensor (auch oben rechts in Bild) und sende ihn an einen Zigbee Empfäger der mit einem Raspberry 4 US verbunden ist und zeichne die Werte auf.

Ganz so einfach ist die Aufzeichnung nicht da das Signal noch transformiert werden muss. Die Transformation des Signals wird mit NodeRED gemacht.

NodeRED

NodeRED ist ein Open Source Programmiertool zum verbinden von IOT Geräten miteinander, APIs und online Services. Es bietet einen Webbrowser basierten Editor und unterstützt JavaScript als Programmiersprache. Die Runtime selbst ist Nodejs.

Sehr cool finde ich auch, dass NodeRED eine Anbindung nach GitHub unterstützt und der aktuelle Stand des NodeRED Projektes mittels Git Protokoll versioniert abgespeichert werden kann. NodeRED bietet viele weitere tolle Funktionen, die ihr unbedingt erforschen solltet. Genauer möchte ich aber hier nur auf den NodeRED Flow eingehen.

NodeRED Flow

Ein NodeRED Projekt kann mehrere Flows besitzen. Ein NodeRED Flow beschreibt die Interaktion von den IOT Geräten mit anderen Geräten, APIs oder online Services. Meinen Flow seht ihr oben links im Bild. Der Flow ließt sich am besten von links nach Rechts. Ganz links sind zwei Eingänge. Der untere Eingang ist von einer Open Weather API mit der ich die aktuelle Außentemperatur erfasse (auch in dem "Gas Delta" Diagram in gelb zu sehen).

Der obere Eingang ist von meinem Zigbee Empfänger der ja das Signal vom Zigbee Türsensor bekommt. Der Zigbee Türsensor und Empfänger arbeiten mit dem sogenannten MQTT Protokoll. MQTT is ein datensparsames, publish und subscribe Protokoll vorranging für die Kommunikation zwischen IOT Geräten.

Ganz rechts in dem Flow sind die Ausgänge zu sehen (etwas abgeschnitten). Der blaue Ausgang ist ein NodeRED UI Element. NodeRED bietet auch die möglichkeit UI Elemente mit z.B. Sensorwerten zu rendern. Diese ist dann erreichbar z.B. unter https://localhost:1880/ui . Die braunen Ausgänge senden Daten zu einer InfluxDB die dann mit Grafana angezeigt werden.

InfluxDB & Grafana

InfluxDB ist eine Open Source time series Datenbank . Es ist in GO geschrieben und optimiert für schnellen, hochverfügbaren Speicher und Abfrage der gespeicherten Daten. Es eignet sich hervorragend für IOT Daten.

Bei meinem Flow speicher ich den aktuellen Gaswert und die Temperatur in InfluxDB. InfluxDB berechnet dann selbstständig den Timestamp. Dann kann ich einfach mit dem graphischen Analysetool Grafana mir die Daten aus dem InfluxDB holen und flexibel anzeigen lassen (siehe Diagramme in Titelbild).

Unten rechts sehe ich den aktuellen und gestrigen Tagesverbrauch. Man sieht es in dem Bild schlecht da nur gelb angezeigt wird aber ich habe unterschiedliche Farben für Farberreiche eingestellt. Von 0 - 7 qm ist grün. Dann von 7 - 14 qm is gelb und alles über 14 qm ist rot. Für eine dreiköpfige Familie ist der durchschnittliche Tagesverbrauch in etwa 7 qm, was in etwa maximal um den Faktor 2 schwankt im Sommer und Winter. Extrem cool ^^.

Ganz unten links wird der Gesamtverbrauch des Gases angezeigt und darüber wie sich der Verbrauch über den Tag relativ ändert. Eine ziemlich coole Funktion von Grafana ist, dass der Zeitbereich komfortabel geändert werden kann. Als default habe ich "Heute" eingestellt welches mir alle Werte von 0 bis jetzt wiedergibt. Es gibt aber noch andere Zeitbereiche wie Gestern, Vorgestern, 12 std. usw. Auch lassen sich Start- und Endzeit direkt eingeben. Extrem cool!

InfluxDB AWS S3 Backup

Mittlerweile habe ich sogar eine Datenbackup Funktion eingebaut. Damit komprimiere ich meine InfluxDB Daten und speicher sie in AWS S3. AWS S3 ist ein günstiger langzeit Cloud Storage. Ich bevorzuge diese Methode da ich mir so keinen externen Speicher kaufen muss und die physische Verwaltung des Speichers AWS überlassen kann.

Für das Backup habe ich eine eigene Docker Image gebaut und release. Das war nötig da es noch keine Docker Image auf Docker Hub gab welche InfluxDB + AWS CLI + arm64 unterstützten. Diese konsumiere ich nun in meinem rasp4 repo im docker-compose.yaml. Das Backup wird per default jeden morgen um 1 Uhr durchgeführt.

Ausblick

Als nächstes möchte ich mich gerne an meinen Stromzähler machen um auch diesen digital auslesen zu können.

Ich will auch mehr IOT Geräte nach NodeRED migrieren da ich zurzeit noch einiges in der Cloud mit der App "Smart Life" am laufen habe. Die Funktionalität dort ist aber sehr beschränkt. Z.B. kann ich bereits meinen Heizboiler an- und ausschalten und das würde ich gerne mit NodeRED steuern können.

Zusammenfassung

Wenn euch noch coole Idee einfallen wie ich meine Sensordaten transformieren oder visualisieren um nützliche Informationen zu generieren, lasst es mich wissen.

Werde ein Patreon!

Langzeit Investieren mit Trading212

Sun, 17 Jan 2021 00:00:00 GMT

Bevor es los geht! In den Trading212 Link ist ein Affiliate bei dem du und ich jeweils eine Aktie geschenkt bekommen

Hi,

Seit November 2020 beschäftige ich mich mit dem Thema Aktien und bin ein aktiver Nutzer der Trading App Trading212. Der Hauptgrund dafür ist, dass ich ein Konto bei der Bank nicht als ideale Form der Aufbewahrung sehe da es dort an Wert verliert.

Die genaue Erklärung warum ich in Aktien investiere und wie meine Strategie aussieht, seht ihr in den nächsten Abschnitten. Nur soviel sei schon vorweg gesagt, es war ein super Entscheidung und ich habe schon nach wenigen Wochen einen höheren Wert geschaffen, als es bei einer Bank in einem Jahr möglich wäre.

Warum?

Banken bieten heutzutage nur noch einen sehr geringen Zinssatz bis maximal 2% pro Jahr an. Das kann kaum bis garnicht mit der Inflationsrate des Geldes mithalten. Anders gesagt, man verliert Kaufkraft. Um das Wort Kaufkraft besser zu verstehen, gebe ich ein kleines Beispiel. Wenn du dir 2020 noch für 100 Brötchen von 100€ leisten konntest, sind es 2021 eventuell nur noch 90 Brötchen die du dir mit 100€ kaufen kannst.

Belässt man also sein Geld auf der Bank verliert man an Kaufkraft. Es sollten also andere Möglichkeiten in Betracht gezogen werden, wenn es um die Anlage von Geld geht. Eine Investition in Aktien mit möglichst niedrigem Verlustrisiko hört sich von daher ja erstmal sehr verlockend an. An dieser Stelle sei aber gesagt, dass jede Investition ein Risiko birgt und das gilt natürlich auch für Aktien. Selbst Banken können Bankrott gehen auf Kosten der Anleger, siehe Griechenland.

Auch sehr spannend finde ich den Gedanken mit dem Kauf von Aktien, bestimmte Firmen zu unterstützen. Denn für Firmen ist der Aktienmarkt eine gute Gelegenheit Zinsfrei an Kapital zum investieren zu gelangen. Alternativ müsste die Firma ein zinsbelasteten Kredit bei einer Bank beantragen. Bis zu einem gewissen Grad kann ich dann selbst in Firmen investieren die ich toll finde. Toll finde ich Firmen in dem Thematiken:

Green Energy: Firmen die den Ausbau und Weiterenwicklung von erneuerbaren Energien wie Solaranlagen oder Windräder voranbringen.
Quality Food: Ich bin ein überzeugter Anhänger von hochqualitativer Nahrung und finde die Themen toll wie Bio, Regional, Fair Trade.
US Tech Firmen: Als Software Entwickler weiß ich natürlich viel über Tech Firmen und weiß wie nützlich und wertvoll diese für die Menschheit sind.
Non-US Tech Firmen: Da ich ja selber aus Deutschland komme, möchte ich spezifisch gerne Tech Unternehmen im EU Raum unterstützen.

Und ich kann mich aktiv gegen Firmen mit gewissen Thematiken entscheiden wie fossile Brennstoffe oder Alkohol als Genussmittel. Das waren jetzt meine persönlich Thematiken und die können bei dir ja ganz anders aussehen, was auch ok ist.

Im nächsten Abschnitt erkläre ich, wie ich mit Trading212 in Aktien investiere.

Trading212

Trading212 ist eine Internetplattform zum investieren in Aktien. Trading212 wirbt damit, keine Kommission dafür zu verlangen, was die Plattform sehr attraktiv macht. Benutzt man einen Broker*innen verlangen diese üblicherweise eine Kommission. Trading212 besitzen auch jeweils eine ios und Android App sowie natürlich eine Weboberfläche.

Ich selber nutze die Trading212 ios App sowie die Weboberfläche und bin sehr zufrieden. Damit ist es sehr einfach in Aktien zu investieren und dessen Verlauf langfristig zu verfolgen. Auch das Ein- und Auszahlen von meinem Bankkonto in meinen Trading212 Account geht sehr einfach und geht schnell.

Letztes Jahr (2020) wurde ein tolles Feature mit Namen Pie released. Damit ist es möglich sogenannte Pies anzulegen in dem man bis zu 50 Aktien anzulegen. Jede Aktie bekommt kann dan einem gewissen Prozentwert zugewiesen werden. In der Summe ergeben alle Prozentwerte dann natürlich wieder 100%. Wenn du wissen möchtest was die Pies noch alles können einfach hier klicken.

Ich finde die Pies toll weil sie bei meiner low risk Strategie helfen und mir einen super Überblick verschaffen wie sich mein breites Portfolio entwickelt. Auch finde ich die Funktion AutoInvest bei der ich monatlich einen gewissen Betrag in den Pie einzahlen kann.

Recht kürzlich ist auch das "Share Pie" Feature dazugekommen. Damit kann man die Erstellten Pies preisgeben und andere können sehen wie mein Pie aussieht, also in welche Aktien und wieviel Prozent ich investiert habe. Konkrete Geldbeträge werden nicht preisgegeben. Und das hier ist mein Pie mit einer diversen Wahl von Aktien und Firmen die ich unterstützen möchte.

Auch wenn das Angebot der verfügbaren Aktien, in die investieren werden kann bei Trading212, sehr groß ist, kam es das eine oder andere mal vor, dass meine gewünschte Aktie nicht / noch nicht verfügbar war. In so einem Fall kann man aber in dem Trading212 Community Forum erbitten die jeweilige Aktie mit ins Portofolio von Trading212 aufzunehmen.

Die Trading212 Forum Community ist der perfekte Ort wenn man mehr über Trading mit Trading212 und generell lernen möchte. Die Community dort hat mich bei meiner Investmentstrategie stark unterstützt wofür ich sehr dankbar bin. Seit kurzem hat Trading212 auch einen Discord Channel.

Auch toll ist, dass Trading212 kostenlose Webinare zum Thema Trading auf ihrer Platform (also auch Apps) sowie auf YouTube anbietet. Im nächsten Abschnitt erkläre ich meine Investmentstrategie.

Meine Strategie

Ich möchte langzeit investieren (mehr als 10 Jahre) in viele verschiedene Sektoren wie IT, Materialien, Energie usw. Welche Sektoren es gibt und was diese bedeuten findet ihr hier. Das Geld in viele verschiedene Sektoren zu investieren, anstatt in einen einzigen spezifischen Sektor, verringert das Verlustrisiko da diese Sektoren unabhängiger voneinander sind als es ein Sektor für sich wäre. Wenn man z.B. die Coronakriese betrachtet sieht man, dass der IT Sektor nicht so stark gelitten hat wie z.B. Real Estate.

Moderne Internet Plattformen wie Trading212 erlauben es auf den Mittelmann wie dem Broker*innen, der ja in der Regel eine Kommission verlangt, zu verzichten da gut gestaltete Plattformen es sehr einfach machen sich selber um sein Portfolio zu kümmern.

Desweiteren möchte ich einen Teil meines monatlichen Einkommens automatisch mit AutoInvest in meinen Pie einzahlen. Somit baue ich uns über die Jahre ein gute Rücklage auf ohne viel Aufwand damit haben zu müssen. Ich starte mit erstmal 100€ die jeden Monat automatisch überwiesen werden und erhöhe diesen Betrag ggf. in Zukunft.

Da ich noch recht neu im Thema Aktien bin, werde ich ca. 20-30% des Portofolios aus ETFs zusammenbauen. Und wenn meine Erfahrung über die Zeit steigt, die ETFs gegen normale Aktien austauschen. ETFs werden von professionellen Tradern verwaltet und diese Verwaltung kostet natürlich etwas. Mein langfristiges Ziel soll es sein komplett auf fremde ETFs zu verzichten, da mir Trading212 mit den Pies quasi erlaubt mir meine eigenen ETFs zu verwalten und ich somit die Kosten sparen kann.

Ausblick

Ich bin schon sehr zufrieden mit meiner aktuellen Auswahl der Aktien und werde wohl nur noch minimal nachbessern. Dann würde ich Aktien und ETFs die nicht so gut performen gegen vielversprechendere austauschen. Mal schauen.

Meine Investitionen konzentrieren sich bisher hauptsächlich auf den Amerikanischen, Deutschen und Britischen Aktienmarkt und ich sollte mir Gedanken darüber machen mein Portfolio noch diverser zu machen und in andere Aktienmärkte zu investieren und wie genau ich in diese Aufteile.

Sehr gespannt warte ich auf das Feature "Pies in Pie" das würde die Verwaltung meines Portfolios noch weiter vereinfachen. Zurzeit brauche ich immer noch eine Excel Tabelle um die übersicht zu behalten in wieviel ich in welche Sektoren investiert habe. Mit Pies in Pie würde das direkt ablesbar sein.

Auch soll bald ein Exportfeature kommen, bei dem ich die Investitionen z.B. in eine Exceltabelle exportieren kann. Damit kann ich dann andere Visualisierungtools füttern um interessante Analysen zu tätigen. Konkrete Ideen habe ich aber noch nicht.

Zusammenfassung

Mit Trading212 macht Investieren in Aktien Spaß. Es gibt mir alle nötigen Tools um selber mein Aktienportfolio verwalten zu können. Das ist eine tolle Alternative zu Konten zum verwahren von Geld und darüber hinaus lernt man viele nützliche Sachen über den Aktienmarkt. Seine finanzielle Intelligenz auszubauen halte ich für wichtig und richtig. Trading212 kann auch dein Einstieg sein genau das zu tun!

Ich liebe es an Content Management Open Source Projekte zu arbeiten. Vieles kannst du bereits frei nutzen auf https://github.com/mmuller88 . Wenn du meine dortige Arbeit sowie meine Blog Posts toll findest, denke doch bitte darüber nach, mich zu unterstützen und ein Patreon zu werden:

Werde ein Patreon!

RC3 Bericht

Tue, 05 Jan 2021 00:00:00 GMT

Hi Freunde des Chaos,

Der 37te Kongress hat vom 27. - 30. Dezember 2020 stattgefunden und aufgrund der Pandemie war alles remote. Somit bekam der Chaos Kongress den Namen RC3. Das war meine aller erste Chaos Computer Club Veranstaltung die ich besucht habe. Wie toll die Tage waren und was ich erlebt habe, beschreibe ich in den nächsten Abschnitten.

Tag 1

Besuchte Streams:

12:20 #rc Eröffnung
13:00 Die Geschichte der Corona-Warn-App
14:00 Flutter - Introduction
14:30 Wie gründe ich eine Genossenschaft?
16:00 Rage Against The Machine Learning
19:00 What the cyberoptimists got wrong-and what to do about it

Wir schreiben den 27ten Dezember 2020. Um 12:20 geht der RC3 los. Das Intro war sehr cool. Es gab eine Zusammenfassung über das Jahr 2020 und neben Corona sind viele interessante und leider auch traurige Sachen passiert auf die aufmerksam gemacht wurde. Es wurde auch gezeigt bzw. gut klar gemacht wieviel Aufwand und wieviel Leute eigentlich daran beteiligt sind den RC3 zu ermöglichen. Extrem cool.

Der erste Vortrag den ich besuchte war 13 Uhr "Die Geschichte der Corona Warn-App". Es war wirklich spannend zu verfolgen wie die deutsche Corona Warn-App sich entwickelt hat, da ich es kaum verfolgt hatte. Sehr cool fand ich, dass die Konferenz ja remote war und ich teilweise in 3 Streams gleichzeitig war um mir den besten raussuchen zu können. Das würde in der Realität nicht funktionieren ^^

Um 14:30 fand mein Highlight Stream statt über "Wie gründe ich eine Genossenschaft?". Das Thema Gründung einer Genossenschaft interessiert mich sehr, da ich mit ein paar anderen Entwicklern gerade dabei bin eine zu gründen. Von daher war es echt cool im Detail zu erfahren was eine Genossenschaft ist und über Erfahrungsberichte von Leuten, die schon welche gegründet haben, zu hören. Für mich sehr interessant war, dass Genossenschaften wohl in einigen Bereichen helfen können Steuern zu sparen und das Genossenschaften wohl in der Allgemeinheit unterschätzt werden, obwohl sie etwas sehr tolles sind.

Ich hab noch viele andere Streams an dem Tag besucht und es ist immer wieder toll Menschen so begeistert über ihre Themen präsentieren zu sehen.

Auch extrem cool und witzig und toll war die RC3 World welches eine digitalisierte zweidimensionale Welt von dem RC3 Messegelände und mehr darstellt. Du erstellst dir dort einen kleinen Avatar und läufst zusammen mit vielen anderen in einer 2 d Welt herum. Mit den anderen kann man auch sprechen und sich gegenseitig per Webcam bestaunen wenn man nah genug zusammenkommt. Extrem witzig und cool. In der World wurden unter anderem die Chaos Spaces von Deutschland modelliert und das Hacklabor ist sehr gut gelungen (siehe Titelbild).

Tag 2

Besuchte Streams:

11:00 Daten : IT bei der Polizei
12:20 Scientific Literacy 101
13:00 Mundhalle
14:20 Flutter - An advanced view on cross-platform app development
15:00 Hackergenossenschaft Plattform chaosnahen Wirtschaftens
19:00 Gesundheit ist eine soziale Frage

Heute ist Montag und der zweite Tag der rC3. Meine Highlight Stream heute war der 15:00 Uhr "Hackergenossenschaft als Plattform chaosnahen Wirtschaftens" . Da ich selber gerade bei einer Genossenschaftsgründung dabei bin, ist es hochspannend darüber zu hören. Etwas verstörend fand ich, dass die dort vorgestellte Hackergenossenschaft ein Jahr gebraucht hat um die Genossenschaft zu gründen. Das soll wohl viel mit der Bürokratie von Deutschland zu tun haben. Ich bin aber optimistisch das unsere Genossenschaftsgründung schneller gehen wird.

Auch sehr spannend wer der 19:00 "Gesundheit ist eine soziale Frage" talks, welcher sehr schön aufgezeigt hat wie das aktuelle Deutsche Gesundheitsystem kränkelt. Z.B. das Präventation eine eher untergeordnete Rolle spielt. Auch sehr zum Nachdenken hat mich gebrachte die Formulierung warum man eigentlich Patienten wieder in ihr Umfeld entlässt, welches sie so krank gemacht hat. Genau da müsste man eigentlich ansetzen und das Umfeld / die Lebensbedingungen des Patienten angehen.

Tag 3

Besuchte Streams:

11:05 Digitales Ehrenamt meets Deutsche Stiftung fuer Engagement und Ehrenamt met
13:00 Offene Daten für Viele Nutzbar machen

Heute hatte ich leider nicht ganz so viel Zeit zum Anschauen von Streams da ich an Projekten gearbeitet habe. Gegen Abends hab ich in der rC3 World etwas sozialised. Ich habe ein paar coole Dudes von dem Rostocker Space kennengelernt. Mir ist dann aufgefallen das ich Einige noch aus meiner Zeit als Rostocker Student her kenne. Die rC3 World ist dann auch irgendwann zusammengebrochen und es hat sehr lange gedauert bis diese wieder erreichbar war.

Tag 4

Heute konnte ich so gut wie keine Streams besuchen da viel auf Arbeit getan werden musste. Ich konnte gegen Abend aber noch etwas Zeit mit Freunden in der World verbringen und ein ein paar Streams schauen.

Fazit

Vielen vielen Dank an die Organisator und mitwirkenden Kräfte des rC3. Es war meine aller erste Chaos Computer Club Veranstaltung und es hat mich einfach aus den Socken gehauen. Es gab viele spannende Streams und die World war genial. Dafür dass dies die erste rC3 war, sind die relativ häufigen technische Markel / Ausfälle auf jedenfall verzeihbar.

Anyhow ich hoffe für 2021 findet die C3 wieder in Person statt, aber falls nicht die rC3 ist eine super Alternative! Danke auch an meinen Kumpel und erfahrenen C3 Kongress Besucher für die vielen kleinen Tipps und das lustige Beisammen sein die meine rC3 Experience super gemacht hat :).

Werde ein Patreon!

Raspberry 4 IOT mit AWS CDK Pipeline automatisiertes Deployment

Sat, 02 Jan 2021 00:00:00 GMT

Hi Raspberry Freunde.

Hinweis: Ich habe in diesem Artikel Provisions-Links verwendet und sie durch "*" gekennzeichnet.

Seit kurzem darf ich mich Besitzer eines Raspberries nennen. Am Cyber Monday habe ich mir einen *Raspberry 4 mit 4 GB gekauft. Ich habe schon früher Erfahrungen mit Home IOT gesammelt und diese in einem Blogpost zusammengefasst. Allerdings waren diese Erfahrungen an fertige IOT Lösungen gebunden und geben daher nur einen limitierten Funktionsumfang. Ein guter Freund von mir, der viel Erfahrung mit Home IOT (Internet of Things) hat, zeigte mir was noch alles so möglich ist.

Ich wollte aus auf das nächste IOT Level und mit Hilfe von MQTT und NodeRED coole Lösungen bauen. Meine erster Use Case ist, dass ich den Gaszähler digital auslesen möchte und in Relation zur Zeit schöne Auswertungsgrafiken angezeigt bekomme. Im Internet fand ich eine Anleitung wie man meinen Gaszähler, digital unterstützt, auslesen kann BK-G4. Diese Lösung verlangte aber ein komplexes NodeRED Deployment mit der Verwendung eines Raspberries.

Der Raspberry kann wie ein normale VM behandelt werden. Das heißt es wird mit einem Betriebsystem wie Ubuntu bespielt. Dann werden erforderliche Programme installiert und anschließend wird das NodeRED Deployment ausgeführt. Bei Bedarf kann die VM einfach weggeschmissen werden und alles nochmal ausgeführt werden. Das sind viele manuelle Schritte die sehr zeitaufwendig und fehleranfällig sein können.

Von daher habe ich mich entschlossen das gesamt Deployment zu einem hohen Grade zu automatisieren mit der Verwendung folgender Technologien GitHub, Docker, Docker Compose, AWS CodeDeploy Agent, AWS CodePipeline mit CDK Pipeline. Prinzipiell muss dann nur noch ein push zum main branch gemacht werden und das gesamte Docker Deployment baut und startet sich von allein.

Wie das alles geht beschreibe ich in den nächsten Abschnitten.

Setup

Zunächst möchte ich aber gerne mein Setup beschreiben. Wie Eingangs schon erwähnt, habe ich mir zum Cyber-Monday einen Raspberry 4 (kurz Rasp4) mit 4GB gekauft *https://amzn.to/3rD3HOf. Desweiteren gab es in dem Set noch eine 64 GB microSSD.

Die Installation von Ubuntu 20.04.1 war sehr einfach und ist sehr gut Dokumentiert auf ubuntu.com . Ich habe mich für den Ubuntu Server entschieden, da ich den Rasp4 als headless remote VM benutzen möchte.

Zum Auslesen des Gaszählers benötigte ich noch zwei weitere Komponenten. Einen *Zigbee Tür-/ Fenstersensor und einen Zigbee USB-Stick als Empfänger. Der Sensor sendet ein Signal zum Zigbee Empfänger jedesmal wenn der Zähler 0,1 qm Gasverbrauch gemessen hat. Das ist eine spezifische Lösung für meinen Gaszähler BK-G4. Für euren Gaszähler ist das eventuell so nicht möglich.

Installation der Umgebung

Die IOT Programme sollen mittels Docker Compose laufen und aus meinem GitHub Repo die Docker Compose YAML File bereitgestellt werden. Desweiteren soll das Docker Compose Deployment automatisch rebuilded und redeployed werden sobald sich was zu den main Branch gepusht wird.

Um das alles zu ermöglichen werden viele Programme wie Docker, Docker Compose, Git, AWS CLI, AWS CodeDeploy Agent usw, benötigt. Um die Installation der benötigten Programme zu vereinfachen habe ich ein Script ./misc/init.sh erstellt. Dieses wird dann einfach auf dem Rasp4 ausgeführt:

sudo chmod +x ./init.sh
./init.sh

Wichtig noch zu erwähnen. Der Rasp4 hat nur eine one way Internetverbindung. Das heißt er hat keine öffentliche IP und ist somit von außen nicht bzw. nur schwer erreichbar. Er ist damit nur im lokalen Netz erreichbar.

Automatisiertes Deployment mit AWS CodeDeploy & AWS CodePipeline

Um manuellen Aufwand so gut es geht zu verringern, habe ich mich dafür entschieden das Docker Compose Deployment zu automatisieren. Dafür verwende ich einen AWS CodeDeploy Agenten der automatisch Änderungen auf dem main Branch registriert und auf dem Rasp4 ausführt. Die Installation des AWS CodeDeploy Agents war etwas knifflig aber hat letztenende funktioniert. Der Agent wird auch mit der init.sh installiert.

Um den Agenten Aktionen auf dem Rasp4 ausführen zu lassen sobald Commits auf dem main Branch passieren, muss noch eine AWS CodePipeline erstellt werden. Die AWS CodePipeline wird Konfiguriert und Verwaltet mit AWS CDK . AWS CDK ist ein Open Source Framework zur Erstellung und Verwaltung von AWS Ressourcen mit Hilfe von high level Sprachen wir TypeScript oder Python. Der AWS CDK Code is ebenfalls in meinem GitHub repo und hier zu finden.

Falls ich dich für das Thema AWS CDK neugierig gemacht habe, findest du auf meiner Blogseite unzählige weitere Blogposts über AWS CDK

IOT Docker Compose Stack

Mein IOT Stack besteht aus den folgenden Containern NodeRED, InfluxDB, Grafana, Mosquitto und Zigbee. Die genauen Einstellungen sind in der docker-compose file . Den Stack habe ich mir mit dem Docker Compose Builder von IOTstack zusammengebastelt.

Ich empfehle euch einen der Forks vom IOTstack zu benutzen da der User gcgarner den Builder nicht mehr zu maintainen scheint.

Was hat mir besonders Spaß gemacht?

Extrem cool fand ich die einfach Installierung von Ubuntu auf meinen Rasp4. Das ging sogar ohne extra Tastatur und Monitor und nennt sich remote Installation. Dafür muss während der Image Bespielung auf der microSSD karte einfach noch das wifi Credentials mit angegeben werden. Dieser einfach Prozess hat mich irgendwie an Docker Images erinnert, die ja auch sehr leichtfüßig unterwegs sind. Extrem cool!

Es ist auch ein paar mal vorgekommen, dass ich das gesamte OS neu bespielt habe um Konfigurationsprobleme zu lösen. Da ich alle Schritte der Installation in der init.sh hatte, war das kein Problem.

Auch die Erstellung der AWS CodePipeline mit AWS CDK war extrem cool. Da ich mit AWS CDK schon sehr viel Erfahrung habe, ging das sehr leicht von der Hand. Infrastructure as Code ist einfach toll!

Schwierigkeiten

Sehr zeitaufwendig und nervig war das Einrichten des AWS CodeDeploy Agents, da dieser nur mit bestimmten Programmversionen von awscli oder ruby funktioniert. Bis heute bin ich mir nicht sicher, warum der Agent immer so viel rumgezickt hat. Naja er funktioniert jetzt und das ist was zählt.

Ausblick

Ich habe bereits begonnen mit dem NodeRED Flow und kann erfolgreich den Zigbee Türsensor auslesen und bei jedem Signal den digitalen Zählerstand erhöhen. Was jetzt noch fehlt ist das Einspeisen in die InfluxDB und das Konfigurieren von Grafana um schöne Auswertungsdiagramme für gewünschte Zeiträume zu bekommen.

Auch möchte ich in Zukunft an noch spannende IOT Sachen mit coolen Use Cases arbeiten. Ich denke darüber nach einige IOT Prozesse von meiner Smart Life App in mein NodeRED zu migrieren.

Der Rasp4 selbst bietet noch mehr Möglichkeiten als nur als IOT Server verwendet zu werden. Z.B. verwende ich ihn bereits als DNS Server mit Pi-Hole. Damit blockt er z.B. nervice DNS Queries wie Telemetrie Daten oder Werbung. Mit Sicherheit werde ich noch weitere coole Use Cases für meinen Rasp4 finden.

Zusammenfassung

IOT ist ein spannendes Thema. Fertiglösungen wie Smart Life, Alexa und co sind leicht zu installieren und versprechen früh den erwünschten Erfolg. Allerdings sind solche Fertiglösungen meistens nur sehr begrenzt in der Funktionalität. Bisher bin ich mit Smart Life ganz gut voran gekommen.

Die Aufgabe den Gaszähler automatisiert auszulesen, hat aber nach einer komplexeren IOT Lösung mit einem Raspberry und NodeRED Flow verlangt. Wie diese Lösung aussieht, habe ich hier beschrieben. Es hat mir unglaublich viel Spaß gemacht an diesem IOT Projekt zu arbeiten und ich bin meinem IOT Kumpel :D extrem dankbar für die Zeit, die er aufbringt um mich dem IOT Thema näher zu bringen.

Fandet ihr den Artikel interessant oder habt ihr noch Fragen? Schreibt mir doch gerne :) .

Werde ein Patreon!

ALPS Helfer Library

Sat, 19 Dec 2020 00:00:00 GMT

Hi :).

Der neue von mir entwickelte ALPS Converter macht es möglich eine ALPS Spezifikation (kurz Spec) zu OpenApi, GraphQL oder anderen APIs zu konvertieren.

import { Alps, FormatType } from 'alps-unified-ts';

// geladen von einer YAML File
Alps.unified(Alps.loadYaml('todo-alps.yaml'), { formatType: FormatType.OPENAPI })

Weitere tolle Features meine ALPS unified Library sind:

automatische versioniertes Releasing nach NPM, PyPi, Maven und Nuget (für .NET)
Typensupport

Das GitHub Projekt wurden mit Projen erstellt. Was die ALPS Api und Projen ist will ich in den nächsten Abschnitten genauer erörtern.

ALPS API

ALPS ist eine Spezifikation zur Beschreibung vom Context eines Services. ALPS kann verwendet werden als Spezifikationinput zum generieren von niedrig abstrahierten Spezifikationen wie OpenApi / Swagger, WSDL, RAML, WADL.

Der ALPS Converter convertiert also eine ALPS Api Spec in niedriger abstrahierten Api Spezifikationen. Ein Beispiel für so eine Konvertierung folgt im nächsten Abschnitt.

ALPS API Spec Beispiel

Das folgende Beispiel ist eine simple TODO ALPS API Spec.


alps:
  version: '1.0'
  doc:
    value: 'Simple Todo list example'

  ####################################
  # metadata
  ext:
    - type: metadata
      name: title
      value: simpleTodo
      tags: 'oas'
    - type: metadata
      name: id
      value: http://alps.io/profiles/mamund/simpleTodo
      tags: 'oas'
    - type: metadata
      name: root 
      value: http://api.example.org/todo
      tags: 'oas'
  
  descriptor:
    # properties
    # - these are the data elements
    - id: id
      type: semantic
      text: storage id of todo item
      
    - id: body
      type: semantic
      text: content of todo item

    # groupings
    # - these are the storage objects
    - id: todoItem
      type: group
      text: todo item
      descriptor:
      - href: '#id'
      - href: '#body'

    # actions
    # - these are the operations
    - id: todoList
      type: safe
      rt: todoItem
      text: return list of todo items
            
    - id: todoAdd
      type: unsafe
      rt: todoItem
      text: create a new todo item
      descriptor:
      - href: '#todoItem'
      
    - id: todoRemove
      type: idempotent
      tags: delete
      rt: todoItem
      text: remove a single todo item
      descriptor:
      - href: '#id'

Das Element todoItem besteht aus einer id und einem todo string body . Es sind drei Aktionen definiert todoList zum listen der todo Einträge, todoAdd zum Einfügen neuer todos und todoRemove zum Löschen von todo Einträgen.

Daraus kann der Unified Convertierer diese OpenApi Spezifikation generieren:

openapi: 3.0.1

# *******************************************************************
# generated by "unified" from src/todo-alps.yaml
# date: Wed Nov 25 2020 18:47:05 GMT+0100 (Central European Standard Time)
# http://github.com/mamund/2020-11-unified
# *******************************************************************

info:
  title: simpleTodo
  description: Simple Todo list example
  version: 1.0.0

servers:
- url: 'http://api.example.org/todo'

paths:
  /todoList:
    get:
      summary: 'return list of todo items'
      operationId: todoList
      responses:
        200:
          description: todoList
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/todoItem'
  /todoAdd:
    post:
      summary: 'create a new todo item'
      operationId: todoAdd
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/todoItem'
      responses:
        200:
          description: add todoAdd
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/todoItem'
  /todoRemove/{id}:
    delete:
      summary: 'remove a single todo item'
      operationId: todoRemove
      parameters:
        - name: id
          in: path
          description: id of todoRemove
          required: true
          schema:
            type: string
      responses:
        204:
          description: delete todoRemove

components:
  schemas:
    todoItem:
      description: todo item
      type: object
      properties:
          id:
            type: string
            example: 4572
          body:
            type: string
            example: jn1ov7axj4kv560d0921xf

Oder auch dieses GraphQL Schema:

# *******************************************************************
# generated by "unified"
# date: Fri Dec 11 2020 16:51:00 GMT+0100 (Central European Standard Time)
# http://github.com/mamund/2020-11-unified
# *******************************************************************

type todoItem {
  id: String!
  body: String!
}

type Query {
  todoList: [todoItem]
}

type Mutation {
  todoAdd(todoItem: String!): todoItem
  todoRemove(id: String!): todoItem
}

schema {
  query: Query,
  mutation: Mutation
}

Projen

Projen erlaubt eine ausgeklügelte Verwaltung von Projektkonfiguration durch Code. Mit nur wenigen Zeilen TypeScript Code kann ein gesamtes Repository konfiguriert werden. Hierfür ein Beispiel:

const { JsiiProject } = require('projen');

const project = new JsiiProject({
  name: 'alps-unified-ts',
  authorAddress: 'damadden88@googlemail.com',
  authorName: 'Martin Mueller',
});

project.synth();

Diese wenigen Zeilen erzeugen alle GitHub Projektfiles die das Herz begehrt. Darunter die package.json, .gitignore, tsconfig.json und noch viele viele mehr.

Wirklich richtig cool ist das Projen auch mit GitHub Workflows kommt die z.B. neue Versionen publishen können nach Registries wie NPM oder PYPI.

Ich habe das Projen Framework lieben gelernt, da es tolle Abstraktion und Vorgabe für ein Setup von Projekten ist. Ich lege dir ans Herz Projen mal einen Versuch zu geben und sehr bald wirst du die Schönheit dieses Frameworks selber erleben.

ALPS Library in Action

Hier möchte ich nun kurz meine neue ALPS Unified Library vorstellen. Das TypeScript package kann so

import { Alps, FormatType } from 'alps-unified-ts';

// geladen von einer YAML File
Alps.unified(Alps.loadYaml('./spec/todo-alps.yaml'), { formatType: FormatType.OPENAPI })

// oder direct per TypeScript Object
Alps.unified(Alps.spec({
    alps: {
      version: '1.0',
      doc: {
        value: 'Simple Todo list example',
      },
      ...
    }
});

Die Alps.unified(...) Function gibt immer einen String zurück. Je nach formType beinhaltet der zurückgegebene String das gewünsche Format. In unserem Beispiel ist das FormatType.OPENAPI welches OpenApi in YAML ist. Würde man nun gerne OpenAPI in JSON zurückhaben wollen, ginge auch FormatType.OPENAPI_JSON. Für die Wiedergabe des Graph QL Schemas müsste man FormatType.DSL verwenden.

In Python kann die Library so benutzt werden:

import alps_unified_ts as alps

alps_def = alps.AlpsDef(
  version='1.0', 
  descriptor=[alps.DescriptorDef(id="id", type="semantic", text="sotrage id of todo item")], 
  doc=alps.DocDef(
    value="Simple Todo list example"), 
    ext=[
      alps.ExtDef(
        name="root", 
        tags="oas", 
        type="metadata", 
        value="http://api.example.org/todo"),
      alps.ExtDef(
        name="title", 
        tags="oas", 
        type="metadata", 
        value="simpleTodo")])

alps_converted = alps.Alps.unified(alps_document=alps.Alps.spec(alps=alps_def), format_type=alps.FormatType.OPENAPI)

Die Verwendung in Java und .NET sollte ähnlich aussehen.

In meinem vorherigen Blogpost ALPS kombiniert mit CDK erkläre ich wie aus einer ALPS Spec wahlweise ein AWS Api Gateway oder AWS Appsync mit dem ALPS Todo Beispiel und der ALPS unified library erzeugen werden kann.

Zusammenfassung

Eine Library mit Projen zu bauen war super fun! Ich habe damit eine neue, verbesserte Version von der alps unified library gebaut. Diese kommt jetzt mit supper coolen neuen Funktionen die ich hier vorgestellt habe.

Achja eine Info noch. Falls euch auch das ALPS Thema interessiert, mit der ALPS Community veranstalten wir regelmäßig Community Treffen online. Dort trefft ihr spannende Leute auß aller Welt. Kommt gerne mal vorbei :) .

Werde ein Patreon!

ALPS Api kombiniert mit AWS CDK

Mon, 14 Dec 2020 00:00:00 GMT

Hi :).

AWS bietet viele spannende Api Technologien an. Solche sind z.B. das AWS Api Gateway welches eine Implementation einer REST Api ist oder AWS Appsync was eine GRAPH QL Api implementiert.

Jeder dieser AWS Api implementationen hat seine Vor- und Nachteile. Z.B. kann die Erstellung von Appsync schneller von der Hand gehen als das Api Gateway, allerdings wird es dann wieder komplizierter bei der Erstellung von Queries and das Graph QL. Zugegeben ich kenne mich zu wenig aus um die Vor- und Nachteile der verschieden Api Implementation in AWS gegeneiner abzuwägen, aber das muss ich jetzt auch nicht mehr!

Mit meiner aufregenden Arbeit mit ALPS in Kombination mit AWS CDK, kann ich die Api frei auswählbar machen oder sogar gegeneinander austauschen und das alles auf Grundlage von einer ALPS Spezifikation (kurz Spec).

Was genau eine ALPS Spec ist und wie daraus mit Hilfe von AWS CDK komplette Apis wie Api Gateway oder Appsync erstellt werden können, erkläre ich euch in den nächsten Abschnitten.

ALPS Api

ALPS ist eine Spezifikation zur Beschreibung vom Context eines Services. ALPS kann verwendet werden als Spezifikationsinput zum generieren von niedrig abstrahierten Spezifikationen wie OpenApi / Swagger, WSDL, RAML, WADL.

Als ich das YouTube Video mit Mike Amundsen gesehen habe, fand ich die Idee von ALPS sofort cool und spannend. Wie jeder gut Entwickler liebe ich Abstraktionen und ALPS scheint eine extrem coole Abstraktion zu sein. Mir kam dan sofort die Idee ob man die ALPS Api nicht mit AWS CDK Constructen verbinden könnte. Genau das habe ich gemacht und berichte mehr im Detail darüber im nächsten Abschnitt.

AWS CDK ALPS Constructs

AWS CDK Constructs sind kurzgefasst Quellcode für Resourcen in AWS. Dafür benutzen sie abstrakte Sprachen wie TypeScript oder Python und generieren aus dem Code Cloudformation Templates welche dann auch noch mit dem AWS CDK Framework applyed werden. Wenn euch das Thema AWS CDK mehr im Detail interessiert, ich habe sehr viele Posts über CDK hier geschrieben.

Mein Ziel war es also mit Hilfe von einer ALPS Specs gezielt AWS Apis wie Api Gateway und Appsync aufbauen zu lassen. Nachfolgend zeige ich zuerst ein ALPS Spec Beispiel. Dann beschreibe ich das Construct bei dem ich aus einer ALPS Spec ein AWS Api Gateway generiere. Danach wird aus der selben ALPS Spec ein Appsync gebaut.

Die beiden nachfolgenden Libraries werden automatisch nach NPM (für JavaScript und TypeScript) und PYPI (für Python) released. In Zukunft plane ich auch zu einem öffentlichen Maven Repository und .Net package Repository zu publishen.

ALPS Spec Beispiel

Das folgende Beispiel ist eine simple TODO List Api.


alps:
  version: '1.0'
  doc:
    value: 'Simple Todo list example'

  ####################################
  # metadata
  ext:
    - type: metadata
      name: title
      value: simpleTodo
      tags: 'oas'
    - type: metadata
      name: id
      value: http://alps.io/profiles/mamund/simpleTodo
      tags: 'oas'
    - type: metadata
      name: root 
      value: http://api.example.org/todo
      tags: 'oas'
  
  descriptor:
    # properties
    # - these are the data elements
    - id: id
      type: semantic
      text: storage id of todo item
      
    - id: body
      type: semantic
      text: content of todo item

    # groupings
    # - these are the storage objects
    - id: todoItem
      type: group
      text: todo item
      descriptor:
      - href: '#id'
      - href: '#body'

    # actions
    # - these are the operations
    - id: todoList
      type: safe
      rt: todoItem
      text: return list of todo items
            
    - id: todoAdd
      type: unsafe
      rt: todoItem
      text: create a new todo item
      descriptor:
      - href: '#todoItem'
      
    - id: todoRemove
      type: idempotent
      tags: delete
      rt: todoItem
      text: remove a single todo item
      descriptor:
      - href: '#id'

CDK ALPS REST Api Construct Library

Das erste ALPS CDK Construct das ich implementiert habe ist das CDK ALPS REST Api Construct in meinem github repo . Es erstellt ein AWS Api Gateway mit Hilfe des CDK SpecRestApi Constructs. Dieses muss dann nur noch eine aus dem ALPS generierte openApi Spec übergeben werden:

const api = new apigw.SpecRestApi(this, 'SpecRestApi', {
  apiDefinition: apigw.ApiDefinition.fromInline(oasSpecJSON),
});

CDK ALPS Graph QL Api Construct Library

Das zweite ALPS CDK Construct war wesentlich spannender für mich, da ich dafür AWS Appsync als Graph QL Api verwendet habe und das noch komplett neu für mich war. Wieder allen Erwartungen war das aber sehr leicht und ich hab in wenigen Stunden das Construct hier auf github fertigstellen können. Dabei übersetzt der ALPS compiler die ALPS Spec in das Graph QL Schema und übergabt das dem CDK GraphqlApi Construct:

export class AlpsGraphQL extends appsync.GraphqlApi {

  constructor(scope: cdk.Construct, id: string, props: AlpsGraphQLProps) {
    // convert ALPS yaml to graph ql schema file in tmp/schema.graphql
    const sdl = Alps.unified(Alps.loadYaml(props.alpsSpecFile), { formatType: FormatType.SDL });
    fs.writeFileSync('tmp/schema.graphql', sdl);
    super(scope, id, {
      ...props,
      schema: appsync.Schema.fromAsset('tmp/schema.graphql'),
    });

    new cdk.CfnOutput(this, 'GraphQlUrl', { value: this.graphqlUrl });
  }
}

CDK Demo Deployment

Super! Wir haben nun diese zwei Constructs welche aus einer ALPS Spec AWS Apis generieren können. Jetzt müssen wir das nur noch machen :). Dafür habe ich ein neues Demo Github Repo erstellt.

Das Demo Deployment verwendet das gleich ALPS Spec TODO Beispiel welches ich schon vorgestellt habe. Zum Speichern der TODO items wird DynamoDB verwendet:

const todoTable = new db.Table(stack, 'TodoTable', {
  removalPolicy: RemovalPolicy.DESTROY,
  partitionKey: {
    name: 'id',
    type: db.AttributeType.STRING,
  },
});

Dann wird das Api Gateway und Appsync erstellt

new AlpsSpecRestApi(stack, 'AlpsSpecRestApi', { alpsSpecFile: 'src/todo-alps.yaml' });
...

const graphQlApi = new AlpsGraphQL(stack, 'AlpsGraphQL', { alpsSpecFile: 'src/todo-alps.yaml' });

...

Das wars. Jetzt nur noch den CDK Stack applyen mit:

yarn build
yarn deploy [--profile X]

Yeahh. Wir haben somit ein Api Gateway und ein Appsync erstellt auf Grundlage der ALPS Api.

Use Cases

Natürlich hab ich mir gedanken gemacht welche Use Cases für die ALPS Spec Abstraktion es geben könnte. Einige sind mir aufgefallen, während ich die CDK ALPS Constructs erstellt habe.

Ich sehe es als einfachen und sicheren Weg für eine Migration vom Api Gateway zu Appsync. Die Resolver für das Graph QL könnten zum Beispiel die Lambda Integrationen von der Rest Api nutzen oder eventuell sogar komplett auf diese verzichten und für CRUD Operationen auf eine DB direkt ein Mapping.

Da die ALPS Spec eine Abstraktion von z.B. Rest Api ist, sollte es möglich sein für Domaineexperten diese selber schreiben zu können. Es wäre super wenn der domainspezifische Context besser abstrahiert werden könnte und das könnte mit ALPS möglich sein. Während sich also der Domaineexperte um die Fachlichkeit kümmert, kann der Entwickler an der konkreten Api und dessen Implementation arbeiten. Somit wird eine besseres modulares Arbeiten ermöglicht.

Zusammenfassung

ALPS Api ist eine faszinierende Idee über die Abstraktion von anderen Apis wie REST, Graph QL usw. Mir persönlich hat es geholfen Graph QL besser zu verstehen da ich durch den Rückweg über den ALPS Spec einen gemeinsamen Nenner hatte. Auch die automatische Generierung des Graph QL Schemas ist super toll um ebenfalls die Api besser zu verstehen.

Ich selber habe bei der Erstellung der drei Repos gemerkt, dass ich noch nicht viel über die ALPS Syntax weiß und mehr darüber lernen möchte. Wenn euch auch das ALPS Thema interessiert, schreibt mir doch. Mit der ALPS Community veranstalten wir regelmäßig Community Treffen online aus aller Welt. Dort trefft ihr spannende Leute und könnt euch einbringen wenn ihr wollt :).

Ich arbeite bereits an einer aufgefrischten Library zur Konvertierung der ALPS Spec zu den lower abstracted Apis hier. Damit wird es dann noch einfacher sein ALPS unified als Library in deinem Code zu benutzen:

// geladen von einer YAML File
Alps.unified(Alps.loadYaml(...), { formatType: FormatType.OPENApi })

// oder direct per TypeScript Object
Alps.unified(Alps.Spec({
    alps: {
      version: '1.0',
      doc: {
        value: 'Simple Todo list example',
      },
      ...
    }
});

Darüber hinaus soll die Library in JavaScript, TypeScript, Python, Java und .NET funktioniert und über öffentliche Registries erhältlicht sein. Mehr darüber kommt in einem separatem Blogpost. Bis dahin stay tuned!

Werde ein Patreon!

Dankbarkeit

Tue, 08 Dec 2020 00:00:00 GMT

Ein herzliches hallo,

Da wir uns jetzt gegen das Ende von 2020 zubewegen, wollte ich gerne die Gelegenheit nutzen meine Dankbarkeit zu zeigen. Dafür möchte ich einen ganzen Blogpost widmen :). Auch wenn es für viele anders war, für uns war 2020 das beste Jahr als Familie. Warum das so ist, werdet ihr herausfinden, wenn ihr den ganzen Post lest.

In den nächsten Abschnitten liste ich meine Danksagungen chronologisch nach meinen Lebensjahren.

Gott

Der erste und größte Danke geht an Gott. Denn er ist barmherzig und großzügig. Er hat mich mit einen gesunden Geist und Körper gesegnet, was bei weitem nicht selbstverständlich ist. Auf meinem Lebensweg hat er mich begleitet und vor größerem Schaden bewahrt.

Vielen Dank Gott und ich bitte dich weiterhin über mich und vor allem über meine Familie, Freunde und der Menschheit zu wachen. Nur Danke sagen reicht mir nicht! Auch 2021 möchte ich mich stärker in deiner Gemeinde angagieren.

Auch wenn das nicht immer einfach ist, gibst du mir die Stärke das zu tun. Ich möchte dir Danken mein Gott.

Eltern

Vielen Dank möchte ich auch an meine Mama und Papa richten. Es sind zwei unglaublich tolle Menschen. Und vor allem sind sie herzensgut. Sie haben mir tolle Werte vermittelt. Meine Kindheit als Außenseiter war gewiss nicht leicht, aber durch die Hilfe und Zuneigung meiner Familie war es kein Problem durch diese relativ schwierige Zeit meines Lebens zu gelangen.

Ganz besonders möchte ich meiner Mutter danken die maßgeblich für meine Entwicklung beigetragen hat. Für sie stand Bildung für mich und meinen Bruder immer an erster Stelle. Dafür bin ich ihr extrem dankbar, denn ohne diesen hohen Stellenwert hätte ich vielleicht meinen Traumberuf als Software Entwickler niemals gefunden.

Sie ist eine herzensgute und starke Frau. Ich denke das hat mich insgeheim auch stark beeinflusst bei der Wahl meiner Frau die ebenfalls herzensgut und stark ist. Vielen Danke Mutti und Pappi.

Frau

Den Dank eine meine Frau. Wo fange ich da nur an. Ich hab soviel über das ich Dankbar sein könnte wenn es zu meiner Frau kommt. Kennengelernt habe ich sie in England. Ich war dort seit fast zwei Jahren. Nach einem Praktikum bei Alfresco, bekam ich dort eine Festanstellung und entschied, länger in England zu bleiben.

Meine Frau war in England für fast einem Jahr. Sie kommt aus Brasilien und wollte unbedingt England kennen lernen. Wie der Zufall es wollte, trafen wir uns und hatten sofort eine Verbindung. Liebe auf dem ersten Blick!

Alles ging dann relativ schnell. Wir ziehten zusammen in eine Wohnung und verlobten uns nur wenige Monate nachdem wir uns kennengelernt hatten. Seit dem sind es nun schon 3 wunderschöne Jahre mit ihr. Unsere Beziehung ist sehr harmonisch und ich freue mich schon auf die vielen kommenden Jahren zusamen mit ihr.

Vielen Dank an meine wunderschöne, kluge und tollen Frau, dafür das du immer an meiner Seite bist und gemeinsam mit mir durch das Abenteuer Leben gehst. Ich möchte keinen Tag ohne dich mehr sein. Und auch vielen Dank das du so eine tolle Mutter bist. Unsere Tochter hat so ein riesen Glück das sie eine so tolle Mutti hat.

Kind

Ein besonderer Dank geht an meine Tochter. Sie ist noch nicht in der Lage diesen Text zu verstehen. Mal sehen vielleicht existiert dieser Blog ja noch, wenn sie es dann kann und sie freute sich vielleicht darüber. Anyway ich bin sehr stolz und glücklich dein Vater sein zu dürfen.

Du schenkst mir jeden Tag erneut dein Vertrauen und ich akzeptiere jeden Tag dieses kostbare Geschenk und verspreche dir, immer zu deinem Besten zu handeln. Vielen Dank das ich dein Vater sein darf.

Allen Anderen

Hier möchte ich gerne allen Danken die auch eine eigenen Abschnitt verdient hätten aber dann der Post extrem lang wäre.

Ein besonderer Dank geht an meinem Bruder. Er spielte und spielt eine wichtige Rolle in meinem Leben. Zusammen aufgewachsen waren wir beste Freunde. Wir sind zusammen durch dick und dünn gegangen während des Kindergartens und zum Teil sogar noch in der Schule. Vielen Dank.

Vielen vielen Dank auch an meine nicht Kernfamilie wie meinen Tanten und Onkel sowie meinen Großeltern. Wir haben euch so unglaublich viel zu verdanken. Ihr habt meiner Frau und mir bei dem Umzug nach Deutschland stark geholfen. Ihr habt uns so toll unterstützt beim Hauskauf. Außerdem waren die vielen kleinen Unterstützungen wie Klamotten für Rebecca und die vielen kleinen Geschenke extrem hilfreich. Vielen Danke für eure Hilfe.

Auch möchte ich meiner Familie aus Brasilien danken. Ich hatte das Glück diese 2018 in Brasilien zu besuchen und hoffe dass ich das wieder machen kann im Jahr 2021.

Auch möchte ich meinen Exkollegen aus der Firma Alfresco und der Firma Object danken. Diese haben mich sehr geprägt und zu einem besseren Entwickler reifen lassen.

Erst seit kurzem leben wir in der schönen Stadt Ludwigslust. Nicht weit von uns haben wir eine tolle junge Familie gefunden mit der wir gerne Zeit verbringen. Es sind herzensgute Menschen und liebevolle Eltern. Vielen Dank dass ihr da seit und wir euch als Freunde haben dürfen.

Ganz anfänglich dankte ich Gott. Ich möchte auch Gottes Gemeinde hier in Ludwigslust Danken. Die Landeskirchliche Gemeinschaft Ludwigslust ist für mich eine wertvolle Gemeinschaft mit dem Ziel Gutes zu tun und forciert Gottes Wort zu verkünden. Vielen Dank dass ich euer Mitglied sein darf.

Zusammenfassung

Dankbarkeit ist eine tolle Sache und macht das Leben schöner. Es erzeugt ein positives Gefühl für an dem der Dank gerichtet ist und demjenigen der den Dank äußert. Ich hoffe euch hat dieser etwas andere Stiel trotzdem gefallen. Schreibt mir wofür ihr dankbar seit.

Werde ein Patreon!

Optimised Fasting

Sat, 28 Nov 2020 00:00:00 GMT

Hi Low Carber :)

In den letzten Monaten habe ich erfolgreich viel Gewicht verloren mit Optimised Fasting (übersetzt optimiertes Fasten). Pro Woche habe ich ca. 500 Gramm, also einen halben Kilo, verloren. Ich habe schon viel Erfahrungen mit Fasten wie Wasserfasten gesammelt. Optimised Fasting is eine Abwandlung vom Wasserfasten. Da diese Diät für mich so erfolgreich funktioniert, wollte ich sie euch gerne einmal vorstellen.

Disclaimer

Ihr solltet diese Diät nur ausprobieren, wenn ihr schon etwas Erfahrungen mit Low Carb oder sogar Ketosis habt. Low Carb bedeutet eine massive Reduzierung der Einnahme jeglicher Arten von Zucker. Der Mensch hat im wesentlichen zwei Stoffwechsel zur Erzeugung von Energie. Das ist zum einem der Zuckerstoffwechsel und zum anderem der Fettstoffwechsel. Beim Zuckerstoffwechsel nutzt der Körper primär Zucker zum gewinnen von Energie und beim Fettstoffwechsel nutzt er primär Fett.

Wenn der Fettstoffwechsel allerdings kaum benutzt wird, verkümmert er, bzw. wird nie vernünftig ausgebaut. Beim Optimised Fasting brauchen wir aber einen stark ausgebildeten Fettstoffwechsel ansonsten können die zwei Tage an denen gefastet wird, physisch und psychisch schwierig werden, da sich der Körper nach Zucker sehnt und nie vernünftig gelernt hat mit dem eignen Körperfett mittels Fettstoffwechsel umzugehen. Es wäre also ein bisschen so wie ins kalte Wasser zu springen. Nebenwirkungen können dann sein Kopfschmerzen und extremes Hungerempfinden.

Wenn ihr also glaubt noch keinen gut ausgebildeten Fettstoffwechsel zu haben, empfehle ich euch erstmal eine Low Carb Diät auszuprobieren und am Wochenende mal einen Tag rheines Wasserfasten zu erleben. Hier ist noch ein älterer Post von mir über das Wasserfasten den ich euch wärmstens empfehlen kann.

In den nächsten Abschnitten möchte ich mehr über meine neue Diätform des Optimised Fasting erzählen. Bei diesem geht es primär darum über viele Wochen kontinuierlich abzunehmen mit minimalem Aufwand.

Optimised Fasting Anleitung

Optimised Fasting besteht aus ca. 2 Tagen langem Wasserfasten. Um das Training herum ist es erlaubt Vitamine, Salze und minimal Proteine zuzuführen. Durch die Zuführung von Protein vor und nach dem Training wird quasi ein anaboles Signal für den Körper ausgeschüttet, welches hilft das Training besser und vor allem intensiver durchzuführen.

Die Menge an Protein darf dabei nicht zu hoch sein, da sonst das Verdauungsystem zu viel beansprucht wird und das hinderlich für das Training wird. Ca. 25g vor und nach dem Training sollten genügen.

Die Vitamine sind allgemein wichtig für den Menschen um die Körperfunktionen aufrecht zu erhalten. Der Körper kann kein oder nur kaum Salz im Körper Zwischenspeichern und daher ist es notwendig Salz nachzuliefern während des Fastens. Am einfachsten geht das, wenn man ein Lebensmittel mit hohem Salzgehalt zu sich nimmt.

Ein genaues Beispiel an Lebensmittel die ich mir zuführen vor und nach dem Training liste in dem nächsten Kapitel.

Ziel ist es nun das Fasten solange zu machen bis du 500 Gramm weniger als letzte Woche erreicht hast. Bei mir war das bisher immer der dritte Tag, also der Tag nach den zwei Tagen Optimised Fasting. Wenn ich die 500 Gramm erreicht habe, mache ich mir immer ein Bild mit dem Smartphone von der Wage. Somit weiß ich dann wieviel KG ich nächste Woche erreichen möchte.

Optimised Fasting Beispiel

Ich arbeite als Software Entwickler für 4 Tage die Woche. Also von Montag bis Donnerstag. Von daher beginne ich das Optimised Fasting schon am Donnerstag. Am Mittwoch Abend ist also der letzte Zeitpunkt an dem ich etwas esse.

Schon am Mittwoch reduziere ich Lebensmittel mit hohem Zuckergehalt. Ich ernähre mich dann hauptsächlich nur noch von Protein und Fett. Das Hilft mir meinen Fettstoffwechsel auf die nächsten 2 Tage Fasten vorzubereiten und erleichtert den Einstieg.

Donnerstag und Freitag wir dan gefastet und nur um mein morgendliches Training eine Kleinigkeit gegessen.

Vor dem Training

Ich mache mir einen grünen Tee mit einer scharfen Chilli Sauce und gepressten Zitronensaft. Dadurch erhoffe ich mir einen aufputsch Effekt und eine höhere Kalorienverbrennung des Körpers durch den erhöhten Koffeingehalt und Scharfstoffe im Chilli. Danach geht es zum Training.

Mein Training morgens ist breit gefächert und sehr abwechslungsreich. Je nach Körperbefinden mache ich etwas Krafttraining, Ausdauertraining oder ein kurzes hoch intensives Training. Auch Aufwärmen und anschließende Dehnung gehört zu meinem Trainingsprogramm. Wenn ihr mehr über mein Training wissen wollt, sagt mir Bescheid :).

Nach dem Training

Esse ich eine kleine Schale voll mit Nüssen (Wallnuss, Kürbiskerne, Paranuss), Omega 3 und Vitamin D Kapseln, ein Stück schwarze Schokolade, Gummibärchen (ca. 8) und zwei Eier. Im Titelbild seht ihr auch diese Mahlzeit. Wenn ihr euch vielleicht fragt wozu die Gummibärchen. Sie enthalten relativ viel Gelatine welches ein gesundes und wichtiges Protein für den Körper ist. Außerdem sind sie lecker und der Zucker in ihnen ist zu wenig um mich aus der Ketosis zu befördern.

Was ich so toll finde am Optimised Fasting

Jede Diät ist nur dann erfolgreich wenn sie einfach umsetzbar ist und Optimised Fasting ist sehr einfach umsetzbar. Es muss ja nur zwei Tage gefastet werden und an den restlichen Tagen kann man essen wie man möchte. Es ist kein aufwendiges Vorbereiten der Mahlzeiten notwendig, da ja gefastet wird.

Beim Wasserfasten hat mich schon immer das viele Salzwasser trinken genervt. Durch Optimised Fasting kann genug Salz durch den Snack nach dem Training dem Körper zugeführt werden. Es tut dann nicht mehr nötig noch extra Salz in Form von Salzwasser zu trinken.

Auch cool finde ich, dass die 500 Gramm, die ich jedes Wochenende erreiche, ein sehr verlässlicher Wert sind da zu einem mein Darm größtenteils entleert ist nach zwei Tagen Fasten und das Wasser, welches durch Zuckereinlagerungen in den Muskeln zustande kam, raus ist. Somit unterliege ich weniger Wasserschwankungen während der Gewichtsaufnahme nach dem zweiten Fastentag.

Vereinfachter Einstieg

Die Durchführungen meiner bisherigen Optimised Fasting waren sehr einfach für mich da ich Fasten gewöhnt bin und mich allgemein Low Carb ernähre. Auch bin ich sehr diszipliniert was den Sport angeht und meistens morgens und abends kurze und knackige Workouts absolviere. Ich kann mir nun aber vorstellen, dass dir der Einstieg etwas schwerer fallen könnte.

Für diesen Fall habe ich mir eine vereinfachte Variante überlegt. Fang die ersten zwei Wochen erstmal nur mit einem Optimised Fasting Tag an. Somit gibst du deinem Körper die Möglichkeit sich langsam an das Fasten zu gewöhnen. Vielleicht reicht bei dir ja auch schon ein Fastentag und am Folgetag hast du bereits schon 500 Gramm gewicht verloren, im Vergleich zur letzten Woche. Das wäre doch super :).

Zusammenfassung

Optimised Fasting ist eine einfach Art und Weise kontinuierlich abzunehmen. Sie ist extrem leicht umzusetzen da nur ca. zwei Tage gefastet werden müssen und in der restlichen Woche kann man essen was man möchte. Kein nerviges Vorbereiten der Mahlzeiten. Kein zählen der Kalorien.

Falls Fasten oder Low Carb generell etwas für dich sind, kann ich dir nur empfehlen mal diese Art der Gewichtsreduktion auszuprobieren. Schreib mir deine Erfahrungen. Ich bin sehr gespannt :) !

Werde ein Patreon!

AWS Cognito Auth Mock

Mon, 16 Nov 2020 00:00:00 GMT

Ahoi AWS'ler

In meinem AWS Projekt, bei dem ich per REST API Alfresco Instanzen Starten, Stoppen und Terminieren kann, verwende ich für die Userverwaltung AWS Cognito als Identity Provider. Cognito macht es mir einfach neue Nutzer anzulegen und ihnen die Rechte zu geben auf die REST API zugreifen zu können.

Das REST API ist mittels AWS API Gateway implementiert und ein Cognito Authorizer erlaubt den Nutzern aus dem Cognito Identity Pool auf die Endpoints zuzugreifen.

Besonders wichtig ist der Cognito Authorizer da ich einen Permission Layer eingebaut habe der verhindert das Nutzer Alfresco Instanzen von anderen Nutzern Abfragen oder Manipulieren können. Prinzipiell funktioniert der Permission Layer mit den vom Cognito Authorizationsprozess zurückgegebenen User ID, wenn die Authorisation erfolgreich war.

Das funktioniert super, allerdings hätte ich gerne zum testen der Funktionalität des Permission Layers automatisierte Tests. Toll wäre es wenn ich dafür Postman verwenden könnte. Leider ist das nicht möglich da der Authentisierungsprozess mit Cognito eine User Interaktion benötigt um die Credentials abzufragen.

Die Lösung für mich war einen Mock Authentication Layer zu schreiben welcher das genau Verhalten des Cognito Authorizer simuliert. Dafür habe ich Middy verwendet. Was Middy ist und wie genau meine Lösung aussieht beschreibe ich in den nächsten Abschnitten.

Middy als Mock Auth Layer

Middy ist ein einfaches Framework zum Bauen von Layers in Lambda Funktionen. Damit ist es möglich alle Features die nicht direkt zur Business Logik gehören in Layers zu kapseln. In meinem Fall möchte ich einen Mock Auth Layer implementieren der die Cognito Authorisation simuliert. Dieser Layer soll dann optional per Environmental Variable an und ausschaltbar sein.

Der komplette Code für den Auth Layer findet ihr bei mir auf GitHub.

const mockAuthLayer = (config?: MockAuthLayerConfig) => {
  return {
    before: (handler: any, next: () => void) => {
      handler.event = handler.event ?? {};
      handler.event.headers = handler.event.headers ?? {};
      const mockHeaderPrefix = config?.mockHeaderPrefix || 'MOCK_AUTH_';
      Object.keys(handler.event.headers)
        .filter((headerKey) => {
          return headerKey.startsWith(mockHeaderPrefix);
        })
        .forEach((headerKey) => {
          const headerValue = handler.event.headers[headerKey] || 'martin';
          handler.event.requestContext = handler.event.requestContext ?? {};
          handler.event.requestContext.authorizer = handler.event.requestContext.authorizer ?? {};
          handler.event.requestContext.authorizer.claims = handler.event.requestContext.authorizer.claims ?? {};
          handler.event.requestContext.authorizer.claims[
            headerKey.substring(mockHeaderPrefix.length).replace(/&/g, ':')
          ] = headerValue;
          console.log(`shifted header ${JSON.stringify(handler)}`);
        });
      next();
    },
  };
};

Ok schauen wir uns den Code mal an.

const mockHeaderPrefix = config?.mockHeaderPrefix || 'MOCK_AUTH_';
  Object.keys(handler.event.headers)
    .filter((headerKey) => {
      return headerKey.startsWith(mockHeaderPrefix);
      ...

Ich filtere also alle Headers die mit einem bestimmten Prefix beginnen. Falls keiner gesetzt wurde verwende ich MOCK_AUTH.

const headerValue = handler.event.headers[headerKey] || 'martin';
  handler.event.requestContext = handler.event.requestContext ?? {};
  handler.event.requestContext.authorizer = handler.event.requestContext.authorizer ?? {};
  handler.event.requestContext.authorizer.claims = handler.event.requestContext.authorizer.claims ?? {};
  handler.event.requestContext.authorizer.claims[
    headerKey.substring(mockHeaderPrefix.length).replace(/&/g, ':')
  ] = headerValue;

Dann werden die Headers in den Authorizer Claims Bereich kopiert welche auch die Cognito Values enthalten würden. Somit steht meiner Lambda z.B. der authentisierte User und Rolle zu Verfügung. Wie nun die MOCK_AUTH_ Header gesetzt werden können zeige ich im nächsten Abschnitt.

Am Schluss mit .replace(/&/g, ':') findet noch ein kleines Symbol Replacing statt da Postman es leider nicht erlaubt Doppelpunkte : im Header Key zu verwenden.

Lambda Unit Tests

Für meine Lambdas habe ich Unit Tests geschrieben die auch die Authorisation mitberücksichtigen sollen. Aus meinem Code picke ich mir eine Unit Test Datei auf GitHub heraus und erkläre diese genauer.

...
it('from himself will success', async (done) => {
  awsSdkPromiseResponse.mockReturnValueOnce({ Items: [{ instanceId: 'i123', userId: 'martin' }] });
  await handler(
    {
      headers: {
        'MOCK_AUTH_cognito:username': 'martin',
        'MOCK_AUTH_cognito:groups': 'Admin',
      },
      queryStringParameters: { userId: 'martin' },
    },
    {} as Context,
    (_, result) => {
      expect(result?.statusCode).toBe(200);
      ...

Also wie wir hier sehen verwende ich den Mock Header MOCK_AUTH_cognito:username': 'martin' und 'MOCK_AUTH_cognito:groups': 'Admin' . Damit simuliere ich einfach das Authorisationsverhalten von Cognito und mache den Usernamen und die Usergruppen zur Laufzeit der Lambda bekannt. Fair enough.

Postman Tests

Natürlich sollen auch meine Postmantests den neuen Auth Mock Layer nutzen können. Auf GitHub habe ich eine Postman Collection mit über 40 Requests. Die gesamte Collection wird mittels Newman nach dem Bau der DEV Umgebung als Integrationtest ausgeführt:

  ...
  testCommands: (stageAccount) => [
    ...(stageAccount.stage === "dev"
      ? [
          `npx newman run test/alf-cdk.postman_collection.json --env-var baseUrl=$RestApiEndPoint -r cli,json --reporter-json-export tmp/newman/report.json --export-environment tmp/newman/env-vars.json --export-globals tmp/newman/global-vars.json; RESULT=$? || \,
          ./scripts/cleanup.sh
          exit $RESULT`,
        ]
      : []),
  ],
  ...

Um nun den Mock Auth Layer zu nutzen müssen einfach die Header gesetzt werden, wie auch schon bei den Unit Tests im vorherigen Abschnitt:

MOCK_AUTH_cognito&username = martin
MOCK_AUTH_cognito&groups = Admin

Aber eine Änderung musste ich vornehmen. Postman erlaubt es nicht einen Doppelpunkt im Header Key zu haben. Also musste ich dafür ein Symbol Replacing einbauen. Das UND Zeichen & wird im Code zum Doppelpunkt : übersetzt.

Falls dich das Thema Testen mit CDK interessiert kann ich dir meinen Blog Post von letzter Woche empfehlen.

Zusammenfassung

AWS Cognito ist mega cool und schnell aufgebaut. Es ermöglicht eine Palette von tollen User Verwaltungs Funktionen. Leider ist es nicht möglich den Cognito Authorisationsprocess komplett automatisiert z.B. für automatische Tests durchzuführen. Aber das macht nichts da ich mit meinem Auth Mock Layer einfach die Authorisation von Cognito simuliere. Nun zu euch. Hat euch der Beitrag gefallen? Wollt ihr mehr wissen? Sagt mir Bescheid.

Werde ein Patreon!

AWS CDK - PipelineApp Library - Automated Testing

Mon, 09 Nov 2020 00:00:00 GMT

Hi CDK Fans,

Kürzlich erst veröffentlichte ich einen Blogpost über die AWS CDK PipelineApp Library an der ich arbeite. Falls euch das Thema AWS CDK Pipeline interessiert sollten ihr unbedingt diesen Blogpost lesen! Mittlerweile habe ich die Library schon dutzende Male in meinen Projekten verwendet und somit auch weiterentwickelt.

In diesem Post möchte ich gerne darauf eingehen wie man mit meiner Library automatisierte Tests mit der Pipeline ausführen kann.

Übrigens meine CDK Library kann direkt genutzt werden via npm Dependency und erfordert kein npm Repository. Einfach die Dependency folgendermaßen angeben:

 "dependencies": {
    "alf-cdk-app-pipeline": "github:mmuller88/alf-cdk-app-pipeline#v0.0.8",
    ...
 }

Wofür testen wir?

Im Zeitalter der schnellen Releases zu Produktion ist es unerlässlich automatisierte Tests während dem Releaseprozess in der Pipeline durchzuführen. Damit wird sichergestellt, dass alte und neue Features immer noch funktionieren.

Cloudformation Stack Tests

Schon im letzten Blogpost habe ich meinen Ec2 Stack vorgestellt. Nun möchte ich genauer auf den Test Part im testCommands Property eingehen.

const pipelineAppProps: PipelineAppProps = {
  branch: 'master',
  ...
  testCommands: (stageAccount) => [
    `curl -Ssf $InstancePublicDnsName
    aws cloudformation delete-stack --stack-name itest123 --region ${stageAccount.account.region}`,
  ],
};

Mit dem Command curl -Ssf $InstancePublicDnsName teste ich ob die Ec2 Instanz erfolgreich gestartet ist. Danach findet ein Cleanup statt mit Verwendung der AWS CLI. Dadurch das die Commands als eine Liste von Strings string[] übergeben werden und sequenziell abgearbeitet wird kann der Cleanup nach dem curl Befehl noch stattfinden bevor die Teststage den nächsten Command abarbeitet oder ein Fail zurückgibt.

Die Variable $InstancePublicDnsName wurde im Ec2 Stack definiert und explizit in die Test Command gerendert. Wie es definiert wurde siehst du hier:

const instancePublicDnsName = new CfnOutput(this, 'InstancePublicDnsName', {
  value: instance.instancePublicDnsName
});
this.cfnOutputs['InstancePublicDnsName'] = instancePublicDnsName;

API Gateway Tests

In meinem AWS API GW Stack lasse ich Postman Tests laufen. Es sind mittlerweile mehr als 40 Requests die gegen das API GW laufen und das Backend ausgiebig testen. Wenn dich Postman Tests interessieren findest du auf meiner Blogseite viele Beiträge über das Thema auf https://martinmueller.dev/tags/postman .

const pipelineAppProps: PipelineAppProps = {
  branch: 'master',
  ...
  testCommands: (stageAccount) => [
    ...(stageAccount.stage === 'dev'? [
      `npx newman run test/alf-cdk.postman_collection.json --env-var baseUrl=$RestApiEndPoint -r cli,json --reporter-json-export tmp/newman/report.json --export-environment tmp/newman/env-vars.json --export-globals tmp/newman/global-vars.json
      aws cloudformation describe-stacks --query "Stacks[?Tags[?Key == 'alfInstanceId'][]].StackName" --region ${stageAccount.account.region} --output text |
      awk '{print $1}' |
      while read line;
      do aws cloudformation delete-stack --stack-name $line --region ${stageAccount.account.region};
      done`,
    ] : []),
  ],
};

Mit dem CLI Tool newman kann die Postman Collection, welche die mehr als 40 Requests Tests enthält, ausgeführt werden. Ab aws cloudformation ... erfolgt auch hier ein Aufräumen von allen übrig gebliebenen Cloudformation Stacks.

Zusammenfassung

Es fühlt sich an, dass meine AWS CDK Pipeline Library nützlicher und robuster wird. Mit jedem neuen Projekt von mir schleife ich etwas an ihr und sie wird somit ein Stück ausgefeilter. Ich bin sehr gespannt wo die Reise mit meiner Library noch hingehen wird.

Werde ein Patreon!

AWS CDK - PipelineApp - Eine Library für Staging Pipelines

Sat, 24 Oct 2020 00:00:00 GMT

Hi CDK Fans,

Das Bauen von AWS CDK Pipelines macht Spaß. Seit Mitte diesen Jahres (2020) gibt es sogar eine High Level CDK Pipeline welche viele Vorteile bringt wie self-mutate, ein vereinfachtes Cross-Account Deployment und eine bessere Abstraktion von den benötigten CodeBuild Projekten.

Ich habe eine CDK Library entwickelt die einige Probleme Lösen soll. Wenn auch ihr auf nur einer der folgenden Probleme stoßt, müsste ihr euch unbedingt den gesamten Post durchlesen :) :

Maintaining der CDK Dependencies zwischen mehreren Repositories
Wiederholung von Code für den Bau von CDK Apps nur um z.B. einen beliebigen Stack zu deployen
Wiederholung von CDK Pipeline Code
Vermissen eines einheitlichen CDK Pipeline Standards über z.B. einem Interface

In den nächsten Abschnitten geht es um diese allgemeine Library und wie ich diese Probleme löse. Zuerst beschreibe ich wozu man überhaupt eine Pipeline braucht. Dann erkläre ich genauer die Idee hinter der Library und zum Schluss zeige ich einige Beispiele meiner Projekte welche bereits die Library verwenden.

Übrigens meine CDK Library kann direkt genutzt werden via npm depedency und erfordert kein npm Repository. Einfach die Dependency folgendermaßen angeben:

 "dependencies": {
    "alf-cdk-app-pipeline": "github:mmuller88/alf-cdk-app-pipeline#v0.0.7",
    ...
 }

Wozu überhaupt eine Pipeline?

In Zeiten von modernen DevOps Praktiken ist es wichtig Änderungen in der Produktion so schnell und einfach wie möglich durchzuführen. Idealerweise geschieht das basierend auf Git Code Commits und einer Staging Pipeline. Eine Staging Pipeline führt Anpassungen auf Stages aus.

In meiner Firma haben wir die vier Stages DEV, QA, PROD. Die DEV Stage ist als Entwicklungsumgebung für die Entwickler gedacht. Die QA Stage ist eine Testumgebung die möglichst ähnlich der PROD Umgebung ist. Und PROD selber ist natürlich die Produktionsumgebung welche aktiv von der Firma und unseren Kunden verwendet wird.

Zum besseren Verständniss benutze ich in den nächsten Abschnitten aber nur eine DEV, PROD Stage. Die PipelineApp Library lässt sich um beliebig viele Stages erweitern.

Anforderungen

Meine CDK Pipeline Library soll einige Anforderungen erfüllen die nach Außen über ein Interface implementiert sind. Hier ist das Interface implementiert mit den PipelineAppProps für die PipelineApp Klasse in der Library:

const pipelineAppProps: PipelineAppProps = {
  branch: 'master',
  repositoryName: 'alf-cdk-ui',
  stageAccounts: [
    {
      account: {
        id: '123...',
        region: 'eu-central-1',
      },
      stage: 'dev',
    },
    {
      account: {
        id: '987...',
        region: 'eu-central-1',
      },
      stage: 'prod',
    },
  ],
  buildAccount: {
    id: '555...',
    region: 'eu-central-1',
  },
  customStack: (scope, account) => {

    const alfCdkSpecifics = {
      ...(account.stage === 'dev' ? {
        hostedZoneId: 'Z08...',
        domainName: 'i.dev.alfpro.net',
        certArn: 'arn:aws:acm:eu-central-1:123...:certificate/d40cd852-5bbf-4c1d-9a18-2d96e5307b4c',
      }
       : // prod
      {
        hostedZoneId: 'Z003...',
        domainName: 'i.alfpro.net',
        certArn: 'arn:aws:acm:eu-central-1:987...:certificate/4fe684df-36da-4516-bd01-7fcc22337dff',
      })
    }

    return new AlfCdkEc2Stack(scope, `${name}-${account.stage}`, {
      env: {
        account: account.id,
        region: account.region,
      },
      gitRepo: 'alf-ec2-1',
      tags,
      customDomain: {
        hostedZoneId: alfCdkSpecifics.hostedZoneId,
        domainName: alfCdkSpecifics.domainName,
        certArn: alfCdkSpecifics.certArn,
      },
      stackName: 'itest12',
      stage: account.stage,
    })
  },
  testCommands: (_) => [
    'sleep 240',
    `curl -Ssf $InstancePublicDnsName && aws cloudformation delete-stack --stack-name itest123 --region ${account.region}`,
  ],
};

// tslint:disable-next-line: no-unused-expression
new PipelineApp(pipelineAppProps);

In den nächsten Unterabschnitten erläutere ich genauer die einzelnen Properties.

Git Repository

Die PipelineApp soll ihre Stages basierend auf Git Repositories deployen. Dafür ist es notwendig das Repository und den Branch zu definieren:

const pipelineAppProps: PipelineAppProps = {
  branch: 'master',
  repositoryName: 'alf-cdk-ui',
  ...

Der repositoryName bezieht sich auf den Namen in meinem Repository auf Github z.B. https://github.com/mmuller88/alf-cdk-ui . Über die Pipeline wird mittels eines Tokens dieses Repository gepullt und als Source definiert.

Verwalten von Stages

Es soll möglich sein zu spezifischen AWS Accounts in der jeweiligen Stage zu connecten. Die Spezifikation über den Account und der Stage soll als Parameter mitgegeben werden. Ich entwickelte das folgende Interface:

stageAccounts: [
  {
    account: {
      id: '123..',
      region: 'eu-central-1',
    },
    stage: 'dev',
  },
  {
    account: {
      id: '987...',
      region: 'eu-central-1',
    },
    stage: 'prod',
  },
],

Hier wird eine Liste von Stage Accounts übergeben in die die Pipeline die Stacks deployen wird. Zusätzlich wird mit dem stage property der Name der Stage festgelegt. Die Reihenfolge der Accounts bestimmt auch die Reihenfolge in der das Staging durchgeführt wird. In diesem Beispiel wird also zuerst die DEV Stage durchlaufen und dann Die PROD Stage.

Der Buildaccount definiert den Account indem die CDK Pipeline deployed werden soll.

buildAccount: {
  id: '555...',
  region: 'eu-central-1',
},

In dem Build Account können auch wichtige Secret mit dem Secret Manager oder dem Parameter Store definiert werden wie z.B. das GitHub Token. In dem Pipeline Stack kann dann dort auf diese Secrets zugegriffen werden.

Ein oder mehrere Stacks

Die Pipeline soll in der Lage sein ein oder mehrere Stacks zu deployen und in diesige zu integrieren. Die Stackdefinition soll dabei im jeweiligen Repository liegen und kann dann einfach der Library als Higher Order Function übergeben werden:

customStack: (scope, account) => {

    const alfCdkSpecifics = {
      ...(account.stage === 'dev' ? {
        hostedZoneId: 'Z08...',
        domainName: 'i.dev.alfpro.net',
        certArn: 'arn:aws:acm:eu-central-1:123...:certificate/d40cd852-5bbf-4c1d-9a18-2d96e5307b4c',
      }
       : // prod
      {
        hostedZoneId: 'Z00371764UBVAUANTU0U',
        domainName: 'i.alfpro.net',
        certArn: 'arn:aws:acm:eu-central-1:987...:certificate/4fe684df-36da-4516-bd01-7fcc22337dff',
      })
    }

    return new AlfCdkEc2Stack(scope, `${name}-${account.stage}`, {
      env: {
        account: account.id,
        region: account.region,
      },
      gitRepo: 'alf-cdk-ec2',
      tags,
      customDomain: {
        hostedZoneId: alfCdkSpecifics.hostedZoneId,
        domainName: alfCdkSpecifics.domainName,
        certArn: alfCdkSpecifics.certArn,
      },
      stackName: 'itest12',
      stage: account.stage,
    })
  },

Der hier aufgezeigte Stack befindet sich im alf-cdk-ec2 Repo mit alf-cdk-ec2-stack.ts als File. Der Stack wird in der app.ts zusammen mit der PipelineApp Library aufgerufen.

Dank der High Order Function können Account Informationen einfach als Parameter mittels account in den jeweiligen Stage Stack integriert werden.

Library Beispiele

In diesem Abschnitt möchte ich einige Verbraucher der PipelineApp Library zeigen.

Alf CDK UI React Frontend

Das erste Beispiel handelt von einem Frontend Stack welcher eine statische Website baut. Die Technologien die ich hier verwende sind React im TypeScript Flavor. Die statische Seite wird gehostet in einem S3 Bucket mit einer davor geschalteten Cloudfront Distribution.

Der gesamte Code ist auf GitHub alf-cdk-ui. Im Rootverzeichniss befindet sich die React App. Im cdk folder sind alle relevanten CDK parts zu finden. Darunter das UIStack in ui-stack.ts Construct und die PipelineApp in app.ts. Die PipelineApp wird folgendermaßen aufgerufen:

import { UIStack } from './ui-stack';
import { name } from './package.json';
import { PipelineApp } from 'alf-cdk-app-pipeline/pipeline-app';
import { sharedDevAccountProps, sharedProdAccountProps } from 'alf-cdk-app-pipeline/accountConfig';


// tslint:disable-next-line: no-unused-expression
new PipelineApp({
  branch: 'master',
  repositoryName: name,
  stageAccounts: [
    {
      account: {
        id: '123...',
        region: 'eu-central-1',
      },
      stage: 'dev',
    },
    {
      account: {
        id: '123...',
        region: 'us-east-1',
      },
      stage: 'prod',
    },
  ],
  buildAccount: {
    id: '123...',
    region: 'eu-central-1',
  },
  customStack: (scope, account) => {
    const stageProps = {
      ...(account.stage === 'dev' ? {
        domainName: sharedDevAccountProps.domainName,
        acmCertRef: sharedDevAccountProps.acmCertRef,
        subDomain: sharedDevAccountProps.subDomain,
        hostedZoneId: sharedDevAccountProps.hostedZoneId,
        zoneName: sharedDevAccountProps.zoneName,
      } : { // prod stage
        domainName: sharedProdAccountProps.domainName,
        acmCertRef: sharedProdAccountProps.acmCertRef,
        subDomain: sharedProdAccountProps.subDomain,
        hostedZoneId: sharedProdAccountProps.hostedZoneId,
        zoneName: sharedProdAccountProps.zoneName,
      })
    };
    // console.log('echo = ' + JSON.stringify(account));
    return new UIStack(scope, `${name}-${account.stage}`, {
      stackName: `${name}-${account.stage}`,
      stage: account.stage,
      domainName: stageProps.domainName,
      acmCertRef: stageProps.acmCertRef,
      subDomain: stageProps.subDomain,
      hostedZoneId: stageProps.hostedZoneId,
      zoneName: stageProps.zoneName,
    })
  },
  buildCommand: 'make distcdk',
  manualApprovals: (account) => {
    return account.stage === 'dev' ? false : true;
  },
  testCommands: (_) => [
    // Use 'curl' to GET the given URL and fail if it returns an error
    'curl -Ssf $domainName',
    'echo done!!!',
  ],
});

Wie man hier sieht verwende ich für die zwei Stages dev und prod den gleichen Account. Es wäre auch möglich unterschiedliche Accounts zu verwenden. Es muss dann nur darauf geachtet werden das beim CDK Bootstrap befehl dem jeweiligen Account getrustet wird! Interessant ist das ich hier den default buildCommand überschreibe. Die Motivation dafür ist ein Finetuning bei der Builderstellung der React App um diesen schneller zu bekommen.

Der wohl interessanteste Bereich ist das customStack Property bzw. die High Order Function. Hier wird nämlich der Stack definiert welcher von der PipelineApp verwaltet werden soll. Das ist ziemlich cool weil so die Stack Definition im UI Repo bleiben kann ich aber nur trotzdem minimal Code für die PipelineApp Library importieren muss.

Ein wichtiger Punkt für die so definierten Stack wie z.B. der UIStack. Diese sind nur erlaubt die aws-cdk Dependencies wie z.B.:

import { StackProps, Construct, CfnOutput, RemovalPolicy } from '@aws-cdk/core';

nur indirekt aus der PipelineApp Library laden. Das ist aber eher ein Vorteil als Nachteil da so nur noch die aws-cdk dependencies in der PipelineApp Library selbst verwaltet werden müssen. Und mit einer vernünftigen Tagging Strategie kann man aws-cdk Updateprobleme vermeiden!

Der Build Command kann optional auch überschrieben werden. Hier tue ich das zum Beispiel mit make distcdk . In den Projekten verwende ich Makefiles da diese hervorragend sind zum kapseln von Commands. Mit Makefiles habe ich auch eine schöne Übersicht von den möglichen und gewünschten Commands.

Am Schluss wird über das testCommands Property noch ein Erreichbarkeitstest durchgeführt. Der Parameter $domainName wurde im Stack so definiert:

this.domainName = new CfnOutput(this, 'domainName', {
  value: route.domainName,
});
this.cfnOutputs['domainName'] = this.domainName;

Diese Notation muss so eingehalten werden, damit die PipelineApp Library nachdem Stack Deployment die Stack Output Variablen wiederfinden kann.

Alf CDK Ec2 Backend

Das nächste Beispiel befindet sich in Github auf alf-cdk-ec2. Hier kreiere ein Alfresco Deployment basierend auf Docker Compose, Ec2 und CDK als Infrastrucktur Orchestrierer. Näheres könnte ihr gerne im Blog Post ACS Infrastruktur erstellen leichtgemacht mit AWS CDK nachlesen.

const pipelineAppProps: PipelineAppProps = {
  branch: 'master',
  repositoryName: name,
  stageAccounts: [
    {
      account: {
        id: '123...',
        region: 'eu-central-1',
      },
      stage: 'dev',
    },
  ],
  buildAccount: {
    id: '123...',
    region: 'eu-central-1'
  },
  customStack: (scope, account) => {
    // console.log('echo = ' + JSON.stringify(account));
    const tags = JSON.parse(process.env.tags || '{}');

    const alfCdkSpecifics = {
      ...(account.stage === 'dev' ? {
        hostedZoneId: process.env.hostedZoneId || 'Z08...',
        domainName: process.env.domainName || 'i.dev.alfpro.net',
        certArn: process.env.certArn || 'arn:aws:acm:eu-central-1:123...:certificate/d40cd852-5bbf-4c1d-9a18-2d96e5307b4c',
      }
       : // prod
      {
        hostedZoneId: process.env.hostedZoneId || 'Z003...',
        domainName: process.env.domainName || 'i.alfpro.net',
        certArn: process.env.certArn || 'arn:aws:acm:us-east-1:123...:certificate/09d5c91e-6579-4189-882b-798301fb8fba',
      })
    };

    return new AlfCdkEc2Stack(scope, `${name}-${account.stage}`, {
      env: {
        account: account.id,
        region: account.region,
      },
      gitRepo: process.env.gitRepo || 'alf-cdk-ec2',
      tags,
      customDomain: {
        hostedZoneId: alfCdkSpecifics.hostedZoneId,
        domainName: alfCdkSpecifics.domainName,
        certArn: alfCdkSpecifics.certArn,
      },
      stackName: process.env.stackName || `itest123`,
      stage: account.stage,
    })
  },
  testCommands: (account) => [
    `aws ec2 get-console-output --instance-id $InstanceId --region ${account.region} --output text`,
    'sleep 180',
    `curl -Ssf $InstancePublicDnsName && aws cloudformation delete-stack --stack-name itest123 --region ${account.region}`,
  ],
};

// tslint:disable-next-line: no-unused-expression
new PipelineApp(pipelineAppProps);

In diesem Beispiel wird nur ein Staging Account definiert

Alf CDK Backend

Das nächste Beispiel befindet sich auch in Github alf-cdk. Es ist ein sehr umfangreicher Stack bestehend aus Cognito, API GW, Lambdas, StepFunction, DynamoDB und mehr. Auch erstellt dieser Stacks andere CDK Stacks mittels einer Lambda Funktion.

import { name } from './package.json';
import { PipelineApp, PipelineAppProps } from 'alf-cdk-app-pipeline/pipeline-app';
import { AlfInstancesStack, AlfInstancesStackProps, alfTypes } from './lib/alf-instances-stack'
import { sharedDevAccountProps, sharedProdAccountProps } from 'alf-cdk-app-pipeline/accountConfig';

const pipelineAppProps: PipelineAppProps = {
  branch: 'master',
  repositoryName: name,
  stageAccounts: [
    {
      account: {
        id: '123...',
        region: 'eu-central-1',
      },
      stage: 'dev',
    },
    {
      account: {
        id: '987...',
        region: 'us-east-1',
      },
      stage: 'prod',
    },
  ],
  buildAccount: {
    id: '123...',
    region: 'eu-central-1'
  },
  customStack: (scope, account) => {
    // values that are differs from the stages
    const alfCdkSpecifics = {
      ...(account.stage === 'dev' ? {
        domain: {
          domainName: `api.${sharedDevAccountProps.zoneName.slice(0,-1)}`,
          zoneName: sharedDevAccountProps.zoneName,
          hostedZoneId: sharedDevAccountProps.hostedZoneId,
          certificateArn: `arn:aws:acm:us-east-1:${account.id}:certificate/f605dd8c-4ae3-4c1b-9471-4b152e0f8846`
        },
        createInstances: {
          enabled: true,
          imageId: 'ami-0ea3405d2d2522162',
          minutes: 5,
          maxPerUser: 2,
          maxInstances: 3,
          domain: {
            domainName: `i.${sharedDevAccountProps.zoneName.slice(0,-1)}`,
            hostedZoneId: 'Z0847928PFMOCU700U4U',
            certArn: `arn:aws:acm:eu-central-1:${account.id}:certificate/d40cd852-5bbf-4c1d-9a18-2d96e5307b4c`,
          }
        },
        swagger: {
          domain: {
            domainName: sharedDevAccountProps.domainName,
            certificateArn: sharedDevAccountProps.acmCertRef,
          }
        },
        auth: undefined,
      } : { // prod stage
        domain: {
          domainName: `api.${sharedProdAccountProps.zoneName.slice(0,-1)}`, // 'api.alfpro.net',
          zoneName: sharedProdAccountProps.zoneName,
          hostedZoneId: sharedProdAccountProps.hostedZoneId,
          certificateArn: `arn:aws:acm:us-east-1:${account.id}:certificate/62010fca-125e-4780-8d71-7d745ff91789`
        },
        createInstances: {
          enabled: false,
          imageId: 'ami-01a6e31ac994bbc09',
          minutes: 45,
          maxPerUser: 2,
          maxInstances: 50,
          domain: {
            domainName: `i.${sharedProdAccountProps.zoneName.slice(0,-1)}`,
            hostedZoneId: 'Z00371764UBVAUANTU0U',
            certArn: `arn:aws:acm:eu-central-1:${account.id}:certificate/4fe684df-36da-4516-bd01-7fcc22337dff`,
          }
        },
        swagger: {
          domain: {
            domainName: sharedProdAccountProps.domainName,
            certificateArn: sharedProdAccountProps.acmCertRef,
          }
        },
        auth: {
          cognito: {
            userPoolArn: `arn:aws:cognito-idp:us-east-1:${account.id}:userpool/us-east-1_8c1pujn9g`,
            scope: 'aws.cognito.signin.user.admin'
          }
        },
      }),
    }
    // console.log('echo = ' + JSON.stringify(account));
    const alfInstancesStackProps: AlfInstancesStackProps = {
      environment: account.stage,
      env: {
        region: account.region,
        account: account.id
      },
      stage: account.stage,
      stackName: `${name}-${account.stage}`,
      domain: alfCdkSpecifics.domain,
      createInstances: {
        enabled: alfCdkSpecifics.createInstances.enabled,
        imageId: alfCdkSpecifics.createInstances.imageId,
        alfTypes,
        automatedStopping: {
          minutes: alfCdkSpecifics.createInstances.minutes
        },
        allowedConstraints: {
          maxPerUser: alfCdkSpecifics.createInstances.maxPerUser,
          maxInstances: alfCdkSpecifics.createInstances.maxInstances,
        },
        domain: alfCdkSpecifics.createInstances.domain,
      },
      executer: {
        rate: 'rate(1 minute)'
      },
      swagger: {
        file: 'templates/swagger_validations.yaml',
        domain: {
          domainName: alfCdkSpecifics.swagger.domain.domainName,
          subdomain: 'openapi',
          certificateArn: alfCdkSpecifics.swagger.domain.certificateArn,
        }
      },
      auth: alfCdkSpecifics.auth,
    };

    return new AlfInstancesStack(scope, `${name}-${account.stage}`, alfInstancesStackProps);
  },
  manualApprovals: (account) => {
    return account.stage === 'dev' ? false : true;
  },
  testCommands: (account) => [
    ...(account.stage==='dev'? [
      `npx newman run test/alf-cdk.postman_collection.json --env-var baseUrl=$RestApiEndPoint -r cli,json --reporter-json-export tmp/newman/report.json --export-environment tmp/newman/env-vars.json --export-globals tmp/newman/global-vars.json`,
      'echo done! Delete all remaining Stacks!',
      `aws cloudformation describe-stacks --query "Stacks[?Tags[?Key == 'alfInstanceId'][]].StackName" --region ${account.region} --output text |
      awk '{print $1}' |
      while read line;
      do aws cloudformation delete-stack --stack-name $line --region ${account.region};
      done`,
    ] : []),
  ],
};

// tslint:disable-next-line: no-unused-expression
new PipelineApp(pipelineAppProps);

Wie ihr seht ist das ein sehr umfangreicher Stack mit vielen Eingangs Properties. In Zukunft werde ich diesen riesen Stack eventuell etwas mehr runterbrechen. Dieses Beispiel ist in erster Linie interessant da es am Schluss ein umfangreiches Testen mit Postman und der AWS CLI macht. Das Property testCommands führt also für die DEV Stage Postman Tests aus mit:

npx newman run test/alf-cdk.postman_collection.json --env-var baseUrl=$RestApiEndPoint -r cli,json --reporter-json-export tmp/newman/report.json --export-environment tmp/newman/env-vars.json --export-globals tmp/newman/global-vars.json`

Dann löscht es alle womöglich verbliebenen CDK Stacks die durch die Tests entstanden sind mit:

aws cloudformation describe-stacks --query "Stacks[?Tags[?Key == 'alfInstanceId'][]].StackName" --region ${account.region} --output text |
awk '{print $1}' |
while read line;
  do aws cloudformation delete-stack --stack-name $line --region ${account.region};
done`,

Zusammenfassung

CDK Codepipelines sind super cool. Allerdings auch super kompliziert bzw. komplex. Diese ganze Komplexität möchte man nicht jedesmal aufs neue bewältigen müssen nur um Stacks in eine Stagingpipeline zu pressen. Es sollte also eine gute Abstraktion zu diesen Stagingpipelines geben.

In diesem Artikel habe ich eine solche Abstraktion in Form einer Library vorgestellt. Ich betreibe damit bereits einige CDK Stacks, welche hier zum vorgestellt wurden.

Diese Library kann bisher nur auf Repositories in meinem Github Account zugreifen. Es wäre möglich die Library allgemeiner zu gestalten um auf beliebige Git Repositories zugreifen zu können. Wenn ihr das als nützlich anseht, sagt mir Bescheid. Jetzt bin ich aber neugierig. Was haltet ihr von meiner PipelineApp Library? Was kann ich verbessern? Lasst es mich wissen.

Werde ein Patreon!

AWS CDK Let's build a Platform - Api Gateway

Sun, 13 Sep 2020 00:00:00 GMT

Hi CDK Fans,

Willkommen zurück zu meiner kleinen Serie "AWS CDK Let's build a platform". In der vorherigen Folge AWS CDK Let's build a Platform - Frontend habe ich erklärt wie wir für meine Firma unimed.de ein cooles static React Web App mit AWS CDK bauen.

AWS CDK ist ein Framework zur Erstellung und Anwendung von Cloudformation Templates. Dabei kann man zwischen gängigen Programmiersprachen wie Java, Python oder TypeScript auswählen. Wir haben uns für TypeScript entschieden. Wenn du mehr über AWS CDK wissen möchtest empfehle ich dir meine anderen Posts hier in meinem Blog wie z.B. cdk-example.

In dieser Folge soll es um das AWS Api Gateway gehen welches von der Frontend Applikation benutzt wird um z.B. interne Daten abzufragen oder zu speichern.

Api Gateway

Das AWS Api Gateway ist das Herzstück vieler AWS Deployments. Es ist ein Rest Api zum verarbeiten von Requests und den darauf folgenden Responses. Sollen zum Beispiel interne Daten erfragt werden könnte das mit diesem Request gemacht werden:

GET https://example.com/users

Der Response Body könnte dann folgender Maßen aussehen:

[
    {"user":"Alice", "age":18},
    {"user":"Bob", "age":19}
]

Das Api Gateway nimmt also ein Request entgegen, leitet es zu einer Integration weiter und gibt dann einen Response zurück. Die Integration kann dabei aus verschieden Technologien gewählt werden wie z.B. Mock, HTTP Proxy, Lambda Proxy oder anderen AWS Services. Bei der Erstellung des API Gateways haben wir uns für die Variante mit der openApi Spezifikation entschieden. Darüber hab ich ja schon in einem vorherigen Post geschrieben und empfehle Euch den zu lesen.

Kurz zusammengefasst bietet die Verwendung einer openApi Spezifikation einige Vorteile wie Schema Validierung der Request Parameter sowie einer tollen Dokumentation über die zu erwartenden Responses und möglichen Fehlermeldungen. Insbesondere bei der Verwendung einer NoSQL Datenbank wie DynamoDB ist die Validierung der Request Parameter extrem wichtig da ja die Datenbank selber kein Schema vorgibt! Und so sieht ein openApi Api Gateway in CDK aus:

const api = new SpecRestApi(this, this.stackName, {
    apiDefinition: ApiDefinition.fromAsset(join(__dirname, './path/to/api-gw.yaml')),
});

Die openApi Spezifikation hier mit Namen api-gw.yaml könnte zum Beispiel so ausehen:

openapi: "3.0.1"
info:
  title: "example-endpoints"
  version: "2020-09-01T13:03:56Z"
paths:
  /enumerations:
    get:
      security:
      x-amazon-apigateway-integration:
        type: "aws_proxy"
        uri: "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:example/invocations"
        passthroughBehavior: "when_no_match"
        httpMethod: "POST"
        credentials: "arn:aws:iam::@@ACCOUNT_ID@@:role/apiRole"
    options:
      responses:
        200:
          description: "200 response"
    ...

Benutzt ihr Lambdas für eure Integrationen könnt ihr auch gleich hier dem Api Gateway erlauben auf eure Lambdas zuzugreifen:

const apiRole = new Role(this, 'apiRole', {
    assumedBy: new ServicePrincipal('apigateway.amazonaws.com'),
});

apiRole.addToPolicy(new PolicyStatement({
    resources: ['*'],
    actions: ['lambda:InvokeFunction'],
}));

Alternative könnte ihr auch bei den Lambdas selbst dem Api Gateway die Permission geben diese aufzurufen.

Teil unsere Staging Pipeline, welche ich in einem der nachfolgenden Parts erläutern möchte, sind Integrationstests die nach jedem commit ausgeführt werden. Zurzeit sind es "nur" Postmantests die via Newman ausgeführt werden:

npx newman run test/postman/example-com.postman_collection.json --env-var baseUrl=http://example.com --env-var keycloakUrl=http://keycloak-dev.example.com  --env-var user=${testUserName} --env-var pass=${testUserPassword} -r cli,json --reporter-json-export tmp/newman/report.json

Die User Credentials werden vorher im Build per secure Environmentvariables gesetze, welche aus AWS SecurityManager geladen werden.

Zusammenfassung

In diesem Teil der "AWS CDK Let's build a Platform" Reihe habe ich euch erklärt wie der Backend Stack grob aussehen könnte. Was ich mit Absicht ausgelassen habe sind die Informationen was hinter dem Api Gateway bzw. den Lambdas kommt. Üblicherweise greift man hier auf Daten aus Speichern zu wie vielleicht DynamoDB oder RDS. Es kann aber auch sein, dass ihr komplexere Verarbeitungsabläufe anstoßen wollt mit AWS Step Functions.

Ein tolles Beispiel wie eine CRUD Implementation mit API Gateway, Lambda und DynamoDB gemacht werden beschreibe ich bereits in einem anderen Post. Hat auch der nächste Teile meiner "AWS CDK Let's build a Platform" Reihe gefallen? Was wollt ihr als nächstes wissen? Lasst es mich wissen.

Werde ein Patreon!

AWS CDK Let's build a Platform - Frontend

Sun, 06 Sep 2020 00:00:00 GMT

Hi CDK Fans,

Da ich die tolle Gelegenheit habe bei dem Bau einer Platform für meine Firma unimed.de zu helfen, will ich euch erklären wie das aussieht. Zurzeit arbeiten wir an einer spannenden Platform zum effizienten Speichern und Auffinden von internen Daten. Meine Hauptverantwortlichkeit liegt dabei in der AWS Infrastruktur.

Unser DevOps Team möchte soviel wie möglich in AWS auslagern. Für die Verwaltung der Ressourcen in AWS nutzen wir AWS CDK. AWS CDK ist ein Framework zur Erstellung und Anwendung von Cloudformation Templates. Dabei kann man zwischen gängigen Programmiersprachen auswählen. Wir haben uns für TypeScript entschieden da auch unser Frontend in TypeScript geschrieben ist und den Vorteil der starken Typendefinition mit sich bringt ohne dabei gefühlt viel an Flexibilität zu verlieren. Wenn du mehr über AWS CDK wissen möchtest empfehle ich dir meine anderen Posts hier in meinem Blog wie z.B. cdk-example.

Das eben erwähnte Frontend ist mit React im TypeScript Flavour implementiert. Ich plane eine mehrteilige Serie über "AWS CDK Let's build a Platform' und in dieser Folge geht es speziell um das Frontend.

React Frontend

Wie schon erwähnt unser Frontend is eine React Browser App im TypeScript Flavor. Sie nutzt das Material Design wo immer es möglich ist. Die Authentifizierung läuft über Keycloak welches an unser firmeninternes Active Directory angeschlossen ist. Nach dem Eingeben der Zugangsdaten kann direkt nach relevanten Daten gesucht und Neue eingefügt werden. Die static App wird mit npm run build in den Ordner build gebaut.

An dieser Stelle möchte ich einen Schwank auf die Infrastruktur machen. Die React Browser App ist eine Static Web App und um diese mittels AWS werden einige AWS Ressourcen benötigt. Diese möchte ich im nächsten Abschnitte Auflisten und wie sie mittel CDK verwaltet werden können.

CDK Stack

Zur Darstellung der static React App wird ein S3 Bucket benötigt, welcher als static Web App Bucket dient:

const bucket = new AutoDeleteBucket(this, props.domainName, {
  bucketName: `${props.subDomain}.${props.domainName}`,
  websiteIndexDocument: 'index.html',
  websiteErrorDocument: 'index.html',
  removalPolicy: core.RemovalPolicy.DESTROY,
});

Ich verwende ein CDK Highlevel Construct mit Namen AutoDeleteBucket welcher sich bei Bedarf selbst löschen kann. Das normale S3Bucket Construct kann die Löschung des Buckets nur durchführen wenn keine Daten in diesem Enthalten sind. Der AutDeleteBucket löscht also erst alle in im enthaltenen Daten und entfernt sich dann selbst. Dieses flexible Verhalten ist durchaus nützlich für Buckets die lediglich als static Web App Container dienen sollen. Der Name des static Web App Buckets bucketName: ${props.subDomain}.${props.domainName} wird üblicherweise nach der Domain vergeben z.B. example.com .

Der S3 Bucket speichert das statische Build und wird mit Cloudfront verbunden:

const cloudFrontOAI = new OriginAccessIdentity(this, 'OAI', {
  comment: `OAI for ${props.domainName} website.`,
});

const cloudFrontDistProps: CloudFrontWebDistributionProps = {
  aliasConfiguration: {
      acmCertRef: props.acmCertRef,
      names: [ `${props.subDomain}.${props.domainName}` ],
      sslMethod: SSLMethod.SNI,
      securityPolicy: SecurityPolicyProtocol.TLS_V1_1_2016,
  },
  originConfigs: [
    {
      s3OriginSource: {
        s3BucketSource: bucket,
        originAccessIdentity: cloudFrontOAI,
      },
      behaviors: [{ isDefaultBehavior: true }],
    },
  ],
  errorConfigurations: [
    {
      errorCode: 404,
      errorCachingMinTtl: 60,
      responseCode: 200,
      responsePagePath: "/index.html"
    }
  ]
};

const cloudfrontDistribution = new CloudFrontWebDistribution(
  this,
  `${props.subDomain}.${props.domainName}-cfd`,
  cloudFrontDistProps
);

Cloudfront ist ein Cloud Distribution Network (kurz: CDN) von AWS welches die static Web Apps überall auf der Welt in den jeweiligen Regionen cashed. Somit wird die Latency während des Ladens auf ein Minimum gehalten.

Um nun selbst den static Web App Build in den S3 Bucket zu laden musst noch ein BucketDeployment Construct erstellt werden:

new BucketDeployment(this, `DeployApp-${new Date().toString()}`, {
  sources: [Source.asset("../build")],
  destinationBucket: bucket,
  distribution: cloudfrontDistribution,
  distributionPaths: ['/'],
});

Auch wird hier im BucketDeployment der Pfad zur Invalidierung der Cloudfront Distribution angegeben. Das sorgt dann für ein Neuladen des Cashes sofern eine neue App deployed wird. Der static Web App build Ordner enthält das Build der React App und wurde vorher mit npm run build erstellt.

Weiterhin wird eine Route 53 Record Resource benötigt um eine Custom Domain (z.B. www.example.com) auf den Cloudfront Endpoint zu zeigen um ein die static Web App mittels URL aufrufbar zu machen:

const zone = HostedZone.fromLookup(this, 'Zone', { domainName: props.domainName });
new ARecord(this, 'SiteAliasRecord', {
  recordName: `${props.subDomain}.${props.domainName}`,
  target: AddressRecordTarget.fromAlias(new CloudFrontTarget(cloudfrontDistribution)),
  zone
});

Und hier ist noch der gesamte Code:

import { StackProps, Construct } from '@aws-cdk/core';
import { AutoDeleteBucket } from '@mobileposse/auto-delete-bucket'
import { BucketDeployment, Source } from '@aws-cdk/aws-s3-deployment';
import {
  CloudFrontWebDistribution,
  CloudFrontWebDistributionProps,
  OriginAccessIdentity,
  SSLMethod,
  SecurityPolicyProtocol
} from '@aws-cdk/aws-cloudfront';
import { ARecord, AddressRecordTarget, HostedZone } from '@aws-cdk/aws-route53';
import { CloudFrontTarget } from '@aws-cdk/aws-route53-targets';
// @ts-ignore
import codedeploy = require('@aws-cdk/aws-codedeploy');
// @ts-ignore
import lambda = require('@aws-cdk/aws-lambda');
// @ts-ignore
import core = require('@aws-cdk/core');


export interface FrontendStackProps extends StackProps {
  stage: string;
  acmCertRef: string;
  domainName: string;
  subDomain: string;
}

export class FrontendStack extends core.Stack {

  constructor(scope: Construct, id: string, props: FrontendStackProps) {
    super(scope, id, props);

    const bucket = new AutoDeleteBucket(this, props.domainName, {
      bucketName: `${props.subDomain}.${props.domainName}`,
      websiteIndexDocument: 'index.html',
      websiteErrorDocument: 'index.html',
      removalPolicy: core.RemovalPolicy.DESTROY,
    });

    const cloudFrontOAI = new OriginAccessIdentity(this, 'OAI', {
      comment: `OAI for ${props.domainName} website.`,
    });

    const cloudFrontDistProps: CloudFrontWebDistributionProps = {
      aliasConfiguration: {
          acmCertRef: props.acmCertRef,
          names: [ `${props.subDomain}.${props.domainName}` ],
          sslMethod: SSLMethod.SNI,
          securityPolicy: SecurityPolicyProtocol.TLS_V1_1_2016,
      },
      originConfigs: [
        {
          s3OriginSource: {
            s3BucketSource: bucket,
            originAccessIdentity: cloudFrontOAI,
          },
          behaviors: [{ isDefaultBehavior: true }],
        },
      ],
      errorConfigurations: [
        {
          errorCode: 404,
          errorCachingMinTtl: 60,
          responseCode: 200,
          responsePagePath: "/index.html"
        }
      ]
    };

    const cloudfrontDistribution = new CloudFrontWebDistribution(
      this,
      `${props.subDomain}.${props.domainName}-cfd`,
      cloudFrontDistProps
    );

    new BucketDeployment(this, `DeployApp-${new Date().toString()}`, {
      sources: [Source.asset("../build")],
      destinationBucket: bucket,
      distribution: cloudfrontDistribution,
      distributionPaths: ['/'],
    });

    const zone = HostedZone.fromLookup(this, 'Zone', { domainName: props.domainName });
    new ARecord(this, 'SiteAliasRecord', {
      recordName: `${props.subDomain}.${props.domainName}`,
      target: AddressRecordTarget.fromAlias(new CloudFrontTarget(cloudfrontDistribution)),
      zone
    });
  }
}

Pipeline

Wir deployen die static React App mittels einer Staging Pipeline. Das bedeutet die App durchläuft die verschieden Stages Dev, QA und Prod. Alle Stages sind separierte Accounts. Somit erreicht man eine erhöhte Sicherheit durch Trennung der Ressourcen. Der Dev Account wird zum testen neuer Features genutzt. Die QA Umgebung dient als nächste Stage.

Ich würde gerne etwas ausführlicher über unsere Staging Pipeline im nächsten Teil der Serie berichten.

Zusammenfassung

Eine Plattform mittels AWS zu bauen ist aufregend und macht Spaß. Die komplette Infrastruktur als Code zu haben ist extrem Vorteilhaft. Es ermöglicht ein ausgeklügeltes Staging von zum Beispiel einer Dev Environment nach QA und dann nach Prod. Des Weiteren dient der Code als Dokumentation über was genau in AWS Deployed wurde und wird. Es ist auch viel weniger fehleranfällig als alles manuelle zusammenklicken zu müssen.

Hier habe ich euch den ersten Teil meiner "AWS CDK Let's build a Platform" Reihe vorgestellt. Ich erkläre welche Ressourcen unsere static Web App in AWS benötigt und wie diese mittels CDK verwaltet werden. Im nächsten Teil werde ich ausführlicher über unsere Staging Pipeline sprechen die quasi überall wiederverwendet wird um CDK Apps durch die verschiedenen Stages Dev, QA und Prod zu schleusen. Ich hoffe euch hat der Artikel gefallen und wenn ihr fragen habt, schreibt mir doch einfach.

Werde ein Patreon!

Alfresco Signaturen mit Sinadura

Fri, 14 Aug 2020 00:00:00 GMT

Gesponsort bei PMGA Tech

Hi Alfrescans.

Digitale Signaturen sind eine der meist genutzten Formen zum Integritätscheck im Internet. Integritätscheck meint hier ob es sich bei dem jeweiligen Dokument um das Originale une damit keine Fälschung oder geänderten Version handelt. Ein Beispiel sind die SSL Zertifikate die zum aufrufen von HTTPS Urls benötigt werden. Dort muss quasi überprüft werden ob das SSL Zertifikat nicht gefälscht ist und das geschieht mit einer digitalen Signatur.

Alfresco bietet keine Signierfunktion ootb, aber mit dem Open Source Addon Sinadura (Repo und Share) kann diese Funktion nachgerüstet werden. Auf YouTube existiert ein kurzes Video über die Signierfunktion von Sinadura. Eine Signierfunktion in Alfresco hat zwei wesentlich Vorteile. Der erste wäre eine erhöhte Sicherheit, da es so fast unmöglich gemacht wird Dokument in Alfresco zu fälschen z.B. durch einen Angreifer der ins System gelangt.

Zweitens könnte somit der normale Use Case Scope, also nur innerhalb einer Firma zu bleiben, verlassen werden und Personen die nicht in der Firma arbeiten wie z.B. Kunden mit ins Content Management System mit einbezogen werden. Durch die Verwendung von Signaturen kann ein verbessertes Vertrauensverhältniss gesichert werden.

In den nächsten Abschnitten möchte ich gerne mehr über das Addon Sinadura erzählen.

Sinadura Addon

Sinadura.net ist ein Open Source Projekt für digital Signatur Software. Dafür läuft normalerweise ein Sinadura Server für den Signatur Check und Erstellung. Ein Client connected sich dann zu dem Sinadura Server.

Sinadura besitzt ein Alfresco Addon Repo in GitHub https://github.com/zylklab/alfresco-sinadura welches bisher allerdings nur mit ACS Community und Enterprise Version 5 funktioniert. Toll wäre es natürlich auch neuere Alfresco Version ggf. mit Docker zu unterstützen. Ich habe es mir also zu Aufgabe gemacht dieses tolle Addon mit ACS 6.2 kompatibel zu machen.

ACS 6.2 Kompatibel

Aktuell basiert das Alfresco Sinadura Addon in https://github.com/zylklab/alfresco-sinadura noch auf SDK 2.2.0 und ACS 5 . Es scheint das SDK 2.2.0 nicht mehr ootb. funktioniert und einige nötige Artefakte im Alfresco Nexus nicht mehr bereitstehen. Nur mir viel Mühe wäre es wohl möglich die Sinadura Amps noch mit SDK 2.2.0 zu kompilieren. Also habe ich mich entschlossen die neuste SDK Version 4.1.0 zu verwenden.

Die Migration, welche ihr in meinem Git Repo findet unter https://github.com/mmuller88/alfresco-sinadura-6X-pmgatech, hat super funktioniert. Wie eine Alfresco SDK 4.1.0 Build gebaut werden kann ist sehr gut beschrieben im offiziellen Alfresco SDK Repo. SDK 4.1.0 basiert stark auf Docker und nutzt Docker Compose als Container Orchestrierer.

Etwas herausfordernd war die Migration der AMP Struktur nach 4.1.0 da einige Datein nun an anderer Stelle platziert werden müssen als noch in 2.2.0 . Die sinaduraCloud war File musste ich in ein eigenständiges Tomcat mit Java 8 packen da Alfresco mit Java 11 läuftgit.

Zusammenfassung

Digitale Signaturen sind ein spannendes Thema und ermöglichen einem Alfresco Document Management System komplett neue Use Cases. Auch interessant könnte der Vorgang des Signierens im Zusammenspiel mit Alfresco Process Service sein.

Vielen Danke für meinen Sponsor www.pmga.tech für die Migrations Arbeiten an Sinadura. Habt ihr spannende Alfresco Projekte an denen ihr arbeitet? Lasst es mich wissen :) !

Werde ein Patreon!

ACS Infrastruktur erstellen leichtgemacht mit AWS CDK

Sun, 26 Jul 2020 00:00:00 GMT

Hi Alfrescans.

Infrastruktur als Code ist in der DevOps schon länger beliebt. Als einer der ersten Vorreiter von IaC (Infrastructure as Code) ist AWS mit Cloudformation. Dazu müssen Cloudformation Templates in JSON oder YAML geschrieben werden. Das funktioniert sehr gut ist aber ein zeitaufwendiger und komplexer Prozess diese Templates zu schreiben.

Mit AWS CDK wurde eine neue Abstraktionsstufe über den Cloudformation Templates geschaffen, welches es so einfach wie noch nie möglich machen, die Infrastruktur für ein lauffähiges ACS bereitzustellen. In den nächsten Abschnitten erkläre ich was AWS CDK eigentlich ist und wie es helfen kann, Infrastruktur für ACS aufzubauen.

Was ist AWS CDK?

CDK steht für Cloud Development Kit und ist ein Open Software Development Framework zum Modellieren und Verwalten von Cloudformation Ressourcen und damit AWS Infrastruktur. AWS CDK synthetisiert zu Cloudformation Templates. Das bedeutet, es werden aus dem CDK Code Cloudformation Templates erstellt. Eine sogenannte CDK App besteht dabei aus einem oder mehreren Cloudformation Stacks. Es unterstützt bekannte Sprachen wie Java, Python, JavaScript oder TypeScript. Für den weiteren Verlauf dieses Artikels verwende ich TypeScript.

Warum ist CDK so toll?

Das tolle an CDK im TypeScript Flavor sind die Typendefinitionen welche ein zügiges vorankommen beim Entwickeln mit der IDEA ermöglicht, da es quasi die Dokumentation dank der Typen mit sich bringt. Ebenfalls werden durch die jahrelangen Erfahrungen mit Cloudformation bereits hervorragende Defaults gesetzt, welche Überschreibungen dieser Defaults selten nötig macht. CDK kümmert sich auch ootb. um den Upload des synthetisierten Cloudformation Template und ggf. Assets in ein S3. Ebenfalls ist das CDK Framework Open Source und falls man doch gerne etwas genauer hinschauen möchte wie CDK arbeitet, ist das einfach in GitHub möglich.

AWS CDK lässt sich also hervorragend verwenden die Infrastruktur für ein ACS 6.2 Deployment bereitzustellen. Nachfolgend erkläre ich die zwei Stacks Ec2 Stack und EKS Stack, welche kreiert mit CDK kreiert wurden.

CDK Constructs

Constructs können entweder low level oder high level sein. Low level Constructs repräsentieren dabei eine Cloudformation Resource. High Level Constructs sind eine Kombination von mehreren low level Constructs. Die ganze CDK App repräsentiert dabei einen Tree an dessen Root die App selbst sind. Danach kommen die high level Constructs und als Blätter sind die low level Constructs. Interessant zu wissen, dass low level Constructs automatisch von Cloudformation Ressourcen generiert werden.

Ein gutes Beispiel dafür ist das high level Construct Vpc aus dem Package @aws-cdk/aws-ec2 welches eine Kombination aus Ressourcen ist wie Vpc, InternetGateway, Cidr oder VpC Iam Role. Die Erstellung des high level VPC Construct sieht folgendermaßen aus:

import { Vpc } from '@aws-cdk/aws-ec2';
import { Stack, App} from '@aws-cdk/core';

class VpcStack extends Stack {
  constructor(app: App, id: string) {
    super(app, id);

    new Vpc(this, 'vpc'); // lediglich diese Zeile
  }
}

const app = new App();
new VpcStack(app, 'VpcStack');

app.synth();

Nur die Zeile new Vpc(this, 'vpc'); ist nötig um ein komplettes public VPC zu definieren. Das Gleiche in einem Cloudformation Template würde 200 Zeilen lang sein! Das wird ermöglicht dadurch das CDK extrem nützliche Default Einstellungen besitzt. Man merkt wie gut dieses Framework durch die Jahre lange Erfahrungen mit Cloudformation profitiert. Möchte man gerne ein private VPC erstellen muss nur ein drittes Parameter Objekt übergeben werden:

new Vpc(this, 'CustomVPC', {
  cidr: '10.0.0.0/16',
  maxAzs: 2,
  subnetConfiguration: [{
    cidrMask: 26,
    name: 'isolatedSubnet',
    subnetType: SubnetType.ISOLATED,
  }],
  natGateways: 0
});

Ec2 Stack

Der Code ist public und im meinem GitHub Repo. Das ACS Deployment wurde mit dem Alfresco Docker Installer generiert und nutzt Docker Compose zur Orchestrierung der ACS Deployment Services. In dem File index.ts ist die CDK App definiert. Falls bisher noch keine CDK Apps deployed wurden muss vorher der CDK Toolkit Stack in der Ziel Region erstellt werden mit:

cdk bootstrap aws://<ACCOUNT-NUMBER>/<REGION>

Anschließend wird der Stack wird mit dem folgenden Befehl deployed:

npm run build && cdk deploy

Wenn alles geklappt hat, sollte die Alfresco Content App kurz ACA auf der public DNS Url erreichbar sein. Z.B.: ec2-34-201-46-76.compute-1.amazonaws.com . Diese Url kannst du direkt aus dem AWS Browser bekommen im EC2 Bereich oder du könntest eine Output Ressource für diese schreiben.

Die CDK App kreiert einen Cloudformation Stack welcher eine Ec2 Instanz hinter einem Application Loadbalancer deployed. Anschließend wird der ACS Deploy Code, der auch im gleichen Repo enthalten ist, auf die Ec2 Instanz kopiert und ACS gestartet. Docker Compose dient dabei als Container Orchestrierer.

Für einfach Entwicklerumgebungen ist das ideal, da sich Docker Compose Templates schnell erstellen lassen und einfach erweiterbar sind. Will man nun aber ein produktionsähnlicheres ACS Deployment erstellen, sollte Kubernetes als Container Orchestrierer verwendet werden.

EKS Stack

EKS steht für Elastic Kubernetes Service und stellt bei Nutzung eine Kubernetes Masternode bereit. Auch werden die Ec2 Workernodes konfiguriert. Im Gegensatz zum Ec2 Stack verwendet der EKS Stack Kubernetes zur Orchestrierung der ACS Deployment Services. Es gibt bereits einige gute Beispiele wie mit CDK ein EKS Deployment erstellt werden kann. Hier findet ihr meinen GitHub Code. Zur Erstellung des Clusters werden folgende Properties benötigt:

const eksCluster = new Cluster(this, 'Cluster', {
  clusterName: this.stackName,
  mastersRole: eksClusterAdmin,
  vpc: vpc,
  kubectlEnabled: true,  // we want to be able to manage k8s resources using CDK
  defaultCapacity: 0,  // we want to manage capacity our selves
  version: KubernetesVersion.V1_17,
});

Ich überschreibe den vom CDK generierten Clusternamen mit clusterName, da dieser nicht leserfreundlich ist. Die masterRole erlaubt meinem IAM User Admin Zugriff zum Cluster. Die Workernode wird dann wie folge definiert:

const onDemandASG = new AutoScalingGroup(this, 'OnDemandASG', {
  vpc: vpc,
  role: workerRole,
  minCapacity: 1,
  maxCapacity: 1,
  instanceType: new InstanceType('t2.large'),
  machineImage: new EksOptimizedImage({
    kubernetesVersion: '1.17',
    nodeType: NodeType.STANDARD  // without this, incorrect SSM parameter for AMI is resolved
  }),
  updateType: UpdateType.ROLLING_UPDATE
});

Um Alfresco per URLs erreichbar zu machen, muss noch der Ingress mit definiert werden. Ich verwende dafür einen Nginx Ingress in AWS Flavour:

new HelmChart(this, 'NginxIngress', {
  cluster: eksCluster,
  chart: 'nginx-ingress',
  repository: 'https://helm.nginx.com/stable',
  namespace: 'kube-system',
  values: {
    'rbac': {
      'create': true
    },
    'controller': {
      'scope': {
        'enabled': true,
        'namespace': acsNamespace
      },
      'config': {
        'force-ssl-redirect': true,
        'server-tokens': false
      },
      'service': {
        'targetPorts': {
          'https': 80
        },
        'annotations': {
          'service.beta.kubernetes.io/aws-load-balancer-backend-protocol': 'http',
          'service.beta.kubernetes.io/aws-load-balancer-ssl-ports': 'https',
          'service.beta.kubernetes.io/aws-load-balancer-ssl-cert': awsCertArn,
          'external-dns.alpha.kubernetes.io/hostname': `${acsNamespace}.eks.alfpro.net`,
          'service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy': awsCertPolicy
        },
        'publishService': {
          'enabled': true
        }
      }
    }
  }
})

Nach erfolgreichen deployen mit

npm run build && cdk deploy

erscheint der folgende Output:

 ✅  AcsEksCluster

Outputs:
AcsEksCluster.ClusterConfigCommand43AAE40F = aws eks update-kubeconfig --name AcsEksCluster --region us-east-1 --role-arn arn:aws:iam::1111122223333:role/AcsEksCluster-eksClusterAdminE955DB57-1H9KJVEE241KS
AcsEksCluster.ClusterGetTokenCommand06AE992E = aws eks get-token --cluster-name AcsEksCluster --region us-east-1 --role-arn arn:aws:iam::1111122223333:role/AcsEksCluster-eksClusterAdminE955DB57-1H9KJVEE241KS

Der aws eks update-config command kann genutzt werden um zu dem Cluster zu connecten und Cluster Konfigurationen mittel kubectl anzuwenden.

Helm 3 Issue

Leider sind bis zum jetzigen Zeitpunkt noch keine der ACS Charts also Community und Enterprise mit Helm 3 kompatibel. Das bedeuted wir können nicht den existierenden HelmChart CDK Constructor verwenden um ACS zu installieren. Alternativ muss also ACS per Helm 2 installiert werden.

Zusammenfassung

AWS CDK ist ein spannendes Framework zur Erstellung von Alfresco Infrastruktur in AWS. CDK synthetisiert zu Cloudformation Templates es müssen also bestehende CI CD Pipelines kaum oder garnicht verändert werden. Dabei ist der Gewinn bei der Verwendung von CDK riesig. Z.B. die Typendefinition verhindert Bugs schon im Editor. Viele Zeilen Code werden gespart und es muss kein oder kaum YAML getemplated werden. Für mich ist CDK der nächste logische Schritt für IaC in AWS. Es gibt mittlerweile sogar die ersten Bemühungen CDK auch in das Terraform Ökosystem zu integrieren, was ich sehr spannend finde. Schreibt mir eure Erfahrungen mit CDK :)!

Werde ein Patreon!

AWS CDK Apps deployed mit Lambda

Sat, 11 Jul 2020 00:00:00 GMT

Ahoi AWS CDK Fans

Beliebig viele Ec2 Instanzen mit einem Lambda zu erzeugen ist kein Problem. Möchte man aber komplexere Deployments wie z.B. LoadBalancer, Securitygroups, Scalingroups, usw. mit einem Lambda erstellen, bieten sich auch hier CDK Apps an. Mit einem Lambda CDK Apps beliebig oft zu deployen ist aber garnicht so einfach und bisher gab es kaum Informationen dazu im Web.

Während eines CDK Meetups habe ich aber den Vorschlag erhalten einfach mal ein CodeBuild Projekt zum erstellen der CDK App via Lambda zu benutzen. Und ja das hat super geklappt. In den nächsten Abschnitten stelle ich vor warum das für mich nützlich ist und wie ich das gemacht habe.

Use Cases

Schon dutzend fach erwähnt auf meiner Blogseite benutze ich CDK zum deployen meine Alfresco Provisioners(auch: CDK Construct Solutions). Alfresco nur auf einer EC2 VM laufen zu lassen funktioniert zwar, ist aber langfristig keine optimale Lösung. Ich wollte gerne auch in der Lage sein einen Loadbalancer und mehrere EC2 Instanzen für einen Alfresco Stack zu starten. In Zukunft will ich auch einen Kubernetes Cluster im Stack integrieren zum Orchestrieren der Instanzen bzw. Pods. Es war also nötig dieses komplexe Deployment zu verwalten und dafür bieten sich CDK Apps perfekt an.

Ein anderer Use Case war für einen Kunden der gerne in der Lage sein wollte, CDK Stacks in verschiedenen Stage Accounts wie Dev, QA, Prod zu deployen. Das ganze sollte orchestriert werden mit CodePipeline. Das Deployment in den anderen Accounts auch mit CDK zu verwalten, liegt auf der Hand. Um das zu erreichen, muss auch ein CodeBuild Projekt, welches direkt CDK Befehle ausführt, erstellt werden. Dieser Use Case unterscheidet sich aber soweit, dass der Stack nicht via Lambda deployed wird, sondern via CodePipeline und CodeBuild.

CDK Deploy via CodeBuild und Lambda

Um nun mittels CDK Stacks deployen zu können, muss ein CodeBuild Projekt erstellt werden. Das Project sieht folgendermaßen aus:

const createInstanceBuild = new Project(scope, 'LambdaBuild', {
    role: createInstanceBuildRole, // role needs all permission for deploying Stacks, accessing S3, logs ...
    source: gitHubSource, 
    buildSpec: codebuild.BuildSpec.fromObject({
    version: '0.2',
    phases: {
        install: {
            commands: [
                'cd src',
                'npm install -g aws-cdk',
                'npm install',
            ],
        },
        build: {
            commands: [
                'npm run build',
                'cdk deploy --require-approval never'
            ]
        },
    },
    }),
    environment: {
        buildImage: codebuild.LinuxBuildImage.STANDARD_4_0,
    },
});

Und so einfach gehts! So können CDK Apps mit CodeBuild innerhalb eines Accounts deployed werden. Willst du allerdings Cross Deploying machen, müssen die commands section nur leicht angepasst werden:

...
phases: {
        install: {
            commands: [
                `aws --profile dev configure set aws_access_key_id $AWS_ACCESS_KEY_ID_DEV`,
                `aws --profile dev configure set aws_secret_access_key $AWS_ACCESS_KEY_ID_DEV`,
                `aws --profile dev configure set region $AWS_ACCESS_KEY_ID_DEV`,
                `aws --profile prod configure set aws_access_key_id $AWS_ACCESS_KEY_ID_PROD`,
                `aws --profile prod configure set aws_secret_access_key $AWS_ACCESS_KEY_ID_PROD`,
                `aws --profile prod configure set region $AWS_ACCESS_KEY_ID_PROD`,
                'cd src',
                'npm install -g aws-cdk',
                'npm install',
            ],
        },
        build: {
            commands: [
                'npm run build',
                'cdk deploy --require-approval never --profile dev'
            ]
        },
    },
}),

Falls du dir gerne vorher die benötigten Stack Änderungen anschauen möchtest, geht das auch ganz einfach mit:

cdk diff --profile dev

Was jetzt noch fehlt ist die Lambda Implementation zur Ausführung des CodeBuild Projektes. Zuerst muss das Lambda erstellt werden:

const createInstanceLambdaRole = new Role(scope, 'createInstanceLambdaRole', {
      assumedBy: new ServicePrincipal('lambda.amazonaws.com'),
      managedPolicies: [ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaBasicExecutionRole')],
    });

    createInstanceLambdaRole.addToPolicy(new PolicyStatement({
      resources: ['*'],
      actions: ['codebuild:StartBuild', 'logs:*']
    }));

new Function(scope, 'createCdkApp', {
    code: new AssetCode('lambda'),
    handler: 'create-cdk-stack.handler',
    runtime: Runtime.NODEJS_12_X,
    environment: {
        PROJECT_NAME: createInstanceBuild.projectName
    },
    role: createInstanceLambdaRole
});

Wie es schon der Lambda CDK Code andeutet, befindet sich im Folder ./lambda die Lambda Funktion:

// lambeda/create-cdk-stack.ts
import AWS = require("aws-sdk");
import { CodeBuild } from "aws-sdk";

var codebuild = new AWS.CodeBuild();

const PROJECT_NAME = process.env.PROJECT_NAME || ''

export const handler = async (event: any = {}): Promise<any> => {
  console.debug("create-cdk-stack event: " + JSON.stringify(event));

  const params: CodeBuild.Types.StartBuildInput = {
    projectName: PROJECT_NAME
  };
  console.debug("params: " + JSON.stringify(params));
  const startBuildResult = await codebuild.startBuild(params).promise();
  console.debug("startBuildResult: " + JSON.stringify(startBuildResult));
}

E voila und kann das Lambda selbstständig CDK Apps deployen.

Zusammenfassung

CDK macht das Erstellen und Verwalten von Stacks einfach. Das ist auch in dynamisch erstellten (z.B. mit einem Lambda) Stacks nützlich! Bei bisherigen Lösungen mussten immer erst Cloudformation Templates erstellt werden um diese anschließend in ein S3 hochladen welches dann als Source für ein Cloudformation Deploy dienen könnte.

Mit der hier vorgestellten Lösung ist das nun nicht mehr notwendig und es kann sich mehr auf die Erstellung der CDK App selbst konzentriert werden. Ein weiterer Vorteil den ich sehr schätzen gelernt zu habe ist, dass ich separat die via Lambda deployten CDK Apps testen kann ohne quasi den kompletten CDK Parent Stack dafür deployen zu müssen. Das kombiniert mit CI CD Pipeline ist der wahrgewordene DevOps Traum!

Werde ein Patreon!

Infrastruktur Optimieren mit CDK Solutions Constructs Teil II.

Sat, 04 Jul 2020 00:00:00 GMT

Hi CDK Fans

Im vorherigen Teil I habe ich das DynamoDB Stream to Lambda Solution Construct in mein Alfresco Provisioner CDK Deployment eingebaut und den Gewinn dadurch diskutiert. Diese Woche habe ich weitere CDK Solutions Constructs integriert. CDK Solutions Constructs sind CDK Constructs welche oft genutzte Cloudformation Pattern kapseln. Näheres darüber kannst du in Teil I lesen.

Cloudfront S3

Zu finden in GitHub ist das das Cloudfront S3 Solution Construct. Es implementiert ein Cloudfront vorangestellt einem S3 Bucket. Dadurch können Dateien performanter verteilt werden, da sie mittels eines Content Delivery Networks gecachet und on the Edge verteilt werden. Mit dem Cloudfront S3 Solution Pattern kommen einige tolle well-architected Aspekte wie z.B. HTTP Security Headers und buckets für CDN und S3 Access Logs.

const { CloudFrontToS3 } = require('@aws-solutions-constructs/aws-cloudfront-s3');

new CloudFrontToS3(stack, 'test-cloudfront-s3', {
    deployBucket: true
});

Ich wollte dieses Pattern verwenden um die S3 Static Webside zu erweitern, da diese bereits ein Cloudfront besitzt. Allerdings unterstützt das Cloudfront S3 Solution Construct keine Static Websides. Deshalb kann ich es leider nicht für meinen Stack benutzen. Egal was zählt ist, dass ich viel über dieses Solution Construct gelernt habe und nun weiß wofür ich es nicht verwenden kann, was ja auch nützlich ist!

SQS Lambda

Das SQS Lambda Solution Construct ist ein spannendes Pattern welches eine Queue vom Simple Queue Service (kurz: SQS), mit einem Lambda verbindet und so die Queue Messages an das Lambda zur Weiterverarbeitung leitet. Die Queue und das Lambda bekommen dabei ausschließlich benötigten Permissions. Zusätzlich deployed das SQS Lambda Solution Construct noch eine Dead Letter Queue die zum Speichern und Weiterverarbeiten von fehlgeschlagenden Messages dient.

const { SqsToLambda } = require('@aws-solutions-constructs/aws-sqs-lambda');

new SqsToLambda(stack, 'SqsToLambdaPattern', {
    deployLambda: true,
    lambdaFunctionProps: {
        runtime: lambda.Runtime.NODEJS_12_X,
        handler: 'index.handler',
        code: lambda.Code.asset(`${__dirname}/lambda`)
    }
});

Ich benötigte dieses Solution Construct da das im Teil I erwähnte DynamoDB Stream to Lambda Solution Construct ein komisches Verhalten aufgewiesen hat indem es anscheinend Event Messages manchmal dupliziert. Mit dem SQS Lambda Solution Construct konnte ich eine FIFO SQS erstellen welche nun zusätzlich die im vorherigen Absatz erwähnten Vorteile besitzt.

Lambda DynamoDB

Ein simples aber dennoch tolles Solution Construct ist das Lambda DynamoDB. Es standardisiert die Verbindung eines Lambdas zu einer DynamoDB perfekt. Bedarfsweise kann eine existierende DynamoDB Tabelle übergeben oder eine neue erstellt werden:

const { LambdaToDynamoDB } = require('@aws-solutions-constructs/aws-lambda-dynamodb');

new LambdaToDynamoDB(stack, 'test-lambda-dynamodb-stack', {
    deployLambda: true,
    lambdaFunctionProps: {
        code: lambda.Code.asset(`${__dirname}/lambda`),
        runtime: lambda.Runtime.NODEJS_12_X,
        handler: 'index.handler'
    },
    //optional existierende Tabelle übergeben
    existingTableObj: ddbTable
});

Als Teil des Solution Constructs werden die DynamoDB Zugriffsprivilegien and das Lambda erteilt. Ebenfalls wird nach der Erstellung oder Weiterleitung der Tabelle eine Environment Variable dem Lambda übergeben, welches den Namen der Tabelle enthält. Somit kann dann ohne jeglichen größeren Aufwand auf die Tabelle innerhalb des Lambdas zugegriffen werden:

// Kopiert vom Solution Construct Repo
this.lambdaFunction.addEnvironment('DDB_TABLE_NAME', this.dynamoTable.tableName);

// Verwendung innerhalb des Lambdas
const DDB_TABLE_NAME = process.env.DDB_TABLE_NAME || ''

Zusammenfassung

Somit konnten die nächsten CDK Solution Construct erfolgreich integriert werden. Bei dem Arbeiten mit den CDK Solution Constructs stellt sich bei mir die Frage, ob es nicht auch Sinn mache eigene Solutions Constructs zu bauen. Das hätte den Vorteil der Abstraktion der Infrastruktur. Allerdings sind die Nachteile, dass eventuell nicht viel Rücksicht auf das well-architected Framework genommen wird.

Ein weiterer Nachteil wäre, dass die selbsterstellten Solution Constructs natürlich maintained und weiter entwickelt werden sollte und das einen zusätzlichen Aufwand darstellt. Ich denke es ist so wie es oft sein sollte, der Use Case wird über die Sinnhaftigkeit der Kreierung von Solution Constructs entscheiden. Bis dahin kann und sollte man ruhig die existieren AWS CDK Solution Constructs verwenden, denn diese sind Open Source auf Git und die starke AWS Community maintained und entwickelt diese kräftig weiter. Ich konnte sogar auch schon zurück kontributieren um einen Bug zu fixen. Lasst mich wissen wie eure Erfahrungen mit den CDK Solution Constructs sind!

Werde ein Patreon!

Infrastruktur Optimieren mit CDK Solutions Constructs Teil I.

Sun, 28 Jun 2020 00:00:00 GMT

Ahoi AWS'ler

Kürzlich wurden die ersten CDK Solution Constructs released. Sie versprechen ein neues Abstraktionslevel für CDK Constructs indem sie oft genutzte Cloudformation Patterns in eigene CDK Constructs zusammenfassen. Zum Beispiel wenn ein API GateWay mit einem Lambdaproxy verwendet werden soll, kann dafür das aws-apigateway-lambda Solution Construct verwendet werden.

Ein toller AWS Blogpost demonstriert die Kombination zweier solcher Solution Constructs sehr gut. Weiterhin versprechen die CDK Solution Constructs sich am well-architected Framework zu orientieren, um so zum Beispiel die fünf Pillars Operational Excellence, Security, Reliability, Performance Efficiency und Cost Optimization best möglichst mit in das CDK Deployment einzubeziehen. Das und die Einsparung an CDK Codezeilen hat mich dazu bewegt zu untersuchen ob mein Alfresco Provisioner CDK Deployment von einigen CDK Solution Constructs profitieren könnten. In den nächsten Abschnitten beschreibe ich ein CDK Solution Pattern as ich erfolgreich in mein Deployment einbauen konnte.

AWS DynamoDB Stream to Lambda

Dieses Pattern, auch zu sehen in Github, beschreibt das oft verwendete Vorhaben eine DynamoDB Tabelle bei Änderungen in den Items mittels eines Streams ein Lambda aufzurufen um ggf. auf Änderungen wie Erstellen, Editieren oder Löschen reagieren zu können. Ein Beispiel dafür könnte sein, wenn das Item aus der Tabelle gelöscht wird, kann es woanders kostengünstiger persistiert werden.

In mein Deployment verwende ich es direkt um die EC2 instanzen gemäß der Wunschkonfiguration in der Tabelle abzubilden. Soll nun zum Beispiel die EC2 Instanz gestoppt wird nur noch stopped in die expectedStatus Spalte der Tabelle geschrieben. Soll die Instanz wieder gestartet werden reicht die Änderung auf running. Soll die Instanz komplett gelöscht werden, kann das Item einfach gelöscht werden und das gestreamte Lambda sorgt dafür, dass die Instanz gelöscht wird.

Meine vorherige Lösung sah dafür die alleinige Verwendung von StepFunction vor, aber Streams dafür zu benutzen ist wesentlich vorteilhafter und spart darüber hinaus viele Zeilen Code. Auch finde ich toll, dass das Pattern den Stream weg abstrahiert und ich mir nur noch Gedanken um die Tabelle und das Lambda machen muss.

Zusammenfassung

Die CDK Solution Constructs sind tolle Pattern die die Erstellung der AWS Infrastruktur massiv vereinfacht und dabei sogar das well-architected Framework mitbeachtet. Nächste Woche will ich versuchen das nächste Pattern Cloudfront S3 zu integrieren. Seit gespannt!

Mit großer Spannung verfolge ich die Entwicklungen der CDK Solution Constructs. Habt ihr schon Erfahrungen gemacht mit CDK oder sogar schon mit den CDK Solution Constructs? Wenn ja für was? Falls ihr Fragen oder Anregungen habt, lasst es mich wissen.

Werde ein Patreon!

ACS und APS Integration

Sun, 14 Jun 2020 00:00:00 GMT

Hi Alfrescans.

Vor einigen Monaten berichtete ich über ein spannendes Projekt mit dem Kunden bei dem wir die neueste ACS und APS version verwenden. Bisher lief alles reibungslos. Nun standen wir aber vor der nächsten spannenden Herausforderung. Wir wollten Prozesse in APS aus ACS heraus starten. Das Ganze aber ohne Verwendung des Share Connector, welcher normalerweise solche Integrationen zwischen ACS und APS erleichtert. Seit ACS 6.0 ist der Share Connector nicht mehr von Alfresco supported.

Problemstellung

ACS und APS sind zwei unabhängige Services die in der Lage sind über CMIS oder REST APIs miteinander zu kommunizieren. Schon seit langem ist es möglich bei APS ACS als Content Management System einzustellen und somit Daten direkt in ACS zu speichern und abrufbar (Content und Properties) zu halten. Das funktioniert super solange die Prozesse von APS aus gestartet werden. Nun kann man sich aber ja auch perfekt den Use Case vorstellen, dass Prozesse aus ACS gestartet werden sollen. Ein Beispiel dafür wäre wenn ein Dokument in einem bestimmten ACS Folder hochgeladen wird, soll ein Prozess in APS mit diesem Dokument gestartet werden.

Für ACS 5.2 ließ sich das Problem mit dem Share Connector lösen. Dieser erweitert ACS mit Webscripts welche über die REST mit APS Prozesse starten kann. Zusätzlich bietet der Share Connector noch einige Share UI Erweiterungen für die APS Integration. Es wäre zwar noch möglich den Share Connector für neuere ACS Versionen zu verwenden, allerdings bietet dann Alfresco keinen Support mehr. Nachfolgend erkläre ich zwei Methoden wie ein Prozess in APS über eine URL gestartet werden kann ohne den Share Connector zu verwenden. Anschließend erkläre ich wie man diese URL in ACS als teil einer Action in Form eines Webhooks aufrufen kann.

Custom Endpoint zum Prozess Starten

APS bietet die Möglichkeit Custom Endpoints per Java Code zu implementieren. Mit diesem lassen sich dann Prozesse starten und Variablen zum Prozess übergeben. Die Alfresco Dokumentation dazu findet ihr hier. Ist nun so ein Custom Endpunkt implementiert, kann dieser als WebHook in ACS genutzt werden um einen Prozess aus ACS heraus zu starten. Wie in der Dokumentation beschrieben, wird der Endpunkt mittels Java definiert um anschließend in eine Jar verpackt zu werden. Die Konfiguration dessen war etwas aufwendig da einige Dependencies nur in dem privaten Alfresco Nexus erhältlich sind. Die folgenden Dependencies habe ich benötigt um die JAR zu bauen:

<dependencies>
    <dependency>
        <groupId>org.alfresco</groupId>
        <artifactId>alfresco-repository</artifactId>
    </dependency>
    <dependency>
        <groupId>com.activiti</groupId>
        <artifactId>activiti-app-rest</artifactId>
        <version>1.11.0</version>
    </dependency>
    <dependency>
    <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>4.1.6.RELEASE</version>
    </dependency>
</dependencies>
...
<repositories>
    <repository>
        <id>enterprise-releases</id>
        <url>https://artifacts.alfresco.com/nexus/content/repositories/activiti-enterprise-releases</url>
    </repository>
</repositories>

Für das private Alfresco Nexus Repository werden Zugangsdaten benötigt. Diese bekommt man unter support.alfresco.com . Anschließend kann die JAR mittels Docker in den Container kopiert werden. Nachfolgend zeige ich die Docker Compose und Docker Settings für das laden der JAR in die Tomcat webapp lib.

process:
    build:
        context: ./process
    environment:
    ...

Im Ordner ./process befindet sich die folgende Dockerfile.

FROM alfresco/process-services:1.11.0

ARG TOMCAT_DIR=/usr/local/tomcat

COPY target/acsaps-1.0.0-SNAPSHOT.jar $TOMCAT_DIR/webapps/activiti-app/WEB-INF/lib

Am besten testet ihr den Custom Endpoint zuerst mit Postman bevor ihr versucht mittels ACS Url Webhook diesen aufzurufen. Ich bin mir noch nicht sicher was diese Methode für Vorteile hat Verglichen mit der APS Signals Methode im nächsten Abschnitt. Ich vermute aber, dass mit der Java Programmierung ein komplexerer Prozessaufruf möglich sein könnte.

APS Signals für den Start des Prozess

Die Verwendung von Start Signalen in APS ist eine andere Art ACS und APS miteinander zu verbinden. Der große Vorteil gegenüber der Custom Endpoint Methode ist, dass kein Java Code erstellt werden muss und sich alles mittels UI in /activiti-app konfigurieren lässt. Ein anderer Vorteil ist, dass das sogenannte Start Signalen mehrere Prozesse staren kann. In unserem Beispiel bleibe ich aber erstmal bei einem. jtsmith beschreibt das Vorgehen sehr gut in seinem Blog Post Start Signal Event with REST example. Kurz zusammengefasst wird dabei mittels APS ein Basic Auth Endpoint erstellt. Danach wird ein Signal Prozess modelliert, welcher in Zukunft das Signal quasi abfängt und auf mapped. Dafür wichtig ist, dass das Request Mapping die folgende Form haben muss:

APS Signal Payload

{
   "signalName":"mysignal",
   "tenantId":"tenant_1",
   "async":"false",
   "variables":
   [
        {
            "name":"document",
            "value":"${document.nodeRef}"
        }
    ]
}

Die genauen Funktionen der Properties bitte im verlinkten original Post nachlesen. Als nächstes können dann Prozesse erstellt werden die als Start Event das Signal mysignal nutzen können umd den Prozess zu starten. Das Modell für den Signal Prozess lässt sich dann auch einfach exportieren und wiederverwenden.

ACS Webhook

In den vorherigen Abschnitten wurde erklärt wie ein APS Prozess über eine URL gestartet werden kann. Jetzt fehlt nur noch die Möglichkeit genau das zu tun mit ACS. Ich betrachte dabei den Use Case, dass ein User gerne einen Prozess gestartet haben möchte, wenn eine Datei in einem Folder in ACS hochgeladen wird. Dafür sind zwei Elemente notwendig. Für den Folder müssen wir eine Rule erstellen, welche aktiviert wenn ein neues Dokument erstellt wird. Dann muss eine WebHook Action ausgeführt werden.

Leider bietet Alfresco ootb keine Webhook Action an. Es bieten sich nun als zwei Möglichkeiten. Entweder du bastelst dir selber eine Alfresco Webhook Action oder benutzt die geniale Webhook Action von Acosix GmBH. Diese kommt mit vielen tollen Funktionen wie z.B. FreeMarker Text Input Felder um den Payload oder die Webhook URL zu definieren, was ziemlich cool ist. Die Webhook Action arbeitet mit Payload Templates die zur Laufzeit erstellt / angepasst werden können.

Ich habe ein APS Payload Template spendiert welche bereits den vorhin erwähnten APS Signal Payload bereitstellt. Wenn ihr noch mehr Variablen wie evtl. Alfresco Properties mittels des Webhooks übertragen wollt, muss das Payload Template nur erweitert werden in der variables Section. Die Webhook Action von Axel bietet dabei auch hervorragende Debugging Optionen um eventuelle Bugs aufzufinden.

Zusammenfassung

ACS und APS sind mächtige Tools welche vereint Unternehmen helfen endlich die lang ersehnte, optimale digitale Lösung zu finden. Die Integration ACS nach APS stellt viele Alfresco Engineers vor Herausforderungen. Ich listete hier mehrere Möglichkeiten wie diese Integration gemeistert werden kann und hoffe das es dir hilft deine ECM BPM Ziele mittels ACS und APS zu erreichen. Unsere ACS APS Integration beim Kunden ist bei weitem noch nicht abgeschlossen, da wir planen relative komplexe Prozesse in APS zu schreiben und uns bereits gedanken über die Integrität zwischen ACS und APS machen, welches uns vor spannenden Problemen stellt. Schreibt mir wie eurer ACS APS Integration aussieht :) .

Werde ein Patreon!

OpenApi generierte Restic REST Serve

Sat, 06 Jun 2020 00:00:00 GMT

Hello Leute :).

In diesem Beitrag möchte ich davon berichten wie einfach es sein kann einen Backend REST Server zu erstellen mit zur Hilfenahme von OpenApi Spezifikationen. Mein ultimatives Ziel ist es Backups und den Restore Prozess von Alfresco Daten so einfach wie möglich zu machen. Nach langem recherchieren habe ich mich entschlossen Restic als Backup und Restoring Engine zu benutzen. Da in meinem bisherigen Deployments alle Alfresco Daten, sprich die Blob Daten, DB Daten, Solr Daten usw. im /data Folder vorliegen scheint es der perfekte Use Case für Restic zu sein. Das automatisierte Backup funktioniert so weit gut. Vielen Dank an dieser Stelle lobaro und seiner brillanten restic Backup Arbeit welche mir im Part automatisierte Backup sehr geholfen hat.

Nun steht allerdings noch der Restoring part an. Und wie es scheint gibt es bisher dafür kein Tooling. Der Administrator müsste also immer die Restoring mittel Restic manuell durchführen. Das heißt in die Machine einloggen und die nötigen Restic Restore Befehle ausführen, welche den gewünschten Snapshot wiederherstellen. Diesen Prozess will ich vereinfachen und dem Administrator eine angenehme UI zur Wiederherstellung bereitstellen. Dafür verwende ich die OpenApi Technologien. In den nächsten Abschnitten erzähle ich mehr über OpenApi und was genau ich gemacht habe.

OpenApi

OpenApi welches früher Swagger genannt wurde, ist eine YAML oder JSON Template Sprache zur Beschreibung von RESTful APIs. Folgend beschreibe ich was super an OpenApi ist. Erstens eigenen sich die Templates extrem gut als Dokumentation über die API selber, da aus dem Template eine schick aussehende HTML UI generiert werden kann, welche die API Endpoints sehr gut beschreibt. Eine solche UI ist im Titelbild dieses Blogposts zu sehen. Noch genialer ist die UI kann direkt zum Testen der Endpoints genutzt werden, also zum Senden und Empfangen von Requests und Responses. Viele API Schnittstellen, wie es auch AWS API Gateway eine ist, bieten es and die Parameter Validierung der Requests über OpenApi Files zu machen. Was mit Parametervalidierung gemeint ist versuche ich anhand des folgenden Beispiels zu erklären:

parameters:
    - in: query
    name: userId
    description: Get items of that user
    required: true
    type: string

Hier ist ein Parameter vom Typ Query zu sehen sehen. Das bedeutet dieser würde in der URL in etwa so aussehen

http://<url>/items?userId=martin

Mit der Parametervalidierung kann ich dann bestimmte Eigenschaften des Parameters definieren, wie hier der name userId ob er required ist und welchen Typ der value haben soll, in unserem Fall als vom typ string.

Auch sehr mächtig ist die Eigenschaft, dass es möglich ist aus OpenApi Files Client Libaries und Server Stubs zu generieren. Alfresco generiert zum Beispiel JavaScript Clients mit zur Hilfenahme des API-Explorers (Näheres auf GitHub Api-Explorer) und ADF (oder ADF JS Github). Dort wird zum Beispiel aus dem Swagger File die eine JavaScript API Library erzeugt, welche als Wrapper für die API Requests genutzt werden kann in den ADF Components Github.

Auch cool ist, Postman bietet eine Importierfunktion für OpenApi Files. Dann wird daraus gleich eine Collections erzeugt. Das ist sehr praktisch, wenn man anfangen möchte die Requests in Postman zu schreiben.

Server Generierung

In diesem Teil erzähle ich mehr über meine Implementierung in Github. Der OpenApi Generator ist ein mächtiges Tool zum erzeugen von Client Libs und Server Stubs von OpenApi Spezifikationen wie der bei mir im Repo ./restic.yaml . Zurzeit interessiert mich aber lediglich die Server Stub Generierung. Es kann aus einer Reihe von verschiedenen Server Technologien wie Go, Kotlin, Java, JavaScript ausgewählt werden. Ich habe mich speziell für den NodeJS Express Server entschieden. Um den Server zu generieren wird der folgenden Befehl in ./build_server ausgeführt:

PWD=$(pwd)
docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli generate \
-i /local/restic.yaml \
-g nodejs-express-server \
-o local/server

Ein zusätzlicher Bonus. Der NodeJS Express Server generiert auch eine Swagger UI die dann erreichbar ist auf /api-doc . Da ich bei der Servergenerierung die Handler für die Endpoints nicht immer wieder neue Implementieren möchte, habe ich diese in einem ausgewiesenem Ordner ./handlers untergebracht . Dann muss im OpenApi Spec nur noch drauf verwiesen werden:

operationId: getSnapshots
description: List all snapshots
x-eov-operation-handler: handlers/DefaultController

Das Property x-eov-operation-handler verweist auf die Handlerfunktion. Der ./handlers Ordner muss dann nur noch in die Docker Image kopiert werden.

Testing

Zum Testen verwende ich die neue GitHub Build Engine GitHub Actions bei dem Workflows generiert werden. Ich habe schon in meinem vorherigen Projekt wobeies um einen Let's Encrypt SSL Docker Companion GitHub Actions ausgiebig getestet und für gut empfunden. In meinen Test Workflow unter ./.github/workflows/action.yml wir die Image mittels Docker Compose gestartet und ausgiebig mit zur Hilfenahme von Postman getestet. Falls du dich mehr für automatisierte Tests mit Postman interessierst klick einfach hier

Zusammenfassung

Die Erstellung von REST Servern ist normalerweise ein aufwändiger Prozess, welcher das Schreiben jeder Menge Code benötigt. Es müssen Request Parameter im Path oder Body auf Richtigkeit validiert werden. Oder Url Mapping Algorithmen mit Request und Response Handlerlogiken ausgestattet werden. Und damit der Benutzer des REST Servers nicht verzweifelt sollte die REST API gut dokumentiert sein. All diese Aufgaben und noch viele mehr kann der OpenApi Ansatz lösen.

Mit tollen Arbeiten wie dem OpenApi Generator lassen sich problemlos Rest Server generieren und mittels Swagger HTML UI dokumentieren. Auch kann der REST Server dann problemlos getestet werden zum einen direkt in der Swagger HTML UI mit der try out Funktion und zum anderen können direkt Postman Tests aus dem OpenApi Spec File generiert werden. Die Arbeit mit OpenApi spec is sehr spannen für mich und ich hoffe, ich konnte euch animieren auch mal OpenApi Technologien auszuprobieren. Lasst mich hören wie es bei euch lief!

Werde ein Patreon!

Alfresco trifft Let's Encrypt

Sat, 30 May 2020 00:00:00 GMT

Hi Alfrescans.

Während des Alfresco Hackathons im Mai 2020 habe ich für den Docker Alfresco Installer eine Docker Companion Erweiterung implementiert, um SSL Zertifikate zu verwalten. Diese können dann für eine HTTPS Verbindung genutzt werden. Die SSL Zertifikate werden dabei von Let's Encrypt ausgestellt und regelmäßig erneuert. Let's Encrypt dient dabei auch als Autorisierer der Zertifikate. Ziemlich cool oder? Somit muss ich mir weniger Gedanken machen über eine sichere, verschlüsselte und maintainte Verbindung zu meinem Alfresco Proxy.

Leider wurde der Pull Request abgelehnt, weil der Docker Alfresco Installer im Fokus Demo und Trial bleiben soll. Um aber dieses tolle Feature euch nicht vor zu enthalten sowie einfacher zugänglich zu machen, habe ich mich entschlossen es in meinem GitHub Repo zu implementieren und es euch hier zu präsentieren. Zusätzlich habe ich automatisierte Tests geschrieben welche die noch recht neue Build Engine GitHub Actions nutzen, um das Let's Encrypt Docker Companion zu testen. In den nächsten Abschnitten erkläre ich die Erweiterung sowie die die automatisierten Tests.

Docker Companion

Der Code für die Let's Encrypt Erweiterung ist bei mir auf GitHub. Das Docker Compose Deployment wird mit dem Script ./start.sh gestarted. Soll nun ein SSL Zertifikat von Lets Encrypt ausgestellt werden, benötigst du einen Server auf dem das Docker Compose Deployment ausgeführt wird und eine Domaine die auf diesen Server umleitet. Ich selber habe dafür EC2 VM von AWS genommen und dann einach einen CNAME Record erstellt welche von meiner Domain auf den Public DNS Name von der EC2 VM zeigen. Der CNAME Record sieht dan in etwas so aus:

a.notreal.net. CNAME ec2-3-8-139-83.eu-west-2.compute.amazonaws.com

Das Alfresco Docker Compose Deployment kann dann folgendermaßen gestarted werden:

./start.sh -spr https -sh a.notreal.net -sp 443

Somit wird das gesamte ACS Docker Compose Deployment spezifisch auf https und der Domain a.notreal.net umgestellt. Das Docker Compose Deployment könnte auch ohne die Nutzung des ./start.sh Scripts gestartet werden. Allerding müssten dann die Variablen im Docker Compose File richtig gesetzt werden!

Die SSL spezifischen Anpassungen im Docker Compose File umfassen dabei nur die drei nochfolgenden Services:

    ...
    proxy:
      image: nginx:alpine
      depends_on:
        - alfresco
        - solr6
        - share
        - content-app
      volumes:
        # redirect Alfresco Apps to port 80
        - ./config/nginx.conf:/etc/nginx/nginx.conf
      environment:
        VIRTUAL_PORT: 80
        VIRTUAL_HOST: ${SERVER_HOST}
        LETSENCRYPT_HOST: ${SERVER_HOST}
        LETSENCRYPT_EMAIL: admin@${SERVER_HOST}


    nginx-proxy:
      image: jwilder/nginx-proxy
      ports:
        - "80:80"
        - "443:443"
      volumes:
        - "/etc/nginx/vhost.d"
        - "/usr/share/nginx/html"
        - "/var/run/docker.sock:/tmp/docker.sock:ro"
        - "/etc/nginx/certs"

    letsencrypt-nginx-proxy-companion:
      image: jrcs/letsencrypt-nginx-proxy-companion
      volumes:
        - "/var/run/docker.sock:/var/run/docker.sock:ro"
      volumes_from:
        - "nginx-proxy"

Der erste Service mit namen proxy ist der Alfresco Proxy über welchen die Alfresco Applikationen wie Share oder Alfresco Content App erreichbar sind. Die beiden nachfolgenden Services bilden zusammen die Docker Companion Images für die SSL Zertifikateverwaltung mit Let's Encrypt.

Testing

Ich hatte große Lust mal die neue Buildengine GitHub Actions auszuprobieren um die Ausstellung des SSL Zertifkates für die Domain a.notreal.com zu testen. Ich habe mir gedacht es müsste doch möglich sein die GitHub Action Runner nicht von GitHub selber laufen zu lassen, sondern auf AWS direkt. So könnte ich dann einach mittels des CNAME Records auf den Public DNS Name vom AWS Runner verweisen. Und ja das hat tatsächlich geklappt. Viel geholfen hat mir dieser Blog Post von Lothar Schulz wo genau beschrieben wird, wie ich AWS Ec2 VMs als GitHub Actions Runner verwenden kann. Mein GitHub Workflow sieht folgendermaßen aus:

name: Test Deployment

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:

  linux-build:
    # runs-on: ubuntu-latest
    runs-on: self-hosted
    strategy:
      fail-fast: true

    steps:
    - name: Checkout
      uses: actions/checkout@v2.1.1
    - name: Setup Node.js environment
      uses: actions/setup-node@v1.4.2
    - name: Execute start.sh
      run: |
        mkdir -p data/solr-data
        mkdir -p logs/postgres
        sudo chown -R 33007 data/solr-data
        sudo chown -R 999 logs/postgres
        chmod +x start.sh && ./start.sh -spr https -sh a.notreal.net -sp 443
    - name: Docker Compose deployment has failed
      if: ${{ failure() }}
      run: |
        docker-compose config
        docker-compose logs
    - name: Execute Postman Tests
      run: |
        npx newman run test/alf-ec2.postman_collection.json -e test/alf-ec2.postman_environment.json -r cli,json --reporter-json-export tmp/newman/report.json
    - name: Postman has failed!
      if: ${{ failure() }}
      run: |
        echo "Postman Failed!"
        cat tmp/newman/report.json
        docker-compose config
        docker-compose logs

Im Workflow File von GitHub Actions sehen wir das Alfresco gestarted wird mit der Domaine die über den CNAME Record auf den EC2 Runner zeigt. Durch die Ausführung von start.sh wird Alfresco gestarted und am Schluss die Erreichbarkeit geprüft. Jetzt sollten wir nur noch sicherstellen, dass auch die Indexengine Solr funktioniert. Mittels Newman, welches ein CLI Tool von Postman ist, wird ein Request mit anschließender Validierung als Test benutzt:

protocol=https
host=a.notreal.net
port=443
POST {{protocol}}://{{host}}:{{port}}/alfresco/api/-default-/public/search/versions/1/search

Dieses tested die Erreichbarkeit von Solr. Zum jetzigen Zeitpunkt sehe ich wenig Sinn in mehr Request Tests mit Postman. Es wäre aber kein Problem dieses zu einem späteren Zeitpunkt nachzuholen. Interessierst du dich mehr für die Möglichkeiten mit Postman? Vor einiger Zeit habe ich schon einen interessanten Artikel geschreiben bei dem ich auch Postman verwende

Zusammenfassung

Verschlüsselte Verbindungen zum Alfresco Proxy sind essenziell für eine Produktionsumgebung mit Alfresco. Es benötigt einen hohen manuellen Aufwand die dafür benötigten SSL Zertifikate zu erstellen, autorisieren und regelmäßig zu erneuern. Mit dem tollen und kostenlosem Angebot von Let's Encrypt lässt sich dieser Aufwand auf fast null reduzieren. Wenn ihr Kubernetes auch so spannend findet wie ich, könnte man darüber nachdenken kleine Let's Encrypt Charts zu erstellen, welche in einem Kubernetes Deployment verwendet werden können, um SSL Zertifikate Verwaltung auch in einem Cluster zu erreichen.

Falls ihr Let's Encrypt auch für eine Produktionsumgebung nutzt, bitte denkt darüber nach eine Spende and Let's Encrypt zu entrichten. Somit kann garantiert werden, dass dieser Service auch in Zukunft kostenlos bleibt. Ich bedanke mich für eure Aufmerksamkeit und hoffe auf reichliches Feedback :).

Werde ein Patreon!

Der Alfresco Provisioner

Tue, 19 May 2020 00:00:00 GMT

Hi Alfrescans.

Hast du schonmal Alfresco auf einer AWS Ec2 Instanz installiert? Vielleicht sogar auch schon mit Docker Compose? Auch wenn Docker die Installation von Alfresco einfacher gemacht hat, ist es immer noch aufwending! Zuerst muss man eine Ec2 Instanz erstellen. Dafür muss man sich in AWS einloggen, einen Ec2 Typen auswählen und diesen starten. Dann dort drauf connecten, Docker installieren und dann muss noch eine Alfresco Docker Compose Installation durchführen. Wie toll wäre es wenn wir einfach einen Managed Service hätten welche das für uns macht?

Gute Nachrichten! Genau das habe ich in den letzten Wochen implementiert. Es muss nun einfach nur noch der gewünschte Ec2 Typ und das gewünschte Alfresco Docker Compose Deployment auswählen und der Alfresco Provisioner übernimmt den Rest und installiert Alfresco für dich! Damit kann Jeder schnell und einfach Alfresco Backends für sich und seine Community erstellen. In den nächsten Abschnitten werde ich genauer von meiner Idee berichten sowie welche Technologien ich dafür verwendet habe.

Zielgruppe

Für die Alfresco Produkte sehe ich auch einen klaren Bedarf bei den eher kleineren Gruppen. Ich habe sogar ein gutes Beispiel aus meiner näheren Umgebung. Ich bin Mitglied in einer Kirchgemeinde. Nun würde sich die Kirchgemeinde gerne modernisieren, auch hin in Richtung Digitalisierung. So werden zum Beispiel Videos von Gottesdiensten auf Youtube hochgeladen oder gemachte Bilder landen irgendwo in Dropbox. Auch werden Gemeinschaftsprojekte hauptsächlich nur auf Stift und Papier geplant, da die richtigen digitalen Werkzeuge einfach fehlen. Ich sehe die Alfresco Produkte in der Lage einer Gruppe wie meiner Kirchengemeinde damit zu helfen, effizienter digitalen Content zu verwalten. Mit großer Wahrscheinlichkeit kennst auch auch du Gruppierungen wie zum Beispiel Vereine in deiner Umgebung die von Alfresco profitieren könnten.

Auch könnte das schnelle bereitstellten von Alfresco Backends Communities bei der zwingend erforderlichen Digitalisierung wärend der Coronakrise helfen. Es sollte so gut es geht vermieden werden Dokumente in Echt von Person zu Person auszutauschen oder daran gemeinschaftlich von Angesicht zu Angesicht daran zu arbeiten. Gerne würde ich meinen Beitrag leisten bei der Pandemie zu helfen und vielleicht ist der Alfresco Provisioner ja eine Möglichkeit.

Herausfordernd wird dan natürlich die verursachten Kosten so gering wie möglich zu halten und die Kostenvorteile der Cloud so gut es geht an den Nutzer weiter zu leiten. Ein paar Ideen die ich diesbezüglich bereits habe sind die Verwendung von Reserved Instances, Spot Instances, S3 als Objektspeicher, Pay as you go für die Alfresco Instanzen und die Möglichkeit die eigenen Ec2 Instanzen nutzen zu können.

Eine andere Möglichkeit bestünde darin, die mit Docker Compose erzeugen und einfach erweiterbaren Backends für Demozwecke zu verwenden und somit potentiellen Nutzer zu zeigen, zu was Alfresco Produkte alles in der Lage sind.

Verwendete Technologien

Der Alfresco Provisioner verwendet eine Vielzahl moderner Technologien. Ich beschreibe diese nachfolgend in den Kategorien Backend, Frontend und DevOps Pipeline.

Backend

Die Alfresco Instanzen werden mit Hilfe von Docker Compose, welche ich mit dem Alfresco Docker Installer erstellt habe, betrieben. Diese laufen dann auf AWS Ec2 Instanzen. Die Verwendung von Ec2 Instanzen für ein Alfresco Backend ist mittlerweile sehr verbreitet. Allerding mache ich diese Kreierung der Instanzen so dynamisch und flexible wie nur möglich. Ich habe nämlich ein AWS Api GateWay erstellt welches autonom in der Lage ist mittels API Requests vom Nutzer, dies Ec2 Instanzen zu starten, stoppen und terminieren.

Nachdem die Instanz gestartet ist, erhält der Nutzer eine Url die ihm zum Alfresco Backend bringt. Hinter dem Api Gateway arbeiten außerdem noch eine vielzahl an Lambdas, Step Functions, Dynamo DB Tables und S3 Buckets um diese zu ermöglichen. All das ist mit Infrastruktur als Code in AWS CDK verfasst. Als Programmiersprache für CDK und den Lambdas verwende ich TypeScript. TypeScript habe ich wärend dieses Projekts lieben gelernt und es ermöglicht mir ein sehr schnelles Entwickeln des Alfresco Provisioner. Auch wird mittels CDK ein Swagger File erzeugt, welches als UI und Client Library für das Frontend gilt. Nähere wie man Swagger / OpenApi lückenlos in CDK einbindet habe ich in diesem Beitrag beschrieben.

Frontend

Das Frontend ist, verglichen mit dem Backend, noch sehr bescheiden. Das liegt zu einem daran das ich noch viel zu lernen habe im Frontendbereich aber auch daran, dass sich das Backend schnell weiterentwickelt und ich nicht jedesmal UI Components neu anpassen möchte. Meine Wahl der Technologien sind React und TypeScript. React besticht durch eine reiche Auswahl an schönen Components und TypeScript ist eine geniale Sprache. Um TypeScript kurz zu beschreiben es nimmt aus Java und JavaScript nur das Beste. Am besten finde ich die Möglichkeit Types zu verwenden. Das dient als Dokumentation und ich schaffe Ordnung im eher Typlosen Dschungel von JavaScript. Auch ist das Nullhandling bzw. Undefinedhandling von TypeScript super.

Darüber hinaus habe ich mich entschlossen den OpenAPI UI Explorer als meine UI zu verwenden. Das hat einfach den super Vorteil, dass quasi die UI Components nur aufgrund des Swagger Files gerendert werden und ich nicht selber Hand anlegen muss. Quasi automatisch generierte Components. Nähere darüber kannst du von meinen vorherigen Posts herausfinden und auf den Swagger UI Seite in GitHub und auf Swagger.io

DevOps Pipeline

Mit DevOps Pipeline meine ich den Prozess vom implementieren neuer Features bis hin zur Production. Diese Wege können sehr vielfältig sein. Es hat sich allgemein aber eingestellt soviel wie möglich automatisieren zu lassen. Bei meiner Pipeline habe ich einen sehr hohen Automatisierungsgrad erreicht. Ich muss quasi nur nach den master Branch pushen, dann wird ein Teststack aufgebaut und danach Postmantests gegen das API GateWay durchgeführt. Wenn die tests erfolgreich waren wird der Produktionsstack geupdated. Dieses Verhalten kann ich noch leicht beeinflussen im Code selber indem ich folgende Variablen setze:

env:
  destroyBefore: true
  deploy: true
  updateProduction: true
  destroyAfter: true

Auch nutze ich AWS CDK welches mir erlaubt per TypeScript den Test- und Produktionsstack zu definieren. Näheres darüber kann in meinem vorherigen Post nachgelesen werden CDK Multistack oder CDK allgemein. Travis und AWS CDK finde ich eine geniale Kombination

Wie Funktionierts?

Das Provisioning der Alfresco Instanzen geschieht via REST API. Der Nutzer logt sich dafür auf der Website ein, erhält dann ein OAUTH Token und kann damit dann neue Alfresco Instanzen erstellen, alte abrufen und ändern. Dadurch dass ich den OpanAPI UI Explorer benutze, erhält der Nutzer genauste Informationen wie die API zu bedienen ist, also welche Parameter in den Requests und Response zu setzen bzw. zu erwarten sind.

Nachfolgend list ich wie zum Beispiel der Body im POST Request ist zum Erstellen einer neuen Instanz:

{
 "userId": "alfresco",
 "alfType": {
  "ec2InstanceType": "t2.large",
  "gitRepo": "alf-ec2-1",
 },
 "customName": "Alf Backend 1"
}

Die userId ist lediglich der Username im System und customName ein Spitzname für das Alfresco Backend kreiert mit dem Provisioner. AlfType beschreibt den Typ des Alfresco Backends. Dieser setzt sich zusammen aus dem Typen den Ec2 VM ec2InstanceType und einem Alfresco Docker Compose Repository gitRepo. Das GitHub Repository ist auf meinem Account und Private. Zurzeit unterstütze ich nur eins:

alf-ec-1 : ACS 6.2 Community, ACA

Alle Komponenten wurden installiert mit dem Alfresco Docker Installer. Natürlich ist geplant dieses Angebot in Zukunft weit auszubreiten. Es wäre auch denkbar Alfresco Git Repositories von anderen Usern, die nicht aus meinem GitHub Realm stammen, zu nutzen. Sie müssten nur einen gewissen Standard erfüllen und dann spräche nichts dagegen.

Eine detaillierte Beschreibung aller REST Endpoints sowie dessen Requests und Response Parameter können auf der Alfresco Provisioner UI Seite nachgelesen werden.

Geplante Features

Bereits jetzt sind viele Features geplant, die es dem Nutzer ermöglichen Geld zu sparen, den Umgang mit den Alfresco Produkten erleichtern und das Backend sicherer zu machen. Der Nutzer soll in der Lage sein die Instanzen stoppen und starten zu können. Wenn die Instanz gestoppt ist, braucht der Nutzer nicht mehr für den Compute zu bezahlen sondern nur noch für den Storage oder evtl. garnicht mehr. Auch nützlich wäre eine Erweiterung zur automatischen Erstellung von Backups. Dafür werde ich mir die interessante Arbeit von Tony mit Alfresco BART. Das würde es auch ermöglichen einfacher zu anderen alfTypes upzugraden. Zum jetzigen Zeitpunkt habe ich damit schon einen guten Fortschritt gemacht indem ich ein Tool in Go geschrieben habe, welches backups erstellen kann. Jetzt fehlt nur noch die Möglichkeit diese auch wieder in Alfresco einspielen zu können.

Bisher ist noch kein HTTPS zum Proxy der Instanzen eingerichtet. Ich plane dafür die Zertifikate bereitgestellt von Let's Encrypt zu nutzen. Dafür muss man einfach ein Docker Companion erstellen, welcher die Zertifikate Verwaltung übernimmt. Auch sollte es so möglich sein die Zertifikate automatisch vor Ablauf erneuern zu lassen. Bisher ist nur ACS Community eingerichtet aber ich plan auch andere Produkte von Alfresco wie ACS Enterprise oder APS anzubieten. Auch denke ich über einen Onboarding Layer für ACA nach.

Ein weiteres nützliches Feature wäre es, wenn der Nutzer die Instanz Url einfach umleiten kann zu seiner eigenen Domain Url.

Closed Alpha

Ich werde bald den Alfresco Provisioner der Öffentlichkeit zu Verfügung stellen. Dafür habe ich mir gedacht eventuell erstmal eine Closed Alpha zu veranstalten. So können Interessierte den Alfresco Instanz Provisioner ausprobieren, Feedback geben und mehr.

Bei Interesse schreibt mir und ich erstelle dann euren Zugangsaccounts. Alles was ich brauche ist die Email Adresse und der gewünschte User Name. Ich habe noch keinen genauen Starttermin für die Closed Alpha allerdings bin ich zuversichtlich, dass ich es noch im Mai passieren wird.

Kurze Anleitung über die Benutzung des Alfresco Provisioner

Ich habe mich dazu entschlossen ein kurzes Video darüber zu machen, wie der Alfresco Provisioner benutzt werden kann. Das Video kann hier angeschaut werden: https://www.youtube.com/watch?v=OOEOE_ncsx4

Mehr über die Alfresco Produkte

Wenn du mehr über die in der Closed Alpha genutzten Alfresco Produkte wissen möchtest, habe ich mir gedacht hier ein paar Informationen darüber bereitzustellen. Der Alfresco Provisioner installiert die moderne Alfresco Angular WebApp ACA welches als vereinfachte und Dateispezifische Version von Share angesehen werden kann. ACA wird sitzt auf Root. Es muss also nur die URL der Instanz eingegeben werden z.B. http://ec2-1-2-3-4.eu-west-2.compute.amazonaws.com/ Eine schnelle Runde über die Fähigkeiten von ACA wird hier gezeigt.

Share welches mit /share aufgerufen werden kann bietet zusätzlich zu ACA eine riesige Auswahl von Funktionen. Einen groben Überblick können die nachfolgenden Video verschaffen:

Aus Persönlicher Sicht

Was mir am meisten gefällt an diesem Projekt ist einfach mal die Tatsache, dass der Großteil der Implementierung, Testung, Entwicklung und Dokumentierung mit Hilfe der Swagger Definition geschieht. Das geht hin von der Validierung der Request Parameter, Implementierung der REST Schnittstelle, Dokumentation, Visualisierung mit Swagger UI und automatisierten Tests in Postman. Ich liebe den Ansatz mit der Swagger Definition, die ich per Swagger Plugin im Visual Studio Code previewen kann, für fast alles nutzen zu können. Aus meinser Sicher ist das die Zukunft der Serverimplementierung.

Das Weiteren bin ich einfach immer noch Überwältigt mit was ein einziger Entwickler in der Lage ist mit AWS CDK, ins Besondere im TypeScript Flavor, zu tun. Meine Begeisterung zu CDK habe ich bereits hier beschrieben und möchte es hier nicht wieder holen. Bitte nachholen.

Zusammenfassung

Was als einfaches AWS CDK experiment startetet entwickelte sich rasch zu einem tollen neuen Service den ich den Alfresco Provisioner genannt habe. Damit ist es einfach möglich Alfresco Backends, welche mit Docker Compose entwickelt wurden, bereitzustellen. In der Closed Alpha Phase lade ich dich herzlich ein den Service zu nutzen.

Kudos

Ein fettes Dankeschön an die AWS CDK Community in Gitter. Selten habe ich eine Community so sehr in Liebe verfallen zu der Technologie gesehen.

Werde ein Patreon!

Alfresco Virtual Hack-a-thon Mai 2020 Zusammenfassung

Fri, 15 May 2020 00:00:00 GMT

Hi Alfhackas.

Der Alfresco Hack-a-thon war super. Am meisten gefallen haben mir die persönlichen Gespräche mit vielen tollen Exkollegn sowie anderen Alfrescojüngern. Darüber hinaus konnte ich auch wertvollen Informationen über Geplante Projekte innerhalb von Alfresco erfahren. Zum Beispiel bin ich sehr gespannt wohin sich Digital Workspace, die hübsche Angular Webapp für ACS Enterprise, entwickelt. Sehr bald wird es UI Elemente bekommen um APS Elemente wie Task und Prozesse anzeigen zu können. Ich wurde auch darauf hingewiesen, dass ich als Alfresco Partner Zugriff zu dem Digital Workspace Repository bekommen könnte, was ich definitiv dankbar machen werde.

Lets Encrypt

Mein Projekt für den Hack-a-thon war es dem Docker Alfresco Installer eine Docker Erweiterung zu spendieren, welche es ermöglichen würde Lets Encrypt autorisierte Zertifikate für die HTTPS Verbindung zu nutzen. Sogar würde die Erweiterung den kompletten Lifecycle des Zertifikates managen. Ich bin zwar nicht komplett fertig geworden damit aber konnte ein gutes Stück implementieren und dieses Wochenende werde ich garantiert damit fertig.

Zum Abschluss

Vielen lieben Dank an die Organisierer des Alfresco Hack-a-thon und an die die tolle Alfresco Community. Definitiv bin ich wieder dabei beim nächsten Hack-a-thon. Cheers.

Werde ein Patreon!

Alfresco Virtual Hack-a-thon Mai 2020

Fri, 08 May 2020 00:00:00 GMT

Hi Alfrescans.

Am 11 Mai 2020 veranstaltet Alfresco ein virtuelles Hackathon. Die aktuellen Projektideen findet ihr hier auf hub.alfresco.com. Mit diesem Post will ich euch recht herzlich einladen teilzunehmen.

Warum Teilnehmen?

Es kann verschiedene Gründe haben warum du teilnehmen solltest. Wenn du die Alfresco Produkte magst, ist es toll mitzuhelfen die Produkte weiter zu entwickeln oder gar komplett neue zu erschaffen. Ich zum Beispiel hätte gerne einen SSL Companion Container für den Alfresco Docker Installer. Kurzerhand habe ich das Projekt einfach angemeldet um mitzuhelfen es zu organisieren und durchzuführen.

Auch ist eine tolle Gelegenheit Kontakte mit motivierten Entwicklern aus aller Welt zu knüpfen. Wärend meiner Zeit bei Alfresco habe ich schlaue als auch hilfsbereite Entwickler kennengelernt, von denen ich mir viel abgeschaut habe. Ich suche immer nach Gelegenheiten zu lernen und der Hackathon ist die perfekte Gelegenheit dafür.

Auch unsere Firma von Object würde gerne mal in Zukunft einen Hackathon veranstalten und der Alfresco Hackathon könnte eine perfekte Gelegenheit seit zu lernen wie man solche Hackathons veranstalten kann.

Der beste Grund: Why not? Es könnte eine interessante neue Erfahrung für dich sein und wenn es dir nicht gefällt, kannst du jeder Zeit gehen und beim nächsten mal einfach nicht mitmachen.

Zusammenfassung

Der Alfresco Hackathon am 11 Mai 2020 steht vor der Tür. In die Startlöcher meine Freunde :) ! Nach dem Even werde ich in Form eine Posts hier berichten wie mie der Hackathon gefallen hat. Bis zum 11 dann und bleibt gesund :D !

Werde ein Patreon!

Go Alfresco BART

Sun, 03 May 2020 00:00:00 GMT

UNDER CONSTRUCTION Hi Alfrescans.

Backups von ACS zu machen und auch diese gegebenfalls wieder einzuspielen war noch nie leicht bei Alfresco. Eine genau Anleitung wie es gemacht werden sollte findet ihr in Alfresco's Dokumentation. Da liegt es natürlich nahe, dass man sich ein gewisses Tooling wünscht, welches diesen Aufwand stark reduziert. Vor einigen Jahren hat Tony ein bemerkenswertes Tool den Alfresco BART geschrieben. Das Projekt wurde aber leider nicht weiter entwickelt. Nun habe ich die Idee eine komplett neue Version mit mehr Features zu schreiben welches ich Go Alfresco BART nenne.

Motivation

Das existierende BART besitzt eine hohe Komplexität und ist mit sicherheit nicht mehr Kompatibel mit Alfresco. Ich muss aber ehrlich gestehen, dass ich BART nicht getested habe. Wie auch immer. Zusätzlich bin ich daran interessiert die Sprache Go zu lernen. Schon nach meinem ersten kleinen Go Projekt ist mir klar, das Go perfekt wäre für eine neue Version von Alfresco BART. Mit diesem Projekt implementiere ich als eine neue, verbesserte Version von BART und lerne Go besser kennen.

Verwendete Technologien

Go Lang
Travis
Repo https://github.com/huacnlee/gobackup

Zusammenfassung

...

Werde ein Patreon!

AWS CDK Multistacks für Test und Produktion

Sat, 18 Apr 2020 00:00:00 GMT

Hi AWS Fans,

Wie gut sich AWS CDK zur Beschreibung in Code der Infrastruktur eignet habe ich ja bereits in einem vorherigen Beitrag beschrieben. In diesem Beitrag soll es darum gehen wie CDK in einer Test- und Produktionsumgebung aussehen könnte. In meinem privaten Projekt habe ich bereits so etwas wie eine Produktionsumgebung implementiert und bin sehr begeistert davon. Kurz gesagt dafür benutze ich CDK's Multistack. In den nächsten Abschnitten beschreibe ich wie mein Deployment aussieht.

CDK Multistack

Ein CDK Multistack ist ein CDK Deployment welches mehrere Stacks verwaltet. Diese Stacks können in der gleichen oder anderen Regionen sein oder sogar in einem anderen AWS Accounts. Die unterschiedlichen Stacks können dann einfach bei der Erstellung mit verschiedenen Parameter initialisiert werden. Nachfolgend ist ein Beispiel mit zwei Stacks:

new MultiStack(app, "EuWest2Prod", {
    environment: 'prod',
    env: {
      region: "eu-west-2",
      account: 'ABC'
    },
    // disable create ec2 instance
    // createInstances: {
    //   imageId: 'ami-04d5cc9b88f9d1d39'
    // },
    cognito: 'true'
    domain: {
      domainName: 'api.nope.dev',
      zoneName: 'api.nope.dev.',
      hostedZoneId: 'AA',
      certificateArn: 'arn:aws:acm:eu-west-2:ABC:certificate/xyz'
    }
  });

new MultiStack(app, "EuWest2", {
  environment: 'dev',
  env: {
    region: 'eu-west-2',
    account: 'XYZ'
  },
  createInstances: {
    imageId: 'ami-0cb790308f7591fa6'
  }
});

Das ist ein kleiner Ausschnitt aus meinem Projekt. Der erste Stack mit Namen EuWest2Prod beschreibt den Produktionsstack der sogar in einem anderen Account liegt. Der Zweite Stack EuWest2 ist der Teststack. Diese Art und Weise der Parametrisierung lässt sich hervorragend nutzen um Features an und auszuschalten. Im Produktionsstack habe ich mit der Auskommentierung von createInstances das Feature zur Erstellung von Ec2 Instanzen erstmal ausgestellt um Kosten zu sparen. Auch unterstützt die Parametrisierung eine einfach Migration von einem AWS Account zu einem anderen.

In den nächsten Abschnitten will ich mehr über meinen Teststack und Produktionsstack für mein Projekt sprechen. Mann muss aber fairerweise erwähnen, dass ich noch keine wirkliche Produktion habe. Also sprich echte Kunden, die meinen Service nutzen. Ich hoffe dieses natürlich bald ändern zu können. Zum jetzigen Zeitpunkt versuche ich Erfahrungen zu sammeln wie ich eine echte Produktion möglichst gut am laufen halten könnte, sprich neue Features problemlos implementieren. Dafür eignen sich AWS ChangeSets für CloudFormationstacks sehr gut. Diese ändern den jeweiligen Stack nur mit den erforderlichen Updates. Bevor du weiterliest, es macht definitiv Sinn über AWS ChangeSets für CloudFormations sich zu informieren.

Teststack

Teststacks sollten in erster Linie günstig sein. Die Tests werden ausgeführt und das Logresult sollte dem Developer einfach zugänglich sein. Kurz danach sollte der Stack die Ressourcen vernichten. Ist noch eine manuelle Begutachtung des Teststacks erwünscht kann man eine Verzögerung der Vernichtung nach den Tests implementieren. Ich habe das zum Beispiel bei den Ec2 Instanzen gemacht, die sich selber nach 55 Minuten terminieren.

Und natürlich sollte der Teststack testen. Was das genau ist hängt von deinem Use Case ab. Bei mir teste ich gegen ein API GateWay und dessen Endpoints. Im Hintergrund werden mehrere DynamoDB Tabellen, sowie EC2 Instanzen kreiert oder terminiert mittels Step Functions. Das mache ich mit Postman. Falls dich das Testen mehr interessiert habe ich bereits darüber in meinem vorherigen Post berichtet.

An sich wars das. Wenn die Testphase erfolgreich war, kann das Update in die Produktions angewandt werden. Das wird im nächsten Abschnitt beschrieben.

Produktionsstack

Der Produktionsstack ist für die Kunden gedacht. Dort muss als alles bestmöglich funktionieren und neue Features sollten erst implementiert werden, wenn sie sich im Teststack bewiesen haben. Auch kann es Sinn machen den Produktionsstack mit etwas veränderten Service Einstellungen zu betreiben. Ein Beispiel dafür wäre, dass ich im Teststack ja keine wirklich User Verwaltung ggf. mit Cognito brauche, aber im Produktionsstack schon. Somit wird die Komplexität im Teststack geringer gehalten. Im obigen Snippet habe ich Cognito in der Produktion definiert. Ein weiteres Beispiel wären EC2 Instanzen. Im Teststack reichen vielleicht kostengünstige EC2 Typen wohingegen in der Produktion stärkere und somit kostenintensivere Instanzen nötig sind.

Es stellt sich nun die Frage wo der Produktionsstack deployed werden sollte. Glücklicherweise bietet uns CDK dort jede Freiheit. Es ist möglich den Stack in der gleichen oder in einer anderen Region, im gleichen Account zu deployen. Auch kann der Produktionsstack in einem anderen Account deployed werden. Dafür müssen dann aber Profiles genutzt werden. Hier ist mal ein Beispiel:

cdk deploy "$STACK_NAME_PRODUCTION" --profile=prod

Dieser Stack wird nun in einem anderen AWS Account deployed. Bisher habe ich mit dieser Art und Weise der Deployments eine gute Erfahrung gesammelt. Ein Nachteil hat diese Art des Deployments allerdings. Da ich nun auf den Profile parameter angewiesen bin, kann ich den gleichen cdk deploy Befehl nicht auch für den Teststack nutzen und ich muss zwei CDK Befehle ausführen:

cdk deploy "$STACK_NAME_TEST"
cdk deploy "$STACK_NAME_PRODUCTION" --profile=prod

Es wäre toll wenn ich bei der Definition im Multistack einfach den Profil namen angeben könnte. Wirklich schlimm ist dieser Nachteil natürlich nicht, da in einer vernünftigen Pipeline sowieso der Teststack alleine nur ausgeführt werden sollte und nachdem die Testphase abgeschlossen ist der Produktionstack deployed wird.

EDIT: Ich habe Feedback bekommen, dass es dafür bereits einen Workaround gibt in der npm registry: https://github.com/hupe1980/cdk-multi-profile-plugin

DevOps Travis Pipeline

Travis sollte jedem Developer bekannt sein. Der Free Tier von Travis erlaubt es, wenn dein GitHub Projekt public ist, darfst du VMs von Travis benutzen. Diese müssen dann lediglich nur noch in der .travis File definiert und konfiguriert werden. Genau das mache ich. Ehrlich gesagt nutze ich Travis sehr stark. Ich beschreibe einfach mal kurz meinen Workflow wenn ich ein neues Feature kreiere:

Code Anpassungen von neue Feature in master schreiben.
Ggf. neuen Test in Postman hinzufügen.
master committen --> Travis build wird getriggert.
Travis schlägt fehl oder passt.
Wenn es fehl geschlagen ist, reverted der Stack automatisch und ich werte die Logs aus um zu sehen was schief lief. Zurück zu schritt 1).
Wenn es passt ist auf allen Stacks das neue Feature und ich kann es jetzt manuell testen.

Das ist sehr genial da ich weniger Interaktionen ausführen muss um dieses neue Feature zu implementieren. Der gesamt Build dauert in etwa 10 Minuten und ich kann dann 10 Minuten einfach was anderes machen. Diese Art der Pipeline hat mir ein sehr schnelle Iteration von neuen Features gebracht. Ich bin regelrecht baff was heutzutage möglich ist mir nur einem DevOps. Was ich alleine leisten kann, dafür hätte man vor 5 Jahren garantiert etwa 10 Leute anstatt nur einem gebraucht.

Zusammenfassung

CDK's Multistacks sind eine tolle Art und Weise mehrere Stacks wie einen Teststack und Produktionsstack zu verwalten. Für mein kleines Projekt habe ich tolle Erfahrungen mit dieser Art der Stackverwaltung gesammelt und hier beschrieben. Bisher hat auch komplett ein relative kleiner Travis build ausgereicht um eine nützliche Pipeline zu kreieren. Ich erwäge in AWS CodePipeline reinzuschauen ob es mir Vorteile bieten könnte. Ich hoffte euch hat meine kleine Zusammenfassung gefallen :)

Werde ein Patreon!

ACS und APS Deployment mit Docker Compose

Sat, 11 Apr 2020 00:00:00 GMT

Hi Alfrescans.

Es ist mal wieder Zeit über ein spannendes Alfresco Partner Projekt von mir zu berichten. Für einen Kunden hier in Deutschland entwickle ich ein POC welches ACS 6.2 und APS 1.10 verwenden soll. Nach ein wenig Überzeugungsarbeit konnte ich die Beteiligten davon überzeugen, Docker für ACS 6.2 zu verwenden. Mein Plan war es ein Docker Compose Deployment zu erstellen welche ACS, APS und als Identity Provider openLDAP beinhaltet. Das komplette Deployment kann bei mir in GitHub gesichtet werden. Eines sei vorweg noch erwähnt. Alfresco offiziell empfiehlt für solche Deployments doch bitte Kubernetes zu verwenden, allerdings ist für meinen Kunden die Cloud erstmal noch ein Tabuthema. Darüber hinaus bin ich gespannt zu sehen wie weit ich mit Docker Compose für so ein Deployment kommen werde.

Docker Compose Setup

Hier beschreibe ich etwas mehr im Detail welche Technologien ich für das Deployment benutze. Wie Eingangs angedeuted soll ACS 6.2 installiert werden. Die zum jetzigen Zeitpunkt zuletzt releaste Version ist 6.2.0.3. Das muss also nur im alfresco Dockerfile in /alfresco/Dockerfile reflektiert werden. Share bleibt auf Version 6.2.0 da keine neuere Version released wurde. ACS soll mit einer openLDAP DB zur User Provisioning connected werden. Zum Glück gibt es bereits toll ausgearbeitete Images zur Erstellung und Management einer openLDAP DB. Zur optischen Verwaltung der openLDAP DB benutze ich phpldapadmin. Wie genau die openLDAP Konfigurations aussieht einfach im docker-compose-base.yml File nachlesen.

Auch soll APS 1.10 zur Modellierung der Workflows beim Kunden verwendet werden. Etwas ungünstig ist die Tatsache, dass Alfresco keine Docker Compose Referenz Deployments für APS 1.10 mehr anbietet. Ich vermute mal, dass ist aufgrund des Kubernetes Deployments und das einfach darauf ein stärker Fokus gelegt wird. Zum Glück existieren noch ein paar alter Docker Compose Vorlagen und mit ein paar Modifikationen funktionieren diese auch!

Da es sehr Memoryintensiv ist ACS und APS gleichzeitig zu laufen, habe ich mich entschlossen das komplexe Deployment in drei voneinander separierbare Deployments zu teilen. Somit kann ich auch weiterhin auf meinem 16 GB Memory Laptop effizient arbeiten. Die Teilung geschieht mittels Docker Compose Files. Das Erste ist das ACS Deployment, gefolge vom Zweiten mit dem APS Deployment. Zu guter Letzt gibt es dann noch das ACS und APS Deployment. Ich finde das eine geniale Idee da ich nun, falls ich nur an ACS oder APS arbeiten möchte, nicht den gesamten Stack hochfahren muss. Zusätzlich bin ich am überlegen das Dritte Deployment also ACS und APS mittels einer DevOps Pipeline in EC2 zu deployen.

Prerequisites

Klar ist, dass du Docker brauchst. Falls du auf einem Windows oder Mac arbeitest empfehle ich dir den Docker Desktop. Nach der Installation bitte daran denken der Docker Umgebung mehr Memory zu Verfügung zu stellen da die default 2 GB viel zu wenig sind umd ACS zum Laufen zu bringen. Mindestens 12 GB wäre angebracht!

Auch verwendet die ACS Docker Compose File private Images von Alfresco gehosted in quay.io . Für diese wäre es wichtig Zugangsdaten vom Alfresco Support zu erfragen. Wenn du diese hast einfach den folgenden Befehl ausführen und die Credentials eingeben:

docker login quay.io

Mehr oder weniger optional aber mein Beispiel im GitHub Repository verwendet Node's NPM für ein CLI Script Tool zum warten bis Alfresco fertig gebooted hat. Also am besten auch Node und NPM installieren.

Git Vorbereiten

Natürlich muss erstmal ein Git Repo erstellt werden. Ich hatte meins alf-acs-aps genannt. Wie auch in meinem letzten Alfresco Docker Projekt empfehle ich den Docker Alfresco Installer zu verwenden um das noch leere Git Repository vorzubereiten. Wie genau der Docker Alfresco Installer verwendet werden kann, beschreibe ich hier. Beim installieren darauf achten, dass auch LDAP und ein SMTP Server ausgewählt wird. Falls du nicht mein GithUb Repo verwendest, müsstest du nun die APS 1.10 services in das Docker Compose Deployment integrieren. Ich empfehle dir das Deployment in drei Teile aufzuteilen. Alle drei werden in den nächsten Abschnitten erläutert.

ACS Deployment

Zuerst wird ein docker-compose-base.yml File erstellt welcher alle Services beinhaltet die für alle drei Deployments benötigt werden. Das sind in meinem Fall eine openLDAP und postgres Datenbank. Sowie ein Mail Server. Danach wird der ACS Docker Compose File erstellt. Das gesamte deployment lässt sich nun so starten:

docker-compose -f docker-compose-base.yml -f docker-compose-ACS.yml up -d --build

und so stoppen:

docker-compose -f docker-compose-base.yml -f docker-compose-ACS.yml stop

Falls ein kompletter ACS Neustart mit leereren Datenbanken und anderen Storage erwünscht ist, einfach diese Befehle ausführen:

docker-compose -f docker-compose-base.yml -f docker-compose-ACS.yml down
rm -rf data
rm -rf logs

APS Deployment

Das APS Deployment wird folgender Maßen gestartet:

docker-compose -f docker-compose-base.yml -f docker-compose-APS.yml up -d --build

und gestoppt wird es so:

docker-compose -f docker-compose-base.yml -f docker-compose-APS.yml stop

Zum Erasen einfach das Folgende ausführen:

docker-compose -f docker-compose-base.yml -f docker-compose-APS.yml down
rm -rf data
rm -rf logs

ACS und APS Deployment

Achtung eine Warnung vorweg! Dieses Deployment ist sehr Memoryintensiv. Mindestens 16Gb sollte dein Laptop oder PC besitzen. Alternativ plan ich diese Variante in der Cloud auf EC2 zu deployen.

Und so werden alle Services gestarted:

docker-compose -f docker-compose-base.yml -f docker-compose-ACS.yml -f docker-compose-APS.yml -f docker-compose-Proxy.yml up -d --build

und so gestoppt

docker-compose -f docker-compose-base.yml -f docker-compose-ACS.yml -f docker-compose-APS.yml -f docker-compose-Proxy.yml stop

Und zum runterreißen einfach eingeben:

docker-compose -f docker-compose-base.yml -f docker-compose-ACS.yml -f docker-compose-APS.yml -f docker-compose-Proxy.yml down
rm -rf data
rm -rf logs

Ausblick

Wie angedeutet würde ich gerne das dritte Deployment also ACS und APS auf AWS EC2 bringen. Am liebsten sogar in einer schönen DevOps Pipeline, sprich commit nach master triggered ein Deploy nach EC2 wo dann dort automatisierte Tests ausgeführt werden wie zum Beispiel ob ACS und APS erfolgreich gebooted haben.

SSO (Single Sign On) erlaubt es für die Alfresco Produkte sich nur noch einmal anmelden zu müssen. Das heißt wenn ich mich zum Beispiel in Share einlogge und dann Alfresco Digital Workspace öffne oder Ativiti App, muss ich mich nicht erneut einloggen. Dafür müsste AIMS Alfresco Identify Manager Service mit ACS konfiguriert werden und zusätzlich für Share dann noch die SAML amp.

Zusammenfassung

Man muss nicht immer gleich die Kubernetes Keule auspacken wenn es um Container Orchestrierung geht. Auch Docker Compose kann hervorragend verwendet werden um Container zu orchestrieren. Es besteht sogar die möglichkeit komplexe Deployments in kleine Teilstücke aufzuteilen, welche nicht den Memory deines Laptops schonen sondern sich auch hervorragend für eine schnelle Iteration bei der Entwicklung eigenen. Also gerne mal ausprobieren ACS und APS mittels Docker Compose zu Deployen. Falls irgendwelche fragen sind, einfach anschreiben.

Kudos

An Thijs von der Tollen Alfrescan Discord Channel Community für den Vorschlag das Docker Compose Deployment so auf zu teilen :).

Werde ein Patreon!

AWS CDK Api Gateway mit Swagger

Sat, 04 Apr 2020 00:00:00 GMT

Ahoi AWS'ler und Swagger Fans

Im letzten Post habe ich gezeigt wie AWS CDK genutzt werden kann als willkommende Alternative zu YAML als Infrastruckturbeschreibung. Während der Weiterentwicklung des CDK Beispiels ist mir ein Problem beim Umgang mit Swagger Files begegnet. Aber erstmal will ich erklären was die Swagger Definition überhaupt ist. Auch sei gesagt, dass seit 2018 die neue Version von Swagger OpenApi heißt. Wenn man AWS API Gateway nutzt, ist es praktisch zur Parameter Validierung wie zum Beispiel dem Query, Path und den Body Parameter, Swagger Files zu verwenden. Was genau Swagger ist und wieso ich es so toll finde beschreibe ich im nächsten Absatz.

Was ist Swagger

Swagger ist eine YAML oder JSON Template Sprache zur Beschreibung von RESTful APIs. Folgend beschreibe ich was super an Swagger ist. Erstens eigenen sich die Templates extrem gut als Dokumentation über die API selber, da aus dem Template eine schick aussehende HTML UI generiert werden kann, welche die API Endpoints sehr gut beschreibt. Eine solche UI ist im Titelbild dieses Blogposts zu sehen. Noch genialer ist die UI kann direkt zum Testen der Endpoints genutzt werden, also zum Senden und Empfangen von Requests und Responses. Viele API Schnittstellen, wie es auch AWS API Gateway eine ist, bieten es and die Parameter Validierung der Requests über Swagger Files zu machen. Was mit Parametervalidierung gemeint ist versuche ich anhand des folgenden Beispiels zu erklären:

parameters:
    - in: query
    name: userId
    description: Get items of that user
    required: true
    type: string

Hier ist ein Parameter vom Typ Query zu sehen sehen. Das bedeutet dieser würde in der URL in etwa so aussehen

http://<url>/items?userId=martin

Auch sehr mächtig ist die Eigenschaft, dass es möglich ist aus Swagger Files Client Libaries zu generieren. Alfresco macht das zum Beispiel mit dem API-Explorer (Näheres auf GitHub Api-Explorer) und ADF (oder ADF JS Github). Dort wird zum Beispiel aus dem Swagger File die eine JavaScript API Library erzeugt, welche als Wrapper für die API Requests genutzt werden kann und auch wird in ADF Components Github.

Auch cool ist, Postman bietet eine Importierfunktion für Swagger Files. Dann wird daraus gleich eine Collections erzeugt. Das ist sehr praktisch, wenn man anfangen möchte die Requests in Postman zu schreiben.

AWS Api Gatway mit Swagger

Die ganzen Features vom vorherigen Abschnitt klingen schon sehr verlockend oder? Wie toll das auch AWS API Gateway es anbietet, Swagger Files aus dessen Deployments zu extrahieren und zu importieren, wenn Cloudformation oder CDK verwendet wird. Leider im Zusammenhang mit AWS CDK, lassen sich extrahierte Swagger Files nicht so einfach wiederverwenden für dessen Beschreibung. Das größte Problem ist, dass wenn zum Beispiel ein Lambda geupdated wird, sich dan logischerweise auch dessen ARN ändert. Allerdings die vom API Gateway extrahierten Swagger Files verwenden genau diese ARNs wenn Lambda als Backendimplementierung für einen Endpoint benutzt wird. Und da sich die ARN ändert sind diese outdated im swagger file. Nachfolgend ist ein Swagger Snippet und dort sieht man die Arn über die ich spreche hinter dem uri keyword.

paths:
  /items:
    get:
      responses:
        '200':
          description: Ok
          content: {}
        '401':
          description: Authorization information is missing or invalid
          content: {}
      x-amazon-apigateway-integration:
        uri: >-
          arn:aws:apigateway:[secure]:lambda:path/2015-03-31/functions/arn:aws:lambda:[secure]:[secure]:function:ApiLambdaCrudDynamoDBExam-getAllItemsFunction0B7A9-1KKCGIJ01C3NI/invocations
        passthroughBehavior: when_no_match
        httpMethod: POST
        type: aws_proxy
      parameters:
        - $ref: '#/parameters/alfUserIdParam'
      x-amazon-apigateway-request-validator: Validator

Das AWS CDK Team weiß über dieses Problem bescheid und es ist auf der Roadmap. So hoffentlich wenn du diesen Beitrag ließt ist der folgende Workaround nicht mehr notwendig. Zur Vollständigkeit liste ich hier die related Issues auf:

https://github.com/aws/aws-cdk/issues/723 https://github.com/aws/aws-cdk/issues/1461

Workaround

Um des Problem zu lösen habe ich mein Travis so konfiguriert, dass CDK zweimal deployed wird. Beim ersten Deploy wird kein Swagger File benutzt und beim zweiten wird dann ein geniertes Swagger File verwendet. Wirklich interessant ist wie ich an das generierte Swagger File komme. Folgend versuche ich den Prozess zu beschreiben, aber bitte schaut auch in meinem GitHub Repo (dort in .travis) nach wie ich diesen Workaround implementiert habe.

Ich deploye oder Swagger File mit:

export WITH_SWAGGER='false' && cdk deploy --require-approval never

Aufpassen WITH_SWAGGER is eine env Variable im CDK Deployment File index.ts . Damit wird programmatisch keine Swagger File für das Deployment verwendet.

Nun kann ich mit der AWS CLI das Swagger File vom API Gateway extrahieren:

aws apigateway get-export --parameters extensions='integrations' --rest-api-id $REST_API_ID --stage-name prod --export-type swagger --accepts application/yaml tmp/swagger_new.yaml

Der generiert Swagger File tmp/swagger_new.yaml sieht dan in etwas so aus:

swagger: '2.0'
info:
    version: '2020-03-29T16:59:22Z'
    title: Items Service
host: hjtiuj2ou1.execute-api.[secure].amazonaws.com
basePath: /prod
schemes:
    - https
paths:
    /items:
        get:
            responses:
                '200':
                description: Ok
                '401':
                description: Authorization information is missing or invalid
            x-amazon-apigateway-integration:
                uri: >-
                arn:aws:apigateway:[secure]:lambda:path/2015-03-31/functions/arn:aws:lambda:[secure]:[secure]:function:ApiLambdaCrudDynamoDBExam-getAllItemsFunction0B7A9-1MLKSKO1RUL3I/invocations
                passthroughBehavior: when_no_match
                httpMethod: POST
                type: aws_proxy
            x-amazon-apigateway-request-validator: Validator
        post:
    ...

Das sieht schon sehr gut aus. Allerdings fehlt jetzt noch die besagt Parameter Validierung. Dafür muss eine zweite Swagger definition erstellt werden templates/swagger_validations.yaml und sieht in etwas so aus:

paths:
    /items:
        get:
        parameters:
            - name: alfUserId
            in: query
            required: false
            type: string
            $ref: '#/parameters/alfUserIdParam'

Was wir jetzt aber wollen ist ein merge beider swagger Files. NPM bietet ein nützliches Tool zum mergen von YAML Files:

npm i -g merge-yaml-cli

Die Swagger Definition tmp/swagger_full.yaml beinhaltet nun die aktuelle LambdaUri und die Parameter Validierung:

swagger: '2.0'
info:
  version: '2020-03-29T16:59:22Z'
  title: Items Service
host: hjtiuj2ou1.execute-api.eu-.amazonaws.com
basePath: /prod
schemes:
  - https
paths:
  /items:
    get:
        parameters:
            - name: alfUserId
            in: query
            required: false
            type: string
            $ref: '#/parameters/alfUserIdParam'
        responses:
            '200':
            description: Ok
            '401':
            description: Authorization information is missing or invalid
        x-amazon-apigateway-integration:
            uri: >-
            arn:aws:apigateway:[secure]:lambda:path/2015-03-31/functions/arn:aws:lambda:[secure]:[secure]:function:ApiLambdaCrudDynamoDBExam-getAllItemsFunction0B7A9-1MLKSKO1RUL3I/invocations
            passthroughBehavior: when_no_match
            httpMethod: POST
            type: aws_proxy
        x-amazon-apigateway-request-validator: Validator
    post:
    ...

Nun kann dieses Swagger File im zweiten CDK Deployment angewendet werden:

export WITH_SWAGGER='true' && cdk deploy --require-approval never

Achtung!: Immer gut darauf aufpassen das auch ein neues Stage Deployment in AWS API Gateway kreiert wurde. Ich mache das in Travis mit der AWS CLI:

aws apigateway create-deployment --rest-api-id $REST_API_ID --stage-name prod

Zusammenfassung

Swagger Definitions eigenen sich hervorragend zur Erstellung, Editierung, Dokumentation und Testung vom APIs wie der von AWS Api Gateway. Sie eigenen sich nicht nur direkt im Backend um dieses Backend zu erstellen, sondern sind nützlich sogar im Frontend da aus den Swagger Definitions Client Libraries generiert werden können und es dem Frontendentwickler gelingt durch die Swagger Dokumentations UI das Backend viel besser und in kürzerer Zeit zu verstehen.

Werde ein Patreon!

AWS CDK Tutorial mit Travis Deployment

Sat, 28 Mar 2020 00:00:00 GMT

Ahoi AWS'ler

Für ein privates Projekt habe ich mich in den letzten Tagen an ein AWS CDK Example gemacht. AWS bietet eine Palette von tollen AWS CDK Beispielen. Die Erfahrung die ich gemacht habe, war so gut, dass ich mich entschlossen habe, einen Blogpost darüber zu schreiben. Schon sehr früh in meiner AWS Karriere durfte ich mich mit CloudFormation beschäftigen. Seit neuem scheint ein neues Kind im Block zu sein mit Namen AWS CDK (Cloud Development Kit), welches bevorzugt als Sprache zur Beschreibung der Infrastruktur in AWS genutzt werden kann. CDK verspricht eine willkommende Alternative zu Cloudformation zu sein, da man anstelle wie üblich diese im eher komplexen YAML schreiben muss, werden im CDK richtige Programmiersprachen wie Java, Python, JS oder Typescript unterstützt. Ich finde das ein super Idee da man, wenn man sich für z.B. Typescript als Sprache für die Lambdas entschieden hat, auch diese für das CDK verwenden kann. Mein Beispiel Code CDK Example Repo ist auf GitHub. In den nächsten Abschnitten werde ich kurz die einzelnen Schritte für die Repo Erstellung beschreiben.

Das wird Benötigt

Wenn du AWS CDK ausprobieren möchtest, benötigst du einen AWS Account. Darüber hinaus brauchst du AWS CLI Credentials, welche es deinem Deployment erlauben, Ressourcen in deinem AWS Account zu nutzen. Üblicherweise erstellt man dafür einen IAM User. Wichtig dabei ist, dass du dir die Zugangsdaten also der die Access Key Id und der Secret Access Key gut abspeicherst. Diese werden nachher im Deployment benötigt. Das verwendete AWS Beispiel verwendet NPM als Package Manager. Das bedeutet es kümmert sich um die Dependencies wie zum Beispiel dem aws-cdk welches mit dem folgenden command installiert wird:

npm install -g aws-cdk

NPM is hier erhältlich.

Git Repo Vorbereiten

So nun geht es los. Zuerst erstellen wir unser GitHub Repository welches noch komplett leer ist. Bei mir habe ich es cdk-example genannt. Dann sollte das AWS CDK Examples Repo geforkt und local ausgecheckt sein. Mit dem Hintergrund, dass wir so einfacher Cherry Picking betreiben können und somit einfach die für uns interesannten Beispiele darin in unser Repository kopieren können.

Wenn man sich das AWS CDK Examples Repository anschaut hat man nun sprichwörtlich die Qual der Wahl. Ich selber kann die Beispiele von der Typescript Kategorie empfehlen da sie reichlich sind und Typescript anscheinend immer beliebter wird als Programmiersprache. Auch empfehle ich mit dem Api Cors Lambda Crud DynamoDB Example anzufangen, da es schon sehr viele AWS Services beinhaltet wie API Gateway, Lambda und DynamoDB. Das Beispiel is ein einfacher CRUD Storage welches mit DynamoDB als DB fungiert. Am besten den bestehenden Quellcode nicht abändern und erstmal versuchen ihn nur zum Laufen zu bekommen. Ich selber hatte eine kleine Schwierigkeit. Das Beispiel hat eine missing Dependency. Undzwar fehlt die NPM uuid Library, welche zur generierung von IDs verwendet wird. Dafür muss ins src/ Verzeichnis gewechselt werden und die folgenden Commands ausgeführt werden:

npm init
npm install uuid

Auch muss der Code etwas angepasst werden, da sich die uuid mit den Versionen etwas geändert hat. Alternativ kann auch einfach aus meinem publizierten GitHub Repo kopiert werden. Im nächsten Abschnitt bringen wir dann das Beispiel zum laufen.

CDK Manuell Deployen

Im vorherigen Abschnitt haben wir das Repo soweit vorbereitet, jetzt wollen wir natürlich deployen! Da wir unser Deployment in AWS haben, muss sichergestellt werden, dass die Zugangscredentials richtig eingestellt sind. In der Das wird Benötigt haben wir bereits die Credentials erhalten. Es gibt verschiedene Möglichkeiten diese Credentials deinem Build zur Verfügung zu stellen. Das automatisierte Deployment in Travis funktioniert mit Environment Variablen. Für das manuelle Deployn ist es komfortabeler die Credentials im aws config folder zu erstellen. dafür einfach die folgenden Datein einfügen:

~/.aws/conf und ~/.aws/credentials ebenfalls! Für Windows Nutzer einfach deinen Benutzerordner anstelle der ~ benutzen. Mit folgenden Content befüllen:

[default]
aws_access_key_id = AKI...
aws_secret_access_key = fIr...
region = eu-west-2

Du solltest dir eine Region aussuchen welche dicht zu dir sind und viel Funktionalität anbieten. Da die Frankfurter Region oftmals hinterher ist mit neuen Features, habe ich mich für die London Region eu-west-2 entschieden.

Jetzt ins Repo wechseln und die folgenden Befehle ausführen:

npm install -g aws-cdk
npm install
npm run build

Die npm install Befehle laden die Dependencies. In der Regel müssen diese nur selten ausgeführt werden. Der Run Befehl hingegen immer wenn Änderungen durchgeführt worden sind. Interessante Tatsache ist, dass dieser die TypeScript Files in JavaScript Files konvertiert. Da TypeScript ein Superset vom JavaScript ist, muss man so das Tooling um TypeScript nicht neu erfinden und nutzt einfach die vorhandenen von JavaScript. Aber aufpassen und nicht verwirren lassen von diesen generierten JS Files. Eventuell machst du deine Änderungen genau an diesen und wunderst dich, warum die Änderungen nicht im Deployment geschehen.

Als nächstes muss CDK so konfiguriert werden, dass es weiß welcher Account und welche Region genutzt werden soll. Warum CDK das nicht aus dem AWS Folder generieren kann, verstehe ich allerdings auch nicht. Dann kann CDK deployed werden:

cdk bootstrab aws //{account}/{region}
cdk deploy

Auch interessant mit:

cdk synth > cfn.yaml

Kann man sich das generierte CloudFormation Template anschauen.

Automation mit Travis

Noch hält sicher der manuelle Aufwand für das Deployment gering, aber das könnte bei mehr werdender Komplexität sicher ändern. Von daher habe ich bisher super Erfahrungen gemacht, wenn ich so viel wie möglich davon automatisiere. Und nunja stellt euch mal vor wie cool es ist einfach nur mit einem Push zu master die Produktionsumgebung zu ändern. Einen kleinen Vorgeschmack wie das aussehen könnte beschreibe ich hier. Auch sei wieder gesagt, dass ihr euch meine Travis Definition gerne anschauen könnte hier CDK Example Repo.

Was ich dort in Travis mache ist recht einfach erklärt. Ich führe einfach nur die manuellen Deployschritte von der vorherigen Sektion in Travis aus. Da Travis meine AWS Credentials in Form von verschlüsselten Environmental Variables hat, erlaube ich es es in meinem AWS Account Ressourcen zu manipulieren. Die folgenden Environmental Variablen waren dafür nötig: AWS_ACCESS_KEY_ID, AWS_ACCOUNT_NUMBER, AWS_DEFAULT_REGION, AWS_SECRET_ACCESS_KEY, CDK_DEFAULT_ACCOUNT, CDK_DEFAULT_REGION.

Nur das Deployment nicht mehr manuell ausführen zu müssen, scheint auf den ersten Blick vielleicht nicht sehr nützlich, aber glaubt mir es lohnt sich! Nachdem das CDK Deployment fertig ist werden dann Postman Tests in Form von Requests und Response Validations ausgeführt. Näheres dazu beschreibe ich in der nächsten Sektion.

Stack Testing mit Postman

Ich denke mittlerweile weiß jeder über Postman bescheid. Es ist ein geniales Tool zum testen von APIs, die mittels Request und Responses arbeiten. In meinem Fall ist das ein REST API welches durch AWS API Gateway definiert ist. In meinem GitHub repository habe ich eine kleine Sammlung von Requests und Response Tests, welches in Postman als Collections bezeichnet werden, zusammengestellt. Diese können dann einfach mittels der CLI Newman zum Ausführen von den mit Postman erstellten Collections genutzt werden. Newman muss dann natürlich vorher auf der Build Maschine installiert sein. In meinem Repo mache ich das via NPM im package.json. Dazu einfach den folgenden Befehl ausführen:

npm install newman

Der kreative Prozess des Collections schreiben sind dann so aus, dass in Postman eine neue Collection erstellt wird und Requests geschrieben werden. Das Request läuft gegen die REST API und gibt ein Response zurück. Das Response kann dann validiert werden. Postman bietet für die Validierung der Responses eine Umfangreiche Möglichkeiten. So kann man einfach den Statuscode im Response mit dem erwarteten Wert abgleichen, andere Erwartungswerte vergleichen, Variablen erstellen für ide nächsten Requests genutzt werden können und vieles vieles mehr. Ein Tip von mir, versucht die Menge an Tests gering zu halten.

Zusammenfassung

AWS noch recht neues CDK ist ein tolles Werkzeug zum erstellen von AWS Cloudformation Stacks. Sehr toll finde ich, dass man es in der gleichen Programmiersprache schreiben kann in der auch eventuell verwendete Lambdas sind. Kombiniert mit automatischen Deployment und Tests zum Beispiel mit Travis, erlaubt es schnell und effizient neue Änderungen am Stack durchzuführen. Ich glaube auch, dass es dadurch nicht oder weniger nötig ist Lambdas lokal testen zu müssen. Wenn ihr Hilfe bei eurem AWS CDK Projekt braucht, zögert nicht mich oder die hilfsbereite CDK Gitter Community zu fragen.

Werde ein Patreon!

Bash Script Contribution für den Alfresco Docker Installer

Sat, 21 Mar 2020 00:00:00 GMT

Hi Alfrescans,

Ich habe tolle Erfahrungen gesammelt in meinem letzten Projekt mit dem Alfresco Docker Installer. Näheres darüber einfach in meinem vorherigen Blogpost nachlesen. Nun bin ich natürlich gespannt darauf sinnvolle neue Features zu kontributieren. Eines davon ist das Start Script welches als Wrapper für das Docker Compose File genutzt werden kann. In meinen bishering Alfresco Docker Compose Projekten habe ich immer dieses Script implementiert da es einige wertvolle Zusatzfunktionen bietet. Welche das sind werden im nächsten Abschnitt erklärt. Für mich macht es daher Sinn das Start Script dem Installer zur Verfügung zu stellen.

Features

Das wohl wichtigste Feature is eine eingebaute warte Routine. Dieses wartet solange bis ACS fertig gebooted hat. Das ist zum Beispiel sehr nützlich wenn man nach dem Start von ACS tests auführen möchte mit Tools wie Postman. Auch können Daten via REST API geladen werden, wenn ACS fertig mit booten ist. Die warte Routine ist mit NPM's wait-on implementiert. Es macht Sinn auf die breite Palette an Tools im public NPM Repository zurückzugreifen, da ich dann diese nicht selber implementieren musst und außerdem sind diese in der Regel gut getested und bieten wenig Freiraum für Fehlerfälle.

Das nächste Feature ist besonders wichtig für mich da ich mit dem Windows arbeite. Wenn man versucht Docker Compose mit Windows auszuführen bekommt man eventuell ein Problem mit den Volumes, da diese nicht die Windows Path schreibweise ootb unterstützen. Glücklicherweise hat die Docker Compose Community eine Lösung bereitgestellt. Es muss einfach die folgende Environment Variable gesetzt werden bevor Docker Compose gestartet wird:

export COMPOSE_CONVERT_WINDOWS_PATHS=1

Das wird nun vorher gemacht wenn man das Start Script zusätzlich mit dem -wp flag startet.

Die nächsten Features haben es bisher noch nicht in den Alfresco Docker Installer geschafft, was sich aber bald ändern könnte und welche ich persönlich schon viel bei meinen Deployment nutze. Es ist möglich mit -hi und -hp die Host IP und den Host Port dynamisch mit dem Start Script zu setzen. Ich finde das sehr praktisch wenn man sich in Umgebungen befindet welche öfter mal die IP wechseln. Zurzeit löst das aber der Installer so, dass er bei der Installation die Host IP und den Host Port abfragt. Es ist also schon konfigurierbar, wenn auch nur während der Installation selbst.

Mehr Features sind zwar möglich aber zurzeit nicht implementiert. Z.B. Das Laden von Testdaten mit dem REST API. In meinem ADF AI Prototypen habe ich noch zusätzlich ein -b für build the Angular Webapp und ein -aca so das nur der ACA Container redeployed wird um ein schnelles Entwickeln mit der ACA Webapp zu gewährleisten. Wie genau ich das Start Script contributed habe, stelle ich im nächsten Abschnitt vor.

Contribution

Zuerst sollte ein Fork vom Alfresco Docker Installer kreiert werden. Auf diesem können dann die Anpassungen gemacht werden. In meinem Fall ist es das Start Script mit Filenamen start.sh. Ich habe das Script unter template/scripts abgespeichert und das Yeoman Setup so eingestellt, dass das Script optional hinzugefügt werden kann, sehr ähnlich wie auch der LDAP Service hinzugefügt wird. Alle Änderungen sollten auf deinen Fork in Form eines Remote Branches gesichert werden. Dafür muss zunächst ein lokaler Branch erzeugt und Änderungen gepushed werden:

git branch startscript
git add --all
git commit -m "added startscript"
git push -u origin HEAD:startscript

Sind nun alle Änderungen vollzogen und ausgiebig getestet, kann ein Pull Request zum Alfresco Docker Installer Repository erstellt werden. Dafür geht man einfach auf die Installer Github Seite. Dort erscheint dann ein Create Pull Request Button.

Oh ja eine Sache bitte noch beachten. Wenn du ein neues Feature contributen willst wäre es sehr toll und best practice wenn du auch dazu einen Test schreibst, welcher garantiert dass das neue Feature funktioniert. Ich habe das im .travis File gemacht. Nun werden Deployments und Start von Alfresco mit und ohne zur Hilfenahme des Start Scriptes getestet.

Ausblick

Als nächstes möchte ich gerne Alfresco's neuen Alfresco Identity Management Service auch AIMS genannt als Kontribution bereit stellen. Dafür wird ein Keycloak Container hinzugefügt, sowie die Alfresco Properties angepasst. AIMS macht nur Sinn wenn man auch einen Identity Provider besitzt. Also soll AIMS nur hinzugefügt werden, wenn LDAP während der Installation ausgewählt wird.

Zusammenfassung

Dieser Artikel beschreibt eine kurz Übersicht zu meiner ersten Kontribution zu dem Alfresco Docker Installer. Zu einem nutze ich das Repository bereits für meine Projekte und es bot mir die perfekte Möglichkeit den Yeoman template Installer besser zu verstehen. Das Start Script bietet viele neue zusätzliche Funktionen. Wie man eine Contribution machen kann, wurde ebenfalls ausführlich beschrieben. Hast du eventuell auch eine tolle Idee wie man den Installer verbessern könnte? Ich freue mich auf dein Feedback.

Werde ein Patreon!

Alfresco's Amps und Jars mit Docker Testen

Sun, 15 Mar 2020 00:00:00 GMT

Hi Alfrescans,

In diesem Artikel werde ich beschreiben wie man Docker nutzen kann um Amps und Jars Erweiterungen für ACS zu testen. Für einen Kunden von OBJECT wurden Share Customizations sowie Costume Content Models entwickelt, welche ich schnell und einfach weiterentwickeln möchte.

Interassant hinzukam für mein Projet, dass die Amps für ein ACS 5.2.6 Deployment geschrieben wurden und Docker als Deployment erst ab ACS 6.0 supported ist. Es war also relativ challenging das Docker Deployment so anzupassen, dass alles funktioniert. Wenn deine Erweiterungen für ACS 6.0 oder neuer geschrieben wurden, sollte es einfacher sein.

Warum Docker Deployment?

Der altmodische Weg ist es die lokal kompilierten Amps und Jars an einem lokalen ACS Deployment zu testen, welches komplett ohne Docker konfiguriert wurde. Das bedeutet Tomcat muss installiert und ACS mit all seinen Dependencies muss auch vorhanden sein. Klar der altmodische Installer hilft dabei, es ist trotzdem eine zeitaufbringende und wenig befriedigende Aufgabe Alfresco so installieren zu müssen. Zusätzlich kommt dann ja noch das man die Amps immer per Hand installieren und evtl. deinstallieren muss. Nicht schön!

Docker Container adressieren genau diese Probleme. Mit Hilfe des Dockerfiles kann ich niederschreiben welche Konfigurationsschritte unternommen werden sollen. Mit Git kann das sogar versioniert passieren und Deployments können blitzschnell zu vorherigen funktionierenden Versionen reverted werden. In diesen Dockerfiles kann man die Installation des Tomcats sowie die Konfiguration von ACS und vieles mehr niederschreiben.

Klingt nach ner Menge Arbeit? Nö! Alfresco maintained ACS Docker Deployments mit Version 6.0 oder neuer. Wie so ein einfaches Docker Deployment, wobei die Container mit Docker Compose orchestriert werden lässt sich hier bestauen für ACS Enterprise und hier für ACS Community. Die Docker Images welches diese Deployment sind hier ACS Enterprise Image und hier ACS Community Image. Zugegeben diese Deployments und Images sind recht limitiert in Punkto Customizations. Das ist zwar gut für einen schnellen Einstieg, erlaubt uns aber nicht unsere lokal erstellten Amps zu testen. Wie das ermöglicht wird, beschreibe ich im nächsten Kapitel.

Git Repo Vorbereiten

Falls der Build Code eure Amps und Jars in verschieden Git Repos liegen, macht es Sinn diese auf einem Repo zu vereinigen um die Docker Image Erstellung zu erleichtern. Z.B. könnte die repo und share amp in gleichnahmgen Unterverzeichnissen liegen. Falls Maven als Build und Packagingtool verwendet wurde, ist das einfach zu realisieren mit Parent Poms. Nach der möglichen Umstrukturierung muss der Build getestet werden, ob auch die Amps oder Jars erstellt werden. Bei mir wurde das durch das durch den einfachen Maven Befehl ausgeführt:

mvn clean install

Nun soll das Docker Backend installiert werden. Die Orchestrierung der Container soll mit Docker Compose geschehen. Zum Glück gibt es dafür den Alfresco Docker Installer der einfach bedienbarer, mit Yeoman unterstützter, Template Installer ist und schon eine breite Palette an Installoptionen wie der ACS Version, ob LDAP verwendet werden soll usw. bietet. Ich würde vorschlagen einfach erstmal einen Ordner mit namen docker im Git Repo zu erstellen und in diesem das Docker Compose Backend mit dem Alfresco Docker Installer zu installieren. Nach der installation sollte das Deployment mit

docker-compose up --build

hochgefahren und die Urls getestet werden welche da sind:

http://localhost:80  Alfresco Content App
http://localhost:80/alfresco 
http://localhost:80/share

Wenn alles funktioniert hat, einfach das Deployment runterfahren mit:

docker-compose down

Im nächsten Abschnitt wird erklärt wie die Share oder Repo Amp / Jar in die Image mit eingebunden werden kann.

Share und Repo Images Anpassen

Nun isst es an der Zeit die Share und Repo Modifikationen mittels Amps oder Jar in die Image zu gießen. Idealerweise sollten die frisch kompilierten Amps / Jars aus dem target Folder dafür genutzt werden. am einfachsten geht dass wenn wir das Dockerfile vom docker/alfresco nach repo/ und docker/share nach share/ verschoben werden. Dadurch erlauben wir Docker bei der Bildung der Image auf das jeweils dortige target Verzeichniss zuzugreifen kann. Jetzt einfach in der repo und share Dockerfile die Anweisung setzen, dass die Amps / Jars aus dem target Folder in die Image kopiert werden wie hier z.B.:

COPY modules/amps $TOMCAT_DIR/amps
COPY modules/jars $TOMCAT_DIR/webapps/alfresco/WEB-INF/lib

COPY target/myamp-62-repo-1.0-SNAPSHOT.amp $TOMCAT_DIR/amps/myamp-62-repo-1.0-SNAPSHOT.amp

Nun muss noch das docker/docker-compose.yaml File geändert und die Verzeichnisse für die Repo und Share Image angepasst werden. In unseren Setup sehe dass dan so aus für Repo:

context: ./../repo

Und so für Share:

context: ./../share

Amps / Jars für ACS 5.2

Wenn ihr auch so wie ich Amps oder Jars für ein ACS 5.2 Deployment testen wollt, kommen ein paar Schwierigkeiten hinzu. Es kann passieren, dass die verwendeten Dependencies für die 5.2 Amp / Jar nicht mehr kompatibel mit dem ACS Docker Deployment sind. Auffallen wird das durch Errors wärend ACS gebooted wird. Der erste Schritt ist herauszufinden welche Dependencies (in der Regel Jar files auf dem Tomcat Classpath) Probleme verursachen. Es empfiehlt sich dann ein Maven Profil für die 6.2 amp zu kreieren, welches dann die Dependencies mit der richtigen Version nachlädt.

Dann müssen diese auch im Dockerfile gelöscht werden. Nicht entmutigen lassen, dass kann schon recht Haaresträubend und Zeitaufwendig werden! Bei mir sah das in etwa dann so aus:

ARG POI_V=4.0.1
RUN rm -f $TOMCAT_DIR/webapps/alfresco/WEB-INF/lib/poi-${POI_V}.jar 
RUN rm -f $TOMCAT_DIR/webapps/alfresco/WEB-INF/lib/poi-ooxml-${POI_V}.jar
RUN rm -f $TOMCAT_DIR/webapps/alfresco/WEB-INF/lib/poi-scratchpad-${POI_V}.jar

ARG TIKA_V=1.21-20190624
RUN rm -f $TOMCAT_DIR/webapps/alfresco/WEB-INF/lib/tika-core-${TIKA_V}-alfresco-patched.jar
RUN rm -f $TOMCAT_DIR/webapps/alfresco/WEB-INF/lib/tika-parsers-${TIKA_V}-alfresco-patched.ja

Zum testen kann dann die Amp / Jar die mit dem 6.2 Profil gebaut wurde, verwendet werden. Aber aufpassen für das 5.2 Deployment muss die Amp / Jar ohne das 6.2 Profil verwendet werden, ansonsten kann es zu anderen Dependency Problemen kommen!

Zusammenfassung

Amps und Jars sind immer noch die beliebteste Methode Customizations an ACS und Share durchzuführen. Diese lokal zu testen, muss auch nicht aufwendig sein, wenn man Docker verwendet. Ich hoffe ich konnte dich animieren zukünftig mal Docket für die Erweiterungen zu benutzen. Falls ja schreib mir doch bitte deine Erfahrung :).

Werde ein Patreon!

Meine Smart Home Erfahrung

Sat, 07 Mar 2020 00:00:00 GMT

Hallo Leute.

Im Oktober 2019 hatte ich die großartige Gelegenheit, mir ein Haus in der schönen deutschen Stadt Ludwigslust zu kaufen. Es ist ein altes, aber kürzlich renoviertes schönes Haus. Da ich mich sehr für Technik interessiere, konnte ich es kaum abwarten, ein paar coole Smart Home Sachen auszuprobieren.

Ich habe tolle Zeiten mit den folgenden Smart Home Geräten gemacht:

Smart Bulbs Teckin: Das sind Smart Bulbs mit integriertem WLAN. Sie passen in normale Fassungen für herkömmliche Beleuchtung.

Smart Sockets Teckin: Schön designte Steckdosen, die ihr zwischen das elektrisches Gerät und der Steckdose platzieren könnt, um es fernzusteuern. Es funktioniert auch mit WLAN.

Smart Garage Door: Eine coole Erweiterung für des Garagenmotors. Damit kann das Garagentor über WLAN ferngesteuert werden.

Thermostate: Ein schönes kleines Gerät, um die Heizungszeiten zu bestimmen. Diejenigen die ich getestet hatte, hatten keine WLAN- oder Bluetooth-Verbindung.

Weiter unten im Artikel habe ich Links zu diesen Geräten bereitgestellt. Meine oberste Priorität war es, langfristig Kosten wie Strom oder Gas zu sparen und die Lebensqualität von mir und meiner Frau zu verbessern.

Es gibt Dutzende von Smart Home Lösungen, und du musst vorsichtig sein, welche du verwenden möchtest, da Gadgets von verschiedenen Anbietern nicht immer gut zusammenspielen.

Ich habe mich für Gadgets entschieden, die sich mit der 'Smart Life'-App gesteuert werden können, da sie ein riesiges Angebot für alle Arten von Smart Home-Geräten bietet.

Welche Funkfrequenz?

Es ist wichtig zu erwähnen, dass alle meine Smart Home-Geräte nur in einem drahtlosen 2,4-GHz-Netzwerk funktionieren. Es ist unwahrscheinlich, dass du Geräte für das 5-GHz-Netzwerk findest. Mit 2.4 GHz sind die Länge der Wellen im Vergleich zu 5 GHz länger und dringt somit besser durch Wände, hat aber dafür eine geringere maximal erreichbare Bandbreite. Tatsächlich benötigen Smart Home-Geräte keine hohe Bandbreite, das ist also in Ordnung. Stell sicher, dass beide Netzwerkfrequenzen auf deinem Router eingerichtet sind!

Intelligente Glühbirnen Überall

Ich habe mich für den Kauf der Smart WLAN LED-Leuchten von Teckin entschieden. Diese können in einem Bündel gekauft werden, um ein bisschen zu sparen. Was soll ich sagen, ich liebe diese Smart-Lampen wirklich. Ich habe bereits Geld gespart, indem ich nur die vorhandenen Lampen ersetzt habe, die mit 40 W betrieben wurden, um die Smart-Lampen zu verwenden, die nur 8 W zum Leuchten benötigen.

Da es vorkommen kann, dass man mal vergisst das Licht auszuschalten, habe ich jede smarte Glühbirne so konfiguriert, dass sie sich um 1 Uhr morgens selber ausschaltet, da zu diesem Zeitpunkt normalerweise niemand mehr wach ist. Leider gibt es einige Stellen im Haus, an denen das WLAN-Signal nicht stark genug ist. Für diesen Fall habe ich keine intelligente Glühbirne installiert. Ich habe nur die 40 W gegen eine einfache 8 W LED ausgetauscht.

Smarte Sockets (Steckdosen)

Das nächste intelligente Gerät waren die Smart Sockets. Ich liebe diese Steckdosen, da sie eine Reihe von schönen Funktionen haben. Erstens, da wir in Deutschland keine manuellen Ein-Aus-Schalter in die Steckdosen integriert haben, wie ich aus Großbritannien gewöhnt bin, ist es sehr praktisch, dass diese intelligenten Steckdosen einen Ein-Aus-Schalter haben. Dann muss man beim Herausziehen kaum Kraft aufbringen.

Die nächste coole Funktion dieser Sockets ist, dass sie per Zeitplan aus und eingeschaltet werden können. Zum Beispiel werden Nachts dann alle Geräte an der Fernsehstation ausgeschaltet, da diese selbst im Standby immer noch viel Strom verbrauchen. Auch die Mikrowelle wird zeigesteuert. Da es sich um eine altes Modell handelt, verbraucht sie viel Energie, selbst wenn sie im Standby ist. Wenn jemand sie wieder einschalten möchte, muss einfach die Taste am Socket gedrückt werden.

Zu guter Letzt die Waschmaschine. Diese hat jetzt auch eine intelligente Steckdose bekommen. Der Ein-Aus-Schalter ist praktisch, um nicht mit roher Gewalt am Kabel ziehen zu müssen. Es spart Energie, weil es die Maschine vollständig ausschaltet. Wirklich cool wirds jetzt! Ich habe die "Smart Life" App so konfiguriert, dass sie mir eine Benachrichtigung sendet, wenn die Wäsche fertig ist. Das ist möglich, weil der Socket eine Benachrichtigung auslösen kann, wenn eine gewisse Wattzahl erreicht wird. Super praktisch!

Intelligentes Garagentor

Stell dir vor, du könntest den Garagentor öffnen indem du nur "Hey Siri, Garage" sagst. Nun, das ist bei mir der Fall. Und bis jetzt fühle ich mich wie Batman, wenn er seine Höhle automatisch öffnet, sobald er sich in seinem Batmobil nähert. Also sehr sehr cool. Wie habe ich das gemacht? Als ich das Haus gekauft habe, gab es bereits ein elektrisches Garagentor, das mit einer einfachen Infrarotfernbedienung gesteuert werden konnte. Ja, das ist schön, aber es ist nicht wirklich praktisch, diese Fernbedienung immer bei sich zu haben, und sie kann auch nicht sprachgesteuert werden. Also schrieb ich den Namen des Garagenmotors auf und kaufte bei Amazon ein Smart Garage-Gadget, das mit diesem Motor und der 'Smart Life'-App kompatibel ist.

Die Installation des Gerätes war einfach. Ich habe nun die folgenden Vorteile. Die altmodische Fernbedienung funktioniert immer noch, aber jetzt kann ich die Tür mit meinem Smartphone und der App 'Smart Life' oder mit direkt per Siri öffnen und schließen. Außerdem kann ich auf meinem Telefon überprüfen, ob die Garage geöffnet oder geschlossen ist, und ich erhalte einen Alarm, wenn die Tür geöffnet wird. Und wirklich cool, der Motor für die Garage wird Nachts ausgeschaltet. Das spart Kosten und erhöht die Sicherheit.

Zeitgesteuerte Thermostate

Ich bin sehr zufrieden mit meinen "Smart" Thermostaten von Eqiva Radiator die ich für viele meiner Heizungen nutze. Obwohl ich nicht sicher bin, ob sie unter die Kategorie der Smart Home-Geräte fallen, da sie im Grunde nur über das Display konfigurierbar sind und ich sie derzeit nur zum planmäßigen Heizen und einfachen Ein- und Ausschalten verwende. Wie auch immer, es war sehr einfach sie zu installieren und sie funktionieren ausgezeichnet.

Smart Home-Geräte

Wenn dir einige der hier erwähnten Gadget gefallen haben, schaue dir doch diese Affiliates an (damit unterstütz du mich auch und ich würde eine kleine Provision erhalten, welche ich direkt in meine Blogpost-Arbeit reinvestieren würde):

Smart Bulbs Teckin (Amazon): UK DE USA

Smart Sockets Teckin (Amazon): UK DE USA

Intelligentes Garagentor (Amazon): UK DE USA

Thermostate (Amazon): UK DE

Zukünftige Ideen

Ich habe das Gefühl, dass ich gerade erst mit meiner kleinen Smart Home-Reise begonnen habe. Bald möchte ich komplexere Technologien wie das Tado Smart Radiator-System ausprobieren. Außerdem denke ich darüber nach, mir meinen eigenen privaten Smart Home Server mit einem PI einzurichten. Ich habe dazu einige interessante Artikel in einer deutschsprachigen Zeitschrift gefunden.

Zusammenfassung

Smart Home-Geräte sind nicht nur Werkzeuge zum Herumspielen. Sie helfen tatsächlich dabei Geld zu sparen und die Lebensqualität verbessern. Wenn du vielleicht daran denkst, einen Blick in die Welt der Smart Home-Geräte zu werfen, empfehle ich dir die WLAN-Smart Bulbs und Smart Sockets, für deren Funktion keine anderen Geräte erforderlich sind! Sei kreativ, wie du sie auf intelligente Art und Weise einsetzen kannst. Und am wichtigsten hab Spaß dabei!

Werde ein Patreon!

ADF App Bauen vom Scratch

Sat, 29 Feb 2020 00:00:00 GMT

Good day

Wie im vorangegangen Blog Post erwähnt, arbeite ich an einem spannenenden AI Prototyp welcher ACS Community als Content Managment System verwendet. Darüber hinaus laufen noch gewisse AI Services welche über die ACS Schnittstelle wie CMIS und REST gewisse AI Aktionen auf ACS durchführen. Leider muss ich hier etwas im unklaren bleiben, um Firmengeheimnisse zu waren. Soviel sei allerdings gesagt OBJECT und die Partnerfirma planen ein Webinar wo unter anderem auch der hier besprochene Prototyp gezeigt wird. Zurück zum Thema! Für die Webapp haben wir uns für ADF entschieden.

In den nächsten Kapiteln werde ich erklären wir man ein ADF Webapp Projekt erstellen kann und es nach wünschen zu ändern. Diese sollten sich auch wenig bis garnicht unterscheiden ob man nun mit Windows 10, MacOS oder Linux arbeitet. Ich selber mag alle drei Operation Systeme.

Das wird Benötigt

Ihr solltet Docker, Docker Compose, NPM und YARN installiert haben. YARN brauchte ich da ich auf einen Windows Laptop arbeite und YARN in der Lage ist die Windows Paths in Unix Paths zu konvertieren. Aufpassen bei Docker! Die Standardinstallation bei Docker erlaubt nur die Verwendung von 2 GB RAM für die Docker Compose Deployments, welches viel zu wenig ist für ACS Community und die anderen Services! Dafür braucht ihr mindestens 10 GB und für ACS Enterprise mindestens 12 GB. Vorzugsweise mehr! Zusätzlich, falls ihr eigene Amps, Jars oder andere Customizations für das ACS Deployment einrichten wollt, empfiehlt es sich Java und Maven zu installieren.

Git Repository Vorbereiten

Als base für den Prototyp verwende ich das ACA Git Repository. Zum einen hat es viele ADF Component und API Libaries bereits integriert und zum andern stellt es eine Shell bereit die schon recht umfangreich das ACS Backend verwendet. Darüber hinaus wird es einfach möglich sein, Updates vom ACA repository in meine Webapp einzuspielen. Und ziemlich cool, ich kann direct zurück kontributieren.

Nun geht es ans Git Repository. Für mich viel die Wahl auf ein privates Git Repository bei uns im OBJECT GitLab, da es ja eine Vorbereitungsprojekt für ein Webinar werden soll und niemand die Webapp schon vorher sehen darf. In deinem fall kannst du vielleicht ein public Git Repository nehmen. Der weitere Verlauf wird sich dadurch nicht ändern.

Wie vorhin angesprochen würde ich gerne in der Lage sein Updates vom ACA repository problemlos einzuspielen. Darüber hinaus will ich natürlich soviel es geht vom ACA repository wiederverwenden. Ich habe mich daher für Git's submodules entschieden. Damit bin ich dann auch in der Lage zurück zu kontributieren. Ich habe ein Fork vom ACA repo erstellt https://github.com/mmuller88/alfresco-content-app . Ich rate dir das gleiche zu tun. Dann einfach ins Projektverzeichniss wechseln und den Fork als submodule laden:

git submodule add https://github.com/<USER>/alfresco-content-app

Eventuell kann auch der folgende Befehl nützlich sein um die Submodules, welches in diesem Fall ja nur ACA ist, zu aktualisieren:

git submodule update --init --remote

Ich brauchte es da ich zu einem Fix Branch gewechselt habe im .gitmodules File.

ACA Starten

Wenn nun das Webapp Repository soweit konfiguriert wurde, können wir testen ob das Docker Compose Deployment im alfresco-content-app Folder auch startet. In meiner Vorherigen Position als Fullstack Entwickler bei Alfresco hatte ich die Gelegenheit viel mit dem ACA Repository zu arbeiten.

Zum starten des ACA Deployments sind die folgenden Befehle nötig:

yarn install

Um die nötigen Node Dependencies zu laden.

yarn run build

Um die ADF Webapp im dist/app Verzeichniss zu erstellen. Darüber hinaus erstellt der Befehl auch die ADF Extensions mit namen @alfresco/aca-shared und @alfresco/adf-office-services-ext . Als frühen Ausblick sei gesagt, Ziel wird es sein für die eigene ADF Webapp eine eigene Extension zu schreiben. Dies hat praktische Gründe wie der Modularisierung und Distributierung.

Das start.sh im ACA Verzeichniss ist ein ausgeklügelt Script. Ihr solltet es bevorzugsweise nutzen um das Deployment zu starten. Die einzelnen Parameter lassen sich mit dem -h oder --help Flag erfragen. Für meinen Windows Laptop muss ich dann diese Parameter Konfiguration nutzen:

.\start.sh -wp -hi 192.168.0.237

Das -wp Flag wandelt die Linux Dateipfade in Windows Dateipfade um und -hi steht für Host IP und übergibt dem Deployment die IP des Computers. Wenn alles Tutti Frutti ist sollten folgende Adressen erreichbar sein:

http://localhost:8080/alfresco/ ACS
http://localhost:8080/content-app/ ACA Webapp
http://localhost:8080/share/ Good old Share

Zum Zeitpunkt der Artikelerstellung bekomme ich einen komischen Error wegen des GoogleDocs Modules auf meinem Windows PC. Ich bin mir sicher, dass ich diesen nicht auf meinem MacBook bekomme. Ich ignoriere diesen Error getrost. Falls du werter Leser allerdings weist warum, würde ich mich gerne über eine Privatnachricht mit Erklärung freuen.

Um das Deployment sauber wieder runterzufahren einfach folgenden Befehl benutzen:

.\start.sh -d

Das stopp und löscht alle Container die mittels start.sh gestartet wurden. Du musst das Deployment löschen und erneut starten wenn du Änderungen von der webapp im dist/app Folder applyen willst. Alternativ kannst du auch das -aca Flag benutzen welches nur den webapp Container neustartet.

Deployment Anpassen

Dieser und der nächste Abschnitt ist wohl der schwerste und erfordert viel Geduld. Bisher war es ein leichtes da wir einfach nur bestehenden Code genommen haben, welches bereits von anderen Entwicklern konfiguriert und getestet wurde. Nun müssen wir das allerdings selber machen, denn wir wollen ja in der Lage sein Customizations so wie unsere eigene Extension einzubinden. Also nehmt euch nen Cafe oder wie in meinem Fall nen Tee und ran an den Speck!

Zum manipulieren des Docker Compose Deployments habe ich alle direkten Dockerbezüglichen Files aus dem ACA Folder in den Projektfolder kopiert. Das beinhaltet zum Beispiel docker-compose.yaml, start.sh, Dockerfile und den docker Folder. Es wäre nun ratsam zu testen ob euer Docker Compose Deployment jetzt immer noch funktioniert. Dafür vielleicht einfach erstmal die ADF Webapp im alfresco-content-app/dist/app folder in den Projekt dist/app Folder kopieren und das Deployment mit start.sh starten. Wie das geht, habe ich ja im vorherigen Kapitel beschrieben.

Jetzt kommt der wohl schwierigste Part, zumindestns war es für mich so. Ihr müsst nun auch die Angular bezüglichen Files in den Projektfolder kopieren und diese so konfigurieren, dass sie die Componenten aus von alfresco-conten-app/src benutzen. In meiem Fall waren es die folgenden Datein:

src\app\extensions.module.ts
src\assets\app.extensions.json
src\app.config.json
src\tsconfig.app.json

Ich will hier nichts vormachen, die richtige Einstellung der Konfiguration hat mich tatsächlich zwei Tage gekostet. Als ich nicht mehr weiterkam, suchte ich Rat bei der wundervollen ADF Community in Gitter. Die Jungs und Mädels verstehen ihr Handwerk. Besonderen Dank an meinen Freund und Exkollegen Bogdan.

Jetzt ist es an der Zeit den dist/app folder selber von Angular compilieren zu lassen, anstelle es nur aus dem aca projekt zu kopieren. Wenn du es hinbekommen hast, dass das Docker Compose Deployment erfolgreich mit der im Parentfolder compilierten Webapp im dist folder, kann endlich das Customizing beginnen :) !

Extension Erstellen

Wohoo! Du hast es tatsächlich bis hierher geschafft. Nun wird es um so mehr Angular lastig. Um eine neue Extension zu bauen empfiehlt sich der Befehl:

ng generate library my-ext

Ich würde sehr empfehlen ein -ext an den Namen der Extension zu fügen, um es unterscheidbarer von der Webapp zu machen. In meinem Projekt haben sie die gleichen Namen mit Ausnahme, dass ich der Extension noch -ext angefügt habe. Was man nun mit der Extension macht ist total offen und es gibt viele tolle Angular Tutorials, Seiten oder Foren die einen Helfen die gewünschten Änderungen zu erreichen.

Willst du zwischendurch oder am Ende deiner Änderungen die Webapp testen, musst du einfach die ADF Webapp compilieren und das Docker Compose Deployment starten. Dies schaut ähnlich auch wie im Abschnit ACA Starten erklärt mit den folgenden Befehlen:

yarn install
yarn run build
.\start.sh -wp -hi 192.168.0.237

Bitte nicht vergessen das -wp ist Windows spezifisch. Wenn ihr MacOS oder Linux benutzt braucht ihr dieses Flag nicht. Ihr würdet dann wahrscheinlich nichtmal -hi IP benötigen.

Neues ACA Update Verfügbar

Als sich das ACA Git Repository mit unglaublich schneller Geschwindigkeit weiterentwickelt, stellt sich die Frage wie wir diese Updates in wenigen Schritten in unsere ADF Webapp integrieren können. Ich brauchte dies zwar bisher nicht machen für meinen ADF AI Prototypen, aber grundlegend seien diese Schritte genannnt:

Es muss das alfresco-content-app Git Submodule geupdated werden.
Die Versionen in package.json im Projetfolder müssen mit denen im alfresco-content-app/package.json synchronisiert werden

Zusammenfassung

Wow überlegt mal was wir hier geschafft haben. Wir haben tatsächlich unsere eigene ADF Webapp geschrieben welche auf ACA basiert und jederzeit einfach upgedatet werden kann! Dafür mussten wir zuerst ein neues Git Repo erstellen. Dann das ACA Projekt als Submodul einbinden. Unmittelbar danach testeten wir das Docker Compose Deployment in ACA. Dann haben wir das Repo so umgebaut, dass wir unsere eigene Angular Extension in die ADF Webapp integriert haben. Das wars! Ich hoffe ihr hattet Spaß und war der Artikel war hilfreich.

Kudos

Für Eddie May der brand neue Digital Community Manager von Alfresco für das Berichtigen meiner englischen Übersetzung und das Angebot mir auch in zukünftigen Posts Feedback zu geben :).

Werde ein Patreon!

Meine Erste aufregende Woche bei OBJECT

Thu, 20 Feb 2020 00:00:00 GMT

Moin.

In diesem Artikel fasse ich kurz die erste Woche bei OBJECT zusammen. Für mich selber bietet dieses einige Vorteile. Zum einen ich übe regelmäßiges Artikelschreiben und zum Anderen dient es als Reflexion über die vorangegangen Tage. Darüber hinaus fällt es einigen meiner Verwandten und Freunden schwer zu verstehen wie mein Traumjob als Software Engineer so aussieht. Diese Art von Blogpost können dabei helfen es besser zu verstehen. Hoffe ich zumindest.

Tag 1 Onboarding

Ursprünglich war es geplant, dass ich ich nach Zürich kommen sollte zum Onboarding. Kurz gesagt als Onboarding bezeichnet man in der Regel der Prozess bei dem neu angestellte Mitarbeiter mit der Hardware und den verschiedenen Softwaresystemen vertraut gemacht werden, sowie die zukünftigen Aufgabenbereiche. Allerdings war meine Frau zu dem Zeitpunkt schwanger und ich wollte sie von daher ungern verlassen.

Um so überraschter und sehr glücklich war ich, als OBJECT mir anbot das Onboarding in Hamburg zu machen. Ich liebe Hamburg, denn es is eine schöne Stadt am Wasser. Im Titelbild ist die Kirche St. Jacobi von Hamburg zu sehen, welche mir gleich aufgefallen war auf dem weg zum Onboarding. Drei spannende Hauptaufgaben wurden mir zugeteilt. Über diese darf und möchte ich nur in sehr groben Details schreiben.

Die erste Aufgabe ist, dass ich ein eigenes Projekt zusammen mit einem anderen Partner übernehmen und leiten soll. Dieses Projekt befasst sich mit einem sehr spannenden Alfresco Deployment. In diesem Deployment sollen ACS (Alfresco Content Service) und APS (Alfresco Process Service) zusammen laufen. Das ist super spannend das ich Alfresco's ECM und BPM Produkte miteinander kombinieren darf.

In dem zweiten Projekt geht es um eine Entwicklung eines Prototypen für die Auffindung von sensiblen Daten. Dafür würden wir auch gerne eine schicke ADF app benutzen. In diesem Projekt werde ich meine bisher erlangten Skills mit Docker und ADF voll ausspielen können.

Im dritten und wohl für mich spannensten Projekt geht es darum, dass OBJECT gerne eine stärker Sozial Media Präsenz hätte. Das ginge von Platformen wie Xing, LinkedIN zu YouTube Videos. Auch hier habe ich großes Interesse mein bisher erlangtes Wissen über Alfresco zielführend einzusetzen und meine bisher bescheidenen aber existierenden Sozial Medial Skills auszubauen.

Zusammenfassend für diesen Tag kann ich sagen, dass der Tag sehr anstrengend, aber auch sehr produktiv und toll, war. Ich bin sehr happy das OBJECT großes mit mir vorhat.

Tag 2 Project Einführung

Mein toller brasilianische Kollege, auch von mir Amigo genannt, hat sich die Zeit genommen und mir das aktuelle ACS 5.2. Deployment gezeigt. Ich habe alle Details verschlungen und ihm viele Fragen gestellt. Wir benötigten etwa zwei Stunden. Am meisten beeindruckt hat mich der Entwurfsprozess für dieses Deployment. Es waren einige Entwurfsdiagramme nötig, bis sich auf das finale Diagram entschieden wurde. Bereits jetzt habe ich schon ein paar interessante Ideen wie man das Deployment besser gestalten könnte in Punkto einfacher Wartbarkeit, Sicherheit, verminderter Fehleranfälligkeit und Verlässlichkeit.

Tag 3 Developer Meeting

Am Mittwoch und somit der dritte Tag hatten wir ein zirka einstündiges Meeting mit allen Developern bei OBJECT. In dieser Runde stellte sich jeder kurz vor und erklärte mir an welchen spannenden Aufgaben sie arbeiten. Um diese Flut an Informationen besser zu verarbeiten, entschloss ich mich diese in kurzen Stichpunkten in mein Notizblock niederzuschreiben. Die Kennenlernrunde war sehr toll und ich wage mich zu behaupten, dass ich einen guten ersten Eindruck von mir hinterlassen habe. Ich hoffe schon bald öfter mit dem einen oder anderen Kollegen zusammenzuarbeiten zu können, da ich das Gefühl habe noch viel von ihnen lernen zu können.

Den Rest des Tages verbrachte ich damit, mich weiter mit dem, im vorherigen Kapitel erwähnten, Deployment zu befassen. Auch habe ich einen Verbesserungsvorschlag ausgearbeitet welchen ich bald meinen Kollegen und unserem Partner vorschlagen möchte.

Tag 4 Inspirierendes Konversation

Heute am Donnerstag hatte ich ein super interessantes und inspirierendes Gespräch mit einem Partner von uns. Dieser ist im Bereich AI (Artificial Inteligence) tätig und hat eine eigene Firma gegründet. Alfresco's Content Managment System ist dabei nur eine Plattform von vielen wo mittels AI wertvolle Informationen extrahiert werden können. Ich war so erstaunt wie dieser Gründer so mit voller Begeisterung über das entwickelte Produkt gesprochen hat.

Mein Ziel ist es nun in den nächsten Wochen einen auf ADF basierenden Prototypen zu entwickeln, welche die zuvor erwähnten AI Fähigkeiten demonstrieren kann. Sehr gerne arbeite ich mit ADF. Wie schon im vorherigen Blog Post erwähnt liebe ich dieses Framework. Meine Idee ist es Alfresco's ADF App mit namen ACA als Grundlage für den Prototypen zu gehört. Vielleicht wäre es eine coole Idee auch einen Artikel über diese App zu schreiben.

Tag 5 AI Magie

Als ich angefangen habe diesen Artikel zu schreiben, habe ich mit sicherheit nichtmal ansatzweise daran gedacht das AI so ein wichtiger Inhalt dieses Post wird. Ich bin sehr AI interessiert und heute am Freitag, habe ich eine coole Life Demonstration über ein AI System bekommen, welches Alfresco's Content Management System als Datenquelle verwendet um extrem interessante Informationen zu extrahieren. Auch warnt das System den Nutzer gegebenfalls, wenn etwas misstrauisches passiert.

Sehr interessant fand ich, dass schon eine einfache ACS Community version ohne jegliche Customization ausreichte. Diese Demonstration hat mir ein gutes Bild verschafft wie die ADF App aussehen soll. Am Montag werde ich anfangen kleine Skizzen von dem Prototypen anzufertigen.

Zusammenfassung

Die erste Woche war intensiv aufgrund der vielen neuen Informationen. Positiv überrascht war ich, dass schon recht viele Kollegen auf die von mir angebotene Hilfe zurückgegriffen haben. Ebenso schaue ich mit voller Ehrgeiz und Begeisterung in die Zukunft von mir zusammen mit OBJECT.

Werde ein Patreon!

Von Alfresco zu OBJECT

Sun, 09 Feb 2020 00:00:00 GMT

Hi werter Leser.

Mit voller Freude darf ich verkünden, dass ich am 14. Februar zu OBJECT wechsle. Diese ist eine Partnerfirma von meiner jetzigen Firma Alfresco. OBJECT agiert hauptsächlich im Deutschen und Schweizerischen ECM (Enterprise Content Management) Markt. Nachfolgend liste ich meine Beweggründe auf und am Schluss erkläre ich meine Zukunftsvisionen von OBJECT und Alfresco für das Jahr 2022.

Gründe für den Wechsel

Einer meiner grössten Beweggründe ist das mir die Alfresco Produkte sehr gefallen. Alfresco Content System (ACS) ist ein geniales und ausgeklügeltes auf der Java VM basierendes Content Management System. Auch wenn ich bisher kaum die Möglichkeit hatte mit Alfresco Process Service (APS) zu arbeiten, erkenne ich wie toll auch dieses Produkt ist und möchte auch gerne in Zukunft damit befassen. Last but not least Alfresco Developer Framework (ADF). Ich finde die neuen, auf Angular basierenden, Weboberflächen sehr schön und genial für das Frontend. Vor allem die einfache Benutzung der Graphischen Oberfläche sowie die umfangreiche Sammlung an vorgefertigten Components, wie z.B. der Document List, haben es mir angetan. 2019 hatte ich die Gelegenheit den ADF Teams mit Alfresco Backend Knowhow zu helfen und konnte dabei auch vieles über ADF lernen, wofür ich sehr dankbar bin.

Der Wechsel zu OBJECT sollte es mir auch ermöglichen näher am Kunden zu sein. Ich möchte Lösungen für und mit dem Kunden entwickeln. Ich bin davon überzeugt das Alfresco hervorragende Lösungen im ECM und BPM Bereich bieten. In Zusammenarbeit mit dem Kunden werde ich dabei helfen die ideale Lösung zu finden. Ich würde dabei auch nicht zurückscheuen neben Alfresco auch andere Software Produkte für Lösungen oder Teillösungen in Betracht zu ziehen. Tatsächlich liebe ich es neue sowie andere Software Technologien kennen zu lernen.

Auch habe ich in den letzten Jahren die Möglichkeiten der Cloud für mich entdeckt und war einfach nur überwältigt. Mit solch einer Einfachheit mit der sich Infrastruktur wie virtuelle Server oder Speicher bereitstellen lassen und kostengünstig zu betreiben, sucht seines gleichen. Das Agieren in der Cloud hat mir soviel Spass gemacht, dass ich mich dazu entschlossen hatte, AWS Zertifikate zu machen. Neben vorangegangen anderen bestandenen Zertifikaten errang ich im Juli 2019 das "AWS Solution Architekt Professional" Zertifikat, worauf ich sehr stolz bin. Wenn du gerne mehr wissen möchtest über das Zertifikat und die Vorbereitungen dafür, schau bei meinem Blogpost SAP-C01 vorbei. Von daher würde ich mich freuen, wenn ich die Benutzung der Cloud im deutschsprachigen Raum vorantreiben kann.

Auch interessiere ich mich sehr für neue Technologien der Informatik wie Docker und Kubernetes. Das arbeiten mit Docker finde ich deshalb so schön, da man quasi immer wieder saubere Umgebungen bereitstellen und ggf. konfigurieren kann und das mit nur wenig Zeilen Code. Auch ist es einfach unvergleichlich um wieviel einfacher die Entwicklung mit Alfresco Produkten wird, wenn diese in Containern bereits definiert sind. Ebenfalls bietet Alfresco Referenz Images z.B. acs-packaging sowie Deployments z.B. acs-deployment an, die einfach verwendbar sowie customizable sind. Auch möchte ich an dieser Stelle Kubernetes nicht auslassen. Kubernetes hat zwar eine steile Lernkurve, aber eingesetzt in der Produktion ist es einfach unschlagbar. Ebenfalls besitzt Alfresco auch hier ein Referenz Deployment alfresco-dbp-deployment. Gerne würde ich mich freuen diese Technologien stärker im deutschsprachigem Raum weiter voranzutreiben.

Zu guter Letzt. Der Bewerbungsprozess mit OBJECT war eine wunderschöne Erfahrung und hat schon sehr herausgestochen zu all meinen Bewerbungen davor. Die Mitarbeiter bei OBJECT machen einen sehr glücklichen und aufgeschlossenen Eindruck. Auch finde ich die Home Office Kultur von OBJECT toll und zeitgemäss. Das ist die ideale Umgebung um mich weiterzuentwickeln.

Im nächsten Abschnitt würde ich gerne einen Ausblick über OBJECT zusammen mit Alfresco für das Jahr 2022 geben.

Ausblick 2022

In dem letzten Jahr bei Alfresco, konnte ich den Cloud Trend beobachten sowie selber daran mitwirken. Ich weiss das dieser noch stärker ausgebaut wird. Alfresco bietet bereits ein starkes PaaS (Program as a Service) Angebot und wird dieses in Zukunft noch weiter ausbauen. Realistisch gesehen glaube ich das dieses Angebot im deutschsprachigen Raum bis 2022 noch nicht oder nur wenig genutzt wird, da Länder wie Deutschland sich sehr vorsichtig und somit auch langsam in der Cloud Welt bewegen.

Auch wenn bis 2022 der deutschsprachige Raum das Alfresco's PaaS Angebot kaum nutzen wird, werden wir einen starken Gang in Richtung Cloud erleben, bezüglich der Alfresco Produkte. Schon heute lassen sich viele Kosten sparen mit der Verwendung der Cloud als Storage z.B. macht es der S3 oder Azure Connector von ACS einfach, die BLOB Storages der jeweiligen Cloud provider zu verwenden. OBJECT kann dabei als vertrauenswürdiger Partner Rat und Tat leisten.

Viele Alfresco Kunden benutzten bereits die schicken mit ADF erstellten Webapplikationen und bis 2022 werden es garantiert mehr. OBJECT sehe ich in der perfekten Lage gemeinsam mit dem Kunden angepasste ADF Apps zu entwickeln.

Werde ein Patreon!