🚀 go-pugleaf

Jest Wed, 8 Mar 2023 15:15:30 +0100, Krystek pisze:
> Loguję się na serwer Debian zainstalowany na jednej maszynie wirtualnej 
> VMware. Został tam zainstalowany - nie przeze mnie - Docker z kontenerem 
> dla Mattermosta. Wczoraj musiałem ten serwer wyłączyć, ze względu na 
> długie wyłączenie prądu w budynku, w którym znajduje się maszyna.
> Zanim zrobiłem shutdown od osoby, która instalowała Dockera dostałem 
> informację, by wpierw - po wejściu jako root do folderu 
> /opt/mattermost/docker/ zatrzymać kontener z Mattermostem komendą: sudo 
> docker compose -f docker-compose.yml -f docker-compose.nginx.yml down
>
> Dzisiaj, po ponownym uruchomieniu maszyny VM z Mattermostem na hoście 
> VMware ESXi musiałem ręcznie podnieść kontener z Dockerem Mattermosta. 
> Tej komendy już mi instalujący Mattermosta nie przekazał ;)
> Zadziałało wpisane z palca polecenie sudo docker compose -f 
> docker-compose.yml -f docker-compose.nginx.yml up --detach

Bywa. :) 

> Chciałbym zautomatyzować ten proces przy uruchamianiu systemu i zacząłem 
> szukać jak to zrobić, bo w tematach Linuksowych nie jestem jakimś 
> ekspertem. Udało mi się wyGoogle'ać, że do tego celu nadawałoby się 
> stworzenie pliku rc.local w folderze /etc i tam wpisanie komendy 
> uruchomieniowej.
> Do pliku rc.local wpisałem następujce rzeczy:

[ … ]

Skoro Docker Ci wstaje to takie kombinacje są zbędne. W plikach
docker-compose.*.yml musisz (w odpowiednim miejscu) dodać dyrektywę
„restart:”. Nie wiem jak wyglądają Twoje pliki compose i w jakiej są
wersji, ale np coś takiego:
#v+
services:
  nazwaserwisu:
    volumes:
      [ … ]
    restart: unless-stopped
#v-
https://github.com/compose-spec/compose-spec/blob/master/spec.md#restart

Jeżeli instalujący nie zastawił na Ciebie kolejnych pułapek, to powinno
zadziałać i kontenery uruchomią się samoczynnie po restarcie.

      k.
-- 
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg

W dniu 08.03.2023 o 15:43, Krzysztof Gajdemski pisze:
> Jest Wed, 8 Mar 2023 15:15:30 +0100, Krystek pisze:
>> Loguję się na serwer Debian zainstalowany na jednej maszynie wirtualnej
>> VMware. Został tam zainstalowany - nie przeze mnie - Docker z kontenerem
>> dla Mattermosta. Wczoraj musiałem ten serwer wyłączyć, ze względu na
>> długie wyłączenie prądu w budynku, w którym znajduje się maszyna.
>> Zanim zrobiłem shutdown od osoby, która instalowała Dockera dostałem
>> informację, by wpierw - po wejściu jako root do folderu
>> /opt/mattermost/docker/ zatrzymać kontener z Mattermostem komendą: sudo
>> docker compose -f docker-compose.yml -f docker-compose.nginx.yml down
>>
>> Dzisiaj, po ponownym uruchomieniu maszyny VM z Mattermostem na hoście
>> VMware ESXi musiałem ręcznie podnieść kontener z Dockerem Mattermosta.
>> Tej komendy już mi instalujący Mattermosta nie przekazał ;)
>> Zadziałało wpisane z palca polecenie sudo docker compose -f
>> docker-compose.yml -f docker-compose.nginx.yml up --detach
> 
> Bywa. :)
> 
>> Chciałbym zautomatyzować ten proces przy uruchamianiu systemu i zacząłem
>> szukać jak to zrobić, bo w tematach Linuksowych nie jestem jakimś
>> ekspertem. Udało mi się wyGoogle'ać, że do tego celu nadawałoby się
>> stworzenie pliku rc.local w folderze /etc i tam wpisanie komendy
>> uruchomieniowej.
>> Do pliku rc.local wpisałem następujce rzeczy:
> 
> [ … ]
> 
> Skoro Docker Ci wstaje to takie kombinacje są zbędne. W plikach
> docker-compose.*.yml musisz (w odpowiednim miejscu) dodać dyrektywę
> „restart:”. Nie wiem jak wyglądają Twoje pliki compose i w jakiej są
> wersji, ale np coś takiego:
> #v+
> services:
>    nazwaserwisu:
>      volumes:
>        [ … ]
>      restart: unless-stopped
> #v-
> https://github.com/compose-spec/compose-spec/blob/master/spec.md#restart
> 
> Jeżeli instalujący nie zastawił na Ciebie kolejnych pułapek, to powinno
> zadziałać i kontenery uruchomią się samoczynnie po restarcie.

