EC2に公開できないなと諦めた3日間+4日間～HTTPS 化したのちEC2へデプロイする～

はじめに

AWSのEC2に本番環境を構築しようとしたとき、思った以上に多くの落とし穴があり、何度も手が止まりました。デプロイと一口に言っても、環境や構成、使っている技術スタックによって必要な手順は千差万別で、聞きなれない言葉ばかり、、、、。
何を準備すればいいのか、どこでつまずきやすいのか、最初はまったく見えていませんでした。

この記事では、私が実際にEC2への本番デプロイでつまずいたポイントを振り返りながら、押さえておきたいチェック項目をざっとまとめてみました。これから本番環境へのデプロイに挑戦する方の道しるべになれば幸いです。

目次

セットアップ環境

AWSでHTTPS通信を安全にする

EC2にデプロイする時のチェック項目

EC2再リリースするコマンド

セットアップ環境はこちら

Left align	言語	バージョン
バックエンド	Laravel	12
フロントエンド	Vue	3.5.22
※ビルドツール	Vite	7.1.9
データベース	MySQL	8.0.44
Webサーバー	Apache	2.4.65 (Amazon Linux)
AWS	サーバー	EC2インスタンス
	データベース	RDS(MySQL)
OS	windows	11
ターミナルソフト	RLogin	(SSH 接続済)
ディレクトリ	/var/www/html	※ec2-userではないため注意

※Vue.jsでApexCharts.jsを実装
※セキュリティグループではHTTP(80)、 HTTPS(443)、 SSH(22) が許可されている

まずはAWSでHTTPS通信を安全にする

HTTPは以下すべて盗まれる可能性がある

• 入力フォームの内容
• パスワード
• Cookie
• 認証トークン

それに比べてHTTPS通信はSSL/TLSによって通信が暗号化されるため、本番環境では必須の通信となります。ELB 経由の場合は ELB 側で SSL/TLS 終端するのが一般的

HTTP通信をHTTPS通信にリダイレクトする

HTTPS443で証明書を発行し、ドメインアクセスを確認できたら、
HTTP80の通信先をHTTPS443へリダイレクトさせるように変更する

リスナールールでルーティング先がターゲットグループでしたが、「URLにリダイレクト」に変更。「HTTPS」の「443」へリダイレクトにする

早速EC2にデプロイしていこう

Laravel単体で開発する分にはデプロイは比較的簡単ですが、パッケージやComposerを導入すると、依存関係や構成が複雑になって難しくなります。

AWSでは以下でリリースを行いました。

Laravel・EC2デプロイのチェックリスト

• インストールの確認(EC2側の環境構築)

  • PHP
  • MySQL
  • Composer ※ビルド含む
  • Git

• SSH接続の権限の確認

• storage/logs と vendor の権限変更

• php-fpm

• Apache サービス起動

• GithubからLaravelアプリをCloneする

• .envファイル作成

  • アプリケーションキー(APP_KEY)生成
  • DBテーブル作成

• マイグレーション・シーディングの実行

• キャッシュのクリア

• その他

• エラーログの確認

✅各種EC2側の環境構築

これから使用する環境を整えるため、以下のソフトウェアをコマンドでインストールする

• PHP
• MySQL
• Composer
• Git

// 確認方法
php -v
mysql --version
composer --version
git --version
apachectl -v
npm -v	※必要な場合は確認する

✅SSH権限の確認

GitHubにSSH接続するために、公開鍵をGitHubに登録する

• GithubにSSHで接続 443に向いているか確認

ssh -T -p 443 [e-mail]

• SSHキーを作成、公開キーが必要

ssh-keygen -t rsa -b 4096 -C "[e-mail]"

• Githubにパブリックキー登録

// 公開鍵の内容を確認
nano ~/.ssh/id_rsa.pub

Laravelでのセッションとセキュリティ設定を保存するためのCookie／Session／Storage の権限設定

.env

SESSION_DRIVER=cookie
SESSION_SECURE_COOKIE=true

SELinux ラベル
どのようなセキュリティコンテキスト（ラベル）が付与されているかを確認でき、SELinux によるアクセス制御の判定に使用される。

// SELinuxラベルの確認
ls -Z /var/www/html

sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/storage
sudo chcon -R -t httpd_sys_rw_content_t /var/www/html/bootstrap/cache

✅storage/logsの権限変更

storage/logs/laravel.log
Laravel実行中に発生したエラーやログ情報を記録するファイル

APP_ENV=production
APP_DEBUG=false
LOG_CHANNEL=stack

Apache（Webサーバー）が書き込み可能であることを確認

ls -ld storage/logs

✅vendorの権限変更

vendorはLaravelなどのPHPアプリケーションで使われる 依存パッケージ群（Composerでインストールされる）を格納する vendor/ ディレクトリに対して、適切なアクセス権限を設定する

• Laravelプロジェクトのルートに vendor/autoload.phpが存在することを確認

composer install
// composer.lock に記載されたバージョンと一致している


// Webサーバーが読み取り可能な権限になっている
ls -ld vendor

※デプロイ時にComposerが実行される場合は、デプロイユーザーに書き込み権限が必要となる

✅php-fpm

