Resources attached to the Road To DevOps tutorial https://blog.noobtoroot.xyz/road-to-devops/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 

13 KiB

GitLab

GitLab

Christian Tritten

Présentation

  • GitLab est une solution d’hébergement de projets Git public ou privés.

  • Fonctionnalités comparables à celles de GitHub.

  • Interface graphique simple et agréable.

  • Utilisable par tous les métiers
    (Product Owner, Dev, Exploitant)

  • S'inscrit totalement dans la mouvance DevOps.

3 versions distinctes

  • Version hébergée sur gitlab.com

  • Version on-premise

  • Version communautaire gratuite et open source

GitLab en tête selon Forrester

Forrester has evaluated GitLab as a Leader in Continuous Integration

(septembre 2017)

Groupe / Projet

  • GitLab utilise un découpage en Groupes et Projets

  • En gros : 1 projet = 1 application / composant

  • Les groupes permettent l'organisation des projets

gitlab screen projects

Chaque projet possède

  • un mode d'accès : privé, interne ou public

  • une liste de contributeurs avec différents niveaux de droits

  • des outils (dépôt de code, wiki, intégration continue, ...)

Note:

  • accès privé : sur invitation seulement
  • accès interne : tous les membres authentifiés
  • accès public : tout le monde

Fonctionnalités principales

  • Dépôt de code source

  • Suivi d'anomalies et de fonctionnalités

  • Collaboration via Merge Requests

  • Documentation

Autres fonctionnalités

  • Wiki

  • Intégration et livraison continues

  • Entrepôt d'images Docker

  • Hébergement de sites web statiques

  • Intégration avec des plateformes de communication collaboratives (Mattermost, Slack...)

Tout en un !

  • GitLab se positionne tranquillement sur l'ensemble de la chaine DevOps.

  • GitLab fourni au sein d'une interface unifiée un maximum d'outils permettant de faciliter la mise en place d'une approche DevOps sur un projet de développement.

Cycle de vie DevOps avec Gitlab

Dépôt de code source

  • C'est la fonctionnalité première de GitLab

  • Seule la technologie git est supportée

  • Multi-utilisateurs

  • Multi-projets

gitlab screen files

gitlab screen commits

gitlab screen commit diff

Suivi d'anomalies et de fonctionnalités

  • Le terme "issue" peut représenter :

    • un ticket de déclaration d'anomalie (un bug !)

    • un ticket de demande de fonctionnalité

    • un ticket de suggestion d'amélioration

    • un ticket de tâche à effectuer

    • ...

Labels

  • Une "issue" peut être associée à un ou plusieurs labels.

  • Les labels permettent l'organisation et le filtrage des issues, par niveau de traitement ou type d'activité par exemples.

gitlab screen issues list

Assignation

  • Une "issue" peut être assigné à une des personnes associées au projet en vue de son traitement.

  • La personne en question se voit automatiquement notifiée.

gitlab screen issue

Discussion

  • Une "issue" peut être discutée via un système de commentaires intégré.

gitlab screen issue

Organisation

  • La vue "Board", présentée sous la forme d'un tableau à colonne permet :

    • d'avoir une vision complète des tickets en cours,

    • d'organiser le travail selon un workflow configurable,

    • de prioriser les tickets les uns par rapports aux autres.

gitlab screen issue board

Collaboration via Merge Requests

  • GitHub a popularisé un principe de partage de code appelé Pull Request.

  • Ce concept est également présent dans GitLab sous le nom de Merge Request.

Qu'est-ce qu'une Merge Request ?

  • Les Merge Requests permettent d'échanger du code facilement et facilitent la collaboration entre les personnes qui travaillent sur le même projet.

  • Une Merge Request est simplement une demande (Request) de fusion (Merge) d'une branche git dans une autre.

Workflow d'une Merge Request

  1. Cloner le projet

  2. Créer une branche et travailler dessus

  3. Publier la branche

  4. Créer la Merge Request

  5. Revue de code (+ Discussion) du contenu de la Merge Request

  6. Fusionner la branche

Documentation

  • La documentation d'un projet s'effectue via la création de fichiers textes :

    • au format Markdown (extension .md),

    • eux-même versionnées dans le projet,

    • par exemple le README.md qui décrit un projet.

  • L'édition en ligne est possible.

  • Syntaxe Markdown : https://daringfireball.net/projects/markdown/syntax

Wiki

  • Chaque projet peut avoir son propre wiki dédié.

  • Les fichiers du wiki sont versionnés séparément des fichiers du projet.

Entrepôt d'images Docker

Plateforme de communication

  • Via l'outil Mattermost

  • Fonctionnalités

    • Discussion instantanée
      • individuelle, en groupe public ou privés
    • Partage de fichiers

mattermost screen

Hébergement de pages web statiques

  • GitLab Pages est un service d'hébergement de pages web statiques.

  • GitLab Pages permet par exemple de publier la documentation de vos applications.

  • Gitlab Pages

    • utilise Gitlab CI, le système d'intégration continue de Gitlab,

    • pour générer des sites statiques

      • à partir de simple pages html

      • ou à l'aide de générateurs (tels que Hugo ou Pelican).

Intégration et livraison continues

GitLab CI / CD

L'intégration continue

consiste à vérifier à chaque
modification du code source
que le résultat des modifications
ne produit pas de régression
dans l'application développée.

Intérêt de l'intégration continue

  • Résultats de la compilation et des tests visibles par l'ensemble de l'équipe.

  • Détection et correction des problèmes d'intégration au plus tôt lors du développement.
    (avant de merger dans la branche de production)

  • Automatisation de l'exécution de suites de tests qui vérifient la qualité et la cohésion du code produit.

Note:

  • Problèmes d'intégration : par exemple, un oubli d'inclusion, des dépendances cassées, des régressions possibles, ...
  • Qualité du code : par exemple, les test unitaires, le respect des normes de nommage, de programmation, ...

La livraison continue

consiste à délivrer les applications
dans des cycles courts,
permettant ainsi de les mettre à disposition
à n’importe quel moment.

Le déploiement continu

consiste à déployer le résultat
de la livraison sur un serveur
sans opération manuelle.

La livraison d’une application sur un serveur n’est pas une opération anodine et triviale.

Elle implique souvent l'exécution de multiples tâches annexes et présente toujours un risque qu'il faut maîtriser lorsque il s'agit de l'environnement de production.

Intérêt de la livraison et du déploiement continus

  • Automatisation du packaging, de la livraison et du déploiement de l'application afin de rendre ces processus fiables et répétables.

  • Augmentation de la fréquence des livraisons et du déploiement.

CI-CD

Déclenchement

Ces étapes d'intégration et de livraison continues sont déclenchables selon des évènements pré-définis, comme :

  • le push d'un commit git,

  • la création d'un tag git,

  • une planification,

  • un appel sur l'API GitLab,

  • un déclenchement manuel.

Pipelines, Stages et Jobs

  • Le processus complet est appelé Pipeline.

  • Chaque Pipeline est composé
    d'une ou plusieurs étapes (Stages).

  • Chaque Stage est composé
    d'une ou plusieurs tâches (Jobs).

gitlab screen pipelines

Déclaration d'un Pipeline

  • Dans GitLab un Pipeline est défini dans le fichier .gitlab-ci.yml

  • Ce fichier est directement versionné dans le projet.

gitlab screen pipeline definition

Runners

Architecture runners

Chaque étape du Pipeline est exécutée sur une machine spéciale appelée Runner.

  • Chaque étape peut faire appel à un Runner différent, spécialisé pour la tâche en question (build, packaging, ...).

  • Les Runners peuvent être conteneurisés.

Exécution du Pipeline

  • L'exécution d'un Pipeline peut être dans les états :

    • running,

    • pending,

    • passed,

    • failed.

gitlab screen pipelines

gitlab screen pipelines

Dans tous les cas il est possible d'accéder au détail de la tâche pour débugger.

gitlab screen pipelines

Un gros Pipeline !

gitlab screen pipeline with a lot of stages

Possibilité de forcer un mode manuel pour les mises en production.

Configurer un Pipeline CI / CD

.gitlab-ci.yml

pipeline

.gitlab-ci.yml

stages:
  - build-script
  - build-image
  - deploy
  - check-deployment

variables:
  IMAGE_RELEASE_NAME: who-is-there:$CI_COMMIT_TAG
  IMAGE_REGISTRY_RELEASE_NAME: $DOCKER_HUB_USER/who-is-there:$CI_COMMIT_TAG
  DEPLOYMENT_WIT_REPLICAS: 3

pipeline

.gitlab-ci.yml

# Compile go source file
build-go-script:
  stage: build-script
  image: golang:1.9.2
  only:
    # Execute the job only if a git tag is pushed
    - tags
  tags:
    # Execute the job only on the runner tagged 'kubernetes'
    - kubernetes
  before_script:
    # Create a symbolic link under $GOPATH,
    # this is needed for local build
    - cd $GOPATH/src
    - mkdir -p gitlab/$CI_PROJECT_NAMESPACE
    - cd gitlab/$CI_PROJECT_NAMESPACE
    - ln -s $CI_PROJECT_DIR
    - cd $CI_PROJECT_NAME
  script:
    # Build full static binary
    - go build -ldflags "-linkmode external -extldflags -static" -o who-is-there
    - chmod +x who-is-there
  artifacts:
    paths:
      - who-is-there

pipeline

.gitlab-ci.yml

# Build a Docker image containing the binary
# generated in job build-go-script
build-docker-image:
  stage: build-image
  image: docker:18.03
  only:
    # Execute the job only if a git tag is pushed
    - tags
  tags:
    # Execute the job only on the runner tagged 'kubernetes'
    - kubernetes
  dependencies:
    - build-go-script
  script:
    - ls -l
    - docker build -t $IMAGE_RELEASE_NAME .
    - docker tag $IMAGE_RELEASE_NAME $IMAGE_REGISTRY_RELEASE_NAME
    - docker image ls
    - docker login -u $DOCKER_HUB_USER -p $DOCKER_HUB_PASS
    - docker push $IMAGE_REGISTRY_RELEASE_NAME

pipeline

.gitlab-ci.yml

# Deploy or update the application
# on the Kubernetes cluster
deploy-on-k8s:
  stage: deploy
  image: xian310/kubectl-proxy:1.11
  only:
    # Execute the job only if a git tag is pushed
    - tags
  tags:
    # Execute the job only on the runner tagged 'kubernetes'
    - kubernetes
  script:
    - cat k8s/wit.deployment.yml.template | envsubst \
        '$IMAGE_REGISTRY_RELEASE_NAME,$DEPLOYMENT_WIT_REPLICAS' > k8s/wit.deployment.yml
    - ls -l
    - kubectl apply -f k8s/wit.namespace.yml
    - kubectl apply -f k8s/wit.service.yml
    - kubectl apply -f k8s/wit.deployment.yml

pipeline

.gitlab-ci.yml

# Check the deployment of the application
# on the Kubernetes cluster
check-deployment-on-k8s:
  stage: check-deployment
  image: busybox
  only:
    # Execute the job only if a git tag is pushed
    - tags
  tags:
    # Execute the job only on the runner tagged 'k8s'
    - kubernetes
  script:
    - for i in 1 2 3 4 5 ; do wget wit.wit.svc.cluster.local:8080 -qO - ; sleep 1 ; done

Liens

GitLab

Liens

Git