Ahoj,
mam prosbu ... potreboval bych vedet, co je nejaka best-practice, popripade nasmerovat, jestli jdu uplne blbe.

Aktualne mam webhosting, kde mam 2 domeny + subdomeny k nim.
Eshop + blog + web/blog (tj. 3 nezavisle weby s DB) + emaily

A resim to, ze bych z webhostingu (wedos) presel na svoje vlastni VPS nekde. Jako prvni me logicky napadnul docker. Nicmene vubec netusim, jak to korektne udelat.

Napriklad u eshopu jsem si rikal, ze by bylo uplne skvely si treba stahnout cely dock jak se souborama, tak s DB ... pustit to u sebe lokalne na PC, udelat upgrade, nahrat zpatky na VPS (cimz bych minimalizoval downtime eshopu).

Jak se todle resi?
1 dock s apache + souborama k webum
1 dock pro DB
1 dock pro ftp / maily ?

Zalohy webu delat formou stazeni celyho docku, anebo pres cron co vysype soubory do zipu nekam?

Diky !

Mám jeden dotaz ohledně dockeru, protože se týká spíš CI/CD, tak jsem ho dal do klubu vedle. Abych to necrosspostoval, tak sem jen odkazem: [ Continuous integration, App Deployment ]

Budu rád za vaše hinty. Vďaka!

MARTEN: jj, tomu rozumim .. jen mne zajimalo, jestli pri tomhle zpusobu to vyrobi vic vrstev nebo ne .. ze jde vyrobit ze scratch jsem uz studoval, mame totiz v praci jednu hodne archaickou aplikaci v Ccku, co uz nejde pod aktualnima OS zbuildit, ted to bezi na serverovym Ubuntu 8.04, ke kterymu uz jsem nenasel zadnej image, takze jsem to chtel prave vyrabet z kopie filesystemu ..

MARTEN: btw, vi v alpine je :)

MARTEN: aha, to s tim ulozenim po vrstvach je docela dulezita informace, diky. Vlastne to urcuje hierarchii, v jaky by mel clovek ten vysledny image skladat (cim nizsi vrstva, tim obecnejsi a vic reusovana vec)

co vrstva to jeden prikaz v docker file? a kdyz by ten image vznikl tak, ze pustim nejaky base image, pripojim se na nej pres ssh a nakonfiguruju/nainstaluju, pak z toho udelam image, bude to jedna vrstva?

ADM: Ano 192.168.99.1 má být jako adresa hosta, když na hostu běží mock. Volá se URL něco jako http://192.168.99.1:10600/v1/secure/nnnnnn. Ale já si na tu adresu hosta ani nepingnu, pokud fyzický počítač (host) není ve firemní síti, ale je offline nebo třeba doma.

Ale díky kolegům jsem objevil workaround, i když příčinu problému stále neznáme.

Stačí do konfigurace pro službu kterou mockuju dát jako endpoint namísto 192.168.99.1 IP adresu, kterou zjistím tak, že se v minikube VM dotážu na ping na název fyzického (hosta) počítače, když jsem v síti, a překladem zjistím IP. Tahle IP asi nebude stálá, ale to tolik práce zjistit jednou denně není.


Takže pokud mi něco neuniká, přijde mi to na problém v nastavení sítí VBoxu nebo v doménové politice či jiných omezeních našich fyzických pracovních počítačů (protože nechápu, proč by adresa hosta jako 192.168.99.1 byla vidět jen ve firemní síti) a asi nesouvisí s Dockerem jako takovým.

MVEK: jasne, takze ta 192.168.99.0/24 bude adresa virtualboxu host only networking, 192.168.99.100 je adresa toho virtualu s minikube, a ta 192.168.99.1 se tam asi pridava jako adresa hosta. takze kdyz si tu lokalni sluzbu nastartujes na 192.168.99.1, tak ji musi sluzby z toho virtualboxu videt. kdyz to teda funguje, jaky jsou tam zdrojovy adresy requestu na http://192.168.99.1:10600/ ?

Samozřejmě nefunguje ani ping z toho virtuálu na tu adresu na hostu, když je host offline nebo třeba přes VPN.
Koukal jsem, že ten adaptér má nastaveno an hostu:

Ethernet adapter VirtualBox Host-Only Network #2:

Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 192.168.99.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

ADM: Ano, už sám vidím svou špatnou úvahu, že nemůžu si hrát s wget z hostu a myslet si, že stejně je na tom aplikace v kontejneru ve VM ve VBoxu. Ale ano nepopírám, že mé síťové znalosti jsou taky chabé, ve škole to mnou před lety bohužel z větší části jen proteklo.

