Прескочи на главни садржај
🔒 Режим прегледа. Првих петнаест Foundations лекција је бесплатно; ова је Pro. Покрените 7-дневни trial да откључате едитор, AI савете и остатак курса. Картица је обавезна, можете отказати у било ком тренутку у Dashboard.
Покрени 7-дневни trial →
⚡
← Kursevi
›
DevOps for Python services
›
Модул 1 · Доцкер & Цонтаинерс
›
Основе Доцкер-а за Питхон
quiz
2 / 104
🇷🇸
SR
▼
↗
Подели
⋯
Више
+100 XP
📋
Zadatak
📖
Teorija
🤖
AI Pomoć
Zadatak
📝 **Питање:** Зашто користити вишестепени Доцкерфиле за Питхон услуге? 📋 Изаберите тачан одговор. 💡 **Савет:** Поново прочитајте горњу теорију ако нисте сигурни.
🎯 Kviz
Pitanje
📝 **Питање:** Зашто користити вишестепени Доцкерфиле за Питхон услуге? 📋 Изаберите тачан одговор. 💡 **Савет:** Поново прочитајте горњу теорију ако нисте сигурни.
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
Odgovori
💬 Diskusija
Budi prvi — postavi pitanje ili podeli savet.
Prijavi se
da bi se pridružio diskusiji. Čitanje je besplatno.
Učitavanje diskusije…