Gdyby kontener z Mattermostem w Dockerze wstał automagicznie po 
uruchomieniu maszyny to nie byłoby tematu i nie musiałbym ręcznie klepać 
regułek na podniesienie serwerów w kontenerze ;) OK. Zerknę do tych 
plików yml, chociaż wolałbym w nich nie grzebać, bo nie ja te kontenery 
instalowałem i uruchamiałem, ale generalnie lubię wiedzieć co się dzieje 
w systemie, szczególnie gdy innych osób odpowiedzialnych za ten serwer 
nie ma w zasięgu, a trzeba coś przy nich zrobić na cito.

Wydawało mi się, że polecenie w rc.local jest najprostszym rozwiązaniem, 
nieinwazyjnym w stosunku do Dockera. Czy gdybym nie zamykał kontenerów 
komendą to byłaby szansa, że po ponownym uruchomieniu serwera same 
wstaną (restart: unless-stopped)?

K.

-- 
Adresy e-mail w domenie art.pl, jak i sama domena nie są już aktywne

Jest Wed, 8 Mar 2023 15:55:05 +0100, Krystek pisze:
> W dniu 08.03.2023 o 15:43, Krzysztof Gajdemski pisze:
>> Jest Wed, 8 Mar 2023 15:15:30 +0100, Krystek pisze:

[ … ]
>>> Chciałbym zautomatyzować ten proces przy uruchamianiu systemu i zacząłem
>>> szukać jak to zrobić, bo w tematach Linuksowych nie jestem jakimś
>>> ekspertem. Udało mi się wyGoogle'ać, że do tego celu nadawałoby się
>>> stworzenie pliku rc.local w folderze /etc i tam wpisanie komendy
>>> uruchomieniowej.
>>> Do pliku rc.local wpisałem następujce rzeczy:
>> 
>> [ … ]
>> 
>> Skoro Docker Ci wstaje to takie kombinacje są zbędne. W plikach
>> docker-compose.*.yml musisz (w odpowiednim miejscu) dodać dyrektywę
>> „restart:”. Nie wiem jak wyglądają Twoje pliki compose i w jakiej są
>> wersji, ale np coś takiego:
>> #v+
>> services:
>>    nazwaserwisu:
>>      volumes:
>>        [ … ]
>>      restart: unless-stopped
>> #v-
>> https://github.com/compose-spec/compose-spec/blob/master/spec.md#restart
>> 
>> Jeżeli instalujący nie zastawił na Ciebie kolejnych pułapek, to powinno
>> zadziałać i kontenery uruchomią się samoczynnie po restarcie.
> Gdyby kontener z Mattermostem w Dockerze wstał automagicznie po 
> uruchomieniu maszyny to nie byłoby tematu i nie musiałbym ręcznie klepać 
> regułek na podniesienie serwerów w kontenerze ;) OK. Zerknę do tych 
> plików yml, chociaż wolałbym w nich nie grzebać, bo nie ja te kontenery 
> instalowałem i uruchamiałem,

