Събираме своя Nginx с няколко команди

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

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

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

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

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

В крайна сметка можем да формулираме редица проблеми:

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

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

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

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

В нашия инструмент искахме да създадем описание на спецификацията под формата на код, който след това може да бъде поставен в 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 [номер_ревизии]

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

строител - ИНФО - Парсиране на yaml файл: example.config.yaml
строител - ИНФО - Сваляне на скриптове за изграждане на deb пакет
строител - ИНФО - Сваляне на nginx src...
строител - ИНФО - --> http://nginx.org/download/nginx-1.14.1.tar.gz
строител - ИНФО - Сваляне на 3d-party модули...
строител - ИНФО - Модулът nginx-auth-ldap ще бъде свален по клон
строител - ИНФО - -- Готово: nginx-auth-ldap
строител - ИНФО - -- Готово: ngx_http_substitutions_filter_module
строител - ИНФО - Модулът headers-more-nginx-module ще бъде свален
строител - ИНФО - Модулът nginx-module-vts ще бъде свален по таг
строител - ИНФО - -- Готово: nginx-module-vts
строител - ИНФО - Модулът ngx_devel_kit ще бъде свален по таг
строител - ИНФО - -- Готово: ngx_devel_kit
строител - ИНФО - -- Готово: ngx_cache_purge
строител - ИНФО - -- Готово: ngx_http_dyups_module
строител - ИНФО - Сваляне на зависимости
строител - ИНФО - Изграждане на .deb пакет
строител - ИНФО - Изпълнение на 'dh_make'...
строител - ИНФО - Изпълнение на 'dpkg-buildpackage'...
dpkg-deb: изграждане на пакет 'nginx' в '..\/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 добре дошли!

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