Python Webアプリケーションを作成する1人の開発者にとって、良いdevopsアプローチは何ですか?


8

一部の読者にとってこの質問は信じられないほど些細なことのように思われますが、開発者であるが、マニュアル以外の方法でアプリをデプロイした経験がほとんどない人としては、ある意味で、期待どおりに、それが理解できることを願っていますさまざまなアプローチやツールの数を確認するのは非常に難しいので、正しい方向に進むために少しアドバイスをすることができました。

私は開発者ですが、今は限られた時間の中でのみです。これまで私はJavaを使用してWebアプリケーションを構築しており、warファイルをTomcat環境にデプロイして、物事を適切にカプセル化しておくことにかなり満足しています。

私は現在PythonとDjangoで作業していますが、デプロイする必要があるポイントに近づいたら、できる限り自動化し、確実にデプロイできるようにするための確固たるdevopsワークフローをセットアップしたいと思いますが、使用例は比較的単純です。自分のニーズに合わせて過剰に設計され、時間の多大な投資を必要とする大きな脂肪のツールセットを学習したくないので、アプリのコーディングを使用します。

ですから、大きな開発エコシステムのセットアップと学習に膨大な時間を費やすことなく、確実にアプリをデプロイして管理することができる中立的な立場を探しています。

さらに詳細...

環境

  1. Macで開発し、PyCharmを使用してDjango 2、Python 3をビルドしています。
  2. ソフトウェアのバージョン管理にはgit(githubではない)を使用しています。
  3. 私は他の言語やスクリプト言語に慣れており、bashはあまり好きではありませんが、いくつかの(おそらくかなりアマチュアっぽい)bashスクリプトを書いています。私はPerlにも手を出しましたが、これは実際には手を出すための言語ではないことに気付きました(つまり、適切に学習するために時間を費やす必要があります)。
  4. VPS環境、おそらくDigitalOceanに展開するつもりです。
  5. 私のアプリはミッションクリティカルではありませんが、サイトがダウンした場合、それがアプリを再起動するか、サーバーを再起動するか、別のサーバーに移動するかにかかわらず、ダウンした場合に確実に回復する方法が必要です(またはその他)。

特定の要件

  1. アプリを受け取るための新しい環境をセットアップする機能。

    これまで私が学んでいる間、これは手動で行われ、それを行うたびに、新しいDropletをゼロから始めました。これをはるかに単純化(自動化)して、緊急時に新しい環境をセットアップしなければならない場合でも確実に行えるようにしたいと思います。

  2. 可能な限りライブと同じステージング環境にアプリをデプロイする機能。理想的には、継続的インテグレーションアプローチを使用してgit pushによってトリガーされる自動化プロセス(これまで行ったことがない)と同じです。

  3. ステージング環境でのアプリに満足したときに「ボタンを押す」機能。理想的には自動的にライブ環境にプッシュします。

  4. サイトを監視する方法(ページへの投票だけで十分です)

  5. ライブサイトでアプリまたはサーバーの障害から回復する必要がある場合に、ライブサイトを別のサーバーに切り替える方法。青緑のアプローチがうまくいくと思いますか?

何を試したり検討したりしましたか?

  • Djangoアプリを使用してライブ環境を手動で設定し、変更があった場合は新しいコードベースを手動でコピーします。これは人為的なミスが発生しやすいと感じており、デプロイでミスをすると回復不可能なエラーが発生することを恐れています。

  • Docker。Dockerについて知ったときは夢が叶ったように思えますが、少し実験と研究を行った後、これを実行して管理するためにどれだけ多くのことを学び、知る必要があるかに悩んでいます。いったん機能するようになるとリスクは非常に低くなるので、これは価値があるかもしれませんが、現時点では、私が期待しているよりも大きな時間を投資しているように感じます。

  • Bashスクリプト。それらを使用して、元の環境をセットアップし、アプリの更新などの特定のタスクを実行します。これについての私の心配は、スクリプトがテストを必要とするコードになることであり、この方法で信頼できるツールセットを構築するには多くの時間がかかるのではないかと心配しています。

  • 私は、フローティングIPアドレスに関するDigital Oceanのオプションと、かなり賢明なように見える「ブルーグリーン」アプローチのために2つのサーバーを使用する機能を見てきました。このルートに進んだ場合でも、展開を自動化できる必要があります。

だから...私は、リスクの最小化(例:更新によってライブアプリが破損するリスク、または障害から回復できなくなるリスク)と時間の最小化の間の適切なバランスを見つけるdevopsアプローチに関するアドバイスを探しています環境とワークフローをセットアップするために必要な投資。

回答:


5

