Docker et ffmpeg optimisation compilation

Sur ma Debian wheezy je peux récupérer un obscure paquet ffmpeg.

>># ffmpeg -version 
ffmpeg version 1.0.10
built on Jul 25 2014 07:50:40 with gcc 4.7 (Debian 4.7.2-5) configuration: --prefix=/usr --extra-cflags='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security ' --extra-ldflags='-Wl,-z,relro' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --disable-stripping --enable-libvpx --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-librtmp --enable-avfilter --enable-libfreetype --enable-libvo-aacenc --disable-decoder=amrnb --enable-libvo-amrwbenc --enable-libaacplus --libdir=/usr/lib/x86_64-linux-gnu --disable-vda --enable-libbluray --enable-libcdio --enable-gnutls --enable-frei0r --enable-openssl --enable-libass --enable-libopus --enable-fontconfig --enable-libfdk-aac --enable-libdc1394 --disable-altivec --disable-armv5te --disable-armv6 --disable-vis --shlibdir=/usr/lib/x86_64-linux-gnu
libavutil 51. 73.101 / 51. 73.101
libavcodec 54. 59.100 / 54. 59.100
libavformat 54. 29.104 / 54. 29.104
libavdevice 54. 2.101 / 54. 2.101
libavfilter 3. 17.100 / 3. 17.100
libswscale 2. 1.101 / 2. 1.101
libswresample 0. 15.100 / 0. 15.100
libpostproc 52. 0.100 / 52. 0.100 

