If, as the developer, access to the oadm command is available, either via sudo or requesting assistance from the OpenShift Container Platform Administrator, create a new project for housing the Credit Service application and assign administrative rights of the new project to the user to be utilized by the developer from that point forward:

$ sudo oadm new-project creditservice --display-name="Credit Service" --description="This is a web service responsible for calculating loan applicant credit scores" --admin=ocuser

Once the new project is established, the developer can use oc login to assume the role assigned as the admin for the project before continuing. The shorthand form of logging in while also specifying the server and security certificate, is as follows:

$ oc login -u ocuser --certificate-authority=/etc/origin/master/ca.crt --server=https://bxms-ose-master.cloud.lab.eng.bos.redhat.com:8443

If you log in after creating or being granted access to a project, a project you have access to is automatically set as the current default, until switching to another one. The following also demonstrates the interactive login prompt with password authentication in lieu of security certificate:

$ oc login
Username: alice
Authentication required for https://openshift.example.com (openshift)
Password:
Login successful.

Using project "exampleProject".

Switching between projects as necessary can be completed using the oc project command:

$ oc project differentProjectName

Once the role of the project admin has been accessed, from this point on assumed to be ocuser, a new application can be created using the EAP 7.0 image stream:

$ oc new-app jboss-eap70-openshift~https://github.com/RHsyseng/BPMS-OCP/ --context-dir=ocp-credit-service --name=cs-service

Note that with some images and applications, some environmental variables are required to be passed in, as during the S2I process, the image will detect and utilize these variables in scripts which are responsible for initializing or configuring the image and/or environment. To pass environment variables into a new-app, use the -e argument format as follows:

$ oc new-app jboss-processserver63-openshift~https://github.com/RHsyseng/BPMS-OCP/ --context-dir=ocp-mortgage-dashboard --name=mort-dashboard -e SECDOMAIN_USERS_PROPERTIES=bpm_users.properties,SECDOMAIN_ROLES_PROPERTIES=bpm_roles.properties,SECDOMAIN_NAME=bpm_domain,SECDOMAIN_PASSWORD_STACKING=true

Once a new-app command has been performed, OCP will create several artifacts related to the new application. The set of artifacts created depends on the artifacts passed as input: source repositories, images, or templates.

Artifact Creation Example:

--> Creating resources with label app=cs-service ...
    imagestream "cs-service" created
    buildconfig "cs-service" created
    deploymentconfig "cs-service" created
    service "cs-service" created
    --> Success
    Build scheduled, use 'oc logs -f bc/cs-service' to track its progress.
    Run 'oc status' to view your app.

The buildconfig artifact is of particular interest at this point as it’s automatically triggered to begin the S2I process, which we can monitor, as the prompt indicates, by issuing the following command:

$ oc logs -f bc/cs-service

Example BuildConfig Log Excerpt:

$ oc logs -f bc/mort-dashboard
I1201 11:02:06.215391       1 builder.go:57] Master version "v3.2.1.13-1-gc2a90e1", Builder version "v3.2.1.13-1-gc2a90e1"
I1201 11:02:06.304554       1 builder.go:145] Running build with cgroup limits: api.CGroupLimits{MemoryLimitBytes:92233720368547, CPUShares:2, CPUPeriod:100000, CPUQuota:-1, MemorySwap:92233720368547}
I1201 11:02:06.330643       1 sti.go:206] The value of ALLOWED_UIDS is [1-]
I1201 11:02:06.330677       1 sti.go:214] The value of DROP_CAPS is [KILL,MKNOD,SETGID,SETUID,SYS_CHROOT]
I1201 11:02:06.352427       1 docker.go:355] Using locally available image "registry.access.redhat.com/jboss-processserver-6/processserver63-openshift@sha256:faf8fe2aa3747a51ff5aa9745278a0e9d7669f05f718773e195624551428fc79"
I1201 11:02:06.356752       1 sti.go:233] Creating a new S2I builder with build config: "Builder Name:\t\t\tJBoss BPMS Intelligent Process Server 6.3\nBuilder Image:\t\t\tregistry.access.redhat.com/jboss-processserver-6/processserver63-openshift@sha256:faf8fe2aa3747a51ff5aa9745278a0e9d7669f05f718773e195624551428fc79\nSource:\t\t\t\tfile:///tmp/s2i-build851998513/upload/src\nOutput Image Tag:\t\tmort-dashboard/mort-dashboard-1:4b64f4e5\nEnvironment:\t\t\tOPENSHIFT_BUILD_NAME=mort-dashboard-1,OPENSHIFT_BUILD_NAMESPACE=mort-dashboard,OPENSHIFT_BUILD_SOURCE=https://github.com/RHsyseng/BPMS-OCP/tree/master/ocp-mortgage-rules\nIncremental Build:\t\tdisabled\nRemove Old Build:\t\tdisabled\nBuilder Pull Policy:\t\tif-not-present\nPrevious Image Pull Policy:\talways\nQuiet:\t\t\t\tdisabled\nLayered Build:\t\t\tdisabled\nWorkdir:\t\t\t/tmp/s2i-build851998513\nDocker NetworkMode:\t\tcontainer:70ad5210da64a872aa046af11183670cc3f25ba66c80641e4992d62548858603\nDocker Endpoint:\t\tunix:///var/run/docker.sock\n"
I1201 11:02:06.361085       1 docker.go:355] Using locally available image "registry.access.redhat.com/jboss-processserver-6/processserver63-openshift@sha256:faf8fe2aa3747a51ff5aa9745278a0e9d7669f05f718773e195624551428fc79"
I1201 11:02:06.369807       1 docker.go:355] Using locally available image "registry.access.redhat.com/jboss-processserver-6/processserver63-openshift@sha256:faf8fe2aa3747a51ff5aa9745278a0e9d7669f05f718773e195624551428fc79"
I1201 11:02:06.369933       1 docker.go:475] Image contains io.openshift.s2i.scripts-url set to 'image:///usr/local/s2i'
I1201 11:02:06.370198       1 sti.go:140] Preparing to build mort-dashboard/mort-dashboard-1:4b64f4e5
I1201 11:02:06.414869       1 source.go:197] Downloading "https://github.com/RHsyseng/BPMS-OCP/tree/master/ocp-mortgage-rules" ...

