21、团队项目部署与配置全流程指南

团队项目部署与配置全流程指南

1. 团队项目前期准备

在为工程团队准备团队项目时，需要根据实际情况规划工作。现有 Gamecorp 门户团队使用为其设置的团队项目，而 Andromeda 团队的开发者使用 GitLab，源控制导入并非难事，帮助他们从使用的电子表格导入工作项也不复杂。但两个团队工作方式不同，为 Cardstock 开发资产和工作项设置新的团队项目，是维持各团队工作结构的最佳方式。

由于有两个不同的团队项目（一个用于 Cardstock，一个用于门户项目），有些设置需按项目进行，而有些可在项目集合级别统一设置。首先安装 Azure DevOps Services 账户级扩展，这些扩展后续配置构建和发布定义时会用到。

在深入配置之前，需创建个人访问令牌（PAT），用于设置构建代理、发布代理和部署组（如适用）。操作步骤如下：
1. 将鼠标悬停在头像上，选择“Security”。
2. 第一部分会显示 PAT，点击“Add”创建新的 PAT。
3. 暂时将其保存到本地，设置有效期为 90 天，并根据需要设置权限。不过，使用与单个用户账户关联的 PAT 通常不是最佳实践，需建立更长期的解决方案。

2. 服务主体原理

在许多组织中，在 Active Directory 中创建特权账户是常见做法。无论是服务账户、管理账户还是其他特殊用途账户，指定专用 AD 对象以限制暴露和访问，可使组织免受因某人将自己的账户用作网站或服务的“管理员”，然后离职而导致的潜在服务中断影响。

在 Azure AD 中，也有服务账户的概念，即服务主体，在门户的 Azure AD 面板中也可称为应用注册。创建服务主体有以下几种方式：
- 从 Azure 门户创建新的应用注册。
- 使用 Azure PowerShell cmdlets 管理 Azure AD。
- 使用 Azure Python CLI 管理 Azure AD。
- 直接从与 Azure 订阅关联的应用程序（如 Azure DevOps Services）创建。

当使用 Azure DevOps Services 时，很容易创建一个服务主体，以授权部署到用户有权访问的一个或多个订阅中。UI 会智能显示 Azure DevOps Services 中现有的 Azure 资源管理器端点，以及用户有权访问但尚未在 Azure DevOps Services 中授权的订阅。若选择授权一个在 Azure DevOps Services 中尚无服务端点的订阅，将创建一个与该订阅关联的新服务主体，其命名约定可能难以理解。

为简化管理员和用户对服务主体名称的管理，可采用以下两种方法：
- 创建专用且使用友好名称的服务主体，例如“Azure DevOps Services [AppName] Non - Prod”和“Azure DevOps Services [AppName] Prod”，有助于明确每个主体的范围和意图，还可将其添加到 Azure 中的各种基于角色的访问控制（RBAC）组中，以允许或限制对资源的访问。
- 创建传统的 AD 服务账户，并将其与 Azure AD 同步。此方法仅适用于有本地 AD 且在本地和 Azure AD 之间进行目录同步的组织。该方法还允许为服务账户分配基本许可证并生成 PAT，用于自动化 Azure DevOps Services 的构建和发布代理等操作。

2.1 新建服务主体练习

使用 Azure CLI 创建两个新的服务主体，以控制对 Azure 的非生产和生产访问，命令如下：

az ad sp create-for-rbac -n "VSTS Cardstock Non-Prod"
az ad sp create-for-rbac -n "VSTS Cardstock Prod"

务必记录每个命令的输出，其中包含 Azure AD 租户 ID、客户端（应用程序）ID 和账户的初始密码，这些信息在 Azure DevOps Services 中设置 Azure 服务端点时会用到。

3. 安装合适的扩展

有一些扩展在开始时就很有用。安装 Azure DevOps Services 扩展有两种方式：点击任何页面右上角（靠近个人资料）的“Marketplace”图标，或直接访问 https://marketplace.visualstudio.com 进行搜索。

需要安装的扩展如下：
- 基础扩展 ：Sonar 扩展和 WhiteSource 扩展（非 WhiteSource Bolt 扩展）。WhiteSource Bolt 扩展是与 WhiteSource 特定附加组件相关的，这里更关注旗舰 WhiteSource 产品提供的通用扫描和覆盖功能。
- 实用扩展 ：
- Code Search
- Package Management
- Delivery Plans
- Docker integration
- Replace Tokens
- Jenkins integration
- Team Project Health
- Azure DevOps Services Analytics

