Last we we announced the general availability of European Hosting for OpenShift Online premium plan members. Now Bronze and Silver plan users can choose where their applications are hosted in the world. With over 2 million applications created by users around the world we heard repeatedly that this ability was needed.
As part of the regular application creation process (from the web console or command line tools) you decide where your application should be created.
Here’s an example from the CLI:
$ rhc create-app --gear-size --region --scaling
To see a list of available regions for the plan you are on:
$ rhc region list
Users with existing applications can easily migrate their application between regions using the command line tools.
To see the region your application is currently being hosted in, use the following command:
$ rhc app show --gears -a
And to migrate your application to a new region:
$ rhc app create New_Name --from-app App_Name --region
If it’s important to you to maintain the same application name you can also use rhc snapshot as outlined in the KB article.
The OpenShift recently team created a whole new website to make Developers successful on OpenShift. We also added a special section explaining how to manage and create applications in different regions.
Stay informed and learn more about OpenShift by receiving email updates.
Yesterday and today have been busy days for lots of system administrators who have been scrambling to patch their systems with updated bash packages. After the disclosure of a bash bug in CVE-2014-6271, nobody wanted their systems compromised by one of the many exploits this bug made possible.
Not everyone is in a panic; users of OpenShift Online have nothing to worry about. They know that the OpenShift Online team works with the Red Hat Product Security team to ensure that our platform remains secure. See the Security Team’s in-depth evaluation of the issue here.
Let me tell you about two of the platforms where I have applications running. The first is an OpenShift Online gear that runs my application in the cloud. The second is an old server I have that runs a traditional Linux distro. Yesterday, when people started getting wind of the advisory, my OpenShift application was already safe. The OpenShift Online team finished rolling out the update to production servers a few minutes before the advisory was published.
The new bash package had gone through the RHEL QA process, was signed and added to repositories, and had been tested by the OpenShift Online team on the OpenShift Online staging systems. Since I knew about the vulnerability, I was anxious to get my other systems patched, including the system running that old distro. I checked the vendor’s tracking page several times throughout the day, but each time I checked, there were updates available for some versions of the distro, but not for mine.
Finally, I decided to take matters into my own hands, and so I took a 40-minute afternoon break from work to download the bash source package, then to remind myself how to add a patch to the package build, and finally to rebuild and install the updated package. Of course, moments after I had my home-brew package installed, the fix was published by the vendor too, but that’s just Murphy’s law manifesting itself, right?
Don’t get me wrong, this isn’t a knock on another Linux distro. I wasn’t running a production version and I shouldn’t have been surprised when my version was the last to get updates. And it could have been much worse.
$ sudo cp /bin/bash /bin/bash.old anyone?
Fast forward to today. This time, we had no warning when CVE-2014-7169 was published. Even so, the OpenShift Online team was ready and had a patched bash package from the RHEL and Product Security teams installed and tested on all OpenShift Online systems very soon after the patch became available.
I’m glad to know that my application that runs on OpenShift Online is secure, but I’ll have to ask you to excuse me. I’ve got an old Linux box to patch!
You can read more about the bug in bash and the patches that fix it here: https://access.redhat.com/articles/1200223
OpenShift Online has been used by developers around the world to create over 2 million applications. Today, we’re taking another step to support our growing global customer base by adding a new hosting offering in Ireland for OpenShift Online. Developers can now run their applications with the same functionality from either of our US or European hosting locations.
Maximize application performance by hosting your app closer to end-users. Our initial testing showed significantly reduced latency of over 100ms for European end-users accessing applications hosted in Europe versus the applications hosted in US.
The RHC client tools have been updated allowing you to easily create or migrate applications to a specific region. Check out our Developer Portal for a complete look at region and zone management.
Multi-region availabililty was ranked #2 by our users on the list of most-wanted features. If you have more feedback about multi-region availability or ideas to make your OpenShift user experience better we want to hear from you at openshift.uservoice.com.
Stay informed and learn more about OpenShift by receiving email updates.
If you ask three people what they think DevOps is, you’ll get three answers: “a way of running an IT department”, “a culture”, “something to do with Phoenix”. Ask a fourth person and you might hear “You can use OpenShift for that”.
To see what DevOps has to do with the world’s favourite PaaS, I went along to the “OpenShift By Red Hat: The PaaS for DevOps” technical deep dive in Brisbane that was given as part of a road show in Australia and New Zealand in July and August 2014.
The session was held at Brisbane’s Treasury Hotel, an early 19th century building with an Edwardian-Baroque exterior and the type of pre-air conditioning climate control features that play havoc on wireless signals (thick walls). There were about 50 people there, with an approximate average age somewhere between late 30s and 40s. About 8 in the crowd were Red Hatters in support our very own Katie Miller, who literally wrote the book on OpenShift. Of those 50ish people, five were in DevOps environments and an additional five were experienced with PaaS.
Using DevOps as a “filter for accessing usefulness of PaaS” was Change Architect Stefano Picozzi, the main presenter of the session. From the beginning, he made it clear he wouldn’t make the case for DevOps, that it would be a given. He also described OpenShift in a way I hadn’t heard before, as the “voice of the customer, telling Red Hat what to do”. The OpenShift Online offering makes that uniquely true for OpenShift, as feedback from the mass market version quickly makes its way into the Enterprise version running behind corporate firewalls. Stefano also suggested what the technologist inside of all of us hopes is true; that access the right tech and tools can encourage good decisions, practice, and process.
For those who haven’t been following the ongoing DevOps revolution, or had The Phoenix Project thrown at them, DevOps is a way of resolving the classic tension between developers and system administrators: fast versus predictable. The extent to which a PaaS supports a DevOps team can be measured by the extent to which it increases the velocity of software releases, improves the quality of each release, and reduces waste. As the DevOps army are quick to point out, DevOps is about culture: the DevOps PaaS should also support teaming, regular feedback, and experimentation.
Stefano introduced the work of B.F. Skinner to address OpenShift’s potential cultural impact, in particular the idea that behavior is a result of the feedback loop between antecedent and consequence. To an operator the consequence of deploying software as an OpenShift gear is consistency in managing gears, which is the same regardless regardless of what the gear contains. The consequence of OpenShift on developers is a (potentially) self service development environment that lets you choose the way you work, with IDE integrations, a CLI, a web interface, and stable REST APIs. Developing on OpenShift means six steps to get from app to done: idea, budget, code, test, launch, scale (and the OpenShift handles the scaling part for you by including HA Proxy and integrating with existing load balancers).
Katie Miller then showed the audience how easy it is to get an app running, using one command to set up DNS, a Git repository, ssh access to the Gear set up, and a local clone of the gear’s Git repository. If you’ve seen it before, you might have forgotten how impressive it is to watch that happen, or to see how easy it is to relate to what’s inside the gear. Same goes for watching the app scale in real time.
Stefano followed Katie’s demo Insulter app (insults you in Shakespearean fashion) with some real life examples. Cisco has seen benefits from using OpenShift as their environment for developing lightweight mobile apps, like the ability to use existing yum update infrastructure, to use OpenShift REST APIs to integrate with their existing development infrastructure, and the density of apps they can deploy on a small number of nodes (242 to date). Stefano mentioned one company where the TCO for PaaS versus more traditional deployment scenarios became cheaper when they reached 6 apps.
Project Atomic and Docker showed up toward the end of the session when talking about the future of OpenShift, in the context of pushing more functionality out of OpenShift itself into the operating system so that the OpenShift developers can focus on delivering value at the top of the stack in the form of a better user (developer / operator) experience. Coming soon is the ability to consume more of Red Hat’s middleware projects (BRMS, etc), niche 3rd party capabilities (SAP, Hortonworks, and .NET support thanks to a company called Uhuru (the Swahili word for freedom, also the name of a pan-African movement).
If innovation is creativity at commercial scale, and DevOps is a path to business agility, then OpenShift is especially compelling if it can help address the behavioral anti-patterns that impede DevOps. Stefano and Katie made a compelling case for “OpenShift By Red Hat: The PaaS for DevOps” that seemed to resonate well with the audience in Brisbane, and got me excited about the possibilities OpenShift could open up.
Its been a very busy couple of weeks here on the Openshift Team. We released several really cool features including a whole new gear profile. Lets dive in.
We’ve added a new gear for those of you that want better cpu performance on small gears and trust me they’re fast. I even put together a video that shows you just how fast they really are. If you’re interested in testing them out on your own you can deploy them one of two way.
$ rhc app create -g small.highcpu
We’ve completely reworked our Developer Portal so that its brighter, clearer, and easier to use.
Plus, this is just the beginning. We’ve got tons of experts on the OpenShift Team, working on new documentation that will include more language/framework specific tutorials and walk throughs.
Thats right, if you want to take a peek into the future and even contribute to it take a look at the new public repo at https://github.com/openshift/origin. This is where our brilliant engineers are bringing together Docker, Kubernetes, Project Atomic to make the best damn PaaS on the planet.
First, get up and running with the Contributing Guide.
Once setup, you can:
2.Start an OpenShift all-in-one server (includes everything you need to try OpenShift)
$ _output/go/bin/openshift start
$ cd $GOPATH/src/github.com/openshift/origin $_output/go/bin/openshift kube create pods -c examples/hello-openshift/hello-pod.json
Once that’s done, open a browser on your machine and go to http://localhost:6061; you should see a ‘Welcome to OpenShift’ message.
OpenShift Online recently announced crossing a new milestone. Over two million applications have been created on the platform! This is a significant announcement because it further illustrates how developers are migrating to Platform as a Service to help them rapidly create and deploy applications.
The news for the Platform as a Service space is not so rosy across the board though. I received an email this morning from the CEO of another PaaS announcing that they are shutting down their PaaS service to focus on Jenkins. This blog post will not delve into speculation of why they decided to shut down their PaaS but rather focus on how to migrate your application to the most popular open source PaaS – OpenShift.
OpenShift is an open source Platform as a Service that was started at Red Hat with a couple of key tenets in mind.
Now that we now some of the key reasons that you should choose OpenShift, let’s walk through how to migrate your application code to the platform. I am going to assume that you are using Java for the examples in the remainder of this blog post.
Step 1: Create an account
Signing up for an OpenShift account is a quick and easy process. All you need to do is head over to www.openshift.com and click the sign up button. You may be asking yourself what information you have to provide in order to get started with the platform. I am happy to report that the only two pieces of information you need is your email address and password. That’s right, you don’t even need to provide a credit to start using the platform. This is because we offer every developer the ability to create up to three servers for free to get familiar with the platform.
Step 2: Choose how to interact with the platform
You can interact with OpenShift in many different ways including using the command line, leveraging the feature rich web console, or even using the Eclipse or IntelliJ IDE.
Once you have decided which method works best for you, click the provided link for instructions on how to get up and running:
Step 3: Create your application
Creating an application on OpenShift is quick and easy. All you need to do is provide the name for your application and the runtime that you want to use. For example, if you are using the command line, you would enter in the following command to create a new application called myapp with the JBoss EAP application server.
$ rhc app create myapp jbosseap-6
Creating a new application on the OpenShift platform takes about 30 seconds to complete. Once complete, your application will be available worldwide at the provided URL and the git repository will be cloned to your local machine.
Step 4: Deploying your application
Now that we have our application created, it’s time to deploy our source code to the platform. If you remember from introductory section of this post, I stated one of the key tenets of the platform is for your application code to work as is, without modification. Because of this, all you need to do is copy your source files over and push them to your OpenShift server. To accomplish this, add your source files and enter in the following command from the root directory of your application:
$ git add . $ git commit –am “Adding my source code” $ git push
Once you enter in the git push command, your maven based project will be compiled on the remote OpenShift server and then deployed to your gear. This process can take up to two minutes the first time you compile an application as all of the Java dependencies are downloaded. Don’t worry, future builds will go faster as the dependencies are cached on your OpenShift server.
Step 5: Add continuous integration with Jenkins)
OpenShift also allows developers to use the popular Jenkins server for their applications that are deployed on the platform. If this is something you are interested in doing, please refer to the following OpenShift Developer Center post for the full instructions on how add this capability:
We are pleased to announce the immediate availability of OpenShift Online Small.highcpu gears. The Small.highcpu gear is a new low-cost, production-ready gear designed to provide double the CPU performance of our existing Small gears.
Priced aggressively at just $0.025 per hour, Small.highcpu are the lowest-cost production-ready gears OpenShift Online offers and are ideal for scalable web services and small databases.
Production gears are available in three sizes: Small.highcpu (512MB RAM), Medium (1GB RAM), and Large (2GB RAM) with expandable storage options. See our pricing page for more details.
The Small.highcpu gear is available now to all new and existing Bronze and Silver plan members. Don’t have the Bronze plan? Upgrade today to try out the new gear.
Want to know how the new Small.highcpu gear stacks up against Small? Check out this short demo for a comparison:
As we turn the corner on 2014 and head towards the end of the year, OpenShift Online continues its rapid pace of innovation and growth. Today I want to announce that since launching in 2011, OpenShift Online users have created more than 2 million applications this month. I also want to take this opportunity to look at highlights from the past year.
More and more people are discovering OpenShift and finding it useful. In a survey performed by Linux.com of open source platforms, 54% of respondents said they preferred OpenShift for open source Platform as a Service.
Users appreciate the benefits OpenShift gives and are using it to create millions of applications. Since OpenShift launched in 2011 users have created over 2 million applications. In the past year, application growth increased over 100% (Aug 2013 to Aug 2014).
OpenShift is not created in a vacuum. As an OpenSource project it depends on a community to create it and move it forward. Github’s “State of the OctoVerse” recognized the health of our community by ranking OpenShift Origin #5 in the Community Highlights category for “Most Merged Pull Requests.”
PaaS, continuous integration and delivery, DevOps, and software development best practices are all things OpenShift gives you. We also practice these things ourselves by staying in a fairly consistent three week release process. This means we push new code containing new features and bug fixes to production every three weeks or so. For a look back at what we’ve delivered in 2014, click here.
In November 2013, we announced a 50% price reduction and introduced a new 2GB gear (large gear). We followed this up with the introduction of our popular Bronze plan and storage options. Since we’ve been listening to you on our Ideas page, launching our Non profit and Education program to further our service to both of these sectors. OpenShift Online continues to receive strong support from numerous Universities including several Ivy League schools. OpenShift is a valuable platform to instructors teaching computer programing.
We have spent the last few years hardening the platform and attracting developers from the Fortune 500 companies and various Government agencies. In response to their requests, we have offered the Annual Plan, a pre-paid annual subscription for enterprises to use the flexibility of OpenShift Online without worrying about usage costs.
Customers also told us they wanted to power their applications with options beyond our standard portfolio. In April 2014 we introduced the OpenShift Marketplace, making it easy to add technologies from our partners to your application and use add-ons in a friction-less way.
Developers are doing incredible things with OpenShift Online. Take a walk through the OpenShift Online Application Gallery to see the amazing applications people from around the world have developed. See what can happen when developers are given the freedom to concentrate on their code.
In addition to improving the underlying OpenShift platform, we’ve also been hard at work making it easier to learn about OpenShift and get help. The following areas of our website recently received significant updates:
OpenShift has received and continues to receive prestigious industry awards, including:
See our awards page for all the details.
Have you experienced OpenShift in the public cloud or in your datacenter? Find out what you’ve been missing:
More announcements and expanded offerings are in the works. To receive automatic notification of these announcements, be sure to subscribe.
Welcome to the OpenShift Developer Spotlight where we get to know the members of the OpenShift community a little better and show off their skills as developers.
Interested in being featured? Apply here or view past entries.
When I first discovered the internet, I was living in Nepal and I was amazed by how you could find information about almost anything. A couple of months later I was doing a programming course ( HTML, Classic ASP and SQL Server) and I loved it and I realized I had found my passion. For me, programming is like a puzzle which I have to solve and I find it really fun.
I was trying to find a PHP PaaS that was easy to setup and deploy. After trying some, I realized that OpenShift was the best in terms of price, ease of use and feature set. You can sign up, create an application, pull and push code using git and map your custom domain in less than 1 hour! That’s awesome.
I think OpenShift has the best pricing model. Setting up domain names is incredibly easy compared to some other PHP PaaS providers. The uptime is great and deploying code is super easy.
At the recent Gartner Catalyst conference, the OpenShift team was invited to join a panel focused on Platform as a Service frameworks. It was a great opportunity to review market trends, get in touch with the audience and openly discuss the differences between our respective PaaS offerings in terms of capabilities, philosophical approach and architecture.
Gartner analyst Eric Knipp also presented on “Building a Software Factory with a Private PaaS” where he explored how enterprise customers can “use cloud computing to improve developer agility while retaining control of the platform.” During this session, Eric discussed how to drive developer productivity with “open PaaS frameworks that standardize, automate and simplify the software development life cycle.” He then reviewed the two dominant open source PaaS platforms, OpenShift and Cloud Foundry. Today, I wanted to take the opportunity to go deeper on a few of the topics discussed, both during the conference and since.
One of the key items that Eric discussed was how PaaS frameworks should integrate with the infrastructure provisioning layer and cloud management platform. The OpenShift platform can be deployed on either bare metal servers, an existing virtualization platform (i.e. vSphere, Hyper-V, RHEV/KVM, etc.), private IaaS cloud (i.e OpenStack) or public cloud (i.e. Amazon, Google). A specific question that was raised related to the recovery of OpenShift Node instances and how that impacts application availability. In OpenShift a “Node” is a virtual or physical machine that acts as a container host and runs end user applications in Linux containers or “Gears”. A typical deployment will have many Nodes, controlled by an OpenShift Broker tier that handles orchestration and scheduling.
There are some important architectural differences to understand here. First, OpenShift Nodes can run on either virtual machines or physical machines, whereas many competing PaaS solutions only run in VMs. In addition, while some PaaS solutions only support stateless applications and don’t provide a persistent filesystem option for writing to local storage, OpenShift supports stateless applications as well as stateful application processes that can write to a persistent filesystem mapped to each Gear. OpenShift also is unique in supporting a full Java EE service with JBoss that also supports stateful clustering with session replication. So there are a number of inherent differences in managing Node hosts, due to the extra functionality OpenShift provides.
While some PaaS frameworks like Cloud Foundry provide a separate management tool for the underlying VM infrastructure which is limited to specific virtualization platforms, OpenShift is more flexible. We work to integrate with provisioning and configuration management tools customers already have in place, to both deploy OpenShift on their choice of bare metal, virtual, private or public cloud platforms and handle ongoing management of the OpenShift Node and Broker infrastructure. These include popular provisioning and configuration management tools like Puppet, Ansible, Chef as well as other monitoring and management tools deployed in a customer’s infrastructure. As a result we have been expanding our investment in providing general purpose automation scripts and expanding integration with leading management tools, sharing best practices from our OpenShift Online Operations team and integrating contributions from customers and community members like Cisco. We have also integrated with OpenStack Heat for deploying OpenShift on OpenStack and integrated with Red Hat CloudForms cloud management platform for deploying and managing the OpenShift PaaS platform in a hybrid cloud environment.
For application availability, OpenShift also provides built-in functionality such as regions & zones which allows you to group Nodes into different availability zones and enforce anti-affinity across zones for multi-container deployments. We also provide a Node watchman feature to monitor and restart failed application processes. This demo shows watchman in action for both a single instance and clustered JBoss application scenario.
We also recently announced our plan for continuing to improve our orchestration & scheduling capabilities in OpenShift v3 working with both Docker and Google Kubernetes communities.
Some additional questions were raised on the way OpenShift handles container isolation, without providing the full context how our platform works and key benefits we provide. As we’ve discussed in a prior post, OpenShift leverages Linux Containers, or what we refer to as “Gears”, to deploy and run applications in a secure multi-tenant platform.
Once users deploy their application, they have the flexibility to work from our Web console, CLI or IDE interfaces or to SSH directly into their Gears and execute commands for additional debugging. Features like remote debugging via SSH or direct debugging from Eclipse are what drive the developer experience that OpenShift users value. However, a competitor raised the fact that you can run commands like netstat from within an OpenShift Gear container and questioned us on security. While no system is completely immune from the threat of malicious hackers, the ability to execute these commands inside a Gear does not mean it is actually insecure, as was later noted. This is due to the multi-layer container security model OpenShift implements.
OpenShift container security and isolation is handled by a combination of kernel namespaces and SELinux. The value of SELinux as an additional security layer in containerized environments is something we’ve been discussing for years and it’s what has enabled us to manage our public OpenShift Online environment and the nearly 2 Million applications deployed on it since launch. The value of a layered security approach for containerization, leveraging solutions like SELinux or AppArmor, was recently highlighted by Docker in a blog on container security, in response to a published exploit. Red Hat’s own Dan Walsh, who works closely with us on OpenShift, contributed Docker’s SELinux enablement and is a member of the Docker governance board, recently discussed container security as well for opensource.com. Although we don’t view OpenShift’s ssh capabilities as an inherent security risk, we do plan to limit certain commands like netstat within an ssh session to remove any user concerns.
A final point of discussion was around application scaling. A competing PaaS vendor was discussing how quickly they could manually scale up large numbers of application instances on their PaaS. This was being compared against manual Gear scale-up times for our OpenShift Online service. It wasn’t clear however whether the tests were running on equivalent infrastructure or that the scenarios actually represented real world use cases, as you might expect from a true performance benchmark. In the case of OpenShift Online, the test was running a JVM-based application in resource constrained Small Gears, using our OpenShift Online free service tier, which is not what we’d recommend for running Java applications at scale.
In our experience, autoscaling, rather than manual scaling, is a key PaaS capability that customers we speak to are more interested in. This demo shows OpenShift’s autoscaling capabilities in action.
In OpenShift, when autoscaling is enabled, an increasing application load will trigger the automatic scale-up of additional application container instances, a feature most other PaaS providers can’t provide. OpenShift will also automatically scale instances down when load decreases and has built-in flap protection to avoid scaling up or down prematurely in response to transient load spikes. OpenShift can also idle inactive applications, to free up compute resources on the Nodes and drive greater density by optionally overcommitting Node resources. In the end it comes down to what features are most important to customers, for their particular application scenarios.
When it comes to choosing a PaaS provider, customers have many choices, including both Public and Private PaaS solutions. This increasingly competitive market landscape drives innovation forward and is good for customers. We are happy that so many customers have chosen OpenShift, are proud of the recognition OpenShift has received in the market and how we have faired in independent head-to-head comparisons. We will continue to drive new innovations and advance OpenShift forward based on feedback from our customers, partners, community members and users.