Category: Unknown Code Ramblings

Azure Arc: Unified Management for Hybrid and Multi-Cloud Environments

I’ve been deep in the trenches of multi-cloud tooling for years now, exploring everything from Kubernetes to Terraform, and all the glue that holds modern infrastructures together. Recently, I took a deep dive into Azure Arc, Microsoft’s hybrid and multi-cloud management solution, to see what it brings to the table. What follows is a breakdown of Azure Arc, framed through the lens of someone who’s seen the evolution of these tools over time.

The Core Idea Behind Azure Arc

At its core, Azure Arc is Microsoft’s answer to the complexities of hybrid and multi-cloud management. The idea is simple yet powerful: provide a unified management experience for resources, regardless of where they live. Whether you’re running workloads on-premises, across different cloud providers, or out on the edge, Azure Arc aims to bring them all under a single, cohesive management umbrella.

What Azure Arc Really Does

Azure Arc extends Azure’s management capabilities beyond its own boundaries. Think of it as a bridge that connects your existing infrastructure to Azure’s powerful tools and services. Once your resources are “Arc-enabled,” you can manage them just like you would any native Azure resource. This means applying policies, leveraging Azure’s security features, and using monitoring tools – all from within the Azure portal.

The beauty of Azure Arc is that it doesn’t discriminate based on where your resources are. Whether it’s a Linux server running in your own datacenter, a Kubernetes cluster on Google Cloud, or even a SQL database on AWS, Azure Arc brings it all together. This isn’t just about management, though. Azure Arc also allows you to deploy Azure services, like SQL and PostgreSQL Hyperscale, directly into your non-Azure environments.

Azure Arc for Kubernetes

Azure Arc’s support for Kubernetes is where things get particularly interesting. If you’re managing Kubernetes clusters across different environments—whether it’s AKS, EKS on AWS, GKE on Google Cloud, or even an on-premises setup—Azure Arc brings these disparate clusters into the fold under Azure’s management.

With Azure Arc, you can attach your Kubernetes clusters to Azure, enabling you to deploy applications consistently across all your clusters using GitOps, apply consistent security and governance policies, and even monitor and manage them from the Azure portal. This is incredibly powerful in multi-cloud environments where you might have clusters spread across different platforms but need a unified approach to management and operations.

The integration with AKS is seamless, of course, but the real power lies in Azure Arc’s ability to connect with other cloud providers’ Kubernetes offerings. Whether you’re dealing with AWS’s EKS, GCP’s GKE, or a custom Kubernetes setup, Azure Arc enables a level of control and consistency that can be a game-changer in complex, hybrid environments.

Defining Azure Arc

Azure Arc is, in essence, a set of technologies that extend Azure’s control plane to wherever your resources reside. Here’s what it means in practice:

  • Unified Server Management: You can connect and manage your Windows and Linux servers across on-premises, edge, and multi-cloud environments from a single pane of glass within Azure.
  • Kubernetes Cluster Integration: Azure Arc allows you to attach and manage Kubernetes clusters from anywhere. This means consistent management, monitoring, and governance across your entire Kubernetes estate, regardless of where those clusters are running.
  • Data Services Anywhere: With Azure Arc, you can run Azure’s data services, like Azure SQL and PostgreSQL Hyperscale, in any environment. This gives you the flexibility to use Azure’s data capabilities wherever you need them most.
  • Consistent Governance and Security: Perhaps one of the biggest wins here is the ability to enforce compliance and governance policies consistently across all your resources, no matter where they’re deployed.

In short, Azure Arc is Microsoft’s play to bring coherence and control to the sprawling, often chaotic, world of hybrid and multi-cloud environments. It’s a tool that’s not just about visibility but about giving you the power to manage, secure, and optimize your entire infrastructure from a single point of control. And in a world where resources are scattered across different platforms and locations, that’s a game-changer.

Further Reading and Viewing on Azure Arc

If you’re interested in diving deeper into Azure Arc and particularly how it integrates with Kubernetes across various environments, there are a few must-see resources:

  1. Azure Arc-enabled Kubernetes Extensibility Model | Azure Friday – In this video, Scott Hanselman and Lior Kamrat discuss how Azure Arc enables Kubernetes clusters outside of Azure to be managed and governed like native Azure resources, complete with demos.
  2. Azure Arc-enabled Kubernetes with GitOps | Azure Friday – This session delves into how Azure Arc uses GitOps to manage Kubernetes clusters across various environments, showcasing how to maintain a single source of truth through GitHub repositories.
  3. Building Modern Hybrid Applications with Azure Arc and Azure Stack | Azure Friday – Thomas Maurer joins Scott Hanselman to demonstrate how to build and manage hybrid applications across multiple environments using Azure Arc, including a demo of Kubernetes integration.

These resources provide a comprehensive look at how Azure Arc can be integrated into your multi-cloud strategy, particularly if Kubernetes is part of your infrastructure mix.

