Wzorzec metodyki DevOps

Kod z jednej lokalizacji i wdrażaj w wielu miejscach docelowych w środowiskach deweloperskich, testowych i produkcyjnych, które mogą znajdować się w lokalnym centrum danych, chmurach prywatnych lub w chmurze publicznej.

Kontekst i problem

Ciągłość wdrażania aplikacji, bezpieczeństwo i niezawodność są niezbędne dla organizacji i mają kluczowe znaczenie dla zespołów programistycznych.

Aplikacje często wymagają refaktoryzowanego kodu do uruchamiania w każdym środowisku docelowym. Oznacza to, że aplikacja nie jest całkowicie przenośna. Należy je zaktualizować, przetestować i zweryfikować podczas przechodzenia przez każde środowisko. Na przykład kod napisany w środowisku deweloperskim musi zostać przepisany do pracy w środowisku testowym i przepisany po zakończeniu pracy w środowisku produkcyjnym. Ponadto ten kod jest powiązany z hostem. Zwiększa to koszt i złożoność konserwacji aplikacji. Każda wersja aplikacji jest powiązana z każdym środowiskiem. Zwiększona złożoność i duplikacja zwiększają ryzyko bezpieczeństwa i jakości kodu. Ponadto kodu nie można łatwo ponownie wdrożyć, gdy usuwasz hosty, które uległy awarii, lub wdrażasz dodatkowe hosty, aby sprostać rosnącemu zapotrzebowaniu.

Rozwiązanie

Wzorzec Metodyki DevOps umożliwia tworzenie, testowanie i wdrażanie aplikacji działającej w wielu chmurach. Ten wzorzec łączy praktykę ciągłej integracji i ciągłego dostarczania. Dzięki ciągłej integracji kod jest kompilowany i testowany za każdym razem, gdy członek zespołu zatwierdza zmianę kontroli wersji. Ciągłe dostarczanie automatyzuje każdy krok z kompilacji do środowiska produkcyjnego. Razem te procesy tworzą proces wydania, który obsługuje wdrażanie w różnych środowiskach. Za pomocą tego wzorca można utworzyć wersję roboczą kodu, a następnie wdrożyć ten sam kod w środowisku lokalnym, różnych chmurach prywatnych i chmurach publicznych. Różnice w środowisku wymagają zmiany w pliku konfiguracji, a nie zmian w kodzie.

Dzięki spójnemu zestawowi narzędzi programistycznych w środowiskach lokalnych, chmury prywatnej i chmury publicznej można zaimplementować praktykę ciągłej integracji i ciągłego dostarczania. Aplikacje i usługi wdrożone przy użyciu wzorca DevOps są zamienne i mogą być uruchamiane w dowolnej z tych lokalizacji, korzystając z funkcji i funkcji chmury lokalnej i publicznej.

Korzystanie z pipelinie wydania DevOps pomaga:

• Zainicjuj nową kompilację na podstawie zatwierdzeń kodu w jednym repozytorium.
• Automatycznie wdróż nowo utworzony kod w chmurze publicznej na potrzeby testowania akceptacyjnego użytkowników.
• Automatyczne wdrażanie w chmurze prywatnej po zakończeniu testowania kodu.

Problemy i zagadnienia

Wzorzec Metodyki DevOps ma zapewnić spójność we wszystkich wdrożeniach niezależnie od środowiska docelowego. Jednak możliwości różnią się w różnych środowiskach chmurowych i lokalnych. Rozważ następujące kwestie:

• Czy funkcje, punkty końcowe, usługi i inne zasoby we wdrożeniu są dostępne w docelowych lokalizacjach wdrażania?
• Czy artefakty konfiguracji są przechowywane w lokalizacjach, które są dostępne w chmurach?
• Czy parametry wdrożenia będą działać we wszystkich środowiskach docelowych?
• Czy właściwości specyficzne dla zasobów są dostępne we wszystkich chmurach docelowych?

Aby uzyskać więcej informacji, zobacz Tworzenie szablonów usługi Azure Resource Manager na potrzeby spójności w chmurze.

Ponadto należy wziąć pod uwagę następujące kwestie podczas podejmowania decyzji, jak zaimplementować ten wzorzec:

Skalowalność

