Saltar al contenido

Etiqueta: docker

Dockerizando una aplicación Net 5.0 – Part. II

Este post es una continuación de su versión anterior, en este nos enfocaremos en como configuramos nuestro ambiente de desarrollo con docker.

Retomemos en el código del proyecto.

Código del proyecto

Vamos a modificar nuestro “launchSetting.json”, eliminemos los profiles que tenemos actualmente, creemos uno nuevo para manejar nuestra instancia en docker que tendrá la siguiente estructura.

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:61567/",
      "sslPort": 44304
    }
  },
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "Docker": {
      "commandName": "Docker",
      "launchBrowser": true,
      "launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}",
      "publishAllPorts": true,
      "useSSL": true,
      "httpPort": 7550,
      "sslPort": 7551,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development",
        "SENTRY_CONNECTION": "",
        "DATABASE_CONNECTION": "",
        "JWT_KEY": "",
        "JWT_EXPIRATION": "",
        "URL_BASE_PATH": "",
        "AWS_ACCESS_KEY": "",
        "AWS_SECRET_KEY": "",
        "EMAIL_NO_REPLY": "",
        "ASPNETCORE_URLS": "http://+:8080;https://+:443"
      }
    }
  }
}
Nueva configuración en launchSettings.json

Lo que hemos hecho es crear un nuevo perfil, le indicamos el comando que va a ejecutar “docker”, que debe abrir un navegador, la url que se va a abrir (esta como vemos se obtiene de variables, no valores en duro), un poco de dolor de cabeza me llevo descubrir el uso de “httpPort” y “sslPort”, dado que estos dos nos permiten indicarle que puertos queremos que use. Esto ultimo parece algo menor, pero nos sirve cuando mapeamos en nuestro postman o en el front el puerto del backend, y que este sea consistente en distintos ambientes, de otro modo, nos asignarán un puerto aleatorio y esto nos generar tener que estar cambiando nuestra configuración en el front. Finalmente, acá también podemos indicarle las variables de entorno que vamos a usar dentro de nuestro dockerfile.

En nuestro ide, selecionamos “Docker” y ejecutamos el proyecto. Si es la primera ves que se ejecuta, se va a crear la imagen en base a nuestro dockerfile, luego de esto, el ide automaticamente va a crear una instancia en base a esta imagen. Veamos que comando es el que usa para ejecutar este comando.

Primero se hace el build:

docker build -f "C:\Users\walbe\Development\Simplicity\simplicity-api\dockerfile-dev" --force-rm -t simplicityserviceapi:dev --target base  --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=Simplicity.Service.Api" "C:\Users\walbe\Development\Simplicity"
Docker build

Luego realizamos se realiza el run de nuestra imagen recién creada:

docker run -dt -v "C:\Users\walbe\vsdbg\vs2017u5:/remote_debugger:rw" -v "C:\Users\walbe\Development\Simplicity\simplicity-api\Simplicity.Service.Api:/app" -v "C:\Users\walbe\Development\Simplicity:/src/" -v "C:\Users\walbe\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro" -v "C:\Users\walbe\AppData\Roaming\ASP.NET\Https:/root/.aspnet/https:ro" -v "C:\Users\walbe\.nuget\packages\:/root/.nuget/fallbackpackages2" -v "C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -e "ASPNETCORE_HTTPS_PORT=7551" -e "NUGET_PACKAGES=/root/.nuget/fallbackpackages2" -e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages;/root/.nuget/fallbackpackages2" -p 7550:8080 -p 7551:443 -P --name Simplicity.Service.Api_1 --entrypoint tail simplicityserviceapi:dev -f /dev/null
Docker run
docker run -dt 
-v "C:\Users\walbe\vsdbg\vs2017u5:/remote_debugger:rw" 
-v "C:\Users\walbe\Development\WebApplication1:/app" 
-v "C:\Users\walbe\Development\WebApplication1:/src/" 
-v "C:\Users\walbe\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro" 
-v "C:\Users\walbe\AppData\Roaming\ASP.NET\Https:/root/.aspnet/https:ro" 
-v "C:\Users\walbe\.nuget\packages\:/root/.nuget/fallbackpackages2" 
-v "C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages" 
-e "DOTNET_USE_POLLING_FILE_WATCHER=1" 
-e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" 
-e "ASPNETCORE_ENVIRONMENT=Development" 
-e "ASPNETCORE_URLS=https://+:443;http://+:80" 
-e "NUGET_PACKAGES=/root/.nuget/fallbackpackages2" 
-e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages;/root/.nuget/fallbackpackages2" 

Con esto, ya tendriamos todo funcionando correctamente, les dejo un video de todo este proceso, donde podemos ver mejor como nuestra aplicación corre desde nuestra imagen docker y los cambios que realizamos se actualizan directamente.

