2. @pythondj
noun ˈpī-ˌthän, -thən+ˈdē-ˌjā
Python
a widely used generalpurpose, high-level
programming
............language
Snake
a very large snake that kills
the animals it eats by
wrapping itself around them
+ short for “Django”
a high-level Python Web
framework that encourages
rapid development & clean
design
+ Disk Jockey
a person who plays popular
recorded music on the radio or
at a party or nightclub
A Snake Charmer
Red Hat's OpenShift Origin Community Manager
3. Agenda { I'll talk (fast) about...}
Learn a bit about PaaS
Understand OpenShift Architecture
Learn how to deploy OpenShift anywhere
3
by
4. Today's Assumptions
You are an ops person
So you can use command line, git, and ssh
You can use Puppet, Ansible, Chef or CFEngine...
You want to see what is involved in running a PaaS
You will ask questions
4
by
6. OpenShift Origin
The upstream project that both OpenShift Online and
OpenShift Enterprise are based on.
• Apache 2.0 Licensed
• All code hosted on GitHub (https://github.com/openshift/)
• Available as:
•
•
Source (tarballs and git repo)
RPMs
• IRC: #openshift-dev on irc.freenode.net
• Mailing lists: http://lists.openshift.redhat.com/openshiftmm/listinfo
• Forums: https://www.openshift.com/forums/openshift
• Stack Overflow: http://stackoverflow.com/questions/tagged/openshift
• Public backlog: https://trello.com/openshift
6
by
7. Origin Release 3
Fedora 19 or RHEL 6.x or CentOS 6.5
Get up and running
Vagrant
Puppet
Comprehensive guide
Ansible
Heat
http://openshift.github.io
7
7
8.
9. Why I love PaaS: It's Magic
SaaS/Applications Layer
Infrastructure Layer
9
16. Infrastructure as a Service gives you
•
Network, storage & compute as an on-demand service
•
Basically, servers in the cloud
•
You’re still on the hook to configure & manage the cloud & stack
“How do I use this?”
16
17. Software as a Service gives you
•
An on-demand application
•
Nothing to install or configure
“This is all my customers and users care about!”
17
18. Platform as a Service delivers
•
Application run-time environment in the cloud
•
Configures & manages both the cloud & stack for your
application
“The cloud is now useful!”
18
21. OpenShift is a PaaS on top of…
Infrastructure
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
21
by
22. The Foundation of OpenShift is
Red Hat Enterprise Linux
OpenShift is Built on Instances of
Red Hat Enterprise Linux (RHEL)
RHEL
RHEL
RHEL
RHEL
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
22
by
24. An OpenShift Broker Manages
Multiple OpenShift Nodes
Nodes are where User Applications live.
Brokers keep OpenShift running.
RHEL
RHEL
RHEL
RHEL
Brokers
Node
Node
Node
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
24
by
25. Unique SELinux Approach Enables
Security and Multi-tenancy
SELinux Policies securely subdivide
the Node instances.
RHEL
Broker
RHEL
Node
RHEL
Node
Node
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
25
by
26. OpenShift User Applications
Run in OpenShift Gears
OpenShift GEARS represent secure
containers in RHEL
RHEL
Broker
RHEL
Node
RHEL
Node
Node
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
26
by
27. Developer
Workflow
Web Console
Eclipse IDE
Cmd Line
OpenShift
Gear
RHEL
Broker
A Developer creates a
new application
OpenShift creates a
GEAR
RHEL
Node
RHEL
Node
Node
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
27
by
28. OpenShift Automates
Gear Configuration
via Cartridges
JBoss
RHEL
Broker
MySQL
Web Console
Eclipse IDE
Cmd Line
CARTRIDGES are how
OpenShift installs
Languages & Middleware
RHEL
Node
RHEL
Node
Node
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
28
by
29. OpenShift Cartridge System
Enables User-Built Cartridges
Java
MySQL
PHP
Postgres
Python
Etc.
CUSTOM
Ruby
Etc.
OpenShift Default
Cartridges
Developers can add custom
language, data-store, or
middleware with with a custom
Cartridge.
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
29
by
30. Now, Code and Push
Git Protocol / ssh
Code
Git
Repo
MySQL
JBoss
RHEL
Broker
Push
Developer pushes
application code via
GIT source code
management system
RHEL
Node
RHEL
Node
Node
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
30
by
31. OpenShift Automates
Build, Test, Publish
Maven
JBoss
(Builds)
Code
Jenkins
Git
Repo
(CI)
RHEL
Broker
Apache
(HTTP)
MySQL
RHEL
Node
RHEL
Node
Node
AWS / CloudForms / OpenStack (IaaS) / RHEV (Virt) / Bare Metal
31
by
47. Learn more about OpenShift & Heat:
●
Users, testers and developers wanted!
–
Connect via IRC on #heat@freenode
–
Check out the repositories:
–
https://github.com/openstack/heat
https://github.com/openstack/heat-templates
Read the Heat Documentation:
http://docs.openstack.org/developer/heat
–
47
48. Learn more about OpenShift:
●
Users, testers and developers wanted!
–
Connect via IRC on #openshift-dev@freenode
–
Check out the repositories:
–
https://github.com/openshift
Read the OpenShift Documentation:
http://openshift.github.io
48
From OpenShift Origin to OpenShift Online, we will discuss the processes and environments used to make this all possible. We will show how OpenShift Online consumed OpenShift Origin to offer the hosted Online version that users can utilize for free in the cloud. We will also talk about how OpenShift Online contributes back to OpenShift Origin as the main contributor to Origin. Finally, and for a large portion of the presentation we will be talking about how all this comes together in a walk through of the environments used for OpenShift Online DevOps as well as the process by which we bring code to production.
OpenShift Origin is the name of the public open source project for the PaaS management and automation system that has been running OpenShift.com since April 2011.
OpenShift Origin is licensed under the Apache 2.0 license which makes it “business friendly” and it is available as Source code, RPMs, and a .ISO or LiveCD for standing up an Origin PaaS instance on your PC.
OpenShift Origin has a vibrant user community accessible via IRC, Email, and online discussion forums.
For Red Hat, OpenShift Origin is the “Upstream” project for both OpenShift Enterprise and OpenShift OnLine. This means that Red Hat takes the stable builds of the open source project and tests and packages them as a commercially supported offering.
OpenShift Origin is to OpenShift Enterprise as Fedora is to RHEL.
<next slide>
For either the Entrepreneurial or the Enterprise Developer, PaaS is the way of the future.
Let's take a quick look at the before-and-after of the application development process.
In the old days, when you wanted to build a new app (or were assigned a project to build a new app), you had to jump through a million hoops to get it up and running. Everything from ordering hardware, to installing middleware, to tuning and testing every facet of the development environment.
With PaaS, life is much easier. You have an idea for an application? You just start writing the code and let OpenShift PaaS handle the rest.
Write your code, Push to OpenShift, Test with Jenkins, and Deploy when ready!
Even Gartner knows that PaaS will be the way of the future for application development.
<number>
So, what you need is the ease of use and access of a SaaS application, but you need it with your purpose-built, mission-critical, applications.
PaaS gives you just that. It allows you to quickly and easily build the application that YOU need. Whether this is for your group, your enterprise, or your next BIG IDEA, you can build it and launch your specific code on a PaaS and not have to deal with the underlying infrastructure, middleware, and management headaches.
Because of the built-in auto-scaling and elasticity provided by the PaaS infrastructure, PaaS's are ideal for modern data-hungry Big Data, Mobile, and Social applications.
With a PaaS, you can focus on what you should be focused on... your application code.
And let the Cloud provide what it is suppose to: Ease, Scale and Power
<number>
So, what you need is the ease of use and access of a SaaS application, but you need it with your purpose-built, mission-critical, applications.
PaaS gives you just that. It allows you to quickly and easily build the application that YOU need. Whether this is for your group, your enterprise, or your next BIG IDEA, you can build it and launch your specific code on a PaaS and not have to deal with the underlying infrastructure, middleware, and management headaches.
Because of the built-in auto-scaling and elasticity provided by the PaaS infrastructure, PaaS's are ideal for modern data-hungry Big Data, Mobile, and Social applications.
With a PaaS, you can focus on what you should be focused on... your application code.
And let the Cloud provide what it is suppose to: Ease, Scale and Power
<number>
So, what you need is the ease of use and access of a SaaS application, but you need it with your purpose-built, mission-critical, applications.
PaaS gives you just that. It allows you to quickly and easily build the application that YOU need. Whether this is for your group, your enterprise, or your next BIG IDEA, you can build it and launch your specific code on a PaaS and not have to deal with the underlying infrastructure, middleware, and management headaches.
Because of the built-in auto-scaling and elasticity provided by the PaaS infrastructure, PaaS's are ideal for modern data-hungry Big Data, Mobile, and Social applications.
With a PaaS, you can focus on what you should be focused on... your application code.
And let the Cloud provide what it is suppose to: Ease, Scale and Power
Platform agnostic
SELinux
As we talk about the OpenShift architecture and how it works, keep in mind that Red Hat has been operating the OpenShift.com public cloud PaaS service for 18 months.
During this time we have designed, built, refined and tuned the architecture so that the OpenShift service today has over 150,000 Live applications running on it. We have seen and solved many challenges related to building and running a PaaS that will enable Developers to work efficiently at massive scale.
<Click for next slide>
OpenShift, as a Platform-as-a-Service, is a software platform that runs on top of Infrastucture.
That is, OpenShift needs a place to run. The good news is that that infrastructure can be provisioned for OpenShift via whatever Infrastructure provisioning mechanism is most convenient for the customer.
OpenShift can run on everything from physical servers, to virtualized servers, to an Infrastructure-as-a-Service offering (either in a public or private cloud), or even on an Open Hybrid Cloud managed by Red Hat’s CloudForms technology.
<next slide>
OpenShift can run on any Infrastructure because all OpenShift really needs is instances of Red Hat Enterprise Linux.
OpenShift is built on top of RHEL and Red Hat has leveraged its deep technical experience in the Linux kernel to take advantage of some key Linux features within the OpenShift PaaS layer that make it more efficient and easier to manage.
So, wherever you can deploy RHEL, you can also deploy OpenShift and take advantage of the scalability and automation of PaaS.
<next slide>
OpenShift utilizes the RHEL instances and delegates them to one of two different functions.
Some of the instances are designated as OpenShift Brokers which serve as the control plane, or management system, for the PaaS. Brokers can be configured in a redundant configuration for HA and failover. Utilizing messaging and automation technologies, the Brokers keep the PaaS running.
The rest of the RHEL instances are designated as OpenShift Nodes and these instances are where user applications will reside.
<next slide>
One of the unique features of OpenShift is that within the Nodes, OpenShift provides secure, fine-grained, multi-tenancy by leveraging powerful Red Hat Enterprise Linux subsystems such as SELinux (Security Enhanced Linux), CGroups (Control Groups), and NameSpaces to divide up the RHEL instances into slices that can be dedicated to each user application firewalled off from each other.
<next slide>
These slices of RHEL are called OpenShift Gears. OpenShift Gears are super-secure and highly efficient containers that host user applications in OpenShift. To the user, the Gear appears like an instance of RHEL. They can even SSH in to the gear. They can see their processes, their memory, and their filesystem, but they are prevented from seeing or impacting anyone else’s environment or the system as a whole.
SELinux was built by Red Hat in conjunction with the National Security Agency in order to support some of their strict requirements. It is a “Deny everything, and allow by exception” policy subsystem that allows very strict control of what processes and users can do. In OpenShift, SELinux policies are used to enable hi security in a container based multitenant environment.
Likewise, Control Groups are used to carefully control what resources an OpenShift Gear is able to consume. Cgroups allow Gears to consume CPU and RAM but also limits that consumption based on configurable policies.
And finally NameSpaces are used to allow each Gear to have it’s own file system complete with the system directories that it may need including /tmp, /var, and others.
Red Hat has been able to leverage these technologies to build a secure and yet efficient multi-tenant PaaS because Red Hat has incredible knowledge with respect to the Operating System underneath, Red Hat Enterprise Linux. With some of the best linux kernel coders in the world, Red Hat has used these smarts to build a cloud Platform-as-a-Service on top of the industry leading enterprise Linux operating system.
OpenShift Gears represent the resulting benefit of leveraging this wealth of knowledge in the Operating System Platform to build a Cloud Application Platform that is both super-secure and highly efficient.
<Optional statements>
The OpenShift Gear-based architecture provides two other key benefits:
Deploying multi-tenancy inside of RHEL Nodes allows many, many applications to be maintained by deploying maintenance to a much smaller set of RHEL Operating System instances. The Sys Admins job becomes much easier when they only need to patch and perform maintenance on a small number of nodes instead of 1000s of Virtual Machine instances (as would be the case with VM-based multi-tenancy).
OpenShift also has the ability to “Idle” Gears that are not actively being used. In this situation the Broker will take a snapshot of an application Gear and write it to disk to take it out of RAM. Network connections are maintained so when an application URL is requested, the Gear will be “un-idled” and able to service the request quickly. This Idling technology allows many more Gears to be supported within one instance of RHEL because not all Gears will be active at the same time. Implemented for the OpenShift hosted service, this Idling capability is also beneficial to the enterprise that wants to optimize resource consumption as much as possible.
<next slide>
So, let’s take a look at how a Developer would use OpenShift once the Brokers and Nodes are up and running.
When a Developer wants to create a new application, the first thing to do is to instantiate a container for the application language runtime and middleware in the PaaS. With OpenShift the Developer can do this using their choice of interface. They can work from the command line via OpenShift’s RHC command-line tool set, they can work from the OpenShift Web Console interface, or they can work from their Eclipse-based IDE.
When the Developer gives the command to create a new application, the OpenShift Broker looks at the Nodes, determines the best place to create the application based on resources and/or policy and then it creates the Gear for the user’s application and provides the connectivity information back to the user.
<next slide>
As part of the application creation process, the user specifies what Language they want to program in and what middleware or database services they want to use. OpenShift installs these via OpenShift Cartridges. The OpenShift Cartridge technology is an extensible mechanism for providing application development services to the Developer.
When database cartridges are installed in a second gear (the default configuration, BTW), OpenShift will automatically wire the two gears together on the network and it will automatically create the new datasource definition within the Jboss configuration, for example.
<next slide>
OpenShift provides built-in Cartridges for most of the popular programming languages including Java, Ruby, Node.JS, PHP, Python, and Perl along with the many Frameworks that can be used with these languages. With OpenShift, Developers can pick the language that either is best suited to solve the problem at hand, or is the one that they are most comfortable with. Our goal is to allow Developers to work the way they want to work.
OpenShift also provides MySQL and Postgres as relational database options and MongoDB as a NoSQL alternative.
In addition to these built-in capabilities OpenShift also provides the ability to create Custom Cartridges so that a user can add their own desired middleware service.
<next slide>
So, once the Gear is fully configured and Cartridges are installed, the Developer can then begin coding. As code is completed, the Developer pushes the code to OpenShift via the Git protocol. Git is a popular Source Code Control system used in the Open Source development world. A Git repository is created in the Gear and the Developer uses the Git “Push” command, or the IDE, to push the latest code into the repository over an SSH encrypted channel using the Git protocol.
Depending on the programming language, once the code is pushed, the application will show the updates immediately. This accelerates the Application Development Lifecycle by providing immediate feedback on application changes.
<next slide>
OpenShift also includes tools to support complex and sophisticated application architecture and lifecycle requirements.
OpenShift has Maven built-in for Build Management. Maven automates the process of compiling and building complex application architectures. Maven also serves as a dependency management system by automatically pulling down libraries required for a java application. Maven is the new and popular replacement for ANT.
Similarly for dependency management in other languages, OpenShift uses Bundler for Ruby, NPM for Node.JS, etc..
OpenShift also includes Jenkins for Continuous Integration and Testing. With Jenkins Master and Slave servers running within OpenShift, a Developer or Development team can set up a sophisticated Continuous Integration facility so that new code is tested immediately upon check-in. Jenkins is the new and popular replacement for Hudson.
Also, within OpenShift, Apache HTTP Server is used as the front-end Web Server to publish HTTP based applications running within OpenShift.
The point here is that OpenShift, as a Platform-as-a-Service, has all the tools that Developers need today to rapidly develop and deploy applications. OpenShift automates the development lifecycle and abstracts away much of the tedious work that slows Developers down. OpenShift allows Developers to focus on what they are good at… writing code.
<next slide>
And, once the application is launched within the OpenShift PaaS, OpenShift provides the elasticity expected in a Cloud Application Platform by automatically scaling the application as needed to meet demand.
When created, applications can be flagged as “Scalable” (some apps may not want to be scaled). When OpenShift sees this flag, it creates an additional Gear and places an HA-Proxy software load-balancer in front of the application. The HA-Proxy then monitors the incoming traffic to the application. When the number of connections to the application crosses a certain pre-defined threshold, OpenShift will then horizontally scale the application by replicating the application code tier of the application across multiple Gears.
For JBoss applications, OpenShift will scale the application using JBoss Clustering which allows stateful or stateless applications to be scaled gracefully. For Ruby, PHP, Python, and other script-oriented languages, the application will need to be designed for stateless scaling where the application container is replicated across multiple gears. The Database tier is not scaled in OpenShift today.
Automatic application scaling is a feature that is unique to OpenShift among the popular PaaS offerings that are out there.
Automatic scaling of production applications is another example of how OpenShift applies automation technologies and a cloud architecture to make life better for both IT Operations and Development.
<next slide>
The advances that OpenShift provides in the automation of both the Application Development Lifecycle and the management and hosting of applications allow OpenShift help IT organizations take a step in the direction of implementing the IT Factory business model in order to increase efficiency and velocity.
OpenShift becomes the Assembly Line for IT Services and Applications.
<Next slide>
OpenShift allows Developers to work the way they want to work, whether it is from the command line, through a web browser or via their IDE.
OpenShift makes this possible because all interaction with OpenShift happens over a set RESTful APIs. This allows the system to be controlled from any mechanism that can implement the API set.
<next slide>
OpenShift allows Developers to work the way they want to work, whether it is from the command line, through a web browser or via their IDE.
OpenShift makes this possible because all interaction with OpenShift happens over a set RESTful APIs. This allows the system to be controlled from any mechanism that can implement the API set.
<next slide>
A bit about Heat: The Heat API implements the AWS Cloud Formations API. This API provides a rest interface for creating composite VMs called Stacks from template files. The goal of the software is to be able to accurately launch AWS CloudFormation Stacks on OpenStack. We will also enable good quality high availability based upon the technologies we created in Pacemaker Cloud including escalation.
Thank you very much for your time today. I’m happy to take any final questions that you may have.
<end>