クマの手も借りたい
馬とテニスとリラックマが好きな IT 系のエンジニアです。
Linux

crontabを消しちゃった時にアタフタしない対処法

たまたま crontab 関連で検索していたところ、こんなタイトルの記事が目に留まりました。

例えば root ユーザーで crontab -e すると、/var/spool/cron/root が書き換えられるわけですが、visudo が /etc/sudoers を直接触らないのと同じく、crontab -e で編集すること自体は別に悪いことではないんじゃないの?って思いました。

気になって記事の中身を読んでみると、キーボードの e と r が隣り合わせだから危険ってことでした。なるほど、そういった意味での使ってはいけないってことだったのですね。確かに、このオプション危ないなって思ったことはありますが、仕事ではサーバ上で直接 crontab を触らないようにしてきたので、そこまで意識したことはありませんでした。

crontabの内容はどこで管理してる?

というのも、私が初めて crontab を仕事で使った時、既に定義する内容が crontab.txt として CVS で管理されていたのですよね。CVS って言っても伝わりにくい時代かもしれませんが、今でいう Git や Subversion のようなソース管理システムです。

この文化があったおかげで、crontab で設定している内容が消えても短時間で復旧可能でしたし、サーバ上で直接書き換えることはなく、必ずデプロイの過程で crontab に最新の crontab.txt の内容が反映されるようになっていました。

$ crontab crontab.txt

運用を意識すると必然的に安全策を考える

プライベートでは、サーバ上でちょこちょこっと触って、後からソース管理上のファイルを修正するみたいな横着をすることもありますが、とにかく若い頃に携わったプロジェクトのおかげで、仕事では運用時のことを見据えた開発ができるようになった気がします。

まあ、これは Web アプリだけでなく、サーバインフラなども担当していたからこその経験かもしれませんが。

サーバの構成や、設定内容、バッチの手順、エラーログに対する調査手順などなど、心配性だったからかもしれませんが、すべて Wiki に書いて運用に備えていました。

最近でも、周りから Jenkins が壊れたからバックアップはないけどジョブを復活させておいてって、プロジェクトの内容もわからない人が頼まれていたという話を聞きましたが、最初にジョブを作った人がせめて何か残しておいてくれたらね・・・。

できる人は、すべて頭の中にあるから、また作り直せる自信があるのでしょうが、やはり長く運用していくプロジェクトについては少しでも手掛かりを残せるように仕組みを考えるのも必要ですね。

最後に、crontab -r してしまったけど、バックアップがない時の対処法として、以下の記事も紹介されていました。少し古いですが、少しは何かの手掛かりになるかもしれませんね。

あっ、ついでに Jenkins のバックアップシェルも紹介しておきます。

Web API The Good Parts

オライリーの「Web API」に特化した本です。最近の多くの Web サービスは API が活用されていますが、その技術はこれまでの Web サイトとそれほど大きく変わりません。

今後、マイクロサービス化が進む中で知っておいて損はない内容が詰め込まれており、現場のエンジニアやこれから Web 系のエンジニアを目指す人にもオススメの一冊です。

created by Rinker
¥2,376
(2018/09/21 11:58:20時点 Amazon調べ-詳細)

あなたにオススメ