Toto je aktualizácia príspevku, ktorý som napísal pred týždňom. Issue na GitHube zatiaľ nedostala žiadnu reakciu.

Stručne, pôvodný problém opisoval skutočnosť, že spustenie príslušnej Ansible Galaxy role by na každom ďalšom behu na systémoch založených na Arch zlyhalo kvôli duplicitnej PID direktíve. Vyzýval som, aby bol nejaký druh opravy prijatý upstream.

Hoci role má vyspelý mechanizmus šablonovania zdokumentovaný pomerne dobre, a sme dôrazne vyzývaní ho správne využívať, v príspevku a v issue vlákne som uviedol, že nestačí na prekonanie tohto bugu, a tak som v príspevku zhruba popísal, ako možno role forknúť a šablónu upraviť.

Možnosť types hash max size #

Postupom času som objavil ďalší problém týkajúci sa inej možnosti konfigurácie Nginx s názvom types_hash_max_size. Problém sa prejavuje cez upozornenie Nginx cez nginx -t alebo v systemd journali:

[warn] could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size

Riešenie — okrem toho, že samotné upozornenie je dosť nápomocné a podrobné — je tiež zdokumentované na Arch wiki:

/etc/nginx/nginx.conf
http {
    types_hash_max_size 4096;
    server_names_hash_bucket_size 128;
    ...
}

Rovnako ako pri pôvodnom probléme s pid direktívou, premenné šablonovania role nepokrývajú riešenie priamo, pretože existuje iba premenná šablóny nginx_server_names_hash_bucket_size a žiadna preddefinovaná pre types_hash_max_size. V porovnaní s problematickou pid direktívou sú tu niektoré dôležité rozdiely:

  • Tento problém nezabráni následným behom role
  • Tento problém nevyžaduje odstránenie riadkov zo šablóny, iba pridanie (spätne kompatibilné)
  • Tento problém možno ľahko vyriešiť cez premennú nginx_extra_http_options

Pozrime sa na tretiu možnosť.

Premenná role pre extra http možnosti #

Pre tých, čo ešte nie sú zvyknutí na mechanizmus šablonovania jinja2 alebo si nevšimli záznam v dokumentácii role, je možné upraviť veľkosť hashu aj veľkosť bucketu cez premenné šablóny tak, aby zodpovedali hodnotám odporúčaným vyššie, a to nasledovným spôsobom ako minimálny príklad playbooku:

---
- hosts: my_hosts
  roles:
    - { role: geerlingguy.nginx }
  vars:
    nginx_conf_template: "{{ playbook_dir }}/templates/nginx.conf.j2"
    nginx_server_names_hash_bucket_size: "128"
    nginx_extra_http_options: |
      types_hash_max_size 4096;

Predvolená veľkosť bucketu je tu 64 a riadok zvyšujúci ju na 128 môže byť dokonca vynechaný, pretože nezabraňuje žiadnemu okamžitému upozorneniu, ale mohol by zabrániť runtime upozorneniam ako client intended to send too large body neskôr.

Táto konfigurácia tiež umiestňuje obe tieto možnosti dosť ďaleko od seba vo výslednom konfiguračnom súbore, čo nie je optimálne, ale s Ansible by sme výsledné súbory nemali vlastne vôbec upravovať. Napriek tomu by ich bolo možné umiestniť spolu, ak niekto neskôr číta súbor.

Prečo jednoducho neupraviť forknútú šablónu? #

Ak by som chcel mať obe premenné umiestnené spolu vo výslednom súbore, musel by som upraviť šablónu buď úplným odstránením riadku nginx_server_names_hash_bucket_size alebo zavedením ďalšej premennej pre types_hash_max_size, pretože jej vloženie do nginx_extra_http_options zjavne vedie k núdzovej situácii:

[emerg] 6175#6175: "server_names_hash_bucket_size" directive is duplicate in /etc/nginx/nginx.conf:40

Rozhodol som sa však šablónu ďalej neupravovať. Kým nenastane zmena upstream, stále musím udržiavať vlastnú forknútú verziu templates/nginx.conf.j2 referencovanú vo vyššie uvedenom príklade playbooku v premennej nginx_conf_template, kvôli problému s pid. Forkovanie je vždy meč s dvoma ostrami. Umožňuje okamžite vyriešiť problém, ale zároveň vyžaduje viac práce pri preberaní upstream zmien, pričom obzvlášť dôležité sú zmeny súvisiace s opravami chýb.

Rozhodol som sa udržiavať zmeny vo forknútej šablóne na absolútnom minime, pretože to zvyšuje šance, že budú prijaté upstream, a namiesto pridávania alebo odstraňovania premenných alebo blokov z forknútej šablóny používam metódu opísanú vo vyššie uvedenom príklade playbooku tak, ako je, zatiaľ.

Toto je 46. príspevok série #100daystooffload.