Contactez-nous
-
devops

Créer une forge logicielle GitLab / Kubernetes hébergée chez Scaleway

GitLab / Kubernetes hébergée chez Scaleway

Sommaire

À la découverte de Scaleway

La souveraineté numérique est aujourd’hui un enjeu important pour un nombre grandissant d’entreprises. Au-delà de la technique, les considérations éthiques et géopolitiques poussent souvent à des choix locaux dans la mesure du possible. Or, même si nous observons de nombreux fournisseurs cloud français, la majorité se concentre sur les offres d’Infrastructure as a Service avec peu ou pas de services managés. À l’heure où le service managé devient une norme pour une grande partie des entreprises, cela représente un gros manque à leurs offres.

Il y a quelques années est apparu la marque Scaleway, qui n’est pas nouvelle, c’est tout simplement le nouveau nom d’Online.net que beaucoup ont connu, moi y compris, au travers des offres de serveurs dédiés Dedibox. Très rapidement ils ont annoncé et créé une offre cloud, Scaleway Elements, avec pour ambition de créer un cloud français avec une offre de services managés à destination des entreprises.

Depuis les expérimentations de cloud ARM chez Scaleway en 2014 (labs.online.net), celui-ci a bien évolué et propose aujourd’hui une liste de services managés intéressante. C’est pour cela que je vous propose de le découvrir par la pratique au travers de la création d’une infrastructure de forge logicielle utilisant GitLab et Kubernetes 

Nous utilisons au maximum les services managés Scaleway, qui nous permettent de couvrir un bon nombre de besoins : base de données, Kubernetes, stockage objet.

Bien sûr nous ferons le plus de choses possibles au travers de l’infrastructure as Code à l’aide de deux outils d’HashiCorp qui sont aujourd’hui devenus de facto des standards : Terraform et Packer.

Découverte de la console et création des clés

Pour créer un compte ou vous connecter il suffit de se rendre sur l’adresse de la console de Scaleway Elements : https://console.scaleway.com

Une fois le compte créé et connecté, vous arrivez sur votre Dashboard, celui-ci vous fait un rappel de votre facturation sur la partie centrale. Sur le côté gauche, vous pouvez voir les différents services qu’offre Scaleway Elements. En bref, simple et efficace, tout ce qu’on demande.

Dans le menu de votre compte, en haut à droite, nous allons nous rendre dans Organisation. Au sens Scaleway, une organisation est un regroupement logique d’un environnement de travail, qui peut-être partagé entre plusieurs comptes/personnes. Ici vous pouvez observer votre organisation par défaut, il est important de conserver l’organisation ID, celui-ci est nécessaire pour interagir avec la CLI Scaleway et donc également pour les outils d’IaC. Notez que dans votre organisation, dans la partie billing, vous pouvez aussi définir une alerte budget. Je vous conseille de le faire si vous souhaitez tester en maîtrisant vos coûts !

Ensuite, nous pouvons remarquer sur la barre de gauche que nous avons une notion de projet. Cette notion permet de découper vos infrastructures en différents projets au sein d’une même organisation. Vos tokens seront limités au projet dans lesquels vous effectuez la création. Une fois dans le projet souhaité, sur la page principale, allez dans la partie “credentials” :

Sur la page, vous pouvez générer vos tokens et ajouter votre clé publique SSH. Sauvegardez vos tokens en sécurité dans un gestionnaire de mots de passe. Une fois que c’est fait on passe dans le coeur du sujet !

Créer une image Scaleway avec Packer

Pour notre forge nous utiliserons GitLab, qui présente plusieurs avantages, notamment d’offrir un forge clé en main avec tous les outils nécessaires. Pour la partie Runner, il est très simple aujourd’hui d’interconnecter GitLab et Kubernetes, c’est donc parfait pour notre Kubernetes managé aka Kapsule !

