Notre voyage vers le déploiement continu avec micro-services, la conteneurisation et l'orchestration des conteneurs utilisant Kubernetes. Sur notre chemin, nous avons dû créer divers outils pour nous aider à mieux utiliser et tester le tout avant d'aller en production. Nous avons également intégré une variété d'autres outils pour nous donner de la visibilité sur notre plate-forme. Cette conférence sera un aperçu de notre voyage jusqu'à maintenant. Our journey towards continuous deployment with micro-services, containerization and orchestration of containers using Kubernetes. On our way there, we've had to create various tools to help us better use and test everything before going to production. We also had to integrate a variety of other tools to give us visibility on our platform. This talk will be an overview of our journey up to now.

1. Micro-services
sous Docker et
Kubernetes
Présentation:
Sébastien Coutu

2. Qui suis-je?
● Tech lead DevOps chez Mnubo, startup IoT
● 5 ans dans le monde Big Data
● 19 ans d’expérience en opérations.
● Amateur d’escalade et d’ébénisterie.

3. Qu’est-ce que mnubo offre?
● Une plateforme SaaS pour l’analytique de données d’objets connectés
● “Data”, “Analytics”, “Intelligence” as a service
● Marchés visés:
○ Produits consommateurs
○ Produits commerciaux
○ Agriculture
○ Industriel léger

4. ● Des applications quasi-monolithiques
● Des performances très variables
● Des déploiements à tous les quelques mois: les nouvelles fonctionnalités
se faisaient attendre trop longtemps.
● Des déploiements qui prennent entre 6 à 12 heures à exécuter.
L’architecture des services de mnubo il y a 2 ans.

5. ● Identifier où le temps est perdu.
● Identifier les changements architecturaux requis pour changer la
situation.
● Identifier les technologies pouvant aider à changer la situation.
● Mettre en place les bons éléments humains pour pousser le changement.
Comment donner un coup de barre?

6. Pourquoi une infrastructure basée sur des micro-services?
● Afin d’éviter des blocs monolithiques d’applications
● Afin d’être capable de “scaler” indépendamment les différents
composants.
● Afin d’améliorer la vitesse de mise en production des fonctionnalités.
● Afin d’améliorer la vélocité générale du développement.

7. Premier composant de la solution: Docker
Cas d’utilisation typiques:
● Environnements avec micro-services
● Intégration continue
● Déploiement continu: déploiements automatisés
“Une plateforme ouverte pour applications distribuées pour développeurs et
administrateurs de systèmes.”
- Source
http://www.docker.com

8. Pourquoi des conteneurs?
● Packaging
○ Toutes les dépendances sont “bundlées” à l’intérieur du conteneur
○ Aucun conflit de versions possible
○ Diminue les “moving parts” lors de mises à jour.
● Simplification des serveurs
○ Seul requis au niveau des opérations est de fournir un kernel et
une version de docker compatible.
○ Les conteneurs sont isolés entre eux.
○ Il est possible de restreindre les ressources allouées aux
conteneurs.

9. Pourquoi des conteneurs?
● Simplification de l’automatisation
○ Conventions requises entre les opérations et le développement.
○ La même “image” est utilisée sur le laptop du développeur, en
intégration, en QA et sur le serveur de production.
● Réutilisation des couches identiques.
○ Chaque conteneur est bâti en utilisant des couches qui sont
réutilisables entre les images.
○ Espace disque utilisé est minimisé sur les serveurs.
○ Rapidité de téléchargement des couches différentes seulement.

10. Prochain composant de la solution: Kafka
Cas d’utilisation typiques:
● Messaging
● Agrégation de logs et de métriques
● Tracking d’activité web
● Stream processing
● Event sourcing
“Kafka est une plateforme de streaming distribuée”
- Source:http://kafka.apache.org

11. Prochain composant de la solution:
Persistance des données

12. Les technologies de base sont identifiées, ensuite?
● Migration d’un modèle semi-monolithique vers un modèle de
micro-services
● La multiplication des micro-services
● L’architecture d’un pipeline qui “scale”
● Révision complète des outils de build
● Révision complète des outils de déploiement

