IaC (Infrastructure as Code) co to jest? I komu to potrzebne?
Po wyszukiwaniu hasła IaC w Google możemy natknąć się na definicję:
Infrastruktura jako kod to proces zarządzania komputerowymi centrami danych i udostępniania ich za pomocą plików definicji do odczytu maszynowego, a nie fizycznej konfiguracji sprzętu lub interaktywnych narzędzi konfiguracyjnych.
Jak na prawdziwą definicję przystało po zapoznaniu się z nią panuje wrażenie, że rozumie się zagadnienie mniej niż przez jej przeczytaniem. A więc co to znaczy w praktyce?
Odnosi się do modelu w którym zamiast „ręcznie” wgrywać konfigurację do serwerów lub usług, stosuje się narzędzia takie jak:
- Ansible,
- Puppet,
- Terraform
dzięki nim możemy w języku (kodzie) specyficznym dla danego rozwiązania opisać naszą konfigurację, następnie uruchomić ją i interpreter wykonuje za nas całą robotę.
Naszym zadaniem jest opisanie docelowej konfiguracji w sposób deklaratywny (określamy efekt końcowy), a narzędzie wykona potrzebne kroki, aby ten stan osiągnąć.
Terraform – poniższy fragment kodu spowoduje stworzenie w Google Cloud (jeśli jeszcze nie istnieją) sieci VPC, oraz maszyny wirtualnej która z tej sieci korzysta.
resource
"google_compute_network" "vpc_network" { name = "terraform-network" } resource "google_compute_instance" "vm_instance" { name = "terraform-instance" machine_type = "e2-micro" tags = ["web", "dev"] boot_disk { initialize_params { image = "cos-cloud/cos-stable" } } network_interface { network = google_compute_network.vpc_network.name access_config { } }
Ansible – poniższy fragment roli uruchomiony na wskazanym hoście spowoduje stworzenie (jeśli nie istnieje) katalogu, oraz przykładowego pliku konfiguracyjnego.
--- - name: Tworzę katalog file: path: /opt/katalog state: directory owner: myuser group: mygroup - name: Przesyłam plik konfiguracyjny w formie templatki Jinja template: src: my-config.ini dest: /etc/my-service/my-config.ini
Ale komu to potrzebne? A dlaczego?
Do głównych zalet IaC możemy zaliczyć:
Automatyzacja, standaryzacja i powtarzalność
Podejście IaC pozwala na elastyczne zarządzanie konfiguracją, przy odpowiednio napisanym kodzie czas konfiguracji 1 instancji usługi, a 100 jest w przybliżeniu identyczny. Dodatkowo zapewniamy 100% standaryzację, oraz wykluczamy drobne błędy takie jak: literówki, pominięcie kroku wdrożenia, które mogą być w późniejszym etapie bardzo trudne do wykrycia.
Kontrola wersji
Nasz kod opisujący infrastrukturę możemy i powinniśmy trzymać w systemie kontroli wersji co pozwala na śledzenie wszystkich zmian jakie zostały wykonany w infrastrukturze, oraz ustalenie kto i w jakim celu takich zmian dokonał. Korzystając z systemu takiego jak git, zyskujemy dodatkowo możliwość weryfikacji wprowadzanych modyfikacji przez innych członków zespołu poprzez wymagany proces recenzji zmian zanim znajdą się w głównej gałęzi repozytorium, skąd dalej zostaną wgrane do środowiska produkcyjnego.
Mniej dostępów, większa kontrola
Najlepszym rozwiązaniem jest uruchamianie narzędzi IaC przy pomocy rozwiązań CI/CD takich jak: Jenkins, czy Gitlab Runner, w takim wypadku osoba wprowadzająca zmiany nie musi mieć bezpośrednich dostępów do naszej infrastruktury, wystarczy, że odpowiednio skonfigurujemy proces CI/CD, a zmiany które pojawią się w głównej gałęzi systemu kontroli wersji zostaną automatycznie wgrane do środowiska.
Mniej dokumentacji
Niewiele jest osób w branży IT, które chętnie tworzą dokumentację, przy zastosowaniu podejścia Infrastructure as Code dokumentacja tworzy się nie jako sama, ponieważ analizując kod opisujący stan infrastruktury możemy dokładnie zrozumieć jak jest zbudowana, oraz w jaki sposób funkcjonuje. Oczywiście takie podejście nie eliminuje w 100% potrzeby tworzenia dokumentacji, ponieważ analiza skomplikowanego kodu IaC może być wymagająca i czasochłonna. Dodatkowo musimy w jakiś sposób opisać jak działa w naszym projekcie IaC i jak z niej korzystać
Zwinna współpraca
Coraz częściej spotykanym modelem, w szczególności w firmach stosujących zwinne podejście do wytwarzania oprogramowania, jest tworzenie gotowego kodu w postaci modułów IaC przez dedykowane zespoły, moduły te są później wykorzystane przez zespoły produktowe, aby samodzielnie np. wdrożyć nowy mikroserwis, polega to jedynie na imporcie odpowiedniego komponentu i podaniu podstawowych informacje takich jak: nazwa aplikacji, czy ilość instancji.