Glosario de Azure Web App

En esta entrada se describen operativas relacionadas con Web Apps.

1.- Deployment Slot

En un nivel de servicio Standard o Premium , se permite crear entornos de desarrollo a nuestra Web App. Esto nos posibilita:

  • Testear la aplicación.
  • Permite subir a esteo entorno y realizar el swap o cambio a producción sin perdida de servicio (se automatiza con Auto Swap).

Los pasos son:

  • 1.- Crear el Slotaddslot
  • 2.- Copiar la configuración de otro entorno, así no tenemos que volver a configurar el nuevo entorno.

Cuando se realiza el swap o cambio hay configuraciones que se mueven de un entorno:

  • General settings como el framework version, 32/64-bit, Web sockets
  • App settings (Se puede bloquear para que no se mueva con el check Slot setting en el App Settings)
  • Connection strings (Se puede bloquear para que no se mueva con el check Slot setting en el App Settings)
  • Handler mappings
  • Monitoring and diagnostic settings
  • WebJobs content

Hay otra configuraciones que no se mueven:

  • Publishing endpoints
  • Custom Domain Names
  • SSL certificates and bindings
  • Scale settings
  • WebJobs schedulers

2.- Configurar SSL

  • 1- Dar de alta el dominio. Para ello debemos apuntar al CNAME del dominio de nuestra Web Appaltadominio
  • 2.- Dar de alta el Binding (como haríamos en el IIS). Subimos el certificado y lo bindeamos con el hostname del dominio.binding
Publicado en Azure, web | Deja un comentario

Azure Search II: Indexers

En la anterior entrada se comento el Azure Search. En esta entrada se profundizará en el Indexer.

Indexer

El Indexer es un servicio que realiza crawl de datos con el objetivo de incorporar documentos en un indice. La creación de este servicio se puede realizar en el portal de Azure, mediante desarrollo con la librería NET SDK o mediante llamadas REST API.

Primeros Pasos

  • 1.- Seleccionar los datos de origen a importar. Estos pueden estar contenidos en:

    • Azure SQL (He probado conectarme a un SQL Azure en otra subscripción pero no he podido😦 )
    • SQL Server en una maquina virtual
    • Azure DocumentDB
    • Azure Blob storage
    • Azure Table storage

    Azure Search Importar de un origen de datos en SQL Azure

    Azure Search Importar de un origen de datos en SQL Azure


    NOTA: Solo se puede importar una item (tabla). Si queremos importar varias tablas deberíamos crear una vista e importar esta.😉
  • 2.- Crear el indice a partir de los datos de origen
    Azure Search Importar crear Indice

    Azure Search Importar crear Indice

  • 3.- Definir el periodo en el que se ejecuta el crawl
    azuresearchimportdataschedule
Publicado en Azure, Indices Cache | Deja un comentario

Azure Search

Azure Search

Servicio disponible en Azureazuresearchlarge que permite indexar para información para su posterior búsqueda; como Lucene.
Es escalable tanto a nivel de Servicio (SKU) y nivel de Replicas (número de servicios de Acceso a datos que permite mayor numero de consultas por segundo) o Particiones (número de servicios de indexación e ingesta de datos que permite añadir mayor contenido).

