さくらサーバー – Laravel~インストール

概要

さくらレンタルサーバーのスタンダードプランを利用していて、そこにLaravelをインストールしてみた記録。以下の2つの方法を試してみた。

  • composerをドキュメントルートに配置し、ドキュメントルート下にプロジェクトを作成
  • composerをドキュメントルートと別の場所に配置し、ドキュメントルート下で公開

ローカルで開発したプロジェクトをデプロイする手順はこちら

ドキュメントルートへのインストール

composerのインストール

ssh接続後~/www(ドキュメントルート)に移動し、composer.pharをダウンロード。

インストール確認。

プロジェクト作成

~/wwwディレクトリーでテスト用のプロジェクトを作成。

動作確認

welcomeページ

ブラウザーでURLを指定。

結果は以下のエラー。

Forbidden
You don’t have permission to access this resource.

 

URLを以下のように指定して、welcomeページが無事表示される。ドキュメントルート下にプロジェクトを配置すると、publicディレクトリー内が公開対象になる。

ルーティング

以下のルーティングで'Hello'が表示される。

コントローラー

TestControllerコントローラーを作成してアクションを定義し、その中で文字列を渡す。

ルーティングを以下のように変更。

これでブラウザーに'Hello!'と表示される。

ビュー

resource/viewsディレクトリーに以下のビューファイルtest.blade.phpを作成。

TestControllerを以下のように修正。

これでブラウザーにアクセスすると、タブのタイトルが'Laravel Test'となり、h1要素のフォントで'Hello from blade!'と表示される。

別ディレクトリーへのインストール

composerのインストール

ドキュメントルート下にプロジェクトを配置するのは気持ち悪いので、別に配置する。ここではユーザーホーム下のディレクトリーに配置してみる。ライブラリーを加えていないので、インストールはcomposer.pharを移動して配置するのみ。

まずcomposer_testディレクトリーを作ってその下にcomposer.pharを移動。また、先にドキュメントルートに作ったプロジェクトを削除しておく。

移動先でcomposerの動作確認。

プロジェクトの作成

composer_testディレクトリー下に先と同じ手順でプロジェクトを作成。

公開ディレクトリーへのシンボリックリンク

公開ディレクトリー以外に配置したプロジェクトは、クライアントからは認識されない。そこでプロジェクトのpublicディレクトリーのシンボリックリンクをドキュメントルート下に作成する。

ここではシンボリックリンク名をプロジェクト名と同じ名前にして、~/wwwディレクトリー下に作成。

この状態で以下のURLを指定するとwelcomeページが表示される。

コントローラー・ビュー

新しいプロジェクトでTestControllerコントローラーを作成。

ビューを呼び出すアクションを定義。

ルーティングを定義。

resources/views/ディレクトリーにtest.blade.phpファイルを以下の内容で作成。

これでブラウザーにアクセスすると、タブのタイトルが'Laravel Test'となり、h1要素のフォントで'Hello from blade!'と表示される。

Laravelのバージョン指定

composerでプロジェクトを作成するときにLaravelのバージョン指定が可能だが、さくらサーバーでワイルドカードを使うとうまくいかない。

以下のようにワイルドカードを指定しない方法だと、無事にプロジェクトが作成される。

バージョン確認。

プロジェクトの設定

タイムゾーンとロケールをconfig/app.phpファイルで設定。

データベースはさくらサーバーの設定に従って、.envファイルで設定。DB_HOSTはmysql5.7アップグレード後の場合、phpMyAdminなどで使われるサーバー名。

 

さくらサーバー – MySQLのアップグレード

概要

2021年11月、さくらインターネットのカスタマーセンターよりメールがあり、内容はMySQL5.1, 5.5から5.7へのアップグレードを推奨するものだった。5.5のサポート終了やWordPressなどCMSの推奨環境のバージョンアップなどの背景によるもの。

私の環境はさくらレンタルサーバーのスタンダードプラン。後述の経緯もあって少しとまどったが、アップグレードとWordPressの設定を終えた。

状況としては、

  • MySQL5.5と並んで、既にMySQL5.7が稼働していた
  • WordPressで使っていたのはMySQL5.5の方

手順の概要は

  1. 5.7のWordPress用データベースを削除
  2. 5.5のWordPress用データベース以外を削除
  3. アップグレード予約・実行
  4. wp-config.php書き換え

経緯

今回の経緯は以下のとおり。

  1. 2016年、さくらレンタルサーバー(スタンダードプラン)の利用開始
    • このときにMySQL、WordPressも運用開始
  2. その後2021年6月までの間に5.5→5.7へアップグレード
    • アップグレード後も5.5は存続
    • このときにWordPressの設定は変更せず
    • このため、これ以降も投稿等は5.5の方に記録
  3. 2021年11月に5.7へのアップグレード推奨メール
  4. 2021年12月に再度アップグレードとWordPress設定変更完了

確認作業

データベース構成

メールを受けてさくらサーバーのコントロールパネルで確認したところ、以下の2つのデータベース(以下、DB)が存在。

  • mysql57.アカウント名.sakura.ne.jp→MySQL5.7
    (mysql2019.db.sakura.ne.jp)
    →システムの管理で使われるホスト名
  • mysql304.db.sakura.ne.jp→MySQL5.5

5.5のデータベースは以下のとおり。

  • information_schemaはMySQLの管理用
  • _wp1はWordPress用のDB
  • _main_testの2つはテスト用に自分で作成したもので、特に重要ではない

5.7のデータベースは以下のとおり。こちらにもWordPress用の_wp1があり、他のDBも5.5と同じ。

WordPress用データベース

MySQL5.5、5.7ともアカウント名_wp1のテーブル構成は同じで、以下のとおり。

ここで、5.5と5.7でwp_ts01_postsに以下のような違いがあった。

5.5の投稿数。投稿日付は2016年6月16日~2021年12月13日で確認時点の日付まで。

5.7の投稿数。2016年6月16日~2021年2月8日まで。

5.5に対して5.7の投稿数が少なく、途中までの投稿記録で途切れている。

wp-config.phpのMySQLホスト名を確認すると、以下のようにMySQL5.5の方のホスト名になっていて、MySQL5.7運用開始後もWordPressは5.5を使っている。

したがってMySQL5.7運用開始後もWordPressでは利用されず、投稿等は5.5の方に記録されていることになる。このことから5.7のWordPress用データベースを破棄して5.5のデータベースに入れ替え、設定変更することにする。

アップグレード

要点

アップグレードの要点は、さくらインターネットのサイトによると以下のとおり。

  • MySQLの5.5→5.7へのアップグレードは、既に5.7が存在していても可能
  • アップグレード先の5.7に5.5と同じ名前のDBが存在する場合はアップグレード不可
  • アップグレードはDBを指定して実行時間を予約
  • アップグレード後にWordPress等の設定変更が必要

データベースの整理方針

5.5のデータベースをアカウント名_wp1のみ残して削除し、アップグレード先の5.7の同じ名前のDBを削除。

  • 5.5の他のデータベースは自分で作成したテスト用のものだけなので、削除しても問題ない
  • 5.7のアカウント名_wp1は途中までしか投稿記録がなく、不要と判断
  • 双方のinformation_schemaは残置

アップグレードの予約

アップグレードの予約はコントロールパネルで行った。

  • さくらのコントロールパネルで
    • 5.7のアカウント名_wp1を削除
    • 5.5のアカウント名_wp1以外を削除
  • information_schemaはコントロールパネルでは表示されないが5.5、5.7とも残置
  • 12/21の02時にアップグレード予約

アップグレードの確認

翌朝確認したところ、MySQL5.7の方にアカウント名_wp1が作成されており、コンソールで確認したところ昨日までの最新の投稿が記録されていた。

コメントが2件、2時以降についていたが、いずれもspam判定のもので、内容も確認して無視。

WordPressの設定変更

