Drugi własny serwer Supla (docker), druga instancja, równoległa instalacja ...

_aro_
Posty: 51
Rejestracja: pn kwie 09, 2018 5:10 pm
Lokalizacja: Legnica

Witam szanowne grono !

Doszedłem do takiego etapu, że chciałbym spróbować postawić równolegle drugi działający serwer Supla.
Chciałbym, aby jeden był moim środowiskiem testowym, a drugi powiedzmy bardziej poważnym :D
Niestety, ale nie znalazłem podobnego tematu na forum, ale może wpisywałem niewłaściwe słowa kluczowe ..
Jeśli ktoś wie gdzie to jest opisane to proszę o wskazanie.

To, czego do tej pory próbowałem:
Rzecz się dzieje na Synology DS716+.
Na dzień dzisiejszy mam zainstalowany w dockerze własny serwer z wykorzystaniem tutoriala kolegi lesny8:
viewtopic.php?p=29999#p29999
po odpowiednim zmodyfikowaniu go do możliwości sprzętu Synology. Niedługo zresztą będę publikował własny tutorial właśnie
pod kątem Synology (tak na marginesie).
Wiadomo, że w dockerze można uruchomić więcej instancji tego samego programu - mam równolegle 4 działające serwery OpenHab :D i chodzi to bez problemów - i tak myślałem właśnie zrobić, ale niestety mi się nie udało.

Przechodząc do konkretów (będę się odnosił do tutoriala powyżej):
1. sklonowałem jeszcze raz git-a, ale tym razem w inne miejsce

Kod: Zaznacz cały

git clone https://github.com/SUPLA/supla-docker.git /volume1/docker_farm/supla2/
2. wygenerowałem nowy plik .env

Kod: Zaznacz cały

./supla.sh
3. wyedytowałem go

Kod: Zaznacz cały

vi .env
na końcu zmieniłem domyślne porty dockera na 8082 oraz 4445 żeby uniknąć konfliktów z działającym już pierwszym serwerem Supla na portach 8080 oraz 4443.

4. uruchamiam skrypt

Kod: Zaznacz cały

sudo ./supla.sh start
i tu się sypie cała koncepcja, bo powstające kontenery i tak łączą się do działającej już instancji - konkretnie łączą się do tej samej podsieci w dockerze (u mnie supla_default, 172.22.0.0/16) w której funkcjonuje już przecież pierwszy serwer. Wynika to pewnie z zapisów samego skryptu uruchamiającego. Ale też nowo powstające kontenery nadpisują stare - nie wiem do końca - tak to po prostu wygląda jakby nowa instancja wchodziła dokładnie w miejsce starej a mi chodzi, aby była obok.
Z OpenHab nie miałem tego problemu - w drugim pliku uruchamiającym dockera (akurat ja mam opis w pliku .yml) określiłem inne, nowe porty, wskazałem inne, nowe wolumeny i wszystko poszło zgodnie z oczekiwaniami.
Tutaj ugrzązłem ...
Awatar użytkownika
lesny8
Posty: 2808
Rejestracja: pn gru 11, 2017 9:43 pm

W pliku .env zmień nazwę projektu na inną
https://github.com/SUPLA/supla-docker/b ... efault#L39
i spróbuj ponownie odpalić skrypt.
Czekam na kolejne Supla Offline Party 👍
_aro_
Posty: 51
Rejestracja: pn kwie 09, 2018 5:10 pm
Lokalizacja: Legnica

Hejka !

Dzięki za zainteresowanie :)

Zmieniłem nazwę projektu na supla2 w pliku .env w przedostatniej linii i dwa kontenery wystartowały, ale ostatni już nie:

Kod: Zaznacz cały

arek@DS716:/volume1/docker_farm/supla2$ sudo ./supla.sh start
Password:
Starting SUPLA containers
Creating network "supla2_default" with the default driver
Creating volume "supla2_supla-server-socket" with default driver
Creating supla2-db ... done
Creating supla2-cloud ... done
Creating supla2-server ... error

