Showing posts with label IaC. Show all posts
Showing posts with label IaC. Show all posts

Friday, August 30, 2024

Azure: ARM template for resource health alerts

 Azure keeps track of the general resource health of a number of components. This information can be viewed under the resource -> Help -> Resource health. However, this information is available only in the portal. To receive alerts around resource health, this must be configured separately.

Resource health alerts belongs, in my opinion, in the category of essential monitoring. You want to know if any of your key components become unavailable or degraded. Once this is setup and running, then implementing utilization based alerts would be the natural next step. See here for example of a VPN tunnel bandwidth utilization alert.

Resource health alerts can be defined on a per component type level. This means that you don't have to have any of the components deployed or specified in advance. If you deploy a health alert for e.g. VPN gateways, then all existing and future VPN gateways will be included in the scope (this will also include ExpressRoute virtual network gateways).

The ARM template in this example (Based on this MSFT ARM template) is useful for a connectivity hub where you have components such as VPN gateways, connections, firewalls, and load balancers.

If you want to add or remove components, it is done in following section of the code:



Once the alert is deployed, it can be viewed in the portal under Monitor -> Alerts -> Alert rules, see below:



The ARM template also deploys an action group which sends the alerts as emails to the specified address in the parameters file.

The files are available on GitHub:

alert-ResourceHealthAlert-weu-001.json

alert-ResourceHealthAlert-weu-001.parameters.json


Azure: ARM template for bandwidth utilization alert for VPN gateways

 Part of having a good setup in Azure and in the Hub specifically is to have proper monitoring configured. In this article will be described a bandwidth utilization alert for VPN gateways using a static threshold as well as an action group that sends emails to a specified address.

In addition to having resource health alerts configured on relevant resources (which will let you know if resources become unavailable), it is also beneficial to know if key components are reaching or exceeding their capacity. This can be done using utilization type alerts.

The default setting if you add a tunnel bandwidth alert for a VPN gateway is dynamic thresholds. But unless you have a fairly consistent usage pattern, then we've seen that too many alerts are thrown which generates unnecessary noise (it might be a bit better if sensitivity is changed to low as opposed to the default medium setting).

Instead it makes sense to configure the alert using a static threshold. What that threshold should be depends on your specific setup. But it could be e.g. 75% or 90% of SKU capacity.

The VPN SKU capacity is specified in Gbps and the threshold is defined in bytes so you have to make that conversion. Below are some examples of how to calculate using SI / decimal system for bits and binary system for bytes (though I actually think that MSFT is using SI system for bytes as well - but it is not overly important in this context).

Examples are for a threshold of 2,5 Gbit for a 3 Gbps gateway and 0,9 Gbit for a 1 Gbps gateway:

  • 1 Gbit = 1.000.000.000 bits
  • 1 byte = 8 bits
  • 1 Gbit = (1.000.000.000 / 8) = 125.000.000 bytes

  • 2,5 Gbit = (125.000.000 * 2,5) = 312.500.000 bytes
  • 0,9 Gbit = (125.000.000 * 0,9) = 112.500.000 bytes

  • 1 Kilobyte = 2^10 bytes = 1024 bytes
  • 1 Megabyte (MB) = 2^20 bytes = 1024 * 1024 bytes = 1.048.576 bytes

  • 1 Gbit = (125.000.000 / 1.048.576) = 119,2 megabytes
  • 2,5 Gbit = (312.500.000 / 1.048.576) = 298 megabytes
  • 0,9 Gbit = (112.500.000 / 1.048.576) = 107,3 megabytes
The ARM template deploys alerts for two VPN gateways with two different thresholds. The VPN gateways must be deployed in advance (or you can adjust the template to use just one GW).

Only the parameter files needs to be updated with relevant info.

ARM template is available on Github:



The template contains an action group and it has two email addresses configured, this can be reduced to just one if needed.


Thursday, November 30, 2023

Installing tools on Windows with Chocolatey - a package manager

 Chocolatey is a useful tool to install apps and tools on a fresh laptop or developer VM via command line.

Install Chocolatey

To install Chocolatey, follow below steps:

  • Install PowerShell 7, see link
  • Open PowerShell 7 as administrator
  • Run the following command to install Chocolatey (copied from the official install instructions)
    • Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
  • Close and re-open the PowerShell 7 window, again as administrator
  • Run the following command to verify that install is succesful:
    • choco upgrade all
  • Enable long paths in PowerShell (command copied from here):
    • New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

Install apps with Chocolatey

Below are some commands for common tools:

  • choco install -y notepadplusplus
  • choco install -y git
  • choco install -y vscode
  • choco install -y 7zip
  • choco install -y kubernetes-cli
  • choco install -y kubernetes-helm
  • choco install -y azure-cli
  • choco install -y az.powershell
  • choco install -y bicep
  • choco install -y terraform
  • choco install -y firefox
You can see a list of available apps here (and search as well, there are many)

Here's instructions on initial config for Git (set user.name and user.email)

Friday, October 20, 2023

Git commands - for setup and daily work

 This article is just to collect some of the Git commands that are being used on a regular basis.

Git commands for daily work

git clone <https link to repo> (clone a remote repo. Make sure you’re in the correct directory when running)

git pull (sync the latest changes from remote repo)

