Les équipes de développement se tournent de plus en plus vers des architectures orientées conteneurs. Une fois les POCs validés, il faut songer à la mise en production de ces solutions. Jonathan est administrateur systéme, il a mis en place et exploité des solutions conteneurisées dont certaines architectures dites ‘star wars’ (cf Devoxx 2015). Jean-Pascal est développeur backend, il a développé Kodo Kojo, une solution de provisionning d’usine logicielle fortement basée sur des conteneurs. Au cours de cette présentation, ils vont vous présenter les solutions permettant de connaître l’état de vos clusters de conteneurs à un instant T.

1. Jonathan Raffre | Jean-Pascal Thiery
1

2. Exploitation de conteneurs en production
Qui sommes nous ?
Jean-Pascal Thiery
@jpthiery
2
Jonathan Raffre
@nekonyuu

3. 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

4. Exploitation de conteneurs en production
Des conteneurs en production ?
4

5. Exploitation de conteneurs en production
Qu’attend la production ?
“Ops Needs”
▼ Métrologie
▼ Supervision
▼ Alerting
5

6. 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

7. 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

8. Exploitation de conteneurs en production
8

9. Nouveau paradigme
9

10. Exploitation de conteneurs en production
Nouvelles contraintes
Un 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

11. 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 Cattle
La mort de la spécificité

12. 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 serveurs
Une vision d’ensemble

13. 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 ?!”

14. Vue d’ensemble de l’application
14

15. 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

16. Exploitation de conteneurs en production
Agrégation de logs
Construction 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

17. Exploitation de conteneurs en production
Agrégation de logs
Extraction 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

18. Exploitation de conteneurs en production
Agrégation de logs
Extraction depuis rkt - journald + syslog
▼ Forward des logs journald vers syslog
▽ $ cat /etc/systemd/journald.conf
[Journal]
ForwardToSyslog=yes
18

19. Exploitation de conteneurs en production
Agrégation de logs
Idé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

20. Exploitation de conteneurs en production
rsyslog
One 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

21. Exploitation de conteneurs en production
$ cat /etc/rsyslog.conf
template(
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
rsyslog
One daemon to rule them all

22. Exploitation de conteneurs en production
Agrégation de logs
Indexer et exploiter ces logs
22

23. Exploitation de conteneurs en production
Pitfalls
Logs 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

24. 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étriques
Réutiliser l'existant

25. Exploitation de conteneurs en production
Récupération de métriques
Avoir 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

26. 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

27. ▼ 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

28. Exploitation de conteneurs en production
28
Hostname "my_server"
LoadPlugin syslog
LoadPlugin cpu
LoadPlugin df
LoadPlugin load
LoadPlugin memory
LoadPlugin network
LoadPlugin 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étriques
Exemple: collectd

29. Exploitation de conteneurs en production
Graph !
29
Récupération de métriques

30. 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
Pitfalls
Y U NO NORMALIZE

31. Exploitation de conteneurs en production
31
Architecture finale

32. Notification de problèmes
32

33. L’alerting
de 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

34. L’alerting
pour ê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

35. L’alerting
pour ê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

36. Attention
vous 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

37. Attention
vous 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. 38

39. 39

40. Jonathan Raffre | Jean-Pascal Thiery
40