Primeros Pasos

  • 1.- Crear un servicio en Azure Search en el portal de Azure.
    Creación de Servicio Azure Search

    Creación de Servicio Azure Search

  • 2.- Crear los indices que permitirán el acceso a los documentos. Un indice se compone de campos que poseen:

    Se puede crear los indices en el portal de Azure, mediante desarrollo con la librería NET SDK o mediante llamadas REST API.

    Creación de Indice en Azure Search

    Creación de Indice en Azure Search

  • 3.- Subir los documentos al indice. Existen dos opciones:
    • Push: Mediante la librería NET SDK o REST API. Permite tiempo real.
    • Indexer: Configurando un proceso de Crawl a un: Blob storage, DocumentDB, Azure SQL database y SQL Server on Azure VMs. El indice se puede actualizar cada 5 minutos.
  • 4.- Realizar la búsqueda en el indice. Hay diferentes tipos de búsquedas que se pueden combinar para obtener resultados:
    • Search: busca un termino en múltiples campos. Se usa Simple query o Lucene query.
    • Filter: busca coincidencias en un campo. Se usa OData filter language.
    • Suggestions: nos provee de sugerencias para auto-completar términos en las búsquedas.

    Estos resultados pueden ser:

    • ordenados por relevancia (scoring) en función del peso de los campos, fecha del documento valor en campos numéricos, distancia en geospacial o tags.
    • Definir un Scoring en un indice

      Definir un Scoring en un indice

    • ordenados por termino (sorting).
    • paginados (paging).
    • con términos resaltados (hightlighting).
    • con categorías que nos permiten agrupar (facets).
    • número total de resultados.

    Se puede realizar mediante llamadas REST API o mediante desarrollo con la librería NET SDK.

    Multidioma

    El proceso Analyzer divide el texto en múltiples palabras o tokens. Esto proceso se mejora al personalizar el motor; ya permite analizar la relevancia de los tokens (por ejemplo elimina preposiciones de ese idioma) o permite realizar búsquedas con raíces de palabra (por ejemplo caminando, caminar, camina,..). Existen dos motores por idioma; el de Lucene y el Microsoft (este segundo incorpora reglas léxicas más avanzadas😉 ).

Publicado en Azure, Indices Cache | 1 Comentario

Tareas en segundo plano y Azure WebJob

Existen diferentes maneras de ejecutar procesos que permiten hacer tareas en segundo plano:

En esta entrada vamos a centrarnos en el WebJob.

Pasos para crear un Azure WebJob

  • 1.- Botón derecho sobre el proyecto Web Application creado con el ASP NET 4.5.2 template (En el ASP NET 5 template no aparece la opción😦 ) y crear el WebJob.
    newazurewebjobproject
    Diferentes modos para lanzar la ejecución del proceso:
    • Run Continuously: Proceso que va capturando items para procesar de una cola.
    • Run on Demand: Proceso que se dispara manualmente desde la consola de Azure.
    • Scheduled: Porceso que se dispara segun programación horaria.
  • 2.- Crear un Storage Account. En este storage se almacenaran el histórico de ejecuciones y el log del proceso.
  • 3.- Modificar el app.config del proyecto WebJob; con las cadenas de conexión al storage.
    <connectionStrings>
        <add name="AzureWebJobsDashboard" connectionString="DefaultEndpointsProtocol=https;AccountName=name;AccountKey=key"/>
        <add name="AzureWebJobsStorage" connectionString="DefaultEndpointsProtocol=https;AccountName=name;AccountKey=key"/>
     </connectionStrings>
    
  • 4.- Poner el Application Settings del portal de Azure la connection string con el nombre AzureWebJobsStorage apuntando al storage (añadiendo en el web.config de la Web Application no me funciona ¿?). logsazurewebjobEsto habilita la posibilidad de ver la información desde un panel Web.
  • alwaysonwebjob5.- Para que los WebJobs se ejecuten la Web Application debe configurarse a Always On en el Application Settings del portal de Azure. Esto evita que los jobs se aborten al pararse la Web Application.
  • publishwebjob6.- Podemos publicar la Web Application y nos publicara también el WebJob o podemos publicar tambien tan solo el WebJob.

Publicado en Azure | Etiquetado | Deja un comentario

Inversion Of Control

Inversion Of Control

La Inversion Of Control o IOC es un patrón de desarrollo que oculta la implementación de nuestro código mediante una Interfaz. Dos son las principales ventajas que aporta:

  • Rompe dependencias: Permite reemplazar una parte del código sin afectar al resto; posibilitando ser más flexible frente cambios.
  • TDD: Aísla el código, permitiendo aplicar test unitarios.

Su uso se complementa con otros dos patrones:

  • Dependency Injection: Permite crear la clases a partir de la interfaz.
  • Service Locator: Permite definir que clase corresponde al interfaz.

