Bonne nouvelle pour les retardataires, il est encore temps pour s’enregistre pour participer à la Build.

Cela se passe ici : https://register.build.microsoft.com/

Ensuite pour profiter de la Build, il faudra se connecter ici : https://mybuild.microsoft.com/

Pour rappel, la Build 2020 a lieu du 19 au 20 exclusivement en ligne.

Actuellement, quand j’entends parler DevOps je suis choqué. Nombre de personnes se sont approprié le DevOps sans le comprendre. DevOps est devenu un de ces buzzwords qu’il faut utiliser et qu’il convient de placer dans une conversation. Une sorte de nouveau « Web 2.0 » qui succède à l’infâme « Agile ».

Oui « Agile » est devenu la nouvelle ambulance sur laquelle il faut tirer (du fait de l’avoir mal utilisé). DevOps c’est bien, Agile c’est nul.

Ce qui démontre que certains n’ont pas compris l’agilité et qu’ils ne comprendront peut-être pas mieux le DevOps. Si vous rencontrez une personne qui critique l’agilité au profit du DevOps, fuyez !

Au-delà du buzzword, il y a deux sujets qui nuisent au DevOps :

• La manière de parler des outils DevOps
• La création du rôle / poste de DevOps.

Prenons le temps de développer ces deux sujets, d’analyser le pourquoi, le comment, et de les rectifier.

Depuis septembre 2018, Kubic utiliser CRI-O comme runtime par défaut https://kubic.opensuse.org/blog/2018-09-17-crio-default/

Kubic est une distribution Linux basée sur Open Suse. Outre le fait de faciliter les déploiements de clusters Kubernetes, elle utilise un certain nombre de solutions très intéressantes dans un contexte professionnel. Par exemple sa possibilité d’effectuer les installations et mises à jour sous forme de transactions (en cas d’erreur, aucune opération n’est conservée sur le disque dur).

Contrairement à ce qu’indique la documentation, l’utilisation de Docker ne passe pas directement pas la désinstallation des packages d’intégration de CRI-O. Cette approche induit des erreurs et complique ensuite l’utilisation de kubeadm.

Installer une machine virtuelle Linux et la cloner n’a rien de sorcier. Tout du moins de premier abord.

La problématique du clonage

Si vous demandez à un administrateur Linux, il vous dira qu’il suffit de copier la VM et le tour est joué. Si en plus il a de grosses ouillères, il ajoutera que sous Linux il n’y a pas de notion de sysprep, car Linux n’en a pas besoin.

Mais c’est là que le bât blesse. En fonction de la solution DevOps à laquelle vous destinez votre VM Linux, il y aura besoin que ces VM soient différenciables. Le plus souvent, l’outil s’appuiera sur des id générés ou récupérés par Linux lors de la détection de ses matériels (Carte mère, Cartes réseau, Disque dur, ...).

Par exemple, Kubernetes s’appuie sur :

• L’adresse MAC de la carte réseau.
• Le product_uuid, déterminé par la carte mère.

Kubernetes 1.18 étant distribué depuis peu, toutes les distributions Linux ne sont pas forcément prêtes. Certains outils comme Kubeadm peuvent poser problème.

Par exemple, sur la variante Kubic d’Open Suse, j’ai eu le message suivant lors de l’utilisation de la commande kubeadm init.

WARNING: kubeadm cannot validate component configs for API groups
[kubelet.config.k8s.io kubeproxy.config.k8s.io]
[init] Using Kubernetes version: v1.17.2
[preflight] Running pre-flight checks
error execution phase preflight: [preflight] Some fatal errors occurred:
        [ERROR KubeletVersion]: the kubelet version is higher than the control plane version. This is not a supported version skew and may lead to a malfunctional cluster. Kubelet version: "1.18.0" Control plane version: "1.17.2"
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher

Heureusement, Kubeadm est très versatile et on peut lui indiquer la version de k8s ciblée. Pour cibler Kubernetes 1.18, il faut utiliser la commande suivante :

kubeadm init --kubernetes-version=v1.18.0