Rule #1: IaaS != PaaS
Virtual machines : Application is not necessarily 1:1
Rule #2: PaaS is not a silver bullet
Great for Self-service deployment of applications, varied volatile workloads (development, testing, scale-up/out), with tightly constrained application rules — which implies standardized deployments from template.
Rule #3: PaaS is about developers — AND OPERATIONS!!!!
Operations becomes about capacity planning, not ticket-drive activities.
Rule #4: Be ready to learn
Developers want languages variety, scaling models, integration models — and they want it automagically
Operations want multi-tenancy, familiar installation, and sane configurations — all reproducible.
What is an application?
Runtime (OpenShift cartridges)
Code (One Git repository per application)
Creating an App
The rhc tools are used to create a namespace (domain), then an application space which includes a name and cartridge type, and push the code.
What do you get from public OpenShift?
A slice of the server, a private Git repository, deployment access.
The PaaS service is comprised of a Broker (director front-end, RESTful) and Nodes. Each node has multiple “gears” (containers secured with SELinux, constrained with cgroups, and isolated with Kernel namespaces and Bind Mounts).
Custom DNS plugins, auth plugs, security policies, and community cartridges. Quick-start frameworks can be offered to community too.
LXC and SELinux are the future for isolating and securing OpenShift…
… but right now, there are a many moving parts being used to provide isolation and security.
PaaS demans a new security model
DAC just won’t cut-it, too complicated for PaaS. MAC (SELinux!) is necessary.
Step 1 – Unlearn this (and embrace SELinux)!
Step 2 – Learn the ‘Z’ (to see SELinux contexts)
ls -lZ ps -efZ
(Review of SELinux contexts and syntax provided)
Demo – deployment of WordPress to OpenShift, in a VirtualBox LiveCD
The OpenShift QuickStart is available here: https://github.com/openshift/wordpress-example