Comment déployer votre application plus rapidement ? Plusieurs solutions existent.
Dans cet article, nous vous présentons l’intérêt majeur de déployer une architecture DevOps avec le CI/CD et un orchestrateur Kubernetes.
Le terme DevOps est un raccourci qui signifie de Development Operations en anglais. Par conséquent, c’est une approche du développement informatique et de son opérationnalité (run).
Nous parlons donc d’une méthodologie pour améliorer en continu les pratiques informatiques pour assurer la bonne réalisation d’un projet IT.
Les enjeux du mouvement 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 alors entraîné un changement massif sur les processus de développement informatique afin d’être plus agile aux demandes du métier.
En réponse à ces enjeux qui poussent les organisations à s’améliorer continuellement, le mouvement DevOps et son architecture a été créée.
Quel est l’objectif de l’architecture DevOps ?
C’est avant tout une méthodologie qui rassemble les 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.
Planifier Développer Construire Tester Relire Déployer Opérer Vérifier Planifier
À quoi sert une chaine d’intégration et de déploiement continus CI/CD
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.
Tout d’abord, que signifie CI/CD ? C’est l’acronyme de Continuous Integration / Continuous Delivery. En d’autres termes, il s’agit d’une combinaison d’intégration et de livraison en continu.
Le CI/CD complète donc parfaitement votre démarche d’amélioration continue mise en place au sein de votre organisation.
Cela vous permet maintenant de comprendre un peu plus les raisons pour lesquelles il fait partie du processus de travail et pourquoi il a été adopté.
Mais ce n’est pas tout ! La mise en place d’une chaine d’intégration et de livraison continue – ci cd – est avant tout une question d’organisation des équipes
Voici un exemple :
Le responsable en charge du développement du produit fournit à son client les fonctionnalités nécessaires à la bonne application du produit. Il lui indique également le comportement à adopter pour la réussite du projet.
- Le responsable réalise une documentation complète et spécifique.
- Après avoir suivi les différentes étapes de gestion du projet informatique, c’est au tour des développeurs de jouer !
- premièrement, les développeurs réalisent le code source de l’application
- deuxièmement, ils effectuent des tests unitaires,
- troisièmement, ils poussent le code sur un logiciel de version (par exemple, git).
- Puis l’équipe de l’assurance qualité (AQ) effectuent une batterie de tests :
- des tests d’acceptation par l’utilisateur
- des tests d’intégration
- des tests de performance
Pendant cette période, il ne doit avoir aucune modification de la base de code jusqu’à ce que la phase d’AQ soit terminée. En cas d’anomalie détectée, les différentes tâches de la phase d’assurance qualité est retournée aux développeurs pour correction avant d’être soumis à nouveau aux testes de l’Assurance Qualité.
Quelles solutions pour créer notre architecture devops ?
Pour construire notre architecture devops avec une chaine ci cd , 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.
- un 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 containers, 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 OVHcloud.
Découvrir notre offre chez OVH cloud : Cluster Kubernetes Infogere
Comment démarrer avec GitLab pour créer une chaine CI CD ?
Pour bien démarrer, vous trouverez ci-dessous les différentes étapes que nous réalisons.
Premièrement, nous construisons un nouveau dépôt pour notre projet. Deuxièmement, nous utilisons 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” donne 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
- 2. 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 créer un cluster Kubernetes rapidement ?
OVH propose un service manage Kubernetes pour héberger vos applications conteneurisées, et maintient l’ensemble des composants nécessaires à son bon fonctionnement ( master , nodes … ).
Par défaut, les clusters sont sur la politique de sécurité “sécurité maximale”. Cela signifie qu’ils obtiennent toutes les mises à jour de patchs automatiquement. Bien entendu, 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 alors ê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 déployer 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 réaliser du déploiement 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