{"id":90874,"date":"2020-08-07T01:42:20","date_gmt":"2020-08-06T23:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds"},"modified":"2020-08-07T01:42:20","modified_gmt":"2020-08-06T23:42:20","slug":"sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Modern Applications on OpenShift, Part 2: Chained Builds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello everyone! This is the second post in our series where we demonstrate how to deploy modern web applications on Red Hat OpenShift. <\/p>\n

\"Modern
\n
\nIn the previous post, we briefly touched on the capabilities of the new S2I (source-to-image) builder image, which is meant for building and deploying modern web applications on OpenShift. We were interested in the topic of quick application deployment, and today we will explore how to use the S2I image as a 'clean' builder image and combine it with related OpenShift builds.
\n<\/a><\/noindex><\/p>\n

Clean builder image<\/h3>\n

\nAs mentioned in the first part, most modern web applications have what is known as a build stage, where operations such as code transpilation, concatenation of multiple files, and minification typically occur. The files produced from these operations \u2013 namely static HTML, JavaScript, and CSS \u2013 are placed in the output folder. The location of this folder usually depends on the build tools used, and for React, it will be the folder .\/build (we will delve into this issue further below).<\/p>\n

Source-to-Image (S2I)<\/h4>\n

\nIn this post, we do not discuss the topic of 'what is S2I and how to use it' (you can read more about it here<\/a><\/noindex>), but it is important to clearly understand two phases of this process to grasp what the Web App Builder image does.<\/p>\n

Assembly phase<\/h4>\n

\nThe assembly phase is essentially very similar to what happens when you run docker build and obtain a new Docker image as a result. Accordingly, this phase occurs when a build is triggered on the OpenShift platform.<\/p>\n

In the case of the Web App Builder image, the installation of your application's dependencies and the initiation of the build is handled by assemble script<\/a><\/noindex>. By default, the builder image uses the npm run build command, but this can be overridden via the NPM_BUILD environment variable.<\/p>\n

As we mentioned earlier, the location of a finished, assembled application depends on the tools being used. For example, in the case of React, it will be the folder .\/build, while for Angular applications, it will be the folder project_name\/dist. And, as shown in the previous post, the location of the output directory, which is set by default to build, can be overridden via the OUTPUT_DIR environment variable. Since the output folder location varies from framework to framework, you simply copy the generated output to the standard folder in the image, specifically to \/opt\/apt-root\/output. This is important for understanding the next part of this article, but for now, let\u2019s quickly review the next stage \u2013 the run phase.<\/p>\n

Run Phase<\/h4>\n

\nThis phase occurs when a new image created during the assembly stage is called with docker run. It also happens when deploying on the OpenShift platform. By default, run script<\/a><\/noindex> use serve module<\/a><\/noindex> for serving static content located in the aforementioned standard output directory.<\/p>\n

This method is good for quickly deploying applications, but generally, serving static content this way is not recommended. Since we are actually serving only static content, we don't need the Node.js installed inside our image \u2013 a web server will suffice.<\/p>\n

In other words, we need one thing at build time and another at runtime. In such cases, chained builds come in handy.<\/p>\n

Chained Builds<\/h3>\n

\nHere\u2019s what they say about chained builds<\/a><\/noindex> in the OpenShift documentation:<\/p>\n

\"Two builds can be linked together, where one generates a compiled entity and the other places this entity in a separate image that is used to run this entity.\"\n<\/p><\/blockquote>\n

\nIn other words, we can use the Web App Builder image to run our build and then use the web server image, specifically NGINX, to serve our content.<\/p>\n

This way, we can use the Web App Builder image as a 'clean' builder while maintaining a smaller runtime image.<\/p>\n

Now let\u2019s break this down with a concrete example.<\/p>\n

For this exercise, we\u2019ll use a simple React application<\/a><\/noindex>, created with the create-react-app command-line tool.<\/p>\n

To bring everything together, we\u2019ll use the OpenShift template file.<\/a><\/noindex>.<\/p>\n

