Nginx on Zwindler's Reflection

De F à A+ sur HTTP Observatory : sécuriser les headers de mon blog Hugo

Sat, 21 Feb 2026 10:00:00 +0200

Après l’optimisation des performances du blog (AVIF, pré-compression), j’étais super content de moi. 🥳

Mais c’était sans compter sur Antoine Caron, qui est venu (à très juste titre) me chatouiller sur un autre aspect que j’avais ignoré, le rapport Mozilla Observatory…

J’ai donc lancé un scan Mozilla HTTP Observatory sur mon blog et le résultat était : F.

Cool, je peux pas faire pire.

Le déclic

En relisant l’article de Julien sur codeka.io, qui a aussi parlé avec Antoine, a aussi un blog statique avec Hugo, MAIS qui lui avait fait le taf, j’ai réalisé que c’était à la fois important et peut-être pas si compliqué à corriger.

Julien y détaille les headers de sécurité à ajouter sur un site Hugo, avec des exemples pour Caddy. Moi je suis sur nginx, mais le principe est le même.

Note : si ça vous intéresse, les liens des épisodes précédents sur l’infra du blog sont ici :

Ça bouge pas mal sur le blog ! (2019) - De 5s à 1s en virant Wordpress pour Hugo
Ça bouge encore sur le blog (2025) - Nettoyage massif, retour auto-hébergé
Automatiser son site Hugo sans Github Action ou Vercel - Le setup nginx + webhook actuel
Optimisation webperf : AVIF et pré-compression - Le round précédent (focus sur les images)

Ce que teste HTTP Observatory

HTTP Observatory vérifie une série de headers HTTP que votre serveur devrait envoyer pour protéger vos visiteurs. Les principaux :

Strict-Transport-Security (HSTS) : force le navigateur à toujours utiliser HTTPS
Content-Security-Policy (CSP) : contrôle quelles ressources le navigateur peut charger (scripts, styles, images, iframes…)
X-Content-Type-Options : empêche le navigateur de “deviner” le type MIME des fichiers
Referrer-Policy : contrôle les informations de provenance envoyées aux sites tiers
X-Frame-Options / frame-ancestors : empêche l’inclusion de votre site dans une iframe (clickjacking)

Sur un blog statique, on pourrait se dire que ce n’est pas critique. Pas de base de données, pas de sessions utilisateur, pas de formulaires sensibles. Mais ces headers protègent quand même contre des attaques réelles :

Un script injecté (XSS) pourrait rediriger vos lecteurs vers un site malveillant
Sans HSTS, un attaquant sur un Wi-Fi public pourrait intercepter la connexion initiale en HTTP
Sans frame-ancestors, quelqu’un pourrait inclure le blog dans une iframe piégée

Bref, même pour un blog statique, ça peut valoir le coup de faire l’effort, a minima pour s’habituer aux bonnes pratiques.

Étape 1 : les headers “faciles”

Le piège nginx : add_header et l’héritage

La première chose, c’est que je suis tombé dans un piège classique avec mon nginx. Je l’ignorais, mais les directives add_header dans un bloc location écrasent (et ne complètent pas) celles du bloc server parent.

Ça veut dire que si vous avez un add_header Cache-Control dans une location (c’était mon cas), tous vos headers de sécurité définis au niveau server disparaissent pour cette location. J’ai pété un plomb pendant quelques minutes à reload / restart en boucle sans comprendre.

La solution : créer un fichier snippet et l’inclure partout.

cat > /etc/nginx/snippets/security-headers.conf << 'EOF'
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "..." always;
EOF

Puis dans la config nginx :

server {
 # Headers de sécurité au niveau server
 include /etc/nginx/snippets/security-headers.conf;

 # Cache des assets statiques
 location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg|webp|avif)$ {
 expires 1y;
 add_header Cache-Control "public, immutable";
 # OBLIGATOIRE : ré-inclure les headers ici !
 include /etc/nginx/snippets/security-headers.conf;
 }

 location ~* \.html$ {
 expires 1h;
 add_header Cache-Control "public, must-revalidate";
 include /etc/nginx/snippets/security-headers.conf;
 }
}

HSTS, X-Content-Type-Options, Referrer-Policy

Ces trois-là sont les plus simples à ajouter et “ne cassent rien” :

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

HSTS avec max-age=63072000 (2 ans) et preload permet à terme (pas encore fait) de s’inscrire sur la HSTS preload list. Le navigateur refusera même la toute première connexion HTTP initiale.
nosniff empêche les navigateurs d’interpréter un fichier texte comme du JavaScript.
strict-origin-when-cross-origin envoie l’URL complète en referrer pour les requêtes same-origin, mais seulement l’origine (domaine) pour les requêtes cross-origin.

Étape 2 : Content-Security-Policy (la vraie difficulté)

La CSP est un header puissant et a priori complexe. C’est lui qui rapporte le plus de points sur Observatory, mais c’est aussi lui qui peut tout casser si on va trop vite.

Le principe : vous déclarez au navigateur exactement quelles ressources votre site a le droit de charger (scripts, styles, images, iframes, fonts…) et depuis quelles origines. Tout le reste est bloqué. C’est la meilleure défense contre le XSS, parce que même si un attaquant arrive à injecter un <script> dans votre HTML, le navigateur refusera de l’exécuter s’il n’est pas dans la liste autorisée.

Le revers de la médaille : si vous oubliez une ressource légitime dans votre CSP, elle sera bloquée et votre site casse silencieusement : un script qui ne charge plus, une font qui disparaît, une iframe vide. Il faut donc faire un inventaire exhaustif avant de verrouiller.

Je me suis fait épauler par un LLM (Opus 4.6) pour les modifs à réaliser et on a fait plusieurs passes jusqu’à ce que tout fonctionne.

Inventaire des ressources externes

Avant d’écrire la CSP, il faut faire l’inventaire de tout ce que le site charge. Voilà une petite synthèse de mon pote Claudio :

Type	Ressource	Origine
Script	GoatCounter analytics	`https://gc.zgo.at/count.js`
Script	Umami analytics	`https://cloud.umami.is/script.js`
Connect	GoatCounter API	`https://blogzwindler.goatcounter.com`
Connect	Umami API	`https://api-gateway.umami.dev`
Script	De mon thème ‘stack’ - vibrant.js (couleurs d’images)	`https://cdn.jsdelivr.net`
Script	De mon thème ‘stack’ - PhotoSwipe (lightbox images)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - PhotoSwipe CSS (lightbox)	`https://cdn.jsdelivr.net`
Style	De mon thème ‘stack’ - CSS du thème	local (`'self'`)
Font	Luciole	locale
Frame	Widget Deezer (inclu dans un seul article 😖)	`https://widget.deezer.com`
Image	data: URIs (SVGs inline)	`data:`
Form	Mailchimp (abonnement newsletter)	`https://zwindler.us15.list-manage.com`

Le problème des scripts d’analytics externes

Avec une CSP comme script-src 'self' https://gc.zgo.at https://cloud.umami.is, je devais soit :

Faire confiance à ces CDN -> si le CDN est compromis, le script malveillant s’exécute sur mon blog. Nope.
Ajouter des hashes SRI (Subresource Integrity). Problème : ces scripts peuvent changer côté serveur sans prévenir, ce qui casserait le hash.

J’ai choisi une troisième voie : télécharger les scripts à chaque build et les servir localement.

# Dans mon petit script blog_refresh.sh, avant le hugo --minify
mkdir -p static/js
curl -sf --max-time 10 https://gc.zgo.at/count.js -o static/js/count.js \
 || echo "WARN: failed to download GoatCounter script"
curl -sf --max-time 10 https://cloud.umami.is/script.js -o static/js/umami.js \
 || echo "WARN: failed to download Umami script"

Et dans le template Hugo :

<script data-goatcounter="https://blogzwindler.goatcounter.com/count"
 async src="/js/count.js"></script>
<script defer src="/js/umami.js"
 data-website-id="3d8f0ea9-..."></script>

Est-ce que c’est “tricher” ?

Une fois que j’avais fait la modif, je me suis demandé : est-ce qu’héberger les scripts localement à chaque build ne contourne pas l’esprit des vérifications d’Observatory ? Sur ce point précis j’ai un petit doute, n’étant pas expert sur ces points là. J’ai demandé à un LLM qui m’a dit que non, mais je veux bien un avis tiers.

Dans tous les cas, ça semble être l’approche recommandée par la documentation GoatCounter pour les sites avec une CSP stricte.

Supprimer `unsafe-inline` de `script-src`

Observatory pénalise fortement 'unsafe-inline' dans script-src. Et c’est normal, car c’est la porte ouverte au XSS : n’importe quel script injecté dans le HTML s’exécute.

Le problème : mon thème Hugo (hugo-theme-stack) générait 4 scripts inline :

Color scheme init — lit le localStorage pour appliquer le thème clair/sombre avant le premier rendu
Color scheme detection — détecte la préférence système (prefers-color-scheme: dark)
Language switcher — le sélecteur de langue <select onchange="window.location.href=this.selectedOptions[0].value"> dans la sidebar, qui est un attribut d’événement inline (script-src-attr)
Font loader — charge la CSS de la font Luciole dynamiquement

