FURYU Tech Blog - フリュー株式会社

フリュー株式会社の開発者が技術情報を発信するブログです。

Amazon Linux 2 EOL をきっかけに Rundeck を ECS 化してハマった話（暗号化エラーと時刻・通知の環境差異編）：その③

AWS ECS

こんにちは、ピクトリンク開発で運用保守を担当している藤本です。

※この記事は、前回の記事 Rundeck ECS 化：SSH / resources.xml / Network Error 編 の続きです。

今回は、リプレース作業中に発生した「既存 EC2 環境の破壊」と、新環境での「ジョブ実行・通知のトラブル」について、その原因と対応をまとめます。

1. 既存 EC2 Rundeck が 500 エラーで悲鳴を上げた話

新しく構築した ECS 側での動作確認のため、ブラウザからジョブを作成・実行したところ、思わぬ副作用が出ました。既存のEC2 Rundeckにアクセスすると500 エラー が発生。（エラーは困るけど、猫はかわいい）EC2側のRundeckログには以下のエラーが頻発していました。

Job not rescheduled in project pictlink: ... Decryption failed.
java.io.IOException: Decryption failed.

原因：暗号化設定の不一致

原因を調査したところ、EC2とECS で DB 内のデータの扱いが食い違っていました。

  • ECSでジョブを作成すると、storageテーブル内のjasypt-encryptionフラグがtrueに書き換わる

  • しかし、既存のEC2側は「暗号化されていない」前提の設定のままだった。

  • その結果、ECSが良かれと思って暗号化した情報を、EC2が復号できずエラーになった。

解決策：フラグの強制修正

RDS内のstorageテーブルを直接修正しました。JSON データ内のjasypt-encryption:encryptedフラグをfalseに書き戻すことで、EC2側からも正常に参照できるようになりました。

2. ジョブが時間になっても動かない？（時刻同期の罠）

ECS化後のテスト中、今度は「設定した時間になってもジョブが自動実行されない」問題に直面しました。

原因：サーバー時刻が UTC（協定世界時）だった

実行ログを叩いてみると、サーバー内の時計が日本時間（JST）より9時間遅れて動作していることが判明しました。

* 現象:23:30実行のジョブが、サーバー内ではまだ 14:30だったため、キックされるのをずっと待っていた状態。

解決策：OSレベルのタイムゾーン設定とRundeck設定の修正

最初は手軽にentrypoint.shでexport TZ=Asia/Tokyoを実行してみましたが、これだけではOS全体の挙動として反映されず、ジョブの実行時刻はUTCのままでした。

そこで、Dockerfileに以下のtzdata設定を組み込み、OSレベルでタイムゾーンを固定しました。

# タイムゾーン設定 (Asia/Tokyo)
RUN apt-get update && apt-get install -y tzdata \
    && ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime \
    && echo "Asia/Tokyo" > /etc/timezone \
    && dpkg-reconfigure -f noninteractive tzdata

さらに、Rundeckのジョブ編集画面でもTime Zone欄に明示的にAsia/Tokyoを設定することで、ようやく意図した時間にジョブが動くようになりました。 コンテナ環境では「環境変数での指定」を過信せず、パッケージレベルでの設定とアプリ側の指定を組み合わせるのが確実です。

3. Slack 通知が飛ばない（プラグインの互換性問題）

最後にハマったのが Slack 通知です。 「サーバーからcurlを叩けば Slack に届くのに、Rundeckのジョブからは一向に通知が来ない」という現象です。

原因：最新プラグインとの相性

導入していた Slackプラグインのバージョン（v0.9）が、今回の環境や設定と上手く噛み合っていなかったようです。

解決策：プラグインをダウングレード

安定稼働の実績があるv0.6.devにダウングレードし、Rundeckサービスを再起動しました。 これで嘘のようにあっさり通知が飛ぶようになりました。「最新版が常に正解とは限らない」ということでしょうか。。。

4. 記事➂のまとめ：ECSリプレースを完遂するために

今回のトラブルから得られた教訓は以下の3点です。

  1. DB 共有時は設定を揃える:EC2/ECSを並行稼働させる際は、暗号化フラグの挙動に要注意。

  2. タイムゾーンは明示的に:コンテナ環境のOS時刻を過信せず、ジョブ単位でAsia/Tokyoを設定する。

  3. プラグインは「実績」重視:動かないときは、設定を疑う前に「実績のあるバージョン」への切り戻しも検討する。

インフラ構成が変わると、今回のように思わぬ挙動の違いが出ます。 今回の記事で「Amazon Linux 2 EOLをきっかけにRundeckをECS化してハマった話」シリーズ完結です。 この記事が、RundeckのECS化でログと格闘している方の助けになれば幸いです！