Ugrás a fő tartalomra
🔒 Előnézet mód. Az első tizenöt Foundations lecke ingyenes; ez Pro. Indíts 7 napos trial-t, hogy feloldd a szerkesztőt, az AI tippeket és a tananyag többi részét. Kártya szükséges, bármikor lemondhatod a Dashboard-ban.
7 napos trial indítása →
⚡
← Kurzusok
›
DevOps for Python services
›
1. modul · Dokkoló és konténerek
›
A Docker alapjai Pythonhoz
quiz
2 / 104
🇭🇺
HU
▼
↗
Megosztás
⋯
Több
+100 XP
📋
Feladat
📖
Elmélet
🤖
AI Segítség
Feladat
🌐 shown in EN
📝 **Question:** Why use a multi-stage Dockerfile for Python services? 📋 Pick the right answer. 💡 **Hint:** Re-read the theory above if unsure.
🎯 Kvíz
Kérdés
📝 **Question:** Why use a multi-stage Dockerfile for Python services? 📋 Pick the right answer. 💡 **Hint:** Re-read the theory above if unsure.
A
It's the only Dockerfile shape modern BuildKit accepts — single-stage Dockerfiles silently fail on `docker build` since the 24.0 release that landed across the major Linux distributions late last year
B
Build tools (gcc, dev headers, uv) stay in the builder stage; only compiled wheels and source make it to the runtime image. Result: 5-10x smaller production images, faster pulls, faster cold starts
C
Kubernetes requires it as of v1.30 — the kubelet refuses to schedule pods built from a single-stage image because the layer-cache hashing changed for OCI v1.1 spec compliance reasons across the cluster
D
Multi-stage images run noticeably faster at request-handling time because the Python interpreter walks fewer layer-overlay paths during import resolution, especially under high concurrency and cold-cache loads
Válaszolj
💬
Ügyfélszolgálat