Przyspiesz wdrożenia w AWS dzięki efektywnemu zarządzaniu

Użytkownicy Amazon Web Services (AWS) często pytają, w jaki sposób przyspieszyć wdrożenia swoich zespołów w AWS przy jednoczesnym zachowaniu zgodności z kontrolami bezpieczeństwa. W poniższym artykule autorzy opisują typowe modele zarządzania wprowadzone w doświadczonych organizacjach w celu zarządzania wdrożeniami AWS w swoich zespołach. Wspomniane modele najlepiej nadają się do zwiększenia dojrzałości wdrożeń infrastruktury chmury.

Modele zarządzania dla wdrożeń AWS

Możemy wyróżnić trzy popularne modele używane przez doświadczonych użytkowników chmury do zarządzania wdrożeniami infrastruktury w AWS. Modele różnią się tym, co kontrolują: kodem infrastruktury, łańcuchem narzędzi do wdrażania lub udostępnionymi zasobami AWS. Modele definiowane są następująco:

1. Główna biblioteka wzorców, która oferuje repozytorium wyselekcjonowanych szablonów wdrożeń, które zespoły aplikacji mogą ponownie wykorzystać w swoich wdrożeniach.
2. Continuous Integration/Continuous Delivery (CI/CD) jako usługa, która oferuje standard toolchain do ponownego wykorzystania przez zespoły aplikacyjne.
3. Infrastruktura Zarządzana Centralnie, która umożliwia zespołom aplikacyjnym wdrażanie zasobów AWS zarządzanych przez centralne zespoły operacyjne.

Decyzja dotycząca tego, jaką odpowiedzialność przenosisz na zespoły aplikacyjne, zależy od ich autonomii, modelu operacyjnego, typu aplikacji i szybkości zmian. Te trzy modele mogą być używane w tandemie, aby rozwiązać różne przypadki użycia i zmaksymalizować wpływ. Zazwyczaj organizacje zaczynają od zebrania wstępnie zatwierdzonych szablonów wdrażania w centralnej bibliotece wzorców.

Model nr 1: Główna biblioteka wzorców

W tym modelu inżynierowie platform chmurowych publikują centralną bibliotekę wzorców, z której zespoły mogą odwoływać się do infrastruktury jako szablonów kodu. Zespoły aplikacyjne ponownie wykorzystują szablony przez rozwidlenie centralnego repozytorium lub kopiowanie szablonów do własnego repozytorium. Zespoły aplikacji mogą również zarządzać własnym kontem i potokiem wdrażania AWS za pomocą AWS CodePipeline), a także procesem udostępniania zasobów, ponownie wykorzystując szablony z centralnej biblioteki wzorców z usługą taką jak AWS CodeCommit. Rysunek nr 1 przedstawia przegląd tego modelu zarządzania.

Centralna biblioteka wzorców reprezentuje najmniej inwazyjną formę uaktywniania dzięki zasobom wielokrotnego użytku. Zespoły aplikacji doceniają model centralnej biblioteki wzorców, ponieważ pozwala im zachować niezależność nad procesem wdrażania i łańcuchem narzędzi. Ponowne wykorzystanie istniejących szablonów przyspiesza tworzenie pierwszych szablonów infrastruktury Twojego zespołu i ułatwia przestrzeganie zasad, takich jak zasady tagowania i kontrole bezpieczeństwa.

Gdy szablony wielokrotnego użytku znajdą się w repozytorium zespołu ds. aplikacji, aktualizacje przyrostowe można pobierać z biblioteki centralnej po ulepszeniu szablonu. Pozwala to zespołom na pobieranie, gdy uznają to za stosowne. Zmiany w repozytorium zespołu spowodują uruchomienie potoku w celu wdrożenia powiązanego kodu infrastruktury.

W przypadku modelu centralnej biblioteki wzorców zespoły aplikacyjne muszą samodzielnie zarządzać konfiguracją zasobów i łańcuchem narzędzi CI/CD, aby czerpać korzyści z automatycznych wdrożeń. Model 2 rozwiązuje ten problem.

Model 2: CI/CD jako usługa

W modelu 2 zespoły aplikacji uruchamiają zarządzany potok wdrażania z katalogu usług AWS. Obejmuje to kod infrastruktury potrzebny do uruchomienia aplikacji i kod źródłowy „hello world”, aby pokazać pełny przepływ wdrożenia.

Inżynierowie platformy chmurowej rozwijają portfolio katalogów usług (w tym przypadku toolchain CI/CD). Następnie zespoły aplikacji mogą uruchomić produkty AWS Service Catalog, które wdrażają instancję kodu potoku i zapełnione repozytorium Git (Rysunek nr 2).

