Plone Hosting:A Panel Discussion

2014 Plone ConferenceBristol

Friday, October 31, 14

Steve McMahonAnsible

Goals:

• Repeatable, fast provisioning of servers/VMs

• Never change configuration via login

Friday, October 31, 14

Steve McMahonAnsible

Pros:

• Uses SSH for transport - no client requirements beyond SSH

• Easy to understand, extend

• Good documentation, example playbooks

• Uses YAML for playbooks, written in Python

• Ansible Galaxy

• Plays well with Vagrant

Friday, October 31, 14

Steve McMahonAnsible

Cons:

• Ansible Tower, the mass management tool, is commercial

• Server or VM is smallest unit of configuration

Friday, October 31, 14

Cris EwingAWS OpsWorks

• Provides a way to reliably and repeatably provision clusters of EC2 servers (aka Stacks) using Chef

• Uses standard recipes as much as possible

• Intended for fully automated production deployments: includes features like automated disk snapshotting, server monitoring and support for high availability configurations

Friday, October 31, 14

Cris EwingAWS OpsWorks

Pros:

• Centralized server management via a nice Web UI with no additional costs

• Allows defining layers of functionality which may be deployed across multiple server instances

• Automated discovery of services within a cluster of instances (e.g. new instances with ZEO Clients being discovered by a load balancing layer)

• Most configuration can be done via JSON settings or simple web forms (including managing Git SSH and HTTP SSL keys)

• Uses Chef and Berkshelf: many open source recipes are available for extending the platform

Friday, October 31, 14

Cris EwingAWS OpsWorks

More Pros:

• Chef recipes for deploying Plone can be used outside of AWS

• Easy to clone a multi-instance production stack to make a single instance staging/development stack and vice versa

• OpsWorks and Chef documentation is extensive and comprehensive (perhaps to the point of being intimidating)

• OpsWorks is a relatively new service and has been getting new and useful features added frequently

Friday, October 31, 14

Cris EwingAWS OpsWorks

Cons:

• AWS/EC2 only

• Uses Chef: extending functionality may require writing custom Chef/Ruby code (yuck)

• Developing and testing custom recipes (using Vagrant) tends to be time-consuming and un-fun

• Provisioning new instances can take some time (15 - 45 minutes): neither EC2 nor chef nor buildout are very fast in that regard

• Current implementation expects a particular buildout structure for deploying Plone in a horizontally scalable manner

Friday, October 31, 14

Cris EwingAWS OpsWorks

https://github.com/alecpm/opsworks-web-python

Thanks to Alec Mitchell with help from David Glick, Carlos de la Guardia, Cris Ewing

Friday, October 31, 14

Sven StrackNix, Docker, OpenVZ

I don’t believe in “Devops”

Friday, October 31, 14

Sven StrackOpenVZ

• Live migrations

• Full vps

• Limiting kernel memory

• Disk usage

• Ploop is a disk loopback block device, not unlike loop but with many features like dynamic resize, snapshots, backups etc. - the main idea is to put container filesystem in a file\

Friday, October 31, 14

Sven StrackOpenVZ

Cons:

• Works better with custom OpenVZ kernel

Friday, October 31, 14

Sven StrackDocker

• Put a process in a container

• Not a VM/VPS

• Fast

• Good for demo stuff and throw away

• Good for simple easy hosting

• Linking of containers

Friday, October 31, 14

Sven StrackDocker

Cons:

• Debugging can be hard

• Building a 'proper image' can be hard

• Linking containers together, creates lots of bottlenecks

Friday, October 31, 14

Sven StrackNix

• Reliable: really hard to break packages

• Reproducible: Nix builds packages in isolation from each other. This ensures that they are reproducible and don’t have undeclared dependencies, so if a package works on one machine, it will also work on another.

• Portable: Nix runs on Linux, Mac OS X and other systems. Nixpkgs, the Nix Packages collection, contains thousands of packages, many pre-compiled.

Friday, October 31, 14

Sven StrackNix

Cons:

• Small community (slowly growing)

• Bad docs (slowly getting better)

Cool kid:

• nix in docker works like a charm

Friday, October 31, 14

Nejc ZupanHeroku

Pros:

• Fully managed stack, you can focus on delivering

• Backend, logging, search, email, auth, geo, etc. services are a click away

• Forces best practices

• Very generous free tier (unlimited one-dyno apps for unlimited time)

• One-click app and db rollbacks

• Easy to do continuous delivery

Friday, October 31, 14

Nejc ZupanHeroku

Cons:

• No persistent filesystem (only a drawback for the Plone ecosystem)

• Forces best practices (sometimes you are in a hurry)

• Can get expensive when you breach the free tier

Friday, October 31, 14

Nate AunePaaS Providers

Pros:

• Easy to get started

• Don't need to understand the complexities of server admin

• Many PaaS can auto-scale as traffic increases

Friday, October 31, 14

Nate AunePaaS Providers

Cons:

• Persistence of disk files (ZODB) can sometimes be an issue

• No real insight into mechanics of infrastructure if forensic debugging is needed

• Short timeouts windows can be a problem for long-running buildout

Friday, October 31, 14

Nate AunePaaS Providers

Plone on Dotcloud (by David Bain aka pigeonflight)

https://github.com/pigeonflight/stack-python-plone

Plone on Redhat's OpenShift (by Izhar Firdaus aka kagesenshi)

http://blog.kagesenshi.org/2012/07/plone-on-openshift-quickstart-using-diy.html

Plone on Heroku

https://github.com/niteoweb/heroku-buildpack-plone

Friday, October 31, 14

QuestionsDiscussion

Friday, October 31, 14