Category: Azure DevOps

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

Disaster Recovery in Sitecore Managed Cloud

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I will explain DR or considering High Availability options in Sitecore Managed Cloud. So without doing any delay, we are going to touch straight to the point and start with a process for recovering your data in the event of an outage, incorporating:

  1. Backup technology
  2. Your secondary environment
  3. The steps of the recovery process
  4. Cost
  5. The recovery point objective (RPO)
  6. The recovery time objective (RTO)

Sitecore Managed Cloud offers three different disaster recovery options that differ slightly in cost and specifications, depending on your requirements. The recovery options available are:

  1. HADR Basic
  2. HADR Hot-warm
  3. HADR Hot-hot

Before we go into an explanation of the above three option, I want to explain basic terminologies in the Sitecore high availability disaster recovery (HADR):

  1. High availability (HA) – A system that aims to ensure an agreed level of operational performance. Usually, the uptime is higher than for the normal period, where the system can failover by itself.
  2. Disaster recovery (DR) – An area of business continuity planning that aims to protect an organization from the effects of significant negative events. Disaster recovery allows an organization to maintain or quickly resume mission-critical functions following a disaster that requires manual intervention.

Now I will explain all three options mentioned above, on a high level one by one as below.

HADR Basic:

With HADR basic, the Sitecore Managed Cloud disaster recovery service sets a process into action in the event of an outage. The steps of this process include:

  1. Scheduling a reoccurring backup, that occurs every 3 hours, of the following assets into the secondary database of the recovery point objective (RPO):
    • The databases.
    • Web applications.
    • The connection strings, (for the credentials).
    • The sizes/tiers of the resources.
  2. Arranging an outage page for customers to see while your site is down.
  3. Setting the traffic manager to switch between the primary Content Delivery (CD) server and the outage page.
  4. Setting up email alerts to notify the Managed Cloud Operations team if the availability tests fail.

HADR Hot-warm:

If you are using the HADR hot-warm option, in the event of an outage the Sitecore Managed Cloud disaster recovery service sets the following process into action:

  1. Deploy a new Sitecore environment in the secondary data center and shut down your web applications.
  2. Use active geo-replication to sync the data between the primary and secondary Azure SQL.
  3. Sync the sizes/tiers of all your Azure resources.
  4. Sync the file contents of all of your web applications.
  5. Set up an outage page to ensure your customers are aware that your site is temporarily down.
  6. Set up a traffic manager to switch between the primary Content Delivery (CD) server and the outage page.
  7. Set up email alerts to notify the Managed Cloud Operations team whenever an availability test fails.

HADR Hot-hot:

In the event of an outage, with the HADR hot-hot option, you must set into motion a recovery a process that is similar to the following:

  1. Enable recovery during a disaster by setting up the necessary environment before the disaster happens.
  2. Initiate the backup and replication process so that the Sitecore deployment and data are available for a healthy recovery.
  3. Deploy a passive Sitecore solution into the secondary region.
  4. Set up and enable the traffic manager to be the public gateway.

Prerequisites:

To set up your disaster recovery process:

  1. Ensure you are running your Sitecore solution (9.1 or later), on Azure.
  2. Install PowerShell with an Azure SDK, version 6.0.0 or later.
  3. Run your setup script and use the relevant modules.
  4. Use PowerShell (AzureRM), to log in to Azure and select the relevant subscription.
  5. Have your Sitecore license file ready.
  6. Have any scripts that you want to develop for your HADR hot-hot scenario ready.
  7. Use the Sitecore Azure Toolkit.

Note:

  1. Sitecore supports the following topologies: XM and XP, and the following deployment sizes: Extra Small, Small, Medium, Large, Extra Large.
  2. You can also use Simple Azure PaaS DR management to create DR of your SMC instances.

Reference:

https://doc.sitecore.com/developers/91/sitecore-experience-manager/en/high-availability-disaster-recovery–hadr-.html

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

Setting Up TDS to Build Azure Repo

~ Nikhil Kulkarni ~ 2 Comments

Hi Champs,

In next few blogs I going to explain you setting up TDS for entire Sitecore CI-CD process. Without any further delay we will start by below.

By using TDS 5.8 and Web Deploy packages, I’ll walk you through on how to create a fully automated build and deployment process from your workstation to source control and into your Azure environment.

The TDS Web Deploy packages were designed around quick and easy deployments to Azure, but they can be deployed to any Sitecore server that supports Web Deploy.

The difference in using .update packages and Web Deploy packages 

Workflow before TDS 5.8
Chart showing deployment before TDS 5.8

Workflow after TDS 5.8

Chart showing deployment process with TDS 5.8

Setting up the TDS project for Web Deploy

The Web Deploy Package tab has similar options to the Update package tab. You can enable building a Web Deploy package, what to include in the package, and the package name. In this example configuration, we’ll need a Web Deploy package, so we’ll check off “Build web deploy package.” The name can be left blank, and it will use the name of the project.

Window showing Web Deploy Package Tab

Since we are planning to build on the cloud based VSO build server, we need to add the TDS Build components NuGet package into the TDS project. To do this, you need to execute the following command in the Package Manager Console of Visual Studio. Side note: make sure you have selected the nuget.org repository while executing this command.

Install-Package HedgehogDevelopment.TDS -Version 5.8.0.6

Building the Web Deploy package

To create the Web Deploy package, simply build the project/solution with the configuration where Web Deploy packages are enabled. When the build is finished, you will find a folder called [Configuration]_WebDeploy with the Web Deploy package and the Web Deploy PowerShell script.

Image showing Publish Web Deploy and TDS Project files

Please note: the PowerShell script provided by TDS isn’t the only way to install the package. It is provided as a convenience for the developer to help them deploy the package if they don’t have another method of deploying it. It also contains script that can be used to monitor the deployment on the server.

Testing the Web Deploy package

Once you have the Web Deploy package and the PowerShell script, you only need to specify where it should be deployed. This can be easily set using a Publish Profile from Azure or by using parameters to the PublishWebDeploy.ps1 script. You can get a publish profile from the control menu of the App Service in Azure.

control menu of App Service in Azure

Now you can make a test deployment to the Sitecore instance using the script. I placed my Publish Profile file in the same directory where the Web Deploy package and the script were generated.

If you want to deploy the Web Deploy package into your Azure instance, all you need is to execute the script using the following parameters:

PublishWebDeploy.ps1 -PackagePath TDSProject1.wdp.zip -PublishSettingsPath tdstestinstance-630820-single.PublishSettings -ViewLogs

Summary

This completes the setup of the TDS project for building Web Deploy packages. Soon, I’ll walk you through on how to set up a TDS build in a Visual Studio Online Build Pipeline.

Ready to move on to the next step? Click here to read about configuring Azure DevOp’s Build Pipelines.
 
 
Happy Learning

Sumo Logic integration with Sitecore Azure PaaS

~ Nikhil Kulkarni ~ Leave a comment

Hi Champs,

Today I am going to take you to the new product called Sumo Logic which we can integrate with Sitecore Azure PaaS for better log management.

Before starting you may have below two questions.

What is Sumo Logic?

Sumo Logic is a cloud-based machine data analytics company focusing on security, operations and BI use-cases. It provides log management and analytics services that leverage machine-generated big data to deliver real-time IT insights

Why Sumo Logic?

As per my experience Sumo Logic is coolest tool I ever seen for Log Management and monitoring. It gives a GUI based Live log management system by which you can track everything and not losing your time for checking logs from files. One more advantage is it alerts you one basis of exception captured in Log.

We will move without killing more time to the steps of configurations which are as below. Note all below steps you need to perform against your Sitecore Azure PaaS resource group.

Step 1. Configure Azure storage account

In this step you configure a storage account to which you will export monitoring data for your Azure service.

If you have a storage account with a container that you want to use for this purpose, make a note of its resource group, storage account name and container name and proceed to Step 2.

