Multi Cloud mit Terraform – Eine Einführung
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 62 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/59730 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FrOSCon 202231 / 62
4
9
12
13
17
18
20
25
28
33
34
39
40
42
44
45
48
54
55
58
60
62
00:00
SoftwareHypermediaProzessautomationHomepageLINUXOpen SourceAMG <Mathematik>KonfigurationsraumWindows AzureCodeCONSULTANT <Datenbank>Virtuelles privates NetzwerkMultiplikationVerfügbarkeitGraphic WorkshopInternetdienstUmsetzung <Informatik>Lösung <Mathematik>ProviderRechenzentrumStreuungsdiagrammLastLaufzeitsystemCodeDienst <Informatik>HomepageInformationProzessautomationUmsetzung <Informatik>Open SourceEnde <Graphentheorie>EckeGoogleServerComputeranimation
08:32
CodeRSA-VerschlüsselungSSHSoftwareLöschen <Datenverarbeitung>Windows AzureLINUXLoginOrdnungsbegriffVirtuelles NetzSicherungskopieProviderVersion <Informatik>LängeTLSOrdnungsbegriffGroßrechnerParametersystemWindows AzureRouterInformationVirtuelles NetzSubnetCodeProviderDateiComputeranimation
17:00
Version <Informatik>ProviderSoftwareSSHZeichenketteVariableWindows AzureSicherungskopieGroßrechnerRSA-VerschlüsselungServerLINUXMono-FrameworkVersion <Informatik>Windows AzureUbuntu <Programm>p-BlockSubnetUpdateProviderErzeugendeVariableSage <Programm>OrdnungsbegriffVECTOR <Programm>Virtuelles NetzCulling <Computergraphik>PlatteKerndarstellungCodeRouterInformationDefaultComputeranimation
25:28
Microsoft NetworkMicrosoftKonfigurationsraumTOUR <Programm>GroßrechnerWindows AzureInformationGroßrechnerOrdnungsbegriffComputeranimation
26:35
Microsoft NetworkMicrosoftKonfigurationsraumTOUR <Programm>InformationWeb logSystemverwaltungLastSoftwareGroßrechnerElektronischer FingerabdruckMessage Transfer AgentLINUXWindows AzureLoginSSHVirtuelles NetzVirtuelles privates NetzwerkStellenringIMPGatewayRoutingInternetOpen SourceInternetStreuungsdiagrammGroßrechnerWindows AzureAnwendungssoftwareICMPSubnetElektronischer FingerabdruckGatewayComputeranimation
33:21
SystemverwaltungWeb logWindows AzureLastSicherungskopieHANS <Datenbanksystem>GatewayLINUXLesen <Datenverarbeitung>Version <Informatik>ZeitrichtungSoftwareICMPOpen SourceVirtuelles privates NetzwerkIPSecSubnetGatewayGeheimnisprinzipRouterWindows Azurep-BlockInternetInformationStreuungsdiagrammComputeranimation
41:47
SicherungskopieLastWindows AzureSystemverwaltungMicrosoft NetworkGatewayMicrosoftTOUR <Programm>KonfigurationsraumProxy ServerGroßrechnerMomentenproblemWechselsprungWindows AzureProxy ServerComputeranimation
43:02
LINUXLastGroßrechnerLoginWindows AzureSoftwareInternetdienstVersionsverwaltungOracle <Marke>Graphic WorkshopWindows AzureInformationCodeGroßrechnerCodierungComputeranimation
47:01
Oracle <Marke>ModulHTTPGraphic WorkshopKonfigurationsdatenbankLINUXLastWindows AzureSoftwareVersion <Informatik>ServerDemoszene <Programmierung>ProviderServerKonfigurationsraumAnbindung <Informatik>Mischung <Mathematik>p-BlockWindows AzureCodeDienst <Informatik>RichtungDatenbankDateiFunktionalitätStreuungsdiagrammInformationGroßrechnerBesprechung/Interview
55:44
Version <Informatik>ServerRepository <Informatik>ProzessautomationGit <Software>VersionsverwaltungAnbindung <Informatik>Vorlesung/Konferenz
57:49
JSONXMLUML
Transkript: Deutsch(automatisch erzeugt)
00:06
Dann fangen wir doch gleich mal an. Und zwar mit dem heutigen Vortrag von mir, Multicloud mit Terraform, eine Einführung. Ich bin Martin Gründer, ich bin Konsultant bei der ATIX AG und heute mit dem Vortrag möchte ich so ein bisschen näher bringen, was ist Terraform
00:21
überhaupt, wie funktioniert es, wie funktioniert da der Einstieg und wie kann das helfen, quasi eine Multicloud Umgebung hochzuziehen, also Infrastruktur über mehrere Clouds, beziehungsweise Cloud Provider. Zwei Folien noch zu mir und zur ATIX. Ich versuche es kurz zu halten. Genau, ATIX AG, wir sind ja auch verstehend mit einem Stand. Wir bezeichnen uns eben selber als
00:43
Open Source und Linux Company. Wir kümmern uns also um die Automatisierung in und ums Rechenzentrum auf Linux-Basis. Wir haben da unser Inhouse-Zool in Ocarino dafür, kümmern uns aber auch viel um Themen wie Puppet, Salt-Stack, Unsealable, also Configuration Management und
01:00
eben auch, was immer großer Punkt ist, ist sowas wie Container, Docker, Kubernetes, Ranger, OpenShift, das Ganze. Wer es interessiert, gerne mal auf die Homepage schauen. Zu mir als Person, ich bin eben Consulted im Linux-Bereich, also im Bereich der Administration, aber auch Configuration Management, also da vor allem Puppet und Unsealable,
01:25
und arbeite mich eben auch immer mehr ein in die Themen Cloud, da primär eben AWS, Hetzner und Escher, und mit der Thematik Infrastructure as Code, dazu später auch noch mehr. Und da möchte ich jetzt gerne eben in meinem Vortrag ein bisschen was zum Thema
01:41
Multicloud mit Terraform sagen zum Aufbau. Ich möchte mir erst noch allgemein ein paar Punkte abhandeln. Was ist Multicloud überhaupt? Was ist die Problematik dabei? Wie kommt es dazu? Dann eine Übersicht geben über Terraform, dass jeder, der sich das auch gerne selber mal aneignen möchte, da einen guten Start damit hat und schon mal die wichtigsten
02:01
Prinzipien damit kennt. Und da möchte ich noch zwei einfache Beispiele zeigen, die man mit Terraform hochziehen kann, auch gerne selbst. Und zwar einmal eine Escher-VM einfach starten und den DNS-Management mit R54 von AWS und eben dann noch zeigen, wie man mit Terraform eine Side-to-Side VPN-Verbindung zwischen dem Escher- und
02:23
dem AWS-Subnet hinbekommt. Genau, dann möchte ich auch gleich starten mit dem Thema Cloud. Und dann natürlich die erste Frage, warum sollte man sich überhaupt mit der Cloud auseinandersetzen? Also warum sollte ich im Endeffekt einem
02:42
Anbieter die Verwaltung meiner Infrastruktur, meiner Betriebssysteme, meiner Services überlassen? Warum sollte ich dann die Cloud gehen? Es gibt mehrere Gründe dafür. Natürlich ist das Ganze sehr flexibel. Das bedeutet, man kann sehr schnell seine Infrastruktur anpassen, Dinge ausrollen, auch mal ausprobieren. Man ist damit auch sehr agil, also kann auch schnell reagieren,
03:05
kann eben auch auf Last relativ gut reagieren, weil die Provider auch natürlich da ihre Lösungen dazu anbieten. Man kann auch das Ganze hoch verfügbar machen. Da gibt es auch normalerweise immer vorgefertigte Lösungen dafür, ob es jetzt
03:21
für Escher, AWS oder Google ist. Also falls das Thema Ausfallsicherheit eine große Rolle spielt, sollte man da immer mal einen Blick drauf werfen. Und natürlich der Kostenfaktor. Es ist ganz klar, wenn ich mein Szenario so designen kann, sinnvoll designen, dann sollte ich eigentlich auch immer eine Kostenersparnis damit erzielen können. Was gibt es jetzt da für Szenarien
03:43
beim Thema Cloud? Ich habe da mal so die vier typischen aufgezeichnet. Das erste ist eigentlich kein Cloud-Szenario. Das bedeutet nämlich, On-Premise bedeutet einfach, ich bleibe in meiner Infrastruktur, in meinem eigenen Daten- und Rechenzentrum, lager gar nichts in die Cloud aus. Demgegenüber
04:02
steht natürlich das reine Cloud-Szenario. Das bedeutet, ich lad meine gesamte Infrastruktur bei einem Anbieter und arbeite nur damit. Dann, was halt sehr oft der Fall ist, sind eben so Hybrid-Szenarien. Das heißt, dass man eben einen Teil seiner Infrastruktur, Rechner, Services eben bei sich vor Ort hat, beim Business, beim eigenen Datenzentrum
04:23
und einen Teil davon in die Cloud auslagert. Das kann Kostengründe haben, das kann aber auch sicherheitsrelevante Gründe haben, dass man zum Beispiel bestimmte Dinge bei sich vorzeitig halten muss, die man nicht in die Cloud ausliefern darf. Dann gibt es eben noch das Multi-Cloud-Szenario. Das bedeutet eben, dass man seine Infrastruktur,
04:43
seine Services, seine Server eben auf mehreren Clouds aufteilt und eben auch damit mehreren Anbietern oder Providern arbeitet. Dazu noch ein Wort. Die Frage ist jetzt natürlich, was bringt das einem? Reicht mir denn nicht eine Cloud? Und da ist die
05:03
Antwort, es kommt darauf an, und zwar auf das Szenario, das man hat. Es gibt nämlich sehr gute Gründe, dass man Multi-Cloud gehen kann. Das kann zum einen damit zusammenhängen, dass man eben vielleicht schon bei einem Provider war und man jetzt einen neuen nutzen will, weil der einfach ein Angebot hatte, das der alte so nicht hatte, und dass man da eben jetzt auf
05:22
neuere Services angewiesen ist und die eben mitbenutzen will. Und dann ist man schon eben Multi-Cloud. Es kann auch sein, dass man eben von einer Cloud in die andere migrieren will. Auch da hat man natürlich, in dem Zwischenstadium ist man da in mehreren Clouds unterwegs. Es können auch rechtliche Vorgaben geben, die vielleicht ein Provider erfüllen kann, die der andere nicht
05:42
erfüllen kann. Wenn man irgendwelche Services in privaten Cloud nutzt, ist man eigentlich auch per sie Multi-Cloud, per Definition. Und natürlich kann es einfach sein, dass ein Provider jetzt plötzlich billiger ist in manchen Bereichen als der andere und dass man das eben mitnehmen will.
06:00
Jetzt kann man sehen, es gibt gute Gründe für Multi-Cloud. Das bringt natürlich auch Probleme, weil in dem Moment, wo ich jetzt bei mehreren Cloud-Anbietern bin, muss ich ja irgendwie den Überblick behalten. Das heißt, jeder dieser Provider bringt eigentlich so sein eigenes Toolset mit, wie man damit interagieren kann mit seinen Services, mit seinen Angeboten. Ich muss das jetzt alles im Blick behalten. Ich muss auf Änderungen reagieren, wie meine Infrastruktur
06:24
durchmacht, was ja in der Cloud sehr schnell und häufig passieren kann. Und ich muss generell irgendwie den Überblick über meine Infrastruktur behalten. Jetzt ist die Frage, wie kann ich denn diese Probleme lösen, wenn ich die Vorteile von Multi-Cloud mitnehmen will? Und da gibt es eben ein Prinzip, das nennt sich Infrastructure as Code, das da an der Stelle helfen kann.
06:45
Und der Gedanke daran ist, okay, ich umgehe diese ganzen Probleme oder löse diese ganzen Probleme, indem ich das natürlich einfach nicht mehr manuell verwalte. Sondern, was ich stattdessen mache, ist, ich schreibe mir also Code oder Dokumentation, die meine Infrastruktur beschreibt, also dass ich das Ganze jetzt
07:05
deklarativ eben angehe. Und zum Schluss möchte ich einfach ein Tool haben, ein Programm, eine Lösung, die mir diese Dokumentation eben übersetzt in meine Infrastruktur. Und die Vorteile, die man dann eben
07:22
damit hat, ist, okay, ich habe eine Dokumentation, das bedeutet, es ist ganz deklarativ, es ist nachvollziehbar, es ist vollständig. Das heißt, ich habe nicht mehr diese Problematik, dass ich an 10 Ecken oder Enden irgendetwas, ich sage mal, versteckt habe, vielleicht auch händisch, sondern dass ich das jetzt eine Quelle der Wahrheit habe,
07:41
die ich benutzen kann. Und sobald es eben auch eindeutig beschrieben ist, kann ich das Ganze eben auch automatisiert ausrollen. Und da kommt eben Terraform ins Spiel. Terraform ist ein Open Source Tool von HashiCorp. Und es ist eben genau dafür da, diesen
08:01
Prozess des Ausrollen und Umsetzen von Code in Infrastruktur zu übernehmen. Wie funktioniert das Ganze? Na ja, Terraform nutzt dafür eine Zielzahl von sogenannten Providern. Und die enthalten eben genau die Informationen dafür, wie man vom Code in die Infrastruktur kommt, im Endeffekt die Information, wie
08:22
Terraform mit den APIs der einzelnen Anbieter interagieren muss, um das zu ermöglichen. Wie sieht denn so ein Workflow theoretisch aus? Na ja, ich muss zuerst mal meine Infrastruktur beschreiben. Also ich muss zuerst einen Code schreiben, der das Ganze darlegt. Dann kann ich meine Infrastruktur
08:44
planen. Da gibt es auch den Terraform Planbefehl dafür, der eben mir dann ausspuckt, was Terraform alles machen würde. Und zum Schluss, wenn ich damit zufrieden bin mit diesem Output, kann ich das Ganze eben applyn, anwenden und meine Infrastruktur hochziehen.
09:00
Das ist natürlich dann auch nicht in Stein gemeißet. Ich kann eben dann Änderungen am Code hinzufügen und das Ganze dann eben in Zyklen durchmachen. Dann kann ich schauen, was würde Terraform ändern an meiner Infrastruktur und eben das Ganze erneut ausrollen, wenn ich damit zufrieden bin. Und dann, wenn ich zum Schluss mit allem fertig bin und meine Infrastruktur nicht brauche, kann ich das Ganze sogar mit Terraform, meine Server,
09:23
meine Services, Datenbanken, was auch immer ich da habe, abreißen. Wie funktioniert das Ganze jetzt intern bei Terraform? Na ja, Terraform liest diese Ressourcen aus einem eigenen Pfeilformat aus. Das sind diese
09:41
TF-Dateien. Da zeige ich nachher dann Beispiele. Und in denen werden eben diese einzelnen Elemente der Infrastruktur beschrieben. Wie kann sowas aussehen? Das wäre hier mal gezeigt, bevor sich jetzt jemand beschwert. Ja, ich würde keinem empfehlen, im praktischen Betrieb ein RSR Key von der Länge zu verwenden. Aber es ist jetzt hier mal als
10:00
Beispiel drin. Da wird eben gezeigt, wie man so einen RSR Key anlegen könnte mit Terraform. Wie so ein ganz kurzer, knapper, prägnantes Terraform-Datei aussieht. Da hat man eben dieses Keyword Resource. Das sagt eben Terraform leg mir eine Ressource an. Dann kommt im zweiten Schritt welche soll das sein? Das soll eben ein TLS Private Key sein.
10:24
Und dann im dritten Satz, wie heißt die ganze Ressource? Das ist hier einfach das. Ich nehme gerne immer das als Namen hier her. Das ist, wenn man immer nur eine Ressource davon hat, dann findet man das sehr schnell wieder. Und dann in Klammern werden die entsprechenden Parameter übergeben. In dem Fall soll ein RSA Key sein von der Länge. Und das ist alles,
10:44
was Terraform im Endeffekt braucht, um diesen Key anzulegen. Jetzt ist es natürlich so, wenn man eine Infrastruktur aufsetzt, hat man ja Dinge, die aufeinander aufbauen. Also man braucht vielleicht zuerst Datenbank, dann Webserver etc. Also man möchte das Ganze
11:00
in einer bestimmten Reihenfolge machen. Wie funktioniert denn das bei Terraform? Im Endeffekt ist Terraform hier in der Lage, anhand von Abhängigkeiten zu anderen Ressourcen die Reihenfolge selbst zu bestimmen. Und das ist natürlich sehr praktisch. Einfaches Beispiel, ich möchte jetzt irgendwie so einen TLS Key anlegen und dann anschließend das Ding vielleicht noch lokal bei mir
11:20
in einem Pfeil ablegen, damit ich mich gleich irgendwo per SSA einlocken kann auf dem Host. Dann kann ich das eben mit Terraform ganz einfach machen, indem ich eine zweite Ressource definiere, so ein Local File in dem Fall. Und das soll eben Public Key heißen. Und dann kann ich sagen, okay, nehme mir als Inhalt, das ist hier dieses Content, nehme mir
11:40
als Inhalt eben aus der vorherigen Ressource, aus diesem TLS Private Key namens DISS den Public Key Teil raus. Und dann schreibt man das in die Datei mit dem Pfeilnamen unten. Und dann wird Terraform zuerst den Key erzeugen und dann in das Pfeil schreiben.
12:03
Eine wichtige Sache, die man sich noch klar sein muss bei Terraform, wenn man damit anfängt, ist, Terraform merkt sich die Infrastruktur, die es ausrollt. Wie funktioniert das Ganze? Na ja, Terraform legt da diese TF State File an und in dem werden eben alle Informationen über die Infrastruktur hinterlegt. Das heißt, wenn man das Gefühl
12:23
hat, dass irgendwas an der Infrastruktur nicht mehr so ist, wie man es haben wollte, und man es wieder auf den Standardzustand zurücksetzen will, kann man einfach wieder in Terraform drüber drauf lassen mit Apply. Und Terraform wird all das ändern, was von diesen Infrastrukturen abweicht, die man definiert hat. Das heißt, man kann das Ganze dann auch sozusagen interaktiv wieder anpassen lassen.
12:43
Und auch dann natürlich zum Schluss mit den Informationen einmal komplett abreißen, wenn man möchte. Hier ein Wort der Warnung an der Stelle. Dieses Terraform State File ist natürlich sehr wichtig. Wenn man da mit Terraform arbeitet, muss man eben gucken, dass dieses State File ordentlich aufbewahrt wird. Das heißt, jeder der das benutzt,
13:03
immer gucken, wie ist der Zugang dazu, kann nur ich drauf zugreifen oder die Leute mit denen ich zusammenarbeite. Sprich, Zugang beschränken, idealerweise verschlüsseln und am besten Fall natürlich, wenn man im Team zusammenarbeitet, irgendein Backend benutzen. Da gibt es einen ganzen Satz an Backends, die man hier hernehmen kann. Ich persönlich arbeite mit dem
13:23
von GitLab, wo man dieses State File eben aufbewahren kann, aber es gibt es auch für S3 Buckets, für Konsolen, also auch für die ganzen HashiCorp Tools und so weiter. Bitte immer benutzen. Genau. Soviel zur grundsätzlichen Funktion, wie Terraform funktioniert. Und da möchte ich jetzt eigentlich
13:43
gleich schon mit einem Beispiel anfangen. Entschuldigung, war das eine Frage? Dann möchte ich nämlich gleich noch mit einem Beispiel anfangen, mit einem einfachen um zu zeigen, wie das Ganze funktioniert. Und zwar möchte ich hier zwei Dinge tun. Ich möchte auf der einen Seite Azure benutzen,
14:02
um da eine Virtual Machine zu starten. Und auf der anderen Seite möchte ich von AWS benutzen, um eben da den S zu managen, dass man sich dann nachher auch via FQDN auf der Maschine einloggen kann via SSH. Okay. Was braucht man dafür?
14:22
Zunächst mal braucht man eine Resource Group in Azure, in der man quasi seine ganzen Elemente gruppieren kann. Dann braucht man ein virtuelles Netzwerk, also das Netzwerk, in dem man dann die Maschine deployen möchte. Ein Subnet da drin. Da kommt dann die Virtual Machine rein. Die soll ein Netzwerkinterface
14:42
bekommen mit einer Public IP, dass sie quasi auch von außen erreichbar ist über diese IP. Und diese IP soll dann anschließend genommen werden, um eben diesen Eintrag, diesen A-Record in Route 53 zu erstellen, um sich dann nachher mit der Maschine verbinden zu können. Dafür werden gleich lokal noch ein paar SSH Keys erzeugt
15:02
und auf der Maschine automatisch mit abgelegt, dass wir uns da einloggen können. Und für Bequemlichkeit lasse ich mir auch gleich noch ein SSH-Config-File rausschreiben. Genau also hier nochmal zusammengepasst, was man alles für dieses Szenario benötigt.
15:21
Sprich, man braucht die SSH Keys, man braucht ein virtuelles Netzwerk in Azure, man braucht eine Resource Group in Azure, wo man das Ganze natürlich reindeployen kann, ein Subnet, die VM selber, das Netzwerkinterface, die Public IP und dann zum Schluss auf AWS den A-Record. Und damit sind wir eben schon formal
15:40
auf zwei verschiedenen Providern unterwegs, eben auf Azure und auf AWS. So, und dann möchte ich tatsächlich auch gleich hier einmal reinspringen und dann eben zeigen, wie das Ganze aussieht. Okay, die Terraform State files werde ich schon mal nicht zeigen,
16:00
weil da stehen die ganzen Credentials drin, die möchte ich jetzt nicht rausgeben, aber ich möchte mal einen Blick werfen in die in die Providers. Terraform muss ja irgendwoher wissen, wie kann ich denn diese Ressourcen, diese VM, diese
16:22
Subnet und so weiter anlegen in Azure? Oder wie kann ich diesen A-Record anlegen in AWS? Diese Informationen sind ja in sogenannten Providern enthalten. Die muss sich Terraform erst einmal bekannt machen für das jeweilige Projekt, das ich habe. Welche Provider braucht es denn dafür?
16:43
Naja, und in dem Fall ist es halt eben einmal der Azure und einmal ein AWS Provider, den wir brauchen. Und das wird hier erstmal in der Datei angelegt. Und zwar funktioniert das so, das ist einmal das Keyword Provider, dann der Provider Namen und der entsprechende Config, den man noch haben möchte damit.
17:02
Und hier ist einmal eben der Azure und der AWS Provider. Ich nehme hier noch zwei weitere her. Und zwar ist es noch der Provider Local, um eben lokal bei mir auf der Maschine noch Files ablegen zu können. Und TLS fürs Erzeugen der Keys, die ich nachher haben möchte.
17:21
Das sind einfach noch zwei weitere Provider hier. Ich werde hier oben nach best practice noch festlegen in diesem Terraform Block, welche Version ich da gerne hätte. Nicht, dass jetzt hier kurz vor meiner Präsentation noch eine neue Version rauskam. Ich fahre ein Update und plötzlich hat sich irgendwas in der Syntax geändert, sehr ungünstig. Deswegen hier einmal noch die Version
17:42
gepinnt. Und das ist quasi das, was Terraform braucht, um nachher die ganzen Ressourcen anzulegen. Das war es schon dazu. Ich habe hier noch zwei weitere Dinge reingepackt. Das ist einmal die Information zur Resource Group und einmal zur Zone in World 53, wo ich eben den
18:04
Rekord deployen möchte. Das sind beides Informationen, die sind schon vorhanden. Die möchte ich nun mit Terraform auslesen. Und dafür benutze ich eben Data, diese Ressource Data und sage einmal, okay, das eine ist eine Azure Resource Group namens DISS und die möchte ich auslesen mit diesem Namen.
18:24
Und das Gleiche mache ich für die Zone. Die nenne ich auch DISS für World 53 und die soll diesen Namen haben. Jetzt sieht man schon, jetzt steht da irgendwas beim Namen drin von var, Punkt und dann eine ewig lange Bezeichnung.
18:41
Das sind sogenannte Variablen in Terraform. Die habe ich reingepackt in die Variablestf. Schauen wir mal kurz. Und zwar kann man Variablen quasi mit einem Default füllen bei Terraform oder man kann sie beim Ausform von Terraform
19:02
auch zum Beispiel über die Kommandozeile ändern. Das ist immer dann sinnvoll, wenn man irgendwelche Terraform Code schreibt, der eben auch von anderen benutzt werden kann, die dann zum Beispiel nicht meine Resource Group hier haben. Deswegen habe ich jetzt zum Beispiel den Namen von meiner Resource Group hier mal
19:22
als Variable angelegt. Dann sage ich einfach Variable Resource Group Name. Die kann ich nennen, wie ich will, diese Variable. Und dann eben sagen was ist es für ein Typ, was ist der Default Wert und noch eine kurze Beschreibung dazu packen. Jeder der das dann vielleicht nachher selber benutzen möchte kann eben das relativ fix mit seinem eigenen Wert überschreiben.
19:44
Selbiges mache ich eben auch hier für die Zone oder noch für so ein paar Sachen wie zum Beispiel in welcher Region möchte ich deployen in AWS. Da bin ich die Frankfurter Region und so weiter und so fort. Genau, ich könnte noch den SSH Keyname nachher ändern.
20:01
Da kann man eben solche Spiele reinmachen. Und dann sehen wir uns doch jetzt im nächsten Schritt mal an, wie solche Ressourcen aussehen. Das ist das Beispiel, was ich vorhin gezeigt habe, nämlich das Anlegen der SSH Keys, die nachher auf der VM deployed werden sollen. Der eigentliche Key wird hier oben erzeugt
20:25
als Ressource. Und dann werden eben zwei Files geschrieben, einmal für den Public und einmal für den Private Key. Und als Pfad packe ich hier ein paar Variablen mit rein. Es gibt ein paar Variablen, die sind bei Terraform vordefiniert, unter anderem
20:41
im Pfad, in dem es ausgeführt wird. Das heißt dann einfach path.root. Und ich nenne noch den Pfeilnamen, den lese ich von meiner eigenen selbst definierten Variable ein. Und dann wird mir eben dieser SSH Key, wenn ich Terraform ausführe, erzeugt und abgelegt. Und dann für Bequemlichkeit
21:02
lasse ich mir diese ganzen Keys und Namen, die dann alle angezeugt werden, noch in den SSH Config Pfeil schreiben. So, dann gehen wir jetzt mal zum Eingemacht, nämlich zum Anlegen der Infrastruktur.
21:21
Und dieses Pfeil enthält jetzt, das ich jetzt hier zeige, alles, was dafür eigentlich nötig ist. Das ist der Kern des Ganzen. Wir haben gesagt, für diese VM braucht man erstmal eine Public IP, um ranzukommen. Dann kann man genau das anlegen, nämlich eine Resource namens Azure RM, Public
21:41
IP. Und die nenne ich das. Der weise ich noch einen Namen zu, in dem sie dann in der GUI in Azure auftauchen soll, sage, welche Resource Group ich dafür benutzen möchte, wo die reingepackt wird, in welche Location. Und ich sage, es ist eine Statische IP. Und das ist alles, was ich brauche, um Terraform zu sagen, dass es eben diese
22:03
IP benutzen soll. Dann kann ich weitermachen. Jetzt habe ich die IP. Jetzt kann ich mal sagen, okay, leg mir mal das virtuelle Netzwerk an, wo das Ganze reinkommen soll. Also sage ich Azure RM, Virtual Network, das gleiche Spiel. Ich muss wieder eine Location mitnehmen, ich muss wieder eine Resource Group
22:23
Name angeben und dann muss ich eben den Azure Space mit angeben. Also welches Netz darf es denn sein, das ich anlegen möchte und ihm noch einen Namen geben. Subnet funktioniert ganz genauso. Da muss ich natürlich den
22:41
SIDA vom Subnet mit angeben. Und jetzt bin ich schon so weit, dass ich das Netzwerk, Subnet und die IP habe. Dann kann ich mich jetzt schon um die Teile kümmern, die ich eben für die VM noch brauche. Das ist einmal das Netzwerkinterface. Das ist hier definiert, in diesem ganzen Block hier. Wie funktioniert das? Eben wieder
23:03
Resource Group Name rein, Location, Name. Und jetzt kann ich eben die IP-Konfiguration mitnehmen und sage, mir für das Ding soll eben eine Public IP bekommen. Und zwar die, die ich vorher definiert habe. Und dann sage ich eben Public IP Address ID ist Azure RM Public IP. Wir haben die
23:23
vorher DIS genannt. Und wenn sie deployed ist, kriegt die eben eine ID. Dann sage ich Punkt ID. Gut, nachdem ich das jetzt habe, fehlen eigentlich nur zwei Dinge. Erstmal die VM selber zu deployen. Das wird jetzt natürlich der größte Block hier. Das sage ich jetzt
23:41
Azure RM Linux Virtual Machine Dis. Sag, wie soll sie denn heißen? Wo soll sie denn hinkommen? Welche Größe sollen sie haben? Was soll denn der Admin Username sein? Und dann weise ich eben das Netzwerkinterface zu, was ich vorher definiert habe. Pack noch die SSH mit rein. Das kann ich hier an der Stelle machen, die ich vorher erzeugt habe.
24:02
Konfigurier noch ein bisschen die Platte. Sag noch, welches Image das Ganze benutzen soll. Ich nehme jetzt hier mal Ubuntu 20.04. Okay, nicht das neueste, aber noch Long-Term-Support. Und bin fertig mit meiner VM. Das heißt, nachdem die erzeugt ist, ist das Einzige, was ich noch machen muss,
24:21
eben noch den Rekord anzulegen. Wie geht das? Naja, ich sage jetzt AWS Route 54 Vector. Dis. Sage, in welche Zone es rein soll. Sag, welchen Namen das Ding haben soll. Dann nehme ich einfach den Namen, den meine Linux-Maschine bekommen hat, dass es ein A-Rekord ist.
24:42
De-Time-To-Live. Und ich schreibe jetzt hier eben die IP rein, die Public IP, die ich vorher meiner Maschine zugewiesen habe. Und damit bin ich fertig. Jetzt gibt es natürlich ein kleines Problem.
25:00
Das Ganze zu deployen dauert natürlich eine gewisse Zeit. Das wollte ich jetzt hier nicht im Vortrag quasi den komplette Deployment machen, aber ich zeige mal, wie das Ganze aussieht, wenn es durchgelaufen ist. Ich kann jetzt nämlich hier sagen, Terraform Plan. Und einfach mal von Terraform ausgeben lassen,
25:20
was eben gerade an meiner Infrastruktur zu tun ist. Und es sagt mir eben hier, die Infrastruktur habe ich gerade ausgelesen, es ist alles da, was da sein sollte. Das heißt, ich habe hier die Information zurückgekriegt. Okay, es ist alles deployed und es hat alles den Stand, den es
25:43
haben soll. Das heißt, ich kann hier zufrieden sein, ich brauche kein Apply. Alles hat beim Ausrollen so funktioniert, wie es sein sollte. Und ich kann jetzt meine Infrastruktur mal testen. Und das werde ich auch tun, indem ich hier mal in das Verzeichnis reingehe, wo es meine SSH Keys abgelegt hat.
26:03
Da sind jetzt eben Public und Private Key drin. Und wir werden, ich schaue jetzt mal hier in meinen SSH Config File. Und da sehe ich eben, es gibt hier zwei vorkonfigurierte Hosts. Ich kann mich einmal mit der IP einlocken oder eben mit der FQDN. Und ich werde das jetzt einmal ausprobieren, einmal tun.
26:26
Kopieren wir uns das gleich mal. Und kann eben sagen, benutze mir das Config File, versuche dich mal via IP auf meiner
26:43
VM einzulocken. Und schon bin ich drauf. Also ich sehe, die VM wurde auch deployed mit der Public IP, die da drin stand. Und ich komme da drauf, kein Problem. Das ist natürlich die Frage, wie sieht
27:01
es denn mit dem FQDN aus? Das sieht man natürlich, ich habe das Ganze vielleicht schon mal vorhin getestet und jetzt beschwert er sich hier, dass ich ihm natürlich,
27:20
na, wirst du wohl? Immer wenn man hier mal demonstriert, sorry. So, ich kopiere das mal etwas raus. Piste das rein. So, neuer Fingerprint.
27:44
Jetzt hat. Genau. Also man sieht, ich kann mich jetzt auch via FQDN einlocken. Das heißt, auch von AWS Seite hat das funktioniert. Mit dem A-Record ist kein Problem hier. Und das ist eigentlich schon das simpelste
28:00
Beispiel, um eben Multicloud zu arbeiten. Ist jetzt natürlich ein sehr einfaches Beispiel. Jetzt möchte ich mal das auch ein bisschen komplizierter machen im nächsten Schritt. So, hier habe ich natürlich noch ein paar Sachen mitgebracht, falls die Netzwerkverbindung nicht geht. Aber brauchen wir hier nicht die Folien.
28:23
Das heißt, ich springe jetzt gleich mal zum zweiten Szenario. Das baut im Endeffekt jetzt auf dem ersten auf. Aber jetzt soll es komplizierter werden. Und zwar möchte ich jetzt einrichten eben eine VPN- Seite-Side-Connection zwischen einem Azure und einem AWS-Subnet. Und dann möchte ich jetzt zwei Hosts
28:43
reindeployen. Einmal auf Azure und einmal auf AWS-Seite. Und eben dort jetzt eine VPN-Connection ermöglichen darüber, dass sie sich eben lokal verbinden können. Was brauchen wir dafür? Na ja, auf Azure-Seite sieht das Ganze jetzt noch genauso aus für die
29:03
VM wie vorher. Ah, pardon. Genau, das heißt auch hier werde ich wieder ein Subnet haben, in dem eben meine VM sitzt, mit dem entsprechenden Netzwerkinterface und der entsprechenden Public API. Soweit so gut. Und genau das gleiche, das Pondor dazu, möchte ich jetzt eben auch auf AWS-Seite
29:23
aufziehen. Das heißt auch da wieder das entsprechende Subnet mit der VM drin. Das Ding soll bitte eine Elastic API bekommen, was Pima Dauman das Pondor ist von der Public API in Azure. Ich hoffe, da stört sich jetzt keine dran.
29:40
Und dann möchte ich eben auch hier in diesem Subnet in AWS noch ein Internet-Gateway anlegen, das eben diese Maschine in dem Subnet auch von außen erreichbar ist bzw. selber ins Internet kann. Und noch ein paar Security-Rules anlegen und ein Routing-Table. Soweit so gut. Also im Endeffekt genau das Pondor auf Azure-Seite. Was kommt neu dazu?
30:05
Auf Azure-Seite. Na ja, ich brauche ja im Endeffekt jetzt ein VPN-Gateway. Dafür lege ich jetzt ein neues Gateway-Subnet an, in das das Ganze reinkommt. Und zwar das sogenannte Virtual-Network-Gateway bei Azure. Das bekommt eine Public-IP, damit es auch von außen erreichbar ist. Und das soll eben die VPN-Verbindung
30:24
von Azure-Seite aufbauen. Wie sieht das auf AWS-Seite aus? Na ja, da gibt es das sogenannte VPN-Gateway. Das bekommt eine Elastic-IP, damit es von außen erreichbar ist, die sich eben nicht ändert. Und zwischen diesen beiden Gateways möchte ich dann eben meine Verbindung aufbauen. Genau.
30:46
Also nochmal zur Übersicht. Es soll also quasi eine Linux-VM im Azure-Subnet 10.0.1.0 angelegt werden. Und eine Linux-VM im AWS-Subnet in 10.10.1.0. Und dann möchte ich zwischen beiden eben eine
31:01
Side-to-Side-Connection einbauen. Und es soll nachher möglich sein, die Maschinen zu pingen. Also ICMP soll funktionieren. Und ich möchte Port 22 offen haben. Also via SSH von der VPNen auf die andere Maschine lokal rüberkommen.
31:20
Was brauche ich dafür? Na ja, das Setup in Azure ändert sich nicht viel für die VM. Das sind dieselben Elemente bloß eben mit anderen Netzsegmenten. Auf AWS-Seite für die VM braucht man eben eine Virtual Private Cloud. Also ich sage mal der große Container, das große Netzwerk. Dann das Subnet, eine Elastic-IP. Wir brauchen Internet-Gateway,
31:44
damit man nachher auch die Maschine von außen erreichen kann. Die VM selber, das wird eine EC2-Instance sein. Das kleinste, was es gibt für Demozwecke, da reicht eine T2-Micro. Man wird natürlich die SSH-Keys draufpacken. Die muss man vorher einmal hochladen zu AWS. Und ganz wichtig an der Stelle noch,
32:04
man muss auch noch die Security Group definieren, die eben nochmal inbound und outbound-Traffic zu der VM beschränkt. Und da werde ich jetzt einfach als Gründen einfach den Traffic komplett zulassen. Für den Demozweck ist das okay. Für praktische Anwendungen natürlich nicht, aber
32:23
hier drücken wir mal ein Auge zu. Genau, fürs VPN-Setup von AWS-Seite braucht man natürlich das Gateway und die Elastic-IP und eine Routing-Table, um den Traffic auch richtig zu routen. Das ist die Frage, was brauchen wir da auf Azure-Seite? Dann nimmt Azure uns ein bisschen was ab. Da werde ich einfach das Standard-Routing von
32:42
Azure benutzen. Das heißt, da muss ich nicht selber noch irgendwie eine Routing-Table definieren. Ich brauche ein Virtual-Network-Gateway und ein Gateway-Subnet. Und die eigentliche Verbindung wird dann ganz am Ende geschlossen zwischen beiden. Und zwar muss ich dafür noch sogenannte Azure-Local-Gateways erzeugen,
33:02
beziehungsweise AWS-Customer-Gateways, sind nichts anderes als die Verbindungsinformation, die die Gateways brauchen zueinander nochmal in Boxen abgelegt. Und das Ganze habe ich auch hier einmal dann vorbereitet.
33:20
Ich gehe mal hier raus. Denn so ein Gateway zu deployen kann bis zu 45 Minuten dauern. Da habe ich leider jetzt nicht die Zeit dafür. Und ich glaube auch nicht, dass jemand hier so lange warten möchte.
33:41
Guter Punkt. Genau. Hier habe ich das Ganze jetzt mal noch ein bisschen anders da aufgeteilt. Von den Dateien her. Gehen wir mal nochmal hier durch.
34:03
Ich möchte nochmal ein paar Zeilen zeigen. Zunächst mal hier unser Azure-TF. Gucken wir mal rein. Dass ich hier auch keinen Unsinn erzähle. Ich habe hier wieder die Public IPs, Virtual Networks, Subnet, Network Interface, die Maschine selber.
34:23
Und natürlich jetzt kein Eintrag mehr zu Route 53. Also sprich auf der Seite für die VM-Deployment ändert sich nicht viel. Das VM-Deployment auf AWS-Seite habe ich hier mal reingebracht in AWS.TF. Das sieht man eben. Hier wird
34:45
die Virtual Private Cloud initialisiert mit dem CIDR-Block. Ich packe hier gleich mal Internet Gateway mit dazu in dieses Subnet. Schauen wir mal. Genau. Und hier haben wir eben
35:02
schon drinnen die entsprechende Route. Hier habe ich eben, sage ich eben, okay, all der Traffic, der nicht mehr definiert ist, bitte schieße ich es über das Internet Gateway. Aber der Traffic, der eben dann intern ins SRM-Subnet gehen soll,
35:23
schickt bitte über das VPN-Gateway. Das sehen wir nachher noch, wo das definiert ist. Ich weise die entsprechende Route eben dem Subnet zu. Definiere mir hier noch Security Groups. Also nochmals quasi diese Kapsel
35:40
um meine VM in AWS. Und da sage ich einfach, okay, lass mir ICMP und SSH eben zu rein und raus, sowieso alles. Dann lade ich noch die Keys hoch, die ich deployen will. Die SSH-Keys in AWS, die muss
36:02
ich einmal hochladen. Hab hier noch meine Elastic IP und jetzt nachdem ich noch die Elastic IP habe, kann ich endlich meine VM deployen mit all den Informationen von vorhin. Das ist eben AWS Instance Disk. Nehme eine T2 Micro Instance, also das kleinste, was so
36:22
rumläuft. Sag, welches Image ich dafür haben will. Dann nehme ich einfach Amazon Linux. Pack die Keys rein. Sag, in welches Subnet soll, in welche Security Group zugewiesen werden soll. Ich werde hier gleich noch einen zusätzlichen User anlegen, dass ich nicht nur diesen EC2-User
36:42
habe, sondern auch meinen Atex User vorher. Pack eben noch hier ein paar Infos dazu, wie zum Beispiel noch ein Name Tag, damit ich die Maschine auch über die GUI zum Beispiel schnell finde. Und das war's. Das reicht, um meine
37:02
AWS VM zu deployen. Dann kommen wir jetzt zum Eingemachten. Das ist nämlich die VPN-Verbindung. Fangen wir mal auf die AWS Seite an. Da werde ich jetzt zunächst mal das Customer Gateway einrichten. Da kommen im Endeffekt nur die Verbindungsinformation nach Escher rüber rein, dass das
37:23
halt AWS bekannt ist. Und dann deploy ich das AWS VPN Gateway. Und das ist alles, was ich dazu brauche. Das ist dieser Block hier. Dann werde ich noch die Verbindungen definieren.
37:43
Das ist eben VPN Connection, AWS VPN Connection gut. Mit den zwei werden quasi die Verbindungen dann definiert und geschlossen von AWS nach Escher rüber. Das heißt, im Endeffekt
38:04
reichen mir hier auf AWS Seite für die VPN Connection diese vier Blöcke aus. Auf Escher Seite brauchen wir ein bisschen mehr.
38:20
Genau, da brauchen wir eben wieder auch eine Public IP, um dieses Gateway von außen zu erreichen. Das Subnet, wo es rein soll, das hier ist Escher typisch. Das muss so heißen, dieses Subnet in der empfohlenen Größe. Und dann kommt hier eben mein Virtual Network Gateway, also die andere Seite der Verbindung. Und hier definiere ich eben die Details
38:44
zu meiner Verbindung rein. Was soll es denn für ein Typ sein? So eine VPN-Verbindung sein, ne? Ganz route-based. Was für eine Generation, was für ein Typ und eben welche Public IP soll es haben und in welchem Subnet soll es sein.
39:02
Hier mache ich noch einen kleinen Trick. Hier wiederhole ich quasi diese Public IP, die ich vorher hatte. Warum muss ich das tun? Mit einem Data Group? Naja, diese Escher im Public IP, die ist jetzt dynamisch angelegt. Das bedeutet, die wird erst definiert seit in dem Moment,
39:21
wo sie angelegt wird, wo sie also diesem Gateway zugewiesen wird oben. Das heißt, möchte ich die irgendwo anders da verwenden, muss ich sicher gehen, dass die schon angelegt ist. Da das Ganze aber dynamisch passiert, weiß das an der Stelle Terraform noch nicht, ob die eben angelegt ist oder nicht. Das heißt, da muss ich mich jetzt mit einem Trick selber drum kümmern.
39:43
Wie funktioniert das? Naja, ich definiere nochmal einfach eine Data Resource namens Escher im Public IP Gateway. Und sage eben, ok, referenziere mir das bitte auf mein Virtual Network Gateway, also hole mir diese Information im Endeffekt raus, sobald mein
40:02
Virtual Network Gateway angelegt ist. Und so kann ich eben sicher sein, dass diese IP existiert und mir Terraform dann nicht irgendwie Fehler wirft. Das muss man immer dann machen, wenn irgendwas an der Stelle eben dynamisch auf diese Art und Weise angelegt wird, um eben dafür zu sorgen, dass das dann auch da ist, wenn Terraform drauf zugreifen möchte. Und hier unten
40:24
wird dann die Verbindung geschlossen. Sprich, hier haben wir einmal das Local Network Gateway, da kommen eben die AWS Verbindungsdaten rein. Das sind insgesamt zwei Tunnel, die hier aufgemacht werden von AWS
40:40
Seite, einfach aus Redundanzgründen, Ausfallsicherheit. Das heißt, ich mache auch zwei Verbindungen rüber, einmal für Tunnel 1, einmal im Local Network Gateway eingetragen und die Verbindung geschlossen dafür, für Azure M Virtual Network Gateway Connection und einmal für Tunnel 2 hier unten.
41:06
Das Ganze wird funktionieren über Preshared Keys und das ist eben das Schöne hier an Terraform an der Stelle. Das funktioniert eben so, dass man sagt, ok, ich bau diese Verbindung, diese Keys werden intern an Terraform zurückgegeben, das heißt,
41:22
ich kann die mir hier gleich als Ressource weiter verwenden und eben dann sagen, die kompletten Verbindungsdaten, die ich brauche von AWS und von Azure kann ich eben beiden Seiten zur Verfügung stellen, einfach damit, dass ich Terraform benutze. Ich werde hier jetzt auch
41:41
einmal noch einen Plan ausführen, um zu zeigen, dass das Ganze eben funktioniert. Da braucht ihr jetzt natürlich einen Moment länger, um das alles auszulesen. Also auch hier ist das Ganze schon quasi deployed. Das heißt, ich brauche gar kein Terraform
42:03
Apply mehr. Ich kann jetzt mal in den Folder schauen, wo mir meine Keys angelegt werden. Und hier habe ich eben vier Einträge drin. Einmal, um quasi von
42:20
extern auf die Maschinen drauf zu kommen. AWS vor allem, Azure VM über die Public IPs, die sie bekommen haben. Und dann habe ich hier noch eingetragenen Proxy Jump. Das heißt, ich kann im Endeffekt gleich sagen, okay, spring mir von außen auf die Azure VM und von da lokal auf die
42:41
AWS VM mit der internen IP 10.1.220. Das heißt, da bitte lokal drüber gehen. Und das werde ich jetzt auch einmal testen.
43:00
Glocken wir uns mal erstmal auf der von AWS. Ah ja, schön. Ich muss natürlich auch das Config-File angeben, sonst geht da natürlich gar nichts. Also von außen komme ich an die Maschine dran. Jetzt ist die Frage, kann ich denn von da aus auch meine Azure Maschine
43:24
pingen, wenn ich jetzt auf meine AWS Maschine bin? Ups, da habe ich wohl die falsche IP eingetragen. Entschuldigung. Ah, Entschuldigung. Das sieht man ja. Es hat tatsächlich funktioniert.
43:56
Man sieht, ich kann eben diese Maschine hier pingen. Sorry.
44:02
Und komme eben auch lokal über die 10.0.1.4 auf die Azure Seite über meine VPN-Connection hin. Jetzt kann man noch das Spiel machen und einmal sagen, okay, wie ist denn das, wenn ich mich zuerst auf meinen Azure Host einlogge und dann den ProxyJump, also eine SSH-Verbindung,
44:22
lokal rüber mache auf die AWS-Seite. Und da sieht man, ich komme wieder auf die Maschine raus. Bin jetzt aber lokal über mein Netzwerk da gegangen und über die VPN-Connection und nicht online.
44:43
Genau. Und so kann ich eben mithilfe von Terraform so eine VPN- Side-to-Side-Connection aufbauen zwischen verschiedenen Anbietern und eben auch diese Informationen lokal sammeln, beiden Seiten zur Verfügung stellen und einen Durchgang eben aufsetzen.
45:04
So, da bin ich auch am Ende von meinem Vortrag angelangt. Fast pünktlich. Kurze Zusammenfassung, also nochmal Multicloud mit Terraform geht. Der Einstieg ist eben auch sehr gut möglich mit Terraform.
45:21
Jeder, der das gerne mal selber ausprobieren möchte, würde ich einfach raten, einfach mal eine Chance zu geben, mal auf die Seite zu gucken, mal in die Doku reinzugucken und das drunterzuladen und mal auszuprobieren. Dessourcen Deployment ist halt sehr einfach möglich mit dieser Syntax. Für Leute, die es gerne noch ein bisschen kryptischer mögen, die
45:40
können auch gerne JSON verwenden, um nicht diese Terraform-Language, würde ich aber keinem empfehlen. Workflow ist eben immer Codes schreiben, dann in Terraform planen, gucken, was er macht, wenn man zufrieden ist Terraform apply, ausrollen oder eben nochmal zurück zur Code-Basis. Soweit zum
46:02
grundsätzlichen Arbeiten und das noch als kleiner Ausblick, wenn man das Ganze dann natürlich produktiv einsetzen möchte, bitte für alle immer aufpassen für das State-File, das immer sicher aufbewahren, idealerweise gleich im Back-It aufsetzen und das Ganze kann man dann natürlich dann auch, weil man eben
46:21
Code hat, eben mit entsprechenden Verwaltungstools, ich sag mal, traktieren. Beispiel bei mir eben ist, man rollt das Ganze in, packt das Ganze in Git, macht das mit den Git-Pipelines eben diese Infrastruktur aufzusetzen und benutzt eben gleich das Backend davon. Genau, dann bin ich jetzt auch am Ende vom Vortrag angelangt
46:45
und hier unten werden auch nochmal die Links, wer sich eben für die ganze Dokumentation für Terraform interessiert, kann da einfach gerne mal nachgucken. Genau, dann gibt es Fragen dazu.
47:00
Oh ja, was ich mich jetzt so ein bisschen frage, wo ist die Grenze zum Thema auf der Maschine selber quasi konfigurieren und Infrastruktur machen? Also wenn man benutzt, da streitet es sowas wie Ansible oder ähnliches Zeug, um auf einer Maschine was einzurichten
47:20
und so. Jetzt hast du hier aber bei Terraform schon gezeigt, ok, du legst da ein paar SS-Hakis an, legst die auch mit Terraform auf deine Entwicklermaschine ab als Dateien und gibst sie dann zumindest bei den Clouds nur in die Cloud-Konfig mit, dass die Clouds automatisch das SS-Hakis bei sich auf den Maschinen unterlegen, aber wo zieht man da so wirklich
47:41
so die Grenze zum Thema Maschinen-Lokale-Konfiguration und Infrastruktur-Konfiguration, weil das verstehe ich gerade nicht noch nicht so ganz, wo da quasi Terraform die Grenze sieht. Ich bin mir nicht sicher, ob ich die Frage an der Stelle richtig verstehe. Wie weit geht Terraform in die lokale Konfiguration
48:01
rein? Also wo ist so für Terraform Schluss? Kann ich theoretisch Ansible komplett mit Terraform ersetzen oder? Es kommt drauf an, welche Philosophie man da bewegt. Also es ist tatsächlich so, dass ich auch unter anderem das gesehen habe, bzw. wir so in der Firma, dass wir einen Einsatz haben, dass man eben auch Terraform mit Ansible
48:21
kombiniert, dass man eben dann auch Hosts eben aufsetzt und dann noch ein Ansible-Playbook drauf laufen lässt. Kommt so auch ein bisschen drauf an, wie man mit den Images rangeht, würde ich sagen. Diese Image-Philosophie in der Cloud-Image und Co. und dann noch nachfunktionen mit Cloud-Init oder
48:40
ich würde sagen, das würde ich dann je nachdem auf das jeweilige Szenario gucken, wie man da am besten rangeht. Es ist aber durchaus möglich, eben Terraform an der Stelle auch mit Ansible zu kombinieren. Dass man sagt, man rollt die VM aus, macht die ganze Infrastruktur mit Terraform und dann die letzte Konfiguration auf seinen Hosts eben mit Ansible.
49:02
Okay, danke. Wie sieht das denn jetzt aus, wenn man in Anführungszeichen gewachsene Infrastruktur hat und möchte die jetzt an der Stelle in so ein System übernehmen? Da muss man natürlich immer gucken.
49:21
Tatsächlich hatte ich jetzt einen Fall selber nicht, dass ich eben auch so zugeben. Es ist natürlich immer möglich, bestehende Infrastruktur auszulesen mit Terraform und eben anhand dieser Informationen weiterzumachen.
49:42
Das heißt, man kann da durchaus auch die Informationen jetzt von bestehenden Datenbanks, Server in der Cloud usw. nehmen und dann da die Anbindung mit Terraform weiter stricken. Ich würde aber empfehlen, das dann nochmal komplett vorsichtig zu sein, sage ich mal. Dass man nicht so eine Mischung drin hat, weil dann
50:01
findet jetzt natürlich dieses Infrastructure as Code Prinzip wird dann so ein bisschen aufgeweicht an der Stelle. Würde ich mir im Detail aber auch immer für das Szenario ansehen, kann ich jetzt quasi kein Patentrezept an der Stelle liefern.
50:22
Du hattest gesagt, dass du auch Erfahrungen mit der Hetzner Cloud auch hast. Gibt es denn Sachen, die bei der Hetzner Cloud mit Terraform nicht funktionieren, die bei der AWS gehen oder wie sind da so deine Erfahrungen? Also ich muss dazu sagen, bei Hetzner
50:43
habe ich mir es angesehen für das Deployment von entsprechenden Maschinen. Generell kann ich sagen, zu den Providern, die da benutzt werden, das ist nämlich ein ziemlich guter Punkt an der Stelle,
51:01
muss man immer aufpassen. Wenn man so einen Tool benutzt, muss man immer gucken, wie diese Providern natürlich dahinter sind, ob die aktuell sind, weil wenn die veralten für so ein Ding, dann nutzt einem natürlich auch das Tool nichts. Da kann ich aber erstmal dazu sagen, dass eben die Providern, da habe ich gute Erfahrungen mit gemacht, aktuell gehalten werden und dass man eigentlich mit den Sachen, die
51:21
über die API geregelt werden kann, den meisten Providern gut zurecht kommt, bei den Hetzner würde ich jetzt, kann ich es jetzt gerade nicht sagen, wie das quasi, welche Funktionalitäten da im Detail jetzt noch nicht gehen oder doch gehen, da müsste ich echt noch in die Doku schauen, wie er das da unterstützt wird.
51:42
Ich kann es auch nicht für alle Features bei AWS und Azure sagen tatsächlich, da müsste ich dann nochmal gucken, ob es da noch irgendwelche Probleme gibt. Für die ganzen Standardsachen bin ich jetzt da gerade für AWS und Azure kann ich mir sagen, jetzt keine Probleme reingerannt, wie weit das dann im Detail vielleicht noch für die 50. Konfigurationsmöglichkeit
52:01
für die Datenbank ist, kann ich es jetzt leider in der Tiefe nicht sagen, weil es auch so ein großes Feld ist. Können Sie was für Erfahrungen mit dem Provider Malti sagen? Malti? Ja genau, Multicloud, so ein relativ neues Projekt, das versucht die Einzelprovider zu vereinheitlichen.
52:25
Kann ich leider an der Stelle jetzt nicht. Das geht glaube ich in eine ähnliche Richtung. Die Provider sind ja spezifisch für einen entsprechenden
52:40
Service. Wenn ich jetzt meine gesamte Infrastruktur quasi von heute auf morgen umziehen müsste, wollte, wie aufwendig wird das? Da muss ich natürlich dazu sagen, dass Terraform jetzt kein Migration Tool ist in irgendeiner Form, wie es halt auch von Multicloud-Provider oder dergleichen, wann durchaus mal angeboten wird.
53:01
Das heißt, da muss man schon Zeit und Arbeit reinstecken und das Ganze auch dementsprechend gut planen. Es gibt quasi jetzt keinen, ich sag mal Terraform Migrate Button zwischen verschiedenen Dingen. Es geht tatsächlich auch weniger auf die Migration bezogen, sondern wie sehr unterscheidet sich der Code für verschiedene
53:20
Provider, wenn ich jetzt quasi sage, ich möchte jetzt nicht mehr auf AWS deployen, ich möchte jetzt auf Azure deployen. Wie hoch ist der Aufwand, die Scriptings anzupassen? Ah, okay. Vielleicht schauen wir da einfach jetzt nochmal die Beispiele an für Azure und AWS.
53:41
Inwieweit die sich unterscheiden und da so ein bisschen Gefühl drin zu haben. Ich denke, was da ganz gut gehen würde ist vielleicht hier der große Block für die VM, was ein bisschen eingängig ist. Na, bist du wohl?
54:00
Man ist da tatsächlich halt auf die Syntax des jeweiligen Providers natürlich gebunden. Ganz klar. Inwieweit für einen jetzt das ein Problem ist, kann man vielleicht sich hier mal anschauen. Das sind jetzt im Endeffekt ja hier einmal links und einmal rechts
54:22
für die Maschinen im Endeffekt identisch oder nahezu identische Informationen. Das heißt, man hat hier durchaus einen Unterschied, wie man das Ganze angeben muss. Also man hat einen Syntax-Unterschied und wenn man quasi jetzt sagt, das eine soll ein Pendant vom anderen sein,
54:42
muss man schon eine Zeit quasi aufwenden, um das Ganze umzuschreiben. Das hängt allerdings auch damit zusammen, dass natürlich jeder Cloud-Anbieter da so auch die Grundformen zwar malerweise identisch sind, aber da auch so ein bisschen sein eigenes Süppchen kocht in Benennung, in
55:02
Form, wie er es denn gerne haben möchte. Und das sich natürlich auch so in den Providern widerspiegelt. Also man hat schon diesen Unterschied. Man sieht es hier zum Beispiel, dass man, dass ich hier einmal zum Beispiel Cloud-Init benutzt habe, um diesen User mit diesen Keys anzulegen und auf der anderen Seite gebe ich zum Beispiel, ups, pardon,
55:20
was denn hier, zum Beispiel die SSH-Keys selber nochmal in der Form mit. Das wäre jetzt so ein Unterschied, auf den man wirklich achten sollte und auch muss, damit das funktioniert. Also man hat da schon einen Aufwand, das umzuschreiben. Das ist es nicht.
55:44
Vielen Dank für den Vortrag. Du hattest ja empfohlen, die State-Files zum Beispiel in einem Git-Repository zu speichern, wenn ich das richtig verstanden habe. Aber davor hattest du auch gesagt, dass in den State-Dateien so Credentials drin sind.
56:01
Genau. Da würde ich dann tatsächlich aufpassen. Also ein Terraform-State-File sollte niemals in irgendeinem Repository landen. Auf keinen Fall. Wenn ich das gesagt habe, war das unsauber formuliert. Es geht eben um diese TF-Files, also da, wo die Ressourcen definiert werden, die Provider,
56:20
etc. Das würde ich mit der Versionsverwaltung stellen, zum Beispiel in dem Git. Dann gerne auch mit Branches, wenn Leute da mehrere zusammenarbeiten, dass man das auch nochmal refueht, etc. Und diese State-Files selber würde ich dann in den Backend packen. Und das erfordert natürlich nochmal bei so größeren Projekten dann auch nochmal in Schritt Automatisierung.
56:41
Dass man dann zum Beispiel, wenn ich jetzt sage, man möchte das Ganze in Git haben oder GitLab, dass man dann eben vielleicht seine Pipelines definiert, wie man das ausrollt und eben da auch nochmal die Anbindung definiert für sein State-File. Das heißt, wenn das durch seine Pipeline, kann ja auch Jenkins oder was man gerne benutzt sein, dass da automatisch eben dafür gesorgt wird, dass
57:00
dieses State-File A abgelegt wird in den Backend. In GitLab ist das eigentlich einigermaßen benutzerfreundlich geregelt. Da kann man sich dann so Tokens erzeugen lassen, wenn man die Permissions setzt, dass er sich das holt, dass es eben da drüber geregelt wird. Also quasi im Git nur DTF-Files und das State-File automatisiert
57:21
irgendwie in den Backend ablegen und holen für seine Sachen. So, gibt es noch Fragen? Keine Fragen mehr? Vielen Dank. Dann sage ich auch vielen Dank.