
I have been a user of Vercel for a long time, but recently I wanted more control over the deployment process of my blog! Which is why I decided to move everything to Azure for this, seeing that they have a [new Static Site hosting option](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website?WT.mc_id=DOP-MVP-5004263) which is simply AMAZING (and free 😉).

## Typical Blog Setup

Typically when setting up a blog, we need to take care of a couple of things:

* Storage Account (expose this to allow public access)
* CDN (for fast worldwide delivery)
* CI/CD setup (e.g. GitHub Actions)

## Azure Static Site with Bicep

Now recently a new offering was made available that bundles all of the above and automatically bundles your application and publishes your website. The only thing we have to do is provide the repository URL and how to build our website! 🤯 Now let's create our Azure setup with an Infrastructure-as-a-Code tool named [Azure Bicep](https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?WT.mc_id=DOP-MVP-5004263)

### Creating Bicep Files

The first file we have to create is our main file that contains the modules we want to deploy and some general overview. In here we use `subscription scoping` to define what has to happen at a *subscription level*

> We split up subscription level resources and resource group level resources in different files. Resource groups are created at a subscription level, while resources are created at a resource group level.

Our `main.bicep` file will thus define some parameters and their defaults and create a resource group. After creating this resource group we will tell it to initiate our `static-website.bicep` module that takes care of creating the static website setup itself.

**main.bicep**

```bicep
param environment string = 'dev'
param location string = 'westeurope'
param resourcePrefix string = 'yourresourceprefix'

// Parameters for static website
param repositoryUrl string
param repositoryToken string // the repository token to setup actions workflow and api secrets (https://github.com/settings/tokens)
param repositoryBranch string = 'master'

// This file operates at a subscription level
targetScope = 'subscription'

resource MainRG 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-${resourcePrefix}-${environment}'
  location: location
}

module ModuleStaticWebsite 'static-website.bicep' = {
  // Change deployment context to RG
  name: 'static-website'
  scope: resourceGroup(MainRG.name)
  params: {
    environment: environment
    resourcePrefix: resourcePrefix
    repositoryUrl: repositoryUrl
    repositoryBranch: repositoryBranch
    repositoryToken: repositoryToken
  }
}
```

Now our resource group is created, we define our `static-website.bicep` module. This module is quite straightforward as we just have to define the SKU, the Tier and our repository settings as well as how to build our application!

> Note: I am using a Next.js deployment, so I define that my site output will be situated in the `out` folder starting from the `/` after building through `npm run build`

**static-website.bicep**

```bicep
param environment string
param resourcePrefix string
param location string = resourceGroup().location

param repositoryBranch string
param repositoryUrl string

// the repository token to setup actions workflow and api secrets (https://github.com/settings/tokens)
// needs to have repo and workflow access
param repositoryToken string
param skuName string = 'Free'
param skuTier string = 'Free'

// https://docs.microsoft.com/en-us/azure/templates/microsoft.web/staticsites?tabs=bicep
resource staticWebApp 'Microsoft.Web/staticSites@2021-01-15' = {
  name: 'ss-${resourcePrefix}-${environment}'
  location: location
  sku: {
    name: skuName
    tier: skuTier
  }
  properties: {
    provider: 'GitHub' // required to ensure success in follow up deployments
    repositoryUrl: repositoryUrl
    repositoryToken: repositoryToken
    branch: repositoryBranch
    buildProperties: {
      outputLocation: 'out' // next.js will export to the out directory
      appLocation: '/'
      apiLocation: ''
    }
  }
}

// Outputs
output deployment_token string = listSecrets(staticWebApp.id, staticWebApp.apiVersion).properties.apiKey
```

And that's it! 😱 in just these few lines I have automated the entire infrastructure definition and can run this.

> What is even more amazing is that the Static Website implementation on Azure will add a `.github` workflow that automatically deploys our website to it!

### Deploying Bicep Template

As a last step we have to deploy all of the code we just wrote. So execute the code below to deploy this to your Azure account:

```bash
# Login to Azure
az login

# Set Subscription
az account set --subscription <your_sub_id>

# Deploy Bicep
az deployment sub create --location westeurope --template-file ./main.bicep
```

## Conclusion

In almost under 10 minutes you should have been able to:

1. Deploy new Cloud Infrastructure
2. Take code from your (private) repository
3. Build this code
4. Deploy the result on a static website
5. Automate all of it through a CI/CD pipeline

Which is now powering my personal blog! 😍

Learn how you can automated your Blog Deployment with a CI/CD pipeline with Azure Bicep in just 10 minutes!

Use Bicep and Azure Static Site for your Blog Deployment


Did you find yourself ever having to set-up your development environment all the time? Well I did as well! What if I could tell you, you could save many minutes each day by automating this? Enter the world of Windows Terminal and WSL! 😎