W takiej sytuacji do dostawcy kontenerów należy skierować pismo z prośbą
o dodanie funkcjonalności automatycznego podnoszenia usług po
restaracie. :) A serio, to z niewiadomych przyczyń developerzy
dostarczający wsad w postaci obrazów i compose'a jakoś nagminnie o tym
zapominają.

> ale generalnie lubię wiedzieć co się dzieje 
> w systemie, szczególnie gdy innych osób odpowiedzialnych za ten serwer 
> nie ma w zasięgu, a trzeba coś przy nich zrobić na cito.
> Wydawało mi się, że polecenie w rc.local jest najprostszym rozwiązaniem, 
> nieinwazyjnym w stosunku do Dockera.

Ale właśnie poprawnym rozwiązaniem problemu jest dodanie dyrektywy
restartu do kontenerów. Zresztą w sytuacji gdy byłoby to niemożliwe,
prędzej dodałbym usługę do systemd podnoszącą co trzeba, niż grzebał
w rc.local.

> Czy gdybym nie zamykał kontenerów 
> komendą to byłaby szansa, że po ponownym uruchomieniu serwera same 
> wstaną (restart: unless-stopped)?

Tak, z unless-stopped by wstały, jeśli by nie były ręcznie położone.
Jest jeszcze możliwość zdefiniowania restart_policy, ale w Twoim
przypadku chyba niczego to nie zmienia:
https://github.com/compose-spec/compose-spec/blob/master/deploy.md#restart_policy

     k.
-- 
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg

W dniu 08.03.2023 o 15:43, Krzysztof Gajdemski pisze:
> Jest Wed, 8 Mar 2023 15:15:30 +0100, Krystek pisze:
>> Loguję się na serwer Debian zainstalowany na jednej maszynie wirtualnej
>> VMware. Został tam zainstalowany - nie przeze mnie - Docker z kontenerem
>> dla Mattermosta. Wczoraj musiałem ten serwer wyłączyć, ze względu na
>> długie wyłączenie prądu w budynku, w którym znajduje się maszyna.
>> Zanim zrobiłem shutdown od osoby, która instalowała Dockera dostałem
>> informację, by wpierw - po wejściu jako root do folderu
>> /opt/mattermost/docker/ zatrzymać kontener z Mattermostem komendą: sudo
>> docker compose -f docker-compose.yml -f docker-compose.nginx.yml down
>>
>> Dzisiaj, po ponownym uruchomieniu maszyny VM z Mattermostem na hoście
>> VMware ESXi musiałem ręcznie podnieść kontener z Dockerem Mattermosta.
>> Tej komendy już mi instalujący Mattermosta nie przekazał ;)
>> Zadziałało wpisane z palca polecenie sudo docker compose -f
>> docker-compose.yml -f docker-compose.nginx.yml up --detach
> 
> Bywa. :)
> 
>> Chciałbym zautomatyzować ten proces przy uruchamianiu systemu i zacząłem
>> szukać jak to zrobić, bo w tematach Linuksowych nie jestem jakimś
>> ekspertem. Udało mi się wyGoogle'ać, że do tego celu nadawałoby się
>> stworzenie pliku rc.local w folderze /etc i tam wpisanie komendy
>> uruchomieniowej.
>> Do pliku rc.local wpisałem następujce rzeczy:
> 
> [ … ]

Dziękuję za rozjaśnienie tematu plików konfiguracyjnych kontenerów 
Dockera. Chyba będę musiał w nich jednak pogrzebać. A tak swoją drogą to 
dokształcam się w temacie bezpiecznego zatrzymywania działania 
kontenerów Dockera ;) - 
<https://www.reddit.com/r/docker/comments/rxe53s/newbie_question_will_dockercontainer_be/>