Let's break down this file in more detail, starting with the parameters section.<\/p>\n

parameters:\n  - name: SOURCE_REPOSITORY_URL\n    description: The source URL for the application\n    displayName: Source URL\n    required: true\n  - name: SOURCE_REPOSITORY_REF\n    description: The branch name for the application\n    displayName: Source Branch\n    value: master\n    required: true\n  - name: SOURCE_REPOSITORY_DIR\n    description: The location within the source repo of the application\n    displayName: Source Directory\n    value: .\n    required: true\n  - name: OUTPUT_DIR\n    description: The location of the compiled static files from your web apps builder\n    displayName: Output Directory\n    value: build\n    required: false\n<\/code><\/pre>\n
\nEverything here is quite clear, but it's worth noting the OUTPUT_DIR parameter. For the React application in our example, there's nothing to worry about since React uses the default value for the output folder, but in the case of Angular or something else, this parameter will need to be changed accordingly.<\/p>\n
Now, let's take a look at the ImageStreams section.<\/p>\n
- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-builder  \/\/ 1 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-runtime  \/\/ 2 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: web-app-builder-runtime \/\/ 3\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: nginx-image-runtime \/\/ 4\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nTake a look at the third and fourth images. They are both defined as Docker images, and it is clear where they come from.<\/p>\n
The third image is the web-app-builder, and it comes from nodeshift\/ubi8-s2i-web-app with the tag 10.x on Docker hub<\/a><\/noindex>.<\/p>\n
The fourth is the NGINX image (version 1.12) with the tag latest on Docker hub<\/a><\/noindex>.<\/p>\n
Now let's look at the first two images. They both start empty and are created only during the build phase. The first image, react-web-app-builder, will be the result of the assembly stage, which combines the web-app-builder-runtime image and our source code. That's why we included '-builder' in the name of this image.<\/p>\n
The second image, react-web-app-runtime, will be the result of combining the nginx-image-runtime and some files from the react-web-app-builder image. This image will also be used during deployment and will contain only the web server and the static HTML, JavaScript, and CSS of our application.<\/p>\n
Confusing? Let's take a look at the build configurations, and it'll become a bit clearer.<\/p>\n
In our template, there are two build configurations. Here\u2019s the first one, and it's quite standard:<\/p>\n
  apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-builder\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-builder:latest \/\/ 1\n    source:   \/\/ 2 \n      git:\n        uri: ${SOURCE_REPOSITORY_URL}\n        ref: ${SOURCE_REPOSITORY_REF}\n      contextDir: ${SOURCE_REPOSITORY_DIR}\n      type: Git\n    strategy:\n      sourceStrategy:\n        env:\n          - name: OUTPUT_DIR \/\/ 3 \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \/\/ 4\n        incremental: true \/\/ 5\n      type: Source\n    triggers: \/\/ 6\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - imageChange: {}\n      type: ImageChange\n<\/code><\/pre>\n
