Crearea unui chart Helm

Vom începe prin a crea un chart Helm simplu, pe care îl vom folosi pentru a deprinde conceptele de bază. Helm oferă comanda helm create pentru a genera un schelet (scaffold) de chart, adică structura de fișiere și câteva șabloane implicite. Să creăm un chart nou numit mychart:

$ helm create mychart
Creating mychart

Helm a creat un director mychart/ cu următoarea structură de fișiere și directoare:

$ tree             
.
└── mychart
    ├── Chart.yaml
    ├── charts
    ├── templates
    │   ├── NOTES.txt
    │   ├── _helpers.tpl
    │   ├── deployment.yaml
    │   ├── hpa.yaml
    │   ├── httproute.yaml
    │   ├── ingress.yaml
    │   ├── service.yaml
    │   ├── serviceaccount.yaml
    │   └── tests
    │       └── test-connection.yaml
    └── values.yaml

5 directories, 11 files

Să analizăm pe scurt componentele unui chart Helm:

• Chart.yaml – fișierul de metadate al chart-ului. Conține numele (name: mychart), versiunea chart-ului (version: 0.1.0 implicit) și, opțional, o descriere, versiunea aplicației containerizate (appVersion), autorii etc. La nevoie, vom actualiza versiunea chart-ului în acest fișier când facem schimbări semnificative, însă pentru laborator nu este critic.
• values.yaml – fișierul cu valori implicite pentru variabilele folosite în șabloanele chart-ului. Aici sunt definite configurările care pot fi personalizate la instalare. De exemplu, în chart-ul generat, values.yaml include chei precum replicaCount (numărul de replici al aplicației, implicit 1), image.repository și image.tag (imaginea Docker folosită), setări pentru portul expus, tipul de serviciu etc. Aceste valori vor fi injectate în manifestele Kubernetes prin mecanismul de templating.
• .helmignore – similar cu un .gitignore, listează fișiere sau tipare care nu ar trebui incluse atunci când se arhivează/împachetează chart-ul (de exemplu, fișiere temporare sau surse ne-necesare).
• templates/ – directorul ce conține șabloanele YAML Kubernetes. Aceste fișiere sunt modele care pot include sintaxă de templating (bazată pe Go templates) și care, la instalarea chart-ului, vor fi completate folosind valorile din values.yaml (suprascrise eventual de utilizator). Chart-ul de bază generat include șabloane pentru obiecte Kubernetes uzuale:
  • deployment.yaml – definește un Deployment Kubernetes pentru rularea aplicației (în cazul nostru, va rula un container NGINX cu replicaCount specificat în valori).
  • service.yaml – definește un Service Kubernetes pentru a expune aplicația. Implicit, tipul serviciului în valori este ClusterIP (acces intern clusterului).
  • ingress.yaml – definește opțional un Ingress (este prezent dar probabil comentat/inactiv implicit, dat fiind că values.yaml are ingress.enabled: false).
  • hpa.yaml – definește opțional un HorizontalPodAutoscaler (HPA) dacă este activat.
  • serviceaccount.yaml – definește un ServiceAccount utilizat de Deployment (implicit).
  • _helpers.tpl – fișier care conține funcții helper template, de exemplu pentru a genera nume unice ale resurselor combinând numele chart-ului și al release-ului. De obicei, acest fișier definește template-uri pentru fullname al aplicației, prefixe, etichete standard etc., folosite de celelalte șabloane.
  • tests/test-connection.yaml – un fișier ce definește un Helm test (un job Kubernetes) care poate fi rulat după instalare pentru a verifica dacă aplicația funcționează.
• templates/NOTES.txt – fișier text cu instrucțiuni care vor fi afișate după instalarea chart-ului. Acesta conține mesaje utile pentru utilizator, de exemplu cum să acceseze aplicația. În chart-ul nostru, NOTES.txt are câteva comenzi sugerate pentru a găsi numele Pod-ului Nginx și a face port-forward la acesta (vom vedea în practică imediat).

Observăm că chart-ul generat este conceput ca un exemplu generic (rulează un NGINX care servește pagina de bun venit). În condiții reale, am edita aceste șabloane și valori pentru a corespunde propriei aplicații (de exemplu, am înlocui imaginea nginx cu imaginea aplicației noastre, am ajusta portul, configurări etc.). Momentan, vom folosi chart-ul mychart exact cum a fost generat, pentru a înțelege fluxul Helm. Vom instala acest chart pe clusterul Kind și ne vom asigura că instanța Nginx pornește corect.

Notă

Chart-ul creat are apiVersion: v2 în Chart.yaml, ceea ce înseamnă că este compatibil cu Helm 3 (nu necesită Tiller, componenta server din Helm 2 care a fost între timp eliminată). Așadar, vom folosi direct comenzi Helm 3, fără nicio altă configurare specială.