A wracając do pytania  to już technikalia dla obeznanych z Linuksem, czy 
skrypt zadziała -

#!/bin/bash
/opt/mattermost/docker/sudo docker compose -f docker-compose.yml -f 
docker-compose.nginx.yml up --detach

Czy może powinienem wywalić ścieżkę /opt/mattermost/docker/ i zostawić 
samo polecenie? Zgodnie z sugestią w przypadku Dockera odpuszczę zabawę 
z rc.local, ale zależy mi na znajomości poprawnej składni (czy ze 
ścieżką folderu i komendą z sudo zadziała, czy ścieżkę folderu wywalać).

K.

-- 
Adresy e-mail w domenie art.pl, jak i sama domena nie są już aktywne

Jest Wed, 8 Mar 2023 22:25:11 +0100, Krystek pisze:
> W dniu 08.03.2023 o 15:43, Krzysztof Gajdemski pisze:
>>> Chciałbym zautomatyzować ten proces przy uruchamianiu systemu i zacząłem
>>> szukać jak to zrobić, bo w tematach Linuksowych nie jestem jakimś
>>> ekspertem. Udało mi się wyGoogle'ać, że do tego celu nadawałoby się
>>> stworzenie pliku rc.local w folderze /etc i tam wpisanie komendy
>>> uruchomieniowej.
>>> Do pliku rc.local wpisałem następujce rzeczy:
>> [ … ]
> Dziękuję za rozjaśnienie tematu plików konfiguracyjnych kontenerów 
> Dockera. Chyba będę musiał w nich jednak pogrzebać. A tak swoją drogą to 
> dokształcam się w temacie bezpiecznego zatrzymywania działania 
> kontenerów Dockera ;) - 
><https://www.reddit.com/r/docker/comments/rxe53s/newbie_question_will_dockercontainer_be/>
>

Cóż, też nie ma co przesadzać. Są aplikacje wyjątkowo czułe na takie
akcje, ale to margines. Dobrze jest dążyć do tego, żeby kontenery – jak
każda inna usługa w systemie – bezpiecznie zamykały się przy restarcie
i same podnosiły się przy starcie maszyny. Zwróć jeszcze uwagę, że
robiąc docker-compose down (tak chyba robiłeś przed restartem serwera)
nie stopujesz kontenerów, lecz je usuwasz. Wtedy docker-compose up -d
stawia je na nowo.

> A wracając do pytania  to już technikalia dla obeznanych z Linuksem, czy 
> skrypt zadziała -
> #!/bin/bash
> /opt/mattermost/docker/sudo docker compose -f docker-compose.yml -f 
> docker-compose.nginx.yml up --detach

Pliki .yml są w katalogu /opt/mattermost/docker/, czy
/opt/mattermost/docker/sudo? Obstawiam to pierwsze.

> Czy może powinienem wywalić ścieżkę /opt/mattermost/docker/ i zostawić 
> samo polecenie?
Skrypt rc.* będzie wywoływany jako root, więc sudo jest zbędne. Bash to
także overkill, wystarczy sh. Więc może coś takiego:
#v+
#!/bin/sh 
docker-compose -f /opt/mattermost/docker/docker-compose.yml \
  -f /opt/mattermost/docker/docker-compose.nginx.yml up -d
#v-

Jeśli to nowy Docker to zamiast „docker-compose” będzie „docker
compose”. Piszesz dwojako, więc ciężko stwierdzić.

> Zgodnie z sugestią w przypadku Dockera odpuszczę zabawę 
> z rc.local,

Nie przekonałeś mnie. :) Licz się z tym, że w miarę nowym Debianie
rc.local i tak może się nie wykonać, jeśli nie uaktywnisz najpierw
usługi rc-local.service… W Linuksie niemal zawsze jest lepsza metoda na
uruchomienie usługi, niż korzystanie z rc.local. Naprawdę odradzam.