13. Rendre les micro-services immuables
● S’assurer que les configurations ne changent pas.
○ Définir des environnements au besoin
○ Maximiser l’utilisation de paramètres par défaut
○ Ne PAS utiliser de nom d’hôte dans les fichiers de configuration, toujours des alias.
● Éviter les différences entre les environnements.
○ Certaines ne peuvent être évitées: Paramètres RAM, nombre de réplicas, etc.
● Utiliser les mêmes conteneurs du laptop du développeur/Jenkins jusqu’à
la production.

14. Déployer et orchestrer les micro-services
● Nous désirons déployer les micro-services là où il y a des ressources
disponibles.
● Nous désirons maximiser l’utilisation des machines abritant les
micro-services.
● Nous désirons accéder dynamiquement et répartir la charge entre les
conteneurs d’une même application.

15. Prochain composant de la solution:
Déploiement et orchestration des conteneurs

16. Assembler les micro-services sous une même adresse
● En premier lieu: routage HTTP fait par un serveur Apache
○ Beaucoup de coupures de sessions lors de changement d’API.
○ Health-checking non adéquat
● En second lieu: routage HTTP fait par HAproxy
○ Scale beaucoup mieux mais aucune modification programmatique facile.
● Maintenant: Séparation de la couche d’encryption SSL et du routage HTTP

17. Prochain composant de la solution:
Routage d’API HTTP

18. Prochain composant de la solution:
Visibilité sur l’infrastructure

19. ● Une plateforme basée sur plus de 20 micro-services.
● Des performances prévisibles.
● De multiples déploiements chaque jour sont possibles.
● Les “downtime” ne sont plus requis pour la majorité des déploiements.
● Plus de 80% du pipeline est automatisé.
L’architecture des services de mnubo aujourd’hui

20. ● Jenkins
● Docker Registry
● SBT
● Gitlab
● Artifactory
Outils d’infrastructure

21. Crédits image

22. Deuxième Partie: Google Kubernetes
Crédits image

23. Qu’est-ce que Kubernetes (K8s)?
● Un système d’orchestration de conteneurs Docker.
● Il permet de placer dynamiquement les conteneurs là où les ressources
sont disponibles.
● Il comporte un système d’auto-découverte pour router les requêtes là où
les conteneurs sont démarrés.

24. Où trouver Kubernetes?
● La documentation et le lien vers les sources sont disponibles sur
http://kubernetes.io/
● Kubernetes est disponible en ligne chez Google avec le Google Container
Engine (GKE)
● Le projet fourni également des instructions pour l’installation locale ou
sur plusieurs fournisseurs “cloud”.

25. Principaux éléments de Kubernetes
● Master
● Worker node
● Compte de services
● Namespace
● Pod

26. Principaux éléments de Kubernetes (suite)
● Volume
● Label
● Service
● Replication Controller
● Secret

27. Architecture de K8s sous Docker (local)
● Déploiement simple
“tout-en-un” sur la
même machine.
● Permet de se
familiariser avec les
différents composants.
● Fonctionnalité complète
présente.
* Image tirée de la documentation de Kubernetes

28. Architecture de K8s sous Docker (multi-noeud)
● Les noeuds de travail
doivent avoir une
connectivité réseau
directe (flanneld) entre
les Pods.
● Les composants
peuvent être mis en
haute-disponibilité.
● Déploiement typique de
production.
* Image tirée de la documentation de Kubernetes

29. Comment configurer et interagir avec Kubernetes
● En utilisant l’API HTTP(s)
● À l’aide de l’utilitaire kubectl, utilitaire CLI se connectant à l’API HTTP.
● En utilisant un des modules Python:
○ kubernetes-py*
○ python-kubernetes-wrapper
○ pykube
○ python-k8sclient
● En utilisant des outils d’automatisation:
○ Salt
○ Puppet
○ Ansible
* Avertissement: Je suis l’auteur de cette librairie mise en ligne par mnubo.

