36、探索 FlixTube：从手动部署到持续交付

探索 FlixTube：从手动部署到持续交付

1. 部署 FlixTube 及验证

部署 FlixTube 会耗费一些时间。在部署前，需要记录两个关键信息：
- storage_account_name ：用于存储视频的 Azure 存储账户名称。
- storage_access_key ：存储账户的访问密钥。

部署完成后，需要验证 FlixTube 是否正常工作。可以通过以下步骤进行检查：
1. 使用 Kubernetes CLI 工具获取 FlixTube 的 IP 地址：

kubectl get services

若需回顾如何安装和使用 Kubectl，可参考相关说明。执行上述命令后，会得到一个表格输出，示例如下：
| NAME | TYPE | CLUSTER - IP | EXTERNAL - IP | PORT(S) | AGE |
| — | — | — | — | — | — |
| azure - storage | ClusterIP | 10.0.70.53 | | 80/TCP | 17h |
| db | ClusterIP | 10.0.233.222 | | 27017/TCP | 17h |
| gateway | LoadBalancer | 10.0.143.56 | 104.42.183.47 | 80:30360/TCP | 17h |
| history | ClusterIP | 10.0.246.117 | | 80/TCP | 17h |
| kubernetes | ClusterIP | 10.0.0.1 | | 443/TCP | 17h |
| metadata | ClusterIP | 10.0.218.226 | | 80/TCP | 17h |
| rabbit | ClusterIP | 10.0.185.74 | | 5672/TCP | 17h |
| video - streaming | ClusterIP | 10.0.230.53 | | 80/TCP | 17h |
| video - upload | ClusterIP | 10.0.244.47 | | 80/TCP | 17h |

2. 从 EXTERNAL - IP 列中找到 gateway 容器的 IP 地址。
3. 将该 IP 地址复制到浏览器地址栏中访问。注意，生产环境中的 FlixTube 配置为使用端口 80，这是 HTTP 的默认端口，因此无需指定端口号。

2. 手动部署的相关说明

目前使用的是 HTTP 协议，所以浏览器会在 FlixTube 的 IP 地址旁显示“不安全”。出于安全考虑，应使用 HTTP 的安全版本 HTTPS。若一切按计划进行，现在可以通过 FlixTube 的用户界面上传和播放视频。在此阶段，可以随意对 FlixTube 或 Terraform 代码进行更改，然后使用 terraform apply 应用更改。

当不再使用 FlixTube 时，务必清理相关基础设施，因为在云端运行这些基础设施会产生费用。可以使用以下命令销毁基础设施：

terraform destroy

3. Terraform 模块的使用

在部署 FlixTube 的多个微服务时，为了提高效率，可使用 Terraform 模块。Terraform 模块允许编写可重用的代码模块，通过提供不同的输入变量在不同环境中使用。以下是用于部署 FlixTube 微服务的 Terraform 模块示例：

variable "app_version" {} 
variable "service_name" {}
variable "dns_name" {
    default = ""
}
variable "login_server" {}
variable "username" {}
variable "password" {}
variable "service_type" {
    default = "ClusterIP"
}
variable "session_affinity" {
    default = ""
}
variable "env" {
    default = {}
    type = map(string)
} 
locals { 
    image_tag = "${var.login_server}/${var.service_name}:${var.app_version}"
} 

resource "kubernetes_deployment" "service_deployment" { 
    depends_on = [ null_resource.docker_push ]
    metadata {
        name = var.service_name 
        labels = {
            pod = var.service_name
        }
    }
    spec {
        replicas = 1
        selector {
            match_labels = {
                pod = var.service_name
            }
        }
        template {
            metadata {
                labels = {
                    pod = var.service_name
                }
            }
            spec {
                container {
                    image = local.image_tag
                    name  = var.service_name 
                    env {
                        name = "PORT"
                        value = "80"
                    }
                    dynamic "env" { 
                        for_each = var.env
                        content {
                          name = env.key
                          value = env.value
                        }
                    } 
                }
                image_pull_secrets {
                    name = kubernetes_secret.docker_credentials.metadata[0].name
                }
            }
        }
    }
}

resource "kubernetes_service" "service" { 
    metadata {
        name = var.dns_name != "" ? var.dns_name : var.service_name 
    }
    spec {
        selector = {
            pod = kubernetes_deployment.service_deployment.metadata[0].labels.pod
        }   
        session_affinity = var.session_affinity 
        port {
            port        = 80
            target_port = 80
        }
        type             = var.service_type 
    }
}

以下是使用该模块部署 gateway 微服务的示例：

