Zwindler's Reflection https://blog.zwindler.fr Ma vie parmi les lol-cats || je mine des bitcoins dans mon dressing Wed, 18 Sep 2019 11:46:19 +0000 fr-FR hourly 1 https://wordpress.org/?v=5.2.3 https://blog.zwindler.fr/wp-content/uploads/2017/03/nyanonimous_rond-150x150.png Zwindler's Reflection https://blog.zwindler.fr 32 32 126029280 Racisme, misogynie, et pire encore… beaucoup de boulot pour nettoyer l’IT https://blog.zwindler.fr/2019/09/17/racisme-misogynie-et-pire-encore-beaucoup-de-boulot-pour-nettoyer-lit/ https://blog.zwindler.fr/2019/09/17/racisme-misogynie-et-pire-encore-beaucoup-de-boulot-pour-nettoyer-lit/#comments Tue, 17 Sep 2019 16:00:52 +0000 https://blog.zwindler.fr/?p=5151 Richard Stallman démissionne de la présidence de la FSF 💥 BOOM ! 💥 C’est la news (qu’on suspectait arriver, certes) de mardi matin, dans le petit monde de l’IT et plus particulièrement du logiciel libre. https://www.fsf.org/news/richard-m-stallman-resigns Richard « RMS » Stallman, sous la pression, démissionne de la présidence de la FSF (Free Software Foundation). C’est pourtant lui […]

Cet article Racisme, misogynie, et pire encore… beaucoup de boulot pour nettoyer l’IT est apparu en premier sur Zwindler's Reflection.

]]>
Richard Stallman démissionne de la présidence de la FSF

💥 BOOM ! 💥

C’est la news (qu’on suspectait arriver, certes) de mardi matin, dans le petit monde de l’IT et plus particulièrement du logiciel libre.

https://www.fsf.org/news/richard-m-stallman-resigns

Richard « RMS » Stallman, sous la pression, démissionne de la présidence de la FSF (Free Software Foundation).

C’est pourtant lui qui l’avait fondée fin 85, dans le but de promouvoir les logiciels libres.

Pour beaucoup, RMS est/était un mentor. Une vie passée à défendre les 4 libertés fondamentales du logiciel libre, forcément, ça laisse des traces.

Une démission inévitable

Qu’est ce qui a « mis le feu au poudre » ?

Depuis quelques jours, de nombreuses personnes réclamaient la démission de Richard Stallman suite à une série d’emails, envoyés sur une large mailing liste du MIT (université dans laquelle RMS est également ). Ces emails ont été révélés par une élève du MIT (Selam Jie Gano), dans un post publié sur Medium qui est quasiment instantanément devenu viral.

Pour ceux qui n’ont pas suivi, Stallman a publiquement défendu un de ses anciens collègues, Marvin Minsky. Sa thèse étant que Epstein a forcé une étudiante du MIT mineure à approcher Minsky, mais que Minsky n’aurait pas su qu’elle n’était pas consentante… Glauque…

We can imagine many scenarios, but the most plausible scenario is that she presented herself to him as entirely willing. Assuming she was being coerced by Epstein, he would have had every reason to tell her to conceal that from most of his associates.

Richard Stallman dans un email envoyé à des collègues et des élèves du MIT

Dans le meilleur des cas, Richard Stallman est juste extrêmement maladroit. Dans le pire…

Difficile de trancher avec certitude, même avec tous les éléments qui sont remontés depuis, mais le passé de Richard Stallman ne l’a sûrement pas servi dans cette histoire. La déferlante médiatique a choisi « le pire », conduisant à son inévitable démission.

Car en réalité, cela fait des années que RMS enchaîne les propos polémiques de ce goût là. Plusieurs articles de blogs ont remontés les nombreuses sorties de RMS (blog/emails), jusqu’à 2006 et clairement ça donne la gerbe.

I am skeptical of the claim that voluntarily pedophilia harms children. The arguments that it causes harm seem to be based on cases which aren’t voluntary, which are then stretched by parents who are horrified by the idea that their little baby is maturing.

–Richard Stallman en 2006

Et encore, si c’était le seul ?

Vous allez me dire « OK, c’est peut-être un sale type, et si c’est le cas, bon débarras ».

Le souci, c’est que Richard Stallman n’est qu’un exemple de ce qui ne va pas dans l’informatique, et plus largement dans notre société.

Je ne compte plus le nombre de commentaires/d’histoires sexistes, misogynes, racistes ou homophobes que j’ai entendu dans notre environnement au sens large (cercles pro, réseaux sociaux, presse, …).

Et ce que je trouve le plus inquiétant dans tout ça, c’est peut être que finalement, on est pas (peu) au courant, à moins d’explicitement chercher ce genre de choses. C’est comme si tout le monde s’en fichait.

Au même titre que je n’apprend que maintenant les opinions publiques de RMS, la semaine dernière, je découvrais avec stupeur que l’auteur de Dilbert (web comic d’un sysadmin), que j’aimais bien, est en réalité un raciste misogyne, ouvertement assumé, depuis des années.

Comment est ce que j’ai pu passer à côté de ça ? Est ce qu’on est à ce point dans notre microcosme technico-technique au point de tout passer à ce genre de personnes ?

Dans un registre différent, Linus Torvalds, le créateur de Linux, est spécialement connu pour son agressivité et sa grossièreté en public, notamment sur la mailing list du noyau Linux :

“Please just kill yourself now. The world will be a better place”

“Guys, this is not a dick-sucking contest”

“SHUT THE FUCK UP!”

— Linus Torvalds

Est ce qu’on a vraiment envie de travailler dans un domaine où on laisse ce genre de personnalités toxiques s’exprimer sans mot-dire ?

Ces gens là sont quand même hyper influents !

Je le redis, pour beaucoup ces gens là sont des mentors, des maîtres à penser. Et donc on les laisse faire…

Alors dans ces conditions, est ce que finalement, sil y a aussi peu de femmes influentes dans la Tech, est ce que c’est vraiment surprenant ?

Dans un monde où un conseiller inconnu de tous sans aucune compétence, qu’on a chargé shortlister une Secrétaire d’état au numérique parmi 4 femmes archis connues et influentes dans la Tech, préfère s’autoproclamer ?

Il a même applaudi des deux mains par la presse spécialisée !

Qu’est ce qu’on peut y faire ?

Après tout, c’est vrai, tous ces problèmes sont des problèmes de société. Dire que cela vient uniquement de l’informatique serait très exagéré.

Pour autant, je suis convaincu qu’on peut tous faire quelque chose pour aller dans le bon sens, notamment dans l’informatique.

Une étape qui ne coute rien : je vais arrêter de parler de ces gens là dans mes talks. Mine de rien, arrêter d’ériger ces gens là en modèle, c’est déjà un premier pas.

Et ensuite, si vous voulez d’autres pistes, vous pouvez (re)écouter le talk d’ouverture de BDX.IO 2018 d’Audrey Neveu – The Hitchhiker’s Guide to Diversity (Don’t panic!) :

Avec un peu d’huile de coude, on devrait réussir à faire bouger le choses.

Cet article Racisme, misogynie, et pire encore… beaucoup de boulot pour nettoyer l’IT est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/09/17/racisme-misogynie-et-pire-encore-beaucoup-de-boulot-pour-nettoyer-lit/feed/ 9 5151
Du Ceph dans mon Kubernetes https://blog.zwindler.fr/2019/09/10/du-ceph-dans-mon-kubernetes/ https://blog.zwindler.fr/2019/09/10/du-ceph-dans-mon-kubernetes/#comments Tue, 10 Sep 2019 06:45:22 +0000 https://blog.zwindler.fr/?p=5141 Tutoriel pour installer simplement un cluster Ceph sur un cluster Kubernetes en utilisant Rook

Cet article Du Ceph dans mon Kubernetes est apparu en premier sur Zwindler's Reflection.

]]>

Un cluster Ceph dans mon K8s

Make Stateful K8s Great Again

La semaine dernière, j’ai partagé mon sentiment sur le fait qu’il y a un intérêt à utiliser (dans certains cas) Kubernetes. Particulièrement dans le cas d’une infrastructure micro-services fortement hétérogène !

Cependant, certains pourraient être tentés de me faire remarquer que cette infrastructure logicielle a été conçue pour être stateless (l’ensemble des états étant stockés à part, dans une base de données externalisées). Et ainsi, elle s’intègre facilement dans Kubernetes (on se mord la queue).

C’est vrai, en partie. Kubernetes simplifie VRAIMENT la vie dans un contexte comme celui ci. Pour autant, ça ne veut pas dire non plus qu’il n’est pas possible (ni même complexe) de faire du stateful avec Kubernetes.

D’ailleurs, un de mes premiers articles sur Kube en parlait, puisque j’avais PoCé (PoCqué ? que c’est moche parfois le Franglais…) le stateful sur K8s avec XWiki, début 2018. Dans cet article, j’avais créé un instance XWiki + PostgreSQL avec du stockage hautement disponible via GlusterFS, installé directement SUR les machines K8s.

Et Ceph dans tout ça ?

Ceph, c’est une autre paire de manches. D’abord, c’est du stockage bloc en mode synchrone (alors que GlusterFS est un FS distribué). C’est donc pas du tout la même chose.

Thanks captain obvious

Ensuite, c’est quand même un poil plus compliqué à installer et configurer. GlusterFR on se contente d’un démon (ou deux) et de connecter les nœuds entre eux puis déclarer des briques. Sur Ceph, en revanche, il existe plusieurs notions complémentaires (les OSD, les moniteurs, les managers, …).

Une fois de plus, je ne dis pas que ça serait compliqué à faire dans K8s, mais bon… pourquoi s’embêter ?

Et donc Rook ?

Pourquoi s’embêter alors qu’un projet intégré à la CNCF prend en charge l’abstraction de Ceph (et d’autre) directement comme des ressources de Kubernetes ?

A Storage Orchestrator for Kubernetes Rook turns distributed storage systems into self-managing, self-scaling, self-healing storage services. It automates the tasks of a storage administrator: deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management.

Grosso modo, Rook nous automatise la gestion de stockage hautement disponible, en gérant le stockage comme une ressource dans Kubernetes.

Dans ce tuto, je vous propose donc de se concentrer sur Ceph uniquement, mais vous pouvez très bien déployer autre chose (en suivant la doc).

Sachez que Ceph vient de passer en V1 dans le projet Rook, signe de stabilité. Cependant, vous avez plein d’autres options (Cassandra, Minio, …) à divers niveaux de maturité dans leur intégrations avec le projet Rook.

Prérequis

D’abord les prérequis => https://rook.github.io/docs/rook/v1.0/k8s-pre-reqs.html.

Rook est disponible depuis un moment, mais si vous voulez vous évité des soucis, il est conseillé de rester sur une version relativement récente de Kubernetes. Rook est officiellement supporté sur les K8s 1.10+.

Il vous faudra un compte avec les prévilèges cluster-admin pour bootstrapper Rook. Ne vous inquiétez pas, c’est juste le temps de créer les rôles et les CRDs.

Si vous n’en possédez pas, il est possible de demander à votre admin préféré de configurer directement les bons droits pour Rook à la main (https://rook.github.io/docs/rook/v1.0/psp.html).

Enfin, il sera nécessaire d’avoir sur les machines qui exécutent Rook+Ceph de disposer du module Kernel rbd et d’avoir le package lvm2 d’installé.

modprobe rbd

Ne doit rien retourner.

If it says ‘not found’, you may have to rebuild your kernel or choose a different Linux distribution.

On déploie Rook et Ceph !

Rook nous met à disposition des fichiers d’exemples sur le dépôt principal, notamment pour configurer Ceph de A à Z :

git clone https://github.com/rook/rook.git
cd rook/cluster/examples/kubernetes/ceph
kubectl create -f common.yaml
kubectl create -f operator.yaml
kubectl create -f cluster-test.yaml

Le fichier common.yaml va créer les CRD nécessaires à Rook, les (Cluster)Roles, les services accounts et enfin les (Cluster)RoleBindings associés.

Le fichier operator.yaml créé un déploiement rook-ceph-operator, qui va nous permettre de gérer les demandes de créations de CRD de Rook (lien vers un tuto pour expliquer ce que sont les CRD et les operators)

Le dernier fichier, cluster-test.yaml est celui qui va réellement créer le cluster Ceph dans votre Kubernetes. C’est lui qui va déterminer le nombre de chaque composant de Ceph dont vous aller disposer.

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: ceph/ceph:v14.2.2-20190722
    allowUnsupported: true
  dataDirHostPath: /var/lib/rook
  mon:
    count: 1
    allowMultiplePerNode: true
  dashboard:
    enabled: true
  monitoring:
    enabled: false  # requires Prometheus to be pre-installed
    rulesNamespace: rook-ceph
  network:
    hostNetwork: false
  rbdMirroring:
    workers: 0
  storage:
    useAllNodes: true
    useAllDevices: false
    directories:
    - path: /var/lib/rook

Note: Dans mon cas, j’ai ajouté à mes machines un disques /dev/sdd; j’ai donc remplacé les dernières lignes par "deviceFilter: sdd"

Une fois que vous avez exécuté la dernière commande, vous avez un cluster Ceph "de démo" opérationnel.

Il n’est pas conseillé de l’utiliser tel quel en production, car plusieurs composants ne sont pas redondés comme on a pu le voir en lisant le YAML ci dessus, et le stockage est assuré par un dossier sur chaque hôte Kubernetes, ce qui n’est pas du tout conseillé.

Cependant, on a l’ensemble des features qui sont activées, c’est parfait pour un test (mode bloc, objet ou fichier)

Vérifier que tout fonctionne

La documentation de Ceph recommande d’utiliser un déploiement appelé rook-toolbox pour vérifier que tout fonctionne.

Dans un premier temps, on peut commencer par simplement regarder si tous nos pods sont vivants :

kubectl --namespace=rook-ceph get pods
NAME                                                   READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-5r648                                 2/2     Running     0          2d22h
csi-cephfsplugin-provisioner-0                         3/3     Running     0          2d22h
csi-rbdplugin-m7299                                    2/2     Running     0          2d22h
csi-rbdplugin-provisioner-0                            4/4     Running     0          2d22h
rook-ceph-agent-b79dl                                  1/1     Running     0          2d22h
rook-ceph-mgr-a-86586f9f4d-lz5df                       1/1     Running     0          2d22h
rook-ceph-mon-a-5fdc888bc4-qqb4m                       1/1     Running     0          2d22h
rook-ceph-operator-698b5d4fcc-dwdth                    1/1     Running     6          2d22h
rook-ceph-osd-0-667dcd84cf-h2tz8                       1/1     Running     0          2d22h
rook-ceph-osd-prepare-aks-agentpool-12737853-0-ntrn5   0/2     Completed   0          5h26m
rook-discover-sfdj4                                    1/1     Running     0          2d22h

Comme on peut le voir, tout est OK dans mon exemple.

On peut ensuite déployer la toolbox, dont le fichier YAML est présent dans le même dossier :

kubectl create -f toolbox.yaml

kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bash

Une fois connecté, on peut lancer les commandes suivantes et commencer à interagir avec Ceph

ceph status
  cluster:
    id:     7099fc42-a47f-4412-8775-f6f3d4ce669d
    health: HEALTH_OK
 
  services:
    mon: 1 daemons, quorum a (age 111s)
    mgr: a(active, since 78s)
    osd: 1 osds: 1 up (since 60s), 1 in (since 60s)
 
  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 B
    usage:   12 GiB used, 84 GiB / 97 GiB avail
    pgs:   


ceph osd status
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| id |           host           |  used | avail | wr ops | wr data | rd ops | rd data |   state   |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
| 0  | aks-agentpool-12737853-0 | 12.4G | 84.4G |    0   |     0   |    0   |     0   | exists,up |
+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+

Créer un pool Ceph

Dans cet exemple, comme je n’ai qu’un seul OSD (un seul "disque", ici un dossier sur un serveur), je vais créer un pool sans réplication.

Si vous utilisez Rook en Production, vous aurez donc vous des disques dédiés (au minimum un sur tous les serveurs, ou à minima, au moins 3). Voir la documentation officielle pour plus d’info.

---
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  failureDomain: host
  replicated:
    size: 1

De même, on va créer une StorageClass, qui va permettre à Kubernetes de réaliser la création des volumes à la demande (les PVs sont créés lorsqu’une application demande la création d’un volume via un Persistent Volume Claim)

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: rook-ceph-block
provisioner: ceph.rook.io/block
parameters:
  blockPool: replicapool
  clusterNamespace: rook-ceph
  fstype: xfs
reclaimPolicy: Retain

A partir de là, vous avez maintenant un stockage hautement disponible et réparti équitablement sur vos serveurs Kubernetes.

Si vous voulez tester, dans le même dépôt, on a à disposition 2 fichiers YAML d’exemple pour déployer MySQL + WordPress

zwindler:~/sources/rook/cluster/examples/kubernetes$ kubectl create -f mysql.yaml
service/wordpress-mysql created
persistentvolumeclaim/mysql-pv-claim created
deployment.apps/wordpress-mysql created

zwindler:~/sources/rook/cluster/examples/kubernetes$ kubectl get pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mysql-pv-claim   Bound    pvc-d245dd2d-d0a1-11e9-9f5c-26f444bf7bdc   20Gi       RWO            rook-ceph-block   10s

zwindler:~/sources/rook/cluster/examples/kubernetes$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS      REASON   AGE
pvc-d245dd2d-d0a1-11e9-9f5c-26f444bf7bdc   20Gi       RWO            Retain           Bound    default/mysql-pv-claim   rook-ceph-block            26s

Elle est pas belle là vie 🙂 ?

Cet article Du Ceph dans mon Kubernetes est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/09/10/du-ceph-dans-mon-kubernetes/feed/ 5 5141
Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? » https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/ https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/#comments Tue, 03 Sep 2019 06:30:16 +0000 https://blog.zwindler.fr/?p=5068 Billet d'humeur pour parler de tout ces gens qui considèrent que Kubernetes apporte plus de problèmes qu'il n'en résout

Cet article Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? » est apparu en premier sur Zwindler's Reflection.

]]>

La hype, c’est de dire que Kubernetes c’est nul (parce que c’est hype ?)

Youpi ! Encore un billet d’humeur cette année 😉

J’espère que comme moi, quand vous lisez dans votre tête "Concerning Kubernetes", vous avez l’air de "Concerning Hobbits" de Howard Shore dans la tête 🙂

Aujourd’hui je vais parler de Kubernetes mais rien de technique, seulement un question que je me pose :

Pourquoi c’est devenu à la mode de dire que Kubernetes c’est pas bien ?

Alors forcément, en "full disclosure", pour ceux qui ne me connaissent pas, je suis obligé d’indiquer que j’utilise Kubernetes dans mon travail d’Ops depuis environ 2 ans (++). J’en ai d’ailleurs abondamment parlé ces deux dernières années.

J’ai également utilisé Kubernetes à titre personnel pendant 6 mois, notamment pour héberger mon blog. L’objectif était uniquement d’apprendre Kubernetes par l’usage et je n’ai à aucun moment considéré que ce mode d’hébergement convenait à mes besoins (d’ailleurs, je ne l’utilise plus à titre personnel, maintenant que je sais comment ça marche).

Car oui, Kubernetes c’est un outil

Et comme tout outil, il faut :

  • l’utiliser idéalement dans les cas qui correspondent à son usage
  • savoir l’utiliser
File source: https://commons.wikimedia.org/wiki/File:Sledgehammer_(3586724830).jpg

Et donc, le cœur du sujet ?

Donc je l’ai déjà dis, mais ça fait quelques semaines que je vois de nombreuses attaques de personnes différentes qui expliquent que Kubernetes, c’est naze.

J’ai classé ces personnes en 4 types d’intervenants sur le sujet.

1, des Ops

D’abord, des confrères. La plupart du temps, il s’agit de gens qui n’ont pas utilisé l’outil, ne travaillent pas dans des environnements où Kubernetes pourrait rapidement leur apporter des gains, ou qui n’ont juste pas envie de changer leurs habitudes.

Oui, Kubernetes c’est (modérément) complexe. Même Kelsey Hightower, évangeliste Kubernetes niveau super Rockstar de chez GCP (Google) et auteur du guide "Kubernetes the hard way" le clame haut et fort :

Utiliser Kubernetes impose d’assimiler un certain nombre de concepts techniques, pour une part inhérents aux architectures microservices containerisées, pour l’autre part spécifiques à Kubernetes lui-même. De même, il faut composer avec un certain nombre de limitations et accepter de travailler différemment (on ne gère pas un serveur web de la même façon dans une VM et dans un container sur un orchestrateur managé).

Autant dire que quand un confrère Ops me parle de passer directement d’un environnement bien massif de type IBM AIX et ERP propriétaire vers l’installation d’un Openshift, la première chose que je lui dis c’est "Tu es sûr ? Tu ne veux pas plutôt tester un peu les containers Docker d’abord ?".

Dans des cas comme ça, échouer puis reprocher à Kubernetes d’être complexe est un peu malhonnête. Car quand on passe directement d’un mainframe à Kubernetes, on a loupé plusieurs changements dans la façon de travailler dans l’IT de ces 10 dernières années (++).

2, des hobbyists

Quasiment à chaque fois que j’écris un article sur Kubernetes, même quand il s’agit d’un truc aussi simple à déployer que l’offre Kubernetes as a Service d’OVH, je me retrouve avec un commentaire du style

Alors, déjà merci, parce que ça me fait toujours sourire ce genre de commentaires sur le blog 😉

Ensuite : mais par rapport à quoi ?

  • A héberger tes photos de vacances sur ton NAS Synology ? Certainement !
  • A gérer une plateforme de domotique sur ton raspberry pi ? Sans aucun doute.
  • A publier tes 3 billets de blog sur Medium ?

Là c’est déjà un peu plus contestable, sachant que tu ne sais pas comment Medium fait pour obtenir un site web utilisé par un grand nombre d’auteurs et de lecteurs, résilient, accessible worldwide et sans plage de maintenance.

Le bon outil

Vous vous souvenez, au début de l’article, la métaphore de la mouche et du sledgehammer ? Bah on est en plein dedans là.

Bien sûr, utiliser Kubernetes pour toutes ces choses n’a pas de sens (publier 3 posts persos lu par 1000 personnes par jour et gérer ta domotique), en tant que particulier.

Ça me rappelle beaucoup le débat qu’il y avait eu lorsqu’un transformateur RTE avait brûlé en juillet 2018 et que la gare Montparnasse avait été dans le noir pendant des heures.

Tout le monde a hurlé au scandale ("pourquoi vous n’avez pas redondé le truc ???") et des types sont venus nous dire sur Twitter "nianiania arrêtez de dire que c’est pas normal de pas redonder. Est ce que vous avez 2 frigos chez vous, au cas où l’un d’entre eux tombe en panne ?"

Je pense que n’importe qui d’un peu honnête peut convenir que des outils d’entreprises comme Kubernetes répondent à des problématiques qu’on ne va pas avoir à gérer quand on est un particulier… Au même titre qu’on peut se permettre de n’avoir qu’un seul réfrigérateur chez soit.

Note : pour ceux qui n’ont pas suivi, dans le cas précis de Montparnasse en 2018, c’était la faute de RTE qui avait garanti à la SNCF que les 3 entrées électriques provenaient de 3 sources différentes, alors que c’était faux.

La 3ème catégorie

Ça fait titre de SF ce sous titre, non ? Ok, je sors => []

Dans les gens qui bashent le plus Kubernetes, on retrouve sans trop de surprise les gens dont le business est en concurrence plus ou moins directe avec Kubernetes. Et naturellement, ce sont eux qui font le plus de bruits (relayés par les autres).

Attention, je ne nie pas le fait que ces gens brillants (s’ils ont réussi, ce n’est pas pour rien) et que leur analyse est pertinente sur certains points.

Pour autant, on peut généralement trouver sans trop de difficultés une certaine mauvaise foi quand ils parlent de Kubernetes (que ce soit conscient ou pas)…

Quand Ian Eyberg écrit "Kubernetes is in Hospice" sur LinkedIn, on peut se demander s’il ne devrait pas demander à quelqu’un de le relire avant d’appuyer sur la touche entrée…

Je vous passe la grossièreté ("crap", etc), le mépris gratuit pour les "développeurs lambda qui font du JS parce que c’est plus simple"… Un type charmant, comme vous pouvez le voir.

k8s est juste une tentative de Google pour faire venir les gens sur Google Cloud

Tu la sens venir la théorie du complot reptilien ?

Facebook n’utilise pas Kubernetes car ça ne scale pas assez bien pour eux. Votre startup de 20 personnes ne devrait pas l’utiliser non plus.

Comparer les besoins de Facebook avec les besoins d’une startup de 20 personnes est une choix intéressant, en terme d’argumentaire je trouve. Et entre la startup et les GAFA, il n’y a rien d’autre ?

La sécurité dans les containers est un échec total

Parce que bien sûr la sécurité dans l’IT non containerisée est totalement maîtrisée. Il n’y a pas du tout d’exploits pour sortir d’une VM, les OS sont toujours à jour chez tout le monde, l’IOT c’est Fort Knox.

(Vous me connaissez, je vous ai forcément gardé le meilleur pour la fin )

Le site https://k8s.af est une collection d’histoires d’horreur sur la façon dont des sociétés ont échoué avec kubernetes. Ce n’est pas quelque chose qu’il faut applaudir ou dont il faut apprendre; c’est quelque chose à éviter. Vous ne pouvez pas dire que vous être ingénieur en génie civil et construire un pont qui risque de s’effondrer. Il y a des vies en jeu !!!!1!1!111

Est ce qu’on peut expliquer à ce monsieur que des fois des ponts s’écroulent et que JUSTEMENT, c’est parce qu’on essaye d’éviter que ça se reproduise qu’on apprend de nos erreurs et qu’on évite de les réitérer ?

Une réponse de l’auteur de k8s.af à ce genre de personnes

Bon, une fois qu’on a lu tout ça, on prend une grande inspiration, on regarde l’entreprise que dirige Ian Eyberg et on voit qu’il est PDG de … NanoVMs.

Et au cas où vous doutiez encore un peu, NanoVMs est une société qui se positionne ouvertement comme une alternative à Docker.

Business is business.

Et les fournisseurs de service ?

