2 szerver összekötése kód futtatására másik szerveren

Üdv!

 

Van egy központi gép (S1, amely jelenleg rendelkezik API-val), és szeretnék egy másik gépen (S2) kódot futtatni. Ez API hívásokat fog elindítani egy külső gépre, a lényeg, hogy erről az S2 gépről induljanak a hívások, viszont az S1 adja meg a paramétereket, és ez a gép indítja el a hívást.

 

Ennek a kialakítására keresek megoldást.

 

A jelenlegi beállításoknál megoldás lenne, ha S2 lekérdezné az API-n keresztül S1-et, hogy kell-e valamit csinálnia, de ez nem hatékony.

 

Megoldás lenne, hogy S2 is felszerelkezik egy API-val, és akkor úgy tudnak kommunikálni, de milyen más megoldás lehetséges még ezen kívül?

 

Pl. S1 besshzik S2-re, és lefuttatja, amit kell. Ez mennyire stabil?

 

Milyen más megoldások vannak még az adott problémára? Inkább ötletekre vagyok kíváncsi.

 

Mindkét gépen debian van.

 

 

 

Köszi a válaszokat.

Hozzászólások

Szerkesztve: 2021. 06. 07., h – 20:52

Mik lennenek azok a muveletek, amiket csinalni kell, milyen gyakran, mennyire valtoznak a parameterek, meddig tart egy programfutas? Megszakithato, folytathato? A ket gep egy halon van, vagy a public neten lognak?

Latatlanban: nem az Ansible-t keresed? 

@BCsabaEngine

A paraméterek változnak, mikor hogy.

 

Python kód futtatására van szükség, nem túl nagy mennyiségben, viszont lehet olyan, hogy azonnal kell, tehát nem ér rá kivárni ameddig mondjuk egy cron job percenként megkérdezi, hogy van-e valami feladat.

 

Szerintem egy futás 30 másodpercnél nem lehet hosszabb, de mivel külső API-t hív, bármi megtörténhet. Átlagban 10 másodperc max.

 

Nem igazan folytatható a kód futtatása, ha nem sikeres, akkor majd S1 újra kiadja a feladatot.

 

Nincsenek egy hálon, mindkettő Internetszolgáltatónál van, de országon belül :- .

Python fixen démonként futó TCP szerver vagy web szerver ... amit feltöltesz ebbe, azt shellen keresztül lefuttatja és törli.
Feltöltés: lehet akár 2 fájl is, ahol a másik csak konfigja a futtatandónak. Fantáziádra van bízva.
Valami minimális auth és IP korlátozás ajánlott bele, ha nyílt interneten van.

Nem teljesen vagyok benne biztos, de nem a "microservices" szot keresed, csak nem tudsz rola? A kommunikacio meg tortenhet kb. barmin, attol fuggoen, hogy mennyire vagy elszigetelt/vedett halon.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

nem feltetlen, csinalsz egy endpointot S2-on, amire S1-rol rahivsz, hogy tessek futni adott parameterrekkel. utana meg le tudod kerdezni az allapotat, es akar letolteni az eredmenyt. mivel nem egy halozatban vannak, szinkron SSH-ra nem feltetlen biznek ilyesmit, de akar ott is meg lehet azt csinalni, hogy ssh-n trigger, utana kesobb vegeredmeny ellenorzes es lekeres.

a minimalista megoldas az ez lehet: https://unix.stackexchange.com/questions/30400/execute-remote-commands-…

"de ez nem hatékony" - ez konkrétan mit jelent? Túl sűrűn kellene? Zavar az aszinkron késés? Lassú? 

 

Sokféle megoldás lehet a problémádra, de őszintén még nincs annyi információ amiből jó választ lehet adni.

Lehet-e a meglévő szervert fejleszteni?

Tranzakciószám/s?

Megengedett késés a feladat keletkezésétől

Tranzakció méret.

 

Az, hogy az egyik helyen keletkezik feladat, a másiknak ezt észre kellene venni és elvégezni, ez eléggé mq felé terel. De ha adott az API és nem fejleszthető az az oldal, akkor marad ahogy van, de keresünk megoldást a "nem hatékony" kérdésre, ha megmondod melyik paraméter szerint nem oké

Nem hatékony, úgy értve, hogy lehet olyan kérés, amit azonnal el kell indítani, amikor S2 kéri, nem lehet kivárni, ha pl. cronjob-ból percenként kérdezzük, hogy van-e valami teendő.

 

S1 és S2 kódbázisa is írható, ha erre irányult a kérdés.

 

Minimális a tranzakciószám, talán 50-1000/nap .

 

A feladatok nagy részénél elég lenne, ha percenként lenne figyelve, hogy van-e valami teendő, de egy részüknél viszont azonnal el kell indítani a feladatot. Semmi kritikus rendszer, de lehet olyan S1-es kérés, ami weben keresztül fut be, és azt illene gyorsan kiszolgálni. 4-5 másodperc itt bőven jó.

 

Tranzakció mérete max. 100Kb, de inkább jóval kevesebb.

 

Mq jó ötletnek tűnik, bár most nagyon hajlók egy paramiko-s "besshzós" irány felé, csak úgy nehéz a visszakapott json-t kezelni. Na jó, annyira talán nem.

valami message queue, vagy worker processing-et csinalnek: S1 feladja hogy kene az adat, az S2 megkapja, vegrehajtja, visszakuldi/tarolja az eredmenyt

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

S1-en egy Ansible script ami az S2-n megcsinálja amit kell. Vagy ez már ágyúval verébre..?

bessh-zik, és lefuttatja mint parancsot. Ez a legegyszerűbb, és semmi baj nincsen vele véleményem szerint. Az ssh kapcsolat felépítése minimális overhead. Hiba felismerése is megoldható, és akkor lehet ismételni.

Az ssh-t kulcspárral kell megoldani, akkor eléggé biztonságos, S1 feltörése esetén persze S2 is elérhetővé válik, legalábbis azzal a userrel, amivel ez a dolog fut.

Korlátozható esetleg a futtatható parancs az adott userhez, ha ez szükséges.

Olyat is lehet csinálni, hogy bash parancsértelmező helyett egy program indul az adott user ssh kapcsolatához, ami veszi a parancsokat. Ezzel meg lehet csinálni azt, hogy korlátozod, hogy mit lehet csinálni, például egy XML, vagy egy JSON a parancs, aminek jólformáltnak kell lenni. Így még S1 feltörése esetén is korlátozott, hogy mit tud csinálni a támadó a privát kulcs ismeretében.

Szóval ha nincs extra igény, akkor én így csinálnám. Minden más bonyolultabb.

Meg lehet azt csinálni, hogy egy adott user SSH-ját úgy konfolod, hogy az adott python program induljon el, és ennek az stdin/stdout-ját rákötöd az SSH csatornára. Ha meg tudod csinálni úgy, hogy a kérdés/válasz 1-1 JSON legyen, akkor már kész is vagy, a két programot SSH-n keresztül pontosan úgy kötheted össze, mintha helyben lenne futtatva.

Te egy Job queue-t keresel. Python alatt például a Celery-t tudom javasolni. Kell neki valami queue (akár egy Redis), amiben a futtatandó jobokat, és azok eredményét tárolja.