De carpeta vacía a producción en OKE en 14 minutos
Pavan Madduri se cronometró: arrancó con una carpeta vacía y una idea de app en Go, y en 14 minutos tenía el contenedor corriendo sobre un cluster de Oracle Kubernetes Engine (OKE). El truco para desplegar aplicación Oracle Kubernetes rápido no fue ningún script secreto, sino docker init, la herramienta de scaffolding que viene incluida en la CLI de Docker y que le generó un Dockerfile production-ready sin escribir una línea de configuración a mano.
docker init es una herramienta interactiva integrada en la CLI de Docker que genera un Dockerfile, un .dockerignore y un docker-compose.yml ajustados al lenguaje de tu proyecto. Detecta (o te pregunta) la plataforma, la versión del runtime, el directorio del paquete principal y el puerto donde escucha tu servidor, y a partir de esas respuestas arma archivos con buenas prácticas ya aplicadas: multi-stage build, imagen base distroless y usuario no-root.
En 30 segundos
- 14 minutos reales: de carpeta vacía a deployment corriendo en OKE, según el experimento documentado por Pavan Madduri en dev.to (24/06/2026).
- docker init hace el laburo pesado: genera Dockerfile multi-stage, distroless y non-root sin que escribas configuración.
- Un solo cambio manual: Madduri solo agregó
-ldflagspara quitar símbolos de debug y achicar el binario. - El flujo es OCIR + OKE: build, push al registry de Oracle (
región.ocir.io) ykubectl applycontra un cluster existente.
¿Qué es docker init y cómo genera los archivos solo?
Ponele que tenés una idea de microservicio en Go y lo último que querés es pelearte con un Dockerfile a las once de la noche. Ahí entra docker init. Lo corrés dentro del directorio del proyecto y te tira un cuestionario corto.
Según la referencia oficial de docker init, la herramienta te pregunta qué plataforma usás, qué versión del runtime, cuál es el directorio relativo de tu paquete principal y en qué puerto escucha el server. En el caso de Madduri las respuestas fueron Go, 1.22, . y 8080.
Con eso genera tres archivos:
- Dockerfile: multi-stage, base distroless, usuario non-root. Defaults que, según el autor, son mejores que los Dockerfiles que escriben muchos equipos a mano.
- docker-compose.yml: mapeo de puertos y variables de entorno básicas.
- .dockerignore: excluye
.git, binarios y el directorio vendor. Razonable.
¿Qué necesitás antes de empezar?
No es magia total. Para reproducir el flujo necesitás algunas cosas en su lugar.
- Docker actualizado:
docker inites parte de la CLI moderna de Docker Desktop / Docker Engine reciente. - OCI CLI configurado: con tu perfil y tu tenancy de Oracle Cloud.
- Un auth token de OCI: es lo que vas a usar como contraseña para loguearte al registry.
- Un cluster OKE existente: el experimento no incluye crear el cluster desde cero, asume que ya lo tenés andando.
Si todavía estás eligiendo dónde correr tus contenedores o necesitás infraestructura web y dominios en Argentina, donweb.com es una opción local para arrancar.
Paso a paso: app en Go con docker init
El ejemplo de Madduri es deliberadamente simple. Inicializás el módulo con go mod init github.com/pmady/oci-api y escribís un servidor HTTP mínimo: un handler en / que devuelve la región leyendo os.Getenv("OCI_REGION"), un handler en /health y un http.ListenAndServe(":8080", nil).
Después viene la parte interesante. Corrés docker init, te aparece el “Welcome to the Docker Init CLI!”, respondés las cuatro preguntas y listo. Los tres archivos quedan generados en el directorio. ¿Cuánto tardás en esta etapa? Cerca de un minuto, contando lo que pensás cada respuesta.
¿Por qué el Dockerfile generado ya es production-ready?
Acá viene lo bueno: el Dockerfile que escupe la herramienta no es un placeholder de juguete. El propio autor dice que es casi idéntico al que escribiría él a mano. Te puede servir nuestra cobertura sobre pipelines de CI/CD automatizados.
- Multi-stage build: compila en una etapa y copia solo el binario a la imagen final, así no arrastrás el toolchain de Go a producción.
- Base distroless: usa
gcr.io/distroless/static-debian12:nonroot, una imagen sin shell ni gestor de paquetes, lo que reduce la superficie de ataque. - Usuario non-root: el contenedor corre sin privilegios de root por default.
- Binario estático: al ser un binario Go estático sobre distroless, la imagen final queda chica.
El único retoque que hizo Madduri fue agregar -ldflags en la compilación para quitar los símbolos de debug y achicar todavía más el binario. Nada más. El resto lo dejó como vino.
Publicar la imagen en OCIR y desplegar en OKE
Oracle Cloud Infrastructure Registry (OCIR) es el registro de contenedores de Oracle donde guardás tus imágenes. La estructura de la URL sigue el patrón región.ocir.io/tenancy/repo:tag, así que el tag de tu imagen tiene que respetar ese formato para que el push vaya al lugar correcto.
El flujo es el clásico: docker login contra OCIR usando tu auth token, docker build con el tag apuntando al registry y docker push. Una vez que la imagen está arriba, armás un manifest de deployment de Kubernetes que referencie esa imagen de OCIR y lo aplicás con kubectl apply contra tu cluster OKE. Ojo con un detalle de seguridad: para que OKE pueda hacer pull de una imagen privada de OCIR vas a necesitar un secret de tipo docker-registry referenciado en el spec del pod, si no el deployment se queda en ImagePullBackOff. Profundizamos sobre los secretos de Kubernetes en nuestra guía de PostgreSQL gestionado en la nube.
¿Cuánto tarda de verdad? Los tiempos reales
El número duro que confirma la fuente es uno solo: 14 minutos de punta a punta. El título redondea a 15. El desglose por etapa es orientativo y depende mucho de tu red, del tamaño de la imagen y de si el cluster ya está caliente.
| Etapa | Tiempo aproximado | De qué depende |
|---|---|---|
| docker init + código | ~1 min | Cuánto pensás cada respuesta |
| docker build | 3 a 5 min | Dependencias y caché de capas |
| docker push a OCIR | 2 a 3 min | Tamaño de imagen y ancho de banda |
| Deployment en OKE | 3 a 5 min | Pull del secret y readiness del cluster |
| Total | 14 a 15 min | Confirmado: 14 min en el test del autor |