安装完基础扩展后，就可以开始设置与 Azure、Sonar 等交互的服务端点了。

4. 设置服务端点

确保团队项目能够连接到所需的一切，首先要建立服务端点。以下是在 Azure DevOps Services 中设置 Azure 订阅、SonarQube 端点和 WhiteSource 端点的步骤：

4.1 设置 Azure 服务端点

1. 点击团队项目的管理齿轮图标。
2. 点击“Services”链接。
3. 选择“New Service Endpoint”，从显示的列表中选择“Azure Resource Manager”以创建新的 Azure 服务端点。

点击“Azure Resource Manager”后，会弹出一个对话框，要求输入一些基本信息。由于使用之前创建的服务主体创建这些端点，需要使用“Add Endpoint”对话框的完整版本，点击“use the full version of the endpoint dialog”链接以启用高级视图。具体输入信息如下：
1. 为端点输入一个友好的（人类可读的）名称，如第一个端点用于非生产部署，可命名为“Gamecorp Dev”，这在将端点关联到构建和发布定义中的任务时很有用。
2. 输入第一个服务主体命令输出中的订阅 ID。
3. 输入与该 ID 关联的订阅名称。
4. 输入第一个服务主体命令输出中的客户端 ID。
5. 输入第一个服务主体命令输出中的密码。
6. 输入第一个服务主体命令输出中的 Azure AD 租户 ID。

点击“OK”添加此端点，然后重复上述步骤为第二个服务主体设置 Azure 生产订阅的服务端点。

4.2 设置 SonarQube 服务端点

1. 输入连接名称。
2. 输入 Sonar 实例的服务器 URL，该 URL 需可被代理访问，不一定要对外公开。
3. 输入与 Sonar 实例交互的令牌。要生成 Sonar 令牌，可按照 https://docs.sonarqube.org/display/SONAR/User+Token 上的说明操作。

4.3 设置 WhiteSource 服务端点练习

参考之前的示例，为团队项目设置新的 WhiteSource 服务。若还没有 WhiteSource 账户，可在 https://www.whitesourcesoftware.com 注册 14 天免费试用。按照 WhiteSource 网站上的说明创建 API 密钥，在添加新端点时显示的对话框中输入所需详细信息。为测试连接，可在新的或现有的构建定义中添加 WhiteSource 任务并运行构建，查看任务是否能使用新端点成功连接。

设置好端点后，接下来将在 Kubernetes 集群中设置构建代理池。部分情况下，无需一直启动代理，将最小实例数设置为零并按需扩展可能更合理。但默认的 CPU 利用率和 RAM 利用率等指标可能无法完全涵盖扩展构建代理的条件，可研究查询 Azure DevOps Services API 以了解排队构建的情况，看是否可作为可行的指标。

经过搜索，发现 GitHub 上有一个使用 Azure 服务总线来衡量代理使用数量的项目 https://github.com/torosent/kube-azure-servicebus-autoscaler ，它可以监控特定队列中的消息，若消息数量超过一定阈值，自动缩放器会根据选择的服务进行扩展或缩减。向队列添加消息有两种方法：在 Azure DevOps Services 中创建一个 Webhook，当代码签入时创建新消息；或让定义在启动时创建一个消息。但需要考虑如何检测构建何时完成，若代理队列中没有待处理的构建，需移除不需要的消息。

考虑到实际操作机制以及对构建架构功能性的需求，决定让团队自行控制集群中运行的代理数量。指导原则是尽量减少活动代理数量，当构建开始排队或耗时过长时，工程师可调整 Azure DevOps Services 代理部署的 Pod 数量，以平衡请求。

5. 建立构建服务

为构建代理池创建服务和部署工件是按需管道启动的下一步。通过向工程师调研，确定了团队需要的通用框架和特定需求如下：
- ASP.NET MVC 和 .NET Framework 4.6.2
- .NET Core
- Node.js
- Azure PowerShell / Azure 命令行界面（CLI）

经过初步实验发现，在集群中使用 Linux 构建代理，甚至使用 Azure DevOps Services 提供的托管 Linux 代理时，Azure PowerShell 命令无法正常工作。可选择使用 CLI，Azure DevOps Services 构建代理中有支持 Azure CLI 的任务处理程序，这样无需在镜像中添加额外依赖，但部分代码可能需要修改以使用 CLI 等效命令（如果可用）。

为满足这些依赖，使用 Dockerfile 构建自定义代理镜像，具体内容如下：

