The document summarizes a panel discussion on Plone hosting at the 2014 Plone Conference, highlighting various hosting solutions including Ansible, AWS OpsWorks, Docker, Nix, Heroku, and PaaS providers. Each solution is evaluated with pros and cons, focusing on aspects like ease of use, configuration management, and automation capabilities. The discussion concludes with a Q&A session, inviting further inquiries on the topic.

1. Plone Hosting:
A Panel Discussion
2014 Plone Conference
Bristol
Friday, October 31, 14

2. Steve McMahon
Ansible
Goals:
• Repeatable, fast provisioning of servers/
VMs
• Never change configuration via login
Friday, October 31, 14

3. Steve McMahon
Ansible
Pros:
• Uses SSH for transport - no client requirements
beyond SSH
• Easy to understand, extend
• Good documentation, example playbooks
• UsesYAML for playbooks, written in Python
• Ansible Galaxy
• Plays well withVagrant
Friday, October 31, 14

4. Steve McMahon
Ansible
Cons:
• Ansible Tower, the mass management
tool, is commercial
• Server orVM is smallest unit of
configuration
Friday, October 31, 14

5. Cris Ewing
AWS 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

6. Cris Ewing
AWS 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

7. Cris Ewing
AWS 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

8. Cris Ewing
AWS OpsWorks
Cons:
• AWS/EC2 only
• Uses Chef: extending functionality may require writing custom
Chef/Ruby code (yuck)
• Developing and testing custom recipes (usingVagrant) 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

9. Cris Ewing
AWS 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

10. Sven Strack
Nix, Docker, OpenVZ
I don’t believe in
“Devops”
Friday, October 31, 14

11. Sven Strack
OpenVZ
• 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

12. Sven Strack
OpenVZ
Cons:
• Works better with custom OpenVZ
kernel
Friday, October 31, 14

13. Sven Strack
Docker
• Put a process in a container
• Not aVM/VPS
• Fast
• Good for demo stuff and throw away
• Good for simple easy hosting
• Linking of containers
Friday, October 31, 14

14. Sven Strack
Docker
Cons:
• Debugging can be hard
• Building a 'proper image' can be hard
• Linking containers together, creates lots
of bottlenecks
Friday, October 31, 14

15. Sven Strack
Nix
• 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

16. Sven Strack
Nix
Cons:
• Small community (slowly growing)
• Bad docs (slowly getting better)
Cool kid:
• nix in docker works like a charm
Friday, October 31, 14

17. Nejc Zupan
Heroku
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

18. Nejc Zupan
Heroku
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

19. Nate Aune
PaaS 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

20. Nate Aune
PaaS 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

21. Nate Aune
PaaS 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

22. Questions
Discussion
Friday, October 31, 14