\nAs we see, the line marked 1 indicates that the result of this build will be placed in the very image react-web-app-builder, which we saw earlier in the ImageStreams section.<\/p>\n
The line marked 2 indicates where to get the code from. In our case, this is a git repository, and the location, ref, and context folder are defined by the parameters we saw above.<\/p>\n
The line marked 3 \u2013 we have already seen this in the parameters section. It adds the environment variable OUTPUT_DIR, which in our example equals 'build'.
\nThe line marked 4 states to use the image web-app-builder-runtime, which we already saw in the ImageStream section.<\/p>\n
The line marked 5 indicates that we want to use an incremental build, if the S2I image supports it, and the Web App Builder image does. On the first run, after completing the assembly phase, the image will save the node_modules folder in an archive file. Then, during subsequent runs, the image will simply extract this folder to reduce the build duration.<\/p>\n
And finally, the line marked 6 \u2013 this is just a few triggers to make the build run automatically, without manual intervention, when something changes.<\/p>\n
Overall, this is quite a standard build configuration.<\/p>\n
Now let\u2019s look at the second build configuration. It is very similar to the first one, but there is one important distinction.<\/p>\n
apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-runtime\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-runtime:latest \/\/ 1\n    source: \/\/ 2\n      type: Image\n      images:                              \n        - from:\n            kind: ImageStreamTag\n            name: react-web-app-builder:latest \/\/ 3\n          paths:\n            - sourcePath: \/opt\/app-root\/output\/.  \/\/ 4\n              destinationDir: .  \/\/ 5\n             \n    strategy: \/\/ 6\n      sourceStrategy:\n        from:\n          kind: ImageStreamTag\n          name: nginx-image-runtime:latest\n        incremental: true\n      type: Source\n    triggers:\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - type: ImageChange\n      imageChange: {}\n    - type: ImageChange\n      imageChange:\n        from:\n          kind: ImageStreamTag\n          name: react-web-app-builder:latest \/\/ 7\n<\/code><\/pre>\n
\nSo, the second build configuration \u2013 react-web-app-runtime \u2013 starts off quite standard.<\/p>\n
In line 1, there's nothing new \u2013 it simply states that the build result is placed in the react-web-app-runtime image.<\/p>\n
Line 2, like in the previous configuration, specifies where to fetch the source code from. However, note that here we indicate that it is taken from the image. Specifically, from the image we just created \u2013 react-web-app-builder (mentioned in line 3). The files we want to use are located inside the image, and their path is specified in line 4, which in our case is \/opt\/app-root\/output\/. If you recall, that\u2019s where the files generated from our application build are placed.<\/p>\n
The destination folder specified in line 5 is just the current directory (all of this, remember, runs inside a magical thing called OpenShift, not on your local computer).<\/p>\n
The section strategy \u2013 line 6 \u2013 is also similar to the first build configuration. This time, however, we plan to use nginx-image-runtime, which we\u2019ve already seen in the ImageStream section.<\/p>\n
Finally, line 7 indicates the trigger section that activates this build every time the react-web-app-builder image changes.<\/p>\n
Otherwise, this template contains quite a standard deployment configuration, along with items related to services and routes, but we won\u2019t delve into that. Note that the image to be deployed is the react-web-app-runtime image.<\/p>\n
Deploying the Application<\/h3>\n
\nSo, after taking a look at the template, let\u2019s see how to use it for deploying the application.<\/p>\n
We can use the OpenShift client tool called oc to deploy our template:<\/p>\n
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f\n\n$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https:\/\/github.com\/lholmquist\/react-web-app\n<\/code><\/pre>\n
\nThe first command in the screenshot above is a deliberately engineering way to find the template .\/openshiftio\/application.yaml.<\/p>\n
The second command simply creates a new application based on this template.<\/p>\n
Once these commands have executed, we will see that we have two builds:<\/p>\n
\"Modern<\/p>\n
And returning to the Overview screen, we will see the started pod:<\/p>\n
\"Modern<\/p>\n
Clicking the link will take us to our application, which is the default React App page:<\/p>\n
\"Modern<\/p>\n
Supplement 1<\/h3>\n
\nFor Angular enthusiasts, we also have an application example<\/a><\/noindex>.<\/p>\n
The template here is the same, except for the OUTPUT_DIR variable.<\/p>\n
Appendix 2<\/h3>\n
\nIn this article, we used NGINX as a web server, but it can be easily replaced with Apache by simply changing it in the template file. NGINX image<\/a><\/noindex> to Apache image<\/a><\/noindex>.<\/p>\n
Conclusion<\/h3>\n
\nIn the first part of this series, we demonstrated how to quickly deploy modern web applications on the OpenShift platform. Today, we explored what makes up the Web App image and how it can be combined with a clean web server like NGINX using chained builds to create a more production-ready application build. In the next, concluding article of this series, we will show how to run a development server for your application on OpenShift and ensure synchronization of local and remote files.<\/p>\n
Contents of this article series<\/h3>\n
<\/p>\n