Curso DevOps en la práctica para WebApps en Azure

Este curso lo hicimos con Alex Campos en 3 partes, comenzamos explicando lo básico de Web Apps para luego explicar como automatizar el despliegue y por ultimo como obtener metricas de nuestro sistema. Estos son los modulos

Modulo 1

devops1

Modulo 2

devops2

Modulo 3

devops3

Contenido relacionado

Azure Media Services Live Streaming using FFMPEG

Introducción

Azure Media Services tiene la capacidad de hacer live streaming como se explica en este link. En este post vamos a utilizar FFmpeg para capturar, codificar e inyectar una señal RTMP en un Channel de Media Services.

Configuración paso a paso

  1. Crear un ChannelLo primero que se debe hacer para configurar un escenario de Live streaming es crear un canal en Media Services. Para ello en el portal de Azure, en la cuenta de Media Services se selecciona la sección de Channels y ahí Add new channel.

    1

    Como parte del proceso de creación debemos dar un nombre, descripción y tipo de codificación al canal. En nuestro caso, no usaremos codificación en Azure ya que FFmpeg la realizará localmente por lo que seleccionamos Encodig Type none.

    2

    El siguiente paso nos pregunta qué tipo de protocolo utilizaremos para la ingestión de la señal. Usaremos RTMP, el más popular.

    3

    Por último, vamos a configurar restricciones de acceso al canal. En nuestro caso como es una demo no aplicaremos restricciones pero en un ambiente productivo se debe proteger el canal para que no se pueda enviar señal desde cualquier origen.

    4

  2. Configurar FFmpegUna vez terminado la creación del canal y está en estado Ready ya podemos configurar FFmpeg.

    Lo primero en conocer la URL de ingestión, la cual podemos leerlas desde el portal.

    5

    Para ejecutar FFmpeg utilizaremos el script livebrodcast.bat , que se describe a continuación

    set ffmpeg=.\ffmpeg-20150109-git-d1c6b7b-win64-static\bin\ffmpeg

    set videoDevice=Integrated Camera

    set audioDevice=Microphone (Realtek High Definition Audio)

    set ingestURL=rtmp://demoffmpeg-mediabutlerdev.channel.mediaservices.windows.net:1935/live/1c11bbadd489450bb03655cb50390b39

    set streamName=mystream1

    %ffmpeg% -v verbose -rtbufsize 2100M -f dshow -i video=”%videoDevice%”:audio=”%audioDevice%” -strict -2 -c:a aac -b:a 128k -ar 44100 -r 30 -g 60 -keyint_min 60 -b:v 400000 -c:v libx264 -preset medium -bufsize 400k -maxrate 400k -pix_fmt yuv420p -f flv %ingestURL%/%streamName%

    En este script se debe especificar el dispositivo de video y audio a utilizar en la captura así como la URL de ingestión.

  3. Ejecutar FFmpeg commandUna vez actualizado el archivo livebrodcast.bat con nuestra información podemos ejecutarlo.

    7

    Al ejecutarlo veremos una salida por pantalla como la siguiente, donde vemos las estadísticas de la trasmisión en la última línea por ejemplo fps 43.

    8

  4. Ver el video en PreviewUna vez que ya comenzamos a alimentar el canal de Media Services y este ya ha acumulado un buffer podemos ver la señal de Preview o control en el mismo portal como se muestra en la siguiente captura de pantalla.

    9

    Para revisar el retardo de la señal, se puede utilizar un reloj y ver la diferencia de tiempo entre el reloj y la señal online.

    10

    Este retardo es el tiempo total que acumula la captura de la señal, la codificación, la ingestión en el canal, el procesamiento del canal y DVR, más la latencia para consumir la señal desde la nube nuevamente.

Conclusiones

Azure Media Services ha simplificado los requerimientos de un escenario para realizar Live Streaming al punto que con un device que envié RTMP ya puedes hacer trasmitir utilizando esta solución de nube.

Es muy sencillo utilizar un software en el punto de captura y completar la cadena para hacer trasmisiones en vivo.

Links relacionados

  1. Automation of premium encoding in Azure Media Services with Media Butler
  2. Enterprise Video: Local cache para Azure Media Services
  3. Windows Azure Media Services: Publicar videos para IOS y Windows Phone #azure

Cómo leer métricas en una máquina virtual de Azure?

Introducción

Una vez que las compañías comienzan a utilizar servicios en la nube, nace inmediatamente la necesidad de leer métricas de los recursos, por ejemplo el uso de memoria, CPU, etc.

En este post vamos a desarrollar una aplicación que lee estas métricas de una máquina virtual corriendo en Microsoft Azure usando Azure Insights REST API.

El siguiente esquema muestra los elementos involucrados y el orden en que debemos hacer las llamadas para poder leer las métricas.

exquema

