Niezależnie od tego, czy jesteście developerami, sysadminami, czy też DevOps Engineers – prawie na pewno mieliście doświadczenie z webowymi panelami dostawców usług infrastrukturalnych takich jak AWS, GCP czy też OVH. Z poziomu tych paneli da się “wyklikać” wszystko, czego potrzeba, ale… czy aby na pewno tędy droga? Środowiskiem bardziej naturalnym dla każdego inżyniera jest wszakże edytor tekstu (czy też IDE) oraz różnorakie polecenia wydawane komputerowi w formie skryptów. Czemu by więc z tego nie skorzystać? Jeśli od klikania bez możliwości pomyłki boli Was ręka, zainwestuj w podkładkę pod mysz… ale przede wszystkim wpadnij na prelekcję Piotra, na której to opowie o założeniach podejścia IaC, jego zaletach oraz przedstawi najpopularniejsze narzędzia.

1. "Dziesięć serwerów poproszę!", czyli co może Ci
zaoferować definiowanie infrastruktury jako kodu (IaC)

2. whoami
Piotr Górni
DevOps Engineer
piotr.gorni@tsh.io

3. Skąd się wzięło Infrastructure as Code?
czyli słowo wstępu o “unicorn serverach”

4. Geneza IaC - przykładowa infrastruktura
web1 “Unicorn” web2 “Banshee” db1 “Sinanju”
user: root
logi: /var/log/my_app/app.log
mount: /media/storage1
OS: Debian 7.0 (SysVinit)
cron: nie
user: cruz
logi: /my_app/app.log
mount: /mnt/storage
OS: CentOS 7 (systemd)
cron: tak
db: MSSQL
OS: MS Server 2016
2013 2014
“unicorn/snowflake servers”
“configuration drift”

5. Geneza IaC - przykładowa obsługa
?
?
?
● w jednym przypadku
aplikacja uruchamiana jest
jako user z
ograniczeniami, w drugim
jako root (źle); logi
aplikacji są niedostępne
dla non-root
● logi są zapisywane w
dwóch różnych miejscach
● mounty są pod innymi
ścieżkami
● na jednym z serwerów jest
cron
● występują dwa różne init
systemy (systemd vs
SysVinit)
● baza w ogóle jest na MS
Server

6. Geneza IaC - “moodboard” problemów
Brak trasowalności zmian
Brak możliwości szybkiego odtworzenia infrastruktury w razie
wypadku
Brak wersjonowania i
rollbacku
Spalone nie tylko serwery
Możliwość pomyłki przy repetycji
Zespół cieśni
nadgarstka...
Ciężkie do osiągnięcia
skalowanie poziome

7. Jak działa Infrastructure as Code?
podstawowe koncepty i mechanizmy działania

8. Infrastructure as Code - rozróżnienie pojęć
configuration orchestration configuration management
apt
install
nodejs
(...)
5k
servers
pls

9. IaC - configuration management - pull vs push
model “pull”
client-server
model “push”
agentless
server
“master”
node1
(running the agent)
node2
(running the agent)
node1
(no agent!)
node2
(no agent!)
+ szybkość dystrybucji
przy dużej skali
- wymaga utrzymywania mastera
- generuje single point of failure
- wdrożenie nowej konfiguracji co t (s,
min, ...)
+
szybkość
dystrybucji
przy
dużej
skali
-
wymaga
utrzymywania
mastera
-
generuje
single
point
of
failure
-
wdrożenie
nowej
konfiguracji
co
t
(s,
min,
...)

10. IaC - configuration management - state
local
remote
changes
terraform.tfstate
state backend
changes
terraform.tfstate
sync state
teraz mogę
dodać zasoby

11. Przegląd narzędzi
dla każdego coś się znajdzie

12. IaC - configuration orchestration
HashiCorp Terraform (2014)
AWS CloudFormation (2011)
Azure Resource Manager (2014)
Google Cloud Deployment Manager (2015?)
Pulumi (2018)
cloud agnostic
“cloud native”/cloud specific

