Udostępnij za pośrednictwem

wzorzec DevOps

  • Artykuł

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ą refaktoryzacji kodu do uruchamiania w każdym środowisku docelowym. Oznacza to, że aplikacja nie jest całkowicie przenośna. Należy ją 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 nie można łatwo ponownie wdrożyć kodu po usunięciu nieudanych hostów przywracania lub wdrożeniu dodatkowych hostów w celu obsługi wzrostu zapotrzebowania.

Rozwiązanie

Wzorzec 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 wydawania, 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.

DevOps pattern

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 możliwości chmury lokalnej i publicznej.

Korzystanie z potoku wydania DevOps ułatwia:

  • 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.
  • Automatycznie wdrażaj w chmurze prywatnej po zakończeniu testowania kodu.

Problemy i kwestie do rozważenia

Wzorzec 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 punkty:

  • Czy funkcje, punkty końcowe, usługi i inne zasoby we wdrożeniu są dostępne w docelowych lokalizacjach wdrożenia?
  • 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 Develop Azure Resource Manager templates for cloud consistency (Tworzenie szablonów usługi Azure Resource Manager na potrzeby spójności w chmurze).

Ponadto podczas podejmowania decyzji o sposobie implementacji tego wzorca należy wziąć pod uwagę następujące kwestie:

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. Maszyny wirtualne kosztują więcej skalowania niż kontenery. Jednak aby można było skalować przy użyciu kontenerów, procesy kompilacji muszą być uruchamiane za pomocą kontenerów.

Dostępność

Dostępność w kontekście 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, weź pod uwagę dwie typowe metryki:

  • Cel czasu odzyskiwania (RTO) określa, jak długo można przejść 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 cel czasu odzyskiwania i cel punktu odzyskiwania oznaczają nadmiarowość i tworzenie kopii zapasowych. W globalnej chmurze platformy Azure dostępność nie jest kwestią odzyskiwania sprzętu — która jest częścią platformy Azure — ale zapewnia utrzymanie stanu systemów DevOps. W usłudze Azure Stack Hub może być brane pod uwagę odzyskiwanie sprzętu.

Kolejną ważną kwestią podczas projektowania systemu używanego do automatyzacji wdrażania jest kontrola dostępu i właściwe zarządzanie prawami wymaganymi 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.

Możliwości zarządzania

Projekt dowolnego systemu na podstawie wzorca DevOps musi uwzględniać automatyzację, rejestrowanie i alerty dla każdej usługi w całym portfolio. Używaj usług udostępnionych, zespołu aplikacji lub obu tych usług, a także śledź zasady zabezpieczeń i ład.

Wdrażanie środowisk produkcyjnych i środowisk deweloperskich/testowych w oddzielnych grupach zasobów na platformie Azure lub w usłudze Azure Stack Hub. Następnie można monitorować zasoby każdego środowiska i zbiorczo naliczać koszty rozliczeń według grupy zasobów. Zasoby można również usuwać jako zestaw, co jest przydatne w przypadku wdrożeń testowych.

Kiedy 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 danego 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 ciągłym procesem 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, aby zaimplementować podejście ciągłej integracji/ciągłego programowania (CI/CD).

Następne kroki

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

Gdy wszystko będzie gotowe do przetestowania przykładu rozwiązania, przejdź do przewodnika wdrażania hybrydowego rozwiązania ciągłej integracji/ciągłego wdrażania DevOps. Przewodnik wdrażania zawiera instrukcje krok po kroku dotyczące wdrażania i testowania jego 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).