Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Microservices Architecture PDF
Microservices Architecture PDF
Cesar de la Torre, administrador de programas sénior del equipo del producto de .NET, Microsoft Corp.
Bill Wagner, desarrollador de contenido sénior de C+E, Microsoft Corp.
Mike Rousos, ingeniero de software principal del equipo de CAT de la división de desarrollo, Microsoft
Editores:
Mike Pope
Steve Hoag
Participantes y revisores:
Introducción
Las empresas cada vez ahorran más costos, resuelven más problemas de implementación y mejoran más las
operaciones de DevOps y producción mediante el uso de contenedores. Microsoft ha lanzado recientemente
innovaciones en los contenedores de Windows y Linux con la creación de productos como Azure Container Service
y Azure Service Fabric, contando además con la colaboración de líderes del sector como Docker, Mesosphere y
Kubernetes. Estos productos ofrecen soluciones de contenedores que ayudan a las empresas a compilar e
implementar aplicaciones a velocidad y escala de nube, sea cual sea la plataforma o las herramientas que hayan
elegido.
Docker se está convirtiendo en el estándar de facto del sector de los contenedores, ya que es compatible con los
proveedores más importantes del ecosistema de Windows y Linux. (Microsoft es uno de los principales
proveedores de nube que admite Docker). En el futuro, Docker probablemente estará omnipresente en todos los
centros de datos en la nube o locales.
Además, la arquitectura de microservicios se está convirtiendo en un enfoque fundamental para las aplicaciones
críticas distribuidas. En una arquitectura basada en microservicios, la aplicación se basa en una colección de
servicios que se pueden desarrollar, probar, implementar y versionar por separado.
La inclusión en contenedores es un enfoque de desarrollo de software en el que una aplicación o un servicio, sus
dependencias y su configuración (extraídos como archivos de manifiesto de implementación) se empaquetan
como una imagen de contenedor. La aplicación en contenedor puede probarse como una unidad e implementarse
como una instancia de imagen de contenedor en el sistema operativo (SO) host.
Del mismo modo que los contenedores de mercancías permiten su transporte por barco, tren o camión
independientemente de la carga de su interior, los contenedores de software actúan como una unidad estándar de
software que puede contener diferentes dependencias y código. De esta manera, la inclusión del software en
contenedor permite a los desarrolladores y los profesionales de TI implementarlo en entornos con pocas
modificaciones o ninguna en absoluto.
Los contenedores también aíslan las aplicaciones entre sí en un sistema operativo compartido. Las aplicaciones en
contenedor se ejecutan sobre un host de contenedor que a su vez se ejecuta en el sistema operativo (Linux o
Windows). Por lo tanto, los contenedores tienen una superficie significativamente menor que las imágenes de
máquina virtual (VM).
Cada contenedor puede ejecutar una aplicación web o un servicio al completo, como se muestra en la figura 2-1.
En este ejemplo, el host de Docker es un host de contenedor, y App 1, App 2, Svc 1 y Svc 2 son aplicaciones o
servicios en contenedor.
Se admiten dos implementaciones para compilar aplicaciones de Docker en contenedor del lado del servidor con
.NET: .NET Framework y .NET Core. Ambas comparten muchos de los componentes de .NET Standard y es posible
compartir código entre ellas. Aun así, presentan diferencias fundamentales, y la elección de la implementación
dependerá de lo que quiera realizar. En esta sección se proporciona orientación sobre cuándo se debe elegir cada
implementación.
A N T E R IO R S IG U IE N T E
Diseñar la arquitectura de aplicaciones basadas en
contenedores y microservicios
03/10/2017 • 2 min to read • Edit Online
Los microservicios ofrecen grandes ventajas, pero también generan nuevos desafíos enormes. Los patrones de
arquitectura de microservicios son los pilares fundamentales a la hora de crear una aplicación basada en
microservicios.
Previamente en esta guía, ha aprendido los conceptos básicos sobre los contenedores y Docker. Con esa
información mínima, ya puede empezar a trabajar con contenedores. Aunque los contenedores son habilitadores y
se consideran una gran elección para microservicios, no son obligatorios para una arquitectura de microservicios, y
muchos conceptos arquitectónicos de esta sección sobre la arquitectura también se podrían aplicar sin
contenedores. A pesar de ello, esta guía se centra en la intersección de ambos debido a la importancia actual de los
contenedores.
Las aplicaciones empresariales pueden ser complejas y, a menudo, se componen de varios servicios en lugar de
una sola aplicación basada en servicios. En esos casos, debe comprender otros enfoques de arquitectura, como son
los microservicios y determinados patrones de diseño guiado por el dominio (DDD), además de conceptos de
orquestación de contenedores. Tenga en cuenta que en este capítulo no solo se describen los microservicios en
contenedor, sino cualquier aplicación en contenedor.
A N T E R IO R S IG U IE N T E
1 min to read •
Edit O nline
Proceso de desarrollo de aplicaciones basadas en
Docker
03/10/2017 • 2 min to read • Edit Online
Desarrolle aplicaciones .NET en contenedor de la forma que prefiera, ya sea centradas en el IDE con Visual Studio y
Visual Studio Tools para Docker o bien centradas en la CLI o el editor con la CLI de Docker y Visual Studio Code.
A N T E R IO R S IG U IE N T E
Implementar aplicaciones web de .NET Core basadas
en un solo contenedor en hosts de Linux o Windows
Nano Server
03/10/2017 • 9 min to read • Edit Online
Puede usar contenedores de Docker para la implementación monolítica de aplicaciones web más sencillas. Esto
mejora la integración continua y las canalizaciones de implementación continua y ayuda a llevar a cabo
correctamente el proceso desde la implementación hasta la producción. Ya no se volverá a preguntar: "Funciona
en mi equipo, ¿por qué no funciona en producción?".
Una arquitectura basada en microservicios tiene muchas ventajas, pero a costa de una mayor complejidad. En
algunos casos, los costos superan a las ventajas y podría resultarle más útil una aplicación de implementación
monolítica que se ejecute en un solo contenedor o en unos pocos contenedores.
Es posible que una aplicación monolítica no se pueda descomponer fácilmente en microservicios bien separados.
Ya ha aprendido que estos se deben particionar por función: los microservicios deberían funcionar de manera
independiente para proporcionar una aplicación más resistente. Si no puede proporcionar sectores de
características de la aplicación, el hecho de separarla solo agrega complejidad.
Una aplicación podría no necesitar inicialmente el escalado de las características por separado. Supongamos que
en una fase temprana del ciclo de vida de la aplicación de referencia eShopOnContainers, el tráfico no justificaba
separar las características en diferentes microservicios. El tráfico era bastante reducido y el hecho de agregar
recursos a un servicio normalmente suponía agregar recursos a todos los servicios. El trabajo adicional que
suponía separar la aplicación en servicios diferenciados apenas proporcionaba beneficio.
Además, en las fases tempranas del desarrollo de una aplicación, es posible que no se tenga una idea clara de
dónde están los límites funcionales naturales. Mientras desarrolla un producto mínimamente viable, puede que
todavía no sea evidente la separación natural.
Algunas de estas condiciones pueden ser temporales. Podría empezar creando una aplicación monolítica y, más
adelante, separar algunas características para desarrollarlas e implementarlas como microservicios. Otras
condiciones podrían ser básicas para el espacio de problemas de la aplicación y, en consecuencia, tal vez no se
pueda dividir nunca en varios microservicios.
La separación de una aplicación en varios procesos diferenciados también introduce una sobrecarga. La separación
de funciones en procesos diferentes conlleva una mayor complejidad. Los protocolos de comunicación se vuelven
más complejos. En lugar de llamadas a métodos, debe usar comunicaciones asincrónicas entre servicios. Cuando
cambie a una arquitectura de microservicios, deberá agregar muchos de los bloques de creación que se
implementan en la versión de microservicios de la aplicación eShopOnContainers: control de bus de eventos,
reintentos y resistencia de mensajes, coherencia eventual y mucho más.
Una versión muy simplificada de eShopOnContainers (denominada eShopWeb e incluida en el mismo repositorio
de GitHub) se ejecuta como una aplicación de MVC monolítica y, tal como se ha indicado, esta opción de diseño
ofrece una serie de ventajas. Puede descargar de GitHub el código fuente para esta aplicación y ejecutarlo de forma
local. Incluso esta aplicación monolítica se beneficia de la implementación en un entorno de contenedor.
Ante todo, la implementación en contenedor implica que cada instancia de la aplicación se ejecuta en el mismo
entorno. Esto incluye el entorno de desarrollo donde tienen lugar las pruebas y el desarrollo iniciales. El equipo de
desarrollo puede ejecutar la aplicación en un entorno en contenedor que coincida con el entorno de producción.
Además, las aplicaciones en contenedor se escalan horizontalmente con un costo menor. Como ya ha visto, el
entorno en contenedor permite un mayor uso compartido de recursos que los entornos de máquina virtual
tradicionales.
Por último, el hecho de incluir la aplicación en un contenedor fuerza la separación entre la lógica de negocios y el
servidor de almacenamiento. Cuando la aplicación se escala horizontalmente, los diversos contenedores se basan
en un único medio de almacenamiento físico. Normalmente, se trata de un servidor de alta disponibilidad que
ejecuta una base de datos de SQL Server.
version: '2'
services:
eshopweb:
image: eshop/web
build:
context: ./eShopWeb
dockerfile: Dockerfile
depends_on:
- sql.data
sql.data:
image: microsoft/mssql-server-linux
La directiva depends_on le indica a Docker que la imagen eShopWeb depende de la imagen sql.data. Unas líneas
por debajo se encuentran las instrucciones para compilar una imagen etiquetada como sql.data mediante la
imagen microsoft/mssql-server-linux.
En el proyecto docker-compose se muestran los demás archivos docker-compose bajo el nodo principal docker-
compose.yml. Esto ayuda a señalar visualmente la relación entre estos archivos. El archivo docker-compose-
override.yml contiene los valores de configuración de ambos servicios, como las cadenas de conexión y otros
valores para las aplicaciones.
En el ejemplo siguiente se muestra el archivo docker-compose.vs.debug.yml, que contiene los valores usados para
la depuración en Visual Studio. En ese archivo, la imagen eshopweb tiene anexada la etiqueta de desarrollo. Esto
ayuda a separar las imágenes de depuración de las imágenes de lanzamiento, para que no se implemente
accidentalmente la información de depuración en un entorno de producción:
version: '2'
services:
eshopweb:
image: eshop/web:dev
build:
args:
source: ${DOCKER_BUILD_SOURCE}
environment:
- DOTNET_USE_POLLING_FILE_WATCHER=1
volumes:
- ./eShopWeb:/app
- ~/.nuget/packages:/root/.nuget/packages:ro
- ~/clrdbg:/clrdbg:ro
entrypoint: tail -f /dev/null
labels:
- "com.microsoft.visualstudio.targetoperatingsystem=linux"
El último archivo agregado es docker-compose.ci.build.yml, que se usaría desde la línea de comandos para
compilar el proyecto desde un servidor CI. Este archivo compuesto inicia un contenedor de Docker que compila las
imágenes necesarias para la aplicación. En el ejemplo siguiente se muestra el contenido del archivo docker-
compose.ci.build.yml.
version: '2'
services:
ci-build:
image: microsoft/aspnetcore-build:1.0-1.1
volumes:
- .:/src
working_dir: /src
command: /bin/bash -c "dotnet restore ./eShopWeb.sln && dotnet publish ./eShopWeb.sln -c Release -o
./obj/Docker/publish"
Tenga en cuenta que la imagen es una imagen de compilación de ASP.NET Core. Esta imagen incluye las
herramientas de compilación y el SDK para compilar la aplicación y crear las imágenes necesarias. Al ejecutar el
proyecto docker-compose con este archivo, se inicia el contenedor de compilación desde la imagen y se compila
la imagen de la aplicación en ese contenedor. Debe especificar ese archivo docker-compose como parte de la línea
de comandos para compilar la aplicación en un contenedor de Docker y, después, iniciarlo.
En Visual Studio, puede ejecutar la aplicación en contenedores de Docker. Para ello, seleccione el proyecto docker-
compose como proyecto de inicio y presione Ctrl+F5 (F5 para depurar), como haría con cualquier otra aplicación.
Cuando se inicia el proyecto docker-compose, Visual Studio ejecuta docker-compose mediante el archivo
docker-compose.yml, el archivo docker-compose.override.yml y uno de los archivos docker-compose.vs.*. Una vez
que se ha iniciado la aplicación, Visual Studio abre automáticamente el explorador.
Si inicia la aplicación en el depurador, Visual Studio se asociará a la aplicación en ejecución en Docker.
Solución de problemas
En esta sección se describen algunos de los problemas que pueden surgir cuando se ejecutan contenedores de
manera local y se sugieren diversas correcciones.
Detener contenedores de Docker
Después de iniciar la aplicación en contenedor, los contenedores siguen ejecutándose incluso después de que se
haya detenido la depuración. Puede ejecutar el comando docker ps desde la línea de comandos para ver qué
contenedores se están ejecutando. El comando docker stop detiene un contenedor en ejecución, tal como se
muestra en la figura 6-2.
Figura 6-2. Mostrar y detener contenedores con los comandos docker ps y docker stop de la CLI
Es posible que necesite detener procesos en ejecución cuando cambie entre diferentes configuraciones. En caso
contrario, el contenedor que ejecuta la aplicación web usará el puerto para la aplicación (5106 en este ejemplo).
Agregar Docker a los proyectos
El asistente que agrega compatibilidad con Docker se comunica con el proceso de Docker que se está ejecutando. El
asistente no se ejecutará correctamente si Docker no está funcionando cuando se inicie el asistente. Además, el
asistente examinará el contenedor que ha elegido actualmente para agregar la compatibilidad correcta con Docker.
Si quiere agregar compatibilidad con contenedores de Windows, debe ejecutar el asistente mientras Docker se
ejecuta con contenedores de Windows configurados. Si quiere agregar compatibilidad con contenedores de Linux,
ejecute el asistente mientras Docker se ejecuta con contenedores de Linux configurados.
A N T E R IO R S IG U IE N T E
Migrar aplicaciones de .NET Framework monolíticas
heredadas a contenedores de Windows
03/10/2017 • 13 min to read • Edit Online
Los contenedores de Windows pueden usarse como una manera para mejorar los entornos de desarrollo y
pruebas y para implementar aplicaciones que se basan en tecnologías de .NET Framework heredadas, como
formularios Web Forms. El uso de contenedores para aplicaciones heredadas de esta manera se conoce como
“migración mediante lift-and-shift”.
Las secciones anteriores de esta guía han abogado por el uso de una arquitectura de microservicios en la que las
aplicaciones empresariales se distribuyen entre diferentes contenedores, cada uno de los cuales ejecuta un
pequeño servicio especializado. Este objetivo tiene numerosas ventajas. En el desarrollo nuevo, se recomienda
encarecidamente este enfoque. Las aplicaciones fundamentales para la empresa también se verán lo bastante
beneficiadas como para justificar el costo que supone el cambio de arquitectura y la reimplementación.
Pero no todas las aplicaciones se beneficiarán lo suficiente como para justificar dicho costo. Esto no significa que
esas aplicaciones no se puedan usar en escenarios de contenedor.
En esta sección, exploraremos una aplicación para eShopOnContainers, mostrada en la figura 7-1. Los usuarios de
esta aplicación serían los miembros del equipo empresarial de eShopOnContainers, que la utilizarían para ver y
editar el catálogo de productos.
Figura 7-1. Aplicación de formularios Web Forms ASP.NET (tecnología heredada) en un contenedor de Windows.
Se trata de una aplicación de formularios Web Forms que se usa para examinar y modificar las entradas del
catálogo. La dependencia de formularios Web Forms significa que esta aplicación no se ejecutará en .NET Core, a
menos que se reescriba sin formularios Web Forms y use en su lugar MVC de ASP.NET Core. Verá cómo puede
ejecutar aplicaciones como estas en contenedores sin ningún cambio. También verá cómo puede realizar cambios
mínimos para trabajar en un modo híbrido en el que alguna función se ha movido a un microservicio
independiente, pero la mayoría de las funciones permanece en la aplicación monolítica.
Figura 7-2. Aplicación de formularios Web Forms de administración de catálogos en Visual Studio de 2017.
Además, todos los desarrolladores pueden ejecutar la aplicación en este entorno coherente. Los problemas que
solo se manifiestan con determinadas versiones aparecerán de inmediato para los desarrolladores, en lugar de
surgir en un entorno de ensayo o de producción. Las diferencias entre los entornos de desarrollo dejan de ser tan
importantes para el equipo de desarrollo una vez que las aplicaciones se ejecutan en contenedores.
Por último, las aplicaciones en contenedor tienen una curva de escalado horizontal más plana. Ya ha aprendido que
las aplicaciones en contenedor permiten la existencia de más contenedores en una máquina virtual o más
contenedores en una máquina física. Esto supone una mayor densidad y requiere menos recursos.
Por todas estas razones, considere la posibilidad de ejecutar aplicaciones monolíticas heredadas en un contenedor
de Docker mediante una operación de “migración mediante lift-and-shift”. La expresión “lift-and-shift” describe el
ámbito de la tarea: extrae (lift) toda la aplicación de una máquina física o virtual y la traslada (shift) a un
contenedor. En situaciones ideales, no es necesario realizar ningún cambio en el código de la aplicación para que
se ejecute en un contenedor.
if (fake)
{
builder.RegisterType<CatalogMockService>()
.As<ICatalogService>();
}
else
{
builder.RegisterType<CatalogService>()
.As<ICatalogService>();
builder.RegisterType<RequestProvider>()
.As<IRequestProvider>();
}
if (ctor != null)
{
// Resolve the parameters for the constructor
var args = (from parm in ctor.GetParameters()
select Container.Resolve(parm.ParameterType))
.ToArray();
Las páginas de la aplicación (Default.aspx.cs y EditPage.aspx.cs) definen constructores que toman estas
dependencias. Observe que el constructor predeterminado sigue estando presente y es accesible. La
infraestructura necesita el código siguiente.
protected _Default() { }
FROM microsoft/aspnet
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .
Este archivo Dockerfile tendrá un aspecto muy similar a los creados para ejecutar una aplicación de ASP.NET Core
en contenedores de Linux. Aun así, hay algunas diferencias importantes. La más importante es que la imagen base
es microsoft/aspnet, que es la imagen actual de Windows Server que incluye .NET Framework. Otra diferencia es
que los directorios copiados del directorio de origen son diferentes.
Los demás archivos del proyecto docker-compose son los activos de Docker necesarios para compilar y
configurar los contenedores. Visual Studio coloca los diversos archivos docker-compose.yml en un nodo para
resaltar cómo se usan. El archivo base docker-compose contiene las directivas que son comunes a todas las
configuraciones. El archivo docker-compose.override.yml contiene variables de entorno y los reemplazos
relacionados para una configuración de desarrollador. Las variantes con .vs.debug y .vs.release proporcionan una
configuración de entorno que permite a Visual Studio adjuntar elementos al contenedor en ejecución y
administrarlo.
Aunque la integración de Visual Studio forma parte de la compatibilidad con la adición de Docker a la solución,
también puede compilar y ejecutar desde la línea de comandos mediante el comando docker-compose up, como
ha visto en secciones anteriores.
A N T E R IO R S IG U IE N T E
Diseñar y desarrollar aplicaciones .NET basadas en
varios contenedores y microservicios
03/10/2017 • 1 min to read • Edit Online
Si desarrolla aplicaciones de microservicios en contenedor significa que está compilando aplicaciones de varios
contenedores. Pero una aplicación de varios contenedores también podría ser más sencilla (por ejemplo, una
aplicación de tres niveles) y podría no compilarse con una arquitectura de microservicios.
Previamente planteamos la pregunta “¿Se necesita Docker para compilar una arquitectura de microservicios?”. La
respuesta es un no rotundo. Docker es un habilitador y puede proporcionar grandes ventajas, pero los
contenedores y Docker no son un requisito imprescindible para los microservicios. Por ejemplo, podría crear una
aplicación basada en microservicios con o sin Docker al usar Azure Service Fabric, que es compatible con los
microservicios que se ejecutan como procesos simples o como contenedores de Docker.
Pero si sabe cómo diseñar y desarrollar una aplicación basada en microservicios que también se base en
contenedores de Docker, podrá diseñar y desarrollar cualquier modelo de aplicación más sencillo. Por ejemplo,
podría diseñar una aplicación de tres niveles que también requiera un enfoque de varios contenedores. Debido a
eso, y dado que las arquitecturas de microservicios son una tendencia importante en el mundo de los
contenedores, esta sección se centra en la implementación de una arquitectura de microservicios con contenedores
de Docker.
A N T E R IO R S IG U IE N T E
Abordar la complejidad empresarial en un
microservicio con patrones DDD y CQRS
03/10/2017 • 2 min to read • Edit Online
Diseñe un modelo de dominio para cada microservicio o contexto limitado que refleje un conocimiento del ámbito
empresarial.
Esta sección se centra en microservicios más avanzados que se implementan cuando se deben abordar
subsistemas complejos y en microservicios derivados de los conocimientos de expertos en el dominio con reglas
de negocios cambiantes. Los patrones de arquitectura que se usan en esta sección se basan en enfoques de diseño
guiado por el dominio (DDD) y separación de la responsabilidad de comandos y consultas (CQRS), como se
muestra en la figura 9-1.
Figura 9-1. Arquitectura de microservicios externa frente a patrones de arquitectura interna para cada
microservicio.
Pero la mayoría de las técnicas para microservicios controlados por datos (por ejemplo, cómo implementar un
servicio ASP.NET Core Web API o cómo exponer metadatos de Swagger con Swashbuckle) también son aplicables a
los microservicios más avanzados que se implementan internamente con patrones DDD. Esta sección es una
ampliación de las secciones anteriores, ya que la mayoría de las prácticas explicadas anteriormente también se
aplican aquí o a cualquier tipo de microservicio.
Esta sección proporciona en primer lugar detalles sobre los patrones CQRS simplificados que se usan en la
aplicación de referencia eShopOnContainers. Más adelante, obtendrá información general sobre las técnicas DDD
que le permiten encontrar patrones comunes que puede volver a usar en sus aplicaciones.
DDD es un tema amplio con numerosos recursos para obtener más información. Puede empezar con libros como
Domain-Driven Design (Diseño guiado por el dominio), de Eric Evans, y materiales adicionales de Vaughn Vernon,
Jimmy Nilsson, Greg Young, Udi Dahan, Jimmy Bogard y muchos otros expertos en DDD y CQRS. Pero, sobre todo,
para aprender a aplicar técnicas DDD, debe recurrir a conversaciones, pizarras interactivas y sesiones de modelado
de dominio con expertos de su ámbito empresarial específico.
Recursos adicionales
D D D (d i se ñ o g u i a d o p o r e l d o m i n i o )
A N T E R IO R S IG U IE N T E
Implementar aplicaciones resistentes
03/10/2017 • 1 min to read • Edit Online
Sus aplicaciones basadas en microservicios y en la nube deben estar preparadas para los errores parciales que
seguramente se acabarán produciendo en algún momento. Debe diseñar su aplicación de modo que sea resistente
a estos errores parciales.
La resistencia es la capacidad de recuperarse de errores y seguir funcionando. No se trata de evitar los errores, sino
de aceptar el hecho de que se producirán errores y responder a ellos de forma que se evite el tiempo de inactividad
o la pérdida de datos. El objetivo de la resistencia consiste en que la aplicación vuelva a un estado totalmente
operativo después de un error.
Es todo un desafío diseñar e implementar una aplicación basada en microservicios. Pero también necesita
mantener la aplicación en ejecución en un entorno en el que con seguridad se producirá algún tipo de error. Por lo
tanto, la aplicación debe ser resistente. Debe estar diseñada para hacer frente a errores parciales, como las
interrupciones de red o el bloqueo de nodos o máquinas virtuales en la nube. Incluso los microservicios
(contenedores) que se mueven a otro nodo dentro de un clúster pueden causar breves errores intermitentes dentro
de la aplicación.
Los numerosos componentes individuales de la aplicación también deberían incorporar características de
seguimiento de estado. Mediante las directrices descritas en este capítulo, podrá crear una aplicación que funcione
sin problemas aunque se produzcan tiempos de inactividad transitorios o las interrupciones típicas de las
implementaciones complejas y basadas en la nube.
A N T E R IO R S IG U IE N T E
Proteger microservicios y aplicaciones web de .NET
03/10/2017 • 11 min to read • Edit Online
A menudo es necesario que los recursos y las API expuestas por un servicio se limiten a determinados usuarios o
clientes de confianza. El primer paso para tomar este tipo de decisiones de confianza en el nivel de API es la
autenticación. La autenticación es el proceso de determinar de forma fiable la identidad de un usuario.
En escenarios de microservicios, la autenticación suele controlarse de manera centralizada. Si usa una puerta de
enlace de API, dicha puerta es un buen lugar para realizar la autenticación, como se muestra en la figura 11-1. Si
emplea este método, asegúrese de que no es posible ponerse en contacto directamente con los microservicios
individuales (sin la puerta de enlace de API), a menos que haya aplicado seguridad adicional para autenticar si los
mensajes provienen de la puerta de enlace.
Figura 11-2. Autenticación realizada por un microservicio de identidad; la confianza se comparte mediante un
token de autorización.
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
services.AddIdentity<ApplicationUser, IdentityRole>()
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();
Una vez configurado ASP.NET Core Identity, debe habilitarlo. Para ello, llame a app.UseIdentity en el método
Startup.Configure del servicio.
El uso de ASP.NET Core Identity permite varios escenarios:
Crear información de usuario con el tipo UserManager (userManager.CreateAsync).
Autenticar a los usuarios con el tipo SignInManager. Puede usar signInManager.SignInAsync para iniciar
sesión directamente, o bien signInManager.PasswordSignInAsync para confirmar que la contraseña del
usuario es correcta y, después, iniciar sesión.
Identificar a un usuario en función de la información almacenada en una cookie (que se lee mediante el
software intermedio de ASP.NET Core Identity), de modo que las solicitudes posteriores desde un explorador
incluyan la identidad y las notificaciones del usuario que ha iniciado sesión.
ASP.NET Core Identity también es compatible con la autenticación en dos fases.
ASP.NET Core Identity es una solución recomendada para los escenarios de autenticación que usan un almacén de
datos de usuario local y que conservan la identidad entre las solicitudes mediante el uso de cookies (como es
habitual en las aplicaciones web MVC).
El parámetro redirectUrl incluye la dirección URL a la que el proveedor externo debe redirigir una vez que se ha
autenticado el usuario. La dirección URL debe representar una acción que iniciará la sesión del usuario en función
de información de identidad externa, como en el siguiente ejemplo simplificado:
// Sign in the user with this external login provider if the user
// already has a login.
var result = await _signInManager.ExternalLoginSignInAsync(info.LoginProvider, info.ProviderKey, isPersistent:
false);
if (result.Succeeded)
{
return RedirectToLocal(returnUrl);
}
else
{
ApplicationUser newUser = new ApplicationUser
{
// The user object can be constructed with claims from the
// external authentication provider, combined with information
// supplied by the user after they have authenticated with
// the external provider.
UserName = info.Principal.FindFirstValue(ClaimTypes.Name),
Email = info.Principal.FindFirstValue(ClaimTypes.Email)
};
var identityResult = await _userManager.CreateAsync(newUser);
if (identityResult.Succeeded)
{
identityResult = await _userManager.AddLoginAsync(newUser, info);
if (identityResult.Succeeded)
{
await _signInManager.SignInAsync(newUser, isPersistent: false);
}
return RedirectToLocal(returnUrl);
}
}
Si elige la opción de autenticación Individual User Account (Cuenta de usuario individual) al crear el proyecto de
aplicación web de ASP.NET Core en Visual Studio, todo el código necesario para iniciar sesión con un proveedor
externo ya está en el proyecto, como se muestra en la figura 11-3.
Figura 11-3. Proceso de selección de una opción para usar la autenticación externa al crear un proyecto de
aplicación web.
Además de los proveedores de autenticación externa mencionados anteriormente, hay disponibles paquetes de
terceros que proporcionan software intermedio para el uso de muchos otros proveedores de autenticación
externos. Para obtener una lista, vea el repositorio AspNet.Security.OAuth.Providers en GitHub.
Por supuesto, también puede crear su propio software intermedio de autenticación externo.
Los valores de configuración son los valores de Azure Active Directory que se crean cuando la aplicación se registra
como cliente de Azure AD. Es posible compartir un identificador de cliente único entre varios microservicios de una
aplicación si todos necesitan autenticar a usuarios autenticados mediante Azure Active Directory.
Tenga en cuenta que, cuando se usa este flujo de trabajo, el software intermedio de ASP.NET Core Identity no es
necesario, porque Azure Active Directory controla el almacenamiento y la autenticación de la información del
usuario.
app.UseJwtBearerAuthentication(new JwtBearerOptions()
{
Audience = "http://localhost:5001/",
Authority = "http://localhost:5000/",
AutomaticAuthenticate = true
});
A N T E R IO R S IG U IE N T E