Espero que les sirva, en el siguiente post explicare como realizar el deploy de una aplicación en NetCore o Net 5.0 en AWS Lambda.

Deja un comentario

Dockerizando una aplicación Net 5.0 – Part. I

Hola, espero que los que me lean a esta fecha estén bien. Hace ya un tiempo que no publicaba nada, principalmente se debe a la falta de tiempo que he tenido por el trabajo y otras complicaciones que empezaron a surgir como consecuencia de la pandemia. En estos meses he aprendido algunas cosas nuevas relacionadas con AWS, Google Cloud y otras cosas que por ahí alguien puede encontrar interesante.

Retomo las publicaciones con este post, por que les comento que en general, en AWS y GCloud no es tan común que sus servicios soporten la última versión de net que nos ofrece microsoft, en mi caso tenía que migrar algunos servicios de AWS a Google Cloud esta semana que pasó y me di con la sorpresa que app engine no soporta Net 5.0. Sin embargo, soportan docker así que fue la oportunidad perfecta para practicar un poco mis skills en docker que hace un tiempito no he podido jugar con esta herramienta.

Quiero que este sea el primer post, por que en algunos de los que tengo pensado más adelante, quiero usar net 5.0, y de este modo sabrán como manejarse con esta versión del framework. Tomemos como ejemplo una aplicación que tiene especial cariño para mi porque yo la inicie como un proyecto personal hace ya un par de años y poco a poco he ido añadiendole funcionalidades y cosas. Sobre la aplicación, puedo decir que usa EF, Clean architecture y que no voy a poder compartirles el código. Sin embargo, este post es para centrarnos en docker y como implementarlo en un ambiente de desarrollo y de producción.

Dicho esto, empecemos, en nuestro proyecto base, vamos a crear un archivo que llamaremos “dockerfile-dev” y otro “dockerfile-prod”. Veamos cual es la estructura de nuestro proyecto desde visual studio y desde el explorador de windows.

Explorador de windows
Visual studio

Para este ejemplo, hemos creado los archivos de correspondientes de docker en la raiz del proyecto. haciendo un build de nuestro proyecto para ver si todo esta funcionando correctamente.

Build del proyecto

Además, es importante revisar el archivo “launchSetting.json” dentro de la carpeta “Properties” como saben este archivo te permite configurar los distintos ambientes en los que quisieras levantar tu aplicación localmente, acá manejaremos las variables de entorno que necesitemos, entre otras configuraciones.

Archivo launchSetting.json

Notemos, que por defecto el visual estudio, nos esta proporcionando ya algunos perfiles. Para nuestro caso, queremos poder levantar nuestra aplicación localmente dentro de una imagen docker. Esto último es un salvavidas en algunos casos, al empezar algún proyecto, hay un tiempo que puede ser menor o mayor para poder levantar las aplicaciones que se tengan, si estuvieran dockerizadas, sólo tendrías que clonar el proyecto, instalar docker, correr tu “docker build .” dentro de la carpeta donde estar el dockerfile y listo, puede iniciar el trabajo. Tenganlo en cuenta por si más adelante les puede servir.

Empecemos trabajando con el archivo “dockerfile-prod”. Añadamos las siguientes lineas y luego detallaremos un poco que es lo que esperamos conseguir con estas.

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 8080

Estamos tomando como base de nuestra futura imagen docker la imagen del repositorio oficial de microsoft para Net 5.0. el “AS base” es un alias que le ponemos en nuestro dockerfile a esta imagen. La sentencia “WORKDIR /app” le indica docker cual es nuestro directorio de trabajo y finalmente el “EXPOSE 8080” le dice que vamos a exponer el puerto 8080 dentro de nuestro container.

ENV ASPNETCORE_ENVIRONMENT=${_ASPNETCORE_ENVIRONMENT}
ENV AWS_ACCESS_KEY=${_AWS_ACCESS_KEY}
ENV AWS_SECRET_KEY=${_AWS_SECRET_KEY}
ENV DATABASE_CONNECTION=${_DATABASE_CONNECTION}
ENV EMAIL_NO_REPLY=${_EMAIL_NO_REPLY}
ENV JWT_EXPIRATION=${_JWT_EXPIRATION}
ENV JWT_KEY=${_JWT_KEY}
ENV SENTRY_CONNECTION=${_SENTRY_CONNECTION}
ENV ASPNETCORE_URLS=${_ASPNETCORE_URLS}
ENV URL_BASE_PATH=${_URL_BASE_PATH}

Esta sección es basicamente para declarar variables de entorno, podemos ver que en este caso las variables hacen referencia a otras variables, esto lo dejo asi por que si esto va a ir a producción, hay un pipeline en el que se reemplazarán estas variables por motivos de seguridad y buenas prácticas.

