[2024-XX-XX] Tworzenie wydajnych obrazów dockerowych w Springu #246
Conversation
| @@ -0,0 +1,329 @@ | |||
| --- | |||
| layout: post | |||
| title: "Tworzenie wydajnych obrazów dockerowych w Springu" | |||
There was a problem hiding this comment.
IMO to raczej tworzenie jest wydajniejsze a nie same obrazy. Może lepiej by było "Wydajne tworzenie" zamiast "Tworzenie wydajnych"
There was a problem hiding this comment.
poprawione
|
|
||
| W poprzedniej sekcji został pokazany standardowy plik Dockerfile dla zbudowania aplikacji Spring Bootowej. Jedną z zawartych w nim instrukcji jest przekopiowanie pliku .jar do obrazu. Standardowo wykonuje się to za pomocą jednej instrukcji co powoduje, że każda zmiana w jakimkolwiek pliku aplikacji wymaga utworzenia warstwy od nowa. | ||
|
|
||
| Jest to bardzo niekorzystne, ponieważ niesie to za sobą wykorzystywanie nadmiernej przestrzeni dyskowej. Przyjmując, że plik .jar waży około 20 MB (gdzie większość to zależności aplikacji) wykonanie 10 wersji aplikacji zajmie nam 200 MB, pomimo że zmiany, jakie wykonaliśmy, były bardzo niewielkie i dotyczyły tylko kodów źródłowych (ważących kilkanaście KB). |
There was a problem hiding this comment.
"ważących kilkanaście KB" - nie zawsze, czasami kody potrafią być bardzo duże ;) może zmieńmy na "ważących przeciętnie kilkanaście KB"
There was a problem hiding this comment.
poprawione
| Tutaj naprzeciw wyszli nam twórcy Spring Boota, dodając od wersji 2.3 możliwość budowania warstwowego pliku jar (eng. **layered jars**). | ||
|
|
||
| ## Jak działa Spring Boot layered jar? | ||
| Spring Boot layered jar zmienia sposób budowania pliku .jar, dzieląc jego części na konkretne warstwy. Wykorzystuje w tym celu plik **layers.idx**. Plik ten zawiera listę warts oraz części pliku .jar, które są w niej zawarte. Warstwy w pliku zapisane są w kolejności, w jakiej powinny zostać dodane do obrazu Dockerowego. Domyślnie plik składa się z poniższych warstw: |
There was a problem hiding this comment.
"listę warts" -> "listę warstw"
There was a problem hiding this comment.
poprawione
| - **snapshot-dependencies** - zawiera zależności aplikacji, które są w wersji SNAPSHOT | ||
| - **application** - zawiera kod źródłowy aplikacji | ||
|
|
||
| Dzięki takiemu rozwiązaniu jesteśmy w stanie podzielić instrukcję kopiowania pliku .jar na kilka mniejszych instrukcji i zapewnić wykorzystanie ponownych warstw, gdy zmienimy tylko kod źródłowy aplikacji. |
There was a problem hiding this comment.
"zapewnić wykorzystanie ponownych warstw" -> "zapewnić ponowne wykorzystanie warstw"
There was a problem hiding this comment.
poprawione
| COPY --from=builder /work/spring-boot-loader/ ./ | ||
| COPY --from=builder /work/snapshot-dependencies/ ./ | ||
| COPY --from=builder /work/application/ ./ | ||
| ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"] |
There was a problem hiding this comment.
A tak z ciekawości - wcześniej mieliśmy CMD a tutaj ENTRYPOINT - pomiędzy jednym i drugim jest różnica. Dlaczego CMD stał się zły?
There was a problem hiding this comment.
CMD nie stał się zły, gdzieś w momencie pisania własnych obrazów zasugerowałem się przykładami z Internetu i tam był ENTRYPOINT. Poprawić to tak żeby było spójnie?
There was a problem hiding this comment.
ujednolicone do CMD
| <layers xmlns="http://www.springframework.org/schema/boot/layers" | ||
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | ||
| xsi:schemaLocation="http://www.springframework.org/schema/boot/layers | ||
| https://www.springframework.org/schema/boot/layers/layers-{spring-boot-xsd-version}.xsd"> |
There was a problem hiding this comment.
spring-boot-xsd-version - może warto zaznaczyć, że tu trzeba wpisać numerek ;)
| <layer>dependencies</layer> | ||
| <layer>spring-boot-loader</layer> | ||
| <layer>snapshot-dependencies</layer> | ||
| <layer>jaxb-dependencies</layer> |
There was a problem hiding this comment.
ta kolejność sugeruje, że jaxb zmienia się częściej niż snapshot
There was a problem hiding this comment.
zamienione
| } | ||
| intoLayer("dependencies") | ||
| } | ||
| layerOrder = listOf("dependencies", "spring-boot-loader", "snapshot-dependencies", "application", "jaxb-dependencies") |
There was a problem hiding this comment.
jaxb-dependencies na końcu? chyba bez sensu
There was a problem hiding this comment.
poprawione
| COPY --from=builder /work/dependencies/ ./ | ||
| COPY --from=builder /work/spring-boot-loader/ ./ | ||
| COPY --from=builder /work/snapshot-dependencies/ ./ | ||
| COPY --from=builder /work/jaxb-dependencies/ ./ |
There was a problem hiding this comment.
ta kolejność sugeruje, że jaxb zmienia się częściej niż snapshot
There was a problem hiding this comment.
poprawione
|
|
||
|
|
||
| ## Podsumowanie | ||
| Wykorzystanie warstwowego budowania plików jar może pomóc z znacznym zmniejszeniu pamięci dyskowaej wykorzystywanej na przechowywanie gotowych obrazów Docker. Warto pamiętać o prawidłowej kolejności operacji w pliku Dockerfile oraz o możliwości definiowania własnych warstw zależności. |
There was a problem hiding this comment.
"pamięci dyskowaej" -> "pamięci dyskowej"
There was a problem hiding this comment.
poprawione
…ithub.com:Consdata/consdata.github.io into tworzenie-wydajnych-obrazow-dockerowych-w-springu
| </layers> | ||
| ``` | ||
|
|
||
| Należy pamiętaj aby przy konfiguracji pliku layers.xml uzupełnić wersję zapisaną pod zmienną _spring-boot-xsd-version_ |
There was a problem hiding this comment.
poprawione
|
|
||
| Należy pamiętaj aby przy konfiguracji pliku layers.xml uzupełnić wersję zapisaną pod zmienną _spring-boot-xsd-version_ | ||
|
|
||
| 2.Do plugina tworzącego warstwowego jarka dodajemy wskazanie na pliku z konfiguracją warstw |
There was a problem hiding this comment.
spacja, literówka i kolokwializm :)
sugestia:
w konfiguracji plugina tworzącego warstwowego jara wskazujemy plik z konfiguracją warstw
There was a problem hiding this comment.
w konfiguracji plugina tworzącego warstwowy .jar wskazujemy plik z konfiguracją warstw
?
There was a problem hiding this comment.
poprawione
pogoma
changed the title
| --- | ||
|
|
||
| ## Jak działa budowanie obrazów Dockerowych? | ||
| Budowanie obrazów Dockerowych polega na tworzeniu niemodyfikowalnych "szablonów" aplikacji i jej zależności, które mogą być uruchamiane w izolowanych kontenerach. Proces ten jest zautomatyzowany za pomocą plików o nazwie Dockerfile. |
There was a problem hiding this comment.
obrazów dockerowych (z małej)
to "jej" wydaje mi się tu zbędne
There was a problem hiding this comment.
poprawione
| ## Jak działa budowanie obrazów Dockerowych? | ||
| Budowanie obrazów Dockerowych polega na tworzeniu niemodyfikowalnych "szablonów" aplikacji i jej zależności, które mogą być uruchamiane w izolowanych kontenerach. Proces ten jest zautomatyzowany za pomocą plików o nazwie Dockerfile. | ||
|
|
||
| Każdy plik Dockerfile zawiera listę instrukcji wykonywanych w podanej kolejności w momencie budowania obrazu. Docker otrzymaną listę instrukcji konwertuje na warstwy składające się na budowany obraz i posiadające określony rozmiar w przestrzeni dyskowej. |
There was a problem hiding this comment.
Docker konwertuje otrzymaną listę instrukcji na warstwy, które składają się na budowany obraz i mają określony rozmiar w przestrzeni dyskowej.
There was a problem hiding this comment.
poprawione
|
|
||
|  | ||
|
|
||
| Podczas uruchomienia budowania builder podejmuję próbę ponownego wykorzystania warstw z poprzednich wersji. Jeśli warstwa obrazu się nie zmieni, builder wyciąga ją z cache, a jeśli warstwa uległa zmianie tworzy ją na nowo. |
There was a problem hiding this comment.
Jeśli warstwa obrazu jest niezmieniona, builder wyciąga ją z cache. Jeśli warstwa uległa zmianie, tworzy ją na nowo.
There was a problem hiding this comment.
poprawione
|
|
||
|  | ||
|
|
||
| W tym wypadku bardzo ważna jest kolejność deklarowania instrukcji tak, aby największa ich ilość była pobierania z cache. Dla powyższego przykładu możemy wykonać optymalizację: |
There was a problem hiding this comment.
tak stricte gramatycznie to w tym zdaniu "ich" odnosiłoby się do instrukcji...a chodzi chyba o warstwy?
odwróciłabym to zdanie (chyba, że jednak źle interpretuję)
Aby z cache była pobierana jak największa liczba warstw, bardzo ważna jest kolejność deklarowania instrukcji.
There was a problem hiding this comment.
poprawione
| W tym wypadku bardzo ważna jest kolejność deklarowania instrukcji tak, aby największa ich ilość była pobierania z cache. Dla powyższego przykładu możemy wykonać optymalizację: | ||
|  | ||
|
|
||
| Dzięki temu przy następnym budowaniu trzy warstwy zostaną ponownie wykorzystane zamiast dwóch. |
There was a problem hiding this comment.
Dzięki temu, przy następnym budowaniu, builder ponownie wykorzysta trzy, a nie tylko dwie warstwy.
może tak?
There was a problem hiding this comment.
Tak brzmi lepiej, poprawiłem
| </layers> | ||
| ``` | ||
|
|
||
| Należy pamiętaj aby przy konfiguracji pliku layers.xml uzupełnić wersję zapisaną pod zmienną _spring-boot-xsd-version_ |
|
|
||
| Należy pamiętaj aby przy konfiguracji pliku layers.xml uzupełnić wersję zapisaną pod zmienną _spring-boot-xsd-version_ | ||
|
|
||
| 2.Do plugina tworzącego warstwowego jarka dodajemy wskazanie na pliku z konfiguracją warstw |
There was a problem hiding this comment.
w konfiguracji plugina tworzącego warstwowy .jar wskazujemy plik z konfiguracją warstw
?
| } | ||
| } | ||
| ``` | ||
| W pliku dockerfile dodajemy kopiowanie nowej warstwy: |
There was a problem hiding this comment.
poprawione
|
|
||
|
|
||
| ## Podsumowanie | ||
| Wykorzystanie warstwowego budowania plików jar może pomóc ze znacznym zmniejszeniem pamięci dyskowej wykorzystywanej na przechowywanie gotowych obrazów Docker. Warto pamiętać o prawidłowej kolejności operacji w pliku Dockerfile oraz o możliwości definiowania własnych warstw zależności. |
There was a problem hiding this comment.
Warstwowe budowanie plików .jar może znacznie zmniejszyć wykorzystanie pamięci dyskowej, w której przechowujemy gotowe obrazy Docker.
?
There was a problem hiding this comment.
poprawione
| - docker | ||
| --- | ||
|
|
||
| ## Jak działa budowanie obrazów Dockerowych? |
There was a problem hiding this comment.
imo, jako przymiotnik, "dockerowy" możemy pisać małą literą
There was a problem hiding this comment.
poprawione
No description provided.