Du docker en prod? OK, parlons en

2. Comment arriver
jusqu’en production?

3. Comment arriver en production ?
• Après avoir travaillé en « local », le passage en production
n’est pas si simple,
• Vous allez devoir prendre des décisions structurantes sur
– l’organisation
– le workflow de travail
– l’architecture
– l’outillage
– …

4. Quelle organisation ?

5. Une équipe pluridisciplinaire
 Formez une équipe pluridisciplinaire
 Ne pas attendre d’avoir finalisé vos premières images avant d’aller voir les Ops
 Privilégier le « fail fast » dans la communication et dans les tests
 Les choix structurants doivent être discutés dès le départ entre les différentes
personnes de l’équipe

6. La Dream Team
 Le sponsor qui a suffisamment de poids pour appuyer les décisions ou arbitrer
certains blocages
 L’architecte qui garantira la cohérence applicative
 L’ingénieur système chargé des aspects installations de produits (docker,
registry…) et OS (choix de l’OS, configuration des Fileystem…)
 Le développeur va construire et mettre à disposition l’image applicative
 L’intégrateur est garant du paramétrage et du déploiement sur les
environnements de tests, recette
 L’exploitant va intégrer le paramétrage de production, brancher ses menus
d’exploitation, brancher la supervision, collecter les logs…
 L’expert Docker intervient de manière ponctuelle pour aider au lancement ou
pour débloquer une situation particulière

7. Quel workflow ?

8. Le workflow – Une évolution pas une révolution
• Pas de grand changement dans la façon d’interagir entre les équipes
• Seul le livrable change
• Certaines questions remonterons plus vite (où écrire les logs ? quel
user d’exécution ?...)
• Cela implique plus de proximité/dialogue/discussion entre les
équipes

9. Le Workflow de delivery
Ingénieur SysIngénieur Sys DéveloppeurDéveloppeur
Base image (OS)Base image (OS)
Librarie image
(so)
Librarie image
(so)
Image
Applicative
Image
Applicative
IntégrateurIntégrateur
Product image
(Tomcat, Weblogic,
ActiveMQ…)
Product image
(Tomcat, Weblogic,
ActiveMQ…)
Paramétrage
Applicatif
Paramétrage
Applicatif
ExploitantExploitant
Orchestration
Mechanism
Orchestration
Mechanism
Paramétrage
Applicatif
Paramétrage
Applicatif
Orchestration
Mechanism
Orchestration
Mechanism
Expert DockerExpert Docker
ArchitecteArchitecte
TopologieTopologie TopologieTopologie

10. Quelle architecture
physique ?

11. Quel OS ?
 Quel OS ?
 Linux 64 bits
 Kernel récent (3.10) pour bénéficier de toutes les fonctionnalités de Docker
 Attention au compatibilité d’OS et aux versions Docker supportées :
 RedHat/CentOS 6.5 minimum
 RedHat/CentOS 6.7 pour Docker 1.7.1 maximum
 RedHat/CentOS 7.x pour toutes les versions de Docker
 Ubuntu 12.04, 14.04, 15.10
 Debian 7.7, 8
 Une distribution dédiée à Docker ?
 RancherOS
 CoreOS

12. Serveur physique ou virtuel ?
 Docker fonctionne sur les deux architectures (bare metal ou virtuel)
 Dépend de la typologie de vos applications (besoin de performance I/O)
 Avez-vous un programme de sortie de la virtualisation ?
 Avez-vous besoin d’optimiser au mieux vos serveurs ?
 Faites vous de l’hébergement multi-tenant ?

13. Que mettre dans mon
image ?

14. Quelle image de base ?
 Est-ce que je peux utiliser une image du Hub ?
 Dois-je reconstruire une image avec mon OS complet ?
 Préférez des images légères ne contenant que ce qui est nécessaire
 Plus facile à faire évoluer
 Plus léger, donc portable
 Moins de surface à couvrir pour les failles de sécurité

15. Que mettre dans mon image ?
• Mon application
– Stateless : application Front ou middle
– Statefull : oui mais dépend de la partie statefull. Nécessitera peut-être un
storage driver particulier.
• Ma configuration d’application
– Non et Oui
• Non pour ne pas avoir des images environnement dépendant
• Oui dans le cadre de l’utilisation de data volume (confd FTW!)
• Base de données
– Oui pour la partie développement
– Non pour la partie production

16. Comment découper mes images
• Une image doit correspondre à un module de votre application (un WS, une
IHM, un broker…)
• Permet de découpler le cycle de vie
• Permet de scaler plus facilement le module

17. Découper mon application en images
LBLB
IHMIHM
LoadBalancerLoadBalancer
IHMIHM
Web serviceWeb service
CacheCache
BDDBDD
IHMIHM
WSWS WSWS WSWS
CacheCache CacheCache
BDDBDD

18. Où stocker ses images ?

