Eksplorowanie wdrożenia środowiska
Załóżmy, że kiedykolwiek otrzymasz telefon pomocy technicznej w środku nocy z powodu awarii serwera.
W takim przypadku znasz problem z przeszukiwaniem wielu arkuszy kalkulacyjnych, a nawet pamięci — aby uzyskać dostęp do ręcznych kroków konfigurowania nowej maszyny.
Następnie istnieje również trudności z utrzymaniem spójnych środowisk programistycznych i produkcyjnych.
Łatwiejszym sposobem usunięcia możliwości błędu ludzkiego podczas inicjowania maszyn jest użycie infrastruktury jako kodu.
Wdrażanie ręczne a infrastruktura jako kod
Powszechna analogia do zrozumienia różnic między ręcznym wdrażaniem a infrastrukturą jako kodem jest rozróżnienie między właścicielem zwierząt domowych a właścicielem bydła.
Kiedy masz zwierzęta domowe, nazywasz każdy z nich i traktujesz je jako osoby; jeśli coś strasznego dzieje się z jednym z Twoich zwierząt domowych, jesteś skłonny do opieki dużo.
Jeśli masz stado bydła, nadal możesz je nazwać, ale uważasz ich stado.
W kategoriach infrastruktury mogą wystąpić poważne konsekwencje w przypadku ręcznego wdrożenia, jeśli jedna maszyna ulegnie awarii i trzeba ją zastąpić (zwierzęta domowe).
W przypadku wdrożenia infrastruktury jako podejścia do kodu można łatwiej aprowizować inną maszynę bez negatywnego wpływu na całą infrastrukturę (bydło), jeśli jedna maszyna ulegnie awarii.
Implementowanie infrastruktury jako kodu
Infrastruktura jako kod umożliwia przechwytywanie środowiska (lub środowisk) w pliku tekstowym (skrypt lub definicja).
Plik może zawierać wszystkie sieci, serwery i inne zasoby obliczeniowe.
Możesz sprawdzić skrypt lub plik definicji w kontroli wersji, a następnie użyć go jako źródła do aktualizowania istniejących środowisk lub tworzenia nowych.
Na przykład można dodać nowy serwer, edytując plik tekstowy i uruchamiając potok wydania, a nie zdalnie go w środowisku i ręcznie aprowizować nowy serwer.
W poniższej tabeli wymieniono istotne różnice między wdrażaniem ręcznym a infrastrukturą jako kodem.
| Wdrażanie ręczne | Infrastruktura jako kod |
|---|---|
| Serwery snowflake. | Spójny serwer między środowiskami. |
| Kroki wdrażania różnią się w zależności od środowiska. | Środowiska są tworzone lub łatwo skalowane. |
| Więcej kroków weryfikacji i bardziej skomplikowanych procesów ręcznych. | W pełni zautomatyzowane tworzenie Aktualizacje środowiska. |
| Zwiększono dokumentację, aby uwzględnić różnice. | Przejście do niezmiennej infrastruktury. |
| Wdrożenie w weekendy, aby umożliwić odzyskiwanie po błędach. | Użyj wdrożeń niebieski/zielony. |
| Wolniejsze tempo uwalniania, aby zminimalizować ból i długie weekendy. | Traktuj serwery jako bydło, a nie zwierzęta domowe. |
Zalety infrastruktury jako kodu
Poniższa lista ma zalety infrastruktury jako kodu:
- Promuje inspekcję, ułatwiając śledzenie wdrożonych, kiedy i jak to zrobić. (Innymi słowy, poprawia możliwość śledzenia).
- Zapewnia spójne środowiska od wydania do wydania.
- Większa spójność w środowiskach deweloperskich, testowych i produkcyjnych.
- Automatyzuje procesy skalowania w górę i skalowania w poziomie.
- Umożliwia kontrolowanie wersji konfiguracji.
- Udostępnia funkcje przeglądu kodu i testowania jednostkowego, które ułatwiają zarządzanie zmianami infrastruktury.
- Używa niezmiennych procesów usługi, co oznacza, że w przypadku konieczności zmiany środowiska zostanie wdrożona nowa usługa, a stary został zdjęty, nie zostanie zaktualizowany.
- Umożliwia wdrożenia niebieskie/zielone . Ta metodologia wydania minimalizuje przestoje, w których istnieją dwa identyczne środowiska — jeden jest żywy, a drugi nie. Aktualizacje są stosowane do serwera, który nie jest uruchomiony. Po zweryfikowaniu i zakończeniu testowania zostanie ona zamieniona na różne serwery na żywo. Staje się nowym środowiskiem na żywo, a poprzednie środowisko na żywo nie jest już aktywne.
- Traktuje infrastrukturę jako elastyczny zasób, który można aprowizować, anulować aprowizację i ponownie aprowizować w razie potrzeby.