Applications

Applications

You are viewing documentation for a release that is no longer supported. The latest supported version of version 3 is [3.11]. For the most recent version 4, see [4]

Applications in OpenShift v2

Applications have always been the focal point within OpenShift. In OpenShift v2, an application was a single unit - it consisted of one web framework and no more than one of any given cartridge type. So an application could have one PHP and one MySQL, for example, but it could not have one Ruby, one PHP, and two MySQLs. It also could not be a MySQL cartridge by itself.

The limited scoping for applications meant that OpenShift could perform seamless linking for all components within an application using well-defined environment variables. Every web framework knew how to connect to MySQL using the OPENSHIFT_MYSQL_DB_HOST and OPENSHIFT_MYSQL_DB_PORT variables, for example. But this linking was limited to within an application and only worked within cartridges designed to work together. There was nothing to help link across application components, such as sharing a MySQL instance across two applications.

Applications in OpenShift v3

From OpenShift v2 it was clear that solving the problems of the entire application is essential. Most other PaaSes limit themselves to web frameworks and rely on external services for the other types of components. OpenShift v3 takes the next steps by making even more application topologies possible and making existing topologies more manageable.

The first step necessary to accomplish this is to remove “application” as a keyword since “application” can mean something different to everyone. Instead, you can have as many components as you desire, contained by a project, flexibly linked together, and optionally labeled to provide any groupings or structure. This new model allows for a standalone MySQL instance, or one shared between JBoss components, or really any combination of components you can imagine.

Flexible linking means you can link any two arbitrary components together. As long as one component can export environment variables and the second component consume values from those environment variables, with potential variable name transformation, you can link together any two components without having to change the images they are based on. So the best containerized implementation of your desired database and web framework can be consumed directly rather than you having to fork them both and rework them to be compatible.

The result means you can build anything on OpenShift. And that is the problem OpenShift really aims to solve: a platform built on containers that lets you build entire applications in a repeatable lifecycle.