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

Sommaire

2

Contexte Présentation fonctionnelle

Architecture Générale

Configuration Bluemix Configuration du

DevOps Workspace

Démonstration

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

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

Portail établissements

Recevoir les informations de la

FESA

Diffuser des annonces auprès des clients finaux

Planifier les RDV

Application Mobile

Gérer son profil et ses véhicules Recevoir les

informations de mon

établissement

Trouver un établissement

Architecture générale

7

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

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

Structure de l’image Docker (cf. Git)

Dockerfile

Conf /etc

Cron /etc

Scripts /scripts

Src /var/www/html

10

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/supervisord

apache2

cron /cronlock.sh

backup-volumes (daily)

send-sms (hourly)

rsyslog

11

Configuration Bluemix

12

L’organisation FESA Sogeti F

R –

FESA U

K

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

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

Configuration du DevOps Workspace

15

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

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

Gitflow Workflow

18

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

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 »

Memcached

20

Remplacer « dev » par « staging » ou « prod » selon l’environnement

Clé non valide, donnée ici à titre d’exemple

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 »

Redis

22

Clé non valide, donnée ici à titre d’exemple

Remplacer « dev » par « staging » ou « prod » selon l’environnement

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 »

Car-contacts – Déploiement

24

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"

Car-contacts – Déploiement

26

Démonstration

27

Merci

SOGETI France