Getting Started

OpenShift Container Platform brings together Docker and Kubernetes, and provides an API to manage these services. OpenShift Container Platform allows you to create and manage containers.

This guide introduces you to the basic concepts of OpenShift Container Platform, and helps you install a basic application. This guide is not suitable for deploying or installing a production environment of OpenShift.

master.openshift.example.com. 300 IN A <IP of the master>
node.openshift.example.com. 300 IN A <IP of the node>
*.apps.openshift.example.com. 300 IN A <IP of the node>

*.cloudapps.openshift.example.com. 300 IN A <IP of the node>

$ subscription-manager repos --enable="rhel-7-server-rpms" --enable="rhel-7-server-extras-rpms" --enable="rhel-7-server-ose-3.6-rpms" --enable="rhel-7-fast-datapath-rpms"

$ yum -y install wget git net-tools bind-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
$ yum -y update
$ yum -y install atomic-openshift-utils
$ yum -y install atomic-openshift-excluder atomic-openshift-docker-excluder
$ atomic-openshift-excluder unexclude
$ yum -y install docker-1.12.6

$ ssh-keygen

for host in master.openshift.example.com node.openshift.example.com; do
ssh-copy-id -i ~/.ssh/id_rsa.pub $host; done

$ atomic-openshift-installer install

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

oc get nodes

OpenShift Container Platform provides two command line utilities to interact with it.

Use oc --help and oc adm --help to view all available options.

In addition, you can use the web console to manage projects and applications. The web console is available at https://<master-fqdn>:8443/console. In the next section, you will see how to create user accounts for accessing the console.

By default, when installed for the first time, there are no roles or user accounts created in OpenShift Container Platform, so you need to create them. You have the option to either create new roles or define a policy that allows anyone to log in (to start you off).

Before you do anything else, log in at least one time with the default system:admin user, on the master run the following command.

$ oc login -u system:admin

By logging in at least one time with this account, you will create the system:admin user’s configuration file, which will allow you to log in subsequently.

There is no password for this system account.

To continue configuring your basic OpenShift Container Platform environment, follow the steps outlined in Configure OpenShift Container Platform.

This guide introduces you to the basic concepts of OpenShift Container Platform, and helps you configure a basic application. This guide provides the configuration steps following the installation of a basic OpenShift Container Platform environment, and is not suitable for deploying or installing a production environment of OpenShift.

The default behavior of a freshly installed OpenShift Container Platform instance is to deny any user from logging in. To change the authentication method to HTPasswd:

Now that you are using the HTPasswdPasswordIdentityProvider provider, you need to generate these user accounts.

Before going forward, change to the default project.

oc project default

For more details, see roles and authentication.

The OpenShift router is the entry point for external network traffic destined for OpenShift services. It supports HTTP, HTTPS, and any TLS-enabled traffic that uses SNI, which enables the router to send traffic to the correct service.

Without the router, OpenShift services and pods are unable to communicate with any resource outside of the OpenShift instance.

The installer creates a default router.

The OpenShift documentation contains detailed information on Router Overview.

Openshift provides an internal, integrated Docker registry that can be deployed to locally manage images. OpenShift uses the docker-registry to store, retrieve, and build Docker images, as well as deploy and manage them throughout their lifecycle.

The installer creates a default registry.

This getting started experience walks you through the simplest way to get a sample project up and running on OpenShift Container Platform. There are a few different ways to launch images within a project, but this topic focuses on the quickest and easiest method.

If this is the first part of the documentation you have read, and you are unfamiliar with the core concepts of OpenShift Container Platform version 3 (v3), you might want to start by reading about what’s new. This version of OpenShift Container Platform is significantly different from version 2 (v2).

OpenShift Container Platform 3 provides out of the box a set of languages and databases for developers with corresponding implementations and tutorials that allow you to kickstart your application development. Language support centers around the Quickstart templates, which in turn leverage builder images.

Other images provided by OpenShift Container Platform include:

In addition, JBoss Middleware has put together a broad range of OpenShift Container Platform templates as well as images as part of their xPaaS services.

The technologies available with the xPaaS services in particular include:

With each of these offerings, a series of combinations are provided:

To help illustrate constructing such applications, the following sections guide you through creating a project that contains a sample Node.js application that will serve a welcome page and the current hit count (stored in a database).

Before you can get started:

To create an application, you must first create a new project, then select an InstantApp template. From there, OpenShift Container Platform begins the build process and creates a new deployment.

