使用 Azure App Service、流量管理員和適用於 MySQL 的 Azure 資料庫重構 Linux 應用程式

  • 發行項

本文說明虛構公司 Contoso 如何重構以 LAMP 為基礎的兩層式應用程式，使用 Azure App Service 與 GitHub 的整合和適用於 MySQL 的 Azure 資料庫，將其從內部部署遷移至 Azure。

osTicket 是我們在此範例中使用的服務台應用程式，以開放原始碼軟體的形式提供。 如果您想要將其用於您自己的測試目的，可以從 GitHub 中的 osTicket 存放庫加以下載。

商業動機

IT 領導小組與商務合作夥伴密切合作，了解他們想要達成什麼目標：

  • 因應業務成長。 Contoso 正在成長並轉向新的市場。 需要額外的客戶服務代理程式。
  • 擴充。 應該建置解決方案，好讓 Contoso 隨著商務擴展而新增更多客戶服務代理程式。
  • 改善復原能力。 過去的系統問題只會影響內部使用者。 使用新的商業模式，外部使用者會受到影響，而 Contoso 需要應用程式隨時保持在運作狀態。

移轉目標

為了判斷最佳移轉方法，Contoso 雲端小組已針對此移轉擬定好各項目標：

  • 應用程式應該擴展超過目前的內部部署容量和效能。 Contoso 正在移動應用程式，以充分利用 Azure 的隨選縮放。
  • Contoso 希望能將應用程式的程式碼基底移至持續傳遞管線。 當應用程式變更推送至 GitHub 時，Contoso 希望營運人員不需要進行任何工作，便可部署這些變更。
  • 應用程式必須先具備成長與容錯移轉的能力，才算是具備復原性。 Contoso 想要在兩個不同的 Azure 區域中部署應用程式，並設定為自動調整。
  • 將應用程式移到雲端之後，Contoso 想要將資料庫管理工作減到最少。

解決方案設計

擬定好目標和需求後，Contoso 會設計和檢閱部署解決方案，並識別移轉程序，包括將用於移轉的 Azure 服務。

目前架構

  • 應用程式會分層至兩個虛擬機器 (VM) (OSTICKETWEB 和 OSTICKETMYSQL)。
  • VM 位於 VMware ESXi 主機 contosohost1.contoso.com(6.5 版)。
  • VMware 環境是由 VM 上所執行的 VCenter Server 6.5 (vcenter.contoso.com) 進行管理。
  • Contoso 有內部部署資料中心 (contoso-datacenter) 以及內部部署網域控制站 (contosodc1)。

目前架構的圖表。

建議的架構

以下是建議的架構：

  • OSTICKETWEB 上的 Web 層應用程式會藉由在兩個 Azure 區域中建至 Azure App Service Web 應用程式來進行遷移。 Contoso 小組將使用 PHP 7.0 Docker 容器來實作適用於 Linux 的 Azure App Service。
  • 應用程式程式碼將會移至 GitHub，而且會設定 Azure App Service Web 應用程式以便透過 GitHub 持續傳遞。
  • Azure App Service 將同時部署在主要區域 (East US 2) 和次要區域 (Central US)。
  • 在這兩個區域中，Azure 流量管理員將會設定於兩個 Web 應用程式前面。
  • 流量管理員將以優先順序模式設定，以強制流量通過 East US 2。
  • 如果 East US 2 中的 Azure 應用程式伺服器離線，使用者可以存取 Central US 中已容錯移轉的應用程式。
  • 應用程式資料庫將使用 Azure 資料庫移轉服務，移轉至適用於 MySQL 的 Azure 資料庫服務。 內部部署資料庫將在本機進行備份，並直接還原到適用於 MySQL 的 Azure 資料庫。
  • 資料庫會存在於主要區域 (East US 2) 中，位於生產網路 (VNET-PROD-EUS2) 的資料庫子網路 (PROD-DB-EUS2) 上。
  • 因為他們要遷移生產工作負載，所以應用程式的 Azure 資源會位於生產資源群組 ContosoRG 中。
  • 流量管理員資源會部署在 Contoso 的基礎結構資源群組 ContosoInfraRG 中。
  • 移轉完成之後，將會解除委任 Contoso 資料中心的內部部署 VM。

