Production-ready Infrastruktur in 3 Wochen
•
0 gefällt mir•70 views
Es gibt sie doch noch: Projekte die man auf der grünen Wiese starten darf - incl. Infrastruktur. Nur AWS als Cloud Provider ist gesetzt. In dieser Session gebe ich nach den ersten Wochen Einblicke und Lessons Learned, wie wir vom Zustand eines weißen Blatt Papiers auf ein Account- und Infrastruktur-Setup gekommen sind, mit dem wir zumindest mal sofort loslegen können ohne die üblichen „Abkürzungen“ bei Qualität und Featureumfang zu gehen. Ein wesentlicher Teil davon ist das Tooling von gruntwork.io, welches in diesem Kontext kurz vorgestellt wird. [Disclaimer: Wir sind auch nur normale Kunden mit einer gruntworks-Subscription ohne weitere Connections dorthin – diese Session wird also explizit keine gruntwork.io Werbeveranstaltung, auch wenn sich das inhaltlich nicht 100%ig vermeiden lässt]
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (11)
Ähnlich wie Production-ready Infrastruktur in 3 Wochen
Ähnlich wie Production-ready Infrastruktur in 3 Wochen (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (6)
Production-ready Infrastruktur in 3 Wochen
- 1. Production-Ready Infrastruktur in 3 Wochen André Goliath
- 2. Was mache ich eigentlich hier? Seit ca. 13 Jahren “entwickelnder Architekt” … ursprünglich mal ECMAScript (4)-Jünger… … dann auf die dunkle Seite konvertiert (JEE) … dann kam Spring Boot… … und jetzt AWS…
- 5. Warum ist AWS eigentlich so schwierig? Wer von euch hat wirklich Ahnung von DNS, Load Balancern, Firewalls, Netzwerktopologien,…?
- 6. Warum ist AWS eigentlich so schwierig? Wir starten auf der komplett grünen Wiese, vielleicht zum ersten Mal in unserem Leben
- 8. Aber wie mappe ich meine Erfahrungen mit klassischer Infrastruktur auf AWS?
- 9. Und was muss alles getan werden, damit wir möglichst bald mit der Fachlichkeit anfangen können?
- 10. Und was brauchen wir überhaupt von AWS?
- 12. Welche Anforderungen haben wir an unsere Architektur?
- 13. Welche Anforderungen haben wir an unsere Architektur? Security-by-default Welche Konsequenzen haben die Aktionen von unerfahrenen Entwicklern?
- 14. Welche Anforderungen haben wir an unsere Architektur? Monitoring, Logging und hohe Dev Exp. von Anfang an Nie wieder „öhhh da muss ich erstmal nachgucken wie man das nochmal macht..“
- 15. Welche Anforderungen haben wir an unsere Architektur? Nur so komplex wie unbedingt nötig Wie lange brauche ich, um einen neuen Entwickler zu erklären wie unser Setup funktioniert? Wieviel Aufwand ist das initiale Setup? Welche Schritte sind notwendig, um neue Clients oder APIs onzuboarden?
- 16. Welche Anforderungen haben wir an unsere Architektur? 100% über versionierten Quelltext verwaltet Wissen wir in 5 Jahren noch exakt, was auf unseren Blechen installiert ist?
- 17. Security-by-default Nur so komplex wie unbedingt nötig Monitoring, Logging und hohe Dev Experience von Anfang an 100% über versionierten Quelltext verwaltet
- 18. Part 1: Account- und User-Struktur
- 19. AWS Organization "meinProjekt" Account "root" Account "security" Account "collab" Account "cicd" Account "qa" Account "stage" Account "prod" Account "spielwiese" Reza Philipp André dev dev&qa-write qa-full-access & stage-read & prod-read
- 20. Part 2: Wie war das mit der Developer Experience?
- 21. Wir haben schnell gemerkt, dass wir entweder Shortcuts gehen müssen oder noch lange mit dem Setup beschäftigt sein werden
- 22. Enter gruntwork.io - Open-Source Tooling - Infrastructure as Code Bibliothek - Referenzarchitektur - Viel Trainingsmaterial (Videos und Blogs) - Support und hoher Reifegrad - Subscription kostet 700 USD/Monat für AWS
- 24. └── live ├── prod │ ├── app │ │ └── main.tf │ ├── mysql │ │ └── main.tf │ └── dns │ └── main.tf ├── qa │ ├── app │ │ └── main.tf │ ├── mysql │ │ └── main.tf │ └── dns │ └── main.tf └── stage ├── app │ └── main.tf ├── mysql │ └── main.tf └── dns └── main.tf Eine klassische Terraform Struktur
- 25. Eine klassische Terragrunt Struktur └── modules ├── app │ └── main.tf │ └── variables.tf │ └── outputs.tf ├── mysql │ └── main.tf │ └── variables.tf │ └── outputs.tf └── dns └── main.tf └── variables.tf └── outputs.tf └── live ├── prod │ ├── app │ │ └── terragrunt.hcl │ ├── mysql │ │ └── terragrunt.hcl │ └── dns │ │ └── terragrunt.hcl │ └── terragrunt.hcl ├── qa │ ├── app │ │ └── terragrunt.hcl │ ├── mysql │ │ └── terragrunt.hcl │ └── dns │ └── terragrunt.hcl └── stage ├── app │ └── … …
- 26. └── live ├── prod │ ├── app │ │ └── terragrunt.hcl │ ├── mysql │ │ └── terragrunt.hcl │ └── dns │ │ └── terragrunt.hcl │ └── terragrunt.hcl ├── qa │ ├── app │ │ └── terragrunt.hcl │ ├── mysql │ │ └── terragrunt.hcl │ └── dns │ └── terragrunt.hcl └── stage ├── app │ └── … … Die “root” terragrunt.hcl eines Accounts # Configure Terragrunt to automatically store tfstate files in an S3 bucket remote_state { backend = "s3" config = { encrypt = true bucket = "acme-multi-account-dev-terraform-state" key = "${path_relative_to_include()}/terraform.tfstate" region = "us-east-1" dynamodb_table = "terraform-locks" } } # „environment-global“ variables inputs = merge( yamldecode( file("${get_terragrunt_dir()}/${find_in_parent_folders("region.yaml", "${path_relative.. ), yamldecode( file("${get_terragrunt_dir()}/${find_in_parent_folders("env.yaml", "${path_relat…")}"), ), # Additional global inputs to pass to all modules called in this directory tree. { aws_account_id = "123345345456" terraform_state_s3_bucket = "acme-multi-account-prod-terraform-state" terraform_state_aws_region = "us-east-1" }, )
- 27. └── live ├── prod │ ├── app │ │ └── terragrunt.hcl │ ├── mysql │ │ └── terragrunt.hcl │ └── dns │ │ └── terragrunt.hcl │ └── terragrunt.hcl ├── qa │ ├── app │ │ └── terragrunt.hcl │ ├── mysql │ │ └── terragrunt.hcl │ └── dns │ └── terragrunt.hcl └── stage ├── app │ └── … … Eine “Modul” terragrunt.hcl eines Accounts terraform { #git source = "git::ssh://git@github.com/…/modules.git//networking/dns/a?ref=898…" } include { path = find_in_parent_folders() } dependency "app" { config_path = "../app" } inputs = { … domain_to_ip_list = { "appname": { domain: dependency.app.appname, ip: dependency.app.elasticip.ip }, "app2": { domain:"app2", ip:"12.123.123.12" } } ttl = 600 }
- 30. In folgenden Punkten weichen wir bewusst von der Multi-Account Referenzarchitektur ab - Geringfügig angepasste Account-Struktur - Wir verwenden gitlab und perspektivisch Spinnaker statt Jenkins - Nur ein VPN von welchem alle anderen Accounts erreicht werden können - Wir erweitern die Architektur um API und Access Management
- 32. Key Takeaways
- 33. Du musst nicht alles vergessen, was du über Infrastruktur weißt, wenn du mit AWS anfängst. Ganz im Gegenteil, die Basics im Bereich Netzwerk sind unerlässlich, um sich schnell in AWS zurecht zu finden. Mach es von Anfang an richtig. Du musst das Rad nicht neu erfinden. Jemand anders hatte bereits das gleiche Problem wie du.