CérénIT

Plateform TICK

• Beta 3 of Chronograf : Chronograf 1.1 continue son bonhomme de chemin avec la parution d'une bêta 3 apportant son lot d'améliorations et de correctifs.

Container & Orchestration

• Kubernetes 1.5: Supporting Production Workloads : Kubernetes, dans cette version 1.5, apporte des améliorations notamment sur la gestion des applications statefull (passage d'un statut alpha à beta) et plein de choses en alpha : le support des containers windows, la fédération de cluster kubernetes, la haute disponibilité, etc.
• containerd – a core container runtime project for the industry : Docker Inc continue de modulariser Docker (Engine) en publiant "containerd" et en prévoyant de le donner à une fondation en début d'année prochaine. Containerd est la partie centrale d'exécution du container. Il a été déployé silencieusement depuis Docker 1.11. L'idée de containerd serait de devenir le "format" universel pour faire tourner des containers sur lequel tout le monde s'appuierait... A suivre dans la guerre des containers et des initiatives de standardisation (ou pas).
• An Early Look at Ansible Container v0.3.0 : Ansible 2.x permet déjà d'interagir avec les containers docker, ansible-container permet d'aller plus loin dans la gestion des containers avec ansible. Cette version apportera le support du format docker-compose v2 et le support de docker 1.12. Même si je suis parvenu à piloter des containers docker avec Ansible 2.2, j'avoue qu'il y a quelques bugs pénibles et j'ai pas forcément l'impression que ce soit la bonne façon de faire. Peut⁻être que ce module apportera des réponses ou qu'il faut repenser la chose différemment.
• Making Elasticsearch in Docker Swarm Elastic : Un billet intéressant sur le déploiement d'Elaticsearch dans un contexte Docker Swarm. En effet, la partie pénible est de gérer la découverte par IP des noeuds et de rendre cela accessible de l'extérieur du cluster. Le billet présente des astuces pour le faire. J'aurais bien aimé l'avoir il y a de cela 6 mois à 1 an...

NoSQL

• Redis — The AK-47 of Post-relational Databases : une bonne présentation de la base NoSQL Redis et de toutes ses capacités.

ARM

• Hypriot OS 1.1.2 : vos raspberry pi vont être gatés avec les dernières versions de Docker, Docker-Compose et Docker-Machine. Je détaillerai en janvier la mise en place d'un cluster docker avec Hypriot OS avec 5 Raspberry et 2 Cubietruck qui permettent d'avoir un stockage distribué/résilient avec GlusterFS.

Python

• Maya: Datetime for Humans™ : l'auteur de l'excellent module requests qui permet de faire simplement des appels HTTP, nous fait la même chose mais pour les dates. Sympathique, même si l'auteur admet lui-même que sa librairie ne fait pas tout pour autant.

Bonnes fêtes de fin d'année à tous !

Mobile

• [Lecture] The 2016 U.S. Mobile App Report : Eric, sur la base des chiffres de 2016 rappelle que "[...] vouloir initier la diffusion de son produit/service par une app mobile, c’est partir avec un boulet au pied" et ce même si les statistiques de téléchargement d'applicaitons s'améliorent. Un site web adapté pour mobile sera donc suffisent à court terme (voire tout court), faudrait juste simplifier la création d'un raccourci sur la page d'accueil pour mettre son site mobile au même niveau qu'une application préférée...

Container & Orchestration

• Rancher 1.2 Is Now Available! : En plus d'apporter la compatibilité avec les dernières versions de Docker (Swarm), Docker-Compose et Kubernes, cette version apporte un meilleur support des plugins réseaux et stockage de Kubernetes & Docker, ainsi qu'une amélioration de la haute disponibilité, de la gestion du cycle de vie de ses applications et une nouvelle politique de sortie de version avec un rythme mensuel.
• Docker acquires Infinit: a new data layer for distributed applications : En faisant l'acquisition d'Infinit (société française !), Docker semble vouloir promettre un stockage distribué notamment pour les composants statefull (base de données, logs, etc) et ce de façon sécurisée (au sens sécurité ou résilience, cela n'est pas encore précisé).

Mode de travail

• La revue de code bienveillante : l'article revient sur les bonnes habitudes à prendre dans le cadre d'une revue de code pour qu'elle soit d'une part efficace pour tous et avec la bonne façon de faire.
• How we stay connected as a remote company : Petit retour pratique sur les habitudes prises au quotidien chez Gitlab pour gérer des équipes distantes.

Packaging

• npm-based release workflow : Thomas décrit très clairement comment utiliser les fonctionnalités de npm pour gérer le cycle de release de son application (génération du changelog, gestion des numéros de versions, création des tags git, etc).

Statistiques, logs, monitoring (et vie privée)

• Server Log Analysis: It’s More Important Than Google Analytics : avec le développement des bloqueurs de publicité (adblock, µblock, etc), les outils de tracking/statistiques de sites comme Google Analytics vont perder en pertinence. Il va falloir en revenir au basic et a minima compléter les statistiques Google Analytics par les stats issus de fichiers de logs de vos serveurs.
• Now in Beta: Chronograf, a UI for the TICK stack & a complete open source monitoring solution : Chronograf, la solution de visualisation des données de la plateforme TICK, passe de la version alpha à la version beta. Vont-ils réussir à percer ou bien est-ce peine perdu face à Grafana v4+ ?

Sécurité

• Content Security Policy : la retranscription de la conférence donnée par Nicolas Hoffmann à Codeurs en Seine 2016 sur CSP, la couche sécurité coté navigateurs permettant d'indiquer quels ressources distantes votre site autorise ou pas.

Pour un projet en cours de finalisation, j'ai utilisé le CMS Grav et j'ai décidé tant pour mon développement en local que pour l'environnement de production de déployer cela sous la forme de container docker et d'utiliser Traefik comme reverse-proxy et m'appuyer notamment sur son support natif et dynamique des containers docker.

Premiers pas...

J'avais initialement publié une image nsteinmetz/grav basée sur l'image officielle PHP:apache mais elle ne me convenait pas totalement :

• Utilisation d'apache2 alors que j'ai basculé depuis longtemps sur nginx
• L'image PHP:apache est basée sur Debian (taille plus importante qu'une image basée sur Alpine)
• Pas d'utilisation des volumes (je n'ai pas pris le temps de les déclarer)

Pour mémoire et à toutes fins utiles, le Dockerfile - nsteinmetz/docker-grav :

FROM php:7-apache
ADD https://github.com/getgrav/grav/releases/download/1.1.8/grav-admin-v1.1.8.zip /tmp/grav-admin-v1.1.8.zip
RUN apt update && \
    apt upgrade -y && \
    apt install -y \
        unzip \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libmcrypt-dev \
        libpng12-dev \
        pkg-config && \
    unzip /tmp/grav-admin-v1.1.8.zip -d /tmp/ && \
    mv /tmp/grav-admin/* /var/www/html/ && \
    mv /tmp/grav-admin/.htaccess /var/www/html/ && \
    chown www-data:www-data -R /var/www/html && \
    docker-php-ext-install -j$(nproc) mcrypt && \
    docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ && \
    docker-php-ext-install -j$(nproc) gd &&\
    docker-php-ext-install -j$(nproc) zip &&\
    a2enmod rewrite && \
    rm -rf /var/lib/apt/lists/*
COPY php.conf /etc/apache2/conf-enabled/ 
COPY server-signature.conf /etc/apache2/conf-enabled/

Avec php.conf :

php_admin_flag display_errors off
php_admin_flag expose_php off

php_admin_value post_max_size "40M"
php_admin_value upload_max_filesize "40M"

et server-signature.conf :

ServerSignature Off
ServerTokens Prod

Améliorations

Les améliorations apportées :

• Passage à docker-compose pour avoir plus de flexibilité au moment de démarrer les containers en fonction des projets utilisant Grav,
• Passage à des images basées sur alpine (plus légères)
• Passage à une architecture PHP-FPM + Nginx

Cela donne :

├── app
│   ├── Dockerfile
│   ├── security.conf
│   └── uploads.conf
└── web
│   ├── Dockerfile
│   └── php-fpm.conf
├── docker-compose.yml

Petites précisions à ce niveau :

• app correspond au container php-fpm
  • security.conf contient des options de sécurité PHP (ne pas exposer la version de PHP, ne pas afficher les erreurs, etc)
  • uploads.conf contient des options liés aux uploads PHP (taille max de fichiers, etc)
• web est le container nginx
  • php-fpm.conf est la configuration de mon virtualhost nginx

Revue du container "app" (php-fpm)

On a app/Dockerfile :

FROM php:7-fpm-alpine
ADD https://github.com/getgrav/grav/releases/download/1.1.8/grav-admin-v1.1.8.zip /tmp/grav-admin-v1.1.8.zip
RUN apk update &&\
    apk upgrade &&\
    unzip /tmp/grav-admin-v1.1.8.zip -d /tmp/ && \
    mv /tmp/grav-admin/* /var/www/html/ && \
    mv /tmp/grav-admin/.htaccess /var/www/html/ && \
    chown www-data:www-data -R /var/www/html &&\
    apk add libjpeg libjpeg-turbo libjpeg-turbo-dev libpng libpng-dev freetype freetype-dev &&\
    docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ && \
    docker-php-ext-install mcrypt zip gd &&\
    rm -rf /var/cache/apk/* &&\
    rm -rf /tmp/grav-admin-v1.1.8.zip &&\
    cd /var/www/html && ./bin/gpm update --no-interaction
COPY uploads.conf /usr/local/etc/php-fpm.d/uploads.conf
COPY security.conf /usr/local/etc/php-fpm.d/security.conf
VOLUME ["/var/www/html", "/var/www/html/assets", "/var/www/html/backup", "/var/www/html/cache", "/var/www/html/images", "/var/www/html/logs", "/var/www/html/tmp"]

A noter, même s'il n'y a rien d'exceptionnel :

• Initialisation du container en récupérerant la version de Grav, gestion des dépendances et des permissions
• La dernière ligne de RUN va mettre à jour les plugins inclus nativement dans Grav
• Les volumes déclarés permettent de sortir du container toutes les zones non stateless : logs, cache, contenus, etc sur la base de la documentation officielle de Grav ; j'ai ajouté néanmoins les répertoire backups et tmp.

Ensuite, app/security.conf:

[www]

php_admin_flag[display_errors] = off
php_admin_flag[expose_php] = off

et app/uploads.conf :

[www]

php_admin_value[post_max_size] = "40M"
php_admin_value[upload_max_filesize] = "40M"

J'ai fait le choix de surcharger l'instance php-fpm par défaut (ie: www) et j'utilise php_admin_* afin d'interdire toute surcharge de ces variables par l'application.

Revue du container "web" (nginx)

web/Dockerfile :

FROM nginx:stable-alpine
RUN rm /etc/nginx/conf.d/default.conf
ADD php-fpm.conf /etc/nginx/conf.d/php-fpm.conf

Je supprime le virtualhost fourni par défaut et je fournis le mien en lieu et place.

web/php-fpm.conf :

server {
    listen 80;
    server_name _;
    charset utf-8;
    
    root /var/www/html/;
    index index.html index.php;

    # Uploads to 100M
    client_max_body_size 100m;

    location / {
        try_files $uri $uri/ /index.php?_url=$uri;
    }

    ## Begin - Security

    # don't send the nginx version number in error pages and Server header
    server_tokens off;

    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Frame-Options SAMEORIGIN;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: ; style-src 'self' 'unsafe-inline'; font-src 'self'; child-src; object-src 'none'";

    # deny all direct access for these folders
    location ~* /(.git|cache|bin|logs|backup|tests)/.*$ { return 403; }
    # deny running scripts inside core system folders
    location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny running scripts inside user folder
    location ~* /user/.*\.(txt|md|yaml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny access to specific files in the root folder
    location ~ /(LICENSE.txt|composer.lock|composer.json|nginx.conf|web.config|htaccess.txt|\.htaccess) { return 403; }
    ## End - Security

    ## Begin - PHP
    location ~ \.php$ {
        fastcgi_pass app:9000;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
    }
    ## End - PHP
    
    location ~* ^.+\.(ico|js|gif|jpg|jpeg|png|bmp)$ {
        expires 30d;
    }
}

A noter :

• Le fichier est inspiré de la configuration officielle nginx donnée pour Grav
• Ajout de directives de sécurité (X-Content-Type-Options, X-XSS-Protection, X-Frame-Options et Content-Security-Policy)
• Interdiction d'accès à des répertoires
• Déclaration de php-fpm où le point d'attention est juste d'indiquer app:9000, car app est le nom de mon service.
• Mise en cache des images

Et un docker-compose.yml pour enrober le tout

version: '2'
services:
    web:
      build: ./web/
      depends_on:
        - app
      volumes_from:
        - app
      ports:
        - "80:80"
    app:
      build: ./app/
      volumes:
        - ./user:/var/www/html/user
        - ./assets:/var/www/html/assets
        - ./backup:/var/www/html/backup
        - ./cache:/var/www/html/cache
        - ./images:/var/www/html/images
        - ./logs:/var/www/html/logs
        - ./tmp:/var/www/html/tmp

Pour builder puis lancer vos containers en mode daemon :

docker-compse up -d --build

Traefik en reverse-proxy

Traefik est un reverse-proxy moderne et il a le bon goût de s'interfacer notamment avec l'API de Docker. On peut alors déclarer dynamiquement nos containers à traefik et celui-ci les prend en compte dynamiquement.

Démarrer Traefik

Pour mon poste en local, j'ai décidé de lancer Traefik de la façon suivante :

docker run -d -v /dev/null:/traefik.toml -v /var/run/docker.sock:/var/run/docker.sock -p 80:80 -p 443:443 -p 8080:8080 --name traefik traefik:camembert --web --docker --docker.domain=docker.localhost --logLevel=DEBUG

Pour les détails :

• -v /dev/null:/traefik.toml permet de démarrer Traefik sans fichier de configuration
• -v /var/run/docker.sock:/var/run/docker.sock permert au container Traefik de communiquer avec Docker et son API
• J'expose les ports 80, 443 et 8080. Le dernier permettra d'accéder au dashboard fourni nativement par Traefik
• --web : lance l'interface web (dashboard)
• --docker --docker.domain=docker.localhost : active le support de docker et fourni un domaine par défaut à tous les containers docker.
• --logLevel=DEBUG : permet d'avoir des logs verbeux si problème via docker logs -f traefik

Rendre son application "traefik-aware"

Il "suffit" d'indiquer des labels à vos services :

version: '2'
services:
    web:
      build: ./web/
      depends_on:
        - app
      volumes_from:
        - app
      labels:
        - "traefik.backend=grav-project"
        - "traefik.frontend.rule=Host:project.grav"
        - "traefik.port=80"
        - "traefik.protocol=http"
        - "traefik.frontend.entryPoints=http"
        - "traefik.docker.network=nom_du_reseau"
    app:
      build: ./app/
      volumes:
        - ./user:/var/www/html/user
        - ./assets:/var/www/html/assets
        - ./backup:/var/www/html/backup
        - ./cache:/var/www/html/cache
        - ./images:/var/www/html/images
        - ./logs:/var/www/html/logs
        - ./tmp:/var/www/html/tmp
      labels:
        - "traefik.enable=false" 

Explications pour le service web :

• je lui indique un nom de backend (peu importe le nom) qui sert juste à Traefik pour "nommer" votre container
• l'url (de frontend) sur laquelle Traefik devra réagir pour vous interfacer avec votre container (ici en tapant http://project.grav/ dans mon navigateur, je dois arriver sur mon container)
• le protocol et le port indiquent que je me connecte sur le port 80 de mon container avec le protocole http
• l'entryPoint indique que je vais me connecter à Traefik sur le port 80 pour me connecter ensuite à mon conteneur.
• le nom du réseau que vous a créé docker lors de l'initialisation du projet. Pour le récupérer, faire un docker network ls.

En gros on a :

Vous <=> Votre navigateur <=> Traefik Frontend (Host:project.grav (frontend.rule) + protocole http (EntryPoint)) <=> Traefik Backend (grav-project + port 80 + protocole http) <=> Container Web

Explications pour le service app :

• Je ne souhaite pas exposer ce service dans Traefik, je désactive alors ce service (par défault, il y a une auto-découverte de tous les services).

Pour finir

Il ne me reste plus qu'à :

• Faire une entrée DNS ou éditer /etc/hosts pour project.grav
• Ouvrir votre navigateur sur http://project.grav/

Sauf que cela ne marche pas à ce stade (si vous utilisez traefik dans un container docker). En effet, lors du docker-compose up -d, docker a créé un réseau pour votre application. Or par défaut, Traefik n'y a pas accès. Il vous faut faire:

docker network connect <nom_du_reseau> <container-traefik>

Et ce coup-ci, votre site propulsé par Grav s'affiche.

Vous pouvez retrouver les fichiers et remonter vos commentaires sur cerenit/docker-grav

Une fois prochaine; je vous parlerais d'Ansible, Docker et Traefik pour déployer vos projets aisément.

Container & orchrestration

• Kompose: a tool to go from Docker-compose to Kubernetes : en cours d'incubation chez Kubernetes, ce projet permet de faciliter la transition de Docker à Kubernetes en transformant les fichier docker-compose.yml en fichiers Manifests Kubernetes. Un pivot intéressant si on considère que les développeurs vont utiliser Docker (et au mieux Swarm) pour leurs environnements de développement et en production éventuellement Swarm et ensuite vouloir migrer vers Kubernetes pour ses fonctionnalités plus évoluées.
• Introducing Distributed Cheese: Traefik 1.1 Camembert Is Out! : Traefik, le reverse proxy moderne qui sait s'interfacer notamment avec Docker, Consul, Kubernetes et plein d'autres est sorti en version 1.1.x. Cette version apporte notamment le support de l'API Docker Swarm (Docker 1.12+), une meilleure gestion des contraintes, le support de Mesos, une meilleure gestion des affinités de sessions, un mode cluster pour Traefik (expérimental) et une image officielle docker basée sur alpine. J'ai profité de l'installation d'un nouveau serveur pour déployer Traefik et c'est vraiment agréable de pouvoir déclarer dynamiquement ses containers docker. Par ailleurs, je rappelle que je maintiens des images docker de Traefik pour sa version ARM
• Docker for AWS Public Beta : l'offre Docker pour AWS passe d'une version alpha à une verion beta. On notera essentiellement qu'il s'agit d'une version plus intégrée avec l'offre AWS que si l'on déployait un docker soi-même. A suivre mais attention à vérifier qu'il n'y a pas un lock-in qui se crée à la fin, que l'intégration apporte un plus et ne nuit pas à la portabilité des containers.

Dashboard, Monitoring

• What's new in Grafana v4.0 : la fonctionnalité phare de cette version est la capacité de définir des alertes au niveau de chaque élément d'un dashboard. Pour se faire il faut définir les règles à appliquer et ensuite s'appuyer sur la partie notification. Pour ceux qui étaient tentés d'installer Chronograf 1.1 (béta) pour avoir cet alerting en plus des dashboards adhoc de Grafana, ils pourraient bien finalement rester dans Grafana (dont la maturité n'est plus à prouver) plutôt que d'attendre que Chronograf se stabilise... A moins que Chonograf n'apporte une valeur ajoutée de part son intégration native avec Telegraf.

Pépites

• Si vous pensiez que toutes les villes commencent par une lettre, maintenant vous savez que c'est faux avec la ville de 's_Herenelderen. Vous pouvez mettre vos regexp à jour !
• These unlucky poeple have names that break computers : même si l'article concède que ce problème est de moins en moins vrai au fur et à mesure des progrès réalisés et de la prise de conscience par les développeurs, mais s'appeller "Null" ou avoir un nom de famille très long (36 caractères dans l'exemple donné ou même 8 au Japon quand l'habitude est de 4...), cela pose des tas de problèmes dans la vie du quotidien.

J'étais à DevOps Rex hier ; elle m'avait intéressé de part son intitulé :

La conférence devops 100% retour d’expérience.

En attendant les vidéos, vous pouvez déjà retrouver les slides sur le compte slideshare devopsrex.

La conférence a plutôt bien tenu son objectif au travers de 9 talks mélangeant des réussites et des échecs mais aussi des contextes de petites et grosses entreprises.

En synthèse :

• DevOps, c'est avant tout une culture, un état d'esprit et des pratiques, bien avant d'être des outils. J'en suis convaincu, la salle le semblait aussi. C'est déjà ça d'acquis mais l'audience était biaisée.
• L'agile, c'est bien car cela rapproche Métier et Développeurs mais s'il n'y a pas du DevOps dans la foulée pour déployer au fur et à mesure la valeur apportée par les cycles itératifs, c'est idiot. La valeur n'existe que si la fonctionnalité est livrée en production. Il faut donc envisager le "Biz/Dev/Ops" comme j'en ai parlé à l'E1 Conférence lors de mon talk sur le Généraliste (transcript
• Des synergies également entre DevOps et le Lean dans tout ce qui touche à la réduction de gaspillage et à l'amélioration continue : fournir l'architecture adaptée (pas de sur-engineering), itérer, etc.
• Notion de juste investissement :
  • Tout automatiser n'a pas de sens mais plutôt que d'avoir des formules complexes pour mesurer le ROI de l'automatisation, prendre simplement une règle de douleur comprise entre 1 et 10 et automatiser tout ce qui représente une douleur supérieure à 5.
  • Le juste investissement fait aussi référence à l'équilibre entre l'agilité et la flexibilité que l'on veut avoir et l'automasation/industrialisation. Cette dernière peut parfois nuire à cette agilité/flexibilité tout comme elle peut la faciliter (en ayant automatisé un sujet, on a du temps pour autre chose)
• Au delà de la notion de culture et d'automatisation, on retrouve la notion de mesure et de partage des indicateurs (KPI). La mesure permet de factualiser/objectiver les choses et d'avoir du feedback sur nos actions. En partageant nos indicateurs et en connaissant les indicateurs des équipes avec lesquelles on travaille, cela peut être utile qu'ils y aient accès mais nous pouvons aussi les prendre en compte pour nos activités.
• Dans un contexte de grande entreprise, où la maturité devops peut varier, il est plus intéressant de partager les indicateurs que d'imposer des outils. En laissant chaque équipe adopter les outils dont elle a besoin mais en remontant des indicateurs commun, on évite que des équipes perdent du temps à réimplmenter leurs pratiques actuelles dans un autre outil sans leur apporter une réelle valeur ajoutée mais on leur demande de remonter des indicateurs communs afin de pouvoir évaluer la progression d'ensemble de l'entreprise.
• Pour mettre en place une démarche DevOps, s'il faut bien partir de la littérature existante, il convient surtout de la contextualiser à son entreprise et ensuite aux équipes voire à l'application concernée afin d'être pertinent.
• Comme tout "transformation", il est important d'avoir un management facilitateur a minima voir sponsor. Le succès se fait tant via des initiatives bottom/up que top/down. S'il est important que les objectifs soient définis globalement et éventuellement par le management, il est tout aussi important de laisser une forte autonomie aux équipes opérationnelles pour leur permettre de trouver leur organisation afin de répondre à ses objectifs.

Pas de véritable découverte durant cette conférence pour moi. Plutôt une confirmation et une objectivation d'opinions et/ou d'intuitions que je pouvais avoir jusqu'à présent et de quoi alimenter certaines réflexions.

Une journée intéressante, même si j'aurais apprécié avoir une conférence plus orientée "DevOps depuis les tranchées" et avec un peu moins de recul/hauteur.