案例架構的圖表。

移轉程序

Contoso 會依照下列方式完成移轉程序：

  1. 在第一個步驟中，Contoso 管理員會設定 Azure 基礎結構，包括佈建 Azure App Service、設定流量管理員，以及佈建適用於 MySQL 的 Azure 資料庫執行個體。
  2. 準備好 Azure 基礎結構後，他們使用 Azure 資料庫移轉服務來移轉資料庫。
  3. 在 Azure 中執行資料庫之後，他們使用持續傳遞為 Azure App Service 上傳 GitHub 私人存放庫，並使用 osTicket 應用程式將其載入。
  4. 在 Azure 入口網站中，他們執行了 Azure App Service，將應用程式從 GitHub 載入至 Docker 容器。
  5. 他們調校 DNS 設定，並且為應用程式設定自動調整。

Contoso 移轉程式的圖表。

Azure 服務

服務 描述 成本
Azure App Service 此服務會對網站使用 Azure 平台即服務 (PaaS)，以執行及調整應用程式。 定價以執行個體的大小和所需的功能為基礎。 深入了解。
Azure 流量管理員 使用網域名稱系統 (DNS) 將使用者導向至 Azure 或外部網站和服務的負載平衡器。 定價以收到的 DNS 查詢數目和已監視的端點數目為基礎。 深入了解。
Azure Database Migration Service Azure 資料庫移轉服務能夠從多個資料庫來源無縫移轉到 Azure 資料平台，將停機時間降到最低。 深入了解支援的區域和資料庫移轉服務定價。
適用於 MySQL 的 Azure 資料庫 此資料庫是以開放原始碼 MySQL 資料庫引擎為基礎。 其可為應用程式開發和部署，提供完全受控且符合企業需求的社群 MySQL 資料庫。 定價以計算、儲存和備份需求為基礎。 深入了解。

必要條件

若要執行此案例，Contoso 必須符合下列必要條件：

需求 詳細資料
Azure 訂用帳戶 Contoso 稍早已在本文章系列中建立訂用帳戶。 如果您沒有 Azure 訂用帳戶，請建立免費帳戶。

如果您建立免費帳戶，您就是訂用帳戶的管理員，並可執行所有動作。

如果您使用現有訂用帳戶，而且您不是系統管理員，則需要與系統管理員合作，讓其指派擁有者或參與者權限給您。
Azure 基礎結構 Contoso 會如適用於移轉的 Azure 基礎結構中所述，設定其 Azure 基礎結構。

案例步驟

以下是 Contoso 用來完成移轉的計劃：

  • 步驟 1：佈建 Azure App Service。 Contoso 管理員會在主要和次要區域中佈建 Web 應用程式。
  • 步驟 2：設定流量管理員。 他們會在 Web 應用程式前面設定流量管理員，以便路由傳送及平衡流量負載。
  • 步驟 3：佈建適用於 MySQL 的 Azure 資料庫。 在 Azure 中，他們會佈建適用於 MySQL 的 Azure 資料庫執行個體。
  • 步驟 4：遷移資料庫。 他們使用 Azure 資料庫移轉服務來移轉資料庫。
  • 步驟 5︰設定 GitHub。 他們設定應用程式網站和程式碼的本機 GitHub 存放庫。
  • 步驟 6：設定 Web 應用程式。 他們使用 osTicket 網站來設定 Web 應用程式。

步驟 1：佈建 Azure App Service

