The scenario I'm imagining for this demo is one where we have the same app running in multiple clouds. Maybe we're using Azure in the US and AWS in Europe. I've containerized the app, so it makes sense to run it in Kubernetes.

I don't want the main application to have cloud-specific builds, but the app will be talking to a database. Well, I'll be faking it in this case. So, it'll be a vendor-specific proxy.

The main app talks to the proxy, and the proxy takes care of talking to the vendor database, be that Cosmos DB and Dynamodb or Azure SQL and RDS. That part isn't really important. I'm just going to have an app listening on a well-known port number and returning a string.

So, there's a main app directory, an AWS directory, and an Azure directory, and at some point in the future maybe a Google one, etcetera. Each directory also has a docker file. I'm going to use Terraform for the infrastructure, and in this scenario, the DevOps team is responsible for the whole shebang, including the infrastructure.

So, my pipeline is going to look something like this. If I commit a change to the infrastructure directory, we're going to validate the changes and then update the EKS and/or the AKS clusters. If I push a change to the main app, we'll rebuild that image and push it to both clouds.

If I update either of the vendor-specific containers, it will just build and push that one. I'm going to use GitHub's registry GHCR, but it could be a and others for the container images. We need to give GitHub permissions to make API calls into AWS and Azure, so we use OIDC as a best practice. For OIDC and Azure I'll put a link to the appropriate document below.

But first I need to create an app registration. I'm calling it GitHub Actions. We'll need the client ID and the tenant ID which I've blurred out here. Then I need to create a credential. The issue is pre-populated because of the scenario I've chosen. The organization needs to be your organization.

In my case, I'm using my personal GitHub account rather than one that all of QA has access to because I'm giving it permissions in my personal Azure and AWS account. I like my colleagues, but I don't necessarily trust them, and I need to specify the repo and branch.

The subject identifier will be populated based on this information. I can give it a description if I feel the need. Now I need to give the identity some permissions. In this screenshot, it's just got the reader role because I was just building out the pipeline when I took it.

Obviously I'll need the appropriate roles and scopes to do what it needs to do. Create and update AKS, etcetera. Then I need to go and plug those IDs from earlier into my secrets manager. I'm just using GitHub secrets, but you might want to use Vault or something.

I also need my subscriptions ID. For OIDC and AWS, again, I've added the link below. This felt a bit more straightforward than in Azure. In IAM, in identity providers, I added an OIDC provider token.actions.githubusercontent.com and gave it an audience of sts.amazonaws.com.

Then I created an IAM role with the permissions to do what I wanted GitHub Actions to be able to do and allowed the GitHub OIDC provider to assume that role using a trust relationship. Finally, I grabbed the roles ARN, Amazon resource name, and added it to my GitHub Secrets.

Now I can get on with a demo. So, we're in VS Code. I've got the infrastructure that YAML pipeline open. We can see here that it triggers on a push to the infra directory, the TF directory. So, what I'm going to do is I'm going to bump a version number in this variables.tf.

All of these variables are passed in by GitHub Actions apart from this version. So, my version bump is just going to force it to deploy the pipeline which I tore down earlier to make sure I was creating everything from scratch.

So, I'll save the changes, add it, and do a Git push which should then kick off the pipeline. So, that's the pipeline running and it's going to take a little while to run. So, let's talk through this pipeline whilst it's doing that. I won't go through the TF templates.

It's creating a VNet and an EKS cluster, and it's creating a VPC and an EKS cluster. So, these permissions are telling it to have permissions to use GitHub tokens to be able to authenticate with AWS and Azure. Got a single job called "Create or update EKS and AKS clusters", need to specify that it runs on the latest Ubuntu VM.

Worker directory is fine. So, we're checking out the source code, configuring AWS credentials. This is one of these custom actions for GitHub.

We're going to configure some Azure credentials, and again, let's put in those secrets, those RIDC secrets out of GitHub secrets. Install Terraform, Terraform init, configuring the back end state bucket, doing a format just with a check.

And effectively, if I haven't linted the TF files correctly, the build's broken. Validate it, do a TF plan, and again we'll pull in these variables out of GitHub's variable store, and then finally apply it with those same variables.