ERROR: for supla2-server  Cannot start service supla-server: driver failed programming external connectivity on endpoint supla2-server (cb517f87a4534264b54fc658a2d66fd212f7e9ac39d051297bcbd9f091027dc1): Bind for 0.0.0.0:2016 failed: port is already allocated

ERROR: for supla-server  Cannot start service supla-server: driver failed programming external connectivity on endpoint supla2-server (cb517f87a4534264b54fc658a2d66fd212f7e9ac39d051297bcbd9f091027dc1): Bind for 0.0.0.0:2016 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.
Rzeczywiście mam przecież te porty używane w działającej pierwszej instancji supla-server

Kod: Zaznacz cały

CONTAINER ID    IMAGE                       COMMAND                     CREATED        STATUS        PORTS                                    NAMES 

1e913bc8b0d1    supla/supla-server      "/usr/bin/server-e..."     3 weeks ago   Up 6 days      0.0.0.0:2015-2016->2015-2016/tcp             supla-server
ale tam też przecież jest drugi port zajęty czyli 2015, a o tym system nic nie pisze. Może jeszcze ten błąd wyskoczy. Nie wiem.
Czy powinienen w związku z tym gdzieś jeszcze zmienić porty na których komunikuje się supla-server ze światem z domyślnych 2015 i 2016 na jakieś inne wolne ? Gdzie ?
Awatar użytkownika
lesny8
Posty: 2808
Rejestracja: pn gru 11, 2017 9:43 pm

Tutaj zmień.
Czekam na kolejne Supla Offline Party 👍
_aro_
Posty: 51
Rejestracja: pn kwie 09, 2018 5:10 pm
Lokalizacja: Legnica

Witam ponownie !

Uwaga długi i nudny post :?

Dzięki za podpowiedź - po zmianie portów z istniejących

Kod: Zaznacz cały

ports:
      - "2016:2016"
      - "2015:2015"
na

Kod: Zaznacz cały

ports:
      - "2014:2016"
      - "2013:2015"
w pliku docker-compose.yml spróbowałem jeszcze raz odpalić skrypt

Kod: Zaznacz cały

sudo ./supla.sh start
Trzy nowe kontenery uruchamiają się prawidłowo, ale podczas uruchamiania zatrzymują się z kolei oryginalne kontenery i widać że ten nowo postawiony serwer ma w jakiś sposób wpływ na działanie oryginalnego - pierwotnego serwera.
Zrobiło się o tyle niefajnie, że niestety, ale już połączone i działające od jakiegoś czasu urządzenia do mojego oryginalnego serwera supla wysypały się całkowicie, nie mogły sie połączyć, serwer przestał odpowiadać i w ogóle tragedia :)
W tym momencie musiałem przyswoić wiedzę w zakresie bacupowania i przywracania danych.
W jakiś sposób są oone jednak ze sobą połączone - nie wiem jeszcze gdzie.
Pomyślałem, że to może poprzez nazwy uruchomionych w pliku docker-compose.yml serwisów następuje jakieś połączenie - nie wiem.
W działającym już serwerze w pliku docker-compose.yml są zdefiniowane przecież takie same nazwy jak w tym nowym.
Dalej działałem trochę na czuja - pogrzebanie w pliku docker-compose.yml wydawało mi się dobrym kierunkiem.
Przypominam, że w moim przypadku jest to wersja docker, ale standalone.
Pozmieniałem go więc w poniższy sposób:

Kod: Zaznacz cały

version: '3'

