碼上快樂

相關內容    簡體    繁體

升級 GitLab

本文轉載自   查看原文   2022-01-01 13:54   3700    gitlab

升級 GitLab 

所有等級
自我管理

升級 GitLab 是一個相對簡單的過程，但根據您使用的安裝方法、您的 GitLab 版本的舊版本、是否升級到主要版本等，復雜性可能會增加。

請務必閱讀整個頁面，因為它包含與每種升級方法相關的信息。

將 GitLab 升級到最新的可用補丁版本，例如 13.8.8 而不是 13.8.0 . 這包括 您必須在升級路徑上停留的版本 ，因為可能有與升級過程相關的問題的修復程序。

該維修策略文檔 有關於升級，包括額外的信息：

  • 如何解釋 GitLab 產品版本控制。
  • 關於要運行的版本的建議。
  • 我們如何使用補丁和安全補丁版本。
  • 當我們向后移植代碼更改時。

根據安裝方式升級

根據安裝方式和你的 GitLab 版本，官方有多種更新 GitLab 的方式：

Linux 包（綜合 GitLab）

該軟件包升級指南 包含更新官方GitLab倉庫安裝了一個包所需的步驟。

當您想要更新到特定版本時，也有說明 。

從源安裝

過去，我們使用單獨的文檔來進行升級說明，但此后我們轉而使用單個文檔。舊的升級指南仍然可以在 Git 存儲庫中找到：

使用 Docker 安裝

GitLab 為社區版和企業版提供官方 Docker 鏡像。它們基於 Omnibus 包，有關如何更新它們的說明位於單獨的文檔中。

使用 Helm 安裝

GitLab 可以使用 Helm 部署到 Kubernetes 集群中。有關如何更新雲原生部署的說明位於 單獨的文檔中。

使用 從圖表版本到 GitLab 版本的版本映射來確定升級路徑。

計划您的升級

請參閱指南以計划您的 GitLab 升級。

升級前檢查后台遷移

在更新到較新版本之前，某些版本可能需要完成不同的遷移。

批量遷移是 GitLab 14.0 及更高版本中可用的遷移類型。后台遷移和批量遷移不一樣，所以你應該在更新之前檢查兩者是否完整。

通過增加 可以處理隊列中作業的Sidekiq 工作器的數量來減少完成這些遷移所需的時間 background_migration。

后台遷移

對於 Omnibus 安裝：

sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.pending'

對於從源安裝：

cd /home/git/gitlab
sudo -u git -H bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
sudo -u git -H bundle exec rails runner -e production 'puts Gitlab::BackgroundMigration.pending'

批量后台遷移

GitLab 14.0 引入了批量后台遷移。

某些安裝可能需要運行 GitLab 14.0 至少一天才能完成該升級引入的數據庫更改。

檢查批量后台遷移的狀態

要檢查批量后台遷移的狀態：

  1. 在頂部欄上，選擇菜單 > 管理。

  2. 在左側邊欄上，選擇Monitoring > Background Migrations。

    排隊批量后台遷移表

Finished在升級 GitLab 之前，所有遷移都必須具有狀態。

批量后台遷移的狀態也可以直接在數據庫中查詢。

  1. psql根據您的實例安裝方法（例如，sudo gitlab-psql對於 Omnibus 安裝）的說明登錄提示。

  2. 在psql會話中運行以下查詢以查看有關未完成的批處理后台遷移的詳細信息：

    select job_class_name, table_name, column_name, job_arguments from batched_background_migrations where status <> 3;

如果遷移未完成並且您嘗試更新到更高版本，GitLab 會提示您錯誤：

Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':

如果出現此錯誤，請檢查批處理后台遷移選項以完成升級。

如果我的后台遷移卡住了怎么辦？

以下操作可能會破壞您的 GitLab 性能。

重新執行這些命令是安全的，尤其是當您有 1000 多個可能會溢出運行時內存的待處理作業時。

用於綜合安裝

# Start the rails console
sudo gitlab-rails c

# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }

對於從源安裝

# Start the rails console
sudo -u git -H bundle exec rails RAILS_ENV=production

# Execute the following in the rails console
scheduled_queue = Sidekiq::ScheduledSet.new
pending_job_classes = scheduled_queue.select { |job| job["class"] == "BackgroundMigrationWorker" }.map { |job| job["args"].first }.uniq
pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_class) }

批量遷移（GitLab 14.0 及更新版本）：

請參閱對批處理后台遷移進行故障排除。

處理運行 CI/CD 管道和作業

