Apps für die Wiederverwendung in mehreren Umgebungen mit Kustomize paketieren

Als Teil einer Cloud-nativen App mit zwölf Faktoren möchten Sie die dev-to-prod-Parität beibehalten, indem Sie eine kontinuierliche Entwicklungs- und Bereitstellungspipeline einrichten, die eine gemeinsame, versionskontrollierte Codebasisquelle verwendet. In Ihren Code-Basis-Repositorys speichern Sie Ihre Kubernetes-Ressourcenkonfigurationsmanifestdateien, oft im YAML-Format. Sie können das Projekt Kubernetes Kustomize sowohl zur Standardisierung als auch zur Anpassung Ihrer Einsätze in verschiedenen Umgebungen nutzen.

Sie können beispielsweise eine Basis-YAML-Datei kustomization einrichten, um Kubernetes-Objekte wie Bereitstellungen und PVCs zu deklarieren, die in Ihren Entwicklungs-, Test- und Produktionsumgebungen gemeinsam genutzt werden. Als Nächstes können Sie separate kustomization-YAML-Dateien einrichten, die für jede Umgebung angepasste Konfigurationen enthalten, z. B. mehr Replikate in der Produktions- als in der Testumgebung. Diese angepassten YAML-Dateien können dann die gemeinsam genutzte Basis-YAML-Datei überlagern oder darauf aufbauen, sodass Sie Umgebungen verwalten können, die bis auf einige wenige Overlay-Konfigurationsunterschiede, die Sie der Quellcodeverwaltung unterziehen, größtenteils identisch sind. Weitere Informationen zu Kustomize, wie z. B. ein Glossar und häufig gestellte Fragen, finden Sie in den Dokumenten unter Kustomize.

Vorbereitende Schritte:

Stellen Sie sicher, dass Ihre kubectl-Version mit der Version Ihres Clusters übereinstimmt.
Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

Gehen Sie wie folgt vor, um Konfigurationsdateien mit Kustomize einzurichten:

Installieren Sie das kustomize-Tool.
- Für macOS können Sie den Paketmanager brew verwenden.
```
brew install kustomize
```
- Für Windows können Sie den Paketmanager chocolatey verwenden.
```
choco install kustomize
```
Erstellen Sie ein Verzeichnis für Ihre App in einem Versionssteuerungssystem, wie z. B. Git.
```
git init ~/<my_app>
```
Erstellen Sie Ihre Verzeichnisstruktur für Ihr kustomize-Verzeichnis base, overlay verzeichnis und Umgebungsverzeichnisse wie Staging und Produktion. In den nachfolgenden Schritten richten Sie diese Repositorys für die Verwendung mit kustomize ein.
```
mkdir -p ~/<my_app>/base &&
mkdir -p ~/<my_app>/overlay &&
mkdir -p ~/<my_app>/overlay/staging &&
mkdir -p ~/<my_app>/overlay/prod
```
Beispiel für eine Repositorystruktur
```
.
├── base
└── overlay
    ├── prod
    └── staging
```
Richten Sie das Repository base ein.
1. Navigieren Sie zum Repository 'base'.
```
cd ~/<my_app>/base
```
2. Erstellen Sie eine Anfangsgruppe mit Kubernetes-YAML-Konfigurationsdateien für Ihre App-Bereitstellung. Sie können die wasliberty YAML-Beispiel zum Erstellen einer Bereitstellung, eines Dienstes, einer Konfigurationszuordnung und eines Anspruchs auf ein dauerhaftes Volumen.
3. Erstellen Sie eine kustomization-Datei, in der die Basiskonfiguration angegeben ist, die auf alle Umgebungen angewendet werden soll. Die kustomization-Datei muss die Liste der YAML-Dateien für die Kubernetes-Ressourcenkonfiguration enthalten, die in demselben Repository base gespeichert sind. In der kustomization-Datei können Sie auch Konfigurationen hinzufügen, die für alle YAML-Ressourcendateien im Repository 'base' gelten, wie z. B. ein Präfix oder Suffix, das an alle Ressourcennamen angehängt wird, eine Bezeichnung, der vorhandene Namensbereich, in dem alle Ressourcen erstellt werden, usw.
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: wasliberty
namePrefix: kustomtest-
nameSuffix: -v2
commonLabels:
  app: kustomized-wasliberty