Luciole: A typeface for visual impairment

Pour chacun, j’ai extrait le code dans un fichier .js externe dans static/js/ et remplacé le script inline par une balise <script src="...">.

Par exemple, pour le color scheme, le thème avait dans layouts/partials/head/colorScheme.html :

<script>
 (function() {
 const colorSchemeKey = 'StackColorScheme';
 if(!localStorage.getItem(colorSchemeKey)){
 localStorage.setItem(colorSchemeKey, "auto");
 }
 })();
 /* ... */
</script>

Que j’ai remplacé par un override de template Hugo :

{{- /* Override: external JS file instead of inline (CSP compliance) */ -}}
<script src="/js/color-scheme.js"></script>

Avec le contenu correspondant dans static/js/color-scheme.js. Hugo permet de surcharger n’importe quel template du thème en plaçant un fichier au même chemin dans le dossier layouts/ du projet.

Pour le language switcher, même approche : j’ai surchargé layouts/partials/sidebar/left.html pour retirer l’attribut onchange du <select> et ajouté un id="language-select", puis créé un fichier static/js/language-switcher.js :

(function () {
 var select = document.getElementById('language-select');
 if (select) {
 select.addEventListener('change', function () {
 window.location.href = this.selectedOptions[0].value;
 });
 }
})();

Note importante : il m’a fallu plusieurs allers-retours avec la console du navigateur (F12 -> Console) avant de trouver la totalité des violations CSP. Chaque correction en révélait de nouvelles, il fallait bien regarder tous les différents types de pages sur le blog (pas juste la page d’accueil et les posts), et certaines erreurs affichées dans la console venaient en fait d’extensions navigateur (typiquement les gestionnaires de mots de passe comme Bitwarden, dont le bootstrap-autofill-overlay.js génère des violations style-src-elem) et non du site lui-même. Il faut donc bien distinguer les erreurs du site de celles injectées par les extensions.

Supprimer `unsafe-inline` de `style-src`, la suite

Même logique pour les styles. J’avais quatre sources d’inline CSS :

Un bloc <style> dans custom.html — les CSS custom properties pour ma font Luciole
Des attributs style="" sur les badges de catégories — background-color: #2a9d8f; color: #fff;
Un attribut style="enable-background:..." sur un SVG (export Adobe Illustrator)
Des attributs style="" dans le formulaire Mailchimp du footer — display:none et un positionnement off-screen pour le honeypot anti-spam

Le <style> bloc : déplacé dans assets/scss/custom.scss, le fichier de personnalisation SCSS prévu par le thème.

/* Font family CSS custom properties */
:root {
 --article-font-family: "Luciole";
 --base-font-family: "Luciole";
 /* ... */
}

Les badges de catégories : toutes mes catégories utilisent les mêmes couleurs (#2a9d8f / #fff), définies dans le front matter de chaque _index.md. Le thème les injectait en style="" via le template article/components/details.html. J’ai surchargé ce template pour retirer le style inline et ajouté une règle CSS dans custom.scss :

.article-category a {
 background-color: #2a9d8f;
 color: #fff;
}

Le SVG : j’avais un SVG que j’avais ajouté à la main (un petit Robot mignon pour mon “AI Manifesto”) avec enable-background, qui est un attribut SVG 1.1 déprécié. Je l’ai simplement supprimé du fichier SVG source, sans impact visuel.

Le formulaire Mailchimp : le code HTML Mailchimp utilise style="display:none" pour masquer les divs de feedback et style="position: absolute; left: -5000px;" pour le champ honeypot (pour les robots qui s’inscrivent à ma newsletter 🤔). J’ai remplacé tout ça par des classes CSS dans custom.scss :

#mce-error-response,
#mce-success-response {
 display: none;
}

.mce-honeypot {
 position: absolute;
 left: -5000px;
}

La CSP finale

Après tous ces changements, plus aucun script ni style inline sur le site. La CSP peut donc être stricte :

default-src 'none';
script-src 'self' https://cdn.jsdelivr.net;
style-src 'self' https://cdn.jsdelivr.net;
img-src 'self' data:;
connect-src 'self' https://blogzwindler.goatcounter.com https://api-gateway.umami.dev https://cdn.jsdelivr.net;
font-src 'self';
frame-src https://widget.deezer.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self' https://zwindler.us15.list-manage.com;
manifest-src 'self';
media-src 'self'

Points notables :

default-src 'none' : par défaut, rien n’est autorisé. Chaque type de ressource doit être explicitement listé. C’est la politique la plus restrictive.
Pas de unsafe-inline nulle part : ni dans script-src, ni dans style-src
frame-ancestors 'none' remplace X-Frame-Options: DENY (plus moderne)
cdn.jsdelivr.net dans script-src, style-src ET connect-src : le thème charge vibrant.js (JS avec SRI), les CSS de PhotoSwipe (lightbox d’images) et les source maps associées depuis ce CDN
form-action autorise Mailchimp pour le formulaire d’abonnement dans le footer

Au final, de nombreux morceaux du thème de mon blog ont du être réécrit / overridés. Je suis un peu gêné d’avoir du en arriver là, mais c’était le prix à payer pour une note maximale 😂.

Nettoyage bonus : Mailchimp

En faisant l’inventaire des ressources externes, j’ai découvert un vieux widget Mailchimp dans la sidebar qui chargeait du CSS et du JavaScript depuis chimpstatic.com. Je ne l’utilisais plus : supprimé. Le formulaire d’abonnement dans le footer des articles a été gardé, mais nettoyé de ses style="" inline (voir plus haut).

Résultat final

De F (0/100) à A+ (125/100). Tous les tests sont verts.

Un grand merci à Antoine pour sa patience avec les débutants naïfs comme moi 😂 et ses super talks !

Optimisation webperf : AVIF et pré-compression pour le blog

Thu, 19 Feb 2026 17:00:00 +0200

Ce blog a presque 16 ans d’existence. Sur cette période, j’ai accumulé plus de 530 articles avec plus de 2700 images. Il y a quelques années, j’avais commencé à taper des limites (notamment quand j’ai essayer Gitlab pages chez Froggit) en atteignant les 500 Mo de medias.

J’avais fait une première passe d’optimisation, à grand coup de resize, jpegoptim et optipng et j’étais redescendu sous les 300 Mo. C’était pas mal, mais pas satisfaisant.

Puis j’ai vu le talk d’Antoine Caron (slashgear) et Mathieu Mure à Touraine Tech 2026 et j’ai enfin pris le temps de lâcher les “formats morts”.

Un peu de contexte

Ça fait un moment que je bricole l’infra et les perfs de ce blog. Si ça vous intéresse, les épisodes précédents sont ici :

Ça bouge pas mal sur le blog ! (2019) - De 5s à 1s en virant Wordpress pour Hugo
Ça bouge encore sur le blog (2025) - Nettoyage massif, retour auto-hébergé
Automatiser son site Hugo sans Github Action ou Vercel - Le setup nginx + webhook actuel

Quand j’ai commencé ce round d’optimisation, la note PageSpeed de la page d’accueil tournait autour de 70-85 en mobile selon les articles. Pas dramatique, mais on peut faire mieux !

Le talk qui a tout déclenché

À Touraine Tech 2026, Antoine Caron et Mathieu Mure ont fait un talk très clair sur l’optimisation des images web, qui pourrissent les perfs des sites web aujourd’hui.

Le message principal : les formats comme JPEG et PNG sont des “formats morts” (ou en tout cas vieillissants). À compression équivalente, les formats modernes comme AVIF prennent beaucoup moins de place, mais surtout, ils affichent des artefacts visuels bien moindres dans les hauts niveaux de compression.

J’avais failli faire une migration vers le WebP il y a quelques années, puis j’avais laissé tomber, par flemme et après quelques soucis techniques dont je ne me souviens plus trop.

Et finalement, c’est presque tant mieux, parce qu’avec AVIF, on peut compresser encore plus fort, sans que ça se voit. C’est exactement ce qu’il me fallait.

Side note : on m’a demandé une comparaison WebP vs AVIF, et Joseph a trouvé ça. C’est plutôt intéressant :

elementor blog - AVIF vs WebP : Quel format d’image règne en maître en 2024 ?

Conversion massive en AVIF

J’ai donc écrit un script qui :

Redimensionne les images trop grandes (> 1500px) pour les ramener à ~1 mégapixel
Convertit en AVIF avec avifenc (qualité 50, speed 6)
Met à jour les références dans tous les articles markdown

Et je l’ai lancé année par année, de 2026 jusqu’à 2010.

Les résultats

Année	Fichiers	Originaux	AVIF	Réduction
2010	12	0.4 MiB	0.1 MiB	74%
2011	27	1.8 MiB	0.7 MiB	63%
2012	6	0.4 MiB	0.1 MiB	78%
2013	2	0.1 MiB	0.1 MiB	56%
2014	43	5.3 MiB	1.0 MiB	81%
2015	214	10.7 MiB	3.7 MiB	65%
2016	231	12.1 MiB	4.1 MiB	66%
2017	428	23.7 MiB	9.1 MiB	62%
2018	142	7.5 MiB	2.4 MiB	68%
2019	136	12.1 MiB	2.9 MiB	76%
2020	228	23.6 MiB	5.6 MiB	77%
2021	187	31.6 MiB	4.8 MiB	85%
2022	237	29.2 MiB	7.5 MiB	74%
2023	253	43.2 MiB	7.8 MiB	82%
2024	259	34.2 MiB	8.0 MiB	77%
2025	255	31.2 MiB	6.8 MiB	78%
2026	44	6.8 MiB	1.8 MiB	74%
Total	2704	~274 MiB	~66 MiB	~76%

