• Tomasz Żok
• Home
• Publications
• Conferences
• Projects

Infrastruktura jako kod

• Złożone projekty składają się z licznych bibliotek i zależności
• Im więcej osób w zespole i im dłużej trwa proces tworzenia oprogramowania, tym środowisko projektowe robi się coraz bardziej wrażliwe na zmiany
• Ma to kilka negatywnych konsekwencji:
  • Używane są stare wersje bibliotek, bo ich aktualizacja za bardzo ingeruje środowisko
  • Występuje syndrom “u mnie działa” tzn. osoby włączające się w pracę na późniejszym etapie mają już inne środowisko niż pozostali
• Jednym ze sposobów przeciwdziałania temu jest podejście infrastruktura jako kod (infrastructure as code)
• W podejściu tym wymagane środowisko opisane jest w sposób formalny, a opis ten jest współdzielony w zespole
• Osobne oprogramowanie zapewnia, że środowisko spełniające wymagania powstanie np. w formie maszyny wirtualnej
• Opis środowiska najczęściej definiowany jest jako deklaratywny kod i podlega kontroli wersji na równych zasadach jak główny kod projektu (różne gałęzie, tagi, wersjonowanie, itp.)

Vagrant

• Vagrant to narzędzie do budowania maszyn wirtualnych i zarządzania nimi
• Definicja w Vagrantfile jest czytelna i można nią zarządzać tak jak głównym kodem projektu
• Raz przygotowany Vagrantfile gwarantuje, że użytkownicy różnych systemów operacyjnych zbudują takie samo środowisko
• Definicje w Vagrantfile można wykorzystać zarówno do szybkiego stworzenia lokalnych instancji do testów, jak i do tworzenia instancji u różnych dostawców w chmurze

Podstawy

• Zainstaluj Vagrant i VirtualBox

• Wykonaj:

  $ vagrant init archlinux/archlinux

• Zapoznaj się z wygenerowanym plikiem Vagrantfile

• Wykonaj:

  $ vagrant up

• Kiedy zbuduje się maszyna wirtualna, podłącz się do niej przez SSH i sprawdź nazwę dystrybucji:

  $ vagrant ssh
  [vagrant@archlinux] $ cat /etc/os-release

• Domyślnie w maszynie wirtualnej pod ścieżką /vagrant znajdziesz podmontowany lokalny katalog:

  [vagrant@archlinux] $ ls /vagrant
  [vagrant@archlinux] $ date > /vagrant/test.txt
  [vagrant@archlinux] $ logout
  $ cat test.txt

• W Vagrantfile można skonfigurować również podmontowanie innych ścieżek albo kopiować pliki bezpośrednio:

  $ vagrant upload /path/to/local/file /path/in/virtual/machine

• Wirtualną maszynę można zniszczyć komendą:

  $ vagrant destroy

• Listę dostępnych obrazów można znaleźć tutaj: https://app.vagrantup.com/boxes/search

Provisioning

• Po stworzeniu maszyny wirtualnej można połączyć się przez SSH i przygotować całe środowisko ręcznie (np. zainstalować Apache)

• Jednak takie podejście jest nieskalowalne, podatne na błędy i niezgodne z ideą infrastruktury jako kodu

• Vagrant umożliwia tzw. provisioning, czyli przygotowanie środowiska zgodnie z wymaganiami użytkownika

• Najbardziej podstawowy mechanizm provisioning to uruchomienie zadanego skryptu powłoki

• Przygotuj skrypt o nazwie provision.sh:

  #! /bin/sh
  sudo pacman -Sy --noconfirm apache
  sudo systemctl enable --now httpd
  echo '<h1>Hello World from Vagrant!</h1>' > /srv/http/index.html

• Uwaga! Skrypt będzie uruchomiony w sposób nieinteraktywny, więc musisz dodać przełączniki -y (do apt-get w Debian/Ubuntu) lub --noconfirm (do pacman w Arch), itp.

