Relacyjne bazy danych - laboratorium 9 - dodatkowe

Wprowadzenie

Poniżej podany skrypt jest dodatkowym nadprogramowym rozwinięciem tematu zarządzania skryptami SQL bazy danych. Podczas całego semestru jednym z zadań było zapisywanie przygotowanych oraz działających skryptów do plików oraz publikowanie ich do repozytorium GIT. Miało to na celu przybliżenie pojęcia procesu tzw. migracji. Na zajęciach poznamy jednen z popularniejszych narzędzi do operowania nad migracjami (zwłaszcza w świecie Javy), którym jest Flyway, całą integracje oraz uruchamianie migracji oraz bazy danych, zautomatyzujemy przy pomocy docker-compose.

Migracja

Migracje bazo danowe, jest to ciągły przyrostowy proces aplikowania modyfikacji struktur bazo danowych. Ich celem jest sprawienie by zmiany w bazach danych były powtarzalne, możliwe do udostępniania i testowania bez utraty danych. Upraszczając, oprogramowanie do migracji tworzy artefakty, które opisują dokładny zestaw operacji wymaganych do przekształcenia bazy danych ze znanego stanu do nowego stanu. Mogą one być sprawdzane i zarządzane przez zwykłe oprogramowanie do kontroli wersji (GIT) w celu śledzenia zmian i udostępniania ich członkom zespołu (1)

Konfiguracja

Na potrzeby przykładu posłuszmy się nową bazą danych, dla której w dalszej cześci przygotujemy nowe skrypty. Zacznijmy najpierw jednak od konfiguracji. Utwórz w jakim kolwiek miejscu folder migrations, a w nim dodaj foldery sql oraz flyway. W głównym katalogu stwórz na razie pusty plik docker-compose.yml. Struktura folderów powinna wyglądac następująco:

migrations -> docker-compose.yml
          |
           -> flyway
          |
           -> sql

Przejdźdmy do docker-compose.yml. Docker compose to narzędzie do definiowania i uruchamiania multi-kontenerowych zdockeryzowanych aplikacji. Jego konfiguracje zapisujemy w pliku o rozszerzeniu .yml - YAML. Za pomocą jednego polecenia można stworzyc i uruchomić wszystkie serwisy zawarte w konfiguracji, które mogą od siebie wzajemnie zależec.

Konfiguracja docker-compose dla naszej automatyzacji migracji powinna wyglądac następująco:

services:
  flyway:
    image: flyway/flyway:latest
    command: migrate -connectRetries=60 -configFiles=/flyway/conf/flyway.config -locations=filesystem:/flyway/sql
    volumes:
      - ./sql:/flyway/sql
      - ./flyway/flyway.config:/flyway/conf/flyway.config
    depends_on:
      - database
  database:
    image: postgres:latest
    ports:
    - "5432:5432"
    environment:
    - POSTGRES_USER=lele
    - POSTGRES_PASSWORD=lele
    - POSTGRES_DB=sales

Przejdźmy teraz po kolei co oznaczają poszczególne linijki w wyżej zademonstrowanej konfiguracji:

• services - obowiązkowe pole pod którym definiowane są serwisy działące pod jednym docker-compose
• flyway - nazwa serwisu, pod którym konfigurowany będzie obraz flyway’a
• image - obraz serwisu z którego będziemy korzysta (w tym przypadku flyway)
• command - inicjalna komenda, która zostanie wywołana wraz z uruchomieniem kontenera z obrazem flyway’a. Jej składnia migrate -connectRetries=60 -configFiles=/flyway/conf/flyway.config -locations=filesystem:/flyway/sql oznacza kolejno:
  • migrate - uruchomienie procesu migracji flyway’a
  • connectRetries=60 - zdefinowanie ilości prób połączenia do bazy danych przez flywaya. Wymagane w docker-compose, gdyż flyway będzie mógł próbowac połączyc sie do bazy danych, zanim ona zacznie przyjmowac połączenia
  • -configFiles=/flyway/conf/flyway.config - path do pliku konfiguracyjnego flyway’a wewnątrz kontenera
  • -locations=filesystem:/flyway/sql - path do skryptów sql wewnątrz kontenera
