Issue d’une expérience sur un projet transverse chez un client bancaire, cette présentation vous présentera la migration d’une application web initialement déployée sur Windows vers un Paas Openshift. Le panel de transition des applications vers un PaaS ne se résume pas choisir entre appliquer des migrations de type Lift and Shift. Les organisations et méthodologies à adopter doivent être repensées, tout comme les architectures applicatives déployées sur ces infrastructures. Nous présenterons au cours de cette session les évolutions réalisées sur une application web initialement déployée sur Windows, mais également les gains du passage à OpenShift qui en découlent, ainsi que les problématiques et difficultés qui ont été résolues au cours de cette transition.

1. Migration d’une application web vers un
Paas OpenShift
Akram BLOUZA
@akram-wewe

2. Texte ici
Plan
1) OpenShift ?
2) Pourquoi OpenShift ?
3) Organisation
4) Choix techniques
5) Difficultés rencontrées
6) Demain ?

3. OpenShift ?
➢ OpenShift : Paas permettant de construire, déployer et exécuter des
applications dans des conteneurs.
➢ Elle repose sur l’orchestrateur des conteneurs Kubernetes.

4. Pourquoi OpenShift ?
Meilleure efficacité du SIMeilleure sécurité des donnéesAugmenter la qualité de service
○ Diminution du nombre de bug
post-développement.
○ Réduction des coûts ( infrastructure,
temps d’installation, maintenance )
○ Inventaire exhaustif du parc pour le
périmètre de la plateforme
○ Réduction du temps entre annonce et
correction
○ Réduction du “Time To Market”
○ Diminution du nombre de bugs en
production
○ Haute disponibilité et haute performance

5. Organisation

6. Equipe DevOps

7. Déroulement du projet
Atelier de
design
Sprints de 2 semaines
Cadrage du projet
Objectifs du projets
Raffinage / estimation
du périmètre
- Un “Sprint planning” au début du sprint
- Un “Daily” quotidien
- Une démo à la fin du sprint
- Un rétro après la démo
Sprint 1
Initialisation
Sprint 2
Plateforme
fonctionnelle
Sprint 3
Première version
de l’application
Sprint 4
Instanciation des
environnements
de l’application
Sprint 5
Application
iso-fonctionnelle
Sprint 6
Exploitabilité
OpenShift
pour la production
Recette applicative
Sprint 7
Application en
production
OpenShift exploité en
production

8. Choix techniques

9. Architecture

10. Architecture de l’application avant migration
Application -
Front
NTLM
Application-
Front
Windows Server 2008
BD
Web
Services
jdbc
SOAP/Http
Web
Service
Outil
interne
filtrage IP
jdbc
ajp
ajp
ajpHttp
Http
Batch 1
Batch 2
Batch 3
jdbc
http

11. Architecture de l’application après migration
BD
WS
Application
Web -
batch
Pod 1
Service
Service
Provisionning et
lancement à la
demande
Batch
Pod
Application
Web
Pod 1
Service
Route
Application
Web
Pod 2
Kerberos
Outil
interne
WS
Pod
Service
Route

12. Sujets traités lors de la migration dans OpenShift
Installation
OpenShift
Création images
Docker
IC / DCSecretsQuotas et limitesRésilienceSupervisionLiveness/Readiness
Traiter les spécificités
de l’environnement
ConfigurationLogging
Installation
OpenShift
Création
images Docker
IC / DC
Secrets
Quotas et limites
Résilience
Supervision
Liveness/Readiness
Traiter les spécificités
de l’environnement
Configuration
Logging

13. Hiérarchie des images Docker dans l’application
openshift/socle-transverse
openshift/tomcat-custom
registry.access.redhat.com/
webserver30-tomcat7-openshift
FROM
FROM
FROM
namespace/
{Application-Web}
namespace/
{Application-WS}
registry.access.redhat.com/
rhel7
openshift/jdk7
openshift/rhel-custom
FROM
FROM
FROM
namespace/
batch1
namespace/
batch2
namespace/
batch3