如果在 GitLab Runner 處理作業時升級 GitLab 實例，則跟蹤更新將失敗。當 GitLab 重新上線時，跟蹤更新應該會自我修復。但是，根據錯誤，GitLab Runner 會重試或最終終止作業處理。

至於工件，GitLab Runner 嘗試上傳它們 3 次，之后作業最終失敗。

針對以上兩種情況，建議升級前進行以下操作：

  1. 計划您的維護。
  2. 暫停你的跑步者。
  3. 等待所有作業完成。
  4. 升級 GitLab。

檢查掛起的高級搜索遷移

此部分僅在您啟用了Elasticsearch 集成時適用。

主要版本要求 在主要版本升級之前從當前版本中的最新次要版本完成所有高級搜索遷移。您可以通過運行以下命令來查找掛起的遷移：

用於綜合安裝

sudo gitlab-rake gitlab:elastic:list_pending_migrations

對於從源安裝

cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:elastic:list_pending_migrations

如果我的高級搜索遷移卡住了怎么辦？

了解如何重試暫停的遷移。

無需停機即可升級

閱讀如何在不停機的情況下進行升級。

升級到新的主要版本

升級主要版本需要更多關注。向后不兼容的更改和遷移保留給主要版本。請仔細按照說明進行操作，因為我們無法保證主要版本之間的升級是無縫的。

需要按照以下升級步驟確保主版本升級成功：

  1. 升級到先前主要版本的最新次要版本。
  2. 升級到下一個主要版本 ( X.0.Z)。
  3. 升級到它的第一個次要版本 ( X.1.Z)。
  4. 繼續升級到該主要版本的較新版本。

確定支持的升級路徑。

在升級到新的主要版本之前，確保所有后台遷移都已完全完成也很重要。要查看background_migration隊列的當前大小， 請在升級前檢查后台遷移。

如果您已啟用Elasticsearch 集成，請確保在當前版本中的最后一個次要版本中完成所有高級搜索遷移。 在繼續進行主要版本升級之前，請務必 檢查待處理的高級搜索遷移。

如果您的 GitLab 實例有任何關聯的運行器，升級 GitLab Runner 以匹配升級到的 GitLab 次要版本非常重要。這是為了確保與 GitLab 版本的兼容性。

升級路徑

一次升級跨多個 GitLab 版本只能通過接受停機時間來實現。以下示例假設升級時停機是可以接受的。如果您不想停機，請閱讀如何零停機升級。

找到您的版本在下面的升級路徑中的位置，並相應地升級 GitLab，同時參考 版本特定的升級說明：

8.11.Z-> 8.12.0-> 8.17.7-> 9.5.10-> 10.8.7-> 11.11.8-> 12.0.12-> 12.1.17-> 12.10.14-> 13.0.14-> 13.1.11-> 13.8.8->最新13.12.Z->最新14.0.Z->最新14.1.Z->最新14.Y.Z

下表雖然並非詳盡無遺，但顯示了支持的升級路徑的一些示例。上述版本之間的附加步驟是可能的。我們只列出了最低限度的必要步驟。

目標版本 你的版本 支持的升級路徑 筆記
14.2.6 13.10.2 13.10.2-> 13.12.12-> 14.0.11-> 14.1.8->14.2.6 需要三個中間版本：13.12、14.0、 和14.1，然后14.2.6。
14.1.8 13.9.2 13.9.2-> 13.12.12-> 14.0.11->14.1.8 需要兩個中間版本：13.12和14.0，然后14.1.8。
13.12.10 12.9.2 12.9.2-> 12.10.14-> 13.0.14-> 13.1.11-> 13.8.8->13.12.10 需要四個中間版本：12.10、13.0、13.1和13.8.8，然后13.12.10。
13.2.10 11.5.0 11.5.0-> 11.11.8-> 12.0.12-> 12.1.17-> 12.10.14-> 13.0.14-> 13.1.11->13.2.10 需要六個中間版本：11.11、12.0、12.1、12.10、13.0和13.1，然后13.2.10。
12.10.14 11.3.4 11.3.4-> 11.11.8-> 12.0.12-> 12.1.17->12.10.14 需要三個中間版本：11.11,12.0和12.1, 然后12.10.14。
12.9.5 10.4.5 10.4.5-> 10.8.7-> 11.11.8-> 12.0.12-> 12.1.17->12.9.5 需要四個中間版本：10.8、11.11、12.0和12.1，然后12.9.5。
12.2.5 9.2.6 9.2.6-> 9.5.10-> 10.8.7-> 11.11.8-> 12.0.12-> 12.1.17->12.2.5 需要五個中間版本：9.5, 10.8, 11.11, 12.0, and 12.1, then 12.2.5。
11.3.4 8.13.4 8.13.4-> 8.17.7-> 9.5.10-> 10.8.7->11.3.4 8.17.7是第 8 版的最后一個版本，9.5.10是第 9 版的最后一個版本，10.8.7是第 10 版的最后一個版本。

