2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Drupal9 環境構築(Docker)

Posted at

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 する必要があります。

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

image.png

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

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

image.png

ふむふむ。

ヘッドレス対応

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

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

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

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

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

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

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

image.png

管理用テーマは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 に対する優位性ですね。(合っているかな・・・)

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

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?