In this lab, we’re going to deploy a backend service, developed in PHP that will expose 2 main REST endpoints to the visualizer application (parksmap web component that was deployed in the previous labs). The application will query for national parks information (including its coordinates) that is stored in a MongoDB database. This application will also provide an external access point, so that the API provided can be directly used by the end user. Background: Source-to-Image (S2I) In a previous lab, we learned how to deploy an existing image. Now we will expand on that by learning how OpenShift builds container images using source code from an existing repository. This is accomplished using the Source-to-Image project. Source-to-Image (S2I) is a open source project sponsored by Red Hat that has the following goal: Source-to-image (S2I) is a tool for building reproducible container images. S2I produces ready-to-run images by injecting source code into an image and assembling a new image which incorporates the builder image and built source. The result is then ready to use with docker run. S2I supports incremental builds which re-use previously downloaded dependencies, previously built artifacts, etc. OpenShift is S2I-enabled and can use S2I as one of its build mechanisms (in addition to building container images from Dockerfiles, and "custom" builds). OpenShift runs the S2I process inside a special Pod, called a Build Pod, and thus builds are subject to quotas, limits, resource scheduling, and other aspects of OpenShift. A full discussion of S2I is beyond the scope of this class, but you can find more information about it either in the OpenShift S2I documentation or on GitHub. The only key concept you need to remember about S2I is that it’s magic. Exercise: Creating a PHP application The backend service that we will be deploying as part of this exercise is called nationalparks. This is a PHP application that performs 2D geo-spatial queries against a MongoDB database to locate and return map coordinates of all National Parks in the world. That was just a fancy way of saying that we are going to deploy a webservice that returns a JSON list of places. Add to Project Because the nationalparks component is a backend to serve data that our existing frontend (parksmap) will consume, we are going to build it inside the existing project that we have been working with. To illustrate how you can interact with OpenShift via the CLI or the Web Console, we will deploy the nationalparks component using the web console. Using application code on embedded Git server OpenShift can work with any accessible Git repository. This could be GitHub, GitLab, or any other server that speaks Git. You can even register webhooks in your Git server to initiate OpenShift builds triggered by any update to the application code! The repository that we are going to use is already cloned in the internal Gogs repository and located at the following URL: Gogs Repository Your Gogs credentials are: username: %USERNAME% password: %GOGS_PASSWORD% Later in the lab, we want you to make a code change and then rebuild your application. This is a fairly simple PHP application. Build the Code on OpenShift Similar to how we used "Add to project" before with an existing image, we can do the same for specifying a source code repository. Since for this lab you have your own git repository, let’s use it with a simple PHP S2I image. In the OpenShift web console, find your %PROJECT% project, and then click the Add button and then the Browse Catalog link as highlighted in the following image: This is the developer catalog which allows a user to select components they want to add to their application. Search for php, and finally select PHP as shown in the following image: After you click PHP, a dialog is presented as shown in the following image: Click on the Create Application button and then enter a name and a Git repository URL. For the name, enter nationalparks, and for the Git repository URL, enter: http://gogs-%INFRA_PROJECT%.%CLUSTER_SUBDOMAIN%/%USERNAME%/nationalparks-php.git All of these runtimes shown are made available via Templates and ImageStreams, which will be discussed in a later lab. In the Git Repository field enter the base of the Git repository for your Nationaparks application. This will cause the S2I process to grab that specific tag in the code repository. Check the box to create a route and then click the Create button. To see the build logs, in Topology view, click the nationalparks entry, then click on View Logs in the Builds section of the Resources tab. The initial build will take a few minutes to downloads all of the dependencies needed for the application. You can see all of this happening in real time! From the command line, you can also see the Builds: oc get builds You’ll see output like: NAME TYPE FROM STATUS STARTED DURATION nationalparks-1 Source Git@b052ae6 Running About a minute ago 1m2s You can also view the build logs with the following command: oc logs -f builds/nationalparks-1 After the build has completed and successfully: The S2I process will push the resulting Docker-formatted image to the internal OpenShift registry The DeploymentConfiguration (DC) will detect that the image has changed, and this will cause a new deployment to happen. A ReplicationController (RC) will be spawned for this new deployment. The RC will detect no Pods are running and will cause one to be deployed, as our default replica count is just 1. In the end, when issuing the oc get pods command, you will see that the build Pod has finished (exited) and that an application Pod is in a ready and running state: NAME READY STATUS RESTARTS AGE nationalparks-1-tkid3 1/1 Running 3 2m nationalparks-1-build 0/1 Completed 0 3m parksmap-1-4hbtk 1/1 Running 0 2h If you look again at the web console, you will notice that, when you create the application this way, OpenShift also creates a Route for you. You can see the URL in the web console, or via the command line: oc get routes Where you should see something like the following: NAME HOST/PORT PATH SERVICES PORT TERMINATION nationalparks nationalparks-%PROJECT%.%CLUSTER_SUBDOMAIN% nationalparks 8080-tcp parksmap parksmap-%PROJECT%.%CLUSTER_SUBDOMAIN% parksmap 8080-tcp In the above example, the URL is: <a href="http://nationalparks-%PROJECT%.%CLUSTER_SUBDOMAIN%" class="bare">http://nationalparks-%PROJECT%.%CLUSTER_SUBDOMAIN%</a> Since this is a back-end application, it doesn’t actually have a web interface. However, it can still be used with a browser. All backends that work with the parksmap frontend are required to implement a /ws/info/ endpoint. To test, visit this URL in your browser: National Parks Info Page The trailing slash is required. You will see a simple JSON string: {"id":"nationalparks-php","displayName":"National Parks (PHP)","center":{"latitude":"47.039304","longitude":"14.505178"},"zoom":4} Earlier we said: This is a PHP application that performs 2D geo-spatial queries against a MongoDB database But we don’t have a database. Yet.