Hallo!
Mein Name ist Sergey, ich arbeite als Infrastrukturingenieur im API-Team der Plattform tinkoff.ru.
In diesem Artikel werde ich über die Probleme sprechen, mit denen unser Team bei der Vorbereitung von Balancern konfrontiert war für verschiedene Projekte. Ich erzähle Ihnen auch von dem Tool, mit dem ich die meisten davon überwinden konnte.
Nginx ist ein multifunktionaler und sich aktiv entwickelnder Proxyserver. Es verfügt über eine große Anzahl von Modulen, . Jedes Projekt stellt bestimmte Anforderungen an die Funktionalität des Balancers und der Nginx-Version (z. B. das Vorhandensein von http/2 und grpc-Proxying) sowie an die Zusammensetzung seiner Module.
Wir würden gerne eine neue Version mit den erforderlichen Modulen sehen, die unter einer bestimmten Linux-Distribution läuft. In unserem Fall handelt es sich um deb- und rpm-basierte Systeme. Die Option mit Containern wird in diesem Artikel nicht berücksichtigt.
Wir möchten die Funktionalität unserer Balancer schnell ändern. Und hier stellt sich sofort die Frage: Wie kann dies mit möglichst geringem Ressourcenaufwand erreicht werden? Noch besser wäre es, den Prozess so einzurichten, dass wir eine endliche Anzahl von Eingabeparametern angeben können und am Ausgang ein Artefakt in Form eines Deb/RPM-Pakets für das gewünschte Betriebssystem erhalten.
Daraus lässt sich eine Reihe von Problemen formulieren:
- Es gibt nicht immer Pakete mit der neuesten Version von Nginx.
- Es sind keine Pakete mit den erforderlichen Modulen vorhanden.
- Das manuelle Kompilieren und Erstellen eines Pakets ist zeitaufwändig und geradezu mühsam.
- Es gibt keine Beschreibung, wie diese oder jene Nginx-Instanz zusammengestellt wird.
Um diese Probleme zu lösen, besteht Bedarf an einem Tool, das eine Spezifikation in einem für Menschen lesbaren Format als Eingabe verwendet und darauf basierend ein Nginx-Paket mit der erforderlichen Funktionalität zusammenstellt.
Da wir auf der riesigen Github-Seite keine passende Option für uns fanden, beschlossen wir, unser eigenes Tool zu entwickeln – .
Technische Daten
In unserem Tool wollten wir eine Beschreibung der Spezifikation in Form von Code erstellen, der dann in ein Git-Repository gestellt werden kann. Dazu haben wir das für solche Dinge bekannte Format gewählt – yaml. Spezifikationsbeispiel:
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 geben wir an, dass wir ein Deb-Paket mit Nginx-Version 1.14.2 mit dem erforderlichen Modulsatz sehen möchten. Der Abschnitt mit Modulen ist optional. Für jeden von ihnen können Sie Folgendes festlegen:
- Titel.
- Adresse, wo Sie es bekommen können:
- Git-Repository. Sie können auch einen Zweig oder ein Tag angeben.
- Weblink zum Archiv.
- Lokaler Link zum Archiv.
Für einige Module müssen zusätzliche Abhängigkeiten installiert werden, beispielsweise erfordert nginx-auth-ldap die Installation von libldap2-dev. Bei der Beschreibung des Moduls können auch notwendige Abhängigkeiten angegeben werden.
Umgebung
Mit unserem Tool erhalten Sie schnell eine Umgebung mit installierten Dienstprogrammen für die Kompilierung, Paketassemblierung und andere Hilfssoftware. Ideal ist hier ein Docker-Container mit allem, was Sie brauchen (das Repository enthält bereits einige Beispiele für Docker-Dateien für Ubuntu und Centos).
Nachdem die Spezifikation erstellt und die Umgebung vorbereitet wurde, starten wir unseren Builder, nachdem wir zuvor seine Abhängigkeiten installiert haben:
pip3 install -r requirements.txt
./main.py build -f [конфиг_файл].yaml -r [номер_ревизии]
Die Revisionsnummer ist hier optional und wird zur Versionierung von Assemblys verwendet. Es wird in die Metainformationen des Pakets geschrieben und erleichtert so die Aktualisierung auf Servern.
Anhand der Protokolle können Sie überwachen, was passiert. Hier ein Beispiel für die wichtigsten Punkte:
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'.
Mit nur wenigen Befehlen erstellen wir also die Umgebung und die erforderliche Nginx-Assembly, und das Paket erscheint in dem Verzeichnis, von dem aus das Skript gestartet wird.
Einbettung
Wir können unser Tool auch in CI/CD-Prozesse integrieren. Dabei kann beispielsweise jedes der vielen heute existierenden CI-Systeme Abhilfe schaffen oder .
Daher wird jedes Mal, wenn sich die Spezifikation im Git-Repository ändert, der Build des Artefakts automatisch gestartet. Die Revisionsnummer ist mit dem Build-Startzähler verknüpft.
Mit etwas mehr Zeit können Sie das Artefakt so konfigurieren, dass es an Ihr lokales Paket-Repository, Nexus, Artifactory usw. gesendet wird.
Ein zusätzlicher Vorteil besteht darin, dass die Yaml-Konfigurationsdatei mit Ansible oder einem anderen automatischen Konfigurationssystem verbunden werden kann und wir von dort die Versionsnummer und den Pakettyp übernehmen können, die wir bereitstellen möchten.
Was weiter
Das Projekt ist noch nicht abgeschlossen. Hier ist, woran wir gerade arbeiten:
- Wir erweitern die Konfigurationsmöglichkeiten, halten sie aber gleichzeitig so einfach wie möglich. Sie möchten nicht tausend Parameter definieren, wenn Sie nur zwei benötigen und der Rest standardmäßig passt. Dazu gehören Kompilierungsflags (Sie können sie jetzt in der internen Konfigurationsdatei src/config.py ändern), Installationspfad und Startbenutzer.
- Wir fügen Optionen zum automatischen Senden eines Pakets an verschiedene Artefakt-Repositorys hinzu.
- Führen Sie beim Laden eines Moduls einen benutzerdefinierten Befehl aus (z. B. zur Verwendung Sie müssen zuerst einen Patch einer bestimmten Version anwenden)
- Tests hinzufügen:
- Das Paket ist korrekt installiert.
- Nginx verfügt über die erforderliche Version und ist mit den erforderlichen Flags und Modulen erstellt.
- Die notwendigen Pfade, Konten usw. werden erstellt.
Aber Sie können dieses Tool jetzt nutzen und auch Verbesserungen vorschlagen - Willkommen!
Source: habr.com