What’s The Practice with Rider & .NET Solutions/Projects? How to resolve IDE errors?

Alright, I’ve fought with these kinds of things since the inception of .NET, the key difference now is that there are the variances in .NET versions and also IDEs. The question is, how should I setup my solution and respective projects?

First – .NET Solution

Usually what I do is create an empty solution. Name it, check the options accordingly to create a directory and make it a Git repository.

Then, as a kind of general practice I create a class library to build out logic and what not, and add a test project and then whatever the interface is going to be. That might be a web app, a GUI, or console as I’ve got selected here. Sometimes, if useful I go ahead and create a Dockerfile.

At this point, there are a few key problems I always bump into. Obviously, since I have a repo I need a .gitignore file, preferably a README.md, and maybe even a license file right? How does one add, so that the IDE is aware of them, any extra files at the solution level? What I usually do here, is use the terminal to just build out the solution level files, but then the IDE doesn’t know about them. Similar problems come up in the other .NET IDEs like Visual Studio and such.

Second – Open a Folder Solution

The second type of solution I find myself creating is started by opening a repo folder.

Empty, with nothing else that looks like this.

Creating a .gitignore and other respective files is easy at this point. As a right click will allow me to do just that. I’ve also added some projects.

At this point everything works great. As you can see below the runner is wired up, the IDE is aware of the tests, and runners are available for that.

One problem I’ve run into however with this technique, is sometimes I close this type of project – one started by merely opening the folder – and all this awareness just disappears. On the same machine, same folder, no deletion of the .idea folder or anything like that. It just loses all the awareness.

So my question is, which method do you use to start a project and how to do you, fellow .NET coders, work around these types of issues?

Using Multiple SSH Keys for Multiple Github Account

FIRST – Setup the Keys

If there is already a key, I can use this one to start with, but if there is no key to start with I’ll need to generate one. I can do this with the following command:

ssh-keygen -t rsa

When generating the keys, best to go with the default location, which is ~/.ssh/id_rsa. This will create two files, id_rsa and id_rsa.pub. The id_rsa file is the private key, and the id_rsa.pub file is the public key. The private key should be kept secret, and the public key can be shared with anyone.

For the next account, which I’ll just call the work account, I’ll generate another new key. This time I’ll hand off the following parameters to the key generation to provide the work account email and the file name:

ssh-keygen -t rsa -C "adron.account@work_mail.com" -f "work_account_one"

I’ve now got two keys, one for my personal account and one for my work account.

~/.ssh/id_rsa

~/.ssh/work_account_one

I’ll need to add these to the ssh-agent and the respect Github (or git whatever servers) so that I can use them.

SECOND – Add the Keys to Github

Adding the keys to Github. We’ll start with the personal account and then add the work account. Copy the public key using pbcopy < ~/.ssh/id_rsa.pub. With that copied log into the Github account that this key should be associated with.

1. Got to *settings*.
2. Select *SSH and GPG keys* from the account user menu.
3. Navigate into `New SSH Key`, give it a title, and paste the key into the key field.
4. Click *Add SSH Key*.

Now log out of that Github account and into the other account, the work account. Repeat the steps above, but this time use the work account email and the work account key.

THIRD

Register the new keys with ssh-agent. Start by checking that the ssh-agent is running with eval "$(ssh-agent -s)". In the past we would add the keys to the agent with ssh-add -K ~/.ssh/id_rsa and ssh-add -K ~/.ssh/work_account_one. Now the keys are registered with the agent with the following.

ssh-add --apple-use-keychain ~/.ssh/id_rsa
ssh-add --apple-use-keychain ~/.ssh/work_account_one

FOURTH

There is one last step, I need to tell the ssh client which key to use for which account. I can do this by adding the following to the ~/.ssh/config file.

# Account 1 - Primary
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  AddKeysToAgent yes
  UseKeychain yes

# Account 2 - Second Account
Host github.com-work_user_account_name
  HostName github.com
  User git
  IdentityFile ~/.ssh/work_account_one
  AddKeysToAgent yes
  UseKeychain yes

Note that work_user_account_name is the name of the work account, not the email address. I can now use the following commands to clone repositories from the respective accounts. This tells ssh-agent to use the id_rsa key for Git URLs starting with github.com and the work_account_one key for Git URLs starting with github-work_user_account_name.

FIFTH

One active SSH key per working session.

This is a good practice to follow. I can use the following command to start the ssh-agent and add the key to it.

eval "$(ssh-agent -s) ssh-add -K ~/.ssh/id_rsa ssh-add ~/.ssh/id_rsa

The same can then be done when the other key needs to be used.

A Quick Post on URL, URI, UDI, URN… Resources