Prerrequisitos

Para poder utilizar las métricas, debemos tener una máquina virtual corriendo en Microsoft Azure con la configuración de Diagnostic On como se muestra en la siguiente imagen.

DiagnosticOn

Una vez que tienes la máquina virtual corriendo y recolectando las métricas debes proveer un usuario de Azure Active Directory para que pueda leer los valores de las métricas de ese recurso como se muestra en la siguiente imagen.

roles

En este momento tenemos acceso de lectura para ese usuario.  Ahora debemos registrar nuestra aplicación cliente en Active Directory para que esta pueda autentificarse con el usuario y leer las métricas. El tipo de aplicación en AAD es Native client Application, y agregar el permiso para otras aplicaciones llamado Windows Azure Service Managment API como se muestra en la siguiente captura de pantalla

appIdPermissions

Ahora estamos listo para comenzar a codificar.

Aplicación cliente

Obtener el cliente

La primera llamada que debemos hacer es para autentificarnos y obtener el json token y así poder  hacer la llamada a la API y el servicio de Storage. El método GetAuthorizationHeaderSilent retorna un string que contiene el Token.

public string GetAuthorizationHeaderSilent()
{
	AuthenticationResult result = null;
        var context = new AuthenticationContext("https://login.windows.net/" + TenantId);
        // Directly specify the username and password. 
        var credential = 
           new Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential(
                    this.UserName,
                    this.Password);
         result = context.AcquireToken(
                "https://management.core.windows.net/",
                this.ClientId,
                credential);
         if (result == null)
         {
            throw new InvalidOperationException("Failed to obtain the JWT token");
         }
         jToken=result.AccessToken;
          return jToken;
}

 

Obtener la lista de métricas

Cada máquina virtual puede tener definidos diferentes grupos de métricas, por lo que debemos obtener la lista de las métricas que están activas para esa instancia. El método LoadMetricDefinitions retorna el json file con la lista de métricas y dónde se encuentran almacenados los valores recolectados de cada métrica.

public  async Task  LoadMetricDefinitions(string ResourceGroup, string Provider, string VmName,string Filter)
{
	string url=String.Format(ListMetrcis, SubscriptionId, ResourceGroup, Provider, VmName, apiVersion, Filter);
        string MetricListResponse = null;
        var client = new HttpClient();
        client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", jToken);
        string stringResponse = null;
        try
        {
           MetricListResponse = await
           client.GetStringAsync(
             String.Format(
		ListMetrcis, 
		SubscriptionId, 
		ResourceGroup, 
		Provider, 
		VmName, 
		apiVersion, 
		Filter));
           stringResponse = MetricListResponse.ToString();
        }
        catch (Exception Err)
            {
                Console.WriteLine(Err.Message);
            }
            return stringResponse;
}

 

Leer el valor de las métricas

Con la lista de métricas y su definición podemos ahora leer desde el servicio Azure Storage los valores de esas métricas. Para hacer eso usamos el método GetMetricStorageData que recorre el documento json con la definición de las métricas y lee la métrica que le indicamos con la variable MetricName. La respuesta del método también es un documento json con los valores de la métrica.

public TableMetricData GetMetricStorageData(string jsonMetricDefinition,string MetricName)
{
 TableMetricData myData = null;
 try
 {
 var jsonData = Newtonsoft.Json.Linq.JObject.Parse(jsonMetricDefinition);
 foreach (var allList in jsonData)
 {
 var list = allList.Value;
 
 foreach (var xxx in list)
 {
 if (xxx["name"]["value"].ToString() == MetricName)
 {
 myData = new TableMetricData();
 foreach (var metricAvailabilities in xxx["metricAvailabilities"])
 {
 myData.tableEndpoint=
 metricAvailabilities["location"]["tableEndpoint"].ToString();
 foreach (var tableInfo in metricAvailabilities["location"]["tableInfo"])
 {
 myData.TableName = tableInfo["tableName"].ToString();
 myData.sasToken=tableInfo["sasToken"].ToString();
 }
 myData.partitionKey = metricAvailabilities["location"]["partitionKey"].ToString();
 }
 break;
 }
 }
 }
 }
 catch (Exception Err)
 {
 Console.WriteLine(Err.Message);
 }
 return 
}

Aplicación de ejemplo

La aplicación de ejemplo que usa los tres métodos expuestos anteriormente es del tipo consola y se muestra a continuación.

static void Main(string[] args)
{
	IMetricProvider myMetric = MetricProviderFactory.GetProvider(0);
	string counterName =  @"\Processor(_Total)\% Processor Time";
	 //1. obtain the JWT token
	 Console.ForegroundColor = ConsoleColor.Red;
	red("My Token is:");
	string myToken = myMetric.GetAuthorizationHeaderSilent();
	Console.WriteLine(myToken);
	Console.WriteLine("");
	//2. Get Metrcis List
	//You need to use your own Data here
       	string ResourceGroupName = "metricsampleRG";
        string ProviderName="Microsoft.Compute";
        string VirtualMachineName="metricsample";

	red("Get Netric List");
	Task<string> defTask=   myMetric.LoadMetricDefinitions(
                    ResourceGroupName,
                    ProviderName,
                    VirtualMachineName,
                   "");
	defTask.Wait();
	string jsonMetricDefinition = defTask.Result;
	PrintMetricDefinition(jsonMetricDefinition);
	//3. Get Metric values Table storage 
       	red("Get Metrics values storage");
	TableMetricData xData = myMetric.GetMetricStorageData(jsonMetricDefinition, counterName);
	//4. Read Values
	red("Metric Values");
	Task<string> readTask = myMetric.ReadMetricValues(xData);
	readTask.Wait();
	PrintValues(readTask.Result, counterName);
	Console.ReadLine();
}

Para poder ejecutar el ejemplo deben actualizar las variables ResourceGroupName, ProviderName y VirtualMachineName con los nombres de su grupo de recursos, el tipo de proveedor que usaron y el nombre de la máquina virtual. Todo esto pueden leerlo en el portal de Azure en las propiedades de la máquina virtua campo Resource ID.

resourceID

Al ejecutar el ejemplo verán primero el token, segundo la lista de métricas disponibles y por último los valores de una de las metricas como se muestra en las siguientes imágenes.

  1. Token

token[2]

2. Lista de Métrica

metricList[2]

3. Valores de la métrica

values[2]

 

El código de ejemplo esta publicado en Git hub en la siguiente liga https://github.com/liarjo/AzureMetricSample

Conclusiones

Para leer métricas de una máquina virtual que está corriendo en Microsoft Azure debemos usar la API Azure Insights.  Ahora, para llegar al valor de la métrica debemos hacer tres llamadas consecutivas. Primero obtener el token de autentificación, luego leer la lista de métricas disponibles para por último los valores de esas métricas.

En este post revisamos paso a cómo hacer estas llamadas y utilizamos un ejemplo completo que está publicado en GITHUB, que lo disfruten

Automation of Premium Encoding in Azure Media Services with Media Butler

Azure Media Services tiene un Encoder Premium que permite hacer trascodificaciones avanzadas, puede leer más aquí.

Para poder hacer uso de Azure media Services Encoder Premium dentro un proceso automático de producción de video en demanda o VOD se puede hacer uso de Media Butler Framework. Un ejemplo de ello puede verse aquí.

Este proceso automático de ejemplo implementa el siguiente proceso de VOD.

preminencoderprocess1

Media Butler Framework es un proyecto de código abierto para automatizar procesos de VOD, que lo disfrutes

Enterprise Video: Local cache para Azure Media Services #azure

Introducción

Una de las cargas de trabajo que hace mucho sentido mover a la nube es el Streaming de videos en demanda desde la nube. Las razones son múltiples, costos, elasticidad, etc.

En el contexto de Enterprise video, por ejemplo cuando el presidente de una empresa le habla a sus colaboradores, donde todos los consumidores del video vendrán de la red interna hace sentido utilizar un nodo de cache local para ahorrar tráfico sobre internet.

En este post, vamos a configurar un nodo de cache de contenidos VOD que están siendo servidos desde un Origin Server de Azure Media Services, como se muestra en el siguiente diagrama.

0

Instalación de IIS Application Request Routing

Esta solución se basa en las funcionalidades de IIS Application Request Routing (ARR) de proxy y cache. La idea es que los player usen como dirección de reproducción la URL del servidor IIS local y este obtenga la información desde Media Services la primera vez y luego utilice una copia almacenada en el cache local.

Más información de ARR la pueden ver en Application Request Routing

La instalación de ARR es muy simple utilizando Web Platform Installer, solo buscar ARR 3.0, lo seleccionas y luego instalar como se muestra en la imagen 2.

2

Una vez instalado ARR, utilizando IIS Manager creamos una nueva Farm. La farm es la definición de un Web Front que está compuesto por varios nodos.

3

Lo primero que se debe definir es el nombre de la Farm.

4

Luego debemos agregar los servidores de origen del contenido, en nuestro caso es el Origin Server de Azure Media Services. En el portal, podemos leer la URL del servidor de origen. En este ejemplo es jpbutler.origin.mediaservices.windows.net como se muestar en la siguiente captura de pantalla.

5

Agregamos el servidor de origen con las opciones por defecto.

7

Una vez terminada la creación del FARM se deben crear las reglas URL rewrite, las cuales en este caso son las reglas por defecto por lo que podemos aceptar la auto creación de las mismas.

8

Prueba de la configuración de ARR Web Farm

Una vez realizada la configuración de la FARM en ARR podemos realizar la siguiente prueba.

Primero vamos a consumir el video desde Media services, que sería la forma en que normalmente se consume cuando no hay un proxy intermedio. Para esto vamos a utilizar el player Silverligth llamado Vertigo que nos permite ver video utilizando Smooth Streaming. Este player nos permite escribir la URL del archivo manifiesto del video y verlo.

La URL de vertigo player es http://player.smooth.vertigo.com/ y la URL del archivo manifiesto en el servidor de origen es http://jpbutler.origin.mediaservices.windows.net/626e3f3a-bfc2-48fc-9077-b7fa826d15ca/dfxptest.ism/Manifest

La siguiente captura de pantalla nos muestra cómo se ve el video en este primer caso.

9

Una vez comprobado que el video se ve directamente desde Media Services, vamos a probar que podemos consumirlo desde el proxy intermedio, implementado con IIS ARR. Para esto vamos a utilizar la URL del servidor IIS http://smoothcache.cloudapp.net/626e3f3a-bfc2-48fc-9077-b7fa826d15ca/dfxptest.ism/Manifest

En mi caso, creé un servidor IIS en una máquina virtual de Azure. En un escenario real, este servidor sería un IIS que está instalado en la red local del cliente.

En esta segunda captura de pantalla podemos ver cómo el mismo video se consume desde el servidor IIS con ARR, el player no distingue que el contenido viene desde Media Services sino que para él el servidor de origen es el IIS ARR.

10

Configuración de IIS ARR Cache

Hasta este momento hemos utilizado la capacidad de proxy de IIS ARR cuando generamos una Web FARM. Esto es muy útil en muchos escenarios, ahora para resolver el problema de consumo de ancho de banda internet de los empleados de una corporación que quieren ver el video del discurso del presidente, necesitamos agregar la capacidad de hacer Cache local.

Esto quiere decir que el proxy cuando obtenga un chunck del video, además de enviarlo al player para que lo proyecte guarde ese trozo de información de modo que el siguiente cliente que necesite esa parte del video pueda consumirlo desde el Cache local y no desde el origen del video en Media Services.

Para configurar el cache de ARR debemos ir a ARR a nivel de servidor y abrir las Features como se muestra en la siguiente pantalla de IIS Manager.

11

Aquí se deben agregar los discos de cache. Estos discos son el storage donde se almancena la información del cache. Se utilizan dos discos, uno primario y el otro secundario.

En nuestro ejemplo, utilizo los dos discos locales del servidor. El disco primario será D:\Cache y el secundario C:\cache. En una solución de producción es recomendable utilizar un storage externo y rápido. La creación de estos dos discos se muestra en las dos siguientes pantallas de IIS Manager.

 1213

Una vez agregado los discos de cache, debemos activarlo en el nivel de Web Farm. Con esto, de ahora en adelante además de actuar como Proxy será también un cache local.

Esto lo hacemos abriendo las propiedades del icono cache en la Web Farm.

14

Los datos de configuración del cache se muestran en la siguiente captura de pantalla. La idea es que los objetos duren en memoria 5 segundos y luego se guardan en disco. Si la Web Farm recibe una nueva petición para ese objeto lo leerá desde el disco y lo mantendrá nuevamente en memoria por 5 segundos

15

Prueba de la configuración de IIS ARR Cache

Una vez terminada la configuración podemos probar nuevamente el consumo de los videos desde el servidor IIS ARR, y validar cómo se van almacenando los chunck del video en el disco local del cache.

La prueba que se hace es consumir con dos clientes diferentes el video, en este caso utilizando Vertigo Player en Chrome y FireFox. Las siguientes dos imágenes muestran los videos en los clientes ya mencionados.

17

18

Por último, podemos ver la utilización del disco en IIS Manager y en el disco primario. La siguiente imagen muestra que el 0.35% de la capacidad del disco primario utilizada por la copia local de este video.

Además, podemos ver que en el disco que se ha creado una estructura de archivos que sigue la jerarquía de servidor de origine, ruta y elemento. Por ejemplo, los fragmentos del video en diferentes calidades ya están almacenado en el cache.

19

Conclusiones

En este ejercicio hemos realizado la instalación y configuración de un Web Farm con funcionalidades de Proxy y Cache. Esto nos permitió mostrar solucionar el problema que se presenta en el contexto de soluciones de Enterprise Videos, donde se requiere hacer almacenamiento local de los contenidos para ahorrar ancho de banda de internet cuando los diferentes empleados ven los videos corporativos.

Esta es una implementación basada en IIS ARR, que es un servicio flexible y configurable en diferentes escenarios. Por ejemplo, si se requiere una implementación en alta disponibilidad es posible utilizando a lo menos 3 servidores IIS ARR que actúan como uno.

Articulos relacionados