如何创建简单的 CI/CD 管道
云原生应用因其提供的可扩展性和灵活性而蓬勃发展。然而,这种架构也面临诸多挑战。实施 CI/CD 流水线可以解决大部分挑战,例如定义交付流程、独立交付应用程序以及获得系统中众多构建块的可观察性。
CI/CD 流水线是实现软件交付流程自动化的关键,包括启动代码构建、运行自动化测试以及部署到测试或生产环境。
一条 CI/CD 流水线由多个步骤组成,这些步骤可以依次执行或并行执行。目前有两种常见的流水线语法—— 脚本式和声明式。它们之间的关键区别在于灵活性。
虽然两种语法都基于 Groovy DSL,但脚本化管道语法的限制较少。它几乎可以实现 Groovy 所能实现的所有功能。这意味着脚本的读写可能会变得困难。
另一方面,声明式语法限制性更强,并提供了定义明确的结构,非常适合更简单的 CI/CD 流水线。此语法支持“流水线即代码”的概念。因此,您可以编写一个文件,并将其签入到 Git 等源代码管理系统中。
为了让开发人员更方便地设置 CI/CD 管道,Microtica支持声明性语法来定义构建过程以及源代码。
声明式 CI/CD 管道
为了使流水线流程正常工作,每个组件/微服务在其源代码的根级别都应该有一个名为microtica.yaml的文件。该文件包含构建流程的规范。
在构建过程中,Microtica 从代码中提取规范。然后,它创建一个状态机来驱动定义的流程。
为了确保管道规范的单一真实来源,Microtica 不允许从 UI 更改构建管道。更改仅从每个源代码存储库中提供的 YAML 文件生效。我们发现这非常有助于避免定义、维护以及(最重要的是)调试过程中可能出现的混乱问题。
定义 CI/CD 管道
您可以定义的构建管道步骤没有限制。以下是microtica.yaml文件的一个示例,该文件定义了NodeJS 应用程序的构建管道。此管道执行命令部分中定义的三个特定命令。
Pipeline:
StartAt: Build
States:
Build:
Type: Task
Resource: microtica.actions.cmd
Parameters:
commands:
- npm install
- npm test
- npm prune --production
sourceLocation: "$.trigger.source.location"
artifacts: true
End: true
- Pipeline — 定义管道部分开始的根键
- StartAt — 定义管道的第一个动作
- 状态 — 定义特定管道的状态列表
- 类型 — 管道操作的类型。始终将其设置为“任务”。
- 资源 — 引擎将使用的操作。目前,我们支持microtica.actions.cmd,这是一个执行 Bash 脚本的操作。
- 参数 ——为操作提供的一组参数
- 命令 — bash 命令列表。在这里,您可以定义用于构建、测试、代码质量检查等的自定义脚本。
- sourceLocation — 操作可以找到源代码的位置。您不应更改此设置。从 Git 存储库提取后,Microtica 会将工件存储在用户为特定组件/微服务指定的位置。$.trigger.source.location定义了该位置。
- artifacts — 定义本次构建将生成的 artifacts 存储在 S3 中并在部署期间使用的值。如果构建的 artifacts 是 Docker 镜像,则应将此值设置为 false
- 结束 ——定义这是管道中的最后一个动作。
Microtica支持使用 bash 命令执行操作。未来,我们计划允许开发人员定义自己的自定义操作。
准备部署 Docker 镜像
让我们从上面的示例中创建一个扩展管道,添加一个额外的步骤来准备要部署的 Docker 镜像:
Pipeline:
StartAt: Build
States:
Build:
Type: Task
Resource: microtica.actions.cmd
Parameters:
environmentVariables:
pipelineId: "$.pipeline.id"
version: "$.commit.version"
commands:
- echo Starting build procedure...
- npm install
- npm test
- echo Logging in to Amazon ECR...
- $(aws ecr get-login --region $AWS_REGION --no-include-email)
- echo Checking if repository exists in ECR. If not, create one
- repoExists=`aws ecr describe-repositories --query "repositories[?repositoryName=='$pipelineId']" --output text`
- if [ -z "$repoExists" ]; then aws ecr create-repository --repository-name $pipelineId; fi
- awsAccountId=$(echo $CODEBUILD_BUILD_ARN | cut -d':' -f 5)
- artifactLocation=$awsAccountId.dkr.ecr.$AWS_REGION.amazonaws.com/$pipelineId
- echo Build Docker image...
- docker build -t $pipelineId .
- docker tag $pipelineId $artifactLocation:$version
- docker tag $pipelineId $artifactLocation:latest
- echo Push Docker image
- docker push $artifactLocation
sourceLocation: "$.source.location"
artifacts: false
End: true
在这个例子中,我们首先在步骤运行时使用environmentVariables参数注入环境变量($.pipeline.id和$.commit.version均由 Microtica 提供)。
最新示例中的 CI/CD 管道首先执行构建和测试代码所需的指令。完成后,如果 ECR 存储库尚不存在,Microtica 会创建一个。
一旦我们拥有了 ECR 存储库,最后一步就是构建一个新的 Docker 镜像,然后将其推送到存储库中。
使用构建管道定义microtica.yaml文件后,您可以在门户中使用向导创建组件或微服务时,在 Microtica 中自动化构建过程。此选项会将webhook添加到您的存储库。
Webhook 是一个监听器,每当您将新代码推送到代码库分支时,它都会触发构建过程。这样,您就可以确保始终使用最新的更改。
构建 Docker 镜像后,我们得到了一个工件,可以将其部署到 Kubernetes 集群中。您可以通过“微服务详情”-“添加到集群”或“Kubernetes 仪表盘”-“微服务”-“部署”来执行此操作。
在 Kubernetes 集群中部署微服务时,您可以选择扩展选项。此外,您还可以为微服务设置持续交付。
管道概述
手动或自动触发构建后,请在门户中关注构建过程并实时查看事件。如果构建失败,屏幕上会以红色标记,并在日志中显示错误。
在“管道概览”页面中关注组件和微服务的所有管道并追踪其状态。如果检测到多个构建失败, Microtica会将管道标记为不健康。
从此页面,您可以访问项目历史记录中的任何构建。更重要的是,您还可以检查日志以查找问题。
我们大力提倡自动化流程,因为它可以消除人工错误。此外,自动化流程对于可靠、可持续的软件交付至关重要。
它们提高了软件开发人员的生产力,使他们不再需要手动执行流程步骤。最重要的是,它们减轻了新产品发布带来的压力。
PS:如果您在尝试过程中遇到任何问题,请随时联系我。
鏂囩珷鏉ユ簮锛�https://dev.to/microtica/how-to-create-a-simple-ci-cd-pipeline-420