変更要約: 初版
4.4運用と実践
配備・運用の現場で使うbashの基本コマンド（ファイル/ディレクトリ操作＝ls/cd/pwd/mkdir/cp/mv/rm/cat、環境変数 export/env）を「このコマンド列は何をするか」という読解として、そしてDevOps原則（文化・自動化・計測・共有）を「なぜこの実践が価値を生むか」という判断として学びます。
自動化のスクリプトも CI のジョブも、最後はシェル（bash）の上で動きます。だから「このコマンド列は何をするか」を正確に読めることは、配備・運用の基礎体力です。同時に DevOps は特定のツール名ではなく、開発と運用の壁を壊し、自動化と計測で速く安全に届ける文化と実践を指します。この節では、bash の基本操作と環境変数の扱いを読解として、DevOps 原則を「なぜ価値があるか」の判断として整理します。
4.4.1ファイル・ディレクトリ操作
- 現在地と一覧：
pwd（現在のディレクトリを表示）／ls（中身を一覧、ls -lで詳細、ls -aで隠しファイルも）／cd path（移動、cd ..で一つ上へ）。移動先を取り違えると相対パスの解釈がずれるため、まずpwdで現在地を確認するのが安全。 - 作成・複製・移動・削除：
mkdir dir（ディレクトリ作成、mkdir -p a/b/cで親ごと）／cp src dst（複製、ディレクトリはcp -r）／mv src dst（移動または改名）／rm file（削除、rm -r dirで再帰）。cat fileはファイル内容を表示する。rm -rは元に戻せないため、対象を確認してから実行する。
4.4.2環境変数
- 環境変数＝プロセスに渡す設定値（API のURL、接続先、secret など）。
export NAME=valueで設定し、echo $NAMEで参照、envで一覧を確認する。設定をコードに埋め込まず環境変数で外から与えることで、同じイメージを開発/本番で切り替えられる（前節の secret 管理とも直結）。 exportした変数はその後に起動する子プロセスへ引き継がれる（例：export API_URL=https://api.example.comの後に実行したアプリがos.environで読める）。exportを付けずにNAME=valueとしただけの変数は現在のシェルに留まり子プロセスへ渡らない——ここを取り違えると「アプリが設定を読めない」障害になる。
4.4.3DevOps原則
- DevOps＝開発（Dev）と運用（Ops）の壁を壊して協働し、リリースを速く・安全にする文化と実践。要点は文化（責任の共有・非難しない改善）・自動化（build/test/deploy をパイプライン化）・計測（変更失敗率やリードタイムを指標化）・共有（知見と可視性の共有）。特定製品の導入そのものが DevOps なのではない。
- 価値の出方：手作業の反復を自動化すると人為ミスと待ち時間が減り、小さく頻繁にリリースすれば1回の変更の影響範囲が小さく切り分けが速い。計測があるからこそ「速くしたら壊れやすくなっていないか」を事実で判断できる。CI/CD（前々節）は DevOps の自動化を体現する仕組み。
「pwd=現在地・ls=一覧・cd=移動・mkdir=作成(-pで親ごと)・cp(-r)/mv/rm(-rは再帰・不可逆)・cat=表示」「環境変数はexport NAME=valueで設定・$NAMEで参照・envで一覧・exportした変数だけ子プロセスへ継承」「DevOps＝Dev/Opsの壁を壊す文化・自動化・計測・共有(特定製品導入がDevOpsではない)」が頻出です。設問はコマンド列が何をするか／なぜこの実践が価値を生むかの判断として来ます。
あなたはデプロイ用の bash スクリプトを引き継ぎ、次の断片の意味を問われました：mkdir -p /opt/app/logs の後に cp -r ./build /opt/app/ を実行し、続けて export API_URL=https://api.example.com としてから python /opt/app/build/main.py を起動しています。これを順に読むと、まず -p 付きでログ用ディレクトリを親ごと作成し（既にあってもエラーにしない）、次にビルド成果物をディレクトリごと再帰コピーし、環境変数 API_URL を設定してからアプリを起動しているので、アプリは os.environ["API_URL"] でその URL を読める、と説明できます。ここで運用担当が「本番で API_URL がアプリに反映されない」と相談してきました。よくある原因は、設定を export せずに API_URL=... とだけ書き、しかもアプリ起動を別のシェル/ジョブで行っているケースです。export していない変数は現在のシェルに留まり、後から起動する子プロセスへ引き継がれないため、アプリからは未設定に見えます。修正は、アプリを起動するのと同じ実行文脈で export API_URL=...（または起動コマンドの直前に環境として付与）することです。この小さな挙動の違いを押さえていれば、「アプリが設定を読めない」障害をシェルの仕組みから即座に切り分けられます。さらに、この手順を毎回手打ちしているなら、それこそ DevOps 的にパイプライン化・自動化して人為ミスを減らし、rm -r のような不可逆操作を安全側に倒すべきだ、という改善提案までが実務の判断です。要は、bash の一行一行を正確に読む力と、それを自動化・計測・共有で継続的に良くする DevOps の視点が、運用の質を決めます。
| コマンド | 役割 | 例 |
|---|---|---|
| `pwd` / `ls` / `cd` | 現在地表示／一覧／移動 | `cd /opt/app && ls -l` |
| `mkdir` | ディレクトリ作成（`-p` で親ごと） | `mkdir -p /opt/app/logs` |
| `cp` / `mv` / `rm` | 複製／移動・改名／削除（`-r` は再帰・不可逆） | `cp -r ./build /opt/app/` |
| `export` / `env` | 環境変数の設定／一覧（子プロセスへ継承） | `export API_URL=https://api.example.com` |
ひっかけ： 「NAME=value と書けば export しなくても後で起動する別プロセスに必ず引き継がれる」は誤りです——export していない変数は現在のシェルに留まり子プロセスへ渡らないため、アプリが設定を読めない障害になります。また「DevOps とは特定の自動化ツールを導入すること」も誤り＝DevOps はDev と Ops の壁を壊す文化・自動化・計測・共有であって、製品導入そのものではありません。
4.4.4この節のまとめ
- bash の基本：
pwd/ls/cdで位置と一覧、mkdir（-p）/cp(-r)/mv/rm(-rは不可逆)/catで操作。まずpwdで現在地確認 - 環境変数は
export NAME=valueで設定し$NAME/envで参照。exportした変数だけが子プロセスへ継承され、設定はコードでなく環境で外から与える - DevOpsは Dev/Ops の壁を壊す文化・自動化・計測・共有。小さく頻繁なリリースと計測で速さと安全を両立する（特定製品導入が DevOps ではない）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. デプロイスクリプトに `mkdir -p /opt/app/logs` という行がある。この `-p` オプションを付けたときの挙動として最も適切なものはどれか。
Q2. あるスクリプトが `API_URL=https://api.example.com`（export なし）と設定した後、別のシェルジョブで起動したアプリが `os.environ["API_URL"]` を読めずに失敗する。原因と対策として最も適切なものはどれか。
Q3. マネージャが「DevOps を導入したいので、特定の自動化ツールを1つ買って入れれば完了だ」と言っている。DevOps の考え方に照らした評価として最も適切なものはどれか。