Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ジョブ管理でcronは限界があったので”Rundeck”を使ってハッピーになりました

インフラ勉強会用の発表資料です。cronで辛かった話から、rundeckがどれだけ素晴らしいかをご紹介。

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

ジョブ管理でcronは限界があったので”Rundeck”を使ってハッピーになりました

  1. 1. ジョブ管理でcronは限界があったの で”Rundeck”を使ってハッピーになりま した 2018/2/9(金) 22:00 インフラ勉強会 もりはや
  2. 2. 免責事項 自己紹介はインフラ勉強会Wikiをご確認ください>< 発表内容は個人のものであり所属する組織にいかなる(略) CentOSでの経験で話します
  3. 3. アジェンダ ジョブとは ジョブ管理とは Cronのあれこれ Rundeckご紹介 デモ(時間余れば)
  4. 4. ジョブとは 何らかのひとまとまりの処理。 実態としてはスクリプトファイルや、バッチファイルであること が多い。 会話では「バックアップジョブ」とか「レポートジョブ」とか 「集計ジョブ」とか気軽に「XXジョブ」という使い方をする。 ﴾異業種の友達と話すとポカンとされます)
  5. 5. ジョブ管理とは 必要に応じて特定の日時に、特定のジョブが実行される状態を維 持すること。 ﴾例﴿ 毎日AM3:00にDBのバックアップを取得 月初﴾1日﴿の09:30に先月分の売り上げレポートを作成 "5のつく日キャンペーン"のメールをキャンペーン開始日の 0:00に送信
  6. 6. Cronとは Linux標準のジョブスケジューラ。Windowsでいうタスクスケジュ ーラの機能。 実行日時の書式は初見殺しだけど、慣れるとこれ以外に無い気が してくるほど便利。 書式は以下の通り。1行=1ジョブ。 分 時 日 月 曜日 実行コマンド 大抵のジョブはCronで十分。
  7. 7. Cronの設定例 毎日AM3:00にDBのバックアップを取得 0 3 * * * /home/ope/bin/get_db_backup.sh 月初﴾1日﴿の09:30に先月分の売り上げレポートを作成 30 9 1 * * /home/ope/bin/create_monthly_report.sh "5のつく日キャンペーン"のメールをキャンペーン開始日の 0:00に送信 0 0 5,15,25 * * /home/ope/bin/send_mail_5dayevent.sh
  8. 8. Cronを使うためには crontab ‐e コマンドで追記する "/var/spool/cron/ユーザ名"のファイルが生成される /etc/crontabに追記する /etc/cron.d/配下へファイルを配置する /etc/cron.daily OR cron.weekly OR cron.monthlyへファイルを 配置する 各ディレクトリに配置されたファイルを/etc/anacronがラ ンダムな時間を付与して実行する仕組み
  9. 9. Cronのココがすごい OS標準である 必ず使えるという安心感 設定が簡単 書式に慣れればさくさくジョブがかける
  10. 10. Cronのココが辛い ログが出ない エラーハンドリングが難しい サーバ単体で完結してしまう
  11. 11. Cronの辛み1 - ログが出ない /var/log/cronへ実行したというログしか出ない。 ﴾MAILTO設定をすればメールで飛ばせるが、基本やらない﴿ Feb  8 14:04:01 localhost CROND[3694]: (ope) CMD (date) Feb  8 14:04:01 localhost CROND[3695]: (ope) CMD (/home/ope/bin/get_d 実行されたジョブが出力した標準出力、およびエラー出力は残ら ない。 ‐> どのような処理が行われたかわからない
  12. 12. Cronの辛み1 - ログが出ない 対策1 : cronのジョブ指定時にリダイレクト 0 3 * * * /home/ope/bin/get_db_backup.sh >> /var/log/job.log 対策2 : 実行されるスクリプトの中でログ出力を実装 #!/bin/bash # This is get_db_backup.sh log="/var/log/job.log date >> ${log} echo "Start db dump" >> ${log} ... ‐> 統一されたルールが無いと両方のパターンが混ざってカオスに なっていく
  13. 13. Cronの辛み2 - エラーハンドリングが難しい Cronは実行されたジョブがエラー終了しても気づけない。 以下のようなコマンド間違いがあったとしても * * * * * date * * * * * data # コマンド間違っている 華麗にスルーして実行 Feb  8 14:19:01 localhost CROND[3991]: (ope) CMD (date) Feb  8 14:19:01 localhost CROND[3992]: (ope) CMD (data) Feb  8 14:20:01 localhost CROND[4003]: (ope) CMD (date) Feb  8 14:20:01 localhost CROND[4004]: (ope) CMD (data) ‐> エラー検知の仕組みを別に実装する必要がある
  14. 14. Cronの辛み3 - サーバ単体で完結してしまう ”jobA"が終わり次第"jobB"を実行というのは以下のように書ける。 0 22 * * * jobA.sh && jobB.sh "サーバAのjobA"が終わり次第"サーバBのjobB"を実行するような処 理は書けないため、後続のサーバで「すでに終わっているはずの 時間」でジョブを実行する。 #@サーバA 0 22 * * * jobA.sh #@サーバB #※jobAは多分1時間以内に終わるはずだから23時に実行 0 23 * * * jobB.sh
  15. 15. Cronアンチパターン(実話) Cronを使っていて実際に経験したアンチパターンをお話します。
  16. 16. アンチパターン1 - crontabが育ちすぎてつらい とある日「なんか11時のジョブおかしそうだから調査ヨロ ノシ」と 言われて入ったサーバでcrontab ‐lを打ったところ > crontab ‐l | wc ‐l 1012       ( Д ) ゜ ゜  < 1000行!? コメントや空白行があるとはいえ、開いた時点でつらい。 その時はgrepして頑張った。 egrep "^[^ #]+ [*1]1* " /var/spool/cron/hoge
  17. 17. アンチパターン2 - 肌感によるピタゴラスイッチ 以下のようなジョブがすべて連携していた。 22:00 サーバAのジョブA 23:00 サーバBのジョブB 24:00 サーバCのジョブC 01:00 サーバDのジョブD とある日の改修でサーバAのジョブAの処理時間が40分 ‐> 1時間30 分に伸びた ‐> 後続のジョブ全滅...!! 加えて、普段うまく稼働していても無駄な空白時間があって モッタイナイ
  18. 18. アンチパターン2 - 肌感によるピタゴラスイッチ さらにサーバごとの部門が異なっていて各担当者への調整が大変 だった。 22:00 経理部門のサーバAのジョブA 23:00 総務部門のサーバBのジョブB 24:00 営業部門のサーバCのジョブC 01:00 管理部門のサーバDのジョブD
  19. 19. そこでRundeck
  20. 20. Rundeckとは https://github.com/rundeck/rundeck OSSのジョブスケジューラ WebのリッチなGUIが特徴 crontabからの移行に最適 細やかなアクセス制御 APIもあるよ GitHub Star 2k超
  21. 21. Rundeckと他ツールとの比較 他にも魅力的なOSSはあるけど、cronからの移行だけならRundeck がおすすめ Jenkins ‐> 多機能すぎてシンプルじゃない digdag ‐> GUIの機能(認証や設定変更)が不足 ConcouceCI ‐> GUIからの編集ができない
  22. 22. ここがすごいぜRundeck
  23. 23. 雰囲気で操作できるGUI
  24. 24. 細かいアクセス制御 少々複雑だが、LDAPやADと連携して以下のようなことが細やかに できる。 ジョブを実行を許可(編集はさせない) ジョブの結果参照を許可 特定のプロジェクトへのアクセス許可(ジョブの集まり)
  25. 25. 細かいアクセス制御 ※最近﴾2017/10﴿GUIから編集ができるようになった。
  26. 26. ログの保存(標準・エラー出力) 個人的にはこれが一番ありがたい。
  27. 27. コマンド、スクリプトの実行 対象サーバ上でコマンドを実行できる 対象サーバ上のスクリプトを実行できる rundeck上でスクリプトを書き、それを対象サーバ上で実行で きる optionという機能でジョブに変数をわたせる cron記法でのスケジューリングができる => 既存資産(スクリプト)をそのまま活かせる!!
  28. 28. ジョブワークフロー 登録したジョブはワークフローとして実行できる ジョブごとにどのサーバで実行するかも指定できる
  29. 29. (おまけ)プラグインによるansible連携 Jenkinsほどではないが、Rundeckも豊富なプラグインがあり、 その中でもansible pluginを使用すると以下が実現できる。 ansibleのインベントリを利用してRundeckへノードを自動登録 しかもインベントリのグループがRundeck上のTabとして 登録される (ただし定期的にGather_factsをするため、各サーバのシスログは 汚れていきます...﴿
  30. 30. Rundeckを利用する上で気を付けること 集中化による負荷 ﴾同時に実行されるジョブ数、出力されるログ容量など) 耐障害性 HA機能は有償のため、pacemaker & corosyncで冗長化 スケーリングについてはドキュメントも参照 http://rundeck.org/docs/administration/scaling‐ rundeck.html
  31. 31. デモ 時間があまったらデモします!! ご清聴ありがとうございました m( _ _ )m

    Be the first to comment

    Login to see the comments

  • ssuserb585322

    Jul. 12, 2018
  • ssuser9e36891

    Aug. 8, 2018
  • ikumahayasaka

    Aug. 10, 2018
  • ttm_ben

    Aug. 18, 2018
  • syouheitada5

    Feb. 2, 2020
  • tsuyoshicho

    Jul. 22, 2020
  • hidekazuhara

    Mar. 11, 2021
  • DaikiSatou1

    Apr. 3, 2021

インフラ勉強会用の発表資料です。cronで辛かった話から、rundeckがどれだけ素晴らしいかをご紹介。

Views

Total views

11,986

On Slideshare

0

From embeds

0

Number of embeds

407

Actions

Downloads

11

Shares

0

Comments

0

Likes

8

×