locals { 
    login_server = azurerm_container_registry.container_registry.login_server
    username = azurerm_container_registry.container_registry.admin_username
    password = azurerm_container_registry.container_registry.admin_password
    rabbit = "amqp://guest:guest@rabbit:5672"
    database = "mongodb://db:27017"
} 

module "gateway - microservice" { 
    source = "./modules/microservice" 
    service_name = "gateway"             
    service_type = "LoadBalancer"        
    session_affinity = "ClientIP"       
    login_server = local.login_server   
    username = local.username           
    password = local.password             
    app_version = var.app_version      
    env = {                   
        RABBIT = local.rabbit
    }                       
} 

4. 搭建 FlixTube 的持续交付（CD）管道

手动部署完成后，接下来可以搭建 FlixTube 的持续交付（CD）管道。

4.1 先决条件

需要一个 Bitbucket 账户。若之前未创建，可在 https://bitbucket.org 注册免费账户。

4.2 设置代码仓库

1. 将相关代码仓库中 example - 1 子目录的全部内容复制到新位置。
2. 在新位置创建一个新的 Git 仓库，并将代码推送到托管的 Bitbucket 仓库。
3. 为仓库启用 Bitbucket Pipelines。若需详细的 Bitbucket 仓库设置说明，可参考相关内容。
4. 配置仓库的环境变量：
   • 添加用于 Azure 身份验证的变量，如 ARM_CLIENT_ID 、 ARM_CLIENT_SECRET 、 ARM_TENANT_ID 和 ARM_SUBSCRIPTION_ID 。
   • 添加用于视频存储微服务访问 Azure 存储账户的变量 STORAGE_ACCOUNT_NAME 和 STORAGE_ACCESS_KEY ，并将其值设置为之前记录的值。

4.3 准备后端

在首次调用 CD 管道之前，需要配置后端，以便 Terraform 的状态文件在后续调用中持久保存。具体步骤如下：
1. 创建一个不同的 Azure 存储容器供 Terraform 使用，不要复用存储视频的容器。
2. 取消 backend.tf 文件中的代码注释，并设置为自己的存储账户和容器详细信息。示例配置如下：

terraform {
    backend "azurerm" {
        resource_group_name  = "<your - resource - group>"
        storage_account_name = "<your - storage - account>" 
        container_name = "terraform" 
        key = "terraform.tfstate" 
    }
}

4.4 部署脚本

FlixTube 的部署脚本如下：

cd ./scripts 
terraform init 
terraform apply -auto - approve \ 
    -var "app_version=$VERSION" \                       
    -var "client_id=$ARM_CLIENT_ID" \                   
    -var "client_secret=$ARM_CLIENT_SECRET" \             
    -var "storage_account_name=$STORAGE_ACCOUNT_NAME" \   
    -var "storage_access_key=$STORAGE_ACCESS_KEY"         

4.5 CD 配置文件

对于 Bitbucket Pipelines，CD 配置文件是一个 YAML 文件，名为 bitbucket - pipelines.yaml ，需放置在代码仓库的根目录。示例配置如下：

image: hashicorp/terraform:0.12.6
pipelines:
    default:
      - step:
          name: Build and deploy
          services:
            - docker
          script:
            - export VERSION=$BITBUCKET_BUILD_NUMBER
            -  chmod +x ./scripts/deploy.sh
            - ./scripts/deploy.sh 

5. 测试 CD 管道及添加自动化测试

5.1 测试 CD 管道

可以通过以下方式测试 CD 管道：
1. 对代码进行小改动，例如修改 UI 中的一些文本。
2. 保存文件，提交更改，并将其推送到 Bitbucket。
3. 在 Bitbucket Pipelines 仪表板中观察管道是否被触发。首次调用管道时，由于要部署基础设施和微服务的第一个实例，会花费一些时间。
4. 管道准备好后，可再次使用 kubectl get services 获取 gateway 的 IP 地址，在浏览器中加载并进行测试。至此，就可以实现持续部署，任何推送到 Bitbucket 的代码更改都会自动部署到生产环境。

5.2 添加自动化测试

可以为 CD 管道添加自动化测试。由于遵循了相关约定，只需要记住一个命令 npm test 。可以通过以下两种方式添加自动化测试：

方式一：在部署脚本中添加

set -e 
cd ./metadata 
npm install 
npm test 
cd .. 
cd ./scripts
terraform init
terraform apply -auto - approve \
    -var "app_version=$VERSION" \
    -var "client_id=$ARM_CLIENT_ID" \
    -var "client_secret=$ARM_CLIENT_SECRET" 

方式二：在 Bitbucket Pipelines 配置文件中添加

image: hashicorp/terraform:0.12.6
pipelines:
    default:
      - step:
          name: Build and deploy
          services:
            - docker
          script:
            - cd metadata && npm install && npm test 
            - export VERSION=$BITBUCKET_BUILD_NUMBER
            -  chmod +x ./scripts/deploy.sh
            - ./scripts/deploy.sh

