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

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. 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. Présentation de

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. Briques CoreOS
systemd fleet
Orchestration
Distribution
Linux
Gestion
Conteneurs
Init
System
Base
clef-valeur
distribuée
Gestion
Cluster

6. Architecture CoreOS

8. Docker c'est quoi déjà ?

10. CoreOS Cloud-init
Ou comment installer vos serveurs CoreOS
sans rien installer.

11. 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

12. 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";
}
}

13. 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"
}

14. 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.

15. 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).

16. 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}}

17. 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}}

18. 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

19. 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

20. Fleet
Fleet permet de gérer, sur l'ensemble d'un cluster CoreOS,
les fichiers systemd.

21. 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.

22. 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.

23. 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

24. 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

25. 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

26. CoreOS
OK
mais pour quel type d'application

27. 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

28. Codebase
Tout code doit être géré par un logiciel de suivi de version
(git, mercurial, ...).
Une application = code source

29. 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.

30. 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.

31. 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.

32. 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, ...).

33. 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.

34. Port binding
L'application fournit un service qui écoute sur un port.

35. 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.

36. 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.

37. 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.

38. 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.

39. 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.

40. 12-factors c'est bien mais...
... Comment les mettre en œuvre de façon
efficace.

41. 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).

42. Mise en production

43. 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

44. 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.

45. Par où commencer ?
Nouveaux projets.
Projet de Desktop as a Service en cours de développement.
Adapter les développements internes.

46. Questions ?