De PNG/JPEG qualité 90 à AVIF qualité 50 : entre 4 et 5 fois moins lourd.

Le plus satisfaisant, c’est que je ne suis pas capable de détecter visuellement de perte de qualité. Les screenshots de terminal et mes photos passent très bien en AVIF 50.

Pré-compression des documents HTML

Après la conversion AVIF, Antoine Caron (@slashgear.dev) m’a fait remarquer un truc :

Alors c’est pas mal déjà ! Je vois aussi que tes documents HTML ne sont pas compressés. Si ton blog est purement static, hésite pas à précompresser à balle et dire à ton server de servir les versions précompressées.

Effectivement, j’avais déjà gzip on; dans ma config nginx, mais c’est de la compression à la volée. Nginx utilise par défaut un niveau de compression modéré (niveau 6 sur 9) pour ne pas consommer trop de CPU.

server {
 server_name blog.zwindler.fr;
 root /usr/share/nginx/html/blog.zwindler.fr/public;
 gzip on;
 ...
}

Or, mon blog est 100% statique. Les fichiers ne changent qu’au rebuild. Ça veut dire qu’on peut les compresser une seule fois, avec le niveau maximum, et demander à nginx de servir directement les fichiers pré-compressés. Zéro CPU à chaque requête, mais surtout un meilleur ratio au final, car on peut compresser plus fort.

Côté build : `blog_refresh.sh`

J’ai ajouté les commandes de pré-compression après le hugo --minify :

# Pre-compress static files (gzip + brotli) for nginx gzip_static/brotli_static
# Zopfli: compatible gzip mais ~3-8% plus petit que gzip -9
if command -v zopfli &> /dev/null; then
 find public -type f \( -name "*.html" -o -name "*.css" -o -name "*.js" \
 -o -name "*.xml" -o -name "*.json" -o -name "*.svg" -o -name "*.txt" \) \
 -exec zopfli --i1023 {} +
else
 find public -type f \( -name "*.html" -o -name "*.css" -o -name "*.js" \
 -o -name "*.xml" -o -name "*.json" -o -name "*.svg" -o -name "*.txt" \) \
 -exec gzip -k -f -9 {} +
fi

# Brotli pre-compression (better ratio than gzip, ~15-25% smaller)
if command -v brotli &> /dev/null; then
 find public -type f \( -name "*.html" -o -name "*.css" -o -name "*.js" \
 -o -name "*.xml" -o -name "*.json" -o -name "*.svg" -o -name "*.txt" \) \
 -exec brotli -k -f -q 11 {} +
fi

Pour la compression gzip, Zigazou m’a conseillé d’utiliser Zopfli (apt install zopfli) plutôt que gzip -9. Zopfli produit des fichiers 100% compatibles gzip mais avec un meilleur ratio (~3-8% en moins). C’est plus lent, mais sur un blog statique où on compresse une seule fois au build, on s’en fiche.

En pratique, le gain de Zopfli est surtout un bonus : la majorité des navigateurs modernes supportent Brotli et recevront les .br, qui sont de toute façon plus petits. Le .gz ne sert que de fallback.

Chaque fichier index.html se retrouve ainsi avec un index.html.gz et un index.html.br à côté de lui.

Côté nginx

# Serve pre-compressed files generated at build time
gzip_static on;
brotli_static on; # nécessite libnginx-mod-http-brotli-static

# Fallback pour les contenus non pré-compressés
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript
 application/javascript application/json
 application/xml image/svg+xml;

Pour Brotli, sur Ubuntu 24.04+, les paquets sont dans les dépôts officiels :

sudo apt install libnginx-mod-http-brotli-filter libnginx-mod-http-brotli-static

Le gain mesuré

Un petit curl pour comparer la page d’accueil :

# Avec Brotli (ce que reçoivent les navigateurs)
curl -so /dev/null -w "%{size_download}" -H "Accept-Encoding: br, gzip" https://blog.zwindler.fr/
# => 6 206 bytes

# Sans compression
curl -so /dev/null -w "%{size_download}" -H "Accept-Encoding: identity" https://blog.zwindler.fr/
# => 32 886 bytes

-81% sur le HTML, de 33 Ko à 6 Ko transférés. Et on le vérifie dans Chrome DevTools : le header Content-Encoding: br confirme que Brotli est bien servi.

Et c’est pareil pour les autres fichiers textes statiques (CSS, JS).

Bilan

Optimisation	Avant	Après	Gain
Images (AVIF)	274 MiB	66 MiB	-76%
HTML page d’accueil (Brotli)	33 Ko transférés	6 Ko transférés	-81%

Le tout sans aucune dégradation visible de la qualité des images, et zéro impact CPU côté serveur pour la compression (puisqu’elle est faite au build).

Et des webperfs qui ont bien progressé, même en mobile :

Addendum

Un peu en vrac…

J’ai du repasser sur du webp pour les images en frontmatter car les sites sociaux (bluesky / slack / linkedin) ne supportent pas AVIF :-/.

On m’a conseillé zopfli en remplacement de gzip.

Pourquoi ne pas utiliser zopfli –i1023 en lieu et place de gzip -9 ?

Sauf que :

la très grande majorité supportent le brotli donc le gain sera marginal
Sur ma mini VM, le zopfli n’aboutissait jamais (bug ou trop intensif en CPU)
le projet n’est plus maintenu et qu’il a été archivé en octobre dernier.

Sinon, il y a libdeflate-gzip, sur le papier aussi bon que zopfli (pas testé) et semble encore maintenu.

On m’a aussi indiqué qu’il y a un paramètre nginx pour hériter les headers

https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header_inherit

Je déconseille nginx en tant qu'ingressController en production

Mon, 14 Nov 2022 06:30:00 +0200

Disclaimer

Je n’utilise plus nginx comme IngressController Kubernetes depuis 2020 (même si j’ai écris quelques articles dessus, notamment Exposer des applications containerisées Kubernetes (nginx Ingress Controller)). Aussi, il se peut que les informations contenues ici soient périmées.

Cependant, des issues récentes faisant état du même problème que le miens sont régulièrement ouvertes donc je pense que c’est toujours le cas.

• github.com/kubernetes/ingress-nginx/issues/2461 • github.com/kubernetes/ingress-nginx/issues/7115

Contexte

Pour qu’on mette tout de suite d’accord sur ce dont on parle, je ne déconseille évidemment pas l’usage de nginx en production. nginx est un soft robuste qui a fait ses preuves pendant des années et que j’utilise encore dans certains contextes pros et perso.

Cependant, quand j’ai commencé à travailler avec Kubernetes, j’ai (comme beaucoup) lu la documentation.

Et à l’époque, pour ce qui est de l’utilisation des Ingress, la documentation officielle mettait en avant l’implémentation de l’IngressController nginx disponible sur le Github de Kubernetes github.com/kubernetes/ingress-nginx.

Point intéressant, il existe un autre dépôt mis à disposition par la société nginx inc, que je n’ai jamais utilisé github.com/nginxinc/kubernetes-ingress. qui n’est peut être pas affecté. Cependant quand on parle de “l’IngressController nginx” la plupart des gens parle du repo sur le Github de Kubernetes (source : moi, tkt)

Et donc quel est le problème ?

Maintenant qu’on est bien d’accord que ce dont on parle, je peux vous raconter une petite histoire.

A l’époque je travaillais pour une entreprise industrielle qui hébergeait “dans le cloud” un logiciel vendu en SaaS.

Chaque client avait sa propre instance, hébergée sur un Kubernetes hébergé sur Azure.

Au début nous avions peu de clients, tout allait bien. Mais au fur et à mesure que le nombre de clients grossissait, on commençait à avoir des retours de la part des équipes métiers et support comme quoi, de temps en temps, l’application perdait temporairement la connexion au serveur.

En bon sysadmin et après avoir vérifié l’absence d’alertes de notre côté, on a d’abord blâmé l’utilisateur, le réseau et l’application elle même (dans cet ordre). #Trollface

Blague à part, la réalité, c’est que nous ne savions pas trop par où prendre le problème car nous n’avions aucun log, aucun incident et le coupures étaient au début très rares et surtout aléatoires en apparence.

Jusqu’au jour où…

Jusqu’au jour où, pour des histoires de CVEs à patcher, nous avons redéployé un très grand nombre d’applications dans un créneau horaire assez court.

A ce moment là, le nombre de plaintes a fortement augmenté et nous a permis de valider que le problème n’était pas aléatoire et était bien de notre côté.

Nous avons deviné qu’il y avait une corrélation entre le déploiement d’applications dans Kubernetes et la coupure des connexions (websockets) côté client.

On est pas seul