Dans le même genre, je me suis pris la tête avec le fondateur d’une solution cloud qui propose aux Dev de gérer l’Ops pour eux, pour qu’ils se concentrent sur le Dev (business totalement pertinent et louable). Il vend un service bien marketé, UX bien pensée, etc, rien à redire de ce côté là.

Cette personne m’explique que c’est plus simple pour un Dev d’utiliser son service que quand je demande à mes collègues Dev d’écrire un template Helm (on y reviendra). Soit, je veux bien l’entendre.

Mais derrière, s’il n’utilise pas Kubernetes (probable vu l’opinion qu’il a de l’outil), il a forcément du déployer des stacks techniques pour résoudre les problématiques similaires (déploiement, provisionning, haute dispo, répartition de charge). Donc au final, il a juste implémenté d’une autre façon, quelque chose qui fait comme Kubernetes.

Et quand je lui fais remarqué ce point précis, devinez ce qu’il m’a répondu (avec les majuscules et tout) ?

RIEN A VOIR

Donc quoi ? Tu fais tout à la main ?

Je vous jure, des fois, la mauvais foi des gens me fatigue…

4, des devs

Et là, on tombe sur la catégorie de personnes dont les réactions négatives m’attristent le plus.

J’ai l’impression que ces gens là ne se rendent pas trop compte de l’effort qu’il faudrait déployer pour obtenir la même chose, sans Kubernetes.

En fait, c’est comme si, en rendant le service aussi résilient qu’il l’est devenu, les Devs pensent que c’est simple d’avoir aussi bien, sans Kubernetes (remplacez Kubernetes par tout autre outil permettant d’automatiser la gestion d’une infrastructure complexe et hétérogène).

Un peu plus de détails

Dans mon travail, nous hébergeons plusieurs plateformes Kubernetes. Ces plateformes sont à destinations des développeurs, pour leur fournir de l’infrastructure de manière "masquée", managée par nous.

Pour vous donner un ordre de grandeur, on parle d’une demi douzaine de clusters, avec entre 50 et 100 machines virtuelles, qui font tourner de manière résiliente plusieurs centaines d’applications chacun.

Ces applications (types microservices) sont hautement hétérogènes. On y dénombre pas moins de 5 ou 6 langages de programmation différents, deux ou trois fois plus de frameworks, des messages bus, des bases de données externes, …

Avec Kubernetes, nous ne leur demandons pas de gérer l’infra, ni même de nous demander de l’infra. Nous leur fournissons, au travers d’une chaîne d’intégration continue (IC), un self service pour consommer cette infrastructure. Les seules choses qu’on leur demande pour consommer cette infrastructure, c’est :

  • de créer leur propre image (aka "image Docker")
  • de rédiger les spécifications de leur application, interprétables par Kubernetes (via Helm, le langage de templating le plus répandu pour déployer sur Kubernetes)
Un extrait d’un chart Helm (https://github.com/helm/charts/blob/master/stable/bitcoind/templates/deployment.yaml)

Pour ces choses, ils peuvent se baser sur des exemples de projets existants et/ou demander de l’aide à mes collègues Ops ou mes collègues de l’intégration continue.

Hashtag DevOps.

Ces deux choses qu’on leur demande sont donc ni plus ni moins que de la configuration et un genre de "code" simpliste, au même titre qu’ils renseignent déjà un pom.xml ou autre packages.json. Pour un développeur, on peut s’attendre à ce que ça ne soit pas un souci.

Et que gagnent ils en échange de ce travail ?

De l’autonomie, du temps

Surtout de l’autonomie sur le déploiement de nouvelles applications, au sens large du terme.

D’abord, pas besoin d’avoir un Ops pour aider et manipuler des problématiques complexes de configuration de serveurs, la redondance/haute disponibilité, répartition de charge, …

Tout ce qu’ils ont besoin de faire, c’est remplir un fichier texte YAML (certes très verbeux) avec les caractéristiques qu’ils souhaitent pour leur application (donne moi 3 instances identiques de telle container, avec tant de CPU/RAM). De base, l’application est alors déployée de manière reproductible, résiliente, se régule d’elle même en cas d’incident, …

Pas besoin de demander aux OPS une nouvelle paire de serveurs webs à la moindre modif et surtout… pas besoin d’attendre pour l’avoir !!

"Le futur et toutes les raisons d’y croire"

Pour illustrer, je peux vous parler d’un exemple personnel. Dans une autre vie pas si lointaine, j’ai été OPS pour un grand opérateur. Pour chaque nouveau projet, je recevais des demandes (aka. un ticket) de la part des Dev pour configurer des serveurs web. Mes collègues et moi avions 3 semaines pour traiter ces demandes.

TROIS… SEMAINES…

Autant dire que j’ai eu un paquet de fois à tout refaire car entre temps, un nouveau modèle (master) avec la mise à jour de l’application était sorti le temps que la demande d’environnement soit traitée.

Avec Kubernetes, en quelques secondes (5 minutes max si on compte toute la chaîne d’intégration continue), c’est livré.

Des Ops plus disponibles

De même, pour gérer ces plateformes, il faut X fois moins de gens pour les administrer que si on devait déployer ces serveurs à la main, à la demande, sur des VMs par exemple. A l’heure actuelle, côté Ops, 2 personnes suffiraient pour maintenir l’ensemble de ces clusters.

Je dis "suffiraient" car nous gérons beaucoup d’autres plateformes en plus de Kubernetes. En terme de "charge homme", 2 ETP auraient encore pas mal de marge pour absorber de nombreux projets (aka applications déployées) en plus. Les autres membres de l’équipe ont le temps de gérer d’autres plateformes.

Je n’ose pas imaginer le nombre d’Ops qu’il faudrait pour maintenir un équivalent "VM" contenant 250 applications hétérogènes, les loadbalancers, etc. 5 ? 10 ? 15 ? Bien plus que 2, c’est sûr…

Et ce temps que l’équipe Ops a de disponible, c’est du temps qui peut servir à améliorer l’infrastructure pour coller le mieux aux besoins des développeurs, maintenir les bonnes pratiques sur l’ensemble du périmètre, les assister en cas de bug, …

Faire du DevOps, en somme.

Moins d’incidents

Là, c’est LA partie qui devrait leur tenir le plus à cœur normalement.

J’ai travaillé sur tous types d’infrastructures. Des bons gros Mainframe, des infrastructures virtualisés, convergées, HYPERconvergées, des SAN, des NAS et depuis 2 ans, sur Kubernetes.

Et bien, laissez moi vous dire qu’il n’y a pas photo. Mais genre, pas du tout.

Le fait de travailler en microservices containerisés, en s’astreignant à suivre quelques bonnes pratiques, permet réellement d’obtenir un service de qualité. 95% des incidents, qu’ils viennent de plantages imprévus de l’application ou de problèmes sur l’infrastructure, se résolvent d’eux même en quelques secondes, la plupart du temps sans notification à l’astreinte lorsque ça n’est pas nécessaire (ce qui n’empêche de débugger a posteriori, juste pas en pleine nuit).

C’est extrêmement impressionnant.

Mes 6 derniers mois d’astreinte se résument quasiment exclusivement à des incidents sur la partie legacy et/ou non containerisée. La partie Kubernetes se gère toute seule, j’ai très rarement eu à intervenir, que ce soit sur la plateforme elle-même, ou sur les applications hébergées dessus.

Au final, les premiers fans de Kubernetes, ce sont les membres de ma famille, que je ne réveille plus la nuit pour redémarrer un serveur web ou basculer un cluster qui s’est mal déclenché.

Donc les devs sont contents ?

Et ben non…

Je ne compte plus le nombre de gens brillants qui m’ont dit :

nan mais attend ton truc, c’est super compliqué

le go template/YAML c’est incompréhensible

c’est pas mon job de faire ça

Et là, je suis hyper déçu.

Venant de gens qui sont capables de m’expliquer avec force de détails pendant 30 minutes ce qu’est une Monad, qu’un Monoid ce n’est du tout la même chose, je trouve ça culotté de venir m’expliquer qu’un bout de GOtemplate, c’est le summum de la complexité.

Je réitère une dernière fois… Oui, Kubernetes, c’est modérément complexe. Non, c’est pas trop complexe. Bien moins que tous les autres concepts que ces gens là manipules tous les jours. C’est juste que le DevOps, au fond, ça ne les intéressent pas vraiment.

Ça se résume d’ailleurs assez bien dans le "c’est pas mon job de faire ça".

C’est le job de qui alors ? De savoir ce que fait l’application, comment elle interagit avec les autres, de quelles ressources elle a besoin ?

Moi je dirais que c’est celui qui l’a développée, EN ÉQUIPE avec celui qui maintient l’infrastructure.

Et je conclurai mon propos par un petit tweet de @bitfield qui a fait pas mal sauter des Devs de leur chaise il y a 3 ans et qui n’a malheureusement pas pris une ride.

¯\_(ツ)_/¯

Cet article Concerning Kubernetes : « combien de problèmes ces stacks ont générés ? » est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/feed/ 11 5068
Cluster Proxmox VE, v6 cette fois ci ! https://blog.zwindler.fr/2019/08/20/cluster-proxmox-ve-v6-cette-fois-ci/ https://blog.zwindler.fr/2019/08/20/cluster-proxmox-ve-v6-cette-fois-ci/#comments Tue, 20 Aug 2019 11:45:00 +0000 https://blog.zwindler.fr/?p=5112 Tutoriel pas à pas (aidé de playbooks Ansible) pour déployer des clusters Proxmox VE 6 depuis des machines Debian Buster

Cet article Cluster Proxmox VE, v6 cette fois ci ! est apparu en premier sur Zwindler's Reflection.

]]>

Proxmox VE

Et oui, avec la sortie de Proxmox VE 6, je vous avais prévenu : il va y avoir pas mal d’articles là dessus, même si quelques articles sur Kubernetes sont en cours d’écriture aussi ;-).

Fin juillet, j’avais écris un article sur des playbooks Ansible que j’ai écris pour faciliter le déploiement de cluster Proxmox VE. Malheureusement, comme cet article traînait dans mes brouillons, les playbooks ne géraient pas la version 6 (qui venait de sortir) de PVE.

C’est aujourd’hui de l’histoire ancienne puisque, pour tester la v6, j’ai forcément du adapter les playbooks ;-).

Point important, je vais partir du principe que vous n’avez pas la possibilité d’installer Proxmox VE directement avec l’ISO. C’est souvent le cas souvent avec les hébergeurs de serveurs dédiés pas chers (oneprovider par exemple) ou de VMs (OVH, Scaleway, etc).

Car si vous avez la main, le plus simple est bien sûr d’installer l’ISO directement ! Cependant, ce tuto reste utile pour toute la partie mise en VPN et configuration du cluster.

Les prérequis

Dans l’article précédent, pour gagner du temps pour ceux qui veulent juste tester, j’avais mis à disposition un playbook permettant de générer des VMs chez le cloud provider Scaleway (et notamment tirer parti de l’inventaire dynamique proposé par le module développé par Scaleway pour Ansible).

Ici, je met volontairement de côté cette partie qui n’apporterait rien de plus. Si vous voulez voir comment ça fonctionne je vous invite à (re)lire l’article précédent, la procédure est la même.

Le seul prérequis pour ce tutoriel sont donc d’avoir idéalement 3 machines* (ou plus) sous Debian 10 (la raison pour laquelle je n’avais pas pu le faire avec Scaleway qui ne propose pas encore Debian Buster) accessibles en depuis votre station de travail.

*Mais si vous voulez juste installer Proxmox, une seule suffit mais vous n’aurez évidemment pas un cluster. A partir de 2, on peut faire un cluster mais il sera instable dès que vous perdrez une seule des 2 machines (ce qui est dommage) à moins d’ajouter un device pour permettre d’avoir le quorum (ce que nous verrons dans un autre article).

Installer Ansible et récupérer les playbooks

Des fois que n’auriez pas Ansible, installez le (pour git, c’est juste plus simple de cloner le dépôt mais vous pouvez le télécharger autrement si vous ne voulez pas installer git)

apt-get install git ansible
git clone https://github.com/zwindler/ansible-proxmoxve
cd 

Ensuite, on créé un fichier d’inventaire pour Ansible (ce qui n’étais pas nécessaire avec Scaleway puisque, je le rappelle, il y a un module d’inventaire dynamique). Ici on se contente juste de lister les serveurs qui nous intéressent.

cat pve_inventory.yml
all:
  children:
    proxmoxve:
      hosts:
        proxmox1.mydomain.tld:
        proxmox2.mydomain.tld:
        proxmox3.mydomain.tld:

Vous ne reconnaissez peut être pas le format de cet inventaire Ansible. En effet, l’inventaire est ici stocké au format YAML et non au format plat. Très peu de gens utilisent ce format (qui existait au début, puis a été retiré pour être de nouveau supporté depuis la 2.4 je crois).

Etant habitué aux inventaires parfois un peu hétéroclites, je préfère largement ce format YAML, qui permet de rajouter de manière beaucoup plus lisibles des varibles à des groupes ou mêmes des hôtes directement (sans passer par une arborescence complète avec groups_vars et hosts_vars). De plus, je trouve les dépendances entre groupes plus claires que lorsque nous avions à déclarer les :children du groupe père (mais c’est subjectif).