13. IaC - configuration orchestration - Terraform
+ open source
+ “dojrzały”, industry standard; ma wsparcie dla setek dostawców usług cloudowych
+ bardzo rozszerzalny; można pisać własne moduły
+ możliwy import istniejącej infrastruktury
- stosunkowo wysoki próg wejścia
- konieczność nauki specjalnego DSL (HCL, tj. HashiCorp
Configuration Language)
- brak automatycznego rollbacku w przypadku dokonania
złych zmian
● pierwsza wersja: 2014
● język: Go
● język plików konfiguracyjnych: HCL

14. IaC - configuration orchestration - Terraform
provider "aws" {
alias = "us_east_1"
region = "us-east-1"
}
module "my_site" {
# Available inputs: https://github.com/futurice/terraform-utils/tree/master/aws_static_site#inputs
# Check for updates: https://github.com/futurice/terraform-utils/compare/v11.0...master
source = "git::ssh://git@github.com/futurice/terraform-utils.git//aws_static_site?ref=v11.0"
site_domain = "hello.example.com"
}
resource "aws_s3_bucket_object" "my_index" {
bucket = "${module.my_site.bucket_name}"
key = "index.html"
content = "<pre>Hello World!</pre>"
content_type = "text/html; charset=utf-8"
}
output "bucket_name" {
description = "The name of the S3 bucket that's used for hosting the content"
value = "${module.my_site.bucket_name}"
}
Źródło kodu: https://github.com/futurice/terraform-examples/tree/master/aws/aws_static_site

15. - brak automatycznego rollbacku w przypadku dokonania
złych zmian (wprowadzenie jest rozważane)
- narzędzie młodsze niż Terraform, dokumentacja jest
miejscami niekompletna
IaC - configuration orchestration - Pulumi
+ open source
+ mocny contender - członek CNCF
+ backend do przechowywania stanu (Pulumi Service) za darmo na start
+ potrafi załadować moduły Terraforma, co daje mu duże wsparcie dostawców
usług cloudowych poza tymi, które są tworzone dla niego natywnie
+ możliwy import istniejącej infrastruktury
+ nie wymaga nauki specjalnego języka/DSL, można pisać w ulubionym języku
+ wspiera więcej operacji na klastrach Kubernetesa
● pierwsza wersja: 2018
● język: głównie Go
● język plików konfiguracyjnych: Python,
TypeScript, JavaScript, Go, C#, F#

16. IaC - configuration orchestration - Pulumi
Źródło kodu: https://www.pulumi.com/docs/tutorials/aws/s3-website/

17. - vendor locking
IaC - configuration orchestration - cloud specific/native
+ najlepiej “rozumieją” cloudy z których pochodzą
+ bardzo szybko dostają update’y odpowiadające najnowszym resource’om
dostępnym na danych cloudach
AWS CloudFormation (2011)
Azure Resource Manager (2014)
Google Cloud Deployment Manager (2015?)

18. IaC - configuration management

19. IaC - configuration management - bezagentowość
agentlessness (bezagentowość)

20. IaC - configuration management - CFEngine
Fakty:
● pierwsza wersja: 1993
● obecny właściciel: Northern.tech
● języki: C
● język plików konfiguracyjnych: DSL
● mechanizm działania: client-server
PoC

21. IaC - configuration management - Nix/NixOS
Fakty:
● pierwsza wersja: 2003
● obecny właściciel: NixOS, open-source
● języki: Nix expression language
● język plików konfiguracyjnych: Nix expression language
● mechanizm działania: declarative package manager
OS na bazie CI?
Hold my beer.

22. IaC - configuration management - NixOS
Źródło kodu: https://en.wikipedia.org/wiki/NixOS
{
boot.loader.grub.device = "/dev/sda";
fileSystems."/".device = "/dev/sda1";
services.sshd.enable = true;
}

