PDFの証明書生成

先週に ディジタルバッジの規格や今のサービスを調べた記事 を書きました。

ディジタルバッジではなくとも、一定の条件を満たした人にその証明を発行する機会はあると思います。ここでは、PDFの証明書を生成する WebClass の機能を紹介します。

使い方

WebClass では一部の学校で、施設利用の研修を終えたときの修了証のような修了証発行する機能を使っていただいています。修了証は PDF ファイルで出力します。次の画像のように、フォーマットが決まっていて、日付や終了した人の名前などが埋め込まれます。ネットワークを使うためのセキュリティ講習など、主に事務的な用途で使っていただいています。

この証明書は、PDF出力設定をした資料教材を開いたときに生成されるようになっています。

証明書のデザインは以下のようにHTMLで記述し、置き換える文字のところにマークを仕込んでいます。ですので、HTML+CSS でやりくりできる範囲でデザインやタイトル文字などは自由に変えることができます。画像も使えます。

  <div class="cert_title">{CERT_TITLE}</div>

  <div class="given_to">
    <div class="given_to_layout">
      <div class="given_to_title">
        <div class="name">{USER_NAME}</div>
        <div class="userid">{USER_ID_LABEL}:{USER_ID}</div>
      </div>
      <div class="honor_title">{HONORIFIC_TITLE}</div>
    </div>
  </div>

  <div class="subject">
    <div class="text">{SUBJECT}</div>
        <table class="detail">
          <tr>
            <td>コース名</td>
            <td>{COURSE_NAME}</td>
          </tr>
          <tr>
            <td>教材名</td>
            <td>{CONTENTS_NAME}</td>
          </tr>
        </table>
  </div>

  <div class="signature">
    <div class="date">{FIRST_EXEC_DATE.JPYMD}</div>
    <div class="given_by">{GIVEN_BY}</div>
  </div>

この証明書の発行条件は、ユニット教材の「順番に進める」設定と、テスト教材の合格点設定を組み合わせています。このユニット教材に合格点設定付きのテストの後で証明書発行の資料教材を並べると、テストに合格したときに証明書発行の資料にたどり着けるというものです。

PDFの生成

内部では、HTML+CSS のWebページソースを生成して、ヘッドレスブラウザに読み込ませてPDFに変換させています。

ヘッドレスブラウザとは、画面表示なしで動くブラウザです。コマンドラインツールから操作でき、その最中にはブラウザがどんな表示をしようとしているか表示することはできませんが、あたかも普通のブラウザで操作したかのように振る舞ってくれます。JS の処理なども対応しており、そうして表示シミュレーションした結果をスクリーンショットして保存したり、PDF に印刷させたりできます。

以前は wkhtmltopdf, PhantomJS などの専用ヘッドレスブラウザを使うことも多かったですが、いまでは Firefox も Chrome もヘッドレスモードをサポートしています。Chrome などをヘッドレスモードで使うことが増えており、wkhtmltopdf などは開発が下火になっているようです。wkhtmltopdf の歴史と現在の状況

Chrome のヘッドレスモードでの使い方はこちらに解説があります。

Linux サーバ上でヘッドレスブラウザを使ってPDFをレンダリングするため、フォントについてはサーバ上にインストールされているフォントに成約されます。

PDF 以外の証明書、認定の仕方

WebClass のユニットとテストの合格点の機能を使って、テストをPassしたら何か証明書を作るという処理を実現しています。その仕組はそのまま使って、証明書のデザインを調整できるようにしているのが PDF 証明書の発行機能です。

PDF ではなく、ディジタルバッジを発行する処理に置き換えることもできます。ですがディジタルバッジでは以下の課題があります。

  • 今実現していた実装は、OpenBadge のバージョンが古い
  • コース内で柔軟にバッジ発行するには、条件の設定の仕方が限られる