Une fois qu’on savait ça, on a trouvé le coupable assez vite. Une rapide recherche Google nous a permis de tomber sur plusieurs issues sur le repository de l’IngressController, décrivant les mêmes symptômes.

En creusant un peu, on a également trouvé un article très complet qui détaille bien mieux que ce que j’aurais pu faire le problème.

DanielFM - pain(less) NGINX Ingress

C’est quoi le problème ???

TL;DR tel que l’IngressController est implémenté par défaut, la configuration de nginx est rechargée à chaque fois qu’une modification a lieu sur les backends des Services Kubernetes.

Pour ceux qui ne sont pas encore bien familier avec ces concepts, à chaque fois qu’un Pod (votre app containerisée) est créé ou détruit, nginx est rechargé.

Théoriquement, ça se fait à chaud car nginx supporte les rechargements de configuration à chaud. Sauf que, tel que l’IngressController est implémenté, les Websockets ouvertes doivent être coupées…

Pour limiter la casse, à chaque rechargement de configuration, un processus nginx avec la nouvelle configuration est généré en parallèle de l’ancien qui est gardé au maximum 10 secondes pour donner une chance à toutes les connexions en cours de se fermer proprement.

Solutions ?

Dans son post, Daniel fait le tour des workarounds à votre disposition pour limiter la casse.

La première chose qu’on peut faire et qui marche bien est d’ajouter l’option --enable-dynamic-configuration qui fait que la configuration n’est plus rechargée à chaque changement de backends sur les services (événements hyper fréquent) mais uniquement lors des créations/suppression de services (le déploiement d’une nouvelle app).

Ça limite drastiquement le nombre de reloads mais n’est évidemment pas une solution.

Le deuxième levier mis en avant par Daniel est d’augmenter le timeout de 10s (--worker-shutdown-timeout) et de mettre quelque chose de très grand. Cependant, il met en garde contre cette solution car on se retrouve vite avec un duplication des processus nginx avec X versions de la conf, ce qui peut faire saturer la RAM de votre ingressController ou votre node…

Dernière idée, pour limiter la disruption causée par un changement, nous avions envisagé de segmenter en ayant un ingressController par namespaces. Ainsi en cas de redéploiement, seul les applications du namespace en cours de déploiement seraient concernées par la coupure (des « workarounds » plutôt) :

Limiter les reloads (pénible)
Augmenter sensiblement (24h ?) les timeout sur les connexions actives
Segmenter les namespaces (1 Ingress Controller par namespace, on limite l’impact d’un redéploiement à un client)

Mais alors on fait quoi ?

Comme il n’y a pas vraiment de solution à date, le plus simple reste de ne tout simplement pas utiliser l’IngressController nginx de Kubernetes 😉 et de lui préférer une implémentation gérant ce genre de cas à chaud.

Même si je n’ai pas retravaillé avec depuis un moment, nous avions eu à l’époque de bons résultats avec Traefik.

Et si vous en connaissez d’autres qui gèrent bien ce genre de cas, n’hésitez pas à me l’indiquer :).

La rentrée 2020 du blog : pas mal de changements, encore !!

Mon, 14 Sep 2020 06:05:00 +0000

2020, l’année du premier confinement (#trollface)

En décembre dernier, j’avais fais un petit recap’ de “mi-année” (d’habitude je le fais plutôt à l’anniversaire du blog) car beaucoup de choses avaient été changées sur le blog. Notamment, j’avais fais un gros effort sur la vie privée, en retirant le plus de trackers possibles (Google Analytics, AMP, Mailchimp, Adwords) et un peu sur la perf.

Il restait du boulot mais vous allez voir, je n’ai pas chaumé ;-).

Trackers et cookies

Dans l’article précédent, j’indiquais que j’avais retiré les boutons de partages (Facebook, Twitter, etc), car ils contenaient du code leakant des données privées. Seboss666 m’a fait remarquer en commentaire qu’il suffisait de copier les icônes et le code que lui utilisait (eux mêmes basés sur un tuto de Korben d’il y a perpet’), ce que j’ai partiellement fais. Les boutons de partages sont donc revenus, respectueux de votre vie privée :)

Un autre souci que j’avais était que j’utilise l’extension de WordPress Jetpack, qui aujourd’hui plein de features à WordPress dont certaines pas très très glop en terme de vie privée.

Notamment, des trackers (nécessaires pour bénéficier des statistiques des visites). Comme je suis passé sur Matomo, les statistiques de WordPress font double emploi mais j’ai mis du temps à trouver comment désactiver uniquement les statistiques et pas le reste (j’utilise Akismet pour les spam en commentaire et Markdown pour la rédaction).

En réalité, les coquins (de chez WordPress) ont cachés l’option (qui était visible il y a 3 ans), mais elle est toujours disponible moyennant une petit bidouille, détaillée dans ce topic sur le support de WordPress.

Maintenant, WordPress ne collecte plus vos données quand vous visitez le site. Et ça c’est cool :) Et enfin, j’ai changé l’email permettant de me contacter a propos du blog. Précédemment, le compte mail pour me contacter était en gmail. Pour plus de cohérence, j’ai migré le compte sur un compte protonmail (zwindl3r@protonmail.com), a priori un peu plus respectueux sur la vie privée (enfin, c’est ce qu’ils disent)…

Amélioration diverses

J’ai vu passer cet article de y0no a propos des security.txt. Pour faire simple, il s’agit d’un draft de RFC permettant aux hackers éthiques (ou simplement aux gens qui trouvent un trou de sécu béant dans votre site) de disposer des informations pour vous prévenir.

L’idée est tellement bonne et coûte tellement peu cher à mettre en place (un fichier texte de quelques lignes) que je vous invite très fortement à le mettre en place vous aussi :) !

J’ai refais une passe sur les mentions légales (disponibles ici). Il s’agit d’un modèle généré via un site web (subdelirium.com) qui n’étaient plus tout à fait à jour.

Enfin, pour le lulz, j’ai voulu faire un test de PRA du blog. Car, oui, j’ai un plan de reprise d’activité pour mon blog perso, comme tous les admin systèmes tarés ;-p.

Et bien sûr, comme tout test, ça a misérablement échoué car ma procédure de PRA n’était pas à jour. Après 30 minutes d’indispo, j’ai retrouvé les bonnes commandes… et j’ai rédigé un Post Mortem (dans un thread Twitter) !

Performances

L’an dernier, j’avais fais un GROS travail pour améliorer les performances du blog. Certaines pages mettaient extrêmement longtemps à s’afficher, ce qui n’avait pas vraiment de sens. Après un gros travail de nettoyage des plugins, mise à jour de la stack technique et ajout de cache, j’avais réussi à descendre sous la seconde.

Histoire d’optimiser encore un peu plus, j’ai suivi quelques tutos dénichés ça et là :

Mise en place de la distribution des images au format wepb (merci Nicolas Simond)
Diverses astuces pour l’optimisation d’un WordPress (encore lui !)

Voici également quelques outils qui m’ont permis de savoir vers quoi concentrer mes efforts pour améliorer les performances générales :

Je me suis concentré sur ces trois outils pour vraiment trouver les causes des problèmes de performances, mais vous pouvez en trouver d’autres (pour d’autres sujets) sur ce billet qui en liste plein d’autres.

Et enfin, plutôt que de passer par une extension pour gérer le caching du blog, j’ai correctement configuré mon frontal nginx pour le faire :

Audimétrie

Le blog a connu une TRÈS forte augmentation lors de la période de confinement en France, notamment car j’avais fait plusieurs articles sur la mise en place de Jitsi pour la visioconférence, avec un pic en avril à plus de 29000 vues, sans compter les visiteurs qui ont activé l’entête DoNotTrack (entre 25 et 50% du trafic sur mon blog, soit plus de 50k).

C’est assez colossal ; même si c’est un peu redescendu depuis (notamment cet été mais c’est tous les ans comme ça), autour de 20000-25000 vues par mois (~35000 si on ignore DNT), ça représente le double de trafic par rapport à l’an dernier, ce qui est complètement fou.

Cet été, vous avez été très nombreux à réagir à deux articles (dont un en deux parties), moins techniques :

J’essayerai de continuer à vous proposer, de temps en temps, ce genre de contenu, même si étonnamment ils réclament beaucoup plus d’efforts à rédiger.

Conclusion

Je suis très touché par tous les retours que j’ai eu ces derniers mois alors une fois de plus, je vous remercie chaleureusement.

Sur ces mots, je vous souhaite une bonne rentrée et en attendant de se retrouver : Have fun !

Mes stats dans Hugo sans Google Analytics (Matomo)

Tue, 18 Jun 2019 11:45:24 +0000

Matomo, pour faire quoi ?

La semaine dernière j’ai écris un article pour expliquer que j’étais en train de migrer de WordPress vers Hugo, mais que ce n’était pas si facile. D’abord, parce que WordPress fait PLEIN de choses (et c’est à la fois son avantage et son inconvénient) et notamment vous fournir des stats sur vos visiteurs. Et, vous vous en doutez, avec un site statique, on n’a pas ça. C’est là que Matomo rentrera en jeu…

Écraser une mouche avec un bulldozer

Alors OK, les statistiques fournies par Jetpack, ce n’est pas forcément un truc fou non plus.