私はPython開発にもDigitalOceanにも精通していないので、いくつかの指針を提供します。

  • 目標は自動化することです。すべて。それをどのように達成するかは本当にあなた次第であり、独自のツールを作成することはそれほど難しいことではありません。多くの人がそのようにしています。具体的でかなり低い(懸案事項)ぶら下がっている実例の1つは、テスト環境をデプロイして再起動するgit post-receiveフックを実行することです。それがあれば、残りは簡単です。
  • 「これについての私の心配は、スクリプトがテストを必要とするコードになることです」-その心配は根拠のないものです。あなたはされているすべての後に、これらのスクリプトにあなたがあなたのテスト環境にデプロイするたびにテストします。特に青緑色のアプローチと組み合わせると、bashスクリプトがあれば問題ありません。
  • 「私はbashを楽しんでいない。」-次に、お好きな別のスクリプト言語を見つけます。Rubyを試してみませんか?言語ライブラリとコアライブラリは非常に簡潔で十分に文書化されており、学ぶのはかなり簡単です。または、面白味のあるGo(lang)は、ツールタスクの開発に適しているようです。そして最後に、あなたはPythonが好きなようですが、それでインストールタスクを実行することもできます。これらのことから、Goはスタンドアロンのバイナリを作成し、最初に複雑な環境をインストールする必要がないため、ブートストラップが簡単になるという利点があります。
  • 「可能な限りライブと同じステージング環境」-環境をゼロから起動するスクリプトがある場合、つまり多かれ少なかれ空の基本イメージから環境同一にすると、環境同一になり、エンコードされたデルタを除いて保存されますあなたのスクリプト。これがすべてのポイントです。
  • 「ライブサイトを別のサーバーに切り替える方法」-永続データで何が起こるかを熟考する唯一のこと。つまり、アプリケーションをさまざまな永続ボリューム/ストアにその場でリンクして、前後に切り替えることができるようにする必要があります。
  • 「ドッカー-気難しい」-正直に言うと、それほど悪くないはずです。コマンドラインツール(GUIツールなし)を使用して最初から環境を構築する方法を知っている場合は、それらをDockerfileに配置するのはかなり簡単です。調整するとき(つまり、画像サイズを小さくするとき)に気になる詳細が表示されますが、それ以外はそれほど悪くないはずです。最初に何とかして機能さ、次にそれを美しくする方法を見つけます。良いことは、あなたが得た知識が他の多くの環境に伝わることです。

幸運を!


3

素晴らしい質問をありがとう。あなたが初めてそれをするとき、本当に簡単なことは何もありません。

私の最初の推奨は、Dockerを再訪することです。いくつかの異なるガイドとチュートリアルを試してください。とても簡単です。「ビルド」されるDockerファイルがあり、文字通り、「コンテナー」または「イメージ」で実行したいコマンドだけです。そのイメージをパブリックまたはプライベートのレジストリにプッシュします。次に、そのイメージをホストマシンで実行します。Dockerは、多くの依存関係があるnode.jsとpythonで非常に重要であり、それらを時々管理するのは本当に難しい場合があります。pipを使用している場合、使用する必要がある場合は、requirements.txtファイルを生成してdockerコンテナーにフィードできます。

これで、gitを使用しているとのことなので、ローカルのgitフックを使用します。これらを使用して、Dockerコンテナーを構築し、自動テストを実行して、コンテナーをデプロイできます。このテーマに関するさまざまなガイドやチュートリアルを調べることができます。

インフラストラクチャの管理には、Terraformを使用します。Terraformは、オンデマンドで環境を起動し、完了時に削除できるため、優れています。私の推奨は単純なものから始めることです。DockerとTerraformをマスターしたら、青/緑のデプロイメントを試すことができます。

Gitlabを使用しているか、切り替えても構わない場合は、無料のci / cdサービスも提供しています。これには非常に多くのクールな機能が含まれており、本当に使いやすいです。私はすべてのアプリで個人的に使用しています。ローカルのgitフックを完全にスキップしてgitlabパイプラインでテストするか、ローカルで各コミットをテストし、gitlabを使用してビルドとデプロイするためにそれらを保持できます。

これが多少役立つことを願っています。


1
Dockerで私が少し面倒だと思ったのは、コンポーネントを異なるコンテナーに入れるという原則でした。したがって、1つはアプリ用、1つはGunicorn用、1つはNginx用などです。次に、追加の構成を追加して、それらが互いに対話できるようにする必要があります。それは、あらゆる環境に転送可能な単一のカプセル化されたコンテナを持つという目的を打ち負かすようです。しかし、この返信と@Anoeは別の外観を与えることを勧めているので、私はやります。
オースパイス

