DevOps with Sitecore in the cloud - sugcon.eu · DevOps with Sitecore in the cloud Nick Hills...
Transcript of 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)
The easyJet approach
During the sale period we’ve doubled capacity by running both blue and green stacks. We’ve also
temporarily increased the server capacities.
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved.
• 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
The easyJet approach
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?
The easyJet approach
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
The easyJet approach
We run across 2 AWS accounts. You need to be granted production specific keys and actively select the
production account within our tools.
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved. 18
• 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?
The easyJet approach
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
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved. 19
• 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
The easyJet approach
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.
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved.
• 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
The easyJet approach
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
The easyJet approach
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
AWS - CloudFormation
Key features:
• Parameters
• Mappings
• Conditions
• Resources
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved.
Azure – Resource Templates
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved.
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
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved.
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
© 2017 Sitecore User Group Conference Europe and its respective speakers. All rights reserved. 28
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
The easyJet approach
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#
The easyJet approach
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