Existen diferentes librerías que proporcionan soporte a IOC:
Microsoft Unity framework, Castle Windsor, NInject,…

Ejemplo en Unity

Se adjunta un ejemplo rápido usando la libraria de Microsoft Unity de este patrón.

  • 1.- Incluir Unity Package en los proyectos.
    Unity Package
  • 2.- Definimos la interfaz que define la funcionalidad.
    namespace Core.Import.Customer
    {
        public interface ICustomerImportService
        {
            void Import();
        }
    }
    
  • 3.- Definimos la clase que implementa la interfaz.
    namespace Core.Import.Customer
    {
        public class CustomerImportService: ICustomerImportService
        {
            public void Import()
            {
               Código que implementa la interfaz....
            }
        }
    }
    
  • 4.- Clase de infraestructura accesible desde todos los proyectos.
    using Microsoft.Practices.Unity;
    
    namespace Infrastructure.Ioc
    {
        public static class UnityContainerFactory
            {
                public static IUnityContainer Container { get; set; }
            }
    }
    
  • 5.- Clase BootStrapper que definen que clases que implementan las interfaces.
    using Microsoft.Practices.Unity;
    using Infrastructure.Ioc;
    using Core.Import.Customer;
    
    namespace App.Ioc
    {
        public static class BootStrapper
        {
            public static void Register()
            {
                var container = new UnityContainer();
                container.RegisterType<ICustomerImportService, CustomerImportService>();
                UnityContainerFactory.Container = container;
            }
        }
    }
    

    NOTA: Al registrar la clase se puede indicar; como se obtendrá la instancia (LifeTime Managers). Los principales 3 son:

    • TransientLifetimeManager: Siempre se crea nueva instancia.
    • ContainerControlledLifetimeManager: Singleton, es decir siempre la misma instancia.
    • PerThreadLifetimeManager: La misma instancia por Thread.
  • 6.- Ya podemos instanciar la clase definida de la interfaz😉.
    var customerImportService = UnityContainerFactory.Container.Resolve<ICustomerImportService>();
    customerImportService.Import();
    
Publicado en net, Patron Software | Deja un comentario

Glosario de Directorio Activo Azure

Cada subscripcion de Azure tiene Azure AD.

Usuario

Hay 4 tipos de usuarios: Del mismo AD, con cuenta Microsoft, de otro AD o invitado (Sharepoint…).
En el siguiente enlace tenemos la vista de nuestro usuario; donde podemos ver nuestro perfil y modificar nuestras aplicaciones. Tendremos más opciones si nuestro usuario pertenece a un Azure AD.

Aplicación

Cualquier usuario no invitado del AD puede registrar una aplicación. Las aplicaciones pueden ser:

  • Nuestras: Creadas en nuestro AD . Esta aplicación (Aplication Object) se muestra como Service Principal en múltiples ADs (incluido en nuestro AD cuando la usamos).
  • Usamos: Incluye ademas de las nuestras otras creadas en otros AD. Es decir, usamos aplicaciones externas😉. La aplicación de otro AD; aparece como un Service Principal en nuestro AD.

