Docker en prod ? Oui, avec Kubernetes !

Pascal MARTIN, DevOps @ M6 Web

Docker en prod ? Oui, avec Kubernetes !

Pascal MARTIN, DevOps @ M6 Web

Appuyez sur [s] pour ouvrir les notes présentateur dans une nouvelle fenêtre.

Utilisez la touche [ESPACE]
pour passer au slide suivant.

Il y a deux ans…

Docker

En dev \o/

Docker

En prod /o\

Aujourd’hui : 6play

Notre projet ?

Migrer vers Le Cloud

Jusqu’à l’année dernière, 6play était hébergée on-prem : sur des VM et des machines physiques que nous gérions nous-mêmes (avec Ansible), à l’ancienne, en déployant avec une surcouche à Capistrano. Nous avons (avions?) un grand projet pour notre hébergement : migrer vers Le Cloud.

Ne plus (vraiment) gérer les serveurs, que ce soit physiques ou virtuels. Exploiter des services managés au lieu de les gérer nous-même. Déployer l’application sous forme de conteneurs.

Même si nous partions vers quelque chose de prometteur, des zones d’ombre subsistaient…

Photo par Bernard Spragg. NZ sur Flickr, Public domain.

Kubernetes

Une solution magique ?

Kubernetes 101

Les conteneurs

Docker : 2013

C’est une révolution ! Amazing!

LXC : 2008

Un conteneur

Virtualisation légére
Un processus
Isolation
Basé sur une image (immuable)

Gestion de conteneurs

Quelques questions

Comment avoir des conteneurs
nginx, php-fpm, varnish, MySQL et Elasticsearch ?
Et qu’ils se parlent ?

Comment avoir
5 conteneurs php-fpm ?
… quand j’ai beaucoup de visiteurs ?

Comment nginx sait
à quels conteneurs php-fpm
envoyer les requêtes ?

Comment avoir
un worker ?
… qui tourne en permanence ?
… et plusieurs ?

Et si un conteneur plante ?

Et comment mettre à jour mon application ?

Bref…

C’est pas facile !

Orchestration is the automated arrangement, coordination, and management of computer systems, middleware, and services.

Quelques orchestrateurs ?

Kubernetes

15 ans d’XP chez Google (Borg)
Open-source (2014), Go
Google, CoreOS, Redhat, Microsoft…
Le orchestrateur de conteneurs.

Primitives principales

Cluster

Regroupe l’ensemble des machines avec lesquelles Kubernetes travaille.

Node

Machine, souvent virtuelle, qui fait partie du cluster.

Master node

Pour les fonctionnalités internes de Kubernetes.

Worker node

Pour vos applications.

Pod

Une application tourne, sous forme d’un ou plusieurs containers, dans un pod.

Pod

Plein d’options !

Replicas
Sécurité
Liveness probe
Readiness probe
Volumes

Requests
Limits
Envvars
Stratégie de MAJ
Hooks start/stop

Service

Expose un (ou plusieurs) pod sur le réseau.

Scaling

Horizontal Pod Autoscaler : + de pods
Cluster autoscaler : + de nodes

C’est pas fini !

Plein d’autres primitives.
Pas besoin de les connaitre tout de suite…

Du YAML

apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: monapp-api
    spec:
      template:
        metadata:
          labels:
            app: "monapp"
            type: "api"
        spec:
          containers:
          - name: "php"
            image: "mon-registre.com/monapp-php:v42"
            env:
            - name: APP_ENV
              value: "prod"
    ...

apiVersion: v1
    kind: Service
    spec:
      type: LoadBalancer
      ports:
      - name: nginx-http
        protocol: TCP
        port: 80
        targetPort: 8080
      selector:
        app: "monapp"
        type: "api"

apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: "monapp-api"
      minReplicas: 2
      maxReplicas: 8
      metrics:
      - type: Resource
        resource:
          name: cpu
          targetAverageUtilization: 80

Enfin, voici l’auto-scaler qui nous permet de répondre à une charge variable.

Il s’assure que nous ayons toujours entre 2 et 8 pods, et vise une charge CPU à 80% sur ceux-ci. Si la charge dépasse 80%, le nombre de pods augment. Sinon, il diminue. Dans les limites 2-8.

