Dieser Beitrag gehört zu einer Serie!
Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an.
So baust Du eine state of the art Infrastruktur mit Terraform! Part 1
Dieser Beitrag gehört zu einer Serie! Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an. Table of Contents <h2>Was bedeutet

Github Actions & Google Cloud Run! Part 2
Dieser Beitrag gehört zu einer Serie! Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an. Table of Contents <h2>Was ist

Skalierbarkeit, Microservices & DNS Einträge! Part 3
Dieser Beitrag gehört zu einer Serie! Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an. Table of Contents Sollte alles
Table of Contents
Was bedeutet „state of the art“?
Die IT gehört zu einem sich ständig weiterentwickelnden Berufsumfeld. Es werden täglich neue Innovative Ideen umgesetzt. Startups gehen an die Börse und Dein lieblings Browser ist jetzt bei Version 2.0 angekommen.
Doch das hat natürlich auch Auswirkungen auf Dich und Dein Unternehmen!
Deine Firma sollte im Strom der Zeit mit schwimmen und sich stetig weiterentwickeln. Das gilt auch für die Infrastruktur!
Wir bei RoyalZSoftware versuchen natürlich immer das Bestmögliche Hosting anzubieten damit Deine Web Anwendung immer:
- Schnell ist!
- Verfügbar ist!
- Automatisiert ist!
- Täglich/Stündliche Snapshots und Backups hat!
- Und vor Angriffen geschützt ist!
Das Konzept
Da ich persönlich rein aus dem DevOps- / Linux- / Automatisierungs-umfeld komme, möchte ich natürlich auch, dass unsere als auch Kundenapplikationen die Bestmögliche Performance mitbringt, sowie auch Kosteneffizient ist. Ruby on Rails arbeitet allerdings ein bisschen anders als seine Kollegen. Es ist ein Full-Stack Framework für Webanwendungen.
Das bedeutet Backend und Frontend werden nicht aufgeteilt. Für die einen ist dies ein Segen, da sie nicht extra container für das Backend bauen müssen. Für andere wie mich ist das ein Fluch, da es weniger Designoptionen und Skalierbarkeitsmöglichkeiten gibt.
Doch wie genau sieht unser Serversystem nun aus?
Nun sehr whsl. ist dir „Cloud Computing“ bereits ein Begriff. Wir verwenden keinen extrigen Windows/Linux Server mit einem Betriebssystem. Sondern wir möchten nativ auf Cloud Computing Ressourcen zurückgreifen. Das spart nicht nur kosten, sondern ist auch ausschlaggebend für die Skalierbarkeit.
RoyalZSoftware hat sich dabei für die Google Cloud entschieden welche mit „Cloud Run“, eine Art „Serverless“ verfahren, Deine Ruby Applikation in einem seperaten Docker Container und weniger anderer Ressourcen zu einer vollwertigen Infrastruktur macht.
Wie genau kommt nun eine Github Pipeline ins Spiel?
Falls dir der Begriff „Pipeline“ nichts sagt. Hierbei handelt es sich um eine „Befehlskette“ die ausgeführt wird wenn sich am Github Repository irgendetwas ändert z.B. einen commit auf dem master branch führt zu einer Pipeline für das Production System.
Mithilfe dieser Pipeline werden wir unsere komplette Infrastruktur aufbauen.

von Terraform zur Infrastruktur
Terraform wie der Name schon sagt ist dazu gedacht große Landschaften zu „terraformen“=(zu verwalten). Dabei handelt es sich allerdings nicht um Erde und Stein wie bei Minecraft, sondern um ganze „Cloud Environments“ und die einzelnen Ressourcen im Hintergrund.
Doch nicht nur das. Anders als die meisten Leute nur die Oberfläche von Cloud Providern ankratzen, bieten fast alle eine sogenannte Cloud Shell=(Command Line Interface) als auch eine Restful API mit der sich die verschiedenen Ressourcen auch per Kommandozeile bearbeiten lassen. Dieser Ansatz ist bekannt als „IaC“=(„Infrastructure as Code“).
Terraform greift nun auf die Restful API des jeweiligen Providers zurück und bietet eine möglichkeit an nun diese normal über das Webinterface erreichbaren Ressourcen per Code im YAML format zu bearbeiten/erstellen. Und genau das wollen wir für unsere Github Pipeline.

Wie verbinden wir uns zur Google Cloud?
Zu aller erst benötigen wir natürlich eine Ruby on Rails Applikation und clonen uns das dazugehörige repository auf den lokalen PC. In diesem Repository erstelle ich am liebsten einen Ordner namens „.terraform“. Innerhalb dieses Ordners erstelle ich einen weiteren mit der Bezeichnung „app-ressources“. Nun erstellen wir zwei dateien: „main.tf“ und „variables.tf“.. ├── main.tf └── variables.tfIn der GCloud müssen wir uns nun einen Service-Benutzer erstellen, welcher die Berechtigungen hat Cloud Ressourcen zu erstellen/bearbeiten/löschen. Unter „IAM und Verwaltung“ klicken wir in der linken Navbar auf „Dienstkonten“ und erstellen ein neues Dienstkonto mit der Berechtigung „Inhaber“. Um es noch sicherer zu gestalten kannst du die Berechtigungen dieses Nutzers auch weiter einschränken. Anschließend erstellen wir für den Benutzer einen „Dienstkontoschlüssel“ und WICHTIG! laden uns diesen an einen sicheren Ort runter. Diesen legen wir nun ebenfalls im „app-ressources“ Ordner ab. WICHTIG! ab jetzt darfst du auf keinen Fall dieses „credentials.json“ file zu Github pushen, da sonst jeder mit dieser Datei Ressourcen erstellen darf… Als letzten Schritt müssen wir nur die GCloud als provider für Terraform definieren das geht indem wir in der „main.tf“ folgendes eintragen:
terraform { required_providers { google = { source = "hashicorp/google" version = "4.24.0" } } } provider "google" { credentials = file("./credentials.json") project = var.project_id region = var.region_name zone = "europe-west-3b" }Wie du bereits villeicht erkennst verwenden wir persönlich so viele Variablen wie es nur möglich ist. Diese Tragen wir in der „variables.tf“ ein:
variable "project_id" { type = string } variable "region_name" { type = string default = "europe-west3" }Wir setzen in diesem Fall bewusst keine „project_id“, da wir diese mithilfe der CLI in der Pipeline später mitgeben.
Installation Terraform
Um das ganze nun zu testen müsst Ihr erstmal die Terraform CLI installiert haben. Für mich unter Ubuntu ist das ein einfaches „sudo apt install terraform“, für Mac ist es Brew und Windows verwendet Chocolately alles genau beschrieben in dieser offiziellen Dokumentation. Zum Schluss können wir das ganze nun testen indem wir in das „app-ressources“ Verzeichnis wechseln und folgenden Befehl eingeben:terraform initSollte als Ergebnis „successfully build up connection“ kommen hast du es geschafft und kannst mit dem nächsten step weiter machen. Andernfalls solltest du nochmal die Berechtigungen und die credentials.json überprüfen.
Welche Ressourcen brauchen wir?
Generell können alle Verfügbaren Ressourcen der Google Cloud in dieser Dokumentation gefunden werden.1. Datenbank
Um in der Google Cloud eine Postgres Datenbank zu erstellen benötigen wir insgesamt 3 Ressourcen. Wir müssen die Datenbank an sich erstellen, dazu eine Instanz (was die eigentliche Datenbank ist) und einen Benutzer der das ganze Verwaltet. In unserem möchten wir noch ein Zufällig vergebenes Passwort haben.resource "google_sql_database" "database" { name = "${var.project_name}_app" instance = google_sql_database_instance.instance.name } resource "google_sql_database_instance" "instance" { name = "${var.project_name}-sql-${var.env_tag}" region = var.region_name database_version = var.sql_version settings { tier = "db-f1-micro" } deletion_protection = "false" } resource "random_password" "sql_user_pass" { length = 32 special = false } resource "google_sql_user" "user" { name = "admin" instance = google_sql_database_instance.instance.name password = random_password.sql_user_pass.result }Soweit sollte alles verständlich sein. Als „tier“ in der Instanz geben wir an welche Rechen Kapazitäten CPU/Arbeitsspeicher die Datenbank haben soll.
2. App-Storage
In unserem Fall generiert die Applikation bestimmte Datei-Outputs. Das kann sein, ein Benutzer lädt ein Profilbild hoch, oder wir haben ein Monitoring System das Log Dateien und Statistiken generiert. Diese wollen wir natürlich (am besten inklusive Backup) in der Cloud redudant abspeichern.Der Bucket lässt sich sehr einfach erstellen:
resource "google_storage_bucket" "storage_bucket" { name = "${var.project_name}-storage-${var.env_tag}" location = var.region_name force_destroy = true uniform_bucket_level_access = false cors { origin = ["*"] method = ["GET", "HEAD", "PUT", "POST", "DELETE"] response_header = ["*"] max_age_seconds = 3600 } }Mit „cors“ gibt man an welche Anfragen von außen an den Bucket gestellt werden dürfen.
3. Rails Secret Key Manager
Der Secret Key Manager ist in Rails ein Dienst der benötigt wird um sich zu bestimmten Environments bestimmte Variablen aus einer verschlüsselten Datei auszulesen. Hiervon wollen wir natürlich auch ein Backup, am besten abgespeichert in einem anderen Land. Dies geht mit „replicas“:resource "google_secret_manager_secret" "rails_master_key_secret" { # IMPORT with following command # terraform import google_secret_manager_secret.rails_master_key_secret $RAILS_SECRET_KEY secret_id = "${var.project_name}-secret-${var.env_tag}" replication { user_managed { replicas { location = var.region_name } } } } resource "google_secret_manager_secret_version" "secret-version-basic" { secret = google_secret_manager_secret.rails_master_key_secret.id secret_data = var.master_key_secret }
Ressourcen außerhalb von Terraform
Nach einem "terraform apply -f terraform.plan"
wird eine sogenannte „*.tfstate“ Datei generiert. Wichtig! Diese Datei ist extrem wichtig für Terraform, damit er weiß welche Ressourcen er erstellt hat, mit welchem Variablen und wie ihr Status ist. Wichtig wird dieses File auch beim Löschen. Es ist natürlich möglich per terraform destroy -f terraform.plan
alle seine erstellten Ressourcen wieder zu löschen.
Erstellung .TFSTATE Storage
terraform { required_providers { google = { source = "hashicorp/google" version = "4.24.0" } } backend "gcs" { } }
Nach der Änderung des backend’s auf „Google Cloud Services“ müssen wir einen Storage Bucket per Hand erstellen auf dem die .tfstate Datei abgelegt wird. Anschließend geben wir den Bucket Namen nicht über die Datei mit, sondern über die CLI. Das gibt uns später viel mehr möglichkeiten damit zu handtieren in der Github Pipeline.
Basic Terraform Commands
terraform init -backend-config="bucket=test-project1234" -backend-config="prefix=test-gcp"
Fazit:
Erstmal Vielen Dank fürs lesen dieses Blog Beitrags. Ich hoffe du konntest einige Dinge über Terraform mitnehmen und für deinen Anwendungszweck umbauen. Wichtig! Das waren noch nicht alle Ressourcen. Was noch fehlt ist Google Cloud Run und der DNS. Hierauf gehen wir allerdings in den nächsten beiden Artikeln ein.
Solltest du weitere Fragen haben, kontaktiere uns gerne per mail, auf Instagram oder vereinbare einen kostenlosen Beratungstermin, falls wir die Arbeit übernehmen sollen.
Dieser Beitrag gehört zu einer Serie!
Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an.
So baust Du eine state of the art Infrastruktur mit Terraform! Part 1
Dieser Beitrag gehört zu einer Serie! Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an. Table of Contents <h2>Was bedeutet

Github Actions & Google Cloud Run! Part 2
Dieser Beitrag gehört zu einer Serie! Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an. Table of Contents <h2>Was ist

Skalierbarkeit, Microservices & DNS Einträge! Part 3
Dieser Beitrag gehört zu einer Serie! Sollte dir der Beitrag gefallen haben schaue dir gerne noch die anderen Teile an. Table of Contents Sollte alles