使用工作階段指令碼管理 AppStream 2.0 使用者的串流體驗 - Amazon AppStream 2.0
串流工作階段開始之前執行指令碼在串流工作階段結束之後執行指令碼建立和指定工作階段指令碼工作階段指令碼組態檔案使用視窗 PowerShell 檔案記錄工作階段指令碼輸出使用儲存連接器搭配工作階段指令碼為工作階段指令碼日誌啟用 Amazon S3 儲存貯體儲存在多工作階段叢集上使用工作階段指令

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

使用工作階段指令碼管理 AppStream 2.0 使用者的串流體驗

AppStream 2.0 提供實例會話腳本。當使用者的串流工作階段發生特定事件時，您可以使用這些指令碼來執行您自己的自訂指令碼。例如，您可以使用自訂指令碼，在使用者的串流工作階段開始之前準備 AppStream 2.0 環境。在使用者完成其串流工作階段之後，您也可以使用自訂指令碼來清除串流執行個體。

會話腳本在 AppStream 2.0 映像中指定。這些指令碼在使用者環境或系統環境之內執行。如果您的工作階段指令碼使用標準輪出來撰寫資訊、錯誤或偵錯訊息，這些都可以選擇性地儲存在您 Amazon Web Services 帳戶內的 Amazon S3 儲存貯體中。

串流工作階段開始之前執行指令碼

您可以設定指令碼來執行最長 60 秒，之後，使用者的應用程式才啟動，他們的串流工作階段才開始。這樣做可讓您在使用者開始串流應用程式之前自訂 AppStream 2.0 環境。當工作階段指令碼執行時，使用者會看到載入環。當您的指令碼成功完成或超過最長等待時間後，使用者的串流工作階段就會開始。如果您的指令碼未成功完成，則會顯示錯誤訊息給使用者。但是，不會阻止您的使用者使用其串流工作階段。

當您在 Windows 執行個體上指定檔案名稱時，您必須使用雙反斜線。例如：

C:\\Scripts\\Myscript.bat

如果未使用雙反斜線，便會顯示錯誤來通知您 .json 檔案的格式不正確。

注意

當您的指令碼成功完成時，必須傳回 0 這個值。如果您的指令碼傳回 0 以外的值， AppStream 2.0 會向使用者顯示錯誤訊息。

當您在串流工作階段開始之前執行指令碼且未啟用 AppStream 2.0 動態應用程式架構時，會發生下列程序：

AppStream 2.0 workflow diagram showing connection, application selection, and session launch steps.

  1. 您的使用者連線到未加入網域的 AppStream 2.0 叢集執行個體。他們使用以下其中一個方法連接：

    • AppStream 2.0 個使用者集區

    • SAML 2.0

    • AppStream 2.0 API 介面

  2. 應用程式目錄會顯示在 AppStream 2.0 入口網站中，而您的使用者則選擇要啟動的應用程式。

  3. 發生以下其中一項：

    • 如果已針對使用者啟用應用程式設定持續性，則會下載並掛載應用程式設定虛擬硬碟 (VHD) 檔案，其中存放使用者的自訂項目和 Windows 設定。在這種情況下，需要 Windows 使用者登入。

      如需應用程式設定持續性的相關資訊，請參閱為您的 AppStream 2.0 使用者啟用應用程式設定持續性。

    • 如果應用程式設定持續性未啟用，但 Windows 使用者已登入。

  4. 您的工作階段指令碼會開始。如果已針對使用者啟用持久性儲存，則儲存連接器掛載也會開始。如需持久性儲存的相關資訊，請參閱為您的 AppStream 2.0 使用者啟用和管理持續性儲存。

    注意

    儲存連接器掛載並不需要完成，串流工作階段也會開始。如果工作階段指令碼比儲存連接器掛載更早完成，串流工作階段會開始。

    如需有關監控儲存連接器掛載狀態的資訊，請參閱使用儲存連接器搭配工作階段指令碼。

  5. 您的工作階段指令碼完成或逾時。

  6. 使用者的串流工作階段會開始。

  7. 使用者選擇的應用程式會啟動。

