This is a cache of https://docs.openshift.com/enterprise/3.0/install_config/install/first_steps.html. It is a snapshot of the page at 2024-11-29T04:45:12.012+0000.
First Steps - Installing | Installation and Configuration | OpenShift Enterprise 3.0
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

First Steps

Overview

You can populate your OpenShift installation with a useful set of Red Hat-provided image streams and templates to make it easy for developers to create new applications. By default, the quick installation and advanced installation methods automatically create these sets in the openshift project, which is a default project to which all users have view access.

Use the following instructions to create the objects yourself. The files are installed on the file system of your master.

This topic is only necessary if you installed OpenShift using a method other than the quick installation or the advanced installation. Image streams and templates will be automatically populated in the openshift project when using these methods.

Prerequisites

  • The integrated Docker registry service must be deployed in your OpenShift installation.

  • You must be able to run the following CLI commands with cluster-admin privileges, because they operate on the default openshift project.

  • You must have cloned the repository that contains the supported imagestreams:

    $ git clone https://github.com/openshift/openshift-ansible

Creating Image Streams for OpenShift Images

The core set of image streams provide images that can be used to build Node.js, Perl, PHP, Python, and Ruby applications. It also defines images for MongoDB, MySQL, and PostgreSQL to support data storage.

If your node hosts are subscribed using Red Hat Subscription Manager and you want to use the Red Hat Enterprise Linux (RHEL) 7 based images:

$ oc create -f \
    openshift-ansible/roles/openshift_examples/files/examples/image-streams/image-streams-rhel7.json \
    -n openshift

Alternatively, to create the core set of image streams that use the CentOS 7 based images:

$ oc create -f \
    openshift-ansible/roles/openshift_examples/files/examples/image-streams/image-streams-centos7.json \
    -n openshift

It is not possible to create both the CentOS and RHEL sets of image streams because they use the same names. If you desire to have both sets of image streams available to users, either create one set in a different project, or edit one of the files and modify the image stream names to make them unique.

Creating Image Streams for xPaaS Middleware Images

The xPaaS Middleware image streams provide images for JBoss EAP, JBoss JWS, and JBoss A-MQ. They can be used to build applications for those platforms using the provided templates.

To create the xPaaS Middleware set of image streams:

$ oc create -f \
    openshift-ansible/roles/openshift_examples/files/examples/xpaas-streams/jboss-image-streams.json \
    -n openshift

Access to the images referenced by these image streams requires the relevant xPaaS Middleware subscriptions.

Creating Database Service Templates

The database service templates make it easy to run a database image which can be utilized by other components. For each database (MongoDB, MySQL, and PostgreSQL), two templates are defined.

One template uses ephemeral storage in the container which means data stored will be lost if the container is restarted, for example if the pod moves. This template should be used for demonstration purposes only.

The other template defines a persistent volume for storage, however it requires your OpenShift installation to have persistent volumes configured.

To create the core set of database templates:

$ oc create -f \
    openshift-ansible/roles/openshift_examples/files/examples/db-templates -n openshift

After creating the templates, users are able to easily instantiate the various templates, giving them quick access to a database deployment.

Creating InstantApp Templates

The InstantApp templates define a full set of objects for a running application. These include:

Some of the templates also define a database deployment and service so the application can perform database operations.

The templates which define a database use ephemeral storage for the database content. These templates should be used for demonstration purposes only as all database data will be lost if the database pod restarts for any reason.

After creating the templates, users are able to easily instantiate full applications using the various language images provided with OpenShift. They can also customize the template parameters during instantiation so that it builds source from their own repository rather than the sample repository, so this provides a simple starting point for building new applications.

To create the core InstantApp templates:

$ oc create -f \
    openshift-ansible/roles/openshift_examples/files/examples/quickstart-templates -n openshift

There is also a set of templates for creating applications using various xPaaS Middleware products (JBoss EAP, JBoss JWS, and JBoss A-MQ), which can be registered by running:

$ oc create -f \
    openshift-ansible/roles/openshift_examples/files/examples/xpaas-templates -n openshift

The xPaaS Middleware templates require the xPaaS Middleware image streams, which in turn require the relevant xPaaS Middleware subscriptions.

The templates which define a database use ephemeral storage for the database content. These templates should be used for demonstration purposes only as all database data will be lost if the database pod restarts for any reason.

What’s Next?

With these artifacts created, developers can now log into the web console and follow the flow for creating from a template. Any of the database or application templates can be selected to create a running database service or application in the current project. Note that some of the application templates define their own database services as well.

The example applications are all built out of GitHub repositories which are referenced in the templates by default, as seen in the SOURCE_REPOSITORY_URL parameter value. Those repositories can be forked, and the fork can be provided as the SOURCE_REPOSITORY_URL parameter value when creating from the templates. This allows developers to experiment with creating their own applications.

You can direct your developers to the Using the InstantApp Templates section in the Developer Guide for these instructions.