注意：這是一個較進階的主題，關於邊緣遞送服務& 文件撰寫。如需EDS& Document Authoring 的介紹，請先查看此處以瞭解相關內容。

檔案型 AEM 邊緣傳送組態的背景& 組態服務

當 Adobe 首次推出 Edge Delivery Services（或稱為 Helix，內部稱之為 Helix）時，所有主要的全站設定都是使用檢查到網站儲存庫的設定檔來完成。部署新組態的方式是推送到套件庫的main 分支，該分支會將該組態推送到網站上。這樣做的缺點是，任何指定的儲存庫都必須直接與網站和文件儲存庫連結。這樣您就無法使用單一程式碼儲存庫來驅動多個網站 - 甚至是單一網站的多個版本 (例如dev/stg/prd 式的內容或設定暫存環境)。

由於這個原因，以及其他技術上的考量，Adobe 已經轉向以Configuration Service 為核心的新架構設計。在這個範例中，Adobe 會在其 API 驅動的 Configuration Service 中集中儲存和版本化組態，一旦遷移到這項服務，您 Edge Delivery 專案中的檔案將不會再對網站有任何影響。

移轉至組態服務的先決條件

如https://www.aem.live/docs/config-service-setup#prerequisites 上所述，在您開始轉移到 Config Service 之前，您需要先確保您的 Adobe 使用者映射為 Github org 的管理員，這樣您才有權限在 Config Service 中進行變更。通常與您打交道的 Adobe 技術聯絡人應該可以幫您連上此功能。

端點& 受移至組態服務影響的組態表面

這會影響 Edge Delivery 專案中的下列設定面：

• 內容匯流排映射：/fstab.yaml 中的組態，專案映射到 DA 中的位置（或其他地方，如 AEM/Universal Editor 或 Sharepoint），現在是在 Config Service 中。這是最關鍵的一點，它允許單一 repo 驅動多個網站（以前稱為"無 repoless" 設定，因為它意味著程式碼 repo 和內容 repo 沒有千絲萬縷的聯繫）。

• 查詢索引：所有語言的索引設定先前儲存在專案中的 /helix-query.yaml

• 網站地圖設定：以前在/helix-sitemap.yaml 中進行的網站地圖設定現在會在 Config Service 中進行。

• Sidekick 配置：有兩種不同類型的 Sidekick 配置，以前保存在 git 專案中，現在則在其他地方。

  • DA 外掛程式：以前，在 DA 的早期，我們把 DA 外掛程式放在程式碼 repo 的/tools/sidekick/config.json 檔案中。這將用於各種 DA UI 增強功能，例如我們的日期選擇器、AEM 標籤外掛程式等。這現在保留在 DA 本身的 DA config 中的Library sheet，而不是在 codebase 中。
  • Sidekick 外掛程式/設定：其他 AEM Sidekick 設定，例如 Quick Edit 或 AEM Experimentation 的設定，現在直接保留在 config 服務中，而非 DA 中。EDS git 專案中的 Sidekick 配置不再會有任何影響。

• HTTP 標頭組態：這以前保留在headers 的 DA 表單中，但現在會推送到 config 服務中。這是用於 CORS 設定，例如在某些主機上貼上access-control-allow-origin 標頭。

• Helix 預覽/發佈驗證：對於已驗證的預覽／發佈存取控制，我們一直使用以工作表為基礎的驗證模型，您會在https://da.live/sheet#/[orgname]/[sitename]/.helix/config 中擁有data 工作表，我們會在其中列出個別 Adobe 實體 ID 的admin.role.author 或admin.role.publish 角色，這些角色會對應到使用者／檔案。現在 Config Service 廢除了這個功能，直接在 Config Service 中針對這些預覽／發佈角色管理使用者，而且也針對存取請求管理使用者。此外，之前的驗證式發佈要求您使用難以辨識的 Adobe 設定檔/使用者 ID，例如"[email protected]" ，該 ID 會對應到使用者登入的特定 org。現在在 Config Service 中，Helix 將會讓您使用電子郵件地址，而不是無法使用的實體 ID，甚至還會允許使用者在遇到預覽/發佈問題時，"請求存取" ，然後浮出水面到 DA 中的管理介面應用程式，以批准/拒絕存取請求。

• Robots.txt 配置：這以前是保存在 git 專案中的/robots.txt ，但現在是在 Config Service 中設定。

• CDN 設定：此設定先前保留在 DA 的.helix/config 表單中，但現在已推入 Config Service。這將用於設定類似的值：

  • cdn.prod.host
  • cdn.prod.type
  • cdn.prod.serviceId
  • cdn.prod.authToken

將現有的檔案型邊界傳送站台移轉至組態服務的步驟

AEM Admin (Helix) API中有一個migrate 指令，可讓您自動將基於檔案的 Edge Delivery 設定轉移到 Config Service。不過也有一些注意事項，以下是需要了解的事項。

首先，假設您有一個使用檔案式組態在 DA 上建立的現有網站 (我知道我有幾個這樣的網站，我可能是少數，但這是我的部落格文章 - 您會想要重新評估您自己使用個案的步驟)。

步驟：

1. 確保您是您的組織的管理員：如上所述，請與 Adobe 合作，確保您的 Github org 上有admin 。請前往https://tools.aem.live/tools/site-admin/index.html ，然後登入以驗證。如果運作正常，您應該會看到一個成功的 200 請求，內容為 https://admin.hlx.page/config/[orgname]/sites.json

2. 取得您的認證標記：執行 shift+ctrl+I 或 shift+cmd+I 來彈出開發者工具，並查看上述sites.json 請求。如果您開啟網路索引標籤，並查看標頭，您會看到x-auth-token 值。複製該值，因為這是您在下列 API 請求中與 AEM Configuration Service 互動時需要使用的承載令牌。

