Jonathan Raffre | Jean-Pascal Thiery

1

Exploitation de conteneurs en production

Qui sommes nous ?

Jean-Pascal Thiery

@jpthiery

2

Jonathan Raffre

@nekonyuu

Exploitation de conteneurs en production

Docker ? rkt ? kezako ?Applications livrées en conteneurs

▼ L’évolution des paradigmes d’architecture motivent de plus en plus la livraison de conteneurs applicatifs

▽ Pattern microservices

▽ The Twelve-Factor App - https://12factor.net/

▼ Applications self-contained▽ aucune dépendance avec l’environnement système !

▽ l’ensemble de l’environnement d’exécution peut être testé et versionné avec l’application

“Build, Ship, and Run Any App, Anywhere”

Docker

3

Exploitation de conteneurs en production

Des conteneurs en production ?

4

Exploitation de conteneurs en production

Qu’attend la production ?“Ops Needs”

▼ Métrologie

▼ Supervision

▼ Alerting

5

Exploitation de conteneurs en production

Pourquoi la production a peur ?Les limites de l’approche actuelle

▼ Un serveur est lié à une application de manière “permanente”

▼ Métriques d’application laissées au middleware (Tomcat,

Websphere)

▼ La supervision et la métrologie sont souvent liés

▽ Utilisation d’outils “tout-en-un”: Zabbix, HPOV, Centreon, ...

6

Exploitation de conteneurs en production

▼ Outils actuels conçus autour d’une approche serveur/agent

▽ Ils montrent déjà leurs limites en contexte cloud “scale-out”

▼ Centralisation de logs peu répandue

▼ Une approche centrée sur le serveur et non sur l’application dans son ensemble !

7

Pourquoi la production a peur ?Les limites de l’approche actuelle

Exploitation de conteneurs en production

8

Nouveau paradigme

9

Exploitation de conteneurs en production

Nouvelles contraintesUn référentiel système instable

▼ Un changement d’approche qui s’impose▽ “J’installe comment mon agent de supervision / métriques ?”▽ “Comment j’audite ce que les administrateurs font dans le conteneur ?”

▼ Une machine peut héberger plusieurs conteneurs d’applications différentes▽ “Que fait le conteneur d91457f5-89d8-45da-a307-276792240224 ?”▽ “À quelle application correspondent ces logs ?”

10

Exploitation de conteneurs en production

▼ Un conteneur n’est qu’une unité d’exécution de l’application

▼ La disparition et l’apparition de conteneurs est un phénomène normal▽ La mise à jour d’un conteneur passe par son remplacement

▽ L’emplacement d’un conteneur n’est pas important pour son fonctionnement

▼ Leur emplacement ne doit pas être une information importante (sauf incident matériel)

▼ Un hôte héberge maintenant plusieurs applications, dont les logs n’ont rien à voir

▽ Nécessité d’identification de chaque ligne de log

11

Pet versus CattleLa mort de la spécificité

Exploitation de conteneurs en production

▼ Les architectures microservices profitent de ce mouvement

▽ La disponibilité d’une application ne dépend plus d’un seul “service” système

▽ Nécessité de centraliser les logs et métriques pour une vision d’ensemble

▼ Les conteneurs démarrent, s’arrêtent, sont remplacés, se déplacent de serveur en serveur

▽ Le lien application/serveur est dynamique, il doit devenir non-important

▼ Nous devons implémenter une vue globale de l’application, agnostique des serveurs !

12

Application plutôt que serveursUne vision d’ensemble

Exploitation de conteneurs en production

▼ Un conteneur va changer régulièrement de serveur

▼ Un conteneur ne doit pas stocker de données métier, doit être immutable▽ Les vérifications système liées à l’application deviennent caduques

▼ Les mises à jour de sécurité doivent être fait en amont, par l’intégration continue

▼ Qu’est-ce que je dois encore vérifier sur un conteneur ?

▼ Quid d’un modèle où les conteneurs se déclarent eux même et exposent leurs métriques ?

13

Panique à bord“Ma supervision centralisée ne sert plus à rien ?!”

Vue d’ensemble de l’application

14

