Rekonstrukcja środowiska Leantime

1. Executive Summary

Zrekonstruowano działające środowisko Leantime złożone z aplikacji leantime/leantime:latest i bazy mysql:8.4. Usługi pracują w dedykowanej sieci bridge leantime-net, korzystają z pięciu trwałych wolumenów i są wystawione pod http://localhost:8080.

Oba kontenery osiągnęły stan healthy. Zakończono instalację schematu, utworzono administratora [email protected], domyślny projekt My Project oraz dane startowe. Przeprowadzono testy logowania, dashboardu, projektów, zadań, Kanbanu, kalendarza, zarządzania użytkownikami, połączenia sieciowego i trwałości.

2. Analiza dokumentacji źródłowej

Informacje wystarczające do rozpoczęcia

• Topologia dwóch usług, wymagane obrazy i mapowanie portu 8080:8080.
• MySQL 8.4, baza leantime, użytkownik admin i wymaganie UTF8MB4.
• Pięć logicznych obszarów trwałości: db_data, userfiles, public_userfiles, plugins, logs.
• Nazwa sieci leantime-net, URL aplikacji i podstawowe zmienne LEAN_DB_*.
• Oczekiwany administrator, projekt domyślny, model domenowy i scenariusze ST01-ST04.

Niekompletności i niejednoznaczności

3. Plan rekonstrukcji

1. Wyodrębnić wymagania infrastrukturalne, funkcjonalne i testowe z jedynego dokumentu źródłowego.
2. Rozstrzygnąć konflikty nazw, wygenerować sekrety i zmapować pięć obszarów trwałości.
3. Zbudować .env, docker-compose.yml i strukturę roboczą; zwalidować Compose.
4. Uruchomić bazę z healthcheckiem, następnie aplikację zależną od zdrowej bazy.
5. Przeprowadzić inicjalizację aplikacji, utworzyć administratora i zweryfikować dane startowe.
6. Wykonać testy infrastruktury, scenariusze ST01-ST04 oraz wymagane kontrole modułów.
7. Przeanalizować logi po restarcie i sporządzić raport odchyleń oraz kompletności.

4. Wykonane działania

Artefakty

Konfiguracja uruchomieniowa

Application: leantime/leantime:latest (runtime: Leantime 3.9.5)
Database:    mysql:8.4 (runtime: MySQL 8.4.10)
Network:     leantime-net / bridge / 2 containers
Endpoint:    http://localhost:8080
Volumes:     leantime_db_data, leantime_userfiles,
             leantime_public_userfiles, leantime_plugins, leantime_logs

W bazie utworzono 37 tabel z prefiksem domenowym zgodnym z opisem, m.in. zp_user, zp_projects, zp_tickets, zp_roles. Konto administratora ma rolę właściciela i dostęp do zarządzania użytkownikami.

5. Napotkane problemy

Ostrzeżenia MySQL dotyczące certyfikatu self-signed, katalogu PID i brakujących danych stref czasowych pochodzą ze standardowego startu obrazu i nie zakłóciły testów. Powtarzane komunikaty PHP-FPM o dyrektywach user/group są informacyjne; proces działa jako użytkownik nierootowy.

6. Podjęte decyzje projektowe

• Usługa Compose otrzymała nazwę mysql_leantime, zgodną z LEAN_DB_HOST; nazwa kontenera pozostała leantime_db, co zachowuje oba warianty z raportu.
• Użyto nazwanych wolumenów z jawnymi, stabilnymi nazwami i punktami: /var/lib/mysql, /var/www/html/userfiles, /var/www/html/public/userfiles, /var/www/html/app/Plugins, /var/www/html/storage/logs.
• Wygenerowano losowe sekrety bazy i sesji; nie powielono przykładowego hasła bazy z dokumentu.
• MySQL uruchomiono z utf8mb4 i utf8mb4_unicode_ci, zgodnie z opisem technicznym.
• Aplikacja startuje dopiero po pozytywnym healthchecku bazy. Obie usługi mają politykę unless-stopped.
• Capabilities ograniczono do operacji plikowych i zmiany UID/GID wymienionych funkcjonalnie przez raport: CHOWN, DAC_OVERRIDE, SETGID, SETUID.
• Nie dodano SMTP, LDAP, proxy TLS ani usług niewymienionych w źródle.

7. Wyniki testów

Scenariusze źródłowe

Kontrole rozszerzone

Nie wykonywano pełnych macierzy negatywnych dla każdego typu roli ani CRUD zdarzenia kalendarza, ponieważ raport nie dostarcza danych testowych ani oczekiwanych reguł szczegółowych. Zweryfikowano dostępność modułów, słownik ról i uprawnienia konta administracyjnego.

8. Porównanie z wymaganiami dokumentacji

9. Ocena kompletności dokumentacji

Ocena: częściowo wystarczająca (około 65%). Raport trafnie opisuje architekturę logiczną, obrazy, port, ogólne wolumeny i funkcje. Pozwala doświadczonemu operatorowi rozpocząć rekonstrukcję, ale nie gwarantuje identycznego wyniku bez rozpoznania zachowania wskazanego obrazu.

Do pełnej odtwarzalności powinny zostać dodane: kompletny Compose, dokładna wersja lub digest aplikacji, wszystkie zmienne środowiskowe, mount points, jawna lista capabilities, procedura pierwszej instalacji, sposób utworzenia hasła administratora, precyzyjna macierz ról oraz wykonywalne przypadki testowe z oczekiwanymi wynikami.

Szczególnie istotne jest zastąpienie latest niezmiennym identyfikatorem obrazu. W trakcie tej realizacji pobrany obraz miał digest sha256:7d0cd20bf6e7b2a3ec79e425807cd796728c7afe2f745166119f85967aee4593 i raportował Leantime 3.9.5; przyszły tag latest może zachowywać się inaczej.

10. Wnioski

Cel operacyjny został osiągnięty: środowisko jest uruchomione, spójne z udokumentowaną architekturą i przeszło wymagane scenariusze. Trwałość danych, komunikacja sieciowa i podstawowe ścieżki biznesowe zostały potwierdzone praktycznie.

Największym ryzykiem nie jest bieżące działanie, lecz powtarzalność przyszłej instalacji. Źródłowy raport należy traktować jako opis reverse engineering, nie jako gotową specyfikację wdrożeniową. Utworzone artefakty wypełniają tę lukę dla obecnego środowiska, a niniejszy raport rejestruje wszystkie decyzje, odstępstwa i dowody testowe.