Nous n’exploitons pas encore cette fonctionnalité, mais nous pourrions aussi nous baser sur d’autres métriques, pour peu qu’elles soient disponibles dans un système compatible -- comme Prometheus. Exemple : scaler un nombre de workers en fonction du nombre de messages dans une file.

Photo par Kletis Roy sur Unsplash.

`kubectl`


    kubectl apply -f *.yaml

$ kubectl get pods
    NAME                            READY  STATUS   RESTARTS  AGE
    service-…-api-764b8d9594-7m2n2  2/2    Running  0         3d
    service-…-api-764b8d9594-884sl  2/2    Running  0         3d

    $ kubectl get svc
    NAME           TYPE          CLUSTER-IP     EXTERNAL-IP   PORT(S)       AGE
    kubernetes     ClusterIP     100.64.0.1     <none>        443/TCP       72d
    service-…-api  LoadBalancer  100.64.14.251  aa4a30a359c…  80:30939/TCP  72d

    $ kubectl get hpa
    NAME           REFERENCE         TARGETS  MINPODS  MAXPODS  REPLICAS  AGE
    service-…-api  Deployment/…-api  12%/80%  2        4        2         18d

Récapitulons

Un cluster Kubernetes…

Nodes (masters + workers)
Pods, Services
Scaling : pods, nodes
kubectl

Le Cloud
@ M6 Web

Nos équipes

Sysadmins
Dév. front + back
DevOps
Product owners
Management

Un projet de cette ampleur, ça ne se fait pas tout seul : il faut des gens qui bossent dessus.

Des sysadmins, bien sûr, ainsi que des développeurs. Nous avons aussi une toute petite équipe devops (dont je fais partie) qui est notamment là pour faciliter ce projet de migration -- y compris en servant un peu de glue entre les deux ops et les devs.

Un projet de cette taille n’est pas possible sans communiquer avec les product owners (la migration impacte les projets ; et demande du temps de développeurs). Et elle n’est absolument pas envisageable sans support du management (même si on l’oublie un peu souvent).

Photo par Margarida CSilva sur Unsplash.

Nos applications

Web, API, Workers
Beaucoup de PHP + JS/node

Charge variable

IaaS, Services managés

Plus de souplesse
Moins d’administration système ?
Sur AWS : S3, RDS, SQS, DynamoDB…

Infrastructure as Code

Base commune : ops
Spécifique projets : devs
Approche DevOps

Nous voulons décrire l’ensemble de notre infrastructure sous forme de code : hors de question que nous allions cliquer dans des consoles Web ! À la place, comme fait depuis toujours par les équipes de développement, nous souhaitons que notre infrastructure soit décrite dans des fichiers (texte), que les modifications passent par des revues de code / pull-requests et que master représente la production.

Les ops sont responsables des briques de base communes à tous les projets (comme la gestion des droits et le réseau) et les développeurs décrivent, dans leurs projets, ce dont ils ont besoin (comme une base de données).

Bien sûr, nous bossons ensemble : il est fréquent qu’un dev et un ops passent deux heures ou une demi-journée en pair sur une même machine pour décrire l’infrastructure d’un projet -- comme les développeurs faisaient déjà, entre eux, pour des problématiques de code.

Photo par Ansh Bhagania sur Unsplash.

Terraform

resource "aws_db_instance" "database" {
        identifier     = "${var.rds_database_identifier}"
        name           = "dbname"
        username       = "username"
        password       = "password"
        engine         = "postgres"
        engine_version = "10.3"
        instance_class = "${var.instance_type}"

        tags {
            project = "${var.project}"
            team    = "${var.team}"
            name    = "${var.rds_database_identifier}"
        }
    }

L’outil que nous utilisons pour décrire et piloter notre infrastructure est Terraform. Vous avez ici un extrait d’un bout de code Terraform qui nous permet de créer une base de données sur le service RDS d’AWS.

Point extrêmement intéressant : on peut utiliser des variables ! Ainsi, cette portion de code est utilisée, pour nous, en développement, puis staging puis production, avec des valeurs différentes pour le type d’instance. Nous prenons une instance de petite taille (ne coutant pas cher) en développement, de taille un peu plus grosse (mais toujours raisonnable) en staging, et une grosse instance (couteuse, mais avec de la patate) en production. Dans tous les cas, c’est le même code qui est employé.