如需 AppStream 2.0 動態應用程式架構的相關資訊，請參閱使用 AppStream 2.0 動態應用程式架構建置動態應用程式提供者。

當您在串流工作階段開始並啟用 AppStream 2.0 動態應用程式架構之前執行指令碼時，會發生下列程序：

AppStream 2.0 workflow from user login to application launch, including SAML authentication and session scripts.

  1. 您的使用者造訪組織適用的 SAML 2.0 應用程式入口網站，並選擇 AppStream 2.0 堆疊。

  2. 它們會連線到已加入網域的 AppStream 2.0 叢集執行個體。

  3. 如果已針對使用者啟用應用程式設定持續性，則會下載並掛載應用程式設定 VHD 檔案，其中存放使用者的自訂項目和 Windows 設定。

  4. 發生 Windows 使用者登入。

  5. 應用程式目錄會顯示在 AppStream 2.0 入口網站中，而您的使用者則選擇要啟動的應用程式。

  6. 您的工作階段指令碼會開始。如果已針對使用者啟用持久性儲存，則儲存連接器掛載也會開始。

    注意

    儲存連接器掛載並不需要完成，串流工作階段也會開始。如果工作階段指令碼比儲存連接器掛載更早完成，串流工作階段會開始。

    如需有關監控儲存連接器掛載狀態的資訊，請參閱使用儲存連接器搭配工作階段指令碼。

  7. 您的工作階段指令碼完成或逾時。

  8. 使用者的串流工作階段會開始。

  9. 使用者選擇的應用程式會啟動。

在串流工作階段結束之後執行指令碼

您也可以將您的指令碼設定為在使用者的工作階段結束之後執行。例如，當使用者從 AppStream 2.0 工具列中選取「結束工作階段」，或達到工作階段允許的持續時間上限時，您可以執行指令碼。您也可以使用這些工作階段指令碼，在串流執行個體終止之前清理 AppStream 2.0 環境。例如，您可以使用指令碼來發行檔案鎖定或上傳日誌檔。當您在串流工作階段結束之後執行指令碼時，則處理如下：

Flowchart showing AppStream 2.0 session termination process with scripts and storage actions.

  1. 您使用者的 AppStream 2.0 串流工作階段結束。

  2. 您的工作階段終止指令碼會開始。

  3. 工作階段終止指令碼完成或逾時。

  4. 發生 Windows 使用者登出。

  5. 以下一項或兩項同時發生 (如果適用)：

    • 如果已針對使用者啟用應用程式設定持續性，則會卸載應用程式設定 VHD 檔案 (其中存放使用者的自訂項目和 Windows 設定)，並上傳到您帳戶中的 Amazon S3 儲存貯體。

    • 如果已針對使用者啟用持久性儲存，則儲存連接器會完成最終同步，然後卸載。

  6. 機群執行個體會終止。

建立和指定工作階段指令碼

您可以設定和指定 Always-on、On-demand 和彈性機群的工作階段指令碼。

設定和指定 Always-on 和 On-demand 機群的工作階段指令碼

  1. 請在以下位置開啟 AppStream 2.0 主控台。 https://console.aws.amazon.com/appstream2

  2. 在導覽窗格中，選擇 Images (映像)、Image Builder (映像建置器)。

  3. 選擇處於 Running (執行中) 狀態的映像建置器，然後選擇 Connect (連線)。

  4. 出現提示時，請選擇 Administrator (管理員)。

  5. 導覽至 C:\AppStream\SessionScripts 並開啟 config.json 組態檔案。

    如需工作階段指令碼參數的相關資訊，請參閱工作階段指令碼組態檔案。

  6. 完成變更之後，儲存並關閉 config.json 檔案。

  7. 在映像建置器桌面上開啟映像助理。

  8. (選用) 您可以指定要包含在映像中的任何其他應用程式。

  9. 按照映像助理的必要步驟建立映像。

    如果無法驗證工作階段指令碼組態 (例如，如果 .json 檔案格式不正確)，當您選擇 Disconnect and create image (中斷連線並建立映像) 會收到通知。

    注意

    若要為 Linux 型映像建置器尋找工作階段指令碼組態檔案，請瀏覽至 /opt/appstream/SessionScripts/config.json。

