Podjąłem próbę ustawienia na swoim laptopie środowiska do rozwijania Sealious, aby mieć miejsce do weryfikowania swoich zmian i udzielania przeglądów kodu. Wszystkie opisane tu czynności wykonywałem na systemie:
- Debian 9.3 Stretch
- Docker w wersji 17.05.0-ce, build 89658be z repozytorium oryginalnego dostawcy
- GNU Make w wersji 4.1
- Repozytorium Sealious Archive ustawione na wersji 3e3b0e3f7068b5249339a7e21bb1967367dfc53b (najświeższa gałąź
alpha)
1. Makefile
Brakuje mi szybkiej i opisanej metody żeby maksymalnie dwoma komendami przejść do rozwoju Sealious. Aktualny Makefile wymaga własnego przeanalizowania, aby wpaść na metodę ustawienia środowiska. Wywołanie make ustawia jedynie bazę danych. Samo make test zwraca:
$ make test
./npm.sh run test
Starting sealiousarchive_mailcatcher_1 ... done
Starting sealiousarchive_db_1 ... done
> sealious@0.8.0 test /opt/sealious
> mocha setup-test.js lib/**/*.test.js
sh: mocha: not found
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR! sealious@0.8.0 test: `mocha setup-test.js lib/**/*.test.js`
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the sealious@0.8.0 test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?
npm ERR! A complete log of this run can be found in:
npm ERR! /home/node/.npm/_logs/2018-04-06T22_05_07_142Z-debug.log
Makefile:9: recipe for target 'test' failed
make: *** [test] Error 1
Wykonanie make build zwraca:
$ make build
./npm.sh run build
Starting sealiousarchive_mailcatcher_1 ... done
Starting sealiousarchive_db_1 ... done
Building test
....
.... (zakończona pomyślnie budowa obrazu, którą wyciąłem dla czytelności)
....
npm ERR! missing script: build
npm ERR! A complete log of this run can be found in:
npm ERR! /opt/sealious/.npm/_logs/2018-04-06T22_29_55_570Z-debug.log
Makefile:15: recipe for target 'build' failed
make: *** [build] Error 1
Ponadto w Makefile znajdują się zwracające błąd lub nic nie robiące targety:
watchtest-nginx
Drogą eksperymentów doszedłem, że do uzyskania gotowego do przeprowadzenia testów środowiska wymagane są komendy:
make installmake test
Propozycje
Usuńmy nadmiarowe targety z Makefile i przygotujmy krótką instrukcję uzyskiwania gotowego do działania środowiska deweloperskiego.
2. Nieudane testy
Uruchomienie testów jeszcze bez zmieniania niczego w kodzie kończy się licznymi błędami. Ze względu na długi output załączam go w pliku error.log (8,8 KB)
Proszę o informację czy jest to zamierzony stan rzeczy. Podczas rozmowy z @bartosz-gordon i @kuba-orlik padło przypuszczenie, że niektóre testy kończą się niepowodzeniem z powodu zbyt długiego czasu wykonywania. W logu rzeczywiście jest parę timeoutów. Czy bylibyśmy w stanie pozbyć się ograniczeń czasowych lub włączać je tylko określoną flagą/zmienną środowiskową, np. podczas testowania wydajności docelowego hardware-u pod aplikację przed wdrożeniem?
3. Środowisko tworzy pliki z obcymi uprawnieniami
Kontener MongoDB binduje katalogi db i configdb z katalogu z kodem wykorzystując użytkownika i grupę inną niż użytkownik uruchamiający środowisko. Powoduje to, że użytkownik pod którym rozwijamy kod nie ma uprawnień żeby je posprzątać, np.:
sealious-archive$ rm db/ -rf
rm: cannot remove 'db/collection-46--5284711994617411567.wt': Permission denied
rm: cannot remove 'db/index-24--5284711994617411567.wt': Permission denied
rm: cannot remove 'db/journal/WiredTigerPreplog.0000000001': Permission denied
rm: cannot remove 'db/journal/WiredTigerPreplog.0000000002': Permission denied
rm: cannot remove 'db/journal/WiredTigerLog.0000000001': Permission denied
Propozycje
Nie widzę powodu żeby binarne pliki bazy danych były w katalogu z kodem. Proponuję przenieść je do woluminów zarządzanych przez Docker. Takie podejście jest stosowane, np. tutaj.
4. Brakuje domyślnych konfiguracji
Uruchomienie Sealious z przykładową aplikacją wymaga posiadania jej konfiguracji, manifestu oraz prostego hello world do działania. Aktualnie w repozytorium jest jedynie przykładowy plik konfiguracyjny. Same automatyczne testy kodu nie pozwalają uruchomić aplikacji, w której można by manualnie testować zmiany(poprawcie mnie, jeśli się tu mylę i gdzieś są przykładowe hello world).
Propozycje
Stwórzmy prosty szablon startowy od którego będzie można zacząć rozwój Sealious.
5. Brak serwera HTTP w środowisku testowym
Mam tu na myśli reverse-proxy w postaci Nginx, za którym się zawsze wdraża aplikacje webowe. Spotykałem już przypadki, gdy w projektach nie brano pod uwagi środowiska produkcyjnego gdzie będzie uruchamiany kod. Takie różnice między testami a produkcją kończyły się czasami problemami przed samym wdrożeniem.
Propozycje
Dodajmy do standardowej konfiguracji deweloperskiej Docker Nginx skonfigurowany dla Sealious. Pozwoli nam to utrzymać aktualną i działającą konfigurację gotową do przeniesienia na serwer produkcyjny. Proponuję, tak jak tutaj, zostawić również bezpośredni dostęp do Sealious na potrzeby deweloperskie, ale zachęcać do testowania raczej w konfiguracji odzwierciedlającej przyszłą produkcję.
6. Przestarzała dyrektywa w Docker Compose
W docker-compose.yml wykorzystywana jest wycofywana już powoli opcja links.
Propozycje
W Docker Compose kontenery zachowują wzajemną widoczność(również po nazwie) w ramach konfiguracji, dlatego links nie jest potrzebne. Mam jednak obawy, że usunięcie links może popsuć zależność kontenerów(mailcatcher i db uruchamianie przed test). W razie problemów zależność możemy wymusić opcją depends_on.