版本間升級

GitLab有兩個版本：社區版是MIT許可，以及企業版，其基於社區版的頂部，包括額外的功能，主要是針對機構擁有超過100個用戶。

您可以在下面找到一些幫助您更改 GitLab 版本的指南。

社區到企業版

以下指南僅適用於企業版訂閱者。

如果您希望將 GitLab 安裝從社區版升級到企業版，請根據安裝方法按照以下指南進行操作：

  • 源 CE 到 EE 更新指南- 步驟與版本升級非常相似：停止服務器，獲取代碼，更新新功能的配置文件，安裝庫並進行遷移，更新初始化腳本，啟動應用程序並檢查其地位。
  • Omnibus CE 到 EE - 按照本指南將您的 Omnibus GitLab 社區版更新為企業版。

企業到社區版

如果您需要將企業版安裝降級回社區版，您可以按照本指南使該過程盡可能順利。

特定版本升級說明

每個月，GitLab 的主要、次要或補丁版本都會與發布帖子一起 發布。您應該閱讀您傳遞的所有版本的發布帖子。在主要和次要發布帖子的末尾，有三個部分需要專門查找：

  • 棄用
  • 移除
  • 升級的重要注意事項

這些包括：

  • 作為升級的一部分需要執行的步驟。例如8.12 需要重新創建 Elasticsearch 索引。任何舊版本的 GitLab 升級到 8.12 或更高版本都需要這樣做。
  • 對我們支持的軟件版本的更改，例如 在 GitLab 13 中停止支持 IE11。

除了本節中的說明外，您還應該根據您安裝 GitLab 的方式檢查特定於安裝的升級說明：

以下與 Ruby 和 Git 版本相關的特定信息不適用於 Omnibus 安裝  和 Helm Chart 部署 。它們帶有適當的 Ruby 和 Git 版本，並且沒有使用 Ruby 和 Git 的系統二進制文件。使用這兩種方法時無需安裝 Ruby 或 Git。

14.5.0

  • 當make運行時，Gitaly版本是現在創建_build/bin的源目錄的根目錄下，並不再。如果您使用的是源代碼安裝，在你更新到這些二進制文件systemd單元文件 或init腳本由下面的文檔。

  • Workhorse 和 Gitaly 之間的連接backchannel默認使用 Gitaly協議。如果您在 Workhorse 和 Gitaly 之間部署了 gRPC 代理，Workhorse 將無法再連接。作為解決方法，禁用臨時workhorse_use_sidechannel 功能標志。如果您需要 Workhorse 和 Gitaly 之間的代理，請使用 TCP 代理。如果您對此更改有任何反饋，請轉到此問題。

  • 在 14.1 中，我們引入了后台遷移，它改變了我們存儲合並請求差異提交的方式，以顯着減少所需的存儲量。在 14.5 中，我們引入了一組遷移，通過確保merge_request_diff_commits完成表上的所有剩余作業來完成此過程。在大多數情況下，這些作業已經處理完畢，因此在升級到 14.5 期間不需要額外的時間。但如果還有剩余作業，部署可能需要額外幾分鍾才能完成。

    所有合並請求差異提交將自動合並這些更改，並且沒有額外的要求來執行升級。merge_request_diff_commits表中的現有數據保持解包狀態，直到您運行VACUUM FULL merge_request_diff_commits. 但請注意，該VACUUM FULL操作會鎖定並重寫整個merge_request_diff_commits表，因此該操作需要一些時間才能完成，並且會阻止對該表的訪問，直到該過程結束。我們建議您僅在 GitLab 未主動使用或在此過程中脫機時運行此命令。完成所需的時間取決於表的大小，可以使用select pg_size_pretty(pg_total_relation_size('merge_request_diff_commits'));.

    有關更多信息，請參閱此問題。

14.4.0

14.3.0

14.2.0

14.1.0

