2017-10-24 41 views
0

codedeployagent.ymlファイルのmax_revisionsの値を編集して、EC2インスタンスに保存されている正常なコード配布リビジョンの数を制限しようとしています。私は現在、値を:max_revisions: 2に設定しています。制限コードmax_revisions値を使用したリビジョンの展開が機能しない

私は、ファイルの値を設定しているという方法が原因であると考えています。私は、コードデプロイメントパッケージでデプロイすることによって価値を設定しようとしています。私は次の行で、このファイルのインストール場所を指定しています私のappspec.ymlファイルで

etc/codedeploy-agent/conf/codedeployagent.yml

:これを行うために、私は次の場所にローカルにカスタムcodedeployagent.ymlファイルを作成している

- source: etc/codedeploy-agent/conf/codedeployagent.yml 
    destination: /etc/codedeploy-agent/conf 

スクリプトが既に存在するために展開しようとすると、このエラーが発生することがわかりました。この問題を回避するには、私は、パッケージのインストールにスクリプトを前に削除されます私のappspec.ymlBeforeInstallのフックスクリプト追加しました:オーケー

#!/bin/bash 
sudo rm /etc/codedeploy-agent/conf/codedeployagent.yml 

を、ので、この後、私は、サーバーと確かにD」sshを持っています十分な場合、:max_revisions: 2の値は期待どおりに設定されます。残念なことに、実際には私はec2のインスタンスに保存されている2つだけのリビジョンよりも多くのリビジョンを見ています。

私の質問の最初に戻る...この回避策は、codedeployagent.ymlファイルを更新する最良の方法ではありません。私は、自動スケーリンググループに展開しているということを付け加えてください。これは、単にログインして値をハードコーディングするのではなく、展開スクリプトまたはクラウドフォーメーションテンプレートに保存できるソリューションである必要があります。このすべての情報で、私はここで何が欠けていますか?どのようにしてリビジョンを適切に制限できますか?ありがとう。

答えて

0

設定ファイルを更新した後でエージェントを再起動しましたか?新しい構成は、エージェントを再起動するまで機能しません。

+0

はい、これは意味があり、 'sudo service httpd restart'を実行するコード配布用の' ApplicationStart'フックの間に起動されるサーバー再起動があります。あなたは設定ファイルの変更のために別のフックでこれが必要だと思いますか? – Presto

+0

私は 'ApplicationStart'フックに次の行を追加しました:' sudo service codedeploy-agent restart'私は ':max_revisions:1'も変更しました。もう一度デプロイした後、 '/ opt/codedeploy-agent/deployment-root/12 ... 83 /'ディレクトリをチェックし、そこに2つの正常なリビジョンパッケージがあります。それはちょうど1つではありませんか? – Presto

+0

最後に、私は 'max_revisions'値を正しく理解していないことに気付きました。 1に設定すると、実際には2が保持されます.1つは現在のデプロイメント用に保持され、次に1つ前のデプロイメント用に保持されます。ありがとう。 – Presto

0

以下の方法のいずれかを試してみてください。

  1. すでに2max_revisionsを変更したインスタンスのAMIを取り、このAMIとASGの起動設定を更新し、そのスケールアウトインスタンスそうにもこの設定を持つことになります。

    "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [ 
        "#!/bin/bash -xe\n", 
        "# Delete last line and add new line \n", 
        "sed '$ d' /etc/codedeploy-agent/conf/codedeployagent.yml > /etc/codedeploy-agent/conf/temp.yml\n", 
        "echo ':max_revisions: 2' >> /etc/codedeploy-agent/conf/temp.yml\n", 
        "rm -f /etc/codedeploy-agent/conf/codedeployagent.yml\n", 
        "mv /etc/codedeploy-agent/conf/temp.yml /etc/codedeploy-agent/conf/codedeployagent.yml\n", 
        "service codedeploy-agent restart\n" 
        ]]}} 
    
  2. referenceあたりとして

は、max_revisionsが展開グループごとの用途に適用されるユーザデータセクションに追加するには、起動設定 コマンドを作成中

  • は、あなたのユーザデータセクションにこの設定を追加します。したがって、 /opt/codedeploy-agent/deployment-root/<deployment_group_id>/の下に2つのリビジョンしか保持しません。 ASGが複数のアプリケーションに関連付けられている場合、codedeployは各アプリケーションの2つのリビジョンをdeployment_group_idディレクトリに格納します。

    +0

    ご返信ありがとうございます。いくつかの理由のために、私はむしろAMIを取ることはしません。この場合、第2の選択肢がより良い解決策であるように思えます。私のcouldのフォーメーションテンプレートのuserdataセクションで 'max_revisions'をどのように更新できるかのサンプルスクリプトを提供できますか? – Presto

    +0

    完了!答えに編集。 – Ravi

    +0

    私は自分のクラウドフォーメーションテンプレートにこのアップデートを試みましたが、次のエラーが表示されました。 '0のSUCCESSシグナルを受信しました.1つの100%のMinSuccessfulInstancesPercent要件を満たすことができませんでした。私は 'MinSuccessfulInstancesPercent'をゼロに調整しようとしましたが、何らかの奇妙な理由のためにこれはまだエラーメッセージです。 – Presto

    関連する問題