設定和指定彈性機群的工作階段指令碼

  1. 建立包含工作階段指令碼和 config.json 檔案的 zip 檔案。指令碼檔案將複製到下列位置。您必須使用這些位置儲存 config.json。

    • 若是 Windows，使用 C:\AppStream\SessionScripts\SessionScript。

    • 若是 Linux，使用 /opt/appstream/SessionScripts/SessionScript。

    注意

    若要執行工作階段指令碼檔案，請確定 .zip 檔案只包含工作階段指令碼和 config.json 檔案，且未包含資料夾。如需詳細資訊，請參閱 工作階段指令碼組態檔案。

  2. 將 zip 檔案上傳至帳戶中的 Amazon S3 儲存貯體。

    注意

    您的 VPC 必須提供 Amazon S3 儲存貯體的存取權。如需詳細資訊，請參閱 使用 Amazon S3 VPC 端端點提供 AppStream 2.0 功能。

    您的 S3 儲存貯體和 AppStream 2.0 叢集必須位於相同的位置 AWS 區域。

    您必須擁有 IAM 許可才能對 Amazon S3 儲存貯體中的工作階段指令碼物件執行 S3:GetObject 動作。若要深入了解如何在 Amazon S3 儲存貯體中存放工作階段指令碼，請參閱 將應用程式圖示、安裝指令碼、工作階段指令碼和 VHD 儲存在 S3 儲存貯體中。

  3. 請在以下位置開啟 AppStream 2.0 主控台。 https://console.aws.amazon.com/appstream2

  4. 在導覽窗格中，選擇 Fleets (機群)。

  5. 選擇您要更新的彈性機群，然後選擇檢視詳細資訊。

  6. 在工作階段指令碼設定索引標籤上，選擇編輯。

  7. 針對 S3 中的工作階段指令碼物件，輸入代表工作階段指令碼物件的 S3 URI，或選擇瀏覽 S3，以導覽至您的 S3 儲存貯體並尋找工作階段指令碼物件。

  8. 完成變更之後，選擇儲存變更。

  9. 此時，工作階段指令碼會提供給所有已啟動的機群執行個體使用。

    注意

    您也可以在建立新的彈性機群時設定工作階段指令碼。

工作階段指令碼組態檔案

若要在 Windows 執行個體中尋找工作階段指令碼組態檔案，請瀏覽至 C:\AppStream\SessionScripts\ 組態 .json。在 Linux 實例上，導航到/選項/appstream//SessionScripts配置。檔案的格式如下所示。

注意

組態檔案為 .json 格式。確認您在此檔案中輸入的任何文字都是有效的 .json 格式。

{
  "SessionStart": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  },
  "SessionTermination": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  }
}

您可以在工作階段指令碼組態檔案中使用以下參數。

SessionStart/SessionTermination

在適當的工作階段事件中根據物件名稱執行的工作階段指令碼。

類型：字串

必要：否

允許的值：SessionStart、SessionTermination

WaitingTime

工作階段指令碼的最長持續時間 (以秒為單位)。

類型：整數

必要：否

限制：最長持續時間為 60 秒。如果工作階段指令碼在此期間內未完成，則會停下。如果需要讓指令碼繼續執行，請以單獨程序的形式來加以啟動。

Executables

要執行的指令碼工作階段的詳細資訊。

類型：字串

必要：是

