This section describes how to deploy a more complex application and use it to test access to the resulting website. The application is a sample training workshop environment from Red Hat called Lab-Guide-Workshop. Lab-Guide-Workshop provides sample applications to enable users to learn more about OpenShift.
We used the OpenShift Container Platform 3.11 HA with 15 servers, including four R740xd servers. Each of the servers had 10 NVMe disks that create the OpenShift Storage Class “glusterfs-nvme,” which is set as the default.
To deploy Lab-Guide-Workshop:
oc login https://ocp.example.com:8443 -u dellemc1 -p Password1 --insecure-skip-tls-verify=true
oc new-project workshop
The following output appears:
Now using project "workshop" on server "https://ocp.example.com:8443". You can add applications to this project with the 'new-app' command. For example, try: oc new-app centos/ruby-25-entos7~https://github.com/sclorg/ruby-ex.git to build a new example application in Ruby.
oc new-app docker.io/osevg/workshopper:0.2 --name=lab-guide -e CONTENT_URL_PREFIX="https://raw.githubusercontent.com/sa-ne/na-se-openshift-workshop/dell_workshop/labguide" -e WORKSHOPS_URLS="https://raw.githubusercontent.com/sa-ne/na-se-openshift-workshop/dell_workshop/labguide/_ocp_admin_testdrive.yaml" -e COOLSTORE_PROJECT="user01" -e OCP_ROUTING_SUFFIX="$OCP_ROUTING_SUFFIX" -e MASTER_HOSTNAME="master1" -e MASTER_EXTERNAL_FQDN="master.$OCP_SUBDOMAIN" -e INFRA_INTERNAL_FQDN="infranode1.$OCP_SUBDOMAIN_INTERNAL" -e NODE1_INTERNAL_FQDN="node1.$OCP_SUBDOMAIN_INTERNAL" -e NODE2_INTERNAL_FQDN="node2.$OCP_SUBDOMAIN_INTERNAL"-e WEB_CONSOLE_URL="https://master.$OCP_SUBDOMAIN_INTERNAL/console" -e SSH_CONSOLE_URL="https://terminal-workshop.$OCP_ROUTING_SUFFIX" -e OPENSHIFT_DOCS_BASE="https://docs.openshift.com/container-platform/3.11" -e KEYNAME="openshift" -e LOG_TO_STDOUT=true
--> Found Docker image d6af21e (17 months old) from docker.io for "docker.io/osevg/workshopper:0.2" * An image stream tag will be created as "lab-guide:0.2" that will track this image * This image will be deployed in deployment config "lab-guide" * Port 8080/tcp will be load balanced by service "lab-guide" * Other containers can access this service through the hostname "lab-guide"
--> Creating resources ...imagestream.image.openshift.io "lab-guide" created deploymentconfig.apps.openshift.io "lab-guide" created service "lab-guide" created--> Success application is not exposed. You can expose services to the outside world by executing one or more of the commands below: 'oc expose svc/lab-guide' Run 'oc status' to view your app.
oc expose svc/lab-guide
The following page appears.
Figure 18. Lab-Guide-Workshop with one lab-guide pod running
You can now scale to three pods, as shown in the following figure.
Figure 19. Scaling the lab-guide to run three pods
The following page appears.
Figure 20. Web URL for the exposed lab-guide workshop service
The Lab-Guide-Workshop application is running on sub-domain apps.ocp.example.com. OpenShift automatically generated lab-guide-workshop when the route was created.
The wildcard DNS entry *.ocp.example.com permits resolution of all sub-domains under ocp.example.com and resolves the OpenShift API. In the Ready Architecture *.ocp.example.com, resolve to 100.82.42.99. This value matches the values in /etc/ansible/hosts.
The following figure shows the exposed route. The route is ready for users to access Lab-Guide-Workshop.
Figure 21. Exposed route
The following figure shows an OpenShift Web Console view of Lab-Guide-Workshop with persistent volume claims on the glusterfs-nvme storage class.
Figure 22. OpenShift Web Console view of Lab-Guide-Workshop