URL, or Uniform Resource Locator, is often used as a blanket term for almost anything on the internet. A URI, or Uniform Resource Identifier, represents a unique resource on a server, located somewhere on the World Wide Web. Other abbreviations that are often confusingly related include UDI for Universal Document Identifier and URN for Universal Resource Name. All together we have the following abbreviations;

  • URL – Uniform Resource Locator
  • URI – Uniform Resource Identifier
  • UDI – Universal Document Identifier
  • URN – Uniform Resource Name

A URI can be either a URL or URN.

URI Syntax

scheme:[//authority]path[?query][#fragment]
  • Scheme – This is a non-empty sequence of characters followed by a colon, followed by any combo of digits, letters, periods, hyphens, or plus characters. The scheme is registered with the Internet Assigned Numbers Authority (IANA).
  • Authority – The authority is an optional field preceded by //. It has the following subfields.
    • Userinfo – A subcomponent which could contain username and password, or other user information data.
    • Host – A subcomponent containing either an IP address or a registered host or domain name.
    • Port – An optional subcomponent that is followed by a colon.
  • Path – Contains a sequence of segments separated by a slash characters. This could be something like /resources or /trains or similar.
  • Query – An optional component preceded by a question mark. The component contains a query string of non-hierarchical data, each parameter is separated by an ampersand in the query component and parameter values are assigned using an equals operator.
  • Fragment – An optional field and is preceded by a hash. The fragment includes a fragment identifier for a secondary resource.

Examples

  • mailto:myaddress@thrashingcode.com
  • telnet://10.20.0.1:23/
  • ldap://[2020:ba6:9:9]/c=ZAZA?objectClassOfDomain?objectOfDomain

The Differentiator

The URI examples above all could be called URLs, however the difference is that a URI is an identifier, where as a URL is an identifier and provides details on how to get to the identified resource.

URN AKA Uniform Resource Name

URNs are not used often. More specific details can be found in RFC 2141. For this quick post it’s safe to sort of ignore URNs, as the other abbreviations are the ones you will see out and about in the world, and specifically used in detailing REST APIs and the like.

Day 4 Studies – Web Related Things

Today I got into some studying Vue.js, but realized I wanted to cover some of the basics around things that Vue.js uses but I’d not really covered in the posts. Also before I got into some of the other core topics as outlined on Day 1 there were a number of things that just needed defined. This post, is about those things.

Virtual DOM – this is something you hear about that isn’t specifically Vue.js related. React uses a virtual DOM as do other frameworks. The DOM part stands for Document Object Model, and the Virtual DOM is a lightweight JavaScript representation of this model. This Virtual DOM is what is updated instead of the actual DOM, and when the Virtual DOM is ready for rendering to the actual DOM, a diff is done of the two and only the changes are rendered in the actual DOM. This generally makes changes render much faster than attempting to make the changes in the actual DOM only.

The frameworks that use a Virtual DOM include; React, Vue.js, and Elm. Other frameworks like Svelte created by Rich Harris does not, and Rich is also quoted as saying a Virtual DOM is pure overhead. A valid point, yet arguable whether this is an advantage or disadvantage, as it appears to depend entirely on the situation and type of page(s) being rendered.

There are other techniques like Angular or Ember.js’s incremental DOM that offer an alternate approach to DOM rendering.

Digging more closely into the Document Object Model, it is a cross-platform language independent interface that uses a tree structure to represent XML or HTML. Each branch of the DOM ends in a node, each node containing objects. This provides a way to programmatically traverse the model and gain access to various parts of the tree. The nodes within the DOM can also have event handlers attached to them, which provides a programmatic way to fire off events for execution.

The DOM technology is currently managed by WHATWG – Web Hypertext Application Technology Working Group.

Rendering Mechanism – This is the way, process, and flow of Vue.js’s rendering of a page for a Vue Application.

This all starts in Vue.js, with the above defined Virtual DOM, as defined in the docs as the VDOM. Remembering from above, that each branch ends in a node, a constant of the VDOM could be written up as shown.

const vnode = {
  type: 'div',
  props: {
    id: 'anIdentifierOfSorts'
  },
  children: [
    /* all the other nodes on down the tree. */
  ]
}

The Render Pipeline, at a high level compiles, mounts, and patches the VDOM. Vue templates are compiled into render functions that return VDOM trees. The mount function then invokes the render function which walks the returned virtual DOM tree, creates actual DOM nodes based on it and renders. This is performed as a reactive effect to apply changes to the actual DOM. Finally during mount changes, the effect reruns during patch, which creates a new VDOM, the runtime renderer walks the tree, does a diff, and applies updates to the actual DOM.

Templates & Render Functions

It’s important to know that Vue templates are compiled into VDOM render functions. Render functions can also be authored and called programmatically, bypassing a need to create a template. Even though vue recommends, and many if not most tutorials will show templates versus render functions, it’s important to know that render functions are available to use for more flexibility when dealing with dynamic logic or just odd business rules and such.