Comment installer et configurer un drone sur Ubuntu 16.04

De Get Docs
Aller à :navigation, rechercher

Attention : Cette version de Drone est obsolète. Pour obtenir de l'aide sur l'installation de la dernière version de Drone, visitez notre tutoriel d'installation d'Ubuntu 20.04 Drone.


Introduction

Drone est une plate-forme populaire d'intégration et de livraison continues intégrée à Go. Il s'intègre à de nombreux services de référentiel de contrôle de version populaires tels que GitHub, GitLab et Bitbucket pour surveiller les modifications de code et créer et tester automatiquement les modifications au fur et à mesure qu'elles sont validées.

Dans ce guide, nous vous montrerons comment mettre en place un environnement complet d'intégration continue Drone pour votre infrastructure. Nous installerons Drone et le configurerons pour l'intégrer à votre référentiel de code source. En cours de route, nous configurerons Nginx, protégé par Let's Encrypt, en tant qu'interface pour Drone. Cela chiffrera les demandes adressées à l'interface Web de Drone et permettra au serveur CI de s'intégrer en toute sécurité au serveur de code source.

Conditions préalables

Pour commencer, vous devez avoir un serveur Ubuntu 16.04 configuré avec un utilisateur non root sudo pour les tâches administratives. Le serveur doit également disposer d'un pare-feu pour filtrer les connexions entrantes. Vous pouvez apprendre à configurer ces éléments en suivant Guide de configuration initiale du serveur Ubuntu 16.04.

Vous devrez effectuer quelques étapes supplémentaires pour satisfaire aux autres exigences de notre configuration. Étant donné que Drone est principalement distribué sous forme d'image Docker, nous utiliserons Docker Compose pour gérer les conteneurs du serveur CI. Pour des raisons de sécurité et de performance, nous transmettrons les requêtes à Drone via une instance Nginx protégée par Let's Encrypt. Vous aurez besoin d'un nom de domaine attaché à votre serveur CI pour le configurer correctement.

Avant de commencer, consultez les articles suivants pour configurer ces exigences supplémentaires :

Lorsque vous avez terminé les guides ci-dessus, votre serveur Drone devrait avoir :

  • Un utilisateur sudo configuré pour les tâches administratives
  • Un pare-feu UFW activé. Il devrait bloquer toutes les connexions à l'exception des requêtes SSH, HTTP et HTTPS sur les ports 22, 80 et 443 respectivement.
  • Docker et Docker Compose installés.
  • Un serveur Nginx configuré avec un certificat SSL fourni par Let's Encrypt

Continuez ci-dessous lorsque vous êtes prêt à commencer.

Ajouter une application à votre référentiel de code source

Afin de surveiller les changements de code pour déclencher les étapes de construction et de test, Drone aura besoin d'accéder à votre référentiel de code source. Le drone peut s'intégrer à GitHub, GitLab, Gogs, Bitbucket Cloud et Bitbucket Server.

Dans ce guide, nous nous concentrerons sur l'intégration avec un référentiel GitHub, mais le processus devrait être similaire pour les autres systèmes. Si vous utilisez un référentiel de code source différent, suivez le lien approprié ci-dessus pour en savoir plus sur la configuration spécifique au logiciel dont vous aurez besoin.

Commencez par visiter votre compte GitHub. Cliquez sur votre icône d'utilisateur dans le coin supérieur droit et sélectionnez Paramètres dans le menu déroulant :

Ensuite, recherchez l'élément Applications OAuth dans la section Paramètres développeur sur le côté gauche de l'écran :

Sur la page qui suit, cliquez sur Enregistrer une nouvelle application :

Ensuite, vous verrez le formulaire d'inscription à l'application OAuth :

