> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Contenerización

> En este tutorial, te mostraremos cómo Devin puede configurar un contenedor Docker para estandarizar el entorno de desarrollo de tu equipo.

<div id="creating-a-docker-container">
  ## Creación de un contenedor Docker
</div>

Dado que Devin tiene acceso a un terminal y puede configurar y ejecutar software en su propio servidor, configurar un contenedor Docker está perfectamente dentro de sus capacidades.

Nuestra aplicación de ejemplo es un proyecto en Go con MongoDB como almacén de datos. Esta sesión es la versión de Devin de un pull request que un desarrollador real hizo a un proyecto de código abierto. Puedes seguir la ejecución en vivo [aquí](https://app.devin.ai/sessions/379eb9a40ff2433db49e51c95c7d9bc1?ts=1729908167981).

<div id="start-with-a-github-issue">
  #### Comenzar con un issue de GitHub
</div>

Comenzamos con el issue original de GitHub:

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/e8a410ab96ee363911b146bcbd923da43c25b03a-1856x746.png)
</Frame>

A continuación, podemos escribir un prompt sencillo para Devin en función de lo que solicita este issue. Le indicamos que lea el issue de GitHub anterior para obtener contexto adicional, pero también le damos nuestro propio resumen de la solución propuesta y de lo que queremos que Devin produzca.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/4caecf4fd393f5573536a5b6d57d7246b684d699-1312x612.png)
</Frame>

<div id="investigating-the-codebase">
  #### Investigando la base de código
</div>

Devin comienza con una etapa de investigación en la que lee nuestro issue de GitHub vinculado y [escanea](/es/release-notes#repo-knowledge) el código real y los archivos de configuración del proyecto en busca de las dependencias necesarias.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/4f146e093bd0374b5d816c5fd9f49d6a411d6c8f-1334x844.png)
</Frame>

Una vez que completa su análisis, Devin procede a instalar Docker en su máquina local y luego crea nuestro Dockerfile inicial, docker-compose.yml y .dockerignore para poder comenzar a probar la configuración del contenedor. También configura nuestro archivo .env para que la aplicación pueda ejecutarse con el backend de contenedores recién configurado.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/710b051e9b5f75d3b5492f554fee786e212dc129-1314x1370.png)
</Frame>

<div id="testing-the-container">
  #### Probando el contenedor
</div>

A continuación, Devin prueba cada contenedor, comenzando con nuestro servidor MongoDB y luego continuando con nuestro entorno de Go. Una vez que los contenedores están en funcionamiento, Devin pasa a probar la aplicación en sí. Al leer el [Historial de comandos](/es/work-with-devin/devin-session-tools#shell-command-history) de Devin, puedo ver que encontró nuestra definición de la API de Swagger y la cargó en el [navegador](/es/work-with-devin/devin-session-tools#interactive-browser) integrado para ver cómo funciona la API de backend.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/3cee193ba84dcea344e4a7fd829ae39c0d602270-2720x1422.png)
</Frame>

Luego, Devin preparó una solicitud curl para comprobar que la API de backend esté en ejecución y devuelva resultados según su especificación de diseño.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/de15b455421e2320b5dd6023bd0d4d47aaff2e7c-1208x710.png)
</Frame>

<div id="debugging">
  #### Depuración
</div>

Dado que obtenemos un error de **Connection refused**, Devin pasa inmediatamente a depurar y corregir la configuración de Docker. Este es un patrón común en el que Devin puede autocorregir errores a medida que avanza en una sesión. Devin corrige rápidamente el problema de configuración, reinicia el contenedor Docker y resume el trabajo que ha completado para nosotros.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/ad2d884abb70c7dd74614addbe1d8e111ebf7d53-1356x2208.png)
</Frame>

Cuando comparamos el trabajo de Devin con el [PR en el proyecto real](https://github.com/Ratnesh-Team/Rehabify/pull/137), vemos algunas diferencias y mejoras importantes:

* Devin configura un archivo docker-compose.yml además de nuestro Dockerfile. Esto nos da algunos ajustes de orquestación más específicos, como definir cómo funciona nuestra red, cómo se configuran nuestros volúmenes y qué servicios dependen entre sí.
* Devin cambia el proceso de compilación de `go mod tidy` a un método que nos permite almacenar en caché algunas de las dependencias en nuestra compilación de Docker.
* Devin genera un binario de Go enlazado estáticamente en lugar de uno enlazado dinámicamente, lo que debería ser más liviano para nuestra compilación de Docker.
* Devin configura nuestros certificados CA para HTTPS y nos permite usar un archivo .env para la configuración en lugar de pasar variables de entorno directamente.
* Y, lo más notable, Devin añade un servicio de MongoDB en nuestra configuración de Docker que el PR del proyecto no incluye. En él se asume que el desarrollador ya tiene una instancia de MongoDB separada en ejecución.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/7607ba8b57199a26812cb8f4c7129ee5a97ffcdb-1818x1206.png)
</Frame>

En 13 minutos, Devin ha ensamblado correctamente nuestro contenedor Docker para el backend de este proyecto siguiendo las mejores prácticas, lo ha probado y ha escrito un resumen completo de su trabajo. Prueba hoy tu propio prompt de Contenerización en tu propia base de código [registrándote](https://cognition.com/get-started#company) para obtener una cuenta de Devin para tu equipo.
