gitlab CICD 部署

### 设置和使用GitLab CI/CD进行部署在GitLab中设置CI/CD流程涉及几个关键组件，包括定义`.gitlab-ci.yml`文件来描述构建、测试以及部署过程。该文件位于项目的根目录下，并指导GitLab Runner完成一系列任务。 #### 创建 `.gitlab-ci.yml` 为了启动CI/CD管道，在仓库的根路径创建名为`.gitlab-ci.yml`的YAML格式配置文件[^3]： ```yaml stages: - build - test - deploy variables: DOCKER_DRIVER: overlay2 before_script: - echo "Preparing environment..." build_job: stage: build script: - echo "Building the project..." only: - main test_job: stage: test script: - echo "Running tests..." only: - main deploy_job: stage: deploy script: - echo "Deploying application..." only: - main ``` 上述示例展示了基本结构，分为三个阶段：构建(build)，测试(test)，部署(deploy)。每个job都指定了要执行的具体命令序列。 #### 使用Runners执行作业 Runner是负责实际处理CI工作的实体。可以通过tags指定特定类型的Runner来运行某些jobs。例如，如果希望某个job仅由带有`docker` tag的Runner执行，则可以在job定义里加入如下内容: ```yaml install_dependencies: tags: -y curl ``` 如果不特别设定tag，默认会采用共享Runner来进行操作。对于私有项目或更复杂的场景，建议注册专属Runner并为其分配适当标签以便更好地控制资源利用情况。 #### 自动化部署至Kubernetes集群当目标平台为Kubernetes时，通常借助Helm Chart简化应用发布流程。下面是一个简单的例子说明怎样把应用程序推送到K8s环境中去: ```yaml deploy_to_k8s: image: google/cloud-sdk:latest stage: deploy script: - gcloud auth activate-service-account --install myapp ./charts/myapp \ --set image.tag=${CI_COMMIT_REF_NAME} \ --namespace ${NAMESPACE} only: - master when: manual ``` 这段脚本首先认证Google Cloud账号权限，接着调用helm命令更新现有release或者新建一个新实例(`upgrade --install`)，最后限定此步骤只会在master分支触发且需手动确认执行。

阅读全文