Tworzenie środowisk docelowych i
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
W tym artykule opisano sposób tworzenia i określania docelowych środowisk usługi Azure Pipelines. Środowisko to kolekcja zasobów , których można kierować przy użyciu wdrożeń z potoku.
Środowisko reprezentuje logiczny element docelowy, w którym potok wdraża oprogramowanie. Typowe nazwy środowisk to Dev, Test, QA, Staging i Production.
Uwaga
Środowiska usługi Azure DevOps nie są dostępne w potokach klasycznych. W przypadku potoków klasycznych grupy wdrożeń oferują podobne funkcje.
Środowiska zapewniają następujące korzyści:
Historia wdrażania. Nazwa potoku i szczegóły uruchomienia są rejestrowane dla wdrożeń w środowisku i jego zasobach. W kontekście wielu potoków przeznaczonych dla tego samego środowiska lub zasobu można użyć historii wdrażania środowiska, aby zidentyfikować źródło zmian.
Możliwość śledzenia zatwierdzeń i elementów roboczych. Zadania można wyświetlić w ramach uruchomienia potoku, które są przeznaczone dla środowiska. Możesz również wyświetlić zatwierdzenia i elementy robocze, które zostały nowo wdrożone w środowisku. Możliwość śledzenia umożliwia również śledzenie, czy zatwierdzenie zmiany kodu, czy element roboczy funkcji/poprawki błędów osiągnął środowisko.
Kondycja zasobu diagnostycznego. Możesz sprawdzić, czy aplikacja działa w żądanym stanie.
Zabezpieczenia. Środowiska można zabezpieczyć, określając użytkowników i potoki, które mogą być przeznaczone dla środowiska.
Środowisko to grupowanie zasobów, w których same zasoby reprezentują rzeczywiste cele wdrożenia. Środowiska usługi Azure Pipelines obsługują obecnie typy zasobów platformy Kubernetes i maszyny wirtualnej.
Jeśli potok YAML odwołuje się do środowiska, które nie istnieje:
Gdy użytkownik wykonujący operację jest znany i można przypisać uprawnienia, usługa Azure Pipelines automatycznie tworzy środowisko.
Jeśli usługa Azure Pipelines nie zawiera informacji o użytkowniku wykonującym operację, na przykład w aktualizacji YAML z zewnętrznego edytora kodu potok kończy się niepowodzeniem.
Wymagania wstępne
Aby dodać środowisko, potrzebne są następujące wymagania wstępne:
- Organizacja i projekt usługi Azure DevOps.
- Rola Twórca dla środowisk w projekcie.
Utwórz środowisko
Aby utworzyć pierwsze środowisko:
Zaloguj się do organizacji usługi Azure DevOps pod adresem
https://dev.azure.com/{yourorganization}
i otwórz projekt.Wybierz pozycję Środowiska potoków>>Utwórz środowisko.
Wprowadź informacje dotyczące środowiska, a następnie wybierz pozycję Utwórz. Zasoby można dodać do istniejącego środowiska później.
Napiwek
Możesz utworzyć puste środowisko i odwoływać się do niego z zadań wdrażania, aby rejestrować historię wdrażania w środowisku.
Usługi Azure Pipelines można użyć do wdrożenia w środowiskach. Aby uzyskać więcej informacji, zobacz Build and deploy to Azure Kubernetes Service with Azure Pipelines (Kompilowanie i wdrażanie w usłudze Azure Kubernetes Service za pomocą usługi Azure Pipelines).
Określanie docelowego środowiska z zadania wdrożenia
Zadanie wdrożenia to kolekcja kroków, które są uruchamiane sekwencyjnie. Za pomocą zadania wdrażania można kierować całą grupę zasobów środowiska, jak pokazano w poniższym przykładowym fragmencie kodu YAML. Potok jest uruchamiany na maszynie, myVM
ponieważ określona jest ta nazwa zasobu.
- stage: deploy
jobs:
- deployment: DeployWeb
displayName: deploy Web App
pool:
vmImage: 'Ubuntu-latest'
# creates an environment if it doesn't exist
environment:
name: 'smarthotel-dev'
resourceName: myVM
resourceType: virtualMachine
strategy:
runOnce:
deploy:
steps:
- script: echo Hello world
Określanie celu określonego zasobu środowiska z zadania wdrożenia
Możesz ograniczyć zakres docelowy wdrożenia do określonego zasobu w środowisku, aby można było rejestrować historię wdrażania dla określonego zasobu. Kroki zadania wdrażania automatycznie dziedziczą szczegóły połączenia z usługą z zasobu docelowym zadania wdrożenia.
W poniższym przykładzie wartość automatycznie kubernetesServiceConnection
przekazuje do zadania z danych wejściowych environment.resource
.
environment:
name: 'smarthotel-dev.bookings'
strategy:
runOnce:
deploy:
steps:
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
namespace: $(k8sNamespace)
manifests: $(System.ArtifactsDirectory)/manifests/*
imagePullSecrets: $(imagePullSecret)
containers: $(containerRegistry)/$(imageRepository):$(tag)
Uwaga
Jeśli używasz prywatnego klastra usługi AKS, upewnij się, że masz połączenie z siecią wirtualną klastra, ponieważ punkt końcowy serwera interfejsu API nie jest uwidoczniony za pośrednictwem publicznego adresu IP.
Usługa Azure Pipelines zaleca skonfigurowanie własnego agenta w sieci wirtualnej, która ma dostęp do sieci wirtualnej klastra. Aby uzyskać szczegółowe informacje, zobacz Opcje nawiązywania połączenia z klastrem prywatnym.
Korzystanie z testów zatwierdzania ręcznego
Aby kontrolować wdrożenia w środowiskach produkcyjnych, usługa Azure Pipelines obsługuje ręczne kontrole zatwierdzeń w środowiskach. Kontrole zatwierdzeń są dostępne dla właścicieli zasobów w celu kontrolowania, kiedy etap w potoku zużywa zasób. Właściciele zasobów mogą definiować zatwierdzenia i kontrole, które muszą być spełnione przed rozpoczęciem etapu zużywania tego zasobu.
Role twórcy środowiska, administratora i użytkownika, ale nie roli Czytelnik, mogą zarządzać zatwierdzeniami i sprawdzaniem. Jako właściciel środowiska możesz ręcznie kontrolować, kiedy etap powinien być uruchamiany przy użyciu kontroli zatwierdzenia. Aby uzyskać więcej informacji, zobacz Definiowanie zatwierdzeń i kontroli.
Zobacz środowiska w szczegółach uruchamiania
Na karcie Środowiska szczegółów przebiegu potoku można wyświetlić wszystkie środowiska, które zostały objęte zadaniami wdrażania przebiegu potoku.
Uwaga
Jeśli używasz klastra prywatnego usługi Azure Kubernetes Service (AKS), karta Środowiska nie jest dostępna.
Wyświetlanie historii wdrażania
Możesz wybrać kartę Wdrożenia w sekcji Środowiska usługi Azure Pipelines, aby wyświetlić historię wdrażania.
Wyświetl zadania ze wszystkich potoków przeznaczonych dla określonego środowiska. Na przykład dwie mikrousługi, które mają własny potok, mogą być wdrażane w tym samym środowisku. Historia wdrażania pomaga zidentyfikować wszystkie potoki wpływające na środowisko, a także pomaga wizualizować sekwencję wdrożeń według każdego potoku.
Aby przejść do szczegółów zadania, wybierz karty Zmiany i Elementy robocze na stronie wdrożenia. Na kartach są wyświetlane listy zatwierdzeń i elementów roboczych wdrożonych w środowisku. Każdy element listy reprezentuje nowe elementy w tym wdrożeniu.
Na karcie Zmiany pierwsza lista zawiera wszystkie zatwierdzenia do tego punktu, a poniższe listy obejmują tylko zmiany dla tego zadania. Jeśli wiele zatwierdzeń jest powiązanych z tym samym zadaniem, na karcie Zmiany znajduje się wiele wyników.
Jeśli wiele elementów roboczych jest powiązanych z tym samym zadaniem, na karcie Elementy robocze znajduje się wiele wyników.
Zabezpieczenia
Środowiska można zabezpieczyć, ustawiając uprawnienia użytkownika i uprawnienia potoku.
Uprawnienia użytkownika
Możesz kontrolować, kto może tworzyć, wyświetlać, używać i zarządzać środowiskami z uprawnieniami użytkownika. Istnieją cztery role: Twórca z zakresem wszystkich środowisk, Czytelnik, Użytkownik i Administrator.
Aby dodać użytkownika przy użyciu panelu uprawnień użytkownika środowiska, przejdź do określonego środowiska, które chcesz autoryzować, wybierz ikonę Więcej akcji i wybierz pozycję Zabezpieczenia.
W panelu Uprawnienia użytkownika na stronie Zabezpieczenia wybierz pozycję Dodaj, a następnie wybierz użytkownika lub grupę i odpowiednią rolę.
W panelu Uprawnienia użytkownika można również ustawić uprawnienia, które są dziedziczone, i zastąpić role dla środowiska.
Rola | opis |
---|---|
Twórca | Rola globalna dostępna z opcji zabezpieczeń centrum środowisk. Członkowie tej roli mogą utworzyć środowisko w projekcie. Współautorzy są domyślnie dodawani jako członkowie. Wymagane do wyzwolenia potoku YAML, gdy środowisko jeszcze nie istnieje. |
Czytelnik | Członkowie tej roli mogą wyświetlać środowisko. |
Użytkownik | Członkowie tej roli mogą używać środowiska podczas tworzenia lub edytowania potoków YAML. |
Administrator | Członkowie tej roli mogą administrować uprawnieniami, tworzyć i wyświetlać środowiska oraz zarządzać nimi. W przypadku określonego środowiska jego twórca jest domyślnie dodawany jako administrator. Administratorzy mogą również otwierać dostęp do środowiska do wszystkich potoków. |
Ważne
Podczas tworzenia środowiska tylko twórca ma rolę administratora.
Rola | opis |
---|---|
Twórca | Rola globalna dostępna z opcji zabezpieczeń centrum środowisk. Członkowie tej roli mogą utworzyć środowisko w projekcie. Współautorzy są domyślnie dodawani jako członkowie. Wymagane do wyzwolenia potoku YAML, gdy środowisko jeszcze nie istnieje. |
Czytelnik | Członkowie tej roli mogą wyświetlać środowisko. |
Użytkownik | Członkowie tej roli mogą używać środowiska podczas tworzenia lub edytowania potoków YAML. |
Administrator | Oprócz korzystania ze środowiska członkowie tej roli mogą zarządzać członkostwem wszystkich innych ról w środowisku. Twórcy są domyślnie dodawani jako członkowie. |
Uprawnienia potoku
Użyj panelu Uprawnienia potoku na stronie Zabezpieczenia, aby autoryzować wszystkie lub wybrane potoki do wdrożenia w środowisku.
Aby usunąć otwarty dostęp w środowisku lub zasobie, wybierz pozycję Ogranicz uprawnienia w obszarze Uprawnienia potoku.
Jeśli uprawnienia są ograniczone, można zezwolić określonym potokom na wdrażanie w środowisku lub w określonym zasobie. Wybierz + i wybierz z listy potoków, które mają być dozwolone.
Często zadawane pytania
Dlaczego podczas próby utworzenia środowiska pojawia się komunikat o błędzie?
Jeśli zostanie wyświetlony komunikat Odmowa dostępu: użytkownik {Użytkownik} musi mieć uprawnienia Utwórz, aby wykonać akcję, przejdź do pozycji Użytkownicy ustawień>organizacji, aby sprawdzić, czy masz rolę uczestnik projektu. Rola uczestnika projektu nie może tworzyć środowisk, ponieważ uczestnicy projektu nie mają dostępu do repozytorium.
Zmień swój poziom dostępu, a następnie sprawdź, czy możesz tworzyć środowiska. Aby uzyskać więcej informacji, zobacz Często zadawane pytania dotyczące zarządzania użytkownikami i uprawnieniami.
Dlaczego występuje błąd mówiący, że nie można odnaleźć środowiska?
Jeśli zostanie wyświetlony komunikat Job XXXX: Environment XXXX nie można odnaleźć. Środowisko nie istnieje lub nie zostało autoryzowane do użycia. Istnieje kilka możliwych przyczyn awarii.
Parametry środowiska uruchomieniowego nie działają podczas tworzenia środowisk, ponieważ parametry są rozszerzane tylko w czasie wykonywania. Możesz użyć zmiennych, aby utworzyć środowisko lub użyć templateContext, aby przekazać właściwości do szablonów.
Usługa Azure Pipelines może nie zawierać informacji o użytkowniku tworzącym środowisko.
Gdy odwołujesz się do środowiska, które nie istnieje w pliku potoku YAML, usługa Azure Pipelines w następujących przypadkach automatycznie tworzy środowisko:
- Używasz kreatora tworzenia potoku YAML w środowisku internetowym usługi Azure Pipelines i odwołujesz się do środowiska, które nie zostało jeszcze utworzone.
- Aktualizujesz plik YAML, używając edytora internetowego usługi Azure Pipelines, i zapisujesz potok po dodaniu odwołania do środowiska.
W następujących przypadkach usługa Azure Pipelines nie ma informacji o użytkowniku tworzącym środowisko, więc potok kończy się niepowodzeniem.
- Aktualizujesz plik YAML przy użyciu innego zewnętrznego edytora kodu.
- Dodajesz odwołanie do środowiska, które nie istnieje, a następnie wywołujesz wyzwalanie potoku ręcznej lub ciągłej integracji.
Wcześniej usługa Azure Pipelines radziła sobie z tymi przypadkami tak, że dodawała wszystkich współautorów projektu do roli administratora środowiska. Każdy członek projektu mógł wtedy zmieniać te uprawnienia i uniemożliwiać innym dostęp do środowiska. Aby zapobiec temu wynikowi, usługa Azure Pipelines kończy się teraz niepowodzeniem tych zadań.