WebClass はできる限りテストの結果や掲示板の書き込みなども CSV でダウンロードして、先生が手元で自由に処理できるようにしています。そうして授業の内容や目的に応じて学生の活動をできる限り多角的に評価できるようにと考えていますが、集計も、結果を学生にどうフィードバックするか手作業になります。

このあたりをうまく仕組み化できたら面白いかもしれないと考えています。

デジタルバッジのサービスの様子

Open Badges の今の様子の調査まとめになります。

Open Badges については WikiPedia にページがありますが、英語/日本語でほぼ同じようです。翻訳になっている感じでしょうか。

規格について

本家はこちらです

Open Badges に関して IMS での動きや仕様書はこちらにまとまっています。

Open Badges の規格は 2.0 までリリースされており、2.1 が Candidate Final のステータスで評価検証されているようです。OpenBadge v2.1 ではOAuth について記載があり、やり取りのセキュリティについても整備されていくのだと思います。

Open Badges に対応している製品は以下で検索できます。

https://site.imsglobal.org/certifications?refinementList%5Bstandards_lvlx%5D%5B0%5D=Open%20Badges

サービス:Badgr

もともと Mozilla が Backupack でデジタルバッジ管理サービスを運営していました。これが本家だったのですが、Mozilla は辞めてしまい、Badgr が引き継いでいます。と言っても、アカウント情報などが引き継がれたわけではなく、新しいサービスとして稼働しています。

4つのリージョンでサーバが異なっています。どこか選んでアカウントを作る、もしくはそれぞれにアカウントを作ることができます。

ログインすると、ここで自分の獲得したバッジを集めて管理することができます。なお、アカウントのメニューには言語の切り替えがなかったので、英語だけかもしれません。

アカウントは無料で登録できますが、Badgr をホストする方法も紹介されています。サーバのプログラムが GitHub で公開されているようです。

Blockcerts (ブロックチェーン証明書) を使ったサービス

もともとの Open Badges は、基本的なバッジのデータ構造と受け渡しのプロトコルが主です。発行元(Issuer)から比較的気軽に発行ができます。バッジを集めるホストでは、Issuer の確認などをしますが、仕組みとしてそこまでかっちりと改ざんチェックをするものではありません。なので、学習のなかの細かな達成事項をどんどんバッジにしてあげて、学習が進んでいく感じを学習者に感じてもらうのには良いのですが、例えば大学や国家資格の修了証書には心もとないです。

改ざんが難しく信頼性の高い証明に使う技術として Blockchain が注目されており、それを使った証明書の技術が Blockcerts です。

日本の企業で NetLearning 社もブロックチェーン型オープンバッジの仕組みを実現しているようです。「オープンバッジとは」のセクションの *2 に Blockcerts を利用していると書かれています。

https://www.netlearning.co.jp/openbadge/index.html

デジタル・ナレッジ社でも、オープンバッジのソリューションとして OpenBadgeとBlockcerts が用意されているようです。

Open Badge 準拠なわけではないかもしれませんが、同じく Blockcerts を使ったブロックチェーン証明書発行システムのサービスが日本にもあるようで、それを運営している会社のブログ記事に解説がありました。

日本語の Wikipedia ページにもリンクがあった一般財団法人 オープンバッジ・ネットワークでも、「オープンバッジとは」のところを見るとブロックチェーン技術を取り入れているとあり、Blockcertsとは書いていませんがおそらく同様のことをしているのではないかと思います。

日本の大学でのオープンバッジ利用

中央大学でオープンバッジの実装実験を行っているそうです。

https://www.chuo-u.ac.jp/aboutus/communication/press/2021/08/55724/

具体的なことはわからないのですが、特定の科目で修了証を発行するそうです。

WebClass での状況

OpenBadge v2.1 は Final Candidate の段階ですが、OAuth について記載がありました。やり取りのセキュリティについても整備されていくのだと思います。それはそれとして、証明書自体が本当に信頼できるものかどうかより確かにするための Blockcerts もあることが分かりました。

