Desplegando su aplicación Sisk

El proceso de desplegar una aplicación Sisk consiste en publicar su proyecto en producción. Aunque el proceso es relativamente sencillo, vale la pena señalar detalles que pueden ser letales para la seguridad y la estabilidad de la infraestructura del despliegue.

Idealmente, debería estar listo para desplegar su aplicación en la nube, después de realizar todas las pruebas posibles para que su aplicación esté preparada.

Publicando su aplicación #

Publicar su aplicación o servicio Sisk consiste en generar binarios listos y optimizados para producción. En este ejemplo, compilaremos los binarios para producción para ejecutarlos en una máquina que tenga el .NET Runtime instalado.

Necesitará el .NET SDK instalado en su máquina para compilar su aplicación, y el .NET Runtime instalado en el servidor de destino para ejecutar su aplicación. Puede aprender cómo instalar .NET Runtime en su servidor Linux aquí, Windows y Mac OS.

En la carpeta donde se encuentra su proyecto, abra una terminal y use el comando .NET publish:

Shell

$ dotnet publish -r linux-x64 -c Release

Esto generará sus binarios dentro de bin/Release/publish/linux-x64.

Nota

Si su aplicación usa un archivo de configuración portable, debe copiar su service-config.json al servidor host junto con todos los binarios generados por dotnet publish. Puede dejar el archivo preconfigurado, con variables de entorno, puertos y hosts de escucha, y configuraciones de servidor adicionales.

El siguiente paso es llevar estos archivos al servidor donde se alojará su aplicación.

Después de eso, otorgue permisos de ejecución a su archivo binario. En este caso, consideremos que el nombre de nuestro proyecto es “my-app”:

Shell

$ cd /home/htdocs
$ chmod +x my-app
$ ./my-app

Después de ejecutar su aplicación, verifique si produce algún mensaje de error. Si no produce ninguno, es porque su aplicación está en ejecución.

En este punto, probablemente no será posible acceder a su aplicación desde la red externa fuera de su servidor, ya que reglas de acceso como el firewall no han sido configuradas. Consideraremos esto en los siguientes pasos.

Debe tener la dirección del host virtual donde su aplicación está escuchando. Esto se establece manualmente en la aplicación y depende de cómo esté instanciando su servicio Sisk.

Si no está usando un archivo de configuración portable, debería encontrarlo donde definió su instancia de HttpServer:

HttpServer server = HttpServer.Emit(5000, out HttpServerConfiguration config, out var host, out var router);
// sisk debería escuchar en http://localhost:5000/

Asociando un ListeningHost manualmente:

config.ListeningHosts.Add(new ListeningHost("https://localhost:5000/", router));

O si está usando un archivo de configuración portable, en su service-config.json:

JSON

{
  "Server": { },
  "ListeningHost": {
    "Ports": [
      "http://localhost:5000/"
    ]
  }
}

A partir de esto, podemos crear un proxy inverso para escuchar su servicio y hacer que el tráfico esté disponible a través de la red abierta.

Proxyando su aplicación #

Proxyar su servicio significa no exponer directamente su servicio Sisk a una red externa. Esta práctica es muy común en despliegues de servidores porque:

Le permite asociar un certificado SSL en su aplicación;
Crear reglas de acceso antes de acceder al servicio y evitar sobrecargas;
Controlar el ancho de banda y los límites de solicitudes;
Separar balanceadores de carga para su aplicación;
Prevenir daños de seguridad a la infraestructura fallida.

Puede servir su aplicación a través de un proxy inverso como Nginx o Apache, o puede usar un túnel http-over-dns como Cloudflared.

Además, recuerde resolver correctamente los encabezados de reenvío de su proxy para obtener la información de sus clientes, como la dirección IP y el host, a través de resolvers de reenvío.

El siguiente paso después de crear su túnel, configurar el firewall y tener su aplicación en ejecución, es crear un servicio para su aplicación.

Nota

Usar certificados SSL directamente en el servicio Sisk en sistemas que no sean Windows no es posible. Esto se debe a la implementación de HttpListener, que es el módulo central de cómo se gestiona la cola HTTP en Sisk, y esta implementación varía de un sistema operativo a otro. Puede usar SSL en su servicio Sisk si asocia un certificado con el host virtual mediante IIS. Para otros sistemas, se recomienda encarecidamente usar un proxy inverso.

Creando un servicio #

Crear un servicio hará que su aplicación esté siempre disponible, incluso después de reiniciar la instancia del servidor o tras un fallo irrecuperable.

En este sencillo tutorial, usaremos el contenido del tutorial anterior como ejemplo para mantener su servicio siempre activo.

Acceda a la carpeta donde se encuentran los archivos de configuración del servicio:
Shell
```
cd /etc/systemd/system
```

Cree su archivo my-app.service e incluya el contenido:

my-app.serviceINI

[Unit]
Description=<description about your app>

[Service]
# establece el usuario que lanzará el servicio
User=<user which will launch the service>

# la ruta ExecStart no es relativa al WorkingDirectory.
# establécela como la ruta completa al archivo ejecutable
WorkingDirectory=/home/htdocs
ExecStart=/home/htdocs/my-app

# configura el servicio para que siempre se reinicie en caso de fallo
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Reinicie el módulo de gestión de servicios:
Shell
```
$ sudo systemctl daemon-reload
```
Inicie el servicio recién creado usando el nombre del archivo que configuró y verifique si está en ejecución:
Shell
```
$ sudo systemctl start my-app
$ sudo systemctl status my-app
```
Ahora, si su aplicación está en ejecución (“Active: active”), habilite su servicio para que continúe ejecutándose después de un reinicio del sistema:
Shell
```
$ sudo systemctl enable my-app
```

Ahora está listo para lanzar y presentar su aplicación Sisk a todos.