DevOps 360°

Florian Dambrine - Engineering Manager - @ GumGum

360°

> Whoami

Florian Dambrine
Engineering Ingénieur
9+ ans d'expérience chez GumGum
Fan de Cloud et d'automatisation !

Juin 2011 Juin 2014 Février 2014

Invente le In-Image Advertising en 2007

Publicité innovante et solution de "contextual intelligence" pour les agences et les sites marchands

GumGum - CONTEXTUAL Intelligence

GumGum - CONTEXTUAL Intelligence

Verity analyzes web pages for content-level brand safety and contextual classification by applying machine learning (ML) techniques to both the text and prominent images on the web page.

> Agenda

Pourquoi le besoin de DevOps ? (~30 min)
Ça fait quoi concrétement un DevOps ? (~30 min)
Le DevOps et l'automatisation avec Ansible (~2 h)
- Concepts de base
- Première automatisation
- L'utilisation de commandes ad-hoc
Réalisation d'un projet DevOps en binôme (~17 h)
- Automatisation d'un projet Web + BDD
- Architecture HA / Scalabilité
- Gestion du processus de release

Theorie Pratique

pourquoi le besoin de devops ?

les Métiers de l'IT

?

> L'époque "old School"

#!/bin/sh
wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add -
echo 'deb http://debmon.org/debmon debmon-jessie main' >/etc/apt/sources.list.d/debmon.list
add-apt-repository ppa:formorer/icinga
add-apt-repository ppa:formorer/icinga
apt-get update
apt-get install icinga2 vim vim-icinga2
apt-get install icinga2 vim vim-icinga2
PREFIX=~/.vim
mkdir -p $PREFIX/{syntax,ftdetect}
cp /usr/share/vim/addons/ftdetect/icinga2.vim $PREFIX/ftdetect/
cp /usr/share/vim/addons/syntax/icinga2.vim $PREFIX/syntax/
vim /etc/vim/vimrc
syntax on
:wq!
apt-get install mysql-server mysql-client
apt-get install icinga2-ido-mysql
# Select <Yes> when prompted with:
mysql -u root -p
mysql>  CREATE DATABASE icinga;
           GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW,  INDEX, EXECUTE ON icinga.* TO 'icinga'@'localhost' IDENTIFIED BY  'yourpasswordhere';
mysql> quit
mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/mysql.sql
icinga2 feature enable ido-mysql
icinga2 feature enable command
icinga2 feature list
service icinga2 restart
 usermod -a -G nagios www-data
apt-get install php5 php5-cli php-pear php5-xmlrpc php5-xsl php5-gd php5-ldap php5-mysql php5-snmp php5-intl php5-imagick apache2
apt-get install icingaweb2
 icingacli setup token create
 icingacli setup token show
icingacli setup config webserver apache --document-root /usr/share/icingaweb2/public
 a2ensite 001-icingaweb2.conf
service apache2 restart
addgroup --system icingaweb2
usermod -a -G icingaweb2 www-data
mysql -u root -p
mysql>  CREATE DATABASE icingaweb2;
           GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icingaweb2.* TO 'icingaweb2'@'localhost' IDENTIFIED BY 'passwordhere';
mysql> quit
mysql -p icingaweb2 < /usr/share/icingaweb2/etc/schema/mysql.schema.sql
service apache2 restart

L'automatisation par

script shell

Complexe
Difficile à maintenir
Manque de robustesse

Inconvénients :

> L'époque "old School"

LEs infrastructures "baremetal"

Infrastructures statiques
Serveurs dédiés aux clients qui les louent
S'assurer de la capacité nécessaire au fonctionnement des services

Inconvénients :

> L'époque "old School"

LEs Releases

PLANIFIÉES

Temps d'attente entre l'implémentation des fonctionnalités et sa mise en production
Plus difficile d'identifier la cause d'un bug

Inconvénients :

> L'éPOQUE "OLD SCHOOL" ET SES INCONVéNIENTS

Time-to-market élevé
Problèmes de communication entre Dev et Ops
- "Throwing code over the wall":
  - Manque de détails dans les documentations (si elles existent)
  - Manque de clarté dans les logs
  - Code trop souvent non testé (unit tests, integration tests)
  - Manque de planification sur les releases et rollbacks

Je veux de la stabilité !

Je veux du changment !

Mur des lamentations

> L'époque "old School" est révolue!

Réduction du Time-to-market par l'automatisation des process
- Cloud Computing (ressources On-Demand et APIs)
- Infrastructure as Code
- Intégration continue / Déploiement continu etc.
Meilleure collaboration entre Dev et Ops:
- Sensibilisation sur la scalibilité, redondance, documentation
- Unification du logging et monitoring continu
- Intégration continue du code
- "Push button" déploiement et rollbacks

Mes systèmes sont plus stables

