簡體   English   中英

是否可以“構建”(“編譯”)Docker鏡像以不需要Docker?

[英]Can Docker images be “built” (“compiled”) to not require Docker?

我在Docker上進行實驗和開發的經驗非常少,而在登台和部署方面,Docker的經驗則為零,因此請原諒任何聽起來很幼稚的事情。

主要問題

假設我有一個Docker映像(甚至是由幾個映像和服務組成的docker-compose.yml文件),在運行時,它會為我的應用設置環境並運行我的應用-允許在公共開放端口上進行連接並響應要求。

為了在生產環境中運行此映像(並因此在生產環境中運行我的應用程序),生產服務器必須安裝了Docker。 這感覺像是違反了十二要素應用程序的設計。 特別是當您考慮端口綁定原則時:

十二要素應用程序完全獨立

就像應用程序不應該依賴Apache或nginx來安裝一樣,應用程序也不應該依賴Docker嗎?

這使我想知道是否有辦法將Docker運行時和映像“打包”,“構建”或以其他方式“編譯”為可執行二進制文件。 可以部署到任何服務器並可以作為單個進程運行的東西,而無需先安裝Docker。

現在,可能我只是在考慮這完全錯誤。 因此,我在下面詳細說明了所關注的問題和細節

是什么導致了這個

我有一個以前使用Cloud9開發的Web應用程序項目。 當我將該項目推向生產環境時,我會通過SSH手動登錄生產服務器並執行git pullcomposer updatenpm installgulp 我有點麻煩,但對於規模非常小的,我在這方面的工作已經足夠了,這是一個很多比通過FTP上傳我的所有依賴更好的地獄

但是,我偶爾會遇到外部依賴項帶來的挑戰。 某些東西在開發中工作正常,然后將其推向生產環境時,我意識到生產服務器具有過時的MySQL版本。 或生產服務器上安裝的pngquant版本有錯誤。 或者服務器上的nginx配置與開發中的nginx配置不完全匹配,並且在路由格式錯誤的請求時會導致一些邊緣情況。

今天,當我嘗試在CodeAnywhere而不是Cloud9中加載項目時,所有這些問題一下子解決了。 我必須確保:

  • PHP版本已更新
  • NodeJS已更新
  • NPM已更新
  • cURL已安裝
  • 已安裝所有必需的PHP擴展
  • 安裝了幾個GNU庫
  • 等等

我花了幾個小時試圖使此代碼運行-這是編寫的代碼

有所有這些問題使我想起了十二要素應用程序的設計。 因此,我跳到該網站,並做了一些思考來弄清楚我做錯了什么。

注意:我不只是單獨開發然后直接部署到生產中。 我實際上是在BitBucket中設置了這個項目,我使用票務系統跟蹤更改,為每個票證創建了一個分支,並且在合並到master之前在臨時環境中檢出了分支。 因此,我創建了一個相當強大的系統來管理更改,以避免錯誤滲入生產環境並允許進行敏捷開發。 但是,在登台生產中簽出分支時,它是相同的手動操作: git pullcomposer updatenpm installgulp

我喜歡Docker的什么

在源代碼控制的配置文件中定義我的工作環境的能力將消除我的大部分問題。 我再也不需要確保PHP是最新的,確保NodeJS是最新的,確保已安裝cURL等。如果Docker映像具有所有依賴項,則在階段或生產中部署時,它仍將具有那些依賴項。 發展的各個階段之間的環境的一致性會讓我的生活輕松了許多

另外,我還沒有玩過任何這種高級功能,但是我想了解到,使用Docker可以很容易地設置自動化部署。 如果我可以單擊BitBucket中的一個分支,然后單擊“發送到暫存”,然后在一分鍾后將其部署並准備進行測試-這樣可以每周節省我數小時的時間。 如果我可以類似地將代碼合並到母版中時將代碼自動部署到生產中,那不僅可以節省我的時間,而且可以避免完成的功能在BitBucket中失效並且永遠不會出現在客戶面前的風險。

最后,這最終可能是一個有爭議的話題,我將了解Docker使綠色/藍色部署更加容易。 目前,當我對生產進行新更改時,生產服務器會暫時脫機。 通常只持續15到20秒,但一次是一個小時。 在這15到20秒的窗口中,我正在運行composer updatenpm installgulp 前兩個命令通常不需要執行任何操作(因為我的依賴關系不會經常更改),並且gulp通常在15秒內完成。 但是,當依賴關系確實發生變化或存在較大問題(例如需要升級MySQL)時,該站點可能會關閉一整小時。 如果我可以緩慢而從容地部署到輔助生產服務器,然后在驗證運行正常的情況下以毫秒為單位切換該開關,則這將意味着減少停機時間並帶來更多客戶滿意。

當然,最后一個可能是有爭議的,因為我目前沒有使用“構建”步驟(十二要素應用程序的另一部分),並且所有這些步驟都應該是“構建”階段的一部分-而不是“部署”階段。

我不喜歡Docker的地方

它是又一種學習工具 為了了解和開發我的應用,您已經需要了解:

  • 的PHP
  • 作曲家
  • Symfony
  • 拉拉韋爾
  • 節點JS
  • NPM
  • 古爾普
  • 引導程序
  • VueJS
  • (可能我現在想不出的許多其他事情)

如果將“ Docker”添加到該列表中,則意味着如果我將其交付給其他開發人員,則該項目將很難培訓某個人。 我想要更少的依賴關系,而不是更多。

另外,Docker並不是我所知道的任何默認操作系統。 因此,這與cURL不同,盡管從技術上講它是第三方依賴項,但通常可以期望人們擁有它。 相反,它是一個完整的野獸,必須單獨安裝。

前一個問題我無法真正解決。 如果我選擇使用Docker,則意味着向該應用程序的工具箱中添加了一個工具。 但是,如果可以將Docker映像以某種方式編譯為獨立的二進制文件,則可以避免后一個問題。

嚴格來說,您可以從沒有docker的docker鏡像運行容器。 Docker映像是一種眾所周知的格式。 有關此規范的更多詳細信息,請參見https://github.com/opencontainers/image-spec OCI映像的運行時有多種實現。 Docker本身實際上並不運行容器,該任務已外包給容器。

但是,映像附帶文件系統(也稱為一堆tar文件),但是容器也希望使用命名空間來隔離應用程序。 您需要某種運行時來實現這一點。 容器不僅是打包應用程序的一種方法,而且是一種隔離運行它們的方法,嘗試將它們拆開將比docker本身做更多的工作,並且需要學習的東西更大。

Docker映像確實確實需要在計算機上安裝docker,但這是一個小得多的問題,而要設置您提到的所有其他依賴項。

雖然可能可以創建某種自包含的docker映像,但是它可能不如docker映像那樣可移植,因為二進制文件將依賴於os。

還應考慮到,如果您使用雲提供商,則它們可以“直接在雲上”部署docker映像-也就是說,您不必管理底層服務器

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM