當我們從Ansible的試用版切換到生產版時，我有更多關於最佳實踐的問題。我們使用Ansible來安裝yum或其他某些回購中不可用的產品和修補程序。他們以高達600MB的zip文件到達，我們將它們作爲zip文件推送到服務器並在那裏解壓縮。這一切工作正常。我們歷史上將這些壓縮文件存儲在項目的文件/產品和文件/補丁目錄中。Ansible大文件存儲
我們現在正在將我們的項目遷移到Git（Bitbucket）。許多人會說你不應該在Git中存儲二進制文件。嘗試時，我們提交和推送較大文件的成功次數有限（我們得到超時）。如果我們只是將它們存儲在項目目錄中的服務器上，則必須非常小心，不要在項目中啓用「刪除更新」設置，因爲當項目更新時，它將吹走大量產品和補丁庫。感覺有點不穩定。
有了這種理解，其他人如何存儲大型文件並使用Ansible分發它們？它們是否存儲在項目的外部並使用完全合格的路徑進行引用？您是否爲Ansible可以從中獲取的大文件實施了其他一些回購形式？任何指導將不勝感激。
首先，你真的不想在Git中存儲二進制文件。這將使您輕鬆克隆回購（無論是開發還是部署）並導航項目成爲絕對的噩夢。
如果您需要使用Ansible部署一些大型二進制文件，那麼該二進制文件屬於某種形式的二進制文件或工件存儲庫。在我們的例子中，我們使用Aptly來存儲apt repos的快照，Artifactory用於一般的二進制文件（通常是zip文件，但偶爾也會有WAR文件和其他許多東西）。
在Aptly的情況下，我們簡單地指出，就好像它是一個普通的回購，而在Artifactory的情況下，我們使用Ansible的get_url模塊從中央Artifactory服務器下載二進制文件。
是的，有一些是不建議存放在Git的大文件，包括每一個開發商必須保持這些文件的每個副本在他們結賬，所有時間的幾個原因。你可以找到各種方法來減輕這個with a simple web search。
就Ansible而言，這應該不會有太大的改變。如果您使用的解決方案將源文件保留在運行Ansible的計算機上，則可以像以前一樣繼續複製它們。
另外，很多人都存儲在單獨的文件存儲這些文件（例如，S3或本地文件服務器），並有Ansible規則引用遠程URL從服務器上下載這些文件。這樣可以使您不必在本地計算機上下載它們，而且主服務器和文件服務器之間的帶寬使用率，而不是您的服務器和本地計算機（可能不會這樣做）。 HTTP（S）在傳輸文件方面比SSH更高效。
隨着這些外部系統，你要確保包的舊版本仍然可用，當您簽出一個版本，預計舊版本的Ansible代碼。一些git解決方案會自動處理，但你也可以通過在文件路徑中包含版本號或校驗和來完成。