一千萬個為什麽

搜索

對於編寫python Web應用程序的單個開發人員來說,有什麽好的devops方法?



我猜這個問題對於一些讀者來說似乎非常微不足道,但作為一個開發人員,但除了手冊,點擊和希望之外的其他任何方式部署應用程序的經驗很少,我希望你能理解它是看到不同方法和工具的數量非常令人生畏,所以我可以做一些建議讓我開始朝著正確的方向前進。

我是開發人員,現在只在業余時間,這是有限的。到目前為止,我一直在使用Java,構建webapps,並且非常樂意將war文件部署到Tomcat環境中,這樣可以很好地封裝。

我現在正在使用Python和Django,但隨著我越來越接近我需要部署的地步,我想建立一個可靠的devops工作流程來盡可能自動化並確保我可以可靠地部署,但鑒於我的用例相對簡單,我想避免學習一個大型的工具集,這個工具集對我的需求進行了過度設計,需要投入大量時間,我寧願使用我的應用程序編碼。

因此,我正在尋找一個中間立場,這使我能夠可靠地部署和管理我的應用程序,而無需花費大量時間來設置和學習大型devops生態系統。

更多細節......

上下文

  1. 我在Mac上開發,使用PyCharm構建Django 2,Python 3。
  2. 我使用git(但不是在github上)來管理軟件版本控制。
  3. 我對其他語言和腳本語言很滿意,並寫了一些(可能相當業余的)bash腳本,雖然我不喜歡bash。我還涉及Perl,我意識到這不是一種用於涉獵的語言(即你需要花時間學習它)
  4. 我打算在VPS環境中部署,可能是DigitalOcean。
  5. 我的應用程序不是關鍵任務,但重要的是我知道網站是否出現故障,並且需要有一種可靠的恢復方式,無論是重新啟動應用程序,重新啟動服務器還是轉移到另一臺服務器(或其他)。

具體要求

  1. Ability to set up a new environment to receive the app.

    Up to now while I am learning, this has been manual, and every time I have done it I have started from scratch with a new Droplet. I would like this to be much simpler (automated) so that if I have to set up a new environment in an emergency I can do so reliably.

  2. Ability to deploy the app to a staging environment which is as identical to the live as possible, ideally as an automated process triggered by a git push using a continuous integration approach (which I have never done before).

  3. Ability to "press the button" when I am happy with the app in the staging environment to push to a live environment ideally automatically.

  4. Way to monitor the site (just a poll to a page will do)

  5. Way to switch live site to another server if I need to recover from an app or server failure on the live site. I think maybe a Blue-Green approach would work for me?

我嘗試過或考慮過什麽?

  • 使用Django app手動設置實時環境,然後在發生更改時手動將新代碼庫復制到其中。這感覺容易出現人為錯誤,我擔心在部署中會導致無法恢復的失敗。

  • 泊塢。我承認,當我發現Docker時,它看起來似乎是夢想成真但經過一些實驗和研究後,我感到很沮喪,我需要學習和知道如何開始運行並管理它。這可能是值得的,因為一旦它正在運作它的風險非常低,但目前感覺我的時間比我希望的更大。

  • Bash腳本。使用它們來設置原始環境以及更新應用程序等特定任務。我對此的擔心是腳本將是需要測試的代碼,我擔心以這種方式構建可靠的工具集需要花費大量時間。

  • 我看過Digital Ocean的浮動IP地址選項,並且能夠使用兩臺服務器來實現“藍綠”方式,這似乎是非常明智的。如果我走這條路線,我仍然需要能夠自動部署。

所以...我正在尋找關於devops方法的建議,該方法在最小化風險(例如,通過更新破壞實時應用程序的風險,或無法從故障中恢復的風險)和最小化時間之間找到適當的平衡我需要進行投資來設置環境和工作流程。

轉載註明原文: 對於編寫python Web應用程序的單個開發人員來說,有什麽好的devops方法?

一共有 3 個回答:

我不熟悉Python開發和DigitalOcean,所以我只提供一些指示:

  • 目標是實現自動化。一切。你如何實現這一點取決於你,創建自己的工具並不是牽強附會,許多人都這樣做。一個具體的,相當低的(ish)懸掛水果是獲得一個git post-receive hook運行,它可以部署並重新啟動你的測試環境。如果你有,那麽其余部分應該很簡單。
  • “我擔心的是腳本將是需要測試的代碼” - 這種擔心是沒有根據的。畢竟,每次部署到測試環境時,測試這些腳本。特別是采用藍綠色方法,可以使用bash腳本。
  • “我不喜歡bash。” - 然後找到你喜歡的另一種腳本語言。也許試試Ruby?語言和核心庫非常幹凈且文檔齊全,我會說,相當容易學習。或者,只是為了好玩,Go(lang),這似乎非常適合開發工具任務。最後,由於您似乎喜歡Python,您當然也可以使用它來執行安裝任務。通過這些,Go的好處是它可以創建獨立的二進制文件,並且不需要首先安裝復雜的環境本身,因此引導可能更容易。
  • “與現場盡可能相同的暫存環境” - 如果您有一個腳本從頭開始旋轉環境,即從一個或多或少的空基礎圖像,那麽您的環境相同,除了腳本中編碼的增量。這就是所有這一切。
  • “將實時網站切換到另一臺服務器的方法” - 唯一需要思考的是持久性數據會發生什麽。即,您需要這樣做,以便您可以動態地將應用程序與不同的持久卷/商店鏈接,以便能夠來回切換。
  • “Docker - 鬧鬼” - 說實話,它不應該那麽糟糕。如果您知道如何使用命令行工具(無GUI工具)從頭開始構建環境,那麽將它們放在Dockerfile中應該相當容易。當需要調整(即減小圖像大小)時會出現令人擔憂的細節,但除此之外它不應該太糟糕。首先讓它以以某種方式工作,然後找出如何讓它變得美麗。好處是你獲得的知識將轉移到許多其他環境中。

祝你好運!

謝謝你提出的好問題。當你第一次這樣做時,沒有什麽是微不足道的,而且我們都曾經是新手。

我的第一個建議是重新訪問docker。嘗試一些不同的指南和教程。這很簡單。你有一個“建立”的docker文件,字面上只是你想要在“容器”或“圖像”上運行的命令。您將該圖像推送到可以是公共或私有的註冊表。然後,您在主機上運行該映像。 Docker對於node.js和python非常重要,你有很多依賴項,有時候管理它們真的很難。如果您正在使用pip,那麽您可以生成 requirements.txt 文件以提供給您的docker容器。

現在你說你正在使用git,所以我會使用本地git鉤子。您可以使用這些來構建docker容器,運行自動化測試,然後部署容器。您可以查看有關此主題的許多不同指南和教程。

為了管理您的基礎設施,我會使用Terraform。 Terraform非常棒,因為您可以根據需要啟動環境並在完成後將其刪除。我的建議是開始簡單,一旦掌握了docker和terraform,你就可以嘗試藍/綠部署。

現在,如果您使用Gitlab或願意切換,它還提供免費的ci/cd服務。這包括許多很酷的功能,並且非常易於使用。我親自為我的所有應用程序使用它。您可以完全跳過本地git鉤子並在gitlab管道中進行測試,或者讓它們在本地測試每個提交並使用gitlab進行構建和部署。

我希望這有點幫助。

發布的答案非常有助於我重新思考我的問題和各種方法。我還沒有實現解決方案,但我已經決定采用一種方法,所以我正在記錄並選擇它作為答案。總之是這樣的:

我選擇的方法

  • 對於實時環境,我將使用運行Ubuntu的兩臺虛擬機(可能使用DigitalOcean飛點)並配置完全相同。
  • 我將采用藍綠方法,使用DO內的浮動IP工具來維護我的兩個相同的服務器,如Live和Pre-Prod/Backup。
  • 我將在我的開發設置中創建一個VM(可能使用VirtualBox),用作暫存環境。該VM的設置與我的兩臺實時服務器完全相同。
  • 我將在Python中編寫一個通用腳本,用於從頭開始設置環境,我將使用它來配置我的暫存環境和我的實時/預生產對。
  • 我將使用git hooks來觸發對環境的更新(可能是手動觸發)。

推動這種方法的考慮因素

  • Docker:我決定反對它。雖然我認真對待回復(感謝@Levi和@Dan),說我應該重新訪問並且不應該那麽糟糕,但我過去曾經有過太多經驗,開始嘗試一些新事物並意識到我已經墮落了沿著一個兔子洞,吃掉時間,需要一個年齡才能開始。我認為如果我甚至與另一個人合作會有所不同,但是因為每分鐘都完全獨自工作的人是寶貴的。

  • 虛擬機:在我開始使用一些使用VM來演示Swarm功能的Docker教程之前,我還沒有真正考慮過這個問題。能夠創造一個我完全控制的全新環境的想法非常吸引人。

  • 腳本編寫:@ AnoE的有用回復提示我已經做了一些挖掘,似乎Python被認為是一個可行的腳本選項,因為我正在編寫我的應用程序似乎應該有一些協同作用(如果我需要為我的腳本學習一些新內容,那將是我在撰寫應用程序時可能會使用的知識)

一旦我在這方面取得了一些進展,我會更新,如果它發生了可怕的錯誤,我會承認我可能做出了錯誤的選擇!)。