Dans cet article, je vous détaille la partie (cachée) de ma démo lors de ma session au Microsoft Expérience 17 avec Stanislas Quastana. Le but de cet article est de préparer le terrain pour les articles suivants. Les prochains arriverons rapidement, avec dans l'idée, de vous aider à mieux appréhendez le CI/CD en tant qu'OPS, pour des sujets qui nous concernent, l'infra as code.

Voici le chemin que nous allons suivre :

  1. Préparation de l'environnement [nous sommes ici]
  2. Préparation d'une image de base Linux
  3. Préparation d'une image de base Windows
  4. Utilisation des images de base pour les spécialiser, afin de les rendre "Immutables"
  5. Déploiement d'image en CI/CD avec Packer et Terraform depuis VSTS
    Nous utiliserons des technologies Microsoft (VSTS, Azure, Windows Server...) mais aussi HashiCorp (Packer, Terraform) ainsi que des technologies Open Source (Linux..). Il n'est normalement pas nécessaire d’être, ni un maître du cloud, ni un demi dieu de l'infra as code pour suivre cette mini séries de 4 articles.

Création des comptes nécessaire

Il faut créer un compte sur Visual Studio Team Services ici et un compte Azure ici.

Création du Workspace VSTS

Création du Projet

https://{votrenomavous}.visualstudio.com/_projects?_a=new
Indiquez le nom que vous souhaitez et sélectionnez Git comme "Version Control" :

Initialisation du repository

C'est prêt


Voila, 3 étapes, notre premier projet est "prêt".

Préparation de l'Agent pour VSTS

Préparation de la VM

Dans Azure, avec le template suivant, déployez une vm Ubuntu basique.
Installez les prérequis de l'agent VSTS via les commandes suivantes :

sudo apt-get install -y libunwind8 libcurl3
sudo apt-add-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git
apt-get install libcurl4-openssl-dev

Installation de l'agent

Préparation dans VSTS

Accédez à la partie sécurité https://{votrenomavous}.visualstudio.com/_details/security/tokens et créer un PAT (Personnal Access Tokens).

Attention, c'est comme un mot de passe, il ne faut pas le diffuser. (Keepass, LastPass et autres peuvent les stocker correctement!).

Dans notre cas, l'agent devra avoir les droits Agent Pools et Deployment Group, car nous n'utiliserons qu'un seul agent. En prod, séparez-les !

Installation de l'agent

wget https://github.com/Microsoft/vsts-agent/releases/download/v2.123.0/vsts-agent-ubuntu.16.04-x64-2.123.0.tar.gz -O vsts-agent-ubuntu.16.04-x64-2.123.0.tar.gz
mkdir agent && cd agent
tar -xvf ../vsts-agent-ubuntu.16.04-x64-2.123.0.tar.gz
./config.sh

# Répondez aux questions

sudo ./svc.sh install
sudo ./svc.sh start

Pour plus d'info sur l'agent VSTS

Vérification dans VSTS

Si vous accédez à l'url https://{votrenomavous}.visualstudio.com/_admin/_AgentPool vous devriez voir que votre agent est en vert !

Introduction

Avant de foncer dans le code de notre infra, nous allons devoir réflechir à l'organisation de nos dossier de "Code".

Ok, maintenant qu'on à réflechi, on y va !

Nous allons générer deux images de base Ubuntu et Windows Server, utiliser des scripts "commun" et des scripts spécifiques, puis spécialiser nos images.

Let's Git

Dolly, ou Clone, comme vous voulez

Ouvrez donc Visual Studio Code (Quoi ? Il est pas déjà installé?) et ajoutez votre repository Git VSTS dans VS Code (Vous devez installer Git sur votre poste avant).

C'est assez simple, cliquez sur "Clone Git Repository":

Récupérez l'url de votre repository dans VSTS :

Puis collez le dans la barre de VS code :

Entrez votre destination, par exemple c:\Users\vous\Documents\git (la racine, le dossier sera créer automatiquement) , puis indiquez vos credentials VSTS, et enfin lorsque le clone est terminé, cliquez sur "Open This repository":

Félicitations, vous avez réussi a cloner votre git vsts sur votre poste!

Ouais, mais moi j'y comprends rien à Git, j'vais jamais m'en sortir !

Git, comment ça marche

Bon, on va faire simple, Git en usage basique comme on va le faire, ce n'est que quelques opérations :

  1. Git clone -> On récupère un git distant sur notre poste de travail
  2. Git Add -> on ajoute les fichiers dans le git "local"
  3. Git Commit -> on valide nos modification (en local)
  4. Git pull -> on va chercher les modifications coté remote
  5. Git push -> on pousse nos modifciation vers remote

Vous inquiétez pas, VS Code va faire beaucoup à notre place !

Création des dossiers

Il faut quand même savoir une petite chose de plus, Git ne gère pas les dossiers vide, il faut donc créer un petit fichier readme.md pour les synchroniser correctement.
Pour créer les dossiers, soit vous le faite en "graphique" :

Soit via le terminal intégrer avec vos commandes préférées (View -> Integrated Terminal).

Personnellement j'ai créer 4 dossiers à la racine  : scripts, windows, ubuntu et specialized, puis dans les dossiers Windows et Ubuntu un sous-dossier scripts. dans chacun de ces dossiers ajouter donc un fichier vide readme.md (et sauvegardez-les). Vous verrez plus tard le "pourquoi" cette arborescence :).

Commit

Maintenant on va "commit" nos modifications en cliquant sur les boutons (et en écrivant le pourquoi du commit :)) :

