イノベーション エンジニアブログ


株式会社イノベーションのエンジニアたちの技術系ブログです。ITトレンド・List Finderの開発をベースに、業務外での技術研究などもブログとして発信していってます!


このエントリーをはてなブックマークに追加

FW移行プロジェクトのLaravel,Golangの開発環境について考えてみる(Docker)

みなさんこんにちは

こへです。 そろそろ、開発環境周りについていろいろ語りたい時期がきましたので記載

どんなプロジェクトか?

FW移行

サーバサイド

Laravel

フロントサイド

Vuejs

バッチ

Golang

環境

Docker

DB

Postgres9系→10系へ table構成も変更

インフラ

Kubernetes

Gitリポジトリ構成

1つのリポジトリですべてを管理するにはあまりにもでかい
golangとdocekrとlaravelとdocker-compose関係は触るメンバーが別々なので依存をなくしたいということで、

リポジトリを5つ使用&submodule化

  • DevEnv (以下のリポジトリ+docker-compose)

    • Online (Laravel,Vue)

    • Batch (Golang)

    • Docker (Dockerfiles)

    • Embulk

DeVEnvリポジトリが他4つのリポジトリを管理し、

docker-composeで各リポジトリのソースコードとコンテナとvolumeする

※Dockerリポジトリは、別

DevEnv

docker-compose.yml、Postgresのdumpファイルなど開発環境だからこそ必要なものを置く箇所。

Online

Laravel,Vuejsのソースコードを置く

Batch

Golangのソースコードを置く

Docker

各イメージを作るための。Dockerfile郡を置くリポジトリ

Embulk

旧Postgresから新Postgresへデータを移行する際に、必要な emblk file郡を置く

docker-compose.yml & Imageの説明

docker-compose.ymlはDevEnvリポジトリにおいておく

全部で11コンテナも必要…

  • nginx

  • php

  • node

  • mailhog

  • redis

  • redis-2

  • go

  • stub(go)

  • postgres-old

  • postgres-new

  • embulk

version: '3.7'
services:
#online
  nginx:
    build:
      context: ./Docker/online/nginx
    depends_on:
      - php
      - redis
      - mailhog
      - new-postgres
      - node
    ports:
      - 443:443
    volumes:
      - ./online/var/www:/var/www:cached
    environment:
      - TZ=Asia/Tokyo

  mailhog:
    image: mailhog/mailhog
    ports:
      - "8025:8025"
      - "1025:1025"

  redis:
    image: redis:3
    container_name: redis-1
    ports:
      - "6379:6379"

  php:
    build:
      context: ./Docker/online/phpfpm
    volumes:
      - ./online/var/www:/var/www:cached
      - ./Docker/online/phpfpm/usr/local/etc/php/php.ini:/usr/local/etc/php/php.ini:cached
    environment:
      - TZ=Asia/Tokyo

  node:
    image: node
    tty: true
    volumes:
      - ./online/var/www:/var/www:cached
    working_dir: /var/www

#batch
  batch:
    build:
      context: ./Docker/batch
    depends_on:
     - fw-postgres
     - redis-shorturl
     - stub
     - mailhog
    volumes:
     - ./go/src/github.com/:/go/src/github.com/
     - ./go/temp:/temp
    #covarage のhtml出力を見るため
     - ./go/tmp:/tmp
    working_dir: /go/src/github.com
    ports:
     - "6060:6060"
    #debugができるようプロセスの監視を許可する
    security_opt:
     - seccomp:unconfined
    env_file:
      - ./Docker/batch/.go_env
    environment:
      - TZ=Asia/Tokyo
    command: ["godoc", "-http=:6060"]

  stub:
    image: golang:latest
    ports:
     - "9090:9090"
    volumes:
     - ./stub:/go/stub
    working_dir: /go/stub/api
    command: ["go", "run", "main.go"]

  redis-two:
    image: redis:3
    container_name: redis-tow
    ports:
      - "63790:6379"

#昔のpostgres
  postgres:
    image: xxxxxxxx/postgres:latest
    container_name: old-postgres
    ports:
      - "5432:5432"

  new-postgres:
    image: postgres:10
    ports:
      - "54320:5432"
    environment:
      POSTGRES_DB: xxxxxx
    volumes:
      - ./embulk/postgres_init:/docker-entrypoint-initdb.d
      - ./postgresql/data:/var/lib/postgresql/data
    environment:
      - TZ=Asia/Tokyo

  embulk:
    image: kooooohe/embulk
    depends_on:
      - postgres
      - fw-postgres
    container_name: embulk
    volumes:
      - ./embulk/opt:/opt
    env_file:
      - ./Docker/embulk/.env

nginx, php

Laravel,Vuejsを動かすためのImage

node

VuejsをトランスパイルするためのImage
(本番では使わない)

mailhog

Login時などのメールをローカルで受け取るためのImage
(本番では使わない)

redis

LarvelでSessionを保持するためのImage
(本番ではクラウドベンダーのフルマネージドサービスを使う)

redis-2

その他簡易なkey-valueを保持するためのImage
(本番ではクラウドベンダーのフルマネージドサービスを使う)

go

golangで書かれたBatchを動かすimage
(本番ではマルチステージングビルドを使用し、alpineのimageで動かす)

stub(go)

golangで書かれたローカルでサードパーティのAPIの代わりとなるスタブImage
(本番では使わない)

postgres-old

postgres9系のイメージ。 ローカルに保存されたdumpファイルを元にデータが初期化される。
(本番では使わない)

postgres-new

postgres10系のイメージ
postgres-oldからembulkを使用し、データを移行する。

ローカルに保存された、DDLを元に初回コンテナ起動時に初期構築される。
(本番ではクラウドベンダーのフルマネージドサービスを使う)

embulk

postgre-oldからpostgres-newへデータ移行するためのコンテナ
(本番では使わない)

最後に

これだけ大規模な開発環境を作ると、小さな環境差異が大変なことになってしまいます。 また、メンバーも10人程度いるので、手に負えなくなります。

dockerを使うと、全員に全く同じ環境をいとも簡単に作ることができます。

GitのSubmoduleはDockerでの開発環境と非常に相性が良いように感じました。

おわり