Сглобяваме нашия Nginx с няколко команди

Привет!
Казвам се Сергей, работя като инфраструктурен инженер в API екипа на платформата tinkoff.ru.

В тази статия ще говоря за проблемите, с които се сблъска нашият екип при изготвянето на базирани на балансьори Nginx за различни проекти. Ще ви разкажа и за инструмента, който ми позволи да преодолея повечето от тях.

Nginx е многофункционален и активно развиващ се прокси сървър. Разполага с голям брой модули, това не е пълен списък. Всеки проект налага определени изисквания към функционалността на балансира и версията на Nginx (например наличието на http/2 и grpc proxying), както и състава на неговите модули.

Бихме искали да видим нова версия с необходимия набор от модули, работеща под конкретна Linux дистрибуция. В нашия случай това са системи, базирани на deb и rpm. Опцията с контейнери не се разглежда в тази статия.

Искаме бързо да променим функционалността на нашите балансьори. И тук веднага възниква въпросът: как да се постигне това, като се харчат възможно най-малко ресурси? Още по-добре би било да настроим процеса така, че да можем да зададем краен брой входни параметри и на изхода да получим артефакт под формата на deb/rpm пакет за желаната ОС.

В резултат на това могат да бъдат формулирани редица проблеми:

• Не винаги има пакети с най-новата версия на Nginx.
• Няма пакети с необходимите модули.
• Ръчното компилиране и изграждане на пакет отнема време и е направо досадно.
• Няма описание как се сглобява това или онова копие на Nginx.

За да се решат тези проблеми, възниква необходимостта от инструмент, който да приема като вход спецификация в четим от човека формат и да сглобява Nginx пакет с необходимата функционалност въз основа на нея.

Не намирайки подходящ вариант за нас в необятността на Github, решихме да създадем наш собствен инструмент - nginx-строител.

Спецификации

В нашия инструмент искахме да създадем описание на спецификацията под формата на код, който след това може да бъде поставен в Git хранилище. За да направим това, избрахме формата, познат за такива неща - yaml. Пример за спецификация:

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

Тук показваме, че искаме да видим deb пакет с Nginx версия 1.14.2 с необходимия набор от модули. Секцията с модули не е задължителна. За всеки от тях можете да зададете:

• Име.
• Адрес, на който можете да го получите:
  • Git хранилище. Можете също да посочите клон или етикет.
  • Архивна уеб връзка.
  • Локален линк към архива.

Някои модули изискват инсталиране на допълнителни зависимости, например nginx-auth-ldap изисква инсталиран libldap2-dev. Необходимите зависимости също могат да бъдат посочени при описанието на модула.

Околната среда

В нашия инструмент можете бързо да получите среда с инсталирани помощни програми за компилиране, сглобяване на пакети и друг спомагателен софтуер. Docker контейнер с всичко, от което се нуждаете, е идеален тук (в хранилището вече има няколко примера на Docker файлове за ubuntu и centos).

След като спецификацията е съставена и средата е подготвена, ние стартираме нашия строител, като предварително сме инсталирали неговите зависимости:

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

Номерът на ревизията тук не е задължителен и се използва за сглобки за версии. Той е записан в мета информацията на пакета, което го прави лесен за актуализиране на сървъри.
От дневниците можете да следите какво се случва. Ето пример за основните точки:

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

И така, само с няколко команди създаваме средата и необходимия сбор на Nginx и пакетът се появява в директорията, от която се стартира скриптът.

Вграждане

Можем също да интегрираме нашия инструмент в CI/CD процеси. Всяка от многото съществуващи днес CI системи може да помогне с това, например Teamcity или Gitlab CI.

В резултат на това всеки път, когато спецификацията се промени в хранилището на Git, изграждането на артефакта се стартира автоматично. Номерът на ревизията е свързан с брояча за стартиране на компилация.
С малко повече време можете да конфигурирате артефакта да бъде изпратен до вашето локално хранилище на пакети, Nexus, Artifactory и т.н.

Допълнително предимство е, че конфигурационният файл на yaml може да бъде свързан към Ansible или друга система за автоматично конфигуриране и оттам можем да вземем номера на версията и типа на пакета, който искаме да внедрим.

Какво следва?

Проектът все още не е завършен. Ето върху какво работим в момента:

• Ние разширяваме възможността за конфигурация, но в същото време я поддържаме възможно най-проста. Не искате да дефинирате хиляда параметъра, ако имате нужда само от два, а останалите пасват по подразбиране. Това включва флагове за компилация (сега можете да ги промените във вътрешния конфигурационен файл src/config.py), инсталационен път и стартиращ потребител.
• Добавяме опции за автоматично изпращане на пакет до различни хранилища на артефакти.
• Изпълнете персонализирана команда при зареждане на модул (например за използване github.com/nginx-modules/nginx_upstream_check_module първо трябва да приложите корекция на определена версия)
• Добавяне на тестове:
  • Пакетът е инсталиран правилно.
  • Nginx има необходимата версия и е изграден с необходимите флагове и модули.
  • Създават се необходимите пътища, акаунти и т.н.

Но можете да използвате този инструмент сега и също да предложите подобрения - github.com/TinkoffCreditSystems/Nginx-builder добре дошли!

Източник: www.habr.com