WebClass ではこれまでに OpenBadge の初期のAPIを使ってコースや教材のバッジ発行を試していました。コースの中で達成したことを、先生が用意する教材に応じてバッジが発行できるのも面白そうです。

Apache mpm_prefork と PHP-FPM の効率の違い

こんにちは。福岡です。

Apache mpm_prefork + mod_php と mpm_event + PHP-FPM を使ったときの、同時アクセス数が増えたときの効率を調査しましたので紹介します。

WebClass はWebサーバにApacheと、スクリプトに PHP を用いています。同時多数のアクセスを扱うためのチューニングは常に問題です。同時多数のアクセスに立ち向かうため、Apache は今では mpm_event をデフォルトとしていますし、PHP も PHP-FPM を使うことで mpm_event と組み合わせることができます。PHP-FPM も正式機能になって10年経つので、すでに利用されている環境もかなりあると思います。

ネットの記事などを読んで MPM_EventとPHP-FPM が仕組みとして mpm_prefork より効率が良さそうだというのはわかっていたのですが、定量的にどこがどれくらい良いのか、いまいちしっくりくる説明を見たことがありませんでした。なので、今更かもしれませんが、測ってみました。

ここでは具体的に、以下について調査しました。

  • 同じ同時アクセスを受けた時、mpm_prefork とくらべて、PHP-FPM はどれくらい効率的に、もしくは安定してリクエストを処理できるか
  • プロセスの立ち上げ速度に差はあるか

結果は以下でした。

  • 用意したPHPのプロセス数よりも多くの同時アクセスを受けている時には PHP-FPM のほうがレスポンスタイムを1/2倍にするくらい効率が良いことが分かりました。
  • プロセスを立ち上げる速度は Kernel や CPU 等の影響が大きく差がありませんでしたが、一気に同時アクセスを受けてからプロセスを立ち上げ始める初動では PHP-FPM のほうが良い動きでした。

ベンチマークに使う PHP プログラム

ベンチマークコマンドは以下のようにして単一URLに ab コマンドで同時アクセスをかけ、レスポンス時間を確認しました。

ab -c 300 -n 1000 http://10.0.0.104/webclass/wait1.php

アクセス先PHPプログラム wait1.php は、1±0.25 [s] だけ待って 'OK' の文字を返します。想定として、プログラムファイルはキャッシュメモリ上に乗っていてIO負荷が殆どかからない、PHPのスクリプトとしても処理はDBサーバからの結果を待つだけでほとんどやることがない状況を想定しています。

<?php
function msleep($milliseconds) {
    return usleep($milliseconds * 1000); 
}
$interval = 1000;
$var = 500; 
msleep(1000 + (rand(0, $var)-$var/2));

echo 'OK';

したがって、スクリプトの処理時間はCPUの負荷状況に影響を受けにくく、CPUが空いていても1秒より早く応答は返さないし、CPUに多少負荷がかかっていてもスクリプトの処理自体はあまり時間が延びません。

このプログラムに対するアクセスのレスポンス時間を計測し、どれだけ1sから離れるかを比較することで、Apache と PHP-FPM の効率だけを比較・評価できると考えました。

計測環境

AWS EC2 インスタンス(m4.large) でDebian 10 + WebClass 11.11.3 を構築しました。

  • CPU Intel® Xeon CPU E5-2686 v4 @ 2.30GHz x2
  • Mem 8G + Swap File 3G
  • Debian 10.9
    • Apache 2.4.38 (Debian)
    • PHP 7.3.29-1~deb10u1

同一VPC内に m4.large のDebian10インスタンスを構築し、http プロトコルで ab コマンドによるベンチマークを計測しました。

  • CPU Intel® Xeon CPU E5-2686 v4 @ 2.30GHz x2
  • Mem 8G
  • Debian 10.9
  • Ab 2.3 Rev.1843412

計測中にはどちらのサーバでも Swap と Hardware Interrupt(Steal)が発生しないのを確認してあります。

計測環境チェック