Once that's done, we install kubectl. It's an Azure GitHub action, but kubectl doesn't care what cluster it's talking to, so it will talk to EKS just as happy as it will talk to AKS. Set up the context. So again, there's this set context action for Azure. Which resource group? Which cluster are we doing it?

I'm creating an Azure namespace called gha-demo-azure. If that namespace doesn't exist, kubectl will throw an error which will break the build, so I'm telling it to ignore if it's not found. So basically, if a namespace isn't there, we'll create the namespace and specify right to outputs that we've created the namespace.

Deploy the Azure manifest. I'll share that manifest in a second. Once that manifest is creating a deployment and a service of the load balancer type.

So, I'm going to wait for that load balancer to be created and add the load balancer's IP address to get up outputs. Reset the cube context for EKS, make sure that namespace exists in AWS. Same thing, it's gha-demo-aws. Apply the manifest.

Now there's an additional step here for AWS because that base manifest, let me show you, has got hard coded. So, that's the main app and we'll show you that later. Here's the proxy, the sidecar. It's hard coded with gha-demo-azure-db-proxy, so I need to change that -azure- into -aws-. So that's what this said stream edit is doing.

I should probably be using something like Customize or GitHubs or Helm, or a combination of all three, but I know that the demo is going to be long enough as it is. So just doing some basic in place editing, wait for the load balancer to be created, spit out the address, and then the outputs, the two outputs from that job are those load balancer IP addresses.

Well, strictly speaking, in EKS, it's going to be a DNS name, not an IP address. Yeah, it's still running. It's going to take a while to do that. Terraform apply. So we'll head back in the VS Code again.

Let's look at the containers. Here's main.py from the main app. So this fake_db_proxy_invoke is opening a request on localhost 9090. It's going to be the fake database response. And it's passing that and a bunch of other variables into the templated index.html.

This is the index.html for the Azure proxy. Just return a single string and docker file using a very basic HTTP server, and it's listed on port 9090. AWS ones are basically the same, it's just it says AWS instead. Pipelines still running so let's look at the container pipelines.

I've got this reusable workflow called build-and-publish.yaml which takes three parameters: the registry we're using (GHCR in this case), the name of the image, could be the main app, could be the Azure proxy, could be the adverse proxy in the working directory so that we know which one to build. Runs on Ubuntu latest.

We need some permissions to do things using that checkout action again. We're using a docker login action, we're logging into GHCR, but we're still using the docker login action. Extracting the metadata, build and push the docker image, and then finally generate some artifact attestations. Seems like that would be a good thing to do in a production environment.

Main app is triggered on a change to source/main app. It's using that reusable workflow, passing in those variables. Got various permissions, runs with Ubuntu latest.

Forgot to mention, workflow dispatch means I can manually trigger this and I set that up whilst I was building this demo out. Remember, a DevOps purist doesn't want a human being anywhere near their pipelines. I'll remove that in production.

So, we're pushing, installing kubectl, setting the AKS context again, all very similar to the infra pipeline. But then this update Azure deployment, all we're doing is using this kubectl set image to update the image to use the latest version of the image in the gha-demo-azure namespace.

Deploy AWS. Same thing again, we're setting the EKS context and we're updating the AWS deploy using the latest version of the AWS image. Those two jobs, the deploy AWS and the deploy Azure can run in parallel as long as the build and push main app has already completed.

That's what this needs, is doing. Azure proxy workflow, pretty much the same. Only true not to change the Azure proxy location, but we're just pushing to Azure. The AWS one, it's the same, it's just it's pushing to AWS. All that commented out stuff is from before I created the reusable workflow.

All right, so it's finally completed. Took 14 minutes and 15 minutes, but we now have the load balancer address of the AKS cluster and a load balancer address for the EKS cluster. Let's see if it's worked. Hurrah.

So yeah, that's the Azure one. Let's look at the EKS one. Brilliant. Now we'll push a few changes. So we'll make a change to the Azure proxy. Not a particularly exciting one, and we'll push it. So, that took about 30 seconds to run. Let's see if it's been updated. Woot.

And I'll do the same thing with the main app. Again, I'm just going to change the message that's being displayed and push that. And again, we'll give it a little while to run. We can see those two deploy jobs running in parallel.

They're running simultaneously and the AWS one is done. That's refresh, okay, and the Azure one is done. Happy days. Thanks for watching, hope you've found it useful.

Demo: GitHub Actions

About