今日は、ここから1つ進める
初めてなら「環境がまだない」から。今の状態に合う作業を1つ選び、終わったら「何が分かったか」を1文残します。
環境の準備・起動がこれからなら、図の次に主作品の準備手順へ。初回実習全体は準備済みで90〜120分が目安です。詳細資料はGitHubで開きます。
サーバーの「入口・返答・確認」を、ひとつずつ
この作品は、サーバーのCPUやメモリなどの数値を見られる個人学習用のラボです。サーバー構築とは、必要なソフトと通信の設定を用意し、使える状態を確かめること。最初はapp と nginx の2サービスで「応答する」「認証で守る」を学びます。
1. 理解する：要求はどこを通る？
「数値を見せて」という要求を送り、応答を受け取ります。このやり取りのルールがHTTPです。まず、次の3つの役割を覚えます。
- 要求する人ブラウザ / curl
画面やコマンドから
「見せて」と頼む127.0.0.1:8080 - 入口・転送係nginx
要求を受け取り
appへ渡すapp:5000 へ - 認証・返答係app
必要な認証を確認し
画面や数値を返すapp.py
動かす土台は Ubuntu（LinuxのOS）。Docker が app と nginx を別々のコンテナ（プログラムと実行環境をまとめて動かす単位）で動かし、Docker Compose が設定ファイルを読んで起動をまとめます。
/healthz も nginx を通って app に届きます。8080 と 5000 は通信の入口を区別するポート番号です。この構成で利用者が入るのは 8080。5000 は内部のapp用です。127.0.0.1 は「今操作しているコンピューター自身」なので、Windowsと別のUbuntu VMでは指す相手が違います。
図と実際のコードを結び付ける
compose.yaml の app・nginx・ports が部品と入口、nginxの設定の proxy_pass が転送先です。app.py の protect_sensitive_routes が認証、/api/stats が数値を返す処理に対応します。
2. 実行する：まずは4つの応答を見る
操作の手順は 主作品 server の初心者向け学習ガイドに集約しています。「実行場所と準備」→ Step 1・2 → Step 3 の順に進み、app と nginx を起動します。初回実習全体の目安は準備済みで90〜120分。途中で区切って構いません。
- 破棄できる専用Ubuntu 24.04環境のBashで、
compose.yamlのあるserver直下にいる。 - ガイドの前提診断に
FAILがなく、設定と秘密値の準備を終えている。 docker compose ps --all app nginxで app がUp・healthy、nginx がUp。nginxにhealthy表示は不要。
準備が足りない場合は理由を付けて BLOCKED（実行できず保留）。Windows PowerShellへBashの手順を貼り付けず、ガイドの準備へ戻ります。
条件がそろったら、同じUbuntuのターミナルで次を実行します。「入口からappへ届けば 200 になるはず」と予想してから結果を見ます。
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/healthzcurl は要求を送る道具です。この書き方は応答の本文を表示せず、HTTPコードだけを表示します。続けてガイドの「3-3. 応答と認証を分けて確認する」の残り3件を、1行ずつ実行します。パスワードはガイドどおり入力し、コマンドや学習記録には書きません。
端末やファイル操作が初めての場合
練習環境の準備とファイルを1つ作る「最初の30分」を先に行います。現在のフォルダと保存した内容を確認できたら、このサーバー実習へ戻ります。ファイル作成だけではサーバーの動作確認は完了しません。
3. 確認する：数字を見て、どこまで分かった？
以下は初期設定と秘密値の準備が正しくできたときの期待値です。あなたの実測結果ではありません。実行日時・Ubuntuの環境・コードの版（git rev-parse HEAD）と、4件それぞれの実際の結果を残します。
| 送る要求 | 期待値 | この結果から分かること |
|---|---|---|
/healthz | 200 要求成功 | nginxを経由してappが応答する。認証・監視・復元の合格は別に確かめる。 |
認証なしの / | 401 認証が必要 | 認証なしでは画面を取得できない。ここでは期待どおり。 |
tokenなしの /metrics | 401 認証が必要 | 数値の収集用にも認証が必要。画面用パスワードとは別のtokenを使う。 |
正しいBasic認証付きの /api/stats | 200 要求成功 | 正しいユーザー名とパスワードで数値取得の要求に成功する。 |
成功の判断は「全部200」ではなく、要求ごとの期待値との一致です。このcurlには -f を付けていないため、コマンドの終了コードが 0 でもHTTPが 401 や 503 のことがあります。
期待値と違うとき：502・000・503をどう読む？
- 502：nginx経由でこの値が返るなら、入口からappへの通信を調べます。appの状態とログを確認し、コードだけで原因を断定しません。
- 000：curlがHTTP応答を取得できなかった表示です。サーバーが返すHTTPコードではありません。実行場所、宛先、nginxの状態、接続エラーを確認します。
- 503：appの認証用秘密値が未設定などの場合にも返ります。appのログと設定を、秘密値を記録へ載せずに調べます。
ガイド Step 4-1 の状態 → ログ → 通信 → 設定へ戻ります。実行結果が期待と違えば FAIL。未実行の項目は NOT RUN のまま残します。
ここまでの合格条件：4件の予想と実結果を記録し、下の問いに図を見ずに答えられること。そろったらガイド Step 4・5で計画停止・再開・終了と説明までを行います。その後は主作品のStep 6で監視を加え、Level 0〜5の道筋で未確認の範囲へ進みます。このページの8段階の構築演習は、VM本体のOS・SSH・設計・引き渡しを補うときに使います。
4. 説明する：自分の記録を使って1分で話す
まず図を隠し、「利用者 → nginx → app」を紙に描いて、要求と応答の向きを声に出します。次の問いは答えと「なぜなら」を先に1文ずつ書いてから開きます。合わなかった理由と、戻って読む場所を記録します。読むだけで実行結果が増えることはありません。
問い1：Ubuntu、Docker、nginx、appは何を担当しますか？
Ubuntuは動かす土台のOS、Dockerはコンテナを動かす仕組みです。nginxは要求を受け取ってappへ渡し、appは必要な認証を確認して画面や数値を返します。Composeは設定をもとに複数のサービスの起動をまとめます。
問い2：/healthzは200、認証なしの画面は401。画面を200に直すべきですか？
認証なしで見せないことが目的なので、この401は期待どおりです。この実習では / と /metrics を認証で守ります。/healthz の200で分かるのは入口経由のappの応答まで。正しい認証での取得、監視の収集、バックアップからの復元は、それぞれの試験が必要です。迷ったら4件の要求と期待値へ戻り、「誰に何を許可する試験か」を確かめます。
問い3：nginxを停止すると、appが動いていても使えないのはなぜですか？
利用者が通る入口が停止するからです。この構成ではappの5000番をホストへ直接公開していません。ガイドの計画停止で観測する接続エラーと、nginx再開後の200を記録します。自分で停止・再開した結果は、自動復旧の実績とは分けます。
問い4：教材の期待値・自動テストの成功・自分の実測は、同じ証拠ですか？
それぞれ確認した対象と実施者が違います。教材の期待値は予想、自動テストの成功はそのテストが調べた範囲の結果です。どちらも、学習者本人が実機で操作し、意味を説明できた証拠にはなりません。面談では、自分が実行した日時・環境・コードの版・実結果を根拠にします。公開済みの過去試験は参考資料、未実施は NOT RUN。AIの補助を受けた範囲と、自分で操作・確認・説明できる範囲も分けます。
4行を書けば、説明に使う材料がそろう
- 目的と予想：【何を確認するために、どの応答を予想したか】
- 実行：【日時・環境・コードの版・自分が行った操作】
- 確認：【4件の実結果と期待値との比較・秘密情報を除いた記録の場所】
- 説明：【分かった理由・まだ未実施のこと・次に確認する1つ】
詳しく残すときは、主作品の初心者実習記録テンプレートを使います。初期値は NOT RUN。実行前に成功へ書き換えません。
面談で使う1分の型
「サーバー構築を学ぶ個人ラボで、入口のnginxがappへ要求を渡し、appが認証して数値を返す構成を学んでいます。私が【環境】で行ったのは【自分の操作】です。【確認した要求】の期待値【予想】に対し、【実結果】を得て、【記録の場所】に残しました。【その結果から説明できる理由】が分かりました。【未実施の範囲】はNOT RUNです。AIの補助は【使った範囲】で、自分が確認したのは【確認した範囲】です。」
翌日の復習：図の3つの役割と、200・401の意味を資料なしで言います。数日後はガイドを見ながら起動・確認・終了をもう一巡し、前回の記録と比べます。答えを暗唱するだけでなく、実際の結果から理由を説明できれば、この小さな実習は習得の目安を満たします。
読むだけで終わらせず、「予想する → 実行する → 証拠を残す → 説明する」の順で進めます
このページは成果物を見る順番ではなく、未経験者が手を動かす順番です。各段階は、目的・前提・操作・期待結果・失敗例・合格条件という同じ型で確認します。型をそろえるのは、次に何を見ればよいか迷わないためです。分からない言葉はインフラ基礎用語集（意味・具体例・確認方法つき）か、一言用語集へ戻ります。冒頭の所要目安12〜20時間は、「8段階の学習ルート」本編8つを合計した時間です。下の準備教材（環境構築・最初の30分・困ったとき・提出前レビュー）に使う時間は、この12〜20時間には含みません。
個人PCの中に作ったVM（1台のPCの中に作る仮想のパソコン）またはWSL2（Windowsの中でLinuxを動かす仕組み）で実施します。職場・学校・第三者のサーバーでは実行しません。ファイルの削除、Firewall（決めた条件で通信を許可・拒否する関所）の変更、SSH（離れた場所からサーバーを操作する通信）の設定変更は、元に戻せなくなる危険があります。実行する前に、スナップショット（今の状態をまるごと保存したもの）を取り、戻し方を確認します。パスワード、秘密鍵、トークンはコマンド行や公開ログへ書きません。
AWS（Amazonが提供するクラウドサービス）での構築、Slackへの実際の通知、72時間連続試験、別ホスト復元（別のサーバーへ復元し直すこと）は、手順は設計済みです。ただし、このリポジトリ（このサイトのファイル一式を置いている場所）では未実測（NOT RUN／手順はあるが実行していない）です。実際に行った範囲だけ、状態の表示を変更します。各Stepの証跡（作業した証拠として残すログや記録）では、MEASURED（実際に測った結果）とNOT RUN（未実行）をはっきり分けて示します。できていないことを、できたように見せないためです。
完全未経験者向けの準備教材
WSL2・VMを選ぶ
必要な空き容量、制限（できないこと）、導入の手順、削除の手順、スナップショットの取り方までを、コース別に確認します。
最初の成功体験
画面に出る表示例とその意味を読みながら進めます。ファイルの作成、確認、記録、片付けまでを一続きの流れで行います。
止める・調べる・相談する
よくあるエラーから安全に復帰し、秘密情報を除いて質問します。
完成水準を見比べる
記入前の空のテンプレート、架空の完成例、そして採点根拠（どこを見て点を付けるか）を確認します。提出前に、自分の成果物がどこまで書けていれば合格かを知るためです。
開始チェック
- CPU、メモリ、ディスク、IPアドレスを自分の言葉で説明できる（Step 0の合格条件で確認）
- 端末（キーボードで命令を打ち込む黒い画面）を開き、現在位置と終了コード（直前のコマンドが成功したか失敗したかを表す数字）を確認できる
- 8GB以上の空き容量があり、作った検証環境（練習用の使い捨ての環境）を後から消しても困らない（学習環境を0から用意するの必要容量と削除方法を参照）
- パスワード、秘密鍵（本人だけが持つ電子の鍵ファイル）、トークン（サービスに入るための合言葉）を、Git（変更履歴を残す仕組み）へ保存しないと理解している（CUI入門 7. 変更コマンドの前に6点確認を参照）
- 困ったら作業を止め、現象・直前操作・時刻を記録できる（エラーFAQ「まず行うこと」を参照）
8段階の学習ルート
主作品を続ける入口はserverのLevel 0〜5です。以下はVM本体の構築・設計・引き渡しを補う教材です。教材ごとの役割を見て必要な段階を選び、対象と確認条件が同じ自分の記録は再利用します。Docker内とVM本体の確認は区別します。
チェックは、各カードの合格条件を自分の実行記録で確かめたときに付けます。「次の候補」は最初の未確認項目で、着手・合格の自動判定ではありません。チェックだけでは、実機の動作や本人の習得を証明できません。
チェックはこのブラウザだけに保存されます。日時・環境・実結果の記録は、実習記録テンプレートへ別に残します。
かんたんに言うとここからは、設計・構築・確認・復旧・引き渡しを段階ごとに学ぶ本編です。DockerのWebサービスと、VM本体のSSH・nginxは別の演習として記録します。各カードは「前提（始めてよい条件）→必要なものと影響→目的→操作→期待（うまくいった状態）→失敗例→合格（次へ進める条件）」の順に読みます。上から順に進め、合格の条件を満たしてから次のStepへ移ります。
環境と安全を確認
前提: 環境準備ガイド完了。一般ユーザー、8GB以上の空き、削除方法。
必要なもの: OSの種類、空き容量、IPアドレス、Gitの状態を調べられること。影響: この段階では設定を変更しない。
目的: 壊してよい範囲を決める。
操作: OS、容量、IP、Git状態を採録。例: bash scripts/capture-lab-evidence.sh preflight（Step 0の詳細手順）
期待: 環境情報ファイルが作られる。
失敗例: 実機とVMの取り違え。
合格: 削除方法と秘密情報の扱いを説明できる。
要件と構成を決める
前提: Step 0に合格していること。用語集でIPアドレス、Port（通信の入口番号）、RTO／RPO（RTOは復旧までにかけてよい時間の目標、RPOは失ってよいデータの時間の上限）を確認しておく。
必要なもの: 文書を書くことだけ。管理者権限もインターネット接続も要らない。影響: サーバーの設定は変わらない。
目的: 作業前に完成条件を決める。
操作: 利用者、通信、RTO/RPO、除外範囲を記入。（Step 1の記入項目）
期待: 要件と構成図が対応する。
失敗例: 技術名だけで目的がない。
合格: 「誰が何のために使うか」を1分で説明できる。
最小OSを準備
前提: Step 1に合格していること。Ubuntu（Linuxの一種）のVM、スナップショット、コンソール経路（SSHが使えなくなっても画面から直接操作できる別の入口）を用意しておく。
必要なもの: インターネット接続と管理者権限。影響: システム設定が変わる。SSHの設定を変える前に、締め出されたときのために別の接続経路を残しておく。
目的: 初期状態を再現する。
操作: Ubuntu VM、一般ユーザー、SSH、更新を準備。例: ssh -i ~/.ssh/lab_key student@192.0.2.10（Step 2の詳細手順）
期待: 管理端末から鍵で接続できる。
失敗例: SSH変更後に接続不能。
合格: 再起動後も接続でき、バージョンを記録できる。
手動で最小構築
前提: Step 2に合格していること。Package（導入しやすくまとめたソフト）、Service（動き続ける機能）、Port、Firewallの意味を用語集で確認しておく。
必要なもの: Docker（アプリを箱に入れて動かす仕組み）を導入すること。影響: Firewallの設定が変わる。失敗したらスナップショットから戻せる状態にしておく。
目的: 自動化の前に構成を理解する。
操作: A: DockerのWeb応答を自分のPC内で確認。B: VM本体のSSHとFirewallを別に確認。例: ss -lntpで待受portを確認（Step 3の詳細手順）
期待: AのローカルWeb応答と、BのSSH許可・拒否を別々に確認する。
失敗例: UFWでDockerの公開ポートも遮断できたと思い込む。
合格: AとBの通信経路・実結果・ログ位置を図で説明できる。
Ansibleで同じ状態を作る
前提: Step 3合格。Git差分とYAMLの基本を確認。
必要なもの: Ansible（設定作業を自動で行うツール）。影響: サーバーの設定が書き換わる。いきなり適用せず、syntax-check（書式の確認）とcheck（変更の予行演習）をapply（実際の適用）より先に実行する。
目的: 人による手順差を減らす。ここではVM本体にnginxを入れる独立した入門演習を行う。
操作: syntax-check、check、applyを順に実行。例: ansible-playbook -i inventory.ini playbook.yml --check --diff（Step 4の詳細手順）
期待: 同じ手順を2回目に実行すると、不要な変更が0になる（冪等性＝同じ操作を何度実行しても結果が変わらない性質）。
失敗例: 変数未定義、権限不足。
合格: changed=0と差分を証跡に残せる。
監視と通知を確認
前提: Step 4に合格していること。Metrics（時間ごとの数値データ）、Logs（出来事の記録）、Alert（異常を知らせる通知）、Runbook（状況別の対応手順書）を用語集で確認しておく。
必要なもの: Docker Composeで複数のコンテナをまとめて動かす構成。影響: 通知先は自分のPCの中だけで、外部サービスへは送らない。
目的: 利用者より先に異常へ気付く。
操作: メトリクス、ログ、ローカル通知を確認。例: docker compose up -dで監視スタックを起動（Step 5の詳細手順）
期待: 発生時刻と復旧時刻が追える。
失敗例: 監視自身の停止を見逃す。
合格: アラートからRunbookへ移動できる。
障害を切り分ける
前提: Step 5の正常値を採録済み。障害演習の共通ルールを確認。
必要なもの: 管理者権限。影響: わざとサービスを止めるので、動かなくなる。原因が分からなくならないよう、壊すのは1回に1つだけにする。どうなったら演習を中止するかを、先に書いておく。
目的: 勘ではなく事実で原因を狭める。
操作: 仮説、確認、結果、次の判断を記録。例: Dockerの lab-web は docker logs --tail 20 lab-web、VM本体のnginxは sudo journalctl -u nginx -n 50 で状態変化のログを確認（Step 6の詳細手順）
期待: 復旧前後の証拠が残る。
失敗例: 記録前に再起動する。
合格: 原因と再発防止を第三者へ説明できる。
復元して引き渡す
前提: Step 6に合格していること。バックアップ、checksum（ファイルが壊れていないか確かめる要約値）、RTO／RPOを用語集で確認しておく。
必要なもの: 新しく作るVMと、十分な空き容量。影響: 復元先のVMだけを変える。元のデータには一切手を加えない。
目的: バックアップが使えることを確かめる。
操作: 復元、整合性確認、RTO/RPO採録。例: sha256sum backup.tar.gzで値を計算し、保存済みの正しい値と比較。さらに復元後の内容と動作を確認（Step 7の詳細手順）
期待: 手順だけで再現できる。
失敗例: バックアップを取っただけで終わり、実際に復元できるか試していない。
合格: 結果票、残課題、切り戻しを引き渡せる。
正常に動くことを確認した後に行う8つの障害演習
かんたんに言うとわざと故障を起こして、直す練習をします。下の表の矢印は、原因を探すときに確認する順番です。手前から順に「ここは正常」と確かめていき、最初に異常が見つかった場所が原因の候補になります。
| 障害 | 最初の確認 | 完了条件 |
|---|---|---|
| SSH接続不可 | IP → 経路 → TCP/22（SSHが使う通信の入口） → Firewall → sshd（SSH接続を受け付ける側のプログラム） | 通信を止めている箇所を特定し、別の接続経路で復旧 |
| Web応答なし | DNS → TCP → Proxy → App → DB | 依存関係ごとに合否を記録 |
| ディスク逼迫 | df（ディスク使用率を表示） → inode（ファイル管理情報の残数） → du（ディレクトリ配下の使用量を集計） → ログ | 削除前に原因と保持要件を確認 |
| CPU高騰 | uptime（稼働時間と負荷平均を表示） → top（プロセスごとのCPU/メモリ使用率をリアルタイム表示） → ps（実行中プロセスの一覧） → ログ | 対象プロセスと発生時刻を特定 |
| メモリ不足 | free（空きメモリ量を表示） → ps → journal/OOM（メモリ不足によるプロセス強制終了） | 再起動だけに頼らず原因を記録 |
| 設定破損 | 構文検査 → Git差分 → 直前変更 | 修正または切り戻しを選択 |
| TLS（通信を暗号化する仕組み）の期限異常 | 名前解決 → 時刻 → 証明書の期限・SAN（証明書が有効な名前の一覧） | 更新手順と、期限切れ前に知らせる監視のしきい値を説明 |
| バックアップ破損 | サイズ → checksum → 展開 → 復元 | 代替世代を選び整合性を確認 |
修了判定と次の行動
かんたんに言うとここは自己採点のやり方です。左の5つの成果物がそろっているかを確かめ、右の5区分（各20点、合計100点）で自分に点を付けます。まだ実行していない項目は「NOT RUN」と記録し、推測で加点しません。必須区分の確認がそろうまで、修了判定は保留します。
必須成果物
- 要件・構成図・パラメータ
- 構築と確認の手順
- 再実行結果とテスト結果
- 障害記録と復旧記録
- 引き渡し報告と残課題
100点ルーブリック（採点の基準表）
- 安全・秘密情報 20点
- 設計の説明 20点
- 再現可能な構築 20点
- 監視・切り分け 20点
- 復旧・記録・引き渡し 20点
80点以上かつ各区分12点以上を取れたら修了とします。未実施は「NOT RUN」と記録して加点せず、必須区分に未確認があれば修了は保留します。面接では「この範囲は実施済み、この範囲は未実施」と分けて説明できる状態を目指します。