Wdrażanie z poczuciem pewności
 Osiągnij żądany stan wdrożenia z przewidywalnością. |
|---|
Utwórz łańcuch dostaw obciążenia, który umożliwia spójne osiągnięcie celu przewidywalności we wszystkich środowiskach, na platformach hostingu obciążenia, aplikacjach, danych i zasobach konfiguracji. Mechanizm wdrażania musi mieć możliwość automatyzacji, testowania, monitorowania i przechowywania wersji. Powinna być modularyzowana i gotowa do wykonania na żądanie. Nie powinien być reprezentowany jako monolityczny proces kompleksowego. Łańcuch dostaw nie musi być przeznaczony do szybszego wykonywania, ale do osiągnięcia spójności i samodzielnej dokumentacji w wielu iteracji.
Zespół ds. obciążeń jest odpowiedzialny za łańcuch dostaw, ponieważ odnosi się do własnego obciążenia.
Przykładowy scenariusz
Firma Contoso Manufacturing opracowała aplikację opartą na języku Java, która służy do monitorowania i optymalizowania procesów produkcyjnych. Obciążenie zostało ostatnio zmigrowane na platformę Azure i jest teraz uruchomione w usługach Azure Spring Apps, Azure Database for MySQL i Azure IoT Hub.
Wdrażanie infrastruktury za pomocą kodu
Użyj infrastruktury jako kodu (IaC), aby zdefiniować powtarzalne aspekty łańcucha dostaw, które są gotowe do produkcji. Preferuj podejścia deklaratywne w przypadku metod imperatywnych.
Technologie IaC deklaratywne są zaprojektowane z myślą o automatyzacji i możliwości ponownego użycia. Wdrożenia infrastruktury można odciążać od użytkowników indywidualnych do narzędzi i osiągać spójną jakość.
Z perspektywy infrastruktury mniejsza liczba opcji technologicznych eliminuje wariancję narzędzi i ułatwia wykrywanie dryfu konfiguracji. Konserwacja będzie również łatwiejsza. Jeśli dostosujesz opcje do istniejącego zestawu umiejętności zespołu, zespół będzie mógł je łatwo wdrożyć.
Wyzwanie firmy Contoso
- Lokalna wersja obciążenia korzystała z kombinacji skryptów i ręcznych kroków w celu skompilowania infrastruktury i wdrożenia aplikacji w różnych środowiskach. Na wczesnym etapie procesu migracji na platformę Azure zespół dokonał modyfikacji istniejących skryptów imperatywnych w celu kierowania nowej platformy, aby umożliwić ponowne użycie jak największej ilości istniejącej bazy kodu automatyzacji. Takie podejście zostało również podjęte ze względu na brak wiedzy na temat technologii Platformy Azure i IaC, takich jak Bicep.
- Gdy migracja się rozwijała, a zespół stał się bardziej zaznajomiony z platformą, przekonali się, że użycie podejścia IaC z Bicepem będzie lepszym rozwiązaniem w dłuższej perspektywie.
Stosowanie podejścia i wyników
- Brak wiedzy w firmie zespół zakontraktował pracę w celu przeprowadzenia migracji i rozszerzenia skryptów automatyzacji wdrożenia dla obciążenia do doświadczonych wykonawców, którzy pracowali z zespołem deweloperów w początkowej fazie projektu, zapewniając jednocześnie transfer wiedzy do reszty zespołu.
- Wynikowa implementacja oparta na Bicep zapewnia bardziej niezawodny, możliwy do zarządzania i wydajny sposób aprowizacji infrastruktury na platformie Azure. Kod jest teraz bardziej czytelny i można go obsługiwać dzięki doskonałej obsłudze narzędzi w programie VSCode. Jest to również w pełni idempotentne i upraszcza zarządzanie stanem, które nigdy nie były w stanie w pełni osiągnąć przy użyciu poprzedniej/imperatywnej wersji.
Traktuj kod IaC tak samo jak kod aplikacji
Postępuj zgodnie z zaleceniami dotyczącymi programowania i konserwacji IaC: Modularyzowanie w moderacji, unikanie abstrakcji niestandardowych lub o niskiej wartości oraz przestrzeganie warstwowego podejścia w celu odzwierciedlenia różnych cykli życia. Warstwy podstawowe formularza, w których dolne warstwy pozostają stałe, a górne warstwy zmieniają się zgodnie z potrzebami.
Artefakty wdrażania, takie jak pliki binarne aplikacji, szablony IaC i parametry, są częścią obszaru ataków. Zastosuj gwarancje, takie jak zarządzanie wpisami tajnymi, kontrola dostępu i inne zasady filaru zabezpieczeń.
Artefakty mają taki sam poziom rygoru inżynieryjnego jak kod aplikacji. Mechanizmy kontroli jakości za pośrednictwem przeglądów równorzędnych i testowania zapewniają pewność wdrożenia.
Podejście warstwowe ułatwia konserwację i tworzy granice, które określają jasne linie odpowiedzialności.
Dodanie mechanizmów kontroli zabezpieczeń do artefaktów pomaga wzmocnić bezpieczeństwo systemu podczas procesu wdrażania.
Wyzwanie firmy Contoso
- Zespół projektu miał hojny budżet na początku wysiłku migracyjnego, więc zatrudnili bardzo doświadczonych wykonawców, którzy dostarczali wysokiej jakości i w krótkim czasie. Wykonawcy używali oddzielnego repozytorium na potrzeby ich programowania i że repozytorium nie zostało regularnie poddawane inspekcji pod kątem zabezpieczeń, podczas gdy główne repozytorium kodu aplikacji jest.
- Zespół przygotowuje się do wydania poważnego przeprojektowania rozwiązania, a kod wdrożenia wymaga znaczących zmian. Ze względu na niedobór zasobów programistycznych najnowsza partia zmian jest wprowadzana przez dwóch stażystów. Gdy jeden z starszych deweloperów w zespole jest wywoływany w celu ułatwienia stażysty, zauważa wiele zatwierdzeń w repozytorium, które nie są zgodne ze standardami programowania zespołu, w tym posiadanie wpisów tajnych aplikacji, takich jak klucze interfejsu API zakodowane na stałe w bazie kodu.
Stosowanie podejścia i wyników
- Zespół decyduje się przenieść bazę kodu kompilacji i wdrożenia do tego samego repozytorium używanego dla kodu aplikacji i rozpocząć stosowanie tego samego poziomu platformy inżynieryjnej co inne obszary bazy kodu. Kod jest wprowadzany do standardów zespołu przed pierwszym zatwierdzeniem, wpisy tajne aplikacji są usuwane, a do niego są stosowane wszystkie inne standardy i narzędzia dotyczące jakości zespołu.
- W rezultacie zespół zabezpieczył tę sekcję bazy kodu przy jednoczesnym zwiększeniu jakości kodu. Idąc dalej, zmiany w tym obszarze bazy kodu będą zgodne z tymi samymi standardami i korzystają z tych samych narzędzi używanych w podstawowej bazie kodu aplikacji, w tym przeglądów kodu równorzędnego i zautomatyzowanego skanowania kodu za pomocą narzędzi jakości i zabezpieczeń.
Standaryzacja wdrożeń w jednym manifeście
Opracuj wspólny manifest wdrożenia, który jest używany we wszystkich środowiskach. Użyj tego manifestu jako domyślnego mechanizmu dla projektów greenfield, przyrostowych aktualizacji obciążeń lub odzyskiwania po awarii.
Zastosowanie tego podejścia umożliwi usunięcie nakładu pracy związanego z konserwowaniem wielu zasobów.
Jeśli wystąpi awaria, odzyskiwanie będzie szybkie i niezawodne, ponieważ można wdrożyć wypróbowany i przetestowany manifest zamiast tworzyć improwizowane środowisko.
Wyzwanie firmy Contoso
- Firma Contoso Manufacturing używa w pełni zautomatyzowanego potoku do wdrażania infrastruktury, kodu aplikacji i zmian konfiguracji w środowisku deweloperskim i produkcyjnym. Aplikacja jest skonfigurowana do wysokiej dostępności w jednym regionie. Większość składników aplikacji jest bezstanowa, z wyjątkiem bazy danych MySQL. Kopia zapasowa bazy danych jest tworzona zgodnie z ustalonym celem punktu odzyskiwania/celu punktu odzyskiwania, a kopia zapasowa jest replikowana do regionu pomocniczego.
- Jeśli w regionie podstawowym wystąpi poważny lub katastrofalny błąd, zespół planuje skompilować nowe środowisko do hostowania aplikacji w regionie pomocniczym. Podczas zaplanowanego testowania procedur odzyskiwania po awarii skrypty wdrażania kończą się niepowodzeniem podczas próby odtworzenia środowiska w regionie pomocniczym z powodu braku dostępności kilku zasobów i innych ograniczeń usługi.
Stosowanie podejścia i wyników
- Zespół ogranicza problemy, które napotkali podczas próby aprowizacji w regionie pomocniczym, zastępując użycie niektórych zasobów równoważnymi jednostkami SKU, które są dostępne w obu regionach i co umożliwia skonfigurowanie niektórych opcji, dzięki czemu można użyć innej, ale prawidłowej wartości w pomocniczym.
- Ćwiczenie zwiększyło zaufanie zespołu do odzyskiwania sprawności po poważnych awariach infrastruktury.