Podíval jsem se víc na situaci a:
VM se vytváří inicializačními příkazy a nástroji, takže při vytváření jsem si svou nevědomostí bordel neudělal.
1) VBox má dva adaptéry, jeden NAT a druhý VirtualBox Host-Only Ethernet Adapter #2 typu Paravirtualized Network (virtio-net).
2) Služba běží v minikube ve VBoxu. Poslouchá sama na http://192.168.99.100:30050/, na kterém jí v mém testovacím scénáři posílám SOAP request z hostu. A pak sama (i podle logů) kontaktuje přes POST ten mock na http://192.168.99.1:10600/.
3) Mock poslouchá na http://192.168.99.1:10600/ a běží na hostu (je napsaný v Javě, volá na poslouchání JdkHttpServerFactory.createHttpServer(new URI("http://192.168.99.1:10600/"), myApplication, true); )

V bodě 2 služba vytimeoutuje, když je host offline (odpojený kabel, vypnutá wifi...), nebo na VPN nebo např. za mým domácím routerem. Ale funguje v pracovní síti.


Jak bych mohl ověřit, jak doopravdy ta služba mock kontaktuje, nebo co bych mohl zkusit dál hledat?

MVEK: tak kristalova koule nepomohla, ale je to samozrejme ciste sitovy problem, podle toho co pises to vypada ze docker kontejnery spoustite pod minikube ve virtualboxu. dulezity bude si zjistit jaky networking pouziva ten virtualbox, viz https://www.thomas-krenn.com/en/wiki/Network_Configuration_in_VirtualBox a s tim souvisi ta sit 192.168.99.1/24, ta je kde, na jakym rozhrani

ted vidim ze pises o proxy, ta se v siti nachazi kde? nedava moc smysl aby se pouzivala externi proxy pro lokalne spustene docker kontejnery

DANIELSOFT, MVEK: Dík, no ten parametr se zdá, že ani můj Docker (17.10 klient, 17.12 server) nezná (není v nápovědě), ale možná opravdu na Win chybí. Ale stejně zatím nevím, jak bych to aplikoval, protože já vůbec příkaz docker pro startování a vytváření díky tomu Helmu atd. nepoužívám (ale třeba bych našel někde, jak to protlačit).


Já ale zhruba příčinu mezitím odhalil, když jsem si zkusil wgetem kontaktovat ten mock. On je problém v našich proxinách. Takže spíš půjdu o dům vedle do nějakého síťového fóra, protože jedna věc je, že defaultně máme nastavenou proxy pro HTTP a HTTPS komunikace, a tu to samozřejmě offline nenajde (a na VPN asi taky ne). Druhá věc je, že vyřazením tohoto nastavení, kdy mi už wget asi kontaktuje mock, mi to stejně stále nefunguje.

MVEK: hmmm... možná to bude něco jiného, ale já měl před časem problém, že mi Docker ignoroval /etc/hosts na hostitelském stroji

v mém případě pomohl parametr "--network host" u "docker run", třeba ti to pomůže taky

Omlouvám se za lame dotaz amatéra, jsem nucen s Dockerem pracovat jako tester vyvíjené aplikace, a přitom podporu máme strašnou, ale hlavně tento problém omezuje v tuto chvíli jen mě, a jen pokud potřebuji pracovat z terénu, nikoliv v kanclu, takže to přenechat jiným moc nemůžu.

Řeším, proč mi komunikace z microservice v Dockeru kontaktuje správně mock na 192.168.99.1:10600 jen, když jsem ve firemní síti. Pokud jsem na VPN nebo offline nebo jinde, tak timeout. Přitom na tom 192.168.99.1:10600 poslouchá mock pouštěný z mého počítače (kousek kódu pouštěný přímo v IDE IntelliJ Idea).
Ping na danou IP adresu můžu udělat kdekoliv a dopadne stejně úspěšně. Komunikace mezi dílčímí mikroservisami také funguje. A z počítače do mikroservis přes jinou soukromou adresu (192.168.99.100) se taky dostanu kdekoliv.

Nenapadá někoho, kam dál se pošťouchnout, kde pátrat?
Dodám jen, že tedy nejedeme na čistém Dockeru. Máme tu ještě gokube/minikube, Helm, Kubernetes a minikube VM se vytvoří a spustí ve VirtualBoxu. Instalaci mikroservis pak řešíme přes Helm. Celé prostředí startujeme přes minikube start/stop.
Workaroundem by pro mě bylo připojit si ten mock jako docker kontejner, který jiný vývojář vytvořil, ale ten neumíme nahrát přes Helm, aby to spolupracovalo. A ano, podle mě je tu pěkný bordel, ale jelikož tomu jen tak rozumět nebudu, tak do toho vrtat nemůžu.

Možná je to spíš síťová záležitost, ale třeba se tu aspoň dozvím, kde pátrat. V tuhle chvíli se půjdu prát s Wiresharkem, ale jsem v něm amatér, zkusil jsem si v něm něco před mnoha lety.

MARTEN: te velikosti jsem se bal u image repository, nas nexus ma aktualne kolem 50gb zbuildenych zdrojaku (mival i 400, nez jsme ho spravne nastavili :) ), kdyz k tomu pridam tu omacku s OS, javou apod .. ale je pravda ze prostor je dneska uz levny a asi to zbytecne optimalizuju dopredu