Obsługiwane parametry usługi GitOps (Flux v2)
Platforma Azure udostępnia funkcję wdrażania aplikacji automatycznych przy użyciu metodyki GitOps, która współpracuje z usługą Azure Kubernetes Service (AKS) i klastrami Kubernetes z obsługą usługi Azure Arc. Metodyka GitOps z rozwiązaniem Flux w wersji 2 umożliwia używanie repozytorium Git jako źródła prawdy na potrzeby konfiguracji klastra i wdrażania aplikacji. Aby uzyskać więcej informacji, zobacz Wdrażanie aplikacji przy użyciu metodyki GitOps (Flux v2) i Samouczek: wdrażanie aplikacji przy użyciu metodyki GitOps z rozwiązaniem Flux w wersji 2.
Usługa GitOps na platformie Kubernetes z włączoną usługą Azure Arc lub Azure Kubernetes Service korzysta z platformy Flux, popularnego zestawu narzędzi typu open source obsługującego wiele parametrów w celu włączenia różnych scenariuszy. Opis wszystkich parametrów obsługiwanych przez platformę Flux można znaleźć w oficjalnej dokumentacji platformy Flux.
Aby wyświetlić wszystkie parametry obsługiwane przez platformę Flux na platformie Azure, zobacz dokumentacjęaz k8s-configuration
. Ta implementacja nie obsługuje obecnie każdego parametru obsługiwanego przez platformę Flux. Poinformuj nas, czy w implementacji platformy Azure brakuje parametru, którego potrzebujesz.
W tym artykule opisano niektóre parametry i argumenty dostępne dla az k8s-configuration flux create
polecenia. Pełną listę parametrów parametrów można az k8s-configuration flux
również wyświetlić przy użyciu parametru -h
w interfejsie wiersza polecenia platformy Azure (na przykład az k8s-configuration flux -h
lub az k8s-configuration flux create -h
).
Napiwek
Obejściem wdrażania zasobów Platformy Flux z nieobsługiwanymi parametrami jest zdefiniowanie wymaganych zasobów niestandardowych Flux (takich jak GitRepository lub Kustomization) w repozytorium Git. Wdróż te zasoby za az k8s-configuration flux create
pomocą polecenia . Następnie nadal będziesz mieć dostęp do zasobów platformy Flux za pośrednictwem interfejsu użytkownika usługi Azure Arc.
Ogólne argumenty konfiguracji
Parametr | Format | Uwagi |
---|---|---|
--cluster-name -c |
String | Nazwa zasobu klastra na platformie Azure. |
--cluster-type -t |
Dozwolone wartości: connectedClusters , managedClusters |
Służy connectedClusters do obsługi klastrów Kubernetes z obsługą usługi Azure Arc lub managedClusters klastrów usługi AKS. |
--resource-group -g |
String | Nazwa grupy zasobów platformy Azure, która zawiera zasób klastra. |
--name -n |
String | Nazwa konfiguracji platformy Flux na platformie Azure. |
--namespace --ns |
String | Nazwa przestrzeni nazw do wdrożenia konfiguracji. Wartość domyślna: default . |
--scope -s |
String | Zakres uprawnień dla operatorów. Możliwe wartości to cluster (pełny dostęp) lub namespace (ograniczony dostęp). Wartość domyślna: cluster . |
--suspend |
flag | Zawiesza wszystkie uzgodnienia źródła i kustomize zdefiniowane w tej konfiguracji platformy Flux. Uzgodnienia aktywne w momencie zawieszenia będą kontynuowane. |
Argumenty ogólne źródła
Parametr | Format | Uwagi |
---|---|---|
--kind |
String | Rodzaj źródła do uzgodnienia. Dozwolone wartości: bucket , git , azblob . Wartość domyślna: git . |
--timeout |
format czasu trwania języka golang | Maksymalny czas próby uzgodnienia źródła przed przekroczeniem limitu czasu. Wartość domyślna: 10m . |
--sync-interval --interval |
format czasu trwania języka golang | Czas między uzgodnieniami źródła w klastrze. Wartość domyślna: 10m . |
Argumenty referencyjne źródła repozytorium Git
Parametr | Format | Uwagi |
---|---|---|
--branch |
String | Gałąź w źródle usługi Git, aby przeprowadzić synchronizację z klastrem. Wartość domyślna: master . Nowsze repozytoria mogą mieć gałąź główną o nazwie main , w tym przypadku należy ustawić .--branch=main |
--tag |
String | Tag w źródle usługi Git w celu synchronizacji z klastrem. Przykład: --tag=3.2.0 . |
--semver |
String | Zakres tagów semver Git w źródle usługi Git do synchronizacji z klastrem. Przykład: --semver=">=3.1.0-rc.1 <3.2.0" . |
--commit |
String | Zatwierdź sha usługi Git w źródle usługi Git, aby przeprowadzić synchronizację z klastrem. Przykład: --commit=363a6a8fe6a7f13e05d34c163b0ef02a777da20a . |
Aby uzyskać więcej informacji, zobacz dokumentację platformy Flux dotyczącą strategii wyewidencjonowania repozytorium Git.
Publiczne repozytorium Git
Parametr | Format | Uwagi |
---|---|---|
--url -u |
http[s]://server/repo[.git] |
Adres URL źródła repozytorium Git w celu uzgodnienia z klastrem. |
Prywatne repozytorium Git z protokołem SSH
Ważne
Usługa Azure DevOps ogłosiła wycofanie protokołu SSH-RSA jako obsługiwanej metody szyfrowania na potrzeby nawiązywania połączenia z repozytoriami platformy Azure przy użyciu protokołu SSH. Jeśli używasz kluczy SSH do nawiązywania połączenia z repozytoriami platformy Azure w konfiguracjach platformy Flux, zalecamy przejście do bezpieczniejszych kluczy RSA-SHA2-256 lub RSA-SHA2-512. Aby uzyskać więcej informacji, zobacz Wycofanie usługi Azure DevOps SSH-RSA.
Prywatne repozytorium Git z kluczami utworzonymi przez protokół SSH i flux
Dodaj klucz publiczny wygenerowany przez narzędzie Flux do konta użytkownika u dostawcy usług Git.
Parametr | Format | Uwagi |
---|---|---|
--url -u |
ssh://user@server/repo[.git] |
git@ element powinien zostać zastąpiony user@ , jeśli klucz publiczny jest skojarzony z repozytorium zamiast konta użytkownika. |
Prywatne repozytorium Git z kluczami SSH i kluczami udostępnianymi przez użytkownika
Użyj własnego klucza prywatnego bezpośrednio lub z pliku. Klucz musi być w formacie PEM i kończyć się nowym wierszem (\n
).
Dodaj skojarzony klucz publiczny do konta użytkownika u dostawcy usług Git.
Parametr | Format | Uwagi |
---|---|---|
--url -u |
ssh://user@server/repo[.git] | git@ element powinien zostać zastąpiony user@ , jeśli klucz publiczny jest skojarzony z repozytorium zamiast konta użytkownika. |
--ssh-private-key |
Klucz Base64 w formacie PEM | Podaj klucz bezpośrednio. |
--ssh-private-key-file |
Pełna ścieżka do pliku lokalnego | Podaj pełną ścieżkę do pliku lokalnego, który zawiera klucz formatu PEM. |
Prywatny host Git z protokołem SSH i hostami znanymi przez użytkownika
Operator Flux utrzymuje listę typowych hostów Git w swoim known_hosts
pliku. Platforma Flux używa tych informacji do uwierzytelniania repozytorium Git przed nawiązaniem połączenia SSH. Jeśli używasz nietypowego repozytorium Git lub własnego hosta Git, możesz podać klucz hosta, aby platforma Flux mogła zidentyfikować repozytorium.
Podobnie jak w przypadku kluczy prywatnych, zawartość known_hosts
możesz podać bezpośrednio lub w pliku. Jeśli udostępniasz własną zawartość, użyj specyfikacji formatu zawartości known_hosts wraz z jednym z powyższych scenariuszy klucza SSH.
Parametr | Format | Uwagi |
---|---|---|
--url -u |
ssh://user@server/repo[.git] | git@ program może zastąpić user@ element . |
--known-hosts |
Ciąg base64 | Podaj known_hosts zawartość bezpośrednio. |
--known-hosts-file |
Pełna ścieżka do pliku lokalnego | Podaj known_hosts zawartość w pliku lokalnym. |
Prywatne repozytorium Git z użytkownikiem i kluczem HTTPS
Parametr | Format | Uwagi |
---|---|---|
--url -u |
https://server/repo[.git] |
Protokół HTTPS z uwierzytelnianiem podstawowym. |
--https-user |
Nieprzetworzone ciągi | Nazwa użytkownika HTTPS. |
--https-key |
Nieprzetworzone ciągi | Osobisty token dostępu https lub hasło. |
Prywatne repozytorium Git z certyfikatem urzędu certyfikacji HTTPS
Parametr | Format | Uwagi |
---|---|---|
--url -u |
https://server/repo[.git] |
Protokół HTTPS z uwierzytelnianiem podstawowym. |
--https-ca-cert |
Ciąg base64 | Certyfikat urzędu certyfikacji na potrzeby komunikacji TLS. |
--https-ca-cert-file |
Pełna ścieżka do pliku lokalnego | Podaj zawartość certyfikatu urzędu certyfikacji w pliku lokalnym. |
Argumenty źródła zasobnika
Jeśli używasz bucket
źródła, oto argumenty poleceń specyficznych dla zasobnika.
Parametr | Format | Uwagi |
---|---|---|
--url -u |
Ciąg adresu URL | Adres URL dla elementu bucket . Obsługiwane formaty: http:// , https:// . |
--bucket-name |
String | Nazwa synchronizacji bucket . |
--bucket-access-key |
String | Identyfikator klucza dostępu używany do uwierzytelniania za pomocą polecenia bucket . |
--bucket-secret-key |
String | Klucz tajny używany do uwierzytelniania za pomocą polecenia bucket . |
--bucket-insecure |
Wartość logiczna | Komunikacja bez bucket protokołu TLS. Jeśli nie zostanie podana, przyjęto wartość false; jeśli zostanie podana wartość true, zakłada się, że wartość true. |
Argumenty źródłowe konta usługi Azure Blob Storage
Jeśli używasz azblob
źródła, oto argumenty poleceń specyficznych dla obiektu blob.
Parametr | Format | Uwagi |
---|---|---|
--url -u |
Ciąg adresu URL | Adres URL dla elementu azblob . |
--container-name |
String | Nazwa kontenera usługi Azure Blob Storage do synchronizacji |
--sp_client_id |
String | Identyfikator klienta do uwierzytelniania jednostki usługi za pomocą obiektu blob platformy Azure, wymagany dla tej metody uwierzytelniania |
--sp_tenant_id |
String | Identyfikator dzierżawy do uwierzytelniania jednostki usługi za pomocą obiektu blob platformy Azure wymagany dla tej metody uwierzytelniania |
--sp_client_secret |
String | Wpis tajny klienta do uwierzytelniania jednostki usługi za pomocą obiektu blob platformy Azure |
--sp_client_cert |
String | Certyfikat klienta zakodowany w formacie Base64 na potrzeby uwierzytelniania jednostki usługi za pomocą usługi Azure Blob |
--sp_client_cert_password |
String | Hasło certyfikatu klienta używanego do uwierzytelniania jednostki usługi za pomocą obiektu blob platformy Azure |
--sp_client_cert_send_chain |
String | Określa, czy należy uwzględnić nagłówek x5c w oświadczeniach klienta podczas uzyskiwania tokenu w celu włączenia uwierzytelniania opartego na nazwie podmiotu/wystawcy dla certyfikatu klienta |
--account_key |
String | Klucz współużytkowany obiektu blob platformy Azure na potrzeby uwierzytelniania |
--sas_token |
String | Token SAS usługi Azure Blob na potrzeby uwierzytelniania |
--managed-identity-client-id |
String | Identyfikator klienta tożsamości zarządzanej na potrzeby uwierzytelniania za pomocą usługi Azure Blob |
Ważne
W przypadku korzystania z uwierzytelniania tożsamości zarządzanej dla klastrów i azblob
źródeł usługi AKS tożsamość zarządzana musi być przypisana co najmniej do roli Czytelnik danych obiektu blob usługi Storage. Uwierzytelnianie przy użyciu tożsamości zarządzanej nie jest jeszcze dostępne dla klastrów Kubernetes z obsługą usługi Azure Arc.
Lokalny wpis tajny na potrzeby uwierzytelniania za pomocą źródła
Możesz użyć lokalnego wpisu tajnego kubernetes do uwierzytelniania za pomocą git
bucket
elementu lub azBlob
źródła. Lokalny wpis tajny musi zawierać wszystkie parametry uwierzytelniania wymagane dla źródła i muszą zostać utworzone w tej samej przestrzeni nazw co konfiguracja platformy Flux.
Parametr | Format | Uwagi |
---|---|---|
--local-auth-ref --local-ref |
String | Lokalne odwołanie do wpisu tajnego platformy Kubernetes w przestrzeni nazw konfiguracji platformy Flux do użycia do uwierzytelniania ze źródłem. |
W przypadku uwierzytelniania HTTPS należy utworzyć wpis tajny z elementami username
i :password
kubectl create ns flux-config
kubectl create secret generic -n flux-config my-custom-secret --from-literal=username=<my-username> --from-literal=password=<my-password-or-key>
W przypadku uwierzytelniania SSH utworzysz wpis tajny z polami identity
i known_hosts
:
kubectl create ns flux-config
kubectl create secret generic -n flux-config my-custom-secret --from-file=identity=./id_rsa --from-file=known_hosts=./known_hosts
Ważne
Usługa Azure DevOps ogłosiła wycofanie protokołu SSH-RSA jako obsługiwanej metody szyfrowania na potrzeby nawiązywania połączenia z repozytoriami platformy Azure przy użyciu protokołu SSH. Jeśli używasz kluczy SSH do nawiązywania połączenia z repozytoriami platformy Azure w konfiguracjach platformy Flux, zalecamy przejście do bezpieczniejszych kluczy RSA-SHA2-256 lub RSA-SHA2-512. Aby uzyskać więcej informacji, zobacz Wycofanie usługi Azure DevOps SSH-RSA.
W obu przypadkach podczas tworzenia konfiguracji platformy Flux należy użyć --local-auth-ref my-custom-secret
zamiast innych parametrów uwierzytelniania:
az k8s-configuration flux create -g <cluster_resource_group> -c <cluster_name> -n <config_name> -t connectedClusters --scope cluster --namespace flux-config -u <git-repo-url> --kustomization name=kustomization1 --local-auth-ref my-custom-secret
Dowiedz się więcej o korzystaniu z lokalnego wpisu tajnego kubernetes z następującymi metodami uwierzytelniania:
- Uwierzytelnianie HTTPS w repozytorium Git
- Certyfikaty z podpisem własnym protokołu HTTPS w repozytorium Git
- Uwierzytelnianie SSH w repozytorium Git
- Uwierzytelnianie statyczne zasobnika
Uwaga
Jeśli potrzebujesz usługi Flux, aby uzyskać dostęp do źródła za pośrednictwem serwera proxy, musisz zaktualizować agentów usługi Azure Arc przy użyciu ustawień serwera proxy. Aby uzyskać więcej informacji, zobacz Nawiązywanie połączenia przy użyciu serwera proxy ruchu wychodzącego.
Implementacja usługi Git
Aby obsługiwać różnych dostawców repozytorium implementujących usługę Git, można skonfigurować platformę Flux do używania jednej z dwóch bibliotek Git: go-git
lub libgit2
. Aby uzyskać szczegółowe informacje, zobacz dokumentację platformy Flux.
Implementacja usługi GitOps platformy Flux w wersji 2 automatycznie określa bibliotekę do użycia w repozytoriach chmury publicznej:
- W przypadku repozytoriów GitHub, GitLab i BitBucket platforma Flux używa polecenia
go-git
. - W przypadku usługi Azure DevOps i wszystkich innych repozytoriów platforma Flux używa polecenia
libgit2
.
W przypadku repozytoriów lokalnych platforma Flux używa polecenia libgit2
.
Kustomization
Kustomization to ustawienie utworzone dla konfiguracji platformy Flux, które umożliwia wybranie określonej ścieżki w repozytorium źródłowym uzgadnianym z klastrem. Nie musisz tworzyć pliku "kustomization.yaml" w tej określonej ścieżce. Domyślnie wszystkie manifesty w tej ścieżce są uzgadniane. Jeśli jednak chcesz mieć nakładkę Kustomize dla aplikacji dostępnych w tej ścieżce repozytorium, należy utworzyć pliki Kustomize w narzędziu git, aby konfiguracja platformy Flux korzystała z usługi.
Za pomocą polecenia az k8s-configuration flux kustomization create
można utworzyć co najmniej jeden element kustomization podczas konfiguracji.
Parametr | Format | Uwagi |
---|---|---|
--kustomization |
Brak wartości | Początek ciągu parametrów, które konfigurują kustomization. Można użyć go wiele razy, aby utworzyć wiele kustomizations. |
name |
String | Unikatowa nazwa dla tej kustomyzacji. |
path |
String | Ścieżka w repozytorium Git w celu uzgodnienia z klastrem. Wartość domyślna to najwyższy poziom gałęzi. |
prune |
Wartość logiczna | Wartość domyślna to false . Ustaw prune=true wartość , aby upewnić się, że obiekty wdrożone w klastrze flux są czyszczone, jeśli zostaną usunięte z repozytorium lub jeśli konfiguracja lub kustomizations flux zostaną usunięte. Użycie prune=true jest ważne w środowiskach, w których użytkownicy nie mają dostępu do klastrów i mogą wprowadzać zmiany tylko za pośrednictwem repozytorium Git. |
depends_on |
String | Nazwa co najmniej jednej kustomyzacji (w ramach tej konfiguracji), która musi uzgodnić, zanim będzie można uzgodnić tę konfigurację kustomizacji. Na przykład: depends_on=["kustomization1","kustomization2"] . Jeśli usuniesz kustomizację, która ma zależne kustomizations, stan zależnych kustomizations DependencyNotReady stanie się , a uzgadnianie zostanie zatrzymane. |
timeout |
format czasu trwania języka golang | Wartość domyślna: 10m . |
sync_interval |
format czasu trwania języka golang | Wartość domyślna: 10m . |
retry_interval |
format czasu trwania języka golang | Wartość domyślna: 10m . |
validation |
String | Wartości: none , , server client . Wartość domyślna: none . Aby uzyskać szczegółowe informacje, zobacz dokumentację platformy Flux. |
force |
Wartość logiczna | Wartość domyślna: false . Ustaw force=true polecenie, aby kontroler kustomize ponownie utworzyć zasoby w przypadku niepowodzenia stosowania poprawek z powodu niezmiennej zmiany pola. |
Można również użyć az k8s-configuration flux kustomization
polecenia , aby zaktualizować, wyświetlić i usunąć kustomizations w konfiguracji platformy Flux.
Następne kroki
- Dowiedz się więcej o wdrożeniach aplikacji przy użyciu usługi GitOps (Flux v2) dla usług AKS i Kubernetes z obsługą usługi Azure Arc.
- Skorzystaj z naszego samouczka, aby dowiedzieć się, jak włączyć metodykę GitOps w klastrach Kubernetes z włączoną usługą AKS lub Azure Arc.
- Dowiedz się więcej o przepływie pracy ciągłej integracji/ciągłego wdrażania przy użyciu metodyki GitOps.