Now that we have successfully built the container image, we need to deploy it.
So under Deployment specifications, I specified AKS,
and I found that although you can create a new cluster right here,
I would strongly recommend that you build it using an ARM
or a Bicep script or in the portal, given all of the configuration options.
Specifically, in this case, I'm going to need not a Linux agent pool,
but a Windows agent pool, and I'm going to need to make sure to use CNI,
rather than kubenet, there is a lot of presumed knowledge there.
Long story short,
I have a windows pool right here so I will validate that AKS cluster here,
and then we'll continue.
Hopefully it makes sense that if you go the route of Java on Linux,
you're going to need Linux for your underlying infrastructure.
And if we're doing ASP.NET Windows, the containers will be running Windows.
Okay, so let's see here, no application.
We don't need to parameterize here because we don't have an app config file,
and if we did,
we would need to specify a secret store to store things like certificates.
Were not using persistent volumes.
This is a consideration for some businesses where
you've got Docker containers running, and you know,
the idea is that containers are meant to be ephemeral,
so they're relatively stateless.
If you have need to maintain state in a container,
you will create what's called a Docker volume, and the way that's implemented
here in AKS is that you use a file share in an Azure Storage account and
that's where your persistent volume will be stored.
I'm not doing any in this simple case, so we'll click Continue,
and then we have our deployment configuration that we can verify.
I'm not doing anything with SSL TLS so it's just going to be port 80.
Let's click, again, Configure, verify the settings,
and click Apply in order to commit our choices and then Continue.
Ready to go?
Let's do it.
Let's click Deploy,
and there is going to be a lot of moving parts going on under
the hood that are all abstracted away from us.
Docker push of our image into the Azure Container Registry,
then the Container Registry is tied in with my AKS cluster.
This is because I've created that integration.
Let me go to the Azure portal and do a search for registries.
We can go to Container registries, there is my registry right here,
and if we come over to Repositories, we have our webapp image.
It looks like it's already there and ready to go,
and then as far as AKS is concerned, I've got my akswin cluster right here,
and if we come down under Settings, Node pools,
you can see my win2 node pool consists of 3 virtual
machines running on a particular size,
and I want to make sure that those are Windows nodes so that they
can host this workflow in this application.
Okay, it looks like our deployment completed.
We can browse to the public IP associated with the service on Port 80.
There is a guidance link here.
We can reset the configuration.
If we come to the Workloads page in our AKS cluster,
it looks like I've got a crash loop going on there,
so I've got some more debugging to do in this case.
Yeah, it looks like it's in a problematic state,
but we can verify that it is, in fact, running as a pod.
It's been running for 6 minutes,
and the image that it's pulled from is from our Container Registry.
This is a good real world case because I found,
in most cases, no matter how much we automate,
well there is still normally a little bit of tweaking and refinement that's necessary as well.