Notez par contre qu’il faut :

  • que mes hôtes soient résolvables par DNS (sinon il faut ajouter une variable ansible_host avec l’IP pour chacun)
  • que vous n’oubliez surtout par le ":" à la fin de chaque hostname, sans quoi vous aurez une erreur de syntaxe.

Lancer le playbook d’installation de Proxmox VE 6

Nous y voilà. Normalement vouspouvez accéder en SSH à l’ensemble de vos machines. Pour installer Proxmox VE 6 sur une debian 10, il faut donc simplement lancer la commande suivante :

ansible-playbook -i pve_inventory.yml proxmox_prerequisites.yml -u root

Normalement, le playbook vous promptera pour répondre à quelques questions basiques (votre domaine, est ce que les machines commencent par test plutôt que proxmox dans le hostname, …) et à l’issue, un reboot sera effectué (pour basculer sur le noyau Linux de PVE et pas celui de debian Buster).

Mise en réseau privé virtuel avec Tinc

Cette étape n’est pas forcément nécessaire. Si vous travaillez sur des machines qui sont dans un même réseau local, il vaut mieux s’en passer.

En revanche, dans le cas où comme moi vous louez des serveurs chez un provider et qu’il ne vous met pas à disposition un moyen de simuler un réseau privé (RPN chez Online, Rack quelque chose chez OVH je crois), il sera préférable de monter un VPN entre les différentes machines du cluster.

Je dis préférable et pas nécessaire, car jusqu’à la version 6 de Proxmox (et Corosync v3), il était nécessaire également de faire passer du multicast entre les machines pour faire fonctionner le cluster. Ce n’est aujourd’hui plus le cas et on peut donc très bien imaginer un cluster Proxmox avec des machines sur des LAN distincts. Cependant, pour activer des fonctionnalités comme Ceph (et probablement d’autre), il est toujours nécessaire d’avoir un LAN.

Pour se faire, j’utilise Tinc plutôt qu’OpenVPN, qui a l’avantage d’être simple à configurer et surtout multipoint (pas de notion de serveur maitre et de clients connectés dessus). Ce n’est pas le cas avec OpenVPN, dont la structure client/serveur complexifie beaucoup l’implémentation si on veut éviter un SPOF (en gros il faut un serveur sur toutes les machines, et que l’ensemble des serveurs soient tous clients les uns des autres, en toile d’araignée). Vous pouvez quand même jeter un oeil sur mes premières tentatives ici, si ça vous intéresse.

Comme j’automatise tout avec Ansible, j’ai donc aussi créé un playbook qui permet d’installer et configurer Tinc sur toutes nos machines et de les mettre en réseau sur un VPN dédié.

ansible-playbook -i pve_inventory.yml tinc_installation.yml -u root

A partir de là, vous avez donc 3 machines Proxmox VE 6, connectés ensembles sur un VPN avec l’adresse 10.10.10.0/24

Le réseau c’est compliqué ?

Un point pas forcément évident avec Proxmox est que la configuration du réseau dépend beaucoup de comment vos machines sont connectées en réseau.

Les différentes configurations conseillées sont détaillées dans un article dédié sur le wiki de Proxmox. J’aurais vraiment aimé connaître cette page lorsque M4vr0x et moi avons fait nos premières expériences avec PVE car nous avons beaucoup tâtonné…

Dans mon cas précis, j’ai des machines hostées par un provider. Je n’ai donc aucunement la main sur le réseau et je ne souhaite pas acheter d’IP supplémentaires.

Dans ce cas là, le plus simple est donc de créer un bridge Linux, qui portera un réseau virtuel interne à chaque serveur et dont le trafic externe sera routé.

L’inconvénient de cette solution est qu’on ne peut pas utiliser l’interface graphique pour faire ces modifications, et aussi qu’en cas d’erreur, vous n’aurez plus accès à votre serveur…

Configuration réseau pour des machines dédiées chez un Provider type OneProvider

Nous voilà donc dans les premières bidouilles manuelles. Connectez vous en SSH à votre (vos) serveurs, et modifier le fichier /etc/network/interfaces.

Je me suis basé sur la section "Masquerading (NAT) with iptables"

Le mien ressemble à ça :

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
#real IP address
iface eth0 inet static
        address  x.x.x.x
        netmask  24
        gateway  x.x x.1

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.1
        netmask 255.255.255.0
	bridge-ports none
	bridge-stp off
	bridge-fd 0

        post-up  echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE

Le plus important ici pour que tout fonctionne est que vous ne vous trompiez pas sur le nom de l’interface réseau (eth0 dans mon exemple).

Ensuite, une fois que les modifications sont faites, redémarrez le réseau (systemctl restart networking) ou carrément le serveur (c’est ce que Proxmox conseille, même si je ne vois pas bien l’intérêt).

Ici, la configuration est beaucoup plus simple que ce que nous avions imaginé avec M4vr0x dans la série d’articles détaillés sur PVE 5. Et c’est tant mieux car ça suffira amplement à la plupart d’entre vous ;-).

Configuration du cluster Proxmox VE

Ok ! Maintenant tous les prérequis sont en place, on peut donc construire le cluster. Le wizard de la GUI a assez peu évolué depuis la V5 (même s’il y a quelques petites améliorations)

  • Vous vous connectez sur une des machines
  • Dans la vue Datacenter, vous sélectionnez Create Cluster, puis vous copiez les informations de connexion pour les autres serveurs.
  • Sur les autres serveurs, vous rejoignez le cluster en collant les informations des

(Plus de détails dans l’article précédent)

Cet article Cluster Proxmox VE, v6 cette fois ci ! est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/08/20/cluster-proxmox-ve-v6-cette-fois-ci/feed/ 2 5112
Un cluster Proxmox VE en 5 minutes avec Ansible https://blog.zwindler.fr/2019/07/22/proxmox-en-5-min-ansible-tinc/ https://blog.zwindler.fr/2019/07/22/proxmox-en-5-min-ansible-tinc/#comments Mon, 22 Jul 2019 11:45:34 +0000 https://blog.zwindler.fr/?p=5088 Tutoriel aidé de playbooks Ansible pour générer des VMs sur Scaleway et démarrer un cluster Proxmox VE

Cet article Un cluster Proxmox VE en 5 minutes avec Ansible est apparu en premier sur Zwindler's Reflection.

]]>

Cool on va (encore) déployer du Proxmox VE !!!

Petit tuto aujourd’hui, massivement facilité par l’usage d’Ansible : on va déployer un cluster de machines Proxmox VE via le cloud provider Scaleway.

A noter : Si jamais vous ne voulez pas utiliser Scaleway, les playbooks ont été découpés de manière à ce que la partie d’installation de Proxmox ainsi que l’installation de tinc et la mise en cluster puissent être réalisés à part. Vous pouvez donc tout à faire partir de machines sous Debian 9 via ces playbooks.

Pourquoi Scaleway me direz vous ? Tout simplement parce qu’ils ont, contrairement à d’autres, une très bonne API, qui a permis à un de leurs employés de faire de très bons modules Ansible, notamment un module permettant de gérer l’inventaire dynamique (pas besoin de renseigner un fichier hosts pour Ansible, c’est directement l’API qui nous liste les VMs).

J’ai d’ailleurs utilisé ce provider à plusieurs reprises pour cette raison (voir mon article sur k3s et Ansible ou mon talk à BDX I/O Ami développeur, deviens un ops sans effort avec Ansible).

Proxmox VE 5.4 ? Pourquoi pas 6.0 ?

La deuxième question, tout aussi légitime, repose donc sur "pourquoi diantre monter un cluster Proxmox VE 5.4 alors que tu viens de nous faire un article qui vante les bienfaits de la version 6.0 qui vient de sortir ?"

Et là j’ai deux raisons (une bonne et une mauvaise). La mauvaise, c’est simplement que l’article trainait dans mes brouillons et que je n’ai pas cliqué sur "Poster"… La "bonne" raison, c’est que la version 10 de Debian, qui est la base de Proxmox VE 6, n’est pas encore disponible sur Scaleway, ce qui complique un peu l’installation.

Lorsqu’elle le sera, je ne manquerais pas de faire un petit refresh de l’article ainsi que des playbooks Ansible 😉

Déployer les VMs avec Ansible

Je l’ai dis juste avant, le gros avantage de Scaleway, c’est de pouvoir spawner des VMs à la volées avec Ansible et surtout d’avoir l’inventaire dynamique.

Petite (grosse?) limitation : comme il s’agit de VMs, il ne sera évidemment pas possible de faire tourner des VMs de type KVM/qemu sur ces machines (sauf moyennant un hack de type nesting de VM dans une VM).

Cependant, depuis quelques temps, je n’utilise plus du tout les VMs (je n’ai pas de workload Windows) et j’utilise plutôt des containers LXC.

C’est vraiment plus léger en terme d’empreinte mémoire (je n’ai jamais été embêté côté CPU mais côté RAM, chaque Mo compte) et ça se gère (install, gestion, sauvegarde) de la même façon qu’une VM, contrairement à Docker qui nécessite une gymnastique mentale complémentaire.

Bon, on fait ça comment ?

Maintenant que j’ai posé le décor, on peut commencer le tuto. L’idée va être de :

  • Créer des VMs
  • Récupérer leurs informations (IP publique, surtout)
  • Installer les prérequis de Proxmox VE (puis les rebooter pour passer sur le kernel PVE)
  • Installer les prérequis et configurer tinc, le VPN qui va nous permettre d’initier le cluster et de laisser passer les trames multicast, nécessaires au clustering

A l’issue de ces étapes, on arrêtera là l’automatisation et on passera sur quelques (rapides) étapes manuelles.

Ok, j’avoue que c’est dommage que tout ne soit pas automatisé. Mais le gros du boulot, c’est vraiment les étapes précédentes. Pour s’en convaincre, vous pouvez lire l’article que j’avais écris pour la version 5.2 (mais avec OpenVPN) ou tout simplement lire le contenu des playbooks.

Prérequis

Et oui, il y a quand même quelques prérequis à ce tuto. Il faudra :

  • Avoir un compte sur Scaleway
  • Avoir une clé SSH, avoir la clé publique à la racine du projet, et l’appeler admin.pub
  • Installer les package pip
pip install jinja2 PyYAML paramiko cryptography packaging
  • Installer Ansible depuis les sources (>= 2.8)
  • Installer jq

J’aurai pu faire aussi un playbook pour ça, mais comme c’est très dépendant de votre distribution Linux (ou Windows ahaha), …

You token to me ?

Créez un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token sur votre machine avec Ansible :

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Puis sourcez le fichier :

source scaleway_token

A partir de maintenant, vous avez le pouvoir tout puissant du cloud au bout de vos doigts (et de votre CB) !

Générer les machines

Là, on tire totalement parti du travail de Rémy Léone et des modules Ansible pour Scaleway, intégrés au repo officiel.

On va donc utiliser le playbook create_proxmox_vms.yaml pour :

  • récupérer l’ID d’organisation du compte Scaleway (votre identifiant unique)
  • récupérer un ID d’une image disque compatible debian Stretch (de la bonne taille)
  • ajouter si nécessaire la clé SSH de l’admin dans le portail Scaleway, qui sera injectée dans vos VMs à leur création
  • créer autant de machines que nécessaire
ansible-playbook create_proxmox_vms.yml

Bon, je vous ai pas menti, c’est quand même hyper simple non ?

A noter, actuellement le script traite les demandes de création de machines séquentiellement. Pour 3 VMs, comptez environ 3 minutes.

Cependant, si vous avez un gros besoin, sachez qu’il est possible de modifier le script pour les lancer en parallèle (déjà fait dans mon repo ansible-deploy-azure sur Github) via la fonction async d’Ansible.

Mise en place de l’inventaire dynamique

J’arrête pas de vous en parler depuis tout à l’heure, normalement dans Ansible, maintenant que nos VMs sont créées, pour pouvoir nous y connecter, on devrait créer un fichier texte "inventory" contenant la liste des hôtes et de leur IP (a minima). C’est fastidieux, surtout si vous avez beaucoup de VMs.

Et là, on a juste un fichier inventory.yml, contenant le nom du plugin, la région utilisée (Paris dans mon script) et le tag des machines générées :

plugin: scaleway
regions:
  - par1
tags:
  - proxmoxve

A partir de là, on peut vérifier le retour de la commande ansible-inventory