Características de la Aplicación Global

  • Identificador: Guid que identifica la aplicación.
  • Tipo de aplicación
    • Web Aplication/Web Api:
      • Application ID URI: URL que identifica la aplicación.
      • Reply Url: URL que indica donde se envia la respuesta cuando el usuario de AD se autentica.
    • Nativa: aplicaciones desktop, jobs… En este caso solo solicita la Reply Url.
  • Key: Se requiere para el proceso de autenticación.
  • Permisos necesarios de la aplicación:
    Requerir permisos para acceder a determinados servicios del Azure AD que son necesarios para la aplicación. Esta parte solo la pueden configurar administradores. A los usuarios se les pedirá el consentimiento para usar estos derechos la primera vez que se conecten (aunque es posible que un usuario administrador del consentimiento para todos los usuarios del AD).
    Los servicios que se puede acceder son:
    • Microsoft Graph: API permite trabajar con los elementos del AD (usuarios, grupos…).
    • Office 365 Management API
    • Windows Azure Active Directory
    • Windows Azure Service Management API: API que permite trabajar con recursos de azure (Maquinas Virtuales, SQL Azure…).
  • Acceso a las Aplicación
    • Las aplicaciones por defecto pueden ser accedidas por todos los usuarios de nuestro AD. Podemos restringir el acceso, requiriendo la User Assignment Required to Access App en la configuración de la aplicación. Y asignando en la aplicación los usuarios o grupo (el grupo sólo AD Premium).
    • Las aplicaciones no pueden ser accedidas por usuarios de otros AD; podemos activar Aplication is MultiTenant (MultiEmpresa) en la configuración de la aplicación para permitirlo.
      NOTA: La aplicación Multitenant para eliminarla del AD; debemos pasarla a SingleTenant y luego borrarla😉.
    • Las aplicaciones nativas son siempre Multitenant; es decir accesibles por otros AD, no es posible restringir a nuestro AD.

Escenarios de Autenticación

En este enlace se describen los escenarios de uso de autenticación contra un Azure AD. Usar las librerías🙂

Proceso de Autenticación de Usuario de una Aplicación en AAD

  • 1.- Se crea la aplicación en un dominio.
    applicationcreation
  • 2.- Cuando el usuario se autentica contra la aplicación la primera vez; se le solicitan los derechos que requiere la aplicación.
    aplicacionrequierederechos
  • 3.- Cuando el usuario concede los derechos a la aplicación; se la crea un registro en el dominio del usuario con la información de la aplicación y se registra allí los accesos que se producen a la misma.
    aplicacionregistrada

Que ocurre internamente cuando el Usuario se autentica la primera vez

La aplicación cuando se registra:

  • Crea un registro de la misma en el Azure AD del usuario se autentico. Si cambiáramos configuración de la aplicación (derechos, url…) deberíamos eliminar dicho registro.
    aplicacionregistrada
  • vistausuarioderechosaplicacionRegistra los permisos concedidos por el usuario a la aplicación. Desde el portal de Azure no podemos ver por el momento esta asignación de permisos por el usuario; pero en la vista de nuestro usuario también vemos los derechos que hemos concedido a la aplicación. Podríamos revocar el acceso de la aplicación a derechos concedidos; eliminándola.
Publicado en Azure, Seguridad | Deja un comentario

Active Geo-Replication SQL Azure

En SQL Azure podemos replicar nuestra base de datos (primaria) hasta en cuatro bases de datos (secundarias). Automáticamente los cambios se traspasan de la primaria a las secundarias. Las secundarias pueden ser accedidas en modo lectura o sin lectura (pensada para desastres-failover). El rendimiento (DTU o eDTU) de la secundarias debe ser el suficiente para admitir las actualizaciones de la primaria. Las funcionalidades que aportar son:

  • Balancear Carga: Múltiples bases de datos para leer datos.
  • Protección ante desastres: Cuando falla la principal, una secundaria puede asumir su rol. En este caso si queremos evitar una perdida critica de datos; deberíamos sp_wait_for_database_copy_sync después del commit de la transacción.
  • Proceso de migración o actualización: Permite copiar la base de datos, con un tiempo de parada mínimo.

Operativa

La operativa se puede realizar en el Portal, Comandos de SQL o script de PowerShell.

  • Creación: Crear una base de datos secundaria. Esta base de datos tendrá el mismo nombre que la primaria pero nos conectarnos a otro servidor
  • Parar replicación: La base de datos secundaria ya no se replica; y se convierte en una base de datos normal (permite escritura de datos).
  • Convertir en primaria: La base de datos secundaria pasa a ser la primaria. En caso de desastres o migraciones.
  • Status de la replicación (únicamente disponible en Comando SQL o Script PowerShell).
Publicado en Sql Azure | Deja un comentario