Własny panel

[mlodycompany 29]

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!

[Gość bolek10]

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

[mlodycompany 29]

Do ogólnego zarządzania serwerem, czyli edycja userów, grup, zarządzanie usługami, obsługa logów i inne szmery bajery

[Misiek08 285]

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.

[mlodycompany 29]

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?

[Misiek08 285]

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.

[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.

[boe666 0]

popieram xml-rpc lub podobny sposób komunikacji. Autoryzację i szyfrowanie łatwo wykonać.

[Misiek08 285]

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.

[mlodycompany 29]

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.

[kafi 2425]

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ć

[Misiek08 285]

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.

[mlodycompany 29]

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?

[blackfire 185]

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/

[Misiek08 285]

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.