#processus de déploiement

#Évolution du processus de déploiement

Les environnements de développement : hicksoncentral-master, et hicksoncomplexe-master (et potentiellement X-recette ) sont déployé sur kubernetes, sur une instance dédié aux développements (hickson et autres clients).

Le déploiement vers des environnement de pré-prod et production seront aussi sur une instance kubernetes, ce qui appel le besoin de faire converger les processus de déploiements sur les différents environnement. Un processus commun permet de s’assurer que le processus vers la prod est éprouvé.

#État du déploiement vers kube développement

Dans le cadre du développement continue, le processus mis en place cherche à permettre de déployer des développement dès son push dans les repository git. En pratiques, sur les différents briques d’une application Bus Applicatif,

• les produit de base : kafka, es, zookeeper … sont déployé à la main, une fois (ce sont des briques qui n’évolue que peu), et les définition de ces produits sont conservé dans le projet /sys-isi/kubernetes-template sous forme de fichier yaml, ressources kubernetes.
• les briques développé : rest-api, job kstream/samza, ui angular … Via gitlab-ci (au sein des .gitlab-ci.yaml de chaque projets), le gitlabrunner déployé construit les différents projets suivant leur types, et sont déployé sur un environnement suivant la branche git (master,recette) sur la-quel à été pushé la modification. La constuction est faite via le projet Golang dev-env , la commande “isi” qui suivant le fichier .isi-build.yaml construit et déploie le projet (les ancienne commandes “dockerrize” et “kube-deploy”. A noter que la commande “isi”, après la construction spécifique (java, angular , …), est suivit de la constuction d’un docker, pushé sur un repository privé, puis le déploiement de la brique est lancé (création ou mise a jour du déploiement) vers kubernetes. Ce sont ensuite les processus kubernetes qui récupèrent le docker, l’instancie et gère son

Les + de ce processus:

• déploiement continue dès le push des développement
• support de plusieurs environnement via les branches git
• support de tag git vers les tag docker

Les - de ce processus

• les ressources autres ne font pas intégralement parti du processus de déploiement. Les mises à jour sont possible via kubectl, avec un minimum de complexité (géré par kube), mais le suivit de ces modifications n’existe pas
• les branches peuvent être différentes, mais dans le cadre de déploiement continue, il serait souhaitable que les environnement suivant : recette,preprod … ne soit que des “avancement” vers le master et non des reconstructions (docker) des briques plutôt que réutiliser les briques déjà construites … le résultat est moins de stabilité. Mais il faut pouvoir garder la possibilité que cela offre en terme de hotfix

#État du déploiement vers les clients:

Pour les clients n’ayant pas de plateforme kubernetes vers lesquelles le bus sera déployé, le processus dépend de la cible.

#exemple : sln

Pour le client sln, le projet liv-debug permet de configurer toutes les briques, en parti via le repository, en parti par extraction à partir de la plateforme de recette (namespace recette -sln du kubernetes de développement) . Il est possible ensuite de éployer unitairement une brique sur leur environnement “DEBUG”.

• sont livré : des fichier de configuration, des fichiers .services pour chaque briques, des fichiers de création de topic kafka, des mappings elasticsearch. les dockers vers le repository docker du client.

Le déploiement vers les autres environnement client sont de leur responsabilité.

#exemple : smti

ISI gère une instance kubernetes pour déployer les projets clients. Les produit pour un client sont déployé dans un namespace réserve.

Helm est utilisé pour déployer les produit. Dans le cadre de la smti, le produit “navitia” a été déployé vers son namespace. Mais le passage des environnement de développement à l’environnement de production s’est faite à la main par l’écriture du chart helm à partir des ressources kubernetes déployé précédemment à la main ou via le processus de déploiement continue gitlab-ci

#Cible de l’évolution du processus de déploiement

Le but est d’utiliser helm pour tous les déploiements, sur le kubernetes de développement aussi bien que sur les kubernetes de recette ou prod.

Pour cela, un repo git /helm sera définit pour chaque client (exemple et poc /hickson/helm) sur lesquelles sera définit

• Le(s) chart(s) “parapluie”, qui définira(ront) en sous-chart toutes les briques (produits ‘stables’ ou développés ) nécessaires à son fonctionnement – le produit peut être découpé en plusieurs charts si nécessaire ; pour hickson il faut gérer 2 environnements cible à déployer, le déploiement est découpé en 4 charts : 1 commun aux 2 environnement, 1 pour chaque environnement, et le dernier pour k2k qui permet les échange de données entre environnement
• le script de déploiement (qui sera presque commun entre diffèrent repo /helm) qui tournera autour de la commande “helm upgrade”
• un (voire peut être plusieurs) fichier type “values.yaml” contenant les valeurs des “variables” supportés par les charts.

Dans le fichier values.yaml sera en particulier présent les tag docker des différentes briques.

• dans le cadre initial, les sous-chart seront aussi définit dans le repo git helm/ en attendant l’utilisation d’un repository helm. Les chart des produit “stable” ou générique seront définit.

#Rappel : helm et chart

helm est le “package manager” pour kubernetes. Il est constitué d’un client “helm” et d’un serveur “tiller” déployé par le client sur kubernetes lors de “helm init” Les objets que gère helm sont des “chart”. Un chart est un dossier (ou sont équivalent compressé .tgz) constitué de :

Dans l’exemple ci dessus, du chart kafka écrit pour isi, le chart est constitué

• du fichier Chart.yaml qui décrit succinctement le chart, et définit sa version v0.1.0 par défaut
• du fichier values.yaml où sont définit les valeurs par défaut des variables utilisé par les templates et sous-chart
• du dossier templates ou sont regrouper des définition de ressources kubernetes (statefulset/service/…). Ces fichiers sont des templates go qui sont géré par tiller avec les valeurs de values.yaml
  • le fichier _helper.tpl décrit des “macro” (nom officiel : template :D ) qui peuvent être utilisés par les fichiers template
• du fichier requirements.yaml (optionnel) qui décrit les sous-chart qui peuvent être nécessaire pour la définition de ce chart
  • dans le cas de kafka, zookeeper et imagehelper y sont requit
• du dossier chart où sont présent les sous-chart nécessaire pour la définition de ce chart. Ils peuvent être un dossier, développé à la manière d’un chart, ou comme ici un chart qui a été importé lors du packaging du chart, et en fonction du requirement.yaml

un Chart peut être packagé puis envoyé sur un chart repository. Par simplicité, lors des phase de build des charts, nous utilisons le repository local, lancé avec “helm serve &”. Pour déployé un chart sur un namespace de kubernetes, soit le chart peut être désigné par son nom et son repository où le trouver (et sa version) ou directement par le répertoire où il est définit.

exemple de commande:

helm install -f myvalues.yaml --namespace dest-namespace kafka/

Ici le chart kafka sera déployé sur le namespace “dest-namespace”, les valeurs utiliser par le template seront le merge du “values.yaml” définit dans le chart, et du fichier “myvalues.yaml” définit par la ligne de commande.

Dans le processus de déploiement, nous utilisons les principes de merge et d’override de values offert par le mécanisme de values.yaml

#Processus et outils

#environnement de développement

Lors du push d’un nouveau code dans son repo git, la construction spécifique et le docker se fera toujours via le gitlab-ci de ce projet (commandes “isi build” “isi dockerize”). Par contre le déploiement consistera à mettre à jour dans le fichier values.yaml le tag du docker construit, en place de la brique.

Pour ce faire un job gitlabci utilisera le docker /isi/deploiement [git@git.isi.nc:hickson/deployment.git], commande “deployhelm.sh” qui modifie le fichier et push la modification dans le repo /helm

tache gitlab-ci pour la mise a jour des infos du projet dans le projet XXX/helm

deploy:
  stage: deploy
  image: dkr.isi/isi/deployment:v1.4.3
  variables:
     HELM_REPO: hickson/helm
  script:
    - deployhelm.sh 
  tags:
    - ci-kubernetes

Via le gitlabci de /helm, le push déclenche le déploiement vers l’environnement correspondant (master/recette). Mais à priori il n’est pas nécessaire d’avoir pour le projet à déployer une branche recette … avoir une branche recette sur le projet helm/ est suffisant pour gérer les 2 environnement. La nécessité de la branche recette pour le projet sera pour les hotfix … cela entraînera une divergence des branche master et recette du projet helm/

taches gitlab-ci pour le déploiement de XXX/helm, déclenché sur push – lors de la mise à jour d’un projet

build:
#build all chart, automaticaly put in local helm repository
   stage: buildchart
   script:
    - make -C chart/
   only:
     - master

#need variable $TILLER (for namespace), 
#CHART : nom du chart
#RELEASE : nom de la release
#VALUES fichier values
#ALLVALUES fichiers values
#TARGET_REPO : if set, deliver images on this docker repo, and change ressource to use theses images
.deploy: &deploy-def
  script:
    - create_namespace
    - install_tiller
    - deploy 

#deploy local/base in $CENTRAL -> es, postgres, odoo, kafka, kafka-notif
deploybasecentral:
  stage: deploybasecentral
  variables:
    TILLER: $CENTRAL
    RELEASE: centralbase
    CHART: local/hickson-base
    VALUES: values.yml
    WAIT: "true"
  <<: *deploy-def
  only:
     - master   

[...]

#ressources spécifiques

topics kafka

Les briques du Bus Applicatif lisent et écrivent des données dans des topics kafka. La gestion de ces topics et des config par défaut doivent être transmise au processus de déploiement avant qu’ils soient utilisés par les consumer et producer des briques.

La cible étant un job kubernetes qui est responsable de la création et la modification des topics. Seulement, la gestion des job par helm n’est pas simple, car un job est désigné pour être lancé qu’une seule fois. Il n’est pas sensé être mis à jour par helm, ni relancé. Les 2 solutions disponible sont :

• créer un nouveau job (nom différent grâce a un random) à chaque upgrade
• lancer le job sur un hook helm

La première solution conduira à la création de beaucoup de job, et surtout à la rétention de ces job dans kubernetes, surtout sur les environnement de développement, donc nous n’avons pas retenu cette solution.

La deuxième solution permet de déclaré le job sur un type de hook helm, (pre-install / pre-upgrade …), et qui permet de supprimer le job. Ainsi un seul job sera toujours présent sur kubernetes, ce qui permet de voir son log si nécessaire. Par contre il ne fait pas partit de la release (pas de conséquence). Le problème et l’avantage du hook est qu’il permet d’être sûr du moment dans l’upgrade où le job va s’exécuter. En effet, on souhaite qu’il s’exécute AVANT le déploiement des briques qui sont susceptibles de les utiliser, mais APRÈS le déploiement de kafka (cas de première installation). Pour cette raison nous nous voyons contraint de découper le chart d’un environnement en 2 parties : la première ayant kafka (et d’autre produit de base) , et la seconde les briques développées, sur lesquels en pre-hook sera le job de gestion de topic

~~Malheureusement la gestion du delete du job hook qui nous intéresse (before-hook-creation), et qui aurait permit de supprimer l’ancien job à chaque update, et ainsi de garder qu’un seul job dans le namespace, n’est disponible qu’à partir de helm v2.9.0 qui n’est pas encore disponible à l’heure de l’écriture. Nous sommes contraint, pour le moment de faire la première solution, mais toujours sur le modèle d’un hook. ~~ helm v2.9 est GA et désormais utilisé par notre processus.

#environnement client

Une fois ce processus mis en place, la livraison vers d’autre environnement consiste à un helm upgrade mais vers une instance kubernetes différente … le chart ne change pas – éventuellement les values.yaml peuvent être spécifique à chaque environnement.

note : Il est à noté que il y a des particularités à prendre en compte : livraison des images dockers : avant l’upgrade, une livraison vers un repo client est nécessaire. Il faudra peut être mettre en place le repo sur le namespace client. Topic kafka, mapping es. La gestion des ressources qui ne sont pas des ressource kubernetes doivent être pris en compte :

topic kafka : la gestion des topics doit venir de chaque projet git qui gère des topics (ceux qui sont responsable de leur création : les producers). Pour cela est mis en place un chart de création de topic (à partir de la commande “topigMngt” [git@git.isi.nc:hickson/deployment.git]) qui permet à partir d’un fichier de description yaml créer, supprime, met à jour les topics. Le fichier yaml embarqué dans un configmap, et exécuté par un job qui sera en hook de helm. le fichier dans le configmap sera généré à partir de plusieurs fichiers, chacun en provenance des repo git.

mapping es: la gestion des mapping es reprend le même principe de fonctionnement que pour la gestion des topics. Seulement, uniquement la création de l’index est géré … pas son mapping a proprement dit… pour le moment.

#En pratique

Les charts générales et génériques sont développé sur le repo git pole-tech/helmchart.

#chart isiinfra

chart parapluie contenant

• subchart kafka – subchart zookeeper
• subchart es6
• subchart kafka-notif – subchart topicmanagment pour la création du topic service.notif.done.json. Le job de création attend que les jobs kafka soit disponible. kafka-notif attend quel job topicManagement soit terminé avant que le container se déploie.

#chart “hickson-base”

chart parapluie contenant

• subchart isiinfra
• subchart odoo – subchart postgres

• ressource config et secret (utilisé par postgres, odoo, et central ) Ces ressources sont appelé “cineges-config” et “cineges-secret”, elles n’auront pas de distinction de nom dans les déploiement central ou complexe leur contenue dépendra du values.yaml fournit en entré de helm

déployé sous le nom de release “basecentral” pour le central et “basecomplexe” pour un complexe, ou “basekone” …

values utilisées Pour le déploiement central, le fichier hickson/helm/values.yml:

#env master : 1 kafka broker
 infra:
	kafka:
   	   replicaCount: 1
	kafka-notif:
	  topicmanagment:
	    kafkaReplicationFactor: 1 
topicmanagment:
   kafkaReplicationFactor: 1 
#odoo, non géré dans un values/odoo.yaml, car plus stable
odoo:
  image:
    tag: 68fd92a
  database: central-mast
# - --init   	
#config to set diffèrent for each central/complex
config:
  data:
#template "odoo.name"
    odoo.host: odoo
#odoo.service.externalPort
    odoo.port: "80"
    odoo.useSsl: "false"
    odoo.user: admin
    as400.user: isi
  secret:
#odoo odoo.conf ? 
    odoo.masterPassword: P@ssw0rd
# user/mdp set in odoo.postgres.postgresPassword
    odoo.password: admin
    as400.password: isi2017

Il contient en particulier la config et secret de l’environnement (à l’exception de odoo.postgres.user et odoo.postgres.password qui sont définit par ailleurs, mais au final bien inscrit dans le configmap de configuration) Il contient les paramètres qui définisse le nombre de nodes kafka à déployer (kafka.replicaCount), et il faut mettre en correspondance le replicationFactor pour topicManagment et kafka-notif.topicManagment. On voit aussi que les odoo.user et odoo.password sont ‘admin’ : ce sont les valeur par défaut de odoo. Le template ne gère pas de changement de mot de passe ou de création de user.

Pour le déploiement complexe le fichier utilisé doit être particulier à chaque complexe : cinecity.yaml

#env master : 1 kafka broker
infra:
	kafka:
	   replicaCount: 1
	kafka-notif:
	  topicmanagment:
	    kafkaReplicationFactor: 1 
topicmanagment:
   kafkaReplicationFactor: 1 
kafka-notif:
  topicmanagment:
    kafkaReplicationFactor: 1 

#odoo, non géré dans un values/odoo.yaml, car plus stable
odoo:
  image: 
    tag: 68fd92a
  database: complexe-cinecity2

config:
  data:
    odoo.host: odoo #odoo service !? 
    odoo.port: "80"
    odoo.useSsl: "false"
#    odoo.user: isi-admin
    odoo.user: admin #todo gestion de l'admin
    odoo.postgres.user: odoo
#taken from the id in es of central namespace
    cineges.cinemaCode: N-M
    o2k.slot.name: debezium_cinecity_test2
  secret:
    odoo.masterPassword: P@ssw0rd #set in odoo.conf de l'image docker
#   odoo.password: P@ssw0rd
    odoo.password: admin
    odoo.postgres.password: odoo

La configuration est très proche de celle pour le central. Est rajouté cineges.cinemaCode concernant le code du cinema correspondant à l’environnement déployé. Il devrait évoluer vers un identifiant plus stable

On remarque que c’est ici aussi que sont décidé du nom de la base de donné de odoo.

#chart “hickson-central”

chart parapluie contenant

• subchart topicManagment gère la création/édition des topics déclaré par les briques suivante dans des values.yaml . Le job de création est un hook sur le pre-install, pre-upgrade, qui impose la nécessite de découper le déploiement en 2 chart
• subchart indexManagement gère la création des index es. Pour le moment ne gère que la création (pas de mapping, de mise a jour …)
• subchart cineges-central-api, de type api-chart
• subchart cineges-central-jobs de type kafkastreams-chart la config des variable d’env doivent changer de nom de configMap
• subchart cineges-db2-jobs de type kafkastreams-chart
• subchart db2kafka définit les cronjob qui importent les tables de l’as400. les jobs sont définit dans central/values.
• subchart odoo2kafka-job de type kafkastream-chart, il est particulier en ça que odoo2kafka est le docker pgdbz-export, paramétré d’une certaine manière pour le cas de odoo TODO: gérer le déploiement continue de odoo2kafka via le repo git pgdbz-export
• subchart cineges-ui de type ui-chart

values utilisées

le déploiement de ce chart utilise les fichiers de valeurs hickson/helm/values/*.yml et values.yml : le même que pour le chart base (voir ci dessus)

Utiliser plusieurs fois values.yaml permettrait de définir dans un seul fichier des configuration pour les chart base et central. En l’état, il n’y a rien dans le fichier values.yaml qui concerne les charts de central.. mais il est possible de surcharger des valeurs dans ce fichier.

Les fichiers values/*.yml sont individuellement les fichiers modifiés par les projets qui en déploiement continue (cineges-central-api, …) Y sont définit les image docker à déployer, les particularité suivant les plugins dev-env, et aussi les topics et index elasticsearch qui sont géré par le processus de déploiement.

#chart “hickson-complexe”

chart parapluie contenant

• subchart topicManagment
• subchart indexManagment
• cinecaisse-ui de type ui-chart
• cineges-caisse-api de type api-chart
• cineges-caisse-jobs de type kafkastream-chart
• cineges-complexe-api de type api-chart
• cineges-complexe-jobs de type kafka-stream-chart
• odoo2kafka-job
• cineges-web de type api-chart
• cineges-hwproxy de type hwproxy

values utilisées

le déploiement de ce chart utilise les fichiers de valeurs hickson/helm/values/*.yml et cinecity.yml : le même que pour le chart base (voir ci dessus)

Comme pour central, il est possible de surcharger des valeurs pour les chart de complexe dans ce fichier.

Les fichiers values/*.yml sont les même utilisé par chart central. En pratique les fichiers correspondant à une brique absente du chart ne sont pas prise en compte (ex: cineges-central-jobs.yml est lu, mais pas de chart cineges-central-jobs dans le chart complexe). C’est pour cette raison que il n’y a pas de distinction pour les déploiement central et complexe.

toutefois odoo2kafka est déployé dans les deux environnements : c’est bien le mémé fichier qui est utilisé pour les deux environnement… ainsi les odoo2kafka déployé sont consistant sur les différents env de même la définition des topic et des index es sont dans ces fichier (cineges-central-api.yml) donc les même topics et index es sont déployé sur les deux env.

#chart kafka2kafka

chart kafka2kafka

est déployé à pars des release base central et complexe

values utilisées le fichier kafka2kafka-master.yaml est utilisé

 replicaCount: 1
image:
  repository: dkr.isi.nc
  name: sys-isi/kafka
  tag: 1.0.0_isi.1
  pullPolicy: IfNotPresent
central:
   bootstrapServers : kafka:9092
complexes:
  - name : cinecity
    bootstrapServers : kafka.hicksoncinecity-deploy:9092
 
topics:
  ctrl2cplx: notifications,cineges.*.data 
  cplx2ctrl: cineges.*.save,cineges.*.saveodooid

y sont définit l’image kafka a utiliser pour utiliser kafka-mirror, central.bootstrapServers est le serveur kafka du central (sur lequel k2k est déployé, donc la valeur kafka:9092 est consistante entre tous les environnement de déploiement

complexes[].name/bootstrapServres est la liste des complexes et le serveur auquel les accéder.

Ces paramètres sont à mettre a jour suivant l’environnement déployé.

#notes hickson

Le kgate ne fait pas parti des chart : son déploiement en dev est particulier avec kgatectl … et à priori il n’est pas à déployé en prod… donc en pratiques, les test de déploiement ont tous pointé vers kgate déployé sur hicksoncentral-master. Si un déploiement souhaite se faire sur une autre “base as400”, il faut déployer kgate en avance, et paramétrer celui ci dans cineges-config.

certain projets initialement sur master ne font pas parti des chart : cineges-doc, kibana, pgadmin, srv-caisse,cineges-hwproxy-mock, cups car à priori ils ne sont pas nécessaire à un déploiement prod. Ces projets peuvent toutefois faire parti du chart, ayant des option différent pour les différent environnements … A voir si le besoin se présente.

#livraison des images docker

Dans le cas où l’environnement cible est distante (non déployé à isi), il est recommandé de livrer les images docker dans un registry docker déployé chez le client réservé au client.

le char docker-registry permet de déployer ce registry (en statefulset, avec un volume pour recevoir les images ).

~~La livraison se fait dans le processus : récupération des images (via les values.yaml ) retag et livraison, déploiement helm en utilisant le registry as global.registry. ~~

Il est pré-requit :

• installer un registry docker (kube ‘online’ de isi) réservé au client
• éditer la config de gitlab-runner pour autoriser les accès à ce registry
• éditer les config des namespace kube du kubernetes client pour autoriser le pull de ce registry
• utiliser le nom de ce registry dans les variables gitlab-ci de déploiement prod

#technique

Afin de lister toutes les images nécessaires à la livraison pour que le déploiement se fasse, nous pensons qu’il faille générer les fichiers de ressources kubernetes par helm – lister les “image” de ces ressources … pour chacune d’entre elle les retager avec le repository client (en remplacement de docker-registry.isi quand c’est une image créer par isi), et les push dans le repository client, puis de lancer helm upgrade avec “global.repository=clientRepo”

Dans ce contexte tous les chart helm construisent leur images des ressources a l’aide du helper contenue dans le chart imagehelper Ainsi, dans tous nos charts, le champ “image” des ressource kubernetes sont construites de manière à accepter une valeur commune (“global.repository”) qui override le image.repository de chaque chart.

Pour se faire nous choisissons de hacker la commande helm, afin de récupérer les arguments d’entrer de la commande pour les utiliser aussi bien pour la génération des ressources sans repoClient, que avec. Pour ce faire, nous avons forké le projet helm , et nous nous sommes insinué dans les commande helm upgrade et helm install pour générer 2 set de overridingvalues, qui seront utiliser pour générer chaque ressources avec chacun d’entre elles.

cf https://git.isi.nc/pole-tech/helmhook/, branch isihook2.9.1

note : ce projet est cloné dans le gitlab-ci de dev-env (construction de gitlab-runner), offrant ainsi la commande “helmhook” en plus de la commande “helm”. Dans les tache du projet XXX/helm, isiAutoDevOps, la fonction deploy() utilise helmhook si TARGET_REPO est fournit :

deploybasecentralprod:
  stage: deploybasecentral
  variables:
    TILLER: $CENTRAL
    RELEASE: centralbase
    CHART: local/hickson-base
    VALUES: values_prod.yml #set to value for prod
    WAIT: "true"
    TARGET_REPO: $PROD_TARGET_REPO
  <<: *deploy-def
  only:
     - prod.v*   
 
 [...]
     
 function deploy() {
    chart=$CHART
    name="$RELEASE"
    values=${VALUES-values.yaml}
    all_values=${ALLVALUES-""}
    helmcmd=helm
    if [ -n $TARGET_REPO ]; then 
       helmcmd=helmhook;
    fi
	
    $helmcmd upgrade --install \
      `[[ $all_values != "" ]] && for i in $all_values ; do echo " -f $i " ; done;` \
      -f $values \
      `[[ $WAIT == "true" ]] && echo --wait ` \
      `[[ -n $TARGET_REPO ]] && --targetRepository=$TARGET_REPO` \
      --tiller-namespace=$TILLER_NAMESPACE \
      --namespace="$TILLER_NAMESPACE" \
      "$name" \
      $chart
  }

#Mise en place générale

	dev/recette	preprod / prod
1 kubernetes	(déjà présent)	installer le kube clients
2 namespace	le namespace est créer par le deploiement (tache gitlab)
3 repo docker	docker.registry.isi déjà présent	créer sur kube ‘online’ un repo dédié client update gitlab-runner pour autoriser la connexion a ce repo paramétrer le kube client pour les accès à ce repo
4 /helm	créer chart(s) parapluie contenant les briques du projet ne pas oublier les chart topicmanagement et indexmanagement
5 /helm .gitlab-ci	définit les tasks de compilation de chart de déploiement du(des) chart(s) (utiliser isiAutoDev)	définit pour d’autres branches (recette/prod/… (ou tag) ) les même taches, en modifiant les noms de namespace/ du kubeconfig
6 projets .gitlab-ci	ajouter la task pour update de /helm définir si besoin les fichiers topic.yaml et index.yaml

étape 3 : il est possible de creer le repo docker via le chart docker-registry de hickson/helm. Il est impératif de creer le ingress de ce chart : value.yaml

service:
  externalPort: 80
ingress:
  enabled: true
  hosts:
    - [ host .isi.nc !? ]
  annotations:
    kubernetes.io/tls-acme: "true"
  tls:
  #the secretName is automaticaly created by cert-manager
    - secretName: [ secretname]
      hosts:
       - [ host ]

étape 5.

exemple de tâche de déploiement

.deploy: &deploy-def
  script:
    - create_namespace
    - install_tiller
    - deploy  
    
deploybasecentral:
  stage: deploybasecentral
  variables:
    TILLER: $CENTRAL
    RELEASE: centralbase
    CHART: local/hickson-base
    VALUES: values.yml
    WAIT: "true"
  <<: *deploy-def
  only:
     - master 

La tache .deploy n’est pas executé ( . en début de nom), mais est définit comme “ancrage”, et est utilisé dans deploybasecentral ( <<: *deploy-def) : le yaml de la tache .deploy est mergé avec celui de deploybasecentral. Cela permet de faire un template commun avec plusieurs tache (toutes les tache de déploiement).

TILLER est le nom du namespace dans lequel est creer tiller et est déployé le chart. RELEASE est le nom de release du chart CHART : le nom du char déployé VALUES et ALLVALUES : permet de définir des fichier yaml d’override des valeurs du chart WAIT : si la commande de deploiement doit attendre que celui ci se termine avant de finir la commande. nécessaire quand on enchaîne les deploiement dans le but que un le précèdent soit bien terminé avant que le suivant soit commencé (déploiement de kafka par exemple)

Les étapes de déploiement sont :

• create-namespace : le namespace est créer : utile surtout la première fois
• install_tiller : install tiller sur ce namespace, utile surtout la première fois
• deploy : helm upgrade le chart avec les values

Pour un déploiement sur un autre kubernetes que le “bureau” (kube de dév), il faut fournir un kubeconfig dans le repo helm, et signifier l’utilisation de celui-ci :

deploybasecentralprod:
  stage: deploybasecentral
  variables:
    TILLER: $CENTRAL
    RELEASE: centralbase
    CHART: local/hickson-base
    VALUES: prod/values.yml #set to value for prod
    WAIT: "true"
    TARGET_REPO: $PROD_TARGET_REPO
    KUBECONFIG: $PROD_CENTRALKUBECONFIG
  <<: *deploy-def
  only:
     - /prod\.v.*/

La variable KUBECONFIG, utilisé par kubectl et helm est renseigné avec le chemin du fichier de config. Elle est mise à PROD_CENTRALKUBECONFIG qui définit le kubeconfig pour le kube pour central (différent de celui pour chaque complexe )

TARGET_REPO : configure un repository docker, dédier au client a priori, sur lequel les images docker seront tous d’abord livré, puis le déploiement du chart utilisera ce repo pour les images des ressources kubernetes. Ce processus utilise helmhook, un fork de helm que nous avons modifié pour brancher un scan des images et leur livraison.

étape 6 : dans .gitlab-ci ajouter retirer le déploiement, et ajouter la tache

deploy:
    stage: deploy
    image: dkr.isi/isi/deployment:v1.4.3
    variables:
	HELM_REPO: hickson/helm
    script:
       - deployhelm.sh
    tags:
      - ci-kubernetes

stage=deploy indique que la tache sera faite après la tache de build image et tags = [ci-kubernetes] indique que la tache n’est pas effectuer par gitlab-runner mais par un autre runner prenant en charge les image docker. le script est la commande dans le docker qui clone modifie et push le repo indiqué dans la variable HELM_REPO. La même branche que celle du projet sera cloné et pushé. Pour réaliser le déploiement sur d’autres branche :

deploy:
    stage: deploy
    image: dkr.isi/isi/deployment:v1.4.3
    variables:
	HELM_REPO: hickson/helm
    script:
       - deployhelm.sh --targetBranch master
    tags:
      - ci-kubernetes
    only:
      - deploy

only : [deploy] indique que la tache n’est faite que pour la branch deploy et tagetBranch indique la branch qui sera cloné et pushé.

#Problèmes connues

• Premier déploiement failed Si le premier déploiement d’un chart est failed (pour diverses causes : soit un mauvais chart, un job qui ne termine pas …), le second ne fonctionne pas : probablement bug https://github.com/kubernetes/helm/issues/4045 Il faut donc veillé à supprimer le déploiement, ainsi que toutes ressources non supprimé (cineges-secret , pvc ) ainsi que le configmap créé par helm “[release].v1”

• Déploiement long le déploiement attend que toutes les ressources soit déployé avant que la commande termine (–wait) … probablement a cause de certain job qui utilisent plusieurs pod avant d’être success, la commande ne termine pas alors que le déploiement est fait. Il faut alors arrête la tache gitlab et la relancer… il y aura un nouveau déploiement, mais la commande terminera.