Mise en place d’une architecture DevOps avec Kubernetes

Home | DevOps | Mise en place d’une architecture DevOps avec Kubernetes

LES ENJEUX DU MOUVEMENT DEVOPS

accompagnement méthodologie devops

La rapidité et la flexibilité commerciale sont devenues des axes stratégiques pour les entreprises.

L’agilité commerciale permet de s’adapter rapidement, et de manière rentable aux changements du marché.

Ces exigences ont donc entraîné un changement massif sur les processus de développement informatique afin d’être plus agile aux demandes du métier.

Le mouvement DevOps permet de répondre à ces nouveaux enjeux , c’est avant tout une méthodologie qui a pour objectif de rassembler des métiers du développement et de l’administration des infrastructures.

Cela permet notamment d’atteindre plus rapidement les objectifs de Time to Market fixés par le métier.

CHAINE D’INTÉGRATION ET DE DÉPLOIEMENT CONTINUS ( CI/CD ), A QUOI CA SERT ?

CI/CD est un terme que l’on entend souvent aux côtés d’autres termes comme DevOps, Agile, Scrum et Kanban, automatisation, et autres.

Parfois, il est considéré comme faisant simplement partie du processus de travail sans vraiment comprendre ce qu’il est ou pourquoi il a été adopté.

La mise en place d’une chaine d’intégration et de déploiement continus est avant tout une question d’organisation des équipes.

Voici un exemple :

  • Le responsable du produit qui représente le client fournit les fonctionnalités nécessaires que le produit devrait avoir et le comportement qu’il devrait suivre. Il ne faut pas oublier de réaliser de la documentation qui doit être aussi complète et spécifique que possible.
  • Les développeurs commence à travailler sur l’application et développe également des tests unitaires, puis poussent le code sur un logiciel de version (par exemple, git).
  • L’équipe de l’assurance qualité effectuent des tests d’acceptation par l’utilisateur, des tests d’intégration, des tests de performance. Pendant cette période, il ne devrait y avoir aucune modification de la base de code jusqu’à ce que la phase d’AQ soit terminée. S’il y a une anomalie, elle est renvoyée aux développeurs pour qu’ils la corrigent, et le produit est à nouveau soumis à l’assurance qualité.

QUELLES SOLUTIONS POUR CRÉER UNE CHAINE D’INTÉGRATION ET DE DÉPLOIEMENT CONTINUS ?

Pour mettre en place notre chaine d’intégration et de déploiement continus , nous devons mettre en place certains outils. Il existe bien sûr de nombreuses alternatives aux outils que je choisis.

Dans cet article , je vous propose les solutions suivantes :

  • Une instance Gitlab CI/CD : Il peut s’agir  d’une machine virtuelle ou d’un conteneur de docker.
  • Registre d’images : vous pouvez utiliser le Dockerhub, une offre basée sur le cloud , ou même installer un registre privé sur votre Gitlab.
  • Un cluster Kubernetes: orchestrateur de conteneurs, devenu très populaire au cours des dernières années que vous pouvez héberger vous même ou chez un hébergeur comme OVH.

COMMENT DEMMARER AVEC GITLAB CI ?

Pour commencer, nous allons construire un nouveau dépot pour notre projet ,puis nous utiliserons une relation directe entre les branches du dépôt Git du projet et les tags des images Docker, de sorte qu’une branche “develop” donnera une nouvelle image taguée “develop”.

Le fichier .gitlab-ci.yml ci-dessous teste, construit et déploie une application NodeJs vers un registre privé Docker hébergé sur notre GitLab.

Pour plus d’informations sur GitLab CI, veuillez vous référer à la documentation officielle.

variables:
  DOCKER_DRIVER: overlay2
  REGISTRY: $CI_REGISTRY
  IMAGE_TAG: $CI_REGISTRY_IMAGE
  K8S_DEPLOYMENT_NAME: deployment/$CI_PROJECT_NAME
  CONTAINER_NAME: $CI_PROJECT_NAME

stages:
  - test
  - build
  - build-docker

test:
  image: node:lts-slim
  stage: test
  script:
    - npm ci
    - npm run test

build:
  image: node:lts-slim
  stage: build
  artifacts:
    paths:
      - .
  script:
    - npm ci

build-docker:
  image: docker:latest
  stage: build-docker
  tags:
    - privileged
  only:
    - develop
  dependencies:
    - build
  script:
    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $REGISTRY
    - docker build --network host -t $IMAGE_NAME:$IMAGE_TAG -t $IMAGE_NAME:latest .
    - docker push $IMAGE_NAME:$IMAGE_TAG
    - docker push $IMAGE_NAME:latest

