Zarządzanie analizą w skali chmury
Obecnie metodyka DevOps zmieniła kulturę tego, jak ludzie myślą i pracują, przyspieszając tempo, w którym firmy zdają sobie sprawę z wartości, pomagając osobom i organizacjom rozwijać i utrzymywać zrównoważone praktyki pracy. Metodyka DevOps łączy programowanie i operacje i jest często kojarzona z narzędziami do inżynierii oprogramowania, które obsługują praktyki ciągłej integracji i ciągłego dostarczania (CD). Te narzędzia i praktyki obejmują menedżerów kodu źródłowego (takich jak Git, Apache Subversion lub Kontrola wersji serwera Team Foundation) oraz menedżerów automatycznego tworzenia i dostarczania (takich jak Azure Pipelines lub GitHub Actions).
Metodyka DevOps połączona z obserwacją ma kluczowe znaczenie dla zapewnienia elastycznej i skalowalnej platformy. Metodyka DevOps umożliwia zespołom implementowanie potoków kontroli źródła, ciągłej integracji/ciągłego wdrażania, infrastruktury jako kodu, przepływów pracy i automatyzacji. Podczas gdy obserwacja umożliwia właścicielom firm, inżynierom DevOps, architektom danych, inżynierom danych i inżynierom niezawodności lokacji wykrywanie, przewidywanie, zapobieganie i rozwiązywanie problemów w zautomatyzowany sposób i unikanie eliminowania przestojów, które w przeciwnym razie przerywają analizę produkcyjną i sztuczną inteligencję.
Kontrola źródła
Kontrola źródła zapewnia trwałość kodu i konfiguracji oraz śledzenie i przechowywanie wersji zmian. Większość systemów kontroli źródła ma również wbudowane procesy przeglądania i pracy w różnych gałęziach repozytorium kodu. Obecnie najpopularniejszym typem kontroli źródła jest usługa Git, czyli rozproszony system kontroli wersji, który umożliwia osobom pracę w trybie offline i synchronizację z centralnymi repozytoriami. Dostawcy usługi Git zazwyczaj używają również gałęzi i postępuj zgodnie ze wskazówkami dotyczącymi żądania ściągnięcia, aby obsługiwać przepływ zmian i przeglądu.
Gałęzie izolować zmiany lub rozwój funkcji bez wpływu na inną pracę, która odbywa się w tym samym czasie. Użycie gałęzi powinno być promowane do tworzenia funkcji, naprawiania usterek i bezpiecznego eksperymentowania z nowymi pomysłami. Żądania ściągnięcia scalają zmiany wprowadzone z jednej gałęzi do gałęzi domyślnej i obsługują kontrolowany proces przeglądu. W celach zabezpieczających gałąź główna powinna używać żądań ściągnięcia w celu zapewnienia przeglądów kodu.
Ważne
Postępuj zgodnie z poniższymi wytycznymi dotyczącymi repozytoriów analitycznych w skali chmury:
- Zabezpiecz gałąź główną repozytorium, wymuszając gałęzie i żądania ściągnięcia, aby zapewnić kontrolowane procesy przeglądu.
- Repozytoria usługi Azure DevOps lub GitHub powinny służyć do śledzenia zmian w kodzie źródłowym i zezwalania wielu członkom zespołu na tworzenie kodu w tym samym czasie.
- Konfiguracje kodu aplikacji i infrastruktury należy zaewidencjonować w repozytorium.
Potoki ciągłej integracji/ciągłego wdrażania
Ciągła integracja umożliwia zespołom automatyczne testowanie i kompilowanie kodu źródłowego oraz umożliwia szybsze iterację i pętle opinii w celu zapewnienia wysokiej jakości kodu na dysku CD. Potoki to sposoby konfigurowania ciągłej integracji zmian (kodu oprogramowania lub kodu infrastruktury) oraz ciągłego wdrażania spakowanych/skompilowanych zmian. Jest to również nazywane kompilacją i wydaniem. Cd opisuje automatyczne wdrażanie aplikacji w co najmniej jednym środowisku. Ciągłe wdrażanie zwykle jest zgodne z procesem ciągłej integracji i używa testów integracji w celu zweryfikowania całej aplikacji.
Potoki mogą zawierać wiele etapów z różnymi zadaniami i mogą mieć proste do złożonych przepływów zatwierdzania w celu zapewnienia zgodności i walidacji. Na podstawie preferencji potoki można również skonfigurować przy użyciu różnych wyzwalaczy automatycznych. W przypadku wdrażania w skali przedsiębiorstwa i sztucznej inteligencji kroki produkcyjne powinny zawsze mieć wstępnie zatwierdzaną przez człowieka i jest to wbudowane w model operacyjny. Potoki ciągłej integracji/ciągłego wdrażania powinny być tworzone przy użyciu GitHub Actions lub usługi Azure Pipelines i powinny być wyzwalaczami automatycznymi.
Infrastruktura jako kod
Termin kod w IaC często budzi obawy pracowników IT bez doświadczenia dewelopera, ale IaC nie odnosi się do pisania kodu, w jaki to robią typowi deweloperzy oprogramowania. Jednak przyjmuje wiele tych samych narzędzi i zasad z procesów tworzenia oprogramowania w celu dostarczania infrastruktury w przewidywalnym formacie.
Usługa IaC ułatwia aprowizację, konfigurowanie i zarządzanie infrastrukturą w ramach potoku DevOps z pełnymi mechanizmami kontroli zmian, historią inspekcji, testami, walidacjami i procesami zatwierdzania, zapewniając, że zadania można delegować do odpowiednich ról dla projektu bez naruszania zabezpieczeń i zgodności.
Dwa podejścia do IaC są deklaratywne i imperatywne:
Deklaratywne odnosi się do określania żądanego stanu infrastruktury i posiadania aparatu orkiestracji wykonywania niezbędnych działań w celu osiągnięcia żądanego stanu. Na platformie Azure odbywa się to za pomocą szablonów usługi Azure Resource Manager. Warstwy abstrakcji innych firm, takie jak Terraform, są również dostępne dla tego podejścia.
Podejście imperatywne odnosi się do wykonywania określonych poleceń w zdefiniowanej kolejności. W przypadku platformy Azure można to osiągnąć za pomocą interfejsu wiersza polecenia lub programu PowerShell, ale natywne zestawy deweloperskie oprogramowania języka programowania, na przykład .NET, Python i Java, są również dostępne, jeśli są wymagane zintegrowane rozwiązania.
W szablonach usługi Azure Resource Manager podstawowa aprowizacja znajduje się w sekcji zasobów, a konfiguracja poszczególnych zasobów jest zdefiniowana w sekcji właściwości. W przypadku Azure Data Lake Storage Gen2 konfiguracja wygląda następująco:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.MachineLearningServices/workspaces/datastores",
"name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
"apiVersion": "2020-05-01-preview",
"location": "[parameters('location')]",
"properties": {
"DataStoreType": "adls-gen2",
"SkipValidation": "[parameters('skipValidation')]",
"ClientId": "[parameters('clientId')]",
"ClientSecret": "[parameters('clientSecret')]",
"FileSystem": "[parameters('fileSystem')]",
"AccountName": "[parameters('accountName')]",
"TenantId": "[parameters('tenantId')]",
"ResourceUrl": "[parameters('resourceUrl')]",
"AuthorityUrl": "[parameters('authorityUrl')]"
}
}
]
}
Ważne
Każda warstwa analizy w skali chmury, taka jak strefa docelowa zarządzania danymi, strefy docelowe danych lub aplikacje danych (które tworzą produkty danych), powinny być definiowane przy użyciu języka deklaratywnego, takiego jak Azure Resource Manager lub Terraform, zaewidencjonowane w repozytorium i wdrożone za pośrednictwem potoków ciągłej integracji/ciągłego wdrażania. Dzięki temu zespoły mogą śledzić zmiany wersji i infrastruktury i konfiguracji zakresu platformy Azure, jednocześnie obsługując różne poziomy architektury w sposób elastyczny. Te wskazówki prowadzą zespoły do korzystania z repozytoriów Git, aby zawsze mieć wgląd w stan określonych zakresów platformy Azure.
Przepływy pracy i automatyzacja
Zespoły powinny używać potoków ciągłej integracji/ciągłego wdrażania na wielu etapach, aby upewnić się, że opracowany kod jest bez błędów i gotowy do produkcji. Niektóre najlepsze rozwiązania to środowisko projektowe, środowisko testowe i środowisko produkcyjne. Te etapy powinny być również odzwierciedlane na platformie Azure przy użyciu oddzielnych usług dla każdego środowiska.
Zespół ds. platformy jest odpowiedzialny za zapewnianie i konserwowanie szablonów wdrażania w celu szybkiego skalowania w organizacji oraz upraszczanie wdrożeń dla zespołów, które nie są w stanie pracować z IaC. Te szablony służą jako punkt odniesienia dla nowych artefaktów w scenariuszu i muszą być utrzymywane wraz z upływem czasu, aby reprezentować najlepsze rozwiązania i wspólne standardy w firmie.
Wdrożenia do testowania i produkcji powinny być zarządzane tylko za pośrednictwem potoku ciągłej integracji/ciągłego wdrażania i połączenia z usługą z podwyższonym poziomem uprawnień w celu wymuszania typowych najlepszych rozwiązań (na przykład szablonów usługi Azure Resource Manager).
Przestroga
Zespoły aplikacji danych powinny mieć dostęp do odczytu tylko do środowisk testowych i produkcyjnych, a wdrożenia w tych środowiskach powinny być wykonywane tylko za pośrednictwem potoków ciągłej integracji/ciągłego wdrażania i połączeń usług z podwyższonym poziomem uprawnień. Aby przyspieszyć ścieżkę do środowiska produkcyjnego, zespoły aplikacji danych powinny mieć dostęp do zapisu w środowisku deweloperskim.