Containers et configuration 

De la promesse au concret avec git et confd

Alexandre Garnier ( zigarn)

Présentation aimablement prêtée
par Christophe Furmaniak

• Qui utilise docker régulièrement ?
• En production ?
• Avec un orchestrateur ?

• Oui, les containers (ou plutôt les images) sont un moyen pratique (voire élégant ?) de packager vos apps
• Mais ⇒ Tous vos environnements (runtime) ne sont pas égaux !
• Qu'en est-il de votre configuration (runtime) ?
• Combien d'environnements devez-vous gérer au fait ?
  • Dev, ..., QA, ..., Prod
• Combien d'équipes (en terme de responsabilités/droits d'accès [RBAC]) ?

Les containers ne sont pas (au premier abord) le facilitateur pour vos problématiques de configuration d'environnement

• Fichiers de configuration "human readable"
  • "server.conf" et compagnie
  • text/yaml/json/toml/xml/properties
• Fichiers binaires (ou presque)
  • Certificats
  • Ce qui a un rapport avec le chiffrement
• Vos secrets !

Tout ce qui permet à vos apps d'intéragir avec leur écosystème !

• Comment apporter la configuration dans vos containers ?
• Comment générer la configuration pour vos containers ?
• Comment gérer sa configuration ?
  • Historique, versions
  • RBAC
  • Comment partager des bouts de configuration entre applications et/ou entre environnements ?

• Docker tout seul ⇒ "Pet docker"
• Docker à fond ⇒ "Cattle docker"
  ⇒ Orchestration FTW !
  (Swarm, Kubernetes, DC/OS Mesos+Marathon, Openshift, Rancher, Nomad, Titus, Deis, Tectonic, Mantl, Kontena, ...)

• Front : AngularJs + nginx
• Gateway : springboot
• Filtre : springboot
• Service  de stockage: springboot
• Couche de stockage : redis

Frontend → Gateway ↔ Filter Service

Apporter la configuration par le biais de variables d'environnement

• 1 Image qui package votre app
• La partie configuration dynamique est exposée à votre app par des variables d'env
  • Ça ne fonctionne pas pour les "fichiers binaires"
  • Dans la vraie vie on apporte souvent beaucoup de variables : ça peut vite devenir douloureux
  • Problème de séparation des responsabilités

docker run -t -d \
  -w /home/user/dev/work-dir \
  -v /home/user/dev/work-dir:/work:rw \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  -e ******** -e ******** -e ******** -e ******** -e ******** \
  mycompany/myimage:v1.0.2
					

Intégrez votre app et sa configuration dans la même image

1. 1 image qui embarque votre app
2. ajout de la configuration "au dessus"
   FROM myapp:1.3.2 ⇒ myapp-prod:1.3.2

PAS BIEN !!

• Ce ne sera pas la même image sur tous les envs
• Vous devrez tout reconstruire à chaque nouvelle version (même si la conf ne change pas)

Fournissez la config par le biais des volumes "mappés" sur le host docker

docker run -v /data/env/prod:/data ...
					

PAS BIEN !!

Êtes vous sur de vouloir préférer les animaux de compagnie au bétail ?

Créez des containers dédiés pour la configuration

1. 1 image pour votre application
2. 1 image pour chaque environnement
3. Les 2 containers résultant assemblés par le biais du --volumes-from (ou équivalent)

Utilisons un service de configuration

