HashiCorp, Cloud Orchestration, IaC Über Terraform Terraform in Action: erste Schritte Oracle Bare Metal Cloud Services Grundlagen Live Demo Kubernetes on Oracle BMCS mit TF

1. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Infrastructure as Code mit Terraform
(Live Demo on Oracle Bare MetalCloud)
Marcus Doeringer
https://www.xing.com/profile/Marcus_Doeringer2
Harald Schmaldienst
https://www.linkedin.com/in/schmaldienst/
InfraCoders Vienna (Meetup)
https://www.meetup.com/de-DE/InfraCoders-Vienna/

2. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Agenda
• HashiCorp, Cloud Orchestration, IaC
• Über Terraform
• Terraform in Action: erste Schritte
• Oracle Bare Metal Cloud Services Grundlagen
• Live Demo Kubernetes on Oracle BMCS mit TF

3. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – entwickelt von HashiCorp
• HashiCorp – bietet verschiedene Tools für Cloud Operations
• Ziel des Tool-Sets – “Any Application” “Any Infrastructure”
• Provisionierung
– Vagrant- erzeugen und konfigurieren von portablen Entwicklungs-Umgebungen
– Packer – Erzeugen von platform-spezifischen server images aus einer “Single Source”
– Terraform – Erzeugung, Deployment und Management von Infrastruktur über
verschienden Provider hinweg (AWS, Azure, GCP, Oracle Cloud Vmware, uvm.)
• Secure
– Vault – Zentrales und sicheres Verwalten des Zugriffs auf “distributed secrets” (z.B. Keys)
• RUN
– Nomad - Cluster manager und Scheduler für das Deployment von Applikationen über
verschiedene Infrastrukturen hinweg
– Consul – Ein verteiltes, hochverfügbares Tool zur Service Discovery, Konfiguration und
Orchestrierung

4. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform
• Open Source Software mit großer Verbreitung im Markt
• Geschrieben in Go
• Runtimes verfügbar für OSX, FreeBSD, Linux, OpenBSD, Solaris, Windows
• IA32, x64 und ARM
• Fast development – monatliche Releases
• HCL: Hashi Configuration Language
– Interoperabilität mit JSON
• Gut integrierbar mit existierenden Tools - Puppet, Chef, Ansible, uvm.

5. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Cloud Orchestration & Infrastructure as Code (IaC)
• (…) Infrastructure as Code (IaC) is the process of managing
and provisioning computing infrastructure (processes, bare-
metal servers, virtual servers, etc.) and their configuration
through machine-processable definition files, rather than
physical hardware configuration or the use of interactive
configuration tools.[1]
• The definition files may be in a version control system. This
has been achieved previously through either scripts or
declarative definitions, rather than manual processes, but
developments as specifically titled 'IaC' are now focused on
the declarative approaches. (…)
[1] https://en.wikipedia.org/wiki/Infrastructure_as_Code

6. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Cloud Orchestration & Infrastructure as Code (IaC)
• Infrastructure Lifecycle
– Provision
– Update
– Destroy
• Die 4 generellen Kategorien von IaC
– Ad hoc Scripts
– Configuration Management Tools
(Chef, Puppet, Ansible, …)
– Server Templating Tools
(Packer, Vagrant, Docker, ….)
– Server Provisioning Tools
(Terraform, Cloud Formation, Heat, …)

7. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Vergleich der gängigsten Server Provisioning und Configuration
Management Tools

8. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Vergleich der gängigsten Server Provisioning und Configuration
Management Tools
Source: https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c

9. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Erste Schritte mit Terraform

10. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Erste Schritte mit Terraform ./
├── terraform
├── terraform-provider-atlas
├── terraform-provider-aws
├── terraform-provider-azure
├── terraform-provider-azurerm
├── terraform-provider-chef
├── terraform-provider-cloudflare
├── terraform-provider-cloudstack
├── terraform-provider-consul
├── terraform-provider-digitalocean
├── terraform-provider-baremetal
alicloud archive arukas atlas aws azure azurerm bitbucket chef circonus clc cloudflare cloudstack cobbler consul
datadog digitalocean dme dns dnsimple docker dyn external fastly github gitlab google grafana heroku http icinga2
ignition influxdb kubernetes librato local logentries mailgun mysql newrelic Neinmad ns1 oneandone opc
openstack opsgenie packet pagerduty postgresql powerdns profitbricks rabbitmq rancher random rundeck
scaleway softlayer spotinst statuscake template terraform tls triton ultradns vault vcd vsphere
• Download
– binary, apt, yum, choco, brew
• Create a .tf file in a workspace
– hw.tf
output "hw" {
value = "test” }
• $ terraform apply
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
hw = test
• Provider… ->

11. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
• Terraform Konfigs werden in .tf Files definiert
• Basierend auf der HashiCorp Configuration Language (HCL) https://github.com/hashicorp/hcl
• JSON ist für die Code Erstellung unterstützt
• Konfigs werden definiert nach folgendem Schema:
keyword1 "some_name" {
key = "value"
nested {
key = "value'
}
}
HCL – Basic Terraform .tf Format
{
"keyword1": [
{
"some_name": [
{
"key": "value",
"nested": [
{
"key": "value"
}
]
}
]
}
]
}

12. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – “Provider”
Zuerst definiert man den “Provider”
Provider abstrahieren die APIs aller unterstützen Anbieter, um Infrastruktur zu erzeugen.
Zum Beispiel:
provider "baremetal" {
tenancy_ocid = "${var.tenancy_ocid}"
user_ocid = "${var.user_ocid}"
fingerprint = "${var.fingerprint}"
private_key_path = "${var.private_key_path}"
}
Der baremetal Provider z.B. erlaubt es Terraform Resourcen im definerten Mandanten der BMCS zu erzeugen,
managen und zu löschen (apply – destroy)
Tenancy ist die OCID des Mandanten (“tenants”). User OCID is der Identifier des Users. Fingerprint ist der md5
fingerprint des privaten Keys, der verwendet wird, um auf die Cloud API zuzugreifen, und private key path ist
der Pfad zum privaten PEM Key für das API.

13. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – “Resources”
Ressourcen
Ist der Provider konfiguriert, kann man beginnen Ressourcen zu erzeugen.
Mit dem BMCS baremetal provider, kann man Cloud Ressourcen erzeugen,
Wie z.B. Compute Instanzen (Server& VMs), Block- und Object Storage, div. Netzwerk-Komponenten,
Loadbalancer, usw.
Das folgende Beispiel erzeugt eine Compute Instanz:
resource "baremetal_core_instance" "TFInstance" {
availability_domain = "${lookup(data.baremetal_identity_availability_domains.ADs.availability_domains[var.AD -
1],"name")}"
compartment_id = "${var.compartment_ocid}"
display_name = "TFInstance"
hostname_label = "instance1"
image = "${lookup(data.baremetal_core_images.OLImageOCID.images[0], "id")}"
shape = "${var.InstanceShape}"
subnet_id = "${var.SubnetOCID}"
metadata {
ssh_authorized_keys = "${var.ssh_public_key}"
user_data = "${base64encode(file(var.BootStrapFile))}"
}
}
component provider type name

14. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – Planning

15. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – Planning
Hat man eine Konfiguration definiert, kann man einen Testlauf ohne “Apply” durchführen .
"terraform plan" übernimmt die Konfiguration und erzeugt einen detaillierten Report darüber, welche Ressourcen erzeugt,
gelöscht oder geändert werden – inklusive den Informationen zu den Abhängigkeiten mit anderen Ressourcen, die von den
Änderungen betroffen wären.
terraform plan -out=plan1
Den Output von terraform plan zu speichern ist v.a. zum Vergleich mit den tatsächlich ausgeführten Aktionen hilfreich.

16. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – Apply

17. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – Apply
Nach Check des Plans kann die Konfiguration ausgeführt werden: APPLY
$ terraform apply
Man kann auch ein Apply von
Gespeicherten TF-Plänen ausführen:
$ terraform apply plan1
Plan und apply kann auch für einzelne
Ressourcen ausgeführt werden:
mit dem -target flag.

18. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform - Destroy

19. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform - Destroy
Wenn Infrastruktur gelöscht werden soll, kann das einfach unter Berücksichtigung aller Abhängigkeiten erfolgen mit:
$ terraform destroy
Nach einem Prompt nach dem “yes” zur Bestätigung löscht Terraform die komplette Umgebung – bzw. einzelne targets,
wenn man die angibt.
Wenn man mit Terraform beginnt, ist es wichtig den Zyklus von plan – apply - destroy zu beachten!
Wird z.B. eine Ressource in einem .tf File geändet oder gelöscht, erkennt Terraform die Differenz im Vergleich zum State File
und ändert oder löscht die Ressource beim nächten apply entsprechend!
$ terraform plan -destroy
Bietet die Möglichkeit zu sehen, was
gelöscht würde, ohne das “destroy”
Wirklich auszuführen.

20. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform - Variablen
Diese Beispiele zeigen häufig verwendete Varuablen wie compartment_id (Cloud Mandant), shape_id (Compute
Größe), OS image/version.
Best Practice ist, Default-Variablen in einem File "variables.tf" zu deklarieren.
# Choose an Availability Domain
variable "AD" {
default = "1"
}
variable "InstanceShape" {
default = "VM.Standard1.2"
}
variable "InstanceOS" {
default = "Oracle Linux"
}
variable "InstanceOSVersion" {
default = "7.3"
}
Map Variable
variable "environment" { default = "dev" }
variable "shape" {
type = "map"
default = {
dev = "VM.Standard1.2"
test = "VM.Standard1.4"
prod = "BM.Standard1.36"
}
}
resource "baremetal_core_instance" "app-server" {
image = "${var.image}"
shape = "${lookup(var.instance_type, var.environment)}"
subnet_id = "${var.subnet_id}"
}

21. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Variablen zuordnen und überschreiben
Variablen ohne default-Wert müssen natürlich Werte zugewiesen werden.
Haben Variablen keinen default-Wert, fragt Terraform bei “plan” oder “apply” nach einem Wert..
Default Varaiblen können mittels Command-Line, tfvars file oder inline überschrieben werden.
Beispiel für das Überschreiben auf der Command-Line:
$ terraform apply -var 'InstanceShape=VM.Standard1.4'
Beispiel für das Setzen von Variablen in einem .tfvars File:
instance_type="VM.Standard1.2"

22. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform - Outputs
Terraform can die dynamisch erzeugten Variablen anzeigen.
Häufiges Beispiel – die IP Adressen neu erzeugter Hosts anzeigen:
$ cat outputs.tf
output "InstancePrivateIP" { value = ["${data.baremetal_core_vnic.InstanceVnic.private_ip_address}"]}
output "InstancePublicIP" { value = ["${data.baremetal_core_vnic.InstanceVnic.public_ip_address}"]}
Oder am Ende eines terraform apply:
Apply complete! Resources: 4 added, 0 changed, 0 destroyed.
State path:
Outputs:
InstancePrivateIP = [ 10.0.0.10 ]
InstancePublicIP = [ 129.146.3.173]
Outputs werden oft zur Interaktion mit anderen Tools genutzt. Terraform show (human readable) und das terraform.tfstate
File beinhalten ebenfalls diese outputs.

23. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform - Provisioners
Terraform kann mit anderen “Provisioners” wie Chef, puppet, Ansible, oder Shells Skripten interagieren.
Das einfache Beispiel unten zeigt die Verwendung eines Provisioners zur Remote Execution, um ein touch auf ein File
mit touch anzulegen:
$ cat remote-exec.tf
resource "null_resource" "remote-exec" {
depends_on = ["baremetal_core_instance.TFInstance"]
provisioner "remote-exec" {
connection {
agent = false
timeout = "10m"
host = "${data.baremetal_core_vnic.InstanceVnic.public_ip_address}"
user = "opc"
private_key = "${var.ssh_private_key}"
}
inline = [
"touch ~/IMadeAFile.Right.Here",
]
}
}

24. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform Command - Übersicht
terraform
Usage: terraform [--version] [--help] <command> [args]
Common commands:
apply Builds or changes infrastructure
console Interactive console for Terraform interpolations
destroy Destroy Terraform-managed infrastructure
env Environment management
fmt Rewrites config files to caNeinnical format
get Download and install modules for the configuration
graph Create a visual graph of Terraform resources
import Import existing infrastructure into Terraform
init Initialize a new or existing Terraform configuration
output Read an output from a state file
plan Generate and show an execution plan
push Upload this Terraform module to Atlas to run
refresh Update local state file against real resources
show Inspect Terraform state or plan
taint Manually mark a resource for recreation
untaint Manually unmark a resource as tainted
validate Validates the Terraform files
version Prints the Terraform version
terraform.tfstate {
"version": 3,
"terraform_version": "0.9.5",
"serial": 1,
"lineage": "a54a3c11-c934-41d5-b60d",
"modules": [

25. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – Resource Graph - Visualisierung
Terraform kann Graphen mit allen Abhängigkeiten erstellen – z.B. für die Planung. management and more.
$ terraform graph | dot -Tpng > tgraph1.png

26. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
BMCS Compute Beispiel – Terraform Snippet
./compute.tf
resource "baremetal_core_instance" "TFInstance" {
availability_domain =
"${lookup(data.baremetal_identity_availability_domains.ADs.availability_domains[var.AD - 1],"name")}"
compartment_id = "${var.compartment_ocid}"
display_name = "TFInstance"
hostname_label = "instance1"
image = "${lookup(data.baremetal_core_images.OLImageOCID.images[0], "id")}"
shape = "${var.InstanceShape}"
subnet_id = "${var.SubnetOCID}"
metadata {
ssh_authorized_keys = "${var.ssh_public_key}"
user_data = "${base64encode(file(var.BootStrapFile))}"
}
timeouts {
create = "60m"
}
}
provider "baremetal" {
tenancy_ocid = "${var.tenancy_ocid}"
user_ocid = "${var.user_ocid}"
fingerprint = "${var.fingerprint}"
private_key_path = "${var.private_key_path}"
}

27. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Pros and Cons – Terraform
Vorteile
• Einfacher Start, fortschreitende Steigerung der Komplexität wo nötig
• Fördert das Prinzip der “Immutable Infrastructure”
• Security – Nachvollziehbarkeit - Versionskontrolle
• Vault, Consult, Nomad, Packer, Atlas von Terraform bilden eine stimmige Tool-Suite
• Ein spezialisiertes Tool für Provisionierung von Infrastruktur – schlankes und zielgerichtets Konzept
• Häufige Releases, sehr lebendiges Projekt, kommerzieller Support kann bezogen werden
Nachteile
• Der Import von existierender Infrastruktur ist mühsam / fast nicht möglich
• Des Handling von Variablen, Iterationen und weitergeben von Variablen kann unübersichtlich werden
• Bei unsauberer Entwicklung zu Beginn kann Bereinigung Neuerstellung bedeuten
• Configuration- und Server Management Tools sind weiterhin notwendig, WEIL:
• Umbenennen ist letztlich destroy-create (etwas extreme Form der “Immutable Infrastructure”)

28. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Terraform – weiterführende Info
Getting Started with Terraform - Kirill Shirinkin
978-1-78646-510-8
http://techbus.safaribooksonline.com/book/operating-systems-and-server-administration/9781786465108
Terraform: Up and Running - Yevgeniy Brikman
978-1-4919-7708-8
http://techbus.safaribooksonline.com/book/operating-systems-and-server-
administration/virtualization/9781491977071
The Terraform Book Kindle Edition - James Turnbull
978-0-9888202-5-8
https://terraformbook.com/

29. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Oracle Cloud Platform – was ist das Besondere daran?
“…reason is that most of the people who are architecting this cloud
at Oracle have already built Amazon, Azure, or Google. We’ve all
already made a ton of mistakes and are eager not to repeat them.”
- Matteo Frigo (Oracle Cloud Architect)

30. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Technology Benefit
Erweiterte Multi-Mandanten-Fähigkeit
Komplexe Organisationen und Access Management sauber
abzubilden
Availability Domains (ADs) Hochverfügbarkeit über mehrere Rechenzentren in Regionen
Flaches Netzwerk (Clos) & non-blocking
Völlig konstante sehr niedrige Latenz
“Noisy Neighbors” Problem eliminiert
IO Virtualization “off host”(!)
Ermöglicht sicheres Deployment von VMs UND Bare Metal
Servern ohne jeglichen “Cloud-Software” + erhöhte Sicherheit
Direct-attached NVMe Storage Für extreme IO Workoads im x 100k IOPS Bereich
Oracle Cloud Platform – Design Konzepte

31. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Availbility
Domain 1
Availability
Domain 2
Availability
Domain 3
Region 1
Availability
Domain 1
Availability
Domain 2
Availability
Domain 3
Availability
Domain 1
Availability
Domain 2
Availability
Domain 3
Region 3
Region 2
Region und Availability Domain Topologie
• Regionen ermöglichen Disaster Recovery (Geo-redundant)
• Availability Domains bieten High Availability innerhalb einer Region
• Fehler-unabhängige ADs
• “Geringe” Entfernung (km)
• Für Low-latency & High-bandwidth Netzwerk
• Synchrone Replication ist supported
• Trotzdem voneinender isoliert

32. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Innerhalb einer Region – High Availability
• Mehere fehlerunabhängige, komplett unabhängige Datacenter – Availability
Domains (ADs)
• Berechenbare niedrige Latenz & High Speed Netzwerk, verschlüsselter
Interconnect zwischen ADs
• < 500µs RTT Latenz, 1Tb/s Bandbreite z.B. in Region US Central (Phoenix)
• Ermöglicht zero-data-loss Architekturen (e.g. Oracle MAA) und
hochverfügbare Scale-Out Architekturen (e.g. Cassandra)
Datacenters
Region
Availability
Domain 1
Availability
Domain 2
Availability
Domain 3

33. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Innerhalb einer AD – hochskalierbares High Performance Netzwerk
• Clos Netzwerk (non-oversubscribed) – flach, performant, berechenbar
• Skaliert sehr gut – ~1 Million Netzwerk Ports in einer AD
• Berechenbare niedrige Latenz & High Speed Interconnect zwischen Hosts in
einer AD
• < 100µs RTT Latenz, 10Gb/s Bandbreite
Physical Network
Datacenters
Region
Availability
Domain 1
Availability
Domain 2
Availability
Domain 3

34. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Virtuelles Netzwerk mit Virtualisierung “off-box”
• Flexible und komplett konfiguierbare Overlay Netzwerke –Management und
IO unabhängig vom Hypervisor – reduzierter Overhead und Bare Metal
Ressourcen
Region Availability
Domain 1
Availability
Domain 2
Availability
Domain 3
Physisches Netzwerk
Data Center
Virtuelles Netzwerk

35. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
Any middlebox – IDS/IPS,…Bare metal hosts VMs Engineered Systems
Physisches Netzwerk
Data Center
Region
Virtuelles Netzwerk
Compute & Storage Ressourcen
Alle Layers – Hochverfügbar, konstante Performance, Flexibel
?
Availability
Domain 1
Availability
Domain 2
Availability
Domain 3
Bare metal w/NVMe

36. Vienna Kubernauts, Überblick über Infrastructure as Code mit Terraform | Harald Schmaldienst
ORACLE CLOUD INFRASTRUCTURE (REGION)
IGW
Internet GatewayVirtual Cloud
Network
AVAILABILITY DOMAIN-1 AVAILABILITY DOMAIN-2
Subnet-A
Public/Web
Subnet-B
App
Subnet-C
Database
IAM Service
Audit Service
Object Storage
Customer
Datacenter
Region Wide Services
Web Server 1
Nexus
App Server 1
Nexus
Batch Server
Oracle DB Server
DMZSubnetPrivateSubnets
Subnet-A
Public/Web
Subnet-B
App
Subnet-C
Database
Web Server 2
Nexus
App Server 2
Oracle DB Server
Oracle Data Guard
Failover
LB HTTP