OpenShift: the ultimate guide to the ultimate PaaS
OpenShift is a PaaS platform produced by Red Hat that leverages container technologies such as Docker and Kubernetes. With its outstanding features that allow both developers and administrators to meet halfway, OpenShift is a solid infrastructure to build and deploy apps on.
PaaS: Developing, deploying made easier
PaaS solutions are built to help developers focus on the code rather than the platform it will run on. By abstracting the developer from setting up the operating system, and setting up the environment (platform) the PaaS solution allow for easy and swift project deployments with baked-in features such as clustering, scaling, monitoring and more, depending on the solution.
The PaaS paradigm is also close to the DevOps model and can be used, depending on the software, to implement DevOps practices as continuous integration or continuous deployment.
Applications? A PaaS subject
Imagine a simple web application, chances are three major components are involved:
- The web server
- The language interpreter (usually PHP, Python or Ruby)
- The database
When a developer is tasked with setting up the web server and the database he surely will be able to set them up on his machine, but will he be able to do the same in production? What about zero-downtime? Scaling? Self-healing? Many of these sysadmin-ish words are unknown to many developers and more often than not what works on localhost isn’t guaranteed to run on remote.
This is what PaaS solutions were created for. The developer interacting with a PaaS solution will not need to trouble with web servers or databases at all, the system will abstract everything away and the developer will be able to focus on his work: developing applications.
Discover the OpenShift platform: PaaS on steroids
The OpenShift platform is a modern PaaS solution that leverages Docker and Kubernetes. The OpenShift cluster can spawn multiple machines and once set up it is a solid development platform that allows:
- Cluster management
- Cluster scaling
- Application scaling
- Application monitoring
- Application self-healing
- and more…
Applications living in containers will be accessible through routes from the outside. In the latest versions of OpenShift a support for the so-called cloud-native storage (based on GlusterFS) was added in order to achieve data persistency. This latest addition is particularly useful since there is no need to trouble configuring Docker Volumes on top of complicated back-ends.
OpenShift terminology and containers
In OpenShift, the highest form of abstraction is a project. A project is a namespace and multiple projects are isolated from each other even when on the same machine. Inside a project there are containers. Containers are the most important thing inside OpenShift, the applications you write live inside containers. OpenShift uses Docker containers. There are currently three ways to create a container:
- Source 2 Image: the preferred way is to track a git repository containing the code of the application. The code is then built into an image that is used to spin the container.
- Docker image: you can pull images directly from a Docker Registry (such as Docker Hub).
- Templates: written for OpenShift can easily be imported and customized to achieve faster deployments.
One platform, multiple interfaces, self-service development
Once the cluster is up and running, both developers and administrators will have access to three interfaces:
- The Web interface: allows easy-to-use, graphical workflow. It is easy to get started with and developers can interact with the platform just using a web browser.
- The Command Line Interface: allows faster operations, but it must be installed on the client machine. The client is not bound to one specific cluster, and the user can log into multiple clusters with the same interface, although not at once.
- The OpenShift and Kerberos API: both API allow the developer to interface its software with the cluster using RESTful APIs.
OpenShift flavors to suit all tastes
There are multiple OpenShift flavors, each one with its model and use case:
- OpenShift Origin: is the upstream project behind the hosted and enterprise flavors. You can download and use it for free, the project is open source.
- OpenShift Container Platform: is the enterprise version of Origin supported by Red Hat available for private on-premise deployments. You can buy it alongside with Red Hat support.
- OpenShift Online: is the Red Hat hosted version, it comes with a free tier and subscription plans with monthly/daily/hourly payments. This solution is for companies looking to build their small/mid-sized applications on a solid infrastructure managed by a provider (Red Hat).
- OpenShift Dedicated: is a service by Red Hat hosted on public clouds, currently only Amazon Web Services and Google Cloud Platform are available. This solution, mostly for large companies, enables them to leverage the power of OpenShift managed by Red Hat without compromising performance.
As you can see there are many different ways to use OpenShift from a developer/consumer point of view. The fact the flavors run on different platforms may lead you to think these are different “versions”, but they ar not! As a matter of fact applications written for OpenShift will run fine regardlessly of their underlying platform.
From Source 2 Image (S2I)
One of the greatest features of OpenShift is the ability to build Docker Images directly from source code. The feature links one container to a git repository by tracking a branch. This is especially useful for developers since they can simply push the changes to the tracked branches and the system will automatically rebuild the image and deploy it according to the configuration. OpenShift can currently be integrated with virtually any git repository such as GitLab or GitHub. The image is built using a base “template” provided by OpenShift and the code is then baked in as a new image.
OpenShift currently supports many languages and databases out of the box such as:
- Java
- JavaScript
- PHP
- Python
- Ruby
- MariaDB/MySQL
- PostgreSQL
Of course there is more to this list, but if you can’t find your favorite language/run-time all you have to do is simply create a DockerFile containing your application.
OpenShift v2 or v3?
Starting from 2015 and during 2016-2017, a complete rewrite of OpenShift v2 source code took place. Resulting from that was the newly born OpenShift v3. Although they share the same name and the same purpose version 2 and version 3 are pretty different under the hood. For example, if you’ve used version 2 you’ve probably seen gears and cartridges, these two fundamental entities are completely gone in version 3.
OpenShift v2 was mostly engineered from scratch by Red Hat engineers and didn’t even use Docker. OpenShift v3 was built on top of (and underneath) Kubernetes and Docker. This fundamental shift was essential to achieve better features, and since the container world was focused on the Docker+Kubernetes combination, Red Hat decided to embrace both projects and contribute with their experience at running large container sets at scale.
Hence, be careful about the version you’re using. An application written for v2 needs to be migrated to v3 in order to work.
OpenShift.io
OpenShift.io is an open online development environment for planning, creating and deploying hybrid cloud services.
Not to be confused with the PaaS solution, OpenShift.io (OSIO) is a tool to aid development, planning and deployment of cloud services. OSIO is a development platform that integrates agile methodologies by using agile tools such as Kanban boards and backlogs. The platform enables teams to collaborate better and have their projects directly integrate through continuous integration/deployment with OpenShift Online.
The platform also monitors the code using machine learning algorithms to enable better decision making, and also detects potential CVEs. If you’re interested, you can find a list of features here.
The project is mainly based on Fabric8 and Eclipse Che, both open source projects.
Is OpenShift a Kubernetes distribution?
Until version 3, OpenShift did not use Kubernetes at all. You might think that means that it is not a Kubernetes distribution, but in fact we could say it is… and it isn’t.
Sure, OpenShift v3 packs Kubernetes, but Kubernetes alone isn’t able to do everything OpenShift does. Take the aforementioned S2I or continuous integration through Jenkins. Those features aren’t tied to Kubernetes, they’re features added by OpenShift on top of Kubernetes. That is because Kubernetes is just an orchestration tool while OpenShift is a full-fledged PaaS solution.
It is safe to say that OpenShift indeed is a Kubernetes distribution, but it also adds many more features. So it would be a great mistake to think it is a Kubernetes distribution only.
Want to try OpenShift? Discover Minishift: OS in a box
If you’re interested in OpenShift but don’t want to set up a cluster on real hardware this section is for you. There are currently two ways to run OpenShift without using real hardware:
- Installing OpenShift Origin in a container. (Yes, containerception.)
- Using Minishift.
Minishift is a great way to test OpenShift capabilities without committing hardware to it. By using Minishift you will set up a virtual machine on your hardware, this vm will be your very own one-machine cluster and when you will be done you can simply throw it away. You also don’t need to worry about making mistakes since you can always start over.
Minishift is currently supported on all the major operating systems:
- Windows: using Hyper-V or VirtualBox.
- OS X: using Xhyve or VirtualBox or VMware Fusion.
- Linux: using Libvirt or VirtualBox.
Before starting it is important to have the selected virtualization software installed and enabled. In order to get started simply go to the Minishift releases page and download the executable according to your operating system and architecture. Once done you can refer to the installation document in order to install Minishift. Since the procedure is different for each operating system/virtualization you need to follow each instruction carefully, but it usually all comes down to adding the minishift binary location to PATH. Once done you can simply start the cluster by issuing in a command line:
minishift start
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020
Recent Comments