En réalité, on pourrait se rapprocher de ce qu’on peut faire avec WordPress en terme de statistiques avec ce que j’avais fais lorsque je testais ElasticStack et en récupérant les stats de nginx.

Mais clairement, pour en arriver au même niveau de détail, il va falloir passer pas mal de temps à nettoyer les données de références (les logs nginx) et à concevoir les tableaux de bord (dans Kibana).

Au final, on pourra même aller encore plus loin, mais ça sera nécessairement très coûteux en temps de développement / configuration.

Méfie-toi du côté obscur. Plus rapide, plus facile, plus séduisant

Si c’est la simplicité que l’on cherche, alors clairement, le plus facile sera probablement d’ouvrir un compte Google Analytics et d’ajouter le petit bout de code fourni clé en main.

De ce point de vue, ça sera clairement le plus simple et vous aurez à votre disposition un outil à la fois simple et puissant. Et qu’importe si Google ~~espionne~~ profile (un peu plus) vos utilisateurs ?

Je vais partir du principe que si vous auto-hébergez comme moi, vous n’avez pas envie de faciliter la tâche à Google. Et c’est donc pour cela que je vous propose une autre option : Matomo.

Donc on ne sait toujours pas ce que c’est que Matomo, en fait…

Pour ceux qui l’ont connu, Matomo est le successeur de Piwik (ça vous parle peut être plus, le projet a été renommé en 2018) et permet d’obtenir un outil similaire à Google Analytics, mais open source ET que vous pouvez auto-héberger. Exit donc, Google, pour un résultat similaire et le tout chez vous. A noter, Matomo propose également une plateforme Analytics managée (payante), qui fera office de concurrent stricto sensu à Google Analytics et a priori plus vertueux envers la vie privée de vos utilisateurs (mais je n’ai pas vérifié).

Le usecase

J’ai donc sur les bras une plateforme Hugo pour le blog, sans aucune stat. Dans mon cas, Hugo est hébergé sur une plateforme CentOS / nginx. Idéalement, j’aimerai bien pouvoir garder mon Matomo sur la même machine, pour faire simple.

Et malheureusement pour moi, la plupart des gens qui ont fait des tutos sur le net ont eux installés ça sur Ubuntu (ça c’est respectable) et souvent sur Apache HTTPd (là par contre, emoji-qui-vomi).

Installation des prérequis

C’est donc parti pour installer Matomo dans un premier temps (on verra ensuite pour Hugo). La stack technique de Matomo étant basée sur PHP/MySQL, on va devoir installer php-fpm pour le moteur PHP et MariaDB.

Et comme sur CentOS, PHP et ses dépendances datent de Mathusalem, on va faire appel une fois de plus aux répos de rémi. Encore une fois, merci à lui…

sudo yum install epel-release
sudo yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
sudo yum install yum-utils
sudo yum-config-manager --enable remi-php72
sudo yum update
sudo yum install mariadb-server nginx php-fpm php-mysql php-mbstring php-dom php-xml php-gd freetype unzip wget

Dans le cas (probable) où vous souhaitez aussi avoir une meilleure localisation de vos lecteurs/visiteurs, il faudra ajouter des modules complémentaire pour GeoIP

sudo yum install gcc php-devel

Maintenant que c’est fait, on peut démarrer php-fpm et l’activer au démarrage de la machine

sudo systemctl start php-fpm
sudo systemctl enable php-fpm
sudo systemctl start mariadb
sudo systemctl enable mariadb

As usual, quand on installe pour la première fois mariadb (ou mysql), on n’oublie surtout pas de passer le petit tool de nettoyage/sécurisation “minimal” :

mysql_secure_installation

Ok, on a un moteur de base de données utilisable maintenant. On va donc créer une base et un utilisateur dédiés à Matomo :

mysql -u root -p
mysql> CREATE DATABASE matomo;
mysql> CREATE USER 'matomo'@'localhost' IDENTIFIED BY 'myawesomepassword';
mysql> GRANT ALL ON matomo.* TO 'matomo'@'localhost';
mysql> FLUSH PRIVILEGES;
exit

Installer Matomo

On a fait le tour des prérequis. On peut maintenant installer et commencer à configurer notre Matomo. Le plus simple reste de télécharger le dernier build sur le site de matomo, et de déposer les sources dans notre “dossier root” nginx :

cd /tmp
wget https://builds.matomo.org/matomo-latest.zip
unzip matomo-latest.zip
sudo mv matomo /usr/share/nginx/html

Dans les prérequis que vous auriez peut être loupés, Matomo conseille également d’ajouter un job de nettoyage dans la crontab. Ce n’est pas nécessaire pour démarrer, mais autant faire les choses bien dès le début. Pour faire simple, j’ai créé un fichier matomo-archive dans /etc/cron.d (mais un crontab -e ferait tout aussi bien l’affaire) :

cat /etc/cron.d/matomo-archive
MAILTO="awesome@email.provider"
5 * * * * nginx /usr/bin/php /usr/share/nginx/html/matomo/console core:archive --url=https://matomo.youexample.org/ > /var/log/nginx/matomo.archive.log

Ensuite, je vais partir du principe que vous allez exposer votre Matomo sur Internet, donc forcément en 443, avec une génération de certificat automatique via Let’s Encrypt.

Là c’est clairement un peu plus touchy, donc si vous voulez plus de détails sur le pourquoi du comment de chaque bloc de configuration nginx, je vous renvoie au fichier d’exemple disponible sur le github de Matomo. La subtilité par rapport au fichier d’exemple est que comme nous sommes sur CentOS et pas Ubuntu, on n’utilise pas le socket unix pour accéder à php-fpm, mais le port 9000

sudo vi /etc/nginx/sites-available/matomo.example.org.conf
server {
listen 443 ssl http2;
server_name matomo.example.org;
ssl_certificate /etc/letsencrypt/live/matomo.example.org/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/matomo.example.org/privkey.pem;
index index.php;
root /usr/share/nginx/html/matomo;
access_log /var/log/nginx/matomo.access.log;
error_log /var/log/nginx/matomo.error.log;
index index.php;
location ~ ^/(index|matomo|piwik|js/index).php {
include fastcgi.conf;
fastcgi_param HTTP_PROXY "";
fastcgi_pass 127.0.0.1:9000;
}
location = /plugins/HeatmapSessionRecording/configs.php {
include fastcgi.conf;
fastcgi_param HTTP_PROXY "";
fastcgi_pass 127.0.0.1:9000;
}
location ~* ^.+\.php$ {
deny all;
return 403;
}
location / {
try_files $uri $uri/ =404;
}
location ~ /(config|tmp|core|lang) {
deny all;
return 403;
}
location ~ /\.ht {
deny all;
return 403;
}
location ~ \.(gif|ico|jpg|png|svg|js|css|htm|html|mp3|mp4|wav|ogg|avi|ttf|eot|woff|woff2|json)$ {
allow all;
expires 1h;
add_header Pragma public;
add_header Cache-Control "public";
}
location ~ /(libs|vendor|plugins|misc/user) {
deny all;
return 403;
}
location ~/(.*\.md|LEGALNOTICE|LICENSE) {
default_type text/plain;
}
}

Maintenant que notre matomo est prêt à être accéder depuis l’extérieur, n’oubliez pas de :

Créer le record DNS pour matomo.example.org
Générer le certificat Let’s Encrypt

Activez le site en créant un lien symbolique entre sites-enabled et sites-available, vérifiez la conf et rechargez nginx

sudo ln -s /etc/nginx/sites-available/matomo.example.org.conf /etc/nginx/sites-enabled/matomo.example.org.conf
nginx -t
sudo systemctl reload nginx

A partir de maintenant, le site est accessible, à l’URL https://matomo.example.org/index.php

Éditer la configuration pour forcer le TLS puis redémarrer php-fpm

vi /usr/share/nginx/html/matomo/config/config.ini.php
[General]
salt = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
trusted_hosts[] = "matomo.example.org"
trusted_hosts[] = "blog.example.org"
force_ssl = 1

Tuner la configuration de MariaDB pour faire plaisir à Matomo

vi /etc/my.cnf
max_allowed_packet=128M
systemctl restart mariadb

Et pour finir, cette partie manque pas mal dans la doc (genre, pas documenté du tout) et me parait pourtant essentiel. Il faut compiler les modules manquants pour ajouter GeoIP 2 (libmaxminddb et MaxMind-DB-Reader-php).

wget https://github.com/maxmind/libmaxminddb/releases/download/1.3.2/libmaxminddb-1.3.2.tar.gz
tar xzf libmaxminddb-1.3.2.tar.gz && cd libmaxminddb-1.3.2
./configure
make
sudo make install
sudo ldconfig
cd ..
wget https://github.com/maxmind/MaxMind-DB-Reader-php/archive/v1.4.1.tar.gz
tar xzf v1.4.1.tar.gz && cd MaxMind-DB-Reader-php-1.4.1/ext
phpize
/configure
make
sudo make install
echo "extension=maxminddb.so" > /etc/php.d/30-maxminddb.ini
systemctl restart php-fpm

Tadaaaa !

Configurer Hugo pour ajouter le code Matomo