以下是 FlixTube 持续交付流程的 mermaid 流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(开发者编辑并提交代码):::process --> B(推送到托管代码仓库):::process
    B --> C(Bitbucket Pipelines 自动触发):::process
    C --> D(Docker 构建并发布镜像):::process
    D --> E(Terraform 构建基础设施并部署容器):::process
    E --> F(自动部署微服务到 Kubernetes 集群):::process

综上所述，通过上述步骤可以完成 FlixTube 的手动部署、持续交付管道搭建以及自动化测试的添加，实现代码更改的自动化部署和测试。

探索 FlixTube：从手动部署到持续交付

6. 各步骤总结与对比

为了更清晰地了解整个 FlixTube 部署和持续交付的过程，下面对关键步骤进行总结和对比，以表格形式呈现：
| 步骤 | 操作内容 | 关键命令或文件 |
| — | — | — |
| 部署前准备 | 记录 storage_account_name 和 storage_access_key | 无 |
| 部署验证 | 使用 kubectl get services 获取 IP 并在浏览器验证 | kubectl get services |
| 手动部署清理 | 不再使用时销毁基础设施 | terraform destroy |
| 代码仓库设置 | 复制代码、创建 Git 仓库、推送到 Bitbucket、启用 Pipelines、配置环境变量 | 无 |
| 后端准备 | 创建 Azure 存储容器，配置 backend.tf | backend.tf |
| 部署脚本 | 初始化 Terraform 并应用更改 | cd ./scripts; terraform init; terraform apply -auto-approve ... |
| CD 配置 | 编写 bitbucket - pipelines.yaml 文件 | bitbucket - pipelines.yaml |
| 测试 CD 管道 | 代码更改并推送，观察管道触发 | kubectl get services |
| 添加自动化测试 | 在部署脚本或配置文件中添加 npm test | npm test |

7. 常见问题及解决思路

在整个部署和持续交付过程中，可能会遇到一些常见问题，以下是一些问题及对应的解决思路：
- 部署失败 ：
- 检查环境变量是否配置正确，特别是 Azure 身份验证和存储账户相关的变量。
- 查看 Terraform 日志，确认是否有资源创建失败或依赖问题。
- CD 管道未触发 ：
- 检查 Bitbucket Pipelines 是否正确启用，配置文件是否存在语法错误。
- 确认代码推送是否正确，是否推送到了正确的分支。
- 自动化测试失败 ：
- 检查 npm test 命令是否能在本地正常运行，依赖是否安装完整。
- 查看测试日志，定位具体的测试用例失败原因。

8. 优化建议

为了提高 FlixTube 的部署效率和稳定性，可以考虑以下优化建议：
- 缓存机制 ：在 CD 管道中使用缓存，避免每次部署都重新下载依赖，例如缓存 Docker 镜像和 npm 包。
- 多环境部署 ：可以配置不同的环境（如开发、测试、生产），使用不同的 Terraform 变量文件进行部署，确保不同环境的配置隔离。
- 监控和报警 ：集成监控工具，对 FlixTube 的运行状态进行实时监控，并设置报警机制，当出现异常时及时通知相关人员。

9. 总结

通过本文的介绍，我们详细了解了 FlixTube 从手动部署到持续交付的全过程，包括部署前的准备、手动部署的操作、Terraform 模块的使用、持续交付管道的搭建、测试以及自动化测试的添加。同时，我们还总结了关键步骤、分析了常见问题及解决思路，并给出了一些优化建议。

在实际应用中，我们可以根据具体需求对流程进行调整和优化，确保 FlixTube 能够高效、稳定地运行。通过持续交付和自动化测试，我们可以快速响应代码更改，提高开发效率和软件质量。

以下是整个流程的 mermaid 流程图，更直观地展示了从代码更改到部署的完整过程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(开发者代码更改):::process --> B(提交并推送到 Bitbucket):::process
    B --> C(Bitbucket Pipelines 触发):::process
    C --> D{是否首次部署?}:::process
    D -->|是| E(创建基础设施和微服务):::process
    D -->|否| F(更新基础设施和微服务):::process
    E --> G(Docker 构建和发布镜像):::process
    F --> G
    G --> H(Terraform 应用更改):::process
    H --> I(部署到 Kubernetes 集群):::process
    I --> J(自动化测试):::process
    J -->|通过| K(持续交付完成):::process
    J -->|失败| L(检查并修复问题):::process
    L --> B

希望这些内容能够帮助你更好地理解和实践 FlixTube 的部署和持续交付，让你的开发工作更加高效和顺畅。