ANNAIマガジン
この記事の目次

ANNAIの青山です。

最近は日本でも少しずつDrupal 8の採用事例が増えてきたように思います。

弊社ではDrupal 8を8.0の段階から商用システム開発のために採用しており、先日リリースされた8.4へのアップデートを含めると計4回のマイナーアップデートを経験してきました。

Drupal 8は非常に生産性の高いCMS・フレームワークです。しかし、コアのセキュリティ更新、コントリビュートモジュールの完成度や互換性、各種ライブラリのアップデートなど、気をつけなければならないポイントがいくつかあります。

弊社がここ2年ほどDrupal 8で開発してきた中で、主に保守(メンテナンス)の観点から重要なポイントを紹介したいと思います。

セキュリティ更新を受けるためには定期的にコアのマイナーアップデートが必要

Drupal 8.xではセマンティックバージョニングが採用されており、マイナーアップデート(0.1単位のアップデート)が約半年に一回行われます。また、かなり重大な問題でない限り、最新のマイナーバージョンにのみセキュリティ更新が行われます。

言い換えると、セキュリティを担保するためには定期的にマイナーアップデートを必ずしなければならない、という事です。

8.0.0〜8.4.0の間にリリースされたマイナーアップデートとセキュリティー更新は以下になります。

バージョン リリース日 リリース種別 前回のセキュリティ更新からの日数
8.0.0 2015年11月19日    
8.0.4 2016年2月24日 セキュリティ更新  97日
8.1.0 2016年4月20日    
8.1.3 2016年6月15日 セキュリティ更新 112日
8.1.7 2016年7月18日 セキュリティ更新 33日
8.1.10 2016年9月21日 セキュリティ更新 65日
8.2.0 2016年10月5日    
8.2.3 2016年11月23日 セキュリティ更新 63日
8.2.7 2017年3月15日 セキュリティ更新 112日
8.2.8 2017年4月19日 セキュリティ更新 35日
8.3.0 2017年4月6日    
8.3.1 2017年4月19日 セキュリティ更新 35日
8.3.7 2017年8月16日 セキュリティ更新 119日
8.4.0 2017年10月4日    

ざっくりですが、100〜150日に1度はセキュリティ更新を受けるためにコアのマイナーアップデートが必要になっています。コアのアップデート自体は0.1単位でも0.0.1単位でもそれほど難しくありません。しかし、モジュールやカスタムコードの追従に関しては、後述するようにいくつか注意するポイントがあります。

「Drupal 8対応モジュール」は全てのDrupal 8のバージョンに対応しているわけではない

繰り返しになりますが、Drupal 8.xではセマンティックバージョニングが採用されており、マイナーアップデート(0.1単位のアップデート)で新しい機能が追加されたり、既存の機能が非推奨の扱いになることがあります。特に新しい機能については、コアの内部設計の見直しによりコードの後方互換性がなくなるケースもあります。

モジュールが依存しているコアの機能でこのような後方互換性がない変更があった場合、当然ですがモジュールが修正されなければ、新しいコアではそのモジュールは動作しないことになります。

「実際どういう時に困るの?」というのがちょっとわかりにくいと思いますので、実際に発生するケースをご紹介します。

RestUIモジュールの例

RestUIはRest APIのエンドポイントをGUIから管理する機能を提供するモジュールです。このモジュールはDrupal 8.0.xの時には全てに存在していたため、使った事のある方もいらっしゃるかもしれません。

Rest UI Module

例えば、Drupa 8.1.10 (2016年9月21にリリースされた8.1.xの最終バージョン)とRestUI 8.x-1.11 (Drupal 8.1.10がリリースされた時点の最新バージョン)を使ったサイトを作ったと仮定しましょう。

前述したとおり、8.2.xの最初のセキュリティー更新であるDrupal 8.2.3が2016年11月16日にリリースされました。この時、私たちはなるべく早急にDrupal 8.2.3までアップデートする必要があります。

この条件下でコアをアップデートするとどうなるでしょうか?実はRestUIモジュールは正しく動作しなくなります。Drupal 8.1.xではREST APIの設定はymlファイルで管理されていましたが、Drupal 8.2.0からはConfiguration Entityとして管理されるようにコアの仕様が変更されています。そして RestUI 8.x-1.11 はこの新しい仕様には対応していないからです。

