Ce post fait écho à un article très intéressant publié sur develpppez.com : Plus de 75% des vulnérabilités dans les projets open source résident dans des dépendances indirectes.

Celui-ci souligne l'impact que peuvent avoir les dépendances d'un projet sur la sécurité de nos applications. Avec un gros accent sur Javascript et l'outillage Node.js. Je vous proprose d'aborder ici le volet RGPD de ce sujet.

Hier, j’ai été récompensé par Microsoft qui m’a décerné un nouveau MVP Award. Cela fait toujours son petit effet quand on reçoit ce genre de nouvelle de Microsoft. C’est un très grand honneur.

J’en profite pour remercier Microsoft, la communauté des développeurs et l’ensemble des MVP avec qui j’ai eu le plaisir d’échanger cette année.

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.