Infrastracture as Code i PowerShell

Uczymy się nowej umiejętności lub narzędzia, nabieramy wprawy i bywa, że widzimy jego wykorzystanie w każdym nowy „wyzwaniu”. Nic w tym dziwnego, z natury lubimy to, co znane.

Takim wyzwaniem może być adaptacja Infrastracture as Code, czyli utrzymanie infrastruktura jako kod. W tym wpisie wyjaśnię czym jest Infrastracture as Code i czy wykorzystanie w tym celu PowerShell to dobry pomysł.

Czym jest Infrastracture as Code?

Jest to koncepcja utrzymywania i dostarczania spójnej, powtarzalne infrastruktury (vm, load balance, sieci, itd.) na podstawie kodu.

Tak jak kod źródłowy aplikacji generuję ten sam plik binarny, Infrastracture as Code (IaC) ma dostarczać takie samo środowisko. Wraz z IaC pojawia się kontrola wersji, testowanie czy automatyczny deployment. Ale również takie pojęcia jak idempotentność czy programowanie deklaratywne.

Idempotentność

Idempotentność cechuję operację, które zwracają ten sam rezultat niezależnie od ilości ich wykonywania. W kontekście Infrastracture as Code, umożliwia to, że poprawne wykonanie tego samego kodu po raz drugi bez efektu ubocznego dla naszej infrastruktury.

Chyba że w wprowadzimy zmiany to, ponownie wykonanie zmieni zasoby tylko w tym wąskim zakresie.

Programowanie deklaratywne

W programowaniu deklaratywnym opisujemy, co chcemy otrzymać na wyjściu, kompletnie nie skupiając się na sposobie realizacji.

Doskonałym przykładem języka deklaratywnego jest SQL, decyzję o sposobie wstawiania, aktualizacji i pobrania danych pozostawiamy systemowi zarządzania bazą danych.

Infrastracture as Code i PowerShell, czy to się uda?

Po pierwsze w PowerShell nie piszemy deklaratywnie a po drugie zapewnienie idempotentności za pomocą PowerShell (nie jest nie możliwe), ale jest bardzo trudne. Aby to osiągnąć, w kodzie należu dbać o logikę i obsługę błędów.

Dlatego PowerShell 💙 Infrastracture as Code

Jak nie PowerShell to co?

Tak na przykład dla Azure narzędziem do Infrastracure as Code będzie Azure Resource Manager (ARM) z plikami JSON, dla Amazon Web Service to CloudFormation (JSON lub YAML).

Oprócz natywnych rozwiązań dostawców chmury, popularnym narzędziem jest Terraform. Umożliwia stosowanie jednej składni (HCL) niezależnie od wykorzystywanej platformy. Ograniczeni jesteśmy tylko providerami dostępnymi w Terraformie, których w sumie jest calkiem sporo.

Terraform vs PowerShell

Na sam koniec porównanie PowerShell i Terraform na przykładzie utworzenia usługi Azure SQL Database.

Mimo prostego przykładu widać przewagę składni HCL, jest krótsza, prostsza i czytelniejsza.

Dodatkowo załóżmy, że chcemy zmienić poziom usługi SQL Database. W przypadku Terraforma zmiana nastąpi tylko w argumencie requested_service_objective_name i ponowne wykonanie pliku tf.

W PowerShell wiązałoby się z dopisanie kolejnych linijek kodu. Dlatego ciężko sobie wyobrazić opisanie całej infrastruktury za pomocą skryptów PS i wprowadzanie zmian w razie potrzeby.

Podsumowanie

Celem wpisu było pokazanie, że wykorzystanie PowerShell do utrzymanie infrastruktury jako kod nie będzie najlepszym pomysłem. Da się, co nie oznacza, że powinno się to robić.

Dla Infrastracture as Code istnieją narzędzia dużo lepsze, chociażby te o, których wspomniałem-ARM, CloudFormation, Terraform.

22 Najważniejsze Wskazówki Pisania Skryptów PowerShell

Mateusz Nadobnik

Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

read more