• Dodaj do Vagrantfile linie:

  config.vm.provision :shell, :path => "provision.sh"
  config.vm.network :forwarded_port, :guest => 80, :host => 8080, :host_ip => "127.0.0.1"

• Jeżeli zniszczyłeś maszynę przy pomocy vagrant destroy, to jej nowe utworzenie zastosuje wprowadzone zmiany

• Jeżeli natomiast maszyna wirtualna jeszcze istnieje, to można wymusić zastosowanie reguł provision przy pomocy:

  $ vagrant provision

  Lub:

  $ vagrant reload --provision

  (w tym przypadku skorzystaj vagrant reload --provision, bo linia config.vm.network ... wymaga restartu maszyny)

• Sprawdź czy działa przekierowanie portów:

  $ vagrant port

• Sprawdź wynik w przeglądarce http://localhost:8080

• Domyślnie skrypt wykona się tylko podczas tworzenia maszyny wirtualnej lub podczas uruchomienia procesu bezpośrednio przez vagrant reload --provision lub vagrant provision

• Aby to zmienić, można w Vagrantfile przy config.vm.provision dodać opcję run: "always"

• W pliku Vagrantfile może znajdować się wiele wpisów config.vm.provision - kolejność ich uruchamiania będzie odpowiadać kolejności występowania w pliku

Mechanizm file

• Oprócz typu shell Vagrant wspiera wiele innych mechanizmów provisioningu
• Przydatny może być file z parametrami source i destination, który pozwala kopiować pliki lub katalogi
• W przeciwieństwie do współdzielonych katalogów, file tworzy niezależne kopie plików
• Mechanizm file działa na prawach zwykłego użytkownika (np. vagrant), więc jeśli chcemy umieścić plik w lokalizacji systemowej potrzebne będzie połączenie mechanizmu file z shell aby przenieść i zmienić prawa dostępu do plików

Mechanizm ansible

• Ansible to kompleksowe rozwiązanie do automatycznej konfiguracji i zarządzania maszynami wirtualnymi (lokalnie lub w chmurze)

• Ansible opiera się na deklaratywnym opisie pożądanego stanu systemu

• Wykorzystywany w tym celu jest zwięzły format YAML

• Sposób działania:

  • Wykorzystywane są bezhasłowe (passwordless) połączenia SSH
  • Gospodarz (host) na podstawie opisu w formacie YAML przesyła krótkie moduły (de facto programy w Pythonie)
  • Każdy moduł ma za zadanie sprawdzić czy system jest w pożądanym stanie oraz wprowadzić modyfikacje jeśli nie jest

• Jest to bardzo ogólny schemat działania:

  • Jedyne wymagania to możliwość połączenia po SSH i zainstalowany Python na maszynie docelowej
  • Gospodarz i zarządzany system mogą być tą samą maszyną podczas testów

• Przykładowo, pożądanym stanem może być:

  istnieje plik /tmp/file
  plik /tmp/file ma zawartość: Hello World from Ansible!
  plik /tmp/file ma prawa dostępu 0644

• Albo:

  w systemie zainstalowany jest apache2
  usługa httpd jest uruchomiona

• Deklaratywny charakter sprawia, że reguły Ansible można stosować wielokrotnie

• Kolejne uruchomienia sprawdzą czy pożądany stan zachodzi i mogą zakończyć się sukcesem bez wykonywania żadnej operacji

• Większość modułów Ansible ma tę cechę, ale nie wszystkie

• Przykładowo moduł script ma parametry creates i removes, które określają, że określony plik ma istnieć lub nie. Można jednak użyć modułu script by bezwarunkowo wykonać skrypt

• Vagrant pozwala uruchamiać Ansible na dwa sposoby:

  • W systemie operacyjnym, który jest gospodarzem dla wirtualnej maszyny: type: "ansible"
  • Na wirtualnej maszynie, która konfigurować będzie siebie jako localhost: type: "ansible_local"

• Jeżeli w swoim głównym systemie operacyjnym możesz zainstalować Ansible, zalecany jest pierwszy sposób

• Plik zawierający konfigurację Ansible nazywa się playbook

