Azure PaaS多区域Sitecore部署咨询：主区域全XP+从区域仅CD配置

Absolutely, using Azure's cloning capabilities combined with targeted configuration tweaks is a valid approach for deploying your secondary regional CD nodes—here's how to pull it off smoothly, along with key considerations to avoid pitfalls:

• First, confirm your primary region's CD node is isolated in a way that makes cloning feasible: if it's an Azure App Service, use the App Service Clone feature to replicate it directly to your target secondary regions. This copies core settings like app service plans, app settings, and deployed Sitecore files, but you’ll want to exclude any region-specific dependencies (like local CD-DB connections) during the clone process.
• If you’re working with ARM templates, cloning is a quick shortcut, but keep in mind that reusing and modifying your existing primary region ARM template for CD-only deployments might be more scalable long-term.

Once the clone is live in your secondary region, you’ll need to update these core settings to connect to your primary region’s resources:

• CD-DB & Publishing Target Setup
  • Edit Sitecore.config and Sitecore.ContentSearch.config (or use Sitecore patch files for cleaner updates) to point the CD node’s database connection strings to your primary region’s master publishing database—not the cloned local DB that came over with the copy.
  • Configure Sitecore.Publishing.targets to add your primary region’s CM node as the publishing source, ensuring the secondary CD receives content updates from the main XP environment.
• XDB & Forms Database Integration
  • Update connection strings in Sitecore.Xdb.Collection.config and related XDB config files to point to your primary region’s XDB collection database, XDB index, and other XDB resources.
  • For Sitecore Forms, adjust the connection string in Sitecore.Forms.config to target your primary region’s Forms database.
• Region-Specific Optimizations
  • Tweak local caching settings in Sitecore.Caching.config to account for network latency between the secondary region and primary databases—adjust cache expiration times to balance freshness and performance.
  • If using Azure Front Door or Traffic Manager, register the secondary CD node’s endpoint in your global routing rules to ensure traffic is routed correctly.

• Pros: Fast to implement, preserves your primary CD’s proven environment configuration (like app service plan sizing, security settings), and avoids rebuilding the CD environment from scratch.
• Cons: May carry over redundant primary-region settings (like local DB connections, region-specific logging) that need manual cleanup. Also, future configuration changes to your primary CD won’t sync automatically to cloned nodes—you’ll need to set up a sync mechanism (like Azure App Configuration) or manually replicate updates.

For better long-term maintainability, consider adapting your existing primary region ARM template into a CD-only deployment:

• Modify the sitecoreRole parameter to ContentDelivery to exclude non-CD roles (CM, Processing, etc.).
• Update all database connection string parameters to point directly to your primary region’s database resources.
• Remove any resource definitions that aren’t needed for a CD node (like CM-specific app services, local CD-DB instances).
• Deploy this modified template to each secondary region—this creates standardized, reproducible CD environments that are easier to update at scale.

内容的提问来源于stack exchange，提问作者Hellraiser