新しいコアの仕様に対応したRestUI 8.x-1.13 がコアのセキュリティ更新の数日前、2016年11月10日にリリースされています。そのため、このケースであればコアと同時にRestUIモジュールをアップデートすればサイトは正常に動作します。しかし、本来の目的であるコアのセキュリティ更新以外にも、予期していなかった作業が発生することになります。また、エンジニアのスキルによってはこの解決方法に辿り着けないかもしれません。

もし、コアのセキュリティー更新が出た時に、対応するモジュールがリリースされていなかったらどうすればいいでしょうか?選択肢としては以下の4つが考えられます。

  1. セキュリティを優先してRestUIモジュールを無効化してコアをアップデートする
  2. 機能を満たすことを優先して、セキュリティアップデートを適用しない
  3. 正式にリリース前のRestUIモジュールのパッチを適用し、コアもアップデートすることでセキュリティ要件も機能要件も満たす
  4. RestUIモジュールのパッチを自分で作成して、コアもアップデートすることでセキュリティ要件も機能要件も満たす

1. で回避できれば良いですが、モジュールの機能によってはそもそもサイト自体が成り立たなくなるケースもありますし、影響が少なかったとしてもユーザーからOKが出ない可能性もあります。そのため、この解決方法を当てにするのは非常にリスクが高いでしょう。

2. も対応としては非常にリスクがあります。サイトの仕様と脆弱性の内容によっては、「早急にパッチを当てなくても問題ない」という判断ができるかもしれませんが、その判断を下すためにも高い技術力とコストが必要になります。また、今年何かと話題になったStruts2のように、「影響範囲が非常に大きく、すぐにパッチを適用せざるを得ない」、というような場合も考えられます。

もしパッチが存在すれば3.は良い選択肢です。Drupal.orgのissueをチェックして、パッチがあるか、他のユーザーによってすでテストされているかを確認すると良いでしょう。正常に動いた場合、結果をissueにコメントすればメンテナーや他のユーザーにとってとても有益な情報になります。

Drupalをしっかりと理解しているエンジニアがいれば4.を選択できるかもしれませんが、小さなモジュールはなんとかなっても、大規模なモジュールのパッチは作ること自体ができないかもしれません。ちなみに、大規模なモジュールのコード量は1万行を軽く超えます。

このようなリスクをなるべく避けるためには、

  • 不用意にモジュールを導入しない
  • アップデートにしっかりと対応できる体制(というか人)を作る
  • 仕様に変更がありそうなコアの機能を利用しているモジュールの導入は、仕様が固まるまで避ける
  • 導入するのであれば、開発が活発かどうか、過去のコアのマイナーアップデートに対する追従は早かったかなどを事前にしっかりと調査する
    • ダウンロード数や利用数が少ない、または最近リリースがないモジュールなどは特に注意
    • Display Suiteのように、新しいコアへの対応バージョンをかなり前からalphaやbetaとしてリリースしたり、一定期間は古いバージョンもセキュリティ更新をしてくれるモジュールは安心です。

などの対策が必要になります。

Drupal 7ではコアの機能は基本的に変わらなかったため、コアがアップデートされたことによりモジュールが動作しなくなるということは、基本的にはありませんでした(モジュール間の依存で似たような問題が発生することはありました)。Drupal 8ではコアとモジュールの依存でこのような事態が発生する可能性があるということを覚えておきましょう。コア自体の機能がかなり多くなっていますので、コアでできることはなるべくコアのみで実現するのが良いと思います。

同じDrupal 8世代でもライブラリのバージョンは変化する

先日リリースされたDrupal 8.4.0 では、Symfonyのバージョンが2.8から3.2に変わり、jQueryのバージョンも2.2.4から3.2.1に更新されました。実際はその他にもたくさん更新されていますが、ここでは省略します。興味がある方は下のリンクからcomposer.lockの差分をチェックしてみてください。

https://github.com/drupal/drupal/compare/8.3.7...8.4.0

実際にDrupalのファウンダーであるDries Buytaert‏が dri.es をDrupal 8.3から8.4にアップデートした時、jQuery3への対応のためにカスタムコードを少し治す必要があったとツイートしています。

https://twitter.com/Dries/status/919258449783017474

先日のBadcamp 2017のセッションでも出てきましたが、Drupal 8.xの最後のバージョンから9.0へのアップデートの際は、機能追加は行われず非推奨の機能の削除のみが実施される予定です。言い換えると、Drupal 8.xのうちは継続的に機能追加が行われる、ということになります。

それに伴い、このようなライブラリのバージョンアップも、少なくともDrupal 8.xのリリースサイクルの間は発生することが予想されます。

もちろん、このようなバージョンアップはリリース時に突然発表されるわけではなく、その前のディスカッションやalphaリリースの時点で情報が公開されています。そのため、開発者は次のマイナーバージョンが正式にリリースされるよりかなり前から、自身のサイトがバージョンアップに伴う影響を受けるかどうか確認する事ができます。

このようなリリースサイクルやライブラリのバージョンアップはWebアプリケーションフレームワークとしてはごく一般的ですが、CMSとしては珍しいかもしれません。

「保守が大変なんじゃないか?」と思われるかもしれませんが、ソフトウェアの保守としてはいたって普通のことを普通にこなすだけです。

alpha、betaは文字通り不完全な機能しか提供されないケースが増えた

これは統計データがあるわけではないので私の主観ですが、本来の概念通り、機能的にはまだ不完全な状態でalpha、betaリリースがされるようになったと感じます。セマンティックバージョニングが採用され、一部のモジュールはcomposer.jsonでメタデータを管理するようになったので、その辺りの影響も大きいのかと予想しています。

これはバージョニングの観点からはむしろ歓迎すべき変化ですが、モジュールを利用する際は気をつけたほうが良いでしょう(ちなみに、Drupal 7でもバージョンニングの規定はちゃんとあります)。

名前が同じモジュールでもDrupal 7と同じ機能が全て提供されるわけではない

フレームワーク自体のコードがほとんど書き直されていたり、多くのモジュールがCoreに取り込まれているので当然と言えば当然なのですが、Drupal 7の時からあるモジュールのDrupal 8版が、Drupal 7版と全く同じ機能を持っていない場合もあります。

例えば webform はDrupal 7, Drupal 8版の両方でモジュールがリリースされていますが、Drupal 8版は元は YAML Form という別のモジュールであり、名称が変更され現在webformになっています。

(ちなみに、この時 webform 8.xのコードは全て削除されています)

Drop webform 8.x

これは極端な例ですが、このような変化もあるということを頭に入れておく必要があります。YAML Formをベースとした現在の Webform 8.xは、従来のWebformの機能の多くをサポートしています(むしろ、だいぶ高機能になっています)が、必ずしもDrupal 7にあった従来の機能やUIがサポートし続けられる保証はありません。

また、前述したようにbetaくらいの段階では、まだ全ての機能が入っていないケースも多いので注意が必要です。「Drupal 7で使ったこのモジュールのDrupal 8版があるので、Drupal 8でも同じことができるはずだ」と安易に考えるのは危険です。しっかりと調査をする時間を取ってからモジュールを導入する判断をすることをお勧めします。

まとめ

Drupal 8は非常に生産性の高いCMS・フレームワークであり、その機能も同じDrupal 8という世代の中でどんどん進化しています。しかし、長期的にシステムやサイトを保守、運用する場合、Drupal 7に比べて様々な要素を考慮してモジュールを導入したり、カスタムコードを書く判断をする必要があります。

社内のエンジニアや開発を依頼している会社が、気軽にモジュールをどんどん追加したりカスタムコードをたくさん書いているのであれば、「それ、本当に今後のメンテナンスを考えて判断してるの?」と聞いてみると良いかもしれません。

弊社のDrupal保守サービスにご興味をお持ちの方はこちらのページをご覧ください。
https://annai.co.jp/solutions/maintenance

(Photo by Luca Bravo on Unsplash)

連載中!:Drupal初心者講座

  • Drupal初心者講座について
  • 第1回 歴史に見るDrupal のDNA
  • 第2回 Drupalはフレームワークか?CMSか?(近日公開予定)
  • 第3回 Drupalの特徴(近日公開予定)
  • 第4回 Drupal 8のインストール(1)(近日公開予定)
  • 第5回 Drupal 8のインストール(2)(近日公開予定)
  • 第6回 コンテンツを投稿してみる(近日公開予定)
  • 第7回 ボキャブラリとタクソノミーを使う(近日公開予定)
  • 第8回 他のCMSと比較してみる(近日公開予定)