Category: CI-CD

SSL binding in Azure App Service

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

In part one we discussed how we can add custom domain in Sitecore App Service. Today we will go through how we can secure this custom domain with SSL bindings, so without doing any further delay below are the points to add SSL bindings.

Secure a custom domain

Do the following steps:

In the Azure portal, from the left menu, select App Services > <app-name>.

From the left navigation of your app, start the TLS/SSL Binding dialog by:

  • Selecting Custom domains > Add binding
  • Selecting TLS/SSL settings > Add TLS/SSL binding

Add binding to domain

In Custom Domain, select the custom domain you want to add a binding for.

If your app already has a certificate for the selected custom domain, go to Create binding directly. Otherwise, keep going.

Add a certificate for custom domain

If your app has no certificate for the selected custom domain, then you have two options:

 Note

You can also Create a free certificate (Preview) or Import a Key Vault certificate, but you must do it separately and then return to the TLS/SSL Binding dialog.

Create binding

Use the following table to help you configure the SSL binding in the TLS/SSL Binding dialog, then click Add Binding.

Setting Description
Custom domain The domain name to add the SSL binding for.
Private Certificate Thumbprint The certificate to bind.
TLS/SSL Type
  • SNI SSL – Multiple SNI SSL bindings may be added. This option allows multiple SSL certificates to secure multiple domains on the same IP address. Most modern browsers (including Internet Explorer, Chrome, Firefox, and Opera) support SNI (for more information, see Server Name Indication).
  • IP SSL – Only one IP SSL binding may be added. This option allows only one SSL certificate to secure a dedicated public IP address. After you configure the binding, follow the steps in Remap A record for IP SSL.
    IP SSL is supported only in Production or Isolated tiers.

Once the operation is complete, the custom domain’s SSL state is changed to Secure.

SSL binding successful

 Note

A Secure state in the Custom domains means that it is secured with a certificate, but App Service doesn’t check if the certificate is self-signed or expired, for example, which can also cause browsers to show an error or warning.

Remap A record for IP SSL

If you don’t use IP SSL in your app, skip to Test HTTPS for your custom domain.

By default, your app uses a shared public IP address. When you bind a certificate with IP SSL, App Service creates a new, dedicated IP address for your app.

If you mapped an A record to your app, update your domain registry with this new, dedicated IP address.

Your app’s Custom domain page is updated with the new, dedicated IP address. Copy this IP address, then remap the A record to this new IP address.

Test HTTPS

In various browsers, browse to https://<your.custom.domain> to verify that it serves up your app.

Portal navigation to Azure app

Advertisement

Deploying to Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

As part of of Sitecore Managed Cloud blog series this my last blog for how to deploy to Sitecore Managed Cloud.

Without any further delay I will start with option which we have to deploy to SMC.

  1. Sitecore Azure Toolkit (SAT).
  2. Use Azure DevOps with TDS and Razl.

Sitecore Azure Toolkit (SAT):

To deploy your Sitecore solution onto Microsoft Azure®. The Sitecore Azure Toolkit simplifies the task of preparing and deploying a Sitecore solution with:

  • PowerShell commandlets to package a Sitecore instance into role-specific packages.
  • Default integration with Microsoft Azure services: Microsoft Azure SQL®, Microsoft Azure Redis Cache, Microsoft Application Insights®, Microsoft Azure Cognitive Search®.
  • Prebuilt ARM templates for frequently used topologies: XM, XP, XPSingle.
  • Configuration tweaks to run Sitecore on the Azure App Service.
  • Security features: HTTPS, low-privileged SQL access, secure Sitecore password.

Click here for more documentation for  getting started with Sitecore Azure Toolkit.

Use Azure DevOps with TDS and Razl:

There is another way which can be used is Configuring CI-CD pipelines in Azure DevOps by Using TDS web deploy packages. And for migrating the database use a Razl for first time. Let me explain this to you steps by step.

  1. Once you get SMC environments to use, you need to raise a ticket to Sitecore support for providing a services contract details for Azure DevOps which you are using.
  2. Once you get those details you need to configure that in your Azure DevOps account.
  3. Once Above is done you can use TDS to build and create web deploy packages pipeline.
  4. Once build pipeline is created then you can go further and create a release pipeline for the same.
  5. Now once entire setup is done you can have two option for getting your content (Sitecore data) migrated. The simple way is to sync everything to TDS and deploy, and the best way(recommended) is that use Razl to Sync all data for first time and then in subsequent release sync only required Sitecore data to TDS.

Summary: I found two ways to deploy the solution on SMC, but there are many different ways to do this. Please let me know in comment the other ways you guys used for deploying Sitecore on SMC.

Note: For using Razl please click here for link where great way described by Jon Jones.

Happy Learning!!!!

Configuring Azure DevOp’s Release Pipeline for TDS

~ Nikhil Kulkarni ~ 2 Comments

Hi Champs,

