A TDD és a Docker mennyire kompatibilis?
Nézegetem egy ideje a Docker-t, most úgy döntöttem, hogy kipróbálnám egy hobbi projektnél, hogy mennyire használható. Elvileg az lenne a lényege a Docker-nek, hogy ne fordulhasson elő, hogy az egyik gépen működik a cucc, a másikon meg nem, mert valami környezet függő probléma van. Tehát nekem úgy logikus, hogy a tesztelésnél is ugyanolyan container-ben teszteljük a kódot, mint amilyenben élesben futni fog. Lehetséges valahogy image build nélkül a Docker-es környezetben tesztelni a kódot? Ha nem, akkor mi értelme van az egésznek? Több másodperces build-ekkel nem igazán lehet TDD fejleszteni...
■ 
TDD
Nem is maga a build a
Nope
Azt is megteheted persze, hogy nem masolod, hanem mountolod (volume). Ez esetben nem kerul idobe lefuttatni.
Okés, akkor így próbálom
Nem
Roviden es tomoren: minden parancs a Dockerfile-ban egy-egy layert hoz letre es az a layer csak akkor fut le ujra es akkor ir a filerendszerre, ha eldobod a cachet es/vagy valtozik a bemenet. Ha nem valtozik semmi, a layer sem irodik ki. Raadasul minden layer diff formaban van tarolva, tehat csak a ket layer kozotti kulonbseg tarolodik.
Ez jól hangzik. Köszi!
Teljesen
Nálunk úgy néz ki a dolog backenden, hogy phpunitot használunk tesztelni, valamikor (amikor változott) buildeltél egy környezetet (nálunk ez 6 db container), és ebben írkálod a kis tesztjeidet-kódodat ameddig akarod. Ha bármelyik image változik, akkor kell új build, addig nyugodtan dolgozhatsz.
Új buildnél is (ha csak nem nyomtál valami okból pl factory resetet) csak az(ok) a container gyártódik újra, amelyik változott, és az sem 0-ról, csak amiben változott.
Nekünk a containerek indítása is bash scripttel történik, hogy egyetlen paranccsal minden le legyen rendezve. Factory reset után sem tart 10 percnél tovább, de ha több, mint 5 perc, akkor már lassú volt a net vagy a github stb.
Na ez nem világos, bár
mount
Itt pont az a lényeg, hogy a konténerben az van, ami az éles szerveren, de neked a kód és IDE, stb, a Te gépeden, a Te szájízed szerint belőve, GitHub klienssel, mindennel.
Módosítasz 1 karaktert 1 fájlban, és azonnal a konténerben is ugyanaz van.
Annyira én nem vagyok ebben otthon, van kolléga, aki csinálja, max értelmezem az eredményt. :)
De a lényeg ez, hogy a kódbázis plusz pár config, temp data könyvtár így van mountolva, ennek élesben is fontos szerepe van: elosztott rendszernél, ahol van 6-8-mittoménmennyi worker-app-memcached-stb konténer, több fizikai vason, azok között is meg legyen osztva az, aminek kell.
Docker konténer(eke)t egyszer elindítod, és amíg nincs benne változás / upgrade, addig hagyhatod is futni, a kódot simán cserélgeted benne, futtatod. Ahhoz, hogy kódot futtass, nem kell image-t buildelni.
Köszi!Így már világos,
Így már világos, tehát a docker csak futtatókörnyezet, a kódot meg mountolással adod át neki. Ezek szerint élesben is így megy?
Van még egy dolog, ami még nem tiszta, hogy hogyan megy docker-nél. Nézegettem még régebben, de már nem nagyon emlékszem. Adatbázist hogyan tudsz container-ben futtatni, egyáltalán szükséges-e? A másik, hogy a fájlrendszerbe hogyan tudsz menteni mondjuk feltöltött fájlokat?
élesben
Pl MySQL: másik konténer, be lehet őket linkelni egymás között. Érdemes külön konténerbe, mert sok esetben másik vason van. Aztán ott van az is, hogy hátha vannak slave db k is stb... :)
Egyéb (upload stb) fájlok: érdemes elkülönített könyvtárba, ugyanúgy lehet mountolni.
Ha konténeren kívül nincs rájuk szükség, akkor csak a futó process nek kell írási jogának lenni a könyvtárra.
A konténeren belül pont olyan szervered van, mint amit megszoktál docker nélkül. Ha mountolod, látod fejlesztés közben is kívülről.
Köszi! Majd holnap