Si vous faites du développement logiciel, vous connaissez forcément Docker. Et si comme moi, vous êtes condamnés à utiliser Windows, la tentation d’utiliser des conteneurs pour tous vos outils peut être grande.
Docker est parfait pour tous les services fonctionnant en ligne de commande, mais on souhaite parfois utiliser des outils graphiques et dans ce cas, c’est un peu plus compliqué. (surtout sous windows où l’utilisation d’un serveur X est au mieux complexe).
Il existe cependant une solution tout à fait exploitable pour utiliser l’interface graphique : VNC.
L’idée est d’embarquer trois services supplémentaires dans le conteneur de votre application :
un serveur X “virtual framebuffer” Xvfb
un window manager tel que fluxbox
un serveur VNC x11vnc
Une fois ces éléments packagés, une connexion via votre client VNC préféré vous permettra d’accéder à vos outils.
Mise en place
Pour les besoins de cet article, j’embarquerai l’éditeur de texte / IDE atom dans un conteneur équipé de VNC.
Le Dockerfile que nous allons développer l’étendra pour installer et configurer les composants cité précédemment.
Concrètement, l’installation des éléments se résumera à inclure les lignes suivantes :
USER root
RUN apt-get install -y xvfb x11vnc fluxbox
Il ne reste qu’à configurer et lancer les éléments :
la variable DISPLAY doit pointer sur le serveur X que nous allons définir
ce serveur est créé via le virtual framebuffer et l’écran est dimensionné à notre convenance : Xvfb :1 -screen 0 1280x1024x16
le window manager fluxbox est lancé : fluxbox
un serveur x11vnc est utilisé pour permettre la connexion distance sur le serveur X et reste actif même si le client se déconnecte : x11vnc -forever
et finalement, l’éditeur atom est lancé (le flag -f permet de désactiver le lancement en tâche de fond, ainsi le conteneur reste ouvert jusqu’à la fermeture d’atom) : atom -f
Ce qui donne :
USER atom
ENV DISPLAY :1
CMD Xvfb :1 -screen 0 1280x1024x16 & fluxbox & x11vnc -forever & /usr/bin/atom -f
Voici alors le Dockerfile complet :
FROM jamesnetherton/docker-atom-editor
USER root
RUN apt-get install -y xvfb x11vnc fluxbox
USER atom
ENV DISPLAY :1
CMD Xvfb :1 -screen 0 1280x1024x16 & fluxbox & x11vnc -forever & /usr/bin/atom -f
Un coup de build :
docker build -t gcastel/docker-atom-editor-vnc .
Et vous pouvez lancer votre conteneur en n’oubliant pas d’ouvrir le port 5900 de VNC et de monter le répertoire contenant les fichiers à éditer avec atom :
docker run -p 5900:5900 -v /documents:/documents -t gcastel/docker-atom-editor-vnc
Une connexion client VNC (ex: TightVNC) sur localhost:5900 vous permettra de vous connecter à atom :
Je fais actuellement quelques tests d’Eclipse che sur mon serveur perso.
Si vous ne l’avez jamais utilisé, il s’agit d’une version de l’IDE Eclipse accessible depuis un navigateur.
Elle est basée sur un client javascript, des APIs REST et la conteneurisation des projets (Docker forever :-) ).
Je ne m’étendrai pas sur ses fonctionnalités, ce n’est pas le sujet. Voici un aperçu de ce que ça donne dans un navigateur :
Exemple d’utilisation des snapshots
Eclipse Che offre une fonctionnalité qui permet de sauvegarder l’état d’un workspace sous la forme d’un snapshot stocké dans un registre docker.
Pour se faire, une des méthodes les plus simple est de lancer le registre docker lors du lancement de che. Voici par exemple la ligne de commande que j’utilise pour lancer che :
bin/che.sh --port:9999 -g
où 9999 est le port de connexion et -g permet de lancer un registre local pour le stockage des snapshots.
Connectez-vous à localhost:9999 et tout roule, créez un projet depuis un modèle et constatez le lancement des conteneurs.
Super, tout va bien. Mettons à jour quelques dépendances maven, modifions notre projet …
Maintenant, sauvegardons l’état du workspace pour ne pas avoir à retélécharger les dépendances maven.
Sauvegarde d’un snapshot
L’accès à la sauvegarde de snapshot ne saute pas aux yeux.
Il faut passer par la vue machine d’Eclipse Che; il suffit de cliquer sur l’icône suivante en haut à droite de l’IDE :
Maintenant, le menu “Machine” est actif dans la barre de menu et vous pouvez créer un snapshot (Create snapshot) :
Si tout se passe bien, Che vous signale qu’il est parvenu à créer le snapshot.
La problématique du rechargement
Maintenant, stoppez le workspace. Au bout d’un moment, vous souhaitez le recharger et cliquez sur le lien suivant dans le dashboard (ici pour mon workspace wksp-java) :
Manque de chance, votre snapshot n’est pas chargé. :-(
Eclipse Che est encore en phase de développement, et il n’est pas rare de tomber sur quelques soucis de ce genre.
En fait, le lien d’ouverture des workspaces depuis le dashboard ne déclenche pas le rechargement.
Si vous souhaitez recharger votre workspace avec un snapshot, il faut utiliser le lien direct. Donc pour moi : 192.168.0.1:9999/ide/wksp-java
Et miracle …
Bref, le mécanisme de snapshot fonctionne, mais la doc n’est pour l’instant pas explicite sur la façon de l’utiliser. Amusez-vous bien avec Eclipse Che !
Alors … j’ai un Raspberry Pi sous la main. Je souhaite développer (of course :)). J’aime bien développer en Go sur cette plateforme car Go fournit une API très riche, de bonnes performances, un garbage collector et est multiplateforme; que du bonheur !
Naturellement, quand je code en Go, j’utilise vim ! Ben oui, j’aime beaucoup vi et vim, qui constituent pour moi un bon IDE disponible sur tous les Unix.
Autre avantage : vim est très léger, pas de soucis pour le faire tourner efficacement sur un Raspberry Pi.
Configurer vim pour le Go
Il existe un plugin qui est entièrement dédié au support de go : vim-go. Celui-ci est très bien, mais comme beaucoup de plugins vim, c’est un peu compliqué à installer; d’autre part je souhaitais aller plus loin dans l’intégration et la configuration de mon environnement.
Or, quelqu’un s’est déjà fait les mêmes réflexions et a créé une intégration très facile à installer de plusieurs plugins pour vim. Vous trouverez toutes les infos dans la page de blog : Vim as Go language IDE.
Globalement, vous devez avoir installé :
go
vim
git
A partir de là, l’installation est très simple :
git clone git@github.com:farazdagi/vim-go-ide.git ~/.vim_go_runtime
sh ~/.vim_go_runtime/bin/install
Et : votre installation de vim n’est pas modifiée !!
Pour l’utiliser, précisez à vim la configuration à utiliser :
vim -u ~/.vimrc.go
Définissez un petit alias et ce sera parfait :
alias vimgo='vim -u ~/.vimrc.go'
Utilisation
Lors de votre première utilisation, lancez la commande vim :
:GoInstallBinaries
Vous serez ainsi sûr d’avoir toutes les commandes nécessaires.
Au lancement, vous constaterez que l’écran est divisé en 2 :
Le NerdTree d’un côté
Le fichier en cours de l’autre
Rapidement, quelques astuces d’utilisation :
Dans le NERDTree, l’ouverture d’un répertoire ou d’un fichier se fait simplement en se déplaçant à la ligne concernée et en appuyant sur Entrée
Pour passer du NERDTree au fichier et réciproquement, faites : ctrl-w 2 fois
Dans le NERDTree, vous pouvez utiliser la touche ? pour voir de l’aide
Pour compiler / installer / exécuter, utilisez les commandes : :GoBuild, :GoInstall et :GoRun
Je vous laisse le soin de découvrir les différentes fonctionnalités de l’outil : complétion, formatage de code, affichage des erreurs …
Suite à la présentation HTTP/2 de David Delabassee au Ch’ti JUG, je me suis dit qu’il était peut-être temps de m’intéresser à l’implémentation du protocole côté serveur web.
En effet, le protocole permet notamment d’optimiser les connexions et les échanges avec le serveur; avec mon petit Raspberry Pi et ma petite connexion ADSL, une petite bouffée d’oxygène peut être appréciable.
NGINX et HTTP/2
J’utilise le serveur NGINX pour le blog. NGINX supporte HTTP/2 à partir de la version 1.9.5 (branche mainline de NGINX).
Pour l’activer, c’est très simple, dans la configuration nginx, modifiez la définition de votre serveur de la manière suivante :
server {
listen 443 ssl http2;
...
Note importante : Il faut être en SSL pour que HTTP/2 soit activable (de toutes façons, la majorité des navigateurs nécessitent une connexion HTTPs pour le supporter).
De mon côté, j’utilise la version stable de NGINX et n’ai donc pas encore accès à HTTP/2, je me suis donc dirigé vers son ancêtre en attendant mieux : SPDY.
De la même manière l’activation est très simple :
server {
listen 443 ssl spdy;
...
Et ça fonctionne !!
Un bémol tout de même : les implémentations NGINX de HTTP/2 et NGINX ne supportent pas le server push.
Pour référence et pour ceux qui ne connaissent pas HTTP/2, voici les slides de la présentation de David Delabassee :
Le travail de conteneurisation d’atom a déjà été effectué, nous partirons donc de ce Dockerfile : jamesnetherton/docker-atom-editor
