Faire le Projet GL sur une machine personnelle

Si vous souhaitez vous retrouver dans un environnement identique à celui des PC de l’école, il est possible de télécharger l’image pour machine virtuelle depuis le site intranet de l’école. Attention : cette image est très lourde. Une autre solution consiste à utiliser Docker qui peut être vu comme une solution de virtualisation légère. Docker est disponible sous Linux (son environnement de prédilection) mais également sous Windows et MacOsX. Vous trouverez [https://docs.docker.com/get-started/overview/ ici] une présentation des principes de cette approche.

Les instructions principales d’installation sont disponibles ici.

• sous Linux : La plupart des distributions proposent des packages standards. Une installation docker consiste en la mise en place d’un démon devant être lancé au démarrage ainsi que des outils clients en ligne de commande. Il est également nécessaire d’ajouter votre compte utilisateur comme membre du groupe créé par docker afin de pouvoir l’utiliser dans être root. Le wiki d’Arch Linux est une source précieuse d’information, y compris pour les autres distributions.
• sous Windows : Cela dépend de la version que vous utilisez. Pour une version Windows home, les instructions sont ici. Pour une version Windows pro ou Windows Education, les instructions sont ici.
• sous MacOs : ici.

L’image Docker proposant un environnement minimal identique à celui disponible en salle peut être soit reconstruite localement depuis votre machine personnelle, soit téléchargée directement sur le gitlab de l’école. Les instructions correspondantes pour ces deux possibilités sont dans le fichier README.md du répertoire docker à la racine de votre dépôt du projet.

Trois modes de fonctionnement nous semblent envisageables (nous sommes ouverts à toutes autres suggestions ou améliorations…).

L’image Docker proposée n’embarque pas en interne le répertoire projet (vous pouvez néanmoins le faire si vous le souhaitez) mais accède par montage au répertoire du projet présent sur votre machine sur votre OS hôte (Windows, MacOs, Linux). Vous pouvez donc éditer votre projet avec votre environnement de développement préféré installé sur votre machine et bénéficier des aides au développement qu’il apporte. Le lancement de la chaîne de compilation et des tests (mvn …, … pouvant être par exemple clean, compile, verify, install etc.) ou le lancement de tests manuels (decac … etc.) se fera en ligne de commande depuis le shell lancé dans le container.

Afin de pouvoir compiler, naviguer en hypertexte des erreurs de compilation vers le code source etc, depuis l’IDE, il faut que celui gère le lancement et les sorties de cette chaîne de compilation. On peut envisager à priori trois configurations :

• l’IDE est installé à l’intérieur du container : on se retrouve dans le cadre du développement sur une seule machine mais cette machine est distante (le container)
• l’IDE est installé sur l’OS hôte mais pilote via ssh la compilation sur la machine distance (le container).
• la solution hybride : l’IDE est partiellement sur l’OS hôte et partiellement sur la machine distance (le container).

Si vous souhaitez bénéficier d’un environnement de développement totalement intégré et lancer en particulier la compilation et les tests depuis votre IDE, vous pouvez installer cet IDE à l’intérieur du container (la version CentOS de cet IDE donc). L’IDE sera alors lancé depuis la ligne de commande du shell du container.

Exécuter votre IDE depuis votre container nécessite que votre OS hôte soit capable d’afficher les fenêtres X-Windows et que votre container soit paramétré pour envoyer les instructions X-Windows vers votre OS hôte.

Sous Windows, vous pouvez installer le serveur X-Windows open-source VcXsrv :
https://sourceforge.net/projects/vcxsrv/

Sous macOS, vous pouvez utiliser par exemple le serveur X-windows open-source XQuartz : https://www.xquartz.org/

Sous Windows et macOS, il faudra également autoriser l’affichage de fenêtres venant d’une machine extérieur (le container docker est vu comme une autre machine). C’est l’équivalent du xhost + sous Linux.

Sous Linux, X-Windows étant le système graphique par défaut, il n’y a pas d’installation supplémentaire à prévoir. Le xhost + n’est pas nécessaire également, le container étant lancé en “re-mappant” le répertoire contenant les socket du serveur X de l’hôte sur le répertoire équivalent du container. Le container voit le serveur X de l’hôte comme si c’était son propre serveur.

Comme cela a été expliqué dans la section précédente, le principe sous Linux consiste à “mapper” le serveur X de l’hôte dans le container (en montant le répertoire /tmp/.X11-unix de l’hôte sur le répertoire /tmp/.X11-unix du container). Il faut ensuite positionner la variable d’environnement DISPLAY à la même valeur que celle utilisée dans votre session. La création du container devient donc (dans le cas du téléchargement de l’image):

$ docker create --interactive --tty -v /home/reignier/Documents/Cours/ENSIMAG/Compil:/home/gl/Compil   -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=$DISPLAY --name projetgl projetgl

Sous macOS et Windows, le principe est de considérer le container l’OS hôte comme deux systèmes distincts et de positionner la variable DISPLAY à l’adresse IP à laquelle le container voit le système hôte.

Pas testé faute de machine à disposition

Pas testé faute de machine à disposition

Cette solution nécessite deux points différents : ajouter un accès ssh au container et choisir un IDE capable de piloter par ssh une chaîne de compilation.

L’image proposée par défaut dans le répertoire Docker (pour reconstruction ou récupération sur gitlab) offre un accès bash mais pas ssh. Vous trouverez également dans ce répertoire le fichier fichier Dockerfile.ssh permettant de reconstruire une image avec accès ssh. Au delà de l’IDE, ce scénario permet via ssh d’avoir un container où vous pouvez vous connecter par ssh depuis plusieurs terminaux différents et donc bénéficier de plusieurs accès simultané au même container). Pour utiliser ce fichier pour la construction, il faut utiliser l’option “-f”.

