SUPLA & QNAP

[plnuker]

Czy komuś działa ten obraz na QNAP z Prockiem ARM czy tylko na Celeronach? Support QNAP sugeruje ze to właśnie ARM stanowi problem.

https://forum.qnap.net.pl/threads/supla ... %85.24938/

Zastanawiam sie jaki program, chyba container station jest jakiś upośledzony, przynajmniej na wersje z ARM

[radzio6]

Witam,

Nie wiem czy coś się zmieniło w ostatnich wersjach oprogramowania QNAP / Container Station ale nieco inaczej wygląda u mnie instalacja SUPLi niż na filmie pzygmunt'a: https://www.youtube.com/watch?v=vxiEpM_r98w

Generalnie po instalacji SUPLi w container-station nie znajduje się ona w podsieci bridge tylko jest schowana za NATem i osiągalna wyłącznie poprzez www: https://adres_ip_qnapa:9999 lub http://adres_ip_qnapa:9998.
Z telefonu nie można się już połączyć (port 2016 nie jest już przekierowywany)

Container station tworzy NATa i dwie podsieci (docker0 i lxcbr0):


Kontenery są "z urzędu" przypisane do lxcbr0 i nie można tego zmienić.
Mam u siebie maszyny wirtualne i je bez można bez problemu przypisać do bridge z virtual switchem a kontenery już nie:




Pomimo, że ustawiam podczas instalacji SUPLi adres ze swojej podsieci lokalnej: (CLOUD_DOMAIN: 192.168.178.220) to i tak kontenery są chowane za NATem i nie osiągalne z podsieci lokalnej a jedynie poprzez podane wcześniej adresy i protokół http:
https://adres_ip_qnapa:9999 lub http://adres_ip_qnapa:9998.

Sama SUPLA w kontenerach wygląda tak (APP supla i 3 kontenery):


Czy ktoś się zspotkał z podobnym problemem, NAS to QNAP 251 z QTS QTS 4.3.6.0875 (2019/03/08), wersja Container Station: 1.9.3590 (2018/11/28).

Chciałbym aby kontenery były osiągalne w mojej podsieci 192.168.178.0/24 a nie chowane za NATem Qnapa (lxcbr0)...

[lesny8]

Czy ktoś się zspotkał z podobnym problemem, NAS to QNAP 251 z QTS QTS 4.3.6.0875 (2019/03/08), wersja Container Station: 1.9.3590 (2018/11/28).
Chciałbym aby kontenery były osiągalne w mojej podsieci 192.168.178.0/24 a nie chowane za NATem Qnapa (lxcbr0)...

Pytanie tylko po co Ci to?

To, że kontenery aplikacji znajdują się za NATem na mostku lxcbr0 nie jest wcale wadą. Kontenery komunikują się ze sobą po sieci, którą zarządza środowisko ContainerStation(docker) a nie Twój router. Twoje podejście do tematu jest błędne, bo zarządzanie tą komunikacją nie jest Ci wcale potrzebne. Każdy z kontenerów w ramach aplikacji wystawia porty dla zaprojektowanych przez autora usług i tak: supla-db(3306), supla-server(2015,2016), supla-cloud(80,443). Podczas instalacji ustalasz na jakich portach będą widziane poza NATem na wskazanym adresie/domenie.

Aplikacja mogła by być w jednym kontenerze, ale lepiej jest dokonać podziału. Uruchomienie aplikacji w środowisku zdockeryzowanym z podziałem na kontenery pełniąniące określone funkcje, daje możliwość łatwego dostarczania aktualizacji tylko dla jej części, np. aktualizacja supla-cloud, czy supla-server z osobna.

W przypadku maszyn wirtualnych jest zupełnie inaczej, nie dość że musisz postawić jakiś system operacyjny, który zarezerwuje zasoby gospodarza, to jeszcze po instalacji aplikacji musisz zadbać o prawidłowe wersje składników systemu aby aplikacja działała prawidłowo. Maszyny wirtualne rezerwują zasoby gospodarza na stałe i nawet jak ich nie używają, to trzymają dla siebie. Uruchamiasz dwie, trzy takie maszyny i kończą Ci się zasoby.

Z kontenerami dockera jest nieco inaczej, bo możesz mieć mnóstwo kontenerów i każdy się dopcha do zasobów, bo jak, któryś ich nie używa, to zwraca je do puli. Są też inne zalety, możesz mieć w ramach jednej aplikacji uruchomione np. dwie chmury. Jedną typu release dostępną przez cloud.mojadomena.pl, a drugą rozwojową np. beta_cloud.mojadomena.pl. Zrobienie tego samego na wirtualce czasami jest nie możliwe, a jak już jest to generuje dużo większy koszt zasobów.

