

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 從 Chef Server 遷移至 OpsWorks Stacks
<a name="best-practices-server-migrate"></a>

**重要**  
 AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援 團隊。

由於 OpsWorks Stacks 是以 Chef 為基礎，因此從 Chef Server 遷移到 OpsWorks Stacks 相當簡單。本主題提供修改 Chef Server 程式碼以使用 OpsWorks Stacks 的準則。

**注意**  
我們不建議遷移至使用早於 Chef 11.10 版本的堆疊，因為這類版本是以 chef-solo 做為基礎，不支援搜尋或資料包。

**Topics**
+ [將角色映射至 Layer](#best-practices-server-migrate-roles)
+ [使用資料包](#best-practices-server-migrate-data-bags)
+ [使用 Chef 搜尋](#best-practices-server-migrate-search)
+ [管理技術指南和配方](#best-practices-server-migrate-cookbooks)
+ [使用 Chef 環境](#best-practices-server-migrate-environments)

## 將角色映射至 Layer
<a name="best-practices-server-migrate-roles"></a>

Chef Server 使用角色代表及管理具有相同用途和組態的執行個體，例如一組執行個體，其中每個執行個體都主控一個 Java 應用程式伺服器。基本上，[OpsWorks Stacks layer](workinglayers.md) 的用途與 Chef 的角色相同。layer 是建立一組具有相同組態、已安裝套件、應用程式部署程序等 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體的藍圖。

OpsWorks Stacks 包含一組適用於多種應用程式伺服器的[內建層](workinglayers.md)、HAProxy 負載平衡器、MySQL 資料庫主伺服器和 Ganglia 監控主伺服器。例如，內建 [Java App Server](layers-java.md) layer 是建立託管 Tomcat 伺服器的執行個體的藍圖。

若要遷移至 OpsWorks Stacks，您需要將每個角色與提供同等功能的 layer 建立關聯。針對某些角色，您可能可以直接使用其中一個內建 layer。其他角色則可能需要不同程度的自訂。從檢查內建 layer 的功能開始 (包含與每個 layer 關聯的配方) 以查看是否有 layer 至少能提供角色的一部分功能。如需內建 layer 的詳細資訊，請參閱 [層](workinglayers.md) 及 [OpsWorks Stacks Layer 參考](layers.md)。若要檢查內建配方，請參閱 [OpsWorks Stacks 公有 GitHub 儲存庫](https://github.com/aws/opsworks-cookbooks)。

接下來您繼續的方式會根據您將 layer 對應到每個角色的程度而有所不同，如下所示。

**內建 layer 支援角色所有的功能**  
您可以直接使用內建 layer，並且僅需要進行微幅的自訂 (若需要的話)。例如，如果角色支援 Tomcat 伺服器，Java App Server layer 的配方可能已經處理角色的所有任務，可能有一些適度的自訂。例如，您可以透過覆寫適當的[屬性](workingcookbook-attributes.md)或[範本](workingcookbook-template-override.md)，讓 layer 的內建配方使用自訂 Tomcat 或 Apache 組態設定。

**內建 layer 支援角色的部分 (並非全部) 功能**  
您可能可以[將 layer 延伸](workingcookbook-extend.md)來使用內建 layer。這通常會涉及實作自訂配方，以支援沒有的功能，以及將配方指派給 layer 的生命週期事件。例如，假設您的角色在與主控 Tomcat 伺服器相同的執行個體上安裝 Redis 伺服器。您可以擴展 Java App Server layer 以符合角色的功能，方法是實作自訂配方以在 layer 的執行個體上安裝 Redis，並將配方指派給 layer 的設定事件。

**沒有任何內建 layer 能適當支援角色的功能**  
實作自訂 layer。例如，假設您的角色支援 MongoDB 資料庫伺服器，但任何內建的 layer 皆不支援該資料庫伺服器。您可以透過實作配方，安裝必要套件、設定伺服器等，並將配方指派給自訂 layer 的生命週期事件，來提供該支援。通常，針對此目的，您至少可以使用角色一部分的配方。如需如何實作自訂 layer 的詳細資訊，請參閱[建立自訂 Tomcat 伺服器 Layer](create-custom.md)。

## 使用資料包
<a name="best-practices-server-migrate-data-bags"></a>

Chef Server 允許您使用資料包將使用者定義的資料傳遞給您的配方。
+ 您會使用您的技術指南存放您的資料，Chef 會在每個執行個體上安裝它。
+ 您可以針對敏感性資料 (例如密碼) 使用加密資料包。

 OpsWorks Stacks 支援資料包；配方可以使用與 Chef Server 完全相同的程式碼來擷取資料。但是，支援具有下列限制和差異：
+ 僅 Chef 11.10 Linux 及更新版本的堆疊支援資料包。

  Windows 堆疊和執行更早版本的 Linux 堆疊不支援資料包。
+ 您不會將資料包存放在您的技術指南儲存庫。

  相反的，您使用自訂 JSON 管理您資料包的資料。
+ OpsWorks Stacks 不支援加密的資料包。

  若您需要以加密的形式存放敏感性資料 (例如密碼或憑證)，我們建議您將其存放在私有 S3 儲存貯體。然後，您可以建立自訂配方，定義其使用[適用於 Ruby 的 Amazon 開發套件](https://aws.amazon.com/documentation/sdk-for-ruby/)擷取資料。如需範例，請參閱 [使用適用於 Ruby 的 SDK](cookbooks-101-opsworks-s3.md)。

如需詳細資訊，請參閱[使用資料包](workingcookbook-chef11-10.md#workingcookbook-chef11-10-databag)。

## 使用 Chef 搜尋
<a name="best-practices-server-migrate-search"></a>

Chef Server 會將堆疊組態資訊 (例如 IP 地址和角色組態) 存放在伺服器上。配方使用 Chef 搜尋來擷取此資料。 OpsWorks Stacks 使用稍微不同的方法。例如，Chef 11.10 Linux 堆疊是基於 Chef 用戶端的本機模式，即一種在執行個體上本機執行輕量版本 Chef Server (通常稱為 Chef Zero) 的 Chef 用戶端選項。Chef Zero 支援針對存放在執行個體節點物件中的資料進行搜尋。

 OpsWorks Stacks 不會將堆疊資料儲存在遠端伺服器上，而是為每個生命週期事件將一組[堆疊組態和部署屬性](workingcookbook-json.md)新增至每個執行個體的節點物件。這些屬性代表堆疊組態的快照。他們使用與 Chef Server 相同的語法，代表配方需要用來從伺服器擷取的大多數資料。

您通常不需要修改配方的 Stacks OpsWorks 搜尋相依程式碼。由於 Chef 搜尋會在包含堆疊組態和部署屬性的節點物件上運作，因此 Stacks OpsWorks 中的搜尋查詢通常會像使用 Chef Server 一樣運作。

主要例外是因為堆疊組態和部署屬性只包含 OpsWorks Stacks 在執行個體上安裝屬性時所知道的資料。如果您在本機在特定執行個體上建立或修改屬性，這些變更不會傳播回 OpsWorks Stacks，也不會納入其他執行個體上安裝的堆疊組態和部署屬性。您可以使用搜尋來僅擷取該執行個體上的屬性值。如需詳細資訊，請參閱[使用 Chef 搜尋](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search)。

為了與 Chef Server 的相容性， OpsWorks Stacks 會將一組`role`屬性新增至節點物件，每個屬性都包含堆疊的其中一個 layer 屬性。若您的配方使用 `roles` 做為搜尋鍵，您不需要變更搜尋程式碼。查詢會自動傳回對應 layer 的資料。例如，以下兩個查詢都會傳回 `php-app` layer 的屬性。

```
phpserver = search(:node, "layers:php-app").first
```

```
phpserver = search(:node, "roles:php-app").first
```

## 管理技術指南和配方
<a name="best-practices-server-migrate-cookbooks"></a>

OpsWorks Stacks 和 Chef Server 處理技術指南和配方的方式有些不同。Chef Server：
+ 無論是自行實作，還是使用社群技術指南，您會提供所有的技術指南。
+ 您會將技術指南存放在伺服器上。
+ 您可以手動執行技術指南，或是根據定期排程執行。

使用 OpsWorks Stacks：
+ OpsWorks Stacks 為每個內建層提供一或多個技術指南。這些技術指南會處理標準任務，例如安裝和設定內建 layer 的軟體和部署應用程式。

  若要處理並未由內建技術指南執行的任務，您會將自訂技術指南新增至您的堆疊，或是使用社群技術指南。
+ 您可以將 OpsWorks Stacks 技術指南存放在遠端儲存庫中，例如 S3 儲存貯體或 Git 儲存庫。

  如需詳細資訊，請參閱[存放技術指南](#best-practices-server-migrate-cookbooks-store)。
+ 您可以[手動執行配方](workingcookbook-manual.md)，但通常讓 OpsWorks Stacks 為您執行配方，以回應在執行個體生命週期期間關鍵點發生的一組[生命週期事件](workingcookbook-events.md)。

  如需詳細資訊，請參閱[執行配方](#best-practices-server-migrate-cookbooks-execute)。
+ OpsWorks Stacks 僅支援 Chef 11.10 堆疊上的 Berkshelf。若您使用 Berkshelf 管理您的技術指南依存性，您無法使用執行 Chef 11.4 或更早版本的堆疊。

  如需詳細資訊，請參閱[使用 Berkshelf](workingcookbook-chef11-10.md#workingcookbook-chef11-10-berkshelf)。

**Topics**
+ [存放技術指南](#best-practices-server-migrate-cookbooks-store)
+ [執行配方](#best-practices-server-migrate-cookbooks-execute)

### 存放技術指南
<a name="best-practices-server-migrate-cookbooks-store"></a>

使用 Chef Server 時，您會將您的技術指南存放在伺服器上，並將他們從伺服器部署到執行個體。使用 OpsWorks Stacks，您可以將技術指南存放在儲存庫中：S3 或 HTTP 封存或 Git 或 Subversion 儲存庫。您可以指定[安裝技術指南](workingapps-creating.md)時 OpsWorks ，Stacks 從儲存庫下載程式碼到堆疊執行個體所需的資訊。

若要從 Chef Server 進行遷移，您必須將您的技術指南放在這些儲存庫中的其中一個。如需如何建構技術指南儲存庫的資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。

### 執行配方
<a name="best-practices-server-migrate-cookbooks-execute"></a>

在 OpsWorks Stacks 中，每個 layer 都有一組[生命週期事件](workingcookbook-events.md)：設定、設定、部署、取消部署和關機，這些事件都會在執行個體生命週期期間的關鍵點發生。若要執行自訂配方，您通常會將它指定給適當 layer 上的適當事件。當事件發生時， OpsWorks Stacks 便會執行關聯的配方。例如，安裝事件會在執行個體完成開機之後發生，因此您通常會將執行像是安裝和設定套件，以及啟動服務等任務的配方指派給此事件。

您可以透過使用[執行配方堆疊命令](workingstacks-commands.md)手動執行配方。此命令在開發和測試期間非常有用，但您也可以用它來執行不會映射到生命週期事件的配方。您也可以使用執行配方命令手動觸發安裝和設定事件。

除了 OpsWorks Stacks 主控台之外，您還可以使用 [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) 或 [SDKs](https://aws.amazon.com/tools/) 來執行配方。這些工具支援所有 [OpsWorks Stacks API 動作](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)，但通常會比使用 API 更簡單。使用 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) CLI 命令觸發生命週期事件，執行所有關聯配方。您也可以使用此命令來執行一或多個配方，而不觸發事件。對等的軟體開發套件程式碼依存於特定語言，但通常與 CLI 命令相似。

以下範例說明使用 `create-deployment` CLI 命令自動化應用程式部署的兩種方式。
+ 透過將具有單一執行個體的自訂 layer 新增至您的堆疊，來根據定期排程部署您的應用程式。

  將自訂安裝配方新增至在執行個體上建立 `cron` 任務的 layer，以根據指定的排程執行命令。如需如何使用配方來建立 `cron` 任務的範例，請參閱[在 Linux 執行個體上執行 Cron 任務](workingcookbook-extend-cron.md)。
+ 將任務新增至您使用 `create-deployment` CLI 命令部署應用程式的連續整合管道。

## 使用 Chef 環境
<a name="best-practices-server-migrate-environments"></a>

OpsWorks Stacks 不支援 Chef 環境；`node.chef_environment`一律傳回 `_default`。