Vous devrez remplir les champs suivants (ces champs sont présents sur GitHub. D'autres fournisseurs de référentiels peuvent avoir des invites différentes) :

  • Nom de l'application : un nom que vous choisissez pour identifier l'intégration. "Drone" est un bon choix si vous n'avez pas de besoins particuliers.
  • URL de la page d'accueil : le nom de domaine de votre serveur Drone. Utilisez https:// ici puisque nous utilisons un domaine sécurisé.
  • Description de l'application : une description simple du drone et de son objectif.
  • URL de rappel d'autorisation : il doit s'agir du spécificateur de schéma https://, suivi du nom de domaine de votre serveur Drone, suivi de /authorize. Si notre nom de domaine est example.com, ce fichier sera https://example.com/authorize.

Lorsque vous êtes prêt, cliquez sur Enregistrer l'application .

Sur la page suivante, vous verrez les détails de votre nouvelle application. Les deux éléments dont nous avons besoin sont le Client ID et le Client Secret :

Copiez ces deux valeurs pour plus tard. Nous en aurons besoin pour connecter Drone à notre compte GitHub.

Tirez l'image Drone Docker et préparez-vous pour la configuration

Maintenant que votre serveur Drone est enregistré auprès d'un fournisseur de référentiel, vous pouvez installer et configurer Drone sur votre serveur.

Drone est distribué en tant que conteneur Docker, il sera donc automatiquement téléchargé si nous l'utilisons dans un fichier Docker Compose. Cependant, pour accélérer légèrement le processus, nous pouvons dérouler l'image à l'avance :

docker pull drone/drone:0.7

L'image Drone Docker est un conteneur unifié qui peut être exécuté de différentes manières. Nous allons exécuter un conteneur qui fonctionne comme le serveur Drone, qui coordonne l'accès au référentiel, héberge l'interface utilisateur Web et sert l'API. En utilisant la même image avec des paramètres différents, nous exécuterons un autre conteneur en tant qu'agent Drone, qui est responsable de la création et du test des logiciels à partir des référentiels configurés.

Nous exécuterons ces deux conteneurs sur l'hôte Drone à l'aide de Docker Compose. Commencez par créer un répertoire de configuration pour stocker les fichiers dont nous aurons besoin :

sudo mkdir /etc/drone

Ensuite, nous allons créer quelques fichiers pour configurer nos services.

Créer un fichier Docker Compose pour Drone

Commencez par créer un fichier Docker Compose dans le répertoire de configuration :

sudo nano /etc/drone/docker-compose.yml

À l'intérieur, nous marquerons le format de fichier Docker Compose comme version "3". Ensuite, nous définirons des services pour les deux services que nous avons décrits ci-dessus.

Le service drone-server démarrera le conteneur principal du serveur Drone à l'écoute sur le port 8000. Nous monterons le répertoire /var/lib/drone de l'hôte à l'intérieur du conteneur afin que Drone puisse conserver ses données. Nous allons configurer le service pour qu'il redémarre automatiquement et pour lire des instructions de configuration plus détaillées sous la forme de variables d'environnement définies dans un fichier que nous allons créer à /etc/drone/server.env.

Le service drone-agent utilise la même image, lancée avec la commande agent. Il reçoit des instructions de l'instance principale du serveur Drone, donc bien qu'il n'ait pas besoin d'un accès général au réseau, il doit être démarré après le service Drone. Il a également besoin d'accéder au fichier de socket de Docker pour faire tourner les conteneurs afin d'exécuter les étapes de construction et de test réelles. Comme le service drone-server, ce service redémarrera également automatiquement et lira un fichier d'environnement sur /etc/drone/agent.env pour une configuration supplémentaire.

Utilisez le fichier Docker Compose suivant pour configurer ces deux services. Portez une attention particulière au formatage YAML du fichier, car des erreurs d'indentation ou de formatage peuvent provoquer des erreurs :

/etc/drone/docker-compose.yml

version: '3'

services:
  drone-server:
    image: drone/drone:0.7
    ports:
      - 127.0.0.1:8000:8000
    volumes:
      - /var/lib/drone:/var/lib/drone
    restart: always
    env_file:
      - /etc/drone/server.env

  drone-agent:
    image: drone/drone:0.7
    command: agent
    depends_on:
      - drone-server
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: always
    env_file:
      - /etc/drone/agent.env

Lorsque vous avez terminé, enregistrez et fermez le fichier Docker Compose.

Configurer le fichier de variable d'environnement du serveur Drone

Ensuite, nous devons créer le fichier de variables d'environnement du serveur Drone que nous avons référencé dans le fichier Docker Compose ci-dessus.

Avant d'ouvrir le fichier, nous devons générer une clé forte pour authentifier les composants de l'agent et du serveur. Bien que notre configuration ait ces deux composants sur le même serveur, à mesure que votre infrastructure de test évolue, une clé solide est essentielle. Sur la ligne de commande, générez une clé en tapant :

LC_ALL=C </dev/urandom tr -dc A-Za-z0-9 | head -c 65 && echo

Cette commande définit temporairement la langue dans le shell sur une plage limitée de caractères. Il prend ensuite un flux d'octets aléatoires de /dev/urandom et filtre davantage tous les caractères non alphanumériques. Nous prenons les 65 premiers caractères comme clé.

La sortie ressemblera à ceci ( Ne copiez pas la valeur ci-dessous ! Générez le vôtre ! ):

OutputERmA7xubDvTa8i0wYBlljc9yjT1NJPG7xOlZBwAdMAmBYL4RZE4QngxWcCLowk9KN

Copiez la clé générée à utiliser dans le fichier d'environnement du serveur.

Créez un nouveau fichier sur /etc/drone/server.env et ouvrez-le dans votre éditeur de texte :

sudo nano /etc/drone/server.env

À l'intérieur, nous définirons les variables d'environnement que Drone utilise pour se connecter pour démarrer le service, se connecter au fournisseur de référentiel et définir des politiques d'autorisation de compte. Vous aurez besoin des valeurs que vous avez copiées précédemment à partir de votre fournisseur de référentiel pour remplir correctement les valeurs.

Pour commencer, définissez les valeurs DRONE_HOST et DRONE_SECRET. Définissez DRONE_SECRET sur la clé que vous avez générée sur la ligne de commande. Le paramètre DRONE_HOST informe Drone de son adresse publiquement accessible. Il doit s'agir de votre domaine protégé Let's Encrypt, précédé du spécificateur de schéma https:// :

/etc/drone/server.env

# Service settings
DRONE_SECRET=secret_generated_on_command_line
DRONE_HOST=https://example.com

Ensuite, nous allons configurer l'intégration avec notre fournisseur VCS, qui est GitHub dans notre cas. Les paramètres appropriés pour votre projet peuvent différer en fonction de vos besoins et de la façon dont vos actifs GitHub sont organisés.

Nous verrouillerons l'installation de notre drone et désactiverons l'enregistrement ouvert en réglant DRONE_OPEN sur false. Cela signifie que seuls les noms de compte GitHub spécifiés dans DRONE_ADMIN pourront se connecter.

Remarque : Si vous travaillez avec des collaborateurs en tant qu'organisation GitHub, il est préférable de définir DRONE_OPEN sur true et de remplacer DRONE_ADMIN par [X146X ]. Le paramètre DRONE_ORGS vous permet de spécifier une ou plusieurs organisations GitHub dont les membres doivent être autorisés à s'inscrire. Drone limitera l'enregistrement aux utilisateurs appartenant à ces groupes.


Assurez-vous que DRONE_ADMIN contient le nom de votre compte GitHub.

Ensuite, activez le plug-in d'intégration GitHub en définissant DRONE_GITHUB sur true. Nous définirons ensuite DRONE_GITHUB_CLIENT et DRONE_GITHUB_SECRET sur les clés que nous avons copiées depuis la page de l'application GitHub OAuth lors de l'enregistrement de notre application Drone :

/etc/drone/server.env

# Service settings
DRONE_SECRET=secret_generated_on_command_line
DRONE_HOST=https://example.com

# Registration settings
DRONE_OPEN=false
DRONE_ADMIN=sammytheshark

# GitHub Settings
DRONE_GITHUB=true
DRONE_GITHUB_CLIENT=Client_ID_from_GitHub
DRONE_GITHUB_SECRET=Client_Secret_from_GitHub

Nous avons terminé la configuration du composant serveur. Avant de quitter, copiez la valeur DRONE_SECRET du fichier. Nous devrons définir cette même clé dans la section suivante lorsque nous configurerons l'agent. Enregistrez et fermez le fichier lorsque vous avez terminé.

Configurer le fichier de variables d'environnement de l'agent drone

Ensuite, nous allons créer un fichier d'environnement pour le composant de l'agent Drone.

Ouvrez un nouveau fichier pour définir les variables d'environnement de l'agent :

sudo nano /etc/drone/agent.env

A l'intérieur, il suffit de définir deux valeurs. Le DRONE_SECRET correspondra à la configuration dans le fichier sever.env.

Le paramètre DRONE_SERVER configurera la manière dont l'agent doit se connecter au composant serveur Drone. Il commencera par un préfixe de protocole wss:// pour indiquer que la connexion utilisera un socket Web crypté suivi du nom de domaine du serveur Drone avec l'URI /ws/broker ajouté à la fin :

/etc/drone/agent.env

DRONE_SECRET=secret_generated_on_command_line
DRONE_SERVER=wss://example.com/ws/broker

Enregistrez et fermez le fichier lorsque vous avez terminé.

Configurer le fichier d'unité Drone Systemd

Maintenant que nos fichiers de configuration sont en place, nous pouvons définir un fichier d'unité systemd pour gérer le service Drone.

Ouvrez un nouveau fichier .service dans le répertoire /etc/systemd/system pour configurer le service :

sudo nano /etc/systemd/system/drone.service

À l'intérieur, collez le contenu suivant :

/etc/systemd/system/drone.service

[Unit]
Description=Drone server
After=docker.service nginx.service

[Service]
Restart=always
ExecStart=/usr/local/bin/docker-compose -f /etc/drone/docker-compose.yml up
ExecStop=/usr/local/bin/docker-compose -f /etc/drone/docker-compose.yml stop

[Install]
WantedBy=multi-user.target

La première section indique à systemd de démarrer ce service une fois que Docker et Nginx sont disponibles. La deuxième section indique au système init de redémarrer automatiquement le service en cas d'échec. Il définit ensuite les commandes pour démarrer et arrêter le service Drone à l'aide de Docker Compose et du fichier de configuration que nous avons créé précédemment. Enfin, la dernière section définit comment permettre au service de démarrer au démarrage.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Avant de démarrer le service Drone, nous devons configurer Nginx. L'agent Drone doit pouvoir se connecter au serveur Drone et la connexion repose sur la mise en place du proxy Nginx.

Configurer Nginx pour envoyer des requêtes proxy au drone

Ensuite, nous devons modifier la configuration de Nginx pour envoyer des requêtes proxy à notre serveur Drone.

Commencez par trouver la configuration du bloc de serveur qui gère votre domaine protégé par Let's Encrypt. Recherchez l'attribut server_name dans tous les blocs de serveur activés en tapant :

grep -R server_name /etc/nginx/sites-enabled
Output/etc/nginx/sites-enabled/default:   server_name example.com;
/etc/nginx/sites-enabled/default:   return 301 https://$server_name$request_uri;
/etc/nginx/sites-enabled/default:   server_name example.com;
/etc/nginx/sites-enabled/default:#  server_name example.com;

Dans la sortie ci-dessus, le nom de domaine (example.com dans ce cas) est défini dans le fichier /etc/nginx/sites-enabled/default. Vous voudrez modifier le fichier (la première colonne) associé à votre nom de domaine.

Il est possible que vous voyiez également quelque chose comme ceci :

Output/etc/nginx/sites-enabled/default:   server_name _;
/etc/nginx/sites-enabled/default:   return 301 https://$server_name$request_uri;
/etc/nginx/sites-enabled/default:   server_name _;
/etc/nginx/sites-enabled/default:#  server_name example.com;

Dans la sortie ci-dessus, les lignes server_name _; représentent des blocs de serveur destinés à agir comme mécanismes de secours. Le spécificateur d'hôte "_" est un hôte invalide, il ne correspondra donc jamais tout seul.

Dans la configuration, ceux-ci sont associés aux directives listen qui définissent l'option default_server afin que le bloc agisse par défaut lorsque l'hôte demandé ne correspond à aucun autre bloc de serveur défini. Si vous ne trouvez pas de définition server_name correspondant à votre nom de domaine, vous devez utiliser le fichier qui définit ces blocs de secours à la place.

Ouvrez le fichier le mieux associé à votre domaine dans votre éditeur de texte :

sudo nano /etc/nginx/sites-enabled/default 

À l'intérieur, nous commencerons par ajouter deux sections en dehors des blocs server existants :

/etc/nginx/sites-enabled/default

upstream drone {
    server 127.0.0.1:8000;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    . . .

Le premier bloc configure un emplacement en amont appelé drone où nous pouvons envoyer des requêtes par proxy. La directive server définit comment se connecter à notre service Drone, qui s'exécutera sur le port 8000.

Le deuxième bloc définit une variable définie par l'utilisateur appelée $connection_upgrade en fonction de la valeur de la variable $http_upgrade, que Nginx définit lorsqu'un en-tête HTTP "Upgrade" est reçu. Si un en-tête de mise à niveau est reçu, Nginx définira la variable $connection_upgrade sur upgrade. Sinon, il le réglera sur close. Ces variables nous permettent de définir les en-têtes corrects lors du proxying des requêtes WebSocket.

Ensuite, trouvez le bloc server avec la directive listen 443 à l'intérieur. Remplacez le contenu du bloc location / par les directives suivantes. Assurez-vous de commenter ou de supprimer toute configuration existante de ce bloc pour éviter les conflits :

/etc/nginx/sites-enabled/default

. . .
server {
    listen 443 ssl;
    . . .
    location / {
        # try_files $uri $uri/ =404;
        proxy_pass http://drone;

        include proxy_params;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_buffering off;
        chunked_transfer_encoding off;
        proxy_read_timeout 86400;
    }
    . . .
}

La ligne proxy_pass indique à Nginx de transmettre tout le trafic servi hors de ce bloc au upstream que nous avons défini précédemment. Ensuite, nous incluons quelques définitions d'en-tête de proxy du fichier proxy_params et ajoutons les en-têtes supplémentaires basés sur notre paramètre map du précédent.

Nous ajustons ensuite d'autres paramètres spécifiques au proxy pour nous assurer que le proxy WebSocket fonctionne correctement et pour nous assurer que nos composants peuvent communiquer efficacement.

Lorsque vous avez terminé, enregistrez et fermez le fichier.

Tester et redémarrer Nginx et Drone

Notre configuration est maintenant terminée. Nous avons juste besoin de démarrer ou de redémarrer nos services pour implémenter la configuration.

Pour commencer, vérifiez la configuration Nginx pour les erreurs de syntaxe :

sudo nginx -t
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si la sortie indique qu'il y a eu un problème de configuration, revenez en arrière et vérifiez à nouveau la configuration Nginx.

Lorsque vous êtes prêt à continuer, redémarrez Nginx :

sudo systemctl restart nginx

Maintenant que Nginx est disponible pour les requêtes proxy entre l'agent et le serveur, nous pouvons démarrer Drone :

sudo systemctl start drone

Vérifiez que le service a pu démarrer avec succès :

sudo systemctl status drone
Output● drone.service - Drone server
   Loaded: loaded (/etc/systemd/system/drone.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-06-09 21:56:33 UTC; 2min 58s ago
 Main PID: 15225 (docker-compose)
    Tasks: 5
   Memory: 37.7M
      CPU: 1.544s
   CGroup: /system.slice/drone.service
           ├─15225 /usr/local/bin/docker-compose -f /etc/drone/docker-compose.yml up
           └─15228 /usr/local/bin/docker-compose -f /etc/drone/docker-compose.yml up

. . .
Jun 09 21:56:35 drone docker-compose[15225]: drone-agent_1   | pipeline: request next execution

Si le service est marqué comme active (running) et qu'aucune erreur n'est présente dans le journal, Drone est opérationnel.

Si vous rencontrez des problèmes, vous pouvez vérifier les journaux Nginx en tapant :

sudo less /var/log/nginx/error.log

Vous pouvez vérifier les journaux du drone en tapant :

sudo journalctl -u drone

Si tout fonctionne correctement, activez Drone pour qu'il démarre au démarrage en tapant :

sudo systemctl enable drone

Le service Drone démarrera une fois les services Docker et Nginx disponibles.

Connectez-vous à Drone pour autoriser l'accès à votre référentiel

Maintenant que Drone est opérationnel, nous pouvons nous connecter à l'interface Web et autoriser l'application à utiliser notre compte GitHub.

Accédez au nom de domaine de votre serveur dans votre navigateur Web pour afficher l'interface Web du drone :

https://example.com

Lors de votre première visite, vous serez invité à vous connecter :

Cliquez sur login pour vous authentifier auprès de Drone avec votre compte GitHub en utilisant OAuth. Si vous n'êtes pas actuellement connecté à GitHub, vous serez d'abord invité à vous connecter à GitHub.

Ensuite, vous serez invité à autoriser Drone à accéder à votre compte GitHub :

Après avoir examiné les autorisations demandées et effectué les ajustements, cliquez sur le bouton Autoriser le nom d'utilisateur pour autoriser Drone.

Vous serez redirigé vers votre serveur Drone :

À partir de là, vous pouvez activer et configurer vos référentiels pour tester automatiquement votre code.

Conclusion

Dans ce guide, nous avons configuré Drone en tant que serveur d'intégration et de livraison continue pour nos projets GitHub. Nous avons configuré le serveur Drone en tant que hub central pour déléguer le travail, gérer l'authentification et écouter les modifications de nos référentiels. Nous avons également configuré un agent Drone qui peut exécuter des tests et gérer des conteneurs. Face à tout cela, nous avons configuré Nginx pour qu'il agisse comme un proxy inverse sécurisé.

Lorsque vous êtes prêt à configurer Drone pour exécuter automatiquement des tests sur vos référentiels, consultez la Drone documentation pour savoir comment définir un fichier .drone.yml avec vos procédures de test.