Posted by Celem tego artykułu jest przedstawienie ścieżki, którą musiałem pokonać, aby połączyć wszystkie mikroserwisy w jedno repozytorium. Lista założeń, które sobie wyznaczyłem jest następująca:
- wszystkie zależności zarządzane z głównego folderu w repozytorium
- docker-compose do uruchamiania całego systemu lokalnie
- proces CI/CD nie ulegnie zmianie (może poza samym plikiem gitlab-ci)
Połączenie kilku mikroserwisów w jedno repozytorium zarządzane z jednego pliku package.json wymaga trochę pracy. Oto lista trudności, które musiałem przejść:
1. Niespójności w wersjach paczek
Najpierw musimy zdefiniować tak zwane workspaces w pliku package.json i podać ścieżkę do katalogu z naszymi modułami, w których są pozostałe pliki package.json. Poniżej dwa obrazki prezentujące jak wygląda struktura katalogów oraz jak zdefiniować workspaces. Więcej o tym, czym są i jak dokładnie działają NPM’owe workspaces możecie przeczytać u nich w dokumentacji.
Niestety, aż tak proste to nie było, ponieważ każdy mikroserwis był rozwijany w innym czasie, dlatego spora część bibliotek ma różne wersje i przy próbie uruchomienia „npm install” w głównym katalogu monorepo pojawiło się sporo błędów odnośnie niespójności pomiędzy zależnościami. Najłatwiejszym rozwiązaniem w moim przypadku było podniesienie wersji wszystkich bibliotek do najnowszych z użyciem tego narzędzia. Po takiej aktualizacji wypada przetestować całą aplikację, czy aby na pewno wszystko działa jak powinno, gdyż naprawdę została zaktualizowana ogromna ilość paczek.
I tym sposobem osiągnęliśmy jedno z 3 założeń, czyli wszystkie zależności zarządzane z głównego katalogu repo.
2. Docker-compose
Kolejnym etapem jest połączenie osobnych plików docker-compose w jeden główny uruchamiający wszystkie moduły systemu. Ten krok nie znalazł się przypadkowo tak wysoko, gdyż nadeszła teraz potrzeba uruchomienia całości i przetestowania.
Na szczęście w tym przypadku obyło się bez większych problemów, gdyż dosłownie większość pracy polegała na kopiuj-wklej. Jedyne co to trzeba to ustawić odpowiednie porty, aby kontenery się nie gryzły i połączyć dwie bazy mysql’owe na jednym kontenerze, co udało się dzięki plikowi wsadowemu, który uruchamiany zostaje po starcie kontenera. Poniżej screen z definicji kontenera w pliku docker-compose oraz zawartość pliku inicjalizujaca bazy danych.
3. Proces CI/CD
Ostatnim krokiem w procesie przenoszenia mikroserwisów do jednego repozytorium jest dostosowanie procesu CI/CD do nowej struktury katalogów oraz do istniejącej infrastruktury. Proces przygotowania aplikacji, czyli wykonanie npm install i nie musiał się w ogóle zmienić, gdyż i tak z głównego katalogu musi być wykonany. Zmiany nastąpiły w procesie uruchamiania testów i budowania aplikacji. Na ten moment uruchamianie są zawsze wszystkie testy oraz build’y, natomiast deployment został manualny.
Na powyższych zrzutach widać definicje dwóch szablonów, jeden do uruchamiania testów a drugi do budowania serwisów. Na ostatnim screenie widać przykład ich użycia. Informacja, jakie testy uruchomić oraz gdzie opublikować zbudowany obraz konfigurowalna jest zmiennymi.
Ostatnim krokiem jest deployment, tam za wiele się nie zmieniło. Zakładałem 0 zmian od strony infrastruktury, ale niestety zmienił się url spod jakiego są brane tagi, wiec to tak naprawdę jedyna zmiana, jaka została zrobiona od tamtej strony. W pliku gitlab-ci.yml wyglada to następująco:
Podsumowanie
Tym oto sposobem zakończył się pierwszy etap migracji. Zajął on w sumie kilka godzin i nie wystąpiły większe problemy z czego jestem bardzo zadowolony. Największym z nich chyba był proces wyrównania wersji paczek dla wszystkich mikroserwisów, bo za nim użyłem gotowego narzędzia, próbowałem robić to ręcznie.