services:
  supla2-cloud:
    container_name: ${COMPOSE_PROJECT_NAME}-cloud
    restart: unless-stopped
    image: supla/supla-cloud
    env_file:
      - .env.default
      - .env
    volumes:
      - ./ssl/cloud:/etc/apache2/ssl:z
      - ${VOLUME_DATA}/cloud-local:/var/www/cloud/var/local
      - ${VOLUME_DATA}/cloud-logs:/var/www/cloud/var/logs
      - supla-server-socket:/supla-server:z
    links:
      - supla2-db
    depends_on:
      - supla2-db

  supla2-db:
    container_name: ${COMPOSE_PROJECT_NAME}-db
    restart: unless-stopped
    image: mysql:5.7.20
    env_file:
      - .env.default
      - .env
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_PASSWORD}
      MYSQL_DATABASE: supla
      MYSQL_USER: supla
      MYSQL_PASSWORD: ${DB_PASSWORD}
    volumes:
      - ${VOLUME_DATA}/mysql:/var/lib/mysql:z

  supla2-server:
    container_name: ${COMPOSE_PROJECT_NAME}-server
    restart: unless-stopped
    image: supla/supla-server
    env_file:
      - .env.default
      - .env
    volumes:
      - ./ssl/server:/etc/supla-server/ssl:z
      - supla-server-socket:/var/run/supla:z
    ports:
      - "2014:2016"
      - "2013:2015"
    links:
      - supla2-db
    depends_on:
      - supla2-cloud

volumes:
  supla-server-socket: {}
Jak widać pozmieniałem (dopisałem cyfrę 2) do nazw serwisów oraz pozmieniałem nazwy powiązań.

Zmieniłem jeszcze nazwę serwisu w pliku docker-compose.standalone.yml bo podczas uruchomienia skryptu

Kod: Zaznacz cały

sudo ./supla.sh start
zgłosił mi błąd

Kod: Zaznacz cały

ERROR: The Compose file is invalid because:
Service supla-cloud has neither an image nor a build context specified. At least one must be provided.
Dopisałem tradycyjnie cyfrę 2:

Kod: Zaznacz cały

version: '3'

services:
  supla2-cloud:
    ports:
      - "${PORT_HTTP}:80"
      - "${PORT_HTTPS}:443"
Po ponownym uruchomieniu skryptu

Kod: Zaznacz cały

sudo ./supla.sh start
wygląda to lepiej, ale ciągle niezbyt dobrze - trzy kontenery uruchamiają się prawidłowo, nie widać żeby miały jakiś wpływ na pierwotny serwer, nie pokazują się błędy.
Działające kontenery - trzy pierwsze to testowa supla, trzy następne to podstawowa (takie nazwy projektów z plików .env żeby je rozróżnić):

Kod: Zaznacz cały

CONTAINER ID        IMAGE                       COMMAND                   CREATED             STATUS                 PORTS                                                                NAMES
1522b14e8850        supla/supla-server          "/usr/bin/server-ent…"    5 hours ago         Up 5 hours             0.0.0.0:2013->2015/tcp, 0.0.0.0:2014->2016/tcp                       testowa_supla-server
a5f6921c550f        supla/supla-cloud           "docker-php-entrypoi…"    5 hours ago         Up About a minute      0.0.0.0:8082->80/tcp, 0.0.0.0:4445->443/tcp                          testowa_supla-cloud
32278b934143        mysql:5.7.20                "docker-entrypoint.s…"    5 hours ago         Up 5 hours             3306/tcp                                                             testowa_supla-db
f8a426634c7e        supla/supla-server          "/usr/bin/server-ent…"    29 hours ago        Up 29 hours            0.0.0.0:2015-2016->2015-2016/tcp                                     podstawowa_supla-server
71acf0483c2f        supla/supla-cloud           "docker-php-entrypoi…"    29 hours ago        Up 29 hours            0.0.0.0:8080->80/tcp, 0.0.0.0:4443->443/tcp                          podstawowa_supla-cloud
169f3984e590        mysql:5.7.20                "docker-entrypoint.s…"    29 hours ago        Up 29 hours            3306/tcp                                                             podstawowa_supla-db
Niestety, ale kontener testowa_supla_cloud restartuje się co minutę:

Kod: Zaznacz cały

sudo docker logs -f testowa_supla-cloud

Kod: Zaznacz cały

Waiting for database connection (10)...
Waiting for database connection (9)...
Waiting for database connection (8)...
Waiting for database connection (7)...
Waiting for database connection (6)...
Waiting for database connection (5)...
Waiting for database connection (4)...
Waiting for database connection (3)...
Waiting for database connection (2)...
Waiting for database connection (1)...

