Empaquetado de apps para su reutilización en varios entornos con Kustomize

Como parte de una aplicación nativa de la nube de doce factores, desea mantener la paridad de l dev-to-prod s mediante la configuración de un canal de desarrollo y entrega continuo que utilice una fuente de código base común y con control de versiones. En sus repositorios de código base, almacena sus archivos de manifiesto de configuración de recursos de Kubernetes, a menudo en formato YAML. Puede utilizar el proyecto Kubernetes Kustomize tanto para estandarizar como para personalizar sus implementaciones en múltiples entornos.

Por ejemplo, puede configurar un archivo YAML de base de datos ( kustomization ) para declarar objetos de base de datos ( Kubernetes ) como implementaciones y PVC que se comparten en sus entornos de desarrollo, prueba y producción. A continuación, puede configurar archivos YAML de kustomization independientes que tengan configuraciones personalizadas para cada entorno, como más réplicas en producción que en pruebas. Estos archivos YAML personalizados pueden superponerse o basarse en el archivo YAML base compartido para que pueda gestionar entornos que son en su mayoría idénticos, excepto por algunas diferencias de configuración de superposición que usted controla. Para obtener más información sobre Kustomize, como un glosario y preguntas frecuentes, consulte los documentos de Kustomize.

Antes de empezar: acceda al clúster de Red Hat OpenShift.

Para configurar los archivos de configuración con Kustomize:

Instale la herramienta kustomize.
- Para macOS, puede utilizar el gestor de paquetes brew.
```
brew install kustomize
```
- Para Windows, puede utilizar el gestor de paquetes chocolatey.
```
choco install kustomize
```
Cree un directorio para la app en un sistema de control de versiones, como por ejemplo Git.
```
git init ~/<my_app>
```
Cree su estructura de repositorios para su directorio kustomize base, overlay, y directorios de entorno como staging y producción. En los pasos siguientes, configurará estos repositorios para que se utilicen con kustomize.
```
mkdir -p ~/<my_app>/base &&
mkdir -p ~/<my_app>/overlay &&
mkdir -p ~/<my_app>/overlay/staging &&
mkdir -p ~/<my_app>/overlay/prod
```
Ejemplo de estructura de repositorio
```
.
├── base
└── overlay
    ├── prod
    └── staging
```
Configure el repositorio base.
1. Vaya al repositorio base.
```
cd ~/<my_app>/base
```
2. Cree un conjunto inicial de archivos YAML de configuración de Kubernetes para el despliegue de su app. Puede utilizar el ejemplo YAML de wasliberty para crear una implementación, un servicio, un mapa de configuración y una reclamación de volumen persistente.
3. Cree un archivo de configuración global(kustomization) que especifique la configuración base que se aplicará en todos los entornos. El archivo kustomization debe incluir la lista de archivos YAML de configuración de recursos de Kubernetes almacenados en el mismo repositorio base. En el archivo kustomization, también puede añadir configuraciones que se apliquen a todos los archivos YAML de recursos del repositorio base, como un prefijo o un sufijo que se añade a todos los nombres de recursos, una etiqueta, el espacio de nombres existente en el que se crean todos los recursos, los secretos, los mapas de configuración y más.
```
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
```
  Los nombres de los archivos YAML de resources deben coincidir con los nombres de los otros archivos del repositorio base. Puede incluir varias configuraciones en el mismo archivo, pero, en el ejemplo, las configuraciones son archivos independientes, como deployment.yaml, service.yaml y pvc.yaml.
4. Cree los archivos YAML de recursos con las configuraciones que ha definido en el archivo YAML base de kustomization. Los recursos se crean combinando las configuraciones de kustomization y los archivos YAML de recursos. Los archivos YAML combinados se devuelven en stdout en la salida. Utilice este mismo mandato para crear los cambios posteriores que realice en el archivo YAML de kustomization, como por ejemplo para añadir una etiqueta.
```
kustomize build
```

Configure el repositorio overlay con archivos YAML de kustomization exclusivos para cada uno de los entornos, como por ejemplo para el de transferencia y el de producción.

En el repositorio de transferencia, cree un archivo kustomization.yaml. Añada las configuraciones que sean exclusivas del entorno de transferencia, como una etiqueta, un código de imagen o un archivo YAML para un nuevo componente que desee probar.

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

Comprender los componentes YAML
Componente	Descripción
`namePrefix`	Especifique el prefijo que se adjuntará al nombre de cada recurso que desee crear con el archivo `kustomization` de transferencia, como por ejemplo `staging-`.
`commonLabels`	Añada etiquetas que sean exclusivas de los objetos de transferencia, como por ejemplo el entorno de transferencia y el equipo responsable.
`bases`	Añada una vía de acceso relativa a un directorio o un URL a un repositorio remoto que contenga el archivo `kustomization` base. En este ejemplo, la vía de acceso relativa a punta al archivo `kustomization` base del repositorio `base` que ha creado anteriormente. Este campo es obligatorio para una `kustomization` de overlay.
`patchesStrategicMerge`	Obtenga una lista de los archivos YAML de configuración de recursos que desea fusionar con `kustomization` base. También debe añadir estos archivos al mismo repositorio que el archivo `kustomization`, como por ejemplo `overlay/staging`. Estos archivos de configuración de recursos pueden contener pequeños cambios que se fusionan con los archivos de configuración base con el mismo nombre como un parche. El recurso obtiene todos los componentes que están en el archivo de configuración `base`, más los componentes adicionales que especifique en el archivo de configuración `overlay`. Si la configuración es un archivo nuevo que no está en la base, también debe añadir el nombre de archivo en el campo `resources`.
`resources`	Obtenga una lista de los archivos YAML de configuración de recursos que sean exclusivos del repositorio de transferencia y que no estén incluidos en el repositorio base. Incluya también estos archivos en el campo `patchesStrategicMerge` y añádalos al mismo repositorio que el archivo `kustomization`, como por ejemplo `overlay/staging`.
Otras configuraciones posibles	Para ver más configuraciones que puede añadir a su archivo, consulte Crear un archivo de configuración de página(`kustomization` ).

Cree los archivos de configuración staging y overlay.
```
kustomize build overlay/staging
```
Repita estos pasos para crear el archivo kustomization overlay de producción y otros archivos YAML de configuración. Por ejemplo, puede aumentar el número de réplicas en su deployment.yaml para que el entorno de producción pueda manejar más solicitudes de usuario.

Revise la estructura de repositorios de kustomize para asegurarse de que incluya todos los archivos de configuración de YAML que necesita. La estructura debería parecerse a la del siguiente ejemplo.

├── 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

Aplique los recursos de Kubernetes correspondientes al entorno que desea desplegar. En el siguiente ejemplo se utiliza el repositorio staging.

Vaya al directorio overlay de staging. Si no ha creado los recursos en el paso anterior, créelos ahora.
```
cd overlay/staging && kustomize build
```

Aplique los recursos de Kubernetes al clúster. Incluya la opción " -k " y el directorio donde se encuentra el archivo " kustomization ". Por ejemplo, si ya está en el directorio staging, incluya ../staging para marcar la vía de acceso al directorio.

oc apply -k ../staging

Salida de ejemplo

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

Asegúrese de que se apliquen los cambios exclusivos de staging. Por ejemplo, si ha añadido un prefijo staging-, los pods y otros recursos que se crean deben incluir este prefijo en su nombre.

oc get -k ../staging

Salida de ejemplo

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

Repita estos pasos para cada entorno que desee crear.

Opcional: limpie el entorno eliminando todos los recursos que ha aplicado con Kustomize.

oc delete -k <directory>

Salida de ejemplo

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