1
@Auspiceこれは、「マイクロサービス」アプローチの詳細です。Dockerコンテナーが単一のプロセスのみを持つことがベストプラクティスですが、多くの場合、私が見るものとは異なります。「Docker way?」をチェックしてください ここgithub.com/just-containers/s6-overlay。Ansibleを使用して、個人的にインフラを育てます。Ansibleを使用してTerraformを呼び出し、作成します。次に、ansibleを使用してサーバーを更新し、Dockerをインストールし、nginxをインストールして、Dockerアプリをサービスとして起動します。アプリとgunicornがあるコンテナにプロキシするようにnginxを設定することができます。
Levi

0

投稿された回答は、問題やさまざまなアプローチを再考するのに非常に役立ちました。私はまだソリューションを実装していませんが、アプローチを決定したので、それを文書化し、それを回答として選択します。要約すると、これは次のとおりです。

私が選んだアプローチ

  • ライブ環境では、Ubuntuを実行し、まったく同じように構成された2つの仮想マシン(おそらくDigitalOceanドロップレットを使用)を使用します。
  • DO内のFloating IP機能を使用してBlue-Greenアプローチを採用し、2つの同一サーバーをLiveおよびPre-Prod / Backupとして維持します。
  • ステージング環境として使用するようにセットアップされた開発環境でVM(おそらくVirtualBoxを使用)を作成します。このVMは、2台のライブサーバーとまったく同じように設定されます。
  • 最初から環境をセットアップするための単一の共通スクリプトをPythonで作成し、これを使用してステージング環境とライブ/プリプロダクションペアを構成します。
  • gitフックを使用して、環境の更新をトリガーします(おそらく手動でトリガーします)。

このアプローチを推進した考慮事項

  • Docker:私はそれに反対することにしました。私はもう一度訪ねるべきだと言っている返事を真剣に受け止めています(@Leviと@Danに感謝します)。ウサギの穴を食い尽くし、時間がかかるようになるには時間がかかります。他の人と一緒に働いていたとしても違うと思いますが、1分ごとに一人で完全に一人で働く人は貴重です。

  • 仮想マシン:VMを使用してSwarm機能をデモンストレーションするいくつかのDockerチュートリアルで作業を開始するまで、これを実際に検討していませんでした。私が完全にコントロールできる真新しい環境を作り出すことができるというアイデアは非常に魅力的です。

  • スクリプティング:@AnoEの有益な返信に促され、もう少し掘り下げました。Pythonはスクリプティングの実行可能なオプションとして認識されているようです。そのため、私がアプリを記述しているので、相乗効果があるはずです(必要な場合)私のスクリプトについて何か新しいことを学ぶことは、私が私のアプリを書くのに使用するかもしれない知識になります)

私はこれでいくつかの進歩を遂げたら更新します、そしてそれがひどく間違っているなら私はおそらく間違った選択をしたことを認めます!)

2018年10月20日更新。

私はPythonスクリプトの作成に着手しましたが、これにはPythonからbashコマンドを呼び出して応答を返すことがしばしば含まれており、これが開発時間にかなりの時間を費やしていることがわかりました。数週間のゆっくりとした進歩の後、私は他の場所を調べました。私は間違ってそれに近づいていたかもしれないことは認めますが、もっと速くなるようなものが必要でした。

私は最終的にVagrant / Ansible / VirtualBoxに落ち着き、数か月後にはうまくいくものを認めましたが、多くの仕事の後にいくつかの新しいスキルを学びました(VagrantとAnsibleはまったく新しいものでした)。次に、Ansibleスクリプトを適用してDigitalOcean Dropletをプロビジョニングしましたが、これが非常にうまく機能していることがわかりました。私はAnsibleのファンになりましたが、(レビュアーと)比較的使いやすいことに同意しても、それはまだ新しいパラダイムであり、非常に急な学習曲線です。

この記事の執筆時点では、DigitalOceanに2つの個別のドロップレットを青緑色の構成でプロビジョニングし、DOフローティングIPアドレスを使用して2つを切り替え、各アプリケーションはgit作業コピー内にあるため、更新するだけです。環境を更新するマスター。

フローティングIPを期待どおりに動作させるのに問題がありますが、すぐに解決する予定であり、そうすればDevOps環境が機能するようになります。

このアプローチの大きな利点は、Ansibleが機能する方法です。何かが機能すると、別の環境で比較的簡単に機能させることができます。これは、Pythonスクリプトで実現するのがそれほど簡単ではない場合があります(または少なくともビルドする必要があります)これは追加の作業です)。

大きな教訓は、物事が予想以上に時間がかかり、新しいテクノロジーを学ぶと常に未知の未知がもたらされるということです。これは私にとって驚くべきことではありません-しかし、それは常に孤独な開発者として働いており、私にはよく起こります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.