S’il y a bien une problématique que l’on rencontre tous les jours dans nos métiers c’est la gestion des secrets au sens large, mot de passe, tokens, clés privées. Cependant, leur gestion peut s’avérer complexe, surtout lorsque nous devons les intégrer à divers outils d’infrastructure tels que Terraform, Ansible, Kubernetes, et bien d’autres. Sur le marché, il existe de nombreuses solutions pour relever ce défi, allant du célèbre Vault de HashiCorp (qui, tout comme Terraform, a connu des changements de licence), à AWS Secret Manager, Azure Vault, Infiniscal, et bien d’autres. Mais parmi cette multitude d’options, il en est une qui se distingue par son approche innovante : SOPS, acronyme de Secrets OPerationS. Contrairement à la plupart des solutions qui adoptent une approche centralisée, souvent sous la forme d’un service exposant les secrets sous forme de clé-valeur, SOPS se démarque en proposant le chiffrement des valeurs directement dans des fichiers de configuration au format JSON, YAML, init, et bien d’autres encore. Une fois chiffrées, ces données peuvent être partagées et versionnées en toute sécurité via des outils tels que Git ou d’autres systèmes de gestion de versions. Ce qui rend SOPS très intéressant c'est son origine. Elle a été directement créée par les équipes techniques de Mozilla. Ce qui lui a permis de bénéficier d'une réelle expertise de la part d'un acteur majeur de la sécurité et de la vie privée. Préparez-vous je vous propose de plonger avec moi dans la découverte de cet outil ! Fonctionnement Le fonctionnement de SOPS est assez flexible et permet un vaste choix, que ça soit sur le format du fichier de sortie ou du gestionnaire de clé. Une solution flexible Le point intéressant est que Sops va uniquement chiffrer les valeurs de vos fichiers. Par exemple pour un fichier YAML ayant une ligne : db_password: my_password, uniquement la valeur de la clé sera chiffrée donc ici my_password. Ce qui va permettre la lecture et la compréhension de la structure des fichiers sans la nécessité de le déchiffrer. Pour gérer la configuration de ce chiffrement, SOPS va ajouter un ensemble de metadatas sous la clé sops lors du processus de chiffrement. Mise en marche Installation # Download the binary curl -LO https://github.com/getsops/sops/releases/download/v3.8.0/sops-v3.8.0.linux.amd64 # Move the binary in to your PATH mv sops-v3.8.0.linux.amd64 /usr/local/bin/sops # Make the binary executable chmod +x /usr/local/bin/sops Les manipulations de base se font assez facilement et de manière transparente. SOPS va utiliser l’éditeur par défaut de votre système (défini par la variable d’environnement: EDITOR). Comme noté plus tôt l'intérêt de SOPS c'est aussi de supporter plusieurs bases de chiffrement. Pour ça je vais vous donner deux exemples, le premier avec PGP qui reste le grand classique, le second avec Age qui est la solution recommandée par SOPS. Il est aussi possible de se reposer sur les KMS cloud, mais je vais laisser cette partie de côté. Utilisation avec PGP On commence par PGP, le classique que j’utilise déjà notamment pour chiffrer mon Pass. Dans mon cas, pour utiliser ma clé : # On récupère la fingerprint de notre clé gpg --list-keys # On export le fingerprint export SOPS_PGP_FP="<VOTRE FINGERPRINT>" J’aurai aussi pu donner la clé avec le paramètre --pgp : sops --pgp "<VOTRE FINGERPRINT>" vous pouvez mettre plusieurs clés à la suite en les séparant par des virgules. Utilisation avec AGE Le chiffrement de fichier, simple et efficace J’ai découvert Age avec SOPS, cela regroupe un outil, un format et une bibliothèque ayant pour but de gérer du chiffrement par clé asymétrique (couple public privé). C’est une bonne alternative à PGP pour des besoins simples, en local notamment. Si vous voulez en savoir plus, le dépôt Git est publique. Petite exemple avec la création d’une clé : # Création d'une clé age-keygen -o private.txt # On export le fichier contenant la clé privée : export SOPS_AGE_KEY_FILE="~/private.txt" # On peut aussi exporter directement la clé : export SOPS_AGE_KEY="<AGE_PRIVTE_KEY>" Tout comme PGP, j'aurai aussi pu utiliser directement le paramèrte en CLI --age <VOTRE CLÉ PUBLIC> Manipulation de base des fichiers Pour modifier des fichiers, il suffit de faire la commande sops <FILENAME>, un fichier sera créé si aucuns n’existe, sinon il sera ouvert avec votre éditeur favori. On constate que si on essaye de consulter le fichier sans SOPS, avec cat par exemple, celui-ci est bien chiffré : ❯ cat demo.json { "hello": "ENC[AES256_GCM,data:CNT6xm/V+fNiMPNVkYob,iv:A97AN48RnPKwIWw1phDCsz5173SfwhOTYS7ruv/g "example_key": "ENC[AES256_GCM,data:FkvHEbCzUurxjBRtEg==,iv:4KpxUeKXxsWM6ovFfK3KzBaLt7Lhe+cRYg "example_array": [ "ENC[AES256_GCM,data:brsfGZb5RTbd6LptRNg=,iv:cVP3FAhfHZrJ0wyRFXkvxVsOpDnzJJJaGhDbTXu2J "ENC[AES256_GCM,data:pgS9SPpFhuHEdxc=,iv:kGNeXctjpuOGwIrUqPKygSNDZQ3tn1ezJ/jA/LGL0Kg=, ], "example_number": "ENC[AES256_GCM,data:2hF1/gxuNa7L,iv:APQXF55YNOf2b1I7WqUo2FkJjKBdzoRf0/Ddjic "example_booleans": [ "ENC[AES256_GCM,data:V6++nQ==,iv:87GrwookidDyM4gpffbf3FhcX0wWE7ArxMVt3COUS9A=,tag:br37 "ENC[AES256_GCM,data:65PVZDA=,iv:GS9nzbsALrAQuC0RYkfIWdmkdJIjnQsLu2wLIgrswsY=,tag:VqxC ], "sops": { "kms": null, "gcp_kms": null, "azure_kv": null, "hc_vault": null, "age": [ { "recipient": "age1w07kwz4ff5f3lfsaah9q3qpqpt9fwjadj6f37hfkej7y2tjm55zs "enc": "-----BEGIN AGE ENCRYPTED FILE-----nYWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSB2UFdYbkpDcnpaek5jUC9Nnb1pIb296anFtK25QNmV5Yk1rTTlHR3pZWVVvCkdRMjAwZWNLT2xpd1R1c3ZDSDgvnUE03SEpEMng0Q1JnMnI0NFRYQkwzdFkKLS0tIDA0YjZ2d09veHcydWFiZGVRRGdpna3ByM1Rocm90VjNBL2lxMEhsTlJCc00KbjavVxgs7JeOvFwRDWupePggMZ3NEr8enZvQihxsNYTxdD95QtJQfns+bcGXmCSnGq66Rv/P+LWfhrEgL4KN35Q==n-----END AGE ENCRYPTED FILE-----n" } ], "lastmodified": "2023-10-03T19:40:39Z", "mac": "ENC[AES256_GCM,data:txriRB+7w56xm7DnU9TrADNm6NDdhw41MTYfiqaFmDbyv0AN0DQ80zU46fD6dFJu5yP1q0Qd9sh+V2FdVoNZLmHKE5fi1t2OowtoL3mmGrEE3mqCvJuESI2yIjCgfY42kkj5HH7Lk+jSnATNz+jzfxNuZss39G1bPGZwrzmvlJ8=,iv:5DBu91Nadq+fEAEgjmkl+yqSKHbuFUwipi2Jrls7jBQ=,tag:77LwtA96Tw7PfceiB2ltqA==,type:str]", "pgp": null, "unencrypted_suffix": "_unencrypted", "version": "3.8.0" } }% Vous pouvez remarquez que le fichier contient aussi les metadatas nécessaire à SOPS. Pour afficher le contenu du fichier déchiffré je peux utiliser la commande sops -d <FILENAME> qui va permettre d’afficher le contenu déchiffré sans ouvrir l'éditeur : ❯ sops -d demo.json { "hello": "Fichier de demo", "example_key": "example_value", "example_array": [ "Vous ne pouvez", "pas me lire" ], "example_number": 1773.1773, "example_booleans": [ true, false ] } On peut même directement extraire des valeurs précises : sops -d --extract '["env"]["prod"]["db"]["password"]'. Dans notre cas : ❯ sops -d --extract '["hello"]' demo.json Fichier de demo% Configuration Imaginons la situation suivante qui est plutôt courante. On souhaite regrouper dans un dossier plusieurs fichiers de configuration pour les différents environements. On va vouloir les chiffrer avec des clés différentes en fonction des environnements. Jongler entre les clés peut très rapidement devenir fatiguant. Ça tombe bien, vous pouvez configurer celles-ci avec un simple fichier de configuration YAML .sops.yaml. Si aucun fichier de configuration n’est présent dans le répertoire courant, SOPS va de manière récursive chercher dans le répertoire parent. Ce fichier va permettre de configurer en fonction de RegEx sur les chemins, différentes clés qui seront automatiquement configurées. WARNING: si vous utilisez un fichier de configuration, les options de sélection de clés en cli annuleront les règles présentes dans le fichier. Exemple de fichier .sops.yaml : creation_rules: - path_regex: demo.json$ age: 'age15lxggyhzkvzpxrczkf4alnuhejj8xdje602ay8zm3msy2djjuufsqsrt2g,age1w07kwz4ff5f3lfsaah9q3qpqpt9fwjadj6f37hfkej7y2tjm55zs0hugwg' #Clés séparées par une virgule Lle fichier demo.json pourra être déchiffré automatiquement avec SOPS à condition d’avoir la partie privée d’une des deux clés publiques Age. Ce qui veut aussi dire que si demain vous souhaitez ajouter ou supprimer un accès, vous devez supprimer la clé de la liste. Néanmoins une fois le fichier .sops.yaml modifié, celui-ci ne va pas mettre à jour les fichiers qui sont impactés. Il vous faudra utiliser la commande sops updatekeys <fichier_chiffré> pour mettre à jour les clés. ❯ sops updatekeys demo.json 2023/10/29 17:45:29 Syncing keys for file /home/thomas/Documents/sops-demo/base-exemple/demo.json The following changes will be made to the file's groups: Group 1 age1w07kwz4ff5f3lfsaah9q3qpqpt9fwjadj6f37hfkej7y2tjm55zs0hugwg +++ age15lxggyhzkvzpxrczkf4alnuhejj8xdje602ay8zm3msy2djjuufsqsrt2g Is this okay? (y/n):y 2023/10/29 17:45:41 File /home/thomas/Documents/sops-demo/base-exemple/demo.json synced with new key Il est aussi possible de donner plusieurs clés en argument à la création en les séparant par des virgules. Exemple : sops –age=, demo.json Dans la vie des SREs Bon, éditer les fichiers, les afficher c’est bien beau, mais on veut surtout que nos outils et systèmes puissent consulter les secrets. Je vais en majorité utiliser Age pour ces exemples, mais comme vous l’aurez deviné ils sont adaptables avec les autres protocoles supportés par SOPS. Usage dans la CI/CD (Gitlab CI) Souvent le premier vrai cas d’usage dans lequel on a besoin de récupérer des secrets c’est la CI/CD. Ici je vais vous montrer ce que ça donne sous Gitlab. À savoir que pour l’instant, SOPS n’est pas nativement supporté dans Gitlab, il va donc falloir procéder de manière plus manuelle. Il faut avant tout créer une image Docker dans laquelle on va exécuter notre job. Personnellement, je suis resté sur du basique : FROM debian:testing RUN apt-get update && apt-get install -y gnupg age curl RUN curl -qsL https://github.com/getsops/sops/releases/download/v3.8.1/sops-v3.8.1.linux.amd64 -o /opt/sops && chmod +x /opt/sops Si vous souhaitez tester directement, l’image est publique : Docker hub On peut ensuite utiliser l’image dans notre CI/CD pour déchiffrer not mots de passe. On commence par créer une paire de clé pour la CI/CD : age-keygen -o key-gitlab.txt Attention : Il est possible de partager les clés mais cela est largement déconseillé pour des questions de sécurité. Il faut aussi faire attention à ne pas commit les fichiers Age qui contiennent la clé publique ET privée. Dans notre cas on va chiffrer un fichier yaml par environnement qui va contenir nos variables sensibles : sops --age=<Gitlab-age-pub-key>,<my-age-pub-key> env.dev.encrypted.yml, je répète l’opération pour l’environnement de staging. J’aurais aussi pu passer par un fichier : .sops.yaml. Je vais ici, faire un fichier .gitlab-ci.yml de CI simple afin de montrer le principe et de tester image: damyr/sops-ci test_dev: before_script: sops -d env.dev.encrypted.yml > env.yml script: cat env.yml test_staging: before_script: sops -d env.staging.encrypted.yml > env.yml script: cat env.yml C’est simple, mais ça vous laisse imaginer ce qu’il est possible de faire ensuite avec ces environnements. WARNING: Je déconseille par contre de stocker ce fichier en clair dans des artefacts de CI/CD, en cas d'accès au runner ils pourraient être trouvés déchiffrésr. Il me reste plus qu’à ajouter la clé privée (SOPS_AGE_KEY) en variable protégée de CI/CD. Une démo simple, des possibilités infinies Usage avec Terraform Terraform est l’un des outils qui nécessite le plus d’accéder à des secrets et d’en créer de nouveaux, ce qui souligne l’importance cruciale de l’intégration de SOPS. Pour simplifier l’usage avec Terraform, un provider est disponible, testons le ! provider "sops" { // age dans notre cas, les autres implémentations fonctionnes age = { key = "~/Documents/sops-demo/terraform/keys-tf.txt" // A mettre si vous ne souhaitez pas passer par les variables d'environnement standard SOPS } } Si on souhaite lire les datas de notre fichier vars.json, on va pouvoir directement utiliser un datasource sops_file : data "sops_file" "id" { source_file = "vars.json" } output "database-user" { value = data.sops_file.id.data["user"] sensitive = true } output "database-password" { value = data.sops_file.id.data["password"] sensitive = true } Je vais utiliser json qui est plus simple de manipulation dans ce cas d’usage et évite de devoir passer par un cast intermédiaire. À noter que la documentation, parle d’une ressource pour écrire des secrets (https://registry.terraform.io/providers/lokkersp/sops/latest/docs/resources/file), mais celle-ci n’est pas implémentée dans le provider. Aussi le provider peut rapidement montrer des limites sur des structures un peu complexes notamment en yaml. À suivre l’évolution de celui-ci. Je préfère mettre mes secrets sous forme d’un yaml et le déchiffrer avec la commande SOPS en amont. Néanmoins, il faut bien faire attention à ne pas commit le fichier déchiffré. Utilisation avec Kubernetes (FluxCD) S’il y a bien une plateforme dont j’aime particulièrement les apports ces dernières années c’est bien Kubernetes. Parmi ces nouveautés il y a une approche que j’apprécie tout particulièrement, c’est le GitOps avec FluxCD. Pour résumer, vous allez décrire l’ensemble des ressources de votre cluster sous forme de fichier YAML dans un repos Git et FluxCD va s’occuper de synchroniser et réconcilier l’ensemble en permanence. Le workflow GitOps Certains d’entre vous doivent déjà faire le lien avec le sujet de l’article. Comment faire pour push des secrets sur Git à destination de FluxCD pour les déployer sur Kubernetes tout en assurant le chiffrement ? Et ça tombe bien, FluxCD supporte SOPS ! Et on va voir comment ça se passe. Je commence avec une arborescence FluxCD assez classique, proche de la structure Monorepo décrite dans la documentation officielle. Pour rester simple et efficace, je vais m’imposer une convention. Tous les fichiers chiffrés seront dans une arborescence à part pour éviter les blagues et je vais me limiter aux champs : data et stringData. Je vais définir ça dans le fameux fichier .sopos.yaml à la racine de mon dépôt FluxCD. creation_rules: - path_regex: ^secrets/.*.(yaml|yml)$ encrypted_regex: '^(data|stringData)$' age: '<ma-clé-pub>,<clé-pub-de-fluxcd>' On va ensuite pouvoir faire notre premier secret. Commençons par un secret bien classique dans le monde k8s: le secret d’authentification au Docker registry. On le créer notre secret : kubectl create secret docker-registry regcred --docker-server=registry.damyr.fr --docker-username=damyr --docker-password=password@demo@fakepassword --docker-email=demo.damyr.fr --dry-run=client -o yaml > secrets/staging/regcred.yaml Je le chiffre ensuite : sops --encrypt --in-place secrets/staging/regcred.yaml Fluxcd doit déjà être fonctionnel sur le cluster à partir de là, je vous laisse consulter la documentation officielle si vous ne l’avez jamais installé. Je crée ensuite mon secret qui va contenir la clé de FluxCD : kubectl create secret generic sops-age --namespace=flux-system --from-file=age.agekey=kube.key. Celui-ci est placé dans le même namespace de FluxCD, lui seul est censé déchiffrer les fichiers. On crée ensuite l’appel au dossier avec une Kustomization : apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: secrets namespace: flux-system spec: interval: 5m0s path: ../secrets/staging prune: true sourceRef: kind: GitRepository name: flux-system decryption: provider: sops secretRef: name: sops-age Je push ensuite la kustomization sur mon dépôt Git. Une fois que FluxCD a bien fait la réconciliation, notre secret apparait : ❯ kubectl get secret NAME TYPE DATA AGE regcred kubernetes.io/dockerconfigjson 1 58s Qu'en penser ? La gestion des secrets est plus que jamais une problématique centrale dans nos métiers, notamment avec l'automatisation qui a mis en exergue les besoins de ce côté. C'est un domaine où je n'ai pas vu de grande diversité, la majorité utilisant la solution fournie par leurs provider cloud ou la solution Vault d'Hasicorp qui est très populaire. Une partie utilise aussi Git-crypt avec les désavantages que ça apporte. Face à une problématique aussi cruciale, adopter une approche agnostique semble être une option judicieuse. C’est là que SOPS se distingue en proposant une solution à la fois simple et entièrement décentralisée, qui se rapproche davantage de Git-crypt que de Vault d’Hasicorp, tout en offrant des fonctionnalités essentielles telles que le chiffrement des clés, la gestion des fichiers de configuration, le chiffrement intelligent et partiel des fichiers, la rotation des clés, et bien plus encore. Dans de nombreux cas, SOPS s’avère être une solution adaptée, qui ne demande ni infrastructure supplémentaire ni abonnement. L’un de ses principaux avantages réside dans sa simplicité d’utilisation. Comme nous l’avons constaté dans les exemples concrets de notre quotidien, l’intégration de certaines solutions n’est pas toujours parfaite ni native. Cependant, la simplicité de SOPS permet de l’intégrer en amont de manière transparente pour faciliter le pré-déchiffrement. Cependant, il est important de noter que SOPS présente également des limites. Son approche décentralisée signifie qu’il offre moins de contrôle sur l’accès aux secrets, car chaque détenteur de la clé peut les consulter sans restriction, sans qu’un système centralisé ne puisse enregistrer ces accès. De plus, SOPS ne propose pas de solution de rotation automatique des secrets, ce qui constitue encore une lacune à combler. Head photo by Philip Swinburn on Unsplash

Un des outils de base que l'on utilise tous les jours après l’éditeur de code et peut-être le navigateur, c'est le multiplexeur de terminal. Celui qui vous permet de laisser tourner des programmes en arrière plan en conservant le contexte, partager un terminal en direct , mais aussi bien sûr de multiplier les terminaux et de les arranger comme bon vous semble. Utilisateur de Tmux de longue date comme vous avez pu le deviner au travers de certains articles, je me suis posé la question d'une possible migration après avoir vu Zellij dans mon fil Twitter il y a quelques mois. Les promesses ? Plus de flexibilité, de modernité, le tout en restant très léger et rapide. Après un premier essai trop rapide il y a quelque temps, j'ai décidé de retenter l'expérience en prenant le temps de mieux comprendre ce qu'il y a sous le capot. La découverte Première chose intéressante c'est que l'on peut tester Zellij sans même l'installer ! bash <(curl -L zellij.dev/launch) Le script du curl est assez basique et installe tout de même une release dans le répertoire temporaire /tmp Aucun package n'est malheureusement disponible pour Debian, je passe donc par asdf qui lui permet de l'installer. L'interface par défaut est assez claire et a le bon goût d'afficher en bas une aide rappelant les différents raccourcis clavier. Chargé, mais tout est là Rapidement nous retrouvons nos marques et nous réussissons à créer, supprimer, naviguer entre les différents panneaux et onglets. Chose intéressante Aram Drevekenin le développeur de Zellij a choisi une approche modale comme Vim. Par exemple pour changer le nom d'un onglet, vous allez d'abord passer en mode onglet <crtl+t>, choisir votre onglet, puis faire <r> pour le renommer. C'est une approche qui ne perdra pas les utilisateurs de Vim, mais qui va demander un peu de pratique à d'autres. Une fois habitué c'est très flexible et rapide, les contrôles par défaut sont plutôt bien définis. Les fonctionnalités sympas Bon pouvoir multiplier les terminaux comme des petits pains c'est sympatique, mais Tmux et Screen le font eux aussi très bien. Donc je ne vais pas m’étendre dessus et je vais plutôt vous présenter les fonctionnalités qui m'ont fait quitter Tmux. Les fenêtres flottantes Souvent dans mon travail quotidien quand je code ou autre et j'ai besoin d'un terminal pour lancer une action, un test, un build ou autre sans pour autant l'ajouter à mon layout. Avec Tmux, j'ouvrais un onglet temporaire et je le fermais, c’était plutôt lourd. Zellij répond parfaitement à ce problème avec la notion de fenêtres flottantes, vous pouvez en effet à tout moment ouvrir un panneau flottant au-dessus des autres. Pour cela rien de plus simple, en mode pane <ctrl+p> faite <alt+w> ! Une efficacié redoutable Mais attendez, ce n’est que le début ! Cette fonctionnalité va bien plus loin. Vous pouvez les déplacer à la souris, même si ce n’est pas le plus ergonomique je trouve ça incroyable et ça m'a déjà servi. Vous pouvez en créer plusieurs en même temps, ce dont j'ai rarement besoin, mais qui reste une option. Pour le coup, une fois votre action terminée vous pouvez les passer au second plan avec le même raccourci et y revenir quand vous le souhaitez. C'est très pratique d'avoir une session flexible pour de petites actions. Une habitude que vous allez vite prendre ! Sortie de commande vers éditeur Surement un titre un peu obscur, mais cette fonctionnalité est très pratique. Vous pouvez ouvrir l'output d'une commande dans votre éditeur favori en un raccourci ! Si vous faites en mode search <ctrl+s>, la commande édite <s> un fichier temporaire va être automatiquement créé avec le contenu des commandes précédentes. Dans mon cas, c'est pratique pour traiter avec NeoVim des sorties un peu complexes que je veux nettoyer avant d'envoyer. Les layouts Avec le temps on a tous nos petites habitudes de travail avec notre petite organisation des terminaux quand on fait des actions courantes. Tiens, prenons l'exemple de ce blog, j'écris mes articles sous NeoVim pour des questions de pratique, je divise en 3 zones : La principale, mon éditeur dans lequel j'écris l'article La zone en bas à gauche, où j'ai Hugo (le CMS static) qui tourne en local Et enfin la zone en bas à droite où j'ai un terminal pour git et d'autres petites actions Le confort en une seconde J'ai des organisations similaires pour un ensemble de cas, Terraform, debug d'industrialisation et j'en passe. En général, on refait rapidement son installation à chaque fois, ce n'est pas grand-chose en soi. Néanmoins, ça reste une action répétitive sur lequel Zellij vous propose une solution, les layout ! Vous pouvez définir dans des fichiers une organisation de panneaux avec les différentes proportions et même exécuter automatiquement les bonnes commandes. Le plus simple est de prendre l'exemple que je vous ai montré un peu plus haut avec mon blog. Le code pour mon layout est le suivant : layout { pane size=50 // La définition des tailles en % marche pas toujours au mieux pane split_direction="vertical" { // on peut split pane command="make" { // on peut lancer des commandes automatiquement args "local" } pane command="git" { args "status" } } pane size=1 borderless=true { // on doit définir les menus si ont le veut plugin location="zellij:tab-bar" } } D'ailleurs si vous ne souhaitez pas démarrer votre fichier de zéro vous pouvez l'initialiser avec le layout par défaut : zellij setup –dump-layout default Pour lancer un de ces layouts rien de plus simple, faite juste un : zellij action new-tab –layout <votre_layout>.kdl Personnellement, je mets un fichier .zellij.kdl dans les projets où j'utilise un layout spécifique, ça me fait gagner un peu de temps, mais surtout du confort. Personnalisation Bien que les layouts soient déjà une sorte de personnalisation très intéressante et puissante, Zellij ne s'arrête pas là bien sûr. Configuration Si vous avez été attentif, vous avez remarqué que l'interface des exemples précédents ne ressemble pas à la première. C'est normal, je l'ai personnalisé et encore une fois c'est très accessible. Comme la majorité des outils, vous pouvez définir un fichier de configuration dans ~/.config/zellij/config.kdl. Vous pouvez générer une base par défaut avec la commande : zellij setup --dump-config > ~/.config/zellij/config.kdl On remarque à nouveau l'utilisation de .kdl qui est un nouveau langage de configuration, une alternative aux traditionnels Yaml ou encore Toml. Dans cette configuration, je vous passe le premier nœud de paramètre keybinds, qui vous permet bien sûr de personnaliser l'ensemble des raccourcis. C'est ici qu'on va définir les plugins notamment, personnellement je suis encore sur ceux fournis par défaut : plugins { tab-bar { path "tab-bar"; } status-bar { path "status-bar"; } strider { path "strider"; } compact-bar { path "compact-bar"; } } Ensuite il y a la définition des thèmes, vous pouvez en définir plusieurs, utilisant uniquement Nord, j'ai supprimé les autres. On peut sélectionner le thème à utiliser avec theme “nord”. N'aimant pas avoir 2000 niveaux de menu et de barre qui me rappelles que trop les Internet Explorer familiaux accumulant les toolbars, j'ai réduit aux maximums ceux-ci avec les deux options suivantes : default_layout "compact" simplified_ui true A noter un gros avantage de Zellij, j'ai directement dans la configuration pu définir la commande à utiliser pour faire des copier-coller. Par défaut, il vous suffit de sélectionner du texte pour copier. Ma configuration Zellij est disponible sur mon Github Les plugins Les plugins sont essentiels sur ce type de solution pour garantir une personnalisation accrue. Pour le coup, dans Zellij tout est plugin, y compris les barres d'onglet et de menu ce qui en fait un outil très flexible. Zellij étant écrit en Rust, on pourrait penser que nous sommes obligés d'utiliser nous aussi Rust pour les plugins, mais il n'en est rien. Ils ont le bon goût de se reposer sur WebAssembly qui permet de développer son plugin avec n'importe quel langage ! Néanmoins, même si la base est solide, elle est encore très jeune et demande sûrement un peu de temps avant d'avoir un écosystème aussi complet que les concurrents historiques. La fin de Tmux et Screen ? Objectivement depuis mon passage à Zellij, je ne suis retourné qu'une fois à Tmux. Tout simplement, car je n'ai pas encore trouvé le moyen de synchroniser des inputs entrées en ensemble de terminaux. Sur tous les autres points, je n'ai aucun reproche à faire à Zellij, il fonctionne très bien, ne souffre pas de bug ou de latence forte dus à son jeune âge. Le choix de la solution technique me semble très pertinent et efficace, que ce soit pour Rust, WebAssembly ou encore KDL que j'ai découvert avec ce projet. En bref, comment faire autrement que de le conseiller ? Essayez-le, même avec le système d’installation temporaire. Head photo by Vadim Sherbakov on Unsplash

Je parle beaucoup de cloud public, que ça soit US ou EU et pour le coup s’il y a bien une chose qui me manque énormément quand j’utilise les solutions clouds EU c’est bien le service IAM. Je ne pense pas que ce service soit anodin, il est la pierre angulaire de la sécurité dans le cloud aujourd’hui. La bonne nouvelle, c’est que Scaleway a sorti sa solution IAM pour son offre cloud ! Une bonne occasion de tester ça. IAM c’est quoi ? Avant tout, définissons un peu IAM, à quoi ça sert et les fonctionnalités qu’on peut y retrouver. Si on définit de manière large, IAM pour Identity and Access Management sert tout simplement à gérer les identités et les accès à la plateforme. Le tout en permettant d’associer des sets de droits spécifiques pour des utilisateurs ou groupes d’utilisateurs au travers de policy. Par exemple, si vous avez besoin d’un utilisateur qui doit pouvoir récupérer des images de conteneur dans un registry du cloud provider vous allez passer par IAM. Dans l’idéal vous allez même lui limiter les droits en lecture sur les images spécifiques. C’est ici le domaine principal de l’IAM, ce qui en fait la serrure sur la porte d’entrée qu'est l'API du fournisseur cloud. À cela, peut s’ajouter plusieurs fonctionnalités plus avancées, comme la lecture des logs des appels APIs sur vos comptes, ce qui est très important du point de vue auditabilité et souvent négligé. Ou encore l’intégration des solutions hébergées dans IAM, ainsi vous pouvez utiliser IAM pour vous connecter à l'API d'un Kubernetes hébergé, une centralisation bienvenue. L’offre de Scaleway IAM était promis et attendu depuis longtemps par les utilisateurs de Scaleway. Actuellement il n’existait qu’une seule vraie limite au sein d’une organisation, c’était la notion de projet avec des clés scopes à celui-ci. C’est chose corrigée avec l’IAM, aujourd’hui. Quand on regarde la page de présentation, on note les points suivants : On a la possibilité de gérer des utilisateurs et de leurs attacher des règles Les règles (policy) sont personnalisables On peut créer des utilisateurs applicatifs La solution est décrite comme simple, quand on connaît AWS IAM c’est une grosse promesse C’est intégré dès le premier jour à Terraform et à la CLI Scaleway Sur le papier c’est clairement une offre intéressante et surtout qui surpasse déjà les solutions concurrentes des autres fournisseurs français. À l’usage ça donne quoi ? Sur la console web À l’arrivée sur la console de gestion, on retrouve dans le menu utilisateur en haut à droite le service IAM. Celui-ci rejoint ce menu qui regroupait déjà les précédentes options de gestion comme pour l’organisation. On nous demande ensuite de l’activer si on le souhaite, on nous précise que l’opération va migrer les droits et clés existantes. Activation en un clic Je précise que je n'ai eu aucun problème de compatibilité, ou d'anciennes clés qui ont été révoquées lors de cette migration. Dans ce test nous créons le moins de ressource possible côté console, je vais néanmoins l’utiliser pour créer un utilisateur pour mon outil d’infrastructure as code Terraform. Je note que les menus d’IAM sont plutôt clairs et permettent une vue globale sur les utilisateurs avec notamment un récapitulatif sur l’activation du 2FA, ce qui est agréable. Pour cela je créé une application et j’y adjoins un set de règle que je créer dans la foulé. J’arrive rapidement à une des parties que j’attends le plus: la conception des règles. C’est le vrai enjeu de l’IAM de pouvoir gérer des droits fins, le tout en étant accessible. Trouver un équilibre là-dessus n’est pas un exercice simple. Si je prends l’exemple d’AWS, leurs systèmes sont top au niveau personnalisation et finesse, mais d’une assez grosse complexité qui finit par pousser les entreprises les moins contentieuses à utiliser des droits très larges. On sent un travail sur l'UX Globalement ici, ça se passe en 2 étapes : On choisit le scope (un projet, tous les projets ou toute l’organisation) On assigne ensuite un pré-set d’autorisations en fonction du service (lecture seule sur les instances, full accès sur les instances, etc.) Dans mon cas, vu que le Terraform va gérer l’IAM, je dois passer par le scope organisation. Je peux ensuite ajouter d’autres règles, dans mon cas il ne me suffit que d’une règle. Je note quand même que j’ai dû recréer ma policy à plusieurs reprises, tombant plusieurs fois sur des messages d’erreur ne précisant pas le problème à date du test (le 4 janvier 2023). Dans l'Infrastructure As Code Maintenant, lançons-nous dans l’iac. Comme tous mes tests, je vous encourage à vous faire votre propre avis dans cette optique le code source du poc est disponible sur : github.com Je vais créer : Trois applications Deux groupes avec chacun des set de règles Ajouter mon utilisateur à un des groupes Je commence par créer mes trois applications et mes deux groupes : resource "scaleway_iam_application" "app" { count = length(var.apps) name = "poc-application-${var.apps[count.index]}" description = "A simple application to create" } resource "scaleway_iam_group" "dev" { name = "dev_group" application_ids = [scaleway_iam_application.app[0].id, scaleway_iam_application.app[1].id] } resource "scaleway_iam_group" "ops" { name = "ops_group" application_ids = [scaleway_iam_application.app[2].id] user_ids = [data.scaleway_iam_user.moi.id] } Pas de soucis par ici, les groupes peuvent tout à fait regrouper utilisateur classique et applicatif. Je vous conseille d’ailleurs de toujours utiliser des groupes pour attacher les droits, cela simplifiera votre gestion. Vient ensuite la création de deux set de règles : dev_policy : qui va venir autoriser sur le compte de prod en readonly sur kapsules, les buckets et en write sur le staging. ops_policy : qui aura les droits en lecture et écriture sur le même set de service. Ce qui nous donne ce résultat sous Terraform : resource "scaleway_iam_policy" "dev" { name = "developers permissions" group_id = scaleway_iam_group.dev.id rule { project_ids = [data.scaleway_account_project.staging.id, data.scaleway_account_project.prod.id] permission_set_names = ["InstancesReadOnly", "KubernetesReadOnly", "ObjectStorageBucketsRead"] } rule { project_ids = [data.scaleway_account_project.staging.id] permission_set_names = ["ObjectStorageObjectsWrite"] } } resource "scaleway_iam_policy" "ops" { name = "SRE permissions" group_id = scaleway_iam_group.ops.id rule { project_ids = [data.scaleway_account_project.staging.id, data.scaleway_account_project.prod.id] permission_set_names = ["KubernetesFullAccess", "InstancesFullAccess", "ObjectStorageBucketsRead", "ObjectStorageObjectsWrite"] } } Pour information, les set de règles sont disponibles avec la commande scw iam permission-set list. Je note qu’il existe aussi la ressource scaleway_iam_api_key, je ne l’utiliserai pas et je déconseille fortement son utilisation comme sur AWS d’ailleurs. Tout simplement, car celle-ci stocke les tokens en clair dans les states Terraform. Si je tente de créer une ressource hors des droits, le code d’erreur est bon et explicite aussi bien avec la cli qu’avec Terraform : scaleway_instance_ip.test: Creating... ╷ │ Error: scaleway-sdk-go: http error 403 Forbidden: insufficient permissions │ │ with scaleway_instance_ip.test, │ on test.tf line 1, in resource "scaleway_instance_ip" "test": │ 1: resource "scaleway_instance_ip" "test" {} │ ╵ À partir de là, on peut créer nos clés et effectuer nos tests. De là on peut continuer normalement à utiliser l’ensemble des services. J’ai testé à l’utilisation notamment le cloisonnement entre projets et je n’ai pas rencontré de problème hormis quelques erreurs sporadiques à la création de policy avec la console web. Une base solide, mais quelques limites Le service fonctionne comme promis, vous pouvez créer, gérer les droits et les accès aux services Scaleway de votre organisation. Et je dois avouer que l’intégration notamment sur Terraform et la documentation le premier jour est un très bon point. Cela n’empêche pas d’y voir déjà quelques limites. Tout d’abord, les règles prédéfinies sont tout de même assez limitées. Alors oui, pour beaucoup ça sera suffisant, mais j’avoue rester sur ma faim sur cette partie. De même il s’agit uniquement d’additionner des droits pas de système de deny ou autre, d’un côté cela permet de garder une simplicité, mais ça réduit aussi les possibilités. L’offre manque aussi de flexibilité, il n’est pas possible de déléguer la gestion IAM d’un projet spécifique à un utilisateur. Au niveau global, j'attends maintenant les fonctionnalités annexes à IAM, qui reposent dessus. Comme par exemple, l'authentification keyless entre service ou encore pouvoir me connecter à Kapsule ou une base managée avec un utilisateur IAM Scaleway, sans oublier l'accès aux logs d'API sur une organisation. Il faut tout de même noter que techniquement, le plus difficile est fait, la couche IAM est intégrée aux API Scaleway, mine de rien c'est souvent le point de blocage. Malgré ces quelques ombres au tableau, ça reste un très gros pas en avant et je félicite les équipes de Scaleway sur ce travail. Je vais surveiller de près ce produit et surtout son évolution. Si je sujet vous intéresses j'ai eu la chance, d'échanger avec des membres de l'équipe IAM Scaleway lors du podcast DevObs disponible par ici : Dev’Obs #30 / IAM @ Scaleway.

Dans les sujets classiques et incontournables de nos métiers, nous retrouvons toujours la veille technologique. Nous allons donc voir ensemble pourquoi la faire et aussi comment j'effectue ma veille technologique de manière efficace. Pourquoi faire la veille Avant tout, pour qu'il n'y ait pas de confusion, je distingue la veille de la formation, qui à mon sens demandent un traitement différent, même si elles sont complémentaires. La formation est une approche longue qui se fait pour se former complètement sur un sujet. Beaucoup voient la veille comme une excuse pour traîner sur Twitter au bureau. Même si la veille peut s’effectuer sur Twitter, le premier but reste d'apprendre et de découvrir de nouvelles solutions. Pour beaucoup, la veille peut paraître à première vue une perte de temps et il peut être tentant de penser qu'il est bien plus efficace d'apprendre uniquement le nécessaire. Je ne pense pas que ce soit une perte de temps, au contraire, faire la veille c'est aussi voir comment d'autres répondent à des problèmes et avec quelles solutions. Trouver des technologies et méthodologies qu'on n’aurait pas découvert dans notre contexte professionnel pour potentiellement les utiliser. La veille technique doit vous permettre d’apporter à votre expérience professionnelle d'autres points de vue et aussi un regard critique pour améliorer le fonctionnement des outils et des organisations. Elle a aussi pour but de vous aider à suivre l'évolution de vos technologies, nouvelles versions, nouveaux apports. En cas d’évolution forte, changement de technologie ou mise à jour majeure c'est la veille qui va vous permettre de rester efficace et de planifier votre calendrier de formation. Quand faire sa veille C'est souvent la question, dois-je faire ma veille sur mon temps personnel ? Quand réserver du temps? Qu'on soit bien d'accord la veille est, je pense, nécessaire pour travailler plus efficacement et fait partie intégrante de nos métiers. Elle doit donc être faite sur le temps de travail. Même s'il m'arrive de lire un article sur le temps personnel cela ne doit pas être une obligation. Pour le quand, j’essaie d’en faire régulièrement une fois par jour au moins une petite session, 20 minutes de lecture d'un ou deux articles. Ces petites sessions se casent plutôt bien avant une réunion, quand on a pas le temps de se plonger dans un nouveau sujet. Ou vers 16h pour faire une petite pause mentale quand on est sur un sujet un peu long. Je vous recommande aussi fortement de ne pas faire votre veille entièrement seul. Partagez avec vos équipes, réservez des moments pour partager des découvertes. C'est un moment d'échange très intéressant et qui permet de capitaliser encore plus sur cette veille. Comment faire sa veille ? Pour faire la veille, il y a une panoplie incroyable de solutions qui existent, le plus important est de trouver celle qui vous convient. Néanmoins, je vais vous détailler le fonctionnement que j'utilise maintenant depuis plusieurs années : La veille de source connue Ce que j'appelle la veille de source connue c'est simplement le fait de veiller sur une liste de sources diverses, en majorité des blogs d'entreprises et de tech. Pour cela j'utilise, ce qui pour moi est le plus efficace RSS. RSS est un protocole qui va me permettre de regrouper en un lieu, dans mon cas une instance FreshRSS (outil que je vous recommande chaudement). Par exemple, si vous ajoutez mon blog sur un flux RSS (à l'aide de l'URL de Feed), lors de la publication d'un nouvel article, votre interface RSS vous informera de sa disponibilité. épuré et efficace Cela me permet en un seul endroit de surveiller les sorties sans avoir à vérifier une multitude de canaux. C'est souvent une partie de ma veille que j'aime bien, car elle est très efficace. Elle me prend peu de temps et je suis rarement déçu par un article. Mon feed étant déjà une liste triée de personnes que je prends beaucoup de plaisir à lire. Quelques sites que je vous recommande dans votre feed (en Français, je ne mets pas les blogs sans activité depuis trop longtemps) : Personnalité tech : Je Suis un dev : un très bon blog qui parle de Dev en général, le tout avec des articles très bien écrits depuis des années. C'est un de ceux qui m'ont donné envie de me lancer ! Bref foncez. Dadall : un blog orienté logiciel libre qui propose des articles toujours sympas si comme moi vous êtes utilisateur de logiciel libre. LaForge : un blog technique et super intéressant qui vous parle d'un tas de sujets du dev à l'ops en passant par le Rust (son langage favori). Avec de grosses qualités de vulgarisation mcorbin : le blog d'un SRE qui nous partage des pensées et des retours d'expériences bien documentés ! Stephane Robert : Sûrement un des blogs Fr les plus prolifiques sur le contenu ! Un mixte entre blog et wiki qui vous parlera sûrement. zwindler : un blog qui nous partage aussi bien outils, astuces que billetsplus généralistes sur l'IT ! La légende raconte même qu'il partage ses meilleures recettes de cuisine. tferdinand : L'Ops qui est tombé dans la sécurité, un blog au top qui aime partager sur le cloud et surtout la sécurité, domaine trop peu présent dans nos sphères. Organisation : Bearstech : ici on vous parle de performance ,de sécurité et de DevOps avec des techniques au top. Ippon : un blog qui parle là encore de toute la chaîne DevOps et même plus. Eleven Labs : vous parle beaucoup de Dev, mais aussi d'Ops, de gestion de projet dans ces articles. Enix : ravira sûrement les fans de Kubernetes ! Avec plein d’astuces de découvertes et de bonnes pratiques. WeScale : propose régulièrement des articles qualitatifs sur le cloud et le DevOps en général. LinuxFr : le site qui parle de linux et par extension de logiciel libre qu'on ne peut pas oublier Désolé pour ceux que j'ai oublié j'ai essayé de faire le tri entre les blogs qui ne publient plus et qui sont en Français. Bien sûr, la liste de mon RSS est plus conséquente, mais je trouvais peu intéressant de vous en faire un export brut. Si jamais vous restez sur votre faim, n'hésitez pas à en découvrir plus sur le dépôt Awesome french DevOps de Stephane Robert qui compile de manière collaborative les sources pour la veille : https://github.com/stephrobert/awesome-french-devops La veille d'exploration La veille de source connue pose néanmoins un gros problème, on peut rapidement se fermer à une liste de contenus. Ce qui, dans ma vision de ce besoin d'ouverture, n'est pas une bonne chose, j'aime aussi me confronter à des avis divergents des miens. Sans oublier que notre liste reste statique et de nouveaux blogs apparaissent régulièrement. Pour répondre à cette problématique de découverte plus large, j'utilise 3 sites : Tutomarks : qui est assez nouveau et vraiment très complet, il regroupe des articles de blog, des podcasts, des articles et bien d'autres types de contenu. HackerNew : un des sites les plus connus, il apporte énormément de variété dans mes découvertes. Journal du hacker : pour moi l'agrégateur avec un grand A des contenus français tech. Vraiment un gros merci à Carl Chenet de gérer ce site depuis tant d'années. (bonus) Internet : Au hasard de Twitter, Github et internet en général il m'arrive de trouver du contenu top ! C'est sûrement le moins efficient en termes de temps, mais souvent le plus satisfaisant. Les vidéos et podcasts Quand on voit mes sources, on remarque rapidement une omniprésence de contenu textuel, en effet il y a peu de podcasts et pour le coup aucune chaîne vidéo. Tout simplement, car j'ai du mal avec ces formats dans le cadre de la veille, j'ai du mal à les rendre efficaces. N'ayant pas de temps de trajet j'écoute au final peu de podcasts tech depuis 2 ans. En ce qui concerne les vidéos, bien que celles-ci soient à la mode, je n'accroche pas avec le fait de ne pas pouvoir simplement m’arrêter pour copier un code ou autre. Ce qui est pour moi une vrai gêne. J'en regarde donc, mais de manière moins systématique. Néanmoins ces formats peuvent tout à fait vous plaire et on ne manque pas de producteur de contenu de ce côté, donc n'hésitez pas. Allez plus loin avec la veille Vous savez désormais à quelques détails près tout sur la manière dont je conçois la veille et surtout comment je m’organise. N'hésitez pas à vous aussi à créer votre propre routine de fonctionnement, et à adapter vos outils pour que celle-ci soit efficace. N'oubliez pas que la veille est essentielle aussi bien au niveau individuel que de l'entreprise elle-même. Une entreprise fermée ne bénéficie pas de cette richesse d'approche. Même si ce blog n'est pas une chaîne Youtube, n'hésitez pas à vous abonner en passant par son flux RSS.

Après avoir écrit plus généralement ce qui avait fait et qui fait encore que les clouds US dominent le marché dans un article que vous pouvez trouver ici. J'ai eu l'occasion de voir une n-ième discussion sur les réseaux sociaux expliquant que les fournisseurs cloud français étaient au même niveau que les acteurs étatsuniens. Pointant notamment du doigt au passage des hyperscalers (comme Doctolib) et startups de choisir des clouds américains justes pour des raisons de crédits offerts. D'expérience, je sais que les crédits jouent, mais plus pour éviter de se faire dépasser par un Azure ou autre que par peur de la comparaissons avec les solutions françaises. J'en avais d'ailleurs déjà parlé dans l'article cité du départ. Au-delà de ces plaintes, trop souvent utilisées comme bouclier contre les critiques, la conversation a glissé sur : Qu'est-ce que les startups et hyperscaler attendent d'un fournisseur cloud ? Pour avoir travaillé avec ce type de client, je connais plutôt bien leurs besoins et surtout ce qu'elles recherchent. Et comme certains me l'ont conseillé, je vais partager ce qui est fréquemment attendu et pas forcément retrouvé chez nos prestataires français. Cloud “2.0” ? Les origines du cloud Je dis cloud 2.0, pour marquer une différence nette avec la vision moderne de celui-ci. En soi le cloud est un terme très vague de l'hébergement de serveurs physique, peut-être défini comme du cloud, notamment si c'est facturé à la demande. Sauf que depuis maintenant plusieurs années on attend plus du cloud des machines virtuelles, mais des services sur étagère qui permettent aux entreprises de construire leurs propres infrastructures. Il y a eu donc un glissement important, ce qui fait la qualité d'un fournisseur cloud n'est plus le matériel, mais le logiciel. C’est très souvent sur cette partie que se base le choix de la société. Elle pourrait très bien se contenter des serveurs et ensuite faire par elle-même toutes ces briques. Sauf qu'aujourd'hui ce n'est pas ce qu'elles recherchent pour des tas de raisons. Notamment le coût et le temps nécessaire pour développer des solutions qui généralement seront moins efficaces. Dans tous les cas, ce choix ne sera pas l'objet du débat de cet article. Alors le cloud 2.0 souverain parfait, il propose quoi ? Tout d'abord, ça dépend bien sûr des entreprises et des besoins. Les réseaux sociaux se plaignent pour la plupart de clients modernes et exigents sur le niveau logiciel. Dans la réalité, les demandes là sont assez proches de la majorité des startups qui cherchent à construire des solutions techniques. Cette liste de service est minimale et j'insiste bien là-dessus d'expérience ce qu'elles visent en termes d'offre comporte souvent des spécificités en fonction de leurs marchés, notamment sur la partie data. L'administration Quoi, vous vous attendiez à ce que je parle de service ultra avancée comme AWS Ground Station ? Non, cet article se veut pragmatique, on commence donc par la base qui est souvent oubliée. Dans l’administration, je regroupe plusieurs fonctionnalités qui sont vraiment importantes quand on s’adresse à une offre d'entreprise. Cela comprend : Possibilité de créer des comptes distincts (et pas d'utilisateur), pour séparer les environnements et permettre la délégation à des équipes spécifiques. Suivit financier à l'aide de TAGs avec centralisation de la facturation des différents comptes. Quand vous payez en millions les factures annuelles, vous avez besoin du détail. Dans l'idéal du SSO afin de faciliter la gestion des comptes. Une organisation de datacenter claire. Pour vous donner une illustration, AWS c'est limpide, vous voulez faire de la redondance, vous savez qu'une Availability Zone est isolée de tant de km d'une autre, une région c'est 10x plus de distance. À l'exemple inverse, je suis toujours effaré à propos de boites comme OVH en constatant que la moitié des datacenters sont très proches et souvent cette information, on l'apprend trop tard. C'est simple, et ça évite de grosses déconvenues qui vous font perdre beaucoup. Sécurité Surement l'un des points sur lesquels les attentes sont les plus grandes, car un cloud qu'il soit souverain ou pas se sécurise. Avoir un système de management de privilège complet (IAM), c'est juste vital pour faire du cloud. Quand je dis gestion fine, je ne parle pas de pouvoir dire c'est un compte de « lecture », mais bien de pouvoir gérer les droits sur un ensemble service + verbe. Là encore dans l'idéal, si on peut avoir des fonctionnalités comme des tokens temporaires, on prend. Du chiffrement disponible sur la totalité des services de stockage avec la possibilité d’utiliser des clés externes. Car oui, un cloud reste un environnement étranger qui représente une menace, moins grande que l'extérieur, mais une menace quand même. Avoir des logs d'audit des accès à l'API sur nos comptes. Au-delà d'être important pour la sécurité c'est en faire nécessaire dans beaucoup de cas pour des certifications ou autre. Je ne vais pas m'étendre là dessus, mais de plus en plus de mes clients demandaient des certifications, de l'ISO27001 et du SecNumCloud. Il s'agit souvent d'un critère éliminatoire. Machine virtuelle Souvent considéré comme du cloud à l'ancienne, les machines virtuelles se retrouvent encore régulièrement. Par contre, on attend plus que pouvoir créer des serveurs de manière statiques. Avoir un système de machine virtuelle à la demande, avec cloud init, gestion du réseau le tout pouvant être réparti sur plusieurs datacenters de manière transparente. Supporter les security groups avec la possibilité d'y faire référence dans les règles dans l'idéal Possibilité de prébuild les images de ces machines avec Packer ou autre. Proposer des loads balancers, avec gestion du HTTPS, certificats, redirection et des health-checks. Disposer d'une solution de scaling automatique. Avoir un groupe dans lequel on définit un nombre d'instances qui peut changer en fonction d'event ou trigger. Que ça soit pour du scale, de la réduction de coût, de la mise à jour, c'est la base aujourd'hui. Quand je parle de machine virtuelle dans ce contexte, je parle plus de groupe d'instances que d'instance. Réseau À force d'entendre parler de couche haute, notamment avec le serverless on oublie qu'on attend souvent encore des fonctionnalités réseau ! Des réseaux privés (VPC), pour isoler les ressources. Il doit évidemment être compatible avec le reste de votre offre. Imaginons si vous avez du Kubernetes managé, on aimerait ne pas exposer les APIs sur le net. Bien sûr dans les VPCs, je compte aussi tout ce qui est attaché : gateway, routing etc. La gestion de DNS, là encore l'idéal dépasse le simple resolver. Des fonctionnalités comme du check d'endpoint, de la résolution en fonction du pays. La possibilité de faire des interconnexions que ce soit avec un service de VPN classique ou de tunnel. Stockage Le stockage est souvent un point qui est uniquement abordé du point de vue capacité et performance, mais aujourd'hui là encore c'est sur le logiciel que se fait la différence. Du stockage par block simple efficace et flexible, pas grand-chose à dire là-dessus tant que ça fonctionne bien avec le reste de l'offre encore une fois. Du stockage objet, je ne compte plus le nombre de fois où des fournisseurs m'ont promis du stockage objet et je me suis retrouvé face à un service ultra dépouillé. Aujourd'hui des options comme l'hébergement d'assets web statique, le chiffrement, les lifecycles, les events et le versionning sont vraiment les bases de ce service. Bases de données Un point qui a fait beaucoup parler notamment au vu des fortes critiques sur Doctolib qui a un gros besoin de ce côté. Alors bien sûr un service de base de données fiable, qui scale c'est attendu. D’autres options comme la possibilité d'exploiter les logs (voir les exporter), créer des clusters multirégion et bien sûr les backups ! Pour ce qui est du type de base, cela dépend vraiment de la stack technique de l’entreprise. Il faut néanmoins s’assurer d’avoir à minima une base de données relationnelle et non relationnelle disponible. Je n'ajoute pas spécialement de besoin de ce côté, cela dépendant beaucoup de la volumétrie client. À noter que si vous gérez les éléments énoncés, une majorité des entreprises de notre catégorie s'en satisferont. Conteneur Difficile de ne pas parler de conteneur en abordant de cloud en 2022, ça tombe bien il y a des attentes sur ce point. Un registry afin de stocker les images avec de la haute disponibilité. On l'oublie régulièrement, mais un registry en rade peut avoir un impact direct sur la disponibilité de vos ressources sur Kubernetes. Et evidemment, Kubernetes qui est attendu par une majorité des clients. Un grand nombre des fournisseurs français le propose, mais là encore dans une version assez simple. Souvent, j'ai constaté le manque de haute disponibilité multizone, l'exposition d'API en public, l'authentification avec des tokens statiques. Faas Pouvoir exécuter des fonctions de code de manière automatique avec un trigger, webhook ou autre. C'est souvent quelque chose qui va se retrouver à gauche et à droite pour gérer des petites actions et automatismes. Néanmoins, c'est de plus en plus un point que j'ai vu passer en moins prioritaire notamment avec l'essor de Kubernetes. API Avoir une console web avec une bonne UX est toujours appréciable, mais aujourd'hui on l'utilise de moins en moins. Il faut donc une API, claire et documentée Au maximum, poussez la disponibilité de ces produits sur Terraform. Dans de nombreux cas, on considère un élément exploitable uniquement quand il arrive sur Terraform. C'est tout ? Oui et ce n’est pas si simple surtout en assurant une cohérence globale de la solution. Ce sont les fonctionnalités de base qu'une entreprise de type startup/scaleup recherche dans la majorité des situations. J'aurais pu aborder des services comme la gestion de secret, ou le monitoring mais j'ai rarement vu ce point bloquant. Je rajouterais même qu’il est préférable d’avoir moins, mais mieux fini que l’inverse. Le reste pouvant être facilement résolu par des plateformes externes, ou pas l'installation en interne. Conclusion J'ai l'impression que des entreprises comme Doctolib sont des cibles régulières, en particulier des providers français sans pour autant que leurs offres puissent actuellement adresser ce type de client. Surtout quand on remet sur le devant de la scène les histoires de crédits, dont à l'heure actuelle Doctolib ne doit plus vraiment profiter. J'aimerais que les fournisseurs français fassent des efforts, pour comprendre et proposer des solutions sur les points techniques. Surtout quand on voit qu'une grande partie de la communauté répond souvent pour donner des feedbacks et aider. C'est d'ailleurs la vocation de cet article. C'est d'autre part dommage que cette bonne volonté de la part de la communauté ne semble pas forcément appréciée. Notamment dans des messages ironiques quand on remonte des problèmes ou des besoins. Ces positions publiques me font questionner sur plusieurs points. Je n'arrive pas à savoir s'il s'agit d'un manque de vision sur ce qui est attendu de certains clients, ou une manière de communiquer. Ces éléments me donnent aussi l'impression qu'on est de plus en plus dans l'idée de confrontation que d'échange enrichissant, même si les réseaux sociaux provoquent sûrement en partie cet effet. Malgré tout, comme je l'ai déjà dit à de multiples reprises, on a de bons acteurs qui s'améliorent tous les jours et qui pour beaucoup cochent un nombre croissant de points dans la liste donnée. Sans compter les articles que je voie passer d'autres blogueurs qui font des retours de qualités sur ce type d'offre. Head photo by Luca Bravo on Unsplash

Ayant migré sous Neovim depuis quelques semaines, je vous fais un retour d’expérience et je vous donne les clés pour comprendre et réussir votre migration vers Neovim ! Avant tout un peu de contexte et d’histoire. Vim, l’incontournable Qui ne connaît pas Vim, ne serait-ce qu’au travers des blagues sur comment le quitter ? Et pour cause Vim - ou souvent son prédécesseur Vi, qui dépasse les 40 ans d’existence - reste souvent notre plus fidèle allié surtout sur des environnements minimaux. Développé en 1976 par Bill Joy, Vi sera une vraie révolution, notamment en introduisant l’usage de l’ensemble de l’écran, ce qui pour l’époque est une véritable révolution. Il faut dire qu’à cette époque la majorité des éditions de texte s’effectuait à l’aide d’ed, dont Vi et Vim hériteront l’aspect modal. Une décennie plus tard, un certain Bram Moolenaar, utilisateur de Vi, cherche à le porter sur Amiga. Il finira par développer en C la version 1.0 de Vim en 1988. Cette version se veut une version améliorée de Vi, d’où l’acronyme (VI iMproved). Celui-ci se voulant simple et efficace, il s’imposera petit à petit comme un éditeur de choix sur les systèmes Unix au côté d’Emacs. Pour vous donner une idée des ordinateurs de l'époque (Photo d'un Commodore64 de Tuomo Lindfors) Vim continuera d’évoluer d’années en année toujours aux mains de Bram Moolenaar, même si le rythme de cette évolution va baisser au cours des 2 dernières décennies. Ce ralentissement va être accentué par la politique de gestion des contributions, très fermée. Les propositions sont complexes à faire accepter par le créateur. De plus, il refusera régulièrement des refactoring de certaines parties, complexifiant la maintenance de Vim. NeoVim, se réinventer sans s’oublier Autant se l’avouer, les problématiques de développement de Vim ont fini par impacter la communauté d’utilisateurs. À tel point qu’en 2014 une partie de la communauté de Vim se lance dans le projet NeoVim, lançant notamment une collecte de fonds qui sera un succès. L’objectif de NeoVim est simple : créer un Vim plus moderne, extensible, avec de meilleures intégrations et bien sûr une communauté de développement plus efficiente. Dès décembre 2015, la version 0.1 de NeoVim sort en offrant le support d’une très grande partie des fonctionnalités de Vim. La communauté va rapidement s’agrandir et le nombre d’utilisateurs croître. Les versions vont, elles aussi, s’enchaîner, offrant régulièrement de nouvelles fonctionnalités. Pour vous donner une idée, nous sommes aujourd’hui à la version 0.7. Bref, un projet qui a déjà fait ses preuves et qui continue d’évoluer en gagnant de plus en plus en fonctionnalités. Pourquoi j’utilise Vim / NeoVim en 2022 ? À part pour des besoins de développements spécifiques, je suppose que la majorité d’entre vous utilise VSCode, même si je ne doute pas que les plus hipsters utilisent un IDE de la suite IntelliJ. Avant toute chose, oui, Vim / Neovim ne sont pas des IDEs, mais des éditeurs de code. Cela ne veut pas dire qu’ils ne peuvent pas remplir les mêmes besoins qu’un IDE une fois la configuration personnalisée et des plugins ajoutés. Bref, oui, à mon sens et pour mon utilisation, c’est comparable dans ce cas. Je n’ai pas toujours utilisé Vim, j’ai débuté sur Eclipse dans mes premières années où j’étais développeur Java EE. Comme beaucoup, je suppose, j’avais l’impression d’utiliser un logiciel lourd, bourré de fonctionnalités surpuissantes. Mais au final d’avoir l’utilité de trop peu. Surtout qu’à cette époque, j’étais encore étudiant, autant vous dire que quand vous passez du Java au C orienté système, votre IDE n’est plus adapté. Après mes études, je suis passé du côté obscur : je suis devenu administrateur systèmes. Autant vous dire que je passais plus de temps devant un terminal qu’autre chose, même si l’industrialisation permettait de limiter les tâches manuelles. Malheureusement, parfois on n'a pas le choix et on doit faire des modifications sans automatisation, souvent par SSH. Autant vous dire que votre IDE ne vous sera d’aucune aide. Donc j’ai fait comme tout le monde, j’utilise Vim, voir Vi. Au début, c’est compliqué : le fonctionnement modal nous paraît d’un autre temps, on se fait violence. Avec le temps, j’ai été amené à travailler en grande partie au travers d’une connexion SSH et j’ai dû commencer à me mettre à Vim et Tmux qui reste, à mon sens, un excellent combo. Un combo gagnant Après cette période, je me suis remis à travailler sur mon poste directement. J’aurais pu repartir sur un IDE, mais au final, je commençais à m’adapter à Vim. Je n’étais pas un expert, mais ça me suffisait pour mon travail. Avec le temps, j’ai commencé à me mettre à l’aise, ajouté des plugins qui ont vraiment changé ma perception de Vim. D’un éditeur de texte très basique, où la fonctionnalité la plus avancée était la coloration syntaxique, je suis passé à un éditeur sous stéroïdes, avec un vrai moteur de compression, l’intégration de Git, et de pleins d’autres outils. En clair tout ce qu'il me fallait. Mais voilà, à cette période Atom, puis VSCode vont gagner en popularité, en particulier dans le milieu DevOps. Je ne vais pas vous mentir : devant tant de personnes conquises, j’ai testé. C’est à ce moment que j’ai compris deux choses : Vim, avec ma configuration et mes plugins, était tout aussi puissant en termes de fonctionnalités pour mon usage et surtout, Vim avait changé ma manière de travailler. Quand je dis “changé ma manière de travailler”, c’est, en particulier, pour un détail qui va vous sembler con : Vim est dans un terminal. Couplé à Tmux c’est devenu, pour moi, un combo idéal. L’organisation de mes espaces de travail Gnome, de mes écrans, en fait tout mon workflow de travail a fini par s’axer là-dessus. J’ai donc décidé de retourner sur Vim, tout en continuant de faire évoluer ma configuration. Ce qui change au quotidien Faut avouer que même le logo de Neovim est un coup de jeune Quand j’ai vu passer Neovim, il me semble qu’il était en 0.2. À l’époque, je me suis dit : “ah encore un fork qui n’apporte pas grand-chose”. Du coup, je suis resté sur Vim. Surtout que la version 8, sortie récemment à l’époque, apportait des fonctionnalités sympas, notamment le support de l’asynchrone. J’ai quand même suivi de loin l’évolution de NeoVim. Un jour, est sortie une nouvelle version 0.5 de NeoVim, et celle-ci a été, je pense, un vrai argument pour commencer à considérer la migration. Cette mise à jour apportait beaucoup de fonctionnalités très intéressantes. Bien sûr un client pour le LSP (on en parle juste après) totalement intégré, un meilleur support de la configuration Lua, un nouveau système de parsing pour la coloration syntaxique notamment (Tree-sitter). Au final j’ai fini par céder et tester devant la liste des apports de celui-ci : Avoir un client pour LSP directement intégré Pouvoir faire une configuration en Lua : Vimscript a rapidement ses limites Plus ouvert : beaucoup de plugins intéressants commencent à n’être disponibles que sur NeoVim La documentation est complète Mine de rien, une communauté plus dynamique, avec souvent une approche moderne Je vous passe les corrections de bugs et petites joies de tous les jours, notamment sur les paramètres par défaut, qui sont bien moins austères que Vi ou même Vim. Pour beaucoup, cette liste doit-être floue et c’est bien normal ! Au-delà de la liste, je vous propose de faire un petit tour de ces nouveautés, ce qu’elles apportent et surtout comment elles fonctionnent. Lua Si vous êtes un utilisateur de Vim un minimum avancé vous avez déjà été confronté au fameux VimScript, le langage qui permet de configurer votre installation, mais aussi de faire des plugins. On ne va pas se mentir, c’était un point désagréable pour beaucoup de monde, moi compris. Avec Lua on a gagné en confort et en possibilités. J’ai eu un peu peur d’avoir du mal au départ n’ayant jamais utilisé de Lua, mais c’est assez clair et simple. Pour être plus à l’aise, j’ai quand même pris quelques minutes pour connaître les bases et pour cela je vous conseille ce site. Une chose est tout de même à remarquer : vous pouvez avoir pas mal de soucis si, comme moi, vous découpez trop votre code. En soit on peut le corriger, mais personnellement ça m’a pas mal fatigué pour un apport minime donc j’ai mis tout mon code dans un fichier. Cela reste lisible, d’ailleurs ma configuration Neovim est toujours sur Github. Petit exemple de code en Lua : function map(mode, shortcut, command) vim.api.nvim_set_keymap(mode, shortcut, command, { noremap = true, silent = true }) end map('', '<C-D>', ':Telescope find_files<CR>') map('', '<C-F>', ':Telescope grep_string<CR>') map('', '<C-X>', ':NvimTreeToggle<CR>') Après si vous êtes un fan de VimScript, déjà pourquoi ? Et sinon, NeoVim le supporte aussi. Packer Je parle de plugins depuis le début de l’article, mais utiliser un éditeur simple n’implique pas de tout faire à la main. J’utilise donc depuis longtemps un gestionnaire de plugins et si vous ne le faites pas, je vous conseille vivement de vous y mettre : c’est très pratique. J’utilisais Vim plug qui était tout ce que j’aime : simple et efficace. Mais avec NeoVim, tout un nouveau monde de plugins s’offre à nous. Et parmi ces plugins, l’un d’eux, très populaire, permet de gérer les plugins : il se nomme Packer et n’est pas développé par Hashicorp. Celui-ci propose, à mon sens, tout ce que je pouvais attendre d’un gestionnaire de plugins sous Neovim : Développé et configuré en Lua Gère les dépendances Beaucoup d’options d’installation et de gestion Gère les installations au travers de tâches asynchrones Supporte Git notamment au niveau des tags Le manager fonctionne bien, permet d’installer, mettre à jour et supprimer différents plugins. Au-delà de ça, il s’installe facilement, de manière automatique, avec quelques lignes de code Lua : local fn = vim.fn -- Automatically install packer local install_path = fn.stdpath "data" .. "/site/pack/packer/start/packer.nvim" if fn.empty(fn.glob(install_path)) > 0 then PACKER_BOOTSTRAP = fn.system { "git", "clone", "--depth", "1", "https://github.com/wbthomason/packer.nvim", install_path, } print "Installing packer close and reopen Neovim..." vim.cmd [[packadd packer.nvim]] end L’installation de plugins est tout aussi simple et efficace : require('packer').startup(function(use) use 'wbthomason/packer.nvim' -- Package manager # Mettez tous vos plugins use { 'nvim-telescope/telescope.nvim', tag="nvim-0.6", requires = { 'nvim-lua/plenary.nvim' } } #Plugin avec une dépendance et un tag end) Pour interagir avec Packer, rien de plus simple : il vous suffit d’utiliser la console NeoVim pour exécuter les commandes, comme par exemple PackerInstall, PackerSync. À noter: Neovim ayant un cycle de développement plus régulier, les plugins, eux aussi, sont souvent mis à jour. Si vous n’êtes pas sous la dernière version de Neovim, n’hésitez pas à tag les installations des plugins. J’ai eu quelques surprises malheureuses : des plugins, qui, une fois mis à jour, n’étaient plus compatibles avec les anciennes versions de NeoVim. Cela se fait simplement comme dans l’exemple donné plus haut. LSP Il faut l’avouer, une des faiblesses de Vim, pendant longtemps, était la qualité de la compression, plus spécialement du moteur qui permettait à l’éditeur de comprendre la structure du code afin de faire de l’autocomplétion ou encore de remarquer des problèmes syntaxiques et j’en passe. Cette situation a déjà changé, il y a quelques années, grâce notamment à Micosoft. Il y a quelques années, il décide de créer un protocole de communication entre un IDE (historiquement VSCode) et des serveurs permettant de renseigner celui-ci sur la structure et les fonctionnalités du langage. Dès 2016, ils vont travailler avec RedHat pour standardiser ce protocole qui va devenir : Language Server Protocol. Une fois le protocole publié, de nombreuses implémentations ont vu le jour, celui-ci se basant sur Json-RPC, il est possible de l’intégrer à une très grande liste d’éditeurs. Vim, d’ailleurs, pourra utiliser LSP assez rapidement. J’ai, d’ailleurs, commencé à l’utiliser il y a 2 ans, avec le plugin Conquer of Completion, qui apportait un support total de LSP. Une fois le client installé sur votre éditeur, il n’y a plus qu’à installer la partie serveur, ce qui se fait facilement, en recherchant les serveurs disponibles sur le site de LSP. Même s’il est possible de l’utiliser en Vim, Neovim va apporter un client natif parfaitement fonctionnel, qui simplifiera l’installation, et nous permettra de profiter de fonctionnalités dignes des éditeurs les plus en vogue. De Python à Terraform, rien ne lui résiste Il est à noter que, même si Neovim intègre le client, certains plugins sont nécessaires à LSP pour vous offrir une meilleure expérience de l’intégration. Je vous conseille : nvim-lsp-installer qui vous permet d’installer les serveurs de langage directement à partir de la console Neovim nvim-lspconfig qui, lui, regroupe un ensemble de configurations de base pour LSP cmp-nvim-lua qui va permettre d’afficher les petites fenêtres pour l’autocomplétion. Si vous souhaitez vérifier que votre éditeur a bien détecté le langage et utilise le bon serveur, vous pouvez utiliser la commande :LspInfo, qui vous affichera toutes les informations du client LSP. Il peut arriver que votre éditeur n’associe pas un type de fichier au serveur de langage. Dans ce cas, vous pouvez lui préciser, comme ci-dessous : require'lspconfig'.terraformls.setup{ capabilities = capabilities, filetypes = { "tf", "tfvar", "terraform" } } Astuce bonus, vous pouvez lancer un diagnostic de votre Neovim, afin d’identifier certains problèmes. Pour ça, rien de plus simple : un outil embarqué existe. Exécutez juste :checkhealth. Telescope, fzf boosté Telescope est vraiment une star sous Neovim Très souvent quand vous commencez à personnaliser votre Vim ou Neovim, vous installez un plugin vous permettant d’afficher l’arborescence dans votre éditeur. C’est sympa, ça permet d’avoir une vue sur la structure, mais pour se déplacer d’un fichier à l’autre c’est lent. Donc, très rapidement, on se tourne vers Fuzzy-finder. Et là, généralement, on revit et on a plus envie de quitter son éditeur. Fzf c’est bien, mais comme je le disais au-dessus, Neovim offre beaucoup de nouveaux plugins avec de nouvelles implémentations. Et parmi elles, un fzf survitaminé : Telescope ! Il vous permet de rechercher des fichiers, et même des patterns de texte, tout en offrant une interface avec de la prévisualisation de fichiers ! Un must have, tout simplement. Enfin la version de Vim qu’on attendait ? Il n'est pas beau mon neovim ? #PimpMyEditor Quand je me suis décidé à migrer sous Neovim, j’ai préféré faire table rase des Vimscripts, au profit de Lua. Et avec le recul, je pense que c’était la bonne approche. Néanmoins, je dois reconnaître que j’ai perdu pas mal de temps, notamment à vouloir, à tout prix, trop diviser mes fichiers de configuration, ce que Lua visiblement n’aime pas. J’ai fini par utiliser une base simple trouvée sur le Net et l’adapter à mon goût. J’ai tout de même conservé le thème qui est un bel hommage à Atom.io que j’avais essayé. Vim était clairement mon IDE / éditeur de code principal, j’ai longtemps hésité à changer, n’étant pas sûr de l’apport. Au final, la transition se fait bien : Neovim est une belle évolution, mais il ne détruit pas l’héritage de Vim. Nous retrouvons donc le système modal, la légèreté, le fonctionnement en terminal natif et tout ce qui fait le charme de Vim. Après, si vous avez détesté votre expérience sous Vim, je doute que vous tombiez sous le charme de Neovim. Au-delà de ces considérations, je trouve ça toujours aussi incroyable, qu’un éditeur si ancien ait toujours sa place, et une communauté aussi active. Il est, d’ailleurs, possible de soutenir le développement de Neovim, en aidant les développeurs sur Github ou en les finançant sur OpenCollective. Pour ce qui est de ma configuration, elle est disponible sur le dépôt Github suivant : ansible-personal-computer comme toutes mes configurations. Head photo by Vadim Sherbakov on Unsplash

Comme vous le savez, j’utilise beaucoup le cloud en particulier AWS dont je vous ai déjà parlé au travers de nombreux posts de blog, mais je travaille aussi beaucoup avec Scaleway qui à mon sens est une bonne alternative côté français. Malgré tout, j’ai pas mal de services qui me manquent quand je passe sur Scaleway. J’avais abordé brièvement ce problème dans l’article sur l’hégémonie du cloud, je guette donc leurs arrivés. Ce qui tombe bien, car l’un des services que j’attendais le plus, avec IAM est sorti : il s’agit des réseaux privés, très souvent abrégés par l’acronyme Virtual Private Network. Les plus assidus avaient remarqué qu’avant cette offre vous aviez déjà des adresses privées notamment sur les instances Scaleway, mais vous n’aviez aucun moyen de contrôler le réseau, donc il était très compliqué de l’utiliser efficacement. De plus, cette nouvelle brique va introduire plusieurs fonctionnalités annexes, que nous allons découvrir. Découverte de l’offre La promesse Techniquement, l’offre vous permet de créer des réseaux privés de niveau 2 dans la fameuse couche OSI. Ce qui nous donne la possibilité d’interconnecter des ressources, machines et services localement sans repasser sur internet ce qui est quand même plus sympa. À la découverte de la documentation, je suis assez agréablement surpris, la plupart des services Scaleway sont supportés, les instances, les load balancers et les bases de données, pour ce qui est de Kapsule leurs offres Kubernetes ce n’est malheureusement pas encore disponible. Liste des ressources supportée (source : scaleway.fr) La bonne surprise, c’est que l’ensemble des ressources est déjà exploitable par API et par extension sous Terraform. Je me permets d’insister là dessus, si vous proposez un service cloud et que celui-ci n’est pas disponible par API et par Terraform, je considère qu’il n'est pas prêt. Gérer des éléments par le biais d’une interface graphique est aujourd’hui contre-productif. Petite déception pour moi, il s’agit d’une ressource monozone, contrairement aux VPC sur AWS par exemple. Ce qui va vous demander un gros effort d’intégration afin d’interconnecter plusieurs régions, aucune solution native n’étant prévue par Scaleway pour l’instant. J’ai néanmoins vu qu’un futur service Direct connect est en beta fermée, celui-ci a pour objectif d’offrir un moyen simple de relier les VPC à d’autres réseaux privés. Dans la catégorie des bonnes nouvelles, la documentation affirme aussi qu’il est possible d’utiliser des IPv6 pour les VPC, mais je ne vais pas le tester dans le cadre de cet article. Côté technique Techniquement, l’offre se compose en réalité de 2 ressources que l’ont peut gérer : Le VPC qui est tout simplement la représentation de notre VLAN et c’est sur cette ressource que nous allons rattacher les différents objets que vous voulez mettre dans votre réseau privé, machine virtuelle, base de données managées, etc. Pour les moins fan de réseau d’entre vous ça équivaut à votre switch/hub que vous avez chez vous pour interconnecter vos machines. À noter, cette partie n’est pas facturée. Ensuite vient le second objet est la Public Gateway, qui a pour but de gérer l’adressage interne au réseau des machines (DHCP), le DNS et globalement le translation des IP (NAT) qui est nécessaire pour permettre d’avoir accès à internet à partir du réseau privé. Cette ressource est donc attachée à votre réseau privé et contrairement à lui, celle-ci est soumise à facturation. Pour continuer l’analogie précédente très simplifiée, c’est l’équivalant de la box de votre fournisseur internet chez vous. Vous avez bien sûr la possibilité de personnaliser la configuration du réseau en définissant votre CIDR et le DHCP/NAT. Donc de quoi bien s’amuser ! Petit lab découverte Sur le papier c’est une offre au top il faut l’avouer, mais entre la théorie et la pratique il y a un monde donc allons mettre tout ça à l’épreuve. Pour tester ça plutôt que créer des ressources au hasard on va provisionner une petite infrastructure Nextcloud, histoire de voir comment ça se passe. Globalement au final cela nous donne cette architecture : Schema C’est assez simple, on se repose sur les services managés pour la base de données (MySQL) et aussi pour le load balancer, pour le reste nous utiliserons 2 instances : Un bastion qui servira d’instance de rebond, même si cela n’est pas nécessaire ça va nous permettre de creuser un peu le fonctionnement du réseau Une instance Nextcloud des plus classiques qui hébergera notre serveur web, elle sera uniquement exposée en local à travers d’un VPC. La configuration Terraform de base J’utiliserai bien sûr Terraform qui est le standard pour faire de l’infra as code. Afin de simplifier le déploiement des différents niveaux, réseau, données et instance, j’ai découpé le tout dans des layers dont l’exécution est orchestrée avec Terragrunt, qui va surtout avoir pour but principal de gérer les dépendances. Comme à chaque fois sur ce blog, vous pouvez tester par vous même, le code est entièrement disponible sur ce répertoire Github. Pour la configuration du provider rien de vraiment nouveau, tout fonctionne comme décrit sur la documentation de celui-ci. terraform { required_providers { scaleway = { source = "scaleway/scaleway" version = "2.2.1-rc.1" } } } provider "scaleway" { profile = "perso" } À noter que pour l’authentification j’utilise le système de profile, pour cela trois petites étapes : Installer la cli Scaleway Créer vos tokens dans la console. Éditez le fichier de configuration $HOME/.config/scw/config.yaml en le complétant avec vos tokens comme ci-dessous: perso: #Mettez le non de profile que vous voulez myProfile: access_key: xxxxxxxxxxxxxxxxxxxx secret_key: xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx default_organization_id: xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx default_project_id: xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx default_zone: fr-par-2 default_region: fr-par api_url: https://api.scaleway.com insecure: false Les ressources de mon infrastructure ayant une grande interdépendance et aussi pour simplifier la maintenance, j’ai décidé de les séparer en 5 parties : vpc/internet gateway, base de données, instances, load balancer/PAT. Création du VPC Pour la ressource VPC en soi, c’est assez simple, on doit juste la nommer : resource "scaleway_vpc_private_network" "private" { name = "private-subnet" tags = var.default_tags } La partie internet gateway est bien plus verbeuse et demande de créer divers éléments : L’IP publique resource "scaleway_vpc_public_gateway_ip" "private" { zone = var.az tags = var.default_tags } Le DHCP Ici, je laisse l’ensemble des options par défaut et le DHCP propager les routes par défaut. Néanmoins si vous le souhaitez, vous pouvez empêcher le DHCP de les pousser, ce qui vous demandera de gérer de votre côté les problématiques d’adressage et de routage. Vous n’avez malheureusement pas la possibilité de personnaliser les routes que le DHCP ajoute, dans les cas complexes là aussi vous serez dans l’obligation de tout faire manuellement. Dans tous les cas dans l’état actuel des choses je vous déconseille de faire de l’attribution manuelle. resource "scaleway_vpc_public_gateway_dhcp" "private" { zone = var.az subnet = var.network_private } La gateway On créer l’internet gateway à lequel on attache l’IP publique et le DHCP. resource "scaleway_vpc_public_gateway" "private" { name = var.ig_name type = var.ig_type ip_id = scaleway_vpc_public_gateway_ip.private.id } resource "scaleway_vpc_gateway_network" "private" { gateway_id = scaleway_vpc_public_gateway.private.id private_network_id = data.scaleway_vpc_private_network.private.id dhcp_id = scaleway_vpc_public_gateway_dhcp.private.id } Les ressources ne sont pas très complexes, il est néanmoins à noter que j’ai séparé la création du VPC et de la gateway dans le code afin d’éviter les contraintes de dépendances qui peuvent arriver. Le point qui pose problème à mon sens est plus dans la limitation des options de personnalisation, notamment sur la table de routage comme expliqué plus tôt. Création de la base de données Notre socle réseaux étant créé on peut enfin y déployer nos ressources. Je commence par la base de données celle-ci étant l’élément demandant le plus de temps avant d’être disponible. Le code reste très basique, on y ajoute juste un bloc : private_network { ip_net = "10.1.0.200/24" #pool high pn_id = data.scaleway_vpc_private_network.this.id } Dans mon code, j’utilise des datasources afin de récupérer les informations sur les ressources créer dans les précédents layers, j’aurai aussi pu utiliser les remotes states. Création de la partie instance Pour la partie machine, il n’y a pas grand-chose à dire de plus que précédemment on ajoute à nouveau un bloc private_network à la ressource scaleway_instance_server. Il y a par contre un élément assez étonnant je dois avouer, les security groups qui permettre de filtrer le trafic réseau sur les instances ainsi que les ACL des bases de données ne s’appliquent pas sur le VPC. Si jamais vous avez une machine sur un VPC elle pourra contacter les autres. Pour ajouter de l’isolation, vous devrez soit utiliser un pare-feu système, soit séparer les ressources sur différents VPC. Load balancer & PAT On a bien toutes nos ressources, par contre pour l’instant il n’est pas possible d’y accéder en effet elles sont placées sur un VPC donc privé. Nous allons avoir besoin de nous y connecter par ssh pour l’administration et en web pour l’instance Nextcloud, pour cela on va utiliser les deux solutions principales permises par les VPC : Un load balancer Scaleway permet de créer des load balancer managés et surtout de les utiliser dans un VPC. Pour cela il suffit d’écrire un bloc private_network et de donner en backend notre machine Nextcloud : resource "scaleway_lb" "this" { ip_id = scaleway_lb_ip.lb.id name = "Nextcloud" type = "LB-S" tags = var.default_tags private_network { private_network_id = data.scaleway_vpc_private_network.private.id dhcp_config = true } } resource "scaleway_lb_backend" "this" { lb_id = scaleway_lb.this.id name = "Nextcloud" forward_protocol = "http" forward_port = "80" server_ips = ["${data.external.dhcp_compute.result.ip}"] } PAT Il nous faut ensuite une possibilité d’accès au bastion afin de se connecter en SSH, pour cela nous allons créer une règle PAT. Cette règle va permettre de diriger le trafic reçu sur un port de notre NAT Gateway, ce qui est un des rôles de l’internet gateway vers le port d’une machine, ici notre bastion. Le code est relativement trivial. resource "scaleway_vpc_public_gateway_pat_rule" "main" { gateway_id = data.scaleway_vpc_public_gateway.this.id private_ip = data.external.dhcp_bastion.result.ip private_port = 22 public_port = 22 protocol = "both" } Cette partie regroupant le load balancer et la configuration du PAT n’est pas particulièrement complexe néanmoins elle comporte une petite subtilité. En effet je vous expliquais précédemment que nous utilisions les fonctionnalités DHCP par défaut, nous ne connaissons pas les IP des machines dans Terraform. Pour résoudre ce problème le plus simple serais d’avoir une data source qui nous permettent de consulter les baux DHCP, malheureusement celle-ci n’existe pas. J’ai donc créé un script bash que j’exécute ensuite avec Terraform pour récupérer les IP des machines. Le script au travers de la cli Scaleway collecte les adressages du DHCP et les affiches sous forme de json, plus facilement exploitable dans le Terraform. all_data=`scw vpc-gw dhcp-entry list | grep ` arr=($all_data) echo "{"id": "${arr[0]}","gateway": "${arr[1]}","ip": "${arr[2]}","mac": "${arr[3]}","hostname": "${arr[4]}","type": "${arr[5]}"}" Il ne reste plus qu’à appeler le code via le provider external avec en option le nom de la machine défini précédemment. data "external" "dhcp_bastion" { program = ["bash", "./../bin/get_ip_from_hostname.sh", "bastion"] } Grâce à ce système, je peux retrouver les IP et d’autres informations de mes machines à partir de mon code Terraform. Cette solution fonctionne bien et dans un cas normal il y a peu de chance que le DHCP change les IP. Néanmoins, il ne s’agit clairement pas d’une méthode adaptée pour de la production ou autre, où il serait trop risqué d’utiliser cette approche. Voilà notre infrastructure et donc créé et disponible sur l’adresse IP du load balancer. Vous avez juste à compléter le formulaire et attendre quelques minutes avant d’avoir cette super page d’accueil : Bienvenue sur Nextcloud Côté performance Notre infrastructure fonctionne plutôt bien avec l’ensemble de nos ressources. On peut néanmoins voir à quoi s’attendre niveau réseau. En effet au-delà de la sécurité, les performances étaient aussi une des grandes promesses de ce service VPC, pour rappel avant vous étiez obligé de repasser par les endpoints internet. Pour cela j’ai effectué un test avec la commande iperf exécutée sur les deux serveurs (Nextcloud et Bastion). J’ai utilisé les instances les plus petites disponibles. Les résultats sont conformes à ce que j’espérai, je pense qu’en termes de performance vers internet par contre le type d’instance utilisé par l’internet gateway a bien plus d’impact. Connecting to host 10.1.0.250, port 434 [ 5] local 10.1.0.251 port 44984 connected to 10.1.0.250 port 434 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 194 MBytes 1.63 Gbits/sec 891 744 KBytes [ 5] 1.00-2.00 sec 208 MBytes 1.74 Gbits/sec 717 676 KBytes [ 5] 2.00-3.00 sec 175 MBytes 1.47 Gbits/sec 245 822 KBytes [ 5] 3.00-4.00 sec 196 MBytes 1.65 Gbits/sec 1006 628 KBytes [ 5] 4.00-5.00 sec 212 MBytes 1.78 Gbits/sec 105 834 KBytes [ 5] 5.00-6.00 sec 214 MBytes 1.79 Gbits/sec 123 785 KBytes [ 5] 6.00-7.00 sec 215 MBytes 1.80 Gbits/sec 325 665 KBytes [ 5] 7.00-8.00 sec 209 MBytes 1.75 Gbits/sec 517 607 KBytes [ 5] 8.00-9.00 sec 210 MBytes 1.76 Gbits/sec 92 814 KBytes [ 5] 9.00-10.00 sec 165 MBytes 1.38 Gbits/sec 298 812 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.95 GBytes 1.68 Gbits/sec 4319 sender [ 5] 0.00-10.00 sec 1.95 GBytes 1.67 Gbits/sec receiver iperf Done. Le service tant attendu ? Comme je le disais au début de l’article, c’est surement le service que j’attendais le plus chez Scaleway et il y a du bon et du moins bon. On l’a vu, le code et l’intégration sont plutôt simples et clairs, la quasi-totalité des services est compatible avec, même si à l’heure de ce test l’utilisation avec certaines ressources sont encore marquées en beta et surtout sont disponibles au travers d’API et du provider Terraform. Malheureusement, la documentation de Terraform est très légère et je vous conseille fortement de préférer celle de l’API plus à jour et surtout les options de personnalisation sont très restreintes. Travaillant avec AWS, je sais qu’il n’est pas possible d’avoir le même niveau de profondeur au vu de la maturité, mais pour moi on est sur une première version que de ce côté est trop limitée, notamment sur le multirégion. Ce n’est pas la première fois avec Scaleway, mais je ressens une sorte de frustration d’avoir le service que j’espérais, mais pas complet dans une V1 qui ne demande qu’à être améliorée. Vient ensuite un point que je n’ai pas abordé dans l’article, l’utilisation avec la console. Scaleway a dès le départ souhaité faire une interface, simple, efficace, ce qui est une bonne chose, un choix d’ailleurs fait aussi par Nuage. Dans le cas des VPC par contre, la console web montre souvent ces limites, notamment sur le paramétrage et l’affichage des informations détaillées de la machine sur le réseau, par exemple si vous cherchez l’IP local d’une instance vous ne la trouverez pas dans cette même partie, mais dans internet gateway puis DHCP puis voir l’adressage. En soit, ce n’est pas grave on utilise en majorité du code ou l’API de nos jours, mais malheureusement traduit peut-être un manque de communication et de vision entre les équipes pour intégrer de manière homogène les solutions. Il est part contre clair qu’avec les VPC on gagne en performance et l'on réduit le risque en termes de sécurité, même si là encore je suis un peu perdu sur le choix de ne pas permettre le filtrage par les security groups dans un VPC. Scaleway avance dans la bonne direction, il me semble d’ailleurs avoir vu que l’IAM arrive bientôt en faisant un acteur solide du cloud. De plus en plus régulièrement, je me dis que je peux faire certains projets sur leurs clouds, même si dans beaucoup de cas les solutions sont encore trop limitées pour ne pas demander de gros sacrifices en termes de fonctionnalités. Comme toujours, je vous donne mon ressenti la fonctionnalité. Je vous invite à le tester par vous-même et je vous fournis l’ensemble du code sur Github : lien. Head photo by Luca Bravo on Unsplash

Comme beaucoup d’entre vous, la souveraineté est un domaine qui me tient à coeur. J’avais déjà notamment abordé l’hégémonie du cloud américain sur ce blog dans l’article revenant sur les causes de cette hégémonie. Le moins que l’on puisse dire c’est que ces derniers mois ont été chargés dans le domaine de la souveraineté numérique. Ce qui m'a poussé à échanger avec vous au travers de cet article pour revenir sur ce qu’est la souveraineté numérique et surtout essayer de comprendre les enjeux actuels. Mais avant de parler de ça, une question me parait essentielle : pourquoi la souveraineté numérique est-elle si importante ? La souveraineté numérique pour quoi faire ? On oublie souvent de se poser cette question qui peut sembler simple, mais vitale avant d’aborder plus en profondeur sur la thématique. Globalement j’aurai tendance à regrouper les problématiques auxquelles répond la souveraineté en deux catégories, la géopolitique et l’économie. Géopolitique Quand on parle de géopolitique, ça peut très rapidement devenir flou, donc je vais détailler un peu ce que j'entends par ce terme. Tout d’abord, le point le plus mis en avant est surement l’espionnage notamment depuis l’affaire Snowden. Honnêtement, je ne pense pas que cela soit la principale raison, une grande partie de l’espionnage concerne des réseaux et services visant le grand public (réseaux sociaux et chat par exemple) et une grosse partie de ce risque en entreprise est déjoué par l’utilisation du chiffrement, même si évidemment la réalité est plus complexe. Le second point que je note est la dépendance directe envers d’autres nations. On l’a bien vu avec notamment la crise du COVID et la pénurie de semi-conducteurs. Une pénurie impacte très rapidement le bon fonctionnement d’un pays et de ces entreprises comme par exemple l’industrie automobile. Cela nous laisse assez facilement imaginer l’impact possible d’un blocus, physique ou numérique des pays dont nous dépendons. Bien sûr actuellement la probabilité reste faible, mais cela reste un moyen de pression qui géopolitiquement pèse dans les différentes négociations. Économie Le domaine le plus impactant est surement l’économie. Pour le coup il s’agit d’un thème moins abordé, même si la keynote de Quentin Adam a remis ce sujet à nouveau sur la table. Pour se convaincre de l’importance du numérique dans l’économie il suffit de regarder les entreprises avec la plus grosse capitalisation : Classement capitalisation - source boursorama.com On voit bien que sur les 7 plus grosses entreprises seulement une n’est pas une entreprise opérant dans le domaine technologique, c’est dire l’importance du numérique dans l’économie des pays. Ce domaine continue de grandir apportant des emplois, mais également au travers des taxes, une bonne santé économique au pays. De plus il ne faut pas négliger l’impact que peuvent avoir des filières locales sur les autres entreprises favorisant la création d’un vrai tissue entrepreneuriat. On pourrait débattre et ajouter d’autres points, mais je pense qu’il s’agit là des principaux éléments poussant à l’adoption de plan visant la souveraineté numérique notamment de la part des gouvernements. Cet article a plus vocation à offrir une vision globale qu’un ensemble de points détaillés. Le gouvernement a-t-il perdu la tête ? Ces derniers mois, le gouvernement et plusieurs grandes entreprises françaises ont annoncé un ensemble de décisions qui semblent un non-sens au niveau de la souveraineté. Ces décisions ont d’ailleurs provoqué de vives réactions sur les réseaux sociaux. Parmi celles-ci, la principale a été de pousser les entreprises françaises à offrir des solutions cloud hébergées chez elles, mais en utilisant des briques de logiciel américaines, par exemple Bleu ou encore Thales. Ces annonces prêtent à se poser plusieurs questions quant à leurs buts et leurs efficacités, sachant qu’elles seront vraisemblablement certifiées par les organismes officiels, au travers du label SecNumCloud … une certaine vision de la souveraineté À l’heure où c’est le logiciel qui créer la valeur notamment dans les offres cloud, reposer entièrement sur des solutions américaines ne répond clairement pas aux enjeux économiques. Il faut aller chercher l’enjeu autre part, et je pense que vous allez mieux comprendre où je veux en venir en parlant du Cloud Act. Le Cloud Act est une loi extraterritoriale américaine qui pour simplifier donne un cadre légal pour l’extraction de données par les autorités à tout client des services clouds américains. C’est précisément cela que le gouvernement actuel essaye d’attaquer, en faisant héberger les stacks par des entreprises françaises, le Cloud Act ne pourra plus rentrer en action légalement. L’objectif est donc plutôt ciblé, mais on voie rapidement ces limites. Beaucoup des problématiques de souverainetés ne sont pas résolues par cette décision, notamment d’un point de vue économique. On peut aussi douter que la barrière légale bloque les autorités américaines dans des cas sensibles, les opérations relevées par Snowden par exemple montraient bien que l’action n’était pas souvent encadrée par un cadre juridique. Cette solution pourrait donc avoir une logique comme solution de transition avant une solution à long terme. Malheureusement, les différentes décisions du gouvernement semblent vouloir pérenniser cette stratégie dans lequel il ne prend pas de risque, ni changer grand-chose concrètement, surement peur d’un nouveau Cloudwatt. Il va néanmoins être intéressant de voir si les élections présidentielles à venir vont voir ce sujet mis en avant et si des propositions intéressantes vont être faites. Même si le sujet risque de n’être que peu abordé directement, celui-ci n’étant pas un des sujets favoris lors des débats de la présidentielle. La situation est-elle meilleure au niveau européen ? Gaia-x, l’arbre qui tarde à bourgeonner Au-delà des actions stratégiques les plus directes du gouvernement, d’autres initiatives à plus large échelle ont vu le jour. La plus importante des initiatives, que vous connaissez surement s’appelle Gaia-X. Au départ elle a réuni des entreprises allemandes et françaises dans le but de créer des normes, spécifications, connecteurs ouverts et aussi des labels visant à faciliter l’interopérabilité et l’adoption du cloud en Europe. Des intentions très louables en somme. Très rapidement il s’est posé question d’ouvrir l’initiative à des acteurs extraeuropéens. Personnellement, je pense que l’idée n’était pas forcément problématique, tant qu’on ne leur donnait pas de contrôle sur Gaia-X. Malheureusement très rapidement une très grande quantité d’acteurs externes sont arrivés et surtout ont accédé aux commissions techniques afin d’imposer en bonne partie de leurs points de vues, donc leurs intérêts. Cet échec, car je pense qu’on peut appeler ça comme cela a notamment entrainé le départ de Scaleway, membre fondateur suite à ces problèmes. Beaucoup de ces acteurs européens ont été eux aussi assez déçus de la tournure de Gaia-x ce qui entraina l’émergence d’une alliance : Euclidia Euclidia va-t-il faire de l'ombre à Gaia-x Euclidia, le papillon tente son envol Une trentaine d’acteurs du cloud européen parmi lesquels vous reconnaitrez surement des noms comme Scaleway, Clever Cloud, Bluemind ou encore Nextcloud, se sont regroupés au tour d’une alliance appelé Euclidia. La définition de leurs buts globale pourrait être résumée elle aussi à favoriser l’adoption de solution cloud souveraine au niveau européen dans les entreprises. Pour y arriver, elle mise notamment sur l’amélioration de la collaboration entre les différentes entreprises afin de créer un écosystème et sur la promotion des solutions européennes. Au final, même si le but est assez proche de celui de Gaia-x, les axes utilisés sont assez différents. Euclidia va notamment faire pas mal de lobbying (ce mot n’est pas forcément péjoratif) auprès des politiques afin de rappeler l’importance des solutions de cloud européenne. Pour autant, les deux organisations ne sont pas en conflit et fonctionnent de manière très différente. Même si Gaia-x s’égare sur ces objectifs premiers, j’espère que les deux pourront apporter leurs pierres à la construction d’acteurs souverains solides. Un combat perdu ? On peut se poser la question à en voir tous les initiatives et efforts mis en place pour des résultats souvent en dessous de l’attente de beaucoup d’acteurs et de personnes intéressées par la question. Néanmoins, je ne pense pas que la souveraineté soit binaire aujourd’hui, comme nous l’avons notamment vu dans les choix du gouvernement. D’ailleurs, si l’on regarde l’exemple de l’affaire d’espionnage matériel par la Chine on constate que même les gros acteurs américains ne sont pas à l’abri. Cela n’empêche pas de tendre vers la souveraineté absolue, afin de répondre en grande partie aux points soulevés et pour le coup c’est un combat à voir sur le long terme, voir très long pour certains points. Plusieurs choses me font penser que cette souveraineté numérique qui tend vers l’absolue est possible en France. Nous avons plusieurs avantages très importants, que nous avons parfois tendance à oublier. Les infrastructures en France sont de bonnes qualités, avec en plus une électricité décarbonée grâce au nucléaire, mais aussi avec une infrastructure réseaux qui reste très bonne en comparaison de beaucoup de pays. Au-delà des infrastructures, nous avons plutôt un bon vivier technologique, des solutions comme Docker ont d’ailleurs débuté en France avant de déménager aux États-Unis. Notre système éducatif public aussi, bien qu’en perte de vitesse, pourrait être le moteur de cette transition. Là on peut se demander pourquoi avec tant de qualité, nous n’arrivons pas à nous imposer sur le marché. Car le cloud ce n'est pas un marché magique, les acteurs américains sont déjà très bien installés et ont de l’avance, qu’on le veuille ou non. Il faut donc du temps et des financements aux acteurs français comme Scaleway, CleverCloud ou encore OVHCloud pour arriver à gagner plus de maturité. Sur ce point du manque d’investissement et de maturité, l’État n’a pas réussi à créer une vraie dynamique. Je ne pense pas qu’il existe de solution miracle, mais rien que de privilégier des solutions françaises quitte à faire des concessions ou investir dans ces sociétés pour leur permettre de se développer plus vite changerait la donne. Il est normal pour l’état de privilégier des solutions qui auront un apport plus important pour le pays à moyen terme. D’ailleurs on le fait dans plusieurs domaines sans que cela choque. Il est tout de fois à noter que la situation est tout autre pour les entreprises privées qui doivent garder leurs libertés. Et les solutions existantes Comme je le disais, il existe des solutions souveraines qui même si elles ne sont pas au niveau des plus gros acteurs peuvent convenir pour une grosse partie des besoins. Pour le coup, je pense que dans une bonne année, si les choses continuent à leurs rythmes, des acteurs comme Scaleway vont devenir très intéressants. Malheureusement, une ombre vient complexifier tout ça, les normes. Dans les entreprises, on aime bien définir des normes, exiger des niveaux de certification en un sens ça permet de s’assurer d’un certain niveau de maturité. C’est d’ailleurs le cas avec le domaine de la souveraineté, on a créé une nouvelle norme : SecNumCloud, qui comme des certifications ISO 27001 va encore complexifier la vie des petits acteurs. Car autant vous dire que les très grosses entreprises n'ont aucun mal à passer la quasi-totalité des normes, mais souvent encore plus la thématique de la sécurité est le parent pauvre des acteurs plus petit (pas de log auditable, pas d’IAM complet, exposition publique par défaut et j’en passe). Ce qui va disqualifier beaucoup de ces acteurs dans bon nombre d’appels d’offres, et encore je ne parle même pas des directions des achats qui vont être encore plus perdus. On se retrouve donc à réduire le nombre d’appels d’offres auxquels nos acteurs peuvent répondre. Bien sûr, je ne dis pas par là que les aspects de sécurité doivent être négligés, juste que ce type de solution est trop souvent contre-productive. En bref Un article assez dense, qui passe en revue les points que je juge les plus importants sur cette question. On peut se demander qu’en retenir, si je devais retenir trois points je donnerais les suivants : La souveraineté n’est pas binaire un acteur cloud comme AWS ou OVHCloud n’est pas lui-même forcément souverain au niveau matériel. La souveraineté est un réel enjeu national, sur plusieurs points aussi bien géopolitiques qu'économique et dépasse donc l’aspect technique. Tout n’est pas perdu et nous pouvons réussir dans ce domaine, qui est et sera un des axes économiques majeurs. Il ne s’agit bien sûr que de mon avis, vous être libres de ne pas être d’accord et je ne pense d’ailleurs pas avoir la solution parfaite.

Je pense qu’on sera tous d’accord pour dire que la complexité des stacks et des technologies nous force aujourd’hui à jongler de plus en plus entre différents outils et contextes projet. C’est pour cela que je vous propose de voir comment et avec quels logiciels j’organise mon quotidien afin de vous faire découvrir comment on peut gagner en efficacité. Autant dire qu’on va aborder toutes sortes d’outils et quelques astuces, mais avant de parler de tout ça je vais un peu vous décrire mon contexte afin de bien comprendre la manière dont je voie la problématique. Comme pas mal de personnes le savent déjà, je suis consultant Cloud & DevOps un métier qui accentue encore plus les multiples changements de contexte et de client. L’année dernière, je me suis retrouvé à jongler entre plusieurs clients sur des missions courtes, la société où je travaille et certains projets perso. Au-delà de l’organisation humaine, j’ai eu pas mal de soucis techniques, me connecter déconnecter en boucle de compte Google, changer en permanence mes configurations Kubernetes, SSH, bref une horreur où j’ai perdu trop de temps à mon goût. J’ai donc travaillé sur comment répondre à ces problématiques et comment être plus efficace et je vous partage aujourd’hui où j’en suis arrivé ! Toujours suivre les bons conseils de Bear Grylls À noter pour le reste de l’article que je travaille exclusivement sous GNU/Linux au niveau de ma station de travail (Debian), mais la grande majorité de la suite de l’article sera adaptable sur d’autres systèmes. Pour la configuration automatique de mon poste de travail avec Ansible, j’avais écrit cet article et bien évidemment le code est toujours disponible par ici, pour le partage des fichiers j’utilise Nextcloud. Mes outils du quotidien Comme tout bon artisan, nous avons nos outils et de bons outils, ça change le métier, en bien. On va donc aborder les différents logiciels que j’utilise et j’apprécie pour me faire gagner en temps ou encore en efficacité. Je ne ferai pas un tutoriel pour chacun, mais dans la mesure du possible je vous conseillerai un article francophone pour aller plus loin. Firefox et ses addons Aujourd’hui le navigateur est surement un des logiciels qu’on utilise le plus, personnellement j’ai choisi Firefox, car je pense que c’est eux qui ont la vision du web qui me tente le plus. Passons en revue les addons dont je n'arriverais pas à me passer : uBlock Origin, que vous connaissez surement pour bloquer les pubs autant pour la pollution visuelle que pour gagner en légèreté sur les pages web. Disconnect, pour réduire le traking et là encore rendre le web un peu plus léger. I don’t care about cookies, pour se débarrasser de la demande de stockage des cookies depuis la directive EU. NoScript, un peu violent, je conçois qu’il ne va pas plaire à tous. Cet addons bloque toutes les exécutions JavaScript, Java et Flash, hors ceux que vous autorisez. Un peu lourd au départ, je m’y suis habitué et je le trouve très efficace notamment grâce à un moteur de règles d’autorisation. Firefox container, le dernier, mais surement le plus important pour moi il permet de conteneuriser les onglets dans des contextes isolés. Grâce à ça je peux notamment être connecté à plusieurs comptes Google sur le même navigateur sans risquer de conflit. Je vous invite fortement à le tester, d’ailleurs un article très sympa de la communauté Firefox est disponible par ici. Système Les outils que j’utilise le plus en addition de ma Debian Zsh avec p10k, la combinaison des deux me permet d’avoir un Shell efficace et très interactif notamment avec beaucoup d’information contextuelle (version logiciel, contexte Kubernetes etc.). On pourrait juste reprocher à cette solution d’être encore un peu lourde à mon sens. Toutes les informations en un coup d'œil Tmux on ne le présente plus le multiplexeur de terminal dont je me sers tous les jours. Au départ j’utilisais Terminator, mais celui-ci contrairement à Tmux ne permet pas d’être exécuté sur un serveur distant au travers d’SSH. Si ça vous intéresse, un article est disponible ici pour le découvrir. Diviser pour mieux régner Direnv un petit binaire très sympathique qui permet d’exécuter automatiquement des actions au passage dans répertoire, par exemple charger les bonnes versions logiciels. Un billet de blog plus complet par ici vous permet d’en savoir plus sur l’outil. Makefile une base sur tout système Unix, il est toujours utile de le garder sous la main pour automatiser des actions quand la CI/CD n’est pas disponible où possible. Un article très sympathique que je vous conseille pour découvrir son utilisation côté Ops : Makefile pour les Ops. Pass utiliser un gestionnaire de mot de passe est surement la décision à prendre qui vous fera gagner le plus de temps ! Et dans ce domaine mon préféré c’est Pass, j’en avais d’ailleurs écrit un article d’introduction toujours disponible à ce lien. Git et collaboration pre-commit vous aussi vous avez tendance à oubliez de passer le linter avant de commit ou encore d'avoir peur d'oublier un secret dans le commit ? N'ayez plus peur avec pre-commit ! Ce petit logiciel va se déclencher avant de valider le commit à l'aide d'un hook git pour effectuer des actions (linter, check de sécurité, etc.). Bref, le tester c'est l'adopter. Si vous voulez en savoir plus, foncez sur ce lien. Toujours mieux quand tous les tests sont au vert asdf a l'heure ou les outils se multiplie et que leurs distributions n'est plus toujours centralisé sur les gestionnaires de packet, gérer les versions notamment en fonction des projets est proche de l'enfer, on ne va pas se mentir. C'est là qu'arrive asdf ! Un petit outil qui va vous permettre de gérer les différentes versions de vos logiciels favoris. Un très bon article est disponible par ici pour le découvrir plus en détail. Vim comme environnement de développement Rien qu'à son évocation, il peut évoquer la joie ou le bonheur. Après plusieurs années, je ne l'ai pas encore quitté et cela reste un de mes outils quotidiens j'apprécie notamment le fait que celui-ci s'exécute directement dans un terminal et soit très largement extensible. J'utilise Vim comme environnement de développement (Python, Terraform, yaml, etc.), pour cela j'y ai adjoint plusieurs addons parmi lesquels les plus intéressants sont : Nerdtree / nerdtree-git-plugin pas essentiel, mais ils permettent d'afficher l'arborescence de fichier avec le statut git de chaque fichier. Qui a dit que Vim était austère ? Gitgutter qui en complément du plugin précédent va permettre d'afficher dans la marge un statut git de la ligne. Très confortable au quotidien. Vim-matchup les utilisateurs de Vim sont habitués à utiliser la touche % qui permet notamment à partir d'une ouverture de parenthèse de se téléporter à la dernière. Ce plugin va étendre le fonctionnement de cette touche à d'autres langages et surtout à des mots spécifiques. Coc qui est permets de clairement passer d'un éditeur de texte à un IDE. Cette extension permet de faire de la complétion automatique et d'afficher des informations contextuelles. Pour cela l'extension communique avec un backend NodeJS qui est celui de VSCode, vous pouvez donc profiter de tous les addons de celui-ci. Vim sous stéroïdes Vim-terraform pour les utilisateurs de Terraform il s'agit d'un must have qui va permettre d'exécuter des commandes Terraform à partir de Vim (:terraform), mais aussi de gérer la coloration HCL. Je n'ai pas encore migré sous NeoVim, mais il y a de grandes chances que je passe sous NeoVim à terme notamment pour des questions de performance. Terraform L'outil d'Infra As code par excellence, sa maturité et le nombre de providers disponible en font un outil de choix quand il s'agit de passer de l'interface graphique au code. Voici 4 petits logiciels qui viendront compléter à la perfection le fonctionnement de Terraform. tfenv surement l'extension à avoir, beaucoup d'entre vous la connaisse surement cette extension vous permet automatiquement ou manuellement de changer votre version de Terraform en une commande, un must have. tfsec on a toutes et tous peur qu'un jour malgré les codes review un security group un peu trop ouvert soit déployé en production. Pour cela je vous conseille tfsec un petit binaire qui va parser votre code Terraform à la recherche de configuration un peu faiblarde sur l'aspect sécurité. Préserez-vous des règles trop larges tflint un peu méta, car il ne s'agit “que” d'un framwork. Néanmoins celui-ci va vous permettre d'ajouter des fonctionnalités comme la recherche d'erreur, les dépréciations de syntaxe ou encore vérifier les conventions de nommage et j'en passe. terraform-docs quand vous écrivez notamment des Modules Terraform, vous savez qu'il est important de documenter les inputs et les output, mais vous savez aussi qu'ils sont rarement mis à jour. Grâce à terraform-docs vous allez automatiquement générer cette documentation ! Conteneurs et virtualisation Malgré les environnements cloud et les chaînes CI/CD il est parfois nécessaire et plus simple de manipuler VM et conteneur sur son poste, une petite occasion de parler de ces outils toujours bons à garder sous la main. kvm / Virt-Manager depuis 2 ans j'ai arrêté d'utiliser VirtualBox au profit de KVM, simple et efficace il permet de créer et gérer des VMs. Quand une interface graphique se fait manquer, Virt-Manager remplit parfaitement son office pour des manipulations basiques. Découvrez comment créer une machine en quelques cliques sur ce tutoriel. Vagrant les fameux outils de la société HashiCorp on pourrait faire un article rien que sur eux. Vagrant vous permet globalement de faire de faire de l'infra as code pour vos labs locaux. Autant vous dire que combiné à KVM cité précédemment, vous pouvez gérer efficacement vos environnements de tests sur votre poste. Là encore, un petit article découvert est disponible par ici. Podman une alternative à Docker, Podman propose une cli complète totalement compatible avec la syntaxe Docker qui a l'avantage notamment de pouvoir manipuler des Pods ! Pour en savoir plus, j'avais écrit un article par ici. Buildah contrairement à Docker Podman ne permet pas de construire des images, mais pas de panique, un outil très efficace existe pour cela il s'agit de Buildah. Pour découvrir comment l'utiliser, je vous conseille cet article. Kubernetes Ah Kubernetes, un des grands sujets qui divise le monde de l'informatique tout comme Vim vs Emacs ou encore tab vs espace. Qu'on l'aime ou non, forcé de constater qu'aujourd'hui il est de plus en plus difficile de trouver des infrastructures sans Kubernetes. kubectx & kubens Il peut être parfois lourd de switcher entre les différents clusters ou les différents namespace Kubernetes. Pour faciliter la vie, voici deux petits scripts qui vont permettre de faire ça rapidement et efficacement. k9s les commandes kubectl c'est cool, mais quand on doit chercher des informations faire des tests, on enchaîne rapidement les longues commandes en perdant beaucoup de temps. Grâce à K9s cette époque est révolue ! Ce binaire vous permet d'interagir de manière interactive avec votre cluster, avec un grand nombre de raccourcie cet outil est là encore un indispensable quand vous manipulez du Kubernetes. De plus un article très cool sur le sujet est disponible par ici. Ne vous perdez plus dans votre cluster Comment j'ai automatisé le changement de contexte client C'est bien beau depuis tout à l'heure je vous parle de pleins d'outils, super sympas, mais ça ne règle pas totalement ma problématique de base simplifier mon quotidien en particulier les changements de contexte. Alors commençons par la base, dans mon home, j'ai créé un dossier par contexte, cela peut-être par exemple : perso, client1, client2. Dans chacune de ces arborescences, je vais retrouver à la base 2 fichiers : .direnv comme j'en parlais dans les outils au-dessus, celui-ci va permettre d'exécuter des commandes et d'exporter des variables à chaque passage. Dans notre cas, il peut servir par exemple à sélectionner le bon cluster Kubernetes, exporter le bon profil AWS, etc. Bref paramétrer beaucoup de choses pour nous faire gagner du temps ! .gitconfig : certains ce demanderons surement, pourquoi il n'est pas dans le home. En faite il est dans le home et dans mes dossiers de contextes. Depuis quelque temps Gitconfig supporte les includes ! Donc pour chacun de mes contextes ma configuration Git va être surchargée par des valeurs spécifiques pour s'adapter à mon compte par exemple ou changer la clé PGP. [includeIf "gitdir:~/contexte1/"] path = ~/contexte1/.gitconfig [includeIf "gitdir:~/contexte2/"] path = ~/contexte2/.gitconfig Bien sûr je fais cela au premier niveau de l'arborescence, mais cela ne m'empêche pas de l'exécuter plus loin dans celle-ci afin de m'adapter à un sous projet. Pour ce qui est des clés (SSH et PGP), je créer systématiquement une clé par contexte, tout simplement pour pouvoir identifier un scope et les révoquer sans impacte sur les autres contextes je vous conseille grandement cette hygiène de sécurité. En parlant de SSH, n'hésitez pas à configurer des hosts spécifiques dans votre fichier de configuration ~/.ssh/config ça vous fera gagner un temps précieux et vous permettra aussi par exemple d'avoir plusieurs comptes Github avec des clés SSH différentes sans soucis. La plupart des logiciels vous proposent ce type de fichier utilisez les ! Cette organisation est simple et efficace, je pense que c'est son avantage, rester simple. Trop la complexifier multiplierait surement les problèmes et le temps de debug, je suis donc plutôt satisfait de cet équilibre. Retour sur 1 an avec ce système Cela fait aujourd'hui environ un an que je marche avec ce système. Bien qu'encore à affiner sur certains points, je pense que l'ensemble de ces outils et l'organisation de mon code m'a permis de gagner en efficacité. Pour beaucoup, la liste d'outil peut paraitre immense, alors que j'en ai zappé quelques-uns moins intéressant où trop situationnel. Cependant, une grande partie du nombre est aussi dû à la philosophie KISS, chacun de ces outils à un rôle précis et le fait bien. J'apprécie réellement cela, ma configuration est très flexible et en grande partie automatisée. Je vois néanmoins deux limites. La première concerne automatisation, il est simple de ne plus savoir ce qui est fait derrière la boite noire. Je vous recommande donc de faire attention à ça et de vous assurer qu'il n'y a pas de doute là-dessus. La seconde est le debug, a ajouté des surcharges de layer il est parfois pas très simple de s'y retrouver dans ceux-ci quand une valeur est erronée. Ce problème est néanmoins limité, car avec une bonne structuration on ne se perd pas trop. Tous mes fichiers de configuration sont toujours disponibles par ici : Github. Head photo by Philip Swinburn on Unsplash

Alors que le thème de la souveraineté cloud est très abordé ces derniers temps, un nouveau cloud souverain apparait sur le marché assez bruyammant. Une solution à la pointe ? Une n-ième solution cloud ? On va essayer de répondre à tout ça dans l’article. Disclamer, ce n’est pas un article sponsorisé j’ai uniquement utilisé des crédits offerts (200€). Un nouvel acteur venu de nul part ? Monter une offre cloud ce n’est clairement pas le business le plus simple à monter et au-delà de la simplicité le billet d’entrée est assez élevé. Derrière cette offre il y a l’entreprise Oxeva, ce nom vous dit peut-être rien, mais si je vous dis qu’il s’agit de la filiale hébergement informatique à haute disponibilité du groupe La Poste ça parait de suite plus claire. Ils ne partent pas de nul part. Pour la stack logicielle, ils ne sont pas repartis de zéro et on choisit une base OpenStack avec un front spécifique. Un choix qui peut très bien marcher celui-ci a notamment été fait par OVH pour la partie cloud public. Je pense que c’était surement la solution la plus rentable, au moins à court / moyen terme. Néanmoins comme vu sur Twitter le but est de ne pas pousser les APIs OpenStack, mais bien d’exposer des APIs spécifiques plus simples selon Nuage. Pour ce qui est de la proposition de valeur, c’est la simplicité et la clarté. Du coup pour voir si cela est vrai testons ! Techniquement ça donne quoi ? La création de comptes est claire et se fait rapidement en cinq étapes, avec les classiques informations de comptes et de facturation, en soit rien à dire. Il est quand même agréable d’avoir un thème clair / sombre, même si cela reste du détail. Ensuite on arrive sur l’interface principale qui nous propose de créer et gérer différents projets et utilisateur. C’est plutôt clair et permets de créer une première couche d’isolation entre différents contextes. Par contre, n’attendez pas une gestion fine des droits utilisateurs dans chaque projet, il s’agit d’un droit binaire. Parceque c'est NOTRE PROJET Une fois dans notre projet nous pouvons créer une instance, le tout avec là encore une interface assez claire et simple pour ne pas dire limitée, il n’est par exemple pas possible de modifier la taille du disque. Vous pouvez donner l’accès sur le port SSH à partir de tout internet en paramétrant le security group en un click. Vous pouvez néanmoins choisir de ne pas assigner d’IP public ce qui est une très bonne chose. Ne vous attendez pas à de l'ultra-personalisation Même si le choix de la simplicité est assez clair le fait de perdre des options natives dans OpenStack et très répandues dans le cloud comme cloud-init est assez regrettable. De plus, il n’est pour l’instant pas possible de choisir une zone ou région, une seul étant disponible au moment où je vous écris ces lignes. En parlant de personnalisation, j’avoue que la base OpenStack me faisait espérer certaines fonctionnalités comme par exemple la configuration des security groups. Malheureusement dans la réalité vous n’avez que 3 options sur vos security groups : HTTPS / HTTP ouverts SSH ouvert Tout ouvert aka Yolo Ce qui veut aussi dire que vous ne pouvez pas faire de règles de security groups internes notamment par référence, ce qui est dommage. Je vous conseille tout de même d’exposer qu’une machine qui servira de bastion et ensuite de n’exposer que le nécessaire et d’utiliser le réseau local pour le reste et l’administration. Vous n’aurez pas non plus de contrôle sur ce réseau local, notamment sur son découpage. Vous retrouvez ensuite l’interface de gestion des instances du projet avec les différentes instances démarrées. Là encore c’est assez clair, rien de spécial à dire là-dessus. Bon j'avais pas masse imagination pour les noms Ensuite, on s’y connecte facilement en utilisant le nom de la distribution et l’adresse IP, en somme tout ce qu’il y a de plus classique. Dans mes tests j’ai par contre eu un comportement étrange, ma clé n'était pas propagée par défaut, j’ai dû redémarrer mon instance pour que celle-ci fonctionne (ce problème est en cours de résolution par leurs équipes). Pour ce qui est des performances, je n’ai pas fait de benchmark complet cela n’etant pas ma spécialité, mais pour vos donner quelques informations et quelques points intéressants : Nous sommes sous plateforme AMD EPYC-Rome : root@poc-1:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 23 model : 49 model name : AMD EPYC-Rome Processor stepping : 0 microcode : 0x1000065 cpu MHz : 2000.000 cache size : 512 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr wbnoinvd arat umip rdpid arch_capabilities bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips : 4000.00 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: Pour ce qui est du stockage, c’est un volume de 100Go non modifiable. Selon la documentation basé sur du NVME réseau à l’aide de CEPH). De ce côté je trouve les performances plutôt bonnes. [root@centos ~]# dd if=/dev/zero of=/home/test bs=2G count=5 oflag=dsync 0+5 records in 0+5 records out 10737397760 bytes (11 GB, 10 GiB) copied, 23.5435 s, 456 MB/s Côté réseau rien de foufou : root@poc-1:~# speedtest Retrieving speedtest.net configuration... Testing from OXEVA SAS (185.189.158.205)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by CCleaner (Paris) [1.88 km]: 2.723 ms Testing download speed................................................................................ Download: 751.46 Mbit/s Testing upload speed...................................................................................................... Upload: 48.39 Mbit/s Update au 21 novembre : après Nuage m’a contacté pour me dire que le soucis réseau est résolu, j’ai effectivement un débit bien meilleur aujourd’hui : Server: Nextmap - LeKloud - Paris (id = 33869) ISP: OXEVA SAS Latency: 0.45 ms (0.02 ms jitter) Download: 3735.52 Mbps (data used: 2.0 GB ) Upload: 7945.47 Mbps (data used: 7.0 GB ) Packet Loss: Not available. En bref côté performances rien de trancandant, mais suffisant pour la plus part des utilisateurs classiques. Pour plus d’information Inpact Hardware à fait un article complet. Je n'ai ensuite pas rencontré de réel problème sur cette partie avec une stack Wordpress (Apache2 + MySQL), vous pouvez installer ce que vous souhaitez sur la machine sans soucis. Les plus habitués à ce blog, où simplement les personnes me connaissant se pose une question pourquoi ne pas avoir fait tout ça sous Terraform où API ? Tout simplement, car celle-ci n’est pas encore officiellement disponible, une API existe déjà pour le backend : api.nua.ge, mais elle n’est pas encore publique. Comme je le disais au départ, même si la solution repose sur OpenStack qui propose une API et un provider Terraform, ils souhaitent offrir une API plus simple dédiée à Nuage. A voir ce que cela va donner par la suite, car proposer un provider Terraform est évidemment une bonne chose, mais proposer une provider mis à jour régulièrement et bien documenté c’est encore autre chose. Comme tout fournisseur qui se respecte, Nuage vous propose aussi une documentation sur un site dédié : doc.nua.ge. Pour l’instant celle-ci est assez basique, mais avec l’API et potentiellement d’autre service elle pourra s’enrichir rapidement. Parlons ensuite d’un aspect essentiel, même si le nombre de parrainages et de codes promo font oublier cet aspect, regardons ce que donne leurs offres niveau tarif. Pour cela je vais comparer une instance type avec 4 CPUs et 16 Go de RAM, où en tout cas m’en rapprocher le plus possible sur les différents cloud. Fournisseur Ikoula Scaleway OVHCloud Nua.ge Offre Large (4vCPUs, 8Go RAM, 10Go Disque) GP1-XS (4vCPUs, 16Go RAM, 150Go Disque) b2-15 (4vCPUs, 15Go RAM, 100Go Disque) 4vCPUs, 16Go RAM, 150Go Disque Tarif (à l’heure) 0,0548€ 0,084 € 0,1169€ 0,12€ Même si les offres ne sont pas tout à fait comparables, pour ça que je donne les caractéristiques, on remarque que Nuage reste assez cher comparée à d’autres acteurs français. Je note néanmoins que cela reste la seule offre à nous laisser choisir chacunes des caractéristiques indépendamment (à l’exception du disque). Pour continuer sur l’aspect financier de Nuage. L’espace facturation est quant à lui assez simple et efficace avec un graphique de consommation lisible et une projection de coûts bienvenue. Vous n'avez pas à craindre qu'un nuage obscursisse la facturation Au-delà de cela, je ne sais pas trop quoi vous dire pour être franc. Cela reste du Iaas très basique, bien exécuté sur ce qu’il fait. Une communication efficace Après ce test, on a une impression étrange surtout si vous n’êtes pas sur Twitter. Pourquoi parler d’une solution comme celle-ci alors que celle-ci n’offre rien de nouveau par rapport à l’existant et surtout pourquoi on en parle tant. Tout simplement suite à une opération de communication d’ampleur. Pile le long week-end du 11 novembre des dizaines de comptes se sont mis à Twitter des photos d’une box reçue par courrier. Je vous avais dit que c'était une filière de La Poste ? Dans cette box, que Julie à reçu à la maison on retrouve des stickers, sucette, un carnet, mais surtout beaucoup de crédit pour la plateforme. Certaines box allaient jusqu’à 10 000€ de crédit. Des chiffres assez impressionnants il faut le reconnaitre qui font parler d’eux. De plus le fait de viser largement et de manière généreuse un publique pas forcément habitué à ce type de communication, limite chez beaucoup l’esprit critique plus ou moins consciemment. S’en suivent alors de nombreux échanges et test de la solution sur les réseaux sociaux. Échange où d’ailleurs les personnes de Nuage étaient bien présentes pour répondre aux diverses questions ou problèmes rencontrés. C’est la première fois que je voie un sujet aussi présent sur mon fil Twitter, si on exclut les pannes. Avoir visé très largement une communauté petite, mais très active comme la tech Fr est surement une très bonne idée de leurs parts, et je pense que l’opération de ce côté est une réussite totale. On peut donc se demander pourquoi cette opération de communication alors que la solution semble pas terminée, au niveau des fonctionnalités. Alors là bien sûr il ne va s’agir que de supposition de ma part. Pour moi Nuage à cette heure n’est qu’un PoC. Quand vous faites un PoC cloud comme celui-ci, vous avez derrière des serveurs, des datacenters, bref un gros coût matériel. Vous savez très bien que de base vous ne pourrez pas remplir vos clusters de client à ce stade, néanmoins vous avez besoin de feedback, de test, de voir si vous tenez la charge. Plutôt que faire des tests en interne, ils se sont dit qu’il serait plus intéressant de laisser les gens tester en arrosant de crédit, cela ne leur coutant virtuellement pas de si grosses sommes le matériel étant là. Un peu à l’image des betas ouvertes de jeux vidéo. De plus maintenant que le produit est présenté on peut imaginer une stratégie de communication régulière lors des annonces pour maintenir la flamme. Pour l’instant la communication est le marketing sont clairement à mon sens leurs plus gros point fort. Alors ? Comme sur un nuage ? Peut-on juger la solution alors qu’elle est plus au stade du PoC que de la sortie ? Non, je ne pense pas. Actuellement c’est très limité, rien que l’indisponibilité publique des APIs et autre automatisme ne permet pas de la juger comme une vraie solution cloud. Ce qui ne nous empêche pas de nous faire un premier avis. Le backlog est aux dires bien remplis, mais je suis le type de personne à attendre les livrables et ne pas juger sur les intentions. Donc je n’aborderai aucun des sujets au backlog. L’interface est propre est soignée, on voit bien que c’était un des buts principaux du produit. Sur l’aspect simplicité, je dois avouer que j’ai peur. Il est assez simple d’avoir une interface épurée quand on dispose de peu de produit et d’options, mais conserver cette simplicité avec plus de produits sera surement un exercice bien plus complexe. Ce qui m’embête un peu c’est que j’ai l’impression que l'on confond simple et simpliste, la personnalisation est très limitée sur certains points, notamment les security groups. Avoir des options avancées quitte à ce quelles soient par défaut masqué serait, je pense nécessaire. Il faut néanmoins reconnaitre que l’opération de communication est une vraie réussite, rien que le fait d’écrire cet article le prouve bien à mon avis et à mon sens a utilisé un vecteur intéressant la communauté tech française. Bravo à eux pour cela. J’aimerais que d’autres acteurs français innovent aussi là-dessus, sur la communication et la promotion de leurs services. Un aspect par contre me questionne et surtout me dérange, qu’apporte de plus un nouvel acteur orienté IaaS ? Leurs propositions de valeur principales, mais je ne pense pas que ça soit suffisant pour des entreprises surtout si cela se fait au détriment de la personnalisation. Des solutions IaaS permettant de créer des machines virtuelles c’est pas ce qui manque en France, rien qu’en prenant des acteurs que me viennent de tête comme Ikoula, Scaleway, OVHCloud, Outscale on a de quoi faire. J’aimerais vraiment qu’on arrive à avoir des fournisseurs qui offrent une vraie alternative aux produits américains, mais j’ai peur qu’en créant des dizaines de fournisseurs IaaS la situation n’avance pas réellement, pire qu’on s’auto-concurence. Au-delà des services, je pense qu’il y a aujourd’hui d’autres moyens de s’imposer, avoir une proposition de valeur qui permette de se démarquer des autres. Et quand je dis ça je n’attaque personne, je me pose juste la question du marché de la machine virutelle et de ce que nous pouvons souhaiter pour le futur de la scène cloud française. Dans tous les cas, il faudra voir comment le produit évolue, et les services qui vont sortir avec. Je souhaite bon courages aux équipes de Nuage pour la suite. header image by Photo by Pero Kalimero on Unsplash

Il faut bien le reconnaitre l’arrivée du Cloud a popularisé pas mal de nouvelles technologies. Parmi elles, une doit vous revenir assez rapidement en tête: l’Object Storage. Popularisé par le service S3 d’AWS, cela permet de stocker des objets dans un espace normalisé au travers d’une API. D’ailleurs il est intéressant de voir qu’aujourd’hui cette technologie est tellement populaire que la plupart des Cloud Provider proposent des services d’Object Storage compatibles avec la technologie S3 d’AWS. En général les Buckets (espace de stockage d’objets), sont utilisés pour beaucoup de besoins divers. Globalement ils sont utilisés pour stocker des fichiers durant un traitement, ou directement des assets web (ce blog est d’ailleurs entièrement hébergé dessus). Au-delà de ces usages plutôt classiques, des personnes ont eu une idée originale: créer un système de fichiers qui utilise les buckets comme base pour le stockage ! Je vous propose donc dans cet article de tester la mise en place de cette solution et de voir ce que cela donne dans la pratique. Tutoriel : Installons tout ça Mise en place du lab Je vais faire cet exemple sur AWS (avec Terraform), car c’est un Cloud que je connais bien, néanmoins il est tout à fait possible de le faire chez d’autres Cloud Provider en adaptant un peu. Pour ce test nous avons besoin de certaines ressources: nous allons donc commencer par les créer. Je ne rentrerai pas dans les détails concernant cette partie, mais je vais quand même revenir sur deux ou trois points qui me semblent importants. Le code Terraform du lab est disponible de manière complète sur Github: Projet Github On commence par créer notre instance, rien de particulier a signaler ici. J’utilise l’image officielle (AMI) de Debian 11 sur AWS. Les plus attentifs auront tout de même remarqué que je créai aussi un rôle IAM que j’attache à l’instance. Ce rôle donnera le droit à mon instance et tout programmes s’exécutant dessus d’utiliser le S3, notamment FuseFS ce qui nous intéresse dans notre cas. C’est une bonne pratique de sécurité d’utiliser cette fonctionnalité plutôt que des tokens dans des fichiers, cela réduit les possibilités de fuite de token. data "aws_iam_policy_document" "bucket_access" { statement { effect = "Allow" actions = [ "s3:*" ] resources = [aws_s3_bucket.this.arn] } } On continue ensuite avec le bucket S3 des plus classiques, on note tout de même que l’on bloque les droits de publication d’objets publiquement afin d’éviter toute erreur et de réduire les risques de fuite encore une fois. resource "aws_s3_bucket" "this" { bucket = var.bucket_name acl = "private" } resource "aws_s3_bucket_public_access_block" "this" { bucket = aws_s3_bucket.this.id block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true } A noter que ce blocage peut-être fait au niveau du compte AWS, ce qui permet de bloquer tous les buckets du compte. C’est une option à considérer sérieusement en entreprise sur les comptes qui n’ont pas à exposer de donnés publiquement pour éviter encore une fois les fuites. Installation et configuration de FuseFS Nous allons donc installer et configurer S3 FS, vous allez voir c’est très simple. Le package est disponible sur les dépôts standards de la distribution, ici Debian donc un simple apt -y install s3fs suffit. Après l’installation, il nous suffit d’ajouter notre nouveau FS dans le fichier /etc/fstab et de faire un petit mount -a. Nous ajoutons donc la ligne suivante : NOM_BUCKET PATH_POINT_MONTAGE fuse.s3fs _netdev,allow_other,iam_role=NOM_DE_VOTRE_ROLE,url=https://s3-eu-west-1.amazonaws.com,use_cache=/tmp 0 0 Décomposition là ensemble, pour comprendre les différentes options : _netdev : permet de préciser au système (systemd.mount) qu’il s’agit d’un volume réseau. allow_other : permet d’autoriser d’autres utilisateurs que l’utilisateur ayant monté le volume (en général root). iam_role : permet de définir le rôle IAM à utiliser, celui-ci étant créé et attaché au point précédent. url : définit l’endpoint à contacter, ici nous paramétrons eu-west-1 car nous avons installé notre lab en Irlande. use_cache : comme vous l’avez compris, nous utilisons directement un bucket en backend, donc chaque action sur le FS se traduit par un appel API, ce qui provoque de la latence. Néanmoins on peut définir un espace de cache afin de stocker les fichiers localement et donc limiter l’impact. Si jamais vous rencontrez des soucis, voici quelques pistes pour debug : Vérifier que vous avez le bon rôle (sensible à la casse) : curl http://169.254.169.254/latest/meta-data/iam/security-credentials/NOM_DE_VOTRE_ROLE Montez le directement avec l’utilitaire, sans passer par fstab : s3fs -o iam_role=NOM_DE_VOTRE_ROLE -o url=”https://s3-eu-west-1.amazonaws.com" -o endpoint=eu-west-1 -o curldbg -o allow_other NOM_BUCKET PATH_POINT_MONTAGE Passez en mode debug : s3fs -o iam_role=NOM_DE_VOTRE_ROLE -o url=”https://s3-eu-west-1.amazonaws.com" -o dbglevel=info -o endpoint=eu-west-1 -o curldbg -o allow_other NOM_BUCKET PATH_POINT_MONTAGE On peut maintenant tester notre installation, en jouant avec des fichiers sur ce nouveau FS ! Que penser de fuseFS (et de l’utilisation de S3 en tant que fs) Comme vous l’avez vu, l’installation et la configuration sont assez triviales, ça fonctionne plutôt bien, malgré quelques problèmes de droits qui peuvent arriver. Comme je le laissais entendre, il y a bien évidemment des performances bien en dessous de ce que l’ont peut avoir avec du stockage classique (EBS par exemple). N’y espérez donc pas y stocker de gros fichiers, ou dans ce cas armez-vous de patience. On peut se demander à quoi cela peut-il servir du coup. Clairement pas à tout le monde, mais dans pas mal de petits besoins cela peut s’avérer très simple et efficace. Par exemple si vous souhaitez garder de côté pour traiter des fichiers d’une instance en autoscaling, cela peut-être moins lourds qu’un EBS. Néanmoins, au vu des performances et des quelques soucis de droits que j’ai pu voir, je déconseille de l’utiliser pour des besoins sensibles. Au-delà du stockage, on pourrai aussi imaginer l’intégrer dans des workflows simples, par exemple en backend de stockage à un petit serveur FTP. Quand la personne upload un fichier, qui va dans S3 on pourrait déclencher automatiquement et nativement une action pour informer par mail ou chat de l’ajout d’un fichier. Ce n’est donc pas un logiciel qui va changer le monde et qui sera utilisé à toutes les sauces, mais une bonne solution à garder sous le coude. Head photo by Luca Bravo on Unsplash

Qui n'a pas entendu parler des certifications techniques ? Souvent, on nous en parle alors que nos études ne sont pas encore terminées. Beaucoup ne savent pas quoi en penser, entre les détracteurs qui n'y voient aucun intérêt, et les personnes qui s'empressent d'aligner un maximum de certifications sur le profil tel un scout aligne les badges. La réalité étant plus nuancée, je vous propose de nous pencher un peu plus sur ce sujet épineux. Le but des certifications techniques ? La première question que l'on peut se poser légitimement est l'utilité d'une certification technique. La réponse qui parait le plus logique est que celle-ci vient en complément des diplômes attestant de compétences spécifiques, en général d'une expertise particulière. Certains se demandent surement si cela apporte plus que ce que notre expérience prouve déjà, la réponse est encore une fois que cela dépend, notamment, de la personne qui juge votre niveau ; les certifications ayant tout de même le mérite de définir une standardisation du niveau sur des domaines qui ne sont pas forcément simples à évaluer. Dans certaines entreprises et dans certains cadres, avoir une certification peut clairement vous débloquer des missions ou des postes. Pour l'instant cela parait plutôt évident et je ne vous apprend surement pas grand-chose. Mais en réalité il s'agit surement pas de l'enjeu majeur des certifications, notamment pour les entreprises. Car si les entreprises poussent à la certification, ce n'est pas juste pour le pur plaisir. L'enjeu est très simple, le nombre et le niveau de certification des employés débloquent des niveaux de partenariats aux entreprises avec les fournisseurs. Exemple assez classique que j'ai connu dans les DSI, Microsoft étant souvent un des principaux fournisseurs. Si jamais votre entreprise arrive à avoir un certain nombre de personnes certifiées, vous obtiendrez des avantages comme des crédits cloud, ou encore des avantages commerciaux plus classiques. Bref, cela devient très rapidement un enjeu très important pour les entreprises. Une certification, ça se passe comment ? Il y a, en règle générale, deux formules pour passer une certification. Il y a tout d'abord les certifications simples, où vous révisez un programme et vous passez votre examen, ce qui revient globalement à passer le bac en candidat libre. Il y a ensuite les formules « tout compris » où vous suivrez une formation qui vous donnera de bonnes bases et vous entrainera à l'examen, même si souvent cela nécessite un investissement personnel en complément. On peut comparer cette deuxième formule à la scolarité classique pour passer le bac. Cette dernière est bien sûr bien plus onéreuse, et c'est souvent la première qui est choisie, les révisions étant prévues sur de l'investissement personnel. Tout ça c'est pour la forme, mais pour le fond ? Comment va-t-on m'évaluer ? Là encore il y a plusieurs écoles : Les questionnaires à choix multiples ou ouvertes sont les plus répandus. Vous êtes évalués sur des questions à propos de la technologie. Les questions peuvent être très théoriques (combien de CPU peut supporter Windows Server 2016) ou plus ouvertes avec parfois des mises en situation, en fonction de la technologie. Il s'agit de questions qui pour beaucoup se font par bachotage de sujet malheureusement. Souvent, la difficulté de l'exercice est plus de comprendre correctement la question que de trouver la bonne réponse. Les examens pratiques sont bien moins nombreux. Ils ont été grandement remis au goût du jour par la Linux Foundation. Ici, fini les questions, vous êtes face à un sujet et une console en général, et c'est à vous d'écrire les commandes ou le code nécessaire pour répondre au sujet. C'est à mon sens la meilleure manière de faire aujourd'hui même si malheureusement elle est encore peu répandue aujourd'hui. En général les certifications peuvent prendre place dans un parcours de certifications, celui-ci est souvent composé de branches allant vers diverses spécialisations. Attention néanmoins, il est souvent nécessaire de réussir les certifications de base pour accéder aux suivantes. Vous pouvez voir un exemple ici avec le parcours de certification d'AWS, où certaines certifications comme l’“architect” nécessite la certification “pro” : Je ne parle pas des certifications de suivi de formation type Udemy qui sont uniquement des certifications “prouvant” que vous avez vu l'ensemble d'un programme. Il est à noter par contre, que beaucoup de formations sur ce type de site sont tout à fait adaptées pour se préparer à passer une certification technique classique. Une bonne manière d’apprendre ? On peut se demander si passer une certification est une bonne manière d'apprendre et de s'améliorer dans une technologie. La question n'est pas si simple, dire que vous n'apprendrez rien au cours du passage d'une certification serait surement de mauvaise foi. Voir la manière dont le fournisseur voit ses services et leurs fonctionnement est, je pense, toujours intéressant. De plus, en fonction de l'examen, s'il y a de la pratique notamment, vous en sortirez surement plus à l'aise avec l'outil. Néanmoins, à mon avis, cela est à nuancer. Comme je le disais, la majorité des certifications restent du bachotage, ce qui n'est à mon sens pas la meilleure des manières d'apprendre. De plus, un grand nombre de certifications reste assez abstrait et se contente de vérifier des connaissances uniquement théoriques. Une fois face à des problématiques et des cas concrets, vous pouvez être perdu malgré l'obtention de celle-ci. Au final, qu’en penser Comme vous l'avez vu, le sujet des certifications est très complet et leur utilité est réelle en fonction du contexte. Même si cela ne représente pas le meilleur moyen d'apprentissage, il s'agit d'un bon moyen d'ajouter un avantage à votre profil, sans oublier les certifications sur la pratique que je vous conseille de privilégier. Pour certains, les certifications sont aussi un bon moyen de se motiver à travailler une technologie, ce qui est une bonne chose. Néanmoins, j'ai tendance aussi à penser que s'il s'agit uniquement d'un besoin d'apprendre ou de visibilité, il y a surement des solutions plus efficientes. Écrire des articles de blog, contribuer sur de l'open source, voir aider des associations vous permettra surement d'en apprendre plus et de gagner en visibilité en moins de temps. Maintenant que nous avons abordé un peu plus ce sujet, vous êtes libre d'évaluer si c'est le bon moment de passer une certification.