Puncte:0

Implementarea monorepo fără SSH

drapel cn

Dezvăluire completă: sunt un noob DevOps.

Rulez un repo MERN mono pe o instanță EC2. Inițial, aș fi întotdeauna SSH în mașina mea, trageam din depozit și construiam din nou. Dar există probleme cu asta... procesul de construire durează mai mult și astfel, când conexiunea SSH se întrerupe uneori, procesul de construire se încheie. Acest lucru se întâmplă des, ceea ce face dificilă implementarea.

M-am gândit la asta și sunt sigur că există un serviciu care poate face acest lucru: pot folosi o conductă CI/CD în repo-ul meu (BitBucket), așa că, atunci când există un commit pe ramura principală, poate ping instanța mea, și apoi există o aplicație care rulează pe instanța mea, care atunci când primește acest ping, trage, reconstruiește și repornește repo. Prin urmare, deoarece ar fi o aplicație în interiorul EC2, a.) nu ar fi nevoie de SSH și b.) ar fi o soluție fiabilă de implementat. Ar fi bine să existe dacă ar exista vreo modalitate de a monitoriza procesul de construire atunci când este declanșat.

Nu pot să-mi exprim cerința, prin urmare nu pot să văd soluțiile disponibile pentru a face acest lucru, vă rugăm să sugerați același lucru.

anx avatar
drapel fr
anx
Dacă aveți caracteristicile pipeline BitBucket și sunteți mulțumit de ele, care este întrebarea atunci? Doar... să le folosești? Dacă sunteți dispus să le înmânați cheile ssh adecvate, conexiunea lor nu va fi afectată de problemele dvs. locale de conectivitate.
drapel cn
Întrebarea mea este următoarea: există o astfel de aplicație disponibilă, care poate fi trimisă doar prin ping de către BitBucket (prin IP-ul elastic și rulează în interiorul mașinii EC2) și, atunci când se face ping, va trage și se va construi pe EC2 (aceasta este partea ușoară)
drapel cn
(Din nou, noob aici, sunt sigur că există așa ceva, dar pur și simplu nu știam cum să-l descriu așa că am venit aici)
drapel cn
simplificat și mai mult: configurația mea actuală de implementare implică tunelul SSH și, după cum știm, acestea pot fi instabile, prin urmare, întreruperea procesului de construire și efectul de declanșare a site-ului. Așa că vreau să încep să o evit în favoarea unei soluții care doar pornește o construcție locală (Script) singură, având în vedere un fel de invocare (cum ar fi o invocare REST, de exemplu)
drapel cn
Ai putea pur și simplu [în fundal/detașa procesul](https://askubuntu.com/q/8653/4827), astfel încât să nu fie ucis atunci când procesul părinte (shell) moare sau să folosești `screen`/`tmux` .
drapel cn
@AaronCopley mulțumesc, aceasta este o idee bună pentru implementările manuale, dar, în același timp, ar fi bine să mă eliberez de această nevoie:)
Puncte:1
drapel dj

Aș recomanda să aflați mai multe despre cum funcționează CI/CD. Conductele Bitbucket sunt destul de adecvate pentru a face ceea ce doriți. Ceea ce vrei tu există în sfera multor instrumente. Nu există instrumente unice care să facă totul exact, unii oameni folosesc Kubernetes, alții folosesc docker-compose. Pentru verificarea stării de sănătate, aceasta este de obicei gestionată pe un echilibrator de încărcare sau altele asemenea. Unii creează scripturi personalizate pentru a gestiona totul. Din ceea ce ați descris, se pare că o mulțime de scriere manuală de scenarii ar fi cea mai potrivită.

drapel cn
da, sunt conștient de faptul că bitbucket este adecvat, dar din moment ce cred că ar putea fi necesare unele configurații locale care ar trebui lăsate doar pe mașinile mele EC2, aș dori să păstrez construcția să ruleze acolo... deci tot acel bitbucket trebuie să fac este să dau un ping la mașina mea - (VERIFICAȚI, folosind webhooks), și singura piesă din puzzle rămasă este o aplicație care să primească acel apel webhook pe acea mașină și să înceapă procesul de construire acolo (rulați un script acolo)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.