Environments & Standards

Environments

There are only a few environments in play:

  1. GitHub for source control
  2. Personal Azure tenant for hosting this site and various completing learning paths
  3. An O365 Developer tenant for all things Intune/Entra/O365
  4. The homelab

Standards

There are general guidelines I try to follow while digging in and exploring things.

  1. Document everything.
    • The red-headed step child that everyone knows they should pay attention to but always seems to leave out.
  2. Technology should work for us - not against us. If the tool doesn’t work, stop using it.
  3. K.I.S.S.
  4. Be flexible. If things aren’t working as expected, look for other ways to accomplish the goal.
  5. Secure by default
    • “It’s not prod so we don’t need to do X,Y,Z.” is too common. If our error logs need to be sanitized then our lab and dev environments need to be just as secure as production.
      • Practice doesn’t make perfect - perfect practice makes perfect.

Azure

Azure is hosting the static web app for alitrum.com and will host additional items in around Bicep deployments and AZ-104 exercises.

Azure Naming Conventions

This may deviate from typical deployments, but I’ve always preferred to have what the resource is ahead of additional information in naming conventions. For example, rg-hugo-westus2 feels much more natural when creating and deploying resources. This does go against some of the automated/default conventions when creating resources in Azure so there will be instances where this convention is broken.

  • rg- The resource group…
  • hugo- for hugo assets…
  • in the West US 2 region

The region appears redundant when you’re going in via the Azure portal, however, I personally find that when deploying via CLI, scripts, etc. having the region is a great sanity check.

app-alitrum-staging and app-alitrum-prod are examples of items where the region is a non-item and I’m more concerned about having the status up front and center.

Tags

Key:Value pairs that will exist on every resource created - period. These are invaluable when stepping into an environment and sorting out what’s what. Even if they’re not maintained and up-to-date, at least knowing what the intended purpose of something was when it was deployed is ridiculously useful.

Key Acceptable Values
Environment Production, Staging, Test
Project as appropriate

Homelab

Even calling it a lab environment is a bit of a stretch.

  1. Flat network (no VLANs)
  2. OpenVPN for remote client access
  3. Firewall with a static public IP
  4. A single cobbled together “server” hosting the Grocy, Jelleyfin, Wazuh, PRTG, and Caddy.
  5. A workstation with Hyper-V enabled for additional on-demand VMs (Intune testing)

Network

There are not currently any details on the network specifics, however, I like diagrams and this is the perfect excuse to make one.

Homelab overview Homelab overview