 Hey, everyone, we're going to give everyone a minute or two else, but a minute or two more to get into the room. Yeah, this is OpenShift and Drupal, a story of true open source collaboration and innovation. So I guess we can start off with some introductions. I'm Stephen Merrill. I'm a director of engineering at Phase 2 Technology. And this is Diane Mueller. And she is the OpenShift community manager. So she manages. We'll talk about some of the different flavors. And I guess before we actually kick off the presentation, how many people here have deployed an app to a platform as a service before? OK, so we've got a fair number of folks. How many people have deployed an app to OpenShift before? OK, how many people have set up OpenShift origin or enterprise behind your own firewall? OK, cool. But it's good to know that we've got some folks who have done this and some folks who are interested to learn, because I think the benefits of this ecosystem can apply to a wide range of folks. And so for the first part, I will hand over the mic and the clicker to Diane to talk about OpenShift itself. And then I'll be talking some more later about specifically working with Drupal on it. All right. Thank you very much, Steve. This is a pleasure to be here at Drupal again. This is my third Drupal con. I've been using Drupal for many, many years, and more than I want to admit. And I'm really pleased to have Phase 2 as our partner to bring Drupal, Drupal 7, Drupal 8, and the different distros of Drupal to OpenShift and make Drupal a first-class citizen on OpenShift. So we're thrilled to be able to be here today at Drupal con Austin. And keeping it weird, we'll make sure we do this. My agenda today, besides the introductions, is to give you a little bit of an overview of what OpenShift is, why it's important to most of your development ecosystems, and how to deploy it, how to deploy an app on it, and some of the usage issues. So to do that, we're going to have to learn a little bit about cloud, servers in the sky kind of thing. There should be a rock star song somewhere, servers in the sky. Learn a little bit about Paz, or Paz, or whatever you want to call or whatever you want to pronounce that acronym. We're going to learn how to deploy Drupal on OpenShift today. I would say we would do it ourselves, but usually we do do it ourselves. And I ask you to deploy it. You can actually do this from your mobile phones. The Wi-Fi here is not that good. So I'm going to ask you not to try this in the room while we're doing it, because it'll slow things down a little. I don't think I'm going to let you take a break, because this is only an hour. We usually do this in about two and a half to three hours. And then I'm going to hand it back over to Steve, who's going to talk about some of the tricks and things that we learned to optimize Drupal on OpenShift, varnish, CDN, all kinds of things with fresh flow, lots of good tricks that we've learned over the years. Then we're going to check out OpenAtrium on OpenShift. And we may, if we have time, do a sneak peek of Drupal 8 on OpenShift. So if we get enough time, we'll see how we do it. So first of all, this is my lovely Drupal OpenAtrium site that is running live. It's origin.openshift.com. It's the community site for OpenShift. I learned a lot about OpenAtrium in the past two or three months from the wonderful people at Phase 2. And I'm really thrilled with it. It's got an amazing collaboration engine under the hood, wonderful, the Penalope pieces that make it very easy for me to deploy different sections of it. It's really, for Drupal 7, it's very responsive on mobile devices. It really is very flexible. So I'm very, very pleased with it. And it's one of those things where at Red Hat, what we like to do is eat our own dog food. And as you see, we eat our own panda food. Rocket Panda is our little logo here. But it allows us to do a lot of things that very well and very easily. And allows me as the community manager for OpenShift to be able to really easily add new functionality and connect other things. Though we have our chat, our blog, our events, documentation, the how-to articles are all in here. And it just seems to have, every time I touch it, I can find a new functionality that I didn't expect to have in it. It's really nice, because I'm used to the vanilla Drupal 7 and 8 now. This is pretty cool. And so it makes me also want to go to the next stage and try OpenPublic, which is another thing we'll talk about a little bit later. But the thing about Red Hat that many of you, you all know that we're an open source company. But we sponsor over 100,000 different projects at Red Hat. So we touch just about every aspect of your life, everything from in the cloud, Centos and Fedora as well. So everything that is up there for our product, commercial size, there's a open source counterpart. So we've got a lot of action going on, a lot of the work around. We're very much into this philosophy of open minds and open source that we share with the folks at phase two. But we're very cognizant of how we touch every aspect. And the folks that are here at DrupalCon, there's probably not one that isn't running something that has some project that Red Hat has resources or supports in some way. Pantheon, for example, is running on Fedora. Aquia is running Gluster for storage. So pretty much all of you here in some way or shape or form touch Red Hat. And it's not just about Linux anymore. It's all kinds of fun stuff. And my project is a community sponsored one. It is a platform as a service. And I can proudly say that we are the upstream feeder for two commercial products at Red Hat. Enterprise version, which allows you to take the open source code that is OpenShift and deploy it on your own machines, on your own servers, on your own cloud or on your own bare metal. We also host OpenShift online. So not only do we eat our own dog food, but 1.5 million other apps are eating our dog food as well. There's a huge amount of people that are running production applications on online. It's Red Hat's cloud, so to speak. And we are very proud of its capabilities and the ability for it to be a production quality cloud for people to host Drupal and a whole plethora of other, cornucopia of other offerings. And I say cornucopia, and I really mean cornucopia. We're here at DrupalCon, I go everywhere. PyCon, DjangoCon, OzCon, AnyCon, GlueCon. Because we are a polyglot platform as a service. So whereas some folks focus just on PHP and Drupal apps and WordPress, we actually support a whole range of things from Java and Jboss to Node.js and Angular.js to Go. You name it. We've got cartridges and quick starts and we're supporting all of that, which is why it's really important for us to come to these community events, find partners like Phase 2 that are experts in Drupal. Because we can't be an expert in everything. We may have 100,000 projects out there that we're sponsoring, but we really want to work closely with the communities that are using our software and using our cloud to make sure that we have the right connectivities. We do, part of my role is to do a lot of cross community collaboration, which means I travel a lot. I'm talking a lot at a lot of different conferences. And if there's something that you find is missing, like we were in the past few months, we got PressFlow up and running on OpenShift because that makes it just smoother deployment and drush and all the other wonderful things that you need for that. So we use a lot of different developer tools. We've got Clip support. We've got some, there's a couple of online IDEs. We have a great command line. Our whole project has a REST API, so if you have something that you want to integrate it into, it's very, very easy to integrate it into your tool set. We're using Jenkins. We've got all that. Tons of packaged apps are available as quick starts and cartridges. Every framework on the planet pretty much is supported. If I tried to put all the little images for this slide in there, you wouldn't be able to read any of them. So I just put a smattering of them. We're doing a lot of work now with Hadoop. We just, someone just submitted a community cartridge and I'll explain what those are in a minute for Hadoop. So there's, we've done a lot of work with Elasticsearch and that community. So it's pretty much everything that you need in the middle. The infrastructure is at the bottom and your application on what you do with Drupal is the SAS layer on top. So I'm gonna step back a little bit, but not too far from the microphone. I just don't know. Well, I guess it doesn't matter how far you step. I'll see, I'm gonna go get a ready person. All right, see if we can get it working. So here, maybe I'll. Yeah. Just swap out the mics. That'll work. That works a little bit better. All right, so just to do some level setting where Paz plays in this open cloud world, the infrastructure as a service is what's giving you what I refer to sort of jokingly as servers in the sky. It's basically creating an elastic set of servers that'll create, you know, whether you put Linux on it or whatever flavor of Linux on it, it'll create those servers and give them to you as a computing resource. With that, what you get is your operating system, in this case, RHEL or we do CentOS or Fedora, whatever your pleasure and your application, but you have to put all of that together. And Paz really focuses on just you having to put your application on it. It services up everything else. And SAS, with SAS you have no control over what it is you're delivering the offering here. So it's a lot about what level of control you want. But what we found at Red Hat was that infrastructure is not enough. So just to give someone the Linux operating system and say, go to it, you still, and in your world or in the past, in my world, using Drupal, I was probably going to a hosting provider that gave me a C panel wall in front of my Drupal and I would try and deploy Drupal with C panel and hopefully I would get some SSH access in and be able to fix things up. So I really, really wouldn't want it. But there's this interplay between C panel, blockage of access and automation to just giving me a server in the sky. And that's where Platform as a Service comes in. So really what you get with infrastructure is you get the network, you get the storage and the compute as an on-demand service, which is great and wonderful. I'm not saying that's wrong. But you're still on the hook for configuring and managing your stack and the cloud itself. So really what we wanted to do with Platform as a Service is to get beyond, how do I use this and make it really useful? Because everything, when we talk about Drupal, people have this sense, the C panel sense. I'm gonna click a button and Drupal's gonna automatically install and it will scale and do all the wonderful things and it will upload and I can configure my email and all that. But the reality is there's a lot more going on in the background. But we also want to have that SSH and the tighter control and the access to those containers and how do you do that between a C panel-like world and a Platform as a, you know, and just to pure that and that's where Platform as a Service sort of steps in. So what you're able to do with Platform as a Service is if you're using Drupal or if you're writing your own application in PHP or in Python or Jboss, whatever, you code your application, you create your application maybe on your own machine in a VM with OpenShift running on it so the environment is exactly the same as the one that you're gonna push it out to in production. You put it all in Git, it'll pull it out and then it will automatically, is my favorite word, deploy up the MySQL or the MariaDB or the PostgresDB that you need. It'll do the DNS configuration. It'll turn on load balancing for you. It'll get all of that stuff working automatically for you and still give you the control and the access to the things that you need as a Drupal administrator to SSHN securely into a multi-tenant environment. So what we're really, what we're trying to build with this Platform as a Service is a way to give you that tight control over a multi-tenant environment that's secure without too much hassle. What we do with Red Hat Linux and Centos and Fedora is we have SE Linux and C Group enabled multi-tenancy. So we have very highly secure multi-tenant containerization going on inside of our Platform as a Service. And that allows us to go into some pretty highly secure government agencies to deploy Platform as a Service where they would probably have put it beforehand. We're trying to give you all of the dev tools and the command line stuff and we'll show you a little bit of that in a bit and create this open ecosystem. So the Drupal community, I hate to say the word, press community, the Moodle and Joomla, all of the CMSs, they all play equally well and they all have a role to play there. But we really aren't trying to lock you into a Drupal-only world because we realize that you're doing more than Drupal. And I think that's the reality of most enterprise deployments is that there are other applications. There are, I just wrote a Python Flask app which we will show you a little bit of and a few bit origin.ly which is our index of all of the quick starts and cartridges. So in my world, I'm using Drupal to host my community site but I have a Python and Flask app and I'm still running it all in the same cloud all with the same level of automation and scaling. The way that we do this and this we'll go into, I'll let Steve talk a little bit more deeply in this is Platform as a Service is creating a way of looking at the resources on the infrastructure as a service in which we have a broker node that is managing the health and watching the traffic that's going into one of those containers which we call gears. We put a whole group of gears in a node so we have broker nodes or hosts and that we can have redundant so you can have HA so if one of them goes down, they'll still keep working. And so we'll have a node that has many, many gears in it that is all shared and it's all managed and in those gears, we have what are called cartridges and cartridges are things like MySQL as a cartridge, PressFlow as a cartridge and we'll do quick starts for things like Open Atrium, PHP as a cartridge so you're injecting those into your gears and in a standardized way and you're able to customize them and deploy multiples in these nodes and the broker is monitoring all the nodes and all of the gears all of the time and helping you scale them up and scaling them down. And you as a developer can have a gear or two or three year VM on your machine and it will have the exact same environment on it. So in the past, one of the things that really bothered me about the sort of the application development lifecycle within an enterprise or even in a small consulting firm is I as a developer would be sitting on my box working on something and it would work perfectly fine on my machine and then I'd throw it over to QA and QA would take my code, put it on their machine and it would break and then we'd waste all of this time trying to figure out what's different in the two different environments and so what you have with platform as a service is the ability to spin up exactly the same environment in QA and test and in production and scale it out and you know that it's compliant and it just mitigates the risk of having those variations and those are pretty human errors and they happen every day when you don't have some automation layer managing your lamp stack. So this is, I think of it as a great tool for improving the developer application lifecycle and getting you more quickly and agilely to the production environment. So that's one thing. The other thing that is kind of scary is we just announced dot net support. So not only are we doing that whole cornucopia of wonderful open source Linux based lamp stacks but we're now supporting and hosting windows natively inside of our those gears. So that's another whole bellywick. I'm gonna have to do something about getting Visual Studio running on one of my machines and it's gonna scare me a little bit. So in a nutshell, basically the broker is monitoring the health and managing the authentication of all of the gears that are living and breathing on nodes and you can spread your nodes into districts and manage those and they can go exponentially high. This is one of the most flexible platform as a service offerings out there. The other thing that's really interesting because it is an open source project. So if you look at what Pantheon or Heroku or Acquia or anybody else is doing, they're offering wonderful platform as a services but that's proprietary. You throw it up there and it's a black box. You don't see the code. You can't take that and run it in your own behind your own firewall. What we've done is taken all that black box magic and open sourced it and created it a community of people in an ecosystem of people supporting that and working on it together, creating the cartridges and the frameworks and continually extending that ecosystem and allowing you to take that and deploy it anywhere you want. We also, we host it online. So if you just wanna try and play with it, openshift.com, you go there and you can get three free gears today and deploy Drupal and it's free as in forever. Kind of free and then there's plans like Silver, Bronze and Titanium or whatever that you can pay for as you grow into them but we've really tried to create a very flexible environment for people to go from just a small development project all the way up to production quality and on openshift online right now we have over 1.5 million applications running. So this thing is highly tested, very scalable and runs on AWS, on OpenStack, on BareMetal with Centos, Fedora, REL, you name it, we can make it work for you inside of your enterprise. So we're really pleased with it. We're really pleased with the way that Drupal works and scales on it. As I said, redhat.com is a huge Drupal site. All of, you know, if you go to any of our properties our customer portal is a Drupal site. So we're big fans of Drupal and we really were keen to make sure that Drupal became a first class citizen on OpenShift and we think we've done that with our partners phase two. So with that, a couple more slides. You can really configure OpenShift to meet any of your needs. So whether you're a small shop and you just wanna create test environments and production environments for your customers to play and see what they're gonna get, you can do that and you can create a white label environment. So you can set up OpenShift.com, you can have phase two.com and phase two's clients can go there or whatever your things. You can deploy this yourself, you can white label it. There's lots of different ways to deploy it. There's lots of ways, there's a lot of information about capacity planning and building it. We have some huge customers using it, Paypal, Dreamworks, major government agencies now are using it partially because it's so super secure using the SC Linux and the C groups, those multi-tenant containers are very secure and easy for people to get permission to deploy in places where you think and they should care about it. And as earlier I mentioned, if you can also download from origin.OpenShift.com, a VM to play with it on your own desktop. But I'd advise you first to go to OpenShift.com and just play with it online. That's probably the easiest thing, most non-invasive to your machine. So as usual, this is my pitch for Red Hat Consulting. If you want to get certified, you want to be certifiably weird, come to Austin, but if you want to get certified in OpenShift, there is training now available to get you certified as an administrator of the platform as a service because that's one role of someone who's got to manage the sysadmin to manage it. And then there's another training session for application development. So if you want to learn how to specifically architect new applications and there's an exam for everything Red Hat, there's an exam and you can get started pretty easily. And if you want to use the open source stuff, I'll love you forever. I'm the community manager of the open source side, but all of this has Red Hat's backing and support. And there is an enterprise version of the on-premise one and online as a whole tier of support layers. But please feel free to go and use it. So and like I said, come and join us at origin.openshift.com if there's anything missing. So today I'm going to turn it over to Steve. At the end of this, I'm going to ask you all, what's missing? We have open atrium, we have Drupal 7, Drupal 8, press flow, I want to hear what's missing. What else we could do to add value for the Drupal community? So with that, I'm going to hand it over to Steve who has got origin on his mobile phone. Yeah, I was, oh, yeah, drop the mic right there, you saw it. Yeah, maybe. Never a dull moment here in Austin. Yeah, so I wanted to talk some first about platform as a service, because I think a lot of folks are coming around to the realization that the platform as a service model is very important. And I do want to say that I think platform as a service is great both for devs and actually also for ops people. Like if you have to manage 20 different servers, I mean, presumably many folks, if you are ops people, can write puppet or Chef scripts or Ansible or Salt. But really, if all you have to do is take care of the single open shift environment, it becomes much easier. Like if you want to add more capacity to be able to run more Drupal or PHP or Ruby apps, you just have to add another open shift node. There's a single homogenous configuration that you have to stand up. So a lot of leaders who've been thinking about this in the community have come up with this idea called the 12 factor app. It's designed to be a way to build applications in a more robust way. So these quotes are all from 12factor.net. In the modern era, software is commonly delivered as a service, as we're talking about. The 12 factor app is a methodology for building software as a service apps that are suitable for deployment on modern cloud platforms and can scale up without significant changes to tooling or development practices. The 12 factor app manifesto goes on to say, a litmus test for whether an app has all config correctly factored out of the code is whether the code base could be made open source at any moment without compromising any credentials. And finally, the way that the 12 factor app recommends storing these configuration values is in environmental variables. The 12 factor app stores config in environmental variables. Envars are easy to change between deploys without changing any code. Unlike config files, there's little chance of them accidentally being checked into the code repo and their language and operating system agnostic. So one of the reasons that's really important, did anyone remember an article that came out a little while ago about NBC accidentally leaking their secret keys? There was a big to do where a guy, basically his name was Glenn and there apparently was a Glenn on the team also there. And he said he got access to this repo on GitHub. And in this case, it was the configuration for some continuous integration build scripts, including the secure AWS secret keys and access tokens to all their servers for all the websites of NBC universal. And then he says, oh, bleep. Yeah, so basically, in the 12 factor app world, if these config keys, if these secret keys hadn't kept in environmental variables, it would mean that having access to the code repo wouldn't matter because all the secrets would just be on your platform as a service. It would just be in the actual runtime production environment. And then you'd have to set them locally, but they wouldn't be in a repository somewhere where you could accidentally download them. So yeah, Diane talked earlier about cartridges and OpenShift itself, one of the reasons that I'm really interested in it is that it does support a large variety of different technology cartridges. So yeah, OpenShift provides a wide range of them for different languages and services and they're deployed as cartridges. So a cartridge can be many different things and actually many applications might have more than one cartridge. So for example, a Drupal site would probably have the PHP cartridge, which is the main thing that's gonna respond to requests. MySQL cartridge, which could be MySQL 5.1 or 5.5. There's also community cartridges for MariaDB. You'd probably have the Cron cartridge, like one of the things that we do in all of our Drupal builds at least, we'll have the Cron cartridge run Drush Cron every hour. So that's just taken care of. And then as Diane mentioned, we do have a small press flow settings helper that uses the part of press flow seven that can read anything in dollar sign con for dollar sign databases from the environment to make it so that you don't have to edit your settings at PHP at all and your code will just work on OpenShift. So as for technology cartridges, these are the ones that come built in with OpenShift and these come whether you're using OpenShift Online, which is the free service that you can use online or get commercial support through Red Hat through or in Enterprise or Origin, which both run behind your firewall and with Enterprise, you also can get commercial support from Red Hat. So you can run, you're running some Perl apps, PHP 5.3 and 5.4, Python 2.6, 2.7 or 3.3, Ruby 187 or 193, Java 7, Node 06 or 010, MySQL 5.1 or 5.5, Mongo 2.4 and Postgres 8.4 or 9.2. So already out of the box, if you have a need to run any combination of these apps, like, oh heck, we've got our Perl app that hits MongoDB, you can easily do that. That can be something that you run alongside a lot of your Drupal doc routes. Then there's also some utility cartridges, like there's actually a Jenkins cartridge. So you can very easily inside of OpenShift spin up a Jenkins instance. And the default is to push code to an application when you push to its built-in Git repository. Every application gets a repository, and the default is, okay, when I make changes on master, go ahead and push. You can disable that and instead use Jenkins. So if you want to use a more in-depth deploy process, like let's say you use Drushmake, or you're going to compile Compass files or SAS or less, you can do that and then actually have Jenkins send the code on to all of your gears in the application. So as I mentioned, there is also Cron. The Cron cartridge makes it easy to run any task or tasks that you want on a regular basis so that as your app is up and online, it can take care of any housekeeping tasks. There is also a Ph.D. Miniman cartridge. If you really decide that you want to open your database up for everyone to see, but certainly it can be useful. And again, the Ph.D. Miniman cartridge, you could add that, do some work, and then remove the cartridge and you'd be okay. So that's the great thing. Every app has to have a primary cartridge, like it's going to be primarily a Ruby app or a PHP app. But then you can add and remove other cartridges as you need to. So if you suddenly decide, oh, I want to add Redis caching to my Drupal app, you can absolutely do that. And then the really great thing about this is that, basically anything that runs on Red Hat Enterprise Linux and or CentOS and or Fedora can be made into a cartridge. So if you come up and say, I've known this a couple of times, like let's say we have a Jenkins builder, we want to generate documentation with oxygen, well, great. You can just actually probably just grab the RPM, grab the binaries out of it, and make it into a custom cartridge. And so there's a ton of these. Some of the community cartridges that are out there are cataloging a site called originly, it's origin.ly. And so this is where members of the community have come together and made either quick starts and quick starts are just collections of repositories that run on top of existing cartridges. So open atrium is an example of a quick start where it's still just an app that's running again PHP, MySQL, Cron and one of our other cartridges, but it'll pre-see the Git repository with open atrium. So you get sort of a one click install, it starts up, you throw it into the installer, the environmental variables have injected all the config you need and it just runs. Yeah, so up at originally there's a lot of different ones. So like Redis is not included out of the box, but there's a great community cartridge for it. There's even sort of beta support for Redis Sentinel and being able to scale up and down your Redis cluster. Cause that's another thing is that with OpenShift you can build either sort of monolithic apps that are all in one gear or you can build auto-scaling apps where each different tier can scale. And so you could say, I'm gonna build a scaling Redis pool or someone's been working on a Galera cluster scaling pool. So you could actually have a cluster of MySQL machines that could scale up and down. There's also a varnish cartridge so that you could actually have your Drupal setup on one site, spin up a varnish application and it will do the caching for you and make requests back to your other application. If you wanna run an app in Go or in Closure those are available and also things like Memcache. So there's a considerable amount of work that has been done by the community to add extra capabilities. And again, that's all possible is because anything that can run on RHEL will work as a cartridge. And you just hook into a couple lifecycle events to say this is how my cartridge starts and stops, this is how it scales. And then the cartridges will export environmental variables to advertise that they're available to the apps that are running inside the platform as a service. So as I mentioned before you, each application has to have at least one cartridge which is the webframer cartridge. This is gonna be the one that actually accepts HTTP requests. So this is the primary language or framework that is running inside of the application. So every app has one and only one of these. And the way that this works is that then the application code that's running will get a set of environmental variables. So it could be like OpenShift Ruby port and OpenShift Ruby IP. And it'll have to bind to those and then the traffic will get sent back to them. And in addition to SE Linux security for all the gears, all of these individual applications are also just listening on local loopback addresses. So they actually also can't cross talk with one another which is an added layer of security. So basically it is very, very, very difficult for any of the apps that are running in these security Linux containers to mess with one another. They're designed to be completely separate from one another and they are also resource isolated. So things like TC and C groups limiting are used to ensure that, for example, an app could burst up and use some extra amount of CPU if it's free. But if not, it gets a fair share compared to all the other applications that are running on a particular node. So working with OpenShift is pretty easy. As I said, every application that gets created has its own Git repository. The cartridges themselves, the web framework cartridges define what the default app is gonna be. In all the built-in technologies, it's basically a version of that language saying, hey, welcome to OpenShift. So like if I spin up a PHP app, it'll say, hey, welcome to OpenShift, clone this repository and do something different. And yeah, you just push code to deploy the app. Whenever you push, by default, whenever you push to the master branch, it will do a deployment. And so, again, based on those framework cartridges, some other things will happen. Like if you're running a node app and you have a package.json file, those dependencies will get installed every time you push. So you add new dependency in, you push, it'll install them. Same thing if you're running a Ruby app and you have a gem file, you can add new gems on the next push, it will actually do a bundle install and then run your application. This push also restarts all your services, like each of the services and cartridges that are running in your app. And then, again, you can, if you want to build with Jenkins, if you don't just want to do a straight get push workflow. You get a little feedback. You do actually get feedback as you're doing the get push. It just shows the entire output, like it'll say, waiting to stop, stopping, installing dependencies, and then, Cron started, MySQL started, PHP started. Now, you don't have to restart the services either. For something like PHP, it doesn't really matter. So there is actually an extra marker you can put into, say, called hot deploy that will not actually bounce Apache when you run. So there's also some options like that. You can do the same thing with Ruby, you can say don't update the dependencies to make your pushes go faster, like if you're rapidly iterating on something. So for Drupal, Drupal itself, we do have a quick start for pressflow seven. So how many folks here are familiar with pressflow six? Yeah, kind of. And how many folks are familiar with pressflow seven? What's that? Right, exactly. So we did the same thing that Pantheon does. One of the Pantheon, or sorry, pressflow seven has a couple of different, a couple of different enhancements, including using APC to cache if files exist. But one of the biggest things that it does is actually a pretty simple change where it says if there is an environmental variable called pressflow underscore settings, then it will take the keys from that in either conf or databases and will inject them into the environment. So basically the simplest thing that you could use as forward would be to inject the databases array, right? Like when your app comes up under OpenShift, there will be some environmental variables, OpenShift MySQL port, OpenShift MySQL host, OpenShift MySQL user that tell you here's how you can access the database that was created for you. And with this, we just made a quick settings cartridge that would actually grab those and put those into the pressflow settings variable. So they're just injected. And again, you could run it without needing to change your settings at PHP or even actually without a settings at PHP at all. And this is also available on the Origin.ly site. So I'm gonna jump out of the slide deck. You can take a look at OpenShift Online and OpenShift Origin, which again is a totally free and open source version. You can run on your own server. Let's do that first of all. Yeah, so I'm gonna go to Chrome here. So this is OpenShift Online that I've just logged into. It's at openshift.redhat.com. And so I've got a number of different applications available to me. One other neat thing about OpenShift is that it has this concept of domains. So you can make multiple different domains and give different folks different levels of access. So you can actually collaborate as a team with this. So I could say, in our domain, you know, Drupalcon, Frank and I both have push access to the applications, which would let us both deploy new code. And then we could, you know, add other things. Someone could get administrator access. They could actually change or delete applications. So there's multi-level access control for these too. And so we have a number of different things that you'll see, like for the Origin.OpenShift.com site, for example, we're actually running the varnish cartridge to act as a varnish server. And then we have OpenHRM, which again is running Cron, PHP 53, MySQL 555, and the PressFlow 7 settings helper. So before I go to Origin, let me actually, I'm gonna go here. So I went to origin.ly, which is the index of those community cartridges and quick starts. And I will just search for PressFlow. And then I can hit launch. And when I hit launch, it's gonna take me into the create application screen of OpenShift online. And from here, you'll see the domain also influences the URL. You can do URL aliasing. So in other words, you know, you can also put in your final URL and put in a C name, and that'll work. But out of the box, all of your apps are going to be app name-domain name. And the nice thing with that is that you just need one wildcard SSL cert to get SSL for your entire platform as a service. So I will say triple condemo-face-technology.rhcloud.com. Origin.ly has preceded this source code bit here. So that's the quick start part. We already have a quick start that's just gonna pull in the latest version of PressFlow 7. And so instead of just a bare PHP git repository, this will be full already with PressFlow. Now I have access to both small and large gears because I have an upgraded account. And again, if you were running this behind your own firewall, you could also set up different classifications of gears. And the main thing with gears is just setting up different resource usage profiles. So how much CPU do they get? How much memory do they get? Or how much memory plus swap do they get? How much max network IO and disk IO? You can control all these levers. So in the case of Origin, or I'm sorry, OpenShift Online, you've got small, medium, and large. In your own infrastructure, you could actually set up whatever classifications you wanted. The only current limitation is that right now, you have to run one node size per node. So if you wanted to run small and medium and large, you'd actually have to have three different servers and all the smalls would live here. Or again, you could have multiple servers and the smalls would run in this district of nodes. And again, it could actually scale across that so that not everything would be on the same machine. So I'll say large. It's got my cartridges set up. I will say no scaling for now and I'll create the app. This could take a little while. So I'll also go and show you this is the phase two, well, A phase two, OpenShift Origin that I've set up. This is a Sentos six box running on Google Compute Engine. And there is a project called OO install, which is just install.openshift.com. So if you're interested in installing this on your own server, there is a site at Red Hat called install.openshift.com. You can go there with a RHEL or Sentos six or Fedora machine, run your little curl bash script and it will give you a wizard and ask, do you want to put the broker, where do you want to put the broker, where do you want to put the nodes? You can set it up all in one. It will generate a config and apply the configuration to get you that. So I did this a couple of months ago to get set up for Red Hat's DevNation hack night. And yeah, so now I've actually got this, my setup here where we're running a considerable number of apps. And you can see here, we actually have multiple different domains. So here I've got the Frank domain and the self-service domain and the joec domain in addition to the Smeryl domain. So this is drupal-smeryl.openshift.phase2technology.com. But then there's also nice camp in PHP 5.4, PHP 5.3. So this one's spinning up. Let me actually, I'll show the, again with my personal, totally open source origin setup, I can go in and say, well let's just make a PHP 5.3 app. So we'll do that. Call it PHP 5.3 Drupal-con. Now this one, I won't put in a Git repo, so we'll just get the standard one. No scaling, I'll make the app. And so this is the console, which is now talking to the broker. It's actually making REST calls. The broker itself is just a REST API. If you don't like the console or if you wanna add extra business rules, you could certainly actually add things onto the console. It's just a Rails app, so it's easy to extend. But if you decided I have a completely totally different workflow, you can do that too. And you can just talk to the broker via REST calls and say, make a new app with these cartridges and it'll spin it up for you. So it's already come back. I can now do a Git clone and go grab that and take a look. Or I'll actually go to my command line because OpenShift also has a really nice command line interface. There's a gem called RHC, which lets you connect and modify apps and do things to them via the command line. So, and I've actually also made an RHCP2 version, which is set up to talk to our OpenShift origin. So I can say RHCP2 app show. Boy, I think I called it PHP 5.4, DrupalCon. PHP 3.0, DrupalCon. See if that's correct. PHP 5.3, DrupalCon, great. Okay, and so it's come up here and it says great. Here's the app. There's the actual URL to it. The domain is esmeral, one gear defaulting to small. There's the Git URL. There's the SSH. One of the nice things about OpenShift and its security model is that because it's completely constrained, even if you manage to get root inside of one of these containers, you couldn't get root on the machine and you couldn't actually break out of the SCLinux context that was assigned to you. So as a matter of course, it's actually safe to let your end users SSH in. So I could do an RHC P2, SSH, PHP 5.3, DrupalCon, and now I'm here in my PHP application. And I can actually run an export command and take a look. And so here are all of my environmental variables. So as I mentioned before, one of the things that you get when you do this is an IP address and a port that you have to bind on to be able to actually get requests out to the outside world. And so it is a loopback address in this case. This particular gear has been given 127.2.1.1 as its IP and the port of 8080. And so when in this case Apache and mod PHP bind on that port, then an incoming request will get routed to that loopback, well with proxy to that loopback address and get sent back out. Yeah, so you can SSH in with the Drupal support. We do also in both PressFlow and OpenHTune we set up Drush to be pointed at where the app is deployed. So you can just SSH in or make a remote Drush alias. Do a CCL, do a DrushDL, do whatever workflow you'd like to work with. So yeah, before I go back to Drupal, I will actually now do an RHC GetClone PHP 5.3 Drupal Con. I can spell. Actually, what we're doing that, how about we actually go take a look at what this looks like since it is actually live on the internet now. Welcome to your PHP app on OpenShift. Nope, just kidding. I don't want to see you at home. So I'll be at the booth in a bit as you see. Yeah, so here's our PHP application. Basically, default is just a big PHP file. That shows what you should do with it. And so I've come under here and did I get the name wrong? PHP 5.3 Drupal Con. Oh, yes, correct. All right, CP2. There we go. And so then I could go into PHP 5.3 Drupal Con and instead of doing all this, put a PHP info page up. Now you either get pushed and now you'll actually see as part of the Poster C hook, it does it, it makes a deployment out of it and it does it. OpenShift also supports multiple different deployments so you can do a rollback if you want to. So you can configure it to say, save the last X number of deployments and actually rollback. Instead of having to like say, get checkout head till the three. A very, very handy feature. Yes, it's very nice for kind of jumping back. And now we have our PHP info page. So yeah, that's all self-contained. Now we can do the slightly better Drupal version which is actually up on OpenShift Online. So these are not servers that I control. This is just part of the free tier on OpenShift Online. And so again, we've set this up. This is probably Pressflow 726 at this point or Pressflow 727 and I can connect to this and it takes me to install that PHP. Now again, OpenShift is setting up the MySQL environmental variables in its own namespace. OpenShift underscore MySQL, et cetera. Then we've got this Pressflow cartridge that will take those and put them all together into a Pressflow settings variable which means that this app will just be able to, again, without any changes to the settings that PHP pull them out of the environment. So I'll take the standard install profile, install it in English, and then it'll check and now it's installing because it's got the database information. And in fact, so then I can do an RHC SSH into Drupal Con demo. No, this one is regular Drupal Con demo I think. I may, you know, I have so many accounts. I might be signed into the wrong account here. Well, what I can also do is just, I don't have to use RHC, I can also just do. Yep, there we go. Yeah, and so there's the combined environmental variables that lets you put that together. And what it's pulling that from is all these OpenShift MySQL variables, which again, OpenShift also, OpenShift, MySQL is also running on a local loopback interface so it's secure, you know, you can, similar to the Pantheon model, like in Pantheon, you know, your code has access to these, but there is no external access. So unless you can actually gain access to SSH, you're not, you know, you're not at danger of being compromised. Yeah, this is the standard model for platform as a service anyway. Okay, and then I can do admin, admin, and do that. Set that up, hit save and continue. And then we've got our new site. Now for the last part of the demo. If my RHC works, and if not, again, I can just get clone it, but I'll try. Doing live demos is always fun. Yeah, I'm really, I'm risking it now. This is going pretty well, so we'll see how the demo gods go. All right, well again, I don't actually have to do this. I can just do, I can go into the OpenShift online control panel, and that is my get clone URL, so I can do a get clone of my repo. Right, so basically the way that, the question was, do you just SSH clone and, or do you SSH and get clone from the same URL? And the answer is yes. So basically every different gear has its own user, and that's the way that it works. Its own user and also its own SE Linux context, and that's how the resource isolation works. So that, you know, even if another, again, even if you somehow could break out of the containerization and get access to it, because like on the host machine, this ultimately just runs in varlib OpenShift and then a GUID, which your application's assigned, which is the same as your UID. But again, they're all SE Linux labeled to only grant access to your SE Linux context. So if you somehow manage to get outside and out of the, you know, sort of trute in SE Linux container and go to varlib OpenShift, you wouldn't actually be able to read those files as another user. Yeah, so here I've got my DrupalCon demo and do the PHP directory. I'll do Drush. What's a great joke module that I could install? What's that? Magic? Yes. There's GL magic. I think there was also a theme called unicorn ponies. Oh, unicorn ponies, we like them. Yeah, so we'll add, okay, so we've got a couple new things here. And so in this case, I'm pushing to OpenShift online. Oh, that's right. Okay, so Frank, I mentioned, I actually mentioned hot deploy. In the latest press flow cartridge I've actually made it the default. So it won't try and restart Apache MySQL every time. So you'll get a zero downtime deploy with this. It can, it absolutely can, yeah. And so, yep, I think I poked the demo guts a little too much. But I can do an SSH again. It just to show even a little bit more about some of the things that we do. We do actually make a dot drush and we make a drush rc.php. So we could actually go in and say drush, you know, game status. And I probably, oh yeah, I probably could. But anyway, that's, I think we'll jump out of live demo mode. But yeah, that's some of the things that you can do with OpenShift and with Drupal. And so again, that was the press flow quick start. Yeah, so for OpenATrium we've done the same thing. And actually maybe I will get this one queued up. I know we're sort of running up on time. But I can do the same thing. If I go in and I search for OpenATrium to quick start, I can launch this one up and I'll put this on a large gear and I'll create the app and well, that's coming up. We can talk about it. So similarly, what, you know, one of the really great things about all of our distros is that we're already shipping them for Pantheon. And so we already have a press flow seven version of them ready to go. So basically whenever we do a new release to the drops repository for press flow seven on Pantheon, we can then just grab that same thing, tag it and make it into the newest version of the OpenShift quick start. So yeah, we have the OpenATrium two quick start as well, which puts together Drupal seven, actually press flow seven in OpenATrium. And again, it sets everything up with no settings that PHP edits. And if we have a little time, I can go back and prove to you that like for that Drupal con demo app that I made, there were actually was not any change to the settings that PHP, it was bone stock. It does use the cron cartridge to run Drush cron automatically. So yeah, if you just go to origin.ly, it's currently on the front page, but you can also search for OpenATrium and it's there. So we have about six minutes left. So yeah, we'd love to take any of your questions about Drupal OpenShift or anything. You do. So for all non downloaded cartridges, yes, absolutely, like whatever platform you're running on, there is a mechanism in the cartridge spec to allow for upgrades. So right, like the example might be, well, yeah, and even like the way that this works is that ultimately an OpenShift node is just a rel box with all the software installed on it. So even if you're running like a Ruby app, you could still run PHP or Java or Node. It's not, you know, the versions of software that are available in the actual container are not constrained. So if you wanted to say like run Compass from your PHP app, that would actually work. So right, you can absolutely, well for one thing, like because of rel security policy of just backporting fixes, sometimes you don't even have to change the cartridges at all. You can actually just install the security update for Apache or PHP. And then you've got that at least the next time your app restarts, there is also an ability for all of those sort of built in foundational cartridges yet to do an upgrade. So, and typically I'd say more of those are actually done to add more features or sometimes they're done to fix things, but yes, absolutely, all of the core cartridges do support upgrading, making changes to their config. Like you can, they have sort of like Drupal's update hooks where you can say on upgrading from, you know, 2.3 to 2.4, do this particular thing. Is that something you physically have to like? You don't sort of fron-try other ones at the hour? So it's not built in like, but for, well for online obviously, the Red Hat Ops team handles everything. But otherwise like all of the, because this is Red Hat, everything is delivered as RPMs. And so when you're subscribed, for example, of the Origin 3 YUM repository, you just do a YUM update and it's like, oh, there's a new update available for OpenShift Community Cartridge PHP. And it does it like that. And then you- You still have to run the YUM. Yeah, exactly. Right, exactly. So for Herkley, you still had to run the YUM install. Not, no, we did it for you. Yes. And that's the role of the Paz administrator. And I think that's one of the sweet spots for this is, whereas like Pantheon and Acreah and Heroku and Engineered and everybody else, they have these black boxes. The same thing that's running on OpenShift Online is available to you and OpenShift Enterprise. So the technology is that it's all there. It's open source. It's not black box magic. And you know what we're doing because you can look at the code. It's white box. It's white box. Transparent boxes. Clear boxes. I have three questions. What is the- Which cartridge should I be using for more existing large scale? When it comes to that, I think that would be confusing. Like a couple of months ago, and I had to start moving like my dock of the ship all the way to my existing site and portion of it. I don't know about that, but that's the right part. Yeah, so I would say that basically, the question was which PHP cartridge should you use if you're migrating an existing site? So the way that it works, like if you already have an existing repository, as of about four months ago, it used to be that the PHP cartridge, you had to put your files in a directory called PHP to go on OpenShift. That's no longer the case. So you can totally, if you have a repository that just has Drupal at the root, you can now use that. And I would say start with one of the built-in cartridges. Use either the PHP-5.3 or PHP-5.4 cartridge depending on which version you're currently running. The database you've already got. Sure. So you can really, if you can export it from your current host, you can upload it to your gear. So you could R-H-C-S-C-P it, there's actually a command called R-H-C-S-C-P. So you can say like R-H-C-S-C-P, mydatabasestump.sql.gz and name your app and it'll put it up there. And then again, you've got CLI access. So you could do just, if you're running the Presto cartridge at least, you will have this Drush in this drushrc.php. So you could literally do like Zcat, mydatabase, pipe it to Drush SQL-C and it'll import it. And then from there, you could use backup and migrate if you wanted to. The files directory is in OpenShift's data directory, which will state put between app deployments. Like your code base will get overwritten when you do an app deployment, but the data directory won't. So you can absolutely use like, and by the way, out of the box with either the press flow quick start or any of these, it automatically puts that files directory into the data directory, which means that it'll persist, which means that yeah, you could then do backup and migrate. Hi, I'm from Canada too. Awesome. So we have the challenge where like a lot of belt related organizations, they want to do so. Like I don't think you guys have a lot of concerns about this thing. No, I- Do you work with partners? Because like we're trying to take the installation and maintenance of OpenShift, and like the origin of Google 2.0, we want to take that out of our world. So at the moment, we don't have a data center in Canada. We were running on AWS, they'll be shipped online. We run on anything. And it is, if you go to install.openshift.com and you talk to whoever your hosting provider is, there are a number of people in Canada that I can hook you up with that could run and install OpenShift for you. And for price, I'm sure they'll manage it too, but it's pretty easy to manage yourself. So if you wanted to host it for people, a lot of people are hosting it behind their own firewalls on their own servers. So I've talked to other people that would be interested in that. So talk to me afterwards and we can hook up. So okay, so the question was, contrast this to Docker? And the answer is in about eight months, it won't matter, because the next generation of OpenShift is going to use Docker instead of this SC Linux containerization. It will actually use SC Linux around Docker. So there's a project, there's two actual sort of projects relating to containerization and Docker specifically currently going on a Red Hat. One of them is called Project Atomic, which I'll say it's somewhat similar to CoreOS. The idea is that it is a host that is designed to just help you run containers. So part of that includes in place upgrades using YUM. So similarly, that's a thing that like CoreOS provides. You can actually have a stateful partition. You can do an upgrade of like a secondary partition using YUM and then reboot back into that. There's another project called GearD, which the Red Hat team has started up and has been contributing to that is going to tightly, I'll say tightly coupled, but it will actually make it very easy to more deeply integrate Docker and SystemD. So in other words, like right now you run Docker and maybe if you're running Fedora, you still start it with SystemD, but there's no real connection. Whereas with GearD, it's designed to actually take that over and for each container you run, that will be a SystemD socket activation file and service. So every time you make a container, it actually becomes its own SystemD unit and that way SystemD can manage the life cycle. It can actually do socket activation. So like OpenShift in its current form does have a thing where it can idle an app if it hasn't gotten a request in a day, then spin it back up. In the future, that'll be Docker and then GearD will take care of that. And so like exactly similar to what Pantheon is doing today, it could, yeah Pantheon, or you can actually like stop what's happening in the container and then again it would take over that socket activation. So the next time an HP request comes in, takes a couple of seconds and then you're back up and running. So definitely the team has seen that like Docker is the future and that will be the next iteration. I pay him money to do this. I don't come here, I don't have to talk at all, but if you want to get in on the beta or the alpha versions of that, talk to me after this. This is like a good way to kind of get into it. Yeah. Because it's going to be coming anyway. Yeah. Sorry. It seems more user-friendly, right? Yeah. Go ahead and click around. Yeah, it's the fact that you get your own, like you get a Git reposter with everything and that's you know like all developers know how to work with Git. And so I mean you might have seen, so I'll give one more really quick thing before we go. So we have this little app for our booth called music.faceyourtechnology.com. It's just a small Sinatra and Angular app that connects to the Beats Music API. You know, so I'm, well I'm not in Portland. I'm at the Container Bar, which you should all be tonight by the way. Diane and our booth will have wristbands for the free booths. So I'm interested in watching core commits with Drupal Superheroes to some oldies. I'll hit jam and we can start playing this. But anyway, this is a, again, it's a Sinatra app running Angular and it's deployed to OpenShift. You know, like we did RHC app create, music Ruby193. Yeah, and so I, you know, I can run it locally. I can do a bundle install, form and start just to run Rack and Sinatra. And then I can push up here and it works. And so again, this is using the aliasing feature like behind the scenes. This is actually music-face2technology.rhcloud.com. But then I can easily add an alias, add in a C name and it just works. So we're using it for this, we're using it for our Hubot. We're using it like in addition to doing PHP and LAMP stack apps, it's so useful because it has all those other technology cartridges. So if you wanna run your own Hubot, run some Ruby applications, do style prototyping, like we found a ton of uses for it. And again, there's no ops burden. Like you don't have to worry about, well we need a VM and we'll run the puppet script. So the Chef Scripts to put Ruby and the stuff on it. Like it is so much quicker and it's so much less management to do just by using the features that are built in. So I think we actually probably gotta get out of here. I think the other folks are coming in. But- Everything that you've seen today, you can go to Openshift online or openshift.com and try it out for free. So come to our booth, come see us and get one of your, come and have a drink with us at the container bar tonight. We'd be happy to answer any more questions that you have. Thank you. Thanks very much. Thank you.