Neobejde se to bez drobného filozovování. Docker, reps. kontejnerizace, začíná tím, že admin v hlavě překope dosavadní vzorce. Ideální start je dvanáctifaktorka. Zcela vážně, bez změny myšlení se na to adaptovat nedá. Jakmile admin pochopí, že aplikace opravdu nepotřebuje udržovat stav, má vyhráno. Pro další body budu předpokládat nasazení přes Docker Compose.
1) Kontejnerová infrastruktura si žije vlastním životem. Takové Sim City. Spojení z vnějšku dovnitř na http/https se děje přes reverzení proxy (doporučuju caddy-docker-proxy, která se automaticky konfiguruje podle labels). Tím pádem není podstatné, jestli aplikační kontejnery běží na IPv4 nebo IPv6.
2) Pro ne-http služby se používají mapované porty. TLS terminace pro ne-http se dají hezky dělat přes stunnel v sajdkáře (podpůrný kontejner).
3) Někdy se admin nevyhne vytváření sítě ručně (docker create network), ale jinak je samozřejmě žádoucí mít všechnu konfiguraci deklarativní (compose.yml).
4) Maximum konfigrace je vhodné nacpat do environmental variables a secrets. Viz dvanáctifaktorka výše.
To je takový základní průlet, ale když si to člověk v hlavě představí, úplně to stačí. Určitě nejlepší praxe se propsala do návrhu Kubernetes. Takže když admin studuje Kubernetes, dokáže si podle toho v Docker Compose nadizajnovat strukturu, včetně škálování. Ale samozřejmě je lepší rovnou přejít na Kubernetes. To ale jiná kapitola. Dřív jsem si třeba říkal, že na některé případy se kontejnery nehodí. Typicky monolitické aplikace. Časem jsem přišel na to, že kontejnery se hodí úplně na všechno.
