This topic describes how to set up an Episerver CMS site to run on Amazon Elastic Beanstalk. Most of the topic also should apply to Amazon CloudFormation. The example creates an Alloy sample site from the Episerver Visual Studio plug-in, but you can apply most steps to sites created in other ways. The AWS (Amazon Web Services) Management Console requires an account with login details.
In this topic
The following image illustrates a CMS website running in an Elastic beanstalk environment with multiple instances. The website instances share the same Amazon RDS (Relational Database Service) SQL instance, and the S3 storage in Amazon that stores binary file data in the cloud environment. The sites are load-balanced, and the SNS (Simple Notification Service)/SQS (Simple Queue Service) message queues manage events between the CMS websites.
Elastic scaling lets you increase or reduce the number of CMS sites from the Elastic Beanstalk administration interface in the AWS management console.
When you use Amazon Elastic Beanstalk as described in this topic, you should install add-ons on the machine locally and then deploy to Amazon together with the application because when you install an add-on, it is present only on the instance where it is installed; it is not present on other instances of the site (in case you configure elastic scaling).
In this example, you create resources manually from the AWS Management console. Other options are to create the resources from Visual Studio using the AWS Toolkit (see http://aws.amazon.com/visualstudio/), or to define the resources in a cloudformation template and provision the resources through the template.
When you create resources in Amazon AWS, make sure you select the correct region in the upper right corner so your resources are located in a data center closest to your main users.
Tip: Consider creating two instances of each resource (for example, RDS instance, Topic, S3 Bucket) or use two different accounts, one for development and one for production, to make it easy to switch between them simply by changing the configuration.
The example in this topic shows you how to create an Elastic Beanstalk instance while deploying the code to Amazon from AWS toolkit. You can also create the Elastic Beanstalk application from the AWS management console and then deploy against that application. If you do, optionally create the RDS database instance while you create the application. (However, to connect to it from your local machine, you need to add an inbound rule to the created security group that allows connection from your machine).
When running on Amazon, media (such as images) should be stored in the S3 storage to enable elastic scaling. You do not need to explicitly create the S3 bucket. The Amazon BLOB provider for CMS creates one if it does not exist.
To create a S3 storage account manually:
To scale the site to run on several instances, set up an SNS Topic in Amazon to handle messages between the site instances. You do not need to explicitly create the SNS topic. The Amazon Event provider for CMS creates one if it does not exist.
To create an SNS topic manually:
Create a new database in the RDS database instance:
If you plan to use workflows on your site:
If you need persistence of workflow instances (if you plan to use workflows on the site), then install the workflow schemas to the site. Install SqlPersistenceService_Schema.sql and SqlPersistenceService_Logic.sql from <windir>\Microsoft.NET\Framework64\v4.0.30319\SQL\en.
Note: If you get a <user> does not have permission to run DBCC TRACEON error, you can safely ignore it.
If you do not plan to use workflows:
Remove the Workflow persistence service from web.config; that is, the entry with type SqlWorkflowPersistenceService under workflowRuntime/Services.
Removal of workflow persistance configuration in web.config:
<workflowRuntime EnablePerformanceCounters="false"> <Services> <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" maxSimultaneousWorkflows="5" /> <add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowCommitWorkBatchService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <strong>REMOVE THIS: <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UnloadOnIdle="true" /></strong> </Services> </workflowRuntime>
Disable workflows completely by adding the disabled attribute to the workflowSettings element.
<episerver> (..) <workflowSettings disabled="true" /> (..) </episerver>
Add the following block to the episerver.framework section in web.config to map BLOB and event providers to Amazon:
<blob defaultProvider="s3blobs"> <providers> <add name="s3blobs" type="EPiServer.Amazon.Blobs.AmazonBlobProvider,EPiServer.Amazon" accessKey="<your accesskey>" secretKey="<your secretkey>" region="<region code>" bucket="mysitemedia" /> </providers> </blob> <event defaultProvider="amazonevents"> <providers> <add name="amazonevents" type="EPiServer.Amazon.Events.AmazonEventProvider,EPiServer.Amazon" profileName="<your profile name>" accessKey="<your accesskey>" secretKey="<your secretkey>" region="<region code>" topic="mysiteevents" disableAutoCleanupQueue="true|false" maxSendThreads="1" maxEventThreads="1" /> </providers> </event>
Under the connectionStrings section, change the connection string EPiServerDB to the connection string from AWS Management console (see Create a new database). Remember to keep the setting MultipleActiveResultSets=true.
Install AWSTools to deploy from Visual Studio. AWSDeploy uses MSDeploy to package the application and includes only the files in the project and bin folder by default.
<DeployIisAppPath>Default Web Site</DeployIisAppPath>
During initialization, a bootstrap feature for content lets you import a package and create a site if you have an export package located at [SolutionDir]\App_Data\DefaultSiteContent.episerverdata. Bootstrap occurs only if the site does not have any previous content.
For cloud deployment, you should first publish the project to the cloud environment before starting a local site configured against the cloud database. Then the bootstrap occurs in the cloud environment, which is much faster (because the site and database are likely in same data center) and also sets the SiteUrl to the cloud URL for the site.
You also can transfer data to an Episerver site running on Amazon with the Episerver CMS export/import functionality. Export the start page from your local site and database and import on the site running in Amazon before continuing to the next step.
You need to create a user that has access to the admin and edit views to be able to log in to the site on Amazon.
Use a scalable search solution, such as EPiServer.Find, when you host in Amazon. EPiServer.Find is a hosted service that you connect to, and it works the same way as when your site runs on-premises.
If you want to use the built-in EPiServer.Search when running in Amazon, create a separate virtual machine (an EC2 instance) and then install Episerver Search on that instance. Then configure the application to use the search service running on the EC2 instance.
The core parts of Episerver CMS do not use Session State but some functionality does, such as some of the Visitor Groups criteria. To enable session state, use the sticky session feature (also known as session affinity) in the Elastic Load Balancer to make sure requests from a user reach the same server combined with the default in-memory session state provider. You can also enable better scaling using an optimized provider for Amazon, such as the session provider for Amazon DynamoDB.
Last updated: Oct 26, 2016