{"id":1151,"date":"2022-01-19T09:32:34","date_gmt":"2022-01-19T08:32:34","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=1151"},"modified":"2023-03-23T14:26:27","modified_gmt":"2023-03-23T13:26:27","slug":"docker-dla-programistow-dystrybucja-aplikacji-cz-3","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/docker-dla-programistow-dystrybucja-aplikacji-cz-3\/","title":{"rendered":"Docker dla programist\u00f3w \u2013 dystrybucja aplikacji"},"content":{"rendered":"\n

W ostatnim artykule\u00a0<\/a>zbudowali\u015bmy \u015brodowisko dla aplikacji uruchamianych na platformie Camunda BPM z wykorzystaniem PostgreSQL i serwera Wildfly. Do tej pory mogli\u015bmy uruchomi\u0107 aplikacj\u0119, startuj\u0105c kontener serwera Wildfly z zamontowanym modu\u0142em WAR, zawieraj\u0105cym nasz\u0105 przyk\u0142adow\u0105 aplikacj\u0119.<\/p>\n\n\n\n

Taki spos\u00f3b uruchomienia jest wygodny dla dewelopera, ale operator \u015brodowiska produkcyjnego raczej nie b\u0119dzie zadowolony. Docker pozwala na znacznie wygodniejsze przygotowanie paczki dystrybucyjnej pod postaci\u0105 obrazu kontenera z zainstalowan\u0105 w nim aplikacj\u0105. Dzi\u0119ki temu, na \u015brodowisko produkcyjne mo\u017cna dostarczy\u0107 gotowy do uruchomienia kontener i znacznie ograniczy\u0107 ilo\u015b\u0107 krok\u00f3w koniecznych do wykonania przez administratora.<\/p>\n\n\n\n

Instalacja aplikacji na serwerach<\/strong><\/h2>\n\n\n\n

Warto w tym miejscu na moment si\u0119 zatrzyma\u0107 i zwr\u00f3ci\u0107 uwag\u0119 na ciekaw\u0105 rzecz. W tradycyjnym podej\u015bciu do instalacji aplikacji na serwerach, ci\u0119\u017car zwi\u0105zany z technikaliami spada na administrator\u00f3w lub operator\u00f3w docelowego \u015brodowiska.<\/p>\n\n\n\n

To znaczy, \u017ce inaczej wdra\u017ca si\u0119 aplikacje pisane w Javie, inaczej w .NET, a jeszcze inaczej w Pythonie lub Ruby. Wynika to, jak wiemy, z ogromnych r\u00f3\u017cnic pomi\u0119dzy tymi platformami i wbudowanymi w nie mechanizmami dystrybucji i uruchomienia paczek. Powoduje to cz\u0119sto problemy i trudno\u015bci a przede wszystkim opory przed nowymi technologiami wdra\u017canymi w organizacji, poniewa\u017c nie tylko deweloperzy, ale r\u00f3wnie\u017c administratorzy, musz\u0105 by\u0107 na bie\u017c\u0105co z nowo\u015bciami, aby skutecznie instalowa\u0107 aplikacje.<\/p>\n\n\n\n

Docker wspiera zaanga\u017cowanie deweloper\u00f3w w proces uruchamiania aplikacji na kolejnych \u015brodowiskach oraz (na sw\u00f3j spos\u00f3b) eliminuje ryzyko zwi\u0105zane z brakiem znajomo\u015bci technologii w zespole OPS. To w\u0142a\u015bnie deweloperzy dokonuj\u0105 niejako instalacji aplikacji po swojej stronie i dostarczaj\u0105 operatorom obrazy kontener\u00f3w z zainstalowan\u0105 aplikacj\u0105.<\/p>\n\n\n\n

Jest to spos\u00f3b na zrealizowanie zasady m\u00f3wi\u0105cej o hermetyzowaniu zmienno\u015bci: zmiana technologii jest ukryta i zamkni\u0119ta w obszarze developmentu, a operatorzy pos\u0142uguj\u0105 si\u0119 niezmienn\u0105 technologi\u0105, czyli Dockerem.<\/p>\n\n\n\n

Wracaj\u0105c do budowania obrazu naszego kontenera z aplikacj\u0105 BPM, warto jeszcze zauwa\u017cy\u0107, \u017ce o ile z punktu widzenia administrator\u00f3w technologia wykonania aplikacji staje si\u0119 mniej znacz\u0105cym elementem, to deweloperzy musz\u0105 dostosowa\u0107 swoje aplikacje tak, aby da\u0142o si\u0119 je prosto zapakowa\u0107 w kontener Dockera.<\/p>\n\n\n\n

Jak przygotowa\u0107 obraz na produkcj\u0119?<\/strong><\/h2>\n\n\n\n

Na pocz\u0105tku chcia\u0142bym skupi\u0107 si\u0119 na mo\u017cliwie prostym podej\u015bciu do przygotowania obrazu wykorzystywanego na kolejnych \u015brodowiskach. Nast\u0119pnie, mam nadziej\u0119, zach\u0119ci\u0107 do poszerzania wiedzy i stosowania dobrych praktyk.<\/p>\n\n\n\n

W poprzednim artykule<\/a> przygotowali\u015bmy plik docker-compose.yml, dzi\u0119ki kt\u00f3remu po uruchomieniu mieli\u015bmy dzia\u0142aj\u0105c\u0105 aplikacj\u0119. Z punktu widzenia programisty by\u0142o to wygodne \u2013 aplikacja uruchomiona wraz z potrzebnymi zale\u017cno\u015bciami. Jednak uruchamianie w ten spos\u00f3b na kolejnych \u015brodowiskach jest oczywi\u015bcie karko\u0142omne. Mo\u017cna by zapyta\u0107: gdzie ten kompletny obraz dla kontenera\u2026?<\/p>\n\n\n\n

Kr\u00f3tko odpowiadaj\u0105c, a jednocze\u015bnie nawi\u0105zuj\u0105c do pierwszego z serii artyku\u0142u:<\/a><\/p>\n\n\n

\n# Dockerfile\nFROM camunda\/camunda-bpm-platform:wildfly-7.16.0\nCOPY .\/target\/pizza-order.war \/camunda\/standalone\/deployments\/pizza-order.war\n<\/pre><\/div>\n\n\n
Budowanie obrazu:<\/p>\n\n\n
\n$ docker build . -t someorganization\/pizza-order:1.0\n<\/pre><\/div>\n\n\n
Plik Dockerfile jest plikiem, kt\u00f3ry zawiera polecenia do zbudowania obrazu.<\/p>\n\n\n\n
Prostym i przejrzystym opisem wspomnianego pliku jest strona z\u00a0 dokumentacj\u0105<\/a>. Zach\u0119cam r\u00f3wnie\u017c do zapoznania si\u0119 z dobrymi praktykami tworzenia obraz\u00f3w<\/a>.
Polecenie build wykonuje instrukcje zawarte w pilku Dockerfile. Parametr . (kropka) oznacza bie\u017c\u0105cy katalog, a przez -t przekazuje si\u0119 nazw\u0119 taga, pod jakim obraz b\u0119dzie dost\u0119pny.<\/p>\n\n\n\n
\u00a0Po wykonaniu powy\u017cszego polecenia powinni\u015bmy otrzyma\u0107 nowy obraz, oczekiwany wynik:<\/p>\n\n\n
\n$ docker images someorganization\/pizza-order\nREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE\nsomeorganization\/pizza-order         1.0                 18105f66f15e        2 minutes ago       527MB\n<\/pre><\/div>\n\n\n
Dla podanej nazwy repozytorium \u201csomeorganization\/pizza-order\u201d otrzymujemy wcze\u015bniej utworzonego taga 1.0.<\/p>\n\n\n\n
Rejestr obraz\u00f3w<\/strong><\/h2>\n\n\n\n
Co dalej? Zbudowany obraz trzeba udost\u0119pni\u0107. W pierwszej cze\u015bci\u00a0<\/a>zapoznali\u015bmy si\u0119 z dwiema metodami udost\u0119pniania.<\/p>\n\n\n\n
Dzisiaj skupimy si\u0119 na rejestrze obraz\u00f3w \u2013 najbardziej popularnym jest Docker Hub<\/a>. Rejestr mo\u017ce by\u0107 publicznie dost\u0119pny lub prywatny. Wyb\u00f3r jest tutaj szczeg\u00f3lnie wa\u017cny \u2013 nie zawsze chcemy udost\u0119pnia\u0107 ca\u0142emu \u015bwiatu aplikacj\u0119, kt\u00f3r\u0105 piszemy dla klienta.<\/p>\n\n\n\n
Spos\u00f3b korzystania z obu dost\u0119p\u00f3w jest podobny, dodanie lub aktualizacja obrazu wymaga logowania do rejestru. Jedynie w przypadku prywatnego rejestru trzeba zalogowa\u0107 si\u0119 przed pobraniem obrazu. Poni\u017csze polecenie loguje do wspomnianego rejestru (uprzednio nale\u017cy za\u0142o\u017cy\u0107 konto<\/a>):<\/p>\n\n\n
\n$ docker login\n<\/pre><\/div>\n\n\n
Wykonuj\u0105c poni\u017csze polecenie, wysy\u0142amy obraz do rejestru:\u00a0<\/p>\n\n\n
\n$ docker push someorganization\/pizza-order:1.0\n<\/pre><\/div>\n\n\n
Nast\u0119pnie, aby u\u017cy\u0107 obraz na produkcji albo dowolnym innym \u015brodowisku, pobieramy go przez znane nam ju\u017c polecenie:<\/p>\n\n\n
\n$ docker pull someorganization\/pizza-order:1.0\n<\/pre><\/div>\n\n\n
Dzi\u0119ki powy\u017cszemu uzyskali\u015bmy obraz z aplikacj\u0105. Jednak w tym miejscu nale\u017cy zrobi\u0107 pauz\u0119. Gdzie\u015b \u201ezgubi\u0142 si\u0119\u201d postgres i co sta\u0142o si\u0119 z docker-compose.yml \u2013 czy jego te\u017c trzeba dostarczy\u0107 na kolejne \u015brodowiska?<\/p>\n\n\n\n
Docker compose nadaje si\u0119 do lokalnej pracy z obrazami, jednak uruchamianie kontener\u00f3w na kolejnych \u015brodowiskach to zadanie dla bardziej wyspecjalizowanych narz\u0119dzi.<\/p>\n\n\n\n
Orkiestracja kontener\u00f3w<\/strong><\/h2>\n\n\n\n
W naszej przyk\u0142adowej aplikacji potrzebujemy do dzia\u0142ania przynajmniej dw\u00f3ch kontener\u00f3w \u2013 pierwszy z aplikacj\u0105, drugi z baz\u0105 danych. Co, je\u015bli jeden kontener z aplikacj\u0105 to za ma\u0142o i potrzebnych jest ich kilka?\u00a0<\/p>\n\n\n\n
Tutaj w\u0142a\u015bnie pojawiaj\u0105 si\u0119 narz\u0119dzia umo\u017cliwiaj\u0105ce orkiestracj\u0119, ci\u0105g\u0142\u0105 dost\u0119pno\u015b\u0107 oraz \u0142atwe wdra\u017canie aplikacji. Przyk\u0142adami s\u0105 Kubernetes, OpenShift, Azure AKS czy AWS ECS \u2013 s\u0105 to kompleksowe rozwi\u0105zania, kt\u00f3re wychodz\u0105 daleko poza prosty docker compose.<\/p>\n\n\n\n
Opisanie tych technologii wykracza poza zakres tego artyku\u0142u, jednak my\u015bl\u0105c powa\u017cnie o dystrybuowaniu swojej aplikacji, zdecydowanie nale\u017cy wzi\u0105\u0107 je pod uwag\u0119, maj\u0105c ju\u017c gotowy obraz \u2013 zbudowany w przedstawiony spos\u00f3b \ud83d\ude42<\/p>\n\n\n\n
Kubernetes<\/strong><\/h2>\n\n\n\n
Wspomn\u0119 tylko kr\u00f3tko o Kubernetes. Jest jednym z bardziej popularnych narz\u0119dzi, opisuj\u0105c za Wikipedi\u0105<\/a>: \u201eKubernetes to otwarto\u017ar\u00f3d\u0142owa platforma do zarz\u0105dzania, automatyzacji i skalowania aplikacji kontenerowych. Jego pierwotna wersja zosta\u0142a stworzona w 2014 roku przez Google, a obecnie rozwijany jest przez Cloud Native Computing Foundation\u201d.<\/p>\n\n\n\n
Na naszym blogu znajduje si\u0119 artyku\u0142 stanowi\u0105cy wprowadzenie do tej technologii.<\/a><\/p>\n\n\n\n
Podsumowanie<\/strong><\/h2>\n\n\n\n
Poznali\u015bmy wcze\u015bniej Docker compose, kt\u00f3ry nadaje si\u0119 do lokalnej pracy. W tym artykule przedstawi\u0142em prosty spos\u00f3b budowania obrazu dla kolejnych \u015brodowisk, \u0142\u0105cznie ze \u015brodowiskiem produkcyjnym.<\/p>\n\n\n\n
Ca\u0142y ten proces budowania obrazu powinien by\u0107 zautomatyzowany i w po\u0142\u0105czeniu z praktykami Continous Integration, Continous Developement lub Continous Delivery stanowi\u0107 spos\u00f3b na wdra\u017canie naszych aplikacji.<\/p>\n\n\n\n
Na koniec jeszcze ma\u0142e s\u0142owo wyja\u015bnienia. Buduj\u0105c obraz, pos\u0142u\u017cy\u0142em si\u0119 bezpo\u015brednim wykorzystaniem polecenia \u201edocker build\u201d. Istniej\u0105 te\u017c inne rozwi\u0105zania, kt\u00f3re wspomagaj\u0105 ten proces (np.: S2I<\/a>, kubernetes maven plugin<\/a>). Jednak celowo o nich nie wspomnia\u0142em,\u00a0poniewa\u017c dodaj\u0105 dodatkow\u0105 warstw\u0119 abstrakcji do projektu i takie wybory powinny by\u0107 \u015bwiadome po poznaniu podstaw.<\/p>\n\n\n\n
Dodatkowo, trzymaj\u0105c si\u0119 regu\u0142y KISS<\/a>\u00a0(ang. Keep It Simple, Stupid) nasz proces powinien by\u0107 mo\u017cliwie prosty.\u00a0Dzi\u0119ki temu \u0142atwiej jest go zautomatyzowa\u0107 \ud83d\ude42<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Zaktualizowane w 2021 i 2022 artyku\u0142y nt. Dockera<\/strong><\/p>\n\n\n\n