Télécharger en tant que ODP, PPTX
Téléchargé parChristophe Furmaniak
Rex docker en production meeutp-docker-nantes
Le document traite du passage de l'environnement de développement à la production en mettant l'accent sur l'organisation d'une équipe pluridisciplinaire, les décisions architecturales et le choix des outils. Il souligne la nécessité d'avoir un workflow de livraison efficace et aborde également des considérations techniques sur la construction d'images Docker et la gestion des logs. Enfin, il évoque l'importance des orchestration et des pratiques de gestion des containers pour garantir une architecture distribuée et maîtrisée.
Rex docker en production meeutp-docker-nantes
- 2.
- 3. Comment arriver enproduction ? • 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.
- 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.
- 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 dedelivery 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.
- 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 ouvirtuel ? 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 dansmon image ?
- 14. Quelle image debase ? 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 dansmon 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 mesimages • 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 applicationen images LBLB IHMIHM LoadBalancerLoadBalancer IHMIHM Web serviceWeb service CacheCache BDDBDD IHMIHM WSWS WSWS WSWS CacheCache CacheCache BDDBDD
- 18. Où stocker sesimages ?
- 19. Mettre en placesa 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 SelfHosted 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 SelfHosted 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.
- 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.
- 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 gestionde mes logs
- 28. Où écrire meslogs ? • 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èsde 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 deslogs • 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 containersentre eux
- 32. Docker et lagestion 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 vabien • 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 etmaitrisé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 leload 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.
- 38. Vos interlocuteurs Youcef Yekhlef Architecture & CultureDevops @youcef_yekhlef [email protected] Christophe Furmaniak Architecture & Culture Devops @looztra [email protected]
- 39. Contactez-nous • [email protected] • Tél: 01 45 26 19 15 • Notre site web : • www.zenika.com • • Notre blog technique : • blog.zenika.com • • • Twitter : @ZenikaIT