V roce 2011 Adam Wiggins z Heroku prezentoval soubor dvanácti rad (The Twelve-Factor App, dále jen TTFA. Jsou to rady, kterými by se měl řídit softwarový vývoj. Rady primárně míří na vývoj SaaS (Software as a Service). Jsou ovšem natolik univerzální a přirozené, že je v průběhu let přijal celý IT průmysl. Nejen vývojáři, ale také administrátoři a šéfové IT oddělení. S několik málo aktualizacemi jsou platné dodnes.

Pojďme si vypíchnout zejména rady, které ocení administrátoři. Pokud se například rozhodujeme, který software nasadit, mějme Twelve-Factor jako jedno z kritérií. Šance, že vybereme správně se vysoce zvýši. Jsou to konfigurace (III.), vazba s portem (VII.) a logy (XI.).

Konfigurace

Konfigurace ukládejte do prostředí.

TTFA klade důraz na konfiguraci přes environmental variables. Takové to PORT=8080. Důrazně varuje před zadrátovanými konfiguračními konstantami v kódu. To je skvělý přístup a těžko něco zásadního namítat. Přesto je dobré si uvědomit dvě skutečnosti:

  1. Environmental variables nejsou tak úplně bezpečné uložiště pro hesla. Pokud to služba umožňuje, používáme pro citlivé údaje šetrnější zacházení. Typicky Cloudflare Secrets, Docker Compose Secrets, Kubernetes Secrets , pro uchování citlivých údajů v git repozitářích SOPS nebo distribuovanou správu citlivých údajů přes OpenBao. Způsobů je spousta a vydalo by to za samostatný článek.

  2. Některé konfigurace vyžadují stukturovanou formu, typicky YAML nebo JSON. Snažit se je nacpat do environmental variables by skončilo velkou frustrací. V takovém případě udržujeme konfigurační soubory v reprodukovatelném (univerzálním, minimálním) stavu, aby těžiště konfigurace zůstalo na straně environmental variables.

Kompletní znění: https://12factor.net/cs/config

Vazba s portem

Exportujte služby pomocí vazby na port.

Ethernet a IP protokol si prorazily cestu všude. K databázím už dávno nepřistupujeme přes ODBC, ale přes TCP/IP. Předávat službu na portu je univerzální a pohodlné. V moderním pojetí tento bod můžem paradoxně chápat také jako "nesnažte se nacpat celé HTTP do jedné služby", protože služba směřem ven sice komunikuje typicky přes HTTP interface, ale mezi uživatelem a službou je HTTP požadavek předáván na několik místech, než k samotné službě dorazí. U velkých aplikací je na začátku typicky Load Balancer, který se stará o rozkládání zátěže. TLS terminace (HTTPS / reverzní proxy), která se stará o cetifikáty. WAF (Web Application Firewall), který se stará o první bezpečnostní vrstvu. Případně další předřazené služby, které se funkcionalitou často překrývají.

U malých služeb je možné celou takovou komplexnost nechat na službách jako "oranžový" Cloudflare. Nebo jen vzít Caddy jako reverzní proxy a doufat, že náš server je natolik nezajímavý, že jej nikdo zneužívat k útokům nebude.

Kompletní znění: https://12factor.net/cs/port-binding

Logy

S logy zacházejte jako s proudy událostí.

Princip je prostý. Nechme proud událostí z aplikace vypisovat na stdout/stderr a posílejme je na centrální zpracování. Na tomto principu kdysi vyrostla logovací služba Splunk, než vstoupila na burzu a stala se nepoužitelnou pro drobné nasazení. Naštěstí máme spoustu open source nástrojů, které sbírají, transformují, agregují a zobrazují logy. Pokud máme nastavené alerty, také posílají upozornění na nenadálé události. Mezi nejpopulárnější řešení patří Grafana Loki.

Mikrotik RouterOS má možnost také vypisovat proud událostí to terminálu a posílat je na vzdálený syslog server.

Dobra pokročila, takže kompletní dohledový stack není jen o logování. Pro administrátory jsou důležité i metriky, ačkoliv tady podpora v síťových prvcích pokulhává. Naopak vývojáři jdou ještě dál a používají trasování a profilování. IT svět pro tuto problematiku vyvinul označí o11n, observability nebo lidové označní Ollie.

Kompletní znění: https://12factor.net/cs/logs

Dvanáctka závěrem

Koho problematika zaujala, může si projít všechny rady na původním webu https://12factor.net/cs/.

Kdo najde maximálně 12 minut, může se mkrnout na výcuc problematiky od @devopstoolbox na výše uvedeném videu.