Depuis l’année dernière, ESENS à commencé l’adoption de Gitpod, un fournisseur d’environnements de développement dans le Cloud.

Qu’on soit clair : on en est plutôt fans. On l’utilise pour faire passer nos entretiens, pour nos développements internes, ainsi que pour nos live coding et séances de coaching.

Nous tentons même l’expérience de développer uniquement à partir de Chromebooks depuis Gitpod.

Gitpod n’est pas parfait cela dit et il existe plusieurs pain points comme l’authentification OAuth 2 auprès de fournisseurs d’identité n’acceptant pas les wildcards. Imaginez devoir éditer les URLs de redirection autorisées de votre configuration, à chaque fois que vous créez un nouveau workspace.

Le problème

Car en effet, les environnements Gitpod sont des environnements temporaires et il vous arrivera souvent de démarrer de nouveaux environnements.

Si vous souhaitez accéder à vos dépendances ou bases de données hébergées sur GCP, vous aurez alors besoin de vous connecter via la Google CLI à chaque création de workspace Gitpod, et le processus d’authentification à Google Cloud Platform au sein d’un environnement Gitpod n’est pas des plus pratiques puisque il doit se faire en 4 étapes :

• - Exécuter la commande gcloud auth application-default login sur votre environnement Gitpod
• - Exécuter la commande fournie en retour sur une machine disposant de la CLI Google Cloud
• - Vous connecter à votre compte Google depuis Chrome
• - Copier le résultat de la CLI Google Cloud de votre machine dans votre environnement Gitpod

Si vous devez comme moi passer une partie de votre temps à valider des Pull Requests, cela devient très vite chronophage.

La solution

Si on regarde de plus près notre commande de login, cette dernière vient créer un fichier application_default_credentials.json, contenant les informations de connexion client_id , client_secret et refresh_token , ainsi que le type d’authentification.

Si nous pouvons recréer ce fichier à chaque création d’un nouvel environnement Gitpod, nous devrions donc réduire grandement le nombre de fois que nous aurons à nous reconnecter.

Heureusement, Gitpod met à disposition un système permettant de stocker des variables d’environnement au niveau de votre profil utilisateur.

A l’aide de la commande gp env , nous pouvons donc enregistrer nos variables :

Par défaut, ces variables ont un scope correspondant au projet GitHub sur lequel elles ont été créées.

Si vous souhaitez pouvoir les utiliser sur vos autres projets, vous allez donc devoir venir modifier le scope depuis vos paramètres Gitpod :

J’ai par exemple ici défini que mes paramètres d’authentification à GCP ne seront utilisables que sur les projets de l’organisation GitHub esensconsulting. Si je le souhaitais, je pourrais également rajouter les mêmes variables sur des scopes différents pour utiliser d’autres comptes sur d’autres organisations.

Maintenant que vos variables sont enregistrées, il ne vous reste plus qu’à configurer vos environnements Gitpod pour qu’ils récupèrent ces variables et créé au démarrage le fichier application_default_credentials.json qui vous permettra d’être authentifiés :

Voilà, désormais, à chaque fois que vous ouvrirez votre workspace, vous serez automatiquement authentifié à GCP et pourrez exécuter vos commandes directement.

------------------------------

Article rédigé par Manu, Tech Lead Full Stack et membre de la DT ESENS.

Retrouvez tous nos articles tech sur le Blog ESENS !

Vous êtes à la recherche d’un nouveau challenge technique ? Découvrez la dream team et rejoignez-nous en postulant à nos offres d’emploi !