サーバーでPythonアプリケーションを整理するためのいくつかのヒント

この記事では、稼働中の（実動）サーバー上でプロジェクトを編成するためのいくつかの便利な方法を共有します。

私は主にPython / Djangoスタックで作業しているため、すべての例は主にこのセットに関連しています。 また、主要なテクノロジー：Ubuntu（17.10）、Python3（3.6）。

内容：

• ログ（logrotate）
• 悪魔（systemd）
• ローカル設定

すべてを正しく実行していることを前提としています。アプリケーションはリポジトリに保存され、サーバー上の別のフォルダーにデプロイされます。たとえば、virtualenvが使用されます。 実行するには、個別に作成されたユーザーが使用されます。これは十分な権限を持ちますが、あまり多くありません（たとえば、sudoがなく、sshログインは許可されません）。

まず、リポジトリに保存されているものはすべてクリーンなコードと静的データであるという一般的な真実を繰り返します。 すべての設定には、未使用のファイルであっても、デフォルトのみが含まれ、パスワードとキーは含まれません。

コードを記述している稼働中のコンピューター（ラップトップ）でさえ、プロジェクトフォルダーに運用環境にアップロードできないものが存在しないようにします。 これは、プロジェクト内の設定フォルダー（オプションとして、development_settings.py）にあるファイル「local_settings.py」を使用するという悪意のある手法を指します。 この例を以下で分析します。

ログ

確かにあなたはロギングを使用しています。 組み込みのロギングモジュールは非常に優れていますが、それを洗練して他のすべてに使用する価値があるとは限りません。

たとえば、ログのローテーション。 インターネットでは、標準のRotatingFileHandlerから始まり、いくつかのソースからのログを記録するためのソケットに独自のデーモンを書き込むことで終わる、複雑で洗練された方法があります。 問題は、純粋なPythonですべてを実行したいという願望のために始まります。 これは愚かで非効率的ですが、エラーが発生する可能性のある場所をたくさんもたらします。

logrotateサービスを使用します。 以下は、セロリのログの簡単な設定です。

標準では、ファイル/var/log/myproject/celery.logを書き込み、毎日/ var / log / myproject / archive /フォルダーに配置し、前日のサフィックスを名前に追加します。

/var/log/myproject/celery.log { size 1 su myuser myuser copytruncate create rotate 10 missingok postrotate timeext=`date -d '1 day ago' "+%Y-%m-%d"` # daily # timeext=$(date +%Y-%m-%d_%H) # hourly mv /var/log/myproject/celery.log.1 /var/log/myproject/archive/celery_$timeext.log endscript }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ログが非常に迅速に書き込まれ、1時間ごとにローテーションする場合は、構成の「daily」および「hourly」の行をコメントアウトします。 また、logrotateを1時間ごとに実行するように構成する必要があります（デフォルトでは、通常は毎日）。 bashで実行：

 sudo cp /etc/cron.daily/logrotate /etc/cron.hourly/logrotate sudo sed -i -r "s/^[[:digit:]]*( .+cron.hourly)/0\1/" /etc/crontab
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成（myserviceファイル）はlogrotateフォルダーに配置する必要があります

 sudo cp config/logrotate/myservice /etc/logrotate.d/myservice
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

重要なポイント：

• 構成をコピーする必要があり、シンボリックリンクは機能しません
• 原則として、設定はほとんどlogrotateによってドックから取得されますが、 copytruncate
  
  
  
  ディレクティブを設定することは非常に重要です
• （ rusnasonovのコメントから追加）logrotateは馬鹿げており、バッファのないシンプルなロータリーシステムを使用しています。 ローテーションは2段階で行われます-最初に古いファイルがコピーされ、次に古い場所にトリミングされます。 これにより、間隔で記録されたログが失われる可能性があります（ ドキュメントに反映 ）

copytruncateは、回転中にファイルが閉じられないため重要です。 「ライブ」システム上でファイルをローテーションするため、ファイルは開いており、ファイルに書き込むサービスは何らかの種類のファイル記述子に従ってこれを行います。 ファイルを移動して新しい空のファイルを作成するだけの場合、そのファイルは使用されません。 copytruncateは、内容をコピーしてからファイルをクリアする必要があるが、閉じないことを示しています。

サービス

アプリケーションをどのように起動しますか？ さまざまな方法があります。 私の観察によると、主なものは次のとおりです。

• screen / tmuxを起動し、内部でインタラクティブスクリプトを起動します
• gunicornまたはセロリの「-D」タイプのデーモンモード
• 監督
• init.dスクリプト
• Docker

それらにはすべて利点がありますが、私の意見では、さらに欠点があります。

ここではDockerを検討しません。 まず、あまり経験がありません。 第二に、コンテナを使用する場合、あなたとこの記事のその他のヒントは実際には必要ありません。 そこでは、アプローチはすでに異なっています。

システムが便利なツールを提供してくれるなら、なぜそれを使わないのかと思います。

Ubuntuでは、バージョン15.04以降、デフォルトでsystemdがサービスの管理用に提供されています（それだけではありません）。

systemdは、すべてを正しく行うという点で非常に便利です。

• 必要なユーザーの下でアプリケーションを起動し、必要に応じて環境変数を設定します
• アプリケーションが突然停止した場合、指定された回数だけ再起動します
• 非常に柔軟で、依存関係と起動順序を設定できます

もちろん、systemdをお持ちでない場合は、supervisordの方を見ることができますが、このツールにはかなり大きな嫌悪があり、使用を避けています。

systemdの使用が有害であると監督されていることを疑う人がいないことを願っています。

以下に、実行する構成の例を示します。

gunicornを起動します（ローカルnginxを介してプロキシされますが、ここでは関係ありません）。

 [Unit] Description=My Web service Documentation= StartLimitIntervalSec=11 [Service] Type=simple Environment=DJANGO_SETTINGS_MODULE=myservice.settings.production ExecStart=/opt/venv/bin/python3 -W ignore /opt/venv/bin/gunicorn -c /opt/myservice/config/gunicorn/gunicorn.conf.py --chdir /opt/myservice myservice.wsgi:application Restart=always RestartSec=2 StartLimitBurst=5 User=myuser Group=myuser ExecStop=/bin/kill -s TERM $MAINPID WorkingDirectory=/opt/myservice ReadWriteDirectories=/opt/myservice [Install] WantedBy=multi-user.target Alias=my-web.service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、悪魔モードを使用しないことが重要です。 通常のプロセスでgunicornを起動し、systemd自体がそれを悪魔化し、クラッシュした場合の再起動も監視します。

virtualenvフォルダーに相対的なpythonおよびgunicornへのパスを使用することに注意してください。

セロリの場合、すべてが同じになりますが、次のように起動ラインをお勧めします（独自のパスと値を入力してください）：

 ExecStart=/opt/venv/bin/celery worker -A myservice.settings.celery_settings -Ofair --concurrency=3 --queues=celery --logfile=/var/log/myservice/celery.log --max-tasks-per-child 1 --pidfile=/tmp/celery_myservice.pid -n main.%h -l INFO -B
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

再起動のパラメータに注意する価値があります。

 StartLimitIntervalSec=11 RestartSec=2 StartLimitBurst=5
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

要するに、これは次のことを意味します。サービスがクラッシュした場合、2秒後にサービスを再起動しますが、11秒で5回を超えません。 StartLimitIntervalSecの値がたとえば9秒である場合、サービスが連続して5回停止した場合（起動直後）、5回目のドロップの後、systemdはあきらめ、それを発生させない（2 * 5）ことを理解することが重要です。 11の値は、そのような品種を除外するために選択されます。 たとえば、15秒間ネットワーク障害が発生し、開始直後にアプリケーションが（タイムアウトなしで）クラッシュした場合、停止するよりも勝利に向けた方がよいでしょう。

この構成をシステムにインストールするには、作業フォルダーからシンボリックリンクを作成するだけです。

 ~~sudo ln -s /opt/myservice/config/systemd/*.service /etc/systemd/system/~~ sudo systemctl daemon-reload
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、シンボリックリンクには注意する必要があります-プロジェクトがシステムドライブにない場合、サービスの開始後にマウントできる可能性があります（たとえば、ネットワークドライブやメモリマップ）。 この場合、単に開始されません。 ここでは、依存関係を正しく構成する方法をグーグルで検索する必要があります。実際には、configdをsystemdフォルダーにコピーすることをお勧めします。

更新： andreymalによる発言の後、構成をフォルダーにコピーし、適切な権限を設定する方が正しいと思います。

 sudo chown root: /opt/myservice/config/systemd/*.service sudo chmod 770 /opt/myservice/config/systemd/*.service sudo cp /opt/myservice/config/systemd/*.service /etc/systemd/system/ sudo systemctl daemon-reload
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、コンソールへの出力を無効にすることをお勧めします。そうしないと、すべてがsyslogに送られます。

systemdにすべてのコンポーネントがある場合、各コンポーネントの使用は次のようになります。

 sudo systemctl stop my-web.service sudo systemctl stop my-celery.service sudo systemctl start my-web.service sudo systemctl start my-celery.service
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

複数のコンポーネントがある場合、サーバー上のエコノミー全体の大規模な管理のためのスクリプトを作成することは理にかなっています。

 bash manage.sh migrate bash manage.sh start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンソール経由のリモートデバッグの場合（django-extensionsからshell_plusを実行します）：

 bash manage.sh debug
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

複数のサーバーがある場合は、もちろん、既にスクリプトを使用して展開していますが、これは単なる例です。

ローカル設定

これはholivarのトピックであり、この段落は私の視点にすぎず、私の経験に基づいていることに注意してください。 あなたが好きなように、私はちょうどお勧めします。

問題の本質は、アプリケーションの作成方法に関係なく、どこかに保存されているデータを処理する必要がある可能性が高いことです。 ユーザーのリスト、キーへのパス、パスワード、データベースへのパスなど...これらの設定はすべてリポジトリに保存できません。 誰かが保管しますが、これは悪質な行為です。 安全ではなく、柔軟性がありません。

そのような設定を保存する最も一般的な方法とそれらの問題は何ですか：

• local_settings.pyファイル。デフォルトのsetting.pyの隣のプロジェクトフォルダーに保存されます。
  
  問題：誤ってファイルをコミットする可能性があります。フォルダーをコピー/更新するときにファイルを消去できます（rsyncまたはアーカイブから）
• 環境変数。 また、あまり安全ではなく、あまり便利ではありません（たとえば、ソフトリロードなど）
• プロジェクトフォルダー外の別のファイル

この特定の方法をお勧めします。 私は通常、プロジェクトのyamlファイルをフォルダー「/ usr / local / etc /」に作成します。 私は小さなモジュールを書きました。 魔法 ハッキングは、ファイルからインポートモジュールのlocals()



またはglobals()



変数をロードします。

非常に簡単に使用されます。 Djangoのsettings.pyの深さのどこか（最後の方が良い）で呼び出します：

 import_settings("/usr/local/etc/myservice.yaml")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、すべてのコンテンツがグローバル設定にミックスされます。 リストと辞書にマージを使用していますが、誰にとっても便利ではないかもしれません。 Djangoは大文字の定数のみをインポートすることを覚えておくことが重要です。つまり、ファイルでは、すぐに大文字にする必要がある最初のレベルの設定です。

それはすべての人々です！

コメントの残りの部分について説明します。