企业平台管理技巧

此页面收集了有关 Travis CI 企业版 (TCIE) 平台日常维护脚本和工具的常见问题解答。

TCIE 3.x：请使用 kubectl 在您的本地机器上 访问您的平台 Pod

TCIE 2.x：在开始之前，请通过 SSH 连接到您的平台机器。

检查日志和运行服务 #

平台日志 #

TCIE 3.x 中的日志 #

在 TCIE 3.x 中，每个服务都部署在单独的 Pod 中。服务日志不会存储在 Pod 中，而是传递到标准输出。

为了从特定的运行 Pod 中获取实时日志，可以在 您的本地机器上 运行

kubectl logs [pod-name]

我们强烈建议设置一个实例，从 Pod 的标准输出获取实时日志并将其存储在您选择的日志存储中。这些存储的日志在诊断或解决已终止和/或重新部署的 Pod 的情况时非常有用。日志的大小严格取决于您的使用情况，因此请根据您的需要进行调整。一般来说，建议存储 4 周的日志。

TCIE 2.x 中的日志 #

在平台上，您可以在 /var/travis/log/travis.log 找到主日志文件。为了方便起见，它们也链接到 /var/log/travis.log。

Worker 日志 #

以 Ubuntu 16.04 及更高版本作为主机操作系统 #

在 Worker 上，您可以通过运行以下命令获取 Worker 日志

$ sudo journalctl -u travis-worker

以 Ubuntu 14.04 作为主机操作系统 #

在 Worker 上，您可以在 /var/log/upstart/travis-worker.log 找到主日志文件。

访问平台上的 Travis 容器和控制台 #

TCIE 3.x 中的控制台访问 #

对于 TCIE 3.x，您可以通过 kubectl 命令访问各个 Pod（相当于企业版 2.x 版本中的 travis bash）。为了运行控制台命令，请在 travis-api-pod 中运行控制台

kubectl exec -it [travis-api-pod] /app/script/console

TCIE 2.x 中的容器和控制台访问 #

travis bash：这将使您进入平台上正在运行的容器。

travis console：这将使您进入平台上的 Ruby IRB 会话。

取消或重置卡住的作业 #

有时，作业可能会在 Worker 上卡在 queued 状态。要取消或重置大量作业，请执行以下步骤

TCIE 3.x：kubectl exec -it [travis-api-pod]j /app/script/console 在您的本地机器上

TCIE 2.x：$ travis console 在平台主机上

然后，请运行

>> stuck_jobs = Job.where(queue: 'builds.linux', state: 'queued').where('queued_at < NOW() - interval \'60 minutes\'').all
>> # Cancels all stuck jobs
>> stuck_jobs.each(&:cancel!)
>> # Or reset them
>> stuck_jobs.each(&:reset!)

清除 Redis 存档队列（适用于版本 < 2.1.7） #

在 2.1.7 之前的企业版版本中，作业会在存档队列中排队以进行日志聚合。目前，此功能仅适用于 Travis CI 的托管版本。

这会导致队列越来越大，但不会被处理。因此，Redis 的内存消耗会随着时间的推移而增加，并可能导致整个平台性能下降。解决方法是清除 archive 队列以释放系统资源。

要清除它，请执行以下命令

TCIE 3.x：kubectl exec -it [travis-api-pod]j /app/script/console 在您的本地机器上

TCIE 2.x：$ travis console 在平台主机上

然后，请运行

>> require 'sidekiq/api'
>> Sidekiq::Queue.new('archive').clear

在 TCIE 3.x 中管理 RabbitMQ #

RabbitMQ 现在部署在名为 travisci-platform-rabbitmq-ha-0 的单独 Pod 中，所有与 Rabbit 相关的维护都应在此处完成。要访问 RabbitMQ Pod，请执行

kubectl exec -it travisci-platform-rabbitmq-ha-0 bash

并执行任何必要的操作。

RabbitMQ 管理 UI 可在 https://[platform-hostname]/amqp_ui 下访问。

在 TCIE 2.x 中重置 RabbitMQ 证书 #

在将 Replicated 2.8.0 升级到较新版本后，服务有时会重新启动并出现以下错误

$ docker inspect --format '{{.State.Error}}' focused_yalow
oci runtime error: container_linux.go:247: starting container process
caused "process_linux.go:359: container init caused
\"rootfs_linux.go:54: mounting
\\\"/var/lib/replicated-operator/44c648980d1e4b1c5a97167046f32f11/etc/travis/ssl/rabbitmq.cert\\\"
to rootfs
\\\"/var/lib/docker/aufs/mnt/a00833d25e72b761e2a0e72b1015dd2b2f3a32cafd2851ba408b298f73b37d37\\\"
at
\\\"/var/lib/docker/aufs/mnt/a00833d25e72b761e2a0e72b1015dd2b2f3a32cafd2851ba408b298f73b37d37/etc/travis/ssl/rabbitmq.cert\\\"
caused \\\"not a directory\\\"\""
: Are you trying to mount a directory onto a file (or vice-versa)? Check
if the specified host path exists and is the expected type

