ProHoster > Dienoraštis > Administravimas > Surenkame savo Nginx su keliomis komandomis

Surenkame savo Nginx su keliomis komandomis

Sveiki!
Mano vardas Sergejus, dirbu tinkoff.ru platformos API komandoje infrastruktūros inžinieriumi.

Šiame straipsnyje papasakosiu apie problemas, su kuriomis susidūrė mūsų komanda ruošdama balansuotojus nginx įvairiems projektams. Taip pat papasakosiu apie įrankį, kuris leido man įveikti daugumą jų.

„Nginx“ yra daugiafunkcis ir aktyviai besivystantis tarpinis serveris. Jame yra daug modulių, tai nėra visas sąrašas. Kiekvienas projektas kelia tam tikrus reikalavimus balanso funkcijoms ir „Nginx“ versijai (pavyzdžiui, http/2 ir grpc tarpinio serverio buvimui) ir jo modulių sudėčiai.

Norėtume pamatyti naują versiją su reikiamu modulių rinkiniu, veikiančią pagal konkretų Linux platinimą. Mūsų atveju tai yra deb ir rpm pagrįstos sistemos. Pasirinkimas su konteineriais šiame straipsnyje neaptariamas.

Norime greitai pakeisti savo balansierių funkcionalumą. Ir čia iš karto kyla klausimas: kaip tai pasiekti išleidžiant kuo mažiau išteklių? Dar geriau būtų nustatyti procesą taip, kad galėtume nurodyti baigtinį skaičių įvesties parametrų, o išvestyje gauti artefaktą deb/rpm paketo pavidalu norimai OS.

Dėl to galima suformuluoti daugybę problemų:

  • Ne visada yra paketų su naujausia Nginx versija.
  • Nėra jokių paketų su reikalingais moduliais.
  • Paketo sudarymas ir kūrimas rankiniu būdu užima daug laiko ir be galo nuobodu.
  • Nėra aprašymo, kaip surenkamas tas ar kitas Nginx egzempliorius.

Norint išspręsti šias problemas, reikia įrankio, kuris įvestų specifikaciją žmogui suprantamu formatu ir pagal ją surinktų Nginx paketą su reikiamomis funkcijomis.

Github platybėse neradę mums tinkamo varianto, nusprendėme sukurti savo įrankį - nginx-builder.

Specifikacija

Savo įrankyje norėjome sukurti specifikacijos aprašymą kodo pavidalu, kurį vėliau būtų galima įdėti į Git saugyklą. Norėdami tai padaryti, pasirinkome tokiems dalykams pažįstamą formatą - yaml. Specifikacijos pavyzdys:

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

Čia nurodome, kad norime matyti deb paketą su Nginx 1.14.2 versija su reikiamu modulių rinkiniu. Skyrius su moduliais yra neprivalomas. Kiekvienam iš jų galite nustatyti:

  • Vardas.
  • Adresas, kur galite gauti:
    • Git saugykla. Taip pat galite nurodyti šaką arba žymą.
    • Archyvuoti žiniatinklio nuorodą.
    • Vietinė nuoroda į archyvą.

Kai kuriems moduliams reikia įdiegti papildomų priklausomybių, pavyzdžiui, nginx-auth-ldap reikalauja įdiegti libldap2-dev. Aprašant modulį galima nurodyti ir būtinas priklausomybes.

Apylinkės

Mūsų įrankyje galite greitai gauti aplinką su įdiegtomis kompiliavimo, paketų surinkimo ir kitos pagalbinės programinės įrangos programomis. Čia idealiai tinka Docker konteineris su viskuo, ko reikia (saugykloje jau yra keletas Docker failų pavyzdžių, skirtų ubuntu ir centos).

Sudarę specifikaciją ir paruošę aplinką, paleidžiame savo statybininką, prieš tai įdiegę jo priklausomybes:

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

Taisymo numeris čia yra neprivalomas ir naudojamas versijų rinkiniams kurti. Jis įrašytas į paketo metainformaciją, todėl jį lengva atnaujinti serveriuose.
Iš žurnalų galite stebėti, kas vyksta. Čia yra pagrindinių dalykų pavyzdys:

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

Taigi, vos keliomis komandomis sukuriame aplinką ir reikiamą Nginx komplektaciją, o paketas atsiranda kataloge, iš kurio paleidžiamas scenarijus.

Įterpimas

Taip pat galime integruoti savo įrankį į CI/CD procesus. Pavyzdžiui, bet kuri iš daugelio šiandien egzistuojančių CI sistemų gali padėti Teamcity arba Gitlab CI.

Todėl kiekvieną kartą, kai Git saugykloje pasikeičia specifikacijos, artefakto kūrimas automatiškai paleidžiamas. Pataisos numeris susietas su versijos paleidimo skaitikliu.
Turėdami šiek tiek daugiau laiko, galite sukonfigūruoti artefaktą, kuris būtų siunčiamas į vietinę paketų saugyklą, „Nexus“, „Artifactory“ ir pan.

Papildomas privalumas yra tai, kad yaml konfigūracijos failą galima prijungti prie Ansible ar kitos automatinės konfigūracijos sistemos, o iš ten galime paimti norimą diegti versijos numerį ir paketo tipą.

Kas toliau?

Projektas dar nebaigtas. Štai prie ko dabar dirbame:

  • Išplečiame konfigūravimo galimybę, bet kartu paliekame ją kuo paprastesnę. Nenorite apibrėžti tūkstančio parametrų, jei jums reikia tik dviejų, o likusieji tinka pagal numatytuosius nustatymus. Tai apima kompiliavimo vėliavėles (dabar jas galite pakeisti vidiniame konfigūracijos faile src/config.py), diegimo kelią ir paleisti vartotoją.
  • Pridedame automatinio paketo siuntimo į įvairias artefaktų saugyklas parinktis.
  • Vykdykite pasirinktinę komandą įkeldami modulį (pavyzdžiui, norėdami naudoti github.com/nginx-modules/nginx_upstream_check_module pirmiausia turite pritaikyti konkrečios versijos pataisą)
  • Testų pridėjimas:
    • Paketas įdiegtas teisingai.
    • „Nginx“ turi reikiamą versiją ir yra sukurta su reikiamomis vėliavėlėmis ir moduliais.
    • Sukuriami reikalingi keliai, paskyros ir pan.

Bet dabar galite naudoti šį įrankį ir pasiūlyti patobulinimų - github.com/TinkoffCreditSystems/Nginx-builder Sveiki atvykę!

Šaltinis: www.habr.com

Добавить комментарий