In AbstractMySQLDriver.php line 103:

  An exception occured in driver: SQLSTATE[HY000] [2002] php_network_getaddre
  sses: getaddrinfo failed: Name or service not known


In PDOConnection.php line 47:

  SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name o
  r service not known


In PDOConnection.php line 43:

  SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name o
  r service not known


In PDOConnection.php line 43:

  PDO::__construct(): php_network_getaddresses: getaddrinfo failed: Name or s
  ervice not known


doctrine:database:create [--shard SHARD] [--connection [CONNECTION]] [--if-not-exists] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command>


In CheckDbConnectionCommand.php line 28:

  Could not connect to to the database.


                    Application Migrations



In AbstractMySQLDriver.php line 103:

  An exception occured in driver: SQLSTATE[HY000] [2002] php_network_getaddre
  sses: getaddrinfo failed: Name or service not known

In PDOConnection.php line 47:

  SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name o
  r service not known


In PDOConnection.php line 43:

  SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name o
  r service not known


In PDOConnection.php line 43:

  PDO::__construct(): php_network_getaddresses: getaddrinfo failed: Name or s
  ervice not known


doctrine:migrations:migrate [--write-sql] [--dry-run] [--query-time] [--allow-no-migration] [--configuration [CONFIGURATION]] [--db-configuration [DB-CONFIGURATION]] [--db DB] [--em EM] [--shard SHARD] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command> [<version>]
Najwyrażniej nie może połączyć się do bazy danych ...
Logi z testowa_supla-db:

Kod: Zaznacz cały

sudo docker logs -f testowa_supla-db

Kod: Zaznacz cały

