Obecnie: Czysta instalacja Ubuntu 16 na produkcji i jako OS, te same programy apt-get, te same configi etc. po prostu tu i tu nginx sobie serwowal aplikacje, na produkcji mialem wszystko na porcie 80 i sobie podpinalem domeny pod server_name, lokalnie po prostu hostowalem appki na innych portach.
Dzieki temu moglem bawic sie nginxem zanim cos rozwalilem na produkcji, instalowac sobie pakiety, bawic sie configami.
No ale Docker wydaje sie do tego o wiele lepszym rozwiazaniem, nie musialbym sobie systemu syfic i miec bardziej "prawdziwa" emulacje.
Pytanie: Powinienem sobie zainstalowac dockera lokalnie i probowac skonfigurowac obraz tak, zeby byl jak najbardziej podobny do produkcji, (taka sama wersja php, nginx, gita, etc.) i nie ruszac serwera produkcyjnego, czy na produkcje takze wrzucam TAKI SAM obraz Dockera i wtedy mam dwa srodowiska 1:1.
Meritum: Jezeli uzywalbym tylko dockera lokalnie a na produkcji nie, to jak zblizone beda te dwa srodowiska? Roznica hardware tutaj nie gra roli?
Jezeli uzywalbym dockera i na produkcji i na lokalnie, to nie odbije sie to na performance na produkcji w postaci znaczacego zuzycia zasobow albo spowolnienia serwera/backendu dodajac te kilka ms opoznienia?
Czy stosowanie dockera lokalnie moze zastapic "staging step" czyli taki dodatkowy VPS na ktory cos wrzucam zanim finalnie wrzuce na produkcje?
@Melcma: W świecie dockera powinieneś mieć tylko jedna apkę na container, tylko jeden container to nginx, inny to php etc etc Ponieważ docker to nie wirtualizacja to lepiej symylować produkcję jakimś vagrantem, albo jak pisze kolega wyżej używać dockera wszędzie - sporo produkcji na tym chodzi. Jeszcze lepiej to złożyć te containery w jakiś pod na kubernetes to wtedy produkcja będzie Ci się skalować i działać jako cluster.
@wrzesien: wait, to chyba nadal nie rozumiem jak dziala Docker. Myslalem, ze to cos jak virtualka, ze sobie klonuje jakby srodowisko z produkcji zeby psuc je lokalnie.
Teraz to sie wydaje jeszcze bardziej skomplikowane, moze Vagrant bardziej sluzy do tego co chce osiagnac? Taki "staging" server, tylko, ze lokalnie zeby nie wysylac po kazdej zmianie commita, tylko sie bawic na zywo w kodzie.
@Melcma: To jest coś mniej niż virtualka i więcej niż chroot. Vagrant jest lepszy, ale często stosuje się obie technologie, co też daje różne zalety. Więc w vagrancie symulujesz sobie infrastrukturę, ale poszczególne mikroserwisy trzymasz w dockerze.
Probuje zrozumiec jak dziala docker,
Obecnie:
Czysta instalacja Ubuntu 16 na produkcji i jako OS, te same programy apt-get, te same configi etc. po prostu tu i tu nginx sobie serwowal aplikacje, na produkcji mialem wszystko na porcie 80 i sobie podpinalem domeny pod server_name, lokalnie po prostu hostowalem appki na innych portach.
Dzieki temu moglem bawic sie nginxem zanim cos rozwalilem na produkcji, instalowac sobie pakiety, bawic sie configami.
No ale Docker wydaje sie do tego o wiele lepszym rozwiazaniem, nie musialbym sobie systemu syfic i miec bardziej "prawdziwa" emulacje.
Pytanie:
Powinienem sobie zainstalowac dockera lokalnie i probowac skonfigurowac obraz tak, zeby byl jak najbardziej podobny do produkcji, (taka sama wersja php, nginx, gita, etc.) i nie ruszac serwera produkcyjnego, czy na produkcje takze wrzucam TAKI SAM obraz Dockera i wtedy mam dwa srodowiska 1:1.
Meritum:
Jezeli uzywalbym tylko dockera lokalnie a na produkcji nie, to jak zblizone beda te dwa srodowiska? Roznica hardware tutaj nie gra roli?
Jezeli uzywalbym dockera i na produkcji i na lokalnie, to nie odbije sie to na performance na produkcji w postaci znaczacego zuzycia zasobow albo spowolnienia serwera/backendu dodajac te kilka ms opoznienia?
Czy stosowanie dockera lokalnie moze zastapic "staging step" czyli taki dodatkowy VPS na ktory cos wrzucam zanim finalnie wrzuce na produkcje?
Komentarz usunięty przez moderatora
Myslalem, ze to cos jak virtualka, ze sobie klonuje jakby srodowisko z produkcji zeby psuc je lokalnie.
Teraz to sie wydaje jeszcze bardziej skomplikowane, moze Vagrant bardziej sluzy do tego co chce osiagnac? Taki "staging" server, tylko, ze lokalnie zeby nie wysylac po kazdej zmianie commita, tylko sie bawic na zywo w kodzie.