REX Openshift à la Poste

Retour d'expérience sur la mise en place d'OpenShift à La Poste - 27/06/2017
Retour d’expérience sur la mise en
place d’OpenShift
à La Poste
Guillaume Membré - Zenika
Pascal Dufourd - La Poste
1

Plan
• Objectifs fixés
• Mise en œuvre de conteneurs Docker avec OpenShift
• Intégration continue / Livraison continue
• Exploitation
• Finalement, où en est-on ?
2

Objectifs
3

Les enjeux pour la DSI La Poste
Simplification des MEP
• Automatisation des MEP
• Moins de documentation
• Rapidité d’installation
• MEP plus légères et plus
fréquentes
• Reproductibilité
Réduction des coûts
Amélioration des performances
Facilitation de l’agilité
• Scalabilité des applications
• Optimisation des ressources
• Dimensionnement évolutif de
la plateforme
• Visualisation en direct de la
montée en charge
• Moins d’acteurs de MEP
• Moins d’erreurs de MEP
• Moins de retours arrière
• Moins d’incidents
• Adéquation du mode de
déploiement avec les projets
AGILE
• Facilite l’expérimentation
(instanciation rapide d’env
de dev ou test)
• Solution adaptée aux projets
pilotés par les délais
4

Organisation du projet
• Projet en mode Agile et DevOps
• Méthode SCRUM adaptée
• 2 Scrum masters
• 2 Product Owners (Logiciel et Infra)
• Equipe pluridisciplinaire
• Projet en mode plateau physique (complété en virtuel)
• Conduite du changement
• Présentation des concepts du PaaS aux MOE
• Tutorat des équipes des projets pilotes
• Collaboration avec la DSI du Courrier
• Instances de coordination
• Participation croisée (échanges techniques, études, démo)
• Convergence des solutions techniques
5

Des profils hétéroclites
6

3 applications sur le pilote
3 candidats basés sur différentes technos :
7

Système
Orchestration
Solution mise en oeuvre
Conteneurs
Services
Outils
8

Mise en œuvre de
conteneurs Docker
avec OpenShift
9

Vue
Utilisateur
ROUTES
NODE
NODE
NODE
Utilisateur
10

Vue
développeur
ROUTES
MASTER NODE
NODE NODE STOCKAGE
SOURCES
NODE
SERVICES
Développeur
MASTER
AUTHENT / API
DATA STORE
MULTI TENANCY
ORCHESTRATION
REPLICATION
SCALING
SCHEDULING
PIC
Utilisateur
REGISTRY
PUITS DE LOGS
11

Workflow de Delivery
Expert MW Développeur
Base image
(Sydney)
Middleware
image
Image
Applicative
Exploitant
Supervision
(conf)
Intégrateur /
Administrateur
Projet OCP &
egress policy
Supervision
applicative
Monitoring
des jobs
Ordonnancements
(conf)
Paramétrage
applicatif
12

Hiérarchie des images middleware
13

Organisation des MW dans GitLab
• Un groupe pour la filière Sydney des middlewares
• un repo par middleware
• une branche par version de middleware
• un tag par version d’image
⇒ Spécifique au contexte client
14

Images de base : RHEL & Sydney
• openshift/rhel7.2
• Maintenue par Red Hat
• Doit être la base de toutes les images s’exécutant dans OCP
• Minimum vital : rpm / yum (couplé à un satellite)
• ~ 200 Mo
• sydney/base
• Hérite de l’image RHEL
• Mère de toutes les images des middlewares La Poste
• Inclut quelques outils supplémentaires (curl, tar, bz2, unzip...)
• Positionne des variables d’environnement
15

Construction des images middleware
Images MW qui héritent de
sydney/base (ou de sydney/java
pour Tomcat)
• sources compilées
par nos soins
httpd, php
• binaires universels
Linux
JDK, MySQL
16

Construction des images applicatives
17

Dockerfile de sydney/apache
Extrait :FROM <registry_url>/openshift/sydney-base:1.0-6
ENV HTTPD_VERSION=2.4.10
HTTPD_HOME=/opt/apache
MW_CONFIG_PATH=/opt/apache/conf
APP_PATH=/var/www/static-content
LABEL MW_Version_HTTPD=${HTTPD_VERSION}
io.openshift.expose-services=8080:httpd
io.k8s.display-name="Apache Sydney"
io.openshift.tags="engine,apache,apache2.4"
18

Attention à yum
• Installation des dépendances RPM avec yum
Ne pas écrire :
Mais :
yum install -y tar bz2
INSTALL_PKGS="tar bz2" &&
yum install -y --setopt=tsflags=nodocs ${INSTALL_PKGS} &&
rpm -V ${INSTALL_PKGS} &&
yum clean all
19

Descripteur de déploiement
• Template OpenShift au format JSON
• Décrit :
• Route / Service / DeploymentConfig / Secret
• Mapping de port
• Image à utiliser
• Scripts de liveness / readiness
• Volumes persistants
• Variables d’environnement
• …
• A fournir en même temps que les images Docker
20