Exploitation de conteneurs en production

Pourquoi ?Sélection des informations pertinentes

▼ Se focalise sur le point important d’une plateforme: le service qu’elle fournit

▼ Exposer des informations plus pertinentes et accessibles par le métier

15

Exploitation de conteneurs en production

Agrégation de logsConstruction d’une vue d’ensemble

16

▼ Centralisation des logs à un seul endroit

▽ Facilite leur exploration▽ Permet de corréler simplement plusieurs évènements !

▼ Événements système : syslog/rsyslog▼ Événements conteneurs :

▽ rkt : intégration avec journald + syslog▽ docker : plugin syslog▽ Logging sur stdout nécessaire

Exploitation de conteneurs en production

Agrégation de logsExtraction depuis Docker - syslog log driver

▼ $ cat /etc/docker/daemon.json

{ "log-driver": "syslog"}

▼ Tagger un conteneur

▽ docker run --log-opt tag=my-awesome-nginx nginx:latest

17

Exploitation de conteneurs en production

Agrégation de logsExtraction depuis rkt - journald + syslog

▼ Forward des logs journald vers syslog▽ $ cat /etc/systemd/journald.conf

[Journal]ForwardToSyslog=yes

18

Exploitation de conteneurs en production

Agrégation de logsIdée : Envoi vers Kafka avec rsyslog

▼ Kafka - File de messages distribuée▽ Garantit la remise des logs et absorbe les pics de charge

▼ rsyslog : input et output Kafka (im/omkafka) depuis la v8.7.0

19

Exploitation de conteneurs en production

rsyslogOne daemon to rule them all

▼ Connu du monde Ops et réputé stable▽ Installé ou disponible dans toutes les distributions

▽ Meilleure adoption opérationnelle

▼ Intégration système déjà effectuée par la distribution▽ 50% de l’intégration déjà faite

▼ Il existe d'autres options ! - beats, fluentd

20

Exploitation de conteneurs en production