To configure an Azure storage account, do the following:

  1. Create a new storage account General-purpose v2 (GPv2) storage account. For instructions, see Create a storage account in Azure help.
  2. In the Azure portal, navigate to the storage account you just created (in the previous step).
  3. Select Blobs under Blob Service.
    Make a note of the container name, you will need to supply later in this procedure.

    1. Select + Container,
    2. Enter the Name
    3. Select Private for the Public Access Level.
    4. Click OK.

Step 2. Configure an HTTP source

In this step, you configure an HTTP source to receive logs from the Azure function.

  1. Select a hosted collector where you want to configure the HTTP source. If desired, create a new hosted collector, as described on Configure a Hosted Collector.
  2. Configure an HTTP source, as described on HTTP Logs and Metrics Source. Make a note of the URL for the source, you will need it in the next step.

Step 3. Configure Azure resources using ARM template

In this step, you use a Sumo-provided Azure Resource Manager (ARM) template to create an Event Hub, three Azure functions, Service Bus Queue, and a Storage Account.

  1. Download the blobreaderdeploy.json ARM template.
  2. Click Create a Resource, search for Template deployment in the Azure Portal, and then click Create.
  3. On the Custom deployment blade, click Build your own template in the editor.
  4. Copy the contents of the template and paste it into the editor window.
  5. Click Save.
  6. On the Custom deployment blade, do the following:
    1. Create a new Resource Group (recommended) or select an existing one.
    2. Choose Location.
    3. Set the values of the following parameters:
  • SumoEndpointURL: URL for the HTTP source you configured in Step 2 above.
  • StorageAccountName: Name of the storage account where  you are storing logs from Azure Service, that you configured in Step 1 above.
  • StorageAccountResourceGroupName: Name of the resource group of the storage account you configured in Step 1 above.
  • Filter Prefix (Optional): If you want to filter logs from a specific container, enter the following, replacing the variable with your container name: /blobServices/default/containers/<container_name>/
  1. Select the check box to agree to the terms and conditions, and then click Purchase.

Azure_Blob_Storage_Custom_Deployment.png

  1. Verify the deployment was successful by looking at Notifications at top right corner of Azure Portal.

notification-success.png

  1. (Optional) In the same window, click Go to resource group to verify the all resources were successfully created, such as shown in the following example:

Azure_Blob_all-resources.png

  1. Go to Storage accounts and search for sumobrlogs, then select sumobrlogs<random-string>.

storage-accounts.png

  1. Under Table Service do the following:
    1. Click Tables.
    2. Click + Table.
    3. For Name, enter FileOffsetMap.
  2. Click OK.

Azure_Blob_create-table.png

Step 4. Push logs from Azure Service to Azure Blob Storage

This section describes how to push logs from an Azure service to Azure Blob Storage by configuring Diagnostic Logs. The instructions use the Azure Web Apps Service as an example.

  1. Login to the Azure Portal.
  2. Click AppServices > Your Function App > Diagnostic Logs under Monitoring.
  3. You will see the Diagnostic Logs blade. Enable Application Logging, Web Server Logging, or both, and click Storage Settings.
  4. Select the Storage Account whose connection string you configured in Step 1.
  5. In the Containers blade, select the container you created in Step 1.
  6. In the Diagnostic Logs blade, specify the Retention Period (Days), and click Save to exit Diagnostic Logs configuration.export-webapp-logs.png

Happy learning and innovating Sitecore.

Automating Deployment Slot Swapping for Sitecore Azure PaaS

~ Nikhil Kulkarni ~ 1 Comment

Hi Champs,

Today I am going to introduce you to the steps which you can use to swap deployment slots for production environment automatically in release pipeline by small manual intervention for approval/resume. Below are the steps which will help you to set-up slot automation.

Given any scenario this will work, but in my case it is like below.

I have release pipeline stetted up according to the environments.

Configuring slot swaps in Production

The Dev and QA environments orchestrate whatever flow you want in those environments (e.g. provision using ARM, deploy, run functional tests, run load tests etc.), and in this example don’t have any slot specific activity. Therefore let’s take a look at the production environment tasks itself directly:

(I’ve kept this to a minimum to keep it clearer, so no provisioning, running scripts or other activities.)