2019-10-06T17:46:26.209909Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-10-06T17:46:26.213083Z 0 [Note] mysqld (mysqld 5.7.20) starting as process 1 ...
2019-10-06T17:46:26.222064Z 0 [Note] InnoDB: PUNCH HOLE support available
2019-10-06T17:46:26.222132Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-10-06T17:46:26.222147Z 0 [Note] InnoDB: Uses event mutexes
2019-10-06T17:46:26.222159Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-10-06T17:46:26.222172Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2019-10-06T17:46:26.222183Z 0 [Note] InnoDB: Using Linux native AIO
2019-10-06T17:46:26.222826Z 0 [Note] InnoDB: Number of pools: 1
2019-10-06T17:46:26.223065Z 0 [Note] InnoDB: Using CPU crc32 instructions
2019-10-06T17:46:26.226653Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2019-10-06T17:46:26.252532Z 0 [Note] InnoDB: Completed initialization of buffer pool
2019-10-06T17:46:26.256407Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2019-10-06T17:46:26.513071Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2019-10-06T17:46:26.876153Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-10-06T17:46:26.876952Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-10-06T17:46:27.087790Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2019-10-06T17:46:27.090624Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2019-10-06T17:46:27.090681Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2019-10-06T17:46:27.091572Z 0 [Note] InnoDB: Waiting for purge to start
2019-10-06T17:46:27.141874Z 0 [Note] InnoDB: 5.7.20 started; log sequence number 12157750
2019-10-06T17:46:27.142527Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2019-10-06T17:46:27.144054Z 0 [Note] Plugin 'FEDERATED' is disabled.
2019-10-06T17:46:27.273372Z 0 [Note] Found ca.pem, server-cert.pem and server-key.pem in data directory. Trying to enable SSL support using them.
2019-10-06T17:46:27.274157Z 0 [Warning] CA certificate ca.pem is self signed.
2019-10-06T17:46:27.278982Z 0 [Note] Server hostname (bind-address): '*'; port: 3306
2019-10-06T17:46:27.279081Z 0 [Note] IPv6 is available.
2019-10-06T17:46:27.279102Z 0 [Note]   - '::' resolves to '::';
2019-10-06T17:46:27.279152Z 0 [Note] Server socket created on IP: '::'.
2019-10-06T17:46:27.299405Z 0 [Note] InnoDB: Buffer pool(s) load completed at 191006 17:46:27
2019-10-06T17:46:27.389592Z 0 [Warning] 'user' entry 'root@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.389688Z 0 [Warning] 'user' entry 'mysql.session@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.389715Z 0 [Warning] 'user' entry 'mysql.sys@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.389821Z 0 [Warning] 'db' entry 'performance_schema mysql.session@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.389858Z 0 [Warning] 'db' entry 'sys mysql.sys@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.389916Z 0 [Warning] 'proxies_priv' entry '@ root@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.625469Z 0 [Warning] 'tables_priv' entry 'user mysql.session@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.625616Z 0 [Warning] 'tables_priv' entry 'sys_config mysql.sys@localhost' ignored in --skip-name-resolve mode.
2019-10-06T17:46:27.891880Z 0 [Note] Event Scheduler: Loaded 0 events
2019-10-06T17:46:27.892665Z 0 [Note] mysqld: ready for connections.
Version: '5.7.20'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2019-10-06T17:46:27.892707Z 0 [Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check.
2019-10-06T17:46:27.892716Z 0 [Note] Beginning of list of non-natively partitioned tables
2019-10-06T17:46:29.212350Z 0 [Note] End of list of non-natively partitioned tables
I ostatnie logi testowa_supla-server:

Kod: Zaznacz cały

INFO[1570384001.647797] Scheduler version 2.3.4
INFO[1570384001.647968] Started at Sun Oct  6 17:46:41 2019
ERR[1570384001.710933] MySQL - Failed to connect to database.
ERR[1570384001.710959] Can't connect to database!
2019-10-06 17:46:41,712 INFO exited: supla-scheduler (exit status 1; not expected)
2019-10-06 17:46:43,717 INFO spawned: 'supla-server' with pid 17
INFO[1570384003.733984] Server version 2.3.13 [Protocol v10]
INFO[1570384003.734133] Started at Sun Oct  6 17:46:43 2019
ERR[1570384003.795289] MySQL - Failed to connect to database.
ERR[1570384003.795311] Can't connect to database!
2019-10-06 17:46:43,796 INFO exited: supla-server (exit status 1; not expected)
2019-10-06 17:46:44,799 INFO spawned: 'supla-scheduler' with pid 18
2019-10-06 17:46:44,800 INFO gave up: supla-server entered FATAL state, too many start retries too quickly
INFO[1570384004.814121] Scheduler version 2.3.4
INFO[1570384004.814264] Started at Sun Oct  6 17:46:44 2019
ERR[1570384004.886694] MySQL - Failed to connect to database.
ERR[1570384004.886719] Can't connect to database!
2019-10-06 17:46:44,887 INFO exited: supla-scheduler (exit status 1; not expected)
2019-10-06 17:46:45,889 INFO gave up: supla-scheduler entered FATAL state, too many start retries too quickly
W tym miejscu ugrzązłem, nie wiem co dalej ...
Awatar użytkownika
lesny8
Posty: 2808
Rejestracja: pn gru 11, 2017 9:43 pm

Coś przekombinowałeś ;)
Zmiana nazwy projektu wystarczy, a w trybie stndalone jeszcze porty trzeba inne wybrać dla chmury i serwera i tyle. U mnie działa od kilku minut, sam zobacz

Kod: Zaznacz cały

 docker ps
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS                                            NAMES
9da5bb40332e        supla/supla-server   "/usr/bin/server-ent…"   12 minutes ago      Up 12 minutes       0.0.0.0:2017->2015/tcp, 0.0.0.0:2018->2016/tcp   supla2-server
85111cf18023        supla/supla-cloud    "docker-php-entrypoi…"   13 minutes ago      Up 13 minutes       0.0.0.0:82->80/tcp, 0.0.0.0:442->443/tcp         supla2-cloud
2c0ae662ef1f        mysql:5.7.20         "docker-entrypoint.s…"   13 minutes ago      Up 13 minutes       3306/tcp                                         supla2-db
0bf449fedf32        supla/supla-server   "/usr/bin/server-ent…"   17 minutes ago      Up 17 minutes       0.0.0.0:2015-2016->2015-2016/tcp                 supla-server
2438a278ee36        supla/supla-cloud    "docker-php-entrypoi…"   17 minutes ago      Up 17 minutes       0.0.0.0:81->80/tcp, 0.0.0.0:444->443/tcp         supla-cloud
b6867f461db1        mysql:5.7.20         "docker-entrypoint.s…"   17 minutes ago      Up 17 minutes       3306/tcp                                         supla-db
Czekam na kolejne Supla Offline Party 👍
_aro_
Posty: 51
Rejestracja: pn kwie 09, 2018 5:10 pm
Lokalizacja: Legnica

