Utiliser VNC comme interface graphique avec un conteneur docker

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 : VNC

  • 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.

Atom.io Le travail de conteneurisation d’atom a déjà été effectué, nous partirons donc de ce Dockerfile : jamesnetherton/docker-atom-editor

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 :

Atom in docker via VNC

Enjoy !

Utiliser les snapshots dans eclipse che

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 :

Eclipse che workspace

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

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 :

Machine icon view

Maintenant, le menu “Machine” est actif dans la barre de menu et vous pouvez créer un snapshot (Create snapshot) :

Machine create snapshot menu

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) :

Open in IDE

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 …

Recover snapshot popup

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 !

vim : un IDE petit mais costaud pour go

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 …

HTTP/2, SPDY et NGINX

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 :

HTTP/2 comes to Java from David Delabassee

Et un bonus : une extension permettant d’afficher le statut de connexion HTTP/2 sous Google Chrome.

Le rôle du product owner en agilité

Très rapidement, je poste cette vidéo présentant efficacement le rôle du Product Owner en agilité.

J’en ai eu à nouveau besoin il y a peu de temps, je la “stocke” donc ici pour référence :)