Hey there!
Mijn naam is Sergey, ik werk als infrastructuuringenieur in het API-team van het tinkoff.ru-platform.
In dit artikel zal ik het hebben over de problemen waarmee ons team werd geconfronteerd bij het voorbereiden van balancers op basis van voor diverse projecten. Ik zal je ook vertellen over de tool waarmee ik de meeste van deze problemen kon overwinnen.
Nginx is een multifunctionele en actief ontwikkelende proxyserver. Het beschikt over een groot aantal modules, . Elk project stelt bepaalde eisen aan de functionaliteit van de balancer en de versie van Nginx (bijvoorbeeld de aanwezigheid van http/2 en grpc proxying) en de samenstelling van de modules.
We zouden graag een nieuwe versie zien met de vereiste set modules, draaiend onder een specifieke Linux-distributie. In ons geval zijn dit deb- en rpm-gebaseerde systemen. De optie met containers wordt in dit artikel niet behandeld.
Wij willen de functionaliteit van onze balancers snel veranderen. En hier rijst meteen de vraag: hoe bereik je dit met zo min mogelijk middelen? Het zou nog beter zijn om het proces zo in te richten dat we een eindig aantal invoerparameters kunnen specificeren, en aan de uitvoer een artefact kunnen ontvangen in de vorm van een deb/rpm-pakket voor het gewenste besturingssysteem.
Als gevolg hiervan kunnen een aantal problemen worden geformuleerd:
- Er zijn niet altijd pakketten met de nieuwste versie van Nginx.
- Er zijn geen pakketten met de benodigde modules.
- Het handmatig compileren en bouwen van een pakket is tijdrovend en ronduit vervelend.
- Er is geen beschrijving van hoe deze of gene Nginx-instantie wordt samengesteld.
Om deze problemen op te lossen ontstaat er behoefte aan een tool die als invoer een specificatie in een voor mensen leesbaar formaat neemt en op basis daarvan een Nginx-pakket samenstelt met de nodige functionaliteit.
Omdat we geen geschikte optie voor ons konden vinden in de uitgestrektheid van Github, hebben we besloten onze eigen tool te maken - .
Specificaties
In onze tool wilden we een beschrijving van de specificatie maken in de vorm van code, die vervolgens in een Git-repository kan worden geplaatst. Om dit te doen, hebben we het bekende formaat voor dergelijke dingen gekozen: yaml. Specificatie voorbeeld:
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
Hier geven we aan dat we een deb-pakket willen zien met Nginx versie 1.14.2 met de benodigde set modules. Het gedeelte met modules is optioneel. Voor elk van hen kunt u het volgende instellen:
- Naam.
- Adres waar u het kunt verkrijgen:
- Git-opslagplaats. U kunt ook een tak of tag opgeven.
- Weblink archiveren.
- Lokale link naar het archief.
Voor sommige modules moeten extra afhankelijkheden worden geïnstalleerd. Voor nginx-auth-ldap is bijvoorbeeld de installatie van libldap2-dev vereist. Noodzakelijke afhankelijkheden kunnen ook worden gespecificeerd bij het beschrijven van de module.
omgeving
In onze tool kunt u snel een omgeving krijgen met geïnstalleerde hulpprogramma's voor compilatie, pakketassemblage en andere hulpsoftware. Een Docker-container met alles wat je nodig hebt is hier ideaal (de repository bevat al een paar voorbeelden van Docker-bestanden voor ubuntu en centos).
Nadat de specificatie is opgesteld en de omgeving is voorbereid, lanceren we onze builder, nadat we eerder de afhankelijkheden ervan hebben geïnstalleerd:
pip3 install -r requirements.txt
./main.py build -f [конфиг_файл].yaml -r [номер_ревизии]
Het revisienummer is hier optioneel en wordt gebruikt voor versiebeheer. Het wordt in de meta-informatie van het pakket geschreven, waardoor het gemakkelijk is om op servers bij te werken.
Vanuit de logboeken kunt u volgen wat er gebeurt. Hier is een voorbeeld van de belangrijkste punten:
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'.
Dus met slechts een paar opdrachten creëren we de omgeving en de vereiste Nginx-assembly, en het pakket verschijnt in de map van waaruit het script wordt gestart.
Inbedden
We kunnen onze tool ook integreren in CI/CD-processen. Elk van de vele CI-systemen die tegenwoordig bestaan, kan hierbij bijvoorbeeld helpen of .
Als gevolg hiervan wordt elke keer dat de specificatie in de Git-repository verandert, de build van het artefact automatisch gestart. Het revisienummer is gekoppeld aan de build-lanceringsteller.
Met wat meer tijd kunt u configureren dat het artefact naar uw lokale pakketrepository, Nexus, Artifactory, enzovoort wordt verzonden.
Bijkomend voordeel is dat het yaml-configuratiebestand kan worden gekoppeld aan Ansible of een ander automatisch configuratiesysteem, en van daaruit kunnen we het versienummer en pakkettype nemen dat we willen inzetten.
What's Next
Het project is nog niet voltooid. Dit is waar we nu aan werken:
- We breiden de configuratiemogelijkheden uit, maar houden het tegelijkertijd zo eenvoudig mogelijk. Je wilt geen duizend parameters definiëren als je er maar twee nodig hebt, en de rest past standaard. Dit omvat compilatievlaggen (nu kunt u deze wijzigen in het interne configuratiebestand src/config.py), het installatiepad en de startgebruiker.
- We voegen opties toe voor het automatisch verzenden van een pakket naar verschillende opslagplaatsen voor artefacten.
- Voer een aangepaste opdracht uit bij het laden van een module (bijvoorbeeld om te gebruiken u moet eerst een patch van een specifieke versie toepassen)
- Testen toevoegen:
- Het pakket is correct geïnstalleerd.
- Nginx heeft de vereiste versie en is gebouwd met de vereiste vlaggen en modules.
- De benodigde paden, accounts, enzovoort worden aangemaakt.
Maar u kunt deze tool nu gebruiken en ook verbeteringen voorstellen - welkom!
Bron: www.habr.com