This template use Custom Script extension to call a target URL and pass Azure subscription ID as parameter, in this way every time this template is deployed you will receive a notification with the target subscription’s ID.
Sample template at https://github.com/liarjo/CustomScriptExtensionCallBack
this is my presentation for Boston Alteryx User Group Meeting
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
Para mis amigos que dicen que solo voy a pasear y no trabajo cuando viajo 😛
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.
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.
El siguiente paso nos pregunta qué tipo de protocolo utilizaremos para la ingestión de la señal. Usaremos RTMP, el más popular.
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.
Lo primero en conocer la URL de ingestión, la cual podemos leerlas desde el portal.
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.
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.
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.
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.
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.
Azure es una de las tecnologías que vamos a cubrir en este evento 🙂
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.
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.
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.
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
Ahora estamos listo para comenzar a codificar.
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;
}
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;
}
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
}
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.
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.
![token[2]](https://jpgarcia69.files.wordpress.com/2015/08/token2.jpg)
2. Lista de Métrica
![metricList[2]](https://jpgarcia69.files.wordpress.com/2015/08/metriclist2.jpg)
3. Valores de la métrica
![values[2]](https://jpgarcia69.files.wordpress.com/2015/08/values2.jpg)
El código de ejemplo esta publicado en Git hub en la siguiente liga https://github.com/liarjo/AzureMetricSample
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
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.
Media Butler Framework es un proyecto de código abierto para automatizar procesos de VOD, que lo disfrutes
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.
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.
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.
Lo primero que se debe definir es el nombre de la Farm.
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.
Agregamos el servidor de origen con las opciones por defecto.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
Desde hace un tiempo muchas cargas de trabajo, de diferentes tipos, se están moviendo a la nube por diferentes motivos. Algunos buscan mejor desempeño, mejorar la disponibilidad y confiabilidad de las soluciones, disminuir costos, etcétera. Dentro de las cargas de trabajo que naturalmente están buscando moverse a la nube tenemos las soluciones de medios de comunicación.
Las necesidades de IT para las soluciones de medios podemos describirlas como:
Para estos tres pilares de necesidades de las soluciones de medios podemos encontrar respuesta en las soluciones de computación en la nube y específicamente en Azure Media Services (WAMS).
WAMS ofrece la flexibilidad, escalabilidad y confiabilidad de una plataforma de nube y el manejo de experiencia de medios de alta calidad para audiencias globales. WAMS ofrece solución para ingestión, codificación, conversión de formatos, protección del contenido y trasmisión de video en vivo o bajo demanda para múltiples plataformas y dispositivos.
En WAMS usted puede construir un workflows de inicio a fin completamente en la nube. Desde la subida hasta la distribución del contenido, para ello WAMS provee un amplio rango de componentes listos para usar, pre construidos o de terceros que se pueden combinar para satisfacer su necesidad especifica.
En el contexto de una solución que utilice WAMS para video en demanda (VOD) el cliente tiene que implementar el workflow de publicación utilizando por ejemplo el SDK de punto NET. Esto es una muy flexible manera de implementar un workflow ya que da la libertad a los desarrolladores de codificar de acuerdo a las necesidades específicas de cada caso. Por otra parte, existen clientes que tienen la necesidad de un flujo de publicación VOD muy simple para los que no necesariamente hace sentido desarrollar código a la medida, por ejemplo un flujo como se muestra a continuación.
Para este tipo de escenario fue creado el código de ejemplo/Framework llamado WAMS VOD Butler, que implementa un flujo de procesamiento directo desde un video MP4 hasta la publicación del mismo ya codificado para ser consumido por los diferentes clientes. Para iniciar el proceso se debe subir el video a un contenedor del almacenamiento de Azure y eso gatilla el inicio del trabajo. El proceso se muestra en el siguiente diagrama de secuencia
Una de las características más interesantes que tiene Butler es que los formatos de video de salida son configurables, por lo cual simplemente cambiando la configuración usted puede obtener diferentes formatos de video y empaquetamiento al final del proceso.
En este artículo vamos a implementar WAMS VOD Butler y codificar un video MP4 en formato multi bit rate y lo empaquetaremos de manera dinámica para que pueda ser consumido mediante HTTP Adaptative streaming con diferentes protocolos, por ejemplo HLS para dispositivos IOS y Smooth Streaming para plataforma Windows.
Como primer paso debemos hacer el despliegue de los componentes de Butler en Microsoft Azure. Butler es un servicio construido íntegramente sobre los servicios de Cloud Service y Storage. El siguiente diagrama muestra los componentes de Butler.
Para realizar el despliegue debemos realizar dos tareas:
Para esto se puede ver el articulo How to Create a Media Services Account en http://azure.microsoft.com/en-us/documentation/articles/media-services-create-account/
Para simplificar la creación de estos elementos y la configuración básica de Butler podemos usar el siguiente PowerShell Script
Pare ejecutarlo debemos definir los siguientes parámetros:
El script se ejecuta como se muestra a continuación:
CreateButlerStorageElements -azureSubscritionName ‘jpgarcia69 Windows Azure MSDN – Visual Studio Ultimate’ -butlerContainerStageName ‘stage’ -wamsAcountKey ‘[your Wams Account Key]’ -wamsAcountName ‘testpoweshell’ -butlerStorageAccountName ‘testpowershellstorage’
Una vez que se cuenta con todas los elementos creados en el almacenamiento de Azure debemos hacer deploy del Worker Role que implementa WAMS VOD Butler.
Butler al ser un ejemplo de código abierto está publicado en GITHUB y usted puede descargarlo directamente desde https://github.com/liarjo/WAMSVODButler y abrirlo con Visual Studio para hacer deploy. Lo único que debe hacer es actualizar dos parámetros de configuración:
En ambos parámetros usted debe colocar la cadena de conexión a la cuenta de almacenamiento de WAMS. Una vez actualizada la configuración se hace deploy. Si no conoce cómo hacer deploy con Visual Studio puede ver el articulo Developing and Deploying Microsoft Azure Cloud Services Using Visual Studio en la liga http://msdn.microsoft.com/en-us/magazine/jj618299.aspx
Una vez terminado el despliegue y configuración de WAMS VOD Butler podemos probar su funcionamiento. Primero debemos subir un video MP4 al contenedor de Staging en la cuenta de almacenamiento. La imagen muestra el video en el contenedor.
Una vez que el video está en el contendor, debemos espera a que Butler detecte el nuevo archivo. Cuando lo hace, crea un Asset con el video original, el que está marcado con rojo, y otro que es el video codificado. En este caso en multiBitrate.
Luego nos movemos a ver la lista de JOBS de WAMS y podemos ver que el trabajo de codificación va avanzando.
Una vez que la codificación termina, podemos volver al contenido y ver que ahora solo tenemos un Asset. La razón de esto es que después de codificar el video original ya no se utiliza y por eso por eso Butler lo borró. Por otra parte podemos ver que el nuevo Asset está ya publicado, lo que significa que está listo para ser consumido.
Para probar el video podemos hacer click en el botón Play de Media Services y vemos con el player por defecto el video codificado, como se muestra en la siguiente imagen.
Ahora vamos a probar la característica de WAMS llamada Dynamic Package, como se muestra en el siguiente diagrama. Más información en http://msdn.microsoft.com/en-us/library/jj889436.aspx
Para probar Dynamic Package necesitamos configurar a lo menos una instancia reservada en el servidor de origen de Media Services. Para nuestro ejemplo necesita solo una instancia reservada, cómo hacerlo puede verse en el artículo How to Scale a Media Service en http://azure.microsoft.com/en-us/documentation/articles/media-services-how-to-scale/
Una vez que tenemos al menos una instancia reservada del servidor de origen tenemos que leer desde la cola de notificaciones de Butler. Está cola se llama wamsbutlerallencodefinish y está en la cuenta de almacenamiento de WAMS. Utilizando alguna de las herramientas para el servicio de almacenamiento de Azure podemos ver el contenido del mensaje de notificación y copiar la URL que contiene el manifiesto, como muestra la siguiente imagen.
En este caso de ejemplo la URL es http://testpoweshell.origin.mediaservices.windows.net/f2def825-e100-4490-81d3-3904c065d8bc/BigBuckBunny_400.ism/manifest
Con esta URL podemos usar un player que soporte Smooth Streaming para ver nuestro video usando adaptative streming. Existen multiples opciones para esto, se puede usar para probar el Player llamado vértigo que se encuentra en la liga http://player.smooth.vertigo.com/.
Copiamos en el cuadro de texto llamado Manifest URL la url de nuestro manifiesto y apretamos el botón Set Source and Play y ya podemos ver nuestro video con este modelo de entrega adaptativo como se muestra en la siguiente imagen.
Los próximos pasos con WAMS VOD Butler son comenzar a manejar la configuración para poder obtener formatos de videos que calcen con las necesidades específicas de su sistema.
..:: Liarjo of Locksley ::.. 