Youpi! votre premier commit ! (c’était dur?)

Push

Avec notre premier commit, en bas de notre fenêtre VS Code, nous avons désormais un commit à envoyer :


Le chiffre de gauche correspond aux modifications distante (vos collègues), celui de droite, les locales (les votre quoi :))

Pour savoir ce qui se passe, ouvre la console "Output" (View, Output, puis sélectionnez Git dans le menu déroulant à gauche)

Allez dans VSTS sur votre navigateur, vous avez tous vos fichiers qui se trouvent désormais sur le Server.

Introduction

Voici un petit récapitulatif ce qu'on aimerait :

Vous devez créer deux comptes de stockage dans Azure vous même, un de "Production" et un "Eval" vous pouvez le faire avec Azure Cloud Shell depuis le portail Azure :

#create resource group
az group create -l westeurope -n vstsforops
#create storage account
az storage account create -n sto0eval -g vstsforops -l westeurope --sku Standard_LRS
az storage account create -n sto0prod -g vstsforops -lwesteurope --sku Standard_LRS

Du coup je vous ai déjà préparer les éléments histoire de ne pas perdre de temps sur la construction des templates packer. Récupérez l'archive ici : Download ZIP, puis copiez les fichiers dans votre répertoire que vous avez cloné la fois dernière. J'ai fais quelques modifications sur la hiérarchie des dossiers afin que ça soit plus évolutif dans le temps, nous y reviendrons plus tard.

Le fichier packer qui nous intéresse est dans le dossier /storage/windows/base/windows_base_packer.json, il est tout a fait standard, comme ceux que Stanislas détaille ici

Vous noterez peut être que j'ai ajouté un provisionner "windows-update" :

"provisioners": [
{
"type": "windows-update"
},

Celui n'est pas standard, vous devez le mettre dans le même répertoire que votre exécutable packer, il est téléchargeable à l'adresse suivante mais je l'ai aussi inclus dans mon repository git au passage nous allons également mettre la dernière version de Packer. Ces actions sont à faire sur la machine "Agent" de vsts-for-ops-1 :

apt install unzip
wget https://github.com/rgl/packer-provisioner-windows-update/releases/download/v0.4.0/packer-provisioner-windows-update-linux.tgz
wget https://releases.hashicorp.com/packer/1.1.0/packer_1.1.0_linux_amd64.zip
tar -xvf ./packer-provisioner-windows-update-linux.tgz
unzip packer_1.1.0_linux_amd64.zip
mv ./packer-provisioner-windows-update-windows /usr/local/bin/
mv ./packer /usr/local/bin/

Si vous n'avez pas installé azure cli et l'agent, vous pouvez aussi utiliser ce script sur votre vm agent:

Script

Bon et La build

Ouvrez VSTS :

puis cliquez sur "build & release" :


Puis sur "+ New"


Puis sur "Empty process"

Puis complétez le champs "Name" avec par exemple "Packer-Base-Windows 2012 R2"

Dans la Phase 1 nous allons ajouter deux étape "build immutable image" et "azure cli" :

Renseignez les variables telles que ci dessous :

Packer Template : "User Provided"

Packer template location, naviguer vers "storage/Windows/base/windows_base_packer.json"

Dans le template parameters (je suis sympa, copiez collez ca :):


{
"client_id":"$(ARM_CLIENT_ID)",
"client_secret":"$(ARM_CLIENT_SECRET)",
"resource_group_name":"$(ARM_RESOURCE_GROUP_NAME)",
"storage_account":"$(ARM_STORAGE_ACCOUNT)",
"subscription_id":"$(ARM_SUBSCRIPTION_ID)",
"object_id":"$(ARM_OBJECT_ID)",
"tenant_id":"$(ARM_TENANT_ID)",
"windows_sku":"$(WINDOWS_SKU)",
"build_resquestfor":"$(BUILD_REQUESTEDFOR)",
"location":"$(ARM_LOCATION)",
"vm_size":"$(ARM_VM_SIZE)",
"capture_name":"$(CAPTURE_NAME)"
}

Puis, dans "Output", renseigner IMAGEURI :


Ajoutez maintenant une tâche "Azure CLI" :


Sélectionnez votre souscription azure (si elle n'est pas dans la liste, cliquez sur manage et ajoutez la) et indiquez le chemin vers le script bash "script/platform/tasks/az-move-vhd.vhd" et ajoutez les arguments "-d "$(DESTACCOUNTKEY)" -s "$(SOURCEACCOUNTKEY)""


Une fois que ces deux tâches sont complétées, nous allons déclarer nos variables (si vous ne savez pas comment les récupérées, suivez le guide sur le dépôt git de Stanislas plus haut) :


Vous remarquerez que certaines sont masquées, rien de bien compliqué, cliquez sur le cadenas et elle sera "protégée" :


Dans l’idéal, les variables a protégées seraient : ARM_CLIENT_SECRET, ARM_SUBSCRIPTION_ID, ARM_TENANT_ID, DESTACCOUNTKEY, SOURCEACCOUNTKEY mais pour des questions de simplifications dans cet exercices, nous ne protégerons que les clés du compte de stockage, nous corrigerons par la suite.

Pour récupérer les clés des comptes de stockage sélectionnez votre compte de stockage dans le resource group que vous avez créer et allez dans "Access Keys" :


Ensuite, comme nous allons construire des images Packer Windows, il y a des chances pour que la build dure plus d'une heure (Mise à jour etc) donc dans les options de la build nous allons passer le time out de la build a 240 minutes :

Cliquez maintenant sur "Save & Queue".

Votre build est maintenant lancé.