Intégration Gitlab dans Kubernetes pour automatiser ses déploiements


08/06/2020 gitlab kubernetes deployment service-account gitlab-ci

Depuis que j’ai migré des sites sous kubernetes, j’avais perdu l’automatisation du déploiement de mes conteneurs. Pour ce site, je modifiais donc le site et une fois le git push realisé, j’attendais que Gitlab-CI crée mon conteneur. Je récupérai alors le tag du conteneur que je mettais dans le dépôt git où je stocke mes fichiers de configuration pour kubernetes. Une fois le tag mis à jour, je pouvais procéder au déploiement de mon conteneur. Il était temps d’améliorer ce workflow.

Gitlab propose depuis un moment une intégration avec kubernetes mais je lui trouve quelques inconvénients au regard de mes besoins :

  • Il faut créer un compte avec un ClusterRole cluster-admin et je ne suis pas super à l’aise avec cette idée,
  • Il est nécessaire de déployer Helm encore en version 2 alors que je suis passé en version 3 pour les rares projets où je l’utilise,
  • L’ingress s’appuie sur nginx-ingress, alors que j’utilise Traefik,
  • Je n’ai pas l’usage des autres fonctionnalités fournies par Gitlab dans mon contexte de “cluster de test” hébergeant quelques sites et applications web.

Mon besoin pourrait se résumer à pouvoir interagir avec mon cluster au travers de kubectl et de pouvoir y déployer la nouvelle version du conteneur que je viens de créer. Cela suppose alors d’avoir 3 choses :

  • le binaire kubectl accessible sous la forme d’un conteneur ou directement en shell dans le runner,
  • un fichier kubeconfig pour m’authentifier auprès du cluster et interagir avec,
  • la référence de l’image docker fraichement crée par Gitlab-CI à appliquer sur un Deployment kubernetes.

Création d’un compte de service avec authentification par token

Utilisant le service managé d’OVH, je n’ai pas accès à tous les certificats du cluster permettant de créer de nouveaux comptes utilisateurs. Par ailleurs, pour les intégrations comme Gitlab, il est recommandé d’utiliser des Service Accounts. C’est ce que nous allons faire.

En plus du Service Account, il nous faut donner un rôle à notre compte pour qu’il puisse réaliser des actions sur le cluster. Par simplicité pour ce billet, je vais lui donner les droits d’admin au sein d’un namespace. Le compte de service pourra alors faire ce qu’il veut mais uniquement au sein du namespace en question. En cas de fuite du compte, les dégats potentiels sont donc moindres qu’avec un compter qui est admin global du cluster. Le rôle admin existe déjà sous kubernetes, il s’agit du ClusteRole admin mais qui est restreint à un namespace via le RoleBinding.

Créons le fichier gitlab-integtration.yml avec ces éléments :

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-example
  namespace: example
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: gitlab-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- kind: ServiceAccount
  name: gitlab-example
  namespace: example

Déployons notre configuration sur le cluster :

# Apply yml file on the cluster
kubectl apply -f gitlab-integration.yml
serviceaccount/gitlab-example created
rolebinding.rbac.authorization.k8s.io/gitlab-admin created

Pour alimenter notre fichier kubeconfig, il nous faut récupérer le token :

# Get secret's name from service account
SECRETNAME=`kubectl -n example get sa/gitlab-example -o jsonpath='{.secrets[0].name}'`
# Get token from secret, encoded in base64
TOKEN=`kubectl -n example get secret $SECRETNAME -o jsonpath='{.data.token}'`
# Decode token
CLEAR_TOKEN=`echo $TOKEN |base64 --decode`

En prenant votre fichier kubeconfig de référence, vous pouvez alors créer une copie sous le nom kubeconfig-gitlab-example.yml et l’éditer de la façon suivante :

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <Existing certificate in a base64 format from your original kubeconfig file>
    server: <url of your k8s http endpoint like https://localhost:6443/ >
  name: kubernetes # adjust your cluster name
contexts:
- context:
    cluster: kubernetes # adjust your cluster name
    namespace: example # adjust your namespace
    user: gitlab-example # adujust your user
  name: kubernetes-ovh # adujust your context
current-context: kubernetes-ovh # adujust your context
kind: Config
preferences: {}
users:
- name: gitlab-example # adujust your user
  user:
    token: <Content of the CLEAR_TOKEN variable>

Vous pouvez tester son bon fonctionnement via :

# Fetch example resources if any:
kubectl --kubeconfig=./kubeconfig-gitlab-example.yml get all
...
# Check you can't access other namespaces information, like kube-system:
kubectl --kubeconfig=./kubeconfig-gitlab-example.yml get all -n kube-system
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "pods" in API group "" in the namespace "kube-system"
Error from server (Forbidden): replicationcontrollers is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "replicationcontrollers" in API group "" in the namespace "kube-system"
Error from server (Forbidden): services is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "services" in API group "" in the namespace "kube-system"
Error from server (Forbidden): daemonsets.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "daemonsets" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): deployments.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "deployments" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): replicasets.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "replicasets" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): statefulsets.apps is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "statefulsets" in API group "apps" in the namespace "kube-system"
Error from server (Forbidden): horizontalpodautoscalers.autoscaling is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "horizontalpodautoscalers" in API group "autoscaling" in the namespace "kube-system"
Error from server (Forbidden): jobs.batch is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "jobs" in API group "batch" in the namespace "kube-system"
Error from server (Forbidden): cronjobs.batch is forbidden: User "system:serviceaccount:example:gitlab-example" cannot list resource "cronjobs" in API group "batch" in the namespace "kube-system"

Integration Gitlab : stocker le kubeconfig

Gitlab permet de stocker des variables. Dans le cas d’un fichier kubeconfig, on va vouloir ne jamais afficher son contenu dans les logs ou autre. Pour cela il est possible de masquer vos variables en respectant quelques contraintes et notamment que la valeur de la variable tienne sur une seule ligne.

Nous allons donc encoder le fichier en base64 et rajouter un argument pour que tout soit sur une seule ligne (et non pas sur plusieurs lignes par défaut):

# create a one line base64 version of kubeconfig file
cat kubeconfig-gitlab-example.yml | base64 -w 0

Copier le contenu obtenu dans une variable que nous appelerons KUBECONFIG et dont on cochera bien la case “Mask variable”. Une fois la variable sauvée, vous avez ceci :

gitlab ci masked variable

Intégration Gitlab : passer la référence de l’image au job de déploiement

Soit le fichier .gitlab-ci.yml suivant:

---
stages:
  - publish
  - image
  - deploy

publish:
  image:  $CI_REGISTRY/nsteinmetz/hugo:latest
  artifacts:
    paths:
      - public
    expire_in: 1 day
  only:
    - master
    - web
  script:
    - hugo
  stage: publish
  tags:
    - go

docker:
  stage: image
  image: docker:stable
  services:
  - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_DRIVER: overlay2
    RELEASE_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA-$CI_PIPELINE_ID-$CI_JOB_ID
  before_script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  script:
    - echo "IMAGE=${RELEASE_IMAGE}" >> docker.env
    - docker build --pull -t $RELEASE_IMAGE .
    - docker push $RELEASE_IMAGE
  when: on_success
  tags:
    - go
  artifacts:
    reports:
      dotenv: docker.env

kube:
  stage: deploy
  script:
    - echo $KUBECONFIG | base64 --decode > kubeconfig
    - export KUBECONFIG=`pwd`/kubeconfig
    - sed -i -e "s|IMAGE|${IMAGE}|g" deployment.yml
    - kubectl apply -f deployment.yml
  needs:
    - job: docker
      artifacts: true
  when: on_success
  tags:
    - shell

Petite explication rapide :

  • l’étape publish va générer la version html du site et la stocker sous la forme d’un artefact qui sera passé aux jobs suivants,
  • l’étape docker va créer l’image en mettant l’artefact du job précédent dans un conteneur nginx et le publier dans la registry gitlab avec le nom suivant gitlab.registry/group/project:<short commit>-<pipeline id>-<job id>
  • l’étape kube va récupérer le contenu de la variable KUBECONFIG, le décoder et créer un fichier kubeconfig. On initialise la variable d’environnement KUBECONFIG pour que kubectl puisse l’utiliser. On met à jour la référence de l’image docker obtenue précédemment dans le fichier deployment.yml qui sert de modèle de déploiement. On applique le fichier obtenu sur le cluster kubernetes pour mettre à jour le déploiement.

