Vi samler vores Nginx med et par kommandoer

Hi!
Mit navn er Sergey, jeg arbejder som infrastrukturingeniør i API-teamet på tinkoff.ru-platformen.

I denne artikel vil jeg tale om de problemer, som vores team stod over for, da de forberedte balancere baseret på Nginx til forskellige projekter. Jeg vil også fortælle dig om det værktøj, der gjorde det muligt for mig at overvinde de fleste af dem.

Nginx er en multifunktionel og aktivt udviklende proxyserver. Den har et stort antal moduler, dette er ikke en komplet liste. Hvert projekt stiller visse krav til funktionaliteten af ​​balanceren og versionen af ​​Nginx (for eksempel tilstedeværelsen af ​​http/2 og grpc proxying) og sammensætningen af ​​dens moduler.

Vi vil gerne se en frisk version med det nødvendige sæt moduler, der kører under en specifik Linux-distribution. I vores tilfælde er der tale om deb- og rpm-baserede systemer. Muligheden med containere er ikke taget i betragtning i denne artikel.

Vi ønsker hurtigt at ændre funktionaliteten af ​​vores balancere. Og her melder spørgsmålet sig straks: hvordan opnår man dette, mens man bruger så få ressourcer som muligt? Det ville være endnu bedre at sætte processen op, så vi kan specificere et endeligt antal inputparametre, og ved udgangen modtage en artefakt i form af en deb/rpm-pakke til det ønskede OS.

Som følge heraf kan en række problemer formuleres:

  • Der er ikke altid pakker med den nyeste version af Nginx.
  • Der er ingen pakker med de nødvendige moduler.
  • At kompilere og bygge en pakke manuelt er tidskrævende og direkte kedeligt.
  • Der er ingen beskrivelse af, hvordan denne eller hin Nginx-instans er samlet.

For at løse disse problemer opstår behovet for et værktøj, der vil tage som input en specifikation i et menneskeligt læsbart format og samle en Nginx-pakke med den nødvendige funktionalitet baseret på den.

Da vi ikke fandt en passende mulighed for os på Githubs vidde, besluttede vi at skabe vores eget værktøj - nginx-builder.

specifikation

I vores værktøj ønskede vi at lave en beskrivelse af specifikationen i form af kode, som derefter kan lægges ind i et Git repository. For at gøre dette valgte vi det velkendte format for sådanne ting - yaml. Specifikationseksempel:

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

Her angiver vi, at vi ønsker at se en deb-pakke med Nginx version 1.14.2 med det nødvendige sæt moduler. Sektionen med moduler er valgfri. For hver af dem kan du indstille:

  • Navn.
  • Adresse hvor du kan få det:
    • Git repository. Du kan også angive en gren eller tag.
    • Weblink til arkiv.
    • Lokalt link til arkivet.

Nogle moduler kræver yderligere afhængigheder for at blive installeret, for eksempel nginx-auth-ldap kræver libldap2-dev installeret. Nødvendige afhængigheder kan også angives ved beskrivelse af modulet.

Miljø

I vores værktøj kan du hurtigt få et miljø med installerede hjælpeprogrammer til kompilering, pakkesamling og anden hjælpesoftware. En Docker-container med alt hvad du har brug for er ideel her (depotet har allerede et par eksempler på Docker-filer til ubuntu og centos).

Efter at specifikationen er udarbejdet og miljøet er forberedt, lancerer vi vores builder, efter at have installeret dens afhængigheder tidligere:

pip3 install -r requirements.txt
./main.py build -f [конфиг_файл].yaml -r [номер_ревизии]

Revisionsnummeret her er valgfrit og bruges til versionering af samlinger. Det er skrevet ind i pakkens metainformation, hvilket gør det nemt at opdatere på servere.
Fra loggene kan du overvåge, hvad der sker. Her er et eksempel på hovedpunkterne:

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'.

Så med blot et par kommandoer opretter vi miljøet og den nødvendige Nginx-samling, og pakken vises i den mappe, hvorfra scriptet er lanceret.

Indlejring

Vi kan også integrere vores værktøj i CI/CD processer. Ethvert af de mange CI-systemer, der findes i dag, kan f.eks. hjælpe med dette Teamcity eller Gitlab CI.

Som et resultat, hver gang specifikationen ændres i Git-lageret, startes opbygningen af ​​artefakten automatisk. Revisionsnummeret er knyttet til build-lanceringstælleren.
Med lidt mere tid kan du konfigurere artefakten til at blive sendt til dit lokale pakkelager, Nexus, Artifactory og så videre.

En yderligere fordel er, at yaml-konfigurationsfilen kan forbindes til Ansible eller et andet automatisk konfigurationssystem, og derfra kan vi tage det versionsnummer og pakketype, som vi ønsker at implementere.

Hvad er næste

Projektet er endnu ikke afsluttet. Her er hvad vi arbejder på nu:

  • Vi udvider muligheden for konfiguration, men holder det samtidig så enkelt som muligt. Du ønsker ikke at definere tusind parametre, hvis du kun har brug for to, og resten passer som standard. Dette inkluderer kompileringsflag (nu kan du ændre dem i den interne konfigurationsfil src/config.py), installationssti og startbruger.
  • Vi tilføjer muligheder for automatisk at sende en pakke til forskellige artefaktlager.
  • Udfør en brugerdefineret kommando, når du indlæser et modul (for eksempel for at bruge github.com/nginx-modules/nginx_upstream_check_module du skal først anvende en patch af en bestemt version)
  • Tilføjelse af tests:
    • Pakken er installeret korrekt.
    • Nginx har den påkrævede version og er bygget med de nødvendige flag og moduler.
    • De nødvendige stier, konti og så videre oprettes.

Men du kan bruge dette værktøj nu og også foreslå forbedringer - github.com/TinkoffCreditSystems/Nginx-builder velkommen!

Kilde: www.habr.com

Tilføj en kommentar