Linux サーバーの歩き方

手元は Mac、本番は Linux です。

普段は気にせず開発できます。問題が起きるまでは。

「デプロイしたのにサービスが起動しない」
「ログはどこにあるんですか」
「ディスクが 100% です、と監視から通知が来た」
「Permission denied と出る。sudo を付けたら動いたが、いいのか？」
「コンテナの中に日本語が化けて出る」

こうなった時、サーバーやコンテナに入って自分で調べられるかで、 解決までの時間が10倍変わります。

この章は、その最低限をまとめたものです。 サーバーを構築する話ではありません。入って、見て、切り分けるための知識です。

どこに何があるか — FHS

Linux のディレクトリ構成には決まりがあります。FHS（Filesystem Hierarchy Standard）といいます。

これを知らないと、「設定ファイルを探す」だけで時間が溶けます。

cat /proc/cpuinfo      # CPU の情報
cat /proc/meminfo      # メモリの情報
cat /etc/os-release    # このマシンは何の OS か

cat /etc/os-release
# NAME="Ubuntu"        → apt
# NAME="Alpine Linux"  → apk
# NAME="Amazon Linux"  → dnf / yum

ユーザーとグループ

Linux はもともと1台を複数人で使う前提で作られています。 だから、すべてのファイルとプロセスに「誰のものか」が付いています。

whoami        # 今の自分
id            # 自分の UID / GID / 所属グループ
# uid=1000(intern) gid=1000(intern) groups=1000(intern),27(sudo),999(docker)

root（UID 0）は特別で、ファイルの所有者や権限による制限のほとんどを無視できます。 何でもできるということは、打ち間違いも何でも通るということです。

（厳密には root も万能ではありません。読み取り専用でマウントされた領域、 SELinux や AppArmor の制御、コンテナに与えられた権限の範囲には縛られます。）

所有者と権限を変える

コマンドラインで生きるで権限（755 など）を扱いました。もう2つあります。

chown app:app /var/www/html      # 所有者とグループを変える
chown -R app:app /var/www        # 配下すべて（-R は影響範囲に注意）
chmod g+w shared.txt             # グループに書き込みを足す（数値でなくてもよい）

umask         # 0022 が一般的
# 644 のファイル、755 のディレクトリができる

sudo — 管理者として実行する

なぜ root で作業しないのか

root でログインすれば、権限で困ることはありません。 それでも実務では常に一般ユーザーで作業し、必要な時だけ sudo を付けます。

理由は3つあります。

3番目は最小権限——「必要な権限を、必要な期間だけ与える」という原則です。 侵入された時の被害範囲がそのまま変わります。 詳しくはセキュリティを設計に組み込むで扱います。

使い方

sudo systemctl restart nginx    # このコマンドだけ管理者として実行する
sudo -u postgres psql           # 別のユーザーとして実行する
sudo -i                         # root のシェルに入る（最後の手段）
sudo -l                         # 自分に何が許可されているか確認する

誰が sudo を使えるかは /etc/sudoers で決まります（編集は必ず visudo で行う。 構文を壊すと誰も sudo できなくなり、復旧が非常に面倒です）。

□ そのファイルは本当に管理者しか触れないべきものか？
□ アプリの実行ユーザーが間違っていないか？
□ 誰かが root で作ったファイルが残っているだけではないか？

curl https://example.com/install.sh | sudo bash   # 何が起きるか誰も知らない

docker run -v /:/host -it alpine sh   # ホストのファイルが全部見える

パッケージ管理

Dockerfile を書けば必ず出てきます。

# 悪い例: update と install が別レイヤーになり、古いキャッシュを掴む
RUN apt-get update
RUN apt-get install -y curl
 
# 良い例: 1つの RUN にまとめ、キャッシュも消す
RUN apt-get update \
 && apt-get install -y --no-install-recommends curl \
 && rm -rf /var/lib/apt/lists/*

ディスクが足りない

実務で最も多いサーバー障害の1つです。しかも、たいてい深夜に起きます。

df -h                    # ディスク全体の使用率
du -sh /var/log/*        # どのディレクトリが太っているか
du -sh * | sort -h       # 今いる場所で大きい順に

df で全体を見て、du で犯人を探す、という順番です。

lsof | grep deleted     # 削除済みだが開かれたままのファイル

df -i                   # inode の使用率

サービスとログ — systemd

Ubuntu・Debian・RHEL 系のサーバーでは、常駐プログラムはほぼ systemd が管理しています。

ただしどこでも systemd とは限りません。Alpine は OpenRC を使い、 コンテナの中には systemd がありません（アプリのプロセスが直接 PID 1 になります）。 systemctl が無いと言われたら、まず /etc/os-release と ps 1 を見てください。

systemctl status nginx      # 動いているか、直近のログは何か  ← まずこれ
systemctl start nginx
systemctl stop nginx
systemctl restart nginx
systemctl enable nginx      # 次回の起動時から自動で立ち上げる
systemctl list-units --failed   # 落ちているものを一覧する

enable と start は別物です。start は今動かすだけなので、 再起動すると消えます。「サーバーを再起動したら上がってこなかった」の原因の定番です。

ログを読む

journalctl -u nginx           # そのサービスのログ
journalctl -u nginx -f        # 追い続ける（tail -f と同じ感覚）
journalctl -u nginx --since '10 min ago'
journalctl -p err -b          # 今回の起動以降のエラーだけ

/var/log にファイルとして出ているものは、tail -f と grep で読みます。

tail -f /var/log/nginx/error.log
grep -i 'out of memory' /var/log/syslog

1. systemctl status <service>     何と言って落ちたか
2. journalctl -u <service> -n 50  直前50行
3. 設定ファイルの構文チェック      nginx -t など、たいてい専用コマンドがある
4. 権限とパス                     実行ユーザーがそのファイルを読めるか

定期実行 — cron

決まった時刻に動かす仕組みです。

crontab -l          # 自分の設定を見る
crontab -e          # 編集する

# 分 時 日 月 曜日  コマンド
0 3 * * *      /usr/local/bin/backup.sh        # 毎日 3:00
*/5 * * * *    /usr/local/bin/health-check.sh  # 5分おき
0 0 1 * *      /usr/local/bin/monthly.sh       # 毎月1日

