Zarządzanie analizą w skali chmury

Obecnie metodyka DevOps zmieniła kulturę sposobu, w jaki ludzie myślą i pracują, przyspieszając tempo, w jakim firmy zdają sobie sprawę z wartości, pomagając osobom i organizacjom w opracowywaniu i utrzymywaniu zrównoważonych praktyk pracy. Metodyka DevOps łączy programowanie i operacje i jest często skojarzona z narzędziami 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 Team Foundation Version Control) oraz menedżerów automatycznej kompilacji i dostarczania (takich jak Azure Pipelines lub GitHub Actions).

Metodyka DevOps połączona z obserwacją ma kluczowe znaczenie dla zapewnienia elastycznej i skalowalnej platformy. Podejście DevOps umożliwia zespołom implementowanie kontroli wersji, potoków CI/CD, infrastruktury jako kodu, przepływów pracy i automatyzacji. Chociaż możliwość obserwacji 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 oraz unikanie eliminowania przestojów, które w przeciwnym razie spowodują przerwanie analizy produkcyjnej i sztucznej inteligencji.

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 do 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 repozytoriami centralnymi. Dostawcy systemu Git zazwyczaj używają również branchy i działają zgodnie ze wskazówkami dotyczącymi żądań przeniesienia, aby wspierać przepływ zmian i przeglądu.

Gałęzie izolują zmiany lub rozwój funkcji bez wpływu na inne równolegle prowadzone prace. 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 bezpieczeństwa gałąź główna powinna używać żądań ściągnięcia w celu zapewnienia przeglądów kodu.

Potoki CI/CD

CI umożliwia zespołom automatyczne testowanie i budowanie kodu źródłowego oraz pozwala na szybkie iteracje i pętle informacji zwrotnej w celu zapewnienia wysokiej jakości kodu w konfiguracji ciągłej. Mechanizmy pipeline to sposoby konfiguracji ciągłej integracji (CI) zmian (kodu oprogramowania lub kodu infrastruktury) oraz ciągłego wdrażania (CD) spakowanych/skompilowanych zmian. Jest to również nazywane kompilacją i wydaniem. Automatyczne wdrażanie aplikacji (CD) opisuje proces wdrażania ich do jednego lub więcej środowisk. Ciągłe wdrażanie (CD) zazwyczaj następuje po procesie ciągłej integracji (CI) i używa testów integracyjnych do weryfikacji całej aplikacji.

Rurociągi mogą zawierać wiele faz z różnorodnymi zadaniami oraz mogą mieć proste lub złożone przepływy zatwierdzania, aby zapewnić zgodność i walidację. Na podstawie preferencji potoki można również skonfigurować za pomocą różnych wyzwalaczy automatycznych. W przypadku wdrożenia w skali przedsiębiorstwa i sztucznej inteligencji kroki produkcyjne powinny zawsze zawierać wstępne zatwierdzenie przez człowieka i jest to wbudowane w model operacji. Potoki CI/CD powinny być tworzone za pomocą GitHub Actions lub Azure Pipelines. Powinny również być wyzwalane automatycznie.

Infrastruktura jako kod

Termin kod w IaC często budzi obawy dotyczące pracowników IT bez doświadczenia deweloperów, ale IaC nie odnosi się do pisania kodu w taki sposób, w jaki to robią typowi deweloperzy oprogramowania. Jednak przyjmuje wiele z 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 wykonywania przez silnik orkiestracji 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 zestawy deweloperów oprogramowania języka natywnego, 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 definiowana w sekcji właściwości . W przypadku usługi 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')]"
            }
        }
    ]
}

Przepływy pracy i automatyzacja

Zespoły powinny używać potoków CI/CD w kilku etapach, aby upewnić się, że opracowany kod jest bez błędów i gotowy do produkcji. Niektóre najlepsze rozwiązania to środowisko deweloperskie, środowisko testowe i środowisko produkcyjne. Te etapy powinny być również odzwierciedlone 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 i upraszczania wdrożeń dla zespołów nieznanych w usłudze 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 typowe standardy w firmie.

Wdrożenia do środowisk testowego i produkcyjnego powinny być zarządzane tylko za pośrednictwem potoku CI/CD i połączenia usługi z podwyższonym poziomem uprawnień, aby zapewnić przestrzeganie powszechnie przyjętych dobrych praktyk (na przykład szablony Azure Resource Manager).

Dalsze kroki

Automatyzacja platformy