Secrets
Chaque middleware propose un modèle de secret que les développeurs peuvent
utiliser pour stocker les informations sensibles (ex : user:passwd)
Modèle au format JSON stockant des couples
clés/valeurs
Le secret sera monté sous la forme de volume dans le
conteneur cible dans un chemin dédié
En production : c’est l’admin qui saisit les valeurs
sensibles et lui-seul en a la connaissance
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "secrets-pwd",
"creationTimestamp":
null
},
"data": {
"key-1": "value-1"
},
"type": "Opaque"
}
21

Packaging des applis
• Exemple : httpd / php-fpm
• Séparation de la partie statique et dynamique
• 1 repo git par module applicatif :
• ccx-apache
• ccx-php
• Conf middleware par défaut modifiable par les MOE
• Conf applicative gérée par les MOE
FROM <registry_url>/openshift/sydney-apache:2.4-15
COPY www/web/ ${APP_PATH}
COPY conf/httpd-vhost-php.conf ${MW_CONFIG_PATH}/conf.d/ccx
├── conf
│ └── httpd-vhost-php.conf
├── Dockerfile
├── README
└── www
├── static-content
├── css
├── images
└── js
22

Variables d’environnements
• déclarées dans les images middleware
• standardisent les chemins à utiliser dans les Dockerfile applicatifs
MW_APP_DIR=/tools/app/
CATALINA_HOME=/opt/tomcat/
MW_CONFIG_PATH=/opt/tomcat/conf
APP_PATH=/var/www/j2ee/
APP_CONFIG_PATH=/var/www/conf
APP_CONTEXT_PATH=/var/www/context
...
23

Bootstrap des applis
• La configuration applicative est modifiée par un script maison en fonction de
l’env
• Recherche / remplace des motifs dans les fichiers de configuration
• Lancé au démarrage du conteneur (CMD)
# Instanciation de la conf applicative
configFileList=${MW_APP_DIR}/configfilelist.json
if [ -f $configFileList ]
then
echo -e "Traitement des fichiers applicatifs"
${MW_SCRIPTS_DIR}/applyConfMethod.sh $configFileList
else
echo -e "L'instanciation de la configuration n'a pu être réalisée car le
fichier $configFileList est introuvable"
fi
echo -e "n--------------------------"
echo -e "Démarrage d'Apachen"
exec ${HTTPD_HOME}/bin/httpd -DFOREGROUND
24

Deux filières applicatives
Par défaut : les applications entrent dans une filière standard :
• Dockerfile simplifié
• Templates middleware
• Middleware au catalogue
Si les développeurs le souhaitent, en fonction de leur connaissance du PaaS, ils
pourront dans un deuxième temps :
• d’embarquer des Dockerfiles plus complexes
• de proposer des templates applicatifs
• de tester des middlewares alternatifs à des fins d’expérimentation
25

Déploiement par OpenShift
Toute nouvelle publication d’une image existante dans la registry OpenShift
déclenchera la suppression du pod existant et la création d’un nouveau
oc new-app --template=sydney-apache-2.4-3 -p IMAGE_NAME=u1-apache
-p IMAGE_VERSION=2.5-SNAPSHOT -p APACHE_SERVICE_NAME=vu-rec-apache
-p PHP_FPM_SERVICE_NAME=vu_rec-php
26

Certificats SSL
• Initialement inclus dans l’image
• Complexes à gérer et mettre à jour
• Désormais, ils sont portés par HA Proxy
• Pros : facilite la maintenance
• Cons : un seul certificat pour toute la plateforme, wildcard DNS étendu
27

Environnement de dev local
•Rendre les phases de développement ISO plateforme DEV/REC/PROD
•Tester la construction d’image applicative …
• Sans le push sur GitLab
• Pour expérimentation technique
•Avoir les outils adaptés à chaque …
• Technologie de développement
• Solution d’hébergement
•Poste de travail du développeur
• Windows 7 Entreprise SP1
• Intel(R) Core(TM)I5
• 8Go de RAM
• Disque SSD
Postedetravail
28

Outils de dev local
•Docker Toolbox 1.10 :
• Virtual Box 5.0.16
• Docker 1.10.3
• Version du Linux : Alpine
•Babun (terminal SSH)
•WinPTY (nécessaire pour conserver le terminal Unix lors d'une connexion à un
conteneur depuis un environnement Windows)
•OpenShift Client 1.3.3
29

Intégration continue
/
Livraison continue
30

Continuous deployment
31

Déploiement en dev
# git clone
Poste de
développeur
GitLab
Slave Jenkins
Master Jenkins
ordonne
Code
Déploie pour
MaJ site de
DEV
REGISTRY
NODE
NODE
NODE
notifie
Build
image
32

Appel du slave Jenkins
33

Construction de l’image applicative
34

Déploiement en prod
Poste de
développeur
Slave Jenkins
Master Jenkins
Ordonne
Déploie pour
MaJ site de
PROD
REGISTRY
NODE
NODE
NODE
Lancement manuel
Copie image
(Skopeo)
Via PF DEV
REGISTRY
35

