发布新帖
文章
· 九月 27 阅读大约需 9 分钟

使用 GitLab 持续交付 InterSystems 解决方案 – 第 7 部分：使用容器的

#Git #变更管理 #容器化 #持续交付 #持续集成 #最佳实践 #Caché

在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：

  • Git 101
  • Git 流程（开发流程）
  • GitLab 安装
  • GitLab 工作流
  • 持续交付
  • GitLab 安装和配置
  • GitLab CI/CD
  • 为何使用容器
  • 容器基础架构
  • 使用容器的 CD

在第一篇文章中，我们介绍了 Git 基础知识、深度理解 Git 概念对现代软件开发至关重要的原因，以及如何使用 Git 开发软件。

在第二篇文章中，我们介绍了 GitLab 工作流 – 一个完整的软件生命周期流程，并介绍了持续交付。

在第三篇文章中，我们介绍了 GitLab 安装和配置以及将环境连接到 GitLab

在第四篇文章中，我们编写了 CD 配置。

在第五篇文章中，我们讨论了容器以及使用容器的方式（和原因）。

在第六篇文章中，我们将探讨运行包含容器的持续交付管道所需的主要组件以及这些组件如何协同运行。

在这篇文章中，我们将构建上一篇文章中探讨的持续交付配置。

工作流

在持续交付配置中，我们会：

  • 将代码推送到 GitLab 仓库
  • 构建 docker 镜像
  • 进行测试
  • 将镜像发布到 docker 注册表
  • 将旧容器换为注册表中的新版本

也可以用示意图形式表示此流程：

我们开始吧。

构建

首先，我们需要构建镜像。

我们的代码通常存储在仓库中，CD 配置位于 gitlab-ci.yml 中，但为了提高安全性，我们会在构建服务器上存储几个服务器特定的文件。

GitLab.xml

包含 CD 挂钩代码。 该代码是在上一篇文章中开发的，并在 GitHub 上提供。 这是一个小型库，用于加载代码、运行各种挂钩以及测试代码。 作为更好的替代方案，您可以使用 git 子模块将此项目或类似项目包含到您的仓库中。 最好选择子模块，因为子模块更容易保持最新状态。 另一个替代方案是在 GitLab 上为版本添加标签，并使用 ADD 命令加载这些版本。

iris.key

许可证密钥。 或者，它可以在容器构建过程中下载，而不是存储在服务器上。 将密钥存储在仓库中非常不安全。

pwd.txt

包含默认密码的文件。 将这类文件存储在仓库中也非常不安全。 此外，如果您在单独的服务器上托管生产环境，它可能有不同的默认密码。

load_ci.script

初始脚本，它执行以下任务：

  • 实现操作系统身份验证
  • 加载 GitLab.xml
  • 初始化 GitLab 实用工具设置
  • 加载代码