> ale zależy mi na znajomości poprawnej składni (czy ze 
> ścieżką folderu i komendą z sudo zadziała, czy ścieżkę folderu wywalać).

Jak wspomniałem sudo jest zbędne, bo polecenie będzie wykonywane
z uprawnieniami roota.

      k.
-- 
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg

W dniu 09.03.2023 o 00:19, Krzysztof Gajdemski pisze:
> Jest Wed, 8 Mar 2023 22:25:11 +0100, Krystek pisze:
>> W dniu 08.03.2023 o 15:43, Krzysztof Gajdemski pisze:
>>>> Chciałbym zautomatyzować ten proces przy uruchamianiu systemu i zacząłem
>>>> szukać jak to zrobić, bo w tematach Linuksowych nie jestem jakimś
>>>> ekspertem. Udało mi się wyGoogle'ać, że do tego celu nadawałoby się
>>>> stworzenie pliku rc.local w folderze /etc i tam wpisanie komendy
>>>> uruchomieniowej.
>>>> Do pliku rc.local wpisałem następujce rzeczy:
>>> [ … ]
>> Dziękuję za rozjaśnienie tematu plików konfiguracyjnych kontenerów
>> Dockera. Chyba będę musiał w nich jednak pogrzebać. A tak swoją drogą to
>> dokształcam się w temacie bezpiecznego zatrzymywania działania
>> kontenerów Dockera ;) -
>> <https://www.reddit.com/r/docker/comments/rxe53s/newbie_question_will_dockercontainer_be/>
>>
> 
> Cóż, też nie ma co przesadzać. Są aplikacje wyjątkowo czułe na takie
> akcje, ale to margines. Dobrze jest dążyć do tego, żeby kontenery – jak
> każda inna usługa w systemie – bezpiecznie zamykały się przy restarcie
> i same podnosiły się przy starcie maszyny. Zwróć jeszcze uwagę, że
> robiąc docker-compose down (tak chyba robiłeś przed restartem serwera)
> nie stopujesz kontenerów, lecz je usuwasz. Wtedy docker-compose up -d
> stawia je na nowo.

OK. Czyli tak naprawdę to osoba, która stawiała te kontenery dla 
Mattermosta powinna mi przesłać komendę, która zawiera słowo "stop" - 
<https://docs.docker.com/engine/reference/commandline/compose_stop/>, a 
nie "down"? I zamiast "up", powinno być "start"?

Tak: docker compose -f docker-compose.yml -f docker-compose.nginx.yml 
start --detach

>> A wracając do pytania  to już technikalia dla obeznanych z Linuksem, czy
>> skrypt zadziała -
>> #!/bin/bash
>> /opt/mattermost/docker/sudo docker compose -f docker-compose.yml -f
>> docker-compose.nginx.yml up --detach
> 
> Pliki .yml są w katalogu /opt/mattermost/docker/, czy
> /opt/mattermost/docker/sudo? Obstawiam to pierwsze.

A, jasne. Żeby nie potraktował słowa sudo jako folderu ze ścieżki.

>> Czy może powinienem wywalić ścieżkę /opt/mattermost/docker/ i zostawić
>> samo polecenie?
>
> Skrypt rc.* będzie wywoływany jako root, więc sudo jest zbędne. Bash to
> także overkill, wystarczy sh. Więc może coś takiego:
>
> #v+
> #!/bin/sh
> docker-compose -f /opt/mattermost/docker/docker-compose.yml \
>    -f /opt/mattermost/docker/docker-compose.nginx.yml up -d
> #v-
> 
> Jeśli to nowy Docker to zamiast „docker-compose” będzie „docker
> compose”. Piszesz dwojako, więc ciężko stwierdzić.

Yyy. "Minusy" są tylko w nazwach plików z .yml: docker-compose.yml oraz 
docker-compose.nginx.yml

Tam jest nowa wersja Dockera, bo nie działa np. skrót -d w komendach, a 
działa --detach.