限制：針對每個工作階段事件可執行的指令碼數量上限為 2 (一個用於使用者環境，另一個用於系統環境)。

Context

用來執行工作階段指令碼的環境。

類型：字串

必要：是

允許的值：user、system

Filename

要執行的工作階段指令碼的完整路徑。如果未指定此參數，則工作階段指令碼不會執行。

類型：字串

必要：否

限制：檔案名稱和完整路徑的最大長度為 1,000 個字元。

允許的值：.bat、.exe、.sh

注意

您也可以使用視窗 PowerShell 檔案。如需詳細資訊，請參閱 使用視窗 PowerShell 檔案。

Arguments (引數)

工作階段指令碼或可執行檔的引數。

類型：字串

必要：否

長度限制：長度上限為 1,000 個字元。

S3 LogEnabled

當此參數的值設為 True 時，您的 Amazon Web Services 帳戶內會建立 S3 儲存貯體，以存放工作階段指令碼所建立的日誌。依預設，此值是設為 True。如需詳細資訊，請參閱本主題稍後的記錄工作階段指令碼輸出一節。

類型：布林值

必要：否

允許的值：True、False

使用視窗 PowerShell 檔案

若要使用 Windows PowerShell 檔案，請在filename參數中指定 PowerShell 檔案的完整路徑：

"filename": 
"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",

然後，在 arguments 參數中指定您的工作階段指令碼：

"arguments": "-File \"C:\\path\\to\\session\\script.ps1\"",

最後，請確認 PowerShell 執行原則允許您的 PowerShell 檔案執行。

記錄工作階段指令碼輸出

在組態檔案中啟用此選項時， AppStream 2.0 會自動擷取寫入標準輸出的工作階段指令碼中的輸出。此輸出會上傳到您帳戶中的 Amazon S3 儲存貯體。您可以檢閱日誌檔以進行故障排除或偵錯。

注意

當工作階段指令碼傳回一個值，或 WaitingTime 中設定值已超過時 (以先到者為準)，就會上傳日誌檔。

使用儲存連接器搭配工作階段指令碼

啟用 AppStream 2.0 儲存區連接器時，它們會在工作階段啟動指令碼執行時開始裝載。如果您的指令碼依賴於掛載的儲存區連接器，您可以等待連接器可用。 AppStream 2.0 會在 Windows 執行個體的 Windows 登錄中維護儲存區連接器的掛載狀態，使用下列機碼：

<provided user name>HKEY _ 本地機器\ 軟件\ Amazon\\ 存儲\\ AppStream <Storage connector>

登錄機碼值如下：

  • 提供的使用者名稱：透過存取模式提供的使用者 ID。每個模式的存取模式和值如下：

    • 使用者集區：使用者的電子郵件地址

    • 串流 URL：UserID

    • SAML：NameID。如果使用者名稱包含斜線 (例如，網域使用者的 SAMAccountName)，則斜線會取代為「-」字元。

  • 儲存連接器：為使用者啟用的持久性儲存選項的連接器。儲存連接器值如下：

    • HomeFolder

    • GoogleDrive

    • OneDrive

每個儲存區連接器登錄機碼都包含 MountStatusDWORD 值。下表列出的可能值MountStatus。

注意

若要檢視這些登錄機碼，您的映像必須安裝 Microsoft .NET Framework 4.7.2 版或更新版本。

值 描述
0

未針對此使用者啟用儲存連接器
1

儲存連接器掛載正在進行中
2

儲存連接器掛載成功
3

儲存連接器掛載失敗
4

儲存連接器掛載已啟用，但尚未掛載

在 Linux 實例中，您可以通過查看文件〜/. 配置/狀態中的應用程序流 _ 文件夾的值來檢查主文件夾的安裝狀態。appstream-home-folder appstream-home-folder-mount

值 描述
True

已成功掛載主資料夾
False 未掛載主資料夾

