docker-composeでローカル環境を構築していて、データベースの構成が変わったときの対応

受付中

回答 1

投稿 編集

  • 評価
  • クリップ 3
  • VIEW 1,179

Sfidante

score 96

 状況

docker-compose build時にMySQLを起動し、dump.sqlのようなデータベースのデータを全てインポートしております。
MySQLはどこかのサーバーに繋いでいるわけではなく、コンテナ内に立てて、それぞれのローカルで動かすイメージです。

 問題点

アプリケーション開発をする上での問題点なのですが、
もし、データベースの構成がALTER TABLE等で変わった場合、
ソースコードはデータベースの構成が変更された状態になっているのですが、
dump.sqlの構成は更新されていないので、
変えた本人以外はアプリケーションを立ち上げた時にエラーになってしまいます。

そうなると、都度、dump.sqlを編集するという作業が必要になってくるという問題が発生します。

上記の問題を回避すべき方法は以下の通りだと考えています。

  • ローカルではなく、別にデータベースサーバーを立てて、そこに接続するようにする(このサーバーの管理が必要)
  • docker-compose buildをしたときに、ステージング環境等からdumpしてきて、そのdump.sqlを利用する(時間がかかる & ローカルで登録等したデータが消えてしまう)
  • ALTER TABLE等でデータベースの構造が変わる際、dump.sqlと同階層に保存し、docker-compose build時にdump.sqlと同様に構築できるようにする(ルール化)

皆様はどのような方法が良いと思いますか?
上記であげた方法、それ以外にもうちではこのようにしている等ございましたらご教授いただけると幸いです。

よろしくお願い致します。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

0

使用しているアプリケーションのフレームワークでマイグレーションとシーダーを使ってください。例えば PHP + Laravel の開発では

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateFlightsTable extends Migration
{
    /**
     * マイグレーション実行
     *
     * @return void
     */
    public function up()
    {
        Schema::create('flights', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->string('airline');
            $table->timestamps();
        });
    }

    /**
     * マイグレーションを元に戻す
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('flights');
    }
}

のようなマイグレーションファイル,および

<?php

use Illuminate\Database\Seeder;
use Illuminate\Database\Eloquent\Model;

class DatabaseSeeder extends Seeder
{
    /**
     * データベース初期値設定の実行
     *
     * @return void
     */
    public function run()
    {
        DB::table('users')->insert([
            'name' => str_random(10),
            'email' => str_random(10).'@gmail.com',
            'password' => bcrypt('secret'),
        ]);
    }
}

のような,開発用のダミーデータを投入するシーダーファイルを必要なぶんだけ作り,

./artisan migrate:fresh --seed

を実行してますね。このコマンドを実行すると

  • データベースの全テーブルの削除+再作成
  • テーブルへのデータ投入

がその都度行われます。

開発環境ではこのようにテーブル群をゼロから構築し,データをその都度再投入すればよいです。またリリース前段階の開発では,作成済みのマイグレーションファイルを編集してコミットしても構いません。

逆にリリース後には,それまで作成したマイグレーションファイルには一切触れてはいけません。変更が必要な場合,新しいマイグレーションファイルにALTER TABLEを書きます。必要に応じてデータの挿入処理を書いたりもします。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/03/16 15:09

    本質はアプリケーションフレームワークの機能を使え,ということではありません。使わなくてもいいです。素のSQLでやるなら

    ・(ソートして順番に実行できるように日付時刻をファイル名に含めた)CREATE TABLE のみを行うファイルを作成する。この段階ではCREATE TABLEをかき消していいのでALTER TABLEは不要。

    ・リリースごとに新しいファイルを作って乗り換え,古いファイルには一切触らないようにする。

    この2つを守ればよいです。

    キャンセル

  • 2018/03/19 13:56

    ご回答頂きまして、ありがとうございます。

    現状はリリースされており、今までのマイグレーションファイルは一切存在しない状況です。
    その場合、追加分からマイグレーションファイルを作成していき、Dockerfileでコマンド実行するという認識でよろしいでしょうか?

    よろしくお願いいたします。

    キャンセル

  • 2018/03/19 21:53 編集

    >> その場合、追加分からマイグレーションファイルを作成していき、Dockerfileでコマンド実行するという認識でよろしいでしょうか?

    私だったら,一番最初のマイグレーションファイルで dump.sql を実行するだけの処理をそのまま書きますね。極端な話,シェルコマンドを呼び出すだけのコードを書いておけばそれで動きます。そして続きからは細かく切ったマイグレーションファイルを作っていけばいいです。

    Dockerfileでやっちゃうと開発環境で何かやらかしてDROP DATABASEしてリセットしたくなったときに手間がかかって若干困るかなぁと思います…

    キャンセル

  • 2018/03/19 21:58 編集

    (もちろん dump.sql に実データが入っているとか極端にサイズが大きいとかであれば,開発用の少量のダミーデータに変更しておくべきだとは思います)

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.21%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる