自動化/定期実行の用語集（22語）
自動化/定期実行に関する Linux 用語を、読み・意味・補足つきでまとめました。
Ansibleアンシブル
SSH 経由で複数サーバの構成を自動化する、エージェント不要の構成管理ツール。
管理対象に常駐プログラムを置かず、SSH で処理を流します。1回限りの操作は ad-hoc コマンド、再利用する手順は YAML の playbook で記述し、各処理は冪等に設計されています。
atアット
指定した時刻にコマンドを一度だけ実行する、単発予約用のコマンド。
繰り返しの cron に対し、at は一回限りの予約に使います。予約一覧は atq、取り消しは atrm で扱います。atd デーモンが予約を管理します。
cronクロン
決まった時刻や間隔でコマンドを自動実行する、Unix系OS標準のスケジューラ。
cron は crond というデーモンが定期的に各ユーザの予定表（crontab）を確認し、時刻が来たコマンドを起動するしくみです。バックアップやログ整理などの定例作業を無人で繰り返すのに使われます。
crontabクロンタブ
cron の予定表そのもの、またはそれを編集するコマンド。ユーザごとに持つ。
crontab -e で自分用の予定表を編集し、crontab -l で内容を確認します。1行が1つの定期ジョブを表し、実行タイミングと実行するコマンドを記述します。
cron式（5フィールド）クロンしき
「分 時 日 月 曜日」の5つで実行タイミングを表す cron の書式。
左から分(0-59)・時(0-23)・日(1-31)・月(1-12)・曜日(0-7)を並べます。* は毎、*/n はn間隔、a,b は列挙、a-b は範囲を表します。例: 0 3 * * * は毎日午前3時。
inotifyあいのーてぃふぁい
Linux カーネルが持つ、ファイルやフォルダの変化を検知する監視機構。
ファイルの作成・変更・削除・移動といった出来事をカーネルが監視し、登録したプログラムへ通知する。自分で繰り返し見に行くポーリングと違い、変化が起きるまで眠って待てるため、CPU をほとんど使わずに即座に反応できる。inotifywait コマンドや systemd の path unit は、この inotify を土台に動いている。監視できるのは基本的にローカルのファイルシステムに限られる。
logrotateろぐろーてーと
肥大するログファイルを区切り・圧縮・世代管理して自動で捨てるツール。
一定の期間や大きさに達したログを名前を付け替えて脇へどけ、新しいファイルに書き込みを続けさせる。番号（.1・.2…）で世代を押し出し、決めた数を超えた古いものは削除する。daily・rotate・compress・missingok などのキーワードで設定し、多くの環境では cron や systemd timer から毎日自動で起動される。
MAILTOめいるとぅー
crontab に書く宛先。ジョブが出力を出すと、その内容がメールで届く。
crontab の先頭に MAILTO=アドレス と書いておくと、cron が実行したジョブが標準出力や標準エラーへ何か出力したとき、その内容が指定アドレスへメール送信される。成功時は無出力・失敗時だけエラーを出すように書けば「メールが来た＝異常」という運用ができる。実際に届くにはサーバー側にメール送信の仕組みが必要。
path unitぱすゆにっと
指定した場所にファイルが現れたら対応サービスを起動する systemd のユニット。
拡張子 .path のユニットで、PathExistsGlob などの条件を満たすファイルが現れた瞬間に、同名の .service を起動する。中身は inotify なのでポーリングではなく変化に即応し、systemd の管理下で常駐するため端末を閉じても再起動しても見張りが持ち場に戻る。while ループの手動監視をサービス化した堅い形と言える。
playbookぷれいぶっく
Ansible の手順書。どの相手に何をどの順で行うかを YAML で書いたファイル。
hosts（対象）・tasks（やることの列）・module（部品）という階層で構成される。ad-hoc コマンドが単発の作業なのに対し、playbook は連なった手順をまとめて何度でも同じ順序で実行できる。YAML 形式なので人が読みやすい反面、行頭の空白（インデント）の数で意味が変わる点に注意する。
Playbookプレイブック
Ansible の実行手順を YAML でまとめたファイル。何をどの順で行うかを記述する。
対象ホスト群と、適用するタスク（パッケージ導入・設定配置・サービス起動など）を順に記述します。ansible-playbook コマンドで実行し、同じ playbook を何度流しても安全です。
postrotateぽすとろーてーと
ログを区切った直後に実行する処理。多くはサービスにログを開き直させる合図。
logrotate の設定内で postrotate と endscript の間に書いたコマンドは、ローテーション直後に一度だけ実行される。サービスが古いファイルをつかんだままだと新しいログに切り替わらないため、ここで reload やシグナル送信を行い「ログを開き直せ」と合図する。切り替えの取りこぼしを防ぐための、いわば後始末の一手。
systemd timerシステムディー タイマー
systemd でコマンドを定期実行するためのユニット。cron の代替として使われる。
実行内容を書いた service ユニットと、起動タイミングを書いた timer ユニットの組で動きます。ログが journal に統合され、逃した実行を補う Persistent 設定ができるのが特徴です。
webhookうぇぶふっく
この URL を叩けば通知が飛ぶ、という受け口。HTTP で外部へ知らせる仕組み。
チャットツールなどが発行する専用 URL に対して HTTP リクエスト（多くは POST）を送ると、その内容がツール側へ届く仕組み。スクリプトからは curl で URL を叩くだけでよく、メール送信の仕組み（MTA）が無い環境でも手軽に通知できる。自動処理の失敗を手元のチャットへ即座に知らせる用途で広く使われる。
インベントリいんべんとり
Ansible の操作対象ホストを並べたリスト。名前でグループにまとめられる。
playbook が「何をするか」を書くのに対し、インベントリは「誰にするか」を書く。テキスト（ini 形式）で角かっこのグループ名の下にホストを並べるのが基本で、playbook 側は hosts でそのグループ名を指す。手順書とホスト一覧を分けておくことで、同じ playbook を本番・検証など別の集団に使い回せる。
デーモンデーモン
バックグラウンドで常駐し続けるプロセス。crond や atd が代表例。
ユーザの操作とは独立に動き続け、要求やスケジュールに応じて処理を行います。定期実行では crond が、単発予約では atd が常駐して時刻を監視します。
ポーリングぽーりんぐ
一定間隔で繰り返し状態を見に行き、変化がないか確かめる方式。
cron で1分ごとにフォルダを覗くような、定期的に自分から確認しに行くやり方。実装は単純で確実だが、確認間隔ぶんだけ反応が遅れ、何も起きていない時も資源を使う空振りが生じる。変化の瞬間に通知を受ける監視（inotify）と対になる考え方で、ネットワーク越しの共有など監視が使えない場面ではポーリングを選ぶこともある。
ユニットユニット
systemd が管理する処理の単位。service や timer などの種類がある。
systemd ではサービス・タイマー・マウントなどをそれぞれユニットとして扱い、設定ファイル（.service や .timer）で定義します。systemctl で起動・停止・有効化を操作します。
ログの世代管理ろぐのせだいかんり
古いログを番号付きで残し、決めた世代数を超えた分から捨てていく管理方式。
現在書き込み中のログを app.log とし、区切るたびに app.log.1、app.log.2 と番号を押し出していく。rotate で残す世代数を決めておくと、それを超えたいちばん古いものが自動で削除される。compress を付ければ古い世代を gzip 圧縮して容量を節約できる。ディスクを一定量に収めつつ、直近の履歴だけを手元に残すための考え方。
終了コードしゅうりょうこーど
コマンドが終了時に残す数値。0 が成功、0 以外が失敗を表す。
終了ステータスとも呼ぶ。直前のコマンドの終了コードは変数 $? で読める。人間はふだん気にしないが、A && B（成功なら続ける）や A || B（失敗なら実行）といった分岐の判断材料になり、スクリプト同士が成否をやり取りする土台になる。パイプでつないだ場合は最後のコマンドの値になる点に注意する。
冪等性べきとうせい
同じ操作を何度実行しても結果が変わらない性質。自動化処理の安全性の鍵。
冪等な処理は、既に望む状態なら何もしないため、繰り返し実行しても副作用が積み重なりません。自動化スクリプトや Ansible の playbook はこの性質を満たすよう設計します。
冪等性べきとうせい
同じ操作を何度繰り返しても、1回行ったのと同じ状態に落ち着く性質。
Ansible の module は命令ではなく「あるべき状態」を宣言する形なので、既に望む状態なら何もしない（ok）、違えば直す（changed）という動きになる。この性質のおかげで playbook は現状を気にせず何度でも流せ、失敗しても安全に再実行できる。ただし command や shell で生コマンドを叩く部分は毎回実行されるため冪等にならない点に注意する。