gmo プライベート dmp 開発で 取り組んできた devops と今後の展望
DESCRIPTION
2014/10/30 にリリースされました GMO プライベート DMP (pr.gmopdmp.jp) の開発に当たって取り組んできた DevOps のプラクティス、および今後発展させていきたいことについてご紹介します。TRANSCRIPT
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 • 状態を保持しない”使い捨て”イメージ • 設計思想として1コンテナ1サービス
• コンテナを維持するには常駐するプロセスが必要
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 • 状態を保持しない”使い捨て”イメージ • 設計思想として1コンテナ1サービス
• コンテナを維持するには何かしら常駐するプロセスが必要
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 のリポジトリ(プロジェクト)数6つ • 常に最新の状態に保つための仕組みを作る
余力がなかった • 共用の開発環境が出来てからは 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
ご清聴ありがとうございました