ansible-inventory --list -i inventory.yml
{
    "_meta": {
        "hostvars": {
            "x.x.x.x": {
                "arch": "x86_64",
                "commercial_type": "DEV1-S",
                "hostname": "test3",
[...]
    "proxmoxve": {
        "hosts": [
            "x.x.x.x",
            "y.y.y.y",
            "z.z.z.z"
        ]
    }

Petite hack SSH : comme Ansible se connecte en SSH aux hôtes distants, à la première connexion on va bloquer sur l’acceptation de la fingerprint.

Un moyen de bypasser ça en une ligne de commande est d’utiliser la commande ssh-keyscan et de coller tout ça dans votre known_hosts. On peut le faire avec ce petit oneliner :

ansible-inventory --list -i inventory.yml | jq -r '.proxmoxve.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Ce n’est évidemment pas recommandé en production !!! Mais dans le cadre d’un test temporaire, vous me pardonnerez cette liberté.

Ajoutez votre clé SSH dans l’agent, puis vérifiez que vous pouvez vous connecter à tous les serveurs :

eval `ssh-agent`
ssh-add myprivate.key
ansible proxmoxve -i inventory.yml -u root -m ping
x.x.x.x | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
y.y.y.y | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
z.z.z.z | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Préparation du serveur

Ok ! Maintenant, on a 3 (ou plus) VMs Debian 9. A partir de là, j’ai créé un playbook Ansible qui suit la doc d’installation officielle de Proxmox sur un Debian Stretch.

ansible-playbook -i inventory.yml -u root proxmox_prerequisites.yml

A l’issue de l’installation, il est nécessaire de rebooter les serveurs (manuellement ou via ansible), pour passer sur le kernel de PVE.

Installation et configuration de tinc

C’est piou-piou.

Une fois que vos serveurs sont revenus à la vie, vous avez installé Proxmox. Pas mal hein ?

Cependant, chez Scaleway (et tous les autres providers que je connais), le multicast est coupé entre vos VMs. Et ça c’est la loose car tout notre clustering va passer par des trames multicast.

Pour bypasser ce souci de taille, le plus simple est de passer par un VPN, de créer un réseau privé virtuel entre toutes nos instances, qui lui ne filtrera rien.

Dans les articles précédents, j’avais utilisé OpenVPN (parce que c’est ce que je connais le mieux). Le souci d’OpenVPN c’est qu’il fonctionne sur un base client-serveur. Or, dès qu’on dépasse les 3 serveurs, on se retrouve avec 1 serveur maitre et 2 (ou plus clients), et donc un SPOF…

L’avantage avec tinc, c’est qu’on a pas cette notion de client/serveur. Tous les tincs sont connectés à tous les tincs, dans un genre de gros maillage qui nous évite donc tout SPOF.

L’installation de tinc n’est en soit pas follement complexe (cf le [playbook}(https://github.com/zwindler/ansible-proxmoxve/blob/master/tinc_installation.yml)), mais là encore, l’automatiser c’est toujours sympa.

ansible-playbook -i inventory.yml -u root tinc_installation.yml

Etapes additionnelles manuelles

Une fois que vous en êtes là, on arrive dans les tâches non triviales à automatiser.

Actuellement, il n’est pas possible de créer un cluster Proxmox VE sans avoir un mot de passe root. Or, lors de la création des VMs, Scaleway utilise notre clé SSH (ce qui est beaucoup mieux). Nous allons donc devoir nous connecter sur l’ensemble des machines et réinitialiser le mot de passe du compte root.

root@test1:~# passwd
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

Créer un cluster

Cette partie aurait pu être automatisée. Dans le tutoriel précédent, je le faisais en ligne de commandes, à cause d’une limitation dans le wizard de création de cluster. En effet, dans les précédentes versions de Proxmox, on ne pouvait pas sélectionner sur quelle interface réseau on souhaitait utiliser, et donc mon cluster ne passait pas par le VPN et les trames multicast ne passaient jamais.

Pour autant, maintenant on peut profiter du beau wizard tout neuf et le faire via la GUI :

  • Se connecter à l’UI de Proxmox avec un des noeuds (le premier, au hasard)
  • Dans Datacenter (à gauche), sélectionner Cluster puis cliquer sur "Create Cluster"
  • Donner un nom au cluster, mais surtout, donner comme adresse ring0 l’adresse VPN (10.10.10.1 si on est sur le noeud 1)
  • Une fois l’opération terminée, cliquer sur "Join Information", dans le même menu, et copier les informations en cliquant sur "Copy Information"

Joindre le cluster

  • Se connecter sur l’UI de la 2ème machine
  • Dans Datacenter, sélectionner Cluster puis cliquer sur "Join Cluster"
  • Dans le champ "Information", coller les données récupérée lors de l’étape précédente. Les informations de connexion devraient automatiquement être remplies, SAUF le Corosync ring0, qu’il faut positionner à 10.10.10.2", et le mot de passe root du noeud 1. Cliquer sur "Join".
  • Si l’opération réussie, un message doit s’afficher pour dire de recharger la page

Répéter l’opération pour les noeuds suivants (3, voire ++)

Et en attendant la même chose avec la v6, amusez vous bien 🙂

Cet article Un cluster Proxmox VE en 5 minutes avec Ansible est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/07/22/proxmox-en-5-min-ansible-tinc/feed/ 2 5088
Sortie de Proxmox VE 6.0, les nouveautés https://blog.zwindler.fr/2019/07/16/sortie-de-proxmox-ve-6-0-les-nouveautes/ https://blog.zwindler.fr/2019/07/16/sortie-de-proxmox-ve-6-0-les-nouveautes/#comments Tue, 16 Jul 2019 16:00:23 +0000 https://blog.zwindler.fr/?p=5082 Cet article Sortie de Proxmox VE 6.0, les nouveautés est apparu en premier sur Zwindler's Reflection.

]]>

Proxmox VE 6.0

Ce n’est pas la première fois que j’écris un article sur les mises à jour de Proxmox VE, une distribution Linux pour faire de la virtualisation qui me tient pas mal à cœur car très simple et très efficace. Aujourd’hui, Proxmox VE 6.0 vient de sortir !

Pour info, le blog ainsi que d’autres services fonctionnent depuis des années sur un hyperviseur Proxmox, ce qui pour moi est un exemple de stabilité et de simplicité, même dans des usecases très simples (sinon je serai passé à autre chose). M4vr0x et moi avons beaucoup écrit sur le sujet.

Mais avant ça ?

La dernière fois que j’avais écris un article sur une release de Proxmox c’était la 5.2 il y a un an, qui avait sorti pas mal de choses sympas.

Depuis, je ne vous ai pas parlé de la 5.3 et de la 5.4, quelques modifs sympas (mais que je n’ai personnellement pas utilisé).

  • Ceph Luminous LTS installable depuis la GUI (5.4)
  • Ajout d’un QDevice pour gérer le quorum dans un cluster à 2 hyperviseurs (5.4)
  • U2F dans l’interface web (5.4)
  • Nesting (faire des containers dans des containers) de containers privilégiés ou pas (5.3)
  • Emulation de VMs ARM sur hyperviseur x86_64 (5.3)

Et Proxmox VE 6.0 ???

Comme toute majeure, il faut s’attendre à pas mal de modifs.

La liste des modifications est longue comme le bras, et les ajouts sont à la fois amenés par la mise à jours des composants principaux et par des améliorations sur les composants internes.

Les composants tiers

D’abord, Proxmox VE 6.0 se base sur la toute nouvelle Debian 10.0 (aka Buster). C’est logique pour l’équipe de Proxmox de partir sur le tout dernier OS, puisque la branche 6.x va durer quelques années.

On tire donc un kernel Linux plus récent que celui PVE 5 (c’était le 4.15) et on passe sur un 5.0. De quoi tirer profit des dernières améliorations du Kernel, notamment pour le stockage (on y reviendra) et le réseau.

Ensuite, les gros composants. Proxmox VE étant une plateforme de virtualisation VM + containers, on va évidemment s’intéresser aux 2 composants qui fournissent ça, à savoir qemu et lxc ont bien évidemment droit à une mise à jour (respectivement 4.0.0 et 3.1). Pour LXC (les containers) je n’ai pas su trouver les améliorations. Pour qemu 4.0.0, on a droit à une majeure mais qui ajoute surtout la compatibilité vers de nouveaux matériels et de nouveaux flags CPU (pour des usecases bien précis).

Une plus grosse modif vient peut être de corosync, le composant qui permet de gérer une grosse partie du clustering, qui passe en version 3 avec Kronosnet. Ça, c’est très impactant. J’ai écris plusieurs articles sur le clustering de serveurs Proxmox avec des machines dédiées chez des cloud providers et j’étais souvent gêné par le fait que corosync utilise du multicast, systématiquement bloqué par les providers. Kronosnet utilise de l’unicast ce qui devrait énormément simplifier les futurs setups de clusters (AKA, plus obligatoirement besoin d’un VPN) !!!

Côté stockage, on passe de Ceph 12 vers Ceph 14 et de ZFS (on Linux) en 0.8.1 (encryption des pools + trim, support de ZFS dans l’UEFI)

Les modifs internes

Voilà pour les mises à jour de packages. Maintenant, les features que j’ai hâte de tester. La plupart sont des améliorations de la GUI :

  • Migration des VMs à chaud depuis l’interface, même si on est sur du local storage. On retrouve une promesse déjà présente en 5.x, qui marchait partiellement en ligne de commande, mais qui devrait être ENFIN disponible dans la GUI (cf ce post sur le forum).

  • Améliorations au niveau du Wizard pour créer des clusters. On peut maintenant sélectionner plus facilement quelle(s) interface(s) doit être utilisée pour la communication Corosync. Une amélioration légère par rapport à ce qu’on pouvait faire en 5.4 avec tinc (article qui n’est jamais sorti car je ne l’avais pas terminé… oups). Dans tous les cas, c’est beaucoup plus simple que ce que j’avais pu montrer en 5.2 ou en 5.0.

  • Encore des améliorations pour gérer Ceph dans la GUI. Je ne peux pas trop en parler car je n’avais pas de machines suffisament proches et puissantes pour monter un cluster Ceph sur mes machines Proxmox VE. Cependant, je pense tester dans les jours qui viennent, profitant du fait que les clusters sont plus simple à créer (donc à tester sur des machines temporaires chez Kimsufi par exemple).

  • Possibilité de configurer les backups non plus par VM/container mais par pool entier (nice to have)

Tu nous montres ?

Une fois de plus, je suis assez enthousiaste quant à cette nouvelle version, qui apporte plein de bonnes choses. Je vais très probablement faire des articles dans les semaines qui viennent sur le sujet, en premier lieu la migration de la 5.4 (sur laquelle je suis actuellement) vers la 6.0.

Wait and see !!

Sources

Cet article Sortie de Proxmox VE 6.0, les nouveautés est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/07/16/sortie-de-proxmox-ve-6-0-les-nouveautes/feed/ 12 5082
J’ai testé pour vous : l’offre Kubernetes as a service d’OVH https://blog.zwindler.fr/2019/07/09/jai-teste-pour-vous-loffre-kubernetes-as-a-service-dovh/ https://blog.zwindler.fr/2019/07/09/jai-teste-pour-vous-loffre-kubernetes-as-a-service-dovh/#comments Tue, 09 Jul 2019 11:30:50 +0000 https://blog.zwindler.fr/?p=5024 Test de l"offre Kubernetes as a Service d"OVH

Cet article J’ai testé pour vous : l’offre Kubernetes as a service d’OVH est apparu en premier sur Zwindler's Reflection.

]]>

OVH sort son offre Kubernetes managée

Vous avez peut être vu passer l’actualité début février, OVH a lancé (comme d’autres cloud providers) son offre Kubernetes as a service (KaaS).

Cette blague hilarante vous est offerte par zwindler !

Comme beaucoup de techno non triviales, une offre managée, c’est un bon moyen de mettre le pied à l’étrier si vous ne connaissez pas encore Kubernetes. C’est aussi un bon moyen pour OVH pour ne pas trop se laisser distancer par les géants américains.

En avril dernier, j’ai pu participer à un meetup dans les locaux d’OVH et de rencontrer les personnes qui avaient mis en place cette technologie. Du coup, je vous propose un petit article dans lequel on va voir ensemble à quoi ça ressemble.

Côté tarif

C’est le nerf de la guerre. Comme tous les autres (à l’exception notable d’EKS d’Amazon), vous ne payez que pour les workers, pas pour les masters (le control plane donc). Niveau tarif pour les workers, c’est simple, ce sont les tarifs applicables sur l’offre cloud public d’OVH.

La plus petite machine que vous pouvez sélectionner est un machine Linux de type B2-7, avec 2 vCPUs, 7 Go de RAM et 50 Go de SSD local.

C’est suffisant pour faire des tests, mais en production on en voudra au minimum 3, ce qui à 22€HT/mois pièce vous fera quand même environ 75€ / mois.

Au final, on est objectivement moins cher que ce que j’avais pu tester sur AKS. Car pour rappel, j’avais monté un cluster de machines de type B2ms avec 2 vCPU et 8 Go de RAM pour 30€ / mois, donc identique. SAUF que ces machines sont des machines dites "burstable" (vous n’avez qu’une portion d’un vCPU, que vous ne pouvez dépasser que pour une durée réduite avant de subir un throttling). Des machines équivalentes reviendraient sur Azure à utiliser des D2, pour un tarif de 83€TTC / mois… par machine !!!

Le fait que le control plane (les masters) ne soient pas payant est à la fois un avantage et un inconvénient. Pour OVH, je n’ai pas encore la réponse, mais lorsque j’avais testé AKS d’Azure, j’avais demandé au commercial ce qui se passait si mon control plane était HS (vu que c’est eux qui gèrent, je ne peux pas prendre la main pour le fixer). Il m’avait répondu texto : "comme c’est un produit gratuit, on ne s’engage sur aucune SLA (seulement un SLO de 2h)". De quoi refroidir quand on est habitué à avoir la main sur son cluster Kubernetes.

Et si on testait ?

Assez parlé ! Dans mon manager d’OVH, j’ai créé un nouveau projet, que j’ai nommé de manière originale "Kubernetes Project". Puis, j’ai créé un cluster Kubernetes en cliquant sur "Créer un cluster Kubernetes"

Actuellement, seul le DC "Graveline 5" semble capable d’accueillir l’offre KaaS d’OVH. Un point qu’il faudra améliorer dans le futur pour pouvoir se construire une infrastructure réellement résiliente.

Edit: Une deuxième région sera disponible dans le mois (cf Maxime Hurtrel, PM K8s chez OVH)

Niveau version de Kubernetes, bonne nouvelle, OVH s’est donné les moyens de proposer des versions très à jour de Kubernetes. Toutes les versions depuis la 1.11 jusqu’à la version 1.14 sont disponibles. La 1.14, qui n’a que quelques mois, est devenue dispo chez OVH assez rapidement. On peut imaginer que la 1.15 de Kubernetes qui vient tout juste de sortir (mi juin) sera probablement assez vite disponible aussi.

A titre de comparaison, chez Azure, ils sont assez bons dans ce domaine, et pourtant ils n’ont la 1.14 qu’en preview. Le mauvais élève Amazon est à la traîne avec seulement la 1.12 (pourtant sortie en septembre 2018).

"Ca va trop vite"

Cette partie là est relativement impressionnante. La création d’un nouveau cluster est extrêmement rapide.

Au total, l’instanciation d’un cluster met moins d’une minute, là où AKS en nécessite une 20aine (en comptant les workers certes, mais bon la moitié du temps le portal ou l’appel à l’API plante !).

Ceci est du à la façon dont le control plane a été créé et conçu par les équipes d’OVH (j’y reviendrais juste après) et est clairement une réussite. Pour avoir déployé à la main Kubernetes un paquet de fois et avec de nombreuses méthodes différentes (cf mes divers articles sur le sujet), c’est la méthode la plus rapide d’installer Kubernetes, et de loin.

L’architecture du control plane

Un des trucs sympas avec OVH, c’est qu’ils n’hésitent pas à communiquer sur les détails techniques. Certes, ils ne sont pas les seuls, mais c’est toujours agréables.

Lors du CNCF Meetup, Kevin Georges, Pierre Peronnet et Sébastien Jardin nous ont donc présenté les entrailles de leur Kubernetes as a service.

L’idée principale est que le control plane doit être le plus léger possible, pour coûter le moins cher possible à OVH (vu que c’est gratuit), tout en restant résilient.

La solution qui a été retenue pour arriver à une solution acceptable a été de déployer les services nécessaires au control plane de Kubernetes (control malanger, api server, scheduler) dans … un Kubernetes ! La seule brique non containerisée est etcd, et il s’agit ici d’un cluster dédié sur des machines physiques (ce qui explique probablement la limitation au DC Graveline).

Dans tous les cas, ça explique probablement aussi la vitesse de démarrage d’un nouveau cluster : il faut juste lancer 3 containers et zou, un nouveau cluster.

Source : OVH
https://www.ovh.com/fr/blog/kubinception-using-kubernetes-to-run-kubernetes/

L’article technique détaillant tout ça est dispo sur le site d’OVH, je n’en dis pas plus, ils l’expliquent mieux que moi.

Les workers

Pour la partie Workers, plutôt que de développer sa propre API et l’intégrer comme module du projet Kubernetes (comme les autres gros cloud providers, qui ont leur code embarqué dans celui de Kubernetes), la team chez OVH en charge du projet s’est appuyée sur de l’existant : leurs propres services OpenStack fournissent déjà l’ensemble des briques dont ils ont besoin pour créer des VMs à la volées et les intégrer à des clusters Kubernetes.

Quand j’ai demandé au Meetup combien de temps il fallait pour "poper" un nouveau worker, un des trois speakers m’a dit, tout désolé "on ne fait pas de miracles, il faut quelques minutes". Il n’a pas compris le pauvre quand j’ai éclaté de rire (parce que sur Azure, ça prend des plombes).

Ajouter des workers

La procédure est assez simple, mais se fait au travers de l’interface (comme la création du cluster). Je suis quasiment certain que tout doit pouvoir se piloter par API (je vois mal pourquoi ils auraient fait autrement pour un service tout neuf), pour autant, je n’en ai pas trouvé de trace dans la documentation officielle (pas à jour avec la nouvelle interface et encore un peu light)

Bon, alors je suis peut être mal tombé, mais quand j’ai cliqué dans l’interface pour ajouter des nodes, ça a quand même pris énormément de temps (facile 20-30 minutes). Du coup j’étais un peu (très) déçu…

Après investigation, en fait… c’est l’interface qui déconne ! En réalité, mon nœud était UP depuis longtemps déjà.

Je m’en suis rendu compte en faisant un petit kubectl get nodes et j’ai vu que mon node "Ready" depuis 28 minutes était encore marqué "En cours d’installation" …

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
vm1.12-1 Ready <none> 28m v1.12.7 51.77.204.236 <none> Container Linux by CoreOS 2135.4.0 (Rhyolite) 4.19.50-coreos-r1 docker://18.6.3

Se connecter au cluster

D’ailleurs, comment on s’y connecte ? Pas de souci de ce côté, OVH vous simplifie la vie en vous proposant de télécharger directement votre fichier kubeconfig préconfiguré, prêt à utiliser.

Si vous en avez plusieurs, pour rappel, vous pouvez utiliser le flag "–kubeconfig=kubeconfig.yml"

En vrai, un node ne met que 3 minutes à poper

Du coup, j’ai voulu retester le démarrage d’une nouvelle VM, en sachant que le temps indiqué sur l’interface web n’est pas bon.

Après quelques tests, en 3 minutes, le node apparait en "Not Ready", puis passe "Ready" au bout de quelques secondes. On est donc très proche de ce dont j’avais pu parler avec les gens d’OVH du coup, c’est très bon comme temps de boot.

Ouf, on est rassurés !

Mise à jour

Un point sympa que permettent les solutions de type KaaS est la gestion des mises à jour depuis votre interface de gestion. Mettre à jour Kubernetes, c’est pénible. La moitié du temps, on a peur de tout casser.

Alors je ne dis pas que rien ne va casser avec le Kubernetes d’OVH, mais comme l’infra est cadrée et gérée par eux, j’imagine que c’est suffisamment bien testé dans des conditions similaires aux vôtres pour être un peu plus serein le jour où ça arrive.

A noter, contrairement à AKS, vous n’avez que peu la main sur les mises à jour. Cela se limite à ça, et je n’ai pas trouver comment monter de la 1.12 à la 1.13 par exemple…

Edit: Toujours selon Maxime Hurtrel, ça devrait arriver bientôt

Conclusion : au delà du compute, l’UI

Dans les points qui déchirent : OVH sait fournir un control plane à une vitesse à faire pâlir d’envie tous les concurrents.

Cependant, cela se fait sur un cluster Kubernetes mono DC (DC5 Graveline), avec la partie etcd externalisée à part, sur un cluster mutualisé. Je ne fais pas de jugement de valeur car, contrairement à OVH qui est transparent, je n’ai pas d’info technique sur les versions proposées par la concurrence.

En revanche, je peux comparer avec un cluster que j’installe moi même, et là clairement, je suis un cran en dessous en terme de ce qui peut être fait en terme de sécurisation de mon cluster.

Pour ce qui est de l’interface, elle souffre un peu de sa jeunesse. Il n’y a rien de plus que les onglets pour créer un cluster et pour ajouter ou supprimer des nœuds (et encore, pas plus d’info sur ces nœuds que leur nom et leur taille !).

Un dernier onglet existe pour "visualiser" ses containers et ses services, mais il est pour l’instant vide et sera de toute façon probablement moins utile que le dashboard ou tout autre outil existant (sauf à fournir un énorme effort de dev sur ce point).

Encore un exemple de la jeunesse de la solution et particulièrement de son interface : OVH pope des VMs (workers) très vite, ce qui devrait être super cool et soulever les foules… mais si on teste la solution rapidement, comme l’interface ne l’indique pas, on pourrait penser que ce n’est pas le cas ! Dommage !

Edit: Le problème est connu et en cours de fix

Et pour ce qui est des mises à jour, c’est le flou total. On vous explique que tout est maintenu à jour, mais les montées de versions majeurs sur un cluster ne semble pas disponible pour l’instant.

Dans les points pas glop : aucune trace dans la doc d’API pour créer des clusters à la volée ou les gérer de manière automatisée via Ansible ou autre…

Edit: l’API est là

Bref, vous l’aurez compris, techniquement c’est une réussite. Chez OVH, ils savent gérer des VMs et des containers et ça se voit. Mais l’offre KaaS d’OVH manque peut être encore d’un petit coup de polish pour qu’on se sente bien chez soi, et pleinement en confiance. Et c’est d’autant plus rageant que la solution a plein de bons points, que le travail abattu (en peu de temps) est colossal.

Je voudrais donc tenter de terminer sur une note positive, car c’est mon ressenti au global. Pour avoir rencontré des membres de l’équipes (de vrais passionnés), j’ai envie de croire que ce produit est amené à grandir, et ses petits défauts de jeunesse à disparaitre.

A suivre donc !

Bonus GPU

Dans les petits "trucs" qui m’ont fait sourire, j’ai vu passer un tweet indiquant qu’OVH se lançait également (en alpha par contre pour l’instant) dans Kubernetes managé avec des instances baremetal avec GPU.

Je n’ai pas forcément de workload en tête, mais pour ceux qui veulent lancer des containers avec des calculs GPU, c’est une option qui peut faire sens.

Si vous voulez en savoir plus, c’est par ici :

Cet article J’ai testé pour vous : l’offre Kubernetes as a service d’OVH est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/07/09/jai-teste-pour-vous-loffre-kubernetes-as-a-service-dovh/feed/ 5 5024
PSES 2019 : Le logiciel libre a-t-il de beaux jours devant lui ? https://blog.zwindler.fr/2019/06/27/pses-2019-le-logiciel-libre-a-t-il-de-beaux-jours-devant-lui/ https://blog.zwindler.fr/2019/06/27/pses-2019-le-logiciel-libre-a-t-il-de-beaux-jours-devant-lui/#comments Thu, 27 Jun 2019 08:30:28 +0000 https://blog.zwindler.fr/?p=5037 – De barbus dans un garage jusqu’à l’ère du « tout sur Github », comment sommes-nous passés de « Linux est un cancer » à « Microsoft <3 Linux » ?– Aujourd’hui, peut-on encore maintenir du code individuellement sans « Mettre en danger des millions d’innocents » ?– Faire de l’open source fait-il de vous […]

Cet article PSES 2019 : Le logiciel libre a-t-il de beaux jours devant lui ? est apparu en premier sur Zwindler's Reflection.

]]>