Photo par https://unsplash.com/@jeremybishop sur Unsplash.

Dans les projets

Infrastructure de dev
Validation en staging
Backups, performances, failover…
Déploiement en production

Dans les projets

.cloud/
        docker/
            nginx/Dockerfile
            php/Dockerfile
        jenkins/
            Jenkinsfile
        kubernetes/
            deployment.yaml
        terraform/
            vars/
            rds.tf

Une nouvelle app ?

Pas d’existant
Pas de migration
Facile !
Pas de fallback ;-(

Sécurité !

Appli existante
1% dans Le Cloud
99% on-premise

Monitoring

Système : Prometheus

Monitoring

Applicatif : on-prem

Logging

on-prem

1^ère migration : bilan ?

1^ère migration : bilan ?

Applications
cloud native

Récapitulons

Coder « cloud native »
Infrastructure : Terraform
Dockerfiles + build des images
Manifests Kubernetes
CD, Jenkins

C’est pas
fini !

Ecosystème
moyennement
mûr

CI/CD,
déploiement

CI/CD, déploiement

Pipeline Jenkins

Ça bouge.
Toujours.
Vite.

Ça bouge. Toujours. Vite.

Service mesh, monitoring, déploiement, logging, CRD, Serverless, Distroless…

Et les mises à jour…

Ça bouge. Toujours. Vite.

On a migré dans le cloud en 5 minutes, pour 5 dollars par mois !

Environnement
de dev ?

Environnement de dev ?

Quelques pistes à essayer

Telepresence
Skaffold

Le mot
de la fin…

Migrer vers Le Cloud

Ça prend beaucoup de temps !

Objectif atteint !

Mais la route n’est pas toute droite…

Kubernetes, super puissant

Outil mûr, qui marche très bien
et qui se répand.

Falaise d’apprentissage !

#noPanic

Pas encore
tout mûr autour…

C.D.D.

~~Conference Driven Devops~~

Pascal MARTIN

blog.pascal-martin.fr
@pascal_martin

M6 Web, Lyon

leanpub.com/6cloud

Le Plan Copenhague

Comment nous avons migré la plate-forme 6play vers Le Cloud, sur AWS et Kubernetes.

Docker en prod ? Oui, avec Kubernetes !

Docker en prod ? Oui, avec Kubernetes !

Il y a deux ans…

Docker

Docker

Aujourd’hui : 6play

Notre projet ?

Kubernetes

Kubernetes 101

Les conteneurs

Un conteneur

Gestion de conteneurs

Bref…

Quelques orchestrateurs ?

Kubernetes

Primitives principales

Cluster

Node

Master node

Worker node

Pod

Pod

Service

Scaling

C’est pas fini !

Du YAML

kubectl

Récapitulons

Le Cloud@ M6 Web

Nos équipes

Nos applications

Charge variable

IaaS, Services managés

Infrastructure as Code

Terraform

Dans les projets

Dans les projets

Une nouvelle app ?

Sécurité !

Monitoring

Monitoring

Logging

1ère migration : bilan ?

1ère migration : bilan ?

1ère migration : bilan ?

Applicationscloud native

Récapitulons

C’est pasfini !

Ecosystème moyennement mûr

CI/CD,déploiement

CI/CD,déploiement

CI/CD, déploiement

Ça bouge. Toujours. Vite.

Ça bouge. Toujours. Vite.

Ça bouge. Toujours. Vite.

Environnementde dev ?

Environnement de dev ?

Le motde la fin…

Migrer vers Le Cloud

Objectif atteint !

Kubernetes, super puissant

Falaise d’apprentissage !

#noPanic

Pas encoretout mûr autour…

C.D.D.

Pascal MARTIN

leanpub.com/6cloud

`kubectl`

Le Cloud
@ M6 Web

1^ère migration : bilan ?

1^ère migration : bilan ?

1^ère migration : bilan ?

Applications
cloud native

C’est pas
fini !

Ecosystème
moyennement
mûr

CI/CD,
déploiement

CI/CD,
déploiement

Ça bouge.
Toujours.
Vite.

Environnement
de dev ?

Le mot
de la fin…

Pas encore
tout mûr autour…