rysiek:
Mogę rzecz jasna zrobić podobnie, jak na libvirt/kvm -- obrazy całych "maszyn", z uruchomionymi usługami (np. maszyna z db, ldapem, nginxem, etherpadem, owncloudem; druga z db, nginxem, django i stroną, etc). Ale...
...mam wrażenie, że w świecie dockera jest inna praktyka: docker container na każdą usługę oddzielnie. Czyli np. kontenery fwioo/postgres, fwioo/ldap, fwioo/etherpad, fwioo/django, fwioo/itakdalej.
Słuszne masz wrażenie.
3 dni. I jestem w podróży. ;)
Justyna dobrze radzi: pobaw się najpierw choć przez chwilę (ale: nie mówię, że zabawiać się nie masz jedną z tych maszyn do przeniesienia).
Może faktycznie przerzucę na razie wirtualki sauté, i obczaję dockera z bliska. Tyle że jak przerzucę vmki sauté, nie będę miał potem motywacji i czasu na przerzucenie tego potem na dockera. Ech, życie.
Mam podobnie – z tym, że odwrotnie: choć *wiem*, że poprawniej jest mieć wszystko w osobnych, odpowiednio polinkowanych między sobą kontenerach, to póki co przynajmniej część usług będę stawiał w postaci całego stosu w jednym kontenerze. Od pięknego „zrobię to poprawnie, szkoda, że będzie gotowe na święty nigdy” czasem lepsze jest pragmatyczne „do GitLaba i ownClouda są gotowe Dockerfile’e, postawię to w nich teraz, a jak już będzie działać to się zajmę wydłubywaniem z nich np. baz danych”.
Oczywiście flame’a „baza tylko żywcem na hoście” vs „wspólna baza w osobnym kontenerze” vs „każdej apce jej własna baza wewnątrz” też trzeba w odpowiednim czasie samemu przepracować. ;)
— Piotr Szotkowski