Zarządzanie wydaniem programu Helm

Ukończone

Jak używać funkcji w szablonie programu Helm

Język szablonu programu Helm definiuje funkcje, których można użyć do przekształcenia wartości z pliku values.yaml. Składnia funkcji jest zgodna ze strukturą {{ nazwaFunkcji arg1 arg2 ... }}. Przyjrzyjmy się na przykład funkcji quote, aby zobaczyć tę składnię w działaniu.

Funkcja quote zawija wartość w znaki cudzysłowu, aby wskazać użycie string. Załóżmy, że zdefiniujesz następujący values.yaml plik:

apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
  enabled: true

Decydujesz się użyć wartości ingress.enabled jako wartości logicznej podczas określania, czy należy wygenerować manifest ruchu przychodzącego. Aby użyć wartości enabled jako wartości logicznej, należy odwołać się do wartości przy użyciu elementu {{ .Values.ingress.enabled }}.

Później można wyświetlić pole jako ciąg w pliku templates/Notes.txt. Ponieważ reguły wymuszania typu YAML mogą prowadzić do trudnego do znalezienia usterek w szablonach, decydujesz się postępować zgodnie ze wskazówkami i być jawne w przypadku dołączania ciągów w szablonach. Na przykład enabled: false nie jest równe enabled: "false".

Aby wyświetlić wartość jako ciąg, użyj elementu {{ quote .Values.ingress.enabled }}, aby odwołać się do wartości logicznej jako ciągu.

Jak używać potoków w szablonie programu Helm

Potoki są używane, gdy więcej niż jedna funkcja musi działać na danej wartości. Potok umożliwia wysyłanie wartości lub wyniku funkcji do innej funkcji. Na przykład można ponownie napisać powyższą funkcję quote jako {{ .Values.ingress.enabled | quote }}. Zwróć uwagę, jak | wskazuje, że wartość jest wysyłana do funkcji quote.

Oto kolejny przykład. Załóżmy, że chcesz przekonwertować wartość na wielkie litery i opakować ją w cudzysłów. Można napisać instrukcję jako {{ .Values.ingress.enabled | upper | quote }}. Zwróć uwagę, jak wartość jest przetwarzana przez funkcję upper, a następnie funkcję quote.

Język szablonu zawiera ponad 60 funkcji, które umożliwiają udostępnianie, wyszukiwanie i przekształcanie wartości oraz obiektów w szablonach.

Jak używać kontroli przepływu warunkowego w szablonie programu Helm

Warunkowa kontrola przepływu pozwala określić strukturę lub dane zawarte w wygenerowanym pliku manifestu. Na przykład możesz chcieć uwzględnić różne wartości na podstawie celu wdrożenia lub kontrolki, jeśli zostanie wygenerowany plik manifestu.

Blok if / else jest taką strukturą przepływu sterowania i jest zgodny z następującym układem:

{{ if | pipeline | }}
  # Do something
{{ else if | other pipeline | }}
  # Do something else
{{ else }}
  # Default case
{{ end }}

Załóżmy, że decydujesz, że plik manifestu ruchu przychodzącego dla wykresu jest tworzony tylko w określonych przypadkach. W poniższym przykładzie pokazano, jak to osiągnąć przy użyciu instrukcji if :

{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{ end }}

Pamiętaj, że możesz użyć symboli zastępczych, aby wypełnić metadane w szablonie. Pliki szablonów są analizowane i oceniane sekwencyjnie przez język szablonu od góry do dołu. W poprzednim przykładzie aparat szablonu generuje zawartość pliku manifestu tylko wtedy, gdy .Values.ingress.enabled wartość to true.

Gdy aparat szablonów przetwarza instrukcję, usuwa zawartość zadeklarowaną wewnątrz {{ }} składni i pozostawia pozostałe odstępy. Ta składnia powoduje, że aparat szablonów dołącza nowy wiersz do wiersza instrukcji if. Jeśli pozostawisz zawartość poprzedniego pliku w następujący sposób, zauważysz puste wiersze w pliku YAML, a plik manifestu ruchu przychodzącego zostanie wygenerowany.

Kod YAML nadaje odstępowi znaczenie. Dlatego karty, spacje i znaki nowego wiersza są uważane za ważne. Aby rozwiązać problem z niechcianym odstępem, można zapisać ponownie plik w następujący sposób:

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{- end }}

Zwróć uwagę na użycie znaku - w ramach początkowej {{- i końcowej -}} sekwencji instrukcji. Znak - nakazuje analizatorowi usunięcie znaków odstępów. Instrukcja {{- usuwa odstęp na początku wiersza, a instrukcja -}} na końcu wiersza, w tym znak nowego wiersza.

Jak iterować po kolekcji wartości w szablonie programu Helm

