Plone Hosting: A Panel Discussion
-
Upload
jazkarta-inc -
Category
Technology
-
view
2.183 -
download
2
Transcript of Plone Hosting: A Panel Discussion
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