Zostanie dodany nowy plik docker-compose.yaml zawierający jeden kontener z redisem.
Należy go wgrać i uruchomić komendą docker-compose up na pojedynczym node middleware (tam gdzie mamy mongo, rabbit). Na ten moment redis nie będzie klastrowany.
​
Redis zostnie usunięty ze stacka aplikacyjnego.
Wartość zmiennej REDIS_CONNECTIONSTRING będzie musiała zostać zmieniona zgodnie z konwencją <redisHost>:<redisPort>,abortConnect=false gdzie redis host to pojedynczy node middleware, na który został wgrany docker-compose z redisem. Domyślny port redisa to 6379.
​
Należy zadbać o dostępność sieciową <redisPort> z hostów aplikacyjnych do <redisHost>.

Od wersji 3.9 dostawca obrazu zrezygnował z możliwości konfiguracji poprzez zmienne środowiskowe na rzecz dedykowanego pliku konfiguracyjnego.

Nie będzie możliwe przekazywanie obecnie wykorzystywanych parametrów takich jak:
RABBITMQ_ERLANG_COOKIE,
RABBITMQ_DEFAULT_USER,
RABBITMQ_DEFAULT_PASS

Więcej informacji można znaleźć na: https://hub.docker.com/_/rabbitmq
​
Obecnie w docker-compose.yaml serwisu Rabbit, obraz ma następujący tag: rabbitmq: 3-management

Istnieje ryzyko przypadkowego podbicia wersji do 3.9 w sytuacji korzystania z publicznego repozytorium obrazów.
Tag 3-management obecnie wskazuje na wersję 3.9
W celu uniknięcia powyższej sytuacji należy podać pełną wersję obrazu serwisu rabbitmq, starszej niż 3.9, np.
image: rabbitmq:3.8-management
image: rabbitmq:3.7-management

Aby upewnić się, który z tagów powinien być użyty należy sprawdzić obecną wersję serwisu rabbitmq. Można to zrobić z panelu management wystawianego na porcie 15672:
​
​

Przykładowo dla wersji 3.7.16 ustawiamy
image: rabbitmq:3.7-management
lub image: rabbitmq:3.7.16-management

jeżeli zależy nam na dokładnym odzwierciedleniu. Ze względu na zmianę sposobu konfiguracji podniesienie wersji rabbitMQ do 3.9 będzie wymagało testów. Dodanie zostanie wtedy również konfiguracja zachowania klastra w wypadku desynchronizacji.

Instrukcja Mongo dump i restore – ondemand
​
​

Skrypt mongo_dump_ondemand.sh:

#!/bin/bash

mongo_dump () {

mongo_cont_id=$(docker ps | awk '{if(NR>1) print $NF}' | grep $1)

docker exec $mongo_cont_id bash -c "mongodump --username $3 --password $4 --archive=/dump.gz --gzip"

docker cp $mongo_cont_id:/dump.gz $2

}

mongo_restore () {

mongo_cont_id=$(docker ps | awk '{if(NR>1) print $NF}' | grep $1)

docker cp $2 $mongo_cont_id:/dump.gz

docker exec $mongo_cont_id bash -c "mongorestore --username $3 --password $4 --archive=/dump.gz --gzip"

}

"$@"
​
​
​

Use case:

Skrypt należy wykonać na hoście mongo. Skrypt przyjmuje konieczne parametry:

$1 = mongo_dump albo mongo_restore

$2 = nazwa serwisu, można sprawdzic poleceniem docker ps, nie musi być pełna nazwa, np. mongo

$3 = ścieżka do pliku na hoście dockera z archiwum mongodump

$4 = login do bazy mongo

$5 = haslo do bazy mongo
​
​

Przykład:
1. Backup wszystkich baz mongo

bash mongo_dump_ondemand.sh mongo_dump mongo <ścieżka-do-pliku.gz> <login> <haslo>

Polecenie utworzy plik archiwum w ścieżce <ścieżka-do-pliku.gz>, np ./dump.gz, który będzie zawierał całkowity backup bazy. Wykonanie może chwilę potrwać.

2. Odtworzenie bazy z backupu mongodump

bash mongo_dump_ondemand.sh mongo_restore mongo <ścieżka-do-pliku.gz> <login> <haslo>