Cool ! Tout est correctement configuré dans Matomo. Maintenant, il faut terminer par ajouter le code de Hugo pour communiquer avec Matomo.

Pour se faire, on peut utiliser le projet suivant, qui agit comme un thème complémentaire et étend le code généré par Hugo pour inclure le code de Matomo

git submodule add https://github.com/holehan/hugo-components-matomo.git themes/matomo

Dans cet exemple, j’ajoute simplement « matomo » comme 2ème thème de mon blog static dans le fichier de configuration config.toml

theme = ["aether", "matomo"]

Et je termine par ajouter la balise suivante dans le thème que j’utilise (ici aether, donc par exemple themes/aether/layouts/partials/head.html)

{{ partial "matomo-tracking" . }}

Vie privée

Pour que tout soit vraiment terminé, il faut également ajouter la ligne suivante dans la page dédiée à la vie privée

{{ matomo-optout }}

Et voilà le travail :)

Récap’ du premier jour de KubeCon Europe 2018

Wed, 02 May 2018 22:09:43 +0000

Premier jour de KubeCon aujourd’hui !

Hier soir, je suis arrivé à Copenhague pour participer à la KubeCon + CloudNativeCon Europe 2018. Vous ne savez pas de quoi il s’agit ? C’est LA conférence sur 3 jours, organisée par la CNCF, qui parle de Kubernetes et tout ce qui gravite autour.

Ce n’est pas la première conf que je couvre sur le blog, j’avais déjà fais un récapitulatif de la Hack-It-N 2018.

On est environ 4300…

La journée a commencée par des Keynotes, ponctuées par des petites interventions de Liz Rice et Kesley Hightower. La plupart étaient un peu humoristiques, mais j’ai retenu ceci parmis les keynotes du matin :

Où en sont les projets de la CNCF ?

Keynote: CNCF Project Update - Liz Rice, Technology Evangelist, Aqua Security; Sugu Sougoumarane, CTO, PlanetScale Data; Colin Sullivan, Product Manager, Synadia Communications, Inc. & Andrew Jessup, Co-founder…

Cette année, le moins que l’on puisse dire est que la CNCF a réellement pris de l’ampleur, en terme de projets notamment.

L’ajout de plusieurs projets à l’état « Sandbox » :

Rook (abstraction du stockage), One Policy Agent (politiques de sécurité pour l’ensemble de la stack), SPIFFE (langage de spec) & SPIRE (runtime env) qui a pour but d’établir un lien de confiance entre l’infrastructure et les workloads.

Plusieurs projets sont à l’état « Incubator » :

CoreDNS, Linkerd (service mesh), Envoy (distributed proxy), Prometheus, OpenTracing, Jaeger (distributed tracing), Fluentd (Splunk Entreprise connector + fluentd daemonset for kubernetes), Fluent bit (client lightweight un peu comme Beats d’Elastic), NATS (messaging), Container Network Interface (CNI), gRPC (client/server), Container runtime (Containerd / Kubernetes CRI), TUF (The Update Framework), Notary, Vitess (distribution de données sur MySQL avec Sharding/resharding automatic)

La liste est vertigineuse.

Kubernetes est également passé à l’état « Graduated » (premier projet CNCF a passé à l’état « production ready » pour la plupart des projets informatiques, pas seulement pour les tech enthousiasts et les early adopters.

Si j’ai tout listé, c’est que l’ensemble de ces projets ont par la suite droit à une ou plusieurs confs et j’aurai l’occasion de revenir dessus si je participe aux confs en question.

Re-thinking Networking for Microservices

Keynote: Re-thinking Networking for Microservices - Lew Tucker, VP/CTO Cloud Computing, Cisco Systems, Inc.

Le CTO Cloud Computing de Cisco est venu nous expliquer que maintenir l’ensemble des services permettant au microservice d’échanger avec le monde extérieur, c’est compliqué, et qu’il vaut mieux utiliser du service mesh (découpler tous les services de communication et externes aux services comme logging, api, auth, …).

REX du CERN

Keynote: CERN Experiences with Multi-Cloud Federated Kubernetes

On ne présente pas le CERN (mais en fait on a quand même eu droit à une présentation ;-p ), mais au delà des travaux scientifiques, il faut des ops pour faire tourner la puissance de calcul brute.

10000 hyperviseurs, des quantités de données très importantes (1 Po/s généré, 10 Go/s enregistré).

Malgré cette force de frappe plus qu’honnête, lors de grosses campagnes de calculs scientifiques, il faut tirer parti de ressources externes (clouds, universités), ce qui induit la nécessité d’un outils permettant de fédérer des machines provenant de tous horizons.

Le CERN utilise la fédération de cluster de Kubernetes, avec en plus l’outil HTCondor qui étend l’API de Kubernetes et leur permet de lancer les jobs sur les machines (distantes ou pas) en fonction du job demandé.

Mini talk du VP & Chief Open Source Officer de VMware

Keynote: From Innovation to Production - Dirk Hohndel, VP & Chief Open Source Officer, VMware

Au delà du présentation plus que rapide des produits opensource sur lesquels contribue VMware, (Harbor, pivotal, BOSH), Dirk Hohndel a surtout utilisé les 5 minutes qu’il avait pour nous faire remarquer que les gens de l’audience sont en grande majorité des hommes blancs et qu’il y a un vrai problème de mixité dans nos métiers. J’ai regardé autour de moi, difficile de lui donner tort.

Et les vraies conférences ont pu commencer !

Pourquoi y a-t-il autant de runtimes ?

Whats Up With All The Different Container Runtimes? - Ricardo Aravena, Branch Metrics

Ricardo Aravena a brossé un tableau de l’évolution des containers runtimes sous Linux, puis a listé leurs avantages et leurs inconvénients. Un talk plutôt sympa en mode comparaisons et Pros/Cons sur les différents runtimes du marché.

Créer et gérer une communauté open source

Building an Open Source Community to Achieve Innovation-Through-Openness - Jonas Rosland, {code}

Un talk « non technique » auquel j’avais vraiment envie d’aller. J’avais été assez surpris de remarquer l’ouverture de Dell EMC en 2015 avec l’équipe {code}, alors forcément, un REX sur comment gérer une communauté open source et le erreurs qui ont pu être faites m’intéressait forcément.

Au final, le talk, même s’il est resté très haut niveau, a donné de bons conseils (planification de la roadmap, transparences, SIGs, focus sur les individus plus que les projets) et des ressources complémentaires (opensource.com guides, codeofconducts), qui n’existaient pas à l’époque où {code} s’est mise en place.

REX de Turbine labs a propos de leur migration de nginx vers envoy

Replacing NGINX with Envoy in a Traffic Control System - Mark McBride, Turbine Labs, Inc

Le CEO de Turbine Labs nous a fait un REX sur un changement majeur qu’ils ont eu à réaliser sur leur produit : le changement de nginx (limité pour leurs besoins spécifiques) pour Envoy. Ce changement impliquait (1) d’écrire une partie des features manquantes dans Envoy (extensions maisons spécifiques à Turbine Labs pour leurs besoins propres) et la façon la plus progressives de migrer ce composant central dans leur architecture.

Si le talk était intéressant en soit (et permet d’avoir un premier aperçu de Envoy), c’était aussi l’occasion de se poser les bonnes questions pour tout migration, qu’elle qu’elle soit.

REX Zalando, la mise à jour des clusters Kubernetes

Continuously Deliver your Kubernetes Infrastructure - Mikkel Larsen, Zalando SE

Le site de e-commerce Zalando est quelque chose d’assez énorme. On ne s’en rend pas forcément compte, mais ce sont des dizaines de clusters Kubernetes qui sont nécessaires pour gérer la partie développement des nouvelles applications.

Zalando est connue comme faisant partie des sociétés qui communiquent beaucoup sur leurs (bonnes) pratiques en terme d’IT. D’ailleurs l’amphi était plein à craquer :

Mikkel Larsen n’y a pas coupé et nous a méthodiquement expliqué pas à pas tout ce qui était mis en place pour assurer (1) des mises à jours des clusters Kubernetes complètement transparentes et quasi automatiques, et (2) des test ends to ends complet permettant de repérer des régressions mêmes subtiles.

Côté technique, Zalando travaille sur AWS, sur plusieurs availability zones, avec des Stack Cloud Formations, 1 seule AMI pour toutes les VMs, des clusters etcd externalisés des nœuds Kubernetes (rendant les masters stateless, et donc plus facile à mettre à jour), …

The Route to rootless container

The Route To Rootless Containers - Ed King, Pivotal & Julz Friedman, IBM

Je ne vais pas le cacher, je suis allé pour le titre de la conf et je n’ai pas été déçus côté clins d’œils / memes (ni par le contenu, mais c’est toujours plus agréables quand les speakers sont bons).

Si Ed King et Julz Friedman ont commencé par dire qu’ils étaient contents qu’autant de gens soient présents pour un « sujet aussi basique », le talk n’était clairement pas à destination de débutants !

Point par point, ils ont expliqué quels technologies et couches de sécurités étaient disponibles, contre quoi elle protégeaient et ne protégeaient pas. Dans une seconde partie, ils ont ensuite expliqués comment réussir à faire fonctionner des containers exécutés côté hôte par un utilisateurs non privilégié mais privilégié au sein du container. Mais surtout, pourquoi ça fonctionne et pourquoi ça n’était pas grave.

Une vraie surprise car j’avais mal compris la conf (je pensais qu’on allait expliquer comment faire pour que les applications ne soient pas root DANS le container).

Améliorer la sécurité des workloads Kubernetes avec la virtualisation matérielle

Improving your Kubernetes Workload Security with Hardware Virtualization - Fabian Deutsch, Red Hat & Samuel Ortiz, Intel

Une conf’ amusante où deux projets dont le but est de faire tourner des workloads Kubernetes dans des machines virtuelles (Kata et KubeVirt), soit disant non concurrents, ont été présentés en même temps.

La subtilité, selon eux, c’est que :

Kata containers est plutôt à destination des personnes qui souhaitent :
- ajouter une couche de sécurité/ségrégation supplémentaire à la conteneurisation simple en ajoutant l’isolation via la virtualisation matérielle
- utiliser des kernels différents pour des containers différents sur un même groupe d’hôtes Kubernetes
Kubevirt permet l’adoption plus rapide de Kubernetes en permettant l’ajout des workload de type legacy « non containerisables » dans un cluster Kubernetes. Ces workloads deviennent des Pods qui tournent dans Kubernetes, ce qui a l’immense avantage d’ajouter toutes les fonctionnalités de Kubernetes sur les Pods, mais aussi la gestion de réseau et du stockage.

A vous de me dire si vous êtes convaincus qu’il faut absolument 2 projets ;-).