30. Définition d’un objet
● La définition d’un objet permet à Kubernetes de comprendre ce que
l’usager désire accomplir.
● Elle peut être écrite en YAML ou en JSON. (YAML est préférable)
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

31. Création d’un Pod
● Créer un fichier avec la définition du Pod, ensuite:
● Vérifier que le Pod a bel et bien été créé:
$ kubectl create -f docs/user-guide/walkthrough/pod-nginx.yaml
$ kubectl get pod
● Pour effacer le Pod
$ kubectl delete pod nginx
● En supposant que l’IP du Pod est accessible tester l’accès au Pod
$ curl http://$(kubectl get pod nginx -o go-template={{.status.podIP}})

32. Persistance des données - Volumes
● Les volumes permettent de persister les données de Pod au travers de
redémarrage de conteneurs et même selon le volume, au travers de
redémarrage sur différents noeuds.
● Ils sont définis au niveau du Pod:
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
…
volumes:
- name: redis-persistent-storage
emptyDir: {}

33. Persistance des données - Volumes (Suite)
● Ils sont par la suite associés à un ou plusieurs conteneurs pour être
utilisés.
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis
ports:
- containerPort: 6389
volumeMounts:
- name: redis-persistent-storage
mountPath: /data/redis
volumes:
- name: redis-persistent-storage
emptyDir: {}

34. Grouper des Pod - Labels
● Pour sélectionner des Pod une fois créés, nous utilisons des “labels”:
● Les “labels” seront par la suite utilisés pour cibler des Pod:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
$ kubectl get pods -l app=nginx

35. Accéder des Pod via un Service
● Un service permettra
d’exposer un port réseau
d’un ou plusieurs Pod à
d’autres.
● Ils sont utilisés comme
système de découverte
automatisé.
● Ils utilisent des “labels”
comme sélecteurs pour
cibler un ou des Pod.
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
ports:
- port: 8000 # the port that this service should serve on
# the container on each pod to connect to, can be a name
# (e.g. 'www') or a number (e.g. 80)
targetPort: 80
protocol: TCP
# just like the selector in the replication controller,
# but this time it identifies the set of pods
# to load balance traffic to.
selector:
app: nginx

36. Cycle de vie d’un Service
● Créer un fichier avec la définition du service, ensuite:
● Vérifier que le service a bel et bien été créé:
$ kubectl create -f docs/user-guide/walkthrough/service.yaml
$ kubectl get service
● Pour effacer le service
$ kubectl delete service nginx-service

37. Répliquer des Pod - Replication Controller
● Un replication controller
permet de créer de multiples
Pod identiques.
● Ils permettent de recréer un
Pod sur un noeud différent
si un noeud disparaît.
● Ils utilisent les labels pour
retracer les Pod qu’ils ont
créé.
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-controller
spec:
replicas: 2
selector:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

38. Cycle de vie d’un Replication Controller
● Créer un fichier avec la définition du replication controller
● Utiliser l’utilitaire kubectl pour créer le replication controller:
● Vérifier que le replication controller a bel et bien été créé:
$ kubectl create -f docs/user-guide/walkthrough/replication-controller.yaml
$ kubectl get rc
● Pour effacer le replication controller
$ kubectl delete rc nginx-controller
● Vérifier que la quantité de réplicas est valide:
$ kubectl get pod -l app=nginx

39. Liens utiles
● Kubernetes-dashboard: Une interface web permettant de visualiser les
différents éléments de Kubernetes.
● Cluster DNS: Service permettant d’utiliser des noms de domaine pour
trouver un élément Kubernetes à la place d’une adresse IP.
● kubectl pour usagers Docker
● Accéder aux logs applicatifs
● Surveillance du cluster
● Exécuter des commandes dans un Pod
● Exemples de logiciels dans Kubernetes

40. Crédits image

41. Démonstration: minikube
Crédits image

42. Micro-services
sous Docker et
Kubernetes
Présentation:
Sébastien Coutu