2020年12月8日、CentOS8のサポートは2021年末に終了し、今後はCentOSとしての新規リリースは行わない（CentOS StreamもしくはRHELに移行して）と言う発表があって、CentOS組に衝撃が走りました（とか言ってますが、世情に疎い私がこの状況を知ったのは最近ですが…）。
当然ながら世間の反発も強いようで、RHEL系に見切りをつけて新天地を求める動きも加速しているようです。
見たところ、本命「Ubuntu」対抗「Oracle Linux」大穴「Rocky Linux」と言ったところでしょうか？（個人的見解）
弊社もCentOS組でしたが、今後の身の振り方を考えざるを得ません。
今後OS（Linux）として何を担ぐかと言うことを考えた場合、以下のポイントを考慮する必要があります。
- ホスティング屋さんが当該OS搭載の環境を提供してくれること
- 開発環境を構築しやすいこと（Virtualbox/Vagrant）
- ネット上に参考情報が多いこと
- OS自体の信頼性（社会での運用実績）
上記観点から考えた場合、個人的知識および若干のリサーチから導き出された結論はほぼほぼ「Ubuntu」一択でしたが、どうでしょうか？
逆に、Ubuntu自体は世界的シェアで言えばNo.1のLinuxディストリビューション（日本のみNo.1はCentOS）らしいので、Ubuntuに乗り換えて問題と言うことはないでしょう。
と言うことで、今回からはUbuntu組の駆け出しとして精進して行きたいと思います。
まずは今までのおさらいも含めて、UbuntuにLaravel環境を構築したいと思います。
具体的な作業内容は以下の通り。
- Virtualbox/Vagrnt環境構築（Virtualbox / vagrant のすゝめ）
- Webmin/Virtualmin環境構築（Webmin / Virtualmin のすゝめ）
- phpMyAdminインストール（Virtualmin環境でphpMyAdminを使う）
- composerインストール（Laravel環境構築）
- Laravelインストール（Laravel環境構築）
- 自作ライブラリインストール（自作ライブラリの管理（git＋composer））
- Xdebugのインストール（LaravelでTDD）
- DB環境構築（LaravelでTDD）
- phpunit動作確認（LaravelでTDD）
括弧内は関連する過去記事（CentOSベース）のタイトルです。上記の通り実施する内容が多いため、本記事ではCentOSと違いがある部分を重点的に記述して行きたいと思います。逆に言えば細かな点は端折って行きますので、良く分からない点が出てきらた上記過去記事も見てみてください（それでダメならGoogle先生に）。
Virtualbox/Vagrnt環境構築
まずはUbuntuのVagrant用Boxを見つけてきます。
Ubuntuの最新LTS版は20.04（コードネーム：Focal）なので、これに該当しそうな物を下記サイトで探します。
https://app.vagrantup.com/boxes/search上記結果「ubuntu/focal64（Official Ubuntu 20.04 LTS (Focal Fossa) builds）」が見つかりました。これを使いたいと思います。
vagrant init ubuntu/focal64Vagrantfileは最小限の設定として以下くらいにしておきます。
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu/focal64"
config.vm.network "private_network", ip: "192.168.33.12"
config.vm.provider "virtualbox" do |vb|
vb.name = "ubuntu_focal64"
vb.memory = "1024"
end
end実は上記設定では後に問題が発生しますが、今のところはこれで。
あとは普通に起動します。
vagrant up特に問題なく起動できるかと思います。
Webmin/Virtualmin環境構築
パッケージの管理方法はCentOSとUbuntuで大きく異なります。CentOSでは「yum」ですが、Ubuntuでは「apt」なるコマンドによって管理しています。
まずは起動したvagrant（Ubuntu）環境にログインし、rootユーザーになった後、以下の２つのコマンドを黙って実行しましょう。
apt update
apt upgrade 前者がパッケージ情報の更新、後者がパッケージの更新と日本語にしても似ていてややこしいですが、分かる人には分かるだろうと言うことで進めます。
さて、ここではまずWebminをインストールしたいのですが、それ自体は以下のコマンドで実行できます。
apt -y install webminただし、この段階ではエラーになります。
E: Unable to locate package webminWebminなんてパッケージがどこにあるかなぞ知らん！と言うことですね。yumでもリポジトリの設定が必要なケースはありました。aptでは「/etc/apt/sources.list」と言うファイルに追加したいリポジトリの情報を記述するようです。
Webminに関して前述のファイルに追記すべき内容は以下になるようです。
deb https://download.webmin.com/download/repository sarge contribUbuntuはDebianと言うLinuxディストリビューションのさらに派生系であり、パッケージ管理に関してはDebian方式を踏襲しているようです。
上記書式は意味的には以下のような構造になっているようです。
deb uri suite component最初の「deb」は「バイナリパッケージのリポジトリ」を意味する模様で、「deb-src」（ソースパッケージのリポジトリ）なる設定もあるようです。
次の「https://download.webmin.com/download/repository」が「uri」で、Webminと言うパッケージがどこにあるかを示す情報と考えれば良いでしょう。ちなみに、CentOSでは「https://download.webmin.com/download/yum」にアクセスしてインストールするパッケージを選択する形になっていました。
「sarge」と「contrib」はそれぞれ「suite」と「component」に当たります。「suite」としては「stable（安定版）」のようにパッケージの状態（完成度）を指定をするケースや「focal」のように当該ディストリビューションのコードネームを指定するケースがあるようです。「component」に関してはDebianでは「main」「contrib」「non-free」の3タイプだったようですが、Ubuntuでは「main」「restricted」「universe」「multiverse」の4タイプに分けるようにしているようです。それぞれの意味ですが、ネット情報を元に独自解釈した結果としては以下のようになります。
（Debian様式）
main：フリーソフト
contrib：フリーソフトだけど、フリーソフトじゃないソフトにも依存しているかも
non-free：フリーソフトじゃない
（Ubuntu様式）
main：Canonicalの人がサポートしてくれるオープンソースソフト
restricted：Canonicalの人が管理してくれるがオープンではないソフト（ドライバなど）
universe：コミュニティの人がサポートしてくれるオープンソースソフト
multiverse：上記3タイプ以外
※CanonicalはUbuntuの支援及び開発援助を目的とする会社です。
上記情報に基づいて先のWebminの設定内容を見てみると、明らかにDebianを意識したものですね。
そもそも「sarge」はDebianのコードネームで2005年6月6日に公開されたような古い物です。「contrib」もDebian様式ですし。
ただ、上記のように細かく見てきましたが、単純に言えばパッケージの在処を特定するための情報の組み合わせに過ぎず、実体としてはサーバ（IP）やパスに変換されるだけの情報のようです。実際に「https://download.webmin.com/download/repository」にアクセスすると「dists」なるフォルダが存在し、その配下に「sarge/contrib」フォルダが存在して、ここにパッケージ関連ファイルが置かれているようです。
「dists」配下に「sarge」以外のフォルダが存在せず、「sarge」配下に「contrib」以外のフォルダが存在しないことから、現状としては「sarge/contrib」一択なのでしょう。
と言うことで、解説が長くなりましたが所定の定義を「/etc/apt/sources.list」に追記します。
リポジトリを追加してので「apt update」を実行してみます。
W: GPG error: https://download.webmin.com/download/repository sarge Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D97A3AE911F63C51
E: The repository 'https://download.webmin.com/download/repository sarge Release' is not signed.なんかエラーが出ました。パブリックキーが無効だ！とか言ってます。
実はパッケージのインストールに先行して上記パブリックキーをインストールしておく必要があるようです。
具体的な手順は以下の通り。
wget https://download.webmin.com/jcameron-key.asc
apt-key add jcameron-key.ascこれで「apt update」でエラーが出なくなります。
蛇足ながら、上記パブリックキーのことを「GPGキー」と書いている記事と、「PGPキー」と書いている記事を見かけます。どちらかが正解でどちらかはタイポだと思っていたのですが、実は両方正解で、それぞれ以下の意味らしいです。
GPG：GNU Privacy Guard
PGP：Pretty Good Privacy
GPGもPGPもそれ自体はソフトウェアの名称で、GPGはOpenPGPに完全準拠し、OpenPGPとはPGPのバージョン5.xを参考にして作られた規格と言うことです。何ともややこしい。
（閑話休題）
「apt update」が終わったら「apt -y install webmin」を実行してみます。
めでたくWebminのインストールができたかと思います。
では、ブラウザからWebminにアクセスしてみます。
https://192.168.33.12:10000CentOSではログインアカウントとしてrootを使用しました。通常はシステム関連の設定にはroot権限が必要なのでそのようにしていたのですが、UbuntuのWebminではrootでのログインができません。仕方がないのでユーザー「vagrant」でログインして操作してみましたが、特に支障はありませんでした。改めて、Webminのログインアカウントと権限の関係が謎になってきましたが…まぁ、結果オーライで今回は話を進めます。
例によって日本語化とタイムゾーンの変更を行います（この辺はCentOSと違いがないため、この記述を以て「できた」とします）。
各種パッケージに関しては先に「apt upgrade」を実行しているので既に最新化されており、コンパネからのアップデートは必要ありません。
上記でWebminのインストールおよび設定ができましたので、次にVirtualminのインストールを行います。
Virtualminのインストール方法自体はOSに依存しない印象のものなので、CentOSと同じ方法をそのまま試します。
Ubuntuのrootユーザーで「/tmp」に移動し、以下のコマンドを実行します。
curl -O http://software.virtualmin.com/gpl/scripts/install.sh
sh install.shすると以下のようなエラーが出ると思います。
[ERROR] Memory is below 1572 MB. A full installation may not be possible.仮想マシンに割り振ったメモリはデフォルト値の1024MBだったので確かに上記メッセージの通りですが、CentOSではこのサイズでインストールできたんですけどね。
仕方がないのでVagrantfileを以下のように書き換えてメモリを拡張し、再起動、再度Virtualminのインストールを試すことにします。
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu/focal64"
config.vm.network "private_network", ip: "192.168.33.12"
config.vm.provider "virtualbox" do |vb|
vb.name = "ubuntu_focal64"
vb.memory = "2048"
end
end今度はインストールできると思います。
ブラウザからVirtualminにアクセスしてみましょう。
CentOSの際にはこの段階で再度パスワードの入力を求められましたが、Ubuntuではそのまま操作が継続できます。これがOSの違いによるものか、アカウントがrootかvagrantかで異なることが影響しているのかは分かりませんが。
Virtualminの画面ではCentOSと同様に初期設定を求められますが、表記がしっかり日本語化されています（CentOSではこの辺は英語のままでした）。英語が不自由な人間にはありがたいです。まぁ、やる事は変わらず、MySQLを使えるようにしつつ、デフォルトの仮想サーバ「ubuntu-focal.com」を作っておきます。
Virtualminの設定が全て終了したら、生成した仮想サーバ「ubuntu-focal.com」にアクセスしてみます。
例によってそのままではアクセスできません。自動生成されたApacheの設定ファイルにおいて自マシンのIPが「10.0.2.15」になっているためです。よってこれを書き換えますが、Apacheの設定ファイルの配置やファイル名がCentOSとUbuntuでは異なります。Ubuntuでは「/etc/apache2/sites-available/ubuntu-focal.com.conf」に該当する設定が書かれていますので、同ファイル内の「10.0.2.15」を仮想マシンに割り振ったIP「192.168.33.12」に変更します。
設定変更後はApacheの再起動が必要ですが、ここもCentOSとUbuntuでは違っていて、Ubuntuでは以下のように実行します。
service apache2 restart上記実行後に以下のURLにアクセスしてみましょう。
https://192.168.33.12/「ubuntu-focal.com 工事中」と表記された画面が表示されればOKです。
phpMyAdminインストール
phpMyAdminのインストールに関してもaptコマンドで行います。
具体的には以下のように実行します。
apt install phpmyadmin php-mbstring php-zip php-gd php-json php-curl依存パッケージ含めてインストールする形です。
なお、インストールがある程度進んでいくと突然「Configuring phpmyadmin」なる画面が表示されて入力を求められます。CentOSにはなかった挙動です。
最初は「使用するWebサーバに合わせて設定を行うのでWebサーバを指定して」と言うものですが、いきなりこの画面が出てきてどのように操作をすれば良いか戸惑うかと思います。
正解は、矢印キーで選択肢移動、スペースで選択、TABでOKなどへの移動です。
「apache2」を選択してOKを実行します。
次に同様の画面で「dbconfig-commonを使用するか？」と聞かれますが、これはphpMyAdminで管理すべきDB本体の方の設定が未実施だった場合に「dbconfig-common」を使って設定ができると言うものらしく、英文を頑張って読めば「既にDBの設定が行われていれば必要ない」と書かれています。
本ケースではVirtualminによりMySQLに関する設定が済んでいますので、ここは「No」を選択します。
上記でインストールが終了します。
なお、上記操作を失敗して進めてしまった場合のやり直し方が良く分かりません。phpMyAdminパッケージを削除してインストールし直しただけでは同画面が表示されません（つまりapache2として必要な設定が行われません）。ネット情報によれば
dpkg-reconfigure phpmyadminと実行すれば再度前述の操作ができるようになるとのことですが、裏はとっていません。実際、初めてこの手順を試した際に前述の罠にハマったのですが、上記やり直しコマンド情報にたどり着くまでに試行錯誤で環境を汚してしまったので、結局最初（Virtualbox/Vagrant環境構築）からやり直しました。
と言うことで、上記操作の際にはお間違いないように。
上記で問題となったApache2に関する設定処理が正しく行われていれば、「/etc/apache2/conf-available/phpmyadmin.conf」と言うファイルが生成されていると思います。
この状態でphpMyAdminにアクセスしてみましょう。
なお、URL上でのスペルは「phpMyAdmin」ではなく「phpmyadmin」（全部小文字）になりますので注意してください。
https://192.168.33.12/phpmyadmin残念ながらphpMyAdminの画面ではなくPHPのソースがそのまま表示されると思います。
これはCentOSでも問題になった、phpMyAdminの設定「/etc/apache2/conf-available/phpmyadmin.conf」においてFastCGI PHPに関する設定がないことが影響しています。前述したようにわざわざApache2の設定に関して手を掛けさせておいてこの程度か！とも思いますが、仕方がないのでここも手作業で直しておきます。
<Directory /usr/share/phpmyadmin>
Options SymLinksIfOwnerMatch
DirectoryIndex index.php
Options +ExecCGI
AddHandler fcgid-script .php
FCGIWrapper /home/ubuntu-focal/fcgi-bin/php7.4.fcgi .php
# limit libapache2-mod-php to files and directories necessary by pma
<IfModule mod_php7.c>
（中略）
</IfModule>
</Directory>
上記ファイルにおける下記書式が追加した部分です。
Options +ExecCGI
AddHandler fcgid-script .php
FCGIWrapper /home/ubuntu-focal/fcgi-bin/php7.4.fcgi .phpFCGWrapperに関してはVirtualminでの設定内容に依存しますので「/etc/apache2/sites-available/ubuntu-focal.com.conf」内の設定を参考にしてください。
上記設定変更後にApache2を再起動するとphpMyAdminに正常にアクセスできるようになると思います。
composerインストール
CentOSではVirtualminインストール時に2つのバージョンのPHPがインストールされており、コマンド実行時のデフォルトが旧バージョン側になっていたので、まずはその点に対処する必要がありました。
Ubuntuではそのようなことはなく、7.4.3（2021年2月6日現在）がインストールされているのみです。よってCentOSのような煩わしさはありません。
と言うことで、普通にcomposerのインストールのみ行います。
cd /tmp
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
mv composer.phar /usr/local/bin/composerこれでcomposerが利用可能になったかと思います。
Laravelインストール
Laravelのインストールに関しては特にCentOSとの違いはありません。
Virtualboxで仮想サーバ「ubuntu-focal.com」を生成するように指定したことにより「ubuntu-focal」と言うユーザーが生成され、「/home/ubuntu-focal」がホームディレクトリに、「/home/ubuntu-focal/public_html」が仮想サーバ「ubuntu-focal.com」のドキュメントルートになっています。ホームディレクトリ配下に「laravel」と言うディレクトリを作成し、その配下に「ubuntutest」と言う名称でLaravel環境を構築してみます。
以下のコマンドをディレクトリ「/home/ubuntu-focal/laravel」で実行します。
composer create-project laravel/laravel --prefer-dist ubuntutest 6.*インストールが正常に終了したら「/home/ubuntu-focal/laravel/ubuntutest/public」がドキュメントルートになるように「/etc/apache2/sites-available/ubuntu-focal.com.conf」を変更します。同ファイル内の「public_html」の部分を上記環境に合うように書き換えてください。
先ほど「ubuntu-focal.com 工事中」が表示されていた同じURLで「Laravel」の画面が表示されればOKです。
自作ライブラリインストール
せっかくなので自作したライブラリも反映しておきます。
CentOSではここまでの操作を行っただけではgitはインストールされませんがUbuntuではインストール済みです。
まずは自己証明書を許容しておきます。
git config --global http.sslVerify falseリポジトリの設定を行います。
composer config repositories.mylib vcs https:/<git共用リポジトリ>/root/mylib_laravel.git当然ながら、リポジトリのURLに関しては読み込みたいライブラリに合わせて書き換えてください。
最後にライブラリのインストールを行います。
composer require wetch/mylibこの辺は特に問題ないですね。
Xdebugのインストール
テストの網羅度を確認できるようにXdebugもインストールしておきましょう。
以下のURLにアクセスし、画面上のテキストエリアにUbuntu上での「php -i」の出力結果をコピペします。
https://xdebug.org/wizardコピペ後に「Analyse my phpinfo() output」ボタンをクリックするとインストール手順が表示されますので、それに準じて作業を進めます。
なお、内容がUbuntuっぽくなっているのが分かるかと思います（apt-getの実行など）。便利ですね。
DB環境構築
せっかくテストに関する動作確認をするのであれば、DBも絡めておきましょう。
まずはphpMyAdminで対象DB（ubuntutestとしておきます）を構築します。collationはLaravelのデフォルト設定に合わせて「utf8mb4_unicode_ci」にします。
.envのDB設定も書き換えておきましょう。
以下のような感じでしょうか。
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=ubuntutest
DB_USERNAME=root
DB_PASSWORD=<パスワード>マイグレーションファイルを作成し、テーブルに関する定義を行います。
今回はあくまで動作検証用に軽く以下のような感じで。
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class CreateTUserTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('t_user', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('name')->comment('名前');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('t_user');
}
}マイグレーションを実行して、テーブルが生成されたことをphpMyAdminの画面から確認します。
問題なければphpMyAdmin画面からテーブル「t_user」にレコードを入れておきます（シーダを使っても良いですが面倒なので）。
上記テーブルに関するEloquent「app/Models/TUser.php」も作っておきます。
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class TUser extends Model
{
protected $table = 't_user';
protected $guarded = array('id');
protected $dates = ['created_at','updated_at'];
}上記モデルを使用して当該テーブルのレコードを表示するコントローラを作ってみます。
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Models\TUser;
class SampleController extends Controller
{
public function sample()
{
$TUserCollection = TUser::get();
return response()->json($TUserCollection->toArray());
}
}ルーティングも忘れずに（route/web.php）。
Route::get('/sample', 'SampleController@sample');以下のURLで上記コントローラの実行結果が確認できれば、ここまでの設定は完了です。
https://192.168.33.12/samplephpunit動作確認
前述のDB関連の振る舞い含めてphpunitで確認するためにはもう一仕事必要です。
まず、通常の動作確認時とphpunit実行時でDBを分けておきましょう。
phpMyAdminから「ubuntutest」とは別に「ubuntutest_test」を作成しておきます（なんか名称がややこしくなってしまった…）。
その上で、「config/database.php」に上記phpunit用の定義（mysql_test）を追加します。
既存の「mysql」の設定をコピーし、名称を「mysql_test」、「database」の名称設定部分で.envで定義した名称の後ろに「_test」を付加するように設定します。
結果は以下のようになります。
'mysql' => [
'driver' => 'mysql',
'url' => env('DATABASE_URL'),
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'prefix_indexes' => true,
'strict' => true,
'engine' => null,
'options' => extension_loaded('pdo_mysql') ? array_filter([
PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
]) : [],
],
'mysql_test' => [
'driver' => 'mysql',
'url' => env('DATABASE_URL'),
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'forge').'_test',
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'prefix_indexes' => true,
'strict' => true,
'engine' => null,
'options' => extension_loaded('pdo_mysql') ? array_filter([
PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
]) : [],
],ここまでできたら以下のコマンドを実行します。
php artisan migrate --database=mysql_testphpMyAdminで、追加した「ubuntutest_test」側に上記マイグレーション結果が反映されていることを確認できるかと思います。
こちらにも適当にレコードを足しておきます。なお、「ubuntutest」と「ubuntutest_test」のどちらにアクセスしているか分かるように登録するダミーデータの内容は違うものにしておくと良いです。
phpunit実行時に上記「ubuntutest_test」側にアクセスするよう「phpunit.xml」を変更します。
変更すべきはファイルの下の方にあるphp関連定義部分で、「DB_CONNECTION」に「mysql_test」を指定し、不要な「DB_DATABASE」の定義は削除しておきます。
<php>
<server name="APP_ENV" value="testing"/>
<server name="BCRYPT_ROUNDS" value="4"/>
<server name="CACHE_DRIVER" value="array"/>
<server name="DB_CONNECTION" value="mysql_test"/>
<server name="MAIL_DRIVER" value="array"/>
<server name="QUEUE_CONNECTION" value="sync"/>
<server name="SESSION_DRIVER" value="array"/>
</php>テストには手っ取り早く既存の「tests/Feature/ExampleTest.php」を使います。
内容は以下のような感じ。
<?php
namespace Tests\Feature;
use Illuminate\Foundation\Testing\DatabaseTransactions;
use Tests\TestCase;
class ExampleTest extends TestCase
{
/**
* A basic test example.
*
* @return void
*/
public function testBasicTest()
{
$response = $this->get('/sample');
$response->assertStatus(200);
$response->assertJson([['name' => '<ubuntutest_testに登録したダミーデータ内の名前>']]);
}
}ポイントはRefreshDatabaseではなくDatabaseTransactionsを使用するように書き換えている点でしょうか。ubuntutest_testに設定しておいたダミーデータをそのまま使えるようにしたいので。
上記を実行してエラーが出なければphpunitによるテスト実行自体はOKです。
さて、いよいよ大詰めですが、これでテストの網羅度が正しく記録されることが確認できれば今回のミッションは完了です。
網羅度を記録しながらphpunitを実行してみましょう。
vendor/bin/phpunit --coverage-html public/report tests/Feature/ExampleTest.php上記のように「–coverage-html public/report」と「–coverage-html」オプションでブラウザから参照可能なパス（ドキュメントルート直下のreportディレクトリ）を指定することで、そのパスに網羅度が記録され、以下のURLで結果が確認できるようになるはずです。
https://192.168.33.12/report/で、実際の結果ですが…参照できないはずです。この辺はCentOSも同様なのですが。
まず、環境変数の設定が必要です。
export XDEBUG_MODE=coverageログインするごとに設定するのは面倒なので、.bashrc辺りに登録しておくと良いでしょう。
これで記録は残されるようになりますが、肝心の「SampleController.php」内の網羅度に関しては記録結果が「SampleController.php.html」と言う名称で記録されるものの、これがPHPファイルだと解釈されるため、今までの設定のままでは正しく表示されません。
ここもCentOSと同じく、Apacheの設定ファイル「/etc/apache2/sites-available/ubuntu-focal.com.conf」の中の「AddHandler」を用いた設定を「SetHandler」を使用するように変更します。
具体的には
AddHandler fcgid-script .phpを
<FilesMatch \.php$>
SetHandler fcgid-script
</FilesMatch>に変更します。
これで「SampleController.php」の網羅度が確認できるようになったかと思います。
総括
今回はなかなかの長編でした…
ただ、今まで（CentOSに関して）は複数の記事に分散させていた内容を集約できたので、ある程度基本が分かっている状態であれば本記事を見るだけでUbuntuでLaravelをTDD的に開発する環境が構築できるかと思います。
CentOSとの違いとしては、やはりパッケージ管理（apt）関連とApacheの設定周りが上げられます。パッケージ管理はともかくApacheの設定ファイルの配置や名称がCentOSとUbuntuで異なっている点は今一つ謎です。と言っていても仕方がないので、この辺は覚えるしかないですね。
課題としてはメモリ要領の削減が上げられます。本記事での設定を全て行った上で同マシン再起動直後のメモリ使用状況をfreeコマンドで確認した結果が以下です。
total used free shared buff/cache available
Mem: 2035280 697264 646588 7392 691428 1165692
Swap: 0 0 0「available」が1G程度あるので使用中のメモリは1G弱程度ではありますが、それでもデフォルト設定「1024MB」では厳しそうです。先にも書いたようにCentOSでは（用途にもよりますが）デフォルト設定で問題なかったので、明らかにUbuntuの方がメモリを多く必要としている状況です。個人的には1台のMac上で仮想マシンを4〜5台動かしていることもままあるので、仮想マシン1台当たりのメモリ要領は1G程度に抑えておきたいところなのですが。
Ubuntuにはデスクトップ版とサーバ版があるはずで、Vagrant用Box取得時に特にその辺の指定がなかったことから、今回インストールしたものはデスクトップ版ではないかと推測します（Ubuntuは特にデスクトップLinuxとしてシェアを伸ばしてきたものと認識していますので）。デスクトップ版であれば、サーバとして不要なソフトが動いていて余計なメモリを喰っていると言う想像もできたりします。
だからと言ってサーバ版らしきBoxが発見できた訳でもないので現時点では役に立たない仮説なのですが、この辺を切り口にメモリ削減の施策を探って行きたいと思っています。
