Depuis son lancement, Visual Studio Code (VS Code) est souvent mis en avant par Microsoft. Lors de la Build 2020 certain on eut l’impression qu’il n’y en avait que pour lui. Lors de celle-ci Microsoft a pourtant beaucoup parlé de Visual Studio 2019 et de ses nouveautés.

Aujourd’hui, il faut bien comprendre que Visual Studio et VS Code sont deux produits indépendants. Les deux ont vocation à exister à et durer dans le temps.

On entend parfois dire que VS Code ne cible pas le même public que Visual Studio. Certains conseillent même aux développeurs utilisant Visual Studio de passer leur chemin. Je ne suis pas du tout du même avis. Les deux peuvent servir à un même développeur.

L’idée de cet article n’est pas de comparer les deux produits, mais d’indiquer ce que VS Code peut offrir à des développeurs quand il est utilisé conjointement à Visual Studio.

Voici donc une liste de quelques avantages du couple Visual Studio + VS Code.

Ces derniers mois, j’ai beaucoup joué avec le couple Windows Server + Linux afin de voir jusqu’où un développeur pouvait aller en 2020. Je n’ai pas été dessus. On est bien loin de ce que l’on pouvait faire en 1998 (date de mes premiers pas avec Linux).

Aujourd’hui, je vous propose un petit retour de ce qu’il est possible de faire avec Kubernetes (v1.18.2) pour faire persister des conteneurs sur Windows Server.

Mon Lab de tests Hyper-V est constitué de deux hôtes et des VM suivantes :

• 2 Master Kubernetes (Kubic, 2 CPU et 3Gb de RAM chacun)
• 2 Nodes Kubernetes (Kubic, 4 CPU et 8Gb de RAM chacun)
• 2 Load balancer (OpenSuse, 2 CPU et 1Gb de RAM chacun)
• 1 Serveur de fichier Windows (Windows 2019, 2 CPU et 2Gb de RAM), NFS et SMB sur NTFS et ReFS.
• 1 Serveur de fichier Linux (OpenSuse, 2 CPU et 2Gb de RAM) NFS sur BTRFS.

Toutes les applications, et OS sont utilisés dans leurs dernières versions (patch compris).

Le serveur de fichier Linux a été monté pour confirmer les tests effectués avec le serveur Windows. Les VM Linux font partie du même domaine Active Directory que le serveur de fichier Windows.

Avoir des namespace est une bonne pratique incontournable de Kubernetes. Si vous n’en utilisez pas, votre cluster va vite devenir un plat de spaghettis indémêlables.

Malheureusement, nombre d’applications déployables avec Helm n’ont pas de namespace défini. Mails Helm dispose d’options pour pallier à cela.

Seul hic, il y a des rumeurs infondées sur l’usage de Helm :

• Azure Kuberntes Service (AKS) aurait des limitations qui empêcheraient d’utiliser pleinement Helm et Kubernetes.
• Helm ne serait pas en mesure de créer/gérer un namespace.

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.