Et le tout sur un petit Atom ça fait pas de miracle. Je me suis dit qu'avec un peu de chance en mettant en oeuvre un container Docker, il y a moyen d'avoir à la fois une version compiler et à jour de ffmpeg sans pour autant pourrir mon serveur.
Oh miracle des images existent et de jolie fichier Dockerfile sont disponibles pour monter rapidement une image en partant des sources des divers librairies. Je suis parti de ce DockerFile, deux, trois vérifications et choix des librairies (un peu au hasard je dois bien l'avouer, je ne suis pas un expert en format vidéo et autre encoding), me voila avec une image permettant de lancer ffmpeg dans un container Docker.
Le docker retourne quand à lui (j'ai fait un alias) :

>># ffmpeg2 -version 
ffmpeg version 2.7.2
Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.9.2 (Debian 4.9.2-10) configuration: --prefix=/usr/local --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib --bindir=/usr/local/bin --extra-libs=-ldl --enable-version3 --enable-libx264 --enable-gpl --enable-postproc --enable-nonfree --enable-avresample --enable-libfdk_aac --disable-debug --enable-small
libavutil 54. 27.100 / 54. 27.100
libavcodec 56. 41.100 / 56. 41.100
libavformat 56. 36.100 / 56. 36.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 16.101 / 5. 16.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.100 / 1. 2.100
libpostproc 53. 3.100 / 53. 3.100 

Sans l'alias le commande ressemble à cela

docker run --rm -t -i -v /Video:/Video bb30ceac9f83 -ss 1418 -i "/Video/test3.avi" -b 1000k -s 640x360 -ar 44100 -ac 2 -v 0 -f flv -vcodec libx264 -preset superfast -threads 4 - > test3.flv 

On remarquera que le container est effacé suite à chaque exécution.
C'est le moment du petit Benchmark ente les 2 ffmpeg et avconv avec le command time :

ffmpeg host	ffmpeg compile docker	avconv docker	avconv host
real 61m29.758s	real 51m16.200s	real 57m51.491s	real 61m48.041s
user 156m1.020s	user 0m31.176s	user 0m35.628s	user 156m6.080s
sys 1m55.872s	sys 1m26.520s	sys 1m32.788s	sys 1m59.684s

Je n'ai pas comparé la qualité des fichiers ni même la taille, les option étant les mêmes je fais confiance. Conclusion : ça va plus vite ! Soit 16,6% plus rapide avec le docker. La commande time ne peut pas dire grand chose sur l'usage du CPU vu que cela s'exécute dans un container. En tout cas ce n'est pas négligeable tout ça peut être justifié par la montée de version, la compilation, les options...

Le voyage du Kimsufi en Docker (Etape 3)

Là je m'attaque à la base de données MySql qui est utilisée essentiellement pour Seafile. Il y a bien au d'autre tests avec mais actuellement elle sert exclusivement à Seafile. Cela va limiter la difficulté à migrer.
Encore une fois je part d'une image officiel, celle de MariaDB. Oui t'en qu'a faire autant prendre du vrai opensource, en général Oracle ne prend pas très soin de ses rachats... alors j'anticipe les soucis futures avec MySQL. Un petit run de l'image officiel de MariaDB tout en modifiant le port histoire d'avoir les 2 bases de données actives :

docker run --name mariadb -e MYSQL_ROOT_PASSWORD=AAAAA --publish=3307:3306 -d mariadb 

Et le tour est joué encore plus simple qu'un apt-get install... après faut faire confiance aux images officiels.
Maintenant il s'agit de réaliser les import / export d'un instance à l'autre de créer les users nécessaires et d'attribuer les droits. Pour cela j'ai utilisé mysql-workbench qui est vraiment complet et sympa, ok c'est un produit Oracle, mais j'ai pas dit qu'ils ne savent pas développer.
Le truc est qu'il faut accorder les droit d'accès non pas en localhost pour la connexion avec seafile mais avec l'IP de l'interface Docker0.

Pour la configuration de la base de données pour Seafile voici les fichiers :

ccnet/ccnet.conf
seafile-data/seafile.conf
seahub_settings.py 

Et un petit restart :

./seafile.sh stop
./seahub.sh stop
./seafile.sh start
./seahub.sh start-fastcgi

Voila maintenant il reste le plus compliqué s'attaquer à des outils comme Seafile et Subsonic, je ne peux plus m'appuyer sur des repos Docker officiel, mais il y a pas mal d'images réalisées sur ces outils. On est pas à l'abri que cela se déroule simplement voir que cela soit trivial !!!

Sinon là c'est clair que le Monit voit de moins en moins de chose... mais cAdvisor de plus en plus !!

Petit détail il faut gérer le firewall (iptables) pour que l'interface docker0 puisse accéder au localhost !!

Le voyage du Kimsufi en Docker (Etape 2)

Petit billet pour une petite étape pas de révolution mais de petites améliorations suite à divers lectures. Et la bonne surprise c'est qu'il y a beaucoup de ressources sur Docker, cette richesse rend l'utilisation de Docker vraiment simple car avec quelques recherches on trouve vite une solution à ses problèmes.
Ainsi j'ai mis en place supervisord dans mon container Nginx pour lancer php-fpm et nginx, oui je persiste et combine le serveur web et php dans le même container.

Voici nouveau Dockerfile :

FROM nginx
MAINTAINER niclange
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y php5-fpm php5
RUN sed -i 's/;extension=gd.so/extension=gd.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=iconv.so/extension=iconv.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=mcrypt.so/extension=mcrypt.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=mysql.so/extension=mysql.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=sqlite3.so/extension=sqlite3.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=pgsql.so/extension=pgsql.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=ldap.so/extension=ldap.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=openssl.so/extension=openssl.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=pdo_pgsql.so/extension=pdo_pgsql.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=pdo_mysql.so/extension=pdo_mysql.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/;extension=pdo_sqlite.so/extension=pdo_sqlite.so/g' /etc/php5/fpm/php.ini
RUN sed -i 's/listen.owner = www-data/listen.owner = nginx/g' /etc/php5/fpm/pool.d/www.conf
RUN sed -i 's/listen.group = www-data/listen.group = nginx/g' /etc/php5/fpm/pool.d/www.conf
RUN sed -i 's/;listen.mode = 0660/listen.mode = 0660/g' /etc/php5/fpm/pool.d/www.conf
RUN touch /etc/supervisor/conf.d/supervisord.conf
RUN echo "[supervisord]" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "nodaemon=true" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "[program:nginx]" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "command = /usr/sbin/nginx" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "user = root" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "autostart = true" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "[program:php5-fpm]" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "command = /usr/sbin/php5-fpm" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "user = root" >> /etc/supervisor/conf.d/supervisord.conf
RUN echo "autostart = true" >> /etc/supervisor/conf.d/supervisord.conf
COPY nginx.conf /etc/nginx/nginx.conf
COPY users /etc/nginx/conf/users
COPY toto.crt /etc/ssl/private/
COPY titi.key /etc/ssl/private/
EXPOSE 80 443 442
CMD ["/usr/bin/supervisord"]

En suite j'ai mis en place cAdvisor, ceci juste en ajoutant un container Docker en suivant la documentation, soit une ligne de commande (à ajuster un peu) et bien entendu je l'ai mis derrière le nginx pour l'exposer en toute sécurité en https et tout. A noter que les liens internes ne semblent pas toujours bien gérés derrière le revers proxy mais on s'en sort quand même.

Et oui les petits containers se reproduisent déjà...
Les interfaces de cAdvisor sont très sympa mais ça m'a l'air d'être assez consommateur en CPU...

Sans remplacer Monit, auquel je tiens accord un peu, j'ai n'ai pas encore décidé de son abandon, et ce billet me donne un espoir.

Après une petite pensée pour Docker, on m'a fait remarquer ceci boycottdocker. Et tout cela m'a fait prendre conscience de toute un mouvement anti docker qui semble porté par des personnes très compétente, plus que moi en tout cas et cela a du sens. Mais je vais continuer avec Docker... parce que justement je n'ai pas besoin d'être un crack de l'admin système et que l'écosystème porté par Docker me plait par ça richesse et ça simplicité. Et je suis bien certain qu'en remontant mes manches avec LXC ou KVM je n'aurais pas de souci avec Monit ou pas...