Project Brief Linuxサーバー構築の学習概要

Ubuntuを使った個人学習

Linuxの状態を見られるWebアプリを動かし、確かめ、復旧する

学ぶ方へ: 仕組み → 小さい実習 → 結果の確認を順に進め、自分の記録で1分説明します。採用担当者の方は、このページで作品の目的と確認範囲をご覧ください。

主作品「Server Monitor」は、CPUの使用率やメモリなど、Linuxの状態を確認する学習用のWebアプリです。Ubuntu（OSという土台）の上で、nginx（通信の入口）がapp（応答を作るプログラム）へ要求を渡します。アプリを置くだけでなく、設定・認証・動作確認・復旧・引き継ぎまでを学ぶ題材にしています。実務経験はまだありません。AIによる文章・コード・テストの作成補助を含み、本人の実行範囲は記録で示します。

過去の検証記録：いつ、どの環境で、何を確認したか

記録した日付・環境・コードの版に限った結果です

2026年9月4日の追加記録: 本人PCのHyper-V上で、Ubuntuの基盤構築を実施しました。Ansibleのfoundation.ymlで基本設定とDockerを用意し、再実行時に不要な変更が出ないことを確認しています。AlmaLinux 9.7の記録は、以前使ったVMへの基盤適用と再実行です。新規構築・SSHだけの最小公開は未証明です。監視システム全体の実行や本番稼働を示すものではありません。

2026年8月22日から25日にかけて、次の記録を残しました。通しでの動作テスト23項目、前の版への切り戻し（変更を前のバージョンに戻す作業）、ディスク拡張、問題箇所の調査、データベース復元、ネットワーク確認です。いずれも、使い捨てのUbuntu（無料で使えるLinuxの一種）環境、WSL2（Windowsの中でLinuxを動かす仕組み）、Docker（アプリを箱に入れて動かす仕組み）、Linux内の分離環境で得た結果です。長く動かし続けている実際のサーバーでの結果ではありません。現在の確認範囲と未実施（NOT RUN）の範囲は、現行mainの証跡台帳を正本（もとになる正しい記録）とします。証跡台帳とは、いつ、どの環境で、何を確認したかを一覧にした記録です。

実装済み 6工程のコード、設定、手順、チェックリストを作って公開しました。作成済みであること自体は、稼働実績を意味しません 実測済み 日付、実行環境、対象の版、結果を記録した確認だけを「実測済み」と表示します。いずれも学習環境の中での確認です 未実施（NOT RUN） 次はまだ行っていません。独立した対象サーバーでの受け入れ確認、72時間の連続稼働、Slackへの実際の通知、AWS apply/destroy（クラウド上に環境を作って消す操作）、D-2（2つ目の復旧演習）、本番環境の変更です

Server Monitorを見る動作確認の記録を見る構築手順・確認資料仕事の進め方

取り組みの概要

学習課題

小規模なWebサービスをUbuntu上で動かす

Webアプリ、外部からの接続、監視、ログ、異常時の通知を設定します。そのうえで、動作確認、復旧の練習、引き継ぎ資料の作成まで行います。

前提・制約

個人学習／AIを補助として使用

個人制作です。プログラムの作成や問題の調査には、AIも補助として使用しました。ほかの人によるレビュー（第三者レビュー）は受けていません。手元VMでの基盤構築など、確認済みの範囲は検証証跡台帳に記録しています。監視システム全体について、独立した対象ホストでの受け入れ確認と本番環境の変更は未実施です。

目標

作業の流れと結果を自分の言葉で説明する

設定内容、作業手順、期待した動き、実際の結果、元に戻す方法、分かっている制約をそろえます。合格だけでなく、失敗、環境上できなかったこと、未実施も記録します。

実務を想定した作業フロー

かんたんに言うとサーバーを1台つくって人に渡すまでを、6つの段階に分けています。設計（何をどう作るか決める）、構築（実際に組み立てる）、試験（決めたとおりに動くか確かめる）、監視（異常に気づく仕組みを入れる）、復旧（壊れたときに元へ戻す練習）、引き渡し（次の人が運用できる状態にする）の順です。

