laraveコンテンツを基盤移行した話

■前提条件

・移行コンテンツがgitに格納されている
・基盤はAWS

１．AWSの作成・初期設定

新規にアカウントを作成するところから。
今回はサービス利用を目的としておらず、表示・動作すればよいためIAMなどの権限設定は行わない。
そのため、AWSアカウントを作成して終わり。

２．EC2作成・ログイン

無料枠でインスタンスをひとつ作成する。
OSはAmazonLinux2023。
DBは腹持ちにするため、以下をインストール。
・git
・mariadb
・php
・php-fpm
・composer
・nginx

３．gitにログイン

認証がかかっていたので、接続確認含めてgitにログイン。
ここで、コンソールからclone実施用のトークンを発行する。
１）画面右上のアイコンタブをクリックし、Settingsを押下
２）左ペイン一番下にあるDeveloper settingsを押下
３）Personal access tokensを押下
４）Tokens（classic）を押下
５）Generate new tokenを押下
６）必要事項を選択
７）Generate tokenを押下
８）出力されたトークンをコピー（テキストエディタなどで保存するとよい）
詳しくはこちら

【GitHub】アクセストークン（Access Tokens）の生成手順まとめ【Java勉強ログ #8】

４．コンテンツをclone

トークンを入手できたら、gitにあるコンテンツをEC2の特定のディレクトリにcloneします。
今回は、/配下の/presenに作成したのでそちらで。

$ cd /sudo
$ mkdir /presen
$ sudo chown ec2-user:ec2-user /presen
$ cd /presen
$ git clone https://github.com/[コンテンツ格納アカウント]/[コンテンツ格納リポジトリ].git

ここで認証が入るので、アカウントと３．で用意したトークンを入力する。
認証が通るとコンテンツをダウンロードできる

５．laravelを更新する

cloneしたディレクトリでupdateを行う

$ cd /presen/[コンテンツ格納リポジトリ]
$ composer update

dnfでインストールしたのであれば、composerのpathは通っているが、通っていないのであれば、composerが格納されている場所を調べる。

$ find / -name "composer"

私は面倒くさいのでよく/配下から調べるのだが、rootユーザで実施しても標準エラー出力がいっぱいでるため、2> /dev/nullをよく付けます。

６．nginxの設定

今回はDNSを利用しないため、sslの設定は行い。
serverディレクティブの80だけ修正した。
一応、Basic認証も実施。

    server {
        listen       80;
        listen       [::]:80;
        server_name  _;
        root         /presen/[コンテンツ格納リポジトリ]/public; #ドキュメントルートを編集
        index index.php; #デフォルト表示されるファイルを指定

    location / {
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;　# Basic 認証用定義

    location = /favicon.ico { access_log off; log_not_found off; } 
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php-fpm/www.sock; # php-fpmのソケット場所に修正
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
        }
        }

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
        location = /404.html {
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        }
    }

７．php-fpmの設定

listenを変更した気がする
nginxで指定したパスと同じものにする。

listen = /run/php-fpm/www.sock

※/runは/var/runのシンボリックリンク

８．nginxの起動確認

起動してみる。
特にエラーはでないと思うが、発生時はログを確認して対処する。
・確認するべきログ
　/var/log/nginx/error.log
　※権限的にrootユーザでしか見れない
なお、AmazonLinux2023はsyslogとしてmessageが作成されない初期設定のため、journalctlコマンドで確認する必要がある。

９．DB設定・起動

mariadbを起動してみる。
DB側の修正は特に必要なく、不足分は後で実施する。
まずはスキーマを流せるようにする。

sudo systemctl start mariadb

必要なパッケージがインストールされていればこれで起動するが、起動しない場合はパッケージ不足を疑う。
以下を入れておけば問題なさそう。
mariadb105-devel
mariadb105-server
mariadb-connector
mariadb105-common

１０．DBにログイン

エラーなく起動したらログインしてみる。

sudo mysql -uroot 

インストール時にパスワードが記載されたログファイルが生成された時代もあったが、これで入れた。
sudoが強力すぎるので、公開するコンテンツを配置するサーバなどは適宜権限設定を怠らないようにする。

１１．DBの作成とユーザの作成

スキーマを流す用のDBを作成する。
何のDBを作成すればよいのかわからない場合、一度スキーマを流してやるとエラーが出るので参考にしてDBを作成する。

mysql -u[ユーザ名] -p[ユーザのパスワード] < sample.bakcup #スキーマファイルを指定する

DBの作成

CREATE DATABASE [DB名];
SHOW databases;

実行後、DBリストに作成したDBが存在していることを確認する。

次に一応一般ユーザを作成しておく。

CREATE USER '[ユーザ名]'@'localhost';

ULTER USER '[ユーザ名]'@'localhost' IDENTIFIED BY '[ユーザ名ユーザのパスワード]';

詳しくはこちら

MySQLユーザ作成について - Qiita

１２．スキーマを流す

一般ユーザの作成を行ったが、権限設定をしていないためスキーマを流せないと思うので、結局rootユーザで流した。

mysql -u[ユーザ名] -p[ユーザのパスワード] < sample.bakcup #スキーマファイルを指定する

１３．nginxを再起動

nginxを再起動して、DBのデータを反映させる。

$ sudo systemctl restart nginx

エラーが発生した場合は、８．nginxの起動確認を参照しエラーを取り除く。

１３．ブラウザで表示確認

EC2に付与されている外部アクセスが行えるアドレスをコピーし、ブラウザからアクセスしてみる。
いざ鎌倉。