EPiServer CMS en Microsoft Azure Web Sites

wcm_banner_
Uno de los CMS con el que he estado trabajando estos días es EPiServer CMS, desarrollado tanto en ASP.NET MVC como en Web Forms y que nos ofrece muchas facilidades para su desarrollo como implementación, entre ellas dar soporte a Microsoft Azure.
En este post voy a mostrar los pasos necesarios para desplegarlo en Azure Web sites.

Instalar EPiServer CMS Visual Studio Extension

El primer paso es instalar la extensión EPiServer CMS Visual Studio desde TOOLS > Extensions and updates…

Extensions and Updates

buscando la extensión de EPiServer:

EPiServer CMS Visual Studio Extension

Creación del proyecto EPiServer Web site

La acción anterior requerirá que reiniciemos Visual Studio para poder hacer uso de las nuevas plantillas de EPiServer. Para crear un nuevo proyecto llevaremos a cabo las acciones habituaciones: New Project > y elegimos EPiServer del listado de plantillas disponibles:

Create a EPiServer Web Site project

En el siguiente cuadro de diálogo debemos elegir la plantilla que queremos utilizar. En este post se usará Alloy (MVC) la cual contiene un sitio de ejemplo que nos ayudará a verificar el funcionamiento de la aplicación en Azure Web Sites.

EPiServer Alloy MVC template

Configurar nueva fuente Install-Package EPiServer.Azure

Para que la solución funcione correctamente en Azure Web Sites es necesario instalar el paquete EPiServer.Azure desde Nuget. Antes de llevar a cabo esta operación es necesario añadir una nueva fuente de paquetes específica de EPiServer:

NuGet Package Sources

PM> Install-Package EPiServer.Azure

Servicios necesarios de Microsoft Azure

Para trabajar con EPiServer CMS necesitamos un sitio en Azure Web sites, una base de datos en SQL Database, una cuenta de almacenamiento en Azure Storage y un sistema de mensajería en Service Bus. Todos ellos pueden ser dados de alta desde https://manage.windowsazure.com/ utilizando el botón NEW del menú inferior.

Dentro del archivo web.config debemos añadir el siguiente código en el apartado episerver.framework, que harán referencia a nuestras cuentas de Storage y Service Bus:

<blob defaultProvider="azureblobs">
  <providers>
    <add name="azureblobs" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure"
          connectionStringName="EPiServerAzureBlobs" container="mysitemedia"/>
  </providers>
</blob>
<event defaultProvider="azureevents">
  <providers>
    <add name="azureevents" type="EPiServer.Azure.Events.AzureEventProvider,EPiServer.Azure"
          connectionStringName="EPiServerAzureEvents" topic="MySiteEvents"/>
  </providers>
</event>

episerver.framework section

Cadenas de conexión en la sección CONFIGURE de Azure Web sites

Una vez que tenemos creados los servicios dentro de la plataforma, debemos añadir las cadenas de conexión de cada uno de ellos dentro de la configuración del sitio web. Tenemos dos opciones: modificar el archivo web.config o bien utilizar la sección CONFIGURE de Azure Web sites del portal:

EPiServer connection strings

Las cadenas de conexión que debemos utilizar deben tener como clave EPiServerDB (Azure SQL Database), EPiServerAzureBlobs (Azure Storage), EPiServerAzureEvents (Azure Service Bus). También es posible añadir las cadenas de conexión directamente en el apartado connectionStrings del archivo web.config, pero sería necesario jugar con las transformaciones del archivo para obtener las conexiones correctas dependiendo del entorno:

  <connectionStrings>
    <add name="EPiServerDB" connectionString="Data Source=tcp:YOUR_SERVER.database.windows.net,1433;Initial Catalog=episerverdatabase;User Id=YOUR_USER@YOUR_SERVER;Password=YOUR_PASSWORD;Connection Timeout=60;Integrated Security=True;MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" />
    <add name="EPiServerAzureBlobs" connectionString="DefaultEndpointsProtocol=https;AccountName=YOUR_ACCOUNT_NAME;AccountKey=YOUR_ACCOUNT_KEY"/>
    <add name="EPiServerAzureEvents" connectionString="Endpoint=sb://YOUR_ACCOUNT_NAME.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=YOUR_ACCOUNT_KEY"/>
  </connectionStrings>

Desplegar la solución en Microsoft Azure Web sites

El último paso que debemos realizar es el despliegue de la solución en Azure Web sites. Para ello hacemos clic con el botón derecho sobre el proyecto y seleccionamos la opción Publish…:

EPiServerSiteDemo Publish...

Seleccionamos el Web site que hemos creado en durante el proceso y, el único valor que debemos modificar es seleccionar la opción Update database y seleccionar la cadena de conexión que apunta a Azure SQL Database:

EPiServer update database

Hacemos clic sobre la opción Configure database updates, eliminamos el check de [Auto schema update] y añadimos el script ubicado en la carpeta packages > EPiServer.CMS.Core.7.15.0 folder > tools llamado EPiServer.CMS.Core.sql (este script sólo debe ser lanzado en el primer despliegue).

EPiServer CMS Configure database updates

Publicamos la solución y confirmamos el sitio web funciona correctamente.

EPiServer Alloy template on Azure Web sites

Si es necesario hacer nuevos deployments sobre el mismo web sites, debes seleccionar la opción Remove additional files at destination y deseleccionar Update database:

EPiServer new deployments

Espero que sea de utilidad.

¡Saludos!

Azure Media Encoder: cambio en el precio… ¡y en el código!