Le projet a également besoin d’un Dockerfile qui sera utilisé pour la construction de l’image Docker :

 

FROM node:lts-slim

WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 8080
CMD [ "npm", "start" ]

COMMENT CREER UN CLUSTER KUBERNETES RAPIDEMENT ?

OVH propose un service manage Kubernetes , et maintient l’ensemble des composants nécessaires a son bon fonctionnement ( master , nodes  … ).

Par défaut, les clusters sont sur la politique de sécurité “sécurité maximale”, ce qui signifie qu’ils obtiennent toutes les mises à jour de patchs automatiquement, ou vous pouvez faire les mises à jour manuellement (via l’interface web ou l’API).

Une fois que le cluster est crée,  vous pouvez ajouter des nœuds individuels, ils sont disponibles en différentes tailles et familles (CPU, RAM, IOPS… ).

Pour en savoir plus , n’hésitez pas à cliquer ici.

COMMENT  CONNECTER GITLAB CI/CD AVEC KUBERNETES ?

Par défaut, l’accès externe au registre GitLab Docker est interdit aux utilisateurs non authentifiés. Un moyen d’accorder un accès par projet à un cluster Kubernetes externe consiste à créer un Token d’authentification.

Afin de permettre une opération de récupération d’images, le jeton de déploiement doit être associé au scopes “read_registry”.

Le token d’authentification peut être enregistré comme secret sur le cluster Kubernetes en utilisant la commande create secret de kubectl

Exemple pour une application dans le namespace my-application :

kubectl create secret docker-registry regcred \
 --docker-server=Myregistry \
 --docker-username=XXXX --docker-password=XXXXXX \
 -n=my-application

COMMENT DEPLOYER UNE APPLICATION SUR KUBERNETES ?

Le déploiement décrit comment créer et mettre à jour les pods de votre application dans le cluster en fournissant des informations sur la façon d’obtenir et de maintenir les images et les conteneurs Docker.

Le tag spec.template.spec.imagePullSecrets déclare une référence au secret “regcred ” pour autoriser le cluster Kubernetes à télécharger les images Docker du registre privé.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: my-application
spec:
  replicas: 1
  selector:
    matchLabels:
      run: api
  template:
    metadata:
      labels:
        run: api
    spec:
      containers:
        - name: api
          image: Myregistry/api:latest
      imagePullSecrets:
        - name: regcred 

COMMENT REALISER DU DEPLOIEMENT CONTINU AVEC GITLAB CI/CD ET KUBERNETES ?

Après une construction réussie de notre chaine d’intégration continue , nous allons créer un compte de service Gitlab afin de réaliser un déploiement automatique de notre application sur notre cluster Kubernetes.

La définition ci-dessous établit un compte de service pour l’espace de noms my-application avec des privilèges d’administrateur :

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-service-account
  namespace: my-application
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: gitlab-service-account-role-binding
  namespace: my-application
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
  - kind: ServiceAccount
    name: gitlab-service-account
    namespace: my-application

Après avoir appliqué le manifeste ServiceAccount ci-dessus avec kubectl apply, le jeton peut être trouvé et obtenu via kubectl get-secret.

Ces références doivent être enregistrées auprès du GitLab en tant que variables pouvant être référencées à partir de l’étape de la chaîne de déploiement proprement dite :

  • CLUSTER_ADDRESS :  API du cluster Kubernetes
  • CA_AUTH_DATA : Certificat de cluster
  • K8S_TOKEN : Token du compte de service décodé en base64

Le fichier .gitlab-ci.yml étendu :

stages:
  - test
  - build
  - build-docker
  - deploy-k8s

deploy-k8s:
  image:
    name: kubectl:latest
    entrypoint: [""]
  stage: deploy
  tags:
    - privileged
  dependencies:
    - build-docker
  script:
    - kubectl config set-cluster k8s --server="$CLUSTER_ADDRESS"
    - kubectl config set clusters.k8s.certificate-authority-data $CA_AUTH_DATA
    - kubectl config set-credentials gitlab-service-account --token=$K8S_TOKEN
    - kubectl config set-context default --cluster=k8s --user=gitlab-service-account --namespace=my-application
    - kubectl config use-context default
    - kubectl set image $K8S_DEPLOYMENT_NAME $CI_PROJECT_NAME=$IMAGE_TAG
    - kubectl rollout restart $K8S_DEPLOYMENT_NAME