Dans cet article, nous allons nous pencher sur les aspects réseaux d’Azure Kubernetes Services. En effet, il n’est pas aisé...
14 juin 2022
Read this post in English
Le poste de travail hybride
Dans le cadre de nos contenus autour de l’hybridation, nous vous proposons aujourd’hui de nous intéresser au poste de travail hybride. Le poste de travail hybride utilise des technologies comme les conteneurs et le Cloud pour étendre le poste de travail et permettre de créer des environnements projet à la demande sans interaction avec la configuration locale du poste. Nous vous proposons notamment une démo sur l’utilisation de VSCode pour montrer que mettre en œuvre cette façon de travailler est extrêmement simple. Tous les outils existent.
État des lieux sur le poste de travail
Alors que nous avons à peu près réussi à maîtriser la configuration de nos environnements de production, il reste encore un endroit où contrôler la configuration reste un défi : le poste de travail du développeur/se.
Par sa nature, le poste de travail est complexe à maintenir :
- Mise à jour des OS ;
- Mise à jour (ou pas) des outils de développements ;
- Besoin de services, comme des bases de données ;
- Versions incompatibles de certains logiciels en fonction des projets.
Chaque développeur/se doit alors jongler entre les différentes versions, savoir quand mettre à jour, pour essayer de garder un environnement de travail compatible sur tous les projets sur lesquels il ou elle travaille.
Ces choix individuels vont impacter l’expérience de développement de l’équipe et parfois faire que des changements mineurs de version génèrent des changements de comportement majeurs. Et on se retrouve finalement avec une équipe dont chaque membre a une configuration unique, bien loin des versions contrôlées de la production.
Tous les types de projets sont concernés, des projets de développements jusqu’aux projets d’infrastructure Cloud où plus personne ne peut déployer quand le petit nouveau de l’équipe a mis à jour les états Terraform avec une version supérieure que celle que l’équipe avait décidée (ceci est un exemple, pas complétement imaginaire).
On pourrait se dire que le fait que nous soyons administrateurs de nos postes est l’origine du problème ; je pense que cela serait pire sans. Nous serions bloqués dans des versions obsolètes de nos outils sans possibilité de changer de façon coordonnée sur toute l’équipe.
Comme nous l’avons évoqué au début de cet article, nous avons réussi à régler ce problème sur nos environnements de production petit à petit. La version la plus aboutie actuellement est le conteneur : une fusion de notre code métier et de son environnement. Voyons comment capitaliser cela sur notre poste de travail.
Conteneur et poste de travail
Pour reproduire en partie certaines démos, il vous faudra :
- un ordinateur, quel que soit son OS ;
- Docker installé ;
- Visual Studio Code et les extensions « Remote ».
On remarque déjà que la configuration n’est pas très compliquée à gérer. Par ailleurs, VSCode va tout mettre à jour automatiquement. L’autre avantage du conteneur est de pouvoir faire abstraction du type d’OS du poste de travail, du moment que les outils de développements sont disponibles.
Pour commencer, j’ouvre VSCode dans un dossier vide. Je vais ensuite demander à VSCode de me créer un conteneur associé à ce dossier. La documentation de VSCode est assez claire pour pouvoir démarrer de zéro, mais VSCode vient avec des modèles déjà faits et l’on ne va pas se priver de les utiliser.
Je vais choisir celui pour du développement .net /C# mais juste celui avec C#. D’autres images sont disponibles avec SQL Server ou Postgresql : VSCode supporte ces images grâce « Docker Compose ». Dans ce cas précis, votre environnement de développement vient aussi avec d’autres services qui tournent dans d’autres conteneurs. Vous pouvez complètement simuler un écosystème applicatif sans installer de serveur sur votre poste. Nous y reviendrons à la fin de l’article.
Au moment de la configuration, je dois maintenant choisir la version de .Net ainsi que d’autres composants.
Regardons ce que VSCode a fait pour nous :
Un dossier « .devcontainer » a été ajouté. Il contient le paramétrage de l’image ainsi que celui de VSCode. En effet, le comportement de VSCode peut être adapté à l’image, comme définir une liste d’extensions nécessaires pour travailler. Nous voyons ici que dans la liste des extensions, il y a celle pour C# :
De cette façon, votre projet contient aussi tous les outils (extensions VSCode) dont votre équipe aura besoin pour travailler.
Une fois le conteneur démarré, vous pouvez ouvrir une invite de commande et créer votre projet. Pour la démo, nous allons créer une simple console :
dotnet new console -n demo
Travailler sur le web
L’autre avantage de VSCode est de pouvoir fonctionner dans un navigateur. Poussons maintenant notre projet sur GitHub. Si vous avez la possibilité de créer des environnements « codespaces », voici ce que vous pouvez voir :
Une fois chargé, nous avons accès via un navigateur à un environnement de travail complet : même IDE, mêmes extensions. GitHub a provisionné une machine pour nous.
Dans ce mode, le conteneur est piloté par GitHub, jusqu’à l’IDE. Plus besoin ici de configuration locale. Il est aussi possible d’utiliser ce mode avec un VSCode sur notre poste de travail :
GitHub n’est pas le seul acteur du logiciel permettant ce genre de fonctionnement. Il y a aussi Gitpod, spécialisé dans le poste de travail dématérialisé, et les outils de la société Jetbrains avec Spaces & Gateway.
Avec leur nouveau produit « Gateway », il est maintenant possible simplement sur Spaces et Gitpod d’avoir un environnement de travail virtualisé utilisable facilement avec les outils tels que Intellij, Rider… Il est possible de répliquer la même chose avec un conteneur local, mais cela demande un peu plus de travail et une configuration spécifique (Java et serveur SSH entre autres).
Un environnement de travail complet jusqu’aux services
Lorsque j’ai créé un environnement de travail au tout début de cet article, j’avais la possibilité de créer un environnement avec SQL Server ou PostgreSQL. C’est plus souvent ce cas qui se produit : l’application a besoin de dépendances comme des services de bases de données pour travailler. Et configurer son poste de travail veut aussi dire avoir ces services disponibles, soit en local, soit à distance.
Créons un projet C# avec SQL Server. Nous voyons un fichier supplémentaire dans le dossier « .devcontainer » : le fichier docker-compose.yml.
Ce fichier permet à Docker de décrire l’ensemble des conteneurs dont il a besoin pour créer son environnement. Ici, il y en a deux : celui pour le développement, nommé « app » ; et celui avec la base de données « db » :
Dans la console Docker, nous voyons bien les 2 conteneurs :
Il y a la possibilité, via les « forwarded ports », de se connecter directement depuis les conteneurs aux outils installés sur le poste de travail et donc d’interagir directement avec ces services.
Les conteneurs, une alternative à l’environnement de travail local
Les conteneurs sont des alternatives viables à l’environnement de travail local, encore faut-il que les outils de développement les supportent. C’est plus complexe pour les langages qui nécessitent des IDEs évolués, car ils ne prennent pas encore forcément en charge ce genre d’environnement. Mais pour tous les autres cas, si VSCode est l’IDE de prédilection, c’est presque naturel de travailler de cette façon que sur votre poste directement. Il a bien une légère perte de performance sur certaines opérations, mais la configuration centralisée apporte beaucoup plus d’avantages que ce désagrément.
Vous souhaitez en savoir plus sur l’hybridation ? Retrouvez l’ensemble de nos contenus sur le sujet :
