Cursul 03. Terraform si Ansible

Pentru cea mai recenta versiune a acestui document intrati aici Terraform si Ansible

Disclaimer

Informatiile de mai jos expun o mica parte a capabilitatilor uneltelor prezentate precum si unul dintre numeroasele contexte si scenarii in care pot fi folosite acestea.

Nu presupuneti ca o problema similara trebuie rezolvata in modul expus aici sau ca aceasta e abordarea corecta; scopul acestui document este de a expune

o mica parte din ce pot face aceste unelte
un scenariu pur teoretic, cu putina aplicabilitate practica

astfel incat sa va formati o opinie despre conceptele de baza din jurul lor.

IaC - Infrastructure as Code

Conceptul se refera la acea categorie de unelte care ne ajuta sa mentinem resursele dintr-un mediu de lucru sub forma de text.

Resursele ce pot fi administrate fac parte dintr-o plaja foarte larga de tehnologii si pot contine:

resurse IaaS:: Infrastructure as a Service
- masini virtuale
- instante dedicate de baze de date: Database as a Service e.g., AWS RDS i.e., Relational Database Service
- volume: discuri i.e., block devices
- routere virtuale: AWS VPC i.e., Virtual Private Cloud, MS Azure Virtual Network
- subneturi
- …
resurse SaaS:: Software as a Service
- Instante i.e., scheme de baze de date
- Utilizatori in respectivele baze de date
- Clustere Kubernetes
- Load Balancere L3/L7
- …
resurse arbitrare
- Proiecte, grupuri, etc in platforme precum GitLab
- record-uri in DNS
- containere intr-un host Docker
- …

Informatii suplimentare despre subiect gasiti pe Wikipedia.

IaC vs click-click

Cream mai jos o masina virtuala intr-o instanta OpenStack folosind providerul OpenStack pentru Terraform:

resource "openstack_compute_instance_v2" "instance" {
  name        = "vm-de-test"
  image_id    = "ubuntu-bionic"
  flavor_name = "m1.small"
  key_pair    = "ssh-rsa a@b"

  network {
    name = "summer-school-net"
  }
}

Spre deosebire de cateva operatiuni manuale:

Operatiuni manuale pentru replicarea declaratiei de mai sus

Alte unelte folosite in acest sens

Ansible
Puppet
SaltStack
Vedeti linkul catre IaC de mai sus pentru mai multe detalii

Terraform

Terraform este o unealta IaC ce foloseste modelul declarativ. Conceptele de baza sunt decrise mai jos.

Modulul ROOT

In diferite locuri i.e., locuri de munca, proiecte, etc, li se mai spune si planuri; oricare ar fi numele utilizat, se refera la radacina directorului in care adaugam fisiere text cu extensia .tf in care declaram resursele pe care dorim sa le administram; sunt citite de Terraform si pe baza lor opereaza acesta potentiale modificari.

Radacina unor planuri se mai numeste si modul ROOT.

$ tree summer-school/
summer-school/      # Radacina planurilor i.e., modulul ROOT
├── main.tf         # Nume arbitrar pentru fisier text in care declaram resurse
├── provider.tf     # Nume arbitrar pentru fisier text in care declaram providerul folosit
├── terraform.state # State terraform tinut local
└── README.adoc     # Documentatie privind scopul directorului/planurilor

Alte module

Modulele pot incapsula tot felul de functionalitati e.g.:

creare de masini virtuale cu volume atasate
creare de masini virtuale cu numar dinamic de interfete de retea si intrari in DNS
SaaS: Clustere Consul in AWS, Cluster Kubernetes in Azure etc

Mai multe despre ele puteti citi in documentatia oficiala.

Provider

Terraform foloseste conceptul de provider pentru a interactiona cu diversi furnizori de servicii si/sau infrastructura:

provideri cloud
instante baze de date
routere

Oricare dintre resursele declarate in Modulul ROOT sau in alte module vor fi legate de providerul folosit. Spre exemplu, o resursa de tip masina virtuala pentru OpenStack nu poate fi folosita in Amazon AWS; fiecare provider are specificul lui si serviciile proprii, macar usor diferite de ale celorlalti provideri.

Poti folosi unul sau mai multi provideri pentru a administra resursele dorite
Poti folosi acelasi provider de mai multe ori pentru scenarii aparte

State

Terraform tine starea^[1] reala a resurselor intr-un fisier oarecum JSON, in care inregistreaza pe care dintre resursele declarate in planuri a reusit sa le creeze provider-ul, precum si metadatele asociate.

State-ul poate fi stocat pe masina de pe care rulam Terraform sau poate fi stocat intr-unul din backend-urile remote suportate e.g.:

consul
azurerm
etcd

Structura fisier state Terraform