Kod YAML umożliwia definiowanie kolekcji elementów i używanie poszczególnych elementów jako wartości w szablonach. Uzyskiwanie dostępu do elementów w kolekcji jest możliwe za pomocą indeksatora. Jednak język szablonu usługi Helm obsługuje iterację kolekcji wartości przy użyciu operatora range.

Załóżmy, że zdefiniujesz listę wartości w values.yaml pliku, aby wskazać dodatkowe hosty ruchu przychodzącego. Oto przykład wartości:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

Używasz operatora zakresu, aby umożliwić aparatowi szablonów iteracyjne przejście przez kolekcję .Values.ingress.extraHosts. Poniższy fragment kodu przedstawia skrócony przykład użycia range operatora :

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  ...
spec:
  rules:
    ...
    {{- range .Values.ingress.extraHosts }}
    - host: {{ .name }}
      http:
        paths:
          - path: {{ .path }}
            ...
    {{- end }}
  ...
{{- end }}

Jak kontrolować zakres wartości w szablonie programu Helm

Jeśli masz zdefiniowane kilka warstw głęboko, składnia może stać się długotrwała i kłopotliwa podczas dołączania tych wartości w szablonie. Akcja with umożliwia ograniczenie zakresu zmiennych w szablonie.

Pamiętaj, że . używany w szablonie programu Helm odwołuje się do bieżącego zakresu. Na przykład polecenie .Values instruuje aparat szablonów, aby znalazł obiekt Values wartości w bieżącym zakresie. Załóżmy, że używasz pliku z wcześniejszej wersji, aby utworzyć plik manifestu values.yaml mapy konfiguracji:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

Zamiast uzyskiwać dostęp do wartości ścieżki poszczególnych elementów przy użyciu instrukcji {{ .Values.ingress.extraHosts.path }}, można użyć akcji with. Poniższy fragment kodu przedstawia przykład użycia range operatora do wygenerowania pliku manifestu mapy konfiguracji:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  {{ end }}

Zapis {{- with .Values.ingress.extraHosts }} ogranicza zakres wartości do tablicy .Values.ingress.extraHosts.

Akcja with ogranicza zakres. Nie można uzyskiwać dostępu do innych obiektów z zakresu nadrzędnego. Załóżmy, że chcesz również uzyskać dostęp do {{ .Release.Name }} wykresu w with bloku kodu. Aby uzyskać dostęp do obiektów nadrzędnych, należy wskazać zakres główny przy użyciu znaku $ lub napisać ponownie kod. Oto zaktualizowany kod pokazujący sposób dołączania obiektów nadrzędnych przy użyciu $ znaku:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  release: {{ $.Release.Name}}
  {{ end }}

Uwaga

W języku szablonów usługi Helm jest dostępnych kilka konstrukcji do sterowania przepływem. Jednostka podsumowania tego modułu obejmuje sekcję zawierającą linki do dokumentacji usługi Helm, co pozwala dowiedzieć się więcej.

How to Helm define chart dependencies (Jak zdefiniować zależności wykresu)

Wykres umożliwia deklarowanie zależności do obsługi głównej aplikacji i składnika formularzy zainstalowanego wydania.

A diagram shows how Helm deploys all subcharts as dependencies of the main chart to a Kubernetes cluster.

Można utworzyć wykres podrzędny przy użyciu polecenia helm create, określając lokalizację nowego wykresu w folderze /charts, lub użyć polecenia helm dependency. Pamiętaj, że /charts folder może zawierać podcharty wdrożone w ramach wydania wykresu głównego.

Polecenie helm dependency umożliwia zarządzanie zależnościami zawartymi w repozytorium usługi Helm. Polecenie używa metadanych zdefiniowanych w sekcji dependencies pliku wartości wykresu. Należy określić nazwę, numer wersji i repozytorium, z którego ma zostać zainstalowany schemat podrzędny. Oto wyodrębnienie values.yaml pliku, który ma wykres MongoDB wymieniony jako zależność:

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
...
dependencies:
  - name: mongodb
    version: 10.27.2
    repository: https://marketplace.azurecr.io/helm/v1/repo

Po zdefiniowaniu metadanych zależności uruchom polecenie helm dependency build, aby pobrać wykres w pakiecie tar. Polecenie kompilowania wykresu pobiera wykres do folderu charts/.

helm dependency build ./app-chart

Wykresy podrzędne są zarządzane oddzielnie od wykresu głównego i mogą wymagać aktualizacji, gdy nowe wersje staną się dostępne. Polecenie aktualizowania wykresów podrzędnych to helm dependency update. To polecenie pobiera nowe wersje schematu podrzędnego podczas usuwania nieaktualnych pakietów.

helm dependency update ./app-chart

Należy pamiętać, że zależność wykresu nie jest ograniczona do innych aplikacji. Możesz zdecydować się na ponowne użycie logiki szablonu na wykresach i utworzenie zależności w szczególności w celu zarządzania tą logiką jako zależnością wykresu. W następnym ćwiczeniu uzyskasz przykład tej strategii.