FROM microsoft/vsts-agent
RUN apt-get update
RUN curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
RUN mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
RUN sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-xenial-prod xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
RUN apt-get install apt-transport-https -y
RUN apt-get update
RUN apt-get install mono-complete nodejs npm dotnet-sdk-2.1.104 -y

任何其他特定于 NodeJS 的依赖项都可以使用 npm 安装。Mono 运行时除了提供 .NET Framework 外，还会提供 MSBuild，这在构建 C# 项目文件时很有用，因为需要 MSBuild 或兼容的构建引擎。

构建好自定义 Docker 镜像后，需要将其发布到注册表。由于 Gamecorp 使用自己的 Azure 容器注册表，可使用该注册表存储新镜像，操作步骤如下：
1. 使用 Docker 登录注册表：

docker login gamecorp.azurecr.io

2. 为构建的代理镜像添加存储库标签，可使用以下两种方法：
   - 使用 docker tag 命令为镜像添加另一个标签：

docker tag vsts-agent gamecorp.azurecr.io/vsts-agent

• 在使用 docker build 命令时指定存储库标签。

3. 使用 docker push 命令将新镜像推送到 ACR：

docker push gamecorp.azurecr.io/vsts-agent

在 Kubernetes 集群中使用该镜像之前，需要创建一个包含访问 ACR 实例所需凭据的机密。可在 Kubernetes 仪表板中点击“Create”创建新对象，或使用 kubectl 创建新机密，示例中使用 kubectl 命令：

kubectl create secret docker-registry gamecorp --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

将所有大写的值替换为 ACR 实例中的相应值。完成后，可在 Kubernetes 集群的“Secrets”部分看到“gamecorp”机密对象。

在从私有注册表创建部署或 Pod 时，需要指定 imagePullSecret 字段，值为“gamecorp”，这会告诉 Kubernetes 使用该机密中的凭据从存储在那里的镜像创建容器。通过仪表板 UI 创建新应用程序，展开“Show Advanced Options”，可看到 imagePullSecret 字段，输入相应值。

在创建应用程序之前，需输入两个环境变量：
- 一个是 Azure DevOps Services 实例的名称，环境变量名为“VSTS_ACCOUNT”，只输入创建的实例名称，而非整个 visualstudio.com URL 值。
- 另一个是之前创建的 PAT，环境变量名为“VSTS_TOKEN”。

创建应用程序后，可在 Azure DevOps Services 实例的管理部分查看“Agent Queues”区域。新应用程序启动后，应会看到一个新的代理添加到“Default”队列中。

6. 集群复制与问题解决

创建好一个集群副本后，可将其复制给其他团队。但发现尚未考虑 Andromeda 团队使用 Jenkins 的情况，不过 Jenkins 有标准的 Docker 镜像，可轻松集成到其中一个开发集群中。为利用外部数据存储和文件系统存储常用插件，决定复用为 SonarQube 构建的布局。

创建一个指向与 SonarQube 共享存储在同一存储账户中的新共享的持久卷。在 Kubernetes 中创建应用程序时，指定 jenkins_home 变量传递给容器，告诉它将插件目录映射到何处。

另外，Andromeda 工程师在修改代码时会构建容器镜像，但在容器内生成容器镜像存在问题。一种选择是创建一个专用的 VM 作为镜像创建点，但经过研究，发现 GitHub 上 genuinetools 的 img 实用工具可能符合需求，可避免搭建更多基础设施。

在构建代理的 Dockerfile 中添加以下代码片段（根据 GitHub 项目 README 文件中的二进制安装说明略有修改）：

# Export the sha256sum for verification.
ENV IMG_SHA256="dad4cec955803d3e8f42b9348c3ae25ee5fca73369364cd4419f77ec1e713040"

综上所述，通过以上一系列步骤，可以完成团队项目的前期准备、服务主体设置、扩展安装、服务端点配置、构建服务建立以及集群的复制和问题解决，为团队的开发和部署工作提供有力支持。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(团队项目前期准备):::process
    B --> C(创建个人访问令牌):::process
    C --> D(了解服务主体原理):::process
    D --> E(创建服务主体):::process
    E --> F(安装扩展):::process
    F --> G(设置服务端点):::process
    G --> H(设置构建代理池):::process
    H --> I(建立构建服务):::process
    I --> J(构建自定义 Docker 镜像):::process
    J --> K(发布镜像到注册表):::process
    K --> L(创建机密):::process
    L --> M(创建应用程序):::process
    M --> N(集群复制与问题解决):::process
    N --> O([结束]):::startend

以上流程图展示了从团队项目前期准备到最终完成集群复制和问题解决的整个流程，各个步骤依次进行，形成一个完整的开发和部署体系。