Le point d’attention ici est que le passage de la variable RELEASE_IMAGE se fait via un dotenv qui est créé sous la forme d’un artefact à l’étape docker et est donc disponible à l’étape kube. Cela devrait être automatique mais j’ai ajouté une dépendance explicite via la directive needs. Lors de l’étape kube, le contenu du fichier docker.env est disponible sous la forme de variables d’environnement. On peut alors faire la substitution de notre placeholder par la valeur voulue dans deployment.yml.

Tout ce mécanisme est expliqué dnas la doc des variables gitlab et sur les variables d’environnement héritées. Attention, il vous faut Gitlab 13.0+ pour avoir cette fonctionnalité et en plus, il faut préalablement activer ce feature flag.

sudo gitlab-rails console
Feature.enable(:ci_dependency_variables)

En conclusion, nous avons vu comment :

  • Créer un compte de service (Service Account) sous kubernetes avec un rôle d’administrateur de namespace,
  • Stocker le fichier kubeconfig utilisant notre service account dans Gitlab sous la forme d’une variable masquée,
  • Passer une référence d’un job à un autre via les dotenv au niveau du job amont et les variables d’environnement au niveau du job en aval,
  • Récupérer le contenu de la variable kubeconfig pour créer une variable d’environnement et être en mesure d’utiliser kubectl.

Ainsi, toute mise à jour de master conduira à une mise à jour du déploiement associé au sein du cluster kubernetes et ne nécessitera plus d’interventions manuelles comme précédemment. Avec un service account lié à un namespace, on évite aussi de s’exposer inutilement en cas de fuite des identifiants.

Web, Ops & Data - Mai 2020


27/05/2020 docker ovh openstack fedora harbor registry traefik maesh percona mysql operator devops timescaledb grafana kubernetes terraform iac cert-manager devops raspberrypi

Le mois prochain, dans le cadre d'InfluxDays London, j’aurai le plaisir de présenter un talk sur le passage d’un monitoring Bare Metal vers un monitoring dans un monde Kubernetes avec Telegraf et InfluxDB.

Cloud

Container & orchestration

  • How To Install Docker On Fedora 32 Or 31 (And Alternatives) : Même si l’utilisation de podman est recommandée en lieu et place de docke-ce depuis Fedora 31, il peut être nécessaire de vouloir utiliser docker-ce sous Fedora. Avec Fedora 32, il faut en plus des cgroups v1 à activer, il y a une règle firewall à ajouter pour que vos conteneurs aient accès au réseau / à internet.
  • Harbor 2.0 : Version 2.0 de la registry Harbor qui permet d’héberger aussi des charts Helm. Pour la partie scan de vulnérabilités, le produit Clair de Quay a été remplacé par Aqua Trivy
  • Announcing Maesh 1.2 : la solution de Service Mesh de Containous basée sur Traefik sort en 1.2 ; elle se base sur Traefik 2.2 et apporte donc le support de l’UDP au niveau reverse proxy. Cette version permet aussi des améliorations au niveau ACL, gestion de la configuration et gestion des middlewares par service.
  • Introduction to Percona Kubernetes Operator for Percona XtraDB Cluster
  • Cert-manager v0.15 and beyond
  • CDK for Kubernetes : AWS vient de sortir un “Cloud Development Kit” permettant de manipuler et déployer des ressources kubernetes en python, typescript ou javascript.

DevOps

IoT

Time Series

Web, Ops & Data - Avril 2020


29/04/2020 traefik scaleway kubernetes telegraf cassandra kafka confluent helm influxdb warp10 timescaledb docker-compose apache-pulsar pubsub deprek8 conftest opa raspberrypi gitlab sidecar

Code et Outillage

Container & orchestration

(Big) Data

Time Series

Web

  • jQuery 3.5.0 Released! : une faille XSS a été identifiée sur jQuery.htmlFilter pour toutes les versions inférieures à 3.5.0 ; il est vivement encouragé de mettre à jour vos sites. Pour le reste, je vous renvoie à la lecture de l’article.

