Stało się… mam opóźnienie 2 tygodniowe, i można powiedzieć że wykorzystałem regulaminową przerwę w pisaniu.
Tak się zaczytałem w 1 tygodniu, że stwierdziłem, że nic nie umiem jeszcze. I nie napisałem nic :(
Drugi tydzień wolnego zużyłem przez natłok zadań w pracy i życiu.
Poniżej rozpiszę hierarchie z WebClient, która będzie obsługiwała Front aplikacji z wykorzystaniem React JS.
Trochę czasu mi zeszło na przygotowanie serwera JS, miałem problem przygotować wszystko. Co chwile coś mi nie działało albo tworzyłem małego potworka.
Znalazłem jednak artykuł na stronie https://nafrontendzie.pl/podstawy-reactjs-kompletny-tutorial/ i stworzyłem pusty projekt, z podstawowymi ustawieniami.
Projekt się pewnie jeszcze zmieni, ponieważ startowy projekt używa „Karma Mocha” do testów. A ja chciałem użyć „JEST” lub „Cucumber w wersji JS”
|
cfg - pliki konfiguracyjne dla wszystkich trybów (dev, prod, test) coverage - testy js z PhantomJS (sam musze to ogarnąć to jeszcze napisze co to dokladnie robi :D ) dist - katalog juz z przygotowanymi plikami na produkcje src - katalog z wszystkimi kodami zródłowymi test - tworzenie testów .babelrc - plik konfiguracyjny babel .eslintrc - plik konfiguracyjny lint karma.conf.js - plik konfiguracyjny testów karma server.js - plik konfiguracyjny serwera webpack.config.js - plik konfiguracyjny webpack'a package.json - wszystkie paczki potrzebne do projektu, oraz polecenia do testów i odpalania serwera |
https://github.com/mfratczak/myfood-generator/tree/master/WebClient
Odpalanie serwera front
# uruchomienie w trybie dev
npm start # lub
npm run serve
# uruchomienie wykorzystując pliki z katalogu dist (wersja produkcyjna)
npm run serve:dist
# generowanie plików do katalogu dist + kopiowanie zasobów statycznych
npm run dist
# urumienie testów
npm test
# uruchomienie testów wraz z re-testem przy zmianie pliku
npm run test:watch
# uruchomienie lintera (dzieje się też automatycznie po testach)
npm run lint
# czyszczenie katalogu dist
npm run clean
# kopiowanie statycznych zasobów
npm run copy
Przy bawieniu się dockerem, testowaniu, wielokrotnym odpalaniu środowisk, zdarza się ze nic nie chce działać.
Czemu?
Odpalanie testowych środowisk powoduje ze ściągamy zcachowane warstwy, lub generujemy nowe. Ponowne generowanie, drobne zmiany itp powodują dwa problemy:
- ilość miejsca na serwerze maleje
- obraz środowiska, który chciałbyś odpalić od zera powinieneś usunąć i odpalić jeszcze raz
Gdy odpalamy dockera:
|
docker-compose up -d | lub docker-compose up -d --build (gdy budujemy swój kontener lokalnie) |
to zostają ściągnięte wszystkie warstwy (layers) potrzebne do zbudowania środowiska. Jeśli budujesz środowisko, to jest ono budowane lokalnie.
Normalnie możesz zatrzymać kontenery:
|
docker-compose stop | docker-compose start (tak pózniej startujesz) |
lub całkowicie je usunać:
Czym to się różni?
Jeśli tworzysz nowy kontener, dla jednego obrazu, prawdopodobnie posiada on skrypty inicjujące, które ustawiają wszystko co trzeba do jakiegoś systemu (np system do zarządzania zadaniami Redmine). Kontenery również zapisują dane wewnątrz siebie dane (jeśli nie wyprowadziłeś ich na zewnątrz).
Aby nie stracić tych ustawień, można zastosować STOP. (np wchodzisz w dany kontener i instalujesz coś ręcznie, i się bawisz poznając nowe rzeczy, dzięki stop tego nie stracisz)
Nie powinniśmy zapisywać jednak danych wewnątrz kontenera. Powinniśmy wyjść z założenia, że cokolwiek w nim jest, można usunąć i zresetować do stanu początkowego.
Dlatego jak nie bawię się, lub nie instaluje ręcznie bibliotek celem jakichś testów, to używam DOWN.
Jednym słowem usuwam kontener, i tworze go znowu.
Co gdy nie można usunąć obrazów i kontenerów?
Zdarza się, że w testach tak zamieszamy :) przy tworzeniu multum wersji, zmian itp (standard), że nie można wygenerować nic nowego, lub nie widać zmian.
Wtedy tutaj przychodzą do pomocy polecenia dockerowe.
Zatrzymywanie wszystkich kontenerów dockerowych
|
docker stop $(docker ps -a -q) |
Usuwanie wszystkich kontenerów, również które są ukryte na pierwszy rzut oka
|
docker rm $(docker ps -q -f status=exited) |
Usuwanie wszystkich obrazów dockerowych na serwerze (ściągnięte, lub wygenerowane przez nas)
|
docker rmi $(docker images -q)docker rm `docker ps --no-trunc -aq` |
Usuwanie reszty obrazów, jeśli nie usuneło wszystkiego a jest na liście docker images
|
docker images -q -a | xargs --no-run-if-empty docker rmi |
Zdarza się, że nie można usunąć obrazów, ponieważ pojawia się błąd:
Error response from daemon: conflict: unable to delete ba62b42dad38 (cannot be forced) – image has dependent child images
Musimy wtedy skorzystać z flagi Force. (mówimy oczywiście o serwerze developerskim, gdzie możemy wszystko usuwać i niczego się nie obawiać, że stracimy dane :) )
|
docker rmi -f $(docker images -q)docker rm `docker ps --no-trunc -aq` |
Sprawdzamy czy usuneliśmy wszystko możemy poleceniami
|
docker ps - spis kontenerów (pokazuje uruchomione) |
|
docker ps - spis kontenerów (pokazuje wszystkie) |
|
docker images - spis wszystkich obrazów |
Aliasy – czyli jak ułatwić sobie pracę
Sam korzystam z aliasów, które można znaleźć tutaj https://github.com/tcnksm/docker-alias/blob/master/zshrc
Krótkie wyjaśnienie: https://kartar.net/2014/03/useful-docker-bash-functions-and-aliases/
Jednym słowem, używam głównie poleceń:
dstop – zatrzymanie WSZYSTKICH kontenerów
drm – usunięcie wszystkich kontenerów
dri – usunięcie wszystkich obrazów
dalias – spis wszystkich aliasów dockerowych
dex nazwa-kontenera bash – wejście w dany kontener
I to tyle :)
Mogłem dać spis poleceń na usuwanie pojedynczych obrazów lub kontenerów, ale o tym wszędzie piszą :) więc na pewno umiesz to robić, lub znajdziesz rozwiązanie.
Na lokalnym komputerze, korzystam z wszystkich poleceń, usuwam wszystko itp. Na serwerach w internecie, trzeba wsiąść pod uwagę, że możesz posiadać limit transferu. Więc każdorazowe usuwanie obrazów, i zaciąganie ich, spowoduje jego zużywanie. Ja wtedy usuwam, konkretny obraz (jeśli trzeba)
W razie pytań, lub moich błędów, pisz !