PSES 2019

Pour ceux qui ne connaissent pas, Pas Sage En Seine, c’est un festival organisé sur plusieurs jours par des passionnés, créé en 2008. Historiquement, il promouvait le hacking et le logiciel libre, mais depuis quelques années, ils fais également la part belle à toutes les activités, notamment associatives. Et cette année, les talks retenus pour PSES 2019 sont très alléchants et prometteurs (programme ici)

Cette année, je peux enfin participer. Si vous y êtes aussi, n’hésitez pas à venir me parler, de tout et de rien. Ça sera avec grand plaisir de pouvoir échanger avec des gens qui ne viennent pas forcément dans ma province ;).

J’y suis … et je suis même speaker 🙂

J’ai l’immense plaisir de donner le tout premier talk (après l’introduction par le staff) de cette édition 2019 !!!

Alors, pour vous teaser un peu de quoi je vais bien pouvoir parler, voici le pitch de mon talk :

– De barbus dans un garage jusqu’à l’ère du « tout sur Github », comment sommes-nous passés de « Linux est un cancer » à « Microsoft <3 Linux » ?– Aujourd’hui, peut-on encore maintenir du code individuellement sans « Mettre en danger des millions d’innocents » ?
– Faire de l’open source fait-il de vous un ZADiste ?

Tant de sujets d’actualité (et d’autres) qui seront traités avec un regard, bien entendu, totalement objectif et impartial (ou pas !)

Le support

J’ai promis que les slides sont en lignes, alors les voici 😉

Le live

J’espère avoir le temps de vous coller aussi le lien du live dans l’article mais je ne garantie rien 😉

La vidéo si vous n’avez pas pu venir

Et j’ajouterai bien entendu le lien vers l’enregistrement vidéo, une fois que celui ci sera disponible 😉

Cet article PSES 2019 : Le logiciel libre a-t-il de beaux jours devant lui ? est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/06/27/pses-2019-le-logiciel-libre-a-t-il-de-beaux-jours-devant-lui/feed/ 3 5037
Mes stats dans Hugo sans Google Analytics (Matomo) https://blog.zwindler.fr/2019/06/18/mes-stats-de-visites-hugo-sans-google-analytics-avec-matomo/ https://blog.zwindler.fr/2019/06/18/mes-stats-de-visites-hugo-sans-google-analytics-avec-matomo/#comments Tue, 18 Jun 2019 11:45:24 +0000 https://blog.zwindler.fr/?p=5007 Comment mettre en place Matomo pour récupérer des statistiques sur les utilisateurs avec un blog statique Hugo (CentOS + nginx)

Cet article Mes stats dans Hugo sans Google Analytics (Matomo) est apparu en premier sur Zwindler's Reflection.

]]>

Matomo, pour faire quoi ?

La semaine dernière j’ai écris un article pour expliquer que j’étais en train de migrer de WordPress vers Hugo, mais que ce n’était pas si facile. D’abord, parce que WordPress fait PLEIN de choses (et c’est à la fois son avantage et son inconvénient) et notamment vous fournir des stats sur vos visiteurs. Et, vous vous en doutez, avec un site statique, on n’a pas ça. C’est là que Matomo rentrera en jeu…

Écraser une mouche avec un bulldozer

Alors OK, les statistiques fournies par Jetpack, ce n’est pas forcément un truc fou non plus.

En réalité, on pourrait se rapprocher de ce qu’on peut faire avec WordPress en terme de statistiques avec ce que j’avais fais lorsque je testais ElasticStack et en récupérant les stats de nginx.

Mais clairement, pour en arriver au même niveau de détail, il va falloir passer pas mal de temps à nettoyer les données de références (les logs nginx) et à concevoir les tableaux de bord (dans Kibana).

Au final, on pourra même aller encore plus loin, mais ça sera nécessairement très couteux en temps de développement / configuration.

Méfie-toi du côté obscur. Plus rapide, plus facile, plus séduisant

Si c’est la simplicité que l’on cherche, alors clairement, le plus facile sera probablement d’ouvrir un compte Google Analytics et d’ajouter le petit bout de code fourni clé en main.

De ce point de vue, ça sera clairement le plus simple et vous aurez à votre disposition un outil à la fois simple et puissant. Et qu’importe si Google espionne profile (un peu plus) vos utilisateurs ?

Je vais partir du principe que si vous auto-hébergez comme moi, vous n’avez pas envie de faciliter la tâche à Google. Et c’est donc pour cela que je vous propose une autre option : Matomo.

Donc on ne sait toujours pas ce que c’est que Matomo, en fait…

Pour ceux qui l’ont connu, Matomo est le successeur de Piwik (ça vous parle peut être plus, le projet a été renommé en 2018) et permet d’obtenir un outil similaire à Google Analytics, mais open source ET que vous pouvez auto-héberger.

Exit donc, Google, pour un résultat similaire et le tout chez vous.

A noter, Matomo propose également une plateforme Analytics managée (payante), qui fera office de concurrent stricto sensu à Google Analytics et a priori plus vertueux envers la vie privée de vos utilisateurs (mais je n’ai pas vérifié).

Le usecase

J’ai donc sur les bras une plateforme Hugo pour le blog, sans aucune stat. Dans mon cas, Hugo est hébergé sur une plateforme CentOS / nginx. Idéalement, j’aimerai bien pouvoir garder mon Matomo sur la même machine, pour faire simple.

Et malheureusement pour moi, la plupart des gens qui ont fait des tutos sur le net ont eux installés ça sur Ubuntu (ça c’est respectable) et souvent sur Apache HTTPd (là par contre, emoji-qui-vomi).

Installation des prérequis

C’est donc parti pour installer Matomo dans un premier temps (on verra ensuite pour Hugo). La stack technique de Matomo étant basée sur PHP/MySQL, on va devoir installer php-fpm pour le moteur PHP et MariaDB.

Et comme sur CentOS, PHP et ses dépendances datent de Mathusalem, on va faire appel une fois de plus aux répos de rémi. Encore une fois, merci à lui…

sudo yum install epel-release
sudo yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
sudo yum install yum-utils
sudo yum-config-manager --enable remi-php72

sudo yum update
sudo yum install mariadb-server nginx php-fpm php-mysql php-mbstring php-dom php-xml php-gd freetype unzip wget

Dans le cas (probable) où vous souhaitez aussi avoir une meilleure localisation de vos lecteurs/visiteurs, il faudra ajouter des modules complémentaire pour GeoIP

sudo yum install gcc php-devel

Maintenant que c’est fait, on peut démarrer php-fpm et l’activer au démarrage de la machine

sudo systemctl start php-fpm
sudo systemctl enable php-fpm

sudo systemctl start mariadb
sudo systemctl enable mariadb

As usual, quand on installe pour la première fois mariadb (ou mysql), on n’oublie surtout pas de passer le petit tool de nettoyage/sécurisation "minimal" :

mysql_secure_installation

Ok, on a un moteur de base de données utilisable maintenant. On va donc créer une base et un utilisateur dédiés à Matomo :

mysql -u root -p
mysql> CREATE DATABASE matomo;
mysql> CREATE USER 'matomo'@'localhost' IDENTIFIED BY 'myawesomepassword';
mysql> GRANT ALL ON matomo.* TO 'matomo'@'localhost';
mysql> FLUSH PRIVILEGES;
exit

Installer Matomo

On a fait le tour des prérequis. On peut maintenant installer et commencer à configurer notre Matomo. Le plus simple reste de télécharger le dernier build sur le site de matomo, et de déposer les sources dans notre "dossier root" nginx :

cd /tmp
wget https://builds.matomo.org/matomo-latest.zip
unzip matomo-latest.zip
sudo mv matomo /usr/share/nginx/html

Dans les prérequis que vous auriez peut être loupés, Matomo conseille également d’ajouter un job de nettoyage dans la crontab. Ce n’est pas nécessaire pour démarrer, mais autant faire les choses bien dès le début. Pour faire simple, j’ai créé un fichier matomo-archive dans /etc/cron.d (mais un crontab -e ferait tout aussi bien l’affaire) :

cat /etc/cron.d/matomo-archive
MAILTO="awesome@email.provider"
5 * * * * nginx /usr/bin/php /usr/share/nginx/html/matomo/console core:archive --url=https://matomo.youdomain.fr/ > /var/log/nginx/matomo.archive.log

Ensuite, je vais partir du principe que vous allez exposer votre Matomo sur Internet, donc forcément en 443, avec une génération de certificat automatique via Let’s Encrypt.

Là c’est clairement un peu plus touchy, donc si vous voulez plus de détails sur le pourquoi du comment de chaque bloc de configuration nginx, je vous renvoie au fichier d’exemple disponible sur le github de Matomo. La subtilité par rapport au fichier d’exemple est que comme nous sommes sur CentOS et pas Ubuntu, on n’utilise pas le socket unix pour accéder à php-fpm, mais le port 9000

sudo vi /etc/nginx/sites-available/matomo.yourdomain.fr.conf

server {
  listen 443 ssl http2;
  server_name matomo.yourdomain.fr;

  ssl_certificate /etc/letsencrypt/live/matomo.yourdomain.fr/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/matomo.yourdomain.fr/privkey.pem;

  index index.php;
  root /usr/share/nginx/html/matomo;

  access_log /var/log/nginx/matomo.access.log;
  error_log /var/log/nginx/matomo.error.log;

  index index.php;

  location ~ ^/(index|matomo|piwik|js/index).php {
    include fastcgi.conf; 
    fastcgi_param HTTP_PROXY "";
    fastcgi_pass 127.0.0.1:9000;
  }

  location = /plugins/HeatmapSessionRecording/configs.php {
    include fastcgi.conf;
    fastcgi_param HTTP_PROXY "";
    fastcgi_pass 127.0.0.1:9000;
  }

  location ~* ^.+\.php$ {
    deny all;
    return 403;
  }

  location / {
    try_files $uri $uri/ =404;
  }

  location ~ /(config|tmp|core|lang) {
    deny all;
    return 403; 
  }

  location ~ /\.ht {
    deny all;
    return 403;
  }

  location ~ \.(gif|ico|jpg|png|svg|js|css|htm|html|mp3|mp4|wav|ogg|avi|ttf|eot|woff|woff2|json)$ {
    allow all;
    expires 1h;
    add_header Pragma public;
    add_header Cache-Control "public";
  }

  location ~ /(libs|vendor|plugins|misc/user) {
    deny all;
    return 403;
  }

  location ~/(.*\.md|LEGALNOTICE|LICENSE) {
    default_type text/plain;
  }
}

Maintenant que notre matomo est prêt à être accéder depuis l’extérieur, n’oubliez pas de :

  • Créer le record DNS pour matomo.yourdomain.fr
  • Générer le certificat Let’s Encrypt

Activez le site en créant un lien symbolique entre sites-enabled et sites-available, vérifiez la conf et rechargez nginx

sudo ln -s /etc/nginx/sites-available/matomo.yourdomain.fr.conf /etc/nginx/sites-enabled/matomo.yourdomain.fr.conf
nginx -t
sudo systemctl reload nginx

A partir de maintenant, le site est accessible, à l’URL https://matomo.yourdomain.fr/index.php

Editer la configuration pour forcer le TLS puis redémarrer php-fpm

vi /usr/share/nginx/html/matomo/config/config.ini.php
[General]
salt = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
trusted_hosts[] = "matomo.yourdomain.fr"
trusted_hosts[] = "blog.yourdomain.fr"
force_ssl = 1

Tuner la configuration de MariaDB pour faire plaisir à Matomo

vi /etc/my.cnf
max_allowed_packet=128M

systemctl restart mariadb

Et pour finir, cette partie manque pas mal dans la doc (genre, pas documenté du tout) et me parait pourtant essentiel. Il faut compiler les modules manquants pour ajouter GeoIP 2 (libmaxminddb et MaxMind-DB-Reader-php).

wget https://github.com/maxmind/libmaxminddb/releases/download/1.3.2/libmaxminddb-1.3.2.tar.gz
tar xzf libmaxminddb-1.3.2.tar.gz &amp;&amp; cd libmaxminddb-1.3.2
./configure
make
sudo make install
sudo ldconfig

cd ..
wget https://github.com/maxmind/MaxMind-DB-Reader-php/archive/v1.4.1.tar.gz
tar xzf v1.4.1.tar.gz &amp;&amp; cd MaxMind-DB-Reader-php-1.4.1/ext
phpize
/configure
make
sudo make install
echo "extension=maxminddb.so" > /etc/php.d/30-maxminddb.ini
systemctl restart php-fpm
Tadaaaa !

Configurer Hugo pour ajouter le code Matomo

Cool ! Tout est correctement configuré dans Matomo. Maintenant, il faut terminer par ajouter le code de Hugo pour communiquer avec Matomo.

Pour se faire, on peut utiliser le projet suivant, qui agit comme un thème complémentaire et étend le code généré par Hugo pour inclure le code de Matomo

git submodule add https://github.com/holehan/hugo-components-matomo.git themes/matomo

Dans cet exemple, j’ajoute simplement « matomo » comme 2ème thème de mon blog static dans le fichier de configuration **config.toml**

theme = ["aether", "matomo"]

Et je termine par ajouter la balise suivante dans le thème que j’utilise (ici aether, donc par exemple themes/aether/layouts/partials/head.html)

{{ partial "matomo-tracking" . }}

Vie privée

Pour que tout soit vraiment terminé, il faut également ajouter la ligne suivante dans la page dédiée à la vie privée

{{ matomo-optout }}

Et voilà le travail 🙂

Cet article Mes stats dans Hugo sans Google Analytics (Matomo) est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/06/18/mes-stats-de-visites-hugo-sans-google-analytics-avec-matomo/feed/ 4 5007
Comment migrer de WordPress à Hugo https://blog.zwindler.fr/2019/06/10/comment-migrer-de-wordpress-a-hugo/ https://blog.zwindler.fr/2019/06/10/comment-migrer-de-wordpress-a-hugo/#comments Mon, 10 Jun 2019 11:35:20 +0000 https://blog.zwindler.fr/?p=4989 Cet article Comment migrer de WordPress à Hugo est apparu en premier sur Zwindler's Reflection.

]]>

Mais c’est qui ce Hugo ?

Dans la rétrospective des 9 ans / 250ème articles sur le blog, je vous ai parlé de mes futurs projets.

Une bonne partie des projets concernent le blog lui-même, en particulier abandonner WordPress et passer à un blog statique.

Car les reproches que je fais à WordPress sont nombreux :

  • Une techno d’un autre âge, d’une lenteur infernale dès qu’on commence à avoir un peu de contenu
  • Besoin de nombreux plugins pour avoir un rendu correct pour un blog tech, pour le partage, les stats, l’antispam, les protections/firewall, des jolies balises pour les bouts de code, …
  • Des sauvegardes BDD + plugins + média à paramétrer (et complexes à tester)
  • Des caches à mettre partout pour éviter que la moindre page avec quelques images mette 5 secondes à charger…
  • Gutenberg, le nouvel éditeur qui par défaut vous fait écrire sur 550 px de large (1/5ème de mon écran, à peine plus large qu’une carte de visite)

Bref, j’en ai marre

Alors je le suis dis : pourquoi j’ai un bousin infâme qui fait le café (franchement ça fait tout et n’importe quoi WordPress, du e-commerce au CV interactif) alors que moi, j’ai juste besoin d’un bidule où je peux ecrire mes bêtises, que ça soit lisible sans avoir besoin de mettre un cache en frontal et éventuellement qu’on puisse me laisser un commentaire pour me remonter une coquille (ou juste discuter) ?

En gros, un site web statique avec un bon éditeur de texte quoi…

Les sites statiques, c’est fantastique

Alors c’est sûr, on peut aussi écrire le HTML/CSS soit même. Mais bon, avoir une application pour nous mâcher le travail et n’avoir que le contenu à gérer, c’est quand même plus sympa.

