I need to backup my NAS to a remote and secured location, and because I am a Azure AZ-103 associate, I have decided to use an Azure storage account. I will use Duplicati, a free backup software written in C# with the following features:
- Native AES-256 encryption.
- Wide variety of storage backends: Azure, S3, GCS, FTP, SSH, Onedrive...
- Works well on Windows, Linux, FreeBSD.
- Works on a headless server with a WebUI.
Storage account offers 3 tier with different pricing: hot, cool, archive. If you choose a hot tier, access is less charged, but storage is more expensive. This is the opposite for cool and archive, storage is cheap but access is expensive. Archive is the most interesting tier for backups but it has many constraints, such as the need to pick every object inside the container and move them to the tier. So I will use cool.
Create a Resource group and a Storage account
First you need to create a Resource group. Go to the Resource groups blade then click +Add. Take a look at Ready: Recommended naming and tagging conventions if you don't know how to name it. Select a region (does not really matters now).
Now you need to create a Storage account. Go to the Storage accounts blade then click +Add.
- Subscription: your subscription.
- Resource group: the one you just created
- Storage account name: must be unique accross Azure and as many limitations, so I recommend using a very short name + short random id.
- Location: Select the location of your choice (choose a close one with an interesting pricing, see Azure Calculator)
- Account kind: StorageV2
- Replication: LRS
- Access tier: cool
Now open you new Storage account and go to the Containers blade then click +Container. This time the name is private and does not need to be unique. Make sure the Public level access is set to Private (no anonymous access).
Go to the Access keys blade and retrieve the value of key1 or key2. These key are private and should not be shared with anyone because they basically give full access to the storage account and the data inside.
Configure Duplicati
Go into the Web UI then + Add backup > Configure a new backup.
Enter a name, a description and a very strong encryption passphrase (if you forget this passphrase, you wan't be able to decrypt your backups).
Select "Azure blob" for Storage type and set your credentials.
Click Test connection to make sure Duplicati can reach your Azure container.
Select the files you want to backup.
Schedule your backups. For me, monthly is enough.
Duplicati will not copy your files one by one but use "volumes". To select the size of each block, read this documentation. Smaller means more transactions but better de duplication. Bigger means less transactions but less optimized de duplication. If you have the bandwith, go for higher chunks. 1 Gbyte seems to be a good value for me. More is not good, takes too much resources.
You can also set a retention, for me it's 6 months.
Et voila, just run your backup now!
Pricing considerations
It is not easy to estimate monthly charges. It depends not only on used storage, but also on write and read operations. Here is how much I pay:
- Region: North Europe
- Chunks: 1 GB
- Monthly backups
- Used Storage: 488 GiB
- Monthly cost: < €5
Après 1 an à travailler sur Azure (sur des périmètres Linux ou serverless), j'ai enfin eu l'occasion de passer ma certification ! Il en existe plusieurs et cela bouge régulièrement. J'ai retenu la AZ-103 (Microsoft Azure Administrator) car accessible pour une première approche et très en rapport avec ce que je fais en ce moment.
L'examen se planifie en ligne et ne se déroule pas chez Microsoft mais dans des centres qui ont reçu l'agrément. Après avoir présenté deux pièces d'identité, vidé nos poches et mis nos affaires dans un casier sécurisé, nous nous rendons dans une pièce filmée où un client léger connecté en TSE nous permet de dérouler les questions de la certification. Dans mon cas j'ai eu :
- 62 questions (tout type compris).
- En majorité du QCM type "code de la route".
- 2 labs (accès au portail Azure avec une liste de tâches à effectuer).
- Plusieurs case study (une page qui décrit un contexte, puis du QCM).
- Temps limité de 3 h (j'ai terminé avec une marge de... 4 min !)
Le résultat est donné dès la sortie, positif pour moi car j'ai eu plus de 800 points alors que le minimum est 700.
Mes conseils pour bien se préparer à la certification AZ-103 sont les suivants:
- Faire les examens à blanc AZ-103 chez Whizlabs. Oui c'est payant (€15,95 au moment où j'écris) mais les questions proposées sont très proches (voire identiques) à celles du vrai examen, je pense que je n'aurais pas réussi sans Whizlabs. Prenez une semaine pour faire et refaire les questions.
- 12 labs AZ-103 par Microsoft (sources). Vous ne pourrez pas faire les points qui évoquent la synchronisation A.D ou demandent une subscription P2, mais c'est quand même une bonne base.
- Bien potasser l'Azure Active Directory, la synchronisation avec les A.D On Premise, la protection des identités (MFA), la migration des Data vers du Blob Storage car beaucoup de questions s'y rapportent.
- Avoir déjà provisionné des machines virtuelles, disques managés, availability sets, scalesets, VNET, peerings. Vous aurez des questions sur les SLA des VMs, et sur les niveaux de tiering des comptes de stockage.
- Avoir de bonnes bases en réseau (masques, VPN, DNS, firewall), des bases en Powershell (bien que pas indispensable).
Bonne chance si vous aussi vous visez la AZ-103 ou tout autre certification :)
J'ai une relation d'amour et de haine avec Terraform. Cet outil est formidable pour discuter avec les providers de cloud et faire de la remédiation, en revanche je me casse régulièrement les dents sur le langage hcl que je trouve extrêmement limité et frustrant. Trois exemples :
- Les variables : Toute variable doit être déclarée, typée et contenir une valeur, même si on ne s'en sert pas. Une variable ne peut pas être égale à une autre. Pas de dictionnaire.
- Pas de if, pas de loop : On doit ruser avec count mais on perd grandement en souplesse et en lisibilité.
- pas DRY: (Don't Repeat Yourself) on ne peut pas utiliser du code commun et envoyer des variables en fonction de l'environnement, donc on duplique pas mal de code. Ce problème est réglé par Terragrunt que je recommande.
C'est principalement pour ces deux raisons que je considère qu'il est très difficile voire impossible de faire du code générique sur Terraform. On ne peut pas créer un module qui gère tous les cas possibles à l'aide des variables, on devra obligatoirement imposer des choix.
Terraform 0.12 est une version qui était très attendue depuis près de 1 an car promettant de lever pas mal de limitations du hcl. Et en effet la nouvelle version du langage nous apporte des nouveautés très appréciables. Mes 3 préférées sont :
- First-class expression syntax :
${var.foo}
devient var.foo
-
${var.foo["key"]}
devient var.foo.key
${var.foo[count.index]}
devient var.foo
(mon préféré)
- Generalized type system :Les variables peuvent être des "object" composés de clés de différents types. Les objets eux-mêmes peuvent faire partie d'une liste: exemple. C'est peut-être le plus gros progrès de cette version.
- Iteration constructs : Arrivée des boucles for et des boucles dynamiques, semble en pratique plus limité que ce qu'on pourrait croire mais c'est bon à prendre. Exemple.
Terraform 0.12 couplé à Terragrunt offre une plus grande souplesse et évite de se répéter. J'ai entamé la migration de mes projets pour profiter de ces nouveautés, et j'en suis très content. Merci Terraform :)
In Azure, the Application Gateway is basically a reverse proxy, passing traffic to some backends. While testing the SSL certificate of a listener with ssllabs, I have been surprised by the "HTTP server signature" field: Nexus/2.14.10-01. Indeed, the backend was a Nexus service, but I was expecting to see the server signature of the Application Gateway (which is Nginx), or nothing, but not the backend.
Turns out the HTTP response contains the following header:
< HTTP/1.1 200 OK
< Server: Nexus/2.14.10-01
[...]
Many sysadmins and organizations consider this as a security issue, giving attackers information about the server. While I do not totally agree with this statement (Obfuscation), I often disable this information. This is simple with Nginx and Apache, but what about Azure Application Gateway?
Application Gateway -> Your application gateway -> Rewrites -> + Rewrite set
- Name: give a name to your rewrite set. Ie: DisableServerTokens.
- Associated routing rules: Select the rule associated to your backend(s)
- Rewrite rule name: give a name to your rewrite rule name. Ie: DisableServerHeader.
- Action type: Delete
- Header type: Response
- Header name: Common header
- Common header: Server
Then Save your modifications. This should remove the "Server" HTTP header.
It took me some time to figure out how to use Azure tags as a filter for Ansible. Well it's not that hard, azure_rm.py will automatically generate groups based on tags with this pattern:
- Tag: role:webserver
- Becomes group: role_webserver
Yes, that's the trick, ":" becomes "_". Let's say you want to run a playbook only on machines tagged with role:webserver, just use the following command:
$ ansible-playbook -i azure_rm.py playbook.yml --limit role_webserver