Bonjour ! Dernièrement, de nombreux outils d'automatisation performants ont été lancés pour la création d'images Docker et le déploiement sur Kubernetes. C'est pourquoi j'ai décidé de tester Gitlab, d'étudier ses fonctionnalités en profondeur et, bien sûr, de mettre en place un pipeline.

L'inspiration pour ce travail était le site Web kubernetes.io, qui est généré à partir de codes sources automatiquement, et pour chaque pull request envoyée, le robot génère automatiquement une version d'aperçu du site avec vos modifications et fournit un lien pour la visualisation.

J'ai essayé de créer un processus similaire de A à Z, mais entièrement basé sur Gitlab CI et les outils gratuits que j'utilisais pour déployer des applications sur Kubernetes. Aujourd'hui, je vais enfin vous en dire plus.

L'article couvrira des outils tels que :
Hugo, Québec, Kaniko, git-crypte и CI GitLab avec la création d'environnements dynamiques.

contenu

Apprendre à connaître Hugo
Préparation du Dockerfile
Apprendre à connaître Kaniko
Apprendre à connaître qbec
Essai de Gitlab-runner avec Kubernetes-executor
Déploiement de graphiques Helm avec qbec
Découvrir Git-Crypt
Créer une image de boîte à outils
Notre premier pipeline et l'assemblage d'images par tags
Automatisation du déploiement
Artefacts et assemblage lors de la poussée vers le maître
Environnements dynamiques
Examiner les applications

1. Apprendre à connaître Hugo

À titre d'exemple de notre projet, nous allons créer un site de publication de documentation basé sur Hugo. Hugo est un générateur de contenu statique.

Pour ceux qui ne connaissent pas les générateurs statiques, je vais vous les présenter plus en détail. Contrairement aux moteurs de site web classiques, dotés d'une base de données et de PHP, qui génèrent des pages à la volée à la demande de l'utilisateur, les générateurs statiques sont organisés différemment. Ils permettent de récupérer le code source, généralement un ensemble de fichiers au format Markdown et des modèles de thème, puis de le compiler pour obtenir un site web complet.

Autrement dit, à la sortie, vous recevrez une structure de répertoire et un ensemble de fichiers HTML générés, que vous pourrez simplement télécharger sur n'importe quel hébergement bon marché et obtenir un site fonctionnel.

Hugo peut être installé localement et testé :

Initialiser un nouveau site :

hugo new site docs.example.org

Et aussi un dépôt git :

cd docs.example.org
git init

Pour l'instant, notre site est vierge et pour que quelque chose y apparaisse, nous devons d'abord connecter un thème, un thème est juste un ensemble de modèles et de règles spécifiées par lesquels notre site est généré.

Comme sujet, nous utiliserons Apprendre, qui, à mon avis, est le plus adapté à un site de documentation.

Je voudrais accorder une attention particulière au fait que nous n'avons pas besoin d'enregistrer les fichiers de thème dans notre référentiel de projet, mais nous pouvons simplement le connecter en utilisant sous-module git:

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

De cette façon, notre référentiel ne contiendra que des fichiers directement liés à notre projet, et le thème connecté restera sous forme de lien vers un référentiel spécifique et un commit dans celui-ci, ce qui signifie qu'il peut toujours être extrait de la source d'origine sans crainte de modifications incompatibles.

Corrigeons la configuration config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

Déjà à ce stade vous pouvez lancer :

hugo server

Et à l'adresse http://localhost:1313/ consultez notre site nouvellement créé, toutes les modifications apportées dans l'annuaire sont automatiquement mises à jour et la page ouverte dans le navigateur, très pratique !

Essayons de créer une page de titre dans contenu/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Capture d'écran de la page nouvellement créée

Pour générer un site Web, exécutez simplement :

hugo

Contenu du répertoire Publique/ et sera votre site Web.
Oui, au fait, ajoutons-le tout de suite .gitignore:

echo /public > .gitignore

N'oubliez pas de valider nos modifications :

