comSysto bei XING

27
.
06
.
2017

Jenkins Builds mit node-sass beschleunigen

Es kann nie schnell genug sein!

Müssen Sie auch trotz 64 CPU Cores und 12 Terrabyte Ram im Jenkins Build-Server immer auf langsame Downloads warten obwohl sie schon einen npmjs.com Mirror nutzen? Dann könnten es langsame post-install Downloads wie node-sass binary bindings sein.

Bernhard

Lean Java Expert

EINLEITUNG

In so ziemlich jedem Projekt verwende ich node-sass und bei jedem CI-Build muss ich zusehen, wie der CI-Server eeeeeeewig braucht bis das sass-binding von github.com heruntergeladen ist. Trotz schneller DSL Leitung scheint der Download irgendwie serverseitig von Github gedrosselt zu sein. Ich sitze hier und warte 1 Minute auf 7MB … das kann so nicht weiter gehen!

Warten ...
‍Warten ...

Da muss man doch einfach einen Mirror aufsetzen können! Im GitHub Issue 1104 wurde ich fündig und entschied mich für einen einfachen NGINX disk cache mirror, da ich nginx bereits auf meinem Server am laufen habe. Daher richten wir nun folgendes ein:

  • NGINX disk cache und proxy auf github.com node-sass releases
  • Anpassung der package.json für node-sass
  • Setzen einer globalen node-sass mirror Variable (gerade bei Dockerized builds super)

 

SIMPLEN NGINX DISK CACHE PROXY AUFSETZEN

Wichtig ist, dass der Cache auf der SSD und nicht auf dem langsamen RAID1 disk array liegt. Der Cache sollte dabei 12 Monate halten (inactive=12M). Wir legen die nötigen Verzeichnisse and und vergeben entsprechende Rechte:

shell:mkdir -p /opt/nginx-cache/node-sass

 

shell:chown -R www-data:www-data /opt/nginx-cache/

 

Mein erster Versuch schlug fehl, weil die download URL von GitHub einfach einen 301 Redirect auf AWS S3 macht und das dann am Proxy-Mirror vorbeiführte. Wir müssen also den Redirect innerhalb des NGINX auflösen. Daher musste ich NGINX mit einem ‘@handle_redirect’ und ein paar anderen Angaben dazu bringen das zu tun. Wir müssen bspw. auch den S3 Cookie ignoren, da sonst nicht gecached wird und mit proxy_cache_valid auch noch angeben, dass die Antwort 12 Monate Gültigkeit hat.

github:0d9077c82e25e91ee952748fc0e5ceba

Nun noch die Subdomain einrichten und den A-Record auf unseren lokalen Jenkins zeigen lassen. In meinem Fall 192.168.178.66. Dabei auch in der FritzBox unter “Heimnetz” => “Netzwerkeinstellungen” => “DNS-Rebind-Schutz” die Domain erlauben, da der Server ja im lokalen Netzwerk steht.

 

TEST

Die Ursprungsurl ‘https://github.com/sass/node-sass/releases/download/v4.5.3/linux_musl-x64-46_binding.node’ schreiben wir auf unseren Mirror um und fragen diese mit Curl ab. Intern führt der NGINX den redirect auf AWS S3 aus und gibt uns die Datei direkt aus.

shell:curl -L -o linux_musl-x64-46_binding.node http://node-sass-binary-mirror.codeclou.io/sass/node-sass/releases/download/v4.5.3/linux_musl-x64-46_binding.node

Jetzt dauert es etwas. Aber schon beim zweiten Versuch geht es super schnell!

 

PACKAGE.JSON UPDATEN

Dort wo node-sass als dependency angegeben ist, haben wir leichtes Spiel. Wir können einfach eine Angabe in der package.json machen:

github:c1b29fe09049eb2082628bd04a7697bb

Doch besser wäre etwas globales, was für alle Projekte gilt.

 

GLOBALE VARIABLE

Wenn wir bspw. die Angular CLI global installieren, haben wir keine package.json zum anpassen. Daher setzen wir einfach die folgende Environment Variable.

shell:SASS_BINARY_SITE='http://node-sass-binary-mirror.codeclou.io/sass/node-sass/releases/download'

Installiert man nun Angular CLI, so wird der Mirror genutzt.

shell:npm install -g @angular/cli

 

FAZIT

Es muss nicht immer die super teure Proxy Lösung oder gar eine Lizenz für irgendeine Software sein. Oft reicht einfach ein kleiner Mirror, und schon hat man mehr Lebenszeit zum coden.

Themen:

Kommentare?

comSysto Logo