set sc = ##Class(Security.System).Get("SYSTEM",.Properties)
write:('sc) $System.Status.GetErrorText(sc)
set AutheEnabled = Properties("AutheEnabled")
set AutheEnabled = $zb(+AutheEnabled,16,7)
set Properties("AutheEnabled") = AutheEnabled
set sc = ##Class(Security.System).Modify("SYSTEM",.Properties)
write:('sc) $System.Status.GetErrorText(sc)
zn "USER"
do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk")
do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/")
do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/")
do ##class(isc.git.GitLab).load()
halt

请注意，第一行有意留空。

由于某些设置可以是服务器特定的，脚本不会存储在仓库中，而是单独存储。 如果此初始挂钩始终相同，将其存储在仓库中即可。

gitlab-ci.yml

现在，继续持续交付配置：

构建镜像：
  stage: build
  tags:
    - test
  script:
    - cp -r /InterSystems/mount ci
    - cd ci
    - echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt
    - mv temp.txt load_ci.script
    - cd ..
    - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME .

这里会执行哪些操作？

首先，由于 docker build 只能访问基础构建目录的子目录（本例中是仓库根目录），我们需要将“秘密”目录（包含 GitLab.xml、iris.key、pwd.txt 和 load_ci.script 的目录）复制到克隆的仓库中。

接下来，首次终端访问需要用户名/密码，因此我们会将这些信息添加到 load_ci.script 中（这也是 load_ci.script 开头一行留空的原因）。

最后，我们会构建 docker 镜像并适当地为其添加标签：docker.domain.com/test/docker:$CI_COMMIT_REF_NAME

其中，$CI_COMMIT_REF_NAME 是当前分支的名称。 请注意，镜像标签的第一部分应与 GitLab 中的项目名称相同，这样才能在 GitLab 的“注册表”标签页中看到它（“注册表”标签页中提供了关于添加标签的说明）。

Dockerfile

构建 docker 镜像是通过 Dockerfile 完成的，具体如下：

FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0

ENV SRC_DIR=/tmp/src
ENV CI_DIR=$SRC_DIR/ci
ENV CI_PROJECT_DIR=$SRC_DIR

COPY ./ $SRC_DIR

RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \
 && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \
 && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \
 && iris start $ISC_PACKAGE_INSTANCENAME \
 && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \
 && iris stop $ISC_PACKAGE_INSTANCENAME quietly

我们从基本的 iris 容器开始。

首先，我们将仓库（和“秘密”目录）复制到容器中。

接下来，我们将许可证密钥和 GitLab.xml 复制到 mgr 目录中。

然后，我们将密码更改为 pwd.txt 中的值。 请注意，此操作会删除 pwd.txt。

之后，实例启动并执行 load_ci.script。

最后，iris 实例停止。

以下是作业日志（部分日志，跳过了加载/编译日志）：

Running with gitlab-runner 10.6.0 (a3543a27)
  on docker 7b21e0c4
Using Shell executor...
Running on docker...
Fetching changes...
Removing ci/
Removing temp.txt
HEAD is now at 5ef9904 Build load_ci.script
From http://gitlab.eduard.win/test/docker
   5ef9904..9753a8d  master     -> origin/master
Checking out 9753a8db as master...
Skipping Git submodules setup
$ cp -r /InterSystems/mount ci
$ cd ci
$ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt
$ mv temp.txt load_ci.script
$ cd ..
$ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME .
Sending build context to Docker daemon  401.4kB

Step 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0
 ---> cd2e53e7f850
Step 2/6 : ENV SRC_DIR=/tmp/src
 ---> Using cache
 ---> 68ba1cb00aff
Step 3/6 : ENV CI_DIR=$SRC_DIR/ci
 ---> Using cache
 ---> 6784c34a9ee6
Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR
 ---> Using cache
 ---> 3757fa88a28a
Step 5/6 : COPY ./ $SRC_DIR
 ---> 5515e13741b0
Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/  && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/  && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt  && iris start $ISC_PACKAGE_INSTANCENAME  && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script  && iris stop $ISC_PACKAGE_INSTANCENAME quietly
 ---> Running in 86526183cf7c
.
Waited 1 seconds for InterSystems IRIS to start
This copy of InterSystems IRIS has been licensed for use exclusively by:
ISC Internal Container Sharding
Copyright (c) 1986-2018 by InterSystems Corporation
Any other use is a violation of your license agreement

%SYS>
1

%SYS>
Using 'iris.cpf' configuration file

This copy of InterSystems IRIS has been licensed for use exclusively by:
ISC Internal Container Sharding
Copyright (c) 1986-2018 by InterSystems Corporation
Any other use is a violation of your license agreement

1 alert(s) during startup. See messages.log for details.
Starting IRIS

Node: 39702b122ab6, Instance: IRIS

Username:
Password:

Load started on 04/06/2018 17:38:21
Loading file /usr/irissys/mgr/GitLab.xml as xml
Load finished successfully.

USER>

USER>

[2018-04-06 17:38:22.017] Running init hooks: before

[2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/

[2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global

[2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local

[2018-04-06 17:38:22.375] Importing dir /tmp/src/

Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl

Compilation started on 04/06/2018 17:38:22 with qualifiers 'c'
Compilation finished successfully in 0.194s.

Load finished successfully.

[2018-04-06 17:38:22.876] Running init hooks: after

[2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local

[2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.Global
Removing intermediate container 39702b122ab6
 ---> dea6b2123165
[Warning] One or more build-args [CI_PROJECT_DIR] were not consumed
Successfully built dea6b2123165
Successfully tagged docker.domain.com/test/docker:master
Job succeeded

请注意，我使用的是 GitLab Shell 执行器，而不是 Docker 执行器。 当您需要从镜像内部提取某些内容时，将使用 Docker 执行器，例如在 Java 容器中构建 Android 应用程序并且只需要一个 apk 时。 在我们的示例中，我们需要整个容器，因此需要使用 Shell 执行器。 因此，我们通过 GitLab Shell 执行器运行 Docker 命令。

 

运行

我们构建了镜像，接下来要运行镜像。如果是功能分支，我们销毁旧容器并启动新容器即可。 如果是环境，我们可以运行临时容器，在测试成功的情况下，可以替换环境容器（此内容留给读者作为练习）。

脚本如下。

destroy old:
  stage: destroy
  tags:
    - test
  script:
    - docker stop iris-$CI_COMMIT_REF_NAME || true
    - docker rm -f iris-$CI_COMMIT_REF_NAME || true

此脚本会销毁当前运行的容器，并且始终都会成功（默认情况下，如果 docker 尝试停止/移除不存在的容器，则会失败）。

接下来，我们启动新镜像并将其注册为环境。 Nginx 容器 使用 VIRTUAL_HOST 环境变量和 expose 指令（用于了解要代理的端口）自动代理请求。

run image:
  stage: run
  environment:
    name: $CI_COMMIT_REF_NAME
    url: http://$CI_COMMIT_REF_SLUG. docker.domain.com/index.html
  tags:
    - test
  script:
    - docker run -d
      --expose 52773
      --env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win
      --name iris-$CI_COMMIT_REF_NAME
      docker.domain.com/test/docker:$CI_COMMIT_REF_NAME
      --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log

 

测试

我们来运行一些测试。

test image:
  stage: test
  tags:
    - test
  script:
    - docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()"

发布

最后，我们将镜像发布到注册表中

publish image:
  stage: publish
  tags:
    - test
  script:
    - docker login docker.domain.com -u dev -p 123
    - docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME

可以使用 GitLab 秘密变量传递用户名/密码。

现在，我们可以在 GitLab 中看到该镜像：

其他开发者可以从注册表中拉取该镜像。 “环境”标签页上提供了我们所有的环境，可以轻松进行浏览：

 

结论

在这一系列文章中，我介绍了持续交付的常规方式。 这是一个涉及面非常广的话题，您应将这一系列文章视为方法集合，而不是确定性内容。 如果您想自动构建、测试和交付应用程序，可以选择持续交付（一般情况）和 GitLab（特殊情况）。 利用持续交付和容器，您可以根据需要自定义工作流。

链接

后续内容

就是这些！ 希望我已介绍了持续交付和容器的基础知识。

但还有一些主题我没有介绍（可能后面会介绍），特别是关于容器的内容：

  • 数据可以在容器外持久保持，以下是相关文档
  • kubernetes 等编排平台
  • InterSystems Cloud Manager
  • 环境管理 – 创建临时环境以进行测试，在功能分支合并后移除旧环境
  • Docker compose 可以实现多容器部署
  • 缩减 docker 镜像大小并缩短构建时间
  • ...
讨论 (0)0
登录或注册以继续