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 ?