Join Chander Dhall for an in-depth discussion in this video Deploy to an Azure cluster, part of Microservices and Azure Service Fabric Basics for Developers.
- [Instructor] Now that we've created the cluster on Azure, we're back to our application where we had two different services that we created. The first one is a stateful service, and the second one is a stateless service. Next thing we would like to do is publish this to our actual Azure cluster. So all we're going to do is go to our app, right click, publish. When you publish, if you haven't signed in, Visual Studio might require you to sign in, with your Azure account. All you have to do is click here and then it will allow you to sign in.
Whenever you sign in, it automatically picks up your cloud.xml publish profile. And then you can click this drop-down and pick either the local cluster, or the cluster we just created. Next we need to hit publish, and we will have our application published to the cloud. It will take some time, but then your app will be on your Azure cluster. So now you can go to portal.azure.com.
And then click on your sample Azure cluster. And then click on explorer. If you notice, the explorer is very similar to your local explorer. It has the same port 19080/Explorer. And then you also have the uri in front of it. Now you might see this problem, but what you need to do is go to advanced, and then say proceed to your cluster. And it's going to ask you for the certificate, and in this case we're going to go over the sample course certificate, which is already installed on our local machine.
And we can see the explorer. You can see that we have applications, and the name of the application here. And then we have the stateful, and the stateless app. And you can click on any of these and then get more details. So in this case, we can see that the stateful service is on a primary node, and then it has two secondary nodes. And you can see the stateless app has got about five different nodes. And you can see more details here. If you look under System, now we have six different services.
When we were running this on the local, we only had four different services. And the reason is because like I said for example, image store, now it's accessible on your Azure instance, even though it doesn't really make sense on the local instance. If I were to come to the primary node, I can look into the details. It tells me that the name is node four, and it happens to be the primary node for the stateful service. At a cluster level I can look at the details here, so it tells me about any kind of health events, so if there was something that went wrong, I would have got a message here.
And then you also have these replica counts. And then the cluster manager service primary counts, and a lot of other metrics that you might be interested in. And then it talks about the Upgrade Domains, and Default Domains that I'll explain to you in a second. So as you can look at the Cluster Map, there are two things here. One is the Fault domain, and the other one is an Upgrade Domain. So the way Microsoft documentation describes a Fault Domain, it is any area of coordinated failure. That simply means, if it's a single machine it's definitely a Fault Domain.
The reason is because at any given point of time, there could be a power failure, or even a dry failure, or something else. That can bring the machine down. At the same time, a bunch of machines that might be connected to the same ethernet switch, are also inside the same Fault Domain. Because all it takes is for that switch to stop working, and all the machines are going to be down. Now Upgrade Domain is very similar to a Fault Domain, however the major difference is that it consists of all the machines that will actually go down in case of an upgrade.
So the benefit of this cluster map is that, let's take an example where you had, a node in Upgrade Domain Zero and Fault Domain Zero, at the same time you had another node in Upgrade Domain One, Fault Domain Zero, and you did not have a domain in Fault Domain One, and Upgrade Domain One. That would not be a very good map for the sustainability of your service fabric architecture. Simply because, at some point of time, the machine that's actually part of the same Fault Domain, as well as Upgrade Domain, both of them would be down.
So we won't have the right redundancy. So what you see currently in front of you is a good way of having that architecture work. So in order for your architecture to be sustainable, for a given service partition, there should never be a difference greater than One in the number of replicas between two domains.
- Reviewing microservices vs. monolithic architecture
- Reviewing microservices and Azure Service Fabric basics
- Programming model architecture
- Creating a stateless service and a stateful service
- Creating a cluster in Azure
- Adding security to a cluster
- Finalizing cluster creation
- Deploying to an Azure cluster
- Debugging an application remotely