Ok, zagalopowałem się :lol:

Widzę rzeczywiście że u ciebie bez problemów to biega. Też bym tak chciał :D
Mam jakiś wydaje mi się problem już na etapie uruchamiania skryptu

Kod: Zaznacz cały

sudo ./supla.sh start
Miałem ten problem od początku swojej przygody z suplą viewtopic.php?p=36636#p36636
Jeśli robię zupełnie czystą instalację, to też mam tą sytuację że kontener supls-cloud się restartuje w kółko...
Restartuję suplę ze skryptu ./supla.sh ponownie i ponownie i za którymś razem zaczyna to działać.
Miałem postawiony serwer już kilka miesięcy i działał znakomicie.
Ale też zauważyłem, że po restarcie mojego Synology supla się nie podnosiła - dorobiłem skrypt, który 5 minut po restarcie hosta restartował kontener supla-server. I wtedy wszystko poprawnie działało.
To może być to samo co wtedy viewtopic.php?p=36801#p36801
Kolega fracz pytał się wtedy jak to możliwe że zgubiłem hasło do bazy danych - ale ja nie robiłem nic poza wpisaniem swoich danych do wygenerowanego pliku .env, zapisaniu go i uruchomieniu polecenia

Kod: Zaznacz cały

sudo ./supla.sh start
Jak pisałem już wtedy skrypt zgłasza problem z nieistniejącymi katalogami, ale dlaczego ?
Może tutaj popełniam jakiś błąd ? Ale nie widzę gdzie - to są proste rzeczy przecież.
Może prawa własności do plików/katalogów lub uprawnienia ?
Jeszcze raz - mój host to Synology DS716+, docker i wersja poniżej

Kod: Zaznacz cały

docker -v && docker-compose -v
Docker version 18.09.8, build 2c0a67b
docker-compose version 1.24.0, build 0aa59064
Działam przez ssh z użytkownika arek

Kod: Zaznacz cały

uid=1026(arek) gid=100(users) groups=100(users),101(administrators)
Katalog /volume1/docker jest własnością root:root, ale wszystkie foldery współdzielone (tak się tu nazywają wystawione katalogi z określonymi prawami dostępu) mają takiego właściciela. W samym folderze /volume1/docker mam masę innych folderów, wszystkie z właścicielem arek:users
Wiem, że Synology to poobcinany linux, ale docker chyba jest taki sam ...
_aro_
Posty: 51
Rejestracja: pn kwie 09, 2018 5:10 pm
Lokalizacja: Legnica

Temat nie umarł :D

Oczywiście był to problem z właściwymi uprawnieniami dla konkretnego użytkownika, do plików i folderów. Czyli to co stwarza najczęściej problemy w Linuxie :D
Kontynuując, udało mi się postawić z boku jeszcze jedną instancję. Kontenery wyglądają tak:

Kod: Zaznacz cały

