Sa luam varianta simpla: un server Linux in cloud cu suficient RAM si stocare (se poate ajusta oricand) la care va conectati prin SSH si rulati aplicatiile in dev mode.
Sta pornit doar la nevoie (nu 24/24) si nu realizeaza mult trafic in exterior, deci nu-i asa scump.
Ce nevoi n-ar acoperi?
Pentru partea asta poti incerca portainer. Eu il folosesc pe un home-server pentru a monitoriza containerele pornite acolo.
Te conectezi la baza de date remote cu ssh tunnel dacă e vorba de backend, dacă e vorba de microservicii faci tracing și loguri la tot în kibana/logstash.
Datele din producție de multe ori sunt secrete și doar SRE-ul, suportul are acces la ele. Nici nu se pune problema ca un dev să aibă acces la datele din producție.
Am mai avut un tool care exporta anonimizat datele de la client, dar doar anumite parti.
Nu zic că ce zici tu e greșit, doar că nu-i universal valabil. Poate că nu toți au microservicii, logstash, SRE, containere etc în infrastructură.
Nu zic că sunt rele, dar poate că nu toți au (nevoie|buget|timp|know-how) de toate lucrurile astea.
Poate structura DB nici măcar nu permite export parțial 
În cazul meu: fac WP iar ce am zis mai sus sunt implementări pentru diverse funcționalități extra. Să sparg WP în microservicii ar fi overkill. Iar export parțial în WP? haha, good one. 
Eroarea legată de caracterele CN nu apărea în absolut niciun log, nici măcar pe dev. Apărea altceva în logs iar cauza era extrem de neevidentă. Era o chestie silent care… se întâmpla. De fapt, modul în care am descoperit problema a fost să pun utilizatorul să înregistreze ecranul, după care am început să reproduc întocmai pașii respectivi, până am putut replica problema.
best fix ever
de acord, dar in cazul de fata pare sa fie regula (cei 200gb) si nu exceptia.
I guess I’m spoiled having a 1TB mac.
Pana găsești un tool poti sa faci un server cu un script simplu care face treburile astea:
Cu asa ceva poti rula multe proiecte preconfigurate într-un config file, trebuie doar să dimensionezi bine serverul sa le duca pe toate. In config poti pune si links la unde tii file uploads,etc. ca sa nu ai 200gb urcati in docker de fiecare data, un fel de S3 bucket.
Ceva de genul ăsta au facut niște colegi pentru testing. Îi dădeau un branch si instala, rula teste, raporta și curăța la sfârșit.
A trebuit sa fac un research, recent, pentru unul din clientii nostri, legat de o arhitectura pentru Remote Development Environment
O sa las aici draft-ul cu informatiile adunate:
Identifying the steps
* 1. Having the environment prepared (node with a starter project)
* 2. Hosting/storing the project (source code) files
* 3. Sync browser code changes with the remote environment filesystem
* 4. Run/Execute/Watch the app source code
* 5. Get the output and display it in the browser
—-
General concept [REMOTE DEVELOPMENT] [Remote Ephemeral Workspaces]
* Articles
* https://slack.engineering/remote-development-at-slack/
* https://engineering.linkedin.com/blog/2021/building-in-the-cloud-with-remote-development
* https://shopify.engineering/shopifys-cloud-development-journey
* https://www.usenimbus.com/post/these-tech-teams-use-cloud-environments
* https://www.jetbrains.com/remote-development/
* https://www.jetbrains.com/space/features/dev-environments.html
* Github Actions
* GitHub Runners
* PHP - https://github.com/marketplace/actions/setup-php-action#github-hosted-runners
* Python - https://github.com/marketplace/actions/setup-python
* Node - https://github.com/marketplace/actions/setup-node-js-environment
—
Preparing the environment (Bare Custom Implementation)
* Having already 10+ each predefined environments for each language (php/python)
* Every time a new user logs in, trigger a build (which will create a new workspace/environment)
* Build can be triggered by triggering a Github Action via GitHub API
* https://www.youtube.com/watch?v=84kUf9ycr9A
* https://www.provartesting.com/documentation/devops/continuous-integration/github-actions/remote-trigger-in-github-actions/
* A GitHub Action can be an workflow running a build pipeline utilising docker
* Azure App Service instances, where choosing different langauge images docker.
* AWS EC2
* Github runners
—-
Sync browser files’s with environment filesystem (node)
* https://github.com/serkanyersen/sync
* https://github.com/sergi/jsftp
* File System Access API - https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API
* https://motif.land/blog/syncing-text-files-using-yjs-and-the-file-system-access-api
* https://github.com/motifland/yfs
* https://yjs.dev/
* https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
—-
Running the Code
* Making a call to our backend
* Which will login through SSH to the environment instance,
* Sync the code
* Then will do a “git pull”, This is needed if no “scp” or “sync” solution was implemented
* Run the code
* Build -> Then restart the environment app process if needed (if not started through watch mode)
* Watch -> nothing else needed
* Then capture output of SSH command
* Send it to the frontend
*
* Others
* https://github.com/marketplace/actions/capture-output
* https://docs.aws.amazon.com/codecatalyst/latest/APIReference/API_ListEventLogs.html
—
3rd Party Services (Remote ENVs) with API
* https://www.gitpod.io/
* https://github.com/features/codespaces
* https://aws.amazon.com/codecatalyst/
* https://docs.aws.amazon.com/codecatalyst/latest/APIReference/Welcome.html
* https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CodeCatalyst.html
* https://docs.aws.amazon.com/codecatalyst/latest/APIReference/API_ListEventLogs.html
Hosting User Project Files
* AWS S3
* Github Repos
* Sync filesystem using SCP for copying files to a environment VM
Online Code Editor
* Custom Implementation (extending CodeMirror)
* https://github.com/Felx-B/vscode-web
* https://vscode.dev/
* https://github1s.com/ShareX/ShareX
* https://github.com/coder/code-server
* https://code.visualstudio.com/docs/remote/vscode-server
Code Compilers API (check if they support multi files, and frameworks like React, Django)
* https://rapidapi.com/j
* https://sphere-engine.com/
* https://www.jdoodle.com/compiler-api/
* https://www.hackerearth.com/recruit/api/
* Open Source
* https://github.com/judge0/judge0
Am facut si noi un research, nu chiar asa complex si am gasit:
Noi momentan folosim proxmox cu vm-uri pentru fiecare developer (avem un template din care clonam vm-ul noului dev).
Pe partea de secrets folosim https://infisical.com/
Interesant. Nu stiam ca exista sa o solutie, deja simteam nevoia de asa o necesitate.
Am facut si noi un research, nu chiar asa complex si am gasit:
Mda, pe astea le-am gasit si eu, cat si multe altele. Sunt o duzina.
In cazul meu, exista deja un Code Editor, iar ce am eu nevoie, e mai mult un 3rd party service de compilare/executie a codului, dar sa suporte si multi-file projects/prgorams. Preferabil sa-i pot trimite o arhiva cu tot proiectul. Si output-ul la executie sa-l primesc cat se poate de instant.
Pentru asta, am gasit acest serviciu al carui API pare sa suporte asa ceva.
Daca ai un proiect care poate fi rulat local e trivial, distractia incepe cand ai servicii cu AI, multiple baze de date mari, zeci de servicii si micro-frontenduri.
Mai trebuie sa ai multi arch build pentru arm pe mac-uri…
Ai descris cam modul nostru de lucru.
GitLab isi face treaba minunat. Separi frumos faza de build (in care se fac imagini docker) cu faza de deploy. GitLab are integrat un Docker Registry.
Poti face un job care declanseze upgrade pe un VM la fiecare commit ce ajunge pe master (care stii ca tot timpul e dupa master, sau dupa ce vrei tu; la noi orice ajunge pe master e reviewed si testat luand commitul din dev branch). Si instalezi manual un anumit commit ID (intern lucram cu commit ID ca “versiune”, extern cu versiuni publicate).
Ai nevoie sa iti “containerizezi” aplicatia si sa ai niste scripturi de install si upgrade.
Eu la mine local in WSL (pe Windows) sau pe orice Linux rulez asta ca sa instalez sau ca sa fac upgrade la un anumit commit ID:
./finstall.sh 52bdb88736ba20ef1633dcf9ce58febafd60f38a
./fupgrade.sh f20c3813bcd027550682dbbdd8c4103132e8e522
Daca poti instala aplicatia ta cu o singura comanda si dureaza cateva minute sa faca instalarea, poti sa iti creezi VPS-uri intr-un cloud si sa le platesti doar cate o ora sau cateva ore pana faci niste verificari.
PS: Evident ca asta nu e “remote dev environment”. Ci e automatizare de build si deploy ca sa testezi foarte rapid aplicatia pe orice Linux chel (si tot evident, e un best practice de CI/CD sa folosesti aceleasi imagini - testate manual - in productie).
Remote dev e inca tricky in 2023. Stackurile sunt variate, nevoile sunt diferite intre echipe. Nu exista un one size fits all.
Dar cam ce a zis si @adrian-a e un punct de plecare bun.
Disclaimer pentru ceea ce urmeaza sa zic: suna simplu de facut, rezultatul este elegant, dar munca e enorma.
Ok, deci noi toti suntem obisnuiti sa lucram local; up/down, o migratie aici, o migratie acolo, schimbi linia de cod, dai commit, faci pr, rezolvi bugul. Si vrei sa faci asta la o urgenta si cand te duci cu janghina de laptop personal acasa la ai tai printre multe pahare de vin? Super, suntem pe aceeasi pagina.
Pasul 1: lucruri de baza
Un mediu reproductibil. Docker deobicei, poate un Podman. Nu ai cum altfel, mediul tau local trebuie sa fie si undeva remote.
Masina/VM-ul de dev. Provisioned cu necesarul de care ai nevoie ca sa iti ruleze mediul. Aceasta masina, o consideram masina personala a devului. Provisioned doar pentru el cu propriile sale chei de la creere. Doar el are access pe aceasta masina.
Un DNS intern accesabil doar prin VPN. Conexiunea se face prin VPN, iar devul ca sa isi acceseze masina se va conecta la: masinamea.vpnintern.com
Pasul 2: modul de lucru
Cam la fel ca pe local, dar prin vpn si ssh se face conexiunea. Adaugi hostul in vscode, lucrezi exact ca si pe local.
Ce ajuta, dar e optional:
La vpn grija mare, daca ai cumva ceva ce face foarte multe request-uri s-ar putea sa ai nevoie de ceva beefy, inclusiv pentru WireGuard. Plus e complicat de setat sa treci doar anumite porturi selectiv prin VPN. Posibil un server de vpn/server, daca folosesti acelasi server de VPN pentru mai multi unul s-ar putea sa ii afecteze pe toti.
Kubernetes e cam singura solutie buna, docker compose e inconsistent intre sistemele de operare. Kubernetes e greu de folosit.
Cand lucrezi cu ceva de dev/instabil, probabil ca o sa ai nevoie de restarturi periodice la VM/intregul server, pur si simplu o sa ai memory leak-uri, ciudatenii pe care nu le poti vedea dar simti ca totul se misca mai incet.
Nu uitati de shared cache, posibil merita sa ai un folder cu rsync/drive shared pe care sa pui cache-ul de la npm (pnpm)/gradle/build de pe mai multe calculatoare. (remote cache)
Kaniko are un sistem de cache interesant daca vine vorba de build si k8s/docker.
Eu cea mai mare problema o vad cu serviciile care ruleaza doar pe Windows sau ceva ce ruleaza doar pe mac (e.g. mobile dev)
Yup, complet posibil; de-aia avem un mic dashboard de genul la Frisbo:
Oh si masinile se si inchid automat dupa cateva ore de inactivitate (mai salveaza niste costuri). Devul cand intra la computer, intra pe dashboard si da click pe start. Un manager poate sa dea access si shared pe o masina (idk, just in case).
Depinde de ce folosesti. Dar oricum, mi se pare mai bine si mai usor sa tratezi VM-ul ca o masina de prod practic si sa lasi doar ce e whitelisted afara/inauntru. Astfel, VPN-ul e mai mult sau mai putin chior configurat si securitatea vine de la setupul masinilor. Bine, asta doar daca VPN-ul ala nu e genul de vpn universal care access peste tot in intranet :))