>> Zgodnie z sugestią w przypadku Dockera odpuszczę zabawę
>> z rc.local,
> 
> Nie przekonałeś mnie. :) Licz się z tym, że w miarę nowym Debianie
> rc.local i tak może się nie wykonać, jeśli nie uaktywnisz najpierw
> usługi rc-local.service… W Linuksie niemal zawsze jest lepsza metoda na
> uruchomienie usługi, niż korzystanie z rc.local. Naprawdę odradzam.
> 
>> ale zależy mi na znajomości poprawnej składni (czy ze
>> ścieżką folderu i komendą z sudo zadziała, czy ścieżkę folderu wywalać).
> 
> Jak wspomniałem sudo jest zbędne, bo polecenie będzie wykonywane
> z uprawnieniami roota.

No tak. sudo to z rozpędu :)

K.

-- 
Adresy e-mail w domenie art.pl, jak i sama domena nie są już aktywne

Jest Thu, 9 Mar 2023 11:20:55 +0100, Krystek pisze:
> W dniu 09.03.2023 o 00:19, Krzysztof Gajdemski pisze:
>> Jest Wed, 8 Mar 2023 22:25:11 +0100, Krystek pisze:
>>> W dniu 08.03.2023 o 15:43, Krzysztof Gajdemski pisze:
>>>>> Do pliku rc.local wpisałem następujce rzeczy:
>>>> [ … ]
>>> Dziękuję za rozjaśnienie tematu plików konfiguracyjnych kontenerów
>>> Dockera. Chyba będę musiał w nich jednak pogrzebać. A tak swoją drogą to
>>> dokształcam się w temacie bezpiecznego zatrzymywania działania
>>> kontenerów Dockera ;) -
>>> <https://www.reddit.com/r/docker/comments/rxe53s/newbie_question_will_dockercontainer_be/>
>> Cóż, też nie ma co przesadzać. Są aplikacje wyjątkowo czułe na takie
>> akcje, ale to margines. Dobrze jest dążyć do tego, żeby kontenery – jak
>> każda inna usługa w systemie – bezpiecznie zamykały się przy restarcie
>> i same podnosiły się przy starcie maszyny. Zwróć jeszcze uwagę, że
>> robiąc docker-compose down (tak chyba robiłeś przed restartem serwera)
>> nie stopujesz kontenerów, lecz je usuwasz. Wtedy docker-compose up -d
>> stawia je na nowo.
> OK. Czyli tak naprawdę to osoba, która stawiała te kontenery dla 
> Mattermosta powinna mi przesłać komendę, która zawiera słowo "stop" - 
><https://docs.docker.com/engine/reference/commandline/compose_stop/>, a 
> nie "down"? I zamiast "up", powinno być "start"?
> Tak: docker compose -f docker-compose.yml -f docker-compose.nginx.yml 
> start --detach

Tak, tylko wiesz, to by trzeba zapytać tę osobę w jakim celu wykonywana
jest ręcznie ta cała operacja. I dlaczego w taki sposób. 

>>> Czy może powinienem wywalić ścieżkę /opt/mattermost/docker/ i zostawić
>>> samo polecenie?
>>
>> Skrypt rc.* będzie wywoływany jako root, więc sudo jest zbędne. Bash to
>> także overkill, wystarczy sh. Więc może coś takiego:
>>
>> #v+
>> #!/bin/sh
>> docker-compose -f /opt/mattermost/docker/docker-compose.yml \
>>    -f /opt/mattermost/docker/docker-compose.nginx.yml up -d
>> #v-
>> Jeśli to nowy Docker to zamiast „docker-compose” będzie „docker
>> compose”. Piszesz dwojako, więc ciężko stwierdzić.
> Yyy. "Minusy" są tylko w nazwach plików z .yml: docker-compose.yml oraz 
> docker-compose.nginx.yml

