Brant Burnett es un Experto en CouchbaseArquitecto de sistemas y desarrollador .Net con experiencia en el desarrollo completo de aplicaciones web y de escritorio. Durante los últimos 12 años, ha estado trabajando con CenterEdge Software, una empresa de software de entretenimiento familiar con sede en Roxboro, Carolina del Norte. Brant tiene experiencia en el desarrollo de aplicaciones para todos los segmentos de su suite de software. Durante los últimos 4 años, ha trabajado en la transición de la infraestructura en la nube de la empresa de una plataforma Microsoft SQL a una plataforma Couchbase NoSQL pura. Gracias a su trabajo en CenterEdge, Brant ha podido centrarse en la creación de soluciones de software serias para empresas divertidas.
Con la publicación del Couchbase .NET SDK 2.4.0Couchbase ya tiene soporte oficial para .NET Core. Esto abre un nuevo mundo para .NET Couchbase desarrolladores. En concreto, ahora podemos utilizar Docker para gestionar fácilmente nuestras aplicaciones y mejorar nuestro proceso de despliegue, algo que antes estaba reservado a aplicaciones de la talla de Java y Node.js.
En Software CenterEdgeEstamos pasando rápidamente de nuestras aplicaciones monolíticas ASP.NET a microservicios ASP.NET Core basados en Docker. Estamos muy entusiasmados con las nuevas posibilidades que ofrece, y las mejoras en la robustez de nuestra aplicación y la facilidad de despliegue. Esperamos que esta visión general de los enfoques que estamos utilizando para hacer esta transición ayude a otros a seguir su ejemplo.
Configuración y entornos
En la mayoría de las aplicaciones ASP.NET Core, la configuración se basa en parámetros leídos de la base de datos appsettings.json en la raíz del proyecto. Estos parámetros se sustituyen por parámetros específicos del entorno (como appsettings.Desarrollo.json). Estos ajustes pueden ser anulados a su vez por las variables de entorno presentes cuando se inicia la aplicación.
En CenterEdge, hemos definido los entornos .NET Core para que signifiquen cosas específicas relativas a nuestros entornos del mundo real. Tenga en cuenta que también puede añadir sus propios nombres de entorno, no es necesario utilizar los predeterminados, pero los predeterminados funcionaron para nosotros.
- Desarrollo - Desarrollo en máquina local usando Visual Studio. La configuración apunta a Couchbase Server en la máquina local, etc.
- Staging - Entornos de prueba en la nube
- Producción - Tanto el entorno de preproducción (para las pruebas finales antes del despliegue) como el entorno de producción final. Estos entornos son generalmente los mismos que los de Puesta en Escena pero con un registro más ligero por defecto.
Así que nuestra base appsettings.json por lo general se ve algo como esto:
{
"Registro": {
"IncludeScopes": falso,
"LogLevel": {
"Predeterminado": "Debug",
"Sistema": "Información",
"Microsoft": "Información",
"Couchbase": "Debug"
}
},
"Couchbase": {
"Cubos": [
{
"Nombre": "mi-cubo"
}
]
}
}
La configuración anterior utiliza localhost para Couchbase Server por defecto, ya que no tenemos ninguna URL de servidor especificada. A continuación crearemos appsettings.Staging.json y/o appsettings.Production.json así:
{
"Registro": {
"LogLevel": {
"Predeterminado": "Información",
"Couchbase": "Información"
}
}
"CouchbaseServiceDiscovery": "_couchbase._tcp.services.local"
}
Esto reduce nuestros niveles de registro a algo más razonable, y también tiene un ajuste para el descubrimiento de servicios (discutido más adelante).
Inyección de dependencia
ASP.NET Core utiliza un montón de técnicas que son diferentes del modelo ASP.NET tradicional, lo que significa que integrar Couchbase en aplicaciones .NET Core es un poco diferente. En particular, ASP.NET Core está construido desde cero para trabajar con inyección de dependencias.
Para ello, utilizamos la función Couchbase.Extensions.DependencyInjection para cerrar la brecha entre los objetos bucket del SDK de Couchbase y el sistema de inyección de dependencias. Couchbase se registra durante ConfigureServices en el Puesta en marcha pasando la sección de configuración anterior. También añadimos algo de código de apagado para cerrar las conexiones cuando la aplicación web está saliendo.
public void ConfigureServices(IServiceCollection services)
{
// Registrar Couchbase con la sección de configuración
servicios
.AddCouchbase(Configuration.GetSection("Couchbase"))
.AddCouchbaseBucket("mi-cubo");
if (!Environment.IsDevelopment())
{
services.AddCouchbaseDnsDiscovery(Configuration["CouchbaseServiceDiscovery"]);
}
services.AddMvc();
// Registre aquí otros servicios
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env,
ILoggerFactory loggerFactory,
IApplicationLifetime applicationLifetime)
{
// …
// Aquí no se muestra el inicio estándar de la aplicación
// …
// Cuando la aplicación se detiene se cierran las conexiones Couchbase con gracia
applicationLifetime.ApplicationStopped.Register(() =>
{
app.ApplicationServices.GetRequiredService().Close();
});
}
Puede acceder a cualquier cubo en cualquier controlador inyectando IBucketProvider a través del constructor. Sin embargo, puede observar que el ejemplo anterior también hace una llamada a AddCouchbaseBucket("mi-cubo").
Este método permite registrar una interfaz vacía heredada de INamedBucketProvider:
public interface IMyBucketProvider : INamedBucketProvider
{
}
Y luego inyectarlo en un controlador o servicio de lógica de negocio. Siempre proporcionará el mismo cubo, basado en la configuración que usted proporcionó durante ConfigureServices.
public class HomeController : Controlador
{
private readonly IMyBucketProvider _bucketProvider;
public HomeController(IMyBucketProvider bucketProvider)
{
_bucketProvider = bucketProvider;
}
public IActionResult Índice()
{
var bucket = _bucketProvider.GetBucket();
var resultado =
await cubo.QueryAsync(
"SELECT Extent.* FROM mi-cesta AS Extent");
if (!result.Success)
{
throw new Exception("Error de Couchbase", result.Exception);
}
return Vista(resultado.Filas);
}
}
Descubrimiento de servicios
Cuando se trabaja con microservicios, el descubrimiento de servicios es un problema común. Cada entorno que ejecutes tenderá a tener diferentes servicios en diferentes puntos finales. Couchbase es uno de esos servicios, que puede existir en una dirección diferente en cada entorno. Hay muchas soluciones para el descubrimiento de servicios, pero en CenterEdge decidimos quedarnos con una solución simple por ahora, DNS SRV registros.
Para ello, utilizamos la función Couchbase.Extensions.DnsDiscovery paquete. Este paquete encontrará registros DNS SRV que enumeran los nodos del clúster. Para ello, creamos un dominio DNS privado en AWS Route 53 llamado "services.local", y creamos un conjunto de registros SRV llamado "_couchbase._tcp.services.local" que contiene la lista de nodos Couchbase. El conjunto de registros de Route 53 tiene este aspecto:
10 10 8091 couchbasedata1.int.dev.centeredgeonline.com
10 10 8091 couchbasedata2.int.dev.centeredgeonline.com
10 10 8091 couchbasedata3.int.dev.centeredgeonline.com
En el ejemplo anterior para ConfigureServices en el inicio, es posible que haya notado la siguiente sección:
if (!Environment.IsDevelopment())
{
services.AddCouchbaseDnsDiscovery(Configuration["CouchbaseServiceDiscovery"]);
}
Esto reemplazará cualquier servidor pasado a través de la configuración con los servidores encontrados buscando en el registro DNS SRV. También proporcionamos el nombre DNS a través de la configuración, haciendo que sea fácil de reemplazar si es necesario. Específicamente no usamos esta extensión en nuestro entorno de desarrollo, donde usamos localhost para acceder al cluster de Couchbase.
Eso está bien, ¿y Docker?
Hasta ahora, todo lo que hemos hecho es aplicable a ASP.NET Core en general, y no es necesariamente específico de Docker. Entonces, ¿cómo pasamos de una aplicación general a una que se ejecuta en un contenedor Docker?
En primer lugar, deberá realizar algunos pasos preparatorios en su máquina de desarrollo:
- Asegúrese de que dispone de Hyper-V activado en Windows
- Instale Docker para Windows
- Configurar un Unidad compartida en Docker para la unidad en la que se encuentra su aplicación
- Instale Herramientas de Visual Studio para Docker
- Asegúrese de que Docker está iniciado (puede configurar Docker para que se inicie automáticamente al iniciar sesión).
Ahora, estás listo para empezar. Simplemente haz clic con el botón derecho del ratón en tu proyecto en Visual Studio, y ve a Add > Docker Support. Esto añade los archivos necesarios a tu proyecto.
Añadir compatibilidad con Docker
Aunque se añaden varios archivos, hay algunos que son especialmente importantes. El primer archivo que me gustaría señalar es Dockerfile:
DE microsoft/aspnetcore:1.0.1
ENTRYPOINT ["dotnet", "TestApp.dll"]
ARG source=.
directorio de trabajo /app
EXPONE 80
COPIAR 1TP4Fuente .
Hay dos líneas clave en este archivo que es posible que tenga que modificar:
DE microsoft/aspnetcore:1.0.1
Debe cambiar esta línea si utiliza una versión diferente de .NET Core, como 1.0.3 o 1.1.0. La etiqueta de versión de esta línea debe coincidir con la versión de .NET Core utilizada en el archivo project.json.
ENTRYPOINT ["dotnet", "TestApp.dll"]
Si cambia el nombre de su proyecto, se mostrará un nombre de archivo DLL diferente. Cambie esta línea para hacer referencia al nombre de archivo DLL correcto.
El siguiente archivo es docker-compose.yml. Este archivo, junto con algunos archivos relacionados, controla la naturaleza de los contenedores Docker que se inician al hacer clic en Ejecutar. Tendremos que hacer un cambio en docker-compose.yml para que funcione la conexión con Couchbase Server.
Nuestra configuración para el entorno de Desarrollo está intentando acceder a "localhost" para acceder a Couchbase Server. Este enfoque funciona bien si la aplicación se ejecuta en IIS Express. Sin embargo, dentro de un contenedor Docker "localhost" ya no apunta a tu ordenador de desarrollo. En su lugar se refiere al contenedor Docker aislado, al igual que lo haría dentro de una máquina virtual.
Para solucionarlo, tenemos que añadir una sección de entorno a docker-compose.yml para utilizar el nombre de su ordenador en lugar de "localhost":
versión: "2
servicios:
testapp:
imagen: user/testapp${TAG}
construir:
contexto: .
Dockerfile: Dockerfile
puertos:
– “80”
medio ambiente:
- Couchbase:Servidores:0=http://$COMPUTERNAME:8091/
Sólo tiene que añadir las dos últimas líneas anteriores a su archivo. Docker Compose sustituirá automáticamente $COMPUTERNAME con el nombre de su equipo, lo que resulta útil a la hora de compartir la aplicación con su equipo a través del control de código fuente.
Ahora estás listo para probar en Docker. Sólo tienes que cambiar el menú desplegable Ejecutar en la barra de herramientas de Visual Studio a Docker en lugar de IIS Express antes de iniciar tu aplicación. Incluso admite depuración y muestra registros en la ventana Depuración.
Si quieres ser realmente sofisticado, también puedes modificar docker-compose.yml para hacer cosas como lanzar contenedores adicionales requeridos, anular otras configuraciones a través de variables de entorno y más. Por ejemplo, en CenterEdge utilizamos este enfoque para lanzar microservicios adicionales que son dependencias de la aplicación que se está desarrollando.
Despliegue
El método exacto de despliegue variará en función de su plataforma Docker. Por ejemplo, CenterEdge utiliza Amazon AWS, por lo que desplegaremos utilizando Servicio de contenedores EC2. Independientemente de la plataforma que elijas, tendrás que crear una imagen Docker de tu aplicación y publicarla en un registro de contenedores Docker.
En CenterEdge hemos añadido esto a nuestro proceso de integración continua, pero aquí tiene un resumen de los pasos necesarios:
- Ejecute "dotnet publish path/to/your/app -c Release" para publicar su aplicación. Esto publicará a "bin/Release/netcoreapp1.0/publish" por defecto, pero esto puede ser controlado con el parámetro "-o some/path". Para .NET Core 1.1, será netcoreapp1.1 en lugar de netcoreapp1.0 por defecto.
- Ejecute "docker build -t myappname path/to/your/app/bin/Release/netcoreapp1.0/publish" para crear una imagen Docker. Se etiquetará como "myappname".
- Ejecute "docker tag myappname yourdockerregistry/myappname:sometag" para etiquetar la imagen Docker para su registro Docker. Sustituye "yourdockerregistry" por la ruta a tu registro Docker. Para Docker Hub, esto es sólo su nombre de usuario. Sustituya "sometag" por la etiqueta que desee utilizar, como "latest" o "1.0.5".
- Ejecute "docker push yourdockerregistry/myappname:sometag" para enviar la imagen a su registro de contenedores Docker. Esto supone que ya ha utilizado "docker login" para autenticarse con su registro.
En cuanto al versionado, en CenterEdge utilizamos la numeración de versiones al estilo NuGet para nuestros microservicios. Por ejemplo, "1.1.0" o "2.0.5-beta002". Este número de versión es la etiqueta que utilizamos en nuestro registro de contenedores Docker. También seguimos SemVerlo que significa que los incrementos a diferentes partes del número tienen significados específicos. Si incrementamos el primer dígito, significa que la API tiene cambios de última hora y no es totalmente compatible con versiones anteriores. Incrementar el segundo dígito indica nuevas características significativas. El tercer dígito se incrementa para corregir errores.
Conclusión
Con suerte, ahora tienes las herramientas básicas que necesitarás para hacer la transición de tus aplicaciones .NET usando Couchbase a .NET Core y Docker. La transición nos ha parecido divertida y emocionante. Aunque ASP.NET Core ha cambiado algunos enfoques y otras cosas han sido obsoletas, la plataforma en general se siente mucho más limpia y fácil de usar. Y estoy seguro de que vendrán cosas aún mejores en el futuro.