Jak uaktualnić wydanie usługi Helm

Usługa Helm umożliwia uaktualnienie istniejących wydań jako różnicy wszystkich zmian, które są stosowane do wykresu i jego zależności.

A diagram shows how the Helm upgrade command creates a delta of all changed items in a Helm chart to upgrade a release and create a new release revision on a Kubernetes cluster.

Załóżmy na przykład, że zespół deweloperów przykładu webapp w tej lekcji wprowadza zmiany kodu, które mają wpływ tylko na funkcjonalność witryny internetowej. Zespół wprowadza następujące aktualizacje do Chart.yaml pliku w celu odzwierciedlenia nowej wersji aplikacji:

  • Aktualizacje obraz kontenera aplikacji internetowej i taguje obraz jako webapp: linux-v2 podczas wypychania obrazu do rejestru kontenerów.
  • Aktualizacje wartość parametru dockerTag linux-v2 i wartość wersji wykresu na 0.2.0 wartość w pliku wartości wykresu.

Oto przykład zaktualizowanego values.yaml pliku:

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes

type: application

version: 0.2.0
appVersion: 1.0.0

registry: "my-acr-registry.azurecr.io"
dockerTag: "linux-v2"
pullPolicy: "Always"

Zamiast odinstalować bieżącą wersję, użyj helm upgrade polecenia , aby uaktualnić istniejącą wersję programu Helm.

helm upgrade my-app ./app-chart

Pamiętaj, że program Helm generuje różnicę zmian wprowadzonych na wykresie programu Helm podczas uaktualniania wydania. W związku z tym uaktualnienie programu Helm uaktualnia tylko składniki zidentyfikowane w delcie. W tym przykładzie tylko witryna internetowa jest wdrażana ponownie.

Po zakończeniu uaktualniania możesz przejrzeć historię wdrażania wydania przy użyciu helm history polecenia z nazwą wydania.

helm history my-app

Polecenie history zwraca kilka pól opisujących wydanie, jak pokazano w poniższych przykładowych danych wyjściowych:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        deployed        aspnet-core-1.3.18      3.1.19          Install complete

Zwróć uwagę na pole revision w wyniku. Usługa Helm śledzi informacje o wszystkich wydaniach wykonanych dla wykresu usługi Helm. Po zainstalowaniu nowej wersji wykresu usługi Helm liczba poprawek wzrasta o jeden, a informacje o nowym wydaniu są dopasowywane do tej poprawki.

Oto przykład tego samego polecenia historii, które jest uruchamiane po zainstalowaniu nowej wersji aplikacji internetowej:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

Jak wycofać wydanie usługi Helm

Usługa Helm umożliwia wycofanie istniejącego wydania usługi Helm do wcześniej zainstalowanego wydania. Przypomnij sobie wcześniej, że program Helm śledzi informacje o wydaniu wszystkich wydań wykresu programu Helm.

Użyj polecenia helm rollback, aby wrócić do określonej poprawki wydania usługi Helm. To polecenie używa dwóch parametrów. Pierwszy parametr określa nazwę wydania, a drugi identyfikuje numer poprawki wydania.

helm rollback my-app 2

Polecenie helm rollback przywraca wersję wydania aplikacji do określonej poprawki i aktualizuje historię wydania aplikacji. Kolejne uruchomienie polecenia powoduje wyświetlenie najnowszego helm history aktywnego numeru poprawki jako najnowszego wpisu wydania.

Załóżmy na przykład, że zespół deweloperów przykładu webapp w tej lekcji wykryje usterkę w aplikacji internetowej do śledzenia dronów i musi wrócić do poprzedniej wersji. Zamiast odinstalować bieżącą wersję i zainstalować poprzednią wersję, są one przywracane do działającej wersji.

helm rollback my-app 1

Po zakończeniu wycofywania możesz przejrzeć historię wdrażania przy użyciu helm history polecenia .

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        superseded      aspnet-core-1.3.18      3.1.19          Rolled back to 1
3               Mon Oct 11 17:38:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

Zwróć uwagę, jak w polu opisu jest wyświetlany numer poprawki wycofywania, aby ułatwić śledzenie zmian.

Sprawdź swoją wiedzę

1.

Załóżmy, że masz rozwiązanie programowe z dwoma krytycznymi składnikami: aplikacją internetową i usługą przetwarzającą zamówienia online. Oba składniki są częścią potoku przetwarzania zamówień online, ale nie mają zależności od siebie. Która strategia najlepiej pasuje do wdrożenia tych dwóch aplikacji przy użyciu programu Helm?

2.

Załóżmy, że masz rozwiązanie programowe, które ma witrynę internetową jako jeden z jego krytycznych składników. Witryna internetowa jest jedynym składnikiem, który zależy od usługi buforowania. Która strategia najlepiej pasuje do wdrożenia tych dwóch aplikacji przy użyciu programu Helm?