Contoso 管理員會使用 Azure App Service 佈建兩個 Web 應用程式 (每個區域一個)。

  1. 他們透過 Azure Marketplace，在主要區域 (East US 2) 中建立 Web 應用程式資源 (osticket-eus2)。

  2. 他們將資源放在生產資源群組 ContosoRG 中。

    在 Linux 中建立 Web 應用程式的 [Web 應用程式] 窗格螢幕擷取畫面。

  3. 他們在主要區域中建立 App Service 方案 APP-SVP-EUS2，並使用標準大小。

    [新增App Service方案] 窗格的螢幕擷取畫面，用於建立App Service方案。

  4. 他們會選取具有 PHP 7.0 執行階段堆疊的 Linux OS，這是一個 Docker 容器。

    [Web 應用程式] 窗格的螢幕擷取畫面，其中已選取 Linux OS、美國東部 2 位置和 PHP 7.0。

  5. 他們建立第二個 Web 應用程式 osticket-cus，以及美國中部的 Azure App Service 方案。

    [Web 應用程式] 窗格的螢幕擷取畫面，其中已選取 Linux OS、美國中部位置和 PHP 7.0。

需要其他協助？

步驟 2：設定流量管理員

Contoso 管理員會設定流量管理員，將輸入的 Web 要求導向至在 osTicket Web 層上執行的 Web 應用程式。

  1. 在 Azure Marketplace 中，他們建立流量管理員資源 osticket.trafficmanager.net。 他們採用優先順序路由，因此美國東部 2 是主要站台。 他們將此資源放在其現有的基礎結構資源群組 ContosoInfraRG 中。 請注意，流量管理員為全域服務，無法繫結至特定位置。

    [建立流量管理員設定檔] 窗格的螢幕擷取畫面。

  2. 他們使用端點來設定流量管理員。 他們將美國東部 2 的 Web 應用程式新增為主要站台 osticket-eus2，並以美國中部的 Web 應用程式作為次要站台 osticket-cus。

    流量管理員中 [新增端點] 窗格的螢幕擷取畫面。

  3. 新增端點後，管理員可加以進行。

    [端點] 窗格的螢幕擷取畫面，用於監視流量管理員中的端點。

需要其他協助？

步驟 3：佈建適用於 MySQL 的 Azure 資料庫

Contoso 管理員在主要區域美國東部 2 佈建 MySQL 資料庫執行個體。

  1. 在 Azure 入口網站中，他們可會建立適用於 MySQL 的 Azure 資料庫資源。

    Azure 入口網站中適用於 MySQL 的 Azure 資料庫連結的螢幕擷取畫面。

  2. 他們新增 Azure 資料庫的名稱 contosoosticket。 他們將資料庫新增至生產資源群組 ContosoRG，然後為其指定認證。

  3. 內部部署 MySQL 資料庫的版本為 5.7，因此他們會為了相容性而選取這個版本。 他們會使用預設大小，以符合其資料庫需求。

    MySQL 伺服器窗格的螢幕擷取畫面，其中已選取 5.7 版。

  4. 針對 [備份備援選項]，他們選取 [異地備援]。 此選項可讓他們在中斷發生時，能夠在其次要區域 (美國中部) 還原資料庫。 只有在佈建資料庫時，才能設定此選項。

    [備份備援選項] 窗格的螢幕擷取畫面，其中已選取 [Geo-Redundant] 選項。

  5. 他們會設定連線安全性。 在資料庫中，他們選取 [連線安全性] 中，然後設定防火牆規則以允許資料庫存取 Azure 服務。

  6. 他們會將本機工作站用戶端 IP 位址新增到開始和結束 IP 位址。 這可讓 Web 應用程式存取 MySQL 資料庫，以及存取執行移轉的資料庫用戶端。

    [連線安全性] 窗格的螢幕擷取畫面，其中顯示已開啟的 Azure 服務的存取權，以及選取的用戶端 IP 位址。

步驟 4：遷移資料庫

有數種方式可以移動 MySQL 資料庫。 每個選項都需要 Contoso 管理員建立目標的適用於 MySQL 的 Azure 資料庫執行個體。 建立執行個體之後，他們就可以使用下列兩個路徑之一來遷移資料庫：

  • 步驟 4a：Azure 資料庫移轉服務
  • 步驟 4b：MySQL Workbench 備份和還原

