Infrastructure as Code: koniec z klikaniem w konsoli
Wyobraź sobie, że budujesz środowisko produkcyjne klikając w konsoli AWS. VPC, subnety, security groups, EC2, RDS, Load Balancer... Godziny pracy. A teraz musisz zbudować identyczne środowisko staging. I development. I disaster recovery w innym regionie. Klikasz znowu? Pomyłka na jednym kroku i masz różnice między środowiskami, których nawet nie zauważysz.
Infrastructure as Code (IaC) to podejście, w którym definiujesz infrastrukturę w plikach tekstowych (szablonach), a narzędzie automatycznie tworzy, modyfikuje i usuwa zasoby AWS na ich podstawie.
Dlaczego IaC?
- Powtarzalność - ten sam szablon tworzy identyczne środowisko za każdym razem
- Wersjonowanie - szablon to plik tekstowy, można go trzymać w Git
- Automatyzacja - nie ma ręcznych kroków, nie ma pomyłek
- Dokumentacja - szablon JEST dokumentacją infrastruktury
- Łatwość usuwania - usuwasz stack = usuwasz wszystkie zasoby
AWS CloudFormation
CloudFormation to natywna usługa IaC w AWS. Opisujesz infrastrukturę w szablonie (template), a CloudFormation tworzy i zarządza zasobami jako stack.
Template (szablon)
Szablon CloudFormation to plik JSON lub YAML, który opisuje jakie zasoby AWS chcesz utworzyć. Kluczowe sekcje szablonu:
- Parameters - wartości wejściowe (np. typ instancji EC2, nazwa środowiska)
- Resources - zasoby do utworzenia (jedyna wymagana sekcja!)
- Outputs - wartości wyjściowe (np. adres Load Balancera)
- Mappings - statyczne mapowania (np. AMI ID per region)
- Conditions - logika warunkowa (np. „utwórz to tylko w produkcji")
Stack
Stack to jednostka wdrożenia w CloudFormation. Kiedy wdrażasz szablon, CloudFormation tworzy stack, czyli kolekcję zasobów, którymi zarządza jako całość.
Kluczowa cecha: usunięcie stacka usuwa wszystkie zasoby, które stack utworzył. To ogromna zaleta, bo nie zostawiasz „zaśmieconych" zasobów.
Drift Detection
Co jeśli ktoś ręcznie zmieni zasób, który jest zarządzany przez CloudFormation? Na przykład doda regułę do security group przez konsolę?
To się nazywa drift (dryf). CloudFormation ma funkcję Drift Detection, która porównuje aktualny stan zasobu z tym, co jest zdefiniowane w szablonie. Wykrywa różnice i raportuje, które zasoby „odleciały" od definicji.
Rollback i ochrona
CloudFormation ma wbudowane mechanizmy bezpieczeństwa:
- Automatic Rollback - jeśli tworzenie stacka się nie powiedzie, CloudFormation automatycznie usuwa już utworzone zasoby
- Change Sets - możesz podejrzeć, co CloudFormation zamierza zmienić, zanim zatwierdzisz
- Stack Policies - chronią krytyczne zasoby przed przypadkową aktualizacją lub usunięciem
- Termination Protection - blokuje przypadkowe usunięcie stacka
Nested Stacks i Cross-Stack References
Dla dużych środowisk jeden szablon to za mało. CloudFormation wspiera:
- Nested Stacks - stack, który tworzy inne stacki (szablon w szablonie). Pozwala na modularność: osobny szablon dla sieci, osobny dla compute, osobny dla baz danych.
- Cross-Stack References - stacki mogą eksportować wartości (Outputs/Export), które inne stacki importują. Na przykład stack sieciowy eksportuje VPC ID, a stack aplikacyjny go importuje.
AWS CDK (Cloud Development Kit)
CDK to alternatywa dla pisania szablonów JSON/YAML. Zamiast deklaratywnego formatu, piszesz kod infrastruktury w swoim ulubionym języku programowania:
- TypeScript / JavaScript
- Python
- Java
- C# (.NET)
- Go
CDK pod spodem generuje szablon CloudFormation i wdraża go. To warstwa abstrakcji nad CloudFormation, nie osobna usługa.
| Aspekt | CloudFormation (YAML/JSON) | CDK (TypeScript/Python/etc.) |
|---|---|---|
| Format | Deklaratywny (YAML/JSON) | Imperatywny (kod programistyczny) |
| Krzywa uczenia | Łatwiejszy start | Wymaga znajomości języka |
| Logika | Ograniczona (Conditions) | Pełna (if/for/klasy) |
| Abstrakcje | Brak (niski poziom) | Constructs L1/L2/L3 (wysoki poziom) |
| Pod spodem | Natywne szablony | Generuje szablony CloudFormation |
AWS SAM (Serverless Application Model)
SAM to rozszerzenie CloudFormation dedykowane aplikacjom serverless. Upraszcza definiowanie:
- Funkcji Lambda
- API Gateway
- Tabel DynamoDB
- Event source mappings
SAM dodaje specjalne typy zasobów (np. AWS::Serverless::Function), które „rozwijają się" do wielu zasobów CloudFormation. Jedna linia SAM może utworzyć funkcję Lambda, rolę IAM, API Gateway endpoint i powiązane permissions.
SAM ma też SAM CLI, który pozwala lokalnie testować i debugować funkcje Lambda.
CloudFormation, CDK i SAM to natywne narzędzia AWS, ale warto wiedzieć o alternatywach:
- Terraform (HashiCorp) - multi-cloud IaC. Może zarządzać zasobami AWS, Azure, GCP i wielu innych providerów w jednym pliku. Używa własnego języka HCL.
- Pulumi - jak CDK, ale multi-cloud. Kod w TypeScript/Python/Go generuje zasoby w dowolnym cloudzie.
- AWS Elastic Beanstalk - nie jest stricte IaC, ale automatyzuje tworzenie infrastruktury dla aplikacji webowych (PaaS).
Na egzaminie Cloud Practitioner musisz znać CloudFormation. CDK i SAM pojawiają się jako opcje odpowiedzi, ale rzadziej.
- Infrastructure as Code (IaC) to definiowanie infrastruktury w plikach tekstowych zamiast klikania w konsoli
- CloudFormation to natywna usługa IaC w AWS: szablony (JSON/YAML) tworzą stacki zasobów
- Resources to jedyna wymagana sekcja szablonu; usunięcie stacka usuwa wszystkie jego zasoby
- Drift Detection wykrywa ręczne zmiany zasobów, które powinny być zarządzane przez CloudFormation
- CDK pozwala pisać infrastrukturę w języku programowania i generuje szablony CloudFormation
- SAM rozszerza CloudFormation o uproszczoną składnię dla aplikacji serverless (Lambda, API GW)
Firma chce powtarzalnie tworzyć identyczne środowiska (dev, staging, prod) w wielu regionach AWS. Jakie podejście jest najlepsze?
Inżynier ręcznie zmienił security group, który jest zarządzany przez CloudFormation. Jak to wykryć?
Zespół developerski chce definiować infrastrukturę w TypeScript zamiast YAML. Jakie narzędzie AWS to umożliwia?