Du concept à la mise en production
Présentation CoreOS de est mise à disposition selon les termes de la@CattGr licence Cre...
En 40 minutes ou plus
1. Présentation de CoreOS
2. Installation avec Cloud Config
3. Etcd
4. Fleet
5. Quel type d'applicat...
Présentation de
Comparaison entre un Hyperviseur et
CoreOS
Hardware
Host OS (Linux)
Hyperviseur Type 2
OpenStack
VM
Guest OS
Data App
Hype...
Briques CoreOS
systemd fleet
Orchestration
Distribution
Linux
Gestion
Conteneurs
Init
System
Base
clef-valeur
distribuée
G...
Architecture CoreOS
Docker c'est quoi déjà ?
CoreOS Cloud-init
Ou comment installer vos serveurs CoreOS
sans rien installer.
Cloud Config
CoreOS-cloudinit permet à un administrateur de
personnaliser ses machines CoreOS en fournissant un
document C...
dhcp pxe/ipxe
Nous avons mis en place un serveur ipxe qui fournit à chaque
serveur CoreOS son image de boot et son fichier...
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.
Ex...
Channels CoreOS
Stable Beta Alpha
Le canal Stable est
utilisable en
production.
Chaque nouvelle
version livrée a été
longu...
Solution Opensource de stockage de clef-valeur distribuée.
API Http en lecture/écriture via curl ou etcdctl.
Clefs et vale...
Positionner une valeur
$ ssh 10.0.0.1
CoreOS beta (xxx.x.x)
$ etcdctl set /foo "Hello world"
Hello world
$ curl -L -X PUT ...
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/v...
Cluster Etcd
Pour un déploiement large (supérieur à 10 nœuds) il est
conseillé d'avoir un nombre de bases etcd limité, afi...
Cluster actif etcd et tolérance de panne
Membre(s) Actif(s) Majorité Tolérance de panne
1 membre 1 membre Aucune
3 membres...
Fleet
Fleet permet de gérer, sur l'ensemble d'un cluster CoreOS,
les fichiers systemd.
Ordonnancement avec Fleet
La directive systemd [X-Fleet] permet d'étendre le
fonctionnement des scripts systemd.
Global : ...
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 u...
Fleetctl list-machines
Pour que fleet fonctionne, la base etcd doit être accessible en
lecture/écriture.
core@coreos1 ~ $ ...
Exemple service Global : cadvisor.service
[Unit]
Description=Google Container Advisor
Requires=docker.socket
After=docker....
Gestion des units avec fleetctl
core@coreos1 ~ $ fleetctl load cadvisor.service
Triggered global unit cadvisor.service loa...
CoreOS
OK
mais pour quel type d'application
The Twelve Factors
12 recommandations pour un déploiement sans soucis.
1. Codebase
2. Dependencies
3. Config
4. Backing Se...
Codebase
Tout code doit être géré par un logiciel de suivi de version
(git, mercurial, ...).
Une application = code source
Dependencies
Toutes les dépendances doivent être clairement précisées.
Le système cible n'est pas censé contenir de progra...
Config
Est considéré comme configuration, tous ce qui diffère d'un
environnement à l'autre (dev, qualif, prod, autre site)...
Backing Services
Un backing service est une ressource externe au conteneur
(base mysql, smtp, activemq, memcache, ...).
L'...
Build, release, run
On recrée l'application et l'environnement avant tout
déploiement d'une nouvelle version.
Aucune modif...
Processes
L'application est exécutée dans l'environnement
d'exécution en tant qu'un ou plusieurs processus.
Toutes les don...
Port binding
L'application fournit un service qui écoute sur un port.
Concurrency
Chaque application peut être mise à l'echelle. Les
conteneurs peuvent être lancés x fois pour répartir la
char...
Disposability
Le conteneur doit être jetable.
Il doit donc pouvoir être lancé très rapidement.
Un arrêt intempestif ne doi...
Dev/prod parity
Le développeur doit pouvoir déployer rapidement le code
qu'il vient de finir d'écrire.
Le développeur doit...
Logs
Les applications doivent externaliser leurs journaux pour la
visualisation et l'archivage à long terme (ELK, Spunk,
r...
Admin process
Les commandes d'administration doivent s'exécuter dans
un environnement identique aux autres processus
d'exp...
12-factors c'est bien mais...
... Comment les mettre en œuvre de façon
efficace.
Les Micro-services
Un système distribué basé sur des micro-services qui
communiquent via des files de messages.
Beaucoup d...
Mise en production
Avantages de la solution
La perte d'un serveur est transparente pour l'utilisateur.
Le système d'exploitation est sécurisé...
Constat
Actuellement peu d'applications de notre SI sont
12 factors.
Fleet est un outil simple et efficace, mais son intég...
Par où commencer ?
Nouveaux projets.
Projet de Desktop as a Service en cours de développement.
Adapter les développements ...
Questions ?
Présentation CoreOS
Présentation CoreOS
Prochain SlideShare
Chargement dans…5
×

Présentation CoreOS

2 140 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
2 140
Sur SlideShare
0
Issues des intégrations
0
Intégrations
17
Actions
Partages
0
Téléchargements
45
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 ?

×