• playbook składa się z listy zadań, które uruchamiane są kolejno od góry do dołu

• Każde zadanie może mieć pole name: ... służące do dokumentacji

• Każde zadanie określa również moduł oraz jego konfigurację

Ćwiczenie

• Stwórz plik playbook.yml:

  - hosts: all
    become: yes
  
    tasks:
    - name: apache is installed
      community.general.pacman:
        name: apache
        state: present
        update_cache: yes
  
    - name: httpd service is enabled
      ansible.builtin.service:
        name: httpd
        state: started
  
    - name: hello world content is ready
      ansible.builtin.lineinfile:
        path: /srv/http/index.html
        create: yes
        line: <h1>Hello World from Vagrant with Ansible!</h1>

• W Ansible możemy grupować zarządzane maszyny i definiować zadania na poziomie grup, ale w przypadku pracy z Vagrant, wystarczy hosts: all

• Vagrant uruchamia Ansible provisioning na poziomie zwykłego użytkownika, więc musimy wskazać, że potrzebna jest eskalacja uprawnień poprzez become: yes (można to ustawić na poziomie pliku Vagrantfile lub na poziomie każdego z zadań z osobna)

• Wykorzystane zostały tutaj trzy moduły:

  • community.general.pacman
  • ansible.builtin.service
  • ansible.builtin.lineinfile

• Zmień konfigurację Vagrantfile:

  -  config.vm.provision :shell, :path => "provision.sh"
  +  config.vm.provision :ansible, :playbook => "playbook.yml"

• Usuń wirtualną maszynę (vagrant destroy) i stwórz nową od początku(vagrant up)

• Sprawdź wynik w przeglądarce http://localhost:8080

• Możesz ponownie uruchamiać vagrant provision i zauważyć, ze zadania Ansible będą w stanie ok zamiast changed

Konfiguracja projektu z wieloma maszynami

• W Vagrantfile można umieścić konfigurację więcej niż jednej maszyny wykorzystując config.vm.define np. tak:

  config.vm.define "web" do |web|
    web.vm.box = "..."
  end
  
  config.vm.define "db" do |db|
    db.vm.box = "..."
  end

• W przykładzie powyżej, wewnątrz bloku można umieścić dokładnie takie same konfiguracje jak wcześniej np. dotyczące otwartych portów czy provisioningu

• Jeżeli mechanizm ten jest wykorzystywany, komendy vagrant zmieniają nieznacznie działanie:

  • vagrant up zbuduje i uruchomi wszystkie maszyny
  • vagrant ssh wymaga dodatkowego parametru będącego nazwą maszyny

• W przypadku takiej konfiguracji, dla zachowania bezpieczeństwa warto umieścić wirtualne maszyny w lokalnej sieci prywatnej i przekierowywać tylko wybrane porty do maszyny gospodarza

• Najczęściej przypisuje się maszynom statyczne adresy IP i w ramach provisioningu konfiguruje się mapowanie w pliku hosts, np.:

  node1.vm.network :private_network, :ip => '192.168.20.21'
  node1.vm.provision :shell, :inline => <<-SHELL
    sed -i '$ a 192.168.20.21 node1' /etc/hosts
    sed -i '$ a 192.168.20.22 node2' /etc/hosts
  SHELL

  (analogicznie dla node2)

Zadanie

• Zrealizuj jeden z poniższych projektów

Ocena 3.0

• Przygotuj wirtualną maszynę, która będzie zawierała wszystkie komponenty Twojego projektu

Ocena 4.0

• Jak wyżej, ale z użyciem Vagrant i mechanizmu shell do provisioningu

Ocena 4.5

• Jak wyżej, ale z użyciem mechanizmu ansible do provisioningu

Ocena 5.0

• Przygotuj konfigurację Vagrant dla trzech maszyn (db, backend, frontend). Jedynie frontend powinien przekierować port, a reszta komunikacji powinna odbywać się w ramach sieci prywatnej. Zawartość każdej z maszyn powinna powstać przy pomocy Ansible