Celem dzisiejszego artykułu, będzie szybkie i praktyczne przybliżenie idei wprowadzenia konteneryzacji na serwerach bazodanowych.
1. Tworzenie konfiguracji
Na samym początku tworzymy katalog o nazwie Mysql-docker-compose a w nim poniższy plik:
Mysql-docker-compose/docker-compose.yml
version: '3.3'
volumes:
db-data:
driver: local
services:
db-mysql:
container_name: db-mysql
image: mysql:${MYSQL_VERSION}
command: --default-authentication-plugin=mysql_native_password
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${ADMIN_PASSWORD}
ports:
- ${MYSQL_PORT}:3306
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-u", "root", "--password=${ADMIN_PASSWORD}"]
interval: 10s
timeout: 5s
retries: 5
volumes:
- ./.docker/mysql-conf:/etc/mysql/conf.d
- ./.docker/mysql-init:/docker-entrypoint-initdb.d
- db-data:/var/lib/mysql
Do którego dołączamy plik z zmiennymi środowiskowymi, za pomocą których ustalimy hasło administratora oraz port serwera:
Mysql-docker-compose/.env
ADMIN_PASSWORD=mega_haslo
MYSQL_PORT=13306
MYSQL_VERSION=8.0.19
Celem wprowadzenia własnej konfiguracji serwera, tworzymy dodatkowo plik:
Mysql-docker-compose/.docker/mysql-conf/my-custom.cnf
[mysqld]
lc_messages=pl_PL
lc_time_names=pl_PL
collation_server=utf8_polish_ci
character_set_server=utf8
max_connections = 900
wait_timeout=240
interactive_timeout=240
skip-name-resolve=1
log_error_verbosity=1
Dodatkowo możemy stworzyć własny własny plik startowy, który wykona się za każdym razem gdy stworzymy na nowo kontener z pustym volumenem.
Mysql-docker-compose/.docker/mysql-init/0_init.sql
CREATE USER '<user>'@'%' IDENTIFIED BY '<password>';
GRANT EXECUTE, PROCESS, SELECT, SHOW DATABASES, SHOW VIEW, ALTER, ALTER ROUTINE, CREATE, CREATE ROUTINE, CREATE TABLESPACE, CREATE TEMPORARY TABLES, CREATE VIEW, DELETE, DROP, EVENT, INDEX, INSERT, REFERENCES, TRIGGER, UPDATE, CREATE USER, FILE, LOCK TABLES, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '<user>'@'%';
FLUSH PRIVILEGES;
Następnie uruchamiamy kontener w tle po przez:
docker-compose --project-name "projekt1" up -d
2. Pierwsze uruchomienie
Krótka ściągawka:
Do samego kontenera możemy wejść po przez (container name otrzymujemy z docker ps)
docker exec -it <container name> /bin/bash
Wyłączenie całej bazy następuje po:
docker-compose down
Z kolei wyłączenie oraz usunięcie lokalnych zmian (czyli plików bazy danych) następuje po wykonaniu:
docker-compose down --volume
Dość ciekawą opcją jest możliwość przetestowania samego działania danej usługi, po przez sprawdzenie wyniku polecenia healthcheck z pliku docker-compose. Przykład poniżej:
docker inspect --format "{{json .State.Health }}" db-dev | jq
W przypadku gdy usługa działa otrzymujemy:
{
"Start": "2022-12-13T16:16:51.237577184+01:00",
"End": "2022-12-13T16:16:51.333164898+01:00",
"ExitCode": 0,
"Output": "mysqld is alive\n"
},
oraz gdy kontener działa ale sama usługa się zatrzymała.
{
"Start": "2022-12-13T16:05:23.882706503+01:00",
"End": "2022-12-13T16:05:24.471926966+01:00",
"ExitCode": 1,
"Output": "mysqladmin: connect to server at 'localhost' failed\nerror: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'\nCheck that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!\n"
},
3. Nim ruszymy dalej...
...pamiętaj o backupie
Chcąc wykonać backup samych danych musi wykonać metodę na około. Stworzymy nowy kontener bazujący np na ubuntu, do którego podmontujemy volumen, z którego wyjmiemy pliki. Poniższy skrypt przedstawia koncept:
make_backup.sh
#/bin/bash
now=$(date +"%Y-%m-%dT%H:%M:%SZ")
echo "Acutal date $now"
echo "Remove old files"
rm -rf backup
echo "Create new folder"
mkdir backup
echo "Making backup"
docker run -v test_db-dev-data:/var/lib/mysql ubuntu tar cf - -C /var/lib/mysql . > backupy/mysql_$now.tar
*Nazwa test_db-dev-data jest tylko poglądowa, w przypadku zmiany pliku docker-compose, należy sprawdzić nazwę volumenu poleceniem:
docker volume ls
Zapytasz się pewnie, dlaczego od razu nie podmontujemy danych do lokalnego folderu serwera. Powody są dwa, użycie wolumenów dramatycznie zwiększa prędkość działań oraz volumeny pozwalają na większą elastyczność gdy chcemy równolegle uruchomić wiele instancji...
Komentarze