git checkout -b feature/new_branch_name (create new feature branch)
git switch -c feature/new_branch_name (create new feature branch)

git checkout main (switch to main branch)
git switch main (switch to main branch)

git add -A (pre-commit/stage command to add all new/modified/deleted files to local staging for whole repo, run this before local commit)

git add . (same as -A but for current directory and sub directories only)

git add -u (stages all modified and deleted files but leaves new and untracked files)

git commit -a -m "adding a test file" (commit all files to local branch and add a message)

git push --set-upstream origin feature/testingbranch (publish local branch to remote repo, use the same name as the current feature branch)

The git push command can be simplified further, see below around the push.autoSetupRemote setting (then you can just use git push).

git add -A && git commit -a -m "adding a test file" (combine git add and git commit and run sequentially)

git checkout main && git pull (combine switch to main branch and run git pull)

git branch -d localBranchName (delete local branch)

git push origin --delete remoteBranchName (delete branch remotely)

git branch -l (list local branches)

git branch --all (see all branches including remote)

Undo last commit

If you've pushed a local repo to a remote repo and also created a PR in e.g. Azure DevOps, you can undo the last commit, make some changes or remove/add files and re-push the changes:

git reset --soft HEAD~1 (undo last commit)

git add -A (run this after changes have been made to re-stage)

git commit -a -m "updated commmit message"

git push --force (this will overwrite the remote branch history. If you don't use --force it will throw an error that remote branch is ahead)

Load everything from remote branch and overwrite local branch

git switch my-local-branch

git fetch origin

git reset --hard origin/my-remote-branch

Git commands configuring Git

git config --global user.name "First Last" (user name and email should be set up as a one time config)

git config --global user.email <user@email.com>

git config --global core.longpaths true (fixes an error with long path names)

git config --list (show git config)

git config --list --show-origin (show git config including where variables are defined)

git config --global http.https://dev.azure.com/.proxy https://someaddress (this is a proxy related setting)

git config --global http.https://dev.azure.com/.proxyauthmethod negotiate (this is a proxy related setting)

git config --global http.https://dev.azure.com/.emptyAuth true (this is a proxy related setting)

git config --global --edit (edit the global config file in VI editor)

git config --global --replace-all user.name "username" (replaces current user name)

git config --global --replace-all user.email <user@email.com>

git config --unset-all credential.helper (unset named settings)

git config --global --set credential.helper (set the credentials helper type)

Note, that if you set push.autoSetupRemote to true with the below command, it is enough to just run: git push and you don't have to specify (--set-upstream origin feature/testingbranch) and it will automatically create a remote branch with same name as current local branch and enable tracking, see more info here:   

git config --global --add --bool push.autoSetupRemote true

   


Sunday, July 10, 2022

Azure: Deploy Azure Firewall in availability zones using Bicep

 Microsoft has some great Quickstart templates for deploying resources as codes. For this post I've looked at deploying an Azure Firewall into multiple availability zones using Bicep.

The Quickstart guide used can be found here.

The template needs only a few changes. I updated the VNet name and IP address info and inserted a reference to a key vault for the VM admin password.

My updated files can be found on Github (fw-conn-weu-001.bicep and fw-conn-weu-001.parameters.json).

The firewall is deployed into three availability zones in West Europe. This increases the availability to 99.99%. There is still only one logical firewall deployed, so the increased availability is managed in the background by Microsoft. And from a Azure Portal point of view it looks the same as if only deploying to one availability zone.

The availability zones can be verified under Azure Firewall -> Properties, see below:


There is no immediate additional cost to deploying to multiple availability zones, however, there is an increased bandwidth cost, see below (or link):




The bicep file deploys the following resources:


If you are testing in a Visual Studio subscription make sure to delete resources again when done as the cost of especially the FW can run up quickly.

One network rule and one application rule are added under Firewall -> Rules (classic) -> Network/Application rule collection tabs, see below. Usually a Firewall Policy will be created and associated with the FW but for testing purposes this can be used.


Using the Bicep visualizer from VS Code you can get a nice graphical overview of the resources to be deployed. To do this, right click the bicep file in VS code and choose "Open Bicep Visualizer", see below: 







Wednesday, July 6, 2022

Azure: Load balancer with pre-allocated IPs in backend pool

 When deploying a load balancer there are two different types of backend pool configurations: NIC based and IP based, see second screenshot below. When using IP based pools, you can pre-allocate IP addresses and then when VM's are added at a later stage they can be assigned the allocated IP addresses.

If you add VMs to the backend pool manually via the portal post deployment, the default choice is NIC based. If you want to deploy the NIC based setup with the ARM templates it's a bit more tricky. Then you have to deploy a couple of vNICs and then associate them with the pool. And then when the backend VMs are deployed, you can associate them with the already deployed NICs.

Note that there are some limitations around using IP based pools and private link services. According to this article "A load balancer with IP based Backend Pool can’t function as a Private Link service".

The content in this post uses this Microsoft article as a starting point.

The ARM template can be found on Github (lb-netw-dv-weu-001.json and lb-netw-dv-weu-001.parameters.json).

The LB is internal, has a frontend IP, one backend pool with two local IPs pre-allocated, one http probe and a load balancing rule that forwards requests on port 80, see more details in screenshots below.