git add .
git commit -m "New site created"

2. Préparation du Dockerfile

Il est maintenant temps de définir la structure de notre dépôt. J'utilise généralement quelque chose comme :

.
├── deploy
│   ├── app1
│   └── app2
└── dockerfiles
    ├── image1
    └── image2

dockerfiles/ — contient des répertoires avec des Dockerfiles et tout ce qui est nécessaire à la construction de nos images Docker.
déployer/ — contient des répertoires pour déployer nos applications sur Kubernetes

Nous allons donc créer notre premier Dockerfile le long du chemin dockerfiles/site web/Dockerfile

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

Comme vous pouvez le voir, le Dockerfile contient deux De, cette opportunité s'appelle construction en plusieurs étapes et vous permet d'exclure tout ce qui est inutile de l'image Docker finale.
Ainsi, notre image finale ne contiendra que darkhttpd (serveur HTTP léger) et Publique/ — le contenu de notre site généré statiquement.

N'oubliez pas de valider nos modifications :

git add dockerfiles/website
git commit -m "Add Dockerfile for website"

3. Apprendre à connaître Kaniko

En tant que constructeur d'images Docker, j'ai décidé d'utiliser Kaniko, car il ne nécessite pas de démon Docker pour fonctionner, et la construction elle-même peut être effectuée sur n'importe quelle machine et le cache peut être stocké directement dans le registre, éliminant ainsi le besoin d'avoir un stockage persistant à part entière.

Pour construire une image, il suffit de lancer un conteneur avec Kaniko Executive et lui passer le contexte de construction actuel, cela peut être fait localement, via docker :

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

Où registry.gitlab.com/kvaps/docs.example.org/website — le nom de votre image Docker, après sa construction, elle sera automatiquement lancée dans le registre Docker.

Paramètre —cache vous permet de mettre en cache des couches dans le registre Docker, pour l'exemple donné, elles seront enregistrées dans registry.gitlab.com/kvaps/docs.example.org/website/cache, mais vous pouvez spécifier un autre chemin en utilisant le paramètre —cache-repo.

Capture d'écran de docker-registry

4. Apprendre à connaître qbec

Qbec — est un outil de déploiement qui vous permet de décrire de manière déclarative les manifestes de vos applications et de les déployer sur Kubernetes. L'utilisation de Jsonnet comme syntaxe sous-jacente simplifie grandement la description des différences entre environnements et élimine presque entièrement la répétition de code.

Cela peut être particulièrement pertinent dans les cas où vous devez déployer une application sur plusieurs clusters avec des paramètres différents et que vous souhaitez les décrire de manière déclarative dans Git.

Qbec permet également de générer des graphiques Helm en leur transmettant les paramètres nécessaires, puis de les exploiter comme des manifestes classiques, y compris en leur imposant diverses mutations. Cela élimine ainsi le recours à ChartMuseum. Autrement dit, vous pouvez stocker et générer des graphiques directement depuis Git, là où ils se trouvent.

Comme je l’ai dit précédemment, nous stockerons tous les déploiements dans le répertoire déployer/:

mkdir deploy
cd deploy

Initialisons notre première application :

qbec init website
cd website

Maintenant, la structure de notre application ressemble à ceci :

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

regardons le fichier qbec.yaml:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

Ce qui nous intéresse ici est principalement environnements spécifiques, qbec a déjà créé un environnement par défaut pour nous et a pris l'adresse du serveur et l'espace de noms de notre kubeconfig actuel.
Maintenant, lors du déploiement sur défaut environnement, qbec se déploiera toujours uniquement sur le cluster Kubernetes spécifié et sur l'espace de noms spécifié, ce qui signifie que vous n'avez plus besoin de basculer entre les contextes et les espaces de noms pour effectuer un déploiement.
Si nécessaire, vous pouvez toujours mettre à jour les paramètres dans ce fichier.

Tous vos environnements sont décrits dans qbec.yaml, et dans le fichier params.libson.net, où il est indiqué où obtenir les paramètres pour eux.

