ugrás a tartalomhoz

A TDD és a Docker mennyire kompatibilis?

inf3rno · Júl. 4. (K), 15.52
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...
 
1

TDD

janoszen · Júl. 4. (K), 16.28
Meg Javaval is lehet TDD-zni, pedig ott is van forditas. Epitsd fel ugy a projektedet es Dockerfile-odat, hogy a filejaid bemasolasa legyen az utolso lepes. Ha rengeteg fajlod van, bontsd librarykra, kulonben amugy is sokaig fog tartan ia libraryk buildelese.
2

Nem is maga a build a

inf3rno · Júl. 4. (K), 16.40
Nem is maga a build a probléma, hanem hogy mennyi ideig tart. Java-nál azért az a benyomásom, hogy általában 1-2 másodperc alatt tudják tartani, ha jól csinálják. A Docker-el kapcsolatban meg az a benyomásom, hogy ennél jóval több időt vesz igénybe, ezért gondoltam, hogy hátha van olyan megoldás, amivel csak egyszer kell buildelni, azzal létrehozok egy állandóan futó teszt környezetet, aminek át tudom küldeni a kódomat. Valahogy hasonlóan, mint a karma-nál. Majd még keresgélek a témában, egyelőre ez csak most merült fel, nem igazán volt időm foglalkozni az elmúlt évben Docker-el.
3

Nope

janoszen · Júl. 4. (K), 17.14
A Dockernel az a helyzet, hogy a Dockerfile osszes parancsa egyenkent fut le es cachelesre kerul. Ha nem valtozik a forras, akkor nem futtatja ujra. Vagyis ha a kod bemasolasa az utolso parancs, akkor csak az fut le.

Azt is megteheted persze, hogy nem masolod, hanem mountolod (volume). Ez esetben nem kerul idobe lefuttatni.
4

Okés, akkor így próbálom

inf3rno · Júl. 4. (K), 17.33
Okés, akkor így próbálom majd. Esetleg van rá lehetőség, hogy ne fájlba menjen a build? Ha mondjuk 1GB egy image fájl, akkor minden build-nél kiír annyit a fájlrendszerbe? Esetleg a cache miatt csak a töredékét? Azért ha rendesen fejleszt az ember gyakori teszteléssel és újra és újra a teljes 1GB-ot írja ki a Docker, akkor egy SSD-n már megeheti a NAND cellákat vagy a vezérlőt a sok írási ciklus.
5

Nem

janoszen · Júl. 4. (K), 20.09
Sztem nezd meg hogy hogy mukodik a Docker. :)

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.
6

Ez jól hangzik. Köszi!

inf3rno · Júl. 4. (K), 20.20
Ez jól hangzik. Köszi!
7

Teljesen

Pepita · Júl. 5. (Sze), 09.37
Nem igazán értem, hogy a build folyamathoz mi köze a TDD-nek...

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.
8

Na ez nem világos, bár

inf3rno · Júl. 5. (Sze), 16.31
Na ez nem világos, bár valszeg amiatt, mert nem teljesen értem a Docker működését. Amikor build-elsz, akkor létrejön egy image, aztán amikor futtatod ezt az image-t, akkor egy container jön létre, ami kb egy futó oprendszernek felel meg alkalmazásokkal, mindennel. Hogyan juttatod el ennek a container-nek a módosított kódot tesztelésre?
9

mount

Pepita · Júl. 5. (Sze), 18.06
A kód könyvtára mount-olva van, kb így(docker-compose.yml)

        volumes:
            - ~/Containers/inf3rno-app/akarmi/:/srv/valami:rw
Első a Te oprendszered alatti elérési út, második a konténeren belüli (Linux) oprendszeré, jogosultsággal.
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.

Hogyan juttatod el ennek a container-nek a módosított kódot tesztelésre?
A rövid válasz erre az, hogy sehogy, mert benne van és benne szerkeszted.
10

Köszi!Így már világos,

inf3rno · Júl. 5. (Sze), 18.30
Köszi!

Í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?
11

élesben

Pepita · Júl. 5. (Sze), 21.32
Azt nem igazán tudom, csak sejtem, hogy élesben is (talán egy vason belül) megosztva van a fájlrendszer.

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.
12

Köszi! Majd holnap

inf3rno · Júl. 5. (Sze), 21.54
Köszi! Majd holnap játszadozok vele egy kicsit, kíváncsi vagyok mire jutok. :-)