Potok jest inicjowany natychmiast po zapełnieniu repozytorium, co powoduje wdrożenie aplikacji „hello world” w pierwszym środowisku. Kod infrastruktury (na przykład Amazon Elastic Compute Cloud [Amazon EC2] i AWS Fargate) zostanie umieszczony w repozytorium zespołu aplikacji. Aktualizacje przyrostowe można pobrać, uruchamiając aktualizację produktu z Katalogu usług AWS. Pozwala to zespołom aplikacyjnym na podjęcie działań, gdy uznają to za stosowne.

Przedstawiony model zarządzania jest szczególnie odpowiedni dla dojrzałych organizacji deweloperskich z pełną odpowiedzialnością lub projektami platformy, ponieważ zapewnia kompleksową automatyzację wdrażania w celu udostępniania zasobów w wielu zespołach i kontach AWS. Model ten dodaje również kontrolę bezpieczeństwa nad procesem wdrażania.

Ze względu na to, że zespoły mają niewiele miejsca na dostosowanie standardu toolchain, model może być postrzegany jako bardzo „zawzięty”. Oczekuje bowiem, że zespoły aplikacyjne będą zarządzać własną infrastrukturą. Model 3 przedstawiony poniżej rozwiązuje ten problem.

Model 3: Infrastruktura zarządzana centralnie

Ten model umożliwia zespołom aplikacyjnym udostępnianie zasobów zarządzanych przez centralny zespół operacyjny jako samoobsługowych. Inżynierowie platformy chmurowej publikują portfolio infrastruktury w AWS Service Catalog ze wstępnie zatwierdzoną konfiguracją przez centralne zespoły (Rysunek nr 3). Te portfolia mogą być współdzielone ze wszystkimi kontami AWS używanymi przez inżynierów aplikacji.

Udostępnianie zasobów AWS za pośrednictwem produktów AWS Service Catalog zapewnia, że konfiguracja zasobów spełnia wymagania operacji centralnych. W porównaniu z Modelem 2, wstępnie wypełnione szablony infrastruktury uruchamiają produkty AWS Service Catalog, w przeciwieństwie do bezpośredniego odwoływania się do API odpowiedniej usługi AWS (na przykład Amazon EC2). To blokuje sposób konfiguracji i aprowizacji infrastruktury.

Z doświadczenia autorów wynika, że zarządzanie różnorodnością produktów AWS Service Catalog jest kluczowe. Pozwala to uniknąć mnożenia produktów z wieloma nieznacznie różniącymi się szablonami. Infrastruktura zarządzana centralnie propaguje nastawienie „lokalne”, dlatego powinna być używana tylko w przypadkach, gdy zespoły aplikacyjne nie mogą posiadać pełnego stosu.

Modele 2 i 3 można łączyć w taki sposób, aby inżynierowie aplikacji mogli uruchamiać zarówno łańcuch narzędzi do wdrażania, jak i zasoby jako produkty AWS Service Catalog (Rysunek nr 4), zachowując jednocześnie możliwość udostępniania z wstępnie wypełnionych szablonów infrastruktury w repozytorium zespołu. Gdy kod znajdzie się w repozytorium, aktualizacje przyrostowe można pobrać, uruchamiając aktualizację z udostępnionego produktu AWS Service Catalog. Dzięki temu zespół ds. aplikacji może w razie potrzeby pobrać aktualizację, unikając ręcznego wdrażania produktów z katalogu usług.

Porównanie modeli

Trzy opisane modele zarządzania różnią się między sobą następującymi aspektami (zob. tabela 1):

• Poziom zarządzania: Jakim komponentem zarządzają centralnie inżynierowie platformy chmurowej?
• Rola inżynierów aplikacji: Jaki jest podział odpowiedzialności i model operacyjny?

• Przypadek użycia: Kiedy każdy model ma zastosowanie?

Tabela 1. Modele zarządzania do zarządzania wdrożeniami infrastruktury

Wnioski

Za pomocą tego artykułu autorzy wyróżnili trzy typowe modele zarządzania do zarządzania wdrażaniem zasobów AWS. Te trzy modele mogą być używane w tandemie, aby zająć się różnymi przypadkami użycia i zmaksymalizować wpływ na Twoją organizację. Decyzja o przeniesieniu odpowiedzialności na zespoły zajmujące się aplikacjami zależy od konfiguracji organizacyjnej i przypadku użycia.

Źródło: AWS