🦁

ディレクトリ構成に「自分なりの標準」を持つことの重要性

に公開
Linux
fhs
idea

はじめに

スクリプトをどこに配置するか迷ったあなたに届けたい。
この記事は、ディレクトリ構成に自分なりの標準を持つとどんなメリットがあるかを書いています。

『動けばいい』の罠 - ディレクトリ名は script で良いですか？ -

個人用の環境や小規模な検証環境だと、つい mkdir script や mkdir temp_work のように、その場しのぎのディレクトリを作ってしまいがちですよね。
最初は良くても、スクリプトが増えたり、管理を引き継いだり（あるいは未来の自分が忘れた頃に）、「あれ、この script って何だっけ？」「conf ファイルはどこに置いたかな？」と混乱することになります。
script という名前自体は悪くないんですが、長期間の運用やチームでの共有を考えると、ちょっと困ったことが起きるんです。

困ったこと

  • 汎用的すぎる
    将来、バックアップ用や監視用など、別のスクリプトを追加したくなった時、/opt/script2 や /opt/backup_script のようにディレクトリが乱立して、管理が大変になります。
  • 意図が不明瞭
    名前から「何のスクリプトか」が分かりません。

さらに怖いのが、/opt/operation/script のような配置ルールを決めずにいると、「どこに置いてもいい」状態になり、セキュリティ事故につながる可能性があることです。
例えば、chmod 777 を習慣的に実行する人が、OSの重要なディレクトリ（/など）に誤って実行したら……。

777 の危険性

  • 誰でも管理者になれてしまう
    777は、Webサーバー（apache）などを含むあらゆるユーザーに、/etc/shadow のような重要ファイルへの書き込み権限を与えてしまいます。
  • SSHで入れなくなる
    SSHは、秘密鍵の権限が厳格でないと「bad permissions（不正な権限）」と判断し、鍵の使用を拒否します。

その場しのぎの運用が、システムの根本を揺るがすことになりかねないんです。

なぜ標準化が必要なのか？

では、なぜディレクトリ構成を標準化する必要があるんでしょうか？
一言でいえば、「ルールを決めた方が、全員が楽になるから」です。LinuxにもFHS（ファイルシステム階層標準）という標準ルールがあるように、明確な基準は大きなメリットをもたらします。

メリット

  • 可読性・検索性が上がる
    ディレクトリ名を見ただけで、何が入っているか直感的にわかります。ファイルを探す時間が減りますよね。
  • ヒューマンエラーの防止
    「スクリプトはこのディレクトリに置き、権限はこうする」というルールが決まれば、作業が定型化（または自動化）できます。777 のような危険な操作の介在を減らせます。
  • メンテナンス性の向上
    ログを目的別に一箇所に集めるルールなら、アーカイブ期間の変更などにも対応しやすくなります。
  • 未来の自分が楽できる（笑）
    個人の環境であっても、「ああ、FHSに従ってるからパラメーターシートを見返さなくても分かるな」「毎回、設計で悩まなくて済む！」と、未来の自分が感心してくれます。

私の考えるディレクトリ設計の原則（現時点の考え）

こうした背景から、私はディレクトリ設計に3つの原則を持つことが大事だと考えています。

3つの原則

  • FHS (ファイルシステム階層標準) を意識する
    これはLinuxの「お作法」を守るということです。
    OS標準のディレクトリ（/bin, /etc）は汚染しないようにし、自作のスクリプトやサードパーティ製のツールは、/opt や /usr/local といった専用の場所に置くようにします。
  • 自己完結性（Self-Contained）を持たせる
    関連するファイル（実行ファイル、設定、ログ）は、一つの親ディレクトリに全部まとめてしまいます。
    「もし不要になったら、この親ディレクトリを rm -rf するだけで済む」状態を目指すのが理想です。
  • 目的を明確にし、状態を分離する
    script のような曖昧な名前ではなく、oracle_backup や system_monitor のように「目的」がわかる名前にします。
    さらに、その中で bin（実行ファイル）、conf（設定ファイル）、log（ログ）のように「状態」でディレクトリを分離します。

具体例：私の「運用スクリプト」標準構成

この原則に基づいて、私が「運用スクリプト」を置くならこうする、という具体例を紹介します。
/opt 配下に、ツールやアプリの名前でディレクトリを作るのがおすすめです。

/opt/operation/                 # 分類別ディレクトリ（運用スクリプトならoperation、監視ならmonitorなど）
├── bin/                     # 実行ファイル
│   ├── main_script.sh
│   └── sub_function.py
├── conf/                    # 設定ファイル (環境変数など)
│   └── config.ini
├── log/                     # ログファイル（アプリケーションログ、エラーログなど）
│   ├── app.log
│   └── error.log
└── README.md                # このディレクトリが何か、どう使うかを書く

こんな感じで、役割ごとにファイルを分離します。

  • bin/
    実行するスクリプト本体を入れます。
  • conf/
    IPアドレスや閾値など、環境によって変わる可能性がある「設定値」を分離して入れます。
  • log/
    スクリプトの実行ログが溜まっていく場所です。（var配下にリンクするのも良いです。溜まるものなのでローテーションは忘れずに。）
  • README.md
    （地味に超重要）これが何のツールで、どう使うのかを書いておきます。未来の自分が絶対に感謝します。

まとめ

ディレクトリ構成に「型」を持つことは、一見すると面倒に思えるかもしれません。
でも、この最初のちょっとした設計こそが、「未来の自分を助ける最高の投資」だと私は思っています。
一度「自分なりの標準ルール」を決めてしまえば、こんなに良いことがあるんですよ。

  • 迷いが消える
    「どこに置こうか」「名前どうしよう」と毎回悩む時間がゼロになります。
  • 効率が上がる
    ルールに従うだけなので、作業スピードが上がります。
  • 本質に集中できる
    設計という雑念から解放され、スクリプトの中身を考えることに集中できます。

皆さんも、自分なりの「ディレクトリの型」、作ってみませんか？

Discussion