This is Part 1 of a 2 part series of blogs that will help you bringing your applications into OpenShift.
OpenShift 3 allows you to deploy your application to the cloud and the great thing is it doesn’t matter if your cloud is public, private, or even hybrid. Typically, the PaaS platform (OpenShift in this case) will provide a set of predefined runtimes that a developer can use to deploy an application on top of. This developer does not need to worry about the infrastructure, the runtime setup, or the configuration, he/she would just need to focus on their application, and what runtime to use. The PaaS platform will take care of sewing it all together and running it.
However, sometimes not all the runtimes are provided by the PaaS platform, or that the usages of these runtimes are not suitable for every application type, and there is a need for the PaaS provider to facilitate these to their users.
As a PaaS provider you’ll need to provide users with:
-
runtimes (a.k.a platforms)
-
configured usages of the runtimes for applications
Runtimes
As OpenShift 3 relies on containers, the runtimes will be base images that provide the underlying foundation to deploy an application (provided by the user) on top of. The containers also need to be highly configurable so there is no need to provide a single image for every use case. Instead, a different configuration provided to the image will make the runtime work as desired.
OpenShift 3 provides some base images certified and ready to use out of the box:
OpenShift provides users with the ability to inject/layer/build source code into these images, as they are created for S2I (Source-To-Image) purposes.
OpenShift 3 also provides some base images with database runtimes that can be used or extended:
Configured usages of the runtimes
OpenShift 3 provides a set of predefined runtime use cases, that are user configurable, and allow for the deployment of applications. These predefined runtimes are modeled as OpenShift templates.
OpenShift 3 provides the following templates that a Developer can use to simplify the build and deployment process for an application with an existing Git source repository:
-
JavaEE application running on an EAP server
-
JavaEE application running on an EAP server and using an ephemeral database (PostgreSQL, MySQL, MongoDB)
-
JavaEE application running on an EAP server and using a persistent database (PostgreSQL, MySQL, MongoDB)
-
Web application running on a Tomcat Container
-
Web application running on a Tomcat Container and using an ephemeral database (PostgreSQL, MySQL, MongoDB)
-
Web application running on a Tomcat Container and using a persistent database (PostgreSQL, MySQL, MongoDB)
-
ActiveMQ brokers with ephemeral storage
-
ActiveMQ brokers with persistent storage
-
Ephemeral database (PostgreSQL, MySQL, MongoDB)
-
Persistent database (PostgreSQL, MySQL, MongoDB)
-
Instant apps for Perl, Python, Ruby, PHP, Node.js
|
Note
|
Instant apps are preconfigured example applications including source code that can be forked and altered, providing a quick experience deploying an app in a popular platform. |
As you can probably guess, not all possible combinations and capabilities for a runtime or set of runtimes can be provided out of the box, and in many cases, the PaaS provider will have to create more of these for the end user.
What is a template
The official OpenShift 3 documentation states:
A template describes a set of objects that can be parameterized and processed to produce a list of objects for creation by OpenShift. The objects to create can include anything that users have permission to create within a project, for example services, build configurations, and deployment configurations. A template may also define a set of labels to apply to every object defined in the template.
This means that typically in a template we will have:
-
A set of resources that will be created as part of "creating/deploying" the template
-
A set of values for the parameters defined in the template
-
A set of labels to describe the generated resources
A template will be defined in JSON or YAML format, and will be loaded into OpenShift for user instantiation, also known as application creation.
The templates can have global visibility scope (visible for every OpenShift project) or project visibility scope (visible only for a specific project).
Benefits of using templates
A template provides developers with an easy way to create all the necessary OpenShift resources for their application to work. This allows a developer to quickly deploy an application without having to understand all of the internals of the OpenShift 3 platform.
-
As a PaaS provider you have better control on what is being created and can make better usage of your resources.
-
As a PaaS provider you can define different Service Level Agreements in templates, defining the amount of host resources (cpu, memory) each and every container can consume.
Predefined templates, or deploy your application on OpenShift
Typically, the PaaS provider will provide users with a set of predefined templates that will cover all of the usages or typologies/topologies of applications that can be deployed on OpenShift.
The set of predefined templates will be accessible through the CLI or through the Web console.
When creating your application using one of these templates, the user will typically provide the template with the source for the code of the application and some other configuration items such as the application name, database credentials, etc.
Custom templates, or OpenShiftify your application
Another use case is when you have a typology/topology of an application that does not fit into the provided templates and you want to create a template to model it. This will be the topic for the next article, a walkthrough on how to create a template for your application.
