Architecture des extensions

Les extensions sont des applications qui s'exécutent à l'intérieur de Docker Desktop. Elles sont packagées comme des images Docker, distribuées via Docker Hub, et installées par les utilisateurs soit via le Marketplace dans le tableau de bord Docker Desktop soit via la CLI Docker Extensions.

Les extensions peuvent être composées de trois composants (optionnels) :

• Un frontend (ou Interface Utilisateur) : Une application web affichée dans un onglet du tableau de bord dans Docker Desktop
• Un backend : Un ou plusieurs services conteneurisés s'exécutant dans la VM Docker Desktop
• Des exécutables : Scripts shell ou binaires que Docker Desktop copie sur l'hôte lors de l'installation de l'extension

Une extension n'a pas nécessairement besoin d'avoir tous ces composants, mais au moins un d'entre eux selon les fonctionnalités de l'extension. Pour configurer et exécuter ces composants, Docker Desktop utilise un fichier metadata.json. Voir la section métadonnées pour plus de détails.

Le frontend

Le frontend est essentiellement une application web faite de HTML, Javascript et CSS. Il peut être construit avec un simple fichier HTML, du Javascript vanilla ou tout framework frontend, comme React ou Vue.js.

Quand Docker Desktop installe l'extension, il extrait le dossier UI de l'image d'extension, comme défini par la section ui dans le metadata.json. Voir la section métadonnées ui pour plus de détails.

Chaque fois que les utilisateurs cliquent sur l'onglet Extensions, Docker Desktop initialise l'UI de l'extension comme si c'était la première fois. Quand ils naviguent loin de l'onglet, l'UI elle-même et tous les sous-processus lancés par elle (s'il y en a) sont terminés.

Le frontend peut invoquer les commandes docker, communiquer avec le backend de l'extension, ou invoquer les exécutables d'extension déployés sur l'hôte, via le SDK Extensions.

Tip

Le docker extension init génère une extension basée sur React. Mais vous pouvez toujours l'utiliser comme point de départ pour votre propre extension et utiliser tout autre framework frontend, comme Vue, Angular, Svelte, etc. ou même rester avec du Javascript vanilla.

En savoir plus sur la construction d'un frontend pour votre extension.

Le backend

Aux côtés d'une application frontend, les extensions peuvent également contenir un ou plusieurs services backend. Dans la plupart des cas, l'Extension n'a pas besoin d'un backend, et les fonctionnalités peuvent être implémentées simplement en invoquant les commandes docker via le SDK. Cependant, il y a des cas où une extension nécessite un service backend, par exemple :

• Pour exécuter des processus de longue durée qui doivent survivre au frontend
• Pour stocker des données dans une base de données locale et les servir avec une API REST
• Pour stocker l'état de l'extension, comme quand un bouton démarre un processus de longue durée, afin que si vous naviguez loin de l'extension et revenez, le frontend puisse reprendre là où il s'est arrêté
• Pour accéder à des ressources spécifiques dans la VM Docker Desktop, par exemple en montant des dossiers dans le fichier compose

Tip

Le docker extension init génère un backend Go. Mais vous pouvez toujours l'utiliser comme point de départ pour votre propre extension et utiliser tout autre langage comme Node.js, Python, Java, .Net, ou tout autre langage et framework.

Habituellement, le backend est composé d'un conteneur qui s'exécute dans la VM Docker Desktop. En interne, Docker Desktop crée un projet Docker Compose, crée le conteneur à partir de l'option image de la section vm du metadata.json, et l'attache au projet Compose. Voir la section métadonnées ui pour plus de détails.

Dans certains cas, un fichier compose.yaml peut être utilisé à la place d'une image. C'est utile quand le conteneur backend a besoin d'options plus spécifiques, comme monter des volumes ou demander des capacités qui ne peuvent pas être exprimées simplement avec une image Docker. Le fichier compose.yaml peut également être utilisé pour ajouter plusieurs conteneurs nécessaires à l'extension, comme une base de données ou un courtier de messages. Notez que, si le fichier Compose définit plusieurs services, le SDK ne peut contacter que le premier d'entre eux.

Note

Dans certains cas, il est utile d'interagir également avec le moteur Docker depuis le backend. Voir Comment utiliser le socket Docker depuis le backend.

Pour communiquer avec le backend, le SDK Extension fournit des fonctions pour faire des requêtes GET, POST, PUT, HEAD, et DELETE depuis le frontend. Sous le capot, la communication se fait via un socket ou un pipe nommé, selon le système d'exploitation. Si le backend écoutait sur un port, il serait difficile d'éviter les collisions avec d'autres applications s'exécutant sur l'hôte ou dans un conteneur déjà. De plus, certains utilisateurs exécutent Docker Desktop dans des environnements contraints où ils ne peuvent pas ouvrir de ports sur leurs machines.

Finalement, le backend peut être construit avec n'importe quelle technologie, tant qu'il peut s'exécuter dans un conteneur et écouter sur un socket.

En savoir plus sur l' ajout d'un backend à votre extension.

Les exécutables

En plus du frontend et du backend, les extensions peuvent également contenir des exécutables. Les exécutables sont des binaires ou des scripts shell qui sont installés sur l'hôte quand l'extension est installée. Le frontend peut les invoquer avec le SDK extension.

Ces exécutables sont utiles quand l'extension a besoin d'interagir avec un outil CLI tiers, comme AWS, kubectl, etc. Livrer ces exécutables avec l'extension assure que l'outil CLI est toujours disponible, à la bonne version, sur la machine des utilisateurs.

Quand Docker Desktop installe l'extension, il copie les exécutables sur l'hôte comme défini par la section host dans le metadata.json. Voir la section métadonnées ui pour plus de détails.

Cependant, puisqu'ils sont exécutés sur la machine des utilisateurs, ils doivent être disponibles pour la plateforme sur laquelle ils s'exécutent. Par exemple, si vous voulez livrer l'exécutable kubectl, vous devez fournir une version différente pour Windows, Mac, et Linux. Les images multi-arch devront également inclure des binaires construits pour la bonne architecture (AMD / ARM)

Voir la section métadonnées host pour plus de détails.

Apprenez comment invoquer les binaires host.