23. IaC - configuration management - Puppet
Fakty:
● pierwsza wersja: 2005
● obecny właściciel: Canonical Ltd.
● języki: Ruby, C++, Clojure
● język plików konfiguracyjnych: Puppet language, Ruby-based
DSL
● nazwy plików konfiguracyjnych: Puppet manifests
● repozytorium plików konfiguracyjnych: Puppet Forge
● mechanizm działania: client-server
Puppetmancing

24. - wymaga znajomości Ruby’ego do bardziej zaawansowanych zastosowań
- wymaga nauki DSL
- lepszy dla ludzi z backgroundem programistycznym
IaC - configuration management - Puppet
+ stoi za nim znacząca firma
+ dość mocna baza użytkowników, dokumentacja i wsparcie
+ dość mocno rozszerzalny
+ dojrzały, długo na rynku

25. IaC - configuration management - Puppet
Źródło kodu: https://www.digitalocean.com/community/tutorials/getting-started-with-puppet-code-manifests-and-modules
# execute 'apt-get update'
exec { 'apt-update': # exec resource named 'apt-update'
command => '/usr/bin/apt-get update' # command this resource will run
}
# install apache2 package
package { 'apache2':
require => Exec['apt-update'], # require 'apt-update' before installing
ensure => installed,
}
# ensure apache2 service is running
service { 'apache2':
ensure => running,
}

26. IaC - configuration management - Chef
Fakty:
● pierwsza wersja: 2009
● obecny właściciel: Progress
● język: Ruby, Erlang
● język plików konfiguracyjnych: DSL oparty na Ruby
● nazwa plików konfiguracyjnych: recipes
● repozytorium plików konfiguracyjnych: Chef Supermarket
● mechanizm działania: it’s complicated
Chef’s kiss… except not

27. - serwer to zawiły kłębek ElasticSearcha, Erlanga, Ruby’ego…
- bardzo konfundujące sposoby uruchamiania
- dziwne zmiany licencyjne w 2019 i 2020
- używanie funkcji dry-run (nazywanej why-run) jest oficjalnie odradzane przez twórców
narzędzia
- konieczność wgłębienia się choć minimalnie w Ruby
- najbardziej dreaded narzędzie w ankiecie Developer Survey Stack Overflow 2019-2021
- starsze wersje nie są 100% open source
- wymaga nauki DSL
- edytowanie JSONów “z palca”
IaC - configuration management - Chef
+ na rynku od dawna
+ można sporo osiągnąć pisząc zaawansowany kod w Ruby/Ruby-based DSL

28. IaC - configuration management - Chef
Źródło kodu: https://www.digitalocean.com/community/tutorials/configuration-management-101-writing-chef-recipes
execute "apt-get update" do
command "apt-get update"
end
apt_package "apache2" do
action :install
end
service "apache2" do
action [ :enable, :start ]
end
directory node['main']['doc_root'] do
owner 'www-data'
group 'www-data'
mode '0644'
action :create
end
cookbook_file "#{node['main']['doc_root']}/index.html" do
source 'index.html'
owner 'www-data'
group 'www-data'
action :create
end

29. IaC - configuration management - Juju
Fakty:
● pierwsza wersja: 2010
● obecny właściciel: Canonical Ltd.
● język: Python, Go
● język plików konfiguracyjnych: YAML + dowolny język
wykonywalny z CLI
● nazwy plików konfiguracyjnych: charms, bundles
● repozytorium plików konfiguracyjnych: Juju Charm Store
● mechanizm działania: client-server
Kolejny wytwór Canonicala...

30. - niewiele ludzi go używa
- snap od Canonicala też nie jest powszechnie używany
- Canonical ma też Puppeta, czemu po prostu nie używać Puppeta
- wysoki próg wejścia
- dokumentacja pozostawia trochę do życzenia
- nie działa na każdej dystrybucji Linuksa
IaC - configuration management - Juju
+ stoi za nim znacząca firma

