👴🏼 📈 🕗 现代OpenShift应用程序，第3部分：作为开发环境的OpenShift和OpenShift管道 💘 👩🏻‍🔬 🧢

大家好，这个博客！这是系列文章中的第三篇，我们向您展示如何在Red Hat OpenShift上部署现代Web应用程序。

在前两篇文章中，我们介绍了如何仅用几个步骤来部署现代Web应用程序，以及如何使用新的S2I映像以及现成的HTTP服务器映像（例如NGINX），并使用链式构建进行生产部署。

今天，我们将向您展示如何在OpenShift平台上为您的应用程序运行开发服务器，并将其与本地文件系统同步，并讨论什么是OpenShift Pipelines，以及如何将其用作链接程序集的替代方法。

OpenShift作为开发环境

开发流程

如第一篇文章中所述，现代Web应用程序的典型开发工作流程就是一个“开发服务器”，它监视本地文件中的更改。当它们发生时，将开始构建应用程序，然后将其更新到浏览器。

在大多数现代框架中，此“开发服务器”都内置在相应的命令行工具中。

当地的例子

首先，让我们看看在本地运行应用程序时这是如何工作的。以以前文章中的React应用为例，尽管许多相同的工作流程概念也适用于所有其他现代框架。

因此，要在我们的React示例中启动“开发服务器”，我们发出以下命令：

$ npm run start

然后，在终端窗口中，我们将看到以下内容：

我们的应用程序将在默认浏览器中打开：

现在，如果我们对文件进行了更改，则应在浏览器中更新应用程序。

好的，在本地模式下进行开发，一切都清楚了，但是如何在OpenShift上实现相同？

OpenShift上的开发服务器

如果您还记得，在上一篇文章中，我们分析了S2I映像的所谓运行阶段，并发现默认情况下，serv模块负责为Web应用程序提供服务。

但是，如果仔细看一下该示例中的运行脚本，您将看到它包含$ NPM_RUN环境变量，该变量允许您执行自己的命令。

例如，我们可以使用nodeshift模块来部署我们的应用程序：

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

注意：上面的示例被简化以说明一般想法。

在这里，我们在部署中添加了NPM_RUN环境变量，该变量告诉运行时运行yarn start命令，该命令将在OpenShift容器内启动React开发服务器。

如果您查看正在运行的Pod的日志，则将显示以下内容：

当然，在我们可以将本地代码与也受监视以进行更改的代码同步，但它们都位于远程服务器上之前，这几乎没有任何意义。

同步远程和本地代码

幸运的是，nodeshift可以轻松地帮助实现同步，并且您可以使用watch命令来跟踪更改。

因此，在执行了为应用程序部署开发服务器的命令后，我们可以安全地使用以下命令：

$ npx nodeshift watch

结果，将与我们之前创建的正在运行的Pod建立连接，本地文件与远程集群的同步将被激活，并且本地系统上的文件将受到更改的监视。

因此，如果我们现在更新src / App.js文件，系统将对这些更改做出反应，将其复制到远程集群并启动开发服务器，然后将在浏览器中更新我们的应用程序。

为了完整起见，让我们展示这些命令的整体外观：

$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000

$ npx nodeshift watch --strictSSL=false

watch命令是oc rsync命令基础上的抽象，您可以在此处了解有关其工作原理的更多信息。

这是React的一个示例，但是其他框架可以使用完全相同的方法，只需根据需要设置NPM_RUN环境变量。

Openshift管道

接下来，我们将讨论OpenShift Pipelines之类的工具，以及如何将其用作链式构建的替代方法。

什么是OpenShift管道

OpenShift Pipelines是基于云的CI / CD持续集成和交付系统，用于使用Tekton组织管道。Tekton是一种灵活的开源Kubernetes本机CI / CD框架，可通过从底层进行抽象来自动跨平台（Kubernetes，无服务器，虚拟机等）进行部署。

要理解本文，必须具备一些管道知识，因此我们强烈建议您首先阅读官方教程。

搭建工作环境

要使用本文中的示例，首先需要准备生产环境：

OpenShift 4. CodeReady Containers (CRD), .
, , Pipeline Operator. , , .
Tekton CLI (tkn) .
create-react-app, , ( React).
() , npm install npm start.

应用程序存储库还将有一个k8s文件夹，用于部署应用程序的Kubernetes / OpenShift YAML将位于其中。我们将在此存储库中创建任务，集群任务，资源和管道。

