Erre nincs feltetlenul szukseg. Alapesetben a szerver kontenerek sajat alhalozaton uldogelnek a sajat kis IP-cimuk mogott, tehat siman expozalhatjak pl. a 80-as portot, nem zavarjak egymast. Elejuk rakhatsz egy reverse proxyt, peldaul. Szoval ha mar Dockeren belul maradsz, akkor megcsinalhatod azt, hogy futtatsz egy ilyet:
https://github.com/jwilder/nginx-proxy
Ez annyit csinal, hogy indit egy nginx-et, es ha a hoston elinditasz egy masik X kontenert (pl. Apache+PHP kombot), akkor X inditasakor specifikalsz egy doment (foo.huptudomany.hu, peldaul), es az nginx-proxy kontener automatikusan general egy reverse proxy konfiguraciot hozza.
Magyarul: semmi mas dolgod nincs, csak felloni ujabb es ujabb Apache+PHP kontenereket, es elerhetove valnak a megfelelo domainen. Ezt meg lehet kombinalni ezzel https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion, ami meg megfejeli a fenti setupot azzal, hogy automatan ker neked egy SSL certet a Letsencrypt-tol.
Production-ben nem feltetlen hasznalnam, de jatszani jo - par perc alatt fellohetsz egy tucatnyi webszervert ugy, hogy mindegyik valid SSL certtel rendelkezik, satobbi.
Mi ezt arra hasznaljuk, hogy a Bitbuckethez csinaltunk nehany apro beepulo modult, es a BB OAuth folyamathoz HTTPS callback URL kell. Tehat ezek az apro modulok egy ilyen nginx+letsencrypt megoldas mogott ulnek, nem kell foglalkozni azzal, hogy mikor jar le a cert, etc. Ez persze mind fejleszteshez hasznalt utility, es nem lenne oriasi gaz, ha valami miatt nem mukodne egy par oraig.
----------------------
while (!sleep) sheep++;