devops with sitecore in the cloud - sugcon.eu · devops with sitecore in the cloud nick hills...

DevOps with Sitecore in the cloud

Nick Hills – True Clarity

May 19th, 2017

#sugcon

df

© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved.

• Why Sitecore developers are good at DevOps

• Templated deployments

• Scripted examples

• But no

What will I find out?

HOWEVER FEAR NOT

There are some gifs, and a fair bit of Sitecore

• Teamcity or other CI tools, Octopus or other deployment tools• Habitat or helix

Some background

Over the last 2 years we’ve worked

closely with easyJet to migrate

their Sitecore site into AWS

We run 12 Sitecore instances in

order to support hundreds of TPS

and millions of £££ of transactions

per day

3

The start of the journey

Life as a .net developer

A word of caution with the tools you choose!

Developers tend to like shiny new things

Don’t get carried away by jumping on the

newest trends

Why are developers a good choice to own your project’s DevOps ?

They understand the code, the features and how Sitecore works*

*If this isn’t the case• http://www.sitecore.net/en/services-and-support/training• http://www.jobcentreguide.co.uk

Sitecore in the wild

In it’s simplest form you need

• IIS backed webserver(s) & SQL server

As you add more features

• Mongo

• SOLR

© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved. 8

Where do we start? There is too much to learn

VPC’s

Virtual Networks

Elastic Block Storage

Lambda

EC2

Web Roles

RDS

SQL Azure

MSDeploy

Octopus Deploy

Azure functions

Teamcity

Jenkins

AppDynamics

Application Insights

New Relic

MSBuild

Plus a heap more…

Where do we start?There is too much to learn

Start simple, and find the right tooling for the size and requirements of your setup. Sitecore provide quickstart templates for Azure

Some tools require no coding or scripting▪ Note, make sure you keep your tools backed up!

For any kind of repeated process a scripted language e.g. Powershell is your friend

Will your DevOps story ever be complete?

Over time things will change• Extra sites or pages• More, or less servers

The easyJet approach

The migration to AWS from On-Premise hosting has been running for over 2 years. The process is

constantly being iterated and improved.

The Nirvana – A big red button

But which red button do you press

▪ Prod vs UAT vs QA▪ Blue vs Green▪ xDB vs Delivery vs Authoring vs

Processing▪ Region A vs Region B

The tools we use for easyJet

Blue / Green deploymentsAKA Staging / Production deployments in Azure

• These are a great approach for deploying

• If things go wrong you simply don’t swing

users onto your non-live setup

• The reality, you need to plan how to

handle certain scenarios» Database backups and versioning

» Editorial experience and downtime

Blue / Green deploymentsAKA Staging / Production deployments in Azure

• Blue / Green does have other

advantages – more power » If your site is under load you could always create both

green and blue stacks ** (as long as your licence allows

more boxes)


During the sale period we’ve doubled capacity by running both blue and green stacks. We’ve also

temporarily increased the server capacities.


• As you move more into the cloud its key to get a holistic view of your infrastructure

• Azure has tight integration with Application Insights

• Important to know: Code version vs database version vs tool version

Visibility of the moving parts


We use Datadog to aggregate all box statistics. This covers things like CPU, Memory & Disk usage along

with custom stats e.g. ImportCompleted, OrderError & API call times.

All the boxes assume a hands off policy

Anyone can deploy

A key driver has been the simplicity of running a build and deployment

• What happens if the build fails?• How do you handle

InsufficientServerResources?


Anyone in the team can run deployments, including graduate developers. The same process is used in

all environments, production is no different. We can re-spin any pod on demand (this will not

overwrite a running pod!)

Production vs non production

• Make sure it’s not easy to nuke production

or deploy inadvertently

• Add extra safeguards if needs be

» Prompts / Confirmations / Access Management


We run across 2 AWS accounts. You need to be granted production specific keys and actively select the

production account within our tools.


• Personal preference or company policy

• Sitecore are providing Azure templates and deployment scripts with recent versions

• https://github.com/Sitecore/Sitecore-Azure-Quickstart-Templates

Which cloud provider to choose?


Sitecore is hosted within AWS. We use EC2 instances for each delivery pod. A delivery pod is made up

of 2 web boxes and 1 sql box


