Openshift Introduction

Openshift/Kubernetes Background Introduction

For simple applications, running a few Docker containers is a relatively straightforward task. This becomes a challenge once the complexity of the application increases. If you require a strong level of availability in your application, how will you ensure this uptime? If traffic increases due to popularity, how do you handle scaling? What about continuous deployment strategies? These are some of the challenges that container PaaS offerings attempt to solve. Openshift is one example - it is (in the simplest terms), Kubernetes for the enterprise. While there are multiple flavors of Openshift available (e.g. Origin and Container Platform) we will focus on Openshift Origin, which is the upstream project.

Because Kubernetes plays such a vital role in Openshift, it is suggested that you give the Kubernetes Overview page a look (sections one through five): https://kubernetes.io/docs/tutorials/kubernetes-basics/

Note that while not all Kubernetes concepts are used or congruent in Openshift land, the overview should provide most of the fundamental knowledge of how it powers Openshift
The rest of this document will discuss concepts strictly from what Openshift supports

Reference guides and helpful links

Origin official documentation https://docs.openshift.org/latest/welcome/index.html

Application creation https://docs.openshift.org/latest/dev_guide/application_lifecycle/new_app.html

Deployment configuration https://docs.openshift.org/latest/dev_guide/deployments/basic_deployment_operations.html#dev-guide-basic-deployment-operations

Using images https://docs.openshift.org/latest/dev_guide/managing_images.html

Best practices for images http://docs.projectatomic.io/container-best-practices/

Concepts Discussion

##Openshift Resources

A brief list and introduction of various Openshift resources are provided below. The descriptions are by no means comprehensive, and readers are recommended to follow the provided links for additional coverage.

Pods

At the core, applications in Openshift are run as pods. These are simply Docker containers running on a schedulable host. This can be verified by running a docker ps command on the host - when the application is up you should be able to see an active container with the name of your application, along with a corresponding "origin-pod" or "ose-pod" container which is part of the infrastructure components.

Pods by themselves are not particularly practical. They can surely run your application, but various management features of Openshift will not be available, for example, ensuring availability of the application if the pod becomes disabled.

Replication Controllers (i.e. ReplicationControllers)

ReplicationControllers provides a way to ensure that a certain number of pods are always running. This is one of the methods to help ensure application availability. In addition, the controllers also allow you to specify a particular configuration for your pods when they are created, such as their metadata and ports to be used.

Note that the ReplicationController resource have largely been superceded by DeploymentConfigs. It's likely the case that you won't be directly creating one, but it is still helpful to understand the functionality that it provides

Deployment Configurations (i.e. DeploymentConfigs)

DeploymentConfigs have the ability to create replication controllers and assume the features that they provide. In addition, DeploymentConfigs also provide a few extra abilities:

A way to define when your application should redeploy itself, such as if the underlying image of your application changes
A way to modify how the deployment should behave when a redeployment occurs. For example, the default behavior is rolling, which follows a canary deployment scheme
Hooks that allow deployments to be modified before and after they trigger, such as running a particular command before your application starts to deploy

Services

Services are what allow your applications to be reachable in a meaningful way. Without being backed by a Service, your pods can only be accessed either from within the node that it lives in or via the podIP, which exists for as long as the pod is active. These two methods aren't particular helpful to ensuring that your application remains accessible - if a pod is recreated, for example, then it is assigned a new podIP.

Through a service, pods are assigned cluster IPs from a pool of internal IPs. In addition, an environment variable with the name of the service and the value of that IP is made available to other pods so that they can reference the original service using the service name. Services then not only allow your applications to reference one another easily, but it also makes sure that your pods continue to be accessible if they are recreated (e.g. during a redeployment).

Routes

Routes allow your applications to be accessed from outside of Openshift. For this to be meaningful, you would also want to set up a DNS to route to your hostname.

Image Streams (i.e. ImageStreams)

ImageStreams represent a number of versions (i.e. tags) of an image. Applications that references an imagestream have the ability to redeploy itself when a new version of the image becomes available; this is defined within the application's deploymentconfig.

Templates

Templates serve as a composition of a group of Openshift resources. Typically, they are used to enable an application and its dependencies to be instantiated all at once. This is very useful especially for convenience as this makes it possible to define all the different DeploymentConfigs, Services, and Routes of an application's components, and then be able to deploy everything in a single command; even for simple applications, this is very useful for debugging as it allows applications to be quickly torn down and re-created.

Creating templates from scratch is not a simple task. For this reason, it is recommended that the oc export command be used to create templates from an already running (preferably configured) application to use as the template's baseline.

Workflows

There are many different workflows that Openshift supports to deploy a given application and this reference doc will attempt to cover some of them.

Docker image with private registry

This method that we will primarily use will have you build a Docker image from an existing application, push it to a private registry, and have Openshift deploy that image. For brevity, authentication/accessibility steps are omitted; make sure that you have access to your private registry and the Openshift CLI

Build your image and tag it appropriately

docker build -t registry/image_name:tag_name .

Push the image

docker push registry/image_name:tag_name

Create a new Openshift project and the secrets for your registry

oc new-project project_name
oc secrets new-dockercfg secret_name --docker-username=username --docker-password=password --docker-email=doesnt_matter --docker-server=registry_url
oc secrets link default secret_name --for=pull
* The secret should be linked to the service account that your project deploys with, as it will use the credentials to initiate the docker pull process. By default the "default" service account will be used

Create an imagestream from your image

oc import-image imagestream_name --from=image_name --confirm
* The image_name refers to the same image name including the tag from the first step
* Supply the --insecure flag if your Docker registry isn't configured to use https

Start a new deployment using the imagestream
```
oc new-app -i imagestream_name
```
Wait a moment for your app to deploy. You can also check its status
```
oc status -v
```