Cómo desplegar una aplicación dotNET con Core-Admin

#1

1. Introducción

El siguiente artículo explica paso a paso cómo desplegar y mantener distintas aplicaciones .NET en una máquina Linux, administrada con Core-Admin, con un sistema de separación de privilegios, y combinando todo con systemctl y apache2.

El escenario recoge las principales recomendaciones de seguridad y separación de privilegios para permitir ejecutar este tipo de aplicaciones, incluso varias de ellas dentro de la misma máquina, pero con una separación de privilegios para asegurar que fallos de unas no afecten a otras.

2. Requisitos

3. Primeros pasos

  1. Instalamos los paquetes .net para el motor que estemos desarrollando. A continuación instalaremos los asociados a 7.0 y 8.0. Adaptar como corresponda:

    # wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
    # dpkg -i packages-microsoft-prod.deb

  2. A continuación actualizamos e instalamos el SDK que necesitemos:

    # apt update
    # apt install -y dotnet-sdk-7.0
    # apt install -y dotnet-sdk-8.0

  3. Tras instalarlo todo, comprobamos con:

    # dotnet --info
    SDK DE .NET:
    Version: 8.0.403
    Commit: c64aa40a71
    Workload version: 8.0.400-manifests.18f19b92
    MSBuild version: 17.11.9+a69bbaaf5

4. Despliegue de la aplicación

  1. Lo primero será crear un alojamiento con el nombre (o nombres) de host que tendrá la aplicación. Este alojamiento es el gestionará el certificado y la localización de IP pública:

    Como crear un alojamiento web desde Core-Admin

  2. Más adelante puedes ir añadiendo hosting alias por si necesitas que la misma aplicación gestione distintos nombres.

  3. MUY IMPORTANTE: no desplegar la aplicación dentro del html/ (la hará insegura y potencialmente accesible)

    IMPORTANTE: Hay que desplegar la aplicación FUERA DEL /html/, en la ruta raíz del alojamiento. Más en los siguientes puntos.

  4. Una vez tengas creado el alojamiento, tendrás una ruta tal que: /var/webs/app.aplicaciondotnet.com.

  5. Ahora hay que determinar el usuario con el que ejecutará la aplicación y el comando a ejecutar para levantar el servicio. Para ello, entrar en la carpeta asociada al alojamiento y ejecutamos:

    # cd /var/webs/app.aplicaciondotnet.com
    # ls -la -tr # ver usuarios y grupos (muy importante, la aplicación fuera del /html/)

    # Apuntamos el grupo y usuario del alojamiento y lo añadimos al procaccess
    # adduser procaccess

  6. A continuación subimos la aplicación por FTP/SSH a una carpeta en el raíz del alojamiento. Para nuestro ejemplo el raíz es /var/webs/app.aplicaciondotnet.com y el nombre de la carpeta podría ser:

    /var/webs/app.aplicaciondotnet.com/aplication

    …elegir ahí el nombre que mejor convenga para la carpeta de almacenará la aplicación (quizás también siguiendo una mecánica de releases/versión). Una vez definido, subir ahí la aplicación:

    1. Subir por FTP: Cómo crear usuario FTP para alojamientos web con Core-Admin
    2. Subir por SSH: Como dar acceso ssh a un alojamiento concreto desde Core-Admin
    3. Subir/mantener con git: Usando GIT para controlar una o todas las carpetas de tu alojamiento vía FTP -- Core-Admin

    …una vez subida la aplicación, ejecutarla con el usuario asociado al alojamiento para verificar que está todo correcto:

    # a continuación, nos convertimos el el usuario visto
    # su - usuario -s /bin/bash

    # a continuación probamos la aplicación, normalmente (donde Application.dll dependerá de la aplicación en concreto):
    > dotnet Aplication.dll

  7. Con esto ya tenemos la aplicación subida, el comando de arranque, el usuario asociado al alojamiento y la ruta completa donde se almacena la aplicación. Con ello, creamos un servicio personalizado con las siguientes indicaciones:

    Crear y gestionar servicios personalizados systemcl para arranque de servicios con Core-Admin

    Introducir los siguientes datos:
    Nombre del servicio: app.aplicaciondotnet.com
    Descripción: Aplicación application.domain.com
    Comando: dotnet Aplication.dll
    Directorio de trabajo: /var/webs/app.aplicaciondotnet.com/application
    Usuario de ejecución: usuario con el que ejecuta el alojamiento
    Grupo de ejecución: grupo con el que ejecuta el alojamiento

  8. Una vez creado el servicio personalizado lo levantamos con las indicaciones systemctl que nos aparecen en la ficha (o utilizando la propia interfaz).

5. Conexión ProxyPass para el apache2 frontal (certificado SSL, etc)

  1. Llegados a este punto ya tenemos la aplicación ejecutando y funcionando en un puerto localhost de la máquina. Muy posiblemente en http://localhost:5000 (aunque este valor se puede cambiar y viene
    determinado por el código y configuración de la aplicación .NET).

  2. Ahora, simplemente nos resta conectar el apache2 frontal con nuestra aplicación .NET. Para ello, pinchamos en la pestaña “Proxy Inverso” y luego "Añadir proxy pass"

    Introducimos los siguientes datos:
    Ruta: /
    URL remota: http://localhost:5000

    NOTA: la url remota vendrá determinada por cada aplicación. Por defecto arranca en el 5000. Ver la salida del comando donde se informará de la ruta.

  3. Llegados a este punto ya tendríamos nuestra aplicación en marcha. Solo resta probar.

6. Añadiendo certificado

Ahora solo resta añadir el certificado. Si no tienes claro los pasos, cuenta con nosotros:

También puedes gestionar tu mismo el certificado con:

7. Actualización de la aplicación.

Para actualizar, simplemente subir la aplicación con el método utilizado y reiniciar la aplicación.

8. Errores conocidos

  1. Al arrancar la aplicación aparece el siguiente error:

    # dotnet Formulacion.dll
    Failed to create CoreCLR, HRESULT: 0x8007000E

    NOTA: no se ha añadido el usuario del alojamiento al grupo procaccess. Este error es debido a que el binario dotnet no puede acceder al /proc