Uruchomienie Leantime - wdrożenie w 120 sekund

Poprzedni post dotyczył Basha jako lingua franca DevOps. W tym wdrożymy aplikację Leantime - mniej wiecej w 2 minuty. W moim przypadku tyle czasu wystarczyło na Ctrl+V tekstu w CLI, wykonanie polecenia (w tym pobranie dwóch obrazów Dockera), uruchomienie aplikacji www i utworzenie pierwszego użytkownika. Wszystko to w środowisku Dockera (o jego instalacji pisałem w poprzednich postach).

Dla przypomnenia - Leantime to open source’owa aplikacja webowa do zarządzania projektami i zadaniami, łącząca tablice Kanban, roadmapy, cele, dokumentację i pracę zespołową w jednym.

Ale do rzeczy, po kolei… Postanowiłem uruchomić prostą aplikację kontenerową Leantime w lokalnym labie. Prostą w tym sensie, że korzysta raptem z dwóch obrazów Dockera, więc wzajemnych zależności nie jest dużo. Moim celem nie było zapoznanie się z funkcjonalnością tej aplikacji, tylko zweryfikowanie, czy zdążę zaparzyć kawę, nim Docker uruchomi aplikację w trybie wizard-setup. Wyszło jak wyszło, tzn. po upływie minuty od zatwierdzenia polecenia aplikacja była gotowa do wyświetlenia w przeglądarce.

Instalacja i uruchomienie od strzała.

W praktyce wystarczyło wkleić do terminala jeden blok kodu:

{
set -euo pipefail

mkdir -p ~/lab/leantime
cd ~/lab/leantime

wget -q \
https://raw.githubusercontent.com/Leantime/docker-leantime/master/docker-compose.yml

cat > .env <<'EOF'
LEAN_DB_HOST=mysql_leantime
LEAN_DB_USER=admin
LEAN_DB_PASSWORD=Admin123!
LEAN_DB_DATABASE=leantime
LEAN_APP_URL=http://localhost:8080
LEAN_SESSION_PASSWORD=ChangeThisSessionSecret123
MYSQL_ROOT_PASSWORD=Root123!
MYSQL_DATABASE=leantime
MYSQL_USER=admin
MYSQL_PASSWORD=Admin123!
EOF

docker compose up -d
docker compose logs -f
}

Zasadniczo nic szczególnego - potok kilku poleceń - pobranie yamla, utworzenie pliku ze zmiennymi, uruchomienie stacka i wyświetlenie logów kontenera, żebym widział, czy usługi wstały.

Ctrl+C kończy podgląd logów, lecz nie przerywa pracy kontenerów.

Jedna istotna uwaga - to nie jest konfiguracja produkcyjna i nawet nie próbuje nią być.

Po ok. minucie mogłem otworzyć http://localhost:8080 i przejść przez wizard-setup. Kolejna minuta wystarczyła na podanie danych użytkownika i szczegółów konta, wybór motywu i zatwierdzenie rytmu pracy. Po zatwierdzeniu Complete Sign up moim oczom ukazała się aplikacja w całej okazałości.

Leantime nie był tu najbardziej istotny

Równie dobrze mógłby to być Redmine, Uptime Kuma, baza danych do testów albo narzędzie, którego nazwy za pół roku nie będę już pamiętał. Schemat pozostaje ten sam:

• utwórz przewidywalne miejsce,
• pobierz deklarację środowiska,
• zapisz konfigurację,
• uruchom całość,
• pokaż logi.

Największą zaletą nie jest nawet szybkość pierwszego uruchomienia. Ważniejsze jest to, że drugi i każdy kolejny raz wyglądają dokładnie tak samo.

Plik Compose opisuje środowisko, .env przechowuje jego parametry, a Bash skleja kilka prostych operacji w jedną powtarzalną czynność.

Ctrl+V zamiast długiej opowieści

Automatyzacja bywa przedstawiana jako pełnoprawny projekt: repozytorium, pipeline, testy, wersjonowanie i pół tablicy zadań. Czasami jednak automatyzacja to dobrze napisany blok poleceń, który łączy w powtarzalną całość kilka nudnych kroków.

To także dobry pomysł na codzienną pracę. Jeśli wykonuję coś po raz kolejny i wciąż odtwarzam te same polecenia z historii terminala, prawdopodobnie powinienem je zebrać w jednym miejscu. Nie po to, żeby pochwalić się skryptem. Po to, żeby następnym razem nie poświęcać temu nadmiernej uwagi.

Ten wpis jest częścią takiego podejścia. Za miesiąc albo za pół roku być może będę potrzebował Leantime. Jest spora szansa, że trafię wtedy tutaj z wyszukiwarki, wkleję blok kodu do terminala i oszczędzę czas samemu sobie. Dokumentacja pisana pod własną pamięć ma zwykle bardzo konkretnego odbiorcę.

Bash nie musi rozwiązywać wielkich problemów, żeby był użyteczny - wystarczy, że regularnie usuwa z dnia drobne, acz powtarzalne czynności.