Skocz do zawartości
Zaloguj się, aby obserwować  
mlodycompany

Własny panel

Polecane posty

Witam. Zamierzam stworzyć własny panel do zarządzania kilkoma maszynami. Panel byłby na jednej centralnej maszynie i komunikował się z pozostałymi maszynami. Zastanawiam się tylko jak rozwiązać komunikację panelu z konkretnym serwerem. Myślałem aby zastosować do tego SSH ale obsługa tego w PHP jest według mnie marna, połączenie trwa za dużo czasu. Macie może jakieś pomysły, ciekawe rozwiązania jak to można rozwiązać? Myślałem też nad stworzeniem deamona i z nim się komunikować, lecz też nie wiem czy to jest do końca dobry pomysł.

 

Pozdrawiam!

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość bolek10

Daemon chyba jest najlepszym rozwiazaniem. Zalezy tez do czego ma byc ten panel.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Zależy co chcesz obsługiwać. Jak masz multum operacji to robisz tabele w bazie z operacjami do wykonania (id, operacja, status) i demon wyciąga po kolei o robi. Jak mnie, to po prostu na żywo łączysz się z demonem z PHP.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Misiek08 co masz na myśli mówiąc multum operacji? Chodzi mi o czyste zarządzanie maszyną + kilka opcji dla ułatwienia np. interpreter logów. Czy można to nazwać multum operacji?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Chodziło mi np. o maszyny, na które wrzuca się dziennie trochę filmów i strona daje demonowi do przerabiania filmy. Wtedy warto zrobić tabelkę w bazie i demon wybiera z bazy zadanie, wykonuje i zmienia status jak skończy. oczywiście to nie muszą być filmy, to może być serwer testujący wytrzymałość stron internetowych (loadimpact, blitz.io). To takie przykłady. W Twoim przypadku wystarczy demon, np. JSON-RPC, które strona podaje informacje, a on na żywo je wykonuje i odpowiada.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość bolek10

A że tak zapytam, są na rynku takie panele? Wiem że allegro coś w pythonie wypuściło ale nie czytałem o tym za wiele.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Nie XML-RPC, bo jest niepotrzebny narzut treści, a JSON-RPC, czyli czystość w przekazie i minimalizm.

 

W Pythonie masz do serwerów gier revo. Tzn daemon jest w revo.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Czyli muszę stworzyć deamona, który będzie nasłuchiwał na jakimś porcie, czekał na otrzymanie danych w postaci JSON'a, interpretował, wykonywał i zwracał odpowiedz również w JSONie? Dobrze zrozumiałem? A jak z autoryzacją i bezpieczeństwem przesyłanych danych? Chciałbym aby wykonywanie komend było z uprawnieniami konkretnego użytkownika, tego co jest zalogowany do panelu. Czyli wypadało by wysłać hasło do deamona. Jak coś takiego można zabezpieczyć lub rozwiązać w taki sposób aby nie wysyłać hasła. Komunikacja przez SSH sama w sobie rozwiązałaby te problemy.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

To, co chcesz zrobić, to ZDALNE WYWOŁYWANIE PROCEDUR (po angielsku RPC).

Opracowań na tworzenie systemów rozproszonych i uwzględniających temat jest co niemiara.

Musisz udać się do biblioteki i poczytać :)

 

Technik na realizację zdalnych procedur jest też wiele. Wspomniane XML-RPC, JSON-RPC.

Jest też Java RMI, CORBA, DCOM, SOAP... Masz w czym wybierać :)

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

JSON-RPC jest prawdopodobnie jednym z najmniej pożerających transfer i bardzo czytelnych.

 

Autoryzacja leży po Twojej stronie: czy to klucz, czy hasło usera kodowane po stronie PHPa jeszcze, a potem sprawdzane przez demon. Wykonywanie z uprawnieniami usera polega na tym, że demon pracuje na roocie, a wykonuje komendy poprzez sudo.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bardziej podoba mi się pomysł z wykorzystaniem bazy. Odpada wtedy autoryzacja i jest łatwiejsza obróbka. Co o tym myślicie? Które rozwiązanie jest bezpieczniejsze? Które byście wybrali?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Z doświadczenia:

 

1. Baza to nie kolejka. Trzymanie tam zadań do wykonania to generalnie głupi pomysł, chociaż jak masz je trzy na krzyż to możesz tego nie zauważyć. Jak chcesz sobie taką kolejkę zrobić, to użyj do tego produktu, który do tego służy, np. RabbitMQ albo Redisa.

 