resources:
- deployment.yaml
- service.yaml
- pvc.yaml
- configmap.yaml
- secret.yaml
```
  Die Namen der resources-YAML-Dateien müssen mit den Namen der anderen Dateien im Repository base übereinstimmen. Sie können mehrere Konfigurationen in derselben Datei einschließen, im Beispiel befinden sich die Konfigurationen jedoch in separaten Dateien, wie z. B. deployment.yaml, service.yaml und pvc.yaml.
4. Erstellen Sie Ihre YAML-Ressourcendateien mit den Konfigurationen, die Sie in der kustomization-YAML-Basisdatei definiert haben. Die Ressourcen werden durch Kombinieren der Konfigurationen in den kustomization-Dateien und in den YAML-Ressourcendateien erstellt. Die kombinierten YAML-Dateien werden in stdout in der Ausgabe zurückgegeben. Verwenden Sie denselben Befehl zum Erstellen nachfolgender Änderungen, die Sie an der kustomization-YAML-Datei vornehmen, wie z. B. Hinzufügen einer Bezeichnung.
```
kustomize build
```

Richten Sie Ihr Overlay-Repository mit eindeutigen kustomization-YAML-Dateien für jede Ihrer Umgebungen, wie z. B. Staging und Produktion, ein.

Erstellen Sie im Repository 'staging' eine Datei kustomization.yaml. Fügen Sie alle Konfigurationen hinzu, die für Staging eindeutig sind, wie z. B. Beschriftung, Image-Tag oder YAML-Datei für eine neue Komponente, die Sie testen wollen.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: staging-
commonLabels:
  env: staging
  owner: TeamA
bases:
- ../../base
patchesStrategicMerge:
- configmap.yaml
- new_staging_resource.yaml
resources:
- new_staging_resource.yaml

Verständnis der YAML-Komponenten
Komponente	Beschreibung
`namePrefix`	Geben Sie ein Präfix an, das dem Namen der Ressourcen, die mit Ihrer `kustomization`-Datei für das Staging erstellt werden sollen, vorangestellt werden soll, z. B. `staging-`.
`commonLabels`	Fügen Sie Bezeichnungen hinzu, die eindeutig für die Staging-Objekte sind, wie z. B. die Staging-Umgebung und das verantwortliche Team.
`bases`	Fügen Sie einen relativen Pfad zu einem Verzeichnis oder eine URL zu einem fernen Repository hinzu, das eine `kustomization`-Basisdatei enthält. Im Beispiel verweist der relative Pfad auf die `kustomization`-Basisdatei im zuvor von Ihnen erstellten Repository `base`. Dieses Feld ist erforderlich für eine `kustomization`-Overlay-Datei.
`patchesStrategicMerge`	Listen Sie die YAML-Dateien für die Ressourcenkonfiguration auf, die Sie mit der `kustomization`-Basisdatei zusammengeführt werden sollen. Sie müssen diese Dateien außerdem demselben Repository hinzufügen wie die `kustomization`-Datei, z. B. zu `overlay/staging`. Diese Ressourcenkonfigurationsdateien können kleine Änderungen enthalten, die in den Basiskonfigurationsdateien mit demselben Namen als Patch zusammengeführt werden. Die Ressource erhält alle Komponenten, die sich in der `base`-Konfigurationsdatei befinden, sowie alle zusätzlichen Komponenten, die Sie in der `overlay`-Konfigurationsdatei angeben. Wenn es sich bei der Konfiguration um eine neue Datei handelt, die sich nicht in 'base' befindet, müssen Sie im Feld `resources` auch den Dateinamen hinzufügen.
`resources`	Listen Sie alle YAML-Ressourcenkonfigurationsdateien auf, die für das Repository 'staging' eindeutig sind und nicht im Repository 'base' enthalten sind. Nehmen Sie diese Dateien ebenfalls in das Feld `patchesStrategicMerge` auf und fügen Sie sie demselben Repository wie die `kustomization`-Datei hinzu, z. B. `overlay/staging`.
Andere mögliche Konfigurationen	Weitere Konfigurationen, die Sie Ihrer Datei hinzufügen können, finden Sie unter "Erstellen einer `kustomization`-Datei ".

Erstellen Sie Ihre Overlay-Konfigurationsdateien für Staging.
```
kustomize build overlay/staging
```
Wiederholen Sie diese Schritte, um Ihre kustomization-Overlay-Datei für die Produktion und andere YAML-Konfigurationsdateien zu erstellen. Sie können beispielsweise die Anzahl der Replikate in Ihrer Datei deployment.yaml erhöhen, sodass Ihre Produktionsumgebung mehr Benutzeranforderungen verarbeiten kann.

Überprüfen Sie Ihre kustomize-Repository-Struktur, um sicherzustellen, dass sie alle YAML-Konfigurationsdateien enthält, die Sie benötigen. Die Struktur kann dem folgenden Beispiel ähneln.

├── base
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── pvc.yaml
│   ├── secret.yaml
│   └── service.yaml
└── overlay
    ├── prod
    │   ├── deployment.yaml
    │   ├── kustomization.yaml
    │   └── new_prod_resource.yaml
    └── staging
        ├── configmap.yaml
        ├── kustomization.yaml
        └── new_staging_resource.yaml

Wenden Sie die Kubernetes-Ressourcen für die Umgebung an, die bereitgestellt werden soll. Im folgenden Beispiel wird das Repository 'staging' verwendet.

Navigieren Sie zum Overlay-Verzeichnis für Staging. Falls Sie Ihre Ressourcen nicht im vorherigen Schritt erstellt haben, erstellen Sie sie jetzt.
```
cd overlay/staging && kustomize build
```
Wenden Sie die Kubernetes-Ressourcen auf Ihren Cluster an. Geben Sie die Option -k und das Verzeichnis an, in dem sich die Datei kustomization befindet. Beispiel: Wenn Sie sich bereits im Verzeichnis 'staging' befinden, schließen Sie ../staging ein, um den Pfad zum Verzeichnis zu markieren.
```
kubectl apply -k ../staging
```
Beispielausgabe
```
configmap/staging-kustomtest-configmap-v2 created
secret/staging-kustomtest-secret-v2 created
service/staging-kustomtest-service-v2 created
deployment.apps/staging-kustomtest-deployment-v2 created
job.batch/staging-pi created
persistentvolumeclaim/staging-kustomtest-pvc-v2 created
```

Stellen Sie sicher, dass die Staging-spezifischen Änderungen angewendet werden. Beispiel: Wenn Sie ein Präfix staging- hinzugefügt haben, enthalten die Pods und die anderen Ressourcen, die erstellt werden dieses Präfix im Namen.

kubectl get -k ../staging

Beispielausgabe

NAME                                        DATA   AGE
configmap/staging-kustomtest-configmap-v2   2      90s

NAME                                  TYPE     DATA   AGE
secret/staging-kustomtest-secret-v2   Opaque   2      90s

NAME                                    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/staging-kustomtest-service-v2   NodePort   172.21.xxx.xxx   <none>        9080:30200/TCP   90s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/staging-kustomtest-deployment-v2   0/3     3            0           91s

NAME                   COMPLETIONS   DURATION   AGE
job.batch/staging-pi   1/1           41s        2m37s

NAME                                              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS       AGE
persistentvolumeclaim/staging-kustomtest-pvc-v2   Pending                                      ibmc-file-bronze   90s

Wiederholen Sie diese Schritte für jede Umgebung, die Sie erstellen wollen.

Optional: Bereinigen Sie Ihre Umgebung, indem Sie alle Ressourcen entfernen, die Sie mit Kustomize angewendet haben.

kubectl delete -k <directory>

Beispielausgabe

configmap "staging-kustomtest-configmap-v2" deleted
secret "staging-kustomtest-secret-v2" deleted
service "staging-kustomtest-service-v2" deleted
deployment.apps "staging-kustomtest-deployment-v2" deleted
job.batch "staging-pi" deleted
persistentvolumeclaim "staging-kustomtest-pvc-v2" deleted