First deploy the web application to the staging slot in the production environment using the Azure App Service Deploy task:

Check the Deploy to slot option in the standard task, and then choose the Slot (I called the slot “staging” but you can use any name).

Next I’ve added an Agentless phase as it’s not going to delegate any actions to an agent, and added a Manual Intervention task. This causes the flow to pause until the manual intervention is completed by the specified approvers (groups and/or individuals). If it’s approved then it carries on, if it’s rejected (or times out and therefore is rejected) then the flow stops. In this case that works for me as I want the staging environment to be manually verified and then signed off as ok for final release to production. If it gets rejected then it never gets promoted from staging to production.

Finally, if the staging slot has been manually verified and is ready to be used, then we can initiate the actual slot swap (in an agent phase) using the Azure App Service Manage task:

The staging and production slots will then be swapped over, leaving the old production version in the staging app and the latest version in the production slot.

This flow supports the actual slot swaps being automated, but with manual approval. A nice side effect of the slot swap is that should there be a problem, the slot swap can be reversed to redeploy (rollback) the old version of the app now in the staging slot.

Happy Learning/Innovating Azure.

Working with Sitecore Managed Cloud

~ Nikhil Kulkarni ~ 1 Comment

Hi Champs,

Today I am going to share my experience of working with Sitecore Managed Cloud from scratch. In my scenario, it was fresh website deployment on Sitecore Managed Cloud offering which I will split this is below section to make it better. Sorry but this is a bit lengthy and theoretical article which may get boring but reading this article will give you a better understanding of working practically with Sitecore Managed Cloud.

Engaging the Customer:

In this process, you need to agree with Customer and Sitecore that you will be using this offering from Sitecore. For that Sitecore Team and you need to list down the benefits like below for this offering.

  1. Service availability is managed by the Sitecore team.
  2. Sitecore Managed Cloud Team will be responsible to set entire infrastructure.
  3. Depending on traffic/expected traffic Sitecore Managed Cloud team suggests the Scaled environment topology be used in the Production environment.
  4. Sitecore Managed Cloud team will be monitoring the activities and report any unwanted incident happens and try to help the Partner team to work on that exact point to make sure that nothing is going wrong.

Step-in to procure:

In this process Customer and Partner team has to sign an agreement and procure the Sitecore Managed Cloud services and also add it to Sitecore License. At the same time Partner and Customer has to also need to provide information about different modules that are used in the implementation so that Sitecore License will have all the necessary conditions applied to it. Once this is done Sitecore Managed Cloud team will assign a ticket to Client for feeling the same information and some more information. This ticket will have table which you guys need to fill for information like including things like Solr/Azure search, EXM, JSS, and different modules if applicable. After this Sitecore Managed Cloud team will commission environments like (Dev, QA, Prod)  as mentioned by you with all the credentials details.

Set-up Azure DevOps:

This process is a bit useful for developers and DevOps guys. You need to follow the below steps.

  1. Create a release pipelines according to branches and strategies.
  2. Once this is done when now you need to change the subscriptions and resources to Sitecore Managed Cloud.
  3. For above you need to add Service Connection for your Azure DevOps.
  4. To get service connection you need to create a Sitecore Ticket so that Sitecore Managed Cloud team will create Service Connection and will share the details to you.
  5. Onccce that is in place you need to create Service Connection in you Azure DevOps and apply right Subscriptions and resources to right task and jobs in pipelines according to environments.
  6. Now you are ready for a fully automated Sitecore System and can deploy everything step by step on respective environment and test the implementation.

Note:

  1. In Sitecore Scaled environment you will get different web apps for each service like cm, cd, processing, redis, xConnect, xcSearch, and others.
  2. As Solr comes as a different Cloud offering in Sitecore Managed Cloud so that will be partially maintained by Sitecore Managed Cloud team but for more information on this you can check with Sitecore itself.
  3. While implementing this if you face any issues you need to follow same process of raising the Sitecore support ticket to get solutions.
  4. For escalations and different leadership help, Sitecore assigns a Customer Success Manager for this offering which is a great help from Sitecore.

Happy Learning Sitecore…..