At this point in the process, S2I is fetching the specified source code for injection into the supplied image. Once complete, the logs will continue feedback (much too long for full inclusion here) as the S2I process runs to completion. The process results in a docker container instance with the finalized image within ready to be exposed. During this process, S2I fetches and builds the code from the specified repository and pulls down all dependencies required for both build time and runtime offline capabilities. It’s possible to specify a maven mirror/proxy to increase the speed of the downloads. Following the build, KIE Container verification is performed to validate all rules and process resources. With the verification complete, there’s less potential for issues to arise around erroneous rules when the new container starts up. Given all the work that is performed at this time, this process may take some time to complete, so monitoring of logs or project status is recommended in order to be aware of the point at which the process is finished. If using the above command, this point is demarcated by an ending of the streaming log tail and a return to the prompt.

If using the oc status command, completion will be exemplified by a successful deployment similar to the following:

$ oc status
In project Credit Service Web Service (creditservice) on server https://bxms-ose-master.cloud.lab.eng.bos.redhat.com:8443

http://cs.bxms.ose to pod port 8080-tcp (svc/cs-service)
  dc/cs-service deploys istag/cs-service:latest <-
    bc/cs-service builds https://github.com/jeremyary/jboss-os-service.git with openshift/jboss-eap70-openshift:latest
    deployment #2 deployed 2 days ago - 1 pod
    deployment #1 deployed 4 days ago

1 warning identified, use 'oc status -v' to see details.

An OpenShift route exposes a service at a host name, like www.example.com, so that external clients can reach it by name.

DNS resolution for a host name is handled separately from routing; your administrator may have configured a cloud domain that will always correctly resolve to the OpenShift router, or if using an unrelated host name you may need to modify its DNS records independently to resolve to the router.

Once a build has been completed, it’s necessary to expose the new service via routing, as follows:

$ oc expose service cs-service --hostname=www.example.com

Unsecured routes are the default configuration, and are therefore the simplest to set up. However, secured routes offer security for connections to remain private. To create a secured HTTPS route encrypted with a key and certificate (PEM-format files which you must generate and sign separately), you can use the create route command and optionally provide certificates and a key. More information on this can be found in the official Red Hat OpenShift Developer Guide.

At times, it may be beneficial to list all the entities associated with a project or application. To view all associated entities, use the oc get all command:

$ oc get all
NAME                 TYPE                                          FROM          LATEST
cs-service           Source                                        Git           2
NAME                 TYPE                                          FROM          STATUS     STARTED       DURATION
cs-service-1         Source                                        Git@16553c3   Complete   2 days ago   5m15s
cs-service-2         Source                                        Git@16553c3   Complete   4 days ago   15m21s
NAME                 DOCKER REPO                                   TAGS          UPDATED
cs-service           172.30.14.135:5000/creditservice/cs-service   latest        4 days ago
NAME                 REVISION                                      REPLICAS      TRIGGERED BY
cs-service           2                                             1             config,image(cs-service:latest)
NAME                 DESIRED                                       CURRENT       AGE
cs-service-1         0                                             0             12d
cs-service-2         1                                             1             10d
NAME                 HOST/PORT                                     PATH          SERVICE                      TERMINATION   LABELS
cs-service           cs.bxms.ose                                                 cs-service:8080-tcp                        app=cs-service
NAME                 CLUSTER-IP                                    EXTERNAL-IP   PORT(S)                      AGE
cs-service           172.30.226.97                                 <none>        8080/TCP,8443/TCP,8778/TCP   12d
NAME                 READY                                         STATUS        RESTARTS                     AGE
cs-service-1-build   0/1                                           Completed     0                            12d
cs-service-2-build   0/1                                           Completed     0                            10d
cs-service-2-uep2k   1/1                                           Running       0                            10d

In cases where further diagnostic troubleshooting is required, it’s also possible to get the YAML-based configuration listing for all entities, by specifying the format of output to get:

$ oc get all -o yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: BuildConfig
  metadata:
    annotations:
      openshift.io/generated-by: OpenShiftNewApp
    creationTimestamp: 2016-09-30T18:20:03Z
    labels:
      app: cs-service
    name: cs-service
    namespace: creditservice
    resourceVersion: "2230152"
    selfLink: /oapi/v1/namespaces/creditservice/buildconfigs/cs-service
    uid: 81886a1f-873a-11e6-9013-0001a4ac33b4
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: cs-service:latest

... (output abbreviated)

Rather than list all entities, it’s also possible to generate a list of specific entity types. For instance, in order to list the pods associated with the project, specify pods with the get command:

$ oc get pods
NAME                 READY     STATUS      RESTARTS   AGE
cs-service-1-build   0/1       Completed   0          12d
cs-service-2-build   0/1       Completed   0          10d
cs-service-2-uep2k   1/1       Running     0          10d

As evident in the example above, a single pod is now running the container instance post-build completion. In order to view and diagnose issues on the server, such as viewing EAP logs, it’s possible to access the output without directly connecting to the pod:

$ oc logs cs-service-2-uep2k

With the images in use as part of this project, the output for the above command resembles a cat of the server logs. Tailing of live logs is also possible with the -f parameter.

Should you further need to diagnose issues on the pod container instance, remote access to pod is performed as follows:

$ oc rsh cs-service-2-uep2k
sh-4.2$

While it’s possible to test server configuration changes or tweak properties via the last command, it’s highly recommended to avoid doing so as the changes made manually via rsh will not persist on a new build and further, will not replicate to other pods hosting your application. Should you need to make changes to the runtime environment, research the image stream and S2I process in use for possibilities of passing through properties or configuration that will instead persist on restarts and replication. Often times, S2I processes expose variables as needed for changing configuration. When working with JBoss EAP, it’s possible to include configuration files in the code repository used to instantiate the BuildConfig which will be added to the standalone configuration directory for further reference.

Should you wish to delete the entities associated to a created app, you may do so by referring to the entities by label:

$ oc delete all -l app=cs-service

It’s also possible to delete a project in its entirety rather than resetting at the app level:

$ oc delete project cs-service

As before, either via sudo or with Administrator assistance, create a new project for housing the Business Process rules application and assign administrative rights of the new project to the user to be utilized by the developer from that point forward:

$ sudo oadm new-project mortgage-rules --display-name="Mortgage Loan Rules" --description="This is an Intelligent Process Server app housing the Mortgage Loan Knowledge Store" --admin=ocuser

Initialize a new Intelligent Process Server application for hosting the Mortgage Loan process rules:

$ oc new-app jboss-processserver63-openshift~https://github.com/RHsyseng/BPMS-OCP --context-dir=ocp-mortgage-rules --name=mortgage-rule

Expose the new service upon completion.

During development phases, it may be more practical to host the Dashboard User Interface portion of the project on a localhost server or local EAP instance rather than deploying and undergoing timely S2I processes with each iteration to OpenShift.

Once again, create a new project for housing the Business Process rules application and assign administrative rights of the new project to the user to be utilized by the developer from that point forward:

$ sudo oadm new-project mortgage-dashboard --display-name="Mortgage Dashboard" --description="This is a User Interface Application intended to interact with the Mortgage Loan Business Process" --admin=ocuser

Once development of the application portion of the project has been completed, another EAP 7.0 container can be used for hosting it in a container:

$ oc new-app jboss-eap70-openshift~https://github.com/RHsyseng/BPMS-OCP --context-dir=ocp-mortgage-dashboard --name=mortgage-dashboard