Docker dans Azure


Azure Loves Linux, comme je disais Smile
L’article suivant est la contribution 100% de mon collègue Maxime Launay, enthousiaste et passionné du Cloud Azure.
Voici cet article dans son intégralité – Merci Maxime !



Cet article présente la mise en place, en ligne de commande, d’une plateforme de développement hébergée sur Microsoft Azure et utilisant Redmine, Jenkins et Gitlab via la technologie de conteneur Docker. Attention, il ne présente pas la création d’un container Docker, uniquement son utilisation.

Contexte

Fin 2014, un client m’a sollicité pour mettre en place une plateforme de développement Open Source. Ces besoins étaient très précis :
- Déployer rapidement ;
- Utiliser git comme contrôleur de code source ;
- Utiliser Jenkins comme outils d’Intégration Continue ;
- Utiliser Redmine comme bug tracker ;
- Conserver « la main » sur les environnements ;
- Limiter les coûts de mise en place et d’exploitation ;
- Avoir des procédures d’installation simples permettant une reconstruction rapide de l’environnement.
Pour l’hébergement, l’utilisation du Cloud Public m’a semblé parfaitement adaptée aux besoins et comme le client avait des affinités avec Microsoft Azure, la décision fut rapide. Pour répondre aux autres besoins, j’ai tout de suite pensé à l’utilisation d’un « petit » projet qui monte, Docker. Je me décidais donc à franchir le pas pour vérifier l’intérêt du couple Azure / Docker.

L’infogérance des environnements Azure avec Operational Insights

Azure Operational Insights est une toute nouvelle offre de service type SaaS - actuellement en preview (bêta) - qui permet de monitorer, capturer, gérer et analyser les informations venant de votre système informatique concernant la configuration, la performance, la capacité, le bon état de santé, les incidents de tout type, les mises à jour, les changements au niveau logiciel.
image
OpInsights – comme nommé plus brièvement – se base sur l’ancienne offre System Center Advisor, qui a été en échange revue et élargie comme fonctionnalité. Ce service cible des environnements à demeure ou cloud et est censé à compléter – ou remplacer même – System Center Operations Manager. Il peut travailler en tandem avec SCOM mais également se dispenser de tout outil d’analyse de monitoring traditionnel.
Comment ça fonctionneComme vous allez voir, un agent installé dans votre environnement (sur les machines à monitorer) enverra des informations vers le service OpInsights. Le type d’informations capturées et envoyées variera en fonction des différentes fonctionnalités que vous activez (Log Management, Update Assessment, Change Tracking ou autres). Ensuite vous pouvez utiliser ces informations via des outils très puissants d’analyse et via des ergonomies adaptées.
Démonstration
En étant ici dans un blog focalisé 100% sur Azure, nous utiliserons Operational Insights pour gérer des environnements hébergés dans Azure. Encore plus, aujourd’hui nous discuterons précisément des environnements type IaaS (Infrastructure-as-a-Service).
Notre but sera donc de monitorer 2 VMs standard Azure hébergés en Europe (à Dublin), à l’aide d’Azure Operational Insights.
Les étapes principales seront:
1. Ouverture d’un espace de travail OpInsights
2. Installation de l’agent et configuration des machines cible
3. Activation des Intelligent Packs OpInsights
4. Suivi de l’activité opérationnelle
Allons-y:

Using Azure Resource Manager within Azure Automation


I am publishing here an extract of a post on MSDN Forums, about the utilization of Azure Resource Manager within Azure Automation.

The answer to the question asked in this post, given by Joe Levy, a Microsoft employee, is more important than the original thread. It may be a temporary solution, but also a long term one (if the ARM module will not be exposed by default in Azure Automation).

Here it is:


·        We do not ship the Azure Resource Manager module out of the box yet in Azure Automation like we do the Azure (AzureServiceManagement) module. We have done some limited testing on the ARM module in Azure Automation. If you would like to import this module yourself, here are the steps to get ARM set up in Azure Automation:
Step 1 – Create an Azure Automation Integration Module from the AzureResourceManager PowerShell module.
Navigate to the AzureResourceManager module within the Azure PowerShell directory on a host with Azure PowerShell installed.

Zip up the AzureResourceManager folder.
Step 2 – Import into Azure Automation
Importing this zip as an integration module into Azure Automation works fine as the below screenshots show:

Step 3 – Write a Runbook that uses AzureResourceManager functionality
Like you normally would, except no need to use Switch-AzureMode to switch between AzureServiceManagement and AzureResourceManager, as both AzureServiceManagement and AzureResourceManager modules are now in the PS path.


Thanks, Joe!

Azure VNET to VNET VPN, across regions and data centers: not so complicated

After finding very interesting articles like this one (thanks, Matt Davies) around recently announced features on Azure, I wanted to push further the IaaS  experience on Microsoft’s public cloud by connecting multiple Azure virtual networks simultaneously, eventually across data centers. The utilization of this functionality becomes quickly interesting in various scenarios, like geo-highly available applications and disaster recovery plans.

So here is my scenario: let’s say we need 1 VNET in North Europe region (Dublin) to be connected to a second VNET  in the same datacenter and to a third one in West Europe (Amsterdam). We will test the result simply by pinging between 3 VMs, one in each VNET.

image

Assumption: in order to keep this article to a reasonable size, I assume you are somehow familiar already with the main (Azure) IaaS concepts (VNET, VPN, VM, Local Network …).

Azure SQL Database : scénario de reprise d'activité et performance avec la géo-réplication active

Parmi des centaines des fonctionnalités arrivant en masse sur le Cloud Azure, voici une qui simplifiera la vie des responsables IT: la géo-réplication des bases de données SQL Database. Comme démontré ci-dessous, nous pourrons utiliser cette fonctionnalité pour augmenter le niveau de disponibilité de votre application et la préparer pour les cas de catastrophe (“disaster recovery”).  Mais la géo-réplication peut servir également à l'amélioration de la performance applicative.

Scénario de reprise d’activité

La nouvelle structure des éditions SQL Database (actuellement en preview public) est composée des niveaux Basic, Standard et Premium. L’édition Premium inclut la fonctionnalité dite de géo-réplication active: pour une base de données hébergée sur un serveur qui se trouve dans une sous-région (datacenter) Azure (ex. Europe / Dublin), il y a l’option d’associer un réplica hébergée dans un autre data center de la même région (dans ce cas-là: Europe / Amsterdam).
Ce réplica sera synchronisé en permanence et de manière transparente avec la base originelle et fera en sorte qu’en cas d’indisponibilité du datacenter source, pour pourrez faire rapidement basculer votre application vers le datacenter destination.
(en l’occurrence, vous aurez les machines virtuelles / les services applicatifs hébergés dans le datacenter destination et prévus à se connecter à la base de données réplica.)