1. 1 image pour votre application
2. 1 (ou plusieurs) services/serveurs hébergeant votre configuration distante
   • Netflix Archaius (#link)
     • Java uniquement 😞
   • Spring Cloud Config (#link)
     • Super méga cool pour les apps Spring(boot)
     • Besoin d'introduire du code pour l'utiliser dans d'autres apps java ou autres langages

• OK pour le "même image quelque soit l'env"
• Points négatifs
  • Potentiellement très intrusif
    • La plupart du temps : NO-GO pour les applis "anciennes" car trop de modifs
  • Attention : désormais ces serveurs/services de configuration distante sont un nouveau composant de votre appli

Swarm configs et secrets

1. 1 image pour votre appli
2. Des configs et secrets pour stocker vos valeurs d'environnement
   • Les configs et secrets sont stockés au niveau cluster Swarm
   • Permettent de peupler des fichiers :
     • /{config-name} pour les configs (ou autre via target)
     • /run/secrets/{secret-name} pour les secrets

Kubernetes (et dérivés) ConfigMaps

1. 1 image pour votre appli
2. Des objets "ConfigMap" pour stocker vos valeurs d'environnement
   • Les ConfigMap sont stockés au niveau cluster Kubernetes
   • Peuvent-être utilisés pour
     • Peupler des vars d'env
     • Enrichir les "commandes" des containers
     • Peupler des fichiers

Nous avons besoin :

• De tracer son historique
• De pouvoir s'appuyer sur des modèles pour la partager plus facilement entre les environnements
• RBAC / Gestion des droits
• De pouvoir partager des éléments de config
  • Entre les environnements
  • Entre les applications

• Git pour la gestion de l'historique et des droits
• Confd pour les modèles
• Une structure de répertoires hierarchisée pour le partage d'éléments

Note : Un dépôt git peut contenir la configuration d'une ou plusieurs applications

Confd ?

• "Lightweight configuration management tool"
• S'appuie sur des modèles (golang text templates)
• Sources de "valeurs" : vars d'env, consul, etcd, zookeeper, redis, vault, dynamodb, ...
• Project initié par Kelsey Higthower
• http://www.confd.io

confd-data-container-generator

• Générateur de data-container avec la base confd pour le backend "env"
• Va aussi gérer des fichiers (au lieu de seulement des valeurs)
• nodevops/confd-data-container-generator

Les utilisateurs collaborent sur la configuration par le biais de git et de la structure hiérarchisée

├── data
│   ├── dev-local (rep)
│   ├── acc-1 (rep)
│   ├── prod (rep)
│   └── common (rep)
└── dictionaries
    ├── dev-local (rep)
    ├── acc-1 (rep)
    ├── prod (rep)
    └── common.dict (fic)
					

Les tags Git permettent de figer
une "version pour un env"

• v0.2.3_dev-local
• v0.2.4_acc-1
• v0.2.4_dev-local
• v0.2.4_prod
• v0.2.5_acc-1

Les images des apps embarquent les modèles de fichier

└── src
    ├── main
    │   ├── confd
    │   │   ├── conf.d
    │   │   └── templates
    │   ├── java
    │   │   └── net
    │   ├── resources
    │   └── scripts
    └── test
        └── java
            └── net
					

filter:
  sanitize:
    url: /api/v1/filter/sanitize
guestbook:
  messages:
    url: /api/v1/guestbook/messages
info:
  custom:
    env: {{ getv "/guestbook/shared/info/custom/env" }}
    message: {{ getv "/guestbook/filter/info/custom/message" }}
					

Les images de configuration embarquent les fichiers bruts et les valeurs pour les modèles sous la forme de vars d'environnement

└── config
    ├── dictionnaries
    │   └── env.sh
    └── data
        ├── dummy.txt
        └── filterDefinition.properties
					

Containers d’application :

• Démarrés avec les volumes des containers de config
• Lancement d’un wrapper qui :
  • Génère la config en assemblant :
    • Les modèles présent dans le container d'appli
    • Les valeurs présentes dans le container de configuration
  • Démarre l'appli qui utilise la config générée et les fichiers bruts

• Compatible avec
  • Solution#3/data-containers
  • Solution#5/Solution orchestrateur
• Ça marche aussi avec des applications qui ne sont pas dans des containers !!!

• Proposer de prendre en compte les sources Consul et Etcd
  • La version de la configuration sera intégrée dans la définition du namespace côté consul et etcd

• Plus d'outils
  • Diff entre environnements ( dépôt, démo)
  • Comparer une clé+valeur sur tous les environnements (idem)
  • Lister les clés inutilisées dans les dict
  • Appli Web facilitant la contribution à la configuration d'utilisateurs moins techniques

(Bientôt sur nodevops)

• nodevops/confd-data-container-generator
• nodevops/dict-explorer
• looztra/guestbook-api-server
• cfurmaniak/guestbook-configuration-confd
• nodevops/confd-maven-plugin

Merci

Des questions ?