Des principes de la démarche DevOps à sa mise en oeuvre

Des principes de la démarche DevOps à sa
mise en oeuvre
Developer Day - le 24/03/2016
Stéphane Manciot

○ Principes de la démarche DevOps
○ Mise en oeuvre
○ Recap
Présentation

○ Bénéfices attendus
○ Intégration à la démarche agile
○ Intégration continue
○ Livraison continue
○ Déploiement continu
Principes de la démarche DevOps

DevOps - Pourquoi ?
○ Des cycles de déploiement plus courts
○ Une mise à disposition de nouvelles fonctionnalités plus
rapidement
○ Des applications ciblées et de qualité pour accroître la
satisfaction cliente
○ Une réduction des coûts et une affectation des ressources
à des tâches à plus haute valeur ajoutée
○ Amélioration de la gouvernance liée à l’automatisation du
tracking et du reporting

DevOps - Intégration continue

DevOps - Déploiement continu
(Nexus)(

○ Spécifications
○ Gestion de code
○ Tests fonctionnels
○ Métriques et gouvernance
○ Construction des livrables
○ Déploiement
○ Tests de performance
Mise en oeuvre de la démarche DevOps

Mise en oeuvre de la démarche DevOps
○ Spécifications
○ Gestion de code
○ Tests fonctionnels
○ Métriques et gouvernance
○ Construction des livrables
○ Déploiement
○ Tests de performance

DevOps - Behaviour Driven Development
○ Spécifications des User Stories décrites selon :
○ Des exigences
○ En tant que <rôle>
○ Je veux que <fonctionnalité>
○ Afin de <bénéfice>
○ Des scénarios / exemples
○ Given (Etant donné) <un contexte>
○ When (Lorsque) l'utilisateur effectue
certaines <actions>
○ Then (Alors) on doit pouvoir constater
telles <conséquences>

DevOps - Behaviour Driven Development - Exigence
○ En tant que client de l’application
○ Je veux pouvoir autoriser une autre application
à accéder à mes informations personnelles
○ Pour pouvoir bénéficier des services proposées
par cette dernière

DevOps - Behaviour Driven Development - OAuth
Authorization Code Grant 
 
+----------+ 
| Resource | 
| Owner | 
| | 
+----------+ 
^ 
| 
(B) 
+----|-----+ Client Identifier +---------------+ 
| -+----(A)-- & Redirection URI ---->| | 
| User- | | Authorization | 
| Agent -+----(B)-- User authenticates --->| Server | 
| | | | 
| -+----(C)-- Authorization Code ---<| | 
+-|----|---+ +---------------+ 
| | ^ v 
(A) (C) | | 
| | | | 
^ v | | 
+---------+ | | 
| |>---(D)-- Authorization Code ---------' | 
| Client | & Redirection URI | 
| | | 
| |<---(E)----- Access Token -------------------' 
+---------+ (w/ Optional Refresh Token)

DevOps - Behaviour Driven Development - Spock
def "given a valid client and an authenticated user, when asking for an
authorisation, a valid token should be generated and granted to the client for
the authenticated user and the user agent should be redirected back to the
client using the redirection URI provided by the client and including an
authorisation code” (){ 
given: 
createUser() 
request.method = 'POST' 
request.setParameter(OAuth.OAUTH_RESPONSE_TYPE, 'code') 
request.setParameter(OAuth.OAUTH_CLIENT_ID, CLIENT_ID) 
request.setParameter(OAuth.OAUTH_REDIRECT_URI,
URLEncoder.encode('http://localhost/eboutique', 'UTF-8')) 
request.setParameter(OAuth.OAUTH_USERNAME, USERNAME) 
request.setParameter(OAuth.OAUTH_PASSWORD, PASSWORD) 
when: 
controller.authorize() 
then: 
HttpServletResponse.SC_FOUND == response.status 
String redirectUrl = response.redirectedUrl 
assertNotNull(redirectUrl) 
Map<String, String> parameters = parametersAsMap(redirectUrl) 
assertNotNull(parameters) 
String code = parameters['code'] 
assertNotNull(code) 
Token token = Token.findByClientIdAndValue(CLIENT_ID, code) 
assertNotNull(token) 
assertTrue(!token.hasExpired()) 
assertEquals(EXPIRES, token.expiresIn) 
User u = User.findByLogin(USERNAME) 
assertEquals(u, token.user) 
assertTrue(StringUtils.isEmpty(token.scope)) 
assertTrue(StringUtils.isEmpty(token.state)) 
}

DevOps - Behaviour Driven Development - jbehave
# EmptyFavoritesRepository.story
Scenario: Empty Favorites Repository
Given empty Favorites Repository
When there is nothing added to the repository
Then favorite book is null
public class EmptyRepositorySteps { 
private FavoritesRepository repository = new DefaultFavoritesRepository();; 
@Given("empty Favorites Repository") 
public void givenEmptyFavoritesRepository() { 
} 
@When("there is nothing added to the repository") 
public void whenThereIsNothingAddedToTheRepository() { 
} 
@Then("favorite book is null") 
public void thenFavoriteBookIsNull() { 
assertThat(repository.getFavorite(Book.class)).isNull(); 
} 
}

DevOps - Behaviour Driven Development - fitnesse
○ Définition sous la forme de tableaux (decision
table) des données en input et des résultats
attendus

DevOps - Behaviour Driven Development - fitnesse
○ Développement de fixtures pour appeler
directement le code
public class Division { 
private double numerator, denominator; 
 
public void setNumerator(double numerator) { 
this.numerator = numerator; 
} 
 
public void setDenominator(double denominator) { 
this.denominator = denominator; 
} 
 
public double quotient() { 
return numerator/denominator; 
} 
}

DevOps - Gestion de code - Git flow
○ develop : branche principale des développements
○ features : nouvelles fonctionnalités
○ release : versions déployées sur un serveur de staging
○ master : code déployé en production
○ hotfix : correction de bugs constatés en production

DevOps - Contraintes d’intégration
○ Base de données
○ Intégration avec d’autres SI
○ …

DevOps - Mock de base de données - liquibase
○ Définition des base de données supportées, des tables à
créer et du jeu de données à injecter
<?xml version="1.0" encoding="UTF-8"?> 
<databaseChangeLog …> 
<preConditions> 
<dbms type="h2,oracle" /> 
</preConditions> 
<include file="db.changelog-tables.xml"/> 
<include file="db.changelog-data.xml"/> 
</databaseChangeLog>
<property name="now" value="sysdate" dbms=“oracle”/>
… 
<changeSet id="1" author="smanciot"> 
<preConditions onFail="MARK_RAN"> 
<not><tableExists tableName="EXPORT_RECAPITULATIF_VENTE" /></not> 
</preConditions> 
<createTable tableName=“EXPORT_RECAPITULATIF_VENTE" …> 
</changeSet> 
</databaseChangeLog> 
 
<changeSet author="smanciot" id="1"> 
<insert dbms="h2" 
tableName=“EXPORT_RECAPITULATIF_VENTE" …> 
</changeSet> 
</databaseChangeLog>

○ Ajout de liquibase dans la chaîne de build (maven)
<plugin> 
<groupId>org.liquibase</groupId> 
<artifactId>liquibase-maven-plugin</artifactId> 
<configuration> 
<changeLogFile>db.changelog-master.xml</changeLogFile> 
<url>${jdbc.url}</url> 
<driver>${jdbc.driver}</driver> 
<username>${jdbc.username}</username> 
<password>${jdbc.password}</password> 
</configuration> 
<executions> 
<execution> 
<phase>process-test-classes</phase> 
<goals> 
<goal>update</goal> 
</goals> 
</execution> 
</executions> 
</plugin>

○ Tests sans création d’objets mockés
"all sales imported" should "be updated" in { 
val rows: Int = retrieveNumberOfRows(MUT, s"SELECT count(*) FROM
$EXPORT_RECAPITULATIF_VENTE WHERE EXPORTED=0").getOrElse(0) 
assert(rows > 0) 
 
import akka.stream.scaladsl.Source 
 
val i = new ImportStreaming(system) 
import i._ 
val sourceUnderTest: Source[Int] =
loadRows(Seq(EXPORT_RECAPITULATIF_VENTE)) via importRows 
val future = sourceUnderTest.runFold(0)(_ + _) 
val result: Int = Await.result(future, 5*60*1000.millis) 
assert(result > 0) 
logger.info(s"imported successfully $result rows") 
assert(retrieveNumberOfRows(MUT, s"SELECT count(*) FROM
$EXPORT_RECAPITULATIF_VENTE WHERE EXPORTED=0").getOrElse(1) == 0) 
}

DevOps - Mock de services soap - soapui
○ Définition du service soap à mocker à partir du contrat
d’interface (wsdl)
○ Définition des réponses en fonction des inputs

DevOps - Mock de services soap - soapui
○ Ajout de soapui dans la chaine de build (maven)
<plugin> 
<groupId>eviware</groupId> 
<artifactId>maven-soapui-plugin</artifactId> 
<version>4.5.1</version> 
<executions> 
<execution> 
<id>proxySCVD</id> 
<phase>process-test-classes</phase> 
<goals> 
<goal>mock</goal> 
</goals> 
<configuration> 
<projectFile>${project.basedir}/src/test/resources/SCVD-soapui-
project.xml</projectFile> 
<port>${soapui.port}</port> 
<noBlock>true</noBlock> 
</configuration> 
</execution> 
</executions> 
<dependencies …> 
</plugin>

DevOps - Mock de services rest - Servlet
@Override 
protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
throws ServletException, IOException { 
OutputStream output = null 
String url = req.getRequestURL().toString() 
String identifiant = parseURL(url, '/pres/v1/pdc/') 
if(!identifiant){ 
resp.sendError(400) 
} 
else{ 
try{ 
output = resp.outputStream 
def inputStream =
TraceoMashup.class.getResourceAsStream(identifiant + '.xml') 
if(inputStream){ 
resp.setHeader('Content-type', 'application/xml') 
byte[] buffer = new byte[1024] 
for (int length = 0; (length = inputStream.read(buffer)) >
0;) { 
output.write(buffer, 0, length); 
} 
output.flush() 
} 
else { 
resp.sendError(404) 
} 
} 
finally{ 
if (output != null) output.close() 
} 
} 
}

○ Définition du descripteur de déploiement (war)
<?xml version="1.0" encoding="ISO-8859-1"?> 
<web-app …> 
<servlet> 
<servlet-name>TraceoServlet</servlet-name> 
<servlet-
class>fr.laposte.intra.courrier.ccmu.mashup.traceo.servlet.TraceoServlet</
servlet-class> 
</servlet> 
…
<servlet-mapping> 
<servlet-name>TraceoServlet</servlet-name> 
<url-pattern>/traceo/pres/*</url-pattern> 
</servlet-mapping>
… 
</web-app>

○ Ajout de jetty dans la chaine de build (maven)
<plugin> 
<groupId>org.mortbay.jetty</groupId> 
<artifactId>jetty-maven-plugin</artifactId> 
<configuration> 
<webAppSourceDirectory>${project.basedir}/src/test/resources</
webAppSourceDirectory> 
<useTestScope>true</useTestScope> 
<webApp> 
<contextPath>${contextPath}</contextPath> 
<descriptor>${project.basedir}/src/test/resources/WEB-INF/web.xml</
descriptor> 
</webApp> 
<stopKey>stop</stopKey> 
<stopPort>${jetty.stopPort}</stopPort> 
<systemProperties> 
<systemProperty> 
<name>jetty.port</name> 
<value>${jetty.port}</value> 
</systemProperty> 
</systemProperties> 
</configuration> 
<dependencies …> 
</plugin>

DevOps - Aide à la gouvernance - sonarqube

DevOps - Hétérogénéité des plates forme

Docker - le conteneur intermodal

Docker - Valeurs ajoutées
○ Construction rapide, idempotent et automatique d’images
(Dockerfile) pouvant être partagées (docker-registry)
○ Séparation des rôles :
○ Développeur : à la main sur le conteneur
○ Opérationnel : à la main sur le reste
○ gestion des logs
○ gestion des accès distants
○ configuration réseau
○ monitoring
○ …
○ Portabilité
○ Provisioning rapide (Another Union File System)
○ Performance : les avantages d’une VM (isolation des processus,
interface réseau, …) sans les inconvénients (processus exécutés au
sein de l’hôte, pas d’émulation de périphérique)
○ pouvoir notamment monter des jeux de test ou de nouvelles
instances en fonction des besoins

Docker - Dockerfile (Exemple)
image de base
variables d’environnement
copie de fichiers
exécution de commandes
points de montage
port(s) d’écoute
commande par défaut

DevOps - Déploiement Zero Downtime (1/2)
○ Pattern Blue/Green

DevOps - Déploiement Zero Downtime (2/2)
○ Pattern Canary

Ansible
○ Orchestration et automatisation des tâches
d’administration système
○ provisioning
○ déploiement d’application

Ansible - Valeurs ajoutées
○ Simplicité d’exécution : pas besoin de maître ni d’agent sur les
systèmes à administrer (ssh)
○ Mode Push
○ Simplicité d’apprentissage (YAML)
○ Performant : exécution des scripts en parallèle sur les machines
cible
○ Extensible : python
○ DRY : rôles
○ Idempotent : chaque tâche est exécutée en garantissant que le
système cible sur lequel elle s’applique se trouvera dans l’état
désiré post exécution
○ Sécurisé : ansible-vault permet d’encrypter les fichiers de
configuration spécifiques à chaque plate forme.

Ansible - Regroupement logique des machines
○ inventory.ini
# 
# logical nodes 
# 
datalab-mesos-master1 
datalab-mesos-batch1 
datalab-mesos-middleware1 
datalab-mesos-realtime1 
datalab-mesos-realtime2
[master] 
[batch] 
[middleware] 
datalab-mesos-middleware1
 
[realtime] 
[slave:children] 
batch 
middleware 
realtime 
master 
 
[mesos:children] 
master 
slave

Ansible - Découpage logique des playbooks
○ ansible-playbbook site.yml -i inventory.ini -vv
--- 
 
- include: proxy.yml # proxy 
- include: zookeeper.yml # cluster zookeeper 
- include: hadoop.yml # cluster hadoop 
- include: mesos.yml # cluster mesos 
- include: mesos-dns.yml # mesos-dns 
- include: middleware.yml # middleware 
- include: batch.yml # batch node(s) 
- include: realtime.yml # realtime node(s) 
- include: chronos.yml # chronos 
- include: datalab.yml # marathon 
- include: registry.yml # docker registry 
- include: docker.yml # docker

Ansible - Définition des rôles
variables par défaut
tâches
templates
tâches
partagées
rôle

Ansible - Application des rôles
○ middleware.yml
--- 
 
- name: Install mesos middleware node(s) 
hosts: middleware 
remote_user: $user 
roles: 
- {role: kafka} 
- {role: flume} 
- {role: spark}
○ hadoop.yml
- name: Install and launch Hadoop cluster 
hosts: hdfs 
remote_user: $user 
pre_tasks: 
… 
- name: add group {{hdfs_group | default(hdfs_user | default('hdfs'))}} 
group: name={{hdfs_group | default(hdfs_user | default('hdfs'))}}
state=present 
run_once: true 
delegate_to: "{{play_hosts[0]}}" 
sudo: yes 
when: not local_certificate.stat.exists 
… 
roles: 
- {role: hdfs, hdfs_configure: no} 
- {role: hdfs, hdfs_configure: yes} 
groupe de
machines
rôles
tâches

Ansible - Spécificités des plates forme
○ définition physique des machines
○ datalab-mesos-master1
--- 
 
ansible_ssh_host: 192.168.33.60 
ansible_ssh_user: vagrant 
ansible_ssh_pass: vagrant 
 
zookeeper_id: 1 
 
mesos_standalone: yes 
 
hdfs_name_node_id: nn1

○ Lancement d’un container
- name: ensure kafka is running 
docker: 
image: "{{docker_registry_host}}/ubuntu14.04-jdk{{java_major_version}}-
kafka:{{kafka_version}}" 
name: "kafka_{{(item|int) - 1}}" 
command: /start.sh 
ports: 
- "{{kafka_config_port}}" 
links: 
- zk:zk1 
volumes: 
- "{{kafka_log_dirs}}:{{kafka_log_dirs}}:rw" 
- "/var/run/docker.sock:/var/run/docker.sock" 
env: 
KAFKA_ADVERTISED_HOST_NAME: "{{ hostvars[inventory_hostname]
['ansible_eth1']['ipv4']['address'] }}" 
KAFKA_BROKER_ID: "{{(item|int) - 1}}" 
KAFKA_ZOOKEEPERS: "zk1:{{zookeeper_config_clientPort}}" 
state: reloaded 
restart_policy: "no" 
privileged: yes 
with_items: "{{range(1,(kafka_cluster_size+1))|list}}" 
sudo: yes 
register: start_kafka 
 
Ansible - Docker
nom de l’image
Variables d’environnement
valorisation des points
de montage

# vi: set ft=ruby : 
 
# All Vagrant configuration is done below. The "2" in Vagrant.configure 
# configures the configuration version (we support older styles for 
# backwards compatibility). Please don't change it unless you know what 
# you're doing. 
Vagrant.configure(2) do |config| 
 
config.vm.box_check_update = false 
…
config.vm.define "mesos-batch3" do |datalab| 
datalab.vm.box = "centos/7" 
datalab.vm.hostname = "datalab-mesos-batch3.vm" 
datalab.vm.network "private_network", ip:"192.168.33.83" 
datalab.vm.synced_folder "./", "/vagrant", disabled:true 
datalab.vm.synced_folder "./", "/home/vagrant/sync", disabled:true 
datalab.vm.provider "virtualbox" do |vb| 
vb.name = "datalab-mesos-batch3" 
vb.cpus = 1 
vb.memory = 1024 
end 
datalab.vm.provision :ansible do |ansible| 
ansible.inventory_path = "vagrant-inventory.ini" 
ansible.playbook = "datalab.yml" 
ansible.extra_vars = { user:"vagrant"} 
ansible.sudo = true 
ansible.limit = 'all' 
ansible.verbose = 'vv' 
end 
end 
 
end 
Ansible - Vagrant
box
vm network
provisioning
vagrant inventory
playbook

DevOps - Tests de performance - Gatling
○ Génération des tests à partir d’une archive HTTP,
en utilisant un proxy, un fichier de logs serveur, …
○ Description du comportement des utilisateurs
(pause, rendezVous, exec, …)
○ Injection de données dans les scénarios (csv,
json, jdbc, redis, …)
○ Contrôle de l’injection des utilisateurs
(atOnceUsers, rampUsers, …)
○ Assertions (responseTime, requestsPerSec, …)
○ Vérification des réponses (check)

DevOps - Tests de performance - Gatling
○ Génération de métriques

Dev
Ops
Continuous delivery
platform
VCS
1
4
3
uat
Build
5
6
docker registry
7
2
8
Schéma de mise en oeuvre

Rappel des principaux composants
○ Docker-registry : disposer d’une référentiel privé des images
construites par la plate forme de livraison continue permettant
leur déploiement sur n’importe quel serveur - “build once deploy
anywhere”
○ SonarQube : disposer de métriques permettant de mesurer en
continu la qualité du code produit
○ artifactory / nexus : pouvoir disposer d’un référentiel de
composants permettant de contrôler, stocker et gérer les binaires
produits tout au long du cycle de vie du projet
○ Fitnesse : pouvoir mettre en oeuvre des tests d’acceptance
automatisés et ainsi s’assurer de la conformité du code produit au
regard des fonctionnalités attendues
○ Gatling : pouvoir effectuer des tests de performance
○ Ansible : pouvoir construire les images docker, sécuriser les
déploiements effectués sur chacune des plates forme (avec ou sans
docker) et ainsi pouvoir livrer en continu

Plus d’informations sur blog.ebiznext.com et
github.com/ebiznext

Des principes de la démarche DevOps à sa mise en oeuvre

Contenu connexe

Tendances

En vedette

Similaire à Des principes de la démarche DevOps à sa mise en oeuvre

Des principes de la démarche DevOps à sa mise en oeuvre