14.0.0

  • 升級到 GitLab 14.0 所做的數據庫更改可能需要數小時或數天才能在更大的 GitLab 實例上完成。這些批量后台遷移更新整個數據庫表以減輕主鍵溢出，並且必須在升級到 GitLab 14.2 或更高版本之前完成。

  • 由於其中一個問題BatchedBackgroundMigrationWorkers是 不工作 的自我管理的情況下，修復被創造 ，需要更新到至少14.0.5。該修復程序也在14.1.0 中發布。

    更新到 14.0.5 或更高版本的 14.0 補丁版本后， 需要先完成批量后台遷移， 然后才能更新到更高版本。

    如果遷移未完成並且您嘗試更新到更高版本，您將看到如下錯誤：

    Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':

    查看如何解決此錯誤。

  • 在 GitLab 13.3中不推薦使用一些管道處理方法， 並且在 GitLab 14.0 中完全刪除了此代碼。如果您計划從GitLab 13.2 或更早版本直接升級 到 14.0（不受支持），則升級時不應運行任何管道，否則升級完成時管道可能會報告錯誤狀態。您應該改為遵循受支持的升級路徑。

  • 已取消對 PostgreSQL 11 的支持。在更新到 GitLab 14.0 之前，請確保將您的數據庫更新到版本 12。

  • 請參閱GitLab 13.9 到 14.4 中的維護模式問題。

升級到更高版本的 14.Y

13.12.0

請參閱GitLab 13.9 到 14.4 中的維護模式問題。

13.11.0

13.10.0

請參閱GitLab 13.9 到 14.4 中的維護模式問題。

13.9.0

  • 我們檢測到列重命名存在問題，該問題 會阻止在遵循零停機步驟時升級到 GitLab 13.9.0、13.9.1、13.9.2 和 13.9.3。零停機升級需要執行以下附加步驟：

    1. 在sudo gitlab-rake db:migrate部署節點上運行最終命令之前，使用 PostgreSQL 控制台（或sudo gitlab-psql）執行以下查詢以刪除有問題的觸發器：

      drop trigger trigger_e40a6f1858e6 on application_settings;
drop trigger trigger_0d588df444c8 on application_settings;
drop trigger trigger_1572cbc9a15f on application_settings;
drop trigger trigger_22a39c5c25f3 on application_settings;

    2. 運行最后的遷移：

      sudo gitlab-rake db:migrate

    如果您已經sudo gitlab-rake db:migrate在部署節點上運行了最終命令並且遇到了列重命名問題，您會看到以下錯誤：

    -- remove_column(:application_settings, :asset_proxy_whitelist)
rake aborted!
StandardError: An error has occurred, all later migrations canceled:
PG::DependentObjectsStillExist: ERROR: cannot drop column asset_proxy_whitelist of table application_settings because other objects depend on it
DETAIL: trigger trigger_0d588df444c8 on table application_settings depends on column asset_proxy_whitelist of table application_settings

    要解決此錯誤，請按照前面的步驟完成更新。本期提供了更多詳細信息。

  • 請參閱GitLab 13.9 到 14.4 中的維護模式問題。

13.8.8

GitLab 13.8 包括后台遷移以解決重復服務記錄的問題。如果存在重復的服務，則此后台遷移必須在唯一索引應用於服務表之前完成，這是在 GitLab 13.9中引入的。從 GitLab 13.8 及更早版本升級到更高版本必須包括對 GitLab 13.8.8 的中間升級，並且必須等到后台遷移完成才能繼續。

如果仍然存在重復的服務，升級到 13.9.x 或更高版本會導致升級失敗並顯示以下錯誤：

PG::UniqueViolation: ERROR:  could not create unique index "index_services_on_project_id_and_type_unique"
DETAIL:  Key (project_id, type)=(NNN, ServiceName) is duplicated.

13.6.0

需要 Ruby 2.7.2。GitLab 不是從 Ruby 2.6.6 或更舊版本開始的。

所需的 Git 版本是 Git v2.29 或更高版本。

13.4.0

GitLab 13.4.0 包括后台遷移，將遺留存儲中的所有剩余存儲庫移動到散列存儲。此遷移存在已知問題，已在 GitLab 13.5.4 及更高版本中修復。如果可能，請跳過 13.4.0 並升級到 13.5.4 或更高版本。請注意，遷移可能需要很長時間才能運行，具體取決於必須移動的存儲庫數量。在進一步升級之前，請務必檢查所有后台遷移是否已完成。

13.3.0

推薦的 Git 版本是 Git v2.28。Git v2.24 所需的最低版本保持不變。

13.2.0

由於 Rails 中的重大更改可能導致授權問題，因此具有多個 Web 節點的 GitLab 安裝必須先 升級到 13.1，然后才能升級到 13.2（及更高版本）。