01 / 実装済み設計要件・基本設計・詳細設計
パラメータ・通信を定義
02 / 実測済み構築 Ansible（設定作業の自動化ツール）とCompose（複数のコンテナをまとめて起動する仕組み）を実行
2回目に不要な差が出ないかも確認しました
03 / 実測済み試験期待値・実測値・環境
対象版を記録
04 / 実測済み監視メトリクス（機械の状態を表す数値）・ログ・通知を
学習環境の中で確認しました
05 / 一部実測済み復旧 D-1（1つ目の復旧演習）で同一環境へ復元
D-2（2つ目の復旧演習）はNOT RUN（未実施）
06 / 実装済み 引き渡し チェックリストを作成
対象ホスト（引き渡し先のサーバー）での受け入れはNOT RUN（未実施）

作成した資料

かんたんに言うと下の表は「どの工程で、どんな資料を作ったか」と「その資料が、作っただけなのか、実際に動かして確かめたのかどうか」を並べたものです。成果物の欄のリンクから、実物の資料をそのまま読めます。

Linuxサーバー構築学習で作成した資料と確認状況
工程	成果物	採用担当者が確認できること	確認状況
設計	基本設計／詳細設計／パラメータシート	目的、非機能（性能や安全性など）、構成値、ポート、監視、バックアップの考え方	実装済み（文書）
構築	Ansible／Compose／構築手順	同じ手順を繰り返せる設定、自動化した範囲、手作業が必要な範囲	実測済み 2回目は不要な変更なし
試験	確認手順／2026年8月22日の記録／以前の記録	期待した結果、実際の結果、詳しい記録、未実施の項目	実測済み一時Ubuntu環境で23項目合格
監視・復旧	復旧手順書／障害対応の練習	異常を見つけた後の確認、復旧するかの判断、復旧時間、失敗からの改善	実測済み D-1・同一環境への復元 D-2はNOT RUN
引き渡し	引き継ぎチェックリスト／変更を戻す手順	運用開始条件、既知の制約、切り戻し後の確認方法	資料は実装済み対象ホスト受入はNOT RUN

なぜこの構成にしたか

かんたんに言うとADRとは、設計で迷ったときに「何をどう決めたか」と「なぜそう決めたか」を残しておく記録のことです。ここでは、5つの決めごとを理由つきで並べています。

ADR-01

まずUbuntu 1台に範囲を固定

まず1台分を最後まで構築・確認することを優先しました。複数台で止まりにくくする構成は今後の課題です。

ADR-02

自動設定を用途ごとに分ける

Ansibleの設定を、基本、Docker、Web接続、監視の4つに分けました。役割ごとに分けたので、変更した場所を見つけやすくなりました。同じ設定を2回実行しても、2回目に不要な変更が出ないことも確認しました。

ADR-03

管理画面を外部へ直接公開しない

監視画面は、原則としてサーバー内部からだけ接続できる設定にしました。外部に公開すると、誰でも監視画面をのぞける状態になってしまうためです。別の管理端末や独立した実機からの接続は、まだ確認していません。

ADR-04

監視の数値とログを同じ画面へ

サーバーの数値と同じ時刻のログを行き来して確認できる構成にしました。Windows上のLinux環境で実際のデータ表示を確認しています。

ADR-05

未実施も理由を残す

まだ試していない項目は「未実施」と理由を記録します。一時的なテスト環境での成功を、独立した実機での成功とは表現しません。

結果・学び・次の一手

実際に確認できたこと

一時的なUbuntu環境で設定を2回実行し、2回目に不要な変更が出ないことを確認しました。同じ手順を繰り返しても同じ状態になる、と言えます。
監視に必要な11個のサービスを起動し、異常と復旧の通知、ログの受け取りを確認。
停止させたサービスの自動復旧と、監視データをバックアップから戻せることを確認。
前の版への切り戻し、ディスク拡張、データベース復元、通信障害の調査を練習。
実際に動かして見つけた問題29件を記録し、誤って合格にしていた6件はテスト方法も修正。

まだ確認していないこと

継続して使うサーバーでの切り戻し、72時間の連続稼働、再起動後の確認。
監視ツールから実際のSlack（チャットの連絡ツール）へ通知することは、まだ試していません。
AWS上での作成・削除と、別サーバーへの復旧。
独立した管理端末とサーバーを使った構築、接続、運用。

面接で説明できる改善事例

D-1演習では2回失敗しました。原因は、障害をわざと起こす方法（障害注入）の誤りと、手元に残っていた古いブランチ（作業用の枝分かれ）だと切り分けました。成功した結果だけでなく、誤った前提、確認に使ったコマンド、修正、やり直した試験まで記録しています。

動作確認の記録を見る仕事の進め方次の実機検証