Avant toute chose, nous allons devoir faire une machine pour héberger ce GitLab. Scaleway offre un catalogue d’images avec des middlewares préinstallés comme par exemple Nextcloud, Mattermost, Golang et GitLab ! Ce catalogue permet de gagner pas mal de temps. Néanmoins, notre but étant de tester les possibilités de Scaleway, je vous propose de créer nous même notre propre image d’instance Scaleway avec un outil que vous connaissez bien : Packer.

Packer est un outil d’Infra as Code qui vous permet de construire une image machine, facilement à partir d’un template, qui peut lui-même se baser sur du Shell, des scripts, ou même du code Ansible. Packer est compatible avec la plupart des principaux fournisseurs cloud (AWS, Azure, ...) et Scaleway en fait partie.

Pour cela, il nous suffit d’installer Packer sur notre poste, il s’agit d’un simple binaire Go à placer dans son PATH comme décrit dans la documentation officielle. Ensuite, il suffit de créer votre fichier template. Dans ce template, vous allez placer les informations suivantes :

  • les tokens que vous exportez en variables d'environnement, afin que Packer puisse se connecter à votre infrastructure :
  "variables": {
    "organization_id": "",
    "api_token": ""
  },
  • dans la partie builder vous allez définir les paramètres spécifique à celui-ci, afin notamment de paramétrer Scaleway :
  "builders": [
    {
      "organization_id": "", # Défini dans les variables
      "api_token": "", # Défini dans les variables
      "server_name": "gitlab",  
      "image_name": "debian-gitlab", # Le nom de l’image Gitlab qui est basé sur Debian
      "snapshot_name": "debian-gitlab-snapshot",
      "type": "scaleway", # Le type de builder Packer, Scaleway est dans les builders officiels
      "image": "9a53e825-19f9-4e1f-b841-dd921e4e1b39", # L’image de base. Toutes les images sont ici : https://api-marketplace.scaleway.com/images
      "region": "par1", # La région ici Paris
      "commercial_type": "DEV1-S", # J’ai mis la plus petite taille d’instance pour le build, vous pourrez la faire tourner sur tout type après
      "ssh_username": "root" # On utilise l’utilisateur root par défaut pour la création de l’image 
    }
  ],
  • et ensuite le code que vous allez exécuter, ici il est assez simple donc nous passons directement par le shell en forçant le mode non interactif puisque le build est automatique :
 "provisioners": [
   {   
     "type": "shell",
     "inline": [
         "sleep 30",
         "apt-get update",
         "export DEBIAN_FRONTEND=noninteractive; apt-get upgrade -yq --force-yes",
         "export DEBIAN_FRONTEND=noninteractive; apt-get install -y curl ca-certificates apt-transport-https",
     "cd /tmp",
     "curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh",
     "bash /tmp/script.deb.sh",
     "apt install gitlab-ce"
     ]  

Et voilà ! Votre template est prêt à être exécuté ! Pour cela, rien de plus simple : export des variables d’API,  packer validate gitlab.json pour confirmer la validité du fichier et packer buid gitlab.json.

Après quelques minutes, durant lesquelles Packer aura lancé une machine sur Scaleway, exécuté le code shell et fait une image du tout avant de la détruire, une nouvelle ID image apparaît. Celle-ci est aussi dans l’interface web dans Instance.

Maintenant que notre image est créée, il nous faut l’utiliser. Pour cela, nous restons sur de l’Infrastructure as Code et chez HashiCorp et nous passons à Terraform.

Créer son infrastructure avec Terraform

Terraform est un incontournable de la boîte à outils DevOps. C’est un outil d’Infrastructure as Code, il vous permet de créer des infrastructures (machines et services managés) à partir de code. Il est aujourd’hui leader dans son domaine, et s’utilise avec un grand nombre de plateformes. Comme vous vous en doutez si j’en parle ici, Scaleway en fait bien sûr partie.

Nous allons partir sur la version 0.13 de Terraform, qui est stable et offre de nombreuses améliorations, notamment sur l’appel des providers, qui sont les connecteurs entre Terraform et votre fournisseur d’infrastructure.

Terraform sera utilisé en local, mais une bonne pratique reste de stocker à distance les “states”, qui sont l’état de l'infrastructure sur lequel se base le client local. Sur AWS, en général vous le stockez dans un S3. Ici nous le stockons dans object storage. Pour cela nous allons faire une entorse et le créer à la main. En effet, gérer le stockage de Terraform avec Terraform serait un peu contre-logique. Pour cela, il vous suffit de faire “Create bucket” dans le produit “Object storage”.

Mettez ensuite un nom valide au niveau DNS. Pour la région, le lab étant sur Paris je garde cette région. Le bucket doit être en privé car il va stocker l’état complet de votre infrastructure, sous forme de fichier “states”. Et vous pouvez lancer la création !

L’installation de Terraform est assez triviale et comme tous les outils HashiCorp, elle se base sur un simple binaire en Go, néanmoins je ne saurai que vous conseiller tfenv qui permet de gérer plusieurs installations de Terraform à partir de la ligne de commande (plus d'information sur leur Github).

Donc là, nous avons nos tokens, notre image GitLab personnalisée, notre bucket pour Terraform : nous sommes totalement prêts pour commencer à coder notre infrastructure !

Nous allons commencer par définir notre provider dans un fichier ‘provider.tf’. Il est à noter que le backend est S3 comme sur AWS, car l’object storage proposé par Scaleway est compatible avec S3 :

terraform {
  required_providers {
    scaleway = {
      source           = "scaleway/scaleway"
      required_version = ">= 0.16"
    }
  }
}
provider "scaleway" {
  region          = var.region
  zone            = var.zone
}
terraform {
  backend "s3" {
    bucket                      = "METTEZ-ICI-VOTRE-NOM-DE-BUCKET"
    key                         = "terraform.tfstate"
    region                      = "fr-par"
    endpoint                    = "https://s3.fr-par.scw.cloud"
    skip_credentials_validation = true
    skip_region_validation      = true
  }
}

Nous allons ensuite créer notre petit ‘variables.tf’ pour définir les variables, notamment celles du provider :

variable "region" {
  default = "fr-par"
}
variable "zone" {
  default = "fr-par-1"
}
variable "imageID" {
   default = "votre ID image donné par Packer ou la console"
}

Exportez ensuite vos tokens :

export SCW_ACCESS_KEY=XXXXXXX
export SCW_SECRET_KEY=YYYY-YYYY-YYYY
export AWS_ACCESS_KEY_ID=XXXXXXX #Pour la compatibilité S3 “AWS”
export AWS_SECRET_ACCESS_KEY=YYYY-YYYY-YYYY
export SCW_DEFAULT_ORGANIZATION_ID=OOOO-OOOO-OOOO

Et là, nous sommes prêts pour lancer notre première commande : terraform init, ce qui va permettre d’initialiser notre environnement Terraform.

Concernant notre élément central, notre instance GitLab, dont l’image a été créée dans le point précédent, nous allons tout d’abord lui donner une adresse IP publique afin de pouvoir nous y connecter :

resource "scaleway_instance_ip" "gitlab" {}

N’oublions pas de créer un security group qui va nous permettre de restreindre l’accès à GitLab à notre IP pour cela :

  • on crée un objet data qui récupère notre IPv4
data "http" "myip" {
  url = "http://ipv4.icanhazip.com"
}
  • On crée le security group pour ouvrir le port 22 (SSH & Git) et le 80 (HTTP), on ferme le reste
resource "scaleway_instance_security_group" "gitlab" {
  inbound_default_policy  = "drop"
  outbound_default_policy = "accept"

  inbound_rule {
    action = "accept"
    port   = 22
    ip     = chomp(data.http.myip.body)
  }

  inbound_rule {
    action = "accept"
    port   = 80
    ip     = chomp(data.http.myip.body)
  }
}

Et ensuite on utilise l’image créée avec Packer pour lancer notre instance GitLab :

resource "scaleway_instance_server" "gitlab" {
  type  = "DEV1-L" #Toujours une instance de Dev, moins puissante mais suffisante pour le lab
  image = var.imageID #L’identifiant de l’image créé par Packer
  ip_id = scaleway_instance_ip.gitlab.id
  security_group_id = scaleway_instance_security_group.gitlab.id
}

Pour ce qui est de la base de données et du cluster Kubernetes, je ne vais pas commenter le code, cela reste du code Terraform assez classique, vous pouvez d’ailleurs retrouver tout le code, Packer et Terraform sur ce repo Github. N’hésitez pas à aussi aller lire la documentation Terraform du provider par ici.

Une fois toute l’infrastructure déployée, à noter que les créations de la base de données et du cluster Kubernetes prennent du temps, on peut accéder à son propre GitLab sur l’IP publique de l’instance ! Après définition d’un mot de passe pour le compte root, l’instance est utilisable !

Connecter GitLab et Kubernetes

GitLab est une très bonne forge logicielle, qui connaît un grand succès notamment avec le mouvement DevOps. Depuis maintenant quelques années, elle propose de s’interconnecter avec un cluster Kubernetes afin de gérer certaines fonctionnalités, comme par exemple gérer les runners de CD ou encore déployer directement sur Kubernetes.

Téléchargez et placez dans votre PATH le binaire de kubectl. C’est lui qui va nous permettre de nous connecter au cluster Kubernetes. Dans la console web de Scaleway, dans l’onglet Kapsule, sélectionnez votre cluster. En bas de celui-ci, utilisez la fonction “Download Kubeconfig”. N’ayant pas d’autre configuration Kubernetes sur le poste, j’ai l’ai directement copié dans ~/kube/config. Vous pouvez faire de même si c’est votre seule configuration Kubernetes, sinon il vous suffit d’exporter le PATH de votre configuration dans la variable d'environnement KUBECONFIG. Si vous effectuez un kubectl cluster-info vous pouvez voir que vous êtes bien connecté à votre cluster Kapsule !

Le reste des actions à faire est assez simple et très bien documenté sur sur cette page du site de GitLab.

Une fois terminé, vous pouvez voir votre cluster Kapsule connecté à votre GitLab ! Dans l’onglet application du cluster vous pourrez installer les applications gérées par GitLab, notamment l’application Runner qui vous permet d’utiliser votre cluster pour effectuer vos pipelines.

Que penser de ce lab ?

Nous avons une belle forge GitLab prête à être utilisée ! Bien sûr elle n’est pas parfaite, mais a le mérite de nous avoir fait découvrir Scaleway.

Maintenant qu’en penser ? Déjà, les outils du marché, ici Terraform et Packer, sont compatibles et fonctionnent plutôt sans problèmes. Même si Terraform ne couvre pas encore toutes les options, malheureusement passer par la console ou la CLI directement est parfois nécessaire. Cela reste comme vous le voyez largement utilisable pour des projets classiques. Nous pouvons aussi noter qu’Ansible peut utiliser de manière dynamique Scaleway en tant qu’inventaire dynamique de machines, ce qui est très pratique.

Dans ce lab, je n’ai pas parlé de certains aspects comme la supervision, qui n’est pas intégrée à Scaleway ou bien encore de gestion du réseau local qui est en beta à l’heure où j’écris ces lignes. Un service de gestion des droits plus fin, à l’image d’AWS IAM et la possibilité de chiffrement “as a Service” seraient aussi des gros plus pour la sécurité. Mais ce qui est sûr c’est que Scaleway offre aujourd’hui une belle panoplie de services managés qui suffiront pour beaucoup de projets. Surtout que nous n’avons pas testé tous les services que propose Scaleway.

Pour moi, il s’agit de l’offre française la plus intéressante en terme d’outils et de services managés, je vous invite plus que jamais à tester leurs solutions, que ça soit avec ce projet ou un autre. Une bonne alternative française à connaître et à suivre de près, car oui, leur roadmap est intéressante et les nouvelles fonctionnalités arrivent rapidement, comme par exemple la gestion par projet qui vient d’arriver : l'annonce est disponible ici. Je n’ai pas de doute sur le fait que la plateforme s’améliore encore longtemps !