• Reconstruction de l’image :

docker build -f Dockerfile.ssh -t projetgl_ssh .

• Création du container (il n’y a pas plus paramètres liés à l’interaction, ce container ne faisant que démarrer un serveur ssh et pas un shell interactif) :

docker create -v <your GL home dir absolute path>:/home/gl/Projet_GL --name projetgl_ssh projetgl_ssh

• Lancement

docker start projetgl_ssh

• Arrêt

docker stop projetgl_ssh

• Détermination de l’adresse IP du container pour se connecter en ssh :

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' projetgl_ssh

projetgl_ssh est le nom du container. Pour voir l’ensemble des containers présents sur votre machine (lancés ou arrêtés) :

docker ps -a

• Connexion :

ssh gl@<ip address>

Netbeans permet de piloter par ssh le compilateur java (utilisé par exemple pour le développement sur raspberry depuis son PC) mais à ma connaissance pas Maven. Eclipse est un candidat potentiel avec en particulier le plugin Remote System Explorer (pas testé… merci de nous prévenir si vous le testez et pour quel résultat).

Les environnements de développement “classiques” comme Netbeans, Eclipse ou Idea sont des environnement monolithiques s’installant donc naturellement sur l’OS hôte ou dans le container. Il existe également des environnements reposant nativement sur une architecture client - serveur même si cela n’est pas apparent en tant qu’utilisateur. C’est le cas en particulier de Visual Studio Code qui est un projet opensource de Microsoft disponible sur Windows, Linux et MacOS. Cette architecture permet en particulier plus facilement de déployer une partie serveur sur le container et le client sur l’OS hôte. Cette approche est expliquée ici et illustrée par le schéma d’architecture présent sur cette page.

Pour mettre en oeuvre cette approche, il faut dans un premier temps installer le plugin Docker fournit par Microsoft au sein de votre Visual Studio Code (vscode-docker). Le lien entre Code et le container est ensuite décrit par un fichier .devcontainer.json qui doit se trouver dans le répertoire où vous lancez l’éditeur. Pour des raisons de facilitée, nous vous en fournissons un dans le répertoire docker de votre projet. C’est donc depuis ce répertoire que vous devez lancer Visual Studio Code si vous voulez utiliser cette solution. Le contenu de ce fichier est le suivant :

{
    "image" : "gitlab.ensimag.fr:5050/reigniep/dockergl",
    "extensions": [
    	"ms-azuretools.vscode-docker",
   	    "redhat.java",
   	    "VisualStudioExptTeam.vscodeintellicode",
   	    "vscjava.vscode-java-debug",
   	    "vscjava.vscode-java-dependency",
   	    "vscjava.vscode-java-pack",
   	    "vscjava.vscode-java-test",
   	    "vscjava.vscode-maven",
   	    "mike-lischke.vscode-antlr4"
    ],
    "workspaceMount": [
        "source=${localWorkspaceFolder}/..,target=/home/gl/Projet_GL,type=bind,consistency=cached"
    ],
    "workspaceFolder" : "/home/gl/Projet_GL"
}

Cette configuration spécifie où Code doit télécharger l’image Docker si elle n’est pas présente sur votre système, quels plugins y ajouter (complétion java, antlr, etc.) et quelle configuration pour la création du container (montage des répertoires pour vous retrouver en particulier à la racine de votre projet). Il n’est donc pas nécessaire dans ce cadre de réaliser les différentes opérations docker de construction / pull, de création de container etc. Le lancement de Code depuis le répertoire docker réalisera tout ceci automatiquement. À la première ouverture, un popup en bas à droite doit vous proposer “Reopen in container” qu’il faudra sélectionner pour que Code utilise le fichier .devcontainer.json et se déploie dans le container.

Remarque : Lorsque Code est connecté au container, le menu Terminal -> New Terminal permet d’ouvrir un nouveau shell à l’intérieur du container

« S’il n’y a pas de solution, c’est qu’il n’y a pas de problème »

• Fichier initial écrit par Matthieu MOY en janvier 2001 (ouch, ça fait un coup de vieux de relire ça maintenant ;-) ), puis amende par Xavier NICOLLIN, destiné à aider les étudiants à installer un environnement de développement chez eux sous Linux pour le projet GL.
  Nous (les enseignants) ne pouvons pas tester toutes les distributions et configurations, mais les corrections pour votre distribution préférée sont les bienvenues !
• Modification pour CygWin par Laurent Belcour (2008)
• Modification pour Mac OS X par Amaury Balliet (2010)