タグ付けされた質問 「python」

統合テスト中に、実際にRESTful API（または一般的なHTTPインターフェイス）を使用して繰り返し使用するケースに取り組んでいることに気付きました。bash+ cURLで確認します。 それはかなり乱雑に見え始め、維持するのが難しくなります。なぜ混乱をもたらすのですか？ 典型的な使用例は次のとおりです。 URLがhttp応答コードを返すことを確認してください（例：200） その場合、コンテンツタイプが必要なMIMEと一致することを確認します 返されたコンテンツが何らかのパターンに一致することを確認するか、抽象的な検証手順に合格する 私がこれまでに見つけたのは、車輪を再発明することなく実行可能なオプションを検討することです。 PyCurlを試してください-すべてのcURLオプションを完全に実装することを期待してください。プロキシだけでなく、私が必要とするかもしれない他のスイッチ Pythonの組み込みユニットテストを使用する 次に、たとえば、チェックするサービスごとに1つのユニットテストを実行できます。 import unittest, pycurl class TestService (unittest.TestCase): def test_1(self): self.assertEqual(pycurl.returncode("some_url"), 200) def test_2(self): self.assertTrue(pycurl.response("some_url").matches ("xxx") ) def test_3(self): self.assertTrue (pycurl.ContentType("some_url").equal("xxx")) if __name__ == '__main__': unittest.main() これは理にかなっていますか、またはより高度な（しかし、複雑すぎずに取り上げて統合できない）ツールがありますか？

14 testing  continuous-deployment  python  curl 

次の最小限の例を使用して、Docker化されたFlaskアプリに接続しようとすると、エラー104「ピアによる接続のリセット」で失敗します。 app.py： from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello World!" if __name__ == "__main__": app.run() Dockerfile： FROM python:alpine RUN pip install flask COPY . /src/ EXPOSE 5000 ENTRYPOINT ["python", "/src/app.py"] docker-compose.yml： … test: build: . ports: - 127.0.0.1:5000:5000 Flaskアプリは期待どおりに実行されているようです： $ docker logs test * Running …

9 docker  python 

一部の読者にとってこの質問は信じられないほど些細なことのように思われますが、開発者であるが、マニュアル以外の方法でアプリをデプロイした経験がほとんどない人としては、ある意味で、期待どおりに、それが理解できることを願っていますさまざまなアプローチやツールの数を確認するのは非常に難しいので、正しい方向に進むために少しアドバイスをすることができました。 私は開発者ですが、今は限られた時間の中でのみです。これまで私はJavaを使用してWebアプリケーションを構築しており、warファイルをTomcat環境にデプロイして、物事を適切にカプセル化しておくことにかなり満足しています。 私は現在PythonとDjangoで作業していますが、デプロイする必要があるポイントに近づいたら、できる限り自動化し、確実にデプロイできるようにするための確固たるdevopsワークフローをセットアップしたいと思いますが、使用例は比較的単純です。自分のニーズに合わせて過剰に設計され、時間の多大な投資を必要とする大きな脂肪のツールセットを学習したくないので、アプリのコーディングを使用します。 ですから、大きな開発エコシステムのセットアップと学習に膨大な時間を費やすことなく、確実にアプリをデプロイして管理することができる中立的な立場を探しています。 さらに詳細... 環境 Macで開発し、PyCharmを使用してDjango 2、Python 3をビルドしています。 ソフトウェアのバージョン管理にはgit（githubではない）を使用しています。 私は他の言語やスクリプト言語に慣れており、bashはあまり好きではありませんが、いくつかの（おそらくかなりアマチュアっぽい）bashスクリプトを書いています。私はPerlにも手を出しましたが、これは実際には手を出すための言語ではないことに気付きました（つまり、適切に学習するために時間を費やす必要があります）。 VPS環境、おそらくDigitalOceanに展開するつもりです。 私のアプリはミッションクリティカルではありませんが、サイトがダウンした場合、それがアプリを再起動するか、サーバーを再起動するか、別のサーバーに移動するかにかかわらず、ダウンした場合に確実に回復する方法が必要です（またはその他）。 特定の要件 アプリを受け取るための新しい環境をセットアップする機能。 これまで私が学んでいる間、これは手動で行われ、それを行うたびに、新しいDropletをゼロから始めました。これをはるかに単純化（自動化）して、緊急時に新しい環境をセットアップしなければならない場合でも確実に行えるようにしたいと思います。 可能な限りライブと同じステージング環境にアプリをデプロイする機能。理想的には、継続的インテグレーションアプローチを使用してgit pushによってトリガーされる自動化プロセス（これまで行ったことがない）と同じです。 ステージング環境でのアプリに満足したときに「ボタンを押す」機能。理想的には自動的にライブ環境にプッシュします。 サイトを監視する方法（ページへの投票だけで十分です） ライブサイトでアプリまたはサーバーの障害から回復する必要がある場合に、ライブサイトを別のサーバーに切り替える方法。青緑のアプローチがうまくいくと思いますか？ 何を試したり検討したりしましたか？ Djangoアプリを使用してライブ環境を手動で設定し、変更があった場合は新しいコードベースを手動でコピーします。これは人為的なミスが発生しやすいと感じており、デプロイでミスをすると回復不可能なエラーが発生することを恐れています。 Docker。Dockerについて知ったときは夢が叶ったように思えますが、少し実験と研究を行った後、これを実行して管理するためにどれだけ多くのことを学び、知る必要があるかに悩んでいます。いったん機能するようになるとリスクは非常に低くなるので、これは価値があるかもしれませんが、現時点では、私が期待しているよりも大きな時間を投資しているように感じます。 Bashスクリプト。それらを使用して、元の環境をセットアップし、アプリの更新などの特定のタスクを実行します。これについての私の心配は、スクリプトがテストを必要とするコードになることであり、この方法で信頼できるツールセットを構築するには多くの時間がかかるのではないかと心配しています。 私は、フローティングIPアドレスに関するDigital Oceanのオプションと、かなり賢明なように見える「ブルーグリーン」アプローチのために2つのサーバーを使用する機能を見てきました。このルートに進んだ場合でも、展開を自動化できる必要があります。 だから...私は、リスクの最小化（例：更新によってライブアプリが破損するリスク、または障害から回復できなくなるリスク）と時間の最小化の間の適切なバランスを見つけるdevopsアプローチに関するアドバイスを探しています環境とワークフローをセットアップするために必要な投資。

8 continuous-integration  git  python 

dockerfileはアプリケーション環境を作成します（例：env変数、apt-getを使用したライブラリーのインストールなど）。また、そのgitリポジトリからPythonアプリケーションコードをプルしてコピーします。 ただし、ビルドされたコンテナーでテストを実行するために、アプリケーションテスト（一部のユニット、一部の統合）をdocker RUNコマンド（例RUN /bin/bash -c "source activate cool_env; pytest"：）内に配置するか、CIスタック（例：Jenkins、Openshift）を使用してビルド後に配置するかについては、議論しています。 それぞれの長所と短所は何ですか？

7 jenkins  docker  testing  python