Systemy automatyzacji wdrażania to kluczowy punkt kontrolny w wzorcach DevOps. Implementacje mogą się różnić. Wybór odpowiedniego rozmiaru serwera zależy od rozmiaru oczekiwanego obciążenia. Skalowanie maszyn wirtualnych kosztuje więcej niż kontenerów. Aby jednak używać kontenerów do skalowania, proces kompilacji musi być uruchamiany z kontenerami.

Dostępność

Dostępność w kontekście metodyki DevPattern oznacza możliwość odzyskania wszelkich informacji o stanie skojarzonych z przepływem pracy, takich jak wyniki testów, zależności kodu lub inne artefakty. Aby ocenić wymagania dotyczące dostępności, rozważ dwie typowe metryki:

• Cel czasu odzyskiwania (RTO) określa, jak długo można obejść się bez systemu.

• Cel punktu odzyskiwania (RPO) wskazuje, ile danych można sobie pozwolić na utratę, jeśli zakłócenia w usłudze wpływają na system.

W praktyce czas odzyskiwania danych (RTO) i punkt odzyskiwania danych (RPO) oznaczają nadmiarowość i tworzenie kopii zapasowych. W globalnej chmurze platformy Azure dostępność nie jest kwestią odzyskiwania sprzętu — jest to część platformy Azure — ale raczej zapewnienie utrzymania stanu systemów DevOps. W usłudze Azure Stack Hub może być brane pod uwagę odzyskiwanie sprzętu.

Innym ważnym zagadnieniem podczas projektowania systemu używanego do automatyzacji wdrażania jest kontrola dostępu i właściwe zarządzanie prawami potrzebnymi do wdrażania usług w środowiskach w chmurze. Jakie prawa są potrzebne do tworzenia, usuwania lub modyfikowania wdrożeń? Na przykład jeden zestaw praw jest zwykle wymagany do utworzenia grupy zasobów na platformie Azure, a drugi do wdrożenia usług w grupie zasobów.

Zarządzalność

Projekt dowolnego systemu opartego na wzorcu DevOps musi uwzględniać automatyzację, rejestrowanie i alerty dla każdej usługi w portfolio. Używaj usług udostępnionych, zespołu aplikacji lub obu naraz, oraz śledź polityki bezpieczeństwa i zasady zarządzania.

Wdróż środowiska produkcyjne i środowiska programistyczne/testowe w osobnych grupach zasobów na platformie Azure lub w usłudze Azure Stack Hub. Następnie można monitorować zasoby każdego środowiska i zbiorczo rozliczać koszty według grupy zasobów. Zasoby można również usunąć jako zestaw, co jest przydatne w przypadku wdrożeń testowych.

Kiedy należy używać tego wzorca

Użyj tego wzorca, jeśli:

• Kod można opracowywać w jednym środowisku spełniającym potrzeby deweloperów i wdrażać w środowisku specyficznym dla rozwiązania, w którym tworzenie nowego kodu może być trudne.
• Możesz użyć kodu i narzędzi, które chcieliby deweloperzy, o ile będą mogli postępować zgodnie z procesem ciągłej integracji i ciągłego dostarczania we wzorcu DevOps.

Ten wzorzec nie jest zalecany:

• Jeśli nie możesz zautomatyzować infrastruktury, aprowizacji zasobów, konfiguracji, tożsamości i zadań zabezpieczeń.
• Jeśli zespoły nie mają dostępu do zasobów chmury hybrydowej w celu zaimplementowania podejścia ciągłej integracji/ciągłego opracowywania (CI/CD).

Następne kroki

Aby dowiedzieć się więcej o tematach wprowadzonych w tym artykule:

• Zapoznaj się z dokumentacją usługi Azure DevOps , aby dowiedzieć się więcej na temat usługi Azure DevOps i powiązanych narzędzi, w tym usługi Azure Repos i Azure Pipelines.
• Zobacz rodziny produktów i rozwiązań usługi Azure Stack, aby dowiedzieć się więcej o całym portfolio produktów i rozwiązań.

Gdy wszystko będzie gotowe do przetestowania przykładowego rozwiązania, kontynuuj z przewodnikiem wdrażania hybrydowego rozwiązania ciągłej integracji/ciągłego wdrażania usługi DevOps . Przewodnik wdrażania zawiera instrukcje krok po kroku dotyczące wdrażania i testowania składników. Dowiesz się, jak wdrożyć aplikację na platformie Azure i w usłudze Azure Stack Hub przy użyciu hybrydowego potoku ciągłej integracji/ciągłego dostarczania (CI/CD).