コンソールでも可能だが、さくらインターネットサイトにあるとおりファイルマネージャーで実行。

  1. コントロールパネル左の”Webサイト/データ”→”インストール済み一覧”を選択して、でWordPressのインストール先を確認
  2. “Webサイト/データ”→”ファイルマネージャー”を開いて上記のディレクトリーに移動
  3. wp-config.phpを確認
  4. コンソールでwp-config.phpのコピーを別名で保存(バックアップ用)
  5. ファイルマネージャーでwp-config.phpを右クリック→編集
    • MySQLのホスト名の変更
    • DB名は同じ名前なので変更しない
    • パスワードも変更していないのでそのまま
  6. ファイルマネージャーで”保存”、”閉じる”

WordPressの設定後確認

設定変更後、以下を確認した。

  • WordPressが正常に表示される
  • 新規投稿を書き込み、投稿が反映されること、その内容がMySQLのDBのテーブルに反映されていることを確認
  • 新規投稿を削除し、削除が反映され、テーブルにも削除経緯が反映されることを確認

 

Vagrant – PHPインストール – FreeBSD

さくらのレンタルサーバーに合わせた仮想環境にPHPをインストール。bootstrap済みのpkgで簡単にインストールできた。

 

Vagrant – MySQLインストール – FreeBSD

pkgによるインストール

FreeBSDのバージョンが古いと言われたが、ミスマッチを無視することができるようなので無視して続行。

インストール直後の主要ファイルの存在状況は以下の通り。

/usr/local/etc/mysql/my.cnf → 存在
$HOME/.mysql_secret → 存在しない
/root/.mysql_secret → 存在しない
/usr/local/libdata/ldconfig/mysql57-server → 存在
/usr/local/share/mysql/mysql.server → 存在

 

MySQLサーバー起動

/etc/rc.confに以下の1行を追加してvagrant reload

サーバーの実行状況を確認。

サーバーを再起動する場合。

サーバーを起動すると.mysql_secretファイルが作成される。

初回ログインとパスワード変更

初期パスワードの確認

rootユーザーの初期パスワードは/root/.mysql_secretファイルに書かれている。

初回ログイン

パスワードを変更

SET PASSWORDクエリーでパスワードを変更。

日本語の設定

さくらサーバーでの日本語の扱い

インストールしたままの状態だと、ロケールやエンコーディングの設定が日本語の扱いに適していないので変更する必要がある。さくらサーバーのMySQLでの扱いは以下のようになっている。

OSのロケール

ロケールは日本(ja_JP)で文字コードはUTF-8で設定されている。

MySQLの文字コード

systemがutf8、databaseとserverがutf8mb4で設定されている。

MySQLの照合順序

databaseとserverの照合順序はutf8mb4_general_ciに設定されている。

Vagrantの設定

さくらサーバー上のMySQLの設定に合わせる。ロケール、文字コード、照合順序の詳細については以下を参照。

ロケール設定

/etc/profileに以下2行を追加してvagrantをリロード。

※’=’の前後にはスペースを入れない。

<変更後のロケール>

文字コードと照合順序の設定

/usr/local/etc/mysql/my.cnf[mysql]セクションと[mysqld]セクションに各々以下を追加してMySQLをリロード(sudo /usr/local/etc/rc.d/mysql-server restart)。

<変更後の文字コード>

<変更後の照合順序>

 

Vagrant – 環境構築 – さくらサーバー/FreeBSD

概要

さくらレンタルサーバーの環境をローカルのVagrantで構築。使用はできるだけ本家に近づけるようにした(2021年6月時点)。

ホストOS
Windows10
ゲストOS/Box
FreeBSD 11.2-RELEASE-p10 (GENERIC)
bento/freebsd-11.2
MySQL
mysql Ver 14.14 Distrib 5.7.34, for FreeBSD11.4 (amd64) using EditLine wrapper
PHP
PHP 7.4.20 (cli) (built: Jun 8 2021 01:11:43) ( NTS )

特にMySQLのインストールで行きつ戻りつして数日かかった。