In this part, we are configuring the settings in the Release pipeline to deploy our Web Deploy package. Although the deployment can also perform as part of the build, we prefer separate steps for build and deployment to reduce the chance of accidental deployments to production environments.

The Release pipeline takes the build artifacts from the Build pipeline and installs them on the Sitecore instances that have been configured in Azure. There are a couple of ways we can do this. We can use the generated PowerShell Script, or we can use some of the built-in settings in Azure DevOps. The PowerShell script can be modified to work within complex build processes, but the deployment can be accomplished even without it.

Deploy to Azure using the built-in Azure DevOps settings

Azure DevOps comes with a built-in App Service deploy task, taking the Web Deploy package from the Build pipeline and installs it in the selected Web App. Keep in mind, there are a couple of important configuration settings here. We need to add the Azure subscription where the Web App is located and select it under the Azure subscription tab. This fills out automatically as part of the settings, and you’ll only need to select your subscription and App Service.

Window of Azure App Service Deploy

Deploy to Azure using the generated PowerShell Script

The second way of deploying the Web Deploy package to the Azure Web App is using the PowerShell script generated by TDS Classic. This can be useful in build servers where there’s no native support for Azure Web deploy, or when the user wants full control and use their release script. The script also gives you an easy-to-read log containing the item names and location in the Sitecore tree of the items.

To use it, we need the Publish profile file, which can be added in source control and made available for the Release pipeline the same way we made available the PowerShell script and the Web Deploy package.

We also need to create a PowerShell Script task in our Release pipeline. In it, we specify the path to the PowerShell script, generated by TDS and the arguments, required for executing it. The arguments are the same as the ones we used for deploying from our development machine.

WIndow of Powershell

Both ways of deploying will give you status about the deployment and a log with all the details. The logs are formatted a bit differently, so consider this when choosing which method to use.

Window showing logs

Summary

With TDS 5.8, we had the goal to simplify the deployment of the TDS project to Azure environments. Using Web Deploy packages, we were also able to reduce the deployment time while making the process more intuitive and visible for the developers.

Missed Part Two? Click here to read how to configure Azure DevOp’s Build Pipeline.

Need to start from the beginning? Click here to read how to set everything up locally.

Also do check my blog for automating slot swapping in Azure DevOps.

Happy Learning

Configuring Azure DevOp’s Build Pipeline for TDS

~ Nikhil Kulkarni ~ 3 Comments

Hi Champs,

In part one, we set up our TDS project to create a Web Deploy package and published the package to an Azure App Service manually. Now that we know we can deploy our Web Deploy package from our local environment, let’s continue by setting up an automated build in Azure DevOps. In this part, we’ll configure only the steps in the Build Pipeline, and publish the build drop (a Web Deploy package and a PowerShell script) to the Release pipeline. Note that this is a simplified scenario to be used as a starting point. Your build/deployment process might be more complex and can include different steps than this one. 

Configure the Build Pipeline

For the build pipeline, we will build the project in the “Release” configuration being it is the configuration we set up for Web Deploy packages. The first step while creating your new Build pipeline is to select your repository settings. In this example, we will use Git.

Window to Select Repository

We also need to add the TDS license; otherwise, our build will fail. This happens in the Variables tab of your Build pipelines. The following variables should be created with your license info in the values.

As a starting template for our Build pipeline, we can use the Azure Web App for ASP.NET template. We don’t need all of the predefined build steps in the template for this example, so we will remove some of them. This is done to simplify the example and focus on the build process.

Window to choose a template

Our build will contain the following tasks in the Build pipeline:

Window of Build Pipeline

Summary of the Tasks

This summary explains each task and the most important thing we should configure:

Use NuGet
This task specifies the NuGet version the build server will use. We can leave it with the default settings.

NuGet restore
This task restores the NuGet package and also doesn’t require any special settings to be configured. 

Build solution
We will set the Build solution task to build the Release configuration. The Platform and the Configuration parameters are configured from the build variables. The default values are “Release” and “Any CPU” so we can use them directly.
Window to set Build Solution

Copy Files to
The next step copies the build output to the Staging directory, so it’s ready for publishing. We only need the PowerShell Script and the Web Deploy package from our build drop, so we will only copy them. Side Note: the paths might be different for your build. 

Window to Copy Files

Publish Artifacts
The final step in the Build pipeline is to publish the build artifacts to the next phase: the Release pipeline.

Window to publish the build artifacts

Once we have everything configured, we can run a test build. If everything is configured properly, we will see the Web Deploy package and the PowerShell script available in the Artifacts explorer in Azure DevOps.

Window of Artifacts Explorer

Summary

As shown above, setting up a build in Visual Studio online to create a Web Deploy package is relatively simple. The only real customization of the build was a step to pick up the files from the build folder and add them to the Artifacts folder. In the next part of the series, we will show you how to configure a release pipeline to deploy the Web Deploy package to an instance of Sitecore running on an Azure App Service.

Missed the first part? Click here to read Part 1.

Ready to continue to the next step? Click here to move on to Part 3.

Happy Learning