Wracając do tematu dostępu do kontenerów to każdy z nich ma wystawione porty na zewnątrz poza NAT dla adresu/domeny, które to podajesz podczas instalacji przez wizarda. O ile porty dla http i https dla supla-cloud możesz podczas instalacji zmienić, o tyle porty 2015 i 2016 dla spupla-server już nie, bo żadne z urządzeń by się nie skomunikowało z serwerem.

Z telefonu nie można się już połączyć (port 2016 nie jest już przekierowywany)

A to nie jest prawdą, bo porty są wystawione. Coś musiałeś przekombinować.

Code: Select all

supla-server:
  environment:
    DB_PASSWORD: password
  image: supla/supla-server
  links:
  - supla-db:supla-db
  ports:
  - 2016:2016
  - 2015:2015
  restart: always
  volumes:
  - ${PWD}/ssl/server:/etc/supla-server/ssl:z
  - ${PWD}/server:/var/run/supla:z

[radzio6]

@lesny 8
Dziękuję za wytłumaczenie. Zapewne wrócę do tematu ponownie, ponieważ na razie zainstalowałem SUPLĘ poprzez dockera na maszynie wirtualnej i mam wszystko w jednej podsieci ale tak jak pisałeś nie jest to wydajne rozwiązanie... no i mniej bezpieczne...
Supla działa na VM ma adres lokalny CLOUD_DOMAIN: 192.168.178.220 i na niego przekierowuję sobie porty z zewnątrz 443, 80, 2015,2016. Plusem przy VM są dla mnie migawki ale pewnie w container station też się to da ogarnąć....

Trochę mi miesza w głowie to NATowanie i osiąganie SUPLI po adresach qnapa tj: https://adres_ip_qnapa:9999 lub http://adres_ip_qnapa:9998. - jak w tym przypadku dodaje się supla-dev? - wpisuje po prostu ip_qnapa:port ??
Obecnie dodając supla-dev podaję lokalne ip clouda tj. 192.168.178.220 i wszystko się ładnie podłącza.
Podsumowując muszę jeszcze raz podejść do tematu i dodatkowo jeszcze przyjrzeć się przekierowaniu portów w container station.

Z telefonu nie można się już połączyć (port 2016 nie jest już przekierowywany)

A to nie jest prawdą, bo porty są wystawione. Coś musiałeś przekombinować.

Code: Select all

supla-server:
  environment:
    DB_PASSWORD: password
  image: supla/supla-server
  links:
  - supla-db:supla-db
  ports:
  - 2016:2016
  - 2015:2015
  restart: always
  volumes:
  - ${PWD}/ssl/server:/etc/supla-server/ssl:z
  - ${PWD}/server:/var/run/supla:z

[/quote]
Robiłem jak na filmie z YT, ale faktycznie może coś przeoczyłem/przekombinowałem.
Raz jeszcze dziękuję za wyjaśnienia.

[lukfud]

Cześć,

Z innej beczki, szukam poprawnego sposobu zainstalowania własnego certyfikatu SSL.

Podmiana certyfikatu i klucza w katalogu supla/ssl/cloud daje nam zieloną kłódkę, ale rejestracja własnej instancji niestety nie przechodzi

Twoja prywatna instancja SUPLA cloud jest niedostępna. Upewnij się, że Twój serwer jest online, a połączenie HTTPS poprawnie działa.

W logu są takie wpisy:

Code: Select all

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.0.3.4. Set the 'ServerName' directive globally to suppress this message                        
[Sat Oct 05 17:10:01.138547 2019] [ssl:warn] [pid 53] AH01906: 10.0.3.4:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)                                           
[Sat Oct 05 17:10:01.139438 2019] [ssl:warn] [pid 53] AH01909: 10.0.3.4:443:0 server certificate does NOT include an ID which matches the server name

[pzygmunt]

Musisz dodać certyfikaty pośrednie.

[lukfud]

Mam certyfikat pośredni, ale nie wiem jak go dodać/zainstalować.

[lukfud]

CA dodany, ale napotkałem kolejną przeszkodę

Code: Select all

Registering your private SUPLA Cloud...
Could not contact Autodiscover service. Try again in a while. (Error: 404)

[pzygmunt]

Nie możesz się połączyć z https://autodiscover.supla.org

[lukfud]

Co mogę z tym zrobić?