FreeBSD仮想環境の構築

Boxのダウンロード

bento/freebsd-11.2のボックスを追加。

仮想環境のディレクトリー準備

Windowsで既作成の\vagrantディレクトリー下にsakuraディレクトリーを作成して移動。

イニシャライズ

仮想環境ディレクトリーを初期化。FreeBSDの仮想環境が構築され、vagrantfileが作成される。

仮想環境の起動

仮想サーバーの起動

vagrant upコマンドでFreeBSDの仮想サーバーを起動する。

仮想サーバーへの接続

vagrant sshで仮想サーバーにログインする。

タイムゾーン設定

初期状態はUTC。

タイムゾーンはtzsetupにタイムゾーンのファイルを指定して設定する。

まずtzsetupの場所を確認。

次にタイムゾーンファイルの場所を確認。

tzsetupTokyoを与えて実行。タイムゾーンファイルを使うかと尋ねられるのでYes。

タイムゾーン設定後

ファイル共有設定

Vagrantfile

以下の行のコメントを外して修正。

1つ目の引数

  • ホスト側の共有ディレクトリーのパスで、仮想環境を起動したディレクトリーからの相対パス
  • この設定ではC:\vagrant\sakura\shareがホスト側の共有ディレクトリーになる
  • このディレクトリーはホスト側で作成する必要がある

2つ目の引数

  • ゲスト側の共有ディレクトリーの絶対パス
  • この場合は~/shareがゲスト側の共有ディレクトリーになる
  • このディレクトリーは自動作成される

ホスト側の共有ディレクトリー作成

ホスト側のWindowsで共有ディレクトリーを作成

Vagrant起動/再起動

vagrant up/reloadでvagrantfileの内容を仮想マシンに反映させる。その結果、vagrantfileで指定したパスで仮想マシンにshareディレクトリーが作成される。

pkgのブートストラップ

MySQLやPHPなどをインストールするのにpkgによるバイナリーパッケージ管理を利用する。このため、pkgをブートストラップする。

 

 

さくらサーバー – MySQL – CSVファイルへのエクスポート

概要

MySQLへのCSVファイルのインポートについては、ターミナル上でのLOAD DATAコマンドによる方法を整理した。

テーブルやSELECTの結果のエクスポートについては、以下の方法がネット上でも一般的。

ただし、さくらレンタルサーバで上記を実行しようとすると、以下のようにエラーになる。

これはレンタルサーバのユーザディレクトリの権限がrwx---r-xとなっていて、MySQLからの書き込みが制限されているためらしく、レンタルサーバでこの権限を変更することは難しい。

phpMyAdminを使ったエクスポートなら、ブラウザ上での操作でテーブルのダウンロードが可能。

phpMyAdminを起動する

さくらレンタルサーバのコントロールパネルを立ち上げ、「データベースの設定」をクリック。

phpmyadmin-start-1

データベースの設定画面で、「管理ツールログイン」をクリック。

phpmyadmin-start-2

新しいタブでphpMyAdminのログイン画面が立ち上がるので、MySQLのユーザ名とパスワードを入力して「実行する」ボタンを押す。

phpmyadmin-login

phpMyAdminでのエクスポート操作

ログイン後の画面の左にデータベースの一覧があるので、エクスポートするテーブルがあるデータベースを選択。

phpmyadmin-select-database

データベース内のテーブル一覧が表示されるので、エクスポートするテーブルにチェックを入れて、「チェックしたものを」のドロップダウンリストから「エクスポート」を選択。

phpmyadmin-table-selection

エクスポート画面の左でCSVを選択すると、右側がCSVのオプション設定になる。

  • フィールド区切りのデフォルト';'','に変更
  • フィールド囲み記号のデフォルト'"'を残すか、必要に応じて削除
  • その他は適当に
  • 「ファイルに保存する」のチェックを外す
  • エンコーディング変換はしない
  • 「実行する」ボタンで、[テーブル名].csvのファイルがダウンロードされる

phpmyadmin-csv-settings