2. Push, nie pull. Z panelu pchaj informacje po dobrze zdefiniowanym interfejsie do jakiegoś demona, który nie ma dostępu do żadnej centralnej bazy. Na początku prościej jest rzeczywiście wystawić sobie całą bazę ryjem w LAN i grzebać po niej z serwerów ale ugryzie Cię to w dupę przy pierwszej zmianie schematu (albo będziesz musiał robić deploy wszędzie_natychmiast_w_jednym_momencie, albo wspierać rozjechane wersje panelu, demona i schematu bazy -- nie ić tom drogom). Coś, co działa z roota, musi być maksymalnie proste, tępe i łatwe do przetestowania.

 

3. KISS. Nie kombinuj, nie wymyślisz lepszego SSLa, lepszego HTTP i lepszego JSONRPC. My jedziemy na własnym mtrpc [1, 3], które sprowadza się do JSONRPC po AMQP, ale jeżeli nie masz (i nie potrzebujesz do innych rzeczy) brokera AMQP, to pomyśl po prostu o komunikacji po ssh (z multipleksowaniem sesji[5] ma całkiem zadowalającą wydajność). Trochę możesz sobie uprościć życie gotowcem typu ansible[4, 6]

 

4. Jeżeli dojdziesz do wniosku, że musisz robić jakieś własne mechanizmy uwierzytelniania, to usiądź i poczekaj aż Ci przejdzie. To bardzo rzadko jest dobry pomysł. Użyj https i certyfikatów klienta, kluczy ssh albo czegokolwiek (nawet http basic auth), ale nie wymyślaj koła na nowo.

 

5. Konkretny mechanizm RPC to rzecz gustu. Są ludzie, którzy z własnej woli używają SOAPa. Realnie i tak nie będziesz tego z łapy generował, a na tcpdumpie jsonrpc jest mniej więcej tak samo czytelny jak xmlrpc (zwłaszcza szyfrowany ;]). Wybierz coś, co ma wygodny interfejs w Twoim języku programowania.

 

My (MegiTeam) obecnie mamy serwery pythonowe rozmawiające po JSONRPC-over-AMQP i to RPC jest ich jedynym interfejsem do świata zewnętrznego (nie mają wjazdu do żadnej bazy itp.). Architektura jest fajna i mocno elastyczna (zwłaszcza z dodatkowym celery[2]), natomiast jak nie potrzebujesz czegoś wymyślnego, to pomyśl o czymś takim:

- SSH z multipleksowaniem połączeń (opcjonalnie zostawiasz `ssh -Nf serwer` w tle dla każdej maszyny)

- wjazd po kluczu ssh na roota ograniczony do jednego polecenia -- tym poleceniem jest jakieś Twoje narzędzie (napisane w czymkolwiek), które jeszcze raz waliduje sensowność wszystkich parametrów (nawet jak Ci panel przepuści założenie usera z uidem 0, dobrze mieć jakąś ostatnią linię obrony), a potem robi.

- protokół możesz mieć jakiś ustandaryzowany typu jsonrpc, albo jechać po bandzie z "ssh serwer 'admintool add-user foo:$1$xxxxxx$...:1234:1234:...'", wszystko zależy od tego, co będziesz miał po stronie serwera i w czym Ci się będzie to dobrze pisać (parsowanie SOAPa w bashu to trochę sport ekstremalny)

 

1. http://www.megiteam.pl/blog/2010/05/23/amqp/

2. http://www.megiteam.pl/blog/2012/06/10/umarl-agent-niech-zyje-agent/

3. http://github.com/gnosek/mtrpc

4. http://www.slideshare.net/gnosek/ansible

5. http://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

6. http://ansible.cc/

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Osobiście bawiłem się w obrabianie zdjęć i filmów i powiem, że albo JSON-RPC albo baza w stylu MongoDB i kolejkowanie. taka baza ma to do siebie, że schemat tworzy sie "live" i dodanie np. nowego parsera do plików czy dodanie opcji przy kompresji nie robiło problemu, bo baza jest mega elastyczna. Autoryzacja po SSL czasami ma swoje zalety, czasami wady. Auth Basic tez powinien wstarczyć.

 

Poza tym - @up - dobry poradnik dla osoby, która w ogóle nie ogarnia agentów i uczy dobrych manier :)

 

Jeszcze co do bazy: MySQL czy Postgre się teoretycznie nie nadają, jednak widziałem 1 rozwiązanie o ruchu ok. 2000 zapytań SELECT/s i działało to nieźle, ale maszynka też była dość kosmiczna - tylko potrzebowali transakcji, więc Mongo czy inne alternatywne odpadały.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się

Zaloguj się, aby obserwować  

×