Et vous reprendrez bien quelques keynotes

Anatomy of a Production Kubernetes Outage

Keynote: Anatomy of a Production Kubernetes Outage - Oliver Beattie, Head of Engineering, Monzo Bank

Un postmortem d’un incident qui a bloqué la prod d’une banque « digital native ». Très bien présenté et d’autant plus intéressant que les « erreurs » qui ont été faites tendent plus de la malchance et de fausses bonnes idées que de l’erreur a proprement parler; il était très facile de m’imaginer à la place des équipes qui ont géré cet incident.

Container Native Dev and ops Experience

Keynote: Container-Native Dev-and-ops Experience: It’s Getting Easier, Fast. - Ralph Squillace, Principal PM – Azure Container Platform, Microsoft

Je ne vais pas mentir, je suis un peu passé à côté de cette keynote. Ralph Squillace nous a fait une démo en live de code qui se déploie, se débugue et tourne sur Kubernetes pour nous prouver à quel point c’est simple. Moui, ok.

Au delà de ça, j’ai surtout remarqué que son PC était sous Ubuntu. Venant de quelqu’un qui bosse chez Microsoft (même si c’est une team Kubernetes), c’est quand même quelque chose qui aurait été impensable il y a quelques années ;-p

Cloud native observability & security

Keynote: CNCF End User Awards - Presented by Chris Aniszczyk, COO, Cloud Native Computing Foundation

Un résumé des annonces faites aujourd’hui par Google à l’occasion de la Kubecon.

gVisor, un système révolutionnaire qui va résoudre tous les pb de sécurité des containers
stackdriver, un outil de monitoring (observability) génial, qui rendre nos vies géniales

Peut être que le format était mal choisi, mais je suis extrêmement sceptique et je vais attendre d’en savoir plus ;)

Prometheus 2.0

Keynote: Prometheus 2.0 – The Next Scale of Cloud Native Monitoring - Fabian Reinartz, Software Engineer, Google

Une tonne de slides pour nous brosser l’historique de Prometheus dans un premier temps, puis nous expliquer qu’un gros problème est arrivé, la TSDB de Prometheus était trop lente sur de très gros workloads. Déluge de slides pour nous montrer à quel point Prometheus 2 est bien meilleur.

Maintenant c’est mieux.

Et demain ?

Et bien demain rebelote (enfin si je poste pas très vite, on va déjà être demain…).

Si ça vous intéresse, vous pouvez suivre les confs que je vais voir sur kccnceu18.sched.com/d.germain.

Exposer des applications containerisées Kubernetes (nginx Ingress Controller)

Tue, 06 Mar 2018 12:45:47 +0000

Ingress et Ingress Controller versus Baremetal

Autant le dire tout de suite, cet article s’adresse surtout aux admins qui font du Kubernetes (K8s pour les intimes) et en plus qui font tout eux même. Mais comme je suis sympa j’explique tout et j’ai mis des schémas si vous êtes curieux ;-).

Je vous plante le décors : vous avez suivi un de mes tutos sur Kubernetes et vous avez maintenant un cluster opérationnel en dehors des gros cloud providers (Amazon, Google, …) et de leurs solutions clés en main (sur vos propres VMs et/ou serveurs physiques). Vous êtes super contents et il y a de quoi.

Seulement voilà, maintenant que vous pouvez spawner des containers à tire larigot, vous voulez pouvoir y accéder depuis l’Internet.

Mais là, comment faire ?

Le premier problème que vous risquez d’avoir est que les applications que vous déployez dans Kubernetes ne sont de base accessibles que DANS Kubernetes.

On va être très très vite limité, niveau usecases.

Pour accéder à un container (ou faire discuter 2 containers comme un serveur web et une base de données), on passe par l’intermédiaire d’un objet appelé Service. C’est cet objet qui permet le service discovery, le scaling aisé de nos applications et la résolution de nom au sein du cluster.

Cependant, hors du cluster, pas de résolution de nom et/ou d’accès aux ressources par ce biais. Vous allez donc devoir passer par un DNS externe pour spécifier aux clients où sont vos applications et trouver un moyen de différencier quelle requête externe doit aboutir dans quelle container.

Accéder aux ressources

Le premier problème est donc de réussir à accéder à notre service. S’il est possible de créer des Services (les points d’entrées de nos containers) de type LoadBalancer sur AWS, Azure et GCP, qui ont l’avantage de permettre un accès direct au service depuis Internet (magie !), le mieux que l’on puisse faire par défaut sur un cluster Baremetal, c’est un Service de type NodePort.

Si vous n’êtes pas chez un cloud provider comme nous l’avons dit au départ, vous allez vite vous rendre compte qu’il n’est pas trivial de présenter un container sur HTTP:80 ou HTTPS:443. Car par défaut, les Services NodePort exposent nos container sur un port aléatoire compris entre 30000 et 3X000-je-sais-pas-combien (mate la précision) sur tous les nœuds du clusters.

Il y a deux choses importantes dans cette dernière phrase :

D’abord, on va se retrouver avec des URLs du type : http://@IP_node:32251 pour accéder à un serveur web depuis l’extérieur. Pas glop.
Ensuite, pour un Service de type NodePort donné, le port alloué l’est sur TOUS les membres du cluster, que le container tourne dessus ou pas. Ça veut dire que peu importe quel nœud Kubernetes on interroge, le 32251 répondra TOUJOURS sur le même container (les requêtes sont forwardé au bon nœud de manière transparente). Ça veut aussi dire qu’il n’y aura qu’un seul service qui aura le privilège d’utiliser le 32251 et aucun autre Service ne pourra le réserver.

Clairement, c’est tout sauf idéal. On se retrouve donc à différencier les applications simplement avec les numéros des ports qu’on accède.

Le DNS

Et c’est pas fini…

Si on prend un cas simple : un site web à exposer sur Internet, on va souvent vouloir relier une URL humainement compréhensible au container qui gère ce site. Cependant cette notion n’a pas vraiment de sens avec Kubernetes.

Vous ne savez pas a priori où va être instancié votre container dans le cluster (i.e. sur quelle machine et donc sur quelle IP). Ça sera un des nœuds du cluster, mais lequel ? D’autant que le Pod bouge d’un nœud à l’autre au gré de la vie de l’application (drain du node pour maintenance ou incident). Difficile donc de donner avec certitude un enregistrement DNS fiable dans le temps.

Alors bien sûr, vous pouvez toujours fixer en dur l’adresse IP d’un des nœuds Kubernetes dans un enregistrement DNS mais cette méthode trouve très vite sa limite : le moindre arrêt du serveur cause la perte de l’accès à l’application, qui pourtant a probablement été redémarrée sur un nœud du cluster.

Vous me pardonnerez ce « comic » en mode Draw.io. On s’amuse comme on peut ;-)

A quoi ça sert d’avoir un cluster dans ce cas là ?

Vous aurez peut être alors l’idée d’utiliser un moyen automatique (genre ce script qui utilise Dynhost, au hasard) pour mettre à jour le DNS dès que l’application change de nœud. Mais c’est clairement de la bidouille et on se retrouvera avec pleins d’utilisateurs dont les caches DNS ne sont pas à jour.

La méthode simple

On peut quand même bosser avec ce qu’on a et présenter à nos gentils utilisateurs des URLs user-friendly sans trop de difficultés, dans la majorité des cas.

La première chose qu’on peut faire c’est simplement mettre en face de notre cluster Kubernetes un bête reverse proxy et/ou répartiteur de charge. Après tout, c’est ni plus ni moins ce que font AWS et autre avec leur implémentation du Service de type Loadbalancer.

