13 mars 2015

filmer une conférence

Ce billet fait suite à mon article sur la prise de son au BreizhJUG

J'ai donc bien insisté sur le fait que la qualité du son est l'élément clé pour diffuser une conférence, ceci dit ce n'est pas une raison pour faire n'importe quoi avec l'image.

Encoder

La majorité des sessions historiques du BreizhJUG sur Parleys sont d'une qualité "passable". La raison : le publisher Parleys limite la vidéo à 300Mo, ce qui pour 90minutes de présentation nécessite de régler le codec avec amour, et de lui imposer un débit max raz des pâquerettes. Le résultat n'est pas sans conséquences. Je n'ai pas creusé très loin les options d'encodage ni les divers codecs disponibles, mais ça semble délicat de faire rentrer une qualité vidéo correcte dans 300Mo, même les films qu'on trouve sur bittorent font 700Mo pour la même durée - enfin il parait, moi j'ai jamais téléchargé de film illégalement et je ne regarde que Arté.


La version actuelle permet d'utiliser une vidéo YouTube, donc on a plus cette limitation;

à nous les HD, 1080p et autres 4K ! 

Le débit est donc un élément important sur la qualité de la vidéo que verrons nos auditeurs, ceci dit sur une conférence, filmer en 50p full HD n'a pas un grand intérêt, à moins de vouloir capturer image par image le moindre détail du sensuel geste d'Amira se recoiffant ... ce que peu de gens font (non, moi non plus, quelle idée enfin). 