让我们开始吧

本示例的第一步是在OpenShift集群中创建一个新项目。让我们将此项目称为webapp-pipeline并使用以下命令创建它：

$ oc new-project webapp-pipeline

此外，该项目的名称将出现在代码中，因此，如果您决定使用其他名称，请不要忘记对示例中的代码进行相应的编辑。从这一点开始，我们不会从上到下，而是从下到上：也就是说，首先我们将创建传送带的所有组件，然后才创建它本身。

所以，首先...

任务

让我们创建几个任务，这些任务将帮助我们通过管道部署应用程序。第一个任务apply_manifests_task负责将YAML应用于我们应用程序的k8s文件夹中的Kubernetes资源（服务，部署和路由）。第二个任务-update_deployment_task-负责将已经部署的映像更新为我们的管道创建的映像。

如果还不清楚，请不要担心。实际上，这些任务类似于实用程序，稍后我们将对其进行详细讨论。现在，让我们创建它们：

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml

然后，使用tkn CLI命令，检查是否已创建任务：

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

注意：这些是您当前项目的本地任务。

集群任务

群集任务基本上与简单任务相同。也就是说，它是可重复使用的步骤的集合，这些步骤在开始特定任务时以一种或另一种方式组合在一起。不同之处在于，群集任务在群集内的任何地方都可用。要查看添加管道操作员后自动创建的集群任务的列表，请再次使用tkn CLI命令：

$ tkn clustertask ls

NAME                       AGE
buildah                    1 day ago
buildah-v0-10-0            1 day ago
jib-maven                  1 day ago
kn                         1 day ago
maven                      1 day ago
openshift-client           1 day ago
openshift-client-v0-10-0   1 day ago
s2i                        1 day ago
s2i-go                     1 day ago
s2i-go-v0-10-0             1 day ago
s2i-java-11                1 day ago
s2i-java-11-v0-10-0        1 day ago
s2i-java-8                 1 day ago
s2i-java-8-v0-10-0         1 day ago
s2i-nodejs                 1 day ago
s2i-nodejs-v0-10-0         1 day ago
s2i-perl                   1 day ago
s2i-perl-v0-10-0           1 day ago
s2i-php                    1 day ago
s2i-php-v0-10-0            1 day ago
s2i-python-3               1 day ago
s2i-python-3-v0-10-0       1 day ago
s2i-ruby                   1 day ago
s2i-ruby-v0-10-0           1 day ago
s2i-v0-10-0                1 day ago

现在，让我们创建两个集群任务。第一个将生成S2I映像并将其发送到内部OpenShift注册表；第二个是使用我们已经组装为内容的应用程序来构建基于NGINX的图像。

创建并发送图像

在创建第一个任务时，我们将重复上一篇有关链接程序集的文章中已经做过的事情。回想一下，我们使用S2I映像（ubi8-s2i-web-app）来“构建”我们的应用程序，并最终将映像存储在内部OpenShift注册表中。现在，我们将使用Web应用程序的此S2I映像为我们的应用程序创建DockerFile，然后使用Buildah进行实际的生成并将生成的映像推送到内部OpenShift注册表中，因为这正是部署您的OpenShift时所做的事情。使用NodeShift的应用程序。

您问我们怎么知道这一切？从官方Node.js的官方版本开始，我们只是复制并自己完成了它。

因此，现在我们创建s2i-web-app集群任务：

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

我们将不对此进行详细介绍，而只停留在OUTPUT_DIR参数上：

params:
      - name: OUTPUT_DIR
        description: The location of the build output directory
        default: build

默认情况下，此参数设置为build，这是React放置收集到的内容的位置。其他框架使用不同的路径，例如，在Ember is dist。我们第一个集群任务的输出将是包含我们收集的HTML，JavaScript和CSS的图像。

基于NGINX构建图像

至于第二个集群任务，它应该使用我们已经收集的应用程序的内容为我们收集基于NGINX的映像。基本上，这是上一节中讨论链式构建的一部分。

为此，我们以与上述相同的方式创建了一个集群任务webapp-build-runtime：

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

如果查看这些集群任务的代码，则可以看到未在其中指定我们正在使用的Git存储库或我们创建的映像的名称。我们仅指定要确切传输到Git的图像或要显示最终图像的特定图像。这就是为什么在使用其他应用程序时可以重用这些群集任务的原因。