為工作階段指令碼日誌啟用 Amazon S3 儲存貯體儲存

在工作階段指令碼組態中啟用 Amazon S3 日誌記錄時， AppStream 2.0 會從工作階段指令碼擷取標準輸出。此輸出會定期上傳到您的 Amazon Web Services 帳戶內的 S3 儲存貯體。對於每個 AWS 地區， AppStream 2.0 會在您的帳戶中建立一個專屬於您帳戶和區域的儲存貯體。

您不需要執行任何設定任務來管理這些 S3 儲存貯體。它們由 AppStream 2.0 服務完全管理。存放在每個儲存貯體中的日誌檔在傳輸中會使用 Amazon S3 的 SSL 端點加密，靜態時則使用 Amazon S3 的受管加密金鑰加密。儲存貯體使用特定格式命名，如下所示：

appstream-logs-region-code-account-id-without-hyphens-random-identifier
region-code

這是使用針對工作階段指令碼日誌啟用 Amazon S3 儲存貯體來建立堆疊的 AWS 區域代碼。

account-id-without-hyphens

您的 Amazon Web Services 帳戶識別符。隨機 ID 可確保與該區域中的其他儲存貯體不發生衝突。儲存貯體名稱的第一部分 appstream-logs，不會因為跨帳戶或區域而變更。

例如，如果您在美國西部 (奧勒岡) 區域 (美國西部 -2) 的映像中指定工作階段指令碼，帳戶號碼 123456789012，則 AppStream 2.0 會在該區域的帳戶內建立一個 Amazon S3 儲存貯體，並使用顯示的名稱。只有具備足夠許可的管理員可以刪除這個儲存貯體。

appstream-logs-us-west-2-1234567890123-abcdefg

停用工作階段指令碼不會刪除任何存放在 S3 儲存貯體的日誌檔。若要永久刪除日誌檔，您或其他具有適當許可的管理員必須使用 Amazon S3 主控台或 API 來執行此操作。 AppStream 2.0 新增值區政策，防止意外刪除值區。如需詳細資訊，請參閱 Amazon AppStream 2.0 的 Identity and Access Management 中的 IAM 政策和應用程式設定持續性的 Amazon S3 儲存貯體。

當工作階段指令碼啟用時，將會為每個啟動的串流工作階段建立唯一資料夾。

在您的帳戶中，日誌檔存放在 S3 儲存貯體中的資料夾路徑使用以下結構：

bucket-name/stack-name/fleet-name/access-mode/user-id-SHA-256-hash/session-id/SessionScriptsLogs/session-event
bucket-name

存放工作階段指令碼的 S3 儲存貯體名稱。名稱格式如本節前文所述。

stack-name

工作階段的來源堆疊名稱。

fleet-name

執行工作階段指令碼的機群名稱。

access-mode

使用者的身分識別方法：custom適用federated於 AppStream 2.0 API 或 CLI、SAML 和userpool使用者集區中的使用者。

user-id-SHA-256-hash

使用者特定的資料夾名稱。此名稱是使用從使用者識別符產生的小寫 SHA-256 雜湊十六進位字串建立。

session-id

使用者串流工作階段的識別符。每個使用者串流工作階段都會產生唯一 ID。

session-event

產生工作階段指令碼日誌的事件。事件值為：SessionStart 和 SessionTermination。

以下範例資料夾結構適用於從 test-stack 和 test-fleet 開始的串流工作階段。工作階段使用來自美國西部 (奧勒岡) 區域 (US-西部 -2) test-stack 的 AWS 帳戶 ID 和設定群組的使用者 ID API：testuser@mydomain.com123456789012

appstream-logs-us-west-2-1234567890123-abcdefg/test-stack/test-fleet/custom/a0bcb1da11f480d9b5b3e90f91243143eac04cfccfbdc777e740fab628a1cd13/05yd1391-4805-3da6-f498-76f5x6746016/SessionScriptsLogs/SessionStart/