Soutenir une initiative contre le Covid19 en tant qu'entreprise ?


07/04/2020 covid19 société entreprise

N’ayant pas (encore) d’imprimante 3D pour faire des protections ou à prêter à d’autres projets et souhaitant préserver ma trésorerie personnelle, je me suis posé la question de savoir si ma société pouvait contribuer à ces efforts dans la luttre contre le Covid19. Tout comme je considère que ma société doit être pérenne et assurer mes revenus, elle s’inscrit dans une société et doit y contribuer dans la mesure de ses moyens.

Connaissant différentes personnes travaillant sur le projet MakAir ; il y a eu cet appel au don (Via). C’est notamment ce qui a suscité mon questionnement, libre à vous de soutenir le projet de votre choix.

Je me suis donc tourné vers mon expert-comptable pour savoir ce qu’il était possible de faire. Une entreprise peut faire un don et le montant du don ouvrant droit à un crédit d’impôt est plafonné à 5/1000 de son chiffre d’affaires.

Dans mon cas d’espèce, cela donne un montant de 750€ ; soit la facturation d’une journée de travail environ.

Pour être complet, et même si ce n’est pas ma motivation première, d’un point de vue fiscal, il est plus intéressant de faire le versement à titre personnel, car la déduction sur l’impôt sera de 66% (plafonné à 20% du revenu imposable) alors que pour l’entreprise, c’est 60%.

Si votre société se porte raisonnablement bien en ces temps incertains et que vous ne pouvez pas contribuer directement, il est possible pour vous de participer à cet effort au travers du don notamment. Il n’est pas question de mettre votre entreprise ou vous même en difficulté, mais si vous avez l’opportunité de soutenir des projets, ce sera une contribution à l’édifice. Le don n’est pas la seule forme possible d’engagement, mon cas est juste l’occasion de vous faire réfléchir sur le sujet.

Sur ce, prenez soin de vous et de vos proches.

Web, Ops & Data - Mars 2020


25/03/2020 ansible molecule test java redis timeseries influxdb warp10

IaC

  • Ansible Molecule 3.0 : l’outil de test des rôles Ansible est passé en version 3.0. Pas mal de changement avec l’externalisation des providers d’infrastructure sous la forme de module python et d’autres rationalisation. Une check list de migration est disponible

Langages

  • What Tens of Millions of VMs Reveal about the State of Java : NewRelic publie une synthèse des versions et configuration de Java déployées dans la nature. ~85% tourne encore sur Java 8 et 11% sur Java 11 et le tout principalement avec les versions fournies par Oracle. On se moquait des communautés PHP (pour PHP 5 à PHP 7) ou Python (2 vers 3) mais visiblement chaque langage d’un certain age rencontre les mêmes soucis.

Time Series

  • RedisTimeSeries Version 1.2 Is Here! : ce module qui apporte des fonctionnalités de séries temporelles à Redis (sans pour autant en faire une base de données orientée séries temporelles) passe en 1.2. On y trouve surtout des améliorations au niveau de la compression des données, des améliorations de performance et une rationnalisation de l’API.
  • SenX publie un guide indiquant les propriétés d’une base de donnée timeseries et comment Warp10 se positionne sur les différents axes. Un joli travaille pédagogique.
  • Warp10 a dépassé les 1000 fonctions
  • InfluxDB 2.0 - beta 6 : améliorations de l’ensemble et l’apparition des premières fonctions géospatiales dans Flux.
  • Le site du Paris Time Series Meetup est en ligne ; à défaut de meetup, vous pourrez y retrouver les vidéos et supports des précédentes éditions.

Web, Ops & Data - Février 2020


26/02/2020 kubernetes tls swarm docker warp10 ptsm influxdata telegraf linky grafana

Container et orchestration

  • Deprecations AKA KubePug - Pre UpGrade (Checker) : Pas encore testé mais un outil qui validerait les objets kubernettes déployés dans un cluster versus une version d’API donnée. Vous pourriez ainsi identifier et anticiper les dépréciations et évolutions d’API.
  • Mirantis will continue to support and develop Docker Swarm : Mirantis, qui a racheté il y a peu Docker Entreprise et aussi l’orchestrateur de conteneurs Swarm, vient d’annonce qu’ils continuaient à développer Swarm sans limite de temps. Mirantis a récemment ajouter la notion de Swarm Jobs et travaille sur la gestion des volumes via les plugins CSI (Container Storage Interface)