3. 複製您的網站：在您的網站上進行測試運行是個好主意（使用基於檔案的配置的網站），這樣您就可以在 prod 上運行之前測試此過程。建立一個新的 EDS repo& 網站，並使用與您目前網站相同的程式碼庫（如果您還沒有開發 repo 的話）。理想的情況是，您也可以填充一個開發內容來源，這樣您就有一個全副武裝且可運作的沙盒可以亂來。

4. 執行 Migrate Command Dry-Run： 執行下列指令，以執行從檔案型服務遷移至組態服務的試運行：
   
   curl --request GET --url 'https://admin.hlx.page/config/{my-org}/sites/{my-site}.json?migrate=true&validate=true' -H "Authorization: token $MY_AUTH_TOKEN_NOTED_ABOVE"
   
   如果成功執行，它會吐出下列驗證文字，告訴您是否能成功移轉。就我而言，這表示我還未準備好進行移轉，而且還有一些事情需要修正：
   
   "error": "validation failed.", "message": "/sidekick/plugins/0/environments/0 must be equal to one of the allowed values; /sidekick/plugins/2/environments/0 must be equal to one of the allowed values",
   
   另外，如果您在調用時收到 400 bad request，您也可以使用 HTTP 回應中的x-error 標頭，它也會告訴您在 migrate dry-run 請求中的任何問題：

   

   在這種情況下，錯誤會告訴我，在我的 AEM Sidekick 外掛程式清單中，/tools/sidekick/config.json 的第一個外掛程式無效，因為 Config Service 已不再支援以這種方式設定外掛程式。在這個範例中，我需要將這個外掛程式移植到 DA 外掛程式的 DA Library 表單中。

   

5. 如上所述，修正任何驗證問題：您需要檢查並修復任何出現的問題，然後再重新執行驗證請求。
   
   將專案中定義為 Sidekick 外掛程式的任何現有外掛程式，放入 DA 中。如果是 Sidekick 外掛程式的類似問題，DA 外掛程式反而會在https://da.live/config#/[orgname]/[sitename]/ 的工作表"library" 標籤中設定。

   

   或其他類似的問題：

   

   這表示我們的標頭中有一些不再受支援的非法屬性（或許從來就不受支援，只是沒有破壞任何東西，所以被錯誤地留在裡面）。
   
   一旦這些問題都處理好了，您就可以執行遷移本身了。

6. 將& 已驗證的完整設定推送/移轉至 config 服務：要推送設定，請使用下列指令：
   
   curl --request POST --url 'https://admin.hlx.page/config/{my-org}/sites/{my-site}.json?migrate=true' -H "Authorization: token $MY_AUTH_TOKEN_NOTED_ABOVE"
   
   基本上與上述命令相同，但使用POST 取代GET 。這會將您遷移至組態服務。

7. 驗證：移轉後，有幾件事需要立即驗證。

   1. 驗證索引：移至https://tools.aem.live/tools/index-admin/index.html 並驗證您的索引是否已正確拉入
   2. 驗證網站地圖：前往https://tools.aem.live/tools/sitemap-admin/index.html 並驗證所有網站映射都已通過
   3. 驗證使用者：前往https://tools.aem.live/tools/user-admin/index.html?org={orgname}&site={sitename} ，確認您的預覽/發佈使用者顯示在那裡。
   4. 在 DA 中驗證使用者：移至https://da.live/apps/aem-permissions#/{orgname}/{sitename} ，這會讓您看到使用者友善的預覽/發佈權限清單，因為這些權限會暴露在 DA 中。這也是您現在能夠
   5. 驗證預覽/發佈：以具有預覽/發佈權限的使用者登入時，請確認您仍具有適當的預覽/發佈能力。找一個沒有預覽或發佈權限的使用者，並確保它被適當地鎖定。
   6. 任何您認為網站需要的其他驗證。

8. 燒入：QA& 與團隊燒入，修正任何其他預覽/發佈時出現的問題，並讓新組態燒入至少一週，以清除任何其他可能出現的問題。

9. 清理組態檔案：一旦燒錄完成，您將不再需要您的 in-repo 配置，您可以開始逐一刪除這些配置。我建議您將現有設定的完整複本持久化到 git 以進行版本管理，以防萬一有人提出錯誤的 API 請求，而無論什麼原因都無法撤銷。

組態服務的 CI/CD 影響注意事項

關於 CI/CD 的注意事項：現在您擁有 API 驅動的設定服務的固有彈性，但也有一個缺點，就是您的 git 驅動 CI/CD 不再有任何作用。

好消息是有一些工具，例如版本管理員，可以追蹤組態變更和誰做了什麼變更：

壞消息是，這會移除內建的、以拉取請求為中心的 CI/CD 架構，我們都已經熟悉 Edge Delivery，並對它愛不釋手。因此，如果您需要初級工程師提出變更建議，要他們向您提出拉取請求，證明他們的組態變更可以安全地向前滾動，就顯得更加困難。

API 的授權是基於您目前登入的使用者，這使得在 CI/CD 管線中整合一組持久性的金鑰時會有一點阻力。我相信這是可以做到的，只是需要一些修補。

因此，對於這一點（在撰寫本文時），您需要針對組織的規模和組成，滾動您自己覺得合適的 CI/CD 流程。

希望這能對您有所幫助，如果您有任何問題，請寫信給我們！

關於作者

喜歡你聽到的嗎？對適合您的產品有疑問？我們很樂意與您討論！聯絡我們

您可能喜歡的更多文章