• Hand over maintenance, replication and resilience concerns to your provider

• The server and licence cost is included in the PAAS SQL cost

PaaS / DBaaS vs IaaS


We host VM’s with Sql server installed and run across 2 regions. AWS does offer an RDS service

however due to support concerns VM’s were preferred.


• As you add more servers and features your bill will go up

• Larger boxes tend to == more $$$

• Make sure the bill payer can cover the cost each month, otherwise the services will stop working

• In AWS, reserved instances can reduce the cost of your hosting

Everything comes at a cost


Everything in non-production gets turned off overnight unless we need environments for things like

automated tests

Creating boxes from scratch takes time

• When requested the cloud provider will have to allocate you kit, assign to an underlying host and then create you boxes

• Larger boxes tend to spin up quicker but cost more $$$

• AWS Containers and Azure Container Service add Docker support


Full Sitecore deployments take roughly 40 minutes. We’ve built a ‘lite’ process to streamline but only

use in QA – this doesn’t create infrastructure every deployment

Templated deployments

e.g. AWS Cloudformation or

Azure Resource Manager

AWS - CloudFormation

Key features:

• Parameters

• Mappings

• Conditions

• Resources


Azure – Resource Templates


Some observations of templated deployments

Pros

• You can source control the templates

• Installing one template can create N entities (boxes, networks etc)

• Deleting one template removes anything it created

Cons

• The templates tend to be pretty verbose

• Parameterizing them can be mucky

• You need to learn the provider specific syntax


Some observations of templated deployments

In the wild (AWS)

• When we create new environments it takes roughly 20 minutes to provision a new windows box

• Any custom installation time runs on top of this

• Auto-scaling is great and can be configured based on a raft of custom parameters

• Note, it will also take time to provision new boxes

• Databases have a limited throughput, scaling your web tier could exceed this


The easyJet deployment process

Blue stack in production

Backup production dbs

Upload to S3

Compile solution

Upload to S3

Compile startup scripts

Upload to S3

Compile Cloud Formation templates

Install templates with parameters from

previous steps

Pull code from S3 Unzip code Run startup scripts Flip DNS to greenPull dbs from S3

and attach

Design with resilience in mind

The cloud is extremely resilient however things can and will go wrong.

A few things we’ve found• Dedicated tenancy instances isolate your

applications• Underlying hosts get patched• Resource availability can fluctuate


All the SQL instances are setup on dedicated tenancy instances. The site is run in two regions and each

pod is isolated into an Availability Zone.

Note. A pod is 2 web servers and 2 SQL servers, one for Sitecore and one for external dbs

Design expecting things to break

Cloud Provider API’s can error unexpectedly

Build resilience into your application• Retry & timeout logic• Circuit Breakers

Polly library provides sync and async toolshttps://github.com/App-vNext/Polly

Cloud functionsAWS Lambda / Azure functions

• Allow you to run code without needing actual boxes

• ‘Serverless’ deployments are becoming more prevalent

• Can be written in JS or C#


We use AWS lambda function to monitor all our backups and alert to Slack if they fail. We also use

them to orchestrate file backups between production and non-production accounts.

Scripted examples

Finally, some code!

Handing over from template installation to Powershell

Download files from cloud storage AWS S3 or Azure blob storage

Install MSI e.g. IIS rewrite module

Start a Windows service

What about Sitecore content?

Packages

Update files

Unicorn

TDS

ANother

Types of ‘content’

• Content owned by content editors• Typically items under /sitecore/content and /sitecore/media library

• Content owned by developers• Typically items

under /sitecore/layout, /sitecore/system and /sitecore/templates

Content changesetsWhy choose one option or tool over another

• How easy is it to build a changeset?• How to source control the changes?• What happens for merge conflicts?• Plus more

https://blog.boro2g.co.uk/migrating-sitecore-content/

Scripted Sitecore changesVia SINJ

https://github.com/tcuk/sinj

A replayable and scripted approach to

Sitecore changes

Updates are as granular or coarse as you

need

Can be run in parallel accross all

publishing targets

Can Sitecore developers do DevOps?

Thank [email protected]

https://blog.boro2g.co.uk

devops with sitecore in the cloud - sugcon.eu · devops with sitecore in the cloud nick hills...

Documents