Drone CI | Pipeline Docker CI / CD – Avis Drones, test et guide d’achat

Dans l'enseignement supérieur, nous avons testé et utilisé
pas mal d'outils CI / CD pour notre pipeline Docker CI. Utilisation de Rancher et
Drone CI s'est avéré être le plus simple, le plus rapide et le plus agréable
expérience que nous avons trouvée à ce jour. À partir du moment où le code est poussé / fusionné
dans une branche de déploiement, le code est testé, créé et déployé sur
production dans environ la moitié du temps des solutions hébergées dans le cloud – aussi peu
de trois à cinq minutes (certaines applications prennent plus de temps en raison d'un
construction / test). Les constructions de drones sont également extrêmement faciles pour nos
les développeurs de configurer et de maintenir, et de le faire installer sur Rancher est
comme tout le reste sur Rancher – très simple.

Nos principales exigences pour un pipeline CI / CD

Le pipeline CI / CD est vraiment le cœur de l'expérience DevOps et est
certainement le plus percutant pour nos développeurs. D'un développeur
perspective, les deux choses qui importent le plus pour un pipeline CI / CD sont
rapidité et simplicité. La vitesse est n ° 1 sur la liste, car rien de pire
que de pousser une ligne de code et d'attendre 20 minutes
arriver à la production. Ou pire encore… en cas de problème de production,
développeur pousse un correctif uniquement pour que les dollars de l'entreprise continuent à
faire pousser des ailes et s'envoler au fur et à mesure que votre pipeline de déploiement se déplace. Simplicité
est n ° 2, car dans un monde idéal, les développeurs peuvent construire et maintenir
leurs propres configurations de déploiement d'applications. Cela rend la vie plus facile
pour tout le monde à long terme. Vous ne voulez certainement pas de développeurs
frapper à votre porte (Slack) à chaque fois que leur construction échoue pour certains
raison.

Points Docker CI / CD Pipeline Speed ​​Pain

Bien que les conteneurs immuables soient de loin supérieurs au maintien avec état
serveurs, ils ont quelques inconvénients – le plus grand étant
vitesse de déploiement: il est plus lent de créer et de déployer une image de conteneur
que de simplement pousser le code vers un serveur existant. Voici tous les lieux
qu'un pipeline de déploiement Docker peut passer du temps: Drone CI | Pipeline Docker CI / CD
- Avis Drones, test et guide d'achat 2 1) (CI: extraire l'image de base pour l'application depuis
Registre Docker) 2) (CI: construire une image de test (avec les dépendances de test) et
exécuter des tests) 3) (CI: construire une image de production (pas de dépendances de test)) 4)
(CI: envoyer l'image de l'application au Docker Registry) 5) (Infrastructure:
tirer l'image de l'application du Docker Registry) 6) (Arrêtez les vieux conteneurs,
commencer de nouveaux) Selon la taille de votre application
et combien de temps il faut pour construire, latence avec le registre Docker (étapes
1, 4, 5) est probablement l'endroit où vous passerez la plupart de votre temps
Build Docker. Le temps de génération de l'application (étapes 2, 3) peut être fixe
variable, mais il peut également être considérablement affecté par la mémoire ou le processeur
cœurs disponibles pour le processus de génération. Si vous utilisez un CI hébergé dans le cloud
solution, vous ne contrôlez pas où les serveurs CI s'exécutent
(la latence du registre peut être vraiment lent) et vous pourriez ne pas avoir le contrôle
sur le type de serveurs / instances en cours d'exécution (la création d'application peut être
lent). Il y aura également beaucoup de travail répété pour chaque construction
comme téléchargement d'images de base pour chaque build.

Entrez Drone CI

Le drone fonctionne sur votre infrastructure Rancher un peu comme un outil comme Jenkins
le ferait, mais, contrairement à Jenkins, Drone est natif de Docker – chaque partie de votre
le processus de construction est un conteneur. L'exécution sur votre infrastructure s'accélère
le processus de construction, car les images de base peuvent être partagées entre les générations ou même
projets. Vous pouvez également éviter BEAUCOUP de latence si vous poussez vers un Docker
registre qui se trouve sur votre propre infrastructure, comme ECR pour AWS. Drone
être natif de Docker supprime également beaucoup de friction de configuration.
Quiconque a dû configurer Jenkins sait que c'est un gros plus. UNE
le déploiement de drone standard fait quelque chose comme ceci:

  • Exécutez un conteneur pour informer Slack qu'un build a commencé
  • Configurez n'importe quelle image de base pour votre conteneur «test», le code obtient
    injecté et tests exécutés dans le conteneur
  • Exécutez un conteneur qui crée et pousse votre image de production (pour
    Docker Hub, AWS ECR, etc.)
  • Exécutez un conteneur qui indique à Rancher de mettre à niveau un service
  • Exécutez un conteneur pour informer Slack qu'une génération est terminée / a échoué

Un fichier .drone.yml ressemble étrangement à un fichier docker-compose.yml
– juste une liste de conteneurs. Étant donné que chaque étape a un conteneur dédié
pour cette tâche, la configuration de cette étape est généralement très simple.

Mise en route et fonctionnement du drone

