Docker: Dobrze wychowane kontenery w NodeJS

0:00Cześć!

0:00W tej sekcji tego kursu omówię różne dobre praktyki związane ze środowiskiem

0:03produkcyjnym i pod koniec tego działu też zdefiniujemy naszą aplikację faktycznie do

0:09internetu, tak aby nasz obraz Dockera, z którego korzystaliśmy do tej pory tylko i

0:13wyłącznie na naszych maszynach lokalnych, pojawił się w internecie, w związku z czym

0:18jako wstęp do tego działu chciałbym opowiedzieć troszkę więcej o dobrze

0:21wychowanych kontenerach w Jamesie czy ogólnie w pokerze.

0:25Bo to co jest najważniejsze to oczywiście już wspominałem o tym troszkę na przełomie

0:29poprzednich lekcji, ale są różne funkcjonalności Dockera, które

0:34może nie są tak oczywiste dla większości web developerów, takie jak na przykład

0:39standardowe wyjście dla logów czy standardowe wyjście błędów.

0:45I tak jak sobie np. zrobimy docker logs.

0:49Na tej naszej aplikacji z dynamicznym przygotowywaniem zasobów.

0:52Ona oczywiście faktycznie działa z follow me.

0:56Czyli jeżeli np. zrobimy zmianę z jakiegoś powodu,

0:59oczywiście na środowiskach produkcyjnych takiej sytuacji by nie było,

1:02to ona się przepisze i w logach będziemy mieli informację o tym.

1:06Trzeba też pamiętać o tym, aby nasze kontenery reagowały na sygnały wejścia,

1:11czyli w momencie kiedy ja robię docker stop czy docker down czy docker kill.

1:17Sposobów na wyłączenie dockera jest naprawdę dużo.

1:20Te aplikacje też powinny wyłączać się

1:23z gracją, tzn ewentualnie sprzątać coś po sobie, wyłączać komunikację z bazą danych

1:29i przede wszystkim nie czekać tych 10 sekund.

1:31Bo o ile to jest po prostu irytujące na

1:33naszym środowisku lokalnym, o tyle na produkcji jeżeli jest jakiś

1:37problem z danym kontenerem i trzeba zastąpić go jakimś nowym,

1:41to tak naprawdę każda sekunda może się liczyć w tym jaki user experience jest

1:45serwowany naszym użytkownikom, naszym klientom stron www.

1:50W związku z czym po prostu ten czas tranzycji z jednej wersji obrazu, z jednej

1:54wersji kodu źródłowego do drugiej powinien być jak najkrótszy.

1:58Aby to osiągnąć, z reguły wystarczy podążać jedną dobrą praktyką.

2:02Czyli jeżeli sobie zrobimy docker a, możemy docker composer exec bash

2:08i tutaj sobie zrobimy configuration file not provided.

2:13Ciekawe, ale musimy przejść do katalogu 13.

2:15Przepraszam.

2:16Tak jak widzimy musimy być w katalogu, w którym znajduje się tokarka.

2:19W przeciwnym razie trzeba przekazać po

2:20prostu flagę, w którym miejscu się znajduje.

2:24Więc jesteśmy teraz w naszym kontenerze i

2:26to co możemy zrobić to wpisać sobie PS a fix.

2:29To jest oczywiście unikatowa komenda,

2:31która sprawdza nam uruchomione procesy i krytyczne w Doktorze.

2:37Jest tutaj ten proces id 1.

2:40Jak to sobie troszkę odpalę zobaczymy.

2:42Proces ID 1 to jest ten proces, który

2:45wypycha nam informację do standardowego wyjścia błędu czy po prostu do auta.

2:52I tak samo ten proces jest procesem, który

2:56pozwala nam poprawnie obsługiwać sygnały wejścia.

2:59Każdy kolejny proces, który zostanie

3:01uruchomiony czy to przez chip process, czy po prostu przez jakieś

3:06inne aplikacje, które zostaną uruchomione one już nie mają takiej mocy, aby po

3:10prostu zabić kontener Dockera i zareagować na te sygnały.

3:16Więc to co zawsze warto patrzeć w Waszych

3:19kontenerach, które już są budowane z myślą o produkcji, to aby

3:23ten proces IT był nieważne jaki jest, nieważne jaki program go obsługuje,

3:28żeby obsługiwał sygnały wyjścia, żeby dawał poprawne inside out

3:33oraz żeby w sytuacji gdy nasza aplikacja się faktycznie np.

3:36crashuje, żeby poprawny dawał kod błędu wyjściowego, bo wtedy agregatory treści

3:43czy orkiestra tory bardziej będą w stanie wykryć ten błąd i stworzyć

3:48nową instancję danego kontenera naszej aplikacji na jego miejsce.

3:53Gdzie w przypadku jeżeli nasza aplikacja

3:56nie wyłączy się w momencie gdy jest błąd, czyli np.

3:59na nie obsłużony wyjątek,

4:02nasza aplikacja się nie wyłącza, tylko dalej chodzi,

4:05to jest to zła praktyka produkcyjnie, ponieważ powinna nasza aplikacja się

4:09prawdopodobnie wywrócić jeżeli jest jakiś nie obsłużony wyjątek tak aby

4:15można było ją podmienić jakąś inną instancją tego samego kontenera.

4:18Chociaż to oczywiście zależy i powinniśmy

4:20wszystkie nasze wyjątki poprawnie obsługiwać.

4:23Więc w kolejnych lekcjach tego kursu

4:25powiem o tym jak obsługiwać sygnały wejścia.

4:29Powiem o tym, jak

4:31alternatywnie dostarczać informacji na standardowe wyjście błędu

4:36bądź informacji oraz zbudujemy nasz przykładowy obraz

4:41produkcyjny, który później deploy do internetu.

4:44To wszystko w tej lekcji. Dzięki za uwagę.