Blog de Florent Appointaire

Blog sur les technologies Microsoft (Windows Server, System Center, Azure, Windows Azure Pack/Azure Stack, etc;)
    • 27/4/2017

    [StarWind] Déployer Virtual SAN Free sur Azure

    Aujourd'hui, je vais vous montrer comment utiliser StarWind Virtual SAN Free sur Azure. Ceci vous permet de présenter des LUNs, à des VMs. vous utiliserez donc moins de disque que pour du Storage Space Direct par exemple, si vous n'utilisez pas le produit en HA bien sur.

    Vous pouvez télécharger le produit et la licence ici: https://www.starwindsoftware.com/starwind-virtual-san-free

    Le Quick Start guide se trouve ici: https://www.starwindsoftware.com/technical_papers/quick-start-guide-creating-ha-device-with-starwind-virtual-san-free.pdf 

    Pour commencer, j'ai déployé l'infrastructure suivante sur Azure:

    • Un groupe de ressource StarWind
    • Un réseau virtuel StarWindNetwork
    • 4 machines virtuelles:
      • Une machine VirtualSan avec 4 disques de 500GB
      • Une machine Node01 (jointe au domaine, avec le rôle File Server et la feature Failover Clustering)
      • Une machine Node02 (jointe au domaine, avec le rôle File Server et la feature Failover Clustering)
      • Une machine FLOAPP-DC02

    Je fais une configuration de base. Il faudrait bien entendu séparer les réseaux (Stockage, Cluster, Management).

    J'utilise des Managed Disks, comme ça, je n'ai pas besoin de me préoccuper de la localisation des disques (plus de LRS, GRS, ZRS, etc.).

    Pour commencer, initialisez les disques sur la machines qui va accueillir le logiciel StarWind Virtual SAN Free et créez un volume. J'ai pour ma part fait un miroir, sur 2 volumes différents, F: et G:.

    Démarrez l'installation du logiciel Starwind, après l'avoir téléchargé sur le serveur ainsi que la licence:

    Acceptez la licence:

    Relisez les informations concernant l'utilisation du produit:

    Choisissez où installer StarWind Virtual SAN:

    Ici, je vais choisir l'installation Full (avec le connecteur SMI-S, pour le connecter par la suite avec SCVMM):

    Choisissez où stocker le raccourci:

    Créez ou non un icône sur le bureau:

    Si vous vous êtes enregistré avec le lien au début de l'article, vous devez avoir une licence:

    Choisissez la licence que vous avez reçu:

    Les informations sur la licence sont disponibles:

    Voici le résumé de l'installation:

    L'installation est terminée, vous pouvez ouvrir la console:

    Au premier lancement, il va vous demander où stocker par défaut le storage pool. Dans mon cas, sur mon volume G: qui est en miroir:

    Cliquez droit sur le serveur, et choisissez Add Device (advanced):

    Choisissez d'ajouter un Hard Disk Device:

    Et choisissez le type Virtual Disk, car nous allons stocker ceci sur des disques virtuels:

    Choisissez où stocker votre virtual disk, ainsi que son nom et sa taille: 

    Choisissez le type de provisionnement: 

    Choisissez le paramètre de cache RAM: 

    Et si vous avez un Flash Cache ou pas: 

    Créez une nouvelle iSCSI target pour pouvoir vous connecter à ce serveur, depuis d'autres serveurs: 

    Cliquez sur Create pour créer votre premier disque: 

    Le disque a été créé avec succès: 

     La vue depuis la console StarWind:

    Et depuis l'explorer: 

    Sur chaque serveur du Cluster (Node01 et Node02 pour moi), lancez le logiciel iSCSI Initiator et cliquez sur Yes: 

    Renseignez l'IP de votre serveur StarWind et cliquez sur Quick Connect: 

    Une fois la connexion établie, vous devriez voir le statut Connected: 

      

    Si vous ouvrez l'explorer de management de disque, un nouveau disque est apparu:

    Initialisez le et créez un nouveau volume: 

    Une fois terminé, que vous avez les 2 serveurs connectés, vous devriez voir les 2 iSCSI connectés dans la console StarWind:

    Ajoutez le disque au Cluster.

    Si vous créez un SOFS, vous pouvez créer un nouveau partage, en stockant les données sur le disque:

    Vous pouvez vous connecter au share du SOFS et copier des données dedans:  

    Vous avez la même vu depuis le CSV ou depuis le Share: 

    Pour conclure, ce logiciel peut vous êtes utile si vous souhaitez faire des économies sur Azure, même si le stockage n'est pas la ressource la plus cher dans le cloud.

    • 10/4/2017

    [Windows Server 2016] Passer de Evaluation à Retail


    Si comme moi, vous n’avez pas pu attendre la sortie de la version retail pour installer Windows Server 2016 l’an dernier, il va falloir activer le serveur si vous souhaitez continuer à l’utiliser.

    Vous trouverez plus d’informations ici : https://technet.microsoft.com/en-us/windows-server-docs/get-started/supported-upgrade-paths?f=255&MSPPError=-2147217396

    Pour faire ceci, il faut que la version soit au moins 14393.0.161119-1705.RS1_REFRESH.

    Pour vérifier que vous êtes bien en version d’évaluation, utilisez la commande suivante :

    slmgr.vbs /dlv

    Vérifiez ensuite si votre serveur est en licence Standard ou Datacenter pour installer la clé qui correspond à votre version. Dans mon cas, c’est une licence Datacenter:

    DISM /online /Get-CurrentEdition

    Lancez l’installation ce la clé avec la commande suivante :

    DISM /online /Set-Edition:ServerDatacenterCor /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula

      

    Après quelques instants, le serveur va vous demander de redémarrer:

    Après le redémarrage, vous pouvez vérifier que la clé a bien été installé et que vous êtes maintenant en version retail avec la commande suivante :

    slmgr.vbs /dlv

    • 30/3/2017

    [GitHub Enterprise] Sauvegardez le contenu

    Si vous ne sauvegardez pas votre machine qui contient votre GitHub Enterprise, vous pouvez sauvegarder directement le contenu GitHub du serveyr. Mon serveur de backup est sous Debian 8. La première étape est d'installer rsync si il n'est pas encore installé:

    apt-get update && apt-get install rsync

    Maintenant, téléchargez l'utilitaire de backup et décompressez le. Copiez la configuration et modifiez la:

    wget https://github.com/github/backup-utils/releases/download/v2.9.0/github-backup-utils-v2.9.0.tar.gz
    sudo tar -xvzf github-backup-utils-v2.9.0.tar.gz
    cd /tmp/github-backup-utils-v2.9.0
    sudo cp backup.config-example backup.config
    sudo vi backup.config

    Ajoutez le nom de votre serveur GitHub (assurez-vous de pouvoir pinguer ce serveur) et sauvegardez la configuration:

    Maintenant; exécutez la commande suivante pour effectuer votre première sauvegarde:

    cd bin/
    sudo ./ghe-backup -v

    -v est pour le verbose.

    Acceptez le certificate. La sauvegarde démarre:

    Maintenant que votre serveur Github est sauvegardé, déployez un nouveau serveur GitHub ou utilisez celui ci.

    Si vous utilisez un nouveau serveur GitHub, importez le certificat, refaites la configuration de base, comme l'intégration SAML, etc.

    Maintenant, enregistrez la clé SSH de votre serveur de sauvegarde dans l'interface GitHub et placez votre serveur GitHub en mode maintenance:

    Vous pouvez démarrer la restauration avec la commande suivante:

    sudo ./ghe-restore IPADDRESS -v

    IPADDRESS est l'adresse ip du serveur qui contient le GitHub où vous souhaitez restaurer la dernière sauvegarde:

    C'est très simple à faire avec cet outil mais aussi très simple à automatiser avec un job cron.

    • 28/3/2017

    [GitHub Enterprise] Changer le certificat avec Lets Encrypt

    Par défaut, le certificat utilisé pas le serveur GitHub Enterprise est auto-signé. Si vous ne pouvez pas acheter de certificat, vous pouvez utiliser LetsEncrypt pour avoir un certificat trusté publiquement. Celui ci doit être renouvelé tous les 3 mois.

    Le serveur GitHub est comme une appliance, il ne faut rien installer dessus, c'est pourquoi, pour générer ce certificat, il faut utiliser un autre serveur. Je vais utiliser un serveur sous Debian 8 pour faire ceci. Nous allons utiliser le paquet certbot pour générer le certificat.

    La première étape est d'enregistrer le répertoire et installer le paquet:

    echo "deb http://ftp.debian.org/debian jessie-backports main" | sudo tee -a /etc/apt/sources.list
    sudo apt-get update
    sudo apt-get install certbot -t jessie-backports

    Quand c'est terminé, utilisez la commande suivante pour démarrer la génération du certificat public, avec le nom GitHub et les noms DNS inclus. Remplacez domaine.be par votre nom DNS:

    sudo certbot certonly --manual --preferred-challenges dns -d github.domain.be -d alambic.github.domain.be -d assets.github.domain.be -d avatars.github.domain.be -d codeload.github.domain.be -d gist.github.domain.be -d pages.github.domain.be -d render.github.domain.be -d reply.github.domain.be -d uploads.github.domain.be -d raw.github.domain.be -d media.github.domain.be

    Le script va vous demander de créer des enregistrement DNS, de type TXT, pour chaque sous-domaine, avec une valeur spécifique, pour vérifier que vous êtes bien le propriétaire du domaine:

    Quand c'est terminé, vous avez un message d'information:

    Sur le serveur, créez un répertoire temporaire, et copiez y le certificat fullchain.pem et privkey.pem dans ce dossier:

    sudo mkdir /tmp/certificates
    sudo cp /etc/letsencrypt/live/github.domain.be/fullchain.pem /tmp/certificates/fullchain.pem
    sudo cp /etc/letsencrypt/live/github.domain.be/privkey.pem /tmp/certificates/privkey.pem

    Quand c'est terminé, téléchargez ces certificats sur l'ordinateur depuis lequel vous allez faire la configuration GitHub. Connectez vous à l'interface d'administration, dans la partie Privacy et sélectionnez vos 2 certificats. Cliquez sur Save sur la gauche:

    Les services vont redémarrer:

    Les services ont redémarré correctement:

    Si vous rafraichissez votre page GitHub, vous allez avoir votre nouveau certificat, validé par votre navigateur:

    Et depuis l'interface d'administration GitHub, vous avez un certificat valide:

    C'est gratuit, rapide à mettre en place, donc oubliez les certificats auto signés et utilisez des certificats valides :)

    • 13/3/2017

    [GitHub Enterprise] Authentification avec Azure AD

    Avec les dernières versions de GitHub Enterprise, il est possible d'utiliser l'authentification via SAML, ce que propose Azure AD. Pour mettre en place ceci, il vous faut donc:

    • Un Azure AD
    • Un environnement GitHub Enterprise

    Pour commencer, il faut créer une application sur votre Azure AD. Depuis le nouveau portail, allez dans votre Azure AD, et créez une nouvelle application, de type WebApp / API. La partie SignOn URL correspond à l'URL de votre GitHub Enterprise:

    Vérifiez bien dans l'application que les permissions soient bien avec au moins Sign in and read user profile:

     

    Il faut maintenant récupérer le fichier FederationMetadata.xml. Pour ce faire il faut aller sur l'URL suivante, en remplaçant l'ID par l'ID de votre tenant, que vous pouvez retrouver dans votre Azure AD:

    https://login.windows.net/TENANTID/FederationMetadata/2007-06/FederationMetadata.xml

    Récupérez la valeur qui se trouve au niveau de la flèche, dans la balise X509Certificate:

    Copiez les données dans un fichier texte, puis, tous les 80 caractères, allez à la ligne:

    Enregistrez ce fichier avec l'extension .cert

    Allez maintenant sur la page d'administration de votre GitHub Enterprise, dans la partie Authentication. Ici, choisissez SAML et dans Single Sign On URL, fournissez l'URL suivante, en remplaçant TENANTID par l'ID de votre Azure AD. Fournissez le certificat que vous avez enregistré avant:

    https://login.microsoftonline.com/TENANTID/saml2 

    Sauvegardez. Vous devriez avoir ceci:

    Allez maintenant sur votre URL GitHub. Au moment de vous connecter, vous devriez être redirigé vers la page d'authentification de Microsoft. Connectez-vous avez votre compte Azure AD. Vous devriez ensuite arriver sur la page GitHub:

    Comme vous pouvez le voire, le . dans le nom d'utilisateur est remplacé par un -.

    Bon courage pour cette manipulation et n'hésitez pas si vous avez des questions :)

    • 23/2/2017

    [Azure] Migrer du portail Classic vers ARM


    Christophe Lams, Cloud Solution Architect, a publié une série d'article pour migrer depuis la version classic de Azure, vers ARM, en utilisant Azure Site Recovery. 

    Voici les différents articles qu'il propose:

    1. Création des VMs classic au travers du nouveau portail
    2. Création du vault ASR
    3. Configuration du réseau
    4. Installation de l'agent de mobilité
    5. Préparation de l'infrastructure ARM
    6. Création du Recovery Plan
    7. Failover
    8. Finalisation de la migration

    Cette série d'article est très intéressante pour vous aider à migrer rapidement de l'ancien mode Azure, vers le nouveau.

    • 22/2/2017

    [Azure] Azure Site Recovery avec ARM - Partie 2


     

    Voici donc la deuxième partie de l'implémentation de Azure Site Recovery avec ARM: 

    Réplication des premières VMs

    Maintenant que l’infrastructure est prête sur Azure, nous allons pouvoir répliquer les VMs/Applications. Choisissez de où vous souhaitez répliquer les VMs (On-Premises pour moi) et sélectionnez le site Hyper-V que vous avez créé dans le premier article :

    Sélectionnez le compte de stockage que vous avez créé au début pour stocker les réplications, mais aussi le réseau que vous avez créé et le sous-réseau associé :

    Sélectionnez enfin les VMs que vous souhaitez protéger avec la réplication :

      

    Choisissez le type d’OS ainsi que le disque OS. Choisissez enfin les disques que vous souhaitez répliquer :

    Appliquez la police créée précédemment :

      

    La réplication commence :

      

    Depuis la console Hyper-V, vous pouvez voir que la réplication a commencé :

    Modification de la VM avant Failover

    Avant de tester le failover, il faut choisir la taille de la VM qui sera déployée et aussi, paramétrer le réseau. En effet, vous pouvez décider de faire tourner la VM sur une taille plus petite en mode dégradé. Et ici, étant donné que mon application a été mal codé et que j’ai une IP fixe dans le code, je vais réattribuer la même IP que dans mon réseau local actuel à cette VM. Si vous ne précisez rien, le DHCP prendra la première IP disponible dans le pool :

    Test du Failover

    Il est maintenant temps de tester le failover. J’ai éteint mon infrastructure, et donc, plus personne ne peut travailler. Dans la console Azure, sur votre réplication de votre application, cliquez sur Unplanned Failover pour dire que votre application doit être déployé sur Azure.

    Choisissez le point de sauvegarde que vous souhaitez restaurer. Je n’ai pas synchronisé les derniers changements car mon infrastructure n’est plus disponible, et j’aurai donc perdu dans mon cas, maximum 15 minutes de données (délai de réplication des VMs vers Azure) :

    Le déploiement de ma VM sur Azure est en cours :

    10 minutes plus tard, ma VM a été déployé dans Azure :

    VNet Peering

    J'ai créé un VNet Peering entre le réseau qui contient mon DC et mon réseau ASR. Vous pouvez retrouver la procédure pour faire ceci ici. Vous pouvez également automatiser cette partie.

    Test de mon application

    En me connectant sur mon DC sur Azure, je peux voir que je ping directement la nouvelle machine ASR (grâce au network peering) et que je peux accéder au site web :

    Et en rajoutant un NLB et en créant une règle NAT, sur le port de l’application, vers la VM qui vient d’être déployé, mes utilisateurs peuvent continuer à travailler, juste en faisant pointer votre DNS, vers la nouvelle IP public du NLB :

      

    Maintenant que votre application est fonctionnelle, il faut faire un Commit du failover :

    Failback

    Votre datacenter est de nouveau opérationnel, il faut donc rapatrier les données avec les changements qu’il y a eu. Pour faire ceci, cliquez sur Planned Failover :

      

    Vous souhaitez faire le failover de Azure vers votre Datacenter. Si vous avez perdu vos données, vous pouvez décider de créer une nouvelle VM dans votre datacenter, sur un hôte bien précis :

    Une fois que le failback est terminé, vous devriez avoir ceci :

      

    Cliquez sur Commit pour valider le changement vers votre datacenter :

      

    Le dernier delta est envoyé :

    Enfin, le failback est terminé :

      

    Pour terminer, il faut réactiver la réplication de la VM vers Azure. Cliquez sur Reverse replicate :

    Si je refais le test, depuis ma VM qui est sur Azure, vers la même IP qui est dans mon datacenter, vous pouvez voir que maintenant, je passe de nouveau par mon VPN S2S et que le site Web n’a pas changé :

    Pour aller plus loin

    Si vous souhaitez aller plus loin, ici nous avons fait le failover pour une seule VM. Vous pouvez créer un groupe de VM, dans la partie Recovery Plan pour faire un failover sur plusieurs VM d’un seul coup :

    Vous pouvez également gérer directement les paramètres de l’infrastructure ASR dans la console Azure, sans passer par le Step-By-Step :)

    Conclusion 

    Cette fonctionnalité est très intéressante pour les sociétés qui ont des applications business critiques pour faire tourner l’entreprise. Même en mode dégradé, les employés peuvent continuer à travailler et donc, faire perdre un minimum d’argent à la société. Ne vous en passez donc pas :)

    • 21/2/2017

    [Azure] Azure Site Recovery avec ARM - Partie 1

    Aujourd’hui, nous allons voir comment implémenter une solution de DRP, avec Azure Site Recovery. Je vais déployer cette solution, basé sur ARM. ASR peut également servir pour des migrations de VM vers Azure mais aussi de VMWare vers Azure, etc.

    Dans mon plan de DRP, le service que j’ai défini comme critique est un site web. Je vais donc répliquer cette VM sur Azure, avec ASR. J’aurais pu faire de même avec une application multi tier.

    Dans mon architecture, j'ai une VPN Site-2-Site vers Azure. Attaché au réseau qui est connecté au 2ème VPN, se trouve mon deuxième contrôleur de domaine, qui fait également DNS.

    Il y aura 2 articles:

    • 1er article: Mise en place de la solution Azure Site Recovery
    • 2ème article: Replication des VMs et Failover/Failback

    Virtual Network et stockage

    Dans un premier temps, je vais préparer mon réseau qui accueillera mon DRP. Ce réseau aura le même sous-réseau que mon réseau dans mon datacenter. Pourquoi ? Car mon application web a été mal codé et qu’il y a des IPs en dur dans le code :)

    Vous pouvez également modifier les DNS, etc. de ce réseau.

    Créez également un compte de stockage qui contiendra les réplications.

    Nouveau Recovery Volt

    Maintenant que le réseau est prêt, créez un nouveau Recovery Volt en allant sur + > Storage > Backup and Site Recovery (OMS) :

    Donnez un nom à votre vault et choisissez la destination et le groupe de ressource associé :

    Après quelques instants, le vault a été créé :

    Configuration

    La première étape étant terminé, il est maintenant temps de commencer la configuration. Dans votre vault, cliquez sur Site Recovery > Step 1 : Prepare Infrastructure et choisissez où vous souhaitez répliquer vos machines (Azure dans mon cas, mais ça peut être sur un site secondaire), si les machines sont virtuelles et si oui, sur quel type d’hyperviseur (Hyper-V pour moi, mais ce peut être VMWare) et enfin, choisissez si vous utilisez SCVMM pour gérer vos hôtes :

    Il faut maintenant créer un site Hyper-V. Ce site contiendra tous les Hyper-V d’un site, par exemple Bruxelles. Vous pouvez par la suite ajouter d’autres sites. Cliquez sur + Hyper-V Site et donnez un nom à ce site :

      

    Sélectionnez-le et cliquez sur + Hyper-V Server pour installer l’agent sur le/les serveur(s) Hyper-V qui contient la/les VM à répliquer sur Azure pour le DRP :

    Dans les instructions, il est dit que l’Hyper-V doit au moins être sur Windows Server 2012 R2, que le proxy doit autoriser les URLs de ASR et ensuite, il vous propose de télécharger l’agent de ASR ainsi que la clé du vault pour le site que vous avez créé précédemment :

    Copiez l’agent et la clé sur l’Hyper-V. Pour l’installer, utilisant la partie Server Core pour mes Hyper-V, j’ai utilisé les lignes de commandes suivantes pour installer l’agent et installer la clé :

    .\AzureSiteRecoveryProvider.exe /x:. /q

    Cd ‘C:\Program Files\Microsoft Azure Site Recovery Provider\’

    .\DRConfigurator.exe /r /Friendlyname ‘FLOAPP-HPV02’ /Credentials ‘C:\Temp\ASRFLOAPP_HYPERVFLOAPP_Wed Feb 15 2017.VaultCredentials’

    Après quelques minutes, l’Hyper-V apparaît dans la console Azure :

    Choisissez maintenant sur quelques suscriptions Azure vous souhaitez répliquer la VM avec ASR (la suscription où vous avez créé le compte de stockage et le réseau) ainsi que le type de déploiement que vous souhaitez utiliser, Classic ou Resource Manager (ARM) :

    Nous allons maintenant créer une règle pour la réplication, pour définir la durée entre chaque point de réplication, le nombre de point de réplication que vous souhaitez conserver, etc. Cliquez sur Create and Associate :

    Et fournissez les valeurs suivants ce que vous souhaitez implémenter :

    Une fois la règle créée, sélectionnez la et cliquez sur OK:

    Exécutez le capacity planner (https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-capacity-planner ) et une fois que ceci est terminé, cliquez sur OK :

    Dans le prochain article, nous verrons comment répliquer les VMs et faire le failover/failback :)

    • 16/2/2017

    FALA Consulting

    Bonjour à tous,

    Je profite de ce billet pour vous annoncer que je viens d'ouvrir ma SPRL en Belgique, sous le nom de FALA Consulting SPRL: http://www.falaconsulting.be

    Je suis disponible pour vous aider à migrer vers Azure par exemple, mais aussi pour tout ce qui tourne autour des Technologies Microsoft, et plus particulièrement Azure Stack, WAP, System Center, Hyper-V.

    N'hésitez pas à me contacter si vous souhaitez avoir des renseignements à florent [at] falaconsulting.be

    Florent

    • 15/2/2017

    [Azure] SQL Server et .Net Core dans ACS

    Dans un billet précédent, nous avons vu comment déployer Azure Container Services. Microsoft a publié une suite de 3 billets pour le déploiement de SQL Server et .Net Core dans des containers sur ACS:

    Cette suite est très intéressante et montre bien le virage que prend Microsoft, en se lançant dans les containers. Et donc, pour les entreprises, la possibilité de faire tourner des applications Business développé en .Net, directement dans des containers :)

    • 8/2/2017

    [Azure] Ajouter plusieurs administrateurs d'un coup

    J'ai eu la demande d'ajouter plusieurs utilisateurs d'un Azure AD Administrateur de la suscription Azure, en ARM. Etant feignant et ne voulant pas ajouter les 10 utilisateurs à la main, j'ai décidé d'écrire un script PowerShell (au cas où on me demande de le refaire plus tard). Ce script est disponible sur Gallery Technet:

    https://gallery.technet.microsoft.com/Add-multiple-admins-in-an-07c7cf59

    Pour l'utiliser, créez un fichier CSV au même endroit que votre script, avec les 3 colonnes suivantes:

    • Email
    • FirstName
    • Lastname

    Sur mes 4 utilisateurs, je n'en ai que 1 qui est actuellement Owner. Le script ajoutera donc les 3 autres:

    Choisissez votre suscription Azure:

    Si il y a un souci pendant l'ajout, vous aurez un message d'erreur:

    Et si l'ajout se passe bien, vous aurez des messages d'informations:

    Et dans ma vue Azure:

    Si vous avez des questions, remarques ou suggestions, n'hésitez pas :)

    • 27/1/2017

    [Azure] Intégration continue / Déploiement continue avec Docker (ACS et ACR), Visual Studio Code, Visual Studio Team Services et GitHub

    Une des grandes forces des infrastructures de nos jours, est le fait de pouvoir réaliser, du CI/CD. Comprenez, Continous Integration et Continus Deployment.

    En résumé, ces techniques, permettent à vos développeurs, de créer/modifier leur code, de l’envoyer sur Github par exemple, de le compiler avec Visual Studio Team Services (VSTS), de l’enregistrer sur votre registry (Azure Container Registry dans mon cas), de gérer les versions, toujours avec VSTS, de l’envoyer comme container sur votre Docker Swarm et pour finir, d’y accéder par une simple interface web.

    Nous allons donc voir comment faire ceci (la documentation Microsoft est disponible ici). Pour commencer, vous devez être sûr d’avoir ceci :

    Avant de commencer, vous devez déployer sur votre ACS, le container Docker qui permettra d’installer l’agent VSTS. Le container et sa documentation sont disponibles ici : https://hub.docker.com/r/microsoft/vsts-agent/

    Il faut un token pour pouvoir installer cet agent. Allez dans votre VSTS > Votre Compte > Security :

    Cliquez sur Add pour créer un nouveau Token :

    Sélectionnez bien Agent Pools (read, manage) comme permission et créez le token :

    Sauvegardez bien la clé qu’il va vous donner car vous ne pourrez pas la récupérer ultérieurement. Connectez-vous sur un serveur qui a Docker pour installer l’agent VSTS (il est également possible de déployer cet agent sur un container Docker). Mon serveur tourne avec Ubuntu 16.04. Dans l’interface VSTS, cliquez sur Settings > Agent queues > Download Agent et sélectionnez votre OS :

    Téléchargez l’agent sur le serveur et exécutez la commande de configuration en remplaçant par l’URL de votre VSTS. Fournissez la clé que vous avez créé juste avant pour l’authentification :

    wget https://github.com/Microsoft/vsts-agent/releases/download/v2.111.1/vsts-agent-ubuntu.16.04-x64-2.111.1.tar.gz

    mkdir myagent && cd myagent

    tar zxvf /home/florent/vsts-agent-ubuntu.16.04-x64-2.111.1.tar.gz

    ./config.sh –url https://floapp.visualstudio.com –auth PAT



    L’agent est maintenant configurer. Pour le lancer, exécutez la commande ./run.sh :

    Pour que tout ce petit monde parle ensemble, il faut dans un premier temps, installer le composant docker, qui va permettre d’interagir entre VSTS et Docker. Sur le marketplace de Visual Studio ( https://marketplace.visualstudio.com/items?itemName=ms-vscs-rm.docker ) cliquez sur Install :

    Puis choisissez sur quel compte VSTS l’installer :

    Pour continuer, récupérez un token sur votre compte GitHub, qui a les permissions repo, user, admin:repo_hook :

    Il faut maintenant associer votre compte GitHub avec notre VSTS. Ouvrez votre projet, puis cliquez sur Settings > Services :

    Ici, cliquez sur New Service Endpoint > Github :

    Dans la nouvelle fenêtre, renseignez le token que vous avez généré avant, ainsi que le nom de votre compte associé à ce token :

    Il faut maintenant enregistrer la registry Docker, en cliquant sur New Service Endpoint > Docker Registry :

    Renseignez les informations de votre registry, que vous pouvez trouver sur Azure, dans la partie Container Registry > Access Key :

    Pour terminer cette partie-là, il faut ajouter un service de type SSH. Donnez un nom, l’URL de connexion que vous retrouvez sur Azure, dans la partie Container Service, le port (2200 par défaut), le nom d’utilisateur que vous avez renseigné lors de la création de ACS et enfin, la clé privée utilisé à la création :

    La partie configuration est maintenant terminée. Passons à la suite. Nous allons commencer par créer une build de base. Allez sur votre VSTS, puis dans Build & Release. Cliquez sur New > Empty :

    Cliquez ensuite sur Github, puis sélectionnez Continuous integration et enfin, choisissez l’agent de type Default :

    Sur votre nouvelle définition, cliquez sur Repository et sélectionnez le compte Github que vous avez configuré avant, ainsi que le repository que vous souhaitez utiliser pour le CD:

    Allez maintenant dans Triggers et sélectionnez Continuous Integration. Ceci aura pour effet de déclancher le trigger à chaque Commit de l’application :

    Puis cliquez sur Save :

    Mon application, que je souhaite déployer, contient une seule image, nginx. Je vais donc créer 2 Docker steps, une pour envoyer l’image sur ACS et l’autre sur ACR. Cliquez sur Add build step… dans Build :

    Choisissez Docker et cliquez sur Add 2 fois (pour ACS et ACR):

    Pour le premier build, sélectionnez la connexion vers votre registry, l’action Build an image, le chemin vers votre Dockerfile qui est sur Github, le chemin avec les sources et votre Dockerfile et pour finir, le nom de votre image, avec le chemin complet vers votre registry :

    Pour la partie push sur votre Registry, sélectionnez la connexion vers votre registry, l’action Push an image et enfin, le nom de votre image complète vers votre registry :

    Pour terminer, il faut ajouter la step suivante, uniquement si vous avez un docker-compose.yml, pour les applications multi-tiers. Sinon, passez à l’étape suivante :

    • Command Line ()
      • Tool : bash
      • Arguments: -c "sed -i 's/BuildNumber/$(Build.BuildId)/g' sources/docker-compose.yml"

    Et pour tout le monde, vous devez ajouter l’étape de publication de l’artifact, avec les sources :

    • Publish Build Artifacts
      • Path to publish: sources
      • Artifact Name: FloAppWebsite2
      • Artifact Type: Server

    Cliquez sur Save pour sauvegarder la configuration.

    Créez ensuite une nouvelle configuration pour la release, pour pousser le container sur votre ACS. Dans Releases, cliquez sur le + puis choisissez Empty et enfin, cliquez sur Next :

    Voici à quoi devrait ressembler votre release definition :

    Nous allons maintenant créer un articfact. Dans votre release, cliquez sur Artifacts, Link an artifact source et donnez un autre nom. Cliquez sur Link :

    Puis, passez le en tant que primaire :

    Cliquez maintenant sur Triggers et cochez la case Continuous Deployment, puis sélectionnez le nouvel artifact que vous avez créé juste avant :

    Sauvegardez. Cliquez sur Add tasks dans Environments dans votre nouvelle release, puis ajoutez une tache de type SSH avec la commande suivante et en décochant la case Fail on STDERR :

    docker login $(docker.registry) -u $(docker.username) -p $(docker.password) && export DOCKER_HOST=10.0.0.4:2375 && if docker inspect --format="{{ .State.Running }}" floappcicdwebsite >/dev/null 2>&1; then echo "Container floappcicdwebsite exist."; docker rm -f floappcicdwebsite; docker run --name floappcicdwebsite -d -p 80:80 floappregistry-on.azurecr.io/floappregistry/websitefloapp2:$(Build.BuildId); else echo "floappcicdwebsite does not exist, creation"; docker run --name floappcicdwebsite -d -p 80:80 floappregistry-on.azurecr.io/floappregistry/websitefloapp2:$(Build.BuildId); fi;

    La commande va se connecter à la registry, télécharger l’image et la déployer si elle n’existe pas déjà, ou la remplacer si elle est déjà existante, avec la dernière version publiée :

    Il faut ajouter 3 variables :

    • username : contient le nom d’utilisateur pour se connecter à la registry
    • password : contient le mot de passe associé à l’utilisateur pour se connecter à la registry
    • registry : contient l’url pour se connecter à la registry

    N’oubliez pas de sauvegarder.

    Il est maintenant temps de tester notre configuration. Pour commencer, modifiez votre code source, et envoyez-le sur Github. Après quelques secondes, sur votre VM où l’agent VSTS tourne, vous devriez voir ceci :

    Et depuis la console VSTS, je peux voir que l’étape de Build s’est bien déroulée :

    Tout comme la release :

    Et si j’essaye donc d’accéder à mon URL qui redistribue vers les agents Docker, j’ai ceci :

    Je vais maintenant modifier mon index.html, et l’envoyer sur mon GitHub. Voici du coté de l’agent VSTS ce qu’il se passe :

    Et du coté de VSTS, une nouvelle build, 35 (contre 34 avant), est disponible :

    Et la release :

    Voici ce que ça donne du côté de ma WebApp :

    Et en vidéo: