Technical and Product News and Insights from Rackspace
With the release of Sitecore® version 10, Kubernetes® is now a supported option. This opens up some great benefits, such as better resource utilization, version-controlled images, and overall operations ease. While building out an automated pipeline, I came across an error during the Kubernetes job step. Let’s dive in and see the fix I used to get successful deployments.
A colleague of mine was trying to figure out a cheap and simple way to store log files from their application and have the functionality to search through it. The first thing that came to mind was using an Azure® monitor to read the logs, but another option that most people forget is the Azure Linux Diagnostic Extension. This extension can collect metrics from the virtual machine (VM), read log events from the syslog, customize collected data metrics, collect specific log files that you can store in a storage table, and send metrics and log events to EventHub endpoints. The Azure portal lets the end-user configure all the preceding settings except collecting specific log files. Let me show you the steps required and a gotcha that sent me on a troubleshooting mission.
If you have been using Azure® Key Vault FlexVolume for Azure Kubernetes Service (AKS), it is time to switch over to the new provider. Azure deprecated the FlexVolume solution in favor of the Azure Key Vault Provider for Secret Store CSI Driver. The Azure Key Vault provider for the Secret Store CSI driver has a simple configuration that makes deployment and governance around keys, secrets, and certificates feel like any other Azure resources talking to the key vault. Let’s take a look at a complete example from provisioning an AKS cluster to reading in a secret as an environmental variable.
I hardly ever see the Azure® proximity placement groups feature implemented for Infrastructure as a Service (IaaS) solutions. Do folks not know that this feature exists, or is it just one of the many components people forget when architecting? For those that do not know what a proximity placement group is, it is a logical grouping that tries to keep your virtual machines (VMs) physically close to each other to reduce network latency between those VMs.
Azure® Private Endpoint provides private IP address access by using a network interface controller (NIC) attached to a virtual network subnet for an Azure web app, allowing access from an on-premise VPN or ExpressRoute. Implementing an endpoint effectively blocks the public inbound access. This technology is very similar to an internal App Service Environment (ASE) but much cheaper.
Most release pipelines have some automation to do after configuration to a virtual machine (VM) to prepare it for use. Looking at SQL Server®, you can configure a lot of options to make it production-ready. What most people do not know is that a resource provider within Microsoft® Azure® configures basic SQL Server settings without the need for any post-configuration scripts.
A colleague of mine sent me a message asking if I ever had an issue deploying an Azure® web app that routed through a hub-and-spoke topology. Trying to think back through the hundreds of deploys I have done, nothing came to me regarding any difficulties. Digging more into the problem with him, he explained that the web app could hit any virtual machine in the hub, but nothing in the spokes. This symptom sounded like a routing issue, with some oddities sprinkled on top.
One of the Azure multi-region topologies I have seen included an Azure Traffic Manager with Azure App Service Web Apps in each region. Some customers are cost conscious and would rather have a static web page display after a region failure with some generic message that there is a problem and it is being looked into. With the introduction of Azure Front Door, there are many capabilities that will not only enhance our live site, but will also serve as a cost-effective failover to a static website in a storage account.
When deploying Sitecore in to an Azure App Service, you have two options for setting up your search method. The first is method is to use the Azure search, which is integrated into the PaaS Deploy. The other method, and my personal favorite, is to deploy Apache® Solr Cloud.
Businesses today are becoming more multi-cloud than ever. When it comes to Sitecore deployments, being able to have fast page response times in China is becoming more critical. My goal is to create a secure site-to-site vpn tunnel between Azure and Alibaba. Once the tunnel is setup, I can then test out remote publishing target deployments.