大家好！
我真的很想直入主題，但更正確的說法是說我的故事：
條目
我是一名程式設計師，擁有在伺服器上開發前端單頁應用程式、scala/java 和 Nodejs 的經驗。
在相當長的一段時間內（肯定是一兩年或三年），我認為 Docker 是天賜之物，總的來說是一個非常酷的工具，絕對每個開發人員都應該能夠使用它。 由此可見，每個開發人員都應該在他們的本機電腦上安裝 Docker。 我的意見呢，看看同一天發布的職缺…。 每一秒都會提到 docker，如果你擁有它，這將是你的競爭優勢😉
在路上，我遇到了很多人，他們對 Docker 及其生態系統有著不同的態度。 有人說，這是一個方便的東西，保證了跨平台功能。 第二個不明白為什麼他們應該在容器中運行以及從中獲得什麼利潤，第三個根本不關心也不打擾（他們只是寫了代碼就回家了 - 我羨慕他們，由方式 ：）
使用理由
我為什麼要使用docker？ 大概有以下幾個原因：
- 資料庫啟動，99%的應用程式使用它們
- 啟動 nginx 進行前端分發並代理到後端
- 你可以將應用程式打包在docker映像中，這樣我的應用程式將在任何docker存在的地方運行，分發問題立即解決
- 開箱即用的服務發現，可以創建微服務，每個容器（連接到公共網路）都可以透過別名輕鬆到達另一個容器，非常方便
- 創建一個容器並在其中“玩”很有趣。
我一直不喜歡 docker 的地方：
- 為了讓我的應用程式正常運作，我需要在伺服器上安裝 Docker。 如果我的應用程式在 jre 或 nodejs 上運行並且它們的環境已經在伺服器上，為什麼我需要這個？
- 如果我想在遠端伺服器上執行我的（私人）本地建置的映像，那麼我需要我自己的docker 儲存庫，我需要註冊表在某個地方工作，並且我還需要配置https，因為docker cli 只能透過https 運行。 哦該死...當然，還有一些選項可以通過以下方式將圖像保存在本地
docker save然後透過 scp 發送影像...但這需要很多身體動作。 此外，在您自己的儲存庫出現之前，它看起來像是一個「拐杖」解決方案 docker-compose。 只需要運行容器即可。 就這樣。 他無能為力。Docker-compose有很多版本的文件，有自己的文法。 無論它多麼聲明，我都不想閱讀他們的文檔。 我在其他地方不需要它。- 在團隊中工作時，大多數人寫Dockerfile 的方式很歪，不明白它是如何緩存的，將自己需要和不需要的所有內容添加到鏡像中，繼承Dockerhub 或私有存儲庫中沒有的鏡像，創建一些
docker-compose帶有資料庫的文件，並且沒有任何內容保留。 與此同時，開發人員自豪地宣稱 Docker 很酷，一切都在本地為他們工作，HR 重要地在空缺中寫道：“我們使用 Docker，我們需要有這樣工作經驗的候選人。” - 我經常被在 Docker 中提升一切的想法所困擾：postgresql、kafka、redis。 遺憾的是，並非所有東西都可以在容器中運行，也不是所有東西都易於配置和運行。 這是由第三方開發人員支援的，而不是由供應商本身支援的。 順便說一句，問題立即出現：供應商不擔心在 Docker 中維護他們的產品，這是為什麼，也許他們知道一些事情？
- 關於容器資料的持久性的問題總是會出現。 然後你會想，我應該掛載主機目錄還是建立一個 docker 磁碟區或建立一個資料容器（現在是這樣）
deprecated？ 如果我掛載目錄，那麼我需要確保容器中使用者的uid和gid與啟動容器的使用者的id匹配，否則容器建立的檔案將以root權限建立。 如果我使用volume那麼數據將簡單地在某些地方創建/usr/*uid 和 gid 的情況與第一種情況相同。 如果您要啟動第三方元件，則需要閱讀文件並尋找以下問題的答案：“元件在哪些容器目錄中寫入檔案？”
我一直不喜歡這樣一個事實：我必須花很長時間修改 Docker 在初始階段：我弄清楚如何啟動容器、從什麼映像啟動、製作了包含長 Docker 命令別名的 Makefile。 我討厭 docker-compose，因為我不想學習另一個 docker 生態系統中的工具。 和 docker-compose up 這讓我很困擾，尤其是如果他們仍然在那裡見面的話 build 結構，而不是已經組裝好的圖像。 我真正想要的只是有效率、快速地製造產品。 但我不知道如何使用 docker。
介紹 Ansible
最近（三個月前），我在一個 DevOps 團隊中工作，幾乎每個成員都對 Docker 持消極態度。 原因：
- docker 規則 iptables（儘管您可以在 daemon.json 中停用它）
- docker 有問題，我們不會在生產中運行它
- 如果 docker 守護程式崩潰，那麼所有具有基礎架構的容器都會相應崩潰
- 不需要碼頭工人
- 如果有 Ansible 和虛擬機，為什麼還要使用 docker
在同一份工作中，我熟悉了另一個工具—Ansible。 我聽說過一次，但我沒有嘗試編寫自己的劇本。 現在我開始寫我的任務，然後我的願景完全改變了！ 因為我意識到：Ansible 具有用於運行相同 docker 容器、映像建置、網路等的模組，容器不僅可以在本地運行，還可以在遠端伺服器上運行！ 我高興極了 - 我找到了一個普通工具並扔掉了我的 Makefile 和 docker-compose 文件，它們被 yaml 任務替換了。 透過使用類似的結構減少了程式碼 loop, when等等。
用於運行資料庫等第三方元件的 Docker
我最近開始熟悉 ssh 隧道。 事實證明，將遠端伺服器的連接埠「轉送」到本機連接埠是非常容易的。 遠端伺服器可以是雲端中的計算機，也可以是 VirtualBox 中執行的虛擬機器。 如果我的同事或我需要資料庫（或其他第三方元件），我們可以簡單地使用該元件啟動伺服器，並在不需要伺服器時將其關閉。 連接埠轉送與在 Docker 容器中執行的資料庫具有相同的效果。
此命令將我的本機連接埠轉送到執行 postgresql 的遠端伺服器：
ssh -L 9000:本地主機:5432 [電子郵件保護]
使用遠端伺服器解決了團隊開發的問題。 這樣的伺服器可以同時由多個開發人員使用；他們不需要能夠設定 postgresql、了解 Docker 和其他複雜的知識。 在遠端伺服器上，如果安裝特定版本有困難，您可以在 Docker 本身中安裝相同的資料庫。 開發人員所需要的只是提供 ssh 存取權限！
我最近讀到，SSH 隧道是常規 VPN 的有限功能！ 您只需安裝 OpenVPN 或其他 VPN 實作、設定基礎架構並將其提供給開發人員使用即可。 這太酷了！
幸運的是，AWS、GoogleCloud 和其他公司為您提供一年的免費使用權，所以請使用它們！ 如果您在不使用時將其關閉，它們會很便宜。 我一直想知道為什麼我需要像 gcloud 這樣的遠端伺服器，看來我找到了它們。
作為本機虛擬機，您可以使用相同的 Alpine，它在 docker 容器中積極使用。 好吧，或者其他一些輕量級發行版可以使機器啟動更快。
底線：您可以而且應該在遠端伺服器或 virtualbox 中運行資料庫和其他基礎架構。 我不需要 docker 來實現這些目的。
關於 docker 映像和分發的一些知識
我已經寫了 我想表達的是，使用 docker 映像並不能提供任何保證。 僅在建立 Docker 容器時才需要 Docker 映像。 如果您要升級到 docker 映像，那麼您將升級為使用 docker 容器，並且您將只使用它們。
您是否見過軟體開發人員僅在 docker 映像中移植其產品的地方？
大多數產品的結果是針對特定平台的二進位檔案；它們只是添加到從所需平台繼承的 docker 映像中。 你有沒有想過為什麼 dockerhub 上有這麼多類似的映像？ 以nginx為例，你會看到100500張來自不同人的圖像。 這些人本身並沒有開發 nginx，他們只是將官方 nginx 添加到他們的 docker 映像中，並使用自己的配置對其進行調味，以方便啟動容器。
一般來說，你可以簡單地將它儲存在tgz 中，如果有人需要在docker 中運行它，那麼讓他們將tgz 添加到Dockerfile 中，從所需的環境繼承並創建額外的包，這些包不會改變tgz 中的應用程式本身。 任何將創建 docker 映像的人都會知道 tgz 是什麼以及他需要做什麼。 這就是我使用docker的方式
底線：我不需要 docker 註冊表，我將使用某種 S3 或僅使用文件存儲，例如 google Drive/dropbox
CI 中的 Docker
我工作過的所有公司都是類似的。 他們通常是雜貨店。 也就是說，他們有一個應用程式、一個技術堆疊（好吧，可能是一兩種或三種程式語言）。
這些公司在運行 CI 流程的伺服器上使用 docker。 問題：為什麼需要在伺服器上的 docker 容器中建置專案？ 為什麼不直接為建置準備一個環境，例如，編寫一個 Ansible playbook 來安裝必要版本的 nodejs、php、jdk，將 ssh 金鑰等複製到將進行建置的伺服器？
現在我明白這是搬起石頭砸自己的腳，因為docker的隔離並不能帶來任何利潤。 我在docker中使用CI遇到的問題：
- 同樣，您需要一個 docker 映像來建置。 您需要尋找映像或編寫自己的 dockerfile。
- 90% 你需要轉送一些 ssh 金鑰，以及你不想寫入 docker 映像的秘密資料。
- 容器創建並消亡，所有快取都隨之丟失。 下次建置時會重新下載所有專案依賴，既費時又無效，時間就是金錢。
開發人員不會在 docker 容器中建置專案（我曾經是這樣的粉絲，真的，我為過去的自己感到難過 xD）。 在java中，可以有多個版本，並用一個命令將它們更改為您現在需要的版本。 在nodejs中也是一樣，有nvm。
產量
我相信docker是一個非常強大和靈活的工具，這是它的缺點（聽起來很奇怪，是的）。 在它的幫助下，公司可以輕鬆地迷上它，並在需要和不需要的地方使用它。 開發人員啟動他們的容器和一些環境，然後一切順利地流入 CI 和生產。 DevOps 團隊正在編寫某種程式碼來運行這些容器。
僅使用 docker 最近的 工作流程中的階段，不要一開始就把它拖到專案中。 它不會解決您的業務問題。 他只會把問題轉移到另一個層面並提供他自己的解決方案，你會做雙重工作。
當需要docker時：我得出的結論是，docker 非常擅長優化給定的進程，但不擅長建立基本功能
如果您仍然決定使用 docker，那麼：
- 要非常小心
- 不要強迫開發者使用docker
- 將其使用本地化在一處，不要將其分散到所有 Dockefile 和 docker-compose 儲存庫中
注：
- 我最近遇到 他們說它與 Ansible 配合得很好，可以讓你統一建構映像（包括 docker 映像）的過程
感謝您的閱讀，祝您在事務中做出透明的決定並度過富有成效的工作日！
來源： www.habr.com