開発環境での Linux 活用例

手元では通るのに、CI だけが落ちる

自動テストが赤くなったとき、手元にあるのは数行のログだけです。画面もエディタもありません。ところがこのログは、Linux のシェルが吐いた出力そのものです。読み方を知っていれば、そこに原因が書かれています。

Run ./scripts/build.sh
/bin/bash: line 1: ./scripts/build.sh: Permission denied
Error: Process completed with exit code 126

実行の許可が付いていないという知らせです。手元では以前に実行ビットを立てたので動き、その状態を記録せずにコミットしたため、取り直した側では立っていません。原因が読めれば、直し方は 1 つに定まります。

No such file or directory なら、動き出した場所が思っていたディレクトリと違います。CI のワーカーはたいてい Ubuntu なので、このコースで打ってきたコマンドがそのまま通用します。

コンテナの中は、別世界ではない

コンテナが立ち上がらないとき、外から眺めていても分かりません。中に入れば、これまでと同じ道具が使えます。

docker exec -it web sh

入ってしまえば、ls -la で置かれたファイルと権限を見て、ps で何が動いているかを見て、cat で設定を読む。手順は普通の Linux と変わりません。仮想マシンではなく、ホストのカーネルの上でプロセスを隔離しているだけだからです。

そもそも起動に失敗して入れないときは、外から出力だけを取り出します。

docker logs --tail 50 web

ここに出るのも、アプリが標準出力へ書いた文字列です。読む対象はログファイルのときと同じです。

同じスクリプトが、Mac では違う結果になる

本番は Linux、開発機は Mac という組み合わせが最も多い一方で、両者のコマンドは細部が違います。同じ名前でも中身が別の実装で、オプションの解釈が食い違います。

• sed -i は、Mac では書き換え後の拡張子を必ず要求します
• date の日付計算のオプションが、Linux と Mac で別の書き方です
• readlink -f は、Mac の既定では使えません

手元だけで確かめたスクリプトを本番に置くと、この差でこけます。避けたいなら、開発側を Linux に寄せるのが早道です。Windows なら WSL2、Mac ならコンテナの中で動かせば、本番との差が縮みます。

ここまでで、ファイル、権限、プロセス、ネットワーク、シェルスクリプトを一通り触りました。どれも、画面が無い場所で何が起きているかを自分の目で確かめるための道具です。次に進むなら、サービスの常駐を管理する systemd と、構成そのものをコードで残す仕組みが、そのまま地続きになります。