OK. Od jakiegoś czasu compose został dodany do Dockera w formie plugina,
jako jedna z jego komend. Korzysta się z niego tak samo, tylko zamiast
binarki docker-compose, używa się cli dockera (stąd brak „-”).

> Tam jest nowa wersja Dockera, bo nie działa np. skrót -d w komendach, a 
> działa --detach.

A to ciekawe co piszesz. Np. u mnie (Ubuntu 20.04, docker-ce 23.0.1) działa:
#v+
songo@s50019:~$ docker compose version
Docker Compose version v2.16.0

songo@s50019:~$ docker compose up --help | grep -- --detach
  -d, --detach                    Detached mode: Run containers in the background
#v-

      k.
-- 
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg

W dniu 09.03.2023 o 15:20, Krzysztof Gajdemski pisze:
> Jest Thu, 9 Mar 2023 11:20:55 +0100, Krystek pisze:
>> W dniu 09.03.2023 o 00:19, Krzysztof Gajdemski pisze:
>>> Jest Wed, 8 Mar 2023 22:25:11 +0100, Krystek pisze:
>>>> W dniu 08.03.2023 o 15:43, Krzysztof Gajdemski pisze:
>>>>>> Do pliku rc.local wpisałem następujce rzeczy:
>>>>> [ … ]
>>>> Dziękuję za rozjaśnienie tematu plików konfiguracyjnych kontenerów
>>>> Dockera. Chyba będę musiał w nich jednak pogrzebać. A tak swoją drogą to
>>>> dokształcam się w temacie bezpiecznego zatrzymywania działania
>>>> kontenerów Dockera ;) -
>>>> <https://www.reddit.com/r/docker/comments/rxe53s/newbie_question_will_dockercontainer_be/>
>>> Cóż, też nie ma co przesadzać. Są aplikacje wyjątkowo czułe na takie
>>> akcje, ale to margines. Dobrze jest dążyć do tego, żeby kontenery – jak
>>> każda inna usługa w systemie – bezpiecznie zamykały się przy restarcie
>>> i same podnosiły się przy starcie maszyny. Zwróć jeszcze uwagę, że
>>> robiąc docker-compose down (tak chyba robiłeś przed restartem serwera)
>>> nie stopujesz kontenerów, lecz je usuwasz. Wtedy docker-compose up -d
>>> stawia je na nowo.
>> OK. Czyli tak naprawdę to osoba, która stawiała te kontenery dla
>> Mattermosta powinna mi przesłać komendę, która zawiera słowo "stop" -
>> <https://docs.docker.com/engine/reference/commandline/compose_stop/>, a
>> nie "down"? I zamiast "up", powinno być "start"?
>> Tak: docker compose -f docker-compose.yml -f docker-compose.nginx.yml
>> start --detach
> 
> Tak, tylko wiesz, to by trzeba zapytać tę osobę w jakim celu wykonywana
> jest ręcznie ta cała operacja. I dlaczego w taki sposób.

Zapytam dlaczego i w jaki sposób. Niech no tylko wróci z urlopu :)

>> Tam jest nowa wersja Dockera, bo nie działa np. skrót -d w komendach, a
>> działa --detach.
> 
> A to ciekawe co piszesz. Np. u mnie (Ubuntu 20.04, docker-ce 23.0.1) działa:
> #v+
> songo@s50019:~$ docker compose version
> Docker Compose version v2.16.0
> 
> songo@s50019:~$ docker compose up --help | grep -- --detach
>    -d, --detach                    Detached mode: Run containers in the background
> #v-

Tutaj jest Docker Compose version v2.15.1, ale już głębiej chyba nie 
będę wnikał co jest z tym nie tak. Ważne, że udało się kontenery 
podnieść i usługi - znaczy Mattermost z przyległościami w postaci 
nginx-a - działają.

Dziękuję za wszelkie wskazówki przesłane do tej pory.

K.

-- 
Adresy e-mail w domenie art.pl, jak i sama domena nie są już aktywne