步驟 4a：透過 Azure 資料庫移轉服務來移轉資料庫

Contoso 管理員會遵循逐步移轉教學課程，透過 Azure 資料庫移轉服務來移轉資料庫。 使用 MySQL 5.6 或 5.7，即可執行線上、離線和混合式 (預覽) 移轉。

注意

適用於 MySQL 的 Azure 資料庫支援 MySQL 8.0，但資料庫移轉服務工具尚不支援該版本。

簡言之，Contoso 會執行下列動作：

  • 確定已符合所有移轉必要條件：

    • MySQL 資料庫伺服器來源必須符合適用於 MySQL 的 Azure 資料庫所支援的版本。 適用於 MySQL 的 Azure 資料庫支援 MySQL 社群版本、InnoDB 儲存體引擎，以及相同版本的來源與目標之間的移轉。

    • 他們在 my.ini (Windows) 或 my.cnf (Unix) 中啟用二進位記錄。 若未這麼做，則會在 [移轉精靈] 中造成下列錯誤：

      Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

      如需詳細資訊，請參閱 MySQL 文件中的二進位記錄選項和變數。

    • 使用者必須具有 ReplicationAdmin 角色。

    • 遷移沒有外部索引鍵和觸發程序的資料庫結構描述。

  • 他們建立透過 ExpressRoute 或 VPN 連線至內部部署網路的虛擬私人網路 (VPN)。

  • 他們會使用連線至虛擬網路的進階 SKU，建立 Azure 資料庫移轉服務執行個體。

  • 他們確定 Azure 資料庫移轉服務可透過虛擬網路存取 MySQL 資料庫。 這需要確定所有連入連接埠都可從 Azure 連入虛擬網路層的 MySQL、網路 VPN 以及裝載 MySQL 的機器。

  • 他們執行資料庫移轉服務工具，然後執行下列動作：

    1. 建立以進階 SKU 為基礎的移轉專案。

      MySQL [概觀] 窗格的螢幕擷取畫面，其中顯示已成功建立移轉服務的訊息。

      MySQL 新增移轉專案窗格的螢幕擷取畫面。

    2. 新增來源 (內部部署資料庫)。

      移轉精靈 [新增來源詳細資料] 窗格的螢幕擷取畫面。

    3. 選取目標。

      [移轉精靈目標詳細資料] 窗格的螢幕擷取畫面。

    4. 選取要移轉的資料庫。

      [移轉精靈對應至目標資料庫] 窗格的螢幕擷取畫面。

    5. 設定進階設定。

      [移轉精靈移轉設定] 窗格的螢幕擷取畫面。

    6. 開始複寫，並解決任何錯誤。

      伺服器詳細資料窗格的螢幕擷取畫面。

    7. 執行最終完全移轉。

      osTicket 詳細資料窗格的螢幕擷取畫面。

      [完成完全移轉] 窗格的螢幕擷取畫面。

      移轉活動狀態資料表的螢幕擷取畫面。

    8. 恢復任何外部索引鍵和觸發程序。

    9. 修改應用程式以使用新的資料庫。

      移轉活動資料表的螢幕擷取畫面。