Pipeline Jenkins
Build QA Approbation Release Deploy
• Jenkinsfile
• DSL groovy d’enchaînement des étapes de constructions
• Versionnable avec les sources du projet
• Reporting visuel
• Rapport d’exécution des TU
36

Pipeline Jenkins
• Exemple d’exécution d’un job de construction applicative
37

Job Jenkins de déploiement en Prod
• Le déploiement en prod requiert des credentials spécifiques
• Tous les développeurs ne doivent pas avoir accès à ces informations
• Utilisation de dossiers Jenkins avec des droits différents
● PFA : les devs ont tous les droits
● PROD : les devs n’ont que le droit de build
38

Tests unitaires sur les middlewares
• Vérification du bon fonctionnement de l’image avant de la publier
• Java est il bien dans le $PATH
$JAVA_HOME est il bien valorisé ?
• Apache httpd démarre t-il ?
• Le user root de MySQL est-il bien désactivé ?
• Rapport dans Jenkins à l’aide du plugin “Tap”
39

Exploitation
40

Architecture de la plateforme
41

Dimensionnement de la plateforme
• 3 VM pour les Master OpenShift
• 1 VIP Alteon pour la répartition de charge
• 1 VM d’infrastructure utilisée pour les installations & migrations OpenShift via
Ansible, surveillance par Centreon, ordonnancement par VTOM
• 2 DELL R730 composés chacun de 2xE5-2630v4 (40 cœurs logiques), 128 Go
de RAM, connectivité réseau 10 Gbps cuivre, connectivité SAN 2x8 Gbps
• Connexion réseau actuellement en 1 Gbps
• 1 seul serveur physique en qualification
• 1 VIP Alteon pour la répartition de charge pour les pods router
42

Gestion des logs
• Prendre en compte cette problématique dès le départ
• Rappel : je risque d’avoir un grand nombre de conteneurs...
• Plusieurs drivers Docker/Kubernetes dédiés aux logs :
• Json-file (default)
• Syslog (UDP, TCP, TCP+TLS, Unix socker), Journald
• Awslog (AWS), Stackdriver (Google)
• Gelf (Graylog ou Logstash pour ELK)
• Fluentd
• Splunk
• ...
43

Mes logs près de mes containers
• Utilisation de volumes persistants (un répertoire du host)
• Attention : à l’UID du user d’écriture des logs
• Attention : les logs du conteneur ne sont pas administrés par défaut
(activer la rotation)
• Attention : les conteneurs ne sont pas attachés à un
hôte en particulier
44

Centralisation des logs
• L’application écrit sur la sortie standard (stdout / stderr)
voir the Twelve-Factor App : http://12factor.net
• Aucune log n’est stockée dans le conteneur
• ⇒ Centralisation des logs dans un puits de données
• Facilite le diagnostic
• Aide la corrélation des traces inter-conteneur
45

ELK - Elastic Stack (v5+)
Logstash
/ Fluentd
Elasticsearch
Kibana
46

Kibana
• IHM de consultation des traces
• Exploration des données via filtre / recherche
• Reporting via différents dashboards
47

Finalement, où en est-on ?
48

3 applications déployées en prod
Aujourd’hui :
3 applis en prod ouvertes aux
utilisateurs
Mises à jour qualifiées de non-
événement par les
développeurs
Bons retours des utilisateurs
(pas de changement perçu
autre qu’une meilleure
réactivité des applis :) )
49

REX de l’appli Forum
•Application hébergée en production sur le PaaS
• Réduction des coûts : gain par MEP de 2 jours
• Simplification des MEP : gain en délai de 3 à 7 jours
• Amélioration des performances : à chaque pallier de 20 000 sessions un pod PHP se crée
permettant de répondre facilement aux demandes utilisateur.
0
20000
40000
60000
80000
100000
120000
140000
160000
1 2 3 4 5 6 7
Nombredesession
Nombre de pod
Hors PAAS Avec PAAS
MCO
Charge
DEV
MOE
Exploit
Charge
DEV
MOE
Exploit
Déploiement en rec (3 en moyenne) 1 0 0,06 0
Réalisation de la documentation 0,25 0 0 0
Déploiement en production 0,25 0,25 0,02 0
Incident lié à la MEP 0,25 0,1 0 0
Sous Total 1,75 0,35 0,08 0
Total 2,1 0,08
50

Le mot L’image de la fin
La théorie
51

Le mot L’image de la fin
La vraie vie
52

Biblio
• Continuous intégration :
https://www.martinfowler.com/articles/continuousIntegration.html
• Label Docker, image métadata : https://blog.codeship.com/container-image-
immutability-power-metadata/
• TU OpenShift Mysql : https://github.com/sclorg/mysql-
container/blob/master/5.7/test/run
53

REX Openshift à la Poste

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à REX Openshift à la Poste

Similaire à REX Openshift à la Poste (20)

Plus de Membré Guillaume

Plus de Membré Guillaume (7)

REX Openshift à la Poste