要解决此问题，请从 /etc/travis/ssl/ 中删除 RabbitMQ 证书。

$ sudo rm -r /etc/travis/ssl/rabbitmq.cert

之后，完全重新启动系统，一切应该能够正常启动。

查看 Sidekiq 队列统计信息 #

过去曾报告过系统变得无响应的情况。作业需要相当长的时间才能被处理完，或者根本没有被获取。我们发现，Sidekiq 队列已满通常是造成这种情况的原因。为了获得一些见解，在 Ruby 控制台中检索一些基本统计信息很有帮助

TCIE 3.x：kubectl exec -it [travis-api-pod]j /app/script/console 在您的本地机器上

TCIE 2.x：$ travis console 在平台主机上

然后，请运行

  >> require 'sidekiq/api'
  => true
  >> stats = Sidekiq::Stats.new
  >> stats.queues
  => {"sync.low"=>315316,
      "archive"=>7900,
      "repo_sync"=>193,
      "webhook"=>0,
      "keen_events"=>0,
      "scheduler"=>0,
      "github_status"=>0,
      "build_requests"=>0,
      "build_restarts"=>0,
      "hub"=>0,
      "slack"=>0,
      "pusher"=>0,
      "pusher-live"=>0,
      "build_cancellations"=>0,
      "sync"=>0,
      "user_sync"=>0}

卸载 Travis CI 企业版 3.x #

如果要从 Kubernetes 集群中卸载 Travis CI 企业版 3.x，请执行

kubectl delete ns [namespace] 在您的本地机器上

在 Worker 机器上，您需要运行此命令以删除 travis-worker 和所有构建镜像

$ sudo docker images | grep travis | awk '{print $3}' | xargs sudo docker rmi -f

卸载 Travis CI 企业版 2.x #

如果要从平台和 Worker 机器上卸载 Travis CI 企业版 2.x，请按照以下说明操作。在平台机器上，您需要按顺序运行以下命令。(说明复制自 Replicated)

以 Ubuntu 16.04 作为主机操作系统 #

sudo systemctl stop replicated
sudo systemctl stop replicated-ui
sudo systemctl stop replicated-operator
sudo docker ps | grep "replicated" | awk '{print $1}' | xargs sudo docker stop
sudo docker ps | grep "quay.io-travisci-te-main" | awk '{print $1}' | xargs sudo docker stop
sudo docker rm -f replicated replicated-ui replicated-operator replicated-premkit replicated-statsd
sudo docker images | grep "replicated" | awk '{print $3}' | xargs sudo docker rmi -f
sudo docker images | grep "te-main" | awk '{print $3}' | xargs sudo docker rmi -f
sudo rm -rf /var/lib/replicated* /etc/replicated* /etc/init/replicated* /etc/init.d/replicated* /etc/default/replicated* /var/log/upstart/replicated* /etc/systemd/system/replicated*

在 Worker 机器上，您需要运行此命令以删除 travis-worker 和所有构建镜像

$ sudo docker images | grep travis | awk '{print $3}' | xargs sudo docker rmi -f

以 Ubuntu 14.04 作为主机操作系统 #

sudo service replicated stop
sudo service replicated-ui stop
sudo service replicated-operator stop
sudo docker stop replicated-premkit
sudo docker stop replicated-statsd
sudo docker rm -f replicated replicated-ui replicated-operator replicated-premkit replicated-statsd
sudo docker images | grep "quay\.io/replicated" | awk '{print $3}' | xargs sudo docker rmi -f
sudo apt-get remove -y replicated replicated-ui replicated-operator
sudo apt-get purge -y replicated replicated-ui replicated-operator
sudo rm -rf /var/lib/replicated* /etc/replicated* /etc/init/replicated* /etc/init.d/replicated* /etc/default/replicated* /var/log/upstart/replicated* /etc/systemd/system/replicated*

在 Worker 机器上，您需要运行此命令以删除 travis-worker

$ sudo apt-get autoremove travis-worker

此外，请使用以下命令清理所有 Docker 构建镜像

$ sudo docker images | grep travis | awk '{print $3}' | xargs sudo docker rmi -f

了解最大可用并发数 #

要了解在您的 Travis CI 企业版设置中可用的并发数

TCIE 3.x：kubectl exec -it travisci-platform-rabbitmq-ha-0 bash 在您的本地机器上

TCIE 2.x：通过 SSH 连接到您的平台机器并运行 $ travis bash

然后，请运行

root@te-main:/# rabbitmqctl list_consumers -p travis | grep builds.trusty | wc -l

此处返回的数字等于可用的最大并发作业数。要调整并发性，请按照每个 Worker 机器的 此处 的说明进行操作。

了解有多少 Worker 机器已连接 #

如果要了解当前连接了多少 Worker 机器，请按照以下步骤操作

TCIE 3.x：kubectl exec -it travisci-platform-rabbitmq-ha-0 bash

TCIE 2.x：通过 SSH 连接到您的平台机器并运行：$ travis bash

然后，请运行

root@te-main:/# rabbitmqctl list_consumers -p travis | grep amq.gen- | wc -l

如果需要启动更多 Worker 机器，请参阅我们有关 安装新的 Worker 机器 的文档。

将 Travis CI 企业版集成到您的监控中 #

要检查您的 Travis CI 企业版 2.x/3.x 安装是否正在运行，请查询实例的 /api/uptime 端点。

$ curl -H "Authorization: token XXXXX" https://<your-travis-ci-enterprise-domain>/api/uptime

如果一切正常，它将返回 HTTP 200 OK，或者在发生故障时返回 HTTP 500 Internal Server Error。

配置备份 #

本节说明如何将 Travis CI 企业版集成到您的备份策略中。在这里，我们将讨论两个主题

• 加密密钥
• 数据目录

加密密钥 #

如果没有加密密钥，则无法访问生产数据库中的信息。为了确保您可以始终恢复数据库，请备份此密钥。

如果没有加密密钥，则无法恢复数据库中的信息。

要在 TCIE 3.x 中备份加密密钥，请按照以下步骤操作

1. 确保您具有对 Kubernetes 集群的适当访问权限：您需要 kubectl 的凭据以及到 [travis-api-pod] 的连接。
2. 运行 kubectl exec -it [travis-api-pod] cat /app/config/travis.yml |grep -A 2 encryption（建议使用 Travis API Pod）。
3. 通过将其写在纸上或存储在另一台计算机上，创建该命令返回值的备份。

要在 TCIE 2.x 中备份加密密钥，请按照以下步骤操作

1. 打开到平台机器的 SSH 连接。
2. 通过运行 travis bash，在 Travis CI 容器上以 root 权限打开 bash 会话。
3. 运行以下命令以获取密钥：grep -A1 encryption: /usr/local/travis/etc/travis/config/travis.yml。
4. 通过将其写在纸上或存储在另一台计算机上，创建该命令返回值的备份。

创建数据目录的备份 #

TCIE 3.x 中的数据备份 #

除非您正在运行 PostgreSQL、RabbitMQ 和 Redis 的自托管实例，否则相应的数据将保存在托管这些服务的 Pod 中。

为了备份 Postgres 数据库，您需要数据库凭据和连接字符串。在 TCIE 3.x 平台 Pod 上，请运行

kubectl exec -it [travis-api-pod] bash

连接到 Pod 后，获取数据库配置数据

root@[travis-api-pod]:/app# cat /app/config/travis.yml | grep database -A 10

您需要查找节点 database: 和 logs_database:。请记录下结果。

database:
  # ....
  host: [main db host name]
  port: [main db port]
  database: [main db name]
  username: [user name]
  password: [password]
#...
logs_database:
  urls: postgres://[username]:[password]@[logs db host name]:[port]/[database name]

接下来，连接到数据库 Pod 并对每个数据库执行数据转储。

root@[travis-api-pod]:/# pg_dump -U travis -h [main database pod] -p [main database port] -C -d [main db name] > [Main DB].sql
root@[travis-api-pod]:/# pg_dump -U travis -h [logs database pod] -p [logs database port] -C -d [logs db name] > [Logs DB].sql

之后，将转储的数据从您的集群复制到您的本地机器。

kubectl cp [travis-api-pod]:/[location of [Main DB].sql] [local_file] 
kubectl cp [travis-api-pod]:/[location of [Logs DB].sql] [local_file] 

如果您想直接从 DB Pod 运行 pg_dump：TCIE 3.x 集群在非 HA 部署中的数据库 Pod 应命名为 travisci-platform-platform-postgresql-0 和 travisci-platform-logs-postgresql-0。

此外，您需要连接到 **Redis** 和 **RabbitMQ** Pod，执行数据转储并将它们以类似的方式从集群中复制出来，使用这些服务可用的工具。有关如何对数据当前状态进行快照/备份的确切说明，请参阅 Redis 文档 和 RabbitMQ 备份和恢复指南 的相应部分。

TCIE 2.x 中的数据备份 #

数据目录位于平台机器上，并挂载到 Travis CI 容器中。在这些目录中，您会找到来自 RabbitMQ、Postgres、Slanger、Redis 的文件，以及容器内各种应用程序的日志文件。

这些文件位于平台机器上的 /var/travis。请运行 sudo tar -czvf travis-enterprise-data-backup.tar.gz /var/travis 以从此文件夹创建压缩存档。完成后，将此文件从机器复制到安全位置。

从 GitHub 服务迁移到 Webhook #

Travis CI Enterprise 最初使用 GitHub 服务将您的存储库与 GitHub.com（或 GitHub Enterprise）连接起来。截至 2019 年 1 月 31 日，github.com 上的服务已被禁用。从 GitHub Enterprise v2.17.0 开始，服务也将被禁用。

从 Travis CI Enterprise v2.2.5 开始，所有激活的存储库都使用 Webhook 来连接和管理与 GitHub.com/GitHub Enterprise 的通信。

在 Travis CI Enterprise v2.2.5 之前激活的存储库可能需要更新。

从 Travis CI Enterprise v2.2.8 开始，提供了一个自动更新存储库的迁移工具。迁移工具将更新使用已弃用的 GitHub 服务而不是 Webhook 的存储库。

要执行自动迁移，请按照以下步骤操作

1. **仅限 TCIE 2.x**：打开到平台机器的 SSH 连接。
2. 运行以下命令

TCIE 3.x:

kubectl exec -it [travis-api-pod] bash
root@[travis-api-pod]:/# bundle exec /app/bin/migrate_hooks <optional-year>

TCIE 2.x:

travis bash -c ". /etc/profile; cd /usr/local/travis-api && ENV=production bundle exec ./bin/migrate-hooks <optional-year>"

这将搜索所有仍在使用 GitHub 服务并将其迁移到使用 Webhook 的活动存储库。

您可以在上述命令中提供年份参数（例如 2017），以仅迁移在该年份在 Travis CI Enterprise 上激活的存储库。

如果您在 Travis CI Enterprise 安装上激活了大量存储库，请多次运行迁移，按年份将其分解。例如

TCIE 3.x:

kubectl exec -it [travis-api-pod] bash
root@[travis-api-pod]:/# bundle exec /app/bin/migrate_hooks 2019
root@[travis-api-pod]:/# bundle exec /app/bin/migrate_hooks 2018
root@[travis-api-pod]:/# bundle exec /app/bin/migrate_hooks 2017

TCIE 2.x:

travis bash -c ". /etc/profile; cd /usr/local/travis-api && ENV=production bundle exec ./bin/migrate-hooks 2019"
travis bash -c ". /etc/profile; cd /usr/local/travis-api && ENV=production bundle exec ./bin/migrate-hooks 2018"
travis bash -c ". /etc/profile; cd /usr/local/travis-api && ENV=production bundle exec ./bin/migrate-hooks 2017"

迁移完成后，您的存储库不应该出现任何行为变化。

联系企业支持 #

要与我们联系，请发送邮件至 enterprise@travis-ci.com。如果可能，请尽可能多地包含以下内容

• 问题描述 - 您观察到了什么？
• 您已经尝试了哪些步骤？
• 支持包（请参阅下表了解如何获取）
• 所有 worker 的日志文件（它们位于 /var/log/upstart/travis-worker.log - 请尽可能多地包含您能检索到的文件）。
• 如果构建失败或出错，则为构建日志的文本文件

自 2020 年第三季度宣布以来，Travis CI Enterprise 的最新版本是 3.x 系列。版本 2.2 没有新版本发布，并且自 2021 年 3 月以来支持补丁也已受到限制。对于 Travis CI 2.x 的现有用户，我们强烈建议您升级到最新的 Travis CI Enterprise 3.x。

您是否对您的设置进行了任何自定义？虽然我们可能能够看到一些信息（例如主机名、IaaS 提供商和许可证到期日期），但还有许多其他我们看不到的东西可能会导致某些功能无法正常工作。因此，我们想请您在您的支持请求中也回答以下问题（如果适用）。

• 您正在使用多少台机器/您的 Kubernetes 集群设置是什么？
• 您是否使用配置管理工具（Chef、Puppet）？
• 哪些其他服务与 Travis CI Enterprise 交互？
• 您与 Travis CI Enterprise 一起使用哪个版本控制系统 (VCS)（例如 github.com、GitHub Enterprise 或 BitBucket Cloud）？
• 如果您使用的是 GitHub Enterprise，则使用的是哪个版本？

我们期待着为您提供帮助！