Présentation CoreOS
-
Upload
gcatt -
Category
Presentations & Public Speaking
-
view
127 -
download
0
Transcript of Présentation CoreOS
Du concept à la mise en productionPrésentation CoreOS de est mise à disposition selon les termes de la @CattGr licence Creative Commons Attribution 4.0 International
En 40 minutes ou plus1. Présentation de CoreOS2. Installation avec Cloud Config3. Etcd4. Fleet5. Quel type d'application ?6. Mise en production
Présentation de
Comparaison entre un Hyperviseur etCoreOS
Hardware
Host OS (Linux)
Hyperviseur Type 2
OpenStack
VM
Guest OS
Data App
Hyperviseur Type 2
VMdockerdockerdocker
VMdockerdockerdocker
HardwareHyperviseur Type 1 (ESXi)Management (vSphere/vCenter)
VM
Guest OS
Data App
Hyperviseur Type 1
VMdockerdockerdocker
VMdockerdockerdocker
Data AppData App
Hardware
Host OS (Linux)
Conteneurs Docker
dockerdockerdocker
OS X/WindowsDocker Daemon
dockerdockerdocker
dockerdockerdocker
dockerdockerdocker
VirtualBoxVM Boot2docker
dockerdocker
dockerdockerdocker
HardwareCoreOS
CoreOS
dockerdockerdocker
cluster
dockerdockerdocker
dockerdockerdocker
dockerdockerdocker
dockerdocker
dockerdockerdocker
CoreOSCoreOS CoreOS
Briques CoreOS
systemd fleet
Orchestration
DistributionLinux
GestionConteneurs
InitSystem
Baseclef-valeurdistribuée
GestionCluster
Architecture CoreOS
Docker c'est quoi déjà ?
CoreOS Cloud-initOu comment installer vos serveurs CoreOS
sans rien installer.
Cloud ConfigCoreOS-cloudinit permet à un administrateur de
personnaliser ses machines CoreOS en fournissant undocument 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
dhcp pxe/ipxeNous avons mis en place un serveur ipxe qui fournit à chaqueserveur 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"; }
}
Images ipxeLes 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"}
Channels CoreOSStable Beta Alpha
Le canal Stable estutilisable enproduction.Chaque nouvelleversion livrée a étélonguement testée.
Dans le canalBeta, onretrouve lesversions Alphaayant unecertainestablilité.
Le canal Alpha suit de près le travailde développement en cours et estmis à jour fréquemment. Lesdernières versions de docker, etcdet fleet seront disponibles pour lestests.
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 commedans un système de fichiers.Supervision d'une clef ou d'un répertoire pour détecter unchangement.Possibilité de fixer un verrou ou une durée de vie (TTL).Découverte des nœuds (static, etcd, dns).
Positionner une valeur$ ssh 10.0.0.1CoreOS beta (xxx.x.x)$ etcdctl set /foo "Hello world"Hello world$ curl -L -X PUT http://127.0.0.1:2379/v2/keys/bar -dvalue="Hello world"{"action":"set","node":{"key":"/bar","value":"Helloworld","modifiedIndex":1943007,"createdIndex":1943007}}
Récupérer une valeur$ ssh 10.0.0.1CoreOS beta (xxx.x.x)$ etcdctl get /fooHello world$ curl -L http://127.0.0.1:2379/v2/keys/bar{"action":"get","node":{"key":"/bar","value":"Helloworld","modifiedIndex":1943007,"createdIndex":1943007}}
Cluster EtcdPour un déploiement large (supérieur à 10 nœuds) il est
conseillé d'avoir un nombre de bases etcd limité, afin de nepas passer trop de temps à obtenir le corum.
Cluster etcd Worker
Cluster actif etcd et tolérance de panneMembre(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
FleetFleet permet de gérer, sur l'ensemble d'un cluster CoreOS,
les fichiers systemd.
Ordonnancement avec FleetLa 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 certainsmembres 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 ensemblesur un même serveur.
Fleet + etcdFleet a besoin d'une vue complète du cluster pour répartirces 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 desmachines est stocké dans etdc.
Fleetctl list-machinesPour que fleet fonctionne, la base etcd doit être accessible en
lecture/écriture.core@coreos1 ~ $ fleetctl list-machinesMACHINE IP METADATA32a89c4b... 10.0.0.21 location=dsi,plateform=kvm,version=681.0.09b2fc7d5... 10.0.0.22 location=dsi,plateform=kvm,version=681.0.0ff9f347b... 10.0.0.23 location=dsi,plateform=kvm,version=681.0.0c93c01c0... 10.0.0.24 location=dsi,plateform=kvm,version=681.0.0
Exemple service Global : cadvisor.service[Unit]Description=Google Container AdvisorRequires=docker.socketAfter=docker.socket
[Service]ExecStartPre=/bin/sh -c "docker history google/cadvisor:latest >/dev/null || docker pull google/cadvisor:latest"ExecStart=/usr/bin/docker run --rm --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8080:8080 --name=cadvisor google/cadvisor:latestRestart=alwaysRestartSec=20s
[Install]WantedBy=multi-user.target
[X-Fleet]Global=true
Gestion des units avec fleetctlcore@coreos1 ~ $ fleetctl load cadvisor.serviceTriggered global unit cadvisor.service load
core@coreos1 ~ $ fleetctl list-unit-filesUNIT HASH DSTATE STATE TARGETcadvisor.service 85f57eb loaded - global
core@coreos1 ~ $ fleetctl start cadvisor.serviceTriggered global unit cadvisor.service start
core@coreos1 ~ $ fleetctl list-unitsUNIT MACHINE ACTIVE SUBcadvisor.service 32a89c4b.../10.0.0.21 active runningcadvisor.service 9b2fc7d5.../10.0.0.22 active runningcadvisor.service c93c01c0.../10.0.0.24 active runningcadvisor.service ff9f347b.../10.0.0.23 active running
core@coreos1 ~ $ fleetctl stop cadvisor.serviceTriggered global unit cadvisor.service stop
CoreOS
OKmais pour quel type d'application
The Twelve Factors12 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
CodebaseTout code doit être géré par un logiciel de suivi de version(git, mercurial, ...).Une application = code source
DependenciesToutes les dépendances doivent être clairement précisées.Le système cible n'est pas censé contenir de programmepré-installé.Pas de dépendances implicites.
ConfigEst considéré comme configuration, tous ce qui diffère d'unenvironnement à l'autre (dev, qualif, prod, autre site).Tout élément de configuration doit être passé par desvariables d'environnement.Il ne doit y avoir absolument aucune référence à laconfiguration dans le code.
Backing ServicesUn 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.
Build, release, runOn recrée l'application et l'environnement avant toutdéploiement d'une nouvelle version.Aucune modification n'est apportée sur l'applicationdéployée.Chaque version déployée a un numéro de version unique(timestamp, numero de commit, ...).
ProcessesL'application est exécutée dans l'environnementd'exécution en tant qu'un ou plusieurs processus.Toutes les données doivent être stockées dans uneressource externe (base de données).Les variables de sessions utilisateurs ne doivent jamais êtrestockées localement.
Port bindingL'application fournit un service qui écoute sur un port.
ConcurrencyChaque application peut être mise à l'echelle. Lesconteneurs peuvent être lancés x fois pour répartir lacharge.Le programme dans le conteneur ne doit pas être lancé entâche de fond.L'arrêt du programme entraîne l'arrêt du conteneur.
DisposabilityLe conteneur doit être jetable.Il doit donc pouvoir être lancé très rapidement.Un arrêt intempestif ne doit pas compromettre lesdonnées.
Dev/prod parityLe développeur doit pouvoir déployer rapidement le codequ'il vient de finir d'écrire.Le développeur doit être plus proche du déploiement(DevOps).Maintenir le développement et la production aussisemblables que possible en utilisant les mêmes outils.Éviter de prendre des backends différents en prod et endev (ex: base de données, ...) pour limiter les surprises enproduction.
LogsLes applications doivent externaliser leurs journaux pour lavisualisation et l'archivage à long terme (ELK, Spunk,rsyslog ...).Les journaux peuvent s'afficher dans la sortie standard del'application, mais pas dans un fichier du conteneur.
Admin processLes commandes d'administration doivent s'exécuter dansun environnement identique aux autres processusd'exploitation.Même conteneur, mêmes variables d'environnement, maisen mode interactif.
12-factors c'est bien mais...... Comment les mettre en œuvre de façon
efficace.
Les Micro-servicesUn système distribué basé sur des micro-services qui
communiquent via des files de messages.
Beaucoup de Micro-services plutôt qu'un programmemonolithique.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 (exAMQP).
Mise en production
Avantages de la solutionLa perte d'un serveur est transparente pour l'utilisateur.Le système d'exploitation est sécurisé et optimisé pourdocker.Moins de 5 minutes pour installer un nouveau serveurCoreOS.Quelques secondes pour déployer une nouvelleapplication.Mise à jour d'un CoreOS = un reboot
ConstatActuellement peu d'applications de notre SI sont12 factors.Fleet est un outil simple et efficace, mais son intégrationdans notre SI nécessite le développement de quelquesoutils complémentaires.Des solutions plus complètes telles que Kubernetes ouMesos permettent de gérer des conteneurs sur des milliersde serveurs CoreOS.De nombreux outils de répartition de charge (lancés dansdes conteneurs) sont capables d'interroger etcd pour sereconfigurer automatiquement.
Par où commencer ?Nouveaux projets.Projet de Desktop as a Service en cours de développement.Adapter les développements internes.
Questions ?