RUN apt-get update
RUN apt-get install -y apt-utils
RUN apt-get install -y libgdiplus
RUN apt-get install -y libc6-dev 
RUN ln -s /usr/lib/libgdiplus.so/usr/lib/gdiplus.dll

Esta parte la añado por que es necesario para esta aplicación, basicamente instala en nuestro entorno una librería necesaria para generar archivos excel que por defecto no están en linux. Sin embargo, nos sirve para ver como correr comandos dentro de una imagen docker.

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ./ ./Simplicity/
RUN dotnet restore Simplicity\\Simplicity.Service.Api\\Simplicity.Service.Api.csproj

Acá vamos a tomar como base para hacer el build el sdk de microsoft de 5.0, le indicarmos cual va a ser nuestro directorio de trabajo para hacer nuestro build, copiamos todo el codigo que tengamos en la carpeta en la que esta ubicada nuestro archivo dockerfile con el siguiente comando “COPY ./ ./Simplicity/” en una carpeta que vamos a crear “Simplicity”. Finalmente, en esta sección vamos a ejecutar el comando “dotnet restore” que si recuerdan la imagen de los archivos esta dentro de “Simplicity.Service.Api\\Simplicity.Service.Api.csproj” en nuestro caso, como le estamos añadiendo una carpeta más, termina siendo “Simplicity\\Simplicity.Service.Api\\Simplicity.Service.Api.csproj”.

COPY . .
WORKDIR /src/Simplicity
RUN dotnet build Simplicity.Service.Api\\Simplicity.Service.Api.csproj -c Release -o /app/build

En esta parte, nuevamente copiamos los archivos al directorio actual, le indicamos a docker cual va a ser nuestro nuevo directorio de trabajo con “/src/Simplicity” y finalmente realizamos nuestro build, recordemos en este punto que estamos haciendo un release y le añadimos que el directorio del output “-o /app/build”, consideremos que ahora no es necesario ponerle “Simplicity” al inicio por que ya lo pusimos en el workdir.

FROM build AS publish
RUN dotnet publish Simplicity.Service.Api\\Simplicity.Service.Api.csproj -c Release -o /app/publish

Ya estamos cerca de terminar, en esta parte vamos a hacer el publish con el típico comando “dotnet publish”, tambien tenemos que indicar el output. Y finalmente, ya llegamos a la última parte de la configuración de nuestro dockerfile.

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Simplicity.Service.Api.dll"]

En este punto, indicamos nuestro directorio de trabajo, copiamos lo que tenemos en nuestra carpeta publish en una carpeta publish que vamos a crear en la carpeta “app” y con el comando “ENTRYPOINT” le indicamos a docker que comando queremos que ejecute, para nuestro caso es “dotnet” al archivo “Simplicity.Service.Api.dll”. Realicemos el build de nuestro dockerfile.

docker build -t simplicity-service --file dockerfile-prod .
Realización del build del dockerfile
Realización del build
Listado de imágenes de docker

Ahora ejecutemos esta imagen docker y probemos el resultado. Notemos en el siguiente comando que le indicamos que corra en modo deamon con el “-dt” y también es necesario que le indiquemos el mapeo de los puertos de nuestra imagen docker con la máquina en la que se está ejecutando, esto lo conseguimos con “-p 4750:8080”.

docker run -dt -p 7551:8080 cb831
Ejecutamos nuestra imagen docker
Listado de imagenes docker ejecutandose

Finalmente, ejecutemos en nuestro browser el localhost para el puerto 7551.

Ejecución de nuestra aplicación dentro de la imagen docker

Les comparto el dockerfile que hemos desarrollado completo.

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 8080

ENV ASPNETCORE_ENVIRONMENT=${_ASPNETCORE_ENVIRONMENT}
ENV AWS_ACCESS_KEY=${_AWS_ACCESS_KEY}
ENV AWS_SECRET_KEY=${_AWS_SECRET_KEY}
ENV DATABASE_CONNECTION=${_DATABASE_CONNECTION}
ENV EMAIL_NO_REPLY=${_EMAIL_NO_REPLY}
ENV JWT_EXPIRATION=${_JWT_EXPIRATION}
ENV JWT_KEY=${_JWT_KEY}
ENV SENTRY_CONNECTION=${_SENTRY_CONNECTION}
ENV ASPNETCORE_URLS=${_ASPNETCORE_URLS}
ENV URL_BASE_PATH=${_URL_BASE_PATH}

RUN apt-get update
RUN apt-get install -y apt-utils
RUN apt-get install -y libgdiplus
RUN apt-get install -y libc6-dev 
RUN ln -s /usr/lib/libgdiplus.so/usr/lib/gdiplus.dll

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ./ ./Simplicity/
RUN dotnet restore Simplicity\\Simplicity.Service.Api\\Simplicity.Service.Api.csproj

COPY . .
WORKDIR /src/Simplicity
RUN dotnet build Simplicity.Service.Api\\Simplicity.Service.Api.csproj -c Release -o /app/build

FROM build AS publish
RUN dotnet publish Simplicity.Service.Api\\Simplicity.Service.Api.csproj -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Simplicity.Service.Api.dll"]

La parte del post, en el que explico como levantar la aplicación para nuestro ambiente de desarrollo, debuggear y realizar cambios de nuestro desarrollor que se actualicen directamente en nuestra imagen docker la realizare en un siguiente post. Espero que lo que he desarrollado hasta acá les sirva. En unos días publico la segunda parte.

Deja un comentario

Spring Boot con Docker

Bueno, cada ves es más frecuente que los proyectos tengan todo un pipeline de devops para sus releases. He incluso, que en los lugares donde trabajan o en los proyectos que desarrollen tengan integrado ambientes con docker en los mismos proyectos. De manera tal, que puedan tener un ambiente de trabajo en el que se tenga la certeza que no se tiene algún factor adicional y que todos están trabajando en el mismo ambiente.

Tal ves resulte un poco dificil de comprender por que es esto importante. Pero creanme cuando les digo que puede ser un dolor de cabeza levantar algunas aplicaciones. En este post quería mostrar como podemos configurar nuestro ambiente de desarrollo con spring boot usando devtools.

Pensando en esto, es que me plantee la pregunta como integrar spring boot con docker. La meta de este post sería tener un proyecto web api con spring boot que que nos permita tener un ambiente configurado y desplegado en nuestro container. Y que al hacer cambios en nuestro proyecto, podamos ver los cambios en nuestra imagen docker sólo con la realización de un build.

Empezamos usando spring initializer para generar un proyecto base, sólo le pondremos las siguientes dependencias:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>

Creamos un controlador en nuestro proyecto, sólo la demo.

Controlador para probar la actualización

Indicamos el puerto en el que queremos que nuestra aplicación funcione, esto lo hacemos poniendo en el “application.yml” la siguiente propiedad:

server:
  port: 8055

Sólo añadiendo la dependencia de devtools, tenemos acceso a ciertas funcionalidades en nuestra aplicación. Como por ejemplo, que nuestra aplicación mumestre los cambios que realizamos sin necesidad des volver a parar el debugging e iniciarlo, es algo parecido al live-realoading que tenemos con webpack. Provemos esto, y luego nos metemos de lleno a la configuración de con docker.

Probando el api inicialmente
Build al cambio que hemos realizado
Probamos el api nuevamente, visualizamos el cambio

Acá viene la magia de spring, para poder dockerizar nuestra aplicación sólo debemos de ejecutar un comando en la carpeta raiz de nuestro proyecto.

mvnw spring-boot:build-image

Esto, nos generará una imagen docker en nuestro equipo (obviamente antes debemos de tener instalado docker) con el nombre que hemos definido para nuestro proyecto. Para la demo sería del modo siguiente:

Nombre proyecto

De modo, que si ejecutamos el comando “docker ps”, tendríamos un resultado similar a este:

Imagen creada

Es posible que la primera ves que ejecutan este proceso tome un poco de tiempo, dado que esta bajando la imagen base por primera ves.

Para poder correr nuestro proyecto en la imagen docker, tenemos que ejecutar el siguiente comando.

docker run --tty --publish 8055:8055 demo:0.0.1-SNAPSHOT

Hasta este punto, tenemos nuestro proyecto dockerizado. Pero que pasa con el live reloading? Bueno, nos toca realizar algunos pasos adicionales. Primero, en nuestro archivo de configuración yml debemos añadir la siguiente configuración.

spring:
  devtools:
    remote:
      secret: wgutierrez

Luego de esto, debemos de añadir una configuración adiciona en nuestro POM, veamos como estaba antes, y como debería de quedar.

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

Tenemos que añadir una configuracion al plugin para que no excluya dev tools.

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <!--PARA PODER ACTUALIZAR EL PUBLICADO SOLO COMPILANDO-->
                <configuration>
                    <excludeDevtools>false</excludeDevtools>
                </configuration>
            </plugin>
        </plugins>
    </build>

Y finalmente, debemos añadir una nueva configuración para nuestro run/debug.

Configuración del run/debug

Es importante, mencionar que la clase:

org.springframework.boot.devtools.RemoteSpringApplication

La usamos por que nos permite tener un filewatcher, que detacta los cambios en nuestro proyecto y los replica en nuestro container. Además, tenemos también que indicar la url con el puerto que hemos configurado en nuestro proyecto.

De este modo, me parece que tenemos el panorama más claro sobre como podemos tener un proyecto spring boot con docker. Dejo el link y el repo del video.

REPO GITHUB

Saludos.

Deja un comentario