程式為什麼不會動?程式人告訴你的為什麼中,第一名始終是「在我的機器明明就可以動啊!」機器是指什麼呢?實體設備?作業系統?執行環境?開發環境?環境變數?外部資源?

其實都有可能,問題看來似乎只有一個,也就是想辦法讓每個開發者的環境都相同,實際上,卻有著各種不同的考量與作法。

為了有一致的環境,有些傳統方式使用像是多重開機、還原卡甚至抽換硬碟(USB行動碟)等,每個人會擁有完全獨立的實體機器、相同的作業系統、應用程式設定等初始環境,都是這些方式的優點,因而至今仍特別容易出現在一些教育訓練場合,然而,這類方式需要實體機器、專人部署整個環境,如果弄髒了環境,無論是重灌(重新部署)或回復至還原點都很麻煩等,缺點也是顯而易見,對於今日複雜的開發環境需求來說,已不適用。

有些語言本身的開發工具箱提供了機制,可以達到一定程度的開發環境隔離。

比方說,Python可以設定各種環境變數,建立各自獨立的程式庫相依環境,為了方便建立這類環境,也有Virtualenv這類工具可以使用,使用Pythonbrew,則可以協助安裝多個Python版本並迅速切換。

若是Java,JVM提供了專有的虛擬環境,啟動的JVM本身就是一個隔離環境,整合開發環境也可以提供不同的JDK版本,或CLASSPATH配置。雖然這類語言提供一定程度的隔離機制,不過,開發除了語言本身環境,還牽涉到不少外部資源管理問題,對於這方面,語言開發工具本身,就無法著墨了。

這個時代電腦的運算能力,其實往往超過使用者實際的需求,多數情況下,開發者需要的是獨立、隔離的運算資源,而不是實體機器。虛擬機器可以提供抽象層,讓客端作業系統以為擁有整臺實體機器,開發者可以在各個虛擬機器安裝、設定各自獨立的開發環境,也可在其中安裝完整的外部資源,另一開發者只要拿到映像檔,就可擁有相同環境。

而且,環境如果弄髒了,只要重新設定原有的虛擬映像檔等是其優點,因而開發者對於使用VirtualBox、VMWare等虛擬機器軟體,並不陌生。在雲端運算概念下,實際也有很多服務商提供虛擬機器服務,不過虛擬機器本身肥大,在虛擬機器中各自針對不同時期或不同需求,配置各自完整的開發環境,會是個很沉重的負擔。

這些傳統開發環境建立的方式,各有其優缺點,也有些相對較新的工具可以取而代之,在這之前,先觀察使用這些傳統開發環境建立的目的,可以知道,一致的開發環境需求其實主要有獨立性(隔離性)、易於組態、易於部署、可攜(Portable)、可版本控制、輕量等需求。

輕量級虛擬機工具Vagrant

對於致力於開發與營運(Development and Operations, DevOps)之間溝通、協調整合的公司來說,身處其下的開發者對於Vagrant應不陌生。從Vagrant創建者Mitchell Hashimoto在〈The Hardest, Most Rewarding Job I've Ever Had〉這篇談到Vagrant誕生的故事,可以知道Vagrant的主要訴求。

由於他當時受雇於一間使用Ruby的公司,每6到8周就可能產生新的專案,要為每個新專案設定新開發環境,而每個新環境與先前專案只有些微不同,使得Hashimoto逐漸對這個過程感到洩氣,為了維護一個舊專案,又得將環境回復至某個狀態,因此更令人生氣。那簡直是一場惡夢。

就表面來看,Vagrant以VirtualBox為基礎(現在也支援VMWare),也是啟動了虛擬機器,開發者可以在其中安裝設定開發環境,如果沒有Box的概念,確實Vagrant跟虛擬機器軟體就沒什麼不同了,開發者可以將開發環境包裝為Box,放在官方或第三方Box伺服器供人下載,Box是以虛擬機器映像檔為基礎,你在虛擬機器中做的變更,不會影響Box,你可以獨立地讓虛擬機器關機、休眠或銷毀虛擬機器,也可以為不同的開發環境需求來包裝不同的Box,搭配一個文字檔案Vagrantfile管理使用的Box,以及配置虛擬機器的資源(記憶體、連接埠、IP等)。

