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

ln

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

Thank You!

- Formulaire Feedback -

Votre avis m'intéresse !

DevOps 360°

By Florian Dambrine

Made with Slides.com

DevOps 360°

DevOps 360° is an introduction to automation with Ansible. This project is meant for teaching automation to Master students. The idea is to spin up virtual machines, install and configure servers to run a Python (Flask) Webapp. This Webapp relies on a Mysql backend. Once the infrastructure is fully up, we will see how Ansible can help orchestrate, deploy / rollback or do blue / green deployments. Finally you will learn about writing modern CI / CD / CDD pipelines with Drone in order to Build / Test / Release and Deploy software on AWS. You can find all the git repositories used in this course matching devops-360-* here https://github.com/Lowess

  • 3,287

More from Florian Dambrine