InfraCoders I

InfraCoders Vienna I, IaC Complete mit Terraform und Chef| Harald Schmaldienst
InfraCoders Vienna I
Toni Schmidbauer & Harald Schmaldienst
https://www.linkedin.com/in/tosmi/
https://www.linkedin.com/in/schmaldienst/
InfraCoders Vienna (Meetup)
https://www.meetup.com/de-DE/InfraCoders-Vienna/

I. Kurze Intro
II. Infrastructure Automation mit puppet bei Erste Bank
Toni Schmidbauer / s-IT Solutions
III. Monitoring von Docker/Kubernetes Environments mit
Prometheus bei der Telekom Austria
Oliver Moser / Telekom Austria Group
IV. Ansible - Why, how and it's so easy
Aleksandar Lazic / Me2Digital
V. IaC complete mit Terraform und Chef / Oracle Cloud
Harald Schmaldienst / Oracle

Warum InfraCoders Vienna?
…weil es in jeder Stadt „InfraCoders“ gibt ;-)

Warum Infrastructure as Code?
…weil es seit 2000 viel Gründe für Automatisierung gibt…

Definition: 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

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, …)

Vorteile von IaC
• Self-service
• Mit einem einzigen Skript/Programm ganze „Datacenter“ erzeugen.
(Netzwerk bis Server!)
• Geschwindigkeit & Sicherheit
• Die Automatisierung des gesamten Provisionierungs- und Deployment-Prozesses
beschleunigt den Vorgang erheblich und macht ihn verlässlicher als manuelle
Konfiguration.
• Dokumentation
• Der Zustand der Infrastruktur ist in Source Files abgebildet – für jeden lesbar und
nicht nur im Kopf eines einzelnen Sysadmins.
• Einfache Möglichkeit zur automatischen Erzeugung von Dokumentation

Vorteile von IaC
• Versionskontrolle
• Die gesamte History der Infrastruktur ist abgebildet
• Hilfreich beim Debuggen
• Roll-Back zu älteren Versionen
• Validierung
• Jeder Infrastruktur-Change kann mit Code Reviews oder automatisierten Tests vor
Einsatz überprüft werden.
• Wiederverwertbakeit
• In der Produktion getestete Infrastruktur Packages machen einfacher Scaling und
Weiterentwicklung der Infrastruktur einfacher
-> Happy developers 

Praktischer Teil. Live Demo
Marcus Doeringer & Harald Schmaldienst
https://www.xing.com/profile/Marcus_Doeringer2
https://www.linkedin.com/in/schmaldienst/
InfraCoders Vienna (Meetup)
https://www.meetup.com/de-DE/InfraCoders-Vienna/

Live Demo: Kurzer Überblick
1
• Oracle Cloud InfrastrukturINFRASTRUKTUR
• Hashicorp: Terraform
INFRASTRUKTUR DEFINITION
(Build, Change, Version)
• Chef Software: ChefCONFIGURATION MANAGEMENT

Oracle Cloud Infrastructure – 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)

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 Infrastructure – Design Konzepte

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

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

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

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

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

Terraform – entwickelt von HashiCorp

Terraform - Überblick
• Open Source Software mit großer Verbreitung im Markt
• Existiert „erst“ seit 2014
• Geschrieben in Go
• Runtimes verfügbar für OSX, FreeBSD, div. 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.
• Hat Plugins („Provider“) für alle gängigen Clouds (AWS, Google Cloud Platform,
Oracle Cloud (OCI)), sowie OpenStack, Vmware, uvm…

• 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"
}
]
}
]
}
]
}

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 = “10m"
}
}
provider "baremetal" {
tenancy_ocid = "${var.tenancy_ocid}"
user_ocid = "${var.user_ocid}"
fingerprint = "${var.fingerprint}"
private_key_path = "${var.private_key_path}"
}

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
• Error Handling – kein Rollback bei Fehlern
• 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”)

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/

Chef – Überblick
• Chef – entwickelt Tools zur IT Automatisierung
• Historisch aus Chef Tool gewachsen
– Entwickelt von Adam Jacob (für seine Consulting Firma)
– Firmengründung durch Jesse Robbins (ex – AWS Head of Ops, „Erfinder“ des „GameDay“)
• Hauptprodukte: Chef, InSpec, Habitat
• Chef
– Ein Configuration Management Tool, geschrieben in Ruby (Client) & Erlang (Server Core)
– Ausgereift, existiert seit 2009
– Unterstützt alle verbreiteten OS
– Starke Verbreitung in den USA, hatte früh namhafte Kunden wie Facebook, (Amazon),
Bloomberg, …
– Integration mit vielen Clouds (AWS, Google Cloud Platform, Azure, Oracle Cloud (OCI),
SoftLayer, Rackspace) zur Provisionierung/Konfiguration von Server Images
– Eher unter Entwicklern verbreitet als unter Sysadmins

Getting Started mit Chef
• Download ChefDK
• Download Chef Server
• Configure Chef Server
• Link ChefDK - Chef Server
• Upload cookbook
• Bootstrap node
• Run
• Mit chef-solo kann man chef auch serverless ausführen (Test oder
Entwicklung)

Chef - Komponenten
Node – Ressource – Recipe – Cookbook – Run List - Roles

Chef - Basics
• Der Anwender schreibt recipes
• Recipes können in cookbooks gruppiert werden
• Alle Operationen beziehen sich auf „ressources“, d.h. auf etwas das auf dem Zielsystem
konfiguriert werden kann, z.B.:
• Chef-client kann interaktiv aufgerufen werden oder als Agent auf einer Node, um den definierten
Zustand (wieder-) herzustellen.
• chef knife ist das Kommando, um den Chef Server und die Chef Nodes & Ressourcen zu managen.
• # knife bootstrap 129.146.22.221 --ssh-user opc --sudo --identity-file ~/.ssh/id_rsa --node-name
chef-client-1 --run-list 'recipe[learn_chef_httpd]'
File:
file '/tmp/file.deleteme' do
action :delete
end
Service:
service 'ntp' do
action [ :enable, :start ]
end
Package:
package 'httpd' do
action :install
end

Chef – Hello World
• File: hello.rb
• Resource type , Resource name, Resource properties.
• Ausführen mit: # chef-client --local-mode hello.rb
• Beispiel Install Skript:
• Viele Beispiele für Ressourcen: https://docs.chef.io/resource_examples.html
file ‘/tmp/hello.txt' do
content 'Hello, world!'
end
bash 'install_something' do
user 'root'
cwd '/tmp'
code <<-EOH
wget http://www.example.com/tarball.tar.gz
tar -zxf tarball.tar.gz
cd tarball
./configure
make
make install
EOH
end

Details zum chef-client run
Quelle: https://www.youtube.com/watch?v=H3Ggublb378

Zeit für die Demo! Beispiel 1
3
1. Erzeugt Infrastruktur bis VM

Zeit für die Demo! Beispiel 2
3
1. Erzeugt Infrastruktur nur bis Netzwerk

InfraCoders I

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie InfraCoders I

Ähnlich wie InfraCoders I (20)

Mehr von Harald Schmaldienst

Mehr von Harald Schmaldienst (6)

InfraCoders I

Hinweis der Redaktion