而常見到的做法是,Vagrantfile所在的目錄就是專案目錄,我們可以連同Vagrantfile一同做版本控制,讓專案與環境有著一致的版本控制記錄。

作為一名開發者,有時頭痛的並不是怎麼安裝開發工具箱、程式庫、整合開發環境,而是資料庫、Web伺服器等各種外部資源,畢竟不是每個開發者都能熟悉各種外部資源如何正確地安裝,由於Vagrant實際上啟動了虛擬機器,每個虛擬機器就是獨立的,實際上就可以管理這些外部資源。

在ingramchen的〈導入Vagrant做開發配置〉中,就談到了為何Java生態圈不需要虛擬機器來做開發環境隔離,以及如何使用Vagrant與Ansible自動化工具來管理外部資源。

提供執行環境的Docker

在虛擬化方面,近來頻頻躍上新聞版面的Docker受到極大關注。2013年3月Docker初次釋出的15個月之後,2014年6月就釋出1.0版本,這期間吸引了眾多使用者的注意,Google也宣布擁抱Docker,發表容器(Container)管理工具Kubernetes,並宣布微軟、紅帽、IBM等廠商也將加入該工具的專案,使得Docker從6月以來,就不斷成為鎂光燈追逐焦點。

虛擬機器透過抽象層而以為擁有整個實體機器,安裝了整個作業系統後,因而運行時使用的是各個客端作業系統核心;但Docker不是虛擬機器,它只提供應用程式執行時應有的相關資源,映像檔不需要包括整個作業系統,只需要包括小部份系統元件,不同的環境需求可以基於既有映像檔疊加,Docker從映像檔建立容器(應用程式所需環境),每個容器使用主作業系統的核心,因此,無論是映像檔或是容器,相較於虛擬機器來說,都極為輕量級。

容器技術上來說,就是一個行程(Process),容器的變更不影響映像檔,容器的狀態可以提交(Commit)成為映像檔,可以搭配Dockerfile自動建構與提交,映像檔可以公開在Docker hub供人下載,可以形成自給自足的資源,這使得Docker的運作上,就像將應用程式必要的資源封裝為一個個軟體貨櫃,便於快速部署。

因此,就開發環境的需求來說,Docker與Vagrant在隔離性、易於組態與部署、可攜、版本控制等方面,功能上有些重疊,這使得兩者經常被視為競爭對象而受到討論,Vagrant普遍被談及的缺點是不夠輕量級,而Docker經常被提及的問題是,lxc只能運行在Linux上,因此在Windows上,還是得透過虛擬機器才能使用,像是boot2docker,或者是透過Vagrant來安裝Docker,在穩定與成熟度上,相對來說,較新的Docker也是被檢討的重點。

重視自己的開發環境需求

對實際去思考過自身開發環境需求,以及Vagrant與Docker兩者差異性的人來說,有不少人其實也將Vagrant與Docker搭配在一起使用,不過,Vagrant與Docker在功能上有重疊是無庸置疑的,兩者間勢必存在競爭關係。就像stackoverflow論壇網站上,有人提出〈Should I use Vagrant or Docker.io for creating an isolated environment?〉的發問,分別引來了Vagrant與Docker創建者Solomon Hykes的回答,而這兩人的回答,實際上仍存在針鋒相對的味道。

無論原創建者的想法是如何,是存在競爭還是互補關係,使用者最終會決定生態圈,身為使用者應思考的重點,並不在於最後選哪邊站,而在於是否實際想過使用上所面臨的狀況,了解到面對現有開發環境的管理,有哪些實際需求,因而才能進一步且有依據地尋找與評估適用的工具,若真如此,就算最後只是選擇傳統的虛擬機器也不為過,怕的是只會一而再、再而三地,像在做手工藝般地與開發環境奮戰,然後持續地洩氣、沮喪,而後對現狀呈現麻木狀態。

作者簡介


Advertisement

更多 iThome相關內容