• volumes - podlinkowanie oraz powiązanie ścieżek wewnątrz kontenera ze ścieżkami w systemie hosta
• depends_on - zaznaczenie od którego serwisu jest zależny dany serwis, przez co serwis nie zostanie uruchomiony przed serwisem zadeklarowanym wewnątrz depend_on
• database - drugi serwis wewnątrz docker-compose, w którym deklarujemy bazę danych
• image - obraz bazy danych, w tym przypadku postgres
• ports - porty, które są exposed z kontenera do systemu hosta
• environment - ustawienie zmiennych środowiskowych w konterze. Tutaj ustawiamy użytkownika, hasło oraz nazwę bazę danych, które zostanę stworzone wraz z inicjalnym uruchomieniem serwisu

Znając już szczegóły docker-compose, a zwłaszcza komendy wywułującej flyway’a, przejdźmy do stworzenia samego pliku konfiguracyjnego dla tego narzędzia. W folderze flyway, stwórz plik flyway.config. Skomfigurujemy w nim credentiale z których ma korzysta flyway by połączyc się z bazą danych, adres do db, podstawową schemę, schemy na których ma działac flyway oraz inne opcje.

flyway.url=jdbc:postgresql://database:5432/sales
flyway.user=lele
flyway.password=lele
flyway.defaultSchema=config
flyway.schemas=config,sales,users

Gdzie po kolei każda linijka oznacza:

• flyway.url - adres jdbc do połączenia z bazą danych. Składnia jdbc:postgresql://database:5432/sales oznacza kolejno:
  • jdbc:posrtgres:// - podstawowy adres jdbc określający z jakim DBMS się łączymy
  • database:5432/sales - faktyczny adres do bazy. W docker-compose database oznacza nazwę naszego serwisu z pliku konfiguracyjnego docker-compose, 5432 jest portem na którym działa baza, a sales dokładną bazą z którą będziemy się łączyc
• flyway.user - nazwa użytkownika bazy danych, którą wykorzysta flyway do połączenia
• flyway.password - hasło użytkownika
• flyway.defaultSchema - podstawowa schema, w której m.in będzie przetrzymywana tabela z hsitorią migracji (zarządzana przez flywaya)
• flyway.schemas - inne możliwe scheme bazy danych

Uwaga! Baza danych oraz scheme na których działamy nie konfigurujemy i nie tworzymy przy pomocy plików SQL! W tym przypadku baza danych zostaje stworzona przez samego postgresa (poprzez przekazanie wartości w komendzie POSTGRES_DB), a scheme są tworzone na podstawie wartości defaultSchema oraz schemas w pliku konfiguracyjnym w flyway.config.

Przejdźmy teraz do dodania kilku plików SQL, które chcemy by automatycznie zaaplikowały się do bazy danych. W folderze sql stwórz plik V1__customer-table.sql, a w nim skrypt tworzący tabelę customer:

CREATE TABLE users.customer (
    id serial NOT NULL,
    name character varying(100) NOT NULL,
    address character varying(100) NULL,
    city character varying(100) NULL,
    country character varying(100) NULL,
    CONSTRAINT pk_customer_id PRIMARY KEY (id)
);

Aby zachowac prawidlowe funkcjonowanie wersjonowania skryptów, ich nazwy plików powinny byc zapisane według poniższej konwencji:

Gdzie:

• Versioned migrations - migracje, które są uruchamiane po kolei tylko i wyłącznie raz
• Undo migrations - migrajce, które cofają wykonane już wcześniej versioned migrations
• Repeatable migrations - migracje, które są powtarzalne. To znaczy że są uruchamiane za każdym razem kiedy zostanie zmieniony plik migracji

Posiadając już w pełni skonfigurowanego docker-compose oraz skrypty, przejdźmy do ich uruchomienia.

Uruchomienie zautomatyzowanego środowiska bazo danowego wraz z migracją

Aby uruchomic całe środowisko, otwórz terminal/cmd , wejdź do folderu migrations i wykonaj poniższą komendę, która uruchomi, całą wcześniej zdefinowaną konfigurację:

docker-compose up

Prawidłowo uruchomiony docker-compose powinien wyglądac następująco:

Następnie możemy zweryfikowac powstałe kontenery w programie Docker Desktop:

Przejdźmy teraz do Datagripa. Po uprzednim połączeniu z bazą, możemy zobaczyc ze opisana wcześniej tabela customers została poprawnie stworzona:

Natomiast w scheme config, możemy znaleźc tabelę flyway_schema_history, w której przetrzymywana jest przez flywaya historia uruchamianych migracji: