Drupal9 環境構築（Docker）

Drupal の時代が来る？

落札したANNAIはCMS（コンテンツ管理システム）「Drupal」（ドルーパル）を使ったWebシステム開発を手掛ける。内閣府や東京大学、京都市などのWeb開発に携わった実績を持つという。

入札説明会の段階で、ヘッドレスCMSという点が、比較的論点になっていたと思います。

「政府統一Webサイト構築に向けたサービス基盤及びデザインシステム等の実証に関する調査業務」に係る入札説明会での質疑応答について

正直、WordPressで良いんじゃない、と思っていたのですが、そうなんですね。
そうとなったら、勉強しておきますか。
そんな感じです。

構成を考える

こちらの構成は、非常に魅力的に感じられました。

個人的には、動的であることはCMSの一つの魅力ではないかと思っていたのですが、世界はどうもそうではない、という気もしてきていて、例えば政府サイトなどは、結構CMSから静的サイトを出力するタイプが多いのではないか、という気がしています。（気がしているだけで、エビデンスはなし）

そう考えた時に、コンテンツをDrupalで作って、何かを介して静的サイトを構築する必要があるのではないか、上記構成はこれに応えるものではないか、そう思ったわけです。

素のDrupal

とはいえ、まずは、素のDrupal サイトを構築します。
DBも必要だし、Docker 構成にします。

基本的には、こちらの通りです。

ただし、ディレクトリ権限の設定が必要です。

chmod +x docker-entrypoint.sh

しかし、これだけだと、この後のインストール画面で、

デフォルトの設定ファイル
デフォルト設定ファイルが存在しません。
Drupal のインストールでは、./sites/default/default.settings.php ファイルをダウンロードしたそのままの状態で、削除も変更も行ってはいけません。
設定ファイル
設定ファイル は存在しません。
Drupal インストーラーはインストールプロセスの中で ./sites/default/settings.php を作成できることを必要としています。 ./sites/default/default.settings.php を ./sites/default/settings.php にコピーしてください。 Drupal のインストールについてのより詳しい情報は INSTALL.txt でご確認いただけます。

というエラーになりますので、事前にもう少し権限をつけておく必要があります。
ちなみに、各フォルダも作っておく必要があります。

chmod a+w default
chmod a+w default/files

また、上記サイトで、

最後に Drupal の configuration management を有効にするために、固定のUUIDをセットしています。
このUUIDはプロジェクトごとに変更すると良いと思います

とありました。uuid生成は、こちらで生成してみました。

準備ができたら、docker compose up して、しばらく待ちます。
ちょっとわかりにくいですが、この表示になったら、スタンバイOKです。

drupal_1  | [Sun Aug 29 08:24:13.240857 2021] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

ここで、http://localhost:3080/ を開くと、Drupal 9.2.4 のインストール画面が開きました。

そういえば、ポートは

docker-compose.yml

    ports:
      - "3080:80"

にしてます。

プロフィールというところで、初期構成を選択しますが、せっかくなので、プロフィールとして Umamiフードマガジン を選択してみました。

先に述べた、default.settings.php はこのタイミングで発生しました。
ここで改めて対応する場合は、権限を付けて（これはコンテナ内でやらなくて良いです）、イメージを削除（docker rmi）してから改めて　up　する必要があります。

あとは、メンテナンスアカウントなどを設定すると、動きました！

検索、ホーム、記事、レシピのフォントが気になるけど、全体的には良い感じかな。

とりあえず、テーマをBootstrapに変更してみました。

ふむふむ。

ヘッドレス対応

では、ヘッドレスが重視されているようなので、対応してみます。

日本語サイトとしては、真っ先にこちらがヒットすると思います。

RESTful Web Services と REST UI の2つのモジュールをインストールすると書かれています。

モジュールのインストールは、日本語だと、「拡張機能」からおこないます。
ところが、行ってみると、ここに用意されているのは、RESTful Web Services と、Serialization。

こちらに、その構成で書かれているので、それに従って、設定していきます。

手順3で、対象データを選択しますが、今回は、コンテンツ(/admin/content)を指定してみました。

ここで問題。管理画面が思いっきり崩れている。

管理用テーマはSevenに戻します・・・

その後は手順に従って、無事jsonのプレビューができました。

このあとどうするか

当初の構成だと、ここから静的サイトの出力に行こうと思いました。

こんなモジュールも提供されており、それはそれでできるようです。

ただ、例えば、検索機能は死んでしまう。
その他、色々制限があることが書かれています。

確かに、自分のブログも、Hugo で静的生成していますが、検索は外部に頼るわけですね。

ここで、完全に静的にする必要はないかと考え直します。

静的コンテンツは静的にしておきますが、コンテンツ部分はAPI経由で取得する。
JAMスタック構成ですね。

結局そうなるんだなぁ。
まあ、ちょっと今作っているものを、Drupal対応してみようか（続く・・・）。

Drupal に対する現時点での感想

ここ最近作っているものは、APIを Django REST Framework で作って、フロントをNuxtで作って、Netlify とか、Azure Static Web Apps のJAMスタック環境で動かしています。

Djang でも、データメンテ画面はそれなりに生成してくれるので、これで良いんじゃないかと思っていました。

ただ、もう少し複雑なデータになってくると、確かに、CMS的な画面が必要になってくるかという気はします。
そもそも、Modelを作って、serializer作って・・・というのは、確かに敷居は高い。
というのが、Django REST Framework に対する、ヘッドレスCMSの優位性かと理解しました。

さらに、WordPressだと、やはり本来ブログツールかな、というのは否定できず、要するにデータ構成がそうなっている。
もちろん、色々拡張して、商品販売とかもできるわけですが、それは標準データからは外れてしまうので、ヘッドレス化した時に、どこまで対応しているか不安（これはやってみていないので、意外とできるものもあるかもしれませんが、それはプラグインが頑張ってくれているのであって、やはりそのプラグインの構成には縛られるはず）。

これに対して、Drupal は、そもそもデータ構成の定義（コンテンツタイプ）が本来の機能となっているため、それをAPIとして提供することが当然想定されている。要するに、ビジュアルに、ノーコードでデータ定義をして、データ作成ができる。これは強いかなと思います。（ちょっと気になっているのは、データの親子関係とか、その辺はこれから勉強）
ここが、Drupal の、WordPress に対する優位性ですね。（合っているかな・・・）

ちょっとポエムっぽくなりました。すみません ><