Sécurité

  • It’s the Boot for TLS 1.0 and TLS 1.1 : Mozilla, Microsoft, Apple et Google se sont mis d’accord pour ne plus supporter les versions 1.0 et 1.1 de TLS pour des raisons évidentes de sécurité. Reste que cela risque de coincer un peu de part les configurations parfois un peu hasardeuses des serveurs et de l’irrégularité de leurs maintenances ou de la vieillesse de certains packages dans certaines distributions.

Time Series

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

kubernetes docker influxdb traefik timeseries grafana kafka ansible elasticsearch postgres python warp10 aws sécurité mysql redis terraform tick cassandra cloud helm ovh git telegraf rancher swarm test timescaledb chronograf docker-compose flux résilience architecture arm confluent devops gitlab ksql log machine-learning microservice monitoring prometheus ptsm s3 serverless spark angularjs api cert-manager cncf container dashboard dns gcp graphql hashicorp iac ingress java javascript opensource operator optimisation raspberrypi service-mesh sql stream vscode warpscript windows bilan csp cérénit documentation elastic flows gke hpkp jenkins kafka-streams kapacitor kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile nginx npm orientdb perspective pipeline redhat rest rethinkdb reverse-proxy rook sauvegarde scaleway ssh agile apm automatisation azure bash big-data ceph certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie deployment diff fluxlang forecast framework gdpr grav hsts http/3 https hypriot hébergement influxace influxdata influxdays istio jq json k3s lets-encrypt linux load-balancer longhorn meetup molecule mongodb nosql nvidia openebs percona performance php pip postgresql reaper registry replication rpi rsyslog scale secrets société solr sre systemd timezone tls vault virtualenv vitess vue.js wagtail warpfleet yarn accessibilité acme akka alerte alibaba amazon-emr amqp anonymisation anthos apache-pulsar ara arima arrow audit bastion beam beat bigdatahebdo bounded-context branche brigade browser buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centralisation-de-logs certificats chart checklist chrome ci cilium cloud-init cloud-native cloud-storage clusterip cnab cni cockroachdb code codeurs-en-seine commit confluence conftest consul continous-deployment conventional-commit coreos cors covid19 cqrs crash cron crontab csi csrf css curl d3.js daemonset data data-engineer data-pipelining data.gouv.fr datacenter dataviz date date-scientist ddd debezium debian delta deprek8 desktop devoxx dig distributed-systems dive docker-app docker-hub docker-registry docker-swarm documentdb dog dokcer données-personnelles draft drop-in duration déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd event-sourcing faas facebook faisabilité falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd formation foundation frontend fsync fullstack github gitignore gitlab-ci glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index influxcloud infrastructure-as-code ingénierie inspec jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl laravel letsencrypt linky liste-de-diffusion loadbalancer logstash logstatsh loi mailing-list management maturité mesh mesos message metallb micro-service mot-de-passe mqtt multi-cloud médecine métrique network newsletter nodeport nomad null object-storage observability observabilité opa opendata openmetrics openshit openssh openstack openweb over-engineering ovhcloud packaging pandas parquet partiql password persistent-volume-claim pipenv pod podman portainer portworx prediction prescience ptyhon publicité pubsub pulsar push pyenv quasardb quay questdb queue quic ram rambleed raml react recaptcha recherche redistimeseries reindex reinvent reliability responsive revocation revue-de-code rgpd rkt rolespec root rootless rpo rto runc rust rwd safe-harbor scalabilité scanner schema scp sdk search select serverless-architecture service-account service-worker setuptools sftp sha1 sharding shell shipyard sidecar souveraineté-numérique spinnaker spécifications sri ssh-agent ssl stash statistique storage superset suse sympa syslog-ng terracost terrascan test-unitaire tidb tiers timer training travail tsl ubuntu unikernel unit ux vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc warpstudio web yaml yq yubikey

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)