Salut!
Je m'appelle Sergey, je travaille comme ingénieur d'infrastructure dans l'équipe API de la plateforme tinkoff.ru.
Dans cet article, je parlerai des problèmes auxquels notre équipe a été confrontée lors de la préparation des équilibreurs basés sur pour divers projets. Je vous parlerai également de l’outil qui m’a permis de surmonter la plupart d’entre eux.
Nginx est un serveur proxy multifonctionnel et en développement actif. Il comporte un grand nombre de modules, . Chaque projet impose certaines exigences sur les fonctionnalités de l'équilibreur et la version de Nginx (par exemple, la présence de proxy http/2 et grpc), ainsi que sur la composition de ses modules.
Nous aimerions voir une nouvelle version avec l'ensemble de modules requis, fonctionnant sous une distribution Linux spécifique. Dans notre cas, il s'agit de systèmes basés sur Deb et RPM. L'option avec conteneurs n'est pas prise en compte dans cet article.
Nous souhaitons modifier rapidement les fonctionnalités de nos équilibreurs. Et là, la question se pose immédiatement : comment y parvenir en dépensant le moins de ressources possible ? Il serait encore mieux de configurer le processus de manière à pouvoir spécifier un nombre fini de paramètres d'entrée et, en sortie, recevoir un artefact sous la forme d'un package deb/rpm pour le système d'exploitation souhaité.
De ce fait, plusieurs problèmes peuvent être formulés :
- Il n’existe pas toujours de packages avec la dernière version de Nginx.
- Il n'existe aucun package avec les modules requis.
- Compiler et construire un package manuellement prend du temps et est carrément fastidieux.
- Il n'y a aucune description de la façon dont telle ou telle instance Nginx est assemblée.
Pour résoudre ces problèmes, il est nécessaire de disposer d'un outil qui prendrait en entrée une spécification dans un format lisible par l'homme et assemblerait un package Nginx avec les fonctionnalités nécessaires basées sur celle-ci.
Ne trouvant pas d'option appropriée pour nous sur l'immensité de Github, nous avons décidé de créer notre propre outil - .
spécification
Dans notre outil, nous souhaitions créer une description de la spécification sous forme de code, qui pourra ensuite être mise dans un dépôt Git. Pour ce faire, nous avons choisi le format familier pour de telles choses - yaml. Exemple de spécification :
nginx_version: 1.14.1
output_package: deb
modules:
- module:
name: nginx-auth-ldap
git_url: https://github.com/kvspb/nginx-auth-ldap.git
git_branch: master
dependencies:
- libldap2-dev
- module:
name: ngx_http_substitutions_filter_module
git_url: https://github.com/yaoweibin/ngx_http_substitutions_filter_module.git
- module:
name: headers-more-nginx-module
web_url: https://github.com/openresty/headers-more-nginx-module/archive/v0.261.zip
- module:
name: nginx-module-vts
git_url: https://github.com/vozlt/nginx-module-vts.git
git_tag: v0.1.18
- module:
name: ngx_devel_kit
git_url: https://github.com/simplresty/ngx_devel_kit.git
git_tag: v0.3.0
- module:
name: ngx_cache_purge
git_url: https://github.com/FRiCKLE/ngx_cache_purge.git
- module:
name: ngx_http_dyups_module
git_url: https://github.com/yzprofile/ngx_http_dyups_module.git
- module:
name: nginx-brotli
git_url: https://github.com/eustas/ngx_brotli.git
git_tag: v0.1.2
- module:
name: nginx_upstream_check_module
git_url: https://github.com/yaoweibin/nginx_upstream_check_module.git
- module:
name: njs
git_url: https://github.com/nginx/njs.git
git_tag: 0.2.5
config_folder_path: nginx
Nous indiquons ici que nous souhaitons voir un package deb avec Nginx version 1.14.2 avec l'ensemble de modules requis. La section avec les modules est facultative. Pour chacun d'eux, vous pouvez définir :
- Titre.
- Adresse où l'obtenir :
- Dépôt Git. Vous pouvez également spécifier une branche ou une balise.
- Lien Web d'archive.
- Lien local vers les archives.
Certains modules nécessitent l'installation de dépendances supplémentaires, par exemple nginx-auth-ldap nécessite l'installation de libldap2-dev. Les dépendances nécessaires peuvent également être spécifiées lors de la description du module.
Environs
Dans notre outil, vous pouvez rapidement obtenir un environnement avec des utilitaires installés pour la compilation, l'assemblage de packages et d'autres logiciels auxiliaires. Un conteneur Docker avec tout ce dont vous avez besoin est idéal ici (le référentiel contient déjà quelques exemples de fichiers Docker pour Ubuntu et Centos).
Une fois le cahier des charges rédigé et l'environnement préparé, nous lançons notre builder, après avoir préalablement installé ses dépendances :
pip3 install -r requirements.txt
./main.py build -f [конфиг_файл].yaml -r [номер_ревизии]
Le numéro de révision ici est facultatif et est utilisé pour la gestion des versions des assemblys. Il est écrit dans les méta-informations du package, ce qui facilite la mise à jour sur les serveurs.
À partir des journaux, vous pouvez surveiller ce qui se passe. Voici un exemple des points principaux :
builder - INFO - Parse yaml file: example.config.yaml
builder - INFO - Download scripts for build deb package
builder - INFO - Downloading nginx src...
builder - INFO - --> http://nginx.org/download/nginx-1.14.1.tar.gz
builder - INFO - Downloading 3d-party modules...
builder - INFO - Module nginx-auth-ldap will download by branch
builder - INFO - -- Done: nginx-auth-ldap
builder - INFO - -- Done: ngx_http_substitutions_filter_module
builder - INFO - Module headers-more-nginx-module will downloading
builder - INFO - Module nginx-module-vts will download by tag
builder - INFO - -- Done: nginx-module-vts
builder - INFO - Module ngx_devel_kit will download by tag
builder - INFO - -- Done: ngx_devel_kit
builder - INFO - -- Done: ngx_cache_purge
builder - INFO - -- Done: ngx_http_dyups_module
builder - INFO - Downloading dependencies
builder - INFO - Building .deb package
builder - INFO - Running 'dh_make'...
builder - INFO - Running 'dpkg-buildpackage'...
dpkg-deb: building package 'nginx' in '../nginx_1.14.1-1_amd64.deb'.
Ainsi, avec seulement quelques commandes, nous créons l'environnement et l'assembly Nginx requis, et le package apparaît dans le répertoire à partir duquel le script est lancé.
Intégration
Nous pouvons également intégrer notre outil dans les processus CI/CD. N'importe lequel des nombreux systèmes CI existants aujourd'hui peut y contribuer, par exemple ou .
En conséquence, chaque fois que la spécification change dans le référentiel Git, la construction de l'artefact est automatiquement lancée. Le numéro de révision est lié au compteur de lancement de build.
Avec un peu plus de temps, vous pouvez configurer l'artefact à envoyer à votre référentiel de packages local, Nexus, Artifactory, etc.
Un avantage supplémentaire est que le fichier de configuration yaml peut être connecté à Ansible ou à un autre système de configuration automatique, et à partir de là, nous pouvons prendre le numéro de version et le type de package que nous souhaitons déployer.
Quelle est la prochaine
Le projet n'est pas encore terminé. Voici ce sur quoi nous travaillons actuellement :
- Nous élargissons les possibilités de configuration, tout en la gardant aussi simple que possible. Vous ne voulez pas définir mille paramètres si vous n’en avez besoin que de deux et que le reste s’adapte par défaut. Cela inclut les indicateurs de compilation (vous pouvez désormais les modifier dans le fichier de configuration interne src/config.py), le chemin d'installation et l'utilisateur de lancement.
- Nous ajoutons des options pour envoyer automatiquement un package à divers référentiels d'artefacts.
- Exécutez une commande personnalisée lors du chargement d'un module (par exemple, pour utiliser vous devez d'abord appliquer un patch d'une version spécifique)
- Ajout de tests :
- Le package est installé correctement.
- Nginx a la version requise et est construit avec les indicateurs et modules requis.
- Les chemins, comptes, etc. nécessaires sont créés.
Mais vous pouvez utiliser cet outil dès maintenant et également suggérer des améliorations : bienvenue !
Source: habr.com