Ensuite, nous voyons deux répertoires :

composants / — tous les manifestes de notre application seront stockés ici, ils peuvent être décrits à la fois dans jsonnet et dans des fichiers yaml classiques
environnements/ — ici nous allons décrire toutes les variables (paramètres) de nos environnements.

Par défaut, nous avons deux fichiers :

environnements/base.libsonnet - il contiendra des paramètres communs à tous les environnements
environnements/default.libsonnet — contient des paramètres redéfinis pour l'environnement défaut

Ouvrons-le environnements/base.libsonnet et ajoutez-y les paramètres de notre premier composant :

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1',
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

Créons également notre premier composant composants/siteweb.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.website;

[
  {
    apiVersion: 'apps/v1',
    kind: 'Deployment',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      replicas: params.replicas,
      selector: {
        matchLabels: {
          app: params.name,
        },
      },
      template: {
        metadata: {
          labels: { app: params.name },
        },
        spec: {
          containers: [
            {
              name: 'darkhttpd',
              image: params.image,
              ports: [
                {
                  containerPort: params.containerPort,
                },
              ],
            },
          ],
          nodeSelector: params.nodeSelector,
          tolerations: params.tolerations,
          imagePullSecrets: [{ name: 'regsecret' }],
        },
      },
    },
  },
  {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      selector: {
        app: params.name,
      },
      ports: [
        {
          port: params.servicePort,
          targetPort: params.containerPort,
        },
      ],
    },
  },
  {
    apiVersion: 'extensions/v1beta1',
    kind: 'Ingress',
    metadata: {
      annotations: {
        'kubernetes.io/ingress.class': params.ingressClass,
      },
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      rules: [
        {
          host: params.domain,
          http: {
            paths: [
              {
                backend: {
                  serviceName: params.name,
                  servicePort: params.servicePort,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Dans ce fichier, nous avons décrit trois entités Kubernetes à la fois, à savoir : Déploiement, Services и EntréeSi nous le voulions, nous pourrions les déplacer dans différents composants, mais à ce stade, un seul nous suffira.

syntaxe jsonnet très similaire au json normal, en principe le json normal est déjà un jsonnet valide, donc au début il pourrait être plus facile pour vous d'utiliser des services en ligne comme yaml2json pour convertir votre yaml habituel en json, ou, si vos composants ne contiennent aucune variable, ils peuvent alors être décrits comme du yaml normal.

Lorsque vous travaillez avec jsonnet Je vous recommande fortement d'installer un plugin pour votre éditeur
Par exemple, il existe un plugin pour vim vim-jsonnet, qui permet la coloration syntaxique et exécute automatiquement jsonnet fmt à chaque sauvegarde (nécessite l'installation de jsonnet).

Tout est prêt, nous pouvons maintenant commencer le déploiement :

Pour voir ce que nous avons obtenu, exécutons :

qbec show default

La sortie vous montrera les manifestes yaml rendus qui seront appliqués au cluster par défaut.

Super, maintenant appliquons-le :

qbec apply default

En sortie vous verrez toujours ce qui sera fait dans votre cluster, qbec vous demandera d'accepter les modifications en tapant y vous pourrez confirmer vos intentions.

C'est fait, maintenant notre application est déployée !

Si vous apportez des modifications, vous pouvez toujours :

qbec diff default

pour voir comment ces changements affecteront le déploiement actuel

N'oubliez pas de valider nos modifications :

cd ../..
git add deploy/website
git commit -m "Add deploy for website"

5. Essayer Gitlab-runner avec Kubernetes-executor

Jusqu'à récemment, je n'utilisais que le modèle normal gitlab-runner Sur une machine pré-préparée (conteneur LXC) avec un shell ou un exécuteur Docker. Initialement, nous disposions de plusieurs exécuteurs de ce type définis globalement dans notre Gitlab. Ils créaient des images Docker pour tous les projets.

Mais comme l'a montré la pratique, cette option n'est pas idéale, tant en termes de praticité que de sécurité. Il est bien plus judicieux, et idéologiquement plus juste, de déployer des exécuteurs distincts pour chaque projet, voire pour chaque environnement.

Heureusement, ce n’est pas du tout un problème, car nous allons maintenant déployer gitlab-runner directement dans le cadre de notre projet directement dans Kubernetes.

Gitlab fournit un diagramme Helm prêt à l'emploi pour le déploiement de gitlab-runner sur Kubernetes. Il vous suffit donc de savoir : jeton d'enregistrement pour notre projet en Paramètres -> CI / CD -> Runners et passe-le à la barre :

helm repo add gitlab https://charts.gitlab.io

helm install gitlab-runner 
  --set gitlabUrl=https://gitlab.com 
  --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc 
  --set rbac.create=true 
  gitlab/gitlab-runner

Où:

https://gitlab.com — l'adresse de votre serveur Gitlab.
yga8y-jdCusVDn_t4Wxc — jeton d'enregistrement pour votre projet.
rbac.create=true — accorde au coureur la quantité nécessaire de privilèges pour pouvoir créer des pods pour exécuter nos tâches à l'aide de kubernetes-executor.

Si tout est fait correctement, vous devriez voir le coureur inscrit dans la section Runners, dans les paramètres de votre projet.

Capture d'écran du coureur ajouté

C'est aussi simple que ça ? Oui, c'est aussi simple que ça ! Plus besoin d'enregistrer manuellement les coureurs : désormais, ils seront créés et supprimés automatiquement.

6. Déploiement de cartes Helm avec QBEC

Depuis que nous avons décidé de compter gitlab-runner une partie de notre projet, il est temps de le décrire dans notre dépôt Git.

Nous pourrions le décrire comme un composant séparé site, mais à l'avenir, nous prévoyons de déployer différentes copies site très souvent, contrairement à gitlab-runner, qui ne sera déployé qu'une seule fois par cluster Kubernetes. Initialisons donc une application distincte pour cela :

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Cette fois, nous ne décrirons pas manuellement les entités Kubernetes, mais utiliserons un graphique Helm prêt à l'emploi. L'un des avantages de qbec est la possibilité de générer des graphiques Helm directement depuis un dépôt Git.

Activons-le en utilisant le sous-module git :

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

Maintenant le répertoire fournisseur/gitlab-runner contient notre référentiel avec un graphique pour gitlab-runner.

De la même manière, vous pouvez connecter d'autres référentiels, par exemple l'intégralité du référentiel avec les graphiques officiels https://github.com/helm/charts

Décrivons le composant composants/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

Le premier argument à développerHelmTemplate nous passons le chemin vers le graphique, puis paramètres.valeurs, que nous prenons à partir des paramètres d'environnement, puis vient l'objet avec

nomModèle — titre de la sortie
namespace - espace de noms transmis à helm
ce fichier — un paramètre obligatoire qui transmet le chemin d'accès au fichier actuel
verbeux - montre la commande Modèle de barre avec tous les arguments lors du rendu du graphique

Décrivons maintenant les paramètres de notre composant dans environnements/base.libsonnet:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
      },
    },
  },
}

Noter jeton d'enregistrement du coureur nous prenons à partir d'un fichier externe secrets/base.libson.net, créons-le :

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Vérifions si tout fonctionne :

qbec show default

si tout va bien, nous pouvons alors supprimer notre version précédemment déployée via Helm :

helm uninstall gitlab-runner

et le déployer, mais via qbec :

qbec apply default

7. Introduction à git-crypt

Git-crypt — est un outil qui vous permet de configurer un cryptage transparent pour votre référentiel.

Pour le moment, notre structure de répertoire pour gitlab-runner ressemble à ceci :

.
├── components
│   ├── gitlab-runner.jsonnet
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
├── qbec.yaml
├── secrets
│   └── base.libsonnet
└── vendor
    └── gitlab-runner (submodule)

Mais stocker des secrets dans Git n'est pas sûr, n'est-ce pas ? Il faut donc les chiffrer correctement.

Généralement, pour une seule variable, cela n'a pas toujours de sens. Vous pouvez transmettre des secrets. Québec et via les variables d'environnement de votre système CI.
Mais il convient de noter qu'il existe également des projets plus complexes qui peuvent contenir beaucoup plus de secrets ; les transmettre tous via des variables d'environnement sera extrêmement difficile.
De plus, dans ce cas, je ne pourrais pas vous parler d’un outil aussi merveilleux que git-crypte.
git-crypte C'est également pratique car cela vous permet de sauvegarder l'intégralité de l'historique des secrets, ainsi que de comparer, fusionner et résoudre les conflits de la même manière que nous avons l'habitude de le faire avec Git.

Première chose après l'installation git-crypte nous devons générer des clés pour notre référentiel :

git crypt init

Si vous disposez d'une clé PGP, vous pouvez immédiatement vous ajouter en tant que collaborateur pour ce projet :

git-crypt add-gpg-user kvapss@gmail.com

De cette façon, vous pourrez toujours décrypter ce référentiel à l'aide de votre clé privée.

Si vous n’avez pas de clé PGP et ne prévoyez pas d’en avoir une, vous pouvez procéder dans l’autre sens et exporter la clé du projet :

git crypt export-key /path/to/keyfile

Ainsi, quiconque a exporté fichier clé sera capable de décrypter votre dépôt.

Il est temps de mettre en place notre premier secret.
Je vous rappelle que nous sommes toujours dans l'annuaire. déployer/gitlab-runner/, où nous avons un répertoire secrets/, chiffrons tous les fichiers qu'il contient, pour cela nous allons créer un fichier secrets/.gitattributes avec le contenu suivant :

* filter=git-crypt diff=git-crypt
.gitattributes !filter !diff

Comme vous pouvez le voir dans le contenu, tous les fichiers sont classés par masque * sera exécuté à travers git-crypte, à l'exception de celui-là même .gitattributes

Nous pouvons vérifier cela en exécutant :

git crypt status -e

La sortie sera une liste de tous les fichiers du référentiel pour lesquels le chiffrement est activé.

Voilà, nous pouvons maintenant valider nos modifications en toute sécurité :

cd ../..
git add .
git commit -m "Add deploy for gitlab-runner"

Pour bloquer un dépôt, exécutez simplement :

git crypt lock

et immédiatement tous les fichiers cryptés se transformeront en quelque chose de binaire, il sera impossible de les lire.
Pour décrypter le référentiel, exécutez :

git crypt unlock

8. Créer une image de boîte à outils

L'image Toolbox contient tous les outils nécessaires au déploiement de notre projet. GitLabRunner l'utilisera pour effectuer les tâches de déploiement courantes.

Tout est simple ici, créons-en un nouveau dockerfiles/boîte à outils/Dockerfile avec le contenu suivant :

FROM alpine:3.11

RUN apk add --no-cache git git-crypt

RUN QBEC_VER=0.10.3 
 && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz 
     | tar -C /tmp -xzf - 
 && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/

RUN KUBECTL_VER=1.17.0 
 && wget -O /usr/local/bin/kubectl 
      https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl 
 && chmod +x /usr/local/bin/kubectl

RUN HELM_VER=3.0.2 
 && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz 
     | tar -C /tmp -zxf - 
 && mv /tmp/linux-amd64/helm /usr/local/bin/helm

Comme vous pouvez le voir, dans cette image, nous installons tous les utilitaires utilisés pour déployer notre application. Nous n'en avons besoin que de kubectl, mais vous souhaiterez peut-être jouer avec pendant l'étape de configuration du pipeline.

De plus, pour pouvoir communiquer avec Kubernetes et y déployer, nous devons configurer un rôle pour les pods générés par gitlab-runner.

Pour ce faire, allez dans le répertoire contenant gitlab-runner :

cd deploy/gitlab-runner

et ajouter un nouveau composant composants/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

Nous décrirons également les nouveaux paramètres dans environnements/base.libsonnet, qui ressemble maintenant à ceci :

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
        runners: {
          serviceAccountName: $.components.rbac.name,
          image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1',
        },
      },
    },
    rbac: {
      name: 'gitlab-runner-deploy',
    },
  },
}

Noter $.components.rbac.name fait référence à Le nom pour le composant rbac

Voyons ce qui a changé :

qbec diff default

et appliquer nos modifications à Kubernetes :

qbec apply default

N'oubliez pas non plus de valider nos modifications dans git :

cd ../..
git add dockerfiles/toolbox
git commit -m "Add Dockerfile for toolbox"
git add deploy/gitlab-runner
git commit -m "Configure gitlab-runner to use toolbox"

9. Notre premier pipeline et l'assemblage d'images par balises

A la racine du projet nous allons créer .gitlab-ci.yml avec le contenu suivant :

.build_docker_image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.15.0
    entrypoint: [""]
  before_script:
    - echo "{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}" > /kaniko/.docker/config.json

build_toolbox:
  extends: .build_docker_image
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG
  only:
    refs:
      - tags

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG
  only:
    refs:
      - tags

Veuillez noter que nous utilisons GIT_SUBMODULE_STRATEGY : normal pour les tâches où vous devez initialiser explicitement les sous-modules avant l'exécution.

N'oubliez pas de valider nos modifications :

git add .gitlab-ci.yml
git commit -m "Automate docker build"

Je pense que nous pouvons sans risque appeler cela une version v0.0.1 et accrochez l'étiquette :

git tag v0.0.1

Nous ajouterons des balises à chaque nouvelle version. Les balises des images Docker seront liées aux balises Git. Chaque push avec une nouvelle balise initialisera la construction des images portant cette balise.

Nous le ferons git push --tags, et regardons notre premier pipeline :

Capture d'écran du premier pipeline

Il est important de noter que les builds basés sur des balises conviennent à la création d'images Docker, mais pas au déploiement d'une application sur Kubernetes. Puisque de nouvelles balises peuvent être attribuées à d'anciens commits, l'initialisation du pipeline pour ces derniers entraînera le déploiement de l'ancienne version.
Pour résoudre ce problème, les builds d’images Docker sont généralement liées à des balises et le déploiement d’applications est lié à une branche. maître, où les versions des images collectées sont codées en dur. Dans ce cas, vous pouvez initialiser la restauration par un simple retour en arrière. maître-branches.

10. Automatisation du déploiement

Pour que Gitlab-runner puisse décrypter nos secrets, nous devrons exporter la clé du référentiel et l'ajouter à nos variables d'environnement CI :

git crypt export-key /tmp/docs-repo.key
base64 -w0 /tmp/docs-repo.key; echo

Nous allons enregistrer la chaîne résultante dans Gitlab, pour ce faire nous irons dans les paramètres de notre projet :
Paramètres -> CI / CD -> Variables

Et créons une nouvelle variable :

Type
ACTIVITES
Valeur
Protégé
Masqué
Domaine

File
GITCRYPT_KEY
<your string>
true (pendant la période de formation, il est possible et false)
true
All environments

Capture d'écran de la variable ajoutée

Maintenant, mettons à jour le nôtre .gitlab-ci.yml en y ajoutant :

.deploy_qbec_app:
  stage: deploy
  only:
    refs:
      - master

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes

deploy_website:
  extends: .deploy_qbec_app
  script:
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes

Ici, nous avons activé plusieurs nouvelles options pour qbec :

—rooter certaines/applications — permet de définir le répertoire d'une application spécifique
--force:k8s-context __incluster__ — Il s'agit d'une variable magique qui indique que le déploiement aura lieu dans le même cluster que celui où s'exécute gtilab-runner. Cette opération est indispensable, car sinon qbec tentera de trouver un serveur Kubernetes approprié dans votre kubeconfig.
-attendez — fait attendre qbec jusqu'à ce que les ressources qu'il crée passent à l'état Prêt et ne sortent qu'ensuite avec un code de sortie réussi.
-Oui - désactive simplement le shell interactif Es-tu sûr? lors du déploiement.

N'oubliez pas de valider nos modifications :

git add .gitlab-ci.yml
git commit -m "Automate deploy"

Et après git push nous verrons comment nos applications ont été déployées :

Capture d'écran du deuxième pipeline

11. Artefacts et assemblage lors de la poussée vers le master

En général, les étapes ci-dessus suffisent à créer et à livrer presque n'importe quel microservice, mais nous ne souhaitons pas ajouter une balise à chaque mise à jour du site. Par conséquent, nous allons adopter une approche plus dynamique et configurer le déploiement par digest dans la branche principale.

L'idée est simple : maintenant l'image de notre site sera reconstruit à chaque fois que vous enfoncerez maître, puis déployé automatiquement sur Kubernetes.

Mettons à jour ces deux emplois dans notre .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

Veuillez noter que nous avons ajouté une branche maître к réfs pour le travail construire_site_web et maintenant nous utilisons $CI_COMMIT_REF_NAME au lieu de $CI_COMMIT_TAG, c'est-à-dire que nous nous détachons des balises dans Git et que nous allons maintenant pousser une image portant le nom de la branche du commit ayant initialisé le pipeline. Il est à noter que cela fonctionnera également avec les balises, ce qui nous permettra d'enregistrer des instantanés du site avec une certaine version dans le registre Docker.

Bien que le nom de la balise Docker pour une nouvelle version d'un site puisse rester inchangé, nous devons toujours décrire les modifications apportées à Kubernetes, sinon il ne redéployera tout simplement pas l'application à partir de la nouvelle image, car il ne remarquera aucun changement dans le manifeste de déploiement.

Option —vm:ext-str digest=”$DIGEST” Pour qbec, vous pouvez transmettre une variable externe à Jsonnet. Nous souhaitons que notre application soit redéployée dans le cluster à chaque nouvelle version. Nous ne pouvons plus utiliser le nom de la balise, désormais immuable, car nous devons l'associer à une version spécifique de l'image et déclencher le déploiement lorsqu'elle change.

Ici, nous serons aidés par la capacité de Kaniko à enregistrer une image de résumé dans un fichier (option —fichier de résumé)
Nous transférerons ensuite ce fichier et le lirons au moment du déploiement.

Mettons à jour les paramètres de notre déployer/site web/environnements/base.libsonnet qui ressemblera désormais à ceci :

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'),
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

Terminé, maintenant tout commit dans maître initialise la construction de l'image docker pour site, puis déployez-le sur Kubernetes.

N'oubliez pas de valider nos modifications :

git add .
git commit -m "Configure dynamic build"

Nous vérifierons plus tard git push nous devrions voir quelque chose comme ceci :

Capture d'écran du pipeline pour le maître

En principe, nous n'avons pas besoin de redéployer gitlab-runner à chaque push, à moins, bien sûr, que rien n'ait changé dans sa configuration, corrigeons cela dans .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

change vous permettra de surveiller les changements dans déployer/gitlab-runner/ et ne déclenchera notre travail que s'il y a de telles

N'oubliez pas de valider nos modifications :

git add .gitlab-ci.yml
git commit -m "Reduce gitlab-runner deploy"

git push, c'est mieux :

Capture d'écran du pipeline mis à jour

12. Environnements dynamiques

Il est temps de diversifier notre pipeline avec des environnements dynamiques.

Commençons par mettre à jour le travail. construire_site_web dans notre .gitlab-ci.yml, en retirant le bloc uniquement, ce qui fera que Gitlab le déclenchera sur n'importe quel commit sur n'importe quelle branche :

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/

Ensuite, nous mettrons à jour le travail déployer_site_web, ajoutons un bloc ici convivial:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

Cela permettra à Gitlab d'associer le travail à poussée environnement et afficher le lien correct vers celui-ci.

Ajoutons maintenant deux autres tâches :

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

Ils seront lancés lorsqu'ils seront poussés vers toutes les branches sauf la branche principale et déploieront une version préliminaire du site.

Nous voyons une nouvelle option pour qbec : —étiquette d'application — il vous permet de marquer les versions déployées de l'application et de travailler uniquement dans cette balise ; lors de la création et de la destruction de ressources dans Kubernetes, qbec fonctionnera uniquement avec elles.
De cette façon, nous pouvons éviter de créer un environnement distinct pour chaque révision, mais simplement réutiliser le même.

Ici, nous utilisons également examen de la candidature qbec, au lieu de qbec applique par défaut — c'est exactement le moment où nous allons essayer de décrire les différences pour nos environnements (révision et par défaut) :

Ajouter évaluation environnement dans déployer/site web/qbec.yaml

spec:
  environments:
    review:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443

Ensuite, nous l'annoncerons dans deploy/website/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

Et nous écrirons des paramètres personnalisés pour cela dans déployer/site web/environnements/révision.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

Examinons également de plus près le joba stop_review, il sera déclenché lorsque la branche est supprimée et afin que gitlab n'essaie pas de l'extraire, il est utilisé GIT_STRATEGY : aucune, plus tard nous clonons maître-branchez et supprimez l'avis via celui-ci.
C'est un peu compliqué, mais je n'ai pas encore trouvé de moyen plus beau.
Une autre option serait de déployer chaque avis dans un espace de noms distinct, qui peut toujours être complètement supprimé.

N'oubliez pas de valider nos modifications :

git add .
git commit -m "Enable automatic review"

git push, git checkout -b test, test d'origine git push, nous vérifions :

Capture d'écran des environnements créés dans Gitlab

Est-ce que tout fonctionne ? - Super, supprimons notre branche de test : maître de caisse git, git push origin :test, nous vérifions que les tâches de suppression de l'environnement ont fonctionné sans erreur.

Ici, je voudrais préciser immédiatement que tout développeur du projet peut créer des branches, il peut également modifier .gitlab-ci.yml fichier et accéder aux variables secrètes.
Pour cette raison, il est fortement recommandé de n'autoriser leur utilisation que pour les branches protégées, par exemple dans maître, ou créez un ensemble distinct de variables pour chaque environnement.

13. Examiner les applications

Examiner les applications Il s'agit d'une fonctionnalité GitLab qui vous permet d'ajouter un bouton pour chaque fichier du référentiel afin de le visualiser rapidement dans l'environnement déployé.

Pour que ces boutons apparaissent, vous devez créer un fichier .gitlab/route-map.yml et décrivez-y toutes les transformations des chemins, dans notre cas ce sera très simple :

# Indices
- source: /content/(.+?)_index.(md|html)/ 
  public: '1'

# Pages
- source: /content/(.+?).(md|html)/ 
  public: '1/'

N'oubliez pas de valider nos modifications :

git add .gitlab/
git commit -m "Enable review apps"

git push, et nous vérifions :

Capture d'écran du bouton « Review App »

Travail terminé !

Sources du projet :

sur Gitlab : https://gitlab.com/kvaps/docs.example.org
sur GitHub : https://github.com/kvaps/docs.example.org

Merci pour votre attention, j'espère que vous avez apprécié

Source: habr.com

Essayer de nouveaux outils pour créer et automatiser le déploiement dans Kubernetes

contenu

1. Apprendre à connaître Hugo

2. Préparation du Dockerfile

3. Apprendre à connaître Kaniko

4. Apprendre à connaître qbec

5. Essayer Gitlab-runner avec Kubernetes-executor

6. Déploiement de cartes Helm avec QBEC

7. Introduction à git-crypt

8. Créer une image de boîte à outils

9. Notre premier pipeline et l'assemblage d'images par balises

10. Automatisation du déploiement

11. Artefacts et assemblage lors de la poussée vers le master

12. Environnements dynamiques

13. Examiner les applications

Travail terminé !

ProHoster