External Hosting: Content Sync Setup

Introduction

AgilityCMS is decoupled from your website so you can host an Agility website in a custom/private data center or a cloud provider of your choice. In this guide, we'll explain what you need to do get your CMS content syncing to your web hosts and the variety of ways you can get it done. At this time, Agility Sync supports .NET websites only, hosted on Windows IIS.

What is a Content Sync and Why is it important?

All of your CMS content is stored in the Agility Azure cloud in SQL databases and managed through the Agility Content Manager (manager.agilitycms.com). In order to provide this data to your Agility website, a sync process occurs between the Agility Content Server and the list of your syncing web servers as you have them defined in Agility.

When content is published via the Agility Content Manager a new sync process is initiated and Agility will copy over the published content to all of your active syncing web servers. This content is then saved in the file system of the server in the Agility Content Repository. The location of the Agility Content Repository is configurable via the web.config using the ContentCacheFilePath property in the Agility.Web section.

For the Agility website to function correctly on the server, it must have read/write access to the Agility Content Repository.

How does Agility handle Sync Errors?

The Agility Content Server automatically handles sync errors, keeps track of them, and will automatically re-try the sync until it eventually goes through. Common sync errors include issues accessing web server(s) due to application errors in the website, or intermittent networking issues/timeouts. When the webserver becomes accessible again, Agility will automatically re-sync any pending updates.

Content Sync Architecture

Ultimately, you need content files accessible via the file system in each server in your web farm. There are several ways to accomplish this.

Using PaaS cloud services such as Azure App Service? Please see our article on Hosting in Azure App Service.

If you only had one server, this is simple as you just need to sync to that single server and can be accomplished by creating a single entry in the syncing web servers list. This may be sufficient for a dev or qa site but a single instance is NOT recommended for production websites. Agility highly recommends using at least two server instances in your web farms for redundancy.

Let's look at the different ways you can sync content to multiple instances:

1. Single Instance Sync - Only sync to a single server, and then have the other servers in the web farm run a file comparison on the Content Repository on the syncing server. This can be accomplished using services such as robo copy. In this setup, the syncing web server must be added to the list of syncing web servers in Agility and able to be individually addressed by domain name, IP or port. This is to ensure the sync requests always go to one server.
2. Single Instance Sync (Dedicated) - Only sync to a single dedicated server which has a deployed version of the Agility Website, can receive and process sync requests but is not ultimately responsible for serving web requests (i.e. no in the load balancer). This enforces a separation of concerns and you don't have computing resources split between syncing and serving web requests. Other servers in the web farm run a file comparison on the Content Repository on the syncing server. This can be accomplished using services such as robo copy. In this setup, the syncing web server must be added to the list of syncing web servers in Agility and able to be individually addressed by domain name, IP or port. This is to ensure the sync requests always go to one server.
3. Multi-Instance Sync - For each web server in your load balancer, add it to the list of syncing web servers. This means that each web server is responsible for syncing its own content files. Each server must able to be individually addressed by domain name, IP or port. This setup is not recommended if you have more than 2 web servers. The more syncing web servers you have, the more resources are consumed by your Agility Instance database to query and sync content and longer it will take to publish/sync content. 

Stateful VMs vs Stateless VMs

The content files that are synced must be stored in a stateful location. The Agility Content Server (which handles sync) keeps its own record of files that have been synced to each web server. Therefore, if you were to delete the content files on the synced web server, Agility CMS wouldn't be aware of this and would still assume you have all the latest synced content files. Deleting your content files will cause errors in production, as content will not be available to your website.

While you could still have stateless VMs powering your website, they would need to copy content from the stateful location where your synced content files are prior to coming online and serving web requests.