本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # OpsWorks 堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。雲端運算通常涉及 AWS 資源群組，例如 Amazon EC2 執行個體和 Amazon Relational Database Service (RDS) 執行個體，這些資源必須共同建立和管理。例如，web 應用程式通常需要應用程式伺服器、資料庫伺服器、負載平衡器等。這個執行個體群組通常稱為「堆疊」**。一個簡易的應用程式伺服器堆疊看起來可能會如下。 ![\[Diagram showing users connecting to app servers through internet and load balancer, with a shared database.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch.png) 除了建立執行個體和安裝必要的套件之外，您通常需要一種將應用程式分佈到應用程式伺服器、監控堆疊效能、管理安全及許可等的方式。 OpsWorks Stacks 提供簡單且靈活的方法來建立和管理堆疊和應用程式。以下是基本應用程式伺服器堆疊在 Stacks OpsWorks 中的外觀。它包含一組在 Elastic Load Balancing 負載平衡器後方執行的應用程式伺服器，以及後端 Amazon RDS 資料庫伺服器。 ![\[OpsWorks Stack architecture with load balancer, application servers, and Amazon RDS instance.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch_4.png) 雖然相對簡單，但此堆疊會顯示所有關鍵的 OpsWorks Stacks 功能。以下是它構成的方式。 **Topics** + [堆疊](#welcome-classic-stacks) + [層](#welcome-classic-layers) + [配方和生命週期 (LifeCycle) 事件](#welcome-classic-lifecycle) + [執行個體](#welcome-classic-instances) + [應用程式](#welcome-classic-apps) + [自訂您的 Stack](#welcome-classic-customizing) + [資源管理](#welcome-classic-resources) + [安全與許可](#welcome-classic-security) + [監控和記錄](#welcome-classic-monitoring) + [CLI、軟體開發套件和 CloudFormation 範本](#welcome-classic-sdk) + [AWS OpsWorks Stacks 生命週期結束FAQs](stacks-eol-faqs.md) + [將您的 AWS OpsWorks Stacks 應用程式遷移至 AWS Systems Manager Application Manager](migrating-to-systems-manager.md) + [使用就地 AWS OpsWorks Stacks 分離工具](using-stacks-detach-tool.md) + [Stacks OpsWorks 入門](gettingstarted_intro.md) + [OpsWorks Stacks 最佳實務](best-practices.md) + [堆疊](workingstacks.md) + [層](workinglayers.md) + [執行個體](workinginstances.md) + [應用程式](workingapps.md) + [技術指南和配方](workingcookbook.md) + [資源管理](resources.md) + [Tags (標籤)](tagging.md) + [監控](monitoring.md) + [安全與許可](workingsecurity.md) + [OpsWorks Chef 12 Linux 的 Stacks 支援](chef-12-linux.md) + [在 Stacks 中支援先前的 Chef OpsWorks 版本](previous-chef-versions.md) + [將 OpsWorks Stacks 與其他 AWS 服務搭配使用](other-services.md) + [使用 OpsWorks Stacks CLI](cli-examples.md) + [偵錯和故障診斷指南](troubleshoot.md) + [OpsWorks Stacks 代理程式 CLI](agent.md) + [OpsWorks Stacks 資料包參考](data-bags.md) + [OpsWorks 代理程式變更](agentchanges.md) ## 堆疊 *堆疊*是核心 OpsWorks Stacks 元件。它基本上是適用於 AWS 資源的容器，例如 Amazon EC2 執行個體、Amazon RDS 資料庫執行個體等，這些資源具有共同目的，並且應該一起邏輯管理。堆疊可協助您將這些資源做為群組管理，也可以讓您定義一些預設組態設定，例如執行個體的作業系統和 AWS 區域。若您希望隔離一些堆疊元件，避免與使用者直接互動，您可以在 VPC 中執行堆疊。 ## 層您可以藉由新增一或多個 *layer* 來定義堆疊的組成內容。layer 代表一組提供特定用途的 Amazon EC2 執行個體，例如服務應用程式或託管資料庫伺服器。您可以透過修改套件的預設組態，新增 Chef 配方以執行像是安裝額外套件等的任務，來自訂或延伸 layer。對於所有堆疊， OpsWorks Stacks 包含*服務層*，代表下列 AWS 服務。 + Amazon Relational Database Service + Elastic Load Balancing + Amazon Elastic Container Service Layer 可讓您完全控制要安裝的套件、其設定的方式、部署應用程式的方式等。 ## 配方和生命週期 (LifeCycle) 事件 Layer 會根據 [Chef 配方](http://docs.chef.io/recipes.html)處理像是在執行個體上安裝套件、部署應用程式、執行指令碼等任務。Stacks OpsWorks 的其中一個主要功能是一組*生命週期事件*：設定、設定、部署、取消部署和關機，這些事件會在每個執行個體的適當時間自動執行一組指定的配方。每一 layer 都可以為每個生命週期事件指派一組配方，處理該事件和 layer 的各種任務。例如，在屬於 Web 伺服器層的執行個體完成開機後， OpsWorks Stacks 會執行下列動作。 1. 執行 layer 的安裝配方，執行像是安裝和設定 web 伺服器等的任務。 1. 執行 layer 的部署配方，將 layer 的應用程式從儲存庫部署到執行個體，並執行相關任務 (例如重新啟動服務)。 1. 在堆疊中的每個執行個體上執行設定配方，使每個執行個體可視需要調整自身的組態，以適應新的執行個體。例如，在執行負載平衡器的執行個體上，設定配方可能會修改負載平衡器的組態，以包含新的執行個體。如果執行個體屬於多個 layer， OpsWorks Stacks 會為每個 layer 執行配方，例如，您可以擁有支援 PHP 應用程式伺服器和 MySQL 資料庫伺服器的執行個體。如果您已實作配方，您可以將每個配方指派給適當的 layer 和事件，而 OpsWorks Stacks 會在適當的時間自動為您執行這些配方。您也可以隨時手動執行配方。 ## 執行個體 *執行個體*代表單一運算資源，例如 Amazon EC2 執行個體。它定義了資源的基本組態，例如作業系統和大小。其他組態設定，例如彈性 IP 地址或 Amazon EBS 磁碟區，是由執行個體的 layer 所定義。layer 的配方會透過執行像是安裝和設定套件及部署應用程式等任務，來完成組態。您可以使用 OpsWorks Stacks 建立執行個體並將其新增至 layer。當您啟動執行個體時， OpsWorks Stacks 會使用執行個體及其 layer 指定的組態設定來啟動 Amazon EC2 執行個體。Amazon EC2 執行個體完成開機後， OpsWorks Stacks 會安裝代理程式，處理執行個體與服務之間的通訊，並執行適當的配方以回應生命週期事件。 OpsWorks Stacks 支援下列執行個體類型，其特性在於它們的啟動和停止方式。 + **全年無休執行個體**為手動啟動，並會持續執行到您停止他們。 + **時間型執行個體**由 OpsWorks Stacks 依指定的每日和每週排程執行。他們可讓您的堆疊自動調整執行個體的數目，以適應可預測的用量模式。 + Stacks 會根據指定的負載指標自動啟動和停止**負載型執行個體**，例如 CPU OpsWorks 使用率。他們可讓您的堆疊自動調整執行個體的數目，以適應傳入流量的變化。負載式執行個體僅適用於 Linux 式的堆疊。 OpsWorks Stacks 支援執行個體自動修復。如果代理程式停止與服務的通訊， OpsWorks Stacks 會自動停止並重新啟動執行個體。您也可以將 Linux 型運算資源整合到在 Stacks OpsWorks 外部建立的堆疊中。 + 您使用 Amazon EC2 主控台、CLI 或 API 直接建立的 Amazon EC2 執行個體。 + 在您自己的硬體上執行的「現場部署」**執行個體，包括在虛擬機器中執行的執行個體。註冊其中一個執行個體之後，該執行個體會成為 OpsWorks Stacks 執行個體，而且您可以像使用 OpsWorks Stacks 建立的執行個體一樣進行管理。 ## 應用程式您可以將應用程式和相關檔案存放在儲存庫中，例如 Amazon S3 儲存貯體。每個應用程式都會以一個「應用程式」**代表，指定應用程式類型並包含從儲存庫將應用程式部署到您執行個體所需要的資訊，例如儲存庫 URL 和密碼。當您部署應用程式時， OpsWorks Stacks 會觸發部署事件，在堆疊的執行個體上執行部署配方。您可採用以下方式來部署應用程式： + 自動 - 當您啟動執行個體時， OpsWorks Stacks 會自動執行執行個體的部署配方。 + 手動 – 若您有新的應用程式，或希望更新現有的應用程式，您可以手動執行線上執行個體的部署配方。您通常會讓 OpsWorks Stacks 在整個堆疊上執行部署配方，以允許其他 layer 的執行個體適當地修改其組態。但是，舉例來說，若您希望在將應用程式部署到每個應用程式伺服器執行個體前測試新的應用程式，您可以將部署限制在執行個體一部分的子集。 ## 自訂您的 Stack OpsWorks Stacks 提供各種自訂 layer 的方式，以滿足您的特定需求： + 您可以透過覆寫代表各種組態設定的屬性，或甚至覆寫用於建立組態檔案的範本，來修改 OpsWorks Stacks 如何設定套件。 + 您可以透過提供您自己的配方，執行像是執行指令碼或安裝和設定非標準套件等任務來延伸現有的 layer。所有堆疊可包含一或多個 layer。一開始的 layer 只會有最小的配方組。您透過實作配方，處理像是安裝套件、部署應用程式等任務，來將功能新增到 layer。您可以將自訂配方和相關檔案封裝在一或多個*技術指南*中，並將技術指南存放在 Amazon S3 或 Git 等儲存庫中。您可以手動執行配方，但 OpsWorks Stacks 也可讓您支援一組五個*生命週期事件*來自動化程序： + **Setup (安裝)** 會在新的執行個體成功開機之後發生。 + **Configure (設定)** 會在執行個體進入或離開線上狀態時，在所有堆疊的執行個體上發生。 + **Deploy (部署)** 會在您部署應用程式時發生。 + **Undeploy (解除部署)** 會在您刪除應用程式時發生。 + **Shutdown (關機)** 會在您停止執行個體時發生。每個 layer 都可以將任何數目的配方指派給每個事件。當 layer 執行個體上發生生命週期事件時， OpsWorks Stacks 會執行相關聯的配方。例如，當應用程式伺服器執行個體上發生部署事件時， OpsWorks Stacks 會執行 layer 的部署配方，以下載應用程式或執行相關任務。 ## 資源管理您可以將其他 AWS 資源 (例如[彈性 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)) 併入您的堆疊。您可以使用 OpsWorks Stacks 主控台或 API 向堆疊註冊資源、將已註冊的資源連接至執行個體或從執行個體分離資源，以及將資源從一個執行個體移至另一個執行個體。 ## 安全與許可 AWS OpsWorks Stacks 與 AWS Identity and Access Management (IAM) 整合，提供強大的方法來控制使用者存取 OpsWorks Stacks 的方式，包括下列項目： + 個別使用者如何與每個堆疊互動，例如是否可以建立堆疊資源，例如 layer 和執行個體，或者是否可以使用 SSH 或 RDP 連線到堆疊的 Amazon EC2 執行個體。 + Stacks OpsWorks 如何代表您與 Amazon EC2 執行個體等 AWS 資源互動。 + 在 OpsWorks Stacks 執行個體上執行的應用程式如何存取 AWS 資源，例如 Amazon S3 儲存貯體。 + 如何管理使用者的公有 SSH 金鑰和 RDP 密碼，以及連線到執行個體。 ## 監控和記錄 OpsWorks Stacks 提供多種功能，可協助您監控堆疊，並針對堆疊和任何配方的問題進行疑難排解。針對所有堆疊： + OpsWorks Stacks 為 Linux 堆疊提供一組自訂 CloudWatch 指標，為方便起見，請參閱**監控**頁面。 OpsWorks Stacks 支援 Windows 堆疊的標準 CloudWatch 指標。您可以使用 CloudWatch 主控台監控它們。 + CloudTrail 日誌，記錄您 AWS 帳戶中由 Stacks 發出或代表 Stacks OpsWorks 發出的 API 呼叫。 + 事件日誌會列出您堆疊中的所有事件。 + Chef 日誌會詳細記載針對每個執行個體上每個生命週期事件進行的行為，例如執行了哪些配方，以及發生了哪些錯誤。以 Linux 為基礎的堆疊也可以包含 Ganglia 主層，可用來收集和顯示堆疊中執行個體的詳細監控資料。 ## CLI、軟體開發套件和 CloudFormation 範本除了主控台之外， OpsWorks Stacks 還支援適用於多種語言的命令列界面 (CLI) 和 SDKs，可用於執行任何操作。考量這些功能： + OpsWorks Stacks CLI 是 [AWS CLI ](https://aws.amazon.com/documentation/cli/)的一部分，可用於從命令列執行任何操作。 AWS CLI 支援多個 AWS 服務，並且可安裝在 Windows、Linux 或 OS X 系統上。 + OpsWorks Stacks 包含在適用於 [Windows PowerShell 的 AWS 工具](https://aws.amazon.com/documentation/powershell/)中，可用於從 Windows PowerShell 命令列執行任何操作。 + Stacks SDK OpsWorks 包含在 AWS SDKs中，可由實作於下列中的應用程式使用：[Java](https://aws.amazon.com/documentation/sdkforjava/)、[JavaScript](https://aws.amazon.com/documentation/sdkforjavascript/) （瀏覽器型和 Node.js)、[.NET](https://aws.amazon.com/documentation/sdkfornet/)、[PHP](https://aws.amazon.com/documentation/sdkforphp/)、[Python (boto)](http://boto.readthedocs.org/en/latest/) 或 [Ruby](https://aws.amazon.com/documentation/sdkforruby/)。您也可以使用 CloudFormation 範本來佈建堆疊。如需一些範例，請參閱 [AWS OpsWorks 程式碼片段](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-opsworks.html)。 # AWS OpsWorks Stacks 生命週期結束FAQs **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。 **Topics** + [現有客戶將受到此生命週期結束的影響？](#w2ab1c14c41b7) + [是否 AWS OpsWorks Stacks 接受新客戶？](#w2ab1c14c41b9) + [我應該將現有堆疊遷移到哪裡？](#w2ab1c14c41c11) + [如何在生命週期結束後保留現有的 Amazon EC2 執行個體？](#w2ab1c14c41c13) + [生命週期結束是否會 AWS 區域同時影響所有？](#w2ab1c14c41c15) + [提供哪些層級的技術支援 AWS OpsWorks Stacks？](#w2ab1c14c41c17) + [是否有任何新的功能版本 AWS OpsWorks Stacks？](#w2ab1c14c41c19) ## 現有客戶將受到此生命週期結束的影響？在的生命週期結束日期 2024 年 5 月 26 日之前，現有客戶不會受到影響 AWS OpsWorks Stacks。2024 年 5 月 26 日之後，客戶將無法使用 OpsWorks 主控台、API、CLI 和 CloudFormation 資源。 ## 是否 AWS OpsWorks Stacks 接受新客戶？否。 AWS OpsWorks Stacks 不再接受新客戶，目前只有現有客戶才能建立新的堆疊。 ## 我應該將現有堆疊遷移到哪裡？我們建議 AWS OpsWorks Stacks 客戶將工作負載遷移到 AWS Systems Manager ，讓他們可以利用下列功能： + 現代 Chef 版本 + SSM Agent + Application Load Balancer + 透過 Auto Scaling 群組增強擴展功能 + 能夠使用 EC2 啟動範本定義所需的主機特性 + 較新的執行個體類型 + 較新的 EBS 磁碟區類型如需 Systems Manager 的詳細資訊，請參閱[AWS Systems Manager 《使用者指南](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)》。如需遷移至的資訊 AWS Systems Manager，請參閱 [將您的 AWS OpsWorks Stacks 應用程式遷移至 AWS Systems Manager Application Manager](migrating-to-systems-manager.md) ## 如何在生命週期結束後保留現有的 Amazon EC2 執行個體？達到生命週期結束日期後，您的 Amazon EC2 執行個體將保留在您的帳戶中，但您將無法再使用 OpsWorks Stacks 服務來控制和管理執行個體。您可以使用就地 AWS OpsWorks Stacks 分離工具，將 OpsWorks 執行個體與 OpsWorks Stacks 服務分離。分離後，您可以使用 Amazon EC2 AWS Systems Manager或任何 EC2 相容方法來設定和管理執行個體。如需詳細資訊，請參閱[使用就地 AWS OpsWorks Stacks 分離工具](using-stacks-detach-tool.md)。 ## 生命週期結束是否會 AWS 區域同時影響所有？是。OpsWorks 主控台、API、CLI 和 CloudFormation 資源將於 2024 年 5 月 26 日在全部中 AWS 區域同時停止。如需 AWS OpsWorks Stacks 可用 AWS 區域的清單，請參閱[AWS 區域服務清單](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)。 ## 提供哪些層級的技術支援 AWS OpsWorks Stacks？ AWS 在生命週期結束日期之前，將繼續為 AWS OpsWorks Stacks 該客戶提供相同層級的支援。如果您有問題或疑慮，可以透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 ## 是否有任何新的功能版本 AWS OpsWorks Stacks？否。由於服務即將生命週期結束，我們將不會發行任何新功能。不過，我們將繼續如預期進行安全性改善和管理 Amazon EC2 執行個體，直到生命週期結束日期為止。 # 將您的 AWS OpsWorks Stacks 應用程式遷移至 AWS Systems Manager Application Manager **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。您現在可以使用遷移指令碼，將 AWS OpsWorks Stacks 應用程式遷移至 [Application Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager.html) AWS Systems Manager的功能。將 Stacks 應用程式遷移至 Systems Manager Application Manager 可讓您使用中無法使用 AWS 的功能 AWS OpsWorks Stacks，例如 Graviton 等新的 Amazon EC2 執行個體類型、gp3 等新的 Amazon Elastic Block Store (EBS) 磁碟區、新的作業系統、與 Auto Scaling 群組的整合，以及應用程式負載平衡器。透過此版本，您現在可以使用 Systems Manager Application Manager 提供的新**執行個體**索引標籤來監控和執行遷移執行個體的操作。您可以使用**執行個體**索引標籤，在一個位置檢視多個 AWS 執行個體。使用此索引標籤，您可以檢視執行個體運作狀態和疑難排解問題的相關資訊。如需使用**執行個體**索引標籤的詳細資訊，請參閱*AWS Systems Manager 《使用者指南*》中的[使用應用程式執行個體](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-instances.html)。 **Topics** + [指令碼的運作方式](#migrating-to-systems-manager-script) + [先決條件](migrating-to-systems-manager-prerequisites.md) + [限制](migrating-to-systems-manager-limitations.md) + [開始使用](migrating-to-systems-manager-getting-started.md) + [常見問答集](migrating-to-systems-manager-faqs.md) + [疑難排解](migrating-to-systems-manager-troubleshooting.md) ## 指令碼的運作方式 OpsWorks 提供您可以使用 CloudFormation 範本執行的指令碼，將 AWS OpsWorks Stacks 應用程式遷移至 Systems Manager Application Manager。指令碼會取得現有 OpsWorks 層的相關資訊，並根據指令碼的 `--provision-application` 參數值，佈建應用程式的複製，或提供您可以使用的入門 CloudFormation 範本 CloudFormation。 # 先決條件 + 請確定 AWS CLI 已安裝並設定。如需安裝的詳細資訊 AWS CLI，請參閱*AWS Command Line Interface 《使用者指南*》中的[安裝或更新最新版本的 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)。 **注意** 如果您不想設定 AWS CLI，您也可以使用執行命令 AWS CloudShell。如需使用 CloudShell 的詳細資訊，請參閱*AWS CloudShell 《使用者指南*》中的[使用 AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/working-with-cloudshell.html) 。 + 請確定 Python 3.6 版或更新版本已安裝或隨附 Amazon Machine Image (AMI)。 + 請確定您的作業系統受到支援。您可以在下列作業系統下載並執行遷移指令碼。 + Amazon Linux 和 Amazon Linux 2 + Ubuntu 18.04 LTS、20.04 LTS、22.04 LTS + Red Hat Enterprise Linux 8 + Windows Server 2019、Windows 10 Enterprise **注意** 不支援 Windows Server 2022。 # 限制新的 OpsWorks 架構與的架構不同 AWS OpsWorks Stacks。本節說明此架構的已知限制。新 OpsWorks 架構不支援下列項目。 + 在 Windows 和 CentOS 執行個體上執行 Chef 配方 + 內建 Chef 11 層和 Berkshelf + Chef 屬性和資料包 + 現場部署執行個體 + 從 EC2 匯入的執行個體 + 不支援安裝使用者指定的作業系統套件清單 + 不支援或遷移應用程式以下支援有限制的。 + 遷移指令碼會複製 EBS 磁碟區資訊，但排除磁碟區中包含的掛載點和實際資料。 + 時間型和負載型擴展執行個體會遷移，但與這些執行個體相關聯的任何擴展規則都不會遷移。您可以修改 Auto Scaling 群組，以達到類似的結果。 + 在 OpsWorks 主控台的堆疊**許可**頁面中定義的 IAM 實體不會建立或產生。 + 遷移指令碼只能在 Systems Manager 中佈建單層應用程式。例如，如果您在同一堆疊中為兩層執行指令碼兩次，您會在 Systems Manager 中取得兩個不同的應用程式。 # 開始使用遷移指令碼是 Python 指令碼`stack_exporter.py`，您可以在本機或在 EC2 執行個體上執行。執行指令碼之前，請確定符合所有先決條件。如需先決條件的詳細資訊，請參閱 [先決條件](migrating-to-systems-manager-prerequisites.md)。以下各節中的步驟說明如何將 OpsWorks 堆疊遷移至 Systems Manager Application Manager。 **Topics** + [步驟 1：準備您的環境以執行指令碼](w2ab1c14c43c17b9.md) + [步驟 2：下載遷移指令碼](migrating-to-systems-manager-download-script.md) + [步驟 3：設定您的環境以執行指令碼](migrating-to-systems-manager-script-parameters.md) + [步驟 4：執行指令碼](migrating-to-systems-manager-run-script.md) + [步驟 5：佈建 CloudFormation 堆疊](migrating-to-systems-manager-provision-stack.md) + [步驟 6：檢閱佈建的資源](migrating-to-systems-manager-provision-resources.md) + [步驟 7：啟動執行個體](migrating-to-systems-manager-start-instance.md) + [步驟 8：檢閱執行個體](migrating-to-systems-manager-review-instance.md) + [步驟 9：使用 Systems Manager Application Manager 在執行個體上監控和執行操作](migrating-to-systems-manager-monitor.md) # 步驟 1：準備您的環境以執行指令碼為您的作業系統執行適當的命令，以準備您的環境。 **Topics** + [Amazon Linux 2](#w2ab1c14c43c17b9b7) + [Amazon Linux](#w2ab1c14c43c17b9b9) + [Ubuntu 18.04、20.04、22.04](#w2ab1c14c43c17b9c11) + [Red Hat Enterprise Linux 8](#w2ab1c14c43c17b9c13) + [Windows Server 2019、Windows 10 Enterprise](#w2ab1c14c43c17b9c15) ## Amazon Linux 2 ``` sudo su python3 -m pip install pipenv PATH="$PATH:/usr/local/bin" yum update yum install git ``` ## Amazon Linux ``` sudo su PATH="$PATH:/usr/local/bin" export LC_ALL=en_US.utf-8 export LANG=en_US.utf-8 yum update yum list | grep python3 yum install python36 // Any python version yum install git ``` 對於 Python 3.6 版，也執行： ``` python3 -m pip install pipenv==2022.4.8 ``` 對於 Python 3.7 版和更新版本，也請執行： ``` python3 -m pip install pipenv ``` ## Ubuntu 18.04、20.04、22.04 ``` sudo su export PATH="${HOME}/.local/bin:$PATH" apt-get update apt install python3-pip apt-get install git // if git is not installed python3 -m pip install --user pipenv==2022.4.8 ``` ## Red Hat Enterprise Linux 8 ``` sudo su sudo dnf install python3 PATH="$PATH:/usr/local/bin" yum update yum install git python3 -m pip install pipenv==2022.4.8 ``` ## Windows Server 2019、Windows 10 Enterprise **注意** 對於 Windows Server 2019，請安裝 Python 3.6.1 版或更新版本。 ``` pip install pipenv ``` 如果尚未安裝 Git，請下載並安裝 [Git](https://git-scm.com/download/win)。如果您使用 Git 做為技術指南來源，請在 Windows 上執行指令碼之前，將 Git 伺服器新增至 `known_hosts` 檔案。您可以使用 PowerShell 建立下列函數。 ``` function add_to_known_hosts($server){ $new_host=$(ssh-keyscan $server 2> $null) $existing_hosts='' if (!(test-path "$env:userprofile\.ssh")) { md "$env:userprofile\.ssh" } if ((test-path "$env:userprofile\.ssh\known_hosts")) { $existing_hosts=Get-Content "$env:userprofile\.ssh\known_hosts" } $host_added=0 foreach ($line in $new_host) { if (!($existing_hosts -contains $line)) { Add-Content -Path "$env:userprofile\.ssh\known_hosts" -Value $line $host_added=1 } } if ($host_added) { echo "$server has been added to known_hosts." } else { echo "$server already exists in known_hosts." } } ``` 然後，您可以在執行函數時提供 Git 伺服器（例如 github.com、git-codecommit.*repository\$1region*.amazonaws.com)。 ``` add_to_known_hosts "myGitServer" ``` # 步驟 2：下載遷移指令碼執行下列命令，下載包含遷移指令碼和所有相關檔案的 zip 檔案。 ``` aws s3api get-object \ --bucket export-opsworks-stacks-bucket-prod-us-east-1 \ --key export_opsworks_stacks_script.zip export_opsworks_stacks_script.zip ``` 如果您使用的是 Linux，請使用下列命令安裝 unzip 公用程式。 ``` sudo apt-get install unzip sudo yum install unzip ``` 使用適合您作業系統的命令解壓縮檔案。 **針對 Linux**，請使用下列命令。 ``` unzip export_opsworks_stacks_script.zip ``` **對於 Windows**，請在 PowerShell 中使用 `Expand-Archive`命令。 ``` Expand-Archive -LiteralPath PathToZipFile -DestinationPath PathToDestination ``` 檔案解壓縮後，即可使用下列目錄和檔案。 + README.md + LICENSE + NOTICE + requirements.txt + 範本/ + OpsWorksCFNTemplate.yaml + MountEBSVolumes.yaml + opsworks/ + cloudformation/ + instance\$1tab/ + cfn\$1stack\$1deployer.py + s3.py + stack\$1exporter\$1context.py + stack\$1exporter.py # 步驟 3：設定您的環境以執行指令碼使用下列命令將您的環境設定為執行指令碼。 ``` pipenv install -r requirements.txt pipenv shell ``` **注意** 目前，指令碼只能在 Application Manager 中佈建單層應用程式。例如，如果您在同一堆疊中為兩層執行指令碼兩次，則指令碼會在 Application Manager 中建立兩個不同的應用程式。設定環境之後，請檢閱指令碼參數。您可以執行 `python3 stack_exporter.py --help`命令來檢視遷移指令碼的可用選項。 **** | 參數 | Description | 必要 | Type | 預設值 | | --- | --- | --- | --- | --- | | --layer-id | 匯出此 OpsWorks layer ID 的 CloudFormation 範本。 | 是 | string | | | --region | OpsWorks 堆疊 AWS 的區域。如果您的 OpsWorks 堆疊區域和 API 端點區域不同，請使用堆疊區域。這與 OpsWorks 堆疊的其他資源部分（例如 EC2 執行個體和子網路）相同。 | 否 | string | us-east-1 | | --provision-application | 根據預設，指令碼會佈建 CloudFormation 範本匯出的應用程式。將此參數傳遞至值為 FALSE 的指令碼，以略過 CloudFormation 範本的佈建。 | 否 | Boolean | TRUE | | --launch-template | 此參數定義是使用現有的啟動範本，還是建立新的啟動範本。您可以建立新的啟動範本，使用建議的執行個體屬性，或使用符合線上執行個體的執行個體屬性。有效值包含： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/migrating-to-systems-manager-script-parameters.html) | 否 | string | RECOMMENDED | | --system-updates | 定義是否要在執行個體開機時執行核心和套件更新。有效值包含： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/migrating-to-systems-manager-script-parameters.html) | 否 | string | ALL\$1UPDATES | | --http-username | Systems Manager SecureString 參數的名稱，存放用於向包含自訂技術指南的 HTTP 封存進行身分驗證的使用者名稱。 | 否 | string | | | --http-password | Systems Manager SecureString 參數的名稱，存放用於向包含自訂技術指南的 HTTP 封存進行身分驗證的密碼。 | 否 | string | | | --repo-private-key | Systems Manager SecureString 參數的名稱，存放用於向包含自訂技術指南的儲存庫進行身分驗證的 SSH 金鑰。如果儲存庫位於 GitHub，您必須產生新的 Ed25519 SSH 金鑰。如果您未產生新的 Ed25519 SSH 金鑰，則與 GitHub 儲存庫的連線會失敗。 | 否 | string | | | --lb-type | 遷移現有負載平衡器時要建立的負載平衡器類型，如果有的話。有效值包含： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/migrating-to-systems-manager-script-parameters.html) | 否 | string | ALB | | --lb-access-logs-path | 儲存負載平衡器存取日誌的現有 S3 儲存貯體和字首路徑。S3 儲存貯體和負載平衡器必須位於相同的區域。如果您未提供值，且--lb-type參數值設定為 None，則指令碼會建立新的 S3 儲存貯體和字首。請確定此字首有適當的儲存貯體政策。 | 否 | string | | | --enable-instance-protection | 如果設定為 TRUE ，指令碼會為您的 Auto Scaling 群組建立自訂終止政策 (Lambda 函數）。具有protected\$1instance標籤的 EC2 執行個體受到縮減事件的保護。將protected\$1instance標籤新增至您要保護免於縮減事件的每個 EC2 執行個體。 | 否 | Boolean | FALSE | | --command-logs-bucket | 用來存放 AWS ApplyChefRecipe和 MountEBSVolumes日誌的現有 S3 儲存貯體名稱。如果您未提供值，指令碼會建立新的 S3 儲存貯體。 | 否 | string | aws-opsworks-application-manager-logs-account-id | | --custom-json-bucket | 儲存自訂 JSON 的現有 S3 儲存貯體名稱。如果您未提供值，指令碼會建立新的 S3 儲存貯體。 | 否 | string | aws-apply-chef-application-manager-transition-data-account-id | **備註**： + 如果您使用私有 GitHub 儲存庫，則必須為 SSH 建立新的`Ed25519`主機金鑰。這是因為 GitHub 變更了 SSH 中支援的金鑰，並移除了未加密的 Git 通訊協定。如需`Ed25519`主機金鑰的詳細資訊，請參閱 GitHub 部落格文章[改善 Git GitHub 通訊協定安全性](https://github.blog/2021-09-01-improving-git-protocol-security-github/)。產生新的`Ed25519`主機金鑰後，請為 SSH 金鑰建立 Systems Manager `SecureString` 參數，並使用 `SecureString` 參數名稱做為 `--repo-private-key` 參數的值。如需如何建立 Systems Manager `SecureString` 參數的詳細資訊，請參閱*AWS Systems Manager 《使用者指南*》中的[建立 SecureString 參數 (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) 或[建立 Systems Manager 參數（主控台）](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)。 + `--http-username`、 `--http-password`和 `--repo-private-key` 參數是指 Systems Manager `SecureString` 參數的名稱。當您執行`AWS-ApplyChefRecipes`文件時，遷移指令碼會使用這些參數。 + `--http-username` 參數要求您也指定 `--http-password` 參數的值。 + `--http-password` 參數要求您也指定 `--http-username` 參數的值。 + 請勿同時設定 `--http-password`和的值`--repo-private-key`。提供 SSH 金鑰 (`--repo-private-key`) 的 Systems Manager `SecureString` 參數名稱，或儲存庫使用者名稱 (`--http-username`) 和密碼 ()`--http-password`。 # 步驟 4：執行指令碼當您執行時`python3 stack_exporter.py`，您可以佈建應用程式，或透過將 `--provision-application` 參數的值設定為來建立入門範本`FALSE`。 **範例 1：佈建 Systems Manager Application Manager 應用程式** 下列命令會取得現有 OpsWorks layer 的相關資訊，並使用較新的 OpsWorks 架構佈建應用程式，進而達到類似於為堆疊設定的 Chef 版本的結果。指令碼會使用 CloudFormation 佈建所有必要的資源，例如 Auto Scaling 群組，然後在 Systems Manager Application Manager 中註冊應用程式。將 *stack-region* 和 *layer-id* 取代為 OpsWorks 堆疊和 layer 的值。 ``` python3 stack_exporter.py \ --layer-id layer-id \ --region stack-region ``` **範例 2：產生範本** 下列命令會取得現有 OpsWorks layer 的相關資訊，並產生 CloudFormation 範本。如果佈建範本，則會達成類似於使用 Chef 14 的結果。在此範例中，不會佈建資源，因為 `--provision-application` 參數設定為 `FALSE`。將 *stack-region* 和 *layer-id* 取代為 OpsWorks 堆疊和 layer 的值。 ``` python3 stack_exporter.py \ --layer-id layer-id \ --region stack-region \ --provision-application FALSE ``` 執行命令後，您可以在 Systems Manager 的 Application Manager 範本程式庫中檢閱範本，也可以佈建範本。如需檢視範本程式庫的詳細資訊，請參閱*AWS Systems Manager 《使用者指南*》中的[使用範本程式庫](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-templates-overview.html#application-manager-working-stacks-template-library-working)。 # 步驟 5：佈建 CloudFormation 堆疊 **注意** 只有在您將指令碼的 `--provision-application` 參數設定為時，才需要完成此步驟`FALSE`。當您以的值指定 `--provision-application` 參數時`FALSE`，指令碼輸出會提供 CloudFormation 範本的名稱和 URL。此範本代表現有 OpsWorks 堆疊和 layer 的建議替換。您可以使用 Application Manager 範本程式庫（建議）或使用 CloudFormation 來佈建範本。如需使用範本程式庫的詳細資訊，請參閱*AWS Systems Manager 《使用者指南*》中的[使用範本程式庫](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-templates-overview.html#application-manager-working-stacks-template-library-working)。 # 步驟 6：檢閱佈建的資源您現在可以檢閱佈建的資源。 1. 使用 CloudFormation 主控台檢閱佈建堆疊的資源。 1. 在 https：//[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) 開啟 CloudFormation 主控台，然後選擇 **Stacks**。 1. 在**堆疊**頁面上，選擇堆疊，然後選擇**資源**索引標籤。 1. 在**資源**索引標籤上，檢閱堆疊列出的資源。資源清單包含 EC2 Auto Scaling 群組，您可以在 Auto Scaling 主控台中檢閱，或 AWS CLI。 1. 使用 Systems Manager Application Manager 檢閱應用程式的資源。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 在**應用程式**區段中，選擇自訂應用程式。Application Manager 會開啟**概觀**索引標籤。 1. 選擇 **Resources** (資源) 標籤。**資源**索引標籤會顯示針對 OpsWorks 堆疊和 layer 遷移的所有資源。應用程式名稱包含 OpsWorks 堆疊的名稱，格式為 *app*-*stack-name*-*suffix*，其中*尾碼*代表堆疊 ID 的前六個字元。如需在 Application Manager 中檢視資源的詳細資訊，請參閱*AWS Systems Manager *[《使用者指南》中的檢視應用程式資源](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-viewing-resources.html)。 # 步驟 7：啟動執行個體佈建執行個體之後，您就可以測試執行個體。此時，沒有執行個體正在執行。若要讓執行個體上線，請將 Auto Scaling 群組的 `Min`、 `Max`和 `Desired capacity`值調整為對您的應用程式有意義的數字。一開始，您可能想要將這些值設定為 1，讓單一執行個體上線，並確認執行個體執行所有預期的動作，包括執行您的自訂 Chef 配方。 # 步驟 8：檢閱執行個體啟動執行個體之後，請驗證執行個體是否如預期般執行。 1. 檢閱位於指令碼`--command-logs-bucket`參數所指定 S3 儲存貯體中的 Chef `startup`和`terminate`日誌。根據預設，日誌會存放在名為的儲存貯體中`aws-opsworks-application-manager-logs-account-id`。 1. 登入 AWS 管理主控台，並在 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)：// 開啟 Amazon S3 主控台。 1. 選擇包含日誌的儲存貯體。 1. 導覽至 `ApplyChefRecipes` 字首以檢視您的日誌。 1. 檢查 Application Load Balancer 連線和運作狀態。執行下列步驟來檢視負載平衡器的存取日誌。您可以使用指令碼的 `--lb-access-logs-path` 參數，指定要存放負載平衡器存取日誌的 S3 儲存貯體。 1. 登入 AWS 管理主控台，並在 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)：// 開啟 Amazon S3 主控台。 1. 選擇您的 S3 儲存貯體，然後導覽至包含日誌的字首。 1. 驗證執行個體通過所有 Auto Scaling 和 Application Load Balancer 運作狀態檢查（如果您已設定）。您可以在新的**執行個體**索引標籤上檢視 Auto Scaling 運作狀態的相關資訊。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 在**應用程式**區段中，選擇**自訂應用程式**。 1. 在清單中選擇應用程式。Application Manager 會開啟**概觀**索引標籤。 1. 選擇**執行個體**索引標籤以檢視 Auto Scaling 運作狀態的相關資訊。驗證 Chef 配方是否成功執行後，您可以減少 Auto Scaling 群組容量來終止執行個體。如果您有任何自訂終止配方，請確認配方如預期般運作。 # 步驟 9：使用 Systems Manager Application Manager 在執行個體上監控和執行操作您現在可以使用 Application Manager 頁面上的新**執行個體**索引標籤來監控和執行執行個體上的操作。如需使用**執行個體**索引標籤的詳細資訊，請參閱*AWS Systems Manager 《使用者指南*》中的[使用應用程式執行個體](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-instances.html)。您可以使用**執行個體**索引標籤，在一個位置檢視多個 AWS 執行個體。使用此索引標籤，您可以檢視執行個體運作狀態和疑難排解問題的相關資訊。 ![\[Application dashboard showing instance status with running, healthy, and OK indicators at 100%.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/instances-tab.png) 執行下列步驟來檢視**執行個體**索引標籤。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 在**應用程式**區段中，選擇**自訂應用程式**。 1. 在清單中選擇應用程式。Application Manager 會開啟**概觀**索引標籤。 1. 選擇**執行個體**索引標籤，以檢視執行個體狀態和 EC2 運作狀態的相關資訊。 # 常見問答集下列FAQs提供一些常見問題的答案。 **Topics** + [我可以遷移哪些 AWS OpsWorks Stacks 版本？](#w2ab1c14c43c19b7) + [我的遷移執行個體可以使用哪些 Chef 版本？](#w2ab1c14c43c19b9) + [我可以遷移哪些儲存庫類型？](#w2ab1c14c43c19c11) + [我可以繼續使用私有 Git 儲存庫嗎？](#w2ab1c14c43c19c13) + [我可以使用哪些 SSH 金鑰來存取執行個體？](#w2ab1c14c43c19c15) + [為什麼我的執行個體會自動向內和向外擴展？](#w2ab1c14c43c19c17) + [我可以關閉 Auto Scaling 嗎？](#w2ab1c14c43c19c19) + [我可以在啟動的 EC2 執行個體上執行核心和套件更新嗎？](#w2ab1c14c43c19c21) + [為什麼我的執行個體中的 EBS 磁碟區不包含任何資料？](#w2ab1c14c43c19c23) + [為什麼我的啟動範本中未掛載 EBS 磁碟區？](#w2ab1c14c43c19c25) + [哪裡可以找到 Chef 配方和掛載 EBS 磁碟區日誌？](#w2ab1c14c43c19c27) + [哪裡可以找到遷移指令碼的偵錯日誌？](#w2ab1c14c43c19c29) + [遷移指令碼是否支援 CloudFormation 範本版本控制？](#w2ab1c14c43c19c31) + [我可以遷移多個層嗎？](#w2ab1c14c43c19c33) + [如何建立`SecureString`參數？](#w2ab1c14c43c19c35) + [如何保護新 Auto Scaling 群組中的執行個體免於終止事件？](#w2ab1c14c43c19c37) + [遷移指令碼可使用哪些負載平衡器？](#w2ab1c14c43c19c39) + [自訂技術指南設定配方是否已遷移？](#w2ab1c14c43c19c41) + [我可以在新建立的執行個體上執行部署和取消部署配方嗎？](#w2ab1c14c43c19c43) + [我可以變更 Auto Scaling 群組跨越哪些子網路嗎？](#w2ab1c14c43c19c45) ## 我可以遷移哪些 AWS OpsWorks Stacks 版本？您只能遷移 Chef 11.10 和 Chef 12、Amazon Linux、Amazon Linux 2、Ubuntu 和 Red Hat Enterprise Linux 7 堆疊。 ## 我的遷移執行個體可以使用哪些 Chef 版本？遷移的執行個體可以使用 Chef 版本 11 到 14。 **注意** 不支援 Windows 堆疊遷移。 ## 我可以遷移哪些儲存庫類型？您可以遷移 S3、Git 和 HTTP 儲存庫類型。 ## 我可以繼續使用私有 Git 儲存庫嗎？可以，您可以繼續使用私有 Git 儲存庫。如果您使用私有 GitHub 儲存庫，則必須為 SSH 建立新的`Ed25519`主機金鑰。這是因為 GitHub 變更了 SSH 中支援的金鑰，並移除了未加密的 Git 通訊協定。如需`Ed25519`主機金鑰的詳細資訊，請參閱 GitHub 部落格文章[改善 Git GitHub 通訊協定安全性](https://github.blog/2021-09-01-improving-git-protocol-security-github/)。產生新的`Ed25519`主機金鑰後，請為此 SSH 金鑰建立 Systems Manager `SecureString` 參數，並使用參數名稱做為 `--repo-private-key` 參數的值。如需如何建立 Systems Manager `SecureString` 參數的詳細資訊，請參閱*AWS Systems Manager 《使用者指南*》中的[建立 SecureString 參數 (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring)。對於任何其他 Git 儲存庫類型，請為此 SSH 金鑰建立 Systems Manager `SecureString` 參數，並使用參數名稱做為指令碼`--repo-private-key`參數的值。 ## 我可以使用哪些 SSH 金鑰來存取執行個體？當您執行指令碼時，指令碼會遷移堆疊中設定的 SSH 金鑰和執行個體。您可以使用 SSH 金鑰來存取執行個體。如果為堆疊和執行個體提供 SSH 金鑰，則指令碼會使用來自堆疊的金鑰。如果您不確定要使用哪些 SSH 金鑰，請在 EC2 主控台 ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)：//) 中檢視執行個體。EC2 主控台中**的詳細資訊**頁面會顯示執行個體的 SSH 金鑰。 ## 為什麼我的執行個體會自動向內和向外擴展？ Auto Scaling 會根據 Auto Scaling 群組的擴展規則來擴展執行個體。您可以設定群組的**最小**、**最大**和**所需容量**值。當您更新這些值時，Auto Scaling 群組會自動相應地擴展您的容量。 ## 我可以關閉 Auto Scaling 嗎？您可以將 Auto Scaling 群組的**最小**、**最大**和**所需容量**值設定為相同的數字，以關閉 Auto Scaling。例如，如果您想要一律有 10 個執行個體，請將**最小**、**最大**和**所需容量**值設定為 10。 ## 我可以在啟動的 EC2 執行個體上執行核心和套件更新嗎？根據預設，核心和套件會在 EC2 執行個體開機時更新。使用下列步驟，在啟動的 EC2 執行個體上執行核心或套件更新。例如，您可能想要在執行部署或設定配方後套用更新。 1. 連線至 EC2 執行個體。 1. 建立下列`perform_upgrade`函數，並在您的執行個體上執行。 ``` perform_upgrade() { #!/bin/bash if [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then sudo yum -y update elif [ -e '/etc/debian_version' ]; then sudo apt-get update sudo apt-get dist-upgrade -y fi } perform_upgrade ``` 1. 在核心和套件更新之後，您可能需要重新啟動 EC2 執行個體。若要檢查是否需要重新啟動，請建立下列`reboot_if_required`函數，並在 EC2 執行個體上執行。 ``` reboot_if_required () { #!/bin/bash if [ -e '/etc/debian_version' ]; then if [ -f /var/run/reboot-required ]; then echo "reboot is required" else echo "reboot is not required" fi elif [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then export LC_CTYPE=en_US.UTF-8 export LC_ALL=en_US.UTF-8 LATEST_INSTALLED_KERNEL=`rpm -q --last kernel | perl -X -pe 's/^kernel-(\S+).*/$1/' | head -1` CURRENTLY_USED_KERNEL=`uname -r` if [ "${LATEST_INSTALLED_KERNEL}" != "${CURRENTLY_USED_KERNEL}" ];then echo "reboot is required" else echo "reboot is not required" fi fi } reboot_if_required ``` 1. 如果執行 `reboot_if_required`會產生`reboot is required`訊息，請重新啟動 EC2 執行個體。如果您收到`reboot is not required`訊息，則不需要重新啟動 EC2 執行個體。 ## 為什麼我的執行個體中的 EBS 磁碟區不包含任何資料？當您執行指令碼時，指令碼會遷移 EBS 磁碟區的組態，為 OpsWorks 堆疊和層建立替代架構。指令碼不會遷移實際執行個體或執行個體中包含的資料。指令碼只會遷移層層級的 EBS 磁碟區組態，並將空的 EBS 磁碟區連接至啟動的 EC2 執行個體。執行下列步驟，從先前執行個體的 EBS 磁碟區提取資料。 1. 拍攝先前執行個體 EBS 磁碟區的快照。如需建立快照的詳細資訊，請參閱[《Amazon EC2 使用者指南》中的建立 Amazon EBS 快照](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)。 *Amazon EC2 * 1. 從快照建立磁碟區。如需從快照建立磁碟區的詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[從快照建立磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot)。 1. 將您建立的磁碟區連接到執行個體。如需連接磁碟區的詳細資訊，請參閱《[Amazon EC2 使用者指南》中的將 Amazon EBS 磁碟區連接至執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html)。 *Amazon EC2 * ## 為什麼我的啟動範本中未掛載 EBS 磁碟區？如果您為具有 EBS 磁碟區的 `--launch-template` 參數提供啟動範本 ID，指令碼會連接 EBS 磁碟區，但不會掛載磁碟區。您可以執行為啟動的 EC2 執行個體建立的 `MountEBSVolumes` RunCommand 文件，來掛載連接的 EBS 磁碟區。如果您未設定`--launch-template`參數，指令碼會建立範本，當 Auto Scaling 群組啟動新的 EC2 執行個體時，Auto Scaling 群組會自動連接 EBS 磁碟區，然後執行 `SetupAutomation`命令，將連接的磁碟區掛載至 layer 設定中設定的掛載點。 ## 哪裡可以找到 Chef 配方和掛載 EBS 磁碟區日誌？ OpsWorks 會將日誌交付至 S3 儲存貯體，您可以透過提供 `--command-logs-bucket` 參數的值來指定該儲存貯體。預設 S3 儲存貯體名稱的格式為：`aws-opsworks-stacks-application-manager-logs-account-id`。Chef 配方日誌存放在 `ApplyChefRecipes` 字首中。掛載 EBS 磁碟區日誌存放在 `MountEBSVolumes` 字首中。從堆疊遷移的所有層都會將日誌交付至相同的 S3 儲存貯體。 **注意** S3 儲存貯體的生命週期組態包含 30 天後刪除日誌的規則。如果您想要保留日誌超過 30 天，您必須在 S3 儲存貯體的生命週期組態中更新規則。目前，OpsWorks 只會記錄 Chef `setup`和`terminate`配方。 ## 哪裡可以找到遷移指令碼的偵錯日誌？指令碼會將偵錯日誌放在名為的儲存貯體中`aws-opsworks-stacks-transition-logs-account-id`。您可以在 S3 儲存貯體的 `migration_script` 資料夾中找到偵錯日誌，這些日誌位於與您遷移層名稱相符的資料夾下。 ## 遷移指令碼是否支援 CloudFormation 範本版本控制？指令碼會產生 CloudFormation 類型的 Systems Manager 文件，為您要遷移的層或堆疊建立替代項目。即使具有相同的參數，仍會再次執行指令碼，匯出先前匯出的層範本的新版本。範本版本存放在與指令碼日誌相同的 S3 儲存貯體中。 ## 我可以遷移多個層嗎？指令碼的 `--layer-id` 參數會在單一 layer 中傳遞。若要遷移多個層，請重新執行指令碼並傳入不同的 `--layer-id`。屬於相同 OpsWorks 堆疊的圖層會列在 Application Manager 中的相同應用程式下。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 在**應用程式**區段中，選擇**自訂應用程式**。 1. 選擇您的應用程式。應用程式名稱以開頭`app-stack-name-first-six-characters-stack-id`。 1. 從應用程式開始的最上層元素會顯示對應至 OpsWorks 堆疊的所有元件。這包括對應至 OpsWorks layer 的元件。 1. 選擇與 layer 對應的元件，以檢視 layer 的資源。代表 OpsWorks 層的元件也會在**自訂應用程式**區段中顯示為個別應用程式。 ## 如何建立`SecureString`參數？您可以使用 Systems Manager 來建立`SecureString`參數。如需如何建立 Systems Manager `SecureString` 參數的詳細資訊，請參閱*AWS Systems Manager 《使用者指南*》中的[建立 SecureString 參數 (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) 或[建立 Systems Manager 參數（主控台）](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html)。您必須提供 `SecureString` 參數做為 `--http-username`、 `--http-password`或 `--repo-private-key` 參數的值。 ## 如何保護新 Auto Scaling 群組中的執行個體免於終止事件？您可以將 `--enable-instance-protection` 參數設定為，`TRUE`並將`protected_instance`標籤金鑰新增至要保護免於終止事件的每個 EC2 執行個體，以保護執行個體。當您將 `--enable-instance-protection` 參數設定為 `TRUE`並新增`protected_instance`標籤金鑰時，指令碼會將自訂終止政策新增至新的 Auto Scaling 群組，並暫停`ReplaceUnhealthy`程序。具有`protected_instance`標籤索引鍵的執行個體會受到保護，免於發生下列終止事件： + 在事件中擴展 + 執行個體重新整理 + 重新平衡 + 執行個體生命週期上限 + 允許列出執行個體終止 + 終止和取代運作狀態不佳的執行個體 **注意** 您必須在要保護的執行個體上設定`protected_instance`標籤金鑰。標籤索引鍵區分大小寫。任何具有該標籤索引鍵的執行個體都會受到保護，無論標籤值為何。若要減少自訂終止政策的執行時間，您可以更新`default_sample_size`函數程式碼變數的值，以增加 Lambda 函數用來篩選受保護執行個體的預設執行個體數量。預設值為 15。如果您增加 `default_sample_size`，您可能需要增加配置給 Lambda 函數的記憶體，這會增加 Lambda 函數的成本。如需 AWS Lambda 定價的資訊，請參閱 [AWS Lambda 定價](https://aws.amazon.com/)。 ## 遷移指令碼可使用哪些負載平衡器？指令碼提供三個負載平衡器選項。 + （建議）建立新的 Application Load Balancer。根據預設，指令碼會建立新的 Application Load Balancer。您也可以將 `--lb-type` 參數設定為 `ALB`。如需 Application Load Balancer 的詳細資訊，請參閱 *Elastic Load Balancing 使用者指南*中的[什麼是 Application Load Balancer？](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)。 + 如果 Application Load Balancer 不是選項，請將 `--lb-type` 參數設定為來建立 Classic Load Balancer`Classic`。如果您選取此選項，連接至 OpsWorks layer 的現有 Classic Load Balancer 會與您的應用程式分開。如需 Application Load Balancer 的詳細資訊，請參閱 Elastic [ Load Balancer Balancing：Classic Load Balancer 使用者指南中的什麼是](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html) Classic Load Balancer？。 *Elastic Load Balancing* + 您可以將 `--lb-type` 參數設定為，以連接現有的負載平衡器`None`。 **重要** 建議您為 AWS OpsWorks Stacks 層建立新的 Elastic Load Balancing 負載平衡器。如果您選擇使用現有的 Elastic Load Balancing 負載平衡器，您應該先確認它未用於其他用途，也沒有連接的執行個體。在負載平衡器連接到 layer 之後，OpsWorks 會移除任何現有的執行個體，並設定負載平衡器，使其僅處理 layer 的執行個體。雖然在技術上可以使用 Elastic Load Balancing 主控台或 API 在將負載平衡器連接到 layer 之後修改負載平衡器的組態，但您不應該這麼做；變更不會永久存在。 **將現有的 OpsWorks layer 負載平衡器連接至 Auto Scaling 群組** 1. 執行遷移指令碼，並將 `--lb-type` 參數設定為 `None`。當值設為時`None`，指令碼不會複製或建立負載平衡器。 1. 在指令碼部署 CloudFormation 堆疊之後，更新 Auto Scaling 群組`Min``Max`和`Desired capacity`值，然後測試您的應用程式。 1. 選擇`Link to the template`顯示在指令碼的輸出中。如果您關閉終端機，請採取這些步驟來存取範本。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 選擇 **CloudFormation 堆疊**，然後選擇**範本程式庫**。 1. 選擇**由我擁有**，並找到您的範本。 1. 從 CloudFormation 範本中，從**動作**功能表中選擇**編輯**。 1. 更新 CloudFormation 範本`ApplicationAsg`資源區段中的 `LabelBalancerNames` 屬性。 ``` ApplicationAsg: DependsOn: CustomTerminationLambdaPermission Properties: #(other properties in ApplicationAsg to remain unchanged) LoadBalancerNames: - load-balancer-name HealthCheckType: ELB ``` 1. 如果您希望 Auto Scaling 群組執行個體的運作狀態檢查也使用負載平衡器的運作狀態檢查，請移除以下區段`HealthCheckType`並輸入 `ELB`。如果您只需要 EC2 運作狀態檢查，則不需要變更範本。 1. 儲存您的變更。儲存會建立新的範本預設版本。如果這是您第一次執行 layer 的指令碼，以及第一次在主控台中儲存變更，則較新版本為 2。 1. 從**動作 **中，選擇**佈建堆疊**。 1. 確認您想要使用範本的預設版本。請務必選取**選取現有的堆疊**，然後選擇要更新的 CloudFormation 堆疊。 1. 針對每個後續頁面選擇**下一步**，直到您看到**檢閱和佈建**頁面為止。在**檢閱和佈建**頁面上，選擇**我確認 AWS CloudFormation 可能會使用自訂名稱建立 IAM 資源****，而且我了解所選範本中的變更可能會導致 AWS CloudFormation 更新或移除現有 AWS 資源。** 1. 選擇 **Provision stack** (佈建堆疊)。如果您需要復原更新，請執行下列步驟。 1. 選擇**動作**，然後選擇**佈建堆疊**。 1. 選擇**挑選其中一個現有版本**，然後選擇先前的範本版本。 1. 選擇**選取現有堆疊**，然後選擇要更新的 CloudFormation 堆疊。 ## 自訂技術指南設定配方是否已遷移？設定自訂技術指南不支援在設定事件期間執行。指令碼會遷移自訂技術指南設定配方，並為您建立 Systems Manager Automation Runbook。不過，您必須手動執行配方。執行下列步驟來執行您的設定配方。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 在**應用程式**區段中，選擇**自訂應用程式**。 1. 選擇您的應用程式。應用程式名稱開頭為 `app-stack-name`。 1. 選擇**資源**，然後選擇設定 Runbook。**** 1. 選擇**執行自動化**。 1. 選擇您要執行設定配方的執行個體 IDs，然後選擇**執行**。 ## 我可以在新建立的執行個體上執行部署和取消部署配方嗎？指令碼可以根據您 layer 的組態建立三個可能的 Automation Runbook。 + 設定 + 設定 + 終止指令碼也可以建立下列 Systems Manager 參數，其中包含`AWS-ApplyChefRecipes Run Command`文件的輸入值。 + 設定 + 部署 + 設定 + Undeploy (解除部署) + 終止發生橫向擴展事件時，安裝 Automation Runbook 會自動執行。這包括從原始 OpsWorks 層設定和部署自訂技術指南配方。發生縮減事件時，終止 Automation Runbook 會自動執行。終止 Automation Runbook 包含來自原始 OpsWorks layer 的關機配方。如果您想要手動執行取消部署或設定配方，請執行下列步驟。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 在**應用程式**區段中，選擇**自訂應用程式**。 1. 選擇您的應用程式。應用程式名稱以開頭`app-stack-name-first-six-characters-stack-id`。Application Manager 會開啟**概觀**索引標籤。 1. 選擇**資源**，然後選擇設定 Automation Runbook。 1. 選擇**執行自動化**。 1. 如需 `applyChefRecipesPropertiesParameter` Automation Runbook 輸入參數，請參閱正確的 Systems Manager 參數。Systems Manager 參數名稱遵循格式 `/ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event` ，其中*事件*的值為 `Configure`、或 `Deploy`，`Undeploy`取決於您要執行的配方。 1. 選擇您要執行配方的執行個體 IDs，然後選擇**執行**。 ## 我可以變更 Auto Scaling 群組跨越哪些子網路嗎？根據預設，Auto Scaling 群組會跨越 OpsWorks 堆疊 VPC 中的所有子網路。若要更新要跨越哪些子網路，請執行下列步驟。 1. 選擇`Link to the template`顯示在指令碼的輸出中。如果您關閉終端機，請採取這些步驟來存取範本。 1. 在 https：//[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) 開啟 Systems Manager 主控台。 1. 在導覽窗格中，選擇 **Application Manager**。 1. 選擇 **CloudFormation 堆疊**，然後選擇**範本程式庫**。 1. 選擇**由我擁有**，並找到您的範本。 1. 在**動作**中，選擇**佈建堆疊**。 1. 確認您想要使用預設範本。選擇**選取現有堆疊**，然後選擇要更新的 CloudFormation 堆疊。 **注意** 如果您在 `--provision-application` 參數設定為的情況下執行指令碼`FALSE`，則必須建立新的 CloudFormation 堆疊。 1. 針對 `SubnetIDs` 參數，提供您希望 Auto Scaling 群組跨越IDs 的逗號分隔清單。 1. 選擇**下一步**，直到您看到**檢閱和佈建**頁面為止。 1. 在**檢閱和佈建**頁面上，選擇**我確認 CloudFormation 可能會使用自訂名稱建立 IAM 資源****，而且我了解所選範本中的變更可能會導致 CloudFormation 更新或移除現有 AWS 資源**。 1. 選擇 **Provision stack** (佈建堆疊)。 # 疑難排解本節包含一些常見問題，以及這些問題的建議解決方案。 **Topics** + [提供的委託人無效](#w2ab1c14c43c21b7) + [啟用 Auto Scaling 群組保護的執行個體時，無法刪除 CloudFormation 堆疊](#w2ab1c14c43c21b9) + [提供現有 S3 儲存貯體和字首時存取遭拒錯誤](#w2ab1c14c43c21c11) ## 提供的委託人無效 **問題：**您收到錯誤訊息，指出您提供的委託人無效。 **原因：**這是因為 Auto Scaling 群組沒有服務角色。 **解決方案：**在發生錯誤的區域中建立 Auto Scaling 群組。建立 Auto Scaling 群組會為您的自訂終止政策建立必要的服務連結角色。 ## 啟用 Auto Scaling 群組保護的執行個體時，無法刪除 CloudFormation 堆疊 **問題：** `--enable-instance-protection` 參數設定為 `TRUE`，且 Auto Scaling 群組的某些 EC2 執行個體會受到`protected_instance`標籤金鑰的保護，以防止您的 CloudFormation 堆疊完全刪除。 **原因：**EC2 執行個體具有`protected_instance`標籤索引鍵，可保護它們免於終止事件。 **解決方案：**從 EC2 執行個體移除`protected_instance`標籤金鑰。這可讓 Auto Scaling 群組縮減規模。Auto Scaling 群組縮減後，您可以刪除 CloudFormation 堆疊。 ## 提供現有 S3 儲存貯體和字首時存取遭拒錯誤 **問題：**當您提供現有的 S3 儲存貯體和字首時，會收到`AccessDenied`錯誤。 **原因：**S3 儲存貯體政策不提供將負載平衡器日誌交付至儲存貯體的必要許可。 **解決方案：**更新 S3 儲存貯體政策，以允許指令碼將負載平衡器存取日誌交付至儲存貯體。如需如何更新儲存貯體政策的詳細資訊，請參閱《Elastic Load Balancing：[Application Load Balancer 使用者指南》中的啟用 Application Load Balancer 的存取日誌](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/enable-access-logging.html)。 *Elastic Load Balancing* # 使用就地 AWS OpsWorks Stacks 分離工具 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。本節說明如何使用就地 AWS OpsWorks Stacks 分離工具將您的 OpsWorks 執行個體與 OpsWorks Stacks 服務分離。您分離的執行個體將保留在中 AWS 帳戶，但您將無法再使用 OpsWorks 管理它們。反之，您將使用 Amazon EC2 AWS Systems Manager或任何 EC2 相容方法來設定和管理執行個體。在高階，分離程序涉及下列步驟： 1. 此工具會執行驗證檢查，以確保資源已準備好進行分離。 1. 工具會從 OpsWorks 堆疊匯出自訂 JSON，並將其儲存為 Amazon S3 中的物件。 1. 此工具會建立 Systems Manager Automation 文件，代表每個 OpsWorks Stacks 生命週期事件。 1. 此工具會為正在分離的所有執行個體建立 AWS Service Catalog AppRegistry 目錄，並將任何 Elastic Load Balancing (ELB) 負載平衡器從 OpsWorks 層分離。 1. 最後，工具會分離和取消註冊其他資源，包括 Amazon Relational Database Service (Amazon RDS) 執行個體。 ## 程序的運作方式就地分離工具提供以下 3 個命令和精靈，例如引導您完成一系列步驟以檢查和設定執行個體，然後再繼續分離 layer 的體驗。 | 命令 | Description | | --- | --- | | `handle-prerequisites` | 此命令會分析 layer 中的所有執行個體是否符合分離資格，並解決先決條件。執行個體在 OpsWorks 中必須處於運作狀態、無法具有時間或負載型自動擴展器，且必須安裝最新的 OpsWorks Agent 版本。此外，命令會檢查所有執行個體是否具有支援 SSM Agent 所需的許可，以及是否已安裝最新的 SSM Agent 版本。如果 SSM 代理程式不存在，則命令會安裝該 SSM 代理程式，如果它未使用最新版本，則會更新 SSM 代理程式。命令也會新增任何必要的許可。 | | `detach` | 此命令會分離指定 layer 的所有 OpsWorks 執行個體。首先，命令會執行先決條件檢查，以確保 layer 符合分離資格。如果您不想解決先決條件，您可以選擇強制分離。接下來，命令會指出透過 OpsWorks 標記 APIs 或透過從層和堆疊傳播標籤新增至執行個體的所有標籤都會保留。您可以在分離完成後，使用相關的 EC2 APIs 移除任何這些標籤。然後，命令會檢查您是否要將 Chef 相關組態匯出至 SSM 參數。如果您將 Classic Load Balancer 連接到 layer，命令會詢問是否可以分離負載平衡器，以防止任何停機時間。 | | `cleanup` | 此命令會從您的帳戶刪除 OpsWorks 中的所有實體。它會終止執行個體並刪除所有堆疊。這應該用於不再需要的資源，做為清除帳戶的最後一步。我們建議您在執行 `cleanup`命令之前，先執行新的設定幾天。這可確保堆疊中任何必要的組態在需要時隨時可用。 | ## 限制就地分離工具的主要目的是安全地分離 OpsWorks Stacks 執行個體。本節摘要說明工具的限制。 + **Windows SSM 代理程式** – 如果 SSM 代理程式未安裝在執行個體上，您將需要手動安裝它。如果代理程式未更新至最新版本，則同樣適用。 + **Time/Load Auto Scaling 執行個體** – 分離工具不支援已啟用 Auto Scaling 的執行個體。您必須在要分離的執行個體上停用 Auto Scaling。 + **許可** – 分離工具不會建立或產生 OpsWorks 主控台**許可**頁面上指定的 IAM 實體。 + **應用程式** – 分離工具不會在 OpsWorks 外部建立或產生應用程式。 ## 開始使用 ### 步驟 1：確認符合先決條件分離就地工具的所有 3 個命令都是 Python 指令碼，您可以在本機、EC2 執行個體或使用執行[AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html#how-to-get-started)。 AWS CloudShell 是一種瀏覽器型 shell，可讓您以命令列方式存取 select. AWS CloudShell comes 中預先安裝熱門工具 AWS （例如 AWS CLI 和 Python) 的資源 AWS 區域。使用時 AWS CloudShell，您可以使用用來登入主控台的相同登入資料。本演練假設您使用 AWS CloudShell。 ### 步驟 2：下載指令碼 1. 執行下列命令，下載包含遷移指令碼和所有相關檔案的 zip 檔案： ``` aws s3api get-object \ --bucket detach-in-place-bucket-prod-us-east-1 \ --key detach_in_place_script.zip detach_in_place_script.zip ``` 1. 執行下列命令來解壓縮檔案。 ``` unzip detach_in_place_script.zip ``` 檔案解壓縮後，即可使用下列檔案： + README.md + LICENSE + NOTICE + requirements.txt + TODO.py 1. 如有必要，請執行下列命令`pipenv`來安裝。 ``` pip install pipenv ``` ### 步驟 3：執行指令碼首先，設定您的環境，以便您可以執行下列命令來執行指令碼。 ``` pipenv install -r requirements.txt pipenv shell ``` 然後，檢閱指令碼參數。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/using-stacks-detach-tool.html) 您可以使用選項執行命令`detach`，來查看 `handle-prerequisites`和 `cleanup` 命令的可用`--help`選項，如下所示： ``` python3 layer_detacher.py detach --help python3 layer_detacher.py handle-prerequisites --help python3 layer_detacher.py cleanup --help ``` 您現在已準備好開始使用。下列範例示範如何針對不同的使用案例執行命令。 **Topics** + [範例 1：檢查 layer 是否符合所有先決條件，且符合分離資格](#using-stacks-detach-tool-step3-ex1) + [範例 2：分離 layer 的所有執行個體](#using-stacks-detach-tool-step3-ex2) + [範例 3：分批分離 layer 的所有執行個體](#using-stacks-detach-tool-step3-ex3) + [範例 4：清除 layer 的所有資源並刪除 layer](#using-stacks-detach-tool-step3-ex4) + [範例 5：清除堆疊的所有資源並刪除堆疊](#using-stacks-detach-tool-step3-ex5) #### 範例 1：檢查 layer 是否符合所有先決條件，且符合分離資格下列命令會讀取 OpsWorks layer （及其包含的執行個體）的相關資訊，並檢查是否符合下列先決條件： + 所有執行個體都在線上。 + 沒有 Load/Time Auto Scaling 執行個體。 + 所有執行個體都有最新的 OpsWorks 代理程式。 + 所有執行個體都已安裝並設定最新的 SSM Agent。 + 所有執行個體都有 SSH 金鑰對。 + 每個執行個體僅屬於一個 layer。 ``` python3 layer_detacher.py handle-prerequisites \ --layer-id opsworks-layer-id \ --region opsworks-stack-region ``` #### 範例 2：分離 layer 的所有執行個體下列命令會逐一查看 layer 的所有執行個體，檢查執行個體是否符合先決條件，並嘗試平行分離符合先決條件的所有執行個體。如果不符合一或多個先決條件，命令將為剩餘的不合規執行個體提供強制分離選項。分離任何執行個體之前，命令將： 1. 儲存自訂 JSON 並將其上傳至 S3。 1. 為 layer 的每個 OpsWorks 生命週期事件建立 SSM Automation 文件，並將自動化文件的執行日誌上傳至 S3。 1. 為所有將分離的執行個體建立 AppRegistry 應用程式。應用程式具有與其相關聯的資源群組，可存放所有分離的執行個體和資源。資源包括 SSM Automation 文件和 SSM 參數，其中包含生命週期事件和自訂 Chef 配方的相關資訊。 1. 如果存在 Classic Load Balancer。此命令只會修改 OpsWorks 資源。EC2 執行個體的狀態將保持不變。 ``` python3 layer_detacher.py detach \ --layer-id opsworks-layer-id \ --region opsworks-stack-region ``` #### 範例 3：分批分離 layer 的所有執行個體下列命令的作用與[上一個範例](#using-stacks-detach-tool-step3-ex2)相同。唯一的差別是它會分批分離執行個體。此命令只會修改 OpsWorks 資源。EC2 執行個體的狀態將保持不變。 ``` python3 layer_detacher.py detach \ --layer-id opsworks-layer-id \ --region opsworks-stack-region \ --batch-size 5 ``` #### 範例 4：清除 layer 的所有資源並刪除 layer 下列命令會逐一查看圖層的所有資源，並將其刪除。更詳細地說，它會停止和刪除 OpsWorks 和 EC2 中的所有執行個體，分離負載平衡器並取消註冊 Amazon RDS 執行個體、彈性 IPs和磁碟區。清除資源後，它會刪除 layer。此命令會刪除 OpsWorks 資源和 EC2 執行個體。如果您希望 EC2 執行個體保持不變，請在使用 `detach`命令之前使用 `cleanup`命令。如此一來，`cleanup`命令就會刪除所有剩餘的資源。 ``` python3 layer_detacher.py cleanup \ --layer-id opsworks-layer-id \ --region opsworks-stack-region ``` #### 範例 5：清除堆疊的所有資源並刪除堆疊下列命令會逐一查看所有圖層，然後逐一查看每個圖層的資源。對於每個 layer，命令會停止和刪除 OpsWorks 和 EC2 中的所有執行個體、分離負載平衡器，以及取消註冊 Amazon RDS 執行個體、彈性 IPs和磁碟區。然後，命令會刪除 layer。相同的程序將在屬於此堆疊的每個 layer 中執行。最後，刪除所有圖層後，堆疊將被移除。此命令會刪除 OpsWorks 資源和 EC2 執行個體。如果您希望 EC2 執行個體保持不變，請在使用 `detach`命令之前使用 `cleanup`命令。如此一來，`cleanup`命令就會刪除所有剩餘的資源。 ``` python3 layer_detacher.py cleanup \ --stack-id opsworks-stack-id \ --region opsworks-stack-region ``` ### 步驟 4：從 OpsWorks 分離後繼續操作您的資源執行 `detach`命令後，該工具會建立一個對應於分離層的新 AWS Service Catalog AppRegistry 應用程式。應用程式名稱遵循格式 `layer-name---layer-id`。它也會新增 `OpsWorksLayerId`標籤，以唯一識別符合分離層的應用程式。若要將新 AWS 資源新增至此應用程式（例如，新的 EC2 執行個體），您可以執行下列其中一項操作： 1. 使用 AppRegistry 應用程式的唯一應用程式標籤來標記資源：標籤索引鍵： `awsApplication` 值：`arn:aws:resource-groups:region:account-id:group/application-name/application-id>` 1. 執行 [https://docs.aws.amazon.com/cli/latest/reference/servicecatalog-appregistry/associate-resource.html](https://docs.aws.amazon.com/cli/latest/reference/servicecatalog-appregistry/associate-resource.html) 命令。此外，會為每個 AppRegistry 應用程式建立資源群組。資源群組包含下列標籤。 | 標籤鍵 | Value | | --- | --- | | `EnableAWSServiceCatalogAppRegistry` | `TRUE` | | `aws:servicecatalog:applicationName` | `application-name` | | `aws:servicecatalog:applicationId` | `application-id` | | `aws:servicecatalog:applicationArn` | `arn:aws:servicecatalog:region:account-id:/applications/application-id` | #### 在分離後執行任務下表提供分離後如何執行任務的相關資訊： | 任務 | Description | | --- | --- | | 執行生命週期事件 | 執行 `detach`命令並選取選項後，指令碼會建立符合 5 個 OpsWorks 生命週期事件的 5 個自動化文件。每個自動化文件的名稱都遵循此格式：`layer-id_lifecycle-event_automation_document`。若要模擬 Systems Manager 中的 OpsWorks 行為，您需要在佈建、終止 EC2 執行個體或部署/移除配方時手動觸發自動化執行。 | | 更新自訂 JSON | 堆疊和 layer 的自訂 JSON 會存放在分離期間指定的 S3 儲存貯體中，或者存放在建立的新 S3 儲存貯體中。為 JSON 檔案儲存的檔案名稱如下： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/using-stacks-detach-tool.html) | | 變更生命週期事件的執行清單 | 每個生命週期事件的執行清單會在對應的自動化文件中定義。若要變更執行清單，請在 AppRegistry 應用程式中尋找自動化文件，並修改 `RunList` 參數。更新配方和技術指南的程序保持不變`AWS-ApplyChefRecipes`，因為自動化文件觸發的支援與 OpsWorks 相同的來源。 | | 管理自動修復/自動擴展 | 當您分離執行個體時，OpsWorks 代理程式會解除安裝。如果沒有代理程式，OpsWorks 就無法自動修復或取代運作狀態不佳的執行個體，也無法自動擴展機群。若要繼續自動擴展和取代失敗的執行個體，請建立 Amazon EC2 Auto Scaling 群組。當 Amazon EC2 偵測到運作狀態不佳且需要取代的執行個體時，群組將啟動新的執行個體，以維持其所需的容量。 | | 管理Load Balancer | 如果您的 layer 使用 Classic Load Balancer，`detach`命令會在取消註冊執行個體之前將其分離。這是為了確保所有 ELB 執行個體關聯在整個分離過程中都保留在 Amazon EC2 上，因此導致零停機時間。程序完成後，您將能夠在 EC2 上管理 ELB。 | | 連線到您的執行個體 | 當您執行 `handle-prerequisites`或 `detach`命令時，會發生兩個檢查： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/using-stacks-detach-tool.html) 這些命令也提供更新 SSM Agent 和新增必要許可的選項，讓您可以使用 Session Manager 連線到執行個體。如果 SSH 金鑰存在，您也可以選擇在執行個體中使用 SSH。 | #### 使用 Systems Manager Application Manager 執行個體索引標籤分離後，您可以在 Application Manager 執行個體[索引標籤上檢視和管理執行個體](https://docs.aws.amazon.com/systems-manager/latest/userguide/application-manager-working-instances.html)。 **執行個體**索引標籤提供應用程式 EC2 執行個體的彙總資訊，例如其狀態、運作狀態和最後一個命令狀態。使用此標籤，您可以檢視個別執行個體的詳細資訊，例如命令歷史記錄、警示狀態、Systems Manager 代理程式運作狀態等。**執行個體**索引標籤也提供各種動作，例如能夠套用 Chef 配方、啟動或停止執行個體，或從 Auto Scaling 群組新增或移除執行個體。 # Stacks OpsWorks 入門 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 提供一組豐富的可自訂元件，您可以混合搭配，以建立符合您特定用途的堆疊。新使用者的挑戰是了解如何將這些元件組合成運作堆疊並有效管理它。以下是開始使用的方法。 | 如果您想要… | 完成本演練： | | --- | --- | | 盡快建立範例堆疊 | [入門：範例](gettingstarted-intro.md) | | 實驗 Linux 式堆疊 | [入門：Linux](gettingstarted-linux.md) | | 實驗 Windows 式堆疊 | [入門：Windows](gettingstarted-windows.md) | | 了解如何建立自己的 Chef 技術指南 | [入門：技術指南](gettingstarted-cookbooks.md) | 如果您有現有的運算資源 - Amazon EC2 執行個體，甚至是在您自己的硬體上執行*的現場部署*執行個體 - 您可以將[它們與使用 Stacks 建立的執行個體整合到堆疊](registered-instances.md)中。 OpsWorks 然後，您可以使用 OpsWorks Stacks 以群組形式管理所有相關執行個體，無論它們的建立方式為何。 ## 區域支援您可以全域存取 OpsWorks Stacks；您也可以全域建立和管理執行個體。使用者可以將 OpsWorks Stacks 執行個體設定為在 AWS GovCloud （美國西部）和中國（北京） AWS 區域以外的任何區域中啟動。若要使用 OpsWorks Stacks，執行個體必須能夠連線至下列其中一個 OpsWorks Stacks 執行個體服務 API 端點。只有在已建立的區域中才能管理資源。在一個區域端點中建立的資源為不可用，也無法複製到另一個區域端點。您可以下列任意區域內啟動執行個體。 + 美國東部 (俄亥俄) 區域 + 美國東部 (維吉尼亞北部) 區域 + 美國西部 (奧勒岡) 區域 + 美國西部 (加利佛尼亞北部) 區域 + 加拿大（中部）區域（僅限 API，不適用於在中建立的堆疊 AWS 管理主控台。) + 亞太地區 (孟買) 區域 + 亞太區域 (新加坡) 區域 + 亞太 (雪梨) 區域 + 亞太 (東京) 區域 + 亞太區域 (首爾) 區域 + 歐洲 (法蘭克福) 區域 + 歐洲 (愛爾蘭) 區域 + 歐洲 (倫敦) 區域 + 歐洲 (巴黎) 區域 + 南美洲 (聖保羅) 區域 # 範例堆疊入門 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本演練說明如何使用 OpsWorks Stacks 快速建立範例 Node.js 應用程式環境，只要按幾下滑鼠，無需編寫程式碼。完成後，您會有一個執行 Chef 12 的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體、Node.js HTTP 伺服器，以及可用來與 Twitter 互動並在網頁上留下評論的 Web 應用程式。 **注意** 由於完成此演練會自動建立類型為 c3.large 的執行個體，因此您無法在 [AWS 免費方案](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-limits.html)中使用此演練或 OpsWorks Stacks 中的**範例堆疊**建立工具。雖然在 VPC **中使用範例堆疊**建立工具會建立 t2.medium 執行個體，但 VPCs 目前無法在 [AWS 免費方案](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-limits.html)中使用。 # 步驟 1：完成事前準備 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您必須先完成下列步驟，才能開始演練。這些設定步驟包括註冊 AWS 帳戶、建立管理使用者，以及將存取許可指派給 OpsWorks Stacks。 **Topics** + [註冊 AWS 帳戶](#sign-up-for-aws) + [建立具有管理存取權的使用者](#create-an-admin) + [指派服務存取許可](#gettingstarted-intro-prerequisites-permissions) ## 註冊 AWS 帳戶如果您沒有 AWS 帳戶，請完成下列步驟來建立一個。 **註冊 AWS 帳戶** 1. 開啟 [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)。 1. 請遵循線上指示進行。部分註冊程序需接收來電或簡訊，並在電話鍵盤輸入驗證碼。當您註冊時 AWS 帳戶，*AWS 帳戶根使用者*會建立。根使用者有權存取該帳戶中的所有 AWS 服務和資源。作為安全最佳實務，請將管理存取權指派給使用者，並且僅使用根使用者來執行[需要根使用者存取權的任務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 AWS 會在註冊程序完成後傳送確認電子郵件給您。您可以隨時登錄 [https://aws.amazon.com/](https://aws.amazon.com/) 並選擇**我的帳戶**，以檢視您目前的帳戶活動並管理帳戶。 ## 建立具有管理存取權的使用者註冊後 AWS 帳戶，請保護 AWS 帳戶根使用者、啟用 AWS IAM Identity Center和建立管理使用者，以免將根使用者用於日常任務。 **保護您的 AWS 帳戶根使用者** 1. 選擇**根使用者**並輸入 AWS 帳戶您的電子郵件地址，以帳戶擁有者[AWS 管理主控台](https://console.aws.amazon.com/)身分登入。在下一頁中，輸入您的密碼。如需使用根使用者登入的說明，請參閱 *AWS 登入使用者指南*中的[以根使用者身分登入](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)。 1. 若要在您的根使用者帳戶上啟用多重要素驗證 (MFA)。如需說明，請參閱《*IAM 使用者指南*》中的[為您的 AWS 帳戶根使用者（主控台）啟用虛擬 MFA 裝置](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)。 **建立具有管理存取權的使用者** 1. 啟用 IAM Identity Center。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[啟用 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)。 1. 在 IAM Identity Center 中，將管理存取權授予使用者。如需使用 IAM Identity Center 目錄做為身分來源的教學課程，請參閱*AWS IAM Identity Center 《使用者指南*》中的[使用預設值設定使用者存取 IAM Identity Center 目錄](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html)。 **以具有管理存取權的使用者身分登入** + 若要使用您的 IAM Identity Center 使用者簽署，請使用建立 IAM Identity Center 使用者時傳送至您電子郵件地址的簽署 URL。如需使用 IAM Identity Center 使用者登入的說明，請參閱*AWS 登入《使用者指南*》中的[登入 AWS 存取入口網站](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)。 **指派存取權給其他使用者** 1. 在 IAM Identity Center 中，建立一個許可集來遵循套用最低權限的最佳實務。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[建立許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-a-permission-set.html)。 1. 將使用者指派至群組，然後對該群組指派單一登入存取權。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[新增群組](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)。 ## 指派服務存取許可將 OpsWorks `AWSOpsWorks_FullAccess`和 `AmazonS3FullAccess`許可新增至您的角色或使用者，以啟用 Stacks 服務的存取權（以及 OpsWorks Stacks 依賴的相關服務）。如需新增許可的詳細資訊，請參閱[新增 IAM 身分許可（主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)。您現已完成所有設定步驟，可[開始本演練](gettingstarted-intro-create-stack.md)。 # 步驟 2：建立堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在此步驟中，您會使用 OpsWorks Stacks 主控台來建立堆疊。*堆疊*是執行個體（例如 Amazon EC2 執行個體）和相關 AWS 資源的集合，這些資源具有共同目的且您想要一起管理。(如需詳細資訊，請參閱 [堆疊](workingstacks.md)。) 本演練只有一個執行個體。在您開始此步驟之前，請先完成[事前準備](gettingstarted-intro-prerequisites.md)。 **建立堆疊** 1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) 開啟 OpsWorks 主控台。 1. 執行下列任一作業 (若適用的話)： + 如果顯示**歡迎使用 OpsWorks Stacks** 頁面，請選擇**新增您的第一個堆疊**或**新增您的第一個 Stacks OpsWorks 堆疊** （這兩個選項都執行相同的動作）。即會顯示 **Add stack (新增堆疊)** 頁面。 + 若顯示 **OpsWorks Dashboard (OpsWorks 儀表板)** 頁面，請選擇 **Add stack (新增堆疊)**。即會顯示 **Add stack (新增堆疊)** 頁面。 1. 在顯示的 **Add stack (新增堆疊)** 頁面中，如果尚未選擇，請選擇 **Sample stack (範例堆疊)**。 1. 為已選擇 **Linux** 的 **Operating system type (作業系統類型)**，選擇 **Create stack (建立堆疊)**： ![\[Add stack interface with options for Sample stack, Chef 12 stack, and Chef 11 stack.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-add-stack-console.png) 1. OpsWorks Stacks 會建立名為 **My Sample Stack (Linux) 的堆疊**。 OpsWorks Stacks 也會新增所有必要的元件，以將應用程式部署至堆疊： + *layer* 是一組執行個體的藍圖。它會指定諸如執行個體的設定、資源、安裝的套件和安全群組等項目。(如需詳細資訊，請參閱 [層](workinglayers.md)。) 此 layer 名為 **Node.js App Server (Node.js 應用程式伺服器)**。 + 在這種情況下，「執行個體」**是 Amazon Linux 2 EC2 執行個體。(如需執行個體的詳細資訊，請參閱[執行個體](workinginstances.md)。) 該執行個體的主機名稱是 **nodejs-server1**。 + 「應用程式」**是在執行個體上執行的程式碼。(如需應用程式的詳細資訊，請參閱[應用程式](workingapps.md)。) 此應用程式名為 **Node.js Sample App (Node.js 範例應用程式)**。 1. Stacks OpsWorks 建立堆疊後，請選擇**探索範例堆疊**以顯示**我的範例堆疊 (Linux)** 頁面（如果您完成此演練多次，則**我的範例堆疊 (Linux)** 之後可能會有序號，例如 **2** 或 **3**)： ![\[Checklist showing completed steps for setting up a sample stack with Node.js App Server.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-add-stack-explore-console.png) 在[下一個步驟](gettingstarted-intro-start-instance.md)中，您會啟動執行個體並將應用程式部署到執行個體。 # 步驟 3：啟動執行個體並部署應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在您有執行個體和應用程式，可啟動執行個體並將應用程式部署到執行個體。 **啟動執行個體並部署應用程式** 1. 執行以下任意一項： + 在服務導覽窗格中，選擇 **Instances (執行個體)**： ![\[Menu options including Stack, Layers, and Instances with Instances circled in red.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-nav-pane-console.png) + 在 **My Sample Stack (Linux)** 頁面上，選擇 **Instances (執行個體)**： ![\[AWS stack interface showing layers and instances, with one Node.js App Server instance stopped.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-instances-console.png) 1. 在 **Instances (執行個體)** 頁面上，針對 **Node.js App Server (Node.js 應用程式伺服器)** 的 **nodejs-server1**，選擇 **start (開始)**： ![\[Node.js App Server interface showing a stopped instance with start and delete options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-start-instance-console.png) 1. 請在 **online (線上)** 圓圈變成亮綠色之後，再繼續。(如果看到故障訊息，請參考[偵錯和故障診斷指南](troubleshoot.md)。) 1. 當執行個體設定時， OpsWorks Stacks 會將應用程式部署到執行個體。 1. 繼續之前，您的結果應該類似下列螢幕擷取畫面 (如果您收到故障訊息，建議您參考[偵錯和故障診斷指南](troubleshoot.md))： ![\[OpsWorks instance dashboard showing one online Node.js App Server instance.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-instance-started-console.png) 您的執行個體現有已部署到執行個體的應用程式。在[下一個步驟](gettingstarted-intro-test-app.md)中，您要測試執行個體上的應用程式。 # 步驟 4：測試執行個體上已部署的應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。測試執行個體上的應用程式部署結果。 **測試執行個體上的部署** 1. 在上一個步驟顯示的 **Instances (執行個體)** 頁面中，針對 **Node.js App Server (Node.js 應用程式伺服器)** 之 **nodejs-server1** 的 **Public IP (公有 IP)**，選擇 IP 地址。 ![\[OpsWorks instance dashboard showing one online Node.js server in us-west-2a.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-instance-ip-console.png) 1. 在賀辭網頁的 **Leave a comment (留下評論)** 文字方塊中輸入評論，然後選擇 **Send (傳送)** 測試應用程式。應用程式會將您的評論新增到網頁。繼續留下評論，並依您需要隨時選擇 **Send (傳送)**。 ![\[Congratulatory message for deploying first app with AWS OpsWorks, featuring stylized landmarks.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-test-app.png) 1. 如果您有 Twitter 帳戶，請選擇 **Tweet (推文)** 或 **Follow @AWSOpsWorks (關注 @AWSOpsWorks)**，然後遵循畫面指示發佈有關此應用程式的推文或關注 @AWSOpsWorks。您現已成功測試執行個體上所部署的應用程式。在其餘步驟中，您可以使用 OpsWorks Stacks 主控台來探索堆疊及其元件的設定。在[下一個步驟](gettingstarted-intro-explore-stack.md)中，您可以從檢查堆疊設定開始您的探索。 # 步驟 5：探索堆疊的設定 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。檢查 OpsWorks Stacks 如何設定堆疊。 **顯示堆疊的設定** 1. 在服務導覽列中，選擇 **Stack (堆疊)**。即會顯示 **My Sample Stack (Linux)** 頁面。 1. 選擇 **Stack Settings (堆疊設定)**。即會顯示 **Settings My Sample Stack (Linux) (設定 My Sample Stack (Linux))** 頁面： ![\[Settings page for My Sample Stack (Linux) showing configuration details like region and OS.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-stack-page-console.png) 若要進一步了解許多設定，請選擇 **Edit (編輯)**，然後將滑鼠的游標移到每項設定上。(並非所有設定在畫面上皆有描述。) 如需這些設定的詳細資訊，請參閱 [建立新的堆疊](workingstacks-creating.md)。若要探索本演練中使用的 Chef 技術指南，請開啟 GitHub 的 [opsworks-linux-demo-cookbooks-nodejs](https://github.com/awslabs/opsworks-linux-demo-cookbook-nodejs) 儲存庫。在[下一個步驟](gettingstarted-intro-explore-layer.md)中，您可以探索 layer 的設定。 # 步驟 6：探索 Layer 的設定 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。檢查 OpsWorks Stacks 如何設定 layer。 **顯示 layer 的設定** 1. 在服務導覽窗格中，選擇 **Layers (Layer)**。即會顯示 **Layers (Layer)** 頁面。 1. 選擇 **Node.js App Server (Node.js 應用程式伺服器)**。即會顯示 **Layer Node.js App Server (Layer Node.js 應用程式伺服器)** 頁面。若要查看 layer 的設定，請選擇 **General Settings (一般設定)**、**Recipes (配方)**、**Network (網路)**、**EBS Volumes (EBS 磁碟區)** 和 **Security (安全性)**： ![\[Node.js App Server layer settings with name, short name, and configuration options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-layers-page-console.png) 若要進一步了解許多設定，請選擇 **Edit (編輯)**，然後將滑鼠的游標移到每項設定上。(並非所有設定在畫面上皆有描述。) 如需這些設定的詳細資訊，請參閱 [編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md)。在[下一個步驟](gettingstarted-intro-explore-instance.md)中，您可以探索執行個體的設定和日誌。 # 步驟 7：探索執行個體的設定和日誌 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。檢查 OpsWorks Stacks 用來啟動執行個體的設定。您也可以檢查 Stacks OpsWorks 建立的執行個體日誌。 **顯示執行個體的設定和日誌** 1. 在服務導覽窗格中，選擇 **Instances (執行個體)**。即會顯示 **Instances (執行個體)** 頁面。 1. 針對 **Node.js App Server (Node.js 應用程式伺服器)**，選擇 **nodejs-server1**。即會顯示執行個體的 properties (屬性) 頁面。 ![\[Details of a stopped Node.js server instance on AWS, showing configuration and resource information.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-instance-details-page-console.png) 1. 若要探索執行個體日誌，請在 **Logs (日誌)** 區段中，針對 **Log (日誌)**，選擇 **show (顯示)**。 ![\[Log entries showing configure and setup commands with timestamps and durations.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-instance-details-logs-console.png) 1. OpsWorks Stacks 會在單獨的 Web 瀏覽器索引標籤中顯示日誌。 ![\[Log output showing AWS OpsWorks instance startup and chef-client initialization process.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-instance-log-console.png) 若要進一步了解某些執行個體設定所代表的意義，請返回 **nodejs-server1** 頁面，選擇 **Stop (停止)**，然後在您看到確認訊息時，選擇 **Stop (停止)**。在**狀態**從**停止**變更為**停止**後選擇**編輯**，然後將滑鼠游標移至每個設定。(並非所有設定在畫面上皆有描述。) 如需這些設定的詳細資訊，請參閱 [將執行個體新增至 Layer](workinginstances-add.md)。完成檢閱設定後，選擇 **Start (啟動)** 重新啟動執行個體，然後等待 **Status (狀態)** 變更為 **online (線上)**。否則，稍後您將無法測試應用程式，因為執行個體會維持停止狀態。 **注意** 如果您想要登入執行個體以進一步探索，您必須先向 OpsWorks Stacks 提供公有 SSH 金鑰的相關資訊（您可以使用 ssh-keygen 或 PuTTYgen 等工具建立），然後您必須在 **My Sample Stack (Linux) **堆疊上設定許可，讓使用者能夠登入執行個體。如需說明，請參閱 [註冊使用者的公有 SSH 金鑰](security-settingsshkey.md) 與 [使用 SSH 登入](workinginstances-ssh.md)。在[下一個步驟](gettingstarted-intro-explore-app.md)中，探索應用程式的設定。 # 步驟 8：探索應用程式的設定 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。檢查 OpsWorks Stacks 用於應用程式的設定。 **顯示應用程式的設定** 1. 在服務導覽窗格中，選擇 **Apps (應用程式)**。即會顯示 **Apps (應用程式)** 頁面。 1. 選擇 **Node.js Sample App (Node.js 範例應用程式)**。即會顯示 **App Node.js Sample App (應用程式 Node.js 範例應用程式)** 頁面： ![\[Node.js Sample App settings page showing app details, source, and data sources.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-app-details-page-console.png) 若要了解某些設定代表的意義，請選擇 **Edit (編輯)**，然後將滑鼠的游標移到每項設定上。(並非所有設定在畫面上皆有描述。) 如需這些設定的詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。在[下一個步驟](gettingstarted-intro-explore-monitoring.md)中，您可以探索 layer 監控報告。 # 步驟 9：探索 Layer 監控報告 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。檢查 OpsWorks Stacks 針對 layer 運算效能產生的報告。 **顯示 layer 監控報告** 1. 在服務導覽窗格中，選擇 **Monitoring (監控)**。即會顯示 **Monitoring Layers (監控 Layer)** 頁面。 1. 若要探索其他檢視，請選擇 **CPU**、**Memory (記憶體)**、**Load (載入)** 和時間旁的箭頭： ![\[Monitoring Layers dashboard showing CPU, Memory, Load, and Processes metrics with expandable options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-monitoring-page-console.png) 如需這些和其他報告的資訊，請參閱[使用 Amazon CloudWatch](monitoring-cloudwatch.md)和[監控](monitoring.md)。在[下一個步驟](gettingstarted-intro-explore-more.md)中，您可以探索其他堆疊設定。 # 步驟 10：探索其他堆疊設定 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在這個步驟中，您可以檢查其他堆疊設定。 OpsWorks Stacks 不會執行個別部署、不會佈建其他資源，也不會在此堆疊中調整其他許可，因此在**部署和命令**、**資源**和**許可**頁面上沒有太多興趣。如果您還是要查看這些設定，請分別選擇服務導覽窗格中的 **Deployments (部署)**、**Resources (資源)** 和 **Permissions (許可)**。如需要這些頁面代表意義的詳細資訊，請參閱[部署應用程式](workingapps-deploying.md)、[資源管理](resources.md)和[管理使用者許可](opsworks-security-users.md)。在[下一個步驟](gettingstarted-intro-clean-up.md)中，您可以清除用於本演練 AWS 的資源。此步驟為選用。當您繼續進一步了解 Stacks OpsWorks 時，建議您繼續使用這些 AWS 資源。不過，保留這些 AWS 資源可能會對 AWS 您的帳戶產生持續費用。如果您想要將這些 AWS 資源保留以供日後使用，您現在已完成本演練，您可以直接跳到 [後續步驟](gettingstarted-intro-next-steps.md)。 # 步驟 11 (選用)：清理 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。為了避免對 AWS 您的帳戶產生額外費用，您可以刪除本演練 AWS 所使用的應用程式和資源，包括執行個體和 Stacks OpsWorks 堆疊。（如需詳細資訊，請參閱 [OpsWorks 定價](https://aws.amazon.com/opsworks/pricing/)。) 不過，當您繼續進一步了解 Stacks OpsWorks 時，建議您繼續使用這些 AWS 資源。如果您想要讓這些 AWS 資源保持可用，您現在已完成本演練，您可以跳至 [後續步驟](gettingstarted-intro-next-steps.md)。存放在您為此逐步解說建立的資源裡的內容，可包含個人識別資訊。如果您不希望再將此資訊存放在 AWS，請遵循本主題的步驟。 **從堆疊刪除應用程式** 1. 在服務導覽窗格中，選擇 **Apps (應用程式)**。即會顯示 **Apps (應用程式)** 頁面。 1. 針對 **Node.js Sample App (Node.js 範例應用程式)** 的 **Actions (動作)**，選擇 **delete (刪除)**。在您看見確認訊息時，選擇 **Delete (刪除)**。刪除應用程式時，您會看到 **No apps (無應用程式)** 訊息。 **刪除堆疊的執行個體** 1. 在服務導覽窗格中，選擇 **Instances (執行個體)**。即會顯示 **Instances (執行個體)** 頁面。 1. 針對 **Node.js App Server (Node.js 應用程式伺服器)** 之 **nodejs-server1** 的 **Actions (動作)**，選擇 **stop (停止)**。在您看見確認訊息時，選擇 **Stop (停止)**。此程序需要幾分鐘的時間。當 OpsWorks Stacks 完成時，會顯示下列結果。 ![\[Node.js App Server instance details showing one stopped server in us-west-2a.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-example-instance-stopped-console.png) 1. 針對 **Actions (動作)**，選擇 **delete (刪除)**。在您看見確認訊息時，選擇 **Delete (刪除)**。執行個體已刪除，並顯示 **No instances (無執行個體)** 訊息。 **刪除堆疊** 1. 在服務導覽窗格中，選擇 **Stack (堆疊)**。即會顯示 **My Sample Stack (Linux)** 頁面。 1. 選擇 **Delete Stack (刪除堆疊)**。在您看見確認訊息時，選擇 **Delete (刪除)**。堆疊已刪除，並顯示 **OpsWorks Dashboard (OpsWorks 儀表板)** 頁面。或者，如果您不想重複使用使用者和 Amazon EC2 金鑰對來存取其他 AWS 服務和 EC2 執行個體，您可以刪除用於此演練的使用者和 Amazon EC2 金鑰對。如需說明，請參閱[刪除 IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting)、[Amazon EC2 金鑰對和 Linux 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair)。您現已完成本演練。如需詳細資訊，請參閱[後續步驟](gettingstarted-intro-next-steps.md)。 # 後續步驟 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在您已完成本演練，您可以進一步了解如何使用 OpsWorks Stacks： + 練習使用 Stacks OpsWorks 自行手動重新建立此堆疊。請參閱 [入門：Linux](gettingstarted-linux.md)。 + 探索技術指南和 OpsWorks Stacks 用於本演練的應用程式。請參閱配套[深入了解：探索本演練中使用的技術指南](gettingstarted-linux-explore-cookbook.md) 演練中的[深入了解：探索本演練中使用的應用程式](gettingstarted-linux-explore-app-source.md)和[入門：Linux](gettingstarted-linux.md)。 + 練習搭配 Windows 執行個體使用 OpsWorks Stacks。請參閱 [入門：Windows](gettingstarted-windows.md)。 + 了解如何[建立新的堆疊](workingstacks-creating.md)以進一步了解堆疊。 + 透過[編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md)進一步了解 layer。 + 透過[將執行個體新增至 Layer](workinginstances-add.md)進一步了解執行個體。 + 透過[部署應用程式](workingapps-deploying.md)進一步了解應用程式。 + 進一步了解 [技術指南和配方](workingcookbook.md)。 + 建立您自己的技術指南。請參閱 [入門：技術指南](gettingstarted-cookbooks.md)。 + 了解使用[安全與許可](workingsecurity.md)控制堆疊的存取權。 # Linux 堆疊入門 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在本演練中，您將了解如何使用 OpsWorks Stacks 來建立 Node.js 應用程式環境。完成後，您將擁有執行 Chef 12 的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體、Node.js HTTP 伺服器，以及可用來與 Twitter 互動並在網頁上留下評論的 Web 應用程式。 Chef 是一個第三方框架，用來設定和維護伺服器 (如 EC2 執行個體) 以及在這些伺服器上部署和維護應用程式的方式。如果您不熟悉 Chef，在完成本演練後，建議您進一步了解 Chef，以便充分利用 Stacks OpsWorks 提供的所有功能。(如需詳細資訊，請參閱[了解 Chef](https://learn.chef.io/) 網站。) OpsWorks Stacks 支援四種 Linux 發行版本：Amazon Linux、Ubuntu Server、CentOS 和 Red Hat Enterprise Linux。在此演練中，我們使用 Ubuntu Server。 OpsWorks Stacks 也適用於 Windows Server。雖然我們有適用於 Windows Server 堆疊的同等逐步解說，但建議您先完成此逐步解說，以了解 Stacks OpsWorks 和 Chef 的基本概念，而這些概念並未在此重複。完成本演練後，請參閱 [入門：Windows](gettingstarted-windows.md) 演練。 **Topics** + [步驟 1：完成事前準備](gettingstarted-linux-prerequisites.md) + [步驟 2：建立堆疊](gettingstarted-linux-create-stack.md) + [步驟 3：將 Layer 新增至堆疊](gettingstarted-linux-add-layer.md) + [步驟 4：指定要部署到執行個體的應用程式](gettingstarted-linux-specify-app.md) + [步驟 5：啟動執行個體](gettingstarted-linux-launch-instance.md) + [步驟 6：將應用程式部署到執行個體](gettingstarted-linux-deploy-app.md) + [步驟 7：測試執行個體上已部署的應用程式](gettingstarted-linux-test-app.md) + [步驟 8 (選用)：清理](gettingstarted-linux-clean-up.md) + [後續步驟](gettingstarted-linux-next-steps.md) + [深入了解：探索本演練中使用的技術指南](gettingstarted-linux-explore-cookbook.md) + [深入了解：探索本演練中使用的應用程式](gettingstarted-linux-explore-app-source.md) # 步驟 1：完成事前準備 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。完成下列步驟，才能開始演練。這些設定步驟包括註冊 AWS 帳戶、建立管理使用者，以及將存取許可指派給 OpsWorks Stacks。若您已完成[入門：範例](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-intro.html)演練，您便已完成本演練的事前準備，可直接跳到[步驟 2：建立堆疊](gettingstarted-linux-create-stack.md)。 **Topics** + [註冊 AWS 帳戶](#sign-up-for-aws) + [建立具有管理存取權的使用者](#create-an-admin) + [指派服務存取許可](#gettingstarted-linux-prerequisites-permissions) ## 註冊 AWS 帳戶如果您沒有 AWS 帳戶，請完成下列步驟來建立一個。 **註冊 AWS 帳戶** 1. 開啟 [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)。 1. 請遵循線上指示進行。部分註冊程序需接收來電或簡訊，並在電話鍵盤輸入驗證碼。當您註冊時 AWS 帳戶，*AWS 帳戶根使用者*會建立。根使用者有權存取該帳戶中的所有 AWS 服務和資源。作為安全最佳實務，請將管理存取權指派給使用者，並且僅使用根使用者來執行[需要根使用者存取權的任務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 AWS 會在註冊程序完成後傳送確認電子郵件給您。您可以隨時登錄 [https://aws.amazon.com/](https://aws.amazon.com/) 並選擇**我的帳戶**，以檢視您目前的帳戶活動並管理帳戶。 ## 建立具有管理存取權的使用者註冊後 AWS 帳戶，請保護 AWS 帳戶根使用者、啟用 AWS IAM Identity Center和建立管理使用者，以免將根使用者用於日常任務。 **保護您的 AWS 帳戶根使用者** 1. 選擇**根使用者**並輸入 AWS 帳戶您的電子郵件地址，以帳戶擁有者[AWS 管理主控台](https://console.aws.amazon.com/)身分登入。在下一頁中，輸入您的密碼。如需使用根使用者登入的說明，請參閱 *AWS 登入使用者指南*中的[以根使用者身分登入](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)。 1. 若要在您的根使用者帳戶上啟用多重要素驗證 (MFA)。如需說明，請參閱《*IAM 使用者指南*》中的[為您的 AWS 帳戶根使用者（主控台）啟用虛擬 MFA 裝置](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)。 **建立具有管理存取權的使用者** 1. 啟用 IAM Identity Center。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[啟用 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)。 1. 在 IAM Identity Center 中，將管理存取權授予使用者。如需使用 IAM Identity Center 目錄做為身分來源的教學課程，請參閱*AWS IAM Identity Center 《使用者指南*》中的[使用預設值設定使用者存取 IAM Identity Center 目錄](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html)。 **以具有管理存取權的使用者身分登入** + 若要使用您的 IAM Identity Center 使用者簽署，請使用建立 IAM Identity Center 使用者時傳送至您電子郵件地址的簽署 URL。如需使用 IAM Identity Center 使用者登入的說明，請參閱*AWS 登入《使用者指南*》中的[登入 AWS 存取入口網站](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)。 **指派存取權給其他使用者** 1. 在 IAM Identity Center 中，建立一個許可集來遵循套用最低權限的最佳實務。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[建立許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-a-permission-set.html)。 1. 將使用者指派至群組，然後對該群組指派單一登入存取權。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[新增群組](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)。 ## 指派服務存取許可將 OpsWorks `AWSOpsWorks_FullAccess`和 `AmazonS3FullAccess`許可新增至您的角色或使用者，以啟用對 Stacks 服務的存取（以及 OpsWorks Stacks 依賴的相關服務）。如需新增許可的詳細資訊，請參閱[新增 IAM 身分許可（主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)。您現已完成所有設定步驟，可[開始本演練](gettingstarted-linux-create-stack.md)。 # 步驟 2：建立堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您將使用 OpsWorks Stacks 主控台來建立堆疊。*堆疊*是執行個體和相關 AWS 資源的集合，具有共同目的且您想要一起管理。(如需詳細資訊，請參閱 [堆疊](workingstacks.md)。) 本演練只有一個執行個體。開始之前，請先完成[事前準備](gettingstarted-linux-prerequisites.md) (若尚未完成)。 **建立堆疊** 1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) 開啟 OpsWorks 主控台。 1. 執行下列任一作業 (若適用的話)： + 如果顯示**歡迎使用 OpsWorks Stacks** 頁面，請選擇**新增您的第一個堆疊**或**新增您的第一個 Stacks OpsWorks 堆疊** （兩個選項都執行相同的動作）。即會顯示 **Add stack (新增堆疊)** 頁面。 + 若顯示 **OpsWorks Dashboard (OpsWorks 儀表板)** 頁面，請選擇 **Add stack (新增堆疊)**。即會顯示 **Add stack (新增堆疊)** 頁面。 1. 在顯示的 **Add stack (新增堆疊)** 頁面中，請選擇 **Chef 12 stack (Chef 12 堆疊)** (若尚未選擇)。 1. 在 **Stack name (堆疊名稱)** 方塊中輸入一個名稱 (例如：**MyLinuxDemoStack**)。(您可以輸入不同的名稱，但請務必在本演練的後續部分一律將 `MyLinuxDemoStack` 取代為您選擇的名稱。) 1. 針對**區域**，選擇**美國西部（奧勒岡）**。 1. 針對 **VPC**，執行下列其中一項作業： + 若 VPC 可用，請選擇它。(如需詳細資訊，請參閱 [在 VPC 中執行堆疊](workingstacks-vpc.md)。) + 否則，請選擇 **No VPC (無 VPC)**。 1. 針對 **Default operating system (預設作業系統)**，選擇 **Linux** 和 **Ubuntu 18.04 LTS**。 1. 針對 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)**，選擇 **Yes (是)**。 1. 針對 **Repository type (儲存庫類型)**，選擇 **Http Archive (Http 封存)**。 1. 針對 **Repository URL (儲存庫 URL)**，輸入 **https://s3.amazonaws.com/opsworks-demo-assets/opsworks-linux-demo-cookbooks-nodejs.tar.gz** 1. 保留下列項目的預設值： + **Default Availability Zone (預設可用區域)** (**us-west-2a**) + **Default SSH key (預設 SSH 金鑰)** (**Do not use a default SSH key (不使用預設 SSH 金鑰)**) + **User name (使用者名稱)** (空白) + **Password (密碼)** (空白) + **Stack color (堆疊色彩)** (深藍色) 1. 選擇 **Advanced (進階)**。 1. 對於 **IAM 角色**，請執行下列其中一項操作（如需詳細資訊，請參閱 [允許 OpsWorks Stacks 代表您採取行動](opsworks-security-servicerole.md))： + 若 **aws-opsworks-service-role** 可用，請選擇它。 + 若 **aws-opsworks-service-role** 不可用，請選擇 **New IAM role (新 IAM 角色)**。 1. 對於**預設 IAM 執行個體描述檔**，請執行下列其中一項（如需詳細資訊，請參閱 [指定在 EC2 執行個體上執行之應用程式的許可](opsworks-security-appsrole.md))： + 若 **aws-opsworks-ec2-role** 可用，請選擇它。 + 如果無法使用 **aws-opsworks-ec2-role**，請選擇**新的 IAM 執行個體描述**檔。 1. 針對 **API endpoint region (API 端點區域)**，選擇您希望與堆疊建立關聯的區域 API 端點。如果您希望堆疊位於美國東部（維吉尼亞北部）區域端點的美國西部（奧勒岡）區域，請選擇 **us-east-1**。如果您希望堆疊同時位於美國西部（奧勒岡）區域，並與美國西部（奧勒岡）區域端點相關聯，請選擇 **us-west-2**。 **注意** 美國東部（維吉尼亞北部）區域端點包含較舊 AWS 區域的回溯相容性，但最佳實務是選擇離您管理位置最近的區域端點 AWS。如需詳細資訊，請參閱[區域支援](gettingstarted_intro.md#gettingstarted-intro-region)。 1. 保留下列項目的預設值： + **Default root device type (預設根設備類型)** (**EBS backed (EBS 後端)**) + **Hostname theme (主機名稱主題)** (**Layer Dependent (依存於 Layer)**) + **OpsWorks Agent version (OpsWorks 代理程式版本)** (最新版本) + **Custom JSON (自訂 JSON)** (空白) + **Use OpsWorks security groups (使用 OpsWorks 安全群組)** **(Yes (是))** 1. 您的結果應該符合下列螢幕擷取畫面，但 **VPC**、**IAM 角色**和**預設 IAM 執行個體描述檔**除外： ![\[AWS OpsWorks Stacks interface for creating a Chef 12 stack with configuration options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-add-stack-top-console.png) ![\[AWS OpsWorks stack configuration form with repository, IAM, and security options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-add-stack-bottom-console.png) 1. 選擇**新增 Stack**. OpsWorks Stacks 建立堆疊並顯示 **MyLinuxDemoStack** 頁面。現在，您已擁有一個設定正確的堆疊可用於本演練。在[下一個步驟](gettingstarted-linux-add-layer.md)中，您將會將 layer 新增至堆疊中。 # 步驟 3：將 Layer 新增至堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 *layer* 是一組執行個體的藍圖，例如 Amazon EC2 執行個體。它會指定例如執行個體的設定、資源、安裝的套件和安全群組等資訊。接下來，將 layer 新增至堆疊。(如需 layer 的詳細資訊，請參閱 [層](workinglayers.md)。) **將 layer 新增至堆疊** 1. 在先前步驟中顯示的 **MyLinuxDemoStack** 頁面上，針對 **Layers (Layer)**，選擇 **Add a layer (新增 layer)**： ![\[Layers section with icon and description, highlighting "Add a layer" option.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-add-layer-console.png) 1. 即會顯示 **Add Layer (新增 Layer)** 頁面。在 **OpsWorks** 標籤上，針對 **Name (名稱)**，輸入 **MyLinuxDemoLayer**。(您可以輸入不同的名稱，但請務必在本演練的後續部分一律將 `MyLinuxDemoLayer` 取代為您選擇的名稱。) 1. 針對 **Short name (短名)**，輸入 **demo** (您可以輸入不同的值，但請務必在本演練全部範圍內將 `demo` 取代為您選擇的名稱)： ![\[Form to add a layer with fields for name and short name, and options for OpsWorks, ECS, and RDS.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-add-layer-page-console.png) 1. 選擇**新增 layer**。 OpsWorks Stacks 會建立 layer 並顯示 **Layers** 頁面。 1. 在 **Layers (Layer)** 頁面上，針對 **MyLinuxDemoLayer**，選擇 **Network (網路)**。 1. 在 **Network (網路)** 標籤上的 **Automatically Assign IP Addresses (自動指派 IP 地址)** 之下，驗證 **Public IP addresses (公有 IP 地址)** 已設為 **yes (是)**。如果已進行變更，請選擇 **Save (儲存)**。 ![\[Network settings showing Public IP addresses set to yes and Elastic IP addresses set to No.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add_layer_publicip.png) 1. 在 **Layers (Layer)** 頁面上，選擇 **Security (安全性)**。 ![\[AWS Layers interface showing MyLinuxDemoLayer with Security tab highlighted.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-layer-page-console.png) 1. **Layer MyLinuxDemoLayer** 頁面即會顯示，並開啟 **Security (安全性)** 標籤。針對 **Security groups (安全群組)**，選擇 **AWS-OpsWorks-WebApp**，然後選擇 **Save (儲存)**： ![\[Security settings interface showing security group selection and EC2 instance profile options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-layer-security-console.png) 1. `AWS-OpsWorks-WebApp` 安全群組即會新增至 layer。（此安全群組可讓使用者在本演練稍後連線至執行個體上的應用程式。如果沒有此安全群組，使用者會在網頁瀏覽器中收到無法連線至執行個體的訊息。) 現在，您已擁有一個設定正確的 layer 可用於本演練。在[下一個步驟](gettingstarted-linux-specify-app.md)中，您將會指定要部署到執行個體的應用程式。 # 步驟 4：指定要部署到執行個體的應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。告訴 OpsWorks Stacks 您將在本演練稍後部署到執行個體的應用程式。在此內容中， OpsWorks Stacks 會將*應用程式*定義為您想要在執行個體上執行的程式碼。(如需詳細資訊，請參閱 [應用程式](workingapps.md)。) 本節中的程序適用於 Chef 12 和更新的堆疊。如需如何在 Chef 11 堆疊中將應用程式新增至 layer 的資訊，請參閱[步驟 2.4：建立和部署應用程式 - Chef 11](gettingstarted-simple-app.md)。 **指定要部署的應用程式** 1. 在服務導覽窗格中，選擇 **Apps (應用程式)**： ![\[Navigation menu with options including Stack, Layers, Instances, and Apps highlighted.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-nav-pane-console.png) 1. 即會顯示 **Apps (應用程式)** 頁面。選擇 **Add an app (新增應用程式用戶端)**。即會顯示 **Add App (新增應用程式)** 頁面。 1. 針對 **Settings (設定)** 的 **Name (名稱)**，請輸入 **MyLinuxDemoApp**。(您可以輸入不同的名稱，但請務必在本演練的後續部分一律將 `MyLinuxDemoApp` 取代為您選擇的名稱。) 1. 針對 **Application Source (應用程式來源)** 的 **Repository URL (儲存庫 URL)**，輸入 **https://github.com/awslabs/opsworks-windows-demo-nodejs.git** 1. 保留下列項目的預設值： + **Settings (設定)**、**Document root (文件根)** (空白) + **Data Sources (資料來源)**、**Data source type (資料來源類型)** (**None (無)**) + **Repository type (儲存庫類型)** (**Git**) + **Repository SSH key (儲存庫 SSH 金鑰)** (空白) + **Branch/Revision (分支/修訂)** (空白) + **Environment Variables (環境變數)** (空白 **KEY (金鑰)**、空白 **VALUE (值)**、不勾選 **Protected Value (受保護的值)**) + **Add Domains (新增網域)**、**Domain Name (網域名稱)** (空白) + **SSL Settings (SSL 設定)**、**Enable SSL (啟用 SSL)** (**No (否)**) ![\[Add App form with settings for name, document root, data sources, and application source.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-add-app-top-console.png) ![\[Application configuration form with environment variables, domain settings, and SSL options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-add-app-bottom-console.png) 1. 選擇**新增 App**. OpsWorks Stacks 新增應用程式，並顯示**應用程式**頁面。現在，您已擁有一個設定正確的應用程式可用於本演練。在[下一個步驟](gettingstarted-linux-launch-instance.md)中，您將啟動執行個體。 # 步驟 5：啟動執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 OpsWorks Stacks 啟動 Ubuntu Server Amazon EC2 執行個體。該執行個體會使用您稍早在本演練中建立之 layer 中定義的設定。(如需詳細資訊，請參閱 [執行個體](workinginstances.md)。) **啟動執行個體** 1. 在服務導覽窗格中，選擇 **Instances (執行個體)**。即會顯示 **Instances (執行個體)** 頁面。 1. 針對 **MyLinuxDemoLayer**，選擇 **Add an instance (新增執行個體)**。 1. 在 **New (新增)** 標籤上，請為下列各項保留預設值： + **Hostname (主機名稱)** (**demo1**) + **Size (大小)** (**c3.large**) + **Subnet (子網路)** (*IP 地址* **us-west-2a**) 1. 選擇 **Advanced (進階)**。 1. 保留下列項目的預設值： + **Scaling type (擴展類型)** (**24/7 (全年無休)**) + **SSH key (SSH 金鑰)** (**Do not use a default SSH key (不使用預設 SSH 金鑰)**) + **Operating system (作業系統)** (**Ubuntu 18.04 LTS**) + **OpsWorks Agent version (OpsWorks 代理程式版本)** (**Inherit from stack (繼承自堆疊)**) + **Tenancy (租用)** (**Default - Rely on VPC settings (預設 – 依存 VPC 設定)**) + **Root device type (根設備類型)** (**EBS backed (EBS 後端)**) + **Volume type (磁碟區類型)** (**General Purpose (SSD) (一般用途 (SSD))**) + **Volume size (磁碟區大小)** (**8**) 1. 您的結果將類似下列螢幕擷取畫面： ![\[Form for configuring a new EC2 instance with options for hostname, size, subnet, and other settings.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-add-instance-console.png) 1. 選擇**新增執行個體**。 OpsWorks Stacks 會將執行個體新增至 layer，並顯示**執行個體**頁面。 1. 針對 **MyLinuxDemoLayer** 之 **demo1** 的 **Actions (動作)**，選擇 **start (啟動)**： ![\[Instance management interface showing a stopped demo1 instance with start and delete options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-start-instance-console.png) 1. 幾分鐘後，會發生下列情況： + **setting up (設定)** 圓圈會從 **0** 變更為 **1**。 + **Status (狀態)** 會從 **stopped** 依次變更為 **requested**、**pending**、**booting**、**running\$1setup**，最後成為 **online**。請注意，此程序需要幾分鐘的時間。 + 當 **Status (狀態)** 變更為 **online** 後，**setting up** 圓圈指標會從 **1** 變更為 **0**，**online** 圓圈會從 **0** 變更為 **1** 並變更為亮綠色。請在 **online (線上)** 圓圈變更為亮綠色並顯示 **1** 個執行個體在線上後再繼續。 1. 繼續之前，您的結果必須符合下列的螢幕擷取畫面 (如果您收到故障訊息，建議您參閱[偵錯和故障診斷指南](troubleshoot.md))： ![\[EC2 instance details showing one online c3.large instance in us-west-2a with stop and ssh options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-instance-started-console.png) 現在，您已經準備好用於部署應用程式的執行個體。 **注意** 如果您想要登入執行個體以進一步探索，您必須先向 OpsWorks Stacks 提供公有 SSH 金鑰的相關資訊（您可以使用 ssh-keygen 或 PuTTYgen 等工具建立），然後您必須在`MyLinuxDemoStack`堆疊上設定許可，讓使用者能夠登入執行個體。如需說明，請參閱 [註冊使用者的公有 SSH 金鑰](security-settingsshkey.md) 與 [使用 SSH 登入](workinginstances-ssh.md)。如果您計劃使用 SSH 透過 PuTTY 連線至執行個體，請參閱 AWS 文件中的[使用 PuTTY 從 Windows 連線至 Linux 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)。在[下一個步驟](gettingstarted-linux-deploy-app.md)中，您會將應用程式部署到執行個體。 # 步驟 6：將應用程式部署到執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在此步驟中，您會將來自 GitHub 的應用程式部署到執行中的執行個體。(如需詳細資訊，請參閱 [部署應用程式](workingapps-deploying.md)。) 部署應用程式之前，您必須指定「配方」**用於協調部署。方法是一個 Chef 概念。配方是以 Ruby 語言語法編寫的指示，指定要使用的資源以及套用那些資源的順序。(如需詳細資訊，請前往[了解 Chef](https://docs.chef.io/recipes.html) 網站上的[關於配方](https://learn.chef.io/)。) **指定配方以用來將應用程式部署到執行個體** 1. 在服務導覽窗格中，選擇 **Layers (Layer)**。即會顯示 **Layers (Layer)** 頁面。 1. 針對 **MyLinuxDemoLayer**，選擇 **Recipes (配方)**。 ![\[Layer interface showing MyLinuxDemoLayer with tabs for Settings, Recipes, Network, EBS Volumes, and Security.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-layers-page-console.png) **Layer MyLinuxDemoLayer** 頁面即會顯示，並開啟 **Recipes (配方)** 標籤。 1. 針對 **Custom Chef Recipes (自訂 Chef 配方)** 的 **Deploy (部署)**，輸入 **nodejs\$1demo::default**，然後按 **Enter** 鍵。`nodejs_demo` 是技術指南的名稱，`default` 是技術指南內目標配方的名稱。(若要探索配方的程式碼，請參閱 [深入了解：探索本演練中使用的技術指南](gettingstarted-linux-explore-cookbook.md)。) 您的結果必須符合下列螢幕擷取畫面： ![\[Custom Chef Recipes configuration panel with Repository URL and lifecycle stages for a Linux demo layer.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-recipes-page-console.png) 1. 選擇 **Save**. OpsWorks Stacks 將配方新增至 layer 的部署生命週期事件。 **將應用程式部署至執行個體** 1. 在服務導覽窗格中，選擇 **Apps (應用程式)**。即會顯示 **Apps (應用程式)** 頁面。 1. 針對 **MyLinuxDemoApp** 的 **Actions (動作)**，選擇 **deploy (部署)**，如下列螢幕擷取畫面所示： ![\[Apps table showing MyLinuxDemoApp with deploy, edit, and delete options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-apps-page-console.png) 1. 在 **Deploy App (部署應用程式)** 頁面上，請為下列各項保留預設值： + **Command (命令)** (**Deploy (部署)**) + **Comment (註解)** (空白) + **Settings (設定)**、**Advanced (進階)**、**Custom Chef JSON (自訂 Chef JSON)** (空白) + **Instances (執行個體)**、**Advanced (進階)** (已核取 **Select all (全選)**、已核取 **MyLinuxDemoLayer**、已核取 **demo1**)。 1. 您的結果必須符合下列螢幕擷取畫面： ![\[Deploy App interface with settings for MyLinuxDemoApp, including command and instance selection.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-deploy-app-console.png) 1. 選擇**部署**。**Deployment MyLinuxDemoApp – deploy** 頁面即會顯示。**Status (狀態)** 會從 **running (執行中)** 變更為 **successful (成功)**。在 **demo1** 旁會顯示一個旋轉圓圈，然後變為綠色核取記號。請注意，此程序需要幾分鐘的時間。請在您看到 **Status (狀態)** 變為 **successful (成功)** 以及綠色核取記號後，再繼續。 1. 您的結果必須符合下列螢幕擷取畫面，當然 **Created at (建立於)**、**Completed at (完成於)**、**Duration (持續時間)** 和 **User (使用者)** 這幾項除外。如果 **status (狀態)** 為 **failed (失敗)**，則進行故障診斷；請針對 **Log (日誌)**，選擇 **show (顯示)** 以取得失敗的詳細資訊： ![\[Deployment details for MyLinuxDemoApp showing successful status and duration of 1 minute 13 seconds.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-app-deployed-console.png) 您現已成功將應用程式部署到執行個體。在[下一個步驟](gettingstarted-linux-test-app.md)中，您將會測試執行個體上已部署的應用程式。 # 步驟 7：測試執行個體上已部署的應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在，測試執行個體上已部署的應用程式。 **測試執行個體上的部署** 1. 在服務導覽窗格中，選擇 **Instances (執行個體)**。即會顯示 **Instances (執行個體)** 頁面。 1. 針對 **MyLinuxDemoLayer** 之 **demo1** 的 **Public IP (公有 IP)**，選擇 IP 地址： ![\[EC2 instance details showing one online c3.large instance in us-west-2a with stop and ssh options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-instance-ip-console.png) 新的 Web 瀏覽器標籤會顯示該應用程式。 1. 在賀辭網頁的 **Leave a comment (留下評論)** 文字方塊中輸入評論，然後選擇 **Send (傳送)** 測試應用程式。應用程式會將您的評論新增到網頁。繼續留下評論，並依您需要隨時選擇 **Send (傳送)**： ![\[Congratulatory message for deploying first app with AWS OpsWorks, featuring stylized tree and buildings.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-test-app.png) 1. 如果您有 Twitter 帳戶，請選擇 **Tweet (推文)** 或 **Follow @AWSOpsWorks (關注 @AWSOpsWorks)**，然後遵循畫面指示發佈有關此應用程式的推文或關注 @AWSOpsWorks。您現已成功測試執行個體上所部署的應用程式。在[下一個步驟](gettingstarted-linux-clean-up.md)中，您可以清除用於本演練 AWS 的資源。此步驟為選用。當您繼續進一步了解 Stacks OpsWorks 時，建議您繼續使用這些 AWS 資源。不過，保留這些 AWS 資源可能會導致 AWS 您的帳戶持續產生一些費用。如果您想要將這些 AWS 資源保留以供日後使用，您現在已完成本演練，您可以直接跳到 [後續步驟](gettingstarted-linux-next-steps.md)。 # 步驟 8 (選用)：清理 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。為了避免 AWS 您的帳戶產生額外費用，您可以刪除 AWS 用於本演練的資源。這些 AWS 資源包括 OpsWorks Stacks 堆疊和堆疊的元件。（如需詳細資訊，請參閱 [OpsWorks 定價](https://aws.amazon.com/opsworks/pricing/)。) 不過，當您繼續進一步了解 Stacks OpsWorks 時，建議您繼續使用這些 AWS 資源。如果您想要讓這些 AWS 資源保持可用，您現在已完成本演練，您可以跳至 [後續步驟](gettingstarted-linux-next-steps.md)。存放在您為此逐步解說建立的資源裡的內容，可包含個人識別資訊。如果您不希望再將此資訊存放在 AWS，請遵循本主題的步驟。 **從堆疊刪除應用程式** 1. 在 OpsWorks Stacks 主控台的服務導覽窗格中，選擇**應用程式**。即會顯示 **Apps (應用程式)** 頁面。 1. 針對 **MyLinuxDemoApp** 的 **Actions (動作)**，選擇 **delete (刪除)**。顯示確認訊息時，選擇**刪除**。 OpsWorks Stacks 會刪除應用程式。 **刪除堆疊的執行個體** 1. 在服務導覽窗格中，選擇 **Instances (執行個體)**。即會顯示 **Instances (執行個體)** 頁面。 1. 針對 **MyLinuxDemoLayer** 之 **demo1** 的 **Actions (動作)**，選擇 **stop (停止)**。在您看見確認訊息時，選擇 **Stop (停止)**。會發生下列情況。 + **Status (狀態)** 從 **online (線上)** 變更為 **stopping (停止中)**，最後變更為 **stopped (已停止)**。 + **online (線上)** 從 **1** 變更為 **0**。 + **shutting down (關機中)** 從 **0** 變更為 **1**，最後變回 **0**。 + **stopped (已停止)** 最後從 **0** 變更為 **1**。此程序需要幾分鐘的時間。Stacks OpsWorks 完成時，會顯示下列結果。 ![\[Instances dashboard showing one stopped Linux instance in the us-west-2a availability zone.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs-linux-instance-stopped-console.png) 1. 針對 **Actions (動作)**，選擇 **delete (刪除)**。當您看到確認訊息時，選擇 **Delete**. OpsWorks Stacks 會刪除執行個體，並顯示**無執行個體**訊息。 **刪除堆疊** 1. 在服務導覽窗格中，選擇 **Stack (堆疊)**。即會顯示 **MyLinuxDemoStack** 頁面。 1. 選擇 **Delete Stack (刪除堆疊)**。當您看到確認訊息時，請選擇 **Delete**. OpsWorks Stacks 刪除堆疊並顯示 **OpsWorks Dashboard** 頁面。或者，如果您不想重複使用使用者和 Amazon EC2 金鑰對來存取其他 AWS 服務和 EC2 執行個體，您可以刪除用於此演練的使用者和 Amazon EC2 金鑰對。如需說明，請參閱[刪除 IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting)、[Amazon EC2 金鑰對和 Linux 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair)。您現已完成本演練。如需詳細資訊，請參閱[後續步驟](gettingstarted-linux-next-steps.md)。 # 後續步驟 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在您已完成本演練，您可以進一步了解如何使用 OpsWorks Stacks： + 探索您在本演練中使用的技術指南和應用程式。請參閱 [深入了解：探索本演練中使用的技術指南](gettingstarted-linux-explore-cookbook.md) 和 [深入了解：探索本演練中使用的應用程式](gettingstarted-linux-explore-app-source.md)。 + 練習搭配 Windows 執行個體使用 OpsWorks Stacks。請參閱 [入門：Windows](gettingstarted-windows.md)。 + 了解如何[建立新的堆疊](workingstacks-creating.md)以進一步了解堆疊。 + 透過[編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md)進一步了解 layer。 + 透過[將執行個體新增至 Layer](workinginstances-add.md)進一步了解執行個體。 + 透過[部署應用程式](workingapps-deploying.md)進一步了解應用程式。 + 進一步了解 [技術指南和配方](workingcookbook.md)。 + 建立您自己的技術指南。請參閱 [入門：技術指南](gettingstarted-cookbooks.md)。 + 了解使用[安全與許可](workingsecurity.md)控制堆疊的存取權。 # 深入了解：探索本演練中使用的技術指南 **重要** 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 概念。配方是以 Ruby 語言語法編寫的指示，指定要使用的資源以及套用那些資源的順序。如需詳細資訊，請前往[了解 Chef](https://docs.chef.io/cookbooks.html) 網站上的[關於技術指南](https://docs.chef.io/recipes.html)和[關於配方](https://learn.chef.io/)。若要查看本演練中使用的技術指南內容，您可以將 [opsworks-linux-demo-cookbooks-nodejs.tar.gz](https://s3.amazonaws.com/opsworks-demo-assets/opsworks-linux-demo-cookbooks-nodejs.tar.gz) 檔案內容擷取到本機工作站的空目錄中。(您也可以登入已部署技術指南的執行個體，來探索 `/var/chef/cookbooks` 目錄中的內容)。在 `cookbooks/nodejs_demo/recipes` 目錄中的 `default.rb` 檔案，是技術指南執行其程式碼的位置： ``` app = search(:aws_opsworks_app).first app_path = "/srv/#{app['shortname']}" package "git" do options "--force-yes" if node["platform"] == "ubuntu" && node["platform_version"] == "18.04" end application app_path do javascript "4" environment.update("PORT" => "80") git app_path do repository app["app_source"]["url"] revision app["app_source"]["revision"] end link "#{app_path}/server.js" do to "#{app_path}/index.js" end npm_install npm_start end ``` 下列是該檔案執行的作業： + `search(:aws_opsworks_app).first` 使用 Chef 搜尋來查詢最終將會部署到執行個體的應用程式。此資訊包含如應用程式短名及其來源儲存庫詳細資訊等設定。由於本演練只部署一個應用程式，Chef 搜尋會在執行個體上 `aws_opsworks_app` 搜尋索引內的第一個項目取得這些設定。每當執行個體啟動時， OpsWorks Stacks 都會將此和其他相關資訊儲存為執行個體本身上的一組資料包，而您可以透過 Chef 搜尋取得資料包內容。雖然您可以使用將這些設定硬式編碼在此配方中，但使用資料包和 Chef 搜尋是更穩健的方法。如需資料包的詳細資訊，請參閱 [OpsWorks Stacks 資料包參考](data-bags.md)。另請參閱 [Learn Chef](https://learn.chef.io/) 網站上的[關於資料包](https://docs.chef.io/data_bags.html)。如需 Chef 搜尋的詳細資訊，請前往[了解 Chef](https://docs.chef.io/chef_search.html) 網站上的[關於搜尋](https://learn.chef.io/)。 + `package` 資源會在執行個體上安裝 Git。 + `application` 資源說明和部署 Web 應用程式： + `javascript` 是要安裝的 JavaScript 執行時間版本。 + `environment` 設定環境變數。 + `git` 從指定的儲存庫和分支取得來源碼。 + `app_path` 是要複製儲存庫到的目標路徑。如果該路徑不存在於執行個體上， OpsWorks Stacks 會建立路徑。 + `link` 建立符號連結。 + `npm_install` 安裝 Node Package Manager，是 Node.js 的預設套件管理工具。 + `npm_start` 執行 Node.js。雖然 OpsWorks Stacks 已建立用於本演練的技術指南，但您可以建立自己的技術指南。若要了解作法，請參閱[入門：技術指南](gettingstarted-cookbooks.md)。此外，請前往[了解 Chef](https://docs.chef.io/cookbooks.html) 網站上的[關於技術指南](https://docs.chef.io/recipes.html)、[關於配方](https://learn.chef.io/modules/learn-the-basics/ubuntu#/)和[了解 Ubuntu 上的 Chef 基本概念](https://learn.chef.io/)，以及 [Chef 入門](http://gettingstartedwithchef.com/first-steps-with-chef.html)網站上的[使用 Chef 的第一步](http://gettingstartedwithchef.com/)。 # 深入了解：探索本演練中使用的應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本主題說明 OpsWorks Stacks 為此演練部署至執行個體的應用程式。若要查看應用程式的來源碼，請將 [opsworks-windows-demo-nodejs](https://github.com/awslabs/opsworks-windows-demo-nodejs) GitHub 儲存庫內容擷取到本機工作站的空目錄中。您也可以登入已部署技術指南的執行個體，來探索 `/srv/mylinuxdemoapp` 目錄中的內容。 `index.js` 檔案包含該應用程式最重要的程式碼： ``` var express = require('express'); var app = express(); var path = require('path'); var os = require('os'); var bodyParser = require('body-parser'); var fs = require('fs'); var add_comment = function(comment) { var comments = get_comments(); comments.push({"date": new Date(), "text": comment}); fs.writeFileSync('./comments.json', JSON.stringify(comments)); }; var get_comments = function() { var comments; if (fs.existsSync('./comments.json')) { comments = fs.readFileSync('./comments.json'); comments = JSON.parse(comments); } else { comments = []; } return comments; }; app.use(function log (req, res, next) { console.log([req.method, req.url].join(' ')); next(); }); app.use(express.static('public')); app.use(bodyParser.urlencoded({ extended: false })) app.set('view engine', 'jade'); app.get('/', function(req, res) { var comments = get_comments(); res.render("index", { agent: req.headers['user-agent'], hostname: os.hostname(), nodeversion: process.version, time: new Date(), admin: (process.env.APP_ADMIN_EMAIL || "admin@unconfigured-value.com" ), comments: get_comments() }); }); app.post('/', function(req, res) { var comment = req.body.comment; if (comment) { add_comment(comment); console.log("Got comment: " + comment); } res.redirect("/#form-section"); }); var server = app.listen(process.env.PORT || 3000, function() { console.log('Listening on %s', process.env.PORT); }); ``` 下列是該檔案執行的作業： + `require` 載入模組，其中包含此 Web 應用程式依預期執行所需要的一些相依程式碼。 + `add_comment` 和 `get_comments` 函數將資訊寫入 `comments.json` 檔案並從中讀取資訊。 + 如需 `app.get`、`app.listen`、`app.post`、`app.set` 和 `app.use` 的資訊，請參閱 [Express API 參考](http://expressjs.com/4x/api.html)。若要了解如何建立和封裝您的應用程式以便部署，請參閱 [應用程式來源](workingapps-creating.md#workingapps-creating-source)。 # Windows 堆疊入門 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。雲端型應用程式通常需要一組必須共同建立和管理的相關資源，例如應用程式伺服器、資料庫伺服器等。此執行個體的集合稱為「堆疊」**。簡易的應用程式堆疊看起來可能如下。 ![\[Diagram showing users connecting to app servers through internet, elastic IP, and load balancer.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/windows_walkthrough_arch.png) 基本架構由下列項目組成： + 用於接收使用者請求的彈性 IP 地址。 + 將傳入請求平均分散至應用程式伺服器的負載平衡器。 + 一組數量足以處理流量的應用程式伺服器執行個體。此外，您通常需要一種將應用程式分散至應用程式伺服器、管理使用者許可等的方式。 OpsWorks Stacks 提供簡單且直接的方式來建立和管理堆疊及其相關聯的應用程式和資源。本章介紹 OpsWorks Stacks 的基本概念，以及一些更複雜的功能，引導您完成圖表中建立應用程式伺服器堆疊的程序。它使用 Stacks OpsWorks 易於遵循的增量開發模型：設定基本堆疊，並在正常運作後新增元件，直到您達到功能完整的實作為止。 + [步驟 1：完成事前準備](gettingstarted-windows-prerequisites.md)示範如何進行設定以開始演練。 + [步驟 2：建立基本應用程式伺服器堆疊](gettingstarted-windows-basic.md) 說明如何建立基本堆疊以支援網際網路資訊服務 (IIS)，並將應用程式部署到伺服器。 + [步驟 3：橫向擴展 IISExample](gettingstarted-windows-scale.md)說明如何透過新增更多應用程式伺服器來擴展堆疊以處理增加的負載、將傳入流量分散的負載平衡器，以及接收傳入請求的彈性 IP 地址。 **Topics** + [步驟 1：完成事前準備](gettingstarted-windows-prerequisites.md) + [步驟 2：建立基本應用程式伺服器堆疊](gettingstarted-windows-basic.md) + [步驟 3：橫向擴展 IISExample](gettingstarted-windows-scale.md) + [後續步驟](gettingstarted-windows-what-next.md) # 步驟 1：完成事前準備 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。完成下列步驟，才能開始演練。這些設定步驟包括註冊 AWS 帳戶、建立管理使用者，以及將存取許可指派給 OpsWorks Stacks。若您已完成[入門：範例](gettingstarted-intro.md)或[入門：Linux](gettingstarted-linux.md)演練，您便已完成本演練的事前準備，可直接跳到[步驟 2：建立基本應用程式伺服器堆疊](gettingstarted-windows-basic.md)。 **Topics** + [註冊 AWS 帳戶](#sign-up-for-aws) + [建立具有管理存取權的使用者](#create-an-admin) + [指派服務存取許可](#gettingstarted-windows-prerequisites-permissions) + [確保 Stacks OpsWorks 使用者已新增至您的網域](#gettingstarted-windows-prerequisites-adusers) ## 註冊 AWS 帳戶如果您沒有 AWS 帳戶，請完成下列步驟來建立一個。 **註冊 AWS 帳戶** 1. 開啟 [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)。 1. 請遵循線上指示進行。部分註冊程序需接收來電或簡訊，並在電話鍵盤輸入驗證碼。當您註冊時 AWS 帳戶，*AWS 帳戶根使用者*會建立。根使用者有權存取該帳戶中的所有 AWS 服務和資源。作為安全最佳實務，請將管理存取權指派給使用者，並且僅使用根使用者來執行[需要根使用者存取權的任務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 AWS 會在註冊程序完成後傳送確認電子郵件給您。您可以隨時登錄 [https://aws.amazon.com/](https://aws.amazon.com/) 並選擇**我的帳戶**，以檢視您目前的帳戶活動並管理帳戶。 ## 建立具有管理存取權的使用者註冊後 AWS 帳戶，請保護 AWS 帳戶根使用者、啟用 AWS IAM Identity Center和建立管理使用者，以免將根使用者用於日常任務。 **保護您的 AWS 帳戶根使用者** 1. 選擇**根使用者**並輸入 AWS 帳戶您的電子郵件地址，以帳戶擁有者[AWS 管理主控台](https://console.aws.amazon.com/)身分登入。在下一頁中，輸入您的密碼。如需使用根使用者登入的說明，請參閱 *AWS 登入使用者指南*中的[以根使用者身分登入](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)。 1. 若要在您的根使用者帳戶上啟用多重要素驗證 (MFA)。如需說明，請參閱《*IAM 使用者指南*》中的[為您的 AWS 帳戶根使用者（主控台）啟用虛擬 MFA 裝置](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)。 **建立具有管理存取權的使用者** 1. 啟用 IAM Identity Center。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[啟用 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)。 1. 在 IAM Identity Center 中，將管理存取權授予使用者。如需使用 IAM Identity Center 目錄做為身分來源的教學課程，請參閱*AWS IAM Identity Center 《使用者指南*》中的[使用預設值設定使用者存取 IAM Identity Center 目錄](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html)。 **以具有管理存取權的使用者身分登入** + 若要使用您的 IAM Identity Center 使用者簽署，請使用建立 IAM Identity Center 使用者時傳送至您電子郵件地址的簽署 URL。如需使用 IAM Identity Center 使用者登入的說明，請參閱*AWS 登入《使用者指南*》中的[登入 AWS 存取入口網站](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)。 **指派存取權給其他使用者** 1. 在 IAM Identity Center 中，建立一個許可集來遵循套用最低權限的最佳實務。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[建立許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-a-permission-set.html)。 1. 將使用者指派至群組，然後對該群組指派單一登入存取權。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[新增群組](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)。 ## 指派服務存取許可將 OpsWorks `AWSOpsWorks_FullAccess`和 `AmazonS3FullAccess`許可新增至您的角色或使用者，以啟用 Stacks 服務的存取權（以及 OpsWorks Stacks 依賴的相關服務）。如需新增許可的詳細資訊，請參閱[新增 IAM 身分許可（主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)。 ## 確保 Stacks OpsWorks 使用者已新增至您的網域在 Chef 12.2 堆疊中，隨附的 `aws_opsworks_users` 技術指南會建立對 Windows 型的執行個體擁有 SSH 和遠端桌面通訊協定 (RDP) 存取權的使用者。當您將堆疊中的 Windows 執行個體加入 Active Directory 網域時，如果 OpsWorks Stacks 使用者不存在於 Active Directory 中，此技術指南執行可能會失敗。如果在 Active Directory 中未識別出使用者，則在您將執行個體加入網域後重新啟動時，執行個體會進入 `setup failed` 狀態。針對加入網域的 Windows 執行個體，在使用者許可頁面對 OpsWorks Stacks 使用者授予 SSH/RDP 存取權並不足夠。在您將 Chef 12.2 堆疊中的 Windows 執行個體加入 Active Directory 網域之前，請確定 Windows OpsWorks 型堆疊的所有 Stacks 使用者都是網域的成員。最好的方法是在建立以 Windows 為基礎的堆疊之前，使用 IAM 設定聯合身分，然後在將堆疊中的執行個體加入網域之前，將聯合身分使用者匯入 OpsWorks Stacks。如需如何執行此操作的詳細資訊，請參閱《[AWS 安全部落格》中的使用 Windows Active Directory、ADFS 和 SAML 2.0 啟用與](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/) AWS [的聯合，以及《IAM 使用者指南》中的聯合現有使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_identity-management.html#intro-identity-federation)。 ** # 步驟 2：建立基本應用程式伺服器堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。基本應用程式伺服器堆疊包含一個具有公有 IP 地址的應用程式伺服器執行個體，以接收使用者請求。應用程式程式碼和任何相關檔案均存放於單獨的儲存庫中，並從該位置部署到伺服器。下圖說明此類堆疊。 ![\[Diagram showing application server stack with Windows instance, IIS layer, and AWS cloud integration.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch_2_windows.png) 該堆疊具有下列元件： + *layer* 代表執行個體的群組，並指定設定它們的方式。此範例中的 layer 代表 IIS 執行個體群組。 + *執行個體*，代表 Amazon EC2 執行個體。在此案例中，layer 設定單一執行個體以執行 IIS，但 layer 可具有任意數目的執行個體。 + 「應用程式」**包含在執行個體上安裝應用程式的必要資訊。 + 「技術指南」**包含支援自訂 IIS layer 的 Chef 配方。技術指南和應用程式程式碼存放在遠端儲存庫中，例如 Amazon S3 儲存貯體或 Git 儲存庫中的封存檔案。下列各節說明如何使用 OpsWorks Stacks 主控台來建立堆疊並部署應用程式。 **Topics** + [步驟 2.1：建立堆疊](gettingstarted-windows-stack.md) + [步驟 2.2：授權 RDP 存取](gettingstarted-windows-rdp.md) + [步驟 2.3：實作自訂技術指南](gettingstarted-windows-cookbook.md) + [步驟 2.4：新增 IIS Layer](gettingstarted-windows-iis-layer.md) + [步驟 2.5：部署應用程式](gettingstarted-windows-deploy.md) # 步驟 2.1：建立堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以透過建立堆疊來啟動 OpsWorks Stacks 專案，堆疊可做為執行個體和其他資源的容器。堆疊組態會指定某些由堆疊的所有執行個體共享之基本設定，如 AWS 區域和預設作業系統。 **建立新堆疊** 1. **新增堆疊** 如果您尚未執行此作業，請登入 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)。 + 若帳戶沒有任何現有的堆疊，您會看到 **Welcome to AWS OpsWorks (歡迎使用 AWS OpsWorks)** 頁面。請選擇 **Add your first stack (新增您的第一個堆疊)**。 + 否則，您會看到 OpsWorks Stacks 儀表板，其中列出您帳戶的堆疊；選擇**新增堆疊**。 1. **設定堆疊** 在 **Add Stack (新增堆疊)** 頁面上，選擇 **Chef 12 stack (Chef 12 堆疊)** 並指定下列設定： **Stack name (堆疊名稱)** 輸入堆疊的名稱，其中可包含英數字元 (a–z、A–Z 和 0–9) 和連字號 (-)。本演練的範例堆疊名為 **IISWalkthrough**。 **區域** 選取美國西部（奧勒岡）做為堆疊的區域。您可以在任何區域中建立堆疊，但我們建議美國西部（奧勒岡）進行教學課程。 **預設作業系統** 選擇 **Windows**，然後指定 **Microsoft Windows Server 2022 Base**，這是預設設定。 **使用自訂 Chef 技術指南** 針對本演練的用途，請為此選項指定 **No (否)**。 1. 選擇 **Advanced (進階)** 以確認您已選取一個 IAM 角色，以及預設的 IAM 執行個體描述檔。 IAM 角色指定堆疊的 IAM (AWS Identity and Access Management) 角色。 OpsWorks Stacks 需要存取其他 AWS 服務才能執行任務，例如建立和管理 Amazon EC2 執行個體。**IAM 角色**會指定 OpsWorks Stacks 擔任的角色，以代表您使用其他 AWS 服務。如需詳細資訊，請參閱[允許 OpsWorks Stacks 代表您採取行動](opsworks-security-servicerole.md)。 + 如果您的帳戶具有現有的 OpsWorks Stacks IAM 角色，您可以從清單中選取它。如果角色是由 OpsWorks Stacks 建立，則會命名為 `aws-opsworks-service-role`。 + 否則，請選取**新 IAM 角色**以指示 OpsWorks Stacks 為您建立具有正確許可的新角色。 **注意：**如果您有 OpsWorks Stacks 完整存取許可，則建立新角色需要幾個額外的 IAM 許可。如需詳細資訊，請參閱[範例政策](opsworks-security-users-examples.md)。 1. 接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)**。如需各種堆疊設定的詳細資訊，請參閱 [建立新的堆疊](workingstacks-creating.md)。 # 步驟 2.2：授權 RDP 存取 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在您已建立堆疊，接下來您將建立一個 layer，並將 Windows 執行個體新增至該 layer。但是，您必須先設定堆疊以讓您使用 RDP 連線到自訂 layer 的執行個體，然後才能執行上述作業。對此，您必須執行下列作業： + 將傳入規則新增至控制 RDP 存取的安全群組。 + 設定此堆疊的 OpsWorks Stacks 許可，以允許 RDP 存取。當您在區域中建立第一個堆疊時， OpsWorks Stacks 會建立一組安全群組。其中包括一個名為的物件`AWS-OpsWorks-RDP-Server`，例如， Stacks OpsWorks 會連接到所有 Windows 執行個體以允許 RDP 存取。不過，此安全群組預設沒有任何規則，因此您必須新增傳入規則來允許 RDP 存取您的執行個體。 **允許 RDP 存取** 1. 開啟 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/v2/)，將其設定為堆疊的區域，然後從導覽窗格中選擇**安全群組**。 1. 選擇 **AWS-OpsWorks-RDP-Server**，並選擇 **Inbound (傳入)** 標籤，然後選擇 **Edit (編輯)**。 1. 選擇 **Add Rule (新增規則)**，然後指定下列設定： + **類型** – **RDP**。 + **來源** – 允許的來源 IP 地址。通常，您會允許來自您 IP 地址或指定 IP 地址範圍 (通常是公司的 IP 地址範圍) 的傳入 RDP 請求。針對學習用途，通常指定 0.0.0.0/0 已足夠，這會允許來自任何 IP 地址的 RDP 存取。此安全群組允許執行個體接收 RDP 連線請求，但這只是此安全群組所能發揮的一半作用。一般使用者將使用 Stacks OpsWorks 提供的密碼登入執行個體。若要讓 OpsWorks Stacks 產生該密碼，您必須明確授權使用者的 RDP 存取。 **為使用者授權 RDP** 1. 在 OpsWorks Stacks 儀表板中，選擇 **IISWalkthrough** 堆疊。 1. 在該堆疊的導覽窗格中選擇 **Permissions (許可)**。 1. 在許可頁面上，選擇 **Edit (編輯)**。 1. 在使用者清單中，選取您要授予必要許可之使用者的 **SSH/RDP** 核取方塊。如果您希望使用者也具有管理員許可，請同時選取 **sudo/admin**。 ![\[使用者的 SSH 與 sudo 許可\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions.png) 1. 選擇**儲存**。使用者隨即可以取得密碼，並用來登入執行個體，如下文所述。 **注意** 您也可以使用管理員身分登入。如需詳細資訊，請參閱[以管理員身分登入](workinginstances-rdp.md#workinginstances-rdp-admin)。 # 步驟 2.3：實作自訂技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。儘管堆疊基本上是執行個體的容器，但您無法直接將執行個體新增到堆疊。您將會新增一或多個 layer，每一個代表相關執行個體的群組，然後將執行個體新增至這些 layer。 layer 基本上是 Stacks OpsWorks 用來建立一組具有相同組態的 Amazon EC2 執行個體的藍圖。執行個體從基礎版本的作業系統開始，且執行個體的 layer 會在執行個體上執行各種任務來實作該藍圖，這些任務可能包括： + 建立目錄和檔案 + 管理使用者 + 安裝並設定軟體 + 啟動或停止伺服器 + 部署應用程式程式碼以及相關檔案。 layer 會透過執行 [Chef 配方](https://docs.chef.io/recipes.html)在執行個體上執行任務，簡稱為配方。配方是使用 Chef 網域專用語言 (DSL) 來描述執行個體最終狀態的 Ruby 應用程式。透過 OpsWorks Stacks，每個配方通常會指派給 layer 的生命週期[事件](workingcookbook-events.md)之一：設定、組態、部署、取消部署和關機。當執行個體上發生生命週期事件時， OpsWorks Stacks 會執行事件的配方來執行適當的任務。例如，安裝事件會在執行個體完成開機後發生。 OpsWorks 堆疊接著會執行安裝配方，通常會執行安裝和設定伺服器軟體以及啟動相關服務等任務。 OpsWorks Stacks 為每個 layer 提供一組執行標準任務的內建配方。您可以實作自訂配方來執行額外任務，並將其指派到 layer 的生命週期事件，以擴展 layer 的功能。Windows 堆疊支援[自訂 layer](workinglayers-custom.md)，這些 layer 具有一組僅執行幾項基本任務的最少量配方。若要將功能新增至您的 Windows 執行個體，您必須實作自訂配方來安裝軟體、部署應用程式等等。本主題說明如何建立簡單的自訂 layer 來支援 IIS 執行個體。 **Topics** + [技術指南和配方的快速簡介](#gettingstarted-windows-layer-recipes) + [實作配方來安裝和啟動 IIS](#gettingstarted-windows-layer-recipe-iis) + [啟用自訂技術指南](#gettingstarted-windows-layer-enable-cookbook) ## 技術指南和配方的快速簡介配方定義執行個體預期狀態的一或多個 layer 面：應包含哪些目錄、應安裝哪些軟體套件、應部署哪些應用程式等等。配方封裝在「技術指南」**中，而技術指南可以包含一或多個相關配方，再加上相關檔案 (例如建立組態檔案的範本)。本主題為配方做了基本的介紹，足以為您示範如何實作技術指南以支援簡單的自訂 IIS layer。如需技術指南一般簡介的詳細資訊，請參閱 [技術指南和配方](workingcookbook.md)。如需詳細的實作技術指南教學介紹，包括某些 Windows 特定主題，請參閱[技術指南 101](cookbooks-101.md)。技術上而言，Chef 配方是 Ruby 應用程式，但大部分 (如非全部) 程式碼位於 Chef DSL 中。DSL 主要由一組「資源」**組成，可用於宣告性指定執行個體狀態的某一 layer 面。例如，[`directory` 資源](https://docs.chef.io/chef/resources.html#directory)會定義要新增至系統的目錄。下列範例定義一個具有完整控制權的 `C:\data` 目錄，此目錄屬於指定使用者，且不會從父目錄繼承權限。 ``` directory 'C:\data' do rights :full_control, 'WORKGROUP\username' inherits false action :create end ``` 當 Chef 執行配方時，會透過將資料傳遞給相關聯的「提供者」**(這是處理修改執行個體狀態詳細資訊的 Ruby 物件) 來執行每項資源。在此範例中，供應者會使用指定組態來建立新目錄。自訂 IIS layer 的自訂技術指南必須執行下列任務： + 安裝 IIS 功能，並開始服務。您通常會在完成啟動執行個體後的安裝期間執行此任務。 + 將應用程式部署到執行個體 (此範例中為一個簡單的 HTML 頁面)。您通常會在設定期間執行此任務。不過，應用程式通常需要定期更新，所以您也需要在執行個體處於上線狀態時部署更新。您可以使用單一配方來執行所有這些任務。但是，首選方法是將單獨的配方用於設定和部署任務。這樣一來，您無需執行設定程式碼，也可隨時部署應用程式更新。下列說明如何設定技術指南來支援自訂 IIS layer。後續主題將說明如何實作配方。 **開始使用** 1. 在您的工作站中方便的位置上，建立名為 `iis-cookbook` 的目錄。 1. 將具有下列內容的 `metadata.rb` 檔案新增至 `iis-cookbook`。 ``` name "iis-cookbook" version "0.1.0" ``` 此範例使用最少量的 `metadata.rb`。如需如何使用此檔案的詳細資訊，請參閱 [metadata.rb](https://docs.chef.io/config_rb_metadata.html)。 1. 將 `recipes` 目錄新增至 `iis-cookbook`。此目錄 (必須命名為 `recipes`) 包含技術指南的配方。一般而言，技術指南可以包含各種其他目錄。例如，如果配方使用範本來建立組態檔案，範本通常會位於 `templates\default` 目錄中。此範例的技術指南完全由配方所組成，所以不需要其他目錄。此外，此範例僅使用單一技術指南，但您可以使用所需數量的技術指南；針對複雜的專案，通常使用多個技術指南會更適當。例如，針對設定和部署任務，您可以使用個別的技術指南。如需更多技術指南範例，請參閱 [技術指南和配方](workingcookbook.md)。 ## 實作配方來安裝和啟動 IIS IIS 是一項 Windows「功能」**，是可安裝在 Windows Server 上的選用系統元件之一。您可以讓配方透過下列其中一種方法來安裝 IIS： + 透過使用 [https://docs.chef.io/chef/resources.html#powershell-script](https://docs.chef.io/chef/resources.html#powershell-script) 資源，來執行 [https://docs.microsoft.com/en-us/powershell/module/servermanager/install-windowsfeature?view=winserver2012-ps](https://docs.microsoft.com/en-us/powershell/module/servermanager/install-windowsfeature?view=winserver2012-ps) cmdlet。 + 透過使用 Chef [ Windows 技術指南](https://github.com/opscode-cookbooks/windows)的 `windows_feature` 資源。 `windows` 技術指南包含一組資源，這些資源的供應者使用[部署映像服務和管理](https://technet.microsoft.com/en-us/library/dd744256%28v=ws.10%29.aspx) (DISM) 在 Windows 執行個體上執行各種任務，包括功能安裝。 **注意** `powershell_script` 位於 Windows 配方的最有用資源之間。您可使用其透過執行適當的 PowerShell 指令碼或 cmdlet 在執行個體上執行各種任務。尤其適用於不受 Chef 資源支援的任務。此範例使用 PowerShell 指令碼來安裝和啟動 Web Server (IIS)。下文將介紹 `windows` 技術指南。如需如何使用 `windows_feature` 來安裝 IIS 的範例，請參閱 [安裝 Windows 功能：IIS](cookbooks-101-opsworks-install-software-feature.md) 將下列內容和名為 `install.rb` 的配方新增至技術指南的 `recipes` 目錄。 ``` powershell_script 'Install IIS' do code 'Install-WindowsFeature Web-Server' not_if "(Get-WindowsFeature -Name Web-Server).Installed" end service 'w3svc' do action [:start, :enable] end ``` 此配方包含兩種資源。 **powershell\$1script** `powershell_script` 執行指定的 PowerShell 指令碼或 cmdlet。此範例具有下列屬性設定： + `code` – 要執行的 PowerShell cmdlet。此範例執行 `Install-WindowsFeature` cmdlet，這會安裝 Web 伺服器 (IIS)。一般而言，`code` 屬性可以具有任意數目的行，因此您可以執行所需數量的 cmdlet。 + `not-if` – [確保配方僅在尚未安裝 IIS 時才安裝的*防護屬性*](https://docs.chef.io/chef/resources.html#guards)。您通常會希望配方是「等冪」**，因此配方不會浪費時間重複執行相同的任務。每個資源都有一個動作，指定提供者要採取的動作。在此範例中沒有明確的動作，因此供應者會採取預設 `:run` 動作，該動作會執行指定 PowerShell 指令碼。如需詳細資訊，請參閱[執行 Windows PowerShell 指令碼](cookbooks-101-opsworks-opsworks-powershell.md)。 **服務** 一個 [https://docs.chef.io/chef/resources.html#service](https://docs.chef.io/chef/resources.html#service) 管理一項服務，在此範例中為 Web Server IIS 服務 (W3SVC)。此範例使用預設屬性並指定 `:start` 與 `:enable` 這兩個動作來啟動和啟用 IIS。 **注意** 如果您希望安裝使用套件安裝程式的軟體 (例如 MSI)，您可以使用 `windows_package` 資源。如需詳細資訊，請參閱[安裝套件](cookbooks-101-opsworks-install-software-package.md)。 ## 啟用自訂技術指南 OpsWorks Stacks 會在每個執行個體上從本機快取執行配方。若要執行您的自訂配方，您必須執行下列作業： + 將技術指南存放在遠端儲存庫中。 OpsWorks Stacks 會將技術指南從此儲存庫下載到每個執行個體的本機快取。 + 編輯堆疊以啟用自訂技術指南。自訂技術指南預設為停用，所以您必須為堆疊啟用自訂技術指南，並提供儲存庫的 URL 和相關資訊。 OpsWorks Stacks 支援自訂技術指南的 S3 封存和 Git 儲存庫；此範例使用 S3 封存。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。 **使用 S3 封存** 1. 建立 `iis-cookbook` 目錄的 `.zip` 存檔。 OpsWorks Stacks 也支援 Windows 堆疊的 `.tgz`(gzip 壓縮 tar) 封存。 1. 將封存上傳至美國西部（加利佛尼亞北部）區域的 S3 儲存貯體，並將檔案設為公有。您也可以使用私有 S3 封存，但在這個範例中公有封存已足夠，且使用起來更簡單。 1. 登入 AWS 管理主控台並開啟位於 https：//[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) 的 Amazon S3 主控台。 1. 如果您在中還沒有儲存貯體`us-west-1`，請選擇**建立儲存貯**體，並在美國西部（加利佛尼亞北部）區域中建立儲存貯體。 1. 在儲存貯體清單中，選擇您要上傳檔案的儲存貯體名稱，然後選擇 **Upload (上傳)**。 1. 選擇 **Add Files (新增檔案)**。 1. 選取要上傳的存檔，然後選擇 **Open (開啟)**。 1. 在 **Upload - Select Files and Folders (上傳 - 選取檔案與資料夾)** 對話方塊的底部，選擇 **Set Details (設定詳細資訊)**。 1. 在 **Set Details (設定詳細資訊)** 對話方塊中，選擇 **Set Permissions (設定許可)**。 1. 在 **Set Permissions (設定許可)** 對話方塊中，選擇 **Make everything public (公開所有項目)**。 1. 在 **Set Permissions (設定許可)** 對話方塊中，選擇 **Start Upload (開始上傳)**。上傳完成時，`iis-cookbook.zip` 檔案會出現在您的儲存貯體中。 1. 選擇儲存貯體，然後選擇儲存貯體的 **Properties (屬性)** 標籤。在 **Link (連結)** 旁，記錄封存檔案的 URL 以供日後使用。如需將檔案上傳至 Amazon S3 儲存貯體的詳細資訊，請參閱《Amazon [ S3 主控台使用者指南》中的如何將檔案和資料夾上傳至 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)。 *Amazon S3 * **重要** 到目前為止，本演練只需您稍微花一點時間； OpsWorks Stacks 服務本身是免費的。不過，您必須支付您使用的任何 AWS 資源，例如 Amazon S3 儲存體。一旦您上傳封存，即會開始產生費用。如需詳細資訊，請參閱 [AWS 定價](https://aws.amazon.com/pricing/)。 **為堆疊啟用自訂技術指南。** 1. 在 OpsWorks Stacks 主控台的導覽窗格中，選擇 **Stack**，然後選擇右上角的**堆疊設定**。 1. 在 **Settings (設定)** 頁面的右上角，選擇 **Edit (編輯)**。 1. 在 **Settings (設定)** 頁面上，將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 設定為 **Yes (是)** 然後輸入下列資訊： + 儲存庫類型 – **S3 Archive**。 + 儲存庫 URL – 您先前記錄之技術指南封存檔案的 S3 URL。 1. 選擇 **Save (儲存)** 來更新堆疊組態。 OpsWorks Stacks 會在所有新的執行個體上安裝您的自訂技術指南。請注意， OpsWorks Stacks 不會自動在線上執行個體上安裝或更新自訂技術指南。您可以手動執行此作業，如下所述。 # 步驟 2.4：新增 IIS Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您的技術指南具有一個安裝和啟動 IIS 的配方。這足以用來建立 layer，並確認您具有正在運作的 IIS 執行個體。之後，您會將應用程式部署功能新增到 layer。 ## 建立 Layer 首先，將 layer 新增堆疊。然後，透過指派自訂配方至適當的生命週期事件，以將功能新增至該 layer。 **將 IIS layer 新增至堆疊** 1. 在導覽窗格中，選擇 **Layers (Layer)**，然後選擇 **Add a layer (新增 layer)**。 1. 如下所示來設定 layer： + **名稱** – **IISExample** + **簡短名稱** – **iisexample** OpsWorks Stacks 使用簡短名稱在內部識別 layer。您也可以在配方中使用短名來識別 layer，但此範例不執行此動作。您可以指定任何短名，但只能包含小寫英數字元和少量標點符號。如需詳細資訊，請參閱[自訂 Layer](workinglayers-custom.md)。 1. 選擇 **Add Layer (新增 Layer)**。如果您此時將執行個體新增至 IISWalkthrough 並將其啟動， OpsWorks Stacks 將自動安裝技術指南，但不會執行 `install.rb`。執行個體上線之後，您可以使用[執行配方堆疊命令](workingstacks-commands.md)來手動執行配方。不過，更好的方法是將配方指派給 layer 的[生命週期事件](workingcookbook-events.md)之一。然後， OpsWorks Stacks 會自動在執行個體生命週期的適當時間點執行配方。在執行個體啟動完成後立即安裝並啟動 IIS。若要這樣做，請將 `install.rb` 指派給 layer 的 `Setup` 事件。 **將配方指派給生命週期事件** 1. 在導覽窗格中選擇 **Layers (Layer)** 1. 在 **IISExample** layer 的方塊中，選擇 **Recipes (配方)**。 1. 在右上角，選擇 **Edit (編輯)**。 1. 在 **Custom Chef Recipes (自訂 Chef 配方)** 下方的 **Setup (安裝)** 配方方塊中，輸入 **iis-cookbook::install**。 **注意** 使用 `cookbook-name::recipe-name` 來識別配方，其中會省略配方名稱的 `.rb` 尾碼。 1. 選擇 **\$1** 將配方新增至 layer。紅色 x 會顯示在配方旁，以便稍後輕鬆移除。 1. 選擇 **Save (儲存)** 以儲存新組態。自訂設定配方現在應包含 `iis-cookbook::install`。 ## 將執行個體新增至 Layer 並啟動您可以透過將執行個體新增至 layer 並啟動執行個體來試用配方。當執行個體完成開機時， OpsWorks Stacks 會自動安裝技術指南並在設定`install.rb`期間執行。 **將執行個體新增至 layer 並啟動** 1. 在 OpsWorks 堆疊導覽窗格中，選擇**執行個體**。 1. 在 **IISExample** layer 下方，選擇 **Add an instance (新增執行個體)**。 1. 選取適當的大小。**t2.micro** (或可供您使用的最低大小) 對此範例應已足夠使用。 1. 選擇 **Add Instance (新增執行個體)**。根據預設， OpsWorks Stacks 會透過將整數附加至 layer 的簡短名稱來產生執行個體名稱，因此執行個體應該命名為 **iisexample1**。 1. 在執行個體**的動作**欄中選擇**開始**以啟動執行個體。然後， OpsWorks Stacks 會啟動 EC2 執行個體並執行安裝配方來設定執行個體。如果 layer 目前有任何部署配方， OpsWorks Stacks 會在安裝配方完成後執行這些配方。此程序可能需費時數分鐘，期間 **Status (狀態)** 欄會顯示一系列的狀態。當您進入 **online (線上)** 狀態時，設定程序即完成，並且執行個體已可供使用。 ## 確認 IIS 已安裝且正在執行您可以使用 RDP 連線到執行個體並驗證您的設定配方是否運作正常。 **驗證 IIS 已安裝且正在執行** 1. 在導覽窗格中選擇**執行個體**，然後在 **iisexample1** 執行個體**的動作**欄中選擇 **rdp**。 OpsWorks Stacks 會自動為您產生在指定時段後過期的 RDP 密碼。 1. 將 **Session valid for (工作階段有效期)** 設定為 2 個小時，然後選擇 **Generate Password (產生密碼)**。 1. OpsWorks Stacks 會顯示密碼，而且為了方便起見，也會顯示執行個體的公有 DNS 名稱和使用者名稱。複製全部三項，然後按一下 **Acknowledge and close (確認並關閉)**。 1. 開啟您的 RDP 用戶端，並使用步驟 3 中的資料來連線到執行個體。 1. 在執行個體上，開啟 Windows 檔案總管並檢查 `C:` 磁碟機。它應有 `C:\inetpub` 目錄，其由 IIS 安裝所建立。 1. 開啟控制台 **Administrative Tools (管理工具)** 應用程式，然後開啟 **Services (服務)**。您應該會在清單底部附近看到 IIS 服務。該服務名為 World Wide Web Publishing Service (全球資訊網發佈服務)，且狀態應為 **running (執行中)**。 1. 返回 OpsWorks Stacks 主控台並選擇 **iisexample1** 執行個體的公有 IP 地址。請務必在 OpsWorks Stacks 中執行此操作，而不是在 Amazon EC2 主控台中執行此操作。這會將 HTTP 請求自動傳送到地址，且應會開啟預設的 IIS 歡迎頁面。下一個主題討論如何部署應用程式到執行個體，以一個簡單的靜態 HTML 頁面為範例。不過，如果您想要休息，請在 **iisexample1** 執行個體**的動作**欄中選擇**停止**，以停止執行個體並避免產生不必要的費用。當您準備好繼續時，您可以重新啟動執行個體。 # 步驟 2.5：部署應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 IIS 安裝會為應用程式的程式碼和相關檔案建立 `C:\inetpub\wwwroot` 目錄。下一步是在該目錄中安裝應用程式。在此範例中，您將在 `default.html` 中安裝靜態 HTML 首頁 `C:\inetpub\wwwroot`。您可以輕鬆擴展一般方法以處理更複雜的案例，如 ASP.NET 應用程式。您可以在技術指南中包含應用程式的檔案，並讓 `install.rb` 複製這些檔案到 `C:\inetpub\wwwroot`。如需如何執行此作業的範例，請參閱 [範例 6：建立檔案](cookbooks-101-basics-files.md)。但是，此方法並不靈活且效率不高，通常更好的方法是將技術指南開發與應用程式開發分隔開來。偏好的解決方案是實作個別的部署配方，從儲存庫擷取應用程式的程式碼和相關檔案，任何您偏好的儲存庫，而不只是技術指南儲存庫，並在每個 IIS 伺服器執行個體上安裝。此方法會將技術指南開發與應用程式開發分隔開來，當您需要更新應用程式時，只需再次執行部署配方即可，無需更新技術指南。本主題說明如何實作將 `default.htm` 部署到 IIS 伺服器的簡單部署配方。您可以隨時將此範例擴展到更複雜的應用程式。 **Topics** + [建立應用程式並存放在儲存庫中。](#w2ab1c14c47c17c23c25c15) + [實作配方來部署應用程式](#w2ab1c14c47c17c23c25c17) + [更新執行個體的技術指南](#w2ab1c14c47c17c23c25c19) + [將配方新增至自訂 IIS Layer](#w2ab1c14c47c17c23c25c21) + [新增應用程式](#w2ab1c14c47c17c23c25c23) + [部署應用程式和開啟應用程式](#w2ab1c14c47c17c23c25c25) ## 建立應用程式並存放在儲存庫中。您可以為應用程式使用任何您偏好的儲存庫。為求簡化，此範例會將 `default.htm` 存放在公有 S3 儲存貯體中。 **建立應用程式** 1. 在您的工作站中方便的位置上，建立名為 `iis-application` 的目錄。 1. 將 `default.htm` 檔案新增至具有以下內容的 `iis-application`。 ``` IIS Example

Hello World!

``` 1. [建立 S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)，[將 `default.htm` 上傳到儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/gsg/PuttingAnObjectInABucket.html)，並記錄此 URL 供以後使用。為求簡化，請[將檔案設為公有](https://docs.aws.amazon.com/AmazonS3/latest/gsg/OpeningAnObject.html)。 **注意** 這是一個非常簡單的應用程式，但您可以擴展基本原則以處理生產層級的應用程式。針對具有多個檔案的更複雜應用程式，為 `iis-application` 建立 .zip 封存並將其上傳至您的 S3 儲存貯體通常會更簡單。然後，您可以下載 .zip 檔並將其內容解壓縮到適當的目錄。不需要下載多個檔案或建立目錄結構等作業。針對生產應用程式，建議您將檔案保留為私有。如需如何讓配方從私有 S3 儲存貯體下載檔案的範例，請參閱 [在 Stacks Windows 執行個體上使用適用於 Ruby OpsWorks 的 SDK](cookbooks-101-opsworks-s3-windows.md)。您可以將您的應用程式存放於任何適當的儲存庫。通常，您會使用儲存庫的公有 API 來下載應用程式。此範例使用 Amazon S3 API。例如，如果您將應用程式存放在 GitHub 上，則可以使用 [GitHub API](https://developer.github.com/guides/getting-started/)。 ## 實作配方來部署應用程式將名為 `deploy.rb` 的配方新增至 `iis-cookbook` `recipes` 目錄中，其中包含下列內容。 ``` chef_gem "aws-sdk-s3" do compile_time false action :install end ruby_block "download-object" do block do require 'aws-sdk-s3' #1 # Aws.config[:ssl_ca_bundle] = 'C:\ProgramData\Git\bin\curl-ca-bundle.crt' Aws.use_bundled_cert! #2 query = Chef::Search::Query.new app = query.search(:aws_opsworks_app, "type:other").first s3region = app[0][:environment][:S3REGION] s3bucket = app[0][:environment][:BUCKET] s3filename = app[0][:environment][:FILENAME] #3 s3_client = Aws::S3::Client.new(region: s3region) s3_client.get_object(bucket: s3bucket, key: s3filename, response_target: 'C:\inetpub\wwwroot\default.htm') end action :run end ``` 此範例使用[適用於 Ruby v2 的 SDK](https://docs.aws.amazon.com/sdkforruby/api/index.html) 下載檔案。不過， OpsWorks Stacks 不會在 Windows 執行個體上安裝此開發套件，因此配方會從處理該任務[https://docs.chef.io/chef/resources.html#chef-gem](https://docs.chef.io/chef/resources.html#chef-gem)的資源開始。 **注意** `chef_gem` 資源會將 gem 安裝到 Chef 專用的 Ruby 版本 (配方使用的版本) 中。如果您要為全系統範圍的 Ruby 版本安裝 gem，請使用 [gem\$1package](https://docs.chef.io/chef/resources.html#gem-package) 資源。大部分配方都是 [https://docs.chef.io/chef/resources.html#ruby-block](https://docs.chef.io/chef/resources.html#ruby-block) 資源，其會執行 Ruby 程式碼區塊，使用適用於 Ruby 的 SDK 下載 `default.htm`。`ruby_block` 中的程式碼可分為下列區段，這些區段分別對應於程式碼範例中的編號註解。 **1：指定憑證套件** Amazon S3 使用 SSL，因此您需要適當的憑證才能從 S3 儲存貯體下載物件。適用於 Ruby v2 的 SDK 不包含憑證套件，因此您必須提供憑證套件，並設定適用於 Ruby 的 SDK 來使用它。 OpsWorks Stacks 不會直接安裝憑證套件，但會安裝 Git，其中包含憑證套件 (`curl-ca-bundle.crt`)。為了方便起見，此範例會將適用於 Ruby 的 SDK 設定為使用適用於 SSL 的 Git 憑證套件。您也可以安裝自己的套件，並依照需要來設定軟體開發套件。 **2：擷取儲存庫資料** 若要從 Amazon S3 下載物件，您需要 AWS 區域、儲存貯體名稱和金鑰名稱。如下文所述，此範例透過將一組環境變數與應用程式建立關聯來提供此資訊。當您部署應用程式時， OpsWorks Stacks 會將一組屬性新增至執行個體的節點物件。這些屬性實際上是包含應用程式組態 (包括環境變數) 的雜湊表。此應用程式的應用程式屬性看起來會類似下列內容 (JSON 格式)。 ``` { "app_id": "8f71a9b5-de7f-451c-8505-3f35086e5bb3", "app_source": { "password": null, "revision": null, "ssh_key": null, "type": "other", "url": null, "user": null }, "attributes": { "auto_bundle_on_deploy": true, "aws_flow_ruby_settings": {}, "document_root": null, "rails_env": null }, "data_sources": [{"type": "None"}], "domains": ["iis_example_app"], "enable_ssl": false, "environment": { "S3REGION": "us-west-2", "BUCKET": "windows-example-app", "FILENAME": "default.htm" }, "name": "IIS-Example-App", "shortname": "iis_example_app", "ssl_configuration": { "certificate": null, "private_key": null, "chain": null }, "type": "other", "deploy": true } ``` 此應用程式的環境變數存放在 `[:environment]` 屬性中。若要擷取，請使用 Chef 搜尋查詢來擷取應用程式的雜湊表，位於 `aws_opsworks_app` 節點之下。此應用程式定義為 `other` 類型，因此查詢會搜尋該類型的應用程式。配方會利用此執行個體上只有一個應用程式的事實，因此特定的雜湊表為 `app[0]`。為了方便起見，配方隨後會將區域、儲存貯體和檔案名稱指派至變數。如需如何使用 Chef 搜尋的詳細資訊，請參閱 [使用 Chef 搜尋取得屬性值](cookbooks-101-opsworks-opsworks-stack-config-search.md)。 **3：下載檔案** 配方的第三個部分是建立 [S3 用戶端物件](https://docs.aws.amazon.com/sdkforruby/api/Aws/S3/Client.html) 並使用其 `[get\$1object](https://docs.aws.amazon.com/sdkforruby/api/Aws/S3/Client.html#get_object-instance_method)` 方法來下載 `default.htm` 到執行個體的 `C:\inetpub\wwwroot` 目錄。 **注意** 配方是 Ruby 應用程式，因此 Ruby 程式碼不一定需要位於 `ruby_block` 中。不過，配方主體中的程式碼會先執行，接著才會執行資源。在此範例中，如果您將下載程式碼放在配方內文中，它會失敗，因為`chef_gem`資源尚未安裝適用於 Ruby 的 SDK。`ruby_block` 資源中的程式碼會在資源執行時，在`chef_gem`資源安裝適用於 Ruby 的 SDK 之後執行。 ## 更新執行個體的技術指南 OpsWorks Stacks 會自動在新的執行個體上安裝自訂技術指南。但是因為您正在使用現有的執行個體，所以您必須手動更新技術指南。 **更新執行個體的技術指南** 1. 建立 `iis-cookbook` 的 `.zip` 存檔，並將其上傳至 S3 儲存貯體。這會覆寫現有的技術指南，但 URL 會保持不變，因此您不需要更新堆疊組態。 1. 如果您的執行個體並未處於線上狀態，請將其重新啟動。 1. 在執行個體上線之後，在導覽窗格中選擇 **Stack (堆疊)**，然後選擇 **Run Command (執行命令)**。 1. 針對 **Command (命令)**，選擇 [Update Custom Cookbooks (更新自訂技術指南)](workingstacks-commands.md)。此命令會在執行個體上安裝更新技術指南。 1. 選擇 **Update Custom Cookbooks (更新自訂技術指南)**。此命令可能需要幾分鐘的時間來完成。 ## 將配方新增至自訂 IIS Layer 如同 `install.rb` 一樣，處理部署的較佳方式是將 `deploy.rb` 指派給適當的生命週期事件。您通常會將部署配方指派至部署事件，並統稱為部署配方。將配方指派至部署事件不會觸發此事件。反之： + 對於新的執行個體， OpsWorks Stacks 會在設定配方完成後自動執行部署配方，因此新的執行個體會自動擁有目前的應用程式版本。 + 針對線上執行個體，請使用[部署命令](workingapps-deploying.md)來手動安裝新的或更新應用程式。此命令會在堆疊的執行個體上觸發部署事件，該事件會執行部署配方。 **將 deploy.rb 指派給 layer 的部署事件** 1. 在導覽窗格中選擇 **Layers (Layer)**，然後在 **Layer IISExample** 下方選擇 **Recipes (配方)**。 1. 在 **Custom Chef Recipes (自訂 Chef 配方)** 下，將 **iis-cookbook::deploy** 新增至 **Deploy (部署)** 配方方塊，並選擇 **\$1** 來將配方新增至 layer。 1. 選擇 **Save (儲存)** 以儲存新組態。自訂部署配方現在應包含 `iis-cookbook::deploy`。 ## 新增應用程式最後一個任務是將應用程式新增至堆疊，以在 Stacks OpsWorks 環境中代表您的應用程式。應用程式包含中繼資料 (如應用程式的顯示名稱) 和從儲存庫下載的應用程式所需資料。 **將應用程式新增至堆疊** 1. 在導覽窗格中選擇 **Apps (應用程式)**，然後選擇 **Add an app (新增應用程式)**。 1. 使用以下設定來設定應用程式。 + **名稱** – I**IIS-Example-App** + **儲存庫類型** – **其他** + **環境變數** – 新增下列三個環境變數： + **S3REGION** – 儲存貯體的區域（在此情況下為 `us-west-1`)。 + **BUCKET** – 儲存貯體名稱，例如 `windows-example-app`。 + **FILENAME** – 檔案名稱：**default.htm**。 1. 接受其餘設定的預設值，然後選擇 **Add App (新增應用程式)** 將應用程式新增至堆疊。 **注意** 此範例使用環境變數來提供下載資料。另一種方法是使用 S3 Archive 儲存庫類型，並提供檔案的 URL。 OpsWorks Stacks 會將資訊以及選用的資料，例如您的 AWS 登入資料，新增至應用程式的 `app_source` 屬性。您的部署配方必須從應用程式屬性中取得 URL 並進行剖析，以擷取區域、儲存貯體名稱和檔案名稱。 ## 部署應用程式和開啟應用程式 OpsWorks Stacks 會自動將應用程式部署到新執行個體，但不會部署到線上執行個體。由於您的執行個體已在執行中，因此您必須手動部署應用程式。 **部署應用程式** 1. 在導覽窗格中選擇 **Apps (應用程式)**，然後在應用程式的 **Actions (動作)** 欄中選擇 **deploy (部署)**。 1. **Command (命令)** 應該設為 **Deploy (部署)**。選擇 **Deploy App (部署應用程式)** 頁面右下方的 **Deploy (部署)**。此命令可能需要幾分鐘的時間來完成。在部署完成後，您可以返回 **Apps (應用程式)** 頁面。**Status (狀態)** 指標會顯示綠色的 **successful (成功)**，且應用程式名稱旁會顯示綠色核取標記，指出部署成功。 **注意** Windows 應用程式一律為 **Other (其他)** 應用程式類型，因此部署應用程式會執行下列作業：將應用程式的資料新增至[堆疊組態和部署屬性](workingcookbook-json.md)，如前所述。在堆疊的執行個體上觸發部署事件，該事件會執行您的自訂部署配方。 **注意** 如需如何故障診斷故障之部署或應用程式的詳細資訊，請參閱[除錯配方](troubleshoot-debug.md)。應用程式現在已安裝。您可以在**導覽**窗格中選擇**執行個體**，然後選擇執行個體的公有 IP 地址來開啟它。這會將 HTTP 請求傳送到執行個體，您應該會在瀏覽器中看到類似以下的內容。 ![\[Text displaying "Hello World!" in large, bold font against a white background.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/windows-iis-app.png) # 步驟 3：橫向擴展 IISExample **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果您的傳入使用者請求數量開始接近您可透過單一 t2.micro 執行個體處理之請求限制，則您需要增加伺服器容量。您可以移至較大的執行個體，但具有限制。更靈活的方法是將執行個體新增到您的堆疊，然後將其放置在負載平衡器後方。此基本架構看起來類似下列內容。 ![\[OpsWorks stack architecture with load balancer, Windows instances, and external repositories.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch_4_windows.png) 除了其他優勢以外，此方法比單一大型執行個體更穩健。 + 如果其中某個執行個體故障，負載平衡器會將傳入請求分配到其餘的執行個體，且您的應用程式可繼續運作。 + 如果您將執行個體放置在不同的可用區域 (建議的實務)，即使某個可用區域遇到問題，您的應用程式仍將繼續運作。 OpsWorks Stacks 可讓您輕鬆地向外擴展堆疊。本節說明如何將第二個全年無休 PHP App Server 執行個體新增至 IISExample，並將兩個執行個體放在 Elastic Load Balancing 負載平衡器後方，以擴展堆疊的基本概念。您可以輕鬆擴展程序來新增 24 小時全年無休的任意執行個體，也可以使用時間型執行個體讓 OpsWorks Stacks 自動擴展您的堆疊。如需詳細資訊，請參閱[使用時間型和負載型執行個體管理負載](workinginstances-autoscaling.md)。 # 新增負載平衡器 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Elastic Load Balancing 是一種 AWS 服務，可在多個 Amazon EC2 執行個體之間自動分配傳入的應用程式流量。負載平衡器有兩種用途。其中一個顯而易見的用途，是使應用程式伺服器上的負載達到均衡。許多網站都偏好隔離其應用程式伺服器和資料庫，讓使用者無法直接存取。除了分佈流量之外，Elastic Load Balancing 還會執行下列動作： + 偵測運作狀態不佳的 Amazon EC2 執行個體。它會將流量重新路由至狀況良好的執行個體，直到狀況不良的執行個體恢復為止。 + 自動擴展處理容量的請求，以回應傳入的流量。 **注意** OpsWorks Stacks 不支援 Application Load Balancer。您只能搭配 OpsWorks Stacks 使用 Classic Load Balancer。雖然 Elastic Load Balancing 通常稱為 layer，但其運作方式與其他內建 layer 略有不同。您可以使用 Amazon EC2 主控台建立 Elastic Load Balancing 負載平衡器，然後將其連接到其中一個現有 layer，通常是應用程式伺服器 layer。 OpsWorks Stacks 接著會向服務註冊 layer 的現有執行個體，並自動新增任何新執行個體。下列程序說明如何新增負載平衡器。 **將負載平衡器連接至自訂 IIS layer** 1. 使用 Amazon EC2 主控台為 IISExample 建立新的負載平衡器。如需詳細資訊，請參閱 [Elastic Load Balancing 入門](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html)。當您執行 **Create Load Balancer (建立負載平衡器)** 精靈時，請設定負載平衡器，如下所示： **1: Define Load Balancer (定義負載平衡器)** 為負載平衡器指派易於識別的名稱，例如 IIS-LB，以便更輕鬆地在 Stacks OpsWorks 主控台中找到。接受其餘設定的預設值，然後選擇 **Next: Assign Security Groups (下一步：指派安全群組)**。 **2: Assign Security Groups (指派安全群組)** 如果您的帳戶支援預設 VPC，精靈會顯示此頁面以決定負載平衡器的安全群組。但不會為 EC2 Classic 顯示此頁面。在本演練中，指定 **default VPC security group (預設 VPC 安全群組)**，然後選擇 **Next: Configure Security Settings (下一步：設定安全設定)**。 **3: Configure Security Settings (設定安全設定)** 本演練需要您的負載平衡器使用安全接聽程式 (也就是在其前端連線使用 HTTPS 或 SSL)，因此請選擇 **Next: Configure Health Check (下一步：設定運作狀態檢查)** 以繼續。 **4: Configure Health Check (設定運作狀態檢查)** 將 ping 路徑設定為 **/**。接受其餘設定的預設值，然後選擇 **Next: Add EC2 Instances (下一步：新增 EC2 執行個體)**。 **5: Add EC2 Instances (新增 EC2 執行個體)** OpsWorks Stacks 會自動負責向負載平衡器註冊執行個體。選擇 **Next: Add Tags (下一步：新增標籤)** 以繼續。 **6: Add Tags (新增標籤)** 在此範例中，您不需要使用標籤。選擇 **Review and Create (檢閱和建立)**。 **7: Review (檢閱)** 檢閱您的選擇，並選擇 **Create (建立)**，然後選擇 **Close (關閉)**，這會啟動負載平衡器。 1. 如果您的帳戶支援預設 VPC，則在您啟動負載平衡器之後，必須確保其安全群組具有適當的傳入規則。預設規則不接受任何傳入流量。 1. 在 Amazon EC2 導覽窗格中選擇**安全群組**。 1. 選擇 **default VPC security group (預設 VPC 安全群組)**。 1. 在 **Inbound (傳入)** 標籤上，選擇 **Edit (編輯)**。 1. 在本演練中，將 **Source (來源)** 設定為 **Anywhere (隨處)**，以指示負載平衡器接受來自任何 IP 地址的傳入流量。 1. 按一下 **Save (儲存)**。 1. 返回 OpsWorks Stacks 主控台。在 **Layers (Layer)** 頁面上，選擇 **Network (網路)**。 1. 在 **Elastic Load Balancing** 下，選取您在步驟 1 建立的 IIS-LB 負載平衡器，然後按一下 **Save (儲存)**。將負載平衡器連接到 layer 之後， OpsWorks Stacks 會自動註冊 layer 的目前執行個體，並在新執行個體上線時新增執行個體。 1. 在 **Layers (Layer)** 頁面上，按一下負載平衡器的名稱，以開啟其詳細資訊頁面。負載平衡器頁面上的執行個體旁之綠色核取標記指出該執行個體已通過運作狀態檢查。您現在可以將請求傳送到負載平衡器來執行 IIS-Example-App。 **透過負載平衡器執行 IIS-Example-App** 1. 選擇 **Layers (Layer)**。IIS-ELB 負載平衡器應做為 layer 列出，且運作狀態欄應有一個綠色的執行個體，指出該執行個體運作狀態良好。 1. 選擇負載平衡器的 DNS 名稱來執行 IIS-Example-App。應會列在負載平衡器的名稱下方，看起來類似於 `IIS-LB-1802910859.us-west-2.elb.amazonaws.com`。負載平衡器會將請求轉遞給執行個體，並傳回回應，而此回應看起來應該與您按一下執行個體的公有 IP 地址時所取得的回應完全相同。此時您只有一個執行個體，所以負載平衡器實際上並未新增更多執行個體。不過，您現在可以將額外的執行個體新增至 layer。 **將執行個體新增至 layer** 1. 選擇 **Instances (執行個體)**，然後選擇 **\$1 instance (\$1 執行個體)** 將其他執行個體新增至 layer。 1. 啟動實例。由於它們是新的執行個體， OpsWorks Stacks 會自動安裝目前的自訂技術指南，並在設定期間部署目前的應用程式版本。當執行個體上線時， OpsWorks Stacks 會自動將其新增至負載平衡器，因此您的執行個體會立即開始處理請求。若要驗證應用程式是否仍在運作，您可以選擇負載平衡器的 DNS 名稱。 # 後續步驟 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本演練帶領您完成設定簡易 Windows 應用程式伺服器堆疊的基本作業。以下是有關後續作業的一些建議。 + 如果您想要進一步了解， [入門：技術指南](gettingstarted-cookbooks.md)會提供實作技術指南的教學簡介，並包含許多 OpsWorks Stacks 特定的範例。 + 您可以將 [Amazon Relational Database Service (Amazon RDS) 層](workinglayers-db-rds.md)新增至堆疊，以用作後端資料庫伺服器。如需如何將應用程式連線至資料庫的資訊，請參閱 [使用自訂配方](workingapps-connectdb.md#workingapps-connectdb-custom)。 # Stacks OpsWorks 中的技術指南入門 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。生產層級 OpsWorks 的 Stacks 堆疊通常需要一些自訂，這通常表示實作自訂的 Chef 技術指南。「技術指南」**為包含組態資訊 (其中包含稱為「配方」**的指示) 的套件檔案。「配方」**為一組一或多個以 Ruby 語言語法撰寫的指示，指定要使用的資源以及套用那些資源的順序。Chef 中所使用的「資源」**為組態政策的陳述式。本演練提供實作 Stacks Chef OpsWorks 技術指南的基本簡介。若要進一步了解 Chef、技術指南、配方及資源，請參閱[後續步驟](gettingstarted-cookbooks-next-steps.md)中的連結。本演練主要說明如何建立您自己的技術指南。您也可以使用社群提供的技術指南，這可在 [Chef Supermarket](https://supermarket.chef.io) 這類網站上取得。為協助您開始使用社群技術指南，後續的演練將包含使用來自 Chef Supermarket 的社群技術指南說明。在您開始本演練前，請完成幾個設定步驟。若您已完成本章中的其他演練 (例如[入門：範例](gettingstarted-intro.md))，您即完成本演練的事前準備，可直接跳到[開始本演練](gettingstarted-cookbooks-create-cookbook.md)。否則，請務必完成[事前準備](gettingstarted-intro-prerequisites.md)，然後再返回本演練。 **Topics** + [步驟 1：建立技術指南](gettingstarted-cookbooks-create-cookbook.md) + [步驟 2：建立堆疊及其元件](gettingstarted-cookbooks-create-stack.md) + [步驟 3：執行及測試配方](gettingstarted-cookbooks-test-recipe.md) + [步驟 4：更新技術指南以安裝套件](gettingstarted-cookbooks-install-package.md) + [步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md) + [步驟 6：更新技術指南以新增使用者](gettingstarted-cookbooks-add-user.md) + [步驟 7：更新技術指南以建立目錄](gettingstarted-cookbooks-create-directory.md) + [步驟 8：更新技術指南以建立及複製檔案](gettingstarted-cookbooks-create-file.md) + [步驟 9：更新技術指南以執行命令](gettingstarted-cookbooks-run-command.md) + [步驟 10：更新技術指南以執行指令碼](gettingstarted-cookbooks-run-script.md) + [步驟 11：更新技術指南以管理服務](gettingstarted-cookbooks-manage-service.md) + [步驟 12：更新技術指南以使用自訂 JSON](gettingstarted-cookbooks-custom-json.md) + [步驟 13：更新技術指南以使用資料包](gettingstarted-cookbooks-data-bags.md) + [步驟 14：更新技術指南以使用反覆運算](gettingstarted-cookbooks-iteration.md) + [步驟 15：更新技術指南以使用條件式邏輯](gettingstarted-cookbooks-conditional-logic.md) + [步驟 16：更新技術指南以使用社群技術指南](gettingstarted-cookbooks-community-cookbooks.md) + [步驟 17：(選用) 清除](gettingstarted-cookbooks-clean-up.md) + [後續步驟](gettingstarted-cookbooks-next-steps.md) # 步驟 1：建立技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。從建立技術指南開始。此技術指南對開始作用不大，但它會作為本演練其餘部分的基礎。 **注意** 此步驟示範如何手動建立技術指南。您可以透過使用 Chef 開發套件 ([Chef DK](https://docs.chef.io/#chef-dk-title)) 在您的本機工作站上執行 [https://docs.chef.io/ctl_chef.html#chef-generate-cookbook](https://docs.chef.io/ctl_chef.html#chef-generate-cookbook) 命令，來更快速的建立技術指南。但是，此命令會建立數個您在本演練中不需要的資料夾及檔案。 **建立技術指南** 1. 在您的本機工作站上，建立名為 `opsworks_cookbook_demo` 的目錄。您可以使用不同的名稱，但請務必在本演練的後續部分一律將 `opsworks_cookbook_demo` 取代為您選擇的名稱。 1. 在 `opsworks_cookbook_demo` 目錄中，使用文字編輯器建立一個名為 `metadata.rb` 的檔案。新增以下程式碼來指定技術指南的名稱。如需 `metadata.rb` 的詳細資訊，請參閱 Chef 網站上的 [metadata.rb](https://docs.chef.io/config_rb_metadata.html)。 ``` name "opsworks_cookbook_demo" ``` 1. 在 `opsworks_cookbook_demo` 目錄中，建立名為 `recipes` 的子目錄。此子目錄包含所有您為本演練的技術指南建立的配方。 1. 在 `recipes` 目錄中，建立名為 `default.rb` 的檔案。此檔案包含具有與檔案名稱相同的配方，但不帶有副檔名：`default`。將下列單行程式碼新增至 `default.rb` 檔案。此程式碼為一個單行配方，會在配方執行時於日誌中顯示簡易訊息： ``` Chef::Log.info("********** Hello, World! **********") ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立名為 `opsworks_cookbook_demo.tar.gz` 的檔案，其中包含 `opsworks_cookbook_demo` 目錄及其內容。例如： ``` tar -czvf opsworks_cookbook_demo.tar.gz opsworks_cookbook_demo/ ``` 您可以使用不同的檔案名稱，但請務必在本演練的後續部分一律將 `opsworks_cookbook_demo.tar.gz` 取代為您選擇的名稱。 **注意** 當您在 Windows 上建立 `tar` 檔案時，最上層目錄必須為技術指南的父系目錄。此演練已在 Linux 上使用 `tar`套件提供的**tar**命令進行測試，並在 Windows 上使用 [Git Bash](https://git-for-windows.github.io/) 提供的**tar**命令進行測試。使用其他命令或程式建立壓縮 TAR (.tar.gz) 檔案可能無法正常運作。 1. 建立 S3 儲存貯體，或使用現有的儲存貯體。如需詳細資訊，請參閱[建立儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)。 1. 將 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。如需詳細資訊，請參閱[將物件新增至儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PuttingAnObjectInABucket.html)。您現在已有您可以在本演練中使用的技術指南。在[下一個步驟](gettingstarted-cookbooks-create-stack.md)中，您會建立 Stacks OpsWorks 堆疊，以供稍後用來上傳技術指南和執行技術指南的配方。 # 步驟 2：建立堆疊及其元件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。建立 OpsWorks Stacks 堆疊及其元件，其中包含 layer 和執行個體。在後續步驟中，您會將您的技術指南上傳至執行個體，並在該執行個體上執行技術指南的配方。 **建立堆疊** 1. 登入 Stacks OpsWorks 主控台，網址為 https：//[https://console.aws.amazon.com/opsworks](https://console.aws.amazon.com/opsworks)。 1. 執行下列其中一個作業 (若適用的話)： + 如果顯示**歡迎使用 OpsWorks Stacks** 頁面，請選擇**新增您的第一個堆疊**或**新增您的第一個 Stacks OpsWorks 堆疊** （這兩個選項都執行相同的動作）。即會顯示 **Add stack (新增堆疊)** 頁面。 + 若顯示 **OpsWorks Dashboard (OpsWorks 儀表板)** 頁面，請選擇 **Add stack (新增堆疊)**。即會顯示 **Add Stack (新增堆疊)** 頁面。 1. 選擇 **Chef 12 stack (Chef 12 堆疊)**。 1. 在 **Stack name (堆疊名稱)** 方塊中，輸入堆疊的名稱 (例如 **MyCookbooksDemoStack**)。您可以輸入不同的名稱，但請務必在本演練的後續部分一律將 `MyCookbooksDemoStack` 取代為您選擇的名稱。 1. 針對**區域**，選擇**美國西部（奧勒岡）**。 1. 針對 **VPC**，執行下列其中一項作業： + 若 VPC 可用，請選擇它。如需詳細資訊，請參閱[在 VPC 中執行堆疊](workingstacks-vpc.md)。 + 否則，請選擇 **No VPC (無 VPC)**。 1. 針對 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)**，選擇 **Yes (是)**。 1. 針對 **Repository type (儲存庫類型)**，選擇 **S3 Archive (S3 封存)**。 **注意** 在[入門：Linux](gettingstarted-linux.md) 演練中，您選擇了 **Http Archive (Http 封存)**。請務必在此改為選擇 **S3 Archive (S3 封存)**。 1. 針對 **Repository URL (儲存庫 URL)**，輸入指向您 S3 中 `opsworks_cookbook_demo.tar.gz` 檔案的路徑。若要取得路徑，請在 S3 主控台中，選取 `opsworks_cookbook_demo.tar.gz` 檔案。在 **Properties (屬性)** 窗格中，複製 **Link (連結)** 欄位的值。(其內容大致如下：`https://s3.amazonaws.com/amzn-s3-demo-bucket/opsworks_cookbook_demo.tar.gz`。) 1. 如果您的 S3 儲存貯體是私有的，這是預設的，則對於**存取金鑰 ID** 和**私密存取金鑰**，輸入您在此演練中使用的 IAM 使用者的存取金鑰 ID 和私密存取金鑰。如需詳細資訊，請參閱[編輯物件許可](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EditingPermissionsonanObject.html)及[與其他人分享物件](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html)。 1. 保留下列項目的預設值： + **Default Availability Zone (預設可用區域)** (**us-west-2a**) + **預設作業系統** (**Linux** 和 **Amazon Linux 2016.09**) + **Default SSH key (預設 SSH 金鑰)** (**Do not use a default SSH key (不使用預設 SSH 金鑰)**) + **Stack color (堆疊色彩)** (深藍色) 1. 選擇 **Advanced (進階)**。 1. 針對 **IAM role (IAM 角色)**，執行以下其中一項作業： + 若 **aws-opsworks-service-role** 可用，請選擇它。 + 若 **aws-opsworks-service-role** 不可用，請選擇 **New IAM role (新 IAM 角色)**。 1. 針對**預設 IAM 執行個體描述檔**，執行下列其中一項： + 若 **aws-opsworks-ec2-role** 可用，請選擇它。 + 如果無法使用 **aws-opsworks-ec2-role**，請選擇**新的 IAM 執行個體描述**檔。 1. 保留下列項目的預設值： + **Default root device type (預設根設備類型)** (**EBS backed (EBS 後端)**) + **Hostname theme (主機名稱主題)** (**Layer Dependent (依存於 Layer)**) + **OpsWorks Agent version (OpsWorks 代理程式版本)** (最新版本) + **Custom Chef JSON (自訂 Chef JSON)** (空白) + **Security (安全)**、**Use OpsWorks security groups (使用 OpsWorks 安全群組)** (**Yes (是)**) 1. 選擇**新增堆疊**。 OpsWorks 堆疊會建立堆疊，並顯示 **MyCookbooksDemoStack** 頁面。 **建立 layer** 1. 在服務導覽窗格中，選擇 **Layers (Layer)**。即會顯示 **Layers (Layer)** 頁面。 1. 選擇 **Add a layer (新增 layer)**。 1. 在 **OpsWorks** 標籤上，針對 **Name (名稱)**，輸入 **MyCookbooksDemoLayer**。您可以輸入不同的名稱，但請務必在本演練的後續部分一律將 `MyCookbooksDemoLayer` 取代為您選擇的名稱。 1. 針對 **Short name (簡短名稱)**，輸入 **cookbooks-demo**。您可以輸入不同的名稱，但請務必在本演練的後續部分一律將 `cookbooks-demo` 取代為您選擇的名稱。 1. 選擇**新增 layer**. OpsWorks Stacks 新增 layer 並顯示 **Layers** 頁面。 **建立及啟動執行個體** 1. 在服務導覽窗格中，選擇 **Instances (執行個體)**。即會顯示 **Instances (執行個體)** 頁面。 1. 選擇 **新增執行個體**。 1. 在 **New (新增)** 標籤上，選擇 **Advanced (進階)**。 1. 保留下列項目的預設值： + **Hostname (主機名稱)** (**cookbooks-demo1**) + **Size (大小)** (**c3.large**) + **Subnet (子網路)** (*IP 地址* **us-west-2a**) + **Scaling type (擴展類型)** (**24/7 (全年無休)**) + **SSH key (SSH 金鑰)** (**Do not use a default SSH key (不使用預設 SSH 金鑰)**) + **作業系統** (**Amazon Linux 2016.09**) + **OpsWorks Agent version (OpsWorks 代理程式版本)** (**Inherit from stack (繼承自堆疊)**) + **Tenancy (租用)** (**Default - Rely on VPC settings (預設 – 依存 VPC 設定)**) + **Root device type (根設備類型)** (**EBS backed (EBS 後端)**) + **Volume type (磁碟區類型)** (**General Purpose (SSD) (一般用途 (SSD))**) + **Volume size (磁碟區大小)** (**8**) 1. 選擇 **Add instance (新增執行個體)**。 1. 針對 **MyCookbooksDemoLayer** 之 **cookbooks-demo1** 的 **Actions (動作)**，選擇 **start (啟動)**。在 **Status (狀態)** 變更為 **online (線上)** 前請不要繼續。此程序可能需要花費數分鐘，敬請耐心等待。您現在已擁有一個堆疊、一個 layer，及一個執行個體，技術指南已自動從您的 S3 儲存貯體複製到其中。在[下一個步驟](gettingstarted-cookbooks-test-recipe.md)中，您會執行及測試執行個體上技術指南中的預設配方。 # 步驟 3：執行及測試配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。從 Stacks OpsWorks 複製到執行個體的技術指南中執行並測試`default`配方。您可能還記得，此為在配方執行時於日誌中顯示簡易訊息的單行配方。 **執行配方** 1. 在服務導覽窗格中，選擇 **Stack (堆疊)**。即會顯示 **MyCookbooksDemoStack** 頁面。 1. 選擇 **Run Command (執行命令)**。即會顯示 **Run Command (執行命令)** 頁面。 1. 針對 **Command (命令)**，選擇 **Execute Recipes (執行配方)**。 1. 針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::default**。 **opsworks\$1cookbook\$1demo** 為在 `metadata.rb` 檔案中定義的技術指南名稱。**default** 為要執行的配方名稱，即技術指南的 `recipes` 子目錄中 `default.rb` 檔案的名稱，不帶副檔名。 1. 保留下列預設值： + **Comment (註解)** (空白) + **Advanced (進階)**、**Custom Chef JSON (自訂 Chef JSON)** (空白) + **Instances (執行個體)** (已核取 **Select all (全選)**，已核取 **MyCookbooksDemoLayer**，已核取 **cookbooks-demo1**) 1. 選擇 **Execute Recipes (執行配方)**。即會顯示 **Running command execute\$1recipes (執行 execute\$1recipes 命令)** 頁面。在 **Status (狀態)** 變更為 **successful (成功)** 前請不要繼續。此程序可能需要花費幾分鐘，敬請耐心等待。 **檢查配方的結果** 1. 在 **Running command execute\$1recipes (執行 execute\$1recipes 命令)** 頁面顯示時，針對 **cookbooks-demo1** 的 **Log (日誌)**，選擇 **show (顯示)**。即會顯示 **execute\$1recipes** 日誌頁面。 1. 向下捲動日誌，尋找與下列內容相似的項目： ``` [2015-11-13T19:14:39+00:00] INFO: ********** Hello, World! ********** ``` 您已成功執行您的第一個配方！在[下一個步驟](gettingstarted-cookbooks-install-package.md)中，您會透過新增在執行個體上安裝套件的配方，來更新您的技術指南。 # 步驟 4：更新技術指南以安裝套件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增在執行個體上安裝包含熱門文字編輯器 GNU Emacs 套件的配方，來更新您的技術指南。雖然您可以輕鬆登入執行個體並安裝套件一次，但撰寫配方可讓您從 OpsWorks Stacks 執行配方一次，同時在堆疊中的多個執行個體上安裝多個套件。 **更新技術指南以安裝套件** 1. 回到您的本機工作站，在 `opsworks_cookbook_demo` 目錄中的 `recipes` 子目錄中，建立名為 `install_package.rb` 的檔案，其中包含下列程式碼： ``` package "Install Emacs" do package_name "emacs" end ``` 此配方會在執行個體上安裝 `emacs` 套件。(如需詳細資訊，請前往 [package](https://docs.chef.io/resource_package.html)。) **注意** 您可以給予配方任何您希望的檔案名稱。每當您想要 Stacks OpsWorks 執行配方時，請務必指定正確的配方名稱。 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。這個新配方會在您每次更新執行個體上的技術指南，並且從更新後的技術指南中執行新的配方時執行。下一個步驟說明如何執行此作業。在您完成[下一個步驟](gettingstarted-cookbooks-copy-cookbook.md)之後，您將能登入執行個體，並從命令提示輸入 **emacs** 以啟動 GNU Emacs。(如需詳細資訊，請參閱[連線至您的 Linux 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)。) 若要離開 GNU Emacs，請按下 **Ctrl\$1X**、**Ctrl\$1C**。 **重要** 若要登入執行個體，您必須先向 OpsWorks Stacks 提供公有 SSH 金鑰的相關資訊（您可以使用 ssh-keygen 或 PuTTYgen 等工具建立），然後您必須在`MyCookbooksDemoStack`堆疊上設定許可，讓使用者能夠登入執行個體。如需說明，請參閱 [註冊使用者的公有 SSH 金鑰](security-settingsshkey.md) 與 [使用 SSH 登入](workinginstances-ssh.md)。 # 步驟 5：更新執行個體上的技術指南及執行配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。更新執行個體上的技術指南，以及從執行個體上已更新的技術指南執行配方。在本演練的後續部分中，每次您新增配方藉以更新技術指南時，都會重複此一步驟。 **更新執行個體上的技術指南** 1. 在服務導覽窗格中，選擇 **Stack (堆疊)**。即會顯示 **MyCookbooksDemoStack** 頁面。 1. 選擇 **Run Command (執行命令)**。即會顯示 **Run Command (執行命令)** 頁面。 1. 針對 **Command (命令)**，選擇 **Update Custom Cookbooks (更新自訂技術指南)**。 1. 保留下列預設值： + **Comment (註解)** (空白) + **Advanced (進階)**、**Custom Chef JSON (自訂 Chef JSON)** (空白) + **Advanced (進階)**、**Instances (執行個體)** (已核取 **Select all (全選)**，已核取 **MyCookbooksDemoLayer**，已核取 **cookbooks-demo1**)。 1. 選擇 **Update Custom Cookbooks (更新自訂技術指南)**。即會顯示 **Running command update\$1custom\$1cookbooks (執行 update\$1custom\$1cookbooks 命令)** 頁面。在 **Status (狀態)** 變更為 **successful (成功)** 前請不要繼續。此程序可能需要花費數分鐘，敬請耐心等待。 **執行配方** 1. 在服務導覽窗格中，選擇 **Stack (堆疊)**。即會顯示 **MyCookbooksDemoStack** 頁面。 1. 選擇 **Run Command (執行命令)**。即會顯示 **Run Command (執行命令)** 頁面。 1. 針對 **Command (命令)**，選擇 **Execute Recipes (執行配方)**。 1. 針對 **Recipes to execute (要執行的配方)**，輸入要執行的配方名稱。您第一次執行此作業時，配方會命名為 **opsworks\$1cookbook\$1demo::install\$1package**。 **注意** 當您在稍後重複此程序時，請輸入技術指南的名稱 (**opsworks\$1cookbook\$1demo**)，其後跟隨兩個冒號 (**::**)，其後再跟隨配方的名稱 (不帶有 `.rb` 副檔名的配方檔案名稱)。 1. 保留下列預設值： + **Comment (註解)** (空白) + **Advanced (進階)**、**Custom Chef JSON (自訂 Chef JSON)** (空白) + **Instances (執行個體)**、已核取 **Select all (全選)**，已核取 **MyCookbooksDemoLayer**，已核取 **cookbooks-demo1** 1. 選擇 **Execute Recipes (執行配方)**。即會顯示 **Running command execute\$1recipes (執行 execute\$1recipes 命令)** 頁面。在 **Status (狀態)** 變更為 **successful (成功)** 前請不要繼續。此程序可能需要花費幾分鐘，敬請耐心等待。 **注意** 您不需要手動執行配方。您可以將配方指派給 layer 的生命週期事件，例如設定和設定事件，而 OpsWorks Stacks 會在事件發生時自動執行這些配方。如需詳細資訊，請參閱[OpsWorks Stacks 生命週期事件](workingcookbook-events.md)。在[下一個步驟](gettingstarted-cookbooks-add-user.md)中，您會更新技術指南，將使用者新增至執行個體。 # 步驟 6：更新技術指南以新增使用者 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增將本機使用者新增至執行個體，並設定使用者的主目錄與殼層的配方，來更新您的技術指南。這與執行 Linux **adduser** 或 **useradd** 命令，或 Windows **net user** 命令相似。您可以將本機使用者新增至執行個體，例如：當您希望控制執行個體檔案與目錄的存取時。您也可以在不使用技術指南的情況下管理使用者。如需詳細資訊，請參閱[管理使用者](opsworks-security-users-manage.md)。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，於 `opsworks_cookbook_demo` 目錄中的 `recipes` 子目錄內，建立名為 `add_user.rb` 的檔案，其中包含下列程式碼 (如需詳細資訊，請前往 [user](https://docs.chef.io/resource_user.html))： ``` user "Add a user" do home "/home/jdoe" shell "/bin/bash" username "jdoe" end ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::add\$1user**。 **測試配方** 1. 登入執行個體 (若您尚未登入的話)。 1. 從命令提示中，執行下列命令以確認新的使用者已新增： ``` grep jdoe /etc/passwd ``` 即會顯示與下列內容相似的使用者相關資訊，包含像是使用者名稱、ID 號碼、群組 ID 號碼、主目錄、殼層等詳細資訊： ``` jdoe:x:501:502::/home/jdoe:/bin/bash ``` 在[下一個步驟](gettingstarted-cookbooks-create-directory.md)中，您會更新技術指南，在執行個體上建立目錄。 # 步驟 7：更新技術指南以建立目錄 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增會將目錄新增至執行個體的配方，來更新您的技術指南。這與執行 Linux **mkdir** 命令，或 Windows **md** 或 **mkdir** 命令相似。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，在 `opsworks_cookbook_demo` 目錄中的 `recipes` 子目錄中，建立名為 `create_directory.rb` 的檔案，其中包含下列程式碼。如需詳細資訊，請前往 [directory](https://docs.chef.io/resource_directory.html)： ``` directory "Create a directory" do group "root" mode "0755" owner "ec2-user" path "/tmp/create-directory-demo" end ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::create\$1directory**。 **測試配方** 1. 登入執行個體 (若您尚未登入的話)。 1. 從命令提示中，執行下列命令以確認新的目錄已新增： ``` ls -la /tmp/create-directory-demo ``` 即會顯示新建立目錄的相關資訊，包含像是許可、擁有者名稱和群組名稱等資訊： ``` drwxr-xr-x 2 ec2-user root 4096 Nov 18 00:35 . drwxrwxrwt 6 root root 4096 Nov 24 18:17 .. ``` 在[下一個步驟](gettingstarted-cookbooks-create-file.md)中，您會更新技術指南，在執行個體上建立檔案。 # 步驟 8：更新技術指南以建立及複製檔案 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增會將兩個檔案新增至執行個體的配方，來更新您的技術指南。配方中的第一個資源會完全使用配方程式碼來建立檔案。這與執行 Linux **cat**、**echo** 或 **touch** 命令，或 Windows **echo** 或 **fsutil** 命令相似。此技術對少量、小型或簡單的檔案相當有用。配方中的第二個資源會將技術指南中的檔案複製到執行個體上的另一個目錄。這與執行 Linux **cp** 命令或 Windows **copy** 命令相似。此技術對於大量、大型或複雜的檔案相當有用。在您開始此步驟前，請先完成[步驟 7：更新技術指南以建立目錄](gettingstarted-cookbooks-create-directory.md)以確保檔案的父系目錄已存在。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，於 `opsworks_cookbook_demo` 目錄中，建立名為 `files` 的子目錄。 1. 在 `files` 子目錄中，建立名為 `hello.txt` 的檔案，其中包含下列文字：**Hello, World\$1** 1. 在 `opsworks_cookbook_demo` 目錄的 `recipes` 子目錄中，建立名為 `create_files.rb` 的檔案，其中包含下列程式碼。如需詳細資訊，請前往 [file](https://docs.chef.io/resource_file.html) 和 [cookbook\$1file](https://docs.chef.io/resource_cookbook_file.html)。 ``` file "Create a file" do content "This is a placeholder for the home page." group "root" mode "0755" owner "ec2-user" path "/tmp/create-directory-demo/index.html" end cookbook_file "Copy a file" do group "root" mode "0755" owner "ec2-user" path "/tmp/create-directory-demo/hello.txt" source "hello.txt" end ``` `file` 資源會在指定的路徑中建立檔案。`cookbook_file` 資源會從您在技術指南中建立的 `files` 目錄 (Chef 預期會找到名為 `files` 的標準命名目錄，並從中複製檔案)，將檔案複製到執行個體上的另一個目錄。 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::create\$1files**。 **測試配方** 1. 登入執行個體 (若您尚未登入的話)。 1. 從命令提示中，逐項執行下列命令以確認新的檔案已新增： ``` sudo cat /tmp/create-directory-demo/index.html sudo cat /tmp/create-directory-demo/hello.txt ``` 即會顯示檔案的內容： ``` This is a placeholder for the home page. Hello, World! ``` 在[下一個步驟](gettingstarted-cookbooks-run-command.md)中，您會更新技術指南，在執行個體上執行命令。 # 步驟 9：更新技術指南以執行命令 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增會執行在執行個體上建立 SSH 金鑰之命令的配方，來更新您的技術指南。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，在 `opsworks_cookbook_demo` 目錄中的 `recipes` 子目錄中，建立名為 `run_command.rb` 的檔案，其中包含下列程式碼。如需詳細資訊，請前往 [execute](https://docs.chef.io/resource_execute.html)。 ``` execute "Create an SSH key" do command "ssh-keygen -f /tmp/my-key -N fLyC3jbY" end ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::run\$1command**。 **測試配方** 1. 登入執行個體 (若您尚未登入的話)。 1. 從命令提示中，逐項執行下列命令以確認 SSH 金鑰已建立： ``` sudo cat /tmp/my-key sudo cat /tmp/my-key.pub ``` 即會顯示 SSH 私有和公有金鑰的內容： ``` -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,DEF7A09C...541583FA A5p9dCuo...wp0YYH1c -----END RSA PRIVATE KEY----- ssh-rsa AAAAB3N...KaNogZkT root@cookbooks-demo1 ``` 在[下一個步驟](gettingstarted-cookbooks-run-script.md)中，您會更新技術指南，在執行個體上執行指令碼。 # 步驟 10：更新技術指南以執行指令碼 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增會在執行個體上執行指令碼的配方，來更新您的技術指南。此配方會建立目錄，然後在該目錄中建立檔案。撰寫配方執行包含多個命令的指令碼，會比一次執行一個命令輕鬆許多。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，在 `opsworks_cookbook_demo` 目錄中的 `recipes` 子目錄中，建立名為 `run_script.rb` 的檔案，其中包含下列程式碼。如需詳細資訊，請前往 [script](https://docs.chef.io/resource_script.html)。 ``` script "Run a script" do interpreter "bash" code <<-EOH mkdir -m 777 /tmp/run-script-demo touch /tmp/run-script-demo/helloworld.txt echo "Hello, World!" > /tmp/run-script-demo/helloworld.txt EOH end ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::run\$1script**。 **測試配方** 1. 登入執行個體 (若您尚未登入的話)。 1. 從命令提示中，執行下列命令以確認新的檔案已新增： ``` sudo cat /tmp/run-script-demo/helloworld.txt ``` 即會顯示檔案的內容： ``` Hello, World! ``` 在[下一個步驟](gettingstarted-cookbooks-manage-service.md)中，您會更新技術指南，在執行個體上管理服務。 # 步驟 11：更新技術指南以管理服務 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增會在執行個體上管理服務的配方，來更新您的技術指南。這和執行 Linux **service** 命令，或 Windows **net stop**、**net start** 和其他類似命令相似。此配方會停止執行個體上的 **crond** 服務。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，在 `opsworks_cookbook_demo` 目錄中的 `recipes` 子目錄中，建立名為 `manage_service.rb` 的檔案，其中包含下列程式碼。如需詳細資訊，請前往 [service](https://docs.chef.io/resource_service.html)。 ``` service "Manage a service" do action :stop service_name "crond" end ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::manage\$1service**。 **測試配方** 1. 登入執行個體 (若您尚未登入的話)。 1. 從命令提示中，執行下列命令以確認 **crond** 服務已停止： ``` service crond status ``` 即會顯示下列資訊： ``` crond is stopped ``` 1. 若要重新啟動 **crond** 服務，請執行下列命令： ``` sudo service crond start ``` 即會顯示下列資訊： ``` Starting crond: [ OK ] ``` 1. 若要確認 **crond** 服務已啟動，請再次執行下列命令： ``` service crond status ``` 即會顯示與下列內容相似的資訊： ``` crond (pid 3917) is running... ``` 在[下一個步驟](gettingstarted-cookbooks-custom-json.md)中，您會更新技術指南，在執行個體上參考以自訂 JSON 存放的資訊。 # 步驟 12：更新技術指南以使用自訂 JSON **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增會參考存放於執行個體上之自訂 JSON 的配方，來更新您的技術指南。您可以在您建立、更新、複製堆疊，或在您執行部署或堆疊命令時以自訂 JSON 格式指定資訊。舉例來說，這在您要讓一小部分不會變動的資料供您執行個體上的配方使用 (而非從資料庫取得資料) 時會非常有用。如需詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。針對本演練，您會使用自訂 JSON 提供一些關於客戶發票的虛擬資訊。自訂 JSON 會在此步驟的稍後進行說明。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，在 `recipes` 目錄中的 `opsworks_cookbook_demo` 子目錄中，建立名為 `custom_json.rb` 的檔案，其中包含下列配方程式碼： ``` Chef::Log.info("********** For customer '#{node['customer-id']}' invoice '#{node['invoice-number']}' **********") Chef::Log.info("********** Invoice line number 1 is a '#{node['line-items']['line-1']}' **********") Chef::Log.info("********** Invoice line number 2 is a '#{node['line-items']['line-2']}' **********") Chef::Log.info("********** Invoice line number 3 is a '#{node['line-items']['line-3']}' **********") ``` 此配方會在日誌中顯示關於自訂 JSON 內值的訊息。 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::custom\$1json**。針對 **Advanced (進階)**、**Custom Chef JSON (自訂 Chef JSON)**，輸入下列自訂 JSON： ``` { "customer-id": "0123", "invoice-number": "9876", "line-items": { "line-1": "tractor", "line-2": "passenger car", "line-3": "trailer" } } ``` **測試配方** 1. 在先前程序中的 **Running command execute\$1recipes (執行 execute\$1recipes 命令)** 頁面顯示時，針對 **cookbooks-demo1** 的 **Log (日誌)**，選擇 **show (顯示)**。即會顯示 **execute\$1recipes** 日誌頁面。 1. 向下捲動日誌，尋找看起來與下列內容相似的項目： ``` [2015-11-14T14:18:30+00:00] INFO: ********** For customer '0123' invoice '9876' ********** [2015-11-14T14:18:30+00:00] INFO: ********** Invoice line number 1 is a 'tractor' ********** [2015-11-14T14:18:30+00:00] INFO: ********** Invoice line number 2 is a 'passenger car' ********** [2015-11-14T14:18:30+00:00] INFO: ********** Invoice line number 3 is a 'trailer' ********** ``` 這些項目會顯示在 **Advanced (進階)**、**Custom Chef JSON (自訂 Chef JSON)** 方塊中輸入之自訂 JSON 的資訊。在[下一個步驟](gettingstarted-cookbooks-data-bags.md)中，您將更新技術指南，從資料包取得資訊，這是 Stacks OpsWorks 在每個執行個體上存放的堆疊設定集合。 # 步驟 13：更新技術指南以使用資料包 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。新增參考 Stacks OpsWorks 存放在執行個體上一組資料包的堆疊設定的配方，以更新您的技術指南。此配方會在日誌中顯示存放於執行個體上之特定堆疊設定的相關訊息。如需更多資訊，請參閱[OpsWorks Stacks 資料包參考](data-bags.md)。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，在 `recipes` 目錄中的 `opsworks_cookbook_demo` 子目錄中，建立名為 `data_bags.rb` 的檔案，其中包含下列程式碼： ``` instance = search("aws_opsworks_instance").first layer = search("aws_opsworks_layer").first stack = search("aws_opsworks_stack").first Chef::Log.info("********** This instance's instance ID is '#{instance['instance_id']}' **********") Chef::Log.info("********** This instance's public IP address is '#{instance['public_ip']}' **********") Chef::Log.info("********** This instance belongs to the layer '#{layer['name']}' **********") Chef::Log.info("********** This instance belongs to the stack '#{stack['name']}' **********") Chef::Log.info("********** This stack gets its cookbooks from '#{stack['custom_cookbooks_source']['url']}' **********") ``` 此配方會在日誌中顯示存放於執行個體上之特定堆疊設定的相關訊息。 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::data\$1bags**。 **測試配方** 1. 在先前程序中的 **Running command execute\$1recipes (執行 execute\$1recipes 命令)** 頁面顯示時，針對 **cookbooks-demo1** 的 **Log (日誌)**，選擇 **show (顯示)**。即會顯示 **execute\$1recipes** 日誌頁面。 1. 向下捲動日誌，尋找看起來與下列內容相似的項目： ``` [2015-11-14T14:39:06+00:00] INFO: ********** This instance's instance ID is 'f80fa119-81ab-4c3c-883d-6028e52c89EX' ********** [2015-11-14T14:39:06+00:00] INFO: ********** This instance's public IP address is '192.0.2.0' ********** [2015-11-14T14:39:06+00:00] INFO: ********** This instance belongs to the layer 'MyCookbooksDemoLayer' ********** [2015-11-14T14:39:06+00:00] INFO: ********** This instance belongs to the stack 'MyCookbooksDemoStack' ********** [2015-11-14T14:39:06+00:00] INFO: ********** This stack gets its cookbooks from 'https://s3.amazonaws.com/amzn-s3-demo-bucket/opsworks_cookbook_demo.tar.gz' ********** ``` 此配方會顯示存放於執行個體上之特定堆疊設定的相關訊息。在[下一個步驟](gettingstarted-cookbooks-iteration.md)中，您會更新技術指南，以多次執行配方程式碼。 # 步驟 14：更新技術指南以使用反覆運算 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。透過新增使用「反覆運算」**(一種重複配方程式碼多次的技術) 的配方，來更新您的技術指南。此配方會在日誌中顯示包含多個內容之資料包項目的訊息。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，在 `recipes` 目錄中的 `opsworks_cookbook_demo` 子目錄中，建立名為 `iteration_demo.rb` 的檔案，其中包含下列程式碼： ``` stack = search("aws_opsworks_stack").first Chef::Log.info("********** Content of 'custom_cookbooks_source' **********") stack["custom_cookbooks_source"].each do |content| Chef::Log.info("********** '#{content}' **********") end ``` **注意** 相較於撰寫下列不使用反覆運算的配方程式碼，撰寫前述配方程式碼更簡短、彈性更佳，也較不容易發生錯誤： ``` stack = search("aws_opsworks_stack").first Chef::Log.info("********** Content of 'custom_cookbooks_source' **********") Chef::Log::info("********** '[\"type\", \"#{stack['custom_cookbooks_source']['type']}\"]' **********") Chef::Log::info("********** '[\"url\", \"#{stack['custom_cookbooks_source']['url']}\"]' **********") Chef::Log::info("********** '[\"username\", \"#{stack['custom_cookbooks_source']['username']}\"]' **********") Chef::Log::info("********** '[\"password\", \"#{stack['custom_cookbooks_source']['password']}\"]' **********") Chef::Log::info("********** '[\"ssh_key\", \"#{stack['custom_cookbooks_source']['ssh_key']}\"]' **********") Chef::Log::info("********** '[\"revision\", \"#{stack['custom_cookbooks_source']['revision']}\"]' **********") ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::iteration\$1demo**。 **測試配方** 1. 在先前程序中的 **Running command execute\$1recipes (執行 execute\$1recipes 命令)** 頁面顯示時，針對 **cookbooks-demo1** 的 **Log (日誌)**，選擇 **show (顯示)**。即會顯示 **execute\$1recipes** 日誌頁面。 1. 向下捲動日誌，尋找看起來與下列內容相似的項目： ``` [2015-11-16T19:56:56+00:00] INFO: ********** Content of 'custom_cookbooks_source' ********** [2015-11-16T19:56:56+00:00] INFO: ********** '["type", "s3"]' ********** [2015-11-16T19:56:56+00:00] INFO: ********** '["url", "https://s3.amazonaws.com/amzn-s3-demo-bucket/opsworks_cookbook_demo.tar.gz"]' ********** [2015-11-16T19:56:56+00:00] INFO: ********** '["username", "secret-key-value"]' ********** [2015-11-16T19:56:56+00:00] INFO: ********** '["password", "secret-access-key-value"]' ********** [2015-11-16T19:56:56+00:00] INFO: ********** '["ssh_key", nil]' ********** [2015-11-16T19:56:56+00:00] INFO: ********** '["revision", nil]' ********** ``` 此配方會在日誌中顯示包含多個內容之資料包項目的訊息。資料包項目位於 `aws_opsworks_stack` 資料包中。資料包項目包含名為 `custom_cookbooks_source` 的內容。此內容的內部為六個名為 `type`、`url`、`username`、`password`、`ssh_key` 和 `revision` 的內容。此處也會顯示他們的值。在[下一個步驟](gettingstarted-cookbooks-conditional-logic.md)中，您會更新技術指南，僅於滿足特定條件時執行配方程式碼。 # 步驟 15：更新技術指南以使用條件式邏輯 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在，透過新增使用「條件式邏輯」**(一種只在條件滿足時才執行程式碼的技術) 的配方，來更新您的技術指南。如需詳細資訊，請前往 [if Statements](https://docs.chef.io/dsl_recipe.html#if-statements) 和 [case Statements](https://docs.chef.io/dsl_recipe.html#case-statements)。此配方會根據資料包的內容執行兩項作業：在日誌中顯示訊息，識別執行執行個體的作業系統，並且只在作業系統為 Linux 時，透過使用特定 Linux 版本的正確套件管理員來安裝套件。此套件名為 tree。該套件為可將目錄清單視覺化的簡易應用程式。 **更新執行個體上的技術指南及執行新的配方** 1. 在您的本機工作站上，於 `opsworks_cookbook_demo directory` 中的 `recipes` 子目錄中，建立名為 `conditional_logic.rb` 的檔案，其中包含下列程式碼： ``` instance = search("aws_opsworks_instance").first os = instance["os"] if os == "Red Hat Enterprise Linux 7" Chef::Log.info("********** Operating system is Red Hat Enterprise Linux. **********") elsif os == "Ubuntu 14.04 LTS" || os == "Ubuntu 16.04 LTS" || os == "Ubuntu 18.04 LTS" Chef::Log.info("********** Operating system is Ubuntu. **********") elsif os == "Microsoft Windows Server 2012 R2 Base" Chef::Log.info("********** Operating system is Windows. **********") elsif os == "Amazon Linux 2015.03" || os == "Amazon Linux 2015.09" || os == "Amazon Linux 2016.03" || os == "Amazon Linux 2016.09" || os == "Amazon Linux 2017.03" || os == "Amazon Linux 2017.09" || os == "Amazon Linux 2018.03" || os == "Amazon Linux 2" Chef::Log.info("********** Operating system is Amazon Linux. **********") elsif os == "CentOS Linux 7" Chef::Log.info("********** Operating system is CentOS 7. **********") else Chef::Log.info("********** Cannot determine operating system. **********") end case os when "Ubuntu 14.04 LTS", "Ubuntu 16.04 LTS", "Ubuntu 18.04 LTS" apt_package "Install a package with apt-get" do package_name "tree" end when "Amazon Linux 2015.03", "Amazon Linux 2015.09", "Amazon Linux 2016.03", "Amazon Linux 2016.09", "Amazon Linux 2017.03", "Amazon Linux 2017.09", "Amazon Linux 2018.03", "Amazon Linux 2", "Red Hat Enterprise Linux 7", "CentOS Linux 7" yum_package "Install a package with yum" do package_name "tree" end else Chef::Log.info("********** Cannot determine operating system type, or operating system is not Linux. Package not installed. **********") end ``` 1. 在終端機或命令提示中，使用 **tar** 命令建立 `opsworks_cookbook_demo.tar.gz` 檔案的新版本，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容。 1. 將更新後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::conditional\$1logic**。 **測試配方** 1. 在先前程序中的 **Running command execute\$1recipes (執行 execute\$1recipes 命令)** 頁面顯示時，針對 **cookbooks-demo1** 的 **Log (日誌)**，選擇 **show (顯示)**。即會顯示 **execute\$1recipes** 日誌頁面。 1. 向下捲動日誌，尋找與下列內容相似的項目： ``` [2015-11-16T19:59:05+00:00] INFO: ********** Operating system is Amazon Linux. ********** ``` 由於執行個體的作業系統是 Amazon Linux 2016.09，因此日誌中只會顯示上述項目（配方程式碼中五個可能項目中的項目）。 1. 若作業系統為 Linux，配方會安裝 tree 套件。若要查看目錄內容的視覺化，請從希望查看的目錄，或使用該目錄的路徑 (例如 `tree /var/chef/runs`)，在命令提示中輸入 **tree**。在[下一個步驟](gettingstarted-cookbooks-community-cookbooks.md)中，您會更新技術指南，使用由 Chef 社群提供之外部技術指南的功能。 # 步驟 16：更新技術指南以使用社群技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。最後，更新技術指南以使用 Chef 社群提供之外部技術指南中的功能。您在本演練中會使用的外部技術指南可從 [Chef Supermarket](https://supermarket.chef.io/) 取得。該網站為存取外部 Chef 技術指南的熱門位置。此外部技術指南提供自訂資源，可讓您下載及安裝應用程式，與您在[步驟 4：更新技術指南以安裝套件](gettingstarted-cookbooks-install-package.md)中執行的作業相似。而除了套件外，此資源還可安裝 Web 應用程式和其他應用程式類型。當技術指南依存於另一個技術指南時，您必須指定其對其他技術指南的依存性。若要宣告及管理技術指南依存性，我們建議您使用名為 Berkshelf 的工具。如需如何在本機工作站上安裝 Berkshelf 的詳細資訊，請參閱 Chef 網站上的[關於 Berkshelf](https://docs.chef.io/berkshelf.html)。在您安裝 Berkshelf 之後，遵循這些程序以宣告技術指南的依存性，然後建立呼叫外部技術指南中資源的配方。 **宣告技術指南依存性** 1. 在您的本機工作站上，於 `opsworks_cookbook_demo` 目錄中，在 `metadata.rb` 檔案的結尾新增此行： ``` depends "application", "5.0.0" ``` 這會宣告其依存於名為 `application`，版本 5.0.0 的技術指南。 1. 從 `opsworks_cookbook_demo` 目錄的根，執行下列命令。命令結尾的句號是有意的。 ``` berks init . ``` Berkshelf 會建立您在稍後針對更進階的案例可使用的資料夾及檔案。我們在本演練中所需要的檔案為名為 `Berksfile` 的檔案。 1. 在 `Berksfile` 檔案的結尾新增此行： ``` cookbook "application", "5.0.0" ``` 這會通知 Berkshelf 您希望使用 [應用程式技術指南，版本 5.0.0](https://supermarket.chef.io/cookbooks/application/versions/5.0.0)。Berkshelf 可從 Chef Supermarket 下載。 1. 在終端機或命令提示中，從 `opsworks_cookbook_demo` 目錄的根執行下列命令： ``` berks install ``` Berkshelf 會為您的技術指南和應用程式技術指南建立依存性清單。Berkshelf 會在下一個程序中使用此依存性清單。 **更新執行個體上的技術指南及執行新的配方** 1. 在 `recipes` 目錄中的 `opsworks_cookbook_demo` 子目錄內，建立名為 `dependencies_demo.rb` 的檔案，其中包含下列程式碼： ``` application "Install NetHack" do package "nethack.x86_64" end ``` 此配方會依存應用程式技術指南的應用程式資源，以在執行個體上安裝熱門的文字式冒險遊戲 NetHack。(您當然可以將其取代為任何其他的套件名稱，只要執行個體上的套件管理員可取得該套件即可。) 1. 從 `opsworks_cookbook_demo` 目錄的根，執行下列命令： ``` berks package ``` Berkshelf 使用先前程序中的依存性清單，來建立名為 `cookbooks-timestamp.tar.gz` 的檔案，其中包含 `opsworks_cookbook_demo` 目錄及其更新後的內容，包含技術指南的依存技術指南。將此檔案重新命名為 `opsworks_cookbook_demo.tar.gz`。 1. 將更新並重新命名後的 `opsworks_cookbook_demo.tar.gz` 檔案上傳至 S3 儲存貯體。 1. 遵循[步驟 5：更新執行個體上的技術指南及執行配方](gettingstarted-cookbooks-copy-cookbook.md)中的程序，更新執行個體上的技術指南及執行配方。在「執行配方」程序中，針對 **Recipes to execute (要執行的配方)**，輸入 **opsworks\$1cookbook\$1demo::dependencies\$1demo**。 1. 在您執行配方之後，應該可以登入執行個體，然後在命令提示輸入 **nethack** 來開始遊玩。(如需遊戲的詳細資訊，請參閱 [NetHack](https://en.wikipedia.org/wiki/NetHack) 和 [NetHack Guidebook](http://www.nethack.org/v343/Guidebook.html)。) 在[下一個步驟](gettingstarted-cookbooks-clean-up.md)中，您可以清除用於本演練 AWS 的資源。此步驟為選用。當您繼續進一步了解 Stacks OpsWorks 時，建議您繼續使用這些 AWS 資源。不過，保留這些 AWS 資源可能會對 AWS 您的帳戶產生持續費用。如果您想要將這些 AWS 資源保留以供日後使用，您現在已完成本演練，您可以直接跳到 [後續步驟](gettingstarted-cookbooks-next-steps.md)。 # 步驟 17：(選用) 清除 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。為了避免 AWS 您的帳戶產生額外費用，您可以刪除 AWS 用於此演練的資源。這些 AWS 資源包括 S3 儲存貯體、 Stacks OpsWorks 堆疊和堆疊的元件。(如需詳細資訊，請參閱 [AWS OpsWorks 定價](https://aws.amazon.com/opsworks/pricing/)。) 不過，當您繼續進一步了解 OpsWorks Stacks 時，建議您繼續使用這些 AWS 資源。如果您想要讓這些 AWS 資源保持可用，您現在已完成本演練，您可以跳至 [後續步驟](gettingstarted-cookbooks-next-steps.md)。存放在您為此逐步解說建立的資源裡的內容，可包含個人識別資訊。如果您不希望再將此資訊存放在 AWS，請遵循本主題的步驟。 **刪除 S3 儲存貯體** + 請參閱[刪除 Amazon S3 儲存貯體](https://docs.aws.amazon.com/gettingstarted/latest/swh/getting-started-cleanup-s3.html)。 **刪除堆疊的執行個體** 1. 在 OpsWorks Stacks 主控台的服務導覽窗格中，選擇**執行個體**。即會顯示 **Instances (執行個體)** 頁面。 1. 針對 **MyCookbooksDemoLayer** 之 **cookbooks-demo1** 的 **Actions (動作)**，選擇 **stop (停止)**。在您看見確認訊息時，選擇 **Stop (停止)**。 1. 下列變更會在數分鐘內發生。請不要在下列所有項目皆完成之前繼續。 + **Status (狀態)** 從 **online (線上)** 變更為 **stopping (停止中)**，最後變更為 **stopped (已停止)**。 + **online (線上)** 從 **1** 變更為 **0**。 + **shutting down (關機中)** 從 **0** 變更為 **1**，最後變回 **0**。 + **stopped (已停止)** 最後從 **0** 變更為 **1**。 1. 針對 **Actions (動作)**，選擇 **delete (刪除)**。當您看到確認訊息時，請選擇 **Delete**。 OpsWorks Stacks 會刪除執行個體並顯示**無執行個體**。 **刪除堆疊** 1. 在服務導覽窗格中，選擇 **Stack (堆疊)**。即會顯示 **MyCookbooksDemoStack** 頁面。 1. 選擇 **Delete Stack (刪除堆疊)**。當您看到確認訊息時，請選擇**刪除**。 OpsWorks 堆疊會刪除堆疊並顯示**儀表板**頁面。您也可以選擇性地刪除您用於本演練的 IAM 使用者和 Amazon EC2 金鑰對，如果您不想重複使用這些金鑰對來存取其他 AWS 服務和 EC2 執行個體。如需說明，請參閱[刪除 IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting)、[Amazon EC2 金鑰對和 Linux 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair)。您現已完成本演練。如需詳細資訊，請參閱[後續步驟](gettingstarted-cookbooks-next-steps.md)。 # 後續步驟 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在您已完成本演練，您可以透過檢閱下列資源，進一步了解 OpsWorks Stacks 對 Chef 技術指南的支援： + [技術指南和配方](workingcookbook.md) – 說明 Stacks OpsWorks 目前支援的 Chef 和 Ruby 版本。也示範如何在執行個體上安裝及更新自訂技術指南，以及如何在執行個體上執行配方。 + [Learn Chef](https://learn.chef.io/) – 提供 Chef 教學的連結、Chef 技能程式庫、完整的 Chef 文件，以及 Chef 培訓課程。 + [關於 Chef](https://docs.chef.io/) – 提供完整的 Chef 文件。特定參考主題包含： + [About Cookbooks](https://docs.chef.io/cookbooks.html) – 說明關鍵技術指南元件，例如屬性、配方、檔案、中繼資料和範本。 + [About Recipes](https://docs.chef.io/recipes.html) – 說明配方的基礎，例如如何使用資料包、包含其他配方，以及在配方中使用 Ruby 程式碼。 + [Resources](https://docs.chef.io/resources.html#resources) – 說明如何使用所有內建 Chef 資源，例如 `apt_package`、`cookbook_file`、`directory`、`execute`、`file` 和 `package`。 + [About the Recipe DSL](https://docs.chef.io/dsl_recipe.html) – 說明如何使用陳述式撰寫 Chef 配方的程式碼，例如 `if`、`case`、`data_bag`、`data_bag_item` 及 `search`。 + [About Templates](https://docs.chef.io/templates.html) – 說明如何使用內嵌式 Ruby (ERB) 範本動態產生靜態文字檔案，例如組態檔案。 + [學習軌道](https://learn.chef.io/tracks) – 說明如何使用 Chef 管理執行個體、管理基本 Web 應用程式、開發和測試基礎設施程式碼、使用 Chef 分析等。 + [http://shop.oreilly.com/product/0636920032397.do](http://shop.oreilly.com/product/0636920032397.do) – Chef 簡介。由 O'Reilly Media 出版。 + [Learning Chef code examples](https://github.com/learningchef/learningchef-code) – 提供程式碼範例，搭配由 O'Reilly Media 出版的《Learning Chef》**書籍。 # OpsWorks Stacks 最佳實務 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節中的策略、技術和建議可協助您從 Stacks OpsWorks 獲得最大效益和最佳成果。 **Topics** + [最佳實務：執行個體的根設備儲存](best-practices-storage.md) + [最佳實務：最佳化應用程式伺服器的數目](best-practices-autoscale.md) + [最佳實務：管理許可](best-practices-permissions.md) + [最佳實務：管理和部署應用程式與技術指南](best-deploy.md) + [本機封裝技術指南依存性](best-practices-packaging-cookbooks-locally.md) # 最佳實務：執行個體的根設備儲存 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題不適用於 Windows 執行個體，其必須為 Amazon Elastic Block Store 後端。 Amazon Elastic Compute Cloud (Amazon EC2) Linux 執行個體具有下列根裝置儲存選項。 + **執行個體後端執行個體** – 根裝置是暫時的。如果您停止執行個體，根設備中的資料便會消失且無法復原。如需詳細資訊，請參閱 [Amazon EC2 執行個體存放區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)。 + **Amazon EBS 後端執行個體** – 根裝置是 Amazon EBS 磁碟區。如果您停止執行個體，Amazon EBS 磁碟區會持續存在。如果您重新啟動執行個體，系統會自動重新掛載磁碟區，並還原執行個體狀態和任何存放的資料。您也可以在不同的執行個體上掛載磁碟區。如需詳細資訊，請參閱 [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)。要決定使用哪一種根設備儲存選項時，請考慮下列各項。 **開機時間** 初始啟動後，Amazon EBS 執行個體通常會更快重新啟動。每種儲存類型的第一次啟動時間約略相同。這兩種類型都必須執行完整設定，其中包含相對較耗時的任務，例如從遠端儲存庫安裝套件。不過，在您之後重新啟動執行個體時請注意下列差異性： + 執行個體存放區後端執行個體執行的設定任務與第一次啟動時相同，包括套件安裝。重新啟動所需的時間也與第一次啟動時間大致相同。 + Amazon EBS 後端執行個體會重新掛載根磁碟區並執行安裝配方。重新啟動通常比第一次啟動更加快速，因為安裝配方不需要執行任務 (例如重新安裝已安裝在根磁碟區的套件)。 **Cost** Amazon EBS 支援的執行個體成本更高： + 使用執行個體存放區後端執行個體時，您只需要在執行個體執行時付費。 + 使用 Amazon EBS 後端執行個體時，無論執行個體是否正在執行，您都需要支付 Amazon EBS 磁碟區的費用。如需詳細資訊，請參閱 [Amazon EBS 定價](https://aws.amazon.com/ebs/pricing/)。 **日誌** Amazon EBS 後端執行個體會自動保留日誌： + 使用執行個體存放區後端執行個體時，日誌會在執行個體停止時消失。您必須先擷取日誌，才能停止執行個體，或使用 [CloudWatch Logs](monitoring-cloudwatch-logs.md) 等服務遠端存放選取的日誌。 + 使用 Amazon EBS 後端執行個體時，日誌會存放在 Amazon EBS 磁碟區中。您可以重新啟動執行個體或將磁碟區掛載在其他執行個體上，以檢視日誌。 **相依性** 這兩種儲存類型有不同的相依性： + 執行個體存放區支援的執行個體取決於 Amazon S3。當您啟動執行個體時，必須從 Amazon S3 下載 AMI。 + Amazon EBS 支援的執行個體取決於 Amazon EBS。當您啟動執行個體時，必須掛載 Amazon EBS 根磁碟區。 **建議：**如果您不確定哪種儲存類型最適合您的需求，建議您從 Amazon EBS 執行個體開始。雖然 Amazon EBS 磁碟區會產生少許費用，但意外資料遺失的風險較低。 # 最佳實務：最佳化應用程式伺服器的數目 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。生產堆疊通常包含分散於多個可用區域的多部應用程式伺服器。不過，依據日期時間或週中的日，傳入的請求數目可能會有大幅差異。您可以執行足以處理最大預期負載數量的伺服器，但大多數情況下，您最後支付的伺服器容量都比實際需要的多。為了有效地執行您的站點，建議的實務就是讓伺服器數目與目前的請求數量相符。 OpsWorks Stacks 提供三種方法來管理伺服器執行個體的數量。 + [全年無休執行個體](workinginstances-starting.md)為手動啟動，並會持續執行到手動停止為止。 + Stacks OpsWorks 會根據使用者指定的排程自動啟動和停止[時間型執行個體](workinginstances-autoscaling.md)。 + [當 Stacks 超過 CPU 或記憶體使用率等使用者指定負載指標的閾值時，負載型執行個體](workinginstances-autoscaling.md)會自動啟動和停止。 OpsWorks **注意** 在建立和設定堆疊的時間式和負載式執行個體之後， OpsWorks Stacks 即會根據指定的組態自動啟動和停止這些執行個體。除非您決定變更組態或執行個體數目，否則您都不需要更動它們。 **建議：**如果您管理的堆疊上有很多個應用程式伺服器執行個體，我們建議您混合使用這三種執行個體類型。下列範例說明如何管理堆疊的伺服器容量，以處理具備下列特點的不同每日請求數量。 + 平均請求數量會在一天中出現正弦曲線般的差異。 + 平均請求數量最少要 5 個應用程式伺服器執行個體。 + 平均請求數量最多要 16 個應用程式伺服器執行個體。 + 通常，一或兩個應用程式伺服器執行個體即可處理遽增的請求數量。這種便利的模型主要是基於討論用途而設，但您可以輕鬆地順應請求數量的變動來調整，也可以擴展這個模型以處理每週的變動。下圖說明如何使用這三種執行個體類型來管理此請求數量。 ![\[Graph showing instance types over 24 hours: time-based, load-based, and 24/7, with average load curve.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/autoscaling.png) 此範例具有下列特性： + 堆疊具備 3 個全年無休執行個體，這些執行個體絕不中斷並會持續處理基本負載。 + 堆疊具備 12 個時間式執行個體，這些執行個體是設定為處理平均每日變動。其中一個從下午 10 點執行到上午 2 點，另外兩個從下午 8 點執行到下午 10 點和上午 2 點執行到上午 4 點，以此類推。為求簡化，此圖表會每兩小時修改一次時間式執行個體，但如果您需要更精確的控制，則可以每小時修改一次數目。 + 此堆疊具備的負載式執行個體足以處理超過全年無休和時間式執行個體可處理的流量高峰。 OpsWorks Stacks 只有在所有目前執行中伺服器的負載超過指定的指標時，才會啟動負載型執行個體。非執行中執行個體的成本極低 (Amazon EBS 後端執行個體）或沒有任何成本（執行個體存放區後端執行個體），因此建議的做法是建立足夠的執行個體，以輕鬆處理您預期的最大請求磁碟區。在這個範例中，堆疊應該至少有三個負載式執行個體。 **注意** 請務必將這所有三種執行個體類型分散於多個可用區域，以降低任何服務中斷的影響。 # 最佳實務：管理許可 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您必須具備某種形式的 AWS 登入資料，才能存取您帳戶的資源。以下是一些將存取提供給您員工的一般性準則。 + 首先，也是第一步，我們建議您不要使用您帳戶的根登入資料存取 AWS 資源。反之，為您的員工建立 [IAM 身分](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)，並新增提供適當存取權的許可。然後，每位員工都可以使用自己的登入資料來存取資源。 + 員工應僅具備存取他們需要用來執行其工作之資源的許可。例如，應用程式開發人員僅需要存取執行其應用程式的堆疊。 + 員工應僅具備使用他們需要用來執行其工作之動作的許可。應用程式開發人員可能需要開發堆疊的完整許可，以及將他們的應用程式部署到對應生產堆疊的許可。他們可能不需要啟動或停止生產堆疊上執行個體的許可、建立或刪除 layer 的許可等。如需管理許可的詳細一般性資訊，請參閱 [AWS 安全登入資料](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)。您可以使用 OpsWorks Stacks 或 IAM 來管理使用者許可。請注意，這兩種選項並非互斥關係，有時候您可能會希望同時使用兩者。 **OpsWorks Stacks 許可管理** 每個堆疊都有一個 **Permissions (許可)** 頁面，您可以使用該頁面來授予使用者存取堆疊的許可，以及指定他們能夠執行的動作。您可以透過設定下列其中一個許可層級，來指定使用者的許可。每個層級代表一個 IAM 政策，授予一組標準動作的許可。 + **Deny (拒絕)** 會拒絕以任何方式與堆疊互動的許可。 + **Show (顯示)** 會授予檢視堆疊組態的許可，但是不會授予以任何方式修改堆疊狀態的許可。 + **Deploy (部署)** 包含 **Show (顯示)** 許可，並且也會授予使用者部署應用程式的許可。 + **Manage (管理)** 包含 **Deploy (部署)** 許可，並且也會允許使用者執行各種堆疊管理動作，例如建立或刪除執行個體和 layer。 **管理**許可層級不會授予少量高階 OpsWorks Stacks 動作的許可，包括建立或複製堆疊。您必須使用 IAM 政策來授予這些許可。除了設定許可層級之外，您也可以使用堆疊的 **Permissions (許可)** 頁面指定使用者是否在堆疊的執行個體上具有 SSH/RDP 和 sudo/admin 權限。如需 OpsWorks Stacks 許可管理的詳細資訊，請參閱[授予每個堆疊的許可](opsworks-security-users-console.md)。如需管理 SSH 存取的詳細資訊，請參閱[管理 SSH 存取](security-ssh-access.md)。 **IAM 許可管理** 透過 IAM 許可管理，您可以使用 IAM 主控台、API 或 CLI 將 JSON 格式的政策連接至明確指定其許可的使用者。如需 IAM 許可管理的詳細資訊，請參閱[什麼是 IAM？](https://docs.aws.amazon.com/IAM/latest/UserGuide/Introduction.html)。 **建議：**從 OpsWorks Stacks **許可**管理開始。若您需要微調使用者的許可，或授予未包含在 **Manage (管理)** 許可層級中的使用者許可，您可以合併使用兩種方法。 OpsWorks Stacks 接著會評估這兩個政策，以判斷使用者的許可。 **重要** 如果使用者有多個具有衝突許可的政策，拒絕一律會獲勝。例如，假設您將 IAM 政策連接到允許存取特定堆疊的使用者，但也使用堆疊的**許可**頁面將**拒絕**許可層級指派給使用者。**Deny (拒絕)** 許可層級會取得優先順序，使用者將無法存取堆疊。如需詳細資訊，請參閱 [IAM 政策評估邏輯](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。例如，假設您希望除了新增和刪除 layer 之外，使用者能夠在堆疊上執行大多數的操作。 + 請指定 **Manage (管理)** 許可 layer 級，允許使用者執行大多數的堆疊管理動作，包含建立和刪除 layer。 + 再將以下[客戶受管政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html)連接到使用者，拒絕在該堆疊上使用 [CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html) 和 [DeleteLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DeleteLayer.html) 動作的許可。您可以透過其 *Amazon Resource Name (ARN)[https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#ARN](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#ARN)* 識別堆疊，該資訊可在堆疊的 **Settings (設定)** 頁面上取得。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "opsworks:CreateLayer", "opsworks:DeleteLayer" ], "Resource": "arn:aws:opsworks:*:*:stack/2f18b4cb-4de5-4429-a149-ff7da9f0d8ee/" } ] } ``` ------ 如需包含範例政策的詳細資訊，請參閱[連接 OpsWorks IAM 政策來管理 Stacks 許可連接 IAM 政策](opsworks-security-users-policy.md)。 **注意** 使用 IAM 政策的另一種方法是設定條件，限制具有指定 IP 地址或地址範圍的員工對堆疊的存取。例如，若要確保員工僅能從您公司的防火牆內部存取堆疊，請設定將存取限制在您公司 IP 地址範圍內的條件。如需詳細資訊，請參閱[條件](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition)。 # 最佳實務：管理和部署應用程式與技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 會從遠端儲存庫將應用程式和技術指南部署到每個新執行個體。在執行個體的生命週期內，您必須經常更新堆疊的線上執行個體應用程式或技術指南，以新增功能、修正錯誤等等。有多種方法可以管理堆疊的應用程式和技術指南，但您使用的方法應該滿足下列一般要求： + 所有生產堆疊執行個體應具有相同的應用程式和自訂技術指南程式碼，但某些有限的例外用於 A/B 測試等用途。 + 即使發生問題，部署更新也不應中斷網站的操作。本節說明管理和部署應用程式與自訂技術指南的建議實務。 **Topics** + [維持一致性](#best-deploy-consistency) + [部署程式碼到線上執行個體](#best-deploy-deploy) ## 維持一致性通常，您需要維持嚴格控制在生產堆疊上執行的應用程式或技術指南程式碼。一般而言，所有執行個體應執行目前已核准版本的程式碼。更新應用程式或技術指南以及因應特殊情況 (例如執行 A/B 測試) 時會出現例外情況，如稍後所述。應用程式和技術指南程式碼會以兩種方式從指定來源儲存庫部署到堆疊的執行個體： + 當您啟動執行個體時， OpsWorks Stacks 會自動將目前的應用程式和技術指南程式碼部署到執行個體。 + 對於線上執行個體，您必須透過執行[部署命令](workingapps-deploying.md) (適用於應用程式) 或[更新自訂技術指南命令](workingstacks-commands.md) (適用於技術指南) 來手動部署目前的應用程式或技術指南。因為有兩種部署機制，所以仔細管理來源碼以避免在不同執行個體上無意中執行不同程式碼非常重要。例如，如果您從 Git 主分支部署應用程式或技術指南， OpsWorks Stacks 會部署該分支當時的內容。如果您更新主分支中的程式碼，然後啟動新執行個體，該執行個體會將具有比舊執行個體的更新版程式碼。較新的版本甚至可能不受批准用於生產。 **建議：Amazon S3 Archives** 為了確保您的所有執行個體都具有核准的程式碼版本，我們建議您從 Amazon Simple Storage Service (Amazon S3) 封存檔部署應用程式和技術指南。這可保證程式碼是靜態成品 - .zip 或其他封存檔案 - 必須明確更新。此外，Amazon S3 非常可靠，因此您很少會無法存取封存。為了進一步確保一致性，請使用命名慣例或使用 [Amazon S3 版本控制](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)來明確版本化每個封存檔案，這可提供稽核線索並輕鬆還原至較早版本。例如，您可以使用像是 [Jenkins](https://jenkins.io/index.html) 的工具來建立部署管道。確認並測試您要部署的程式碼之後，請建立封存檔案並將其上傳至 Amazon S3。所有應用程式部署或技術指南更新，都會在該封存檔案和安裝程式碼的每個執行個體中具有相同程式碼。 **建議：Git 或 Subversion 儲存庫** 如果您希望使用 Git 或 Subversion 儲存庫，請不要從主要分支部署。反之，請標記已核准版本並指定該版本為[應用程式](workingapps-creating.md#workingapps-creating-source)或[技術指南](workingcookbook-installingcustom-enable.md#workingcookbook-installingcustom-enable-repo)來源。 ## 部署程式碼到線上執行個體 OpsWorks Stacks 不會自動將更新的程式碼部署到線上執行個體。您必須手動執行該操作，這會有下列挑戰： + 有效部署更新，而不影響網站在部署程序中處理客戶請求的能力。 + 處理不成功的部署，可能是因為部署的應用程式或技術指南問題，也可能是部署程序本身的問題。最簡單的方法是執行預設的[部署命令](workingapps-deploying.md) (適用於應用程式) 或[更新自訂技術指南命令](workingstacks-commands.md) (適用於技術指南)，會同時部屬每個執行個體的更新。這種方法非常簡單且快速，但沒有錯誤的餘地。若部署失敗或更新的程式碼發生任何問題，每個您生產堆疊中的執行個體都會受到影響，可能中斷或停用您的網站，直到您修正問題或是還原至先前版本為止。 **建議：**使用穩健的部署策略，可讓執行舊版本程式碼的執行個體繼續處理請求，直到您成功驗證部署並可以放心地傳輸所有傳入流量到新的版本。下列各節提供兩個穩健部署策略的範例，接著會討論如何在部署期間管理後端資料庫。為簡潔起見，僅說明應用程式更新，但您也可以對技術指南使用類似的策略。 **Topics** + [使用滾動部署](#best-deploy-rolling) + [使用單獨的堆疊](#best-deploy-environments) + [管理後端資料庫](#best-deploy-db) ### 使用滾動部署滾動部署會以多個階段更新堆疊之線上應用程式伺服器執行個體的應用程式。對於每個階段，您將更新線上執行個體的子集合，並在下一階段開始之前驗證更新是否成功。如果您遇到問題，仍在執行舊應用程式版本的執行個體可以繼續處理傳入流量，直到您解決問題為止。下列範例假設您使用的建議做法，是跨多個可用區域分發堆疊的應用程式伺服器執行個體。 **執行滾動部署** 1. 在[部署應用程式頁面](workingapps-deploying.md)上，選擇 **Advanced (進階)**，然後選擇單一應用程式伺服器執行個體，並將應用程式部署到該執行個體。如果您想要謹慎行事，您可以在部署應用程式之前從負載平衡器移除該執行個體。這可確保使用者不會遇到更新的應用程式，直到您驗證其正確運作。如果您使用 Elastic Load Balancing，請使用 Elastic Load Balancing 主控台、CLI 或 SDK 從負載平衡器[移除執行個體](https://docs.aws.amazon.com/opsworks/latest/userguide/load-balancer-elb.html)。 1. 請驗證更新的應用程式是否正常運作，以及執行個體是否具有可接受的效能指標。如果您從 Elastic Load Balancing 負載平衡器移除執行個體，請使用 Elastic Load Balancing 主控台、CLI 或 SDK 進行還原。更新的應用程式版本現在會處理使用者請求。 1. 將更新部署到可用區域中的其餘執行個體，並驗證其是否正確運作並具有可接受的指標。 1. 對堆疊的其他可用區域重複步驟 3，一次進行一個區域。如果您想要特別謹慎，請重複步驟 1 – 3。 **注意** 如果您使用 Elastic Load Balancing 負載平衡器，您可以使用其運作狀態檢查來驗證部署是否成功。但是，請將 [ping 路徑](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)設定為檢查相依性並驗證一切是否正常運作的應用程式，而不是僅確認應用程式伺服器正在執行的靜態檔案。 ### 使用單獨的堆疊管理應用程式的另一種方法，是為應用程式生命週期的每個階段使用單獨的堆疊。不同的堆疊有時稱為環境。此模式可讓您對不可公開存取的堆疊進行開發和測試。當您準備好部署更新時，請將使用者流量從託管目前應用程式版本的堆疊，切換到託管更新版本的堆疊。 **Topics** + [使用開發、暫存和生產堆疊](#best-deploy-environments-stacks) + [使用藍/綠部署策略](#best-deploy-environments-blue-green) #### 使用開發、暫存和生產堆疊最常見的方法使用下列堆疊。 **開發堆疊** 使用開發堆疊執行任務，例如實作新功能或修正錯誤。開發堆疊實質上是一個原型生產堆疊，包含在生產堆疊中的相同 layer、應用程式、資源等等。由於開發堆疊通常不必處理與生產堆疊相同的負載，因此通常可以使用較少或較小的執行個體。開發堆疊不公開；您可以控制存取，如下所示： + 透過設定應用程式伺服器或負載平衡器[安全群組入站規則](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)來限制網路存取，以僅接受來自指定 IP 地址或地址範圍的傳入請求。例如，限制對公司地址範圍內地址的 HTTP、HTTPS 和 SSH 存取。 + 使用堆疊[的許可頁面](opsworks-security-users.md)控制對 OpsWorks Stacks 堆疊管理功能的存取。例如，授予開發團隊管理許可層級，並授予其他所有員工顯示許可。 **預備堆疊** 使用預備堆疊來測試和完成更新生產堆疊的候選。當您完成開發，請透過[複製開發堆疊](workingstacks-cloning.md)來建立預備堆疊。然後在預備堆疊上執行測試套件，並將更新部署到該堆疊，以修正發生的問題。預備堆疊也不公開；您可以像控制開發堆疊一樣控制堆疊和網路存取。請注意，當您複製開發堆疊以建立預備堆疊時，您可以複製 Stacks OpsWorks 許可管理授予的許可。不過，複製並不影響使用者的 IAM 政策所授予之許可。您必須使用 IAM 主控台、CLI 或軟體開發套件來修改這些許可。如需詳細資訊，請參閱[管理使用者許可](opsworks-security-users.md)。 **生產堆疊** 生產堆疊是公開堆疊，可支援您目前的應用程式。當預備堆疊通過測試，您可將其提升為生產堆疊，並淘汰舊的生產堆疊。如需如何執行此作業的範例，請參閱 [使用藍/綠部署策略](#best-deploy-environments-blue-green)。 **注意** 不是使用 OpsWorks Stacks 主控台手動建立堆疊，而是為每個堆疊建立 AWS CloudFormation 範本。這種方法具有下列優勢：速度和便利性 – 當您啟動範本時， CloudFormation 會自動建立堆疊，包括所有必要的執行個體。一致性 – 將每個堆疊的範本存放在您的來源儲存庫中，以確保開發人員將相同的堆疊用於相同的用途。 #### 使用藍/綠部署策略「藍/綠」**部署策略的常見方法，是有效使用單獨堆疊來部署應用程式更新到生產堆疊。 + 藍色環境是生產堆疊，託管目前的應用程式。 + 綠色環境是預備堆疊，託管更新的應用程式。當您準備好將更新的應用程式部署到生產環境，請將使用者流量從藍色堆疊切換到綠色堆疊，此綠色堆疊將成為新的生產堆疊。然後淘汰舊的藍色堆疊。下列範例說明如何使用 OpsWorks Stacks 堆疊執行藍綠部署，以及 [Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) 和 [Elastic Load Balancing 負載平衡器](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/SvcIntro.html)集區。進行切換之前，您應該先確保下列各項： + 綠色堆疊上的應用程式更新已通過測試，並準備好用於生產。 + 綠色堆疊與藍色堆疊相同，差別在於其包含已更新的應用程式且不公開。兩個堆疊在每個 layer 中具有相同的許可、數目以及執行個體類型，相同[以時間為基礎和以負載為基礎](workinginstances-autoscaling.md)的組態等等。 + 所有綠色堆疊的全年無休執行個體、排定之以時間為基礎的執行個體都是在線。 + 您有一個 Elastic Load Balancing 負載平衡器集區，可動態連接至任一堆疊中的圖層，並可[預先暖機](https://aws.amazon.com/articles/1636185810492479#pre-warming)處理預期的流量。 + 您已使用 Route 53 [加權路由功能](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)，在包含集區負載平衡器的託管區域中建立記錄集。 + 您已為負載平衡器指派了非零權重，該負載平衡器連接至藍色堆疊的應用程式伺服器 layer，並且為未使用的負載平衡器指派了零權重。這可確保藍堆疊的負載平衡器處理所有傳入流量。 **將使用者切換至綠色堆疊** 1. [連接集區中其中一個未使用的負載平衡器](layers-elb.md)到綠色堆疊的應用程式伺服器 layer。在某些情況下，例如，當您預期出現瞬間流量或如果您無法設定負載測試以逐步增加流量，請[預先培養](https://aws.amazon.com/articles/1636185810492479#pre-warming)負載平衡器以處理預期的流量。 1. 在所有綠色堆疊的執行個體都通過 Elastic Load Balancing 運作狀態檢查後，請變更 Route 53 記錄集中的權重，讓綠色堆疊的負載平衡器具有非零權重，而藍色堆疊的負載平衡器具有對應的減輕權重。我們建議您先讓綠色堆疊處理一小部分請求，比方說 5%，而藍色堆疊處理其餘請求。您現在有兩個生產堆疊，綠色堆疊處理一些傳入請求，藍色堆疊處理其餘請求。 1. 監控綠色堆疊的效能指標。如果可接受，請增加綠色堆疊的權重，以便其可以處理約 10% 的傳入流量。 1. 請重複步驟 3，直到綠色堆疊處理約一半的傳入流量。此時任何問題都應已浮現，因此如果綠色堆疊的表現令人滿意，您可以透過將藍色堆疊的權重減少到零來完成程序。綠色堆疊現在是新的藍色堆疊，並處理所有傳入的流量。 1. 從舊藍色堆疊的應用程式伺服器 layer [分離負載平衡器](layers-elb.md)並傳回到集區。 1. 雖然舊的藍色堆疊不再處理使用者請求，但我們建議保留一段時間，以防新藍色堆疊出現問題。若發生該情況，您可以透過反轉程序來復原更新，以將傳入流量引導回舊的藍色堆疊。當您確信新藍色堆疊的運作可接受，請[關機舊藍色堆疊](workingstacks-shutting.md)。 ### 管理後端資料庫如果您的應用程式依賴後端資料庫，您將需要從舊應用程式轉換到新的應用程式。 OpsWorks Stacks 支援下列資料庫選項。 **Amazon RDS Layer** 使用 [Amazon Relational Database Service (Amazon RDS)](workinglayers-db-rds.md) layer，您可以分別建立 RDS 資料庫執行個體，然後向堆疊註冊該執行個體。您可以一次只用一個堆疊來註冊 RDS 資料庫執行個體，但您可以將 RDS 資料庫執行個體從某個堆疊切換到另一個堆疊。 OpsWorks Stacks 會以應用程式可輕易使用的格式，在您的應用程式伺服器上安裝具有連線資料的檔案。 OpsWorks Stacks 也會將資料庫連線資訊新增至堆疊組態和部署屬性，而這些屬性可由配方存取。您也可以使用 JSON 提供應用程式的連線資料。如需詳細資訊，請參閱[連線至資料庫](workingapps-connectdb.md)。更新依賴於資料庫的應用程式會帶來兩個基本挑戰： + 請確保在轉換期間正確記錄每個交易，同時避免新舊應用程式版本之間的競爭條件。 + 以限制對網站效能影響的方式執行轉換，並最大限度減少或排除停機時間。使用本主題中說明的部署策略時，您不能僅從舊應用程式分離資料庫，再將其重新連接到新的應用程式。兩個版本的應用程式在轉換期間會平行執行，並且必須能夠存取相同的資料。下列說明了兩種管理轉換的方法，這兩種方法各自有其優點和挑戰之處。方法 1：讓兩個應用程式連線到相同的資料庫 **優點** + 在轉換期間沒有停機時間。一個應用程式會逐漸停止存取資料庫，而另一個應用程式會逐漸接管。 + 您不需要同步兩個資料庫之間的資料。 **挑戰** + 兩個應用程式都存取相同的資料庫，因此您必須管理存取以防止資料遺失或損壞。 + 如果您需要遷移到新的資料庫結構描述，則舊的應用程式版本必須能夠使用新的結構描述。如果您使用的是單獨的堆疊，此方法可能最適合 Amazon RDS，因為執行個體不會永久繫結至特定堆疊，並且可以由在不同堆疊上執行的應用程式存取。但是，您無法一次註冊具有多個堆疊的 RDS 資料庫執行個體，因此您必須向兩個應用程式提供連線資料，例如使用 JSON。如需詳細資訊，請參閱[使用自訂配方](workingapps-connectdb.md#workingapps-connectdb-custom)。如果您使用滾動升級，新舊應用程式版本會託管在相同的堆疊上，因此您可以使用 Amazon RDS 或 MySQL layer。方法 2：為每個應用程式版本提供自己的資料庫 **優點** + 每個版本都有自己的資料庫，所以結構描述不需相容。 **挑戰** + 在轉換期間同步兩個資料庫之間的資料，而不遺失或損壞資料。 + 確保您的同步程序不會導致嚴重停機時間，或大幅降低網站效能。如果您使用單獨的堆疊，每個堆疊都有自己的資料庫。如果您使用滾動部署，則可以將兩個資料庫連接至堆疊，每個應用程式一個。如果舊應用程式和更新應用程式沒有相容的資料庫結構描述，則此方法更佳。 **建議：**通常，我們建議您使用 Amazon RDS layer 做為應用程式的後端資料庫，因為它更靈活，可用於任何轉換案例。如需如何處理轉換的詳細資訊，請參閱 [Amazon RDS 使用者指南](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)。 # 本機封裝技術指南依存性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用 Berkshelf 在本機封裝技術指南相依性、將套件上傳至 Amazon S3，以及修改堆疊以使用 Amazon S3 上的套件做為技術指南來源。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。下列逐步解說說明如何將技術指南及其相依性預先封裝至 .zip 檔案，然後使用 .zip 檔案做為 Stacks 中 Linux OpsWorks 執行個體的技術指南來源。第一個演練說明如何封裝單一技術指南。第二個演練說明如何封裝多個技術指南。在開始之前，請先安裝 [Chef Development Kit](https://www.chef.io/downloads) (又稱為 Chef DK)，此為由 Chef 社群建置的各種工具。您需要此項目才能使用 `chef` 命令列工具。 ## 在 Chef 12 中本機封裝依存性在 Chef 12 Linux 中，根據預設，Berkshelf 不會再安裝到堆疊執行個體。我們建議您在本機開發電腦上安裝及使用 Berkshelf，以在本機封裝您的技術指南相依性。將包含相依性的套件上傳至 Amazon S3。最後，修改您的 Chef 12 Linux 堆疊，使其使用上傳的套件做為技術指南來源。請在於 Chef 12 中封裝技術指南時注意下列差異。 1. 在本機電腦上，透過執行 `chef` 命令列工具建立技術指南。 ``` chef generate cookbook "server-app" ``` 此命令會建立技術指南、一個 Berksfile、一個 `metadata.rb` 檔案和配方目錄，並將他們置放在一個具有和技術指南相同名稱的資料夾中。以下範例顯示建立項目的結構。 ``` server-app <-- the cookbook you've just created └── Berksfile ├── metadata.rb └── recipes ``` 1. 在文字編輯器中，編輯 Berksfile，使其指向 `server-app` 技術指南依存的技術指南。在我們的範例中，我們希望 `server-app` 依存於來自 Chef Supermarket 的 [https://supermarket.chef.io/cookbooks/java](https://supermarket.chef.io/cookbooks/java) 技術指南。我們會指定版本 1.50.0 或更新的 minor (次要) 版本，但您可以在單引號中輸入任何發佈的版本。儲存您的變更並結束檔案。 ``` source 'https://supermarket.chef.io' cookbook 'java', '~> 1.50.0' ``` 1. 編輯 `metadata.rb` 檔案來新增依存性。儲存您的變更並結束檔案。 ``` depends 'java' , '~> 1.50.0' ``` 1. 變更為 Chef 為您建立的 `server-app` 技術指南目錄，然後執行 `package` 命令建立技術指南的 `tar` 檔案。若您要封裝多個技術指南，建議您在所有技術指南存放的根目錄中執行此命令。若要封裝單一技術指南，請在技術指南目錄層級執行此命令。在此範例中，我們會在 `server-app` 目錄執行此命令。 ``` berks package cookbooks.tar.gz ``` 輸出結果與以下內容相似。`tar.gz` 檔案會在您的本機目錄內建立。 ``` Cookbook(s) packaged to /Users/username/tmp/berks/cookbooks.tar.gz ``` 1. 在中 AWS CLI，將您剛建立的套件上傳至 Amazon S3。在您上傳至 S3 後記下技術指南套件的新 URL，您在堆疊設定中將需要此 URL。 ``` aws s3 cp cookbooks.tar.gz s3://bucket-name/ ``` 輸出結果與以下內容相似。 ``` upload: ./cookbooks.tar.gz to s3://bucket-name/cookbooks.tar.gz ``` 1. 在 OpsWorks Stacks 中，[修改堆疊](https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-installingcustom-enable.html)以使用您上傳做為技術指南來源的套件。 1. 將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 設定設為 **Yes (是)**。 1. 將 **Repository type (儲存庫類型)** 設定為 **S3 Archive (S3 封存)**。 1. 在 **Repository URL (儲存庫 URL)** 中，貼上您在步驟 5 中上傳之技術指南套件的 URL。儲存您的堆疊變更。 ## 本機封裝單一技術指南依存性 **** 1. 在本機電腦上，透過使用 chef 命令列工具建立技術指南： ``` chef generate cookbook "server-app" ``` 此命令會建立技術指南及一個 Berksfile，並將他們置放在一個具有和技術指南相同名稱的資料夾中。 1. 變更為 Chef 為您建立的技術指南目錄，然後透過執行下列命令封裝所有項目： ``` berks package cookbooks.tar.gz ``` 輸出如下： ``` Cookbook(s) packaged to /Users/username/tmp/berks/cookbooks.tar.gz ``` 1. 在中 AWS CLI，將您剛建立的套件上傳至 Amazon S3： ``` aws s3 cp cookbooks.tar.gz s3://bucket-name/ ``` 輸出如下： ``` upload: ./cookbooks.tar.gz to s3://bucket-name/cookbooks.tar.gz ``` 1. 在 OpsWorks Stacks 中，[修改堆疊](https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-installingcustom-enable.html)以使用您上傳做為技術指南來源的套件。 ## 本機封裝多個技術指南依存性此範例會建立兩個技術指南，並為他們封裝依存性。 1. 在本機電腦上，執行下列 `chef` 命令以產生兩個技術指南： ``` chef generate cookbook "server-app" chef generate cookbook "server-utils" ``` 在此範例中，server-app 技術指南會執行 Java 組態，因此我們需要新增 Java 的依存性。 1. 編輯 `server-app/metadata.rb` 以在社群 Java 技術指南上新增依存性： ``` maintainer "The Authors" maintainer_email "you@example.com" license "all_rights" description "Installs/Configures server-app" long_description "Installs/Configures server-app" version "0.1.0" depends "java" ``` 1. 透過編輯技術指南根目錄中的 Berksfile 檔案，告知 Berkshelf 要封裝的內容為何，如下所示： ``` source "https://supermarket.chef.io" cookbook "server-app", path: "./server-app" cookbook "server-utils", path: "./server-utils" ``` 您的檔案結構現在看起來應該會像是這樣： ``` .. └── Berksfile ├── server-app └── server-utils ``` 1. 最後，建立 zip 套件，將其上傳至 Amazon S3，並修改 Stacks OpsWorks 堆疊以使用新的技術指南來源。若要執行此作業，請遵循[本機封裝單一技術指南依存性](#best-practices-packaging-cookbooks-locally-one)中的步驟 2 到 4。 ## 其他資源如需封裝技術指南依存性的詳細資訊，請參閱下列項目。 + AWS DevOps 部落格上的[如何使用 Berkshelf 本機封裝技術指南依存性](https://aws.amazon.com/blogs/devops/how-to-package-cookbook-dependencies-locally-with-berkshelf/) + OpsWorks 論壇上的 [Linux Chef 12 搭配 Berkshelf](https://forums.aws.amazon.com/thread.jspa?threadID=221131) + OpsWorks 論壇[上 Chef 12 中的 Berkshelf](https://forums.aws.amazon.com/message.jspa?messageID=694464) + 本指南中的[安裝自訂技術指南](workingcookbook-installingcustom-enable.md) + 本指南中的[技術指南儲存庫](workingcookbook-installingcustom-repo.md) # 堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。堆疊是最上層 OpsWorks 的 Stacks 實體。它代表您想要集合管理的一組執行個體，通常是因為它們具有常見用途，例如服務 PHP 應用程式。除當成容器使用之外，堆疊還可以處理適用於整個執行個體群組的任務，例如管理應用程式和技術指南。例如，堆疊的用途是為可能看起來類似以下項目的 Web 應用程式提供服務： + 一組應用程式伺服器執行個體，每個處理一部分的傳入流量。 + 負載平衡器執行個體，接收傳入流量並將它分發至應用程式伺服器。 + 資料庫執行個體，做為應用程式伺服器的後端資料存放區。常見的做法是讓多個堆疊代表不同的環境。堆疊集一般包含： + 開發人員使用的開發堆疊，新增功能、修復錯誤及執行其他開發和維護任務。 + 預備堆疊，驗證更新或修正後再公開它們。 + 生產堆疊，這是處理使用者傳入請求的公開版本。本節說明使用堆疊的基本概念。 **Topics** + [將堆疊從 Amazon EC2-Classic 遷移至 VPC](workingstacks-migrate-ec2-vpc.md) + [建立新的堆疊](workingstacks-creating.md) + [在 VPC 中執行堆疊](workingstacks-vpc.md) + [更新堆疊](workingstacks-edit.md) + [複製堆疊](workingstacks-cloning.md) + [執行 OpsWorks Stacks Stack 命令](workingstacks-commands.md) + [使用自訂 JSON](workingstacks-json.md) + [刪除堆疊](workingstacks-shutting.md) # 將堆疊從 Amazon EC2-Classic 遷移至 VPC **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本主題說明如何將 AWS OpsWorks Stacks 堆疊從 Amazon EC2 Classic 網路平台遷移至 [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) (Amazon VPC) 網路。如果您在 2013-12-04 之前建立 AWS 帳戶，您可能在某些 AWS 區域中支援 EC2-Classic。有些 Amazon EC2 資源和功能 (例如增強型聯網和較新的執行個體類型) 需要 Virtual Private Cloud (VPC)。有些資源可在 EC2-Classic 與 VPC 之間共用，而有些卻不能。為了避免服務中斷，建議您將 AWS OpsWorks Stacks 堆疊遷移至 VPC。 **Topics** + [先決條件](#workingstacks-migrate-vpc-prereqs) + [將 AWS OpsWorks Stacks 堆疊遷移至 VPC](#workingstacks-migrate-vpc) + [另請參閱](#workingstacks-migrate-seealso) ## 先決條件開始之前，您必須擁有符合 AWS OpsWorks Stacks 組態需求的 VPC。若要在 VPC 中設定私有子網路 AWS OpsWorks Stacks，請參閱本指南[在 VPC 中執行堆疊](workingstacks-vpc.md)中的。您可以使用 Amazon VPC 管理主控台建立自訂 VPC。如需詳細資訊，請參閱《[Amazon Virtual Private Cloud 使用者指南》中的 Amazon VPC 主控台精靈組態](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_wizard.html)和 [VPCs 和子網路](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_wizard.html)。 *Amazon Virtual Private Cloud * 若要繼續遷移，您需要 VPC ID 和要使用的子網路 ID。 ## 將 AWS OpsWorks Stacks 堆疊遷移至 VPC 首先，使用 AWS OpsWorks Stacks 主控台或 API 複製現有的 EC2-Classic 堆疊。然後，將現有堆疊的資源移至新堆疊。在複製的堆疊中啟動新的執行個體，並部署應用程式。驗證新堆疊是否正常運作。最後，從 EC2-Classic 堆疊刪除 EC2-Classic 資源，然後刪除舊堆疊。 1. 將現有的 EC2-Classic 堆疊複製到 VPC。複製堆疊會將堆疊設定、 layer、應用程式、使用者和使用者許可複製到新堆疊。如需如何複製堆疊的詳細資訊，請參閱本指南[複製堆疊](workingstacks-cloning.md)中的。您也可以使用 AWS OpsWorks Stacks API 複製堆疊。當您使用 AWS CLI AWS SDKs複製堆疊時，請將 `VpcId` 參數的值設定為您在中建立的 VPC ID[先決條件](#workingstacks-migrate-vpc-prereqs)。如需詳細資訊，請參閱 *AWS OpsWorks Stacks API 參考*中的 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CloneStack.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CloneStack.html)。 1. 在複製堆疊的圖層中建立新的執行個體。請務必指定您在中建立的子網路 ID[先決條件](#workingstacks-migrate-vpc-prereqs)。如需如何在堆疊中建立執行個體的詳細資訊，請參閱本指南[將執行個體新增至 Layer](workinginstances-add.md)中的。 1. 將傳統資源遷移至 VPC，例如 EC2 安全群組、Elastic Load Balancing 負載平衡器和彈性 IP 地址，然後將它們與複製的堆疊建立關聯。如需詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[將您的資源遷移至 VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html#full-migrate)。 1. 向複製的堆疊註冊 Amazon EBS 磁碟區和 Amazon RDS 執行個體。如需使用堆疊註冊資源的詳細資訊，請參閱本指南[向堆疊註冊資源](resources-reg.md)中的。 Amazon EBS 磁碟區未與 VPC 相關聯，您可以在 EC2-Classic 堆疊和 VPC 中的堆疊中跨執行個體使用它們。您可以在 EC2-Classic 中向 EC2-Classic 堆疊和 VPC 中的堆疊註冊 Amazon RDS 執行個體。 1. 在複製的堆疊中啟動執行個體，然後將一小部分的工作負載移至複製的堆疊。例如，將一小部分的流量移至複製堆疊中的 Elastic Load Balancing 負載平衡器。如果您使用的是 Amazon Route 53，請參閱《*Amazon Route 53 開發人員指南*》中的將[流量路由到 ELB 負載平衡器](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)。只路由一小部分的流量，直到您確定新的堆疊正常運作並支援您的應用程式為止。讓新的堆疊在試用期間使用一小部分的流量，例如一週。驗證新堆疊是否正常運作後，請將剩餘的流量路由到堆疊。 1. 確定複製的堆疊正常運作後，請將剩餘的生產流量或工作負載移至複製的堆疊。您現在可以停止 EC2-Classic 堆疊中的執行個體。建議您將舊堆疊保持可用數週，以便在遷移後數週內新堆疊發生任何問題時，將工作負載移回舊堆疊。 1. 當新堆疊已運作幾週時，請刪除 EC2-Classic 堆疊中的執行個體。如需如何刪除執行個體的詳細資訊，請參閱本指南[刪除 OpsWorks Stacks 執行個體](workinginstances-delete.md)中的。 **重要** 請勿使用 Amazon EC2 主控台或 API 來停止或刪除 OpsWorks 執行個體。 1. 刪除 EC2-Classic 堆疊中的應用程式。如需如何刪除應用程式的詳細資訊，請參閱本指南中的[從堆疊刪除應用程式](gettingstarted-intro-clean-up.md)。 1. 刪除 EC2-Classic 堆疊。如需如何刪除堆疊的詳細資訊，請參閱本指南[刪除堆疊](workingstacks-shutting.md)中的。 ## 另請參閱 + [從 EC2-Classic 遷移至 VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html#full-migrate) + [偵錯和故障診斷指南](troubleshoot.md) + [在 VPC 中執行堆疊](workingstacks-vpc.md) # 建立新的堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要建立新的堆疊，請在 Stacks OpsWorks 儀表板上按一下**新增堆疊**。然後，您可以使用 **Add Stack (新增堆疊)** 頁面來設定堆疊。在您完成後，按一下 **Add Stack (新增堆疊)**。 **Topics** + [選擇要建立的堆疊類型](#workingstacks-creating-decision-table) + [基本選項](#workingstacks-creating-basic) + [進階選項](#workingstacks-creating-advanced) ## 選擇要建立的堆疊類型在您建立堆疊前，您必須決定要建立的堆疊類型。如需協助，請參閱下表。 | 如果您想要建立… | 在下列情況下建立此堆疊類型... | 若要了解建立方法，請遵循這些說明： | | --- | --- | --- | | 堆疊範例 | 探索 AWS OpsWorks 的基本概念，包括 Linux Chef 12 堆疊和 Node.js 應用程式範例。 | [入門：範例](gettingstarted-intro.md) | | Linux Chef 12 堆疊 | 建立使用 AWS OpsWorks 支援之最新版 Chef 的 Linux 堆疊。如果您是進階的 Chef 使用者，並想要享有廣泛的社群 cookbook (技術指南) 選擇或撰寫您自己的自訂 cookbook (技術指南)，請選擇此選項。如需詳細資訊，請參閱[Chef 12 Linux](chef-12-linux.md)。 | [入門：Linux](gettingstarted-linux.md) | | Windows Chef 12.2 堆疊 | 建立 Windows 堆疊。 | [入門：Windows](gettingstarted-windows.md) | | Linux Chef 11.10 堆疊 | 如果您的組織需要搭配 Linux 使用 Chef 11.10 以回溯相容，請建立此堆疊。 | [Chef 11 Linux 堆疊入門](gettingstarted.md) | ## 基本選項 **Add Stack (新增堆疊)** 頁面具有下列基本選項。 **Stack name (堆疊名稱)** （必要）用於在 Stacks OpsWorks 主控台中識別堆疊的名稱。名稱不需要是唯一的。 OpsWorks Stacks 也會產生堆疊 ID，這是可唯一識別堆疊的 GUID。例如，透過 [update-stack](https://docs.aws.amazon.com/cli/latest/reference/opsworks/update-stack.html) 等 [ AWS CLI](https://aws.amazon.com/documentation/cli/) 命令，您可以使用堆疊 ID 來識別特定堆疊。在您建立堆疊後，您可以選擇導覽窗格中的 **Stack (堆疊)**，然後選擇 **Stack Settings (堆疊設定)**，來尋找其 ID。此 ID 會標記為 **OpsWorks ID**。 **區域** (必要) 要啟動執行個體的 AWS 區域。 **VPC** (選用) 要啟動堆疊之目標 VPC 的 ID。所有執行個體都會啟動至此 VPC，而且您之後無法變更 ID。 + 如果您的帳戶支援 EC2 Classic，而且您不想要使用 VPC，您可以指定 **No VPC (無 VPC)** (預設值)。如需 EC2 Classic 的詳細資訊，請參閱「[支援的平台](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html)」。 + 如果您的帳戶不支援 EC2 Classic，您必須指定 VPC。預設設定為 **Default VPC (預設 VPC)**，其結合 EC2 Classic 簡單易用的特點與 VPC 聯網功能的優點。如果您想要在一般 VPC 中執行堆疊，您必須使用 VPC [主控台](https://console.aws.amazon.com/vpc/)、[API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html) 或 [CLI](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/Welcome.html) 來建立該 VPC。如需如何為 OpsWorks Stacks 堆疊建立 VPC 的詳細資訊，請參閱[在 VPC 中執行堆疊](workingstacks-vpc.md)。如需一般資訊，請參閱 [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html)。 **預設可用區域/預設子網路** (選用) 此設定取決於您是否在 VPC 中建立堆疊： + 如果您的帳戶支援 EC2 Classic，而且您將 **VPC** 設為 **No VPC (無 VPC)**，此設定會標記為 **Default Availability Zone (預設可用區域)**，其會指定要啟動執行個體的預設 AWS 可用區域。 + 如果您的帳戶不支援 EC2 Classic，或您選擇指定 VPC，此欄位會標記為 **Default subnet (預設子網路)**，其會指定要啟動執行個體的預設子網路。您可以在建立執行個體時覆寫此值，藉此在其他子網路中啟動執行個體。每個子網路皆會與一個可用區域相關聯。您可以在建立執行個體時覆寫此設定，讓 OpsWorks Stacks [在不同可用區域或子網路中啟動執行個體](workinginstances-add.md)。如需如何在 VPC 中執行堆疊的詳細資訊，請參閱「[在 VPC 中執行堆疊](workingstacks-vpc.md)」。 **預設作業系統** (選用) 根據預設安裝於每個執行個體上的作業系統。您有下列選項： + 其中一個內建 Linux 作業系統。 + Microsoft Windows Server 2012 R2。 + 以其中一個支援作業系統為基礎的自訂 AMI。如果您選取 **Use custom AMI (使用自訂 AMI)**，則作業系統取決於您在建立執行個體時指定的自訂 AMI。如需詳細資訊，請參閱[使用自訂 AMI](workinginstances-custom-ami.md)。如需可用作業系統的詳細資訊，請參閱「[OpsWorks Stacks 作業系統](workinginstances-os.md)」。您可以在建立執行個體時覆寫預設作業系統。不過，您無法覆寫 Linux 作業系統以指定 Windows，或覆寫 Windows 以指定 Linux 作業系統。 **預設 SSH 金鑰** （選用）來自堆疊區域的 Amazon EC2 金鑰對。預設值為 none (無)。如果您指定金鑰對， OpsWorks Stacks 會在執行個體上安裝公有金鑰。 + 若是 Linux 執行個體，您可以使用私有金鑰透過 SSH 用戶端登入堆疊的執行個體。如需詳細資訊，請參閱[使用 SSH 登入](workinginstances-ssh.md)。 + 使用 Windows 執行個體時，您可以使用私有金鑰搭配 Amazon EC2 主控台或 CLI 來擷取執行個體的管理員密碼。然後您可以使用該密碼透過 RDP 用戶端以管理員身分登入執行個體。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。如需如何管理 SSH 金鑰的詳細資訊，請參閱「[管理 SSH 存取](security-ssh-access.md)」。您可以在[建立執行個體](workinginstances-add.md)時指定不同金鑰對或不指定任何金鑰對，來覆寫此設定。 **Chef 版本** 這會顯示您已選擇的 Chef 版本。如需 Chef 版本的詳細資訊，請參閱「[Chef 版本](workingcookbook-chef11.md)」。 **使用自訂 Chef 技術指南** 是否要在堆疊的執行個體上安裝您的自訂 Chef cookbook (技術指南)。若是 Chef 12，預設設定為 **Yes (是)**。對於 Chef 11，預設設定為**否**。 **是**選項會顯示數個額外的設定，為 OpsWorks Stacks 提供從其儲存庫部署自訂技術指南至堆疊執行個體所需的資訊，例如儲存庫 URL。詳細資訊取決於您為 cookbook (技術指南) 使用的儲存庫。如需詳細資訊，請參閱[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)。 **堆疊色彩** （選用）用來代表 Stacks OpsWorks 主控台上堆疊的色調。您可以為不同的堆疊使用不同的色彩來協助區分，例如區分開發、預備和生產堆疊。 **堆疊標籤** 您可以在堆疊和 layer 層級套用標籤。建立標籤時，您會將標籤套用於已加上標籤的結構中每項資源。例如，如果您將標籤套用至堆疊，您要將標籤套用至層中的每個層，以及每個層中的每個執行個體、Amazon EBS 磁碟區或層中的 Elastic Load Balancing 負載平衡器。如需如何啟用標籤並使用它們來追蹤和管理 OpsWorks Stacks 資源成本的詳細資訊，請參閱帳單與成本管理使用者指南中的[使用成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)和[啟用使用者定義的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)。 **如需在 Stacks OpsWorks 中標記的詳細資訊，請參閱 [Tags (標籤)](tagging.md)。 ## 進階選項對於進階設定，按一下 **Advanced >> (進階 >>)** 以顯示 **Advanced options (進階選項)** 和 **Security (安全)** 區段。 **Advanced options (進階選項)** 區段具有下列選項：預設根設備類型決定要用於執行個體根磁碟區的儲存體類型。如需詳細資訊，請參閱[儲存體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)。 + Linux 堆疊預設使用 Amazon EBS 支援的根磁碟區，但您也可以指定執行個體存放區支援的根磁碟區。 + Windows 堆疊必須使用 Amazon EBS 支援的根磁碟區。 IAM 角色（選用）堆疊的 AWS Identity and Access Management (IAM) 角色，由 OpsWorks Stacks 代表您與 AWS 互動。預設 IAM 執行個體描述檔（選用）要與堆疊的 Amazon EC2 執行個體相關聯的預設 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-toplevel.html)。此角色會將存取 AWS 資源 (例如 S3 儲存貯體) 的許可授予在堆疊執行個體上執行的應用程式。 + 若要將特定許可授予應用程式，請選擇具備適當政策的現有執行個體描述檔 (角色)。 + 一開始，設定檔的角色不會授予任何許可，但您可以使用 IAM 主控台、API 或 CLI 來連接適當的政策。如需詳細資訊，請參閱[指定在 EC2 執行個體上執行之應用程式的許可](opsworks-security-appsrole.md)。 API 端點區域此設定會使用您在堆疊之基本設定中選擇的區域做為其值。您可以從下列區域端點中選擇。 + 美國東部 (維吉尼亞北部) 區域 + 美國東部 (俄亥俄) 區域 + 美國西部 (奧勒岡) 區域 + 美國西部 (加利佛尼亞北部) 區域 + 加拿大（中部）區域（僅限 API；不適用於在中建立的堆疊 AWS 管理主控台 + 亞太地區 (孟買) 區域 + 亞太區域 (新加坡) 區域 + 亞太 (雪梨) 區域 + 亞太 (東京) 區域 + 亞太區域 (首爾) 區域 + 歐洲 (法蘭克福) 區域 + 歐洲 (愛爾蘭) 區域 + 歐洲 (倫敦) 區域 + 歐洲 (巴黎) 區域 + 南美洲 (聖保羅) 區域在某個 API 端點中建立的堆疊無法在另一個 API 端點中使用。由於 OpsWorks Stacks 使用者也是區域特定的，如果您希望其中一個端點區域中的 OpsWorks Stacks 使用者管理另一個端點區域中的堆疊，您必須將使用者匯入至與堆疊相關聯的端點。如需匯入使用者的詳細資訊，請參閱[將使用者匯入 OpsWorks Stacks](https://docs.aws.amazon.com/opsworks/latest/userguide/opsworks-security-users-manage-import.html)。主機名稱主題 (選用) 用來產生每個執行個體之預設主機名稱的字串。預設值為 **Layer Dependent (與堆疊層相依)**，這會使用執行個體堆疊層的簡短名稱，並對每個執行個體附加唯一號碼。例如，與角色相依之**負載平衡器**主題的根為 "lb"。您新增至該堆疊層的第一個執行個體會命名為 "lb1"，第二個執行個體會命名為 "lb2"，以此類推。 OpsWorks Agent version (OpsWorks 代理程式版本) （選用）是否在新版本可用時自動更新 OpsWorks Stacks 代理程式，或使用指定的代理程式版本並手動更新。此功能適用於 Chef 11.10 和 Chef 12 堆疊。預設設定為 **Manual update (手動更新)**，並已設為最新代理程式版本。 OpsWorks Stacks 會在與服務通訊的每個執行個體上安裝代理程式，並處理任務，例如啟動 Chef 執行以回應[生命週期事件](workingcookbook-events.md)。此代理程式會定期更新。您可使用兩種選項指定堆疊的代理程式版本。 + **自動更新** – 一旦更新可用， OpsWorks 堆疊會在堆疊的執行個體上自動安裝每個新的代理程式版本。 + **手動更新** – OpsWorks Stacks 會在堆疊的執行個體上安裝指定的代理程式版本。 OpsWorks 當新的代理程式版本可用，但未更新堆疊的執行個體時，Stacks 會在堆疊頁面上張貼訊息。若要更新代理程式，您必須手動[更新堆疊設定](workingstacks-edit.md)以指定新的代理程式版本，然後 OpsWorks Stacks 會更新堆疊的執行個體。您可以[更新其組態，覆寫](workinginstances-properties.md)特定執行個體的預設 **OpsWorks 代理程式版本**設定。在此情況下，會優先使用執行個體的設定。例如，假設預設設定為 **Auto-update (自動更新)**，但您為特定執行個體指定 **Manual update (手動更新)**。當 OpsWorks Stacks 發行新的代理程式版本時，它會自動更新堆疊的所有執行個體，但設定為**手動更新的**執行個體除外。若要在該執行個體上安裝新的代理程式版本，您必須手動[更新其組態](workinginstances-properties.md)並指定新的版本。主控台會顯示縮寫的代理程式版本號碼。若要查看完整版本號碼，請呼叫 AWS CLI [describe-agent-versions](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-agent-versions.html) 命令，或是同等的 API 或 SDK 方法。它們會傳回可用代理程式版本的完整版本號碼。自訂 JSON (選用) 一或多個自訂屬性，並會格式化為 JSON 結構。這些屬性會合併為[堆疊組態和部署屬性](workingcookbook-json.md)，並安裝在每個執行個體上且可供配方使用。例如，您可以透過覆寫指定預設設定的內建屬性，來使用自訂 JSON 自訂組態設定。如需詳細資訊，請參閱[使用自訂 JSON](workingcookbook-json-override.md)。 **安全性**有一個選項：**使用 OpsWorks 安全群組**，可讓您指定是否要將 OpsWorks Stacks 內建安全群組與堆疊層建立關聯。 OpsWorks Stacks 提供一組標準內建安全群組，每個 layer 各一個，預設會與 layer 相關聯。**Use OpsWorks security groups (使用 OpsWorks 安全群組)** 可讓您改為提供自己的自訂安全群組。如需詳細資訊，請參閱[使用安全群組](workingsecurity-groups.md)。 **Use OpsWorks security groups (使用 OpsWorks 安全群組)** 具有下列設定： + **是** - OpsWorks Stacks 會自動將適當的內建安全群組與每個 layer 建立關聯（預設設定）。您可以在建立堆疊層後，將其他安全群組與其建立關聯，但無法刪除內建安全群組。 + **否** - OpsWorks Stacks 不會將內建安全群組與 layer 建立關聯。您必須建立適當的 EC2 安全群組，並將安全群組與您建立的每個堆疊層建立關聯。不過，您仍然可以在建立時手動將內建安全群組與堆疊層建立關聯；只有需要自訂設定的堆疊層才需要自訂安全群組。注意下列事項： + 如果 **Use OpsWorks security groups (使用 OpsWorks 安全群組)** 設為 **Yes (是)**，您無法透過將更嚴格的安全群組新增至堆疊層，來限制預設安全群組的連接埠存取設定。對於多個安全群組，Amazon EC2 會使用最寬鬆的設定。此外，您無法透過修改內建安全群組組態，來建立更嚴格的設定。當您建立堆疊時， OpsWorks Stacks 會使用標準設定覆寫內建安全群組的組態，因此您所做的任何變更都會在您下次建立堆疊時遺失。如果 layer 需要比內建安全群組更嚴格的安全群組設定，請將 **Use OpsWorks security groups (使用 OpsWorks 安全群組)** 設為 **No (否)**，並使用您偏好的設定建立自訂安全群組，然後在建立時將其指派給 layer。 + 如果您不小心刪除 Stacks OpsWorks 安全群組，並想要重新建立該群組，它必須完全複製原始群組，包括群組名稱的大寫。與其手動重新建立群組，建議您讓 OpsWorks Stacks 為您執行這項任務。只要在相同的 AWS 區域和 VPC 中建立新的堆疊，如果有的話， Stacks OpsWorks 就會自動重新建立所有內建安全群組，包括您刪除的安全群組。您接著可以刪除您不再需要使用的堆疊，安全群組仍會留下。 # 在 VPC 中執行堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以在 virtual private cloud (VPC) 中建立堆疊的執行個體，以控制使用者對其的存取權。例如，您可能不想讓使用者直接存取您堆疊的應用程式伺服器或資料庫，而要求所有公有流量都經由 Elastic Load Balancer 導引。在 VPC 中執行堆疊的基本步驟如下： 1. 使用 Amazon VPC 主控台或 API 或 CloudFormation 範本建立適當設定的 VPC。 1. 在建立堆疊時指定 VPC ID。 1. 在適當子網路中，啟動堆疊的執行個體。下列簡要說明 VPC 在 OpsWorks Stacks 中的運作方式。 **重要** 如果您使用 VPC 端點功能，請注意堆疊中的每個執行個體都必須能夠從 Amazon Simple Storage Service (Amazon S3) 完成下列動作：安裝執行個體代理程式。安裝 Ruby 這類資產。上傳 Chef 執行日誌。擷取堆疊命令。若要啟用這些動作，您必須確保堆疊的執行個體可以存取下列符合堆疊區域的儲存貯體。否則，上述動作將會失敗。對於 Chef 12 Linux 和 Chef 12.2 Windows，儲存貯體如下所示。 | 代理程式儲存貯體 | 資產儲存貯體 | 日誌儲存貯體 | DNA 儲存貯體 | | --- | --- | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | 若是 Linux 的 Chef 11.10 和更早版本，儲存貯體如下所示。美國東部（維吉尼亞北部）區域以外的區域端點不支援 Chef 11.4 堆疊。 | 代理程式儲存貯體 | 資產儲存貯體 | 日誌儲存貯體 | DNA 儲存貯體 | | --- | --- | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workingstacks-vpc.html) | 如需詳細資訊，請參閱 [VPC 端點](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-endpoints.html)。 **注意** 若要讓 OpsWorks Stacks 連線到您啟用的 VPC 端點，您也必須設定 NAT 或公有 IP 的路由，因為 OpsWorks Stacks 代理程式仍然需要存取公有端點。 **Topics** + [VPC 基本概念](#workingstacks-vpc-basics) + [為 OpsWorks Stacks Stack 建立 VPC](#workingstacks-vpc-create-vps) ## VPC 基本概念如需 VPC 的詳細討論，請參閱 [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html)。簡短來說，VPC 包含一或多個「子網路」**，而其中每個都包含一或多個執行個體。每個子網路都有一個相關聯的路由表，以根據其目標 IP 地址指示傳出流量。 + VPC 中的執行個體預設為可互相通訊，而不管它們的子網路為何。不過，變更網路存取控制清單 (ACL)、安全群組政策，或使用靜態 IP 地址的話，可能會切斷此通訊。 + 如果子網路的執行個體可以與網際網路通訊，則這種子網路稱為「公有子網路」**。 + 如果子網路的執行個體只能與 VPC 中的其他執行個體通訊，而無法直接與網際網路通訊，則這種子網路稱為「私有子網路」**。 OpsWorks Stacks 需要設定 VPC，以便堆疊中的每個執行個體都能存取下列端點，包括私有子網路中的執行個體： + 列於「區域支援」一節的其中一個 OpsWorks Stacks 服務端點[Stacks OpsWorks 入門](gettingstarted_intro.md)。 + 下列其中一個執行個體服務端點，由 Stacks OpsWorks 代理程式使用。受管的客戶執行個體上執行的代理程式會與服務交換資料。 + opsworks-instance-service.us-east-2.amazonaws.com + opsworks-instance-service.us-east-1.amazonaws.com + opsworks-instance-service.us-west-1.amazonaws.com + opsworks-instance-service.us-west-2.amazonaws.com + opsworks-instance-service.ap-south-1.amazonaws.com + opsworks-instance-service.ap-northeast-1.amazonaws.com + opsworks-instance-service.ap-northeast-2.amazonaws.com + opsworks-instance-service.ap-southeast-1.amazonaws.com + opsworks-instance-service.ap-southeast-2.amazonaws.com + opsworks-instance-service.ca-central-1.amazonaws.com + opsworks-instance-service.eu-central-1.amazonaws.com + opsworks-instance-service.eu-west-1.amazonaws.com + opsworks-instance-service.eu-west-2.amazonaws.com + opsworks-instance-service.eu-west-3.amazonaws.com + Amazon S3 + 作業系統仰賴的任何套件儲存庫，例如 Amazon Linux 或 Ubuntu Linux 儲存庫。 + 您的應用程式和自訂技術指南儲存庫。有多種方法可以將 VPC 設定為提供此連線能力。以下是如何為 Stacks 應用程式伺服器堆疊設定 VPC OpsWorks 的簡單範例。 ![\[VPC diagram showing public and private subnets, NAT, load balancing, and connections to external services.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/vpc.png) 此 VPC 有多個元件： **子網路** VPC 有兩個子網路：一個公有子網路和一個私有子網路。 + 公有子網路包含一個負載平衡器和網路地址轉譯 (NAT) 裝置，其可與外部地址和私有子網路中的執行個體通訊。 + 私有子網路包含應用程式伺服器，其可與公有子網路中的 NAT 和負載平衡器通訊，但無法直接與外部地址通訊。 **網際網路閘道** 網際網路閘道允許含公有 IP 地址的執行個體 (例如負載平衡器) 與 VPC 外部地址通訊。 **負載平衡器** Elastic Load Balancing 負載平衡器會接收來自使用者的傳入流量，將它分發至私有子網路中的應用程式伺服器，並將回應傳回給使用者。 **NAT** (NAT) 裝置提供的應用程式伺服器只能對網際網路進行有限的存取；通常是用來從外部儲存庫下載軟體更新。所有 OpsWorks Stacks 執行個體都必須能夠與 OpsWorks Stacks 和適當的 Linux 儲存庫進行通訊。其中一種處理此問題的方法是，將含相關聯彈性 IP 地址的 NAT 裝置放在公有子網路中。然後，您就可以將來自私有子網路執行個體的傳出流量透過 NAT 進行路由。單一 NAT 執行個體會在私有子網路的傳出流量中建立單一故障點。您可以使用一對 NAT 執行個體來設定 VPC，以在其中一個執行個體發生故障時由另一個接替，藉此提升可靠性。如需詳細資訊，請參閱 [Amazon VPC NAT 執行個體的高可用性](https://aws.amazon.com/articles/6079781443936876)。您也可以使用 NAT 閘道。如需詳細資訊，請參閱《[Amazon VPC 使用者指南](https://docs.aws.amazon.com/vpc/latest/userguide/)》中的 [NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html)。最佳 VPC 組態取決於您的 Stacks OpsWorks 堆疊。下列的一些範例說明您可能會使用特定 VPC 組態的時機。如需其他 VPC 案例的範例，請參閱 [Amazon VPC 使用情境](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenarios.html)。 **使用公有子網路中的一個執行個體** 如果您有沒有相關聯私有資源的單一執行個體堆疊，例如不應公開存取的 Amazon RDS 執行個體，您可以建立一個具有一個公有子網路的 VPC，並將執行個體放在該子網路中。如果您不是使用預設 VPC，則必須讓執行個體 layer 指派彈性 IP 地址給該執行個體。如需詳細資訊，請參閱[OpsWorks Layer 基本概念](workinglayers-basics.md)。 **使用私有資源** 如果您的資源不應公開存取，您可以建立一個 VPC，其中含有一個公有子網路和一個私有子網路。例如，在負載平衡的自動擴展環境中，您可以將所有 Amazon EC2 執行個體放在私有子網路中，並將負載平衡器放在公有子網路中。如此一來，就無法直接從網際網路存取 Amazon EC2 執行個體；所有傳入流量都必須透過負載平衡器路由。私有子網路會將執行個體與 Amazon EC2 直接使用者存取隔離，但仍必須將傳出請求傳送至 AWS 和適當的 Linux 套件儲存庫。若要允許這類請求，您可以使用自帶彈性 IP 地址的網路地址轉譯 (NAT) 裝置，然後透過 NAT 路由該執行個體的傳出流量。您可以將 NAT 放在負載平衡器的相同公有子網路中，如上述範例所示。 + 如果您使用的是後端資料庫，例如 Amazon RDS 執行個體，您可以將這些執行個體放在私有子網路中。對於 Amazon RDS 執行個體，您必須在不同的可用區域中指定至少兩個不同的子網路。 + 如果您需要直接存取私有子網路中的執行個體，例如，您想要使用 SSH 登入執行個體，您可以將堡壘主機放在代理網際網路請求的公有子網路中。 **將自己的網路擴展至 AWS** 若您想要將自己的網路擴展至雲端，並直接從 VPC 存取網際網路，您可以建立 VPN 閘道。如需詳細資訊，請參閱[案例 3：具有公有子網路和私有子網路以及硬體 VPN 存取的 VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario3.html)。 ## 為 OpsWorks Stacks Stack 建立 VPC 本節說明如何使用範例 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 範本建立 OpsWorks Stacks 堆疊的 VPC。您可以在 [OpsWorksVPCtemplates.zip 檔案](samples/OpsWorksVPCtemplates.zip)中下載範本。如需如何手動建立一個本主題所述 VPC 的詳細資訊，請參閱[案例 2：具有公有子網路和私有子網路的 VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html)。如需如何設定路由表、安全群組等，請參閱範本範例。 **注意** 根據預設， OpsWorks Stacks 會透過串連其 CIDR 範圍和可用區域來顯示子網路名稱，例如 `10.0.0.1/24 - us-east-1b`。若要讓名稱更易讀，請為每個子網路建立標籤，並將**金鑰**設為 **Name**，並將**值**設為子網路名稱。然後， OpsWorks Stacks 會將子網路名稱附加到預設名稱。例如，下列範例中的私有子網路，其標籤的 **Name (名稱)** 設定為 **Private**，因此 OpsWorks 會顯示為 `10.0.0.1/24 us-east - 1b - Private`。您可以使用 CloudFormation 主控台啟動 VPC 範本，只需幾個步驟。下列程序使用範例範本在美國東部（維吉尼亞北部）區域建立 VPC。如需如何使用範本在其他區域中建立 VPC 的指示說明，請參閱程序之後的[備註](#vpc-note)。 **若要建立 VPC** 1. 開啟 [CloudFormation 主控台](https://console.aws.amazon.com/cloudformation/)，選取 **US East (N. Virginia) (美國東部 (維吉尼亞北部))** 區域，然後選擇 **Create Stack (建立堆疊)**。 1. 在 **Select Template (選取範本)** 頁面上，選取 **Upload a template (上傳範本)**。瀏覽您在 OpsWorksVPCtemplates.zip `OpsWorksinVPC.template` 檔案中下載的檔案。選擇**繼續**。 [OpsWorksVPCtemplates.zip ](samples/OpsWorksVPCtemplates.zip) ![\[CloudFormation Select Template (選取範本) 頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/vpc_create_vpc.png) 您也可以開啟 [AWS CloudFormation 範本](https://aws.amazon.com/cloudformation/aws-cloudformation-templates/)、尋找 OpsWorks Stacks VPC 範本，然後選擇**啟動堆疊來啟動此堆疊**。 1. 接受 **Specify Parameters (指定參數)** 頁面中的預設值，然後選擇 **Continue (繼續)**。 1. 在 **Add Tags (新增標籤)** 頁面中，將 **Key (索引鍵)** 設定為 **Name**，將 **Value (值)** 設定為 VPC 名稱，以建立標籤。此標籤可讓您在建立 Stacks OpsWorks 堆疊時更輕鬆地識別 VPC。 1. 選擇 **Continue (繼續)**，然後選擇 **Close (關閉)** 以啟動堆疊。 **備註：**您可以使用下列任一種方法，在其他區域中建立 VPC。 + 移至[在不同區域中使用範本](https://aws.amazon.com/cloudformation/aws-cloudformation-templates/#regions)，選擇適當的區域，找到 OpsWorks Stacks VPC 範本，然後選擇**啟動堆疊**。 + 將範本檔案複製到您的系統中，並在 [CloudFormation 主控台](https://console.aws.amazon.com/cloudformation/)中選取適當的區域，然後使用 **Create Stack (建立堆疊)** 精靈的 **Upload a template to Amazon S3 (上傳範本到 Amazon S3)** 選項，從您的系統上傳範本。此範例範本包含輸出，可提供建立 Stacks OpsWorks 堆疊所需的 VPC、子網路和負載平衡器 IDs。您可以選擇 CloudFormation 主控台視窗底部的**輸出**索引標籤來查看它們。 ![\[Stack outputs table showing VPC, subnet, and load balancer IDs for OpsWorks-in-VPC stack.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/vpc_cfn_outputs.png) # 更新堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。建立好堆疊之後，您即可隨時更新組態。在 **Stack (堆疊)** 頁面中，按一下 **Stack Settings (堆疊設定)**，然後按一下 **Edit (編輯)**，以顯示 **Settings (設定)** 頁面。視需要進行變更，然後按一下 **Save (儲存)**。這些設定與[建立新的堆疊](workingstacks-creating.md)所述的設定相同。如需詳細資訊，請參閱該主題。但是，請注意以下內容： + 您不能修改區域或 VPC ID。 + 如果您的堆疊是在 VPC 中執行，則設定含有 **Default subnet (預設子網路)** 設定，其會列出 VPC 的子網路。如果您的堆疊不是在 VPC 中執行，則設定會標記為 **Default Availability Zones (預設可用區域)**，並列出區域的可用區域。 + 您可以變更預設的作業系統，但您不能為 Windows 堆疊指定 Linux 作業系統，或為 Linux 堆疊指定 Windows 作業系統。 + 如果您變更任何預設的執行個體設定，例如 **Hostname theme (主機名稱主題)** 或 **Default SSH key (預設 SSH 金鑰)**，則新值只會套用至您建立的任何新執行個體，而不會套用至現有的執行個體。 + 變更**名稱**會變更主控台顯示的名稱；不會變更 OpsWorks Stacks 用來識別堆疊的基礎簡短名稱。 + 在您將 **Use OpsWorks security groups (使用 OpsWorks 安全群組)** 從 **Yes (是)** 變更為 **No (否)** 之前，每個 layer 除了 layer 的內建安全群組之外，還必須至少有一個安全群組。如需詳細資訊，請參閱[編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md)。 OpsWorks Stacks 接著會從每一層刪除內建的安全群組。 + 如果您將 **Use OpsWorks 安全群組**從**否**變更為**是**， OpsWorks Stacks 會將適當的內建安全群組新增至每個 layer，但不會刪除現有的安全群組。 # 複製堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。建立堆疊的多個副本，有時會很有幫助。例如，建議您將冗餘新增為災難復原或預防措施，或者可以使用現有堆疊做為新堆疊的起點。最簡單的方法是複製來源堆疊。在 OpsWorks Stacks 儀表板上，在您要複製之堆疊列**的動作**欄中，選擇**複製**，這會開啟**複製堆疊**頁面。 ![\[OpsWorks Dashboard showing stacks with regions, layers, instances, and action options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/clone_stack_action.png) 複製堆疊的設定與來源堆疊相同，差別在「複製」這個字附加到堆疊名稱。如需這些設定的資訊，請參閱 [建立新的堆疊](workingstacks-creating.md)。還有兩個額外的選用設定： **許可** 如果 **all permissions (所有許可)** 已選取 (預設)，則來源堆疊許可會套用至複製堆疊。 **應用程式** 列出部署在來源堆疊上的應用程式。針對每個列出的應用程式，如果選取對應的核取方塊 (預設)，則會將應用程式部署到複製堆疊。 **注意** 您無法將堆疊從一個區域端點複製到另一個區域端點；例如，您無法將堆疊從美國西部（奧勒岡）區域 (us-west-2) 複製到亞太區域（孟買）區域 (ap-south-1)。當您完成設定時，請選擇**複製堆疊**。 OpsWorks 堆疊會建立新的堆疊，其中包含來源堆疊的層，以及選擇性的應用程式和許可。這些 layer 與原始 layer 具有相同的組態，但您可以進行任何修改。不過，複製不會建立任何執行個體。您必須為複製堆疊的每個 layer 新增一組適當執行個體，然後將其啟動。如同使用任何堆疊，您可以在複製堆疊上執行一般管理任務，例如新增、刪除或修改 layer，或新增和部署應用程式。若要讓複製的堆疊運作，請啟動執行個體。 OpsWorks 堆疊會根據其層成員資格來設定每個執行個體。也會部署任何應用程式，如同使用新堆疊一樣。 # 執行 OpsWorks Stacks Stack 命令 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 提供一組*堆疊命令*，您可以用來在堆疊的執行個體上執行各種操作。若要執行堆疊命令，請按一下**堆疊**頁面上的**執行命令**。您接著可選擇適當的命令，指定任何選項，然後按下位於右下方的按鈕 (會標上命令的名稱)。 **注意** OpsWorks Stacks 也支援一組*部署命令*，您可用來管理應用程式部署。如需詳細資訊，請參閱[部署應用程式](workingapps-deploying.md)。您可以在任何堆疊上執行下列堆疊命令。 **Update Custom Cookbooks (更新自訂技術指南)** 使用目前儲存庫的版本更新執行個體的自訂技術指南。此命令不會執行任何配方。若要執行更新後的配方，您可以使用 `Execute Recipes`、`Setup`，或 `Configure` 堆疊命令，或[重新部署您的應用程式](workingapps-deploying.md)來執行部署配方。如需自訂技術指南的詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。 **Execute Recipes (執行配方)** 在執行個體上執行指定的一組配方。如需詳細資訊，請參閱[手動執行配方](workingcookbook-manual.md)。 **設定** 執行執行個體的安裝配方。 **設定** 執行執行個體的設定配方。 **注意** 若要使用 **Setup (安裝)** 或 **Configure (設定)** 來在執行個體上執行配方，配方必須指派給執行個體 layer 的對應生命週期事件。如需詳細資訊，請參閱[執行配方](workingcookbook-executing.md)。您僅能在 Linux 式堆疊上執行下列堆疊命令。 **安裝相依性** 安裝執行個體套件。從 Chef 12 開始，此命令無法使用。 **Update Dependencies (更新依存項目)** （僅限 Linux。從 Chef 12 開始，此命令無法使用。) 安裝一般作業系統更新及套件更新。詳細資訊取決於執行個體的作業系統。如需詳細資訊，請參閱[管理安全性更新](workingsecurity-updates.md)。使用 **Upgrade Operating System (升級作業系統)** 命令，將執行個體升級至新的 Amazon Linux 版本。 **Upgrade Operating System (升級作業系統)** (僅限 Linux) 將執行個體的 Amazon Linux 作業系統升級至最新版本。如需詳細資訊，請參閱[OpsWorks Stacks 作業系統](workinginstances-os.md)。在執行 **Upgrade Operating System (升級作業系統)** 之後，我們建議您也執行 **Setup (安裝)**。這可確保服務正確重新啟動。堆疊命令具有下列選項，其中有些選項只會在特定命令內出現。 **Comment** (選擇性) 輸入任何您欲新增的自訂備註。 **Recipes to execute (要執行的配方)** (必要項目) 此設定只會在您選取 **Execute Recipes (執行配方)** 命令時才會出現。使用標準 *cookbook\$1name*::*recipe\$1name* 格式，輸入要執行的配方，並以逗點分隔。如果您指定多個配方， OpsWorks Stacks 會依列出的順序執行它們。 **Allow reboot (允許重新開機)** (選擇性) 此設定只會在您選取 **Upgrade Operating System (升級作業系統)** 命令時才會出現。預設值為**是**，這會指示 OpsWorks Stacks 在安裝升級之後重新啟動執行個體。 **Custom Chef JSON (自訂 Chef JSON)** (選擇性) 選擇 **Advanced (進階)** 以顯示此選項，允許您指定要併入[堆疊組態及部署屬性](workingcookbook-json.md)的自訂 JSON 屬性。 **執行個體** (選擇性) 指定要執行命令的執行個體。根據預設，會選取所有線上執行個體。若要在一部分的執行個體上執行命令，請選取適當的 layer 或執行個體。 **注意** 您可能會看到您並未執行的 execute\$1recipes 執行在 **Deployment (部署)** 和 **Commands (命令)** 頁面上列出。這通常是許可變更的結果，例如授予或移除使用者的 SSH 許可。當您進行這類變更時， OpsWorks Stacks 會使用 execute\$1recipes 來更新執行個體的許可。 # 使用自訂 JSON **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。數個 OpsWorks Stacks 動作可讓您指定自訂 JSON，而 OpsWorks Stacks 會安裝在執行個體上，並且可供配方使用。您可以在下列情況中指定自訂的 JSON： + 當您建立、更新或複製堆疊時。 AWS OpsWorks Stacks 會在所有執行個體上安裝所有後續[生命週期事件](workingcookbook-events.md)的自訂 JSON。 + 當您執行部署或堆疊命令時。 AWS OpsWorks Stacks 只會針對該事件將自訂 JSON 傳遞給執行個體。自訂 JSON 必須以有效的 JSON 物件表示，且格式化為有效的 JSON 物件。例如： ``` { "att1": "value1", "att2": "value2" ... } ``` OpsWorks Stacks 會將自訂 JSON 存放在下列位置： Linux 執行個體為： + `/var/chef/runs/run-ID/attribs.json` + `/var/chef/runs/run-ID/nodes/hostname.json` Windows 執行個體為： + `drive:\chef\runs\run-ID\attribs.json` + `drive:\chef\runs\run-ID\nodes\hostname.json` **注意** 適用於 Linux 的 Chef 11.10 和舊版中，自訂 JSON 位於 Linux 執行個體的下列路徑，Windows 執行個體不可用，而且沒有 `attribs.json` 檔案。日誌存放在和 JSON 相同的資料夾或目錄中。如需適用於 Linux 之 Chef 11.10 和舊版中自訂 JSON 的詳細資訊，請參閱[使用自訂的 JSON 覆寫屬性](https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-json-override.html)和 [Chef 日誌檔](https://docs.aws.amazon.com/opsworks/latest/userguide/troubleshoot-debug-log.html#troubleshoot-debug-log-instance)。 `/var/lib/aws/opsworks/chef/hostname.json` 在上述的路徑中，*run-ID* 是 OpsWorks Stacks 指派給在執行個體上執行之每個 Chef 的唯一 ID，而 *hostname* 則是執行個體的主機名稱。若要從 Chef 配方存取自訂的 JSON，請使用標準的 Chef `node` 語法。例如，假設您想要為要部署的應用程式定義簡單的設定；例如，是否一開始即顯示應用程式，以及應用程式的初始前景和背景顏色。假設您使用 JSON 物件定義這些應用程式設定，如下所示： ``` { "state": "visible", "colors": { "foreground": "light-blue", "background": "dark-gray" } } ``` 為堆疊宣告自訂的 JSON： 1. 在堆疊頁面中，選擇 **Stack Settings (堆疊設定)**，然後選擇 **Edit (編輯)**。 1. 針對 **Custom Chef JSON (自訂 Chef JSON)**，輸入 JSON 物件，然後選擇 **Save (儲存)**。 **注意** 您可以在部署、layer 和堆疊層級宣告自訂 JSON。如果您只想向個別的部署或 layer 顯示一些自訂的 JSON，建議您執行此作業。或者，例如，您可能希望使用在 layer 層級宣告的自訂 JSON 暫時覆寫在堆疊層級宣告的自訂 JSON。如果您在多個層級宣告自訂 JSON，則在部署層級宣告的自訂 JSON，會覆寫在 layer 和堆疊層級宣告的任何自訂 JSON。在 layer 層級宣告的自訂 JSON，將會覆寫僅在堆疊層級宣告的任何自訂 JSON。若要使用 OpsWorks Stacks 主控台指定部署的自訂 JSON，請在**部署應用程式**頁面上選擇**進階**。在 **Custom Chef JSON (自訂 Chef JSON)** 方塊中輸入自訂的 JSON，然後選擇 **Save (儲存)**。若要使用 OpsWorks Stacks 主控台指定 layer 的自訂 JSON，請在 **Layers** 頁面上，選擇所需 layer **的設定**。在 **Custom JSON (自訂 JSON)** 方塊中輸入自訂的 JSON，然後選擇 **Save (儲存)**。如需詳細資訊，請參閱[編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md)及[部署應用程式](workingapps-deploying.md)。當您執行部署或堆疊命令時，配方會使用標準的 Chef `node` 語法擷取這些自訂值，直接將它們映射在自訂 JSON 物件的階層。例如，下列配方程式碼會將有關先前自訂 JSON 值的訊息寫入 Chef 日誌： ``` Chef::Log.info("********** The app's initial state is '#{node['state']}' **********") Chef::Log.info("********** The app's initial foreground color is '#{node['colors']['foreground']}' **********") Chef::Log.info("********** The app's initial background color is '#{node['colors']['background']}' **********") ``` 此方法有助於將資料傳遞至配方。 OpsWorks Stacks 會將該資料新增至執行個體，而配方可以使用標準 Chef `node` 語法擷取資料。 **注意** 自訂 JSON 的大小限制為 120 KB。如果您需要更多容量，建議您將部分資料儲存在 Amazon Simple Storage Service (Amazon S3) 上。然後，您的自訂配方可以使用 [AWS CLI](https://aws.amazon.com/documentation/cli/) 或 [適用於 Ruby 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)，將資料從 Amazon S3 儲存貯體下載到您的執行個體。 # 刪除堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以刪除不再需要的堆疊。只能刪除空的堆疊，您必須先刪除堆疊中所有執行個體、應用程式和 Layer。 **刪除堆疊** 1. 在 OpsWorks Stacks 儀表板上，選擇您要關閉和刪除的堆疊。 1. 在導覽窗格中，選擇**執行個體**。 1. 在 **Instances (執行個體)** 頁面上，選擇 **Stop all Instances (停止所有執行個體)**。 ![\[Instances section showing 1 total instance online, with "Stop All Instances" button highlighted.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/stop_all_instances.png) 1. 執行個體停止後，針對 layer 中的每個執行個體，在**動作**欄中選擇**刪除**。出現確認提示時，請選擇 **Yes, Delete (是，刪除)**。 ![\[Confirmation dialog for deleting a stopped database instance, warning of data loss.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/delete_instance.png) 1. 刪除所有執行個體後，在導覽窗格中，選擇 **Layers (Layer)**。 1. 在 **Layers (Layer)** 頁面上，為堆疊中的每個 layer，選擇 **delete (刪除)**。在 (刪除堆疊) 確認提示上，選擇 **Yes, Delete** (是的，請刪除)。 ![\[PHP App Server layer settings with options for Recipes, Network, EBS Volumes, and Security.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/delete_layer.png) 1. 刪除所有 layer 後，在導覽窗格中，選擇 **Apps (應用程式)**。 1. 在**應用程式**頁面上，針對堆疊中的每個應用程式，選擇**動作**欄中的**刪除**。在 (刪除堆疊) 確認提示上，選擇 **Yes, Delete** (是的，請刪除)。 ![\[Apps page showing delete confirmation prompt for SimplePhp app with options to cancel or confirm.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/delete_app.png) 1. 刪除所有應用程式後，在導覽窗格中，選擇 **Stack (堆疊)**。 1. 在 stack (堆疊) 頁面上，選擇 **Delete stack (刪除堆疊)**。在 (刪除堆疊) 確認提示上，選擇 **Yes, Delete** (是的，請刪除)。 ![\[Delete stack option circled in red on the ShortStack interface.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/delete_stack.png) ## 刪除堆疊使用的其他 AWS 資源您可以使用其他 AWS 資源搭配 OpsWorks Stacks 來建立和管理堆疊。當您刪除堆疊時，如果另一個堆疊未使用堆疊，且 Stacks OpsWorks 以外的資源未使用堆疊，請考慮也刪除使用堆疊的資源。以下是清理與堆疊搭配使用之外部 AWS 資源的建議原因。 + 外部 AWS 資源可以繼續在您的 AWS 帳戶中產生費用。 + Amazon S3 儲存貯體等資源可能包含個人識別、敏感或機密資訊。 **重要** 請勿刪除其他的堆疊正在使用的資源。請注意，IAM 角色和安全群組是全域的，因此其他區域中的堆疊可能會使用這些相同的資源。以下是堆疊使用的其他 AWS 資源，以及有關如何刪除這些資源的資訊連結。服務角色和執行個體描述檔當您建立堆疊時，您可以指定 IAM 角色和執行個體描述檔，讓 OpsWorks Stacks 代表您建立允許的資源。 OpsWorks 如果您未選擇現有的角色和執行個體描述檔，會為您建立角色和執行個體描述檔。為您 OpsWorks 建立的角色和執行個體描述檔`aws-opsworks-ec2-role`分別名為 `aws-opsworks-service-role`和。如果您帳戶中沒有其他堆疊正在使用 IAM 角色和執行個體描述檔，則可以安全地刪除這些資源。如需有關如何刪除 IAM 角色和執行個體描述檔的資訊，請參閱《*IAM 使用者指南*》中的[刪除角色或執行個體描述](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)檔。 Security groups (安全群組) 在 OpsWorks Stacks 中，您可以在 layer 層級指定使用者定義的安全群組。您可以使用 Amazon EC2 主控台或 API 建立安全群組。堆疊和 layer 可以在其他區域中使用相同的安全群組，因為安全群組是全域通用。如果其他 AWS 資源未使用安全群組，您可以將其刪除。如需如何刪除安全群組的詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[刪除安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#deleting-security-group)。 Amazon EBS 磁碟區在 OpsWorks Stacks 中，您可以在 layer 層級新增 EBS 磁碟區，並將它們連接到 layer 中的執行個體。您可以使用 Amazon EC2 服務主控台或 API 建立 EBS 磁碟區，然後將它們連接到 layer 層級的 OpsWorks Stacks 執行個體。EBS 磁碟區專屬的[可用區域](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_delete.html)。如果您不再使用特定區域和可用區域中堆疊裡的 EBS 磁碟區，您可以刪除。如需如何刪除 Amazon EBS 磁碟區的詳細資訊，請參閱《Amazon *Amazon EC2*[刪除 Amazon EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-deleting-volume.html)。 Amazon Simple Storage Service (Amazon S3) 儲存貯體在 OpsWorks Stacks 中，您可以針對下列項目使用 Amazon S3 儲存貯體。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 + 儲存應用程式程式碼 + 儲存技術指南和配方 + 如果您已在 CloudTrail Stacks 中啟用 CloudTrail 記錄，CloudTrail OpsWorks 日誌 + 如果您已在 Stacks 中啟用 Amazon CloudWatch Logs OpsWorks 串流彈性 IP 位址如果您已向 Stacks OpsWorks [註冊](https://docs.aws.amazon.com/opsworks/latest/userguide/resources-reg.html)[彈性 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)，且不再需要彈性 IP 地址，則可以[釋出彈性 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#using-instance-addressing-eips-releasing)。 Elastic Load Balancing 負載平衡器如果您不再需要與堆疊中的層搭配使用的 Elastic Load Balancing 傳統負載平衡器，則可以將其刪除。如需詳細資訊，請參閱[ Classic Load Balancers 使用者指南](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-getting-started.html#delete-load-balancer)中的「*刪除您的負載平衡器*」。 Amazon Relational Database Service (Amazon RDS) 執行個體如果您已向 Stacks [註冊](https://docs.aws.amazon.com/opsworks/latest/userguide/resources-reg.html) Amazon RDS 資料庫 OpsWorks (DB) 執行個體，且不再需要這些執行個體，則可以刪除資料庫執行個體。如需如何刪除資料庫執行個體的詳細資訊，請參閱《*Amazon RDS 使用者指南*》中的[刪除資料庫執行個體](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html)。 Amazon Elastic Container Service (Amazon ECS) 叢集如果您的堆疊包含 ECS 叢集層，而且您不再使用以 layer 註冊的 ECS 叢集，您可以刪除 ECS 叢集。如需如何刪除 ECS 叢集的詳細資訊，請參閱《*Amazon ECS 開發人員指南*》中的[刪除叢集](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete_cluster.html)。 # 層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。每個堆疊各包含一或多個層，每個 layer 各代表一個堆疊元件，例如負載平衡器或一組應用程式伺服器。當您使用 OpsWorks Stacks layer 時，請記住下列事項： + 堆疊中的每個 layer 必須至少具有一個執行個體，並可選擇性具有多個執行個體。 + 堆疊中的每個執行個體必須至少是一個 layer 的成員，但[已註冊的執行個體](registered-instances.md)除外。除了部分基本設定 (例如 SSH 金鑰和主機名稱) 以外，您無法直接設定執行個體。您必須建立和設定適當的 layer，並將執行個體新增至該 layer。 Amazon EC2 執行個體可以選擇性地成為多層的成員。在這種情況下， OpsWorks Stacks 會執行配方，為每個執行個體的 layer 安裝和設定套件、部署應用程式等。透過將執行個體指派至多個 layer，您可以執行諸如以下動作： + 透過在單一執行個體上託管資料庫伺服器和負載平衡器來降低費用。 + 使用其中一個應用程式伺服器進行管理。建立自訂管理 layer，並將其中一個應用程式伺服器執行個體新增至 layer。管理 layer 的配方會設定該應用程式伺服器執行個體來執行管理任務，並安裝任何其他必要軟體。其他應用程式伺服器執行個體則僅是應用程式伺服器。本節說明如何使用 layer。 **Topics** + [OpsWorks Layer 基本概念](workinglayers-basics.md) + [Elastic Load Balancing Layer](layers-elb.md) + [Amazon RDS 服務層](workinglayers-db-rds.md) + [ECS 叢集層](workinglayers-ecscluster.md) + [自訂 OpsWorks Stacks Layers](workinglayers-custom.md) + [個別 layer 作業系統套件安裝](per-layer-os-package-install.md) # OpsWorks Layer 基本概念 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節說明如何執行所有 Stacks OpsWorks layer 通用的操作。 **Topics** + [建立 OpsWorks Layer](workinglayers-basics-create.md) + [編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md) + [使用自動修復來替換故障的執行個體](workinginstances-autohealing.md) + [刪除 OpsWorks Layer](workinglayers-basics-delete.md) # 建立 OpsWorks Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當您建立新的堆疊，您會看到以下頁面： ![\[AnotherStack interface showing an empty stack with a prompt to add the first layer.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/new_stack_page_layers.png) **新增第一個 OpsWorks layer** 1. 按一下 **Add a Layer (新增 Layer)**。 1. 在 **Add Layer (新增 Layer)** 頁面上，選取會顯示 layer 組態選項的適當 layer。 1. 適當設定該 layer，然後按一下 **Add Layer (新增 Layer)** 以新增到堆疊。下列各節說明如何設定各種 layer。 **注意** **Add Layer (新增 Layer)** 頁面只會顯示每個 layer 較常用的組態設定。您可以透過[編輯 layer](workinglayers-basics-edit.md) 來指定額外的設定。 1. 將執行個體新增至 layer 並啟動。 **注意** 如果執行個體是多個 layer 的成員，您必須先將其新增到所屬的所有 layer，才能啟動該執行個體。您不能將線上執行個體新增到 layer。若要新增更多 layer，請開啟 **Layers (Layer)** 頁面，然後按一下 **\$1Layer** 以開啟 **Add Layer (新增 Layer)** 頁面。當您啟動執行個體時， OpsWorks Stacks 會自動為每個執行個體的 layer 執行設定和部署配方，以安裝和設定適當的套件，並部署適當的應用程式。您可以透過各種方式[自訂 layer 的設定和組態程序](customizing.md)，例如將自訂配方指派給適當的生命週期事件。 OpsWorks Stacks 會在每個事件的標準配方之後執行自訂配方。如需詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。下列圖層特定章節說明如何處理各種 Stacks 圖層的步驟 2 OpsWorks 和 3。如需如何新增執行個體的詳細資訊，請參閱[將執行個體新增至 Layer](workinginstances-add.md)。 # 編輯 OpsWorks Layer 的組態 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在您建立 layer 後，某些屬性 (例如 AWS 區域) 是不可變的，但您可以變更大多數的 layer 設定。編輯 layer 也可以存取 **Add Layer (新增 Layer)** 頁面上不可用的組態設定。儲存新組態後，設定將立即生效。 **編輯 OpsWorks layer** 1. 在導覽窗格中，按一下 **Layers (Layer)**。 1. 在 **Layers (Layer)** 頁面上，選擇 layer 名稱以開啟詳細資訊頁面，會顯示目前的組態。 **注意** 選擇 layer 名稱下的其中一個名稱，會直接帶您到詳細資訊頁面上的相關聯標籤。 1. 按一下 **Edit (編輯)**，然後選取適當的標籤：**General Settings (一般設定)**、**Recipes (配方)**、**Network (網路)**、**EBS Volumes (EBS 磁碟區)** 或 **Security (安全性)**。下列各節說明可用於所有 layer 之各種標籤上的設定。某些 layer 具有額外 layer 特定的設定，這些設定會顯示在頁面頂端。此外，某些設定僅適用於 Linux 系統的堆疊，如上所述。 **Topics** + [一般設定](#workinglayers-basics-edit-general) + [配方](#workinglayers-basics-edit-recipes) + [網路](#workinglayers-basics-edit-network) + [EBS 磁碟區](#workinglayers-basics-edit-ebs) + [安全](#workinglayers-basics-edit-security) + [CloudWatch Logs](#w2ab1c14c53c21c11c23) + [Tags (標籤)](#w2ab1c14c53c21c11c25) ## 一般設定所有 layer 都具有以下設定： **已啟用自動修復** Layer 的執行個體是否已啟用[自動修復](workinginstances-autohealing.md)。預設設定為 **Yes (是)**。 **自訂 JSON** JSON 格式資料，傳遞給此 layer 中所有執行個體的 Chef 配方。例如，您可以使用此配方將資料傳遞至您自己的配方。如需詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。您可以在部署、layer 和堆疊層級宣告自訂 JSON。如果您希望在堆疊中顯示某些自訂 JSON 或僅在個別的部署中顯示，則建議您執行此作業。或者，例如，您可能希望使用在部署層級宣告的自訂 JSON，暫時覆寫在 layer 層級宣告的自訂 JSON。如果您在多個層級宣告自訂 JSON，則在部署層級宣告的自訂 JSON，會覆寫在 layer 和堆疊層級宣告的任何自訂 JSON。在 layer 層級宣告的自訂 JSON，將會覆寫僅在堆疊層級宣告的任何自訂 JSON。若要使用 OpsWorks Stacks 主控台指定部署的自訂 JSON，請在**部署應用程式**頁面上選擇**進階**。在 **Custom Chef JSON (自訂 Chef JSON)** 方塊中輸入自訂的 JSON，然後選擇 **Save (儲存)**。若要使用 OpsWorks Stacks 主控台指定堆疊的自訂 JSON，請在堆疊設定頁面上，在自訂 JSON 方塊中輸入**自訂 JSON**，然後選擇**儲存**。如需詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)及[部署應用程式](workingapps-deploying.md)。 **執行個體關機逾時** 指定觸發[關機生命週期事件](workingcookbook-events.md)後， OpsWorks Stacks 在停止或終止 Amazon EC2 執行個體前的等待時間（以秒為單位）。預設設定為 120 秒。設定的目的是在終止執行個體之前，為執行個體的關機配方提供足夠時間來完成其任務。如果您的自訂關機可能會需要更多時間，則請視情況修改設定。如需執行個體關機的詳細資訊，請參閱[停止執行個體](workinginstances-starting.md#workinginstances-starting-stop)。此標籤上其餘的設定會因 layer 類型而異，並與 layer 之 **Add Layer (新增 Layer)** 頁面上的設定相同。 ## 配方 **Recipes (配方)** 標籤包含下列設定。 **自訂 Chef 配方** 您可以將自訂 Chef 配方指派給 layer 的生命週期事件。如需詳細資訊，請參閱[執行配方](workingcookbook-executing.md)。 ## 網路 **Network (網路)** 標籤包含下列設定。 **Elastic Load Balancing** 您可以將 Elastic Load Balancing 負載平衡器連接至任何 layer。 OpsWorks Stacks 接著會自動向負載平衡器註冊 layer 的線上執行個體，並在它們離線時取消註冊。如果您已啟用負載平衡器的連線耗盡功能，您可以指定 Stacks OpsWorks 是否支援此功能。如需詳細資訊，請參閱[Elastic Load Balancing Layer](layers-elb.md)。 **自動指派 IP 地址** 您可以控制 OpsWorks Stacks 是否自動將公有或彈性 IP 地址指派給 layer 的執行個體。以下是當您啟用此選項時會發生的情況： + 對於執行個體後端執行個體， OpsWorks Stacks 會在每次執行個體啟動時自動指派地址。 + 對於 Amazon EBS 後端執行個體，當執行個體第一次啟動時， OpsWorks Stacks 會自動指派地址。 + 如果執行個體屬於多個 layer，且您已為至少一個 layer 啟用自動指派， OpsWorks 則Stacks 會自動指派地址。如果您啟用公有 IP 地址的自動指派，它僅適用於新的執行個體。 OpsWorks Stacks 無法更新現有執行個體的公有 IP 地址。如果您的堆疊在 VPC 中執行，則您可以對公有 IP 地址和彈性 IP 地址進行個別設定。下表說明這些互動方式： ![\[Table showing interactions between public IP addresses, Elastic IP addresses, and instance network configurations.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/ip-address.png) 執行個體必須能夠與 OpsWorks Stacks 服務、Linux 套件儲存庫和技術指南儲存庫進行通訊。如果未指定公有或彈性 IP 地址，則 VPC 必須包含允許 layer 的執行個體與外部網站通訊之元件 (如 NAT)。如需詳細資訊，請參閱[在 VPC 中執行堆疊](workingstacks-vpc.md)。如果您的堆疊不是在 VPC 中執行，則 **Elastic IP addresses (彈性 IP 地址)** 是您唯一的設定： + **Yes (是)**：執行個體在第一次啟動時會收到彈性 IP 地址，而如果無法指派彈性 IP 地址則會收到公有 IP 地址。 + **No (否)**：執行個體在每次啟動時都會收到公有 IP 地址。 ## EBS 磁碟區 **EBS Volumes (EBS 磁碟區)** 標籤包含下列設定。 EBS 最佳化執行個體是否應為 Amazon Elastic Block Store (Amazon EBS) 最佳化 layer 的執行個體。如需詳細資訊，請參閱 [Amazon EBS 最佳化執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html)。 **額外的 EBS 磁碟區** （僅限 Linux) 您可以將 [Amazon EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)新增至 layer 執行個體或從中移除它們。當您啟動執行個體時， OpsWorks Stacks 會自動建立磁碟區並將其連接至執行個體。您可以使用 **Resources (資源)** 頁面來管理堆疊的 EBS 磁碟區。如需詳細資訊，請參閱[資源管理](resources.md)。 + **掛載點** – （必要）指定要掛載 EBS 磁碟區的掛載點或目錄。 + **\$1 磁碟** – （選用）如果您指定 RAID 陣列，則為陣列中的磁碟數量。每個 RAID 層級都有預設的磁碟數目，但您可以從清單中選取更大的數目。 + **大小總計 (GiB)** – （必要）磁碟區的大小，以 GiB 為單位。對於 RAID 陣列，此設定會指定陣列的總大小，而不是每個磁碟的大小。下表說明每種磁碟區類型允許的磁碟區大小下限和上限。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/workinglayers-basics-edit.html) + **磁碟區類型** – （選用）指定要建立磁性、一般用途 SSD、輸送量最佳化 HDD、冷 HDD 或 PIOPS 磁碟區。預設值為 **Magnetic (磁帶)**。 + **加密 – **（選用）指定是否加密 EBS 磁碟區的內容。 + **每個磁碟的 IOPS** – （佈建 IOPS SSD 和一般用途 SSD 磁碟區需要）如果您指定佈建 IOPS SSD 或一般用途 SSD 磁碟區，您也必須指定**每個磁碟的 IOPS**。在建立磁碟區時，您可以指定佈建 IOPS 磁碟區的 IOPS 速率。已佈建的 IOPS 和所請求的磁碟區大小之比例最高為 30 (換言之，一個 3000 IOPS 的磁碟區必須至少有 100 GB)。一般用途 (SSD) 磁碟區類型的基準 IOPS 為磁碟區大小乘以 3，上限為 10000 IOPS，並可突發最高 3000 IOPS 達 30 分鐘。當您將磁碟區新增至 layer，或是從 layer 移除磁碟區時，請注意以下事項： + 如果您新增磁碟區，每個新執行個體都會取得新的磁碟區，但 OpsWorks Stacks 不會更新現有的執行個體。 + 如果您移除某個磁碟區，則僅會套用於新的執行個體；現有的執行個體會保留其磁碟區。 ### 指定掛載點您可以指定您喜歡的任何掛載點。不過，請注意，某些掛載點保留供 OpsWorks Stacks 或 Amazon EC2 使用，不應用於 Amazon EBS 磁碟區。請勿使用典型的 Linux 系統資料夾，例如 `/home` 或 `/etc`。下列掛載點保留供 Stacks OpsWorks 使用。 + `/srv/www` + `/var/log/apache2` (Ubuntu) + `/var/log/httpd` (Amazon Linux) + `/var/log/mysql` + `/var/www` 當執行個體啟動或重新啟動時，autofs (自動掛載協助程式) 會使用臨時裝置掛載點，例如 `/media/ephemeral0` 用於綁定掛載。此操作會在掛載 Amazon EBS 磁碟區之前進行。為了確保 Amazon EBS 磁碟區的掛載點不會與 autofs 衝突，請勿指定暫時性裝置掛載點。可能的暫時性裝置掛載點取決於特定的執行個體類型，以及它是執行個體後端還是 Amazon EBS 後端。為了避免與 autofs 衝突，請執行下列作業： + 驗證您希望使用之特定執行個體類型與備用存放區的臨時裝置掛載點。 + 請注意，如果您切換到 Amazon EBS 支援的執行個體，則適用於執行個體後端執行個體的掛載點可能會與 autofs 衝突，反之亦然。 **注意** 如果您想要變更執行個體存放區塊型設備映射，您可以建立自訂 AMI。如需詳細資訊，請參閱 [Amazon EC2 執行個體存放區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)。如需如何為 Stacks 建立自訂 AMI OpsWorks 的詳細資訊，請參閱 [使用自訂 AMI](workinginstances-custom-ami.md)。下列範例說明如何使用自訂配方來確保磁碟區的掛載點不與 autofs 衝突。您可以依照特定使用案例來調整。 **避免衝突的掛載點** 1. 將 Amazon EBS 磁碟區指派給所需的 layer，但使用掛載點，例如 `/mnt/workspace` 永遠不會與 autofs 衝突。 1. 實作下列自訂配方，該配方會在 Amazon EBS 磁碟區上建立應用程式目錄，並從連結至該目錄`/srv/www/`。如需如何實作和自訂配方的詳細資訊，請參閱 [技術指南和配方](workingcookbook.md) 和 [自訂 OpsWorks Stacks](customizing.md)。 ``` mount_point = node['ebs']['raids']['/dev/md0']['mount_point'] rescue nil if mount_point node[:deploy].each do |application, deploy| directory "#{mount_point}/#{application}" do owner deploy[:user] group deploy[:group] mode 0770 recursive true end link "/srv/www/#{application}" do to "#{mount_point}/#{application}" end end end ``` 1. 新增 `depends 'deploy'` 行到自訂技術指南的 `metadata.rb` 檔案。 1. [將此配方指派至 layer 的設定事件。](workingcookbook-executing.md) ## 安全 **Security (安全性)** 標籤包含下列設定。 **安全群組** Layer 必須至少具有一個相關聯的安全群組。您可以指定如何在[建立](workingstacks-creating.md)或[更新](workingstacks-edit.md)堆疊時關聯安全群組。 OpsWorks Stacks 提供一組標準內建安全群組。 + 預設選項是讓 OpsWorks Stacks 自動將適當的內建安全群組與每個 layer 建立關聯。 + 您也可以選擇不自動為內建安全群組建立關聯，而在建立 layer 時將自訂安全群組與每個 layer 建立關聯。如需安全群組的詳細資訊，請參閱 [使用安全群組](workingsecurity-groups.md)。建立 layer 後，您可以使用 **Security Groups (安全群組)** 來將更多安全群組新增至 layer，藉由從 **Custom security groups (自訂安全群組)** 清單中選取這些安全群組。將安全群組新增至 layer 之後， OpsWorks Stacks 會將其新增至所有新的執行個體。（請注意，重新啟動的執行個體存放區執行個體會變成新的執行個體，因此也會有新的安全群組。) OpsWorks Stacks 不會將安全群組新增至線上執行個體。您可以按一下 **x** 來刪除現有的安全群組，如下所示： + 如果您選擇讓 OpsWorks Stacks 自動關聯內建安全群組，您可以按一下 **x** 來刪除先前新增的自訂安全群組，但無法刪除內建群組。 + 如果您選擇不自動為內建安全群組建立關聯，則可以刪除任何現有安全群組 (包括原始安全群組)，只要該 layer 至少保留一個群組即可。從 layer 移除安全群組之後， OpsWorks Stacks 不會將其新增至任何新的或重新啟動的執行個體。 OpsWorks Stacks 不會從線上執行個體移除安全群組。如果您的堆疊是在 VPC 中執行，您可以使用 Amazon EC2 主控台、API 或 CLI 來新增或移除線上執行個體的安全群組。不過，此安全群組不會在 Stacks OpsWorks 主控台中顯示。如果您想要移除安全群組，您還必須使用 Amazon EC2。如需詳細資訊，請參閱[安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html)。注意下列事項： + 您無法藉由新增更嚴格的安全群組，來限制內建安全群組的連接埠存取設定。有多個安全群組時，Amazon EC2 會使用最寬鬆的設定。 + 您不應修改內建安全群組的組態。當您建立堆疊時， OpsWorks Stacks 會覆寫內建安全群組的組態，因此您所做的任何變更都會在您下次建立堆疊時遺失。如果您發現一或多個 layer 需要更嚴格的安全群組設定，請執行下列步驟： 1. 使用適當的設定來建立自訂安全群組，並將其新增至適當的 layer。除了內建群組之外，堆疊中的每個 layer 都必須至少具有一個安全群組，即使只有一個 layer 需要自訂設定。 1. [編輯堆疊組態](workingstacks-edit.md)並將 **Use OpsWorks security groups (使用 OpsWorks 安全群組)** 設定切換至 **No (否)**。 OpsWorks Stacks 會自動從每一層移除內建的安全群組。如需安全群組的詳細資訊，請參閱 [Amazon EC2 安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)。 **EC2 執行個體描述檔** 您可以為 layer 的執行個體變更 EC2 描述檔。如需詳細資訊，請參閱[指定在 EC2 執行個體上執行之應用程式的許可](opsworks-security-appsrole.md)。 ## CloudWatch Logs **CloudWatch Logs** 索引標籤可讓您啟用或停用 Amazon CloudWatch Logs。CloudWatch Logs 整合適用於 Chef 11.10 和 Chef 12 Linux 型堆疊。如需啟用 CloudWatch Logs 整合和指定要在 CloudWatch Logs 主控台中管理之日誌的詳細資訊，請參閱 [搭配 Stacks OpsWorks 使用 Amazon CloudWatch Logs](monitoring-cloudwatch-logs.md)。 ## Tags (標籤) **Tags (標籤)** 標籤可讓您將成本分配標籤套用至您的 layer。新增標籤後，您可以在 AWS 帳單與成本管理主控台中啟用標籤。建立標籤時，您會將標籤套用於已加上標籤的結構中每項資源。例如，如果您將標籤套用至 layer，您要將標籤套用至 layer 中的每個執行個體、Amazon EBS 磁碟區或 Elastic Load Balancing 負載平衡器。如需如何啟用標籤並使用它們來追蹤和管理 OpsWorks Stacks 資源成本的詳細資訊，請參閱 *帳單與成本管理使用者指南*中的[使用成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)和[啟用使用者定義的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)。如需 OpsWorks Stacks 中標記的詳細資訊，請參閱[Tags (標籤)](tagging.md)。 # 使用自動修復來替換故障的執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。每個執行個體都有 Stacks OpsWorks 代理程式，可定期與服務通訊。 OpsWorks Stacks 使用該通訊來監控執行個體的運作狀態。如果代理程式超過約五分鐘未與服務通訊， OpsWorks Stacks 會將執行個體視為失敗。自動修復是在 layer 層級設定；您可以透過編輯 layer 設定來變更自動修復設定，如下列螢幕擷取畫面所示。 ![\[Layer settings interface showing Auto healing enabled option set to Yes.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/layer_auto_healing.png) **注意** 執行個體可以是多個 layer 的成員。如果其中任何圖層已停用自動修復， OpsWorks 則Stacks 不會在執行個體失敗時修復執行個體。如果 layer 已啟用自動修復 — 預設設定 —OpsWorks Stacks 會自動取代 layer 的失敗執行個體，如下所示： **執行個體後端執行個體** 1. 停止 Amazon EC2 執行個體，並驗證其已關閉。 1. 刪除根磁碟區上的資料。 1. 建立具有相同主機名稱、組態和層成員資格的新 Amazon EC2 執行個體。 1. 重新連接任何 Amazon EBS 磁碟區，包括在最初啟動舊執行個體之後連接的磁碟區。 1. 指派新的公有及私有 IP 地址。 1. 如果舊執行個體與彈性 IP 地址相關聯，則會將新執行個體與相同的 IP 地址建立關聯。 **Amazon EBS 支援的執行個體** 1. 停止 Amazon EC2 執行個體，並驗證其已停止。 1. 啟動 EC2 執行個體。自動修復的執行個體恢復上線後， OpsWorks Stacks 會在所有堆疊的執行個體上觸發設定[生命週期事件](workingcookbook-events.md)。相關聯的[堆疊設定和部署屬性](workingcookbook-json.md)包括執行個體的公有和私有 IP 地址。自訂設定配方可以從節點物件取得新的 IP 地址。如果您為 layer [執行個體指定 Amazon EBS 磁碟區](workinglayers-basics-edit.md#workinglayers-basics-edit-ebs)， OpsWorks Stacks 會建立新的磁碟區，並在執行個體啟動時將其連接至每個執行個體。如果您稍後想要將磁碟區從執行個體分離，請使用[資源](resources.md)頁面。當 OpsWorks Stacks 自動修復 layer 的其中一個執行個體時，它會以下列方式處理磁碟區： + 如果磁碟區在執行個體失敗時連接到執行個體，則會儲存磁碟區及其資料，而 OpsWorks Stacks 會將磁碟區連接到新的執行個體。 + 如果在執行個體故障時未將磁碟區連接至執行個體，則 OpsWorks Stacks 將使用 layer 指定之組態建立新的空磁碟區，並將該磁碟區連接至新執行個體。根據預設會為所有 layer 啟用自動修復，但您可以[編輯 layer 的一般設定](workinglayers-basics-edit.md)來將其停用。 **重要** 如果您已啟用自動修復，請務必執行下列作業：僅使用 OpsWorks Stacks 主控台、CLI 或 API 來停止執行個體。如果您以任何其他方式停止執行個體，例如使用 Amazon EC2 主控台， OpsWorks Stacks 會將執行個體視為失敗，並自動修復。如果執行個體已自動修復，請使用 Amazon EBS 磁碟區來存放您不想遺失的任何資料。自動修復會停止舊的 Amazon EC2 執行個體，這會銷毀任何未存放在 Amazon EBS 磁碟區的資料。Amazon EBS 磁碟區會重新連接至新的執行個體，以保留任何儲存的資料。 # 刪除 OpsWorks Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果您不再需要 OpsWorks Stacks layer，您可以從堆疊中刪除它。 **刪除 OpsWorks 層** 1. 在導覽窗格中，按一下 **Instances (執行個體)**。 1. 在 **Instances (執行個體)** 頁面上，在您要刪除的 layer 名稱下，按一下每個執行個體 **Actions (動作)** 欄位中的 **stop (停止)**。 ![\[Confirmation dialog to stop a PHP app server instance, warning of potential data loss.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/stop_instance.png) 1. 每個執行個體停止後，按一下 **delete (刪除)** 將其從 layer 中刪除。 1. 在導覽窗格中，按一下 **Layers (Layer)**。 1. 在 **Layers (Layer)** 頁面上，選擇 **Delete (刪除)**。 ![\[PHP App Server settings page with options for Recipes, Network, EBS Volumes, and Security.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/delete_layer.png) # Elastic Load Balancing Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Elastic Load Balancing 的運作方式與 OpsWorks Stacks layer 略有不同。您可以使用 Elastic Load Balancing 主控台或 API 來建立負載平衡器，然後將其連接到現有的 layer，而不是建立 layer 並將其新增至其中。除了將流量分配到 layer 的執行個體之外，Elastic Load Balancing 還會執行下列動作： + 偵測運作狀態不佳的 Amazon EC2 執行個體，並將流量重新路由至其餘運作狀態良好的執行個體，直到恢復運作狀態不佳的執行個體為止。 + 自動擴展處理容量的請求，以回應傳入的流量。 + 若您啟用[連接耗盡](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-conn-drain.html)，負載平衡器會停止將新的請求傳送至狀況不良或即將取消註冊的執行個體，但會在到達指定的逾時值之前保持連線，讓執行個體完成任何傳遞中的請求。將負載平衡器連接到 layer 之後， OpsWorks Stacks 會執行下列動作： + 取消註冊任何目前註冊的執行個體。 + 在該層的執行個體上線時自動註冊，並在執行個體離線時取消註冊，包含負載式和時間式執行個體。 + 自動開始在可用區域將請求路由傳送到註冊的執行個體。如果您已啟用負載平衡器的[連線耗盡](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-conn-drain.html)功能，您可以指定 Stacks OpsWorks 是否支援它。如果您啟用連線耗盡支援（預設設定），則在執行個體關閉後， OpsWorks Stacks 會執行下列動作： + 從負載平衡器取消註冊執行個體。負載平衡器會停止傳送新的請求，並啟動連接耗盡。 + 延遲觸發[關機生命週期事件](workingcookbook-events.md)，直到負載平衡器完成連接耗盡。如果您未啟用連線耗盡支援，即使執行個體仍連接至負載平衡器， OpsWorks Stacks 仍會在執行個體關閉後立即觸發關機事件。若要搭配堆疊使用 Elastic Load Balancing，您必須先使用 Elastic Load Balancing 主控台、CLI 或 API，在相同區域中建立一或多個負載平衡器。建議您注意以下事項： + 您只能將一個負載平衡器連接到一個 layer。 + 每個負載平衡器只能處理一個 layer。 + OpsWorks Stacks 不支援 Application Load Balancer。您只能搭配 OpsWorks Stacks 使用 Classic Load Balancer。這表示您必須為要平衡的每個堆疊中的每個層建立單獨的 Elastic Load Balancing 負載平衡器，並僅將其用於該目的。建議的做法是為您計劃與 OpsWorks Stacks 搭配使用的每個 Elastic Load Balancing 負載平衡器指派獨特的名稱，例如 MyStack1-RailsLayer-ELB，以避免將負載平衡器用於多個用途。 **重要** 建議您為 Stacks 層建立新的 Elastic Load Balancing OpsWorks 負載平衡器。如果您選擇使用現有的 Elastic Load Balancing 負載平衡器，您應該先確認它未用於其他用途，也沒有連接的執行個體。在負載平衡器連接到 layer 之後，OpsWorks 會移除任何現有的執行個體，並設定負載平衡器，使其僅處理 layer 的執行個體。雖然在技術上可以使用 Elastic Load Balancing 主控台或 API 在將負載平衡器連接到 layer 之後修改負載平衡器的組態，但您不應該這麼做；變更不會永久存在。 **將 Elastic Load Balancing 負載平衡器連接到 layer** 1. 如果您尚未這麼做，請使用 [Elastic Load Balancing 主控台](https://console.aws.amazon.com/ec2/#s=LoadBalancers)、API 或 CLI 在堆疊的區域中建立負載平衡器。當您建立負載平衡器時，請執行下列作業： + 請務必指定適合您應用程式的運作狀態檢查 ping 路徑。預設 ping 路徑為 `/index.html`，因此若您的應用程式根並未包含 `index.html`，您必須指定適當的 ping 路徑，否則運作狀態檢查會失敗。 + 若您欲使用[連接耗盡](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/config-conn-drain.html)，請確認已啟用該功能，並且具有適當的逾時值。如需詳細資訊，請參閱 [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/Welcome.html)。 1. [建立您希望平衡的 layer](workinglayers-basics-create.md) 或[編輯現有 layer 的網路設定](workinglayers-basics-edit.md)。 **注意** 您無法在建立自訂 layer 時連接負載平衡器。您必須編輯 layer 的設定。 1. 在 **Elastic Load Balancing** 下，選取您要連接到 layer 的負載平衡器，並指定是否要 Stacks OpsWorks 支援連線耗盡。將負載平衡器連接到 layer 之後， OpsWorks Stacks 會在堆疊的執行個體上觸發[設定生命週期事件](workingcookbook-events.md)，通知他們變更。當您分離負載平衡器時， OpsWorks Stacks 也會觸發設定事件。 **注意** 執行個體啟動後， OpsWorks Stacks 會執行[安裝和部署配方](workingcookbook-executing.md)，以安裝套件和部署應用程式。在這些配方完成後，執行個體會處於線上狀態，且 OpsWorks Stacks 會向 Elastic Load Balancing 註冊執行個體。當執行個體上線後， OpsWorks Stacks 也會觸發設定事件。這表示 Elastic Load Balancing 註冊和設定配方可以同時執行，而且執行個體可能會在設定配方完成之前註冊。為了確保配方在向 Elastic Load Balancing 註冊執行個體之前完成，您應該將配方新增至 layer 的設定或部署生命週期事件。如需詳細資訊，請參閱[執行配方](workingcookbook-executing.md)。有時候將執行個體從負載平衡器移除也會非常有用。例如，當您更新應用程式時，我們建議您將應用程式部署至單一執行個體，並在將其部署到每個執行個體前，驗證應用程式已正常運作。您通常會將執行個體從負載平衡器移除，使其在您完成驗證更新之前不會接收到使用者請求。您必須使用 Elastic Load Balancing 主控台或 API，暫時從負載平衡器移除線上執行個體。以下說明如何使用主控台。 **暫時將執行個體從負載平衡器移除** 1. 開啟 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/)，然後選擇**負載平衡器**。 1. 選擇適當的負載平衡器，然後開啟 **Instances (執行個體)** 標籤。 1. 在執行個體的 **Actions (動作)** 資料行中，選擇 **Remove from Load Balancer (從負載平衡器移除)**。 1. 當您完成時，請選擇 **Edit Instances (編輯執行個體)**，然後將執行個體返回負載平衡器。 **重要** 如果您使用 Elastic Load Balancing 主控台或 API 從負載平衡器移除執行個體，您還必須使用 Elastic Load Balancing 將其放回。 OpsWorks Stacks 不知道您使用其他服務主控台或 APIs 執行的操作，而且不會將執行個體傳回負載平衡器。有時候， OpsWorks Stacks 可以將執行個體新增回 ELB，但這並不保證行為，而且不會在所有情況下發生。您可以將多個負載平衡器連接到特定的執行個體組，如下所示： **連接多個負載平衡器** 1. 使用 [Elastic Load Balancing 主控台](https://console.aws.amazon.com/ec2/#s=LoadBalancers)、API 或 CLI 來建立一組負載平衡器。 1. 為每個負載平衡器[建立自訂 layer](workinglayers-custom.md)，並將其中一個負載平衡器連接到該 layer。您不需要為這些 layer 實作任何自訂配方。預設自訂 layer 已足夠。 1. 將[執行個體組新增](workinginstances-add.md)至每個自訂 layer。您可以藉由前往執行個體頁面並按一下適當的負載平衡器名稱，來檢查負載平衡器的屬性。 ![\[PHP App Server table showing two online instances with their details and status.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elb_view.png) **ELB** 頁面會顯示負載平衡器的基本屬性，包含其 DNS 名稱和關聯執行個體的運作狀態。若堆疊正在 VPC 中執行，頁面會顯示子網路，而非可用區域。綠色的核取記號表示運作狀態良好的執行個體。您可以按一下名稱透過負載平衡器以連線到伺服器。 ![\[ELB My-Stack-PHP settings showing DNS name, layer, region, and instance status.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elb_properties.png) # Amazon RDS 服務層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Amazon RDS 服務層代表 Amazon RDS 執行個體。layer 只能代表現有的 Amazon RDS 執行個體，您必須使用 [Amazon RDS 主控台](https://console.aws.amazon.com/rds/)或 API 分別建立。將 Amazon RDS 服務層整合到您的堆疊的基本程序如下： 1. 使用 Amazon RDS 主控台、API 或 CLI 來建立執行個體。請務必記錄執行個體的 ID、主要使用者名稱、主要密碼和資料庫名稱。 1. 若要將 Amazon RDS layer 新增至堆疊，請向堆疊註冊 Amazon RDS 執行個體。 1. 將 layer 連接至應用程式，將 Amazon RDS 執行個體的連線資訊新增至應用程式的[`deploy`屬性](workingcookbook-json.md#workingcookbook-json-deploy)。 1. 使用語言特定檔案或 `deploy` 屬性中的資訊，將應用程式連線至 Amazon RDS 執行個體。如需如何將應用程式連線至資料庫伺服器的詳細資訊，請參閱[將應用程式連線至資料庫伺服器](workingapps-connectdb.md) **警告** 請確定執行個體之主要密碼和使用者名稱中的字元與您的應用程式伺服器相容。例如，使用 Java App Server layer，包括在任一字串`&`中會導致 XML 剖析錯誤，以防止 Tomcat 伺服器啟動。 **Topics** + [指定安全群組](#workinglayers-db-rds-security) + [向堆疊註冊 Amazon RDS 執行個體](#workinglayers-db-rds-register) + [將 Amazon RDS 服務層與應用程式建立關聯](#workinglayers-db-rds-register-attach) + [從堆疊移除 Amazon RDS Service Layer](#workinglayers-db-rds-register-remove) ## 指定安全群組若要搭配 Stacks 使用 Amazon RDS OpsWorks 執行個體，資料庫或 VPC 安全群組必須允許從適當的 IP 地址存取。針對生產用途，安全群組通常會限制僅存取這些需要存取資料庫的 IP 地址。它通常包含您用來管理資料庫的系統地址，以及需要存取資料庫的 OpsWorks Stacks 執行個體。當您在區域中建立第一個堆疊時， OpsWorks Stacks 會自動為每種類型的 layer 建立 Amazon EC2 安全群組。為 OpsWorks Stacks 執行個體提供存取權的簡單方法是將適當的 OpsWorks Stacks 安全群組指派給 Amazon RDS 執行個體或 VPC。 **指定現有 Amazon RDS 執行個體的安全群組** 1. 前往 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)，開啟 Amazon RDS 主控台。 1. 按一下導覽窗格中**的執行個體**，然後選取適當的 Amazon RDS 執行個體。按一下 **Instance Actions (執行個體動作)**、**Modify (修改)**。 1. 從 **Security Group (安全群組)** 清單中選取下列安全群組，然後按一下 **Continue (繼續)** 和 **Modify DB Instance (修改資料庫執行個體)** 更新執行個體。 + **AWS-OpsWorks-DB-Master-Server (*security\$1group\$1id*)** 安全群組。 + 其執行個體將連線至資料庫之應用程式伺服器 layer 的安全群組。群組名稱包括 layer 名稱。例如，若要提供 PHP App Server 執行個體的資料庫存取權，請指定 **AWS-OpsWorks-PHP-App-Server** 群組。如果您要建立新的 Amazon RDS 執行個體，您可以在啟動資料庫執行個體精靈**的設定進階設定**頁面上指定適當的 OpsWorks Stacks 安全群組。如需如何使用此精靈的描述，請參閱[建立 MySQL 資料庫執行個體和連線至 MySQL 資料庫執行個體上的資料庫](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.MySQL.html)。如需如何指定 VPC 安全群組的資訊，請參閱 [VPC 的安全群組](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html)。 ## 向堆疊註冊 Amazon RDS 執行個體若要在堆疊中新增 Amazon RDS 服務層，您必須向堆疊註冊執行個體。 **向堆疊註冊 Amazon RDS 執行個體** 1. 在 OpsWorks Stacks 主控台中，按一下導覽窗格中的**圖層**，按一下 **\$1 Layer** 或**新增圖層**以開啟**新增圖層**頁面，然後按一下 **RDS** 標籤。 1. 如有必要，請更新堆疊的服務角色，如[更新堆疊的服務角色](#workinglayers-db-rds-register-role)中所述。 1. 按一下 RDS 索引標籤，列出可用的 Amazon RDS 執行個體。 **注意** 如果您的帳戶沒有任何 Amazon RDS 執行個體，您可以按一下 **RDS 標籤上的新增 RDS 執行個體**來建立執行個體，這會將您導向 Amazon RDS 主控台並啟動**啟動資料庫執行個體**精靈。您也可以直接前往 [Amazon RDS 主控台](https://console.aws.amazon.com/rds/)，然後按一下**啟動資料庫執行個體**，或使用 Amazon RDS API 或 CLI。如需如何建立 Amazon RDS 執行個體的詳細資訊，請參閱 [Amazon RDS 入門](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html)。 1. 選取適當的執行個體，並將 **User (使用者)** 和 **Password (密碼)** 設定為適當的使用者和密碼值，然後按一下 **Register to Stack (向堆疊註冊)**。 **重要** 您必須確保您用來註冊 Amazon RDS 執行個體的使用者和密碼對應至有效的使用者和密碼。否則，您的應用程式將無法連線至執行個體。不過，您可以[編輯 layer](workinglayers-basics-edit.md) 以提供有效的使用者和密碼值，然後重新部署應用程式。 ![\[RDS instance details showing connection information for opsinstance2 with MySQL engine.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/rds-register.png) 當您將 Amazon RDS 服務層新增至堆疊時， OpsWorks Stacks 會為其指派 ID，並將相關聯的 Amazon RDS 組態新增至[堆疊組態和部署屬性](workingcookbook-json.md)的 [`[:opsworks][:stack]`](attributes-json-opsworks-stack.md) 屬性。 **注意** 如果您變更已註冊的 Amazon RDS 執行個體密碼，則必須手動更新 Stacks OpsWorks 中的密碼，然後重新部署您的應用程式，以更新堆疊執行個體上的堆疊組態和部署屬性。 **Topics** + [更新堆疊的服務角色](#workinglayers-db-rds-register-role) ### 更新堆疊的服務角色每個堆疊都有一個 [IAM 服務角色](opsworks-security-servicerole.md)，指定 OpsWorks Stacks 可以代表您與其他 AWS 服務執行的動作。若要向堆疊註冊 Amazon RDS 執行個體，其服務角色必須授予 OpsWorks Stacks 存取 Amazon RDS 的許可。第一次將 Amazon RDS 服務層新增至其中一個堆疊時，服務角色可能缺少必要的許可。若是如此，當您按一下 **Add Layer (新增 Layer)** 頁面上的 RDS 標籤時，將會看到下列內容。 ![\[Warning message about OpsWorksIAM role needing RDS instances access policy.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/rds-iam-update.png) 按一下**更新**，讓 OpsWorks Stacks 將服務角色的政策更新如下。 ``` {"Statement": [{"Action": ["ec2:*", "iam:PassRole", "cloudwatch:GetMetricStatistics", "elasticloadbalancing:*", "rds:*"], "Effect": "Allow", "Resource": ["*"] }] } ``` **注意** 您只需要執行更新一次。所有堆疊接著會自動使用更新過的角色。 ## 將 Amazon RDS 服務層與應用程式建立關聯新增 Amazon RDS 服務層之後，您可以將其與應用程式建立關聯。 + 您可以在[建立](workingapps-creating.md)應用程式時，或稍後[編輯應用程式的組態，將 Amazon RDS layer 與應用程式](workingapps-editing.md)建立關聯。 + 若要取消 Amazon RDS layer 與應用程式的關聯，請編輯應用程式的組態以指定不同的資料庫伺服器，或無伺服器。 Amazon RDS layer 仍是堆疊的一部分，並且可以與不同的應用程式建立關聯。將 Amazon RDS 執行個體與應用程式建立關聯後， OpsWorks Stacks 會將資料庫連線資訊放在應用程式的伺服器上。每個伺服器執行個體上的應用程式接著都可以使用此資訊連線至資料庫。如需如何連線至 Amazon RDS 執行個體的詳細資訊，請參閱 [將應用程式連線至資料庫伺服器](workingapps-connectdb.md)。 ## 從堆疊移除 Amazon RDS Service Layer 若要從堆疊中移除 Amazon RDS 服務層，請將其取消註冊。 **取消註冊 Amazon RDS 服務層** 1. 按一下導覽窗格中**的圖層**，然後按一下 Amazon RDS 服務圖層的名稱。 1. 按一下 **Deregister (取消註冊)**，並確認您想要將 layer 取消註冊。此程序會從堆疊中移除 layer，但不會刪除基礎 Amazon RDS 執行個體。執行個體和任何資料庫都會保留在您的帳戶中，而且可以向其他堆疊註冊。您必須使用 Amazon RDS 主控台、API 或 CLI 來刪除執行個體。如需詳細資訊，請參閱[刪除資料庫執行個體](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html#CHAP_GettingStarted.Deleting)。 # ECS 叢集層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 [Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) 會管理 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體叢集上的 Docker 容器，稱為容器執行個體。ECS 叢集層代表 Amazon ECS 叢集，並提供以下功能來簡化叢集管理： + 簡化的容器執行個體佈建及管理 + 容器執行個體作業系統及套件更新 + 使用者許可管理 + 容器執行個體效能監控 + Amazon Elastic Block Store (Amazon EBS) 磁碟區管理 + 公有和彈性 IP 地址管理 + 安全群組管理 ECS 叢集層具有下列限制和要求： + layer 僅適用於在 VPC 中執行的 Chef 11.10 或 Chef 12 Linux 堆疊，包含[預設 VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html)。 + layer 的執行個體必須執行以下任一作業系統。 + Amazon Linux 2 + Amazon Linux 2018.03 + Amazon Linux 2017.09 + Amazon Linux 2017.03 + Amazon Linux 2016.09 + Amazon Linux 2016.03 + Amazon Linux 2015.09 + Amazon Linux 2015.03 + Ubuntu 18.04 LTS + Ubuntu 16.04 LTS + Ubuntu 14.04 LTS + Custom + layer 的執行個體上的 [OpsWorks Stacks 代理程式版本](workingstacks-creating.md#workingstacks-creating-advanced)必須為 `3425-20150727112318` 或更新版本。 **Topics** + [將 ECS 叢集層新增至堆疊](#workinglayers-ecscluster-add) + [管理 ECS 叢集](#workinglayers-ecscluster-manage) + [從堆疊刪除 ECS 叢集層](#workinglayers-ecscluster-delete) ## 將 ECS 叢集層新增至堆疊 OpsWorks Stacks 可簡化啟動和維護現有 Amazon ECS 叢集容器執行個體的程序。若要建立或啟動其他 Amazon ECS 實體，例如叢集和任務，請使用 Amazon ECS 主控台、命令列界面 (CLI) 或 API。（如需詳細資訊，請參閱 [Amazon Elastic Container Service 開發人員指南](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/)。) 然後，您可以透過建立 ECS 叢集層來建立叢集與堆疊的關聯，以用於在 Stacks OpsWorks 中管理叢集。您可以將叢集與堆疊建立關聯，如下所示： + 每個堆疊可以有一個 ECS 叢集層，代表單一叢集。 + 一個叢集只能與一個堆疊建立關聯。您必須先更新通常名為 OpsWorks 的 Stacks AWS Identity and Access Management (IAM) 服務角色，以允許 OpsWorks Stacks 代表您與 Amazon ECS 互動`aws-opsworks-service-role`，才能將 ECS 叢集層新增至堆疊。如需服務角色的詳細資訊，請參閱[允許 OpsWorks Stacks 代表您採取行動](opsworks-security-servicerole.md)。第一次建立 ECS 叢集層時，主控台會提供**更新**按鈕，您可以選擇指示 OpsWorks Stacks 為您更新角色。 OpsWorks 堆疊接著會顯示**新增層**頁面，讓您可以將層新增至堆疊。您只需要更新服務角色一次。然後，您可以使用更新的角色，將 ECS 叢集層新增至任何堆疊。 **注意** 若您偏好的話，您可以透過將 `ecs:*` 許可新增至現有的政策來手動更新服務角色的政策，如下所示： ``` { "Statement": [ { "Action": [ "ec2:*", "iam:PassRole", "cloudwatch:GetMetricStatistics", "elasticloadbalancing:*", "rds:*", "ecs:*" ], "Effect": "Allow", "Resource": ["*"] } ] } ``` 將叢集與堆疊建立關聯需要兩項操作：使用堆疊註冊叢集，然後建立關聯 layer。Stacks OpsWorks 主控台結合了這些步驟； layer 建立會自動註冊指定的叢集。如果您使用 OpsWorks Stacks API、CLI 或 SDK，您必須使用個別的操作來註冊叢集並建立相關聯的 layer。若要使用主控台將 ECS 叢集層新增至堆疊，請選擇**圖層**、選擇 **\$1圖層**或**新增圖層**，然後選擇 ECS 叢集層類型。 ![\[Form for adding an ECS 叢集 Layer, showing layer type, 叢集 selection, and EC2 instance profile options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add_layer_ecs.png) **Add Layer (新增 Layer)** 頁面包含下列組態選項： **ECS 叢集** 您要向堆疊註冊的 Amazon ECS 叢集。 **EC2 Instance profile (EC2 執行個體描述檔)** 叢集的 Amazon Elastic Compute Cloud(Amazon EC2) 執行個體描述檔。此設定檔授予在叢集容器執行個體上執行的應用程式存取其他 AWS 服務的許可，包括 Amazon ECS。當您建立第一個 ECS 叢集層時，請選擇**具有 ECS 存取權的新設定檔**以指示 OpsWorks Stacks 建立必要的設定檔，其名稱為 `aws-opsworks-ec2-role-with-ecs`。然後，您可以將該設定檔用於所有後續的 ECS 叢集層。如需執行個體描述檔的詳細資訊，請參閱[指定在 EC2 執行個體上執行之應用程式的許可](opsworks-security-appsrole.md)。您可以藉由[編輯 layer 的組態](workinglayers-basics-edit.md)指定其他設定，包含： + [將 Elastic Load Balancing 負載平衡器](workinglayers-basics-edit.md#workinglayers-basics-edit-network)連接至 layer。此方法可能適用於某些使用案例，但 Amazon ECS 提供更複雜的選項。如需詳細資訊，請參閱[服務負載平衡](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html)。 + 指定是否要自動將[公有 IP 地址或彈性 IP 地址](workinglayers-basics-edit.md#workinglayers-basics-edit-network)指派給容器執行個體。若您停用兩種地址類型的自動指派，執行個體會無法上線，除非子網路已有適當設定的 NAT。如需詳細資訊，請參閱[在 VPC 中執行堆疊](workingstacks-vpc.md)。 ## 管理 ECS 叢集建立 ECS 叢集層之後，您可以使用 OpsWorks Stacks 來管理叢集，如下所示： **佈建及管理容器執行個體** 一開始，ECS 叢集層不包含任何容器執行個體，即使原始叢集已包含。一個選項是透過使用下列項目的適當組合，管理 layer 的執行個體： + 手動[新增全年無休執行個體](workinginstances-add.md)至 layer 及在不需要時[刪除執行個體](workinginstances-delete.md)。 + 透過將[時間式執行個體](workinginstances-autoscaling-timebased.md)新增至 layer，藉以在排程上新增或刪除執行個體。 + 將負載型執行個體新增至 layer，以根據 OpsWorks Stacks 主機指標或 CloudWatch 警示新增或刪除執行個體。 [使用自動負載型擴展](workinginstances-autoscaling-loadbased.md) 如果堆疊的預設作業系統不支援 Amazon ECS，您必須在建立容器執行個體時明確指定支援的作業系統：Amazon Linux 2、Amazon Linux 2018.03、Amazon Linux 2017.09、Amazon Linux 2017.03、Amazon Linux 2016.09、Amazon Linux 2016.03、Amazon Linux 2015.09、Amazon Linux 2015.03、Ubuntu 18.04 LTS、Ubuntu 16.04 LTS、Ubuntu 14.04 LTS 或 Custom—。請勿使用 ECS Optimized AMI 在 ECS layer 中建立執行個體，因為此 AMI 已包含 ECS 代理程式。 OpsWorks Stacks 也會嘗試在執行個體設定程序期間安裝 ECS 代理程式，且衝突可能會導致設定失敗。如需詳細資訊，請參閱 [最佳化應用程式伺服器的數目](best-practices-autoscale.md). OpsWorks Stacks 將 **AWS-OpsWorks-ECS-Cluster** 安全群組指派給每個執行個體。每個新執行個體完成開機後， OpsWorks Stacks 會安裝 Docker 和 Amazon ECS 代理程式，然後向叢集註冊執行個體，將其轉換為容器執行個體。如果您偏好使用現有的容器執行個體，則可以[向堆疊註冊它們](registered-instances-register.md)，並將[它們指派給 ECS 叢集層](registered-instances-assign.md)。請注意，執行個體必須執行支援的作業系統，Amazon Linux 2015.03 或更新版本、Ubuntu 14.04 LTS 或更新版本。容器執行個體不能同時屬於 ECS 叢集層和另一個內建層。不過，容器執行個體*可以*屬於 ECS 叢集層和一或多個[自訂層](workinglayers-custom.md)。 **執行作業系統及套件更新** 新執行個體完成開機後， OpsWorks Stacks 會安裝最新的更新。然後，您可以使用 OpsWorks Stacks 將容器執行個體保持在最新狀態。如需詳細資訊，請參閱[管理安全性更新](workingsecurity-updates.md)。 **管理使用者許可** OpsWorks Stacks 提供簡單的方法來管理容器執行個體的許可，包括管理使用者的 SSH 金鑰。如需詳細資訊，請參閱[管理使用者許可](opsworks-security-users.md)及[管理 SSH 存取](security-ssh-access.md)。 **監控效能指標** OpsWorks Stacks 提供各種方法來監控堆疊、 layer 或個別執行個體的效能指標。如需詳細資訊，請參閱[監控](monitoring.md)。您可以透過 Amazon ECS 處理其他管理任務，例如建立任務或服務。如需詳細資訊，請參閱《[Amazon Elastic Container Service 開發人員指南》](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/)。 **注意** 若要直接前往 Amazon ECS 主控台上的叢集頁面，請選擇**執行個體**，然後選擇靠近 **ECS 叢集**層區段右上角的 ECS 叢集。 ## 從堆疊刪除 ECS 叢集層當您不再需要叢集時，請刪除 ECS 叢集層並取消註冊相關聯的叢集。從堆疊移除叢集需要兩項操作：取消註冊叢集，然後刪除關聯 layer。Stacks OpsWorks 主控台結合了這些步驟； layer 刪除會自動取消註冊指定的叢集。如果您使用 OpsWorks Stacks API、CLI 或 SDK，則必須使用單獨的操作來取消註冊叢集並刪除相關聯的 layer。 **使用主控台刪除 ECS 叢集層** 1. 如果您想要控制任務關閉的方式，請使用 Amazon ECS 主控台、API 或 CLI 來縮減規模並刪除叢集的服務。如需詳細資訊，請參閱[清除 Amazon ECS 資源](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CleaningUp.html)。 1. [停止 layer 的執行個體](workinginstances-starting.md#workinginstances-starting-stop)，然後[刪除執行個體](workinginstances-delete.md)。當您停止容器執行個體時， OpsWorks Stacks 會自動停止任何執行中的任務、從叢集取消註冊執行個體，以及終止執行個體。 **注意** 若您有已使用堆疊註冊的現有容器執行個體，您可以[從 layer 取消指派執行個體](registered-instances-unassign.md)，然後[取消註冊他們](registered-instances-deregister.md)，使執行個體回歸 ECS 的控制。 1. [刪除 layer](workinglayers-basics-delete.md). OpsWorks Stacks 會取消註冊相關聯的叢集，但不會將其刪除。叢集會保留在 Amazon ECS 中。 # 自訂 OpsWorks Stacks Layers **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。自訂 layer 僅包含一組最少的配方。您可以實作[自訂配方](workingcookbook.md)並將其指派到 layer 的[ 生命週期事件](workingcookbook-events.md)，以將適當的功能新增至 layer。自訂 layer 具有下列組態設定。 **注意** OpsWorks Stacks 會自動在 layer 的執行個體上安裝 Ruby。如果您想要在執行個體上執行 Ruby 程式碼，但不想使用預設的 Ruby 版本，則可以使用自訂 JSON 或自訂屬性檔案，來指定您慣用的版本。如需詳細資訊，請參閱[Ruby 版本](workingcookbook-ruby.md)。建立自訂 layer 的基本程序有下列步驟： 1. 實作[技術指南](workingcookbook.md)，其中包含安裝和設定套件、處理組態變更、部署應用程式等所需的配方與相關聯檔案。根據您的需求，您可能也需要取消部署和關機任務的配方。如需詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。 1. 建立自訂 layer。 1. 將您的配方指定給適當的[生命週期事件](workingcookbook-events.md)。接著，您可以將執行個體新增至 layer、啟動執行個體，然後部署應用程式到這些執行個體中。 **重要** 若要將應用程式部署到自訂 layer 的執行個體，您必須實作配方來處理部署操作，並將配方指派給該 layer 的部署事件。 # 個別 layer 作業系統套件安裝 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。從 Chef 12 開始，您必須使用自訂配方，在執行不同作業系統的 layer 上安裝套件。此方法提供套件安裝的最大彈性和控制。例如，假設您想要在執行 RedHat、Ubuntu 和 Amazon 版本之 Linux 作業系統的 layer 上安裝 Apache。RedHat 和 Amazon Linux 的 Apache 套件稱為 `httpd`，但在 Ubuntu 上稱為 `apache2`。若要解決套件命名的差異，您可以使用下列範例配方中的類似語法。此配方會安裝每個作業系統適用的 Apache 套件。此範例根據 [Chef 文件](https://docs.chef.io/)。 ``` package "Install Apache" do case node[:platform] when "redhat", "amazon" package_name "httpd" when "ubuntu" package_name "apache2" end end ``` 如需如何使用 `package` 資源管理套件的詳細資訊，請前往 Chef 文件中的[套件](https://docs.chef.io/resource_package.html)頁面。或者，您可以從 Chef 配方 DSL (網域特定語言) 使用 `value_for_platform` 協助程式方法，更簡潔地完成相同的事項： ``` package "Install Apache" do package_name value_for_platform( ["redhat", "amazon"] => { "default" => "httpd" }, ["ubuntu"] => { "default" => "apache2" } ) end ``` 如需使用 `value_for_platform` 協助程式方法的資訊，請前往[關於配方 DSL](https://docs.chef.io/dsl_recipe.html)。 # 執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。執行個體代表運算資源，例如 Amazon EC2 執行個體，可處理服務應用程式、平衡流量等的工作。執行個體的作業系統可以有多個 Linux 發行版本之一或 Windows Server 2012 R2。您可用下列任一方法將執行個體新增至堆疊： + 使用 OpsWorks Stacks 將執行個體新增至堆疊。您新增的執行個體代表 Amazon EC2 執行個體。 + 對於 Linux 型堆疊，您可以註冊在其他地方建立的執行個體，包括您使用 Amazon EC2 建立的執行個體，以及在您自己的硬體上執行*的內部部署*執行個體。然後，您可以使用 OpsWorks Stacks 以與使用 Stacks OpsWorks 建立的執行個體大致相同的方式管理這些執行個體本節說明如何使用 OpsWorks Stacks 來建立和管理執行個體。 **Topics** + [使用 OpsWorks Stacks 執行個體](workinginstances-opsworks.md) + [使用在 OpsWorks Stacks 之外建立的運算資源](registered-instances.md) + [編輯執行個體組態](workinginstances-properties.md) + [刪除 OpsWorks Stacks 執行個體](workinginstances-delete.md) + [使用 SSH 登入 Linux 執行個體](workinginstances-ssh.md) + [使用 RDP 登入 Windows 執行個體](workinginstances-rdp.md) # 使用 OpsWorks Stacks 執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用 OpsWorks Stacks 建立執行個體並將其新增至堆疊。 **Topics** + [OpsWorks Stacks 作業系統](workinginstances-os.md) + [將執行個體新增至 Layer](workinginstances-add.md) + [使用自訂 AMI](workinginstances-custom-ami.md) + [手動啟動、停止和重新開機全年無休的執行個體](workinginstances-starting.md) + [使用時間型和負載型執行個體管理負載](workinginstances-autoscaling.md) # OpsWorks Stacks 作業系統 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 支援數個內建作業系統的 64 位元版本，包括 Amazon 和 Ubuntu Linux 發行版本，以及 Microsoft Windows Server。下列為一般注意事項： + 堆疊的執行個體可以執行 Linux 或 Windows。堆疊可以具備不同 Linux 發行版本或不同執行個體，但您不可以混合 Linux 和 Windows 執行個體。 + 您可以使用[自訂 AMIs](workinginstances-custom-ami.md) (Amazon Machine Image)，但它們必須基於本節主題中所述的其中一個 OpsWorks Stacks 支援的 AMIs。雖然可以使用從自訂或社群所產生 AMI 建立而成的其他作業系統 (例如 CentOS 6.*x*) 建立或註冊執行個體，但並未正式受到支援。 + [Linux 作業系統](workinginstances-os-linux.md) + [Microsoft Windows Server](workinginstances-os-windows.md) + 您可以[手動啟動和停止執行個體](workinginstances-starting.md)，或讓 OpsWorks Stacks [自動擴展](workinginstances-autoscaling.md)執行個體的數目。您可以針對任何堆疊使用以時間為基礎的自動擴展；Linux 堆疊也可以使用以負載為基礎的擴展。 + 除了使用 OpsWorks Stacks 建立 Amazon EC2 執行個體之外，您還可以[向在 Stacks 外部建立的 Linux 堆疊註冊執行個體](workinginstances-autoscaling.md)。 OpsWorks 這包括在您自己的硬體上執行的 Amazon EC2 執行個體和執行個體。不過，它們必須執行其中一種支援的 Linux 發行版本。您無法註冊 Amazon EC2 或內部部署 Windows 執行個體。您可以執行 OpsWorks Stacks [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeOperatingSystems.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeOperatingSystems.html) API 來傳回支援的作業系統及其支援的 Chef 版本清單。下面是使用 AWS CLI的範例命令。 ``` aws opsworks describe-operating-systems ``` 以下是回應範例。 ``` { "OperatingSystems": [ { "Name": "Amazon Linux", "Id": "Amazon Linux", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2014.03", "Supported": false }, { "Name": "Amazon Linux 2", "Id": "Amazon Linux 2", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" } ], "ReportedName": "amazon", "ReportedVersion": "2" }, { "Name": "Amazon Linux 2014.09", "Id": "Amazon Linux 2014.09", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2014.09", "Supported": false }, { "Name": "Amazon Linux 2015.03", "Id": "Amazon Linux 2015.03", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2015.03", "Supported": false }, { "Name": "Amazon Linux 2015.09", "Id": "Amazon Linux 2015.09", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2015.09", "Supported": false }, { "Name": "Amazon Linux 2016.03", "Id": "Amazon Linux 2016.03", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2016.03" }, { "Name": "Amazon Linux 2016.09", "Id": "Amazon Linux 2016.09", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2016.09" }, { "Name": "Amazon Linux 2017.03", "Id": "Amazon Linux 2017.03", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2017.03" }, { "Name": "Amazon Linux 2017.09", "Id": "Amazon Linux 2017.09", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "amazon", "ReportedVersion": "2017.09" }, { "Name": "Amazon Linux 2018.03", "Id": "Amazon Linux 2018.03", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" } ], "ReportedName": "amazon", "ReportedVersion": "2018.03" }, { "Name": "CentOS Linux 7", "Id": "CentOS Linux 7", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" } ], "ReportedName": "CentOS Linux", "ReportedVersion": "7" }, { "Name": "Microsoft Windows Server 2012 R2 Base", "Id": "Microsoft Windows Server 2012 R2 Base", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2012 r2 standard", "Supported": false }, { "Name": "Microsoft Windows Server 2012 R2 with SQL Server Express", "Id": "Microsoft Windows Server 2012 R2 with SQL Server Express", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2012 r2 standard", "Supported": false }, { "Name": "Microsoft Windows Server 2012 R2 with SQL Server Standard", "Id": "Microsoft Windows Server 2012 R2 with SQL Server Standard", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2012 r2 standard", "Supported": false }, { "Name": "Microsoft Windows Server 2012 R2 with SQL Server Web", "Id": "Microsoft Windows Server 2012 R2 with SQL Server Web", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2012 r2 standard", "Supported": false }, { "Name": "Microsoft Windows Server 2019 Base", "Id": "Microsoft Windows Server 2019 Base", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2019 datacenter" }, { "Name": "Microsoft Windows Server 2019 with SQL Server Express", "Id": "Microsoft Windows Server 2019 with SQL Server Express", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2019 datacenter" }, { "Name": "Microsoft Windows Server 2019 with SQL Server Standard", "Id": "Microsoft Windows Server 2019 with SQL Server Standard", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2019 datacenter" }, { "Name": "Microsoft Windows Server 2019 with SQL Server Web", "Id": "Microsoft Windows Server 2019 with SQL Server Web", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2019 datacenter" }, { "Name": "Microsoft Windows Server 2022 Base", "Id": "Microsoft Windows Server 2022 Base", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2022 datacenter" }, { "Name": "Microsoft Windows Server 2022 with SQL Server Express", "Id": "Microsoft Windows Server 2022 with SQL Server Express", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2022 datacenter" }, { "Name": "Microsoft Windows Server 2022 with SQL Server Standard", "Id": "Microsoft Windows Server 2022 with SQL Server Standard", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2022 datacenter" }, { "Name": "Microsoft Windows Server 2022 with SQL Server Web", "Id": "Microsoft Windows Server 2022 with SQL Server Web", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ], "ReportedName": "microsoft windows server", "ReportedVersion": "2022 datacenter" }, { "Name": "Red Hat Enterprise Linux 7", "Id": "Red Hat Enterprise Linux 7", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" } ], "ReportedName": "Red Hat Enterprise Linux", "ReportedVersion": "7" }, { "Name": "Ubuntu 12.04 LTS", "Id": "Ubuntu 12.04 LTS", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ], "ReportedName": "ubuntu", "ReportedVersion": "12.04", "Supported": false }, { "Name": "Ubuntu 14.04 LTS", "Id": "Ubuntu 14.04 LTS", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" } ], "ReportedName": "ubuntu", "ReportedVersion": "14.04" }, { "Name": "Ubuntu 16.04 LTS", "Id": "Ubuntu 16.04 LTS", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" } ], "ReportedName": "ubuntu", "ReportedVersion": "16.04" }, { "Name": "Ubuntu 18.04 LTS", "Id": "Ubuntu 18.04 LTS", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" } ], "ReportedName": "ubuntu", "ReportedVersion": "18.04" }, { "Name": "Ubuntu 20.04 LTS", "Id": "Ubuntu 20.04 LTS", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" } ], "ReportedName": "ubuntu", "ReportedVersion": "20.04" }, { "Name": "Custom", "Id": "Custom", "Type": "Linux", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12" }, { "Name": "Chef", "Version": "11.10" }, { "Name": "Chef", "Version": "11.4" }, { "Name": "Chef", "Version": "0.9" } ] }, { "Name": "CustomWindows", "Id": "CustomWindows", "Type": "Windows", "ConfigurationManagers": [ { "Name": "Chef", "Version": "12.2" } ] } ] } ``` **Topics** + [Linux 作業系統](workinginstances-os-linux.md) + [Microsoft Windows Server](workinginstances-os-windows.md) # Linux 作業系統 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 支援下列 Linux 作業系統的 64 位元版本。 + [Amazon Linux](https://aws.amazon.com/amazon-linux-ami/faqs/) 和 [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/) （請參閱 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)以取得目前支援的版本） + [Ubuntu 20.04 LTS](https://wiki.ubuntu.com/FocalFossa/ReleaseNotes) + [CentOS 7 (CentOS 7)](https://docs.centos.org/en-US/centos/install-guide/Revision_History/) + [Red Hat Enterprise Linux 7](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/) 您也可以根據這些作業系統使用[自訂 AMI](workinginstances-custom-ami.md)。下列為 Linux 執行個體的一般注意事項： **支援的套件版本** 支援的套件 (例如 Ruby) 版本和修補程式層級，取決於下列各節中所述的作業系統和版本。 **更新** 根據預設， OpsWorks Stacks 會在執行個體開機`apt-get update`後自動呼叫 `yum update`或，以確保 Linux 執行個體具有最新的安全修補程式。若要停用自動更新，請使用 [CreateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html)、[UpdateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html)、[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html) 或 [UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html) 動作，或同等的 [AWS 開發套件](https://aws.amazon.com/tools/)方法或 [AWS CLI](https://aws.amazon.com/documentation/cli/) 命令，將 `InstallUpdatesOnBoot` 參數設定為 `false`。為了避免服務中斷， OpsWorks Stacks 不會在執行個體上線後自動安裝更新。您可以執行 [Upgrade Operating System (升級作業系統) 堆疊命令](workingstacks-commands.md)，隨時手動更新線上執行個體的作業系統。如需如何管理安全性更新的詳細資訊，請參閱[管理安全性更新](workingsecurity-updates.md)。如需進一步了解 OpsWorks Stacks 如何更新執行個體，請根據其中一個支援的作業系統建立自訂 AMI。例如，您可以使用自訂 AMI 來指定要在執行個體上安裝哪些套件版本。每個 Linux 發行版本都有不同的支援時程和套件合併政策，因此您應該考慮哪種方法最符合您的需求。如需詳細資訊，請參閱[使用自訂 AMI](workinginstances-custom-ami.md)。 **主機檔案** 每個線上執行個體都有一個將 IP 地址映射至主機名稱`/etc/hosts`的檔案。 OpsWorks Stacks 包含每個執行個體`hosts`檔案中堆疊所有線上執行個體的公有和私有地址。例如，假設您的堆疊有兩個 Node.js App Server 執行個體，即 nodejs-app1 和 nodejs-app2，以及一個 MySQL 執行個體，db-master1。nodejs-app1 執行個體的 `hosts` 檔案看起來如下列範例，而另一個執行個體則會有類似的 `hosts` 檔案。 ``` ... # OpsWorks Layer State 192.0.2.0 nodejs-app1.localdomain nodejs-app1 10.145.160.232 db-master1 198.51.100.0 db-master1-ext 10.243.77.78 nodejs-app2 203.0.113.0 nodejs-app2-ext 10.84.66.6 nodejs-app1 192.0.2.0 nodejs-app1-ext ``` **OpsWorks Stacks 代理程式代理支援** Chef 11.10 OpsWorks 和更新版本堆疊的 Stacks 代理程式包含代理伺服器的基本支援，通常與隔離VPCs 搭配使用。若要啟用代理伺服器支援，執行個體必須具備 `/etc/environment` 檔案以提供適當的 HTTP 和 HTTPS 流量設定。此檔案應該會如下列所示；請將反白的文字取代為您的代理伺服器 URL 和連接埠： ``` http_proxy="http://myproxy.example.com:8080/" https_proxy="http://myproxy.example.com:8080/" no_proxy="169.254.169.254" ``` 若要啟用代理支援，我們建議您[建立自訂 AMI](workinginstances-custom-ami.md)，以包含適當的 `/etc/environment` 檔案，並使用該 AMI 來建立您的執行個體。我們不建議使用自訂配方在您的執行個體上建立 `/etc/environment` 檔案。在任何自訂配方執行之前， OpsWorks Stacks 在設定程序的早期需要代理伺服器資料。 **Topics** + [Amazon Linux](#workinginstances-os-amazon) + [Ubuntu LTS](#workinginstances-os-linux-ubuntu) + [CentOS](#workinginstances-os-linux-centos) + [Red Hat Enterprise Linux](#workinginstances-os-linux-rhel) ## Amazon Linux OpsWorks Stacks 支援 Amazon Linux 和 Amazon Linux 2 的 64 位元版本。除了定期更新和修補程式，Amazon Linux 大約每六個月會發行新版本，其中涉及大量變更。當您建立堆疊或新執行個體時，您必須指定要使用的 Amazon Linux 版本。當 AWS 發行新版本時，您的執行個體會繼續執行指定的版本，直到您明確變更版本為止。當新的 Amazon Linux 版本發行之後，會有四週的遷移期間，在這段期間，AWS 會持續提供舊版本的定期更新。遷移期間結束之後，您的執行個體可以繼續執行舊版本，但 AWS 不會提供進一步的更新。如需詳細資訊，請參閱 [Amazon Linux AMI 常見問答集](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)。當新的 Amazon Linux 版本發行之後，建議您在遷移期間內更新至新版本，以讓執行個體持續接收安全性更新。在您更新生產堆疊的執行個體之前，建議您先啟動新的執行個體，並確認應用程式可在新版本上正確執行。接著，您即可更新生產堆疊的執行個體。 **注意** 根據預設，當新的 Amazon Linux 版本發行時，以其為依據的自訂 AMI 會自動更新到該版本。建議作法是將自訂 AMI 鎖定為特定 Amazon Linux 版本，以便將更新延遲直到您測試過新版本為止。如需詳細資訊，請參閱[如何將 AMI 鎖定為特定版本？](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)。如果您使用 CloudFormation 範本建立具有執行 Amazon Linux 之執行個體的堆疊，範本應明確指定 Amazon Linux 版本。尤其是，若您的範本指定 `Amazon Linux`，執行個體會持續執行 2016.09 版本。如需詳細資訊，請參閱 [AWS::OpsWorks::Stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworks-stack.html) 及 [AWS::OpsWorks::Instance](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-opsworks-instance.html)。若要更新執行個體的 Amazon Linux 版本，請執行下列其中一項作業： + 針對線上執行個體，執行 [**Upgrade Operating System (升級作業系統)** 堆疊命令](workingstacks-commands.md)。當新的 Amazon Linux 版本可用時，**Instances (執行個體)** 和 **Stack (堆疊)** 頁面會顯示一則通知與連結，以帶您前往 **Run Command (執行命令)** 頁面。然後，您可以執行 **Upgrade Operating System (升級作業系統)** 以升級執行個體。 + 對於離線 Amazon Elastic Block Store 後端 (EBS 後端）執行個體，啟動執行個體並執行**升級作業系統**，如上述陳述式所述。 + 針對離線的執行個體存放區後端執行個體 (包括時間式和負載式執行個體)，請[編輯執行個體的 **Operating system (作業系統)** 設定](workinginstances-properties.md)以指定新的版本。 OpsWorks Stacks 會在執行個體重新啟動時，自動將執行個體更新為新版本。 **Amazon Linux：支援的 Node.js 版本** | Amazon Linux 版本 | Node.js 版本 | | --- | --- | |

(Not applicable to operating systems that are available for Chef 12 and higher stacks only)

| |

2018.03

0.12.18

| |

2017.09

0.12.18

| |

2017.03

0.12.18

| |

2016.09

0.12.18
0.12.17
0.12.16
0.12.15

| |

2016.03

0.12.18
0.12.17
0.12.16
0.12.15
0.12.14
0.12.13
0.12.12
0.12.10

| **Amazon Linux：支援的 Chef 版本** | Chef 版本 | 支援的 Amazon Linux 版本 | | --- | --- | |

Amazon Linux 2
Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03

| |

11.10

Amazon Linux 2018.03
Amazon Linux 2017.09
Amazon Linux 2017.03
Amazon Linux 2016.09
Amazon Linux 2016.03

| |

11.4 (deprecated)

Amazon Linux 2016.09
Amazon Linux 2016.03

| **重要** 更新 t1.micro 執行個體之前，請確認它們具備 `/var/swapfile` 暫時置換檔。Chef 0.9 堆疊上的 t1.micro 執行個體不具備置換檔。若是 Chef 11.4 和 Chef 11.10 堆疊，最新版本的執行個體代理程式會自動為 t1.micro 執行個體建立置換檔。不過，這項變更已推出數週，因此如果執行個體大約是在 2014 年 3 月 24 日前建立，您應該檢查其中是否具備 `/var/swapfile`。如果 t1.micro 執行個體缺少置換檔，您可以建立一個置換檔，如下所示：若是 Chef 11.10 和更新版本的堆疊，請建立新的 t1.micro 執行個體，其中即會自動含有置換檔。若是 Chef 0.9 堆疊，請以根使用者的身分在每個執行個體上執行下列命令。 ``` dd if=/dev/zero of=/var/swapfile bs=1M count=256 mkswap /var/swapfile chown root:root /var/swapfile chmod 0600 /var/swapfile swapon /var/swapfile ``` 如果您不想建立新的執行個體，也可以在 Chef 11.10 和更新版本的堆疊上使用這些命令。 ## Ubuntu LTS Ubuntu 約每兩年會發行新的 Ubuntu LTS 版本，每個版本約支援 5 年。Ubuntu 會在作業系統支援期間提供安全性修補程式和更新。如需詳細資訊，請參閱 [LTS - Ubuntu Wiki](https://wiki.ubuntu.com/LTS)。 + 您不能將現有 Ubuntu 執行個體更新到較新版本的 Ubuntu。您必須[建立新的 Ubuntu 執行個體](workinginstances-add.md)，並[刪除較舊的執行個體](workinginstances-delete.md)。 + 只有 Chef 12 和更新版本的堆疊支援 Ubuntu 20.04 LTS。 ## CentOS OpsWorks Stacks 支援 64 位元版本的 [CentOS 7](https://docs.centos.org/en-US/docs/)。最初支援的版本是 CentOS 7，而 CentOS 約每兩年會發行新版本。當您在 CentOS 堆疊中啟動新執行個體時， OpsWorks Stacks 會自動安裝最新的 CentOS 版本。由於發行新的 CentOS OpsWorks 次要版本時，Stacks 不會自動更新現有執行個體上的作業系統，因此新建立的執行個體可能會收到比堆疊現有執行個體更新的版本。為了保持堆疊間的版本一致性，您可以將現有的執行個體更新至目前的 CentOS 版本，如下所示： + 針對線上執行個體，請執行 [**Upgrade Operating System (升級作業系統)** 堆疊命令](workingstacks-commands.md)，其會在指定執行個體上執行 `yum update` 以將其更新至目前的版本。當新的 CentOS 7 次要版本可用時，**Instances (執行個體)** 和 **Stack (堆疊)** 頁面會顯示一則通知與連結，以帶您前往 **Run Command (執行命令)** 頁面。然後，您可以執行 **Upgrade Operating System (升級作業系統)** 以升級執行個體。 + 對於離線 Amazon EBS 支援的執行個體，啟動執行個體並執行**升級作業系統**，如上述清單項目所述。 + 對於離線執行個體後端執行個體， OpsWorks Stacks 會在執行個體重新啟動時自動安裝新版本。 **CentOS：支援的 Chef 版本** | Chef 版本 | 支援的 CentOS 版本 | | --- | --- | |

CentOS 7

| |

11.10

(None supported)

| |

11.4 (deprecated)

(None supported)

| **注意** OpsWorks Stacks 支援適用於 CentOS 執行個體的 Apache 2.4。 ## Red Hat Enterprise Linux OpsWorks Stacks 支援 64 位元版本的 [Red Hat Enterprise Linux 7](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/) (RHEL 7)。最初支援的版本是 RHEL 7.1，而 Red Hat 約每九個月會發行新的次要版本。次要版本應與 RHEL 7.0 相容。如需詳細資訊，請參閱[生命週期和更新政策](https://access.redhat.com/support/policy/update_policies)。當您啟動新的執行個體時， OpsWorks Stacks 會自動安裝目前的 RHEL 7 版本。由於發行新的 RHEL OpsWorks 7 次要版本時，Stacks 不會自動更新現有執行個體上的作業系統，因此新建立的執行個體可能會收到比堆疊現有執行個體更新的版本。為了保持堆疊間的版本一致性，您可以將現有的執行個體更新至目前的 RHEL 7 版本，如下所示： + 針對線上執行個體，請執行 [**Upgrade Operating System (升級作業系統)** 堆疊命令](workingstacks-commands.md)，其會在指定執行個體上執行 `yum update` 以將其更新至目前的版本。當新的 RHEL 7 次要版本可用時，**Instances (執行個體)** 和 **Stack (堆疊)** 頁面會顯示一則通知與連結，以帶您前往 **Run Command (執行命令)** 頁面。然後，您可以執行 **Upgrade Operating System (升級作業系統)** 以升級執行個體。 + 對於離線 Amazon EBS 支援的執行個體，啟動執行個體並執行**升級作業系統**，如上述清單項目所述。 + 對於離線執行個體後端執行個體， OpsWorks Stacks 會在執行個體重新啟動時自動安裝新版本。 **Red Hat Enterprise Linux：支援的 Node.js 版本** | RHEL 版本 | Node.js 版本 | | --- | --- | |

(Node.js versions only apply to Chef 11.10 stacks)
0.8.19
0.8.26
0.10.11
0.10.21
0.10.24
0.10.25
0.10.27
0.10.29
0.10.40
0.12.10
0.12.12
0.12.13
0.12.15

| **Red Hat Enterprise Linux：支援的 Chef 版本** | Chef 版本 | 支援的 RHEL 版本 | | --- | --- | |

Red Hat Enterprise Linux 7

| |

11.10

Red Hat Enterprise Linux 7

| |

11.4 (deprecated)

(None supported)

| 所有早於 0.10.40 的 Node.js 版本都已棄用。 0.12.7 和 0.12.9 也已棄用。 **注意** OpsWorks Stacks 支援 RHEL 7 執行個體的 Apache 2.4。 # Microsoft Windows Server **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。下列備註說明 OpsWorks Stacks 對 Windows 執行個體的支援。Windows 執行個體僅適用於 Chef 12.2 堆疊。Windows 堆疊中的 Chef 明確版本為 12.22。目前，Stacks OpsWorks 代理程式無法安裝在使用**英文 - 美國 **(en-US) 以外系統 UI 語言的 Windows 執行個體上，且 OpsWorks Stacks 無法管理。 **版本** OpsWorks Stacks 支援下列 Windows 64 位元版本： + Microsoft Windows Server 2022 基礎 + Microsoft Windows Server 2022 搭配 SQL Server Express + Microsoft Windows Server 2022 搭配 SQL Server Standard + Microsoft Windows Server 2022 搭配 SQL Server Web + Microsoft Windows Server 2019 Base + Microsoft Windows Server 2019 搭配 SQL Server Express + Microsoft Windows Server 2019 搭配 SQL Server Standard + Microsoft Windows Server 2019 搭配 SQL Server Web **建立執行個體** 您可以使用 Stacks OpsWorks 主控台、API 或 CLI 建立 Windows 執行個體。Windows 執行個體為 Amazon EBS 後端，但您無法掛載額外的 Amazon EBS 磁碟區。 Windows 堆疊可以使用[全年無休](workinginstances-starting.md)執行個體；您可以手動將其啟動和停止。也可以使用[時間式自動擴展功能](workinginstances-autoscaling-timebased.md)，根據使用者指定的排程自動啟動和停止執行個體。以 Windows 為基礎的堆疊無法使用[負載式自動擴展功能](workinginstances-autoscaling-loadbased.md)。您無法向堆疊[註冊在 Stacks 外部建立的 Windows 執行個體](registered-instances.md)。 OpsWorks **更新** AWS 會更新 Windows AMI 的每組修補程式，因此當您建立執行個體時，執行個體即具備最新的更新。不過， OpsWorks Stacks 不提供將更新套用至線上 Windows 執行個體的方法。若要確保 Windows 為最新狀態，最簡單的方法是定期取代您的執行個體，讓它們始終執行最新的 AMI。 **層** 若要處理安裝軟體、設定軟體或部署應用程式等任務，您需要使用自訂配方實作一或多個[自訂 layer](workinglayers-custom.md)。 **Chef** Windows 執行個體會使用 Chef 12.22 並執行[本機模式中的 chef-client](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)，以啟動名稱為 [chef-zero](https://docs.chef.io/ctl_chef_client.html#about-chef-zero) 的本機記憶體內 Chef 伺服器。此伺服器的存在可讓自訂配方使用 Chef 搜尋和資料包。 **遠端登入** OpsWorks Stacks 為授權的 IAM 使用者提供可用於登入 Windows 執行個體的密碼。此密碼會在指定的時間後過期。管理員可以使用 SSH 金鑰對擷取執行個體的管理員密碼，該密碼提供不受限制的 [RDP 存取權](workinginstances-rdp.md)。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。 **AWS 開發套件** OpsWorks Stacks 會自動在每個執行個體[適用於 .NET 的 AWS SDK](https://aws.amazon.com/sdk-for-net/)上安裝。此套件包含 AWS .NET 程式庫和適用於 Windows 的 AWS 工具 (包括 [適用於 PowerShell 的 AWS 工具](https://aws.amazon.com/powershell/))。若要使用 Ruby 軟體開發套件，您可以使用自訂配方來安裝適當的 Gem 套件。 **監控與指標** Windows 執行個體支援標準 [Amazon CloudWatch (CloudWatch) 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html)，您可以在 CloudWatch 主控台中檢視。 **Ruby** Stacks 在 Windows 執行個體上安裝的 Chef 12.22 OpsWorks 用戶端隨附 Ruby 2.3.6。不過， OpsWorks Stacks 不會將可執行檔的目錄新增至 PATH 環境變數。若要讓應用程式使用此 Ruby 版本，您通常可以在 `C:\opscode\chef\embedded\bin\` 中找到它。 **OpsWorks Stacks 代理程式 CLI** Windows 執行個體上的 OpsWorks Stacks 代理程式不會公開[命令列界面](agent.md)。 **代理支援** 若要設定 Windows 執行個體的代理支援，請執行下列作業： 1. 修改 `machine.config` 以新增下列項目，將代理支援新增至 Windows PowerShell （初始引導）和 .NET (OpsWorks Stacks 代理程式）應用程式： ``` ``` 1. 執行下列命令來設定環境變數，供 Chef 和 Git 日後使用： ``` setx /m no_proxy "localhost,169.254.169.254" setx /m http_proxy "http://10.100.1.91:3128" setx /m https_proxy "http://10.100.1.91:3128" ``` **注意** 如需進一步了解 OpsWorks Stacks 如何更新執行個體，請建立以 Microsoft Windows Server 2022 Base 為基礎的自訂 AMI。例如，您可以使用自訂 AMI 來指定要在執行個體上安裝哪些軟體，例如 Web 伺服器 (IIS)。如需詳細資訊，請參閱[使用自訂 AMI](workinginstances-custom-ami.md)。 # 將執行個體新增至 Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在您建立 layer 之後，通常會新增至少一個執行個體。如果目前集合無法處理負載，則您稍後可以新增多個執行個體。您也可以使用[負載類型或時間類型執行個體](workinginstances-autoscaling.md)自動擴展執行個體數目。您可以將新的或現有執行個體新增至 layer： + **New**–OpsWorks 會建立新的執行個體，並根據您的規格設定，使其成為 layer 的成員。 + **現有** – 您可以從任何相容的 layer 新增現有執行個體，但必須處於離線（已停止）狀態。如果執行個體屬於多 layer，則 OpsWorks Stacks 會在發生生命週期事件時，或執行 [stack](workingstacks-commands.md) 或 [deployment](workingapps-deploying.md) 命令時，執行執行個體每個 layer 的配方。您也可以編輯執行個體的組態，讓執行個體成為多 layer 的成員。如需詳細資訊，請參閱[編輯執行個體組態](workinginstances-properties.md)。 **將新的執行個體新增至 layer** 1. 在 **Instances (執行個體)** 頁面上，選擇適當 layer 的 **\$1Instance (\$1執行個體)**，並視需要選擇 **New (新建)** 標籤。如果您不只是想要設定 **Host name (主機名稱)**、**Size (大小)** 和 **Subnet (子網路)** 或 **Availability Zone (可用區域)**，則請選擇 **Advanced >> (進階 >>)** 查看其他選項。以下顯示一組完整的選項： ![\[Instances (執行個體) 頁面上新執行個體的 +Instance (+執行個體)\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add_instance.png) 1. 如有需要，您可以覆寫預設組態，而其中大多數都是您在建立堆疊時指定。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **Hostname (主機名稱)** 識別網路上的執行個體。根據預設， OpsWorks Stacks 會使用您在建立堆疊時指定的**主機名稱主題**來產生每個執行個體的主機名稱。您可以覆寫此值，並指定您慣用的主機名稱。 **大小** Amazon EC2 執行個體類型，指定執行個體的資源，例如記憶體數量或虛擬核心數量。 OpsWorks Stacks 會指定每個執行個體的預設大小，您可以使用您偏好的執行個體類型覆寫。 Stacks OpsWorks 支援的執行個體類型取決於堆疊是否在 VPC 中。若您的帳戶使用 AWS 免費方案，執行個體類型也會受限。下拉式 **Size (大小)** 清單會顯示您堆疊所支援 Chef 版本的支援執行個體類型。請注意，微型執行個體 (例如 t1.micro) 的資源可能不足，無法支援一些 layer。如需詳細資訊，請參閱 [ 執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。如果您使用[負載平衡執行個體](workinginstances-autoscaling-loadbased.md)，請注意，[設定生命週期事件](workingcookbook-events.md)可以產生可能持續一分鐘或更久的重要 CPU 負載峰值。如果執行個體較小，則此負載峰值就足以觸發向上擴展，特別是具有頻繁設定事件的大型負載平衡堆疊。下列一些方法可以減少設定事件造成不必要向上調整的可能性。 + 使用較大的執行個體，因此，設定事件的額外負載不足以觸發向上調整。 + 不使用執行個體類型 (例如共享 CPU 資源的 T2)。這確保在發生設定事件時，執行個體的所有 CPU 資源都立即可用。 + 讓 `exceeded threshold` 時間遠大於處理設定事件所需的時間，可能是 5 分鐘。如需詳細資訊，請參閱[使用自動負載型擴展](workinginstances-autoscaling-loadbased.md)。 **Availability Zone/Subnet (可用區域/子網路)** 如果堆疊不在 VPC 中，則此設定的標籤為 **Availability Zone (可用區域)**，並列出區域 (region) 的區域 (zone)。您可以使用此設定來覆寫您在建立堆疊時所指定的預設可用區域。如果堆疊正在 VPC 中執行，則此設定的標籤為 **Subnet (子網路)**，並列出 VPC 的子網路。您可以使用此設定來覆寫您在建立堆疊時所指定的預設子網路。根據預設， OpsWorks Stacks 會列出子網路的 CIDR 範圍。若要讓清單更易讀，請使用 VPC 主控台或 API 將標籤新增至每個子網路，並將**金鑰**設定為 **Name**，並將**值**設定為子網路的名稱。 OpsWorks Stacks 會將該名稱附加至 CIDR 範圍。在上述範例中，子網路的 Name (名稱) 標籤已設為 **Private**。 **Scaling Type (擴展類型)** 判斷執行個體的啟動和停止方式。 + 預設值為 **24/7 (全年無休)** 執行個體，您可以手動將其啟動和停止。 + OpsWorks Stacks 會根據指定的排程啟動和停止以**時間為基礎的**執行個體。 + （僅限 Linux) OpsWorks Stacks 會根據指定的**負載指標啟動和停止負載型**執行個體。您無法自行啟動或停止負載類型或時間類型執行個體。反之，您可以設定執行個體，而 OpsWorks Stacks 會根據組態啟動和停止執行個體。如需詳細資訊，請參閱[使用時間型和負載型執行個體管理負載](workinginstances-autoscaling.md)。 **SSH 金鑰** Amazon EC2 金鑰對。 OpsWorks Stacks 會在執行個體上安裝公有金鑰。 + 針對 Linux 執行個體，您可以搭配使用對應的私有金鑰與 SSH 用戶端來[登入執行個體](workinginstances-ssh.md)。 + 針對 Windows 執行個體，您可以使用對應的私有金鑰來[擷取執行個體的管理員密碼](workinginstances-rdp.md#workinginstances-rdp-admin)。您接著可以搭配使用該密碼與 RDP，以管理員身分登入執行個體。一開始，此設定是您在建立堆疊時所指定的 **Default SSH key (預設 SSH 金鑰)** 值。 + 如果預設值設定為**不使用預設 SSH 金鑰**，您可以指定帳戶的其中一個 Amazon EC2 金鑰。 + 如果預設值設定為 Amazon EC2 金鑰，您可以指定不同的金鑰或無金鑰。 **作業系統** **作業系統**指定執行個體正在執行的作業系統。 OpsWorks Stacks 僅支援 64 位元作業系統。一開始，此設定是您在建立堆疊時所指定的 **Default operating system (預設作業系統)** 值。您可以覆寫預設值，以指定不同的 Linux 作業系統或自訂 Amazon Machine Image (AMI)。不過，您無法從 Linux 切換至 Windows，或從 Windows 切換至 Linux。如果您選取 **Use custom AMI (使用自訂 AMI)**，則此頁面會顯示自訂 AMI 清單，而非 **Architecture (架構)** 和 **Root device type (根設備類型)**。 ![\[Instances (執行個體) 頁面上新執行個體的 +Instance (+執行個體)\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add_instance_ami.png) 如需詳細資訊，請參閱[使用自訂 AMI](workinginstances-custom-ami.md)。 **OpsWorks Agent version (OpsWorks 代理程式版本)** **OpsWorks 代理程式版本**會指定您要在執行個體上執行的 OpsWorks Stacks 代理程式版本。如果您希望 OpsWorks Stacks 自動更新代理程式，請選擇 **Inherit from stack (繼承自堆疊)**。若要安裝代理程式的特定版本，並手動更新執行個體上的代理程式，請從下拉式清單中選擇版本。並非所有代理程式版本都會使用所有作業系統版本。如果您的執行個體正在執行代理程式，或您在執行個體作業系統上未完全支援的執行個體上安裝代理程式，則 OpsWorks Stacks 主控台會顯示錯誤訊息，指示您安裝相容的代理程式。 **租用** 選擇您執行個體的租用選項。您可以選擇在專供您使用的實體伺服器上執行執行個體。 + **Default - Rely on VPC settings (預設 - 依賴 VPC 設定)**。無租用，或繼承您 VPC 中的租用設定。 + **Dedicated - Run a dedicated instance (專用 - 執行專用執行個體)**。依時數為單一租戶硬體上執行的執行個體付費。如需詳細資訊，請參閱《Amazon VPC 使用者指南》中的[專用執行個體](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/dedicated-instance.html)，以及 [Amazon EC2 專用執行個體](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/)。 + **Dedicated host - Run this instance on a dedicated host (專用主機 - 在專用主機上執行此執行個體)**。付費使用專供您執行執行個體的實體主機，並使用您現有的每個通訊端、每個核心或每個 VM 軟體的授權，以降低成本。如需詳細資訊，請參閱 [Amazon EC2 文件中的專用主機概觀](https://aws.amazon.com/ec2/dedicated-hosts/)，以及 [Amazon EC2 專用主機](https://aws.amazon.com/ec2/dedicated-hosts/)。 Amazon EC2 **Root device type (根設備類型)** 指定執行個體的根設備儲存體。 + Linux 執行個體可以是 Amazon EBS 後端或執行個體存放區後端。 + Windows 執行個體必須為 Amazon EBS 後端。如需詳細資訊，請參閱[儲存體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)。初次開機後，Amazon EBS 支援的執行個體開機速度會比執行個體存放區支援的執行個體更快，因為 OpsWorks Stacks 不需要從頭重新安裝執行個體的軟體。如需詳細資訊，請參閱[根設備儲存](best-practices-storage.md)。 **磁碟區類型** 指定根設備磁碟區類型：**Magnetic (磁性)**、**Provisioned IOPS (SSD) (佈建 IOPS (SSD))** 或 **General Purpose (SSD) (一般用途 (SSD))**。如需詳細資訊，請參閱 [Amazon EBS 磁碟區類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。 **磁碟區大小** 指定所指定磁碟區類型的根設備磁碟區大小。如需詳細資訊，請參閱 [Amazon EBS 磁碟區類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。 + **General Purpose (SSD) (一般用途 (SSD))**。最小允許大小為 8 GiB，最大大小為 16384 GiB。 + **Provisioned IOPS (SSD) (佈建 IOPS (SSD))**。最小允許大小為 8 GiB，最大大小為 16384 GiB。您可以設定每秒最少 100 個輸入/輸出操作 (IOPS)，最多則為 240 個 IOPS。 + **磁帶**. 最小允許大小為 8 GiB，最大大小為 1024 GiB。 1. 選擇 **Add Instance (新增執行個體)** 建立新的執行個體。 **注意** 當您建立執行個體時，無法覆寫[堆疊預設代理程式版本](workingstacks-creating.md#workingstacks-creating-advanced-agent)設定。若要指定自訂代理程式版本設定，您必須建立執行個體，然後[編輯其組態](workinginstances-properties.md)。 **將現有執行個體新增至 layer** 1. 在 **Instances (執行個體)** 頁面上，選擇適當 layer 的 **\$1Instance (\$1執行個體)**，然後開啟 **Existing (現有)** 標籤。 **注意** 如果您不想要使用現有執行個體，則請選擇 **New (新建)** 建立新的執行個體，如之前程序中所述。 1. 在 **Existing (現有)** 標籤上，從清單中選取執行個體。 1. 選擇 **Add Instance (新增執行個體)** 建立新的執行個體。執行個體代表 Amazon EC2 執行個體，但基本上只是 Stacks OpsWorks 資料結構。執行個體必須開始建立執行中的 Amazon EC2 執行個體，如以下各節所述。 **重要** 如果您將執行個體啟動到預設 VPC，則必須小心地修改 VPC 組態。執行個體必須一律能夠與 OpsWorks Stacks 服務、Amazon S3 和套件儲存庫通訊。例如，如果您移除預設閘道，執行個體將失去與 Stacks OpsWorks 服務的連線，然後會將執行個體視為失敗並[自動修復](workinginstances-autohealing.md)。不過， OpsWorks Stacks 將無法在修復的執行個體上安裝執行個體代理程式。如果沒有代理程式，則執行個體無法與服務通訊，而且啟動程序無法離開 `booting` 狀態。如需預設 VPC 的詳細資訊，請參閱[支援的平台](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html)。您也可以將 Linux 運算資源整合到在 Stacks OpsWorks 外部建立的堆疊中： + 您使用 Amazon EC2 主控台、CLI 或 API 直接建立的 Amazon EC2 執行個體。 + 在您自己的硬體上執行的「現場部署」**執行個體，包括在虛擬機器中執行的執行個體。如需詳細資訊，請參閱[使用在 OpsWorks Stacks 之外建立的運算資源](registered-instances.md)。 # 使用自訂 AMI **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 支援兩種自訂執行個體的方式：自訂 [Amazon Machine Image (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 和 Chef 配方。這兩種方法都可讓您控制所安裝的套件和套件版本、其設定方式，以此類推。不過，每種方法都有不同的優點，因此最好的方法取決於您的需求。以下是考慮使用自訂 AMI 的主要原因： + 您想要預先綁定特定套件，而不是在啟動執行個體之後安裝它們。 + 您想要控制套件更新的時間，以提供 layer 的一致基礎映像。 + 您想要盡快啟動執行個體 (特別是[負載類型](workinginstances-autoscaling.md)執行個體)。以下是考慮使用 Chef 配方的主要原因： + 它們比自訂 AMI 更具彈性。 + 它們更容易更新。 + 它們可以在執行中執行個體上執行更新。實際上，最佳解決方案可能是這兩種方法的組合。如需配方的詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。 **Topics** + [自訂 AMIs 如何使用 OpsWorks Stacks](#workinginstances-custom-ami-work) + [為 OpsWorks Stacks 建立自訂 AMI](#workinginstances-custom-ami-create) ## 自訂 AMIs 如何使用 OpsWorks Stacks 若要為您的執行個體指定自訂 AMI，請在建立新執行個體時，選取**使用自訂 AMI** 做為執行個體的作業系統。 OpsWorks 堆疊接著會顯示堆疊區域中自訂 AMIs。如需詳細資訊，請參閱[將執行個體新增至 Layer](workinginstances-add.md)。 **注意** 您無法將特定自訂 AMI 指定為堆疊的預設作業系統。您可以將 `Use custom AMI` 設定為堆疊的預設作業系統，但只有在將新的執行個體新增至 layer 時才能指定特定 AMI。如需詳細資訊，請參閱[將執行個體新增至 Layer](workinginstances-add.md)及[建立新的堆疊](workingstacks-creating.md)。雖然可以使用其他作業系統 (例如 CentOS 6.*x*) (從自訂或社群產生的 AMI 所建立) 建立執行個體，但並未正式受到支援。本主題討論您在建立或使用自訂 AMI 之前應該考慮的一些一般問題。 **Topics** + [啟動行為](#workinginstances-custom-ami-work-startup) + [選擇 Layer](#workinginstances-custom-ami-work-layer) + [處理應用程式](#workinginstances-custom-ami-work-apps) ### 啟動行為當您啟動執行個體時， OpsWorks Stacks 會使用指定的自訂 AMI 來啟動新的 Amazon EC2 執行個體。 OpsWorks Stacks 接著會使用 [cloud-init](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonLinuxAMIBasics.html#included-aws-command-line-tools) 在執行個體上安裝 OpsWorks Stacks 代理程式，代理程式會執行執行個體的設定配方，後面接著部署配方。執行個體上線之後，代理程式會執行堆疊中每個執行個體的設定配方 (包括新增的執行個體)。 ### 選擇 Layer Stacks OpsWorks 代理程式通常不會與已安裝的套件衝突。不過，執行個體必須是至少一個 layer 的成員。 OpsWorks Stacks 一律會執行該 layer 的配方，這可能會導致問題。您應該確切了解 layer 的配方對執行個體所執行的作業，再將具有自訂 AMI 的執行個體新增至 layer。若要查看特定 layer 類型在您執行個體上執行的配方，請開啟包含該 layer 的堆疊。然後按一下導覽窗格中的 **Layers (Layer)**，然後按一下感興趣 layer 的 **Recipes (配方)**。若要查看實際程式碼，請按一下配方名稱。 **注意** 對於 Linux AMIs，降低衝突可能性的一種方法是使用 OpsWorks Stacks 佈建和設定執行個體，這是自訂 AMI 的基礎。如需詳細資訊，請參閱[從 Stacks OpsWorks 執行個體建立自訂 Linux AMI](#workinginstances-custom-ami-create-opsworks)。 ### 處理應用程式除了套件之外，也建議您在 AMI 中包括應用程式。如果您有大型複雜應用程式，則將它包括在 AMI 中可以縮短執行個體的啟動時間。您可以在 AMI 中包含小型應用程式，但相對於讓 OpsWorks Stacks 部署應用程式，通常沒有或很少的時間優勢。其中一個選項是將應用程式包括在 AMI 中，同時[建立應用程式](workingapps-creating.md)，以將應用程式從儲存庫部署至執行個體。這種方法可縮短開機時間，同時提供方便的方法以在執行個體執行之後更新應用程式。請注意，Chef 配方為等冪操作，因此只要儲存庫中的版本與執行個體上版本相同，部署配方就不會修改應用程式。 ## 為 OpsWorks Stacks 建立自訂 AMI 若要搭配 Stacks OpsWorks 使用自訂 AMI，您必須先從自訂執行個體建立 AMI。您可以從兩個選項中選擇： + 使用 Amazon EC2 主控台或 API，根據其中一個 [OpsWorks Stacks 支援的 AMIs](workinginstances-os.md) 的 64 位元版本來建立和自訂執行個體。 + 對於 Linux AMIs，請使用 OpsWorks 根據其關聯層的組態來建立 Amazon EC2 執行個體。建立自訂 Linux AMI 之前，請在`/tmp`分割區`noexec`上停用，以允許 OpsWorks Stacks 在自訂 Linux 執行個體上安裝其代理程式。 **注意** 請注意，AMI 可能無法使用所有執行個體類型，因此請確定您的啟動中 AMI 與您計劃使用的執行個體類型相容。具體而言，[R3](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/r3-instances.html) 執行個體類型需要硬體輔助虛擬化 (HVM) AMI。然後，您可以使用 Amazon EC2 主控台或 API 從自訂執行個體建立自訂 AMI。將執行個體新增至 layer，並指定自訂 AMI，即可在相同區域的任何堆疊中使用自訂 AMI。如需如何建立利用自訂 AMI 之執行個體的詳細資訊，請參閱[將執行個體新增至 Layer](workinginstances-add.md)。 **注意** 根據預設， OpsWorks Stacks 會在開機時安裝所有 Amazon Linux 更新，為您提供最新版本。此外，Amazon Linux 大約每六個月會發行新版本，其中涉及大量變更。根據預設，當新的 Amazon Linux 版本發行時，以其為依據的自訂 AMI 會自動更新到該版本。建議作法是將自訂 AMI 鎖定為特定 Amazon Linux 版本，讓您可以將更新延遲到您測試過新版本為止。如需詳細資訊，請參閱[如何將 AMI 鎖定為特定版本？](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)。 **Topics** + [使用 Amazon EC2 建立自訂 AMI](#workinginstances-custom-ami-create-ec2) + [從 Stacks OpsWorks 執行個體建立自訂 Linux AMI](#workinginstances-custom-ami-create-opsworks) + [建立自訂 Windows AMI](#w2ab1c14c55c15c13c21c20) ### 使用 Amazon EC2 建立自訂 AMI 建立自訂 AMI 的最簡單方法是使用 Amazon EC2 主控台或 API 執行整個任務，這是 Windows AMIs 的唯一選項。如需下列步驟的詳細資訊，請參閱[建立自己的 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami.html)。 **使用 Amazon EC2 主控台或 API 建立自訂 AMI** 1. 使用其中一個 [OpsWorks Stacks 支援 AMI](workinginstances-os.md) 的 64 位元版本，來建立執行個體。 1. 從步驟 1 自訂執行個體，方法是設定執行個體、安裝套件，以此類推。請記住，會根據 AMI 以在每個執行個體上重新產生您安裝的每個項目，因此請不要包括特定執行個體特有的項目。 1. 停止執行個體，並建立自訂 AMI。 ### 從 Stacks OpsWorks 執行個體建立自訂 Linux AMI 若要使用自訂 OpsWorks 的 Stacks Linux 執行個體來建立 AMI，請注意 OpsWorks 建立的每個 Amazon EC2 執行個體都包含唯一的身分。如果您從這類執行個體建立自訂 AMI，它會包含該身分，而且所有以 AMI 為基礎的執行個體都有相同的身分。為了確保根據您自訂 AMI 的執行個體具有唯一的身分，您必須先從自訂的執行個體移除身分，再建立 AMI。 **從 Stacks OpsWorks 執行個體建立自訂 AMI** 1. [建立 Linux 堆疊](workingstacks-creating.md)，並[新增一或多 layer](workinglayers-basics-create.md)，以定義自訂執行個體的組態。您可以使用內建 layer、適當地自訂，以及完全自訂 layer。如需詳細資訊，請參閱[自訂 OpsWorks Stacks](customizing.md)。 1. [編輯 layer](workinglayers-basics-edit.md) 並停用 AutoHealing。 1. [新增具有您慣用 Linux 發行版本的執行個體](workinginstances-add.md)至一或多 layer，並[啟動它](workinginstances-starting.md)。建議使用 Amazon EBS 支援的執行個體。開啟執行個體的詳細資訊頁面，並記錄其 Amazon EC2 ID 以供稍後使用。 1. 執行個體上線時，請[使用 SSH 登入](workinginstances-ssh.md)，並根據執行個體作業系統執行接下來四個步驟之一。 1. 對於 Chef 11 或 Chef 12 堆疊中的 Amazon Linux 執行個體，或 Chef 11 堆疊中的 Red Hat Enterprise Linux 7 執行個體，執行下列動作。 1. `sudo /etc/init.d/monit stop` 1. `sudo /etc/init.d/opsworks-agent stop` 1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef` **注意** 對於 Chef 12 堆疊中的執行個體，請將下列兩個資料夾新增至此命令： `/var/chef` `/opt/chef` 1. `sudo rpm -e opsworks-agent-ruby` 1. `sudo rpm -e chef` 1. 用於 Chef 12 堆疊中的 Ubuntu 16.04 LTS 或 18.04 LTS 執行個體時，請執行下列動作。 1. `sudo systemctl stop opsworks-agent` 1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef` 1. `sudo apt-get -y remove chef` 1. `sudo dpkg -r opsworks-agent-ruby` 1. `systemctl stop apt-daily.timer` 1. `systemctl stop apt-daily-upgrade.timer` 1. `rm /var/lib/systemd/timers/stamp-apt-daily.timer` 1. `rm /var/lib/systemd/timers/stamp-apt-daily-upgrade.timer` 1. 如需 Chef 12 堆疊中其他支援的 Ubuntu 版本，執行下列動作。 1. `sudo /etc/init.d/monit stop` 1. `sudo /etc/init.d/opsworks-agent stop` 1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /var/chef /opt/chef /etc/chef` 1. `sudo apt-get -y remove chef` 1. `sudo dpkg -r opsworks-agent-ruby` 1. 對於 Chef 12 堆疊中的 Red Hat Enterprise Linux 7 執行個體，執行下列動作。 1. `sudo systemctl stop opsworks-agent` 1. `sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/ /var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc /etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/ /etc/chef /var/chef` 1. `sudo rpm -e opsworks-agent-ruby` 1. `sudo rpm -e chef` 1. 此步驟取決於執行個體類型： + 對於 Amazon EBS 後端執行個體，請使用 OpsWorks Stacks 主控台[停止執行個體](workinginstances-starting.md)並建立 AMI，如[建立 Amazon EBS 後端 Linux AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) 中所述。 + 對於執行個體後端執行個體，請依照建立[執行個體後端 Linux AMI 所述建立 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-instance-store.html)，然後使用 OpsWorks Stacks 主控台停止執行個體。當您建立 AMI 時，請務必包括憑證檔案。例如，您可以呼叫 [https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/CLTRG-ami-bundle-vol.html](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/CLTRG-ami-bundle-vol.html)命令，並將`-i`引數設為 `-i $(find /etc /usr /opt -name '*.pem' -o -name '*.crt' -o -name '*.gpg' | tr '\n' ',')`。請不要在綁定時移除 apt 公有金鑰。預設 `ec2-bundle-vol` 命令會處理此任務。 1. 返回 Stacks OpsWorks 主控台並從堆疊[刪除執行個體，](workinginstances-delete.md)以清除您的堆疊。 ### 建立自訂 Windows AMI 下列程序會為 Windows Server 2022 Base 建立自訂 AMIs。您可以在 Amazon EC2 管理主控台中選擇其他 Windows Server 作業系統。 **重要** 目前，Stacks OpsWorks 代理程式無法安裝在使用英文 - OpsWorks 美國 (en-US) 以外的系統 UI 語言的 Windows 執行個體上，也無法管理。 **** **Topics** + [使用 `Sysprep` 建立自訂 Windows AMI](#w2ab1c14c55c15c13c21c20b9) + [不使用 `Sysprep` 建立自訂 Windows AMI](#w2ab1c14c55c15c13c21c20c11) + [使用自訂 Windows AMI 新增執行個體](#w2ab1c14c55c15c13c21c20c13) #### 使用 `Sysprep` 建立自訂 Windows AMI 使用 Sysprep 建立自訂 Windows AMI 通常會導致較慢的執行個體啟動但較乾淨的程序。由於`Sysprep`活動、重新啟動、 OpsWorks 堆疊佈建和第一個 OpsWorks Stacks 執行，包括設定和組態，從建立的映像建立的執行個體第一次啟動`Sysprep`需要更多時間。完成在 Amazon EC2 主控台中建立自訂 Windows AMI 的步驟。 **使用 Sysprep 建立自訂 Windows AMI** 1. 在 Amazon EC2 主控台中，選擇**啟動執行個體**。 1. 尋找 **Microsoft Windows Server 2022 Base**，然後選擇**選取**。 1. 選擇您想要的執行個體類型，然後選擇 **Configure Instance Details (設定執行個體詳細資訊)**。變更 AMI 的組態 (包括機器名稱、儲存體和安全群組設定)。選擇**啟動**。 1. 執行個體啟動程序完成之後，請取得密碼，然後在 Windows **Remote Desktop Connection (遠端桌面連線)** 視窗中連線至執行個體。 1. 在 Windows **Start (開始)** 畫面上，選擇 **Start (開始)**，然後開始輸入 **ec2configservice**，直到結果顯示 **EC2ConfigServiceSettings** 主控台為止。開啟主控台。 1. 在**一般**索引標籤上，確定已填入**啟用 UserData 執行**核取方塊（雖然不需要此選項`Sysprep`，但 OpsWorks Stacks 必須安裝其代理程式）。清除 **Set the computer name of the instance... (設定執行個體的電腦名稱...)** 選項的核取方塊，因為此選項可能會導致 OpsWorks Stacks 的重新啟動迴圈。 1. 在**映像**索引標籤上，將**管理員密碼**設定為 **Random**，以允許 Amazon EC2 自動產生您可以使用 SSH 金鑰擷取的密碼，或**指定 **以指定您自己的密碼。會`Sysprep`儲存此設定。如果您指定自己的密碼，請將密碼存放在便利的位置。建議您不要選擇 **Keep Existing (保留現有)**。 1. 選擇 **Apply (套用)**，然後選擇 **Shutdown with Sysprep (使用 Sysprep 關機)**。出現確認提示時，選擇 **Yes (是)**。 1. 執行個體停止後，在 Amazon EC2 主控台中，在執行個體清單中的**執行個體**上按一下滑鼠右鍵，選擇**映像**，然後選擇**建立映像**。 1. 在 **Create Image (建立映像)** 頁面上，提供映像的名稱和描述，並指定磁碟區組態。完成之後，請選擇 **Create Image (建立映像)**。 1. 開啟 **Images (映像)** 頁面，並等待映像從 **pending (待定)** 階段變更為 **available (可用)**。新的 AMI 現在已可使用。 #### 不使用 `Sysprep` 建立自訂 Windows AMI 完成在 Amazon EC2 主控台中建立自訂 Windows AMI 的步驟。 **不使用 Sysprep 建立自訂 Windows AMI** 1. 在 Amazon EC2 主控台中，選擇**啟動執行個體**。 1. 尋找 **Microsoft Windows Server 2022 Base**，然後選擇**選取**。 1. 選擇您想要的執行個體類型，然後選擇 **Configure Instance Details (設定執行個體詳細資訊)**。變更 AMI 的組態 (包括機器名稱、儲存體和安全群組設定)。選擇**啟動**。 1. 執行個體啟動程序完成之後，請取得密碼，然後在 Windows **Remote Desktop Connection (遠端桌面連線)** 視窗中連線至執行個體。 1. 在執行個體上，開啟 `C:\Program Files\Amazon\Ec2ConfigService\Settings\config.xml`，並變更下列兩種設定，然後儲存和關閉檔案： + `Ec2SetPassword` 至 `Enabled` + `Ec2HandleUserData` 至 `Enabled` 1. 中斷與**遠端桌面**工作階段的連線，並返回 Amazon EC2 主控台。 1. 在 **Instances (執行個體)** 清單中，停止執行個體。 1. 在執行個體停止後，在 Amazon EC2 主控台中，以滑鼠右鍵按一下執行個體清單中**的執行個體**，選擇**映像**，然後選擇**建立映像**。 1. 在 **Create Image (建立映像)** 頁面上，提供映像的名稱和描述，並指定磁碟區組態。完成之後，請選擇 **Create Image (建立映像)**。 1. 開啟 **Images (映像)** 頁面，並等待映像從 **pending (待定)** 階段變更為 **available (可用)**。新的 AMI 現在已可使用。 #### 使用自訂 Windows AMI 新增執行個體在您的映像變更為 **available (可用)** 狀態之後，即可建立根據自訂 Windows AMI 的新執行個體。當您從 **Operating system (作業系統)** 清單中選擇 **Use custom Windows AMI (使用自訂 Windows AMI)** 時， OpsWorks Stacks 會顯示自訂 AMI 清單。 **新增根據自訂 Windows AMI 的執行個體** 1. 當您的新 AMI 可用時，請前往 OpsWorks Stacks 主控台，開啟 Windows 堆疊的**執行個體**頁面，然後選擇頁面底部附近的 **\$1 執行個體**來新增執行個體。 1. 在 **New (新增)** 標籤上，選擇 **Advanced (進階)**。 1. 在 **Operating system (作業系統)** 下拉式清單上，選擇 **Use custom Windows AMI (使用自訂 Windows AMI)**。 1. 在 **Custom AMI (自訂 AMI)** 下拉式清單上，選擇您所建立的 AMI，然後選擇 **Add Instance (新增執行個體)**。您現在可以啟動並執行執行個體。 # 手動啟動、停止和重新開機全年無休的執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 您可以 Linux 和 Windows 堆疊使用全年無休的執行個體。將全年無休執行個體新增至 layer 之後，您必須手動啟動執行個體以啟動對應的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體，並手動停止執行個體以終止 Amazon EC2 執行個體。您也可以手動重新啟動無法正常運作的執行個體。 OpsWorks Stacks 會自動啟動和停止時間型和負載型執行個體。如需詳細資訊，請參閱[使用時間型和負載型執行個體管理負載](workinginstances-autoscaling.md)。 **重要** OpsWorks Stacks 執行個體必須只在主控台中 OpsWorks 啟動、停止和重新啟動。 OpsWorks 無法辨識在 Amazon EC2 主控台中執行的啟動、停止或重新啟動操作。 **Topics** + [啟動或重新啟動執行個體](#workinginstances-starting-start) + [停止執行個體](#workinginstances-starting-stop) + [重新啟動執行個體](#workinginstances-starting-reboot) ## 啟動或重新啟動執行個體若要啟動新的執行個體，請在 **Instances (執行個體)** 頁面上，按一下執行個體 **Actions (動作)** 欄中的 **start (啟動)**。 ![\[Instances (執行個體) 頁面上的啟動動作\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/start_instance.png) 您也可以建立多個執行個體，然後按一下 **Start all Instances (啟動所有執行個體)** 同時將它們啟動。啟動執行個體之後， OpsWorks Stacks 會啟動 Amazon EC2 執行個體並啟動作業系統。啟動程序通常需要幾分鐘，而且 Windows 執行個體一般會比 Linux 執行個體慢。隨著啟動的進行，執行個體的 **Status (狀態)** 欄位會顯示下列一系列的值： 1. **requested** - OpsWorks Stacks 已呼叫 Amazon EC2 服務來建立 Amazon EC2 執行個體。 1. **待**定 - OpsWorks Stacks 正在等待 Amazon EC2 執行個體啟動。 1. **開機** - Amazon EC2 執行個體正在開機。 1. **running\$1setup** - OpsWorks Stacks 已觸發安裝事件，並正在執行 layer 的Setup配方，後面接著其Deploy配方。如需詳細資訊，請參閱[執行配方](workingcookbook-executing.md)。如果您已將[自訂技術指南](workingcookbook-installingcustom-enable.md)新增至堆疊， OpsWorks Stacks 會在執行 Setup和 Deploy配方之前，從您的儲存庫安裝目前版本。 1. **online** - 執行個體已準備就緒可供使用。當 **Status (狀態)** 變更為 **online** 時，執行個體為完全運作狀態。 + 如果 layer 有連接的負載平衡器， OpsWorks Stacks 會將執行個體新增至該 layer。 + OpsWorks Stacks 會觸發Configure事件，執行每個執行個體的Configure配方。這些配方會視需要更新執行個體，以容納新的執行個體。 + OpsWorks Stacks 會將執行個體的**啟動**動作取代為**停止**，您可以使用此動作來停止執行個體。如果執行個體未能成功啟動或設定配方失敗，則狀態會分別設為 **start\$1failed** 或 **setup\$1failed**。您可以檢查日誌以確定原因。如需詳細資訊，請參閱[偵錯和故障診斷指南](troubleshoot.md)。已停止的執行個體仍留在堆疊中，並保留所有資源。例如，Amazon EBS 磁碟區和彈性 IP 地址仍與已停止的執行個體相關聯。您可以在執行個體**的動作**欄中選擇**啟動**，以重新啟動已停止的執行個體。重新啟動已停止的執行個體會執行下列動作： + 執行個體存放區後端執行個體 – OpsWorks Stacks 會以相同的組態啟動新的 Amazon EC2 執行個體。 + Amazon EBS 後端執行個體 – OpsWorks Stacks 會重新啟動 Amazon EC2 執行個體，重新連接根磁碟區。執行個體完成開機後， OpsWorks Stacks 會安裝作業系統更新並執行 Setup 和 Deploy配方，就像初始啟動一樣。 OpsWorks Stacks 也會視需要針對重新啟動的執行個體執行下列動作。 + 重新建立彈性 IP 地址的關聯。 + 重新連接 Amazon Elastic Block Store (Amazon EBS) 磁碟區。 + 針對執行個體後端執行個體，安裝最新的技術指南版本。 Amazon EBS 後端執行個體會繼續使用存放在根磁碟區的自訂技術指南。如果您的自訂技術指南在您停止執行個體後已變更，則您必須在這些執行個體上線後，手動更新它們。如需詳細資訊，請參閱[更新自訂技術指南](workingcookbook-installingcustom-enable-update.md)。 **注意** 彈性 IP 地址與重新啟動的執行個體重新建立關聯可能需要幾分鐘的時間。請注意，執行個體的 **Elastic IP (彈性 IP)** 設定代表中繼資料，僅指出地址應與執行個體相關聯。**Public IP (公有 IP)** 設定反映執行個體的狀態，一開始可能是空的。當彈性 IP 地址與執行個體相關聯時，地址會指派給 **Public IP (公有 IP)** 設定，後面接著 (EIP)。 ## 停止執行個體在**執行個體**頁面上，按一下執行個體**動作**欄中的**停止**，通知 Stacks OpsWorks 執行關機配方並終止 EC2 執行個體。 ![\[Instances (執行個體) 頁面上的停止動作\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/stop_instance.png) 您也可以按一下 **Stop All Instances (停止所有執行個體)** 關機堆疊中的每個執行個體。在您停止執行個體之後， OpsWorks Stacks 會執行數個任務： 1. 如果執行個體的 layer 具有連接的 Elastic Load Balancing 負載平衡器， OpsWorks Stacks 會取消註冊執行個體。若 layer 支援負載平衡器的連接耗盡功能， OpsWorks Stacks 會延遲觸發 Shutdown 事件，直到連接耗盡完成。如需詳細資訊，請參閱[Elastic Load Balancing Layer](layers-elb.md)。 1. OpsWorks Stacks 會觸發執行執行個體Shutdown配方Shutdown的事件。 1. 觸發Shutdown事件後， OpsWorks Stacks 會等待指定的時間，讓Shutdown配方有時間完成，然後執行下列動作： + 終止執行個體後端執行個體，這會刪除所有資料。 + 停止 Amazon EBS 後端執行個體，這會保留根磁碟區上的資料。如需執行個體儲存體的詳細資訊，請參閱[儲存體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)。 **注意** 預設關機逾時設定為 120 秒。若您的 Shutdown 配方需要更多時間，您可以[編輯 layer 組態](workinglayers-basics-edit.md)來變更設定。您可以查看執行個體的 **Status (狀態)** 欄來監控關機程序。隨著關機進度，其會顯示以下一系列的值： 1. **終止** - OpsWorks Stacks 正在終止 Amazon EC2 執行個體。 1. **shutting\$1down** - OpsWorks Stacks 正在執行 layer 的Shutdown配方。 1. **已終止** - Amazon EC2 執行個體已終止。 1. **stopped** - 執行個體已停止。 ## 重新啟動執行個體在 **Instances (執行個體)** 頁面上，按一下未作用的執行個體名稱，開啟 details (詳細資訊) 頁面，然後按一下 **Reboot (重新開機)**。 ![\[Instances (執行個體) 頁面上的重新開機按鈕\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/reboot_instance.png) 此命令會執行相關聯 Amazon EC2 執行個體的軟重新啟動。它不會刪除執行個體的資料，即使是執行個體後端執行個體的資料，也不會觸發任何[生命週期事件](workingcookbook-events.md)。 **注意** 若要讓 OpsWorks Stacks 自動取代失敗的執行個體，請啟用自動修復。如需詳細資訊，請參閱[使用自動修復](workinginstances-autohealing.md)。 # 使用時間型和負載型執行個體管理負載 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。隨著您的傳入流量變化，您的堆疊擁有的執行個體數可能會太少而無法正常處理負載，或是超過所需數太多。您可以透過使用時間式或負載式的執行個體，自動增加或減少 layer 的執行個體，來節省時間和金錢，以讓您總有足夠的執行個體來適當處理傳入流量，而無須為不需要的容量支付費用。您無須監控伺服器負載，也無須手動啟動或停止執行個體。此外，時間式和負載式的執行個體會自動分散、擴展和平衡區域內多個可用區域的應用程式，給予您備援及延展性。自動擴展是以兩個執行個體類型為基礎，會根據不同的條件調整 layer 的線上執行個體。 + **Time-based (時間式)** 執行個體他們允許堆疊透過包含只在特定時間或特定幾天執行的執行個體，來處理遵循可預測模式的負載。例如，您可以在下午 6 點之後啟動一些執行個體，來執行每天晚上的備份任務，或是在週末流量較低時停止某些執行個體。 + **Load-based (負載式)** 執行個體他們允許堆疊透過在流量較高時啟動額外執行個體，並在流量較低時停止執行個體，來根據幾項負載指標中的任何指標來處理變動的負載。例如，當平均 CPU 使用率超過 80% 時，您可以讓 OpsWorks Stacks 啟動執行個體，並在平均 CPU 負載低於 60% 時停止執行個體。時間式和負載式執行個體都支援 Linux 堆疊，但 Windows 堆疊只能使用時間式執行個體。與您必須手動啟動和停止的全年無休執行個體不同，您不會自行啟動或停止時間式或負載式執行個體。反之，您可以設定執行個體，而 OpsWorks Stacks 會根據其組態啟動或停止執行個體。例如，您將時間型執行個體設定為依指定的排程啟動和停止。然後， OpsWorks Stacks 會根據該組態啟動和停止執行個體。常見的實務便是同時使用三種執行個體類型，如下所示。 + 一組全年無休的執行個體，處理基本負載。您通常只需啟動這些執行個體，並讓他們持續執行即可。 + 一組以時間為基礎的執行個體，Stacks OpsWorks 會開始和停止處理可預測的流量變化。例如，或您的流量在工作時間內最高，您會將時間式執行個體設為在上午啟動，並在傍晚關機。 + 一組負載型執行個體，Stacks OpsWorks 會開始和停止處理無法預測的流量變化。 OpsWorks 當負載接近堆疊全年無休和時間型執行個體的容量時，Stacks 會啟動它們，並在流量恢復正常時停止它們。如需如何使用這些擴展時間的詳細資訊，請參閱[最佳化應用程式伺服器的數目](best-practices-autoscale.md)。 **注意** 如果您已為執行個體的 layer 建立應用程式或建立自訂技術指南，則 OpsWorks Stacks 會在執行個體首次啟動時，自動將最新版本部署到時間型執行個體和負載型執行個體。不過， OpsWorks Stacks 不一定會部署最新的技術指南以重新啟動離線執行個體。如需詳細資訊，請參閱[編輯應用程式](workingapps-editing.md)及[更新自訂技術指南](workingcookbook-installingcustom-enable-update.md)。 **Topics** + [使用自動以時間為基礎的擴展](workinginstances-autoscaling-timebased.md) + [使用自動負載型擴展](workinginstances-autoscaling-loadbased.md) + [負載型擴展與自動修復有何不同](#workinginstances-autoscaling-differs) # 使用自動以時間為基礎的擴展 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。以時間為基礎的擴展可讓您控制 layer 在一週的某些時間應該有多少個執行個體上線，方法是依指定的排程啟動或停止執行個體。 OpsWorks Stacks 會每幾分鐘檢查一次，並視需要啟動或停止執行個體。您會為每個執行個體分別指定排程，如下所示： + 一天當中的時間。例如，您可以在白天執行比夜間更多的執行個體。 + 一週當中的天。例如，您可以在工作日執行比週末更多的執行個體。 **注意** 您無法指定特定日期。 **Topics** + [將以時間為基礎的執行個體新增至 layer](#workinginstances-autoscaling-timebased-add) + [設定以時間為基礎的執行個體](#workinginstances-autoscaling-timebased-configure) ## 將以時間為基礎的執行個體新增至 layer 您可以將新的時間式執行個體新增至 layer，或是使用現有的執行個體。 **新增新的時間式執行個體** 1. 在**執行個體**頁面上，選擇 **\$1 執行個體**以新增執行個體。在**新增**索引標籤上，選擇**進階**，然後選擇以**時間為基礎的**選項。 ![\[Add instance (新增執行個體) 頁面上的時間式擴展選項\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/time_based_instances.png) 1. 設定執行個體。然後選擇**新增執行個體**，將執行個體新增至 layer。 **將現有時間式執行個體新增至 layer** 1. 在以**時間為基礎的執行個體**頁面上，如果 layer 已有以時間為基礎的執行個體，請選擇 **\$1** 執行個體。否則，請選擇**新增以時間為基礎的執行個體**。然後選擇**現有**索引標籤。 ![\[將現有時間類型執行個體新增至 layer\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/time_based_instances_existing.png) 1. 在**現有**索引標籤上，從清單中選擇執行個體。清單只會顯示時間式執行個體。 **注意** 如果您改變使用現有執行個體的想法，請在**新增**索引標籤上建立新的執行個體，如上述程序所述。 1. 選擇**新增執行個體**，將執行個體新增至 layer。 ## 設定以時間為基礎的執行個體在您將時間式執行個體新增至 layer 後，您會根據以下程序設定其排程。 **設定時間式執行個體** 1. 在導覽窗格中的**執行個體**下，選擇**時間型**。 1. 填寫所需小時以下的適當方塊，以指定每個以時間為基礎的執行個體的線上期間。 + 若要每天使用相同的排程，請選擇**每天**索引標籤，然後指定線上時段。 + 若要在不同日期使用不同的排程，請選擇每天，然後選擇適當的時段。 ![\[時間類型擴展的排程\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/time_based.png) **注意** 請務必允許啟動執行個體所需的時間，且 Stacks OpsWorks 只會每隔幾分鐘檢查一次執行個體是否應該啟動或停止。例如，若執行個體在 UTC 時間 1:00 時應處於執行狀態，請在 UTC 時間 0:00 啟動它。否則， OpsWorks Stacks 可能無法啟動執行個體，直到超過 1：00 UTC 的幾分鐘，而且執行個體還需要幾分鐘才能上線。您可以執行上述步驟，隨時變更執行個體的線上時段。下次 OpsWorks Stacks 檢查時，它會使用新的排程來判斷要啟動還是停止執行個體。 **注意** 您可以透過開啟以時間為基礎的****頁面，然後選擇**新增以時間為基礎的執行個體** （如果您尚未將以時間為基礎的執行個體新增至 layer) 或 **\$1 執行個體** （如果 layer 已有一或多個以時間為基礎的執行個體），將新的以時間為基礎的執行個體新增至 layer。然後，如上述程序所述設定執行個體。 # 使用自動負載型擴展 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。負載型執行個體可讓您快速啟動或停止執行個體，以回應傳入流量的變更。 OpsWorks Stacks 使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 資料來運算每個 layer 的下列指標，代表所有 layer 執行個體的平均值： + CPU：平均 CPU 消耗，例如 80% + 記憶體：平均記憶體消耗，例如 60% + 負載：系統在一分鐘內執行的平均運算工作。您可以為任何或全部的指標定義「擴展」**和「縮小」**閾值。您也可以使用自訂 CloudWatch 警示做為閾值。跨越閾值即會觸發「擴展事件」**。您可以透過指定下列項目，來判斷 OpsWorks Stacks 回應擴展事件的方式： + 要啟動或停止的執行個體數。 + OpsWorks Stacks 在超過閾值後應該等待多久，才能開始或刪除執行個體。例如，CPU 使用率必須超過閾值至少 15 分鐘。此值可讓您忽略短暫的流量波動。 + Stacks OpsWorks 應在啟動或停止執行個體後等待多久，然後再次監控指標。您通常會希望允許足夠的時間，讓啟動的執行個體上線或停止的執行個體關機之後，再評定 layer 是否仍然超過閾值。發生擴展事件時， OpsWorks Stacks 只會啟動或停止負載型執行個體。它不會啟動或停止全年無休執行個體或時間式執行個體。 **注意** 自動負載式擴展不會建立新的執行個體。它只會啟動和停止您已建立的執行個體。因此您必須事先佈建足夠的負載式執行個體，才能處理預期的最大負載。 **建立負載式執行個體** 1. 在**執行個體**頁面上，選擇 **\$1Instance** 以新增執行個體。選擇**進階**，然後選擇**負載型**。 ![\[Add instance (新增執行個體) 頁面上的負載類型擴展選項\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/load_based_instances.png) 1. 設定執行個體，然後選擇**新增執行個體**，將執行個體新增至 layer。重複這個程序，直到您已建立足夠數目的執行個體。您可以視需要於稍後新增或移除執行個體。在您將負載式執行個體新增到 layer 後，您必須啟用負載式擴展並指定組態。負載式擴展組態為一種 layer 屬性，而非執行個體屬性，可指定 layer 應啟動或停止其負載式執行個體的時機。您必須為每個使用負載式執行個體的 layer 分別指定它。 **啟用和設定自訂負載式擴展** 1. 在導覽窗格的**執行個體**下，選擇**負載型**，然後選擇適當 layer 的**編輯**。 ![\[執行個體 layer 上的編輯動作\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/load_based.png) 1. 將**啟用負載型自動擴展**設定為**開啟**。然後設定閾值和擴展參數，定義新增或刪除執行個體的方式和時機。 ![\[負載類型擴展的閾值\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/load_based_config.png) **Layer 平均閾值** 您可以根據下列值 (所有 layer 執行個體的平均) 設定擴展的閾值。 + **平均 CPU** – 層的平均 CPU 使用率，以總數的百分比表示。 + **平均記憶體** – layer 的平均記憶體使用率，以總數的百分比表示。 + **平均負載** – layer 的平均負載。如需如何計算負載的詳細資訊，請參閱 Wikipedia 上的[負載（運算）](http://en.wikipedia.org/wiki/Load_(computing))。跨越閾值會導致擴展事件，如果需要更多執行個體，則向上擴展，如果需要較少的執行個體，則向下擴展。 OpsWorks Stacks 接著會根據擴展參數新增或刪除執行個體。 **自訂 CloudWatch 警示** 您最多可以使用五個自訂 CloudWatch 警示作為擴展或縮減閾值。他們必須位於和堆疊相同的區域中。如需如何建立自訂警示的詳細資訊，請參閱[建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/AlarmThatSendsEmail.html)。若要使用自訂警示，您必須更新您的服務角色，允許 `cloudwatch:DescribeAlarms`。您可以在第一次使用此功能時讓 OpsWorks Stacks 為您更新角色，也可以手動編輯角色。如需詳細資訊，請參閱[允許 OpsWorks Stacks 代表您採取行動](opsworks-security-servicerole.md)。當有多個警示設定為負載型組態時，如果警示處於`INSUFFICIENT_DATA`指標型警示狀態，即使另一個警示處於 `ALARM` 狀態，也無法進行負載型執行個體擴展。只有在所有警示都處於 `OK`或 `ALARM` 狀態時，才能繼續自動擴展。如需使用 Amazon CloudWatch 警示的詳細資訊，請參閱《[Amazon CloudWatch 使用者指南》中的使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。 *Amazon CloudWatch * **擴展參數** 下列參數控制 OpsWorks Stacks 如何管理擴展事件。 + **批次啟動伺服器** – 發生擴展事件時要新增或移除的執行個體數量。 + **如果超過閾值** – 在 Stacks 觸發擴展事件之前，負載必須保持超過擴展閾值或低於縮減閾值的時間量 OpsWorks （以分鐘為單位）。 + **擴展後，忽略指標 ** – 發生擴展事件後 Stacks OpsWorks 應忽略指標並抑制其他擴展事件的時間量（以分鐘為單位）。例如， OpsWorks Stacks 在升級事件之後新增執行個體，但執行個體在開機和設定之前不會開始減少負載。在新的執行個體上線並開始處理請求之前 (通常需要數分鐘)，引發其他擴展事件沒有意義。此設定可讓您命令 OpsWorks Stacks 隱藏擴展事件足夠的時間，以讓新的執行個體上線。您可以增加此設定，以防止當**平均 CPU**、**平均記憶體**或**平均負載**等圖層平均值出現暫時性分歧時，突然擺動擴展。例如，如果 CPU 用量超過限制，且記憶體用量接近縮減規模，則執行個體向上擴展事件之後可能會立即發生記憶體縮減事件。若要避免這種情況，您可以增加**擴展後忽略指標**設定的分鐘數。在此範例中，會發生 CPU 擴展，但記憶體縮減事件不會。 1. 若要新增其他負載型執行個體，請選擇 **\$1 執行個體**、設定設定，然後選擇**新增執行個體**。重複執行此作業，直到您擁有足夠的負載式執行個體處理您的預期最大負載。然後選擇 **Save** (儲存)。 **注意** 您也可以開啟負載型****頁面，然後選擇**新增負載型執行個體** （如果您尚未將負載型執行個體新增至 layer) 或 **\$1 執行個體** （如果 layer 已有一或多個負載型執行個體），將新的負載型執行個體新增至 layer。接著設定執行個體，如本節中先前部分所述。 **將現有負載式執行個體新增至 layer** 1. 在導覽窗格的**執行個體**下，選擇**負載型**。 1. 如果您已啟用層的負載型自動擴展，請選擇 **\$1 執行個體**。否則，請選擇**新增負載型執行個體**。選擇**現有**索引標籤。 ![\[將現有負載類型執行個體新增至 layer\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/load_based_instances_existing.png) 1. 在**現有**索引標籤上，選擇執行個體。清單只會顯示負載式執行個體。 **注意** 如果您改變使用現有執行個體的想法，請在**新增**索引標籤上，如上述程序所述建立新的執行個體。 1. 選擇**新增執行個體**，將執行個體新增至 layer。您可以隨時修改自動負載式擴展的組態或停用它。 **停用自動負載式擴展** 1. 在導覽窗格的**執行個體**下，選擇**負載型**，然後選擇適當 layer 的**編輯**。 1. **啟用以負載為基礎的自動擴展**至**否**。 ## 負載型擴展與自動修復有何不同自動負載式擴展使用所有執行中執行個體的平均負載指標。如果指標保持在指定的閾值之間， OpsWorks Stacks 不會啟動或停止任何執行個體。另一方面，透過自動修復，當執行個體停止回應時， OpsWorks Stacks 會自動啟動具有相同組態的新執行個體。執行個體可能會因網路問題或執行個體的一些問題而無法回應。例如，假設您的 CPU 升級閾值為 80%，且一個執行個體停止回應。 + 如果停用自動修復，且剩餘的執行中執行個體可以將平均 CPU 使用率保持在 80% 以下，則 OpsWorks Stacks 不會啟動新的執行個體。它只會在剩餘執行個體的平均 CPU 使用率超過 80% 時啟動取代用執行個體。 + 如果啟用自動修復，無論負載閾值為何， OpsWorks Stacks 都會啟動替換執行個體。 # 使用在 OpsWorks Stacks 之外建立的運算資源 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。 [執行個體](workinginstances.md) 說明如何使用 OpsWorks Stacks 來建立和管理 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體的群組。您也可以將 Linux 運算資源整合到在 Stacks OpsWorks 外部建立的堆疊中： + 您使用 Amazon EC2 主控台、CLI 或 API 直接建立的 Amazon EC2 執行個體。 + 在您自己的硬體上執行的「現場部署」**執行個體，包括在虛擬機器中執行的執行個體。這些運算資源會成為 OpsWorks Stacks 受管執行個體，您可以像一般 Stacks OpsWorks 執行個體一樣進行管理： + **管理使用者許可** – 您可以使用 [OpsWorks Stacks 使用者管理](opsworks-security-users.md)來指定允許哪些使用者存取您的堆疊、允許他們在堆疊執行個體上執行哪些動作，以及他們是否具有 SSH 存取和 sudo 權限。 + **自動化任務** – 您可以讓 OpsWorks Stacks 執行自訂 Chef 配方來執行任務，例如使用單一命令在任何或所有堆疊的執行個體上執行指令碼。如果您將執行個體指派給 [layer](workinglayers.md)， OpsWorks Stacks 會在執行個體[生命週期](workingcookbook-events.md)中的關鍵點自動在執行個體上執行一組指定的 Chef 配方，包括您的自訂配方。請注意，您只能將註冊的 Amazon EC2 執行個體指派給[自訂層](workinglayers-custom.md)。 + **管理資源** – 堆疊可讓您分組和管理中的資源 AWS 區域，而 OpsWorks 儀表板會顯示所有區域中堆疊的狀態。 + **安裝套件** – 您可以使用 Chef 配方在堆疊中的任何執行個體上安裝套件。 + **更新作業系統** – OpsWorks Stacks 提供在堆疊執行個體上安裝作業系統安全修補程式和更新的簡單方法。 + **部署應用程式** – OpsWorks Stacks 會將應用程式一致地部署到堆疊的所有應用程式伺服器執行個體。 + **監控** – OpsWorks Stacks 會建立自訂 [CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) 指標來監控堆疊的所有執行個體。如需定價資訊，請參閱 [AWS OpsWorks 定價](https://aws.amazon.com/opsworks/stacks/pricing/)。以下是使用已註冊執行個體的基本程序。 1. 向堆疊註冊執行個體。執行個體現在是堆疊的一部分，並由 Stacks OpsWorks 管理。 1. (選擇性) 將執行個體指派給某 layer。此步驟可讓您充分利用 OpsWorks Stacks 管理功能。您可以將已註冊的內部部署執行個體指派給任何 layer；已註冊的 Amazon EC2 執行個體只能指派給自訂 layer。 1. 使用 OpsWorks Stacks 管理執行個體。 1. 當您不再需要堆疊中的執行個體時，請將其取消註冊，這會從 Stacks OpsWorks 中移除執行個體。下列各節將詳細說明此程序。 **Topics** + [向 OpsWorks Stacks Stack 註冊執行個體](registered-instances-register.md) + [管理已註冊的執行個體](registered-instances-manage.md) + [將已註冊的執行個體指派給某 Layer](registered-instances-assign.md) + [取消指派已註冊的執行個體](registered-instances-unassign.md) + [取消註冊已註冊的執行個體](registered-instances-deregister.md) + [已註冊執行個體的生命週期](registered-instances-lifecycle.md) # 向 OpsWorks Stacks Stack 註冊執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。若要註冊 Stacks OpsWorks 外部的執行個體，請執行 AWS CLI **aws opsworks register**命令。您可以從要註冊的執行個體或從另一部電腦執行此命令您可以將 `AWSOpsWorksRegisterCLI_EC2`或 `AWSOpsWorksRegisterCLI_OnPremises`政策套用至使用者或群組，以授予註冊 AWS CLI EC2 或內部部署執行個體所需的許可。這些政策需要 1.16.180 版 AWS CLI 或更新版本。 **注意** 若要防止使用者或角色註冊執行個體，請更新執行個體描述檔以拒絕存取 **register**命令。註冊程序會在您想要使用 Stacks OpsWorks 管理的執行個體上安裝代理程式，並使用您指定的 OpsWorks 堆疊註冊執行個體。在註冊執行個體之後，執行個體會成為堆疊的一部分，並由 OpsWorks Stacks 管理。如需詳細資訊，請參閱[管理已註冊的執行個體](registered-instances-manage.md)。 **注意** 雖然 [AWS Tools for PowerShell ](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-welcome.html)包含呼叫 `register` API 動作的 [https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html) cmdlet，但我們建議您改用 AWS CLI 來執行 `register`命令。下圖顯示註冊 Amazon EC2 執行個體的兩種方法。您可以使用相同的方法來註冊現場部署執行個體。 ![\[Two diagrams showing EC2 instance registration: from workstation and from instance itself.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/on-prem-provision.png) **注意** 您可以使用 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)來管理已註冊的執行個體，但必須執行 AWS CLI `register` 命令來註冊執行個體。這樣做的原因是因為註冊程序必須從執行個體執行，無法透過主控台完成。下列各節將詳細說明此程序。 **Topics** + [演練：從您的工作站註冊執行個體](registered-instances-register-walkthrough.md) + [註冊 Amazon EC2 和內部部署執行個體](registered-instances-register-registering.md) # 演練：從您的工作站註冊執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。註冊程序支援數種案例。本節會逐步解說一個案例的end-to-end範例：如何使用工作站註冊 Amazon EC2 執行個體。其他註冊案例使用類似的程序。如需詳細資訊，請參閱[註冊 Amazon EC2 和內部部署執行個體](registered-instances-register-registering.md)。 **注意** 您通常想要註冊現有的 Amazon EC2 執行個體。不過，在本演練中，您可以直接建立新的執行個體和新的堆疊，並於完成時予以刪除。 **Topics** + [步驟 1：建立堆疊和執行個體](#registered-instances-register-walkthrough-prepare) + [步驟 2：安裝並設定 AWS CLI](#registered-instances-register-walkthrough-cli) + [步驟 3：向 EC2Register 堆疊註冊執行個體](#registered-instances-register-walkthrough-register) ## 步驟 1：建立堆疊和執行個體若要開始使用，您需要堆疊和 Amazon EC2 執行個體才能註冊該堆疊。 **建立堆疊和執行個體** 1. 使用 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)來[建立新的堆疊](workingstacks-creating.md)，並命名為 **EC2Register**。針對其他堆疊設定，您可以接受預設值。 1. 從 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/)啟動新的執行個體。請注意下列內容。 + 執行個體必須與堆疊位於相同的區域和 VPC。如果您使用 VPC，請為本演練挑選一個公有子網路。 + 如果您需要建立 SSH 金鑰，請將私有金鑰檔案儲存至您的工作站，並記錄名稱和檔案位置。如果您使用現有的金鑰，請記錄名稱和私有金鑰檔案位置。您稍後需要這些值。 + 執行個體必須以其中一個[支援的 Linux 作業系統](workinginstances-os-linux.md)為基礎。例如，如果您的堆疊位於美國西部（奧勒岡），您可以使用 `ami-35501205`在該區域中啟動 Ubuntu 14.04 LTS 執行個體。否則，請接受預設值。在執行個體啟動期間，您可以繼續進行下一節。 ## 步驟 2：安裝並設定 AWS CLI 使用 AWS CLI **aws opsworks register** 命令執行註冊。註冊第一個執行個體之前，您必須執行 1.16.180 版 AWS CLI 或更新版本。安裝詳細資訊取決於您工作站的作業系統。如需安裝的詳細資訊 AWS CLI，請參閱[安裝 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)。若要檢查您正在執行的 AWS CLI 版本，請在 shell 工作階段中輸入 `aws --version`。 **注意** 若要防止使用者或角色註冊執行個體，請更新執行個體描述檔以拒絕存取 **register**命令。強烈建議您不要略過此步驟，即使您已在工作站 AWS CLI 上執行。使用最新版 AWS CLI 是安全最佳實務。您必須提供 `register` 一組具備適當許可的 AWS 登入資料。建議的做法是使用執行個體描述檔註冊啟動的執行個體，然後將`--use-instance-profile`交換器新增至`register`命令，以避免直接在執行個體上安裝登入資料。如果您透過執行個體描述檔取得登入資料，則請跳到本主題中的[步驟 3：向 EC2Register 堆疊註冊執行個體](#registered-instances-register-walkthrough-register)。不過，如果未使用執行個體描述檔啟動您的執行個體，則可以建立 IAM 使用者。下列程序會建立具有適當許可的新使用者，在工作站上安裝使用者的登入資料，然後將這些登入資料傳遞給 `register`。 **警告** IAM 使用者具有長期憑證，這會造成安全風險。為了協助降低此風險，建議您只為這些使用者提供執行任務所需的許可，並在不再需要這些使用者時將其移除。 **建立使用者** 1. 在 [IAM 主控台](https://console.aws.amazon.com/iam/)的導覽窗格中，選擇 **Users (使用者)**，然後選擇 **Add user (新增使用者)**。 1. 新增名為 **EC2Register** 的使用者。 1. 選擇**下一步**。 1. 在**設定許可**頁面上，選擇**直接連接政策**。 1. **OpsWorks** 在**許可政策**篩選條件方塊中輸入以顯示 OpsWorks 政策，選取下列其中一個政策，然後選擇**下一步：檢閱**。此政策會授予您的使用者執行 `register` 所需的許可。 + 選擇 `AWSOpsWorksRegisterCLI_EC2` 以許可使用者註冊使用執行個體設定檔的 EC2 執行個體。 + 選擇 `AWSOpsWorksRegisterCLI_OnPremises` 以許可使用者註冊現場部署執行個體。 1. 選擇**下一步**。 1. 在 **Review** (檢閱) 頁面上，選擇 **Create user** (建立使用者)。 1. 現在為您的使用者建立存取金鑰。從導覽窗格中，選擇**使用者**，然後選擇您要為其建立存取金鑰的使用者。 1. 選擇**安全登入**資料索引標籤，然後選擇**建立存取金鑰**。 1. 選擇最符合您任務的**存取金鑰最佳實務和替代方案**。 1. 選擇**下一步**。 1. （選用）輸入標籤以識別存取金鑰。 1. 選擇**下一步**。 1. 選擇**下載 .csv 檔案**，將登入資料檔案儲存到系統上方便的位置，然後選擇**完成**。您需要將 IAM 使用者的登入資料提供給 `register`。本演練會透過安裝您工作站之 `credentials` 檔案中的 EC2Register 登入資料，來處理此任務。如需有關管理登入資料的其他方式的資訊 AWS CLI，請參閱[組態和登入資料檔案](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)。 **安裝使用者的登入資料** 1. 建立或開啟您工作站的 `credentials` 檔案。該檔案位於 `~/.aws/credentials` (Linux、Unix 和 OS X) 或 `C:\Users\User_Name\.aws\credentials` (Windows 系統) 中。 1. 使用下列格式，將 EC2Register 使用者的描述檔新增至 `credentials` 檔案。 ``` [ec2register] aws_access_key_id = access_key_id aws_secret_access_key = secret_access_key ``` 將 *access\$1key\$1id* 和 *secret\$1access\$1key* 取代為您稍早下載的 EC2Register 金鑰。 ## 步驟 3：向 EC2Register 堆疊註冊執行個體您現在可以註冊執行個體。 **註冊執行個體** 1. 在 OpsWorks Stacks 中，返回 EC2Register 堆疊，在導覽窗格中選擇**執行個體**，然後選擇**註冊執行個體**。 1. 選取 **EC2 Instances (EC2 執行個體)**，並選擇 **Next: Select Instances (下一步：選取執行個體)**，然後從清單中選取您的執行個體。 1. 選擇**下一步：安裝 AWS CLI** 和**下一步：註冊執行個體**。 OpsWorks Stacks 會自動使用可用的資訊，例如堆疊 ID 和執行個體 ID 來建立`register`命令範本，這會顯示在**註冊執行個體**頁面上。在此範例中，您使用 `register` 透過 SSH 金鑰登入執行個體，並明確指定金鑰檔案，因此，請將 **I use SSH keys to connect to my instances (我使用 SSH 金鑰連線到我的執行個體)** 設為 **Yes (是)**。此命令範本如下所示。 ``` aws opsworks register --infrastructure-class ec2 --region region endpoint ID --stack-id 247be7ea-3551-4177-9524-1ff804f453e3 --ssh-username [username] --ssh-private-key [key-file] i-f1245d10 ``` **注意** 如果堆疊位於與區域端點相關聯的傳統區域中，您必須將區域設定為 OpsWorks Stacks 服務的端點區域，而不是堆疊`us-east-1`的區域。 OpsWorks Stacks 會從堆疊 ID 決定堆疊的區域。 1. 命令範本包含數個使用者特定的引數值，這些值會以括號表示且必須取代為適當的值。將命令範本複製到文字編輯器，並依照下列方式編輯。 **重要** 在註冊程序期間建立的 IAM 使用者需要註冊執行個體的整個生命週期。刪除使用者會導致 OpsWorks Stacks 代理程式無法與服務通訊。為了協助避免在意外刪除使用者時管理已註冊執行個體的問題，請將 `--use-instance-profile` 參數新增至您的`register`命令，以改用執行個體的內建執行個體描述檔。新增 `--use-instance-profile` 參數也可防止每 90 天輪換 AWS 帳戶存取金鑰時發生錯誤（建議的最佳實務），因為它可防止代理程式和必要的 IAM 使用者可用的 OpsWorks 存取金鑰不相符。 + 將*金鑰檔案*取代為您建立執行個體時所儲存 Amazon EC2 金鑰對之私有金鑰檔案的完整路徑。如果您想要，也可以使用相對路徑。 + 將 *username* 取代為執行個體的使用者名稱。在此範例中，使用者名稱是 `ubuntu` (若是 Ubuntu 執行個體) 或 `ec2-user` (若是 Red Hat Enterprise Linux (RHEL) 或 Amazon Linux 執行個體)。 + 新增 `--use-instance-profile`，這會`register`使用執行個體描述檔執行，以防止金鑰輪換期間或意外刪除主體 IAM 使用者時發生錯誤。您的命令應該如下所示。 ``` aws opsworks register --use-instance-profile --infrastructure-class ec2 \ --region us-west-2 --stack-id 247be7ea-3551-4177-9524-1ff804f453e3 --ssh-username ubuntu \ --ssh-private-key "./keys/mykeys.pem" i-f1245d10 ``` 1. 在您的工作站上開啟終端機視窗，從您的編輯器貼上 `register` 命令，然後執行命令。註冊通常需要約 5 分鐘。完成後，返回 Stacks OpsWorks 主控台並選擇**完成**。然後，在導覽窗格中選擇 **Instances (執行個體)**。您的執行個體應該會列於 **Unassigned Instances (未指派的執行個體)** 下。然後，您可以[將執行個體指派給某 layer](registered-instances-assign.md) 或保持不變，端視您預計管理執行個體的方式而定。 1. 完成後，請[停止執行個體](workinginstances-starting.md#workinginstances-starting-stop)，然後使用 Stacks OpsWorks 主控台或命令[將其刪除](workinginstances-starting.md#workinginstances-starting-stop)。這會終止 Amazon EC2 執行個體，因此您不需要支付任何進一步的費用。 # 註冊 Amazon EC2 和內部部署執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。本節說明如何向 OpsWorks Stacks 堆疊註冊 Amazon EC2 或內部部署執行個體。 **Topics** + [準備執行個體](registered-instances-register-registering-prepare.md) + [安裝並設定 AWS CLI](registered-instances-register-registering-cli.md) + [註冊執行個體](registered-instances-register-registering-register.md) + [使用 `register` 命令列](registered-instances-register-registering-command.md) + [register 命令範例](registered-instances-register-registering-examples.md) + [執行個體註冊政策](registered-instances-register-registering-template.md) # 準備執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。註冊執行個體之前，您必須確定其與 OpsWorks Stacks 相容。詳細資訊取決於您是註冊現場部署還是 Amazon EC2 執行個體。 ## 現場部署執行個體內部部署執行個體必須符合下列條件： + 執行個體必須執行其中一個[支援的 Linux 作業系統](workinginstances-os-linux.md)。雖然可以使用從自訂或社群所產生 AMI 建立而成的其他作業系統 (例如 CentOS 6.*x*) 建立或註冊執行個體，但並未正式受到支援。您必須在執行個體上安裝 `libyaml` 套件。若是 Ubuntu 執行個體，套件名稱為 `libyaml-0-2`。若是 CentOS 和 Red Hat Enterprise Linux 執行個體，套件名稱為 `libyaml`。 + 執行個體必須具有支援的執行個體類型 (有時稱為執行個體大小)。支援的執行個體類型可能會因作業系統而異，並取決於您的堆疊是否在 VPC 中。如需支援的執行個體類型清單，請檢視當您嘗試在目標堆疊中建立新執行個體時 Stacks OpsWorks 主控台中顯示**的大小**下拉式清單值。如果執行個體類型呈現灰色且無法在您的目標堆疊中建立，則您無法註冊該類型的執行個體。 + 執行個體必須具有網際網路存取，允許其與 OpsWorks Stacks 服務端點通訊`opsworks.us-east-1.amazonaws.com (HTTPS)`。執行個體也必須支援對 Amazon S3 等 AWS 資源的傳出連線。 + 如果您預計從個別工作站註冊執行個體，已註冊的執行個體必須支援從工作站的 SSH 登入。如果您從執行個體執行註冊命令，則不需要 SSH 登入。 + AWS 存取金鑰用於從 OpsWorks 代理程式到 Stacks OpsWorks 服務的身分驗證。如果您依建議每 90 天輪換存取金鑰，請手動更新 OpsWorks 代理程式以使用新的金鑰。在內部部署電腦或執行個體上，使用新的存取金鑰和私密金鑰編輯 `/etc/aws/opsworks/instance-agent.yml` 檔案。下列命令顯示此檔案中的存取金鑰和秘密金鑰。使用舊金鑰的代理程式可能會造成錯誤。 ``` cat /etc/aws/opsworks/instance-agent.yml | egrep "access_key|secret_key" :access_key_id: AKIAIOSFODNN7EXAMPLE :secret_access_key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ## Amazon EC2 執行個體 Amazon EC2 執行個體必須符合下列條件： + AMI 必須以其中一個支援的 Linux 作業系統為基礎。如需目前的清單，請參閱[OpsWorks Stacks 作業系統](workinginstances-os.md)。如需詳細資訊，請參閱[使用自訂 AMI](workinginstances-custom-ami.md)。如果執行個體是以衍生自標準支援 AMI 的自訂 AMI 為基礎，或包含最少的安裝，您必須在執行個體上安裝 `libyaml` 套件。若是 Ubuntu 執行個體，套件名稱為 `libyaml-0-2`。對於 Amazon Linux 和 Red Hat Enterprise Linux 執行個體，套件名為 `libyaml`。 + 執行個體必須具有支援的執行個體類型 (有時稱為執行個體大小)。支援的執行個體類型可能會因作業系統而異，並取決於您的堆疊是否在 VPC 中。如需支援的執行個體類型清單，請檢視當您嘗試在目標堆疊中建立新執行個體時， Stacks OpsWorks 主控台中顯示**的大小**下拉式清單值。如果執行個體類型呈現灰色且無法在您的目標堆疊中建立，則您也無法註冊該類型的執行個體。 + 執行個體必須處於 `running` 狀態。 + 執行個體不應該是 [Auto Scaling 群組](https://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/WhatIsAutoScaling.html)的一部分。如需詳細資訊，請參閱[從 Auto Scaling 群組分離 EC2 執行個體](https://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/detach-instance-asg.html)。 + 執行個體可以是 [VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Introduction.html) 的一部分，但必須與堆疊位於相同的 VPC 中，且 VPC 必須設定為與 Stacks OpsWorks 正常運作。 + 不支援 [Spot 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-spot-instances-work.html)，因為這些執行個體不適用於[自動修復](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)。當您註冊 Amazon EC2 執行個體時， OpsWorks Stacks 不會修改執行個體[的安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)或規則。請確定執行個體的安全群組規則符合下列 Stacks OpsWorks 要求。 **Ingress Rules (輸入規則)** 輸入規則應該允許下列項目。 + SSH 登入。 + 來自適當 layer 的流量。例如，資料庫伺服器通常會允許來自堆疊之應用程式伺服器 layer 的輸入流量。 + 連入適當連接埠的流量。例如，應用程式伺服器執行個體通常會允許連入連接埠 80 (HTTP) 和 443 (HTTPS) 的所有輸入流量。 **Egress Rules (輸出規則)** 輸出規則應該允許下列項目。 + 來自執行個體上執行之應用程式的 Stacks OpsWorks 服務流量。 + 使用 AWS API 從應用程式存取 Amazon S3 等 AWS 資源的流量。一個常用方法是不指定任何輸出規則，如此就不會對輸出流量設限。 # 安裝並設定 AWS CLI **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。註冊第一個執行個體之前，您必須在執行的電腦上執行 1.16.180 版 AWS CLI 或更新版本`register`。安裝詳細資訊取決於您工作站的作業系統。如需安裝的詳細資訊 AWS CLI，請參閱[安裝 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)和[設定 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。若要檢查您正在執行的 AWS CLI 版本，請在 shell 工作階段中輸入 `aws --version`。 **注意** 雖然 [AWS Tools for PowerShell ](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-welcome.html)包含呼叫 `register` API 動作的 [https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-OPSInstance.html) cmdlet，但我們建議您改用 AWS CLI 來執行 `register`命令。您必須以適當許可執行 `register`。您可以在要註冊的工作站或執行個體上安裝具有適當許可的使用者登入資料，以使用 IAM 角色取得許可，或以最佳方式取得許可。然後，您可以使用這些登入資料來執行 `register`，如稍後所述。透過將 IAM 政策連接至使用者或角色來指定許可。對於 `register`，您可以使用 `AWSOpsWorksRegisterCLI_EC2`或 `AWSOpsWorksRegisterCLI_OnPremises`政策，分別授予註冊 Amazon EC2 或內部部署執行個體的許可。 **注意** 如果您在 Amazon EC2 執行個體`register`上執行，最好使用 IAM 角色來提供登入資料。如需如何將 IAM 角色連接至現有執行個體的詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[將 IAM 角色連接至執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)或[取代 IAM 角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#replace-iam-role)。如需 `AWSOpsWorksRegisterCLI_EC2` 和 `AWSOpsWorksRegisterCLI_OnPremises` 政策的範例程式碼片段，請參閱[執行個體註冊政策](registered-instances-register-registering-template.md)。如需建立及管理 AWS 登入資料的詳細資訊，請參閱 [AWS 安全登入資料](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)。 **Topics** + [使用 IAM 角色](#registered-instances-register-registering-cli-role) + [使用安裝的登入資料](#registered-instances-register-registering-cli-creds) ## 使用 IAM 角色如果您從要註冊的 Amazon EC2 執行個體執行命令，提供登入資料給的偏好策略`register`是使用已連接`AWSOpsWorksRegisterCLI_EC2`政策或同等許可的 IAM 角色。此方法可讓您避免在執行個體上安裝您的登入資料。其中一種做法是在 EC2 主控台中使用 **Attach/Replace IAM Role (連接/取代 IAM 角色)** 命令，如下圖所述。 ![\[AWS EC2 console showing Instance Settings menu with Attach/Replace IAM Role option highlighted.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/instance_register_attachrole.png) 如需如何將 IAM 角色連接至現有執行個體的詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[將 IAM 角色連接至執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)或[取代 IAM 角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#replace-iam-role)。對於使用執行個體描述檔所啟動的執行個體 (建議)，將 `--use-instance-profile` 參數新增至 `register` 命令，以提供登入資料；請不要使用 `--profile` 參數。如果執行個體正在執行且具有角色，您可以透過將 `AWSOpsWorksRegisterCLI_EC2` 政策連接至該角色來授予必要許可。該角色會提供一組預設登入資料給執行個體。只要您尚未在執行個體上安裝任何登入資料，`register` 就會自動擔任該角色並以其許可執行。 **重要** 我們建議您不要在執行個體上安裝登入資料。除了建立安全風險之外，執行個體的角色也位於 AWS CLI 用來尋找預設登入資料的預設提供者鏈結尾。安裝的登入資料可能會優先於角色，因此 `register` 可能沒有必要許可。如需詳細資訊，請參閱 [AWS CLI入門](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence)。如果執行中的執行個體沒有角色，您必須安裝在執行個體上安裝具備必要許可的登入資料，如[使用安裝的登入資料](#registered-instances-register-registering-cli-creds)中所述。建議使用透過執行個體描述檔所啟動的執行個體，而這種方式較為簡單，也較不容易出錯。 ## 使用安裝的登入資料有數種方式可在系統上安裝使用者登入資料，並將其提供給 AWS CLI 命令。以下說明不再建議使用的方法，但此方法可以用於您註冊未使用執行個體描述檔所啟動的 EC2 執行個體時。只要連接的政策授予必要許可，您也可以使用現有使用者的登入資料。如需詳細資訊，包括安裝登入資料之其他方式的說明，請參閱[組態與登入資料檔案](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)。 **使用安裝的登入資料** 1. [建立 IAM 使用者](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)，並將存取金鑰 ID 和私密存取金鑰儲存在安全的位置。 **警告** IAM 使用者具有長期憑證，這會造成安全風險。為了協助降低此風險，建議您只為這些使用者提供執行任務所需的許可，並在不再需要這些使用者時將其移除。 1. [連接 AWSOpsWorksRegisterCLI\$1OnPremises 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html)至使用者。如果您想要，也可以連接授予更廣泛許可的政策，只要其中包含 `AWSOpsWorksRegisterCLI_OnPremises` 許可。 1. 在系統的 `credentials` 檔案中建立使用者的描述檔。該檔案位於 `~/.aws/credentials` (Linux、Unix 和 OS X) 或 `C:\Users\User_Name\.aws\credentials` (Windows 系統) 中。檔案包含以下格式的一或多個設定檔，每個設定檔都包含使用者的存取金鑰 ID 和私密存取金鑰。 ``` [profile_name] aws_access_key_id = access_key_id aws_secret_access_key = secret_access_key ``` 將您先前儲存的 IAM 登入資料替換為 *access\$1key\$1id* 和 *secret\$1access\$1key* 值。您可以為描述檔名稱指定任何想要的名稱，但有兩項限制：該名稱必須是唯一的，而且預設描述檔必須命名為 `default`。您也可以使用現有的描述檔，只要該檔案具備必要許可。 1. 使用 `register` 命令的 `--profile` 參數來指定描述檔名稱。`register` 命令會以授予相關聯登入資料的許可執行。您也可以省略 `--profile`。在此情況下，`register` 會使用預設登入資料執行。請注意，這些不一定是預設描述檔的登入資料，因此您必須確定預設登入資料具備必要許可。如需如何 AWS CLI 決定預設登入資料的詳細資訊，請參閱[設定 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。 # 註冊執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。您可以從工作站或執行個體執行 AWS CLI `register` 命令，來註冊執行個體。處理此操作的最簡單方式就是使用 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)的註冊精靈，這會簡化建構命令字串的程序。熟悉註冊程序之後，如果您想要，也可以略過精靈，並執行 `register` 命令。以下說明如何使用註冊精靈向現有的堆疊註冊執行個體。 **注意** 若要向新堆疊註冊執行個體，您可以在 Stacks OpsWorks 儀表板上選擇**註冊執行個體**。這會啟動與現有堆疊的精靈相同的精靈，但多了一個用來設定新堆疊的頁面。 **使用註冊精靈註冊執行個體** 1. 在 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)中，建立堆疊或開啟現有的堆疊。 1. 在導覽窗格中，選擇 **Instances (執行個體)**，然後選擇 **register an instance (註冊執行個體)**。 1. 在**選擇執行個體類型**頁面上，指定您要註冊 Amazon EC2 還是現場部署執行個體： + 如果您要註冊 Amazon EC2 執行個體，請選擇**下一步：選取執行個體**。 + 如果您要註冊現場部署執行個體，請選擇**下一步：安裝 AWS CLI**，然後前往步驟 5。 1. 如果您要註冊 Amazon EC2 執行個體，請開啟**選取執行個體**頁面以選取要註冊的執行個體。 OpsWorks Stacks 會收集建置命令所需的資訊。完成時，選擇 **Next:Install AWS CLI (下一步：安裝 AWS CLI)**。 1. 您計劃執行的執行個體`register`必須執行 1.16.180 版 AWS CLI 或更新版本。為了安裝或更新 AWS CLI，註冊精靈頁面會提供安裝和設定指示的連結。驗證 AWS CLI 安裝之後，指定您會從要註冊的執行個體還是個別的工作站執行命令，然後選擇 **Next: Register Instances (下一步：註冊執行個體)**。 1. **Register Instances (註冊執行個體)** 頁面會顯示 `register` 命令字串的範本，其中包含您選取的選項。例如，如果您從個別工作站註冊 Amazon EC2 執行個體，預設範本會如下所示。 ``` aws opsworks register --infrastructure-class ec2 --region us-west-2 --stack-id 247be7ea-3551-4177-9524-1ff804f453e3 --ssh-username [username] i-f1245d10 ``` **重要** 在註冊程序期間建立的 IAM 使用者需要註冊執行個體的整個生命週期。刪除使用者會導致 OpsWorks Stacks 代理程式無法與服務通訊。為了協助避免在意外刪除使用者時管理已註冊執行個體的問題，請將 `--use-instance-profile` 參數新增至您的`register`命令，以改用執行個體的內建執行個體描述檔。新增 `--use-instance-profile` 參數也可防止每 90 天輪換 AWS 帳戶存取金鑰時發生錯誤（建議的最佳實務），因為它可防止代理程式和必要的 IAM 使用者可用的 OpsWorks 存取金鑰不相符。如果您將**我使用 SSH 金鑰**設定為**是**， OpsWorks Stacks 會將`--ssh-private-key`引數新增至字串，您可以使用該字串來指定私有 SSH 金鑰檔案。 **注意** 如果您想要使用密碼`register`登入，請將**我使用 SSH 金鑰**設定為**否**。當您執行時`register`，系統會提示您輸入密碼。將此字串複製至文字編輯器，並視需要編輯。請注意下列內容。 + 括號文字代表您必須提供的資訊，例如您的 SSH 金鑰檔案位置。 + 此範本假設您使用預設 AWS 登入資料執行 `register`。否則，請將 `--profile` 引數新增至命令字串，並指定您要使用的登入資料描述檔名稱。對於其他案例，您可能需要進一步變更命令。如需可用 `register` 引數的說明，以及建構命令字串的替代方式，請參閱[使用 `register` 命令列](registered-instances-register-registering-command.md)。您也可以從命令列執行 `aws opsworks help register` 來顯示命令的文件。如需一些範例命令字串，請參閱[register 命令範例](registered-instances-register-registering-examples.md)。 1. 完成編輯命令字串之後，在您的工作站上開啟終端機視窗或使用 SSH 登入執行個體並執行命令。整個操作通常需要約五分鐘，在這段期間，執行個體會處於 **Registering (正在註冊)** 狀態。 1. 完成操作時，選擇 **Done (完成)**。執行個體現在處於 **Registered (已註冊)** 狀態，並在堆疊的 **Instances (執行個體)** 頁面上列為未指派的執行個體。 `register` 命令會執行下列動作。 1. 如果 `register` 正在工作站上執行，命令會先使用 SSH 登入要註冊的執行個體。其餘處理會在執行個體上進行，不論您在何處執行命令都一樣。 1. 從 OpsWorks Amazon S3 下載 Stacks 代理程式套件。 1. 解壓縮並安裝代理程式及其相依性，例如[適用於 Ruby 的 AWS 開發套件](https://aws.amazon.com/documentation/sdk-for-ruby/)。 1. 建立下列項目： + 使用 Stacks 服務引導代理程式以提供安全通訊的 IAM OpsWorks 使用者。使用者的許可只允許 `opsworks:RegisterInstance` 動作，並會在 15 分鐘後過期。 + 堆疊的 IAM 群組，其中包含已註冊執行個體的使用者。 1. 建立 RSA 金鑰對，並將公有金鑰傳送至 OpsWorks Stacks。此金鑰對可用來加密代理程式與 OpsWorks Stacks 之間的通訊。 1. 向 Stacks OpsWorks 註冊執行個體。堆疊接著會執行一組初始安裝配方來設定執行個體，其中包含下列項目。 + 覆寫執行個體的主機檔案。透過註冊執行個體，您已將使用者管理移交給 OpsWorks Stacks，而 Stacks 必須擁有自己的主機檔案才能控制 SSH 登入許可。 + 對於 Amazon EC2 執行個體，初始設定也包含向堆疊註冊任何連接的 Amazon EBS 磁碟區或彈性 IP 地址。您必須確保 Amazon EBS 磁碟區未掛載至預留掛載點，包括 `/var/www`和執行個體層預留的任何掛載點。如需管理堆疊資源的詳細資訊，請參閱[資源管理](resources.md)。如需 layer 掛載點的詳細資訊，請參閱[OpsWorks Stacks Layer 參考](layers.md)。如需初始安裝組態變更的完整說明，請參閱[初始安裝組態變更](registered-instances-lifecycle.md#registered-instances-lifecycle-setup-config)。 **注意** 初始安裝不會更新已註冊執行個體的作業系統，您必須自行處理該任務。如需詳細資訊，請參閱[管理安全性更新](workingsecurity-updates.md)。 # 使用 `register` 命令列 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。若要註冊執行個體，請確定您正在執行至少 1.16.180 版的 AWS CLI。以下顯示 `register` 命令的一般語法。 ``` aws opsworks register \ [--profile profile_name] \ [--region region_name] \ --infrastructure-class instance_type \ --stack-id stack ID \ [--local] | [--ssh-private-key key_file --ssh-username username] | [--override-ssh command_string] \ [--override-hostname hostname] \ [--debug] \ [--override-public-ip public IP] \ [--override-private-ip private IP] \ ..[--use-instance-profile] \ [ [IP address] | [hostname] | [instance ID] ``` 下列引數適用於所有 AWS CLI 命令。 **`--profile`** (選用) 登入資料的描述檔名稱。如果您省略此引數，命令會使用您的預設登入資料執行。如需如何 AWS CLI 決定預設登入資料的詳細資訊，請參閱[設定 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。 **`--region`** （選用） Stacks OpsWorks 服務端點的區域。請勿`--region`設定為堆疊的區域。 OpsWorks 堆疊會自動從堆疊 ID 決定堆疊的區域。如果您的預設區域已設定，您可以省略此引數。如需如何指定預設區域的詳細資訊，請參閱[設定 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。針對 Amazon EC2 和內部部署執行個體使用以下引數。 **`--infrastructure-class`** （必要）此參數必須設定為 `ec2`或 `on-premises`，以指出您是分別註冊 Amazon EC2 還是內部部署執行個體。 **`--stack-id`** (必要) 要用來註冊執行個體的堆疊 ID。若要尋找堆疊 ID，請在 **Stack (堆疊)** 頁面上，選擇 **Settings (設定)**。堆疊 ID 會以 **OpsWorks ID** 標記，而且是看起來類似 `ad21bce6-7623-47f1-bf9d-af2affad8907` 的 GUID。 **SSH 登入引數** 使用下列引數指定 `register` 應該如何登入執行個體。 **`--local`** (選用) 使用此引數註冊您執行命令的執行個體。在此情況下，`register` 不需要登入執行個體。 **`--ssh-private-key` 和 `--ssh-username`** (選用) 如果您想要從個別工作站註冊執行個體，並想要明確指定使用者名稱或私有金鑰檔案，請使用這些引數。 + `--ssh-username` – 使用此引數指定 SSH 使用者名稱。如果您省略 `--ssh-username`，`ssh` 會使用預設使用者名稱。 + `--ssh-private-key` – 使用此引數明確指定私有金鑰檔案。如果您省略 `--ssh-private-key`，`ssh` 會嘗試使用不需要密碼的身分驗證技術登入，包含使用預設私有金鑰。如果不支援上述任何技術，`ssh` 會詢問您的密碼。如需 `ssh` 如何處理身分驗證的詳細資訊，請參閱 [The Secure Shell (SSH) Authentication Protocol](https://www.ietf.org/rfc/rfc4252.txt)。 **`--override-ssh`** (選用) 如果您想要從個別工作站註冊執行個體，並想要指定自訂 [http://linux.about.com/od/commands/l/blcmdl1_ssh.htm](http://linux.about.com/od/commands/l/blcmdl1_ssh.htm) 命令字串，請使用此引數。`register` 命令使用此命令字串登入已註冊的執行個體。如需 `ssh` 的詳細資訊，請參閱 [SSH](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1)。 **`--override-hostname`** （選用）指定執行個體的主機名稱，僅供 Stacks OpsWorks 使用。預設值是執行個體的主機名稱。 **`--debug`** (選用) 如果註冊程序失敗，則提供除錯資訊。如需故障診斷資訊，請參閱[故障診斷執行個體註冊](common-issues.md#common-issues-instance-registration)。 **`--use-instance-profile`** （選用，但強烈建議 Amazon EC2 執行個體）讓`register`命令使用連接的執行個體描述檔，而不是建立 IAM 使用者。如果不小心刪除 IAM 使用者時嘗試管理已註冊的執行個體，新增此參數有助於防止發生錯誤。在註冊程序期間建立的 IAM 使用者需要註冊執行個體的整個生命週期。刪除使用者會導致 OpsWorks Stacks 代理程式無法與服務通訊。為了協助避免在意外刪除使用者時管理已註冊執行個體的問題，請將 `--use-instance-profile` 參數新增至您的`register`命令，以改用執行個體的內建執行個體描述檔。新增 `--use-instance-profile` 參數也可防止每 90 天輪換 AWS 帳戶存取金鑰時發生錯誤（建議的最佳實務），因為它可防止 OpsWorks 代理程式和所需使用者可用的存取金鑰不相符。 **Target** (條件式) 如果您從工作站執行此命令，命令字串中的最終值會以下列其中一種方式指定註冊目標。 + 執行個體的公有 IP 地址。 + 執行個體的主機名稱。 + 對於 Amazon EC2 執行個體，則為執行個體 ID。 OpsWorks Stacks 使用執行個體 ID 來取得執行個體組態，包括執行個體的公有 IP 地址。根據預設， OpsWorks Stacks 會使用此地址來建構用來登入執行個體的`ssh`命令字串。如果您需要連線至私有 IP 地址，您必須使用 `--override-ssh` 提供自訂命令字串。如需範例，請參閱 [從工作站註冊現場部署執行個體](registered-instances-register-registering-examples.md#registered-instances-register-registering-examples-workstation-onprem)。如果您指定主機名稱，`ssh` 需要 DNS 伺服器將名稱解析為特定執行個體。如果您不確定主機名稱是唯一的，請使用 `ssh` 確認主機名稱解析為正確的執行個體。如果您從要註冊的執行個體執行此命令，請省略執行個體識別符，並改用 `--local` 引數。下列引數僅適用於現場部署執行個體。 **`--override-public-ip`** （選用） OpsWorks Stacks 會將指定的地址顯示為執行個體的公有 IP 地址。它不會變更執行個體的公有 IP 地址。不過，如果使用者使用主控台連線至執行個體，例如選擇**執行個體**頁面上的地址， OpsWorks Stacks 會使用指定的地址。 OpsWorks Stacks 會自動判斷引數的預設值。 **`--override-private-ip`** （選用） OpsWorks Stacks 會將指定的地址顯示為執行個體的私有 IP 地址。它不會變更執行個體的私有 IP 地址。 OpsWorks Stacks 會自動判斷引數的預設值。 # register 命令範例 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。本節包含 `register` 命令字串的一些範例。 **從工作站註冊 Amazon EC2 執行個體** 下列範例會從工作站註冊 Amazon EC2 執行個體。命令字串使用預設登入資料，並透過其 Amazon EC2 執行個體 ID 識別執行個體。透過將 `ec2` 變更為 `on-premises`，即可將範例用於現場部署執行個體。 ``` aws opsworks register \ --region us-west-2 \ --use-instance-profile \ --infrastructure-class ec2 \ --stack-id ad21bce6-7623-47f1-bf9d-af2affad8907 \ --ssh-user-name my-sshusername \ --ssh-private-key "./keys/mykeys.pem" \ i-2422b9c5 ``` **從工作站註冊現場部署執行個體** 下列範例會從個別工作站註冊現場部署執行個體。命令字串使用預設登入資料，並以指定的 `ssh` 命令字串登入執行個體。如果您的執行個體需要密碼，`register` 會提示您。您可以將 `on-premises`變更為，以使用 Amazon EC2 執行個體的範例`ec2`。 ``` aws opsworks register \ --region us-west-2 \ --infrastructure-class on-premises \ --stack-id ad21bce6-7623-47f1-bf9d-af2affad8907 \ --override-ssh "ssh your-user@192.0.2.0" ``` 您可以使用 `--override-ssh` 指定任何自訂 SSH 命令字串。然後， OpsWorks Stacks 會使用指定的字串登入執行個體，而不是建構命令字串。如需其他範例，請參閱[使用自訂 SSH 命令字串註冊執行個體](#registered-instances-register-registering-examples-custom-ssh)。 **使用自訂 SSH 命令字串註冊執行個體** 下列範例會從工作站註冊現場部署執行個體，並使用 `--override-ssh`引數指定`register`使用登入執行個體的自訂 SSH 命令。此範例使用 `sshpass` 以使用者名稱和密碼登入，但您可以指定任何有效的 `ssh` 命令字串。 ``` aws opsworks register \ --region us-west-2 \ --infrastructure-class on-premises \ --stack-id 2f92ff9d-04f2-4728-879b-f4283b40783c \ --override-ssh "sshpass -p 'mypassword' ssh your-user@192.0.2.0" ``` **從執行個體執行 `register` 來註冊執行個體** 下列範例示範如何`register`透過從執行個體本身執行來註冊 Amazon EC2 執行個體。命令字串取決於其許可的預設登入資料。若要使用現場部署執行個體的範例，請將 `--infrastructure-class`變更為 `on-premises`。 ``` aws opsworks register \ --region us-west-2 \ --infrastructure-class ec2 \ --stack-id ad21bce6-7623-47f1-bf9d-af2affad8907 \ --local ``` **使用私有 IP 地址註冊執行個體** 根據預設，`register` 使用執行個體的公有 IP 地址登入執行個體。若要使用私有 IP 地址註冊執行個體 (例如 VPC 之私有子網路中的執行個體)，您必須使用 `--override-ssh` 指定自訂 `ssh` 命令字串。 ``` aws opsworks register \ --region us-west-2 \ --infrastructure-class ec2 \ --stack-id 2f92ff9d-04f2-4728-879b-f4283b40783c \ --override-ssh "ssh -i mykey.pem ec2-user@10.183.201.93" \ i-2422b9c5 ``` # 執行個體註冊政策 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 `AWSOpsWorksRegisterCLI_EC2` 和 `AWSOpsWorksRegisterCLI_OnPremises` 政策分別提供適當的許可，來註冊 EC2 和現場部署執行個體。您可以將 `AWSOpsWorksRegisterCLI_EC2`新增至您的 IAM 使用者以註冊 EC2 執行個體，但將 `AWSOpsWorksRegisterCLI_OnPremises`新增至您的使用者以註冊現場部署執行個體。若要使用這些政策，您必須執行至少 1.16.180 版 AWS CLI 或更新版本的。 ## `AWSOpsWorksRegisterCLI_EC2` 政策將 `AWSOpsWorksRegisterCLI_EC2`新增至您的使用者以註冊 EC2 執行個體。如果您計劃只註冊 EC2 執行個體，則應該使用此設定檔。當您使用此政策，許可是由 EC2 執行個體的執行個體設定檔提供。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "opsworks:AssignInstance", "opsworks:CreateLayer", "opsworks:DeregisterInstance", "opsworks:DescribeInstances", "opsworks:DescribeStackProvisioningParameters", "opsworks:DescribeStacks", "opsworks:UnassignInstance" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances" ], "Resource": [ "*" ] } ] } ``` ------ ## (已廢除) `AWSOpsWorksRegisterCLI_OnPremises` 政策將 `AWSOpsWorksRegisterCLI_OnPremises`新增至您的使用者以註冊現場部署執行個體。此政策包含 IAM 許可，例如 `AttachUserPolicy`，但這些許可工作的資源受到限制。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "opsworks:AssignInstance", "opsworks:CreateLayer", "opsworks:DeregisterInstance", "opsworks:DescribeInstances", "opsworks:DescribeStackProvisioningParameters", "opsworks:DescribeStacks", "opsworks:UnassignInstance" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:DescribeInstances" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "iam:CreateGroup", "iam:AddUserToGroup" ], "Resource": [ "arn:aws:iam::*:group/AWS/OpsWorks/OpsWorks-*" ] }, { "Effect": "Allow", "Action": [ "iam:CreateUser", "iam:CreateAccessKey" ], "Resource": [ "arn:aws:iam::*:user/AWS/OpsWorks/OpsWorks-*" ] }, { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy" ], "Resource": [ "arn:aws:iam::*:user/AWS/OpsWorks/OpsWorks-*" ], "Condition": { "ArnEquals": { "iam:PolicyARN": "arn:aws:iam::aws:policy/AWSOpsWorksInstanceRegistration" } } } ] } ``` ------ ## (已廢除) `AWSOpsWorksRegisterCLI` 政策 **重要** `AWSOpsWorksRegisterCLI` 政策已廢除，因此無法用來註冊新的執行個體。它只適用於已註冊之執行個體的回溯相容性。此`AWSOpsWorksRegisterCLI`政策包含許多 IAM 許可`CreateUser`，包括 `PutUserPolicy`、和 `AddUserToGroup`。由於這些是管理員層級許可，您應該只將 `AWSOpsWorksRegisterCLI` 政策指派給信任的管理使用者。 # 管理已註冊的執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。當您註冊執行個體時，它會成為 OpsWorks Stacks 執行個體，而且您可以像使用 Stacks OpsWorks 建立的執行個體一樣進行管理。主要有兩點差異： + 已註冊的執行個體不一定會指派給某 layer。 + 您可以取消註冊已註冊的執行個體，並將其交還給您直接控制。註冊執行個體後，執行個體會處於已註冊狀態。 OpsWorks Stacks 為所有已註冊的執行個體提供下列管理功能： + **運作狀態檢查** – OpsWorks Stacks 會監控代理程式，以評估執行個體是否繼續運作。如果執行個體未通過運作狀態檢查， OpsWorks Stacks [會自動修復](workinginstances-autohealing.md)已註冊的 Amazon EC2 執行個體，並將已註冊現場部署執行個體的狀態變更為 `connection lost`。 + **[CloudWatch 監控](monitoring-cloudwatch.md)** – 針對已註冊的執行個體啟用 CloudWatch 監控。您可以監控 CPU 使用率和可用記憶體等指標，並選擇性地在指標超過指定的閾值時收到通知。 + **使用者管理** – OpsWorks Stacks 提供簡單的方法來指定哪些使用者可以存取執行個體，以及他們可以執行哪些操作。如需詳細資訊，請參閱[管理使用者許可](opsworks-security-users.md)。 + **配方執行** – 您可以使用[執行配方堆疊命令](workingstacks-commands.md)在執行個體上執行 Chef 配方。 + **作業系統更新** – 您可以使用[更新相依性堆疊命令](workingstacks-commands.md)來更新執行個體的作業系統。若要充分利用 OpsWorks Stacks 管理功能，您可以將執行個體指派給 layer。如需詳細資訊，請參閱[將已註冊的執行個體指派給某 Layer](registered-instances-assign.md)。 Stacks OpsWorks 管理 Amazon EC2 和內部部署執行個體的方式有所不同。 Amazon EC2 執行個體 + 如果您停止已註冊的 Amazon EC2 執行個體， OpsWorks Stacks 會終止執行個體存放區後端執行個體，並停止 Amazon EBS 後端執行個體。執行個體仍處於已向堆疊註冊的狀態並已指派給其所在 layer，因此您可以視需要將它重新啟動。您必須取消註冊已註冊的執行個體來將它從堆疊中移除，可以[明確進行](registered-instances-deregister.md)或透過[刪除執行個體](workinginstances-delete.md)，後者會自動將它取消註冊。 + 如果您重新啟動已註冊的 Amazon EC2 執行個體，或執行個體失敗且自動修復，則結果與使用 Amazon EC2 停止和重新啟動執行個體相同。請注意下列差異： + 執行個體後端執行個體 – OpsWorks Stacks 使用相同的 AMI 啟動新的執行個體。請注意， OpsWorks Stacks 不了解您在執行個體註冊之前在執行個體上執行的任何操作，例如安裝軟體套件。如果您希望 OpsWorks Stacks 在啟動時安裝套件或執行其他組態任務，您必須提供自訂 Chef 配方來執行所需的任務，並將其指派給適當的 layer 設定事件。 + Amazon EBS 後端執行個體 – OpsWorks Stacks 會使用相同的 AMI 啟動新的執行個體，並重新連接根磁碟區，將執行個體還原至先前的組態。 + 如果您取消註冊已註冊的 Amazon EC2 執行個體，它會返回為一般 Amazon EC2 執行個體。現場部署執行個體 + OpsWorks Stacks 無法停止或啟動已註冊的內部部署執行個體。取消指派已註冊的內部部署執行個體會觸發關機事件。不過，該事件只會執行所指派 layer 的關機配方。它們會執行關閉服務等任務，但不會停止執行個體。 + OpsWorks 如果已註冊的內部部署執行個體失敗， Stacks 無法自動修復，但執行個體會標記為連線遺失。 + 內部部署執行個體無法使用 Elastic Load Balancing、Amazon EBS 或彈性 IP 地址服務。 # 將已註冊的執行個體指派給某 Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。註冊執行個體之後，您可以將其指派給一或多 layer。將執行個體指派給 layer 而不是讓它保持未指派的優點是，您可以將自訂配方指派給 layer 的[生命週期事件](workingcookbook-events.md)。然後， OpsWorks Stacks 會在 layer 的配方之後的適當時間自動執行它們。 + 您可以將已註冊的任何執行個體指派給[自訂 layer](workinglayers-custom.md)。自訂 layer 包含不會安裝任何套件的一組最少配方，因此應該不會與執行個體的現有組態產生任何衝突。 + 您可以將內部部署執行個體指派給 OpsWorks Stacks [內建 layer](workinglayers.md)。每個內建 layer 包含自動安裝一或多個套件的配方。例如，Java App Server 設定配方會安裝 Apache 和 Tomcat。該 layer 的配方也可能會執行其他操作，例如重新啟動服務及部署應用程式。在將現場部署執行個體指派給內建 layer 之前，您應該確保 layer 的配方不會產生任何衝突，例如嘗試安裝與執行個體目前不同的應用程式伺服器版本。如需詳細資訊，請參閱[層](workinglayers.md)及[OpsWorks Stacks Layer 參考](layers.md)。 **將已註冊的執行個體指派給某 layer** 1. 新增您要使用堆疊的 layer (如果您尚未這樣做)。 1. 在導覽窗格中選擇**執行個體**，然後在執行個體**的動作**欄中選擇**指派**。 1. 選取適當 layer，然後選擇 **Save (儲存)**。當您將執行個體指派給 layer Stacks OpsWorks 時，會執行下列動作。 + 執行該 layer 的安裝配方。 + 將任何連接的彈性 IP 地址或 Amazon EBS 磁碟區新增至堆疊的資源。然後，您可以使用 OpsWorks Stacks 來管理這些資源。如需詳細資訊，請參閱[資源管理](resources.md)。完成後，執行個體會處於線上狀態，並完全整合到堆疊中。 OpsWorks 堆疊接著會在每次生命週期事件發生時執行 layer 指派的配方。 # 取消指派已註冊的執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。您可以使用 OpsWorks 主控台或 SDK 操作 AWS CLI，從其 layer 取消指派已註冊的執行個體。當您取消指派執行個體時， OpsWorks Stacks 會在執行個體上執行 layer 的關機配方。這些配方會執行關閉服務等任務，但不會停止執行個體。如果將執行個體指派給多 layer，取消指派會套用至每一 layer；您無法將執行個體從其一小部分 layer 取消指派。不過，執行個體仍處於已向堆疊註冊的狀態，因此您可以視需要將其指派給另一 layer。 **使用主控台取消指派已註冊的執行個體** 1. 在導覽窗格中，選擇**執行個體**。 1. 選擇您要取消指派的執行個體。 1. 在執行個體**的詳細資訊**頁面上，選擇**取消指派**。 ![\[在執行個體的詳細資訊頁面上取消指派已註冊的執行個體\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/unassign-instance.png) **使用取消指派已註冊的執行個體 AWS CLI** 執行 [https://docs.aws.amazon.com/cli/latest/reference/opsworks/unassign-instance.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/unassign-instance.html)命令，從使用該執行個體的所有層取消指派已註冊的執行個體。 ``` aws opsworks unassign-instance --region region --instance-id instance-id ``` # 取消註冊已註冊的執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用 OpsWorks 主控台 AWS CLI或 SDK 操作取消註冊執行個體。 ** **使用主控台取消註冊執行個體** 1. 在導覽窗格中，選擇**執行個體**。 1. 選擇您要取消註冊的執行個體。 1. 在執行個體**的詳細資訊**頁面上，選擇**取消註冊**。 ![\[在執行個體的詳細資訊頁面上取消註冊執行個體\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/deregister-instance.png) **使用取消註冊執行個體 AWS CLI** 執行 [https://docs.aws.amazon.com/cli/latest/reference/opsworks/deregister-instance.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/deregister-instance.html)命令，從其堆疊取消註冊執行個體。 ``` aws opsworks deregister-instance --region region --instance-id instance-id ``` 當您取消註冊執行個體時， OpsWorks Stacks 會執行下列動作： + 將執行個體從堆疊中移除。 + 將執行個體從任何指派 layer 取消指派。 + 關閉並解除安裝代理程式。 + 取消註冊任何連接的資源（彈性 IP 地址和 Amazon EBS 磁碟區）。此程序包括在註冊之前連接到執行個體的資源，以及您使用 OpsWorks Stacks 在作為堆疊的一部分時連接到執行個體的資源。取消註冊之後，資源將不再是堆疊資源的一部分，但會保持連接至執行個體。 + 停止收取現場部署執行個體的費用。 + 移除 OpsWorks 新增至執行個體的所有標籤。執行個體會維持在執行中狀態，但由您直接控制，且不再由 Stacks OpsWorks 管理。 **注意** 只有在 Linux 堆疊中完全支援註冊和取消註冊電腦或執行個體。對於 Windows 堆疊，允許取消註冊執行個體，但不會從執行個體解除安裝 OpsWorks 代理程式。取消註冊不會移除所有變更的檔案，也不會完整還原為特定檔案的備份副本。此清單適用於 Chef 11.10 和 Chef 12 堆疊；以下說明這兩種版本之間的差異。 `/etc/hosts` 會備份至 `/var/lib/aws/opsworks/local-mode-cache/backup/etc/`，但不會還原。 `aws` 和 `opsworks` 項目會保留在 passwd、group 和 shadow 檔案等。 `/etc/sudoers` 包含 Stacks OpsWorks 目錄的參考。下列檔案會安全留下；若要長期保留，請考慮刪除 `/var/lib/aws/opsworks`。 `/var/log/aws/opsworks` 會保留在 Chef 11.10 堆疊中的執行個體上。 `/var/lib/aws/opsworks` 會保留在 Chef 11.10 和 Chef 12 堆疊上。 `/var/chef` 會保留在 Chef 12 堆疊中的執行個體上。其他留下的檔案： `/etc/logrotate.d/opsworks-agent` `/etc/cron.d/opsworks-agent-updater` `/etc/ld.so.conf.d/opsworks-user-space.conf` `/etc/motd.opsworks-static` `/etc/aws/opsworks` `/etc/sudoers.d/opsworks` `/etc/sudoers.d/opsworks-agent` # 已註冊執行個體的生命週期 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 只有 Linux 堆疊支援此功能。已註冊執行個體的生命週期是從安裝及執行代理程式之後開始。此時，它會指示 OpsWorks Stacks 向堆疊註冊執行個體。下列狀態圖表摘要說明生命週期的主要元素。 ![\[State diagram showing lifecycle of registered instances with various states and transitions.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/on-prem-state.png) 每個狀態對應至一個執行個體狀態。邊緣代表下列其中一個 OpsWorks Stacks 命令。下列各節將會詳細討論。 + **設定** – 此命令對應於設定[生命週期事件](workingcookbook-events.md)，並執行執行個體的設定配方。 + **設定** – 此命令對應至設定生命週期事件。 OpsWorks 當執行個體進入或離開線上狀態時， Stacks 會在堆疊中的每個執行個體上觸發此事件。執行個體會執行其設定配方，這會進行任何必要變更，以配合新的執行個體。 + **關閉** – 此命令對應於執行執行個體關機配方的關機生命週期事件。這些配方會執行關閉服務等任務，但不會停止執行個體。 + **取消註冊** – 此命令會取消註冊執行個體，且不對應至生命週期事件。 **注意** 為求簡化，此圖表不會顯示 Deregistering (正在取消註冊) 和 Deleted (已刪除) 狀態。您可以取消註冊圖表中任何狀態的執行個體，這會將取消註冊命令傳送至執行個體，並將其移至 Deregistering (正在取消註冊) 狀態。如果您取消註冊線上執行個體， OpsWorks Stacks 會將 Configure 命令傳送至堆疊中的其餘執行個體，以通知他們執行個體正在離線。確認取消註冊命令之後，執行個體仍在執行中，但會處於 Deleted (已刪除) 狀態，且不再是堆疊的一部分。如果您想要將執行個體再次納入堆疊，您必須重新註冊。 **Topics** + [正在註冊](#registered-instances-lifecycle-registering) + [安裝執行中](#registered-instances-lifecycle-running-setup) + [已登記](#registered-instances-lifecycle-registered) + [正在指派](#registered-instances-lifecycle-assigning) + [線上](#registered-instances-lifecycle-online) + [安裝失敗](#registered-instances-lifecycle-setup-failed) + [正在取消指派](#registered-instances-lifecycle-unassigning) + [初始安裝組態變更](#registered-instances-lifecycle-setup-config) ## 正在註冊代理程式傳送註冊請求後， OpsWorks Stacks 會傳送設定命令至執行個體，使其進入註冊狀態，以啟動執行個體生命週期。執行個體確認安裝命令之後，便會移至 [安裝執行中](#registered-instances-lifecycle-running-setup) 狀態。 ## 安裝執行中 Running Setup (安裝執行中) 狀態會執行執行個體的安裝配方。安裝運作與否，取決於先前狀態。 **注意** 如果您在執行個體處於執行中設定狀態時取消指派執行個體， OpsWorks Stacks 會傳送 Shutdown 命令，該命令會執行執行個體的關機配方，但不會停止執行個體。執行個體會移至 [正在取消指派](#registered-instances-lifecycle-unassigning) 狀態。 **Topics** + [正在註冊](#registered-instances-lifecycle-running-setup-registering) + [正在指派](#registered-instances-lifecycle-running-setup-assigning) + [安裝失敗](#registered-instances-lifecycle-running-setup-failed) ### 正在註冊在註冊程序期間，設定會建立 OpsWorks Stacks 執行個體來代表堆疊中已註冊的執行個體，並在執行個體上執行一組核心設定配方。初始安裝所執行的一項重要變更是覆寫執行個體的主機檔案。藉由註冊執行個體，您會將使用者管理移交給 OpsWorks Stacks，其必須具有自己的主機檔案才能控制 SSH 登入許可。初始安裝也會建立或修改一些檔案，並在 Ubuntu 系統上修改套件來源及安裝一組套件。如需詳細資訊，請參閱[初始安裝組態變更](#registered-instances-lifecycle-setup-config)。在註冊期間，程序會呼叫 IAM`AttachUserPolicy`，該 IAM 是附加至您建立為先決條件的 IAM 使用者之許可的一部分。如果 `AttachUserPolicy` 不存在 (最可能的原因是您執行舊版 AWS CLI)，則程序會回到呼叫 `PutUserPolicy`。 **注意** 為了保持一致性， OpsWorks Stacks 會執行每個核心設定配方。不過，其中一些配方只會在執行個體已指派給至少一 layer 時執行其部分或所有任務，因此不一定會影響初始安裝。 + 如果安裝成功，執行個體會移至 [已登記](#registered-instances-lifecycle-registered) 狀態。 + 如果安裝失敗，執行個體會移至 [安裝失敗](#registered-instances-lifecycle-setup-failed) 狀態。 ### 正在指派執行個體至少有一個指派的 layer。 OpsWorks Stacks 會執行每個 layer 的設定配方，包括您[指派給 layer 設定事件](workingcookbook-executing.md)的任何自訂配方。 + 如果安裝成功，執行個體會移至 Online (線上) 狀態，而且 OpsWorks Stacks 會在堆疊中的每個執行個體上觸發設定生命週期事件，以通知它們有此新的執行個體。 + 如果安裝失敗，執行個體會移至 Setup Failed (安裝失敗) 狀態。 **注意** 此安裝程序會再次執行核心配方。不過，Chef 配方為等冪操作，因此不會重複已執行的任何任務。 ### 安裝失敗如果 [正在指派](#registered-instances-lifecycle-assigning) 狀態之執行個體的安裝程序失敗，您可以使用[安裝堆疊命令](workingstacks-commands.md)再試一次，來手動重新執行執行個體的安裝配方。 + 如果安裝成功，指派的執行個體會移至 [線上](#registered-instances-lifecycle-online) 狀態，而且 OpsWorks Stacks 會在堆疊中的每個執行個體上觸發設定生命週期事件，以通知它們有此新的執行個體。 + 如果安裝嘗試失敗，執行個體會移回 Setup Failed (安裝失敗) 狀態。 ## 已登記處於已註冊狀態的執行個體是堆疊的一部分，由 Stacks OpsWorks 管理，但不會指派給 layer。它們可以無限期地保持在此狀態。如果您將執行個體指派給一或多個 layer， OpsWorks Stacks 會傳送設定命令給執行個體，並移至 [正在指派](#registered-instances-lifecycle-assigning) 狀態。 ## 正在指派執行個體確認安裝命令之後，便會移至 [安裝執行中](#registered-instances-lifecycle-running-setup) 狀態。如果您在執行個體處於指派狀態時取消指派執行個體， OpsWorks Stacks 會終止設定程序並傳送關機命令。執行個體會移至 [正在取消指派](#registered-instances-lifecycle-unassigning) 狀態。 ## 線上執行個體現在是至少一 layer 的成員，並會視為一般 OpsWorks Stacks 執行個體。它可以無限期地保持在此狀態。如果您在執行個體處於線上狀態時取消指派執行個體， OpsWorks Stacks 會將 Shutdown 命令傳送至執行個體，並將 Configure 命令傳送至堆疊的其餘執行個體。執行個體會移至 [正在取消指派](#registered-instances-lifecycle-unassigning) 狀態。 ## 安裝失敗安裝命令失敗。 + 您可以執行[安裝堆疊命令](workingstacks-commands.md)再試一次。執行個體會返回 [安裝執行中](#registered-instances-lifecycle-running-setup) 狀態。 + 如果您取消指派執行個體， OpsWorks Stacks 會將 Shutdown 命令傳送至執行個體。執行個體會移至 [正在取消指派](#registered-instances-lifecycle-unassigning) 狀態。 ## 正在取消指派關機命令完成之後，執行個體將不再指派給任一 layer，並會返回 [已登記](#registered-instances-lifecycle-registered) 狀態。 **注意** 如果將執行個體指派給多 layer，取消指派會套用至每一 layer；您無法取消指派一小部分指派 layer。如果您想要一組不同的指派 layer，請取消指派執行個體，然後重新指派所需 layer。 ## 初始安裝組態變更初始安裝會建立或修改所有已註冊執行個體上的下列檔案和目錄。 **建立的檔案** ``` /etc/apt/apt.conf.d/99-no-pipelining /etc/aws/ /etc/init.d/opsworks-agent /etc/motd /etc/motd.opsworks-static /etc/sudoers.d/opsworks /etc/sudoers.d/opsworks-agent /etc/sysctl.d/70-opsworks-defaults.conf /opt/aws/opsworks/ /usr/sbin/opsworks-agent-cli /var/lib/aws/ /var/log/aws/ /vol/ ``` **修改的檔案** ``` /etc/apt/apt.conf.d/99-no-pipelining /etc/crontab /etc/default/monit /etc/group /etc/gshadow /etc/monit/monitrc /etc/passwd /etc/security/limits.conf (removing limits only for EC2 micro instances) /etc/shadow /etc/sudoers ``` 初始設定也會在 Amazon EC2 微型執行個體上建立交換檔案。初始安裝會對 Ubuntu 系統進行下列變更。套件來源初始安裝會將套件來源變更如下。 + `deb http://archive.ubuntu.com/ubuntu/ ${code_name} main universe` 收件人： `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name} main universe` + `deb http://archive.ubuntu.com/ubuntu/ ${code_name}-updates main universe` 收件人： `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name}-updates main universe` + `deb http://archive.ubuntu.com/ubuntu ${code_name}-security main universe` 收件人： `deb-src http://archive.ubuntu.com/ubuntu ${code_name}-security main universe` + `deb http://archive.ubuntu.com/ubuntu/ ${code_name}-updates multiverse` 收件人： `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name}-updates multiverse` + `deb http://archive.ubuntu.com/ubuntu ${code_name}-security multiverse` 收件人： `deb-src http://archive.ubuntu.com/ubuntu ${code_name}-security multiverse` + `deb http://archive.ubuntu.com/ubuntu/ ${code_name} multiverse` 收件人： `deb-src http://archive.ubuntu.com/ubuntu/ ${code_name} multiverse` + `deb http://security.ubuntu.com/ubuntu ${code_name}-security multiverse` 收件人： `deb-src http://security.ubuntu.com/ubuntu ${code_name}-security multiverse` 套件初始安裝會解除安裝 `landscape` 並安裝下列套件。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/registered-instances-lifecycle.html) # 編輯執行個體組態 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以編輯執行個體組態，包括[已註冊的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體](registered-instances.md)，但有下列限制： + 執行個體必須處於停止狀態。雖然您無法修改線上執行個體的屬性，但您可以透過編輯執行個體的 layer 來變更其組態的一部分。如需詳細資訊，請參閱[編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md)。 + 有些設定 (例如 **Availability Zone (可用區域)** 和 **Scaling Type (擴展類型)**) 是在您建立執行個體時決定的，之後便無法修改。 + 某些設定只能針對執行個體後端執行個體進行修改，不適用於 Amazon Elastic Block Store 後端執行個體。例如，您可以變更執行個體後端執行個體的作業系統。Amazon EBS 後端執行個體必須使用您在建立執行個體時指定的作業系統。如需執行個體儲存體的詳細資訊，請參閱[儲存體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)。 + 根據預設，執行個體會繼承[堆疊的代理程式版本](workingstacks-creating.md#workingstacks-creating-advanced-agent)設定。您可以使用 **OpsWorks Agent Version (OpsWorks 代理程式版本)** 覆寫堆疊的代理程式版本設定，並為執行個體指定特定的代理程式版本。如果您指定執行個體的代理程式版本， OpsWorks 即使堆疊的代理程式版本設定為**自動**更新，Stacks 也不會在有新版本可用時自動更新代理程式。您必須編輯執行個體組態，手動更新執行個體的代理程式版本。然後， OpsWorks Stacks 會在執行個體上安裝指定的代理程式版本。 **注意** 您無法編輯已註冊現場部署執行個體的組態。 **編輯執行個體組態** 1. 停止執行個體 (若還未停止的話)。 1. 在 **Instances (執行個體)** 頁面上，按一下執行個體名稱以顯示 **Details (詳細資訊)** 頁面。 1. 按一下 **Edit (編輯)** 顯示編輯頁面。 1. 妥善編輯執行個體的組態。如需 **Host name (主機名稱)**、**Size (大小)**、**SSH key (SSH 金鑰)** 和 **Operating system (作業系統)** 設定的說明，請參閱[將執行個體新增至 Layer](workinginstances-add.md)。**Layers (Layer)** 設定可讓您新增或移除 layer。執行個體目前的 layer 會出現在 layer 的清單之後。 + 若要新增另外一 layer，請從清單中選取它。 + 若要從其中一個 layer 移除執行個體，請按一下適當 layer 旁邊的 **x**。執行個體必須至少是一個 layer 的成員，因此您無法移除最後一個 layer。當您重新啟動執行個體時， OpsWorks Stacks 會使用更新後的組態啟動新的 Amazon EC2 執行個體。 # 刪除 OpsWorks Stacks 執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用 OpsWorks Stacks 來停止執行個體，包括[已註冊的 Amazon EC2 執行個體](registered-instances.md)。執行此作業會停止 EC2 執行個體，但執行個體仍會留在堆疊中。您可以在執行個體**的動作**欄中按一下**開始**來重新啟動它。如果您不再需要執行個體，並想要將其從堆疊中移除，則可以將其刪除，這會從堆疊中移除執行個體並終止相關聯的 Amazon EC2 執行個體。刪除執行個體也會刪除任何相關聯的日誌或資料，以及執行個體上的任何 Amazon Elastic Block Store (EBS) 磁碟區。 **重要** 本主題僅適用於由 Stacks 管理的 Amazon EC2 OpsWorks 執行個體。如需如何刪除由 Amazon EC2 主控台或 API 管理之執行個體的詳細資訊，請參閱[終止您的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html)。 **注意** 您無法使用 OpsWorks Stacks 刪除已註冊的內部部署執行個體。若執行個體屬於多個 layer，您可以從堆疊刪除執行個體，或是只移除特定的 layer。您也可以透過編輯執行個體組態，來從執行個體移除 layer，如[編輯執行個體組態](workinginstances-properties.md)中所說明。 **重要** 您只能使用 OpsWorks Stacks 主控台或 API 刪除 OpsWorks Stacks 執行個體。特別是，您不應使用 OpsWorks Amazon EC2 主控台或 API 刪除 Stacks 執行個體，因為 Amazon EC2 OpsWorks 動作不會自動與 Stacks 同步。例如，如果已啟用自動修復，而您使用 Amazon EC2 主控台終止執行個體， OpsWorks Stacks 會將終止的執行個體視為失敗的執行個體，並啟動另一個 Amazon EC2 執行個體來取代它。如需詳細資訊，請參閱[使用自動修復](workinginstances-autohealing.md)。 **刪除執行個體** 1. 在 **Instances (執行個體)** 頁面上，在適當的 layer 底下尋找執行個體。若執行個體正在執行中，請在 **Actions (動作)** 資料行中按一下 **stop (停止)**。 1. 在狀態變更為 **stopped (已停止)** 時，按一下 **delete (刪除)**。如果執行個體是多個 layer 的成員， layer OpsWorks Stacks 會顯示下列區段。 ![\[屬於多個 layer 執行個體 Instances (執行個體) 頁面上的刪除動作\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/delete_instance_multiple.png) + 若要僅從選取的 layer 移除執行個體，請按一下 **Remove from layer (從 layer 移除)**。執行個體仍然會是其他 layer 的成員，可重新啟動。 + 若要從所有 layer 刪除執行個體，並從堆疊中移除它，請按一下 **here (這裡)**。 1. 如果您選擇從堆疊完全移除執行個體，或者如果執行個體只是一個 layer 的成員， OpsWorks Stacks 會提示您確認刪除。選擇**刪除**以確認刪除。除了從堆疊刪除執行個體之外，此動作會刪除所有相關的日誌或資料，以及附加至執行個體的根磁碟區。若要移除所有執行個體磁碟區，請選擇**刪除執行個體的 EBS 磁碟區（快照將不會刪除）**，然後再選擇**刪除**。 # 使用 SSH 登入 Linux 執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以搭配內建的 MindTerm 用戶端或第三方用戶端 (例如 PuTTY)，使用 SSH 登入您的線上 Linux 執行個體。SSH 通常依存於身分驗證的 RSA 金鑰對。您會在執行個體上安裝公有金鑰，並將對應的私有金鑰提供給 SSH 用戶端。 OpsWorks Stacks 會為您在堆疊的執行個體上安裝公有金鑰，如下所示。 + Amazon Elastic Compute Cloud (Amazon EC2) 金鑰對 – 如果堆疊的區域有一或多個 Amazon EC2 金鑰對，您可以[指定堆疊的預設 SSH 金鑰對](workingstacks-creating.md)。您可以選擇性的在建立執行個體時覆寫預設金鑰對，及指定不同的金鑰對。無論哪種情況， OpsWorks Stacks 都會在執行個體上安裝指定的金鑰對公有金鑰。如需如何建立 Amazon EC2 金鑰對的詳細資訊，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。 + 個人金鑰對 – 每個使用者可以向 OpsWorks Stacks [註冊個人金鑰對](security-settingsshkey.md)。使用者或管理員向 Stacks OpsWorks 註冊公有金鑰，使用者將私有金鑰存放在本機。在設定堆疊的許可時，管理員會指定哪些使用者應具備堆疊執行個體的 SSH 存取。 OpsWorks Stacks 會自動為每個授權使用者在堆疊的執行個體上建立系統使用者，並安裝使用者的個人公有金鑰。使用者必須具備 SSH 授權，才能使用 MindTerm SSH 用戶端，或使用他們的個人金鑰對登入堆疊的執行個體。 **為使用者授權 SSH** 1. 在 OpsWorks 堆疊導覽窗格中，按一下**許可**。 1. 為所需的 IAM 使用者選取 **SSH/RDP**，以授予必要的許可。如果您想要允許使用者使用 `sudo` 提升權限，例如執行[代理程式 CLI](agent.md) 命令，請同時選取 **sudo/admin**。 ![\[使用者的 SSH 與 sudo 許可\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions.png) 如需如何使用 OpsWorks Stacks 管理 SSH 存取的詳細資訊，請參閱 [管理 SSH 存取](security-ssh-access.md)。 **Topics** + [使用內建的 MindTerm SSH 用戶端](workinginstances-ssh-mindterm.md) + [使用第三方 SSH 用戶端](workinginstances-ssh-third.md) # 使用內建的 MindTerm SSH 用戶端 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。登入 Linux 執行個體最簡單的方式，便是使用內建的 MindTerm SSH 用戶端。每個線上執行個體都包含一個 **ssh** 動作，可讓您用來啟動 MindTerm 用戶端。 **注意** 您必須在您的瀏覽器中啟用 Java，才能使用 MindTerm 用戶端。 **使用 MindTerm 用戶端登入** 1. 若您尚未執行此作業，請授權要連線到執行個體之 IAM 使用者的 SSH 存取，如上一節所述。 1. 以使用者身分登入。 1. 在 **Instances (執行個體)** 頁面上，在適當執行個體的 **Actions (動作)** 資料行中選擇 **ssh**。 ![\[Instances (執行個體) 頁面上的 ssh 動作\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/ssh.png) 1. 對於**私有金鑰**，提供使用者個人私有金鑰或 Amazon EC2 私有金鑰的路徑，取決於您在執行個體上安裝的公有金鑰。 1. 選擇 **Launch Mindterm (啟動 Mindterm)**，然後使用終端機視窗在執行個體上執行命令。 # 使用第三方 SSH 用戶端 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您也可以使用第三方 SSH 用戶端 (例如 PuTTY) 連線到 Linux 執行個體。 **使用第三方 SSH 用戶端** 1. 請確定 OpsWorks Stacks 已在執行個體上安裝 Amazon EC2 公有金鑰或 IAM 使用者的個人公有金鑰，如前所述。 1. 從其詳細資訊頁面，取得執行個體的公有 DNS 名稱或公有 IP 地址。 1. 根據作業系統，提供用戶端執行個體的主機名稱，如下所示： + Amazon Linux 和 Red Hat Enterprise Linux (RHEL)– `ec2-user@DNSName/Address.` + Ubuntu – `ubuntu@DNSName/Address`。將 *DNSName/Address* 取代為先前步驟中的公有 DNS 名稱或 IP 地址。 1. 提供用戶端對應至已安裝公有金鑰的私有金鑰。您可以根據執行個體上安裝的公有金鑰，使用 Amazon EC2 私有金鑰或 IAM 使用者的個人私有金鑰。 # 使用 RDP 登入 Windows 執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用 Windows 遠端桌面通訊協定 (RDP) 登入線上 Windows 執行個體，如下所示： + 執行個體必須具有允許 RDP 存取之入站規則的安全群組。如需使用安全群組的詳細資訊，請參閱[使用安全群組](workingsecurity-groups.md)。 + 一般使用者 – OpsWorks Stacks 為授權的一般使用者提供在有限期間內有效的 RDP 密碼，範圍可從 30 分鐘到 12 小時。除了獲得授權之外，使用者必須至少具有[顯示許可層級](opsworks-security-users-console.md)，或其連接的 AWS Identity and Access Management (IAM) 政策必須允許 `opsworks:GrantAccess`動作。 + 管理員 – 您可以使用管理員密碼無限時間登入。如稍後所述，如果您已為執行個體指定 Amazon Elastic Compute Cloud (Amazon EC2) 金鑰對，您可以使用它來擷取管理員密碼。 **注意** 本主題說明如何使用 Windows 遠端桌面連線用戶端從 Windows 工作站登入。您也可以使用其中一個 Linux 或 OS X 可用的 RDP 用戶端，但程序可能會有些不同。如需與 Microsoft Windows Server 2012 R2 相容之 RDP 用戶端的詳細資訊，請參閱 [Microsoft 遠端桌面用戶端](https://technet.microsoft.com/en-us/library/dn473009.aspx)。 **Topics** + [提供允許 RDP 存取的安全群組](#workinginstances-rdp-rdp-ingress) + [以一般使用者身分登入](#workinginstances-rdp-ordinary) + [以管理員身分登入](#workinginstances-rdp-admin) ## 提供允許 RDP 存取的安全群組在您使用 RDP 登入 Windows 執行個體前，執行個體的安全群組入站規則必須允許 RDP 連線。當您在區域中建立第一個堆疊時， OpsWorks Stacks 會建立一組安全群組。其中包括一個名為的物件`AWS-OpsWorks-RDP-Server`，例如， Stacks OpsWorks 會連接到所有 Windows 執行個體以允許 RDP 存取。不過，此安全群組預設沒有任何規則，因此您必須新增傳入規則來允許 RDP 存取您的執行個體。 **允許 RDP 存取** 1. 開啟 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/v2/)，將其設定為堆疊的區域，然後從導覽窗格中選擇**安全群組**。 1. 選取 **AWS-OpsWorks-RDP-Server**，選擇 **Inbound (入站)** 標籤，然後選擇 **Edit (編輯)**。 1. 選擇 **Add Rule (新增規則)**，然後指定下列設定： + **類型** – **RDP** + **來源** – 允許的來源 IP 地址。通常，您會允許來自您 IP 地址或指定 IP 地址範圍 (通常是公司的 IP 地址範圍) 的傳入 RDP 請求。 ## 以一般使用者身分登入授權使用者可使用 OpsWorks Stacks 提供的暫時密碼登入執行個體。 **為使用者授權 RDP；** 1. 在 Stacks OpsWorks 導覽窗格中，按一下**許可**。 1. 選取所需使用者的 **SSH/RDP** 核取方塊，以授予必要的許可。若您希望使用者具有管理員許可，您也應選取 **sudo/admin**。 ![\[使用者的 SSH 與 sudo 許可\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions.png) 已授權的使用者可登入任何堆疊的線上執行個體，如下所示。 **以一般 IAM 使用者身分登入** 1. 以 IAM 使用者身分登入。 1. 在 **Instances (執行個體)** 頁面上，在適當執行個體的 **Actions (動作)** 資料行中選擇 **rdp**。 1. 指定工作階段長度，範圍可從 30 分鐘至 12 小時，然後選擇 **Generate Password (產生密碼)**。密碼只會在指定的工作階段期間內有效。 1. 記錄 **public DNS name (公有 DNS 名稱)**、**username (使用者名稱)** 及 **password (密碼)** 的值，然後選擇 **Acknowledge and close (確認並關閉)**。 1. 開啟 Windows 遠端桌面連線用戶端，選擇 **Show Options (顯示選項)**，並從您在步驟 4 記錄的資訊提供下列項目： + **電腦** – 執行個體的公有 DNS 名稱。若您希望的話，您也可以使用公有 IP 地址。選擇 **Instances (執行個體)** 並從執行個體的 **Public IP (公有 IP)** 資料行複製地址。 + **使用者名稱** – 使用者名稱。 1. 當用戶端提示您提供登入資料時，輸入您在步驟 4 儲存的密碼。 **注意** OpsWorks Stacks 只會為線上執行個體產生使用者密碼。若您啟動執行個體並且假設您其中一個自訂安裝配方失敗，執行個體將會處於 `setup_failed` 狀態。即使執行個體就 Stacks 而言並不在線上，EC2 OpsWorks 執行個體正在執行中，而且通常有助於對問題進行故障診斷。在此情況下， OpsWorks Stacks 不會為您產生密碼，但如果您已將 SSH 金鑰對指派給執行個體，您可以使用 EC2 主控台或 CLI 來擷取執行個體的管理員密碼，並以管理員身分登入。如需詳細資訊，請參閱下一節。 ## 以管理員身分登入您可以透過使用適當的密碼，以管理員身分登入執行個體。如果您已將 EC2 金鑰對指派給執行個體，Amazon EC2 會使用它在執行個體啟動時自動建立和加密管理員密碼。您接著便可搭配 EC2 主控台、API 或 CLI，使用金鑰對的私有金鑰擷取和解密密碼。 **注意** 您無法使用[個人 SSH 金鑰對](security-ssh-access.md)擷取管理員密碼。您必須使用 EC2 金鑰對。以下說明如何使用 EC2 主控台擷取管理員密碼並登入執行個體。若您偏好使用命令列工具，您也可以使用 AWS CLI 的 `[get-password-data](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-password-data.html)` 命令擷取密碼。 **以管理員身分登入** 1. 確認您已為執行個體指定 EC2 金鑰對。您可以在建立堆疊時[為所有堆疊的執行個體指定預設金鑰對](workingstacks-creating.md)，或是在您建立執行個體時[為特定執行個體指定金鑰對](workinginstances-add.md)。 1. 開啟 [EC2 主控台](https://console.aws.amazon.com/ec2/v2/)，將其設為堆疊的區域，然後從導覽窗格選擇 **Instances (執行個體)**。 1. 選取執行個體，選擇 **Connect (連線)**，然後選擇 **Get Password (取得密碼)**。 1. 提供您工作站上指向 EC2 金鑰對私有金鑰的路徑，然後選擇 **Decrypt Password (解密密碼)**。複製解密後的密碼，將於稍後使用。 1. 開啟 Windows 遠端桌面連線用戶端，選擇 **Show Options (顯示選項)**，並提供下列資訊： + **電腦** – 執行個體的公有 DNS 名稱或公有 IP 地址，您可以從執行個體的詳細資訊頁面取得。 + **使用者名稱** – `Administrator`。 1. 當用戶端提示您提供登入資料時，提供您在步驟 4 取得的解密密碼。 # 應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks *應用程式*代表您想要在應用程式伺服器上執行的程式碼。程式碼本身位於儲存庫中，例如 Amazon S3 封存；應用程式包含將程式碼部署至適當應用程式伺服器執行個體所需的資訊。當您部署應用程式時， OpsWorks Stacks 會觸發部署事件，執行每一層的部署配方。 OpsWorks Stacks 也會安裝[堆疊組態和部署屬性](workingcookbook-json.md)，其中包含部署應用程式所需的所有資訊，例如應用程式的儲存庫和資料庫連線資料。您必須實作自訂配方，從堆疊組態和部署屬性擷取應用程式的部署資料，以及處理部署任務。 **Topics** + [新增應用程式](workingapps-creating.md) + [部署應用程式](workingapps-deploying.md) + [編輯應用程式](workingapps-editing.md) + [將應用程式連線至資料庫伺服器](workingapps-connectdb.md) + [使用環境變數](apps-environment-vars.md) + [傳遞資料到應用程式](apps-data.md) + [使用 Git 儲存庫 SSH 金鑰](workingapps-deploykeys.md) + [使用自訂網域](workingapps-domains.md) + [使用 SSL](workingsecurity-ssl.md) # 新增應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要將應用程式部署到您的應用程式伺服器，第一個步驟是將應用程式新增至堆疊。app 代表應用程式，並包含各式各樣的中繼資料，例如應用程式的名稱和類型，以及將應用程式部署至伺服器執行個體所需的資訊，例如儲存庫 URL。您必須具有管理許可才能將應用程式新增至堆疊。如需詳細資訊，請參閱[管理使用者許可](opsworks-security-users.md)。 **注意** 本節中的程序適用於 Chef 12 和更新的堆疊。如需如何在 Chef 11 堆疊中將應用程式新增至 layer 的資訊，請參閱[步驟 2.4：建立和部署應用程式 - Chef 11](gettingstarted-simple-app.md)。 **將應用程式新增至堆疊** 1. 將程式碼放在您偏好的儲存庫中：Amazon S3 封存、Git 儲存庫、Subversion 儲存庫或 HTTP 封存。如需詳細資訊，請參閱[應用程式來源](#workingapps-creating-source)。 1. 按一下導覽窗格中的 **Apps (應用程式)**。針對您的第一個應用程式，在 **Apps (應用程式)** 頁面中，按一下 **Add an app (新增應用程式)**。針對後續的應用程式，按一下 **\$1App (\$1應用程式)**。 1. 使用 **App New (新的應用程式)** 頁面來設定應用程式，如下節中所述。 ## 設定應用程式 **Add App (新增應用程式)** 頁面包含下列區段：**Settings (設定)**、**Application source (應用程式來源)**、**Data Sources (資料來源)**、**Environment Variables (環境變數)**、**Add Domains (新增網域)** 和 **SSL Settings (SSL 設定)**。 **Topics** + [設定](#workingapps-creating-settings) + [應用程式來源](#workingapps-creating-source) + [資料來源](#workingapps-creating-data) + [環境變數](#workingapps-creating-environment) + [網域和 SSL 設定](#workingapps-creating-domain-ssl) ### 設定 **名稱** 應用程式名稱，用於在 UI 中代表應用程式。 OpsWorks Stacks 也會使用此名稱為內部使用的應用程式產生簡短名稱，並在[堆疊組態和部署屬性](workingcookbook-json.md)中識別應用程式。將應用程式新增至堆疊之後，您可以按一下導覽窗格中的 **Apps (應用程式)**，然後按一下應用程式名稱開啟詳細資訊頁面，以查看短名。 ****Document root (文件根)**** OpsWorks Stacks 會將**文件根**設定指派給應用程式[`[:document_root]`](attributes-json-deploy.md#attributes-json-deploy-app-root)屬性中的 `deploy` 屬性。預設值為 `null`。您的部署配方可以使用標準 Chef 節點語法，從 `deploy` 屬性取得該值，並將指定的程式碼部署到伺服器的適當位置。如需如何部署應用程式的詳細資訊，請參閱[部署配方](create-custom-deploy.md)。 ### 應用程式來源您可以從下列儲存庫類型部署應用程式：Git、Amazon S3 套件、HTTP 套件和其他。所有儲存庫類型都要求您必須指定儲存庫類型和儲存庫 URL。個別儲存庫類型都有自己的要求，如下所示。 **注意** OpsWorks Stacks 會自動將應用程式從標準儲存庫部署到內建伺服器層。如果您使用其他儲存庫類型，這是 Windows 堆疊的唯一選項， OpsWorks Stacks 會將儲存庫資訊放在應用程式的[`deploy`屬性](workingcookbook-json.md#workingcookbook-json-deploy)中，但您必須實作自訂配方來處理部署任務。 **Topics** + [HTTP 封存](#w2ab1c14c57c13c11b8b8) + [Amazon S3 封存](#w2ab1c14c57c13c11b8c10) + [Git 儲存庫](#w2ab1c14c57c13c11b8c12) + [其他儲存庫](#w2ab1c14c57c13c11b8c14) #### HTTP 封存若要使用可公開存取的 HTTP 伺服器做為儲存庫： 1. 針對包含應用程式程式碼和任何相關聯檔案的資料夾，建立壓縮封存檔 -zip、gzip、bzip2、Java WAR 或 tarball。 **注意** OpsWorks Stacks 不支援未壓縮的 tarball。 1. 將封存檔案上傳至伺服器。 1. 若要在主控台中指定儲存庫，請選取 HTTP Archive (HTTP 封存) 做為儲存庫類型並輸入 URL。如果封存受到密碼保護，請在**應用程式來源**下指定登入憑證。 #### Amazon S3 封存若要使用 Amazon Simple Storage Service 儲存貯體做為儲存庫： 1. 建立公有或私有 Amazon S3 儲存貯體。如需詳細資訊，請參閱 [Amazon S3 文件](https://aws.amazon.com/documentation/s3/)。 1. 若要讓 OpsWorks Stacks 存取私有儲存貯體，您必須是對 Amazon S3 儲存貯體具有至少唯讀權限的使用者，而且您將需要存取金鑰 ID 和私密存取金鑰。如需詳細資訊，請參閱 [AWS Identity and Access Management 文件](https://docs.aws.amazon.com/iam/)。 1. 將程式碼和任何相關聯的檔案放入資料夾，並將該資料夾存放到壓縮封存 (zip、gzip、bzip2、Java WAR 或 tarball) 中。 **注意** OpsWorks Stacks 不支援未壓縮的 tarball。 1. 將封存檔案上傳至 Amazon S3 儲存貯體並記錄 URL。 1. 若要在 Stacks OpsWorks 主控台中指定儲存庫，請將**儲存庫類型**設定為 **S3 Archive**，然後輸入封存的 URL。若是私有封存，您也必須提供 AWS 存取金鑰 ID 和私密存取金鑰，其政策可授予存取儲存貯體的許可。若是公有封存，則將這些設定保留空白。 #### Git 儲存庫 [Git](http://git-scm.com/) 儲存庫提供來源控制和版本控制。 OpsWorks Stacks 支援公有託管儲存庫網站，例如 [GitHub](https://github.com/) 或 [Bitbucket](https://bitbucket.org)，以及私有託管的 Git 伺服器。若是應用程式和 Git 子模組，您用來在 **Application Source (應用程式來源)** 中指定儲存庫的 URL 格式則取決於儲存庫為公有或私有： **公有儲存庫** – 使用 HTTPS 或 Git 唯讀通訊協定。例如，[Chef 11 Linux 堆疊入門](gettingstarted.md) 會使用公有 GitHub 儲存庫，其可透過下列任一 URL 格式來存取： + Git 唯讀：**git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** + HTTPS：**https://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** **私有儲存庫** – 使用以下範例中顯示的 SSH 讀取/寫入格式： + Github 儲存庫：**git@github.com:*project*/*repository***。 + 位於 Git 伺服器上的儲存庫：***user*@*server*:*project*/*repository*** 在 **Source Control (來源控制)** 下方選取 **Git** 時，會顯示兩個額外的選擇性設定： **Repository SSH key (儲存庫 SSH 金鑰)** 您必須指定部署 SSH 金鑰才能存取私有 Git 儲存庫。此欄位需要私有金鑰；公有金鑰會指派到您的 Git 儲存庫。針對 Git 子模組，指定的金鑰必須要能存取這些子模組。如需詳細資訊，請參閱[使用 Git 儲存庫 SSH 金鑰](workingapps-deploykeys.md)。部署的 SSH 金鑰不需要密碼； OpsWorks Stacks 無法傳遞密碼。 **Branch/Revision (分支/修訂)** 如果儲存庫有多個分支， OpsWorks Stacks 預設會下載主分支。若要指定特定分支，請輸入分支名稱、SHA1 雜湊或標籤名稱。若要指定特定的遞交，請輸入完整 40 個八進位碼的遞交識別符。 #### 其他儲存庫如果標準儲存庫不符合您的需求，您可以使用其他儲存庫，例如 [Bazaar](http://bazaar.canonical.com/en/)。不過， OpsWorks Stacks 不會自動從這類儲存庫部署應用程式。您必須實作自訂配方來處理部署程序，並將這些配方指派給適當 layer 的部署事件。如需如何實作部署配方的範例，請參閱[部署配方](create-custom-deploy.md)。 ### 資料來源此區段會將資料庫連接到應用程式。您有下列選項： + **RDS** – 連接其中一個堆疊的 [Amazon RDS 服務層](workinglayers-db-rds.md)。 + **無** – 請勿連接資料庫伺服器。如果您選取 **RDS**，則必須指定下列項目。 **資料庫執行個體** 此清單包含每個 Amazon RDS 服務層。您也可以選取下列之一： (必要) 指定哪部資料庫伺服器連接到應用程式。清單內容取決於資料來源而定。 + **RDS** – 堆疊的 Amazon RDS 服務層清單。 **資料庫名稱** (選用) 指定資料庫名稱。 + Amazon RDS layer – 輸入您為 Amazon RDS 執行個體指定的資料庫名稱。您可以從 [Amazon RDS 主控台](https://console.aws.amazon.com/rds/)取得資料庫名稱。當您使用連接的資料庫部署應用程式時， OpsWorks Stacks 會將資料庫執行個體的連線新增至應用程式的[`deploy`屬性](workingcookbook-json.md#workingcookbook-json-deploy)。您可以編寫自訂配方，以從 `deploy` 屬性擷取資訊，並將資訊放入可供應用程式存取的檔案中。這是將資料庫連線資訊提供給其他應用程式類型的唯一選項。如需如何處理資料庫連線的詳細資訊，請參閱[連線至資料庫](workingapps-connectdb.md)。若要將資料庫伺服器與應用程式分離，請[編輯應用程式的組態](workingapps-editing.md)以指定不同的資料庫伺服器，或不指定任何伺服器。 ### 環境變數您可以為每個應用程式指定一組環境變數，以專屬於該應用程式。例如，如果您有兩個應用程式，則第二個應用程式無法使用您為第一個應用程式定義的環境變數，反之亦然。您也可以為多個應用程式定義相同的環境變數，並為每個應用程式指派不同的值。 **注意** 環境變數的數目並沒有特定限制。不過，包含變數名稱、值和受保護標記值的相關聯資料結構大小不得超過 20 KB。此限制應該可以容納大多數的使用案例。超過此限制時會導致服務錯誤 (主控台)，或含下列訊息的例外狀況 (API)："Environment: is too large (maximum is 20KB)" (環境：太大 (上限為 10 KB))。 OpsWorks Stacks 會將變數儲存為應用程式屬性中的[`deploy`屬性](workingcookbook-json.md#workingcookbook-json-deploy)。您可以使用標準 Chef 節點語法，讓您的自訂配方擷取這些值。如需如何存取應用程式環境變數的範例，請參閱[使用環境變數](apps-environment-vars.md)。 **金錀** 變數名稱。它最多可以包含 64 個大小寫字母、數字和底線 (\$1)，但必須以字母或底線開頭。 **Value** 變數值。它最多可以包含 256 個字元，且全都必須為可列印字元。 **受保護的值** 值是否受保護。此設定可讓您隱藏密碼之類的敏感資訊。如果您在建立應用程式之後，為變數設定 **Protected value (受保護的值)**： + 應用程式的詳細資訊頁面只會顯示變數名稱，而非值。 + 如果您有編輯應用程式的許可，則可以按一下 **Update value (更新值)** 來指定新的值，但您無法查看或編輯舊值。 **注意** Chef 部署日誌有時可能包含環境變數。這表示受保護的變數可能會顯示在主控台。為了防止受保護的變數顯示在主控台中，我們建議您使用 Amazon S3 儲存貯體做為您不想在主控台中顯示的受保護變數的儲存體。S3 儲存貯體如何用於此用途，請參閱本指南中的[使用 Amazon S3 儲存貯體](gettingstarted.walkthrough.photoapp.md)。 ### 網域和 SSL 設定對於其他應用程式類型， OpsWorks Stacks 會將設定新增至應用程式的`deploy`屬性。您的配方可以從這些屬性擷取資料，並視需要設定伺服器。 **網域設定** 此區段有一個選用的 **Add Domains (新增網域)** 欄位，可用來指定網域。如需詳細資訊，請參閱[使用自訂網域](workingapps-domains.md)。 **SSL 設定** 此區段有一個 **SSL Support (SSL 支援)** 切換，可讓您用來啟用或停用 SSL。如果您按一下 **Yes (是)**，則需要提供 SSL 憑證資訊。如需詳細資訊，請參閱[使用 SSL](workingsecurity-ssl.md)。 # 部署應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。部署的主要目的是將應用程式程式碼和相關檔案部署到應用程式伺服器執行個體。部署操作會由每個執行個體的部署配方處理，該配方則由執行個體的 layer 判斷。當您啟動執行個體時，安裝配方完成後， OpsWorks Stacks 會自動執行執行個體的部署配方。但是，當您新增或修改應用程式時，您必須手動部署到任何線上的執行個體。您必須具有管理或部署許可才能部署應用程式。如需詳細資訊，請參閱[管理使用者許可](opsworks-security-users.md)。 **部署應用程式** 1. 在 **Apps (應用程式)** 頁面上，按一下應用程式的 **deploy (部署)** 動作。 ![\[Apps page showing SimplePHP app with deploy, edit, and delete action options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/apps_with_content.png) **注意** 您也可以透過按一下導覽窗格中的 **Deployments (部署)** 來部署應用程式。在 **Deployments & Commands (部署及命令)** 頁面上，按一下 **Deploy an app (部署應用程式)**。當您執行此作業時，您也可以選擇要部署的應用程式。 1. 指定下列內容： + (必要項目) 將 **Command: (命令：)** 設為 **deploy (部署)** (若尚未選取的話)。 + (選用) 包含註解。 1. 按一下**進階 >>** 指定自訂 JSON. OpsWorks Stacks 會將一組[堆疊組態和部署屬性](workingcookbook-json.md)新增至節點物件。`deploy` 屬性包含部署詳細資訊，可由部署配方用來處理安裝及組態。在 Linux 堆疊上，您可以使用自訂 JSON 欄位來[覆寫預設的 Stacks OpsWorks 設定](workingcookbook-json-override.md)，或將自訂設定傳遞至您的自訂配方。如需如何使用自訂 JSON 的詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。 **注意** 若您在此指定自訂 JSON，它只會新增至此部署的堆疊組態和部署屬性。若您希望永久新增自訂 JSON，您必須[將其新增至堆疊](workingstacks-json.md)。自訂 JSON 的大小限制為 120 KB。如果您需要更多容量，建議您將部分資料儲存在 Amazon S3 上。您的自訂配方接著可以使用 AWS CLI 或[適用於 Ruby 的 AWS 開發套件](https://aws.amazon.com/documentation/sdk-for-ruby/)將資料從儲存貯體下載到您的執行個體。如需範例，請參閱 [使用適用於 Ruby 的 SDK](cookbooks-101-opsworks-s3.md)。 1. 在 **Instances (執行個體)** 下方，按一下 **Advanced >> (進階 >>)** 並指定要在哪個執行個體上執行部署命令。部署命令會觸發部署事件，在選取的執行個體上執行部署配方。關聯應用程式伺服器的部署配方會從儲存庫下載程式碼和相關檔案，並將他們安裝在執行個體上，因此您通常會選取所有關聯的應用程式伺服器執行個體。但是，其他執行個體類型可能需要一些組態變更，才能適應新的應用程式，因此通常在那些執行個體上也執行部署配方會非常有用。那些配方會視需要更新組態，但不會安裝應用程式的檔案。如需配方的詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。 1. 按一下 **Deploy (部署)** 以在指定的執行個體上執行部署配方，顯示部署頁面。程序完成時， OpsWorks Stacks 會以綠色核取標記應用程式，表示部署成功。如果部署失敗， OpsWorks Stacks 會將應用程式標記為紅色 X。在這種情況下，您可以前往**部署**頁面並檢查部署日誌以取得更多資訊。 ![\[Deployment status page showing successful deployment of PHPTestApp with details.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/deployed_app.png) **注意** 在您將更新部署至 JSP 應用程式時，Tomcat 可能會無法識別更新，而繼續執行現有的應用程式版本。舉例來說，這可能會在您將應用程式做為僅包含 JSP 頁面的 .zip 檔案部署時發生。若要確保 Tomcat 執行的是最近部署的版本，專案的根目錄應包括內含 `web.xml` 檔案的 WEB-INF 目錄。`web.xml` 檔案可包含各種內容，但以下內容便足以確保 Tomcat 識別更新及執行目前部署的應用程式版本。您不需要為每次更新變更版本。若版本沒有變更，Tomcat 將會識別更新。 ```

appVersion

0.1

``` ## 其他部署命令 **Deploy app (部署應用程式)** 頁面包含數種其他用於管理您應用程式和關聯伺服器的命令。在下列命令中，只有 **Undeploy (解除部署)** 適用於位於 Chef 12 堆疊上的應用程式。 **Undeploy (解除部署)** 觸發解除部署[生命週期事件](workingcookbook-events.md)，執行解除部署配方，從指定執行個體移除所有版本的應用程式。 **轉返** 還原先前部署的應用程式版本。例如，若您已部署應用程式三次，然後執行 **Rollback (轉返)**，伺服器會從第二次部署提供應用程式。若您再次執行 **Rollback (轉返)**，伺服器會從第一次部署提供應用程式。根據預設， OpsWorks Stacks 會存放五個最近的部署，可讓您復原最多四個版本。若您超過存放版本的數目，命令會失敗，並留下最舊的版本。此命令無法在 Chef 12 堆疊中使用。 **Start Web Server (啟動 Web 伺服器)** 執行會在指定之執行個體上啟動應用程式伺服器的配方。此命令無法在 Chef 12 堆疊中使用。 **Stop Web Server (停止 Web 伺服器)** 執行會在指定之執行個體上停止應用程式伺服器的配方。此命令無法在 Chef 12 堆疊中使用。 **Restart Web Server (重新啟動 Web 伺服器)** 執行會在指定之執行個體上重新啟動應用程式伺服器的配方。此命令無法在 Chef 12 堆疊中使用。 **重要** **Start Web Server (啟動 Web 伺服器)**、**Stop Web Server (停止 Web 伺服器)**、**Restart Web Server (重新啟動 Web 伺服器)** 和 **Rollback (轉返)** 基本上就是[執行配方堆疊命令](workingstacks-commands.md)的自訂版本。他們會執行一組在指定之執行個體上執行任務的配方。這些命令不會觸發生命週期事件，因此您無法引用命令執行自訂程式碼。這些命令僅適用於內建的[應用程式伺服器 layer](workinglayers-servers.md)。特別是，這些命令對於自訂 layer 沒有任何效果，即使他們支援應用程式伺服器也一樣。若要在自訂 layer 上啟動、停止或重新啟動伺服器，您必須實作自訂配方以執行這些任務，並使用[執行配方堆疊命令](workingstacks-commands.md)執行他們。如需如何實作和安裝自訂配方的詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。 # 編輯應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以透過編輯應用程式來修改應用程式的組態。例如，如果您已準備好部署新版本，您可以編輯應用程式的 OpsWorks Stacks 設定，以使用新的儲存庫分支。您必須具有管理或部署許可才能編輯應用程式組態。如需詳細資訊，請參閱[管理使用者許可](opsworks-security-users.md)。 **編輯應用程式** 1. 在 **Apps (應用程式)** 頁面按一下應用程式名稱，開啟它的 details (詳細資訊) 頁面。 1. 按一下 **Edit (編輯)** 變更應用程式的組態。 + 如果您修改應用程式的名稱， OpsWorks Stacks 會使用新名稱在主控台中識別應用程式。變更名稱不會變更相關聯的簡稱。簡稱是在您將應用程式新增到堆疊後設定，以後無法修改。 + 如已指定受保護的環境變數，您即無法查看或編輯值。不過，您可以按一下 **Update value (更新值)** 指定新的值。 1. 按一下 **Save (儲存)** 儲存新的組態，然後按一下 **Deploy App (部署應用程式)** 部署應用程式。編輯應用程式會變更 Stacks OpsWorks 的設定，但不會影響堆疊的執行個體。當您第一次[部署應用程式](workingapps-deploying.md)時，Deploy 配方會將程式碼及相關檔案下載到應用程式伺服器執行個體，然後這些執行個體會執行本機複本。如果您修改儲存庫中的應用程式，或變更任何其他設定，則必須部署應用程式，才能在應用程式伺服器執行個體上安裝更新，如下所示。當啟動時， OpsWorks Stacks 會自動將目前的應用程式版本部署到新的執行個體。不過，現有執行個體的情況則不同： + OpsWorks Stacks 會在啟動時自動將目前的應用程式版本部署到新的執行個體。 + OpsWorks Stacks 會在重新啟動時，自動將最新的應用程式版本部署至離線執行個體，包括[負載型和時間型執行個體](workinginstances-autoscaling.md)。 + 您必須將更新的應用程式以手動方式部署到線上執行個體。如需如何部署應用程式的詳細資訊，請參閱[部署應用程式](workingapps-deploying.md)。 # 將應用程式連線至資料庫伺服器 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以在[建立應用程式](workingapps-creating.md)時或稍後編輯[應用程式，將 Amazon RDS 資料庫伺服器與應用程式](workingapps-editing.md)建立關聯。然後，您的應用程式可以使用資料庫連線資訊 - 使用者名稱、密碼 ... - 來連線至資料庫伺服器。當您[部署應用程式](workingapps-deploying.md)時， OpsWorks Stacks 會以兩種方式將此資訊提供給應用程式： + 對於 Linux 堆疊， OpsWorks Stacks 會在每個內建應用程式伺服器執行個體上建立檔案，而此檔案包含應用程式可用來連線至資料庫伺服器的連線資料。 + OpsWorks Stacks 包含[堆疊組態中的連線資訊，以及安裝在每個執行個體上的部署屬性](workingcookbook-json.md)。您可以實作自訂配方以從這些屬性中擷取連線資訊，並將它放入您慣用格式的檔案中。如需詳細資訊，請參閱[傳遞資料到應用程式](apps-data.md)。 **重要** 對於 Linux 堆疊，如果您想要將 Amazon RDS 服務層與應用程式建立關聯，則必須將適當的驅動程式套件新增至關聯的應用程式伺服器層，如下所示：按一下導覽窗格中的 **Layers (Layer)**，然後開啟應用程式伺服器的 **Recipes (配方)** 標籤。按一下 **Edit (編輯)**，然後將適當的驅動程式套件新增至 **OS Packages (OS 套件)**。例如，如果 layer 包含 Amazon Linux 執行個體，則您應該指定 `mysql`；如果 layer 包含 Ubuntu 執行個體，則應該指定 `mysql-client`。儲存變更，並重新部署應用程式。 ## 使用自訂配方您可以實作自訂配方以從應用程式的 [`deploy` 屬性](workingcookbook-json.md#workingcookbook-json-deploy)中擷取連線資料，並將它儲存為應用程式可讀取的形式 (例如 YAML 檔案)。當您[建立應用程式](workingapps-creating.md)或稍後[編輯應用程式](workingapps-editing.md)時，可以將資料庫伺服器連接至應用程式。當您部署應用程式時， OpsWorks Stacks 會在包含資料庫連線資訊的每個執行個體上安裝[堆疊組態和部署屬性](workingcookbook-json.md)。您的應用程式接著可以擷取適當的屬性。詳細資訊取決於您使用 Linux 還是 Windows 堆疊。 ### 連線至 Linux 堆疊的資料庫伺服器對於 Linux 堆疊，[堆疊組態和部署屬性的](workingcookbook-json.md) `deploy` 命名空間包括每個已部署應用程式的屬性 (命名為應用程式的簡短名稱)。當您將資料庫伺服器連接至應用程式時， OpsWorks Stacks 會將連線資訊填入應用程式的`[:database]`屬性，並針對每個後續部署將其安裝在堆疊的執行個體上。屬性值由使用者所提供或由 OpsWorks Stacks 所產生。 **注意** OpsWorks Stacks 可讓您將資料庫伺服器連接到多個應用程式，但每個應用程式只能有一個連接的資料庫伺服器。如果您想要將應用程式連線至多部資料庫伺服器，則請將其中一部伺服器連接至應用程式，並在應用程式的 `deploy` 屬性中使用此資訊來連線至該伺服器。使用自訂 JSON 將其他資料庫伺服器的連線資訊傳遞給應用程式。如需詳細資訊，請參閱[傳遞資料到應用程式](apps-data.md)。應用程式可以使用執行個體之 `deploy` 屬性中的連線資訊來連線至資料庫。不過，應用程式無法直接存取該資訊，只有配方可以存取`deploy`屬性。您可以實作自訂配方來解決此問題，而自訂配方會擷取 `deploy` 屬性中的連線資訊，並將它放入應用程式可讀取的檔案中。 # 使用環境變數 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題中的建議適用於 Chef 11.10 及更早版本的 Chef。若要在 Chef 12 及更新版本中取得環境變數，您必須使用應用程式資料包。如需詳細資訊，請參閱 [AWS OpsWorks 資料包參考](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bags.html)及[應用程式資料包 (aws\$1opsworks\$1app)](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bag-json-app.html)。當您[為應用程式指定環境變數](workingapps-creating.md#workingapps-creating-environment)時， OpsWorks Stacks 會將變數定義新增至應用程式的[`deploy`屬性](workingcookbook-json.md#workingcookbook-json-deploy)。自訂 layer 可透過使用標準節點語法，利用配方擷取變數的值，並以可由 layer 的應用程式存取的形式存放。您必須實作從執行個體的 `deploy` 屬性取得環境變數的自訂配方。配方接著會將資料以可由應用程式存取的形式存放在執行個體上 (例如 YAML 檔案)。應用程式的環境變數定義會存放在應用程式 `deploy` 中的 `environment_variables` 屬性。以下範例顯示名為 `simplephpapp` 之應用程式內這些屬性的位置，並使用 JSON 代表屬性的結構。 ``` { ... "ssh_users": { }, "deploy": { "simplephpapp": { "application": "simplephpapp", "application_type": "php", "environment_variables": { "USER_ID": "168424", "USER_KEY": "somepassword" }, ... } } ``` 配方可透過使用標準節點語法，取得變數的值。以下範例示範如何從先前的 JSON 中取得 `USER_ID` 的值，並將其置放於 Chef 日誌中。 ``` Chef::Log.info("USER_ID: #{node[:deploy]['simplephpapp'][:environment_variables][:USER_ID]}") ``` 如需如何從堆疊組態及部署 JSON 擷取資訊，並將其存放在執行個體上的更詳細說明，請參閱[傳遞資料到應用程式](apps-data.md)。 # 傳遞資料到應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。通常將資料 (例如鍵/值對) 傳遞給伺服器上的應用程式很有用。若要執行此作業，請使用[自訂 JSON](workingstacks-json.md) 將資料新增至堆疊。 OpsWorks Stacks 會將資料新增至每個生命週期事件的每個執行個體節點物件。但是，請注意，雖然配方可透過 Chef 屬性從節點物件取得自訂 JSON 資料，應用程式則無法。其中一個將自訂 JSON 資料傳遞給一或多個應用程式的方式，便是實作自訂配方，從 `node` 物件擷取資料，然後將資料寫入應用程式可讀取的檔案中。本主題中的範例示範如何將資料寫入 YAML 檔案，但您可以針對其他格式 (例如 JSON 或 XML) 使用相同的基本方法。若要將鍵/值資料傳遞給堆疊的執行個體，請新增如下的自訂 JSON 至堆疊。如需如何將自訂 JSON 新增至堆疊的詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。 ``` { "my_app_data": { "app1": { "key1": "value1", "key2": "value2", "key3": "value3" }, "app2": { "key1": "value1", "key2": "value2", "key3": "value3" } } } ``` 範例假設您有兩個應用程式，名稱分別為 `app1` 和 `app2`，並且每一個皆有三個資料值。隨附的配方假設您使用應用程式的短名識別關聯資料。其他名稱則為任意。如需應用程式短名的詳細資訊，請參閱[設定](workingapps-creating.md#workingapps-creating-settings)。下列範例中的配方示範如何為每個應用程式，從 `deploy` 屬性擷取資料，然後將其置放在 `.yml` 檔案中。配方假設您的自訂 JSON 包含每個應用程式的資料。 ``` node[:deploy].each do |app, deploy| file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` `deploy` 屬性包含每個應用程式的屬性，以應用程式的短名命名。每個應用程式屬性皆包含一組屬性，代表應用程式的各種資訊。此範例使用應用程式的部署目錄，以 `[:deploy][:app_short_name][:deploy_to]` 屬性代表。如需 `[:deploy]` 的詳細資訊，請參閱[deploy 屬性](attributes-json-deploy.md)。針對每個 `deploy` 中的應用程式，配方會執行下列作業： 1. 在應用程式的 `app_data.yml` 目錄中的 `shared/config` 子目錄內，建立名為 `[:deploy_to]` 的檔案。如需 Stacks OpsWorks 如何安裝應用程式的詳細資訊，請參閱 [部署配方](create-custom-deploy.md)。 1. 將應用程式的自訂 JSON 值轉換成 YAML，並將格式化後的資料寫入 `app_data.yml`。 **將資料傳遞到應用程式** 1. 將應用程式新增至堆疊，然後記下其短名。如需詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。 1. 使用應用程式的資料，將自訂 JSON 新增至 `deploy` 屬性，如先前所述。如需如何將自訂 JSON 新增至堆疊的詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。 1. 建立技術指南，並將程式碼以先前範例做為基礎的配方新增至其中，針對您在自訂 JSON 中使用的屬性名稱，根據需求進行修改。如需如何建立技術指南和配方的詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。若您已有此堆疊的自訂技術指南，您也可以將配方新增至現有的技術指南，或是將程式碼新增至現有的部署配方。 1. 在您的堆疊上安裝技術指南。如需詳細資訊，請參閱[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)。 1. 將配方指派給應用程式伺服器層的部署生命週期事件。 OpsWorks 堆疊接著會在開機後在每個新執行個體上執行配方。如需詳細資訊，請參閱[執行配方](workingcookbook-executing.md)。 1. 部署應用程式，同時也會安裝包含您資料的堆疊組態和部署屬性。 **注意** 若資料檔案必須在應用程式部署前便存在，您也可以將配方指派給 layer 的安裝生命週期事件。該事件只會在執行個體完成開機後執行一次。不過， OpsWorks Stacks 尚未建立部署目錄，因此您的配方應該在建立資料檔案之前明確建立所需的目錄。以下範例明確建立應用程式的 `/shared/config` 目錄，然後在該目錄中建立資料檔案。 ``` node[:deploy].each do |app, deploy| directory "#{deploy[:deploy_to]}/shared/config" do owner "deploy" group "www-data" mode 0774 recursive true action :create end file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` 若要載入資料，您可以使用看起來像是下列 [Sinatra](http://www.sinatrarb.com/) 程式碼的內容： ``` #!/usr/bin/env ruby # encoding: UTF-8 require 'sinatra' require 'yaml' get '/' do YAML.load(File.read(File.join('..', '..', 'shared', 'config', 'app_data.yml'))) End ``` 您可以透過更新自訂 JSON 來隨時更新應用程式的資料值，如下所示。 **更新應用程式資料** 1. 編輯自訂 JSON 以更新資料值。 1. 再次部署應用程式，這會指示 OpsWorks Stacks 在堆疊的執行個體上執行部署配方。配方會使用已更新堆疊組態及部署屬性的屬性，因此您的自訂配方會使用目前的值更新資料檔案。 # 使用 Git 儲存庫 SSH 金鑰 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Git 儲存庫 SSH 金鑰，有時候稱為部署 SSH 金鑰，為不帶密碼的 SSH 金鑰，可提供私有 Git 儲存庫的存取。此金鑰理應不屬於任何特定的開發人員。其目的是允許 OpsWorks Stacks 從 Git 儲存庫非同步部署應用程式或技術指南，而不需要您進一步輸入。下列說明建立儲存庫 SSH 金鑰的基本程序。如需詳細資訊，請參閱您儲存庫的文件。例如，[管理部署金鑰](https://help.github.com/articles/managing-deploy-keys)說明如何建立 GitHub 儲存庫的儲存庫 SSH 金鑰，[Bitbucket 上的部署金鑰](http://blog.bitbucket.org/2012/06/20/deployment-keys/)則說明如何建立 Bitbucket 儲存庫的儲存庫 SSH 金鑰。請注意，某些文件會說明在伺服器上建立金鑰。對於 OpsWorks Stacks，只需在說明中將 "server" 取代為 "workstation"。 **建立儲存庫 SSH 金鑰** 1. 在您的工作站上使用像是 `ssh-keygen` 等程式，建立您 Git 儲存庫的部署 SSH 金鑰對。 **重要** OpsWorks Stacks 不支援 SSH 金鑰密碼片語。 1. 將公有金鑰指派給儲存庫，然後在您的工作站上存放私有金鑰。 1. 在您新增應用程式或指定技術指南儲存庫時，在 **Repository SSH Key (儲存庫 SSH 金鑰)** 方塊中輸入私有金鑰。如需詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。 OpsWorks Stacks 會將儲存庫 SSH 金鑰傳遞給每個執行個體，然後內建配方會使用金鑰連線至儲存庫並下載程式碼。金鑰會做為 [`deploy`](workingcookbook-json.md) 存放於 [`node[:deploy]['appshortname'][:scm][:ssh_key]` 屬性](attributes-json-deploy.md#attributes-json-deploy-app-scm-key)中，且僅能由根使用者存取。 # 使用自訂網域 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果您透過第三方託管網域名稱，您可將該網域名稱映射至應用程式。基本程序如下： 1. 透過 DNS 註冊商建立子網域，然後將其映射至負載平衡器的彈性 IP 地址，或應用程式伺服器的公有 IP 地址。 1. 更新應用程式的組態以指向子網域並重新部署應用程式。 **注意** 請確定您將不合格網域名稱 (例如 myapp1.example.com) 轉送至合格網域名稱 (例如 www.myapp1.example.com)，以便兩者都能映射至您的應用程式。當您為應用程式設定網域時，網域在伺服器的組態檔案中會做為伺服器別名列出。如果您使用負載平衡器，則負載平衡器會在請求傳入時檢查 URL 中的網域名稱，並根據網域來重新導向流量。 **將子網域映射至 IP 地址** 1. 如果您使用負載平衡器，請在 **Instances (執行個體)** 頁面上按一下負載平衡器執行個體，以開啟其詳細資訊頁面，並取得該執行個體的 **Elastic IP (彈性 IP) ** 地址。否則請從應用程式伺服器執行個體的詳細資訊頁面取得公有 IP 地址。 1. 遵循 DNS 註冊商提供的指示來建立子網域，並將其映射至步驟 1 中的 IP 地址。 **注意** 如果負載平衡器執行個體在某個時間點終止，會為您指派新的彈性 IP 地址。您需要更新 DNS 註冊設定，才能映射到新的彈性 IP 地址。 OpsWorks Stacks 只會將網域設定新增至應用程式的[`deploy`屬性](workingcookbook-json.md#workingcookbook-json-deploy)。您必須實作自訂配方，才可從節點物件擷取資訊，並適當設定伺服器。如需詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。 # 在同一個應用程式伺服器上執行多個應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題中的資訊不適用於 Node.js 應用程式。如果您有多個相同類型的應用程式，在同一個應用程式伺服器執行個體上執行有時更符合成本效益。 **在同一個伺服器上執行多個應用程式** 1. 將應用程式新增至每個應用程式的堆疊。 1. 為每個應用程式取得個別的子網域，並將子網域映射至應用程式伺服器或負載平衡器的 IP 地址。 1. 編輯每個應用程式的組態以指定適當的子網域。如需如何執行這些任務的詳細資訊，請參閱[使用自訂網域](workingapps-domains.md)。 **注意** 如果您的應用程式伺服器執行多個 HTTP 應用程式，您可以使用 Elastic Load Balancing 進行負載平衡。對於多個 HTTPS 應用程式，您必須在負載平衡器終止 SSL 連線，或為每個應用程式建立個別的堆疊。HTTPS 請求經過加密，這表示如果您在伺服器終止 SSL 連線，負載平衡器就無法檢查網域名稱，判斷哪個應用程式應處理請求。 # 使用 SSL **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要搭配使用 SSL 與您的應用程式，您必須先從憑證授權機構 (CA) 取得數位伺服器憑證。為求簡化，本演練會建立憑證，然後對它自我簽署。自簽憑證適用於學習和測試，但您應該一律使用由 CA 針對生產堆疊所簽署的憑證。在本演練中，您將會執行下列作業： 1. 安裝及設定 OpenSSL。 1. 建立私有金鑰。 1. 建立憑證簽署請求。 1. 產生自簽憑證。 1. 使用您的憑證資訊編輯應用程式。 **重要** 如果您的應用程式使用 SSL，則建議您盡可能在應用程式伺服器 layer 中停用 SSLv3 來處理 [CVE-2014-3566](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-3566) 中所述的漏洞。如果您的堆疊包含 Ganglia 層，您也應該停用該層的 SSL v3。詳細資訊取決於特定 layer；如需詳細資訊，請參閱下列項目。 [Java 應用程式伺服器 OpsWorks 堆疊層](layers-java.md) [Node.js 應用程式伺服器 OpsWorks 堆疊層](workinglayers-node.md) [PHP 應用程式伺服器 OpsWorks 堆疊層](workinglayers-php.md) [Rails 應用程式伺服器 OpsWorks 堆疊層](workinglayers-rails.md) [靜態 Web 伺服器 OpsWorks 堆疊層](workinglayers-static.md) [Ganglia 層](workinglayers-ganglia.md) **Topics** + [步驟 1：安裝和設定 OpenSSL](#w2ab1c14c57c29c15) + [步驟 2：建立私有金鑰](#w2ab1c14c57c29c17) + [步驟 3：建立憑證簽署請求](#w2ab1c14c57c29c19) + [步驟 4：將 CSR 提交至憑證授權機構](#w2ab1c14c57c29c21) + [步驟 5：編輯應用程式](#w2ab1c14c57c29c23) ## 步驟 1：安裝和設定 OpenSSL 建立和上傳伺服器憑證需要支援 SSL 和 TLS 通訊協定的工具。OpenSSL 是一種開放原始碼工具，可提供建立 RSA 字符並使用私有金鑰簽署它所需的基本加密函數。下列程序假設您的電腦尚未安裝 OpenSSL。 **在 Linux 和 Unix 上安裝 OpenSSL** 1. 前往 [OpenSSL: Source, Tarballs](https://www.openssl.org/source/)。 1. 下載最新原始碼。 1. 建置套件。 **在 Windows 安裝 OpenSSL** 1. 如果您的系統尚未安裝 Microsoft Visual C\$1\$1 2008 可轉散發套件，請下載[套件](https://www.microsoft.com/en-us/download/details.aspx?id=11895)。 1. 執行安裝程式，並遵循 Microsoft Visual C\$1\$1 2008 Redistributable Setup Wizard (Microsoft Visual C\$1\$1 2008 可轉散發套件設定精靈) 所提供的說明來安裝可轉散發套件。 1. 前往 [OpenSSL: Binary Distributions](https://www.openssl.org/community/binaries.html)，並按一下您環境適用的 OpenSSL 二進位檔版本，並在本機儲存安裝程式。 1. 執行安裝程式，並遵循 **OpenSSL Setup Wizard (OpenSSL 設定精靈)** 中的說明來安裝二進位檔。開啟終端機或命令視窗，並使用下列命令列，以建立指向 OpenSSL 安裝點的環境變數。 + 在 Linux 和 Unix 上 ``` export OpenSSL_HOME=path_to_your_OpenSSL_installation ``` + 在 Windows 上 ``` set OpenSSL_HOME=path_to_your_OpenSSL_installation ``` 開啟終端機或命令視窗，並使用下列命令列，以將 OpenSSL 二進位檔的路徑新增至您電腦的路徑變數。 + 在 Linux 和 Unix 上 ``` export PATH=$PATH:$OpenSSL_HOME/bin ``` + 在 Windows 上 ``` set Path=OpenSSL_HOME\bin;%Path% ``` **注意** 您使用這些命令列對環境變數做出的任何變更，僅適用於目前命令列工作階段。 ## 步驟 2：建立私有金鑰您需要有唯一私有金鑰才能建立憑證簽署請求 (CSR)。使用下列命令列來建立金鑰： ``` openssl genrsa 2048 > privatekey.pem ``` ## 步驟 3：建立憑證簽署請求憑證簽署請求 (CSR) 是一種檔案，可傳送至憑證授權機構 (CA) 以申請數位伺服器憑證。使用下列命令列來建立 CSR。 ``` openssl req -new -key privatekey.pem -out csr.pem ``` 命令的輸出看起來與下列類似： ``` You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ``` 下表可協助您建立憑證請求。 **憑證請求資料** | 名稱 | 描述 | 範例 | | --- | --- | --- | | Country Name (國家/地區名稱) | 兩個字母的 ISO 縮寫，用來代表您的國家/地區。 | US = 美國 | | State or Province (州或省) | 您組織位在的州名或省名。此名稱不得使用縮寫。 | 華盛頓州 | | Locality Name (地區名稱) | 您組織所在城市的名稱。 | 西雅圖 | | Organization Name (組織名稱) | 您組織的完整法定名稱。請不要使用您組織名稱的縮寫。 | CorporationX | | 組織單位 | (選用) 這是額外的組織資訊。 | Marketing | | Common Name (通用名稱) | 您 CNAME 的完整網域名稱。如果這不是完全相符的項目，則您會收到憑證名稱檢查警告。 | www.example.com | | 電子郵件地址 | 伺服器管理員的電子郵件地址。 | someone@example.com | **注意** Common Name (通用名稱) 欄位容易遭人誤解，因此完全不正確。通用名稱一般是您的主機加上網域名稱。它看起來像是 "www.example.com" 或 "example.com"。您需要使用正確的通用名稱來建立 CSR。 ## 步驟 4：將 CSR 提交至憑證授權機構針對生產用途，您可以將 CSR 提交至憑證授權機構 (CA) 來取得伺服器憑證，這可能需要其他登入資料或身分證明。如果您的應用程式成功，則 CA 會傳回數位簽署的身分憑證，因此可能是憑證鏈檔案。AWS 不建議使用特定 CA。如需可用 CA 的部分清單，請參閱 Wikipedia 上的 [Certificate Authority - Providers](https://en.wikipedia.org/wiki/Certificate_authority#Providers)。您也可以產生自簽憑證，以用於測試目的。在此範例中，使用下列命令列產生自簽憑證。 ``` openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out server.crt ``` 輸出格式應類似以下內容： ``` Loading 'screen' into random state - done Signature ok subject=/C=us/ST=washington/L=seattle/O=corporationx/OU=marketing/CN=example.com/emailAddress=someone@example.com Getting Private key ``` ## 步驟 5：編輯應用程式在您產生並簽署憑證之後，請更新應用程式以啟用 SSL，並提供憑證資訊。在 **Apps (應用程式)** 頁面上，選擇應用程式以開啟詳細資訊頁面，然後按一下 **Edit App (編輯應用程式)**。若要啟用 SSL 支援，請將 **Enable SSL (啟用 SSL)** 設為 **Yes (是)**，以顯示下列組態選項。 **SSL 憑證** 將公有金鑰憑證 (.crt) 檔案的內容貼入方塊中。憑證看起來應該與下列類似： ``` -----BEGIN CERTIFICATE----- MIICuTCCAiICCQCtqFKItVQJpzANBgkqhkiG9w0BAQUFADCBoDELMAkGA1UEBhMC dXMxEzARBgNVBAgMCndhc2hpbmd0b24xEDAOBgNVBAcMB3NlYXR0bGUxDzANBgNV BAoMBmFtYXpvbjEWMBQGA1UECwwNRGV2IGFuZCBUb29sczEdMBsGA1UEAwwUc3Rl cGhhbmllYXBpZXJjZS5jb20xIjAgBgkqhkiG9w0BCQEWE3NhcGllcmNlQGFtYXpv ... -----END CERTIFICATE----- ``` 如果您使用 Nginx 並且具有憑證鏈檔案，則應該將內容附加到公有金鑰憑證檔案。如果您更新現有憑證，則請執行下列動作： + 選擇 **Update SSL certificate (更新 SSL 憑證)** 來更新憑證。 + 如果新憑證不符合現有私有金鑰，請選擇 **Update SSL certificate key (更新 SSL 憑證金鑰)**。 + 如果新憑證不符合現有憑證鏈，請選擇 **Update SSL certificates (更新 SSL 憑證)**。 **SSL Certificate Key (SSL 憑證金鑰)** 將私有金鑰檔案 (.pem 檔案) 的內容貼入方塊中。它看起來應該與下列類似： ``` ----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC0CYklJY5r4vV2NHQYEpwtsLuMMBhylMrgBShKq+HHVLYQQCL6 +wGIiRq5qXqZlRXje3GM5Jvcm6q0R71MfRIl1FuzKyqDtneZaAIEYniZibHiUnmO /UNqpFDosw/6hY3ONk0fSBlU4ivD0Gjpf6J80jL3DJ4R23Ed0sdL4pRT3QIDAQAB AoGBAKmMfWrNRqYVtGKgnWB6Tji9QrKQLMXjmHeGg95mppdJELiXHhpMvrHtpIyK ... -----END RSA PRIVATE KEY----- ``` **SSL certificates of Certification Authorities (憑證授權機構的 SSL 憑證)** 如果您有憑證鏈檔案，則請將內容複製至方塊中。如果您使用 Nginx，則應該將此方塊空白。如果您有憑證鏈檔案，請在 **SSL Certificate (SSL 憑證)** 中將它附加到公開金鑰憑證檔案。 ![\[SSL Settings interface with options for SSL 支援, Certificate, Key, and Certification Authorities.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/app_ssl_settings.png) 在您按一下 **Save (儲存)** 之後，請[重新部署應用程式](workingapps-deploying.md)以更新線上執行個體。對於[內建應用程式伺服器層](workingcookbook-json.md#workingcookbook-json-deploy)， OpsWorks Stacks 會自動更新伺服器組態。在部署完成之後，您可以驗證 OpenSSL 安裝已運作，如下所示。 **驗證 OpenSSL 安裝** 1. 前往 **Instances (執行個體)** 頁面。 1. 按一下應用程式伺服器執行個體的 IP 地址 (或者，如果您使用負載平衡器，則為負載平衡器的 IP 地址) 來執行應用程式。 1. 將 IP 地址字首從 **http://** 變更為 **https://**，並重新整理瀏覽器來使用 SSL 驗證頁面正確載入。已設定要在 Mozilla Firefox 中執行之應用程式的使用者，有時會得到下列憑證錯誤：`SEC_ERROR_UNKNOWN_ISSUER`。造成此錯誤的原因可能是您組織的防毒和反惡意軟體中的憑證更換功能、某些類型的網路流量監控和篩選軟體，或惡意軟體。如需如何排除此錯誤的詳細資訊，請參閱 Mozilla Firefox 支援網站上的[如何排除安全網站上的安全錯誤碼](https://support.mozilla.org/en-US/kb/error-codes-secure-websites?redirectlocale=en-US&redirectslug=troubleshoot-SEC_ERROR_UNKNOWN_ISSUER#w_monitoringfiltering-in-corporate-networks)。針對所有其他 layer (包括自訂 layer)， OpsWorks Stacks 只會將 SSL 設定新增至應用程式的 [`deploy` 屬性](workingcookbook-json.md#workingcookbook-json-deploy)。您必須實作自訂配方，才可從節點物件擷取資訊，並適當設定伺服器。 # 技術指南和配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 使用 Chef 技術指南來處理安裝和設定套件和部署應用程式等任務。本節說明如何搭配 Stacks OpsWorks 使用技術指南。如需詳細資訊，請參閱 [Chef](http://www.opscode.com/)。 **注意** OpsWorks Stacks 目前支援 Chef 版本 12、11.10.4、11.4.4 和 0.9.15.5。不過，Chef 0.9.15.5 即將移除，我們不建議您將它用於新的堆疊。為了方便起見，通常只以主要和次要版本號碼稱呼它們。執行 Chef 0.9 或 11.4 的堆疊使用 [Chef Solo](https://docs.chef.io/chef_solo.html)，執行 Chef 12 或 11.10 的堆疊則在本機模式中使用 [Chef Client](http://www.getchef.com/blog/2013/10/31/chef-client-z-from-zero-to-chef-in-8-5-seconds/)。針對 Linux 堆疊，您可以在您[建立堆疊](workingstacks-creating.md)時，使用組態管理員指定要使用的 Chef 版本。Windows 堆疊必須使用 Chef 12.2。如需詳細資訊 (包含將堆疊遷移至更近 Chef 版本的準則)，請參閱 [Chef 版本](workingcookbook-chef11.md)。 **Topics** + [技術指南儲存庫](workingcookbook-installingcustom-repo.md) + [Chef 版本](workingcookbook-chef11.md) + [Ruby 版本](workingcookbook-ruby.md) + [安裝自訂技術指南](workingcookbook-installingcustom-enable.md) + [更新自訂技術指南](workingcookbook-installingcustom-enable-update.md) + [執行配方](workingcookbook-executing.md) # 技術指南儲存庫 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您的自訂技術指南必須存放在線上儲存庫，如 .zip 檔案的封存或如 Git 的來源控制管理員。堆疊只能有一個自訂技術指南儲存庫，但儲存庫可以包含任意數目的技術指南。當您安裝或更新技術指南時， OpsWorks Stacks 會在每個堆疊執行個體的本機快取中安裝整個儲存庫。例如，當執行個體需要執行一或多個配方時，會使用來自本機快取的程式碼。下列說明如何建構您的技術指南儲存庫，這取決於類型。圖中的斜體文字代表使用者定義的目錄和檔案名稱，包括儲存庫或封存名稱。 **來源控制管理員** OpsWorks Stacks 支援下列來源控制管理員： + Linux 堆疊 – Git 和 Subversion + Windows 堆疊 – Git 下列顯示所需的目錄和檔案結構： ![\[SCM 技術指南儲存庫的必要結構\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cookbook_folders.png) + 技術指南目錄必須全在最上層。 **存檔** OpsWorks Stacks 支援下列封存： + Linux 堆疊 – zip、gzip、bzip2 或 tarball 檔案，存放在 Amazon S3 或網站 (HTTP 封存）。 OpsWorks Stacks 不支援未壓縮的 tarball。 + Windows 堆疊 – zip 和 tgz (gzip 壓縮 tar) 檔案，存放在 Amazon S3 上。下列顯示所需的目錄和檔案結構，這取決於您執行的是 Linux 或 Windows 堆疊。技術指南結構和 SCM 儲存庫結構相同，所以使用省略號 (...) 表示。 ![\[用於存檔的必要結構\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cookbook_folders_archive.png) + Linux 堆疊 – 技術指南目錄必須包含在根目錄中。 + Windows 堆疊 – 技術指南必須位於封存的頂層。如果您只有一個技術指南，您可以選擇略過技術指南目錄，將技術指南檔案放在最上層。在這種情況下， OpsWorks Stacks 會從 metadata.rb 取得技術指南名稱。每個技術指南目錄最少有下列標準目錄和檔案之一，一般全都有，它們必須使用標準名稱： + `attributes` – 技術指南的屬性檔案。 + `recipes` – 技術指南的配方檔案。 + `templates` – 技術指南的範本檔案。 + *other* – 包含其他檔案類型的選用使用者定義目錄，例如定義或規格。 + `metadata.rb` – 技術指南的中繼資料。針對 Chef 11.10 和更新版本，如果您的配方依賴其他技術指南，您必須在您技術指南的 `metadata.rb` 檔案中包含對應的 `depends` 陳述式。例如，若您的技術指南包含具有如 `include_recipe anothercookbook::somerecipe` 陳述式的配方，則您技術指南的 `metadata.rb` 檔案就必須包含下列內容：`depends "anothercookbook"`。如需詳細資訊，請參閱 [About Cookbook Metadata](http://docs.chef.io/cookbook_repo.html#about-cookbook-metadata)。範本必須在 `templates` 目錄的子目錄中，此目錄至少包含一或多個子目錄。這些子目錄也可以有子目錄。 + 範本通常有一個 `default` 子目錄，包含 Chef 預設使用的範本檔案。 + 「其他」**代表可用於操作系統專屬範本的選用子目錄。 + 根據 [File Specificity](http://docs.chef.io/templates.html#file-specificity) 中所述的命名慣例，Chef 會自動使用來自適當子目錄的範本。例如，在 Amazon Linux 和 Ubuntu 作業系統，您可以將作業系統專屬範本分別放在名為 `amazon` 或 `ubuntu` 的子目錄中。如何處理自訂技術指南的詳細資訊，取決於您慣用的儲存庫類型。 **使用封存** 1. 使用上述章節顯示的資料夾結構實作您的技術指南。 1. 建立壓縮封存並將其上傳至 Amazon S3 儲存貯體或網站。如果您更新技術指南，您必須建立和上傳新的封存檔案。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **使用 SCM** 1. 使用前文顯示的結構設定 Git 或 Subversion 儲存庫。 1. 或者，使用儲存庫的版本控制功能來實作多個分支或版本。如果您更新技術指南，您可以在新的分支中如此做，只指示 OpsWorks 使用新版本。您也可以指定特定的標記版本。如需詳細資訊，請參閱[指定自訂技術指南儲存庫](workingcookbook-installingcustom-enable.md#workingcookbook-installingcustom-enable-repo)。 [安裝自訂技術指南](workingcookbook-installingcustom-enable.md) 說明如何讓 OpsWorks Stacks 在堆疊的執行個體上安裝您的技術指南儲存庫。 **重要** 更新儲存庫中的現有技術指南後，您必須執行`update_cookbooks`堆疊命令，指示 OpsWorks Stacks 更新每個線上執行個體的本機快取。如需詳細資訊，請參閱[執行堆疊命令](workingstacks-commands.md)。 # Chef 版本 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 支援多個版本的 Chef。您在[建立堆疊](workingstacks-creating.md)時選取版本。 OpsWorks 堆疊接著會在堆疊的所有執行個體上安裝該版本的 Chef，以及與該版本相容的一組內建配方。若您安裝任何自訂配方，他們必須和堆疊的 Chef 版本相容。 OpsWorks Stacks 目前支援適用於 Linux 堆疊的 Chef 12、11.10、11.4 和 0.9 版，以及適用於 Windows 堆疊的 Chef 12.2 （目前為 Chef 12.22)。為了方便起見，通常只以主要和次要版本號碼稱呼它們。針對 Linux 堆疊，您可以在您[建立堆疊](workingstacks-creating.md)時，使用組態管理員指定要使用的 Chef 版本。Windows 堆疊必須使用 Chef 12.2。如需詳細資訊 (包含將堆疊遷移至更近 Chef 版本的準則)，請參閱 [Chef 版本](#workingcookbook-chef11)。如需完整的版本資訊，請參閱[OpsWorks Stacks 作業系統](workinginstances-os.md)。 **Chef 12.2** Chef 12.2 支援於 2015 年 5 月推出，僅供 Windows 堆疊使用。Windows 堆疊上目前的 Chef 版本為 Chef 12.22。它會執行 Ruby 2.3.6，並使用[本機模式中的 chef-client](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)，以啟動名為 [chef-zero](https://docs.chef.io/ctl_chef_client.html#about-chef-zero) 的本機記憶體內 Chef 伺服器。此伺服器的存在可讓配方使用 Chef search 和資料包。如[實作配方：Chef 12.2](workingcookbook-chef12.md)中所說明，支援具有某些限制，但您可以執行許多社群技術指南，而無須進行修改。 **Chef 12** Chef 12 支援於 2015 年 12 月推出，僅由 Linux 堆疊使用。它使用 Ruby 2.1.6 或 2.2.3 執行，並且使用可讓配方利用 Chef search 和資料包之[本機模式中的 chef-client](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)。如需詳細資訊，請參閱[OpsWorks Stacks 作業系統](workinginstances-os.md)。 **Chef 11.10** Chef 11.10 支援於 2014 年 3 月推出，僅由 Linux 堆疊使用。它使用 Ruby 2.0.0 執行，並且使用可讓配方利用 Chef search 和資料包之[本機模式中的 chef-client](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode)。如[實作配方：Chef 11.10](workingcookbook-chef11-10.md)中所說明，支援具有某些限制，但您可以執行許多社群技術指南，而無須進行修改。您也可以使用 [Berkshelf](http://berkshelf.com/) 來管理您的技術指南依存項目。支援的 Berkshelf 版本取決於作業系統。如需詳細資訊，請參閱[OpsWorks Stacks 作業系統](workinginstances-os.md)。您無法建立使用 Chef 11.10 的 CentOS 堆疊。 **Chef 11.4** Chef 11.4 支援於 2013 年 7 月推出，僅由 Linux 堆疊使用。它使用 Ruby 1.8.7 執行，並且使用 [chef-solo](https://docs.chef.io/chef_solo.html)，不支援 Chef search 或資料包。您通常可以透過 Stacks OpsWorks 使用相依於這些功能的社群技術指南，但您必須如中所述進行修改[遷移至新的 Chef 版本](workingcookbook-chef11-migrate.md)。您無法建立使用 Chef 11.4 的 CentOS 堆疊。美國東部（維吉尼亞北部）區域以外的區域端點不支援 Chef 11.4 堆疊。 **Chef 0.9** Chef 0.9 僅由 Linux 堆疊使用，並且已不再受到支援。請注意以下詳細資訊： + 您無法使用主控台建立新的 Chef 0.9 堆疊。您必須使用 CLI 或 API，或是使用不同版本的 Chef 建立堆疊之後，再修改堆疊的組態。 + 新的 OpsWorks Stacks 功能不適用於 Chef 0.9 堆疊。 + 新的作業系統版本僅會針對 Chef 0.9 堆疊提供有限的支援。特別是，Amazon Linux 2014.09 和更新版本不支援使用依賴於 Ruby 1.8.7 的 Rails App Server 層的 Chef 0.9 堆疊。 + 包括歐洲（法蘭克福）在內的新 AWS 區域不支援 Chef 0.9 堆疊。我們不建議針對新的堆疊使用 Chef 0.9。建議您將任何現有的堆疊盡快遷移至最新的 Chef 版本。如果您想要搭配 Stacks OpsWorks 使用社群技術指南，建議您[為新的 Linux 堆疊指定 Chef 12，](workingstacks-creating.md)並將現有的 Linux 堆疊遷移至 Chef 12。您可以使用 OpsWorks Stacks 主控台、API 或 CLI 將現有堆疊遷移至較新的 Chef 版本。如需詳細資訊，請參閱[遷移至新的 Chef 版本](workingcookbook-chef11-migrate.md)。 **Topics** + [實作 Chef 12.2 Stacks 配方](workingcookbook-chef12.md) + [實作 Chef 12 堆疊的配方](workingcookbook-chef12-linux.md) + [實作 Chef 11.10 堆疊的配方](workingcookbook-chef11-10.md) + [實作 Chef 11.4 堆疊的配方](workingcookbook-chef11-4.md) + [將現有 Linux 堆疊遷移至新的 Chef 版本](workingcookbook-chef11-migrate.md) # 實作 Chef 12.2 Stacks 配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Chef 12.2 (目前為 Chef 12.22) 僅供 Windows 堆疊使用，且該堆疊也必須執行該 Chef 版本。 + 配方必須針對某些用途使用 Windows 限定屬性和資源。如需詳細資訊，請參閱 [Chef for Microsoft Windows](https://docs.chef.io/windows.html)。 + Chef 執行使用 Ruby 2.3.6，因此您的配方可以使用新的 Ruby 語法。 + 配方可以使用 Chef search 和資料包。 Chef 12.2 堆疊可以使用許多社群技術指南，無需修改。如需詳細資訊，請參閱[使用 Chef 搜尋](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search)及[使用資料包](workingcookbook-chef11-10.md#workingcookbook-chef11-10-databag)。 + 大部分在[OpsWorks Stacks 資料包參考](data-bags.md)和[內建技術指南屬性](attributes-recipes.md)中說明的堆疊組態及部署屬性都可供 Windows 配方使用。您可以使用 Chef search 取得這些屬性值。如需範例，請參閱 [使用 Chef 搜尋取得屬性值](cookbooks-101-opsworks-opsworks-stack-config-search.md)。如需屬性清單，請參閱[OpsWorks Stacks 資料包參考](data-bags.md)。 # 實作 Chef 12 堆疊的配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Chef 12 堆疊與 Chef 11.10 堆疊相比有下列優點： + Chef 執行使用 Ruby 2.1.6，因此您的配方可以使用新的 Ruby 語法。 + Chef 12 堆疊可以使用更多社群技術指南，而無須修改。由於不再有任何內建的技術指南，因此再也不會發生內建技術指南與自訂技術指南的名稱發生衝突的情況。 + 您不再受限於 OpsWorks Stacks 為其提供預先建置套件的 Berkshelf 版本。Berkshelf 不再安裝在 Chef 12 中的 OpsWorks Stacks 執行個體上。您可以改為在您的本機工作站上使用任何 Berkshelf 版本。 + Stacks OpsWorks 隨 Chef 12 (Elastic Load Balancing、Amazon RDS 和 Amazon ECS) 提供的內建技術指南與自訂技術指南之間現在有明確的區隔。這可讓針對失敗的 Chef 執行進行故障診斷更容易。 # 實作 Chef 11.10 堆疊的配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Chef 11.10 堆疊與 Chef 11.4 堆疊相比有下列優點： + Chef 執行使用 Ruby 2.0.0，因此您的配方可以使用新的 Ruby 語法。 + 配方可以使用 Chef search 和資料包。 Chef 11.10 堆疊可以使用許多社群技術指南，而無須修改。 + 您可以使用 Berkshelf 來管理技術指南。 Berkshelf 提供更多更靈活的方式來管理您的自訂技術指南，以及在堆疊中使用社群技術指南。 + 技術指南必須在 `metadata.rb` 中宣告依存項目。若您的技術指南依存於其他技術指南，您必須在您技術指南的 `metadata.rb` 檔案中包含該依存項目。例如，若您的技術指南包含具有如 `include_recipe anothercookbook::somerecipe` 陳述式的配方，則您技術指南的 `metadata.rb` 檔案就必須包含下列內容：`depends "anothercookbook"`。 + OpsWorks 只有在堆疊包含 MySQL layer 時， Stacks 才會在堆疊的執行個體上安裝 MySQL 用戶端。 + OpsWorks 只有在堆疊包含 Ganglia 層時， Stacks 才會在堆疊的執行個體上安裝 Ganglia 用戶端。 + 若部署執行 `bundle install` 但安裝失敗，部署也會失敗。 **重要** 請勿針對自訂或社群技術指南重複使用內建技術指南的名稱。和內建技術指南具有相同名稱的自訂技術指南可能會失敗。如需 Chef 11.10、11.4 和 0.9 堆疊可用內建技術指南的完整清單，請參閱 [GitHub 上的 opsworks-cookbooks 儲存庫](https://github.com/aws/opsworks-cookbooks)。帶有非 ASCII 字元並在 Chef 0.9 和 11.4 堆疊上可成功執行的技術指南，在 Chef 11.10 堆疊上可能會失敗。原因是 Chef 11.10 堆疊會針對 Chef run 使用 Ruby 2.0.0，該版本比 Ruby 1.8.7 具有更嚴格的編碼規範。為了確保這類技術指南能在 Chef 11.10 堆疊上成功執行，每個使用非 ASCII 字元的檔案都應在其頂端具備註解，提供關於編碼的提示。例如，針對 UTF-8 編碼，註解應為 `# encoding: UTF-8`。如需 Ruby 2.0.0 編碼的詳細資訊，請參閱 [Encoding](http://www.ruby-doc.org/core-2.0.0/Encoding.html)。 **Topics** + [技術指南安裝與優先順序](#workingcookbook-chef11-10-override) + [使用 Chef 搜尋](#workingcookbook-chef11-10-search) + [使用資料包](#workingcookbook-chef11-10-databag) + [使用 Berkshelf](#workingcookbook-chef11-10-berkshelf) ## 技術指南安裝與優先順序安裝 OpsWorks Stacks 技術指南的程序對 Chef 11.10 堆疊的運作方式與舊版 Chef 略有不同。對於 Chef 11.10 堆疊，在 OpsWorks Stacks 安裝內建、自訂和 Berkshelf 技術指南之後，它會以下列順序將它們合併到通用目錄： 1. 內建技術指南。 1. Berkshelf 技術指南 (若有的話)。 1. 自訂技術指南 (若有的話)。當 OpsWorks Stacks 執行此合併時，它會複製目錄的完整內容，包括配方。若有任何重複項目，則會套用下列規則： + Berkshelf 技術指南的內容會優先於內建技術指南。 + 自訂技術指南的內容會優先於 Berkshelf 技術指南。為了示範此程序運作的方式，請考慮以下案例，其中三個技術指南目錄都包含名為 `mycookbook` 的技術指南： + 內建技術指南 – `mycookbook`包含名為的屬性檔案`someattributes.rb`、名為的範本檔案`sometemplate.erb`，以及名為的配方`somerecipe.rb`。 + Berkshelf 技術指南 – `mycookbook`包括 `sometemplate.erb`和 `somerecipe.rb`。 + 自訂技術指南 – `mycookbook`包含 `somerecipe.rb`。合併的技術指南包含以下內容： + 來自內建技術指南的 `someattributes.rb`。 + 來自 Berkshelf 技術指南的 `sometemplate.erb`。 + 來自自訂技術指南的 `somerecipe.rb`。 **重要** 建議您不要透過將整個內建技術指南複製到您的儲存庫，然後修改技術指南的一部分，來自訂您的 Chef 11.10 堆疊。這樣做會覆寫整個內建技術指南 (包含配方)。如果 OpsWorks Stacks 更新了該技術指南，除非您手動更新私有複本，否則您的堆疊將不會受益於這些更新。如需如何自訂堆疊的詳細資訊，請參閱[自訂 OpsWorks Stacks](customizing.md)。 ## 使用 Chef 搜尋您可以在您的配方中使用 Chef [`search` 方法](http://docs.chef.io/dsl_recipe.html#search)來查詢堆疊資料。您可以使用與 Chef 伺服器相同的語法，但 OpsWorks Stacks 會從本機節點物件取得資料，而不是查詢 Chef 伺服器。此資料包括： + 執行個體的[堆疊組態及部署屬性](workingstacks-json.md)。 + 執行個體的內建和自訂技術指南之屬性檔案的屬性。 + 由 Ohai 收集的系統資料。堆疊組態和部署屬性包含配方通常透過搜尋取得的大部分資訊，包括堆疊中每個線上執行個體的主機名稱和 IP 地址等資料。 OpsWorks 堆疊會為每個[生命週期事件](workingcookbook-events.md)更新這些屬性，以確保它們準確反映目前的堆疊狀態。這表示您通常可以在您的堆疊中使用搜尋依存的社群配方，而無須修改。search 方法仍然會傳回適當的資料，只是該資料會來自堆疊組態及部署屬性，而非伺服器。 OpsWorks Stacks 搜尋的主要限制是僅處理本機節點物件中的資料，特別是堆疊組態和部署屬性。因此，下列資料類型可能無法透過 search 取得： + 在其他執行個體上的本機定義屬性。如果配方在本機定義屬性，該資訊不會回報給 OpsWorks Stacks 服務，因此您無法使用搜尋從其他執行個體存取該資料。 + 自訂 `deploy` 屬性。您可以在您[部署應用程式](workingapps-deploying.md)時指定自訂 JSON，對應的屬性即會為該部署安裝在堆疊的執行個體上。但是，若您僅部署到選取的執行個體，屬性也會在那些執行個體上安裝。在所有其他執行個體上查詢那些自訂 JSON 屬性都會失敗。此外，自訂屬性也僅會包含在該特定部署的堆疊組態和部署 JSON 中。您僅能在下一次生命週期事件安裝新的一組堆疊組態及部署屬性之前存取他們。請注意，若您[指定堆疊的自訂 JSON](workingstacks-json.md)，屬性便會針對每個生命週期事件於每個執行個體上安裝，並且永遠可透過 search 進行存取。 + 來自其他執行個體的 Ohai 資料。 Chef 的 [Ohai 工具](http://docs.chef.io/resource_ohai.html)會取得執行個體上的各種系統資料，並新增到節點物件。這項資料會存放於本機，而不會報告回 OpsWorks Stacks 服務，因此 search 無法從其他執行個體存取 Ohai 資料。但是，這項資料的其中一部分可能會包含在堆疊組態及部署屬性中。 + 離線執行個體。堆疊組態及部署屬性只包含線上執行個體的資料。下列配方摘要會示範如何使用 search 取得 PHP layer 執行個體的私有 IP 地址。 ``` appserver = search(:node, "role:php-app").first Chef::Log.info("The private IP is '#{appserver[:private_ip]}'") ``` **注意** 當 OpsWorks Stacks 將堆疊組態和部署屬性新增至節點物件時，它實際上會建立兩組 layer 屬性，每個屬性都具有相同的資料。`layers` 命名空間中有一個集合，這是 Stacks OpsWorks 存放資料的方式。另一組則位於 `role` 命名空間，即 Chef 伺服器存放對等資料的方式。`role` 命名空間的目的是允許為 Chef 伺服器實作的搜尋程式碼在 Stacks OpsWorks 執行個體上執行。如果您專門為 OpsWorks Stacks 編寫程式碼，您可以在上述範例中使用 `layers:php-app`或 `role:php-app` `search`，並傳回相同的結果。 ## 使用資料包您可以在您的配方中使用 Chef [`data_bag_item` 方法](http://docs.chef.io/dsl_recipe.html#data-bag-item)來查詢資料包中的資訊。您會使用與您在使用 Chef 伺服器時相同的語法，但 OpsWorks Stacks 會從執行個體的堆疊組態及部署屬性取得資料。不過， OpsWorks Stacks 目前不支援 Chef 環境，因此 `node.chef_environment` 一律會傳回 `_default`。您會透過使用自訂 JSON 建立資料包，來將一或多個屬性新增至 `[:opsworks][:data_bags]` 屬性。以下範例示範在自訂 JSON 中建立資料包的一般格式。 **注意** 您無法透過將其新增至您的技術指南儲存庫，來建立資料包。您必須使用自訂 JSON。 ``` { "opsworks": { "data_bags": { "bag_name1": { "item_name1: { "key1" : “value1”, "key2" : “value2”, ... } }, "bag_name2": { "item_name1": { "key1" : “value1”, "key2" : “value2”, ... } }, ... } } } ``` 您通常會[指定堆疊的自訂 JSON](workingstacks-json.md)，針對每個接下來的生命週期事件，於每個執行個體上安裝自訂屬性。您也可以在您部署應用程式時指定自訂 JSON，但那些屬性只會針對該部署進行安裝，並且可能只會安裝到選取的執行個體。如需詳細資訊，請參閱[部署應用程式](workingapps-deploying.md)。下列自訂 JSON 範例會建立名為 `myapp` 的資料包。其中有一個項目 (`mysql`)，以及兩個鍵/值對。 ``` { "opsworks": { "data_bags": { "myapp": { "mysql": { "username": "default-user", "password": "default-pass" } } } } } ``` 若要在您的配方中使用資料，您可以呼叫 `data_bag_item` 並將資料包和值名稱傳遞給它，如下列摘要所示。 ``` mything = data_bag_item("myapp", "mysql") Chef::Log.info("The username is '#{mything['username']}' ") ``` 若要修改資料包中的資料，您只需修改自訂 JSON，它便會針對下一次的生命週期事件安裝在堆疊的執行個體上。 ## 使用 Berkshelf 在 Chef 0.9 和 Chef 11.4 堆疊中，您只能安裝一個自訂技術指南儲存庫。在 Chef 11.10 堆疊中，您可以使用 [Berkshelf](http://berkshelf.com/) 來管理您的技術指南和其依存項目，讓您可以從多個儲存庫安裝技術指南。(如需詳細資訊，請參閱 [本機封裝技術指南依存性](best-practices-packaging-cookbooks-locally.md)。) 特別是，使用 Berkshelf，您可以直接從儲存庫安裝 OpsWorks 與 Stacks 相容的社群技術指南，而不必將其複製到自訂技術指南儲存庫。支援的 Berkshelf 版本取決於作業系統。如需詳細資訊，請參閱[OpsWorks Stacks 作業系統](workinginstances-os.md)。若要使用 Berkshelf，您必須明確啟用它，如[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)中所說明。然後，在您的技術指南儲存庫根目錄中包含一個 `Berksfile` 檔案，指定要安裝的技術指南。若要在 Berksfile 中指定外部技術指南來源，請在檔案的頂端包含一個來源屬性，指定預設儲存庫 URL。Berkshelf 會在來源 URL 中尋找技術指南，除非您明確指定儲存庫。然後，在每個您希望安裝的技術指南中包含一行文字，格式如下： ``` cookbook 'cookbook_name', ['>= cookbook_version'], [cookbook_options] ``` `cookbook` 之後的欄位會指定特定技術指南。 + *cookbook\$1name* – （必要）指定技術指南的名稱。若您沒有包含任何其他欄位，Berkshelf 會從指定來源 URL 安裝技術指南。 + *cookbook\$1version* – （選用）指定技術指南版本。您可以使用像是 `=` 或 `>=` 等前綴，來指定特定版本或可接受的版本範圍。若您並未指定版本，Berkshelf 會安裝最新的版本。 + *cookbook\$1options* – （選用）最後一個欄位是包含一或多個索引鍵/值對的雜湊，指定儲存庫位置等選項。例如，您可以包含一個 `git` 鍵，指定特定的 Git 儲存庫，以及一個 `tag` 鍵，指定特定的儲存庫分支。指定儲存庫分支通常是確保安裝您偏好之技術指南的最佳方式。 **重要** 請不要透過在您的 Berksfile 中包含 `metadata` 並在 `metadata.rb` 中宣告技術指南依存項目，來宣告技術指南。若要使其正常執行，兩個檔案都必須位於相同的目錄中。使用 OpsWorks Stacks 時，Berksfile 必須位於儲存庫的根目錄中，但`metadata.rb`檔案必須位於各自的技術指南目錄中。您應改為在 Berksfile 中明確宣告外部技術指南。以下為 Berksfile 的範例，示範指定技術指南的不同方式。如需如何建立 Berksfile 的詳細資訊，請參閱 [Berkshelf](http://berkshelf.com/)。 ``` source "https://supermarket.chef.io" cookbook 'apt' cookbook 'bluepill', '>= 2.3.1' cookbook 'ark', git: 'git://github.com/opscode-cookbooks/ark.git' cookbook 'build-essential', '>= 1.4.2', git: 'git://github.com/opscode-cookbooks/build-essential.git', tag: 'v1.4.2' ``` 此檔案會安裝以下技術指南： + 來自社群技術指南儲存庫的最新版本 `apt`。 + 來自社群技術指南的最新版本 `bluepill` (只要其版本為 2.3.1 或更新版本)。 + 來自指定儲存庫的最新版本 `ark`。此範例的 URL 為 GitHub 上公有社群技術指南儲存庫的 URL，但您可以從其他儲存庫安裝技術指南，包含私有儲存庫。如需詳細資訊，請參閱 [Berkshelf](http://berkshelf.com/)。 + 來自指定儲存庫 v1.4.2 分支的 `build-essential` 技術指南。除了 Berksfile，自訂技術指南儲存庫可以包含自訂技術指南。在這種情況下， OpsWorks Stacks 會安裝兩組技術指南，這表示執行個體最多可以有三個技術指南儲存庫。 + 內建的技術指南會安裝到 `/opt/aws/opsworks/current/cookbooks`。 + 或您的自訂技術指南儲存庫包含技術指南，他們會安裝到 `/opt/aws/opsworks/current/site-cookbooks`。 + 若您已啟用 Berkshelf，且您的自訂技術指南儲存庫包含 Berksfile，指定的技術指南便會安裝到 `/opt/aws/opsworks/current/berkshelf-cookbooks`。內建技術指南和您的自訂技術指南會在設定期間安裝在每個執行個體上，除非您手動執行[**更新自訂技術指南**堆疊命令](workingstacks-commands.md)，否則後續不會更新。 OpsWorks 堆疊`berks install`會在每次 Chef 執行時執行，因此您的 Berkshelf 技術指南會根據下列規則，針對每個[生命週期事件](workingcookbook-events.md)更新： + 若您在儲存庫中有新的技術指南版本，此操作會從儲存庫更新技術指南。 + 否則，此操作會從本機快取更新 Berkshelf 技術指南。 **注意** 操作會覆寫 Berkshelf 技術指南，因此若您已修改任何技術指南的本機複本，變更將會遭到覆寫。如需詳細資訊，請參閱 [Berkshelf](http://berkshelf.com/) 您也可以透過執行**更新自訂技術指南**堆疊命令來更新您的 Berkshelf 技術指南，該命令會同時更新 Berkshelf 技術指南和您的自訂技術指南。 # 實作 Chef 11.4 堆疊的配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **重要** 請勿針對自訂或社群技術指南重複使用內建技術指南的名稱。和內建技術指南具有相同名稱的自訂技術指南可能會失敗。如需 Chef 11.10、11.4 和 0.9 堆疊可用內建技術指南的完整清單，請參閱 [GitHub 上的 opsworks-cookbooks 儲存庫](https://github.com/aws/opsworks-cookbooks)。 Chef 11.4 堆疊的主要限制為配方無法使用 Chef search 或資料包。不過， OpsWorks Stacks 會在每個執行個體上安裝[堆疊組態和部署屬性](workingcookbook-json.md)，其中包含您可以透過搜尋取得的大部分資訊，包括下列項目： + 來自主控台的使用者定義資料，例如主機或應用程式名稱。 + Stacks OpsWorks 服務產生的堆疊組態資料，例如堆疊的 layer、應用程式和執行個體，以及 IP 地址等每個執行個體的詳細資訊。 + 包含由使用者提供之資料的自訂 JSON 屬性，其用途與資料包幾乎相同。 OpsWorks Stacks 會在每個生命週期事件的每個執行個體上安裝目前版本的堆疊組態和部署屬性，然後再開始事件的 Chef 執行。資料會透過標準 `node[:attribute][:child_attribute][...]` 語法，供配方使用。例如，堆疊組態及部署屬性包含堆疊名稱，`node[:opsworks][:stack][:name]`。以下來自其中一個內建配方的摘要會取得堆疊名稱，並用它來建立組態檔案。 ``` template '/etc/ganglia/gmetad.conf' do source 'gmetad.conf.erb' mode '0644' variables :stack_name => node[:opsworks][:stack][:name] notifies :restart, "service[gmetad]" end ``` 許多堆疊組態及部署屬性值包含多個屬性。您必須逐一查看這些屬性，才能取得您需要的資訊。以下範例顯示來自堆疊組態及部署屬性的摘要。為了方便，以下以 JSON 物件表示。它包含一個最上層屬性 `deploy`，其針對每個堆疊的應用程式都包含一個屬性，以該應用程式的短名命名。 ``` { ... "deploy": { "app1_shortname": { "document_root": "app1_root", "deploy_to": "deploy_directory", "application_type": "php", ... }, "app2_shortname": { "document_root": "app2_root", ... } }, ... } ``` 每個應用程式屬性都包含一組描述應用程式的屬性。例如，`deploy_to` 屬性表示應用程式的部署目錄。以下摘要會設定每個應用程式部署目錄的使用者、群組及路徑。 ``` node[:deploy].each do |application, deploy| opsworks_deploy_dir do user deploy[:user] group deploy[:group] path deploy[:deploy_to] end ... end ``` 如需堆疊組態及部署屬性的詳細資訊，請參閱[自訂 OpsWorks Stacks](customizing.md)。如需部署目錄的詳細資訊，請參閱[部署配方](create-custom-deploy.md)。 Chef 11.4 堆疊不支援資料包，但您可以透過指定[自訂 JSON](workingstacks-json.md)，將任意資料新增到堆疊組態及部署屬性。您的配方接著便能透過使用標準 Chef 節點語法來存取資料。如需詳細資訊，請參閱[使用自訂 JSON](workingcookbook-json-override.md)。如果您需要加密資料包的功能，其中一個選項是將敏感屬性存放在安全的位置，例如私有 Amazon S3 儲存貯體。然後，您的配方可以使用安裝在所有 Stacks OpsWorks 執行個體上的 [AWS Ruby 開發套件](https://aws.amazon.com/documentation/sdkforruby/)，從儲存貯體下載資料。 **注意** 每個 OpsWorks Stacks 執行個體都有一個執行個體描述檔。相關聯的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html)會指定執行個體上執行的應用程式可存取哪些 AWS 資源。若要讓您的配方存取 Amazon S3 儲存貯體，角色的政策必須包含類似以下的陳述式，這會授予從指定儲存貯體擷取檔案的許可。 ``` "Action": ["s3:GetObject"], "Effect": "Allow", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", ``` 如需執行個體描述檔的詳細資訊，請參閱[指定在 EC2 執行個體上執行之應用程式的許可](opsworks-security-appsrole.md)。 # 將現有 Linux 堆疊遷移至新的 Chef 版本 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用 OpsWorks Stacks 主控台、API 或 CLI 將 Linux 堆疊遷移至較新的 Chef 版本。但是，您的配方可能需要修改，才能和更新的版本相容。在準備遷移堆疊時，請考慮以下事項。 + 您無法透過編輯或複製堆疊，將 OpsWorks Stacks 堆疊版本從 Chef 11 變更為 Chef 12。Chef 主要版本的升級無法透過本節中的程序執行。如需從 Chef 11.10 轉換至 Chef 12 的詳細資訊，請參閱[實作配方：Chef 12](workingcookbook-chef12-linux.md)。 + 從一個版本的 Chef 轉換至另一個版本，會涉及幾項變更，其中也有一些重大變更。如需從 Chef 0.9 轉換至 Chef 11.4 的詳細資訊，請參閱[遷移至新的 Chef 版本](#workingcookbook-chef11-migrate)。如需從 Chef 11.4 轉換至 Chef 11.10 的詳細資訊，請參閱[實作配方：Chef 11.10](workingcookbook-chef11-10.md)。如需從 Chef 11.10 轉換至 Chef 12 的詳細資訊，請參閱[實作配方：Chef 12](workingcookbook-chef12-linux.md)。 + Chef 執行在 Chef 0.9 和 Chef 11.4 堆疊 (Ruby 1.8.7)、Chef 11.10 堆疊 (Ruby 2.0.0)，以及 Chef 12 堆疊 (Ruby 2.1.6) 上皆使用了不同的 Ruby 版本。如需詳細資訊，請參閱[Ruby 版本](workingcookbook-ruby.md)。 + Chef 11.10 堆疊處理技術指南安裝的方式與 Chef 0.9 或 Chef 11.4 堆疊不同。這項差異可能會導致在遷移使用自訂技術指南的堆疊至 Chef 11.10 時發生問題。如需詳細資訊，請參閱[技術指南安裝與優先順序](workingcookbook-chef11-10.md#workingcookbook-chef11-10-override)。以下是將 Chef 堆疊遷移至更新 Chef 版本的建議準則： **將堆疊遷移至更新的 Chef 版本** 1. [複製您的生產堆疊](workingstacks-cloning.md)。在 **Clone Stack (複製堆疊)** 頁面上，按一下 **Advanced>> (進階>>)** 以顯示 **Configuration Management (組態管理)** 區段，然後將 **Chef version (Chef 版本)** 變更至下一個更高的版本。 **注意** 若您是使用 Chef 0.9 堆疊開始的，您無法直接升級至 Chef 11.10。您必須先升級到 Chef 11.4。若您希望在測試您的配方前先將您的堆疊遷移至 Chef 11.10，請等待 20 分鐘讓更新執行，再將堆疊從 11.4 升級到 11.10。 1. 將執行個體新增到 layer，然後在測試或預備系統上測試複製堆疊的應用程式和技術指南。如需詳細資訊，請參閱 [All about Chef ...](https://docs.chef.io/index.html)。 1. 當您滿意測試結果時，請執行下列其中一項作業： + 若這是您需要的 Chef 版本，您可以直接使用複製堆疊做為您的生產堆疊，或在您的生產堆疊上重設 Chef 版本。 + 若您正在兩階段式的將 Chef 0.9 堆疊遷移至 Chef 11.10，請重複程序，將堆疊從 Chef 11.4 遷移至 Chef 11.10。 **注意** 當您在測試配方時，您可以[使用 SSH 連線到](workinginstances-ssh.md)執行個體，然後使用[執行個體代理程式 CLI](agent.md) [run\$1command](agent-run.md) 命令，來執行與各種生命週期事件關聯的配方。代理程式 CLI 在測試安裝配方時特別有用，因為即使安裝失敗，執行個體並未達到線上狀態，您也可以使用它。您也可以使用[安裝堆疊命令](workingstacks-commands.md)來重新執行安裝配方，但該命令只有在安裝成功且執行個體處於線上狀態時，才能使用。您也可以將執行中的堆疊更新至新的 Chef 版本。 **將執行中的堆疊更新至新的 Chef 版本** 1. [編輯堆疊](workingstacks-edit.md)，變更 **Chef version (Chef 版本)** 堆疊設定。 1. 儲存新設定並等待 OpsWorks Stacks 更新執行個體，這通常需要 15 - 20 分鐘。 **重要** OpsWorks Stacks 不會同步 Chef 版本更新與生命週期事件。若您希望在生產堆疊上更新 Chef 版本，您必須小心，確保更新在下一次的[生命週期事件](workingcookbook-events.md)發生前完成。如果事件發生，通常是部署或設定事件，執行個體代理程式會更新您的自訂技術指南，並執行事件的指派配方，無論版本更新是否完成。沒有直接的方式能判斷版本更新是否已完成，但部署日誌中會包含 Chef 版本。 # Ruby 版本 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Linux 堆疊中的所有執行個體都已安裝 Ruby。 OpsWorks Stacks 會在每個執行個體上安裝 Ruby 套件，用來執行 Chef 配方和執行個體代理程式。 OpsWorks Stacks 會根據堆疊執行的 Chef 版本來決定 Ruby 版本。請勿嘗試修改此版本，這樣做可能會停用執行個體代理程式。 OpsWorks Stacks 不會在 Windows 堆疊上安裝應用程式 Ruby 可執行檔。Chef 12.2 用戶端隨附 Ruby 2.0.0 p451，但 Ruby 可執行檔不會新增至執行個體的 PATH 環境變數。如果您想要使用此可執行檔執行 Ruby 程式碼，它位在您 Windows 磁碟機的 `\opscode\chef\embedded\bin\ruby.exe`。下表摘要說明 OpsWorks Stacks Ruby 版本。可用的應用程式 Ruby 版本也取決於執行個體的作業系統。如需詳細資訊，包括可用的修補程式版本，請參閱 [OpsWorks Stacks 作業系統](workinginstances-os.md)。 | Chef 版本 | Chef Ruby 版本 | 可用的應用程式 Ruby 版本 | | --- | --- | --- | | 0.9 (c) | 1.8.7 | 1.8.7(a)、1.9.3(e)、2.0.0 | | 11.4 (c) | 1.8.7 | 1.8.7(a)、1.9.3(e)、2.0.0、2.1、2.2.0、2.3 | | 11.10 | 2.0.0-p481 | 1.9.3(c、e)、2.0.0、2.1、2.2.0、2.3、2.6.1 | | 12 (b) | 2.1.6、2.2.3 | 無 | | 12.22 (d) | 2.3.6 | 無 | **(a)** 不適用於 Amazon Linux 2014.09 及更新版本、Red Hat Enterprise Linux (RHEL)，或 Ubuntu 14.04 LTS。 **(b)** 僅適用於 Linux 堆疊。 **(c)** 不適用於 RHEL。 **(d)** 僅適用於 Windows 堆疊。主要版本為 12.2。目前的次要版本為 12.22。 **(e)** 棄用已完成；支援已結束。安裝位置取決於 Chef 版本： + 應用程式對所有 Chef 版本都使用 `/usr/local/bin/ruby` 可執行檔。 + 若為 Chef 0.9 和 11.4，執行個體代理程式和 Chef 配方使用 `/usr/bin/ruby` 可執行檔。 + 若為 Chef 11.10，執行個體代理程式和 Chef 配方使用 `/opt/aws/opsworks/local/bin/ruby` 可執行檔。 # 安裝自訂技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要使堆疊安裝及使用自訂技術指南，您必須設定堆疊，啟用自訂技術指南 (若還未設定的話)。您接著必須提供儲存庫 URL 和任何相關資訊 (例如密碼)。 **重要** 將堆疊設定為支援自訂技術指南之後， OpsWorks Stacks 會在啟動時在所有新執行個體上自動安裝技術指南。不過，您必須執行更新自訂技術指南堆疊命令，明確指示 OpsWorks Stacks 在任何現有的執行個體上安裝新的或更新的技術指南。 [****](workingstacks-commands.md)如需詳細資訊，請參閱[更新自訂技術指南](workingcookbook-installingcustom-enable-update.md)。在您於堆疊上啟用 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 前，請確認您執行的自訂和社群技術指南支援您堆疊使用的 Chef 版本。 **若要為自訂技術指南設定堆疊** 1. 在您的堆疊頁面上，按一下 **Stack Settings (堆疊設定)** 顯示其 **Settings (設定)** 頁面，按一下 **Edit (編輯)** 以編輯設定。 1. 將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 切換為 **Yes (是)**。 ![\[編輯堆疊設定頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/stack_settings_edit.png) 1. 設定您的自訂技術指南。當您完成後，按一下 **Save (儲存)** 以儲存更新的堆疊。 ## 指定自訂技術指南儲存庫 Linux 堆疊可以從下列任何儲存庫類型安裝自訂技術指南： + HTTP 或 Amazon S3 封存。它們可以是公有或私有，但 Amazon S3 通常是私有封存的偏好選項。 + Git 和 Subversion 儲存庫提供來源控制和具有多個版本的能力。 Windows 堆疊可以從 Amazon S3 封存和 Git 儲存庫安裝自訂技術指南。所有儲存庫類型都有以下必要欄位。 + **儲存庫類型** – 儲存庫類型 + **儲存庫 URL** – 儲存庫 URL OpsWorks Stacks 支援公有託管的 Git 儲存庫網站，例如 [GitHub](https://github.com/) 或 [Bitbucket](https://bitbucket.org)，以及私有託管的 Git 伺服器。針對 Git 儲存庫，您必須使用下列其中一個 URL 格式，取決於儲存庫為公有或私有。針對 Git 子模組遵循相同的 URL 準則。針對公有 Git 儲存庫，使用 HTTPS 或 Git 唯讀通訊協定： + Git 唯讀 – `git://github.com/amazonwebservices/opsworks-example-cookbooks.git`。 + HTTPS – `https://github.com/amazonwebservices/opsworks-example-cookbooks.git`。針對私有 Git 儲存庫，您必須使用 SSH 讀取/寫入格式，如下列範例所示： + Github 儲存庫 – `git@github.com:project/repository`。 + Git 伺服器上的儲存庫 – `user@server:project/repository` 其餘設定則會根據儲存庫類型而有所不同，如以下章節所說明。 ### HTTP 封存針對 **Repository type (儲存庫類型)** 選取 **Http Archive (Http 封存)** 會顯示兩個額外設定，若封存受到密碼保護，您便必須完成這些設定。 + **使用者名稱** – 您的使用者名稱 + **密碼** – 您的密碼 ### Amazon S3 封存選取 **S3 Archive** for **Repository 類型**會顯示下列額外的選用設定。 OpsWorks 無論您使用 Stacks API 或主控台， Stacks 都可以使用 Amazon EC2 角色（主機作業系統管理員身分驗證） OpsWorks 存取您的儲存庫。 + **存取金鑰 ID** – AWS 存取金鑰 ID，例如 AKIAIOSFODNN7EXAMPLE。 + **私密存取金鑰** – 對應的 AWS 私密存取金鑰，例如 wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY。 ### Git 儲存庫在 **Source Control (來源控制)** 下方選取 **Git** 會顯示下列額外選擇性設定： **Repository SSH key (儲存庫 SSH 金鑰)** 您必須指定部署 SSH 金鑰才能存取私有 Git 儲存庫。針對 Git 子模組，指定的金鑰必須要能存取這些子模組。如需詳細資訊，請參閱[使用 Git 儲存庫 SSH 金鑰](workingapps-deploykeys.md)。部署的 SSH 金鑰不需要密碼； OpsWorks Stacks 無法傳遞密碼。 **Branch/Revision (分支/修訂)** 如果儲存庫有多個分支， OpsWorks Stacks 預設會下載主分支。若要指定特定分支，請輸入分支名稱、SHA1 雜湊或標籤名稱。若要指定特定的遞交，請輸入完整 40 個八進位碼的遞交 ID。 ### Subversion 儲存庫在 **Source Control (來源控制)** 下方選取 **Subversion** 會顯示下列額外選擇性設定： + **使用者名稱** – 私有儲存庫的使用者名稱。 + **密碼** – 您的密碼，適用於私有儲存庫。 + **Revision**–【選用】如果您有多個修訂，則為修訂名稱。若要指定分支或標籤，您必須修改儲存庫 URL，例如：**http://repository\$1domain/repos/myapp/branches/my-apps-branch** 或 **http://repository\$1domain\$1name/repos/calc/myapp/my-apps-tag**。 # 更新自訂技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當您為 OpsWorks Stacks 提供自訂技術指南時，內建的設定配方會在每個新啟動的執行個體上建立本機快取，並將技術指南下載至快取。然後， OpsWorks Stacks 會從快取執行配方，而非儲存庫。如果您修改儲存庫中的自訂技術指南，您必須確保更新的技術指南已安裝在執行個體的本機快取上。當新執行個體啟動時， OpsWorks Stacks 會自動將最新的技術指南部署到新執行個體。不過，現有執行個體的情況則不同： + 您必須將更新的自訂技術指南手動部署到線上執行個體。 + 您不必將更新的自訂技術指南部署到離線的執行個體後端執行個體，包括以負載為基礎和以時間為基礎的執行個體。 OpsWorks Stacks 會在執行個體重新啟動時自動部署目前的技術指南。 + 您必須啟動不以負載為基礎或以時間為基礎的全天候離線 EBS 後端執行個體。 + 您不能啟動以負載為基礎和以時間為基礎的離線 EBS 後端執行個體，因此最簡單的方法是刪除離線執行個體，並新增執行個體加以取代。由於它們現在是新的執行個體，因此當執行個體啟動時， OpsWorks Stacks 會自動部署目前的自訂技術指南。 **若要手動更新自訂技術指南** 1. 使用修改過的技術指南更新您的儲存庫。 OpsWorks Stacks 會使用您最初安裝技術指南時提供的快取 URL，因此技術指南根檔案名稱、儲存庫位置和存取權不應變更。 + 對於 Amazon S3 或 HTTP 儲存庫，請以具有相同名稱的新 .zip 檔案取代原始 .zip 檔案。 + 若是 Git 或 Subversion 儲存庫，[編輯您的堆疊設定](workingstacks-edit.md)以將 **Branch/Revision (分支/修訂)** 欄位變更為新版本。 1. 在堆疊的頁面上，按一下 **Run Command (執行命令)**，並選取 **Update Custom Cookbooks (更新自訂技術指南)** 命令。 ![\[執行命令頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/update_cookbooks.png) 1. 視需要新增註解。 1. 或者，指定命令的自訂 JSON 物件，將自訂屬性新增至 OpsWorks Stacks 在執行個體上安裝的堆疊組態和部署屬性。如需詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)及[覆寫屬性](workingcookbook-attributes.md)。 1. 根據預設， OpsWorks Stacks 會更新每個執行個體上的技術指南。若要指定更新哪些執行個體，請從頁面底端的清單選取適當的執行個體。若要選取 layer 中的每個執行個體，請在左欄選取適當的 layer 核取方塊。 1. 按一下**更新自訂技術指南**以安裝更新的技術指南。 OpsWorks Stacks 會刪除指定執行個體上快取的自訂技術指南，並從儲存庫安裝新的技術指南。 **注意** 僅現有執行個體需要進行此程序，其快取中含有舊版技術指南。如果您之後將執行個體新增至 layer， OpsWorks Stacks 會部署目前在儲存庫中的技術指南，讓他們自動取得最新版本。 # 執行配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可使用兩種方式執行配方： + 自動執行，方法是將配方指派給適當 layer 的生命週期事件。 + 手動執行，方法是執行[執行配方堆疊命令](workingstacks-commands.md)或使用代理程式 CLI。 **Topics** + [OpsWorks Stacks 生命週期事件](workingcookbook-events.md) + [自動執行配方](workingcookbook-assigningcustom.md) + [手動執行配方](workingcookbook-manual.md) # OpsWorks Stacks 生命週期事件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。每個 layer 都有一組五個生命週期事件，而每個事件都有一組特別與該 layer 相關聯的配方。當事件在 layer 的執行個體上發生時， OpsWorks Stacks 會自動執行該組適當的配方。若要提供這些事件的自訂回應，請實作自訂配方，並將其[指派給每個 layer 的適當事件](workingcookbook-assigningcustom.md)。 OpsWorks Stacks 會在事件的內建配方之後執行這些配方。 **Setup** 此事件會在已啟動的執行個體完成開機後發生。您也可以使用[設定堆疊命令](workingstacks-commands.md)來手動觸發Setup事件。 OpsWorks Stacks 會執行根據其 layer 設定執行個體的配方。例如，如果執行個體是 Rails App Server layer 的成員，Setup配方會安裝 Apache、Ruby Enterprise Edition、 Passenger 和 Ruby on Rails。 **Setup (設定)** 事件會導致執行個體服務中斷。由於執行個體在 **Setup (設定)** 生命週期事件執行時，並未處於 **Online (線上)** 狀態，因此會從負載平衡器移除您執行 **Setup (設定)** 事件的執行個體。 **Configure** 發生以下其中一種情況時，此事件會在堆疊的所有執行個體上發生： + 執行個體進入或離開線上狀態。 + 您[將彈性 IP 地址與執行個體建立關聯](resources-attach.md#resources-attach-eip)，或[將某個彈性 IP 地址從執行個體解除關聯](resources-detach.md#resources-detach-eip)。 + 您可以將 [ Elastic Load Balancing 負載平衡器連接到](layers-elb.md) layer，或從 layer 分離。例如，假設您的堆疊有執行個體 A、B 和 C，而且您啟動新的執行個體 D。在 D 完成執行其設定配方之後， OpsWorks Stacks 會在 A、B、C 和 D 上觸發Configure事件。如果您隨後停止 A， OpsWorks Stacks 會在 B、C 和 D 上觸發Configure事件。 OpsWorks Stacks 會透過執行每個 layer 的Configure配方來回應Configure事件，以更新執行個體的組態以反映目前的線上執行個體集。Configure 事件是重新產生組態檔案的好機會。例如，HAProxy Configure配方會重新設定負載平衡器，以適應線上應用程式伺服器執行個體集中的任何變更。您也可以使用[設定堆疊命令](workingstacks-commands.md)來手動觸發設定事件。 **Deploy** 此事件會在您執行 **Deploy (部署)** 命令時發生，通常發生於將應用程式部署至一組應用程式伺服器執行個體的情況下。執行個體會執行將應用程式和任何相關檔案從其儲存庫部署到 layer 之執行個體的配方。例如，針對 Rails 應用程式伺服器執行個體，Deploy 配方會檢查指定的 Ruby 應用程式，並告知 [Phusion Passenger](https://www.phusionpassenger.com/) 重新載入它。您也可以在其他執行個體上執行 Deploy，讓它們 (舉例來說) 可更新其組態以適應新部署的應用程式。安裝包含部署，其會在安裝完成後執行部署配方。 **Undeploy** 此事件會在您刪除應用程式或執行 Undeploy 命令，藉此從一組應用程式伺服器執行個體中移除應用程式時發生。指定的執行個體會執行配方，以移除所有應用程式版本，並執行所有必要的清除。 **Shutdown** 此事件會在您指示 OpsWorks Stacks 關閉執行個體，但在關聯的 Amazon EC2 執行個體實際終止之前發生。 OpsWorks Stacks 會執行配方來執行清除任務，例如關閉服務。如果您已將 Elastic Load Balancing 負載平衡器連接到 layer，並[啟用連線耗盡的支援](layers-elb.md)， OpsWorks Stacks 會等到連線耗盡完成，再觸發Shutdown事件。觸發Shutdown事件後， OpsWorks Stacks 允許Shutdown配方有指定的時間執行其任務，然後停止或終止 Amazon EC2 執行個體。預設 Shutdown 逾時值為 120 秒。若您的 Shutdown 配方可能需要更多時間，您可以[編輯 layer 組態](workinglayers-basics-edit.md#workinglayers-basics-edit-general)來變更逾時值。如需執行個體 Shutdown 的詳細資訊，請參閱[停止執行個體](workinginstances-starting.md#workinginstances-starting-stop)。 **注意** [重新啟動執行個體](workinginstances-starting.md#workinginstances-starting-reboot)不會觸發任何生命週期事件。如需更多有關 Deploy 和 Undeploy 應用程式命令的討論，請參閱[部署應用程式](workingapps-deploying.md)。在已啟動的執行個體完成開機後，其餘的啟動順序如下： 1. OpsWorks Stacks 會執行執行個體的內建Setup配方，後面接著任何自訂Setup配方。 1. OpsWorks Stacks 會執行執行個體的內建Deploy配方，後面接著任何自訂Deploy配方。執行個體現在已上線。 1. OpsWorks Stacks 會在堆疊中的所有執行個體上觸發Configure事件，包括新啟動的執行個體。 OpsWorks Stacks 會執行執行個體的內建Configure配方，後面接著任何自訂Configure配方。 **注意** 若要查看發生在特定執行個體上的生命週期事件，請前往 **Instances (執行個體)** 頁面，然後按一下該執行個體的名稱以開啟其詳細資訊頁面。事件清單位於頁面底部的 **Logs (日誌)** 區段。您可以按一下**日誌**欄中的**顯示**，以檢查事件的 Chef 日誌。該日誌會提供事件處理方式的詳細資訊，包括哪些配方已執行。如需如何解讀 Chef 日誌的詳細資訊，請參閱 [Chef 日誌](troubleshoot-debug-log.md)。 ![\[Log entries showing commands, timestamps, and durations for system operations.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/instance_logs.png) 對於每個生命週期事件， OpsWorks Stacks 會在每個執行個體上安裝一組[堆疊組態和部署屬性](workingcookbook-json.md)，其中包含目前堆疊狀態，以及Deploy事件的部署相關資訊。這些屬性包括哪些執行個體可用、其 IP 地址等資訊。如需詳細資訊，請參閱[堆疊組態及部署屬性](workingcookbook-json.md)。 **注意** 同時啟動或停止大量的執行個體，可能會快速產生大量的 Configure 事件。為了避免不必要的處理， OpsWorks Stacks 只會回應最後一個事件。該事件的堆疊組態和部署屬性包含為堆疊之執行個體更新整組變更所需的所有資訊。這樣就不需要處理較早Configure的事件。 OpsWorks Stacks 會將未處理Configure的事件標記為**已取代**。 # 自動執行配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。每個 layer 都各有一組指派給每個生命週期事件的內建配方，不過部分 layer 缺少解除部署配方。當執行個體上發生生命週期事件時， OpsWorks Stacks 會為相關聯的 layer 執行適當的配方集。如果您已安裝自訂技術指南，您可以將每個配方指派給 layer 的生命週期事件，讓 OpsWorks Stacks 自動執行部分或全部配方。事件發生後， OpsWorks Stacks 會在 layer 的內建配方之後執行指定的自訂配方。 **將自訂配方指派給 layer 事件** 1. 在 **Layers** 頁面上，對適當的 layer 按一下 **Recipes (配方)**，然後按一下 **Edit (編輯)**。如果您尚未啟用自訂技術指南，請按一下**設定技術指南**，以開啟堆疊的 **Settings (設定)** 頁面。將 **Use custom Chef Cookbooks (使用自訂 Chef 技術指南)** 切換到 **Yes (是)**，並提供技術指南的儲存庫資訊。然後按一下 **Save (儲存)**，並導覽回 **Recipes (配方)** 標籤的編輯頁面。如需詳細資訊，請參閱[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)。 1. 在 **Recipes (配方)** 標籤上，在適當的事件欄位中輸入每個自訂配方，並按一下 **\$1** 將其新增至清單。配方的指定如下：*cookbook*::*somerecipe* (省略 `.rb` 副檔名)。 ![\[Layer 詳細資訊頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_edit.png) 當您啟動新的執行個體時， OpsWorks Stacks 會在執行標準配方之後，為每個事件自動執行自訂配方。 **注意** 自訂配方會按照您在主控台中輸入的順序執行。控制執行順序的另一個方法，是實作按正確順序執行配方的中繼配方。 # 手動執行配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。雖然配方通常會自動執行以回應生命週期事件，您仍可隨時在任何或所有堆疊執行個體上手動執行配方。這項功能通常用於未良好映射到生命週期事件的任務，例如備份執行個體。若要手動執行自訂配方，該配方必須位於您其中一個自訂技術指南中，但不需要指派給生命週期事件。當您手動執行配方時， OpsWorks Stacks 會安裝與部署事件相同的`deploy`屬性。 **若要在堆疊執行個體上手動執行配方** 1. 在 **Stack (堆疊)** 頁面上，按一下 **Run command (執行命令)**。針對 **Command (命令)**，選取 **Execute Recipes (執行配方)**。 ![\[執行命令頁面上的執行配方命令\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/execute_recipe.png) 1. 使用標準*技術指南名稱*：：*recipename* 格式，在要**執行的配方**中，輸入要執行的配方。使用逗號分隔多個配方，這些配方將按您列出的順序執行。 1. 您可以選擇性使用 **Custom Chef JSON (自訂 Chef JSON)** 方塊來新增自訂 JSON 物件，以定義要合併到安裝在執行個體上之堆疊組態和部署屬性的自訂屬性。如需使用自訂 JSON 物件的詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md) 和[覆寫屬性](workingcookbook-attributes.md)。 1. 在**執行個體**下，選取 OpsWorks Stacks 應執行配方的執行個體。當生命週期事件發生時， Stacks OpsWorks 代理程式會收到執行相關聯配方的命令。您可以在特定執行個體上手動執行這些命令，方法為使用適當的[堆疊命令](workingstacks-commands.md)或使用代理程式 CLI 的 [run\$1command](agent-run.md) 命令。如需如何使用代理程式 CLI 的詳細資訊，請參閱 [OpsWorks Stacks 代理程式 CLI](agent.md)。 # 資源管理 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **資源**頁面可讓您在 Stacks 堆疊中使用帳戶的[彈性 IP 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)、[Amazon EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)或 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) OpsWorks 執行個體資源。您可使用 **Resources (資源)** 執行下列作業： + 使用讓您將資源連接到其中一個堆疊執行個體的堆疊[註冊資源](resources-reg.md)。 + [連接資源](resources-attach.md)到其中一個堆疊的執行個體。 + 在執行個體之間[移動資源](resources-attach.md)。 + 從執行個體[分離資源](resources-detach.md)。資源維持註冊狀態，並可連接到另一個執行個體。 + [取消註冊資源](resources-dereg.md)。未註冊的資源無法供 Stacks OpsWorks 使用，但除非您刪除它，否則它仍會保留在您的帳戶中，並且可以向另一個堆疊註冊。請注意下列限制條件： + 您無法將已註冊的 Amazon EBS 磁碟區連接至 Windows 執行個體。 + 資源頁面管理標準、PIOPS、輸送量最佳化 HDD、冷 HDD 或一般用途 (SSD) Amazon EBS 磁碟區，但不管理 RAID 陣列。 + Amazon EBS 磁碟區必須是 xfs 格式。 OpsWorks Stacks 不支援其他檔案格式，例如 ext4。如需準備 Amazon EBS 磁碟區的詳細資訊，請參閱[讓 Amazon EBS 磁碟區可供使用](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html)。 + 您無法將 Amazon EBS 磁碟區連接至執行中的執行個體，或將其從中分離。您只能在離線執行個體上操作。例如，您可以向堆疊註冊使用中的磁碟區，然後將它連接到離線執行個體，但您先必須停止原執行個體並分離磁碟區，再啟動新的執行個體。否則，啟動程序會失敗。 + 所有已註冊的資源都會僅管理 OpsWorks。這可以覆寫資源生命週期屬性，例如適用於 EC2 磁碟區的 `DeleteOnTermination`。 + 您可以連接和分離彈性 IP 地址與執行中的執行個體。您可以在線上或離線執行個體上操作。例如，您可以註冊使用中的地址，並將其指派給執行中的執行個體，而 OpsWorks Stacks 會自動重新指派該地址。 + 若要註冊和取消註冊資源，您的 IAM 政策必須授予下列動作的許可： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/resources.html) [管理許可等級](opsworks-security-users-console.md)授予所有這些動作的許可。為避免管理使用者註冊或取消註冊特定資源，請編輯他們的 IAM 政策以拒絕適當動作的許可。如需詳細資訊，請參閱[安全與許可](workingsecurity.md)。 **Topics** + [向堆疊註冊資源](resources-reg.md) + [連接與移動資源](resources-attach.md) + [分離資源](resources-detach.md) + [取消註冊資源](resources-dereg.md) # 向堆疊註冊資源 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Amazon EBS 磁碟區或彈性 IP 地址必須先向堆疊註冊，才能將其連接至執行個體。當 OpsWorks Stacks 為堆疊建立資源時，它們會自動向該堆疊註冊。如果您想要使用外部建立的資源，您必須明確註冊它們。注意下列事項： + 您一次只能向一個堆疊註冊資源。 + 當您刪除堆疊時， OpsWorks Stacks 會取消註冊所有資源。 **Topics** + [向堆疊註冊 Amazon EBS 磁碟區](#resources-reg-ebs) + [向堆疊註冊彈性 IP 地址](#resources-reg-eip) + [向堆疊註冊 Amazon RDS 執行個體](#resources-reg-rds) ## 向堆疊註冊 Amazon EBS 磁碟區 **注意** 此資源只搭配 Linux 堆疊使用。雖然您可以使用 Windows 堆疊註冊 Amazon EBS 磁碟區，但無法將其連接至執行個體。您可以使用 **資源**頁面向堆疊註冊 Amazon EBS 磁碟區，但需受下列限制： + 連接的非根 Amazon EBS 磁碟區必須是標準、輸送量最佳化 HDD、冷 HDD、PIOPS 或一般用途 (SSD)，但不是 RAID 陣列。如需磁碟區大小之上限和下限的資訊，請參閱本指南的[EBS 磁碟區](workinglayers-basics-edit.md#workinglayers-basics-edit-ebs)。 + 磁碟區必須是 XFS 格式。 + OpsWorks Stacks 不支援非根 Amazon EBS 磁碟區的其他檔案格式，例如第四個擴充檔案系統 (ext4)。如需準備 Amazon EBS 磁碟區的詳細資訊，請參閱[讓 Amazon EBS 磁碟區可供使用](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html)。請注意，該主題中的範例說明如何建立 ext4 型磁碟區，但您可以遵循相同的步驟建立 XFS 型磁碟區。 **註冊 Amazon EBS 磁碟區** 1. 開啟所需的堆疊，然後按一下導覽窗格中的 **Resources (資源)**。 1. 按一下**磁碟區**以顯示可用的 Amazon EBS 磁碟區。堆疊一開始沒有任何註冊的磁碟區，如下圖所示。 ![\[Resources page showing no registered volumes, with option to show unregistered volumes.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-ebs1.png) 1. 按一下**顯示未註冊的磁碟**區，以顯示您帳戶中位於堆疊區域中的 Amazon EBS 磁碟區，如果適用，則為堆疊的 VPC。**Status (狀態)** 欄指示磁碟區可供使用。**Volume Type (磁碟區類型)** 指出磁碟區是標準 (`standard`)、一般用途 SSD (`gp2`)、PIOPS (`io1`，後面跟著以括號括住的每個磁碟值 IOPS)、輸送量最佳化 HDD (`st1`) 或 Cold HDD (`sc1`)。 ![\[Table of unregistered EBS volumes showing name, EC2 ID, size, type, and status.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-ebs2.png) 1. 選取適當的磁碟區，然後按一下 **Register to Stack (向堆疊註冊)**。**Resources (資源)** 頁面現可列出新註冊的磁碟區。 ![\[Resources page showing a registered volume with details like EC2 ID, size, and actions.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-ebs3.png) 若要註冊其他磁碟區，請按一下 **Show Unregistered Volumes (顯示未註冊的磁碟區)** 或 **\$1 Unregistered Volumes (\$1 未註冊的磁碟區)**，並重複此程序。 ## 向堆疊註冊彈性 IP 地址使用下列程序註冊彈性 IP 地址。 **註冊彈性 IP 地址** 1. 開啟堆疊的 **Resources (資源)** 頁面，然後按一下 **Elastic IPs (彈性 IP)** 顯示可用的彈性 IP 地址。堆疊一開始沒有任何註冊的地址，如下圖所示。 ![\[Resources page showing no registered Elastic IPs with an option to show unregistered ones.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip1.png) 1. 按一下 **Show Unregistered Elastic IPs (顯示未註冊的彈性 IP)** 顯示您帳戶中該堆疊區域的可用彈性 IP 地址。 ![\[List of unregistered Elastic IPs in us-east-1 with options to add, register, and search.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip2.png) 1. 選取適當的地址，然後按一下 **Register to Stack (向堆疊註冊)**。這會讓您回到 **Resources (資源)** 頁面，現可列出新註冊的地址。 ![\[Resources page showing Elastic IPs with one registered address and option to add unregistered IPs.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip3.png) 若要註冊其他地址，請按一下 **Show Unregistered Elastic IPs (顯示未註冊的彈性 IP)** 或 **\$1 Unregistered Elastic IPs (\$1 未註冊的彈性 IP)**，並重複此程序。 ## 向堆疊註冊 Amazon RDS 執行個體使用下列程序註冊 Amazon RDS 執行個體。 **註冊 Amazon RDS 執行個體** 1. 開啟堆疊**的資源**頁面，然後按一下 **RDS** 以顯示可用的 Amazon RDS 執行個體。堆疊一開始沒有任何註冊的執行個體，如下圖所示。 ![\[Resources page showing no registered RDS DB instances with an option to view unregistered instances.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-rds1.png) 1. 按一下**顯示未註冊的 RDS 資料庫執行個體**，以顯示您帳戶中位於堆疊區域中的可用 Amazon RDS 執行個體。 ![\[List of unregistered RDS DB instances with connection details for opsinstance1.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-rds2.png) 1. 選取適當的執行個體，針對 **User (使用者)** 和 **Password (密碼)** 輸入其主要使用者和主密碼值，然後按一下 **Register to Stack (向堆疊註冊)**。這會讓您回到 **Resources (資源)** 頁面，現可會註冊的執行個體。 ![\[RDS resources page showing one MySQL instance with options to add or edit.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-rds3.png) **重要** 您必須確保您用來註冊 Amazon RDS 執行個體的使用者和密碼對應至有效的使用者和密碼。否則，您的應用程式將無法連線至執行個體。若要註冊其他地址，請按一下 **Show Unregistered RDS DB instances (顯示未註冊的 RDS 資料庫執行個體)** 或 **\$1 Unregistered RDS DB instances (\$1 未註冊的 RDS 資料庫執行個體)**，並重複此程序。如需如何搭配 Stacks 使用 Amazon RDS OpsWorks 執行個體的詳細資訊，請參閱 [Amazon RDS 服務層](workinglayers-db-rds.md)。 **注意** 您也可以透過 **Layers** 頁面註冊 Amazon RDS 執行個體。如需詳細資訊，請參閱[Amazon RDS 服務層](workinglayers-db-rds.md)。 # 連接與移動資源 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在您向堆疊註冊資源之後，您就可以將它連接到堆疊的其中一個執行個體。您也可以將已連接的資源從某個執行個體移動到另一個。注意下列事項： + 當您連接或移動 Amazon EBS 磁碟區時，操作中涉及的執行個體必須離線。如果您有興趣的執行個體不在 **Resources (資源)** 頁面中，請移至 **Instances (執行個體)** 頁面[停止執行個體](workinginstances-starting.md)。停止後，您可以返回 **Resources (資源)** 頁面並連接或移動資源。 + 當您連接或移動彈性 IP 地址時，執行個體可以為線上或離線。 + 如果您刪除執行個體，任何連接的資源都保持向堆疊註冊。然後，您可以將資源連接到另一個執行個體；或者，如果您不再需要它，請取消註冊此資源。 **Topics** + [將 Amazon EBS 磁碟區指派給執行個體](#resources-attach-ebs) + [建立彈性 IP 地址與執行個體的關聯](#resources-attach-eip) + [將 Amazon RDS 執行個體連接至應用程式](#resources-attach-rds) ## 將 Amazon EBS 磁碟區指派給執行個體 **注意** 您無法將 Amazon EBS 磁碟區指派給 Windows 執行個體。您可以將已註冊的 Amazon EBS 磁碟區指派給執行個體，並將其從一個執行個體移至另一個執行個體，但兩個執行個體都必須離線。 **將 Amazon EBS 磁碟區指派給執行個體** 1. 在 Resources (資源) 頁面，在適當磁碟區的 **Instance (執行個體)** 欄中按一下 **assign to instance (指派給執行個體)**。 ![\[Resources page showing volume details with "assign to instance" option highlighted.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-ebs4.png) 1. 在磁碟區的 details (詳細資訊) 頁面，選取適當的執行個體，指定磁碟區的名稱和掛載點，然後按一下 **Save (儲存)** 將磁碟區連接到執行個體。 ![\[Volume details page showing fields for name, ID, mount point, and other properties.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-ebs5.png) **重要** 如果您已將外部使用中磁碟區指派給執行個體，則必須使用 Amazon EC2 主控台、API 或 CLI 從原始執行個體取消指派，否則啟動程序將會失敗。您也可以使用詳細資訊頁面，將指派的 Amazon EBS 磁碟區移至堆疊中的另一個執行個體。 **將 Amazon EBS 磁碟區移至另一個執行個體** 1. 確定兩個執行個體都是離線狀態。 1. 在 **Resources (資源)** 頁面中按一下 **Volumes (磁碟區)**，然後在磁碟區的 **Actions (動作)** 欄中按一下 **edit (編輯)**。 1. 執行以下任意一項： + 若要將磁碟區移到堆疊的另一個執行個體，請從 **Instance (執行個體)** 清單中選取適當的執行個體，然後按一下 **Save (儲存)**。 + 若要將磁碟區移至另一個堆疊的執行個體，請[取消註冊磁碟區](resources-dereg.md)、向新的堆疊[註冊磁碟區](resources-reg.md)，然後[連接](#resources-attach)到新的執行個體。 ## 建立彈性 IP 地址與執行個體的關聯您可以建立已註冊彈性 IP 地址與執行個體的關聯，然後將它從一個執行個體移到另一個執行個體，包括其他堆疊中的執行個體。這些執行個體可以是線上或離線。 **建立彈性 IP 位址與執行個體的關聯** 1. 在 **Resources (資源)** 頁面，在適當地址的 **Instance (執行個體)** 欄中按一下 **associate with instance (與執行個體建立關聯)**。 ![\[Elastic IP address row with "associate with instance" highlighted in the Instance column.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip4.png) 1. 在地址的 details (詳細資訊) 頁面，選取適當的執行個體，指定地址的名稱，然後按一下 **Save (儲存)** 建立地址與執行個體的關聯。 ![\[Elastic IP configuration interface showing IP details and instance selection dropdown.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip5.png) **注意** 如果彈性 IP 地址目前與另一個線上執行個體相關聯， OpsWorks Stacks 會自動將地址重新指派給新的執行個體。您也可以使用 details (詳細資訊) 頁面將相關聯彈性 IP 地址移到另一個執行個體。 **將彈性 IP 地址移到另一個執行個體** 1. 在 **Resources (資源)** 頁面中按一下 **Elastic IPs (彈性 IP)**，然後在地址的 **Actions (動作)** 欄中按一下 **edit (編輯)**。 1. 執行以下任意一項： + 若要將地址移到堆疊的另一個執行個體，請從 **Instance (執行個體)** 清單中選取適當的執行個體，然後按一下 **Save (儲存)**。 + 若要將地址移至另一個堆疊中的執行個體，請按一下**堆疊**設定中的**變更**，以查看可用堆疊的清單。從 **Stack (堆疊)** 清單中選取堆疊，從 **Instance (執行個體)** 清單中選取執行個體。然後按一下 **Save (儲存)**。 ![\[Elastic IP configuration panel showing IP address, name, region, domain, stack, and instance details.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip7.png) 在您連接或移動地址之後， OpsWorks Stacks 會觸發[設定生命週期事件](workingcookbook-events.md)，以通知堆疊的執行個體變更。 ## 將 Amazon RDS 執行個體連接至應用程式您可以將 Amazon RDS 執行個體連接至一或多個應用程式。 **將 Amazon RDS 執行個體連接至應用程式** 1. 在 **Resources (資源)** 頁面，在適當執行個體的 **Apps (應用程式)** 欄中按一下 **Add app (新增應用程式)**。 ![\[RDS resources table showing one MySQL instance with options to add apps and edit.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-rds4.png) 1. 使用**新增應用程式**頁面來連接 Amazon RDS 執行個體。如需詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。由於 Amazon RDS 可以連接到多個應用程式，因此沒有將執行個體從一個應用程式移至另一個應用程式的特殊程序。只要編輯第一個應用程式移除 RDS 執行個體，或編輯第二個應用程式新增 RDS 執行個體即可。如需詳細資訊，請參閱[編輯應用程式](workingapps-editing.md)。 # 分離資源 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當您不再需要連接的資源時，您可以分離它。此資源會保持向堆疊註冊，並可連接到其他位置。 **Topics** + [取消指派 Amazon EBS 磁碟區](#resources-detach-ebs) + [取消與彈性 IP 地址的關聯](#resources-detach-eip) + [分離 Amazon RDS 執行個體](#resources-detach-rds) ## 取消指派 Amazon EBS 磁碟區使用下列程序從執行個體取消指派 Amazon EBS 磁碟區。 **取消指派 Amazon EBS 磁碟區** 1. 確定此執行個體為離線狀態。 1. 在 **Resources (資源)** 頁面中按一下 **Volumes (磁碟區)**，然後按一下磁碟區名稱。 1. 在磁碟區的 details (詳細資訊) 頁面，按一下 **Unassign (取消指派)**。 ![\[Volume details page showing settings for PHP-LB-PIOPs, including EC2 Volume ID and mount point.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-ebs8.png) ## 取消與彈性 IP 地址的關聯使用下列程序從其執行個體取消與彈性 IP 地址的關聯。 **取消與彈性 IP 位址的關聯** 1. 在 **Resources (資源)** 頁面中按一下 **Elastic IPs (彈性 IP)**，然後在地址的 **Actions (動作)** 欄中按一下 **edit (編輯)**。 1. 在地址的 details (詳細資訊) 頁面，按一下 **Disassociate (取消關聯)**。 ![\[Elastic IP details page showing settings for PHP-Vol2 with IP address and instance information.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip8.png) 取消與地址的關聯之後， OpsWorks Stacks 會觸發[設定生命週期事件](workingcookbook-events.md)，以通知堆疊的執行個體變更。 ## 分離 Amazon RDS 執行個體使用下列程序從應用程式分離 Amazon RDS。 **分離 Amazon RDS 執行個體** 1. 在 **Resources (資源)** 頁面中按一下 **RDS**，然後在 **Apps (應用程式)** 欄中按一下適當的應用程式。 1. 按一下 **Edit (編輯)**，編輯應用程式組態以分離執行個體。如需詳細資訊，請參閱[編輯應用程式](workingapps-editing.md)。 **注意** 此程序會將 Amazon RDS 從單一應用程式分離。如果執行個體連接到多個應用程式，您必須為每個應用程式重複此程序。 # 取消註冊資源 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果您不再需要向堆疊註冊資源，您可以取消註冊。取消註冊不會從您的帳戶刪除資源；資源會保留在那裡，並且可以使用另一個堆疊註冊或在 Stacks OpsWorks 外部使用。如果您要刪除整個資源，您有兩個選擇： + 如果彈性 IP 或 Amazon EBS 資源連接到執行個體，您可以在刪除執行個體時刪除資源。移至 **Instances (執行個體)** 頁面，按一下執行個體 **Actions (動作)** 欄中的 **delete (刪除)**，然後選取 **Delete instance's EBS volumes (刪除執行個體的 EBS 磁碟區)** 或 **Delete the instance's Elastic IP (刪除執行個體的彈性 IP)**。 + 取消註冊資源，然後使用 Amazon EC2 或 Amazon RDS 主控台、API 或 CLI 將其刪除。 **Topics** + [取消註冊 Amazon EBS 磁碟區](#resources-dereg-ebs) + [取消註冊彈性 IP 地址](#resources-dereg-eip) + [取消註冊 Amazon RDS 執行個體](#resources-dereg-rds) ## 取消註冊 Amazon EBS 磁碟區使用下列程序取消註冊 Amazon EBS 磁碟區。 **取消註冊 Amazon EBS 磁碟區** 1. 如果磁碟區已連接到執行個體，請如[取消指派 Amazon EBS 磁碟區](resources-detach.md#resources-detach-ebs)中所述取消指派它。 1. 在 **Resources (資源)** 頁面，按一下 **Name (名稱)** 欄的磁碟區名稱。 1. 在磁碟區的 details (詳細資訊) 頁面，按一下 **Deregister (取消註冊)**。 ![\[Volume details page showing settings for PHP-LB-PIOPs with name and EC2 Volume ID fields.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-ebs9.png) ## 取消註冊彈性 IP 地址使用下列程序取消註冊彈性 IP 地址。 **取消註冊彈性 IP 地址** 1. 如果地址與執行個體相關聯，請如[取消與彈性 IP 地址的關聯](resources-detach.md#resources-detach-eip)中所述取消關聯。 1. 在 **Resources (資源)** 頁面中按一下 **Elastic IPs (彈性 IP)**，然後按一下 **Address (地址)** 欄中的 IP 地址。 1. 在地址的 details (詳細資訊) 頁面，按一下 **Deregister (取消註冊)**。 ![\[Elastic IP settings page showing IP address, name, region, domain, and instance details.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-eip9.png) **注意** 如果您只想向不同的堆疊註冊 Elastic IP 地址，您必須從它目前的堆疊取消註冊，然後向新的堆疊註冊。不過，您可以將已連接的彈性 IP 地址直接移到另一個堆疊的執行個體。如需詳細資訊，請參閱[連接與移動資源](resources-attach.md)。 ## 取消註冊 Amazon RDS 執行個體使用下列程序取消註冊 Amazon RDS 執行個體。 **取消註冊 Amazon RDS 執行個體** 1. 如果執行個體與應用程式相關聯，請如[分離資源](resources-detach.md)中所述分離它。 1. 在 **Resources (資源)** 頁面中按一下 **RDS**，然後按一下執行個體的名稱。 1. 在執行個體的 details (詳細資訊) 頁面，按一下 **Deregister (取消註冊)**。 ![\[RDS instance details page showing settings and configuration for opsinstance1.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/resources-rds5.png) # Tags (標籤) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。標籤可以協助您對 Chef 11.10、Chef 12 和 Chef 12.2 堆疊中的資源進行分組，並追蹤在 [AWS 帳單與成本管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html) 中使用這些資源的成本。您可以在堆疊和 layer 層級套用標籤。建立標籤時，您會將標籤套用於已加上標籤的結構中每項資源。例如，如果您將標籤套用至 layer，您要將標籤套用至 layer 中的每個執行個體、Amazon EBS 磁碟區（根除外）或 Elastic Load Balancing 負載平衡器。標籤目前無法套用至執行個體根或預設的 EBS 磁碟區。標籤是您指派給 Stacks OpsWorks 中堆疊或層的鍵/值對。建立標籤後，請開啟 Billing and Cost Management 主控台以啟用使用者定義的標籤。如需如何啟用標籤並使用它們來追蹤和管理 OpsWorks Stacks 資源成本的詳細資訊，請參閱帳單與成本管理使用者指南中的[使用成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)和[啟用使用者定義的成本分配標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)。 ** 標籤的運作方式類似於 Stacks OpsWorks 中的自訂屬性。您套用到堆疊的標籤，會由該堆疊中的每個 layer 繼承。在圖層層級，您可以覆寫繼承標籤的值（而非金鑰名稱），並新增新的圖層特定標籤。會將產生的標籤集 OpsWorks 套用至圖層中的所有資源。當您建立新資源或將現有資源指派到某個 layer 時，該 layer 中的新資源將使用相同的標籤集進行標記。 **Topics** + [在堆疊層級設定標籤](#w2ab1c14c63c15) + [在 Layer 層級設定標籤](#w2ab1c14c63c17) + [使用管理標籤 AWS CLI](#w2ab1c14c63c19) + [標籤限制](#w2ab1c14c63c21) ## 在堆疊層級設定標籤在堆疊層級，您可以在堆疊的首頁上選擇 **Tags (標籤)** 來新增和管理標籤。 ![\[Tags section with icon and description for applying tags to stack resources.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/stack_tags.png) 在 **Tags (標籤)** 頁面上，將標籤新增為鍵/值對。下列螢幕擷取畫面示範一些範例標籤。您可以選擇鍵/值對右邊的紅色 **X** 來刪除標籤。 ![\[Tags interface showing key-value pairs for Organization and Staging, with options to add or delete tags.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/stack_tags_add.png) ## 在 Layer 層級設定標籤在 layer 層級，選擇 **Tags (標籤)** 標籤來設定標籤。您可以在 **Layers (Layer)** 首頁以及每個 layer 的首頁上找到此標籤。 ![\[List of layers including ELB, HAProxy, Rails, PHP, Node.js, and MySQL with configuration options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/layers_tags.png) 當您在 layer 層級變更或新增標籤時，請注意，已在父堆疊層級新增的標籤將由該 layer 及其資源繼承。雖然您可以變更繼承標籤的值，但無法變更鍵名稱或刪除繼承標籤。請在堆疊設定中變更鍵名稱或刪除從父堆疊繼承的標籤。下列螢幕擷取畫面示範從堆疊層級繼承的標籤。繼承的標籤呈現灰色。 ![\[Tags interface showing inherited and editable fields for Organization and Staging keys.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/layer_inherited_tags.png) 如需將標籤新增至堆疊的詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。如需如何將標籤新增至 layer 的詳細資訊，請參閱[編輯 OpsWorks Layer 的組態](workinglayers-basics-edit.md)。 ## 使用管理標籤 AWS CLI 您也可以使用 AWS CLI 命令在堆疊和 layer 層級新增和移除標籤。如需下載和安裝的詳細資訊 AWS CLI，請參閱[安裝 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)。如果要標記的堆疊不在您的預設區域內，請記得將 `--region` 參數新增到您的命令中。Layer ARNs目前不會顯示在中 AWS 管理主控台。若要取得 layer 的 ARN，請執行 [describe-layers](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-layers.html) 命令。 **使用新增標籤 AWS CLI** + 在 AWS CLI 命令提示字元中輸入下列命令，取代 *stack\$1or\$1layer\$1ARN* 並指定您的鍵值對標籤，然後按 **Enter** 鍵。雙引號會以反斜線逸出。 ``` aws opsworks tag-resource --resource-arn stack_or_layer_ARN --tags "{\"key\":\"value\",\"key\":\"value\"}" ``` 下列是範例。 ``` aws opsworks tag-resource --resource-arn arn:aws:opsworks:us-east-2:800000000003:stack/500b99c0-ec00-4cgg-8a0d-1000000jjd1b --tags "{\"Stage\":\"Production\",\"Organization\":\"Mobile\"}" ``` **使用移除標籤 AWS CLI** + 在 AWS CLI 命令提示字元中輸入以下內容，然後按 **Enter**。 ``` aws opsworks untag-resource --resource-arn stack_or_layer_ARN --tag-keys "[\"key\",\"key\"]" ``` 若要移除標籤，您只需指定您想要移除的標籤鍵即可。下列是範例。 ``` aws opsworks untag-resource --resource-arn arn:aws:opsworks:us-east-2:800000000003:stack/500b99c0-ec00-4cgg-8a0d-1000000jjd1b --tag-keys "[\"Stage\",\"Organization\"]" ``` **注意** 您無法從 layer 中移除繼承的標籤 (在父堆疊層級中新增的標籤)。請從堆疊移除繼承的標籤。 ## 標籤限制建立標籤時，請謹記下列限制： + OpsWorks Stacks 會將堆疊和 layer 層級的使用者定義標籤數量限制為 40，包括繼承自父層級的使用者定義標籤。這將保留 10 個可用插槽，用於以開頭的預設標籤`opsworks:`，以及由其他 AWS 程序設定的標籤。資源最多允許 50 個標籤，包括由建立的使用者定義和預設標籤 AWS。 + 標籤鍵不能以 **aws:**、**opsworks:** 或 **rds:** 起始。請勿使用 **name**或 **Name**做為標籤索引鍵，因為 **Name** 是由 Stacks OpsWorks 保留。 + 一個鍵最多可包含 127 個字元，並且只能包含 Unicode 字母、數字或分隔符號，或是下列特殊字元：`+ - = . _ : / `。 + 一個值最多可包含 255 個字元，並且只能包含 Unicode 字母、數字或分隔符號，或是下列特殊字元：`+ - = . _ : / `。 # 監控 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可採用以下方式來監控您的堆疊。 + OpsWorks Stacks 使用 Amazon CloudWatch 為堆疊中的每個執行個體提供 13 個具有詳細監控的自訂指標。 + OpsWorks Stacks 與整合 AWS CloudTrail ，以記錄每個 OpsWorks Stacks API 呼叫，並將資料存放在 Amazon S3 儲存貯體中。 + 您可以使用 Amazon CloudWatch Logs 來監控堆疊的系統、應用程式和自訂日誌。 **Topics** + [使用 Amazon CloudWatch 監控堆疊](monitoring-cloudwatch.md) + [使用 OpsWorks 記錄 Stacks API 呼叫 AWS CloudTrail](monitoring-cloudtrail.md) + [搭配 Stacks OpsWorks 使用 Amazon CloudWatch Logs](monitoring-cloudwatch-logs.md) + [使用 Amazon CloudWatch Events 監控堆疊](monitoring-cloudwatch-events.md) # 使用 Amazon CloudWatch 監控堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 使用 Amazon CloudWatch (CloudWatch) 來監控堆疊。 + 對於 Linux 堆疊， OpsWorks Stacks 支援十三個自訂指標，為堆疊中的每個執行個體提供詳細監控，並在**監控**頁面上總結資料，方便您使用。 + 對於 Windows 堆疊，您可以使用 [CloudWatch 主控台](https://console.aws.amazon.com/cloudwatch/)監控執行個體的標準 Amazon EC2 指標。 **Monitoring (監控)** 頁面不會顯示 Windows 指標。 **監控**頁面會顯示整個堆疊、 layer 或執行個體的指標。 OpsWorks Stacks 指標與 Amazon EC2 指標不同。您也可以透過 CloudWatch 主控台啟用其他指標，但通常需要額外付費。您也可以在 CloudWatch 主控台上檢視基礎資料，如下所示： **在 CloudWatch 中檢視 OpsWorks 自訂指標** 1. 透過 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 開啟 CloudWatch 主控台。 1. 在導覽列中，選取堆疊的區域。 1. 在導覽窗格中，選擇 **指標**。 1. 在 OpsWorks Metrics (OpsWorks 指標) 中，選擇 **Instance Metrics (執行個體指標)**、**Layer Metrics (Layer 指標)** 或 **Stack Metrics (堆疊指標)**。 ![\[CloudWatch metrics summary showing 362 total metrics across EBS, EC2, ElastiCache, and OpsWorks categories.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/monitor_cloudwatch.png) **注意** OpsWorks Stacks 透過在每個執行個體（執行個體代理程式）上執行程序來收集指標。由於 CloudWatch 使用 Hypervisor 收集指標的方式不同，因此 CloudWatch 主控台中的值可能與 Stacks 主控台中**監控**頁面上 OpsWorks 的對應值略有不同。您也可以使用 CloudWatch 主控台來設定警示。如需如何建立警示的詳細資訊，請參閱[建立 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。如需 CloudWatch 自訂指標的清單，請參閱 [AWS OpsWorks 指標和維度](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ops-metricscollected.html)。如需詳細資訊，請參閱 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)。 **Topics** + [AWS OpsWorks 堆疊指標](#opsworks-metrics-dimensions) + [OpsWorks 堆疊指標的維度](#opsworks-metricdimensions) + [堆疊指標](#monitoring-cloudwatch-stack) + [Layer 指標](#monitoring-cloudwatch-layer) + [執行個體指標](#monitoring-cloudwatch-instance) ## AWS OpsWorks 堆疊指標 OpsWorks Stacks 每五分鐘會將下列指標傳送至 CloudWatch。 **CPU 指標** | 指標 | Description | | --- | --- | | `cpu_idle` | CPU 閒置時間的百分比。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `cpu_nice` | CPU 處理具有正`nice`值之程序的時間百分比，其排程優先順序較低。如需這項措施的詳細資訊，請參閱[良好 (Unix)](http://en.wikipedia.org/wiki/Nice_(Unix))。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `cpu_steal` | 隨著 AWS 在越來越多的執行個體中配置 Hypervisor CPU 資源，虛擬化負載會增加，並可能影響 Hypervisor 在執行個體上執行請求工作的頻率。會`cpu_steal`測量執行個體等待 Hypervisor 配置實體 CPU 資源的時間百分比。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `cpu_system` | CPU 正在處理系統操作的時間百分比。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `cpu_user` | CPU 處理使用者操作的時間百分比。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `cpu_waitio` | CPU 等待輸入/輸出操作的時間百分比。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | **記憶體指標** | 指標 | Description | | --- | --- | | `memory_buffers` | 緩衝記憶體的數量。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `memory_cached` | 快取記憶體的數量。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `memory_free` | 可用記憶體的數量。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `memory_swap` | 交換空間的數量。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `memory_total` | 記憶體總量。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `memory_used` | 使用中的記憶體數量。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | **載入指標** | 指標 | Description | | --- | --- | | `load_1` | 一分鐘時段內的平均負載。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `load_5` | 在五分鐘時段內平均的負載。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | | `load_15` | 在 15 分鐘時段內的平均負載。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | **程序指標** | 指標 | Description | | --- | --- | | `procs` | 作用中程序的數量。有效維度：您要檢視指標之個別資源IDs：StackId、 LayerId 或 InstanceId。有效統計資料：`Average`、`Minimum`、`Sum`、 `Maximum`或 `Data Samples`。單位：無 | ## OpsWorks 堆疊指標的維度 OpsWorks Stacks 指標使用 OpsWorks Stacks 命名空間，並提供下列維度的指標： | 維度 | Description | | --- | --- | | `StackId` | 堆疊的平均值。 | | `LayerId` | 分層的平均值。 | | `InstanceId` | 執行個體的平均值。 | ## 堆疊指標若要檢視整個堆疊的指標摘要，請在堆疊**儀表板**中選取 OpsWorks 堆疊，然後在導覽窗格中按一下**監控**。下列範例為使用 PHP 和資料庫 layer 的堆疊。 ![\[Monitoring dashboard showing CPU, memory, load, and process metrics for system layers over time.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/monitor_stack.png) 堆疊檢視會為每個 layer 顯示經過一段指定時間後四類指標的圖表：1 小時、8 小時、24 小時、1 週或 2 週。注意下列事項： + OpsWorks Stacks 會定期更新圖形；右上角的倒數計時器會指出下次更新之前剩餘的時間。 + 如果 layer 有多個執行個體，圖表會顯示 layer 的平均值。 + 您可以按一下右上的清單，然後選取您慣用的值指定期間。您可以使用圖表上方的清單，為每個指標類型選取您要檢視的特定指標。 ## Layer 指標若要查看特定 layer 的指標，請按一下 **Monitoring Layers (監控 Layers)** 檢視中的 layer 名稱。下列範例顯示 PHP layer 的指標，它有兩個執行個體。 ![\[Monitoring dashboard showing CPU, memory, load, and processes for two PHP app server instances over time.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/monitor_layer.png) 指標類型和堆疊指標的類型相同，您可以使用圖表上方的清單，為每個類型選取您要檢視的特定指標。 **注意** 您也可以移至 layer 的 details (詳細資訊) 頁面，按一下右上角的 **Monitoring (監控)**，顯示 layer 指標。 ## 執行個體指標若要檢視特定執行個體的指標，請按一下 layer 監控檢視中的執行個體名稱。下列範例顯示 PHP layer **php-app1** 執行個體的指標。 ![\[Dashboard showing CPU, memory, load, and process metrics for a PHP application instance.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/monitor_instance.png) 圖表摘要每個指標類型所有可用的指標。若要取得特定時間點的確切值，請使用滑鼠將滑桿 (上圖中紅色箭頭所指處) 移至適當的位置。 **注意** 您也可以移至執行個體的 details (詳細資訊) 頁面，選擇右上角的 **Monitoring (監控)**，來顯示執行個體指標。 # 使用 OpsWorks 記錄 Stacks API 呼叫 AWS CloudTrail **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 已與服務整合 AWS CloudTrail，此服務可提供 IAM 身分所採取之動作的記錄，或 Stacks OpsWorks 中的 AWS 服務。CloudTrail OpsWorks 會將 Stacks 的所有 API 呼叫擷取為事件，包括從 Stacks OpsWorks 主控台以及從程式碼呼叫到 OpsWorks Stacks APIs呼叫。如果您建立線索，則可以將 CloudTrail 事件持續交付至 Amazon S3 儲存貯體，包括 Stacks OpsWorks 的事件。即使您未設定追蹤，依然可以透過 CloudTrail 主控台中的**事件歷史記錄**檢視最新事件。您可以使用 CloudTrail 所收集的資訊，判斷對 OpsWorks Stacks 提出的請求、提出請求的 IP 地址、提出請求的人員、提出請求的時間，以及其他詳細資訊。若要進一步了解 CloudTrail，請參閱[「AWS CloudTrail 使用者指南」](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)。 ## OpsWorks CloudTrail 中的堆疊資訊當您建立 AWS 帳戶時，會在您的帳戶上啟用 CloudTrail。當活動在 OpsWorks Stacks 中發生時，該活動會與**事件歷史記錄**中的其他服務 AWS 事件一起記錄在 CloudTrail 事件中。您可以在 AWS 帳戶中檢視、搜尋和下載最近的事件。如需詳細資訊，請參閱《使用 CloudTrail 事件歷史記錄檢視事件》[https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)。若要持續記錄您 AWS 帳戶中的事件，包括 Stacks OpsWorks 的事件，請建立追蹤。線索能讓 CloudTrail 將日誌檔案交付至 Amazon S3 儲存貯體。根據預設，當您在主控台建立線索時，線索會套用到所有區域。線索會記錄 AWS 分割區中所有區域的事件，並將日誌檔案傳送到您指定的 Amazon S3 儲存貯體。此外，您可以設定其他 AWS 服務，以進一步分析和處理 CloudTrail 日誌中收集的事件資料。如需詳細資訊，請參閱： + [建立追蹤的概觀](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) + [CloudTrail 支援的服務和整合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations) + [設定 CloudTrail 的 Amazon SNS 通知](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html) + [從多個區域接收 CloudTrail 日誌檔案](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)，以及[從多個帳戶接收 CloudTrail 日誌檔案](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) CloudTrail OpsWorks 會記錄所有 Stacks 動作，並記錄在 [AWS OpsWorks Stacks API 參考中。](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)例如，對 `[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html)`、`[DescribeInstances](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeInstances.html)` 以及 `[StartInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_StartInstance.html)` 動作發出的呼叫會在 CloudTrail 日誌檔案中產生項目。每一筆事件或日誌專案都會包含產生請求者的資訊。身分資訊可協助您判斷下列事項： + 該請求是否使用根或 IAM 使用者憑證提出。 + 提出該請求時，是否使用了特定角色或聯合身分使用者的暫時安全憑證。 + 請求是否由其他 AWS 服務提出。如需詳細資訊，請參閱 [CloudTrail userIdentity 元素](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)。 ## 了解 OpsWorks Stacks 日誌檔案項目追蹤是一種組態，能讓事件以日誌檔案的形式交付到您指定的 Amazon S3 儲存貯體。CloudTrail 日誌檔案包含一或多個日誌專案。一個事件為任何來源提出的單一請求，並包含請求動作、請求的日期和時間、請求參數等資訊。CloudTrail 日誌檔案並非依公有 API 呼叫追蹤記錄的堆疊排序，因此不會以任何特定順序出現。以下範例顯示的是展示 `CreateLayer` 動作的 CloudTrail 日誌項目。 ``` { "Records": [ { "awsRegion": "us-west-2", "eventID": "342cd1ec-8214-4a0f-a68f-8e6352feb5af", "eventName": "CreateLayer", "eventSource": "opsworks.amazonaws.com", "eventTime": "2014-05-28T16:05:29Z", "eventVersion": "1.01"ed, "requestID": "e3952a2b-e681-11e3-aa71-81092480ee2e", "requestParameters": { "attributes": {}, "customRecipes": {}, "name": "2014-05-28 16:05:29 +0000 a073", "shortname": "customcf4571d5c0d6", "stackId": "a263312e-f937-4949-a91f-f32b6b641b2c", "type": "custom" }, "responseElements": null, "sourceIPAddress": "198.51.100.0", "userAgent": "aws-sdk-ruby/2.0.0 ruby/2.1 x86_64-linux", "userIdentity": { "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "accountId": "111122223333", "arn": "arn:aws:iam::111122223333:user/A-User-Name", "principalId": "AKIAI44QH8DHBEXAMPLE", "type": "IAMUser", "userName": "A-User-Name" } }, { "awsRegion": "us-west-2", "eventID": "a860d8f8-c1eb-449b-8f55-eafc373b49a4", "eventName": "DescribeInstances", "eventSource": "opsworks.amazonaws.com", "eventTime": "2014-05-28T16:05:31Z", "eventVersion": "1.01", "requestID": "e4691bfd-e681-11e3-aa71-81092480ee2e", "requestParameters": { "instanceIds": [ "218289c4-0492-473d-a990-3fbe1efa25f6" ] }, "responseElements": null, "sourceIPAddress": "198.51.100.0", "userAgent": "aws-sdk-ruby/2.0.0 ruby/2.1x86_64-linux", "userIdentity": { "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "accountId": "111122223333", "arn": "arn:aws:iam::111122223333:user/A-User-Name", "principalId": "AKIAI44QH8DHBEXAMPLE", "type": "IAMUser", "userName": "A-User-Name" } } ] } ``` # 搭配 Stacks OpsWorks 使用 Amazon CloudWatch Logs **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。為了簡化監控多個執行個體日誌的程序， OpsWorks Stacks 支援 Amazon CloudWatch Logs。您可以在 Stacks 的 layer OpsWorks 層級啟用 CloudWatch Logs。CloudWatch Logs 整合適用於 Chef 11.10 和 Chef 12 Linux 型堆疊。啟用 CloudWatch Logs 時會產生額外費用，因此請在開始使用之前檢閱 [Amazon CloudWatch 定價](https://aws.amazon.com/cloudwatch/pricing/)。 CloudWatch Logs 會監控選取的日誌是否存在使用者指定的模式。例如，您可以監控出現 `NullReferenceException` 等文字的日誌，或計算這類事件的數目。在 Stacks OpsWorks 中啟用 CloudWatch Logs 之後，Stacks OpsWorks 代理程式會將日誌傳送至 CloudWatch Logs。如需 CloudWatch Logs 的詳細資訊，請參閱 [ CloudWatch Logs 入門](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_GettingStarted.html)。 ## 先決條件在啟用 CloudWatch Logs 之前，您的執行個體必須在 Chef 11.10 堆疊中執行 3444 版或更新版本的 OpsWorks Stacks 代理程式，並在 Chef 12 堆疊中執行 4023 版或更新版本。您也必須為使用 CloudWatch Logs 監控的任何執行個體使用相容的執行個體描述檔。如果您使用的是自訂執行個體描述檔 OpsWorks (Stacks 在您建立堆疊時未提供的描述檔）， OpsWorks Stacks 就無法自動升級執行個體描述檔。您必須使用 IAM 手動將 **AWSOpsWorksCloudWatchLogs** 政策連接至您的設定檔。如需詳細資訊，請參閱《[IAM 使用者指南》中的管理 IAM 政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#attach-managed-policy-console)。 ** 如果您需要升級代理程式版本或執行個體描述檔，當您開啟 **Layer** 頁面上的 CloudWatch Logs 索引標籤時， OpsWorks Stacks 會顯示類似下列螢幕擷取畫面的提醒。 ![\[Layer 頁面上的 CloudWatch Logs 索引標籤\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cw_logs_upgrade.png) 更新 layer 中所有執行個體上的代理程式可能需要一些時間。如果您在客服人員升級完成之前嘗試在 layer 上啟用 CloudWatch Logs，您會看到類似以下的訊息。 ![\[Layer 頁面上的 CloudWatch Logs 索引標籤\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cloudwatch_logs_upgrade_time.png) ## 啟用 CloudWatch Logs 1. 完成任何必要的代理程式和執行個體設定檔升級後，您可以將 CloudWatch Logs 標籤上的滑桿控制項設定為**開啟**，以啟用 **CloudWatch Logs**。 ![\[CloudWatch Logs 滑桿控制\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cw_logs_enable_switch.png) 1. 若要串流命令日誌，請將 **Stream command logs (串流命令日誌)** 滑桿設定為 **On (開啟)**。這會將 layer 執行個體上的 Chef 活動和使用者起始命令的日誌傳送至 CloudWatch Logs。當您開啟日誌 URL 的目標時，這些日誌中包含的資料與您在 [DescribeCommands](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html) 操作結果中看到的內容密切相符。它包含有關 `setup`、`configure`、`deploy`、`undeploy`、`start`、`stop` 和配方執行命令的資料。 1. 若要串流存放在 layer 執行個體上之自訂位置的活動日誌，例如 `/var/log/apache/myapp/mylog*`，請在 **Stream custom logs (串流自訂日誌)** 字串方塊中輸入自訂位置，然後選擇 **Add (新增)** (**\$1**)。 1. 選擇**儲存**。在幾分鐘內， OpsWorks Stacks 日誌串流應該會顯示在 CloudWatch Logs 主控台中。 ![\[CloudWatch Logs 已啟用\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cw_logs_enabled.png) ## 關閉 CloudWatch Logs 若要關閉 CloudWatch Logs，請編輯您的 layer 設定。 1. 在您 layer 的 properties (屬性) 頁面上，選擇 **Edit (編輯)**。 ![\[Layer properties (屬性) 頁面上的 Edit (編輯) 按鈕\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cw_logs_enabled_edit.png) 1. 在編輯頁面上，選擇 **CloudWatch Logs (CloudWatch 日誌)** 標籤。 1. 在 **CloudWatch Logs (CloudWatch 日誌)** 區域中，關閉 **Stream command logs (串流命令日誌)**。選擇自訂日誌的 **X** 將它們從日誌串流刪除 (如果適用)。 1. 選擇**儲存**。 ### 從 CloudWatch Logs 刪除串流日誌從 Stacks 關閉 CloudWatch Logs OpsWorks 串流後，現有的日誌仍可在 CloudWatch Logs 管理主控台中使用。除非您將日誌匯出至 Amazon S3 或刪除日誌，否則您仍需支付儲存日誌的費用。如需將日誌匯出至 S3 的詳細資訊，請參閱[將日誌資料匯出至 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)。您可以在 CloudWatch Logs 管理主控台或透過執行和 [https://docs.aws.amazon.com/cli/latest/reference/logs/delete-log-group.html](https://docs.aws.amazon.com/cli/latest/reference/logs/delete-log-group.html) AWS CLI 命令來刪除日誌串流[https://docs.aws.amazon.com/cli/latest/reference/logs/delete-log-stream.html](https://docs.aws.amazon.com/cli/latest/reference/logs/delete-log-stream.html)和日誌群組。如需變更日誌保留期間的詳細資訊，請參閱在 [ CloudWatch Logs 中變更日誌資料保留](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html)。 ## 在 CloudWatch Logs 中管理您的日誌您正在串流的日誌會在 CloudWatch Logs 主控台中管理。 ![\[CloudWatch Logs 主控台\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cw_logs_dash.png) OpsWorks 會自動建立預設日誌群組和日誌串流。 OpsWorks Stacks 資料的日誌群組名稱符合以下模式： *stack\$1name*`/`*layer\$1name*`/`*chef\$1log\$1name* 自訂日誌名稱符合下列模式： */stack\$1name/layer\$1short\$1name/file\$1path\$1name*。路徑名稱在移除星號 (\$1) 等特殊字元後，更容易閱讀。當您在 CloudWatch Logs 中找到日誌時，您可以將[日誌組織成群組](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Create-Log-Group.html)、[建立指標篩選條件來搜尋和篩選日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)，以及[建立自訂警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)。 ## 設定 Chef 12.2 Windows Layer 使用 CloudWatch Logs Windows 執行個體不支援 CloudWatch Logs 自動整合。無法在 Chef 12.2 堆疊中的 layer 上使用 **CloudWatch Logs (CloudWatch 日誌)** 標籤。若要手動啟用串流至適用於 Windows 執行個體的 CloudWatch Logs，請執行下列動作。 + 更新 Windows 執行個體的執行個體描述檔，以便 CloudWatch Logs 代理程式具有適當的許可。**AWSOpsWorksCloudWatchLogs** 政策陳述式會顯示必要的許可。此任務一般只需要執行一次。然後，您可以為 layer 中所有的 Windows 執行個體使用更新的執行個體描述檔。 + 在每個執行個體上編輯下列 JSON 組態檔案。這個檔案包含日誌串流偏好設定，例如要監控哪些日誌。 `%PROGRAMFILES%\Amazon\Ec2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json` 您可以建立自訂配方處理必要任務，將它們指派給 Chef 12.2 layer 的 **Setup (設定)** 事件，來自動化前兩項任務。每次在這些 layer 上啟動新的執行個體時， OpsWorks Stacks 都會在執行個體完成開機後自動執行您的配方，以啟用 CloudWatch Logs。若要在 Windows 執行個體上關閉 CloudWatch Logs，請反轉程序。清除 **EC2 Service Properties** 對話方塊中的**啟用 CloudWatch Logs 整合**核取方塊，從 `AWS.EC2.Windows.CloudWatch.json` 檔案刪除日誌串流偏好設定，並停止執行任何自動將 CloudWatch Logs 許可指派給 Chef 12.2 layer 中新執行個體的 Chef 配方。 # 使用 Amazon CloudWatch Events 監控堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以在 Amazon CloudWatch Events OpsWorks 中設定規則來提醒您 Stacks 資源的變更，並指示 CloudWatch Events 根據事件內容採取動作。如需如何開始使用 CloudWatch Events 和設定規則的詳細資訊，請參閱[CloudWatch Events 使用者指南》中的 CloudWatch Events 入門](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CWE_GettingStarted.html)。 *CloudWatch * CloudWatch Events OpsWorks 支援下列 Stacks 事件類型。 **Instance state change (執行個體狀態變更)** 表示 Stacks OpsWorks 執行個體的狀態變更。 **Command state change (命令狀態變更)** 表示 Stacks OpsWorks 命令的狀態發生變更。 **Deployment state change (部署狀態變更)** 表示 OpsWorks Stacks 部署的狀態發生變更。 **Alerts (提醒)** 表示已引發 OpsWorks Stacks 服務錯誤。如需 CloudWatch Events 支援之 OpsWorks Stacks 事件類型的詳細資訊，請參閱《CloudWatch Events 使用者指南》中的 [OpsWorks Stacks](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#opsworks_event_types) Events。 *CloudWatch * # 安全與許可 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您的每個使用者都必須有適當的 AWS 登入資料，才能存取您帳戶 AWS 的資源。向使用者提供登入資料的建議方法是使用 [AWS Identity and Access Management](https://docs.aws.amazon.com/iam/)(IAM)。 OpsWorks Stacks 與 IAM 整合，可讓您控制下列項目： + 個別使用者如何與 Stacks OpsWorks 互動。例如，您可以允許某些使用者在任何堆疊部署應用程式，但不能修改堆疊本身，同時授予其他使用者特定堆疊的完整存取權等等。 + Stacks OpsWorks 如何代表您存取堆疊資源，例如 Amazon EC2 執行個體和 Amazon S3 儲存貯體。 OpsWorks Stacks 提供的服務角色會授予這些任務的許可。 + 在 Stacks 控制之 Amazon EC2 OpsWorks 執行個體上執行的應用程式如何存取其他 AWS 資源，例如存放在 Amazon S3 儲存貯體上的資料。您可以將執行個體描述檔指派給 layer 的執行個體，以授予在這些執行個體上執行的應用程式存取其他 AWS 資源的許可。 + 如何管理以使用者為基礎的 SSH 金鑰，以及使用 SSH 或 RDP 連線到執行個體。針對每個堆疊，管理使用者都可以指派每個使用者個人的 SSH 金鑰，或授權使用者指定自己的金鑰。您也可以在每個使用者的堆疊執行個體上授權 SSH 或 RDP 存取權以及 sudo 或管理員權限。其他安全方面包括下列項目： + 如何使用最新的安全性修補程式管理更新您的執行個體作業系統。如需詳細資訊，請參閱[管理安全性更新](workingsecurity-updates.md)。 + 如何設定 [Amazon EC2 安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)來控制往返執行個體的網路流量。如何指定自訂安全群組，而不是 OpsWorks Stacks 預設安全群組。如需詳細資訊，請參閱[使用安全群組](workingsecurity-groups.md)。 **Topics** + [管理 OpsWorks Stacks 使用者許可](opsworks-security-users.md) + [允許 OpsWorks Stacks 代表您採取行動](opsworks-security-servicerole.md) + [Stacks OpsWorks 中的跨服務混淆代理人預防](cross-service-confused-deputy-prevention-stacks.md) + [指定在 EC2 執行個體上執行之應用程式的許可](opsworks-security-appsrole.md) + [管理 SSH 存取](security-ssh-access.md) + [管理 Linux 安全性更新](workingsecurity-updates.md) + [使用安全群組](workingsecurity-groups.md) # 管理 OpsWorks Stacks 使用者許可 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。最佳實務是將 OpsWorks Stacks 使用者限制為一組指定的動作或一組堆疊資源。您可以透過兩種方式控制 OpsWorks Stacks 使用者許可：使用 OpsWorks Stacks **許可**頁面，以及套用適當的 IAM 政策。 OpsWorks **許可**頁面 - 或同等的 CLI 或 API 動作 - 可讓您透過為每個使用者指派多個許可*層級中的一個來控制多使用者環境中的使用者許可*。每個層級都會授予特定堆疊資源之標準動作組的許可。使用 **Permissions (許可)** 頁面，您可以控制下列項目： + 誰可以存取每個堆疊。 + 每個使用者在每個堆疊上允許執行的動作有哪些。例如，您可以允許一部分的使用者僅能檢視堆疊，其他使用者則能部署應用程式、新增執行個體等。 + 誰可以管理每個堆疊。您可以將每個堆疊的管理委派給一或多個指定的使用者。 + 在每個堆疊的 Amazon EC2 執行個體上具有使用者層級 SSH 存取和 sudo 權限 (Linux) 或 RDP 存取和管理員權限 (Windows) 的人員。您可以隨時為每個使用者分別授予或移除這些許可。 **重要** 拒絕 SSH/RDP 存取不一定能防止使用者登入執行個體。如果您為執行個體指定 Amazon EC2 金鑰對，則任何具有對應私有金鑰的使用者都可以登入或使用金鑰來擷取 Windows 管理員密碼。如需詳細資訊，請參閱[管理 SSH 存取](security-ssh-access.md)。您可以使用 [IAM 主控台](https://console.aws.amazon.com/iam)、CLI 或 API 將政策新增至您的使用者，以授予各種 OpsWorks Stacks 資源和動作的明確許可。 + 使用 IAM 政策來指定許可比使用許可層級更靈活。 + 您可以設定 [IAM 身分（使用者、使用者群組和角色）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)，將許可授予 IAM 身分，例如使用者和使用者群組，或定義可與聯合身分使用者相關聯的[角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。 + IAM 政策是授予特定金鑰 Stacks OpsWorks 動作許可的唯一方法。例如，您必須使用 IAM 授予 `opsworks:CreateStack`和的許可`opsworks:CloneStack`，這些許可分別用於建立和複製堆疊。雖然無法在主控台中明確匯入聯合身分使用者，但聯合身分使用者可以透過選擇 Stacks OpsWorks 主控台右上角的**我的設定**，然後選擇右上角的使用者，隱含地建立**使用者**設定檔。在**使用者**頁面上，聯合身分使用者 - 透過使用 API 或 CLI 建立帳戶，或隱含地透過主控台 - 可以像非聯合身分使用者一樣管理其帳戶。兩種方式並非互斥關係，有時候合併使用兩者也會非常有用。 OpsWorks Stacks 接著便會評估這兩組許可。例如，假設您希望允許使用者新增或刪除執行個體，但不希望其新增或刪除 layer。沒有任何 OpsWorks Stacks 許可層級會授予該特定許可集。不過，您可以使用**許可**頁面授予使用者**管理**許可層級，以允許他們執行大多數堆疊操作，然後套用拒絕新增或移除層許可的 IAM 政策。如需詳細資訊，請參閱[使用政策控制對資源的 AWS 存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)。以下是管理使用者許可的典型模型。在每個案例中，皆預設讀者 (即您) 具備管理員身分。 1. 使用 [IAM 主控台](https://console.aws.amazon.com/iam)將 AWSOpsWorks\$1FullAccess 政策套用至一或多個管理使用者。 1. 使用不授予 OpsWorks Stacks 許可的政策為每個非管理使用者建立使用者。如果使用者只需要存取 OpsWorks Stacks，您可能完全不需要套用政策。您可以改為使用 OpsWorks Stacks Permissions 頁面來管理其**許可**。 1. 使用 OpsWorks Stacks **使用者**頁面將非管理使用者匯入 OpsWorks Stacks。 1. 針對每個堆疊，使用堆疊的 **Permissions (許可)** 頁面，將許可層級指派給每個使用者。 1. 視需要套用適當設定的 IAM 政策，以自訂使用者的許可層級。如需管理使用者的詳細建議，請參閱 [最佳實務：管理許可](best-practices-permissions.md)。如需 IAM 最佳實務的詳細資訊，請參閱《[IAM 使用者指南》中的 IAM 中的安全最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。 ** **Topics** + [管理 OpsWorks Stacks 使用者](opsworks-security-users-manage.md) + [授予每個 OpsWorks 堆疊的 Stacks 使用者許可](opsworks-security-users-console.md) + [連接 OpsWorks IAM 政策來管理 Stacks 許可](opsworks-security-users-policy.md) + [範例政策](opsworks-security-users-examples.md) + [OpsWorks Stacks 許可層級](opsworks-security-users-standard.md) # 管理 OpsWorks Stacks 使用者 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您必須先為每個人建立使用者，才能將使用者匯入 OpsWorks Stacks 並授予許可。若要建立 IAM 使用者，請先以已授予 IAMFullAccess 政策中定義許可的使用者 AWS 身分登入。然後，您可以使用 IAM 主控台為需要存取 Stacks 的每個人[建立 IAM 使用者](opsworks-security-users-create-user.md)。 OpsWorks 然後，您可以將這些使用者匯入 Stacks OpsWorks ，並授予使用者許可，如下所示： **一般 OpsWorks Stacks 使用者** 一般使用者不需要連接政策。如果他們確實有，則通常不包含任何 OpsWorks Stacks 許可。反之，請使用 OpsWorks Stacks **許可**頁面，以stack-by-stack方式將下列其中一個許可層級指派給一般使用者。 + **Show (顯示)** 許可允許使用者檢視堆疊，但不允許其執行任何操作。 + **Deploy (部署)** 許可包含 **Show (顯示)** 許可，並且也會允許使用者部署及更新應用程式。 + **Manage (管理)** 許可包含 **Deploy (部署)** 許可，但也會允許使用者執行堆疊管理操作 (例如新增 layer 或執行個體、使用 **Permissions (許可)** 頁面設定使用者許可，以及啟用其自身的 SSH/RDP 和 sudo/admin 權限)。 + **Deny (拒絕)** 許可會拒絕存取堆疊。如果這些許可層級不如您想要的特定使用者，您可以透過套用 IAM 政策來自訂使用者的許可。例如，您可能想要使用 OpsWorks Stacks **許可**頁面將**管理**許可層級指派給使用者，這會授予他們執行所有堆疊管理操作的許可，但不會建立或複製堆疊。然後，您可以透過拒絕這些許可來套用限制這些許可的政策，以新增或刪除層，或透過允許它們建立或複製堆疊來增強這些許可。如需詳細資訊，請參閱[連接 OpsWorks IAM 政策來管理 Stacks 許可連接 IAM 政策](opsworks-security-users-policy.md)。 **OpsWorks Stacks 管理使用者** 管理使用者是帳戶擁有者或具有 [AWSOpsWorks\$1FullAccess 政策](opsworks-security-users-examples.md#opsworks-security-users-examples-admin)所定義許可的 IAM 使用者。除了授予給 **Manage (管理)** 使用者的許可之外，此政策還包含無法透過 **Permissions (許可)** 頁面授予的動作許可，例如以下項目： + 將使用者匯入 OpsWorks Stacks + 建立和複製堆疊如需取得完整的政策，請參閱[範例政策](opsworks-security-users-examples.md)。如需只能透過套用 IAM 政策授予使用者之許可的詳細清單，請參閱 [OpsWorks Stacks 許可層級許可層級](opsworks-security-users-standard.md)。 **Topics** + [使用者和區域](#UsersandRegions) + [建立 OpsWorks Stacks 管理使用者](opsworks-security-users-manage-admin.md) + [為 Stacks 建立 IAM OpsWorks 使用者](opsworks-security-users-create-user.md) + [將使用者匯入 OpsWorks Stacks](opsworks-security-users-manage-import.md) + [編輯 OpsWorks Stacks 使用者設定](opsworks-security-users-manage-edit.md) ## 使用者和區域 OpsWorks Stacks 使用者可在其建立所在的區域端點中使用。您可以在下列任何區域中建立使用者。 + 美國東部 (俄亥俄) 區域 + 美國東部 (維吉尼亞北部) 區域 + 美國西部 (奧勒岡) 區域 + 美國西部 (加利佛尼亞北部) 區域 + 加拿大（中部）區域（僅限 API；不適用於 AWS 管理主控台 + 亞太地區 (孟買) 區域 + 亞太區域 (新加坡) 區域 + 亞太 (雪梨) 區域 + 亞太 (東京) 區域 + 亞太區域 (首爾) 區域 + 歐洲 (法蘭克福) 區域 + 歐洲 (愛爾蘭) 區域 + 歐洲 (倫敦) 區域 + 歐洲 (巴黎) 區域 + 南美洲 (聖保羅) 區域當您將使用者匯入 Stacks OpsWorks 時，您可以將其匯入其中一個區域端點；如果您希望使用者可在多個區域中使用，則必須將使用者匯入該區域。您也可以將 OpsWorks Stacks 使用者從一個區域匯入另一個區域；如果您將使用者匯入已有相同名稱使用者的區域，則匯入的使用者會取代現有的使用者。如需匯入使用者的詳細資訊，請參閱[匯入使用者](opsworks-security-users-manage-import.md)。 # 建立 OpsWorks Stacks 管理使用者 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以透過將 `AWSOpsWorks_FullAccess`政策新增至使用者來建立 OpsWorks Stacks 管理使用者，以授予該使用者 OpsWorks Stacks 完整存取許可。如需建立管理使用者的詳細資訊，請參閱[建立管理使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-set-up.html#create-an-admin)。 **注意** AWSOpsWorks\$1FullAccess 政策允許使用者建立和管理 OpsWorks Stacks 堆疊，但使用者無法為堆疊建立 IAM 服務角色；他們必須使用現有的角色。建立堆疊的第一個使用者必須具有額外的 IAM 許可，如中所述[管理許可](opsworks-security-users-examples.md#opsworks-security-users-examples-admin)。當此使用者建立第一個堆疊時， OpsWorks Stacks 會建立具有所需許可的 IAM 服務角色。之後，任何具有 `opsworks:CreateStack` 許可的使用者皆能使用該角色建立額外的堆疊。如需詳細資訊，請參閱[允許 OpsWorks Stacks 代表您採取行動](opsworks-security-servicerole.md)。當您建立使用者時，您可以視需要新增額外的客戶受管政策來微調使用者的許可。例如，您可能希望管理使用者能夠建立或刪除堆疊，但無法匯入新的使用者。如需詳細資訊，請參閱[連接 OpsWorks IAM 政策來管理 Stacks 許可連接 IAM 政策](opsworks-security-users-policy.md)。如果您有多個管理使用者，而不是為每個使用者分別設定許可，您可以將 AWSOpsWorks\$1FullAccess 政策新增至 IAM 群組，並將使用者新增至該群組。如需建立群組的資訊，請參閱[建立 IAM 使用者群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html)。當您建立群組時，請新增 **AWSOpsWorks\$1FullAccess** 政策。您也可以新增 **AdministratorAccess** 政策，其中包含 **AWSOpsWorks\$1FullAccess** 許可。如需將許可新增至現有群組的詳細資訊，請參閱[將政策連接至 IAM 使用者群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_manage_attach-policy.html)。 # 為 Stacks 建立 IAM OpsWorks 使用者 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您需要先建立 IAM 使用者，才能將他們匯入 OpsWorks Stacks。您可以使用 [IAM 主控台](https://console.aws.amazon.com/iam/)、命令列或 API 來執行此操作。如需完整說明，請參閱[在 AWS 帳戶中建立 IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html)。請注意，與[管理使用者](opsworks-security-users-manage-admin.md)不同，您不需要連接政策以定義許可。您可以在[將使用者匯入 OpsWorks Stacks](opsworks-security-users-manage-import.md) 之後設定許可，如[管理使用者許可](opsworks-security-users.md)中所解釋。如需建立 IAM 使用者和群組的詳細資訊，請參閱 [IAM 入門](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html)。 # 將使用者匯入 OpsWorks Stacks **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。管理使用者可以將使用者匯入 OpsWorks Stacks；也可以將 OpsWorks Stacks 使用者從一個區域端點匯入另一個區域端點。當您將使用者匯入 Stacks OpsWorks 時，您可以將他們匯入其中一個 OpsWorks Stacks 區域端點。如果您希望使用者可在多個區域中使用，您必須將使用者匯入該區域。雖然無法明確地在主控台中匯入聯合身分使用者，但聯合身分使用者可以透過選擇 Stacks OpsWorks 主控台右上角的**我的設定**，然後選擇使用者，也可以在右上角隱含地建立**使用者**設定檔。在**使用者**頁面上，聯合身分使用者 - 透過使用 API 或 CLI 建立帳戶，或隱含地透過主控台 - 可以像非聯合身分使用者一樣管理其帳戶。 **將使用者匯入 OpsWorks Stacks** 1. 以管理使用者或帳戶擁有者身分登入 OpsWorks Stacks。 1. 選擇位於右上方的 **Users (使用者)** 以開啟 **Users (使用者)** 頁面。 ![\[顯示 us-east-1 使用者的 Users (使用者) 頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions_users_page.png) 1. 選擇**將 IAM 使用者匯入 <*region name*>**，以顯示可用但尚未匯入的使用者。 ![\[Users (使用者) 頁面上的 Import (匯入) 命令\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions_import.png) 1. 填滿 **Select all (選取全部)** 核取方塊，或是選取一或多個個別使用者。當您完成時，請選擇 **Import to OpsWorks (匯入 OpsWorks)**。 **注意** 將使用者匯入 OpsWorks Stacks 之後，如果您使用 IAM 主控台或 API 從您的帳戶中刪除使用者，使用者不會自動失去您透過 OpsWorks Stacks 授予的 SSH 存取權。您也必須從 OpsWorks Stacks 刪除使用者，方法是開啟**使用者**頁面，然後在使用者**的動作**欄中選擇**刪除**。 **將 OpsWorks Stacks 使用者從一個區域匯入到另一個區域** OpsWorks Stacks 使用者可在其建立所在的區域端點中使用。您可以在中顯示的區域中建立使用者[使用者和區域](opsworks-security-users-manage.md#UsersandRegions)。您可以將 OpsWorks Stacks 使用者從一個區域匯入目前篩選**使用者**清單的區域。如果您將使用者匯入已有相同名稱使用者的區域，則匯入的使用者會取代現有的使用者。 1. 以管理使用者或帳戶擁有者身分登入 OpsWorks Stacks。 1. 選擇位於右上方的 **Users (使用者)** 以開啟 **Users (使用者)** 頁面。如果您在多個區域中有 OpsWorks Stacks 使用者，請使用**篩選條件**控制項來篩選您要匯入使用者的區域。 ![\[顯示 us-east-1 使用者的 Users (使用者) 頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions_users_page.png) 1. 選擇將 **Stacks OpsWorks 使用者從另一個區域匯入至 <*目前區域*>**。 ![\[顯示 us-west-2 使用者的 Users (使用者) 頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions_import_otherregion.png) 1. 選取您要從中匯入 Stacks OpsWorks 使用者的區域。 1. 選取要匯入的一或多個使用者，或是選取所有使用者，然後選擇 **Import to this region (匯入此區域)**。等待 OpsWorks Stacks 在使用者清單中顯示匯入**的使用者**。 ## Unix 外部堆疊建立IDs OpsWorks 和使用者 OpsWorks 會在 OpsWorks 2000 到 4000 之間指派 Stacks 執行個體上的使用者 Unix ID (UID) 值。由於 OpsWorks 會保留 2000-4000 範圍的 UIDs，因此您在之外建立的使用者 OpsWorks （例如使用技術指南配方，或從 IAM OpsWorks 將使用者匯入 ) 可以擁有由 OpsWorks Stacks 為其他使用者覆寫的 UIDs。這可能會導致您在 OpsWorks Stacks 外部建立的使用者未出現在資料包搜尋結果中，或被排除在 OpsWorks Stacks 內建`sync_remote_users`操作之外。外部程序也可以使用 Stacks 可以覆寫UIDs OpsWorks 建立使用者。舉例來說，有些作業系統套件可能會建立使用者，做為後安裝程序的一部分。當您或軟體程序在 Linux 作業系統上建立使用者時，而不明確指定 UID，這是預設值，Stacks OpsWorks 指派的 UID 是 *<最高現有 OpsWorks UID>* \$1 1。最佳實務是在 OpsWorks Stacks 主控台中 AWS CLI或使用 AWS SDK 建立 OpsWorks Stacks 使用者並管理其存取權。如果您在外部的 OpsWorks Stacks 執行個體上建立使用者 OpsWorks，請使用大於 4000 的 *UnixID* 值。 # 編輯 OpsWorks Stacks 使用者設定 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在您匯入使用者之後，您可以編輯其設定，如下所示： **編輯使用者設定** 1. 在 **Users (使用者)** 頁面上，在使用者的 **Actions (動作)** 資料行中選擇 **edit (編輯)**。 1. 您可以指定下列設定。 **自我管理** 選取 **Yes (是)** 以允許使用者使用 MySettings 頁面指定自身的 SSH 金鑰。您也可以將 IAM 政策新增至授予 [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html) 和 [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html) 動作許可的 IAM 身分，以啟用自我管理。 **公有 SSH 金鑰** (選用) 輸入使用者的公有 SSH 金鑰。此金鑰會顯示在使用者的 **My Settings (我的設定)** 頁面上。若您啟用自我管理，使用者可編輯 **My Settings (我的設定)** 並指定其自身的金鑰。如需詳細資訊，請參閱[註冊使用者的公有 SSH 金鑰](security-settingsshkey.md)。 OpsWorks Stacks 會在所有 Linux 執行個體上安裝此金鑰；使用者可以使用相關聯的私有金鑰來登入。如需詳細資訊，請參閱[使用 SSH 登入](workinginstances-ssh.md)。您無法搭配 Windows 堆疊使用此金鑰。 **許可** (選擇性) 在同一處設定使用者每個堆疊的許可層級，而非透過使用每個堆疊的 **Permissions (許可)** 頁面分別設定他們。如需許可層級的詳細資訊，請參閱[授予每個堆疊的許可](opsworks-security-users-console.md)。 ![\[User details page showing name, ARN, SSH settings, and permission levels for various stacks.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions_edit_user.png) # 授予每個 OpsWorks 堆疊的 Stacks 使用者許可 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。管理 OpsWorks Stacks 使用者許可的最簡單方法是使用堆疊的**許可**頁面。每個堆疊都有自己的頁面，可授予該堆疊的許可。您必須以管理使用者身分或 **Manage (管理)** 使用者登入，才能修改任何許可設定。此清單只會顯示已匯入 Stacks OpsWorks 的使用者。如需如何建立和匯入使用者的資訊，請參閱[管理使用者](opsworks-security-users-manage.md)。預設許可層級是僅限 IAM 政策，只會授予使用者在其 IAM 政策中的那些許可。 + 當您從 IAM 或其他區域匯入使用者時，系統會將使用者新增至具有 **IAM 僅政策**許可層級之所有現有堆疊的清單。 + 根據預設，您剛從另一個區域匯入的使用者無法存取目的地區域中的堆疊。如果您從另一個區域匯入使用者，若要讓他們管理目的地區域中的堆疊，則必須在匯入使用者之後將許可指派給這些堆疊。 + 當您建立新的堆疊時，所有目前的使用者都會新增至清單，並帶有 **IAM Policies Only (僅限 IAM 政策)** 許可層級。 **Topics** + [設定使用者的許可](#opsworks-security-users-console-set) + [檢視您的許可](#opsworks-security-users-console-viewing) + [使用 IAM 條件金鑰驗證暫時登入資料](#w2ab1c14c67c15c37c21) ## 設定使用者的許可 **設定使用者的許可** 1. 在導覽窗格中，選擇 **Permissions (許可)**。 1. 在 **Permissions (許可)** 頁面上，選擇 **Edit (編輯)**。 1. 變更 **Permission level (許可層級)** 和 **Instance access (執行個體存取)** 設定。 + 使用 **Permissions level (許可層級)** 設定指派其中一個標準許可層級給每個使用者。該許可層級會判斷使用者是否可以存取堆疊，以及使用者可執行的動作為何。如果使用者具有 IAM 政策， OpsWorks Stacks 會評估兩組許可。如需範例，請參閱[範例政策](opsworks-security-users-examples.md)。 + **Instance access (執行個體存取)** **SSH/RDP** 設定會指定使用者是否具有堆疊執行個體的 SSH (Linux) 或 RDP (Windows) 存取。若您授權 **SSH/RDP** 存取，您可以選擇性的選取 **sudo/admin**，授予使用者堆疊執行個體上的 sudo (Linux) 或管理 (Windows) 權限。 ![\[使用許可頁面管理使用者。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions-edit.png) 您可以將每個使用者指派給下列其中一個許可層級。如需每個層級允許動作的清單，請參閱[OpsWorks Stacks 許可層級許可層級](opsworks-security-users-standard.md)。 **拒絕** 使用者無法在堆疊上執行任何 OpsWorks Stacks 動作，即使他們具有授予 Stacks 完整存取許可的 IAM OpsWorks 政策。舉例來說，您可能會使用此層級來拒絕某些使用者存取未發行產品的堆疊。 **僅限 IAM 政策** 預設層級，這是指派給所有新匯入使用者，以及新建立堆疊中所有使用者的層級。使用者的許可取決於其 IAM 政策。如果使用者沒有 IAM 政策，或其政策沒有明確的 OpsWorks Stacks 許可，則無法存取堆疊。管理使用者通常會獲指派此層級，因為其 IAM 政策已授予完整存取許可。 **Show (顯示)** 使用者可檢視堆疊，但無法執行任何操作。例如，管理人員可能希望監控帳戶的堆疊，但不需要部署應用程式或以任何方式修改堆疊。 **部署** 包含 **Show (顯示)** 許可，同時也會允許使用者部署應用程式。例如，應用程式開發人員可能需要將更新部署到堆疊的執行個體，但不需要將 layer 或執行個體新增至堆疊。 **Manage (管理)** 包含 **Deploy (部署)** 許可，但同時也會允許使用者執行各種堆疊管理操作，包含： + 新增或刪除 layer 和執行個體。 + 使用堆疊的 **Permissions (許可)** 頁面將許可層級指派給使用者。 + 註冊或取消註冊資源。例如，每個堆疊可以有一名指定管理人員，負責確認堆疊具有適當數目及類型的執行個體、處理套件和作業系統更新等。管理層級無法讓使用者建立或複製堆疊。這些許可必須由 IAM 政策授予。如需範例，請參閱 [管理許可](opsworks-security-users-examples.md#opsworks-security-users-examples-manage)。如果使用者也有 IAM 政策， OpsWorks Stacks 會評估兩組許可。這可讓您將許可層級指派給使用者，然後套用政策來限制或增強層級的允許動作。例如，您可以套用允許**管理**使用者建立或複製堆疊的政策，或拒絕該使用者註冊或取消註冊資源的能力。如需這類政策的一些範例，請參閱[範例政策](opsworks-security-users-examples.md)。 **注意** 若使用者的政策允許額外的動作，其結果可能會覆寫 **Permissions (許可)** 頁面設定。例如，如果使用者的政策允許 [CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html) 動作，但您使用**許可**頁面指定**部署**許可，則使用者仍然可以建立層。此規則的例外是**拒絕**選項，即使具有 AWSOpsWorks\$1FullAccess 政策的使用者也拒絕堆疊存取。如需詳細資訊，請參閱[使用政策控制對 AWS 資源的存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)。 ## 檢視您的許可若已啟用 [self-management](opsworks-security-users-manage-edit.md)，使用者可透過選擇位於右上角的 **My Settings (我的設定)**，來檢視其在每個堆疊上的許可層級。**** 如果使用者的政策授予 [DescribeMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeMyUserProfile.html) 和 [UpdateMyUserProfile](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateMyUserProfile.html) 動作的許可，使用者也可以存取 My Settings。 ## 使用 IAM 條件金鑰驗證暫時登入資料 OpsWorks Stacks 具有內建的授權層，可支援其他授權案例（例如簡化管理個別使用者的唯讀或讀寫堆疊存取）。此授權 layer 依存於使用暫時登入資料。因此，您無法使用 `aws:TokenIssueTime`條件來驗證使用者是否使用長期登入資料，或封鎖使用臨時登入資料之使用者的動作，如 [IAM 文件中的 IAM JSON 政策元素參考](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_Null)所述。 # 連接 OpsWorks IAM 政策來管理 Stacks 許可 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以連接 IAM OpsWorks 政策來指定使用者的 Stacks 許可。連接的政策為某些許可的必要項目： + 管理使用者許可 (例如匯入使用者)。 + 某些動作的許可 (例如建立或複製堆疊)。如需需要已連接政策的完整動作清單，請參閱[OpsWorks Stacks 許可層級許可層級](opsworks-security-users-standard.md)。您也可以使用政策來自訂透過許可頁面授予**的許可**層級。本節提供如何將 IAM 政策套用至使用者以指定 Stacks OpsWorks 許可的簡短摘要。如需詳細資訊，請參閱 [AWS 資源的存取管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)。 IAM 政策是包含一或多個*陳述*式的 JSON 物件。每個陳述式元素皆有一個許可清單，其具備自身三個基本元素： **Action** 許可影響的動作。您可以將 OpsWorks Stacks 動作指定為 `opsworks:action`。`Action` 可設為特定動作，例如 `opsworks:CreateStack`，這會指定是否允許使用者呼叫 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateStack.html)。您也可以使用萬用字元指定動作群組。例如，`opsworks:Create*` 會指定所有建立動作。如需 Stacks OpsWorks 動作的完整清單，請參閱 [OpsWorks Stacks API 參考](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)。 **效果** 允許或拒絕指定動作。 **Resource** 許可影響 AWS 的資源。 OpsWorks 堆疊有一個資源類型，即堆疊。若要指定特定堆疊資源的許可，請將 `Resource` 設為堆疊的 ARN，其格式如下：`arn:aws:opsworks:region:account_id:stack/stack_id/`。您也可以使用萬用字元。例如，將 `Resource` 設為 `*` 會授予每個資源的許可。例如，下列政策會拒絕使用者停止 ID 為 `2860-2f18b4cb-4de5-4429-a149-ff7da9f0d8ee` 之堆疊上的執行個體。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "opsworks:StopInstance", "Effect": "Deny", "Resource": "arn:aws:opsworks:*:*:stack/2f18b4cb-4de5-4429-a149-ff7da9f0d8ee/" } ] } ``` ------ 如需將許可新增至 IAM 使用者的詳細資訊，請參閱 [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)。如需如何建立或修改 IAM 政策的詳細資訊，請參閱 [IAM 中的政策和許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。如需 Stacks OpsWorks 政策的一些範例，請參閱 [範例政策](opsworks-security-users-examples.md)。 # 範例政策 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節說明可套用至 Stacks 使用者的範例 IAM OpsWorks 政策。 + [管理許可](#opsworks-security-users-examples-admin) 描述用來將許可授予管理使用者的政策。 + [管理許可](#opsworks-security-users-examples-manage) 和 [部署許可](#opsworks-security-users-examples-deploy)顯示可套用至使用者以增強或限制管理和部署許可層級的政策範例。 OpsWorks Stacks 透過評估 IAM 政策授予的許可以及許可頁面授予**的**許可，來決定使用者的許可。如需詳細資訊，請參閱[使用政策控制對 AWS 資源的存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)。如需 **Permissions (許可)** 頁面許可的詳細資訊，請參閱[OpsWorks Stacks 許可層級許可層級](opsworks-security-users-standard.md)。 ## 管理許可使用 IAM 主控台 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)：// AWSOpsWorks\$1FullAccess 政策，將此政策連接至使用者，以授予他們執行所有 Stacks OpsWorks 動作的許可。需要 IAM 許可，才能允許管理使用者匯入使用者。您必須建立 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)，允許 OpsWorks Stacks 代表您存取其他 AWS 資源，例如 Amazon EC2 執行個體。您通常會讓管理使用者建立第一個堆疊，並讓 OpsWorks Stacks 為您建立角色，以處理此任務。您接著可以使用針對所有後續的堆疊使用該角色。如需詳細資訊，請參閱[允許 OpsWorks Stacks 代表您採取行動](opsworks-security-servicerole.md)。建立第一個堆疊的管理使用者必須具有 AWSOpsWorks\$1FullAccess 政策中未包含的一些 IAM 動作的許可。將下列許可新增至政策的 `Actions`區段。若要取得適當的 JSON 語法，請務必在動作之間新增逗號，並移除動作清單結尾的結尾逗號。 ``` "iam:PutRolePolicy", "iam:AddRoleToInstanceProfile", "iam:CreateInstanceProfile", "iam:CreateRole" ``` ## 管理許可 **Manage (管理)** 許可 layer 級允許使用者執行各種堆疊管理動作，包含新增或刪除 layer。本主題說明數個政策，可用來**管理**使用者以增強或限制標準許可。拒絕 **Manage (管理)** 使用者新增或刪除 layer。您可以限制**管理**許可層級，以允許使用者執行所有**管理**動作，但使用下列 IAM 政策新增或刪除層除外。將 *region*、*account\$1id* 和 *stack\$1id* 取代為您的組態適用的值。允許 **Manage (管理)** 使用者建立或複製堆疊 **管理**許可層級不允許使用者建立或複製堆疊。您可以變更**管理**許可，以允許使用者套用下列 IAM 政策來建立或複製堆疊。將 *region* 和 *account\$1id* 取代為您的組態適用的值。拒絕 Manage (管理) 使用者註冊或取消註冊資源。 **管理**許可層級允許使用者向堆疊[註冊和取消註冊 Amazon EBS 和彈性 IP 地址資源](resources-reg.md)。您可以藉由套用下列政策，限制**管理**許可以允許使用者執行除註冊資源以外的所有**管理**動作。 **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "opsworks:RegisterVolume", "opsworks:RegisterElasticIp" ], "Resource": "*" } ] } ``` 允許 **Manage (管理)** 使用者匯入使用者 **管理**許可層級不允許使用者將使用者匯入 OpsWorks Stacks。您可以透過套用下列 IAM 政策來增強**管理**許可，以允許使用者匯入和刪除使用者。將 *region* 和 *account\$1id* 取代為您的組態適用的值。 ## 部署許可 **Deploy (部署)** 許可層級不允許使用者建議或刪除應用程式。您可以擴增**部署**許可，以允許使用者套用下列 IAM 政策來建立和刪除應用程式。將 *region*、*account\$1id* 和 *stack\$1id* 取代為您的組態適用的值。 # OpsWorks Stacks 許可層級 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節列出 OpsWorks Stacks 許可頁面上**顯示**、**部署****和管理****許可**層級所允許的動作。它還包含一個動作清單，您只能透過將 IAM 政策套用至使用者來授予許可。 **Show (顯示)** **Show (顯示)** 層級允許 `DescribeXYZ` 命令，除了以下例外： ``` DescribePermissions DescribeUserProfiles DescribeMyUserProfile DescribeStackProvisioningParameters ``` 若管理使用者已啟用使用者的自我管理，**Show (顯示)** 使用者也可以使用 `DescribeMyUserProfile` 和 `UpdateMyUserProfile`。如需自我管理的詳細資訊，請參閱[編輯使用者設定](opsworks-security-users-manage-edit.md)。 **部署** 除了 **Show (顯示)** 層級允許的動作之外，**Deploy (部署)** 層級還允許以下動作。 ``` CreateDeployment UpdateApp ``` **Manage (管理)** 除了 **Deploy (部署)** 和 **Show (顯示)** 層級允許的動作之外，**Manage (管理)** 層級還允許以下動作。 ``` AssignInstance AssignVolume AssociateElasticIp AttachElasticLoadBalancer CreateApp CreateInstance CreateLayer DeleteApp DeleteInstance DeleteLayer DeleteStack DeregisterElasticIp DeregisterInstance DeregisterRdsDbInstance DeregisterVolume DescribePermissions DetachElasticLoadBalancer DisassociateElasticIp GrantAccess GetHostnameSuggestion RebootInstance RegisterElasticIp RegisterInstance RegisterRdsDbInstance RegisterVolume SetLoadBasedAutoScaling SetPermission SetTimeBasedAutoScaling StartInstance StartStack StopInstance StopStack UnassignVolume UpdateElasticIp UpdateInstance UpdateLayer UpdateRdsDbInstance UpdateStack UpdateVolume ``` **需要 IAM 政策的許可** 您必須將適當的 IAM 政策套用至使用者，以授予下列動作的許可。如需一些範例，請參閱[範例政策](opsworks-security-users-examples.md)。 ``` CloneStack CreateStack CreateUserProfile DeleteUserProfile DescribeUserProfiles UpdateUserProfile ``` # 允許 OpsWorks Stacks 代表您採取行動 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 需要代表您與各種 AWS 服務互動。例如， OpsWorks Stacks 會與 Amazon EC2 互動以建立執行個體，並與 Amazon CloudWatch 互動以取得監控統計資料。當您建立堆疊時，您可以指定 IAM 角色，通常稱為服務角色，以授予 OpsWorks Stacks 適當的許可。 ![\[新增堆疊頁面中的 IAM 角色清單。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add-stack-iamrole.png) 當您指定新堆疊的服務角色時，您可以執行下列其中一項作業： + 指定您先前建立的標準服務角色。您通常可以在建立您第一個堆疊時建立一個標準服務角色，然後針對所有後續的堆疊使用該角色。 + 指定您使用 IAM 主控台或 API 建立的自訂服務角色。如果您想要授予 OpsWorks Stacks 比標準服務角色更多的有限許可，此方法非常有用。 **注意** 若要建立您的第一個堆疊，您必須在 IAM **AdministratorAccess** 政策範本中定義許可。這些許可會允許 OpsWorks Stacks 建立新的 IAM 服務角色，允許您匯入使用者，[如先前所述](opsworks-security-users-manage-import.md)。針對所有後續堆疊，使用者可選取為第一個堆疊建立的服務角色。他們不需要完整的管理許可也能建立堆疊。標準服務角色會授予下列許可： + 執行所有 Amazon EC2 動作 (`ec2:*`)。 + 取得 CloudWatch 統計資料 (`cloudwatch:GetMetricStatistics`)。 + 使用 Elastic Load Balancing 將流量分配到伺服器 (`elasticloadbalancing:*`)。 + 使用 Amazon RDS 執行個體做為資料庫伺服器 (`rds:*`)。 + 使用 IAM 角色 (`iam:PassRole`) 在 OpsWorks Stacks 和 Amazon EC2 執行個體之間提供安全通訊。如果您建立自訂服務角色，您必須確保它授予 Stacks OpsWorks 管理堆疊所需的所有許可。下列 JSON 範本是標準服務角色的政策聲明；自訂服務角色應該在其政策聲明中至少包含以下許可。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:*", "iam:PassRole", "cloudwatch:GetMetricStatistics", "cloudwatch:DescribeAlarms", "ecs:*", "elasticloadbalancing:*", "rds:*" ], "Effect": "Allow", "Resource": [ "*" ], "Condition": { "StringEquals": { "iam:PassedToService": "ec2.amazonaws.com" } } } ] } ``` ------ 服務角色也具有信任關聯。Stacks OpsWorks 建立的服務角色具有下列信任關係。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "StsAssumeRole", "Effect": "Allow", "Principal": { "Service": "opsworks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ 服務角色必須具有此信任關係， Stacks OpsWorks 才能代表您採取行動。若您使用預設服務角色，請不要修改信任關聯。如果您要建立自訂服務角色，請執行下列其中一項動作來指定信任關係： + 如果您在 [IAM 主控台](https://console.aws.amazon.com/iam/home#roles)中使用**建立角色**精靈，請在**選擇使用案例**中選擇 **Opsworks**。此角色具有適當的信任關係，但不會隱含連接任何政策。若要授予 OpsWorks Stacks 代表您執行動作的許可，請建立包含下列項目的客戶受管政策，並將其連接至新角色。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudwatch:DescribeAlarms", "cloudwatch:GetMetricStatistics", "ec2:*", "ecs:*", "elasticloadbalancing:*", "iam:GetRolePolicy", "iam:ListInstanceProfiles", "iam:ListRoles", "iam:ListUsers", "rds:*" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "ec2.amazonaws.com" } } } ] } ``` ------ + 如果您使用的是 CloudFormation 範本，您可以將類似下列內容新增至範本**的資源**區段。 ``` "Resources": { "OpsWorksServiceRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "opsworks.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] }, "Path": "/", "Policies": [ { "PolicyName": "opsworks-service", "PolicyDocument": { ... } ] } }, } } ``` # Stacks OpsWorks 中的跨服務混淆代理人預防 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。混淆代理人問題屬於安全性議題，其中沒有執行動作許可的實體可以強制具有更多許可的實體執行該動作。在中 AWS，跨服務模擬可能會導致混淆代理人問題。在某個服務 (*呼叫服務*) 呼叫另一個服務 (*被呼叫服務*) 時，可能會發生跨服務模擬。可以操縱呼叫服務來使用其許可，以其不應有存取許可的方式對其他客戶的資源採取動作。為了預防這種情況， AWS 提供的工具可協助您保護所有服務的資料，而這些服務主體已獲得您帳戶中資源的存取權。我們建議在堆疊存取政策中使用 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)和 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)全域條件內容金鑰，以限制 AWS OpsWorks Stacks 為堆疊提供其他服務的許可。如果 `aws:SourceArn` 值不包含帳戶 ID (例如 Amazon S3 儲存貯體 ARN)，您必須使用這兩個全域條件內容金鑰來限制許可。如果同時使用這兩個全域條件內容金鑰，且 `aws:SourceArn` 值包含帳戶 ID，則在相同政策陳述式中使用 `aws:SourceAccount` 值和 `aws:SourceArn` 值中的帳戶時，必須使用相同的帳戶 ID。`aws:SourceArn` 如果您希望只有一個堆疊與跨服務存取相關聯，請使用。`aws:SourceAccount` 如果您想要允許該帳戶中的任何堆疊與跨服務使用相關聯，請使用。的值`aws:SourceArn`必須是 OpsWorks 堆疊的 ARN。防範混淆代理人問題最有效的方法是使用`aws:SourceArn`全域條件內容索引鍵搭配 Stacks 堆疊的完整 ARN OpsWorks 。如果您不知道完整的 ARN，或者如果您指定多個堆疊 ARNs，請將`aws:SourceArn`全域內容條件金鑰與萬用字元 (`*`) 用於 ARN 的未知部分。例如 `arn:aws:servicename:*:123456789012:*`。下一節說明如何使用 Stacks 中的 OpsWorks `aws:SourceArn`和 `aws:SourceAccount`全域條件內容索引鍵來防止混淆代理人問題。 ## 防止 Stacks OpsWorks 中的混淆代理人入侵本節說明如何協助防止 Stacks 中的 OpsWorks 混淆代理人入侵，並包含您可以連接到您用來存取 OpsWorks Stacks 之 IAM 角色的許可政策範例。作為安全最佳實務，建議您將 `aws:SourceArn`和 `aws:SourceAccount`條件金鑰新增至 IAM 角色與其他服務的信任關係。信任關係可讓 OpsWorks Stacks 擔任角色，在建立或管理您的 Stacks OpsWorks 堆疊所需的其他服務中執行動作。 **編輯信任關係以新增 `aws:SourceArn` 和 `aws:SourceAccount`條件索引鍵** 1. 前往 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。 1. 在左側導覽窗格中，選擇 **Roles** (角色)。 1. 在**搜尋**方塊中，搜尋您用來存取 Stacks OpsWorks 的角色。 AWS 受管角色為 `aws-opsworks-service-role`。 1. 在角色的**摘要**頁面上，選擇**信任關係**索引標籤。 1. 在**信任關係**索引標籤上，選擇**編輯信任政策**。 1. 在**編輯信任政策**頁面上，將至少一個 `aws:SourceArn`或 `aws:SourceAccount`條件索引鍵新增至政策。使用 `aws:SourceArn` 將跨服務（例如 Amazon EC2) 和 OpsWorks Stacks 之間的信任關係限制為更嚴格的特定 OpsWorks Stacks 堆疊。新增 `aws:SourceAccount` 以將跨服務與 Stacks OpsWorks 之間的信任關係限制為特定帳戶中的堆疊，這是較不嚴格的。下列是範例。請注意，如果您使用兩個條件索引鍵，帳戶 IDs 必須相同。 1. 完成新增條件索引鍵後，請選擇**更新政策**。以下是使用 `aws:SourceArn`和限制對堆疊存取的其他角色範例`aws:SourceAccount`。 **Topics** + [範例：存取特定區域中的堆疊](#confused-deputy-opsworks-stacks-example1) + [範例：將多個堆疊 ARN 新增至 `aws:SourceArn`](#confused-deputy-opsworks-stacks-example2) ### 範例：存取特定區域中的堆疊下列角色信任關係陳述式會存取美國東部（俄亥俄）區域 () 中的任何 OpsWorks Stacks 堆疊`us-east-2`。請注意，區域是在 ARN 值中指定`aws:SourceArn`，但堆疊 ID 值是萬用字元 (\$1)。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "opsworks.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws:opsworks:us-east-2:123456789012:stack/*" } } } ] } ``` ------ ### 範例：將多個堆疊 ARN 新增至 `aws:SourceArn` 下列範例限制存取帳戶 ID 123456789012 中兩個 OpsWorks Stacks 堆疊的陣列。 # 指定在 EC2 執行個體上執行之應用程式的許可 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果在堆疊的 Amazon EC2 執行個體上執行的應用程式需要存取其他 AWS 資源，例如 Amazon S3 儲存貯體，則必須具有適當的許可。若要授予那些許可，您可以使用執行個體描述檔。您可以在[建立 Stacks OpsWorks 堆疊](workingstacks-creating.md)時為每個執行個體指定執行個體描述檔。 ![\[Add Stack (新增堆疊) 頁面中的 Advanced (進階) 選項。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add-stack-instanceproflie.png) 您也可以透過[編輯 layer 組態](workinglayers-basics-edit.md)，來指定 layer 執行個體的描述檔。執行個體描述檔指定 IAM 角色。在執行個體上執行的應用程式可取得該角色來存取 AWS 資源，並受角色政策授予的許可約束。如需應用程式取得角色之方式的詳細資訊，請參閱[使用 API 呼叫取得角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-assume-role.html)。您可以透過下列任何一種方式建立執行個體描述檔： + 使用 IAM 主控台或 API 來建立設定檔。如需詳細資訊，請參閱[角色 (委派及聯合)](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html)。 + 使用 CloudFormation 範本建立設定檔。如需如何在範本中包含 IAM 資源的一些範例，請參閱 [Identity and Access Management (IAM) 範本程式碼片段](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html)。執行個體描述檔必須具備信任關聯及授予存取 AWS 資源許可的連接政策。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ 執行個體描述檔必須具有此信任關係， Stacks OpsWorks 才能代表您採取行動。若您使用預設服務角色，請不要修改信任關聯。若您建立自訂服務角色，請指定信任關聯如下： + 若您使用 **IAM 主控台**中的 [Create Role (建立角色)](https://console.aws.amazon.com/iam/home#roles) 精靈，請在精靈第二頁的 **AWS Service Roles (AWS 服務角色)** 下方輸入 **Amazon EC2** 角色。 + 如果您使用的是 CloudFormation 範本，您可以將類似下列內容新增至範本**的資源**區段。 ``` "Resources": { "OpsWorksEC2Role": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ec2.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] }, "Path": "/" } }, "RootInstanceProfile": { "Type": "AWS::IAM::InstanceProfile", "Properties": { "Path": "/", "Roles": [ { "Ref": "OpsWorksEC2Role" } ] } } } ``` 建立執行個體描述檔時，您可以將適當的政策連接到該描述檔當時的角色。建立堆疊之後，您必須使用 [IAM 主控台](https://console.aws.amazon.com/iam/)或 API 將適當的政策連接到設定檔的角色。例如，下列政策會授予 Amazon S3 儲存貯體中名為 amzn-s3-demo-bucket 的所有物件的完整存取權。將 *region* 和 amzn-s3-demo-bucket 取代為您的組態適用的值。如需如何建立和使用執行個體描述檔的範例，請參閱[使用 Amazon S3 儲存貯體](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted.walkthrough.photoapp.html)。如果您的應用程式使用執行個體描述檔從 EC2 執行個體呼叫 OpsWorks Stacks API，則除了 Stacks 和其他 AWS OpsWorks 服務的適當`iam:PassRole`動作之外，政策還必須允許動作。`iam:PassRole` 許可允許 OpsWorks Stacks 代您取得服務角色。如需 OpsWorks Stacks API 的詳細資訊，請參閱 [AWS OpsWorks API 參考](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)。以下是 IAM 政策的範例，可讓您從 EC2 執行個體呼叫任何 OpsWorks Stacks 動作，以及任何 Amazon EC2 或 Amazon S3 動作。 **注意** 如果您不允許 `iam:PassRole`，任何呼叫 OpsWorks Stacks 動作的嘗試都會失敗，並出現如下錯誤： ``` User: arn:aws:sts::123456789012:federated-user/Bob is not authorized to perform: iam:PassRole on resource: arn:aws:sts::123456789012:role/OpsWorksStackIamRole ``` 如需針對許可在 EC2 執行個體上使用角色的詳細資訊，請參閱《[ 使用者指南》](https://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html)*中的AWS Identity and Access Management 授予在 Amazon EC2 執行個體上執行的應用程式存取 AWS 資源*。 # 管理 SSH 存取 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 支援 Linux 和 Windows 堆疊的 SSH 金鑰。 + 若是 Linux 執行個體，您可以使用 SSH 登入執行個體以執行[代理程式 CLI](agent.md) 命令。如需詳細資訊，請參閱[使用 SSH 登入](workinginstances-ssh.md)。 + 若是 Windows 執行個體，您可以使用 SSH 金鑰取得該執行個體的管理員密碼，以用來登入 RDP。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。身分驗證是根據 SSH 金鑰對來進行；金鑰對中包含公有金鑰和私有金鑰： + 您會在執行個體上安裝公有金鑰。位置取決於特定的作業系統，但 OpsWorks Stacks 會為您處理詳細資訊。 + 您可將私有金鑰存放在本機，並將其提供給 SSH 用戶端 (例如 `ssh.exe`)，以存取執行個體。 SSH 用戶端會使用私有金鑰連線到該執行個體。若要將 SSH 存取權提供給堆疊的使用者，您需要一種可以建立 SSH 金鑰對、在堆疊的執行個體上安裝公有金鑰，以及安全地管理私有金鑰的方式。 Amazon EC2 提供在執行個體上安裝公有 SSH 金鑰的簡單方法。您可以使用 Amazon EC2 主控台或 API，為您計劃使用的每個 AWS 區域建立一或多個金鑰對。Amazon EC2 會將公有金鑰存放在 AWS 上，而您將私有金鑰存放在本機。當您啟動執行個體時，您可以指定其中一個區域的金鑰對，Amazon EC2 會自動將其安裝在執行個體上。然後，您即可使用對應的私有金鑰登入執行個體。如需詳細資訊，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。使用 OpsWorks Stacks，您可以在建立堆疊時指定其中一個區域的 Amazon EC2 金鑰對，並在建立每個執行個體時選擇性地使用不同的金鑰對覆寫它。當 OpsWorks Stacks 啟動對應的 Amazon EC2 執行個體時，它會指定金鑰對，Amazon EC2 會在執行個體上安裝公有金鑰。然後，您可以使用私有金鑰登入或擷取管理員密碼，就像使用標準 Amazon EC2 執行個體一樣。如需詳細資訊，請參閱[安裝 Amazon EC2 金鑰](security-settingec2key.md)。使用 Amazon EC2 金鑰對很方便，但有兩個重大限制： + Amazon EC2 金鑰對與特定 AWS 區域繫結。如果您在多個區域中工作，就必須管理多組金鑰對。 + 您只能在執行個體上安裝一個 Amazon EC2 金鑰對。如果您想要允許多位使用者登入，則所有使用者都必須具備私有金鑰的複本；這不是建議的安全做法。對於 Linux 堆疊， OpsWorks Stacks 提供更簡單且更靈活的方法來管理 SSH 金鑰對。 + 每位使用者可註冊個人金鑰對。它們會在本機存放私有金鑰，並向 Stacks OpsWorks 註冊公有金鑰，如中所述[註冊使用者的公有 SSH 金鑰](security-settingsshkey.md)。 + 在設定堆疊的許可時，您可以指定哪些使用者應具備堆疊執行個體的 SSH 存取權。 OpsWorks Stacks 會自動為每個授權使用者在堆疊的執行個體上建立系統使用者，並安裝其公有金鑰。使用者即可使用對應的私有金鑰登入，如[使用 SSH 登入](workinginstances-ssh.md)中所述。使用個人 SSH 金鑰有下列優勢。 + 您不需要手動設定執行個體上的金鑰； OpsWorks Stacks 會自動在每個執行個體上安裝適當的公有金鑰。 + OpsWorks Stacks 只會安裝授權使用者的個人公有金鑰。未經授權的使用者不能使用其個人私有金鑰來存取執行個體。使用 Amazon EC2 金鑰對，任何具有對應私有金鑰的使用者都可以登入，無論是否具有授權的 SSH 存取。 + 如果使用者不再需要 SSH 存取權，您可以使用 [**Permissions (許可)** 頁面](opsworks-security-users-manage-edit.md)，撤銷使用者的 SSH/RDP 許可。 OpsWorks Stacks 會立即從堆疊的執行個體解除安裝公有金鑰。 + 您可以為任何 AWS 區域使用相同的金鑰。使用者只需要管理一個私有金鑰。 + 您不需要共享私有金鑰。每位使用者都有自己的私有金鑰。 + 輪換金鑰非常簡單。您或使用者可以在 **My Settings (我的設定)** 中更新公有金鑰，而 OpsWorks Stacks 即會自動更新執行個體。 # 安裝 Amazon EC2 金鑰 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當您建立堆疊時，您可以指定預設安裝在堆疊中每個執行個體上的 Amazon EC2 SSH 金鑰。 ![\[新增堆疊頁面上的預設 SSH 金鑰清單\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/ec2_keys.png) **預設 SSH 金鑰**清單會顯示您 AWS 帳戶的 Amazon EC2keys。您可以執行下列任一作業： + 從清單中選取適當的金鑰。 + 若不指定任何金鑰，請選取 **Do not use a default SSH key (不使用預設 SSH 金鑰)**。如果您已選取 **Do not use a default SSH key (不使用預設 SSH 金鑰)**，或是您希望覆寫堆疊的預設金鑰，則可以在您建立執行個體時指定金鑰。 ![\[指定 SSH 金鑰\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/instance_keys.png) 當您啟動執行個體時， Stacks OpsWorks 會在 `authorized_keys` 檔案中安裝公有金鑰。 # 註冊使用者的公有 SSH 金鑰 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您有兩種方式可以註冊使用者的公有 SSH 金鑰： + 管理使用者可以將公有 SSH 金鑰指派給一或多位使用者，並提供對應的私有金鑰給他們。 + 管理使用者可以啟用一或多位使用者的自我管理。這些使用者可以指定自己的公有 SSH 金鑰。如需了解管理使用者如何啟用自行管理或將公有金鑰指派給使用者的詳細資訊，請參閱 [編輯使用者設定](opsworks-security-users-manage-edit.md)。若要在 PuTTY 終端機中使用 SSH 連線至 Linux 式執行個體，會需要額外的步驟。如需詳細資訊，請參閱 AWS 文件中的[使用 PuTTY 從 Windows 連線至您的 Linux 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)和[對您的執行個體連線進行故障診斷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html)。以下說明啟用自我管理的使用者如何指定其公有金鑰。 **指定您的 SSH 公有金鑰** 1. 建立 SSH 金鑰對。最簡單的方法是本機產生金鑰對。如需詳細資訊，請參閱[如何產生自己的金鑰並將它匯入 Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/generating-a-keypair.html#how-to-generate-your-own-key-and-import-it-to-aws)。 **注意** 如果您使用 PuTTYgen 產生金鑰對，請從公有金鑰複製**公有金鑰，以貼入 OpenSSH authorized\$1keys 檔案**方塊中。按一下 **Save Public Key (儲存公有金鑰)** 時，會將公有金鑰儲存為 MindTerm 不支援的格式。 1. 以啟用自我管理的 IAM 使用者身分登入 OpsWorks Stacks 主控台。 **重要** 如果您以帳戶擁有者或未啟用自我管理的 IAM 使用者身分登入， OpsWorks Stacks 不會顯示**我的設定**。如果您是管理使用者或帳戶擁有者，則可以前往 **Users (使用者)** 頁面，並[編輯使用者設定](opsworks-security-users-manage-edit.md)，來改為指定 SSH 金鑰。 1. 選取**我的設定**，顯示登入使用者的設定。 ![\[OpsWorks 儀表板中的 My Settings (我的設定) 連結。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/permissions-mysettings-link.png) 1. 在 **My Settings (我的設定)** 頁面中，按一下 **Edit (編輯)**。 ![\[My Settings (我的設定) 頁面中的 Edit (編輯) 按鈕。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/mysettings-editbutton.png) 1. 在 **Public SSH Key (公有 SSH 金鑰)** 方塊中，輸入您的 SSH 公有金鑰，然後按一下 **Save (儲存)**。 ![\[My Settings (我的設定) 頁面中的 Public SSH Key (公有 SSH 金鑰) 方塊。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/mysettings-setsshkey.png) **重要** 若要使用內建的 MindTerm SSH 用戶端連線至 Amazon EC2 執行個體，使用者必須以 IAM 使用者身分登入，並擁有向 Stacks 註冊的公有 SSH OpsWorks 金鑰。如需詳細資訊，請參閱[使用內建的 MindTerm SSH 用戶端](workinginstances-ssh-mindterm.md)。 # 管理 Linux 安全性更新 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 ## 安全性更新 Linux 作業系統供應商會提供定期更新；其中大部分都是作業系統安全性修補程式，但也可能包含已安裝套件的更新。您應該確保您的執行個體作業系統處於最新狀態，並含有最新的安全性修補程式。根據預設，當執行個體完成開機後， OpsWorks Stacks 會自動安裝最新的更新。當執行個體上線後， OpsWorks Stacks 不會自動安裝更新，以避免重新啟動應用程式伺服器等中斷。反之，您可以自行管理線上執行個體的更新，將任何中斷降至最低。我們建議您使用下列其中一個項目，來更新線上執行個體。 + 建立並啟動新的執行個體，以取代目前的線上執行個體。然後刪除目前的執行個體。新的執行個體會在設定期間安裝最新的一組安全性修補程式。 + 在 Chef 11.10 或較舊版本堆疊中的 Linux 類型執行個體上，執行[更新相依性堆疊命令](workingstacks-commands.md)，以在指定的執行個體上安裝最新一組安全性修補程式和其他更新。對於這兩種方法， OpsWorks Stacks 透過`yum update`執行 Amazon Linux 和 Red Hat Enterprise Linux (RHEL) 或 `apt-get update` Ubuntu 來執行更新。每個分佈處理更新的方式略有不同，因此您應該查看相關連結中的資訊，以確切了解更新會對您的執行個體造成哪些影響： + **Amazon Linux** – Amazon Linux 更新會安裝安全修補程式，也可能安裝功能更新，包括套件更新。如需詳細資訊，請參閱 [Amazon Linux AMI 常見問答集](https://aws.amazon.com/amazon-linux-ami/faqs/#lock)。 + **Ubuntu** – Ubuntu 更新主要僅限於安裝安全修補程式，但也可能針對有限數量的關鍵修正安裝套件更新。如需詳細資訊，請參閱 [LTS - Ubuntu Wiki](https://wiki.ubuntu.com/LTS)。 + **CentOS** – CentOS 更新通常會維持與舊版的二進位相容性。 + **RHEL** – RHEL 更新通常會維持與舊版的二進位相容性。如需詳細資訊，請參閱 [Red Hat Enterprise Linux Life Cycle](https://access.redhat.com/support/policy/updates/errata/)。如果您想要更多控制更新，例如指定特定套件版本，您可以使用 [CreateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateInstance.html)、[UpdateInstance](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateInstance.html)、[CreateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateLayer.html) 或 [UpdateLayer](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_UpdateLayer.html) 動作，或同等的 [AWS SDK](https://aws.amazon.com/tools/) 方法或 [AWS CLI](https://aws.amazon.com/documentation/cli/) 命令，將 `InstallUpdatesOnBoot` 參數設定為來停用自動更新`false`。下列範例說明如何使用 AWS CLI 來停用 `InstallUpdatesOnBoot`，以做為現有 layer 的預設設定。 ``` aws opsworks update-layer --layer-id layer ID --no-install-updates-on-boot ``` 接著，您必須自行管理更新。例如，您可以採用下列其中一個策略： + 實作自訂配方，其可[執行適當的 shell 命令](cookbooks-101-basics-commands.md#cookbooks-101-basics-commands-script)以安裝您慣用的更新。由於系統更新不會自然對應到[生命週期事件](workingcookbook-events.md)，因此請將配方納入您的自訂技術指南中，但[以手動方式執行](workingcookbook-manual.md)。針對套件更新，您也可以使用 [yum\$1package](https://docs.chef.io/chef/resources.html#yum-package) (Amazon Linux) 或 [apt\$1package](https://docs.chef.io/chef/resources.html#apt-package) (Ubuntu) 資源，而不是 shell 命令。 + [使用 SSH 登入每個執行個體](workinginstances-ssh.md)，並手動執行適當的命令。 # 使用安全群組 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 ## 安全群組 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。每個 Amazon EC2 執行個體都有一或多個關聯的安全群組來管理執行個體的網路流量，就像防火牆一樣。安全群組有一或多個「規則」**，每一個都會指定允許流量的特定類別。指定下列項目的規則： + 允許流量的類型，例如 SSH 或 HTTP + 此流量的通訊協定，例如 TCP 或 UDP + 流量來源的 IP 地址範圍 + 流量的允許連接埠範圍安全群組有兩種規則類型： + 傳入規則管理傳入的網路流量。例如，應用程式伺服器執行個體通常有一個傳入規則允許來自任何 IP 地址的 HTTP 流量傳入連接埠 80，另一個傳入規則允許來自指定 IP 地址集的 SSH 流量傳入連接埠 22。 + 傳出規則管理傳出的網路流量。常用實務是使用允許任何傳出流量的預設設定。如需安全群組的詳細資訊，請參閱 [Amazon EC2 安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)。第一次在區域中建立堆疊時， OpsWorks Stacks 會使用一組適當的規則，為每個 layer 建立內建的安全群組。所有的群組都有允許所有傳出流量的預設傳出規則。一般而言，傳入規則允許下列項目： + 從適當的 Stacks 層傳入 TCP、UDP OpsWorks 和 ICMP 流量 + 連接埠 22 上的傳入 TCP 流量 (SSH 登入) **警告** 預設的安全群組組態會向任何網路位置 (0.0.0.0/0) 開放 SSH (連接埠 22)。這可讓所有 IP 地址使用 SSH 存取您的執行個體。對於生產環境，您必須使用只允許特定 IP 地址或地址範圍之 SSH 存取的組態。在它們建立後立即更新預設的安全群組，或改用自訂的安全群組。 + 對於 Web 伺服器 layer，所有的傳入 TCP 以及 UDP 流量流向連接埠 80 (HTTP) 和 443 (HTTPS) **注意** 內建的 `AWS-OpsWorks-RDP-Server` 安全群組會指派給所有的 Windows 執行個體，以允許 RDP 存取。不過，根據預設，它沒有任何規則。如果您執行的是 Windows 堆疊，並想要使用 RDP 存取執行個體，您必須新增允許 RDP 存取的傳入規則。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。若要查看每個群組的詳細資訊，請前往 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/)，在導覽窗格中選取**安全群組**，然後選取適當的 layer 安全群組。例如，**AWS-OpsWorks-Default-Server** 是所有堆疊的預設內建安全群組，而 **AWS-OpsWorks-WebApp** 是 Chef 12 範例堆疊的預設內建安全群組。 **注意** 如果您不小心刪除 OpsWorks Stacks 安全群組，建議重新建立的方式是讓 OpsWorks Stacks 為您執行任務。只要在相同的 AWS 區域和 VPC 中建立新的堆疊，如果有的話， Stacks OpsWorks 就會自動重新建立所有內建安全群組，包括您刪除的安全群組。您接著可以刪除您不再需要使用的堆疊，安全群組仍會留下。如果您想要手動重新建立安全群組，它必須是和原始安全群組完全一致 (包含群組名稱大小寫) 的複本。此外，如果發生下列任何情況， OpsWorks Stacks 將嘗試重新建立所有內建安全群組：您可以在 Stacks OpsWorks 主控台中對堆疊的設定頁面進行任何變更。您啟動其中一個堆疊的執行個體。您建立新的堆疊。您可以使用以下任一種方法指定安全群組。您使用 **Use OpsWorks security groups (使用 OpsWorks 安全群組)** 設定在您建立堆疊時指定偏好。 + **是** （預設設定） – OpsWorks Stacks 會自動將適當的內建安全群組與每個 layer 建立關聯。您可以新增自訂安全群組與您偏好的設定，微調 layer 的內建安全群組。不過，當 Amazon EC2 評估多個安全群組時，會使用限制最少的規則，因此您無法使用此方法來指定比內建群組更嚴格的規則。 + **否** – OpsWorks Stacks 不會將內建安全群組與 layer 建立關聯。您必須建立適當的安全群組，並建立至少一個安全群組與您所建之每個 layer 的關聯。使用此方法指定比內建群組更嚴格的規則。請注意，只要您想要，您仍然可以手動建立內建安全群組與 layer 的關聯；只有需要自訂設定的 layer 才需要自訂的安全群組。 **重要** 如果您使用內建的安全群組，您即無法透過手動修改群組設定來建立更嚴格的規則。每次建立堆疊時， OpsWorks Stacks 都會覆寫內建安全群組的組態，因此您所做的任何變更都會在您下次建立堆疊時遺失。如果 layer 需要比內建安全群組更嚴格的安全群組設定，請將 **Use OpsWorks security groups (使用 OpsWorks 安全群組)** 設為 **No (否)**，並使用您偏好的設定建立自訂安全群組，然後在建立時將其指派給 layer。 # OpsWorks Chef 12 Linux 的 Stacks 支援 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節提供 OpsWorks Stacks for Chef 12 Linux 的簡短概觀。如需 Windows 上 Chef 12 的資訊，請參閱「[入門：Windows](gettingstarted-windows.md)」。如需 Linux 上舊版 Chef 的資訊，請參閱「[適用於 Linux 的 Chef 11.10 和較舊版本](chef-11-linux.md)」。 ## 概觀 OpsWorks Stacks 支援適用於 Linux 堆疊的 Chef 最新版本 Chef 12。如需詳細資訊，請參閱 [Learn Chef](https://docs.chef.io/)。 OpsWorks Stacks 持續支援適用於 Linux 堆疊的 Chef 11.10。不過，如果您是進階的 Chef 使用者，並希望享有廣泛的社群 cookbook (技術指南) 選擇或撰寫您自己的自訂 cookbook (技術指南)，建議您使用 Chef 12。Chef 12 堆疊與 Chef 11.10 和較舊版 Linux 堆疊相比有下列優點： + **兩個不同的 Chef 執行** - 在執行個體上執行命令時， Stacks OpsWorks 代理程式現在會執行兩個隔離的 Chef 執行：一個執行用於整合執行個體與其他 AWS 服務的任務，例如 AWS Identity and Access Management (IAM)，另一個執行用於您的自訂技術指南。第一個 Chef 執行會在執行個體上安裝 OpsWorks Stacks 代理程式，並執行系統任務，例如使用者設定和管理、磁碟區設定和組態、CloudWatch 指標的組態等。第二個執行則專門執行您在 [OpsWorks Stacks 生命週期事件](workingcookbook-events.md)方面的自訂配方。第二個執行可讓您使用自己的 Chef cookbook (技術指南) 或社群 cookbook (技術指南)。 + **解決命名空間衝突** - 在 Chef 12 以前的版本中， OpsWorks Stacks 會在共享環境中執行系統任務，以及執行內建和自訂配方。這會導致命名空間衝突，以及不清楚 Stacks OpsWorks 已執行哪些配方。您必須手動覆寫不需要的預設組態，這項任務耗時又容易出錯。在適用於 Linux 的 Chef 12 中， OpsWorks Stacks 不再支援 PHP、Node.js 或 Rails 等應用程式伺服器環境的內建 Chef 技術指南。透過消除內建配方， OpsWorks Stacks 消除了內建配方與自訂配方之間命名衝突的問題。 + 對 **Chef 社群技術指南的強大支援** – OpsWorks Stacks Chef 12 Linux 為 Chef 超級市場的社群技術指南提供更高的相容性和支援。您現在可以使用優於 Stacks OpsWorks 先前提供的內建技術指南的社群技術指南，這些技術指南旨在與最新的應用程式伺服器環境和架構搭配使用。您可以在適用於 Linux 的 Chef 12 上執行大部分 cookbook (技術指南)，而不需修改。如需詳細資訊，請前往 [Learn Chef](https://docs.chef.io/supermarket.html) 網站上的 [Chef Supermarket](https://docs.chef.io/)、[Chef Supermarket](https://supermarket.chef.io/) 網站，以及 [GitHub](https://github.com/chef-cookbooks) 上的 [Chef Cookbooks](https://github.com/) 儲存庫。 + **及時 Chef 12 更新** - OpsWorks Stacks 會在每次 Chef 發行後不久將其 Chef 環境更新為最新的 Chef 12 版本。使用 Chef 12，次要 Chef 更新和新的 OpsWorks Stacks 代理程式版本將會一致。這可讓您直接測試新的 Chef 版本，並讓您的 Chef 配方和應用程式利用最新的 Chef 功能。如需 Chef 12 以前之 Chef 支援版本的詳細資訊，請參閱「[適用於 Linux 的 Chef 11.10 和較舊版本](chef-11-linux.md)」。 ## 移至 Chef 12 Chef 12 Linux OpsWorks 的 Key Stacks 變更與舊版 Chef 11.10、11.4 和 0.9 的支援相比，如下所示： + 適用於 Linux 堆疊的 Chef 12 已不再提供或支援內建堆疊層。由於只會執行您的自訂配方，因此移除此支援可讓您全面了解執行個體的設定情況，並更輕鬆地撰寫及維護自訂 cookbook (技術指南)。例如，不再需要覆寫內建 Stacks OpsWorks 配方的屬性。移除內建 layer 也可讓 OpsWorks Stacks 更好地支援 Chef 社群開發和維護的技術指南，讓您可以充分利用這些技術指南。適用於 Linux 的 Chef 12 不再提供的內建堆疊層類型包括：[AWS Flow (Ruby)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-awsflow.html)、[Ganglia](https://docs.aws.amazon.com/opsworks/latest/userguide/layers-other-ganglia.html)、[HAProxy](https://docs.aws.amazon.com/opsworks/latest/userguide/layers-haproxy.html)、[Java 應用程式伺服器](https://docs.aws.amazon.com/opsworks/latest/userguide/layers-java.html)、[Memcached](https://docs.aws.amazon.com/opsworks/latest/userguide/layers-other-memcached.html)、[MySQL](https://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-db-mysql.html)、[Node.js 應用程式伺服器](https://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-node.html)、[PHP 應用程式伺服器](https://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-php.html)、[Rails 應用程式伺服器](https://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-rails.html)和[靜態 Web 伺服器](https://docs.aws.amazon.com/opsworks/latest/userguide/workinglayers-static.html)。 + 由於 OpsWorks Stacks 正在執行您提供的配方，因此不再需要執行自訂技術指南來覆寫內建的 OpsWorks Stacks 屬性。若要覆寫您自己或社群配方中的屬性，請遵循 Chef 12 文件內 [About Attributes](https://docs.chef.io/attributes.html) 中的說明和範例。 + OpsWorks Stacks 持續為 Chef 12 Linux 堆疊提供下列層的支援： + [自訂 Layer](workinglayers-custom.md) + [Amazon RDS 服務層](workinglayers-db-rds.md) + [ECS 叢集層](workinglayers-ecscluster.md) + Chef 12 Linux 的堆疊組態和資料包已變更，看起來與 Chef 12.2 Windows 的堆疊組態和資料包非常類似。這可讓您更輕鬆地查詢、分析這些資料包及排解其問題 (尤其如果您使用作業系統類型不同的堆疊)。請注意， OpsWorks Stacks 不支援加密的資料包。若要以加密形式存放機密資料 (例如密碼或憑證)，建議您將它存放在私有 S3 儲存貯體中。然後，您可以建立自訂配方，定義其使用[適用於 Ruby 的 Amazon 開發套件](https://aws.amazon.com/documentation/sdk-for-ruby/)擷取資料。如需範例，請參閱「[使用適用於 Ruby 的 SDK](cookbooks-101-opsworks-s3.md)」。如需詳細資訊，請參閱「[OpsWorks Stacks 資料包參考](data-bags.md)」。 + 在 Chef 12 Linux 中，Berkshelf 不會再安裝到堆疊執行個體。相反地，建議您在本機開發機器上使用 Berkshelf，以在本機封裝您的 cookbook (技術指南) 相依性。然後將包含相依性的套件上傳至 Amazon Simple Storage Service。最後，修改您的 Chef 12 Linux 堆疊，使其使用上傳的套件做為技術指南來源。如需詳細資訊，請參閱[本機封裝技術指南依存性](best-practices-packaging-cookbooks-locally.md)。 + 不再支援 EBS 磁碟區的 RAID 組態。為了提高效能，您可以使用 [Amazon Elastic Block Store (Amazon EBS) 的佈建 IOPS](https://aws.amazon.com/about-aws/whats-new/2012/07/31/announcing-provisioned-iops-for-amazon-ebs/)。 + 不再支援 autofs。 + 不再支援 Subversion 儲存庫。 + 各堆疊層的 OS 套件安裝現在必須透過自訂配方完成。如需詳細資訊，請參閱[個別 layer 套件安裝](per-layer-os-package-install.md)。 ## 支援的作業系統 Chef 12 支援與舊版 Chef 相同的 Linux 作業系統。如需 Chef 12 Linux 堆疊可以使用的 Linux 作業系統類型和版本清單，請參閱「[Linux 作業系統](workinginstances-os-linux.md)」。 ## 支援的執行個體類型 OpsWorks Stacks 支援 Chef 12 Linux 堆疊的所有執行個體類型，除了高效能運算 (HPC) 叢集運算、叢集 GPU 和高記憶體叢集執行個體類型等特殊執行個體類型。 ## 詳細資訊若要進一步了解如何使用適用於 Linux 堆疊的 Chef 12，請參閱下列各章： + [入門：範例](gettingstarted-intro.md) 透過引導您使用 OpsWorks Stacks 主控台進行簡短的實作練習來建立 Node.js 應用程式環境，來向您介紹 OpsWorks Stacks。 + [入門：Linux](gettingstarted-linux.md) 向您介紹 OpsWorks Stacks 和 Chef 12 Linux，方法是引導您使用 Stacks 主控台進行實作練習，以建立基本的 Chef 12 Linux OpsWorks 堆疊，其中包含使用 Node.js 應用程式提供流量的簡單層。 + [自訂 Layer](workinglayers-custom.md) 提供指導，用以將包含 cookbook (技術指南) 和配方的堆疊層新增至 Chef 12 Linux 堆疊。您可以使用 Chef 社群提供之現成可用的 cookbook (技術指南) 和配方，也可以自行建立。 + [移至資料包](attributes-to-data-bags.md) 比較及比對執行 Chef 11 以前 (含) 版本及 Chef 12 之 Linux 堆疊使用的執行個體 JSON。同時提供 Chef 12 執行個體 JSON 格式的參考文件指標。 # 將堆疊設定屬性移至資料包 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 會向 Chef 配方公開各種堆疊設定。這些堆疊設定包含的值如： + 堆疊技術指南來源 URL + Layer 磁碟區組態 + 執行個體主機名稱 + Elastic Load Balancing DNS 名稱 + 應用程式來源 URL + 使用者名稱與直接在配方中硬編碼堆疊設定相比，參考配方中的堆疊設定能讓配方程式碼更強大且較不容易出錯。本主題說明如何存取這些堆疊設定，以及如何將它們從適用於 Linux 之 Chef 11.10 和舊版的屬性中移至 Chef 12 Linux 的資料包。在適用於 Linux 的 Chef 11.10 和舊版中，堆疊設定可提供為 [Chef 屬性](https://docs.chef.io/attributes.html)，並可透過 Chef `node` 物件或透過 Chef 搜尋存取。這些屬性存放在 OpsWorks `/var/lib/aws/opsworks/chef`目錄中一組 JSON 檔案的 Stacks 執行個體上。如需詳細資訊，請參閱[堆疊組態及部署屬性：Linux](attributes-json-linux.md)。在 Chef 12 Linux 中，堆疊設定可提供為 [Chef 資料包](https://docs.chef.io/data_bags.html)，但只能透過 Chef 搜尋存取。資料包存放在 OpsWorks `/var/chef/runs/run-ID/data_bags`目錄中一組 JSON 檔案的 Stacks 執行個體上，其中 *run-ID* 是 OpsWorks Stacks 指派給執行個體上每個 Chef 執行的唯一 ID。堆疊設定不再提供為 Chef 屬性，因此堆疊設定再也不能透過 Chef `node` 物件存取。如需更多資訊，請參閱[OpsWorks Stacks 資料包參考](data-bags.md)。例如，在適用於 Linux 的 Chef 11.10 和舊版中，以下配方程式碼使用 Chef `node` 物件取得代表應用程式簡稱和來源 URL 的屬性。接著使用 Chef 日誌寫入這兩個屬性值： ``` Chef::Log.info ("********** The app's short name is '#{node['opsworks']['applications'].first['slug_name']}' **********") Chef::Log.info("********** The app's URL is '#{node['deploy']['simplephpapp']['scm']['repository']}' **********") ``` 在 Chef 12 Linux 中，以下配方程式碼使用 `aws_opsworks_app` 搜尋索引取得 `aws_opsworks_app` 資料包中第一個資料包項目的內容。然後，程式碼將兩個訊息寫入 Chef 日誌，一個有應用程式簡稱資料包內容，另一個有應用程式來源 URL 資料包內容： ``` app = search("aws_opsworks_app").first Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********") Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********") ``` 若要將您存取堆疊設定配方程式碼，從適用於 Linux 的 Chef 11.10 和舊版遷移至 Chef 12 Linux，您必須修改您的程式碼，以： + 存取 Chef 資料包，而非 Chef 屬性。 + 使用 Chef 搜尋，而非 Chef `node` 物件。 + 使用 OpsWorks Stacks 資料包名稱，例如 `aws_opsworks_app`，而不是使用 OpsWorks Stacks 屬性名稱，例如 `opsworks`和 `deploy`。如需更多資訊，請參閱[OpsWorks Stacks 資料包參考](data-bags.md)。 # 在 Stacks 中支援先前的 Chef OpsWorks 版本 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節提供先前 Chef 版本的 OpsWorks Stacks 文件的簡短概觀。 [適用於 Linux 的 Chef 11.10 和較舊版本](chef-11-linux.md) 提供適用於 Linux OpsWorks 堆疊之 Chef 11.10、11.4 和 0.9 的 Stacks 支援文件。 # 適用於 Linux 的 Chef 11.10 和較舊版本 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節提供 Chef OpsWorks 11.10、11.4 和 0.9 for Linux Stacks 文件的簡短概觀。 [Chef 11 Linux 堆疊入門](gettingstarted.md) 提供示範如何建立簡易但具有功能之 PHP 應用程式伺服器堆疊的演練。 [建立您的第一個 Node.js 堆疊](gettingstarted-node.md) 說明如何建立支援 Node.js 應用程式伺服器的 Linux 堆疊，以及如何部署簡易應用程式。 [自訂 OpsWorks Stacks](customizing.md) 說明如何自訂 OpsWorks Stacks 以符合您的特定需求。 [技術指南 101](cookbooks-101.md) 說明如何實作 Stacks OpsWorks 執行個體的配方。 [平衡 Layer 的負載](best-server-load-balancing.md) 說明如何使用可用的 OpsWorks Stacks 負載平衡選項。 [在 VPC 中執行堆疊](workingstacks-vpc.md) 描述如何在 virtual private cloud 中建立和執行堆疊。 [從 Chef Server 遷移](best-practices-server-migrate.md) 提供從 Chef Server 遷移至 Stacks OpsWorks 的指導方針。 [OpsWorks Stacks Layer 參考](layers.md) 描述可用的 OpsWorks Stacks 內建層。 [技術指南元件](workingcookbook-installingcustom-components.md) 說明下列三個標準技術指南元件：屬性、範本和配方。 [堆疊組態及部署屬性：Linux](attributes-json-linux.md) 說明適用於 Linux 的堆疊組態和部署屬性。 [內建技術指南屬性](attributes-recipes.md) 說明如何使用內建配方屬性控制已安裝軟體的組態。 [對適用於 Linux 的 Chef 11.10 和舊版故障診斷](troubleshooting-chef-11-linux.md) 描述疑難排解 Stacks OpsWorks 中各種問題的方法。 # Chef 11 Linux 堆疊入門 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本節說明如何開始搭配 Chef 11 使用 Linux 堆疊。如需 Chef 12 Linux 堆疊入門的資訊，請參閱[入門：Linux](gettingstarted-linux.md)。如需 Chef 12 Windows 堆疊入門的資訊，請參閱[入門：Windows](gettingstarted-windows.md)。雲端型應用程式通常需要一組必須共同建立和管理的相關資源，例如應用程式伺服器、資料庫伺服器等。此執行個體的集合稱為「堆疊」**。簡易的應用程式堆疊看起來可能如下。 ![\[Diagram showing users connecting to app servers via internet and load balancer, with a shared database.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch.png) 基本架構由下列項目組成： + 將來自使用者的傳入流量平均分散至應用程式伺服器的負載平衡器。 + 一組數量足以處理流量的應用程式伺服器執行個體。 + 提供應用程式伺服器後端資料存放區的資料庫伺服器。此外，您通常需要一種將應用程式分散至應用程式伺服器、監控堆疊等的方式。 OpsWorks Stacks 提供簡單且直接的方式來建立和管理堆疊及其相關聯的應用程式和資源。本章介紹 OpsWorks Stacks 的基本概念，以及一些更複雜的功能，引導您完成圖表中建立應用程式伺服器堆疊的程序。它使用 Stacks OpsWorks 易於遵循的增量開發模型：設定基本堆疊，並在正常運作後新增元件，直到您達到功能完整的實作為止。 + [步驟 1：完成事前準備](gettingstarted-prerequisites.md)示範如何進行設定以開始演練。 + [步驟 2：建立簡易應用程式伺服器堆疊 - Chef 11](gettingstarted-simple.md) 示範如何建立只由單一應用程式伺服器組成的極簡堆疊。 + [步驟 3：新增後端資料存放區](gettingstarted-db.md)示範如何建立資料庫伺服器，並將其連線至應用程式伺服器。 + [步驟 4：橫向擴展 MyStack](gettingstarted-scale.md)示範如何透過新增更多應用程式伺服器來擴展堆疊以處理增加的負載，以及分配傳入流量的負載平衡器。 **Topics** + [步驟 1：完成事前準備](gettingstarted-prerequisites.md) + [步驟 2：建立簡易應用程式伺服器堆疊 - Chef 11](gettingstarted-simple.md) + [步驟 3：新增後端資料存放區](gettingstarted-db.md) + [步驟 4：橫向擴展 MyStack](gettingstarted-scale.md) + [步驟 5：刪除 MyStack](gettingstarted-delete.md) # 步驟 1：完成事前準備 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。完成下列步驟，才能開始演練。這些設定步驟包括註冊 AWS 帳戶、建立管理使用者，以及將存取許可指派給 OpsWorks Stacks。若您已完成任何 [Stacks OpsWorks 入門](gettingstarted_intro.md)演練，您便完成本演練的事前準備，可直接跳到[步驟 2：建立簡易應用程式伺服器堆疊 - Chef 11](gettingstarted-simple.md)。 **Topics** + [註冊 AWS 帳戶](#sign-up-for-aws) + [建立具有管理存取權的使用者](#create-an-admin) + [將服務存取許可指派給您的使用者](#gettingstarted-prerequisites-permissions) ## 註冊 AWS 帳戶如果您沒有 AWS 帳戶，請完成下列步驟來建立一個。 **註冊 AWS 帳戶** 1. 開啟 [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)。 1. 請遵循線上指示進行。部分註冊程序需接收來電或簡訊，並在電話鍵盤輸入驗證碼。當您註冊時 AWS 帳戶，*AWS 帳戶根使用者*會建立。根使用者有權存取該帳戶中的所有 AWS 服務和資源。作為安全最佳實務，請將管理存取權指派給使用者，並且僅使用根使用者來執行[需要根使用者存取權的任務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 AWS 會在註冊程序完成後傳送確認電子郵件給您。您可以隨時登錄 [https://aws.amazon.com/](https://aws.amazon.com/) 並選擇**我的帳戶**，以檢視您目前的帳戶活動並管理帳戶。 ## 建立具有管理存取權的使用者註冊後 AWS 帳戶，請保護 AWS 帳戶根使用者、啟用 AWS IAM Identity Center和建立管理使用者，以免將根使用者用於日常任務。 **保護您的 AWS 帳戶根使用者** 1. 選擇**根使用者**並輸入 AWS 帳戶您的電子郵件地址，以帳戶擁有者[AWS 管理主控台](https://console.aws.amazon.com/)身分登入。在下一頁中，輸入您的密碼。如需使用根使用者登入的說明，請參閱 *AWS 登入使用者指南*中的[以根使用者身分登入](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)。 1. 若要在您的根使用者帳戶上啟用多重要素驗證 (MFA)。如需說明，請參閱《*IAM 使用者指南*》中的[為您的 AWS 帳戶根使用者（主控台）啟用虛擬 MFA 裝置](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)。 **建立具有管理存取權的使用者** 1. 啟用 IAM Identity Center。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[啟用 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)。 1. 在 IAM Identity Center 中，將管理存取權授予使用者。如需使用 IAM Identity Center 目錄做為身分來源的教學課程，請參閱*AWS IAM Identity Center 《使用者指南*》中的[使用預設值設定使用者存取 IAM Identity Center 目錄](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html)。 **以具有管理存取權的使用者身分登入** + 若要使用您的 IAM Identity Center 使用者簽署，請使用建立 IAM Identity Center 使用者時傳送至您電子郵件地址的簽署 URL。如需使用 IAM Identity Center 使用者登入的說明，請參閱*AWS 登入《使用者指南*》中的[登入 AWS 存取入口網站](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)。 **指派存取權給其他使用者** 1. 在 IAM Identity Center 中，建立一個許可集來遵循套用最低權限的最佳實務。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[建立許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-a-permission-set.html)。 1. 將使用者指派至群組，然後對該群組指派單一登入存取權。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[新增群組](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)。 ## 將服務存取許可指派給您的使用者將 OpsWorks `AWSOpsWorks_FullAccess`和 `AmazonS3FullAccess`許可新增至您的角色或使用者，以啟用 Stacks 服務的存取權（以及 OpsWorks Stacks 依賴的相關服務）。如需新增許可的詳細資訊，請參閱[新增 IAM 身分許可（主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)。您現已完成所有設定步驟，可[開始本演練](gettingstarted-simple.md)。 # 步驟 2：建立簡易應用程式伺服器堆疊 - Chef 11 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。基本應用程式伺服器堆疊包含一個具有公有 IP 地址的應用程式伺服器執行個體，以接收使用者請求。應用程式程式碼和任何相關檔案均存放於單獨的儲存庫中，並從該位置部署到伺服器。下圖說明此類堆疊。 ![\[Diagram showing application server stack with users, internet, and AWS components.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch_2.png) 該堆疊具有下列元件： + *layer* 代表執行個體的群組，並指定設定它們的方式。此範例中的 layer 代表一組 PHP App Server 執行個體。 + *執行個體*，代表 Amazon EC2 執行個體。在此範例中，執行個體已設定為執行 PHP 應用程式伺服器。Layers 可以有任意數量的執行個體。 OpsWorks Stacks 也支援數個其他應用程式伺服器。如需詳細資訊，請參閱[應用程式伺服器 Layer](workinglayers-servers.md)。 + 「應用程式」**包含在應用程式伺服器上安裝應用程式的必要資訊。程式碼存放在遠端儲存庫中，例如 Git 儲存庫或 Amazon S3 儲存貯體。下列各節說明如何使用 OpsWorks Stacks 主控台來建立堆疊並部署應用程式。您也可以使用 CloudFormation 範本來佈建堆疊。如需本主題中說明之佈建堆疊的範例範本，請參閱 [AWS OpsWorks 程式碼片段](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-opsworks.html)。 **Topics** + [步驟 2.1：建立堆疊 - Chef 11](gettingstarted-simple-stack.md) + [步驟 2.2：新增 PHP 應用程式伺服器層 - Chef 11](gettingstarted-simple-layer.md) + [步驟 2.3：將執行個體新增至 PHP App Server Layer - Chef 11](gettingstarted-simple-instance.md) + [步驟 2.4：建立和部署應用程式 - Chef 11](gettingstarted-simple-app.md) # 步驟 2.1：建立堆疊 - Chef 11 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以透過建立堆疊來啟動 OpsWorks Stacks 專案，堆疊可做為執行個體和其他資源的容器。堆疊組態會指定某些由堆疊的所有執行個體共享之基本設定，如 AWS 區域和預設作業系統。 **注意** 此頁面可協助您建立 Chef 11 堆疊。如需如何建立 Chef 12 堆疊的資訊，請參閱[建立堆疊](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-intro-create-stack.html)。此頁面可協助您在 Chef 11 中建立堆疊。 **建立新堆疊** 1. **新增堆疊** 登入 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)。若帳戶沒有堆疊，您會看到 **Welcome to AWS OpsWorks (歡迎使用 AWS OpsWorks)** 頁面。按一下 **Add your first stack (新增您的第一個堆疊)**。否則，您會看到 OpsWorks Stacks 儀表板，其中列出您帳戶的堆疊；按一下**新增堆疊**。 ![\[如果您沒有堆疊，您會在 Stacks OpsWorks 主控台中看到初次執行頁面；否則，您會看到帳戶所有堆疊的清單。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/firstrun.png) 1. **設定堆疊** 在 **Add Stack (新增堆疊)** 頁面上，選擇 **Chef 11 stack (Chef 11 堆疊)** 並指定下列設定： **Stack name (堆疊名稱)** 輸入堆疊的名稱，其中可包含英數字元 (a–z、A–Z 和 0–9) 和連字號 (-)。本演練的範例堆疊名為 **MyStack**。 **區域** 選取美國西部（奧勒岡）做為堆疊的區域。接受其他設定的預設值，然後按一下 **Add Stack (新增堆疊)**。如需各種堆疊設定的詳細資訊，請參閱 [建立新的堆疊](workingstacks-creating.md)。 # 步驟 2.2：新增 PHP 應用程式伺服器層 - Chef 11 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。儘管堆疊基本上是執行個體的容器，但您無法直接將執行個體新增到堆疊。您會新增 layer，其代表相關執行個體的群組，然後將執行個體新增至 layer。 layer 基本上是 Stacks OpsWorks 用來建立具有相同組態之 Amazon EC2 執行個體集的藍圖。您會為每個相關執行個體群組的堆疊新增一個 layer。 OpsWorks Stacks 包含一組內建層，代表執行 MySQL 資料庫伺服器或 PHP 應用程式伺服器等標準軟體套件的執行個體群組。此外，您可以建立部分或完整自訂的 layer，以符合您的特定需求。如需詳細資訊，請參閱[自訂 OpsWorks Stacks](customizing.md)。 MyStack 有一個 layer，即內建的 PHP App Server layer，代表一組充當 PHP 應用程式伺服器的執行個體。如需詳細資訊，包含內建 layer 的描述，請參閱[層](workinglayers.md)。 **將 PHP App Server layer 新增至 MyStack** 1. **開啟新增 Layer 頁面** 建立堆疊完成後， OpsWorks Stacks 會顯示**堆疊**頁面。按一下 **Add a layer (新增 layer)** 以新增您的第一個 layer。 ![\[MyStack interface showing layers and instances sections with options to add components.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs2a.png) 1. **指定 Layer 類型及設定 Layer** 在**層類型**方塊中，選取 **PHP App Server**，接受預設**的 Elastic Load Balancer** 設定，然後按一下**新增層**。在您建立 layer 後，您可以藉由[編輯 layer](workinglayers-basics-edit.md) 來指定其他屬性，例如：EBS 磁碟區組態。 ![\[Add layer interface showing PHP App Server layer type selection and Elastic Load Balancer option.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs3.png) # 步驟 2.3：將執行個體新增至 PHP App Server Layer - Chef 11 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Stacks OpsWorks 執行個體代表特定的 Amazon EC2 執行個體： + 執行個體的組態會指定一些基本概念，例如 Amazon EC2operating系統和大小；它會執行，但不會執行太多操作。 + 執行個體的 layer 可透過判斷要安裝何種套件、執行個體是否具有彈性 IP 地址等，為執行個體新增功能。 OpsWorks Stacks 會在與服務互動的每個執行個體上安裝代理程式。若要將 layer 的功能新增至執行個體， OpsWorks Stacks 會指示代理程式執行稱為 [Chef 配方](http://docs.chef.io/recipes.html)的小型應用程式，這些應用程式可以安裝應用程式和套件、建立組態檔案等。 OpsWorks Stacks 會在執行個體[生命週期](workingcookbook-events.md)中的關鍵點執行配方。例如，OpsWorks 會在執行個體完成開機後執行安裝配方，處理像是安裝軟體等任務，然後在您部署應用程式時執行部署配方安裝程式碼和相關檔案。 **注意** 如果您對配方的運作方式感到好奇，所有 OpsWorks Stacks 內建配方都在公有 GitHub 儲存庫中：[OpsWorks 技術指南](https://github.com/aws/opsworks-cookbooks)。您也可以建立您自己的自訂配方，讓 OpsWorks Stacks 執行他們，如稍後所說明。若要將 PHP 應用程式伺服器新增至 MyStack，請將執行個體新增至您在上一個步驟中建立的 PHP App Server layer。 **將執行個體新增至 PHP App Server layer** 1. **開啟新增執行個體** 新增 layer 完成後， OpsWorks Stacks 會顯示 **Layers **頁面。在導覽窗格中按一下**執行個體**，然後在 **PHP App Server** 下按一下**新增執行個體**。 1. **設定執行個體** 每個執行個體都有 Stacks OpsWorks 為您產生的預設主機名稱。在此範例中， OpsWorks Stacks 只會將數字新增至 layer 的簡短名稱。您可以個別設定每個執行個體，包含覆寫您在建立堆疊時指定的部分預設設定，例如可用區域或作業系統。針對本演練，請接受預設設定，然後按一下 **Add Instance (新增執行個體)** 將執行個體新增至 layer。如需詳細資訊，請參閱[執行個體](workinginstances.md)。 ![\[Form for adding a new PHP App Server instance with hostname, size, and subnet options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs7.png) 1. **啟動執行個體** 到目前為止，您完成了執行個體組態的指定。您必須啟動執行個體，才能建立執行中的 Amazon EC2 執行個體。然後， OpsWorks Stacks 會使用組態設定在指定的可用區域中啟動 Amazon EC2 執行個體。您啟動執行個體之方式的詳細資訊取決於執行個體的「擴展類型」**。在先前的步驟中，您使用預設擴展類型「全年無休」**建立執行個體，該類型必須手動啟動，並且會持續執行直到手動停止。您也可以建立時間型和負載型擴展類型， OpsWorks 堆疊會根據排程或目前的負載自動啟動和停止。如需詳細資訊，請參閱[使用時間型和負載型執行個體管理負載](workinginstances-autoscaling.md)。前往 **PHP App Server** 下的 **php-app1**，然後按一下列**的動作**欄中的**開始**以啟動執行個體。 ![\[PHP App Server instance list showing php-app1 stopped with start and delete options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs8.png) 1. **在啟動時監控執行個體的狀態** 通常需要幾分鐘的時間來啟動 Amazon EC2 執行個體並安裝套件。隨著啟動的進行，執行個體的 **Status (狀態)** 欄位會顯示下列一系列的值： 1. **requested** - OpsWorks Stacks 已呼叫 Amazon EC2 服務來建立 Amazon EC2 執行個體。 1. **待**定 - OpsWorks Stacks 正在等待 Amazon EC2 執行個體啟動。 1. **開機** - Amazon EC2 執行個體正在開機。 1. **running\$1setup** - Stacks OpsWorks 代理程式正在執行 layer 的設定配方，處理設定和安裝套件等任務，以及部署配方，將任何應用程式部署到執行個體。 1. **online** - 執行個體已準備就緒可供使用。在 php-app1 上線後，**Instances (執行個體)** 頁面看起來應該會像是這樣： ![\[PHP App Server instance table showing php-app1 online with details like size and IP address.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs9.png) 頁面的開頭為所有您堆疊執行個體的快速摘要。現在，它會顯示一個線上的執行個體。在 php-app1 的 **Actions (動作)** 資料行中，請注意會停止執行個體的 **stop (停止)** 已取代 **start (啟動)** 和 **delete (刪除)**。 # 步驟 2.4：建立和部署應用程式 - Chef 11 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要讓 MyStack 更有用，您需要將應用程式部署到 PHP App Server 執行個體。您將應用程式的程式碼和任何相關檔案存放在儲存庫中 (例如 Git)。您需要幾個步驟，才能使那些檔案進入到您的應用程式伺服器內。 **注意** 本節中的程序適用於 Chef 11 堆疊。如需如何在 Chef 12 堆疊中將應用程式新增至 layer 的資訊，請參閱[新增應用程式](workingapps-creating.md)。 1. 建立應用程式。應用程式包含 OpsWorks Stacks 從儲存庫下載程式碼和相關檔案所需的資訊。您也可以指定額外的資訊，例如應用程式的網域。 1. 將應用程式部署到您的應用程式伺服器。當您部署應用程式時， OpsWorks Stacks 會觸發部署生命週期事件。代理程式接著會執行執行個體的部署配方，將檔案下載到適當的目錄並執行相關任務，例如設定伺服器、重新啟動服務等。 **注意** 當您建立新的執行個體時， OpsWorks Stacks 會自動將任何現有的應用程式部署到執行個體。但是，當您建立新的應用程式或更新現有的應用程式時，您必須手動部署應用程式或更新所有現有的執行個體。此步驟顯示如何手動從公有 Git 儲存庫將範例應用程式部署到應用程式伺服器。若您想要檢查應用程式，請前往 [https://github.com/amazonwebservices/opsworks-demo-php-simple-app](https://github.com/amazonwebservices/opsworks-demo-php-simple-app)。此範例中使用的應用程式位於版本 1 分支中。 OpsWorks Stacks 也支援數種其他儲存庫類型。如需詳細資訊，請參閱[應用程式來源](workingapps-creating.md#workingapps-creating-source)。 **建立和部署應用程式** 1. **開啟應用程式頁面** 在導覽窗格中，按一下 **Apps (應用程式)**，然後在 **Apps (應用程式)** 頁面上，按一下 **Add an app (新增應用程式)**。 ![\[Apps page showing no apps and an "Add an app" button with a brief description.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs13.png) 1. **設定應用程式。** 在 **App (應用程式)** 頁面上，指定下列值： **名稱** 應用程式的名稱， Stacks OpsWorks 用於顯示目的。範例應用程式名為 **SimplePHPApp**。 OpsWorks Stacks 也會為此範例產生簡短名稱 -simplephpapp，供內部和部署配方使用，如下所述。 **Type** 應用程式的類型，判斷部署應用程式的位置。此範例使用 **PHP**，會將應用程式部署到 PHP App Server 執行個體。 **Data source type (資料來源類型)** 關聯的資料庫伺服器。現階段請先選取 **None (無)**。我們將於[步驟 3：新增後端資料存放區](gettingstarted-db.md)介紹資料庫伺服器。 **儲存庫類型** 應用程式的儲存庫類型。範例應用程式存放於 **Git** 儲存庫。 **Repository URL (儲存器 URL)** 應用程式的儲存庫 URL。範例 URL 為 **git://github.com/awslabs/opsworks-demo-php-simple-app.git** **Branch/Revision (分支/修訂)** 應用程式的分支或版本。本演練的此部分使用 **version1** 分支。保留剩餘設定的預設值，然後按一下 **Add App (新增應用程式)**。如需詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。 ![\[Add App form with settings for name, type, document root, data sources, and application source.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs14.png) 1. **開啟部署頁面** 若要在伺服器上安裝程式碼，您必須「部署」**應用程式。若要執行此作業，請按一下 SimplePHPApp 中 **Actions (動作)** 資料行中的 **deploy (部署)**。 ![\[Apps table showing SimplePHPApp with deploy, edit, and delete options in the Actions column.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs15.png) 1. **部署應用程式** 當您部署應用程式時，代理程式會在 PHP App Server 執行個體上執行部署配方，以下載和設定應用程式。 **Command (命令)** 應該已設為 **deploy (部署)**。保持其他設定的預設值，然後按一下 **Deploy (部署)** 部署應用程式。 ![\[Deploy app interface with settings for SimplePHPApp and instance selection options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs16.png) 部署完成後，**Deployment (部署)** 頁面便會顯示 **Status (狀態)** 為 **Successful (成功)**，並且 **php-app1** 一旁會有綠色的核取記號。 1. **執行 SimplePHPApp** SimplePHPApp 現在已安裝並準備好可供使用。若要執行它，請按一下導覽窗格中的 **Instances (執行個體)** 以前往 **Instances (執行個體)** 頁面。然後按一下 php-app1 執行個體的公有 IP 地址。 ![\[PHP App Server instance details showing hostname, status, size, and public IP address.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs20.png) 您應該會在您的瀏覽器中看到如下的頁面。 ![\[Confirmation page for a simple PHP application running on AWS 雲端 with PHP version 5.3.20.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs21.png) **注意** 本演練假設您會繼續前進到下一節，並最終會於一個工作階段中完成整個演練。如果您願意，您可以隨時停止，稍後再登入 Stacks OpsWorks 並開啟堆疊以繼續。但是，您必須為任何您使用的 AWS 資源支付費用 (例如線上執行個體)。為避免不必要的費用，您可以停止您的執行個體，如此便會停止對應的 EC2 執行個體。當您準備好繼續時，您可以再次啟動執行個體。 # 步驟 3：新增後端資料存放區 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 [步驟 2.1：建立堆疊 - Chef 11](gettingstarted-simple-stack.md) 向您示範如何建立提供 PHP 應用程式的堆疊。不過，這是非常簡單的應用程式，作用只比顯示一些靜態文字多一點。生產應用程式通常使用後端資料存放區，產生類似下圖的堆疊組態。 ![\[AWS OpsWorks stack architecture diagram showing PHP app, MySQL, and user interactions.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch_3.png) 本節示範如何擴展 MyStack 以包含後端 MySQL 資料庫伺服器。雖然您需要做的不只是新增 MySQL 伺服器到堆疊。您也必須將應用程式設定為與資料庫伺服器正確通訊。 OpsWorks Stacks 不會為您執行此操作；您將需要實作一些自訂配方來處理該任務。 **Topics** + [步驟 3.1：新增後端資料庫](gettingstarted-db-db.md) + [步驟 3.2：更新 SimplePHPApp](gettingstarted-db-update.md) + [簡短分類：技術指南、配方和 OpsWorks Stacks 屬性](gettingstarted-db-recipes.md) + [步驟 3.3：將自訂技術指南新增至 MyStack](gettingstarted-db-cookbooks.md) + [步驟 3.4：執行配方](gettingstarted-db-lifecycle.md) + [步驟 3.5：部署 SimplePHPApp 2 版](gettingstarted-db-deploy.md) + [步驟 3.6：執行 SimplePHPApp](gettingstarted-db-run.md) # 步驟 3.1：新增後端資料庫 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 SimplePHPApp 的新版本將其資料存放在後端資料庫中。 OpsWorks Stacks 支援兩種類型的資料庫伺服器： + [MySQL OpsWorks Stacks layer](workinglayers-db-mysql.md) 是建立託管 MySQL 資料庫主節點的 Amazon EC2 執行個體的藍圖。 + Amazon RDS 服務層提供將 [Amazon RDS 執行個體](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)併入堆疊的方法。您也可以使用其他資料庫，例如 Amazon DynamoDB，或建立自訂 layer 以支援資料庫，例如 [MongoDB](http://www.mongodb.org/)。如需詳細資訊，請參閱[使用後端資料存放區](customizing-rds.md)。此範例使用 MySQL layer。 **將 MySQL layer 新增至 MyStack** 1. 在 **Layers (Layer)** 頁面上，按一下 **\$1 Layer**。 1. 在 **Add Layer (新增 Layer)** 頁面上，針對 **Layer type (Layer 類型)**，選取 **MySQL**，接受預設設定，然後按一下 **Add Layer (新增 Layer)**。 ![\[Add Layer interface for MySQL with options to set 根使用者 password and apply to all instances.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb3.png) **將執行個體新增至 MySQL layer** 1. 在 **Layers (Layer)** 頁面的 **MySQL** 資料列上，按一下 **Add an instance (新增執行個體)**。 1. 在 **Instances (執行個體)** 頁面上，在 **MySQL** 下，按一下 **Add an instance (新增執行個體)**。 1. 接受預設值，然後按一下 **Add instance (新增執行個體)**，但先不啟動它。 **注意** OpsWorks Stacks 會自動建立名為的資料庫，在此範例中使用應用程式的簡短名稱 simplephpapp。如果您想要使用 [Chef 配方](http://docs.chef.io/recipes.html)與資料庫互動，您會需要此名稱。 # 步驟 3.2：更新 SimplePHPApp **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要開始，您必須使用後端資料存放區的新版 SimplePHPApp。使用 OpsWorks Stacks，您可以輕鬆更新應用程式。如果您使用 Git 或 Subversion 儲存庫，每個應用程式版本都可以有單獨的儲存庫分支。範例應用程式會將使用後端資料庫之版本的應用程式存放在 Git 儲存庫的 version2 分支。您只需要更新應用程式的組態來指定新分支以及重新部署應用程式。 **更新 SimplePHPApp** 1. **開啟應用程式的 Edit (編輯) 頁面** 在導覽窗格中，按一下 **Apps (應用程式)**，然後按一下 **SimplePHPApp** 資料列中 **Actions (動作)** 欄的 **edit (編輯)**。 1. **更新應用程式組態** 變更下列設定。 **Branch/Revision (分支/修訂)** 此設定指出應用程式的儲存庫分支。第一版的 SimplePHPApp 未連線到資料庫。若要使用已啟用資料庫的應用程式版本，請將此值設定為 **version2**。 **Document root (文件根)** 此設定指定應用程式的根資料夾。第一版的 SimplePHPApp 使用預設設定，將 `index.php` 安裝在伺服器的標準根資料夾中 (PHP 應用程式為 `/srv/www`)。如果您在此處指定子資料夾 — 僅名稱，沒有前置 '/' —OpsWorks Stacks 會將它附加到標準資料夾路徑。SimplePHPApp 版本 2 應該在 `/srv/www/web`，因此請將 **Document root (文件根)** 設為 **web**。 **Data source type (資料來源類型)** 此設定會建立資料庫伺服器與應用程式的關聯。此範例使用您在上一個步驟中建立的 MySQL 執行個體，因此請將**資料來源類型**設定為 OpsWorks 和**資料庫執行個體**，設定為您在上一個步驟 **db-master1 (mysql)** 中建立的執行個體。將**資料庫名稱**保留空白； OpsWorks Stacks 將在名為的伺服器上，以應用程式的簡短名稱 simplephpapp 建立資料庫。然後按一下 **Save (儲存)**，儲存新的組態。 ![\[Add App form with settings for SimplePHP application and OpsWorks data source.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb2.png) 1. 啟動 MySQL 執行個體。更新應用程式後，當您啟動應用程式伺服器執行個體時， OpsWorks Stacks 會自動將新的應用程式版本部署到任何新的應用程式伺服器執行個體。不過， OpsWorks Stacks 不會自動將新的應用程式版本部署到現有的伺服器執行個體；您必須手動執行此操作，如中所述[步驟 2.4：建立和部署應用程式 - Chef 11](gettingstarted-simple-app.md)。您現在可以部署已更新的 SimplePHPApp，但在此範例中，最好再等等。 # 簡短分類：技術指南、配方和 OpsWorks Stacks 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您現在有應用程式和資料庫伺服器，但它們還不能使用。您仍然需要設定資料庫並設定應用程式的連線設定。 OpsWorks Stacks 不會自動處理這些任務，但支援 Chef 技術指南、配方和動態屬性。您可以實作一對配方，一個用於設定資料庫，另一個用於設定應用程式的連線設定，並讓 OpsWorks Stacks 為您執行它們。包含必要配方的 phpapp 技術指南已實作可供使用，如果想要，您可以直接跳到[步驟 3.3：將自訂技術指南新增至 MyStack](gettingstarted-db-cookbooks.md)。如果想知道更多，本節會提供一些有關技術指南和配方的背景，說明配方的運作方式。若要查看技術指南本身，請參閱 [phpapp 技術指南](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/phpapp)。 **Topics** + [配方和屬性](#gettingstarted-db-recipes-attributes) + [設定資料庫](#gettingstarted-db-recipes-dbsetup) + [將應用程式連線到資料庫](#gettingstarted-db-recipes-appsetup) ## 配方和屬性 Chef 配方基本上是專門在執行個體上執行任務 (例如安裝套件、建立組態檔案、執行 shell 命令等等) 的 Ruby 應用程式。相關配方的群組會組織成「技術指南」**，其也包含支援的檔案，例如建立組態檔案的範本。 OpsWorks Stacks 有一組支援內建 layer 的技術指南。您也可以使用自己的配方建立自訂技術指南，在您的執行個體上執行自訂任務。本主題提供配方的簡介，並示範如何使用它們設定資料庫以及設定應用程式的連線設定。如需技術指南和配方的詳細資訊，請參閱[技術指南和配方](workingcookbook.md)或[自訂 OpsWorks Stacks](customizing.md)。配方通常取決於輸入資料的 Chef「屬性」**： + 這些屬性有部分由 Chef 定義，提供執行個體的基本資訊，例如作業系統。 + OpsWorks Stacks 會定義一組屬性，其中包含堆疊的相關資訊，例如 layer 組態，以及已部署應用程式的相關資訊，例如應用程式儲存庫。您可以將[自訂 JSON](workingstacks-json.md) 指派給堆疊或部署，將自訂的屬性新增至此集合。 + 您的技術指南也可以定義技術指南專用的屬性。 phpapp 技術指南屬性在 `attributes/default.rb` 中定義。如需 OpsWorks Stacks 屬性的完整清單，請參閱 [堆疊組態及部署屬性：Linux](attributes-json-linux.md)和 [內建技術指南屬性](attributes-recipes.md)。如需詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。屬性是以階層式結構組織，可以 JSON 物件表示。您使用 Chef 節點語法將此資料併入您的應用程式，如下所示： ``` [:deploy][:simplephpapp][:database][:username] ``` `deploy` 節點有單一應用程式節點 `simplephpapp`，其包含應用程式資料庫、Git 儲存庫等等的資訊。此範例呈現資料庫使用者名稱的值，解析成 `root`。 ## 設定資料庫 MySQL layer 的內建設定配方會自動為名為的應用程式建立資料庫，並使用應用程式的短名，因此在此範例中，您已有一個名為 simplephpapp 的資料庫。不過，您需要建立表格供應用程式存放其資料，以完成設定。您可以手動建立資料表，但更好的方法是實作自訂配方來處理任務，並讓 OpsWorks Stacks 為您執行。本節說明如何實作配方 `dbsetup.rb`。稍後將說明讓 OpsWorks Stacks 執行配方的程序。若要查看儲存庫中的配方，請前往 [dbsetup.rb](https://github.com/amazonwebservices/opsworks-example-cookbooks/blob/master/phpapp/recipes/dbsetup.rb)。以下範例顯示 `dbsetup.rb` 程式碼。 `execute` 是執行指定命令的「Chef 資源」**。在此範例中，它是建立表格的 MySQL 命令。如果指定的表格已存在，`not_if` 指令會確保命令不會執行。如需 Chef 資源的詳細資訊，請參閱[關於資源和提供者](https://docs.chef.io/resource.html)。配方使用先前討論過的節點語法，將屬性值插入命令字串。例如，以下內容會插入資料庫的使用者名稱。 ``` #{deploy[:database][:username]} ``` 讓我們解釋這個有點隱晦的程式碼： + 每次重複，`deploy` 都設為目前的應用程式節點，所以它會解析成 `[:deploy][:app_name]`。在此範例中，它解析成 `[:deploy][:simplephpapp]`。 + 使用先前顯示的部署屬性值，整個節點會解析成 `root`。 + 您用 \$1\$1 \$1 包裝節點，將它插入字串中。其他大部分的節點也以類似方式解析。但 `#{node[:phpapp][:dbtable]}` 是例外，它是由自訂技術指南的屬性檔案所定義，解析成表格名稱 `urler`。因此，在 MySQL 執行個體上執行的實際命令為： ``` "/usr/bin/mysql -uroot -pvjud1hw5v8 simplephpapp -e'CREATE TABLE urler( id INT UNSIGNED NOT NULL AUTO_INCREMENT, author VARCHAR(63) NOT NULL, message TEXT, PRIMARY KEY (id))' " ``` 此命令會使用來自部署屬性的登入資料和資料庫名稱，建立有 ID、作者和訊息欄位的表格，名為 `urler`。 ## 將應用程式連線到資料庫第二塊拼圖是應用程式，它需要連線資訊，例如存取表格的資料庫密碼。SimplePHPApp 其實只有一個工作檔案 `app.php`，而 `index.php` 所做的只是載入 `app.php`。 `app.php` 包含處理資料庫連線的 `db-connect.php`，但此檔案不在儲存庫中。您不能事先建立 `db-connect.php`，因為它會根據特定的執行個體定義資料庫。反之，`appsetup.rb` 配方使用來自部署屬性的連線資料產生 `db-connect.php`。若要查看儲存庫中的配方，請前往 [appsetup.rb](https://github.com/amazonwebservices/opsworks-example-cookbooks/blob/master/phpapp/recipes/appsetup.rb)。以下範例顯示 `appsetup.rb` 程式碼。就像一樣`dbsetup.rb`， `appsetup.rb` 會反覆運算`deploy`節點中的應用程式 - 只需再次使用 simplephpapp 即可。它會執行有 `script` 資源和 `template` 資源的程式碼區塊。 `script` 資源會安裝 [Composer](http://www.getcomposer.org)，這是 PHP 應用程式的相依性管理員。然後執行 Composer 的 `install` 命令，將範例應用程式的相依性安裝到應用程式的根目錄。 `template` 資源會產生 `db-connect.php`，並將它放在 `/srv/www/simplephpapp/current`。注意下列事項： + 此配方使用條件式陳述式指定檔案擁有者，這取決於執行個體的作業系統。 + `only_if` 指令通知 Chef 只在指定目錄存在時產生範本。 `template` 資源在基本上與相關聯檔案有相同的內容和結構，但包含各種資料值的預留位置的範本上操作。`source` 參數指定範本 `db-connect.php.erb`，它在 phpapp 技術指南的 `templates/default` 目錄中，包含下列內容：當 Chef 處理範本時，它會以範本資源中的對應變數值取代 `<%= =>` 預留位置，因此取自部署屬性。因此產生的檔案為： # 步驟 3.3：將自訂技術指南新增至 MyStack **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您將自訂技術指南存放在儲存庫中，很類似應用程式。每個堆疊都有一個包含一組自訂技術指南的儲存庫。然後，指示 OpsWorks Stacks 在堆疊的執行個體上安裝自訂技術指南。 1. 按一下導覽窗格中的 **Stack (堆疊)** 查看目前堆疊的頁面。 1. 按一下 **Stack Settings (堆疊設定)**，然後按一下 **Edit (編輯)**。 1. 如下修改堆疊組態： + **使用自訂 Chef 技術指南** – **是** + **儲存庫類型** – **Git** + **儲存庫 URL** – **git://github.com/amazonwebservices/opsworks-example-cookbooks.git** 1. 按一下 **Save (儲存)** 更新堆疊組態。 ![\[Configuration options for custom Chef cookbooks with Git repository settings.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb6.png) OpsWorks Stacks 接著會在堆疊的所有執行個體上安裝技術指南儲存庫的內容。如果您建立新的執行個體， OpsWorks Stacks 會自動安裝技術指南儲存庫。 **注意** 如果您需要更新任何技術指南，或將新的技術指南新增至儲存庫，您可以這樣做，而無需接觸堆疊設定。 OpsWorks Stacks 會自動在所有新的執行個體上安裝更新的技術指南。不過， OpsWorks Stacks 不會自動在堆疊的線上執行個體上安裝更新的技術指南。您必須執行堆疊`Update Cookbooks`命令，明確指示 OpsWorks Stacks 更新技術指南。如需詳細資訊，請參閱[執行堆疊命令](workingstacks-commands.md)。 # 步驟 3.4：執行配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。有了自訂技術指南之後，您需要在適當的執行個體上執行配方。您可以[手動執行它們](workingcookbook-manual.md)。不過，配方一般需要在執行個體生命週期的可預測點上執行，例如在執行個體開機後，或部署應用程式時。本節說明更簡單的方法：讓 OpsWorks Stacks 在適當的時間自動為您執行。 OpsWorks Stacks 支援一組[生命週期事件](workingcookbook-events.md)，可簡化執行中的配方。例如，執行個體開機完成後會發生 Setup (設定) 事件，當您部署應用程式時則會發生 Deploy (部署) 事件。每個 layer 都有一組與每個生命週期事件相關聯的內建配方。當執行個體上發生生命週期事件時，代理程式會為每個執行個體 layer 執行相關聯的配方。若要讓 OpsWorks Stacks 自動執行自訂配方，請將其新增至適當 layer 上的適當生命週期事件，代理程式會在內建配方完成後執行配方。在此範例中，您需要`dbsetup.rb`在 MySQLinstance 和 PHP App Server 執行個體`appsetup.rb`上執行兩個配方。 **注意** 您使用 *cookbook\$1name*::*recipe\$1name* 格式在主控台上指定配方，*recipe\$1name* 不包含 .rb 副檔名。例如，您參考 `dbsetup.rb` 為 **phpapp::dbsetup**。 **將自訂配方指派給生命週期事件** 1. 在 **Layers** 頁面上，針對 MySQL，按一下**配方**，然後按一下**編輯**。 1. 在**自訂 Chef 配方**區段中，輸入 [**phpapp::dbsetup**](gettingstarted-db-recipes.md#gettingstarted-db-recipes-dbsetup) **部署**。 ![\[Custom Chef recipes section with Repository URL and three configuration steps.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb6a.png) 1. 按一下 **\$1** 圖示，將配方指派給事件，然後按一下 **Save (儲存)** 儲存新的 layer 組態。 1. 返回 **Layers (Layer)** 頁面，重複此程序將 **phpapp::appsetup** 指派給 **PHP App Server (PHP 應用程式伺服器)** layer 的 **Deploy (部署)** 事件。 # 步驟 3.5：部署 SimplePHPApp 2 版 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。最終步驟是部署新版本的 SimplePHPApp。 **部署 SimplePHPApp** 1. 在 **Apps (應用程式)** 頁面上，按一下 **SimplePHPApp** 應用程式 **Actions (動作)** 中的 **deploy (部署)**。 ![\[Apps page showing SimplePHPApp with deploy, edit, and delete options in the Actions column.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb6aa.png) 1. 接受預設值，然後按一下 **Deploy (部署)**。 ![\[Deploy App interface with settings for SimplePHPApp and instance selection options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs17a.png) 當您在**部署****應用程式**頁面上按一下部署時，會觸發部署生命週期事件，通知客服人員執行其部署配方。根據預設，您會觸發所有堆疊的執行個體上之事件。內建的部署配方只會將應用程式部署到應用程式類型的適當執行個體，在此情況下為 PHP App Server 執行個體。不過，觸發其他執行個體上的 Deploy (部署) 事件，讓它們回應應用程式部署，通常很有用。在此情況下，您也想要觸發 MySQL 執行個體上的部署來設定資料庫。注意下列事項： + PHP App Server 執行個體上的代理程式會執行 layer 的內建配方，後面接著 `appsetup.rb`，這會設定應用程式的資料庫連線。 + MySQL 執行個體上的代理程式不會安裝任何項目，但會執行 `dbsetup.rb`來建立 urler 資料表。當部署完成後，**Deployment (部署)** 頁面上的 **Status (狀態)** 會變更為 **successful (成功)**。 # 步驟 3.6：執行 SimplePHPApp **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。部署狀態變更為 **successful (成功)** 後，您就可以執行新的 SimplePHPApp 版本，如下所示。 **執行 SimplePHPApp** 1. 在 **Instances (執行個體)** 頁面上，按一下在 **php-app1** 資料列中的公有 IP 地址。您應該會在瀏覽器中看到如下頁面。 ![\[Text input field labeled "Your Thoughts" with a "Share Your Thought" button above.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb7.png) 1. 按一下 **Share Your Thought (分享您的想法)**，輸入類似 **Hello world\$1** (針對 **Your Thought (您的想法)**) 和您的姓名 (針對 **Your Name (您的姓名)**)。然後按一下 **Submit Your Thought (提交您的想法)** 將訊息新增到資料庫。 ![\[Form with success message, text input fields for thought and name, and submit buttons.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb8.png) 1. 按一下 **Go Back (返回)** 檢視資料庫中的所有訊息。 # 步驟 4：橫向擴展 MyStack **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 MyStack 目前只有一部應用程式伺服器。生產堆疊可能需要多部應用程式伺服器才能處理傳入流量，以及一個負載平衡器才能將傳入流量平均配送至應用程式伺服器。此架構類似下列內容。 ![\[AWS OpsWorks stack architecture with load balancer, application servers, and RDS instance.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/php_walkthrough_arch_4.png) OpsWorks Stacks 可讓您輕鬆地向外擴展堆疊。本節說明如何將第二個全年無休 PHP App Server 執行個體新增至 MyStack，並將兩個執行個體放在 Elastic Load Balancing 負載平衡器後方，以擴展堆疊的基本概念。您可以輕鬆擴展程序來新增 24 小時全年無休的任意執行個體，也可以使用時間型或負載型執行個體讓 OpsWorks Stacks 自動擴展您的堆疊。如需詳細資訊，請參閱[使用時間型和負載型執行個體管理負載](workinginstances-autoscaling.md)。 # 步驟 4.1：新增負載平衡器 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Elastic Load Balancing 是一種 AWS 服務，可在多個 Amazon EC2 執行個體之間自動分配傳入的應用程式流量。除了分佈流量之外，Elastic Load Balancing 還會執行下列動作： + 偵測運作狀態不佳的 Amazon EC2 執行個體。它會將流量重新路由至狀況良好的執行個體，直到狀況不良的執行個體恢復為止。 + 自動擴展處理容量的請求，以回應傳入的流量 **注意** 負載平衡器有兩種用途。其中一個顯而易見的用途，是使應用程式伺服器上的負載達到均衡。此外，許多網站都偏好隔離它們的應用程式伺服器和資料庫，讓使用者無法直接存取。使用 OpsWorks Stacks，您可以透過在具有公有和私有子網路的虛擬私有雲端 (VPC) 中執行堆疊來執行此操作，如下所示。將應用程式伺服器和資料庫放入私有子網路中，而 VPC 中的其他執行個體可以在其中存取它們，但使用者無法存取。將使用者流量導向公有子網路中的負載平衡器，接著將流量轉遞給私有子網路中的應用程式伺服器，並將回應傳回給使用者。如需詳細資訊，請參閱[在 VPC 中執行堆疊](workingstacks-vpc.md)。如需延伸本演練中範例以在 VPC 中執行的 CloudFormation 範本，請下載 [`OpsWorksVPCtemplates.zip` 檔案](samples/OpsWorksVPCtemplates.zip)。雖然 Elastic Load Balancing 通常稱為 layer，但其運作方式與其他內建 layer 略有不同。您可以使用 Amazon EC2 主控台建立 Elastic Load Balancing 負載平衡器，然後將它連接到其中一個現有的 layer，通常是應用程式伺服器 layer。 OpsWorks Stacks 接著會向服務註冊 layer 的現有執行個體，並自動新增任何新的執行個體。下列程序說明如何將負載平衡器新增至 MyStack 的 PHP App Server layer。 **注意** OpsWorks Stacks 不支援 Application Load Balancer。您只能搭配 Stacks OpsWorks 使用 Classic Load Balancer。 **將負載平衡器連接至 PHP App Server layer** 1. 使用 Amazon EC2 主控台為 MyStack 建立新的負載平衡器。詳細資訊取決於您的帳戶是否支援 EC2 Classic。如需詳細資訊，請參閱 [Elastic Load Balancing 入門](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html)。當您執行 **Create Load Balancer (建立負載平衡器)** 精靈時，請設定負載平衡器，如下所示： **Define Load Balancer (定義負載平衡器)** 指派可輕鬆辨識的名稱給負載平衡器，例如 PHP-LB，讓您更輕鬆地在 Stacks OpsWorks 主控台中找到。然後選擇 **Continue (繼續)** 接受其餘設定的預設值。如果您從 **Create LB Inside (於內部建立 LB)** 選單中選擇具有一或多個子網路的 VPC，則必須針對您想要負載平衡器路由流量的每個可用區域選取子網路。 **Assign Security Groups (指派安全群組)** 如果您的帳戶支援預設 VPC，精靈會顯示此頁面以決定負載平衡器的安全群組。但不會為 EC2 Classic 顯示此頁面。在本演練中，選擇 **default VPC security group (預設 VPC 安全群組)**。 **Configure Security Settings (設定安全設定)** 如果您在定義負載平衡器頁面上選擇 **HTTPS** 做為負載平衡器通訊協定，請在此頁面設定憑證、密碼和 SSL 通訊協定設定。 **Load Balancer ** ** Load Balancer** 在本演練中，接受預設值，然後選擇 **Configure Health Check (設定運作狀態檢查)**。 **Configure Health Check (設定運作狀態檢查)** 將 ping 路徑設定為 **/**，並接受其餘設定的預設值。 **Add EC2 Instances (新增 EC2 執行個體)** 選擇**繼續**； OpsWorks Stacks 會自動向負載平衡器註冊執行個體。 **新增標籤** 新增標籤，協助您尋找。每個標籤都是鍵/值對；例如，您可以指定 **Description** 做為鍵並指定 **Test LB** 做為值，以用於演練。 **檢閱** 檢閱您的選擇，並選擇 **Create (建立)**，然後選擇 **Close (關閉)**，以啟動負載平衡器。 1. 如果您的帳戶支援預設 VPC，則在您啟動負載平衡器之後，必須確保其安全群組具有適當的傳入規則。預設規則不接受任何傳入流量。 1. 在 Amazon EC2 導覽窗格中選擇**安全群組**。 1. 選取 **default VPC security group (預設 VPC 安全群組)** 1. 在 **Inbound (傳入)** 標籤上，選擇 **Edit (編輯)**。 1. 在本演練中，將 **Source (來源)** 設定為 **Anywhere (隨處)**，以指示負載平衡器接受來自任何 IP 地址的傳入流量。 1. 返回 OpsWorks Stacks 主控台。在 **Layers (Layer)** 頁面上，選擇 layer 的 **Network (網路)** 連結，然後選擇 **Edit (編輯)**。 1. 在 **Elastic Load Balancing** 下，選擇您在步驟 1 建立的負載平衡器，然後選擇 **Save (儲存)**。 ![\[Dropdown menu for Elastic Load Balancer selection with options "Available ELBs" and "None".\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elb_select.png) 將負載平衡器連接到 layer 之後， OpsWorks Stacks 會自動註冊 layer 的目前執行個體，並在新執行個體上線時新增執行個體。 1. 在 **Layers (Layer)** 頁面上，按一下負載平衡器的名稱，以開啟其詳細資訊頁面。當註冊完成且執行個體通過運作狀態檢查時， OpsWorks Stacks 會在負載平衡器頁面上的執行個體旁顯示綠色核取記號。 ![\[Elastic Load Balancing details page showing one EC2 instance in US-west-2a with InService status.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elb_properties3.png) 您現在可以將請求傳送到負載平衡器來執行 SimplePHPApp。 **透過負載平衡器執行 SimplePHPApp** 1. 再次開啟負載平衡器的詳細資訊頁面 (若尚未開啟)。 1. 在屬性頁面上，驗證執行個體的運作狀態檢查狀態，然後按一下負載平衡器的 DNS 名稱來執行 SimplePHPApp。負載平衡器會將請求轉送到 PHP App Server 執行個體，並傳回回應，這看起來應該與您按一下 PHP App Server 執行個體的公有 IP 地址時收到的回應完全相同。 ![\[Elastic Load Balancing settings showing DNS name for PHP-LB in US West region.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elb_properties2.png) **注意** OpsWorks Stacks 也支援 HAProxy 負載平衡器，這對於某些應用程式可能具有優勢。如需詳細資訊，請參閱[HAProxy OpsWorks Stacks Layer](layers-haproxy.md)。 # 步驟 4.2：新增 PHP 應用程式伺服器執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在負載平衡器已就緒，您可以將更多執行個體新增至 PHP App Server layer 來擴展堆疊。從您的觀點而言，操作會無縫進行。每次新的 PHP App Server 執行個體上線時， OpsWorks Stacks 會自動向負載平衡器註冊它並部署 SimplePHPApp，以便伺服器可以立即開始處理傳入流量。為了簡潔起見，本主題說明如何新增一個額外的 PHP App Server 執行個體，但您可以使用相同的方法來新增所需的數量。 **將另一個執行個體新增至 PHP App Server layer** 1. 在執行個體頁面上，按一下 **PHP App Server** 下的 **\$1 執行個體**。 1. 接受預設設定，然後按一下 **Add Instance (新增執行個體)**。 1. 按一下 **start (啟動)** 以啟動執行個體。 # 步驟 4.3：監控 MyStack **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 使用 Amazon CloudWatch 來提供堆疊的指標，並在**監控**頁面上摘要這些指標，方便您使用。您可以檢視整個堆疊、指定 layer 或指定執行個體的指標。 **監控 MyStack** 1. 在導覽窗格中，按一下 **Monitoring (監控)**，以顯示一組具有每 layer 平均指標的圖形。您可以使用 **CPU System (CPU 系統)**、**Memory Used (已使用記憶體)** 和 **Load (負載)** 的選單來顯示不同的相關指標。 ![\[Monitoring dashboard showing CPU, memory, load, and process metrics over time for system layers.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/monitor_stack.png) 1. 按一下 **PHP App Server**，查看該 layer 每個執行個體的指標。 ![\[Dashboard showing CPU, memory, load, and processes metrics for Layer PHP App Server over time.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/monitor_layer.png) 1. 按一下 **php-app1**，查看該執行個體的指標。您可以移動滑桿來查看任何特定時間點的指標。 ![\[Dashboard showing CPU, memory, load, and process metrics for a PHP application instance.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/monitor_instance.png) **注意** OpsWorks Stacks 也支援 Ganglia 監控伺服器，這對於某些應用程式可能具有優勢。如需詳細資訊，請參閱[Ganglia 層](workinglayers-ganglia.md)。 # 步驟 5：刪除 MyStack **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。一旦您開始使用 Amazon EC2 執行個體等 AWS 資源，就會根據用量收費。若您目前暫時不需要使用，建議您停止執行個體，以避免產生任何不必要的費用。若您不再需要堆疊，您可以刪除它。 **刪除 MyStack** 1. **停止所有執行個體** 在 **Instances (執行個體)** 頁面上，按一下 **Stop All Instances (停止所有執行個體)**，然後在出現提示確認操作時，按一下 **Stop (停止)**。 ![\[Confirmation dialog asking if user wants to stop the stack, warning about data loss.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gse1.png) 按一下**停止**後， OpsWorks Stacks 會終止相關聯的 Amazon EC2 執行個體，但不會終止任何相關聯的資源，例如彈性 IP 地址或 Amazon EBS 磁碟區。 1. **刪除所有執行個體** 停止執行個體只會終止相關聯的 Amazon EC2 執行個體。在執行個體狀態顯示已停止時，您必須刪除每個執行個體。在 **PHP App Server (PHP 應用程式伺服器)** layer 中，在 php-app1 執行個體的 **Actions (動作)** 資料行中按一下 **delete (刪除)**。 ![\[PHP App Server table showing two instances with status, size, and actions including delete option.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gse2.png) OpsWorks Stacks 接著會要求您確認刪除，並顯示任何相依的資源。您可以選擇保留任何或全部的資源。此範例沒有依存資源，因此只需按一下 **Delete (刪除)**。針對 php-app2、**MySQL** 執行個體、db-master1 重複此程序。請注意，db-master1 具有相關聯的 Amazon Elastic Block Store 磁碟區，這是預設選取的。將其維持在選取狀態，以伴隨執行個體一同刪除它。 1. **刪除 Layer。** 在 **Layers (Layer)** 頁面上，按一下 **Delete (刪除)**，然後按一下 **Delete (刪除)** 確認。 ![\[PHP App Server layer with options for General Settings, Recipes, Network, EBS Volumes, and Security.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gse4.png) 針對 **MySQL** layer 重複此程序。 1. **刪除應用程式** 在 **Apps (應用程式)** 頁面上，按一下 **SimplePHPApp** 應用程式的 **Actions (動作)** 資料行中的 **delete (刪除)**，然後按一下 **Delete (刪除)** 確認。 ![\[Confirmation dialog for deleting SimplePHPApp, warning of configuration loss.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gse5.png) 1. **刪除 MyStack** 在 **Stack (堆疊)** 頁面上，按一下 **Delete Stack (刪除堆疊)**，然後按一下 **Delete (刪除)** 確認。 ![\[Confirmation dialog for deleting MyStack, warning of settings loss with Cancel and Delete options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gse6.png) 這份演練到此結束。 # 建立您的第一個 Node.js 堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。此範例說明如何建立支援 Node.js 應用程式伺服器的 Linux 堆疊，以及如何部署簡易應用程式。堆疊包含下列元件： + 具有兩個執行個體的 [Node.js App Server layer](workinglayers-node.md) + [Elastic Load Balancing 負載平衡器](layers-elb.md)可將流量分配到應用程式伺服器執行個體 + 提供後端資料庫的 [Amazon Relational Database Service (Amazon RDS) 服務層](#gettingstarted-node-next) **Topics** + [先決條件](#gettingstarted-node-start) + [實作應用程式](#gettingstarted-node-app) + [建立資料庫伺服器和負載平衡器](#gettingstarted-node-create-db) + [建立堆疊](#gettingstarted-node-stack) + [部署應用程式](#gettingstarted-node-deploy) + [後續步驟？](#gettingstarted-node-next) ## 先決條件本演練的假設如下： + 您有一個 AWS 帳戶，並對如何使用 OpsWorks Stacks 有基本的了解。如果您是初次使用 OpsWorks Stacks 或 AWS，請完成中的簡介教學課程來學習基本知識[Chef 11 Linux 堆疊入門](gettingstarted.md)。 + 您具有如何實作 Node.js 應用程式的基本理解。若您是初次使用 Node.js，請完成簡介教學 (例如 [Node: Up and Running](http://chimera.labs.oreilly.com/books/1234000001808/index.html)) 來學習基本概念。 + 您已在您計劃於此範例中使用的 AWS 區域內建立至少一個堆疊。當您在區域中建立第一個堆疊時， OpsWorks Stacks 會為每個層類型建立 Amazon Elastic Compute Cloud (Amazon EC2) 安全群組。您需要這些安全群組才能建立 Amazon RDS 資料庫 (DB) 執行個體。如果您是初次使用 OpsWorks Stacks，我們建議您在此範例中使用與您在中遵循教學課程時相同的區域[Chef 11 Linux 堆疊入門](gettingstarted.md)。若您希望使用新的區域，請在區域內建立新的堆疊。堆疊不需要具備任何 layer 或執行個體。建立堆疊後， OpsWorks Stacks 會自動將一組安全群組新增至區域。 + 您會在[預設 VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html) 中建立您的堆疊。您可以針對本演練使用 EC2-Classic，但一部分的詳細資訊可能會有所不同。例如，使用 EC2-Classic 時，您必須指定執行個體的可用區域 (AZ) 而非其子網路。 + 您的 IAM 使用者具有 Stacks OpsWorks 的完整存取許可。基於安全考量，我們強烈建議您不要在本演練中使用您帳戶的根登入資料。反之，請建立具有 OpsWorks Stacks 完整存取許可的使用者，並將這些登入資料與 Stacks OpsWorks 搭配使用。如需詳細資訊，請參閱[建立管理使用者](opsworks-security-users-manage-admin.md)。 ## 實作應用程式此演練使用連接至 Amazon RDS 資料庫執行個體的簡單 [Express](http://expressjs.com/) 應用程式，並列出執行個體的資料庫。若要實作應用程式，請在您工作站上方便的位置建立名為 `nodedb` 的目錄，並將下列三個檔案新增至其中。 **Topics** + [套件描述項](#w2ab1c14c71b9c11c13b8) + [配置檔案](#w2ab1c14c71b9c11c13c10) + [程式碼檔案](#w2ab1c14c71b9c11c13c12) ### 套件描述項若要建立應用程式的套件描述項，請在 `nodedb` 目錄中新增名為 `package.json` 的檔案，其中包含以下內容。`package.json` 為 Express 應用程式的必要項目，因此必須位於應用程式的根目錄中。 ``` { "name": "Nodejs-DB", "description": "Node.js example application", "version": "0.0.1", "dependencies": { "express": "*", "ejs": "*", "mysql": "*" } } ``` 此 `package.json` 範例相當精簡。它定義了所需的 `name` 及 `version` 屬性，並列出依存套件： + `express` 參考 [Express](http://expressjs.com/) 套件。 + `ejs` 參考 [EJS](http://www.embeddedjs.com/) 套件，應用程式會用它來將文字插入 HTML 配置檔案。 + `mysql` 參考 [node-mysql](https://github.com/felixge/node-mysql) 套件，應用程式會用它來連線至 RDS 執行個體。如需套件描述項檔案的詳細資訊，請參閱 [package.json](https://docs.npmjs.com/cli/v9/configuring-npm/package-json)。 ### 配置檔案若要建立應用程式的配置檔案，請將 `views` 目錄新增至 `nodedb` 目錄，然後將名為 `index.html` 的檔案新增至 `views`，其中內容如下： ``` AWS Opsworks Node.js Example

AWS OpsWorks Node.js Example

Amazon RDS Endpoint: <%= hostname %>

User: <%= username %>

Password: <%= password %>

Port: <%= port %>

Database: <%= database %>

Connection: <%= connectionerror %>

Databases: <%= databases %>

``` 在此範例中，配置檔案是簡單的 HTML 文件，會顯示來自 Amazon RDS 的一些資料。每個 `<%= ... =>` 元素都代表在應用程式程式碼檔案中定義的變數值。我們會在接下來的步驟中建立。 ### 程式碼檔案若要建立應用程式的程式碼檔案，請在 `nodedb` 目錄中新增名為 `server.js` 的檔案，其中包含以下內容。 **重要** 透過 OpsWorks Stacks，Node.js 應用程式的主要程式碼檔案必須命名`server.js`並位於應用程式的根資料夾中。 ``` var express = require('express'); var mysql = require('mysql'); var dbconfig = require('opsworks'); //[1] Include database connection data var app = express(); var outputString = ""; app.engine('html', require('ejs').renderFile); //[2] Get database connection data app.locals.hostname = dbconfig.db['host']; app.locals.username = dbconfig.db['username']; app.locals.password = dbconfig.db['password']; app.locals.port = dbconfig.db['port']; app.locals.database = dbconfig.db['database']; app.locals.connectionerror = 'successful'; app.locals.databases = ''; //[3] Connect to the Amazon RDS instance var connection = mysql.createConnection({ host: dbconfig.db['host'], user: dbconfig.db['username'], password: dbconfig.db['password'], port: dbconfig.db['port'], database: dbconfig.db['database'] }); connection.connect(function(err) { if (err) { app.locals.connectionerror = err.stack; return; } }); // [4] Query the database connection.query('SHOW DATABASES', function (err, results) { if (err) { app.locals.databases = err.stack; } if (results) { for (var i in results) { outputString = outputString + results[i].Database + ', '; } app.locals.databases = outputString.slice(0, outputString.length-2); } }); connection.end(); app.get('/', function(req, res) { res.render('./index.html'); }); app.use(express.static('public')); //[5] Listen for incoming requests app.listen(process.env.PORT); ``` 範例顯示資料庫連線資訊，並查詢資料庫伺服器及顯示伺服器的資料庫。您可以輕易的將其一般化，以和資料庫互動 (若需要的話)。下列備註指向先前程式碼中具有編號的註解。 **[1] 包含資料庫連線資料** `require` 陳述式包含資料庫連線資料。如稍後所述，當您將資料庫執行個體連接至應用程式時， OpsWorks Stacks 會將連線資料放入名為的檔案中`opsworks.js`，看起來類似以下內容： ``` exports.db = { "host":"nodeexample.cdlqlk5uwd0k.us-west-2.rds.amazonaws.com", "database":"nodeexampledb", "port":3306, "username":"opsworksuser", "password":"your_pwd", "reconnect":true, "data_source_provider":"rds", "type":"mysql"} ``` `opsworks.js` 位於應用程式的 `shared/config` 目錄，`/srv/www/app_shortname/shared/config` 中。不過， OpsWorks Stacks `opsworks.js`會在應用程式的根目錄中將符號連結放入，因此您可以只使用來包含物件`require 'opsworks'`。 **[2] 取得資料庫連線資料** 這一組陳述式會將 `db` 物件的值指派給一組 `app.locals` 屬性，其中每一項都會對應到 `index.html` 檔案中的其中一個 <%= ... %> 元素，以顯示 `opsworks.js` 的連線資料。轉譯後的文件會使用對應的屬性值取代 <%= ... %> 元素。 **[3] 連線至 Amazon RDS 執行個體** 範例使用 `node-mysql` 存取資料庫。為連線到資料庫，範例會透過將連線資料傳遞給 `connection`，然後呼叫 `createConnection` 建立連線，來建立 `connection.connect` 物件。 **[4] 查詢資料庫** 在建立連線後，範例會呼叫 `connection.query` 查詢資料庫。此範例只會查詢伺服器的資料庫名稱。`query` 會傳回 `results` 物件的陣列，每個資料庫一個，並且資料庫名稱會指派給 `Database` 屬性。範例會串連名稱，並將他們指派給 `app.locals.databases,`，在轉譯後的 HTML 頁面上顯示清單。在此範例中，有五個資料庫，您在建立 RDS 執行個體時指定的`nodeexampledb`資料庫，以及由 Amazon RDS 自動建立的四個其他資料庫。 **[5] 接聽傳入請求** 最後一個陳述式會在指定連接埠上接聽傳入請求。您不必指定明確的連接埠值。當您將應用程式新增至堆疊時，您可以指定應用程式是否支援 HTTP 或 HTTPS 請求。 OpsWorks Stacks 接著會將`PORT`環境變數設定為 80 (HTTP) 或 443 (HTTPS)，而且您可以在應用程式中使用該變數。您可以監聽其他連接埠，但 Node.js App Server 層的內建安全群組 **AWS-OpsWorks-nodejs-App-Server** 僅允許傳入使用者流量至連接埠 80、443 和 22 (SSH)。若要允許傳入使用者流量到其他連接埠，請使用適當的傳入規則[建立安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)[，並將其指派給 Node.js App Server layer](workinglayers-basics-edit.md#workinglayers-basics-edit-security)。請勿透過編輯內建安全群組來修改傳入規則。每次建立堆疊時， OpsWorks Stacks 都會以標準設定覆寫內建的安全群組，因此您所做的任何變更都會遺失。 **注意** 您可以在您[建立](workingapps-creating.md#workingapps-creating-environment)或[更新](workingapps-editing.md)關聯應用程式時，將自訂環境變數與您的應用程式建立關聯。您也可以使用自訂 JSON 和自訂配方將資料傳遞到您的應用程式。如需詳細資訊，請參閱[傳遞資料到應用程式](apps-data.md)。 ## 建立資料庫伺服器和負載平衡器此範例使用 Amazon RDS 資料庫伺服器和 Elastic Load Balancing 負載平衡器執行個體。您必須分別建立每個執行個體，然後將其併入您的堆疊。本節說明如何建立新的資料庫和負載平衡器執行個體。雖然您可以改為使用現有的執行個體，但我們建議您閱讀整個程序，以確保那些執行個體的設定正確。以下說明如何建立精簡設定，足以用於此範例的 RDS 資料庫執行個體。如需詳細資訊，請參閱 [Amazon RDS 使用者指南](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)。 **建立 RDS 資料庫執行個體** 1. **開啟主控台。** 開啟 [Amazon RDS 主控台，](https://console.aws.amazon.com/rds/)並將區域設定為美國西部（奧勒岡）。在導覽窗格中，選擇 **RDS Dashboard (RDS 儀表板)**，然後選擇 **Launch DB Instance (啟動資料庫執行個體)**。 1. **指定資料庫引擎。** 選擇 **MySQL Community Edition** 做為資料庫引擎。 1. **拒絕異地同步備份部署。** 選擇 **No, this instance... (否，此執行個體...)**，然後選擇 **Next (下一步)**。您在此範例中不需要使用異地同步備份部署。 1. **設定基本設定。** 在 **DB Instance Details (資料庫執行個體詳細資訊)** 頁面上，指定下列設定： + **DB Instance Class (資料庫執行個體類別)**：**db.t2.micro**。 + **Multi-AZ Deployment (異地同步備份部署)**：**No (否)** + **Allocated Storage (配置儲存體)**：**5** GB + **DB Instance Identifier (資料庫執行個體識別符)**：**nodeexample** + **Master Username (主要使用者名稱)**：**opsworksuser** + **Master Password (主要密碼)**：您選擇的密碼記錄執行個體識別符、使用者名稱、密碼以供稍後使用，接受其他選項的預設設定，然後選擇 **Next (下一步)**。 1. **設定進階設定。** 在 **Configure Advanced Settings (設定進階設定)** 頁面上，指定下列設定： + **資料庫名稱**：**nodeexampledb** + **DB Security Group(s) (資料庫安全群組)**：**AWS-OpsWorks-DB-Master-Server** **注意** **AWS-OpsWorks-DB-Master-Server** 安全群組只會允許您堆疊的執行個體存取資料庫。若您希望直接存取資料庫，請將額外的安全群組連接到 RDS 資料庫執行個體，並搭配適當的傳入規則。如需詳細資訊，請參閱 [Amazon RDS 安全群組](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html)。您也可以透過將執行個體置放在 VPC 中，來控制存取。如需詳細資訊，請參閱[在 VPC 中執行堆疊](workingstacks-vpc.md)。記錄資料庫名稱以供稍後使用，接受其他設定的預設值，然後選擇 **Launch DB Instance (啟動資料庫執行個體)**。下列程序說明如何為此範例建立 Elastic Load Balancing 負載平衡器。如需詳細資訊，請參閱《[Elastic Load Balancing 使用者指南](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elastic-load-balancing.html)》。 **建立負載平衡器** 1. **開啟 Amazon EC2 主控台。** 開啟 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/)，並確保區域設定為美國西部（奧勒岡）。在導覽窗格中，選擇 **Load Balancers (負載平衡器)**，然後選擇 **Create Load Balancer (建立負載平衡器)**。 1. **定義負載平衡器。** 在 **Define Load Balancer (定義負載平衡器)** 頁面上，指定下列設定。 + **名稱** – **Node-LB** + **在內部建立 LB** – **我的預設 VPC** 接受其他選項的預設設定，然後選擇 **Next (下一步)**。 1. **指派安全群組。** 在 **Assign Security Groups (指派安全群組)** 頁面上，指定下列群組： + **default VPC security group (預設 VPC 安全群組)** + **AWS-OpsWorks-nodejs-App-Server** 選擇**下一步**。在 **Configure Security Settings (設定安全設定)** 頁面上，選擇 **Next (下一步)**。您在此範例中不需要使用安全接聽程式。 1. **設定運作狀態檢查。** 在 **Configure Health Check (設定運作狀態檢查)** 頁面上，將 **Ping Path (Ping 路徑)** 設為 **/**，並接受其他設定的預設值。選擇**下一步**。在 **Add EC2 Instances (新增 EC2 執行個體)** 頁面上，選擇 **Next (下一步)**。在**新增標籤**頁面上，選擇**檢閱和建立**。 OpsWorks Stacks 會處理將 EC2 執行個體新增至負載平衡器的任務，在此範例中您不需要標籤。 1. **建立負載平衡器。** 在 **Review (頁面)** 上，選擇 **Create (建立)** 以建立負載平衡器。 ## 建立堆疊您現在已具備所有需要用來建立堆疊的元件。 **建立堆疊** 1. **登入 Stacks OpsWorks 主控台。** 登入 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。 1. **建立堆疊。** 若要建立新的堆疊，請選擇 **Chef 11 stack (Chef 11 堆疊)**，然後指定下列設定。 + – **NodeStack** + **區域** – **美國西部（奧勒岡）** 您可以在任何 AWS 區域中建立堆疊，但我們建議美國西部（奧勒岡）進行教學課程。選擇 **Add Stack (新增堆疊)**。如需堆疊組態設定的詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 1. **使用連接的負載平衡器新增 Node.js App Server layer。** 在 **NodeStack** 頁面上，選擇 **Add a layer (新增 layer)**，然後指定下列設定： + **Layer 類型** – **Node.js 應用程式伺服器** + **Elastic Load Balancer** – **Node-LB** 接受其他設定的預設值，然後選擇 **Add Layer (新增 Layer)**。 1. **將執行個體新增至 layer 並啟動。** 在導覽窗格中選擇 **Instances (執行個體)**，然後新增兩個執行個體至 Rails 應用程式伺服器 layer，如下所示。 1. 在 **Node.js App Server** 下，選擇**新增執行個體**。將 **Size (大小)** 設為 **t2.micro**，接受其他設定的預設值，然後選擇 **Add Instance (新增執行個體)**。 1. 選擇 **\$1Instance (\$1執行個體)**，然後新增第二個 **t2.micro** 執行個體至位於不同子網路中的 layer。這會將執行個體置放在不同的可用區域 (AZ) 中。 1. 選擇 **Add instance (新增執行個體)**。 1. 若要啟動兩個執行個體，請選擇 **Start All Instances (啟動所有執行個體)**。您已將 Elastic Load Balancing 負載平衡器指派給此層。當執行個體進入或離開線上狀態時， OpsWorks Stacks 會自動向負載平衡器註冊或取消註冊執行個體。 **注意** 針對生產堆疊，我們建議您將您的應用程式伺服器執行個體分散到多個 AZ 中。若使用者無法連線到其中一個 AZ，負載平衡器會將傳入流量路由至剩餘區域中的執行個體，讓您的網站可繼續運作。 1. **向堆疊註冊 RDS 資料庫執行個體。** 在導覽窗格中選擇 **Resources (資源)** 並向堆疊註冊 RDS 資料庫執行個體，如下所示。 1. 選擇 **RDS** 標籤，然後選擇 **Show Unregistered RDS DB (顯示未註冊的 RDS 資料庫)** 執行個體。 1. 選擇 **nodeexampledb** 執行個體，然後指定下列設定： + **使用者** – 您在建立執行個體時指定的主要使用者名稱；在此範例中為 **opsworksuser**。 + **密碼** – 您在建立執行個體時指定的主要密碼。 1. 選擇**向 Stack 註冊**，將 RDS 資料庫執行個體新增至堆疊做為 [Amazon RDS 服務層](workinglayers-db-rds.md)。 **警告** OpsWorks Stacks 不會驗證**使用者**或**密碼**值，只會將值傳遞給應用程式。若您輸入不正確，您的應用程式將無法連線至資料庫。若要將 RDS 資料庫執行個體新增至堆疊做為 [Amazon RDS 服務層](workinglayers-db-rds.md)，請選擇**向 Stack 註冊**。 ## 部署應用程式您必須將應用程式存放在遠端儲存庫中。當您部署它時， OpsWorks Stacks 會將程式碼和相關檔案從儲存庫部署到應用程式伺服器執行個體。為了方便起見，此範例使用公有 Amazon Simple Storage Service (Amazon S3) 封存做為儲存庫，但您也可以使用其他幾種儲存庫類型，包括 Git 和 Subversion。如需詳細資訊，請參閱[應用程式來源](workingapps-creating.md#workingapps-creating-source)。 **部署應用程式** 1. **將應用程式封裝在封存檔中。** 建立 `.zip` 目錄和子目錄的 `nodedb` 封存，命名為 nodedb.zip。您也可以使用其他類型的封存檔，包括 gzip、bzip2 和 tarball。請注意， OpsWorks Stacks 不支援未壓縮的 tarball。如需詳細資訊，請參閱[應用程式來源](workingapps-creating.md#workingapps-creating-source)。 1. **將封存檔案上傳至 Amazon S3。** `nodedb.zip` 上傳至 Amazon S3 儲存貯體，將檔案設為公有，然後複製檔案的 URL 以供日後使用。如需如何建立儲存貯體以及上傳檔案的詳細資訊，請參閱[開始使用 Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)。 **注意** OpsWorks Stacks 也可以從 Amazon S3 儲存貯體部署私有檔案，但為了簡單起見，此範例會使用公有檔案。如需詳細資訊，請參閱[應用程式來源](workingapps-creating.md#workingapps-creating-source)。 1. **建立 OpsWorks Stacks 應用程式。** 返回 OpsWorks Stacks 主控台，在導覽窗格中，選擇**應用程式**，然後選擇**新增應用程式**。指定下列設定： + **Name** (名稱) – `NodeDB`。此字串為應用程式的顯示名稱。大多數情況下，您需要應用程式的簡短名稱，Stacks OpsWorks 會透過將所有字元轉換為小寫並移除標點符號，從顯示名稱產生該名稱。針對此範例，短名為 `nodedb`。若要驗證應用程式的短名，在建立應用程式之後，請在 **Apps (應用程式)** 頁面上選擇應用程式以顯示其詳細資訊頁面。 + **類型** – `Node.js`. + **Data source type (資料來源類型)** – `RDS`。 + **資料庫執行個體** – 選擇您先前註冊的 Amazon RDS 資料庫執行個體。 + **Database name (資料庫名稱)** – 指定您先前建立的資料庫名稱，此範例中為 `nodeexampledb`。 + **Repository type (儲存庫類型)** – `Http Archive`。您必須將此儲存庫類型用於公有 Amazon S3 檔案。`S3 Archive` 類型僅用於私有封存。 + **儲存庫 URL** – 封存檔案的 Amazon S3 URL。針對剩餘設定使用預設值，然後按一下 **Add App (新增應用程式)** 以建立應用程式。 1. **部署應用程式。** 前往 **Apps (應用程式)** 頁面，然後在 NodeDB 應用程式的 **Actions (動作)** 資料行中，選擇 **deploy (部署)**。然後選擇**部署**，將應用程式部署到伺服器執行個體。 OpsWorks Stacks 會在每個執行個體上執行部署配方，從儲存庫下載應用程式並重新啟動伺服器。當每個執行個體都有綠色的核取記號，並且 **Status (狀態)** 為 **successful (成功)** 時，部署便已完成，應用程式已準備好開始處理請求。 **注意** 如果部署失敗，請選擇**日誌**欄中**的顯示**以顯示部署的 Chef 日誌。錯誤資訊位於接近底部的位置。 1. **開啟應用程式。** 若要開啟應用程式，請選擇 **Layer (Layer)**，選擇負載平衡器，然後選擇負載平衡器的 DNS 名稱，將 HTTP 請求傳送到負載平衡器。您應該會看到類似下列的內容。 ![\[AWS OpsWorks Node.js example showing RDS endpoint, user credentials, and database details.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/node_walkthrough.png) **注意** OpsWorks Stacks 會在設定期間自動將應用程式部署到新的執行個體。只需要針對線上執行個體進行手動部署。如需詳細資訊，請參閱[部署應用程式](workingapps-deploying.md)。如需部署的一般討論，包含一些更複雜的部署策略，請參閱[管理和部署應用程式與技術指南](best-deploy.md)。 ## 後續步驟？ **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本演練帶領您完成設定簡易 Node.js 應用程式伺服器堆疊的基本操作。以下是有關後續作業的一些建議。 **檢查 Node.js 的內建技術指南** 如果您想要詳細了解執行個體的設定方式，請參閱 layer 的內建技術指南 [opsworks\$1nodejs](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_nodejs)，其中包含 Stacks OpsWorks 用來安裝和設定軟體的配方和相關檔案，以及內建[部署技術指南](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/deploy)，其中包含 OpsWorks Stacks 用來部署應用程式的配方。 **自訂伺服器組態** 範例堆疊相當基本。針對生產用途，您可以會希望自訂堆疊。如需詳細資訊，請參閱[自訂 OpsWorks Stacks](customizing.md)。 **新增 SSL 支援** 您可以為您的應用程式啟用 SSL 支援，並在建立應用程式時為 OpsWorks Stacks 提供適當的憑證。 OpsWorks Stacks 接著會在適當的目錄中安裝憑證。如需詳細資訊，請參閱[使用 SSL](workingsecurity-ssl.md)。 **新增記憶體內快取** 生產層級網站通常會透過在記憶體內鍵/值存放區 (例如 Redis 或 Memcache) 中快取資料來改善效能。您可以搭配 Stacks OpsWorks 堆疊使用。如需詳細資訊，請參閱[ElastiCache Redis](other-services-redis.md)及[Memcached](workinglayers-mem.md)。 **使用更複雜的部署策略** 範例使用簡易的應用程式部署策略，將更新同時部署到每個執行個體。這種方法非常簡單且快速，但沒有錯誤的餘地。若部署失敗或更新發生任何問題，每個您生產堆疊中的執行個體都會受到影響，可能中斷或停用您的網站，直到您修正問題為止。如需部署策略的詳細資訊，請參閱[管理和部署應用程式與技術指南](best-deploy.md)。 **擴展 Node.js 應用程式伺服器層** 您可以透過各種方式延伸 layer。例如，您可以實作配方，以在執行個體上執行指令碼，或實作 Chef 部署勾點以自訂應用程式部署。如需詳細資訊，請參閱[擴充 Layer](workingcookbook-extend.md)。 **定義環境變數** 您可以透過定義關聯應用程式的環境變數，來將資料傳遞給您的應用程式。當您部署應用程式時， OpsWorks Stacks 會匯出這些變數，以便您可以從應用程式存取它們。如需詳細資訊，請參閱[使用環境變數](apps-environment-vars.md)。 # 自訂 OpsWorks Stacks **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 內建 layer 提供的標準功能足以用於許多用途。不過，您可能會遇到下列一或多種情況： + 內建 layer 的標準組態雖足夠但不理想，您希望針對您的特定需求最佳化。例如，您可能想要透過指定自己的值來調整靜態 Web 伺服器層的 Nginx 伺服器組態，例如工作者程序數目上限或`keepalivetimeout`值。 + 內建 layer 的功能很好，但您想要安裝額外的套件或執行一些自訂安裝程式碼擴展它。例如，您可能也想要安裝 Redis 伺服器來擴展 PHP App Server layer。 + 您有任何內建 layer 都不處理的要求。例如， OpsWorks Stacks 不包含某些熱門資料庫伺服器的內建層。您可以建立自訂 layer，在 layer 的執行個體上安裝這些伺服器。 + 您執行的是 Windows 堆疊，它只支援自訂 layer。 OpsWorks Stacks 提供多種自訂 layer 的方式，以符合您的特定需求。下列範例依增加複雜度和功能的順序列出： **注意** 這些方法有部分只適用於 Linux 堆疊。請參閱以下主題以了解詳細資訊。 + 使用自訂 JSON OpsWorks 覆寫預設的 Stacks 設定。 + 使用覆寫預設 Stacks 設定的屬性檔案實作自訂 Chef OpsWorks 技術指南。 + 使用覆寫或擴展預設 Stacks 範本的範本實作自訂 Chef OpsWorks 技術指南。 + 使用執行 shell 指令碼的簡單配方實作自訂的 Chef 技術指南。 + 使用執行任務 (例如建立和設定目錄、安裝套件、建立組態檔案、部署應用程式等等) 的配方，實作自訂的 Chef 技術指南。您也可以覆寫配方，視堆疊的 Chef 版本和作業系統而定。 + 使用 Chef 0.9 和 11.4 堆疊，您無法透過以相同的技術指南和配方名稱實作自訂配方，來覆寫內建配方。對於每個生命週期事件， OpsWorks Stacks 一律會先執行內建配方，接著執行任何自訂配方。由於這些 Chef 版本不會執行兩次有相同技術指南和配方名稱的配方，所以內建配方優先，不執行自訂配方。 + 您可以在 Chef 11.10 堆疊上覆寫內建配方。如需詳細資訊，請參閱[技術指南安裝與優先順序](workingcookbook-chef11-10.md#workingcookbook-chef11-10-override)。 + 您無法在 Windows 堆疊上覆寫內建配方。 Stacks 處理 Chef 為 Windows OpsWorks 堆疊執行的方式不允許覆寫內建配方。 **注意** 由於許多技術都使用自訂技術指南，[技術指南和配方](workingcookbook.md)如果您尚未熟悉技術指南實作，應先閱讀。 [技術指南基本概念](cookbooks-101-basics.md)提供實作自訂技術指南的詳細教學簡介，並[實作 Stacks OpsWorks 的技術指南](cookbooks-101-opsworks.md)涵蓋如何實作 Stacks OpsWorks 執行個體技術指南的一些詳細資訊。 **Topics** + [透過覆寫屬性自訂 OpsWorks Stacks 組態](workingcookbook-attributes.md) + [使用自訂範本擴展 OpsWorks Stacks 組態檔案](workingcookbook-template-override.md) + [擴充 Layer](workingcookbook-extend.md) + [建立自訂 Tomcat 伺服器 Layer](create-custom.md) + [堆疊組態及部署屬性](workingcookbook-json.md) # 透過覆寫屬性自訂 OpsWorks Stacks 組態 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 對於 Windows 堆疊和 Chef 12 Linux 堆疊， OpsWorks Stacks 會針對內建配方和自訂配方使用個別的 Chef 執行。這表示您無法使用本節討論的技術覆寫 Windows 堆疊和 Chef 12 Linux 堆疊的內建屬性。配方和範本取決於執行個體的各種 Chef 屬性，或堆疊限定的資訊 (例如 layer 組態或應用程式伺服器設定)。這些屬性有幾個來源： + **自訂 JSON** – 您可以在建立、更新或複製堆疊或部署應用程式時選擇性地指定自訂 JSON 屬性。 + **堆疊組態屬性** –OpsWorks 堆疊會定義這些屬性以保留堆疊組態資訊，包括您透過主控台設定指定的資訊。 + **部署屬性** – AWS OpsWorks 會定義部署事件的部署相關屬性。 + **技術指南屬性** – 內建和自訂技術指南通常包含一或多個[屬性檔案](workingcookbook-installingcustom-components-attributes.md)，其中包含代表技術指南特定值的屬性，例如應用程式伺服器組態設定。 + **Chef**–Chef 的 [Ohai 工具](http://docs.chef.io/resource_ohai.html)定義了代表各種系統組態設定的屬性，例如 CPU 類型和已安裝的記憶體。如需堆疊組態、部署屬性和內建技術指南屬性的完整清單，請參閱[堆疊組態及部署屬性：Linux](attributes-json-linux.md) 和[內建技術指南屬性](attributes-recipes.md)。如需 Ohai 屬性的詳細資訊，請參閱 [Ohai](https://docs.chef.io/ohai.html)。當部署或設定等[生命週期事件](workingcookbook-events.md)發生時，或是您執行像是 [ 或 ](workingstacks-commands.md) 等`execute_recipes`堆疊命令`update_packages`時， OpsWorks Stacks 會執行下列作業： + 將對應的命令傳送到每個受影響之執行個體的代理程式。代理程式會執行適當的配方。例如，針對部署事件，代理程式會執行內建的部署配方，其後跟隨任何自訂部署配方。 + 將任何自訂 JSON 和部署屬性與堆疊組態屬性合併，然後在執行個體上安裝他們。來自自訂 JSON、堆疊組態和部署屬性、技術指南屬性和 Ohai 屬性的屬性會合併成一個「*節點物件*」，該物件會將屬性值提供給配方。針對堆疊組態屬性，執行個體基本上是無狀態的，包含任何自訂 JSON。當您執行部署或堆疊命令時，關聯的配方會使用以命令下載的堆疊組態屬性。 **Topics** + [屬性優先順序](workingcookbook-attributes-precedence.md) + [使用自訂 JSON 覆寫屬性](workingcookbook-json-override.md) + [使用自訂技術指南屬性覆寫 OpsWorks Stacks 屬性](workingcookbook-cookbook-attributes.md) # 屬性優先順序 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若屬性的定義是唯一的，Chef 會直接將其併入節點物件。但是，任何屬性來源都可以定義任何屬性，因此相同的屬性可能會有值不同的多個定義。例如，內建的 `apache2` 技術指南定義了 `node[:apache][:keepalive]`，但您也可以在自訂 JSON 或自訂技術指南中定義該屬性。若屬性具有多個定義，他們會按照稍後說明的順序進行評估，並且節點物件會接收到具有最高優先順序的定義。一個屬性定義如下： ``` node.type[:attribute][:sub_attribute][:...]=value ``` 如果屬性有多個定義，類型會決定哪個定義具有優先順序，且該定義會併入節點物件中。 OpsWorks Stacks 會使用下列屬性類型： + **default** – 這是最常見的類型，基本上表示「如果尚未定義屬性，請使用此值」。若所有屬性的定義皆為 `default` 類型，評估順序中的第一個定義便具有優先順序，其餘值則會遭到忽略。請注意， Stacks OpsWorks 會將所有堆疊組態和部署屬性定義設定為 `default`類型。 + 具有此類型的 **normal**–Attributes 會覆寫先前在評估順序中定義的任何 `default`或 `normal` 屬性。例如，若第一個屬性是來自內建的技術指南，並且具有 `default` 類型，而第二個則是具有 `normal` 類型的使用者定義屬性，則第二個定義便具有優先順序。 + **set** – 這是您在舊版技術指南中可能看到的已棄用類型。它已由具有相同優先順序的 `normal` 取代。 Chef 支援數種額外的屬性類型，包含優先順序高於任何其他屬性定義的 `automatic` 類型。由 Chef 的 Ohai 工具產生的屬性定義全部皆為 `automatic` 類型，因此他們基本上等同於唯讀。這通常不是問題，因為沒有理由覆寫它們，而且它們與 OpsWorks Stacks 的屬性不同。不過，建議您小心地為自訂技術指南屬性命名，使其與 Ohai 屬性相異。如需詳細資訊，請參閱[關於屬性](http://docs.chef.io/attributes.html)。 **注意** Ohai 工具為您可以從命令列執行的可執行檔。若要列出執行個體的 Ohai 屬性，請登入執行個體並在終端機視窗中執行 `ohai`。請注意，它會產生非常長的輸出。以下為將各種屬性定義併入節點物件的步驟： 1. 將任何自訂堆疊組態屬性併入堆疊組態和部署屬性。您可為堆疊或特定部署設定自訂 JSON 屬性。他們會位於評估的第一優先順序，基本上等同於 `normal` 類型。若一或多個堆疊組態屬性也在自訂 JSON 中定義，則自訂 JSON 的值會具有優先順序。否則 OpsWorks Stacks 會直接將自訂 JSON 屬性併入堆疊組態。 1. 將任何部署自訂 JSON 屬性併入堆疊組態和部署屬性。部署自訂 JSON 屬性也等同於 `normal` 類型，因此他們會優先於內建和自訂堆疊組態 JSON 及內建部署 JSON。 1. 將堆疊組態和部署屬性合併成執行個體的節點物件。 1. 將執行個體的內建技術指南屬性合併成節點物件。內建技術指南屬性全部皆為 `default` 類型。如果堆疊組態和部署屬性中也定義了一或多個內建技術指南屬性，通常是因為您使用自訂 JSON 定義它們，則堆疊組態定義優先於內建技術指南定義。所有其他內建技術指南屬性也會直接併入節點物件。 1. 將執行個體的自訂技術指南屬性合併成節點物件。自訂技術指南屬性通常不是 `normal` 就是 `default` 類型。唯一屬性會併入節點物件。如果步驟 1–3 中也定義了任何自訂技術指南屬性（通常是因為您使用自訂 JSON 定義了它們），則優先順序取決於自訂技術指南屬性的類型： + 步驟 1-3 中定義的屬性優先於自訂技術指南`default`屬性。 + 自訂 c ookbook `normal` 屬性優先於步驟 1–3 的定義。 **重要** 請勿使用自訂技術指南的 `default` 屬性覆寫堆疊組態或內建技術指南屬性。由於自訂技術指南屬性會在最後評估，`default` 屬性具有最低的優先順序，因此無法覆寫任何內容。 # 使用自訂 JSON 覆寫屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 由於 OpsWorks Stacks 處理 Chef 的執行方式與 Linux 堆疊不同，因此您無法針對 Windows 堆疊使用本節中討論的技術。覆寫 OpsWorks Stacks 屬性的最簡單方法是在自訂 JSON 中定義它，其優先順序高於堆疊組態和部署屬性，以及內建和自訂技術指南`default`屬性。如需詳細資訊，請參閱[屬性優先順序](workingcookbook-attributes-precedence.md)。 **重要** 建議您小心覆寫堆疊組態和部署屬性。例如：覆寫 `opsworks` 命名空間中的屬性可能會影響內建配方。如需詳細資訊，請參閱[堆疊組態及部署屬性](workingcookbook-json.md)。您也可以使用自訂 JSON 定義唯一屬性，通常是將資料傳遞到您的自訂配方。屬性會直接併入節點物件，並且配方可以透過使用標準 Chef 節點語法參考他們。 ## 如何指定自訂 JSON 若要使用自訂 JSON 覆寫屬性值，您必須先判斷屬性的完整屬性名稱。您接著會建立包含您希望覆寫之屬性的 JSON 物件，將其設為您喜好的值。為了方便起見，[堆疊組態及部署屬性：Linux](attributes-json-linux.md) 和[內建技術指南屬性](attributes-recipes.md)文件常會使用堆疊組態、部署和內建技術指南屬性，包含其完整名稱。物件的父系和子系關聯必須對應到適當的完整 Chef 節點。例如，假設您希望變更以下 Apache 屬性： + 節點為 [ 並且預設值為 `keepalivetimeout` 的 ](attributes-recipes-apache.md#attributes-recipes-apache-keep-timeout)`node[:apache][:keepalivetimeout]``3` 屬性。 + 節點為 `logrotate` 並且預設值為 [ 的 `schedule`](attributes-recipes-apache.md#attributes-recipes-apache-log-schedule)`node[:apache][:logrotate][:schedule]``"daily"` 屬性。若要覆寫屬性並將值分別設為 `5` 和 `"weekly"`，您會使用下列自訂 JSON： ``` { "apache" : { "keepalivetimeout" : 5, "logrotate" : { "schedule" : "weekly" } } } ``` ## 何時指定自訂 JSON 您可以為下列任務指定自訂 JSON： + [建立新的堆疊](workingstacks-creating.md) + [更新堆疊](workingstacks-edit.md) + [執行堆疊命令](workingstacks-edit.md) + [複製堆疊](workingstacks-cloning.md) + [部署應用程式](workingapps-deploying.md) 對於每個任務， OpsWorks Stacks 會將自訂 JSON 屬性與堆疊組態和部署屬性合併，並將其傳送至執行個體，以合併至節點物件。但是，請注意以下內容： + 若您在建立、複製或更新堆疊時指定自訂 JSON，針對後續生命週期事件和堆疊命令，屬性會合併至堆疊組態和部署屬性。 + 若您為部署指定自訂 JSON，屬性只會針對對應的事件合併至堆疊組態和部署屬性。若您希望針對後續部署使用那些自訂屬性，您必須再次明確指定自訂 JSON。請務必記得，屬性只有在由配方使用時才會影響執行個體。若您覆寫屬性值，但是沒有任何後續的配方參考該屬性，則變更便不具有效果。您必須確保在關聯配方執行前傳送自訂 JSON，或是重新執行適當的配方。 ## 自訂 JSON 最佳實務您可以使用自訂 JSON 覆寫任何 OpsWorks Stacks 屬性，但手動輸入資訊有些麻煩，而且不在任何來源控制下。自訂 JSON 最適合用於以下目的： + 當您希望覆寫少量的屬性，並且不需要使用自訂技術指南時。透過自訂 JSON，您可以免於僅為了覆寫幾個屬性而設定及維護技術指南儲存庫的額外負荷。 + 敏感性值，例如密碼或身分驗證金鑰。技術指南屬性存放於儲存庫中，因此任何敏感性資訊都會暴露在洩漏的風險中。相反的，請使用 dummy 值定義屬性，並使用自訂 JSON 設定真正的值。 + 值應不同。例如，建議的實務是使用獨立的開發和預備堆疊支援您的生產堆疊。假設這些堆疊支援接受付款的應用程式。若您使用自訂 JSON 指定付款端點，您可以為您的預備堆疊指定測試 URL。當您準備好將更新後的堆疊遷移至您的生產堆疊時，您可以使用相同的技術指南，並使用自訂 JSON 將付款端點設為生產 URL。 + 特定堆疊或部署命令專屬的值。 # 使用自訂技術指南屬性覆寫 OpsWorks Stacks 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 對於 Windows 堆疊， OpsWorks Stacks 會針對內建配方和自訂配方使用個別的 Chef 執行。這表示您無法使用本節討論的技術覆寫 Windows 堆疊的內建屬性。自訂 JSON 是覆寫 OpsWorks Stacks 堆疊組態和內建技術指南屬性的便利方式，但有一些限制。特別是您必須為每一次的使用手動輸入自訂 JSON，因此您可用來管理定義的強固方法。較佳的方法通常是使用自訂技術指南屬性檔案覆寫內建的屬性。這樣做可讓您將定義置放在來源控制之下。使用自訂屬性檔案覆寫 OpsWorks Stacks 定義的程序非常簡單。 **覆寫 OpsWorks Stacks 屬性定義** 1. 設定技術指南儲存庫，如[技術指南和配方](workingcookbook.md)中所述。 1. 使用與內建技術指南相同的名稱建立技術指南，其中包含您希望覆寫的屬性。例如，若要覆寫 Apache 屬性，技術指南的名稱應為 apache2。 1. 將一個 `attributes` 資料夾新增至技術指南，並在該資料夾中新增一個名為 `customize.rb` 的檔案。 1. 針對每一個內建技術指南中您希望覆寫的屬性，將屬性定義新增至檔案，並設為您喜好的值。屬性必須是 `normal` 類型或更高版本，並且與對應的 OpsWorks Stacks 屬性具有完全相同的節點名稱。如需 OpsWorks Stacks 屬性的詳細清單，包括節點名稱，請參閱 [堆疊組態及部署屬性：Linux](attributes-json-linux.md)和 [內建技術指南屬性](attributes-recipes.md)。如需屬性和屬性檔案的詳細資訊，請參閱[關於屬性檔案](http://docs.chef.io/attributes.html)。 **重要** 您的屬性必須是`normal`類型才能覆寫 OpsWorks Stacks 屬性；`default`類型沒有優先順序。例如，若您的 `customize.rb` 檔案包含 `default[:apache][:keepalivetimeout] = 5` 屬性定義，內建 `apache.rb` 屬性檔案中的對應屬性會先受到評估，並取得優先順序。如需詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 1. 為每個內建技術指南重複步驟 2 – 4，其中包含您要覆寫的屬性。 1. 為您的堆疊啟用自訂技術指南，並提供 Stacks OpsWorks 將技術指南下載至堆疊執行個體所需的資訊。如需詳細資訊，請參閱[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)。 **注意** 如需此程序的完整演練，請參閱[覆寫內建屬性](cookbooks-101-opsworks-attributes.md)。後續生命週期事件、部署命令和堆疊命令所使用的節點物件現在將包含您的屬性定義，而不是 OpsWorks Stacks 值。例如，若要覆寫`keepalivetimeout` 中討論的內建 Apache `logrotate schedule` 和 [如何指定自訂 JSON](workingcookbook-json-override.md#workingcookbook-json-override-specify) 設定，請將 `apache2` 技術指南新增至您的儲存庫，然後將 `customize.rb` 檔案新增至技術指南的 `attributes` 資料夾，並帶有以下內容。 ``` normal[:apache][:keepalivetimeout] = 5 normal[:apache][:logrotate][:schedule] = 'weekly' ``` **重要** 您不應透過修改相關聯的內建屬性檔案複本來覆寫 OpsWorks Stacks 屬性。假設您將 `apache.rb` 複製到您的 `apache2/attributes` 資料夾並修改其部分設定，您基本上便已覆寫內建檔案中的每個屬性。配方會使用您複本中的屬性定義，並忽略內建檔案。若 OpsWorks Stacks 稍後修改了內建屬性檔案，配方將無法存取變更，除非您手動更新您的複本。為避免這種情況，所有內建的技術指南都包含一個空白的 `customize.rb` 屬性檔案，為所有透過 `include_attribute` 指示詞之模組的必要項目。透過覆寫您 `customize.rb` 複本中的屬性，您只會影響那些特定的屬性。配方會從內建屬性檔案取得任何其他的屬性值，並自動取得任何您未覆寫之屬性的目前值。這種方法可協助您將您技術指南儲存庫中的屬性維持在較小的數目，減少您的維護額外負荷，並使未來的升級更容易管理。 # 使用自訂範本擴展 OpsWorks Stacks 組態檔案 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 由於 OpsWorks Stacks 處理 Chef 的執行方式與 Linux 堆疊不同，因此您無法針對 Windows 堆疊使用本節中討論的技術。 OpsWorks Stacks 使用範本來建立組態檔案等檔案，這些檔案通常取決於許多設定的屬性。如果您使用自訂 JSON 或自訂技術指南屬性來覆寫 OpsWorks Stacks 定義，您偏好的設定會併入組態檔案中，以取代 OpsWorks Stacks 設定。不過， OpsWorks Stacks 不一定會為每個可能的組態設定指定屬性；它接受某些設定的預設值，並直接在範本中硬式編碼其他設定。如果沒有對應的 Stacks 屬性，則無法使用自訂 JSON OpsWorks 或自訂技術指南屬性來指定偏好的設定。您可以藉由建立自訂範本，來擴展組態檔案以包含額外組態設定。然後，您可以將所需的任何組態設定或其他內容新增至該檔案，並覆寫任何硬式編碼的設定。如需範本的詳細資訊，請參閱[範本](workingcookbook-installingcustom-components-templates.md)。 **注意** 您可以覆寫任何內建範本，但 opsworks-agent.monitrc.erb「除外」**。 **建立自訂範本** 1. 使用與內建技術指南相同的結構和目錄名稱來建立技術指南。接著，在適當的目錄中，使用您想要自訂之內建範本的相同結構和目錄名稱，來建立範本檔案。例如，若要使用自訂範本以擴展 Apache `httpd.conf` 組態檔案，您必須在儲存庫中實作 `apache2` 技術指南，且您的範本檔案必須為 `apache2/templates/default/apache.conf.erb`。使用完全相同的名稱可讓 OpsWorks Stacks 辨識自訂範本，並使用它而非內建範本。最簡單的方法是從[內建技術指南的 GitHub 儲存庫](https://github.com/aws/opsworks-cookbooks)，將內建的範本檔案複製到您的技術指南，並視需要修改。 **重要** 除了您想要自訂的範本檔案以外，請不要從內建的技術指南複製任何檔案。其他類型的技術指南檔案 (例如配方) 複本會建立重複的 Chef 資源，並可能造成錯誤。技術指南也可以包含自訂屬性、配方和相關的檔案，但它們的檔案名稱不應與內建的檔案名稱重複。 1. 自訂範本檔案以產生符合您要求的組態檔案。您可以新增更多設定、刪除現有的設定、取代硬式編碼的屬性等。 1. 如果您尚未執行，請編輯堆疊設定以啟用自訂技術指南，並指定您的技術指南儲存庫。如需詳細資訊，請參閱[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)。 **注意** 如需此程序的完整演練，請參閱[覆寫內建範本](cookbooks-101-opsworks-templates.md)。您不需要實作任何配方或[將配方新增至 layer 組態](workingcookbook-assigningcustom.md)，即可覆寫範本。 OpsWorks Stacks 一律會執行內建配方。當您執行配方以建立組態檔案時，它會自動使用您的自訂範本，而不是使用內建的範本。 **注意** 如果 OpsWorks Stacks 對內建範本進行任何變更，您的自訂範本可能會變得不同步且無法正常運作。例如，假設您的範本參考相依檔案，且檔案名稱變更。 OpsWorks Stacks 不會經常進行此類變更，當範本確實變更時，它會列出變更，並讓您選擇升級至新版本。您應該監控 OpsWorks Stacks 儲存庫的變更，並視需要手動更新範本。 # 擴充 Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。針對透過修改 OpsWorks Stacks 屬性或自訂範本處理的項目以外的項目，您有時需要自訂內建 layer。例如，假設您需要建立符號連結、設定檔案或資料夾模式、安裝額外的套件，以此類推。您必須擴充自訂 layer，以提供高於最少功能的功能。在該情況下，您需要實作一或多個具有配方的自訂技術指南來處理自訂任務。本主題提供如何使用配方來擴充 layer 的一些範例。如果您是第一次使用 Chef，建議您先閱讀[技術指南 101](cookbooks-101.md)，該教學介紹如何實作技術指南以執行各種常見任務的基本概念。如需如何實作自訂 layer 的詳細範例，請參閱[建立自訂 Tomcat 伺服器 Layer](create-custom.md)。 **Topics** + [使用配方執行指令碼](workingcookbook-extend-scripts.md) + [使用 Chef 部署勾點](workingcookbook-extend-hooks.md) + [在 Linux 執行個體上執行 Cron 任務](workingcookbook-extend-cron.md) + [在 Linux 執行個體上安裝和設定套件](workingcookbook-extend-package.md) # 使用配方執行指令碼 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果您的現有指令碼執行所需的自訂任務，則擴充 layer 的最簡單方式實作通常是實作簡單配方來執行指令碼。您接著可以將配方指派給適當的生命週期事件 (一般是安裝或部署)，或使用 `execute_recipes` 堆疊命令手動執行配方。下列範例會在 Linux 執行個體上執行 Shell 指令碼，但您可以將相同的方式用於其他類型的指令碼 (包括 Windows PowerShell 指令碼)。 ``` cookbook_file "/tmp/lib-installer.sh" do source "lib-installer.sh" mode 0755 end execute "install my lib" do command "sh /tmp/lib-installer.sh" end ``` `cookbook_file` 資源代表存放在技術指南 `files` 目錄之子目錄中的檔案，並將檔案傳輸至執行個體上的指定位置。此範例會將 Shell 指令碼 `lib-installer.sh` 傳輸至執行個體的 `/tmp` 目錄，並將檔案的模式設定為 `0755`。如需詳細資訊，請參閱 [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file)。 `execute` 資源代表命令 (如 Shell 命令)。此範例執行 `lib-installer.sh`。如需詳細資訊，請參閱 [execute](https://docs.chef.io/chef/resources.html#execute)。您也可以將指令碼併入配方來執行指令碼。下列範例會執行 bash 指令碼，但 Chef 也支援 Csh、Perl、Python 和 Ruby。 ``` script "install_something" do interpreter "bash" user "root" cwd "/tmp" code <<-EOH #insert bash script EOH end ``` `script` 資源代表指令碼。此範例指定 bash 解譯器、將使用者設定為 `"root"`，並將工作目錄設定為 `/tmp`。它接著會執行 `code` 區塊中的 bash 指令碼，可視需要包括多行。如需詳細資訊，請參閱 [script](https://docs.chef.io/chef/resources.html#script)。如需如何使用配方執行指令碼的詳細資訊，請參閱[範例 7：執行命令和指令碼](cookbooks-101-basics-commands.md)。如需如何在 Windows 執行個體上執行 PowerShell 指令碼的範例，請參閱[執行 Windows PowerShell 指令碼](cookbooks-101-opsworks-opsworks-powershell.md)。 # 使用 Chef 部署勾點 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。部署的自訂方式是實作自訂配方來執行所需任務，並將它指派給適當 layer 的部署事件。替代且有時更簡單的方法，特別是當您不需要實作技術指南用於其他用途時，就是使用 Chef 部署勾點來執行自訂程式碼。此外，自訂部署配方會在內建配方已執行部署之後執行。部署勾點可讓您在部署期間互動，例如，從儲存庫簽出應用程式碼之後，但在重新啟動 Apache 之前。 Chef 會以四個階段部署應用程式： + **結帳** – 從儲存庫下載檔案 + **Migrate** – 視需要執行遷移 + **Symlink** – 建立符號連結 + **重新啟動** – 重新啟動應用程式 Chef 部署勾點提供一種簡單的方法，選擇性地在每個階段完成之後執行使用者所提供的 Ruby 應用程式來自訂部署。若要使用部署勾點，請實作一或多個 Ruby 應用程式，並將它們放入您應用程式的 `/deploy` 目錄中 (如果您的應用程式沒有 `/deploy` 目錄，則請在 `APP_ROOT` 層級建立該目錄)。應用程式必須具有下列其中一個名稱，以決定其何時執行。 + `before_migrate.rb` 是在 Checkout (簽出) 階段完成之後但在 Migrate (遷移) 之前執行。 + `before_symlink.rb` 是在 Migrate (遷移) 階段完成之後但在 Symlink (符號連結) 之前執行。 + `before_restart.rb` 是在 Symlink (符號連結) 階段完成之後但在 Restart (重新啟動) 之前執行。 + `after_restart.rb` 是在 Restart (重新啟動) 階段完成之後執行。 Chef 部署勾點使用標準節點語法，即可存取節點物件，就像配方一樣。部署勾點也可以存取您所指定之任何[應用程式環境變數](workingapps-creating.md#workingapps-creating-environment)的值。不過，您必須使用 `new_resource.environment["VARIABLE_NAME"] ` 存取變數的值，而不是 `ENV["VARIABLE_NAME"]`。 # 在 Linux 執行個體上執行 Cron 任務 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Linux Cron 任務會指示 Cron 協助程式依指定的排程執行一或多個命令。例如，假設您的堆疊支援 PHP 電子商務應用程式。您可以設定 cron 任務，讓伺服器在每週的指定時間將銷售報告傳送給您。如需 cron 的詳細資訊，請參閱 Wikipedia 上的 [cron](http://en.wikipedia.org/wiki/Cron)。如需如何直接在 Linux 電腦或執行個體上執行 cron 任務的詳細資訊，請參閱 Indiana University 知識庫網站上的 [What are cron and crontab, and how do I use them? (什麼是 cron 和 crontab 以及如何使用它們？)](https://kb.iu.edu/d/afiz)。雖然您可以使用 SSH 連線 `cron` 任務並編輯其 `crontab` 項目以在個別 Linux 執行個體上手動設定它們，但是 OpsWorks Stacks 的主要優點是您可以指示它跨整 layer 的執行個體執行任務。下列程序說明如何在 PHP App Server layer 的執行個體上設定`cron`任務，但您可以將相同的方法與任何 layer 搭配使用。 **若要在 layer 執行個體上設定 `cron` 任務** 1. 實作配方具有已設定任務之 `cron` 資源的技術指南。此範例假設配方命名為 `cronjob.rb`；稍後會說明實作詳細資訊。如需技術指南和配方的詳細資訊，請參閱[技術指南和配方](workingcookbook.md)。 1. 在您的堆疊上安裝技術指南。如需詳細資訊，請參閱[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)。 1. 讓 OpsWorks Stacks 透過將配方指派給下列生命週期事件，在 layer 的執行個體上自動執行配方。如需詳細資訊，請參閱[自動執行配方](workingcookbook-assigningcustom.md)。 + **設定** – 指派給`cronjob.rb`此事件會指示 OpsWorks Stacks 在所有新執行個體上執行配方。 + **部署** – 當您將應用程式部署或重新部署至 layer 時，指派`cronjob.rb`至此事件會指示 OpsWorks Stacks 在所有線上執行個體上執行配方。您也可以使用 `Execute Recipes` 堆疊命令手動在線上執行個體上執行配方。如需詳細資訊，請參閱[執行堆疊命令](workingstacks-commands.md)。以下是 `cronjob.rb` 範例，可設定 Cron 任務一週一次執行使用者實作的 PHP 應用程式，以從伺服器收集銷售資料，並透過郵件傳送報告。如需如何使用 cron 資源的更多範例，請參閱 [cron](https://docs.chef.io/chef/resources.html#cron)。 ``` cron "job_name" do hour "1" minute "10" weekday "6" command "cd /srv/www/myapp/current && php .lib/mailing.php" end ``` `cron` 是代表 `cron` 任務的 Chef 資源。當 OpsWorks Stacks 在執行個體上執行配方時，相關聯的提供者會處理設定任務的詳細資訊。 + `job_name` 是 `cron` 任務的使用者定義名稱，例如 `weekly report`。 + `hour`/`minute`/`weekday` 指定何時應該執行命令。此範例會在每週六的上午 1:10 執行命令。 + `command` 指定要執行的命令。此範例執行兩個命令。第一個導覽至 `/srv/www/myapp/current` 目錄。第二個執行使用者實作的 `mailing.php` 應用程式，以收集銷售資料並傳送報告。 **注意** `bundle` 命令預設不會與 `cron` 任務搭配運作。原因是 OpsWorks Stacks 在 `/usr/local/bin`目錄中安裝 Bundler。若要搭配使用 `bundle` 與 `cron` 任務，您必須將路徑 `/usr/local/bin` 明確地新增至 Cron 任務。此外，因為 \$1PATH 環境變數可能不會在 `cron` 任務中擴展，所以最佳實務是將任何必要的路徑資訊明確地新增至任務，而不依賴擴展 \$1PATH 變數。下列範例顯示兩種在 `cron` 任務中使用 `bundle` 的方式。 ``` cron "my first task" do path "/usr/local/bin" minute "*/10" command "cd /srv/www/myapp/current && bundle exec my_command" end ``` ``` cron_env = {"PATH" => "/usr/local/bin"} cron "my second task" do environment cron_env minute "*/10" command "cd /srv/www/myapp/current && /usr/local/bin/bundle exec my_command" end ``` 如果您的堆疊有多個應用程式伺服器，`cronjob.rb`則指派給 PHP App Server layer 的生命週期事件可能不是理想的方法。例如，配方會在 layer 的所有執行個體上執行，因此您會收到多份報告。較佳的方式是使用自訂 layer，確保只有一部伺服器傳送報告。 **只在 layer 的其中一個執行個體上執行配方** 1. 建立自訂 layer (例如稱為 PHPAdmin)，並將 `cronjob.rb` 指派給其安裝和部署事件。自訂 layer 不一定需要執行很多操作。在此情況下，PHPAdmin 只會在其執行個體上執行一個自訂配方。 1. 將其中一個 PHP App Server 執行個體指派給 AdminLayer。如果執行個體屬於多個 layer， OpsWorks Stacks 會執行每個 layer 的內建和自訂配方。由於只有一個執行個體屬於 PHP App Server 和 PHPAdmin layer，因此 `cronjob.rb`只會在該執行個體上執行，而且您只會收到一個報告。 # 在 Linux 執行個體上安裝和設定套件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。內建 layer 只支援特定套件。如需詳細資訊，請參閱[層](workinglayers.md)。您可以安裝其他套件 (例如 Redis 伺服器)，方法是實作自訂配方來處理相關的安裝、組態和部署任務。在某些情況下，最佳方式是擴充內建 layer，讓它在其執行個體上安裝套件以及 layer 的標準套件。例如，如果您的堆疊支援 PHP 應用程式，而且您想要包含 Redis 伺服器，則除了 PHP 應用程式伺服器之外，您還可以擴展 PHP App Server layer 在 layer 的執行個體上安裝和設定 Redis 伺服器。套件安裝配方一般需要執行任務，如下所示： + 建立一或多個目錄，並設定其模式。 + 從範本建立組態檔案。 + 在執行個體上執行安裝程式來安裝套件。 + 啟動一或多個服務。如需如何安裝 Tomcat 伺服器的範例，請參閱[建立自訂 Tomcat 伺服器 Layer](create-custom.md)。本主題說明如何設定自訂 Redis layer，但您可以使用更多相同的程式碼，以在內建 layer 上安裝和設定 Redis。如需如何安裝其他套件的範例，請參閱內建技術指南，網址為 https：//[https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks)。 # 建立自訂 Tomcat 伺服器 Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題說明如何實作 Linux 堆疊的自訂 layer。不過，基本原則和部分程式碼經改寫後也能用於實作 Windows 堆疊的自訂 layer，特別是應用程式部署一節的內容。在 Stacks OpsWorks 執行個體上使用非標準套件的最簡單方法是[擴展現有的 layer](workingcookbook-extend-package.md)。但是，此方法會在 layer 的執行個體上同時安裝及執行標準和非標準套件，而這並非是您所想要的。有一種要求較高也更強大的方式，便是實作自訂 layer，讓您幾乎可以完全控制 layer 的執行個體，包含下列項目： + 要安裝的套件 + 每個套件的設定方式 + 從儲存庫將應用程式部署到執行個體的方式無論您是使用主控台還是 API，您建立和管理自訂 layer 的方式與其他 layer 幾乎一模一樣，如[自訂 Layer](workinglayers-custom.md)所述。但是，自訂 layer 的內建配方會執行一些非常基本的任務，例如安裝 Ganglia 用戶端以將指標報告給 Ganglia 主機。若要使自訂 layer 執行個體不僅具有最低限度的功能，您必須使用 Chef 配方和相關檔案實作一或多個自訂技術指南，以處理安裝及設定套件、部署應用程式等任務。但您不一定需要從頭開始實作所有東西。例如，若您在其中一個標準儲存庫中存放應用程式，您可以使用內建的部署配方處理在 layer 的執行個體上安裝應用程式的大部分工作。 **注意** 如果您是第一次使用 Chef，建議您先閱讀[技術指南 101](cookbooks-101.md)，該教學介紹如何實作技術指南以執行各種常見任務的基本概念。下列演練說明如何實作支援 Tomcat 應用程式伺服器的自訂 layer。layer 是以名為 Tomcat 的自訂技術指南為基礎，其中包含處理套件安裝、部署等的配方。演練包含摘錄自 Tomcat 技術指南的摘要。您可以從其 [GitHub 儲存庫](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)下載完整的技術指南。若您不熟悉 [Opscode Chef](http://www.opscode.com/chef/)，建議您先閱讀[技術指南和配方](workingcookbook.md)。 **注意** OpsWorks Stacks 包含用於生產用途的完整功能 [Java App Server layer](layers-java.md)。Tomcat 技術指南的目的是示範如何實作自訂 layer，使其支援 Tomcat 限制版本 (不包含諸如 SSL 等功能)。如需完整實作的範例，請參閱內建的 [opsworks\$1java](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_java) 技術指南。 Tomcat 技術指南支援執行個體具有下列特性的自訂 layer： + 他們支援使用 Apache 前端的 Tomcat Java 應用程式伺服器。 + Tomcat 設定為允許應用程式使用 JDBC `DataSource` 物件連線到單獨的 MySQL 執行個體，做為後端資料存放區。此專案的技術指南涉及幾項主要元件： + [屬性檔案](create-custom-attributes.md)包含各種配方會使用的組態設定。 + [安裝配方](create-custom-setup.md)會指派給 layer 的安裝[生命週期事件](workingcookbook-events.md)。他們會在執行個體啟動並執行像是安裝套件和建立組態檔案等任務後執行。 + [設定配方](create-custom-configure.md)會指派給 layer 的設定生命週期事件。它們會在堆疊的組態變更後執行，主要是在執行個體上線或離線時，並處理任何必要的組態變更。 + [部署配方](create-custom-deploy.md)會指派給 layer 的部署生命週期事件。他們會在安裝配方之後，以及您手動部署應用程式，然後在 layer 的執行個體上安裝程式碼和相關檔案時執行，並會處理相關任務 (例如重新啟動服務)。最後一節說明如何建立堆疊，其中包含以 Tomcat 技術指南為基礎的自訂 layer[建立堆疊和執行應用程式](create-custom-stack.md)，以及如何部署和執行簡單的 JSP 應用程式，以顯示在屬於個別 MySQL layer 的執行個體上執行之 MySQL 資料庫的資料。 **注意** Tomcat 技術指南配方取決於一些 OpsWorks Stacks 內建配方。為使每個配方的來源更為清晰，本主題會使用 Chef *cookbookname*::*recipename* 慣例識別配方。 **Topics** + [屬性檔案](create-custom-attributes.md) + [安裝配方](create-custom-setup.md) + [設定配方](create-custom-configure.md) + [部署配方](create-custom-deploy.md) + [建立堆疊和執行應用程式](create-custom-stack.md) # 屬性檔案 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在查看配方前，先檢查 Tomcat 技術指南的屬性檔案 (包含各種配方使用的組態設定) 會非常有用。屬性並非必要項目。您可以直接以硬式編碼的方式在您的配方或範本中撰寫這些值。不過，如果您使用屬性定義組態設定，您可以使用 OpsWorks Stacks 主控台或 API 透過定義自訂 JSON 屬性來修改值，這比每次變更設定時重寫配方或範本程式碼更簡單且更具彈性。舉例來說，這種方法可讓您針對多個堆疊使用相同的技術指南，但為每一個堆疊分別設定不同的 Tomcat 伺服器。如需屬性和其覆寫方式的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。下列範例顯示完整的屬性檔案 (`default.rb`)，位於 Tomcat 技術指南的 `attributes` 目錄。 ``` default['tomcat']['base_version'] = 6 default['tomcat']['port'] = 8080 default['tomcat']['secure_port'] = 8443 default['tomcat']['ajp_port'] = 8009 default['tomcat']['shutdown_port'] = 8005 default['tomcat']['uri_encoding'] = 'UTF-8' default['tomcat']['unpack_wars'] = true default['tomcat']['auto_deploy'] = true case node[:platform] when 'centos', 'redhat', 'fedora', 'amazon' default['tomcat']['java_opts'] = '' when 'debian', 'ubuntu' default['tomcat']['java_opts'] = '-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC' end default['tomcat']['catalina_base_dir'] = "/etc/tomcat#{node['tomcat']['base_version']}" default['tomcat']['webapps_base_dir'] = "/var/lib/tomcat#{node['tomcat']['base_version']}/webapps" default['tomcat']['lib_dir'] = "/usr/share/tomcat#{node['tomcat']['base_version']}/lib" default['tomcat']['java_dir'] = '/usr/share/java' default['tomcat']['mysql_connector_jar'] = 'mysql-connector-java.jar' default['tomcat']['apache_tomcat_bind_mod'] = 'proxy_http' # or: 'proxy_ajp' default['tomcat']['apache_tomcat_bind_config'] = 'tomcat_bind.conf' default['tomcat']['apache_tomcat_bind_path'] = '/tc/' default['tomcat']['webapps_dir_entries_to_delete'] = %w(config log public tmp) case node[:platform] when 'centos', 'redhat', 'fedora', 'amazon' default['tomcat']['user'] = 'tomcat' default['tomcat']['group'] = 'tomcat' default['tomcat']['system_env_dir'] = '/etc/sysconfig' when 'debian', 'ubuntu' default['tomcat']['user'] = "tomcat#{node['tomcat']['base_version']}" default['tomcat']['group'] = "tomcat#{node['tomcat']['base_version']}" default['tomcat']['system_env_dir'] = '/etc/default' end ``` 設定本身會在稍後的相關章節中討論。下列注意事項一概適用： + 所有的節點定義都是 `default` 類型，讓您可以使用[自訂 JSON 屬性](workingcookbook-json-override.md)予以覆寫。 + 檔案使用 `case` 陳述式，根據執行個體的作業系統，有條件的設定一些屬性值。 `platform` 節點是由 Chef 的 Ohai 工具產生的，代表執行個體的作業系統。 # 安裝配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。安裝配方會指派給 layer 的安裝[生命週期](workingcookbook-events.md)事件，並會在執行個體啟動後執行。他們會執行像是安裝套件、建立組態檔案和啟動服務等任務。安裝配方完成執行後， OpsWorks Stacks 會執行[部署配方](create-custom-deploy.md)，將任何應用程式部署到新的執行個體。 **Topics** + [tomcat::setup](#create-custom-setup-setup) + [tomcat::install](#create-custom-setup-install) + [tomcat::service](#create-custom-setup-service) + [tomcat::container\$1config](#create-custom-setup-config) + [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) ## tomcat::setup `tomcat::setup` 配方用於指派給 layer 的安裝生命週期事件。 ``` include_recipe 'tomcat::install' include_recipe 'tomcat::service' service 'tomcat' do action :enable end # for EBS-backed instances we rely on autofs bash '(re-)start autofs earlier' do user 'root' code <<-EOC service autofs restart EOC notifies :restart, resources(:service => 'tomcat') end include_recipe 'tomcat::container_config' include_recipe 'apache2' include_recipe 'tomcat::apache_tomcat_bind' ``` `tomcat::setup` 配方基本上就是一個中繼配方。它包含一組處理大部分安裝和設定 Tomcat 之詳細資訊和相關套件的依存配方。`tomcat::setup` 的第一個部分會執行下列配方。下列配方會在稍後進行討論： + [tomcat::install](#create-custom-setup-install) 配方會安裝 Tomcat 伺服器套件。 + [tomcat::service](#create-custom-setup-service) 配方會設定 Tomcat 服務。 `tomcat::setup` 的中間部分會啟用並執行 Tomcat 服務： + Chef [service 資源](https://docs.chef.io/chef/resources.html#service)會在開機時啟用 Tomcat 服務。 + Chef [bash 資源](https://docs.chef.io/chef/resources.html#bash)會執行 Bash 指令碼來啟動 autofs 協助程式，這是 Amazon EBS 後端執行個體的必要項目。資源接著會通知 `service` 資源重新啟動 Tomcat 服務。如需詳細資訊，請參閱 [autofs](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html) (Amazon Linux 適用) 或 [Autofs](https://help.ubuntu.com/community/Autofs) (Ubuntu 適用)。 `tomcat::setup` 的最後部分會建立組態檔案，安裝及設定前端 Apache 伺服器： + [tomcat::container\$1config](#create-custom-setup-config) 配方會建立組態檔案。 + `apache2` 配方 ( 的速記`apache2::default`) 是安裝和設定 Apache 伺服器的 OpsWorks Stacks 內建配方。 + [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) 配方會設定 Apache 伺服器，做為 Tomcat 伺服器的前端。 **注意** 您通常可以透過使用內建配方執行一部分的必要任務，省下時間和精力。此配方使用內建的 `apache2::default` 配方安裝 Apache，而非從零開始實作。如需如何使用內建配方的另一個範例，請參閱[部署配方](create-custom-deploy.md)。下列章節會更詳細的說明 Tomcat 技術指南的安裝配方。如需 `apache2` 配方的詳細資訊，請參閱 [opsworks-cookbooks/apache2](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/apache2)。 ## tomcat::install `tomcat::install `配方會安裝 Tomcat 伺服器、OpenJDK 和處理 MySQL 伺服器連線的 Java 連接器程式庫。 ``` tomcat_pkgs = value_for_platform( ['debian', 'ubuntu'] => { 'default' => ["tomcat#{node['tomcat']['base_version']}", 'libtcnative-1', 'libmysql-java'] }, ['centos', 'redhat', 'fedora', 'amazon'] => { 'default' => ["tomcat#{node['tomcat']['base_version']}", 'tomcat-native', 'mysql-connector-java'] }, 'default' => ["tomcat#{node['tomcat']['base_version']}"] ) tomcat_pkgs.each do |pkg| package pkg do action :install end end link ::File.join(node['tomcat']['lib_dir'], node['tomcat']['mysql_connector_jar']) do to ::File.join(node['tomcat']['java_dir'], node['tomcat']['mysql_connector_jar']) action :create end # remove the ROOT webapp, if it got installed by default include_recipe 'tomcat::remove_root_webapp' ``` 配方會執行下列任務： 1. 根據執行個體的作業系統建立要安裝的套件清單。 1. 安裝清單中的每個套件。 Chef [套件資源](https://docs.chef.io/chef/resources.html#id146)使用適用於 Amazon Linux 和 `apt-get` Ubuntu 的適當提供者`yum`來處理安裝。套件提供者會將 OpenJDK 做為 Tomcat 的依存安裝，但 MySQL 連接器程式庫必須明確安裝。 1. 使用 Chef [link 資源](https://docs.chef.io/chef/resources.html#link)，在 Tomcat 伺服器的 lib 目錄中建立連結到 JDK 中 MySQL 連接器程式庫的 symlink。使用預設屬性值，Tomcat lib 目錄為 `/usr/share/tomcat6/lib`，MySQL 連接器程式庫 (`mysql-connector-java.jar`) 則位於 `/usr/share/java/`。 `tomcat::remove_root_webapp` 配方會移除 ROOT web 應用程式 (預設為 `/var/lib/tomcat6/webapps/ROOT`)，避免某些安全問題。 ``` ruby_block 'remove the ROOT webapp' do block do ::FileUtils.rm_rf(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT'), :secure => true) end only_if { ::File.exists?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) && !::File.symlink?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) } end ``` `only_if` 陳述式會確保只有在檔案存在時，配方才會移除他們。 **注意** Tomcat 的版本以 `['tomcat']['base_version']` 屬性指定，其在屬性檔案中已設為 6。若要安裝 Tomcat 7，您可以使用自訂 JSON 屬性覆寫屬性。您只需[編輯您的堆疊設定](workingstacks-edit.md)並在 **Custom Chef JSON (自訂 Chef JSON)** 方塊中輸入下列 JSON，或是將其新增至任何現有的自訂 JSON： ``` { 'tomcat' : { 'base_version' : 7 } } ``` 自訂 JSON 屬性會覆寫預設屬性，並將 Tomcat 的版本設為 7。如需覆寫屬性的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 ## tomcat::service `tomcat::service` 配方會建立 Tomcat 服務定義。 ``` service 'tomcat' do service_name "tomcat#{node['tomcat']['base_version']}" case node[:platform] when 'centos', 'redhat', 'fedora', 'amazon' supports :restart => true, :reload => true, :status => true when 'debian', 'ubuntu' supports :restart => true, :reload => false, :status => true end action :nothing end ``` 配方會使用 Chef [service 資源](https://docs.chef.io/chef/resources.html#service)指定 Tomcat 服務名稱 (預設為 tomcat6)，並設定 `supports` 屬性，以定義 Chef 管理服務重新啟動、重新載入和在不同作業系統上狀態命令的方式。 + `true` 表示 Chef 可使用 init 指令碼或其他服務提供者執行命令。 + `false` 表示 Chef 必須嘗試使用其他方式執行命令。請注意，`action` 已設為 `:nothing`。對於每個生命週期事件， OpsWorks Stacks 會啟動 [Chef 執行](https://docs.chef.io/chef_client_overview.html#the-chef-client-run)，以執行適當的配方集。Tomcat 技術指南遵循讓配方建立服務定義，但不重新啟動服務的常見模式。Chef 執行中的其他配方會處理重新啟動，其方式通常為藉由在用來建立組態檔案的 `notifies` 資源中包含 `template` 命令。通知為重新啟動服務的一種便利方式，因為他們只會在組態變更時才會執行此作業。此外，當 Chef 執行具有多個服務的重新啟動通知時，Chef 最多只會重新啟動服務一次。這種做法可避免在嘗試重新啟動未完全運作的服務時可能發生的問題。此為 Tomcat 錯誤的常見來源。必須為任何使用重新啟動通知的 Chef run 定義 Tomcat 服務。因此，`tomcat::service` 會包含在數個配方中，確保為每一個 Chef run 定義服務。即使 Chef 執行包含多個 `tomcat::service` 的執行個體，也不會有任何損失，因為 Chef 會確保每個配方只會在每次執行時執行一次，無論其包含多少次在內。 ## tomcat::container\$1config `tomcat::container_config` 配方會從技術指南範本檔案建立組態檔案。 ``` include_recipe 'tomcat::service' template 'tomcat environment configuration' do path ::File.join(node['tomcat']['system_env_dir'], "tomcat#{node['tomcat']['base_version']}") source 'tomcat_env_config.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'tomcat') end template 'tomcat server configuration' do path ::File.join(node['tomcat']['catalina_base_dir'], 'server.xml') source 'server.xml.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'tomcat') end ``` 配方首先會呼叫 `tomcat::service`，其將於必要時定義服務。大量的配方皆由兩個 [template 資源](https://docs.chef.io/chef/resources.html#template)組成，這兩個資源會各自從其中一個技術指南範本檔案建立組態檔案、設定檔案屬性，並通知 Chef 重新啟動服務。 ### Tomcat 環境資訊檔案第一個 `template` 資源會使用 `tomcat_env_config.erb` 範本檔案建立 Tomcat 環境資訊檔案，用於設定像是 `JAVA_HOME` 等環境變數。預設檔案名稱為 `template` 資源的引數。`tomcat::container_config` 會使用 `path` 屬性覆寫預設值及命名組態檔 `/etc/sysconfig/tomcat6` (Amazon Linux) 或 `/etc/default/tomcat6` (Ubuntu)。`template` 資源也會指定檔案的擁有者、群組和模式設定，並指示 Chef 不要建立備份檔案。若您查看來源碼，通常會有三種版本的 `tomcat_env_config.erb`，每一種都位於 `templates` 目錄中的不同子目錄內。`ubuntu` 和 `amazon` 目錄包含其各自作業系統的範本。`default` 資料夾則包含僅有一行註解的 dummy 範本，僅會在您嘗試在使用不支援作業系統的執行個體上執行此配方時使用。`tomcat::container_config` 配方不需要指定要使用何種 `tomcat_env_config.erb`。Chef 會自動根據[檔案精確性](http://docs.chef.io/templates.html#file-specificity)中描述的規則，為執行個體的作業系統挑選適當的目錄。此範例的 `tomcat_env_config.erb` 檔案大部分由註解組成。若要設定其他環境變數，只需要取消註解適當的行，並提供您喜好的值即可。 **注意** 任何可能變更的組態設定都應定義為屬性，而非在範本中硬式編碼。如此一來，您便不需要重新撰寫範本以變更設定；您可以直接覆寫屬性。 Amazon Linux 範本只會設定一個環境變數，如下列摘要所示。 ``` ... # Use JAVA_OPTS to set java.library.path for libtcnative.so #JAVA_OPTS="-Djava.library.path=/usr/lib" JAVA_OPTS="${JAVA_OPTS} <%= node['tomcat']['java_opts'] %>" # What user should run tomcat #TOMCAT_USER="tomcat" ... ``` JAVA\$1OPTS 可用來指定 Java 選項 (例如程式庫路徑)。若使用預設屬性值，範本便不會為 Amazon Linux 設定任何 Java 選項。您可以藉由覆寫 `['tomcat']['java_opts']` 屬性 (例如：使用自訂 JSON 屬性)，來設定您自己的 Java 選項。如需範例，請參閱 [建立堆疊](create-custom-stack.md#create-custom-stack-stack)。 Ubuntu 範本會設定數個環境變數，如下列範本摘要所示。 ``` # Run Tomcat as this user ID. Not setting this or leaving it blank will use the # default of tomcat<%= node['tomcat']['base_version'] %>. TOMCAT<%= node['tomcat']['base_version'] %>_USER=tomcat<%= node['tomcat']['base_version'] %> ... # Run Tomcat as this group ID. Not setting this or leaving it blank will use # the default of tomcat<%= node['tomcat']['base_version'] %>. TOMCAT<%= node['tomcat']['base_version'] %>_GROUP=tomcat<%= node['tomcat']['base_version'] %> ... JAVA_OPTS="<%= node['tomcat']['java_opts'] %>" <% if node['tomcat']['base_version'].to_i < 7 -%> # Unset LC_ALL to prevent user environment executing the init script from # influencing servlet behavior. See Debian bug #645221 unset LC_ALL <% end -%> ``` 若使用預設屬性值，範本便會設定 Ubuntu 環境變數，如下所示： + 代表 Tomcat 使用者和群組的 `TOMCAT6_USER` 和 `TOMCAT6_GROUP` 都已設為 `tomcat6`。若您將 ['tomcat']['base\$1version'] 設為 `tomcat7`，變數名稱會解析為 `TOMCAT7_USER` 和 `TOMCAT7_GROUP`，並且都會設為 `tomcat7`。 + `JAVA_OPTS` 已設定為 `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`： + 將 `-Djava.awt.headless` 設為 `true` 會向圖形引擎通知執行個體沒有標題並且也沒有主控台，表示特定圖形應用程式的錯誤行為。 + `-Xmx128m` 可確保 JVM 具有足夠的記憶體資源，此範例為 128MB。 + `-XX:+UseConcMarkSweepGC` 指定同時標記整理記憶體回收，協助限制記憶體回收造成的暫停。如需詳細資訊，請參閱 [Concurrent Mark Sweep Collector Enhancements](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html)。 + 若 Tomcat 的版本低於 7，範本會取消設定處理 Ubuntu 錯誤的 `LC_ALL`。 **注意** 若使用預設屬性，部分環境變數便會設為其預設值。但是，明確將環境變數設為屬性表示您可以定義自訂 JSON 屬性覆寫預設屬性，並提供自訂的值。如需覆寫屬性的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如需完整的範本檔案，請參閱[來源碼](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)。 ### Server.xml 組態檔案第二個 `template` 資源會使用 `server.xml.erb` 建立 [`system.xml` 組態檔](http://tomcat.apache.org/tomcat-7.0-doc/config/)，設定 servlet/JSP 容器。`server.xml.erb` 沒有包含任何作業系統限定設定，因此它會位於 `template` 目錄的 `default` 子目錄中。範本使用者使用標準設定，但它也可以為 Tomcat 6 或 Tomcat 7 建立 `system.xml` 檔案。例如，下列來自範本的伺服器區段的程式碼會為指定的版本適當設定接聽程式。 ``` <% if node['tomcat']['base_version'].to_i > 6 -%> <% end -%> <% if node['tomcat']['base_version'].to_i < 7 -%> <% end -%> <% if node['tomcat']['base_version'].to_i > 6 -%> <% end -%> ``` 範本使用屬性，而非硬式編碼設定，讓您可以藉由定義自訂 JSON 屬性，輕易變更設定。例如： ``` ``` 如需詳細資訊，請參閱[來源碼](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)。 ## tomcat::apache\$1tomcat\$1bind `tomcat::apache_tomcat_bind` 配方會啟用 Apache 伺服器做為 Tomcat 的前端，接受傳入的請求，並將他們轉遞至 Tomcat 並將回應傳回用戶端。此範例使用 [mod\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) 做為 Apache 代理/閘道。 ``` execute 'enable mod_proxy for apache-tomcat binding' do command '/usr/sbin/a2enmod proxy' not_if do ::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', 'proxy.load')) || node['tomcat']['apache_tomcat_bind_mod'] !~ /\Aproxy/ end end execute 'enable module for apache-tomcat binding' do command "/usr/sbin/a2enmod #{node['tomcat']['apache_tomcat_bind_mod']}" not_if {::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', "#{node['tomcat']['apache_tomcat_bind_mod']}.load"))} end include_recipe 'apache2::service' template 'tomcat thru apache binding' do path ::File.join(node['apache']['dir'], 'conf.d', node['tomcat']['apache_tomcat_bind_config']) source 'apache_tomcat_bind.conf.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'apache2') end ``` 若要啟用 `mod_proxy`，您必須啟用 `proxy` 模組及通訊協定式模組。您有兩個通訊協定模組選項： + HTTP: `proxy_http` + [Apache JServ 通訊協定](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html) (ASP)：`proxy_ajp` AJP 是一種內部 Tomcat 通訊協定。兩種配方的 [execute 資源](https://docs.chef.io/chef/resources.html#execute)都會執行 `a2enmod` 命令，透過建立必要的 symlink 啟用指定的模組： + 第一個 `execute` 資源會啟用 `proxy` 模組。 + 第二個 `execute` 資源會啟用通訊協定模組，根據預設設為 `proxy_http`。若您要使用 AJP，您可以定義自訂 JSON 覆寫 `apache_tomcat_bind_mod` 屬性，將其設為 `proxy_ajp`。 `apache2::service` 配方是定義 Apache OpsWorks 服務的 Stacks 內建配方。如需詳細資訊，請參閱 Stacks GitHub OpsWorks 儲存庫中的[配方](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb)。 `template` 資源使用 `apache_tomcat_bind.conf.erb` 建立根據預設名為 `tomcat_bind.conf` 的組態檔案。它會將檔案置放在 `['apache']['dir']/.conf.d` 目錄中。`['apache']['dir']` 屬性會在內建的 `apache2` 屬性檔案中定義，並根據預設設為 `/etc/httpd` (Amazon Linux) 或 `/etc/apache2` (Ubuntu)。若 `template` 資源建立或變更組態檔案，`notifies` 命令會排程 Apache 服務重新啟動。 ``` <% if node['tomcat']['apache_tomcat_bind_mod'] == 'proxy_ajp' -%> ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/ ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/ <% else %> ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/ ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/ <% end -%> ``` 範本使用 [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass) 和 [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse) 指示詞設定用來在 Apache 和 Tomcat 間傳遞流量的連接埠。因為兩個伺服器都位於相同的執行個體上，他們可以使用 localhost URL，並且根據預設都會設為 `http://localhost:8080`。 # 設定配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。設定配方會指派給 layer 的設定[生命週期](workingcookbook-events.md)事件，該事件會在執行個體進入或離開線上狀態時，在所有堆疊的執行個體上發生。您可使用設定配方調整執行個體的組態，以適當回應變更。當您實作設定配方時，請記得堆疊組態變更可能會涉及與這一 layer 無關的執行個體。配方必須要能適當地進行回應，在某些案例中，可能不會進行任何行為。 ## tomcat::configure `tomcat::configure` 配方用於 layer 的設定生命週期事件。 ``` include_recipe 'tomcat::context' # Optional: Trigger a Tomcat restart in case of a configure event, if relevant # settings in custom JSON have changed (e.g. java_opts/JAVA_OPTS): #include_recipe 'tomcat::container_config' ``` `tomcat::configure` 配方基本上就是執行兩個依存配方的中繼配方。 1. `tomcat::context` 配方會建立 web 應用程式內容組態檔案。此檔案會設定應用程式用來與 MySQL 執行個體通訊的 JDBC 資源，如下一節所討論。執行此配方以回應設定事件，可讓 layer 在資料庫 layer 變更時更新 web 應用程式內容組態檔案。 1. `tomcat::container_config` 安裝配方會再次執行，以擷取任何容器組態中的變更。 `include` 的 `tomcat::container_config` 在此範例中已標示為註解。若您希望使用自訂的 JSON 修改 Tomcat 設定，您可以移除註解。設定生命週期事件接著會執行 `tomcat::container_config` 更新 Tomcat 的相關組態檔案 (如 [tomcat::container\$1config](create-custom-setup.md#create-custom-setup-config) 所述) 並重新啟動 Tomcat 服務。 ## tomcat::context Tomcat 技術指南可透過使用 [J2EE DataSource](http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html) 物件，讓應用程式存取可能在分離的執行個體上執行的 MySQL 資料庫伺服器。透過 Tomcat，您可以藉由建立和安裝每個應用程式的 web 應用程式內容組態檔案，來啟用連線。此檔案定義應用程式和應用程式用來與資料庫通訊之 JDBC 資源間的關聯。如需詳細資訊，請參閱[內容容器](http://tomcat.apache.org/tomcat-7.0-doc/config/context.html)。 `tomcat::context` 配方的主要用途是建立此組態檔案。 ``` include_recipe 'tomcat::service' node[:deploy].each do |application, deploy| context_name = deploy[:document_root].blank? ? application : deploy[:document_root] template "context file for #{application} (context name: #{context_name})" do path ::File.join(node['tomcat']['catalina_base_dir'], 'Catalina', 'localhost', "#{context_name}.xml") source 'webapp_context.xml.erb' owner node['tomcat']['user'] group node['tomcat']['group'] mode 0640 backup false only_if { node['datasources'][context_name] } variables(:resource_name => node['datasources'][context_name], :webapp_name => application) notifies :restart, resources(:service => 'tomcat') end end ``` 除了 Tomcat 技術指南屬性之外，此配方還使用 OpsWorks Stacks 隨設定事件一起安裝的[堆疊組態和部署屬性](workingcookbook-json.md)。Stacks OpsWorks 服務會將屬性新增至每個執行個體的節點物件，其中包含配方通常會使用資料包或搜尋取得的資訊，並在每個執行個體上安裝屬性。屬性包含堆疊組態、部署應用程式和任何使用者希望包含之自訂資料的詳細資訊。配方可透過使用標準 Chef 節點語法，從堆疊組態和部署屬性取得資料。如需詳細資訊，請參閱[堆疊組態及部署屬性](workingcookbook-json.md)。透過 Chef 11.10 堆疊，您也可以使用 Chef 搜尋取得堆疊組態和部署資料。如需詳細資訊，請參閱[使用 Chef 搜尋](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search)。 `deploy` 屬性是指`[:deploy]`命名空間，其中包含透過主控台或 API 定義的部署相關屬性，或由 Stacks OpsWorks 服務產生的屬性。`deploy` 屬性包含每個部署應用程式的屬性，以應用程式的短名命名。每個應用程式屬性都包含一組描述應用程式的屬性，例如文件根 (`[:deploy][:appname][:document_root]`)。 `context` 配方首先會透過呼叫 [tomcat::service](create-custom-setup.md#create-custom-setup-service)，確認已為此 Chef 執行定義服務。它接著會定義 `context_name` 變數，代表組態檔案的名稱 (排除 `.xml` 副檔名)。若您使用預設文件根，`context_name` 會設為應用程式的短名。否則，它會設為指定的文件根。[建立堆疊和執行應用程式](create-custom-stack.md)中討論的範例會將文件根設為 `"ROOT"`，因此內容為 ROOT，組態檔案則名為 `ROOT.xml`。大量的配方都會穿過每個應用程式的部署應用程式清單，使用 `webapp_context.xml.erb` 範本建立內容組態檔案。範例只會部署一個應用程式，但 `deploy` 屬性的定義仍會要求您將其視為應用程式清單處理。 `webapp_context.xml.erb` 範本並非作業系統限定，因此它會位於 `templates` 目錄的 `default` 子目錄中。配方會建立組態檔案如下： + 當使用預設屬性值時，組態檔案名稱會設為 `context_name.xml`，並安裝在 `/etc/tomcat6/Catalina/localhost/` 目錄中。堆疊組態屬性的 `['datasources']` 節點包含一或多個屬性，每一種都會將一個內容名稱映射到關聯應用程式用來與資料庫通訊的 JDBC 資料來源。節點和其內容都會在您建立堆疊時，使用自訂 JSON 定義，如稍後的[建立堆疊和執行應用程式](create-custom-stack.md)所述。範例具有將 ROOT 內容名稱與名為 jdbc/mydb 的 JDBC 資源建立關聯的單一屬性。 + 使用預設屬性值，檔案的使用者和群組都會設為由 Tomcat 套件定義的值：`tomcat` (Amazon Linux) 或 `tomcat6` (Ubuntu)。 + `template` 資源只會在 `['datasources']` 節點存在且包含 `context_name` 屬性值建立組態檔案。 + `template` 資源會定義兩個變數：`resource_name` 和 `webapp_name`。 `resource_name` 已設為與 `context_name` 關聯的資源名稱，`webapp_name` 則已設為應用程式的短名。 + 範本資源會重新啟動 Tomcat 服務，載入及啟用變更。 `webapp_context.xml.erb` 範本由包含具有自己屬性組之 `Context` 元素的 `Resource` 元素組成。 `Resource` 屬性會描述內容組態的特性： + **name** – JDBC 資源名稱，設定為中定義的`resource_name`值`tomcat::context`。例如，資源名稱已設為 jdbc/mydb。 + **驗證**和**類型** – 這些是 JDBC `DataSource`連線的標準設定。 + **maxActive**、**maxIdle** 和 **maxWait** – 作用中和閒置連線的數量上限，以及傳回連線的等待時間上限。 + **username**， and **password** – 從`deploy`屬性取得的資料庫使用者名稱和根密碼。 + **driverClassName** – JDBC 驅動程式的類別名稱，設定為 MySQL 驅動程式。 + **url** – 連線 URL。前綴取決於資料庫。其應設為 `jdbc:mysql` (MySQL)、`jdbc:postgresql` (Postgres) 和 `jdbc:sqlserver` (SQL Server)。範例將 URL 設為 `jdbc:mysql://host_IP_Address:3306:simplejsp`，其中 *simplejsp* 為應用程式的短名。 + **factory** – MySQL 資料庫需要的 `DataSource` factory。如需此組態檔案的詳細資訊，請參閱 Tomcat 維基的 [Using DataSources](http://wiki.apache.org/tomcat/UsingDataSources) 主題。 # 部署配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。部署配方會指派給 layer 的部署[生命週期](workingcookbook-events.md)事件。每當您部署應用程式時，它通常會在所有堆疊的執行個體上發生，但您可以選擇將事件限制為僅指定執行個體。安裝配方完成後， OpsWorks 堆疊也會在新執行個體上執行部署配方。部署配方的主要用途是從儲存庫將程式碼和相關檔案部署到應用程式伺服器 layer 的執行個體。但是，您通常也需要在其他 layer 執行部署配方。這可讓那些 layer 的執行個體進行像是更新其組態以適應新部署之應用程式等行為。當您實作部署配方時，請記得部署事件不一定表示應用程式正部署到執行個體。它可能只是一項針對應用程式正在部署到堆疊中其他執行個體的通知，讓執行個體進行任何必要的更新。配方必須要能適當地進行回應，其可能不會進行任何行為。 OpsWorks Stacks 會自動將標準應用程式類型的應用程式部署到對應的內建應用程式伺服器層。若要將應用程式部署到自訂 layer，您必須實作自訂部署配方，從儲存庫將應用程式檔案下載到執行個體上的適當位置。但是，您通常可以藉由使用內建的[部署技術指南](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy)限制您必須撰寫的程式碼數量，處理一部分的部署。例如，若您將您的檔案存放在其中一個支援的儲存庫，內建技術指南可以處理從儲存庫將檔案下載到 layer 的執行個體的詳細資訊。 `tomcat::deploy` 技術指南用於指派給部署生命週期事件。 ``` include_recipe 'deploy' node[:deploy].each do |application, deploy| opsworks_deploy_dir do user deploy[:user] group deploy[:group] path deploy[:deploy_to] end opsworks_deploy do deploy_data deploy app application end ... ``` `tomcat::deploy` 配方針對部署中非應用程式限定的一部分使用內建的部署技術指南。`deploy` 配方 (為內建 `deploy::default` 配方的速記) 是一種內建的配方，可根據 `deploy` 屬性的資料處理設定使用者、群組等詳細資訊。配方使用兩個內建 Chef 定義 (`opsworks_deploy_dir` 和 `opworks_deploy`) 安裝應用程式。 `opsworks_deploy_dir` 定義會根據應用程式部署 JSON 的資料設定目錄結構。定義基本上是封裝資源定義的便利方式，位於技術指南的 `definitions` 目錄中。配方可像資源一樣使用定義，但定義本身不具有關聯的提供者，只有包含在定義內的資源。您可以在配方中定義變數，該變數會傳遞到基礎資源定義。`tomcat::deploy` 配方會根據部署 JSON 的資料設定 `user`、`group` 和 `path` 變數。他們會傳遞到定義的 [directory 資源](https://docs.chef.io/chef/resources.html#directory)，該資源會管理目錄。 **注意** 您部署應用程式的使用者和群組由 `[:opsworks][:deploy_user][:user]` 和 `[:opsworks][:deploy_user][:group]` 屬性決定，這兩個屬性的定義位於[內建部署技術指南的 `deploy.rb` 屬性檔案](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb)中。`[:opsworks][:deploy_user][:user]` 的預設值為 `deploy`。`[:opsworks][:deploy_user][:group]` 的預設值視執行個體的作業系統而定。若是 Ubuntu 執行個體，預設群組為 `www-data`。對於使用 Nginx 和 Unicorn 的 Rails App Server layer 成員的 Amazon Linux 執行個體，預設群組為 `nginx`。若是其他所有 Amazon Linux 執行個體，預設群組為 `apache`。您可以透過使用自訂 JSON 或自訂屬性檔案覆寫適當的屬性，來變更設定。如需詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。其他定義 (`opsworks_deploy`) 會根據 `deploy` 屬性的資料，處理檢查來自儲存庫的應用程式程式碼和相關檔案，以及將他們部署到執行個體的詳細資訊。您可以針對任何應用程式類型使用此定義。部署詳細資訊 (例如目錄名稱) 會在主控台中或透過 API 指定，並置放於 `deploy` 屬性中。但是，`opsworks_deploy` 僅適用於四種[支援的儲存庫類型](workingcookbook-installingcustom-repo.md)：Git、Subversion、S3 和 HTTP。若您希望使用不同的儲存庫類型，您必須自行實作程式碼。您會在 Tomcat `webapps` 目錄中安裝應用程式的檔案。典型的做法是將檔案直接複製到 `webapps`。不過， OpsWorks Stacks 部署的設計可在執行個體上保留最多五個版本的應用程式，因此您可以視需要轉返至較早的版本。 OpsWorks Stacks 因此會執行下列動作： 1. 將應用程式部署到名稱包含時間戳記的相異目錄，例如 `/srv/www/my_1st_jsp/releases/20130731141527`。 1. 建立連結到此唯一目錄，名為 `current` 的 symlink，例如 `/srv/www/my_1st_jsp/current`。 1. 若尚未存在，請從 `webapps` 目錄建立連結到步驟 2 中建立之 `current` symlink 的 symlink。若您需要轉返至較早的版本，請修改 `current` symlink 指向包含適當時間戳記的相異目錄 (例如，變更 `/srv/www/my_1st_jsp/current` 的連結目標)。 `tomcat::deploy` 中間的區段會設定 symlink。 ``` ... current_dir = ::File.join(deploy[:deploy_to], 'current') webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root]) # opsworks_deploy creates some stub dirs, which are not needed for typical webapps ruby_block "remove unnecessary directory entries in #{current_dir}" do block do node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry| ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true) end end end link webapp_dir do to current_dir action :create end ... ``` 配方首先會建立兩個變數 (`current_dir` 和 `webapp_dir`) 分別代表 `current` 和 `webapp`。它接著會使用 `link` 資源將 `webapp_dir` 連結到 `current_dir`。Stacks OpsWorks `deploy::default`配方會建立此範例不需要的一些 stub 目錄，因此摘錄的中間部分會將其移除。 `tomcat::deploy` 的最終部分會重新啟動 Tomcat 服務 (若必要的話)。 ``` ... include_recipe 'tomcat::service' execute 'trigger tomcat service restart' do command '/bin/true' not_if { node['tomcat']['auto_deploy'].to_s == 'true' } notifies :restart, resources(:service => 'tomcat') end end include_recipe 'tomcat::context' ``` 配方首先會執行 `tomcat::service`，確保已為此 Chef 執行定義服務。它接著會使用 [execute 資源](https://docs.chef.io/chef/resources.html#execute)通知服務重新啟動，但只有在 `['tomcat']['auto_deploy']` 設為 `'true'` 時才會這麼做。否則，Tomcat 會接聽其 `webapps` 目錄中的變更，使明確重新啟動 Tomcat 服務為非必要事項。 **注意** `execute` 資源不會執行任何實際操作。`/bin/true` 僅是一個 dummy shell 指令碼，只會傳回成功代碼。在此使用它的目的只是為了方便產生重新啟動通知。如先前所述，使用通知可確保服務不會太頻繁的重新啟動。最後，`tomcat::deploy` 會執行 `tomcat::context`，更新 web 應用程式內容組態檔案 (若您有變更後端資料庫的話)。 # 建立堆疊和執行應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節說明如何使用 Tomcat 技術指南實作基本堆疊設定，執行名為 SimpleJSP 的簡易 Java 伺服器頁面 (JSP) 應用程式。堆疊包含名為 TomCustom 的 Tomcat 型自訂層和 MySQL 層。SimpleJSP 會部署到 TomCustom，並顯示 MySQL 資料庫中的一些資訊。如果您尚未熟悉如何使用 OpsWorks Stacks 的基本概念，您應該先閱讀 [Chef 11 Linux 堆疊入門](gettingstarted.md)。 ## SimpleJSP 應用程式 SimpleJSP 應用程式會示範如何設定資料庫連線和從堆疊的 MySQL 資料庫擷取資料的基本操作。 ``` DB Access <%@ page language="java" import="java.sql.*,javax.naming.*,javax.sql.*" %> <% StringBuffer output = new StringBuffer(); DataSource ds = null; Connection con = null; Statement stmt = null; ResultSet rs = null; try { Context initCtx = new InitialContext(); ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/mydb"); con = ds.getConnection(); output.append("Databases found:
"); stmt = con.createStatement(); rs = stmt.executeQuery("show databases"); while (rs.next()) { output.append(rs.getString(1)); output.append("
"); } } catch (Exception e) { output.append("Exception: "); output.append(e.getMessage()); output.append("
"); } finally { try { if (rs != null) { rs.close(); } if (stmt != null) { stmt.close(); } if (con != null) { con.close(); } } catch (Exception e) { output.append("Exception (during close of connection): "); output.append(e.getMessage()); output.append("
"); } } %> <%= output.toString() %> ``` SimpleJSP 使用 `DataSource` 物件與 MySQL 資料庫通訊。Tomcat 使用 [Web 應用程式內容組態檔案](create-custom-configure.md#create-custom-configure-context)中的資料建立和初始化 `DataSource` 物件，並將其繫結到邏輯名稱。它接著會使用 Java 命名及目錄界面 (JNDI) 命名服務註冊邏輯名稱。為取得適當 `DataSource` 物件的執行個體，您會建立 `InitialContext` 物件，並將資源的邏輯名稱傳遞給物件的 `lookup` 方法，擷取適當的物件。SimpleJSP 範例的邏輯名稱 (`java:comp/env/jdbc/mydb`) 包含下列元件： + 根命名空間 (`java`)，以冒號 (:) 與名稱的剩餘部分分開。 + 任何額外的命名空間，都會以斜線 (/) 分開。 Tomcat 會自動將資源新增到 `comp/env` 命名空間。 + 資源名稱，定義於 web 應用程式內容組態檔案中，並以斜線與命名空間分隔。此範例的資源名稱為 `jdbc/mydb`。為建立資料庫的連線，SimpleJSP 會執行下列作業： 1. 呼叫 `DataSource` 物件的 `getConnection` 方法，傳回 `Connection` 物件。 1. 呼叫 `Connection` 物件的 `createStatement` 方法，建立 `Statement` 物件，您會使用此物件與資料庫通訊。 1. 透過呼叫適當的 `Statement` 方法與資料庫通訊。 SimpleJSP 會呼叫 `executeQuery` 執行 SHOW DATABASES 查詢，列出伺服器的資料庫。 `executeQuery` 方法會傳回 `ResultSet` 物件，其中包含查詢的結果。SimpleJSP 會從傳回的 `ResultSet` 物件取得資料庫名稱，然後串連它們以建立輸出字串。最後，範例會關閉 `ResultSet`、`Statement` 和 `Connection` 物件。如需 JSP 和 JDBC 的詳細資訊，請分別參考 [JavaServer Pages Technology](http://docs.oracle.com/javaee/5/tutorial/doc/bnagx.html) 和 [JDBC Basics](http://docs.oracle.com/javase/tutorial/jdbc/basics/)。若要搭配堆疊使用 SimpleJSP，您必須將其置放在儲存庫中。您可以使用任何支援的儲存庫，但若要搭配下列章節中討論的範例堆疊使用 SimpleJSP，您必須將其置放在公有 S3 封存中。如需如何使用其他標準儲存庫的資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。 **將 SimpleJSP 置放在 S3 封存儲存庫中** 1. 將範例程式碼複製到名為 `simplejsp.jsp` 的檔案，然後將檔案置放在名為 `simplejsp` 的目錄中。 1. 建立 `simplejsp` 目錄的 `.zip` 存檔。 1. 建立公有 Amazon S3 儲存貯體、上傳至`simplejsp.zip`儲存貯體，並將檔案設為公有。如需如何執行此任務的說明，請參閱 [Amazon Simple Storage Service 入門](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)。 ## 建立堆疊若要執行 SimpleJSP，您需要具有下列 layer 的堆疊。 + 支援後端 MySQL 資料庫的 MySQL layer。 + 使用 Tomcat 技術指南支援 Tomcat 伺服器執行個體的自訂 layer。 **建立堆疊** 1. 在 OpsWorks Stacks 儀表板上，按一下**新增堆疊**以建立新的堆疊，然後按一下**進階 >>** 以顯示所有選項。設定堆疊如下。 + **名稱** – 使用者定義的堆疊名稱；此範例使用 TomStack。 + **使用自訂 Chef 技術指南** – 將切換設定為**是**，這會顯示一些額外的選項。 + **儲存庫類型** – Git。 + **儲存庫 URL**–`git://github.com/amazonwebservices/opsworks-example-cookbooks.git`。 + **自訂 Chef JSON** – 新增下列 JSON： ``` { "tomcat": { "base_version": 7, "java_opts": "-Djava.awt.headless=true -Xmx256m" }, "datasources": { "ROOT": "jdbc/mydb" } } ``` 對於剩餘的選項，您可以接受預設值。自訂 JSON 會執行下列操作： + 覆寫 Tomcat 技術指南的 `['base_version']` 屬性，將 Tomcat 的版本設為 7。預設值為 6。 + 覆寫 Tomcat 技術指南的 `['java_opts']` 屬性，指定執行個體沒有標題，並將 JVM 最大堆積大小設為 256MB。預設值不會為執行 Amazon Linux 的執行個體設定任何選項。 + 指定 `['datasources]` 屬性值，指派 JDBC 資源名稱 (jdbc/mydb) 給 web 應用程式內容名稱 (ROOT)，如 [tomcat::context](create-custom-configure.md#create-custom-configure-context) 中所討論。這個最後一個屬性沒有任何預設值。您必須使用自訂 JSON 設定它。 ![\[Configuration Management interface showing Chef version options and custom JSON input field.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/tom_add_stack.png) 1. 按一下 **Add a layer (新增 layer)**。針對 **Layer type (Layer 類型)**，選取 **MySQL**。然後按一下 **Add Layer (新增 Layer)**。 1. 按一下導覽窗格中的 **Instances (執行個體)**，然後按一下 **Add an instance (新增執行個體)**。按一下 **Add Instance (新增執行個體)** 接受預設值。在執行個體的列上，按一下 **start (啟動)**。 1. 返回 **Layers (Layer)** 頁面然後按一下 **\$1 Layer (\$1Layer)** 以新增 layer。針對 **Layer type (Layer 類型)**，按一下 **Custom (自訂)**。範例使用 **TomCustom** 和 **tomcustom** 分別做為 layer 的名稱和短名。 ![\[Add Layer form with Custom layer type, Name, and Short name fields for creating a customized layer.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/tom_add_custom_layer.png) 1. 在 **Layers (Layer)** 頁面上，針對自訂 layer，按一下 **Recipes (配方)** 然後按一下 **Edit (編輯)**。在 **Custom Chef Recipes (自訂 Chef 配方)** 下，將 Tomcat 技術指南配方指派給 layer 的生命週期事件，如下所示： + 針對 **Setup (安裝)**，輸入 **tomcat::setup** 然後按一下 **\$1**。 + 針對 **Configure (設定)**，輸入 **tomcat::configure** 然後按一下 **\$1**。 + 針對 **Deploy (部署)**，輸入 **tomcat::deploy** 然後按一下 **\$1**。然後按一下 **Save (儲存)**。 . ![\[Custom Chef Recipes interface showing setup, configure, and deploy steps with options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/tom_events.png) 1. 按一下導覽窗格中的 **Apps (應用程式)**，然後按一下 **Add an app (新增應用程式)**。指定下列選項，然後按一下 **Add App (新增應用程式)**： + **名稱** – 應用程式的名稱；範例使用 SimpleJSP，而 Stacks OpsWorks 產生的簡短名稱將是 simplejsp。 + **應用程式類型** – 將此選項設定為**其他**。 OpsWorks Stacks 會自動將標準應用程式類型部署至相關聯的伺服器執行個體。若您將 **App type (應用程式類型)** 設為「其他」， OpsWorks Stacks 便只會執行部署配方，並讓它們處理部署。 + **文件根** – 將此選項設定為 **ROOT**。 **Document root (文件根)** 的值指定內容名稱。 + **儲存庫類型** – 將此選項設定為 **S3 Archive**。 + **儲存庫 URL** – 將此設定為您先前建立的應用程式 Amazon S3 URL。其他選項請使用預設設定。 ![\[Application settings form with fields for name, app type, document root, and source details.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/tom_app.png) 1. 使用**執行個體**頁面將執行個體新增至 TomCustom 層並啟動。安裝配方完成後， OpsWorks Stacks 會自動在新執行個體上執行部署配方，因此啟動執行個體也會部署 SimpleJSP。 1. 當 TomCustom 執行個體上線時，在 **Instances (執行個體)** 頁面上按一下執行個體名稱以查看詳細資訊。複製公有 IP 地址。然後建構 URL 如下：http://*publicIP*/tc/*appname.jsp*。例如，此 URL 看起來會像這樣：**http://50.218.191.172/tc/simplejsp.jsp**。 **注意** 轉遞請求至 Tomcat 的 Apache URL 已設為預設 `['tomcat']['apache_tomcat_bind_path']` 屬性，`/tc/`。SimpleJSP 文件根已設為 `ROOT`，為解析至 `/` 的特殊值。URL 因此為 ".../tc/simplejsp.jsp"。 1. 將先前步驟中的 URL 於您的瀏覽器內貼上。請查看下列事項： ``` Databases found: information_schema simplejsp test ``` **注意** 如果您的堆疊有 MySQL 執行個體， OpsWorks Stacks 會自動為每個應用程式建立資料庫，以應用程式的簡短名稱命名。 # 堆疊組態及部署屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當 OpsWorks Stacks 在執行個體上執行命令時，例如，回應部署生命週期事件的部署命令，它會將一組屬性新增至描述堆疊目前組態的執行個體節點物件。對於部署事件和[執行配方堆疊命令](workingstacks-commands.md)， OpsWorks Stacks 會安裝部署屬性，以提供一些額外的部署資訊。如需節點物件的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如需常用堆疊組態及部署屬性的清單 (包含完整的節點名稱)，請參閱[堆疊組態及部署屬性：Linux](attributes-json-linux.md) 和[內建技術指南屬性](attributes-recipes.md)。 **注意** 在 Linux 堆疊上，您可以透過使用代理程式 CLI 的 [get\$1json 命令](agent-json.md)取得這些屬性的完整清單，其格式為 JSON 物件。下列各節顯示與設定事件關聯的屬性，以及一個簡易堆疊的部署事件，由下列項目組成： + 具有兩個執行個體的 PHP App Server layer + 具有一個執行個體的 HAProxy layer 這些範例來自其中一個 PHP App Server 執行個體 **php-app1**。為了方便，屬性已格式化為 JSON 物件。物件的結構會映射到屬性的完整名稱。例如，`node[:opsworks][:ruby_version]` 屬性會在 JSON 表示中以下列方式呈現。 ``` { "opsworks": { ... "ruby_version": "1.8.7", ... } } ``` **Topics** + [設定屬性](#workingcookbook-json-configure) + [部署屬性](#workingcookbook-json-deploy) ## 設定屬性下列 JSON 物件顯示設定事件的屬性，其會在執行個體上線或離線時，在堆疊中的每個執行個體上發生，屬性包含內建堆疊組態屬性和任何在事件之前為堆疊定義的[自訂 JSON 屬性](workingstacks-json.md) (在此範例中則無)。它已針對長度進行編輯。如需各種屬性的詳細描述，請參閱[堆疊組態及部署屬性：Linux](attributes-json-linux.md) 和[內建技術指南屬性](attributes-recipes.md)。 ``` { "opsworks": { "layers": { "php-app": { "id": "4a2a56c8-f909-4b39-81f8-556536d20648", "instances": { "php-app2": { "elastic_ip": null, "region": "us-west-2", "booted_at": "2013-02-26T20:41:10+00:00", "ip": "192.0.2.0", "aws_instance_id": "i-34037f06", "availability_zone": "us-west-2a", "instance_type": "c1.medium", "private_dns_name": "ip-10-252-0-203.us-west-2.compute.internal", "private_ip": "10.252.0.203", "created_at": "2013-02-26T20:39:39+00:00", "status": "online", "backends": 8, "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com" }, "php-app1": { ... } }, "name": "PHP Application Server" }, "lb": { "id": "15c86142-d836-4191-860f-f4d310440f14", "instances": { "lb1": { ... } }, "name": "Load Balancer" } }, "agent_version": "104", "applications": [ ], "stack": { "name": "MyStack" }, "ruby_version": "1.8.7", "sent_at": 1361911623, "ruby_stack": "ruby_enterprise", "instance": { "layers": [ "php-app" ], "region": "us-west-2", "ip": "192.0.2.0", "id": "45ef378d-b87c-42be-a1b9-b67c48edafd4", "aws_instance_id": "i-32037f00", "availability_zone": "us-west-2a", "private_dns_name": "ip-10-252-84-253.us-west-2.compute.internal", "instance_type": "c1.medium", "hostname": "php-app1", "private_ip": "10.252.84.253", "backends": 8, "architecture": "i386", "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com" }, "activity": "configure", "rails_stack": { "name": null }, "deployment": null, "valid_client_activities": [ "reboot", "stop", "setup", "configure", "update_dependencies", "install_dependencies", "update_custom_cookbooks", "execute_recipes" ] }, "opsworks_custom_cookbooks": { "recipes": [ ], "enabled": false }, "recipes": [ "opsworks_custom_cookbooks::load", "opsworks_ganglia::configure-client", "ssh_users", "agent_version", "mod_php5_apache2::php", "php::configure", "opsworks_stack_state_sync", "opsworks_custom_cookbooks::execute", "test_suite", "opsworks_cleanup" ], "opsworks_rubygems": { "version": "1.8.24" }, "ssh_users": { }, "opsworks_bundler": { "manage_package": null, "version": "1.0.10" }, "deploy": { } } ``` 大多數的資訊都位於 `opsworks` 屬性下方，通常其名為命名空間。以下清單說明關鍵屬性： + `layers` 屬性 – 一組屬性，每個屬性都會描述其中一個堆疊層的組態。這些 layer 會根據其短名識別，此範例中為 `php-app` 和 `lb`。如需其他 layer 之短名的詳細資訊，請參閱 [OpsWorks Stacks Layer 參考](layers.md)。 + `instances` 屬性 – 每個 layer 都有 `instances`元素，其中包含每個 layer 線上執行個體的屬性，以執行個體的簡短名稱命名。 PHP App Server layer 有兩個執行個體 `php-app1`和 `php-app2`。HAProxy layer 有一個執行個體 `lb1`。 **注意** `instances` 元素只包含那些在建立特定堆疊及部署屬性時處於線上狀態的執行個體。 + 執行個體屬性 – 每個執行個體屬性都包含一組屬性來描述執行個體，例如執行個體的私有 IP 地址和私有 DNS 名稱。為了簡化，此範例只顯示 `php-app2` 屬性的詳細資訊。其他的也包含相似的資訊。 + `applications` – 部署的應用程式清單，未用於此範例。 + `stack` – 堆疊名稱；在此範例中`MyStack`為。 + `instance` – 已安裝這些屬性的執行個體；在此範例中`php-app1`為。配方可使用此屬性取得執行中執行個體的資訊，例如執行個體的公有 IP 地址。 + `activity` – 產生屬性的活動；在此範例中為設定事件。 + `rails_stack` – 包含 Rails App Server layer 之堆疊的 Rails 堆疊。 + `deployment` – 這些屬性是否與部署相關聯。此範例中已設為 `null`，因為他們是與設定事件關聯。 + `valid_client_activities` – 有效用戶端活動的清單。 `opsworks` 屬性其後跟隨幾個其他最上層屬性，包含下列項目： + `opsworks_custom_cookbooks` – 是否啟用自訂技術指南。若為是，則屬性會包含自訂配方的清單。 + `recipes` – 此活動執行的配方。 + `opsworks_rubygems` – 執行個體的 RubyGems 版本。 + `ssh_users` – SSH 使用者清單；此範例中沒有。 + `opsworks_bundler` – 綁定器版本及其是否已啟用。 + `deploy` – 部署活動的相關資訊；此範例中沒有。 ## 部署屬性部署事件或[執行配方堆疊命令](workingstacks-commands.md)的屬性由內建的堆疊組態及部署屬性，以及任何自訂堆疊或部署屬性組成 (此範例中則無)。下列 JSON 物件顯示與部署事件關聯之 **php-app1** 的屬性。該事件會將 SimplePHP 應用程式部署到堆疊的 PHP 執行個體。物件的大部分都是由與先前章節中說明的設定事件屬性相似的堆疊組態屬性組成，因此範例主要會聚焦在部署限定的屬性。如需各種屬性的詳細描述，請參閱[堆疊組態及部署屬性：Linux](attributes-json-linux.md) 和[內建技術指南屬性](attributes-recipes.md)。 ``` { ... "opsworks": { ... "activity": "deploy", "applications": [ { "slug_name": "simplephp", "name": "SimplePHP", "application_type": "php" } ], "deployment": "5e6242d7-8111-40ee-bddb-00de064ab18f", ... }, ... { "ssh_users": { }, "deploy": { "simplephpapp": { "application": "simplephpapp", "application_type": "php", "environment_variables": { "USER_ID": "168424", "USER_KEY": "somepassword" }, "auto_bundle_on_deploy": true, "deploy_to": "/srv/www/simplephpapp", "deploying_user": "arn:aws:iam::123456789012:user/guysm", "document_root": null, "domains": [ "simplephpapp" ], "migrate": false, "mounted_at": null, "rails_env": null, "restart_command": "echo 'restarting app'", "sleep_before_restart": 0, "ssl_support": false, "ssl_certificate": null, "ssl_certificate_key": null, "ssl_certificate_ca": null, "scm": { "scm_type": "git", "repository": "git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git", "revision": "version1", "ssh_key": null, "user": null, "password": null }, "symlink_before_migrate": { "config/opsworks.php": "opsworks.php" }, "symlinks": { }, "database": { }, "memcached": { "host": null, "port": 11211 }, "stack": { "needs_reload": false } } }, } ``` `opsworks` 屬性大致上與先前章節中的範例相同。以下區段是與部署最為相關的部分： + `activity` – 與這些屬性相關聯的事件；此範例中的部署事件。 + `applications` – 包含每個應用程式一組屬性，提供應用程式的名稱、slug 名稱和類型。 slug 名稱是應用程式的簡短名稱，由 OpsWorks Stacks 從應用程式名稱產生。SimplePHP 的動態資料欄位名稱為 simplephp。 + `deployment` – 部署 ID，可唯一識別部署。 `deploy` 屬性包含正在部署之應用程式的相關資訊。例如，內建的部署配方會使用 `deploy` 屬性中的資料，來在適當的目錄中安裝檔案及建立資料庫連線檔案。`deploy` 屬性包含每個部署應用程式的一個屬性，以應用程式的短名命名。每個應用程式的屬性都包含以下屬性： + `environment_variables` – 包含您已為應用程式定義的任何環境變數。如需詳細資訊，請參閱[環境變數](workingapps-creating.md#workingapps-creating-environment)。 + `domains` – 根據預設，網域是應用程式的簡短名稱，在此範例中為 simplephpapp。若您已指派自訂網域，他們也會出現在這裡。如需詳細資訊，請參閱[使用自訂網域](workingapps-domains.md)。 + `application` – 應用程式的簡短名稱。 + `scm` – 此元素包含從其儲存庫下載應用程式檔案所需的資訊；在此範例中為 Git 儲存庫。 + `database` – 資料庫資訊，如果堆疊包含資料庫層。 + `document_root` – 文件根，`null`在此範例中設定為，表示根為公有。 + `ssl_certificate_ca`、`ssl_support`、 `ssl_certificate_key` – 指出應用程式是否支援 SSL。若有的話，`ssl_certificate_key` 和 `ssl_certificate_ca` 屬性會設為對應的憑證。 + `deploy_to` – 應用程式根目錄。 # 技術指南 101 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。生產層級 OpsWorks 的 Stacks 堆疊通常需要一些[自訂](customizing.md)，這通常表示使用一或多個配方、屬性檔案或範本檔案實作自訂 Chef 技術指南。本主題是實作 Stacks OpsWorks 技術指南的教學簡介。如需 Stacks OpsWorks 如何使用技術指南的詳細資訊，其中包括技術指南的簡短一般簡介，請參閱 [技術指南和配方](workingcookbook.md)。如需如何實作和測試 Chef 配方的額外資訊，請參閱 [Test-Driven Infrastructure with Chef, 2nd Edition](https://www.amazon.com/Test-Driven-Infrastructure-Chef-Behavior-Driven-Development/dp/1449372201/ref=sr_1_fkmr0_1?ie=UTF8&qid=1405556803&sr=8-1-fkmr0&keywords=Test-Driven+Infrastructure+with+Chef%2C+2nd+Edition)。教學範例分為兩個部分： + [技術指南基本概念](cookbooks-101-basics.md)是一組範例演練，適合不熟悉 Chef 的使用者。經驗豐富的 Chef 使用者可以跳過此節。範例會帶您演練如何實作技術指南以執行常見任務 (例如安裝套件或建立目錄) 的基礎。為了簡化程序，您會使用一對有用的工具，[Vagrant](http://docs.vagrantup.com/v2/) 和 [Test Kitchen](http://kitchen.ci/) 來在虛擬機器中本機執行大多數的範例。在開始[技術指南基本概念](cookbooks-101-basics.md)前，建議您先閱讀 [Vagrant 和 Test Kitchen](#cookbooks-101-tools)，了解如何安裝和使用這些工具。由於 Test Kitchen 尚不支援 Windows，因此所有的範例都只適用於 Linux，但會有附註，指示如何改寫以供 Windows 使用。 + [實作 Stacks OpsWorks 的技術指南](cookbooks-101-opsworks.md) 說明如何實作 Stacks OpsWorks 的配方，包括適用於 Windows 堆疊的配方。它還包括一些更進階的，例如如何使用 Berkshelf 來管理外部技術指南。範例是針對新的 Chef 使用者撰寫，與[技術指南基本概念](cookbooks-101-basics.md)中的範例相似。不過 OpsWorks ，Stacks 的運作方式與 Chef 伺服器略有不同，因此我們建議經驗豐富的 Chef 使用者至少閱讀本節。 ## Vagrant 和 Test Kitchen 若您使用適用於 Linux 執行個體的配方，Vagrant 和 Test Kitchen 對於了解和初始開發及測試來說是非常有用的工具。這提供 Vagrant 和 Test Kitchen 的簡短描述，並引導您參閱安裝指示和演練，協助您設定並熟悉如何使用工具的基本概念。雖然 Vagrant 支援 Windows，但 Test Kitchen 不支援，因此針對這些工具只提供 Linux 範例。 ### Vagrant [Vagrant ](http://docs.vagrantup.com/v2/) 提供在虛擬機器上執行和測試程式碼的一致環境。它支援各種環境，稱為 Vagrant 方塊，每個環境都代表設定的作業系統。對於 OpsWorks Stacks，感興趣的環境是以 Ubuntu、Amazon 或 Red Hat Enterprise Linux (RHEL) 發行版本為基礎，因此範例主要使用名為的 Vagrant 方塊`opscode-ubuntu-12.04`。 Vagrant 可供 Linux、Windows 和 Macintosh 系統使用，因此您可以使用您偏好的工作站，在任意支援的作業系統上實作和測試配方。本章的範例是在 Ubuntu Linux 系統上建立的，但將程序翻譯為 Windows 或 Macintosh 系統非常簡單。 Vagrant 基本上就是虛擬化提供者的包裝函式。大多數的範例使用 [VirtualBox](https://www.virtualbox.org/) 提供者。VirtualBox 是免費的，可用於 Linux、Windows 和 Macintosh 系統。若您的系統上還沒有 VirtualBox，Vagrant 演練提供了安裝說明。請注意，您可以在 VirtualBox 上執行 Ubuntu 型環境，但 Amazon Linux 僅適用於 Amazon EC2 執行個體。但是，您可以在 VirtualBox 上執行相似的作業系統 (例如 CentOS)，這對初始開發和測試來說非常有用。如需其他提供者的資訊，請參閱 [Vagrant](http://docs.vagrantup.com/v2/) 文件。特別是，`vagrant-aws`外掛程式提供者可讓您將 Vagrant 與 Amazon EC2 執行個體搭配使用。此提供者在 Amazon Linux 上測試配方特別有用，僅適用於 Amazon EC2 執行個體。`vagrant-aws` 提供者是免費的，但您必須擁有 AWS 帳戶並為您使用的任何 AWS 資源支付費用。此時，建議您參閱 Vagrant 的[入門演練](http://docs.vagrantup.com/v2/getting-started/index.html)。其內容說明了如何在您的工作站上安裝 Vagrant，並教您了解使用 Vagrant 的基礎。請注意，本章內的範例沒有使用 Git 儲存庫，因此若您需要的話，您可以省略演練中的該部分。 ### Test Kitchen [Test Kitchen](http://kitchen.ci/) 可簡化您在 Vagrant 上執行和測試技術指南的程序。實際上來說，您很少需要直接使用 Vagrant。Test Kitchen 會執行大多數的常見任務，包含： + 在 Vagrant 中啟動執行個體。 + 將技術指南傳輸到執行個體。 + 在執行個體上執行技術指南的配方。 + 在執行個體上測試技術指南的配方。 + 使用 SSH 來登入執行個體。相較於直接安裝 Test Kitchen gem，我們建議您安裝 [Chef DK](https://www.chef.io/downloads)。除了 Chef 本身之外，此套件還包含了 Test Kitchen、[Berkshelf](http://berkshelf.com/)、[ChefSpec](https://docs.chef.io/chefspec.html) 和其他幾項有用的工具。此時，建議您參閱 Test Kitchen 的[入門演練](http://kitchen.ci/)。其內容會教您如何使用 Test Kitchen 執行和測試配方的基礎。 **注意** 本章中的範例會使用 Test Kitchen 以方便執行配方。若您偏好的話，您可以在完成手動驗證一節後停止入門演練，因為屆時其內容已涵蓋所有您針對範例需要了解的部分。但是，Test Kitchen 主要是一個支援像是 [Bash 自動化測試系統 (BATS)](https://github.com/sstephenson/bats) 等測試框架的測試平台。建議您在之後找時間完成演練的剩餘部分，以了解如何使用 Test Kitchen 測試您的配方。 # 技術指南基本概念 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用技術指南來完成各式各樣的任務。下列主題假設您不熟悉 Chef，所以會說明如何使用技術指南完成一些常見的任務。由於 Test Kitchen 尚不支援 Windows，因此所有的範例都只適用於 Linux，但會有附註，指示如何改寫以供 Windows 使用。如果您不熟悉 Chef，即使您使用的是 Windows，我們仍建議您演練這些範例。本主題的大部分範例稍加變更都可以在 Windows 執行個體上使用，範例中會註明。所有的範例都是在虛擬機器中執行，因此您甚至都不需要有 Linux 電腦。只需在您平常的工作站上安裝 Vagrant 和 Test Kitchen 即可。 **注意** 如果您想要在 Windows 執行個體上執行這些配方，最簡單的方法是建立 Windows 堆疊，在其中一個堆疊的執行個體上執行這些配方。如需如何在 OpsWorks Stacks Windows 執行個體上執行配方的詳細資訊，請參閱 [在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)。請先確認您已安裝 Vagrant 和 Test Kitchen，並已完成它們的入門演練，再繼續操作。如需詳細資訊，請參閱[Vagrant 和 Test Kitchen](cookbooks-101.md#cookbooks-101-tools)。 **Topics** + [配方結構](cookbooks-101-basics-structure.md) + [範例 1：安裝套件](cookbooks-101-basics-packages.md) + [範例 2：管理使用者](cookbooks-101-basics-users.md) + [範例 3：建立目錄](cookbooks-101-basics-directories.md) + [範例 4：新增流程控制](cookbooks-101-basics-ruby.md) + [範例 5：使用屬性](cookbooks-101-basics-attributes.md) + [範例 6：建立檔案](cookbooks-101-basics-files.md) + [範例 7：執行命令和指令碼](cookbooks-101-basics-commands.md) + [範例 8：管理服務](cookbooks-101-basics-services.md) + [範例 9：使用 Amazon EC2 執行個體](cookbooks-101-basics-ec2.md) + [後續步驟](cookbooks-101-basics-next.md) # 配方結構 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。技術指南主要是一組可在執行個體上執行各種任務的「配方」**。若要釐清如何實作配方，查看簡單的範例會有所幫助。以下是內建 [HAProxy layer](layers-haproxy.md) 的設定配方。這個時候只要關注整體結構，不必太過擔心詳細資訊，後續範例會有相關說明。 ``` package 'haproxy' do action :install end if platform?('debian','ubuntu') template '/etc/default/haproxy' do source 'haproxy-default.erb' owner 'root' group 'root' mode 0644 end end include_recipe 'haproxy::service' service 'haproxy' do action [:enable, :start] end template '/etc/haproxy/haproxy.cfg' do source 'haproxy.cfg.erb' owner 'root' group 'root' mode 0644 notifies :restart, "service[haproxy]" end ``` **注意** 如需此範例和其他範例的工作配方和相關檔案，請參閱 [OpsWorks Stacks 內建配方](https://github.com/aws/opsworks-cookbooks)。此範例強調關鍵的配方元素，下列各節中會詳加說明。 **Topics** + [Resources](#cookbooks-101-basics-structure-resources) + [流量控制](#cookbooks-101-basics-structure-ruby) + [隨附的配方](#cookbooks-101-basics-structure-include) ## Resources 配方的組成主要是一組 Chef「資源」**。它們每一個都會指定特定方面的執行個體最終狀態，例如要安裝的套件或要啟動的服務。此範例有四項資源： + `package` 資源，在本範例中代表已安裝的套件，即 [HAProxy 伺服器](http://haproxy.1wt.eu/)。 + `service` 資源，在本範例中代表服務，即 HAProxy 服務。 + 兩個 `template` 資源，在本範例中代表要從指定的範本建立的檔案，即兩個 HAProxy 組態檔案。資源以宣告的方式指定執行個體狀態。在幕後，每項資源都有一個相關聯的「提供者」**，執行所需的任務，例如安裝套件、建立及設定目錄、啟動服務等等。如果任務的詳細資訊取決於特定的作業系統，則資源會有多個提供者，並會使用最適合系統的那一個。例如，在 Red Hat Linux 系統中，`package` 提供者會使用 `yum` 安裝套件。在 Ubuntu Linux 系統中，`package` 提供者會使用 `apt-get`。您要將資源實作為具有下列一般格式的 Ruby 程式碼區塊。 ``` resource_type "resource_name" do attribute1 'value1' attribute2 'value2' ... action :action_name notifies : action 'resource' end ``` 這些元素是： **Resource Type (資源類型)** (必要) 本範例包括三種資源類型：`package`、`service` 和 `template`。 **資源名稱** (必要) 此名稱可識別特定的資源，有時用為其中一個屬性的預設值。在此範例中，`package` 代表名為 `haproxy` 的套件資源，而第一個 `template` 資源代表名為 `/etc/default/haproxy` 的組態檔案。 **屬性** (選用) 這些屬性會指定資源組態，並會隨著資源類型及您設定資源的方式而不同。 + 此範例的 `template` 資源會明確定義一組屬性，指定已建立的檔案來源、擁有者、群組和模式。 + 此範例的 `package` 和 `service` 資源不會明確定義任何屬性。資源名稱一般是必要屬性的預設值，有時候只需要它就夠了。例如，資源名稱是 `package` 資源之 `package_name` 屬性的預設值，它是唯一需要的屬性。也有一些特殊化的屬性，稱之為保護屬性，它們會指定資源提供者何時採取動作。例如，`only_if` 屬性只有在符合指定條件時，才會指示資源提供者採取動作。HAProxy 配方不使用保護屬性，但下列幾個範例會使用它們。 **動作和通知** (選用) 動作和通知會指定提供者要執行的任務。 + `action` 指示提供者採取指定的動作，例如安裝或建立。每項資源都有一組取決於特定資源的動作，其中一個是預設動作。在此範例中，`package` 資源的動作是 `install`，它會指示提供者安裝套件。第一項 `template` 資源沒有 `action` 元素，所以提供者採取預設的 `create` 動作。 + `notifies` 指示另一項資源的提供者執行動作，但只有在資源狀態變更後。 `notifies` 通常搭配 `template` 和 `file` 等資源使用，執行的任務如在修改組態檔案後重新啟動服務。資源沒有預設的通知。如果您想要有通知，資源必須有明確的 `notifies` 元素。在 HAProxy 配方中，如果相關聯的組態檔案已變更，第二項 `template` 資源會通知 haproxy `service` 資源重新啟動 HAProxy 服務。資源有時取決於作業系統。 + 有些資源只能用於 Linux 或 Windows 系統。例如，[package](https://docs.chef.io/chef/resources.html#package) 會在 Linux 系統上安裝套件，而在 Windows 系統上安裝套件要使用 [windows\$1package](https://docs.chef.io/chef/resources.html#windows-package)。 + 有些資源可搭配任何作業系統，但需要特定系統的專屬屬性。例如，[file](https://docs.chef.io/chef/resources.html#file) 資源可用於 Linux 或 Windows 系統，但設定許可時使用不同的屬性集。如需標準資源的說明，包括每項資源的可用屬性、動作和通知，請參閱[關於資源和提供者](https://docs.chef.io/resource.html)。 ## 流量控制因為配方是 Ruby 應用程式，所以您可以使用 Ruby 控制結構在配方中納入流程控制。例如，您可以使用 Ruby 條件邏輯，讓配方在不同的系統中有不同的行為。HAProxy 配方包含的 `if` 區塊可使用 `template` 資源建立組態檔案，但只有當配方在 Debian 或 Ubuntu 系統中執行時才可以。另一個常見的情況是使用迴圈以不同的屬性設定來多次執行資源。例如，您可以使用迴圈以不同的目錄名稱多次執行 `directory` 資源，來建立一組目錄。 **注意** 如果您不熟悉 Ruby，請參閱[僅足夠適用於 Chef 的 Ruby](https://docs.chef.io/just_enough_ruby_for_chef.html)，其中包含多數配方需要知道的內容。 ## 隨附的配方 `include_recipe` 在您的程式碼中包含其他配方，讓您模組化您的配方，並在多種配方中重複使用相同的程式碼。當您執行主機配方時，Chef 會先使用指定的配方程式碼取代每個 `include_recipe` 元素，再執行主機配方。您使用標準的 Chef `cookbook_name::recipe_name` 語法來納入配方，其中 `recipe_name` 會省略 `.rb` 副檔名。此範例包含的配方 `haproxy::service`，代表 HAProxy 服務。 **注意** 如果您在於 Chef 11.10 和更新版本上執行的配方中使用 `include_recipe` 來納入其他技術指南的配方，即必須使用 `depends` 陳述式在技術指南的 `metadata.rb` 檔案中宣告相依性。如需詳細資訊，請參閱[實作配方：Chef 11.10](workingcookbook-chef11-10.md)。 # 範例 1：安裝套件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。套件安裝是較常用的配方之一，相當簡單，視套件而定。例如，下列配方將 Git 安裝在 Linux 系統中。 ``` package 'git' do action :install end ``` [`package` 資源](https://docs.chef.io/chef/resources.html#package)處理套件安裝。在本範例中，您不需要指定任何屬性。資源名稱是 `package_name` 屬性的預設值，它可以識別套件。`install` 動作指示提供者安裝套件。略過 `install` 可讓程式碼變得更簡單，它是 `package` 資源的預設動作。當您執行配方時，Chef 會使用適當的提供者安裝套件。在本範例要使用的 Ubuntu 系統中，提供者透過呼叫 `apt-get` 來安裝 Git。 **注意** 在 Windows 系統上安裝軟體需要的程序略有不同。如需詳細資訊，請參閱[安裝 Windows 軟體](cookbooks-101-opsworks-install-software.md)。若要使用 Test Kitchen 在 Vagrant 中執行此配方，您必須先設定技術指南，然後初始化及設定 Test Kitchen。下列內容適用於 Linux 系統，但 Windows 和 Macintosh 系統所用的程序基本類似。一開始先開啟終端機視窗，本章的所有範例都使用命令列工具。 **準備技術指南** 1. 在您的主目錄中建立名為 `opsworks_cookbooks` 的子目錄，它會包含本章所有的技術指南。然後，為此技術指南建立名為 `installpkg` 的子目錄中，導覽至它。 1. 在 `installpkg` 中建立名為 `metadata.rb` 的檔案，包含下列程式碼。 ``` name "installpkg" version "0.1.0" ``` 為求簡化，本章的範例只指定技術指南名稱和版本，但 `metadata.rb` 可以包含各種技術指南中繼資料。如需詳細資訊，請參閱 [About Cookbook Metadata](http://docs.chef.io/cookbook_repo.html#about-cookbook-metadata)。 **注意** 初始化 Test Kitchen 之前請務必先建立 `metadata.rb`，它會使用資料建立預設的組態檔案。 1. 在 `installpkg` 中執行 `kitchen init`，這會初始化 Test Kitchen 並安裝預設的 Vagrant 驅動程式。 1. `kitchen init` 命令會在 `installpkg` 中建立名為 `.kitchen.yml` 的 YAML 組態檔案。在您偏好的文字編輯器中開啟檔案。`.kitchen.yml` 檔案包含 `platforms` 區段，指定執行配方的系統。Test Kitchen 會在每個平台上建立執行個體並執行指定的配方。 **注意** Test Kitchen 預設一次只在一個平台上執行配方。如果您在建立執行個體的任何命令中新增 `-p` 參數，Test Kitchen 就會以平行方式在每個平台上執行配方。針對本範例，單一平台即已足夠，所以請編輯 `.kitchen.yml` 以移除 `centos-6.4` 平台。您的 `.kitchen.yml` 檔案現在看起來應如下： ``` --- driver: name: vagrant provisioner: name: chef_solo platforms: - name: ubuntu-12.04 suites: - name: default run_list: - recipe[installpkg::default] attributes: ``` Test Kitchen 只執行 `.kitchen.yml` 執行清單中的配方。您使用 `[cookbook_name::recipe_name]` 格式識別配方，其中 *recipe\$1name* 省略 `.rb` 副檔名。`.kitchen.yml` 執行清單一開始會包含技術指南的預設配方 `installpkg::default`。這是您要實作的配方，因此您不需要修改執行清單。 1. 建立 `installpkg` 的子目錄，名為 `recipes`。如果技術指南包含配方，大多數情況下，它們必須位於 `recipes`子目錄中。您現在可以將配方新增到技術指南，使用 Test Kitchen 在執行個體上執行它。 **執行配方** 1. 建立包含區段開頭處之 Git 安裝範例程式碼名為 `default.rb` 的檔案，並將它儲存到 `recipes` 子目錄中。 1. 在 `installpkg` 目錄中執行 `kitchen converge`。此命令會在 Vagrant 中啟動新的 Ubuntu 執行個體、將技術指南複製到執行個體，並啟動 Chef 執行以執行`.kitchen.yml`執行清單中的配方。 1. 若要驗證配方是否成功，請執行 `kitchen login` 開啟執行個體的 SSH 連線。然後，`git --version` 驗證是否已成功安裝 Git。若要返回您的工作站，請執行 `exit`。 1. 完成後，請執行 `kitchen destroy` 關機執行個體。下一個範例會使用不同的技術指南。此範例是非常好的入門方法，但它非常簡單。其他套件的安裝比較複雜，您可能需要執行下列任一或所有作業： + 建立並設定使用者。 + 建立一或多個資料、日誌等等的目錄。 + 安裝一或多個組態檔案。 + 為不同的作業系統指定不同的套件名稱或屬性值。 + 啟動服務，然後視需要再重新啟動它。下列範例說明如何解決這些問題，以及其他一些有用的操作。 # 範例 2：管理使用者 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。另一個簡單的任務是管理執行個體上的使用者。下列配方會將新的使用者新增到 Linux 執行個體。 ``` user "myuser" do home "/home/newuser" shell "/bin/bash" end ``` 您會使用 [user](https://docs.chef.io/chef/resources.html#user) 資源來管理 Linux 和 Windows 系統上的使用者，不過有些屬性只適用一個系統。範例建立名為 `myuser` 的使用者並指定其主目錄和 shell。不指定任何動作，所以資源會使用預設的 `create` 動作。您可以將屬性新增至 `user` 以指定各種其他設定，例如其密碼或群組 ID。您也可以為修改使用者設定或刪除使用者等相關的使用者管理任務使用 `user`。如需詳細資訊，請參閱 [user](https://docs.chef.io/chef/resources.html#user)。 **執行配方** 1. 在 `opsworks_cookbooks` 內建立並導覽至名為 `newuser` 的目錄。 1. 建立包含下列程式碼的 `metadata.rb` 檔案，並儲存至 `newuser`。 ``` name "newuser" version "0.1.0" ``` 1. 初始化及設定 Test Kitchen (如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述)，並在 `recipes` 目錄中新增 `newuser` 目錄。 1. 將具有範例配方的 `default.rb` 檔案新增至技術指南的 `recipes` 目錄。 1. 執行 `kitchen converge` 以執行配方。 1. 使用 `kitchen login` 登入執行個體，執行 `cat /etc/passwd` 驗證新的使用者是否存在。`myuser` 使用者應位在檔案底部。 # 範例 3：建立目錄 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當您在執行個體上安裝套件時，通常需要建立一些組態檔案並將它們放置在適當的目錄中。不過，這些目錄可能還不存在。您可能還需要建立資料、日誌檔等等的目錄。例如，您首先啟動用於大多數範例的 Ubuntu 系統，`/srv`目錄沒有子目錄。如果您要安裝應用程式伺服器，您可能希望有資料檔案、日誌等等的 `/srv/www/` 目錄，可能還有一些子目錄。下列配方在執行個體上建立 `/srv/www/`。 ``` directory "/srv/www/" do mode 0755 owner 'root' group 'root' action :create end ``` 您使用 [`directory` 資源](https://docs.chef.io/chef/resources.html#directory)在 Linux 和 Windows 系統上建立並設定目錄，但某些屬性的用法不盡相同。資源名稱是用於將資源的 `path` 屬性預設值，因此本範例會建立 `/srv/www/` 並指定其 `mode`、`owner` 和 `group` 屬性。 **執行配方** 1. 在 `opsworks_cookbooks` 中建立名為 `createdir` 的目錄，導覽至它。 1. 初始化及設定 Test Kitchen (如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述)，並在 `recipes` 中新增 `createdir` 目錄。 1. 將具有配方程式碼的 `default.rb` 檔案新增至技術指南的 `recipes` 子目錄。 1. 執行 `kitchen converge` 以執行配方。 1. 執行 `kitchen login`，導覽至 `/srv` 並驗證它是否有 `www` 子目錄。 1. Run `exit` 返回到工作站，但保持執行個體執行。 **注意** 在執行個體中建立主目錄的相對目錄，使用 `#{ENV['HOME']}` 表示主目錄。例如，下列內容會建立 `~/shared` 目錄。 ``` directory "#{ENV['HOME']}/shared" do ... end ``` 假設您想要建立更深的巢狀目錄，例如 `/srv/www/shared`。您可以修改前述配方，如下所示。 ``` directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' action :create end ``` **執行配方** 1. 以前述配方取代 `default.rb` 中的程式碼。 1. 從 `kitchen converge` 目錄執行 `createdir`。 1. 若要確認已確實建立目錄，請執行 `kitchen login`、導覽至 `/srv/www`，然後驗證它是否包含 `shared` 子目錄。 1. 執行 `kitchen destroy` 關閉執行個體。您會發現 `kitchen converge` 命令執行速度更快了。這是因為執行個體已在執行，所以不需要開機執行個體、安裝 Chef 等等。Test Kitchen 只是將更新的技術指南複製到執行個體，並啟動 Chef 執行。現在再次執行 `kitchen converge`，這會在全新的執行個體中執行配方。您現在會看到下列結果。 ``` Chef Client failed. 0 resources updated in 1.908125788 seconds [2014-06-20T20:54:26+00:00] ERROR: directory[/srv/www/shared] (createdir::default line 1) had an error: Chef::Exceptions::EnclosingDirectoryDoesNotExist: Parent directory /srv/www does not exist, cannot create /srv/www/shared [2014-06-20T20:54:26+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1) >>>>>> Converge failed on instance . >>>>>> Please see .kitchen/logs/default-ubuntu-1204.log for more details >>>>>> ------Exception------- >>>>>> Class: Kitchen::ActionFailed >>>>>> Message: SSH exited (1) for command: [sudo -E chef-solo --config /tmp/kitchen/solo.rb --json-attributes /tmp/kitchen/dna.json --log_level info] >>>>>> ---------------------- ``` 發生了什麼？問題是，`directory` 資源預設一次只能建立一個目錄，無法建立目錄鏈。此配方之前可以運作是因為您在執行個體上執行的最初配方已建立 `/srv/www`，因此建立 `/srv/www/shared` 只會建立一個子目錄。 **注意** 當您執行 `kitchen converge` 時，請確定您知道您是在新的或現有的執行個體上執行您的配方。您可能會得到不同的結果。若要建立子目錄鏈，請將 `recursive` 屬性新增至 `directory` 並將它設為 `true`。下列配方會在乾淨的執行個體上建立 `/srv/www/shared` 目錄。 ``` directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end ``` # 範例 4：新增流程控制 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。有些配方只是一系列的 Chef 資源。在這種情況下，當您執行配方時，它僅會依序執行每個資源提供者。不過，有更精密的執行路徑通常會很有幫助。下列是兩個常見情況： + 您想要某個配方以不同的屬性設定多次執行相同的資源。 + 您想要在不同的作業系統上使用不同的屬性設定。您可以將 Ruby 控制結構併入配方以處理類似的情況。本節示範如何修改[範例 3：建立目錄](cookbooks-101-basics-directories.md)中的配方來處理這兩種情況。 **Topics** + [重複](#cookbooks-101-basics-ruby-iteration) + [條件式邏輯](#cookbooks-101-basics-ruby-conditional) ## 重複 [範例 3：建立目錄](cookbooks-101-basics-directories.md)示範如何使用 `directory` 資源來建立目錄或目錄鏈。不過，假設您要建立兩個不同的目錄 `/srv/www/config` 和 `/srv/www/shared`。您可以分別為每個目錄實作目錄資源，但如果您想要建立非常多的目錄，這種方法太過繁瑣。下列配方示範處理此任務的較簡單方式。 ``` [ "/srv/www/config", "/srv/www/shared" ].each do |path| directory path do mode 0755 owner 'root' group 'root' recursive true action :create end end ``` 配方使用包含子目錄路徑的字串集合，而不是為每個子目錄分別使用目錄資源。Ruby `each` 方法從第一個元素開始，為每個集合元素執行一次資源。資源中以 `path` 變數表示元素，在本例中表示目錄路徑。您可以輕鬆地調整此範例建立任意數目的子目錄。 **執行配方** 1. 留在 `createdir` 目錄中，接下來數個範例都會使用該技術指南。 1. 若尚未完成，請執行 `kitchen destroy` 以從乾淨的執行個體開始。 1. 以範例取代 `default.rb` 中的程式碼並執行 `kitchen converge`。 1. 登入執行個體，您會在 `/srv` 下看到新建立的目錄。您可以使用雜湊表為每次重複指定兩個值。下列配方建立 `/srv/www/config` 和 `/srv/www/shared`，每個都有不同的模式。 ``` { "/srv/www/config" => 0644, "/srv/www/shared" => 0755 }.each do |path, mode_value| directory path do mode mode_value owner 'root' group 'root' recursive true action :create end end ``` **執行配方** 1. 若尚未完成，請執行 `kitchen destroy` 以從乾淨的執行個體開始。 1. 以範例取代 `default.rb` 中的程式碼並執行 `kitchen converge`。 1. 登入執行個體，您會在指定模式的 `/srv` 下看到新建立的目錄。 **注意** OpsWorks Stacks 配方通常會使用此方法來從[堆疊組態和部署 JSON](workingcookbook-json.md) 擷取值，基本上是大型雜湊資料表，並將其插入資源。如需範例，請參閱 [部署配方](create-custom-deploy.md)。 ## 條件式邏輯您也可以使用 Ruby 條件式邏輯來建立多個執行分支。下列配方使用 `if-elsif-else` 邏輯來擴展前一個範例，以便建立名為 `/srv/www/shared` 的子目錄，但只限於 Debian 和 Ubuntu 系統。針對所有其他系統，其會記錄顯示在 Test Kitchen 輸出中的錯誤訊息。 ``` if platform?("debian", "ubuntu") directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end else log "Unsupported system" end ``` **執行範例配方** 1. 如果您的執行個體仍在執行中，請執行 `kitchen destroy` 關閉它。 1. 以範例程式碼取代 `default.rb` 中的程式碼。 1. 編輯 `.kitchen.yml` 將 CentOS 6.4 系統新增到平台清單。檔案的 `platforms` 區段看起來應該如下： ``` ... platforms: - name: ubuntu-12.04 - name: centos-6.4 ... ``` 1. 執行 `kitchen converge`，這會建立執行個體，並依序為 `.kitchen.yml` 中的每個平台執行配方。 **注意** 如果您想收歛成僅只一個執行個體，請將執行個體名稱新增為參數。例如，若要將配方收歛成僅在 Ubuntu 平台，請執行 `kitchen converge default-ubuntu-1204`。如果您忘記了平台名稱，只要執行 `kitchen list` 即可。您應該會在 Test Kitchen 的 CentOS 部分看到您的日誌訊息，它看起來類似如下： ``` ... Converging 1 resources Recipe: createdir::default * log[Unsupported system] action write[2014-06-23T19:10:30+00:00] INFO: Processing log[Unsupported system] action write (createdir::default line 12) [2014-06-23T19:10:30+00:00] INFO: Unsupported system [2014-06-23T19:10:30+00:00] INFO: Chef Run complete in 0.004972162 seconds ``` 您現在可以登入執行個體並驗證是否已建立目錄。不過，現在無法僅執行 `kitchen login`。您必須透過附加平台名稱來指定執行個體，例如 `kitchen login default-ubuntu-1204`。 **注意** 如果 Test Kitchen 命令接受執行個體名稱，您就不需要輸入完整的名稱。Test Kitchen 會將執行個體名稱視為 Ruby 規則表達式，因此您只需要可提供唯一相符的足夠字元即可。例如，您可以透過執行 `kitchen converge ub` 收歛成僅 Ubuntu 執行個體，或透過執行 `kitchen login 64` 登入 CentOS 執行個體。此時可能有的疑問，是配方如何知道它在哪個平台上執行。Chef 為收集系統資料 (包括平台) 的每個回合都執行名為 [Ohai](https://docs.chef.io/ohai.html) 的工具，在稱為「節點物件」**的結構中用一組屬性表示此資料。Chef `platform?` 方法使用括號來比較系統和 Ohai 平台值，如果其中一項符合即傳回 true。您可以使用 `node['attribute_name']` 直接參考您程式碼中的節點屬性值。例如，平台值以 `node['platform']` 表示。例如，您可能將前述範例撰寫如下。 ``` if node[:platform] == 'debian' or node[:platform] == 'ubuntu' directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end else log "Unsupported system" end ``` 在配方中包含條件邏輯的常見原因，是為了因應不同的 Linux 系列有時使用不同的套件名稱、目錄等等。例如，Apache 套件名稱在 CentOS 系統為 `httpd`，在 Ubuntu 系統為 `apache2`。如果只是因為不同的系統需要不同的字串，Chef [http://docs.chef.io/dsl_recipe.html#value-for-platform](http://docs.chef.io/dsl_recipe.html#value-for-platform) 方法是比 `if-elsif-else` 更簡單的解決方案。下列配方在 CentOS 系統中建立 `/srv/www/shared` 目錄，在 Ubuntu 系統中建立 `/srv/www/data` 目錄，在所有其他系統中建立 `/srv/www/config`。 ``` data_dir = value_for_platform( "centos" => { "default" => "/srv/www/shared" }, "ubuntu" => { "default" => "/srv/www/data" }, "default" => "/srv/www/config" ) directory data_dir do mode 0755 owner 'root' group 'root' recursive true action :create end ``` `value_for_platform` 將適當的路徑指派給 `data_dir`，而 `directory` 資源則使用該值建立目錄。 **執行範例配方** 1. 如果您的執行個體仍在執行中，請執行 `kitchen destroy` 關閉它。 1. 以範例程式碼取代 `default.rb` 中的程式碼。 1. 執行 `kitchen converge`，然後登入每個執行個體，以驗證是否有適當的目錄。 # 範例 5：使用屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。除平台之外，前面各節中的配方針對所有項目都使用硬式編碼值。這種方法很麻煩，例如，當您想要在多個配方中使用相同的值時。您可以在技術指南中包含屬性檔案，從配方分別定義值。屬性檔案是將值指派給一或多個屬性的 Ruby 應用程式。它必須位在技術指南的 `attributes` 資料夾。Chef 將屬性併入到節點物件，而所有配方可以透過參考屬性使用這些屬性值。本主題示範如何修改[重複](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-iteration)中的配方來使用這些屬性。下列是供參考的原始配方。 ``` [ "/srv/www/config", "/srv/www/shared" ].each do |path| directory path do mode 0755 owner 'root' group 'root' recursive true action :create end end ``` 下列定義子目錄名稱、模式、擁有者和群組值的屬性。 ``` default['createdir']['shared_dir'] = 'shared' default['createdir']['config_dir'] = 'config' default['createdir']['mode'] = 0755 default['createdir']['owner'] = 'root' default['createdir']['group'] = 'root' ``` 注意下列事項： + 每個定義都是以「屬性類型」**開始。如果屬性定義超過一次，可能是在不同屬性檔案中，屬性類型會指定屬性的優先順序，這會決定哪個定義會併入節點物件。如需詳細資訊，請參閱[屬性優先順序](workingcookbook-attributes-precedence.md)。本範例中的所有定義均有 `default` 屬性類型，這是此用途的一般類型。 + 屬性有巢狀名稱。節點物件基本上是可任意深度嵌套的雜湊表，所以屬性名稱可以是、也普遍是巢狀的。此屬性檔案遵循使用巢狀名稱的標準實務，以技術指南名稱 `createdir` 為第一個元素。使用 createdir 為屬性第一個元素的原因是，當您執行 Chef 執行時，Chef 會將每個技術指南的屬性納入節點物件。使用 OpsWorks Stacks，除了您定義的任何屬性之外，節點物件還包含[來自內建技術指南](https://github.com/aws/opsworks-cookbooks)的大量屬性。在屬性名稱中包含技術指南名稱，可降低與其他技術指南屬性名稱發生衝突的風險，特別是當您的屬性名稱類似 `port` 或 `user` 時。除非您想要覆寫該屬性的值，否則請不要將屬性命名為類似 [`[:apache2][:user]`](attributes-recipes-apache.md#attributes-recipes-apache-user)。如需詳細資訊，請參閱[使用自訂技術指南屬性](workingcookbook-cookbook-attributes.md)。下列範例顯示使用屬性的原始配方，不是使用硬式編碼值。 ``` [ "/srv/www/#{node['createdir']['shared_dir']}", "/srv/www/#{node['createdir']['config_dir']}" ].each do |path| directory path do mode node['createdir']['mode'] owner node['createdir']['owner'] group node['createdir']['group'] recursive true action :create end end ``` **注意** 如果您想要將屬性值納入字串中，請用 `#{}` 括住它。在上述範例中，`#{node['createdir']['shared_dir']}` 會將 "shared" 附加到 "/srv/www/" 的後面。 **執行配方** 1. 執行 `kitchen destroy` 以從乾淨的執行個體開始。 1. 以前述的配方範例取代 `recipes/default.rb` 中的程式碼。 1. 建立名為 `createdir` 的 `attributes` 子目錄，並新增包含屬性定義之名為 `default.rb` 的檔案。 1. 編輯 `.kitchen.yml` 將 CentOS 從平台清單中移除。 1. 執行 `kitchen converge`，然後登入執行個體，驗證 `/srv/www/shared` 和 `/srv/www/config` 是否在此。 **注意** 透過 OpsWorks Stacks，將值定義為屬性可提供額外的優點；您可以使用[自訂 JSON](workingstacks-json.md) 來覆寫每個堆疊或甚至每個部署的這些值。這是適用於各種用途，包括：您可以自訂您的配方行為，例如組態設定或使用者名稱，不必修改技術指南。例如，您可以在不同的堆疊使用相同的技術指南，使用自訂 JSON 指定特定堆疊的關鍵組態設定。這可節省您修改技術指南或為每個堆疊使用不同技術指南所需的時間和心力。您不必將資料庫密碼等可能的敏感資訊放在技術指南儲存庫。您可以改用屬性定義預設值，然後使用自訂的 JSON 以真實的值覆寫該值。如需如何使用自訂 JSON 覆寫屬性的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如果是相當簡單的名稱，此屬性檔案名為 `default.rb`，因為它是 Ruby 應用程式。例如，這表示您可以根據作業系統，使用條件式邏輯指定屬性值。在[條件式邏輯](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-conditional)中，您已在配方中為不同的 Linux 系列指定不同的子目錄名稱。使用屬性檔案，您可以改將條件式邏輯放在屬性檔案中。下列屬性檔案使用 `value_for_platform` 指定不同的 `['shared_dir']` 屬性值，視作業系統而定。其他條件可以使用 Ruby `if-elsif-else` 邏輯或 `case` 陳述式。 ``` data_dir = value_for_platform( "centos" => { "default" => "shared" }, "ubuntu" => { "default" => "data" }, "default" => "user_data" ) default['createdir']['shared_dir'] = data_dir default['createdir']['config_dir'] = "config" default['createdir']['mode'] = 0755 default['createdir']['owner'] = 'root' default['createdir']['group'] = 'root' ``` **執行配方** 1. 執行 `kitchen destroy` 從全新的執行個體開始。 1. 以前述範例取代 `attributes/default.rb` 中的程式碼。 1. 編輯 `.kitchen.yml` 將 CentOS 平台新增到平台部分，如[條件式邏輯](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-conditional)中所述。 1. 執行 `kitchen converge`，然後登入執行個體，驗證目錄是否在此。完成後，請執行 `kitchen destroy` 終止執行個體。下一個範例會使用新的技術指南。 # 範例 6：建立檔案 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在您建立目錄之後，您通常需要在目錄中放入組態檔案、資料檔案等等。本主題顯示在執行個體上安裝檔案的兩種方式。 **Topics** + [從技術指南安裝檔案](#cookbooks-101-basics-files-cookbook_file) + [從範本建立檔案](#cookbooks-101-basics-files-template) ## 從技術指南安裝檔案在執行個體上安裝檔案的最簡單方法是使用 [https://docs.chef.io/chef/resources.html#cookbook-file](https://docs.chef.io/chef/resources.html#cookbook-file) 資源，將檔案從技術指南複製到 Linux 和 Windows 系統之執行個體上的指定位置。此範例會擴展[範例 3：建立目錄](cookbooks-101-basics-directories.md)中的配方，在目錄建立之後將資料檔案新增到 `/srv/www/shared`。下列的原始配方提供您參考。 ``` directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end ``` **設定技術指南** 1. 在 `opsworks_cookbooks` 目錄中建立名為 `createfile` 的目錄，導覽至它。 1. 將 `metadata.rb` 檔案新增至具有以下內容的 `createfile`。 ``` name "createfile" version "0.1.0" ``` 1. 初始化及設定 Test Kitchen (如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述)，並從 `platforms` 清單中移除 CentOS。 1. 將 `recipes` 子目錄新增至 `createfile`。要安裝的檔案包含下列 JSON 資料。 ``` { "my_name" : "myname", "your_name" : "yourname", "a_number" : 42, "a_boolean" : true } ``` **設定資料檔案** 1. 將 `files` 子目錄新增至 `createfile`，`default` 子目錄新增至 `files`。所有使用 `cookbook_file` 安裝的檔案都必須位在 `files` 的子目錄中，例如本範例中的 `files/default`。 **注意** 如果您想要為不同的系統指定不同的檔案，您可以將每個系統專屬的檔案放在以系統為名的子資料夾中，例如 `files/ubuntu`。`cookbook_file` 資源會複製適當的系統專屬檔案 (如果有的話)，否則使用 `default` 檔案。如需詳細資訊，請參閱 [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file)。 1. 使用上述範例中的 JSON 建立名為 `example_data.json` 的檔案，然後將它新增至 `files/default`。下列配方會將 `example_data.json` 複製到指定的位置。 ``` directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end cookbook_file "/srv/www/shared/example_data.json" do source "example_data.json" mode 0644 action :create_if_missing end ``` 在目錄資源建立 `/srv/www/shared` 之後，`cookbook_file` 資源會將 `example_data.json` 複製到該目錄，並且設定檔案的使用者、群組和模式。 **注意** `cookbook_file` 資源引入新的動作：`create_if_missing`。您也可以使用 `create` 動作，但這會覆寫現有的檔案。如果您不想覆寫任何內容，請使用 `create_if_missing`，當 `example_data.json` 還不存在時才安裝。 **執行配方** 1. 執行 `kitchen destroy` 從全新的執行個體開始。 1. 建立包含前述配方的 `default.rb` 檔案，並儲存至 `recipes`。 1. 執行 `kitchen converge`，然後登入執行個體，驗證 `/srv/www/shared` 是否包含 `example_data.json`。 ## 從範本建立檔案 `cookbook_file` 資源適合某些用途，但只會安裝技術指南中已有的檔案。[https://docs.chef.io/chef/resources.html#template](https://docs.chef.io/chef/resources.html#template) 透過以動態方式從範本建立檔案，讓您用更有彈性的方式在 Windows 或 Linux 執行個體上安裝檔案。然後，您可以在執行時間判斷檔案的詳細資訊，視需要變更它們。例如，當您啟動執行個體時，您可能希望組態檔案有特定的設定，稍後當您在堆疊中新增更多執行個體時，修改此設定。本範例修改 `createfile` 技術指南以使用 `template` 資源安裝稍為修改的 `example_data.json` 版本。已安裝的檔案看起來如下： ``` { "my_name" : "myname", "your_name" : "yourname", "a_number" : 42, "a_boolean" : true, "a_string" : "some string", "platform" : "ubuntu" } ``` Template 資源通常搭配屬性檔案使用，因此範例會使用一個屬性檔案來定義下列值。 ``` default['createfile']['my_name'] = 'myname' default['createfile']['your_name'] = 'yourname' default['createfile']['install_file'] = true ``` **設定技術指南** 1. 刪除 `createfile` 技術指南的 `files` 目錄及其內容。 1. 將 `attributes` 子目錄新增至 `createfile`，然後將 `default.rb` 檔案新增至包含前述屬性定義的 `attributes`。範本是一種 `.erb` 檔案，基本上是最終檔案的複本，某些內容由預留位置表示。當 `template` 資源建立檔案時，會將範本的內容複製到指定的檔案，以其獲指派的值覆寫預留位置。下列為 `example_data.json` 範本。 ``` { "my_name" : "<%= node['createfile']['my_name'] %>", "your_name" : "<%= node['createfile']['your_name'] %>", "a_number" : 42, "a_boolean" : <%= @a_boolean_var %>, "a_string" : "<%= @a_string_var %>", "platform" : "<%= node['platform'] %>" } ``` 這些 `<%=...%>` 值是預留位置。 + `<%=node[...]%>` 表示節點屬性值。在此範例中，"your\$1name" 值是表示技術指南屬性檔案中其中一個屬性值的預留位置。 + 如前文所述，`<%=@...%>` 表示範本資源中定義的變數值。 **建立範本檔案** 1. 將 `templates` 子目錄新增至 `createfile` 技術指南，`default` 子目錄新增至 `templates`。 **注意** `templates` 目錄的作用如同 `files` 目錄。您可以將系統專屬範本放入以系統為名的子目錄，例如 `ubuntu`。`template` 資源會使用適當的系統專屬範本 (如果有的話)，否則使用 `default` 範本。 1. 建立名為 `example_data.json.erb` 的檔案，放入 `templates/default` 目錄。範本可使用任意名稱，但通常會在檔案名稱後附加 `.erb`，包括任何副檔名。下列配方使用 `template` 資源建立 `/srv/www/shared/example_data.json`。 ``` directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end template "/srv/www/shared/example_data.json" do source "example_data.json.erb" mode 0644 variables( :a_boolean_var => true, :a_string_var => "some string" ) only_if {node['createfile']['install_file']} end ``` 此 `template` 資源從範本建立 `example_data.json`，然後將它安裝在 `/srv/www/shared`。 + 範本名稱 `/srv/www/shared/example_data.json`，指定已安裝檔案的路徑和名稱。 + `source` 屬性指定建立檔案所使用的範本。 + `mode` 屬性指定已安裝檔案的模式。 + 資源會定義兩個變數：`a_boolean_var` 和 `a_string_var`。當資源建立 `example_data.json` 時，會使用資源中的對應值覆寫範本中的變數預留位置。 + `only_if` *guard* 屬性指示資源只有當 `['createfile']['install_file']` 設為 `true` 時才建立檔案。 **執行配方** 1. 執行 `kitchen destroy` 從全新的執行個體開始。 1. 以前述範例取代 `recipes/default.rb` 中的程式碼。 1. 執行 `kitchen converge`，然後登入執行個體，驗證檔案是否位於 `/srv/www/shared` 且具有正確的內容。完成後，請執行 `kitchen destroy` 關機執行個體。下一節使用新的技術指南。 # 範例 7：執行命令和指令碼 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Chef 資源可以處理執行個體上的各式任務，但有時使用 shell 命令或指令碼會更好。例如，您可能已有用以達成特定任務的指令碼，而且繼續使用它們比實作新程式碼更容易。本節示範如何在執行個體上執行命令或指令碼。 **Topics** + [執行命令](#cookbooks-101-basics-commands-script) + [執行指令碼](#cookbooks-101-basics-commands-execute) ## 執行命令 [https://docs.chef.io/chef/resources.html#script](https://docs.chef.io/chef/resources.html#script) 資源執行一或多個命令。它支援 csh、bash、Perl、Python 和 Ruby 命令解譯器，因此只要安裝適當的轉譯器，就可以用於 Linux 或 Windows 系統。本主題示範如何在 Linux 執行個體上執行簡單的 bash 命令。Chef 也支援 [powershell\$1script](https://docs.chef.io/chef/resources.html#powershell-script) 和 [batch](https://docs.chef.io/chef/resources.html#batch) 資源在 Windows 上執行指令碼。如需詳細資訊，請參閱[執行 Windows PowerShell 指令碼](cookbooks-101-opsworks-opsworks-powershell.md)。 **開始使用** 1. 在 `opsworks_cookbooks` 目錄中建立名為 `script` 的目錄，導覽至它。 1. 將 `metadata.rb` 檔案新增至具有以下內容的 `script`。 ``` name "script" version "0.1.0" ``` 1. 初始化及設定 Test Kitchen (如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述)，並從 `platforms` 清單中移除 CentOS。 1. 在 `script` 中建立名為 `recipes` 的目錄。您可以使用 `script` 資源本身執行命令，但 Chef 也支援資源的一組命令解譯器特定版本，以解譯器為名。下列配方使用 [https://docs.chef.io/chef/resources.html#bash](https://docs.chef.io/chef/resources.html#bash) 資源執行簡單的 bash 指令碼。 ``` bash "install_something" do user "root" cwd "/tmp" code <<-EOH touch somefile EOH not_if do File.exists?("/tmp/somefile") end end ``` `bash` 資源設定如下。 + 它使用預設動作 `run`，在 `code` 區塊中執行命令。此範例有一個命令 `touch somefile`，但 `code` 區塊可以包含多個命令。 + `user` 屬性指定執行命令的使用者。 + `cwd` 屬性指定工作目錄。在此範例中，`touch` 會在 `/tmp` 目錄中建立檔案。 + 如果檔案已存在，`not_if` 保護屬性指示資源不採取任何動作。 **執行配方** 1. 建立包含前述範例程式碼的 `default.rb` 檔案，並將它儲存至 `recipes`。 1. 執行 `kitchen converge`，然後登入執行個體，驗證檔案是否位於 `/tmp`。 ## 執行指令碼 `script` 資源很方便，尤其是當您只需要執行一或兩個命令時，但通常將指令碼存放在檔案中並執行該檔案會更好。[https://docs.chef.io/chef/resources.html#execute](https://docs.chef.io/chef/resources.html#execute) 資源在 Linux 或 Windows 上執行指定的可執行檔，包括指令碼檔案。本主題修改前述範例中的 `script` 技術指南，使用 `execute` 執行簡單的 shell 指令碼。您可以輕鬆將此範例擴展為較複雜的指令碼，或其他類型的可執行檔。 **設定指令碼檔案** 1. 將 `files` 子目錄新增至 `script`，`default` 子目錄新增至 `files`。 1. 建立包含下列內容且名為 `touchfile` 的檔案，將它新增至 `files/default`。本範例中使用常見的 Bash 解譯器程式碼，但如有需要可取代為您 shell 環境中使用的解譯器。 ``` #!/usr/bin/env bash touch somefile ``` 指令碼檔案可以包含任意數目的命令。為了方便起見，此範例指令碼只有單一 `touch` 命令。下列配方執行指令碼。 ``` cookbook_file "/tmp/touchfile" do source "touchfile" mode 0755 end execute "touchfile" do user "root" cwd "/tmp" command "./touchfile" end ``` `cookbook_file` 資源將指令碼檔案複製到 `/tmp`，並設定模式讓檔案變成可執行檔。然後 `execute` 資源執行此檔案，如下所示： + `user` 屬性指定命令的使用者 (本範例中為 `root`)。 + `cwd` 屬性指定工作目錄 (本範例中為 `/tmp`)。 + 此 `command` 屬性指定要執行的指令碼 (本範例中為 `touchfile`)，位於工作目錄。 **執行配方** 1. 以前述範例取代 `recipes/default.rb` 中的程式碼。 1. 執行 `kitchen converge`，然後登入執行個體以驗證 `/tmp` 現在包含模式設定為 0755 的指令碼檔案以及 `somefile`。完成後，請執行 `kitchen destroy` 關機執行個體。下一節使用新的技術指南。 # 範例 8：管理服務 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。應用程式伺服器等套件，通常會有相關聯的服務，必須啟動、停止、重新啟動等等。例如，在安裝套件或執行個體完成開機之後，您需要啟動 Tomcat 服務，每次修改組態檔案後也要重新啟動服務。本主題以 Tomcat 應用程式伺服器為例，討論如何在 Linux 執行個體上管理服務的基本概念。細節上雖有一些差異，但 service 資源的作用在 Windows 執行個體上極其相似。如需詳細資訊，請參閱[https://docs.chef.io/chef/resources.html#service](https://docs.chef.io/chef/resources.html#service)。 **注意** 此範例執行 Tomcat 最小安裝，僅足以示範如何使用 `service` 資源的基本概念。如需如何實作配方以取得更多 Tomcat 伺服器功能的範例，請參閱[建立自訂 Tomcat 伺服器 Layer](create-custom.md)。 **Topics** + [定義及啟動服務](#cookbooks-101-basics-services-service) + [使用通知來啟動或重新啟動服務](#cookbooks-101-basics-services-notifies) ## 定義及啟動服務本節說明如何定義及啟動服務的基本概念。 **開始使用** 1. 在 `opsworks_cookbooks` 目錄中建立名為 `tomcat` 的目錄，導覽至它。 1. 將 `metadata.rb` 檔案新增至具有以下內容的 `tomcat`。 ``` name "tomcat" version "0.1.0" ``` 1. 初始化及設定 Test Kitchen (如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述)，並從 `platforms` 清單中移除 CentOS。 1. 將 `recipes` 子目錄新增至 `tomcat`。您要使用 [https://docs.chef.io/chef/resources.html#service](https://docs.chef.io/chef/resources.html#service) 資源管理服務。下列預設配方安裝 Tomcat 並啟動服務。 ``` execute "install_updates" do command "apt-get update" end package "tomcat7" do action :install end include_recipe 'tomcat::service' service 'tomcat' do action :start end ``` 配方會執行下列動作： + `execute` 資源執行 `apt-get update` 安裝最新的系統更新。對於此範例中使用的 Ubuntu 執行個體，您必須先安裝更新，才能安裝 Tomcat。其他系統可能會有不同的需求。 + `package` 資源安裝 Tomcat 7。 + 包含在內的 `tomcat::service` 配方會定義服務並在後文中討論。 + `service` 資源啟動 Tomcat 服務。您也可以使用此資源發出其他命令，例如停止和重新啟動服務。下列範例顯示 `tomcat::service` 配方。 ``` service 'tomcat' do service_name "tomcat7" supports :restart => true, :reload => false, :status => true action :nothing end ``` 此配方會建立 Tomcat 服務定義，如下所示： + 其他配方使用資源名稱 `tomcat` 參考服務。例如，`default.rb` 參考 `tomcat` 以啟動服務。 + `service_name` 資源指定服務名稱。當您列出執行個體上的服務時，Tomcat 服務即命名為 tomcat7。 + `supports` 指定 Chef 如何管理服務的 `restart`、`reload` 和 `status` 命令。 + `true` 表示 Chef 可使用 init 指令碼或其他服務提供者執行命令。 + `false` 表示 Chef 必須嘗試使用其他方式執行命令。請注意，`action` 設為 `:nothing`，指示資源不採取任何動作。服務資源不支援 `start` 和 `restart` 等動作。不過，此技術指南會遵循使用服務定義的標準實務，不採取任何動作，在其他位置啟動或重新啟動服務。每個啟動或重新啟動服務的配方，都必須先行定義，以便使用最簡單的方法將服務定義放在不同的配方中，並視需要將其包含在其他配方中。 **注意** 為求簡化，此範例的預設配方會在執行服務定義後，使用 `service` 資源啟動服務。生產實作通常會使用 `notifies` 啟動或重新啟動服務，如後文所述。 **執行配方** 1. 建立包含預設配方範例的 `default.rb` 檔案，並將它儲存至 `recipes`。 1. 建立包含服務定義範例的 `service.rb` 檔案，並將它儲存至 `recipes`。 1. 執行 `kitchen converge`，然後登入執行個體，執行下列命令驗證服務是否正在執行。 ``` sudo service tomcat7 status ``` **注意** 如果您從 `default.rb` 分別執行 `service.rb`，您即必須編輯 `.kitchen.yml` 將 `tomcat::service` 新增到執行清單。不過，當您包含配方時，其程式碼會先納入父配方，再執行配方。因此，`service.rb` 基本上已是 `default.rb` 的一部分，而不需要另一個執行清單項目。 ## 使用通知來啟動或重新啟動服務生產實作通常不使用 `service` 啟動或重新啟動服務。而是將 `notifies` 新增到數個資源之中的任一個。例如，如果您想要在修改組態檔案後重新啟動服務，請將 `notifies` 包含在相關聯的 `template` 資源中。使用 `notifies` 明確重新啟動服務，比使用 `service` 資源的更有優勢，如下所示。 + `notifies` 元素只會在相關聯的組態檔案變更時才會重新啟動服務，所以沒有重新啟動不必要服務的風險。 + 無論回合包含多少個 `notifies`，Chef 在每個回合結束時最多重新啟動服務一次。例如，Chef 執行可能包含多項範本資源，它們每一個都會修改不同的組態檔案，檔案變更後需要重新啟動服務。不過，在 Chef 執行結束後，您通常只會想要重新啟動服務一次。否則，您可能嘗試重新啟動在前面重新啟動中尚未完全運作的服務，這會導致錯誤。此範例會修改 `tomcat::default` 以包含 `template` 資源，使用 `notifies` 重新啟動服務。實際範例會使用範本資源建立其中一個 Tomcat 組態檔案的自訂版本，但這些檔案又長又複雜。為求簡化，此範例只使用[從範本建立檔案](cookbooks-101-basics-files.md#cookbooks-101-basics-files-template)中的範本資源。它和 Tomcat 沒有任何關係，但會提供簡單的方式，示範如何使用 `notifies`。如需如何使用範本建立 Tomcat 組態檔案的範例，請參閱[安裝配方](create-custom-setup.md)。 **設定技術指南** 1. 將 `templates` 子目錄新增至 `tomcat`，`default` 子目錄新增至 `templates`。 1. 將 `example_data.json.erb` 範本從 `createfile` 技術指南複製到 `templates/default` 目錄。 1. 將 `attributes` 子目錄新增至 `tomcat`。 1. 將 `default.rb` 屬性檔案從 `createfile` 技術指南複製到 `attributes` 目錄。下列配方使用 `notifies` 重新啟動 Tomcat 服務。 ``` execute "install_updates" do command "apt-get update" end package "tomcat7" do action :install end include_recipe 'tomcat::service' service 'tomcat' do action :enable end directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end template "/srv/www/shared/example_data.json" do source "example_data.json.erb" mode 0644 variables( :a_boolean_var => true, :a_string_var => "some string" ) only_if {node['createfile']['install_file']} notifies :restart, resources(:service => 'tomcat') end ``` 此範例將[從範本建立檔案](cookbooks-101-basics-files.md#cookbooks-101-basics-files-template)中的配方合併到上一節的配方，有兩大變更： + `service` 資源仍然存在，但用途略有不同。 `:enable` 動作可在開機時啟用 Tomcat 服務。 + 範本資源現在包含 `notifies`，如果 `example_data.json` 有所變更，則會重新啟動 Tomcat 服務。這可確保每次組態變更之後，Tomcat 一經安裝和重新啟動即啟動服務。 **執行配方** 1. 執行 `kitchen destroy` 以從乾淨的執行個體開始。 1. 以前述範例取代 `default.rb` 中的程式碼。 1. 執行 `kitchen converge`，然後登入執行個體，驗證服務是否正在執行。 **注意** 如果您想要重新啟動服務，但配方不包含支援 `template` 的 `notifies` 等資源，您可改用虛擬 `execute` 資源。例如 ``` execute 'trigger tomcat service restart' do command 'bin/true' notifies :restart, resources(:service => 'tomcat') end ``` `execute` 資源必須有 `command` 屬性，即使您只是使用資源來執行 `notifies`。此範例透過執行 `/bin/true` 規避需求，這個 shell 命令只會傳回成功代碼。 # 範例 9：使用 Amazon EC2 執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。此時，您一直在本機的 VirtualBox 中執行執行個體。雖然這快速又簡單，但您最終會想要在 Amazon EC2 執行個體上測試配方。特別是，如果您想要在 Amazon Linux 上執行配方，它只能在 Amazon EC2 上使用。您可以使用類似的系統，例如 CentOS 進行初步實作和測試，但在 Amazon Linux 上完整測試配方的唯一方法是使用 Amazon EC2 執行個體。本主題說明如何在 Amazon EC2 執行個體上執行配方。Test Kitchen 和 Vagrant 的使用方法和前面各節差不多，但有兩點不同： + 驅動程式是 [https://rubygems.org/gems/kitchen-ec2](https://rubygems.org/gems/kitchen-ec2)，不是 Vagrant。 + 技術指南`.kitchen.yml`的檔案必須設定啟動 Amazon EC2 執行個體所需的資訊。 **注意** 另一種方法是使用 `vagrant-aws` Vagrant 外掛程式。如需詳細資訊，請參閱 [Vagrant AWS 提供者](https://github.com/mitchellh/vagrant-aws)。您需要 AWS 登入資料才能建立 Amazon EC2 執行個體。如果您沒有 AWS 帳戶，您可以取得一個，如下所示。 ## 註冊 AWS 帳戶如果您沒有 AWS 帳戶，請完成下列步驟來建立一個。 **註冊 AWS 帳戶** 1. 開啟 [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)。 1. 請遵循線上指示進行。部分註冊程序需接收來電或簡訊，並在電話鍵盤輸入驗證碼。當您註冊時 AWS 帳戶，*AWS 帳戶根使用者*會建立。根使用者有權存取該帳戶中的所有 AWS 服務和資源。作為安全最佳實務，請將管理存取權指派給使用者，並且僅使用根使用者來執行[需要根使用者存取權的任務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 AWS 會在註冊程序完成後傳送確認電子郵件給您。您可以隨時登錄 [https://aws.amazon.com/](https://aws.amazon.com/) 並選擇**我的帳戶**，以檢視您目前的帳戶活動並管理帳戶。 ## 建立具有管理存取權的使用者註冊後 AWS 帳戶，請保護 AWS 帳戶根使用者、啟用 AWS IAM Identity Center和建立管理使用者，以免將根使用者用於日常任務。 **保護您的 AWS 帳戶根使用者** 1. 選擇**根使用者**並輸入 AWS 帳戶您的電子郵件地址，以帳戶擁有者[AWS 管理主控台](https://console.aws.amazon.com/)身分登入。在下一頁中，輸入您的密碼。如需使用根使用者登入的說明，請參閱 *AWS 登入使用者指南*中的[以根使用者身分登入](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)。 1. 若要在您的根使用者帳戶上啟用多重要素驗證 (MFA)。如需說明，請參閱《*IAM 使用者指南*》中的[為您的 AWS 帳戶根使用者（主控台）啟用虛擬 MFA 裝置](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html)。 **建立具有管理存取權的使用者** 1. 啟用 IAM Identity Center。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[啟用 AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)。 1. 在 IAM Identity Center 中，將管理存取權授予使用者。如需使用 IAM Identity Center 目錄做為身分來源的教學課程，請參閱*AWS IAM Identity Center 《使用者指南*》中的[使用預設值設定使用者存取 IAM Identity Center 目錄](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html)。 **以具有管理存取權的使用者身分登入** + 若要使用您的 IAM Identity Center 使用者簽署，請使用建立 IAM Identity Center 使用者時傳送至您電子郵件地址的簽署 URL。如需使用 IAM Identity Center 使用者登入的說明，請參閱*AWS 登入《使用者指南*》中的[登入 AWS 存取入口網站](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)。 **指派存取權給其他使用者** 1. 在 IAM Identity Center 中，建立一個許可集來遵循套用最低權限的最佳實務。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[建立許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-a-permission-set.html)。 1. 將使用者指派至群組，然後對該群組指派單一登入存取權。如需指示，請參閱《AWS IAM Identity Center 使用者指南》**中的[新增群組](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)。您應該[建立具有存取 Amazon EC2 許可的 IAM 使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html)，並將使用者的存取和私密金鑰儲存至工作站上的安全位置。 Amazon EC2 Test Kitchen 會使用這些登入資料建立執行個體。向 Test Kitchen 提供登入資料，最好是將金鑰指派給您工作站的下列環境變數。 **警告** IAM 使用者具有長期憑證，這會造成安全風險。為了協助降低此風險，建議您只為這些使用者提供執行任務所需的許可，並在不再需要這些使用者時將其移除。 + AWS\$1ACCESS\$1KEY – 使用者的存取金鑰，看起來像 AKIAIOSFODNN7EXAMPLE。 + AWS\$1SECRET\$1KEY – 使用者的私密金鑰，看起來像 wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY。此方法可以減少意外危害您帳戶的機率，例如，將包含您登入資料的專案上傳到公有儲存庫。 **設定技術指南** 1. 若要使用 `kitchen-ec2` 驅動程式，您必須在您的系統上安裝 `ruby-dev` 套件。下列範例命令說明如何使用 `aptitude` 將套件安裝在 Ubuntu 系統。 ``` sudo aptitude install ruby1.9.1-dev ``` 1. `kitchen-ec2` 驅動程式是 Gem 套件，安裝方式如下： ``` gem install kitchen-ec2 ``` 視您的工作站而定，此命令可能需要 `sudo`，或者您也可以使用 Ruby 環境管理員，例如 [RVM](https://rvm.io/)。此程序已經 `kitchen-ec2` 驅動程式 0.8.0 版測試，但現有更新版本。若要安裝[特定版本](https://rubygems.org/gems/kitchen-ec2/versions)，請執行 `gem install kitchen-ec2 -v `。 1. 您必須指定 Test Kitchen 可用來連線至執行個體的 Amazon EC2 SSH 金鑰對。如果您沒有 Amazon EC2 金鑰對，請參閱 [Amazon EC2 金鑰對，以取得如何建立金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)的資訊。請注意，金鑰對必須屬於與執行個體相同的 AWS 區域。此範例使用美國西部（加利佛尼亞北部）。在您選取金鑰對後，請建立名為 `opsworks_cookbooks` 的 `ec2_keys` 子目錄，將金鑰對的私有金鑰 (`.pem`) 檔案複製到該子目錄。請注意，將私有金鑰放在 `ec2_keys` 中，只為方便略微簡化程式碼，它可在您系統上的任何位置。 1. 建立並導覽至名為 `createdir-ec2` 的 `opsworks_cookbooks` 子目錄。 1. 將 `metadata.rb` 檔案新增至具有以下內容的 `createdir-ec2`。 ``` name "createdir-ec2" version "0.1.0" ``` 1. 初始化 Test Kitchen，如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述。下一節說明如何設定 `.kitchen.yml`，這對於 Amazon EC2 執行個體來說更為複雜。 1. 將 `recipes` 子目錄新增至 `createdir-ec2`。 ## 為 Amazon EC2 設定 .kitchen.yml 您可以使用`kitchen-ec2`驅動程式啟動適當設定`.kitchen.yml`之 Amazon EC2 執行個體所需的資訊來設定。以下是美國西部（加利佛尼亞北部）區域中 Amazon Linux 執行個體`.kitchen.yml`的檔案範例。 ``` driver: name: ec2 aws_ssh_key_id: US-East1 region: us-west-1 availability_zone: us-west-1c require_chef_omnibus: true security_group_ids: sg........ subnet_id: subnet-......... associate_public_ip: true interface: dns provisioner: name: chef_solo platforms: -name: amazon driver: image_id: ami-xxxxxxxx transport: username: ec2-user ssh_key: ../ec2_keys/US-East1.pem suites: - name: default run_list: - recipe[createdir-ec2::default] attributes: ``` 您可以使用 `provisioner` 和 `suites` 區段的預設設定，但必須修改預設的 `driver` 和 `platforms` 設定。此範例使用最少的設定清單，接受餘數的預設值。如需完整的 `kitchen-ec2` 設定清單，請參閱 [Kitchen::Ec2：適用於 Amazon EC2 的 Test Kitchen 驅動程式](https://github.com/test-kitchen/kitchen-ec2)。此範例設定下列 `driver` 屬性。假設您已將使用者存取金鑰和秘密金鑰指派給標準環境變數，如前所述。驅動程式預設使用這些金鑰。否則，您必須將 `aws_access_key_id` 和 `aws_secret_access_key` 新增至 `driver` 屬性，設為適當的金鑰值，明確指定金鑰。 **name** (必要) 此屬性必須設定為 `ec2`。 **aws\$1ssh\$1key\$1id** （必要） Amazon EC2 SSH 金鑰對名稱，`US-East1`在此範例中名為。 **transport.ssh\$1key** (必要) 您為 `aws_ssh_key_id` 指定之金鑰的私有金鑰 (`.pem`) 檔案。在本範例中，此檔案名為 `US-East1.pem`，位在 `../opsworks/ec2_keys` 目錄中。 **region** (必要) 執行個體的 AWS 區域。此範例使用美國西部（加利佛尼亞北部），由表示`us-west-1`)。 **availability\$1zone** (選用) 執行個體的可用區域。如果您省略此設定，Test Kitchen 會使用指定區域的預設可用區域，`us-west-1b`即美國西部（加利佛尼亞北部）。不過，您的帳戶可能無法使用預設區域。在這種情況下，您必須明確指定可用區域。發生這種情況時，用來準備範例的帳戶不會支援 `us-west-1b`，所以範例會明確指定 `us-west-1c`。 **require\$1chef\$1omnibus** 設為 `true` 時，此設定會確保使用 omnibus 安裝程式在所有平台執行個體上安裝 `chef-client`。 **security\$1group\$1ids** (選用) 套用到執行個體的安全群組 ID 清單。此設定會將 `default` 安全群組套用到執行個體。請確定安全群組傳入規則允許送入 SSH 連線，否則 Test Kitchen 無法與執行個體通訊。如果您使用 `default` 安全群組，您可能需要因應情況編輯它。如需詳細資訊，請參閱 [Amazon EC2 安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)。 **subnet\$1id** 執行個體的目標子網路 ID (如適用)。 **associate\$1public\$1ip** 如果您想要能夠從網際網路存取執行個體，則可以讓 Amazon EC2 將公有 IP 地址與執行個體建立關聯。 **interface** 您用來存取執行個體的主機名稱組態類型。有效值為 `dns`、`public`、`private` 或 `private_dns`。如果您不指定此屬性的值，`kitchen-ec2` 會以下列順序設定主機名稱組態。如果略過此屬性，即不設定組態類型。 1. DNS 名稱 1. 公有 IP 地址 1. 私有 IP 地址 1. 私有 DNS 名稱 **重要** 您應該建立使用者並將這些登入資料提供給 Test Kitchen，而不是將您的帳戶登入資料用於存取和私密金鑰。如需詳細資訊，請參閱[管理 AWS 存取金鑰的最佳實務](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)。請小心不要將 `.kitchen.yml` 放在公開存取的位置；例如，上傳到 GitHub 或 Bitbucket 的公有儲存庫。這麼做會公開您的登入資料，而且可能會危害您帳戶的安全性。 `kitchen-ec2` 驅動程式為下列平台提供預設的支援： + ubuntu-10.04 + ubuntu-12.04 + ubuntu-12.10 + ubuntu-13.04 + ubuntu-13.10 + ubuntu-14.04 + centos-6.4 + debian-7.1.0 + windows-2012r2 + windows-2008r2 如果您想要使用一或多個這些平台，請將適當的平台名稱新增至 `platforms`。`kitchen-ec2` 驅動程式會自動選取適當的 AMI 並產生 SSH 使用者名稱。您可以使用其他平台，此範例使用 Amazon Linux，但您必須明確指定下列`platforms`屬性。 **name** 平台名稱。此範例使用 Amazon Linux，所以 `name` 設為 `amazon`。 **driver** `driver` 屬性包含下列項目： + `image_id` – 平台的 AMI，必須屬於指定的區域。此範例使用 `ami-ed8e9284`，這是來自美國西部（加利佛尼亞北部）區域的 Amazon Linux AMI。 + `transport.username` – Test Kitchen 用來與執行個體通訊的 SSH 使用者名稱。針對 Amazon Linux，請使用 `ec2-user`。其他 AMI 可能會有不同的使用者名稱。以範例取代 `.kitchen.yml` 中的程式碼，將適當的值指派給帳戶專屬屬性，例如 `aws_access_key_id`。 ## 執行配方此範例使用[重複](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-iteration)中的配方。 **執行配方** 1. 使用下列程式碼建立名為 `default.rb` 的檔案，並將它儲存到技術指南的 `recipes` 資料夾。 ``` directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end ``` 1. 執行 `kitchen converge` 以執行配方。請注意，由於啟動和初始化 Amazon EC2 執行個體所需的時間，此命令的完成時間會比先前的範例更長。 1. 前往 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/)，選取美國西部（加利佛尼亞北部）) 區域，然後按一下導覽窗格中**的執行個體**。您會在清單中看到新建立的執行個體。 1. 執行 `kitchen login` 登入執行個體，就像您對在 VirtualBox 中執行的執行個體做的那樣。您會在 `/srv` 下看到新建立的目錄。您也可以使用您最愛的 SSH 用戶端連線到執行個體。 # 後續步驟 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本章會引導您了解如何實作 Chef 技術指南的基本概念，但仍有許多等您發掘： + 此範例向您示範了如何使用一些較常用的資源，但還有很多等您發掘。在涵蓋的資源中，範例只使用了一些可用的屬性和動作。如需完整參考，請參閱[關於資源和提供者](https://docs.chef.io/resource.html)。 + 這些範例只使用了核心技術指南元素：`recipes`、`attributes`、`files` 和 `templates`。技術指南也可以包含各種其他元素，例如 `libraries`、`definitions` 和 `specs`。如需詳細資訊，請參閱 [Chef 文件](https://docs.chef.io)。 + 這些範例只將 Test Kitchen 用為啟動執行個體、執行配方及登入執行個體的便利方法。 Test Kitchen 主要是一種測試平台，您可用來對您的配方執行各種測試。如果還未嘗試過，請試試其他的 [Test Kitchen 演練](https://kitchen.ci/docs/getting-started/introduction/)，了解其測試功能。 + [實作 Stacks OpsWorks 的技術指南](cookbooks-101-opsworks.md) 提供一些更進階的範例，並說明如何實作 Stacks OpsWorks 的技術指南。 # 實作 Stacks OpsWorks 的技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 [技術指南基本概念](cookbooks-101-basics.md) 介紹技術指南和配方。該區段中的範例設計簡單，可用於支援 Chef 的任何執行個體，包括 OpsWorks Stacks 執行個體。若要為 OpsWorks Stacks 實作更複雜的技術指南，您通常需要充分利用 OpsWorks Stacks 環境，這與標準 Chef 有許多不同之處。本主題說明實作 Stacks OpsWorks 執行個體配方的基本概念。 **注意** 如果您不熟悉如何實作技術指南，則應該開始使用[技術指南基本概念](cookbooks-101-basics.md)。 **Topics** + [在 Stacks Linux OpsWorks 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md) + [在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md) + [執行 Windows PowerShell 指令碼](cookbooks-101-opsworks-opsworks-powershell.md) + [在 Vagrant 上模擬堆疊組態和部署屬性](opsworks-opsworks-mock.md) + [使用堆疊組態和部署屬性值](cookbooks-101-opsworks-opsworks-stack-config.md) + [在 Linux 執行個體上使用外部技術指南：Berkshelf](cookbooks-101-opsworks-berkshelf.md) + [使用適用於 Ruby 的開發套件：從 Amazon S3 下載檔案](cookbooks-101-opsworks-s3.md) + [安裝 Windows 軟體](cookbooks-101-opsworks-install-software.md) + [覆寫內建屬性](cookbooks-101-opsworks-attributes.md) + [覆寫內建範本](cookbooks-101-opsworks-templates.md) # 在 Stacks Linux OpsWorks 執行個體上執行配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Test Kitchen 和 Vagrant 提供簡單且有效率的方式來實作技術指南，但為了驗證技術指南的配方在生產環境中正確執行，您必須在 OpsWorks Stacks 執行個體上執行它們。本主題說明如何在 OpsWorks Stacks Linux 執行個體上安裝自訂技術指南，以及執行簡單配方。本主題也提供一些有效修復配方錯誤的秘訣。如需如何在 Windows 執行個體上執行配方的描述，請參閱[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)。 **Topics** + [建立和執行配方](#opsworks-opsworks-instance-create) + [自動執行配方](#cookbooks-101-opsworks-opsworks-instance-events) + [故障診斷和修復手冊](#cookbooks-101-opsworks-opsworks-instance-bugs) ## 建立和執行配方首先，您需要建立堆疊。以下簡短地彙總如何針對此範例建立堆疊。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後按一下 **Add Stack (新增堆疊)**。 1. 指定下列設定，並接受其他設定的預設值，然後按一下 **Add Stack (新增堆疊)**。 + **名稱** – OpsTest + **預設 SSH 金鑰** – Amazon EC2 金鑰對如果您需要建立 Amazon EC2 金鑰對，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。請注意，金鑰對必須屬於與執行個體相同的 AWS 區域。此範例使用預設的美國西部（奧勒岡）區域。 1. 按一下 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – OpsTest + **簡短名稱**：opstest 任何 layer 類型都會實際作用於 Linux 堆疊，但此範例不需要其他 layer 類型所安裝的任何套件，因此自訂 layer 是最簡單的方法。 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 layer，以及[啟動它](workinginstances-starting.md)。當執行個體啟動時，您通常需要幾分鐘的時間來建立技術指南。此範例將使用[條件式邏輯](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-conditional)中稍微修改過的配方版本，這會建立其名稱取決於平台的資料目錄。 **設定技術指南** 1. 在 `opsworks_cookbooks` 內建立並導覽至名為 `opstest` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `opstest`。 ``` name "opstest" version "0.1.0" ``` 1. 在 `recipes` 內建立 `opstest` 目錄。 1. 使用下列配方建立 `default.rb` 檔案，並將它儲存至 `recipes` 目錄。 ``` Chef::Log.info("******Creating a data directory.******") data_dir = value_for_platform( "centos" => { "default" => "/srv/www/shared" }, "ubuntu" => { "default" => "/srv/www/data" }, "default" => "/srv/www/config" ) directory data_dir do mode 0755 owner 'root' group 'root' recursive true action :create end ``` 請注意，配方會記錄訊息，但做法是呼叫 `Chef::Log.info`。您在此範例中未使用 Test Kitchen，因此 `log`方法不太有用。會將訊息`Chef::Log.info`放入 Chef 日誌中，您可以在 Chef 執行完成後讀取該日誌。 OpsWorks Stacks 提供檢視這些日誌的簡單方法，如下所述。 **注意** Chef 日誌通常包含許多例行作業和相對無趣的資訊。括住訊息文字的 '\$1' 字元可讓您更輕鬆地找到它們。 1. 建立 `opsworks_cookbooks` 的 `.zip` 存檔。若要在 OpsWorks Stacks 執行個體上安裝技術指南，您必須將其存放在儲存庫中，並提供 Stacks OpsWorks 將技術指南下載至執行個體所需的資訊。您可以將技術指南存放至任何數個支援的儲存庫類型中。此範例會將包含技術指南的封存檔案存放在 Amazon S3 儲存貯體中。如需技術指南儲存庫的詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。 **注意** 為求簡化，此範例只會封存整個 `opsworks_cookbooks` 目錄。不過，這表示 Stacks OpsWorks 會將中的所有技術指南下載`opsworks_cookbooks`到執行個體，即使您只使用其中一個技術指南。若只要安裝範例技術指南，請建立另一個父目錄，並將 `opstest` 移至該目錄。然後，建立父目錄的 `.zip` 封存，並使用它，而非 `opsworks_cookbooks.zip`。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 1. [將封存上傳至 Amazon S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)，[將封存設為公](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)有，並記錄封存的 URL。您現在可以安裝技術指南，並執行配方。 **執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 封存** + **儲存庫 URL** – 您先前記錄的技術指南封存 URL 針對其他設定使用預設值，然後按一下 **Save (儲存)** 以更新堆疊組態。 1. [執行更新自訂技術指南堆疊命令](workingstacks-commands.md)，以在堆疊執行個體上安裝最新版的自訂技術指南。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 使用配方執行**執行執行配方**堆疊命令**以執行設定為的配方****opstest::default**。此命令會啟動 Chef 執行，內含包含 `opstest::default` 的回合清單。成功執行配方之後，您就可以驗證配方。 **驗證 opstest** 1. 第一步是檢查 [Chef 日誌](troubleshoot-debug-log.md)。按一下 **** opstest1 執行個體**日誌**欄中的顯示以顯示日誌。向下捲動，您會在接近底端看到您的日誌訊息。 ``` ... [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/attributes/customize.rb in the cache. [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/metadata.rb in the cache. [2014-07-31T17:01:46+00:00] INFO: ******Creating a data directory.****** [2014-07-31T17:01:46+00:00] INFO: Processing template[/etc/hosts] action create (opsworks_stack_state_sync::hosts line 3) ... ``` 1. [使用 SSH 登入執行個體](workinginstances-ssh.md)，並列出 `/srv/www/` 的內容。如果您已遵循所有步驟，則會看到 `/srv/www/config`，而不是您預期的 `/srv/www/shared` 目錄。下節提供一些快速修復這類錯誤的指導方針。 ## 自動執行配方 **Execute Recipes (執行配方)** 命令是一種輕鬆測試自訂配方的方法，這是在其中大部分範例中使用它的原因。不過，實際上，您通常會在執行個體生命週期中的標準點執行配方，例如在執行個體完成開機後或部署應用程式時。 OpsWorks Stacks 透過支援每一層的一組[生命週期事件](workingcookbook-events.md)，簡化執行個體上執行的配方：設定、設定、部署、取消部署和關機。您可以將配方指派給適當的生命週期事件，讓 OpsWorks Stacks 在 layer 的執行個體上自動執行配方。您通常會在執行個體完成開機時立即建立目錄，這對應至安裝事件。以下顯示如何使用您稍早在範例中建立的相同堆疊，在安裝時執行範例配方。您可以針對其他事件使用相同的程序。 **在安裝時自動執行配方** 1. 選擇導覽窗格中的 **Layers (Layer)**，然後選擇 OpsTest layer 之 **Recipes (配方)** 連結旁的鉛筆圖示。 1. 將 **opstest::default** 新增至 layer 的 **Setup (安裝)** 配方，並按一下 **\$1** 將它新增至 layer，然後選擇 **Save (儲存)** 儲存組態。 1. 選擇 **Instances (執行個體)**，並將另一個執行個體新增至 layer，然後啟動它。執行個體應該命名為 `opstest2`。開機完成後， OpsWorks Stacks 會執行 `opstest::default`。 1. 在 `opstest2` 執行個體上線之後，請驗證 `/srv/www/shared` 已存在。 **注意** 如果您已將配方指派給安裝、設定或部署事件，則也會手動執行它們，方法是使用[堆疊命令](workingstacks-commands.md) (安裝和設定) 或[部署命令](workingapps-deploying.md) (部署) 來觸發事件。請注意，如果您有多個指派給事件的配方，則這些命令會執行所有配方。 ## 故障診斷和修復手冊如果您未取得預期的結果，或您的配方甚至未成功執行，則故障診斷通常會從檢查 Chef 日誌開始。它包含執行的詳細描述，而且包括您配方中的任何內嵌日誌訊息。如果您的配方失敗，則日誌特別有用。發生該情況時，Chef 會記錄錯誤 (包括堆疊追蹤)。如果配方成功 (如此範例所示)，則 Chef 日誌通常不怎麼有幫助。在這種情況下，只要仔細查看配方 (特別是前幾行)，就可以找出問題所在： ``` Chef::Log.info("******Creating a data directory.******") data_dir = value_for_platform( "centos" => { "default" => "/srv/www/shared" }, "ubuntu" => { "default" => "/srv/www/data" }, "default" => "/srv/www/config" ) ... ``` 當您在 Vagrant 上測試配方時，CentOS 是 Amazon Linux 的適用備用方法，但現在您將在實際 Amazon Linux 執行個體上執行。Amazon Linux 的平台值是 `amazon`，但未包含在 `value_for_platform` 呼叫中，因此配方會建立 `/srv/www/config`。如需故障診斷的詳細資訊，請參閱[偵錯和故障診斷指南](troubleshoot.md)。現在您已找到問題，您需要更新配方並驗證修復。您可以返回原始來源檔案、更新 `default.rb`、上傳新的封存至 Amazon S3，以此類推。不過，該程序可能有點繁瑣且耗時。下列更快速的方式特別適用於簡單配方錯誤 (例如範例中的配方錯誤)：編輯執行個體上的配方。 **編輯執行個體上的配方** 1. 使用 SSH 登入執行個體，然後執行 `sudo su` 以提升您的權限。您需要有 root 權限才能存取技術指南目錄。 1. OpsWorks Stacks 會將您的技術指南存放在中`/opt/aws/opsworks/current/site-cookbooks`，因此請導覽至 `/opt/aws/opsworks/current/site-cookbooks/opstest/recipes`。 **注意** OpsWorks Stacks 也會將技術指南的副本存放在中`/opt/aws/opsworks/current/merged-cookbooks`。請不要編輯該技術指南。當您執行配方時， OpsWorks Stacks 會將技術指南從複製到 `.../site-cookbooks` `.../merged-cookbooks`，因此您在中所做的任何變更`.../merged-cookbooks`都會遭到覆寫。 1. 在執行個體上使用文字編輯器來編輯 `default.rb`，並將 `centos` 取代為 `amazon`。您的配方現在看起來應該與下列類似。 ``` Chef::Log.info("******Creating a data directory.******") data_dir = value_for_platform( "amazon" => { "default" => "/srv/www/shared" }, "ubuntu" => { "default" => "/srv/www/data" }, "default" => "/srv/www/config" ) ... ``` 若要驗證修復，請重新執行 **Execute Recipe (執行配方)** 堆疊命令來執行配方。執行個體現在應該會有一個 `/srv/www/shared` 目錄。如果您需要進一步變更配方，則可以經常執行 **Execute Recipe (執行配方)**；每次執行命令時，並不需要停止並重新啟動執行個體。對配方正確運作感到滿意後，請不要忘記更新您來源技術指南中的程式碼。 **注意** 如果您已將配方指派給生命週期事件，讓 OpsWorks Stacks 自動執行它，您一律可以使用**執行配方**來重新執行配方。您也可以使用 Stacks OpsWorks 主控台手動觸發適當的事件，以任意次數重新執行配方，而無需重新啟動執行個體。不過，此方式會執行事件的所有配方。提醒如下：使用[堆疊命令](workingstacks-commands.md)來觸發安裝或設定事件。使用[部署命令](workingapps-deploying.md)來觸發部署或解除部署事件。 # 在 Windows 執行個體上執行配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本主題基本上是[在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)的縮短版本，顯示如何在 Windows 堆疊上執行配方。建議您先參閱[在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)，因為它提供更多詳細討論，其中大部分都是與任一種作業系統有關。如需如何在 Stacks Linux OpsWorks 執行個體上執行配方的說明，請參閱 [在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)。 **Topics** + [啟用 RDP 存取](#cookbooks-101-opsworks-opsworks-windows-rdp) + [建立和執行配方](#cookbooks-101-opsworks-opsworks-windows-run-recipe) + [自動執行配方](#cookbooks-101-opsworks-opsworks-windows-event) ## 啟用 RDP 存取開始之前，如果您尚未這麼做，則必須設定安全群組，其具有允許 RDP 存取您執行個體的傳入規則。您在建立堆疊時將會需要該群組。當您在區域中建立第一個堆疊時， OpsWorks Stacks 會建立一組安全群組。其中包括一個名為的物件`AWS-OpsWorks-RDP-Server`，例如， Stacks OpsWorks 會連接到所有 Windows 執行個體以允許 RDP 存取。不過，此安全群組預設沒有任何規則，因此您必須新增傳入規則來允許 RDP 存取您的執行個體。 **允許 RDP 存取** 1. 開啟 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2/v2/)，將其設定為堆疊的區域，然後從導覽窗格中選擇**安全群組**。 1. 選擇 **AWS-OpsWorks-RDP-Server**，並選擇 **Inbound (傳入)** 標籤，然後選擇 **Edit (編輯)**。 1. 新增具有下列設定的規則： + **類型** – **RDP** + **來源** – 允許的來源 IP 地址。通常，您會允許來自您 IP 地址或指定 IP 地址範圍 (通常是公司的 IP 地址範圍) 的傳入 RDP 請求。 **注意** 如稍後所述，您還必須編輯使用者許可來授權 RDP 存取一般使用者。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。 ## 建立和執行配方以下簡短地彙總如何針對此範例建立堆疊。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。指定下列設定，並接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)**。 + **名稱** – WindowsRecipeTest + **區域** – 美國西部（奧勒岡）此範例適用於任何區域，但我們建議您使用美國西部（奧勒岡）進行教學課程。 + **預設作業系統** – Microsoft Windows Server 2012 R2 1. 選擇 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – RecipeTest + **簡短名稱** – recipetest 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 RecipeTest layer，以及[啟動它](workinginstances-starting.md)。 OpsWorks Stacks 會自動指派給`AWS-OpsWorks-RDP-Server`此執行個體，允許授權使用者登入執行個體。 1. 選擇 **Permissions (許可)**，並選擇 **Edit (編輯)**，然後選擇 **SSH/RDP** 和 **sudo/admin**。除了 `AWS-OpsWorks-RDP-Server` 安全群組之外，一般使用者還需要有此授權，才能登入執行個體。 **注意** 您也可以登入為管理員，但需要不同的程序。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。當執行個體啟動時，您通常需要幾分鐘的時間來建立技術指南。此範例的配方會建立資料目錄，而且基本上是[範例 3：建立目錄](cookbooks-101-basics-directories.md) (針對 Windows 所修改) 中的配方。 **注意** 實作 Stacks Windows OpsWorks 執行個體的技術指南時，您使用的目錄結構與實作 Stacks Linux OpsWorks 執行個體的技術指南略有不同。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。 **設定技術指南** 1. 建立並導覽至名為 `windowstest` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `windowstest`。 ``` name "windowstest" version "0.1.0" ``` 1. 在 `recipes` 內建立 `windowstest` 目錄。 1. 使用下列配方建立 `default.rb` 檔案，並將它儲存至 `recipes` 目錄。 ``` Chef::Log.info("******Creating a data directory.******") directory 'C:\data' do rights :full_control, 'instance_name\username' inherits false action :create end ``` 將 *username* 取代為您的使用者名稱。 1. 將技術指南放在儲存庫中。若要在 Stacks OpsWorks 執行個體上安裝技術指南，您必須將其存放在儲存庫中，並提供 Stacks OpsWorks 將技術指南下載至執行個體所需的資訊。您可以將 Windows 技術指南存放為 S3 儲存貯體或 Git 儲存庫中的封存檔。此範例使用 S3 儲存貯體，因此您必須建立 `windowstest` 目錄的 .zip 封存。如需技術指南儲存庫的詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。 1. [將封存上傳至 S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)，並[將封存設為公有](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)，然後記錄封存的 URL。您也可以使用私有封存，但在此範例中公有封存就已足夠，而且使用起來更為簡單。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。您現在可以安裝技術指南，並執行配方。 **執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 封存** + **儲存庫 URL** – 您先前記錄的技術指南封存 URL 接受其他設定的預設值，然後選擇 **Save (儲存)** 以更新堆疊組態。 1. [執行更新自訂技術指南堆疊命令](workingstacks-commands.md)，以在堆疊執行個體上安裝最新版的自訂技術指南 (包括線上執行個體)。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 更新自訂技術指南完成後，透過使用配方執行[**執行配方堆疊**命令](workingstacks-commands.md)**以執行設定為的配方****windowstest::default**。此命令會啟動 Chef 執行，內含包含您配方的回合清單。成功執行配方之後，您就可以驗證配方。 **驗證 windowstest** 1. 檢查 [Chef 日誌](troubleshoot-debug-log.md)。選擇 ****opstest1 執行個體**日誌**欄中的顯示以顯示日誌。向下捲動，您會在接近底端看到您的日誌訊息。 ``` ... [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/attributes/customize.rb in the cache. [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/metadata.rb in the cache. [2014-07-31T17:01:46+00:00] INFO: ******Creating a data directory.****** [2014-07-31T17:01:46+00:00] INFO: Processing template[/etc/hosts] action create (opsworks_stack_state_sync::hosts line 3) ... ``` 1. 選擇**執行個體**，在執行個體**的動作**欄中選擇 **rdp**，並請求具有適當過期時間的 RDP 密碼。複製 DNS 名稱、使用者名稱和密碼。您接著可以搭配使用該資訊與 RDP 用戶端 (例如 Windows 遠端桌面連線用戶端) 來登入執行個體，然後驗證 `c:\data` 已存在。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。 **注意** 如果您的配方未正常運作，請參閱[故障診斷和修復手冊](cookbooks-101-opsworks-opsworks-instance.md#cookbooks-101-opsworks-opsworks-instance-bugs)中的故障診斷秘訣；其中大部分也適用於 Windows 執行個體。如果您想要在執行個體上編輯配方來測試修正，請在 `C:\chef\cookbooks`目錄中尋找您的技術指南，其中 OpsWorks Stacks 會安裝自訂技術指南。 ## 自動執行配方 **Execute Recipes (執行配方)** 命令是一種輕鬆測試自訂配方的方法，這是在其中大部分範例中使用它的原因。不過，實際上您通常會在執行個體生命週期中的標準點執行配方，例如在執行個體完成開機後或部署應用程式時。 OpsWorks Stacks 透過支援每一層的一組[生命週期事件](workingcookbook-events.md)，簡化執行個體上執行的配方：設定、設定、部署、取消部署和關機。您可以將配方指派給適當的生命週期事件，讓 OpsWorks Stacks 在 layer 的執行個體上自動執行配方。您通常會在執行個體完成開機時立即建立目錄，這對應至安裝事件。以下顯示如何使用您稍早在範例中建立的相同堆疊，在安裝時執行範例配方。您可以針對其他事件使用相同的程序。 **在安裝時自動執行配方** 1. 選擇導覽窗格中的 **Layers (Layer)**，然後選擇 RecipeTest layer 之 **Recipes (配方)** 連結旁的鉛筆圖示。 1. 將 **windowstest::default** 新增至 layer 的 **Setup (安裝)** 配方，並選擇 **\$1** 將它新增至 layer，然後選擇 **Save (儲存)** 儲存組態。 1. 選擇 **Instances (執行個體)**，並將另一個執行個體新增至 layer，然後啟動它。執行個體應該命名為 `recipetest2`。開機完成後， OpsWorks Stacks 會執行 `windowstest::default`。 1. 在 `recipetest2` 執行個體上線之後，請驗證 `c:\data` 已存在。 **注意** 如果您已將配方指派給安裝、設定或部署事件，則也可以手動執行它們，方法是使用[堆疊命令](workingstacks-commands.md) (安裝和設定) 或[部署命令](workingapps-deploying.md) (部署) 來觸發事件。請注意，如果您有多個指派給事件的配方，則這些命令會執行所有配方。 # 執行 Windows PowerShell 指令碼 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些範例假設您已完成[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)範例。否則，您應該先執行該範例。具體而言，它說明如何[啟用 RDP 存取](cookbooks-101-opsworks-opsworks-windows.md#cookbooks-101-opsworks-opsworks-windows-rdp)您的執行個體。讓配方在 Windows 執行個體上執行任務的一種方式，特別是沒有對應 Chef 資源的任務，就是讓配方執行 Windows PowerShell 指令碼。本節說明如何使用 Windows PowerShell 指令碼安裝 Windows 功能，以介紹基本概念。 [https://docs.chef.io/chef/resources.html#powershell-script](https://docs.chef.io/chef/resources.html#powershell-script) 資源會在執行個體上執行 Windows PowerShell cmdlet。下列範例使用 [Install-WindowsFeature Cmdlet](https://technet.microsoft.com/en-us/library/hh849795.aspx) 以在執行個體上安裝 XPS 檢視器。以下簡短地彙總如何針對此範例建立堆疊。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。指定下列設定，並接受其他設定的預設值，然後按一下 **Add Stack (新增堆疊)**。 + **名稱** – PowerShellTest + **區域** – 美國西部（奧勒岡）此範例適用於任何區域，但我們建議您使用美國西部（奧勒岡）進行教學課程。 + **預設作業系統** – Microsoft Windows Server 2012 R2 1. 選擇 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – PowerShell + **簡短名稱** – powershell 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 PowerShell layer，以及[啟動它](workinginstances-starting.md)。 1. 選擇 **Permissions (許可)**，並選擇 **Edit (編輯)**，然後選取 **SSH/RDP** 和 **sudo/admin**。除了 `AWS-OpsWorks-RDP-Server` 安全群組之外，您還需要有此授權，才能以一般使用者身分登入執行個體。當執行個體啟動時，通常需要幾分鐘的時間，您可以建立技術指南。此範例的配方會建立資料目錄，而且基本上是[範例 3：建立目錄](cookbooks-101-basics-directories.md) (針對 Windows 所修改) 中的配方。 **設定技術指南** 1. 建立並導覽至名為 `powershell` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `windowstest`。 ``` name "powershell" version "0.1.0" ``` 1. 在 `recipes` 目錄內，建立 `powershell` 目錄。 1. 使用下列配方建立 `default.rb` 檔案，並將它儲存至 `recipes` 目錄。 ``` Chef::Log.info("******Installing XPS.******") powershell_script "Install XPS Viewer" do code <<-EOH Install-WindowsFeature XPS-Viewer EOH guard_interpreter :powershell_script not_if "(Get-WindowsFeature -Name XPS-Viewer).installed" end ``` + `powershell_script` 資源會執行 Cmdlet 來安裝 XPS 檢視器。此範例只會執行一個 Cmdlet，但 `code` 區塊可以包含任意數目的命令列。 + `guard_interpreter` 屬性會指示 Chef 使用 64 位元版本的 Windows PowerShell。 + `not_if` 保護屬性可確保 Chef 不會安裝已安裝的功能。 1. 建立 `powershell` 目錄的 `.zip` 存檔。 1. [將封存上傳至 Amazon S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)，[將封存設為公](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)有，並記錄封存的 URL。您也可以使用私有封存，但在此範例中公有封存就已足夠，而且使用起來更為簡單。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。您現在可以安裝技術指南，並執行配方。 **執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 封存** + **儲存庫 URL** – 您先前記錄的技術指南封存 URL 接受其他設定的預設值，然後選擇 **Save (儲存)** 以更新堆疊組態。 1. [執行 **Update Custom Cookbooks (更新自訂技術指南)** 堆疊命令](workingstacks-commands.md)，以在堆疊執行個體上安裝最新版的自訂技術指南。 1. **更新自訂技術指南**完成後，使用配方執行[**執行配方堆疊**命令](workingstacks-commands.md)**以執行設定為的配方****powershell::default**。 **注意** 為了方便起見，此範例使用**執行配方**，但您通常會讓 OpsWorks Stacks 透過將配方指派給適當的生命週期事件來[自動執行](workingcookbook-assigningcustom.md)配方。您可以手動觸發事件來執行這類配方。您可以使用堆疊命令來觸發安裝和設定事件，以及使用[部署命令](workingapps-deploying.md)來觸發部署和解除部署事件。成功執行配方之後，您就可以驗證配方。 **驗證 powershell 配方** 1. 檢查 [Chef 日誌](troubleshoot-debug-log.md)。按一下 powershell1 執行個體**日誌**欄中的**顯示**以顯示日誌。向下捲動，您會在接近底端看到您的日誌訊息。 ``` ... [2015-04-27T18:12:09+00:00] INFO: Storing updated cookbooks/powershell/metadata.rb in the cache. [2015-04-27T18:12:09+00:00] INFO: ******Installing XPS.****** [2015-04-27T18:12:09+00:00] INFO: Processing powershell_script[Install XPS Viewer] action run (powershell::default line 3) [2015-04-27T18:12:09+00:00] INFO: Processing powershell_script[Guard resource] action run (dynamically defined) [2015-04-27T18:12:42+00:00] INFO: powershell_script[Install XPS Viewer] ran successfully ... ``` 1. [使用 RDP 登入執行個體](workinginstances-rdp.md)，並開啟 **Start (開始)** 選單。XPS 檢視器應該與 **Windows Accessories (Windows 附屬應用程式)** 一起列出。 # 在 Vagrant 上模擬堆疊組態和部署屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題僅適用於 Linux 執行個體。Test Kitchen 尚未支援 Windows，因此您將在 Stacks 執行個體上執行所有 Windows OpsWorks 範例。 OpsWorks Stacks 會將[堆疊組態和部署屬性](workingcookbook-json.md)新增至堆疊中每個生命週期事件每個執行個體的節點物件。這些屬性提供堆疊組態的快照，包括每 layer 和其線上執行個體的組態、每個已部署應用程式的組態，以此類推。由於這些屬性位於節點物件中，因此任何配方都可以存取它們；大多數 Stacks OpsWorks 執行個體的配方會使用一或多個這些屬性。在 Vagrant 方塊中執行的執行個體不是由 Stacks OpsWorks 管理，因此其節點物件預設不會包含任何堆疊組態和部署屬性。不過，您可以將適合的屬性集新增至 Test Kitchen 環境。Test Kitchen 接著會將屬性新增至執行個體的節點物件，而您的配方可以像在 Stacks OpsWorks 執行個體上一樣存取屬性。本主題顯示如何取得適合堆疊組態和部署屬性的複本、在執行個體上安裝屬性，以及存取它們。 **注意** 如果您使用 Test Kitchen 在配方上執行測試，則 [fauxhai](https://github.com/customink/fauxhai) 提供替代方法來模擬堆疊組態和部署 JSON。 **設定技術指南** 1. 建立並導覽至名為 `printjson` 的 `opsworks_cookbooks` 子目錄。 1. 初始化並設定 Test Kitchen，如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述。 1. 將兩個子目錄新增至 `printjson`：`recipes` 和 `environments`。您可以將具有適當定義的屬性檔案新增至技術指南，來模擬堆疊組態和部署屬性，但更佳的方式是使用 Test Kitchen 環境。有兩種基本方式： + 將屬性定義新增至 `.kitchen.yml`。如果您只有幾個屬性，則此方式最為有用。如需詳細資訊，請參閱 [kitchen.yml](https://docs.chef.io/config_yml_kitchen.html)。 + 在環境檔案中定義屬性，並參考 `.kitchen.yml` 中的檔案。此方式通常適用於堆疊組態和部署屬性，因為環境檔案已為 JSON 格式。您可以從適當的 Stacks OpsWorks 執行個體取得 JSON 格式的屬性副本，並直接貼上。所有範例都會使用環境檔案。建立您技術指南的堆疊組態和部署屬性的最簡單方法是建立已適當設定的堆疊，以及從執行個體複製產生的屬性且其格式為 JSON。為了讓 Test Kitchen 環境易於管理，您可以接著編輯該 JSON 檔案，使其只具有您配方所需的屬性。本章中的範例根據[Chef 11 Linux 堆疊入門](gettingstarted.md) 中的堆疊，此簡單 PHP 應用程式伺服器堆疊具有一個負載平衡器、多部 PHP 應用程式伺服器和一個 MySQL 資料庫伺服器。 **建立堆疊組態和部署 JSON** 1. 如[Chef 11 Linux 堆疊入門](gettingstarted.md) 中所述，建立 MyStack (包括部署 SimplePHPApp)。如果您願意，可以省略在中呼叫的第二個 PHP App Server 執行個體[步驟 4：橫向擴展 MyStack](gettingstarted-scale.md)；範例不會使用這些屬性。 1. 如果您尚未這麼做，則請啟動 `php-app1` 執行個體，然後[使用 SSH 登入](workinginstances-ssh.md)。 1. 在終端機視窗中，執行下列 [agent cli](agent.md) 命令： ``` sudo opsworks-agent-cli get_json ``` 此命令會將執行個體的最新堆疊組態和部署屬性以 JSON 格式列印到終端機視窗。 1. 將 JSON 複製至 `.json` 檔案，並將它儲存至工作站上的方便位置。詳細資訊取決於 SSH 用戶端。例如，如果您在 Windows 上使用 PuTTY，則可以執行 `Copy All to Clipboard` 命令，以將終端機視窗中的所有文字都複製至 Windows 剪貼簿。您接著可以將內容貼入 `.json` 檔案，並編輯檔案以移除多餘的文字。 1. 視需要編輯 MyStack JSON。堆疊組態和部署屬性有很多，而且技術指南通常只會使用其中的一小部分。為了讓環境檔案易於管理，您可以編輯 JSON，讓它保留原始結構，但只包含您技術指南實際使用的屬性。此範例使用大量編輯過的 MyStack JSON 版本，其中僅包含兩個 `['opsworks']['stack']` 屬性：`['id]` 和 `['name']`。建立編輯過的 MyStack JSON 版本，看起來與下列類似： ``` { "opsworks": { "stack": { "name": "MyStack", "id": "42dfd151-6766-4f1c-9940-ba79e5220b58", }, }, } ``` 若要讓此 JSON 進入執行個體的節點物件，您需要將它新增至 Test Kitchen 環境。 **將堆疊組態和部署屬性新增至 Test Kitchen 環境** 1. 使用下列內容建立名為 `test.json` 的環境檔案，並將它儲存至技術指南的 `environments` 資料夾。 ``` { "default_attributes": { "opsworks" : { "stack" : { "name" : "MyStack", "id" : "42dfd151-6766-4f1c-9940-ba79e5220b58" } } }, "chef_type" : "environment", "json_class" : "Chef::Environment" } ``` 環境檔案具有下列元素： + `default_attributes` – JSON 格式的預設屬性。這些屬性會新增至具有 `default` 屬性類型的節點物件，這是所有堆疊組態和部署 JSON 屬性所使用的類型。此範例使用先前顯示且編輯過的堆疊組態和部署 JSON 版本。 + `chef_type` – 將此元素設定為 `environment`。 + `json_class` – 將此元素設定為 `Chef::Environment`。 1. 編輯 `.kitchen.yml` 來定義 Test Kitchen 環境，如下所示。 ``` --- driver: name: vagrant provisioner: name: chef_solo environments_path: ./environments platforms: - name: ubuntu-12.04 suites: - name: printjson provisioner: solo_rb: environment: test run_list: - recipe[printjson::default] attributes: ``` 您可以將下列元素新增至 `kitchen init` 所建立的預設 `.kitchen.yml`，來定義環境。 **provisioner** 新增下列元素。 + `name` – 將此元素設定為 `chef_solo`。若要更緊密地複寫 OpsWorks Stacks 環境，您可以使用 [Chef 用戶端本機模式](https://docs.chef.io/ctl_chef_client.html)，而不是 Chef 獨佔。本機模式是一個 Chef 用戶端選項，使用在執行個體上本機執行的輕量版 Chef 伺服器 (Chef Zero)，而非遠端伺服器。這可讓您的配方使用 Chef 伺服器功能，例如未連線至遠端伺服器的搜尋或資料包。 + `environments_path` – 技術指南子目錄，其中包含環境檔案，在此範例中`./environments`為。 **suites:provisioner** 新增 `solo_rb` 元素，但其 `environment` 元素設定為環境檔案名稱並去除 .json 副檔名。此範例將 `environment` 設定為 `test`。 1. 使用下列內容建立名為 `default.rb` 的配方檔案，並將它儲存至技術指南的 `recipes` 目錄。 ``` log "Stack name: #{node['opsworks']['stack']['name']}" log "Stack id: #{node['opsworks']['stack']['id']}" ``` 此配方只會記錄您新增至環境的兩個堆疊組態和部署值。雖然配方是在 Virtual Box 本機執行，但您可以使用與配方在 Stacks OpsWorks 執行個體上執行時相同的節點語法來參考這些屬性。 1. 執行 `kitchen converge`。您應該會看到與下列類似的日誌輸出。 ``` ... Converging 2 resources Recipe: printjson::default * log[Stack name: MyStack] action write[2014-07-01T23:14:09+00:00] INFO: Processing log[Stack name: MyStack] action write (printjson::default line 1) [2014-07-01T23:14:09+00:00] INFO: Stack name: MyStack * log[Stack id: 42dfd151-6766-4f1c-9940-ba79e5220b58] action write[2014-07-01T23:14:09+00:00] INFO: Processing log[Stack id: 42dfd151-6766-4f1c-9940-ba79e5220b58] action write (printjson::default line 2) [2014-07-01T23:14:09+00:00] INFO: Stack id: 42dfd151-6766-4f1c-9940-ba79e5220b58 ... ``` # 使用堆疊組態和部署屬性值 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。配方通常需要堆疊組態或已部署應用程式的相關資訊。例如，您可能需要有堆疊 IP 地址清單才能建立組態檔案，或需要有應用程式的部署目錄才能建立日誌目錄。 OpsWorks Stacks 不會將此資料儲存在中央伺服器上，而是為每個生命週期事件在每個執行個體的節點物件中安裝一組堆疊組態和部署屬性。這些屬性代表目前堆疊狀態 (包括已部署的應用程式)。配方接著可以從節點物件取得它們所需的資料。 **注意** 應用程式有時需要節點物件中的資訊 (例如堆疊組態和部署屬性值)。不過，應用程式無法存取節點物件。若要將節點物件資料提供給應用程式，您可以實作配方，以從節點物件擷取所需的資訊，並將它以方便的格式放入檔案中。應用程式接著可以從檔案讀取資料。如需詳細資訊和範例，請參閱 [傳遞資料到應用程式](apps-data.md)。配方可以從節點物件取得堆疊組態和部署屬性值，如下所示。 + 直接使用屬性的完整名稱。您可以搭配使用此方式與任何 Linux 堆疊，但不能與 Windows 堆疊搭配使用。 + 使用 Chef 搜尋，可用來查詢節點物件的屬性值。您可以搭配使用此方式與 Windows 堆疊和 Chef 11.10 Linux 堆疊。 **注意** 使用 Linux 堆疊，您可以使用代理程式 CLI 來取得執行個體的堆疊組態和部署屬性複本，且格式為 JSON。如需詳細資訊，請參閱[在 Vagrant 上模擬堆疊組態和部署屬性](opsworks-opsworks-mock.md)。 **Topics** + [直接取得屬性值](cookbooks-101-opsworks-opsworks-stack-config-node.md) + [使用 Chef 搜尋取得屬性值](cookbooks-101-opsworks-opsworks-stack-config-search.md) # 直接取得屬性值 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此方式僅適用於 Linux 堆疊。 [在 Vagrant 上模擬堆疊組態和部署屬性](opsworks-opsworks-mock.md)顯示如何使用節點語法取得堆疊組態和部署資料，以直接參考特定屬性。這有時是最佳方式。不過，許多屬性都定義在集合或清單中，而集合或清單的內容和名稱可能會因不同的堆疊以及特定堆疊的一段時間而不同。例如，`deploy` 屬性包含應用程式屬性清單，而應用程式屬性以應用程式的短名命名。此清單 (包括應用程式屬性名稱) 通常會因不同的堆疊甚至會因不同的部署而不同。以清單或集合形式列舉屬性來取得所需的資料，通常更為有用，有時甚至是必要的。例如，假設您想要知道堆疊執行個體的公有 IP 地址。該資訊位於設定為雜湊表的 `['opsworks']['layers']` 屬性中，而雜湊表針對每個堆疊 layer 都包含一個元素，以 layer 的短名命名。每個 layer 元素都會設定為包含 layer 屬性的雜湊表，而其中一個是 `['instances']`。該元素接著會設定為另一個雜湊表，其中針對每個 layer 執行個體都包含一個屬性，以執行個體的短名命名。每個執行個體屬性都會設定為另一個雜湊表，其中包含執行個體屬性 (包括代表公有 IP 地址的 `['ip']`)。如果您無法視覺化此項目，則下列程序包括 JSON 格式的範例。此範例顯示如何從堆疊 layer 的堆疊組態和部署 JSON 取得資料。 **設定技術指南** 1. 在 `opsworks_cookbooks` 內建立並導覽至名為 `listip` 的目錄。 1. 初始化並設定 Test Kitchen，如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述。 1. 將兩個目錄新增至 `listip`：`recipes` 和 `environments`。 1. 建立編輯過的 MyStack 組態和部署屬性 JSON 版本，其中包含相關的屬性。它看起來應該與下列類似。 ``` { "opsworks": { "layers": { "php-app": { "name": "PHP App Server", "id": "efd36017-ec42-4423-b655-53e4d3710652", "instances": { "php-app1": { "ip": "192.0.2.0" } } }, "db-master": { "name": "MySQL", "id": "2d8e0b9a-0d29-43b7-8476-a9b2591a7251", "instances": { "db-master1": { "ip": "192.0.2.5" } } }, "lb": { "name": "HAProxy", "id": "d5c4dda9-2888-4b22-b1ea-6d44c7841193", "instances": { "lb1": { "ip": "192.0.2.10" } } } } } } ``` 1. 建立名為 `test.json` 的環境檔案，並將範例 JSON 貼入 `default_attributes`，然後將檔案儲存至技術指南的 `environments` 資料夾。此檔案應該與下列類似 (為求簡潔，會以省略符號代表大部分的範例 JSON)。 ``` { "default_attributes" : { "opsworks": { "layers": { ... } } }, "chef_type" : "environment", "json_class" : "Chef::Environment" } ``` 1. 將 `.kitchen.yml` 中的文字取代為下列內容。 ``` --- driver: name: vagrant provisioner: name: chef_zero environments_path: ./environment platforms: - name: ubuntu-12.04 suites: - name: listip provisioner: client_rb: environment: test run_list: - recipe[listip::default] attributes: ``` 在設定技術指南之後，您可以使用下列配方來記錄 layer ID。 ``` node['opsworks']['layers'].each do |layer, layerdata| log "#{layerdata['name']} : #{layerdata['id']}" end ``` 配方會列舉 `['opsworks']['layers']` 中的 layer，並記錄每 layer 的名稱和 ID。 **執行 layer ID 記錄配方** 1. 使用範例配方建立名為 `default.rb` 的檔案，並將它儲存至 `recipes` 目錄。 1. 執行 `kitchen converge`。輸出的相關部分應該與下列類似。 ``` Recipe: listip::default * log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write[2014-07-17T22:56:19+00:00] INFO: Processing log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write (listip::default line 4) [2014-07-17T22:56:19+00:00] INFO: PHP App Server : efd36017-ec42-4423-b655-53e4d3710652 * log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write[2014-07-17T22:56:19+00:00] INFO: Processing log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write (listip::default line 4) [2014-07-17T22:56:19+00:00] INFO: MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251 * log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write[2014-07-17T22:56:19+00:00] INFO: Processing log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write (listip::default line 4) [2014-07-17T22:56:19+00:00] INFO: HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193 ``` 若要列出執行個體的 IP 地址，您將需要巢狀循環，如下所示。 ``` node['opsworks']['layers'].each do |layer, layerdata| log "#{layerdata['name']} : #{layerdata['id']}" layerdata['instances'].each do |instance, instancedata| log "Public IP: #{instancedata['ip']}" end end ``` 內部迴圈會逐一查看每 layer 的執行個體，並記錄 IP 地址。 **執行執行個體 IP 記錄配方** 1. 將 `default.rb` 中的程式碼取代為範例配方。 1. 執行 `kitchen converge` 以執行配方。輸出的相關部分應該與下列類似。 ``` * log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write (listip::default line 2) [2014-07-17T23:09:34+00:00] INFO: PHP App Server : efd36017-ec42-4423-b655-53e4d3710652 * log[Public IP: 192.0.2.0] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[Public IP: 192.0.2.0] action write (listip::default line 4) [2014-07-17T23:09:34+00:00] INFO: Public IP: 192.0.2.0 * log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write (listip::default line 2) [2014-07-17T23:09:34+00:00] INFO: MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251 * log[Public IP: 192.0.2.5] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[Public IP: 192.0.2.5] action write (listip::default line 4) [2014-07-17T23:09:34+00:00] INFO: Public IP: 192.0.2.5 * log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write (listip::default line 2) [2014-07-17T23:09:34+00:00] INFO: HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193 * log[Public IP: 192.0.2.10] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[Public IP: 192.0.2.10] action write (listip::default line 4) [2014-07-17T23:09:34+00:00] INFO: Public IP: 192.0.2.10 ``` 當您完成之後，請執行 `kitchen destroy`；下個主題會使用新的技術指南。 **注意** 列舉堆疊組態和部署 JSON 集合的其中一個最常見原因，是取得特定已部署應用程式的資料 (例如其部署目錄)。如需範例，請參閱 [部署配方](create-custom-deploy.md)。 # 使用 Chef 搜尋取得屬性值 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此方式適用於 Windows 堆疊和 Chef 11.10 Linux 堆疊。直接從節點物件取得堆疊組態和部署屬性值可能十分複雜，而且無法與 Windows 堆疊搭配使用。替代方式是使用 [Chef 搜尋](http://docs.chef.io/chef_search.html)查詢感興趣的屬性。如果您熟悉 Chef 伺服器，您會發現 Chef 搜尋與 Stacks OpsWorks 的運作方式略有不同。由於 OpsWorks Stacks 在本機模式中使用 Chef-client，因此 Chef 搜尋取決於稱為 chef-zero 的 Chef 伺服器本機版本，因此搜尋會操作存放在執行個體節點物件本機的資料，而非遠端伺服器。實際上，限制搜尋本機儲存的資料通常並不重要，因為 Stacks OpsWorks 執行個體上的節點物件包含[堆疊組態和部署屬性](workingcookbook-json.md)。如果不是配方通常從 Chef 伺服器取得並使用相同名稱的所有資料，則它們包含大部分資料，因此您通常可以在 Stacks OpsWorks 執行個體上使用為 Chef 伺服器撰寫的搜尋碼，無需修改。如需詳細資訊，請參閱[使用 Chef 搜尋](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search)。以下顯示搜尋查詢的基本結構： ``` result = search(:search_index, "key:pattern") ``` + 搜尋索引指定要套用查詢的屬性，以及決定要傳回的物件類型。 + 索引鍵指定屬性名稱。 + 模式指定您要擷取之屬性的值。您可以查詢特定屬性值，或使用萬用字元來查詢某範圍的值。 + 結果是滿足查詢的物件清單，而且各為包含多個相關屬性的雜湊表。例如，如果您使用 `node` 搜尋索引，則查詢會傳回執行個體物件清單，而每個滿足查詢的執行個體都各有一個清單。每個物件都是一個雜湊表，其中包含可定義執行個體組態的一組屬性 (例如主機名稱和 IP 地址)。例如，下列查詢使用 `node` 搜尋索引，這是套用至堆疊執行個體 (或 Chef 術語的節點) 的標準 Chef 索引。它會搜尋主機名稱為 `myhost` 的執行個體。 ``` result = search(:node, "hostname:myhost") ``` 搜尋會傳回主機名稱為 `myhost` 的執行個體物件清單。如果您想要第一個執行個體的作業系統 (例如，以 `result[0][:os]` 表示)。如果查詢傳回多個物件，您可以列舉它們以擷取所需資訊。如何在配方中使用搜尋的詳細資訊取決於您使用 Linux 還是 Windows 堆疊。下列主題提供這兩種堆疊類型的範例。 **Topics** + [在 Linux 堆疊上使用搜尋](cookbooks-101-opsworks-opsworks-stack-config-search-linux.md) + [在 Windows 堆疊上使用搜尋](cookbooks-101-opsworks-opsworks-stack-config-search-windows.md) # 在 Linux 堆疊上使用搜尋 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。此範例根據具有單一 PHP 應用程式伺服器的 Linux 堆疊。它使用 Chef 搜尋取得伺服器的公有 IP 地址，並將地址放入 `/tmp` 目錄的檔案中。它基本上會從節點物件擷取相同的資訊 (如[直接取得屬性值](cookbooks-101-opsworks-opsworks-stack-config-node.md)所述)，但程式碼更為簡單，而且不是取決於堆疊組態和部署屬性結構的詳細資訊。以下簡短地彙總如何針對此範例建立堆疊。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **注意** 如果您之前沒有在 OpsWorks Stacks 執行個體上執行自訂配方，您應該先瀏覽[在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)範例。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後按一下 **Add Stack (新增堆疊)**。 1. 指定下列設定，並接受其他設定的預設值，然後按一下 **Add Stack (新增堆疊)**。 + **名稱** – SearchJSON + **預設 SSH 金鑰** – Amazon EC2 金鑰對如果您需要建立 Amazon EC2 金鑰對，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。請注意，金鑰對必須屬於與執行個體相同的 AWS 區域。此範例使用美國西部（奧勒岡）區域。 1. 按一下**新增圖層**，並使用預設設定將 [PHP App Server 圖層新增至](workinglayers-custom.md)堆疊。 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 layer，以及[啟動它](workinginstances-starting.md)。 **設定技術指南** 1. 在 `opsworks_cookbooks` 內建立並導覽至名為 `searchjson` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `opstest`。 ``` name "searchjson" version "0.1.0" ``` 1. 在 `recipes` 內建立 `searchjson` 目錄。 1. 使用下列配方建立 `default.rb` 檔案，並將它儲存至 `recipes` 目錄。 ``` phpserver = search(:node, "layers:php-app").first Chef::Log.info("**********The public IP address is: '#{phpserver[:ip]}'**********") file "/tmp/ip_addresses" do content "#{phpserver[:ip]}" mode 0644 action :create end ``` Linux 堆疊僅支援 `node` 搜尋索引。配方會使用此索引來取得 `php-app` layer 中的執行個體清單。因為 layer 已知只有一個執行個體，所以配方只需要將第一個執行個體指派給 `phpserver`。如果 layer 具有多個執行個體，您可以列舉它們以擷取所需資訊。每個清單項目都是一個雜湊表，其中包含一組執行個體屬性。`ip` 屬性設定為執行個體的公有 IP 地址，因此您可以將後續配方程式碼中的該地址呈現為 `phpserver[:ip]`。將訊息新增至 Chef 日誌之後，配方接著會使用 [https://docs.chef.io/chef/resources.html#file](https://docs.chef.io/chef/resources.html#file) 資源來建立名為 `ip_addresses` 的檔案。`content` 屬性設定為以字串呈現 `phpserver[:ip]`。Chef 建立 `ip_addresses` 時，會將該字串新增至檔案。 1. 建立的`.zip`封存`opsworks_cookbooks`、[上傳封存至 Amazon S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)、[將封存設為公](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)有，並記錄封存的 URL。如需技術指南儲存庫的詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。您現在可以安裝技術指南，並執行配方。 **執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **Http Archive** + **儲存庫 URL** – 您先前記錄的技術指南封存 URL 針對其他設定使用預設值，然後按一下 **Save (儲存)** 以更新堆疊組態。 1. 編輯自訂 layer 組態，並[指派給 `searchjson::default`](workingcookbook-assigningcustom.md) layer 的安裝事件。 OpsWorks 堆疊會在執行個體開機後或您明確觸發安裝事件時執行配方。 1. [執行更新自訂技術指南堆疊命令](workingstacks-commands.md)，以在堆疊執行個體上安裝最新版的自訂技術指南儲存庫。如果存在舊版的儲存庫，則此命令會予以覆寫。 1. 執行 **Setup (安裝)** 堆疊命令來執行配方，這會在執行個體上觸發安裝事件，並執行 `searchjson::default`。保留 **Running command setup page (執行命令安裝頁面)** 的開啟狀態。成功執行配方之後，您就可以驗證配方。 **驗證 searchjson** 1. 第一步是檢查 [Chef 日誌](troubleshoot-debug-log.md)中的最新安裝事件。在**執行命令設定頁面上**，按一下 php-app1 執行個體**日誌**欄中**的**顯示以顯示日誌。向下捲動以在接近中間的位置找到您的日誌訊息，這看起來與下列類似。 ``` ... [2014-09-05T17:08:41+00:00] WARN: Previous bash[logdir_existence_and_restart_apache2]: ... [2014-09-05T17:08:41+00:00] WARN: Current bash[logdir_existence_and_restart_apache2]: ... [2014-09-05T17:08:41+00:00] INFO: **********The public IP address is: '192.0.2.0'********** [2014-09-05T17:08:41+00:00] INFO: Processing directory[/etc/sysctl.d] action create (opsworks_initial_setup::sysctl line 1) ... ``` 1. [使用 SSH 登入執行個體](workinginstances-ssh.md)，並列出 `/tmp` 的內容，其中應該包括名為 `ip_addresses` 且包含 IP 地址的檔案。 # 在 Windows 堆疊上使用搜尋 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 提供兩種在 Windows 堆疊上使用搜尋的選項。 + `node` 搜尋索引，可用來查詢一組標準 Chef 屬性。如果您有具有使用之搜尋碼的現有配方`node`，它們通常可在 Stacks OpsWorks 堆疊上運作，無需修改。 + 可用來查詢 OpsWorks Stacks 特定屬性集的一組額外搜尋索引，以及一些標準屬性。 [在 Windows OpsWorks Stacks 上使用 Stacks 特定的搜尋索引](cookbooks-101-opsworks-opsworks-stack-config-search-opsworks.md)中會討論這些索引。建議使用 `node` 來擷取標準資訊 (例如主機名稱或 IP 地址)。該方式可讓您的配方與標準 Chef 實務一致。使用 OpsWorks Stacks 搜尋索引來擷取 Stacks OpsWorks 特有的資訊。 **Topics** + [在 Windows 堆疊上使用搜尋索引節點](cookbooks-101-opsworks-opsworks-stack-config-search-node.md) + [在 Windows OpsWorks Stacks 上使用 Stacks 特定的搜尋索引](cookbooks-101-opsworks-opsworks-stack-config-search-opsworks.md) # 在 Windows 堆疊上使用搜尋索引節點 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此範例假設您已完成[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)範例。否則，您應該先執行該範例。具體而言，它說明如何啟用 RDP 存取您的執行個體。此範例根據具有單一自訂 layer 和一個執行個體的 Windows 堆疊。它搭配使用 Chef 搜尋與 `node` 搜尋索引來取得伺服器的公有 IP 地址，並將地址放入 `C:\tmp` 目錄的檔案中。以下簡短地彙總如何針對此範例建立堆疊。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。 1. 指定下列設定，並接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)**。 + **名稱** – NodeSearch + **區域** – 美國西部（奧勒岡）此範例適用於任何區域，但我們建議您使用美國西部（奧勒岡）進行教學課程。 + **預設作業系統** – Microsoft Windows Server 2012 R2 1. 選擇 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – IPTest + **簡短名稱** – iptest 1. [新增全年無休 t2.micro 執行個體](workinginstances-add.md) (具有預設設定) 至 IPTest layer，以及[啟動它](workinginstances-starting.md)。它將會命名為 iptest1。 OpsWorks Stacks 會自動指派給`AWS-OpsWorks-RDP-Server`此執行個體，以允許授權使用者登入執行個體。 1. 選擇 **Permissions (許可)**，並選擇 **Edit (編輯)**，然後選取 **SSH/RDP** 和 **sudo/admin**。除了 `AWS-OpsWorks-RDP-Server` 安全群組之外，一般使用者還需要有此授權，才能登入執行個體。 **注意** 您也可以登入為管理員，但需要不同的程序。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。 **設定技術指南** 1. 建立並導覽至名為 `nodesearch` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `opstest`。 ``` name "nodesearch" version "0.1.0" ``` 1. 在 `recipes` 內建立 `nodesearch` 目錄。 1. 使用下列配方建立 `default.rb` 檔案，並將它儲存至 `recipes` 目錄。 ``` directory 'C:\tmp' do rights :full_control, 'Everyone' recursive true action :create end windowsserver = search(:node, "hostname:iptest*").first Chef::Log.info("**********The public IP address is: '#{windowsserver[:ipaddress]}'**********") file 'C:\tmp\addresses.txt' do content "#{windowsserver[:ipaddress]}" rights :full_control, 'Everyone' action :create end ``` 配方會執行下列動作： 1. 使用目錄資源來建立檔案的 `C:\tmp` 目錄。如需此資源的詳細資訊，請參閱[範例 3：建立目錄](cookbooks-101-basics-directories.md)。 1. 搭配使用 Chef 搜尋與 `node` 搜尋索引，以取得主機名稱開頭為 `iptest` 的節點 (執行個體) 清單。如果您使用預設主題 (這會將整數附加至 layer 的短名來建立主機名稱)，則此查詢將會傳回 IPTest layer 中的每個執行個體。在此範例中，layer 已知只有一個執行個體，因此配方只需要將第一個執行個體指派給 `windowsserver`。針對多個執行個體，您可以取得完整清單，然後列舉它們。 1. 將具有 IP 地址的訊息新增至此執行的 Chef 日誌。 `windowsserver` 物件是 `ipaddress` 屬性設定為執行個體之公有 IP 地址的雜湊表，因此您可以將後續配方程式碼中的該地址呈現為 `windowsserver[:ipaddress]`。配方會將對應的字串插入至訊息，並將其新增至 Chef 日誌。 1. 使用 `file` 資源建立 IP 地址為 `C:\tmp\addresses.txt` 的檔案。資源的 `content` 屬性指定要新增至檔案的內容，在此情況下即公有 IP 地址。 1. 建立 `nodesearch` 的 `.zip` 封存、[將封存上傳至 S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)、[將封存設為公有](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)，並記錄封存的 URL。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。您現在可以安裝技術指南，並執行配方。 **安裝技術指南並執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 封存** + **儲存庫 URL** – 您先前記錄的技術指南封存 URL 接受其他設定的預設值，然後選擇 **Save (儲存)** 以更新堆疊組態。 1. [執行更新自訂技術指南堆疊命令](workingstacks-commands.md)，以在堆疊執行個體上安裝最新版的自訂技術指南 (包括線上執行個體)。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 更新自訂技術指南完成後，使用配方執行[**執行配方堆疊**命令](workingstacks-commands.md)**以執行設定為的配方****nodesearch::default**。此命令會啟動 Chef 執行，內含包含您配方的回合清單。保留 execute\$1recipes 頁面的開啟狀態。成功執行配方之後，您就可以驗證配方。 **驗證 nodesearch** 1. 檢查 [Chef 日誌](troubleshoot-debug-log.md)中的最新 execute\$1recipes 事件。在**執行命令 execute\$1recipes 頁面上**，選擇在 iptest1 執行個體的**日誌**欄中**顯示** 以顯示日誌。向下捲動以在接近底端的位置找到您的日誌訊息，這看起來與下列類似。 ``` ... [2015-05-13T18:55:47+00:00] INFO: Storing updated cookbooks/nodesearch/recipes/default.rb in the cache. [2015-05-13T18:55:47+00:00] INFO: Storing updated cookbooks/nodesearch/metadata.rb in the cache. [2015-05-13T18:55:47+00:00] INFO: **********The public IP address is: '192.0.0.1'********** [2015-05-13T18:55:47+00:00] INFO: Processing directory[C:\tmp] action create (nodesearch::default line 1) [2015-05-13T18:55:47+00:00] INFO: Processing file[C:\tmp\addresses.txt] action create (nodesearch::default line 10) ... ``` 1. [使用 RDP 登入執行個體](workinginstances-rdp.md)，並檢查 `C:\tmp\addresses.txt` 的內容。 # 在 Windows OpsWorks Stacks 上使用 Stacks 特定的搜尋索引 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此範例假設您已完成[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)範例。否則，您應該先執行該範例。具體而言，它說明如何啟用 RDP 存取您的執行個體。 OpsWorks 除了之外， Stacks 還提供下列搜尋索引`node`： + `aws_opsworks_stack` – 堆疊組態。 + `aws_opsworks_layer` – 堆疊的 layer 組態。 + `aws_opsworks_instance` – 堆疊的執行個體組態。 + `aws_opsworks_app` – 堆疊的應用程式組態。 + `aws_opsworks_user` – 堆疊的使用者組態。 + `aws_opsworks_rds_db_instance` – 已註冊 RDS 執行個體的連線資訊。這些索引包含一些標準 Chef 屬性，但主要用於擷取 OpsWorks Stacks 特定的屬性。例如，`aws_opsworks_instance` 包括 `status` 屬性，以提供執行個體的狀態 (例如 `online`)。 **注意** 建議的做法是盡可能使用 `node`，在讓您的配方與標準 Chef 使用量一致。如需範例，請參閱 [在 Windows 堆疊上使用搜尋索引節點](cookbooks-101-opsworks-opsworks-stack-config-search-node.md)。此範例示範如何使用 OpsWorks Stacks 索引來擷取 OpsWorks Stacks 特定屬性的值。它根據自訂 layer 具有一個執行個體的簡單 Windows 堆疊。它使用 Chef 搜尋來取得執行個體的 OpsWorks Stacks ID，並將結果放入 Chef 日誌中。以下簡短地彙總如何針對此範例建立堆疊。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **\$1 Stack (\$1 堆疊)**。指定下列設定，並接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)**。 + **名稱** – IDSearch + **區域** – 美國西部（奧勒岡）此範例適用於任何區域，但我們建議您使用美國西部（奧勒岡）進行教學課程。 + **預設作業系統** – Microsoft Windows Server 2012 R2 1. 選擇 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – IDCheck + **簡短名稱** – IDcheck 1. [新增全年無休 t2.micro 執行個體](workinginstances-add.md) (具有預設設定) 至 IDCheck layer，以及[啟動它](workinginstances-starting.md)。它將會命名為 iptest1。 OpsWorks Stacks 會自動指派給`AWS-OpsWorks-RDP-Server`此執行個體。 [啟用 RDP 存取](cookbooks-101-opsworks-opsworks-windows.md#cookbooks-101-opsworks-opsworks-windows-rdp) 說明如何將傳入規則新增至此安全群組，以允許授權使用者登入執行個體。 1. 選擇 **Permissions (許可)**，並選擇 **Edit (編輯)**，然後選擇 **SSH/RDP** 和 **sudo/admin**。除了 `AWS-OpsWorks-RDP-Server` 安全群組之外，一般使用者還需要有此授權，才能登入執行個體。 **注意** 您也可以登入為管理員，但需要不同的程序。如需詳細資訊，請參閱[使用 RDP 登入](workinginstances-rdp.md)。 **設定技術指南** 1. 建立並導覽至名為 `idcheck` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `opstest`。 ``` name "idcheck" version "0.1.0" ``` 1. 在 `idcheck` 內建立 `recipes` 目錄，並將 `default.rb` 檔案新增至包含下列配方的目錄。 ``` windowsserver = search(:aws_opsworks_instance, "hostname:idcheck*").first Chef::Log.info("**********The public IP address is: '#{windowsserver[:instance_id]}'**********") ``` 配方使用 Chef 搜尋搭配`aws_opsworks_instance`搜尋索引，取得堆疊中每個執行個體的[執行個體屬性](data-bag-json-instance.md)，其主機名稱開頭為 `idcheck`。如果您使用預設主題 (這會將整數附加至 layer 的短名來建立主機名稱)，則此查詢將會傳回 IDCheck layer 中的每個執行個體。在此範例中，layer 已知只有一個執行個體，因此配方只需要將第一個執行個體指派給 `windowsserver`。針對多個執行個體，您可以取得完整清單，然後列舉它們。配方會利用具有此主機名稱之堆疊中只有一個執行個體的事實，因此第一個結果就是正確的結果。如果您的堆疊具有多個執行個體，則搜尋其他屬性可能會傳回多個結果。如需執行個體屬性的清單，請參閱[執行個體資料包 (aws\$1opsworks\$1instance)](data-bag-json-instance.md)。執行個體屬性基本上是雜湊資料表，且執行個體的 Stacks ID OpsWorks 會指派給 `instance_id` 屬性，因此您可以將 ID 稱為 `windowsserver[:instance_id]`。配方會將對應的字串插入至訊息，並將其新增至 Chef 日誌。 1. 建立`ipaddress`技術指南的`.zip`封存、[上傳封存至 Amazon S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)，並記錄封存的 URL。如需技術指南儲存庫的詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。您現在可以安裝技術指南，並執行配方。 **安裝技術指南並執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 封存** + **儲存庫 URL** – 您先前記錄的技術指南封存 URL 接受其他設定的預設值，然後選擇 **Save (儲存)** 以更新堆疊組態。 1. [執行更新自訂技術指南堆疊命令](workingstacks-commands.md)，以在堆疊執行個體上安裝最新版的自訂技術指南 (包括線上執行個體)。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 更新自訂技術指南完成後，透過使用配方執行[**執行配方**堆疊命令](workingstacks-commands.md)**以執行設定為的配方****idcheck::default**。此命令會啟動 Chef 執行，內含包含您配方的回合清單。保留 execute\$1recipes 頁面的開啟狀態。成功執行配方之後，您可以檢查 [Chef 日誌](troubleshoot-debug-log.md)中的最新 execute\$1recipes 事件來驗證。在**執行命令 execute\$1recipes 頁面上**，選擇在 iptest1 執行個體的**日誌**欄中**顯示** 以顯示日誌。向下捲動以在接近底端的位置找到您的日誌訊息，這看起來與下列類似。 ``` ... [2015-05-13T20:03:47+00:00] INFO: Storing updated cookbooks/nodesearch/recipes/default.rb in the cache. [2015-05-13T20:03:47+00:00] INFO: Storing updated cookbooks/nodesearch/metadata.rb in the cache. [2015-05-13T20:03:47+00:00] INFO: **********The instance ID is: 'i-8703b570'********** [2015-05-13T20:03:47+00:00] INFO: Chef Run complete in 0.312518 seconds ... ``` # 在 Linux 執行個體上使用外部技術指南：Berkshelf **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** Berkshelf 僅適用於 Chef 11.10 Linux 堆疊。在您開始實作技術指南之前，請參閱 [Chef 社群技術指南](https://github.com/opscode-cookbooks)，其中包含 Chef 社群成員基於各種用途所建立的技術指南。其中許多技術指南可以與 OpsWorks Stacks 搭配使用，無需修改，因此您可能可以針對某些任務利用它們，而不是自行實作所有程式碼。若要在執行個體上使用外部技術指南，您需要安裝它並管理任何相依性的方法。偏好的方式是實作技術指南，而技術指南支援名為 Berkshelf 的相依性管理員。Berkshelf 適用於 Amazon EC2 執行個體，包括 OpsWorks Stacks 執行個體，但也旨在與 Test Kitchen 和 Vagrant 搭配使用。不過，Vagrant 上的用量與 Stacks OpsWorks 略有不同，因此本主題包含兩個平台的範例。如需如何使用 Berkshelf 的詳細資訊，請參閱 [Berkshelf](http://berkshelf.com/)。 **Topics** + [搭配使用 Berkshelf 與 Test Kitchen 和 Vagrant](#cookbooks-101-opsworks-berkshelf-vagrant) + [搭配 Stacks OpsWorks 使用 Berkshelf](#opsworks-berkshelf-opsworks) ## 搭配使用 Berkshelf 與 Test Kitchen 和 Vagrant 此範例顯示如何使用 Berkshelf 來安裝 getting-started 社群技術指南並執行其配方，以在執行個體的主目錄中安裝簡短文字檔。 **安裝 Berkshelf 並初始化技術指南** 1. 在您的工作站上，安裝 Berkshelf Gem，如下所示。 ``` gem install berkshelf ``` 視您的工作站而定，此命令可能需要 `sudo`，或者您也可以使用 Ruby 環境管理員，例如 [RVM](https://rvm.io/)。若要驗證是否已成功安裝 Berkshelf，請執行 `berks --version`。 1. 本主題的技術指南命名為 external\$1cookbook。您可以使用 Berkshelf 建立初始化的技術指南，而非先前主題所採用的手動方式。若要這麼做，請導覽至 `opsworks_cookbooks` 目錄，並執行下列命令。 ``` berks cookbook external_cookbook ``` 此命令會建立 `external_cookbook` 目錄以及數種標準 Chef 和 Test Kitchen 子目錄 (包括 `recipes` 和 `test`)。此命令也會建立數種標準檔案的預設版本，包括下列項目： + `metadata.rb` + Vagrant、Test Kitchen 和 Berkshelf 的組態檔 + `default.rb` 目錄中的空 `recipes` 配方 **注意** 您不需要執行 `kitchen init`；`berks cookbook` 命令會處理這些任務。 1. 執行 `kitchen converge`。新建立的技術指南目前不會執行任何有趣的動作，但會收歛。 **注意** 您也可以使用 `berks init`，初始化現有技術指南來使用 Berkshelf。若要使用 Berkshelf 管理技術指南的外部相依性，技術指南的根目錄必須包含 `Berksfile`，而此組態檔指定 Berkshelf 應該如何管理相依性。當您使用 `berks cookbook` 建立 `external_cookbook` 技術指南時，會建立具有下列內容的 `Berksfile`。 ``` source "https://supermarket.chef.io" metadata ``` 此檔案的宣告如下： + `source` – 技術指南來源的 URL。 Berksfile 可以有任意數目的 `source` 宣告，而且每個宣告都指定相依技術指南的預設來源。如果您未明確指定技術指南的來源，則 Berkshelf 會查看同名技術指南的預設儲存庫。預設 Berksfile 包括可指定社群技術指南儲存庫的單一 `source` 屬性。該儲存庫包含 getting-started 技術指南，因此您可以將該列保持不變。 + `metadata` – 指示 Berkshelf 包含技術指南檔案中宣告的技術指南相依性`metadata.rb`。您也可以包括 `cookbook` 屬性以在 Berksfile 中宣告相依技術指南，稍後將會予以討論。有兩種方法可以宣告技術指南相依性： + 在 Berksfile 中包括 `cookbook` 宣告。這是 Stacks OpsWorks 使用的方法。例如，若要指定此範例中所使用的 getting-started 技術指南，請在 Berksfile 中包括 `cookbook "getting-started"`。Berkshelf 接著會查看預設儲存庫中是否有該名稱的技術指南。您也可以使用 `cookbook` 明確指定技術指南來源，甚至指定特定版本。如需詳細資訊，請參閱 [Berkshelf](http://berkshelf.com/)。 + 在 Berksfile 中包括 `metadata` 宣告，並在 `metadata.rb` 中宣告相依性。此宣告指示 Berkshelf 包括 `metadata.rb` 中所宣告的技術指南相依性。例如，若要宣告 getting-started 相依性，請將 `depends 'getting-started'` 宣告新增至技術指南的 `metadata.rb` 檔案。此範例使用第一個方法，以與 Stacks OpsWorks 保持一致。 **安裝 getting-started 技術指南** 1. 編輯預設 Berksfile，以將 `metadata` 宣告取代為 `cookbook` 的 `getting-started` 宣告。內容應該與下列類似。 ``` source "https://supermarket.chef.io" cookbook 'getting-started' ``` 1. 執行 `berks install`，以將 getting-started 技術指南從社群技術指南儲存庫下載至您工作站的 Berkshelf 目錄 (通常為 `~/.berkshelf`)。此目錄通常只會稱為 *Berkshelf*。查看 Berkshelf 的 `cookbooks` 目錄，而您應該會看到 getting-started 技術指南的目錄，而其命名類似 `getting-started-0.4.0`。 1. 將 `external_cookbook::default` 回合清單中的 `.kitchen.yml` 取代為 `getting-started::default`。此範例不會從 external\$1cookbook 執行任何配方；它基本上就只是使用 getting-started 技術指南的方式。`.kitchen.yml` 檔案現在應該與下列類似。 ``` --- driver: name: vagrant provisioner: name: chef_solo platforms: - name: ubuntu-12.04 suites: - name: default run_list: - recipe[getting-started::default] attributes: ``` 1. 執行 `kitchen converge`，然後使用 `kitchen login` 登入執行個體。登入目錄應該包含名為 `chef-getting-started.txt` 且具有下列類似內容的檔案： ``` Welcome to Chef! This is Chef version 11.12.8. Running on ubuntu. Version 12.04. ``` Test Kitchen 會在執行個體的 `/tmp/kitchen/cookbooks` 目錄中安裝技術指南。如果您列出該目錄的內容，則會看到兩個技術指南：external\$1cookbook 和 getting-started。 1. 執行 `kitchen destroy` 關機執行個體。下一個範例使用 OpsWorks Stacks 執行個體。 ## 搭配 Stacks OpsWorks 使用 Berkshelf OpsWorks Stacks 選擇性地支援 Berkshelf for Chef 11.10 堆疊。若要搭配使用 Berkshelf 與您的堆疊，您必須執行下列動作。 + 啟用堆疊的 Berkshelf。 OpsWorks Stacks 接著會處理在堆疊執行個體上安裝 Berkshelf 的詳細資訊。 + 將 Berksfile 新增至技術指南儲存庫的根目錄。 Berksfile 應該包含所有相依技術指南的 `source` 和 `cookbook` 宣告。當 OpsWorks Stacks 在執行個體上安裝您的自訂技術指南儲存庫時，它會使用 Berkshelf 來安裝儲存庫 Berksfile 中宣告的相依技術指南。如需詳細資訊，請參閱[使用 Berkshelf](workingcookbook-chef11-10.md#workingcookbook-chef11-10-berkshelf)。此範例示範如何使用 Berkshelf 在 Stacks OpsWorks 執行個體上安裝入門社群技術指南。它也會安裝用來建立 createfile 自訂技術指南的版本，以在指定的目錄中建立檔案。如需 createfile 運作方式的詳細資訊，請參閱[從技術指南安裝檔案](cookbooks-101-basics-files.md#cookbooks-101-basics-files-cookbook_file)。 **注意** 如果這是您第一次在 Stacks OpsWorks 堆疊上安裝自訂技術指南，您應該先瀏覽[在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)範例。從建立堆疊開始，彙總如下。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後按一下 **Add Stack (新增堆疊)**。 1. 指定下列設定，並接受其他設定的預設值，然後按一下 **Add Stack (新增堆疊)**。 + **名稱** – BerksTest + **預設 SSH 金鑰** – Amazon EC2 金鑰對如果您需要建立 Amazon EC2 金鑰對，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。請注意，金鑰對必須屬於與執行個體相同的 AWS 區域。此範例使用預設的美國西部（奧勒岡）區域。 1. 按一下 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – BerksTest + **簡短名稱** – berkstest 您可以針對此範例實際使用任何 layer 類型。不過，此範例不需要其他 layer 所安裝的任何套件，因此自訂 layer 是最簡單的方法。 1. [新增全年無休執行個體](workinginstances-add.md)至 BerksTest layer (具有預設設定)，但尚未啟動它。使用 OpsWorks Stacks，技術指南必須位於具有標準目錄結構的遠端儲存庫中。然後，您將下載資訊提供給 OpsWorks Stacks，其會在啟動時自動將儲存庫下載到每個堆疊的執行個體。為了簡化，此範例的儲存庫是公有 Amazon S3 封存，但 OpsWorks Stacks 也支援 HTTP 封存、Git 儲存庫和 Subversion 儲存庫。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **建立技術指南儲存庫** 1. 在 `opsworks_cookbooks` 目錄中，建立名為 `berkstest_cookbooks` 的目錄。如果您想要，則可以在您方便找到的任何位置建立此目錄，因為您會將它上傳至儲存庫。 1. 使用下列內容，將名為 Berksfile 的檔案新增至 `berkstest_cookbooks`。 ``` source "https://supermarket.chef.io" cookbook 'getting-started' ``` 此檔案宣告 getting-started 技術指南相依性，並指示 Berkshelf 從社群技術指南網站下載它。 1. 將 `createfile` 目錄新增至包含下列內容的 `berkstest_cookbooks`。 + 具有下列內容的 `metadata.rb` 檔案。 ``` name "createfile" version "0.1.0" ``` + 包含具有下列內容之 `files/default` 檔案的 `example_data.json` 目錄。 ``` { "my_name" : "myname", "your_name" : "yourname", "a_number" : 42, "a_boolean" : true } ``` 檔案的名稱和內容為任意的。配方只需要將檔案複製至指定的位置。 + 包含具有下列配方程式碼之 `recipes` 檔案的 `default.rb` 目錄。 ``` directory "/srv/www/shared" do mode 0755 owner 'root' group 'root' recursive true action :create end cookbook_file "/srv/www/shared/example_data.json" do source "example_data.json" mode 0644 action :create_if_missing end ``` 此配方會建立 `/srv/www/shared`，並將 `example_data.json` 從技術指南的 `files` 目錄複製至該目錄。 1. 建立的`.zip`封存`berkstest_cookbooks`、[上傳封存至 Amazon S3 儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)、[將封存設為公](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)有，並記錄封存的 URL。您現在可以安裝技術指南，並執行配方。 **安裝技術指南並執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **Http Archive** + **儲存庫 URL** – 您先前記錄的技術指南封存 URL + **管理 Berkshelf** – **是** 前兩個設定提供 OpsWorks Stacks 將技術指南儲存庫下載到您的執行個體所需的資訊。最後一個設定會啟用 Berkshelf 支援，以將 getting-started 技術指南下載至執行個體。接受其他設定的預設值，然後按一下 **Save (儲存)** 以更新堆疊組態。 1. 編輯 BerksTest layer，以[將下列配方新增至 layer 的安裝生命週期事件](workingcookbook-assigningcustom.md)。 + `getting-started::default` + `createfile::default` 1. [啟動](workinginstances-starting.md)實例。設定事件會在執行個體完成開機後發生。 OpsWorks Stacks 接著會安裝技術指南儲存庫、使用 Berkshelf 下載入門技術指南，以及執行 layer 的設定和部署配方，包括 `getting-started::default`和 `createfile::default`。 1. 執行個體上線之後，請[使用 SSH 登入](workinginstances-ssh.md)。您應該會看到下列事項： + `/srv/www/shared` 應該包含 `example_data.json`。 + `/root` 應該包含 `chef-getting-started.txt`。 OpsWorks Stacks 會以根目錄執行配方，因此入門會將檔案安裝在 `/root`目錄中，而不是您的主目錄中。 # 使用適用於 Ruby 的開發套件：從 Amazon S3 下載檔案 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 Chef 資源無法處理一些任務 (例如與 AWS 服務互動)。例如，有時偏好遠端存放檔案，並讓配方將它們下載至執行個體。您可以使用 [remote\$1file](https://docs.chef.io/chef/resources.html#remote-file) 資源，以從遠端伺服器下載檔案。不過，如果您想要將檔案存放在 [Amazon S3 ](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)儲存貯體中，只有在 [ACL](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html) 允許操作時`remote_file`，才能下載這些檔案。配方可以使用[適用於 Ruby 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)存取大部分的 AWS 服務。本主題說明如何使用適用於 Ruby 的 SDK 從 S3 儲存貯體下載檔案。 **注意** 如需如何使用[適用於 Ruby 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)處理加密和解密的詳細資訊，請參閱 [AWS::S3::S3Object](https://docs.aws.amazon.com/AWSRubySDK/latest/AWS/S3/S3Object.html)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **Topics** + [在 Vagrant 執行個體上使用適用於 Ruby 的 SDK](cookbooks-101-opsworks-s3-vagrant.md) + [在 Stacks Linux 執行個體上使用適用於 Ruby OpsWorks 的 SDK](cookbooks-101-opsworks-s3-opsworks.md) + [在 Stacks Windows 執行個體上使用適用於 Ruby OpsWorks 的 SDK](cookbooks-101-opsworks-s3-windows.md) # 在 Vagrant 執行個體上使用適用於 Ruby 的 SDK **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本主題說明在 Vagrant 執行個體上執行的配方如何使用從 Amazon S3 [適用於 Ruby 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)下載檔案。開始之前，您必須先擁有一組 AWS 登入資料：存取金鑰和私密存取金鑰，以允許配方存取 Amazon S3。 **重要** 強烈建議您不要基於此目的使用 root 帳戶登入資料。反之，請使用適當的政策建立使用者，並將這些登入資料提供給配方。請注意不要將登入資料—甚至是 IAM 使用者登入資料—放在可公開存取的位置，例如將包含登入資料的檔案上傳至公有 GitHub 或 Bitbucket 儲存庫。這麼做會公開您的登入資料，而且可能會危害您帳戶的安全性。在 EC2Amazon EC2 執行個體上執行的配方可以使用更好的方法，即 IAM 角色，如中所述[在 Stacks Linux 執行個體上使用適用於 Ruby OpsWorks 的 SDK](cookbooks-101-opsworks-s3-opsworks.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。如果您還沒有適當的使用者，則可以建立一位使用者，如下所示。如需詳細資訊，請參閱[什麼是 IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/Introduction.html)。 **警告** IAM 使用者具有長期憑證，這會造成安全風險。為了協助降低此風險，建議您只為這些使用者提供執行任務所需的許可，並在不再需要這些使用者時將其移除。 **建立 IAM 使用者** 1. 登入 AWS 管理主控台並開啟位於 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 的 IAM 主控台。 1. 在導覽窗格中，選擇**使用者**，並視需要選擇**新增使用者**以建立新的管理使用者。 1. 在**設定許可**頁面上，選擇**直接連接政策**。 1. **S3** 在**許可政策**搜尋方塊中輸入以顯示 Amazon S3 政策。選擇 **AmazonS3ReadOnlyAccess**。如果您想要，則可以指定政策來授予更廣泛的許可 (例如 **AmazonS3FullAccess**)，但標準實務是僅授予這些所需的許可。在此情況下，配方僅會下載檔案，因此唯讀存取就已足夠。 1. 選擇**下一步**。 1. 選擇**建立使用者** 1. 接著為您的使用者建立存取金鑰。如需建立存取金鑰的詳細資訊，請參閱*IAM 使用者指南*中的[管理 IAM 使用者的存取金鑰](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)。您必須接著提供要下載的檔案。此範例假設您將名為 `myfile.txt` 的檔案放入名為 `cookbook_bucket` 的新建立 S3 儲存貯體中。 **提供要下載的檔案** 1. 建立名為 `myfile.txt` 且具有下列文字的檔案，並將它儲存至工作站上的方便位置。 ``` This is the file that you just downloaded from Amazon S3. ``` 1. 在 [Amazon S3 主控台](https://console.aws.amazon.com/s3/)`cookbook_bucket`上，在**標準**區域中建立名為的儲存貯體，並上傳至`myfile.txt`儲存貯體。設定技術指南，如下所示。 **設定技術指南** 1. 在 `opsworks_cookbooks` 內建立並導覽至名為 `s3bucket` 的目錄。 1. 初始化並設定 Test Kitchen，如[範例 1：安裝套件](cookbooks-101-basics-packages.md)中所述。 1. 將 `.kitchen.yml` 中的文字取代為下列內容。 ``` --- driver: name: vagrant provisioner: name: chef_solo environments_path: ./environments platforms: - name: ubuntu-14.04 suites: - name: s3bucket provisioner: solo_rb: environment: test run_list: - recipe[s3bucket::default] attributes: ``` 1. 將兩個目錄新增至 `s3bucket`：`recipes` 和 `environments`。 1. `test.json` 使用下列`default_attributes`區段建立名為的環境檔案，將 `access_key`和 `secret_key`值取代為您的使用者對應的金鑰。將檔案儲存至技術指南的 `environments` 資料夾。 ``` { "default_attributes" : { "cookbooks_101" : { "access_key": "AKIAIOSFODNN7EXAMPLE", "secret_key" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" } }, "chef_type" : "environment", "json_class" : "Chef::Environment" } ``` 您有各種方法可以將登入資料提供給執行個體上所執行的配方。主要考量是限制意外公開金鑰以及危害您帳戶安全性的機會。因此，不建議在您的程式碼中使用明確金鑰值。此範例改為將金鑰值放入節點物件中，以使用節點語法而非公開常值來允許配方參考它們。您必須擁有 root 權限才能存取節點物件，這會限制可能公開金鑰的可能性。如需詳細資訊，請參閱[管理 AWS 存取金鑰的最佳實務](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)。 **注意** 請注意，此範例使用巢狀屬性，而且 `cookbooks_101` 為第一個元素。如果節點物件中有其他 `access_key` 或 `secret_key` 屬性，則本實務可限制名稱衝突的機會。下列配方會從 `myfile.text` 儲存貯體下載 `cookbook_bucket`。 ``` gem_package "aws-sdk ~> 3" do action :install end ruby_block "download-object" do block do require 'aws-sdk' s3 = Aws::S3::Client.new( :access_key_id => "#{node['cookbooks_101']['access_key']}", :secret_access_key => "#{node['cookbooks_101']['secret_key']}") myfile = s3.bucket['cookbook_bucket'].objects['myfile.txt'] Dir.chdir("/tmp") File.open("myfile.txt", "w") do |f| f.write(myfile.read) f.close end end action :run end ``` 配方的第一部分會安裝適用於 Ruby 的 SDK，這是 Gem 套件。[gem\$1package](https://docs.chef.io/chef/resources.html#gem-package) 資源會安裝配方或其他應用程式所使用的 Gem。 **注意** 您的執行個體通常會有兩個 Ruby 執行個體，這一般是不同的版本。其中一個是 Chef 用戶端所使用的專用執行個體。另一個是供執行個體上所執行的應用程式和配方使用。安裝 Gem 套件時，請務必了解這項差異，因為有兩個適用於安裝 Gem ([gem\$1package](https://docs.chef.io/chef/resources.html#gem-package) 和 [chef\$1gem](https://docs.chef.io/chef/resources.html#chef-gem)) 的資源。如果應用程式或配方使用 Gem 套件，則請使用 `gem_package` 安裝它。`chef_gem` 僅適用於 Chef 用戶端所使用的 Gem 套件。配方的其餘部分是 [ruby\$1block](https://docs.chef.io/chef/resources.html#ruby-block) 資源，而此資源包含可下載檔案的 Ruby 程式碼。您可能認為配方是 Ruby 應用程式，因此可以直接將程式碼放入配方中。不過，Chef 執行會先編譯整個程式碼，再執行任何資源。如果您將範例程式碼直接放在配方中，則 Ruby 會嘗試先解決 `require 'aws-sdk'` 陳述式，再執行 `gem_package` 資源。由於尚未安裝適用於 Ruby 的 SDK，編譯將會失敗。除非執行 `ruby_block` 資源，否則不會編譯該資源中的程式碼。在此範例中，`ruby_block`資源會在`gem_package`資源完成安裝適用於 Ruby 的 SDK 後執行，因此程式碼將成功執行。 `ruby_block` 中的程式碼會運作，如下所示。 1. 建立新的 [https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3.html](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3.html) 物件，以提供服務界面。存取金鑰和秘密金鑰的指定方式是參考節點物件中所存放的值。 1. 呼叫`S3`物件的`bucket.objects`關聯，傳回名為的[https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3/Object.html](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3/Object.html)物件`myfile`，代表 `myfile.txt`。 1. 使用 `Dir.chdir` 將工作目錄設定為 `/tmp`。 1. 開啟名為 `myfile.txt` 的檔案，並將 `myfile` 的內容寫入該檔案，然後關閉該檔案。 **執行配方** 1. 使用範例配方建立名為 `default.rb` 的檔案，並將它儲存至 `recipes` 目錄。 1. 執行 `kitchen converge`。 1. 執行 `kitchen login` 登入執行個體，然後執行 `ls /tmp`。您應該會看到 `myfile.txt`，以及數種 Test Kitchen 檔案和目錄。 ``` vagrant@s3bucket-ubuntu-1204:~$ ls /tmp install.sh kitchen myfile.txt stderr ``` 您也可以執行 `cat /tmp/myfile.txt`，確認檔案的內容正確。完成後，請執行 `kitchen destroy` 終止執行個體。 # 在 Stacks Linux 執行個體上使用適用於 Ruby OpsWorks 的 SDK **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本主題說明如何在 Stacks Linux 執行個體上使用適用於 Ruby OpsWorks 的 SDK，從 Amazon S3 儲存貯體下載檔案。 OpsWorks Stacks 會自動在每個 Linux 執行個體上安裝適用於 Ruby 的 SDK。不過，當您建立服務的用戶端物件時，必須提供一組適合的 AWS 登入資料 `AWS::S3.new` 或其他服務的對等項目。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 [在 Vagrant 執行個體上使用適用於 Ruby 的 SDK](cookbooks-101-opsworks-s3-vagrant.md)顯示如何降低公開您登入資料的風險，方法是將登入資料存放在節點物件中，並參考配方程式碼中的屬性。當您在 Amazon EC2 執行個體上執行配方時，您有更好的選項：[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。 IAM 角色的運作方式與 IAM 使用者非常類似。它的已連接政策授予使用各種 AWS 服務的許可。不過，您可以將角色指派給 Amazon EC2 執行個體，而不是個人。該執行個體上執行的應用程式接著可以取得已連接政策所授予的許可。使用角色，登入資料絕不會出現在您的程式碼中，即使是間接也是一樣。本主題說明如何使用 IAM 角色在 Amazon EC2 執行個體[在 Vagrant 執行個體上使用適用於 Ruby 的 SDK](cookbooks-101-opsworks-s3-vagrant.md)上從執行配方。您可以搭配執行此配方與使用 kitchen-ec2 驅動程式的 Test Kitchen，如[範例 9：使用 Amazon EC2 執行個體](cookbooks-101-basics-ec2.md)中所述。不過，在 Amazon EC2 執行個體上安裝適用於 Ruby 的 SDK 有點複雜，而不是您需要為 OpsWorks Stacks 關注的事項。所有 OpsWorks Stacks Linux 執行個體預設都會安裝適用於 Ruby 的 SDK。為了簡化，範例因此使用 OpsWorks Stacks 執行個體。第一步是設定 IAM 角色。此範例採用最簡單的方法，即使用 OpsWorks Stacks 在您建立第一個堆疊時建立的 Amazon EC2 角色。它命名為 `aws-opsworks-ec2-role`。不過， OpsWorks Stacks 不會將政策連接至該角色，因此預設不會授予任何許可。您必須將`AmazonS3ReadOnlyAccess`政策連接至`aws-opsworks-ec2-role`角色，才能授予適當的許可。如需如何將政策連接至角色的詳細資訊，請參閱《[IAM 使用者指南》中的新增 IAM 身分許可（主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)。 ** 您可以在建立或更新堆疊時指定角色。設定具有自訂 layer 的堆疊，如[在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)中所述，並有一項新增。在**新增堆疊**頁面上，確認**預設 IAM 執行個體描述**檔設定為 **aws-opsworks-ec2-role**。 OpsWorks Stacks 接著會將該角色指派給堆疊的所有執行個體。設定技術指南的程序與[在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)所使用的程序類似。以下是簡短摘要；您應該參閱該範例以了解詳細資訊。 **設定技術指南** 1. 建立並導覽至名為 `s3bucket_ops` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `s3bucket_ops`。 ``` name "s3bucket_ops" version "0.1.0" ``` 1. 在 `recipes` 內建立 `s3bucket_ops` 目錄。 1. 使用下列配方建立 `default.rb` 檔案，並將它儲存至 `recipes` 目錄。 ``` Chef::Log.info("******Downloading a file from Amazon S3.******") ruby_block "download-object" do block do require 'aws-sdk' s3 = AWS::S3.new myfile = s3.buckets['cookbook_bucket'].objects['myfile.txt'] Dir.chdir("/tmp") File.open("myfile.txt", "w") do |f| f.syswrite(myfile.read) f.close end end action :run end ``` 1. 建立的`.zip`封存，`s3bucket_ops`並將封存上傳至 Amazon S3 儲存貯體。為求簡化，請[將封存設為公有](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)，然後記錄封存的 URL 以供日後使用。您也可以將技術指南存放在私有 Amazon S3 封存中，或其他幾種儲存庫類型。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。此配方與先前範例所使用的配方類似，但例外狀況如下。 + 由於 OpsWorks Stacks 已安裝適用於 Ruby 的 SDK，因此已刪除`chef_gem`資源。 + 配方不會將任何登入資料傳遞給 `AWS::S3.new`。會根據執行個體的角色，將登入資料自動指派給應用程式。 + 配方使用 `Chef::Log.info` 將訊息新增至 Chef 日誌。針對此範例建立堆疊，如下所示。您也可以使用現有 Windows 堆疊。只需要更新技術指南，如後面所述。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後按一下 **Add Stack (新增堆疊)**。 1. 指定下列設定，並接受其他設定的預設值，然後按一下 **Add Stack (新增堆疊)**。 + **名稱** – RubySDK + **預設 SSH 金鑰** – Amazon EC2 金鑰對如果您需要建立 Amazon EC2 金鑰對，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。請注意，金鑰對必須屬於與執行個體相同的 AWS 區域。此範例使用預設的美國西部（奧勒岡）區域。 1. 按一下 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – S3Download + **簡短名稱** – s3download 任何 layer 類型都會實際作用於 Linux 堆疊，但此範例不需要其他 layer 類型所安裝的任何套件，因此自訂 layer 是最簡單的方法。 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 layer，以及[啟動它](workinginstances-starting.md)。您現在可以安裝並執行配方 **執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **Http Archive** + **儲存庫 URL** – 您先前記錄的技術指南的封存 URL。針對其他設定使用預設值，然後按一下 **Save (儲存)** 以更新堆疊組態。 1. [執行更新自訂技術指南堆疊命令](workingstacks-commands.md)，以在堆疊執行個體上安裝最新版的自訂技術指南。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 透過使用配方執行**執行執行配方**堆疊命令來執行設定為 **的配方****s3bucket\$1ops::default**。此命令會啟動 Chef 執行，內含包含 `s3bucket_ops::default` 的回合清單。 **注意** 您通常會讓 OpsWorks Stacks 透過將配方指派給適當的生命週期事件來[自動執行配方](workingcookbook-assigningcustom.md)。您可以手動觸發事件來執行這類配方。您可以使用堆疊命令來觸發安裝和設定事件，以及使用[部署命令](workingapps-deploying.md)來觸發部署和解除部署事件。成功執行配方之後，您就可以驗證配方。 **驗證 s3bucket\$1ops** 1. 第一步是檢查 Chef 日誌。您的堆疊應該有一個名為 opstest1 的執行個體。在**執行個體**頁面上，按一下執行個體**日誌**欄中**的顯示**以顯示 Chef 日誌。向下捲動，並在接近底端發現您的日誌訊息。 ``` ... [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/attributes/customize.rb in the cache. [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/metadata.rb in the cache. [2014-07-31T17:01:46+00:00] INFO: ******Downloading a file from Amazon S3.****** [2014-07-31T17:01:46+00:00] INFO: Processing template[/etc/hosts] action create (opsworks_stack_state_sync::hosts line 3) ... ``` 1. [使用 SSH 登入執行個體](workinginstances-ssh.md)，並列出 `/tmp` 的內容。 # 在 Stacks Windows 執行個體上使用適用於 Ruby OpsWorks 的 SDK **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此範例假設您已完成[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)範例。否則，您應該先執行該範例。具體而言，它說明如何啟用 RDP 存取您的執行個體。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。本主題說明如何在 OpsWorks Stacks Windows 執行個體[適用於 Ruby 的 AWS SDK](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)上使用，從 S3 儲存貯體下載檔案。如果 Ruby 應用程式需要存取 AWS 資源，您必須使用具有適當許可的一組 AWS 登入資料來提供它。對於配方，提供 AWS 登入資料的最佳選項是使用 AWS Identity and Access Management ([IAM) 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。IAM 角色的運作方式與具有連接政策的 IAM 使用者非常類似，該政策授予使用各種 AWS 服務的許可。不過，您可以將角色指派給 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體，而不是個人。該執行個體上執行的應用程式接著可以取得已連接政策所授予的許可。使用角色，登入資料絕不會出現在您的程式碼中，即使是間接也是一樣。第一步是設定 IAM 角色。此範例採用最簡單的方法，即使用 OpsWorks Stacks 在您建立第一個堆疊時建立的 Amazon EC2 角色。它命名為 `aws-opsworks-ec2-role`。不過， OpsWorks Stacks 不會將政策連接至該角色，因此預設不會授予任何許可。您必須將`AmazonS3ReadOnlyAccess`政策連接至`aws-opsworks-ec2-role`角色，才能授予適當的許可。如需如何將政策連接至角色的詳細資訊，請參閱《[IAM 使用者指南》中的新增 IAM 身分許可（主控台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)。 ** 您可以在建立或更新堆疊時指定角色。設定具有自訂 layer 的堆疊，如[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)中所述，並有一項新增。在**新增堆疊**頁面上，確認**預設 IAM 執行個體描述**檔設定為 **aws-opsworks-ec2-role**。 OpsWorks Stacks 接著會將該角色指派給堆疊的所有執行個體。設定技術指南的程序與[在 Linux 執行個體上執行配方](cookbooks-101-opsworks-opsworks-instance.md)所使用的程序類似。以下是簡短摘要；如需詳細資訊，請參閱該範例。 **設定技術指南** 1. 建立並導覽至名為 `s3bucket_ops` 的目錄。 1. 使用下列內容建立 `metadata.rb` 檔案，並將它儲存至 `s3bucket_ops`。 ``` name "s3download" version "0.1.0" ``` 1. 在 `recipes` 內建立 `s3download` 目錄。 1. 使用下列配方建立 `default.rb` 檔案，並將它儲存至 `recipes` 目錄。將 *windows-cookbooks* 取代為您用來存放要下載之檔案的 S3 儲存貯體名稱。 ``` Chef::Log.info("******Downloading an object from S3******") chef_gem "aws-sdk-s3" do compile_time false action :install end ruby_block "download-object" do block do require 'aws-sdk-s3' Aws.use_bundled_cert! s3_client = Aws::S3::Client.new(region:'us-west-2') s3_client.get_object(bucket: 'windows-cookbooks', key: 'myfile.txt', response_target: '/chef/myfile.txt') end action :run end ``` 1. 建立 `s3download` 的 `.zip` 封存，並將檔案上傳至 S3 儲存貯體。將檔案設為公有，並記錄 URL 以供日後使用。 1. 建立名為 `myfile.txt` 的文字檔，並將其上傳至 S3 儲存貯體。這是您配方將下載的檔案，因此您可以使用任何方便使用的儲存貯體。配方會執行下列任務。 1：安裝適用於 Ruby v2 的 SDK。此範例使用適用於 Ruby 的 SDK 下載物件。不過， OpsWorks Stacks 不會在 Windows 執行個體上安裝此開發套件，因此配方的第一部分會使用 [https://docs.chef.io/chef/resources.html#chef-gem](https://docs.chef.io/chef/resources.html#chef-gem) 資源來處理該任務。您可以使用此資源來安裝 Gem 以供 Chef 使用，其中包含配方。 2：下載檔案。配方的第三個部分使用 [https://docs.chef.io/chef/resources.html#ruby-block](https://docs.chef.io/chef/resources.html#ruby-block) 資源來執行適用於 Ruby 的 SDK v2 程式碼，`myfile.txt`從名為的 S3 儲存貯體下載`windows-cookbooks`到執行個體的`/chef`目錄。將 `windows-cookbooks` 變更為包含 `myfile.txt` 的儲存貯體名稱。 **注意** 配方是 Ruby 應用程式，因此，您可以將 Ruby 程式碼放入配方主體中；它不需要在 `ruby_block` 資源中。不過，Chef 會先執行配方主體中的 Ruby 程式碼，接著依序執行每個資源。在此範例中，如果您將下載程式碼放在配方的內文中，它將會失敗，因為它取決於適用於 Ruby 的 SDK，以及安裝 SDK `chef_gem`的資源尚未執行。`ruby_block` 資源中的程式碼會在資源執行時執行，並在`chef_gem`資源安裝適用於 Ruby 的 SDK 後執行。針對此範例建立堆疊，如下所示。您也可以使用現有 Windows 堆疊。只需要更新技術指南，如後面所述。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。指定下列設定，並接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)**。 + **名稱** – S3Download + **區域** – 美國西部（奧勒岡）此範例適用於任何區域，但我們建議您使用美國西部（奧勒岡）進行教學課程。 + **預設作業系統** – Microsoft Windows Server 2012 R2 1. 選擇 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – S3Download + **簡短名稱** – s3download 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 S3Download layer，以及[啟動它](workinginstances-starting.md)。您現在可以安裝並執行配方 **執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 Archive**。 + **儲存庫 URL** – 您先前記錄的技術指南的封存 URL。接受其他設定的預設值，然後選擇 **Save (儲存)** 以更新堆疊組態。 1. [執行更新自訂技術指南堆疊命令](workingstacks-commands.md)，以在堆疊線上執行個體上安裝最新版的自訂技術指南。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 使用配方執行**執行執行配方**堆疊命令**以執行設定為的配方****s3download::default**。此命令會啟動 Chef 執行，內含包含 `s3download::default` 的回合清單。 **注意** 您通常會讓 OpsWorks Stacks 透過將配方指派給適當的生命週期事件來[自動執行](workingcookbook-assigningcustom.md)配方。您也可以手動觸發事件來執行這類配方。您可以使用堆疊命令來觸發安裝和設定事件，以及使用[部署命令](workingapps-deploying.md)來觸發部署和解除部署事件。成功執行配方之後，您就可以驗證配方。 **驗證 s3download** 1. 第一步是檢查 Chef 日誌。您的堆疊應該有一個名為 s3download1 的執行個體。在**執行個體**頁面上，選擇在執行個體的**日誌**欄中**顯示** ，以顯示 Chef 日誌。向下捲動，以在接近底端發現您的日誌訊息。 ``` ... [2015-05-01T21:11:04+00:00] INFO: Loading cookbooks [s3download@0.0.0] [2015-05-01T21:11:04+00:00] INFO: Storing updated cookbooks/s3download/recipes/default.rb in the cache. [2015-05-01T21:11:04+00:00] INFO: ******Downloading an object from S3****** [2015-05-01T21:11:04+00:00] INFO: Processing chef_gem[aws-sdk] action install (s3download::default line 3) [2015-05-01T21:11:05+00:00] INFO: Processing ruby_block[download-object] action run (s3download::default line 8) ... ``` 1. [使用 RDP 登入執行個體](workinginstances-rdp.md)，並檢查 `c:\chef` 的內容。 # 安裝 Windows 軟體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些範例假設您已完成[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)範例。否則，您應該先執行該範例。具體而言，它說明如何啟用 RDP 存取您的執行個體。 Windows 執行個體是從 Windows Server 2012 R2 Standard 開始，因此，您一般需要安裝一些軟體。詳細資訊取決於軟體類型。 + Windows 功能是選用的系統元件，包括 .NET 架構和網際網路資訊服務 (IIS)，您可以下載到您的執行個體。 + 第三方軟體通常會隨附您必須下載至執行個體後執行的安裝程式套件 (例如 MSI 檔案)。一些 Microsoft 軟體也會隨附安裝程式套件。本節說明如何實作技術指南來安裝 Windows 功能和套件。它也會介紹 Chef Windows 技術指南，其中包含資源和協助程式函數可簡化實作 Windows 執行個體的配方。 **Topics** + [安裝 Windows 功能：IIS](cookbooks-101-opsworks-install-software-feature.md) + [在 Windows 執行個體上安裝套件](cookbooks-101-opsworks-install-software-package.md) # 安裝 Windows 功能：IIS **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Windows 功能是一組選用的系統元件，包括 .NET 架構和網際網路資訊服務 (IIS)。本主題說明如何實作技術指南來安裝常用的功能：網際網路資訊服務 (IIS)。 **注意** [安裝套件](cookbooks-101-opsworks-install-software-package.md)顯示如何安裝軟體，其隨附您必須下載至執行個體並執行的安裝程式套件 (例如 MSI 檔案)。[IIS 技術指南](https://github.com/opscode-cookbooks/iis) [在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)顯示如何使用 `powershell_script` 資源來安裝 Windows 功能。此範例顯示替代方式：使用 Chef [Windows 技術指南的](https://github.com/opscode-cookbooks/windows) `windows_feature` 資源。此技術指南包含一組資源，以使用[部署映像服務和管理](https://technet.microsoft.com/en-us/library/dd744256%28v=ws.10%29.aspx)在 Windows 上執行各種任務，包括功能安裝。 **注意** Chef 也具有 IIS 技術指南，以用來管理 IIS。如需詳細資訊，請參閱 [IIS 技術指南](https://github.com/opscode-cookbooks/iis)。 **設定技術指南** 1. 前往 [windows 技術指南 GitHub 儲存庫](https://github.com/opscode-cookbooks/windows)，並下載 `windows` 技術指南。此範例假設您將 `windows` 儲存庫下載為 .zip 檔案，但如果您想要，也可以複製儲存庫。 1. 前往 [chef\$1handler 技術指南 GitHub 儲存庫](https://github.com/opscode-cookbooks/chef_handler)，並下載 `chef-handler` 技術指南。 `windows` 技術指南取決於 `chef_handler`；您將不會直接使用它。此範例假設您將 `chef_handler` 儲存庫下載為 .zip 檔案，但如果您想要，也可以複製儲存庫。 1. 將 `windows` 和 `chef_handler` 技術指南分別解壓縮至 cookbooks 目錄中名為 `windows` 和 `chef_handler` 的目錄。 1. 在 cookbooks 目錄中建立並導覽至名為 `install-iis` 的目錄。 1. 將 `metadata.rb` 檔案新增至具有以下內容的 `install-iis`。 ``` name "install-iis" version "0.1.0" depends "windows" ``` `depends` 指令可讓您在配方中使用 `windows` 技術指南資源。 1. 將 `recipes` 目錄新增至 `install-iis`，並將名為 `default.rb` 的檔案新增至包含下列配方程式碼的那個目錄。 ``` %w{ IIS-WebServerRole IIS-WebServer }.each do |feature| windows_feature feature do action :install end end service 'w3svc' do action [:start, :enable] end ``` 配方使用 `windows` 技術指南的 `windows_feature` 資源來安裝下列項目： 1. [IIS Web 伺服器角色](https://technet.microsoft.com/en-us/library/cc770634.aspx)。 1. [IIS Web 伺服器](https://technet.microsoft.com/en-us/library/cc753433%28v=ws.10%29.aspx)。配方接著會使用 [https://docs.chef.io/chef/resources.html#service](https://docs.chef.io/chef/resources.html#service) 資源來啟動和啟用 IIS 服務 (W3SVC)。 **注意** 如需完整的可用 Windows 功能清單，請[使用 RDP 登入執行個體](workinginstances-rdp.md)，並開啟命令提示視窗，然後執行下列命令。請注意，清單相當長。 ``` dism /online /Get-Features ``` 1. 建立包含 `install-iis`、`chef_handler` 和 `windows` 技術指南的 `.zip` 封存，並將封存上傳至 S3 儲存貯體。將封存設為公有，並記錄 URL 以供日後使用。此範例假設封存命名為 `install-iis.zip`。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。針對此範例建立堆疊，如下所示。您也可以使用現有 Windows 堆疊。只需要更新技術指南，如後面所述。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。指定下列設定，並接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)**。 + **名稱** – InstallIIS + **區域** – 美國西部（奧勒岡）此範例適用於任何區域，但我們建議您使用美國西部（奧勒岡）進行教學課程。 + **預設作業系統** – Microsoft Windows Server 2012 R2 1. 選擇 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – IIS + **簡短名稱** – iis 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 IIS layer，以及[啟動它](workinginstances-starting.md)。您現在可以安裝技術指南，並執行配方 **安裝技術指南並執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 封存** + **儲存庫 URL** – 您先前記錄的技術指南封存的 URL。接受其他設定的預設值，然後選擇 **Save (儲存)** 以更新堆疊組態。 1. [執行 **Update Custom Cookbooks (更新自訂技術指南)** 堆疊命令](workingstacks-commands.md)，以在堆疊線上執行個體上安裝最新版的自訂技術指南。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 使用配方執行**執行執行配方**堆疊命令**以執行設定為的配方****install-iis::default**。此命令會啟動 Chef 執行，以執行指定的配方。 **注意** 為了方便起見，此範例使用**執行配方**，但您通常會讓 OpsWorks Stacks 透過將配方指派給適當的生命週期事件來[自動執行](workingcookbook-assigningcustom.md)配方。您可以手動觸發事件來執行這類配方。您可以使用堆疊命令來觸發安裝和設定事件，以及使用[部署命令](workingapps-deploying.md)來觸發部署和解除部署事件。 1. 若要驗證安裝，請[使用 RDP 連線至執行個體](workinginstances-rdp.md)，並開啟 Windows 檔案總管。檔案系統現在應該會有一個 `C:\inetpub` 目錄。如果您檢查控制台系統管理工具應用程式中的服務清單，則 IIS 應該接近底端。不過，它將命名為 World Wide Web Publishing Service，而不是 IIS。 # 在 Windows 執行個體上安裝套件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此範例假設您已完成[在 Windows 執行個體上執行配方](cookbooks-101-opsworks-opsworks-windows.md)範例。否則，您應該先執行該範例。具體而言，它說明如何啟用 RDP 存取您的執行個體。如果您的軟體隨附安裝程式套件 (例如 MSI)，則您必須將檔案下載至執行個體後執行。此範例顯示如何實作技術指南來安裝 MSI 套件 (Python 執行時間)，包括如何定義相關的環境變數。如需如何安裝 Windows 功能 (例如 IIS) 的詳細資訊，請參閱[安裝 Windows 功能：IIS](cookbooks-101-opsworks-install-software-feature.md)。 **設定技術指南** 1. 建立並導覽至名為 `installpython` 的目錄。 1. 將 `metadata.rb` 檔案新增至具有以下內容的 `installpython`。 ``` name "installpython" version "0.1.0" ``` 1. 將 `recipes` 和 `files` 目錄新增至 `installpython`，並將 `default` 目錄新增至檔案。 1. 將 Python 套件從[適用於 Windows 的 Python 版本](https://www.python.org/downloads/windows/)下載至技術指南的 `files\default` 目錄。此範例會安裝 Windows x86-64 版的 Python 3.5.0a3，以使用名為 `python-3.4.3.amd64.msi` 的 MSI 安裝程式。 1. 將名為 `default.rb` 的檔案新增至包含下列配方程式碼的 `recipes` 目錄。 ``` directory 'C:\tmp' do rights :full_control, 'Everyone' recursive true action :create end cookbook_file 'C:\tmp\python-3.4.3.amd64.msi' do source "python-3.4.3.amd64.msi" rights :full_control, 'Everyone' action :create end windows_package 'python' do source 'C:\tmp\python-3.4.3.amd64.msi' action :install end env "PATH" do value 'c:\python34' delim ";" action :modify end ``` 配方會執行下列動作： 1. 使用 [directory](https://docs.chef.io/chef/resources.html#directory) 資源來建立 `C:\tmp` 目錄。如需此資源的詳細資訊，請參閱[範例 3：建立目錄](cookbooks-101-basics-directories.md)。 1. 使用 [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file) 資源，將安裝程式從技術指南的 `files\default` 目錄複製至 `C:\tmp`。如需此資源的詳細資訊，請參閱[從技術指南安裝檔案](cookbooks-101-basics-files.md#cookbooks-101-basics-files-cookbook_file)。 1. 使用 [windows\$1package](https://docs.chef.io/chef/resources.html#windows-package) 資源執行 MSI 安裝程式，以將 Python 安裝至 `c:\python34`。安裝程式會建立必要的目錄並安裝檔案，但不會修改系統的 `PATH` 環境變數。 1. 使用 [env](https://docs.chef.io/chef/resources.html#env) 資源，將 `c:\python34` 新增至系統路徑。您可以使用 env 資源定義環境變數。在此情況下，配方透過將 `c:\python34` 新增至路徑，以讓您輕鬆地從命令列執行 Python 指令碼。 + 資源名稱指定環境變數的名稱，在此範例中為 `PATH`。 + `value` 屬性指定變數的值，在此範例中為 `c:\\python34` (您需要逸出 `\` 字元)。 + `:modify` 動作會將指定的值附加到變數目前值的前面。 + `delim` 屬性指定隔開新值與現有值的分隔符號，在此範例中為 `;`。 1. 建立 `.zip` 的 `installpython` 封存，並將封存上傳至 S3 儲存貯體，然後將它設為公有。記錄封存的 URL，供日後使用。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。針對此範例建立堆疊，如下所示。您也可以使用現有 Windows 堆疊。只需要更新技術指南，如後面所述。 **建立堆疊** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。指定下列設定，並接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)**。 + **名稱** – InstallPython + **區域** – 美國西部（奧勒岡）此範例適用於任何區域，但我們建議您使用美國西部（奧勒岡）進行教學課程。 + **預設作業系統** – Microsoft Windows Server 2012 R2 1. 選擇 **Add a layer (新增 layer)**，並[新增自訂 layer](workinglayers-custom.md) 至具有下列設定的堆疊。 + **名稱** – Python + **簡短名稱** – python 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 Python layer，以及[啟動它](workinginstances-starting.md)。在執行個體上線之後，您可以安裝技術指南並執行配方 **安裝技術指南並執行配方** 1. [編輯堆疊以啟用自訂技術指南](workingcookbook-installingcustom-enable.md)，然後指定下列設定。 + **儲存庫類型** – **S3 Archive**。 + **儲存庫 URL** – 您先前記錄的技術指南的封存 URL。接受其他設定的預設值，然後選擇 **Save (儲存)** 以更新堆疊組態。 1. [執行 **Update Custom Cookbooks (更新自訂技術指南)** 堆疊命令](workingstacks-commands.md)，以在堆疊線上執行個體上安裝最新版的自訂技術指南。如果存在舊版的技術指南，則此命令會予以覆寫。 1. 透過使用配方執行**執行執行配方**堆疊命令來執行設定為 **的配方****installpython::default**。此命令會啟動 Chef 執行，內含包含 `installpython::default` 的回合清單。 **注意** 為了方便起見，此範例使用**執行配方**，但您通常會讓 OpsWorks Stacks 透過將配方指派給適當的生命週期事件來[自動執行](workingcookbook-assigningcustom.md)配方。您可以手動觸發事件來執行這類配方。您可以使用堆疊命令來觸發安裝和設定事件，以及使用[部署命令](workingapps-deploying.md)來觸發部署和解除部署事件。 1. 若要驗證安裝，請[使用 RDP 連線至執行個體](workinginstances-rdp.md)，並開啟 Windows 檔案總管。 + 檔案系統現在應該會有一個 `C:\Python34` 目錄。 + 如果您從命令列執行 `path`，則它應該看起來像：`PATH=c:\python34;C:\Windows\system32;...` + 如果您從命令列執行 `python --version`，則它應該會傳回 `Python 3.4.3`。 # 覆寫內建屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題僅適用於 Linux 堆疊。您無法在 Windows 堆疊上覆寫內建屬性。 OpsWorks Stacks 會在每個執行個體上安裝一組內建技術指南。許多內建技術指南都支援內建 layer，而且其屬性檔案定義各種預設系統和應用程式設定 (例如 Apache 伺服器組態設定)。將這些設定放在屬性檔案中，即可使用下列方式覆寫對應內建屬性來自訂許多組態設定： + 使用自訂 JSON 定義屬性。此方式的優點是簡單並具彈性。不過，您必須手動輸入自訂 JSON，因此沒有健全的方法可以管理屬性定義。 + 實作自訂技術指南，並在 `customize.rb` 屬性檔案中定義屬性。此方式比使用自訂 JSON 更不具彈性，但是更為健全，因為您可以將自訂技術指南放在來源控制之下。本主題說明如何使用自訂技術指南屬性檔案覆寫內建屬性，並使用 Apache 伺服器做為範例。如需如何覆寫具有自訂 JSON 之屬性的詳細資訊，請參閱 [使用自訂 JSON](workingcookbook-json-override.md)。如需如何覆寫屬性的一般討論，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **注意** 偏好使用覆寫屬性來自訂組態設定，但不會一律透過屬性呈現設定。在該情況下，您通常可以覆寫內建配方用來建立組態檔案的範本，來自訂組態檔案。如需範例，請參閱 [覆寫內建範本](cookbooks-101-opsworks-templates.md)。內建屬性通常代表範本檔案中安裝配方用來建立組態檔案的值。例如，其中一個 `apache2` 安裝配方 [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/recipes/default.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/recipes/default.rb) 使用 [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb) 範本來建立 Apache 伺服器的主要組態檔案 `httpd.conf` (Amazon Linux) 或 `apache2.conf` (Ubuntu)。以下是範例檔案中的摘錄： ``` ... # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests <%= node[:apache][:keepaliverequests] %> # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout <%= node[:apache][:keepalivetimeout] %> ## ## Server-Pool Size Regulation (MPM specific) ## ... ``` 此範例中的 `KeepAliveTimeout` 設定是 `[:apache][:keepalivetimeout]` 屬性的值。此屬性的預設值定義於 `apache2` 技術指南的 [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/attributes/apache.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/attributes/apache.rb) 屬性檔案，如下列摘錄所示： ``` ... # General settings default[:apache][:listen_ports] = [ '80','443' ] default[:apache][:contact] = 'ops@example.com' default[:apache][:log_level] = 'info' default[:apache][:timeout] = 120 default[:apache][:keepalive] = 'Off' default[:apache][:keepaliverequests] = 100 default[:apache][:keepalivetimeout] = 3 ... ``` **注意** 如需常用內建屬性的詳細資訊，請參閱[內建技術指南屬性](attributes-recipes.md)。若要支援覆寫內建屬性，所有內建技術指南都會包含 `customize.rb` 屬性檔案，而此屬性檔案透過 `include_attribute` 指令併入所有模組中。內建技術指南的 `customize.rb` 檔案未包含任何屬性定義，而且不會影響內建屬性。若要覆寫內建屬性，您可以建立與內建技術指南同名的自訂技術指南，並將自訂屬性定義放入也命名為 `customize.rb` 的屬性檔案中。該檔案的優先順序高於內建版本，並包含在任何相關模組中。如果您在 `customize.rb` 中定義任何內建屬性，則它們會覆寫對應的內建屬性。此範例顯示如何覆寫內建 `[:apache][:keepalivetimeout]` 屬性，以將其值設定為 5，而非 3。您可以將類似的方式用於任何內建屬性。不過，請注意您覆寫哪些屬性。例如，`opsworks` 命名空間中的覆寫屬性可能會導致一些內建配方的問題。 **重要** 請不要修改內建屬性檔案的複本本身來覆寫內建屬性。例如，您「可以」**將 `apache.rb` 的複本放入您自訂技術指南的 `apache2/attributes` 資料夾，並修改它的一些設定。不過，此檔案的優先順序高於內建版本，而內建配方現在會使用您的 `apache.rb` 版本。如果 OpsWorks Stacks 稍後修改內建`apache.rb`檔案，除非您手動更新版本，否則配方將不會取得新值。透過使用 `customize.rb`，您只會覆寫指定的屬性；內建配方會持續自動取得每個尚未覆寫之屬性的最新值。若要開始，請建立自訂技術指南。 **建立技術指南** 1. 在 `opsworks_cookbooks` 目錄內，建立並導覽至名為 `apache2` 的技術指南目錄。若要覆寫內建屬性，自訂技術指南必須與內建技術指南同名，在此範例中為 `apache2`。 1. 在 `apache2` 目錄中，建立 `attributes` 目錄。 1. 將名為 `customize.rb` 的檔案新增至 `attributes` 目錄，並使用它來定義您想要覆寫的內建技術指南屬性。在此範例中，檔案應該包含下列項目： ``` normal[:apache][:keepalivetimeout] = 5 ``` **重要** 若要覆寫內建屬性，自訂屬性必須是 `normal` 類型或以上類型，並且具有與對應內建屬性完全相同的節點名稱。`normal` 類型確保自訂屬性的優先順序高於內建屬性，即所有 `default` 類型。如需詳細資訊，請參閱[屬性優先順序](workingcookbook-attributes-precedence.md)。 1. 建立`opsworks_cookbooks`名為的`.zip`封存，`opsworks_cookbooks.zip`並將封存上傳至 Amazon Simple Storage Service (Amazon S3) 儲存貯體。為求簡化，請[將檔案設為公有](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)。記錄 URL，供日後使用。您也可以將技術指南存放在私有 Amazon S3 封存或其他儲存庫類型中。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。若要使用自訂屬性，請建立堆疊，並安裝技術指南。 **使用自訂屬性** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。 1. 指定下列標準設定。 + **名稱** – ApacheConfig + **區域** – 美國西部（奧勒岡）您可以將堆疊放在任何區域，但我們建議美國西部（奧勒岡）進行教學課程。 + **預設 SSH 金鑰** – EC2 金鑰對如果您需要建立 EC2 金鑰對，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。請注意，金鑰對必須屬於與堆疊相同的 AWS 區域。選擇 **Advanced>> (進階>>)**，並將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 設定為 **Yes (是)**，然後指定下列設定。 + **儲存庫類型** – **Http Archive** + **儲存庫 URL** – 您先前記錄的技術指南封存的 URL 接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)** 來建立堆疊。 **注意** 此範例使用預設作業系統：Amazon Linux。如果您想要，可以使用 Ubuntu。唯一的差異是，在 Ubuntu 系統上，內建安裝配方會產生具有相同設定且名為 `apache2.conf` 的組態檔案，並將它放入 `/etc/apache2` 目錄中。 1. 選擇**新增 layer**，然後將具有預設設定的 [Java App Server layer 新增至](layers-java.md)堆疊。 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 layer，然後啟動執行個體。在此範例中，t2.micro 執行個體就已足夠。 1. 執行個體上線之後，請[使用 SSH 連線至它](workinginstances-ssh.md)。`httpd.conf` 檔案位在 `/etc/httpd/conf` 目錄中。如果您檢查檔案，則應該會看到您的自訂 `KeepAliveTimeout` 設定。這些設定的其餘部分將會有內建 `apache.rb` 檔案中的預設值。`httpd.conf` 的相關部分應該看起來與下列類似： ``` ... # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout 5 ... ``` # 覆寫內建範本 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題僅適用於 Linux 堆疊。您無法在 Windows 堆疊上覆寫內建範本。 Stacks OpsWorks 內建配方使用範本在執行個體上建立檔案，主要是伺服器組態檔案，例如 Apache。例如，`apache2` 配方使用 [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb) 範本來建立 Apache 伺服器的主要組態檔案 `httpd.conf` (Amazon Linux) 或 `apache2.conf` (Ubuntu)。這些範本中的大部分組態設定是以屬性呈現，因此自訂組態檔案的偏好方式是覆寫適當的內建屬性。如需範例，請參閱 [覆寫內建屬性](cookbooks-101-opsworks-attributes.md)。不過，如果您想要自訂的設定不是以內建屬性呈現，或根本不在範本中，則必須覆寫範本本身。本主題說明如何覆寫內建範本，以指定自訂 Apache 組態設定。您可以將 `ErrorDocument` 設定新增至 `httpd.conf` 檔案，以將自訂錯誤回應提供給 Apache。`apache2.conf.erb` 只會包含一些標示為註解的範例，如下所示： ``` ... # # Customizable error responses come in three flavors: # 1) plain text 2) local redirects 3) external redirects # # Some examples: #ErrorDocument 500 "The server made a boo boo." #ErrorDocument 404 /missing.html #ErrorDocument 404 "/cgi-bin/missing_handler.pl" #ErrorDocument 402 http://www.example.com/subscription_info.html ... ``` 因為這些設定是硬式編碼註解，所以您無法覆寫屬性來指定自訂值；您必須覆寫範本本身。不過，與屬性不同的是，沒有方法可以覆寫範本檔案的特定部分。您必須建立與內建版本同名的自訂技術指南、將範本檔案複製至相同的子目錄，以及視需要修改檔案。本主題顯示如何覆寫 `apache2.conf.erb` 以提供錯誤 500 的自訂回應。如需覆寫範本的一般討論，請參閱[使用自訂範本 ](workingcookbook-template-override.md)。 **重要** 當您覆寫內建範本時，內建配方會使用您自訂的範本版本，而不是內建版本。如果 OpsWorks Stacks 更新內建範本，自訂範本會變得不同步且可能無法正常運作。 OpsWorks Stacks 不會經常進行此類變更，而且當範本確實變更時， OpsWorks Stacks 會列出變更，並讓您選擇升級至新版本。建議您監控 [OpsWorks Stacks 儲存庫](https://github.com/aws/opsworks-cookbooks)的變更，並視需要手動更新自訂範本。請注意，儲存庫的每個支援 Chef 版本都有個別的分支，因此請確定您在正確的分支中。若要開始，請建立自訂技術指南。 **建立技術指南** 1. 在 `opsworks_cookbooks` 目錄中，建立並導覽至名為 `apache2` 的技術指南目錄。若要覆寫內建範本，自訂技術指南必須與內建技術指南同名，在此範例中為 `apache2`。 **注意** 如果您已經完成 [覆寫內建屬性](cookbooks-101-opsworks-attributes.md) 逐步解說，則可以在此範例中使用相同的 `apache2` 技術指南，並略過步驟 2。 1. 使用下列內容建立 `metadata.rb` 檔案，然後將它儲存至 `apache2` 目錄。 ``` name "apache2" version "0.1.0" ``` 1. 在 `apache2` 目錄中，建立 `templates/default` 目錄。 **注意** `templates/default` 目錄適用於使用預設`apache2.conf.erb`範本的 Amazon Linux 執行個體。Ubuntu 14.04 執行個體使用作業系統特定 `apache2.conf.erb` 範本，其位在 `templates/ubuntu-14.04` 目錄中。如果您也想要自訂套用至 Ubuntu 14.04 執行個體，則也必須覆寫該範本。 1. 將[內建 `apache2.conf.erb` 範本](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb)複製至您的 `templates/default` 目錄。開啟範本檔案，並將 `ErrorDocument 500` 行標示為註解，並提供自訂錯誤訊息，如下所示： ``` ... ErrorDocument 500 "A custom error message." #ErrorDocument 404 /missing.html ... ``` 1. 建立`opsworks_cookbooks`名為的`.zip`封存`opsworks_cookbooks.zip`，然後將檔案上傳至 Amazon Simple Storage Service (Amazon S3) 儲存貯體。為求簡化，請[將封存設為公有](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)。記錄封存的 URL，供日後使用。您也可以將技術指南存放在私有 Amazon S3 封存或其他儲存庫類型中。如需詳細資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **注意** 為求簡化，此範例會將硬式編碼錯誤訊息新增至範本。若要變更它，您必須修改範本，並[重新安裝技術指南](workingcookbook-installingcustom-enable-update.md)。若要提供更大的彈性，您可以在[自訂技術指南的屬性檔案中定義](cookbooks-101-opsworks-attributes.md)錯誤字串的預設自訂`customize.rb`屬性，並將該屬性的值指派給 `ErrorDocument 500`。例如，如果您將屬性命名為 `[:apache][:custom][:error500]`，則 `apache2.conf.erb` 中的對應行看起來應該與下列類似： ``` ... ErrorDocument 500 <%= node[:apache][:custom][:error500] %> #ErrorDocument 404 /missing.html ... ``` 您接著可以覆寫 `[:apache][:custom][:error500]`，隨時變更自訂錯誤訊息。如果您[使用自訂 JSON 覆寫屬性](workingcookbook-json-override.md)，則甚至不需要接觸技術指南。若要使用自訂範本，請建立堆疊，並安裝技術指南。 **使用自訂範本** 1. 開啟 [OpsWorks Stacks 主控台](https://console.aws.amazon.com/opsworks/)，然後選擇 **Add Stack (新增堆疊)**。 1. 指定下列標準設定： + **名稱** – ApacheTemplate + **區域** – 美國西部（奧勒岡） + **預設 SSH 金鑰** – Amazon Elastic Compute Cloud (Amazon EC2) 金鑰對如果您需要建立 Amazon EC2 金鑰對，請參閱 [Amazon EC2 金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。請注意，金鑰對必須屬於與執行個體相同的 AWS 區域。選擇 **Advanced>> (進階>>)**，並選擇 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 指定下列設定： + **儲存庫類型** – **Http Archive** + **儲存庫 URL** – 您先前記錄的技術指南封存的 URL 接受其他設定的預設值，然後選擇 **Add Stack (新增堆疊)** 來建立堆疊。 1. 選擇**新增 layer**，然後使用預設設定將 [Java App Server layer 新增至](layers-java.md)堆疊。 1. [新增全年無休執行個體](workinginstances-add.md) (具有預設設定) 至 layer，然後啟動執行個體。在此範例中，t2.micro 執行個體就已足夠。 1. 執行個體上線之後，請[使用 SSH 連線至它](workinginstances-ssh.md)。`httpd.conf` 檔案位在 `/etc/httpd/conf` 目錄中。檔案應該包含自訂 `ErrorDocument` 設定，看起來會與下列類似： ``` ... # Some examples: ErrorDocument 500 "A custom error message." #ErrorDocument 404 /missing.html #ErrorDocument 404 "/cgi-bin/missing_handler.pl" #ErrorDocument 402 http://www.example.com/subscription_info.html ... ``` # 平衡 Layer 的負載 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 提供兩種負載平衡選項：[Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elastic-load-balancing.html) 和 [HAProxy](http://www.haproxy.org/)，通常用於平衡應用程式伺服器層執行個體的負載。本主題說明其各自的優點和限制，幫助您在 layer 新增負載平衡時決定要選擇的選項。在某些情況下，最好的方法是兩個都使用。 **SSL 終止** 內建 HAProxy layer 不會處理 SSL 終止；您必須在伺服器上終止 SSL。此方法的優點是會加密流量，直到它到達伺服器。不過，伺服器必須處理解密，這會增加伺服器的負載。此外，您必須將您的 SSL 憑證放在應用程式伺服器上，這讓使用者更容易存取。使用 Elastic Load Balancing，您可以在負載平衡器終止 SSL。這可減少應用程式伺服器上的負載，但負載平衡器與伺服器之間的流量不會加密。Elastic Load Balancing 也可讓您[終止伺服器上的 SSL](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-https-load-balancers.html)，但設定有點複雜。 **擴展** 如果傳入流量超過 HAProxy 負載平衡器的容量，您就必須手動增加容量。 Elastic Load Balancing 會自動擴展以處理傳入流量。若要確保 Elastic Load Balancing 負載平衡器在第一次上線時有足夠的容量來處理預期的負載，您可以[對其進行預熱](https://aws.amazon.com/articles/1636185810492479#pre-warming)。 **負載平衡器故障** 如果託管您 HAProxy 伺服器的執行個體故障，您可能要讓整個網站離線，直到您可以重新啟動執行個體為止。 Elastic Load Balancing 比 HAProxy 更能防止故障。例如，它在每個已註冊 EC2 執行個體的可用區域中佈建負載平衡節點。如果某個區域的服務中斷，其他節點會繼續處理傳入的流量。如需詳細資訊，請參閱 [Elastic Load Balancing 概念](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html)。 **閒置逾時** 如果伺服器閒置超過指定的閒置逾時值，兩種負載平衡器都會終止連線。 + HAProxy – 閒置逾時值沒有上限。 + Elastic Load Balancing – 預設閒置逾時值為 60 秒，上限為 3600 秒 (60 分鐘）。 Elastic Load Balancing 閒置時間限制足以用於大多數用途。如果您需要較長的閒置逾時，我們建議您使用 HAProxy。例如： + 推送通知所用之長時間執行的 HTTP 連線。 + 您用來執行可能需要超過 60 分鐘任務的管理界面。 **以 URL 為基礎的映射** 您可能希望使用負載平衡器，根據請求的 URL 將傳入請求轉發到特定的伺服器。例如，假設您有 10 個一組的應用程式伺服器支援線上商務應用程式。八個伺服器處理型錄，兩個處理付款。您想要根據請求 URL，將所有付款相關的 HTTP 請求導向至付款伺服器。在此案例中，您會將包含「付款」或「結帳」的所有 URL 導向至其中一個付款伺服器。透過 HAProxy，您可以使用以 URL 為基礎的映射將包含指定字串的 URL 導向到特定的伺服器。若要搭配 OpsWorks Stacks 使用 URL 型映射，您必須覆寫`haproxy`內建技術指南中的`haproxy-default.erb`範本，以建立自訂 HAProxy 組態檔案。如需詳細資訊，請參閱 [HAProxy 組態手冊](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)和[使用自訂範本 ](workingcookbook-template-override.md)。您不能使用以 URL 為基礎的映射處理 HTTPS 請求。HTTPS 請求已加密，所以 HAProxy 無法檢查請求 URL。 Elastic Load Balancing 對 URL 映射的支援有限。如需詳細資訊，請參閱 [Elastic Load Balancing 的接聽程式組態](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)。 **建議：**我們建議您使用 Elastic Load Balancing 進行負載平衡，除非您有只能由 HAProxy 處理的需求。在這種情況下，最佳方法可能是使用 Elastic Load Balancing 作為前端負載平衡器，將傳入流量分配到一組 HAProxy 伺服器。若要執行此作業： + 設定您堆疊中每個可用區域的 HAProxy 執行個體，將請求分配到區域的應用程式伺服器。 + 將 HAProxy 執行個體指派給 Elastic Load Balancing 負載平衡器，然後將傳入的請求分配至 HAProxy 負載平衡器。這種方法可讓您使用以 URL 為基礎的 HAProxy 映射，將不同類型的請求分配到適當的應用程式伺服器。不過，如果其中一個 HAProxy 伺服器離線，網站會繼續運作，因為 Elastic Load Balancing 負載平衡器會自動將傳入流量分配到運作狀態良好的 HAProxy 伺服器。請注意，您必須使用 Elastic Load Balancing 做為前端負載平衡器；HAProxy 伺服器無法將請求分發到其他 HAProxy 伺服器。 # 從 Chef Server 遷移至 OpsWorks Stacks **重要** 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 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)。 ## 使用資料包 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 搜尋 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 ``` ## 管理技術指南和配方 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) ### 存放技術指南使用 Chef Server 時，您會將您的技術指南存放在伺服器上，並將他們從伺服器部署到執行個體。使用 OpsWorks Stacks，您可以將技術指南存放在儲存庫中：S3 或 HTTP 封存或 Git 或 Subversion 儲存庫。您可以指定[安裝技術指南](workingapps-creating.md)時 OpsWorks ，Stacks 從儲存庫下載程式碼到堆疊執行個體所需的資訊。若要從 Chef Server 進行遷移，您必須將您的技術指南放在這些儲存庫中的其中一個。如需如何建構技術指南儲存庫的資訊，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)。 ### 執行配方在 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 環境 OpsWorks Stacks 不支援 Chef 環境；`node.chef_environment`一律傳回 `_default`。 # OpsWorks Stacks Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 部署的每個執行個體都必須是至少一個層的成員，該層定義執行個體在堆疊中的角色，並控制設定執行個體、安裝套件、部署應用程式等的詳細資訊。如需如何使用 OpsWorks Stacks 建立和管理 layer 的詳細資訊，請參閱 [層](workinglayers.md)。每個 layer 描述都包含 Stacks OpsWorks 針對每個 layer 生命週期事件執行的內建配方清單。這些配方存放在 [https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks)。請注意，清單僅包含由 Stacks OpsWorks 直接執行的配方。這些配方有時會執行相依配方，而相依配方並未列出。若要查看特定事件的完整配方清單 (包括相依和自訂配方)，請檢查適當[生命週期事件 Chef 日誌](troubleshoot-debug-log.md)中的執行清單。 **Topics** + [HAProxy Layer 參考](layers-load.md) + [HAProxy OpsWorks Stacks Layer](layers-haproxy.md) + [MySQL Layer 參考](layers-mysql.md) + [MySQL OpsWorks Layer](workinglayers-db-mysql.md) + [應用程式伺服器 Layer 參考](layers-server.md) + [應用程式伺服器 Layer](workinglayers-servers.md) + [ECS 叢集層參考](#w2ab1c14c71b9c21c23) + [Custom Layer 參考](layers-other-custom.md) + [其他 Layer 參考](layers-other.md) + [其他 Layer](workinglayers-other.md) # HAProxy Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 HAProxy layer 使用可靠的高效能 TCP/HTTP 負載平衡器 [HAProxy](http://haproxy.1wt.eu/)，為 TCP 型和 HTTP 型應用程式提供高可用性負載平衡和代理服務。這特別適用於必須在極高負載下網路爬取同時需要持久性或第 7 Layer 處理的網站。 HAProxy 會監控流量，並顯示網頁上相關聯執行個體的統計資料和運作狀態。根據預設，URI 是 http：//*DNSName*/haproxy？stats，其中 *DNSName* 是 HAProxy 執行個體的 DNS 名稱。 **Short name: (簡短名稱：)** lb **相容性：**HAProxy 層與下列層相容：自訂、db-master 和 memcached。 **開放連接埠：**HAProxy 允許公開存取連接埠 22 (SSH)、80 (HTTP) 和 443 (HTTPS)。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為開啟 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-LB-Server **組態：**若要設定 HAProxy layer，您必須指定下列項目： + 運作狀態檢查 URI (預設：http://*DNSName*/)。 + 統計資料 URI (預設：http://*DNSName*/haproxy?stats)。 + 統計資料密碼 (選用)。 + 運作狀態檢查方法 (選用)。HAProxy 預設會使用 HTTP OPTIONS 方法。您也可以指定 GET 或 HEAD。 + 啟用統計資料 (選用) + 連接埠. 根據預設， OpsWorks Stacks 會將 HAProxy 設定為同時處理 HTTP 和 HTTPS 流量。您可以覆寫 Chef 組態[範本](https://github.com/aws/opsworks-cookbooks/tree/master-chef-11.4/haproxy/templates/default) `haproxy.cfg.erb`，以設定 HAProxy 只處理其中任一個。 **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + haproxy **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version + haproxy::configure **Deploy recipes: (部署配方：)** + deploy::default + haproxy::configure **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + haproxy::stop **安裝:** + OpsWorks Stacks 會使用執行個體的套件安裝程式，將 HAProxy 安裝至其預設位置。 + 您必須設定 syslog 將日誌檔案導向指定的位置。如需詳細資訊，請參閱 [HAProxy](http://haproxy.1wt.eu/)。 # HAProxy OpsWorks Stacks Layer **注意** 此 layer 僅適用於 Chef 11 或更舊的 Linux 類型堆疊。 OpsWorks Stacks HAProxy layer 是 OpsWorks Stacks layer，可為託管 [HAProxy](http://haproxy.1wt.eu/) 伺服器的執行個體提供藍圖，這是可靠的高效能 TCP/HTTP 負載平衡。一個小型執行個體通常便足以處理所有應用程式伺服器流量。 **注意** 堆疊會限制在單一區域。若要將您的應用程式分散至多個區域，您必須為每個區域分別建立堆疊。 **建立 HAProxy layer** 1. 在導覽窗格中，按一下 **Layers (Layer)**。 1. 在 **Layers (Layer)** 頁面上，按一下 **Add a Layer (新增 Layer)** 或 **\$1 Layer (\$1Layer)**。針對 **Layer type (Layer 類型)**，選取 **HAProxy**。 layer 具有下列組態設定，所有設定皆為選擇性。 **HAProxy statistics (HAProxy 統計)** layer 是否會收集及顯示統計。預設值為 **Yes (是)**。 **Statistics URL (統計 URL)** 統計頁面的 URL 路徑。完整的 URL 為 http://*DNSName**StatisticsPath*，其中 *DNSName* 是關聯執行個體的 DNS 名稱。預設 *StatisticsPath* 值為 /haproxy？stats，對應於類似：http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/haproxy?stats。 **Statistics user name (統計使用者名稱)** 統計資料頁面的使用者名稱，您必須提供才能檢視統計資料頁面。預設值為「opsworks」。 **Statistics password (統計密碼)** 統計頁面的密碼，您必須提供此密碼才能檢視統計頁面。預設值為隨機產生的字串。 **Health check URL (運作狀態檢查 URL)** 運作狀態檢查 URL 前綴。HAProxy 使用此 URL 在每個應用程式伺服器執行個體上定期呼叫 HTTP 方法，以判斷執行個體是否正常運作。若運作狀態檢查失敗，HAProxy 會停止將流量路由至執行個體，直到其透過手動方式或[自動修復](workinginstances-autohealing.md)重新啟動。URL 前綴的預設值為 "/"，其對應到伺服器執行個體的首頁：http://*DNSName*/。 **Health check method (運作狀態檢查方法)** 用於檢查執行個體是否正常運作的 HTTP 方法。預設值為 **OPTIONS**，您也可以指定 **GET** 或 **HEAD**。如需詳細資訊，請參閱 [httpchk](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)。 **自訂安全群組** 如果您選擇不自動將內建 OpsWorks 的 Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。請確認群組具備正確的設定，可允許 layer 之間的流量。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 ![\[HAProxy layer configuration form with options for statistics and health check settings.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add_layer_haproxy.png) **注意** 記錄密碼以供日後使用； OpsWorks Stacks 不允許您在建立 layer 之後檢視密碼。但是，您可以透過前往 layer 的 **Edit (編輯)** 頁面，然後按一下 **General Settings (一般設定)** 標籤上的 **Update password (更新密碼)** 來更新密碼。 ![\[HAProxy layer settings interface with options for statistics, health checks, and auto healing.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/haproxy_update_password.png) ## HAProxy Layer 的運作方式根據預設，HAProxy 會執行下列作業： + 接聽 HTTP 和 HTTPS 連接埠的請求。您可以透過覆寫 Chef 組態範本 (`haproxy.cfg.erb`) 來設定 HAProxy 僅接聽 HTTP 或 HTTPS 連接埠。 + 將傳入流量路由至任何身為應用程式伺服器 layer 成員的執行個體。根據預設， OpsWorks Stacks 會將 HAProxy 設定為將流量分散至屬於任何應用程式伺服器層成員的執行個體。例如，您可以同時擁有 Rails App Server 和 PHP App Server 層的堆疊，HAProxy 主節點會將流量分配到兩個層中的執行個體。您可以透過使用自訂配方，來設定預設路由。 + 路由流量至多個可用區域若其中一個可用區域停機，負載平衡器會將傳入流量路由至其他區域內的執行個體，讓您的應用程式可繼續運作，而無須中斷。因此，建議的做法為將您的應用程式伺服器分散至多個可用區域。 + 定期在每個應用程式伺服器執行個體上執行指定的運作狀態檢查方法，以評估其運作狀態。如果方法未在指定的逾時期間內傳回，則假設執行個體失敗，HAProxy 會停止將請求路由到執行個體。 OpsWorks Stacks 也提供自動取代失敗執行個體的方法。如需詳細資訊，請參閱[使用自動修復](workinginstances-autohealing.md)。您可以在您建立 layer 時變更運作狀態檢查方法。 + 收集統計並選擇性的將他們顯示在網頁上。 **重要** 若要使運作狀態檢查搭配預設的 OPTIONS 方法正常運作，您的應用程式必須傳回 2xx 或 3xx 狀態碼。根據預設，當您將執行個體新增至 HAProxy layer 時， OpsWorks Stacks 會為其指派一個彈性 IP 地址來代表應用程式，該應用程式對世界是公有的。由於 HAProxy 執行個體的彈性 IP 地址是應用程式唯一公開的 URL，因此您不需要為基礎應用程式伺服器執行個體建立和管理公有網域名稱。您可以透過前往**執行個體**頁面，檢查執行個體的公有 IP 地址來取得地址，如下圖所示。後方跟隨 (EIP) 的地址即為彈性 IP 地址。如需彈性 IP 地址的詳細資訊，請參閱[彈性 IP 地址 (EIP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)。 ![\[HAProxy instance table showing hostname, status, size, type, AZ, and public IP address.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/load_balancer_elastic_ip.png) 當您停止 HAProxy 執行個體時， OpsWorks Stacks 會保留彈性 IP 地址，並在重新啟動執行個體時將其重新指派給執行個體。如果您刪除 HAProxy 執行個體，根據預設， OpsWorks Stacks 會刪除執行個體的 IP 地址。若要保留地址，請清除 **Delete instance's Elastic IP (刪除執行個體的彈性 IP)** 選項，如下圖所示。 ![\[HAProxy instance deletion confirmation dialog with option to retain Elastic IP address.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/delete_lb.png) 此選項會影響您將新的執行個體新增至 layer 以取代遭刪除執行個體時會發生的情況。 + 如果您保留已刪除執行個體的彈性 IP 地址， OpsWorks Stacks 會將該地址指派給新的執行個體。 + 否則， OpsWorks Stacks 會將新的彈性 IP 地址指派給執行個體，而且您必須更新 DNS 註冊商設定，才能映射到新的地址。當應用程式伺服器執行個體上線或離線時，無論是手動或由於[自動擴展](workinginstances-autoscaling.md)或[自動修復](workinginstances-autohealing.md)，負載平衡器組態都必須更新，以將流量路由到目前的線上執行個體集。此任務會由 layer 的內建配方自動處理： + 當新的執行個體上線時， OpsWorks Stacks 會觸發設定[生命週期事件](workingcookbook-events.md)。HAProxy layer 的內建設定配方會更新負載平衡器組態，因此也會將請求分發到任何新的應用程式伺服器執行個體。 + 當執行個體離線或執行個體運作狀態檢查失敗時， OpsWorks Stacks 也會觸發設定生命週期事件。HAProxy 設定配方會更新負載平衡器的組態，只將流量路由至剩餘的線上執行個體。最後，您也可以搭配 HAProxy layer 使用自訂網域。如需詳細資訊，請參閱[使用自訂網域](workingapps-domains.md)。 ## 統計頁面如果您已啟用統計資料頁面，HAProxy 會在指定的 URL 顯示包含各種指標的頁面。 **檢視 HAProxy 統計資料** 1. 從執行個體**的詳細資訊**頁面取得 HAProxy 執行個體的**公有 DNS** 名稱，並將其複製。 1. 在**圖層**頁面上，按一下 **HAProxy** 開啟圖層的詳細資訊頁面。 1. 從圖層詳細資訊取得統計資料 URL，並將其附加至公有 DNS 名稱。例如：**http://ec2-54-245-102-172.us-west-2.compute.amazonaws.com/haproxy?stats**. 至它。 1. 將先前步驟中的 URL 在您的瀏覽器中貼上，然後使用您在建立 layer 時指定的使用者名稱及密碼以開啟統計頁面。 ![\[HAProxy statistics report showing process information and session data for frontend and backend servers.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/haproxy_stats.png) # MySQL Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 MySQL layer 支援 MySQL，這是一種廣泛使用的關聯式資料庫管理系統。 OpsWorks Stacks 會安裝最新的可用版本，這取決於作業系統。如果您新增 MySQL 執行個體，則會將所需的存取資訊提供給應用程式伺服器 layer。您必須撰寫自訂 Chef 配方來設定主要-主要或主要-從屬組態。 **Short name: (簡短名稱：)** db-master **相容性：**MySQL 層與下列層相容：自訂、lb、memcached、 monitoring-master、 nodejs-app、php-app、rails-app 和 Web。 **開放連接埠：**MySQL layer 允許從堆疊的 Web 伺服器、自訂伺服器和 Rails、PHP 和 Node.js 應用程式伺服器公開存取連接埠 22 (SSH) 和所有連接埠。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 是，位於 `/vol/mysql` **Default security group: (預設安全群組：)** AWS-OpsWorks-DB-Master-Server **組態：**若要設定 MySQL layer，您必須指定下列項目： + 根使用者密碼 + MySQL 引擎 **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + mysql::server + dependencies + deploy::mysql **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version + deploy::mysql **Deploy recipes: (部署配方：)** + deploy::default + deploy::mysql **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + mysql::stop **安裝:** + OpsWorks Stacks 使用執行個體的套件安裝程式，將 MySQL 及其日誌檔案安裝到其預設位置。如需詳細資訊，請參閱 [MySQL 文件](http://dev.mysql.com/doc/index.html)。 # MySQL OpsWorks Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Chef 11 或更舊的 Linux 類型堆疊。 MySQL OpsWorks layer 為做為 [MySQL](http://www.mysql.com/) 資料庫主節點的 Amazon EC2 執行個體提供藍圖。內建配方會為已部署到應用程式伺服器 layer 的每個應用程式建立資料庫。例如，如果您部署 PHP 應用程式 “myapp”，則配方會建立一個 “myapp” 資料庫。 MySQL layer 具有下列組態設定。 **MySQL 根使用者密碼** (必要) 根使用者密碼。 **在每個執行個體上設定根使用者密碼** (選用) 無論根使用者密碼是否包含在堆疊中每個執行個體上安裝的堆疊組態和部署屬性中。預設設定為 **Yes (是)**。如果您將此值設定為**否**， OpsWorks Stacks 只會將根密碼傳遞給應用程式伺服器執行個體。 **自訂安全群組** (選用) 要與 layer 建立關聯的自訂安全群組。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 ![\[Add layer interface for MySQL database setup with OpsWorks, ECS, and RDS options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/add_layer_mysql.png) 您可以將一或多個執行個體新增至 layer，每個執行個體代表一個單獨的 MySQL 資料庫主控。然後，您可以[將執行個體連接至應用程式](workingapps-creating.md)，會在應用程式的應用程式伺服器上安裝必要的連線資訊。然後，應用程式可以使用連線資訊[連線到執行個體的資料庫伺服器](workingapps-connectdb.md)。 # 應用程式伺服器 Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 支援數個不同的應用程式和靜態網頁伺服器。 **Topics** + [AWS Flow (Ruby) Layer 參考](layers-server-flow.md) + [Java App Server Layer 參考](layers-server-java.md) + [Node.js 應用程式伺服器層參考](layers-server-nodejs.md) + [PHP App Server Layer 參考](layers-server-php.md) + [Rails App Server Layer 參考](layers-server-rails.md) + [靜態 Web 伺服器層參考](layers-server-static.md) # AWS Flow (Ruby) Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 AWS Flow (Ruby) layer 為託管 Amazon Simple Workflow Service 活動和工作流程工作者的執行個體提供藍圖。 **Short name: (簡短名稱：)** aws-flow-ruby **相容性：**AWS Flow (Ruby) layer 與 PHP App Server、MySQL、Memcached、Ganglia 和自訂 layer 相容。 **Open ports: (開放連接埠：)** 無。 **IAM 角色：**aws-opsworks-ec2-role-with-swf 是 OpsWorks Stacks 應要求為您建立的標準 AWS Flow (Ruby) 角色。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS Volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-AWS-Flow-Ruby-Server **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + opsworks\$1aws\$1flow\$1ruby::setup **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + mysql::client + agent\$1version + opsworks\$1aws\$1flow\$1ruby::configure **Deploy recipes: (部署配方：)** + deploy::default + deploy::aws-flow-ruby **Undeploy recipes: (解除部署配方：)** + deploy::aws-flow-ruby-undeploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default # Java App Server Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 Java App Server layer 支援 [Apache Tomcat 7.0](http://tomcat.apache.org/) 應用程式伺服器。 **Short name: (簡短名稱：)** java-app **相容性：**Java App Server layer 與下列 layer 相容：Custom、db-master 和 memcached。 **開放連接埠：**Java App Server layer 允許公開存取連接埠 22 (SSH)、80 (HTTP)、443 (HTTPS) 和來自負載平衡器的所有連接埠。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS Volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-Java-App-Server **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + opsworks\$1java::setup **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version + opsworks\$1java::configure **Deploy recipes: (部署配方：)** + deploy::default + deploy::java **Undeploy recipes: (解除部署配方：)** + deploy::java-undeploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + deploy::java-stop **安裝:** + Tomcat 會安裝至 `/usr/share/tomcat7`。 + 如需如何產生日誌檔案的詳細資訊，請參閱 [Logging in Tomcat](http://tomcat.apache.org/tomcat-6.0-doc/logging.html)。 # Node.js 應用程式伺服器層參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 Node.js App Server layer 支援 [Node.js](http://nodejs.org/) 應用程式伺服器，這是實作高可擴展性網路應用程式伺服器的平台。程式以 JavaScript 撰寫，並使用事件驅動的非同步 I/O，將額外負荷降到最低，且將可擴展性提到最高。 **Short name: (簡短名稱：)** nodejs-app **相容性：**Node.js App Server layer 與下列層相容：自訂、db-master、memcached 和 monitoring-master。 **開放連接埠：**Node.js App Server layer 允許從負載平衡器公開存取連接埠 22 (SSH)、80 (HTTP)、443 (HTTPS) 和所有連接埠。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-nodejs-App-Server **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + opsworks\$1nodejs + opsworks\$1nodejs::npm **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version + opsworks\$1nodejs::configure **Deploy recipes: (部署配方：)** + deploy::default + opsworks\$1nodejs + opsworks\$1nodejs::npm + deploy::nodejs **Undeploy recipes: (解除部署配方：)** + deploy::nodejs-undeploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + deploy::nodejs-stop **安裝:** + Node.js 會安裝至 `/usr/local/bin/node`。 + 如需如何產生日誌檔案的詳細資訊，請參閱 Nodejitsu 網站上的 [How to log in node.js](https://docs.nodejitsu.com/articles/intermediate/how-to-log/)。 **Node.js application configuration: (Node.js 應用程式組態：)** + Node.js 所執行的主要檔案必須命名為 `server.js` 並且位在已部署應用程式的根目錄中。 + Node.js 應用程式必須設定為接聽連接埠 80，適用時，也可以接聽連接埠 443。 **注意** 執行 Express 的 Node.js 應用程式普遍使用下列程式碼來設定接聽連接埠，其中 `process.env.PORT` 代表預設連接埠並解析為 80： ``` app.set('port', process.env.PORT || 3000); ``` 使用 OpsWorks Stacks，您必須明確指定連接埠 80，如下所示： ``` app.set('port', 80); ``` # PHP App Server Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 PHP App Server layer 透過搭配 mod\$1php 使用 [Apache2](http://httpd.apache.org/) 來支援 PHP 應用程式伺服器。 **Short name: (簡短名稱：)** php-app **相容性：**PHP App Server layer 與下列 layer 相容：Custom、db-master、memcached、 monitoring-master 和 rails-app。 **開放連接埠：**PHP App Server layer 允許公開存取連接埠 22 (SSH)、80 (HTTP)、443 (HTTPS) 和來自負載平衡器的所有連接埠。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-PHP-App-Server **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + mysql::client + dependencies + mod\$1php5\$1apache2 **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version + mod\$1php5\$1apache2::php + php::configure **Deploy recipes: (部署配方：)** + deploy::default + deploy::php **Undeploy recipes: (解除部署配方：)** + deploy::php-undeploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + apache2::stop **Installation: (安裝：)** + OpsWorks Stacks 使用執行個體的套件安裝程式，將 Apache2、mod\$1php 和相關聯的日誌檔案安裝到其預設位置。如需安裝的詳細資訊，請參閱 [Apache](http://httpd.apache.org/)。如需記錄的詳細資訊，請參閱 [Log Files](http://httpd.apache.org/docs/2.2/logs.html)。 # Rails App Server Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 Rails App Server layer 支援 [Ruby on Rails](http://rubyonrails.org/) 應用程式伺服器。 **Short name: (簡短名稱：)** rails-app **相容性：**Rails App Server layer 與下列 layer 相容：Custom、db-master、memcached、 monitoring-master、php-app。 **連接埠：**Rails App Server layer 允許從負載平衡器公開存取連接埠 22 (SSH)、80 (HTTP)、443 (HTTPS) 和所有連接埠。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-Rails-App-Server **組態：**若要設定 Rails App Server layer，您必須指定下列項目： + Ruby 版本 + Rails 堆疊 + Rubygems 版本 + 是否安裝和管理 [Bundler](http://gembundler.com/) + Bundler 版本 **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + apache2 apache2::mod\$1deflate + passenger\$1apache2 + passenger\$1apache2::mod\$1rails + passenger\$1apache2::rails **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version + rails::configure **Deploy recipes: (部署配方：)** + deploy::default + deploy::rails **Undeploy recipes: (解除部署配方：)** + deploy::rails-undeploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + apache2::stop **安裝:** + OpsWorks Stacks 使用執行個體的套件安裝程式，將具有 mod\$1passenger、mod\$1rails 和相關聯日誌檔案的 Apache2 安裝至其預設位置。如需安裝的詳細資訊，請參閱 [Phusion Passenger](https://www.phusionpassenger.com/)。如需記錄的詳細資訊，請參閱 [Log Files](http://httpd.apache.org/docs/2.2/logs.html)。 # 靜態 Web 伺服器層參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。靜態 Web Server layer 提供靜態 HTML 頁面，其中可包含用戶端程式碼，例如 JavaScript。它是以 [Nginx](http://nginx.org/en/) 為基礎，這是一種開放原始碼 HTTP、反向代理和郵件代理伺服器。 **Short name: (簡短名稱：)** web **相容性：**靜態 Web 伺服器層與下列層相容：自訂、db-master、memcached。 **開放連接埠：**靜態 Web 伺服器層允許從負載平衡器公開存取連接埠 22 (SSH)、80 (HTTP)、443 (HTTPS) 和所有連接埠。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-Web-Server **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + nginx **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version **Deploy recipes: (部署配方：)** + deploy::default + deploy::web **Undeploy recipes: (解除部署配方：)** + deploy::web-undeploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + nginx::stop **安裝:** + Nginx 會安裝至 `/usr/sbin/nginx`。 + Nginx 日誌檔案位於 `/var/log/nginx`。 # 應用程式伺服器 Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些 layer 僅供 Chef 11 和更早版本的 Linux 式堆疊使用。 OpsWorks Stacks 支援數個不同的應用程式伺服器，其中「應用程式」包含靜態網頁。每種類型的伺服器都有單獨的 OpsWorks Stacks layer，其內建配方可處理在每個 layer 的執行個體上安裝應用程式伺服器和任何相關套件、部署應用程式等。例如，Java App Server layer 安裝數個套件，包括 Apache、Tomcat 和 OpenJDK，並將 Java 應用程式部署到 layer 的每個執行個體。以下是使用應用程式伺服器 layer 的基本程序： 1. [建立](workinglayers-basics-create.md)一種可用的 **App Server (應用程式伺服器)** layer 類型。 1. [新增一或多個執行個體](workinginstances-add.md)至 layer。 1. 建立應用程式並將其部署至執行個體。如需詳細資訊，請參閱[應用程式](workingapps.md)。 1. (選用) 如果 layer 有多個執行個體，您可以新增負載平衡器，以將傳入流量分配到執行個體。如需詳細資訊，請參閱[HAProxy OpsWorks Stacks Layer](layers-haproxy.md)。 **Topics** + [AWS Flow (Ruby) Layer](workinglayers-awsflow.md) + [Java 應用程式伺服器 OpsWorks 堆疊層](layers-java.md) + [Node.js 應用程式伺服器 OpsWorks 堆疊層](workinglayers-node.md) + [PHP 應用程式伺服器 OpsWorks 堆疊層](workinglayers-php.md) + [Rails 應用程式伺服器 OpsWorks 堆疊層](workinglayers-rails.md) + [靜態 Web 伺服器 OpsWorks 堆疊層](workinglayers-static.md) # AWS Flow (Ruby) Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 AWS Flow (Ruby) layer 是 OpsWorks Stacks layer，可為託管 [Amazon SWF](https://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-welcome.html) 活動和工作流程工作者的執行個體提供藍圖。工作者的實作方式是使用適用於 [Ruby 的 AWS Flow Framework](https://docs.aws.amazon.com/amazonswf/latest/awsrbflowguide/welcome.html)，這是一種程式設計架構，可簡化實作分散式非同步應用程式的程序，同時提供 Amazon SWF 的所有優點。這項功能適用於實作應用程式來解決廣泛情境，包括商務程序、媒體編碼、長時間執行的任務和背景處理。 AWS Flow (Ruby) layer 包含下列組態設定。 **RubyGems 版本** 框架的 Gem 版本。 **Bundler 版本** [Bundler](http://bundler.io/) 版本。 **EC2 Instance profile (EC2 執行個體描述檔)** layer 執行個體要使用的使用者定義 Amazon EC2 執行個體描述檔。此設定檔必須授予在 layer 執行個體上執行的應用程式存取 Amazon SWF 的許可。如果您的帳戶沒有適當的設定檔，您可以選取**具有 SWF 存取權的新設定檔**，讓 OpsWorks Stacks 更新的設定檔，或者您可以使用 [IAM 主控台](https://console.aws.amazon.com/iam/)自行更新。您接著可以使用針對所有後續 AWS Flow layer 之更新的描述檔。以下是如何使用 IAM 主控台建立設定檔的簡短描述。如需詳細資訊，請參閱 [Amazon Simple Workflow Service 中的 Identity and Access Management](https://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-dev-iam.html)。 **建立 AWS Flow (Ruby) 執行個體的設定檔** 1. 前往 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。 1. 在導覽窗格中選擇**政策**，然後選擇**建立政策**以建立新的客戶受管政策。 1. 針對**服務**，選擇 **SWF**。 1. 針對**動作**，選擇**所有 SWF 動作 (swf：\$1)**。 1. 針對 **Amazon Resource Name (ARN)**，輸入指定工作者可存取哪些 Amazon SWF 網域的 ARN。選擇**All resources**提供所有網域的存取權。 1. 選擇**下一步**。 1. 或者，輸入標籤以識別政策。 1. 選擇**下一步**。 1. 完成後，請選擇**建立政策**。 1. 在導覽窗格中選擇**角色**，然後選擇**建立角色**。 1. 指定角色名稱，然後選擇**下一步**。建立角色之後，就無法變更名稱。 1. 選擇 **AWS 服務**，然後選擇 ** EC2**。 1. 選擇**下一步**。 1. 從**許可政策**清單中，選擇您先前建立的政策。 1. 選擇**下一步**。 1. 輸入角色名稱，然後選擇 **Create role (建立角色)**。建立角色之後，就無法變更名稱。 1. 在 Stacks 中建立 AWS Flow (Ruby) OpsWorks layer 時指定此設定檔。 # Java 應用程式伺服器 OpsWorks 堆疊層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 Java App Server layer 是 OpsWorks Stacks layer，為做為 Java 應用程式伺服器的執行個體提供藍圖。此層以 [Apache Tomcat 7.0](http://tomcat.apache.org/) 和 [Open JDK 7](http://openjdk.java.net/). OpsWorks Stacks 為基礎，也會安裝 Java 連接器程式庫，讓 Java 應用程式使用 JDBC `DataSource` 物件連線到後端資料存放區。 **Installation (安裝)**：Tomcat 安裝在 `/usr/share/tomcat7` 中。 **Add Layer (新增 Layer)** 頁面提供下列組態選項： **Java VM 選項** 您可以使用此設定來指定自訂 Java VM 選項；沒有預設選項。例如，一組常見選項為 `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`。如果您使用 **Java VM 選項**，請確定您已傳遞一組有效的選項； OpsWorks Stacks 不會驗證字串。如果您嘗試傳遞無效的選項，則通常無法啟動 Tomcat 伺服器，進而導致設定失敗。如果發生此情況，您可以檢查執行個體的設定 Chef 日誌以了解詳細資訊。如需如何檢視和解釋 Chef 日誌的詳細資訊，請參閱[Chef 日誌](troubleshoot-debug-log.md)。 **自訂安全群組** 如果您選擇不自動將內建 OpsWorks Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **Elastic Load Balancer** 您可以將 Elastic Load Balancing 負載平衡器連接至 layer 的執行個體。如需詳細資訊，請參閱[Elastic Load Balancing Layer](layers-elb.md)。您可以使用自訂 JSON 或自訂屬性檔案，來指定其他組態設定。如需詳細資訊，請參閱[自訂組態](layers-java-config.md)。 **重要** 如果您的 Java 應用程式使用 SSL，則建議您盡可能停用 SSLv3 來處理 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) 中所述的漏洞。如需詳細資訊，請參閱[停用 Apache 伺服器的 SSLv3](#layers-java-sslv3)。 **Topics** + [停用 Apache 伺服器的 SSLv3](#layers-java-sslv3) + [自訂組態](layers-java-config.md) + [部署 Java 應用程式](layers-java-deploy.md) ## 停用 Apache 伺服器的 SSLv3 若要停用 SSLv3，您必須修改 Apache 伺服器之 `ssl.conf` 檔案的 `SSLProtocol` 設定。若要這麼做，您必須覆寫內建 [apache2 技術指南的](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/apache2)`ssl.conf.erb`範本檔案，Java App Server 層的設定配方會使用此檔案來建立 `ssl.conf`。詳細資訊取決於您針對 layer 執行個體所指定的作業系統。以下摘要說明 Amazon Linux 和 Ubuntu 系統所需的修改。會自動停用 Red Hat Enterprise Linux (RHEL) 系統的 SSLv3。如需如何覆寫內建範本的詳細資訊，請參閱[使用自訂範本 ](workingcookbook-template-override.md)。 **Amazon Linux** 這些作業系統的 `ssl.conf.erb` 檔案位於 `apache2` 技術指南的 `apache2/templates/default/mods` 目錄中。以下顯示內建檔案的相關部分。 ``` ... #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2 SSLProtocol all -SSLv2 ``` 覆寫 `ssl.conf.erb` 和修改 `SSLProtocol` 設定，如下所示。 ``` ... #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2 SSLProtocol all -SSLv3 -SSLv2 ``` **Ubuntu 14.04 LTS** 此作業系統的 `ssl.conf.erb` 檔案位於 `apache2` 技術指南的 `apache2/templates/ubuntu-14.04/mods` 目錄中。以下顯示內建檔案的相關部分。 ``` ... # The protocols to enable. # Available values: all, SSLv3, TLSv1.2 # SSL v2 is no longer supported SSLProtocol all ... ``` 請將此設定變更為下列內容。 ``` ... # The protocols to enable. # Available values: all, SSLv3, TLSv1.2 # SSL v2 is no longer supported SSLProtocol all -SSLv3 -SSLv2 ... ``` # 自訂組態 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 會將其他組態設定公開為內建屬性，這些屬性都位於 `opsworks_java` 命名空間中。您可以使用自訂 JSON 或自訂屬性檔案來覆寫內建屬性，並指定自訂值。例如，JVM 和 Tomcat 版本由內建 `jvm_version` 和 `java_app_server_version` 屬性所代表，而這兩者都設定為 7。您可以使用自訂 JSON 或自訂屬性檔案，將其中一個或兩者設定為 6。下列範例使用自訂 JSON 將兩個屬性都設定為 6： ``` { "opsworks_java": { "jvm_version": 6, "java_app_server_version" : 6 } } ``` 如需詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。另一個自訂組態的範例是覆寫 `use_custom_pkg_location`、`custom_pkg_location_url_debian` 和 `custom_pkg_location_url_rhel` 屬性來安裝自訂 JDK。 **注意** 如果您覆寫內建技術指南，則需要自行更新這些元件。如需屬性和其覆寫方式的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如需內建屬性的清單，請參閱[opsworks\$1java 屬性](attributes-recipes-java.md)。 # 部署 Java 應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。下列主題說明如何將應用程式部署到 Java App Server layer 的執行個體。這些範例是針對 JSP 應用程式，但您可以使用基本上相同的程序，來安裝其他類型的 Java 應用程式。您可以從任何支援的儲存庫部署 JSP 頁面。如果您想要部署 WAR 檔案，請注意 Stacks OpsWorks 會自動從 Amazon S3 或 HTTP 封存檔擷取部署的 WAR 檔案，但不會從 Git 或 Subversion 儲存庫擷取。如果您想要將 Git 或 Subversion 用於 WAR 檔案，則可以執行下列其中一項： + 將擷取的封存檔存放至儲存庫。 + 將 WAR 檔案存放至儲存庫，並使用 Chef 部署勾點來擷取封存檔，如下列範例所述。您可以使用 Chef 部署勾點，在四個部署階段中的任何一階段，於執行個體上執行使用者提供的 Ruby 應用程式。應用程式名稱可決定階段。下列範例是名為 `before_migrate.rb` 的 Ruby 應用程式，可擷取已從 Git 或 Subversion 儲存庫所部署的 WAR 檔案。該名稱會建立應用程式與 Checkout 部署勾點的關聯，以在部署操作開始時、檢查程式碼之後但在遷移之前執行。如需如何使用此範例的詳細資訊，請參閱[使用 Chef 部署勾點](workingcookbook-extend-hooks.md)。 ``` ::Dir.glob(::File.join(release_path, '*.war')) do |archive_file| execute "unzip_#{archive_file}" do command "unzip #{archive_file}" cwd release_path end end ``` **注意** 在您將更新部署至 JSP 應用程式時，Tomcat 可能會無法識別更新，而繼續執行現有的應用程式版本。舉例來說，這可能會在您將應用程式做為僅包含 JSP 頁面的 .zip 檔案部署時發生。若要確保 Tomcat 執行的是最近部署的版本，專案的根目錄應包括內含 `web.xml` 檔案的 WEB-INF 目錄。`web.xml` 檔案可包含各種內容，但以下內容便足以確保 Tomcat 識別更新及執行目前部署的應用程式版本。您不需要為每次更新變更版本。若版本沒有變更，Tomcat 將會識別更新。 ```

appVersion

0.1

``` **Topics** + [部署 JSP 應用程式](#layers-java-deploy-jsp) + [使用後端資料庫部署 JSP 應用程式](#layers-java-deploy-jsp-db) ## 部署 JSP 應用程式若要部署 JSP 應用程式，請指定名稱和儲存庫資訊。您也可以選擇指定網域和 SSL 設定。如需如何建立應用程式的詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。下列程序說明如何從公有 Amazon S3 封存建立和部署簡單的 JSP 頁面。如需如何使用其他儲存庫類型的資訊，包括私有 Amazon S3 封存，請參閱 [應用程式來源](workingapps-creating.md#workingapps-creating-source)。下列範例所顯示的 JSP 頁面只會顯示一些系統資訊。 ``` <%@ page import="java.net.InetAddress" %> <% java.util.Date date = new java.util.Date(); InetAddress inetAddress = InetAddress.getLocalHost(); %> The time is <% out.println( date ); out.println("
Your server's hostname is "+inetAddress.getHostName()); %>
``` **注意** 下列程序假設您已熟悉建立堆疊、將執行個體新增至 layer 等等的基本知識。如果您是初次使用 OpsWorks Stacks，您應該會先看到 [Chef 11 Linux 堆疊入門](gettingstarted.md)。 **從 Amazon S3 封存檔部署 JSP 頁面** 1. 使用 Java App Server layer [建立堆疊](workingstacks-creating.md)，將[全年無休執行個體新增至](workinginstances-add.md) layer，然後[啟動它](workinginstances-starting.md)。 1. 將程式碼複製至名為 `simplejsp.jsp` 的檔案，並將檔案放入名為 `simplejsp` 的資料夾中，然後建立資料夾的 `.zip` 封存檔。名稱可以是任意名稱；您可以使用您想要的任何檔案或資料夾名稱。您也可以使用其他類型的封存檔，包括 gzip、bzip2、tarball 或 Java WAR 檔案。請注意， OpsWorks Stacks 不支援未壓縮的 tarball。若要部署多個 JSP 頁面，請將它們包括在相同的封存檔中。 1. 將封存上傳到 Amazon S3 儲存貯體並將檔案設為公有。複製檔案的 URL，供日後使用。如需如何建立儲存貯體以及上傳檔案的詳細資訊，請參閱[開始使用 Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)。 1. [新增應用程式](workingapps-creating.md#workingapps-creating-general)至堆疊，然後指定下列設定： + **名稱** – `SimpleJSP` + **App type (應用程式類型)** – `Java` + **Repository type (儲存庫類型)** – `Http Archive` + **儲存庫 URL** – 封存檔案的 Amazon S3 URL。針對剩餘設定使用預設值，然後按一下 **Add App (新增應用程式)** 以建立應用程式。 1. [將應用程式部署](workingapps-deploying.md)到 Java App Server 執行個體。您現在可以前往應用程式的 URL，以及檢視應用程式。如果您尚未指定網域，則可以使用執行個體的公有 IP 地址或其公有 DNS 名稱來建構 URL。若要取得執行個體的公有 IP 地址或公有 DNS 名稱，請前往 OpsWorks Stacks 主控台，然後按一下執行個體頁面上**的執行個體**名稱以開啟其詳細資訊頁面。其餘 URL 取決於應用程式的簡短名稱，這是 OpsWorks Stacks 從您在建立應用程式時指定的應用程式名稱產生的小寫名稱。例如，SimpleJSP 的簡短名稱是 simplejsp。您可以從其詳細資訊頁面中取得應用程式的簡短名稱。 + 如果簡短名稱是 `root`，則您可以使用 `http://public_DNS/appname.jsp` 或 `http://public_IP/appname.jsp`。 + 否則，您可以使用 `http://public_DNS/app_shortname/appname.jsp` 或 `http://public_IP/app_shortname/appname.jsp`。如果您已指定應用程式的網域，則 URL 為 `http://domain/appname.jsp`。此範例的 URL 會類似 `http://192.0.2.0/simplejsp/simplejsp.jsp`。如果您想要將多個應用程式部署至相同的執行個體，則不應該使用 `root` 做為簡短名稱。這可能會導致 URL 衝突，進而防止應用程式正常運作。相反地，請將不同的網域名稱指派給每個應用程式。 ## 使用後端資料庫部署 JSP 應用程式 JSP 頁面可以使用 JDBC `DataSource` 物件以連線至後端資料庫。您可以使用上節中的程序來建立和部署這類應用程式，而且只要再一個額外的步驟就可以設定連線。下列 JSP 頁面顯示如何連線至 `DataSource` 物件。 ``` DB Access <%@ page language="java" import="java.sql.*,javax.naming.*,javax.sql.*" %> <% StringBuffer output = new StringBuffer(); DataSource ds = null; Connection con = null; Statement stmt = null; ResultSet rs = null; try { Context initCtx = new InitialContext(); ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/mydb"); con = ds.getConnection(); output.append("Databases found:
"); stmt = con.createStatement(); rs = stmt.executeQuery("show databases"); while (rs.next()) { output.append(rs.getString(1)); output.append("
"); } } catch (Exception e) { output.append("Exception: "); output.append(e.getMessage()); output.append("
"); } finally { try { if (rs != null) { rs.close(); } if (stmt != null) { stmt.close(); } if (con != null) { con.close(); } } catch (Exception e) { output.append("Exception (during close of connection): "); output.append(e.getMessage()); output.append("
"); } } %> <%= output.toString() %> ``` OpsWorks Stacks 會建立和初始化`DataSource`物件、將其繫結至邏輯名稱，並使用 Java 命名和目錄界面 (JNDI) 命名服務註冊名稱。完整的邏輯名稱為 `java:comp/env/user-assigned-name`。您必須指定名稱中由使用者指派的部分，方法是將自訂 JSON 屬性新增至堆疊組態和部署屬性來定義 `['opsworks_java']['datasources']` 屬性，如下所述。 **部署連線至 MySQL 資料庫的 JSP 頁面** 1. 使用 Java App Server layer [建立堆疊](workingstacks-creating.md)，將[全年無休的執行個體新增至](workinginstances-add.md)每個 layer，然後[啟動它](workinginstances-starting.md)。 1. 將資料庫 layer 新增至堆疊。詳細資訊取決於您使用的資料庫。若要使用 MySQL 執行個體做為範例，請將 [ MySQL layer 新增至](workinglayers-db-mysql.md)堆疊，將[全年無休的執行個體新增至](workinginstances-add.md) layer，然後[啟動它](workinginstances-starting.md#workinginstances-starting-start)。若要使用 Amazon RDS (MySQL) 執行個體做為範例： + 指定執行個體的 MySQL 資料庫引擎。 + 將 **AWS-OpsWorks-DB-Master-Server (*security\$1group\$1id*)** 和 **AWS-OpsWorks-Java-App-Server (*security\$1group\$1id*)** 安全群組指派給執行個體。當您在區域中建立第一個堆疊時， OpsWorks Stacks 會為您建立這些安全群組。 + 建立名為 `simplejspdb` 的資料庫。 + 確定主要使用者名稱和密碼未包含可能會導致 Tomcat 錯誤的 `&` 或其他字元。具體而言，在啟動期間，Tomcat 必須剖析 Web 應用程式內容檔案，而此檔案是一種 XML 檔案，其中包括主要密碼和使用者名稱。如果任一字串包括 `&` 字元，則 XML 剖析器會將它視為格式異常的 XML 實體，並拋出剖析例外狀況，以防止啟動 Tomcat。如需 Web 應用程式內容檔案的詳細資訊，請參閱[tomcat::context](create-custom-configure.md#create-custom-configure-context)。 + 將[ MySQL 驅動程式](workingapps-connectdb.md)新增至 Java App Server layer。 + 向堆疊[註冊 RDS 執行個體](workinglayers-db-rds.md#workinglayers-db-rds-register)。如需如何搭配 Stacks 使用 Amazon RDS OpsWorks 執行個體的詳細資訊，請參閱 [Amazon RDS 服務層](workinglayers-db-rds.md)。 1. 將範例程式碼複製至名為 `simplejspdb.jsp` 的檔案，並將檔案放入名為 `simplejspdb` 的資料夾中，然後建立資料夾的 `.zip` 封存檔。名稱可以是任意名稱；您可以使用您想要的任何檔案或資料夾名稱。您也可以使用其他類型的封存檔，包括 gzip、bzip2 或 tarball。若要部署多個 JSP 頁面，請將它們包括在相同的封存檔中。如需如何從其他儲存庫類型部署應用程式的資訊，請參閱[應用程式來源](workingapps-creating.md#workingapps-creating-source)。 1. 將封存上傳到 Amazon S3 儲存貯體並將檔案設為公有。複製檔案的 URL，供日後使用。如需如何建立儲存貯體以及上傳檔案的詳細資訊，請參閱[開始使用 Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)。 1. [新增應用程式](workingapps-creating.md#workingapps-creating-general)至堆疊，然後指定下列設定： + **名稱** – `SimpleJSPDB` + **App type (應用程式類型)** – `Java` + **資料來源類型** – **OpsWorks** （適用於 MySQL 執行個體）或 **RDS** （適用於 Amazon RDS 執行個體）。 + **資料庫執行個體** – 您先前建立的 MySQL 執行個體，通常名為 **db-master1(mysql)**，或名為 ***DB\$1instance\$1name* (mysql)** 的 Amazon RDS 執行個體。 + **Database name (資料庫名稱)** – `simplejspdb`。 + **Repository type (儲存庫類型)** – `Http Archive` + **儲存庫 URL** – 封存檔案的 Amazon S3 URL。針對剩餘設定使用預設值，然後按一下 **Add App (新增應用程式)** 以建立應用程式。 1. 將下列自訂 JSON 屬性新增至堆疊組態屬性，其中 simplejspdb 是應用程式的簡短名稱。 ``` { "opsworks_java": { "datasources": { "simplejspdb": "jdbc/mydb" } } } ``` OpsWorks Stacks 使用此映射來產生具有必要資料庫資訊的內容檔案。如需如何將自訂 JSON 屬性新增至堆疊組態屬性的詳細資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。 1. [將應用程式部署](workingapps-deploying.md)至 Java App Server 執行個體。您現在可以使用應用程式的 URL 來檢視應用程式。如需如何建構 URL 的描述，請參閱[部署 JSP 應用程式](#layers-java-deploy-jsp)。此範例的 URL 會類似 `http://192.0.2.0/simplejspdb/simplejspdb.jsp`。 **注意** `datasources` 屬性可以包含多個屬性。每個屬性的名稱都會有應用程式簡短名稱，並設定為邏輯名稱中由使用者指派的適當部分。如果您有多個應用程式，則可以使用不同的邏輯名稱，這需要與下面類似的自訂 JSON。 ``` { "opsworks_java": { "datasources": { "myjavaapp": "jdbc/myappdb", "simplejsp": "jdbc/myjspdb", ... } } } ``` # Node.js 應用程式伺服器 OpsWorks 堆疊層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 Node.js App Server layer 是一種 OpsWorks Stacks layer，為做為 [Node.js](http://nodejs.org/) 應用程式伺服器的執行個體提供藍圖。 OpsWorks Stacks 也會安裝 [Express](http://expressjs.com/)，因此 layer 的執行個體同時支援標準和 Express 應用程式。 **Installation (安裝)**：Node.js 安裝在 `/usr/local/bin/node` 中。 **Add Layer (新增 Layer)** 頁面提供下列組態選項： **Node.js 版本** 如需目前所支援版本的清單，請參閱[OpsWorks Stacks 作業系統](workinginstances-os.md)。 **自訂安全群組** 如果您選擇不自動將內建 OpsWorks Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **Elastic Load Balancer** 您可以將 Elastic Load Balancing 負載平衡器連接至 layer 的執行個體。 **重要** 如果您的 Node.js 應用程式使用 SSL，則建議您盡可能停用 SSLv3 來處理 [CVE-2015-8027](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8027) 中所述的漏洞。若要這麼做，您必須將 **Node.js version (Node.js 版本)** 設定為 `0.12.9`。 ## 部署 Node.js 應用程式如需如何實作 OpsWorks Stacks 簡單 Node.js 應用程式並將其部署至堆疊的詳細演練，請參閱[建立您的第一個 Node.js 堆疊](gettingstarted-node.md)。一般而言， OpsWorks Stacks 的 Node.js 應用程式應該會符合下列條件： + 主要檔案必須命名為 `server.js` 並且位在已部署應用程式的根目錄中。 + [Express](http://expressjs.com/) 應用程式必須在應用程式的根目錄中包括 `package.json` 檔案。 + 根據預設，應用程式必須接聽連接埠 80 (HTTP) 或連接埠 443 (HTTPS)。您可以監聽其他連接埠，但 Node.js App Server 層的內建安全群組 **AWS-OpsWorks-nodejs-App-Server** 僅允許傳入使用者流量至連接埠 80、443 和 22 (SSH)。若要允許傳入使用者流量到其他連接埠，請使用適當的傳入規則[建立安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)[，並將其指派給 Node.js App Server layer](workinglayers-basics-edit.md#workinglayers-basics-edit-security)。請勿透過編輯內建安全群組來修改傳入規則。每次建立堆疊時， OpsWorks Stacks 都會以標準設定覆寫內建的安全群組，因此您所做的任何變更都會遺失。 **注意** OpsWorks Stacks 會將 PORT 環境變數設定為 80 （預設）或 443 （如果您啟用 SSL)，因此您可以使用下列程式碼來接聽請求。 ``` app.listen(process.env.PORT); ``` 如果您將 [Node.js 應用程式設定為支援 SSL](workingapps-creating.md#workingapps-creating-domain-ssl)，則必須指定金鑰和憑證。 OpsWorks Stacks 會將每個應用程式伺服器執行個體的資料做為個別檔案放入 `/srv/www/app_shortname/shared/config`目錄中，如下所示。 + `ssl.crt` – SSL 憑證。 + `ssl.key` – SSL 金鑰。 + `ssl.ca` – 鏈結憑證，如果您已指定。您的應用程式可以從這些檔案中取得 SSL 金鑰和憑證。 # PHP 應用程式伺服器 OpsWorks 堆疊層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 PHP App Server layer 是 OpsWorks Stacks layer，可為做為 PHP 應用程式伺服器的執行個體提供藍圖。PHP App Server layer 是以 [Apache2](http://httpd.apache.org/) 為基礎，`mod_php`且沒有標準組態選項。PHP 和 Apache 版本取決於您針對 layer 執行個體所指定的[作業系統](workinginstances-os.md)。 | 作業系統 | PHP 版本 | Apache 版本 | | --- | --- | --- | | Amazon Linux 2018.03 | 5.3 | 2.2 | | Amazon Linux 2017.09 | 5.3 | 2.2 | | Amazon Linux 2017.03 | 5.3 | 2.2 | | Amazon Linux 2016.09 | 5.3 | 2.2 | | Amazon Linux 2016.03 | 5.3 | 2.2 | | Amazon Linux 2015.09 | 5.3 | 2.2 | | Amazon Linux 2015.03 | 5.3 | 2.2 | | Amazon Linux 2014.09 | 5.3 | 2.2 | | Ubuntu 14.04 LTS | 5.5 | 2.4 | **Installation**： OpsWorks Stacks 使用執行個體的套件安裝程式，在其`mod_php`預設位置安裝 Apache2 和。如需安裝的詳細資訊，請參閱 [Apache](http://httpd.apache.org/)。 **Add Layer (新增 Layer)** 頁面提供下列組態選項： **自訂安全群組** 如果您選擇不自動將內建 OpsWorks Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **Elastic Load Balancer** 您可以將 Elastic Load Balancing 負載平衡器連接至 layer 的執行個體。您可以使用自訂 JSON 或自訂屬性檔案，來修改一些 Apache 組態設定。如需詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如需可覆寫的 Apache 屬性清單，請參閱[apache2 屬性](attributes-recipes-apache.md)。如需如何部署 PHP 應用程式的範例 (包括如何將應用程式連線至後端資料庫)，請參閱[Chef 11 Linux 堆疊入門](gettingstarted.md)。 **重要** 如果您的 PHP 應用程式使用 SSL，則建議您盡可能停用 SSLv3 來處理 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) 中所述的漏洞。若要執行此作業，您必須修改 Apache 伺服器 `ssl.conf` 檔案中的 `SSLProtocol` 設定。如需如何修改此設定的詳細資訊，請參閱[停用 Apache 伺服器的 SSLv3](layers-java.md#layers-java-sslv3)。 # Rails 應用程式伺服器 OpsWorks 堆疊層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 Rails App Server layer 是 OpsWorks Stacks layer，可為充當 Rails 應用程式伺服器的執行個體提供藍圖。 **Installation**： OpsWorks Stacks 使用執行個體的套件安裝程式，在其預設位置安裝伺服器套件。如需 Apache/Passenger 安裝的詳細資訊，請參閱 [Phusion Passenger](https://www.phusionpassenger.com/)。如需記錄的詳細資訊，請參閱 [Log Files](http://httpd.apache.org/docs/2.2/logs.html)。如需 Nginx/Unicorn 安裝的詳細資訊，請參閱 [Unicorn](http://unicorn.bogomips.org/)。 **Add Layer (新增 Layer)** 頁面提供下列組態選項，而且全部都是選用的。 **Ruby 版本** 將由您的應用程式使用的 Ruby 版本。預設值為 2.3. 您也可以[覆寫 `[:opsworks][:ruby_version]`](workingcookbook-attributes.md) 屬性，來指定慣用的 Ruby 版本。 OpsWorks Stacks 會安裝個別的 Ruby 套件，以供配方和執行個體代理程式使用。如需詳細資訊，請參閱[Ruby 版本](workingcookbook-ruby.md)。 **Rails 堆疊** 預設 Rails 堆疊是具有 [Phusion Passenger](https://www.phusionpassenger.com/) 的 [Apache2](http://httpd.apache.org/)。您也可以搭配使用 [Nginx](http://nginx.org/en/) 與 [Unicorn](http://unicorn.bogomips.org/)。如果您使用 Nginx 和 Unicorn，則必須將 Unicorn Gem 新增至應用程式的 Gemfile，如下列範例所示： ``` source 'https://rubygems.org' gem 'rails', '3.2.15' ... # Use unicorn as the app server gem 'unicorn' ... ``` **Passenger 版本** 如果您指定 Apache2/Passenger，則必須指定 Passenger 版本。預設值為 5.0.28。 **Rubygems 版本** 預設 [Rubygems](http://rubygems.org/) 版本是 2.5.1。 **安裝和管理 Bundler** 可讓您選擇是否安裝和管理 [Bundler](http://gembundler.com/)。預設值為 **Yes (是)**。 **Bundler 版本** 預設 Bundler 版本是 1.12.5。 **自訂安全群組** 如果您選擇不自動將內建 OpsWorks Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **Elastic Load Balancer** 您可以將 Elastic Load Balancing 負載平衡器連接至 layer 的執行個體。您可以使用自訂 JSON 或自訂屬性檔案，來修改一些組態設定。如需詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如需可覆寫的 Apache、Nginx、Phusion Passenger 和 Unicorn 屬性清單，請參閱[內建技術指南屬性](attributes-recipes.md)。 **重要** 如果您的 Ruby on Rails 應用程式使用 SSL，則建議您盡可能停用 SSLv3 來處理 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) 中所述的漏洞。如需詳細資訊，請參閱[停用 Rails 伺服器的 SSLv3](#workinglayers-rails-sslv3)。 **Topics** + [停用 Rails 伺服器的 SSLv3](#workinglayers-rails-sslv3) + [連線至資料庫](#workinglayers-rails-db) + [部署 Ruby on Rails 應用程式](#workinglayers-rails-deploy) ## 停用 Rails 伺服器的 SSLv3 若要停用 Rails 伺服器的 SSLv3，請將 layer 的 **Ruby Version (Ruby 版本)** 設定更新為 2.1 或更高版本，這會安裝 Ruby 2.1.4 或更高版本做為應用程式所使用的版本。 + 將層級的 **Ruby Version (Ruby 版本)** 設定更新為 2.1 或更高版本。 + 更新 Rails 堆疊的組態檔案，如下所示。 **具有 Phusion Passenger 的 Apache** 更新 Apache 伺服器 `SSLProtocol` 檔案中的 `ssl.conf` 設定，如[停用 Apache 伺服器的 SSLv3](layers-java.md#layers-java-sslv3) 中所述。 **具有 Unicorn 的 Nginx** 將明確的 `ssl_protocols` 指示詞新增至 Nginx 伺服器的 `nginx.conf` 檔案。若要停用 SSLv3，請覆寫 Rails App Server layer 用於建立 [的內建 nginx 技術指南](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/nginx)`nginx.conf.erb`範本檔案`nginx.conf`，並新增下列指令： ``` ssl_protocols TLSv1.2; ``` 如需如何設定 `nginx.conf` 的詳細資訊，請參閱[設定 HTTPS 伺服器](http://nginx.org/en/docs/http/configuring_https_servers.html)。如需如何覆寫內建範本的詳細資訊，請參閱[使用自訂範本 ](workingcookbook-template-override.md)。 ## 連線至資料庫當您部署應用程式時， OpsWorks Stacks 會使用應用程式[`deploy`屬性](workingcookbook-json.md#workingcookbook-json-deploy)中的資訊建立新的`database.yml`檔案。如果您[將 MySQL 或 Amazon RDS 執行個體](workingapps-creating.md#workingapps-creating-data)連接至應用程式， OpsWorks Stacks 會將連線資訊新增至`deploy`屬性，讓 `database.yml`自動包含正確的連線資料。如果應用程式沒有連接的資料庫，根據預設， OpsWorks Stacks 不會將任何連線資訊新增至`deploy`屬性，也不會建立 `database.yml`。如果您想要使用不同的資料庫，則可以使用自訂 JSON 將資料庫屬性與連線資訊新增至應用程式的 `deploy` 屬性。屬性都在下`["deploy"]["appshortname"]["database"]`，其中 *appshortname* 是應用程式的簡短名稱， OpsWorks Stacks 會從應用程式名稱產生。您在自訂 JSON 中指定的值會覆寫任何預設設定。如需詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。 OpsWorks Stacks 會將下列[`[:...][:database]`](attributes-json-deploy.md#attributes-json-deploy-app-db)屬性值納入 `database.yml`。必要屬性取決於特定資料庫，但您必須具有`host`屬性，否則 OpsWorks Stacks 不會建立 `database.yml`。 + `[:adapter] (String)` – 資料庫轉接器，例如 `mysql`。 + `[:database]` （字串） – 資料庫名稱。 + `[:encoding]` （字串） – 編碼，通常設定為 `utf8`。 + `[:host]` （字串） – 主機 URL，例如 `railsexample.cdlqlk5uwd0k.us-west-2.rds.amazonaws.com`。 + `[:reconnect]` （布林值） – 如果連線不再存在，應用程式是否應重新連線。 + `[:password]` （字串） – 資料庫密碼。 + `[:port]` (數字). – 資料庫的連接埠號碼。使用此屬性可覆寫預設連接埠號碼，這是由轉接器所設定。 + `[:username]` （字串） – 資料庫使用者名稱。下列範例顯示簡短名稱為 *myapp* 之應用程式的自訂 JSON。 ``` { "deploy" : { "myapp" : { "database" : { "adapter" : "adapter", "database" : "databasename", "host" : "host", "password" : "password", "port" : portnumber "reconnect" : true/false, "username" : "username" } } } } ``` 如需如何指定自訂 JSON 的資訊，請參閱[使用自訂 JSON](workingstacks-json.md)。若要查看用來建立 `database.yml` (`database.yml.erb`) 的範本，請前往[內建技術指南儲存庫](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/rails/templates/default)。 ## 部署 Ruby on Rails 應用程式您可以從任何支援的儲存庫部署 Ruby on Rails 應用程式。以下顯示如何將範例 Ruby on Rails 應用程式部署至執行 Apache/Passenger Rails 堆疊的伺服器。範例程式碼會存放在公有 GitHub 儲存庫中，但其他受支援儲存庫的基本程序都相同。如需如何建立和部署應用程式的詳細資訊，請參閱[應用程式](workingapps.md)。若要檢視包含大量註解的範例程式碼，請前往 [https://github.com/awslabs/opsworks-demo-rails-photo-share-app](https://github.com/awslabs/opsworks-demo-rails-photo-share-app)。 **從 GitHub 儲存庫部署 Ruby on Rails 應用程式** 1. [建立](workingstacks-creating.md)具有 Rails App Server layer 的堆疊，並將 Apache/Passenger 作為 Rails 堆疊，[新增全年無休的執行個體](workinginstances-add.md)到 layer，然後[啟動它](workinginstances-starting.md)。 1. 執行個體在線上之後，請[新增應用程式](workingapps-creating.md#workingapps-creating-general)至堆疊，並指定下列設定： + **Name (名稱)** – 您偏好的任何名稱；範例會使用 `PhotoPoll`。 OpsWorks Stacks 將此名稱用於顯示目的，並產生簡短名稱以供內部使用，並在[堆疊組態和部署屬性](workingcookbook-json.md)中識別應用程式。例如，PhotoPoll 的簡短名稱是 photopoll。 + **App type (應用程式類型)** – **Ruby on Rails**。 + ** Rails environment (Rails 環境)** – 可用的環境是由應用程式所決定。範例應用程式有三種：**development**、**test** 及 **production**。針對此範例，請將環境設定為 **development**。如需每個環境的描述，請參閱範例程式碼。 + **儲存庫類型** – 任何支援的儲存庫類型。在此範例中，指定 `Git`。 + **Repository URL (儲存庫 URL)** – 應該從中部署程式碼的儲存庫。針對此範例，請將 URL 設為 **git://github.com/awslabs/opsworks-demo-rails-photo-share-app**。針對剩餘設定使用預設值，然後按一下 **Add App (新增應用程式)** 以建立應用程式。 1. [將應用程式部署](workingapps-deploying.md)至 Rails App Server 執行個體。 1. 部署完成後，請前往**執行個體**頁面，然後按一下 Rails App Server 執行個體的公有 IP 地址。請查看下列事項： ![\[Congratulatory message for deploying first app with AWS OpsWorks, with stylized logo.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/rails_example.png) # 靜態 Web 伺服器 OpsWorks 堆疊層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。靜態 Web Server layer 是 OpsWorks Stacks layer，為執行個體提供範本來提供靜態 HTML 頁面，其中包含用戶端指令碼。此 layer 是以 [Nginx](http://nginx.org/en/) 為基礎。 **Installation (安裝)**：Nginx 安裝在 `/usr/sbin/nginx` 中。 **Add Layer (新增 Layer)** 頁面提供下列組態選項： **自訂安全群組** 如果您選擇不自動將內建 OpsWorks Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **Elastic Load Balancer** 您可以將 Elastic Load Balancing 負載平衡器連接至 layer 的執行個體。您可以使用自訂 JSON 或自訂屬性檔案，來修改一些 Nginx 組態設定。如需詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如需可覆寫的 Apache 屬性清單，請參閱[nginx 屬性](attributes-recipes-nginx.md)。 **重要** 如果您的 Web 應用程式使用 SSL，則建議您盡可能停用 SSLv3 來處理 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) 中所述的漏洞。若要停用 SSLv3，您必須修改 Nginx 伺服器的 `nginx.conf` 檔案。若要這麼做，請覆寫 Rails App Server layer 的安裝配方用來建立 [的內建 nginx 技術指南](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/nginx)`nginx.conf.erb`範本檔案`nginx.conf`，並新增下列指令： ``` ssl_protocols TLSv1.2; ``` 如需如何設定 `nginx.conf` 的詳細資訊，請參閱[設定 HTTPS 伺服器](http://nginx.org/en/docs/http/configuring_https_servers.html)。如需如何覆寫內建範本的詳細資訊，請參閱[使用自訂範本 ](workingcookbook-template-override.md)。 ## ECS 叢集層參考 **注意** 此 layer 僅適用於 Linux 類型堆疊。 ECS 叢集層代表 [Amazon Elastic Container Service (Amazon ECS) 叢集](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)，並簡化叢集管理。 **Short name: (簡短名稱：)** ecs-cluster **相容性：**[Amazon ECS 服務](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)層僅與自訂層相容 **開放連接埠：**ECS 叢集允許公開存取連接埠 22 (SSH) **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-ECS-Cluster **組態：**若要設定 ECS 叢集層，您必須指定下列項目： + 是否將公有 IP 地址或彈性 IP 地址指派給容器執行個體 + 容器執行個體的執行個體描述檔 **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + opsworks\$1ecs::setup **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + mysql::client + agent\$1version + opsworks\$1ecs::configure **Deploy recipes: (部署配方：)** + deploy::default + opsworks\$1ecs::deploy **Undeploy recipes: (解除部署配方：)** + opsworks\$1ecs::undeploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + opsworks\$1ecs::shutdown **安裝:** + OpsWorks Stacks 使用執行個體的套件安裝程式，將 Docker 安裝到其預設位置 + 設定事件的 Chef 日誌會記下 Amazon ECS 代理程式是否已成功安裝。否則，Stacks OpsWorks 提供的日誌不包含 Amazon ECS 錯誤日誌資訊。如需如何處理 handleAmazon ECS 錯誤的詳細資訊，請參閱 [Amazon ECS 故障診斷](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)。 # Custom Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果標準 layer 不符合您的需求，您可以建立自訂 layer。一個堆疊可以有多個自訂 layer。自訂 layer 預設會執行可支援基本功能的一組有限標準配方。您接著可以實作該 layer 的主要功能，方法是針對每個適當的生命週期事件實作一組自訂 Chef 配方，以設定該 layer 的軟體，以此類推。自訂配方會在每個事件的標準 OpsWorks Stacks 配方之後執行。 **Short name: (簡短名稱：)** 由使用者定義；堆疊中的每個自訂 layer 都必須有不同的簡短名稱 **Open ports: (開放連接埠：)** 自訂伺服器 layer 預設會開啟下列連接埠的公有存取：連接埠 22 (SSH)、80 (HTTP)、443 (HTTPS)，以及堆疊之 Rails 和 PHP 應用程式伺服器 layer 的所有連接埠 **Autoassign Elastic IP Addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default Security Group: (預設安全群組：)** AWS-OpsWorks-Custom-Server **Compatibility: (相容性：)** Custom layer 與下列各 layer 相容：custom、db-master、lb、memcached、monitoring-master、nodejs-app、php-app、rails-app 和 web **Configuration: (組態：)** 若要設定自訂 layer，您必須指定下列項目： + layer 的名稱 + layer 的簡短名稱，可識別 Chef 配方中的 layer，而且只能使用 a-z 和數字針對 Linux 堆疊，自訂 layer 使用下列配方。 **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version **Deploy recipes: (部署配方：)** + deploy::default **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default # 其他 Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 OpsWorks Stacks 也支援下列層。 **Topics** + [Ganglia Layer 參考](layers-other-ganglia.md) + [Memcached Layer 參考](layers-other-memcached.md) # Ganglia Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 Ganglia layer 支援 [Ganglia](http://ganglia.sourceforge.net/)，這是管理執行個體指標儲存和視覺化的分散式監控系統。它的設計是要使用階層執行個體拓撲，這特別適用於執行個體群組。Ganglia 有兩個基本元件： + 低額外負荷用戶端，安裝於堆疊中的每個執行個體上，並將指標傳送到主要。 + 主伺服器，從用戶端收集指標並將其存放在 Amazon EBS 磁碟區。它也會在網頁上顯示指標。 OpsWorks Stacks 在其管理的每個執行個體上都有 Ganglia 監控代理程式。當您將 Ganglia 層新增至堆疊並啟動它時，每個執行個體上的 Ganglia 代理程式都會向 Ganglia 執行個體報告指標。若要使用 Ganglia，請將具有一個執行個體的 Ganglia 層新增至堆疊。您存取資料的方式是在主要的 IP 地址登入 Ganglia 後端。您可以撰寫 Chef 配方來提供額外的指標定義。 **Short name: (簡短名稱：)** monitoring-master **相容性：**Ganglia 層與下列層相容：Custom、db-master、memcached、php-app、rails-app。 **Open ports: (開放連接埠：)** 負載平衡器允許連接埠 22 (SSH)、80 (HTTP) 和 443 (HTTPS) 的公有存取。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 是，位於 `/vol/ganglia` **Default security group: (預設安全群組：)** AWS-OpsWorks-Monitoring-Master-Server **組態：**若要設定 Ganglia 層，您必須指定下列項目： + 提供監控圖表存取權的 URI。預設值為 http：//*DNSName*/ganglia，其中 *DNSName* 是 Ganglia 執行個體的 DNS 名稱。 + 可控制監控統計資料存取權的使用者名稱和密碼。 **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + opsworks\$1ganglia::server **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version + opsworks\$1ganglia::configure-server **Deploy recipes: (部署配方：)** + deploy::default + opsworks\$1ganglia::configure-server + opsworks\$1ganglia::deploy **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + apache2::stop **安裝:** + Ganglia 用戶端安裝在 `/etc/ganglia` 下方。 + Ganglia Web 前端安裝在 `/usr/share/ganglia-webfrontend` 下方。 + Ganglia logtailer 安裝在 `/usr/share/ganglia-logtailer` 下方。 # Memcached Layer 參考 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Linux 類型堆疊。 [Memcached](http://memcached.org/) 是任意資料的分散式記憶體快取系統。其加速網站的方式是將字串和物件快取為 RAM 中的鍵和值，以降低必須讀取外部資料來源的次數。若要在堆疊中使用 Memcached，請建立 Memcached layer 並新增一或多個執行個體，其做為 Memcached 伺服器運作。執行個體會自動安裝 Memcached，而堆疊的其他執行個體可以存取和使用 Memcached 伺服器。如果您使用 Rails App Server layer， OpsWorks Stacks 會自動將`memcached.yml`組態檔案放置在 layer 中每個執行個體的組態目錄中。您可以從此檔案取得 Memcached 伺服器和連接埠號碼。 **Short name: (簡短名稱：)** memcached **相容性：**Memcached layer 與下列 layer 相容：Custom、db-master、lb、 monitoring-master、 nodejs-app、php-app、rails-app 和 web。 **開放連接埠：**Memcached layer 允許從堆疊的 Web 伺服器、自訂伺服器和 Rails、PHP 和 Node.js 應用程式伺服器公開存取連接埠 22 (SSH) 和所有連接埠。 **Autoassign Elastic IP addresses: (自動指派彈性 IP 地址：)** 預設為關閉 **Default EBS volume: (預設 EBS 磁碟區：)** 否 **Default security group: (預設安全群組：)** AWS-OpsWorks-Memcached-Server 若要設定 Memcached layer，您必須以 MB 為單位指定快取大小。 **Setup recipes: (安裝配方：)** + opsworks\$1initial\$1setup + ssh\$1host\$1keys + ssh\$1users + mysql::client + dependencies + ebs + opsworks\$1ganglia::client + memcached **Configure recipes: (設定配方：)** + opsworks\$1ganglia::configure-client + ssh\$1users + agent\$1version **Deploy recipes: (部署配方：)** + deploy::default **Shutdown recipes: (關機配方：)** + opsworks\$1shutdown::default + memcached::stop **安裝:** + OpsWorks Stacks 會使用執行個體的套件安裝程式，在其預設位置安裝 Memcached 及其日誌檔案。 # 其他 Layer **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些 layer 僅供 Chef 11 和更早版本的 Linux 式堆疊使用。 OpsWorks Stacks 也支援 Ganglia 和 Memcached 層。 **Topics** + [Ganglia 層](workinglayers-ganglia.md) + [Memcached](workinglayers-mem.md) # Ganglia 層 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Chef 11 或更舊的 Linux 類型堆疊。 OpsWorks Stacks 會將所有執行個體和磁碟區指標傳送至 [Amazon CloudWatch](https://aws.amazon.com/documentation/cloudwatch/)，讓您輕鬆檢視圖形和設定警示，以協助您疑難排解，並根據資源的狀態採取自動化動作。您也可以使用 Ganglia OpsWorks Stacks layer 進行其他應用程式監控選項，例如存放您選擇的指標。 Ganglia layer 是執行個體的藍圖，可透過使用 [Ganglia](http://ganglia.sourceforge.net/) 分散式監控來監控您的堆疊。堆疊通常只有一個 Ganglia 執行個體。Ganglia layer 包含下列選用組態設定： **Ganglia URL** 統計的 URL 路徑。完整的 URL 為 http://*DNSName**URLPath*，其中 *DNSName* 是關聯執行個體的 DNS 名稱。預設 *URLPath* 值為 "/ganglia"，對應於類似：http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/ganglia。 **Ganglia user name (Ganglia 使用者名稱)** 統計網頁的使用者名稱。當您檢視頁面時，必須提供使用者名稱。預設值為「opsworks」。 **Ganglia password (Ganglia 密碼)** 控制統計網頁存取的密碼。當您檢視頁面時，您必須提供密碼。預設值為隨機產生的字串。記錄密碼以供日後使用； OpsWorks Stacks 不允許您在建立 layer 之後檢視密碼。不過您可以透過前往 layer 的編輯頁面，然後按一下 **Update password (更新密碼)**，來更新密碼。 **自訂安全群組** 如果您選擇不自動將內建 OpsWorks Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 **Elastic Load Balancer** 您可以將 Elastic Load Balancing 負載平衡器連接至 layer 的執行個體。 **重要** 如果您的堆疊包含 Ganglia 層，我們建議您盡可能停用 SSLv3，以解決 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) 中所述的漏洞。若要執行此作業，您必須覆寫 Apache 伺服器的 `ssl.conf.erb` 範本來修改 `SSLProtocol` 設定。如需詳細資訊，請參閱[停用 Apache 伺服器的 SSLv3](layers-java.md#layers-java-sslv3)。 ## 檢視 Ganglia 統計資料 OpsWorks Stacks 配方會在每個執行個體上安裝低額外負荷 Ganglia 用戶端。如果您的堆疊包含 Ganglia 層，Ganglia 用戶端會在執行個體上線後立即自動開始向 Ganglia 報告。Ganglia 使用用戶端資料來計算各種統計資料，並以圖形方式在其統計資料網頁上顯示結果。 **檢視 Ganglia 統計** 1. 在**圖層**頁面上，按一下 Ganglia 開啟圖層的詳細資訊頁面。 1. 在導覽窗格中，按一下 **Instances (執行個體)**。在 **Ganglia** 下，按一下執行個體名稱。 1. 複製執行個體的 **Public DNS (公有 DNS)** 名稱。 1. 使用 DNS 名稱來建構統計資料 URL，看起來像：https：//http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/ganglia。 1. 將完整的 URL 在您的瀏覽器中貼上，導覽至頁面，然後輸入 Ganglia 使用者名稱和密碼以顯示頁面。範例如下。 ![\[ShortStack 叢集 Report dashboard showing system metrics and load graph for the past hour.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/ganglia_stats.png) # Memcached **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此 layer 僅適用於 Chef 11 或更早版本的 Linux 式堆疊。 Memcached layer 是 OpsWorks Stacks layer，可為做為 [Memcached](http://memcached.org/) 伺服器運作的執行個體提供藍圖，這是用於任意資料的分散式記憶體快取系統。Memcached layer 包含下列組態設定。 **Allocated memory (MB) (配置記憶體 (MB))** (選擇性) 每個 layer 執行個體的快取記憶體數量 (單位為 MB)。預設為 512 MB。 **自訂安全群組** 如果您選擇不自動將內建 OpsWorks Stacks 安全群組與 layer 建立關聯，則會顯示此設定。您必須指定要和 layer 關聯的安全群組有哪些。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。 # 技術指南元件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。技術指南通常包含下列基本元件： + **屬性**檔案包含一組屬性值，以代表配方和範本所使用的值。 + **範本**檔案；為配方用來建立其他檔案 (例如組態檔案) 的範本。範本檔案通常可讓您透過覆寫屬性來修改組態檔案，這些屬性可以在不接觸技術指南的情況下完成，而不是重寫組態檔案。標準實務是每當您要變更執行個體上的組態檔案 (即使只要稍微修改) 時，都應該使用範本檔案。 + **配方**檔案是 Ruby 應用程式，其定義設定系統 (包括建立和設定資料夾、安裝和設定套件、啟動服務等) 所需的一切項目。技術指南不一定要包含這三個元件。若要更輕鬆地進行自訂，只需使用屬性或範本檔案。此外，技術指南也可以選擇性加入其他檔案類型，例如定義或規格。本節說明這三個標準技術指南元件。如需詳細資訊 (尤其是配方的實作方法資訊)，請參閱 [Opscode](http://www.opscode.com/chef/)。 **Topics** + [屬性](workingcookbook-installingcustom-components-attributes.md) + [範本](workingcookbook-installingcustom-components-templates.md) + [配方](workingcookbook-installingcustom-components-recipes.md) # 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。配方和範本視各種不同的值 (例如組態設定) 而定。您可以建立屬性檔案並以其中的屬性來代表每個值，而不必將這些值硬式編碼在配方或範本中。然後，您可以使用配方或範本中的屬性，而非明確的值。使用屬性的優點是您可以覆寫它們的值，而無需動用到技術指南。因此，您應該一律使用屬性來定義下列類型的值： + 可能因不同堆疊或時間而異的值，例如使用者名稱。如果您硬式編碼這些值，那麼在您每次變更值時都必須變更配方或範本。使用屬性來定義這些值時，您可以為每個堆疊使用相同的技術指南，而只要覆寫適當的屬性即可。 + 機密值，例如密碼或秘密金鑰。若您在技術指南中放入明確的機密值，可能會提高曝光的風險。相反的，請使用虛設值定義屬性，再將其覆寫以設定實際的值。覆寫這類屬性的最佳方式是使用自訂 JSON。如需詳細資訊，請參閱[使用自訂 JSON](workingcookbook-json-override.md)。如需屬性和其覆寫方式的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。下列是範例屬性檔案的部分範例。 ``` ... default["apache"]["listen_ports"] = [ '80','443' ] default["apache"]["contact"] = 'ops@example.com' default["apache"]["timeout"] = 120 default["apache"]["keepalive"] = 'Off' default["apache"]["keepaliverequests"] = 100 default["apache"]["keepalivetimeout"] = 3 default["apache"]["prefork"]["startservers"] = 16 default["apache"]["prefork"]["minspareservers"] = 16 default["apache"]["prefork"]["maxspareservers"] = 32 default["apache"]["prefork"]["serverlimit"] = 400 default["apache"]["prefork"]["maxclients"] = 400 default["apache"]["prefork"]["maxrequestsperchild"] = 10000 ... ``` OpsWorks Stacks 使用以下語法定義屬性： ``` node.type["attribute"]["subattribute"]["..."]=value ``` 您也可以使用冒號 (:)，如下所示： ``` node.type[:attribute][:subattribute][:...]=value ``` 屬性定義具有下列元件： ## `node.` `node.` 字首是選用的，且通常會將其省略，如範例所示。 ## `type` 類型會管理是否可以覆寫屬性。 OpsWorks Stacks 屬性通常會使用下列其中一種類型： + `default` 是最常用的類型，因為它允許屬性覆寫。 + `normal` 會定義屬性，覆寫其中一個標準 OpsWorks Stacks 屬性值。 **注意** Chef 支援其他類型，這些類型對 OpsWorks Stacks 來說並非必要，但可能對您的專案有用。如需詳細資訊，請參閱[關於屬性](http://docs.chef.io/attributes.html)。 ## `attribute name` 屬性名稱會使用標準的 Chef 節點語法 `[:attribute][:subattribute][...]`。您可以隨喜好使用任何屬性名稱。不過，如[覆寫屬性](workingcookbook-attributes.md)中所述，自訂的技術指南屬性會與來自堆疊組態、部署屬性和 Chef [Ohai 工具](https://docs.chef.io/ohai.html)的屬性，一起合併到執行個體的節點物件中。常用的組態名稱 (如 *port* 或 *user*) 可能會出現在各種技術指南中。為了避免名稱衝突，慣例是建立含有至少兩個元素的完整屬性名稱，如範例所示。第一個元素應該是唯一的，且通常以產品名稱 (如 *Apache*) 為依據。後面接著一或多個子屬性以識別特定的值，例如 `[:user]` 或 `[:port]`。您可以依據專案使用任何適當數量的子屬性。 ## `value` 您可以為下列類型的值設定屬性： + 字串，例如 `default[:apache][:keepalive] = 'Off'`。 + 數字 (不含引號)，例如 `default[:apache][:timeout] = 120`。 + 布林值，其可為 `true` 或 `false` (無引號)。 + 值清單，例如 `default[:apache][:listen_ports] = [ '80','443' ]`。屬性檔案是一種 Ruby 應用程式，因此您也可以使用節點語法和邏輯運算子，根據其他屬性來指派值。如需如何定義屬性的詳細資訊，請參閱[關於屬性](https://docs.chef.io/chef_overview_attributes.html)。如需運作屬性檔案的範例，請參閱 OpsWorks Stacks 內建技術指南，網址為 https：//[https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks)。 # 範本 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以建立組態檔案並將其放在適當的目錄中，以設定許多套件。您可以在技術指南中加入組態檔案，並將其複製到適當的目錄中，但更靈活的方法是使用配方以透過範本建立組態檔。範本的其中一個優點是，您可以使用屬性來定義範本的值。如此一來，您就可以使用自訂 JSON 覆寫適當的屬性值以修改組態檔案，而無需動用到技術指南。基本上，範本的內容和結構與其相關聯的檔案相同。下列 `httpd.conf` 即為範例檔。 ``` ServerRoot "<%= node[:apache][:dir] %>" <% if node[:platform] == "debian" || node[:platform] == "ubuntu" -%> LockFile /var/lock/apache2/accept.lock <% else -%> LockFile logs/accept.lock <% end -%> PidFile <%= node[:apache][:pid_file] %> Timeout <%= node[:apache][:timeout] %> KeepAlive <%= node[:apache][:keepalive] %> MaxKeepAliveRequests <%= node[:apache][:keepaliverequests] %> KeepAliveTimeout <%= node[:apache][:keepalivetimeout] %> StartServers <%= node[:apache][:prefork][:startservers] %> MinSpareServers <%= node[:apache][:prefork][:minspareservers] %> MaxSpareServers <%= node[:apache][:prefork][:maxspareservers] %> ServerLimit <%= node[:apache][:prefork][:serverlimit] %> MaxClients <%= node[:apache][:prefork][:maxclients] %> MaxRequestsPerChild <%= node[:apache][:prefork][:maxrequestsperchild] %> ... ``` 下列範例是針對 Ubuntu 執行個體產生的 `httpd.conf` 檔案： ``` ServerRoot "/etc/httpd" LockFile logs/accept.lock PidFile /var/run/httpd/httpd.pid Timeout 120 KeepAlive Off MaxKeepAliveRequests 100 KeepAliveTimeout 3 StartServers 16 MinSpareServers 16 MaxSpareServers 32 ServerLimit 400 MaxClients 400 MaxRequestsPerChild 10000 ... ``` 範本的許多文字都是從範本複製到 `httpd.conf` 檔案。不過，`<%= ... %>` 內容的處理方式則如下所示： + Chef 會將 `<%= node[:attribute][:sub_attribute][:...]%>` 取代為屬性值。例如，`StartServers <%= node[:apache][:prefork][:startservers] %>` 會變成 `httpd.conf` 中的 `StartServers 16`。 + 您可以使用 `<%if-%>, <%else-%>, and <%end-%>` 依條件選取值。此範例會根據平台設定不同的 `accept.lock` 檔案路徑。 **注意** 您並不一定僅限於使用技術指南屬性檔案中的屬性。您可以在執行個體的節點物件中使用任何屬性。例如，由 Chef 工具 (名稱為 [Ohai](https://docs.chef.io/ohai.html)) 產生的屬性也會納入節點物件。如需屬性的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。如需範本的詳細資訊，包括如何採用 Ruby 程式碼，請參閱[關於範本](http://docs.chef.io/templates.html)。 # 配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。配方是一種 Ruby 應用程式，可定義系統的組態。配方可以安裝套件、透過範本建立組態檔案、執行 shell 命令、建立檔案和目錄等。您通常會讓 OpsWorks Stacks 在執行個體上發生[生命週期事件](workingcookbook-events.md)時自動執行配方，但您也可以使用[執行配方堆疊命令隨時明確執行配方](workingcookbook-executing.md)。如需詳細資訊，請參閱[關於配方](http://docs.chef.io/recipes.html)。配方主要是由一系列的「*資源*」構成，每組資源都代表系統方面的理想狀態。每個資源都包含一組屬性，可定義理想的狀態，並指定要採取的動作。Chef 會將每個資源與適當的「*提供者*」建立關聯，而提供者可以執行動作。如需詳細資訊，請參閱[資源和提供者參考](https://docs.chef.io/resource.html)。 `package` 資源可協助您管理 Linux 執行個體上的軟體套件。下列範例會安裝 Apache 套件。 ``` ... package 'apache2' do case node[:platform] when 'centos','redhat','fedora','amazon' package_name 'httpd' when 'debian','ubuntu' package_name 'apache2' end action :install end ... ``` Chef 會針對平台使用適當的套件提供者。資源屬性通常只會指派一個值，但您可以使用 Ruby 邏輯操作來執行條件式指派。此範例使用 `case` 運算子，其會使用 `node[:platform]` 來識別執行個體的作業系統，並依此設定 `package_name` 屬性。您可以使用標準的 Chef 節點語法將屬性插入配方，Chef 即會以相關聯的值進行取代。您可以在節點物件中使用任何屬性，而不只限於技術指南的屬性。在判斷適當的套件名稱之後，程式碼區段會以 `install` 動做為結尾，由該動作安裝套件。此資源的其他動作包括 `upgrade` 和 `remove`。如需詳細資訊，請參閱[套件](https://docs.chef.io/chef/resources.html#id150)。下列方法通常很實用：將複雜的安裝和設定任務拆解為一或多個子任務，再以個別配方形式實作每個子任務，然後讓您的主要配方在適當的時間執行這些任務。下列範例所示的這行程式碼即遵循上述範例： ``` include_recipe 'apache2::service' ``` 若要讓配方執行子配方，請使用 `include_recipe` 關鍵字，後接配方名稱。配方是使用標準的 Chef `CookbookName::RecipeName` 語法來識別，其中 `RecipeName` 會省略 `.rb` 副檔名。 **注意** `include_recipe` 陳述式會有效地執行主要配方中該時間點的配方。然而，實際情況是，Chef 會將每個 `include_recipe` 陳述式取代為指定的配方程式碼，之後才執行主要配方。 `directory` 資源代表目錄，例如用來包含套件檔案的目錄。下列 `default.rb` 資源會建立 Linux 日誌目錄。 ``` directory node[:apache][:log_dir] do mode 0755 action :create end ``` 日誌目錄定義於其中一個技術指南的屬性檔案中。資源會將目錄的模式指定為 0755，並使用 `create` 動作來建立目錄。如需詳細資訊，請參閱[目錄](https://docs.chef.io/chef/resources.html#directory)。您也可以搭配使用此資源和 Windows 執行個體。 `execute` 資源代表命令，如 shell 命令或指令碼。下列範例會產生 module.load 檔案。 ``` execute 'generate-module-list' do if node[:kernel][:machine] == 'x86_64' libdir = 'lib64' else libdir = 'lib' end command "/usr/local/bin/apache2_module_conf_generate.pl /usr/#{libdir}/httpd/modules /etc/httpd/mods-available" action :run end ``` 資源首先會先判定 CPU 類型。`[:kernel][:machine]` 是 Chef 自動產生的另一個屬性，用來代表各種系統屬性，在此案例中為 CPU 類型。接著，它會指定命令 (Perl 指令碼) 並使用 `run` 動作來執行指令碼，以產生 module.load 檔案。如需詳細資訊，請參閱 [execute](https://docs.chef.io/chef/resources.html#execute)。 `template` 資源代表檔案，通常是組態檔案，該檔案會從其中一個技術指南的範本檔案產生。下列範例會透過 `apache2.conf.erb` 範本 (如[範本](workingcookbook-installingcustom-components-templates.md)中所述) 建立一個 `httpd.conf` 組態檔案。 ``` template 'apache2.conf' do case node[:platform] when 'centos','redhat','fedora','amazon' path "#{node[:apache][:dir]}/conf/httpd.conf" when 'debian','ubuntu' path "#{node[:apache][:dir]}/apache2.conf" end source 'apache2.conf.erb' owner 'root' group 'root' mode 0644 notifies :restart, resources(:service => 'apache2') end ``` 資源會根據執行個體的作業系統來判斷產生的檔案名稱和位置。接著，它會指定 `apache2.conf.erb` 為範本，以用來產生檔案，並設定檔案的擁有者、群組和模式。它會執行 `notify` 動作來通知 `service` 資源 (其代表要重新啟動伺服器的 Apache 伺服器)。如需詳細資訊，請參閱[範本](https://docs.chef.io/chef/resources.html#template)。 # 堆疊組態及部署屬性：Linux **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本主題包含最常用的堆疊組態和部署屬性及其相關節點語法。環繞 Linux 堆疊所使用的堆疊組態命名空間結構組織而成。請注意，相同的屬性名稱有時會用於不同的目的，因此出現在不同的命名空間。例如，`id` 可以是堆疊 ID、Layer ID、應用程式 ID 等等，因此您需要完整的名稱才能使用屬性值。將此資料視覺化為 JSON 物件是很方便的方法。如需範例，請參閱「[堆疊組態及部署屬性](workingcookbook-json.md)」。 **注意** 在 Linux 執行個體上，除了將資料新增至節點物件之外， OpsWorks Stacks 還會在每個執行個體上安裝此 JSON 物件。您可以使用[代理程式 CLI 的 `get_json` 命令](agent-json.md)來擷取它。 **Topics** + [opsworks 屬性](attributes-json-opsworks.md) + [opsworks\$1custom\$1cookbooks 屬性](attributes-json-custom.md) + [dependencies 屬性](attributes-json-dependencies.md) + [ganglia 屬性](attributes-json-ganglia.md) + [mysql 屬性](attributes-json-mysql.md) + [passenger 屬性](attributes-json-passenger.md) + [opsworks\$1bundler 屬性](attributes-json-bundler.md) + [deploy 屬性](attributes-json-deploy.md) + [其他最上層屬性](attributes-json-other.md) # opsworks 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 `opsworks` 元素有時稱為`opsworks`命名空間，包含一組定義基本堆疊組態的屬性。 **重要** 不建議覆寫 `opsworks` 命名空間中的屬性值。這樣會造成內建配方失敗。 **Topics** + [應用程式](attributes-json-opsworks-applications.md) + [instance 屬性](attributes-json-opsworks-instance.md) + [layer 屬性](attributes-json-opsworks-layers.md) + [rails\$1stack 屬性](attributes-json-opsworks-rails-stack.md) + [stack 屬性](attributes-json-opsworks-stack.md) + [其他最上層 opsworks 屬性](attributes-json-opsworks-other.md) # 應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。包含內嵌物件的清單，堆疊中現有的每個應用程式各一份。每個內嵌物件都包含說明應用程式組態的下列屬性。 **注意** 這些屬性的一般節點語法如下，其中 `i` 指定執行個體以零起始的清單索引。 ``` node["opsworks"]["applications"]["i"]["attribute_name"] ``` **application\$1type** 應用程式的類型 (字串)。可能的值如下： + `php`：PHP 應用程式 + `rails`：Ruby on Rails 應用程式 + `java`：Java 應用程式 + `nodejs`：Node.js 應用程式 + `web`：靜態 HTML 頁面 + `other`：所有其他應用程式類型 ``` node["opsworks"]["applications"]["i"]["application_type"] ``` **name** 使用者定義的顯示名稱，例如 `"SimplePHP"` (字串)。 ``` node["opsworks"]["applications"]["i"]["name"] ``` **slug\$1name** 簡稱，這是全部小寫的名稱，例如 `"simplephp"` 就是 OpsWorks 從應用程式名稱產生的 (字串)。 ``` node["opsworks"]["applications"]["i"]["slug_name"] ``` # instance 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 `instance` 屬性包含一組指定此執行個體組態的屬性。 **** | | | | | --- |--- |--- | | [架構](#attributes-json-opsworks-instance-arch) | [availability\$1zone](#attributes-json-opsworks-instance-availability) | [backends](#attributes-json-opsworks-instance-backends) | | [aws\$1instance\$1id](#attributes-json-opsworks-instance-ec2-id) | [hostname](#attributes-json-opsworks-instance-host) | [id](#attributes-json-opsworks-instance-id) | | [instance\$1type](#attributes-json-opsworks-instance-type) | [ip](#attributes-json-opsworks-instance-ip) | [圖層](#attributes-json-opsworks-instance-layers) | | [private\$1dns\$1name](#attributes-json-opsworks-instance-private-dns) | [private\$1ip](#attributes-json-opsworks-instance-private-ip) | [public\$1dns\$1name](#attributes-json-opsworks-instance-dns) | | [region](#attributes-json-opsworks-instance-region) | | | **架構** 該執行個體的架構，例如 `"i386"` (字串)。 ``` node["opsworks"]["instance"]["architecture"] ``` **availability\$1zone** 該執行個體的可用區域，例如 `"us-west-2a"` (字串)。 ``` node["opsworks"]["instance"]["availability_zone"] ``` **backends** 後端 Web 程序的數目 (字串)。例如，它會決定 HAProxy 要轉遞到 Rails 後端的並行連線數目。預設值視執行個體的記憶體和核心數而定。 ``` node["opsworks"]["instance"]["backends"] ``` **aws\$1instance\$1id** EC2 執行個體 ID (字串)。 ``` node["opsworks"]["instance"]["aws_instance_id"] ``` **hostname** 主機名稱，例如 `"php-app1"` (字串)。 ``` node["opsworks"]["instance"]["hostname"] ``` **id** 執行個體 ID，這是 OpsWorks Stacks 產生的 GUID，可唯一識別執行個體（字串）。 ``` node["opsworks"]["instance"]["id"] ``` **instance\$1type** 執行個體類型，例如 `"c1.medium"` (字串)。 ``` node["opsworks"]["instance"]["instance_type"] ``` **ip** 公有 IP 地址 (字串)。 ``` node["opsworks"]["instance"]["ip"] ``` **圖層** 該執行個體的 Layer 清單，依簡稱識別，例如 `"lb"` 或 `"db-master"` (字串清單)。 ``` node["opsworks"]["instance"]["layers"] ``` **private\$1dns\$1name** 私有 DNS 名稱 (字串)。 ``` node["opsworks"]["instance"]["private_dns_name"] ``` **private\$1ip** 私有 IP 地址 (字串)。 ``` node["opsworks"]["instance"]["private_ip"] ``` **public\$1dns\$1name** 公有 DNS 名稱 (字串)。 ``` node["opsworks"]["instance"]["public_dns_name"] ``` **region** AWS 區域，例如 `"us-west-2"` (字串)。 ``` node["opsworks"]["instance"]["region"] ``` # layer 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 `layers` 屬性包含一組 layer 屬性，每個堆疊 layer 一個，以 layer 的簡稱為名，例如 `php-app`。堆疊的每個內建 layer 最多可有一個，其簡稱如下： + `db-master`：MySQL layer + `java-app`：Java App Server layer + `lb`：HAProxy layer + `monitoring-master`：Ganglia layer + `memcached`：Memcached layer + `nodejs-app`：Node.js App Server layer + `php-app`：PHP App Server layer + `rails-app`：Rails App Server layer + `web`：靜態 Web 伺服器層堆疊可以包含任意數目的自訂 layer，有使用者定義的簡稱。每個 layer 屬性都包含以下屬性： + [id](#attributes-json-opsworks-layers-id) + [執行個體](#attributes-json-opsworks-layers-instances) + [name](#attributes-json-opsworks-layers-name) **id** layer ID，是 OpsWorks 產生的一種 GUID，且為 layer 的唯一識別 (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["id"] ``` **執行個體** `instances` 元素包含一組 instance 屬性，每個 layer 的線上執行個體各一個。它們以執行個體的主機名稱為名，例如 `php-app1`。 `instances` 元素只包含那些在建立特定堆疊組態和部署屬性時處於線上狀態的執行個體。每個 instance 元素都包含以下屬性： **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/attributes-json-opsworks-layers.html) **availability\$1zone** 可用區域，例如 `"us-west-2a"` (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["availability_zone"] ``` **aws\$1instance\$1id** EC2 執行個體 ID (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["aws_instance_id"] ``` **backends** 後端 Web 程序的數目 (數值)。例如，它會決定 HAProxy 要轉遞到 Rails 後端的並行連線數目。預設值視執行個體的記憶體和核心數而定。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["backends"] ``` **booted\$1at** EC2 執行個體的開機時間，使用 UTC yyyy-mm-dddThh:mm:ss\$1hh:mm 格式 (字串)。例如，`"2013-10-01T08:35:22+00:00"` 對應到 2013 年 10 月 10 日 8:35:22，無時區位移。如需詳細資訊，請參閱 [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["booted_at"] ``` **created\$1at** EC2 執行個體建立的時間，使用 UTC yyyy-mm-dddThh:mm:ss\$1hh:mm 格式 (字串)。例如，`"2013-10-01T08:35:22+00:00"` 對應到 2013 年 10 月 10 日 8:35:22，無時區位移。如需詳細資訊，請參閱 [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["created_at"] ``` **elastic\$1ip** 彈性 IP 地址，如果執行個體沒有此地址則設為 null (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["elastic_ip"] ``` **instance\$1type** 執行個體類型，例如 `"c1.medium"` (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["instance_type"] ``` **ip** 公有 IP 地址 (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["ip"] ``` **private\$1ip** 私有 IP 地址 (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["private_ip"] ``` **public\$1dns\$1name** 公有 DNS 名稱 (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["public_dns_name"] ``` **private\$1dns\$1name** 私有 DNS 名稱 (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["private_dns_name"] ``` **region** AWS 區域，例如 `"us-west-2"` (字串)。 ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["region"] ``` **status** 狀態 (字串)。可能的值如下： + `"requested"` + `"booting"` + `"running_setup"` + `"online"` + `"setup_failed"` + `"start_failed"` + `"terminating"` + `"terminated"` + `"stopped"` + `"connection_lost"` ``` node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["status"] ``` **name** layer 的名稱，用以在主控台中表示 layer (字串)。它可以是使用者定義的，但不一定是唯一的。 ``` node["opsworks"]["layers"]["layershortname"]["name"] ``` # rails\$1stack 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **name** 指定 Rails 堆疊，並設為 `"apache_passenger"` 或 `"nginx_unicorn"` (字串)。 ``` node["opsworks"]["rails_stack"]["name"] ``` **recipe ** 相關的配方，取決於您使用的是 Passenger 或 Unicorn (字串)： + Unicorn：`"unicorn::rails"` + Passenger：`"passenger_apache2::rails"` ``` node["opsworks"]["rails_stack"]["recipe"] ``` **restart\$1command ** restart 命令，取決於您使用的是 Passenger 或 Unicorn (字串)： + Unicorn：`"../../shared/scripts/unicorn clean-restart"` + Passenger：`"touch tmp/restart.txt"` **服務 ** 服務名稱，取決於您使用的是 Passenger 或 Unicorn (字串)： + Unicorn：`"unicorn"` + Passenger：`"apache2"` ``` node["opsworks"]["rails_stack"]["service"] ``` # stack 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 `stack` 屬性指定堆疊組態的某些方面，例如服務 layer 組態。 + [elb-load-balancers](#attributes-json-opsworks-stack-elb) + [id](#attributes-json-opsworks-stack-id) + [name](#attributes-json-opsworks-stack-name) + [rds\$1instances](#attributes-json-opsworks-stack-rds) + [vpc\$1id](#attributes-json-opsworks-stack-vpc-id) **elb-load-balancers** 包含內嵌物件的清單，堆疊中每個 Elastic Load Balancing 負載平衡器各一份。每個內嵌物件都包含說明負載平衡器組態的下列屬性。這些屬性的一般節點語法如下，其中 `i` 指定執行個體以零起始的清單索引。 ``` node["opsworks"]["stack"]["elb-load-balancers"]["i"]["attribute_name"] ``` **dns\$1name** 負載平衡器的 DNS 名稱 (字串)。 ``` node["opsworks"]["stack"]["elb-load-balancers"]["i"]["dns_name"] ``` **name** 負載平衡器的名稱 (字串)。 ``` node["opsworks"]["stack"]["elb-load-balancers"]["i"]["name"] ``` **layer\$1id** 負載平衡器連接到的 layer ID (字串)。 ``` node["opsworks"]["stack"]["elb-load-balancers"]["i"]["layer_id"] ``` **id** 堆疊 ID (字串)。 ``` node["opsworks"]["stack"]["id"] ``` **name** 堆疊名稱 (字串)。 ``` node["opsworks"]["stack"]["name"] ``` **rds\$1instances** 包含內嵌物件的清單，向堆疊註冊的每個 Amazon RDS 執行個體各一份。每個內嵌物件都包含一組屬性，它們會定義執行個體的組態。當您使用 Amazon RDS 主控台或 API 建立執行個體時，可以指定這些值。您也可以在建立執行個體之後，使用 Amazon RDS 主控台或 API 來編輯某些設定。如需詳細資訊，請參閱 [Amazon RDS 文件](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)。這些屬性的一般節點語法如下，其中 `i` 指定執行個體以零起始的清單索引。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["attribute_name"] ``` 如果您的堆疊有多個 Amazon RDS 執行個體，以下是如何在配方中使用特定執行個體的範例。 ``` if my_rds = node["opsworks"]["stack"]["rds_instances"].select{|rds_instance| rds_instance["db_instance_identifier"] == ‘db_id’ }.first template “/etc/rds.conf” do source "rds.conf.erb" variables :address => my_rds["address"] end end ``` **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/attributes-json-opsworks-stack.html) **address** 執行個體 URL，例如 `opsinstance.ccdvt3hwog1a.us-west-2.rds.amazonaws.com` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["address"] ``` **allocated\$1storage** 配置的儲存體，以 GB 為單位 (數值)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["allocated_storage"] ``` **arn** 執行個體的 ARN (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["arn"] ``` **auto\$1minor\$1version\$1upgrade** 是否自動套用次要版本升級 (布林值)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["auto_minor_version_upgrade"] ``` **availability\$1zone** 執行個體的可用區域，例如 `us-west-2a` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["availability_zone"] ``` **backup\$1retention\$1period** 備份保留期，以天為單位 (數值)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["backup_retention_period"] ``` **db\$1instance\$1class** 資料庫執行個體類別，例如 `db.m1.small` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_instance_class"] ``` **db\$1instance\$1identifier** 使用者定義的資料庫執行個體識別符 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_instance_identifier"] ``` **db\$1instance\$1status** 執行個體的狀態 (字串)。如需詳細資訊，請參閱[資料庫執行個體](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_instance_status"] ``` **db\$1name** 使用者定義的資料庫名稱 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_name"] ``` **db\$1parameter\$1groups** 執行個體的資料庫參數群組，包含內嵌物件的清單，每個參數群組各一份。如需詳細資訊，請參閱[使用資料庫參數群組](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)。每個物件包含下列屬性： **db\$1parameter\$1group\$1name** 群組名稱 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_parameter_groups"][j"]["db_parameter_group_name"] ``` **parameter\$1apply\$1status** 套用狀態 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_parameter_groups"][j"]["parameter_apply_status"] ``` **db\$1security\$1groups** 執行個體的資料庫安全群組，包含內嵌物件的清單，每個安全群組各一份。如需詳細資訊，請參閱[使用資料庫安全群組](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithSecurityGroups.html)。每個物件包含下列屬性 **db\$1security\$1group\$1name** 安全群組名稱 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_security_groups"][j"]["db_security_group_name"] ``` **status** 狀態 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_security_groups"][j"]["status"] ``` **db\$1user** 使用者定義的主要使用者名稱 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["db_user"] ``` **engine** 資料庫引擎，例如 `mysql(5.6.13)` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["engine"] ``` **instance\$1create\$1time** 執行個體建立時間，例如 `2014-04-15T16:13:34Z` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["instance_create_time"] ``` **license\$1model** 執行個體的授權模型，例如 `general-public-license` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["license_model"] ``` **multi\$1az** 是否啟用異地同步備份部署 (布林值)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["multi_az"] ``` **option\$1group\$1memberships** 執行個體的選項群組成員資格，包含內嵌物件的清單，每個選項群組各一份。如需詳細資訊，請參閱[使用選項群組](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithOptionGroups.html)。每個物件包含下列屬性： **option\$1group\$1name** 群組名稱 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["option_group_memberships"][j"]["option_group_name"] ``` **status** 群組狀態 (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["option_group_memberships"][j"]["status"] ``` **port** 資料庫伺服器的連接埠 (數值)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["port"] ``` **preferred\$1backup\$1window** 每天偏好的備份時段，例如 `06:26-06:56` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["preferred_backup_window"] ``` **preferred\$1maintenance\$1window** 每週偏好的維護時段，例如 `thu:07:13-thu:07:43` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["preferred_maintenance_window"] ``` **publicly\$1accessible** 資料庫是否可公開存取 (布林值)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["publicly_accessible"] ``` **read\$1replica\$1db\$1instance\$1identifiers** 僅供讀取複本執行個體識別符清單 (字串清單)。如需詳細資訊，請參閱[使用僅供讀取複本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["read_replica_db_instance_identifiers"] ``` **region** AWS 區域，例如 `us-west-2` (字串)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["region"] ``` **status\$1infos** 狀態資訊清單 (字串清單)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["status_infos"] ``` **vpc\$1security\$1groups** VPC 安全群組清單 (字串清單)。 ``` node["opsworks"]["stack"]["rds_instances"]["i"]["vpc_security_groups"] ``` **vpc\$1id** VPC ID (字串)。如果執行個體不是 VPC，則此值為 `null`。 ``` node["opsworks"]["stack"]["vpc_id"] ``` # 其他最上層 opsworks 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節包含沒有子屬性的 `opsworks` 屬性。 **activity** 與屬性相關聯的活動，例如 `deploy` (字串)。 ``` node["opsworks"]["activity"] ``` **agent\$1version** 執行個體的 OpsWorks 代理程式版本 (字串)。 ``` node["opsworks"]["agent_version"] ``` **deploy\$1chef\$1provider** Chef 部署供應商，這會影響已部署的應用程式目錄結構 (字串)。您可以將此屬性設定為下列其中一項： + `Branch` + `Revision` + `Timestamped` (預設值) ``` node["opsworks"]["deploy_chef_provider"] ``` **ruby\$1stack** Ruby 堆疊 (字串)。預設設定為企業版本 (`ruby_enterprise`)。若為 MRI 版本，請將此屬性設為 `ruby`。 ``` node["opsworks"]["ruby_stack"] ``` **ruby\$1version** 應用程式會使用的 Ruby 版本 (字串)。您可以使用此屬性只指定主要和次要版本。您必須使用適當的 [["ruby"]](attributes-recipes-ruby.md) 屬性來指定修補程式版本。如需如何指定版本的詳細資訊，包括範例，請參閱 [Ruby 版本](workingcookbook-ruby.md)。如需 OpsWorks Stacks 如何決定 Ruby 版本的完整詳細資訊，請參閱內建的屬性檔案 [ruby.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/ruby/attributes/ruby.rb)。 ``` node["opsworks"]["ruby_version"] ``` **run\$1cookbook\$1tests** 是否對您的 Chef 11.4 技術指南執行 [minitest-chef-handler](https://github.com/calavera/minitest-chef-handler) 測試 (布林值)。 ``` node["opsworks"]["run_cookbook_tests"] ``` **sent\$1at** 此命令傳送到執行個體的時間 (數值)。 ``` node["opsworks"]["sent_at"] ``` **deployment** 如果這些屬性與部署活動相關聯，`deployment` 會設為部署 ID，該 ID 是由 OpsWorks Stacks 產生的 GUID (字串)，可唯一識別部署。否則屬性設為 null。 ``` node["opsworks"]["deployment"] ``` # opsworks\$1custom\$1cookbooks 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。包含指定堆疊自訂技術指南的屬性。 **已啟用** 是否啟用自訂技術指南 (布林值)。 ``` node["opsworks_custom_cookbooks"]["enabled"] ``` **recipes** 要以此命令執行的配方清單，包括自訂配方，使用 `cookbookname::recipename` 格式 (字串清單)。 ``` node["opsworks_custom_cookbooks"]["recipes"] ``` # dependencies 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。包含多個與 `update_dependencies` [堆疊命令](workingstacks-commands.md)相關的屬性。 **gem\$1binary** Gems 二元碼的位置 (字串)。 **upgrade\$1debs** 是否升級 Debs 套件 (布林值)。 **update\$1debs** 是否更新 Debs 套件 (布林值)。 # ganglia 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。包含 **web** 屬性，它有多個屬性可指定如何存取 Ganglia 統計資料網頁： **password** 存取統計資料頁面所需的密碼 (字串)。 ``` node["ganglia"]["web"]["password"] ``` **url** 統計資料頁面的 URL 路徑，例如 `"/ganglia"` (字串)。完整的 URL 為 `http://DNSNameURLPath`，其中 `DNSName` 是關聯執行個體的 DNS 名稱。 ``` node["ganglia"]["web"]["url"] ``` **user** 存取統計資料頁面所需的使用者名稱 (字串)。 ``` node["ganglia"]["web"]["user"] ``` # mysql 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。包含一組指定 MySQL 資料庫伺服器組態的屬性。 **用戶端** 用戶端 IP 地址清單 (字串清單)。 ``` node["mysql"]["clients"] ``` **server\$1root\$1password** 根密碼 (字串)。 ``` node["mysql"]["server_root_password"] ``` # passenger 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。包含一組指定 Phusion Passenger 組態的屬性。 **gem\$1bin** RubyGems 二元碼的位置，例如 `"/usr/local/bin/gem"` (字串)。 ``` node["passenger"]["gem_bin"] ``` **max\$1pool\$1size** 集區大小上限 (數值)。 ``` node["passenger"]["max_pool_size"] ``` **ruby\$1bin** Ruby 二元碼的位置，例如 `"/usr/local/bin/ruby"`。 ``` node["passenger"]["ruby_bin"] ``` **version** Passenger 版本 (字串)。 ``` node["passenger"]["version"] ``` # opsworks\$1bundler 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。包含指定 [Bundler](http://gembundler.com/) 支援的元素。 **manage\$1package** 是否安裝與管理 Bundler (布林值)。 ``` node["opsworks_bundler"]["manage_package"] ``` **version** bundler 版本 (字串)。 ``` node["opsworks_bundler"]["version"] ``` # deploy 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果這些屬性與[部署事件](workingcookbook-events.md)或[執行配方堆疊命令](workingstacks-commands.md)相關，則 `deploy` 屬性會包含每個以應用程式簡稱為名之已部署應用程式的屬性。每個應用程式屬性都包含下列屬性： **** | | | | | --- |--- |--- | | [應用程式](#attributes-json-deploy-app-app) | [application\$1type](#attributes-json-deploy-app-type) | [auto\$1bundle\$1on\$1deploy](#attributes-json-deploy-app-auto) | | [資料庫](#attributes-json-deploy-app-db) | [deploy\$1to](#attributes-json-deploy-app-deploy-to) | [domains](#attributes-json-deploy-app-domains) | | [document\$1root](#attributes-json-deploy-app-root) | [environment\$1variables](#attributes-json-deploy-app-environment) | [群組](#attributes-json-deploy-app-group) | | [keep\$1releases](#attributes-json-deploy-app-keep-releases) | [memcached](#attributes-json-deploy-app-memcached) | [migrate](#attributes-json-deploy-app-migrate) | | [mounted\$1at](#attributes-json-deploy-app-mounted) | [purge\$1before\$1symlink](#attributes-json-deploy-app-purge-before-symlink) | [rails\$1env](#attributes-json-deploy-app-ssl-rails) | | [restart\$1command](#attributes-json-deploy-app-restart) | [scm](#attributes-json-deploy-app-scm) | [ssl\$1certificate](#attributes-json-deploy-app-ssl-cert) | | [ssl\$1certificate\$1ca](#attributes-json-deploy-app-ssl-ca) | [ssl\$1certificate\$1key](#attributes-json-deploy-app-ssl-key) | [ssl\$1support](#attributes-json-deploy-app-ssl-supp) | | [堆疊](#attributes-json-deploy-app-stack) | [symlink\$1before\$1migrate](#attributes-json-deploy-app-symlink-migrate) | [symlinks](#attributes-json-deploy-app-symlinks) | | [user](#attributes-json-deploy-app-user) | | | **應用程式** 應用程式的動態資料欄位名稱，例如 `"simplephp"` (字串)。 ``` node["deploy"]["appshortname"]["application"] ``` **application\$1type** 應用程式類型 (字串)。可能的值如下： + `java`：Java 應用程式 + `nodejs`：Node.js 應用程式 + `php`：PHP 應用程式 + `rails`：Ruby on Rails 應用程式 + `web`：靜態 HTML 頁面 + `other`：所有其他應用程式類型 ``` node["deploy"]["appshortname"]["application_type"] ``` **auto\$1bundle\$1on\$1deploy** 若為 Rails 應用程式，是否在部署期間執行 bundler (布林值)。 ``` node["deploy"]["appshortname"]["auto_bundle_on_deploy"] ``` **資料庫** 包含連線應用程式資料庫所需的資訊。如果應用程式已連接資料庫層， OpsWorks Stacks 會自動將適當的值指派給這些屬性。 **adapter** 資料庫轉接器，例如 `mysql` (字串)。 ``` node["deploy"]["appshortname"]["database"]["adapter"] ``` **資料庫** 資料庫名稱，通常是應用程式的動態資料欄位名稱，例如 `"simplephp"` (字串)。 ``` node["deploy"]["appshortname"]["database"]["database"] ``` **data\$1source\$1provider** 資料來源：`mysql` 或 `rds` (字串)。 ``` node["deploy"]["appshortname"]["database"]["data_source_provider"] ``` **託管** 資料庫主機的 IP 地址 (字串)。 ``` node["deploy"]["appshortname"]["database"]["host"] ``` **password** 資料庫密碼 (字串)。 ``` node["deploy"]["appshortname"]["database"]["password"] ``` **port** 資料庫連接埠 (數值)。 ``` node["deploy"]["appshortname"]["database"]["port"] ``` **reconnect** 若為 Rails 應用程式，當連線不再存在時，是否應該重新連線應用程式 (布林值)。 ``` node["deploy"]["appshortname"]["database"]["reconnect"] ``` **使用者名稱** 使用者名稱 (字串)。 ``` node["deploy"]["appshortname"]["database"]["username"] ``` **deploy\$1to** 應用程式的部署位置，例如 `"/srv/www/simplephp"` (字串)。 ``` node["deploy"]["appshortname"]["deploy_to"] ``` **domains** 應用程式網域清單 (字串清單)。 ``` node["deploy"]["appshortname"]["domains"] ``` **document\$1root** 如果指定非預設的根目錄，即為文件根目錄；如果使用預設根目錄，則為 null (字串)。 ``` node["deploy"]["appshortname"]["document_root"] ``` **environment\$1variables** 最多二十個屬性的集合，代表已為應用程式定義之使用者指定的環境變數。如需如何定義應用程式環境變數的詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。每個屬性名稱都設為環境變數名稱，對應的值則設為變數的值，所以您可以使用下列語法來參考特定的值。 ``` node["deploy"]["appshortname"]["environment_variables"]["variable_name"] ``` **群組** 應用程式的群組 (字串)。 ``` node["deploy"]["appshortname"]["group"] ``` **keep\$1releases** Stacks OpsWorks 將存放的應用程式部署數目（數目）。此屬性控制您可以轉返應用程式的次數。根據預設，它設定為全球值 [deploy\$1keep\$1releases ](attributes-recipes-deploy.md#attributes-recipes-deploy-global-keep-releases)，預設值為 5。您可以覆寫 `keep_releases` 以指定特定應用程式的已存放部署數目。 ``` node["deploy"]["appshortname"]["keep_releases"] ``` **memcached** 包含定義 memcached 組態的兩個屬性。 **託管** Memcached 伺服器執行個體的 IP 地址（字串）。 ``` node["deploy"]["appshortname"]["memcached"]["host"] ``` **port** memcached 伺服器接聽的連接埠 (數值)。 ``` node["deploy"]["appshortname"]["memcached"]["port"] ``` **migrate** 若為 Rails 應用程式，是否執行遷移 (布林值)。 ``` node["deploy"]["appshortname"]["migrate"] ``` **mounted\$1at** 如果指定非預設的掛載點，即為應用程式的掛載點，如果使用預設的掛載點則為 null (字串)。 ``` node["deploy"]["appshortname"]["mounted_at"] ``` **purge\$1before\$1symlink** Rails 應用程式會先清除路徑陣列，再建立 symlinks (字串清單)。 ``` node["deploy"]["appshortname"]["purge_before_symlink"] ``` **rails\$1env** 對於 Rails App Server 執行個體，導軌環境，例如 `"production"`（字串）。 ``` node["deploy"]["appshortname"]["rails_env"] ``` **restart\$1command** 重新啟動應用程式時要執行的命令，例如 `"echo 'restarting app'"`。 ``` node["deploy"]["appshortname"]["restart_command"] ``` **scm** 包含一組屬性，指定 OpsWorks 從其來源控制儲存庫部署應用程式所使用的資訊。屬性隨儲存庫類型而異。 **password** 私有儲存庫為密碼，公有儲存庫則為 null (字串)。對於私有 Amazon S3 儲存貯體，屬性會設定為私密金鑰。 ``` node["deploy"]["appshortname"]["scm"]["password"] ``` **repository** 儲存庫 URL，例如 `"git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git"` (字串)。 ``` node["deploy"]["appshortname"]["scm"]["repository"] ``` **修訂** 如果儲存庫有多個分支，此屬性會指定該應用程式的分支或版本，例如 `"version1"` (字串)。否則會設為 null。 ``` node["deploy"]["appshortname"]["scm"]["revision"] ``` **scm\$1type** 儲存庫類型 (字串)。可能的值如下： + `"git"`：Git 儲存庫 + `"svn"`：Subversion 儲存庫 + `"s3"`：Amazon S3 儲存貯體 + `"archive"`：HTTP 封存 + `"other"`：其他儲存庫類型 ``` node["deploy"]["appshortname"]["scm"]["scm_type"] ``` **ssh\$1key** 用來存取私有 Git 儲存庫的[部署 SSH 金鑰](workingapps-deploykeys.md)，公有儲存庫則為 null (字串)。 ``` node["deploy"]["appshortname"]["scm"]["ssh_key"] ``` **user** 私有儲存庫為使用者名稱，公有儲存庫則為 null (字串)。對於私有 Amazon S3 儲存貯體，屬性會設定為存取金鑰。 ``` node["deploy"]["appshortname"]["scm"]["user"] ``` **ssl\$1certificate** 如已啟用 SSL 支援，則為應用程式的 SSL 憑證，否則為 null (字串)。 ``` node["deploy"]["appshortname"]["ssl_certificate"] ``` **ssl\$1certificate\$1ca** 如已啟用 SSL，則為指定中繼憑證授權單位金鑰或用戶端身分驗證的屬性 (字串)。 ``` node["deploy"]["appshortname"]["ssl_certificate_ca"] ``` **ssl\$1certificate\$1key** 如已啟用 SSL 支援，則為應用程式的 SSL 私有金鑰，否則為 null (字串)。 ``` node["deploy"]["appshortname"]["ssl_certificate_key"] ``` **ssl\$1support** 是否支援 SSL (布林值)。 ``` node["deploy"]["appshortname"]["ssl_support"] ``` **堆疊** 包含一個布林值屬性 `needs_reload`，指定是否在部署期間重新載入應用程式伺服器。 ``` node["deploy"]["appshortname"]["stack"]["needs_reload"] ``` **symlink\$1before\$1migrate** Rails 應用程式包含的 symlink，要先建立再當成 `"link":"target"` 配對執行遷移。 ``` node["deploy"]["appshortname"]["symlink_before_migrate"] ``` **symlinks** 包含部署的 symlink 做為 `"link":"target"` 配對。 ``` node["deploy"]["appshortname"]["symlinks"] ``` **user** 應用程式的使用者 (字串)。 ``` node["deploy"]["appshortname"]["user"] ``` # 其他最上層屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節包含沒有子屬性的最上層堆疊組態屬性。 **rails 屬性** 包含指定伺服器集區大小上限的 **max\$1pool\$1size** 屬性 (數值)。屬性值由 Stacks OpsWorks 設定，並取決於執行個體類型，但您可以使用自訂 JSON 或自訂屬性檔案[來覆寫](workingcookbook-attributes.md)它。 ``` node["rails"]["max_pool_size"] ``` **recipes 屬性** 此活動過去執行的內建配方清單，使用 `"cookbookname::recipename"` 格式 (字串清單)。 ``` node["recipes"] ``` **opsworks\$1rubygems 屬性** 包含指定 RubyGems 版本的 **version** 元素 (字串)。 ``` node["opsworks_rubygems"]["version"] ``` **languages 屬性** 包含為每個已安裝語言命名的屬性，例如 **ruby**。此屬性是一種物件，可包含屬性 (例如 **ruby\$1bin**)，也可指定安裝資料夾 (例如 `"/usr/bin/ruby"`) (字串)。 **ssh\$1users 屬性** 包含一組屬性，每個屬性都會描述已授予 SSH 許可的其中一個使用者。每個屬性都以使用者的 Unix ID 命名。 OpsWorks Stacks 會為 2000-4000 範圍內的每個使用者產生唯一的 ID，例如 `"2001"`，並在每個執行個體上建立具有該 ID 的使用者。因為 OpsWorks 會保留 2000-4000 範圍，您在之外建立的使用者 OpsWorks （例如使用技術指南配方，或從 IAM OpsWorks 將使用者匯入 ) 可以擁有由 Stacks OpsWorks 為其他使用者覆寫的 UIDs。最佳實務是在 Stacks OpsWorks 主控台中建立使用者並管理其存取權。如果您在 OpsWorks Stacks 之外建立使用者，請使用大於 4000 的 *UnixID* 值。每個屬性都包含下列屬性： **email** 使用者的電子郵件地址 (字串)。 ``` node["ssh_users"]["UnixID"]["email"] ``` **public\$1key** 使用者的公有 SSH 金鑰 (字串)。 ``` node["ssh_users"]["UnixID"]["public_key"] ``` **sudoer** 使用者是否有 sudo 許可 (布林值)。 ``` node["ssh_users"]["UnixID"]["sudoer"] ``` **name** 使用者名稱 (字串)。 ``` node["ssh_users"]["UnixID"]["name"] ``` # 內建技術指南屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 其中大部分屬性僅適用於 Linux 堆疊。大多數內建配方具有一或多個[屬性檔案](workingcookbook-installingcustom-components-attributes.md)，可定義各種設定。您可以存取自訂配方中的這些設定，並使用自訂 JSON 加以覆寫。您通常需要存取或覆寫屬性，以控制 Stacks OpsWorks 支援的各種伺服器技術的組態。本節摘要說明這些屬性。您可以在 [https://github.com/aws/opsworks-cookbooks.git](https://github.com/aws/opsworks-cookbooks.git) 找到完整的屬性檔案，以及相關聯的配方和範本。 **注意** 所有內建配方屬性都是 `default` 類型。 **Topics** + [apache2 屬性](attributes-recipes-apache.md) + [deploy 屬性](attributes-recipes-deploy.md) + [haproxy 屬性](attributes-recipes-haproxy.md) + [memcached 屬性](attributes-recipes-mem.md) + [mysql 屬性](attributes-recipes-mysql.md) + [nginx 屬性](attributes-recipes-nginx.md) + [opsworks\$1berkshelf 屬性](attributes-recipes-berkshelf.md) + [opsworks\$1java 屬性](attributes-recipes-java.md) + [passenger\$1apache2 屬性](attributes-recipes-passenger.md) + [ruby 屬性](attributes-recipes-ruby.md) + [unicorn 屬性](attributes-recipes-unicorn.md) # apache2 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [apache2 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/attributes/apache.rb)指定 [Apache HTTP 伺服器](http://httpd.apache.org/)組態。如需詳細資訊，請參閱 [Apache Core Features](http://httpd.apache.org/docs/current/mod/core.html)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [binary ](#attributes-recipes-apache-bin) | [contact ](#attributes-recipes-apache-contact) | [deflate\$1types](#attributes-recipes-apache-deflate) | | [dir ](#attributes-recipes-apache-dir) | [document\$1root ](#attributes-recipes-apache-doc-root) | [群組 ](#attributes-recipes-apache-group) | | [hide\$1info\$1headers ](#attributes-recipes-apache-hide) | [icondir ](#attributes-recipes-apache-icondir) | [init\$1script ](#attributes-recipes-apache-init-script) | | [keepalive ](#attributes-recipes-apache-keep) | [keepaliverequests ](#attributes-recipes-apache-keep-requests) | [keepalivetimeout ](#attributes-recipes-apache-keep-timeout) | | [lib\$1dir ](#attributes-recipes-apache-lib-dir) | [libexecdir ](#attributes-recipes-apache-libexecdir) | [listen\$1ports ](#attributes-recipes-apache-ports) | | [log\$1dir ](#attributes-recipes-apache-log-dir) | [logrotate 屬性](#attributes-recipes-apache-log) | [pid\$1file ](#attributes-recipes-apache-pidfile) | | [prefork 屬性](#attributes-recipes-apache-prefork) | [serversignature ](#attributes-recipes-apache-sig) | [servertokens ](#attributes-recipes-apache-tokens) | | [timeout ](#attributes-recipes-apache-timeout) | [traceenable ](#attributes-recipes-apache-trace) | [user ](#attributes-recipes-apache-user) | | [version](#attributes-recipes-apache-version) | [worker 屬性](#attributes-recipes-apache-worker) | | **binary ** Apache 二進位檔的位置 (字串)。預設值為 `'/usr/sbin/httpd'`。 ``` node[:apache][:binary] ``` **contact ** 電子郵件聯絡人 (字串)。預設值是虛擬地址 `'ops@example.com'`。 ``` node[:apache][:contact] ``` **deflate\$1types** 引導 `mod_deflate` 啟用受瀏覽器支援之指定 MIME 類型的壓縮 (字串清單)。預設值如下： ``` ['application/javascript', 'application/json', 'application/x-javascript', 'application/xhtml+xml', 'application/xml', 'application/xml+rss', 'text/css', 'text/html', 'text/javascript', 'text/plain', 'text/xml'] ``` 壓縮可能會引發安全風險。若要完全停用壓縮，請設定此屬性如下： ``` node[:apache][:deflate_types] = [] ``` ``` node[:apache][:deflate_types] ``` **dir ** 伺服器的根目錄 (字串)。預設值如下： + Amazon Linux 和 Red Hat Enterprise Linux (RHEL)：`'/etc/httpd'` + Ubuntu：`'/etc/apache2'` ``` node[:apache][:dir] ``` **document\$1root ** 文件根 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'/var/www/html'` + Ubuntu：`'/var/www'` ``` node[:apache][:document_root] ``` **群組 ** 群組名稱 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'apache'` + Ubuntu：`'www-data'` ``` node[:apache][:group] ``` **hide\$1info\$1headers ** 是否省略 HTTP 標頭中的版本和模組資訊 (`'true'`/`'false'`) (字串)。預設值為 `'true'`。 ``` node[:apache][:hide_info_headers] ``` **icondir ** 圖示目錄 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'/var/www/icons/'` + Ubuntu：`'/usr/share/apache2/icons'` ``` node[:apache][:icondir] ``` **init\$1script ** 初始化指令碼 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'/etc/init.d/httpd'` + Ubuntu：`'/etc/init.d/apache2'` ``` node[:apache][:init_script] ``` **keepalive ** 是否啟用持續連線 (字串)。可能的值為 `'On'` 和 `'Off'` (字串)。預設值為 `'Off'`。 ``` node[:apache][:keepalive] ``` **keepaliverequests ** Apache 會同時處理的持續連線請求數目上限 (數值)。預設值為 `100`。 ``` node[:apache][:keepaliverequests] ``` **keepalivetimeout ** Apache 等待請求的時間，之後會關閉連線 (數值)。預設值為 `3`。 ``` node[:apache][:keepalivetimeout] ``` **lib\$1dir ** 包含物件程式碼程式庫的目錄 (字串)。預設值如下： + Amazon Linux (x86)：`'/usr/lib/httpd'` + Amazon Linux (x64) 和 RHEL：`'/usr/lib64/httpd'` + Ubuntu：`'/usr/lib/apache2'` ``` node[:apache][:lib_dir] ``` **libexecdir ** 包含可執行程式的目錄 (字串)。預設值如下： + Amazon Linux (x86)：`'/usr/lib/httpd/modules'` + Amazon Linux (x64) 和 RHEL：`'/usr/lib64/httpd/modules'` + Ubuntu：`'/usr/lib/apache2/modules'` ``` node[:apache][:libexecdir] ``` **listen\$1ports ** 伺服器接聽的連接埠清單 (字串清單)。預設值為 `[ '80','443' ]`。 ``` node[:apache][:listen_ports] ``` **log\$1dir ** 日誌目錄 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'/var/log/httpd'` + Ubuntu：`'/var/log/apache2'` ``` node[:apache][:log_dir] ``` **logrotate 屬性** 這些屬性指定如何輪換日誌檔案。 **delaycompress ** 是否將已關閉的日誌檔案壓縮延遲到下一個輪換週期開始 (`'true'`/`'false'`) (字串)。預設值為 `'true'`。 ``` node[:apache][:logrotate][:delaycompress] ``` **群組 ** 日誌檔案的群組 (字串)。預設值為 `'adm'`。 ``` node[:apache][:logrotate][:group] ``` **模式 ** 日誌檔案的模式 (字串)。預設值為 `'640'`。 ``` node[:apache][:logrotate][:mode] ``` **owner ** 日誌檔案的擁有者 (字串)。預設值為 `'root'`。 ``` node[:apache][:logrotate][:owner] ``` **rotate ** 輪換週期次數，之後會移除已關閉的日誌檔案 (字串)。預設值為 `'30'`。 ``` node[:apache][:logrotate][:rotate] ``` **schedule ** 輪換排程 (字串)。可能的值如下： + `'daily'` + `'weekly'` + `'monthly'` 預設值為 `'daily'`。 ``` node[:apache][:logrotate][:schedule] ``` **pid\$1file ** 包含協助程式之處理序 ID 的檔案 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'/var/run/httpd/httpd.pid'` + Ubuntu：`'/var/run/apache2.pid'` ``` node[:apache][:pid_file] ``` **prefork 屬性** 這些屬性指定預先分支處理組態。 **maxclients ** 要儲存的同步請求數目上限 (數值)。預設值為 `400`。僅針對執行 Amazon Linux 或 RHEL 的執行個體使用此屬性。如果您的執行個體執行 Ubuntu 14.04 LTS，請使用 [maxrequestworkers](#attributes-recipes-apache-prefork-maxrequestworkers)。 ``` node[:apache][:prefork][:maxclients] ``` **maxrequestsperchild ** 子伺服器處理序會處理的請求數目上限 (數值)。預設值為 `10000`。 ``` node[:apache][:prefork][:maxrequestsperchild] ``` **maxrequestworkers** 要儲存的同步請求數目上限 (數值)。預設值為 `400`。此屬性只能用於執行 Ubuntu 14.04 LTS 的執行個體。如果您的執行個體正在執行 Amazon Linux 或 RHEL，請使用 [maxclients ](#attributes-recipes-apache-prefork-maxclients)。 ``` node[:apache][:prefork][:maxrequestworkers] ``` **maxspareservers ** 閒置子伺服器處理序數目上限 (數值)。預設值為 `32`。 ``` node[:apache][:prefork][:maxspareservers] ``` **minspareservers ** 閒置子伺服器處理序數目下限 (數值)。預設值為 `16`。 ``` node[:apache][:prefork][:minspareservers] ``` **serverlimit ** 可設定的處理序數目上限 (數值)。預設值為 `400`。 ``` node[:apache][:prefork][:serverlimit] ``` **startservers ** 要在啟動時建立的子伺服器處理序數目 (數值)。預設值為 `16`。 ``` node[:apache][:prefork][:startservers] ``` **serversignature ** 指定是否及如何設定伺服器產生文件尾端的頁尾 (字串)。可能的值為 `'On'`、`'Off'` 和 `'Email'`。預設值為 `'Off'`。 ``` node[:apache][:serversignature] ``` **servertokens ** 指定要包含在回應標頭中的伺服器版本資訊類型 (字串)： + `'Full'`：完整資訊。例如，伺服器：Apache/2.4.2 (Unix) PHP/4.2.2 MyMod/1.2 + `'Prod'`：產品名稱。例如，伺服器：Apache + `'Major'`：主要版本。例如，伺服器：Apache/2 + `'Minor'`：主要和次要版本。例如，伺服器：Apache/2.4 + `'Min'`：最低版本。例如，伺服器：Apache/2.4.2 + `'OS'`：作業系統版本。例如，伺服器：Apache/2.4.2 (Unix) 預設值為 `'Prod'`。 ``` node[:apache][:servertokens] ``` **timeout ** Apache 等待 I/O 的時間 (數值)。預設值為 `120`。 ``` node[:apache][:timeout] ``` **traceenable ** 是否啟用 `TRACE` 請求 (字串)。可能的值為 `'On'` 和 `'Off'`。預設值為 `'Off'`。 ``` node[:apache][:traceenable] ``` **user ** 使用者名稱 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'apache'` + Ubuntu：`'www-data'` ``` node[:apache][:user] ``` **version** Apache 版本 (字串)。預設值如下： + Amazon Linux: `2.2` + Ubuntu 14.04 LTS：`2.4` + RHEL: `2.4` ``` node[:apache][:version] ``` **worker 屬性** 這些屬性指定工作者處理序組態。 **startservers ** 要在啟動時建立的子伺服器處理序數目 (數值)。預設值為 `4`。 ``` node[:apache][:worker][:startservers] ``` **maxclients ** 要儲存的同步請求數目上限 (數值)。預設值為 `1024`。 ``` node[:apache][:worker][:maxclients] ``` **maxsparethreads ** 閒置執行緒數目上限 (數值)。預設值為 `192`。 ``` node[:apache][:worker][:maxsparethreads] ``` **minsparethreads ** 閒置執行緒數目下限 (數值)。預設值為 `64`。 ``` node[:apache][:worker][:minsparethreads] ``` **threadsperchild ** 每個子處理序的執行緒數目 (數值)。預設值為 `64`。 ``` node[:apache][:worker][:threadsperchild] ``` **maxrequestsperchild ** 子伺服器處理序會處理的請求數目上限 (數值)。預設值為 `10000`。 ``` node[:apache][:worker][:maxrequestsperchild] ``` # deploy 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 [內建部署技術指南的 `deploy.rb` 屬性檔案](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/deploy/attributes/deploy.rb)定義 `opsworks` 命名空間中的下列屬性。如需部署目錄的詳細資訊，請參閱[部署配方](create-custom-deploy.md)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **deploy\$1keep\$1releases ** Stacks OpsWorks 將存放之應用程式部署數量的全域設定（數字）。預設值為 5。此值控制您可以復原應用程式的次數。 ``` node[:opsworks][:deploy_keep_releases] ``` **群組 ** (僅限 Linux) 應用程式部署目錄的 `group` 設定 (字串)。預設值視執行個體的作業系統而定。 + 若是 Ubuntu 執行個體，預設值為 `www-data`。 + 對於使用 Nginx 和 Unicorn 的 Rails App Server 層成員的 Amazon Linux 或 RHEL 執行個體，預設值為 `nginx`。 + 若是其他所有 Amazon Linux 或 RHEL 執行個體，預設值為 `apache`。 ``` node[:opsworks][:deploy_user][:group] ``` **user ** (僅限 Linux) 應用程式部署目錄的 `user` 設定 (字串)。預設值為 `deploy`。 ``` node[:opsworks][:deploy_user][:user] ``` # haproxy 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`haproxy` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/haproxy/attributes/default.rb)指定 [HAProxy 伺服器](http://haproxy.1wt.eu/)組態。如需詳細資訊，請參閱 [HAProxy 文件](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [balance ](#attributes-recipes-haproxy-balance) | [check\$1interval ](#attributes-recipes-haproxy-interval) | [client\$1timeout ](#attributes-recipes-haproxy-client-timeout) | | [connect\$1timeout ](#attributes-recipes-haproxy-connect-timeout) | [default\$1max\$1connections ](#attributes-recipes-haproxy-default-max) | [global\$1max\$1connections ](#attributes-recipes-haproxy-global-max) | | [health\$1check\$1method ](#attributes-recipes-haproxy-health-method) | [health\$1check\$1url ](#attributes-recipes-haproxy-health-url) | [queue\$1timeout ](#attributes-recipes-haproxy-queue-timeout) | | [http\$1request\$1timeout ](#attributes-recipes-haproxy-http-timeout) | [maxcon\$1factor\$1nodejs\$1app ](#attributes-recipes-haproxy-nodejs-app) | [maxcon\$1factor\$1nodejs\$1app\$1ssl ](#attributes-recipes-haproxy-nodejs-ssl) | | [maxcon\$1factor\$1php\$1app ](#attributes-recipes-haproxy-php-app) | [maxcon\$1factor\$1php\$1app\$1ssl ](#attributes-recipes-haproxy-php-ssl) | [maxcon\$1factor\$1rails\$1app ](#attributes-recipes-haproxy-rails-app) | | [maxcon\$1factor\$1rails\$1app\$1ssl ](#attributes-recipes-haproxy-rails-ssl) | [maxcon\$1factor\$1static ](#attributes-recipes-haproxy-static-app) | [maxcon\$1factor\$1static\$1ssl ](#attributes-recipes-haproxy-static-ssl) | | [retries ](#attributes-recipes-haproxy-retries) | [server\$1timeout ](#attributes-recipes-haproxy-server-timeout) | [stats\$1url ](#attributes-recipes-haproxy-stats-url) | | [stats\$1user ](#attributes-recipes-haproxy-user) | | | **balance ** 負載平衡器用來選取伺服器的演算法 (字串)。預設值為 `'roundrobin'`。其他選項為： + 'static-rr' + 'leastconn' + 'source' + 'uri' + 'url\$1param' + 'hdr(name)' + 'rdp-cookie' + 'rdp-cookie(name)' 如需這些引數的詳細資訊，請參閱 [balance](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)。 ``` node[:haproxy][:balance] ``` **check\$1interval ** 運作狀態檢查時間間隔 (字串)。預設值為 `'10s'`。 ``` node[:haproxy][:check_interval] ``` **client\$1timeout ** 用戶端可處於非作用中狀態的時間上限 (字串)。預設值為 `'60s'`。 ``` node[:haproxy][:client_timeout] ``` **connect\$1timeout ** HAProxy 會等待伺服器連線嘗試成功的時間上限 (字串)。預設值為 `'10s'`。 ``` node[:haproxy][:connect_timeout] ``` **default\$1max\$1connections ** 預設的連線數目上限 (字串)。預設值為 `'80000'`。 ``` node[:haproxy][:default_max_connections] ``` **global\$1max\$1connections ** 連線數目上限 (字串)。預設值為 `'80000'`。 ``` node[:haproxy][:global_max_connections] ``` **health\$1check\$1method ** 運作狀態檢查方法 (字串)。預設值為 `'OPTIONS'`。 ``` node[:haproxy][:health_check_method] ``` **health\$1check\$1url ** 用來檢查伺服器運作狀態的 URL 路徑 (字串)。預設值為 `'/'`。 ``` node[:haproxy][:health_check_url ] ``` **queue\$1timeout ** 可用連線的等待時間上限 (字串)。預設值為 `'120s'`。 ``` node[:haproxy][:queue_timeout] ``` **http\$1request\$1timeout ** HAProxy 會等待 HTTP 請求完成的時間上限 (字串)。預設值為 `'30s'`。 ``` node[:haproxy][:http_request_timeout] ``` **retries ** 伺服器連線失敗之後的重試次數 (字串)。預設值為 `'3'`。 ``` node[:haproxy][:retries] ``` **server\$1timeout ** 用戶端可處於非作用中狀態的時間上限 (字串)。預設值為 `'60s'`。 ``` node[:haproxy][:server_timeout] ``` **stats\$1url ** 統計資料頁面的 URL 路徑 (字串)。預設值為 `'/haproxy?stats'`。 ``` node[:haproxy][:stats_url] ``` **stats\$1user ** 統計資料頁面使用者名稱 (字串)。預設值為 `'opsworks'`。 ``` node[:haproxy][:stats_user] ``` `maxcon` 屬性代表載入因數乘數，用來運算 HAProxy 允許[後端](attributes-json-opsworks-instance.md#attributes-json-opsworks-instance-backends)的連線數目上限。例如，假設您在`backend`值為 4 的小型執行個體上有一個 Rails 應用程式伺服器，這表示 OpsWorks Stacks 將為該執行個體設定四個 Rails 程序。如果您使用預設 `maxcon_factor_rails_app` 值 7，HAProxy 會處理 Rails 伺服器的 28 (4\$1 7) 個連線。 **maxcon\$1factor\$1nodejs\$1app ** Node.js 應用程式伺服器的 maxcon 因數 (數值)。預設值為 `10`。 ``` node[:haproxy][:maxcon_factor_nodejs_app] ``` **maxcon\$1factor\$1nodejs\$1app\$1ssl ** 使用 SSL 之 Node.js 應用程式伺服器的 maxcon 因數 (數值)。預設值為 `10`。 ``` node[:haproxy][:maxcon_factor_nodejs_app_ssl] ``` **maxcon\$1factor\$1php\$1app ** PHP 應用程式伺服器的 maxcon 因數 (數值)。預設值為 `10`。 ``` node[:haproxy][:maxcon_factor_php_app] ``` **maxcon\$1factor\$1php\$1app\$1ssl ** 使用 SSL 之 PHP 應用程式伺服器的 maxcon 因數 (數值)。預設值為 `10`。 ``` node[:haproxy][:maxcon_factor_php_app_ssl] ``` **maxcon\$1factor\$1rails\$1app ** Rails 應用程式伺服器的 maxcon 因數 (數值)。預設值為 `7`。 ``` node[:haproxy][:maxcon_factor_rails_app] ``` **maxcon\$1factor\$1rails\$1app\$1ssl ** 使用 SSL 之 Rails 應用程式伺服器的 maxcon 因數 (數值)。預設值為 `7`。 ``` node[:haproxy][:maxcon_factor_rails_app_ssl] ``` **maxcon\$1factor\$1static ** 靜態 Web 伺服器的 maxcon 因數 (數值)。預設值為 `15`。 ``` node[:haproxy][:maxcon_factor_static] ``` **maxcon\$1factor\$1static\$1ssl ** 使用 SSL 之靜態 Web 伺服器的 maxcon 因數 (數值)。預設值為 `15`。 ``` node[:haproxy][:maxcon_factor_static_ssl] ``` # memcached 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`memcached` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/memcached/attributes/default.rb)指定 [Memcached](http://memcached.org/) 伺服器組態。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [memory ](#attributes-recipes-mem-memory) | [max\$1connections ](#attributes-recipes-mem-max) | [pid\$1file ](#attributes-recipes-mem-pid) | | [port ](#attributes-recipes-mem-port) | [start\$1command ](#attributes-recipes-mem-start) | [stop\$1command ](#attributes-recipes-mem-stop) | | [user ](#attributes-recipes-mem-user) | | | **memory ** 可使用的記憶體上限，以 MB 為單位 (數值)。預設值為 `512`。 ``` node[:memcached][:memory] ``` **max\$1connections ** 連線數目上限 (字串)。預設值為 `'4096'`。 ``` node[:memcached][:max_connections] ``` **pid\$1file ** 包含協助程式之處理序 ID 的檔案 (字串)。預設值為 `'var/run/memcached.pid'`。 ``` node[:memcached][:pid_file] ``` **port ** 要接聽的連接埠 (數值)。預設值為 `11211`。 ``` node[:memcached][:port] ``` **start\$1command ** 啟動命令 (字串)。預設值為 `'/etc/init.d/memcached start'`。 ``` node[:memcached][:start_command] ``` **stop\$1command ** 停止命令 (字串)。預設值為 `'/etc/init.d/memcached stop'`。 ``` node[:memcached][:stop_command] ``` **user ** 使用者 (字串)。預設值為 `'nobody'`。 ``` node[:memcached][:user] ``` # mysql 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`mysql` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/mysql/attributes/server.rb)指定 [MySQL](http://www.mysql.com/) 主組態。如需詳細資訊，請參閱 [Server System Variables](http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [basedir ](#attributes-recipes-mysql-basedir) | [bind\$1address ](#attributes-recipes-mysql-bind) | [用戶端 ](#attributes-recipes-mysql-clients) | | [conf\$1dir ](#attributes-recipes-mysql-conf) | [confd\$1dir ](#attributes-recipes-mysql-confd) | [datadir ](#attributes-recipes-mysql-datadir) | | [grants\$1path ](#attributes-recipes-mysql-grants) | [mysql\$1bin ](#attributes-recipes-mysql-bin) | [mysqladmin\$1bin ](#attributes-recipes-mysql-admin-bin) | | [pid\$1file ](#attributes-recipes-mysql-pid) | [port ](#attributes-recipes-mysql-port) | [root\$1group ](#attributes-recipes-mysql-group) | | [server\$1root\$1password ](#attributes-recipes-mysql-pwd) | [socket ](#attributes-recipes-mysql-socket) | [tunable 屬性](#attributes-recipes-mysql-tunable) | **basedir ** 基本目錄 (字串)。預設值為 `'/usr'`。 ``` node[:mysql][:basedir] ``` **bind\$1address ** MySQL 接聽的地址 (字串)。預設值為 `'0.0.0.0'`。 ``` node[:mysql][:bind_address] ``` **用戶端 ** 用戶端清單 (字串清單)。 ``` node[:mysql][:clients] ``` **conf\$1dir ** 包含組態檔案的目錄 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'/etc'` + Ubuntu：`'/etc/mysql'` ``` node[:mysql][:conf_dir] ``` **confd\$1dir ** 包含其他組態檔案的目錄 (字串)。預設值為 `'/etc/mysql/conf.d'`。 ``` node[:mysql][:confd_dir] ``` **datadir ** 資料目錄 (字串)。預設值為 `'/var/lib/mysql'`。 ``` node[:mysql][:datadir] ``` **grants\$1path ** 授予資料表位置 (字串)。預設值為 `'/etc/mysql_grants.sql'`。 ``` node[:mysql][:grants_path] ``` **mysql\$1bin ** mysql 二進位檔位置 (字串)。預設值為 `'/usr/bin/mysql'`。 ``` node[:mysql][:mysql_bin] ``` **mysqladmin\$1bin ** mysqladmin 位置 (字串)。預設值為 `'/usr/bin/mysqladmin'`。 ``` node[:mysql][:mysqladmin_bin] ``` **pid\$1file ** 包含協助程式之處理序 ID 的檔案 (字串)。預設值為 `'/var/run/mysqld/mysqld.pid'`。 ``` node[:mysql][:pid_file] ``` **port ** 伺服器接聽的連接埠 (數值)。預設值為 `3306`。 ``` node[:mysql][:port] ``` **root\$1group ** 根群組 (字串)。預設值為 `'root'`。 ``` node[:mysql][:root_group] ``` **server\$1root\$1password ** 伺服器的根密碼 (字串)。預設值為隨機產生。 ``` node[:mysql][:server_root_password] ``` **socket ** 通訊端檔案的位置 (字串)。預設值為 `'/var/lib/mysql/mysql.sock'`。預設值如下： + Amazon Linux 和 RHEL：`'/var/lib/mysql/mysql.sock'` + Ubuntu：`'/var/run/mysqld/mysqld.sock'` ``` node[:mysql][:socket] ``` **tunable 屬性** tunable 屬性用於效能調校。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/attributes-recipes-mysql.html) **back\$1log ** 未完成的請求數目上限 (字串)。預設值為 `'128'`。 ``` node[:mysql][:tunable][:back_log] ``` **innodb\$1additional\$1mem\$1pool\$1size ** [Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html) 用來存放內部資料結構的集區大小 (字串)。預設值為 `'20M'`。 ``` node[:mysql][:tunable][:innodb_additional_mem_pool_size] ``` **innodb\$1buffer\$1pool\$1size ** [Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html) 緩衝集區大小 (字串)。屬性值由 Stacks OpsWorks 設定，並取決於執行個體類型，但您可以使用自訂 JSON 或自訂屬性檔案[來覆寫](workingcookbook-attributes.md)它。 ``` node[:mysql][:tunable][:innodb_buffer_pool_size] ``` **innodb\$1flush\$1log\$1at\$1trx\$1commit ** [Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html) 排清日誌緩衝區的頻率 (字串)。預設值為 `'2'`。如需詳細資訊，請參閱 [innodb\$1flush\$1log\$1at\$1trx\$1commit](http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit)。 ``` node[:mysql][:tunable][:innodb_flush_log_at_trx_commit] ``` **innodb\$1lock\$1wait\$1timeout ** [Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html) 交易等待資料列鎖定的時間上限，以秒為單位 (字串)。預設值為 `'50'`。 ``` node[:mysql][:tunable][:innodb_lock_wait_timeout] ``` **key\$1buffer ** 索引緩衝區大小 (字串)。預設值為 `'250M'`。 ``` node[:mysql][:tunable][:key_buffer] ``` **log\$1slow\$1queries ** 慢速查詢日誌檔案的位置 (字串)。預設值為 `'/var/log/mysql/mysql-slow.log'`。 ``` node[:mysql][:tunable][:log_slow_queries] ``` **長查詢時間 ** 指定查詢為長時間查詢所需的時間，以秒為單位 (字串)。預設值為 `'1'`。 ``` node[:mysql][:tunable][:long_query_time] ``` **max\$1allowed\$1packet ** 允許的封包大小上限 (字串)。預設值為 `'32M'`。 ``` node[:mysql][:tunable][:max_allowed_packet] ``` **max\$1connections ** 同時用戶端連線數目上限 (字串)。預設值為 `'2048'`。 ``` node[:mysql][:tunable][:max_connections] ``` **max\$1heap\$1table\$1size ** 使用者建立的 `MEMORY` 資料表大小上限 (字串)。預設值為 `'32M'`。 ``` node[:mysql][:tunable][:max_heap_table_size] ``` **net\$1read\$1timeout ** 等待更多連線資料的時間，以秒為單位 (字串)。預設值為 `'30'`。 ``` node[:mysql][:tunable][:net_read_timeout] ``` **net\$1write\$1timeout ** 等待區塊寫入連線的時間，以秒為單位 (字串)。預設值為 `'30'`。 ``` node[:mysql][:tunable][:net_write_timeout] ``` **query\$1cache\$1limit ** 個別快取查詢大小上限 (字串)。預設值為 `'2M'`。 ``` node[:mysql][:tunable][:query_cache_limit] ``` **query\$1cache\$1size ** 查詢快取大小 (字串)。預設值為 `'128M'`。 ``` node[:mysql][:tunable][:query_cache_size] ``` **query\$1cache\$1type ** 查詢快取類型 (字串)。可能的值如下： + `'0'`：不快取或擷取快取的資料。 + `'1'`：不以 `SELECT SQL_NO_CACHE` 開頭的快取陳述式。 + `'2'`：以 `SELECT SQL_CACHE` 開頭的快取陳述式。預設值為 `'1'`。 ``` node[:mysql][:tunable][:query_cache_type] ``` **thread\$1cache\$1size ** 快取以重複使用的用戶端執行緒數目 (字串)。預設值為 `'8'`。 ``` node[:mysql][:tunable][:thread_cache_size] ``` **thread\$1stack ** 每個執行緒的堆疊大小 (字串)。預設值為 `'192K'`。 ``` node[:mysql][:tunable][:thread_stack] ``` **wait\$1timeout ** 等待非互動式連線的時間，以秒為單位。預設值為 `'180'` (字串)。 ``` node[:mysql][:tunable][:wait_timeout] ``` **table\$1cache ** 開啟的資料表數目 (字串)。預設值為 `'2048'`。 ``` node[:mysql][:tunable][:table_cache] ``` # nginx 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`nginx` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/nginx/attributes/nginx.rb)指定 [Nginx](http://wiki.nginx.org/Main) 組態。如需詳細資訊，請參閱 [Directive Index](http://wiki.nginx.org/DirectiveIndex)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [binary ](#attributes-recipes-nginx-binary) | [dir ](#attributes-recipes-nginx-dir) | [gzip ](#attributes-recipes-nginx-gzip) | | [gzip\$1comp\$1level ](#attributes-recipes-nginx-gzip-comp) | [gzip\$1disable ](#attributes-recipes-nginx-gzip-disable) | [gzip\$1http\$1version ](#attributes-recipes-nginx-gzip-http) | | [gzip\$1proxied ](#attributes-recipes-nginx-gzip-proxied) | [gzip\$1static ](#attributes-recipes-nginx-gzip-static) | [gzip\$1types ](#attributes-recipes-nginx-gzip-types) | | [gzip\$1vary ](#attributes-recipes-nginx-gzip-vary) | [keepalive ](#attributes-recipes-nginx-keepalive) | [keepalive\$1timeout ](#attributes-recipes-nginx-keepalive-timeout) | | [log\$1dir ](#attributes-recipes-nginx-log) | [user ](#attributes-recipes-nginx-user) | [server\$1names\$1hash\$1bucket\$1size](#attributes-recipes-nginx-worker-hash) | | [worker\$1processes ](#attributes-recipes-nginx-worker-processes) | [worker\$1connections ](#attributes-recipes-nginx-worker-connections) | | **binary ** Nginx 二進位檔的位置 (字串)。預設值為 `'/usr/sbin/nginx'`。 ``` node[:nginx][:binary] ``` **dir ** 檔案 (例如組態檔案) 的位置 (字串)。預設值為 `'/etc/nginx'`。 ``` node[:nginx][:dir] ``` **gzip ** 是否啟用 gzip 壓縮 (字串)。可能的值為 `'on'` 和 `'off'`。預設值為 `'on'`。壓縮可能會引發安全風險。若要完全停用壓縮，請設定此屬性如下： ``` node[:nginx][:gzip] = 'off' ``` ``` node[:nginx][:gzip] ``` **gzip\$1comp\$1level ** 壓縮層級的範圍介於 1–9 之間，其中 1 對應於最小壓縮（字串）。預設值為 `'2'`。 ``` node[:nginx][:gzip_comp_level] ``` **gzip\$1disable ** 停用指定使用者代理程式的 gzip 壓縮 (字串)。此值為規則表達式，預設值為 `'MSIE [1-6].(?!.*SV1)'`。 ``` node[:nginx][:gzip_disable] ``` **gzip\$1http\$1version ** 啟用指定 HTTP 版本的 gzip 壓縮 (字串)。預設值為 `'1.0'`。 ``` node[:nginx][:gzip_http_version] ``` **gzip\$1proxied ** 是否及如何壓縮代理請求的回應，可接受下列其中一個值 (字串)： + `'off'`：不壓縮代理請求 + `'expired'`：Expire 標頭防止快取時壓縮 + `'no-cache'`：Cache-Control 標頭設為 "no-cache" 時壓縮 + `'no-store'`：Cache-Control 標頭設為 "no-store" 時壓縮 + `'private'`：Cache-Control 標頭設為 "private" 時壓縮 + `'no_last_modified'`：未設定 Last-Modified 時壓縮 + `'no_etag'`：請求缺少 ETag 標頭時壓縮 + `'auth'`：請求包含 Authorization 標頭時壓縮 + `'any'`：壓縮所有代理請求預設值為 `'any'`。 ``` node[:nginx][:gzip_proxied] ``` **gzip\$1static ** 是否啟用 gzip 靜態模組 (字串)。可能的值為 `'on'` 和 `'off'`。預設值為 `'on'`。 ``` node[:nginx][:gzip_static] ``` **gzip\$1types ** 要壓縮的 MIME 類型清單 (字串清單)。預設值為 `['text/plain', 'text/html', 'text/css', 'application/x-javascript', 'text/xml', 'application/xml', 'application/xml+rss', 'text/javascript']`。 ``` node[:nginx][:gzip_types] ``` **gzip\$1vary ** 是否啟用 `Vary:Accept-Encoding ` 回應標頭 (字串)。可能的值為 `'on'` 和 `'off'`。預設值為 `'on'`。 ``` node[:nginx][:gzip_vary] ``` **keepalive ** 是否啟用持續連線 (字串)。可能的值為 `'on'` 和 `'off'`。預設值為 `'on'`。 ``` node[:nginx][:keepalive] ``` **keepalive\$1timeout ** 持續連線保持開啟的時間上限，以秒為單位 (數值)。預設值為 `65`。 ``` node[:nginx][:keepalive_timeout] ``` **log\$1dir ** 日誌檔案的位置 (字串)。預設值為 `'/var/log/nginx'`。 ``` node[:nginx][:log_dir] ``` **user ** 使用者 (字串)。預設值如下： + Amazon Linux 和 RHEL：`'www-data'` + Ubuntu：`'nginx'` ``` node[:nginx][:user] ``` **server\$1names\$1hash\$1bucket\$1size** 伺服器名稱雜湊表的儲存貯體大小，可設為 `32`、`64` 或 `128` (數值)。預設值為 `64`。 ``` node[:nginx][:server_names_hash_bucket_size] ``` **worker\$1processes ** 工作者處理序數目 (數值)。預設值為 `10`。 ``` node[:nginx][:worker_processes] ``` **worker\$1connections ** 工作者連線數目上限 (數值)。預設值為 `1024`。用戶端數目上限會設為 `worker_processes * worker_connections`。 ``` node[:nginx][:worker_connections] ``` # opsworks\$1berkshelf 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`opsworks_berkshelf` 屬性](https://github.com/aws/opsworks-cookbooks/blob/master-chef-11.10/opsworks_berkshelf/attributes/default.rb)指定 Berkshelf 組態。如需詳細資訊，請參閱 [Berkshelf](http://berkshelf.com/)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **偵錯** 是否在 Chef 日誌中包含 Berkshelf 除錯資訊 (布林值)。預設值為 `false`。 ``` node['opsworks_berkshelf]['debug'] ``` # opsworks\$1java 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`opsworks_java` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/opsworks_java/attributes/default.rb)指定 [Tomcat](http://tomcat.apache.org/) 伺服器組態。如需詳細資訊，請參閱 [Apache Tomcat Configuration Reference](http://tomcat.apache.org/tomcat-5.5-doc/config/)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [datasources ](#attributes-recipes-java-datasources) | [java\$1app\$1server\$1version ](#attributes-recipes-java-server-version) | [java\$1shared\$1lib\$1dir ](#attributes-recipes-java-shared-lib) | | [jvm\$1pkg 屬性 ](#attributes-recipes-java-pkg) | [custom\$1pkg\$1location\$1url\$1debian ](#attributes-recipes-java-pkg-debian) | [java\$1home\$1basedir ](#attributes-recipes-java-pkg-basedir) | | [custom\$1pkg\$1location\$1url\$1rhel ](#attributes-recipes-java-pkg-rhel) | [use\$1custom\$1pkg\$1location ](#attributes-recipes-java-pkg-use) | [jvm\$1options ](#attributes-recipes-java-jvm-options) | | [jvm\$1version ](#attributes-recipes-java-jvm-version) | [tomcat 屬性](#attributes-recipes-java-tomcat) | | **datasources ** 定義 JNDI 資源名稱的一組屬性 (字串)。如需如何使用此屬性的詳細資訊，請參閱[使用後端資料庫部署 JSP 應用程式](layers-java-deploy.md#layers-java-deploy-jsp-db)。預設值是空的雜湊，可填入應用程式簡短名稱與 JNDI 名稱之間的自訂映射。如需詳細資訊，請參閱[使用後端資料庫部署 JSP 應用程式](layers-java-deploy.md#layers-java-deploy-jsp-db)。 ``` node['opsworks_java']['datasources'] ``` **java\$1app\$1server\$1version ** Java 應用程式伺服器版本 (數值)。預設值為 `7`。您可以覆寫此屬性來指定版本 6。如果您安裝非預設 JDK，則忽略此屬性。 ``` node['opsworks_java']['java_app_server_version'] ``` **java\$1shared\$1lib\$1dir ** Java 共享程式庫的目錄 (字串)。預設值為 `/usr/share/java`。 ``` node['opsworks_java']['java_shared_lib_dir'] ``` **jvm\$1pkg 屬性 ** 您可以覆寫來安裝非預設 JDK 的一組屬性。 **use\$1custom\$1pkg\$1location ** 是否安裝自訂 JDK 而不是 OpenJDK (布林值)。預設值為 `false`。 ``` node['opsworks_java']['jvm_pkg']['use_custom_pkg_location'] ``` **custom\$1pkg\$1location\$1url\$1debian ** 要在 Ubuntu 執行個體上安裝 JDK 套件的位置 (字串)。預設值為 `'http://aws.amazon.com/'`，這只是沒有適當意義的初始化值。如果您想要安裝非預設 JDK，您必須覆寫此屬性並將其設為適當的 URL。 ``` node['opsworks_java']['jvm_pkg']['custom_pkg_location_url_debian'] ``` **custom\$1pkg\$1location\$1url\$1rhel ** 要在 Amazon Linux 和 RHEL 執行個體上安裝 JDK 套件的位置 (字串)。預設值為 `'http://aws.amazon.com/'`，這只是沒有適當意義的初始化值。如果您想要安裝非預設 JDK，您必須覆寫此屬性並將其設為適當的 URL。 ``` node['opsworks_java']['jvm_pkg']['custom_pkg_location_url_rhel'] ``` **java\$1home\$1basedir ** 要解壓縮 JDK 套件的目標目錄 (字串)。預設值為 `/usr/local`。您不需要為 RPM 套件指定此設定；這些套件會包含完整的目錄結構。 ``` node['opsworks_java']['jvm_pkg']['java_home_basedir'] ``` **jvm\$1options ** JVM 命令列選項，可讓您指定堆積大小等設定 (字串)。一組常見選項為 `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`。預設值為沒有選項。 ``` node['opsworks_java']['jvm_options'] ``` **jvm\$1version ** OpenJDK 版本 (數值)。預設值為 `7`。您可以覆寫此屬性來指定 OpenJDK 6 版。如果您安裝非預設 JDK，則忽略此屬性。 ``` node['opsworks_java']['jvm_version'] ``` **tomcat 屬性** 您可以覆寫來安裝預設 Tomcat 組態的一組屬性。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/attributes-recipes-java.html) **ajp\$1port ** AJP 連接埠 (數值)。預設值為 `8009`。 ``` node['opsworks_java']['tomcat]['ajp_port'] ``` **apache\$1tomcat\$1bind\$1mod ** 代理模組 (字串)。預設值為 `proxy_http`。您可以覆寫此屬性來指定 AJP 代理模組 `proxy_ajp`。 ``` node['opsworks_java']['tomcat]['apache_tomcat_bind_mod'] ``` **apache\$1tomcat\$1bind\$1path ** Apache-Tomcat 繫結路徑 (字串)。預設值為 `/`。您不應該覆寫此屬性；變更繫結路徑可能會導致應用程式停止運作。 ``` node['opsworks_java']['tomcat]['apache_tomcat_bind_path'] ``` **auto\$1deploy ** 是否自動部署 (布林值)。預設值為 `true`。 ``` node['opsworks_java']['tomcat]['auto_deploy'] ``` **connection\$1timeout ** 連線逾時，以毫秒為單位 (數值)。預設值為 `20000` (20 秒)。 ``` node['opsworks_java']['tomcat]['connection_timeout'] ``` **mysql\$1connector\$1jar ** MySQL 連接器程式庫的 JAR 檔案 (字串)。預設值為 `mysql-connector-java.jar`。 ``` node['opsworks_java']['tomcat]['mysql_connector_jar'] ``` **port ** 標準連接埠 (數值)。預設值為 `8080`。 ``` node['opsworks_java']['tomcat]['port'] ``` **secure\$1port ** 安全連接埠 (數值)。預設值為 `8443`。 ``` node['opsworks_java']['tomcat]['secure_port'] ``` **shutdown\$1port ** 關機連接埠 (數值)。預設值為 `8005`。 ``` node['opsworks_java']['tomcat]['shutdown_port'] ``` **threadpool\$1max\$1threads ** 執行緒集區中的執行緒數目上限 (數值)。預設值為 `150`。 ``` node['opsworks_java']['tomcat]['threadpool_max_threads'] ``` **threadpool\$1min\$1spare\$1threads ** 執行緒集區中的備用執行緒數目下限 (數值)。預設值為 `4`。 ``` node['opsworks_java']['tomcat]['threadpool_min_spare_threads'] ``` **unpack\$1wars ** 是否解壓縮 WAR 檔案 (布林值)。預設值為 `true`。 ``` node['opsworks_java']['tomcat]['unpack_wars'] ``` **uri\$1encoding ** URI 編碼 (字串)。預設值為 `UTF-8`。 ``` node['opsworks_java']['tomcat]['uri_encoding'] ``` **use\$1ssl\$1connector ** 是否使用 SSL 連接器 (布林值)。預設值為 `false`。 ``` node['opsworks_java']['tomcat]['use_ssl_connector'] ``` **use\$1threadpool ** 是否使用執行緒集區 (布林值)。預設值為 `false`。 ``` node['opsworks_java']['tomcat]['use_threadpool'] ``` **userdatabase\$1pathname ** 使用者資料庫路徑名稱 (字串)。預設值為 `conf/tomcat-users.xml`。 ``` node['opsworks_java']['tomcat]['userdatabase_pathname'] ``` # passenger\$1apache2 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`passenger_apache2` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/passenger_apache2/attributes/passenger.rb)指定 [Phusion Passenger](https://www.phusionpassenger.com/) 組態。如需詳細資訊，請參閱 [Phusion Passenger users guide, Apache version](http://www.modrails.com/documentation/Users%20guide%20Apache.html)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [friendly\$1error\$1pages](#attributes-recipes-passenger-friendly-error-pages) | [gem\$1bin ](#attributes-recipes-passenger-gem-bin) | [gems\$1path](#attributes-recipes-passenger-gems-path) | | [high\$1performance\$1mode ](#attributes-recipes-passenger-perf) | [root\$1path ](#attributes-recipes-passenger-root) | [max\$1instances\$1per\$1app ](#attributes-recipes-passenger-instances) | | [max\$1pool\$1size ](#attributes-recipes-passenger-max-pool) | [max\$1requests](#attributes-recipes-passenger-max-requests) | [module\$1path ](#attributes-recipes-passenger-mod_path) | | [pool\$1idle\$1time ](#attributes-recipes-passenger-pool-idle) | [rails\$1app\$1spawner\$1idle\$1time ](#attributes-recipes-passenger-rails-app) | [rails\$1framework\$1spawner\$1idle\$1time ](#attributes-recipes-passenger-rails-framework) | | [rails\$1spawn\$1method ](#attributes-recipes-passenger-rails-spawn) | [ruby\$1bin ](#attributes-recipes-passenger-ruby-bin) | [ruby\$1wrapper\$1bin ](#attributes-recipes-passenger-ruby-wrapper) | | [stat\$1throttle\$1rate ](#attributes-recipes-passenger-throttle) | [version](#attributes-recipes-passenger-version) | | **friendly\$1error\$1pages** 是否在應用程式無法啟動時顯示易用的錯誤頁面 (字串)。此屬性可設為 'on' 或 'off'；預設值為 'off'。 ``` node[:passenger][:friendly_error_pages] ``` **gem\$1bin ** Gem 二進位檔的位置 (字串)。預設值為 `'/usr/local/bin/gem'`。 ``` node[:passenger][:gem_bin] ``` **gems\$1path** Gem 路徑 (字串)。預設值視 Ruby 版本而定。例如： + Ruby 1.8 版：`'/usr/local/lib/ruby/gems/1.8/gems'` + Ruby 1.9 版：`'/usr/local/lib/ruby/gems/1.9.1/gems'` ``` node[:passenger][:gems_path] ``` **high\$1performance\$1mode ** 是否使用 Passenger 的高效能模式 (字串)。可能的值為 `'on'` 和 `'off'`。預設值為 `'off'`。 ``` node[:passenger][:high_performance_mode ] ``` **root\$1path ** Passenger 根目錄 (字串)。預設值視 Ruby 和 Passenger 版本而定。在 Chef 語法中，此值為 `"#{node[:passenger][:gems_path]}/passenger-#{passenger[:version]}"`。 ``` node[:passenger][:root_path] ``` **max\$1instances\$1per\$1app ** 每個應用程式的應用程式處理序數目上限 (數值)。預設值為 `0`。如需詳細資訊，請參閱 [PassengerMaxInstancesPerApp](http://www.modrails.com/documentation/Users%20guide%20Apache.html#_passengermaxinstancesperapp_lt_integer_gt)。 ``` node[:passenger][:max_instances_per_app] ``` **max\$1pool\$1size ** 應用程式處理器數目上限 (數值)。預設值為 `8`。如需詳細資訊，請參閱 [PassengerMaxPoolSize](http://www.modrails.com/documentation/Users%20guide%20Apache.html#_passengermaxpoolsize_lt_integer_gt)。 ``` node[:passenger][:max_pool_size] ``` **max\$1requests** 請求數目上限 (數值)。預設值為 `0`。 ``` node[:passenger][:max_requests] ``` **module\$1path ** 模組路徑 (字串)。預設值如下： + Amazon Linux 和 RHEL：`"#{node['apache']['libexecdir']}/mod_passenger.so"` + Ubuntu：`"#{passenger[:root\$1path]}/ext/apache2/mod_passenger.so"` ``` node[:passenger][:module_path] ``` **pool\$1idle\$1time ** 應用程式處理序可處於閒置狀態的時間上限，以秒為單位 (數值)。預設值為 `14400` (4 小時)。如需詳細資訊，請參閱 [PassengerPoolIdleTime](http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerPoolIdleTime)。 ``` node[:passenger][:pool_idle_time] ``` **rails\$1app\$1spawner\$1idle\$1time ** Rails 應用程式 spawner 的閒置時間上限 (數值)。如果此屬性設為零，應用程式 spawner 不會逾時。預設值為 `0`。如需詳細資訊，請參閱 [Spawning Methods Explained](http://www.modrails.com/documentation/Users%20guide%20Apache.html#spawning_methods_explained)。 ``` node[:passenger][:rails_app_spawner_idle_time] ``` **rails\$1framework\$1spawner\$1idle\$1time ** Rails 架構 spawner 的閒置時間上限 (數值)。如果此屬性設為零，架構 spawner 不會逾時。預設值為 `0`。如需詳細資訊，請參閱 [Spawning Methods Explained](http://www.modrails.com/documentation/Users%20guide%20Apache.html#spawning_methods_explained)。 ``` node[:passenger][:rails_framework_spawner_idle_time] ``` **rails\$1spawn\$1method ** Rails 繁衍方法 (字串)。預設值為 `'smart-lv2'`。如需詳細資訊，請參閱 [Spawning Methods Explained](http://www.modrails.com/documentation/Users%20guide%20Apache.html#spawning_methods_explained)。 ``` node[:passenger][:rails_spawn_method] ``` **ruby\$1bin ** Ruby 二進位檔的位置 (字串)。預設值為 `'/usr/local/bin/ruby'`。 ``` node[:passenger][:ruby_bin] ``` **ruby\$1wrapper\$1bin ** Ruby 包裝函式指令碼的位置 (字串)。預設值為 `'/usr/local/bin/ruby_gc_wrapper.sh'`。 ``` node[:passenger][:ruby_wrapper_bin] ``` **stat\$1throttle\$1rate ** Passenger 執行檔案系統檢查的速率 (數值)。預設值為 `5`，這表示最多每 5 秒執行檢查一次。如需詳細資訊，請參閱 [PassengerStatThrottleRate](http://www.modrails.com/documentation/Users%20guide%20Apache.html#_passengerstatthrottlerate_lt_integer_gt)。 ``` node[:passenger][:stat_throttle_rate] ``` **version** 版本 (字串)。預設值為 `'3.0.9'`。 ``` node[:passenger][:version] ``` # ruby 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`ruby` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/ruby/attributes/ruby.rb)指定應用程式使用的 Ruby 版本。請注意，屬性用量會隨著引進 Ruby 2.1 中的語意版本控制而產生變更。如需如何指定版本的詳細資訊，包括範例，請參閱 [Ruby 版本](workingcookbook-ruby.md)。如需 OpsWorks Stacks 如何決定 Ruby 版本的完整詳細資訊，請參閱內建屬性檔案 [ruby.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/ruby/attributes/ruby.rb)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **full\$1version** 完整版本號碼 (字串)。您不應該覆寫此屬性。請改用 [[:opsworks][:ruby\$1version]](attributes-json-opsworks-other.md#attributes-json-opsworks-ruby-version) 和適當的修補程式版本屬性來指定版本。 ``` [:ruby][:full_version] ``` **major\$1version** 主要版本號碼 (字串)。您不應該覆寫此屬性。請改用 [[:opsworks][:ruby\$1version]](attributes-json-opsworks-other.md#attributes-json-opsworks-ruby-version) 來指定主要版本。 ``` [:ruby][:major_version] ``` **minor\$1version** 次要版本號碼 (字串)。您不應該覆寫此屬性。請改用 [[:opsworks][:ruby\$1version]](attributes-json-opsworks-other.md#attributes-json-opsworks-ruby-version) 來指定次要版本。 ``` [:ruby][:minor_version] ``` **patch** 修補程式等級 (字串)。此屬性適用於 Ruby 2.0.0 版及舊版。對於更新版本的 Ruby，請使用 `patch_version` 屬性。 ``` [:ruby][:patch] ``` 修補程式號碼前面必須加上 `p`。例如，您會使用下列自訂 JSON 來指定修補程式等級 484。 ``` { "ruby":{"patch":"p484"} } ``` **patch\$1version** 修補程式號碼 (字串)。此屬性適用於 Ruby 2.1 版及更新版本。對於舊版的 Ruby，請使用 `patch` 屬性。 ``` [:ruby][:patch_version] ``` **pkgrelease** 套件版次號碼 (字串)。 ``` [:ruby][:pkgrelease] ``` # unicorn 屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 這些屬性僅適用於 Linux 堆疊。 [`unicorn` 屬性](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/unicorn/attributes/default.rb)指定 [Unicorn](http://unicorn.bogomips.org/) 組態。如需詳細資訊，請參閱 [Unicorn::Configurator](http://unicorn.bogomips.org/Unicorn/Configurator.html)。如需如何覆寫內建屬性以指定自訂值的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 **** | | | | | --- |--- |--- | | [accept\$1filter](#attributes-recipes-unicorn-accept) | [backlog](#attributes-recipes-unicorn-backlog) | [延遲](#attributes-recipes-unicorn-delay) | | [tcp\$1nodelay](#attributes-recipes-unicorn-nodelay) | [tcp\$1nopush](#attributes-recipes-unicorn-nopush) | [preload\$1app](#attributes-recipes-unicorn-preload) | | [timeout](#attributes-recipes-unicorn-timeout) | [tries](#attributes-recipes-unicorn-tries) | [version](#attributes-recipes-unicorn-version) | | [worker\$1processes](#attributes-recipes-unicorn-worker) | | | **accept\$1filter** 接受篩選條件 `'httpready'` 或 `'dataready'` (字串)。預設值為 `'httpready'`。 ``` node[:unicorn][:accept_filter] ``` **backlog** 佇列可保留的請求數目上限 (數值)。預設值為 `1024`。 ``` node[:unicorn][:backlog] ``` **延遲** 等待重試繫結通訊端的時間，以秒為單位 (數值)。預設值為 `0.5`。 ``` node[:unicorn][:delay] ``` **preload\$1app** 是否預先載入應用程式，再分支處理工作者處理序 (布林值)。預設值為 `true`。 ``` node[:unicorn][:preload_app] ``` **tcp\$1nodelay** 是否停用 TCP 通訊端的 Nagle 演算法 (布林值)。預設值為 `true`。 ``` node[:unicorn][:tcp_nodelay] ``` **tcp\$1nopush** 是否啟用 TCP\$1CORK (布林值)。預設值為 `false`。 ``` node[:unicorn][:tcp_nopush] ``` **timeout** 工作者可用於每個請求的時間上限，以秒為單位 (數值)。超過逾時值的工作者會終止。預設值為 `60`。 ``` node[:unicorn][:timeout] ``` **tries** 重試繫結至通訊端的次數上限 (數值)。預設值為 `5`。 ``` node[:unicorn][:tries] ``` **version** Unicorn 版本 (字串)。預設值為 `'4.7.0'`。 ``` node[:unicorn][:version] ``` **worker\$1processes** 工作者處理序數目 (數值)。如果存在，預設值為 `max_pool_size`；否則為 `4`。 ``` node[:unicorn][:worker_processes] ``` # 對適用於 Linux 的 Chef 11.10 和舊版故障診斷 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 如需其他故障診斷資訊，請參閱[偵錯和故障診斷指南](troubleshoot.md)。 ## 適用於 Linux 之 Chef 11.10 和舊版的 Chef 日誌 OpsWorks Stacks 會將每個執行個體的 Chef 日誌存放在其`/var/lib/aws/opsworks/chef`目錄中。您需要 sudo 權限才能存取此目錄。每個回合的日誌位於名為 `YYYY-MM-DD-HH-MM-SS-NN.log` 的檔案中。如需詳細資訊，請參閱下列內容： + [使用主控台檢視 Chef 日誌](troubleshoot-debug-log.md#troubleshoot-debug-log-console) + [使用 CLI 或 API 檢視 Chef 日誌](troubleshoot-debug-log.md#troubleshoot-debug-log-cli) + [解讀 Chef 日誌](troubleshoot-debug-log.md#troubleshoot-debug-log-interpret) + [常見的 Chef 日誌錯誤](troubleshoot-debug-log.md#troubleshoot-debug-log-errors) # 將 OpsWorks Stacks 與其他 AWS 服務搭配使用 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以讓應用程式伺服器在 OpsWorks Stacks 堆疊中執行，使用各種未直接與 Stacks 整合的 AWS OpsWorks 服務。例如，您可以讓您的應用程式伺服器使用 Amazon RDS 做為後端資料庫。您可以藉由使用下列一般模式，存取這類服務： 1. 透過使用 AWS 主控台、API 或 CLI 建立和設定 AWS 服務，並記錄任何應用程式需要存取服務的必要資訊，例如主機名稱或連接埠。 1. 建立一或多個配方以設定應用程式，使其能夠存取服務。配方會從您在執行配方前使用自訂 JSON 定義的[堆疊組態及部署 JSON](workingcookbook-json.md) 屬性取得組態資料。 1. 將自訂配方指派給應用程式伺服器 layer 上的部署生命週期事件。 1. 建立將適當的值指派給組態資料屬性的自訂 JSON 物件，並將其新增至您的堆疊組態及部署 JSON。 1. 將應用程式部署到堆疊。部署會執行自訂配方，使用您在自訂 JSON 中定義的組態資料值設定應用程式，使其能夠存取服務。本節說明如何讓 OpsWorks Stacks 應用程式伺服器存取各種 AWS 服務。它假設您已熟悉 Chef 技術指南以及配方使用堆疊和組態 JSON 屬性設定應用程式的方式 (通常是透過建立組態檔案)。若您尚未熟悉，建議您先閱讀[技術指南和配方](workingcookbook.md)和[自訂 OpsWorks Stacks](customizing.md)。 **Topics** + [使用後端資料存放區](customizing-rds.md) + [使用 ElastiCache Redis 做為記憶體內鍵值存放區](other-services-redis.md) + [使用 Amazon S3 儲存貯體](gettingstarted.walkthrough.photoapp.md) + [使用 AWS CodePipeline 搭配 OpsWorks Stacks](other-services-cp.md) # 使用後端資料存放區 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。應用程式伺服器堆疊通常包含資料庫伺服器，以提供後端資料存放區。 OpsWorks 堆疊透過 MySQL layer 為 [MySQL ](workinglayers-db-mysql.md) 伺服器提供整合支援，並透過 [Amazon Relational Database Service (Amazon RDS) layer](workinglayers-db-rds.md) 為多種類型的資料庫伺服器提供整合支援。不過，您可以輕鬆自訂堆疊，讓應用程式伺服器使用其他資料庫伺服器，例如 Amazon DynamoDB 或 MongoDB。本主題說明將應用程式伺服器連線至 AWS 資料庫伺服器的基本程序。它使用 [Chef 11 Linux 堆疊入門](gettingstarted.md)中的堆疊和應用程式，以顯示如何手動將 PHP 應用程式伺服器連線至 RDS 資料庫。雖然範例是根據 Linux 堆疊，但基本原則也適用於 Windows 堆疊。如需如何將 MongoDB 資料庫伺服器併入堆疊的範例，請參閱[使用 OpsWorks 部署 MongoDB](https://aws.amazon.com/blogs/devops/deploying-mongodb-with-opsworks/)。 **注意** 本主題使用 Amazon RDS 做為方便的範例。不過，如果您想要將 Amazon RDS 資料庫與堆疊搭配使用，使用 Amazon RDS layer 會更容易。 **Topics** + [如何設定資料庫連線](customizing-rds-setup.md) + [如何將 Application Server 執行個體連線至 Amazon RDS](customizing-rds-connect.md) # 如何設定資料庫連線 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以使用自訂配方，來設定應用程式伺服器與其後端資料庫之間的連線。配方會視需要設定應用程式伺服器，一般是透過建立組態檔案。配方會從[堆疊組態中的一組屬性取得連線資料，例如主機和資料庫名稱，以及 Stacks 在每個執行個體上安裝的部署屬性](workingcookbook-json.md)。 OpsWorks 例如，的步驟 2 [Chef 11 Linux 堆疊入門](gettingstarted.md) 是以名為 MyStack 的堆疊為基礎，堆疊具有兩層：PHP App Server 和 MySQL，每個堆疊都有一個執行個體。您可以將名為 SimplePHPApp 的應用程式部署到使用 MySQL 執行個體上的資料庫做為後端資料存放區的 PHP App Server 執行個體。當您部署應用程式時， OpsWorks Stacks 會安裝包含資料庫連線資訊的堆疊組態和部署屬性。下列範例顯示資料庫連線屬性 (以 JSON 呈現)： ``` { ... "deploy": { "simplephpapp": { ... "database": { "reconnect": true, "password": null, "username": "root", "host": null, "database": "simplephpapp" ... }, ... } } } ``` 屬性值由 Stacks OpsWorks 提供，並產生或根據使用者提供的資訊。若要允許 SimplePHPApp 存取資料存放區，您必須將名為的自訂配方指派給 PHP App Server layer 的部署[生命週期事件](workingcookbook-events.md)，以設定 `appsetup.rb` PHP 應用程式伺服器與 MySQL 資料庫之間的連線。當您部署 SimplePHPApp 時， OpsWorks Stacks 會執行 `appsetup.rb`，這會建立名為的組態檔案`db-connect.php`來設定連線，如下列摘錄所示。 ``` node[:deploy].each do |app_name, deploy| ... template "#{deploy[:deploy_to]}/current/db-connect.php" do source "db-connect.php.erb" mode 0660 group deploy[:group] if platform?("ubuntu") owner "www-data" elsif platform?("amazon") owner "apache" end variables( :host => (deploy[:database][:host] rescue nil), :user => (deploy[:database][:username] rescue nil), :password => (deploy[:database][:password] rescue nil), :db => (deploy[:database][:database] rescue nil), :table => (node[:phpapp][:dbtable] rescue nil) ) ... end end ``` 描述連線特性的變數 `host`-`user`、等 - 會從[部署的 JSON](workingcookbook-json.md#workingcookbook-json-deploy) `[:deploy][:app_name][:database]` 屬性設定對應的值。為求簡化，此範例假設您已建立名為 `urler` 的表格，因此表格名稱是由技術指南屬性檔案中的 `[:phpapp][:dbtable]` 所呈現。此配方實際上可以將 PHP 應用程式伺服器連線到任何 MySQL 資料庫伺服器，而不只是 MySQL layer 的成員。若要使用不同的 MySQL 伺服器，您只需要將`[:database]`屬性設定為適合您伺服器的值，您可以使用[自訂 JSON](workingstacks-json.md) 來執行此操作。 OpsWorks 堆疊接著會將這些屬性和值併入堆疊組態和部署屬性，`appsetup.rb`並使用它們來建立設定連線的範本。如需覆寫堆疊組態和部署 JSON 的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 # 如何將 Application Server 執行個體連線至 Amazon RDS **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節說明如何從 [Chef 11 Linux 堆疊入門](gettingstarted.md)自訂 MyStack，讓 PHP 應用程式伺服器連線至 RDS 執行個體。 **Topics** + [建立 Amazon RDS MySQL 資料庫](customizing-rds-connect-create.md) + [自訂堆疊以連線至 RDS 資料庫](customizing-rds-connect-customize.md) # 建立 Amazon RDS MySQL 資料庫 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。現在您已準備好使用 Amazon RDS 主控台的啟動資料庫執行個體精靈為範例建立 RDS 資料庫。下列程序是基本詳細資訊的簡短摘要。如需如何建立資料庫的詳細描述，請參閱 [Amazon RDS 入門](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html)。 **建立 Amazon RDS 資料庫** 1. 如果這是您第一次建立 RDS 資料庫，請按一下 **Get Started Now (立即開始)**。否則，按一下導覽窗格中的 **RDS Dashboard (RDS 儀表板)**，然後按一下 **Launch a DB Instance (啟動資料庫執行個體)**。 1. 選取 **MySQL Community Edition** 做為資料庫執行個體。 1. 針對 **Do you plan to use this database for production purposes? (您打算以生產為目的使用此資料庫嗎？)**，選取 **No, this instance... (否，此執行個體...)**，這對此範例就已足夠。針對生產用途，建議您選取 **Yes, use Multi-AZ Deployment... (是，使用異地同步備份部署...)**。按一下**Next Step (下一步)**。 1. 在 **Specify DB Details (指定資料庫詳細資訊)** 頁面上，指定下列設定： + **DB Instance Class (資料庫執行個體類別)**：**db.t2.micro**。 + **Multi-AZ Deployment (異地同步備份部署)**：**No (否)** + **Allocated Storage (配置儲存體)**：**5** GB + **DB Instance Identifier (資料庫執行個體識別符)**：**rdsexample** + **Master Username (主要使用者名稱)**：**opsworksuser** + **Master Password (主要密碼)**：指定並記錄適合的密碼，以供日後使用。接受其他選項的預設設定，然後按一下 **Next Step (下一步)**。 1. 在 **Configure Advanced Settings (設定進階設定)** 頁面上，指定下列設定： + 在 **Network & Security (網路和安全)** 區段中，針對 **VPC Security Group(s) (VPC 安全群組)**，選取 **phpsecgroup (VPC)** + 在 **Database Options (資料庫選項)** 區段中，針對 **Database Name (資料庫名稱)**，輸入 **rdsexampledb**。 + 在 **Backup (備份)** 區段中，針對本演練的用途，將 **Backup Retention Period (備份保留期)** 設定為 **0**。接受其他選項的預設設定，然後按一下 **Launch DB Instance (啟動資料庫執行個體)**。 1. 選擇 **View Your DB Instances (檢視資料庫執行個體)**，以查看資料庫執行個體清單。 1. 在清單中選取 **rdsexample** 執行個體，然後按一下箭頭以顯示執行個體端點和其他詳細資訊。記錄端點，供日後使用。它應該類似 `rdsexample.c6c8mntzhgv0.us-west-2.rds.amazonaws.com:3306`。只需要記錄 DNS 名稱；您不需要連接埠號碼。 1. 使用 MySQL Workbench 這類工具，利用下列 SQL 命令在 `urler` 資料庫中建立名為 `rdsexampledb` 的表格： ``` CREATE TABLE urler(id INT UNSIGNED NOT NULL AUTO_INCREMENT,author VARCHAR(63) NOT NULL,message TEXT,PRIMARY KEY (id)) ``` # 自訂堆疊以連線至 RDS 資料庫 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在您[建立 RDS 執行個體](customizing-rds-connect-create.md)以當成 PHP 應用程式伺服器的後端資料庫使用之後，即可從 [Chef 11 Linux 堆疊入門](gettingstarted.md)自訂 MyStack。 **將 PHP 應用程式伺服器連線至 RDS 資料庫** 1. 開啟 OpsWorks Stacks 主控台，並使用包含一個執行個體的 PHP App Server layer 建立堆疊，並部署 SimplePHPApp，如中所述[Chef 11 Linux 堆疊入門](gettingstarted.md)。此堆疊使用 SimplePHPApp 的第 1 版，而此版本不使用資料庫連線。 1. [更新堆疊組態](workingstacks-edit.md)以使用包括 `appsetup.rb` 配方的自訂技術指南，以及相關的範本和屬性檔案。 1. 將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 設為 **Yes (是)**。 1. 將 **Repository type (儲存庫類型)** 設定為 **Git**，並將 **Repository URL (儲存庫 URL)** 設為 `git://github.com/amazonwebservices/opsworks-example-cookbooks.git`。 1. 將下列內容新增至堆疊的 **Custom Chef JSON (自訂 Chef JSON)** 方塊，以將 RDS 連線資料指派給 `appsetup.rb` 用來建立組態檔案的 `[:database]` 屬性。 ``` { "deploy": { "simplephpapp": { "database": { "username": "opsworksuser", "password": "your_password", "database": "rdsexampledb", "host": "rds_endpoint", "adapter": "mysql" } } } } ``` 使用下列屬性值： + **username**：您在建立 RDS 執行個體時所指定的主要使用者名稱。此範例使用 `opsworksuser`。 + **password**：您在建立 RDS 執行個體時所指定的主要密碼。請填入您指定的密碼。 + **database**：您在建立 RDS 執行個體時所建立的資料庫。此範例使用 `rdsexampledb`。 + **host**：RDS 執行個體的端點，這是您在上節中建立執行個體時從 RDS 主控台取得。請不要包括連接埠號碼。 + **adapter**：轉接器。此範例的 RDS 執行個體使用 MySQL，因此 **adapter** 設定為 `mysql`。與其他屬性不同，**轉接器**不會由使用`appsetup.rb`。PHP App Server layer 的內建設定配方會改用它來建立不同的組態檔案。 1. [編輯 SimplePHPApp 組態](workingapps-editing.md)，以指定使用後端資料庫的 SimplePHPApp 版本，如下所示： + **Document root (文件根)**：將此選項設為 `web`。 + **Branch/Revision (分支/修訂)**：將此選項設為 `version2`。將其餘的選項保持不變。 1. [編輯 PHP App Server layer](workinglayers-basics-edit.md)，透過將 `phpapp::appsetup`新增至 layer 的部署配方來設定資料庫連線。 1. [部署新 SimplePHPApp 版本](workingapps-deploying.md)。 1. 部署 SimplePHPApp 時，前往 **Instances (執行個體)** 頁面並按一下 php-app1 執行個體的公有 IP 地址，來執行應用程式。您應該會在瀏覽器中看到下列頁面，以讓您輸入文字，並將其存放在資料庫中。 ![\[Text input field labeled "Your Thoughts" with a "Share Your Thought" button.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gsb7.png) **注意** 如果您的堆疊有 MySQL layer， OpsWorks Stacks 會自動將對應的連線資料指派給`[:database]`屬性。不過，如果您將自訂 JSON 指派給定義不同 `[:database]` 值的堆疊，則它們會覆寫預設值。由於`[:deploy]`屬性會安裝在每個執行個體上，任何依賴`[:database]`屬性的配方都會使用自訂連線資料，而不是 MySQL layer 的資料。如果您想要特定應用程式伺服器 layer 使用自訂連線資料，請將自訂 JSON 指派給 layer 的部署事件，並將該部署限制為該 layer。如需如何使用部署屬性的詳細資訊，請參閱[部署應用程式](workingapps-deploying.md)。如需覆寫 OpsWorks Stacks 內建屬性的詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 # 使用 ElastiCache Redis 做為記憶體內鍵值存放區 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 本主題是以 Linux 堆疊為基礎，但 Windows 堆疊也可以使用 Amazon ElastiCache (ElastiCache)。如需如何搭配 Windows 執行個體使用 ElastiCache 的範例，請參閱 [ElastiCache 作為 ASP.NET 工作階段存放區](https://aws.amazon.com/blogs/developer/elasticache-as-an-asp-net-session-store/)。您通常可以透過使用快取伺服器為字串等小型資料項目提供記憶體內鍵值存放區，來改善應用程式伺服器效能。Amazon ElastiCache 是一種 AWS 服務，可讓您使用 [Memcached](http://memcached.org/) 或 [Redis](https://redis.io) 快取引擎，輕鬆地為應用程式伺服器提供快取支援。 OpsWorks Stacks 提供 [Memcached](workinglayers-mem.md) 的內建支援。不過，如果 Redis 更符合您的需求，您可以自訂堆疊，讓您的應用程式伺服器使用 ElastiCache Redis。本主題會逐步引導您使用 Rails 應用程式伺服器為 Linux 堆疊提供 ElastiCache Redis 快取支援的基本程序。它假設您已有適當的 Ruby on Rails 應用程式。如需 ElastiCache 的詳細資訊，請參閱[什麼是 Amazon ElastiCache？](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/WhatIs.html)。 **Topics** + [步驟 1：建立 ElastiCache Redis 叢集](other-services-redis-cluster.md) + [步驟 2：設定 Rails 堆疊](other-services-redis-stack.md) + [步驟 3：建立和部署自訂技術指南](other-services-redis-cookbook.md) + [步驟 4：將配方指派給 LifeCycle (生命週期) 事件](other-services-redis-event.md) + [步驟 5：將存取資訊新增至堆疊組態 JSON](other-services-redis-json.md) + [步驟 6：部署和執行應用程式](other-services-redis-app.md) # 步驟 1：建立 ElastiCache Redis 叢集 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您必須先使用 Amazon ElastiCache ElastiCache Redis 叢集。以下說明如何使用主控台來建立叢集。 **建立 ElastiCache Redis 叢集** 1. 前往 [ElastiCache 主控台](https://console.aws.amazon.com/elasticache/)，然後按一下**啟動快取叢集**以啟動快取叢集精靈。 1. 在 Cache Cluster Details (快取叢集詳細資訊) 頁面上，執行下列作業： + 將 **Name (名稱)** 設為您的快取伺服器名稱。此範例使用 OpsWorks-Redis。 + 將 **Engine (引擎)** 設為 **redis**。 + 將 **Topic for SNS Notification (SNS 通知主題)** 設為 **Disable Notifications (停用通知)**。 + 針對其他設定接受預設值，然後按一下 **Continue (繼續)**。 ![\[Cache 叢集 Wizard interface for configuring Redis 叢集 details and settings.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elasticache-wizard-1.png) 1. 在 **Additional Configuration (其他組態)** 頁面上，接受預設值，然後按一下 **Continue (繼續)**。 ![\[Cache 叢集 Wizard configuration page with security group, parameter group, and maintenance window options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elasticache-wizard-2.png) 1. 按一下 **Launch Cache Cluster (啟動快取叢集)** 以建立叢集。 **重要** 針對此範例，預設快取安全群組便已足夠，但若為生產用途，建議您建立適合您環境的快取安全群組。如需詳細資訊，請參閱[管理快取安全群組](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/ManagingSecurityGroups.html)。 1. 在啟動叢集後，按一下名稱以開啟詳細資訊頁面，然後按一下 **Nodes (節點)** 標籤。記下叢集的 **Port (連接埠)** 和 **Endpoint (端點)** 值，以供稍後使用。 ![\[Cache 叢集 details showing node status, creation date, port, and endpoint for a Redis instance.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/elasticache-wizard-3.png) # 步驟 2：設定 Rails 堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。除了建立支援 Rails App Server layer 的堆疊之外，您還必須設定 layer 的安全群組，以便 Rails 伺服器可以與 Redis 伺服器正確通訊。 **設定堆疊** 1. 建立為此**RedisStack**範例命名的新堆疊，並新增 Rails App Server layer。您可以使用兩者的預設設定。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)及[建立 OpsWorks Layer](workinglayers-basics-create.md)。 1. 在 **Layers **頁面上，針對 Rails App Server，按一下**安全性**，然後按一下**編輯**。 1. 前往**安全群組**區段，並將 ElastiCache 叢集的安全群組新增至**其他群組**。針對此範例，選取 **default (預設)** 安全群組，按一下 **\$1** 將它新增至 layer，然後按一下 **Save (儲存)** 以儲存新的組態。 ![\[Security Groups section showing default and additional groups with a dropdown menu of AWS OpsWorks options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/redis-security.png) 1. 將執行個體新增至 Rails App Server layer 並啟動它。如需如何新增並啟動執行個體的詳細資訊，請參閱[將執行個體新增至 Layer](workinginstances-add.md)。 # 步驟 3：建立和部署自訂技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。目前堆疊還沒有什麼功能。您必須啟用您的應用程式，才能存取 Redis 伺服器。最靈活的方式便是在應用程式的 `config` 子資料夾中置放一個帶有存取資訊的 YAML 檔案。應用程式接著便能從檔案取得資訊。使用此方法，您可以變更連線資訊，無需重新撰寫和重新部署應用程式。在此範例中，檔案應該命名`redis.yml`並包含 ElastiCache 叢集的主機名稱和連接埠，如下所示： ``` host: cache-cluster-hostname port: cache-cluster-port ``` 您可以手動將此檔案複製到伺服器，但更好的方法是實作 Chef *配方*來產生檔案，並讓 OpsWorks Stacks 在每個伺服器上執行配方。Chef 配方是專門的 Ruby 應用程式，由 OpsWorks Stacks 用來在執行個體上執行任務，例如安裝套件或建立組態檔案。配方是封裝在「技術指南」**中，而技術指南可以包含多個配方和相關檔案 (例如組態檔案的範本)。技術指南會放置於儲存庫 (例如 GitHub) 中，且必須擁有標準目錄結構。如果您還沒有自訂技術指南儲存庫，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)，以取得如何設定技術指南的資訊。針對此範例，請將名為 `redis-config` 的技術指南新增至您的技術指南儲存庫，其內容如下： ``` my_cookbook_repository redis-config recipes generate.rb templates default redis.yml.erb ``` `recipes` 資料夾包含名為 `generate.rb` 的配方，該配方會從 `redis.yml.erb` 產生應用程式的組態檔案，如下所示： ``` node[:deploy].each do |app_name, deploy_config| # determine root folder of new app deployment app_root = "#{deploy_config[:deploy_to]}/current" # use template 'redis.yml.erb' to generate 'config/redis.yml' template "#{app_root}/config/redis.yml" do source "redis.yml.erb" cookbook "redis-config" # set mode, group and owner of generated file mode "0660" group deploy_config[:group] owner deploy_config[:user] # define variable “@redis” to be used in the ERB template variables( :redis => deploy_config[:redis] || {} ) # only generate a file if there is Redis configuration not_if do deploy_config[:redis].blank? end end end ``` 配方取決於 Stacks OpsWorks [堆疊組態和部署 JSON](workingcookbook-json.md) 物件的資料，這些物件會安裝在每個執行個體上，並包含堆疊和任何部署應用程式的詳細資訊。物件的 `deploy` 節點具有以下結構： ``` { ... "deploy": { "app1": { "application" : "short_name", ... } "app2": { ... } ... } } ``` deploy 節點包含每個部署應用程式 (以應用程式的短名命名) 的一組內嵌 JSON 物件。每個應用程式物件都包含一組定義應用程式組態的屬性，例如文件根和應用程式類型。如需部署屬性的清單，請參閱[deploy 屬性](attributes-json-deploy.md)。配方可使用 Chef 屬性語法來表示堆疊組態及部署 JSON 的。例如：`[:deploy][:app1][:application]` 表示 app1 應用程式的短名。針對 `[:deploy]` 中的每個應用程式，配方會執行關聯的程式碼區塊，其中 `deploy_config` 表示應用程式屬性。第一個配方會將 `app_root` 設為應用程式的根目錄，`[:deploy][:app_name][:deploy_to]/current`。它接著會使用 Chef [範本資源](https://docs.chef.io/chef/resources.html#template)從 `redis.yml.erb` 產生組態檔案，然後將其置放於 `app_root/config` 中。組態檔案通常會從範本建立，其中許多設定都由 Chef「屬性」**定義。使用屬性，您可以於稍後使用自訂 JSON 變更設定，而無須重新撰寫範本檔案。`redis.yml.erb` 範本包含下列項目： ``` host: <%= @redis[:host] %> port: <%= @redis[:port] || 6379 %> ``` <%... %> 元素為代表屬性值的預留位置。 + `<%= @redis[:host] %>` 表示 `redis[:host]` 的值，也就是快取叢集的主機名稱。 + `<%= @redis[:port] || 6379 %>` 表示 `redis[:port]` 的值或預設連接埠值 6379 (若屬性尚未定義的話)。 `template` 資源的運作方式如下： + `source` 和 `cookbook` 分別指定範本和技術指南名稱。 + `mode`、`group` 和 `owner` 會給予組態檔案與應用程式相同的存取權。 + `variables` 區段會將範本中使用的 `@redis` 變數設為應用程式的 `[:redis]` 屬性值。 `[:redis]` 屬性值是透過使用自訂 JSON 來設定，如稍後所述。它並非標準應用程式屬性之一。 + `not_if` 指示詞會確保配方不會在已有現有檔案時再次產生組態檔案。在您撰寫技術指南之後，您必須將其部署至每個執行個體的技術指南快取。此操作不會執行配方。它只會將新的技術指南安裝到堆疊的執行個體上。您通常會藉由將其指派給 layer 的生命週期事件來執行配方，如稍後所述。 **部署您的自訂技術指南** 1. 在 OpsWorks 堆疊**堆疊**頁面上，按一下**堆疊設定**，然後按一下**編輯**。 1. 在 **Configuration Management (組態管理)** 區段中，將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 設為 **Yes (是)**，輸入技術指南儲存庫資訊，然後按一下 **Save (儲存)** 以更新堆疊組態。 ![\[Configuration form for custom Chef cookbooks with repository details and options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/redis_walkthrough_cookbook.png) 1. 在 **Stack (堆疊)** 頁面中，按一下 **Run Command (執行命令)**，選取 **Update Custom Cookbooks (更新自訂技術指南)** 堆疊命令，然後按一下 **Update Custom Cookbooks (更新自訂技術指南)** 以將新的技術指南安裝到執行個體的技術指南快取中。 ![\[Run Command interface showing Update Custom Cookbooks option and instance selection for Rails App Server.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/redis_walkthrough_command.png) 若您修改您的技術指南，只須再次執行 **Update Custom Cookbooks (更新自訂技術指南)** 即可安裝更新後的版本。如需此程序的詳細資訊，請參閱[安裝自訂技術指南](workingcookbook-installingcustom-enable.md)。 # 步驟 4：將配方指派給 LifeCycle (生命週期) 事件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以[手動](workingcookbook-manual.md)執行自訂配方，但最佳方法是讓 Stacks OpsWorks 自動執行。每個 layer 都有一組內建配方，分別指派五個[生命週期事件](workingcookbook-events.md)：設定、設定、部署、取消部署和關機。每當執行個體發生事件時， OpsWorks Stacks 就會針對每個執行個體的 layer 執行相關聯配方，以處理對應的任務。例如，當執行個體完成開機時， OpsWorks Stacks 會觸發設定事件。此事件會執行關聯 layer 的安裝配方，通常會處理像是安裝和設定套件等任務。您可以將配方指派給適當的生命週期事件，讓 OpsWorks Stacks 在 layer 的執行個體上執行自訂配方。在此範例中，您應該將`generate.rb`配方指派給 Rails App Server layer 的部署事件。 OpsWorks 堆疊接著會在啟動期間、安裝配方完成後，以及每次部署應用程式時，在 layer 的執行個體上執行配方。如需詳細資訊，請參閱[自動執行配方](workingcookbook-assigningcustom.md)。 **將配方指派給 Rails App Server layer 的部署事件** 1. 在 OpsWorks Stacks **Layers **頁面上，針對 Rails App Server，按一下**配方**，然後按一下**編輯**。 1. 在 **Custom Chef Recipes (自訂 Chef 配方)** 下方，將完整配方名稱新增至部署事件，然後按一下 **\$1**。完整的配方名稱會使用 `cookbookname::recipename ` 格式，其中 `recipename` 不包含 `.rb` 副檔名。針對此範例，完整名稱為 `redis-config::generate`。然後按一下 **Save (儲存)**，以更新 layer 組態。 ![\[Custom Chef Recipes interface showing setup, configure, deploy, undeploy, and shutdown options.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/redis_walkthrough_event.png) # 步驟 5：將存取資訊新增至堆疊組態 JSON **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 `generate.rb` 配方依存於一對代表 Redis 伺服器主機名稱和連接埠的堆疊組態及部署 JSON 屬性。雖然這些屬性是標準`[:deploy]`命名空間的一部分，但 Stacks OpsWorks 不會自動定義這些屬性。相反的，您會透過將自訂 JSON 物件新增至堆疊，來定義屬性和他們的值。以下範例顯示此範例的自訂 JSON。 **將存取資訊新增至堆疊組態及部署 JSON** 1. 在 OpsWorks 堆疊**堆疊**頁面上，按一下**堆疊設定**，然後按一下**編輯**。 1. 在 **Configuration Management (組態管理)** 區段中，將存取資訊新增至 **Custom Chef JSON (自訂 Chef JSON)** 方塊。內容看起來應會類似以下範例，而您必須進行這些修改： + 將 `elasticache_redis_example` 取代為您應用程式的短名。 + 將 `host`和 `port`值取代為您在中建立的 ElastiCache Redis 伺服器執行個體的值[步驟 1：建立 ElastiCache Redis 叢集](other-services-redis-cluster.md)。 ``` { "deploy": { "elasticache_redis_example": { "redis": { "host": "mycluster.XXXXXXXXX.amazonaws.com", "port": "6379" } } } } ``` ![\[Custom Chef JSON input field for configuring ElastiCache Redis instance details.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/redis_walkthrough_json.png) 此方法的優點是您可以隨時變更連接埠或主機值，而無需碰觸自訂技術指南。 OpsWorks Stacks 會將自訂 JSON 合併至內建 JSON，並針對所有後續生命週期事件將其安裝在堆疊的執行個體上。應用程式接著便可以透過使用 Chef 節點語法存取屬性值，如[步驟 3：建立和部署自訂技術指南](other-services-redis-cookbook.md)中所述。下一次您部署應用程式時， OpsWorks Stacks 會安裝包含新定義的堆疊組態和部署 JSON，並且 `generate.rb` 會建立帶有更新過主機和連接埠值的組態檔案。 **注意** 由於 `[:deploy]` 會自動包含每個部署應用程式的屬性，因此 `[:deploy][elasticache_redis_example]` 已位於堆疊和組態 JSON 中。不過， `[:deploy][elasticache_redis_example]` 不包含`[:redis]`屬性，使用自訂 JSON 定義它們會指示 OpsWorks Stacks 將這些屬性新增至 `[:deploy][elasticache_redis_example]`。您也可以使用自訂 JSON 覆寫現有的屬性。如需詳細資訊，請參閱[覆寫屬性](workingcookbook-attributes.md)。 # 步驟 6：部署和執行應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。此範例假設您已有使用 Redis 的 Ruby on Rails 應用程式。若要存取組態檔案，您可以將 `redis` gem 新增至您的 Gemfile，並在 `config/initializers/redis.rb` 中建立 Rails 初始設定式，如下所示： ``` REDIS_CONFIG = YAML::load_file(Rails.root.join('config', 'redis.yml')) $redis = Redis.new(:host => REDIS_CONFIG['host'], :port => REDIS_CONFIG['port']) ``` 然後[建立應用程式](workingapps-creating.md)來代表您的應用程式[，並將其部署](workingapps-deploying.md)到 Rails App Server layer 的執行個體，這會更新應用程式程式碼並執行 `generate.rb`以產生組態檔案。當您執行應用程式時，它會使用 ElastiCache Redis 執行個體做為其記憶體內金鑰值存放區。 # 使用 Amazon S3 儲存貯體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。應用程式通常會使用 Amazon Simple Storage Service (Amazon S3) 儲存貯體來存放大型項目，例如映像或其他媒體檔案。雖然 OpsWorks Stacks 不提供 Amazon S3 的整合支援，但您可以輕鬆自訂堆疊，以允許應用程式使用 Amazon S3 儲存。本主題將引導您完成提供 Amazon S3 存取應用程式的基本程序，使用 Linux 堆疊搭配 PHP 應用程式伺服器做為範例。基本原則同樣適用於 Windows 堆疊。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **Topics** + [步驟 1：建立 Amazon S3 儲存貯體](using-s3-bucket.md) + [步驟 2：建立 PHP 應用程式伺服器堆疊](using-s3-stack.md) + [步驟 3：建立和部署自訂技術指南](using-s3-cookbook.md) + [步驟 4：將配方指派給生命週期事件](using-s3-events.md) + [步驟 5：將存取資訊新增至堆疊組態及部署屬性](using-s3-json.md) + [步驟 6：部署和執行 PhotoApp](using-s3-run.md) # 步驟 1：建立 Amazon S3 儲存貯體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您必須先建立 Amazon S3 儲存貯體。您可以使用 Amazon S3 主控台、API 或 CLI 直接執行此操作，但建立資源的簡單方式通常是使用 CloudFormation 範本。下列範本會為此範例建立 Amazon S3 儲存貯體，並使用 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html)設定[執行個體描述](https://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html)檔，以授予儲存貯體不受限制的存取權。然後，您可以使用 layer 設定，將執行個體描述檔連接到堆疊的應用程式伺服器執行個體，讓應用程式存取儲存貯體，如稍後所述。執行個體描述檔的實用性不限於 Amazon S3；它們對於整合各種 AWS 服務非常有用。 ``` { "AWSTemplateFormatVersion" : "2010-09-09", "Resources" : { "AppServerRootRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "ec2.amazonaws.com" ] }, "Action": [ "sts:AssumeRole" ] } ] }, "Path": "/" } }, "AppServerRolePolicies": { "Type": "AWS::IAM::Policy", "Properties": { "PolicyName": "AppServerS3Perms", "PolicyDocument": { "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": { "Fn::Join" : ["", [ "arn:aws:s3:::", { "Ref" : "AppBucket" } , "/*" ] ] } } ] }, "Roles": [ { "Ref": "AppServerRootRole" } ] } }, "AppServerInstanceProfile": { "Type": "AWS::IAM::InstanceProfile", "Properties": { "Path": "/", "Roles": [ { "Ref": "AppServerRootRole" } ] } }, "AppBucket" : { "Type" : "AWS::S3::Bucket" } }, "Outputs" : { "BucketName" : { "Value" : { "Ref" : "AppBucket" } }, "InstanceProfileName" : { "Value" : { "Ref" : "AppServerInstanceProfile" } } } } ``` 當您啟動範本時會發生幾種情況： + `[AWS::S3::Bucket](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html)` 資源會建立 Amazon S3 儲存貯體。 + `[AWS::IAM::InstanceProfile](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-instanceprofile.html)` 資源會建立執行個體描述檔，以指派給應用程式伺服器執行個體。 + `[AWS::IAM::Role](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html)` 資源會建立執行個體描述檔的角色。 + `[AWS::IAM::Policy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-iam-policy.html)` 資源會設定角色的許可，以允許不受限制地存取 Amazon S3 儲存貯體。 + 在您啟動範本之後， CloudFormation 主控台中的 `Outputs` 區段會顯示儲存貯體和執行個體描述檔名稱。您需要這些值來設定堆疊和應用程式。如需如何建立 CloudFormation 範本的詳細資訊，請參閱[了解範本基本概念](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/gettingstarted.templatebasics.html)。 **建立 Amazon S3 儲存貯體** 1. 將範例範本複製到您系統中的文字檔案。此範例假設檔案名稱為 `appserver.template`。 1. 開啟 [CloudFormation](https://console.aws.amazon.com/cloudformation/) 主控台，然後選擇 **Create Stack (建立堆疊)**。 1. 在 **Stack Name (堆疊名稱)** 方塊中，輸入堆疊名稱。此範例假設名稱為 **AppServer**。 1. 依序選擇 **Upload template file (上傳範本檔案)** 和 **Browse (瀏覽)**，並選取您在步驟 1 中建立的 `appserver.template` 檔案，然後選擇 **Next Step (下一步)**。 1. 在 **Specify Parameters (指定參數)** 頁面中，選取 **I acknowledge that this template may create IAM resources (我知道此範本可能會建立 IAM 資源)**，然後選擇每個精靈頁面的 **Next Step (下一步)**，直到完成為止。選擇**建立**。 1. 在 **AppServer** 堆疊達到 **CREATE\$1COMPLETE** 狀態之後，請選取它，然後選擇 **Outputs (輸出)** 標籤。您可能需要重新整理幾次以更新狀態。 1. 在 **Outputs (輸出)** 標籤中，記錄 **BucketName** 和 **InstanceProfileName** 值，供日後使用。 **注意** CloudFormation 使用 *堆疊*一詞來參考從範本建立的資源集合；它與 OpsWorks Stacks 堆疊不同。 # 步驟 2：建立 PHP 應用程式伺服器堆疊 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。堆疊包含兩層：PHP App Server 和 MySQL，每個都有一個執行個體。應用程式會將相片存放在 Amazon S3 儲存貯體上，但會使用 MySQL 執行個體做為後端資料存放區，以保留每張相片的中繼資料。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **建立堆疊** 1. 建立為此**PhotoSite**範例命名的新堆疊，並新增 PHP App Server layer。您可以使用兩者的預設設定。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)及[建立 OpsWorks Layer](workinglayers-basics-create.md)。 1. 在 **Layers** 頁面上，針對 PHP App Server，選擇**安全性**，然後選擇**編輯**。 1. 在 **Layer Profile** 區段中，選取您在啟動 AppServer CloudFormation 堆疊後先前記錄的執行個體設定檔名稱。它就像 `AppServer-AppServerInstanceProfile-1Q3KD0DNMGB90`. OpsWorks Stacks 會將此設定檔指派給 layer 的所有 Amazon EC2 執行個體，這會授予許可來存取在 layer 執行個體上執行的應用程式 Amazon S3 儲存貯體。 ![\[IAM Instance Profile dropdown showing available profiles, including a custom AppServer profile.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/photoapp_profile.png) 1. 將執行個體新增至 PHP App Server layer 並啟動它。如需如何新增並啟動執行個體的詳細資訊，請參閱[將執行個體新增至 Layer](workinginstances-add.md)。 1. 將 MySQL layer 新增至堆疊、新增執行個體，然後啟動它。您可以使用 layer 和執行個體的預設設定。特別是，MySQL 執行個體不需要存取 Amazon S3 儲存貯體，因此可以使用預設選取的標準 OpsWorks Stacks 執行個體描述檔。 # 步驟 3：建立和部署自訂技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。堆疊尚未就緒： + 您的應用程式需要一些資訊才能存取 MySQL 資料庫伺服器和 Amazon S3 儲存貯體，例如資料庫主機名稱和 Amazon S3 儲存貯體名稱。 + 您需要在 MySQL 資料庫伺服器中設定資料庫，並建立資料表來保存相片的中繼資料。您可以手動處理這些任務，但更好的方法是實作 Chef *配方*，並讓 OpsWorks Stacks 在適當的執行個體上自動執行配方。Chef 配方是 Stacks OpsWorks 用來在安裝套件或建立組態檔案等執行個體上執行任務的專門 Ruby 應用程式。配方封裝在「技術指南」**中，而技術指南可以包含多個配方和相關檔案 (例如組態檔案的範本)。技術指南會放置於儲存庫 (例如 GitHub) 中，且必須擁有標準目錄結構。如果您還沒有自訂技術指南儲存庫，請參閱[技術指南儲存庫](workingcookbook-installingcustom-repo.md)，以取得如何設定技術指南的資訊。這個範例已為您實作技術指南，並將其存放在[公有 GitHub 儲存庫](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/photoapp)中。此技術指南包含 `appsetup.rb` 和 `dbsetup.rb` 這兩個配方，以及 `db-connect.php.erb` 範本檔案。 `appsetup.rb` 配方會建立組態檔案，其中包含應用程式存取資料庫和 Amazon S3 儲存貯體所需的資訊。基本上，它是稍經修改的 `appsetup.rb` 配方 (如[將應用程式連線到資料庫](gettingstarted-db-recipes.md#gettingstarted-db-recipes-appsetup)中所述) 版本主要差別在於傳遞到範本的變數，其代表存取資訊。前四個屬性會定義資料庫連線設定，並在您建立 MySQL 執行個體時由 OpsWorks Stacks 自動定義。這些變數和原始配方中的變數有兩項差異： + 與原始配方相同，`table` 變數代表由 `dbsetup.rb` 建立的資料庫表格名稱，並設定為技術指南屬性檔案中定義的屬性值。不過，屬性具有不同的名稱：`[:photoapp][:dbtable]`。 + `s3bucket` 變數專屬於此範例，並設定為代表 Amazon S3 儲存貯體名稱的屬性值`[:photobucket]`。 `[:photobucket]` 是使用自訂 JSON 來定義，如稍後所述。如需屬性的詳細資訊，請參閱[屬性](workingcookbook-installingcustom-components-attributes.md)。如需屬性的詳細資訊，請參閱[屬性](workingcookbook-installingcustom-components-attributes.md)。 `dbsetup.rb` 配方會設定資料庫表格，以存放每個相片的中繼資料。基本上，它是稍經修改的 `dbsetup.rb` 配方 (如[設定資料庫](gettingstarted-db-recipes.md#gettingstarted-db-recipes-dbsetup)中所述) 版本；請參閱該主題以了解詳細描述。此範例與原始配方的唯一差異是資料庫結構描述，其有三個資料欄，其中包含存放在 Amazon S3 儲存貯體上每張相片的 ID、URL 和字幕。配方已實作，因此您只需要將相片應用程式技術指南部署到每個執行個體的技術指南快取。然後， OpsWorks Stacks 會在適當的生命週期事件發生時執行快取的配方，如下所述。 **部署 photoapp 技術指南** 1. 在 OpsWorks 堆疊**堆疊**頁面上，選擇**堆疊設定**，然後選擇**編輯**。 1. 在 **Configuration Management (組態管理)** 區段中： + 將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 設為 **Yes (是)**。 + 將 **Repository type (儲存庫類型)** 設定為 Git。 + 將 **Repository URL (儲存庫 URL)** 設定為 **git://github.com/amazonwebservices/opsworks-example-cookbooks.git**。 1. 在 **Stack (堆疊)** 頁面上，選擇 **Run Command (執行命令)**，並選取 **Update Custom Cookbooks (更新自訂技術指南)** 堆疊命令，然後選擇 **Update Custom Cookbooks (更新自訂技術指南)**，以將新的技術指南安裝到執行個體的技術指南快取中。 ![\[Run Command interface showing Update Custom Cookbooks option and instance selection.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/redis_walkthrough_command.png) # 步驟 4：將配方指派給生命週期事件 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。您可以[手動](workingcookbook-manual.md)執行自訂配方，但最佳方法是讓 Stacks OpsWorks 自動執行。每個 layer 都有一組內建配方，指派給五個[生命週期事件](workingcookbook-events.md)中的每一個：設定、設定、部署、取消部署和關機。每次在執行個體上發生事件時， OpsWorks Stacks 都會為每個執行個體的 layer 執行相關聯的配方，以處理所需的任務。例如，當執行個體完成開機時， OpsWorks Stacks 會觸發安裝事件來執行安裝配方，這通常會處理安裝和設定套件等任務。您可以將每個配方指派給適當的生命週期事件，讓 OpsWorks Stacks 在 layer 的執行個體上執行自訂配方。 OpsWorks Stacks 會在 layer 的內建配方完成後執行任何自訂配方。在此範例中，將 `appsetup.rb`指派給 PHP App Server layer 的部署事件`dbsetup.rb`和 MySQL layer 的部署事件。 OpsWorks 堆疊接著會在啟動期間、內建安裝配方完成後，以及每次您部署應用程式時，在內建部署配方完成後，在相關聯的 layer 執行個體上執行配方。如需詳細資訊，請參閱[自動執行配方](workingcookbook-assigningcustom.md)。 **將自訂配方指派給 layer 的部署事件** 1. 在 OpsWorks Stacks **Layers **頁面上，針對 PHP 應用程式伺服器選擇**配方**，然後選擇**編輯**。 1. 在 **Custom Chef Recipes (自訂 Chef 配方)** 下方，將配方名稱新增至部署事件，然後選擇 **\$1**。名稱必須為 Chef `cookbookname::recipename` 格式，其中 `recipename` 不含 `.rb` 副檔名。在此範例中，您可以輸入 `photoapp::appsetup`。然後選擇 **Save (儲存)**，以更新 layer 組態。 ![\[Custom Chef Recipes configuration with Repository URL and lifecycle events.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/psb6a.png) 1. 在 **Layers** 頁面上，選擇 MySQL layer **動作**欄中的**編輯**。 1. 將 `photoapp::dbsetup` 新增至 layer 的部署事件，並儲存新的組態。 # 步驟 5：將存取資訊新增至堆疊組態及部署屬性 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 `appsetup.rb` 配方取決於 Stacks OpsWorks [堆疊組態和部署屬性](workingcookbook-json.md)的資料，這些屬性會安裝在每個執行個體上，並包含堆疊和任何部署應用程式的詳細資訊。物件的 `deploy` 屬性具有下列結構；為了方便，將其顯示為 JSON： ``` { ... "deploy": { "app1": { "application" : "short_name", ... } "app2": { ... } ... } } ``` deploy 節點包含每個部署應用程式 (以應用程式的短名命名) 的屬性。每個應用程式屬性都包含一組定義應用程式組態的屬性，例如文件根和應用程式類型。如需 `deploy` 屬性的清單，請參閱[deploy 屬性](attributes-json-deploy.md)。您可以使用 Chef 屬性語法，來代表配方中的堆疊組態和部署屬性值。例如，`[:deploy][:app1][:application]` 代表 app1 應用程式的短名。自訂配方取決於代表資料庫和 Amazon S3 存取資訊的數個堆疊組態和部署屬性： + Stacks 會在建立 MySQL OpsWorks layer 時定義資料庫連線屬性`[:deploy][:database][:host]`，例如。 + `[:photoapp][:dbtable]` 資料表名稱屬性定義於自訂技術指南的屬性檔案中，並設為 `foto`。 + 您必須使用自訂 JSON 來定義儲存貯體名稱屬性 `[:photobucket]`，並將該屬性新增至堆疊組態和部署屬性。 **定義 Amazon S3 儲存貯體名稱屬性** 1. 在 OpsWorks 堆疊**堆疊**頁面上，選擇**堆疊設定**，然後選擇**編輯**。 1. 在 **Configuration Management (組態管理)** 區段中，將存取資訊新增至 **Custom Chef JSON (自訂 Chef JSON)** 方塊。它看起來應該與下列類似： ``` { "photobucket" : "yourbucketname" } ``` 將 *yourbucketname* 取代為您在[步驟 1：建立 Amazon S3 儲存貯體](using-s3-bucket.md)中記錄的儲存貯體名稱。 ![\[Custom Chef cookbook configuration with Git repository and JSON settings.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/photoapp_walkthrough_json.png) OpsWorks Stacks 會將自訂 JSON 合併到堆疊組態和部署屬性，再將其安裝在堆疊的執行個體上；然後`appsetup.rb`可以從 `[:photobucket]` 屬性取得儲存貯體名稱。如果您想要變更儲存貯體，您不需要動用配方，而可以直接[覆寫屬性](workingcookbook-attributes.md)以提供新的儲存貯體名稱。 # 步驟 6：部署和執行 PhotoApp **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。這個範例也已為您實作應用程式，並將其存放在[公有 GitHub 儲存庫](https://github.com/amazonwebservices/opsworks-demo-php-photo-share-app)中。您只需要將應用程式新增至堆疊，並將其部署到應用程式伺服器，然後加以執行。 **將應用程式新增至堆疊，並將其部署到應用程式伺服器** 1. 開啟 **Apps (應用程式)** 頁面，然後選擇 **Add an app (新增應用程式)**。 1. 在 **Add App (新增應用程式)** 頁面上，執行下列作業： + 將 **Name (名稱)** 設定為 **PhotoApp**。 + 將 **App type (應用程式類型)** 設定為 **PHP**。 + 將 **Document root (文件根)** 設定為 **web**。 + 將 **Repository type (儲存庫類型)** 設定為 **Git**。 + 將 **Repository URL (儲存庫 URL)** 設定為 **git://github.com/awslabs/opsworks-demo-php-photo-share-app.git**。 + 選擇 **Add App (新增應用程式)**，以接受其他設定的預設值。 ![\[Form to add an app with fields for name, type, document root, and repository details.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/photoapp_walkthrough_app.png) 1. 在 **Apps (應用程式)** 頁面上，選擇 PhotoApp 應用程式 **Actions (動作)** 欄中的 **deploy (部署)**。 ![\[Apps page showing PhotoApp with deploy, edit, and delete options in the Actions column.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/photoapp_walkthrough_deploy.png) 1. 接受預設值，然後選擇 **Deploy (部署)** 將應用程式部署至伺服器。若要執行 PhotoApp，請前往**執行個體**頁面，然後選擇 PHP App Server 執行個體的公有 IP 地址。 ![\[PHP App Server instance details showing hostname, status, and public IP address.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/photoapp_walkthrough_run.png) 您應該會看到下列使用者界面。選擇**新增相片**，將相片存放在 Amazon S3 儲存貯體和後端資料存放區中的中繼資料。 ![\[User interface section titled "My Photos" with an "Add a Photo" button.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/photoapp_walkthrough_ui.png) # 使用 AWS CodePipeline 搭配 OpsWorks Stacks **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 [AWS CodePipeline](https://aws.amazon.com/codepipeline/) 可讓您建立持續交付管道，以追蹤來自 CodeCommit、Amazon Simple Storage Service (Amazon S3) 或 [GitHub](https://github.com/) 等來源的程式碼變更。您可以使用 CodePipeline 在 Chef 11.10、Chef 12 和 Chef 12.2 OpsWorks 堆疊上，自動將 Chef 技術指南和應用程式程式碼發佈至 Stacks。本節中的範例說明如何從 CodePipeline 建立和使用簡單的管道，做為您在 Stacks OpsWorks layer 上執行之程式碼的部署工具。 **注意** CodePipeline 和 OpsWorks Stacks 整合不支援部署至 Chef 11.4 和較舊的堆疊。 **Topics** + [AWS CodePipeline 搭配 OpsWorks Stacks - Chef 12 Stacks](other-services-cp-chef12.md) + [AWS CodePipeline 搭配 OpsWorks Stacks - Chef 11 Stacks](other-services-cp-chef11.md) # AWS CodePipeline 搭配 OpsWorks Stacks - Chef 12 Stacks **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 [AWS CodePipeline](https://aws.amazon.com/codepipeline/) 可讓您建立持續交付管道，以追蹤來自 CodeCommit、Amazon Simple Storage Service (Amazon S3) 或 [GitHub](https://github.com/) 等來源的程式碼變更。本主題中的範例說明如何從 CodePipeline 建立和使用簡單的管道，做為您在 OpsWorks Stacks layer 上執行之程式碼的部署工具。在此範例中，您會為簡單的 [Node.js 應用程式](samples/opsworks-nodejs-demo-app.zip)建立管道，然後指示 OpsWorks Stacks 在 Chef 12 堆疊中層中的所有執行個體上執行應用程式（在此案例中為單一執行個體）。 **注意** 本主題說明如何使用管道在 Chef 12 堆疊上執行與更新應用程式。如需如何使用管道在 Chef 11.10 堆疊上執行與更新應用程式的資訊，請參閱 [AWS CodePipeline 搭配 OpsWorks Stacks - Chef 11 Stacks](other-services-cp-chef11.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **Topics** + [先決條件](#w2ab1c14c73c19c11c11) + [其他支援的案例](#w2ab1c14c73c19c11c13) + [步驟 1：在 Stacks 中建立堆疊、 layer OpsWorks 和執行個體](other-services-cp-chef12-stack.md) + [步驟 2：設定您的堆疊和 layer 使用自訂的技術指南](other-services-cp-stackconfig.md) + [步驟 3：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef12-s3.md) + [步驟 4：將您的應用程式新增至 OpsWorks Stacks](other-services-cp-chef12-addapp.md) + [步驟 5：在 CodePipeline 中建立管道](other-services-cp-chef12-pipeline.md) + [步驟 6：驗證 OpsWorks Stacks 中的應用程式部署](other-services-cp-chef12-verify.md) + [步驟 7 （選用）：更新應用程式程式碼，以查看 CodePipeline 自動重新部署您的應用程式](other-services-cp-chef12-update.md) + [步驟 8 (選用)：清理資源](other-services-cp-chef12-cleanup.md) ## 先決條件在您開始本演練之前，請確定您有執行下列所有任務的管理員許可。您可以是已套用 **AdministratorAccess** 政策之群組的成員，也可以是具有下表所示許可和政策之群組的成員。作為安全最佳實務，您應該屬於具有執行下列任務許可的群組，而不是將必要的許可指派給個別使用者。如需在 IAM 中建立安全群組和指派許可給群組的詳細資訊，請參閱[建立 IAM 使用者群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html)。如需管理 OpsWorks Stacks 許可的詳細資訊，請參閱[最佳實務：管理許可](https://docs.aws.amazon.com/opsworks/latest/userguide/best-practices-permissions.html)。 | 許可 | 建議連接至群組的政策 | | --- | --- | | 在 Stacks OpsWorks 中建立和編輯堆疊、層和執行個體。 | AWSOpsWorks\$1FullAccess | | 在 CloudFormation中建立、編輯和執行範本。 | AmazonCloudFormationFullAccess | | 建立、編輯和存取 Amazon S3 儲存貯體。 | AmazonS3FullAccess | | 在 CodePipeline 中建立、編輯和執行管道，尤其是使用 Stacks OpsWorks 做為提供者的管道。 | AWSCodePipeline\$1FullAccess | 您也必須有 Amazon EC2 金鑰對。當您執行在此演練中建立範例堆疊、 layer 和執行個體的 CloudFormation 範本時，系統會提示您提供此金鑰對的名稱。如需在 Amazon EC2 主控台中取得金鑰對的詳細資訊，請參閱 Amazon EC2 文件中的[建立金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair)。金鑰對必須位於美國東部（維吉尼亞北部）區域。如果您在該區域中已有金鑰對，則可以使用該現有金鑰對。 ## 其他支援的案例本演練會建立包含一個 **Source (來源)** 和一個 **Deploy (部署)** 階段的簡易管道。不過，您可以建立使用 Stacks OpsWorks 做為提供者的更複雜管道。下列是支援的管道和案例範例： + 您可以編輯管道，以將 Chef 技術指南新增至 **Source (來源)** 階段，以及將已更新技術指南的相關聯目標新增至 **Deploy (部署)** 階段。在此情況下，您可以新增 **Deploy (部署)** 動作，以在您變更來源時觸發技術指南更新。已更新的技術指南會比應用程式先部署。 + 您可以使用自訂技術指南和多個應用程式建立複雜的管道，並部署到 Stacks OpsWorks 堆疊。該管道會同時追蹤對應用程式和技術指南來源所做的變更，並在您變更後重新部署。下圖示範類似的複雜管道範例： ![\[Pipeline diagram showing Source stage with Amazon S3 inputs and Beta stage with AWS OpsWorks outputs.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_complexpipeline.png) 如需使用 CodePipeline 的詳細資訊，請參閱 [CodePipeline 使用者指南](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)。 # 步驟 1：在 Stacks 中建立堆疊、 layer OpsWorks 和執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要使用 OpsWorks Stacks 做為管道的部署提供者，您必須先在 layer 中擁有堆疊、 layer 和至少一個執行個體。雖然您可以遵循 Linux OpsWorks Stacks [入門](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-linux.html)或 [Windows Stacks 入門中的指示在 Stacks 中建立堆疊](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-windows.html)，但為了節省您的時間，此範例會使用 AWS CloudFormation 範本來建立以 Linux 為基礎的 Chef 12 堆疊、 layer 和執行個體。此範本建立的執行個體會執行 Amazon Linux 2016.03，且執行個體類型為 `c3.large`。雖然範本不會設定您的堆疊使用自訂技術指南，但您稍後仍會在演練中執行此作業。 **重要** CloudFormation 範本必須與稍後上傳應用程式的 Amazon S3 儲存貯體位於相同的區域，以及稍後在 CodePipeline 中建立管道的相同區域。目前，CodePipeline 僅支援美國東部（維吉尼亞北部）區域 (us-east-1) 的 OpsWorks Stacks 供應商。此演練中的所有資源都應在美國東部（維吉尼亞北部）區域建立。如果堆疊建立失敗，您可能即將達到您帳戶的 IAM 角色允許數目上限。如果您的帳戶無法啟動執行個體類型為 `c3.large` 的執行個體，堆疊建立也可能失敗。例如，如果您使用 AWS 免費方案，您可能會收到錯誤，例如 `Root device type: must be included in EBS`。如果您的帳戶對您可以建立的執行個體類型有限制，例如 AWS 免費方案施加的限制，請嘗試將範本執行個體區塊中的 `InstanceType` 參數值變更為您的帳戶可以使用的執行個體類型。 **使用建立堆疊、 layer 和執行個體 CloudFormation** 1. 將下列 CloudFormation 範本複製到新的純文字文件。將檔案儲存到本機電腦中方便使用的位置，並將其命名為 **NewOpsWorksStack.template** 或您方便使用的其他名稱。 ``` { "AWSTemplateFormatVersion": "2010-09-09", "Mappings": { "Region2Principal": { "us-east-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "us-west-2": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "us-west-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "eu-west-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-southeast-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-northeast-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-northeast-2": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-southeast-2": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "sa-east-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "cn-north-1": { "EC2Principal": "ec2.amazonaws.com.rproxy.govskope.ca.cn", "OpsWorksPrincipal": "opsworks.amazonaws.com.rproxy.govskope.ca.cn" }, "eu-central-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" } } }, "Parameters": { "EC2KeyPairName": { "Type": "String", "Description": "The name of an existing EC2 key pair that lets you use SSH to connect to the OpsWorks instance." } }, "Resources": { "CPOpsDeploySecGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription" : "Lets you manage OpsWorks instances to which you deploy apps with CodePipeline" } }, "CPOpsDeploySecGroupIngressHTTP": { "Type": "AWS::EC2::SecurityGroupIngress", "Properties" : { "IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0", "GroupId": { "Fn::GetAtt": [ "CPOpsDeploySecGroup", "GroupId" ] } } }, "CPOpsDeploySecGroupIngressSSH": { "Type": "AWS::EC2::SecurityGroupIngress", "Properties" : { "IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0", "GroupId": { "Fn::GetAtt": [ "CPOpsDeploySecGroup", "GroupId" ] } } }, "MyStack": { "Type": "AWS::OpsWorks::Stack", "Properties": { "Name": { "Ref": "AWS::StackName" }, "ServiceRoleArn": { "Fn::GetAtt": [ "OpsWorksServiceRole", "Arn" ] }, "ConfigurationManager" : { "Name": "Chef","Version": "12" }, "DefaultOs": "Amazon Linux 2016.03", "DefaultInstanceProfileArn": { "Fn::GetAtt": [ "OpsWorksInstanceProfile", "Arn" ] }, "UseCustomCookbooks": "false" } }, "MyLayer": { "Type": "AWS::OpsWorks::Layer", "Properties": { "StackId": { "Ref": "MyStack" }, "Name": "Node.js App Server", "Type": "custom", "Shortname": "app1", "EnableAutoHealing": "true", "AutoAssignElasticIps": "false", "AutoAssignPublicIps": "true", "CustomSecurityGroupIds": [ { "Fn::GetAtt": [ "CPOpsDeploySecGroup", "GroupId" ] } ] }, "DependsOn": [ "MyStack", "CPOpsDeploySecGroup" ] }, "OpsWorksServiceRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ { "Fn::FindInMap": [ "Region2Principal", { "Ref": "AWS::Region" }, "OpsWorksPrincipal" ] } ] }, "Action": [ "sts:AssumeRole" ] } ] }, "Path": "/", "Policies": [ { "PolicyName": "opsworks-service", "PolicyDocument": { "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "iam:PassRole", "cloudwatch:GetMetricStatistics", "elasticloadbalancing:*" ], "Resource": "*" } ] } } ] } }, "OpsWorksInstanceProfile": { "Type": "AWS::IAM::InstanceProfile", "Properties": { "Path": "/", "Roles": [ { "Ref": "OpsWorksInstanceRole" } ] } }, "OpsWorksInstanceRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ { "Fn::FindInMap": [ "Region2Principal", { "Ref": "AWS::Region" }, "EC2Principal" ] } ] }, "Action": [ "sts:AssumeRole" ] } ] }, "Path": "/", "Policies": [ { "PolicyName": "s3-get", "PolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "*" } ] } } ] } }, "myinstance": { "Type": "AWS::OpsWorks::Instance", "Properties": { "LayerIds": [ { "Ref": "MyLayer" } ], "StackId": { "Ref": "MyStack" }, "InstanceType": "c3.large", "SshKeyName": { "Ref": "EC2KeyPairName" } } } }, "Outputs": { "StackId": { "Description": "Stack ID for the newly created AWS OpsWorks stack", "Value": { "Ref": "MyStack" } } } } ``` 1. 登入 AWS 管理主控台並在 https：//[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) 開啟 CloudFormation 主控台。 1. 在 CloudFormation 首頁上，選擇**建立堆疊**。 1. 在 **Select Template (選取範本)** 頁面上的 **Choose a template (選擇範本)** 區域中，選擇 **Upload a template to Amazon S3 (將範本上傳至 Amazon S3)**，然後選擇 **Browse (瀏覽)**。 1. 瀏覽至您在步驟 1 中儲存的 CloudFormation 範本，然後選擇**開啟**。在 **Select Template** (選取範本) 頁面上，請選擇 **Next** (下一步)。 ![\[選取 AWS CloudFormation Create Stack 精靈的範本頁面。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_cfstackcreate.png) 1. 在 **Specify Details (指定詳細資訊)** 頁面中，將堆疊命名為 **CodePipelineDemo** 或您帳戶唯一的任何堆疊名稱。如果您選擇不同的堆疊名稱，請變更整個本演練中該堆疊的名稱。 1. 在**參數**區域中，提供您要用來在建立 Stacks 執行個體之後存取的 EC2 OpsWorks 金鑰對名稱。選擇**下一步**。 1. 在**選項**頁面上，選擇**下一步**。(本演練不需要執行此頁面上的設定。) 1. 您在此演練中使用的 CloudFormation 範本會建立 IAM 角色、執行個體描述檔和執行個體。 **重要** 在選擇**建立**之前，請選擇**成本**來預估使用此範本 AWS 建立資源時可能衍生的費用。如果可以建立 IAM 資源，請選取**我確認此範本可能會導致 AWS CloudFormation 建立 IAM 資源**核取方塊，然後選擇**建立**。如果無法建立 IAM 資源，則無法繼續此程序。 1. 在 CloudFormation 儀表板上，您可以檢視建立堆疊的進度。請先等候 **Status (狀態)** 欄位顯示 **CREATE\$1COMPLETE** 後，再繼續進行下一步。 ![\[AWS CloudFormation 儀表板顯示堆疊建立。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_createstack12.png) **驗證在 Stacks OpsWorks 中建立堆疊** 1. 在 https：//[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) 開啟 OpsWorks 主控台。 1. 在 OpsWorks Stacks 儀表板上，檢視您建立的堆疊。 ![\[AWS OpsWorks 儀表板顯示堆疊建立。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_verifystack12.png) 1. 開啟堆疊並檢視 layer 和執行個體。請注意，層和執行個體是使用 CloudFormation 範本中提供的名稱和其他中繼資料建立的。您已準備好設定您的堆疊和 layer 使用自訂的 Chef 技術指南和配方。 # 步驟 2：設定您的堆疊和 layer 使用自訂的技術指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Stacks 中的 Chef 12 OpsWorks 堆疊需要您自己或社群建立的技術指南來建置自訂應用程式層。在本演練中，您可以指向包含一組 [Chef 技術指南](https://docs.chef.io/cookbooks.html)和 Chef 配方的儲存庫。這些配方會在您的執行個體上安裝 Node.js 套件及其相依性。您會使用其他 Chef 配方來部署您即將在[步驟 4：將您的應用程式新增至 OpsWorks Stacks](other-services-cp-chef12-addapp.md)中準備的 Node.js 應用程式。您在此步驟中指定的 Chef 配方會在 CodePipeline 部署應用程式的新版本時執行。 1. 在 OpsWorks Stacks 主控台中，開啟您在中建立的堆疊[步驟 1：在 Stacks 中建立堆疊、 layer OpsWorks 和執行個體](other-services-cp-chef12-stack.md)。選擇 **Stack Settings (堆疊設定)**，然後選擇 **Edit (編輯)**。 1. 將 **Use custom Chef cookbooks (使用自訂 Chef 技術指南)** 設為 **Yes (是)**。這會顯示相關的自訂技術指南設定。 1. 從 **Repository type (儲存庫類型)** 下拉式清單，選擇 **S3 Archive (S3 封存)**。若要同時使用 CodePipeline 和 OpsWorks，您的技術指南來源必須是 S3。 1. 針對 **Repository URL (儲存庫 URL)**，指定 **https://s3.amazonaws.com/opsworks-demo-assets/opsworks-linux-demo-cookbooks-nodejs.tar.gz**。您的設定應該類似下列： ![\[使用自訂 Chef 技術指南設定。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_usecustomcook.png) 1. 選擇**儲存**。 1. 在導覽視窗中，選擇 **圖層**。 1. 選擇您在**中設定之 layer 的 **Settings (設定)[步驟 1：在 Stacks 中建立堆疊、 layer OpsWorks 和執行個體](other-services-cp-chef12-stack.md)。 1. 在 **General Settings (一般設定)** 標籤中，確定 layer 名稱為 **Node.js App Server**，layer 簡稱為 **app1**。選擇 **Recipes (配方)**。 1. 在 **Recipes (配方)** 標籤中，將 **nodejs\$1demo** 指定為您要在 **Deploy (部署)** 生命週期事件中執行的配方。選擇**儲存**。 1. 在 **Security (安全性)** 標籤中，從 **Security groups (安全群組)** 下拉式清單，選擇 **AWS-OpsWorks-Webapp** 安全群組。 1. 選擇**儲存**。 # 步驟 3：將應用程式碼上傳至 Amazon S3 儲存貯體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。由於您必須提供程式碼儲存庫的連結做為管道設定的一部分，因此在建立管道前，請先準備好程式碼儲存庫。在此逐步解說中，您將 Node.js 應用程式上傳至 Amazon S3 儲存貯體。雖然 CodePipeline 可以直接從 GitHub 或 CodeCommit 使用程式碼做為來源，但本演練示範如何使用 Amazon S3 儲存貯體。在此演練中，您將範例 [Node.js 應用程式](samples/opsworks-nodejs-demo-app.zip)上傳到您自己的 Amazon S3 儲存貯體，以便您可以變更應用程式。您在此步驟中建立的 Amazon S3 儲存貯體可讓 CodePipeline 偵測應用程式程式碼的變更，並自動部署變更的應用程式。您也可以視需要使用現有的儲存貯體。請確定儲存貯體符合 CodePipeline 文件中的[簡易管道演練 (Amazon S3 儲存貯體）](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html) 中所述的條件。 **重要** Amazon S3 儲存貯體必須位於您稍後將建立管道的相同區域。目前，CodePipeline 僅支援美國東部（維吉尼亞北部）區域 (us-east-1) 的 OpsWorks Stacks 供應商。此演練中的所有資源都應在美國東部（維吉尼亞北部）區域建立。儲存貯體也必須進行版本控制，因為 CodePipeline 需要版本控制來源。如需詳細資訊，請參閱[使用版本控制](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)。 **將應用程式上傳至 Amazon S3 儲存貯體** 1. 下載 OpsWorks Stacks 範例 [Node.js 應用程式的](samples/opsworks-nodejs-demo-app.zip) ZIP 檔案，並將其儲存至本機電腦上方便的位置。 1. 開啟位於 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) 的 Amazon S3 主控台。 1. 選擇 **Create Bucket** (建立儲存貯體)。 1. 在 **Create a Bucket - Select a Bucket Name and Region (建立儲存貯體 - 選取儲存貯體名稱和區域)** 頁面上，針對 **Bucket Name (儲存貯體名稱)**，輸入儲存貯體的唯一名稱。儲存貯體名稱在所有 AWS 帳戶中必須是唯一的，而不只是在您自己的帳戶中。本演練使用的名稱是 **my-appbucket**，但您可使用 `my-appbucket-yearmonthday`，讓您的儲存貯體名稱成為唯一名稱。從 **Region (區域)** 下拉式清單，選擇 **US Standard (美國標準)**，然後選擇 **Create (建立)**。**US Standard (美國標準)** 相當於 `us-east-1`。 ![\[S3 Create a Bucket (建立儲存貯體) 頁面。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_s3bucket.png) 1. 從 **All Buckets (所有儲存貯體)** 清單選擇您建立的儲存貯體。 1. 在儲存貯體頁面上，選擇 **Upload (上傳)**。 1. 在 **Upload - Select Files and Folders (上傳 - 選取檔案和資料夾)** 頁面上，選擇 **Add files (新增檔案)**。瀏覽您在步驟 1 中儲存的 ZIP 檔案，選擇 **Open (開啟)**，再選擇 **Start Upload (開始上傳)**。 ![\[S3 Select Files and Folders (選取檔案和資料夾) 對話方塊\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_uploadzip12.png) 1. 在上傳完成後，從您儲存貯體中的檔案清單選取 ZIP 檔案，然後選擇 **Properties (屬性)**。 1. 在 **Properties (屬性)** 窗格中，複製您 ZIP 檔案的連結，並記下此連結。您將需要儲存貯體名稱和此連結的 ZIP 檔案名稱部分來建立管道。 # 步驟 4：將您的應用程式新增至 OpsWorks Stacks **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在 CodePipeline 中建立管道之前，請將 Node.js 測試應用程式新增至 OpsWorks Stacks。建立管道時，您需要選取已新增至 Stacks OpsWorks 的應用程式。準備好先前程序的步驟 9 中的 Amazon S3 儲存貯體連結。您將需要存放測試應用程式所在的儲存貯體連結來完成此程序。 **將應用程式新增至 OpsWorks Stacks** 1. 在 OpsWorks Stacks 主控台中，開啟 **CodePipelineDemo**，然後在導覽窗格中選擇**應用程式**。 1. 選擇 **Add app (新增應用程式)**。 1. 在 **Add App (新增應用程式)** 頁面上，提供下列資訊： 1. 為應用程式指定名稱。本逐步教學使用的名稱是 `Node.js Demo App`。 1. 針對 **Data source type (資料來源類型)**，選擇 **None (無)**。此應用程式不需要外部資料庫或資料來源。 1. 在 **Repository type (儲存庫類型)** 下拉式清單中，選擇 **S3 Archive (S3 封存)**。 1. 在 **Repository URL (儲存庫 URL)** 字串方格中，貼上您在[步驟 3：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef12-s3.md)的步驟 9 中複製的 URL。您的表單應類似下列內容： ![\[Add App (新增應用程式) 頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_addapp12ops.png) 1. 您不需要變更此表單中的任何其他設定。選擇 **Add App (新增應用程式)**。 1. 當 **Node.js Demo App (Node.js 示範應用程式)** 應用程式出現在 **Apps (應用程式)** 頁面的清單中時，請繼續下一項程序 ([步驟 5：在 CodePipeline 中建立管道](other-services-cp-chef12-pipeline.md))。 # 步驟 5：在 CodePipeline 中建立管道 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在 Stacks 中設定了具有 layer OpsWorks 和至少一個執行個體的堆疊之後，請使用 OpsWorks Stacks 在 CodePipeline 中建立管道，以將應用程式或 Chef 技術指南部署到您的 OpsWorks Stacks 資源。 **建立管道** 1. 前往 [https://console.aws.amazon.com/codepipeline/](https://console.aws.amazon.com/codepipeline/) 開啟 CodePipeline 主控台。 1. 選擇 **Create pipeline (建立管道)**。 1. 在 ** CodePipeline 入門**頁面上，輸入 **MyOpsWorksPipeline**或您的帳戶唯一的任何其他管道名稱，然後選擇**下一步**。 1. 在 **Source Location (來源位置)** 頁面上，從 **Source provider (來源提供者)** 下拉式清單選取 **Amazon S3**。 1. 在 **Amazon S3 詳細資訊**區域中，以格式輸入您的 Amazon S3 儲存貯體路徑**s3://*bucket-name*/*file name***。參考您在[步驟 3：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef12-s3.md)的步驟 9 中記下的連結。在本演練中，路徑為 `s3://my-appbucket/opsworks-nodejs-demo-app.zip`。選擇 **下一個步驟**。 ![\[AWS CodePipeline 來源和提供者\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_source12.png) 1. 在 **Build (組建)** 頁面上，從下拉式清單選擇 **No Build (無組建)**，然後選擇 **Next step (下一步)**。 1. 在 **Deploy (部署)** 頁面上，選擇 **OpsWorks Stacks** 做為部署提供者。 ![\[Deploy configuration form for AWS OpsWorks Stacks with fields for stack, layer, and app selection.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_cpprovider12.png) 1. 在 **Stack (堆疊)** 欄位中輸入 `CodePipelineDemo`，或您在[步驟 1：在 Stacks 中建立堆疊、 layer OpsWorks 和執行個體](other-services-cp-chef12-stack.md)中建立的堆疊名稱。 1. 在 **Layer** 欄位中輸入 `Node.js App Server`，或您在[步驟 1：在 Stacks 中建立堆疊、 layer OpsWorks 和執行個體](other-services-cp-chef12-stack.md)中建立的 layer 名稱。 1. 在**應用程式**欄位中，選取您在中上傳到 Amazon S3 的應用程式[步驟 3：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef12-s3.md)，然後選擇**下一步**。 1. 在**AWS 服務角色**頁面上，選擇**建立角色**。新的視窗隨即開啟，其中包含 IAM 主控台頁面，說明將為您建立的角色：`AWS-CodePipeline-Service`。從 **Policy name (政策名稱)** 下拉式清單，選擇 **Create new policy (建立新政策)**。請確認政策文件包含下列內容。如有需要，請選擇 **Edit (編輯)** 來變更政策文件。 ``` { "Statement": [ { "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetBucketVersioning" ], "Resource": "*", "Effect": "Allow" }, { "Action": "opsworks:*", "Resource": "*", "Effect": "Allow" } ] } ``` 完成政策文件的變更後，選擇 **Allow (允許)**。您的變更會顯示在 IAM 主控台中。 ![\[IAM role summary with AWS-CodePipeline-Service role and policy document editor.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_iamrole.png) **注意** 如果角色建立失敗，可能是因為您已經有名為 **AWS-CodePipeline-Service** 的 IAM 角色。如果您在 2016 年 5 月之前已使用 **AWS-CodePipeline-Service** 角色，該角色可能沒有使用 OpsWorks Stacks 做為部署提供者的許可。在本例中，您必須更新此政策陳述式，如本步驟中所示。若您看到錯誤訊息，請回到此步驟的開頭，並選擇 **Use existing role (使用現有的角色)** 而非 **Create role (建立角色)**。如果您使用現有的角色，該角色應會連接含有此步驟中所示許可的政策。如需服務角色及其政策陳述式的詳細資訊，請參閱[編輯 IAM 服務角色的政策](https://docs.aws.amazon.com/codepipeline/latest/userguide/access-permissions.html#how-to-custom-role)。 1. 如果角色建立程序成功，IAM 頁面會關閉，而且您會返回**AWS 服務角色**頁面。選擇 **下一個步驟**。 1. 在 **Review your pipeline (檢閱管道)** 頁面上，確認頁面顯示的選項，然後選擇 **Create pipeline (建立管道)**。 1. 當管道就緒時，其應會開始尋找來源碼，並自動將應用程式部署到堆疊。此程序需要幾分鐘的時間。 # 步驟 6：驗證 OpsWorks Stacks 中的應用程式部署 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要驗證 CodePipeline 已將 Node.js 應用程式部署到您的堆疊，請登入您在中建立的執行個體[步驟 1：在 Stacks 中建立堆疊、 layer OpsWorks 和執行個體](other-services-cp-chef12-stack.md)。您應該可以看到並使用 Node.js Web 應用程式。 **驗證 Stacks OpsWorks 執行個體中的應用程式部署** 1. 在 https：//[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) 開啟 OpsWorks 主控台。 1. 在 OpsWorks Stacks 儀表板上，選擇 **CodePipelineDemo**，然後選擇 **Node.js App Server**。 1. 在導覽窗格中，選擇 **Instances (執行個體)**，然後選擇您建立之執行個體的公有 IP 地址，以檢視 Web 應用程式。 ![\[OpsWorks instance management interface showing one online Node.js App Server instance.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_instanceapp12.png) 該應用程式會顯示在新的瀏覽器標籤中。 ![\[Congratulatory message for deploying first app with AWS OpsWorks, featuring stylized landmarks.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_successnode12.png) # 步驟 7 （選用）：更新應用程式程式碼，以查看 CodePipeline 自動重新部署您的應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當您使用 CodePipeline 對已部署的應用程式或技術指南中的程式碼進行變更時，已更新的成品將由 CodePipeline 自動部署到您的目標執行個體（在此情況下為目標 Stacks OpsWorks 堆疊）。本節示範在您更新範例 Node.js 應用程式中的程式碼時，自動重新部署。如果您仍將本演練的應用程式程式碼存放在本機，而且在您開始本演練後沒有人變更過程式碼，您可以略過此程序的步驟 1-4。 **在範例應用程式中編輯程式碼** 1. 登入 AWS 管理主控台，並在 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)：// 開啟 Amazon S3 主控台。 1. 開啟您存放範例 Node.js 應用程式的儲存貯體。 ![\[AWS S3 bucket interface showing a single zip file in the my-appbucket folder.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_editcodeS312.png) 1. 選取內含應用程式的 ZIP 檔案。在 **Actions (動作)** 選單上，選擇 **Download (下載)**。 1. 在對話方塊中，(按一下右鍵) 開啟內容功能表，選擇 **Download (下載)**，然後將 ZIP 檔案儲存到方便使用的位置。選擇**確定**。 1. 將 ZIP 檔案的內容解壓縮到方便使用的位置。您可能需要變更已解壓縮資料夾及其子資料夾和內容的許可，以允許編輯。在 `opsworks-nodejs-demo-app\views` 資料夾中，開啟 `header.html` 檔案編輯。 1. 搜尋片語 `You just deployed your first app with`。使用 `updated` 取代 `deployed`。在下一行中，將 `OpsWorks.` 變更成 `OpsWorks and AWS CodePipeline.` 請不要編輯文字以外的內容。 ![\[Congratulatory message for updating first app with OpsWorks and AWS CodePipeline.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_editheader12.png) 1. 儲存並關閉 `header.html` 檔案。 1. 壓縮 `opsworks-nodejs-demo-app` 資料夾，並將 ZIP 檔案儲存在方便的位置。請勿變更 ZIP 檔案名稱。 1. 將新的 ZIP 檔案上傳至您的 Amazon S3 儲存貯體。在本演練中，儲存貯體的名稱為 `my-appbucket`。 1. 開啟 CodePipeline 主控台，並開啟您的 OpsWorks Stacks 管道 (**MyOpsWorksPipeline**)。選擇 **Release Change (版本變更)**。（您可以等待 CodePipeline 偵測來自 Amazon S3 儲存貯體中應用程式更新版本的程式碼變更。為了節省您的時間，本演練會指示您直接選擇**版本變更**。) 1. 觀察 CodePipeline 執行管道的階段。首先，CodePipeline 會偵測來源成品的變更。 ![\[Pipeline diagram showing Source stage in progress and Beta stage succeeded 13 days ago.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_cpupdatesource.png) CodePipeline 會將更新的程式碼推送至 Stacks OpsWorks 中的堆疊。 ![\[Pipeline view showing Source stage succeeded and Beta stage in progress.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_updatestack.png) 1. 當管道的兩個階段都成功完成後，開啟 OpsWorks Stacks 中的堆疊。 1. 在堆疊屬性頁面中，選擇 **Instances (執行個體)**。 1. 在 **Public IP (公有 IP)** 欄位中，選擇您執行個體的公有 IP 地址，以檢視更新的應用程式文字。 ![\[Congratulatory message for updating an app with AWS OpsWorks and CodePipeline, with stylized icons.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_successedit12.png) # 步驟 8 (選用)：清理資源 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。為了協助避免 AWS 您的帳戶產生不必要的費用，您可以刪除您用於本演練 AWS 的資源。這些 AWS 資源包括 OpsWorks Stacks 堆疊、IAM 角色和執行個體描述檔，以及您在 CodePipeline 中建立的管道。不過，當您繼續進一步了解 OpsWorks Stacks 和 CodePipeline 時，建議您繼續使用這些 AWS 資源。如果您要保留這些資源，您已完成本演練。 **從堆疊刪除應用程式** 由於您未在 CloudFormation 範本中建立或套用應用程式，請先刪除 Node.js 測試應用程式，再刪除堆疊 CloudFormation。 1. 在 OpsWorks Stacks 主控台的服務導覽窗格中，選擇**應用程式**。 1. 在 **Apps (應用程式)** 頁面上，選取 **Node.js Demo App (Node.js 示範應用程式)**，然後在 **Actions (動作)** 中，選擇 **delete (刪除)**。系統提示您確認時，請選擇 **Delete**。 OpsWorks Stacks 會刪除應用程式。 **刪除堆疊** 由於您透過執行 CloudFormation 範本建立堆疊，因此您可以在 CloudFormation 主控台中刪除堆疊，包括範本建立的 layer、執行個體、執行個體描述檔和安全群組。 1. 開啟 CloudFormation 主控台。 1. 在 CloudFormation 主控台儀表板中，選取您建立的堆疊。在 **Actions (動作)** 選單上，選擇 **Delete Stack (刪除堆疊)**。出現確認提示時，選擇 **Yes, Delete (是，刪除)**。 1. 等待堆疊的 **Status (狀態)** 欄位中顯示 **DELETE\$1COMPLETE**。 **刪除管道** 1. 開啟 CodePipeline 主控台。 1. 在 CodePipeline 儀表板中，選擇您為此演練建立的管道。 1. 在管道頁面上，選擇 **Edit (編輯)**。 1. 在 **Edit (編輯)** 頁面上，選擇 **Delete (刪除)**。出現確認提示時，選擇 **Delete (刪除)**。 # AWS CodePipeline 搭配 OpsWorks Stacks - Chef 11 Stacks **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 [AWS CodePipeline](https://aws.amazon.com/codepipeline/) 可讓您建立持續交付管道，以追蹤來自 CodeCommit、Amazon Simple Storage Service (Amazon S3) 或 [GitHub](https://github.com/) 等來源的程式碼變更。本主題中的範例說明如何從 CodePipeline 建立並使用簡單的管道，做為您在 OpsWorks Stacks layer 上執行之程式碼的部署工具。在此範例中，您會為簡單的 [PHP 應用程式](https://github.com/awslabs/opsworks-demo-php-simple-app)建立管道，然後指示 OpsWorks Stacks 在 Chef 11.10 堆疊中層中的所有執行個體上執行應用程式（在此案例中為單一執行個體）。 **注意** 本主題說明如何使用管道在 Chef 11.10 堆疊上執行與更新應用程式。如需如何使用管道在 Chef 12 堆疊上執行與更新應用程式的資訊，請參閱 [AWS CodePipeline 搭配 OpsWorks Stacks - Chef 12 Stacks](other-services-cp-chef12.md)。傳遞至 Amazon S3 儲存貯體的內容可能包含客戶內容。如需移除敏感資料的詳細資訊，請參閱[如何清空 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html)或[如何刪除 S3 儲存貯體？](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)。 **Topics** + [先決條件](#w2ab1c14c73c19c13c11) + [其他支援的案例](#w2ab1c14c73c19c13c13) + [步驟 1：在 OpsWorks Stacks 中建立堆疊、layer 和執行個體](other-services-cp-chef11-stack.md) + [步驟 2：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef11-s3.md) + [步驟 3：將您的應用程式新增至 OpsWorks Stacks](other-services-cp-chef11-addapp.md) + [步驟 4：在 CodePipeline 中建立管道](other-services-cp-chef11-pipeline.md) + [步驟 5：在 Stacks OpsWorks 中驗證應用程式部署](other-services-cp-chef11-verify.md) + [步驟 6 （選用）：更新應用程式程式碼，以查看 CodePipeline 自動重新部署您的應用程式](other-services-cp-chef11-update.md) + [步驟 7 (選用)：清除資源](other-services-cp-chef11-cleanup.md) ## 先決條件在您開始本演練之前，請確定您具有執行下列所有任務的管理員許可。您可以是已套用 **AdministratorAccess** 政策之群組的成員，也可以是具有下表所示許可和政策之群組的成員。作為安全最佳實務，您應該屬於具有執行下列任務許可的群組，而不是將必要的許可指派給個別使用者。如需在 IAM 中建立安全群組和指派許可給群組的詳細資訊，請參閱[建立 IAM 使用者群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups_create.html)。如需管理 OpsWorks Stacks 許可的詳細資訊，請參閱[最佳實務：管理許可](https://docs.aws.amazon.com/opsworks/latest/userguide/best-practices-permissions.html)。 | 許可 | 建議連接至群組的政策 | | --- | --- | | 在 Stacks OpsWorks 中建立和編輯堆疊、層和執行個體。 | AWSOpsWorks\$1FullAccess | | 在 CloudFormation中建立、編輯和執行範本。 | AmazonCloudFormationFullAccess | | 建立、編輯和存取 Amazon S3 儲存貯體。 | AmazonS3FullAccess | | 在 CodePipeline 中建立、編輯和執行管道，尤其是使用 Stacks OpsWorks 做為提供者的管道。 | AWSCodePipeline\$1FullAccess | 您也必須有 Amazon EC2 金鑰對。當您執行在此演練中建立範例堆疊、 layer 和執行個體的 CloudFormation 範本時，系統會提示您提供此金鑰對的名稱。如需在 Amazon EC2 主控台中取得金鑰對的詳細資訊，請參閱 Amazon EC2 文件中的[建立金鑰對](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair)。金鑰對應該位於美國東部（維吉尼亞北部）區域。如果您在該區域中已有金鑰對，則可以使用該現有金鑰對。 ## 其他支援的案例本演練會建立包含一個 **Source (來源)** 和一個 **Deploy (部署)** 階段的簡易管道。不過，您可以建立使用 Stacks OpsWorks 做為供應商的更複雜管道。下列是支援的管道和案例範例： + 您可以編輯管道，以將 Chef 技術指南新增至 **Source (來源)** 階段，以及將已更新技術指南的相關聯目標新增至 **Deploy (部署)** 階段。在此情況下，您可以新增 **Deploy (部署)** 動作，以在您變更來源時觸發技術指南更新。已更新的技術指南會比應用程式先部署。 + 您可以使用自訂技術指南和多個應用程式建立複雜的管道，並部署到 Stacks OpsWorks 堆疊。該管道會同時追蹤對應用程式和技術指南來源所做的變更，並在您變更後重新部署。下圖示範類似的複雜管道範例： ![\[Pipeline diagram showing Source stage with Amazon S3 inputs and Beta stage with AWS OpsWorks outputs.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_complexpipeline.png) 如需使用 CodePipeline 的詳細資訊，請參閱 [CodePipeline 文件](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)。 # 步驟 1：在 OpsWorks Stacks 中建立堆疊、layer 和執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要使用 OpsWorks Stacks 做為管道的部署提供者，您必須先在 layer 中擁有堆疊、 layer 和至少一個執行個體。雖然您可以依照 Linux OpsWorks Stacks [入門](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-linux.html)或 [Windows Stacks 入門中的指示在 Stacks 中建立堆疊](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-windows.html)，但為了節省您的時間，此範例會使用 AWS CloudFormation 範本來建立 Linux Chef 11.10 堆疊、 layer 和執行個體。此範本建立的執行個體會執行 Amazon Linux 2016.03，且執行個體類型為 `c3.large`。 **重要** CloudFormation 範本必須與稍後上傳應用程式的 Amazon S3 儲存貯體位於相同的區域，以及稍後在 CodePipeline 中建立管道的相同區域。目前，CodePipeline 僅支援美國東部（維吉尼亞北部）區域 (us-east-1) 的 OpsWorks Stacks 供應商。此演練中的所有資源都應在美國東部（維吉尼亞北部）區域建立。如果堆疊建立失敗，您可能即將達到您帳戶的 IAM 角色允許數目上限。如果您的帳戶無法啟動執行個體類型為 `c3.large` 的執行個體，堆疊建立也可能失敗。例如，如果您使用 AWS 免費方案，您可能會收到錯誤，例如 `Root device type: must be included in EBS`。如果您的帳戶對您可以建立的執行個體類型有限制，例如 AWS 免費方案施加的限制，請嘗試將範本執行個體區塊中的 `InstanceType` 參數值變更為您的帳戶可以使用的執行個體類型。 **使用建立堆疊、 layer 和執行個體 CloudFormation** 1. 將下列 CloudFormation 範本複製到新的純文字文件。將檔案儲存到本機電腦中方便使用的位置，並將其命名為 **NewOpsWorksStack.template** 或您方便使用的其他名稱。 ``` { "AWSTemplateFormatVersion": "2010-09-09", "Mappings": { "Region2Principal": { "us-east-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "us-west-2": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "us-west-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "eu-west-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-southeast-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-northeast-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-northeast-2": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "ap-southeast-2": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "sa-east-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" }, "cn-north-1": { "EC2Principal": "ec2.amazonaws.com.rproxy.govskope.ca.cn", "OpsWorksPrincipal": "opsworks.amazonaws.com.rproxy.govskope.ca.cn" }, "eu-central-1": { "EC2Principal": "ec2.amazonaws.com", "OpsWorksPrincipal": "opsworks.amazonaws.com" } } }, "Parameters": { "EC2KeyPairName": { "Type": "String", "Description": "The name of an existing EC2 key pair that allows you to use SSH to connect to the OpsWorks instance." } }, "Resources": { "CPOpsDeploySecGroup": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "GroupDescription" : "Lets you manage OpsWorks instances deployed to by CodePipeline" } }, "CPOpsDeploySecGroupIngressHTTP": { "Type": "AWS::EC2::SecurityGroupIngress", "Properties" : { "IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0", "GroupId": { "Fn::GetAtt": [ "CPOpsDeploySecGroup", "GroupId" ] } } }, "CPOpsDeploySecGroupIngressSSH": { "Type": "AWS::EC2::SecurityGroupIngress", "Properties" : { "IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0", "GroupId": { "Fn::GetAtt": [ "CPOpsDeploySecGroup", "GroupId" ] } } }, "MyStack": { "Type": "AWS::OpsWorks::Stack", "Properties": { "Name": { "Ref": "AWS::StackName" }, "ServiceRoleArn": { "Fn::GetAtt": [ "OpsWorksServiceRole", "Arn" ] }, "ConfigurationManager" : { "Name": "Chef","Version": "11.10" }, "DefaultOs": "Amazon Linux 2016.03", "DefaultInstanceProfileArn": { "Fn::GetAtt": [ "OpsWorksInstanceProfile", "Arn" ] } } }, "MyLayer": { "Type": "AWS::OpsWorks::Layer", "Properties": { "StackId": { "Ref": "MyStack" }, "Name": "MyLayer", "Type": "php-app", "Shortname": "mylayer", "EnableAutoHealing": "true", "AutoAssignElasticIps": "false", "AutoAssignPublicIps": "true", "CustomSecurityGroupIds": [ { "Fn::GetAtt": [ "CPOpsDeploySecGroup", "GroupId" ] } ] }, "DependsOn": [ "MyStack", "CPOpsDeploySecGroup" ] }, "OpsWorksServiceRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ { "Fn::FindInMap": [ "Region2Principal", { "Ref": "AWS::Region" }, "OpsWorksPrincipal" ] } ] }, "Action": [ "sts:AssumeRole" ] } ] }, "Path": "/", "Policies": [ { "PolicyName": "opsworks-service", "PolicyDocument": { "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "iam:PassRole", "cloudwatch:GetMetricStatistics", "elasticloadbalancing:*" ], "Resource": "*" } ] } } ] } }, "OpsWorksInstanceProfile": { "Type": "AWS::IAM::InstanceProfile", "Properties": { "Path": "/", "Roles": [ { "Ref": "OpsWorksInstanceRole" } ] } }, "OpsWorksInstanceRole": { "Type": "AWS::IAM::Role", "Properties": { "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ { "Fn::FindInMap": [ "Region2Principal", { "Ref": "AWS::Region" }, "EC2Principal" ] } ] }, "Action": [ "sts:AssumeRole" ] } ] }, "Path": "/", "Policies": [ { "PolicyName": "s3-get", "PolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "*" } ] } } ] } }, "myinstance": { "Type": "AWS::OpsWorks::Instance", "Properties": { "LayerIds": [ { "Ref": "MyLayer" } ], "StackId": { "Ref": "MyStack" }, "InstanceType": "c3.large", "SshKeyName": { "Ref": "EC2KeyPairName" } } } }, "Outputs": { "StackId": { "Description": "Stack ID for the newly created AWS OpsWorks stack", "Value": { "Ref": "MyStack" } } } } ``` 1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) 開啟 CloudFormation 主控台。 1. 在 CloudFormation 首頁上，選擇**建立堆疊**。 1. 在 **Select Template (選取範本)** 頁面上的 **Choose a template (選擇範本)** 區域中，選擇 **Upload a template to Amazon S3 (將範本上傳至 Amazon S3)**，然後選擇 **Browse (瀏覽)**。 1. 瀏覽至您在步驟 1 中儲存的 CloudFormation 範本，然後選擇**開啟**。在 **Select Template** (選取範本) 頁面上，請選擇 **Next** (下一步)。 ![\[AWS CloudFormation Create Stack (建立堆疊) 精靈的 Select Template (選取範本) 頁面。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_cfstackcreate.png) 1. 在 **Specify Details (指定詳細資訊)** 頁面上，將堆疊命名為 **MyStack** 或對您帳戶而言為唯一的任何堆疊名稱。如果您選擇不同的堆疊名稱，請變更整個本演練中該堆疊的名稱。 1. 在**參數**區域中，提供您要用來在建立 Stacks 執行個體之後存取的 EC2 OpsWorks 金鑰對名稱。選擇**下一步**。 1. 在**選項**頁面上，選擇**下一步**。(本演練不需要執行此頁面上的設定。) 1. 您在此演練中使用的 CloudFormation 範本會建立 IAM 角色、執行個體描述檔和執行個體。 **重要** 在選擇**建立**之前，請選擇**成本**來預估使用此範本 AWS 建立資源時可能衍生的費用。如果可以建立 IAM 資源，請選取**我確認此範本可能會導致 AWS CloudFormation 建立 IAM 資源**核取方塊，然後選擇**建立**。如果無法建立 IAM 資源，則無法繼續此程序。 1. 在 CloudFormation 儀表板上，您可以檢視建立堆疊的進度。請先等候 **Status (狀態)** 欄位顯示 **CREATE\$1COMPLETE** 後，再繼續進行下一步。 ![\[顯示堆疊建立的 AWS CloudFormation 儀表板。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_createstack.png) **驗證在 Stacks OpsWorks 中建立堆疊** 1. 在 https：//[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) 開啟 OpsWorks 主控台。 1. 在 OpsWorks Stacks 儀表板上，檢視您建立的堆疊。 ![\[顯示堆疊建立的 AWS OpsWorks 儀表板。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_verifystack.png) 1. 開啟堆疊並檢視 layer 和執行個體。請注意，層和執行個體是使用 CloudFormation 範本中提供的名稱和其他中繼資料建立的。您已準備好將應用程式上傳至 Amazon S3 儲存貯體。 # 步驟 2：將應用程式碼上傳至 Amazon S3 儲存貯體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。由於您必須提供程式碼儲存庫的連結做為管道設定的一部分，因此在建立管道前，請先準備好程式碼儲存庫。在此逐步解說中，您將 PHP 應用程式上傳到 Amazon S3 儲存貯體。雖然 CodePipeline 可以直接從 GitHub 或 CodeCommit 使用程式碼做為來源，但本演練示範如何使用 Amazon S3 儲存貯體。Amazon S3 儲存貯體可讓 CodePipeline 偵測應用程式程式碼的變更，並自動部署變更的應用程式。您也可以視需要使用現有的儲存貯體。確保儲存貯體符合 CodePipeline 標準，如 CodePipeline 文件中的[簡易管道逐步解說 (Amazon S3 儲存貯體）](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html) 所述。 **重要** Amazon S3 儲存貯體必須位於您稍後建立管道的相同區域。目前，CodePipeline 僅支援美國東部（維吉尼亞北部）區域 (us-east-1) 的 OpsWorks Stacks 供應商。此演練中的所有資源都應在美國東部（維吉尼亞北部）區域建立。儲存貯體也必須進行版本控制，因為 CodePipeline 需要版本控制來源。如需詳細資訊，請參閱[使用版本控制](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)。 **將應用程式上傳至 Amazon S3 儲存貯體** 1. 從 [GitHub 網站](https://github.com/awslabs/opsworks-demo-php-simple-app/archive/version1.zip)下載 OpsWorks Stacks 範例 PHP 應用程式的 ZIP 檔案，並將其儲存至本機電腦上方便的位置。 1. 請確定 `index.php` 和 `ASSETS` 資料夾在已下載 ZIP 檔案的根層級。若未在根層級，請解壓縮該檔案，並建立讓這些檔案在根層級的新 ZIP 檔案。 1. 開啟位於 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) 的 Amazon S3 主控台。 1. 選擇 **Create Bucket** (建立儲存貯體)。 1. 在 **Create a Bucket - Select a Bucket Name and Region (建立儲存貯體 - 選取儲存貯體名稱和區域)** 頁面上，針對 **Bucket Name (儲存貯體名稱)**，輸入儲存貯體的唯一名稱。儲存貯體名稱在所有 AWS 帳戶中必須是唯一的，而不只是在您自己的帳戶中。本演練使用的名稱是 **my-appbucket**，但您可使用 `my-appbucket-yearmonthday`，讓您的儲存貯體名稱成為唯一名稱。從 **Region (區域)** 下拉式清單，選擇 **US Standard (美國標準)**，然後選擇 **Create (建立)**。**US Standard (美國標準)** 相當於 `us-east-1`。 ![\[S3 Create a Bucket (建立儲存貯體) 頁面。\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_s3bucket.png) 1. 從 **All Buckets (所有儲存貯體)** 清單選擇您建立的儲存貯體。 1. 在儲存貯體頁面上，選擇 **Upload (上傳)**。 1. 在 **Upload - Select Files and Folders (上傳 - 選取檔案和資料夾)** 頁面上，選擇 **Add files (新增檔案)**。瀏覽您在步驟 1 中儲存的 ZIP 檔案，選擇 **Open (開啟)**，再選擇 **Start Upload (開始上傳)**。 ![\[S3 Select Files and Folders (選取檔案和資料夾) 對話方塊\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_uploadzip.png) 1. 在上傳完成後，從您儲存貯體中的檔案清單選取 ZIP 檔案，然後選擇 **Properties (屬性)**。 1. 在 **Properties (屬性)** 窗格中，複製您 ZIP 檔案的連結，並記下此連結。您將需要儲存貯體名稱和此連結的 ZIP 檔案名稱部分來建立管道。 # 步驟 3：將您的應用程式新增至 OpsWorks Stacks **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在 CodePipeline 中建立管道之前，請將 PHP 測試應用程式新增至 OpsWorks Stacks。建立管道時，您需要選取已新增至 Stacks OpsWorks 的應用程式。準備好先前程序的步驟 10 中的 Amazon S3 儲存貯體連結。您將需要存放測試應用程式所在的儲存貯體連結來完成此程序。 **將應用程式新增至 OpsWorks Stacks** 1. 在 OpsWorks Stacks 主控台中，開啟 **MyStack**，然後在導覽窗格中選擇**應用程式**。 1. 選擇 **Add app (新增應用程式)**。 1. 在 **Add App (新增應用程式)** 頁面上，提供下列資訊： 1. 為應用程式指定名稱。本逐步教學使用的名稱是 `PHPTestApp`。 1. 在 **Type (類型)** 下拉式清單中，選擇 **PHP**。 1. 針對 **Data source type (資料來源類型)**，選擇 **None (無)**。此應用程式不需要外部資料庫或資料來源。 1. 在 **Repository type (儲存庫類型)** 下拉式清單中，選擇 **S3 Archive (S3 封存)**。 1. 在 **Repository URL (儲存庫 URL)** 字串方格中，貼上您在[步驟 2：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef11-s3.md)的步驟 10 中複製的 URL。您的表單應類似下列內容： ![\[Add App (新增應用程式) 頁面\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_addappops.png) 1. 您不需要變更此表單中的任何其他設定。選擇 **Add App (新增應用程式)**。 1. 當 **PHPTestApp** 應用程式出現在 **Apps (應用程式)** 頁面的清單中時，請繼續下一項程序：[步驟 4：在 CodePipeline 中建立管道](other-services-cp-chef11-pipeline.md)。 # 步驟 4：在 CodePipeline 中建立管道 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。在 Stacks 中設定了具有 layer OpsWorks 和至少一個執行個體的堆疊之後，請在 CodePipeline 中建立管道，並將 OpsWorks Stacks 做為將應用程式或 Chef 技術指南部署到 OpsWorks Stacks 資源的提供者。 **建立管道** 1. 前往 [https://console.aws.amazon.com/codepipeline/](https://console.aws.amazon.com/codepipeline/) 開啟 CodePipeline 主控台。 1. 選擇 **Create pipeline (建立管道)**。 1. 在 ** CodePipeline 入門**頁面上，輸入 **MyOpsWorksPipeline**或您的帳戶唯一的任何其他管道名稱，然後選擇**下一步**。 1. 在 **Source Location (來源位置)** 頁面上，從 **Source provider (來源提供者)** 下拉式清單選取 **Amazon S3**。 1. 在 **Amazon S3 詳細資訊**區域中，以格式輸入您的 Amazon S3 儲存貯體路徑**s3://*bucket-name*/*file name***。參考您在[步驟 2：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef11-s3.md)的步驟 10 中記下的連結。在本演練中，路徑為 `s3://my-appbucket/opsworks-demo-php-simple-app-version1.zip`。選擇 **下一個步驟**。 ![\[AWS CodePipeline 來源與提供者\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_source.png) 1. 在 **Build (組建)** 頁面上，從下拉式清單選擇 **No Build (無組建)**，然後選擇 **Next step (下一步)**。 1. 在 **Deploy (部署)** 頁面上，選擇 **OpsWorks Stacks** 做為部署提供者。 ![\[Deploy configuration form for AWS OpsWorks Stacks with fields for stack, layer, and app selection.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_cpprovider.png) 1. 在 **Stack (堆疊)** 欄位中輸入 `MyStack`，或您在[步驟 1：在 OpsWorks Stacks 中建立堆疊、layer 和執行個體](other-services-cp-chef11-stack.md)中建立的堆疊名稱。 1. 在 **Layer** 欄位中輸入 `MyLayer`，或您在[步驟 1：在 OpsWorks Stacks 中建立堆疊、layer 和執行個體](other-services-cp-chef11-stack.md)中建立的 layer 名稱。 1. 在**應用程式**欄位中，選取您在中上傳到 Amazon S3 的應用程式[步驟 2：將應用程式碼上傳至 Amazon S3 儲存貯體](other-services-cp-chef11-s3.md)，然後選擇**下一步**。 1. 在 **AWS Service Role (AWS 服務角色)** 頁面上，選擇 **Create Role (建立角色)**。新的視窗隨即開啟，其中包含 IAM 主控台頁面，說明將為您建立的角色：`AWS-CodePipeline-Service`。從 **Policy name (政策名稱)** 下拉式清單，選擇 **Create new policy (建立新政策)**。請確認政策文件包含下列內容。如有需要，請選擇 **Edit (編輯)** 來變更政策文件。 ``` { "Statement": [ { "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetBucketVersioning" ], "Resource": "*", "Effect": "Allow" }, { "Action": "opsworks:*", "Resource": "*", "Effect": "Allow" } ] } ``` 完成政策文件的變更後，選擇 **Allow (允許)**。您的變更將在 IAM 主控台中發佈。 ![\[AWSIAM role summary with policy document showing S3 object actions allowed.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_iamrole.png) **注意** 如果角色建立失敗，可能是因為您已經有名為 **AWS-CodePipeline-Service** 的 IAM 角色。如果您在 2016 年 5 月之前已使用 **AWS-CodePipeline-Service** 角色，該角色可能沒有使用 OpsWorks Stacks 做為部署提供者的許可；在此情況下，您必須更新政策陳述式，如此步驟所示。若您看到錯誤訊息，請回到此步驟的開頭，並選擇 **Use existing role (使用現有的角色)** 而非 **Create role (建立角色)**。如果您使用現有的角色，該角色應會連接含有此步驟中所示許可的政策。如需服務角色及其政策陳述式的詳細資訊，請參閱[編輯 IAM 服務角色的政策](https://docs.aws.amazon.com/codepipeline/latest/userguide/access-permissions.html#how-to-custom-role)。 1. 如果角色建立程序成功，IAM 頁面會關閉，而且您會返回 **AWS 服務角色**頁面。選擇 **下一個步驟**。 1. 在 **Review your pipeline (檢閱管道)** 頁面上，確認頁面顯示的選項，然後選擇 **Create pipeline (建立管道)**。 ![\[Pipeline configuration details for MyOpsWorksPipeline with source, build, and beta stages.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_cpreview.png) 1. 當管道就緒時，其應會開始尋找來源碼，並自動將應用程式部署到堆疊。此程序需要幾分鐘的時間。 # 步驟 5：在 Stacks OpsWorks 中驗證應用程式部署 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。若要驗證 CodePipeline 是否已將 PHP 應用程式部署到您的堆疊，請登入您在中建立的執行個體[步驟 1：在 OpsWorks Stacks 中建立堆疊、layer 和執行個體](other-services-cp-chef11-stack.md)。您應該可以看到並使用 PHP Web 應用程式。 **驗證 Stacks OpsWorks 執行個體中的應用程式部署** 1. 在 https：//[https://console.aws.amazon.com/opsworks/](https://console.aws.amazon.com/opsworks/) 開啟 OpsWorks 主控台。 1. 在 OpsWorks Stacks 儀表板上，選擇 **MyStack**，然後選擇 **MyLayer**。 1. 在導覽窗格中，選擇 **Instances (執行個體)**，然後選擇您建立之執行個體的公有 IP 地址，以檢視 Web 應用程式。 ![\[Instance details showing one online c3.large instance in us-east-1a with a public IP.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_instanceapp.png) 該應用程式會顯示在新的瀏覽器標籤中。 ![\[Confirmation message for a successfully deployed PHP application on AWS 雲端.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_successphp.png) # 步驟 6 （選用）：更新應用程式程式碼，以查看 CodePipeline 自動重新部署您的應用程式 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當您使用 CodePipeline 對已部署的應用程式或技術指南中的程式碼進行變更時，已更新的成品將由 CodePipeline 自動部署到您的目標執行個體（在此情況下為目標 Stacks OpsWorks 堆疊）。本節示範在您更新範例 PHP 應用程式程式碼時的自動重新部署。 **在範例應用程式中編輯程式碼** 1. 登入 AWS 管理主控台，並在 https：//[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) 開啟 Amazon S3 主控台。 1. 開啟您存放範例 PHP 應用程式的儲存貯體。 ![\[AWS S3 console interface showing a bucket with a PHP application file listed.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_editcodeS3.png) 1. 選取內含應用程式的 ZIP 檔案。在 **Actions (動作)** 選單上，選擇 **Download (下載)**。 1. 在對話方塊中，(按一下右鍵) 開啟內容功能表，選擇 **Download (下載)**，然後將 ZIP 檔案儲存到方便使用的位置。選擇**確定**。 1. 將 ZIP 檔案的內容解壓縮到方便使用的位置。您可能需要變更已解壓縮資料夾及其子資料夾和內容的許可，以允許編輯。在 `opsworks-demo-php-simple-app-version1` 資料夾中，開啟 `index.php` 檔案編輯。 1. 搜尋片語 `Your PHP application is now running`。將 `Your PHP application is now running` 這段文字取代為 `You've just deployed your first app to AWS OpsWorks with AWS CodePipeline,`。請勿編輯變數。 ![\[HTML code snippet showing a simple PHP app deployment message with AWS 服務.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_editheader.png) 1. 儲存並關閉 `index.php` 檔案。 1. 壓縮 `opsworks-demo-php-simple-app-version1` 資料夾，並將 ZIP 檔案儲存在方便的位置。請勿變更 ZIP 檔案名稱。 1. 將新的 ZIP 檔案上傳至您的 Amazon S3 儲存貯體。在本演練中，儲存貯體的名稱為 `my-appbucket`。 1. 開啟 CodePipeline 主控台，並開啟您的 OpsWorks Stacks 管道 (**MyOpsWorksPipeline**)。選擇 **Release Change (版本變更)**。（您可以等待 CodePipeline 偵測來自 Amazon S3 儲存貯體中應用程式更新版本的程式碼變更。為了節省您的時間，此演練會指示您直接選擇**版本變更**。) 1. 觀察 CodePipeline 執行管道的階段。首先，CodePipeline 會偵測來源成品的變更。 ![\[Pipeline diagram showing Source stage in progress and Beta stage succeeded 13 days ago.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_cpupdatesource.png) CodePipeline 會將更新的程式碼推送至 Stacks OpsWorks 中的堆疊。 ![\[Pipeline view showing Source stage succeeded and Beta stage in progress.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_updatestack.png) 1. 當管道的兩個階段都成功完成後，開啟 OpsWorks Stacks 中的堆疊 (**MyStack**)。 1. 在 **MyStack** 屬性頁面上，選擇 **Instances (執行個體)**。 1. 在 **Public IP (公有 IP)** 欄位中，選擇您執行個體的公有 IP 地址，以檢視更新的應用程式文字。 ![\[Confirmation message for successful deployment of a PHP app to AWS OpsWorks using AWS CodePipeline.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/cp_integ_successedit.png) # 步驟 7 (選用)：清除資源 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。為了協助避免您的 AWS 帳戶產生不必要的費用，您可以刪除用於本演練 AWS 的資源。這些 AWS 資源包括 OpsWorks Stacks 堆疊、IAM 角色和執行個體描述檔，以及您在 CodePipeline 中建立的管道。不過，當您繼續進一步了解 OpsWorks Stacks 和 CodePipeline 時，建議您繼續使用這些 AWS 資源。如果您要保留這些資源，您已完成本演練。 **從堆疊刪除應用程式** 由於您未在 CloudFormation 範本中建立或套用應用程式，請先刪除 PHP 測試應用程式，再刪除堆疊 CloudFormation。 1. 在 OpsWorks Stacks 主控台的服務導覽窗格中，選擇**應用程式**。 1. 在 **Apps (應用程式)** 頁面上，選取 **PHPTestApp**，然後在 **Actions (動作)** 中選擇 **delete (刪除)**。當您收到確認提示時，請選擇 **Delete**. OpsWorks Stacks 將刪除應用程式。 **刪除堆疊** 由於您透過執行 CloudFormation 範本建立堆疊，因此您可以在 CloudFormation 主控台中刪除堆疊，包括範本建立的 layer、執行個體、執行個體描述檔和安全群組。 1. 開啟 CloudFormation 主控台。 1. 在 CloudFormation 主控台儀表板中，選取您建立的堆疊 (**MyStack**)。在 **Actions (動作)** 選單上，選擇 **Delete Stack (刪除堆疊)**。出現確認提示時，選擇 **Yes, Delete (是，刪除)**。 1. 等待堆疊的 **Status (狀態)** 欄位中顯示 **DELETE\$1COMPLETE**。 **刪除管道** 1. 開啟 CodePipeline 主控台。 1. 在 CodePipeline 儀表板中，選擇您為此演練建立的管道。 1. 在管道頁面上，選擇 **Edit (編輯)**。 1. 在 **Edit (編輯)** 頁面上，選擇 **Delete (刪除)**。出現確認提示時，選擇 **Delete (刪除)**。 # 使用 OpsWorks Stacks CLI **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Stacks OpsWorks 命令列界面 (CLI) 提供與主控台相同的功能，可用於各種任務。Stacks CLI OpsWorks 是的一部分 AWS CLI。如需詳細資訊，包括如何安裝和設定 AWS CLI，請前往[什麼是 AWS Command Line Interface？](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)。如需每個命令的完整說明，請前往 [OpsWorks Stacks 參考](https://docs.aws.amazon.com/cli/latest/reference/opsworks/index.html)。 **注意** 如果您使用的是 Windows 型工作站，您也可以執行 AWS Tools for Windows PowerShell，從命令列執行 OpsWorks Stacks 操作。如需詳細資訊，請參閱[適用於 Windows PowerShell 的 AWS 工具](https://aws.amazon.com/documentation/powershell/)。 OpsWorks Stacks 命令具有下列一般格式： ``` aws opsworks --region us-west-1 opsworks command-name [--argument1 value] [...] ``` 若引數值為 JSON 物件，您應逸出 `"` 字元，否則命令會傳回錯誤，顯示 JSON 無效。例如，若 JSON 物件為 `"{"somekey":"somevalue"}"`，您應將其格式化為 `"{\"somekey\":\"somevalue\"}"`。另一種方法為將 JSON 物件放置在檔案中，然後在命令列中使用 `file://` 以包含它。以下範例會使用存放在 appsource.json 中的應用程式來源物件建立應用程式。 ``` aws opsworks --region us-west-1 create-app --stack-id 8c428b08-a1a1-46ce-a5f8-feddc43771b8 --name SimpleJSP --type java --app-source file://appsource.json ``` 大多數命令會傳回一或多個值，並封裝為 JSON 物件。以下章節包含一些範例。如需每個命令傳回值的詳細說明，請前往 [OpsWorks Stacks 參考](https://docs.aws.amazon.com/cli/latest/reference/opsworks/index.html)。 **注意** AWS CLI 命令必須指定區域，如範例所示。--region 參數的有效值如下表所示。若要簡化 OpsWorks Stacks 命令字串，請設定 CLI 以指定您的預設區域，讓您可以省略 `--region` 參數。如果您通常在多個區域端點中工作，請勿 AWS CLI 將設定為使用預設區域端點。加拿大（中部）區域端點僅在 API 中提供 AWS CLI ，不適用於您在中建立的堆疊 AWS 管理主控台。如需詳細資訊，請參閱[設定 AWS 區域](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-installing-specifying-region)。 | 區域名稱 | 命令程式碼 | | --- | --- | | 美國東部 (俄亥俄) 區域 | us-east-2 | | 美國東部 (維吉尼亞北部) 區域 | us-east-1 | | 美國西部 (加利佛尼亞北部) 區域 | us-west-1 | | 美國西部 (奧勒岡) 區域 | us-west-2 | | 加拿大 (中部) 區域 | ca-central-1 | | 歐洲 (愛爾蘭) 區域 | eu-west-1 | | 歐洲 (倫敦) 區域 | eu-west-2 | | 歐洲 (巴黎) 區域 | eu-west-3 | | 歐洲 (法蘭克福) 區域 | eu-central-1 | | 亞太地區 (東京) 區域 | ap-northeast-1 | | 亞太 (首爾) 區域 | ap-northeast-2 | | 亞太區域 (孟買) 區域 | ap-south-1 | | 亞太區域 (新加坡) 區域 | ap-southeast-1 | | 亞太 (雪梨) 區域 | ap-southeast-2 | | 南美洲 (聖保羅) 區域 | sa-east-1 | 若要使用 CLI 命令，您必須擁有適當的許可。如需 OpsWorks Stacks 許可的詳細資訊，請參閱[管理使用者許可](opsworks-security-users.md)。若要判斷特定命令需要的許可，請參閱 [OpsWorks Stacks 參考](https://docs.aws.amazon.com/cli/latest/reference/opsworks/index.html)中該命令的參考頁面。下列各節說明如何使用 OpsWorks Stacks CLI 來執行各種常見任務。 # 建立執行個體 (create-instance) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [create-instance](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-instance.html) 命令來在指定堆疊上建立執行個體。 **Topics** + [使用預設主機名稱建立執行個體](#cli-examples-create-instance-default) + [使用主題主機名稱建立執行個體](#cli-examples-create-instance-themed) + [使用自訂 AMI 建立執行個體](#cli-examples-create-instance-custom-ami) ## 使用預設主機名稱建立執行個體 ``` C:\>aws opsworks --region us-west-1 create-instance --stack-id 935450cc-61e0-4b03-a3e0-160ac817d2bb --layer-ids 5c8c272a-f2d5-42e3-8245-5bf3927cb65b --instance-type m1.large --os "Amazon Linux" ``` 引數如下： + `stack-id` – 您可以從主控台上的堆疊設定頁面取得堆疊 ID (尋找 **OpsWorks ID**) 或呼叫 [describe-stacks](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-stacks.html)。 + `layer-ids` – 您可以從主控台的 layer 詳細資訊頁面取得 layer IDs （尋找 **OpsWorks ID**) 或呼叫 [describe-layers](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-layers.html)。在此範例中，執行個體僅屬於一個 layer。 + `instance-type` – 定義記憶體、CPU、儲存體容量，和執行個體每小時成本的規格。此範例為 `m1.large`。 + `os` – 執行個體的作業系統。此範例為 Amazon Linux。命令會傳回包含執行個體 ID 的 JSON 物件，如下所示： ``` { "InstanceId": "5f9adeaa-c94c-42c6-aeef-28a5376002cd" } ``` 此範例會使用預設主機名稱 (僅為一個整數) 建立執行個體。下列章節說明如何使用從主題產生的主機名稱建立執行個體。 ## 使用主題主機名稱建立執行個體您也可以使用主題主機名稱建立執行個體。您會在建立堆疊時指定主題。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。若要建立執行個體，首先請呼叫 [get-hostname-suggestion](https://docs.aws.amazon.com/cli/latest/reference/opsworks/get-hostname-suggestion.html) 以產生名稱。例如： ``` C:\>aws opsworks get-hostname-suggestion --region us-west-1 --layer-id 5c8c272a-f2d5-42e3-8245-5bf3927cb65b ``` 若您指定預設 `Layer Dependent` 主題，`get-hostname-suggestion` 只會將數字附加到 layer 的短名。如需詳細資訊，請參閱[建立新的堆疊](workingstacks-creating.md)。命令會傳回產生的主機名稱。 ``` { "Hostname": "php-app2", "LayerId": "5c8c272a-f2d5-42e3-8245-5bf3927cb65b" } ``` 您接著可以使用 `hostname` 引數將產生的名稱傳遞給 `create-instance`，如下所示： ``` c:\>aws --region us-west-1 opsworks create-instance --stack-id 935450cc-61e0-4b03-a3e0-160ac817d2bb --layer-ids 5c8c272a-f2d5-42e3-8245-5bf3927cb65b --instance-type m1.large --os "Amazon Linux" --hostname "php-app2" ``` ## 使用自訂 AMI 建立執行個體以下 [create-instance](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-instance.html) 命令會使用自訂 AMI 建立執行個體，該自訂 AMI 必須來自堆疊的區域。如需如何為 Stacks 建立自訂 AMI OpsWorks 的詳細資訊，請參閱 [使用自訂 AMI](workinginstances-custom-ami.md)。 ``` C:\>aws opsworks create-instance --region us-west-1 --stack-id c5ef46ce-3ccd-472c-a3de-9bec94c6028e --layer-ids 6ff8a2ac-c9cc-49cf-9c67-fc852539ade4 --instance-type c3.large --os Custom --ami-id ami-6c61f104 ``` 引數如下： + `stack-id` – 您可以從主控台上的堆疊設定頁面取得堆疊 ID (尋找 **OpsWorks ID**) 或呼叫 [describe-stacks](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-stacks.html)。 + `layer-ids` – 您可以從主控台的 layer 詳細資訊頁面取得 layer IDs （尋找 **OpsWorks ID**) 或呼叫 [describe-layers](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-layers.html)。在此範例中，執行個體僅屬於一個 layer。 + `instance-type` – 值定義執行個體的記憶體、CPU、儲存體容量和每小時成本，且必須與 AMI 相容 (此範例中為 `c3.large`)。 + `os` – 執行個體的作業系統；自訂 AMI 必須設為 `Custom`。 + `ami-id` – AMI ID，形式看起來應該像 `ami-6c61f104` **注意** 當您使用自訂 AMI 時，不支援區塊型設備映射，因此您為 `--block-device-mappings` 選項指定的值將會遭到忽略。命令會傳回包含執行個體 ID 的 JSON 物件，如下所示： ``` { "InstanceId": "5f9adeaa-c94c-42c6-aeef-28a5376002cd" } ``` # 部署應用程式 (create-deployment) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) 命令將應用程式部署到指定堆疊。 **Topics** + [部署應用程式](#cli-examples-create-deployment-deploy) ## 部署應用程式 ``` aws opsworks --region us-west-1 create-deployment --stack-id cfb7e082-ad1d-4599-8e81-de1c39ab45bf --app-id 307be5c8-d55d-47b5-bd6e-7bd417c6c7eb --command "{\"Name\":\"deploy\"}" ``` 引數如下： + `stack-id` – 您可以從主控台上的堆疊設定頁面取得堆疊 ID (尋找 **OpsWorks ID**) 或呼叫 `describe-stacks`。 + `app-id` – 您可以從應用程式詳細資訊頁面取得應用程式 ID (尋找 **OpsWorks ID**) 或呼叫 [describe-apps](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-apps.html)。 + `command` – 引數接受一個將命令名稱設為 `deploy` 的 JSON 物件，將指定應用程式部署到堆疊。請注意，JSON 物件中的 `"` 字元全部都已逸出。否則，命令可能傳回錯誤，顯示 JSON 無效。命令會傳回包含部署 ID 的 JSON 物件，如下所示： ``` { "DeploymentId": "5746c781-df7f-4c87-84a7-65a119880560" } ``` **注意** 上述範例會部署到堆疊中的每個執行個體。若要部署到指定的執行個體子集，請新增 `instance-ids` 引數並列出執行個體 ID。 # 列出堆疊的應用程式 (describe-apps) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [describe-apps](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-apps.html) 命令來列出堆疊的應用程式或取得特定應用程式的詳細資訊。 ``` aws opsworks --region us-west-1 describe-apps --stack-id 38ee91e2-abdc-4208-a107-0b7168b3cc7a ``` 上述範例會傳回一個 JSON 物件，其中包含每個應用程式的相關資訊。此範例只有一個應用程式。如需每個參數的說明，請參閱 [describe-apps](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-apps.html)。 ``` { "Apps": [ { "StackId": "38ee91e2-abdc-4208-a107-0b7168b3cc7a", "AppSource": { "Url": "url", "Type": "archive" }, "Name": "SimpleJSP", "EnableSsl": false, "SslConfiguration": {}, "AppId": "da1decc1-0dff-43ea-ad7c-bb667cd87c8b", "Attributes": { "RailsEnv": null, "AutoBundleOnDeploy": "true", "DocumentRoot": "ROOT" }, "Shortname": "simplejsp", "Type": "other", "CreatedAt": "2013-08-01T21:46:54+00:00" } ] } ``` # 列出堆疊的命令 (describe-commands) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [describe-commands](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html) 命令來列出堆疊的命令或取得特定命令的詳細資訊。以下範例會取得已於指定之執行個體上執行的命令資訊。 ``` aws opsworks --region us-west-1 describe-commands --instance-id 8c2673b9-3fe5-420d-9cfa-78d875ee7687 ``` 命令會傳回一個 JSON 物件，其中包含每個命令的詳細資訊。`Type` 參數會識別命令名稱，此範例中為 deploy 或 undeploy。如需其他參數的說明，請參閱 [describe-commands](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)。 ``` { "Commands": [ { "Status": "successful", "CompletedAt": "2013-07-25T18:57:47+00:00", "InstanceId": "8c2673b9-3fe5-420d-9cfa-78d875ee7687", "DeploymentId": "6ed0df4c-9ef7-4812-8dac-d54a05be1029", "AcknowledgedAt": "2013-07-25T18:57:41+00:00", "LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/008c1a91-ec59-4d51-971d-3adff54b00cc?AWSAccessKeyId=AIDACKCEVSQ6C2EXAMPLE &Expires=1375394373&Signature=HkXil6UuNfxTCC37EPQAa462E1E%3D&response-cache-control=private&response-content-encoding=gzip&response-content- type=text%2Fplain", "Type": "undeploy", "CommandId": "008c1a91-ec59-4d51-971d-3adff54b00cc", "CreatedAt": "2013-07-25T18:57:34+00:00", "ExitCode": 0 }, { "Status": "successful", "CompletedAt": "2013-07-25T18:55:40+00:00", "InstanceId": "8c2673b9-3fe5-420d-9cfa-78d875ee7687", "DeploymentId": "19d3121e-d949-4ff2-9f9d-94eac087862a", "AcknowledgedAt": "2013-07-25T18:55:32+00:00", "LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/899d3d64-0384-47b6-a586-33433aad117c?AWSAccessKeyId=AIDACKCEVSQ6C2EXAMPLE &Expires=1375394373&Signature=xMsJvtLuUqWmsr8s%2FAjVru0BtRs%3D&response-cache-control=private&response-content-encoding=gzip&response-conten t-type=text%2Fplain", "Type": "deploy", "CommandId": "899d3d64-0384-47b6-a586-33433aad117c", "CreatedAt": "2013-07-25T18:55:29+00:00", "ExitCode": 0 } ] } ``` # 列出堆疊的部署 (describe-deployments) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [describe-deployments](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-deployments.html) 命令來列出堆疊的部署或取得特定部署的詳細資訊。 ``` aws opsworks --region us-west-1 describe-deployments --stack-id 38ee91e2-abdc-4208-a107-0b7168b3cc7a ``` 上述命令會傳回一個 JSON 物件，其中包含指定堆疊每個部署的詳細資訊。如需每個參數的說明，請參閱 [describe-deployments](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-deployments.html)。 ``` { "Deployments": [ { "StackId": "38ee91e2-abdc-4208-a107-0b7168b3cc7a", "Status": "successful", "CompletedAt": "2013-07-25T18:57:49+00:00", "DeploymentId": "6ed0df4c-9ef7-4812-8dac-d54a05be1029", "Command": { "Args": {}, "Name": "undeploy" }, "CreatedAt": "2013-07-25T18:57:34+00:00", "Duration": 15, "InstanceIds": [ "8c2673b9-3fe5-420d-9cfa-78d875ee7687", "9e588a25-35b2-4804-bd43-488f85ebe5b7" ] }, { "StackId": "38ee91e2-abdc-4208-a107-0b7168b3cc7a", "Status": "successful", "CompletedAt": "2013-07-25T18:56:41+00:00", "IamUserArn": "arn:aws:iam::444455556666:user/example-user", "DeploymentId": "19d3121e-d949-4ff2-9f9d-94eac087862a", "Command": { "Args": {}, "Name": "deploy" }, "InstanceIds": [ "8c2673b9-3fe5-420d-9cfa-78d875ee7687", "9e588a25-35b2-4804-bd43-488f85ebe5b7" ], "Duration": 72, "CreatedAt": "2013-07-25T18:55:29+00:00" } ] } ``` # 列出堆疊的彈性 IP 地址 (describe-elastic-ips) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [describe-elastic-ips](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-elastic-ips.html) 命令列出已向堆疊註冊的彈性 IP 地址，或取得特定彈性 IP 地址的詳細資訊。 ``` aws opsworks --region us-west-2 describe-elastic-ips --instance-id b62f3e04-e9eb-436c-a91f-d9e9a396b7b0 ``` 上述命令會傳回一個 JSON 物件，其中包含指定之執行個體的每個彈性 IP 地址 (此範例中為一個) 的詳細資訊。如需每個參數的說明，請參閱 [describe-elastic-ips](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-elastic-ips.html)。 ``` { "ElasticIps": [ { "Ip": "192.0.2.0", "Domain": "standard", "Region": "us-west-2" } ] } ``` # 列出堆疊的執行個體 (describe-instances) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-elastic-ips.html) 命令來列出堆疊的執行個體或取得特定執行個體的詳細資訊。 ``` C:\>aws opsworks --region us-west-2 describe-instances --stack-id 38ee91e2-abdc-4208-a107-0b7168b3cc7a ``` 上述命令會傳回一個 JSON 物件，其中包含指定堆疊中之每個執行個體的詳細資訊。如需每個參數的說明，請參閱 [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-elastic-ips.html)。 ``` { "Instances": [ { "StackId": "38ee91e2-abdc-4208-a107-0b7168b3cc7a", "SshHostRsaKeyFingerprint": "f4:3b:8e:27:1b:73:98:80:5d:d7:33:e2:b8:c8:8f:de", "Status": "stopped", "AvailabilityZone": "us-west-2a", "SshHostDsaKeyFingerprint": "e8:9b:c7:02:18:2a:bd:ab:45:89:21:4e:af:0b:07:ac", "InstanceId": "8c2673b9-3fe5-420d-9cfa-78d875ee7687", "Os": "Amazon Linux", "Hostname": "db-master1", "SecurityGroupIds": [], "Architecture": "x86_64", "RootDeviceType": "instance-store", "LayerIds": [ "41a20847-d594-4325-8447-171821916b73" ], "InstanceType": "c1.medium", "CreatedAt": "2013-07-25T18:11:27+00:00" }, { "StackId": "38ee91e2-abdc-4208-a107-0b7168b3cc7a", "SshHostRsaKeyFingerprint": "ae:3a:85:54:66:f3:ce:98:d9:83:39:1e:10:a9:38:12", "Status": "stopped", "AvailabilityZone": "us-west-2a", "SshHostDsaKeyFingerprint": "5b:b9:6f:5b:1c:ec:55:85:f3:45:f1:28:25:1f:de:e4", "InstanceId": "9e588a25-35b2-4804-bd43-488f85ebe5b7", "Os": "Amazon Linux", "Hostname": "tomcustom1", "SecurityGroupIds": [], "Architecture": "x86_64", "RootDeviceType": "instance-store", "LayerIds": [ "e6cbcd29-d223-40fc-8243-2eb213377440" ], "InstanceType": "c1.medium", "CreatedAt": "2013-07-25T18:15:52+00:00" } ] } ``` # 列出帳戶的堆疊 (describe-stacks) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [describe-stacks](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-stacks.html) 命令來列出帳戶的堆疊或取得特定堆疊的詳細資訊。 ``` aws opsworks --region us-west-2 describe-stacks ``` 上述命令會傳回一個 JSON 物件，其中包含帳戶中每個堆疊的詳細資訊 (此範例中為兩個堆疊)。如需每個參數的說明，請參閱 [describe-stacks](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-stacks.html)。 ``` { "Stacks": [ { "ServiceRoleArn": "arn:aws:iam::444455556666:role/aws-opsworks-service-role", "StackId": "aeb7523e-7c8b-49d4-b866-03aae9d4fbcb", "DefaultRootDeviceType": "instance-store", "Name": "TomStack-sd", "ConfigurationManager": { "Version": "11.4", "Name": "Chef" }, "UseCustomCookbooks": true, "CustomJson": "{\n \"tomcat\": {\n \"base_version\": 7,\n \"java_opts\": \"-Djava.awt.headless=true -Xmx256m\"\n },\n \ "datasources\": {\n \"ROOT\": \"jdbc/mydb\"\n }\n}", "Region": "us-west-2", "DefaultInstanceProfileArn": "arn:aws:iam::444455556666:instance-profile/aws-opsworks-ec2-role", "CustomCookbooksSource": { "Url": "git://github.com/example-repo/tomcustom.git", "Type": "git" }, "DefaultAvailabilityZone": "us-west-2a", "HostnameTheme": "Layer_Dependent", "Attributes": { "Color": "rgb(45, 114, 184)" }, "DefaultOs": "Amazon Linux", "CreatedAt": "2013-08-01T22:53:42+00:00" }, { "ServiceRoleArn": "arn:aws:iam::444455556666:role/aws-opsworks-service-role", "StackId": "40738975-da59-4c5b-9789-3e422f2cf099", "DefaultRootDeviceType": "instance-store", "Name": "MyStack", "ConfigurationManager": { "Version": "11.4", "Name": "Chef" }, "UseCustomCookbooks": false, "Region": "us-west-2", "DefaultInstanceProfileArn": "arn:aws:iam::444455556666:instance-profile/aws-opsworks-ec2-role", "CustomCookbooksSource": {}, "DefaultAvailabilityZone": "us-west-2a", "HostnameTheme": "Layer_Dependent", "Attributes": { "Color": "rgb(45, 114, 184)" }, "DefaultOs": "Amazon Linux", "CreatedAt": "2013-10-25T19:24:30+00:00" } ] } ``` # 列出堆疊的 Layer (describe-layers) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [describe-layers](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-layers.html) 命令來列出堆疊的 layer 或取得特定 layer 的詳細資訊。 ``` aws opsworks --region us-west-2 describe-layers --stack-id 38ee91e2-abdc-4208-a107-0b7168b3cc7a ``` 上述命令會傳回 JSON 物件，其中包含指定堆疊中每個 layer 的詳細資訊，在此範例中為 MySQL layer 和自訂 layer。如需每個參數的說明，請參閱 [describe-layers](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-layers.html)。 ``` { "Layers": [ { "StackId": "38ee91e2-abdc-4208-a107-0b7168b3cc7a", "Type": "db-master", "DefaultSecurityGroupNames": [ "AWS-OpsWorks-DB-Master-Server" ], "Name": "MySQL", "Packages": [], "DefaultRecipes": { "Undeploy": [], "Setup": [ "opsworks_initial_setup", "ssh_host_keys", "ssh_users", "mysql::client", "dependencies", "ebs", "opsworks_ganglia::client", "mysql::server", "dependencies", "deploy::mysql" ], "Configure": [ "opsworks_ganglia::configure-client", "ssh_users", "agent_version", "deploy::mysql" ], "Shutdown": [ "opsworks_shutdown::default", "mysql::stop" ], "Deploy": [ "deploy::default", "deploy::mysql" ] }, "CustomRecipes": { "Undeploy": [], "Setup": [], "Configure": [], "Shutdown": [], "Deploy": [] }, "EnableAutoHealing": false, "LayerId": "41a20847-d594-4325-8447-171821916b73", "Attributes": { "MysqlRootPasswordUbiquitous": "true", "RubygemsVersion": null, "RailsStack": null, "HaproxyHealthCheckMethod": null, "RubyVersion": null, "BundlerVersion": null, "HaproxyStatsPassword": null, "PassengerVersion": null, "MemcachedMemory": null, "EnableHaproxyStats": null, "ManageBundler": null, "NodejsVersion": null, "HaproxyHealthCheckUrl": null, "MysqlRootPassword": "*****FILTERED*****", "GangliaPassword": null, "GangliaUser": null, "HaproxyStatsUrl": null, "GangliaUrl": null, "HaproxyStatsUser": null }, "Shortname": "db-master", "AutoAssignElasticIps": false, "CustomSecurityGroupIds": [], "CreatedAt": "2013-07-25T18:11:19+00:00", "VolumeConfigurations": [ { "MountPoint": "/vol/mysql", "Size": 10, "NumberOfDisks": 1 } ] }, { "StackId": "38ee91e2-abdc-4208-a107-0b7168b3cc7a", "Type": "custom", "DefaultSecurityGroupNames": [ "AWS-OpsWorks-Custom-Server" ], "Name": "TomCustom", "Packages": [], "DefaultRecipes": { "Undeploy": [], "Setup": [ "opsworks_initial_setup", "ssh_host_keys", "ssh_users", "mysql::client", "dependencies", "ebs", "opsworks_ganglia::client" ], "Configure": [ "opsworks_ganglia::configure-client", "ssh_users", "agent_version" ], "Shutdown": [ "opsworks_shutdown::default" ], "Deploy": [ "deploy::default" ] }, "CustomRecipes": { "Undeploy": [], "Setup": [ "tomcat::setup" ], "Configure": [ "tomcat::configure" ], "Shutdown": [], "Deploy": [ "tomcat::deploy" ] }, "EnableAutoHealing": true, "LayerId": "e6cbcd29-d223-40fc-8243-2eb213377440", "Attributes": { "MysqlRootPasswordUbiquitous": null, "RubygemsVersion": null, "RailsStack": null, "HaproxyHealthCheckMethod": null, "RubyVersion": null, "BundlerVersion": null, "HaproxyStatsPassword": null, "PassengerVersion": null, "MemcachedMemory": null, "EnableHaproxyStats": null, "ManageBundler": null, "NodejsVersion": null, "HaproxyHealthCheckUrl": null, "MysqlRootPassword": null, "GangliaPassword": null, "GangliaUser": null, "HaproxyStatsUrl": null, "GangliaUrl": null, "HaproxyStatsUser": null }, "Shortname": "tomcustom", "AutoAssignElasticIps": false, "CustomSecurityGroupIds": [], "CreatedAt": "2013-07-25T18:12:53+00:00", "VolumeConfigurations": [] } ] } ``` # 執行配方 (create-deployment) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) 命令來執行[堆疊命令](workingstacks-commands.md)和[部署命令](workingapps-deploying.md)。以下範例會執行堆疊命令來在指定堆疊上執行自訂配方。 ``` aws opsworks --region us-west-1 create-deployment --stack-id 935450cc-61e0-4b03-a3e0-160ac817d2bb --command "{\"Name\":\"execute_recipes\", \"Args\":{\"recipes\":[\"phpapp::appsetup\"]}}" ``` `command` 引數接受 JSON 物件，其格式如下： + `Name` - 指定命令名稱。此範例中使用的 `execute_recipes` 命令會在堆疊的執行個體上執行指定配方。 + `Args` - 指定引數清單和其值。此範例有一個引數 (`recipes`)，已設為要執行的配方 (`phpapp::appsetup`)。請注意，JSON 物件中的 `"` 字元全部都已逸出。否則，命令可能傳回錯誤，顯示 JSON 無效。命令會傳回部署 ID，您可以用以識別其他 CLI 命令 (例如 `describe-commands`) 的命令。 ``` { "DeploymentId": "5cbaa7b9-4e09-4e53-aa1b-314fbd106038" } ``` # 安裝相依性 (create-deployment) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) 命令來執行[堆疊命令](workingstacks-commands.md)和[部署命令](workingapps-deploying.md)。以下範例會執行 `update_dependencies` 堆疊命令來更新堆疊執行個體上的依存項目。 ``` aws opsworks --region us-west-1 create-deployment --stack-id 935450cc-61e0-4b03-a3e0-160ac817d2bb --command "{\"Name\":\"install_dependencies\"}" ``` `command` 引數接受帶有 `Name` 參數的 JSON 物件，該參數會指定命令名稱。此範例中為 `install_dependencies`。請注意，JSON 物件中的 `"` 字元全部都已逸出。否則，命令可能傳回錯誤，顯示 JSON 無效。命令會傳回部署 ID，您可以用以識別其他 CLI 命令 (例如 `describe-commands`) 的命令。 ``` { "DeploymentId": "aef5b255-8604-4928-81b3-9b0187f962ff" } ``` # 更新堆疊組態 (update-stack) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。使用 [update-stack](https://docs.aws.amazon.com/cli/latest/reference/opsworks/update-stack.html) 命令更新指定堆疊的組態。以下範例會更新堆疊，以將自訂 JSON 新增到[堆疊組態屬性](workingstacks-json.md)。 ``` aws opsworks --region us-west-1 update-stack --stack-id 935450cc-61e0-4b03-a3e0-160ac817d2bb --custom-json "{\"somekey\":\"somevalue\"}" --service-role-arn arn:aws:iam::444455556666:role/aws-opsworks-service-role ``` 請注意，JSON 物件中的 `"` 字元全部都已逸出。否則，命令可能傳回錯誤，顯示 JSON 無效。 **注意** 範例也指定了堆疊的服務角色。您必須將 `service-role-arn` 設為有效的服務角色 ARN，否則動作將會失敗。未有預設值。您可以指定目前堆疊的服務角色 ARN (若您偏好的話)，但您必須清楚明確地指定。 `update-stack` 命令不會傳回值。 # 偵錯和故障診斷指南 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果您需要除錯配方或故障診斷服務問題，最佳的方法通常是遵循以下步驟依序操作： 1. 檢查[常見的除錯和故障診斷問題](common-issues.md)是否有您的特定問題。 1. 搜尋 [OpsWorks Stacks 論壇](https://forums.aws.amazon.com/forum.jspa?forumID=153#)，查看是否已討論過這些問題。論壇包含許多經驗豐富的使用者，並由 OpsWorks Stacks 團隊監控。 1. 對於配方的問題，請參閱[除錯配方](troubleshoot-debug.md)。 1. 聯絡 OpsWorks Stacks 支援或在 [OpsWorks Stacks 論壇](https://forums.aws.amazon.com/forum.jspa?forumID=153#)上張貼您的問題。下節提供除錯配方的指導方針。最終節說明常見的除錯和故障診斷問題及其解決方案。 **注意** 每個 Chef 執行都會產生日誌，詳細描述回合的狀況，是寶貴的故障診斷資源。若要指定日誌中詳細資訊的數量，請將 [https://docs.chef.io/resource_log.html](https://docs.chef.io/resource_log.html) 陳述式新增至指定所需日誌層級的自訂配方。預設值為 `:info`。以下範例說明如何將 Chef 日誌層級設定為 `:debug`，提供最詳細的回合描述。 ``` Chef::Log.level = :debug ``` 如需檢視和解釋 Chef 日誌的詳細資訊，請參閱 [Chef 日誌](troubleshoot-debug-log.md)。 **Topics** + [除錯配方](troubleshoot-debug.md) + [常見的除錯和故障診斷問題](common-issues.md) # 除錯配方 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。當生命週期事件發生，或您執行[執行配方堆疊命令](workingstacks-commands.md)時， OpsWorks Stacks 會向[代理程式](troubleshoot-debug-cli.md)發出命令，在指定的執行個體上初始化 [Chef Solo 執行](https://docs.chef.io/ctl_chef_solo.html)，以執行適當的配方，包括您的自訂配方。本節說明一些您可以為失敗配方除錯的方法。 **Topics** + [登入故障的執行個體](troubleshoot-debug-login.md) + [Chef 日誌](troubleshoot-debug-log.md) + [使用 OpsWorks Stacks 代理程式 CLI](troubleshoot-debug-cli.md) # 登入故障的執行個體 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。如果配方失敗，執行個體將會以 `setup_failed` 狀態結束，而不是線上狀態。即使與 OpsWorks Stacks 相關的執行個體尚未上線，EC2 執行個體仍在執行中，登入對問題進行疑難排解通常很有用。例如，您可以檢查應用程式或自訂技術指南是否已正確安裝。Stacks OpsWorks 內建的 [SSH](workinginstances-ssh.md) 和 [RDP](workinginstances-rdp.md) 登入支援僅適用於處於線上狀態的執行個體。不過，如果您已為執行個體指派 SSH 金鑰對，您仍可登入，說明如下： + Linux 執行個體 – 使用 SSH 金鑰對的私有金鑰來登入第三方 SSH 用戶端，例如 OpenSSH 或 PuTTY。您可以使用 EC2 金鑰對或您的[個人 SSH 金鑰對](security-ssh-access.md)登入。 + Windows 執行個體 – 使用 EC2 金鑰對的私有金鑰來擷取執行個體的管理員密碼。使用該密碼透過您偏好的 RDP 用戶端登入。如需詳細資訊，請參閱[以管理員身分登入](workinginstances-rdp.md#workinginstances-rdp-admin)。您無法使用[個人 SSH 金鑰對](security-ssh-access.md)擷取管理員密碼。 # Chef 日誌 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 Chef 日誌是您的關鍵疑難排解資源之一，特別是用於偵錯配方。 OpsWorks Stacks 會擷取每個命令的 Chef 日誌，並保留執行個體最近 30 個命令的日誌。由於執行處於除錯模式，因此日誌內含 Chef 執行的詳細說明，包括傳送到 `stdout` 和 `stderror` 的文字。如果配方失敗，日誌會包含 Chef 堆疊追蹤。 OpsWorks Stacks 提供數種檢視 Chef 日誌的方式。一旦您擁有日誌資訊，就可用其為失敗配方除錯。 **注意** 您也可以透過使用 SSH 連線到執行個體並執行代理程式 CLI `show_log` 命令，來檢視指定日誌的結尾。如需詳細資訊，請參閱[顯示 Chef 日誌](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log)。 **Topics** + [使用主控台檢視 Chef 日誌](#troubleshoot-debug-log-console) + [使用 CLI 或 API 檢視 Chef 日誌](#troubleshoot-debug-log-cli) + [在執行個體上檢視 Chef 日誌](#troubleshoot-debug-log-instance) + [解讀 Chef 日誌](#troubleshoot-debug-log-interpret) + [常見的 Chef 日誌錯誤](#troubleshoot-debug-log-errors) ## 使用主控台檢視 Chef 日誌檢視 Chef 日誌最簡單的方法是前往執行個體的詳細資訊頁面。**Logs (日誌)** 區段包含每個事件和[執行配方](workingstacks-commands.md)命令的進入點。下圖為執行個體的 **Logs (日誌)** 區段，顯示的內容是 **configure (設定)** 和 **setup (安裝)** 命令的日誌，兩者分別對應到設定和安裝生命週期事件。 ![\[Logs section showing configure and setup commands with timestamps and durations.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/gs11.png) 按一下適當命令的**日誌**欄中的**顯示**，以檢視對應的 Chef 日誌。如果發生錯誤， OpsWorks Stacks 會自動將日誌開啟為錯誤，通常位於檔案結尾。 ## 使用 CLI 或 API 檢視 Chef 日誌您可以使用 OpsWorks Stacks CLI [https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)命令或 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html) API 動作來檢視存放在 Amazon S3 儲存貯體上的日誌。以下說明如何使用 CLI 檢視指定執行個體目前任一組日誌檔案。使用 `DescribeCommands` 的程序基本上很類似。 **使用 OpsWorks Stacks 檢視執行個體的 Chef 日誌** 1. 開啟執行個體的詳細資訊頁面，並複製其 **OpsWorks ID** 值。 1. 使用此 ID 值執行 `describe-commands` CLI 命令，如下所示： ``` aws opsworks describe-commands --instance-id 67bf0da2-29ed-4217-990c-d895d51812b9 ``` 該命令會針對 OpsWorks Stacks 在執行個體上執行的每個命令，傳回具有內嵌物件的 JSON 物件，並以最新的先到者為準。`Type` 參數包含每個內嵌物件的命令類型，在此範例中為 `configure` 命令和 `setup` 命令。 ``` { "Commands": [ { "Status": "successful", "CompletedAt": "2013-10-25T19:38:36+00:00", "InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9", "AcknowledgedAt": "2013-10-25T19:38:24+00:00", "LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/b6c402df-5c23-45b2-a707-ad20b9c5ae40?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE &Expires=1382731518&Signature=YkqS5IZN2P4wixjHwoC3aCMbn5s%3D&response-cache-control=private&response-content-encoding=gzip&response-content- type=text%2Fplain", "Type": "configure", "CommandId": "b6c402df-5c23-45b2-a707-ad20b9c5ae40", "CreatedAt": "2013-10-25T19:38:11+00:00", "ExitCode": 0 }, { "Status": "successful", "CompletedAt": "2013-10-25T19:31:08+00:00", "InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9", "AcknowledgedAt": "2013-10-25T19:29:01+00:00", "LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/2a90e862-f974-42a6-9342-9a4f03468358?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE &Expires=1382731518&Signature=cxKYHO8mCCd4MvOyFb6ywebeQtA%3D&response-cache-control=private&response-content-encoding=gzip&response-content- type=text%2Fplain", "Type": "setup", "CommandId": "2a90e862-f974-42a6-9342-9a4f03468358", "CreatedAt": "2013-10-25T19:26:01+00:00", "ExitCode": 0 } ] } ``` 1. 將 `LogUrl` 值複製到瀏覽器以檢視日誌。如果執行個體具有多個命令，您可以將參數新增至 `describe-commands`，篩選出哪些命令應包含在回應物件中。如需詳細資訊，請參閱 [describe-commands](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)。 ## 在執行個體上檢視 Chef 日誌 **注意** 本節中的主題適用於 Chef 12。如需 Chef 11.10 和較舊版 Chef 日誌位置的資訊，請參閱[為 Linux 的 Chef 11.10 和更舊版本進行故障診斷](https://docs.aws.amazon.com/opsworks/latest/userguide/troubleshooting-chef-11-linux.html)。 ### Linux 執行個體 OpsWorks Stacks 會將每個執行個體的 Chef 日誌存放在其`/var/chef/runs`目錄中。(對於 Linux 執行個體，此目錄也包含相關聯的[資料包](data-bags.md)，其以 JSON 格式的檔案存放)。您需要 [sudo 權限](opsworks-security-users.md)才能存取此目錄。每個執行的日誌位於個別執行子目錄中名為 `chef.log` 的檔案。 OpsWorks Stacks 會將其內部日誌存放在執行個體的 `/var/log/aws/opsworks` 資料夾中。此資訊通常對故障診斷的幫助不大。不過，這些日誌對於 OpsWorks Stacks 支援很有用，如果您遇到服務問題，可能會要求您提供這些日誌。Linux 日誌有時也可提供有用的故障診斷資料。 ### Windows 執行個體 **代理程式日誌** 在 Windows 執行個體上，OpsWorks 日誌存放於 `ProgramData` 路徑，如下所示。數字會包含時間戳記。 ``` C:\ProgramData\OpsWorksAgent\var\logs\number ``` **注意** 根據預設，`ProgramData` 是隱藏的資料夾。若要將其取消隱藏，請導覽至 **Folder Options (資料夾選項)**。在 **View (檢視)** 下，選擇顯示隱藏檔案的選項。下列範例示範 Windows 執行個體上的代理程式日誌。 ``` Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 5/24/2015 11:59 PM 127277 command.20150524.txt -a--- 5/25/2015 11:59 PM 546772 command.20150525.txt -a--- 5/26/2015 11:59 PM 551514 command.20150526.txt -a--- 5/27/2015 9:43 PM 495181 command.20150527.txt -a--- 5/24/2015 11:59 PM 24353 keepalive.20150524.txt -a--- 5/25/2015 11:59 PM 106232 keepalive.20150525.txt -a--- 5/26/2015 11:59 PM 106208 keepalive.20150526.txt -a--- 5/27/2015 8:54 PM 92593 keepalive.20150527.txt -a--- 5/24/2015 7:19 PM 3891 service.20150524.txt -a--- 5/27/2015 8:54 PM 1493 service.20150527.txt -a--- 5/24/2015 11:59 PM 112549 wire.20150524.txt -a--- 5/25/2015 11:59 PM 501501 wire.20150525.txt -a--- 5/26/2015 11:59 PM 499640 wire.20150526.txt -a--- 5/27/2015 8:54 PM 436870 wire.20150527.txt ``` **Chef 日誌** 在 Windows 執行個體上，Chef 日誌存放於 `ProgramData` 路徑，如下所示。數字會包含時間戳記。 ``` C:\ProgramData\OpsWorksAgent\var\commands\number ``` **注意** 此目錄僅包含第一個 (OpsWorks 擁有的) Chef 執行的輸出。下列範例示範 Windows 執行個體上 OpsWorks 擁有的 Chef 日誌。 ``` Mode LastWriteTime Name ---- ------------- ---- d---- 5/24/2015 7:23 PM configure-7ecb5f47-7626-439b-877f-5e7cb40ab8be d---- 5/26/2015 8:30 PM configure-8e74223b-d15d-4372-aeea-a87b428ffc2b d---- 5/24/2015 6:34 PM configure-c3980a1c-3d08-46eb-9bae-63514cee194b d---- 5/26/2015 8:32 PM grant_remote_access-70dbf834-1bfa-4fce-b195-e50e85402f4c d---- 5/26/2015 10:30 PM revoke_remote_access-1111fce9-843a-4b27-b93f-ecc7c5e9e05b d---- 5/24/2015 7:21 PM setup-754ec063-8b60-4cd4-b6d7-0e89d7b7aa78 d---- 5/26/2015 8:27 PM setup-af5bed36-5afd-4115-af35-5766f88bc039 d---- 5/24/2015 6:32 PM setup-d8abeffa-24d4-414b-bfb1-4ad07319f358 d---- 5/24/2015 7:13 PM shutdown-c7130435-9b5c-4a95-be17-6b988fc6cf9a d---- 5/26/2015 8:25 PM sync_remote_users-64c79bdc-1f6f-4517-865b-23d2def4180c d---- 5/26/2015 8:48 PM update_custom_cookbooks-2cc59a94-315b-414d-85eb-2bdea6d76c6a ``` **使用者 Chef 日誌** 您可以在名為 `logfile.txt` 的檔案中找到您 Chef 執行的日誌，該檔案則位於以編號之 Chef 命令命名的資料夾中，如下圖所示。 C:/chef └── `runs` └── `command-12345` ├── `attribs.json` ├── `client.rb` └── `logfile.txt` ## 解讀 Chef 日誌日誌的開頭主要包含內部 Chef 記錄。 ``` # Logfile created on Thu Oct 17 17:25:12 +0000 2013 by logger.rb/1.2.6 [2013-10-17T17:25:12+00:00] INFO: *** Chef 11.4.4 *** [2013-10-17T17:25:13+00:00] DEBUG: Building node object for php-app1.localdomain [2013-10-17T17:25:13+00:00] DEBUG: Extracting run list from JSON attributes provided on command line [2013-10-17T17:25:13+00:00] INFO: Setting the run_list to ["opsworks_custom_cookbooks::load", "opsworks_custom_cookbooks::execute"] from JSON [2013-10-17T17:25:13+00:00] DEBUG: Applying attributes from json file [2013-10-17T17:25:13+00:00] DEBUG: Platform is amazon version 2013.03 [2013-10-17T17:25:13+00:00] INFO: Run List is [recipe[opsworks_custom_cookbooks::load], recipe[opsworks_custom_cookbooks::execute]] [2013-10-17T17:25:13+00:00] INFO: Run List expands to [opsworks_custom_cookbooks::load, opsworks_custom_cookbooks::execute] [2013-10-17T17:25:13+00:00] INFO: Starting Chef Run for php-app1.localdomain [2013-10-17T17:25:13+00:00] INFO: Running start handlers [2013-10-17T17:25:13+00:00] INFO: Start handlers complete. [2013-10-17T17:25:13+00:00] DEBUG: No chefignore file found at /opt/aws/opsworks/releases/20131015111601_209/cookbooks/chefignore no files will be ignored [2013-10-17T17:25:13+00:00] DEBUG: Cookbooks to compile: ["gem_support", "packages", "opsworks_bundler", "opsworks_rubygems", "ruby", "ruby_enterprise", "dependencies", "opsworks_commons", "scm_helper", :opsworks_custom_cookbooks] [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook gem_support's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/gem_support/libraries/current_gem_version.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook packages's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/packages/libraries/packages.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook dependencies's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/dependencies/libraries/current_gem_version.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/activesupport_blank.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/monkey_patch_chefgem_resource.rb ... ``` 檔案的這一部分對 Chef 專家來說非常有用。請注意，即使大多數命令包含更多配方，執行清單僅含兩個配方。這兩個配方處理載入和執行其他所有內建和自訂配方的任務。檔案最有趣的部分通常在結尾。如果執行成功結束，您應該會看到類似以下的內容： ``` ... [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: STDERR: [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: ---- End output of /sbin/service mysqld restart ---- [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Ran /sbin/service mysqld restart returned 0 [Tue, 11 Jun 2013 16:00:50 +0000] INFO: service[mysql]: restarted successfully [Tue, 11 Jun 2013 16:00:50 +0000] INFO: Chef Run complete in 84.07096 seconds [Tue, 11 Jun 2013 16:00:50 +0000] INFO: cleaning the checksum cache [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-8wef7e-0 [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-1xpwyb6-0 [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--etc-monit-conf [Tue, 11 Jun 2013 16:00:50 +0000] INFO: Running report handlers [Tue, 11 Jun 2013 16:00:50 +0000] INFO: Report handlers complete [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Exiting ``` **注意** 您可以使用代理程式 CLI 在執行期間或結束後顯示日誌結尾。如需詳細資訊，請參閱[顯示 Chef 日誌](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log)。如果配方失敗，您應該尋找 ERROR 層級的輸出，該輸出將包含例外狀況，並接續著 Chef 堆疊追蹤，如下所示： ``` ... Please report any problems with the /usr/scripts/mysqlbug script! [ OK ] MySQL Daemon failed to start. Starting mysqld: [FAILED]STDERR: 130611 15:07:55 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead. 130611 15:07:56 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead. ---- End output of /sbin/service mysqld start ---- /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:184:in `handle_command_failures' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:131:in `run_command' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service/init.rb:37:in `start_service' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service.rb:60:in `action_start' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `send' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `run_action' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:53:in `run_action' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `each' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:84:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:268:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:158:in `run' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:190:in `run_application' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `loop' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `run_application' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application.rb:62:in `run' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/chef-solo:25 /opt/aws/opsworks/current/bin/chef-solo:16:in `load' /opt/aws/opsworks/current/bin/chef-solo:16 ``` 檔案的結尾是 Chef 堆疊追蹤。您也應該檢查例外狀況之前的輸出，通常包含系統錯誤 (例如 `package not available`)，這在故判斷失敗原因時也很有用。在此範例中，MySQL 協助程式無法啟動。 ## 常見的 Chef 日誌錯誤下列是一些常見的 Chef 日誌錯誤及其解決方法。找不到日誌在 Chef 執行開始時，執行個體會收到預先簽章的 Amazon S3 URL，可讓您在 Chef 執行完成時在網頁上檢視日誌。由於此 URL 會在兩個小時後過期，因此如果 Chef 執行需要超過兩個小時，即使 Chef 執行期間沒有發生任何問題，也不會將日誌上傳至 Amazon S3 網站。建立日誌的命令會成功，但僅可在執行個體上檢視日誌，而不能在預先簽章的 URL 上檢視。日誌意外結束如果 Chef 日誌意外結束，並未指出成功或顯示錯誤資訊，您可能發生記憶體低下的狀態，讓 Chef 無法完成日誌。最佳選項就是使用更大的執行個體重試。缺少技術指南或配方如果 Chef 執行發生技術指南或配方不在技術指南快取內的情況，您將看到類似以下的內容： ``` DEBUG: Loading Recipe mycookbook::myrecipe via include_recipe ERROR: Caught exception during execution of custom recipe: mycookbook::myrecipe: Cannot find a cookbook named mycookbook; did you forget to add metadata to a cookbook? ``` 此項目指出 `mycookbook` 技術指南不在技術指南快取內。使用 Chef 11.4 時，如果您未在 `metadata.rb` 中正確宣告相依性，也可能發生此錯誤。 OpsWorks Stacks 會從執行個體的技術指南快取執行配方。其會在執行個體啟動時，將儲存庫中的技術指南下載到此快取中。不過，如果您後續修改儲存庫中的技術指南， OpsWorks Stacks 不會自動更新線上執行個體上的快取。如果您在執行個體啟動後，修改技術指南或新增技術指南，請執行以下步驟： 1. 確定您已將變更遞交到儲存庫。 1. 執行[更新技術指南堆疊命令](workingstacks-commands.md)，以使用儲存庫中的最新版本來更新技術指南快取。本機命令失敗如果 Chef `execute` 資源無法執行指定命令，您將會看到類似以下的內容： ``` DEBUG: ---- End output of ./configure --with-config-file-path=/ returned 2 ERROR: execute[PHP: ./configure] (/root/opsworks-agent/site-cookbooks/php-fpm/recipes/install.rb line 48) had an error: ./configure --with-config-file-path=/ ``` 向上捲動日誌，您應該會看到命令的 `stderr` 和 `stdout` 輸出，這有助您判斷命令失敗的原因。套件失敗如果套件安裝失敗，您將會看到類似以下的內容： ``` ERROR: package[zend-server-ce-php-5.3] (/root/opsworks-agent/site-cookbooks/zend_server/recipes/install.rb line 20) had an error: apt-get -q -y --force-yes install zend-server-ce-php-5.3=5.0.4+b17 returned 100, expected 0 ``` 向上捲動日誌，您應該會看到命令的 STDOUT 和 STDERROR 輸出，這有助您判斷套件安裝失敗的原因。 # 使用 OpsWorks Stacks 代理程式 CLI **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 代理程式 CLI 只適用於 Linux 執行個體。在每個線上執行個體上， OpsWorks Stacks 都會安裝代理程式，該代理程式會與服務通訊。Stacks OpsWorks 服務會依序傳送命令給代理程式，以執行任務，例如在生命週期事件發生時啟動執行個體上的 Chef 執行。在 Linux 執行個體上，代理程式會公開命令列界面 (CLI)，這對故障診斷非常有用。若要執行代理程式 CLI 命令，請使用 [SSH 連線到執行個體](workinginstances-ssh.md)。然後您可以執行代理程式 CLI 命令來執行各種任務，包括下列任務： + 執行配方。 + 顯示 Chef 日誌。 + 顯示[堆疊組態與部署 JSON](workingcookbook-json.md)。如需如何設定與執行個體間 SSH 連線的詳細資訊，請參閱[使用 SSH 登入](workinginstances-ssh.md)。您也必須具有堆疊的 [SSH 和 sudo 許可](opsworks-security-users.md)。本節說明如何使用代理程式 CLI 進行故障診斷。如需詳細資訊和完整命令參考，請參閱 [OpsWorks Stacks 代理程式 CLI](agent.md)。 **Topics** + [執行配方](#troubleshoot-debug-cli-recipes) + [顯示 Chef 日誌](#troubleshoot-debug-cli-log) + [顯示堆疊組態與部署 JSON](#troubleshoot-debug-cli-json) ## 執行配方代理程式 CLI [`run_command`](agent-run.md) 命令會指示代理程式重新執行其先前執行過的命令。最實用的故障診斷命令為 `setup`、`configure`、`deploy` 和 `undeploy`，並各自對應到一個生命週期事件。這些命令會指示代理程式起始 Chef 執行，以執行相關聯的配方。 **注意** `run_command` 命令僅限執行與指定命令相關聯的配方群組，通常是與生命週期事件相關聯的配方。您無法用它執行特定配方。若要執行一或多個指定配方，請使用[執行配方堆疊命令](workingstacks-commands.md)或同等的 CLI 或 API 動作 ([https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) 和 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html))。 `run_command` 命令在為自訂配方除錯方面相當有用，尤其是指派至安裝和設定生命週期事件的配方，這些事件並無法直接從主控台加以觸發。透過使用 `run_command`，您可以隨時視需要執行特定事件的配方，而無須啟動或停止執行個體。 **注意** OpsWorks Stacks 會從執行個體的技術指南快取執行配方，而非技術指南儲存庫。當執行個體啟動時， OpsWorks Stacks 會將技術指南下載至此快取，但如果您後續修改技術指南，則不會自動更新線上執行個體上的快取。如果您在啟動執行個體後修改了技術指南，請務必執行[更新技術指南堆疊命令](workingstacks-commands.md)堆疊命令，以使用儲存庫中的最新版本更新技術指南快取。代理程式僅快取最新的命令。您可以執行 [`list_commands`](agent-list.md) 來列出這些命令，這會傳回已快取命令及其執行時間的清單。 ``` sudo opsworks-agent-cli list_commands 2013-02-26T19:08:26 setup 2013-02-26T19:12:01 configure 2013-02-26T19:12:05 configure 2013-02-26T19:22:12 deploy ``` 若要重新執行最新的命令，請執行： ``` sudo opsworks-agent-cli run_command ``` 若要重新執行最新執行個體的指定命令，請執行： ``` sudo opsworks-agent-cli run_command command ``` 例如，若要重新執行安裝配方，您可以執行下列命令： ``` sudo opsworks-agent-cli run_command setup ``` 每個命令都有一個相關聯的[堆疊組態和部署 JSON](workingcookbook-json.md)，代表該命令執行時堆疊和部署的狀態。由於該資料可能隨著命令不同有所差異，因此較舊執行個體的命令可能使用與最新執行個體不同的資料。若要重新執行特定執行個體的命令，請複製 `list_commands` 輸出中的時間，並執行以下命令： ``` sudo opsworks-agent-cli run_command time ``` 上述範例均使用預設 JSON 重新執行命令，也就是為該命令安裝的 JSON。您可以對任意 JSON 檔案重新執行命令，如下所示： ``` sudo opsworks-agent-cli run_command -f /path/to/valid/json.file ``` ## 顯示 Chef 日誌代理程式 CLI [`show_log`](agent-show.md) 命令會顯示指定的日誌。在命令完成後，您將會看到檔案結尾。因此，`show_log` 命令提供方便查看日誌結尾的方法，您通常會在這裡找到錯誤資訊。您可以向上捲動以查看日誌的先前部分。若要顯示目前命令的日誌，請執行： ``` sudo opsworks-agent-cli show_log ``` 您也可以顯示特定命令的日誌，但請注意，代理程式僅快取最後三十個命令的日誌。您可以執行 [`list_commands`](agent-list.md) 列出執行個體的命令，這會傳回已快取命令及其執行時間的清單。如需範例，請參閱 [執行配方](#troubleshoot-debug-cli-recipes)。若要顯示特定命令最新執行狀況的日誌，請執行下列命令： ``` sudo opsworks-agent-cli show_log command ``` 命令參數可以設為 `setup`、`configure`、`deploy`、`undeploy`、`start`、`stop` 或 `restart`。這些命令大部分都對應到生命週期事件，並指示代理程式執行相關聯配方。若要顯示特定命令執行狀況的日誌，請複製 `list_commands` 輸出中的日期並執行： ``` sudo opsworks-agent-cli show_log date ``` 如果命令仍在執行，`show_log` 會顯示日誌的目前狀態。 **注意** 使用 `show_log` 來為錯誤和記憶體不足問題進行故障診斷的其中一種方法，是在執行期間顯示日誌的結尾，如下所示：使用 `run_command` 來觸發適當的生命週期事件。如需詳細資訊，請參閱[執行配方](#troubleshoot-debug-cli-recipes)。重複執行 `show_log` 以在寫入日誌時查看日誌的結尾。如果 Chef 記憶體不足或意外結束，日誌會突然結束。如果配方失敗，日誌的結尾為例外狀況和堆疊追蹤。 ## 顯示堆疊組態與部署 JSON 配方使用的許多資料來自[堆疊組態和部署 JSON](workingcookbook-json.md)，這定義了一組 Chef 屬性，以提供堆疊組態、任何部署和使用者可新增之選用自訂屬性的詳細說明。對於每個命令， OpsWorks Stacks 會安裝代表命令時堆疊和部署狀態的 JSON。如需詳細資訊，請參閱[堆疊組態及部署屬性](workingcookbook-json.md)。如果自訂配方從堆疊組態和部署 JSON 取得資料，您可以檢查該 JSON 來驗證資料。顯示堆疊組態和部署 JSON 最簡單的方式，是執行代理程式 CLI [`get_json`](agent-json.md) 命令，這會顯示 JSON 物件的格式化版本。以下提供某些一般輸出的前幾行： ``` { "opsworks": { "layers": { "php-app": { "id": "4a2a56c8-f909-4b39-81f8-556536d20648", "instances": { "php-app2": { "elastic_ip": null, "region": "us-west-2", "booted_at": "2013-02-26T20:41:10+00:00", "ip": "10.112.235.192", "aws_instance_id": "i-34037f06", "availability_zone": "us-west-2a", "instance_type": "c1.medium", "private_dns_name": "ip-10-252-0-203.us-west-2.compute.internal", "private_ip": "10.252.0.203", "created_at": "2013-02-26T20:39:39+00:00", "status": "online", "backends": 8, "public_dns_name": "ec2-10-112-235-192.us-west-2.compute.amazonaws.com" ... ``` 您可以顯示最新的堆疊組態和部署 JSON，如下所示： ``` sudo opsworks-agent-cli get_json ``` 您可以執行下列命令來顯示指定命令的最新堆疊組態和部署 JSON： ``` sudo opsworks-agent-cli get_json command ``` 命令參數可以設為 `setup`、`configure`、`deploy`、`undeploy`、`start`、`stop` 或 `restart`。這些命令大部分都對應到生命週期事件，並指示代理程式執行相關聯配方。您可以指定命令的日期，來顯示特定命令執行的堆疊組態和部署 JSON，如下所示： ``` sudo opsworks-agent-cli get_json date ``` 使用此命令的最簡單方式如下： 1. 執行 `list_commands` 會傳回清單，內含已在執行個體上執行的命令，以及每個命令的執行日期。 1. 複製適當命令的日期，並將其做為 `get_json` *date* 引數使用。 # 常見的除錯和故障診斷問題 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節說明一些常見的除錯和故障診斷問題，以及其解決方案。 **Topics** + [對 OpsWorks Stacks 進行故障診斷](common-issues-troubleshoot.md) + [故障診斷執行個體註冊](#common-issues-instance-registration) # 對 OpsWorks Stacks 進行故障診斷 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。本節包含一些常見的 OpsWorks Stacks 問題及其解決方案。 **Topics** + [無法管理執行個體](#w2ab1c14c77c17b9b9) + [在 Chef 執行之後，執行個體無法開機](#w2ab1c14c77c17b9c11) + [Layer 的執行個體皆未通過 Elastic Load Balancing 運作狀態檢查](#common-issues-troubleshoot-health) + [無法與 Elastic Load Balancing Load Balancer 通訊](#w2ab1c14c77c17b9c15) + [匯入的現場部署執行個體在重新啟動之後無法完成磁碟區設定](#w2ab1c14c77c17b9c17) + [EBS 磁碟區在重新開機後無法重新連接](#common-issues-troubleshoot-ebs) + [無法刪除 OpsWorks Stacks 安全群組](#common-issues-troubleshoot-booting-secgroup) + [意外刪除 OpsWorks Stacks 安全群組](#common-issues-troubleshoot-booting-secgroup-delete) + [Chef 日誌無故終止](#common-issues-troubleshoot-log-terminates) + [無法更新技術指南](#common-issues-troubleshoot-update) + [執行個體停滯在開機中狀態](#common-issues-troubleshoot-booting) + [執行個體未預期的重新啟動](#common-issues-troubleshoot-restart) + [`opsworks-agent` 程序在執行個體上執行](#common-issues-troubleshoot-agent) + [未預期的 execute\$1recipes 命令](#common-issues-troubleshoot-unexpected) ## 無法管理執行個體 **問題：**您再也無法管理以前能管理的執行個體。在某些情況下，日誌可能會顯示類似下列內容的錯誤。 ``` Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid. ``` **原因：**此問題可能會在執行個體依存之 OpsWorks 以外的資源遭到編輯或刪除時發生。以下是可能會中斷與執行個體通訊之資源變更的範例。 + 與執行個體相關聯的 IAM 使用者或角色在 Stacks OpsWorks 之外被意外刪除。這會導致安裝在執行個體上的 OpsWorks 代理程式與 OpsWorks Stacks 服務之間的通訊失敗。與執行個體關聯的使用者需要在執行個體的生命存續期間內存在。 + 在執行個體離線時編輯磁碟區或儲存體組態，可能會使執行個體無法管理。 + 手動將 EC2 執行個體新增至 ELB。每次執行個體進入或離開線上狀態時，都會 OpsWorks 重新設定指派的 Elastic Load Balancing 負載平衡器。 OpsWorks 只會將已知為有效成員的執行個體視為有效成員；在外部新增的執行個體 OpsWorks，或透過其他程序新增的執行個體會遭到移除。每一個其他的執行個體都會遭到移除。 **解決方案：**請勿刪除執行個體所依賴的 IAM 使用者或角色。若可能的話，請只在依存執行個體執行時編輯磁碟區或儲存體組態。使用 OpsWorks 管理 OpsWorks 執行個體的負載平衡器或 EIP 成員資格。當您註冊執行個體時，為協助避免在使用者意外刪除時管理已註冊執行個體的問題，請將 `--use-instance-profile` 參數新增至您的`register`命令，以改用執行個體的內建執行個體描述檔。 ## 在 Chef 執行之後，執行個體無法開機 **問題：**於設定為使用自訂技術指南的 Chef 11.10 或較舊版本的堆疊上，在使用社群技術指南的 Chef 執行之後，執行個體無法開機。日誌訊息可能會表示配方編譯失敗 ("Recipe Compile Error")，或是因為找不到依存項目而無法載入。 **原因：**最有可能的原因是自訂或社群技術指南不支援堆疊所使用的 Chef 版本。一些熱門的社群技術指南，例如 `[apt](https://supermarket.chef.io/cookbooks/apt)` 和 `[build-essential](https://supermarket.chef.io/cookbooks/build-essential/versions/3.2.0)` 與 Chef 11.10 有已知的相容性問題。 **解決方案：**在開啟**使用自訂 Chef 技術指南**設定的 OpsWorks Stacks 堆疊上，自訂或社群技術指南必須一律支援堆疊使用的 Chef 版本。請將社群技術指南固定 (即將技術指南版本編號設為特定版本) 在與您在堆疊設定中設定之 Chef 版本相容的版本。若要尋找支援的社群技術指南版本，請檢視編譯失敗之技術指南的變更記錄，並只使用您堆疊可支援的最近版本。若要固定技術指南的版本，請在您自訂技術指南儲存庫的 Berksfile 中指定明確的版本編號。例如 `cookbook 'build-essential', '= 3.2.0'`。 ## Layer 的執行個體皆未通過 Elastic Load Balancing 運作狀態檢查 **問題：**您將 Elastic Load Balancing 負載平衡器連接到應用程式伺服器層，但所有執行個體都未通過運作狀態檢查。 **原因：**當您建立 Elastic Load Balancing 負載平衡器時，您必須指定負載平衡器呼叫的 ping 路徑，以判斷執行個體是否正常運作。請務必指定適合您應用程式的 ping 路徑。預設值為 /index.html。若您的應用程式不包含 `index.html`，您必須指定適當的路徑，否則運作狀態檢查將會失敗。例如，[Chef 11 Linux 堆疊入門](gettingstarted.md)中使用的 SimplePHPApp 應用程式並未使用 index.html。那些伺服器的適當 ping 路徑為 /。 **解決方案：**編輯負載平衡器的 ping 路徑。如需詳細資訊，請參閱 [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html) ## 無法與 Elastic Load Balancing Load Balancer 通訊 **問題：**您建立 Elastic Load Balancing 負載平衡器並將其連接到應用程式伺服器層，但當您按一下負載平衡器的 DNS 名稱或 IP 地址來執行應用程式時，您會收到下列錯誤：「遠端伺服器未回應」。 **原因：**如果您的堆疊在預設 VPC 中執行，當您在區域中建立 Elastic Load Balancing 負載平衡器時，您必須指定安全群組。安全群組必須具備輸入規則，允許來自您 IP 地址的傳入流量。若您指定 **default VPC security group (預設 VPC 安全群組)**，預設的輸入規則不會接受任何傳入流量。 **解決方案：**編輯安全群組輸入規則，以接受來自適當 IP 地址的傳入流量。 1. 在 [Amazon EC2 主控台的](https://console.aws.amazon.com/ec2/)導覽窗格中按一下**安全群組**。 1. 選取負載平衡器的安全群組。 1. 按一下 **Inbound (傳入)** 標籤上的 **Edit (編輯)**。 1. 新增一條輸入規則，並將其中的 **Source (來源)** 設為適當的 CIDR。例如，指定 **Anywhere (任何位置)** 會將 CIDR 設為 0.0.0.0/0，即指示負載平衡器接受來自任何 IP 地址的傳入流量。 ## 匯入的現場部署執行個體在重新啟動之後無法完成磁碟區設定 **問題：**您重新啟動已匯入 Stacks OpsWorks 的 EC2 執行個體，且 OpsWorks Stacks 主控台顯示**失敗**為執行個體狀態。這可能會在 Chef 11 或 Chef 12 執行個體上發生。 **原因：**OpsWorks Stacks 於設定程序中可能無法將磁碟區連接至您的執行個體。其中一個可能的原因是 OpsWorks Stacks 在您執行 `setup` 命令時覆寫了您執行個體上的磁碟區組態。 **解決方案：**開啟執行個體的 **Details (詳細資訊)** 頁面，檢查 **Volumes (磁碟區)** 區域內的磁碟區組態。請注意，您只能在您的執行個體處於 **stopped (已停止)** 狀態時才能變更您的磁碟區組態。請確認每個磁碟區都有指定的掛載點和名稱。在重新啟動執行個體之前，請確認您在 OpsWorks Stacks 的組態中提供正確的掛載點。 ## EBS 磁碟區在重新開機後無法重新連接 **問題：**您使用 Amazon EC2 主控台將 Amazon EBS 磁碟區連接至執行個體，但當您重新啟動執行個體時，磁碟區不再連接。 **原因：** OpsWorks Stacks 只能重新連接其已知的 Amazon EBS 磁碟區，這些磁碟區僅限於下列項目： + Stacks OpsWorks 建立的磁碟區。 + 來自您帳戶的磁碟區，且已藉 **Resources (資源)** 頁面明確向堆疊註冊。 **解決方案：**僅使用 Stacks 主控台、API 或 CLI OpsWorks 管理您的 Amazon EBS 磁碟區。如果您想要將其中一個帳戶的 Amazon EBS 磁碟區與堆疊搭配使用，請使用堆疊**的資源**頁面來註冊磁碟區並將其連接至執行個體。如需詳細資訊，請參閱[資源管理](resources.md)。 ## 無法刪除 OpsWorks Stacks 安全群組 **問題：**刪除堆疊後，會留下一些無法刪除的 Stacks OpsWorks 安全群組。 **原因：**安全群組必須依照特定順序進行刪除。 **解決方案：**首先，請確認沒有任何執行個體正在使用安全群組。接著，依照以下順序刪除下列任何安全群組 (若有的話)： 1. AWS-OpsWorks-Blank-Server 1. AWS-OpsWorks-Monitoring-Master-Server 1. AWS-OpsWorks-DB-Master-Server 1. AWS-OpsWorks-Memcached-Server 1. AWS-OpsWorks-Custom-Server 1. AWS-OpsWorks-nodejs-App-Server 1. AWS-OpsWorks-PHP-App-Server 1. AWS-OpsWorks-Rails-App-Server 1. AWS-OpsWorks-Web-Server 1. AWS-OpsWorks-Default-Server 1. AWS-OpsWorks-LB-Server ## 意外刪除 OpsWorks Stacks 安全群組 **問題：**您已刪除其中一個 OpsWorks Stacks 安全群組，需要重新建立。 **原因：**這些安全群組通常都是意外遭到刪除。 **解決方案：**重新建立的群組必須是和原始群組完全一模一樣的複本，其群組名稱也要有相同的大小寫。與其手動重新建立群組，建議的方法為讓 OpsWorks Stacks 為您執行這項任務。只要在相同的 AWS 區域和 VPC 中建立新的堆疊，如果有的話， Stacks OpsWorks 就會自動重新建立所有內建的安全群組，包括您刪除的安全群組。您接著可以刪除您不再需要使用的堆疊，安全群組仍會留下。 ## Chef 日誌無故終止 **問題：**Chef 日誌無故終止。日誌的最後沒有指出成功執行或顯示異常和堆疊追蹤。 **原因：**此行為通常是因為記憶體不足。 **解決方案：**建立更大的執行個體，並使用代理程式 CLI `run_command` 命令重新執行配方。如需詳細資訊，請參閱[執行配方](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes)。 ## 無法更新技術指南 **問題：**您更新您的技術指南，但堆疊的執行個體仍然執行舊的配方。 **Cause：** OpsWorks Stacks 會快取每個執行個體上的技術指南，並從快取執行配方，而非儲存庫。當您啟動新的執行個體時， OpsWorks Stacks 會將您的技術指南從儲存庫下載到執行個體的快取。但是，若您之後修改您的自訂技術指南， OpsWorks Stacks 不會自動更新線上執行個體的快取。 **解決方案：**執行[更新技術指南堆疊命令](workingstacks-commands.md)，明確指示 OpsWorks Stacks 更新線上執行個體的技術指南快取。 ## 執行個體停滯在開機中狀態 **問題：**當您重新啟動執行個體，或自動修復自動予以重新啟動時，啟動操作停滯在 `booting` 狀態。 **原因：**此問題其中一個可能的原因是 VPC 組態，包含預設 VPC。執行個體必須始終能夠與 OpsWorks Stacks 服務、Amazon S3 和套件、技術指南和應用程式儲存庫進行通訊。例如，如果您從預設 VPC 移除預設閘道，執行個體會失去與 Stacks OpsWorks 服務的連線。由於 OpsWorks Stacks 無法再與執行個體[代理](troubleshoot-debug-cli.md)程式通訊，因此會將執行個體視為失敗並[自動修復](workinginstances-autohealing.md)。不過，如果沒有連線， OpsWorks Stacks 就無法在已修復的執行個體上安裝執行個體代理程式。如果沒有代理程式， OpsWorks Stacks 就無法在執行個體上執行安裝配方，因此啟動操作無法超過「開機」狀態。 **解決方案：**修改您的 VPC 組態，讓您的執行個體具備需要的連線能力。 ## 執行個體未預期的重新啟動 **問題：**已停止的執行個體未預期的重新啟動。 **原因 1：**如果您已啟用執行個體的[自動修復](workinginstances-autohealing.md)， OpsWorks Stacks 會定期對相關聯的 Amazon EC2 執行個體執行運作狀態檢查，並重新啟動任何運作狀態不佳的執行個體。如果您使用 Amazon EC2 主控台、API 或 OpsWorks CLI 來停止或終止 Stacks 受管執行個體，則不會通知 OpsWorks Stacks。因此，它會將已停止的執行個體視為運作狀態不良，並自動重新啟動它。 **解決方案：**僅使用 OpsWorks Stacks 主控台、API 或 CLI 管理您的執行個體。如果您使用 OpsWorks Stacks 來停止或刪除執行個體，則不會重新啟動執行個體。如需詳細資訊，請參閱[手動啟動、停止和重新開機全年無休的執行個體](workinginstances-starting.md)及[刪除 OpsWorks Stacks 執行個體](workinginstances-delete.md)。 **原因 2：**執行個體可能會因為各種原因而故障。如果您已啟用自動修復， OpsWorks Stacks 會自動重新啟動失敗的執行個體。 **解決方案：**這是正常操作；除非您不希望 OpsWorks Stacks 重新啟動失敗的執行個體，否則不需要執行任何動作。在這種情況下，建議您停用自動修復。 ## `opsworks-agent` 程序在執行個體上執行 **問題：**您的執行個體上有數個 `opsworks-agent` 程序正在執行。例如： ``` aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543 aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543 aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543 aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24 ``` **原因：**這些是維持代理程式正常操作所需的程序。他們會執行像是處理部署，以及將持續連線訊息傳送回服務等任務。 **解決方案：**這是正常行為。請不要停止這些程序，否則會影響代理程式的操作。 ## 未預期的 execute\$1recipes 命令 **問題：**執行個體詳細資訊頁面上的 **Logs (日誌)** 區段包含未預期的 `execute_recipes` 命令。未預期的 `execute_recipes` 命令也會顯示在 **Stack (堆疊)** 和 **Deployments (部署)** 頁面上。 **原因：**此問題通常是因許可變更而造成。當您變更使用者或群組的 SSH 或 sudo 許可時， OpsWorks Stacks 會執行 `execute_recipes`來更新堆疊的執行個體，也會觸發設定事件。另一個 `execute_recipes` 命令的來源是 OpsWorks Stacks，其會更新執行個體代理程式。 **解決方案：**這是正常操作，您不需要採取任何行動。若要查看 `execute_recipes` 命令執行的動作是什麼，請前往 **Deployments (部署)** 頁面，然後按一下命令的時間戳記。這會開啟命令的詳細資訊頁面，列出執行的關鍵配方。例如，以下詳細資訊頁面是執行 `ssh_users` 以更新 SSH 許可的 `execute_recipes` 命令。 ![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/images/command_details.png) 若要查看所有詳細資訊，請按一下命令的**日誌**欄中的**顯示**以顯示相關聯的 Chef 日誌。在日誌中搜尋 **Run List**. OpsWorks Stacks 維護配方。 `OpsWorks Custom Run List`例如，以下是在先前螢幕擷取畫面中顯示之 `execute_recipes` 命令的 run list，顯示每個與命令關聯的配方。 ``` [2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync", "ssh_users", "test_suite", "opsworks_cleanup"] ``` ## 故障診斷執行個體註冊本節包含一些常見的執行個體註冊問題及其解決方案。 **注意** 若您有註冊問題，請搭配 `--debug` 引數執行 `register`，這會提供額外的除錯資訊。 **Topics** + [EC2User 無權執行：...](#common-issues-instance-registration-ec2user) + [登入資料應設定在有效區域](#common-issues-instance-registration-valid-region) ### EC2User 無權執行：... **問題：**`register` 命令傳回類似下列內容： ``` A client error (AccessDenied) occurred when calling the CreateGroup operation: User: arn:aws:iam::123456789012:user/ImportEC2User is not authorized to perform: iam:CreateGroup on resource: arn:aws:iam::123456789012:group/AWS/OpsWorks/OpsWorks-b583ce55-1d01-4695-b3e5-ee19257d1911 ``` **原因：**`register`命令使用未授予必要許可的登入資料執行。使用者的政策必須允許 `iam:CreateGroup` 動作及其他動作。 **解決方案：**提供 `register` 具有必要許可的 IAM 使用者登入資料。如需詳細資訊，請參閱[安裝並設定 AWS CLI](registered-instances-register-registering-cli.md)。 ### 登入資料應設定在有效區域 **問題：**`register` 命令傳回下列內容： ``` A client error (InvalidSignatureException) occurred when calling the DescribeStacks operation: Credential should be scoped to a valid region, not 'cn-north-1'. ``` **原因：**命令的區域必須為有效的 OpsWorks Stacks 區域。如需支援的區域的清單，請參閱[區域支援](gettingstarted_intro.md#gettingstarted-intro-region)。此錯誤通常會因下列其中一個原因發生： + 堆疊位於不同的區域中，但您將堆疊的區域指派給命令的 `--region` 引數。您不需要指定堆疊區域； OpsWorks 堆疊會自動從堆疊 ID 判斷。 + 您忽略了 `--region` 引數，其隱含指定預設區域，但您的預設區域不受 OpsWorks Stacks 支援。 **解決方案：**明確`--region`設定為支援的 OpsWorks Stacks 區域``，或編輯 `config` 檔案 AWS CLI ，將預設區域變更為支援的 OpsWorks Stacks 區域。如需詳細資訊，請參閱[設定 AWS 命令列界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。 # OpsWorks Stacks 代理程式 CLI **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 **注意** 此功能只適用於 Linux 執行個體。 OpsWorks Stacks 在每個執行個體上安裝的代理程式會公開命令列界面 (CLI)。如果您[使用 SSH 登入](workinginstances-ssh.md)執行個體，則可以使用 CLI 執行下列作業： + 存取 Chef 執行的日誌檔案。 + 存取 OpsWorks Stacks 命令。 + 手動執行 Chef 配方。 + 檢視執行個體報告。 + 檢視代理程式報告。 + 檢視一組有限的堆疊組態和部署屬性。 **重要** 您只能以 root 身分或透過使用 `sudo` 來執行代理程式 CLI 命令。基本命令語法為： ``` sudo opsworks-agent-cli [--help] [command [activity] [date]] ``` 四個引數如下： **help** (選用) 單獨使用時會顯示可用命令的概覽。搭配命令使用時，`help` 會顯示命令的描述。 **command** (選用) 代理程式 CLI 命令，必須設為下列其中一項： + [agent\$1report](agent-report.md) + [get\$1json](agent-json.md) + [instance\$1report](agent-instance.md) + [list\$1commands](agent-list.md) + [run\$1command](agent-run.md) + [show\$1log](agent-show.md) + [stack\$1state](agent-stack.md) **activity** (選用) 做為某些命令的引數時可指定特定 OpsWorks Stacks 活動：`setup`、`configure`、`deploy`、`undeploy`、`start`、`stop` 或 `restart`。 **date** (選用) 做為某些命令的引數時可指定特定 OpsWorks Stacks 命令執行。透過將 **date** 設為執行命令的時間戳記，並使用 *yyyy-mm-ddThh:mm:ss* 格式 (包括單引號)，即可指定命令執行。例如，對於 2013 年 2 月 5 日星期二 10:31:55，請使用：`'2013-02-05T10:31:55'`。若要判斷何時執行特定 OpsWorks Stacks 命令，請執行 [list\$1commands](agent-list.md)。 **注意** 如果代理程式多次執行相同的 OpsWorks Stacks 活動，您可以透過指定活動及其執行時間來挑選特定的執行。如果您指定活動並省略時間，代理程式 CLI 命令會對活動的最近執行採取動作。如果您省略這兩個引數，代理程式 CLI 命令會對最近的活動採取動作。下列各節說明命令及其相關聯的引數。為簡潔起見，語法部分會省略可搭配任何命令使用的選用 `--help` 選項。 **Topics** + [agent\$1report](agent-report.md) + [get\$1json](agent-json.md) + [instance\$1report](agent-instance.md) + [list\$1commands](agent-list.md) + [run\$1command](agent-run.md) + [show\$1log](agent-show.md) + [stack\$1state](agent-stack.md) # agent\$1report **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。傳回代理程式報告。 ``` sudo opsworks-agent-cli agent_report ``` 下列輸出範例來自最近執行設定活動的執行個體。 ``` $ sudo opsworks-agent-cli agent_report AWS OpsWorks Instance Agent State Report: Last activity was a "configure" on 2015-12-01 18:19:23 UTC Agent Status: The AWS OpsWorks agent is running as PID 30998 Agent Version: 4004-20151201152533, up to date ``` # get\$1json **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。傳回 Chef 執行的相關資訊做為 JSON 物件。 ``` sudo opsworks-agent-cli get_json [activity] [date] [-i | --internal | --no-i | --no-internal] ``` 根據預設，`get_json` 會顯示客戶針對最近 Chef 執行所提供的資訊。使用下列選項來指定一組特定的資訊。 **activity** 顯示與最近指定活動相關聯之 Chef 執行的資訊。若要取得有效的活動清單，請執行 [list\$1commands](agent-list.md)。 **date** 顯示與在指定時間戳記執行的活動相關聯之 Chef 執行的資訊。若要取得有效的時間戳記清單，請執行 [list\$1commands](agent-list.md)。 **-i, --internal** 顯示 OpsWorks Stacks 內部用於 Chef 執行的資訊。 **--no-i, --no-internal** 明確顯示客戶針對 Chef 執行所提供的資訊。如果未指定其他選項，這會是預設值。 **注意** 若是 Chef 12 Linux 執行個體，執行此命令將傳回有效的資訊，例如執行個體的堆疊組態和部署屬性。不過，若要取得更完整的資訊，請參閱 OpsWorks Stacks 在執行個體上建立的 Chef 資料包。如需更多資訊，請參閱[OpsWorks Stacks 資料包參考](data-bags.md)。下列輸出範例會顯示客戶針對最近設定活動之 Chef 執行所提供的資訊。 ``` $ sudo opsworks-agent-cli get_json configure { "run_list": [ "recipe[opsworks_cookbook_demo::configure]" ] } ``` 下列輸出範例顯示 OpsWorks Stacks 在內部用於針對指定時間戳記執行之 Chef 執行的資訊。 ``` $ sudo opsworks-agent-cli get_json 2015-12-01T18:20:24 -i { "aws_opsworks_agent": { "version": "4004-20151201152533", "valid_client_activities": [ "reboot", "stop", "deploy", "grant_remote_access", "revoke_remote_access", "update_agent", "setup", "configure", "update_dependencies", "install_dependencies", "update_custom_cookbooks", "execute_recipes", "sync_remote_users" ], "command": { "type": "configure", "args": { "app_ids": [ ] }, "sent_at": "2015-12-01T18:19:23+00:00", "command_id": "5c2113f3-c6d5-40eb-bcfa-77da2885eeEX", "iam_user_arn": null, "instance_id": "cfdaa716-42fe-4e3b-9762-fef184ddd8EX" }, "resources": { "apps": [ ], "layers": [ { "layer_id": "93f50d83-1e73-45c4-840a-0d4f07cda1EX", "name": "MyCookbooksDemoLayer", "packages": [ ], "shortname": "cookbooks-demo", "type": "custom", "volume_configurations": [ ] } ], "instances": [ { "ami_id": "ami-d93622EX", "architecture": "x86_64", "auto_scaling_type": null, "availability_zone": "us-west-2a", "created_at": "2015-11-18T00:21:05+00:00", "ebs_optimized": false, "ec2_instance_id": "i-a480e960", "elastic_ip": null, "hostname": "cookbooks-demo1", "instance_id": "cfdaa716-42fe-4e3b-9762-fef184ddd8EX", "instance_type": "c3.large", "layer_ids": [ "93f50d83-1e73-45c4-840a-0d4f07cda1EX" ], "os": "Amazon Linux 2015.09", "private_dns": "ip-192-0-2-0.us-west-2.compute.internal", "private_ip": "10.122.69.33", "public_dns": "ec2-203-0-113-0.us-west-2.compute.amazonaws.com", "public_ip": "192.0.2.0", "root_device_type": "ebs", "root_device_volume_id": "vol-f6f7e8EX", "ssh_host_dsa_key_fingerprint": "f2:...:15", "ssh_host_dsa_key_public": "ssh-dss AAAAB3Nz...a8vMbqA=", "ssh_host_rsa_key_fingerprint": "0a:...:96", "ssh_host_rsa_key_public": "ssh-rsa AAAAB3Nz...yhPanvo7", "status": "online", "subnet_id": null, "virtualization_type": "paravirtual", "infrastructure_class": "ec2", "ssh_host_dsa_key_private": "-----BEGIN DSA PRIVATE KEY-----\nMIIDVwIB...g5OtgQ==\n-----END DSA PRIVATE KEY-----\n", "ssh_host_rsa_key_private": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIB...78kprtIw\n-----END RSA PRIVATE KEY-----\n" } ], "users": [ ], "elastic_load_balancers": [ ], "rds_db_instances": [ ], "stack": { "arn": "arn:aws:opsworks:us-west-2:80398EXAMPLE:stack/040c3def-b2b4-4489-bb1b-e08425886fEX/", "custom_cookbooks_source": { "type": "s3", "url": "https://s3.amazonaws.com/amzn-s3-demo-bucket/opsworks-cookbook-demo.tar.gz", "username": "AKIAJUQN...WG644EXA", "password": "O5v+4Zz+...rcKbFTJu", "ssh_key": null, "revision": null }, "name": "MyCookbooksDemoStack", "region": "us-west-2", "stack_id": "040c3def-b2b4-4489-bb1b-e08425886fEX", "use_custom_cookbooks": true, "vpc_id": null }, "ecs_clusters": [ ], "volumes": [ ] }, "chef": { "customer_recipes": [ "opsworks_cookbook_demo::configure" ], "customer_json": "e30=\n", "customer_data_bags": "e30=\n" } } } ``` # instance\$1report **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。傳回延伸的執行個體報告。 ``` sudo opsworks-agent-cli instance_report ``` 下列輸出範例來自執行個體。 ``` $ sudo opsworks-agent-cli instance_report AWS OpsWorks Instance Agent State Report: Last activity was a "configure" on 2015-12-01 18:19:23 UTC Agent Status: The AWS OpsWorks agent is running as PID 30998 Agent Version: 4004-20151201152533, up to date OpsWorks Stack: MyCookbooksDemoStack OpsWorks Layers: MyCookbooksDemoLayer OpsWorks Instance: cookbooks-demo1 EC2 Instance ID: i-a480e9EX EC2 Instance Type: c3.large Architecture: x86_64 Total Memory: 3.84 Gb CPU: 2x Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz Location: EC2 Region: us-west-2 EC2 Availability Zone: us-west-2a Networking: Public IP: 192.0.2.0 Private IP: 198.51.100.0 ``` # list\$1commands **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。列出已在此執行個體上執行之每個活動的時間。您可以在其他代理程式 CLI 命令中使用這些時間來指定特定的執行。 ``` sudo opsworks-agent-cli list_commands [activity] [date] ``` 下列輸出範例來自已執行配置、設定及更新自訂技術指南活動的執行個體。 ``` $ sudo opsworks-agent-cli list_commands 2015-11-24T21:00:28 update_custom_cookbooks 2015-12-01T18:19:09 setup 2015-12-01T18:20:24 configure ``` # run\$1command **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。執行 OpsWorks Stacks 命令，這是包含 Chef 執行清單的 JSON 檔案，其中包含執行 OpsWorks Stacks 活動（設定、設定、部署等）所需的資訊。`run_command` 命令會產生您可以透過執行 [show\$1log](agent-show.md) 檢視的日誌項目。此選項僅用於開發目的，因此 OpsWorks Stacks 不會追蹤變更。 ``` sudo opsworks-agent-cli run_command [activity] [date] [/path/to/valid/json.file] ``` 根據預設， `run_command`會執行最新的 OpsWorks Stacks 命令。使用下列選項來指定特定命令。 **activity** 執行指定的 OpsWorks Stacks 命令：`setup`、`configure`、`deploy`、`undeploy``start`、`stop`、或 `restart`。 **date** 執行已在指定時間戳記執行的 AWS OpsWorks 命令。若要取得有效的時間戳記清單，請執行 [list\$1commands](agent-list.md)。 **file** 執行指定的命令 JSON 檔案。若要取得命令的檔案路徑，請執行 [get\$1json](agent-json.md)。下列輸出範例來自執行個體並執行設定命令。 ``` $ sudo opsworks-agent-cli run_command configure [2015-12-02 16:52:53] INFO [opsworks-agent(21970)]: About to re-run 'configure' from 2015-12-01T18:20:24 ... [2015-12-02 16:53:02] INFO [opsworks-agent(21970)]: Finished Chef run with exitcode 0 ``` # show\$1log **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。傳回命令的日誌檔案。 ``` sudo opsworks-agent-cli show_log [activity] [date] ``` 根據預設，`show_log` 會尾隨最新的日誌檔案。使用下列選項來指定特定命令。 **activity** 顯示指定活動的日誌檔案。 **date** 顯示在指定時間戳記執行之活動的日誌檔案。若要取得有效的時間戳記清單，請執行 [list\$1commands](agent-list.md)。下列輸出範例會顯示最新的日誌。 ``` $ sudo opsworks-agent-cli show_log [2015-12-02T16:52:59+00:00] INFO: Storing updated cookbooks/opsworks_cookbook_demo/opsworks-cookbook-demo.tar.gz in the cache. ... [2015-12-02T16:52:59+00:00] INFO: Report handlers complete ``` # stack\$1state **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。顯示 OpsWorks Stacks 在內部用於最近 Chef 執行的資訊。 ``` opsworks-agent-cli stack_state ``` **注意** 若是 Chef 12 Linux 執行個體，執行此命令將傳回有效的資訊，例如執行個體的堆疊組態和部署屬性。不過，若要取得更完整的資訊，請參閱 OpsWorks Stacks 在執行個體上建立的 Chef 資料包。如需更多資訊，請參閱[OpsWorks Stacks 資料包參考](data-bags.md)。下列輸出範例來自執行個體。 ``` $ sudo opsworks-agent-cli stack_state { "last_command": { "sent_at": "2015-12-01T18:19:23+00:00", "activity": "configure" }, "instance": { "ami_id": "ami-d93622EX", "architecture": "x86_64", "auto_scaling_type": null, "availability_zone": "us-west-2a", "created_at": "2015-11-18T00:21:05+00:00", "ebs_optimized": false, "ec2_instance_id": "i-a480e9EX", "elastic_ip": null, "hostname": "cookbooks-demo1", "instance_id": "cfdaa716-42fe-4e3b-9762-fef184ddd8EX", "instance_type": "c3.large", "layer_ids": [ "93f50d83-1e73-45c4-840a-0d4f07cda1EX" ], "os": "Amazon Linux 2015.09", "private_dns": "ip-192-0-2-0.us-west-2.compute.internal", "private_ip": "10.122.69.33", "public_dns": "ec2-203-0-113-0.us-west-2.compute.amazonaws.com", "public_ip": "192.0.2.0", "root_device_type": "ebs", "root_device_volume_id": "vol-f6f7e8EX", "ssh_host_dsa_key_fingerprint": "f2:...:15", "ssh_host_dsa_key_public": "ssh-dss AAAAB3Nz...a8vMbqA=", "ssh_host_rsa_key_fingerprint": "0a:...:96", "ssh_host_rsa_key_public": "ssh-rsa AAAAB3Nz...yhPanvo7", "status": "online", "subnet_id": null, "virtualization_type": "paravirtual", "infrastructure_class": "ec2", "ssh_host_dsa_key_private": "-----BEGIN DSA PRIVATE KEY-----\nMIIDVwIB...g5OtgQ==\n-----END DSA PRIVATE KEY-----\n", "ssh_host_rsa_key_private": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIB...78kprtIw\n-----END RSA PRIVATE KEY-----\n" }, "layers": [ { "layer_id": "93f50d83-1e73-45c4-840a-0d4f07cda1EX", "name": "MyCookbooksDemoLayer", "packages": [ ], "shortname": "cookbooks-demo", "type": "custom", "volume_configurations": [ ] } ], "applications": null, "stack": { "arn": "arn:aws:opsworks:us-west-2:80398EXAMPLE:stack/040c3def-b2b4-4489-bb1b-e08425886fEX/", "custom_cookbooks_source": { "type": "s3", "url": "https://s3.amazonaws.com/amzn-s3-demo-bucket/opsworks-cookbook-demo.tar.gz", "username": "AKIAJUQN...WG644EXA", "password": "O5v+4Zz+...rcKbFTJu", "ssh_key": null, "revision": null }, "name": "MyCookbooksDemoStack", "region": "us-west-2", "stack_id": "040c3def-b2b4-4489-bb1b-e08425886fEX", "use_custom_cookbooks": true, "vpc_id": null }, "agent": { "valid_activities": [ "reboot", "stop", "deploy", "grant_remote_access", "revoke_remote_access", "update_agent", "setup", "configure", "update_dependencies", "install_dependencies", "update_custom_cookbooks", "execute_recipes", "sync_remote_users" ] } } ``` # OpsWorks Stacks 資料包參考 **重要** 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 概念。資料包為以 JSON 資料存放在執行個體上的全域變數。JSON 資料可從 Chef 進行存取。例如，資料包可以存放全域變數，例如應用程式的來源 URL、執行個體的主機名稱，以及相關聯的堆疊 VPC 識別符。 OpsWorks Stacks 會將其資料包存放在每個堆疊的執行個體上。在 Linux 執行個體上， OpsWorks Stacks 會將資料包存放在 `/var/chef/runs/run-ID/data_bags`目錄中。在 Windows 執行個體上，它會將資料包存放在 `drive:\chef\runs\run-id\data_bags` 目錄中。在這兩種情況下，*run-ID* 都是 Stacks OpsWorks 指派給執行個體上每個 Chef 執行的唯一 ID。這些目錄包含一組資料包 (子目錄)。每個資料包都包含零或多個資料包項目，即包含資料包內容組的 JSON 格式檔案。 **注意** OpsWorks Stacks 不支援加密的資料包。若要以加密形式存放機密資料 (例如密碼或憑證)，建議您將它存放在私有 S3 儲存貯體中。然後，您可以建立自訂配方，定義其使用[適用於 Ruby 的 Amazon 開發套件](https://aws.amazon.com/documentation/sdk-for-ruby/)擷取資料。如需範例，請參閱 [使用適用於 Ruby 的 SDK](cookbooks-101-opsworks-s3.md)。資料包內容可包含下列任何項目： + **字串**內容遵循標準 Ruby 語法，可使用單引號或雙引號，雖然包含特定特殊字元的字串必須使用雙引號。如需詳細資訊，請前往 [Ruby](http://www.ruby-lang.org/en/documentation/) 文件網站。 + **布林值**內容，為 `true` 或 `false` (無引號)。 + **數字**內容，為整數或小數，例如 `4` 或 `2.5` (無引號)。 + **清單**內容，其格式為以中括弧圍起的逗點分隔值 (無引號)，例如 `[ '80', '443' ]` + **JSON 物件**，包含額外的資料包內容，例如 `"my-app": {"elastic_ip": null,...}`。 Chef 配方可透過 Chef 搜尋或直接存取資料包、資料包項目，以及資料包內容。下列內容說明如何使用兩種存取方式 (雖然 Chef 搜尋為偏好選項)。若要透過 Chef 搜尋存取資料包，請使用[搜尋](https://docs.chef.io/dsl_recipe.html#search)方法，指定所需的搜尋索引。 OpsWorks Stacks 提供下列搜尋索引： + [aws\$1opsworks\$1app](data-bag-json-app.md)，代表堆疊的一組部署應用程式。 + [aws\$1opsworks\$1command](data-bag-json-command.md)，代表在堆疊上執行的一組命令。 + [aws\$1opsworks\$1ecs\$1cluster](data-bag-json-ecs-cluster.md)，代表堆疊的一組 Amazon Elastic Container Service (Amazon ECS) 叢集執行個體。 + [aws\$1opsworks\$1elastic\$1load\$1balancer](data-bag-json-elb.md)，代表堆疊的一組 Elastic Load Balancing 負載平衡器。 + [aws\$1opsworks\$1instance](data-bag-json-instance.md)，代表堆疊的一組執行個體。 + [aws\$1opsworks\$1layer](data-bag-json-layer.md)，代表堆疊的一組 layer。 + [aws\$1opsworks\$1rds\$1db\$1instance](data-bag-json-rds.md)，代表堆疊的一組 Amazon Relational Database Service (Amazon RDS) 執行個體。 + [aws\$1opsworks\$1stack](data-bag-json-stack.md)，代表堆疊。 + [aws\$1opsworks\$1user](data-bag-json-user.md)，代表堆疊的一組使用者。在您了解搜尋索引名稱之後，您便可以存取該搜尋索引的資料包內容。例如，下列配方程式碼使用 `aws_opsworks_app` 搜尋索引取得 `aws_opsworks_app` 資料包 (`aws_opsworks_app` 目錄) 中第一個資料包項目 (第一個 JSON 檔案) 的內容。然後，程式碼將兩個訊息寫入 Chef 日誌，一個有應用程式短名資料包內容 (JSON 檔案中的字串)，另一個有應用程式來源 URL 資料包內容 (JSON 檔案中的另一個字串)： ``` app = search("aws_opsworks_app").first Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********") Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********") ``` 其中 `['shortname']` 和 `['app_source']['url']` 指定對應 JSON 檔案中的下列資料包內容： ``` { ... "shortname": "mylinuxdemoapp", ... "app_source": { ... "url": "https://s3.amazonaws.com/opsworks-demo-assets/opsworks-linux-demo-nodejs.tar.gz", }, ... } ``` 如需您可以搜尋的資料包內容清單，請參閱本節中的參考主題。您也可以逐一查看資料包中的一組資料包項目。例如，下列配方程式碼 (與先前範例相似) 會在有超過一個資料包項目時，逐一查看資料包中的每個資料包項目。 ``` search("aws_opsworks_app").each do |app| Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********") Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********") end ``` 若您知道特定資料包內容存在，您可以使用下列語法尋找對應的資料包項目： ``` search("search_index", "key:value").first ``` 例如，下列配方程式碼使用 `aws_opsworks_app` 搜尋索引尋找包含應用程式短名 `mylinuxdemoapp` 的資料包項目。程式碼接著會使用資料包項目的內容將對應應用程式短名和來源 URL 寫入 Chef 日誌： ``` app = search("aws_opsworks_app", "shortname:mylinuxdemoapp").first Chef::Log.info("********** For the app with the short name '#{app['shortname']}', the app's URL is '#{app['app_source']['url']}' **********") ``` 僅適用於 `aws_opsworks_instance` 搜尋索引，您可以指定 `self:true` 代表正在執行配方的執行個體。下列配方程式碼使用對應的資料包項目內容，搭配對應的執行個體 Stacks 產生的 ID 和作業系統，將訊息寫入 Chef OpsWorks 日誌： ``` instance = search("aws_opsworks_instance", "self:true").first Chef::Log.info("********** For instance '#{instance['instance_id']}', the instance's operating system is '#{instance['os']}' **********") ``` 除了使用 Chef 搜尋存取資料包、資料包項目和資料包內容之外，您也可以直接存取他們。若要執行此作業，請使用 [data\$1bag](https://docs.chef.io/dsl_recipe.html#data-bag) 和 [data\$1bag\$1item](https://docs.chef.io/dsl_recipe.html#data-bag-item) 方法分別存取資料包和資料包項目。例如，下列配方程式碼會執行與先前範例一模一樣的動作，但是它會直接存取單一資料包項目，並會在超過一個的時候存取多個資料包項目： ``` # Syntax: data_bag_item("the data bag name", "the file name in the data bag without the file extension") app = data_bag_item("aws_opsworks_app", "mylinuxdemoapp") Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********") Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********") data_bag("aws_opsworks_app").each do |data_bag_item| app = data_bag_item("aws_opsworks_app", data_bag_item) Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********") Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********") end ``` 在這兩種方法中，我們建議您使用 Chef 搜尋。所有本指南中的相關範例都會示範此方法。 **Topics** + [應用程式資料包 (aws\$1opsworks\$1app)](data-bag-json-app.md) + [命令資料包 (aws\$1opsworks\$1command)](data-bag-json-command.md) + [Amazon ECS 叢集資料包 (aws\$1opsworks\$1ecs\$1cluster)](data-bag-json-ecs-cluster.md) + [Elastic Load Balancing 資料包 (aws\$1opsworks\$1elastic\$1load\$1balancer)](data-bag-json-elb.md) + [執行個體資料包 (aws\$1opsworks\$1instance)](data-bag-json-instance.md) + [Layer 資料包 (aws\$1opsworks\$1layer)](data-bag-json-layer.md) + [Amazon RDS 資料包 (aws\$1opsworks\$1rds\$1db\$1instance)](data-bag-json-rds.md) + [堆疊資料包 (aws\$1opsworks\$1stack)](data-bag-json-stack.md) + [使用者資料包 (aws\$1opsworks\$1user)](data-bag-json-user.md) # 應用程式資料包 (aws\$1opsworks\$1app) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。針對[部署事件](workingcookbook-events.md)或[執行配方堆疊命令](workingstacks-commands.md)，代表應用程式的設定。下列範例示範如何使用 Chef 搜尋搜尋單一資料包項目及多個資料包項目，將應用程式的短名和來源 URL 寫入 Chef 日誌： ``` app = search("aws_opsworks_app").first Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********") Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********") search("aws_opsworks_app").each do |app| Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********") Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********") end ``` **** | | | | | --- |--- |--- | | [app\$1id](#data-bag-json-app-app-id) | [app\$1source](#data-bag-json-app-app-source) | [data\$1sources](#data-bag-json-app-app-data-source) | | [部署](#data-bag-json-app-deploy) | [屬性](#data-bag-json-app-attributes) | [domains](#data-bag-json-app-app-domains) | | [enable\$1ssl](#data-bag-json-app-enable-ssl) | [環境](#data-bag-json-app-app-environment) | [name](#data-bag-json-app-app-name) | | [shortname](#data-bag-json-app-app-shortname) | [ssl\$1configuration](#data-bag-json-app-app-ssl-config) | [type](#data-bag-json-app-app-type) | **app\$1id** 應用程式 ID (字串)。識別應用程式的 GUID。 **app\$1source** 一組內容，指定 OpsWorks Stacks 用來從其來源控制儲存庫部署應用程式的資訊。內容會根據儲存庫類型而有所不同。 **password** 私有儲存庫為密碼，公有儲存庫則為 `"null"` (字串)。若為私有 S3 儲存貯體，則此內容會設為私有金鑰。 **修訂** 如果儲存庫有多個分支，此內容會指定該應用程式的分支或版本，例如 `"version1"` (字串)。否則會設為 `"null"`。 **ssh\$1key** 用來存取私有 Git 儲存庫的[部署 SSH 金鑰](workingapps-deploykeys.md)，公有儲存庫則為 `"null"` (字串)。 **type** 應用程式的來源位置 (字串)。有效值包含： + `"archive"` + `"git"` + `"other"` + `"s3"` **url** 應用程式來源的位置 (字串)。 **user** 私有儲存庫為使用者名稱，公有儲存庫則為 `"null"` (字串)。若為私有 S3 儲存貯體，此內容會設為存取金鑰。 **屬性** 一組內容，描述目錄結構和應用程式的內容。 **document\$1root** 文件樹狀結構的根目錄。定義指向文件根 (或應用程式首頁位置，例如 `home_html`) 的路徑，相對於您的部署目錄。除非指定此屬性，否則 document\$1root 預設為 `public`。`document_root` 的值開頭只能為 `a-z`、`A-Z`、`0-9`、`_` (底線) 或 `-` (連字號) 字元。 **data\$1sources** 連線到應用程式資料庫所需的資訊。如果應用程式有連接的資料庫層， OpsWorks Stacks 會自動將適當的值指派給此內容。 data\$1sources 的值為一個陣列，陣列必須使用整數位移存取，而非鍵。例如，若要存取應用程式的第一個資料來源，請使用 `app[:data_sources][0][:type]`。 **database\$1name** 資料庫名稱，通常是應用程式的短名 (字串)。 **type** 資料庫執行個體的類型，通常為 `"RdsDbInstance"` (字串)。 **arn** 資料庫執行個體的 Amazon Resource Name (ARN) (字串)。 **部署** 是否應部署應用程式 (布林值)。`true` 表示應用程式應在部署生命週期事件中部署。在安裝生命週期事件中，所有應用程式的此內容將為 `true`。若要判斷哪些應用程式應在執行個體上部署，請檢查執行個體所屬的 layer。 **domains** 應用程式的網域清單 (字串清單)。 **enable\$1ssl** 是否啟用 SSL 支援 (布林值)。 **環境** 使用者針對應用程式指定之環境變數的集合。如需如何定義應用程式環境變數的詳細資訊，請參閱[新增應用程式](workingapps-creating.md)。每個內容名稱都會設為環境變數名稱，並且對應的值都會設為變數的值。 **name** 應用程式的名稱，用於顯示用途 (字串)。 **shortname** 應用程式的簡短名稱，由 Stacks 從名稱（字串） OpsWorks 產生。短名會在內部及由配方使用。短名會做為您應用程式檔案安裝目錄的名稱使用。 **ssl\$1configuration** **certificate** 若您啟用 SSL 支援，則為應用程式的 SSL 憑證，否則為 `"null"` (字串)。 **chain** 若啟用 SSL，則為指定中繼憑證授權單位金鑰或用戶端身分驗證的內容 (字串)。 **private\$1key** 若您啟用 SSL 支援，則為應用程式的 SSL 私有金鑰，否則為 `"null"` (字串)。 **type** 應用程式的類型，若為 Chef 12 Linux 和 Chef 12.2 Windows 堆疊，則總是會設為 `"other"` (字串)。 # 命令資料包 (aws\$1opsworks\$1command) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。代表 Stacks OpsWorks 在一或多個執行個體上執行之命令的設定。下列範例示範如何使用 Chef 搜尋搜尋單一資料包項目及多個資料包項目，將命令的類型和傳送命令的時間寫入 Chef 日誌： ``` command = search("aws_opsworks_command").first Chef::Log.info("********** The command's type is '#{command['type']}' **********") Chef::Log.info("********** The command was sent at '#{command['sent_at']}' **********") search("aws_opsworks_command").each do |command| Chef::Log.info("********** The command's type is '#{command['type']}' **********") Chef::Log.info("********** The command was sent at '#{command['sent_at']}' **********") end ``` **** | | | | | --- |--- |--- | | [args](#data-bag-json-command-args) | [command\$1id](#data-bag-json-command-command-id) | [iam\$1user\$1arn](#data-bag-json-command-iam-user-arn) | | [instance\$1id](#data-bag-json-command-instance-id) | [sent\$1at](#data-bag-json-command-sent-at) | [type](#data-bag-json-command-type) | **args** 命令的引數 (字串)。 **command\$1id** 命令的隨機唯一識別符，由 Stacks OpsWorks （字串）指派。 **iam\$1user\$1arn** 若命令是由客戶建立，則為建立命令之使用者的 Amazon Resource Name (ARN) (字串)。 **instance\$1id** 執行命令之執行個體的識別符 (字串)。 **sent\$1at** Stacks 執行命令（字串） OpsWorks 時的時間戳記。 **type** 命令的類型 (字串)。有效值包含： + `"configure"` + `"deploy"` + `"deregister"` + `"execute_recipes"` + `"grant_remote_access"` + `"install_dependencies"` + `"restart"` + `"revoke_remote_access"` + `"rollback"` + `"setup"` + `"shutdown"` + `"start"` + `"stop"` + `"sync_remote_users"` + `"undeploy"` + `"update_agent"` + `"update_custom_cookbooks"` + `"update_dependencies"` # Amazon ECS 叢集資料包 (aws\$1opsworks\$1ecs\$1cluster) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。代表 Amazon ECS 叢集的設定。下列範例示範如何使用 Chef 搜尋來搜尋單一資料包項目，然後搜尋多個資料包項目，以使用 Amazon ECS 叢集的名稱和 Amazon Resource Name (ARNs) 將訊息寫入 Chef 日誌： ``` ecs_cluster = search("aws_opsworks_ecs_cluster").first Chef::Log.info("********** The ECS cluster's name is '#{ecs_cluster['ecs_cluster_name']}' **********") Chef::Log.info("********** The ECS cluster's ARN is '#{ecs_cluster['ecs_cluster_arn']}' **********") search("aws_opsworks_ecs_cluster").each do |ecs_cluster| Chef::Log.info("********** The ECS cluster's name is '#{ecs_cluster['ecs_cluster_name']}' **********") Chef::Log.info("********** The ECS cluster's ARN is '#{ecs_cluster['ecs_cluster_arn']}' **********") end ``` **** | | | | --- |--- | | [ecs\$1cluster\$1arn](#data-bag-json-ecs-cluster-ecs-cluster-arn) | [ecs\$1cluster\$1name](#data-bag-json-ecs-cluster-ecs-cluster-name) | **ecs\$1cluster\$1arn** 叢集的 Amazon Resource Name (ARN) (字串)。 **ecs\$1cluster\$1name** 叢集的名稱 (字串)。 # Elastic Load Balancing 資料包 (aws\$1opsworks\$1elastic\$1load\$1balancer) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。代表 Elastic Load Balancing 負載平衡器的設定。下列範例示範如何使用 Chef 搜尋來搜尋單一資料包項目，然後使用 Elastic Load Balancing 負載平衡器的名稱和 DNS 名稱將訊息寫入 Chef 日誌： ``` elastic_load_balancer = search("aws_opsworks_elastic_load_balancer").first Chef::Log.info("********** The ELB's name is '#{elastic_load_balancer['elastic_load_balancer_name']}' **********") Chef::Log.info("********** The ELB's DNS name is '#{elastic_load_balancer['dns_name']}' **********") search("aws_opsworks_elastic_load_balancer").each do |elastic_load_balancer| Chef::Log.info("********** The ELB's name is '#{elastic_load_balancer['elastic_load_balancer_name']}' **********") Chef::Log.info("********** The ELB's DNS name is '#{elastic_load_balancer['dns_name']}' **********") end ``` **** | | | | | --- |--- |--- | | [elastic\$1load\$1balancer\$1name](#data-bag-json-elb-elastic-load-balancer-name) | [dns\$1name](#data-bag-json-elb-dns-name) | [layer\$1id](#data-bag-json-elb-layer-id) | **elastic\$1load\$1balancer\$1name** 負載平衡器的名稱 (字串)。 **dns\$1name** 負載平衡器的 DNS 名稱 (字串)。 **layer\$1id** 負載平衡器指派給的 layer 的 OpsWorks Stacks ID （字串）。 # 執行個體資料包 (aws\$1opsworks\$1instance) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。代表執行個體的設定。下列範例示範如何使用 Chef 搜尋搜尋單一資料包項目及多個資料包項目，將執行個體的主機名稱和 ID 寫入 Chef 日誌： ``` instance = search("aws_opsworks_instance").first Chef::Log.info("********** The instance's hostname is '#{instance['hostname']}' **********") Chef::Log.info("********** The instance's ID is '#{instance['instance_id']}' **********") search("aws_opsworks_instance").each do |instance| Chef::Log.info("********** The instance's hostname is '#{instance['hostname']}' **********") Chef::Log.info("********** The instance's ID is '#{instance['instance_id']}' **********") end ``` 下列範例顯示使用 Chef 搜尋來搜尋多個資料包項目的不同方式，以尋找包含指定 Amazon EC2 執行個體 ID 的資料包項目。範例接著會使用資料包項目的內容將對應執行個體的公有 IP 地址寫入 Chef 日誌： ``` instance = search("aws_opsworks_instance", "ec2_instance_id:i-12345678").first Chef::Log.info("********** For instance '#{instance['ec2_instance_id']}', the instance's public IP address is '#{instance['public_ip']}' **********") search("aws_opsworks_instance").each do |instance| if instance['ec2_instance_id'] == 'i-12345678' Chef::Log.info("********** For instance '#{instance['ec2_instance_id']}', the instance's public IP address is '#{instance['public_ip']}' **********") end end ``` 以下範例示範如何使用 Chef 搜尋以 `self:true` 尋找包含與執行配方之執行個體相關資訊的資料包項目。此範例接著會使用資料包項目的內容，以對應執行個體的 OpsWorks Stacks 產生的 ID 和執行個體的公有 IP 地址，將訊息寫入 Chef 日誌： ``` instance = search("aws_opsworks_instance", "self:true").first Chef::Log.info("********** For instance '#{instance['instance_id']}', the instance's public IP address is '#{instance['public_ip']}' **********") ``` **** | | | | | --- |--- |--- | | [ami\$1id](#data-bag-json-instance-ami) | [架構](#data-bag-json-instance-arch) | [auto\$1scaling\$1type](#data-bag-json-instance-autoscaling) | | [availability\$1zone](#data-bag-json-instance-az) | [created\$1at](#data-bag-json-instance-created-at) | [ebs\$1optimized](#data-bag-json-instance-ebs-optimized) | | [ec2\$1instance\$1id](#data-bag-json-instance-ec2-id) | [elastic\$1ip](#data-bag-json-instance-elastic-ip) | [hostname](#data-bag-json-instance-hostname) | | [instance\$1id](#data-bag-json-instance-id) | [instance\$1type](#data-bag-json-instance-type) | [layer\$1ids](#data-bag-json-instance-layers) | | [os](#data-bag-json-instance-os) | [private\$1dns](#data-bag-json-instance-private-dns) | [private\$1ip](#data-bag-json-instance-private-ip) | | [public\$1dns](#data-bag-json-instance-public-dns) | [public\$1ip](#data-bag-json-instance-public-ip) | [root\$1device\$1type](#data-bag-json-instance-root-device-type) | | [root\$1device\$1volume\$1id](#data-bag-json-instance-root-device-volume-id) | [self](#data-bag-json-instance-self) | [ssh\$1host\$1dsa\$1key\$1fingerprint](#data-bag-json-instance-ssh-host-dsa-key-fingerprint) | | [ssh\$1host\$1dsa\$1key\$1private](#data-bag-json-instance-ssh-host-dsa-key-private) | [ssh\$1host\$1dsa\$1key\$1public](#data-bag-json-instance-ssh-host-dsa-key-public) | [ssh\$1host\$1rsa\$1key\$1fingerprint](#data-bag-json-instance-ssh-host-rsa-key-fingerprint) | | [ssh\$1host\$1rsa\$1key\$1private](#data-bag-json-instance-ssh-host-rsa-key-private) | [ssh\$1host\$1rsa\$1key\$1public](#data-bag-json-instance-ssh-host-rsa-key-public) | [status](#data-bag-json-instance-status) | | [subnet\$1id](#data-bag-json-instance-subnet-id) | [virtualization\$1type](#data-bag-json-instance-virt-type) | | **ami\$1id** 執行個體的 AMI (Amazon Machine Image) ID (字串)。 **架構** 執行個體的架構，一律設為 `"x86_64"` (字串)。 **auto\$1scaling\$1type** 執行個體的擴展類型：`null`、`timer` 或 `load` (字串)。 **availability\$1zone** 執行個體的可用區域 (AZ)，例如 `"us-west-2a"` (字串)。 **created\$1at** 執行個體的建立時間，使用 UTC `"yyyy-mm-dddThh:mm:ss+hh:mm"` 格式 (字串)。例如，`"2013-10-01T08:35:22+00:00"` 對應到 2013 年 10 月 10 日 8:35:22，無時區位移。如需詳細資訊，請參閱 [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601)。 **ebs\$1optimized** 執行個體是否為 EBS 最佳化 (布林值)。 **ec2\$1instance\$1id** EC2 執行個體 ID (字串)。 **elastic\$1ip** 彈性 IP 地址，若執行個體沒有彈性 IP 地址，則設為 `"null"` (字串)。 **hostname** 主機名稱，例如 `"demo1"` (字串)。 **instance\$1id** 執行個體 ID，這是 OpsWorks Stacks 產生的 GUID，可唯一識別執行個體（字串）。 **instance\$1type** 執行個體類型，例如 `"c1.medium"` (字串)。 **layer\$1ids** 執行個體 layer 的清單，以其唯一 ID 識別。例如：`307ut64c-c7e4-40cc-52f0-67d5k1f9992c`。 **os** 執行個體的作業系統 (字串)。有效值包含： + `"Amazon Linux 2"` + `"Amazon Linux 2018.03"` + `"Amazon Linux 2017.09"` + `"Amazon Linux 2017.03"` + `"Amazon Linux 2016.09"` + `"Custom"` + `"Microsoft Windows Server 2022 Base"` + `"Microsoft Windows Server 2022 with SQL Server Express"` + `"Microsoft Windows Server 2022 with SQL Server Standard"` + `"Microsoft Windows Server 2022 with SQL Server Web"` + `"Microsoft Windows Server 2019 Base"` + `"Microsoft Windows Server 2019 with SQL Server Express"` + `"Microsoft Windows Server 2019 with SQL Server Standard"` + `"Microsoft Windows Server 2019 with SQL Server Web"` + `"CentOS 7"` + `"Red Hat Enterprise Linux 7"` + `"Ubuntu 20.04 LTS"` + `"Ubuntu 18.04 LTS"` + `"Ubuntu 16.04 LTS"` + `"Ubuntu 14.04 LTS"` **private\$1dns** 私有 DNS 名稱 (字串)。 **private\$1ip** 私有 IP 地址 (字串)。 **public\$1dns** 公有 DNS 名稱 (字串)。 **public\$1ip** 公有 IP 地址 (字串)。 **root\$1device\$1type** 根設備類型 (字串)。有效值包含： + `"ebs` + `"instance-store"` **root\$1device\$1volume\$1id** 根設備的磁碟區 ID (字串)。 **self** 若此資料包項目包含執行配方之執行個體的相關資訊，則為 `true`。否則為 `false` (布林值)。此值僅適用於配方，而不是透過 OpsWorks Stacks API。 **ssh\$1host\$1dsa\$1key\$1fingerprint** 位元組的短序列，用來識別較長的 DSA 公有金鑰 (字串)。 **ssh\$1host\$1dsa\$1key\$1private** 由 DSA 為執行個體 SSH 身分驗證產生的私有金鑰 (字串)。 **ssh\$1host\$1dsa\$1key\$1public** 由 DSA 為執行個體 SSH 身分驗證產生的公有金鑰 (字串)。 **ssh\$1host\$1rsa\$1key\$1fingerprint** 位元組的短序列，用來識別較長的 RSA 公有金鑰 (字串)。 **ssh\$1host\$1rsa\$1key\$1private** 由 RSA 為執行個體 SSH 身分驗證產生的私有金鑰 (字串)。 **ssh\$1host\$1rsa\$1key\$1public** 由 RSA 為執行個體 SSH 身分驗證產生的公有金鑰 (字串)。 **status** 執行個體的狀態 (字串)。有效值包含： + `"requested"` + `"booting"` + `"running_setup"` + `"online"` + `"setup_failed"` + `"start_failed"` + `"terminating"` + `"terminated"` + `"stopped"` + `"connection_lost"` **subnet\$1id** 執行個體的子網路 ID (字串)。 **virtualization\$1type** 執行個體的虛擬化類型 (字串)。 # Layer 資料包 (aws\$1opsworks\$1layer) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。代表 layer 的設定。下列範例示範如何使用 Chef 搜尋搜尋單一資料包項目及多個資料包項目，將 layer 的名稱和短名寫入 Chef 日誌： ``` layer = search("aws_opsworks_layer").first Chef::Log.info("********** The layer's name is '#{layer['name']}' **********") Chef::Log.info("********** The layer's shortname is '#{layer['shortname']}' **********") search("aws_opsworks_layer").each do |layer| Chef::Log.info("********** The layer's name is '#{layer['name']}' **********") Chef::Log.info("********** The layer's shortname is '#{layer['shortname']}' **********") end ``` **** | | | | | --- |--- |--- | | [ecs\$1cluster\$1arn](#data-bag-json-ecs-cluster-arn) | [layer\$1id](#data-bag-json-layer-id) | [name](#data-bag-json-layer-name) | | [packages](#data-bag-json-layer-packages) | [shortname](#data-bag-json-layer-shortname) | [type](#data-bag-json-layer-type) | | [volume\$1configurations](#data-bag-json-layer-volume-config) | | | **ecs\$1cluster\$1arn** 如果 layer 已指派 Amazon ECS 叢集，Amazon ECS 叢集的 Amazon Resource Name (ARN) （字串）。 **encrypted** 若 EBS 磁碟區已加密，則為 `true`。否則為 `false` (布林值)。 **layer\$1id** layer ID，這是 Stacks OpsWorks 產生的 GUID，可唯一識別 layer （字串）。 **name** layer 的名稱，用以在主控台中表示 layer (字串)。名稱可以是使用者定義的，且不一定要是唯一的。 **packages** 要安裝的套件清單 (字串清單)。 **shortname** layer 的短名，由使用者定義 (字串)。 **type** layer 的類型，若為 Chef 12 Linux 和 Chef 12.2 Windows 堆疊，一律會設為 `"custom"` (字串)。 **volume\$1configurations** Amazon EBS 磁碟區組態的清單。 **iops** 磁碟區可支援的每秒 I/O 操作數。 **mount\$1point** 磁碟區的掛載點目錄。 **number\$1of\$1disks** 磁碟區中的磁碟數。 **raid\$1level** 磁碟區的 RAID 組態層級。 **size** 磁碟區的大小 (GiB)。 **volume\$1type** 磁碟區的類型：一般用途、磁性、佈建 IOPS、輸送量最佳化 HDD，或冷 HDD。 # Amazon RDS 資料包 (aws\$1opsworks\$1rds\$1db\$1instance) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。一組資料包內容，指定 Amazon Relational Database Service (Amazon RDS) 執行個體的組態，如下所示： **** | | | | | --- |--- |--- | | [address](#data-bag-json-rds-address) | [db\$1instance\$1identifier](#data-bag-json-rds-id) | [db\$1password](#data-bag-json-rds-password) | | [db\$1user](#data-bag-json-rds-user) | [engine](#data-bag-json-rds-engine) | [rds\$1db\$1instance\$1arn](#data-bag-json-rds-arn) | | [region](#data-bag-json-rds-region) | | | 下列範例示範如何使用 Chef 搜尋來搜尋單一資料包項目，然後搜尋多個資料包項目，以使用 Amazon RDS 執行個體的地址和資料庫引擎類型將訊息寫入 Chef 日誌： ``` rds_db_instance = search("aws_opsworks_rds_db_instance").first Chef::Log.info("********** The RDS instance's address is '#{rds_db_instance['address']}' **********") Chef::Log.info("********** The RDS instance's database engine type is '#{rds_db_instance['engine']}' **********") search("aws_opsworks_rds_db_instance").each do |rds_db_instance| Chef::Log.info("********** The RDS instance's address is '#{rds_db_instance['address']}' **********") Chef::Log.info("********** The RDS instance's database engine type is '#{rds_db_instance['engine']}' **********") end ``` **address** 執行個體的 DNS 名稱。 **port** 執行個體的連接埠。 **db\$1instance\$1identifier** 執行個體的 ID。 **db\$1password** 執行個體的主要密碼。 **db\$1user** 執行個體的主要使用者名稱。 **engine** 執行個體的資料庫引擎，例如 `mysql` (字串)。 **rds\$1db\$1instance\$1arn** 執行個體的 Amazon Resource Name (ARN)。 **region** 執行個體的 AWS 區域，例如 `us-west-2` (字串)。 # 堆疊資料包 (aws\$1opsworks\$1stack) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。代表堆疊的設定。下列範例示範如何使用 Chef 搜尋將堆疊的名稱和技術指南的來源 URL 寫入 Chef 日誌： ``` stack = search("aws_opsworks_stack").first Chef::Log.info("********** The stack's name is '#{stack['name']}' **********") Chef::Log.info("********** The stack's cookbook URL is '#{stack['custom_cookbooks_source']['url']}' **********") ``` **** | | | | | --- |--- |--- | | [arn](#data-bag-json-stack-arn) | [custom\$1cookbooks\$1source](#data-bag-json-stack-cookbook-source) | [name](#data-bag-json-stack-name) | | [region](#data-bag-json-stack-region) | [stack\$1id](#data-bag-json-stack-id) | [use\$1custom\$1cookbooks](#data-bag-json-stack-use-cookbooks) | | [vpc\$1id](#data-bag-json-stack-vpc-id) | | | **arn** 堆疊的 Amazon Resource Name (ARN) (字串)。 **custom\$1cookbooks\$1source** 一組內容，指定自訂技術指南的來源儲存庫。 **type** 儲存庫類型 (字串)。有效值包含： + `"archive"` + `"git"` + `"s3"` **url** 儲存庫 URL，例如 `"git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git"` (字串)。 **使用者名稱** 私有儲存庫為使用者名稱，公有儲存庫則為 `null` (字串)。對於私有 Amazon Simple Storage Service (Amazon S3) 儲存貯體，內容會設定為存取金鑰。 **password** 私有儲存庫為密碼，公有儲存庫則為 `null` (字串)。若為私有 S3 儲存貯體，則此內容會設為私有金鑰。 **ssh\$1key** 用來存取私有 Git 儲存庫的[部署 SSH 金鑰](workingapps-deploykeys.md)，公有儲存庫則為 `null` (字串)。 **修訂** 如果儲存庫有多個分支，此內容會指定該應用程式的分支或版本，例如 `"version1"` (字串)。否則會設為 `null`。 **name** 堆疊名稱 (字串)。 **region** 堆疊的 AWS 區域名稱 (字串)。 **stack\$1id** 識別堆疊的 GUID (字串)。 **use\$1custom\$1cookbooks** 是否啟用自訂技術指南 (布林值)。 **vpc\$1id** 若堆疊正在 VPC 中執行，則為 VPC ID (若堆疊正在 VPC 中執行) (字串)。 # 使用者資料包 (aws\$1opsworks\$1user) **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。代表使用者的設定。下列範例示範如何使用 Chef 搜尋搜尋單一資料包項目及多個資料包項目，將使用者的使用者名稱和 Amazon Resource Name (ARN) 寫入 Chef 日誌： ``` user = search("aws_opsworks_user").first Chef::Log.info("********** The user's user name is '#{user['username']}' **********") Chef::Log.info("********** The user's user ARN is '#{user['iam_user_arn']}' **********") # Or... search("aws_opsworks_user").each do |user| Chef::Log.info("********** The user's user name is '#{user['username']}' **********") Chef::Log.info("********** The user's user ARN is '#{user['iam_user_arn']}' **********") end ``` **** | | | | | --- |--- |--- | | [administrator\$1privileges](#data-bag-json-user-admin) | [iam\$1user\$1arn](#data-bag-json-user-arn) | [remote\$1access](#data-bag-json-user-rdp) | | [ssh\$1public\$1key](#data-bag-json-user-ssh-public-key) | [unix\$1user\$1id](#data-bag-json-user-unix-id) | [使用者名稱](#data-bag-json-user-username) | **administrator\$1privileges** 使用者是否具備管理員權限 (布林值)。 **iam\$1user\$1arn** 使用者的 Amazon Resource Name (ARN) (字串)。 **remote\$1access** 使用者是否可以使用 RDP 登入執行個體 (布林值)。 **ssh\$1public\$1key** 使用者的公有金鑰，如透過 Stacks OpsWorks 主控台或 API （字串）所提供。 **unix\$1user\$1id** 使用者的 Unix ID (號碼)。 **使用者名稱** 使用者名稱 (字串)。 # OpsWorks 代理程式變更 **重要** AWS OpsWorks Stacks 此服務已於 2024 年 5 月 26 日終止，並已針對新客戶和現有客戶停用。我們強烈建議客戶盡快將其工作負載遷移至其他解決方案。如果您對遷移有任何疑問，請透過 [AWS re：Post](https://repost.aws/) 或透過 [AWS Premium Support](https://aws.amazon.com/support) 聯絡 AWS 支援團隊。 ## Chef 12 代理版本下表說明 AWS OpsWorks Stacks 在其管理的執行個體上安裝之 Chef 12 代理程式的重要變更。 | 代理程式版本 | Description | 版本日期 | | --- | --- | --- | | 4042 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2023 年 2 月 7 日 | | 4041 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2023 年 1 月 27 日 | | 4040 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2022 年 7 月 22 日 | | 4039 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2020 年 4 月 30 日 | | 4038 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2020 年 3 月 5 日 | | 4037 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2019 年 6 月 4 日 | | 4035 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2019 年 5 月 8 日 | | 4033 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 11 月 26 日 | | 4032 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 10 月 24 日 | | 4031 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 8 月 15 日 | | 4030 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 5 月 31 日 | | 4029 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 5 月 2 日 | | 4028 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 3 月 20 日 | | 4027 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 2 月 17 日 | | 4026 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 1 月 31 日 | | 4025 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2017 年 12 月 13 日 | | 4024 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2017 年 12 月 5 日 | | 4023 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2017 年 4 月 2 日 | | 4022 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2017 年 2 月 1 日 | | 4021 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 12 月 16 日 | | 4020 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 12 月 8 日 | | 4019 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 10 月 19 日 | | 4018 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 8 月 25 日 | | 4017 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 8 月 10 日 | | 4016 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 6 月 23 日 | | 4015 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 6 月 17 日 | | 4011 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 5 月 19 日 | | 4008 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 3 月 16 日 | | 4007 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 3 月 4 日 | | 4006 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 1 月 21 日 | | 4005 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 12 月 17 日 | | 4004 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 12 月 3 日 | ## Chef 11.10 代理版本下表說明 AWS OpsWorks Stacks 在其管理的執行個體上安裝之 Chef 11.10 代理程式的重要變更。 | 代理程式版本 | Description | 版本日期 | | --- | --- | --- | | 3456 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2023 年 1 月 27 日 | | 3455 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2022 年 11 月 1 日 | | 3454 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2020 年 4 月 28 日 | | 3453 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2020 年 3 月 5 日 | | 3452 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2019 年 8 月 13 日 | | 3451 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2019 年 3 月 20 日 | | 3450 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 12 月 3 日 | | 3449 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 6 月 5 日 | | 3448 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 5 月 8 日 | | 3447 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2018 年 1 月 31 日 | | 3446 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2017 年 12 月 14 日 | | 3445 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2017 年 10 月 31 日 | | 3444 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2017 年 4 月 1 日 | | 3443 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 12 月 15 日 | | 3442 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 6 月 12 日 | | 3441 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 10 月 21 日 | | 3440 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 9 月 13 日 | | 3439 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 7 月 29 日 | | 3438 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 6 月 17 日 | | 3437 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 5 月 4 日 | | 3436 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 4 月 18 日 | | 3435 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 4 月 6 日 | | 3434 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 3 月 16 日 | | 3433 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 2 月 27 日 | | 3432 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 1 月 20 日 | | 3431 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 12 月 22 日 | | 3430 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 11 月 25 日 | | 3429 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 18 月 11 日 | | 3428 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2016 年 6 月 17 日 | | 3427 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 9 月 11 日 | | 3426 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 8 月 27 日 | | 3425 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 7 月 27 日 | | 3424 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 7 月 9 日 | | 3422 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 6 月 29 日 | | 3421 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/opsworks/latest/userguide/agentchanges.html) | 2015 年 6 月 11 日 |