Je peux déployer de nouvelles fonctionnalités

Ca fait quoi un devops ?

> l'équipe devops - Par rapport aux autres équipes

Image Science

Web Team

Data Science

Big Data

8 Ingénieurs

4 Ingénieurs

19 Ingénieurs

4 Ingénieurs

11 Ingénieurs

DevOps

10.5 Ingénieurs pour 1 DevOps

> l'équipe devops - par rapport à l'infrastucture

250 serveurs pour 1 DevOps

> Les missions du devops - L'Automatisation

Infrastructure as Code:
- Robustesse / Testabilité
- Reproductibilité (Erreur humaine)
- Flexibilité
- Simplicité
- Versionning

$ ansible-playbook ec2-provision.yml \
      --extra-vars ec2_count=<X>

$ ansible-playbook apache2.yml \
      --limit webservers

> Les missions du devops - L'éducation et le conseil

Conseil les équipes sur les choix d'architectures:
- Application Dev != Application Prod
  - Besoin de scalabilité (Loadbalancer / Autoscaling)?
  - Besoin de redondance / criticité du service
  - Performance du service (Multi-régions)
  - Prévoir les scénario de type "Disaster Recovery"
Éducation des développeurs:
- Exemple: Qu'est ce qu'un serveur web ?
- Bonnes pratiques de la gestion des dépendances dans leurs projets (virtualenv, dependency manager)
- Où et comment je gère les secrets ?

> Les missions du devops - SYSTème et Réseaux

Bonnes pratiques en Système :
- Une application ne tourne pas en tant que root
- On ne peut pas faire de "git push" depuis un serveur (deploy key)
- Les logs dans /var/log/<application>
- Init script ou Upstart script pour les services
- Pas de clé d'identification sur les serveurs. Pas d'utilisation de clé personnelle dans les scripts.
Bonnes pratiques en Réseaux :
- Réseaux privés / publics
- Pas de partage de clé SSH (La clé est individuelle)
- VPN et restrictions basés sur les sous-réseaux

> Les missions du devops - securité

Bonnes pratiques en Sécurité :
- Veille technologique
- Patch de vulnérabilité
- Monitoring et alertes:
  - Changement de règles du Firewall
  - Utilisation de l'API et codes de retour

> Les missions du devops - Intégration continue

Intégration Continue (CI):
- Construction de projets en continu avec feedback rapide
  - L'état d'un projet est toujours connu à un instant T
Livraison Continue - "Push button" (CD):
- La release de code source peut se faire a n'importe quel moment et sans effort
Déploiement Continu (CDD):
- Série de pipeline permettant de valider les changements jusqu'a la mise en production sans intervention humaine

Intégration continue + Facilité de déploiement =

Augmentation de la fréquence de déploiement

Moins de changements par releases

Facilités de debugging et rollback

devops et automatisation

> Les outils d'automatisation

Terraform

Ansible

> Introduction à Ansible

Projet Open source démarré par Michael DeHaan en 2012
Moteur d'automatisation écrit en Python
Automatisations rédigées en YAML
Utilisations :
- Management de configuration (IAC)
- Orchestration
- Déploiement d'applications

22.8K Stars

7.5K Forks

12K Pull requests

> Ansible - Terminologie

Inventory : Qui est la cible de l'automatisation ?

Static Inventory

Dynamic Inventory

### INI file format

[insset]
10.3.134.11[0:9]
 
[master]
10.3.134.110
 
[students]
10.3.134.111
10.3.134.112
10.3.134.113
10.3.134.11[4:9]

...

> Ansible - Terminologie

Fact : Information pouvant être découverte sur les systèmes

{
...
    "ansible_eth0": {
        "active": true,
        "device": "eth0",
        "ipv4": {
            "address": "REDACTED",
            "netmask": "255.255.255.0",
            "network": "REDACTED"
        },
        ...
    },
    "ansible_kernel": "3.5.0-23-generic",
    "ansible_lsb": {
        "codename": "precise",
        "description": "Ubuntu 12.04.2 LTS",
        "id": "Ubuntu",
        "major_release": "12",
        "release": "12.04"
    },
    "ansible_machine": "x86_64",
...
}

> Ansible - Terminologie

Module : Abstraction d'une tâche

Commandes Linux

Modules Ansible

apt

mkdir

touch

apt

file

http://docs.ansible.com/ansible/list_of_all_modules.html

> Ansible - Terminologie

Task : Éxecution de l'action d'un module avec ses arguments

Codes de retour:

ok - changed - skipped - failed

---
- name: Install Nginx
  apt: 
    name: nginx 
    update_cache: yes 
    state: present

---
- name: Create the scripts log folder 
  file: 
    state: directory
    path: /var/log/scripts
    owner: gumgum
    group: gumgum
    mode: 644

---
- name: Start an EC2 instance
  local_action: 
    module: ec2
    aws_access_key: 'AKIAXXXXXXXXX'
    aws_secret_key: 'XXXXXXXXXXXXX'
    key_name: 'mykeypair.pem'
    instance_type: 'c3.large'
    wait: yes
    image: 'ami-XXXXXX'
    count: 1
    region: 'us-east-1'
    zone: 'us-east-1b'
    monitoring: yes
    group: ['sshonly', 'webapp']
    instance_tags: 
      Name: demo
      Owner: 'Florian Dambrine'
    volumes: 
      - device_name: /dev/sda1
        volume_size: 30

> Ansible - Terminologie

Play : Éxecution de tâches sur une cible (Tasks + Inventory)

$ ansible students -i insset -s -m apt -a "name=nginx state=latest update_cache=yes"
insset-td1 | success >> {
    "changed": true, 
    "stderr": "", 
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state......"
}
insset-td2 | success >> { ...

Exemple avec la commande ad-hoc ansible

Exemple avec la commande ansible-playbook

$ ansible-playbook -i insset nginx-play.yaml

PLAY [webserver] *************************************

TASK: [Install Nginx] ********************************
changed: [insset-td1]
changed: [insset-td2]

PLAY RECAP *******************************************
insset-td1 : ok=0 changed=1 unreachable=0 failed=0   
insset-td2 : ok=0 changed=1 unreachable=0 failed=0

### nginx-play.yaml
---
- hosts: students
  sudo: yes
  tasks:
    - name: Install Nginx
      apt: 
        name: nginx 
        update_cache: yes 
        state: latest

> Ansible - Terminologie

Playbook : Une liste de plays

### nginx-playbook.yaml
---
- name: Install Nginx on Webservers
  hosts: webservers
  sudo: yes
  tasks:
    - name: Install Nginx
      apt: 
        name: nginx
        state: latest
        update_cache: yes

    - name: Cleanup apps-enabled
      file: 
        state: absent 
        path: /etc/nginx/sites-enabled/default
    
    - name: Cleanup apps-available
      file: 
        state: absent 
        path: /etc/nginx/sites-available/default

    - name: Restart Nginx
      service:
        name: nginx
        state: restarted

http://docs.ansible.com/ansible/playbooks_roles.html

> Ansible - Terminologie

Role : Une brique d'automatisation réutilisable

rolename/
├── defaults/        ---> Lowest priority variables.
│   └── main.yaml
├── files/           ---> Contains static files that need to be deployed on remote server.
│   └── ...               
├── handlers/        ---> Contains tasks that can be triggered by a notification event.
│   └── main.yaml         
├── meta/            ---> Contains dependencies between roles.
│   └── main.yaml
├── tasks/           ---> Contains your soup.
│   ├── ...
│   └── main.yaml
├── templates/       ---> Contains templates that will be fed with variables (facts, or role vars).
│   ├── ....j2            
└──  vars/           ---> Higher level of priority where default variables will be overiden.
    ├── ...               
    └── main.yaml

http://docs.ansible.com/ansible/playbooks_roles.html

> Ansible - pour RÉsumer

La liste des DNS et/ou Ip des serveurs gérés par Ansible sont stockés dans un inventory.
Ansible collecte des informations nommées facts sur les serveurs cibles.
L'état d'un serveur est construit grâce à l'exécution de tasks sur le serveur. Une task fait appel à un module Ansible.
Le playbook contient un ou plusieurs plays qui eux mêmes contiennent un ensemble de tasks.
Le role Ansible permet de gagner en modularité, il peut être réutilisé dans plusieurs playbooks.

> Ansible - les variables

group_vars : Définit les variables à utiliser pour un groupe de serveurs
host_vars : Définit les variables à utiliser pour un serveur

### inventories/ccm/hosts

[insset]
10.3.134.11[0:9]
 
[master]
10.3.134.110
 
[students]
10.3.134.111
10.3.134.112
10.3.134.113
10.3.134.11[4:9]

inventories/
└── ccm/
    ├── group_vars/
    │   ├── all/
    │   │   └── vars.yml
    │   ├── master/
    │   │   └── vars.yml
    │   └── students/
    │       └── vars.yml
    ├── hosts
    └── host_vars/
        └── 10.3.134.118/
            └── vars.yaml

roles/what-is-my-port/defaults/main.yml: what_is_my_port: 80

ccm/group_vars/all/vars.yml: what_is_my_port: 8080

ccm/group_vars/master/vars.yml: what_is_my_port: 443

ccm/group_vars/students/vars.yml: what_is_my_port: 8081

ccm/host_vars/10.3.134.118/vars.yaml: what_is_my_port: 8082

http://docs.ansible.com/ansible/intro_inventory.html

https://github.com/Lowess/devops-360-variables

> Ansible - les oPtions en ligne de commande

Principales options:

--limit (-l) : Limite l'action du playbook à un groupe ou à un serveur en particulier

--extra-vars (-e) : Ajoute / Réécrit les variables en ligne de commande

--list-tasks : Liste les tâches qui seront exécutées sur les cibles

--list-hosts : Liste les cibles qui seront impactées par l'automatisation

--start-at-task : Démarre l'automatisation à un endroit donné

--step : Exécute l'automatisation pas-à-pas

--syntax-check : Vérifie la syntaxe de l'automatisation

> Ansible - Hello World !

https://github.com/Lowess/devops-360-hello-world

rÉalisation d'un Projet devops

https://github.com/Lowess/devops-360

https://github.com/Lowess/devops-360-webapp

> L'association 'beerbattle'

Storyboard

Jonathan et Iris lancent une nouvelle association: BeerBattle. Pour leur projet, ils ont decidé de réaliser un site Web qu'ils voudraient héberger sur les serveurs de l'INSSET.

Tous deux développeurs, ils manquent de connaissances en admistration système et font appel à vous pour mettre en place leur infrastructure.

Désireux de faire évoluer leur projet dans le futur, il voudrait que l'ensemble de l'infrastructure soit automatisée afin d'envisager une migration vers le Cloud.

> beerbattle - Overview

Technologies

Infrastructure

LoadBalancer

Webservers

BDD

(Vue par les Devs)

(Vue par les Ops)

Le DevOps apporte ses conseils aux équipes de Devs sur les bonnes pratiques de mise en production de logiciel

Le DevOps doit parfois se former sur les technologies utilisées par les Devs. Il se doit d'uniformiser les bonnes pratiques à travers les différentes équipes de Devs.

> beerbattle - Getting started

https://github.com/Lowess/devops-360

http://docs.ansible.com

L'intégration continue

https://github.com/Lowess/devops-360-ci-cd

https://github.com/Lowess/devops-360-react

> L'intégration continue

Storyboard

Afin d'accélérer les cycles de développement de l'application, les développeurs vous demandent de mettre en place un pipeline d'intégration continue pour leur Single Page Application (SPA).

Continuous Integration (CI):

📍 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🏁

Continuous Delivery (CD):

📍 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🏁

Continuous Deployment (CDD):

📍 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🏁

> L'intégration continue - Infrastructure

> L'intégration continue - Getting Started

https://github.com/Lowess/devops-360-ci-cd

https://github.com/Lowess/devops-360-react

> Références

www.ansiblefordevops.com

The book begins with fundamentals, like installing Ansible, setting up a basic inventory file, and basic concepts, then guides you through Ansible's many uses, including ad-hoc commands, basic and advanced playbooks, application deployments, multiple-provider server provisioning, and even Docker orchestration! Everything is explained with pertinent real-world examples, often using Vagrant-managed virtual machines.

> Extra resources

http://principlesofchaos.org/

Thank You!

florian@gumgum.com

@DambrineF

DevOps 360°

360°

> Whoami

GumGum - CONTEXTUAL Intelligence

GumGum - CONTEXTUAL Intelligence

> Agenda

pourquoi le besoin de devops ?

les Métiers de l'IT

?

?

> L'époque "old School"

L'automatisation par

script shell

> L'époque "old School"

LEs infrastructures "baremetal"

> L'époque "old School"

LEs Releases

PLANIFIÉES

> L'éPOQUE "OLD SCHOOL" ET SES INCONVéNIENTS

> L'époque "old School" est révolue!

Ca fait quoi un devops ?

> l'équipe devops - Par rapport aux autres équipes

DevOps

> l'équipe devops - par rapport à l'infrastucture

> Les missions du devops - L'Automatisation

> Les missions du devops - L'éducation et le conseil

> Les missions du devops - SYSTème et Réseaux

> Les missions du devops - securité

> Les missions du devops - Intégration continue

devops et automatisation

> Les outils d'automatisation

> Introduction à Ansible

> Ansible - Terminologie

> Ansible - Terminologie

> Ansible - Terminologie

> Ansible - Terminologie

> Ansible - Terminologie

> Ansible - Terminologie

> Ansible - Terminologie

> Ansible - pour RÉsumer

> Ansible - les variables

> Ansible - les oPtions en ligne de commande

> Ansible - Hello World !

rÉalisation d'un Projet devops

> L'association 'beerbattle'

Storyboard

> beerbattle - Overview

Technologies

Infrastructure

> beerbattle - Getting started

L'intégration continue

> L'intégration continue

Storyboard

📍 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🏁

📍 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🏁

📍 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🔀 ................. 🏁

> L'intégration continue - Infrastructure

> L'intégration continue - Getting Started

> Références

> Extra resources

Thank You!

Thank You!

- Formulaire Feedback -

Votre avis m'intéresse !