CérénIT

Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)

Web, Ops & Data - Février 2017

machine-learning sécurité header cookie nosql rethinkdb postgres csrf hacker ingénierie over-engineering ux

Admin Sys

HTML,JS,CSS

  • Les sections HTML, CSS et JavaScript de MDN sont disponibles en français : " TL;DR : Les 1 749 pages de MDN pour les sections HTML/JS/CSS sont désormais disponibles, à jour, en français." ; MDN (ou plus longuement le « Mozilla Developer Network ») est un wiki, documentant les technologies web. Si la langue de Shakespeare vous rebutait, vous n’avez plus aucune raison maintenant. Impréssionnant travail en tous cas !

Machine learning

(No)SQL

  • RethinkDB joins The Linux Foundation : l’arrêt de la société (Octobre 2016) ne signifiera donc pas la fin du projet opensource associé. Il est peut être encore un peu tôt pour statuer sur la pérénité du projet, mais au moins, il y a une lueur au bout du tunnel. Pour rappel, RethinkDB est une base de données scalable, orientée temps réel et document (JSON). L’article permet de voir également les enjeux de licences/propriété intellectuelle.
  • RethinkDB versus PostgreSQL: my personal experience : Un retour d’expérience sur RethinkDB vs Postgres avec Postgres qui gagne à la fin (comme toujours ! :-) ). Il semble néanmoins avoir un volume de données et un traffic que tout le nonde n’a pas.
  • Is Postgresql good enough? : revue des différents cas d’utilisation des bases NoSQL et voir comment / dans quelle(s) mesure(s) on peut y répondre avec Postgres. L’idée est de se dire que plutôt d’avoir n outils (et la gestion de l’expertise qui va avec), autant en avoir moins, qui répondent au besoin même s’ils ne font pas aussi bien que l’outil de référence.
  • PostgreSQL worst practices, version FOSDEM PGDay 2017 : revue des mauvaises pratiques Postgres pour vous faire prendre les bonnes.
  • Zero Downtime Postgres Upgrades : Présentation d’une architecture Postgres multi-noeuds permettant la gestion du failover.

Opinions

Sécurité

  • Cross-Site Request Forgery is dead! : il est possible de sécuriser de plus en plus ses cookies pour tuer toute tentative de CSRF. Il est conseillé de lire préalablement Tough cookies pour avoir le petit rappel sur les cookies et leurs attributs.
  • A new security header: Referrer Policy : un nouveau Header http, au state de recommandation du W3C, va faire son apparition et permet de définir des politiques sur la gestion du referer (le propager ou pas).

UX

  • Dois-je utiliser ? : Une revue des écueils des carrousels, pop-in, un défilement inifini, etc avec exemples, des solutions, des alternatives et des argumentaires.

Web, Ops & Data - Janvier 2017

docker arm hypriot api rest raml python csp kubernetes spark kafka stream rancher json ansible devops elasticsearch postgres timezone pip virtualenv sql service worker react foundation

Nouvelle année, nouveau format - au programme une édition mensuelle mixant brèves et des choses plus construites/élaborées (j’espère le mois prochain)

En Bref

API

ARM / RPi

  • Setup Kubernetes on a Raspberry Pi Cluster easily the official way! : Kubernetes, la solution d’orchestration de conteneurs, devient de plus en plus utilisable sur un enrionnement ARM (Raspberry, etc). Il faut que je réessaie ça sur mon Picocluster ; les derniers essais n’étaient pas très probant mais je n’avais pas utilisé apparemment le bon driver réseau (ie flannel et non pas weave pour ARM comme indiqué dans le billet).
  • HypriotOS 1.2 avec Docker 1.13 est également disponible pour vos RPi.

Big Data

  • Databricks and Apache Spark 2016 Year in Review : Databricks, l’éditeur de Spark, fait sa revue de l’année 2016 et des apports significatifs réalisés sur Spark : Support SQL, Structured Streaming, Spark 2.x.
  • Introduction to Kafka Streams with a Real-Life Example : l’auteur montre les limites de la combinaison Kafka+Spark (j’en ai vécu une partie) et propose son retour d’expérience sur la migration vers Kafka Streams (et conforte l’opinion que j’avais). Reste la problématique du monitoring de Kafka Streams à améliorer même si des solutions adhoc sont listées.
  • Towards a realtime streaming architecture : dans la continuité du billet précédent, retour d’expérience d’une entreprise passant de Spark+Kafka à Kafka, Kafka Streams, Kafka Connect et Akka pour faire du vrai streaming (et pas du micro-batch). Intéressant de voir qu’ils jugent Flink trop complexe pour le moment au regard de leurs besoins. Globalement, l’article montre le problème récurrent dans une architecture big data de la maitrise de l’ensemble des composants pour bien les faire fonctionner. Confluent, en apportant Kafka Streams et Kafka Connect autour de Kafka, semble avoir trouver le bon créneau combinant (une relative) simplicité technologique et performance.

CLI

Container & Orchrestration

DevOps

  • 10 astuces Ansible : revue de 10 bonnes pratiques concernant l’outil d’automatisation Ansible. Il me manquait la personnalisation du logger et de ansible.cfg

Elasticsearch

Opinions

  • Tools & Teams : au-delà du “Utiliser le bon outil pour la bonne tâche”, c’est surtout d’utiliser les outils avec lesquelles une équipe est efficace à un instant donnée. La vision a long terme étant d’aller au-delà des outils vers les concepts afin d’avoir une compétence/expérience qui s’affranchit plus facilement des outils (qui ne sont pas éternels).

Postgres

  • Simple but handy postgresql features : Sympa le \watch ou jsonb_pretty pour respectivement surveiller le résultat d’une requête et affichrer proprement une donnée au format JSON.

Python

  • Records, SQL for Humans : comme tous les projets de Kenneth Reitz (requests, maya, etc), une API simple pour manipuler des données (ici des requêtes SQL)
  • pytz : World Timezone Definitions for Python - permet de faire des calculs sur les dates, la librairie gérerait également les heures d’été/d’hiver dans les calculs.
  • Announcing Pipenv! : Vous réviez d’un outil combinant pip et virtualenv et avec des options supplémentaires, Kenneth Reitz l’a fait durant un week-end…

Sécurité

  • Web Security 101 : présentation des principaux concepts, des cas d’exemples et des moyens de se prémunir.
  • Introducing support for Content Security Policy Level 2 : Microsoft Edge se dote du support de niveau 2 de Content Security Policy (CSP) afin de permettre au propriétaire d’un site de mieux protéger ses clients en déclarant les ressources autorisées ou pas.
  • Github’s Post CSP Journey : retour des équipes de Github sur l’implémentation de CSP et les points encore à adresser (spoiler : non, CSP n’est pas l’arme ultime). Ces points sont peut être des cas marginaux pour des sites classiques mais pas pour Github. Intéressant à lire.

Web

Web, Ops & Data - Semaine 51

docker kubernetes elasticsearch tick chronograf python date ansible redis hypriot arm

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

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

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

Web, Ops & Data - Semaine 50

docker rancher mobile log grafana chronograf statistique packaging npm sécurité csp

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)

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.

Grav, Docker-Compose et Traefik

docker docker-compose traefik grav

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.

21 22 23 24 25