Webサーバー（NginxやApache）とPHPの橋渡しを行い、同時アクセスや高負荷に強い構成で、PHPの設定ファイルを編集して調整できる

sudo nano /etc/php/8.1/fpm/pool.d/www.conf

✅Apache サービス起動

Apache（Webサーバー）がどのユーザー権限で動いているか確認する

ps aux | grep apache
ps aux | grep httpd

# 所有者をApacheユーザーに変更（例：apache）
sudo chown -R apache:apache storage bootstrap/cache

# 書き込み権限を付与
sudo chmod -R 775 storage bootstrap/cache

sudo systemctl start httpd

• Apache 設定ファイルで DocumentRoot を Laravel の public/ に設定されているか確認

DocumentRoot /var/www/laravel_project/public

• Apache 書き込み権限確認
  ・storage や bootstrap/cache の Apache 書き込み権限確認

ls -ld storage/logs bootstrap/cache

✅GithubからLaravelアプリをCloneする

※クローン先が正しい確認/var/www/html以下に配置すること

// ルートディレクトリに移動して、クローンする
 cd /var/www/html
 git clone [e-mail]:[アカウント名]/[リポジトリ名]

✅.envファイル作成

Laravelの APP_URL　.env に以下記載

APP_URL=https://your-domain.com/laravel

アプリケーションキー(APP_KEY)生成

php artisan key:generate

✅マイグレーション・シーディングの作成

php artisan migrate

※必要な場合はシーディングも作成する
php artisan db:seed

・データベース存在ありの確認

mysql -u root -p

✅キャッシュクリア

 php artisan cache:clear
 php artisan config:cache
 php artisan route:cache
 php artisan view:cache

その他

• HTTPSリダイレクト先が間違ていないか
• WordPress側の .htaccess がLaravelのURLを邪魔していないか確認
• SSL証明書　Apache/NginxでSSLが正しく設定されている
• アクセス・ルーティング先の確認(.htac　public/.htaccess が存在し、mod_rewrite が有効)
• SELinux 状態

✅エラーログ確認のコマンド

• Apache の設定ファイルをまとめて確認する

sudo cat /etc/httpd/conf.d/*.conf

HTTP から HTTPS へリダイレクト する設定が書かれている

  # return 301 https://$host$request_uri;
  # listen 443 ssl;
  # ssl_certificate /etc/letsencrypt/live/onehouse.click/fullchain.pem;
  # ssl_certificate_key /etc/letsencrypt/live/onehouse.click/privkey.pem;

• HTTPS で指定サイトにアクセスして、詳細な通信状況を確認する

curl -v https://your-project.jp

• ブラウザからアクセスされたすべてのリクエストを受け取るファイルに余計な出力やエラーがない確認する

nano public/index.php

// サーバー起動エラーの確認
sudo tail -n 50 /var/log/nginx/error.log

// Laravel のログ確認
tail -n 50 storage/logs/laravel.log

// .env ファイルの値を参照する、
　　DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORDの確認
cat config/database.php

// Apache の SSL エラーログ確認
sudo tail -n 50 /var/log/httpd/ssl_error.log

再デプロイで詰まった箇所

• public/index.php は Laravel アプリのエントリーポイントであり、ここに dd() を書いていたことにより500が出た

cat /app/Http/Middleware/TrustProxies.php

• PHP-FPM と mod_php の環境差が起こっていた
  　→今回はPHP-FPM(HP実行環境)
• .env におけるセキュア設定（APP_URL= https://…, SESSION_SECURE_COOKIE=true, SESSION_DOMAIN=… など）

GitHubの変更を本番環境に再リリースする手順

• gitHubからクローン
• キャッシュのクリア
• HTTPSページ確認

// ステージ変更がある確認
git status

//　変更分を削除
git restore .

// gitHubからクローン
git pull origin main

// キャッシュクリア
php artisan optimize:clear

// errorログ確認
tail -n 160 /var/www/html/OneHouse/onehouse/storage/logs/laravel.log

package.json、package-lock.jsonを変更した場合は
node_modules は Git 管理外のため毎回npm installが必要

• ビルドするための容量を確保するためのスワップを作成
• npm インストール
• npm ビルド

// メモリ使用状況を確認、2GB以下でスワップを作成
free -h

// スワップ作成
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

npm install
npm install --no-audit --no-fund　(軽量版)

npm run build

// Vite でビルドされた本番用CSS・JSがあるか確認
ls public/build

新しいテーブルをつくった、既存テーブル内容を変更した場合に行う

• マイグレーション作成

php artisan migrate 

まとめ

今回この記事をまとめるのに、およそ、１か月ほどかかりました。
最初の３日間で初デプロイに苦戦して、その後ログイン機能を追加しての再リリースで４日間～６日間ほど時間を要し、試行錯誤した内容を項目ごとに理解するまで１か月といった具合です。

今回、LaravelにVueやらVite他パッケージを含んだプロジェクトであったためボリュームが多く設定に時間がかかる結果となりましたが、なんとか一通りの環境構築を完了することができました。

サーバー側なのか、.envファイルの設定なのか、HTTPS通信接続問題なのかの状況を切り分ける力がついたと思います。
今後は、この経験を活かして GitHub Actions を活用したデプロイ自動化 にも挑戦していきたいと考えています。