31/01/2018
mysql mariadb root dns ssh bastion docker kubernetes let's encrypt test unitaire test coreos redhat
Container & Orchestration
- Core Workloads API GA : la version 1.9 de Kubernetes sortie tout début janvier marque un tourant intéressant avec le passage en stable des “Core Workload API” (Pod, ReplicationController, ReplicaSet, Deployment, DaemonSet, and StatefulSet). Avec cette stabilisation des termes, des concepts et des API, c’est le socle de Kubernetes qui se stabilise sérieusement. Une bonne raison de plus de creuser cette solution au fur et à mesure que l’écosystème va se stabiliser et se simplifier.
- The Twelve-Factors Kubernetes : Revue de la terminilogie et des concepts de Kubernetes au travers de 12 points et énonciation de quelques bonnes pratiques générales associées.
- Traefik 1.5 - Cancoilote Is Here : cette version corrige notamment le problème de méthode de génération de certificat de Let’s Encrypt (voir plus bas). En plus de celà, cette version apporte notamment une gestion dynamique des certificats par frontend/backend et de la qualité de service avec la possibilité de définir des limites de consommation de ressources.
- Container Structure Tests: Unit Tests for Docker Images : Google vient de sortir son framework de tests unitaires pour les containers Docker. A creuser pour voir s’il n’est possible de faire que de tests de “surface” ou bien si on peut aller plus en profondeur (mais est-ce souhaitable ?)
- CoreOS to join Red Hat to deliver automated operations to all : CoreOS rejoint la galaxie RedHat qui fait son retour dans le monde des conteneurs… après Openshift (qui s’appuie sur Docker + Kubernetes), voilà qu’ils mettent la main sur CoreOS + Tectonic (la version de Kubernetes packagée par CoreOS), ainsi que les autres projets CoreOS (etcd, etc). Ils vont pouvoir proposer un sacré vertical et revenir dans la cour des acteurs majeurs du conteneur ; sans parler du fait qu’ils ont aussi Ansible pour la partie automatisation…
Infrastructure
- Le Bastion SSH : Petite revue théorique et pratique d’un bastion SSH, la passerelle SSH qui vous permet d’accéder depuis un réseau X à des machines d’un réseau Y en SSH dans exposer tout le réseau Y en libre accès ou parce que le réseau Y n’a pas d’IP publique ou … Si vous prévoyer de déployer un bastion, prévoyez d’en avoir deux pour éviter le SPOF (ou qu’il soit redéployable très rapidement).
- PHP et les résolveurs DNS : à l’heure des micro-services et des API, une mauvaise couche réseau et votre application peut très mal se comporter. L’article porte ici sur la résolution DNS et les solutions de cache possible pour que votre application soit plus résiliente.
(No)SQL
- Moving from MySQL to MariaDB in Debian 9 : je me demandais pourquoi je perdais mon accès au compte root d’une instance MariaDB suite à un
mysql_secure_installation, voici enfin la réponse. Sur les nouvelles installations, l’accès au compte root de mariadb est protégé. Il faut passer par sudo mysql -u root -p ... par ex pour pouvoir se connecter en root.
- How to Install MariaDB on Debian 9 Stretch : l’article qui m’a mis sur la piste et qui donne éventuellement une solution de contournement pour reproduire l’ancien mécanisme (à vos risques et périls).
- An update on Redis Streams development : les Streams dans Redis, ce sera pour la version 5.0 prévue pour dans 2 mois. Pour rappel, les Streams, ce sont des listes Redis + PubSub + historique. C’est une réponse de Redis sur la partie Topic/Message de Kafka.
Certificats
- Let’s Encrypt a annoncé le 10 janvier avoir identifié une “faille” lors de la génération du certificat lié à l’utilisation de Let’s Encrypt dans un environnement mutualisé via la méthode
TLS-SNI. Avec le partage d’une même IP, il serait possible pour une personne malveillante de récupérer un certificat pour votre domaine à votre insu. Let’s Encrypt a finalement décidé de désactiver complètement les méthodes TLS-SNI-001 et TLS-SNI-002 et de travailler sur une nouvelle méthode TLS-SNI-003 qui corrigerait ce problème. En attendant, il faut utiliser les méthodes HTTP-01 ou DNS-01.
Astuce(s) du mois
La commande docker history (ou docker image history) permet de voir le nombre de layers d’une image, la taille de ces layers et leur âge. Exemple avec l’image nginx:stable :
docker image history nginx:stable
IMAGE CREATED CREATED BY SIZE COMMENT
dfe062ee1dc8 6 weeks ago /bin/sh -c #(nop) CMD ["nginx" "-g" "daemon… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) STOPSIGNAL [SIGTERM] 0B
<missing> 6 weeks ago /bin/sh -c #(nop) EXPOSE 80/tcp 0B
<missing> 6 weeks ago /bin/sh -c ln -sf /dev/stdout /var/log/nginx… 22B
<missing> 6 weeks ago /bin/sh -c set -x && apt-get update && apt… 53.1MB
<missing> 6 weeks ago /bin/sh -c #(nop) ENV NJS_VERSION=1.12.2.0.… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) ENV NGINX_VERSION=1.12.2-… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) LABEL maintainer=NGINX Do… 0B
<missing> 6 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 6 weeks ago /bin/sh -c #(nop) ADD file:f30a8b5b7cdc9ba33… 55.3MB
Pour avoir l’intégralité du contenu de la ligne “CREATED BY”, il suffit de rajouter un --no-trunc.
Source : Docker - history
C’est assez pratique lorsque l’on cherche notamment à comprendre et optimiser la taille de ses images Docker.