wait1.php はほぼ待つだけなので、同時アクセスが多数発生してもCPUはあまり消費せず、ApacheとPHPの同時アクセス・複数プロセスのマネジメントの効率が良いほど応答時間は1sに近づくはず、という前提を確認します。

この前提条件の確認のため、mpm_prefork とphp7.3-fpm のそれぞれについて、300 プロセス用意した状態で100同時アクセスをかけて応答時間が1s程度になることをチェックしておきました。

ab -c 100 -n  10000 http://10.0.0.104/webclass/wait1.php

MPM_Prefork + Mod_php 7.3 (MaxRequestWorkers=300 ) の結果

Mpm_prefork のケースでは、Apache のMPM設定は以下のようにしました。

StartServers   300
MinSpareServers 300
MaxSpareServers 300
MaxRequestWorkers 300
ServerLimit    300

abコマンドの結果は以下です。

Concurrency Level:      100
Time taken for tests:   101.782 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      2260000 bytes
HTML transferred:       20000 bytes
Requests per second:    98.25 [#/sec] (mean)
Time per request:       1017.816 [ms] (mean)
Time per request:       10.178 [ms] (mean, across all concurrent requests)
Transfer rate:          21.68 [Kbytes/sec] received

応答時間が1sで、CPU負荷もほとんどかからなかったため、問題なさそうです。

MPM_event + php7.3-fpm (max_children=300 ) の結果

Mpm_event のケースでは、Apache のMPM設定は以下のようにしました。スレッドを100ずつ増やしていき、上限も2000にしてあるので、プロセスの起動とスレッド上限があまり影響しないようにしています。

StartServers      2
MinSpareServers 100
MaxSpareServers 100
ThreadLimit        300
ThreadsPerChild  100
MaxRequestWorkers 2000

PHP-FPM のプロセスモードは以下の設定です。

pm = dynamic
pm.max_children = 300
pm.start_servers = 50
pm.min_spare_servers = 20
pm.max_spare_serves = 50

なお、この設定は Prefork に揃えるには static にすればよかったと後で気づきました。

abコマンドの結果は以下です。

Concurrency Level:      100
Time taken for tests:   103.935 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      2300000 bytes
HTML transferred:       20000 bytes
Requests per second:    96.21 [#/sec] (mean)
Time per request:       1039.351 [ms] (mean)
Time per request:       10.394 [ms] (mean, across all concurrent requests)
Transfer rate:          21.61 [Kbytes/sec] received

dynamic/static の点は気になりますが、一応は応答時間が1sで、CPU負荷もほとんどかからなかったため、問題なさそうです。

レスポンス時間の計測結果

Prefork と PHP-FPM のワーカ数上限と、同時アクセス数を変えながら ab コマンドでレスポンス時間をプロットしたのが以下です。

グラフの凡例の名前「Prefork」もしくは「PHP-FPM」の横に書いた数字が、それぞれに設定したワーカーの上限です。

wait1.php は1±0.25s 待つだけなので、同時アクセスが多数発生しても CPU に掛かる負荷はわずかでした。ですので、MPM と PHP-FPM の効率がレスポンスタイム1sよりどれくらい上に離れてくか、に反映されると考えられます。1sでフラットなグラフになるほど、同時アクセスが増えても効率が落ちないことを意味します。

MPM_Prefork は、用意したプロセス未満の同時アクセスに対しては非常に効率が良いです。しかし、プロセス数を超える同時アクセスに対しては、著しく効率が悪化し、ab はエラーを計上することもありました。MaxRequestWorkers 900 で同時アクセス1500のケースでもCPUの利用時間は大して増えませんが、Load Average は 9.3 ほどになりました。エラーを計上したところより上の同時アクセス数はデータを取っていません。

PHP-FPM はプロセス数未満の同時アクセスに対して効率が良いのはMPM_Preforkと変わりません。一方、同時アクセス数がプロセス数よりも増えた時は、MPM_Prefork よりもレスポンス時間を1/2 程度に保てました。Load Averageは1いくか行かないか程度で、CPU使用率は低いままです。

プロセス数が足りない方に寄った計測をしているため、どちらの方式でもプロセス数を増やすことによる効率の悪化の様子は観察できませんでした。ただし、実際の運用ではプロセス数が増えるとスクリプトによるCPU利用量も増えるため、プロセス管理の効率の問題以前にCPUがボトルネックになることも考えられます。

プロセスの立ち上がり速度の計測

MPM_Prefork も PHP-FPM もワーカとしてプロセスを立ち上げます。一般にプロセスのフォークは重い処理になります。また、待機しているワーカ数よりも多くの同時アクセスがワッと来た時の反応にも影響します。WebClassですと、10時半から2限では試験をします!というとき、授業の開始時刻で一斉に学生が操作し始めるので侮れないパラメータになります。

2つの環境のそれぞれに、ワーカの最大値を500に、初期待機ワーカ数を50にした状態で待機させ、ab コマンドで同時500アクセスをかけました。そこからプロセス数を1秒単位で数えていって、500に達したところまでをグラフにしています。

グラフの凡例の名前「PHP-FPM」の横に書いた数字は min_spaire_servers の値です。最初は10にして計測したところ著しくプロセス起動が遅かったので、50の結果を加えてPreforkと比べられるようにしています。なお、これ以上値を増やしても、もしくは同時アクセス数を増やしても、速度は変わりませんでした。

プロセスの立ち上げ速度(グラフの傾き)は MPM_PreforkとPHP-FPM50で差がありません。これは Kernel や CPU などのもっと下のレイヤーの性能によるものと思います。ですが、同時アクセスが急にきてからプロセスを増やし始める反応はPHP−FPMのほうが良く、500プロセス揃うまでの時間に3sの差が出ました。その結果、平均応答時間は初動の速いPHP-FPM のほうが短くなりました。

CPUへの負荷を見ると、MPM_Prefork はプロセス上限に至るまでは CPU も Load Averageも低いままですが、PHP-FPM のほうはCPU使用率と Load Average が Prefork よりも高くなりました。もしPHPにそれなりの処理が有る時、PHP-FPMのプロセスの立ち上げにどれくらい影響するかちょっと気になります。

まとめ

まずは基本的なところの違いを知りたいと思って、できるだけプロセス管理効率に的を絞った計測をしてみました。

MPM_Event については、PHP-FPMの計測でほぼ無視できるほどサクサクと1500同時リクエストなどを抱えてくれていて、数字では示せませんでしたが流石だなと思いました。そのおかげで、PHP-FPM はワーカ数を絞っていても効率的に処理できるようになっていると思います。PHPのプロセス数を絞ることができれば、接続先のDBのワーカ数も減らすことができます。コア数とメモリが限られる環境での安定性に繋がります。また、この安定性を保ったまま、CPU とメモリを増やした分だけワーカ数を増やしていければ、1台のプロセッサでカバーできる同時アクセス数も増やしやすいかもしれません。このあたり、今後詰めていきたいところです。

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

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

Dockerコンテナ内で make: /bin/sh: Operation not permitted

GitLab CI のジョブ実行環境として Docker イメージ composer:2 を使っていたのですが、 make: /bin/sh: Operation not permitted というエラーによりジョブの途中で停止していました。単純な make コマンドが実行できないようです。

この問題に関係するのは以下のようでした。

https://github.com/alpinelinux/docker-alpine/issues/146
https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2

まとめると以下の状況です。

  • Alpine 3.14.0 からシステムコール faccessat2 を使うようになったため、ホストOSで以下を必要とするようになった
    • runc v1.0.0-rc93
      • containerd.io 1.4.3-2 (DebianリポジトリのDockerの場合)か、Docker Desktop 3.3.0 (WindowsかMacのDockerの場合)に含まれる
    • Docker 20.10.0 以上
    • libseccomp 2.4.4 以上

弊社では、GitLab runner が動作しているサーバーの Docker バージョンを最新にしたらエラーが起きなくなりました。