Quand j’ai commencé à m’y intéresser, un nom revenait souvent : Jekyll (et Ghost encore avant). Mais je n’ai jamais sauté le pas. Mais depuis, un petit nouveau fait parler de lui. Et comme d’autres, j’ai voulu tester Hugo pour remplacer WordPress. Hugo est un moteur de blog statique écrit en Go. Il a plutôt le vent en poupe et est assez simple à prendre en main.

C’est open source donc je peux l’auto-heberger de façon pérenne (coucou les gens qui postent une vie de travail sur Medium). Mais bien plus encore que ca, le contenu, c’est juste du Markdown. On a donc un site entièrement réversible au cas où Hugo viendrait à disparaître.

La syntaxe utilisée (Markdown, je viens de le dire) est archi connue et relativement simple à prendre en main. D’ailleurs, on peut très bien utiliser des blocs Markdown avec Jetpack dans WordPress pour écrire ses articles.

Tu te moques pas un peu de nous ?

Depuis le début, je vous dis que WordPress c’est tout moisi et que Hugo ça a l’air trop cool. Mais ce site… est encore sous WordPress !

Pour être honnête, c’était plus difficile à migrer que je le pensais, d’où cet article. A date, j’ai une copie du blog en ligne sous Hugo (EDIT : Down maintenant), qui fonctionne, mais pas totalement isopérimètre en terme de fonctionnalités. Je vais donc laisser vivre en parallèle les deux versions, le temps que je fixe tout ce qui manque.

Mais en attendant, je vous propose de me suivre pour cette merveilleuse aventure : Migrer de WordPress vers Hugo.

Installation

A en croire le site, c’est hyper simple !

C’est comme toutes les docs d’installs en page principale d’un site pour un logiciel open source, c’est simple mais en fait ça marche jamais (du premier coup). Fou cette coïncidence ! ;-P

https://gohugo.io/getting-started/installing/

Prérequis

Les prérequis sont en effet plutôt simples. Sous Debian/Ubuntu :

apt-get update
apt-get upgrade
apt-get install git python-pip

pip install Pygments

On va ensuite chercher le numéro de la dernière release sur le site https://github.com/gohugoio/hugo/releases puis on la wget + dpkg -i comme des cochons :

export VER="0.54"
wget https://github.com/gohugoio/hugo/releases/download/v${VER}.0/hugo_${VER}.0_Linux-64bit.deb
dpkg -i ./hugo_0.54.0_Linux-64bit.deb

Initialiser le site

Ok, pour l’instant, ils ne nous ont pas trop menti. Ça a l’air simple. On peut initialiser un nouveau site simplement avec la commande hugo new site. Puis ensuite, on peut versionner / sauvegarder blog et tout son contenu avec un dépôt git :

mkdir hugo &amp;&amp; cd hugo
hugo new site blog.zwindler.fr
git init

Trouver un thème

Un des soucis que j’ai avec Hugo (mais avec WordPress aussi alors je suis peut-être juste quelqu’un de pénible ?), c’est de trouver un thème.

Je veux un thème de blog (mais qu’est ce que vous avez tous à faire du e-commerce avec des moteurs de blog!!!), avec une colonne centrale assez large pour que les bouts de codes/lignes de commandes soient lisibles, avec la possibilité de mettre une image en avant sur la page d’accueil.

https://themes.gohugo.io/

Personnellement, le thème qui se rapproche le plus de ce que j’ai aujourd’hui, c’est le thème aether, auquel j’ai apporté quelques modifications. Pour ajouter un thème, le plus propre est d’utiliser la encore git, via la fonctionnalité des submodules.

cd blog.zwindler.fr
git submodule add https://github.com/josephhutch/aether.git themes/aether

Je vous donne mes modifs personnelles sur ce thème (colonne centrale plus large, modification de la taille des images sur la page d’accueil) mais cette étape n’est absolument pas nécessaire.

diff ./themes/aether/assets/css/style.css.ori ./themes/aether/assets/css/style.css
25c25
< max-width: 50rem;
---
> max-width: 60rem;
165c165
< max-width: 49rem;
---
> max-width: 59rem;
419,420c419,421
< height: 100%;
< width: 15em;
---
> height: 83%;
> padding: 1.5em 0em;
> width: 20em;

Configurer le site

Maintenant qu’on a initialisé le site et choisi un thème, on peut commencer à configurer le site et le thème. En effet, de nombreux paramètres dépendent du thème que vous aurez choisi et des fonctionnalités qu’il intègre. Je ne peux donc que vous donner un exemple :

Dans le fichier config.toml à la racine du site, voici ce qui a été paramétré

baseURL = "https://blog.zwindler.fr/"
languageCode = "fr-fr"
title = "Zwindler's Reflection"
theme = "aether"
disqusShortname = "zwindler"
[params]
brand = "Zwindler's Reflection"
description = "Ma vie parmi les lol-cats || Je mine des bitcoins dans mon garage"
homeimg = "./wp-content/uploads/2019/05/servers.jpg"

De plus, pour ajouter la coloration syntaxique sur les partions de code, il faut ajouter dans la conf les deux paramètres suivants :

pygmentsCodefences = true
pygmentsStyle = "pygments"

Puis lancer la commande suivante :

hugo gen chromastyles --style=monokai > themes/aether/assets/css/syntax.css

Extraire les données de WordPress

OK ! Notre site est paramétré. Si vous êtes sur cet article simplement pour découvrir Hugo, vous avez déjà un blog fonctionnel. Il ne reste plus qu’à écrire du contenu et générer le code statique.

cependant, dans mon cas, j’ai parlé depuis le début de migrer depuis WordPress. Je pars donc du principe que, comme moi, vous avez de nombreux articles (et éventuellement commentaires) que vous souhaitez conserver. Il serait dommage de devoir repartir de 0.

Heureusement, il est possible de récupérer les données existantes d’un WordPress pour les réimporter dans Hugo. Le site officiel liste les options possibles et notamment un plugin qui converti les articles (et éventuellement les commentaires sous les articles) en Markdown.

Tout simplement (enfin… n’exagérons rien).

wordpress-to-hugo-exporter

Je suis donc parti sur le projet wordpress-to-hugo-exporter, qui est une extension native à WordPress permettant de réaliser cet export "en un clic".

La première chose à faire pour installer cette extension est de vérifier que votre serveur qui héberge le WordPress dispose bien de l’extension PHP zip.so.

Si c’est bien le cas, on peut cloner le projet git directement dans le dossier plugin de WordPress

cat /etc/php.d/40-zip.ini
; Enable ZIP extension module
extension=zip.so

cd /var/www/html/wp-content/plugins/
git clone https://github.com/SchumacherFM/wordpress-to-hugo-exporter

Il nous faut plus de ziggourats RAM

Ça arrive tout le temps… Il n’est pas rare que les processus de ce genre (export/import/package de sauvegarde) nécessitent une grande quantité de RAM. J’avais déjà eu le souci avec Xwiki, je savais à quoi m’attendre ici.

Si vous aussi vous avez comme moi pas mal de contenu (250 articles, 500 Mo de media), sachez que vous devrez probablement augmenter les tailles mémoires autorisées par WordPress dans le fichier wp-config.php.

// Set initial default constants including WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, WP_DEBUG, SCRIPT_DEBUG, WP_CONTENT_DIR and WP_CACHE.
wp_initial_constants();
define( 'WP_MEMORY_LIMIT', '2048M' );
define( 'WP_MAX_MEMORY_LIMIT', '2048M' );

De même, le temps que le processus d’export arrive à son terme, votre page web sera peut être partie en timeout. Deux possibilités dans ce cas.

Soit vous exécutez l’export depuis la ligne de commande

cd wp-content/plugins/wordpress-to-hugo-exporter/

This is your file!
/tmp/wp-hugo.zip

php hugo-export-cli.php
#ou pour s'affranchir des limites RAM en même temps
php hugo-export-cli.php memory_limit=-1

Dans tous les cas, vous devriez finir par obtenir un ZIP, contenant tous vos articles et toutes vos pages, au format Markdown. Le contenu de ce ZIP est à déposer dans le sous dossier content de votre arborescence de blog Hugo :

unzip wp-hugo.zip
cd hugo-export
cp -r posts wp-content ~/hugo/blog.zwindler.fr/content/

Nettoyage du markdown

Ca y est ? On peut générer le site statique maintenant ?

Et bien non… pas encore. En fait, le processus d’export de WordPress vers Markdown n’est pas parfait.

J’ai du "nettoyer" le code Markdown pour que le résultat soit enfin acceptable.

La première chose, difficilement compréhensible, est que s’il y a bien les données correspondant à l’image "mise en avant" pour chacun de nos article, le nom de la variable est featured_image alors qu’Hugo attend le nom featuredImage.

On peut régler ça avec un bête "sed"

find . -name "*.md" -exec sed -i "s/featured_image/featuredImage/g" {} \;

Par défaut, toutes les images de wordpress sont réduites dans plusieurs tailles, pour optimiser les temps de chargement. Cependant, dans l’export, on se retrouver avec des vignettes très petites, difficilement lisibles.

Pour me simplifier la vie, j’ai utilisé cette commande pour remettre les images en taille complète. Attention cependant, cela peut avoir un impact important sur les temps de chargement des pages si vous avez de très grandes images…

find . -name "*.md" -exec sed -i 's/-220x162//g' {} \;

Un des problèmes que j’ai avec l’éditeur de WordPress, c’est justement qu’il réencode tous les caractères spéciaux avec leurs codes HTML. D’un point de vue lecture de texte simple, ça ne pose souvent pas de problème. Cependant pour tout ce qui est scripts et bouts de code, ça génère très souvent des erreurs.

Voici une liste des caractères que j’ai remplacés dans mon Markdown. Attention cependant, il pourrait que cela remplace des caractères spéciaux que vous auriez légitimement (pour une raison qui m’échappe) encodé en HTML.

find . -name "*.md" -exec sed -i "s/>/>/g" {} \;
find . -name "*.md" -exec sed -i "s/</</g" {} \;
find . -name "*.md" -exec sed -i "s/&amp;/&amp;/g" {} \;
find . -name "*.md" -exec sed -ie "s/ /\n/g" {} \;
find . -name "*.md" -exec sed -i "s/–/–/g" {} \;
find . -name "*.md" -exec sed -i "s/—/—/g" {} \;
find . -name "*.md" -exec sed -i "s/…/…/g" {} \;
find . -name "*.md" -exec sed -i "s/″/″/g" {} \;
find . -name "*.md" -exec sed -i "s/′/″/g" {} \;
find . -name "*.md" -exec sed -i "s/«/«/g" {} \;
find . -name "*.md" -exec sed -i "s/»/»/g" {} \;
find . -name "*.md" -exec sed -i "s/’/’/g" {} \;
find . -name "*.md" -exec sed -i "s/‘/‘/g" {} \;

J’ai aussi trouvé les caractères suivants, que je n’ai pas osé réencoder de peur de casser des URLs :

  • &#038
  • &#039
  • &quot;
  • &#8217;

Et pour finir, dans WordPress, j’utilisais dans WordPress un plugin qui entourait mes bouts de code de balises HTML pre pour afficher du code avec la coloration syntaxique.

Dans Hugo, les balises sont celle de markdown. Voici donc la commande pour convertir les balises pre en balise de code Markdown

find . -name "*.md" -exec sed -ie "s/<pre.*>/\n\`\`\`\n/g" {} \;
find . -name "*.md" -exec sed -ie "s/<\/pre>/\n\`\`\`\n/g" {} \;

Tester le blog

Voila !!! Vous pouvez enfin tester votre blog, avec votre contenu Markdown. Hugo propose un serveur web que vous pouvez utiliser localement pour vous assurer que tout vas bien avant d’uploader votre site statique.

Il n’est évidement pas question d’utiliser ce mode en production. Il s’agit seulement d’un mode "preview".

$ hugo server

                   |  EN    
+------------------+-------+
  Pages            |  2634  
  Paginator pages  |   231  
  Non-page files   | 10951  
  Static files     |    73  
  Processed images |     0  
  Aliases          |  1187  
  Sitemaps         |     1  
  Cleaned          |     0  

Total in 7694 ms
Watching for changes in /home/zwindler/hugo/blog.zwindler.fr/{content,data,layouts,static,themes}
Watching for config changes in /home/zwindler/hugo/blog.zwindler.fr/config.toml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Sauvegarder/générer/déployer le site

Si après vérification, votre blog vous convient, vous n’avez alors plus qu’à "sauvegarder" votre site via git.

Vous pouvez ensuite générer le site statique en invoquant simplement la commande hugo

$ hugo

                   |  EN    
+------------------+-------+
  Pages            |  2634  
  Paginator pages  |   231  
  Non-page files   | 10951  
  Static files     |    73  
  Processed images |     0  
  Aliases          |  1187  
  Sitemaps         |     1  
  Cleaned          |     0  

Total in 5555 ms

Les pages statiques seront générées et sauvegardées dans le sous dossier public. Vous pourrez enfin simplement copier ce dossier sur n’importe quel serveur web (voire même des blobs sur un cloud provider) et vous aurez votre site statique !!!

Enjoy !

Cet article Comment migrer de WordPress à Hugo est apparu en premier sur Zwindler's Reflection.

]]>
https://blog.zwindler.fr/2019/06/10/comment-migrer-de-wordpress-a-hugo/feed/ 13 4989