Proces<\/h2>\n\n\n\n
Ka\u017cdorazowe budowanie obrazu opiera si\u0119 o szereg czynno\u015bci, z kt\u00f3rych cz\u0119\u015b\u0107 jest jednorazowa, jak np. napisanie Dockerfile\u2019a, inne za\u015b s\u0105 powtarzalne, np. uruchomienie budowania poprzez odpowiednie polecenie. Standardowy przebieg tego procesu wygl\u0105da w nast\u0119puj\u0105cy spos\u00f3b:<\/p>\n\n\n\n
- \n
- Instalacja Dockera
<\/u>O ile punkt ten jest raczej jasny i nie trzeba go t\u0142umaczy\u0107, to warto doda\u0107, \u017ce na systemach z rodziny Windows mo\u017ce on sprawia\u0107 trudno\u015bci, gdy\u017c Docker wspiera ten system dopiero od wersji 10.<\/li>\n\n\n\n- Napisanie Dockerfile\u2019a<\/u>
Dockerfile dockerfile\u2019owi nier\u00f3wny. Samo utworzenie tej konfiguracji jest rzecz\u0105 jednorazow\u0105 i wzgl\u0119dnie prost\u0105, jednak mo\u017cna to zrobi\u0107 w poprawny lub optymalny spos\u00f3b.<\/li>\n\n\n\n- Zbudowanie projektu<\/u><\/u><\/u><\/li>\n\n\n\n
- Utworzenie obrazu aplikacji<\/u>
Jest to najbardziej powtarzalna z czynno\u015bci, kt\u00f3ra polega na wywo\u0142aniu polecenia \u201edocker build\u201d<\/em>. Problematyczno\u015b\u0107 mo\u017ce powsta\u0107 w przypadku, gdy nasz projekt si\u0119 rozrasta, a wraz z nim ro\u015bnie poziom zaawansowania aplikacji. W takim przypadku owe polecenie z wersji podstawowej r\u00f3wnie\u017c mo\u017ce si\u0119 rozrosn\u0105\u0107 o zestaw dodatkowych opcji. I o ile samo to nie jest problemem, to w przypadku, gdy za kt\u00f3r\u0105\u015b iteracj\u0105 zapomnimy o jednym z nich mo\u017ce doj\u015b\u0107 do utraty kilku godzin czasu pracy i zyskaniu kilku nowych siwych w\u0142os\u00f3w.<\/li>\n\n\n\n- Wypchni\u0119cie projektu<\/u>
Nie jest to cz\u0119\u015b\u0107 budowania obrazu, gdy\u017c takowy mamy ju\u017c po wykonaniu punktu 4 (o ile nie pope\u0142nili\u015bmy jakiego\u015b b\u0142\u0119du po drodze), jednak bardzo cz\u0119sto zachodzi r\u00f3wnie\u017c potrzeba umieszczenia go z kontenerze obraz\u00f3w.<\/li>\n<\/ol>\n\n\n\nKa\u017cdy z wy\u017cej wymienionych punkt\u00f3w mo\u017ce sprawia\u0107 problemy lub po prostu sprawia\u0107 k\u0142opot swoim istnieniem. Jib pozwala zniwelowa\u0107 te problemy praktycznie do zera, a powy\u017csz\u0105 list\u0119 skr\u00f3ci\u0107 do zaledwie jednego punktu, kt\u00f3rym jest zbudowanie projektu. Skoro mamy ju\u017c odpowied\u017a na pytanie „Po co?”, sprawd\u017amy teraz jak brzmi odpowied\u017a na pytanie „Jak?”.<\/p>\n\n\n\n
Nieco praktyki<\/h2>\n\n\n\n
Program, kt\u00f3ry b\u0119dziemy pr\u00f3bowali uruchomi\u0107 to prosta aplikacja oparta o Spring Boot, zawieraj\u0105ca jeden endpoint zwracaj\u0105cy \u201eHello World!\u201d.<\/p>\n\n\n
\npackage com.jibintroduction;\n \nimport org.springframework.boot.SpringApplication;\nimport org.springframework.boot.autoconfigure.SpringBootApplication;\nimport org.springframework.web.bind.annotation.GetMapping;\nimport org.springframework.web.bind.annotation.RestController;\n \n@RestController\n@SpringBootApplication\npublic class JibIntroductionApplication {\n \n public static void main(String[] args) {\n SpringApplication.run(JibIntroductionApplication.class, args);\n }\n \n @GetMapping(\"\/say\/hello\")\n String sayHello() {\n return \"Hello World!\";\n }\n}\n<\/pre><\/div>\n\n\nPierwszym krokiem jest dodanie odpowiedniego pluginu. Zar\u00f3wno w przypadku korzystania z Gradle, jak i Mavena konfiguracja wygl\u0105da analogicznie, tj. nazwy p\u00f3l i mo\u017cliwe warto\u015bci s\u0105 takie same. Jedyna r\u00f3\u017cnica wyst\u0119puje w nazwach goali, jednak o tym opowiem p\u00f3\u017aniej. Prezentowany przyk\u0142ad wykorzystywa\u0142 b\u0119dzie narz\u0119dzie Gradle.<\/p>\n\n\n
\nplugins {\n id 'org.springframework.boot' version '2.4.4'\n id 'io.spring.dependency-management' version '1.0.11.RELEASE'\n id 'java'\n id 'com.google.cloud.tools.jib' version '2.8.0'\n}\n<\/pre><\/div>\n\n\nAby plugin ten m\u00f3g\u0142 poprawnie wykonywa\u0107 swoje zadanie potrzebuje przynajmniej minimalnej konfiguracji. Nale\u017cy zdefiniowa\u0107, kt\u00f3ry obraz ma by\u0107 obrazem bazowym dla naszej aplikacji (FROM<\/em>) oraz jak ma si\u0119 nazywa\u0107 obraz wynikowy (TO<\/em>).<\/p>\n\n\n
\njib {\n from {\n image = 'openjdk:alpine'\n }\n to {\n image = 'repositoryName\/jib-introduction'\n }\n}\n<\/pre><\/div>\n\n\nAplikacja, kt\u00f3r\u0105 utworzona na potrzeby tego artyku\u0142u b\u0119dzie domy\u015blnie nas\u0142uchiwa\u0142a na ruch na porcie 8080, dlatego nale\u017cy ten port aktywowa\u0107 (odpowiednik EXPOSE 8080 w dockerfile). Lista opcji, kt\u00f3re mo\u017cna ustawi\u0107 w tym miejscu jest naprawd\u0119 du\u017ca. Dla przyk\u0142adu mo\u017cna doda\u0107 list\u0119 argument\u00f3w, z kt\u00f3rymi zostanie uruchomiona nasza aplikacja.<\/p>\n\n\n
\ncontainer {\njvmFlags = ['-Xms1024m', '-Xdebug']\nargs = ['some', 'random', 'input', 'text']\nports = ['8080']\n}\n<\/pre><\/div>\n\n\nKonfiguracja konieczna do utworzenia prostego obrazu jest gotowa, jednak to nie wszystko. Pozostaje nam jeszcze skonfigurowanie dost\u0119pu do rejestru obraz\u00f3w. Mowa konkretnie o autoryzacji.
Sposob\u00f3w jest kilka, a to, kt\u00f3ry nale\u017cy u\u017cy\u0107 zale\u017cy od rejestru, kt\u00f3ry wykorzystujemy. Opis tego zagadnienia to materia\u0142 na kolejny artyku\u0142, dlatego tym razem skupimy si\u0119 na rejestrze dockerhuba. W tym przypadku nale\u017cy jedynie poda\u0107 nazw\u0119 u\u017cytkownika oraz has\u0142o (warto\u015bci USERNAME oraz PASSWORD ustawione zosta\u0142y w pliku gradle.properties).<\/p>\n\n\n\njib {\n from {\n image = 'openjdk:alpine'\n }\n to {\n image = 'repositoryName\/jib-introduction'\n tags = ['latest', '1.0.0']\n auth {\n username = USERNAME\n password = PASSWORD\n }\n }\n}\n<\/pre><\/div>\n\n\nNast\u0119pnym krokiem jest uruchomienie pluginu oraz sprawdzenie, czy obraz trafi\u0142 do rejestru. Goale, z kt\u00f3rych nale\u017cy skorzysta\u0107 wygl\u0105daj\u0105 nast\u0119puj\u0105co: Zbudowanie i umieszczenie w Docker deamon:\u00a0jibDockerBuild (Gradle)<\/em>,\u00a0dockerBuild (Maven).
<\/em>Zbudowanie i umieszczenie w zewn\u0119trznym rejestrze obraz\u00f3w:\u00a0build (Gradle \/ Maven).\u00a0<\/em>Przyk\u0142adowy wynik, kt\u00f3ry mo\u017cemy otrzyma\u0107 po umieszczeniu obrazu w Dockerhub:<\/p>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2023\/10\/jib-ostatni-1-1024x562-1.png\")
<\/a><\/figure>\n\n\n\n<\/div>\n\n\n\nPowy\u017csza konfiguracja jest wystarczaj\u0105ca, by uruchomi\u0107 przyk\u0142adow\u0105 aplikacj\u0119. Istnieje jednak szereg parametr\u00f3w, kt\u00f3re mog\u0105 dosta\u0107 skonfigurowane. Umo\u017cliwiaj\u0105 m.in. zdefiniowanie bardziej skomplikowanego punktu wej\u015bcia\/ uruchomienia aplikacji, dodanie wolumen\u00f3w i wiele innych rzeczy. Zach\u0119cam do zapoznania si\u0119 z nimi. Mo\u017cna je bez problemu znale\u017a\u0107 w dokumentacji Jiba.<\/p>\n\n\n\n
Po pobraniu obrazu z repozytorium Dockerhub i uruchomieniu kontenera powinni\u015bmy zobaczy\u0107 standardowe logi Spring Boota (o ile nie u\u017cyli\u015bmy flagi -d<\/em><\/strong>). Nast\u0119pnie mo\u017cna przej\u015b\u0107 do sprawdzenia, czy wszystko dzia\u0142a. Po wywo\u0142aniu polecenia curl <\/em>http:\/\/localhost:8080\/say\/hello<\/em><\/a> naszym oczom powinien ukaza\u0107 si\u0119 napis „Hello World!”.<\/p>\n\n\n\n
Podsumowanie<\/h2>\n\n\n\n
Zadaniem Jiba jest zautomatyzowanie pracy developera oraz zniwelowanie szansy na b\u0142\u0119dy natury ludzkiej spowodowanych m.in. powtarzalno\u015bci\u0105 dzia\u0142a\u0144, niedoinformowaniem lub brakiem do\u015bwiadczenia. Na powy\u017cszym przyk\u0142adzie wida\u0107, \u017ce doskonale radzi sobie ze swoim zadaniem. W dodatku jest narz\u0119dziem o bardzo niskim progu wej\u015bcia i nie wymaga kl\u0119czenia nad dokumentacj\u0105, a niniejszy artyku\u0142 powinien wystarczy\u0107, by m\u00f3c rozpocz\u0105\u0107 prac\u0119 z owym pluginem. Gor\u0105co zach\u0119cam do samodzielnego przetestowania Jiba i zag\u0142\u0119bienia si\u0119 w dokumentacj\u0119. ?<\/p>\n\n\n
- Napisanie Dockerfile\u2019a<\/u>