19. Mettre en place sa registry
 Le Hub en public ou privé via abonnement
 La Docker Trusted Registry
 Une Registry privée en SaaS (Quay.io, Aws, ...)
 Une registry v2 selfhosted

20. Registry v2 Self Hosted
 Se baser sur l’image du Hub
 Attention à la configuration par défaut
 Prévoir un espace de stockage pour les images
 Monitorer l’espace disponible
 Prévoir des namespaces différents pour les équipes et/ou les images
production ready

21. Registry v2 Self Hosted
 Nécessité d’outiller la registry
 Pas d’IHM (possibilité d’utiliser des images du hub)
 Pas d’outil de nettoyage (purge des images)
 Peu de sécurité
 Pas d’alerting…

22. Construire les images ?

23. Construire vos images
• Le processus de construction automatique d’une image est
très simple
• L’intégrer dans vos outil d’intégration continue
• Utiliser le mécanisme de tag pour versionner vos images
• N’ajouter que ce qui est nécessaire

24. Construire vos images
• Garder en tête les bonnes pratiques de création d’images
• Attention au nombre de layer créés
• Attention à la taille du répertoire de construction d’image
(utilisez le .dockerignore) pour ne pas saturer le daemon
docker
• Attention à l’utilisation du cache local

25. The maven effect !

26. The maven effect ! Ne téléchargez pas tout Internet
• Attention à l’utilisation de la bande passante
– Une image fait entre 4Mo et 1Go sur le Hub
• Mettre en place un proxy (fonctionnalité de la registry v2)
• Mettre à disposition un catalogue d’entreprise (Rancher,
Registry v2, DTR)

27. Ou la gestion de mes logs

28. Où écrire mes logs ?
• Prendre en compte cette problématique dès le départ
• Plusieurs log drivers disponibles
– Json-file (default)
– Syslog (UDP, TCP, TCP+TLS, Unix socker)
– Awslog (AWS)
– Gelf (Graylog ou Logstask pour ELK)
– Fluentd
– journald
– splunk

29. Mes logs près de mes containers
• Utilisation du volume disk (un répertoire du host)
• Attention au UID du user d’écriture des logs
• Attention les logs du container ne sont pas gérés par défaut
(activer la rotation)

30. La collecte des logs
• L’application publie dans la sortie standard
• Aucun logs ne reste stocké sur le container
• Utilisation du driver GELF pour envoi vers ELK
• Facilite le diagnostic et la remontée d’erreur

31. Faire parler des
containers entre eux

32. Docker et la gestion du Réseau
• Le daemon Docker attribut une adresse IP au container à sa création,
cette IP est locale à la machine (pénurie IPv4)
• Possibilité de publier le port du container sur le port du Host
– Ex : Tomcat : 80 sur Host et 8080 dans le container
• Deux containers sur des machines différentes ne pourront pas
communiquer naturellement (utilisation de port publiés)
• Gestion du network overlay avec Swarm, Rancher, Flannel, Calico ou
Weave

33. Jusqu’ici tout va bien
• Je travaille dans un environnement maîtrisé
– Nombre de containers connus à l’avance
– Utilisation des ports connus
– Tous les containers tournent sur une même machine
– Pas ou peu d’évolution de l’architecture
• L’utilisation de Docker Compose peut suffire
– Description de mon application via un fichier yml
– Possibilité de scaler facilement une partie de l’application

34. Architecture distribuée et maitrisée
• La machines sont typées (front, middle, cache…)
• Des containers répartis sur des machines différentes
• Nécessité de publier des ports sur les hosts
• Configuration statique entre container

35. Comment gérer le load balancing ?
• Gestion statique/à la main des loadbalancer
• Découverte de service (etcd, consul, zookeeper, fleet…)
• Traefik un reverse proxy intelligent
– Rechargement à chaud et via API
– Supporte plusieurs backend (Docker, Consul, etcd, Zookeeper,
Mesos/Marathon, file…)
– Ajoute ou supprime un container sur la base de label et du
backend choisi

36. L’utilité d’un orchestrateur
• Je ne veux pas redévelopper un système de répartition de mes
containers
• Mon architecture est changeante
• Je ne veux pas devoir me poser la question de où lancer mes
containers
• Je veux injecter des contraintes
• Je veux m’abstraire de la communication entre containers

37. Quels orchestrateurs ?
+

38. Vos interlocuteurs
Youcef Yekhlef
Architecture
&
Culture Devops
@youcef_yekhlef
youcef.yekhlef@zenika.com
Christophe Furmaniak
Architecture
&
Culture Devops
@looztra
christophe.furmaniak@zenika.com

39. Contactez-nous
• info@zenika.com
• Tél : 01 45 26 19 15
• Notre site web :
• www.zenika.com
•
• Notre blog technique :
• blog.zenika.com
•
•
• Twitter : @ZenikaIT