Présentation CoreOS

1 902 vues

Publié le

La présentation est également disponible au format html ici : http://gauthierc.github.io/SlideCoreOS/

0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 902
Sur SlideShare
0
Issues des intégrations
0
Intégrations
17
Actions
Partages
0
Téléchargements
34
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Présentation CoreOS

  1. 1. Du concept à la mise en production Présentation CoreOS de est mise à disposition selon les termes de la@CattGr licence Creative Commons Attribution 4.0 International
  2. 2. En 40 minutes ou plus 1. Présentation de CoreOS 2. Installation avec Cloud Config 3. Etcd 4. Fleet 5. Quel type d'application ? 6. Mise en production
  3. 3. Présentation de
  4. 4. Comparaison entre un Hyperviseur et CoreOS Hardware Host OS (Linux) Hyperviseur Type 2 OpenStack VM Guest OS Data App Hyperviseur Type 2 VM docker docker docker VM docker docker docker Hardware Hyperviseur Type 1 (ESXi) Management (vSphere/vCenter) VM Guest OS Data App Hyperviseur Type 1 VM docker docker docker VM docker docker docker Data App Data App Hardware Host OS (Linux) Conteneurs Docker docker docker docker OS X/Windows Docker Daemon docker docker docker docker docker docker docker docker docker VirtualBox VM Boot2docker docker docker docker docker docker Hardware CoreOS CoreOS docker docker docker cluster docker docker docker docker docker docker docker docker docker docker docker docker docker docker CoreOSCoreOS CoreOS
  5. 5. Briques CoreOS systemd fleet Orchestration Distribution Linux Gestion Conteneurs Init System Base clef-valeur distribuée Gestion Cluster
  6. 6. Architecture CoreOS
  7. 7. Docker c'est quoi déjà ?
  8. 8. CoreOS Cloud-init Ou comment installer vos serveurs CoreOS sans rien installer.
  9. 9. Cloud Config CoreOS-cloudinit permet à un administrateur de personnaliser ses machines CoreOS en fournissant un document Cloud Config au format YAML. #cloud-config coreos: units: - name: etcd2.service command: start users: - name: core passwd: $1$allJZawX$00S5T756I5PGdQga5qhqv1 write_files: - path: /etc/resolv.conf content: | nameserver 192.0.2.2 nameserver 192.0.2.3
  10. 10. dhcp pxe/ipxe Nous avons mis en place un serveur ipxe qui fournit à chaque serveur CoreOS son image de boot et son fichier cloud-init. Le serveur obtient ces informations via le serveur dhcp. host coreos1 { hardware ethernet 1e:3f:4e:53:1f:52; next-server 10.0.0.11; fixed-address 10.0.0.21; server-name "coreos1.mondomaine"; if exists user-class and option user-class = "iPXE" { filename "http://10.0.0.11:4777/?profile=production"; } else { filename "undionly.kpxe"; } }
  11. 11. Images ipxe Les images sont téléchargées sur le site de CoreOS. Une version de CoreOS est spécifiée pour chaque profil. Exemple de fichier config: production.json # cat production.json { "cloud_config": "production", "console": ["tty0", "tty1"], "coreos_autologin": "tty1", "rootfstype": "btrfs", "root": "LABEL=ROOT", "version": "681.0.0" }
  12. 12. Channels CoreOS Stable Beta Alpha Le canal Stable est utilisable en production. Chaque nouvelle version livrée a été longuement testée. Dans le canal Beta, on retrouve les versions Alpha ayant une certaine stablilité. Le canal Alpha suit de près le travail de développement en cours et est mis à jour fréquemment. Les dernières versions de docker, etcd et fleet seront disponibles pour les tests.
  13. 13. Solution Opensource de stockage de clef-valeur distribuée. API Http en lecture/écriture via curl ou etcdctl. Clefs et valeurs stockées dans une arborescence comme dans un système de fichiers. Supervision d'une clef ou d'un répertoire pour détecter un changement. Possibilité de fixer un verrou ou une durée de vie (TTL). Découverte des nœuds (static, etcd, dns).
  14. 14. Positionner une valeur $ ssh 10.0.0.1 CoreOS beta (xxx.x.x) $ etcdctl set /foo "Hello world" Hello world $ curl -L -X PUT http://127.0.0.1:2379/v2/keys/bar -d value="Hello world" {"action":"set","node":{"key":"/bar","value":"Hello world","modifiedIndex":1943007,"createdIndex":1943007}}
  15. 15. Récupérer une valeur $ ssh 10.0.0.1 CoreOS beta (xxx.x.x) $ etcdctl get /foo Hello world $ curl -L http://127.0.0.1:2379/v2/keys/bar {"action":"get","node":{"key":"/bar","value":"Hello world","modifiedIndex":1943007,"createdIndex":1943007}}
  16. 16. Cluster Etcd Pour un déploiement large (supérieur à 10 nœuds) il est conseillé d'avoir un nombre de bases etcd limité, afin de ne pas passer trop de temps à obtenir le corum. Cluster etcd Worker
  17. 17. Cluster actif etcd et tolérance de panne Membre(s) Actif(s) Majorité Tolérance de panne 1 membre 1 membre Aucune 3 membres 2 membres 1 membre 4 membres 3 membres 1 membre 5 membres 3 membres 2 membres 6 membres 4 membres 2 membres 7 membres 4 membres 3 membres 8 membres 5 membres 3 membres 9 membres 5 membres 4 membres
  18. 18. Fleet Fleet permet de gérer, sur l'ensemble d'un cluster CoreOS, les fichiers systemd.
  19. 19. Ordonnancement avec Fleet La directive systemd [X-Fleet] permet d'étendre le fonctionnement des scripts systemd. Global : lance un unit systemd sur l'ensemble des nœuds. MachineMetadata : ne lance un unit que sur certains membres du cluster (en fonction du Metadata). Conflits : permet d'exclure 2 units incompatibles pour éviter qu'ils ne tournent sur le même serveur. MachineOf : inversement, permet de lier 2 units ensemble sur un même serveur.
  20. 20. Fleet + etcd Fleet a besoin d'une vue complète du cluster pour répartir ces units sur l'ensemble des nœuds actifs. Quels units tournent sur le serveur ? Quelles machines fonctionnent dans le cluster ? Chaque fichier unit, chaque état des process, état des machines est stocké dans etdc.
  21. 21. Fleetctl list-machines Pour que fleet fonctionne, la base etcd doit être accessible en lecture/écriture. core@coreos1 ~ $ fleetctl list-machines MACHINE IP METADATA 32a89c4b... 10.0.0.21 location=dsi,plateform=kvm,version=681.0.0 9b2fc7d5... 10.0.0.22 location=dsi,plateform=kvm,version=681.0.0 ff9f347b... 10.0.0.23 location=dsi,plateform=kvm,version=681.0.0 c93c01c0... 10.0.0.24 location=dsi,plateform=kvm,version=681.0.0
  22. 22. Exemple service Global : cadvisor.service [Unit] Description=Google Container Advisor Requires=docker.socket After=docker.socket [Service] ExecStartPre=/bin/sh -c "docker history google/cadvisor:latest >/dev/nul l || docker pull google/cadvisor:latest" ExecStart=/usr/bin/docker run --rm --volume=/:/rootfs:ro --volume=/var/r un:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/ docker:ro --publish=8080:8080 --name=cadvisor google/cadvisor:latest Restart=always RestartSec=20s [Install] WantedBy=multi-user.target [X-Fleet] Global=true
  23. 23. Gestion des units avec fleetctl core@coreos1 ~ $ fleetctl load cadvisor.service Triggered global unit cadvisor.service load core@coreos1 ~ $ fleetctl list-unit-files UNIT HASH DSTATE STATE TARGET cadvisor.service 85f57eb loaded - global core@coreos1 ~ $ fleetctl start cadvisor.service Triggered global unit cadvisor.service start core@coreos1 ~ $ fleetctl list-units UNIT MACHINE ACTIVE SUB cadvisor.service 32a89c4b.../10.0.0.21 active running cadvisor.service 9b2fc7d5.../10.0.0.22 active running cadvisor.service c93c01c0.../10.0.0.24 active running cadvisor.service ff9f347b.../10.0.0.23 active running core@coreos1 ~ $ fleetctl stop cadvisor.service Triggered global unit cadvisor.service stop
  24. 24. CoreOS OK mais pour quel type d'application
  25. 25. The Twelve Factors 12 recommandations pour un déploiement sans soucis. 1. Codebase 2. Dependencies 3. Config 4. Backing Services 5. Build, release, run 6. Processes 7. Port binding 8. Concurrency 9. Disposability 10. Dev/prod parity 11. Logs 12. Admin process http://12factor.net
  26. 26. Codebase Tout code doit être géré par un logiciel de suivi de version (git, mercurial, ...). Une application = code source
  27. 27. Dependencies Toutes les dépendances doivent être clairement précisées. Le système cible n'est pas censé contenir de programme pré-installé. Pas de dépendances implicites.
  28. 28. Config Est considéré comme configuration, tous ce qui diffère d'un environnement à l'autre (dev, qualif, prod, autre site). Tout élément de configuration doit être passé par des variables d'environnement. Il ne doit y avoir absolument aucune référence à la configuration dans le code.
  29. 29. Backing Services Un backing service est une ressource externe au conteneur (base mysql, smtp, activemq, memcache, ...). L'accès à ces ressources doit être passé en paramètre. Pas de distinction entre les services locaux et distants.
  30. 30. Build, release, run On recrée l'application et l'environnement avant tout déploiement d'une nouvelle version. Aucune modification n'est apportée sur l'application déployée. Chaque version déployée a un numéro de version unique (timestamp, numero de commit, ...).
  31. 31. Processes L'application est exécutée dans l'environnement d'exécution en tant qu'un ou plusieurs processus. Toutes les données doivent être stockées dans une ressource externe (base de données). Les variables de sessions utilisateurs ne doivent jamais être stockées localement.
  32. 32. Port binding L'application fournit un service qui écoute sur un port.
  33. 33. Concurrency Chaque application peut être mise à l'echelle. Les conteneurs peuvent être lancés x fois pour répartir la charge. Le programme dans le conteneur ne doit pas être lancé en tâche de fond. L'arrêt du programme entraîne l'arrêt du conteneur.
  34. 34. Disposability Le conteneur doit être jetable. Il doit donc pouvoir être lancé très rapidement. Un arrêt intempestif ne doit pas compromettre les données.
  35. 35. Dev/prod parity Le développeur doit pouvoir déployer rapidement le code qu'il vient de finir d'écrire. Le développeur doit être plus proche du déploiement (DevOps). Maintenir le développement et la production aussi semblables que possible en utilisant les mêmes outils. Éviter de prendre des backends différents en prod et en dev (ex: base de données, ...) pour limiter les surprises en production.
  36. 36. Logs Les applications doivent externaliser leurs journaux pour la visualisation et l'archivage à long terme (ELK, Spunk, rsyslog ...). Les journaux peuvent s'afficher dans la sortie standard de l'application, mais pas dans un fichier du conteneur.
  37. 37. Admin process Les commandes d'administration doivent s'exécuter dans un environnement identique aux autres processus d'exploitation. Même conteneur, mêmes variables d'environnement, mais en mode interactif.
  38. 38. 12-factors c'est bien mais... ... Comment les mettre en œuvre de façon efficace.
  39. 39. Les Micro-services Un système distribué basé sur des micro-services qui communiquent via des files de messages. Beaucoup de Micro-services plutôt qu'un programme monolithique. Chaque Micro-service fait une seule chose mais la fait bien (Philosophie Unix). Les Micro-services sont déployés indépendamment. Ils communiquent en utilisant des files de messages (ex AMQP).
  40. 40. Mise en production
  41. 41. Avantages de la solution La perte d'un serveur est transparente pour l'utilisateur. Le système d'exploitation est sécurisé et optimisé pour docker. Moins de 5 minutes pour installer un nouveau serveur CoreOS. Quelques secondes pour déployer une nouvelle application. Mise à jour d'un CoreOS = un reboot
  42. 42. Constat Actuellement peu d'applications de notre SI sont 12 factors. Fleet est un outil simple et efficace, mais son intégration dans notre SI nécessite le développement de quelques outils complémentaires. Des solutions plus complètes telles que Kubernetes ou Mesos permettent de gérer des conteneurs sur des milliers de serveurs CoreOS. De nombreux outils de répartition de charge (lancés dans des conteneurs) sont capables d'interroger etcd pour se reconfigurer automatiquement.
  43. 43. Par où commencer ? Nouveaux projets. Projet de Desktop as a Service en cours de développement. Adapter les développements internes.
  44. 44. Questions ?

×