introduction
Concourse CI est un système d’intégration continue moderne et évolutif, conçu pour automatiser les pipelines de test avec une syntaxe déclarable composable. S’appuyant sur le succès des systèmes CI précédents, Concourse vise à simplifier la gestion des pipelines et à éliminer les serveurs «flocon» afin que le serveur de test soit aussi bien réglementé que le code qu’il traite.
Dans un previous tutorial, nous avons montré comment installer et configurer une instance Concourse CI sur un serveur Ubuntu 16.04. À la fin, il nous restait un serveur d’intégration continue qui pouvait être géré et surveillé à partir de la ligne de commande et d’une interface Web.
Dans ce guide, nous allons sécuriser les interfaces Concourse CI en configurant un proxy inverse TLS / SSL avec Nginx. Alors que Concourse peut être configuré pour utiliser SSL en mode natif, un proxy inverse offre davantage de flexibilité pour la future mise à l’échelle et l’accès à un ensemble de fonctionnalités plus robuste.
Conditions préalables
Avant de commencer, vous aurez besoin d’un serveur Ubuntu 16.04 * avec au moins 1 Go de RAM *. Complétez les guides suivants pour configurer un utilisateur non root, installer et configurer Concourse, installer Nginx et configurer les connexions TLS / SSL sur le serveur. Vous aurez également besoin d’un * nom de domaine * pointé sur votre serveur Concourse pour le sécuriser correctement:
Après avoir suivi ces conditions préalables, vous aurez un serveur Concourse fonctionnant sur le port 8080. De plus, Nginx sera opérationnel sur les ports 80 et 443. Le trafic sur le port 80 sera redirigé sur le port 443, qui chiffrera le trafic des demandes adressées au nom de domaine de votre serveur.
Lorsque vous êtes prêt à commencer, continuez ci-dessous.
Configuration de Nginx en tant que proxy inverse pour Concourse
La première chose à faire est de modifier le fichier de blocage du serveur SSL pour acheminer le trafic vers le serveur Concourse CI.
Trouver le bon fichier à éditer
Puisque nous voulons que notre nom de domaine sécurisé par SSL serve l’interface Concourse, nous devons rechercher le fichier de blocage de serveur qui gère actuellement notre nom de domaine. Puisque nous ne nous intéressons qu’aux blocs de serveur actifs, nous pouvons utiliser + grep + pour effectuer une recherche dans le répertoire + / etc / nginx / sites-enabled +:
grep -R server_name /etc/nginx/sites-enabledVous verrez probablement quelque chose comme ça:
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, le nom de domaine (+ example.com + dans cet exemple) est défini dans le fichier + / etc / nginx / sites-enabled / default +. Vous voudrez éditer le fichier (la première colonne) associé à votre nom de domaine.
Il est possible que vous voyiez aussi 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;Le + nom_serveur _; + généralement dans la sortie ci-dessus est une définition de bloc de serveur qui correspond à toutes les demandes sans correspondance. Si vous ne trouvez pas une définition + nom_serveur + correspondant à votre nom de domaine, vous devez utiliser le fichier qui ressemble à cela à la place.
Définir le bloc serveur de concours
Ouvrez le fichier qui définit votre domaine dans votre éditeur de texte pour commencer:
sudo nano /etc/nginx/sites-enabled/Si vous supprimez les commentaires par souci de brièveté, votre fichier ressemblera probablement à ceci si vous avez suivi correctement les didacticiels de la section relative aux prérequis:
/ etc / nginx / sites-enabled / default
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name ;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl-.conf;
include snippets/ssl-params.conf;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name ;
location / {
try_files $uri $uri/ =404;
}
location ~ /.well-known {
allow all;
}
}Il peut y avoir de légères variations, mais cela devrait être la structure générale du fichier. Nous pouvons l’adapter au proxy à notre serveur Concourse en apportant deux modifications importantes.
Tout d’abord, au tout début du fichier, avant le blocage du serveur +, nous allons créer un bloc + amont` appelé * concourse * qui définit la manière dont notre processus Web Concourse accepte les connexions. Le serveur d’intégration continue accepte les connexions sur le port 8080.
Recherchez ensuite le bloc serveur responsable de la diffusion du contenu SSL en recherchant le bloc portant la chaîne + listen 443 +. Vérifiez à nouveau que les + nom_serveur + définis dans ce bloc correspondent à votre nom de domaine (ou sont définis sur + nom_serveur _; + si vous n’avez trouvé aucun résultat correspondant à votre nom de domaine lors de votre recherche avec + find +).
À l’intérieur de ce bloc de serveur, nous devons ajuster le bloc + emplacement / + afin que Nginx transmette toutes les demandes (qui ne sont pas explicitement définies ailleurs) au serveur Concourse. Pour ce faire, nous allons inclure les paramètres d’un fichier externe, définir quelques paramètres supplémentaires et définir les en-têtes de proxy nécessaires avant de transmettre la requête au + amont + défini précédemment.
Remplacez la directive + try_files + définie dans le bloc + location / + par les lignes de l’exemple suivant. Lorsque vous avez terminé, le fichier terminé devrait ressembler à ceci:
/ etc / nginx / sites-enabled / default
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name ;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl-.conf;
include snippets/ssl-params.conf;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name ;
location / {
}
location ~ /.well-known {
allow all;
}
}Lorsque vous avez terminé, enregistrez et fermez le fichier.
Tester et activer la nouvelle configuration
Avant d’utiliser la nouvelle configuration, laissez Nginx vérifier les erreurs de syntaxe en tapant:
sudo nginx -tOutputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulSi vous voyez des messages d’erreur à la place du message de réussite ci-dessus, revenez en arrière et vérifiez si le fichier que vous avez modifié ne contient pas d’erreurs avant de continuer.
Pour implémenter la nouvelle configuration, redémarrez Nginx:
sudo systemctl restart nginxNginx est maintenant configuré pour transférer les demandes de votre nom de domaine vers le serveur Concourse.
Configuration de Concourse pour se lier à l’interface de bouclage local
Maintenant que Nginx est configuré pour transférer le trafic vers le serveur Concourse, nous devrions limiter les emplacements où Concourse accepte les connexions. À l’heure actuelle, Concourse accepte les connexions au port 8080 sur toutes les interfaces. Les utilisateurs peuvent donc contourner le cryptage SSL en se connectant directement au serveur d’intégration.
Nous pouvons modifier ce comportement en modifiant la configuration Web Concourse. Ouvrez le fichier de configuration du processus + web + créé dans + / etc / concourse / web_environment + dans votre éditeur de texte:
sudo nano /etc/concourse/web_environmentRecherchez le paramètre + CONCOURSE_EXTERNAL_URL + et modifiez-le afin de refléter l’URL que les utilisateurs doivent utiliser pour accéder à l’interface Web Concourse. Cela inclut le protocole, spécifié par + https: // +, suivi de notre nom de domaine.
Ensuite, définissez une nouvelle variable d’environnement appelée + CONCOURSE_BIND_IP + sur + 127.0.0.1 +. Par défaut, Concourse écoute toutes les interfaces, mais ce paramètre indique à Concourse de se lier uniquement à l’interface locale. Les connexions distantes doivent être mandatées via Nginx, qui peut appliquer le protocole SSL:
/ etc / concourse / web_environment
. . .
CONCOURSE_EXTERNAL_URL=://Enregistrez et fermez le fichier lorsque vous avez terminé.
Redémarrez le processus Concourse + web + pour commencer à utiliser les nouveaux paramètres:
sudo systemctl restart concourse-webVérifiez que l’interface Concourse + web + n’écoute que l’interface de bouclage local en tapant:
sudo netstat -plunt | grep 8080Outputtcp 0 0 0.0.0.0:* LISTEN 20932/concourseLa sortie ci-dessus indique que le processus Concourse + web + n’écoute que sur l’interface locale.
Nous pouvons maintenant modifier nos paramètres de pare-feu pour supprimer notre exception pour le port 8080, car toutes les demandes externes seront acheminées via Nginx:
sudo ufw delete allow 8080secondary_label Output]
Rule deleted
Rule deleted (v6)Maintenant, nous pouvons nous connecter à l’interface Web en toute sécurité.
Test de l’interface Web
Dans le navigateur Web de votre choix, visitez le nom de domaine de votre serveur:
https://Vous devriez pouvoir accéder à la page initiale de CI Concourse:
image: https: //assets.digitalocean.com/articles/concourseci_ssl_1604/initial_screen.png [Écran initial Concourse CI]
Si vous regardez dans la barre d’adresse de votre navigateur, il y aura une indication que vous vous connectez au serveur d’intégration via une connexion sécurisée:
image: https: //assets.digitalocean.com/articles/concourseci_ssl_1604/secure_indicator.png [Connexion sécurisée Concourse CI]
Nginx sécurise la connexion avec votre navigateur et transmet la demande à Concourse. Maintenant que nous pouvons nous connecter en toute sécurité, vous pouvez vous connecter en toute sécurité à l’interface Web.
Si vous cliquez sur le lien * login * dans le coin supérieur droit, vous pouvez vous connecter à l’interface Web. Tout d’abord, il vous sera demandé de sélectionner votre équipe. L’équipe * principale *, qui est le groupe administratif, est la seule sélection disponible par défaut:
image: https: //assets.digitalocean.com/articles/concourseci_ssl_1604/select_main_team.png [Équipe principale du concours CI]
Sur la page suivante, il vous sera demandé de saisir vos identifiants.
Après avoir entré les informations d’identification que vous avez configurées dans le fichier + web_environment +, vous serez connecté et ramené à l’interface d’espace réservé par défaut:
image: https: //assets.digitalocean.com/articles/concourseci_ssl_1604/placeholder_interface.png [Équipe principale du concours CI]
Une fois que vous avez soumis votre configuration de pipeline au serveur avec + fly +, cet écran sera remplacé par une interface permettant de surveiller l’activité de votre pipeline.
Conclusion
Dans ce guide, nous avons configuré Nginx en tant que proxy inverse sécurisé pour un serveur Concourse CI. Nginx accepte les connexions sécurisées des clients et transmet les demandes au serveur Concourse. Concourse se lie à l’interface de bouclage local afin que les clients distants ne puissent pas se connecter directement.
Maintenant que vous pouvez contacter le serveur Concourse en toute sécurité, vous pouvez commencer à créer et à gérer des pipelines à l’aide de l’outil `+ fly + 'et de l’interface Web. Vous pouvez suivre notre prochain guide pour apprendre https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-pipelines-with-concourse-ci-on-ubuntu-16-04 [ comment développer et mettre en œuvre des pipelines d’intégration continue] pour configurer des processus de test automatiques pour votre projet. Vous pouvez également consulter le hthello world ”dans la documentation de Concourse.