在这里，我们优雅地进行到下一点...

资源资源

因此，由于正如我们刚刚说过的，群集任务应尽可能概括，因此我们需要创建将在输入（Git存储库）和输出（最终图像）中使用的资源。我们需要的第一个资源是应用程序所在的Git，如下所示：

# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: web-application-repo
spec:
  type: git
  params:
    - name: url
      value: https://github.com/nodeshift-starters/react-pipeline-example
    - name: revision
      value: master

这里PipelineResource是git类型。params部分中的url键指向特定的存储库并设置master分支（这是可选的，但出于完整性考虑，我们将其编写为）。

现在我们需要为图像创建资源，将在其中保存s2i-web-app任务的结果，方法如下：

# This resource is the result of running "npm run build",  the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: built-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest

这里PipelineResource的类型为image，并且url参数值指向内部OpenShift Image Registry，特别是webapp-pipeline命名空间中的那个。如果使用其他名称空间，请记住要更改此参数。

最后，我们需要的最后一个资源也将是映像类型，这将是最终的NGINX映像，然后将在部署期间使用它：

# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: runtime-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest

再次注意，此资源将图像存储在webapp-pipeline命名空间的内部OpenShift注册表中。

要一次创建所有这些资源，请使用create命令：

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

您可以确保已创建资源，如下所示：

$ tkn resource ls

管道管线

现在我们已经拥有了所有必需的组件，我们将根据它们组装一个管道，并使用以下命令创建它：

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

但是，在运行此命令之前，让我们看一下这些组件。第一个是名称：

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

然后，在规范部分中，我们看到了我们之前创建的资源的指示：

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

然后，我们为管道创建任务以完成任务。首先，他必须执行我们已经创建的s2i-web-app任务：

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

此任务接受输入（GIR资源）和输出（Web应用程序图像资源内置）参数。我们还为它传递了一个特殊参数，以使它不会验证TLS，因为我们使用的是自签名证书：

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

下一个任务几乎相同，仅在这里已创建的webapp-build-runtime集群任务称为：

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

与上一个任务一样，我们正在传递资源，但这现在是一个内置的Web应用程序映像（上一个任务的输出）。作为输出，我们再次设置图像。由于此任务应在上一个任务之后执行，因此我们添加runAfter字段：

resources:
        inputs:
          - name: image
            resource: built-web-application-image
        outputs:
          - name: image
            resource: runtime-web-application-image
        params:
        - name: TLSVERIFY
          value: "false"
      runAfter:
        - build-web-application

接下来的两个任务负责为Web应用程序的k8s目录中的服务，路由和部署应用YAML文件，并在创建新映像时更新此部署。我们在本文开头设置了这两个集群任务。

运行输送机

因此，创建了管道的所有部分，我们将使用以下命令启动它：

$ tkn pipeline start build-and-deploy-react

在此阶段，以交互方式使用命令行，您需要根据其每个请求选择适当的资源：对于git资源，选择web-application-repo，然后对于第一个图像的资源，选择build-web-application-image，最后对于第二个图像资源–runtime-web-application-image：

? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr

现在，使用以下命令检查管道状态：

$ tkn pipeline logs -f

在管道启动并部署了应用程序之后，我们使用以下命令请求发布的路由：

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

为了获得更多可见性，您可以在“管道”部分的Web控制台的“开发人员”模式下查看我们的管道，如图2所示。1。

图。1。正在运行的管道概述。

单击正在运行的管道会显示其他信息，如图2所示。

数字：2.有关管道的更多信息。

获得更多信息后，您可以在“拓扑”视图中查看正在运行的应用程序，如图3所示。

图3.运行吊舱。

单击图标右上角的圆圈将打开我们的应用程序，如图4所示。

数字：4.启动React应用程序。

结论

因此，我们展示了如何在OpenShift上为您的应用程序运行开发服务器并将其与本地文件系统同步。我们还研究了如何使用OpenShift Pipelines模仿链式构建模板。本文的所有示例代码都可以在此处找到。

附加资源（英文）

即将举行的网络研讨会公告

我们将在星期五举行一系列网络研讨会，介绍使用Red Hat OpenShift容器平台和Kubernetes的原生体验：

现代OpenShift应用程序，第3部分：作为开发环境的OpenShift和OpenShift管道