Tomá el desglose con pinzas. El total de 14 minutos es el dato verificado; los tramos intermedios son una estimación razonable, no un cronómetro oficial por etapa.
Errores comunes al replicar este flujo
- Olvidarte del imagePullSecret: si el repo de OCIR es privado, OKE no puede bajar la imagen y el pod queda en ImagePullBackOff. Creá el secret docker-registry y referencialo en el spec.
- Tag con formato incorrecto: si no respetás
región.ocir.io/tenancy/repo:tag, el push falla o te lo manda al lugar equivocado. La región del tag tiene que coincidir con la de tu tenancy. - Usar tu password de Oracle en lugar del auth token: el login a OCIR pide el auth token generado en la consola de OCI, no la contraseña de tu usuario.
- Tocar los defaults del Dockerfile sin entenderlos: cambiar la base distroless por una imagen “más cómoda” con shell te suma superficie de ataque. Si Madduri solo agregó
-ldflags, por algo será.
Preguntas Frecuentes
¿Qué es docker init?
docker init es una herramienta interactiva incluida en la CLI de Docker que genera Dockerfile, .dockerignore y docker-compose.yml ajustados al lenguaje de tu proyecto. La corrés en el directorio del proyecto, respondés unas pocas preguntas (plataforma, versión, puerto) y obtenés archivos con buenas prácticas ya aplicadas. Cubrimos ese tema en detalle en orquestación automatizada de despliegues.
¿Cuánto se tarda en desplegar una app en OKE con este método?
14 minutos de carpeta vacía a deployment corriendo, según el experimento documentado por Pavan Madduri en dev.to. El tiempo varía con el tamaño de la imagen, tu ancho de banda y si el cluster OKE ya está listo.
¿Qué es OCIR?
OCIR (Oracle Cloud Infrastructure Registry) es el registro de contenedores de Oracle Cloud donde almacenás y distribuís tus imágenes Docker. Las URLs siguen el patrón región.ocir.io/tenancy/repo:tag y el login se hace con un auth token generado en la consola de OCI.
¿El Dockerfile generado sirve para producción sin tocarlo?
En el caso de Madduri sí, casi. Trae multi-stage build, base distroless y usuario non-root por default. El único cambio que hizo fue agregar -ldflags para quitar símbolos de debug y achicar el binario.
¿Necesito crear el cluster OKE para seguir este flujo?
No, el experimento asume un cluster OKE ya existente. Los 14 minutos cuentan desde la carpeta vacía hasta el deployment, pero no incluyen el aprovisionamiento del cluster, que se hace una sola vez y por separado.
Conclusión
Lo que cambió acá no es que Oracle haya lanzado nada nuevo, sino que docker init elimina la fricción que solía comerte la primera hora de cualquier proyecto en contenedores. El Dockerfile que antes copiabas de un gist viejo ahora lo genera la CLI con defaults de seguridad sensatos.
Si ya tenés un cluster OKE andando, el camino es claro: corré docker init, revisá el Dockerfile (no lo apliques a ciegas), pusheá a OCIR con el tag bien formado y aplicá el manifest con su imagePullSecret. Los 14 minutos de Madduri son reproducibles si tenés los requisitos en orden. El cuello de botella real no va a ser el scaffolding, va a ser tu red y la readiness de tu cluster.
Fuentes
- docker init OCIR OKE: From Empty Folder to Production in 15 Minutes – experimento original de Pavan Madduri (dev.to)
- Referencia oficial de docker init – documentación de Docker
- Oracle Cloud Infrastructure Registry (OCIR) – documentación oficial de Oracle
- Oracle Kubernetes Engine (OKE) – documentación oficial de Oracle






