はいっ、というわけでねー、つい先日開催された合同勉強会 in 大都会岡山 -2020 Winter Online-で発表してきたのでそこで話ができなかったこととか書いていこうと思っています。
ちなみに本エントリは大都会岡山 Advent Calendar 2020の18日目の予定です。
ちなみに本エントリは大都会岡山 Advent Calendar 2020の18日目の予定です。
ちなみに、発表スライドはこちら
発表動画は以下です。
スライド中にちょいちょい出てくる構成図はawslabs/aws-icons-for-plantumlを利用しています。
AWSが公式で配布しているPowerPoint用のアイコンセットを利用しても良かったのですが、パワポでポチポチ図を配置していくよりは、(細かい位置の調整は諦めて)コードで書いて変換するほうが性に合っているのでPlantUMLで作りました。
なお、社内でインフラ構成の検討や説明時に同じようにPlantUMLで(かなり細かいところまで)作っていたものがあるので、それを参考にし発表に不要な部分はそぎ落とせばよかったから、という理由もあったりします。
RundeckはOSSのジョブスケジューラ(cronみたいなヤツ)です。
弊社の主力製品は顧客ごとにサーバーが立って、その中でいろんな定期バッチが動いていたりします。
また、顧客ごとにカスタマイズが入っているため、こっちではAとBのバッチを動かすけど、こっちのサーバーはBとCを動かす、というようなことも普通にあります。
そのため、各サーバーで必要なバッチのキックをcronに設定していくと確実に設定漏れが発生したりしますが、Rundeckに集約することでそのあたりの漏れをできるだけ減らそうという魂胆で構築しています。
Rundeckも古くから稼働していましたが、こいつに何かあると全サーバーで障害発生(バッチが動かない)ということになりかねないため、数年前に再構築し直しました(私が)。
ちなみに、Rundeckを(EC2で)普通に動かすだけであれば、yum install rundeck とかで動いたりしますし、今ならdockerでもサクッと構築できたりするので、どんな感じか簡単に試せます。
Rundeckを普通に構築すると色々問題があるので、いろんな対策は入れています。
基本的にはRundeck公式のドキュメント(英語)を読めばできる内容ばかりではありますが。
そのため、サーバーに何かがあった場合に取り返しがつかないので外部に逃がすようにしています。
例えば、プロジェクトの設定はDB(RDSのMySQL)に、接続先のサーバー情報(ノード情報)はS3に置いて読み書きが自由にできるようにしていたりします。
※ ただし、ログインユーザーだけは動かせなかったので、Rundeckのサーバーローカルにいます。
Rundeck単独でもSSL対応できるみたいですが、証明書の作成や更新がめんどくさいので、手っ取り早くフロントにELB(ALB)を配置して、ACMの証明書を突っ込んでいます。
後、EC2がガチで死んだ時に新しいインスタンスを立ち上げられるように、ansibleのプレイブックを作っていたりします。
ちなみに、connectivityが落ちてなくても普通にRundeckのプロセスが死んでるケースも考慮して、Mackerelのプロセスチェックプラグインを利用してRundeckのプロセスを監視、死んでた場合にはaction機能を利用して再起動をかけるようにしています。
発表動画は以下です。
構成図について
正解 #gbdaitokai https://t.co/29hjXPoxzv
— (っ’ヮ’c) < ★しっぽ (@ryosms) November 3, 2020
スライド中にちょいちょい出てくる構成図はawslabs/aws-icons-for-plantumlを利用しています。
AWSが公式で配布しているPowerPoint用のアイコンセットを利用しても良かったのですが、パワポでポチポチ図を配置していくよりは、(細かい位置の調整は諦めて)コードで書いて変換するほうが性に合っているのでPlantUMLで作りました。
なお、社内でインフラ構成の検討や説明時に同じようにPlantUMLで(かなり細かいところまで)作っていたものがあるので、それを参考にし発表に不要な部分はそぎ落とせばよかったから、という理由もあったりします。
Rundeckについて
発表内でもちょいちょいRundeckという単語が出てきていますが、詳しい説明はしていませんでした。RundeckはOSSのジョブスケジューラ(cronみたいなヤツ)です。
弊社の主力製品は顧客ごとにサーバーが立って、その中でいろんな定期バッチが動いていたりします。
また、顧客ごとにカスタマイズが入っているため、こっちではAとBのバッチを動かすけど、こっちのサーバーはBとCを動かす、というようなことも普通にあります。
そのため、各サーバーで必要なバッチのキックをcronに設定していくと確実に設定漏れが発生したりしますが、Rundeckに集約することでそのあたりの漏れをできるだけ減らそうという魂胆で構築しています。
Rundeckも古くから稼働していましたが、こいつに何かあると全サーバーで障害発生(バッチが動かない)ということになりかねないため、数年前に再構築し直しました(私が)。
ちなみに、Rundeckを(EC2で)普通に動かすだけであれば、yum install rundeck とかで動いたりしますし、今ならdockerでもサクッと構築できたりするので、どんな感じか簡単に試せます。
Rundeckを普通に構築すると色々問題があるので、いろんな対策は入れています。
基本的にはRundeck公式のドキュメント(英語)を読めばできる内容ばかりではありますが。
設定情報
通常、Rundeckはログインユーザーやプロジェクトの設定をすべてローカルのファイルとして管理しています。そのため、サーバーに何かがあった場合に取り返しがつかないので外部に逃がすようにしています。
例えば、プロジェクトの設定はDB(RDSのMySQL)に、接続先のサーバー情報(ノード情報)はS3に置いて読み書きが自由にできるようにしていたりします。
※ ただし、ログインユーザーだけは動かせなかったので、Rundeckのサーバーローカルにいます。
接続ポート
Rundeckは通常は4440ポートで稼働しますが、会社のいろんな情報が入っていることを考慮して、HTTPS配下で動かすようにしています。Rundeck単独でもSSL対応できるみたいですが、証明書の作成や更新がめんどくさいので、手っ取り早くフロントにELB(ALB)を配置して、ACMの証明書を突っ込んでいます。
その他
Rundeckが動いているEC2が死んだ時にすぐに通知が来るように、Mackerelで監視を入れています。で、connectivityが落ちたらEC2を自動で再起動するように設定しています。後、EC2がガチで死んだ時に新しいインスタンスを立ち上げられるように、ansibleのプレイブックを作っていたりします。
ちなみに、connectivityが落ちてなくても普通にRundeckのプロセスが死んでるケースも考慮して、Mackerelのプロセスチェックプラグインを利用してRundeckのプロセスを監視、死んでた場合にはaction機能を利用して再起動をかけるようにしています。
コメント