La liste des tâches ici est simple:

  • Enregistrer une nouvelle application GitHub OAuth
  • Créer un environnement de drone dans Rancher
  • Ajouter un hôte «Drone Server» et un ou plusieurs hôtes «Drone Worker»
    • Ajouter un drone=server tag vers l'hôte du serveur Drone
  • Exécutez la pile de drones

La taille des instances dépend de vous – dans l'enseignement supérieur, nous préférons moins,
des travailleurs plus puissants, car cela se traduit par des builds plus rapides. (Nous avons
a constaté qu'un travailleur puissant a tendance à gérer les constructions très bien pour
équipes de sept) Une fois que vos serveurs de drones sont en place, vous pouvez exécuter cette pile:

version: '2'
services:
  drone-server:
    image: drone/drone:0.5
    environment:
      DRONE_GITHUB: 'true'
      DRONE_GITHUB_CLIENT: 
      DRONE_GITHUB_SECRET: 
      DRONE_OPEN: 'true'
      DRONE_ORGS: myGithubOrg
      DRONE_SECRET: 
      DRONE_GITHUB_PRIVATE_MODE: 'true'
      DRONE_ADMIN: someuser,someotheruser,
      DRONE_DATABASE_DRIVER: mysql
      DRONE_DATABASE_DATASOURCE: user:password@tcp(databaseurl:3306)/drone?parseTime=true
    volumes:
    - /drone:/var/lib/drone/
    ports:
    - 80:8000/tcp
    labels:
      io.rancher.scheduler.affinity:host_label: drone=server
  drone-agent:
    image: drone/drone:0.5
    environment:
      DRONE_SECRET: 
      DRONE_SERVER: ws://drone-server:8000/ws/broker
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    command:
    - agent
    labels:
      io.rancher.scheduler.affinity:host_label_ne: drone=server
      io.rancher.scheduler.global: 'true'

Cela exécutera un Drone Server sur votre drone=server hôte, et un
agent de drone sur tous les autres hôtes de votre environnement. Soutenir le drone avec
MySQL via le DATABASE_DRIVER et DATASOURCE les valeurs sont facultatives,
mais fortement recommandé. Nous utilisons une petite instance RDS. Une fois que la pile est
opérationnel, vous pouvez vous connecter à votre adresse IP du serveur Drone et
sur un repo pour les builds (depuis le menu Compte). Vous remarquerez que
il n'y a vraiment aucune configuration pour chaque dépôt depuis l'interface utilisateur du drone. Tout ça
se produit via un fichier .drone.yml archivé dans chaque référentiel.

Ajout d'une configuration de construction

Pour créer et tester un projet node.js, ajoutez un fichier .drone.yml à votre référentiel
qui ressemble à ceci:

pipeline:
  build:
    image: node:6.10.0
    commands:
      - yarn install
      - yarn test

C'est simple et direct, votre étape de construction définit simplement le conteneur
image dans laquelle le code du référentiel est placé et spécifie les commandes à
courir dans ce conteneur. Tout le reste sera géré avec Drone
plugins
, qui ne sont que des conteneurs conçus
pour une tâche. Étant donné que les plugins vivent dans Docker Hub, vous n'installez pas
leur
, ajoutez-les simplement à votre fichier .drone.yml Une version plus complète
comme je l'ai mentionné ci-dessus utilise les plugins Slack, ECR et Rancher pour créer
ce .drone.yml:

pipeline:
  slack:
    image: plugins/slack
    webhook: 
    channel: deployments
    username: drone
    template: " on  by {{build.author}}"
    when:
      branch: ( master, staging )
  build:
    image: 
    commands:
      - yarn install
      - yarn test
    environment:
      - SOME_ENV_VAR=some-value
  ecr:
    image: plugins/ecr
    access_key: ${AWS_ACCESS_KEY_ID}
    secret_key: ${AWS_SECRET_ACCESS_KEY}
    repo: 
    dockerfile: Dockerfile
    storage_path: /drone/docker
  rancher:
    image: peloton/drone-rancher
    url: 
    access_key: ${RANCHER_ACCESS_KEY}
    secret_key: ${RANCHER_SECRET_KEY}
    service: core/platform
    docker_image: 
    confirm: true
    timeout: 240
  slack:
    image: plugins/slack
    webhook: 
    channel: deployments
    username: drone
    when:
      branch: ( master, staging )
      status: ( success, failure )

Bien qu'il puisse s'agir de 40 lignes, il est extrêmement lisible et 80% de cela est
copier et coller à partir des documents du plugin Drone. (Essayez de faire tout cela
les choses dans une plate-forme CI hébergée dans le cloud et vous aurez probablement une journée
valeur de documents à lire devant vous.) Remarquez comment chaque plugin
n'a pas besoin de beaucoup de configuration. Si vous souhaitez utiliser Docker Hub à la place
ECR, utilisez le Docker
brancher
au lieu.
Voilà! En quelques minutes, vous pouvez avoir un CD pleinement fonctionnel
pipeline en marche. C’est aussi une bonne idée d’utiliser le Rancher
Pile de catalogue de concierge pour empêcher l'espace disque de vos employés de se remplir,
sachez que moins vous nettoyez souvent, plus vos constructions seront rapides
être, car plus de couches seront mises en cache. Will Stern est architecte logiciel
pour HigherEducation et offre également une formation Docker à travers
LearnCode.academy et O’Reilly Video Training.

Nous serions ravis de connaître votre avis

      Laisser un commentaire