Pour ne pas pénaliser ceux qui ont un débit réduit (toi qui partage une livebox à 50 dans l'openspace tu me comprend) mais aussi pour que l'upload ne prenne pas 72h, il faut encoder avec un débit adapté, et plus on a une haute résolution à encoder, plus le fichier va être lourd, donc plus on est obligé de dégrader au niveau de la compression ... Bref, j'ai retenu le 720p qui permet de faire du plein écran sans exploser la taille des fichiers - et ça permet au Ch'tiJUG de passer nos vidéos quand ils sont en manque de speaker :P

Je capture en full HD 50p puis j'exporte en 720p avec un débit "raisonnable" de 2.5Mb/s. Je fait la capture dans ce mode "haute qualité" car je préfère dégrader à la post-production une image de qualité que de travailler sur une image déjà dégradée. Un filtre d'élimination du bruit de fond par exemple applique une moyenne / flou sur le fond considéré uniforme mais qui subit un bruit numérique. Sur une image HD il dispose de nombreux points donc cette moyenne est pertinente. La réduction d'échelle en 720 est alors appliquée sur une image "propre".

Filmer

Vous noterez sans doute entre ces deux captures une grande différence de contraste / luminosité. C'est ici que l'autre bout de la chaine intervient : la qualité de la capture vidéo. La première date de 2010 avec notre "vieux" caméscope et la seconde date de février avec notre caméra HD achetée l'an dernier. Mais ce n'est pas la seule explication.

Le lieu de prise de vue n'est pas le même. En général un problème dans les salles de conférence c'est qu'on éclaire peu pour avoir un bon contraste sur l'écran de vidéo-projection, alors que la caméra elle exige un max de lumière sur le speaker. On a la chance à l'ISTIC d'avoir un compromis très correct de ce point de vue. Les grandes conférences n'hésitent pas à installer du matériel de scène pour éclairer le speaker. C'est aussi ce que j'envisage pour le BreizhCamp 2015. 

Au passage attention si ça vous tente, les lampes n'ont pas toutes la même couleur de blanc ('température'). Le risque avec un éclairage type néon, une lumière très "bleue", c'est de rendre l'image blafarde, alors qu'un halogène donnera une image très (trop?) "chaude". Sur le caméscope on peut régler la "balance des blancs" en conséquence, et on peut aussi corriger cela au montage - cette correction est surtout nécessaire sous éclairage néon, assez blafards. Sous Final Cut Pro, il suffit de laisser tourner le soft en analyse de la balance des couleurs et de cocher une case... 

Si la lumière n'est pas géniale, et même si elle est suffisante, une bonne qualité de capture vidéo reste nécessaire. J'ai déjà évoqué le cas de la GoPro. Cette micro-caméra de sport corrige les défauts de ses capacités physiques par de l'extrapolation et du renforcement des contrastes qui lui donnent une image qui pète un max. Que les choses soient claires: l'objectif d'une GoPro, comme celui de votre téléphone, ne pourra jamais rivaliser avec un objectif de type photographie en termes de lumière captée, ne serait-ce qu'en considérant sa section de collecte de la lumière - ce qui n'est qu'un des nombreux facteurs à envisager.

Un autre point à considérer avec la GoPro c'est son effet fish-eye : le grand angle déforme la géométrie de prise de vue. C'est l'effet "immersion" voulu quand on filme du base-jump, par contre pour une conférence, c'est plutôt dérangeant. 

Evidemment, on est pas obligé d'investir dans un Canon 5D avec un objectif à 2000€ pour filmer un talk sur Cassandra. Un caméscope correct fait très bien le travail, le tout est de bien évaluer ce qu'on entent par "correct".

Un caméscope est par définition un "tout terrain automatique". Pour filmer en conférence, on filme sur pied, sans mouvement important, sans changement de lumière, sans changement de focus, et souvent avec une lumière assez faible. Si vous devez choisir un modèle, je vous conseille vivement de lire les tests du site les numériques qui sont très complets, et testent souvent le comportement en faible luminosité (test encore plus complet si vous choisissez un DSLR). Les défauts qu'ils révèlent sont ceux qui vous feront ch.. lors de vos prise de vue en conférence. Sur cet exemple, on a d'un côté beaucoup de bruit numérique et de l'autre une image certes moins lumineuse, mais plus propre.


Nous avons un Sony HDR CX740 qui a une image que je trouve très correcte, et réagit plutôt bien au manque de lumière. 

Monter

Entre la prise de vue et la diffusion il y a le "montage", ce qui veut dire en gros "passer des heures sous Final Cut à chercher le bon filtre et le réglage qui va bien".

Pour un film de conférence, c'est une étape qui se fait rapidement puisqu'il n'y a pas à proprement parler de montage : on détermine le début et la fin de la présentation, basta. Je débute encore sous FCP mais je sais qu'on peut aussi ajuster le rendu de l'image pour corriger la luminosité et le rendu des couleurs et rendre l'image plus sympa. Tout dépend du temps libre dont on dispose :P

Bon, ça c'était la partie facile - ok, on a donc le film de notre speaker qui porte la bonne parole. Mais manquent les slides, ou pire les démos / live coding. Parce que sans ça, nos vidéos ne servent pas à grand chose.


Filmer l'écran

On voit souvent des sessions où le speaker est filmé de loin avec l'écran de projection. C'est malheureusement la fausse bonne idée. Les stats Youtube qui indique le moment où notre lecteur d'Internet nous quitte (durée moyenne de visionnage) est assez révélateur pour cela.

Autant la qualité d'image pour regarder Julien nous expliquer JHipster n'est pas un point clé, autant celle de la capture de son écran quand il tape du code l'est, car toute notre concentration est portée sur l'image à ce moment là. 

Or, filmer une image projetée sur écran, ça donne souvent un grand carré blanc flou, à peine lisible, très fatigant. Sauf à avoir un sujet qui déchire, personne ne restera devant cette vidéo jusqu'à la fin.



Screen-recording
En tant que speaker on m'a parfois demandé d'installer un truc qui va enregistrer tout ce qui se passe sur mon écran. Ca parait pas mal comme solution, et c'est clairement à considérer si vous n'avez pas le budget pour la solution suivante, mais ...

  1. le speaker (moi le premier) est souvent réticent à installer un truc sur sa machine, il a peur que ça fasse planter ça démo qu'il a préparé depuis 2 mois
  2. ça bouffe souvent pas mal de CPU et en effet, ça fait planter la démo
  3. ça peut bouffer pas mal de disque, se gaufrer en plein milieu (ça m'est arrivé), et en plus planter la démo
  4. si on oublie de récupérer le fichier à la fin de la session, alors que le speaker se dépêche de remballer, harcelé de questions ... on ne verra jamais la vidéo.
  5. y'a toujours un mec qui n'a rien trouvé de mieux que d'installer ArchLinux ou Windows 10
  6. si on utilise pas le mode "recopie vidéo", qu'il y a des changements de résolution à un moment donné, ou toute autre manip' de ce genre, il y a une incertitude sur ce qui est enregistré.

Variante intéressante, on m'a proposé à BDX.io la capture à distance. Je lance un soft depuis une clé USB (pas d'installation donc) et il est sensé permettre à l'opérateur de capturer mon écran. Evidemment, un truc quelque part bloquait le port, et comme on mettait ça en place 5 minutes avant mon intervention, c'était mort

Bref, c'est globalement fragile, stressant pour tout le monde, et pas sans risques même en dehors de foirer la capture. C'est donc à considérer comme un plan B, pour une salle annexe, ou pour sa propre utilisation.


Que faire alors ? 

Capturer le signal vidéo.

Au BreizhJUG nous avons dès 2009 utilisé un boitier "VGA2USB" qui marche pas trop mal mais est vite limité. Sur la session live-coding de David Gageot par exemple, on obtient une résolution 1024x768 avec quelque chose comme 20 images/seconde, et une image correcte. C'est suffisant pour suivre les refactoring qui s'enchaînent sans avoir mal au crâne (ou du moins, ce n'est pas la faute de la capture vidéo). Ce boitier coute quelques centaines d'euro et nécessite un PC connecté pour récolter la capture, ce qui est plutôt contraignant. Raison pour laquelle on ne l'a utilisé que quelques fois, et jamais pendant le BreizhCamp.

Il faut croire qu'on était en avance sur notre temps vu qu'on est référencé sur leur site maintenant !



En 2015 le HDMI devient de plus en plus présent, et simplifie beaucoup les choses. En effet, le problème du VGA c'est que c'est un signal analogique, donc le système de capture doit recomposer le signal écran pour l'échantillonner. Le HDMI par contre véhicule directement un signal numérique. Cerise sur le gateau, avec l'explosion du social gaming sur Youtube, on dispose aujourd'hui de boitiers de capture HDMI autonomes conçu pour permettre au gamers de capturer leurs moments d'anthologie.

Je viens de faire l'acquisition d'un AVerMedia Game Capture HD II. Equipé d'un disque 2.5", c'est un boitier autonome qu'on intercale entre le speaker et le vidéo projecteur. On appuie sur le bouton rouge et c'est parti pour 1h30 de capture vidéo. Je vous dirais ce que ça donne sur le terrain dans un prochain billet :) 

Ce type d'appareil est très orienté Gamer et du coup on pourra lui préférer du matos plus "vidéo" - Epiphan propose par exemple un boitier dédié à ce cas d'usage, mais pas pour le même tarif !


Au montage
Si vous publiez sur Parleys, la question ne devrait pas se poser vu que c'est le publisher parleys qui va vous permettre de mixer la vidéo du speaker avec la capture écran. Sauf qu'il faut tout de même que la bande son soit la même sur les deux vidéos, donc vous vous coltinerez tout de même l'étape "montage" pour avoir la même bande son sur les deux.

Au montage, on peut choisir d'intercaler cette vidéo avec l'image du speaker comme le fait Parleys, ou faire de l'incrustation comme par exemple sur les vidéos de la DockerCon ou l'inverse pour la Jenkins User Conférence - selon qu'on préfère voir le code ou le speaker :P.

 




Voilà, donc amis organisateur de conférence, y'a plus qu'à !

n'hésitez pas si vous avez des questions/remarques => @ndeloof




prise de son : déboires et expérimentations

Depuis bientôt 5 ans le BreizhJUG met en ligne les vidéos des conférences que nous avons organisées. Après nos débuts sur google video (RIP), les plus récentes sont disponibles sur notre channel youtube - abonnez vous d'ailleurs, d'une part pour ne pas en rater une seule, d'autre part pour qu'on puisse obtenir une URL personnalisée :P

Notre matos a pas mal évolué, avec quelques mauvaises surprises.  

2008 : Les débuts
Nous avons commencé avec un caméscope grand public et son micro intégré. Ca donne ça (oh putain, ce que j'ai vieilli !). 



La qualité d'image est dégueulasse, car à l'époque nous voulions mettre les vidéos sur Parleys.com, ce qui a pour contrainte une taille max de 300Mb, et pour 90' de vidéo le codec peut être aussi bon qu'il veut, ça charcute. Depuis parleys accepte les vidéos Youtube, on peut donc faire du HD 720 en 50p  de 1Gb - faut juste poireauter des heures pour l'upload :) 

Ceci dit, si vous regarder des vidéos techniques sur le Net, typiquement des webinars, je pense que vous serez d'accord pour dire que la qualité de la vidéo n'est pas un réel soucis, à part quand on regarde du live coding avec une police pas assez grande. Par contre, si le son est moyen - surtout si on suit une session en anglais - c'est vite désagréable.

Le cinéma l'a d'ailleurs très bien compris, dans un film la qualité de l'image peut ne pas être fantastique sans que ce soit un problème (voir les films tournés caméra au poing), par contre si la bande son n'est pas au top le spectateur décroche très vite.

Question son, on a d'ailleurs pas mal souffert : par exemple quand on nous a prêté généreusement une salle de conférence, équipée avec du matos pro qui a du être facturé un tarif exorbitant par la boite qui a monté l'installation, et que le micro sans fil déconne et tombe en rade de piles après 10 minutes, et que l'ampli ronfle en continu ...

Bref, le son c'est le nerf de la guerre. Les youtubers l'ont d'ailleurs bien compris, et les stars du Net ont tous du bon matos pour éviter l'effet salle de bain. 

Défauts
Petit tour des défauts de cette vidéo :

  • Bruit de fond. on entend un ronflement permanent. Nous avions un camescope a disque dur, dont le vrombissement était capté par le micro intégré. Il existe des filtres pour réduire ce type de bruit, mais ils sont assez compliqués à bien utiliser sans dégrader le son principal et c'est tout de même plus sain d'avoir une bande son originale de bonne qualité ...





  • Effet "salle de bain". la combinaison d'une raisonnance assez importante et d'un déséquilibre dans le rendu des fréquences donne la même impression que quand on chante sous la douche. Pour atténuer la raisonnance il faut placer le micro très proche du sujet. Pour équilibrer les fréquences ... il faut un bon micro - et ça dépend de ce qu'on veut capter : voix, chant, instruments, percussions. Les gammes de micro pro laissent rêveur.
  • Saturation. ce n'est pas trop le cas sur cette vidéo mais ça a souvent été un problème. Les caméscope grand public ajustent automatiquement la sensibilité de leur micro au son capté. Sauf bien sur qu'après un moment de silence, on peut avoir de mauvaises surprises.
  • Bruit ambiant. on entend des portes, des sirènes dans la rue, des windows qui démarrent, les commentaires du gars assis juste à côté ... C'est un point délicat car cela dénature la qualité du son, mais en même temps pour rendre la vidéo vivante le son d'ambiance est important : rires du public, questions, etc. C'est souvent ce qui manque d'ailleurs dans les vidéos des grandes conférences où on a juste le son du micro speaker.
En résumé : ingénieur du son c'est un métier ...


2009 : un canon et un serre tête
Nous avons utilisé un micro canon pour amélioré la qualité de la prise de son. C'est une solution simple et souvent utilisée par les équipes de reportage pour isoler le son de la personne filmée.

Nous avions au départ un micro Sony adapté à la griffe propriétaire du camescope. Ca a apporté un progrès sans régler le problème de fond.

J'ai appris depuis que les modèles pro et semi-pro sont montés sur des support élastiques pour éliminer tout bruit mécanique lié à la caméra, quand il ne sont pas déportés sur une perche (le fameux perchman du cinéma) pour se placer au plus près du sujet. Ne vous faites pas trop d'illusion sur les "super-canon". Leur but n'est pas de faire téléobjectif, mais de capter le son avec une très forte directivité. Il faudra donc les placer à proximité du speaker quoi qu'il arrive.

Nous avons aussi acheté nos propres micros sans fil dont un serre-tête pour ne plus dépendre du matériel de la salle de conférence. C'est la piste son à privilégier vu qu'elle est prise au plus proche de la source. Par contre, il ne faut pas chercher à radiner, un bon micro et un système RF fiable ça douille. Nous avions en fait acheté un système pas cher, et eu les mêmes déboires que le ParisJUG qui avait les même. Ils ont fini à la déchèterie.


2010 : un sony
Entre temps, changement de camescope pour un Sony HDR CX740, dont je croyais très naïvement que la griffe serait la même que sur notre précédent Sony. L'image est plutôt propre même dans la lumière souvent difficile des salles de conférence. Il dispos aussi d'une prise jack pour un micro externe. 

(parenthèse
Je vous l'ai dit la qualité de l'image n'est pas forcément cruciale, ce n'est pas une raison pour faire n'importe quoi. J'ai vu des conférences tournées avec une GoPro. C'est sans doute super pour filmer ses descente à ski en pleine lumière, mais dans une salle éclairée aux néons, avec un objectif de 2mm qui en plus fait fisheye faut arrêter de se la raconter avec des "ça fait du 4k" - le capteur ne reçoit pas assez de lumière pour fournir une image correcte.


Tiens d'ailleurs, filmer l'écran c'est aussi un problème. Mais bon je m'égare, j'en parlerais dans un prochain billet !
/parenthèse)

Dans les accessoires Sony il y a également un très intéressant micro bluetooth, qu'on place près du speaker. Nous l'avons utilisé pendant 2 ans et c'est une très bonne solution. Le son n'est pas parfait, mais au moins on évite tous les autres soucis liés au caméscope. Globalement la qualité est meilleure. Bon par contre il faut avoir le caméscope qui va avec.

Par contre attention à la consommation de piles, on a déjà perdu la moitié d'une conf à cause de ça :'(
Je l'utilise toujours aujourd'hui d'une part en backup et pour avoir une piste son de référence sur le camescope.

2014 : quelques déboires

Nous avons acheté un Rode VideoMic qui est pas très cher et de bonne qualité audio, par contre il utilise une sortie jack - pratique pour brancher directement sur un camescope grand public, mais ... 

... la prise jack du camescope crée un ronflement terrible, que j'ai eu bien du mal a limiter sur les vidéos de la conf Docker


J'ai essayé plusieurs cables, micros, etc avant d'apprendre sur un forum que c'était un soucis électronique sur certains modèles Sony lié au "plug in power" sur la prise :'(

Bref j'ai vite compris pourquoi les pros enregistrent l'audio indépendamment de l'image... si c'est pratique d'avoir une référence son sur la vidéo pour le montage (à moins d'avoir réglé les timecodes), les appareil de capture audio dédiés sont bien plus efficaces. 

2015 : zoom
Place donc à du matos d'enregistrement audio. J'ai investi dans un zoom H5, qui ne coute d'ailleurs pas très cher et est très compact donc utilisable dans tout un tas de configurations. Zoom c'est la référence qu'on retrouve partout, depuis le succès du modèle H4 écrasant toute la concurrence.

Le H5 dispose de deux micros "en X" ce qui permet d'avoir la stéréo. On le place devant le speaker et hop, on a une piste son de très bonne qualité. Le Zoom enregistre une seconde piste de "backup" à -12Db. En effet, quand on fait venir un Horacio pour une session au JUG avec sa voix puissante (et son accent terrible) et qu'en plus il bouge tout le temps, le micro sature parfois.

Il aurait fallu en principe que je surveille le niveau de capture - voir plus bas - mais cette seconde piste m'a du coup bien aidé !

Le H5 dispose aussi de deux entrées XLR/Jack. Pour le BreizhCamp 2015 je vais sans doute retenir cette configuration :
  • micro BlueTooth en backup et syncro
  • micros en X du H5
  • piste backup -12db
  • Rode pour le son d'ambiance de la salle / questions
  • serre tête speaker en piste de référence


Un point important que je n'ai pas précisé, c'est qu'une bonne capture son n'est possible que si on la surveille. Jeudi soir avec Horacio j'aurais du contrôler les niveaux du H5 et constaté qu'il était en limite de saturation, et ajuster le niveau. La piste backup n'est sensée servir qu'en cas de sur-volume imprévu. Ca veut dire : casque audio, ou au moins une oreillette.

(parenthèse
Au passage, un petit piège à con :

Le Rode videomic est un micro simple, monophonique - comme quasi tous les micros. Il a cependant une prise jack stéréo. Rode à fait ce choix (sic) et envoie donc le même signal audio en R+L - c'est sans doute plus simple pour se brancher à un caméscope ou DSLR. 

La connectique XLR est conçue pour transporter des signaux analogiques avec peu de perturbation, via un signal symétrique. En gros, on envoie le signal d'un côté, et le signal en opposition de phase de l'autre. Les deux signaux seront perturbés de la même manière par d'éventuels parasites, il "suffit" donc de les inverser + additionner pour supprimer le parasite. Ca existe aussi en mode asymétrique mais dans ce cas ça n'est que de la poudre aux yeux pour avoir l'air pro avec une grosse prise bien costaud, mais autant mettre un bon vieux Jack/RCA.

Rode fournit un adaptateur Jack-XLR, sauf que celui ci évidemment n'est pas actif et envoie donc un signal R+L identique au lieu d'un signal symétrique. donc Son + -1*Son = 0 - le zoom enregistre une piste muette. 

Y'a peut être une option, j'ai pas cherché. Sinon il faut juste un bon vieil adaptateur mini-Jack > 6.35mm car le Zoom à une prise double-standards.
/parenthèse)

Montage
Pour le montage, après des années sous Première, j'utilise aujourd'hui Final Cut Pro (avec une vraie license). Avec plusieurs pistes son évidemment ça complique un peu. Idéalement il faudrait utiliser les timecode mais j'avoue ne pas avoir encore regardé et ce n'est pas sur que le caméscope - un modèle grand public - les supporte. L'astuce du "clap" reste le plus simple, un pic est facilement identifiable sur la piste son, il n'y a plus qu'à les aligner. Ceci dit je débute en montage vidéo donc y'a encore plein d'axes d'amélioration en "post-production".




Conclusion
La prise de son, c'est compliqué si on veut obtenir de la qualité - c'est même un métier :P
Avec du matos dédié et sans se ruiner on arrive à des résultats très corrects, le tout est de préparer son affaire, car les surprises ne manquent pas, et de surveiller ce qui se passe pendant l'enregistrement.








30 janvier 2015

Do-Ker :: la conférence Docker des Bretons

Hier, nous organisions la Conférence "Do-KER", la conférence Docker au beurre salé.







L'événement était un beau succès.



Les 5 sessions proposées ont soulevé de nombreuses et intéressantes questions, qui ont pu être débattues lors de la session open-space en fin de conférence. Les retour que j'ai pu avoir laissent penser que tout le monde y a trouver son compte, une formule donc à reprendre pour un prochain événement



Le Lab que nous avions prévu en soirée s'est lui aussi bien passé, malgré une réduction drastique du scope initial faute de préparation, cependant chacun a pu manipuler, expérimenter, et éclaircir les points d'ombre de sa propre utilisation de Docker. Sylvain a même réussi à faire fonctionner la démo swarm que j'avais renoncée à faire tournée le matin :)



Autre point positif, l'appel à proposition nous a offert plusieurs sujets pour nos prochains événements dans un format plus classique, aussi le Docker Meetup va pouvoir continuer à animer la place Rennaise cette année.



Merci à la Cantine Numérique Rennaise pour l'accueil, et a Zenika qui soutiens financièrement le Docker Meetup.

11 janvier 2015

Est-ce que Je suis Charlie ?

Ceci étant un blog technique (enfin, en principe) je m'étale rarement sur ce genre de sujet, mais bon l'actualité est chargée.

J'ai grandi avec les dessins de Cabu, j'ai rigolé aux unes de Charlie Hebdo, mais je n'ai jamais acheté un seul exemplaire (alors que j'ai laissé un sacré pognon à "PC Achat").

Je ne vais pas m'étendre sur les événements de la semaine. A titre personnel je suis Athée - j'ai refusé de rentrer dans l'église où on faisait la baptême d'un de mes neveu car je ne considère pas qu'un enfant de 1 an soit en mesure de choisir sa religion. Je me retrouve donc assez bien dans les caricatures qui ont fait la renommée de Charlie Hebdo. Je trouve cette population qui ne va à la messe que le jour d'un mariage et se dit catholique particulièrement hypocrite. J'ai par contre aussi rencontré des personne (catholiques ou musulmanes) réellement croyantes, de grande qualité et d'une réelle ouverture d'esprit, avec qui j'ai eu des discussions très enrichissantes.

J'écrie ce billet non pas pour soutenir le journal ou en homage aux disparu - ce que je ferais à titre personnel dans un autre contexte. Je l'écrie parce que plusieurs articles font mention d'une montée du "#JeNeSuisPasCharlie" - en particulier de la part de jeunes lycéens qui ont eu du mal à accepter la minute de silence qu'on leur imposait.

Si les caricatures de Charlie Hebdo me font marrer, je peux comprendre que des personnes croyantes soit horrifiées par la tuerie de Charlie Hebdo mais ne se sentent pas pour autant solidaires du journal. Les caricatures restent un heurt pour leur convictions religieuse, qui ne justifie aucunement une quelconque violence, mais qui sont une blessure à leur identité, déjà malmenée par 20% de vote FN et de discours politique populiste. 

Ne nous volons pas la face : la France ce week-end montre son unité, son ouverture, sa force. Pourtant la première femme présidente pourrait ne pas être Ségolène Royal. 

27 décembre 2014

Multiple Dockerfiles for project

When you start to use docker for the application you're developing, you need to choose if the Dockerfile you write is designed to

  • Build from source and produce binary
  • Package built binary for production application
  • Build from source and hot-reload source code for quick development cycles

Docker doesn't let you (yet) set the file you want to use as a Dockerfile, and enforce your use Dockerfile.
A possible workaround is for you to define a "Build from source" Dockerfile at project root, so it can ADD the source directory, and build binary in a target directory, then add to this directory another Dockerfile designed to produce the production image, just adding the binary with runtime dependencies. You still miss the 3rd use case, that require the docker image you run to allow hot-reload of source code you bind-mount in container.

After some experiments with various approach, my preference is to build the Docker build context by myself. So I have 3 Dockerfiles : Dockerfile.dev, Dockerfile.build, Dockerfile.prod.


  • First one uses a VOLUME to access project source code and run the app with hot-reload enabled (typically, play run). This let you use your IDE to hack the code and see the resulting app running in Docker container.
  • Second one build the application and package it for production execution (mvn package). This is the reference build environment, the one you probably use for CI as well. You can setup Jenkins to archive the resulting artifacts, or can just run it and execute a cp or cat command to export it from Docker container.
  • Last one to use the built artifact (from previous step) and ADD it to another image that only define required runtime dependencies, so the image is as small as possible. Such an image can't be used isolated, as it relies on the build one, so for sample can't be used with trusted builds, until Docker team offer some way to support non-trivial build scenarios.

To work around lack of a --file option for docker build command (#2112), I'm passing the build context explicitly as a tar.gz archive - there is no overweight doing this, as docker build commands does the same with current folder.

gtar --transform='s|Dockerfile.dev|Dockerfile|' -cz * | docker build -t dev -

As I'm running OSX and the included tar command does not support --transform option (sic) I had to install gnu-tar with homebrew, so the gtar command I'm using. As this is not a trivial command this can be set within a makefile, so you can just run make dev|build|prod.

Hope this will be useful for you as well.

10 décembre 2014

Do-Ker :: la conférence Docker des Bretons

Vous l'avez peut-être remarqué, Docker c'est mon dada depuis un moment (faut dire que ça me change des thread-dump Jenkins). Si vous n'étiez pas au courant alors c'est que vous êtes tombé sur ce blog totalement par hasard, aussi revenez à votre recherche Google et essayez le liens suivant.

Je co-anime le Docker Meetup Rennais, et avec mes amis de Rennes DevOps on avait en tête de "faire un truc", et bien c'est chose faire (enfin, prévue) avec l'annonce de la Do-Ker-Conf.

WTF
L'équipe Docker (qui comporte pas mal de Frenchies) organise tout le mois de décembre un Docker tour de France qui ne passe malheureusement pas à Rennes. Du coup, nous organisons notre propre événement fait main, 100% beurre salé, l'après midi du 29 janvier à la Cantine Numérique.

Le programme (si on peut dire)

14h00 - 15h00 : retours et débats sur la DockerCon.europe. 
J'essayerais de vous retransmettre l'ambiance et les annonces de la première édition européenne de la DockerCon. Je ne garanti pas de pouvoir vous faire des démos qui tienne la route, et le but est surtout d'avoir votre point de vue et de débattre du sujet.

15h00 - 17h00 : 4 talks "retours d'expérience" de 30 minutes
Pour ces quatre sujets nous avons mis en place un call-for-papers, si vous voulez témoigner de l'utilisation de Docker dans un contexte quelconque (votre home-automation, votre équipe de dev, votre service de prod, etc) contribuez. Nous ne retiendrons peut être pas tout mais ça fera des sujets pour les prochains Docker Meetup :)

17h00 - 17h30 : Session Q&A avec Jérôme Petazzoni
"bricoleur extraordinaire" chez Docker Inc, Jérôme se joindra à nous par Hangout depuis la jungle/office de Docker SF pour répondre à vos questions.

17h30 - 18h30 : un open-space
Lors de notre tentative de Hackhaton, il est apparu que Docker donne envie de parler, d'échanger, de débattre, au point de cannibaliser l'événement initialement prévu. Et comme ça a du sens autant le faire correctement. Nous vous proposons donc un format open-space, à savoir des discussions structurées "juste ce qu'il faut" sans ordre du jour préalable. 

18h30 : buffet (et suite des discussions)
SVP ne vous inscrivez pas "juste" pour le buffet :-)

19h00 - 22h00 : un lab d'une durée de 3h 
pour ceux qui veulent mettre les mains dans le cambouis sans jamais avoir osé demander. Il s'agit d'un sujet que nous voulons proposer à DevoxxFrance, en gros notre première répétition.

Et comme tout événement qui se respecte, nous avons un super logo, intégrant tous les éléments clés qui font notre identité :

  

09 décembre 2014

About Docker authentication

On my previous blog post I was experimenting with Docker machine, this one require to run a custom build for docker client with "identity-auth". I was wondering what this is about.

This is actually implementation for a development topic introduced at DockerCon.SF in june



The authorization issue when using Docker is that client is talking to daemon on a TCP connection, so open to all possible abuses, and let you run arbitrary container or do crazy things on target host. Docker 1.3.0 introduced TLS authorization with a client and server certificate, so only well identified clients can connect to daemon. That's fine, but won't scale. In such a setup, all clients need to get certificate signed by authority as well as daemon, and revocation for such a client certificate is a complex process.

SSH based authentication with authorized_keys on server is a common practice to manage enterprise infrastructures. The proposed change is to adopt this exact same practice for docker.

Each docker instance (daemon or client) will get a unique identity, set first time it is ran and saved in .docker/. Surprisingly, JSON files are used to store keys - not openssl PEM files. This is actually JSON Web Keys, I never heard about this recent standard (admittedly not a topic I'm actively following). It's a bit surprising such a fresh new standard has been chosen, vs long terms established PEM format. Proposal says both format are actually supported, so third party client library will have to support both. Having looked at Java deplorable support for PEM files I wonder just adopting this fresh new format would make things simpler...

First time you establish connection with a Docker daemon, you'll have to confirm remote identity, confirming the remote key fingerprints - just like you use to do with SSH. On Daemon side, authorized client keys are stored under some authorized_keys.d directory.

As a resume, this proposed Authorization system is more or less just adopting SSH successful model. This makes me wonder why they not just use SSH directly, just like Git does as a transport layer they build docker on, and just require a secure communication channel with daemon.


The detailed proposal is discussed on #7667

08 décembre 2014

First experiment with Docker Machine

Docker "machine" is a new command created by Docker team to manage docker servers you can deploy containers to. Think about boot2docker you use to run on your development workstation, but applied to all possible Cloud and on-premises hosting services.

"machine" is actually an OSX / BSD command, so conflict with your installation (#2). To prevent this I've moved it to my go/bin and declared this first in PATH.

Docker machine is based on ssh authentication to setup docker host nodes. You won't be able to use it with a standard Docker client, so need to download a custom 1.3.1-dev-identity-auth build - the related changes haven't been merged in 1.3.2 yet. I've moved this binary to go/bin to get it as default docker command during my test session. Run docker command once to get your authentication setup well done (~/.docker/public-key.json file).

Right, you're well done now. Let's first experiment locally, to compare with boot2docker

➜ machine create -d virtualbox local
INFO[0000] Downloading boot2docker...                   
INFO[0039] Creating SSH key...                          
INFO[0039] Creating VirtualBox VM...                    
INFO[0044] Starting VirtualBox VM...                    
INFO[0044] Waiting for VM to start...                   
INFO[0075] "local" has been created and is now the active machine. Docker commands will now run against that machine. 
➜ echo $DOCKER_HOST
tcp://boot2docker:2376
➜ export DOCKER_HOST=`machine url` DOCKER_AUTH=identity
➜ echo $DOCKER_HOST
tcp://192.168.99.100:2376

I expected (according to "Docker commands will now run against that machine") that DOCKER_HOST would be well set, but I had to set it by myself - maybe because it's already defined in my environment.


➜  machine ip local
192.168.99.100
➜  machine ssh local
                        ##        .
                  ## ## ##       ==
               ## ## ## ##      ===
           /""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
           \______ o          __/
             \    \        __/
              \____\______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
boot2docker: 1.2.0
             master : 8a06c1f - Fri Nov 28 17:03:52 UTC 2014
docker@boot2docker:~$ ls /Users/nicolas/
Applications/     Library/          bin/              
Boulot/           Movies/           
Desktop/          Music/            
Documents/        Pictures/         dotfiles/
Downloads/        Public/           go/
Dropbox/          VirtualBox VMs/   google-cloud-sdk/
docker@boot2docker:~$ exit
➜  docker ps
The authenticity of host "192.168.99.100:2376" can't be established.
Remote key ID EJF7:BPI4:GKOC:GR7H:RKZL:KH5J:LOBB:YZRU:HCWR:JYXZ:AOGH:OOEO
Are you sure you want to continue connecting (yes/no)? yes
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
➜  docker run --rm -ti ubuntu bash
Unable to find image 'ubuntu:latest' locally
ubuntu:latest: The image you are pulling has been verified
511136ea3c5a: Pull complete 
01bf15a18638: Downloading 9.731 MB/201.6 MB 20m43s
30541f8f3062: Download complete 
e1cdf371fbde: Download complete 
9bd07e480c5b: Download complete
...
 


So I get a classic Boot2Docker installation on machine, with /Users shared volume and all expected setup. Also get equivalent commands I use to run with boot2docker client command.

The user experience here is very comparable to boot2docker, so I don't worry you'll get quickly used with it.

Let's no switch to a Cloud provider. Google Compute Engine is not (yet) supported, so was an opportunity to give Microsoft Azure a try, as this is terra incognita for me ...

First need to subscribe - then get your subscriber ID. Authentication on Azure is based on client certificate, so need to create a cert file, that you then have to register on https://manage.windowsazure.com. As it took me some time to discover where to upload it, here is a screenshot :


test


➜  machine create  -d azure --azure-subscription-id="c33.....ec5" --azure-subscription-cert="mycert.pem" azure
INFO[0000] Creating Azure host...                       
INFO[0072] Waiting for SSH...                           
INFO[0161] Waiting for docker daemon on host to be available... 
INFO[0202] "azure" has been created and is now the active machine. Docker commands will now run against that machine. 
➜  export DOCKER_HOST=`machine url` DOCKER_AUTH=identity
➜  docker run --rm -it debian bash
FATA[0000] TLS Handshake error: tls: oversized record received with length 20527 


wtf ? This is actually a know issue. I have the same issue running docker client 1.3.2. I'm still stuck here.

Also, provisionning Azure host took a looooong time, "Waiting for SSH". I have no idea this is just me due to some misconfiguration, or something expected on Azure. I'm used with GCE to give me SSH prompt within 10 seconds... :P #troll

Anyway, the question here is not if provider A is better than B, but the option Docker Machine offer to change provider without changing the toolchain. Assuming I have a production delivery pipeline based on Docker containers, I'd be happy I can run the same both locally and provisioning Cloud instances by whatever IaaS provider.

Isn't that cool ?



06 décembre 2014

About Docker monolithic design

CoreOS Rocket announcement claim to fix a design / security issue within Docker. They didn't explained much, and as you can imagine this has been discussed during DockerCon.

Docker uses a one-does-all executable model, just like busybox does. Busybox is a minimalist Linux distribution design for embedded use, and as such provides a single executable to cover all common Unix commands. This significantly reduce the distribution size.

Docker did adopt the same model and provide a single "docker" command both for client and daemon - make sense as they share lot's of code to communicate on REST api. The design and security consideration comes on the fact Docker daemon runs as root. The daemon has to be root to manage Linux namespaces and cgroup and few other kernel level stuff (network, ...). From a security perspective having a root component exposed over HTTP(S) to get client commands on the network is unpleasant, and daemon does lot's of stuff that does not require to be root (downloading image layers for sample) that offer a larger surface attack. If you consider Apache httpd design (as a sample), main daemon run as root to bind port 80, but workers process run as non-root to prevent any abuse for http handlers and module possible security issues.

CoreOS point of view is SystemD should be used to manage containers, and the container manager doesn't have to be running as root and delegate to SystemD when some kernel-level container management stuff is required.

Solomon just tweeted this :

solomonstre
So who wants to help make Docker embeddable? Daemon mode would be optional if you prefer another central daemon to be in charge like systemd
06/12/2014 02:28
solomonstre
@solomonstre the difficulty is that some parts of "just run" require managing global system state, eg ip allocation. How do we do this?
06/12/2014 02:46
solomonstre
@solomonstre rocket sweeps this under the rug by putting it all in systemd. But I don't want to tie Docker to systemd, it's too monolithic
06/12/2014 02:48

That's a major point : SystemD does not enough so Docker daemon doesn't need to run as root, so can't just say "let's make Docker rely on SystemD". Also, Docker changed it's design in 0.6 to make the image persistence extensible, so you can use AUFS or device-mapper, maybe alternate Filesystem solution (ZFS for sample) will later plug into docker. Docker team doesn't want to have SystemD as unique solution. So as they use to : define a clean extension point with neutral API, provide a default implementation (current design, with docker daemon running as root) and offer extensibility so you can configure docker to run third-party implementation, maybe relying on SystemD, maybe on other solutions.


Today Docker team is organizing a Hackathon for people still at Amsterdam after DockerCon (~80 hackers have registered afaik). Not sure this will be enough to get this implemented during the week-end, but I expect this will be actively discussed and maybe some plan for a proposal.