□ PATH が最小限（/usr/bin:/bin だけのことが多い）→ コマンドが見つからない
□ .zshrc は読まれない → 環境変数が無い
□ カレントディレクトリが違う → 相対パスが壊れる
□ 標準出力は所有者へメールされる実装が多いが、メールの設定が無ければ誰も読めない

0 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

時刻とロケール

時刻がずれると何が起きるか

□ ログの時刻が食い違い、障害の順序が分からなくなる
□ TLS 証明書が「まだ有効になっていない」と判定される
□ トークンの有効期限の判定がおかしくなる

だからサーバーの時刻は NTP で自動的に合わせます。

timedatectl               # 現在時刻・タイムゾーン・同期状態
date -u                   # UTC で表示する

サーバーのタイムゾーンは UTC が基本です。 表示するときだけ日本時間に直します（見つけにくいバグで扱った通り）。

文字化けの正体

locale                    # 今の設定
# LANG=C.UTF-8 なら概ね安全

コンテナの中は LANG が設定されておらず、C（= ASCII 前提） になっていることがあります。 その状態で日本語を出力すると化けたり、Python が UnicodeEncodeError を投げたりします。

ENV LANG=C.UTF-8

詳しくは文字コードと改行コードを参照してください。

アーカイブと圧縮

ログを持ち帰る、バックアップを取る、といった場面で使います。

tar czf logs.tar.gz /var/log/myapp/    # c=作る z=gzip f=ファイル名
tar xzf logs.tar.gz                    # x=展開
tar tzf logs.tar.gz                    # t=中身を見るだけ  ← 展開前に必ず

tar tzf logs.tar.gz          # まず一覧を見る
mkdir tmp && cd tmp          # 出所の怪しいものは空の場所で開く

SSH — サーバーに入る

ssh intern@203.0.113.10
ssh -i ~/.ssh/id_ed25519 intern@example.com

鍵を作る

ssh-keygen -t ed25519 -C "you@example.com"
# ~/.ssh/id_ed25519      秘密鍵  ← 絶対に他人に渡さない
# ~/.ssh/id_ed25519.pub  公開鍵  ← これをサーバーに登録する

パスワードではなく鍵で入るのが基本です。理由は暗号と鍵の扱いにあります。

chmod 600 ~/.ssh/id_ed25519    # 400 でもよい。要は他人に読ませないこと

~/.ssh/config を書く

毎回長いコマンドを打たないために、接続情報をファイルに書けます。

Host staging
  HostName 203.0.113.10
  User intern
  IdentityFile ~/.ssh/id_ed25519
  Port 22

Host db-via-bastion
  HostName 10.0.1.20
  User intern
  ProxyJump staging          # 踏み台を経由する

これで ssh staging だけで繋がります。 踏み台（bastion）経由でしか入れない構成は実務で一般的なので、ProxyJump は覚えておくと効きます。

共有ライブラリ

「バイナリはあるのに動かない」時の話です。

ldd /usr/local/bin/myapp    # このプログラムが必要としているライブラリ
# libssl.so.3 => not found   ← これが原因

「ローカル（Debian ベース）では動くのに、Alpine のイメージだと
 no such file or directory と言われる」

実務の落とし穴まとめ

まとめ

• FHS を知っていれば、設定（/etc）とログ（/var/log）はすぐ見つかる
• root で常用しない。 sudo は事故を減らし、誰が何をしたかを記録する
• sudo で押し切らない。 所有者が間違っているだけのことが多い
• サービスは systemctl status → journalctl -u の順で見る。設定をいじるのはその後
• ディスクは df で全体、du で犯人。消したのに空かないなら lsof と df -i
• cron はあなたのシェルとは別の環境で動く。絶対パスとログ出力
• サーバーの時刻は UTC、文字コードは UTF-8 を明示する
• 秘密鍵は 600。~/.ssh/config を書くと世界が変わる

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次は、同じ「動かない・遅い」でも、 書いたコードそのものが遅い場合の話です。