Linux入門：コマンド操作のきほん

開発環境での Linux 活用例

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

開発環境での Linux 活用例 とは

開発現場でLinuxがどのように活用されているか、具体的な例を通して学びます。本レッスンでは、開発環境での Linux 活用例 の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

なぜ重要か

ここまで学んできたコマンド群は、単体で覚えるだけでなく、日々の開発フローに組み込まれて初めて価値が出ます。Git でコード管理し、Docker でアプリを動かし、SSH でクラウドへ入り、CI/CD で自動化する。これらはすべて Linux の知識がベースで、ファイル、プロセス、ネットワーク、シェルスクリプトの基礎が分かっていれば、トラブル時に「何が起きているか」を自分で追跡できるようになります。

このレッスンでは、本コース全体で学んだコマンドが「実際の開発現場のどこに現れるか」を俯瞰します。Git, Docker, SSH 経由のリモート開発, WSL2, CI/CD の各シーンで Linux が背骨になっている様子を一つの絵で繋ぎ、次に学ぶべき方向性まで示します。

全体像 開発者が触る Linux

diagram (will load when visible)

ローカル PC からスタートし、シェル経由で Git / Docker / SSH を叩く。Git push をきっかけに CI が回り、Docker イメージを作って本番サーバーへデプロイする。この一連のワークフローの構成要素は、ほぼすべて Linux 上で動いています。

Git とシェル

ターミナル

# 現在のブランチをプロンプトに出す PS1='\u@\h:\w$(__git_ps1 " (%s)") \$ ' # 直近 10 件のコミットを 1 行ずつ git log --oneline -10 # 変更ファイル一覧をエディタへ git status --short | awk '{print $2}' | xargs code

Git は Linux カーネル開発のために生まれたツールで、設計思想がシェルと相性抜群です。alias を ~/.gitconfig に書き、コマンド出力を awk/sed で繋ぐと、開発フローが一気に速くなります。

Docker は Linux カーネルの上に建つ

ターミナル

# 走っているコンテナとプロセスツリーを並べる docker ps --format '{{.ID}}\t{{.Image}}\t{{.Names}}' # コンテナに入ってシェル操作 docker exec -it myapp bash # コンテナの環境変数を覗く docker exec myapp env | sort # ログを末尾追跡 docker logs -f --tail 100 myapp

Docker コンテナの中身は Linux そのもの。コンテナ内で ps, ls, cat /etc/os-release, df -h がそのまま使えます。「コンテナの調子がおかしい」と感じたら、まず exec で中に入って ps, ls -la, cat /proc/1/cmdline を打つのが定石です。

Docker は仮想マシンではなく、ホスト Linux カーネルの上で namespace と cgroup によってプロセスを隔離しているだけです。だからカーネルバージョンはホストに依存し、Mac や Windows ではアダプタ的に Linux VM を裏で動かしています。これを知っているとイメージサイズや起動速度の差が腑に落ちます。

SSH と リモート開発

ターミナル

# 鍵ベースで接続 ssh -i ~/.ssh/id_ed25519 user@app01.example.com # 多段 SSH (踏み台経由) ssh -J bastion.example.com user@app01.internal # ローカル 8080 をリモート 80 にトンネル ssh -L 8080:localhost:80 user@app01.example.com # rsync で同期 rsync -av --delete ./dist/ user@app01:/var/www/html/

クラウドサーバーへのアクセスは SSH が事実上の唯一手段で、~/.ssh/config にエイリアスを書いて使い回します。VSCode の Remote-SSH 拡張や JetBrains の Gateway は、内部で SSH トンネルを張ってリモートのファイルとプロセスをローカルのように扱える機能です。

WSL2 と macOS

ターミナル

# WSL2 (Windows 上の Linux) wsl -l -v wsl --install -d Ubuntu # macOS は Darwin uname # Darwin

WSL2 は Windows 上に本物の Linux カーネルを VM として動かす仕組みで、エンジニア向け Windows 開発の事実上の標準です。macOS は BSD 系 Unix で、ls cd grep などはほぼ同じ感覚で使えますが、sed や date などコマンド単位でフラグが微妙に異なるため、スクリプトを Linux と Mac で共有する場合は GNU 版 (gsed, gdate) を入れて統一する流派もあります。

「本番は Linux、開発機は Mac か Windows」が現実的に最頻パターンです。WSL2 や Docker を介してローカル開発を Linux 化すると、本番との差分が減り、デプロイ時の事故も減ります。

CI/CD ランナーの正体

ターミナル

# GitHub Actions のワーカーは Ubuntu LTS # .github/workflows/test.yml jobs: test: runs-on: ubuntu-22.04 steps: - uses: actions/checkout@v4 - run: | uname -a node --version npm test

GitHub Actions, GitLab CI, CircleCI のランナーはほぼ Ubuntu です。CI が落ちたとき、ジョブログには ls, cat, grep の結果がそのまま出ます。Linux のコマンドを直接読めることが、CI 失敗のデバッグ速度を決めます。

エディタとシェルの組み合わせ

ターミナル

# 最近編集した markdown を fzf で選んで開く find . -name '*.md' -mtime -7 | fzf | xargs code # 大量のファイルを一括置換 grep -rl 'old_api' src | xargs sed -i 's/old_api/new_api/g'

IDE 内蔵の Find & Replace だけでなく、grep / sed / xargs を使えると、IDE が手につかない巨大リポジトリやリモート環境でも同じ感覚で作業できます。

ファイル管理の癖を再利用する

本コースで学んだ次のコマンドは、開発現場の至るところで再登場します。

  • find でビルド成果物を一括削除
  • tar / gzip でログをまとめてダウンロード
  • ls -la でコンテナ内のパーミッション確認
  • chmod 600 で SSH 鍵の権限を直す
  • ps aux | grep node で固まったプロセスを掴む

次に学ぶと良いこと

  • bash よりさらに高機能な zsh / fish と starship プロンプト
  • systemd の Unit ファイル設計 (サービス / timer / socket)
  • Ansible / Terraform などの構成管理 / IaC
  • Linux のシステムコール (strace, perf, eBPF) を使った詳細トラブルシュート
  • ネットワーク詳細 (iptables 後継の nftables, tcpdump, Wireshark)

よくある間違い

  • Docker コンテナ内なら自由に書き換えていいと思い、コミット忘れで消える
  • SSH 鍵を chmod 644 のままで動かず原因不明と勘違いする
  • WSL2 と Windows のファイルシステム間 (/mnt/c) を頻繁に行き来し、I/O が遅くなる
  • 本番サーバーで apt upgrade を打って、依存ライブラリの巻き込みで service が落ちる

まとめ

  • Git / Docker / SSH / CI のすべてが Linux カーネルとシェルの上に立っている
  • コンテナの中も同じ Linux であり、これまで学んだコマンドはほぼそのまま通用する
  • 本番が Linux なら、開発機を WSL2 や Docker で Linux 化すると差分が減って事故が減る
  • 開発フローを高速化するには、シェル芸 (find / grep / sed / xargs / fzf) と alias の活用が効く
  • 次のステップは systemd, IaC, システムコール解析、現代ネットワーク (nftables / eBPF) へ広げる

次のレッスン

次は 総合チェック で、開発現場でLinuxがどのように活用されているか、具体的な例を通して学びます を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. 開発環境での Linux の要点を自分の言葉で説明できる
  2. このレッスンの最小コード (または操作手順) を見ずに書ける
  3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. 開発環境での Linux とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン

参考リンク