GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望

GMO インターネット株式会社 次世代システム研究室

山邉 哲生

1

2http://pr.gmopdmp.jp

4

今回のお話は GMO プライベート DMP 開発の裏側

5

① GMO プライベート DMP 開発初期に取り組んだこと

② 実開発の中で明確になった問題点

③ 今、取り組み始めたことイマココ！

開発着手 3月くらい

10月末 リリース

　　　　　　　∧＿∧ 　　 ∧＿∧ 　（́<_｀ 　）　 （　́_ゝ`）　/　　 ⌒i ／　　　＼　　　|　| /　　 　/‾‾‾‾/　|

＿_ (__ﾆつ / FMV / .| .|＿＿＿＿ 　　　 ＼/＿＿＿＿/　（u　⊃

6

GMO プライベート DMP 開発初期に 取り組んだこと

①

7

『ポータブルでモダンな開発環境の実現』

8

9

1. 開発者が自分だけの開発環境を持つことができる

2. それぞれの開発環境は独立しており、個々の変更は互いに影響を及ぼさない

10

11

誰かの環境が 壊れても他の人は平気

12

3. それぞれの開発環境は任意のタイミングで容易に最新化することができる

4. 開発環境の構成・構築手順はステージング環境や本番環境のそれと何も変わらない

13

ローカルから本番環境まで、リポジトリで管理された同一手順で構築

14

『個々人が、他者に影響されない 本番環境と同じ構成の開発環境を持つ』

15

http://www.slideshare.net/beniyama/continuous-delivery-3594447916

ポータビリティ＆一貫性

17

https://www.docker.io/18

19

• Docker 社が Go 言語で開発した、コンテナ型の仮想環境を管理するためのツール • Yelp, Spotify, Baidu, Rackspace,

ebay… • ハイパーバイザー型より軽量な仮想環境の

実現（ホストからはプロセスとして見える）

https://www.docker.com/resources/usecases/

VM

ハイパーバイザー

OS

OS

ミドルウェア

アプリ

コンテナ管理ツール (Docker)

VM

OS

ミドルウェア

アプリコンテナ

ミドルウェア

アプリ

コンテナ

ミドルウェア

アプリ

20

21

• Infrastructure as Code • Dockerfile というコードで記述できる

• Immutable Infrastructure • 状態を保持しない”使い捨て”イメージ • 設計思想として１コンテナ１サービス

• コンテナを維持するには常駐するプロセスが必要

22

Dockerfile 記述例 !FROM centos MAINTAINER Tetsuo Yamabe !# Misc packages RUN yum groupinstall -y "Development Tools" RUN yum --enablerepo=epel,centosplus install -y rsyslog wget sudo passwd openssh openssh-server openssh-clients… !# User management RUN groupadd web RUN useradd -M -g web web …

23

• Infrastructure as Code • Dockerfile というコードで記述できる

• Immutable Infrastructure • 状態を保持しない”使い捨て”イメージ • 設計思想として１コンテナ１サービス

• コンテナを維持するには何かしら常駐するプロセスが必要

Build

Run Push Pull

Stop

24

25

!

Docker を支える要素技術 !

1. Namespaces 2. Control groups 3. Union file systems 4. Container format

https://docs.docker.com/introduction/understanding-docker/#what-is-dockers-architecture

26

1. Namespaces (名前空間)

• PID : プロセス ID (Linux 2.6.24 ～) • NET : ネットワーク (Linux 2.6.24 ～) • IPC : プロセス間通信 (Linux 2.6.19 ～) • MNT : マウント (Linux 2.4.19 ～) • UTS : ホスト名、ドメイン名など (Linux

2.6.19 ～)http://lwn.net/Articles/531114/

27

2. Control groups (コントロールグループ)

• 通称 cgroup(s) • プロセスをグループ化して、それぞれに提

供するリソースのコントロールを行う • CPU 時間、CPU コア • メモリ • デバイス etc

28

3. Union file systems (UnionFS)

https://docs.docker.com/terms/layer/

異なる FS のファイル・ディレクトリを透過的に重ねて利用。!親は読み取り専用。

29

4. Container format

http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers-7000030397/

LXC (Linux Containers) から Docker 独自の libcontainer へ移行

Hadoop エコシステム

管理画面

30

　GMO プライベート DMP 概観

31

Docker を使って初期開発を行ったもの 1. 管理画面

• Nginx + PHP + MariaDB 2. Hadoop (CDH5)

• Flume (+HDFS) 3. RabbitMQ 4. ファイルサーバー

32

• Dockerfile による構成管理の記述が楽 • 軽量なので必要なときに必要なイメージを

手軽に起動して開発できる

33

実開発の中で明確になった問題点

②

34

35

Dockerfile の ビルドがつらい

36

• 外部から取得するファイルが多すぎて再ビルドに時間がかかる

37

… RUN git pull RUN git checkout develop RUN git submodule init RUN git submodule update RUN php composer.phar self-update RUN php composer.phar update RUN npm install RUN grunt RUN php oil r install …

38

• 気がつくとライブラリがバージョンアウトしてリポジトリから消失

• Dockerfile に記述しただけでは冪等性は保証できない

39

Windows がつらい

40

• Linux カーネルの機能を使う Docker は Win/Mac 直上では動かない

• 一枚 VM をかまして動かす必要がある

Windows Mac

VM (Linux) VM (Linux)

boot2docker boot2docker

コンテナ コンテナ コンテナ コンテナ

41

42

• Docker というより Vagrant / VirtualBox を使う上での障壁が大きい • 64 bit イメージを動かすために BIOS 設定が

必要、Vagrant / VirtualBox のバージョン差異に起因するエラーなどなど

• 今は win 用の boot2docker インストーラがあるので楽になっている様子

43

作業内容が 消えそうでつらい

44

• Immutable Infrastructure を体現する Docker は内部状態を永続的に保持しない

• 作業スペースを外出し（マウント）しておかないと commit しない限り Docker の停止とともに消失する

45

サブシステムも 多いし 分散環境が つらい

46

• Git のリポジトリ（プロジェクト）数６つ • 常に最新の状態に保つための仕組みを作る

余力がなかった • 共用の開発環境が出来てからは Hadoop

がらみの開発は直接 on-server で行われるようになっていった

47

Docker の アンチパターンを 理解していませんでした

48

• ビルド済みのイメージではなく Dockerfile を配布してしまった

• 複数のサービスを一つのコンテナに詰め込んでしまった (supervisord パターン)

• 作業ディレクトリをホスト OS に外出ししていなかった

Vagrant

49

環境構築を Ansible 化するに伴って Vagrant 環境へ移行

Docker

Nginx PHP FuelPHP MariaDB !上記イメージの環境構築 (Dockerfile)

VirtualBoxNginx PHP FuelPHP

VirtualBox

MariaDB

AnsibleWeb と DB の構成管理 DB マイグレーション

移行

http://www.ansible.com/home50

51

• Chef や Puppet に並ぶ構成管理ツール • YAML でデータをいじるので Python を意

識しなくて良い • ほぼ全部入りでクライアントレス • 柔軟なディレクトリ構成

52

• Web / DB を独立させて変更に強くなった • データが揮発しなくなった • Dockerfile に記述していた構築手順を

Ansible に担わせることで、各種サーバへのプロビジョニングを可能にできた

53

• 重いので同時起動できる VM は限られる。ノート PC での開発がたまに辛い。

• Win の敷居はまだまだ高い • box ファイルの作成・取得・差し替えの手

間が割と大きいので、一度配布されたイメージとマスターの乖離が大きくなりがち（DB スキーマ含む）

54

③ 今、取り組み始めたこと

55

これを

Vagrant

VirtualBoxNginx PHP FuelPHP

VirtualBox

MariaDB

AnsibleWeb と DB の構成管理 DB マイグレーション

56

こうしたい

Vagrant

オーケストレーションDocker

Nginx PHP FuelPHP

Docker

MariaDB

AnsibleWeb と DB の構成管理 DB マイグレーション

57

• Vagrant だろうが Docker だろうが開発者には極力意識させたくない (PaaS 化)

• せめてビルドせずに出来上がりの最新イメージをすぐ使えるようにしたい

58

Docker イメージの継続的デリバリー

59

日次での Docker イメージの作成 & 単体・結合テスト

開発者

テスト結果 修正

Docker プライベートレジストリ

登録

Docker コンテナ群

オーケストレーション

60

Docker オーケストレーションツール!

• Kubernetes (Google + Docker, MS, Redhat…) • Panamax (Centurylink) • Fleet x CoreOS (CoreOS) • Fig (Orchard => Docker) • Serf (HashiCorp) • Maestro (signalfuse)

61

まとめ

62

• Docker を使って局所的に仮想化を行うこだけでも、必要な部分だけローカル環境で立ち上げて開発を行ったり、共用環境調達までのリードタイムを稼ぐことができる

• Ansible による構成管理でプロジェクトを横断したサーバ構築手順の再利用が進む

63

• 分散システムはフルセットの開発環境を仮想化で提供・保守するのは片手間だと困難 • 適切なバージョニングやマスターとの差

異の検知、統一的なデプロイの実装 • Ansible などで構成管理を切り出すため

には専任の人員が必要

64

• Mac で作ると大抵上手くいってしまうので現場に一人でも Windows で開発する人がいるのであれば必ず Win 環境で構築・テストする

• イメージの構築プロセスは隠蔽して極力出来上がったものを共有する

65

ご清聴ありがとうございました