步驟 4b：遷移資料庫 (MySQL Workbench)

  1. Contoso 管理員檢查必要條件以及下載 MySQL Workbench。

  2. 他們會按照安裝指示，安裝適用於 Windows 的 MySQL Workbench。 安裝 MySQL Workbench 的機器，必須可由 osticketmysql VM 和 Azure 透過網際網路來存取。

  3. 在 MySQL Workbench 中，他們建立 osticketmysql 的 MySQL 連線。

    MySQL Workbench 連線詳細資料窗格的螢幕擷取畫面。

  4. 他們以 osticket 的形式將資料庫匯出至本機獨立檔案。

    MySQL Workbench 資料匯出窗格的螢幕擷取畫面。

  5. 在本機備份資料庫之後，管理員建立適用於 MySQL 的 Azure 資料庫執行個體連線。

    [MySQL Workbench 設定新連線] 窗格。

  6. 他們現在可以在適用於 MySQL 的 Azure 資料庫執行個體中，從該獨立檔案匯入 (還原) 資料庫。 系統會為執行個體建立新的結構描述 osticket。

    MySQL Workbench 資料匯入窗格的螢幕擷取畫面。

  7. 在還原資料之後，管理員可以使用 MySQL Workbench 來查詢資料。 資料會顯示在 Azure 入口網站中。

    Azure 入口網站的螢幕擷取畫面，其中顯示還原的資料。

    [MySQL 資料庫] 刀鋒視窗的螢幕擷取畫面，其中箭號指向 osTicket 資料庫。

  8. 管理員更新 Web 應用程式上的資料庫資訊。 在 MySQL 執行個體上，他們會開啟連接字串。

    MySQL 實例中 [連接字串] 連結的螢幕擷取畫面。

  9. 在連接字串清單中，他們選取 Web 應用程式設定，然後選取 [按一下以複製] 加以複製。

    MySQL 實例中 Web 應用程式設定的螢幕擷取畫面。

  10. 他們在記事本中開啟新檔案，並將字串貼到其中，然後更新字串以符合 osTicket 資料庫、MySQL 執行個體和認證設定。

    貼在記事本檔案中的連接字串螢幕擷取畫面。

  11. 他們可以透過 Azure 入口網站中 MySQL 執行個體的 [概觀] 窗格，來確認伺服器名稱和登入。

    資源群組窗格的螢幕擷取畫面，其中顯示伺服器名稱和伺服器管理員帳戶名稱。

步驟 5︰設定 GitHub

Contoso 管理員建立了新的私人 GitHub 存放庫，並設定連到適用於 MySQL 的 Azure 資料庫中 osTicket 資料庫的連線。 然後，他們會將 Web 應用程式載入 Azure App Service 中。

  1. 他們瀏覽至 osTicket 軟體公用 GitHub 存放庫，並將其派生至 Contoso GitHub 帳戶。

    GitHub 存放庫頁面的螢幕擷取畫面，其中醒目提示 [分支] 按鈕。

  2. 派生存放庫之後，他們瀏覽至該 include 資料夾，並選取 ost-config.php 檔案。

    GitHub 中 PHP 檔案的螢幕擷取畫面。

  3. 檔案會在瀏覽器中開啟，他們加以編輯。

    GitHub 中檔案編輯 (鉛筆) 圖示的螢幕擷取畫面。

  4. 在編輯器中，管理員更新資料庫詳細資料，特別是 DBHOST 和 DBUSER。

    GitHub 中檔案編輯窗格的螢幕擷取畫面。

  5. 他們認可變更。

    醒目提示編輯窗格上 [認可變更] 按鈕的螢幕擷取畫面。

  6. 對於每個 Web 應用程式 (osticket-eus2 和 osticket-cus)，他們在 Azure 入口網站中選取左窗格上的 [應用程式設定]，然後修改設定。

    醒目提示Azure 入口網站中 [應用程式設定] 連結的螢幕擷取畫面。

  7. 他們輸入名稱為 osticket 的連接字串，並將此字串從 [記事本] 複製到值區域中。 他們會選取字串旁邊下拉式清單中的 MySQL，並儲存設定。

    [連接字串] 窗格的螢幕擷取畫面，其中醒目提示 osTicket 連接字串。

步驟 6：設定 Web 應用程式

在移轉程序的最後一個步驟中，Contoso 管理員會使用 osTicket 網站來設定 Web 應用程式。

  1. 在主要 Web 應用程式 osticket-eus2 中，他們開啟 [部署選項]，然後將來源設定為 [GitHub]。

    [部署] 選項窗格的螢幕擷取畫面，其中已選取 GitHub 作為來源。

  2. 他們會選取部署選項。

    [部署] 選項窗格上選項詳細資料的螢幕擷取畫面。

  3. 設定這些選項之後，設定會在 Azure 入口網站中顯示為 [擱置]。

    [部署選項] 窗格的螢幕擷取畫面，其中顯示擱置的月臺狀態。

  4. 更新設定，且 osTicket Web 應用程式從 GitHub 載入至執行 Azure App Service 的 Docker 容器之後，站台就會顯示為作用中。

    [部署選項] 窗格的螢幕擷取畫面。

  5. 他們針對次要 Web 應用程式 osticket-cus 重複上述步驟。

  6. 設定好網站之後，即可透過流量管理員設定檔進行存取。 DNS 名稱是 osTicket 應用程式的新位置。 深入了解。

    [流量管理員設定檔] 窗格的螢幕擷取畫面，其中顯示 DNS 名稱。

  7. Contoso 想要使用容易記住的 DNS 名稱。 在 [新增資源記錄] 窗格中，他們建立別名、CNAME 和完整網域名稱，此名稱指向其網域控制站上 DNS 中的流量管理員名稱 osticket.contoso.com。

    [新增資源記錄] 窗格的螢幕擷取畫面，其中顯示別名名稱和流量管理員的指標。

  8. 他們設定 osticket-eus2 和 osticket-cus Web 應用程式以允許自訂主機名稱。

    [廣告主機名稱] 窗格的螢幕擷取畫面，其中醒目提示 [驗證] 按鈕。

設定自動調整

最後，Contoso 管理員為應用程式設定自動調整。 自動調整可確保當服務專員使用應用程式時，應用程式執行個體會根據商務需求而增加和減少。

  1. 在 App Service APP-SVP-EUS2 中，他們開啟 [縮放單位]。

  2. 他們以單一規則設定新的自動調整設定，以便在目前執行個體的 CPU 使用率超過 70% 達到 10 分鐘時，將執行個體計數加一。

    第一個區域的自動調整設定頁面螢幕擷取畫面。

  3. 他們在 APP-SVP-CUS 上設定相同的設定，以確保應用程式容錯移轉至次要區域時會套用相同的行為。 唯一的差異在於他們將預設執行個體設定為 1，因為這僅適用於容錯移轉。

    第二個區域的自動調整設定頁面螢幕擷取畫面。

移轉之後進行清除

移轉完成後，osTicket 應用程式會重構，以使用私人 GitHub 存放庫透過持續傳遞方式在 Azure App Service Web 應用程式中執行。 應用程式會在兩個區域中執行，以提高復原能力。 在移轉到 PaaS 平台之後，osTicket 資料庫會在適用於 MySQL 的 Azure 資料庫中執行。

為了在移轉後進行清除，Contoso 執行下列動作：

  • 他們從 vCenter 清查中移除 VMware VM。
  • 他們會從本機備份作業中移除內部部署 VM。
  • 他們更新內部文件以顯示新的位置和 IP 位址。
  • 他們檢閱與內部部署 VM 互動的任何資源，並更新任何相關的設定或文件，以反映新的設定。
  • 他們重新設定監視而指向 osticket.trafficmanager.net URL，以追蹤應用程式是否啟動並執行中。

檢閱部署

應用程式正在執行中，Contoso 必須能發揮一切功能並保護其新的基礎結構。

安全性

Contoso 安全性小組會檢查應用程式，以判斷是否有安全性問題。 他們發現 osTicket 應用程式與 MySQL 資料庫執行個體之間的通訊並未針對 SSL 進行設定。 他們必須這麼做，才能確保資料庫流量不會遭到駭客入侵。 深入了解。

備份

  • osTicket Web 應用程式不包含狀態資料，因此不需要進行備份。
  • Contoso 小組不需要設定資料庫的備份。 適用於 MySQL 的 Azure 資料庫會自動建立伺服器備份和存放區。 小組選擇對資料庫使用異地備援，因此資料庫可復原並已準備好用於生產。 備份可以用來將伺服器還原至某個時間點。 深入了解。

授權和成本最佳化

  • PaaS 部署沒有任何授權問題。
  • Contoso 將使用 Azure 成本管理 + 計費，確保維持在 IT 領導階層所建立的預算內。