7. 构建代理池的进一步优化

虽然已经完成了构建代理池的基本设置，但为了提高效率和资源利用率，还可以进行一些优化。以下是一些建议：

7.1 代理资源监控

建立对构建代理资源使用情况的监控机制，包括 CPU、内存、磁盘 I/O 等。可以使用 Kubernetes 自带的监控工具，如 Prometheus 和 Grafana，也可以使用第三方监控工具。通过监控，可以及时发现资源瓶颈，调整代理数量或资源分配。

7.2 代理自动伸缩策略细化

除了根据构建队列长度进行伸缩外，还可以结合其他指标，如代理的平均响应时间、构建成功率等，制定更复杂的自动伸缩策略。例如，当平均响应时间超过一定阈值时，增加代理数量；当构建成功率低于一定比例时，检查代理是否存在问题并进行相应调整。

7.3 代理负载均衡

确保构建任务能够均匀地分配到各个代理上，避免出现部分代理负载过高，而其他代理闲置的情况。可以使用 Kubernetes 的负载均衡器，或者在 Azure DevOps Services 中配置代理队列的负载均衡规则。

8. 服务端点的安全管理

服务端点涉及到与外部服务的连接，因此安全管理至关重要。以下是一些安全管理的建议：

8.1 定期更新凭据

定期更新服务主体的密码和 PAT，避免因凭据泄露而导致安全风险。可以使用自动化脚本或工具来实现定期更新。

8.2 限制访问权限

只给服务端点分配必要的访问权限，避免过度授权。例如，对于 Azure 服务端点，只允许访问特定的资源组和订阅。

8.3 监控服务端点的使用情况

监控服务端点的使用情况，及时发现异常访问行为。可以使用 Azure DevOps Services 的审计日志或第三方安全监控工具。

9. 持续集成与持续部署（CI/CD）流程优化

在完成上述设置后，可以进一步优化 CI/CD 流程，提高开发和部署效率。

9.1 自动化测试

在构建和部署过程中加入自动化测试，确保代码质量。可以使用 SonarQube 进行代码静态分析，使用单元测试框架进行单元测试，使用集成测试框架进行集成测试。

9.2 多阶段部署

采用多阶段部署策略，如开发环境、测试环境、预生产环境和生产环境。每个阶段都进行严格的测试和验证，确保代码在生产环境中稳定运行。

9.3 回滚机制

建立回滚机制，当部署出现问题时，能够快速回滚到上一个稳定版本。可以使用 Azure DevOps Services 的发布定义中的回滚功能。

10. 总结与展望

通过以上一系列的操作，我们完成了团队项目的前期准备、服务主体设置、扩展安装、服务端点配置、构建服务建立以及集群的复制和问题解决，为团队的开发和部署工作搭建了一个高效、稳定的平台。

在未来的工作中，我们可以继续关注技术的发展，不断优化和改进现有的流程和架构。例如，随着容器技术和 Kubernetes 的不断发展，可以尝试使用更先进的容器编排技术和工具；随着人工智能和机器学习的应用，可以探索如何将其应用到 CI/CD 流程中，提高自动化程度和代码质量。

同时，我们也需要关注安全问题，不断加强安全管理，确保系统的安全性和稳定性。通过持续的学习和实践，不断提升团队的技术水平和创新能力。

10.1 关键步骤总结表格

步骤	操作内容
团队项目前期准备	规划工作，设置团队项目，安装 Azure DevOps Services 账户级扩展
创建个人访问令牌	鼠标悬停头像选 Security，点击 Add 创建，设置有效期和权限
创建服务主体	使用 Azure CLI 命令创建，记录输出信息
安装扩展	通过 Marketplace 安装 Sonar、WhiteSource 等扩展
设置服务端点	在 Azure DevOps Services 中设置 Azure、SonarQube、WhiteSource 等端点
建立构建服务	使用 Dockerfile 构建自定义镜像，发布到注册表，创建机密和应用程序
集群复制与问题解决	复制集群，解决 Andromeda 团队使用 Jenkins 和容器镜像构建问题

10.2 优化策略 mermaid 流程图

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始优化]):::startend --> B(构建代理池优化):::process
    B --> C(服务端点安全管理):::process
    C --> D(CI/CD 流程优化):::process
    D --> E(持续监控与改进):::process
    E --> F([结束优化]):::startend

这个流程图展示了从构建代理池优化开始，到服务端点安全管理、CI/CD 流程优化，最后持续监控与改进的整个优化过程，形成一个闭环，不断提升系统的性能和安全性。