14. Workflow de déploiement dans OpenShift
OpenShift
API
Application
Pod 1
Application
Pod 2
Service
Route
Namespace DEV
2
checkout
3
deploy
4
build & push
1
commit
Développeur
5
deploy
schedule

15. Workflow de déploiement dans OpenShift
Application
Pod 1
Application
Pod 2
Service
Route
Namespace Recette
Technique
Application
Pod 1
Application
Pod 2
Service
Route
Namespace PRE PROD
Application
Pod 1
Application
Pod 2
Service
Route
Namespace PROD
Application
Pod 1
Application
Pod 2
Service
Route
Namespace RECETTE
FONCTIONNELLE
Application
Pod 1
Application
Pod 2
Service
Route
Namespace DEV
Namespace
preprod-ref
secret
Namespace
prod-ref
secret
Namespace
preprod-ref
secret
DéploymentConfig
Secrets
Images
Routes
Services
Pvc

16. Réussir cette migration: Accompagnement des équipes
▼ Objectif: Faire monter en compétence les équipes sur OpenShift
▼ Ateliers organisés :
▽ Former les équipes sur les sujets OpenShift qui les concernent.
▽ Accompagnement sur le nouveau processus de livraison sur OpenShift.
▽ Accompagnement sur les premiers livrables sur OpenShift.
▼ Traiter les retours des équipes
▼ Correctifs
▼ Nouveaux besoins

17. Difficultés rencontrées

18. ▼ Montée en compétences de l’équipe sur OpenShift.
Difficultés rencontrées
▼ Équipe non réellement dédiée : Membres de l’équipe rattachés à leurs entités respectives.
▼ Blocage pour faire valider certains sujets :
▽ Mise en place d’un outil unique de déploiement et de promotion.
▽ Effectuer le build des images Docker dans OpenShift.
▼ Nouveau mode de fonctionnement : DevOps, Agilité.

19. Avant/Après OpenShift ?

20. Avant OpenShift
▼ Etudes de besoin (OS, Performances, Disque, …)
▼ Fourniture de machine (VM ou serveur physique)
■ Construction de la machine (socle)
■ Livraison de la machine
■ Actions manuelles pour l’installation des serveurs
applicatifs
▼ Paramétrage d’éléments sensibles
■ Journalisation
■ Sauvegarde
■ Surveillance
■ Création de consignes d’exploitation (A/R), …
▼ Augmentation du nombre de nœuds
■ Mêmes étapes que ci-dessus
■ Mise à jour :
■ Sauvegarde complète
■ Installation de la mise à jour
■ Restauration de la sauvegarde en cas de régression avec fortes interruptions

21. Avec OpenShift
○ Déploiement dans un
environnement iso-prod
○ Diminution du nombre de
bugs.
○ Provisioning facile des
environnements
○ Centralisation des logs
○ Possibilité de déployer
l’application sans arrêt du
service
○ Rollback plus facile
○ Meilleure qualité des livrables
DÉVELOPPEMENT
○ Gestion de la sécurité plus
efficaces
○ Incidents en production plus
facile à identifier et donc à
corriger
○ Rollback plus facile et sans
arrêt de service
○ Haute disponibilité facile à
mettre en place
○ Pas d’arrêt de service en cas
de problème de production
○ Supervision plus simple de la
production
EXPLOITATION
○ Délai de provisionnement
réduit du socle
○ Mise à jours de
l’infrastructure beaucoup plus
simple et sans arrêt du
service
○ Ajout de machines dans le
cluster beaucoup plus simple
et sans arrêt du service
○ Rollback possible de manière
plus efficace et sans arrêt du
service
INFRASTRUCTURE

22. Demain ?

23. ▼ Migration de nouvelles applications vers OpenShift.
▼ Continuer à travailler sur les sujets autour de l’écosystème Devops.
▼ Une équipe 100 % OpenShift ?
Demain ?

24. WESCALE
01 85 08 18 81
contact@wescale.fr
156 boulevard Haussmann 75008 Paris
www.wescale.fr | blog.wescale.fr | @YesWeScale

25. MERCI.
QUESTIONS ?