The Select Image or Template page gives you the option to create from a publicly accessible git repository, or from a template:

Creating your application might take some time. You can follow along on the Overview page of the web console to see the new resources being created, and watch the progress of the build and deployment.

While the Ruby pod is being created, its status is shown as pending. The Ruby pod then starts up and displays its newly-assigned IP address. When the Ruby pod is running, the build is complete.

If your DNS is correctly configured, then your new application can be accessed using a web browser. If you cannot access your application, then speak with your system administrator.

To view your new application:

You forked the source code for this application from the OpenShift Container Platform GitHub repository. Therefore, you can use a webhook to automatically trigger a rebuild of your application whenever you push code changes to your forked repository.

To set up a webhook for your application:

GitHub now attempts to send a ping payload to your OpenShift Container Platform server to ensure that communication is successful. If you see see a green check mark appear next to your webhook URL, then it is correctly configured. Hover your mouse over the check mark to see the status of the last delivery.

The next time you push a code change to your forked repository, your application will automatically rebuild.

To work locally and then push changes to your application:

Now going forward, all you need to do is push code updates and OpenShift Container Platform handles the rest.

This getting started experience walks you through the simplest way to get a sample project up and running on OpenShift Container Platform. There are a few different ways to launch images within a project, but this topic focuses on the quickest and easiest method.

If this is the first part of the documentation you have read, and you are unfamiliar with the core concepts of OpenShift Container Platform version 3 (v3), you might want to start by reading about what’s new. This version of OpenShift Container Platform is significantly different from version 2 (v2).

OpenShift Container Platform 3 provides out of the box a set of languages and databases for developers with corresponding implementations and tutorials that allow you to kickstart your application development. Language support centers around the Quickstart templates, which in turn leverage builder images.

Other images provided by OpenShift Container Platform include:

In addition, JBoss Middleware has put together a broad range of OpenShift Container Platform templates as well as images as part of their xPaaS services.

The technologies available with the xPaaS services in particular include:

With each of these offerings, a series of combinations are provided:

To help illustrate constructing such applications, the following sections guide you through creating a project that contains a sample Node.js application that will serve a welcome page and the current hit count (stored in a database).

Before you can get started:

To create an application, you must create a new project and specify the location of the source. From there, OpenShift Container Platform begins the build process and creates a new deployment.

After creating the new project, you will be automatically switched to the new project namespace.

To create a new application from the code in your forked repository:

Creating your application might take some time. You can follow along on the Overview page of the web console to see the new resources being created, and watch the progress of the build and deployment. You can also use the oc get pods command to check when the pod is up and running, or the oc get builds command to see build statistics.

While the Ruby pod is being created, its status is shown as pending. The Ruby pod then starts up and displays its newly-assigned IP address. When the Ruby pod is running, the build is complete.

The oc status command tells you what IP address the service is running; the default port it deploys to is 8080.

An OpenShift Container Platform route exposes a service at a host name, so that external clients can reach it by name. To create a route to your new application:

To view your new application, paste the route location that you copied (in the previous section) into the address bar of your web browser and hit enter.

The example ruby-ex application is a simple welcome screen, and contains details on how to deploy code changes, manage your application, and other development resources.

Next, configure automated builds via a GitHub webhook trigger, so that code changes in your forked repository cause your application to rebuild.

You forked the source code for this application from the OpenShift Container Platform GitHub repository. Therefore, you can use a webhook to automatically trigger a rebuild of your application whenever you push code changes to your forked repository.

To set up a webhook for your application:

GitHub now attempts to send a ping payload to your OpenShift Container Platform server to ensure that communication is successful. If you see see a green check mark appear next to your webhook URL, then it is correctly configured. Hover your mouse over the check mark to see the status of the last delivery.

The next time you push a code change to your forked repository, your application will automatically rebuild.

To work locally and then push changes to your application:

Now going forward, all you need to do is push code updates and OpenShift Container Platform handles the rest.

$ oc start-build ruby-ex

Changing Projects

Although the oc new-project command automatically sets your current project to the one you’ve just created, you can always change projects by running:

$ oc project <project-name>

To view a list of projects:

$ oc get projects

Manually Triggering Builds

If the build does not start automatically, start a build and stream the logs:

$ oc start-build ruby-ex --follow

Alternatively, do not include --follow in the above command, and instead issue the following command after triggering the build, where n is the number of the build to track:

$ oc logs -f build/ruby-ex-n

OpenShift Container Platform 3.6 Initial Release