{
    "version": 3,
    "serial": 1,
    "lineage": "6bae2eff-3a14-945e-035c-9796accc5887",
    "backend": {
        "type": "swift",
        "config": {
            "allow_reauth": null,
            "application_credential_id": null,

...
}

Ansible?

Da, si Ansible poate fi folosit pentru IaC:

- name:  Creeaza o instanta
  openstack.cloud.server:
    state: present
    auth:
      auth_url: https://endpoint.iam.instanta.openstack.lan
      username: admin
      password: admin
      project_name: summer-school
    name: vm-de-test
    image: ubuntu-bionic
    key_name: "ssh-rsa a@b"
    timeout: 200
    flavor: "m1.small"
    network: "summer-school-net"

Vrei sa folosesti Ansible pentru IaC? Poate; eu nu.

Poate daca:

Proiectul pe care lucrezi a investit masiv in asta
Cei implicati stiu doar Ansible

Altfel, as spune ca:

Modelul implicit Ansible este de a se conecta la sisteme remote; aici modulele s-ar executa pe hostul de pe care rulam Ansible → inventarul ar putea arata cam ciudat
Nu exista un raspuns corect; nu il cautati

Software provision, Configuration management, App deployment

Cu toate ca linia de demarcatie e difuza, spre deosebire de IaC, in zona de configuration management, app deployment etc, atentia e indreptata asupra altor aspecte, precum:

serviciile
pachetele
utilizatorii
deployment-ului de aplicatii custom

de pe un sistem dat. Altfel spus, mai putin asupra resurselor de infrastructura si mai mult asupra serviciilor si ecosistemului serviciilor respective.

Configuration management vs click-clack

Scenariu

Vrem sa:

cream trei utilizatori, toti parte a grupului primar admini:
- asterix
- obelix
- idefix
instalam patru pachete:
- lynx
- tmux
- vsftpd
- gcc
configuram un banner specific la login:

Va rugam politicos sa nu folositi acest sistem daca nu aveti dreptul sa o faceti.  Multumim!

--- Panoramix si echipa

pe o distributie Debian 10 si pe o distributie CentOS 7. Mai intai aratam cum se face 'de mana' dupa documentatie si-apoi vedem cum se poate face folosind o unealta de configuration management.

Click-clack

Cream utilizatorii pe ambele sisteme folosind aceleasi comenzi

sudo groupadd admini
sudo useradd asterix --gid admini
sudo passwd asterix # adaugam o parola pentru userul asterix
sudo useradd obelix --gid admini
sudo useradd idefix --gid admini

Pe Debian instalam pachetele cu

sudo apt-get update
sudo apt-get install lynx tmux vsftpd gcc

Pe CentOS instalam pachetele cu:

sudo yum install lynx tmux vsftpd gcc

Aplicam bannerul ce trebuie afisat la login

cat <<EOF > /workspace/student/motd
Va rugam politicos sa nu folositi acest sistem daca nu aveti dreptul sa o faceti.  Multumim!

--- Panoramix si echipa
EOF
sudo mv /workspace/student/motd /etc/motd

Configuration management

playbook.yml

---
- hosts: "{{ _hosts | default('all') }}"   # executam asupra tuturor sistemelor despre care stim
  become_user: root                        # ne conectam ca si utilizatorul root
  vars:
    utilizatori:
      - user: asterix # Parola este: asterix
        parola: "$6$U9D8CKVFasZBXtfE$jElu7BDrU7bykn2LudE1moTKea3ffK5Tad0P9x2T/U5y0rGm8Q4qcbm/VivSvRy0Yk3b29V0rX3J.KH0UFMEP/"
      - user: obelix
      - user: idefix
    pachete:   # definim o variabila de tip lista pentru stocarea numelor pachetelor
      - lynx
      - tmux
      - vsftpd
      - gcc
    motd: |
      Va rugam politicos sa nu folositi acest sistem daca nu aveti dreptul sa o faceti.  Multumim!

      --- Panoramix si echipa
  tasks:       # executam pasii pe care ni-i dorim
    - name: Instalam grupul
      group:
        name: "admini"

    - name: Instalam utilizatorii
      user:
        name: "{{ item.user }}"
        group: "admini"
        password: "{{ item.parola | default(omit) }}"
        state: present
      loop: "{{ utilizatori }}" # executam modulul `user` pentru fiecare utilizator

    - name: Instalam pachetele
      package:
        name: "{{ pachete }}"
        state: present

    - name: Aplicam bannerul
      copy:
        content: "{{ motd }}"
        dest: "/etc/motd"
        owner: root
        group: root
        mode: "0644"

Terraform?

Cum ar veni, putem folosi Terraform in scopul asta? Nu.

Alte solutii?

Destule, nu toate se muleaza 1:1 pe situatia de mai sus.

Ansible

Inventar

Unul sau mai multe fisiere statice, dinamice, sau combinatie intre aceste variante prin care definim sistemele pe care dorim sa le administram.

Pentru constructia inventarului, ansible se foloseste de plugin-uri; acestea pot citi hosturi din fisiere in formate precum .ini sau .yaml, sau pot executa scripturi care la randul lor culeg informatii despre hosturile pe care dorim sa le administram.

Doua hosturi parte din grupul all, unul parte din grupul debian, intr-un inventar static in format .ini

[all]
sistem1.lan
sistem2.lan

[debian]
sistem3.lan

Note	`sistem3.lan` face parte si din grupul `all`; toate hosturile fac parte implicit si din grupul `all`.

Proprietati specifice grupului sau hostului in sine pot fi declarate in directoarele host_vars sau group_vars:

$ tree inventar
.
├── group_vars
│   ├── all.yml
│   └── debian.yml
├── host_vars
│   └── sistem1.lan.yml
└── inventar.yml

Playbook

Playbook-ul defineste o succesiune de taskuri^[2], precum si hosturile asupra carora se va executa acea succesiune de taskuri; un exemplu de task ar putea fi chemarea unui modul ansible specializat pe un grup de actiuni e.g., modulul user, care administreaza aspecte legate de utilizatorii prezenti pe un sistem Linux/Unix:

username
parola
home directory
shell folosit
…

Documentatie

Terraform
Ansible
- Documentatie oficiala Ansible
- Concepte de baza
- site:https://jpmens.net ansible in motorul vostru de cautare favorit

1. Reala, relativ la ultima data cand a rulat :^) Daca cineva modifica resurse in afara Terraform vor aparea potentiale situatii ciudate

2. Indiferent ca taskurile reprezinta executia unui modul, chemarea unui rol, definirea unui handler etc

Cursuri

Coming soon…

Laboratoare

Coming soon…

Resurse

Coming soon…

devops/cursuri/03.txt · Last modified: 2021/07/28 16:28 by bogdan.croitoru

Old revisions

Media Manager Back to top