$ cat /etc/rsyslog.conftemplate( name="jsonLogFormat" type="string" string="{ %timegenerated:::date-rfc3339,jsonf:timestamp%, %source:::jsonf:source_host%, \"message\":\"%timestamp% %app-name%:%msg:::json%\", \"fields\":{ %syslogfacility-text:::jsonf:facility%, %syslogseverity-text:::jsonf:severity%, %app-name:::jsonf:program%, %procid:::jsonf:processid% } }"action(type="omkafka" topic="app_log" partitions.auto="on" broker=[ kafka.1.xebia.io ] template="jsonLogFormat")

21

rsyslogOne daemon to rule them all

Exploitation de conteneurs en production

Agrégation de logsIndexer et exploiter ces logs

22

Exploitation de conteneurs en production

PitfallsLogs Waterfall

▼ “Mais à quelle application correspond ce conteneur….?”▽ Ajout de contexte

■ machine source, id du conteneur, service (via tag)

▽ Docker intègre la plupart de ces infos dans ses logs https://docs.docker.com/engine/admin/logging/syslog/

▼ “J’ai trop de logs !”▽ N'envoyez pas forcément tous vos logs▽ … mais attention à ne pas trop filtrer pour le futur

23

Exploitation de conteneurs en production

▼ “Et mon agent d’APM/NewRelic/AppDynamics ?”▽ Certains éditeurs fournissent des agents spécifiques à Docker

▽ La plupart des frameworks de métriques fournissent des méthodes d’export vers statsd

▽ Il devient aussi à la charge de l’application de remonter les métriques

24

Récupération de métriquesRéutiliser l'existant

Exploitation de conteneurs en production

Récupération de métriquesAvoir des indicateurs métiers et techniques

▼ Les logs nous permettent de voir les évènements de manière chronologique▽ Quid des métriques système, business ?

▼ Il reste donc le problème des applications ...

25

Exploitation de conteneurs en production

▼ Applications : via des frameworks applicatifs

▽ metrics, kamon, scales, pyformance, ... ▽ Implémentation de métriques adaptées au fonctionnel !

▼ Système, conteneurs : via des daemons système

▽ telegraf, collectd, cAdvisor, …▽ Ces outils se chargent de récupérer les métriques système typiques : CPU, RAM, Disque, …

▼ Agrégation des métriques : Stockage de séries de temps et requêtes

▽ Prometheus, InfluxDB, Carbon/Graphite▽ Gestion de la rétention, de l'échantillonnage et du requêtage des données

Avec quel outil ?

26

Récupération de métriques

▼ Daemon de collecte de métriques

▽ Empreinte mémoire et CPU basse (développé en C)

▽ Open-Source et maintenu

▽ Plugins divers et variés pour la collecte et l'envoi

■ Système : CPUs, RAM, Disque

■ Middlewares : Varnish, Redis, MySQL, MongoDB, ...

■ Graphite, RabbitMQ, Kafka, InfluxDB, Prometheus, ...■ https://collectd.org/wiki/index.php/Table_of_Plugins

Exploitation de conteneurs en production

Couteau suisse des métriques

27

Exemple: collectd

Exploitation de conteneurs en production

28

Hostname "my_server"LoadPlugin syslogLoadPlugin cpuLoadPlugin dfLoadPlugin loadLoadPlugin memoryLoadPlugin networkLoadPlugin write_graphite

<Plugin tcpconns> AllPortsSummary false LocalPort "25" RemotePort "25"</Plugin>

<Plugin write_graphite> <Node "graphitenode1"> Host "my_graphite" Prefix "my.metrics.prod" </Node></Plugin>

Couteau suisse des métriquesExemple: collectd

Exploitation de conteneurs en production

Graph !

29

Récupération de métriques

Exploitation de conteneurs en production

▼ Testez, testez, testez !

▼ Nommage de vos métriques et labellisation

▽ Les dashboards dépendent de ce nommage▽ Attention à ne pas surcharger la normalisation, les labels sont aussi là !

30

PitfallsY U NO NORMALIZE

Exploitation de conteneurs en production

31

Architecture finale

Notification de problèmes

32

L’alertingde manière intelligente

▼ Effectuer les checks sur des points névralgiques de la plateforme▽ Accès aux points d'entrée critiques (sur HAProxy, Traefik, …)

■ Implémentation d'un endpoint validant la santé de l'application■ Il sera utilisé par votre orchestrateur !

▽ Vérification de la présence d’une balise validant le fonctionnement “end-to-end”■ À prévoir dans la conception des applications !

▽ Santé de vos systèmes de cluster (Mesos, Kubernetes, Swarm, …)■ Via les métriques collectées précédemment !

33

Exploitation de conteneurs en production

L’alertingpour être proactif

▼ Vue d'ensemble comme base de notre alerting

▼ Discuter des métriques fonctionnelles significatives et s'y restreindre▽ Nombre de messages traités

▽ Temps de latence “end-to-end” d’une requête

▽ Ne pas tomber dans l'excès, limiter les alertes !

34

Exploitation de conteneurs en production

L’alertingpour être proactif

▼ Surveiller les tendances, plutôt que des valeurs absolues▽ Nombre moyen de messages selon les périodes (“rush hour”, nuit, …)

▽ Patterns d’utilisation CPU / réseau

▽ Taux de croissance de l'occupation disque

▽ Permet d’agir avant l’incident et de réduire les faux positifs

35

Exploitation de conteneurs en production

Attentionvous pourriez vous faire mal

▼ Ne multipliez pas les outils

▼ Infrastructure as Code▽ Terraform/CloudFormation/Google Deploy Manager▽ Ansible/SaltStack/Chef

▼ Faites usage au maximum de templating lorsque c’est possible▽ Kibana + paramètres

▽ http://docs.grafana.org/reference/templating/

36

Exploitation de conteneurs en production

Attentionvous pourriez vous faire mal

▼ Ne sous-estimez pas la volumétrie des données que vous allez devoir gérer :

▽ Multitude de sources de données (nombre de serveurs, d’applications)

■ Load à un instant t importante

▽ Attention à la durée de rétention (logs et métriques)

37

Exploitation de conteneurs en production

38

39

Jonathan Raffre | Jean-Pascal Thiery

40