## Requirements

### WSL Environment

For this post we will need an initialized WSL environment. To get started feel free to follow my [previous blog post](https://xaviergeerinck.com/post/coding/python/windows-development-environment-setup) which gives you full control of where you want WSL to be installed! 

### Windows Terminal

If you don't have it yet (you should) go download [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701) or install it with `winget install Microsoft.WindowsTerminal`

## Tips and Tricks

### Automating Development Environment Startup

Windows Terminal has a lot of [CLI tricks up its sleeves](https://docs.microsoft.com/en-us/windows/terminal/command-line-arguments?tabs=windows&WT.mc_id=DT-MVP-5004263), one of these is that you can use 1 single command to open up your entire development environment. Typically, I make a shortcut with the following command in it that opens up my environment, starts processes and lets me know how I can start my other programs:

```powershell
CMD /C wt.exe --title "Services" wsl -d "Ubuntu-20.04" -- bash -c "cd ~/ && sudo service postgresql start && sudo service docker start && exec bash"; new-tab --title "Site" wsl -d "Ubuntu-20.04" -- bash -c "cd ~/frontend && sleep 3 && npm run dev"; split-pane -V wsl -d "Ubuntu-20.04" -- bash -c "cd ~/ && sleep 3 && npm run dev"; new-tab --title "Flow Engine" wsl -d "Ubuntu-20.04" -- bash -c "cd ~/backend/dotnet/API && sleep 1 && ./start.sh"; focus-tab -t 0
```

In the following sections I will dissect some of the tricks used above:

### Starting a Service

When WSL boots, not all your services are started automatically. You want to do this but not always adapt the `~/.bashrc` file, so add yourself to sudoers first so you don't have to enter a password all the time and then execute the line below on Windows.

```powershell
# on WSL
echo "$USER ALL=(ALL:ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/$USER

# on Windows
CMD /C wt.exe --title "Services" wsl -d "Ubuntu-20.04" -- bash -c "cd ~/ && sudo service postgresql start && sudo service docker start && exec bash";
```

### Starting a Program

Besides starting a service you also might want to start your program automatically after navigating to a specific directory. The trick here is to **make bash interactive** by appending `-i`

```powershell
CMD /C wt.exe --title "Services" wsl -d "Ubuntu-20.04" -- bash -i -c "cd ~/ && sudo service postgresql start && sudo service docker start && exec bash";
```

### Printing to Console

You can print to console by just using echo, just don't forget to open an interactive shell afterwards so it doesn't closes.

```powershell
CMD /C wt.exe --title "Demo" wsl -d "Ubuntu-20.04" -- bash -c "cd ~/ && echo 'hello world' && exec bash"
```

### Open interactive Bash

Sometimes you want to have an interactive bash screen and not just your program running. For this just append `exec bash` behind it:

```powershell
CMD /C wt.exe --title "Demo" wsl -d "Ubuntu-20.04" -- bash -c "cd ~/ && exec bash";
```

Elevate your developer experience with Windows Terminal and WSL

Windows Terminal and WSL Tips and Tricks


So you are working on a production scale and suddenly notice that you don't have to provision just 1, not 10 but 1000s of devices. What do you do?

This is where you start automating stuff, rather than doing everything manually, you ideally:

1. Create an image
2. Flash an SD Card
3. Install the SD Card
4. Boot-up the device

Applying this to Azure IoT Edge, I will walk you through how you can create your own Azure IoT Edge image for your devices. This way we can follow a previous blog post to [automatically register our devices on boot with IoT Hub !](/posts/iot/iot-dps)

## Packer Installation

To do so, we will be utilizing a tool named [Packer](https://www.packer.io/). Packer is a tool created by Hashicorp to create "Golden Images" for a target platform through **Builders**. These *builders* are responsible for generating an image for that target platform. (e.g. we create an Image and save it to Azure, we create an Image to run on Hyper-V, ...)

* [VirtualBox](https://www.packer.io/docs/builders/virtualbox)
* [Hyper-V](https://www.packer.io/docs/builders/hyperv)
* [Azure](https://www.packer.io/docs/builders/azure)
* [AWS](https://www.packer.io/docs/builders/amazon)
* [GCP](https://www.packer.io/docs/builders/googlecompute)
* [ARM](https://github.com/mkaczanowski/packer-builder-arm)
* ...

## Installing Packer with ARM support

In our case, we want to utilize Packer to create an image that can run on our target devices which are ARM based. Packer didn't have this option natively, but provided a [community supported module that can do just this](https://github.com/mkaczanowski/packer-builder-arm).

### Packer

Let's get started on creating our own image by installing Packer itself.

```bash
# Install Go (required for Packer)
# See: https://github.com/canha/golang-tools-install-script
wget -q -O - https://git.io/vQhTU | bash

# Install dependencies
sudo apt install -y git unzip qemu qemu-user-static e2fsprogs dosfstools

# Install Packer
# see version at: https://www.packer.io/downloads
PACKER_VERSION=1.7.4
wget "https://releases.hashicorp.com/packer/${PACKER_VERSION}/packer_${PACKER_VERSION}_linux_amd64.zip"
unzip packer_${PACKER_VERSION}_linux_amd64.zip 
sudo mv packer /usr/local/bin/
```

### ARM for Packer

Since ARM is not natively installed, we will have to install a plugin for this. 

```bash
# Download the Packer ARM Builder
git clone https://github.com/mkaczanowski/packer-builder-arm

# Build it
cd packer-builder-arm
go mod download
go build

# Install to /usr/local/bin (packer will discover plugins with prefix packer-*)
sudo mv packer-builder-arm /usr/local/bin
```

## Configuring

Once packer is installed and the ARM plugin was added we can get started on creating our own custom image. Let's recap on how our image should look like:

1. **Use a Jetson Nano with Ubuntu:** We want to utilize a base Ubuntu image as our source compiled for a Jetson nano.
2. **Add a custom script for IoT Edge with DPS configuration:** We utilize DPS to set-up our device, this script will take in the ScopeID and Primary Key of a Group Enrollment and automatically provision our Device in IoT Hub.
3. **Basic System Configuration:** We want to configure time settings, ssh access, admin users, cleanup, ... so we add that as well.

Create a folder structure that looks like the below:

```bash                  
.
├── jetson-azure-iot-edge.json    # Packer Configuration Details
├── scripts
│   ├── 00-clean-nvidia-jetson.sh # Cleanup Nvidia Jetson base image (remove GUI)
│   ├── 01-configure-system.sh    # Configure the system (hostname, DNS, upgrading)
│   ├── 02-configure-ssh.sh       # Allow SSH Access
│   ├── 03-configure-chrony.sh    # Time Synchronisation
│   ├── 04-create-admin-user.sh   # Admin Login
│   └── 05-install-iot-edge.sh    # IoT Edge Configuration on Boot
```

The main `jetson-azure-iot-edge.json` file will contain the configuration for how Packer should build our image. Here we will detail that:

* Variables for our scripts
* It should use the Nvidia Jetson Nano SD Card Image
* Copy our scripts to `/tmp/packer/scripts`
* Execute the different scripts with the variables passed as environment variables at build.

> For the full source code, feel free to check my [Public Repository](https://github.com/XavierGeerinck/PublicProjects/tree/master/Azure-IoT-Edge/PackerImage/NvidiaJetsonNano)

Our Packer JSON Image (`jetson-azure-iot-edge.json`) will then look like:

**jetson-azure-iot-edge.json:**

```javascript
{
    "variables": {
        "dps_group_enrollment_key": "NOT_SET_PASS_BY_CLI",
        "dps_scope_id": "NOT_SET_PASS_BY_CLI",
        "admin_create": "true",
        "admin_user": "admin",
        "admin_group": "admin",
        "admin_passwd": "admin",
        "admin_uid": "1000",
        "admin_gid": "1000",
        "admin_groups": "cdrom,floppy,sudo,audio,dip,video,plugdev,netdev,systemd-journal",
        "admin_shell": "/bin/bash",
        "admin_gecos": "Administrator",
        "admin_ssh_authorised_key": ""
    },
    "builders": [
        {
            "type": "arm", // The builder type
            "file_urls": [ // Our base image URL
                "https://developer.nvidia.com/jetson-nano-sd-card-image-r3221"
            ],
            "file_checksum": "7b87e26d59c560ca18692a1ba282d842", // Our base image checksum
            "file_checksum_type": "md5", // Our base image checksum type
            "file_target_extension": "zip", // The extension/compression of the image
            "image_build_method": "reuse", // Reuse disk image or create from scratch?
            "image_path": "jetson-nano.img", // Where to unpack to
            "image_size": "12G", // The size of the image
            "image_type": "dos", // Partition Table Scheme
            "image_partitions": [ // Specifications of the partitions of the image
                {
                    "name": "root",
                    "type": "83",
                    "start_sector": "24576",
                    "filesystem": "ext4",
                    "size": "12G",
                    "mountpoint": "/"
                }
            ],
            "image_chroot_env": [ // The shell environment that is passed to chroot
                "PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin"
            ],
            "qemu_binary_source_path": "/usr/bin/qemu-aarch64-static", // Where is qemu situated?
            "qemu_binary_destination_path": "/usr/bin/qemu-aarch64-static" // Where will copy it to?
        }
    ],
    "provisioners": [
        {
            "type": "shell",
            "inline": [
                "mkdir -p /tmp/packer/scripts"
            ]
        },
        {
            "type": "file",
            "source": "./scripts",
            "destination": "/tmp/packer/"
        },
        {
            "type": "shell",
            "remote_folder": "/tmp/packer",
            "skip_clean": true,
            "environment_vars": [
                "ADMIN_CREATE={{user `admin_create`}}",
                "ADMIN_GECOS={{user `admin_gecos`}}",
                "ADMIN_GID={{user `admin_gid`}}",
                "ADMIN_GROUP={{user `admin_group`}}",
                "ADMIN_GROUPS={{user `admin_groups`}}",
                "ADMIN_PASSWD={{user `admin_passwd`}}",
                "ADMIN_SHELL={{user `admin_shell`}}",
                "ADMIN_SSH_AUTHORISED_KEY={{user `admin_ssh_authorised_key`}}",
                "ADMIN_UID={{user `admin_uid`}}",
                "ADMIN_USER={{user `admin_user`}}",
                "DPS_GROUP_ENROLLMENT_KEY={{user `dps_group_enrollment_key`}}",
                "DPS_SCOPE_ID={{user `dps_scope_id`}}"
            ],
            "scripts": [
                "./scripts/00-clean-nvidia-jetson.sh",
                "./scripts/01-configure-system.sh",
                "./scripts/02-configure-ssh.sh",
                "./scripts/03-configure-chrony.sh",
                "./scripts/04-create-admin-user.sh",
                "./scripts/05-install-iot-edge.sh"
            ]
        }
    ],
    "post-processors": []
}
```

## Building

Finally, to build our image it is as simple as running the command below. Which sets the variables as defined in the variables section, more specifically variables `dps_scope_id` and `dps_group_enrollment_key`.

We can adapt the other variables as well the same way by passing them in the CLI. Otherwise, Packer will use their default values.

```bash
sudo packer build -var 'dps_scope_id=<YOUR_DPS_SCOPE_ID>' -var 'dps_group_enrollment_key=<YOUR_DPS_GROUP_KEY>' jetson-nano.json 
```

This should take around 12 minutes (mainly due to removal of packages and upgrading the system), but once that is finishes you will have a `jetson-nano.img` image created that can be flashed to an SD Card!

## Conclusion

After following this article, you should be left with an Image that can be installed on an SD Card. Which, when booted completely configures a brand new device and registers it with the IoT Device Provisioning Service (DPS). All without us having to log in on the device, configure network, install DPS, configure DPS, configure hostname, ... 

If we would have to do the above on 1000s of devices, this would save us ~10min per device (the build time) thus saving ~10.000 minutes!

## Troubleshooting

When working with complex software as the above (more specifically `qemu` virtualization), errors are bound to happen. In my case I receive the following errors sometimes:

* **==> arm: Failed to find binfmt_misc for /usr/bin/qemu-aarch64-static under /proc/sys/fs/binfmt_misc**
  * To resolve this I had to reinstall the `qemu-user-static` environment with `sudo apt install --reinstall qemu-user-static` more information can be found in the [WSL Interop Issue](https://github.com/microsoft/WSL/issues/2103)

## References

I always love to include some of the references I checked that were precious in me writing this. Below you can find the ones I used for this blog post.

* [https://linuxhit.com/build-a-raspberry-pi-image-packer-packer-builder-arm/](https://linuxhit.com/build-a-raspberry-pi-image-packer-packer-builder-arm/)
* [https://www.thegeekdiary.com/how-to-create-virtual-block-device-loop-device-filesystem-in-linux/](https://www.thegeekdiary.com/how-to-create-virtual-block-device-loop-device-filesystem-in-linux/)

Learn how you can create your own OS Golden Image to setup your IoT Edge Devices and get them provisioned automatically!

Creating an Azure IoT Edge Golden Image


Once you get further in the world of the Internet of Things (IoT) you will notice that you have to setup devices in bulk rather than device-per-device. This is where Azure helps you through a service named **Device Provisioning Service**.

## Requirements

* Azure IoT Hub (Standard Tier or higher)
* A device with Ubuntu installed

## The Device Provisioning Process

Before we get started with creating and configuring DPS, let's go through the basics of how Device Provisioning works.

> Device Provisioning is the process of getting a device ready for hand-off to an end-user (i.e. the device is ready for bootup and usage)

In the case of provisioning a device with DPS we have 2 main steps:

1. The creation of the device with a bare OS
2. The configuration of the OS to connect to cloud 

While step 1 is trivial, step 2 is considerably more complex as a lot of security aspects have to be taken into account. The diagram below explains [how Step 2 is handled through DPS](https://docs.microsoft.com/en-us/azure/iot-dps/about-iot-dps?WT.mc_id=DT-MVP-5004263):

![](https://docs.microsoft.com/en-us/azure/iot-dps/media/about-iot-dps/dps-provisioning-flow.png)

1. Device manufacturer adds the device registration information to the enrollment list in the Azure portal.
2. Device contacts the DPS endpoint set at the factory. The device passes the identifying information to DPS to prove its identity.
3. DPS validates the identity of the device by validating the registration ID and key against the enrollment list entry using either a nonce challenge (Trusted Platform Module) or standard X.509 verification (X.509).
4. DPS registers the device with an IoT hub and populates the device's desired twin state.
5. The IoT hub returns device ID information to DPS.
6. DPS returns the IoT hub connection information to the device. The device can now start sending data directly to the IoT hub.
7. The device connects to IoT hub.
8. The device gets the desired state from its device twin in IoT hub.

## Creating and Configuring DPS

### Creating DPS and Linking IoT Hub

Now we know how device provisioning works, let's create and configure our DPS.

To get started we need to create and configure the Device Provisioning Service (DPS). To do this, open up the Azure Portal, search for "Device Provisioning Service" and create one.

![](./dps-create-1.png)

Once the Device Provisioning Service has been created, we need to **link our IoT Hub** to it. So open it up and navigate to "Linked IoT Hubs" and add the created IoT Hub from the requirements.

![](./dps-create-2.png)

### Creating a Device Enrollment

We now have an IoT Hub linked to the DPS and are able to get started on **creating an *Enrollment* for our device.** Open up the Azure Portal under DPS and navigate towards "Manage Enrollments"

![](./dps-configure-1.png)

Here we can pick Individual Enrollment or Group Enrollment:
* **Individual Enrollment:** This is for a single device
* **Group Enrollment:** This is for a group of devices sharing a common attestation (i.e. how will the devices confirm their identity)

Personally I find it more interesting to cover **Group Enrollments** as this is what we would typically see in production environments. So let's continue with this one.

Head over to **Add Enrollment Group** and select the configuration you want to use. Here I used the configuration to pick an *Edge Device*, *Symmetric Keys* and give it a specific *Name*.

![](./dps-configure-2.png)

⚠️ Finally, don't click save yet, but **configure the *Initial Device Twin State*** to contain a tag. In our case I picked: `"deviceType": "nvidia-cluster"`

> We will utilize this tag later to let IoT Hub know which modules should be provisioned to which set of devices. DPS will help us connect the device to the correct IoT Hub with the correct initial state, but IoT Hub will add our modules.

![](./dps-configure-3.png)

## Configuring our IoT Edge Modules to be Deployed

Ok, so let's recap. We now have:

1. Created a DPS 
2. Configured it to link to our IoT Hub
3. Created an enrollment for a group of devices based on an attestation
4. Configured it so the devices provisioned get a specific Twin State with them

If we would connect a device now, we will see that it will get provisioned with the tag we provided earlier (`"deviceType": "nvidia-cluster"`). Now we have to use this tag to let IoT Hub know which modules should get deployed on this set of devices.

Open up your IoT Hub and go towards **IoT Edge** and click **Add Deployment** in the IoT Edge Deployments tab.

![](./iothub-deployment-1.png)

For the initial name, feel free to pick something unique for yourself.

![](./iothub-deployment-create-1.png)

The next step is the first of the 2 most important steps. Here we will define which modules should get deploy. So open up the "Add" pane and add an "IoT Edge Module"

> Note: here you can also configure Azure Container Registry credentials if you need those.

![](./iothub-deployment-create-2.png)

In our case we want a simple simulation, so add the public Simulation device from the Docker Hub

* **Image URI:** `mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0`

![](./iothub-deployment-create-3.png)

Afterwards, we specify the routes (send everything upstream)

![](./iothub-deployment-create-4.png)

Now the second most important part comes: **specifying the target devices**. Here we specify which devices should get these modules. In our case we will thus configure `tags.deviceType = 'nvidia-cluster'` as we defined before (remember where we put the initial twin state to have `"tags": { "deviceType": "nvidia-cluster" }`)

![](./iothub-deployment-create-5.png)

Finally, validate the deployment and you will get redirect back to your IoT Hub and see your deployment standing (but with 0 devices for now!)

![](./iothub-deployment-create-6.png)
![](./iothub-deployment-create-7.png)

## Configuring our Devices

As a last step, we need to configure our devices to know where they should connect to and fetch their information. We could do this manually for each device, but for production workloads this is a long cumbersome task. Therefore, we will utilize the [iot-edge-config](https://github.com/Azure/iot-edge-config?WT.mc_id=DT-MVP-5004263) tool that will make our lives so much easier!

> Note: since we are using a group enrollment key, we have to [derive a new key from it](https://docs.microsoft.com/en-us/azure/iot-edge/how-to-auto-provision-symmetric-keys?view=iotedge-2020-11&tabs=linux&WT.mc_id=DT-MVP-5004263#derive-a-key-on-linux)

Open up your device and run the following commands:

```bash
# DPS Enrollment Group Key
DPS_GROUP_ENROLLMENT_KEY=<YOUR_GROUP_ENROLLMENT_KEY>
DPS_SCOPE_ID=<YOUR_DPS_SCOPE_ID>

# Get the MAC Address
MAC_ADDR=$(ifconfig eth0 | grep -o -E '([[:xdigit:]]{1,2}:){5}[[:xdigit:]]{1,2}' | sed -En "s/:/-/gp")

# Specify the Registration ID
# Note: in our case we utilize the Mac Address
REG_ID=$MAC_ADDR

# Compute a Derived key
keybytes=$(echo $DPS_GROUP_ENROLLMENT_KEY | base64 --decode | xxd -p -u -c 1000)
DERIVED_KEY=$(echo -n $REG_ID | openssl sha256 -mac HMAC -macopt hexkey:$keybytes -binary | base64)

# Configure
wget https://github.com/Azure/iot-edge-config/releases/latest/download/azure-iot-edge-installer.sh -O azure-iot-edge-installer.sh 
chmod +x azure-iot-edge-installer.sh 
sudo -H ./azure-iot-edge-installer.sh -s $DPS_SCOPE_ID -r $MAC_ADDR -k $DERIVED_KEY
rm -rf azure-iot-edge-installer.sh
```

![](./device-install-2.png)

We can now check the status by running `sudo iotedge system logs` which should not show any errors. If we then open our DPS and go to Enrollment Group Details -> Registration Records we can see our device being registered.

![](./device-install-3.png)

Finally, open up IoT Hub and go to IoT Edge devices. There you will now see your device automatically being provisioned! After a couple of minutes, the modules should as well be available on it.

![](./device-install-4.png)

Seeing that we configured a simulated sensor to be deployed, we can open up our VSCode, go to the IoT Hub Extension and listen for incoming messages to view our messages.

> Note: The simulated sensor module sends 1 message every 5 seconds and automatically stops after 500 to preserve your quota. It could be that you have to restart the container if it stops.

![](./iothub-view-messages-1.png)

![](./iothub-view-messages-2.png)

![](./iothub-view-messages-3.png)


Learn how you can automatically provision your IoT Device using Azure Device Provisioning Service (DPS)

Automatically Provision an IoT Device with DPS

Troubleshoot your Azure IoT Edge solution with the useful commands and locations!

Azure IoT Edge Troubleshooting


Autonomous Platforms are being deployed all around us, optimizing our daily processes and improving their efficiency and stability without the need of human intelligence. They learn by themself, iteratively improving themselves and staying ahead of the competition.

One of the biggest hurdles for Autonomous Platforms to be deployed is the access to a simulation environment that can be configured to the real-world use case and scaled to millions of instances to train on. Achieving 100s of iterations per second in training.

This is where the [Azure Project Bonsai platform](https://www.microsoft.com/en-us/ai/autonomous-systems-project-bonsai) comes into the picture, helping customers to teach their machines to achieve super-human optimization.

Through the following articles, I introduce you to how you can get started yourself with this amazing topic:

* [1. Platform Introduction & Overview](/post/ai/rl/bonsai/introduction) (+ [update!](/post/ai/rl/bonsai/introduction-revisiting))
* [2. Create and integrate your first "Brain" - CartPole Problem](/post/ai/rl/bonsai/brain-integration)
* 3 Create your own Simulation Environment from scratch - Self-Balancing Cube Problem [Coming Soon]
* 4 3D Model and Teach your own Robot to Walk - Custom Robotics Project [Coming Soon]

Learn how you can create an autonomous system through Machine Teaching with the Azure Project Bonsai platform.

Machine Teaching through Azure Project Bonsai - Series Overview

In a [previous article](/posts/infrastructure/azure-arc) I went in detail on how you can get started running your own Azure Arc setup and connect your cross-cloud and on-premises systems and Kubernetes clusters. In this article I would like to go in more detail how you are now able to utilize the previously created infrastructure and run Azure App Service on it! Bringing the ecosystem of Azure towards your multi-cloud environment.

## Overview

I'd love to explain the above through a graphic as illustrated below. Here you have several components:
* Multi-Cloud / Hybrid Cloud environment (illustrated as "Hosting" below)
* Azure Application Services with Azure Arc (the top block)

Making it clear that Arc is there to enable us to run Azure Application Services across our cloud environments, no matter the infrastructure layer beneath it. 

![](./arc-overview.png)

## Hands-On

After the above, let's actually do this ourselves! To deploy an Azure Service we need to have an Azure Arc enabled cluster or server available and execte the following steps:

1. Enable an Extension (e.g. App Service)
2. Create a Custom Location (our own "cloud" location!)
3. Create an App Service

### Enable an Extension (App Service)

First we start by enabling an extension on the target cluster. For this we open up the cluster in Azure Arc, navigate to "Extensions" and find the extension we want to install. In our case we will install the App Service extension.

![](./azure-arc-cluster-extensions.png)
![](./azure-arc-cluster-extensions-add-1.png)
![](./azure-arc-cluster-extensions-add-2.png)

Now we get to the details pane, where a public IP is required. This is the static IP created when you create the Kubernetes Cluster, to find this in GCP we can simply navigate to our GKE instance and locate the public IP endpoint.

![](./azure-arc-cluster-extensions-add-5-enter-details.png)
![](./azure-arc-cluster-extensions-add-3-gcp-public-ip-finding.png)
![](./azure-arc-cluster-extensions-add-4-gcp-public-ip-finding.png)

All details are now entered and a script will be generated for us. Execute this by copying this to a PowerShell instance of your choice that has access to the cluster and AZ CLI.

![](./azure-arc-cluster-extensions-add-6-run-script.png)
![](./azure-arc-cluster-extensions-add-7-copy-script-to-az-shell.png)

### Create a Custom Location

Since the Extension is now enabled, we are able to create a custom location. Navigate to Azure Arc "Custom Locations" and click the "Add" button.

![](./azure-arc-custom-location-overview.png)

This will open up the interface to add a custom location. Just navigate through this, selecting the settings you require.

![](./azure-arc-custom-location-create.png)
![](./azure-arc-custom-location-create-2.png)
![](./azure-arc-custom-location-create-3-created.png)

Once this has been created, we can verify that it has been created by navigating to a `kubectl` shell and checking the deployed pods. We will see a new namespace being created containing the resources.

![](./azure-arc-custom-location-create-4-created-gcp-overview.png)

### App Service Creation

We are almost there! So far we created a App Service enabled Kubernetes cluster on GCP and added the GCP Kubernetes cluster as a target location for Azure App Service instances. Finally we need to deploy App Service on it! 

Open Azure Arc and navigate towards "App Service" on the left, creating it in the previously created custom location with the default image.

![](./azure-arc-appsvc-1.png)
![](./azure-arc-appsvc-2.png)
![](./azure-arc-appsvc-3.png)
![](./azure-arc-appsvc-4.png)
![](./azure-arc-appsvc-5-deployed.png)

**Congratulations**, App Service is now up and running on your own instance! To verify it, open up the GKE console again and verify that an extra pod is running.

![](./azure-arc-appsvc-6-gcp-confirm.png)



## Conclusion

As shown in this article, it is trivial to deploy your own Azure Services across your existing hardware! This opens up a lot of scenarios where customers can connect their existing infrastructure running across multiple clouds and easily managing it from an easy to understand portal! Personally, I am a big fan of this solution and cannot wait for it to expand and improve more. Some of my personal learnings:

* Some errors exist and might be difficult to work with (e.g. I had a stamp issue as well as a Storage Class not existing, requiring some manual intervention - which can be automated). Tickets are being raised and the service is maturing more and more (it is still in preview!)
* I would love to see more automation happening. Currently a lot of the commands have to be ran manually, but it is prone to making mistakes.

In any case, if you have existing infrastructure and want a good control plane, Azure Arc is definitely a promising service to check out!

Learn how you can deploy Azure App Service across your Multi-Cloud environment on GCP through the Azure Arc control plane

Run Azure App Service on GCP through Azure Arc


Azure Arc was released a while ago, but got a great update in May 2021 during the [annual Build conference](https://azure.microsoft.com/en-gb/blog/build-cloudnative-applications-that-run-anywhere/?WT.mc_id=DT-MVP-5004263) allowing it to run Azure Application services across your Azure Arc enabled Kubernetes services.

## Introduction

In this article, I will explain how you can get started with Azure Arc. As **Prerequisites** I created the following on each cloud provider and on-premise infrastructure.

* Azure
    * Server
    * Kubernetes (AKS)
* Google GCP
    * Server
    * Kubernetes (GKE)
* On-Premises (VMWare)
    * Server
    * 3-Server Nodes combined to Kubernetes through K3S ([see this article on how you can set this up](/post/infrastructure/nvidia-jetson-k3s))

## Azure Arc

To summarize Azure Arc in my own words: "it's a management plane for your Kubernetes Clusters and Phyiscal servers that allows you to manage your machines no matter where they sit".

In Azure terms: "Azure Arc offers simplified management, faster app development, and consistent Azure services. Easily organize, govern, and secure Windows, Linux, SQL Server and Kubernetes clusters across data centers, the edge, and multicloud environments right from Azure."

Personally, I find this an amazing tool with a low cost to manage your entire datacenter and cloud estate! 

## Creating an Azure Arc connected Cloud

So let's get started and create our clusters and servers! Each cloud has their own specificalities, but I would love to show you how you can create them on each one of them. The overall process is quite similar:

* **Server**
    * Login an configure the Azure Arc agent

* **Kubernetes**
    * Fetch the kubectl access
    * Configure Azure Arc with `az cli`

### Azure Arc Connect Server

To connect a server, we navigate to Azure Arc in the Azure Portal 

![](./azure-arc-get-started.png)

In there we can click on Servers which will open up the overview of our servers. On the Left top we can now click "add" to add a server.

![](./azure-arc-servers-overview.png)

Seeing that the process is quite similar, I won't go into detail of how you should do this for the different cloud providers. To connect your server, open op the "Add" page and navigate through the steps while selecting your resource group operating system.

![](./azure-arc-servers-connect-3.png)
![](./azure-arc-servers-connect.png)
![](./azure-arc-servers-connect-4.png)

Once you have done that you need to install the agent. In our case I was running Linux as an operating system. At this step we will now see the commands we should run to get Arc up and running

> 💡 Do not forget to switch to root with `sudo su`

![](./azure-arc-servers-connect-5-install-agent.png)
![](./azure-arc-servers-connect-6-install-agent-final.png)
![](./azure-arc-servers-connect-7-configure-agent-complete.png)

Congratulations 🎉 you have now connected your server to Azure Arc!

### Azure Arc Connect Kubernetes

We already have single servers configured, but how can we configure our Kubernetes clusters? Well this is a bit more tricky. For this we can follow these steps:

1. Install Kubernetes (managed with AKS or GKE or through k3s for example)
2. Install & Configure Kubectl
3. Install Helm
4. Run AZ CLI

> 💡 You can make things easier (as I did) by utilizing the Azure Cloud Shell and configure `kubectl` in it. If you are working with GKE, just copy the `~/.kube/config` file content from GKE to Azure Cloud Shell and you can run `kubectl get pods -A` in your Azure Cloud Shell to connect to your GKE Kubernetes 😉

Showing this example on GKE (as Azure is straightforward with the shell), let's open up the Kubernetes pane and click "Add" again. We will now have to enter the subscription again, plus a cluster name (metadata) to name it.

![](./azure-arc-k8s-connect.png)
![](./azure-arc-k8s-connect-gcp-1.png)

Now we will be presented by the commands we need to execute to connect this Kubernetes cluster. Again, **remember to have kubectl configured** to connect to your cluster, then everything should be going smoothly!

![](./azure-arc-k8s-connect-gcp-2.png)

As explained before, I opened up the Kubectl configuration and copied the GKE config towards the Azure Cloud Shell one (to skip installation of AZ CLI on GCP):

![](./azure-arc-k8s-connect-gcp-3.png)
![](./azure-arc-k8s-connect-gcp-4.png)

Once this has been pasted I verify to ensure `kubectl get pods -A` is working and showing my GKE pods.

![](./azure-arc-k8s-connect-gcp-5.png)

Since that has been verified, I am now able to run the required commands and get cluster configured to Azure Arc.

![](./azure-arc-k8s-connect-gcp-6.png)
![](./azure-arc-k8s-connect-gcp-8.png)

We are now connected to Azure Arc, but let's for fun check on GKE to see our pods running (including the Azure Arc pods) in the Google Cloud Shell:

![](./azure-arc-k8s-connect-gcp-7-verify.png)


## Final Overview

Looking at our final overview, this is what we have created, a beautiful server park consisting out of our Kubernetes clusters and Servers!

![](./azure-arc-final-overview-servers.png)

![](./azure-arc-final-overview-k8s.png)

## Conclusion

In this article I went in more details on how you can get started with Azure Arc and connect your existing Servers and Kubernetes clusters, no matter where they are running! 

Learn how you can manage your own Multi-cloud environment with Azure Arc and set it up across Azure, Google GCP and On-Premise

Create a Multi-Cloud Infrastructure with Azure Arc


I recently acquired an Nvidia Jetson Nano 2GB Developer Kit and had some fun with it! In this series I present the overview of the articles I created:

* [Setting up an Nvidia Jetson Nano Node](/post/infrastructure/nvidia-jetson-setup)
* [Creating your own Nvidia Jetson Cluster](/post/infrastructure/nvidia-jetson-cluster)
* [Deploying Kubernetes on your Nvidia Jetson Nano Cluster](/post/infrastructure/nvidia-jetson-k3s)
* [Adding Dapr and Grafana to the Nvidia Jetson Nano Kubernetes Cluster](/post/infrastructure/nvidia-jetson-k3s-dapr-and-grafana)


Learn how to configure the Jetson Nano, Deploy a Kubernetes server and finally monitor it with Grafana

Xavier Geerinck

Did you enjoy reading? Or do you want to stay up-to-date of new Articles?