Drupal Advent Calendar 2015 13日目です！
このページは以下の資料の参考にして、
実際にDrupal8で手を動かしてみた記録になります。
https://www.acquia.com/resources/ebooks/ultimate-guide-drupal-8
(資料は登録するとダウンロードできました。)
Drupal8のエッセンスが詰まっていて素敵な資料です。
既にこちらをお読みの方は・・・ここで終了でございます。
Configretion Manegerとは？
Drupal8の新機能で、DBに保存されている設定情報をエクスポート・インポートできる機能です。
なにが嬉しい？
メリットを享受できるのは実際にコードを書いてカスタマイズしたり、リリース作業を担当するプログラマーです。修正の反映２度手間！な作業が少し減ります。
詳細
以下、個人的な思いがあふれます。
Drupalはコンテンツ設定・サイト設定などの「設定情報」のほとんどをDBに持っているため、
その情報を別環境に反映したいときは、同じ手順を踏んで別環境で反映しなければいけないですよね。
例えば開発環境で管理画面よりブロック追加したら、検証環境・本番環境にも同じように管理画面からブロックを追加・・・
手作業は間違えの元、緊張もあいまって、本番反映時に設定をミスって障害発生・・・超怒られる（当たり前。でも繰り返す・・・）
↓
リリースは・・・
ソース反映 + コマンド１個実行くらいで終わらないのかなーーー！
スクラッチ開発の方がいいよね!!ってなってきます。
(CMSカスタマイズをやっていると1回くらいありませんでしたか・・・？)
※この思いを解消してくれる機能はD７の時点でもあります。モジュールのhook_update_N()を定義したりFeaturesなどのモジュールやDrush実行でできる反映など。
Configretion Manegerが素敵なことは、
- 設定情報のファイル形式がymlファイル。
- よく見る形式、見慣れてる！修正時のDiffが取りやすい気がする！
- 反映のコマンドはDrushで提供されている。
- 大規模リリースでもソース反映 + 簡単なシェル実行１個 で完結するのも夢じゃない！
- いままでの反映時の障害がなくなるかも！(怒られなくなるかも！)
ということでスクラッチに戻りたいとか思わなくなります。たぶん。
なにが設定ファイル化できるの？
一例として・・・(参考資料抜粋です)
- Content Types
- Custom Block Types
- User Roles
- Views
- Taxonomy Vocabularies
- Image Styles
プログラマーがカスタム設定しそうなところは、
大体網羅されてるのでは？と思います。
ただBasic pageなどのコンテンツ自体や登録されたメニューなどの情報は、
設定ファイル化できないので、各自でがんばらないとです。
参考にさせていただいた資料には
8.1.0 や8.2.0にもしかしたらコンテンツ自体のサイト間移行機能が用意されるかも・・・
なんて書いてありました。ぜひ実装されて欲しい！です。
想定される使い方
- 【A環境】Configretion Manegerの管理画面から、全設定ファイルをエクスポートする。
- 【A環境】DrupalのStagingディレクトリに配置、Gitで管理。
- 【B環境】Git経由で設定ファイルを取得、配置。
- 【B環境】管理画面 で設定をインポート。
おまけ その１
イメージ図で載せていますが、
設定ファイルのエクスポート元、インポート先はConfigテーブルです。
テーブルを眺めるとymlのファイル名、ファイル内容と一致します。
キャッシュはconfig_chacheみたいです。
Drupal7でいうと
- system
- variable
- field_config
- node_type etc…
このような設定情報を保持していたテーブルが
Drupal8ではconfigテーブルに集約された感じがします。
Configretion Manegerの管理画面はどこにある？
Configuration > Configuration synchronization です。
URLは「/admin/config/development/configuration」です。
設定ファイルを置くディレクトリはどこにある？
sites/deault/setting.php で設定します。マルチサイト構成の場合は、そのサイトのsetting.phpをみてください。
対象の変数はこちら。
$config_directories['active']
$config_directories['staging']
デフォルトだとsites/deault/files配下に対象ディレクトリがあると思います。
.gitignoreの指定
自分の中ではぞれぞれのディレクトリは、
| ディレクトリ | 用途 |
|---|---|
| Active | 現設定を一時的に出力する場所。Git管理したくない。 |
| Staging | これから反映する設定を配置する場所。Git管理したい。 |
という風に解釈しています。
またsites/deault/files配下はGit管理対象がにしていることが多いので、
Stagingディレクトリだけ、sites/default/config/を作成、その配下に移動しました。
って書いた後に、こんな風に設定している方もいました。こちらの方が真っ当な気がします。。。
実際に使って見る
A環境というサイトがあり、B環境はそのコピーしたサイトとします。
A環境でブロックを追加し、B環境へ設定ファイル経由でブロック情報をインポートしてみます。
準備として、A環境にブロックを追加する前に、
全設定ファイルをエクスポートしてStagingディレクトリに配置します。
【A環境】準備
-
Configuration > Configuration synchronizationを表示し、Exportタブをクリック。 - タブ内にあるExportボタンをクリックすると全設定ファイルが入ったtarファイルがダウンロードされます。
- tarファイルを展開して、Stagingディレクトリへ配置します。
【A環境】ブロックを追加
Structure > Block layout のメニューでカスタムブロックを追加、現在のテーマのヘッダーにセットしました。
(なんとなくでいけると思います。説明すっ飛ばします。)
この時点で、【A環境】のConfiguration > Configuration synchronization を表示してみると、なにやら差分が・・・。
このページは現在のDB内設定とStagingディレクトリの差分を表示してくれます。
Stagingディレクトリに追加したブロックの設定ファイルがないので、「1 Removed」となっています。
(この状態でimport allを実行すると・・・追加したブロックは削除されます！)
【A環境】設定ファイルをエクスポート
準備と手順と同じでStagingディレクトリに設定ファイルを配置します。
ここで【A環境】Configuration > Configuration synchronization を見てみると、差分がなくなっています。
DB内設定とStagingディレクトリの内容が同じになったということですね。
【B環境】インポート
StagingディレクトリにA環境の設定ファイルを配置します。
ここで【B環境】Configuration > Configuration synchronizationを見てみると
「1 New」表示になりました。
この状態でimport allボタンをクリック・・・
ブロック設定のページをみると、ちゃんと追加されてます。
Drushで実行
エクスポート
drush cex
Stagingディレクトリ内、旧設定ファイルを削除してから新設定ファイルが配置されます。
インポート
drush cim
StagingディレクトリをDBへインポートします。
いままで管理画面で必死に説明してきましたが・・・
Drushの方がナニこれレベルで楽です(笑)
カスタムモジュールの設定をConfigretion Manegerに任せる
Configretion APIを利用します。
http://drupal.org/project/examples
ここでダウンロードできるサンプルをみると超わかりやすいです。
私はまだテスト実装もできていません。ごめんなさい。
ハマったところ
どんな情報が設定ファイルに出力されるのかは、
そのモジュール次第なところにはまるかもしれないです。
カスタムブロックを追加するだけ、テーマに配置なしの状態で説明しようとしたのですが、
なんと設定ファイルが出力されず・・・。
いろいろなパターンのエクスポート・インポートを試さないとなぁと思い直した次第です。
最後に
Drupal7と比較してDrupal8は全体的に開発者に優しい作りになっていると思います。
モジュールの仕組みが、えっそんな・・・というくらい仕組みが変わっていて、吸収するのが大変ですが、
コントリビューションモジュールが整ってくるのもこれからなので
今のうちにコアで出来ることを覚えたいなと思います。
以上です。