Debain 11 と unattended-upgrades

Debian 11 が8月にリリースされました。

PHP 7.4 + PostgreSQL 13 になっています。WebClass の対応状況は検証中ですが、構成はあまり変わっておらず、PHPもPostgreSQLも下位互換性のない変更はあまり無さそうです。

Debian 10 からですが、Install CD からインストールすときにパッケージの自動更新を有効にするかどうか聞かれます。このプログラムは unattended-upgrades といい、セキュリティアップデートなどを定期的にチェックして更新を適用します。

https://wiki.debian.org/UnattendedUpgrades

デスクトップ用途では便利かもしれませんが、サーバ用途ではサービスの再起動などがかかると夜に仕込んでいたバッチ処理に影響が出るなどするので、OFF にしています。

Install CDからインストールするとき確認画面で No を選択しているとパッケージもインストールされませんが、AWS 上のイメージを使ったときには最初から有効になっていたケースがありました。以下のコマンドで設定状況を確認して、もしあれば purge しています。

systemctl status unattended-upgrades
systemctl stop unattended-upgrades
systemctl disable unattended-upgrades
apt purge -y unattended-upgrades

Debian のaptコマンドは、インストールするときはプロセスを自動的に立ち上げてくれますが、remove/purge するときはプロセスを殺してくれません。なので、予めサービスを止めてしまいます。

Chrome 93 以降は 4週ごとにアップデートリリースになります

こんにちは。福岡です

Chrome browser のリリースサイクルが早くなるようです。これまでは6週サイクルでしたが、今日にリリース予定の 93 がリリースされた後は4週サイクルに変わります。

https://developer.chrome.com/blog/faster-release-cycle/

Microsoft Edge もいまは chromium ベースで、リリースサイクルは Chrome に合わせています。そのため、Edge の 4週サイクルになるそうです。

https://docs.microsoft.com/en-us/deployedge/microsoft-edge-release-schedule

でたばかりの頃のChrome は結構攻めた変更を入れてきた印象ですが、今は流石にシェアもあってわきまえている印象ですので、それで普段使う操作があれこれ変わるということはないと思います。それよりもセキュリティ対応を素早く提供してもらえる恩恵があると思います。

Chrome は新しい機能の実装もどんどん進められています。新しい機能は開発者向けに Origin Trails という、有効化しないと動かない隔離された実装として提供されています。それでフィードバックを集めたりしてこなれたものが標準機能に降りてくるのだと思います。

https://developer.chrome.com/blog/origin-trials/

https://developer.chrome.com/origintrials/

Firefox 91

Firefox Desktop Browser 91 が8月5日にリリースされました。

Release notes

Firefox 91 release notes

Firefox 91 release notes for developers

Pickup for WebClass

webclass に影響のある変更はありませんでした。

今後の Firefox のリリースについて

次回のリリースは2021年9月7日に予定されています。

Firefox Release Calendar

その他ブラウザのリリースはこちらにまとめています。

docker コンテナを使ってPHP のバージョンへの対応チェック

こんにちは。福岡です

ご無沙汰になってしまいましたが、最近に調整していた開発環境の話を紹介します。いろんなPHPのバージョンで動くか検査する方法です。

PHPバージョンの対応状況

WebClass は Debian と RHEL をサポートしています。具体的には、両者について OS の側でサポートされている期間の間、WebClass も動くように維持するというポリシーです。したがって、サポートする PHP バージョンもこれらOSが現在サポートしている範囲になります。

正直なところ、特に RHEL はメジャーバージョン単位のサポート期間が長くてしんどいです。RHEL 6 の PHP 5.3 はようやく去年にサポート・メンテナンス2が終了しました( REF:Red Hat Enterprise Linux 6 (RHEL6) のサポート終了と移行について)。これで 5.3 が消えると思いきや、RHEL 7 は PHP 5.4 !! 。PHP 5.4 の最初のリリースは 2012年 3月でして、これももう10年になろうとしています(REF: Version 5.4 changelog)。なお、Debian 11 が先週にリリース(REF)されたため、これから PHP 7.4 の対応等を進めていくことになります。

どうやって PHP 5.3 - PHP 7.4 で動くように確認するのか? これが問題です。

昔は、それこそ Debian 8 と Debian 9 と CentOS6 と、という感じで複数のサーバを構築していました。ですが、機能も増えてきている今の WebClass を1つ1つ手でチェックしていくというのは無理です。ベテランプログラマーはバージョン依存が出にくい PHP のコーディングスタイルを身につけていますが、新しく加わった人がそれを身につけるものしんどいし、レビューでもチェックしきれません。実際のところ、バージョン依存の問題をポロポロと出してしまっています。

そこで、検査と開発者へのフィードバックの機械化を進めています。

PHP Unit による自動テスト

WebClass ではアジャイルな開発スタイルを採用しています。開発作業の流れとしては、社内の GitLab を使って Issue => Merge Request => Merge を繰り返しています。そして、このイテレーションでは GitLab の継続的インテグレーション機能を使って、テストとパッケージングを機械化し、素早く完全な変更を繰り返していくことを意識しています。自動テストの一部は PHP Unit を使っており、継続的インテグレーション機能(Pipelie)は次のような感じです。

GitLab のPipeline

PHP Unit の実行環境として、それこそ少し前までは Debian のサーバを構築していました。その後にテスト用のサーバの維持などの問題で CI での自動テストの運用が止まってしまいましたが、そうするとやっぱり開発者が自分でテストをするというのは、どうしてもおろそかになります。そこで、CI-Runner が使う Php Unit 実行用の docker イメージを作り、メンテナンスが後手に回ったテストを直し、今では Merge Request を発行するたびに自動的に Php Unit の結果がフィードバックされるようになっています。

GitLab の MergeRequest で Pipeline の結果部分

PHP のバージョンごとにコンテナイメージを追加することで、複数のPHPバージョンで並行して自動テストを行うことができます。今は PHP5.6 と PHP 7.3 の環境で自動テストが走っています。

一方、Php Unit さえあればいいかと言うとそうでもありません。自動テストが実装されていないところはテストされないのが何より問題です。WebClass は2000年から開発スタートして、今まで完全な作り直しはありません。ですので、フレームワークのない状態から今まで拡張の傍らで必死にリファクタリングを進めて構造化し、後から自動テストスイートを加えて、そこからテスト可能な実装にリファクタリングしてテスト実装して、と走ってきました。まだテスタブルでないコードも、自動テストが実装されていないコードも残っています。

CI に PHP Linter 追加

Php Unit は自動テストが実装されないとコードを検査できませんが、PHP のコードの文法レベルであればすぐにスキャンできます。文法レベルの問題としては、例えば以下があります。

// PHP 5.4 から使える。それ以前のバージョンでは文法エラー
$array = [ 1, 2, 3];
// この書き方はどのバージョンでも使える
$array = array( 1, 2, 3 );

この程度と思いきや、文法エラーは PHP をロードした時点でエラーになって落ちるので、初期の require() などで1つでも混入すると機能が全く動かなくなります。ですので、検査する価値はあります。

PhpLinter のライブラリもいくつか公開されていますが、中を除くと基本は PHP に実装されている Lint 機能を使っているようです。この機能はコマンドラインで php -l test.php と実行して検査できます。ということは、 PhpUnit を動かせるコンテナであれば、composer とか phing を使うまでもなく以下のコマンドでチェックできます。

find $SRCDIR  \( -type f -name "*.php" -o  -name "*.inc" \)  -exec php -l {} \; | grep -v 'No syntax errors detected' 

ということで、準備しました!

PHP 7.4 で早速 PhpUnit が落ちています。また、UnitTest のJob に 7.0 などがいないのは、まだ調整中のためテストJob を入れたり外したりしているからです。

自動テストに失敗していれば、Merge Request 画面でもその結果が表示されて、マージできなくなります。

PhpUnit 失敗

テストターゲットのチューニング

Lint を実行するコマンドは、実は PHP のバージョンごとに用意してあります。

これは、大学に提供しているカスタム機能などがその大学での実行環境に依存していることが有るためです。このように、もともと特定の環境で動くことを想定しているコードがどうしてもあるのと、新しいバージョンに対応させていく優先順位はありますので、全てを一気にとは行きません。このタイムラグを解決するための苦肉の策です。

composer の overtrue/phplint などのツールもあり、phplint ツールのコンフィグファイルを書き分けるても有るのですが、それはやめました。理由は2つ。1つは、PHP バージョンごとに実行環境を分けているので、PHP バージョンが古いと composer の使いたいライブラリやバージョンを使えなかったりして返ってややこしい。1つは、php -l は Deprecated などの情報もバリバリ書き出してくれるので、将来のバージョン対応を見据えて Error ではない情報もチェックするときに便利なため。こういうときには良くも悪くも Bash は単純で、除外リストなど開発者がそのまま読んだり調整しやすいと思ったからです。

まとめと今後

PHP のバージョンごとのテスト用 Docker がひとまず揃いました。CI でも動かしますが、Docker なので開発者の手元でもすぐに動かせます。まずはこれで PHP の文法レベルの問題は未然に防げるようになると期待できます。

さらにテストの内容を充実させるために PHPUnit のテストはどんどん書き足していきます。そのため、Merge Request のレビューではテスト可能な設計になっているか、テストの内容は十分か、なども引き続き突っ込んでいきます。

また、レビューにおける脆弱性の検査もなかなか難しいため、GitLab の SAST 機能あたりに興味を持っています。よく見ると PHPについては PHP-CS の拡張パターンのようですが。

https://git.lan.datapacific.co.jp/help/user/application_security/sast/index

小さなチームでレガシーコードも抱えていますが、うまくやりくりして良くしていきます。

いろんなサービスの稼働状況・障害状況

こんにちは。福岡です

今日ではいろんなクラウドサービスが利用されており、いつも当たり前のように使っているところで突然サービスが止まってしまったりすると、仕事が進められなくて困ったりします。もしくは、動きが変わってしまうこともあります。

WebClass を利用いただいている学校では WebClass もそうですが、実際にはブラウザのアップデートやインターネット回線、遠隔会議システムなど組み合わさって利用されていると思います。

ブラウザのリリース情報とWebClassの対応については こちら で案内しています。

ここでは、他にいくつか、組み合わせて使っていらっしゃると考えられるクラウドサービスの稼働状況を確認できるサイトを列挙しました。

Zoom

Cisco Webex

Microsoft Office 365

Google

こうしたサービス稼働状況はずっと見ていられるわけではないですし、リリースノートも毎回細かく見ていくのはかなり大変です。ですが「あれ?」と思ったときに、こちらのサービス状況を見ると問題切り分けの助けになることもあると思います。