Néhány 4-5 tagú webfejlesztő csapatnak keresek fejlesztői környezetet. Főként php, js, pyhtonban nyelveket beszélünk.
Jelenleg van:
- Egy régebbi legacy php+js web applikáció ami sima managed vason fut (apache, php és társai). A dev környezet itt tulajdonképpen remote deployment. PhpStorm minden változtatást feltol a storage-ra, onnan a webszerver mindenkinek kiszolgálja a saját virtualhostján.
- Egy újabb stack ami micro service alapú, és kubernetes clusteren fut. A service-ek önálló docker image-ek. A lokális fejlesztés laptopokon dockerben történik. A service aztán megy a dev/staging clusterre illetve a prod clusterre.
Régen midnig gond volt a lassú és problémás fel/letöltéssel, vpn, stb. Újabban, hogy lokálisan dockerben lehet futtatni az egészet, az lett a gond, hogy a különböző IDE-k mellett a nehany docker image, nodejs stb build processzek rendesen pörgetik a procit... Másrészt, ok, dockerral ezerszer könnyebb lett az élet, viszont szinte minden platformon sántít valami. Win, win wsl, mac os... mindenhol valmi más miatt de lassan minden nem Linuxos fejlesztőnél ott figyel egy Ubuntu virtualboxban ahol szépen összelapátolták maguknak a dev setupot. :)
- Milyen dev setupot/környezetet használtok, miért?
- Remote vagy lokális dev?
- Ha remote docker (pl docker machine-nel) egy távoli vason/VM-en, akkor egy docker engine hogyan tud ki szolgálni több fejlesztőt? Van valamilyen megoldás hogy elkülönítsem a felhasználókat? Egymás image-eit láthatják, nem gond, csak ne akadjanak össze (többen ugyanazt a portot használnák). Vagy mindenkinek kell külön VM, docker engine-nel?
- Ha remote deploymentben gondolkodnék (pl VM dockerrel tokkal vonoval) minden fejlesztőnek ahova az IDE automatikusan sync-el?
- Ha lokális akkor milyen praktikák vannak azon túl, hogy vegyek erősebb hardvert?
Kubernetes problematika
- Ha fejlesztek egy feature-t ami megkövetel egy másik service-t ami eltér a pillanatnyi master vagy developmenttől akkor jelenleg a legegyszerűbb amit tehetek, hogy gyalog készítek egy másik deployt a kívánt barnch-ről és futtatom egy másik hostname-en/porton. Viszont összetettebb helyzetben ennek káosz lesz a vége. Fejlesztőnként egy kubernetes cluster az luxus. Valahogyan route-olni header alapján Istioval, vagy LinkerD-vel? Van valami más automatizált megoldás?
Kíváncsi vagyok a tapasztalatokra, esetleg ha valaki tud más forrást hasonló témákban szívesen fogadom.
- 521 megtekintés
Hozzászólások
Lokális devet ajánlom. Mi a https://www.ddev.com/ddev-local/ -t használjuk, nagyon aktívan fejlesztik, csomó kényelmi dolog van, kb. kiküszöböli az összes hátrányát a Docker alapú megoldásoknak.
Több kérdést tettél fel, most csak a dev setupra írom ezt, a többire persze nem megoldás.
- A hozzászóláshoz be kell jelentkezni
Ez megoldás lesz arra, hogy itt nem megy, ott nem megy, mert ad egy jól dokumentált, letesztelt keretet több platformra.
- A hozzászóláshoz be kell jelentkezni
Ddev vs "nagyon aktivan fejlesztik": https://www.ddev.com/notice/
Remelem ez a mondandodra nem lesz kihatassal.
- A hozzászóláshoz be kell jelentkezni
"DDEV-Local continues, more details will be shared soon."
A hosting business csődölt be sajnos, Drupalos körökben tekintve csak a felhasználói bázisát, eléggé valószínű, hogy nem lesz belőle halott projekt.
- A hozzászóláshoz be kell jelentkezni
A próféta szóljon belőled :)
- A hozzászóláshoz be kell jelentkezni
Nálunk nagyvonalakban a k8ses világ így néz ki:
- minden kubernetesre deployolt cuccra van egy helm chart, amit ugyanúgy verziózunk, deployolunk gitlab CI/CDvel, mint a docker imageket
- Egy helmfile repoban van leírva, hogy a különböző dolgokból mi kerül ki
- Az utóbbi helmfile repoból a különböző branchekről 1-1 namespacebe a gitlab tud új környezetet deployolni, ahol a fejlesztő a teljes stacken kipróbálhatja azt, amit változtatott. Mergekor, vagy x nap után automatán legyakjuk a namespacet
- Ha perzisztens adatok kellenek, akkor azokat a pipeline végén, a namespace létrehozásakor (első futáskor) valahogy odavarázsoljuk
- Valahogy ezek kapnak saját domaint (pl foobar.namespace.company.com) de ebbe nem látok bele
Kicsit nyögvenyelős, mert ha változtatsz, akkor a projekt repojában commit, megvárod, amíg lefut a pipeline, majd a helmfile repoban commit egy branchre, és még egy pipeline indul innen. De cserébe működik, és nem kell különböző módon magicelni, ha szeretnék 1-1 változtatást kipróbálni.
Plusz gondolom egy jó adag vas kell hozzá, mert ha új környezetet akarok, akkor a helmfile deployment miatt a teljes stack kikerül.
Nálunk a perzisztens adatok nagyrészt minioban vannak, szóval bashből simán átmásoljuk, ami kell. Az adatok utolsó verzióinak fájlneveit a forrás oldali (fő) namespace egy cm-je tárolja.
- A hozzászóláshoz be kell jelentkezni
csak ne akadjanak össze (többen ugyanazt a portot használnák)
Erre az egy "szép" megoldás, hogy per fejlesztői környezet legyen külön IP címe a távoli vasnak, és a port publikálásnál ne csak port, hanem IP cím is legyen megadva. Nyilván ezt a rendszer automatikusan nem fogja megcsinálni, úgyhogy a toolingot meg kell hozzá írni.
de lassan minden nem Linuxos fejlesztőnél ott figyel egy Ubuntu virtualboxban ahol szépen összelapátolták maguknak a dev setupot
Teljesen jogos, ha egyszer a végeredmény Linuxon fog futni, és helyben akarja a dev futtatni a cuccost.
és futtatom egy másik hostname-en/porton
Per fejlesztői környezet másik namespace, a helyben meghivatkozott hostname a namespace-en belüli legyen (nem FQDN), és ha nem a namespace-en belül akarod valójában futtatni ezt a szolgáltatást, akkor tegyél egy externalName típusú Service-t a namespace-en belülre, ami az igazi nevére mutat.
Ja, és nyugodtan mehet így az éles környezet is.
Fejlesztőnként egy kubernetes cluster az luxus.
Szinte biztos, hogy hibás a koncepció, ha a fejlesztőnkénti Kubernetes cluster az egyedüli megoldás. Kivételek: security szempontok (nem megbízhatók a fejlesztők, szeparálni kell őket), illetve olyan projekt, ahol a fejlesztett valami a Kubernetesbe beépül (CRD/operátor) vagy Kubernetest deployol. Minden más felállásra kell legyen Kubernetesen belüli megoldás.
- A hozzászóláshoz be kell jelentkezni