在此範例資料夾結構中，一個日誌檔用於使用者環境工作階段開始指令碼，另一個日誌檔用於系統環境工作階段開始指令碼 (如果適用)。

在多工作階段叢集上使用工作階段指令

在多重工作階段叢集上使用工作階段指令碼時，還有額外的需求和考量，以確保最佳效能和安全性。

要求

在單一工作階段叢集上，對於指定的執行個體，SessionStart和SessionTermination掛接程式保證只會執行一次。這是因為工作階段與執行個體有 1:1 對應。使用多重工作階段叢集時，會有工作階段與執行個體的 N: M 對應，其中每個工作階段都會執行自己的並掛接。SessionStartSessionTermination這表示SessionStart和SessionTermination掛接程式可以在指定的執行個體上執行多次，並以許多不同的順序執行。為了獲得最佳體驗，在多工作階段叢集上使用時，工作階段指令碼應符合下列條件：

  • 腳本是冪等的。

    當動作已經執行時，指令碼應該在同一個執行個體上以優雅的處理方式處理多個執行。

  • 腳本是獨立的。

    由於指令碼是每個工作階段執行，所以如果某個工作階段在另一個工作階段執行SessionTermination時正在執行 SessionStart，它們不應該互相干擾，也不應干擾其他工作階段的經驗

  • 腳本是高性能的。

    在多重工作階段執行個體上，可同時佈建多個工作階段。這意味著會話腳本可以有多個並發執行。指令碼應該有效率，不會耗用過多的資源，也不會影響其他使用者在執行個體上的體驗或工作階段的穩定性。

通過將會話腳本邏輯集中在腳本正在運行的特定用戶會話上，可以滿足其中許多要求。

安全考量

AppStream 2.0 映像檔不應設定為允許任何使用者寫入工作階段指令碼檔案的權限。這會引入惡意使用者的嚴重攻擊媒介，讓他們可以修改指令碼檔案。視您的組態而定，這些檔案可以以 SYSTEM 或其他使用者身分執行。

重要

您有責任確保安全地配置 AppStream 2.0 映像檔。這對於多個使用者使用相同執行個體的多工作階段執行個體尤其重要。如果映像檔未安全設定，則該執行個體的所有使用者都有安全性風險。

以下情況應符合您的影像和工作階段指令碼檔案：

  • 使用者沒有修改工作階段指令碼檔案的權限。

  • 使用者沒有修改工作階段指令碼 config.json 的權限。映像上的預設行為會限制管理員的存取權。

會話腳本可執行文件應存儲在安全的位置，在那裡他們是安全的，在運行時修改。

如果服務偵測到工作階段指令碼可執行檔已修改，則該執行個體上該勾點的任何後續執行都會失敗，將日誌檔上傳到 Amazon S3 (如果啟用 Amazon S3 日誌記錄)，並且您會看到下列訊息：

未執行階段作業命令檔，因為執行檔是在執行處理佈建之後修改的。為了安全起見，已跳過執行。

如果您的用例需要在運行時修改會話腳本可執行文件（例如，如果您指向在運行時自動更新過程修改的 EXE 文件），則上述檢查將失敗。在這種情況下，請使用腳本將執行重定向到已修改的可執行文件。服務執行安全性檢查時，不要在執行階段修改指令碼。

如果您的工作階段指令碼檔案過大 (超過 100 MB)，這可能會造成執行個體和工作階段佈建延遲，而且安全性檢查會花費額外的時間 (視執行個體類型和可用資源而定)。如果您的使用案例需要大型工作階段指令碼，請考慮使用較小的指令碼重新導向 這將改善執行個體和工作階段佈建體驗。

請注意，該服務僅檢查會話腳本 config.json 中定義的可執行文件，這只是後備/最佳工作機制。您有責任確保工作階段指令碼可執行檔中的所有程式碼路徑都是安全的，而且一般使用者無法修改。