CONTAINER ID        IMAGE                      COMMAND                   CREATED             STATUS              PORTS                                                                NAMES
33683dcc7a33        supla/supla-server         "/usr/bin/server-ent…"    10 hours ago        Up 10 hours         0.0.0.0:2013->2015/tcp, 0.0.0.0:2014->2016/tcp                       test_supla-server
a5b937be97bd        supla/supla-cloud          "docker-php-entrypoi…"    10 hours ago        Up 10 hours         0.0.0.0:8082->80/tcp, 0.0.0.0:4445->443/tcp                          test_supla-cloud
7469355f466a        mysql:5.7.20               "docker-entrypoint.s…"    10 hours ago        Up 10 hours         3306/tcp                                                             test_supla-db
6ef15a17758a        supla/supla-server         "/usr/bin/server-ent…"    34 hours ago        Up 34 hours         0.0.0.0:2015-2016->2015-2016/tcp                                     supla-server
5f614d8ed8c8        supla/supla-cloud          "docker-php-entrypoi…"    34 hours ago        Up 34 hours         0.0.0.0:8080->80/tcp, 0.0.0.0:4443->443/tcp                          supla-cloud
d8bf0b6c0517        mysql:5.7.20               "docker-entrypoint.s…"    34 hours ago        Up 34 hours         3306/tcp                                                             supla-db
Żeby łatwiej się odnaleźć nazwijmy te dwie instancje jako podstawowa i testowa. Podstawowy serwer www działa na jednej subdomenie. Testowy serwer działa na drugiej subdomenie.
Obydwie strony www śmigają, można się zalogować, wszystko OK.
I tu się robi dziwnie - o ile w podstawowej instancji bez problemu można zarejestrować urządzenie (moduł), smartfon i działa apka mobilna tak jak należy to w testowej już nie :o
Na routerze od początku mam otwarte porty 80, 443, 2015 i 2016. Tak samo w firewallu Synology. Wyłączenie firewalla zresztą nie robi różnicy. Jak pisałem wszystko po stronie serwera podstawowego działa właściwie.
Jak widać obydwa serwery działają na tych samych portach, ale w Synology wykorzystuję wewnętrzny serwer reverse proxy dla tych dwóch subdomen.
Jak pisałem obydwa serwery www od strony LAN-u i WAN-u działają OK, ale w tym drugim moduły się nie łączą z serwerem w sieci LAN, apka mobilna na smartfonie nie działa - nie można się zalogować po przepisaniu właściwych danych z działającego serwera ze strony www - zgłasza "Błędne poświadczenia", a na pewno nie są błędne.
Dziwne, ale prawdziwe :?
I dlaczego ja :lol:
Awatar użytkownika
lesny8
Posty: 2808
Rejestracja: pn gru 11, 2017 9:43 pm

Nie wiem czy problemem nie jest to, że dla instancji testowej są inne porty niż standardowe 2015, 2016 które to chyba zaszyte są w protokole :roll:
O ile udało się dwie instancje uruchomić, to podłączenie klienta do tej ze zmienionymi portami może być niemożliwe, chyba że skompilujesz sobie soft dla modułów ze zmodyfikowanym protokołem o te porty. Apkę na andka też. Robi się z tego rzeźba ;)

Na logikę, to jak postawisz wszystko za proxy, to powinno działać. W klientach, nie możesz wtedy używać adresów IP tylko nazwy subdomen.
Czekam na kolejne Supla Offline Party 👍
_aro_
Posty: 51
Rejestracja: pn kwie 09, 2018 5:10 pm
Lokalizacja: Legnica

Właśnie też widzę, że te porty są jakieś lewe:

supla-server
supla-server.png
supla-server.png (48.42 KiB) Przejrzano 4124 razy
test-supla-server
test-supla-server.png
test-supla-server.png (48.25 KiB) Przejrzano 4124 razy
No właśnie na logikę powinno działać, skoro i tak posługuję się nazwami domenowymi a nie numerem IP.
Reverse proxy miał to tak właśnie ogarniać a coś nie bardzo.
Przed chwilą sprawdziłem - zatrzymałem test-supla-server, zmieniłem te porty w pliku docker-compose.yml tak jak było czyli z aktualnych

ports:
- "2014:2016"
- "2013:2015"

na oryginalne, czyli
ports:
- "2016:2016"
- "2015:2015"
i oczywiście wszystko poszło od strzała - klienci się rejestrują, smartfon się rejestruje - tak jak powinno być ...
test-supla-server-2.png
test-supla-server-2.png (49.89 KiB) Przejrzano 4124 razy
Jakieś pomysły ?

Teraz tylko jak to pogodzić
ODPOWIEDZ

Wróć do „FAQ / Jak to zrobić”