Digitalisation du réseau FESA

1. Car-Contacts
Une application Native Cloud Bluemix
Développement d’une application Native Cloud Bluemix
et déploiement avec Docker dans un modèle DEVOPS
13/04/2016

2. Sommaire
2
Contexte
Présentation
fonctionnelle
Architecture
Générale
Configuration
Bluemix Configuration du
DevOps Workspace
Démonstration

3. Contexte
► FESA : Fédération des Entreprises Spécialisées de l’Automobile
► 6 800 établissements spécialisés dans l’automobile
► Potentiel de 3,5 millions d’utilisateurs finaux
► Digitalisation des établissements adhérents
► Garder le contact avec les clients finaux
3

4. Solution
Développement
Pré –production
Production
TMA /Support technique et fonctionnel
Clients établissements
Etablissements adhérents FESA : Portail
FESA
Application Mobile
Portail établissement
Back Office

5. Portail établissements
Recevoir les
informations de la
FESA
Diffuser des
annonces auprès
des clients finaux
Planifier
les RDV

6. Application Mobile
Gérer son profil et ses
véhicules Recevoir les
informations de
mon
établissement
Trouver un
établissement

7. Architecture générale
7

8. 8
Architecture initiale
Serveur applicatif
- Portail
- Backoffice
- API mobile
Applications mobiles
- iPhone
- Android
Base de données
SMS Gateway
Serveur SMTP
Serveurs de Push
- APNS
- GCM

9. Choix applicatifs
► OS : Debian stable (Jessie)
► Serveur : Apache2
• Portail : PHP 5, HTML 5, jQuery
• CMS : Drupal 7
• API : REST / JSON
► Applications Mobiles : Cordova, jQuery Mobile
► Base de données : MySQL Server 5.x
► Cache : Memcached (official Docker image)
► Lock : Redis (official Docker image)
9

10. Structure de l’image Docker (cf. Git)
Dockerfile
Conf /etc
Cron /etc
Scripts /scripts
Src /var/www/html
10

11. Séquence d’appel (de haut en bas et de gauche à droite)
Dockerfile
/compress-
js.sh
/compress-
css.sh
/run.sh
/configure-
environment.
sh
/mount-
volumes.sh
/set-base-
permissions.
sh
/set-drupal-
permissions.
sh
/usr/bin/sup
ervisord
apache2
cron /cronlock.sh
backup-
volumes
(daily)
send-sms
(hourly)
rsyslog
11

12. Configuration Bluemix
12

13. L’organisation FESASogetiFR–FESAUK
Spaces
Car-Contacts_Dev
(eu-gb.mybluemix.net)
File Share Persistent Volumes
CF Bridge App Services
Containers
Car-Contacts_Staging
(slcloud.fr)
As above… As above …
Car-Contacts_Prod
(car-contacts.fr)
As above… As above…
Dev
Rapid prototyping,
experiments, …
Image Repository
13

14. Architecture sur un espace Bluemix
DevOps
Workspace
Main B&D
pipeline
Main
Container
Group
Fileshare
Backup
Volume
Private
Volume
Public Volume
Sessions
Volume
CF Bridge App
(service
binding)
ClearDb
(MySQL)
SendGrid
(email)
Twilio (SMS)
IBM Push
Notifications
New Relics
(Monitoring)
Load Impact?
(load & perf
testing)
Memcached
B&D
pipeline
Memcached
Container
Redis B&D
pipeline
Redis
Container
Persistent
Volume
14

15. Configuration du DevOps Workspace
15

16. 3 projets
► car-contacts
• L’application elle-même, regroupe le site, l’appli mobile, et le backoffice
► car-contacts-memcached
• Utilisé par les instances applications pour optimiser les performances
► car-contacts-redis
• Utilisé comme « cron lock »
16

17. Les étapes pour DEV, STAGING, PROD
Git
• GITFLOW
Build
• Default build
job from
develop,
release,
master
branches
Assess
• IBM
Vulnerability
Assessment
Deploy
• Cf. next slides
for parameters
Test
• Ping, unit
tests, New
Relics
17

18. Gitflow Workflow
18
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

19. Memcached
19
DEV-Build construit l’image à partir de la branche « develop »
STAGING-Build construit l’image de préprod à partir de la branche « release »
PROD-Build contrauira l’image de production à partir de la banche « master »

20. Memcached
20
Remplacer « dev » par « staging »
ou « prod » selon l’environnement
Clé non valide, donnée ici
à titre d’exemple

21. Redis
21
DEV-Build construit l’image à partir de la branche « develop »
STAGING-Build construit l’image de préprod à partir de la branche « release »
PROD-Build construira l’image de production à partir de la banche « master »

22. Redis
22
Clé non valide, donnée ici
à titre d’exemple
Remplacer « dev » par « staging »
ou « prod » selon l’environnement

23. Car-contacts – Build & Deploy
23
DEV-Build construit l’image à partir de la branche « develop »
STAGING-Build construit l’image de préprod à partir de la branche « release »
PROD-Build construira l’image de production à partir de la banche « master »

24. Car-contacts – Déploiement
24

25. Car-contacts – Déploiement
25
► « Optional deploy arguments »
• -v public:/mnt/volume-public -v private:/mnt/volume-private -v backup:/mnt/volume-
backup -v sessions:/mnt/volume-sessions --env MEMCACHED_HOST=XXX.XXX.XX.XX --
env MEMCACHED_USER=toto --env MEMCACHED_AUTH=toto42 --env
REDIS_HOST=XXX.XXX.XX.XX --env REDIS_AUTH=toto42 --env APP_ENV=PROD --env
TWILIO_FROM=+33012345678
► « Deployer script »
• Commenter cette ligne :
• /bin/bash deployscripts/deploycontainer.sh
• Décommenter cette ligne :
• #/bin/bash deployscripts/deploygroup.sh
• Ajouter juste avant la dernière ligne :
• echo -e "Map additional routes to ${CONTAINER_NAME}_${BUILD_NUMBER}”
cf ic route map -n app -d car-contacts.fr ${CONTAINER_NAME}_${BUILD_NUMBER}
cf ic route map -n toto -d car-contacts.fr ${CONTAINER_NAME}_${BUILD_NUMBER}
cf ic route map -n www -d car-contacts.fr ${CONTAINER_NAME}_${BUILD_NUMBER}
echo -e "Done mapping routes"

26. Car-contacts – Déploiement
26

27. Démonstration
27

28. Merci
SOGETI France