コンテンツへスキップ

Technical

Overview

このページでは、大学や自ら学んだことのアウトプットとして、実際に手を動かしたことや調べて検証したことをまとめています。少し長いですけど読んでいただけると嬉しいです^^

Portfolio Site on AWS

本ポートフォリオサイトは、AWSアカウント作成から始めて、Lightsail上にLinuxサーバーを立ち上げ、Bitnami WordPress環境で構築・運用しています。単にページを作るだけでなく、公開に必要な土台(DNS・HTTPS・セキュリティ)まで含めて整える経験が欲しかったため、あえてサーバを立てる構成にしました。

サイトの枠組みを先に完成させ、公開にあたってまず行ったのが、DNS設定とhttps化です。単純なIPアドレスだと覚えづらいため、直感的に理解しやすいドメインを取得し、静的IPを割り当てました。HTTPS化はLet’s Encryptで証明書を発行して、Bitnamiのbncert-toolで一気に設定しました。Let’s Encryptの証明書は有効期限が短いため、bncert-toolの自動更新を前提に運用することにしました。ちなみにHTTP→HTTPSのリダイレクトも入れてあります。

最後に、最低限のセキュリティ対策として、FW設定で不要なポートを閉じ(22/80/443に制限)、fail2banによるSSH不正ログイン対策などを行い「公開できる状態」を一通り整えました。

苦労した点

今回、セキュリティ対策ツールとしてfail2banを導入したのですが、正常に動きませんでした。ログをチェックすると、fail2banのクライアントがソケットに接続できていないことが確認でき、これが「そもそも起動できていない」のか「起動はできているがソケットがずれている」のかを切り分ける必要がありました。そこでfail2banが実際に作っているソケットがどこにあるのかを確認し、 /run と /var/run のどちらを参照しているかの差分に着目しました。ネットで情報を集めると、最近のLinuxでは /var/run は実体として /run に寄せられるケースが多い一方で、Bitnamiなどの環境によっては参照が混在し、サーバー側とクライアント側で見に行く場所のズレが起こる場合もあることがわかりました。そこで、シンボリックリンクを作ってズレを吸収する対応を取り、再度実行すると、サーバーとクライアント間の通信が復旧しました。

この作業を通じて、セキュリティツールは「入れて終わり」ではなく、OSやディストリビューションによるログ管理方式・パスの差分を理解しながら合わせる重要性を再確認できました。また、エラー→調査→修正→検証のループを回して前に進めた点は、運用の現場で必要になる基本動作そのものだと感じています。

Linux on Laptop (Ubuntu)

サーバ運用の基礎に慣れるため、ノートPCにUbuntuを導入して日常的に触っています。ファイル操作やパッケージ管理などの基本に加え、SSH・権限管理・サービス管理・ログ確認まで一通り扱えるようになりました。

特に、このポートフォリオサイト構築では「エラーが出たらログを見る」「切り分けして原因を狭める」という流れを繰り返したため、Ubuntuでの習慣がそのままトラブル対応に活きました。今後も、簡単なスクリプト作成や運用の自動化など、実務に近い形で手を動かしながら学習を続けています。

Hardware / Device

ハードウェアに興味を持ったきっかけはPCゲームです。ゲームによってGPUが重要なケースやCPU・メモリが聞くケースがあると知り、CPU・GPU・メモリ・ストレージの役割や、ボトルネックの考え方を調べるようになりました。

「用途に対してどこに投資すべきか」を考えて、構成を比較検討したり、ベンチマークやモニタリングで状態を確認したりするのが好きです。限られた予算の中で、性能とコストのバランスを見て最適解を探す過程に面白さを感じています。

将来的には、クラウドだけでなくオンプレミス環境の物理サーバーやネットワーク機器にも触れ、より広い視点でインフラを理解できるようになりたいです。