將 WebLogic Server 應用程式遷移至 Azure Kubernetes Service 上的 WildFly
本指南說明當您想要移轉現有的 WebLogic Server 應用程式以在 Azure Kubernetes Service 容器中的 WildFly 上執行時,應該注意的事項。
移轉前
為確保成功移轉,在開始之前,請先完成下列各節中所述的評量和清查步驟。
如果您無法符合移轉前需求,請參閱隨附移轉指南:
清查伺服器容量
記錄目前生產伺服器的硬體(記憶體、CPU、磁碟),以及平均和尖峰要求計數和資源使用率。 無論您選擇哪一種遷移路徑,您都需要這項資訊。 例如,協助引導選取節點集區中 VM 的大小、容器要使用的記憶體數量,以及容器需要多少 CPU 共用。
它可以調整 AKS 中的節點集區大小。 若要瞭解如何,請參閱 調整 Azure Kubernetes Service (AKS) 中的節點集區大小。
清查所有秘密
在 Azure 金鑰保存庫 等「設定即服務」技術出現之前,沒有定義完善的「秘密」概念。 相反地,您所擁有的是一組完全不同的組態設定,其作用實際上等同於我們現在所謂的「秘密」。 使用 WebLogic Server 之類的應用程式伺服器,這些秘密位於許多不同的組態檔和組態存放區中。 檢查實際執行伺服器上的所有屬性和設定檔是否有任何秘密和密碼。 請務必在 WAR 中檢查 weblogic.xml 。 您也可以在應用程式內找到包含密碼或認證的設定檔。 如需詳細資訊,請參閱 Azure 金鑰保存庫 基本概念。
清查所有憑證
記載所有用於公用 SSL 端點的憑證。 您可以執行下列命令來檢視實際執行伺服器上的所有憑證:
keytool -list -v -keystore <path to keystore>
清查 JNDI 資源
清查所有 JNDI 資源。 例如,資料庫之類的數據源可能會有相關聯的 JNDI 名稱,可讓 JPA 正確地將 的 EntityManager
實例系結至特定資料庫。 如需 JNDI 資源和資料庫的詳細資訊,請參閱 Oracle 檔中的 WebLogic Server 數據源 。 其他 JNDI 相關資源,例如 JMS 訊息代理程式,可能需要移轉或重新設定。 如需 JMS 設定的詳細資訊,請參閱 Oracle WebLogic Server 12.2.1.4.0。
判斷是否使用會話複寫
如果您的應用程式依賴會話復寫,且具有或不含 Oracle 一致性*Web,您有兩個選項:
- 重構您的應用程式以使用資料庫進行會話管理。
- 重構您的應用程式,以將會話外部化至 Azure Redis 服務。 如需詳細資訊,請參閱 Azure Cache for Redis。
檔數據源
如果應用程式使用任何資料庫,則必須擷取下列資訊:
- 數據源名稱為何?
- 連線集區設定是什麼?
- 哪裡可以找到 JDBC 驅動程式 JAR 檔案?
如需 WebLogic 中 JDBC 驅動程式的詳細資訊,請參閱 搭配 WebLogic Server 使用 JDBC 驅動程式。
判斷 WebLogic 是否已自定義
判斷已進行下列哪一項自定義,並擷取已完成的工作。
- 啟動文稿是否已變更? 這類腳本包括 setDomainEnv、commEnv、startWebLogic 和 stopWebLogic。
- 是否有任何特定參數傳遞至 JVM?
- 是否有 JAR 新增至伺服器類別路徑?
判斷是否需要連線至內部部署環境
如果您的應用程式需要存取您的任何內部部署服務,您必須佈建其中一個 Azure 連線能力服務。 如需詳細資訊,請參閱將內部部署網路連線至 Azure。 或者,您必須重構應用程式,以使用內部部署資源所顯示的公開可用 API。
判斷 Java 訊息服務 (JMS) 佇列或主題是否正在使用中
如果應用程式使用 JMS 佇列或主題,您就必須將這些佇列或主題遷移到裝載在外部的 JMS 伺服器。 對於這些使用 JMS 的佇列或主題來說,Azure 服務匯流排和進階訊息佇列通訊協定 (AMQP) 會是絕佳的移轉策略。 如需詳細資訊,請參閱搭配 Azure 服務匯流排 標準和AMQP 1.0使用Java Message Service 1.1。
如果您已設定 JMS 持續性存放區,就必須在移轉之後擷取存放區的設定並加以套用。
判斷您是否使用自己的自定義建立共用Java EE 連結庫
如果您使用共用 Java EE 連結函式庫功能,您有兩個選項:
- 重構應用程式程式代碼以移除連結庫上的所有相依性,並改為將功能直接併入您的應用程式。
- 將連結庫新增至伺服器類別路徑。
判斷是否使用OSGi套件組合
如果您使用新增至 WebLogic 伺服器的 OSGi 套件組合,則必須將相等的 JAR 檔案直接新增至 Web 應用程式。
判斷您的應用程式是否包含 OS 特定程式代碼
如果您的應用程式包含主機 OS 上具有相依性的任何程式代碼,則必須重構它以移除這些相依性。 例如,您可能需要使用 或 \
取代檔案系統路徑File.Separator
中的任何用法/
,或Paths.get
如果您的應用程式在 Windows 上執行。
判斷 Oracle 服務匯流排 是否正在使用中
如果您的應用程式使用 Oracle 服務匯流排 (OSB),您必須擷取 OSB 的設定方式。 如需詳細資訊,請參閱關於 Oracle 服務匯流排 安裝。
判斷應用程式是否由多個 WAR 組成
如果應用程式由多個 WAR 組成,則應該將這些 WAR 視為個別應用程式,並瀏覽本指南以了解這些 WAR。
判斷應用程式是否封裝為 EAR
如果您的應用程式封裝為 EAR 檔案,請務必檢查 application.xml 和 weblogic-application.xml 檔案並擷取其組態。
注意
如果您想要能夠獨立調整每個 Web 應用程式,以便更妥善地使用 Azure Kubernetes Service 資源,您應該將 EAR 分成不同的 Web 應用程式。
識別在生產伺服器上執行的所有外部處理序和精靈
如果您有任何在應用程式伺服器外部執行的處理序 (例如監視精靈),則必須加以消除或將其遷移到其他位置。
驗證支援的 Java 版本是否正常運作
在 Azure Kubernetes Service 上使用 WildFly 需要特定版本的 Java,因此您必須確認您的應用程式使用該支援的版本正確執行。
注意
如果您的目前伺服器是在不支援的 JDK 上執行,此驗證特別重要(例如 Oracle JDK 或 IBM OpenJ9)。
若要取得目前的 Java 版本,請登入您的生產伺服器,然後執行下列命令:
java -version
如需使用哪些版本來執行WildFly的指引,請參閱 需求 。
判斷您的應用程式是否依賴排程的作業
排程的作業,例如讓排程器工作或 Unix cron 工作,不應該與 Azure Kubernetes Service (AKS) 搭配使用。 Azure Kubernetes Service 不會防止您在內部部署包含排程工作的應用程式。 不過,如果您的應用程式相應放大,則每個排程期間,相同的排程工作可能會執行多次。 這種情況可能會導致非預期的後果。
若要在 AKS 叢集上執行排程的工作,請視需要定義 Kubernetes CronJobs。 如需詳細資訊,請參閱 使用 CronJob 執行自動化工作。
判斷是否使用 WebLogic 腳本工具
如果您目前使用 WebLogic 腳本工具 (WLST) 來執行部署,您必須評估其運作狀況。 如果 WLST 正在變更應用程式的任何 (執行時間) 參數作為部署的一部分,請確定這些參數符合下列其中一個選項:
- 參數會外部化為應用程式設定。
- 參數會內嵌在您的應用程式中。
- 參數會在部署期間使用 JBoss CLI。
如果WLST執行的動作超過上述內容,則您在移轉期間會有一些額外的工作要做。
判斷您的應用程式是否使用 WebLogic 特定 API
如果您的應用程式使用 WebLogic 特定的 API,您必須重構它以移除這些相依性。 例如,如果您已使用 Oracle WebLogic Server 的 Java API 參考中所述的類別,則已在應用程式中使用 WebLogic 特定的 API。 您必須重構才能移除參考。
判斷您的應用程式是否使用 Entity Beans 或 EJB 2.x 樣式 CMP Beans
如果您的應用程式使用 Entity Beans 或 EJB 2.x 樣式 CMP 豆類,您必須重構應用程式以移除這些相依性。
判斷 Java EE 應用程式用戶端應用程式功能是否正在使用中
如果您有使用 Java EE 應用程式用戶端應用程式用戶端功能連線到您的 (server) 應用程式,您必須重構用戶端應用程式和 (伺服器) 應用程式,才能使用 HTTP API。
判斷是否已使用部署計劃
如果您的應用程式是使用部署計劃部署,請評估部署計劃正在執行的動作。 如果部署計劃是直接部署,您將能夠在不進行任何變更的情況下部署Web應用程式。 如果部署計劃更詳細,請判斷您是否可以使用 JBoss CLI 來正確設定應用程式作為部署的一部分。 如果無法使用 JBoss CLI,請以不再需要部署計畫的方式重構您的應用程式。
判斷EJB定時器是否正在使用中
如果您的應用程式使用EJB定時器,您必須驗證每個WildFly實例都可以獨立觸發EJB定時器程序代碼。 此驗證是必要的,因為在 Azure Kubernetes Service 部署案例中,每個 EJB 定時器都會在其自己的 WildFly 實例上觸發。
判斷是否要使用檔案系統及如何使用
應用程式伺服器上的檔案系統使用方式都需要重新設定,或在某些情況下,架構變更。 檔案系統可能由 WebLogic 共用模組或您的應用程式程式代碼使用。 您可能會識別下列各節所述的部分或所有案例。
唯讀靜態內容
如果應用程式目前提供靜態內容,則必須為其提供替代位置。 您可能想要考慮將靜態內容移至 Azure Blob 儲存體 並新增 Azure CDN,以在全球快速下載。 如需詳細資訊,請參閱 Azure 儲存體中的靜態網站裝載和快速入門:整合 Azure 儲存體帳戶與 Azure CDN。
動態發佈的靜態內容
如果您的應用程式允許您應用程式上傳/產生的靜態內容,但在建立後不可變,則您可以使用上述的 Azure Blob 儲存體和 CDN,搭配 Azure 函式來處理上傳和 CDN 重新整理。 我們已在使用 Azure Functions 上傳和透過 CDN 預先載入靜態內容中提供範例實作供您使用。
動態或內部內容
對於您應用程式經常寫入和讀取的檔案 (例如暫存資料檔案),或只有您的應用程式才能看見的靜態檔案,您可以掛接 Azure 儲存體共用,作為永續性磁碟區。 如需詳細資訊,請參閱在 Azure Kubernetes Service 中建立和使用具有 Azure 檔案儲存體 的磁碟區(AKS)。
判斷是否使用 JCA 連接器
如果您的應用程式使用 JCA 連接器,您必須驗證 JCA 連接器是否可以在 WildFly 上使用。 如果 JCA 實作系結至 WebLogic,您必須重構應用程式以移除該相依性。 如果可以使用,則必須將 JAR 新增至伺服器 classpath,並將必要的組態檔放在 WildFly 伺服器目錄中的正確位置,以供使用。
判斷您的應用程式是否使用資源配接器
如果您的應用程式需要資源配接器 (RA),它必須與WildFly相容。 藉由將RA部署到伺服器並正確設定,判斷RA在WildFly的獨立實例上是否正常運作。 如果 RA 正常運作,您必須將 JAR 新增至 Docker 映像的伺服器類別路徑,並將必要的組態檔放在 WildFly 伺服器目錄中的正確位置,以供使用。
判斷 JAAS 是否正在使用中
如果您的應用程式使用 JAAS,您必須擷取 JAAS 的設定方式。 如果使用資料庫,您可以將它轉換成WildFly上的JAAS網域。 如果是自定義實作,您必須驗證它是否可以在WildFly上使用。
判斷是否使用 WebLogic 叢集
您很可能已在多個 WebLogic 伺服器上部署應用程式,以達到高可用性。 Azure Kubernetes Service 能夠調整,但如果您使用 WebLogic 叢集 API,則需要重構程式代碼,以消除使用該 API 的使用。
執行就地測試
在建立容器映像之前,請將您的應用程式移轉至您想要在 AKS 上使用的 JDK 和 WildFly 版本。 徹底測試應用程式,以確保相容性和效能。
遷移
布建 Azure Container Registry 和 Azure Kubernetes Service
使用下列命令來建立容器登錄和具有登錄上讀取者角色的服務主體的 Azure Kubernetes 叢集。 請務必 為叢集的網路需求選擇適當的網路模型 。
az group create \
--resource-group $resourceGroup \
--location eastus
az acr create \
--resource-group $resourceGroup \
--name $acrName \
--sku Standard
az aks create \
--resource-group $resourceGroup \
--name $aksName \
--attach-acr $acrName \
--network-plugin azure
建立WildFly的 Docker 映像
若要建立 Dockerfile,您需要下列必要條件:
- 支援的 JDK。
- WildFly 的安裝。
- 您的 JVM 執行時間選項。
- 傳入環境變數的方法(如果適用的話)。
然後,您可以執行下列各節中所述的步驟,如果適用的話。 您可以使用 WildFly容器快速入門存放庫 作為 Dockerfile 和 Web 應用程式的起點。
設定 KeyVault FlexVolume
建立 Azure KeyVault 並填入所有必要的秘密。 如需詳細資訊,請參閱快速入門:使用 Azure CLI 從 Azure Key Vault 設定和擷取祕密。 然後,設定 KeyVault FlexVolume ,讓 Pod 能夠存取這些秘密。
您也需要更新用來啟動WildFly的啟動腳本。 此腳本必須先將憑證匯入WildFly所使用的密鑰存放區,才能啟動伺服器。
設定數據源
若要將WildFly設定為存取資料源,您必須將JDBC驅動程式JAR新增至 Docker 映像,然後執行適當的 JBoss CLI 命令。 建置 Docker 映射時,這些命令必須設定數據源。
下列步驟提供 PostgreSQL、MySQL 和 SQL Server 的指示。
下載適用於 PostgreSQL、MySQL 或 SQL Server 的 JDBC 驅動程式。
將下載的封存解壓縮,以取得驅動程式.jar檔案。
建立名稱如下
module.xml
的檔案,並新增下列標記。 將<module name>
佔位元元(包括角括號)取代org.postgres
為 PostgreSQL、com.mysql
MySQL 或com.microsoft
SQL Server。 將 取代<JDBC .jar file path>
為上一個步驟中.jar檔案的名稱,包括將檔案放在 Docker 映射中位置的完整路徑,例如 。/opt/database
<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="<module name>"> <resources> <resource-root path="<JDBC .jar file path>" /> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
建立名稱如下
datasource-commands.cli
的檔案,並新增下列程序代碼。 將取代<JDBC .jar file path>
為您在上一個步驟中使用的值。<module file path>
取代為上一個步驟中的檔案名稱與路徑, 例如/opt/database/module.xml
。注意
Microsoft 建議您使用最安全的可用驗證流程。 此程式中所述的驗證流程,例如資料庫、快取、傳訊或 AI 服務,在應用程式中需要高度的信任,而且不會在其他流程中帶來風險。 只有在更安全的選項,例如無密碼或無密鑰連線的受控識別時,才能使用此流程。 針對本機計算機作業,偏好使用無密碼或無密鑰連線的使用者身分識別。
batch module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path> /subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource) data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker reload run batch shutdown
更新應用程式的 JTA 資料來源:
src/main/resources/META-INF/persistence.xml
開啟應用程式的檔案,並尋找<jta-data-source>
元素。 取代其內容,如下所示:<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
將下列內容新增至 ,
Dockerfile
以便在建置 Docker 映射時建立數據源RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \ sleep 30 && \ <WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \ sleep 30
DATABASE_CONNECTION_URL
判斷要用於每個資料庫伺服器的 ,且與 Azure 入口網站 上的值不同。 這裡顯示的網址格式是 WildFly 使用的必要格式:jdbc:postgresql://<database server name>:5432/<database name>?ssl=true
在稍後階段建立部署 YAML 時,您必須傳遞下列環境變數 ,
DATABASE_CONNECTION_URL
DATABASE_SERVER_ADMIN_FULL_NAME
並使用DATABASE_SERVER_ADMIN_PASSWORD
適當的值。
注意
Microsoft 建議您使用最安全的可用驗證流程。 此程式中所述的驗證流程,例如資料庫、快取、傳訊或 AI 服務,在應用程式中需要高度的信任,而且不會在其他流程中帶來風險。 只有在更安全的選項,例如無密碼或無密鑰連線的受控識別時,才能使用此流程。 針對本機計算機作業,偏好使用無密碼或無密鑰連線的使用者身分識別。
如需使用WildFly設定資料庫連線的詳細資訊,請參閱PostgreSQL、MySQL或 SQL Server。
設定 JNDI 資源
若要設定您需要在WildFly上設定的每個JNDI資源,您通常會使用下列步驟:
- 下載必要的 JAR 檔案,並將其複製到 Docker 映像。
- 建立參考這些 JAR 檔案的 WildFly module.xml 檔案。
- 建立特定 JNDI 資源所需的任何設定。
- 建立 JBoss CLI 腳本,以在 Docker 組建期間用來註冊 JNDI 資源。
- 將所有專案新增至 Dockerfile。
- 在部署YAML中傳遞適當的環境變數。
下列範例顯示建立 JMS 連線至 Azure 服務匯流排 之 JNDI 資源所需的步驟。
-
將下載的封存解壓縮,以取得.jar檔案。
在 中建立名稱如下
module.xml
的檔案,並在 中/opt/servicebus
新增下列標記。 請確定 JAR 檔案的版本號碼與上一個步驟的 JAR 檔名一致。<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider"> <resources> <resource-root path="proton-j-0.31.0.jar"/> <resource-root path="qpid-jms-client-0.40.0.jar"/> <resource-root path="slf4j-log4j12-1.7.25.jar"/> <resource-root path="slf4j-api-1.7.25.jar"/> <resource-root path="log4j-1.2.17.jar"/> <resource-root path="netty-buffer-4.1.32.Final.jar" /> <resource-root path="netty-codec-4.1.32.Final.jar" /> <resource-root path="netty-codec-http-4.1.32.Final.jar" /> <resource-root path="netty-common-4.1.32.Final.jar" /> <resource-root path="netty-handler-4.1.32.Final.jar" /> <resource-root path="netty-resolver-4.1.32.Final.jar" /> <resource-root path="netty-transport-4.1.32.Final.jar" /> <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" /> <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" /> <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" /> <resource-root path="qpid-jms-discovery-0.40.0.jar" /> </resources> <dependencies> <module name="javax.api"/> <module name="javax.jms.api"/> </dependencies> </module>
在中
/opt/servicebus
建立jndi.properties
檔案。connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY} queue.${MDB_QUEUE}=${SB_QUEUE} topic.${MDB_TOPIC}=${SB_TOPIC}
建立名稱如下
servicebus-commands.cli
的檔案,並新增下列程序代碼。batch /subsystem=ee:write-attribute(name=annotation-property-replacement,value=true) /system-property=property.mymdb.queue:add(value=myqueue) /system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF) /subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"} /subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties]) /subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction) /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY}) /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY}) /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties") /subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true) /subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra) run-batch reload shutdown
將下列內容新增至 ,
Dockerfile
以便在建置 Docker 映射時建立 JNDI 資源RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \ sleep 30 && \ <WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \ sleep 30
在稍後階段建立部署 YAML 時,您必須使用適當的值傳遞下列環境變數、
MDB_CONNECTION_FACTORY
DEFAULT_SBNAMESPACE
和SB_SAS_POLICY
、SB_SAS_KEY
、MDB_QUEUE
、SB_QUEUE
MDB_TOPIC
和SB_TOPIC
。
檢閱WildFly設定
檢閱 WildFly系統管理指南 ,以涵蓋先前指引未涵蓋的任何其他移轉前步驟。
建置 Docker 映射並將其推送至 Azure Container Registry
建立 Dockerfile 之後,您必須建置 Docker 映射,並將其發佈至您的 Azure 容器登錄。
如果您使用WildFly 容器快速入門 GitHub 存放庫,建置映像並將其推送至 Azure Container Registry 的程式相當於叫用下列三個命令。
在這些範例中 MY_ACR
,環境變數會保存 Azure 容器登錄的名稱,而 MY_APP_NAME
變數會保留您想要在 Azure 容器登錄上使用的 Web 應用程式名稱。
建置 WAR 檔案:
mvn package
登入您的 Azure Container Registry:
az acr login --name ${MY_ACR}
建置並推送映射:
az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .
或者,您可以使用 Docker CLI 先在本機建置及測試映射,如下列命令所示。 這種方法可以簡化在初始部署至 ACR 之前測試和精簡映像。 不過,您必須安裝 Docker CLI,並確定 Docker 精靈正在執行。
建置映像:
docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}
在本機執行映像:
docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}
您現在可以在 http://localhost:8080
存取您的應用程式。
登入您的 Azure Container Registry:
az acr login --name ${MY_ACR}
將映像推送至您的 Azure 容器登錄:
docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}
如需在 Azure 中建置和儲存容器映像的詳細資訊,請參閱 Learn 模組 使用 Azure Container Registry 建置和儲存容器映像。
布建公用IP位址
如果您的應用程式可從內部或虛擬網路外部存取,您將需要公用靜態IP位址。 您應該在叢集的節點資源群組內布建此 IP 位址,如下列範例所示:
export nodeResourceGroup=$(az aks show \
--resource-group $resourceGroup \
--name $aksName \
--query 'nodeResourceGroup' \
--output tsv)
export publicIp=$(az network public-ip create \
--resource-group $nodeResourceGroup \
--name applicationIp \
--sku Standard \
--allocation-method Static \
--query 'publicIp.ipAddress' \
--output tsv)
echo "Your public IP address is ${publicIp}."
部署到 Azure Kubernetes Service (AKS)
建立並套用 Kubernetes YAML 檔案(s)。 如需詳細資訊,請參閱 快速入門:使用 Azure CLI 部署 Azure Kubernetes Service (AKS) 叢集。 如果您要建立外部負載平衡器(無論是針對您的應用程式還是輸入控制器),請務必提供上一節中布建的IP位址作為 LoadBalancerIP
。
將外部化參數納入為環境變數。 如需詳細資訊,請參閱 定義容器的環境變數。 請勿包含秘密(例如密碼、API 金鑰和 JDBC 連接字串)。 下一節將討論這些內容。
建立部署 YAML 時,請務必包含記憶體和 CPU 設定,讓您的容器大小正確。
設定永續性記憶體
如果您的應用程式需要非揮發性記憶體,請設定一或多個 永續性磁碟區。
移轉排程的工作
若要在 AKS 叢集上執行排程的工作,請視需要定義 Kubernetes CronJobs。 如需詳細資訊,請參閱 使用 CronJob 執行自動化工作。
移轉後
既然您已將應用程式移轉至 Azure Kubernetes Service,您應該確認它如預期般運作。 執行此動作之後,請參閱下列建議,讓您的應用程式更具雲端原生。
建議
請考慮將 DNS 名稱新增至配置給輸入控制器或應用程式負載平衡器的 IP 位址。 如需詳細資訊,請參閱 在 Azure Kubernetes Service (AKS) 上搭配輸入控制器使用 TLS。
請考慮為您的應用程式新增 HELM 圖表 。 Helm 圖表可讓您將應用程式部署參數化,以供一組更多樣化的客戶使用和自定義。
設計和實作DevOps策略。 若要在提高開發速度的同時維持可靠性,請考慮使用 Azure Pipelines 將部署和測試自動化。 如需詳細資訊,請參閱 使用 Azure Pipelines 建置和部署至 Azure Kubernetes Service。
啟用叢集的 Azure 監視。 如需詳細資訊,請參閱啟用 Kubernetes 叢集的監視。 這可讓 Azure 監視器收集容器記錄、追蹤使用率等等。
請考慮透過 Prometheus 公開應用程式特定計量。 Prometheus 是 Kubernetes 社群中廣泛採用的開放原始碼計量架構。 您可以在 Azure 監視器中設定 Prometheus 計量,而不是裝載自己的 Prometheus 伺服器,以啟用應用程式的計量匯總,以及自動回應或呈報異常狀況。 如需詳細資訊,請參閱 啟用 Prometheus 和 Grafana。
設計和實作商務持續性和災害復原策略。 針對任務關鍵性應用程式,請考慮多區域部署架構。 如需詳細資訊,請參閱 Azure Kubernetes Service 的高可用性和災害復原概觀(AKS)。
檢閱 Kubernetes 版本支持原則。 您必須繼續更新 AKS 叢集,以確保它一律執行支援的版本。 如需詳細資訊,請參閱 Azure Kubernetes Service (AKS) 叢集的升級選項。
讓負責叢集管理和應用程式開發的所有小組成員檢閱相關的 AKS 最佳做法。 如需詳細資訊,請參閱 在 Azure Kubernetes Service (AKS) 上建置和管理應用程式的叢集操作員和開發人員最佳做法。
請確定您的部署檔案會指定輪流更新的完成方式。 如需詳細資訊,請參閱 Kubernetes 檔中的滾動更新部署 。
設定自動調整以處理尖峰時間負載。 如需詳細資訊,請參閱在 Azure Kubernetes Service (AKS) 中使用叢集自動調整程式。
請考慮監視程序代碼快取大小,並在 Dockerfile 中新增 JVM 參數
-XX:InitialCodeCacheSize
-XX:ReservedCodeCacheSize
,以進一步優化效能。 如需詳細資訊,請參閱 Oracle 檔中的 Codecache Tuning 。