Having built out a new managed SF cluster, and having secured it with a management cert for SFX AND a nice signed X.509 cert for the API endpoint, I'd like to make sure when I push a change to the master branch that holds my SF definition and all the related services, that it deploys. 

In this case, I'm only interested in pushing new code out to a test cluster so I'm not hyper-concerned about preserving any data stored in any reliable collections in the stateful services. I just want the new stuff out in the semi-wild so QA and other stakeholders can fiddle with it. 

Azure DevOps pipelines to the rescue!

But nothing's really that simple. 

This solution has a bunch of requirements that you're average "Hello, Service Fabric" solution won't need.

  1. We have our own private Nuget feed so we need to connect that.
  2. We have git submodules in the solution.
  3. We're using the latest .NET 6 core.
  4. We're deploying to our cluster using an Active Directory credential.

I could do this in YAML... If I was a YAML expert. I am not. Mostly I just want to write code and leave infrastructure to others. But sometimes "others" aren't. This is one of those times. So I take it one by one.

Private NuGet repositories

I have a couple of private NuGet repositories. These can be setup and located in the "Artifacts" section of DevOps. Setting these up is an entry for another day. To get at them, I include a classic build step of NuGet restore. 



The "Feed(s) I select here" is a lie. I can only select one feed at a time, so unless I enumerate them in my NuGet.config file, I will need one of these tasks for each private feed.

Git submodules in the solution

To enable Git submodules, check the box.




If you don't do this, the submodules won't be pulled for the build and you'll be missing sources. :(

Using .NET 6 Core

.NET 6.0 requires I specify the windows-2022 build agent. Windows-latest does NOT cut the mustard. 



I also have to specify Visual Studio 2022 in the Visual Studio Version of the Build Solution task:

Deploying to our cluster using an Active Directory credential

This one is every bit as fun as it sounds. 

The key here is the Cluster Service Connection. Instead of using a cert to get the code out of the pipeline and into the cluster, I'm going with AAD.



Obviously, the Cluster Endpoint is where you need the cluster deployed - that's where it lives. If you're using a CNAME record to access the cluster, you don't want that here. Just use the FQDN (fully qualified domain name) Azure calls your cluster.

Under Authentication, it says "Server Certificate Lookup (optional)". Lies. It's not optional. You need to have something there. You do have a choice to use either the thumbprint or a common name. If you've read some of my earlier blog posts, you'll no doubt I'm not a fan of thumbprints because they change. However, I'm not entirely clear about how to find the common name of the cert that backs the cluster. And it's also not obvious where to find information about that cert. For example, here it isn't...


Don't bother looking on any of the other screens either. It's not there. Not under properties, or security, or access control. Nowhere there. The key is the JSON view. 

If you open the JSON view (because that's obvious), you'll find what you need.



THAT's the cluster certificate thumbprint. I couldn't find it anywhere else. But THAT'S what you need to fill in the "Server Certificate Thumbprint" above for the "Cluster Service Connection". Copying that screen cap here for convenience...


The next piece is the username and password of the Active Directory user under which deployment will occur. 



I simply created a new user for this particular task under Azure Active Directory/Users.

Important:

  1. This role CANNOT have multifactor authentication enabled. When the pipeline runs, there's really no way to wait for MFA. 
  2. After creating this role, log in as this user. You'll have to change the password that first time. If you don't, the deployment will fail because the user hasn't ever logged in and changed their initial password.
  3. If you require users to change passwords on a regular basis, be aware this will occasionally break the pipeline and you'll have to fix the connection with the new password.

In my instance, the deployment user doesn't have any access rights to the cluster itself. It's merely an AD member. However, it's going to need some additional access rights to the enterprise application that BACKS the managed SF app. 

Go to the Enterprise applications section of Azure Active Directory. Counterintuitively, eliminate the "Application type == Enterprise Applications". You need to be on this blade because you need to configure user access. 


In this list of now unfiltered applications, find the application registration that matches your cluster. I have a previous blog post that explains how to set up a managed SF cluster - see that for details.


Now, assign the deployment user to this application.



At this point, you should now be able to configure the deployment task having everything you need to flesh out the "Cluster Service Connection". 

In you deployment task, you should see (using classic build pipelines):



The highlighted yellow is where you specify and/or manage the "Cluster Service Connection" which, as we've seen, is what links:

  1. Where we're deploying - the cluster endpoint.
  2. How we're verifying we've connected to the right cluster - the server certificate thumbprint.
  3. The Azure Active Directory user we'll use to authenticate for deployment.
  4. The name of the service connection we can set in the deployment task.

AS ALWAYS, I put these out as much to educate you as me. If you see something amiss, or can add some detail or explanation or just correct me as I've got something wrong, please comment. These posts aren't meant to be canon, but merely to help others along the same rocky road.

 

Comments


Comments are closed