本番環境やテスト環境へのデプロイ作業において、毎回手動で git pull を行うのは手間がかかりますし、オペレーションミスの原因にもなります。
そこで今回は、Unix系OSの標準機能である「Cron（クロン）」を使用して、指定した日時に git pull を自動実行する方法をまとめました。
基本的な書き方から、私が実際にハマった「Cronが動かないときのチェックポイント」まで解説します。
実行環境
本記事は以下の環境での動作を想定しています。
⚠ 内容には注意してまとめていますが、最終的な動作確認や設定は自身の環境に合わせて必ず確認してください。この記事は動作を保証するものではありません。
Cron（クロン）とは
Cron（クロン）は、Unix系OS（Linux、macOSなど）に標準で搭載されている 定期実行タスク管理ツールです。 設定ファイル（crontab）に記述されたスケジュールに従って、コマンドやスクリプトを自動的に実行します。
Cronの主な特徴
- ユーザーごとに設定可能: ユーザー（SSHログインしているアカウント）ごとに個別の
crontabを持ちます。 - 最短実行間隔: 通常は「1分単位」でスケジュールを確認・実行します。
- 実体の場所: 設定ファイルは
/var/spool/cron/crontabs等に保存されます（OSにより異なります）。
Cronの設定方法
Cronの設定は、ターミナルから以下のコマンドを入力して行います。
1. 編集モードに入る
crontab -e
-e: エディタを起動して設定を編集するオプションです。- 初回起動時はエディタの選択（nano, vim等）を求められる場合があります。
- 注意: ローカルPCで実行すればローカルのCronが、SSH先で実行すればサーバー側のCronが編集されます。
2. ジョブ（実行内容）を記述する
エディタが開いたら、以下の書式に従って行を追加します。
# ┌───────────── 分 (0 - 59) # │ ┌───────────── 時 (0 - 23) # │ │ ┌───────────── 日 (1 - 31) # │ │ │ ┌───────────── 月 (1 - 12) # │ │ │ │ ┌───────────── 曜日 (0 - 7) (0 または 7 = 日曜日) # │ │ │ │ │ # * * * * * 実行するコマンド
設定例
| 目的 | 書式 |
|---|---|
| 毎日 5:00 にバックアップ | 0 5 * * * /home/user/backup.sh |
| 毎週日曜 0:00 にログ掃除 | 0 0 * * 0 /home/user/cleanup_logs.sh (※ 0 または 7 = 日曜、1 = 月曜) |
| 10分ごとにスクリプト実行 | */10 * * * * /home/user/check.sh |
| 平日 9:00〜18:00 に毎時実行 | 0 9-18 * * 1-5 /home/user/work.sh |
crontab コマンドオプション一覧
作業時によく使うオプションを整理しました。特に -r は危険なので注意が必要です。
| オプション | 説明 |
|---|---|
crontab -e |
設定を編集する（Edit）。保存時に構文チェックが行われます。 |
crontab -l |
現在の設定を表示する（List）。 |
crontab -r |
設定を全削除する（Remove）。確認なしで消えるため注意。 |
crontab -i |
削除時（-r実行時）に確認メッセージを表示する安全オプション。 |
crontab -u ユーザー |
指定したユーザーのCronを操作する（root権限が必要）。 |
Cronが動かない？ つまずきポイントと対策
Cronの設定をしたのに「なぜか動かない」という場合、以下の原因が考えられます。私が実際に検証して重要だと感じたポイントです。
1. サーバーのタイムゾーン（JST vs UTC）
多くのクラウドサーバー（AWS EC2など）は、デフォルトの時刻が UTC（協定世界時） になっています。
- 現象: 日本時間（JST）のつもりで設定すると、9時間ずれて実行される。
- 対策:
dateコマンドでサーバー時刻を確認するか、9時間引いた時間で設定します。
2. 相対パスは使えない
Cron実行時は、ホームディレクトリ等ではなく、システムルートなど特定の場所から実行されることが多いです。また、環境変数 PATH も読み込まれていない場合があります。
- 現象:
cdやgitコマンドが見つからない、ファイルパスが不正などのエラーになる。 - 対策: コマンドやファイルパスはすべて 絶対パス で記述します。
- NG:
git pull - OK:
/usr/bin/git pull(実行環境でwhich gitなどと入力しパスを確認）
- NG:
3. 「実行されたか」が見えない
Cronはバックグラウンドで動くため、標準出力はコンソールに表示されません（設定によってはメールでroot宛に飛びます）。
- 対策: 実行結果をログファイルに書き出すように記述します。
# 末尾に「>> /path/to/log 2>&1」をつける
* * * * * /path/to/command >> /var/log/cron-test.log 2>&1
※ `2>&1` は「エラー出力も標準出力と同じ場所に書き込む」という意味です。
最終的な設定内容
上記を踏まえ、今回は「4月1日の深夜2:00」にプロジェクトディレクトリへ移動し、git pull を行う設定を以下のように記述しました。
0 2 1 4 * cd /home/user/workspace/myproject && /usr/bin/git checkout main && /usr/bin/git pull origin main >> /home/user/workspace/cron-test.log 2>&1
コマンドの解説
0 2 1 4 *: 4月1日の2:00に実行。cd /home/user/...: まず作業ディレクトリへ移動（これを行わないとgitコマンドがリポジトリを認識できません）。&&: 前のコマンドが成功したら次を実行。/usr/bin/git ...: Gitコマンドもフルパスで指定（which gitでパス確認推奨）。>> ... 2>&1: 成功・失敗に関わらずログファイルに追記。
おわりに
Cronは一度設定してしまえば非常に便利ですが、パスの問題や環境変数の違いなど、初回はつまずきやすいポイントがいくつかあります。 「動かないな？」と思ったら、まずは 絶対パス と ログ出力 を確認してみてください。
この記事が、同じように自動化に取り組む方の参考になれば幸いです。