El 1 de Octubre se anunció a través del blog oficial de la plataforma un cambio significativo en el precio relacionado con el encoding en Microsoft Azure Media Services: A partir de ahora sólo se cobrará por los gigasbytes de salida del proceso.

Lo que es importante saber es que no se trata de un cambio automático, sino que es necesario ser cuidadosos con el procesador que estamos recuperando de la plataforma, para que este nuevo precio sea el que se nos esté aplicando. Para tenerlo más claro, a través del siguiente código, podemos recuperar el listado de los procesadores que actualmente nos devuelve la plataforma:

using Microsoft.WindowsAzure.MediaServices.Client;
using System;
using System.Linq;

namespace GetAMSProcessors
{
    class Program
    {
        static void Main(string[] args)
        {
            //0. Constants
            const string AccountName = "YOUR_MEDIA_ACCOUNT_NAME";
            const string AccountKey = "YOUR_MEDIA_ACCOUNT_KEY";

            //1. Install-Package windowsazure.mediaservices

            //2. Get context
            var context = new CloudMediaContext(AccountName, AccountKey);

            foreach (var processor in context.MediaProcessors.ToList())
            {
                Console.WriteLine(string.Format("{0} {1}", processor.Name, processor.Version));
            }

            Console.ReadLine();
        }
    }
}

Si ejecutamos el código anterior, podemos observar que existe más de un procesador para la tarea de encoding, pero sólo uno de ellos a día de hoy es el correcto a la hora de aplicar el nuevo precio:

MediaProcessors

Parece algo obvio pero debemos de tener especial cuidado, ya que si utilizamos una versión anterior a Azure Media Encoder 4.1 se nos cobrará tanto por la entrada como por la salida.

Dicho esto, podemos recuperar el procesador correcto de dos formas distintas:

Usando Media extensions

            var processor = context.MediaProcessors.GetLatestMediaProcessorByName("Azure Media Encoder");

O través de la siguiente expresión lambda:

            var processor = _context.MediaProcessors.Where(p => p.Name == "Azure Media Encoder").ToList().OrderBy(wame => new Version(wame.Version)).LastOrDefault();

Happy encoding!

Portal Kudu en Azure Web sites vs Nuevo portal de Azure

Es posible que no conozcas el portal Kudu que acompaña al servicio Azure Web sites. Lo cierto es que el mismo no está anunciado de forma alguna en ninguno de los dos portales que están conviviendo actualmente. Se trata de un portal paralelo que nos permite recuperar información del servidor donde se está ejecutando nuestra aplicación, con el objetivo de diagnosticar nuestro sitio web. Lo cierto es que muchas de las características que se ofrecen a través de este sitio están ya reflejadas en el nuevo portal en https://portal.azure.com/. En este post me gustaría comparar Kudu vs la integración en el nuevo sitio.

En primer lugar, vamos a ver cómo acceder al portal Kudu. Para ello, basta con añadir scm a la URL, entre el nombre elegido por nosotros y azurewebsites.net:

Kudu portal

Para poder acceder a este sitio es necesario tener las credenciales de acceso al portal de Azure, o bien las que utilizamos para los despliegues. En cuanto al nuevo portal, accedemos a http://portal.azure.com y seleccionamos a través del menú lateral BROWSE > Websites > y elegimos el sitio que queremos explorar.

portal.azure.com Website

Una vez dentro de ambos sitios, podemos comparar las diferentes pestañas:

  • Environment: Encontramos información del sistema (versión del SO, número de procesadores, nombre de la máquina, etc.), AppSettings, Connection strings asociados a ese despliegue, variables de entorno, etcétera. Disponemos de un menú para poder movernos entre la diferente información:

    Environment section
    A día de hoy no existe esta información en el nuevo portal, aunque si que es cierto que podemos ver en la sección Site settings los apartados Connection strings y App settings.

  • Debug console: Nos permite lanzar comandos sobre la máquina. Podemos lanzar un CMD o una consola de Powershell:

    Kudu Debug console
    En el nuevo portal, podemos acceder a la consola desde el apartado de Operations:

    Azure portal Operation Console

  • Process explorer: Nos muestra los procesos que se están ejecutando, he incluso podemos matar un proceso, obtener un volcado de memoria del mismo, etcétera:

    Kudu Process explorer
    Al igual que el anterior, en el apartado de Operations encontramos el acceso a la consola, donde se nos permite únicamente matar procesos utilizando el botón derecho:
    Azure portal Operation processes

  • Tools: Disponemos de varias herramientas que nos permiten descargar un volcado de memoria, descargar el script del despliegue, web hooks o acceder al log del servidor.

    Kudu Tools
    En el nuevo portal, tenemos la opción Log stream (Streaming logs) tanto a nivel de servidor como de aplicación, pero a día de hoy no está disponible por ejemplo la opción de descargar volcados de memoria o web hooks:
    Azure portal Operations Streaming logs

  • Site extensions: Se trata de una de las partes más interesantes del portal, ya que nos permite instalar y lanzar extensiones asociadas a nuestro sitio web.

    Kudo site extensions
    En el caso del nuevo portal, la parte de extensiones está ubicada en la sección Configuration:

    Azure Portal Site Extensions

Como veis, tenemos todo un conjunto de herramientas que pueden aportarnos un valor añadido al servicio de web sites, con el objetivo de dar más control al desarrollador tanto en el diagnóstico como en ampliar la funcionalidad del servicio de una manera sencilla. Las características más importantes ya están a nuestra disposición en el nuevo portal de Azure, por lo que os animo a que echéis un vistazo a la integración, ya que resulta mucho más cómodo que tener que cambiar de portal.

Espero que sea de utilidad.

¡Saludos!