使用 WebSphere CloudBurst 進行應用程式環境遷移(一)

CloudSpace發表於2010-08-20
Dustin Amrhein, 軟體工程師, IBM

簡介:  在本教程中,作者展示瞭如何使用 WebSphere® CloudBurst 構建可用於表示應用程式和應用程式基礎設施的配置的模式。文中還介紹了在應用程式環境經歷 4 個生命週期階段 — 開發、測試、QA 和生產的遷移時,如何使用這些模式對其進行統一部署。教程提供了一個完整的步進式示例,教您如何使用模式來處理變更拓撲、底層平臺架構和配置屬性。

前言

關於本教程

在本教程中,作者展示瞭如何使用 WebSphere® CloudBurst 構建可用於表示應用程式和應用程式基礎設施的配置的模式。文中還介紹了在應用程式環境經歷 4 個生命週期階段 — 開發、測試、QA 和生產的遷移時,如何使用這些模式對其進行統一部署。教程提供了一個完整的步進式示例,教您如何使用模式來處理變更拓撲、底層平臺架構和配置屬性。

本教程的目標是:

  • 向您展示如何使用 CloudBurst 構建可表示應用程式/應用程式基礎設施的配置的模式。
  • 向您展示如何使用這些模式統一部署應用程式環境,不管經歷的生命週期階段是什麼(開發、測試、QA 和生產)。
  • 使您熟悉這些模式型別,從而在類似的任務中使用它們。

如果擁有對 WebSphere CloudBurst Appliance、模式建立和雲端計算應用開發的一些基礎知識和經驗,本文中的資訊會對開發人員更有意義。但是,由於本教程既有為輔助雲應用程式/應用程式基礎設施遷移而構建模式的具體步驟,也包含這些任務中涉及的概念。沒有軟體產品相關知識的人也可以從中受益。

為吸收本教程中我們呈現的概念,您需要的是一個好的開發人員頭腦。不過,如果您希望複製這些練習,就需要獲准訪問 WebSphere CloudBurst Appliance,以建立目錄內容、建立模式和部署模式。

背景知識

為何定義一致的配置?

組織們面臨著將應用程式和相關基礎設施部署到不同環境中的挑戰。例如,大部分應用程式經歷某些升遷鏈,包括將應用程式及其依賴的基礎設施從開發移動到測試,最後到生產。在每一個階段安裝和配置應用程式和應用程式基礎設施 — 這個過程通常很耗時且可能需要手動操作。

更重要的是,每次重新安裝和配置應用程式及其相關基礎設施來支援一個遷移時,都有可能引入 bugs,尤其會有未知或意外的變更新增到應用程式或其平臺的配置上。在有這些型別的 bugs 引入時,通常很難找到原因,幾乎不可能檢測到。這就導致了常見的現象:“它以前有效;發生了什麼變化?”

IBM WebSphere CloudBurst Appliance 能夠為您的基礎設施和應用程式定義一致的配置。WebSphere CloudBurst 也支援將它們從一個環境移動到另一環境:

  • 您可以使用該裝置構建捕獲應用程式基礎設施、應用程式和配置的模式
  • 這些模式儲存在裝置上,且被反覆部署,實現應用程式環境的一致性。
  • 引數化模式,來為正在部署的階段塑造應用程式環境。

WebSphere CloudBurst 對映像和模式的獨特結合加速了部署,現在是以分鐘度量,而非天數或週數。結果是一個完全配置的、可重複的應用程式環境,隨時可供使用。

大部分應用程式經歷多個階段,包括開發、測試和生產。如果每個環境是一樣的,實現一致性和可重複部署可能不是那麼難;不過,在大多數 IT 企業中,可用硬體、軟體配置和在用後端資源有區別。這就導致生命週期每個階段的配置發生變化,因而不可能直接複製一個配置,且難以根據引入問題的不良變更區分和跟蹤所需的配置變更。

讓我們來看一下應用程式及其支撐基礎設施在生命週期中可能經歷的變更公共集,並討論如何使用 WebSphere CloudBurst 功能簡化對這些變更的管理,從而提供可重複部署。一些典型變更包括:

  • 不同的基礎設施拓撲。
  • 不同的硬體平臺架構。
  • 不同的配置設定。
  • 不同的資源。

不同的基礎設施拓撲

儘管虛擬化使得複製多節點生產拓撲用於部署和測試更加容易,無需太多耗資,但很多人仍然喜歡生命週期較早階段的簡單拓撲。例如,WebSphere 開發環境通常包括一個虛擬機器,其中包含部署管理器、Web 伺服器和自定義節點。在應用程式經歷不同生命週期階段時,相同的基礎設施元件仍然存在;但是,後面的階段在多個虛擬機器之間分配這些元件。

下圖顯示了一體化開發環境移動到一個多節點測試拓撲的一個典型進度,其中應用程式伺服器節點被分離並組合成一個叢集,之後將 Web 伺服器分成一個 DMZ,以作最終的質量保證和生產之用。


CloudBurst 中每個獨有拓撲對映到一個模式
CloudBurst 中每個獨有拓撲對映到一個模式

在 WebSphere CloudBurst 中,每個獨有拓撲對映到一個模式。因此,正如您在示例中會看到的,圖中的生命週期有三個獨特的模式。模式建立過程複製前面的模式,以幫助維護任何配置資訊,特別是任何獨特指令碼。

不同的硬體拓撲

另一個生命週期變更可能是所選擇的硬體架構平臺。由於各種原因,WebSphere 開發有時在一個不同於生產的平臺上,或有多個開發、測試和生產平臺在使用中。

例如,上一個圖顯示了 VMware 上的開發和測試環境,以及 PowerVM 上的 QA 和生產環境。WebSphere CloudBurst 拓撲定義與平臺無關,允許將同一模式定義部署到不同平臺。

當然,映像是平臺特有的;因此,正如場景展示的,要將同一模式從 VMware 移動到 PowerVM,您只要生成一個模式副本,並選擇與新平臺對應的映像。在為另一個平臺複製模式時,您需要對所開發的任何平臺特有的指令碼做出解釋,並進行必要的更改。

不同的配置設定

配置設定也需要隨不同的生命週期部署而改變。虛擬化的目標之一 — 複製一個虛擬機器並重用它 — 遇到一個挑戰,即相同的副本存在衝突。為避免衝突,最小值、名稱、密碼和其他設定通常需要 變更。

WebSphere CloudBurst 模式提供引數,允許在啟動虛擬機器時進行配置更改。在模式建立過程中,您可以將這些值鎖定到模式中,或允許在部署時修改它們。例如,如果您希望有一個具體的單元名,您可以將該值鎖定到模式中;如果您希望使用帶不同單元名的同一模式,您可以將其留給部署時規範。

不同的資源

大多數 WebSphere 應用程式與某些物件(比如資料庫、目錄伺服器等)互動,且這些資源的位置在開發、測試和生產環境中可能不同。例如,質量保證環境極可能包含一些測試資料庫,從生產資料中建模和複製。WebSphere CloudBurst 指令碼允許您定義引數。向一個模式新增一個指令碼會自動公開引數,將其作為模式或部署配置的一部分。指令碼引數提供大量靈活性來保持模式的公共性,同時支援切換資源位置。

在部署指令碼時,您可以為整個生命週期中變更的資源連線新增引數。WebSphere CloudBurst 自動向模式新增引數,您可以在定義模式或維護模式靈活性時選擇指定引數值,方法是將引數值規範留待部署時。例如,要重用不同資源的同一模式,只需將位置設定為一個指令碼引數,然後在部署時指定該值。

在接下來的示例場景中,我們為資料庫位置和應用程式位置同時使用該方法。該方法對於任何特定於應用程式的配置設定也很有用。

樣例場景

現在,我們將探討一個使用 WebSphere CloudBurst 實現這些概念的樣例場景。在該例中,應用程式基礎設施將是一個叢集化的 WebSphere Application Server 環境。環境包括以下節點和應用程式伺服器:

  • 一個部署管理器節點。
  • 兩個新增到部署管理器的自定義節點。每個節點包含一個應用程式伺服器例項和屬於一個叢集的應用程式伺服器。
  • 一個 IBM HTTP Server 節點。

除了基本的 WebSphere Application Server 拓撲之外,我們還有一個 Java™ 2 平臺,安裝在應用程式伺服器叢集上的 Enterprise Edition (J2EE) 應用程式(我們稱之為 Account Management)。該應用程式對一個外部 IBM DB2® 資料庫例項有一個依賴性,且對該依賴性的配置在不同的設定中也有所不同。

圖 1 展示了我們剛才描述的應用程式環境。


圖 1. 示例應用程式環境
示例應用程式環境

在我們的場景中,我們將向您展示如何使用 WebSphere CloudBurst 在從開發、測試、質量保證到最後的生產設定移動時建立和管理該環境。這包括以下步驟:

  1. 建立必要的 WebSphere CloudBurst 指令碼包。
  2. 建立用於開發設定的初始 WebSphere CloudBurst 模式。
  3. 將應用程式環境遷移和部署到一個測試設定。
  4. 將應用程式環境遷移和部署到一個 QA 設定。
  5. 將應用程式環境遷移和部署到一個生產設定。

在每個遷移和隨後的部署期間,我們將闡釋如何輕鬆地對設定進行微小更改,而不影響最終應用程式環境的整體完整性。這些變更將包括對 WebSphere Application Server 拓撲的更改、對 DB2 整合的配置更改,甚至對底層作業系統平臺的更改。

請注意,如果您試圖複製本文剩餘部分採用的步驟,就需要獲准訪問一個 WebSphere CloudBurst Appliance,以建立目錄內容、建立模式和部署模式。

建立指令碼包

在 WebSphere CloudBurst 中,指令碼包 是您向 WebSphere 中介軟體應用程式環境提供自定義配置經由的機制。一個指令碼包由一個二進位制存檔檔案和配置設定組成,前者包含可執行和支撐工件,後者告訴 WebSphere CloudBurst 如何呼叫指令碼包。

對於本例,我們將建立兩個不同的指令碼包:

  • 其中一個會將 Account Management 應用程式安裝到 WebSphere Application Server 環境中。
  • 另一個會配置一個 DB2 資料來源,以供應用程式使用。

為建立安裝和配置 Account Management 應用程式所需的指令碼包,首先單擊 WebSphere CloudBurst Web 控制檯中頂部工具欄上的 Catalog -> Script. Packages 連結。這會將您帶到 WebSphere CloudBurst 目錄的指令碼包部分。單擊左上角的綠十字建立新指令碼包。


圖 2. 建立新指令碼包
建立新指令碼包

現在上傳這個指令碼包的二進位制存檔檔案。這個指令碼包的存檔檔案包含一個 wsadmin 指令碼,它從指定位置檢索 Account Management 並將其安裝到 WebSphere Application Server 環境中。

要上傳存檔檔案,使用 Account Management Application 指令碼包細節頁面上 Script. package files 欄位中的檔案上傳對話方塊。上傳存檔檔案之後,您要提供有關指令碼包的其他資訊。


圖 3. Account Management Application 指令碼包
Account Management Application 指令碼包

注意,您在 Environment 部分定義了一個名為 APPLICATION_URL 的變數:這將允許您在部署時為包含指令碼包的模式指定該變數的值。指定值可用於安裝指令碼,允許指令碼從指定位置檢索應用程式二進位制檔案。

除了提供變數之外,您還要告知 WebSphere CloudBurst 如何呼叫您的指令碼包。特別地,您要告訴 WebSphere CloudBurst 使用包含在 WebSphere Application Server 安裝中的 wsadmin 工具,以呼叫包含在指令碼包存檔檔案中的 installApp.jy 指令碼。根據 Executes 欄位,WebSphere CloudBurst 將自動在接近模式部署時呼叫該指令碼,也就是說,部署過程的結果將會是一個包含 Account Management 應用程式的 WebSphere Application Server 環境。

您還需要建立一個指令碼包來在 WebSphere Application Server 環境中配置 DB2 資料來源。Account Management 應用程式將使用該資料來源與一個 DB2 例項進行互動。將該指令碼包命名為 “Create DB2 data source”。它的存檔檔案包含一個 shell 指令碼,該指令碼協調多個 wsadmin 指令碼的執行,從而在 WebSphere Application Server 環境中配置合適的資源。


圖 4. 用於建立一個 DB2 資料來源的指令碼包
用於建立一個 DB2 資料來源的指令碼包

值得一提的是,有多個環境變數允許您在部署時為包含該指令碼包的模式提供資料來源配置資訊。這包括資料來源名稱、資料庫名稱和資料庫位置等資訊。通過採用這種方法,您可以使用同一指令碼包在不同的環境(開發、測試和生產)中為大量不同的 DB2 資料庫例項配置 DB2 資料來源。

在定義了兩個必要的指令碼包之後,您可以使用這些資源構建模式。

(未完)

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14789789/viewspace-671482/,如需轉載,請註明出處,否則將追究法律責任。

相關文章