31. IaC - configuration management - Juju
Źródło kodu: https://discourse.charmhub.io/t/writing-your-first-juju-charm/1046
name: vanilla
summary: Vanilla is an open-source, pluggable, themeable, multi-lingual forum.
maintainer: Your Name <your@email.tld>
description: |
Vanilla is designed to deploy and grow small communities to scale.
This charm deploys Vanilla Forums as outlined by the Vanilla Forums installation guide.
tags:
- social
provides:
website:
interface: http
requires:
database:
interface: mysql
#!/bin/bash
set -e # If any command fails, stop execution of the hook with that error
apt-get install -y apache2 php5-cgi php5-mysql curl php5-gd wget libapache2-mod-php5
dl="https://github.com/vanillaforums/Garden/archive/Vanilla_2.0.18.8.tar.gz"
# Grab Vanilla from upstream.
status-set maintenance "Fetching and installing Vanilla"
wget "$dl" -O /tmp/vanilla.tar.gz
# IDEMPOTENCY is very important in all charm hooks, even the install hook.
if [ -f /var/www/vanilla/conf/config.php ]; then
cp /var/www/vanilla/conf/config.php /tmp/
rm -rf /var/www/vanilla
fi
(...)
charm
hook

32. IaC - configuration management - Salt (SaltStack)
Fakty:
● pierwsza wersja: 2011
● obecny właściciel: VMWare, Inc.
● języki: Python
● język plików konfiguracyjnych: language-agnostic
● nazwy plików konfiguracyjnych: state modules, (…)
● mechanizm działania: both client-server and agentless
Salty?

33. - stosunkowo młody
- nie mogę znaleźć repozytorium plików konfiguracyjnych
IaC - configuration management - Salt (SaltStack)
+ tryb agentless istnieje
+ oparty na kolejce ZeroMQ - szybszy niż konkurencja
+ wspiera zdalne wykonywanie kodu - node’y nie muszą czekać na pobranie
konfiguracji
+ oficjalne tutoriale wydają się być dość sensowne

34. IaC - configuration management - SaltStack
Źródło kodu: https://docs.saltproject.io/en/latest/topics/tutorials/walkthrough.html#the-first-sls-formula
nginx:
pkg.installed: []
service.running:
- require:
- pkg: nginx

35. IaC - configuration management - Ansible
Fakty:
● pierwsza wersja: 2012
● obecny właściciel: RedHat
● język: Python
● język plików konfiguracyjnych: YAML
● nazwa plików konfiguracyjnych: playbooki
● repozytorium plików konfiguracyjnych: Ansible Galaxy
● mechanizm działania: agentless SSH
KISS!

36. - czasem trzeba się natrudzić, by napisać pewne rzeczy w YAMLu
- mimo wszystko dość młody
- może być wolniejszy niż konkurencja, szczególnie w skali
IaC - configuration management - Ansible
+ z racji prostoty mocny industry standard
+ stoi za nim znacząca firma
+ agentless SSH - prosty i zrozumiały mechanizm działania
+ konfiguracja w YAMLu, który jest to dość czytelny i przyjazny dla developerów
+ spora baza użytkowników

37. IaC - configuration management - Ansible
Źródło kodu: https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html
---
- name: Update web servers
hosts: webservers
remote_user: root
tasks:
- name: Ensure apache is at the latest version
ansible.builtin.yum:
name: httpd
state: latest
- name: Write the apache config file
ansible.builtin.template:
src: /srv/httpd.j2
dest: /etc/httpd.conf

38. Werdykt
co wybrać?

39. Czynniki związane z wyborem narzędzia
- rozmiar zespołu developerskiego
- języki znane przez zespół developerski
- zastosowanie - bardzo specyficzna konfiguracja, czy może tylko instalacja
Dockera?

40. Przyszłość
kryształowa kula