备份和还原极狐GitLab 实例
极狐GitLab Helm chart 通过 Toolbox 子 chart 提供公用 pod,用作备份和还原实例的接口。该 pod 配备一个 backup-utility
可执行文件,可与其它必要使用的 pod 进行交互。有关技术细节,请查看 架构文档。
前提条件
-
本文描述的备份和还原过程仅使用 S3 兼容 API 测试过。对其它对象存储服务的支持,例如 Google Cloud Storage,将在未来的修订版中进行测试。
-
在还原期间,备份的原始数据需要解压到磁盘。这意味着 Toolbox pod 应有必要可用大小的磁盘。
-
chart 依赖于利用对象存储,保存
artifacts
、uploads
、packages
、registry
和lfs
对象,在还原期间不会迁移。如果您正在还原一个其它实例的备份,您必须在备份之前使用对象存储,迁移现有实例。
备份和还原过程
对象存储
使用 chart 时,我们提供了开箱即用的 MinIO 实例,除非指定了外部对象存储。Task Runner 默认连接到 MinIO,除非进行特别设置。Toolbox 也可以配置为备份到 Amazon S3 或 Google Cloud Storage (GCS)。
备份到 S3
Toolbox 使用 s3cmd
连接到对象存储。为了配置与外部对象存储的连接,应指定 gitlab.toolbox.backups.objectStorage.config.secret
,指向包含 .s3cfg
文件的 Kubernetes Secret。当和 config
的默认值不同时,应当指定 gitlab.toolbox.backups.objectStorage.config.key
,指向包含 .s3cfg
文件内容的键。
举例如下:
helm install gitlab gitlab-jh/gitlab \
--set gitlab.toolbox.backups.objectStorage.config.secret=my-s3cfg \
--set gitlab.toolbox.backups.objectStorage.config.key=config .
获取关于 s3cmd .s3cfg
文件的信息,请查看文档。
此外,需要配置两个 bucket location,一个用于存储备份,另一个在还原备份时作为临时 bucket。
--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage
备份到 Google Cloud Storage (GCS)
要备份到 GCS,您必须设置 gitlab.toolbox.backups.objectStorage.backend
为 gcs
。这样确保 Toolbox 在存储和检索对象时使用 gsutil
CLI。此外您必须将 gitlab.toolbox.backups.objectStorage.config.gcpProject
设置为 GCP 项目的 project ID,GCP 项目应包含您的存储桶。
您必须使用有效 service account JSON 密钥的内容创建 Kubernetes secret,service account 对用于备份的存储桶,应具有 storage.admin
角色。下面时使用 gcloud
和 kubectl
创建 secret 的示例。
export PROJECT_ID=$(gcloud config get-value project)
gcloud iam service-accounts create gitlab-gcs --display-name "Gitlab Cloud Storage"
gcloud projects add-iam-policy-binding --role roles/storage.admin ${PROJECT_ID} --member=serviceAccount:gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com
gcloud iam service-accounts keys create --iam-account gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com storage.config
kubectl create secret generic storage-config --from-file=config=storage.config
参考下面的示例,配置您的 Helm chart,使用 service account 密钥对用于备份的 GCS 进行认证。
helm install gitlab gitlab-jh/gitlab \
--set gitlab.toolbox.backups.objectStorage.config.secret=storage-config \
--set gitlab.toolbox.backups.objectStorage.config.key=config \
--set gitlab.toolbox.backups.objectStorage.config.gcpProject=my-gcp-project-id \
--set gitlab.toolbox.backups.objectStorage.backend=gcs
此外,需要配置两个 bucket location,一个用于存储备份,另一个在还原备份时作为临时 bucket。
--set global.appConfig.backups.bucket=gitlab-backup-storage
--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage
故障排查
Pod 驱逐问题
由于备份是在本地生成,在对象存储目标之外,因此需要临时磁盘空间,所需空间可能会超过实际备份存档的大小。默认配置将使用 Toolbox pod 的文件系统存储临时数据。如果您发现 pod 由于资源不足被驱逐,您需要挂载一个持久卷到 pod 上,以保持临时数据。在 GKE 上,在您的 Helm 命令中添加以下设置:
--set gitlab.toolbox.persistence.enabled=true
如果您的备份作为包含备份的 cron job 的一部分运行,那么您还需要为 cron job 启用持久性:
--set gitlab.toolbox.backups.cron.persistence.enabled=true
对于其它云提供商,您可能需要创建持久卷。查看 存储文档,参考可能适用的案例。
“Bucket not found” 错误
如果在备份时发现 Bucket not found
错误,检查为您的存储桶配置的凭证。
使用的命令取决于云服务提供商:
-
对于 AWS S3, 凭证存储在 toolbox pod 的
~/.s3cfg
中。执行以下命令:s3cmd ls
-
对于 GCP GCS,执行以下命令:
gsutil ls
您可以看到可用的存储桶列表。
GCP 中的 “AccessDeniedException: 403” 错误
类似 [Error] AccessDeniedException: 403 <GCP Account> does not have storage.objects.list access to the Google Cloud Storage bucket.
的错误通常由于缺少权限,发生在备份或还原极狐GitLab 实例的过程中。
备份和还原操作使用环境中的所有存储桶,因此需要确认所有环境中的存储桶都已创建,并且 GCP 帐户可以访问(list、read 和 write)所有存储桶:
-
找到您的 toolbox pod:
kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
-
获取 pod 环境中的所有存储桶。将
<toolbox-pod-name>
替换为实际的 task-runner pod 名称,但不要替换"BUCKET_NAME"
,将其原地保留:kubectl describe pod <toolbox-pod-name> | grep "BUCKET_NAME"
-
确认您具有访问环境中的每个存储桶的权限:
# List gsutil ls gs://<bucket-to-validate>/ # Read gsutil cp gs://<bucket-to-validate>/<object-to-get> <save-to-location> # Write gsutil cp -n <local-file> gs://<bucket-to-validate>/