GitLab 13.2.0修復了電子郵件驗證繞過。升級后，如果您的某些用戶在登錄時意外遇到 404 或 422 錯誤，或者在使用命令行時出現“被阻止”消息，則他們的帳戶可能未得到確認。在這種情況下，請讓他們查看電子郵件以獲取重新確認鏈接。有關更多信息，請參閱我們對電子郵件確認問題的討論。

GitLab 13.2.0 依賴於btree_gistPostgreSQL的擴展。對於使用外部管理的 PostgreSQL 設置的安裝，如果 GitLab 的數據庫用戶不是超級用戶，請確保 在升級 GitLab 之前手動安裝擴展。這對於使用 GitLab 管理的 PostgreSQL 數據庫的安裝來說不是必需的。

13.1.0

在 13.1.0 中，您必須升級到：

  • 至少 Git v2.24（以前，所需的最低版本是 Git v2.22）。
  • 推薦的 Git v2.26。

由於使用了新的--end-of-optionsGit 標志，否則會導致某些 RPC 中 Gitaly 服務出現內部錯誤。

此外，在 GitLab 13.1.0 中，Rails的版本從 6.0.3 升級到 6.0.3.1。Rails 升級包括對不向后兼容的 CSRF 令牌生成的更改 - 具有新 Rails 版本的 GitLab 服務器生成具有舊 Rails 版本的 GitLab 服務器無法識別的 CSRF 令牌 - 這可能導致非 GET 請求失敗多節點 GitLab 安裝。

因此，如果您使用多個 Rails 服務器並專門從 13.0 升級，則必須先將所有服務器升級到 13.1.Z，然后再升級到 13.2.0 或更高版本：

  1. 確保所有 GitLab Web 節點都運行 GitLab 13.1.Z。

  2. 啟用global_csrf_token功能標志以啟用CSRF令牌生成的新方法：

    Feature.enable(:global_csrf_token)
  3. 只有這樣，才能繼續升級到更高版本的 GitLab。

12.2.0

在 12.2.0 中，我們啟用了 Rails 的經過身份驗證的 cookie 加密。舊會話會自動升級。

但是，不支持會話 cookie 降級。因此，升級到 12.2.0 后，任何降級都會導致所有會話無效並且用戶注銷。

12.1.0

如果您打算從 升級12.0.Z到12.10.Z，則需要在升級12.1.Z前執行中間升級到，12.10.Z以避免出現#215141 之類的問題。

12.0.0

在 12.0.0 中，我們進行了各種與數據庫相關的更改。這些更改要求用戶首先升級到最新的 11.11 補丁版本。升級到 11.11.Z 后，用戶可以升級到 12.0.Z。否則可能會導致無法應用數據庫遷移，從而導致應用程序錯誤。

還需要您升級到 12.0.Z，然后再移動到 12.Y 的更高版本。

示例 1：您當前使用的是 GitLab 11.11.8，這是 11.11.Z 的最新補丁版本。您可以像往常一樣升級到 12.0.Z。

示例 2：您當前使用的是 GitLab 10.Y 版本。要升級，請先升級到最后一個 10.Y 版本 (10.8.7)，然后再升級到最后一個 11.Y 版本 (11.11.8)。升級到 11.11.8 后，您可以安全地升級到 12.0.Z。

有關 更多信息，請參閱我們關於升級路徑的文檔。

GitLab 13.9 到 14.4 中的維護模式問題

當維護模式啟動時，使用者無法與SSO，SAML，或LDAP登錄。

在啟用維護模式之前登錄的用戶將繼續登錄。如果啟用維護模式的管理員丟失了他們的會話，那么他們將無法通過 UI 禁用維護模式。在這種情況下，您可以通過 API 或 Rails 控制台禁用維護模式。

此錯誤已在 GitLab 14.5.0 中修復，預計將向后移植到 GitLab 14.3 和 14.4。

各種各樣的


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 GitLab升級 Gitlab升級記 Gitlab 跨版本升級 gitlab安裝及升級（借鑒官網方法） docker中的gitlab數據備份、遷移和升級 Gitlab 備份 | 恢復 | 卸載 | 遷移 | 版本升級 gitlab安裝升級（大版本跨度9.4.5----13.2.1） gitlab-ce12.x升級13.x路線 gitlab安裝升級（大版本跨度9.4.5----13.2.1） Gitlab+Jenkins學習之路（六）之Jenkins部署、升級和備份
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM