Odhad velikosti kontejneru Docker
What is Docker Container Size Estimator?
▾
Docker Container Size Estimator vypočítá přibližnou velikost obrazu Dockeru na základě výběru základního obrazu (scratch, alpine, distroless, debian, ubuntu), runtime (Node.js, Python, Go, Java, Ruby), závislostí balíčků, kódu aplikace a volitelných nástrojů pro sestavení. Velikost kontejneru má podstatný praktický dopad: doba stahování (rychlost zpracování CI/CD a odezva automatického škálování), náklady na úložiště (DockerHub, AWS ECR, registrační poplatky GCR), bezpečnostní povrch (více kódu = více potenciálních zranitelností) a produktivita vývojáře. Obraz o velikosti 50 MB se nasadí během několika sekund; obraz o velikosti 800 MB zabere minuty a působí pomalu v celém pracovním postupu vývoje. Složení obrazu dockeru se řídí předvídatelnými vzory. Základní vrstva (operační systém nebo prostředí minimálního běhu) poskytuje základní knihovny. Runtime vrstva (jazykový interpret nebo kompilovaná binární podpora) přidává 0-170 MB v závislosti na jazyku. Závislosti balíčků (npm, pip, apt-get) se obvykle pohybují v rozmezí 5–50 MB na balíček v závislosti na ekosystému a konkrétních knihovnách. Kód aplikace je obvykle nejmenší komponenta (10–100 MB pro většinu aplikací). Nástroje pro sestavení (kompilátory, závislosti pro vývojáře) přidají 100–500 MB, pokud zůstanou ve finálním obrazu bez vícefázového sestavení. Volba základního obrázku dramaticky ovlivňuje celkovou velikost. Scratch (0 MB) funguje pro kompilované statické binární soubory (Go, Rust) a vytváří obrázky o celkové velikosti 10-30 MB. Alpine (7 MB) je nejoblíbenější minimální linuxová základna – rychlé stahování, ale používá musl libc, což může způsobit problémy s kompatibilitou s některými koly Pythonu a Java aplikacemi. Distroless (Google, 25 MB) neobsahuje žádný shell nebo správce balíčků, poskytuje silné zabezpečení díky minimalizaci. Debian-slim (80 MB) vyvažuje velikost a kompatibilitu pro většinu případů použití. Full Debian (120 MB) nebo Ubuntu (78 MB) jsou vhodné, když potřebujete širokou kompatibilitu knihoven, ale jsou předimenzované pro většinu produkčních úloh. Tato kalkulačka pomáhá inženýrům správně dimenzovat jejich kontejnery před stavbou, porozumět nákladům na jednotlivé komponenty a identifikovat příležitosti k optimalizaci. Zadejte základní obrázek, runtime, počet balíčků a průměrnou velikost, velikost kódu aplikace, počet vrstev a zda zahrnout nástroje pro sestavení. Kalkulačka poskytuje celkovou velikost, velikostní kategorii (malá/střední/velká/velmi velká), odhadovanou dobu vytažení při 50 Mb/s a vizuální rozdělení podle komponent. Použijte funkci porovnání k testování alternativních základních obrazů a runtime, abyste našli optimální rovnováhu pro vaši aplikaci.
Calkulon makes complex calculations simple — built for students and everyday problem-solvers.
Vzorec
▾
Celková velikost = základní obrázek + běh + (počet balíčků × průměrná velikost balíčku) + kód aplikace + nástroje pro sestavení + (vrstvy × 0,5 MB)Variable Legend
▾
| Symbol | Jméno | Jednotka | Popis |
|---|---|---|---|
| B | Základní velikost obrázku | MB | Velikost základní vrstvy operačního systému. Scratch (0), Alpine (7), Wolfi (12), Distroless (25), Debian-slim (80), Ubuntu (78), Debian full (120). |
| R | Velikost runtime | MB | Vrstva jazykového běhu. Žádné pro statické binární soubory (0). Node.js 20 (~140 MB). Python 3.11 (~55 MB). Python-slim (~35 MB). Java 17 JRE (~170 MB). Java-slim (~100 MB). Ruby (~80 MB). |
| P | Počet balíků | count | Počet závislých balíčků (npm, pip, apt-get). Typické aplikace Node.js: 10–100 balíčků. Python: 5-30. Přejít: 0 (kompilováno). Počítá pouze skutečně odeslané přímé + tranzitivní závislosti. |
| P_s | Průměrná velikost balíčku | MB | Průměrná velikost na balení. Odlehčené knihovny: 1-5 MB. Rámce: 10-30 MB. Těžké ML/datové knihovny (numpy, scipy, tensorflow): 50-200 MB. Používá se k odhadu celkového příspěvku balíčku. |
| C | Velikost kódu aplikace | MB | Kód vaší aplikace v MB. Typické malé služby: 5-25 MB. Střední aplikace: 25–100 MB. Velké monolity: 100-500 MB. Zahrnuje zkompilované výstupy, statická aktiva a konfigurační soubory. |
| L | Počet vrstev | count | Počet vrstev v Dockerfile. Každý přidá ~0,5 MB režii. Typicky: 5-15 vrstev. Nadměrné (>20) vrstev snižuje efektivitu mezipaměti. Vícestupňové sestavení konečného obrazu obvykle 3-8 vrstev. |
| T | Celková velikost obrázku | MB | Součet všech složek. Kategorie: malé (<100 MB), střední (<300 MB), velké (<800 MB), velmi velké (>800 MB). Zacilte na malé nebo střední pro výrobu. |
How to Docker Container Size Estimator
▾
- 1Krok 1 — Vyberte základní obrázek: Vyberte základní vrstvu OS. Rozhodovací faktory: Scratch pro statické binární soubory (nejmenší, ale bez shellu/utilit), Alpine pro obecné použití (nejmenší se správcem balíčků), Distroless pro zabezpečení (bez shellu, velmi malý), Debian-slim pro kompatibilitu (nejběžnější produkce), plný Debian/Ubuntu pouze v případě, že je vyžadována široká kompatibilita knihoven.
- 2Krok 2 — Vyberte Runtime: Přidejte jazykový modul runtime na základnu. Staticky kompilované jazyky (Go, Rust) nepotřebují žádné runtime — vyberte 'none'. Interpretované jazyky potřebují běhové prostředí: Node.js, Python, Ruby, Java. Vyberte si tenké varianty, pokud jsou k dispozici (python-slim, java-slim) pro ~40% zmenšení velikosti s většinou ekvivalentní funkčností.
- 3Krok 3 — Zadejte informace o balíčku: Počítejte přímé + tranzitivní balíčky, na kterých vaše aplikace závisí za běhu (pouze produkce, nikoli závislosti na vývoji). Najít pomocí 'npm ls --production' (Node), 'pip list' (Python), 'go list -m all' (Go). Odhadněte průměrnou velikost balíčku nebo použijte výchozí hodnoty: 15 MB Node, 10 MB Python, 5 MB Go.
- 4Krok 4 — Zadejte velikost kódu aplikace: Změřte výstup vaší sestavené aplikace. Pro Node: 'du -sh dist/' nebo 'du -sh node_modules/.cache/' pro zobrazení kompilované velikosti. Pro Python: velikost zdrojového kódu (obvykle malá) plus jakákoli zkompilovaná rozšíření. Zahrnuje statické podklady (obrázky, CSS) dodávané s aplikací.
- 5Krok 5 — Zadejte počet vrstev: Otevřete svůj Dockerfile a spočítejte různé pokyny pro vytváření vrstev (RUN, COPY, ADD). Každý přidá ~0,5 MB režii metadat. Optimalizace: zkombinujte více příkazů RUN s && pro snížení počtu vrstev. Produkční Dockerfily mají obvykle 5-10 vrstev v konečném obrázku.
- 6Krok 6 — Include Build Tools: Zaškrtněte toto políčko, pokud váš Dockerfile uchovává nástroje pro sestavení (gcc, make, dev headers) ve finálním obrázku. Přidá ~200 MB. Obvykle označuje chybějící vícestupňovou optimalizaci sestavení. Odstranění nástrojů pro sestavení pomocí vícestupňových nástrojů může snížit velikost obrázku o 30–50 %.
- 7Krok 7 — Kontrola celkové velikosti a doporučení: Kalkulačka zobrazuje celkový počet MB, kategorii (od malých po velmi velké), odhadovanou dobu vytažení při připojení 50 Mb/s a rozdělení komponent v koláčovém grafu. Použijte funkci porovnání k testování alternativních základních obrázků nebo odeberte komponenty, abyste viděli vliv velikosti. Zacilte na malé (<100 MB) nebo střední (<300 MB) pro produkci.
Worked Examples
▾
Typický produkční obraz Node.js střední velikosti
Rozdělení: Alpine 7 MB + runtime Node 20 140 MB + 10 balíčků × 15 MB = 150 MB + aplikace 25 MB + 8 vrstev × 0,5 MB = celkem 326 MB. 150 MB v balíčcích je největší komponenta – většina možností optimalizace zahrnuje snížení počtu balíčků nebo použití lehčích alternativ (náhrada lodash nativním ES2022, nahrazení momentu date-fns).
Kontejner Optimal Go – zkompilovaný binární soubor v odkládacím obrázku
Go se zkompiluje do jediného statického binárního souboru bez závislostí na běhovém prostředí. Scratch base (0 MB) + zkompilovaný binární soubor (15 MB) + 3 vrstvy (1,5 MB) = celkem 16,5 MB. Táhne za 3 sekundy, nasazuje se okamžitě, nulová nevyužitá útočná plocha. Toto je zlatý standard pro optimalizaci velikosti kontejneru. Statické binární soubory Rust a C++ dosahují podobných výsledků.
Nabubřelý – potřebuje vícestupňovou optimalizaci sestavení
Rozdělení: Debian 120 MB + Python 55 MB + 20 balíčků × 15 MB = 300 MB + aplikace 50 MB + nástroje pro sestavení 200 MB + 12 vrstev × 0,5 MB = 731 MB. 200 MB sestavovací nástroje (kompilátory, dev hlavičky) jsou ve výrobě zbytečné. Vícefázové sestavení (kompilace v tlustém obrazu, kopírování artefaktů do tenkého běhového prostředí) by se snížilo na ~370 MB. Přechod na debian-slim nebo python-slim přináší dalších 30-50 MB úspory.
Rozumný produkční obraz Java – běhové moduly Java jsou ze své podstaty velké
Java JRE jsou velké (170 MB pro Java 17 base). Java-slim varianty snižují na 100 MB. Aplikační JAR přidávají objem. Celkových ~472 MB je pro Javu přiměřených, ale inženýrům zvyklým na Go (16 MB) nebo Node (300 MB) se to zdá velké. Nativní obraz Java GraalVM lze zkompilovat do malých statických binárních souborů (~50 MB), ale s kompromisy ve složitosti sestavení.
Real-World Applications
▾
Dimenzování požadavků na úložiště kanálu CI/CD před nasazením nových mikroslužeb
Porovnání kompromisů mezi základním obrazem pro bezpečnost a pohodlí v produkčním nasazení
Výpočet nákladů na úložiště registru (DockerHub, AWS ECR, GCR) pro organizace se stovkami obrázků
Optimalizace doby studeného startu Kubernetes pod zkrácením doby vytahování obrazu
Odhad nákladů na šířku pásma pro okrajová nasazení, kdy jsou obrazy stahovány do mnoha distribuovaných umístění
Základní obrázek a reference velikosti běhu
▾
| Obraz | Velikost | Poznámky |
|---|---|---|
| poškrábat | 0 MB | Prázdná základna pro statické binární soubory (Go, Rust) |
| alpský:nejnovější | 7 MB | Minimální Linux se správcem balíčků (musl libc) |
| základna wolfi | 12 MB | Chainguardova moderní alpská alternativa (glibc) |
| bez distroly/statické | 2 MB | Bezprostřední základna Google, žádná skořápka |
| distroless/nodejs | 55 MB | Runtime Node.js v distroless |
| distroless/java17 | 180 MB | Runtime Java 17 v distroless |
| debian:slim | 80 MB | Minimální Debian s apt |
| debian:nejnovější | 120 MB | Plný Debian s nástroji |
| ubuntu: nejnovější | 78 MB | Ubuntu LTS minimální |
| uzel:20 | 1 GB+ | Úplný soubor Node.js s nástroji pro vytváření – vyhněte se pro produkci |
| uzel:20-alpský | 140 MB | Node.js připravený na produkci |
| python:3.11 | 1 GB+ | Plný Python s nástroji pro vytváření |
| krajta:3.11-tenká | 120 MB | Produkční Python |
| krajta:3.11-alpská | 60 MB | Nejmenší Python (upozornění na kompatibilitu) |
Frequently Asked Questions
▾
Proč na velikosti nádoby záleží?
Větší obrazy znamenají: pomalejší kanály CI/CD (každé stisknutí stáhne obraz), pomalejší automatické škálování (studené starty se zvětší s rostoucí velikostí obrazu), vyšší náklady na úložiště registru (zejména pro organizace s mnoha službami), větší plocha pro útok (více kódu = více potenciálních CVE), delší doby návratu během incidentů. Snížením z 800 MB na 200 MB lze zkrátit dobu zpracování CI o 30–50 % a podstatně zlepšit rychlost opakování vývojářů.
Jaký je nejmenší praktický obrázek Node.js?
node:20-alpine (~140 MB) nebo použijte vícestupňové sestavení s distroless/nodejs jako konečnou fází (~80 MB). Pro maximální kompresi zvažte Bun (alternativní běhové prostředí JavaScriptu, tenké obrázky Docker) nebo kompilaci do Dena pomocí statických binárních souborů. Runtime Node.js AWS Lambda má celkem zhruba 40 MB. U většiny produkčních aplikací Node.js je s přiměřeným úsilím dosažitelných 100–200 MB.
Je alpské vždy nejlepší?
Ne — alpine používá musl libc místo glibc, což může způsobit problémy s kompatibilitou s některými balíčky. Běžné problémy: Python Wheels (numpy, scipy, pandy často potřebují glibc), problémy s kompilací Java JIT, některé nativní moduly Node.js. Distroless nebo debian-slim jsou pro Python bezpečnější; alpine exceluje pro Node.js, Go a Rust. Otestujte alpine vs slim ve vašem konkrétním stacku, než se zavážete.
Co je to vícestupňové sestavení?
Funkce Dockerfile, která používá více příkazů FROM. Build stage používá tlustý obraz se všemi kompilátory a dev nástroji; finální fáze používá tenký runtime obraz a zkopíruje pouze zkompilované artefakty z fáze sestavení. Typický vzor: vestavěný uzel:20 (těžký), kopie dist/ do uzlu:20-alpský (lehký) pro výrobu. Výsledkem je 40-70% zmenšení velikosti ve srovnání s jednostupňovými sestavami.
Jak zjistím, co dělá můj obrázek velkým?
Chcete-li zobrazit příspěvek velikosti vrstvy po vrstvě, použijte 'historii dockeru <image>'. 'dive' tool (CLI) poskytuje interaktivní prozkoumávání vrstev a ukazuje přesně, které soubory přispívají do každé vrstvy. 'docker images' s volbou --format pomáhá velikostem inventárních obrázků ve vašem zásobníku. Pro hloubkovou analýzu kontejner-diff (Google) porovnává dva obrázky a ukazuje rozdíly.
Co je špatného na použití plného debianu nebo ubuntu?
Nic ze své podstaty — ale obsahují stovky balíčků, které většina aplikací nepotřebuje (manové stránky, dokumentace, více shellů, vývojové nástroje). Pro produkční běhové prostředí obvykle potřebujete pouze knihovnu libc, své běhové prostředí a aplikaci. Tenké varianty zbaví nepotřebného obsahu. Plný debian/ubuntu používejte pouze v případě, že skutečně potřebujete širokou dostupnost nástrojů (vývojové sandboxy, CI runner).
Mám optimalizovat na velikost nebo rychlost sestavení?
Obojí, přičemž velikost má prioritu pro produkční obrazy a rychlost sestavení pro vývoj. Produkce: optimalizace pro malý výsledný obraz (vícefázové sestavení, tenké základny, optimalizace vrstev). Vývoj: optimalizace pro rychlé přírůstkové přestavby (ukládání do mezipaměti BuildKit, .dockerignore, vícefázové připojení mezipaměti). Tyto cíle se obvykle doplňují – dobře strukturované soubory Dockerfiles dosahují obojího.
Common Mistakes to Avoid
▾
- !Použití plného debian/ubuntu, když by fungovalo alpine, distroless nebo debian-slim – typické úspory 100+ MB při stejné funkčnosti.
- !Nepoužívá se vícestupňová sestavení – ponechává sestavení nástroje v produkčním obrazu, přičemž často zdvojnásobuje velikost tím, že zahrnuje nepoužívané kompilátory a hlavičky pro vývojáře.
- !Přílišné příkazy RUN vytvářející nadměrné vrstvy – každý zvyšuje režii o 0,5 MB a snižuje efektivitu mezipaměti. Zkombinujte související operace s && nebo použijte syntaxi heredoc.
- !apt-get install without --no-install-recommends — přidá desítky MB nežádoucích balíčků (manové stránky, dokumentace, navrhované nástroje), které produkce nikdy nepotřebuje.
- !Včetně adresářů .git, testovacích souborů, souborů README ve finálním obrazu přes 'COPY . .' — použijte .dockerignore k vyloučení vývojových artefaktů z produkčních obrázků.
Pro Tip
Použijte vícestupňová sestavení k dramatickému snížení velikosti konečného obrazu – vytvořte tlustý obraz pomocí všech nástrojů, zkopírujte pouze artefakty do tenkého obrazu za běhu. Typické 60-80% zmenšení velikosti. V kombinaci s .dockerignore vyloučíte testy, dokumenty, adresář .git a vývojové soubory. Většina aplikací Node.js může přejít od 1 GB+ obrázků do 200 MB s vícestupňovým + alpine. Většina aplikací Python od 1 GB+ do 250 MB s vícestupňovým + tenkým.
Did you know?
Nejmenší známý produkční obraz Dockeru má pouhých 3,5 kB – program Go „ahoj světe“ v základním obrázku. Docker byl původně spuštěn v roce 2013 s obrázky, které byly pro základní Linux větší než 500 MB. Více než deset let optimalizačních nástrojů, základů bez distribuce, vícestupňových sestavení a vylepšení jazykového ekosystému (statické binární soubory Go, tenký běhový modul Bunu) učinily 50–200 MB produkčních obrazů standardem. Některé společnosti hlásí nasazení celých mikroslužeb s průměrem pod 100 MB na službu.
References
Ratings & comments
Získejte týdenní matematické tipy
Připojte se k 12 000+ odběratelům, kteří každý týden dostávají tipy na kalkulačku.