緊接在 import 語句之後，應用程式的啟動程式代碼會初始化在整個要求處理函式中使用的金鑰變數。
首先，應用程式會建立 Flask 應用程式物件，其可作為定義路由及處理傳入 HTTP 要求的基礎。 接下來，它會從環境變數擷取第三方 API 端點 URL。 此方法使得在不修改程式碼庫的情況下，輕鬆配置端點：
app = Flask(__name__)
app.config["DEBUG"] = True
number_url = os.environ["THIRD_PARTY_API_ENDPOINT"]
接著，它取得DefaultAzureCredential物件，這是在與 Azure 服務驗證時建議使用的憑證。 請參閱 使用DefaultAzureCredential驗證 Azure 託管應用程式。
credential = DefaultAzureCredential()
在本機執行時，DefaultAzureCredential 會尋找 AZURE_TENANT_ID、AZURE_CLIENT_ID和 AZURE_CLIENT_SECRET 環境變數，其中包含您用於本機開發之服務主體的資訊。 在 Azure 中執行時，DefaultAzureCredential 預設會使用在應用程式上啟用的系統指派受控識別。 你可以用應用程式設定覆蓋預設行為，但在這個範例情境中，預設行為是被使用的。
接下來的程式代碼會從 Azure Key Vault 擷取第三方 API 的存取密鑰。 在配置指令碼中，使用 az keyvault create 建立 金鑰保存庫，並使用 az keyvault secret set 儲存祕密。
金鑰保存庫 資源本身是透過從 KEY_VAULT_URL 環境變數載入的URL存取。
key_vault_url = os.environ["KEY_VAULT_URL"]
若要從 Azure Key Vault 擷取秘密，應用程式必須建立與 金鑰保存庫 服務通訊的客戶端物件。 由於目標是讀取秘密，因此應用程式會從SecretClient連結庫使用 azure.keyvault.secrets 類別。 這個用戶端需要兩個輸入：
- 金鑰保存庫 URL – 通常是從環境變數擷取
- 認證物件 – 例如稍早建立的
DefaultAzureCredential實例，代表應用程式執行所在的身分識別。
keyvault_client = SecretClient(vault_url=key_vault_url, credential=credential)
建立 SecretClient 物件並不會立即驗證應用程式的身份。 用戶端只是儲存 金鑰保存庫 URL 和認證物件的本機建構。 只有在您透過用戶端叫用作業時，才會進行驗證和授權，例如 get_secret，這會產生對 Azure 資源的 REST API 呼叫。
api_secret_name = os.environ["THIRD_PARTY_API_SECRET_NAME"]
vault_secret = keyvault_client.get_secret(api_secret_name)
# The "secret" from Key Vault is an object with multiple properties. The key we
# want for the third-party API is in the value property.
access_key = vault_secret.value
即使應用程式的身份被授權存取 Azure Key Vault，也必須明確授權執行特定操作——例如讀取祕密。 如果沒有此許可權，即使身分識別無效，呼叫 get_secret() 也會失敗。 為了解決此權限問題，provisioning 腳本會透過 Azure CLI 指令 . 來設定應用程式的「取得秘密」存取政策。 az keyvault set-policy 如需詳細資訊，請參閱 金鑰保存庫 驗證 和 授予您的應用程式對金鑰保存庫的存取權。 後者文章展示了如何透過 Azure 入口網站設定存取政策。 （本文同樣針對管理身份撰寫，但同樣適用於用於地方開發的服務主體。）
最後，應用程式程式代碼會設定客戶端物件，以便將訊息寫入 Azure 記憶體佇列。 佇列的 URL 位於 環境變數中，STORAGE_QUEUE_URL。
queue_url = os.environ["STORAGE_QUEUE_URL"]
queue_client = QueueClient.from_queue_url(queue_url=queue_url, credential=credential)
如同 Azure Key Vault，應用程式會使用來自 Azure SDK 的特定客戶端物件來與 Azure 佇列記憶體互動。 在此情況下，它會使用 azure-storage-queue 函式庫中的 QueueClient 類別。
若要初始化用戶端，應用程式會使用 from_queue_url 方法，提供佇列的完整 URL 和認證物件。 此認證物件再次是 DefaultAzureCredential 稍早建立的實例，代表應用程式執行所在的身分識別。
如本指南稍早所述，該授權是透過將「儲存體佇列資料參與者」角色指派給應用程式的身分識別來授予的——無論是在 Azure 中的受管理身分識別，或是在本機開發期間的服務主體。
此角色指派可在配置腳本中使用 Azure CLI 指令az role assignment create完成。
假設所有啟動程序代碼都成功，應用程式就已具備其所有內部變數，以支援其 /api/v1/getcode API 端點。