L’ensemble des requêtes HTTP(S) sont donc dirigées vers le reverse proxy, qui se charge de masquer la complexité de l’URL (l’aiguillage via des ports chelous et le maintiens à jour de l’ensemble des nœud du cluster qu’on arrive à contacter) à l’utilisateur final.

Personnellement, pour mes projets perso, ça m’ennuie d’avoir un composant externe au cluster K8s pour faire ça. J’ai déjà investi dans un cluster pour rendre mes applications hautement disponibles (ce qui est déjà overkill), je ne vais pas en plus :

soit ajouter un SPOF en ajoutant une seule machine pour faire mon reverse proxy
soit ajouter un cluster de machines rien que pour le reverse proxy

Et les Ingress dans tout ça ?

Donc on l’a vu, tout ça c’est pas super propre et on ajoute potentiellement un SPOF, mais ça « marche ». Mais on peut faire mieux :)

Si vous manipulez un peu Kubernetes, vous avez donc peut être vu qu’il existe un autre type d’objet qui s’appelle les Ingress et les Ingress Controllers.

Pour ceux qui n’ont pas eu le temps de potasser, un Ingress est une règle qui permet de relier une URL à un Service et un Ingress Controller est un composant qui permet de piloter un reverse-proxy pour implémenter cette règle. C’est LA méthode propre pour traduire une URL provenant d’un client en requête interne dans le cluster K8s pour atteindre le bon service.

L’Ingress Controller le plus utilisé est probablement celui pour nginx, mais il existe des Ingress Controllers pour traefik ou ha-proxy (ou autre) qui ont été développés et qui sont plus ou moins aboutis.

Helm

Helm c’est super. J’en ai parlé dans un autre article il n’y a pas longtemps, c’est un genre de gestionnaire d’application pour Kubernetes et ça simplifie grandement son utilisation. Mais il faut être honnête, ce n’est pas toujours une super idée…

Déjà, la documentation sur la page d’accueil du Chart est super light. Si vous ne trouvez pas d’infos sur comment le déployer, c’est normal, c’est parce qu’il faut aller dans le dossier « deploy » du dépôt pour trouver la doc d’installation.

Du coup, confiant, j’y suis allé avant d’avoir trouvé cette page, et je me suis pris ma première claque ;-)

helm install stable/nginx-ingress --name nginx-ingress
NAME: nginx-ingress
LAST DEPLOYED: Sun Feb 25 16:24:11 2018
NAMESPACE: default
STATUS: DEPLOYED
[...]
NOTES:
The nginx-ingress controller has been installed.

Oh cool, ça marché déjà ?

kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-7c6f79d45c-jwqkp 0/1 CrashLoopBackOff 14 47m
nginx-ingress-default-backend-6664bc64c9-2zpg4 1/1 Running 0 47m

Ah ben non en fait parce que je suis en RBAC (K8s > 1.7.0) ! Il faut créer des autorisations et un compte de service pour l’Ingress Controller.

kubectl logs nginx-ingress-controller-7c6f79d45c-jwqkp
-------------------------------------------------------------------------------
NGINX Ingress controller
Release: 0.10.2
Build: git-fd7253a
Repository: https://github.com/kubernetes/ingress-nginx
-------------------------------------------------------------------------------
I0225 16:11:13.374547 7 flags.go:159] Watching for ingress class: nginx
I0225 16:11:13.376659 7 main.go:181] Creating API client for https://10.233.0.1:443
I0225 16:11:13.438774 7 main.go:193] Running in Kubernetes Cluster version v. (v1.9.0+coreos.0) - git (clean) commit 1b69a2a6c01194421b0aa17747a8c1a81738a8dd - platform linux/amd64
F0225 16:11:13.442654 7 main.go:80] &#x2716; It seems the cluster it is running with Authorization enabled (like RBAC) and there is no permissions for the ingress controller. Please check the configuration

Ok, pas grave… On supprime et on recommence !

helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
nginx-ingress 1 Sun Feb 25 16:24:11 2018 DEPLOYED nginx-ingress-0.9.1 default
helm delete nginx-ingress
release "nginx-ingress" deleted
helm install stable/nginx-ingress --name nginx-ingress --set rbac.create=true
[...]

Bon, ne vous fatiguez pas. Ça aura l’air de marcher mais en fait, le nginx-ingress-controller se base sur un Service de type… Loadbalancer ! Si vous n’êtes pas sur AWS, GCE ou Azure, votre Service restera indéfiniment à l’état Pending en attente d’une IP publique ;-)

kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-controller LoadBalancer 10.233.52.122 80:30215/TCP,443:31438/TCP 41m
nginx-ingress-default-backend ClusterIP 10.233.29.8 80/TCP 41m

Donc on laisse tomber Helm pour cette fois

En réalité, le mieux c’est de repartir sur le projet nginx Ingress Controller, qui donne (pour qui trouve la documentation) la bonne marche à suivre pour instancier rapidement son Ingress Controller.

github.com/kubernetes/ingress-nginx
github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md#bare-metal (lien mis à jour le 08/10/2018)

Partie à exécuter dans tous les cas

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/namespace.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/default-backend.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/tcp-services-configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/udp-services-configmap.yaml \
| kubectl apply -f -

Partie spécifique à ajouter pour déployer l’Ingress Controller dans un environnement de type RBAC (K8s >= 1.7)

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/rbac.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/with-rbac.yaml \
| kubectl apply -f -

Partie spécifique à ajouter en dernier, dans le cas où on est sur un cluster baremetal (i.e. en dehors des cloud providers).

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/provider/baremetal/service-nodeport.yaml \
| kubectl apply -f -

OK, on a quoi maintenant ?

Et bien, c’est pas encore fini malheureusement… En fait, tel quel, le dernier fichier YAML qu’on a créé nous créé un service de type NodePort…

Oui vous l’avez compris : retour à la case départ ! Nous avons un composant reverse proxy intégré à K8s, mais qui est en écoute sur un port 3XXXX au lieu du 80, et 3YYYY au lieu du 443. Là encore, on aurait pas du tout ce problème si on était chez AWS, car un service de type Loadbalancer (avec une IP publique) aurait été créé pour nous.

Rassurez vous, il y a des solutions, moyennant un peu de bidouille. J’en ai trouvé 2 dans notre cas.

Pour faire simple, la première nécessite juste de modifier unfichier de configuration de Kubernetes pour autoriser le composant NodePort à utiliser des ports en dessous de la limite arbitraire des 30000. Je ne suis pas fan du tout de cette solution mais elle « fonctionne » donc je vous laisse juger.

En revanche, je trouve la seconde bien plus élégante quoique peut être un peu moins flexible. On peut modifier le Service de l’Ingress Controller en y listant toutes les adresses IPs de tous vos serveurs K8s. Ce n’est pas super confortable dans le cas où ils changent souvent, mais ça à l’effet qu’on recherche, à savoir ouvrir les ports 80 et 443 et rediriger l’ensemble des requêtes HTTP vers les Ingress.

La modification à réaliser se situe au niveau du champ externalIPs :

curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/cb876766897806ed60b1f2f36564d5f3af8a18c8/deploy/provider/baremetal/service-nodeport.yaml -o ingress-nginx-service-nodeport.yaml
vi ingress-nginx-service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: ingress-nginx
namespace: ingress-nginx
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
- name: https
port: 443
targetPort: 443
protocol: TCP
externalIPs:
- 10.0.0.1
- 10.0.0.2
- 10.0.0.3
selector:
app: ingress-nginx
kubectl apply -f ingress-nginx-service-nodeport.yaml

Normalement après application de la modification vous devriez avoir la joie (oui oui, carrément) de voir apparaitre sur tous les serveurs (que vous aurez listés) les ports 80 et 443 en écoute !!

ss -lnt
LISTEN 0 128 8.8.8.8:80 *:*
LISTEN 0 128 8.8.8.8:443 *:*

Super, et maintenant c’est bon, mon container nginx est accessible ?

Ah ben non, toujours pas. On a configuré l’Ingress Controller, mais ça fait un moment qu’on parle plus des Ingress…

Comme je l’ai dis plus haut, les Ingress sont donc les règles de notre reverse proxy, permettant de mapper les URLs entrant dans le cluster sur les ports 80 et 443 (ou autre si on en définit d’autres) vers les Services définis dans le K8s.

Heureusement c’est partie est assez simple à configurer. Voici l’exemple minimaliste d’une application dont le Service toto-app-svc écoute sur le port 8080 à l’intérieur du cluster Kubernetes. Ce service est maintenant accessible pour toute requête HTTP aboutissant sur un des noeuds du cluster et accédé avec l’URL toto.zwindler.fr.

cat nginx-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
name: nginx-ingress
spec:
rules:
- host: toto.zwindler.fr
http:
paths:
- path: /
backend:
serviceName: toto-app-svc
servicePort: 8080

Point intéressant à noter, il n’est plus nécessaire de faire du NodePort maintenant, on peut se contenter des ClusterIP par défaut. En effet, l’Ingress Controller étant interne au cluster K8s, il sait résoudre les Services sans passer par un port crado en 30000. Autant ne plus les exposer donc et bannir les NodePorts à présent !

Bon vous avez vu ? Cette dernière étape n’est pas la plus dure qu’on ait fait !

Et maintenant, à vos Ingress !