GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望
•
21 gefällt mir•6,101 views
2014/10/30 にリリースされました GMO プライベート DMP (pr.gmopdmp.jp) の開発に当たって取り組んできた DevOps のプラクティス、および今後発展させていきたいことについてご紹介します。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望
Ähnlich wie GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 (20)
GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望
- 1. GMO プライベート DMP 開発で 取り組んできた DevOps と今後の展望 GMO インターネット株式会社 次世代システム研究室 山邉 哲生 1
- 4. 4 今回のお話は GMO プライベート DMP 開発の裏側
- 5. 5 ① GMO プライベート DMP 開発初 期に取り組んだこと ② 実開発の中で明確になった問題点 ③ 今、取り組み始めたこと 開発着手 3月くらい ∧＿∧ ∧＿∧ （́<_｀ ） （ ́_ゝ`） / ⌒i ／ ＼ | | / /‾‾‾‾/ | ＿_ (__ﾆつ / FMV / .| .|＿＿＿＿ ＼/＿＿＿＿/ （u ⊃ イマココ！ 10月末 リリース
- 6. GMO プライベート DMP 開発初期に 取り組んだこと① 6
- 8. 8 էԺՙԳԷԯՊյՈԱ
- 9. 9 1. 開発者が自分だけの開発環境を持つこと ができる 2. それぞれの開発環境は独立しており、 個々の変更は互いに影響を及ぼさない
- 10. 10
- 12. 12 3. それぞれの開発環境は任意のタイミング で容易に最新化することができる 4. 開発環境の構成・構築手順はステージン グ環境や本番環境のそれと何も変わらない
- 13. 13 ローカルから本番環境 まで、リポジトリで管理さ れた同一手順で構築
- 15. 15
- 17. ポータビリティ＆一貫性 17
- 19. 19 • Docker 社が Go 言語で開発した、コンテ ナ型の仮想環境を管理するためのツール • Yelp, Spotify, Baidu, Rackspace, ebay… • ハイパーバイザー型より軽量な仮想環境の 実現（ホストからはプロセスとして見える） https://www.docker.com/resources/usecases/
- 20. VM アプリ ミドル ウェア アプリ ミドル ウェア ハイパーバイザー OS OS アプリ アプリ コンテナ管理ツール (Docker) VM OS コンテナ ミドル ウェア コンテナ ミドル ウェア 20
- 21. 21 • Infrastructure as Code • Dockerfile というコードで記述できる • Immutable Infrastructure • 状態を保持しない”使い捨て”イメージ • 設計思想として１コンテナ１サービス • コンテナを維持するには常駐するプロ セスが必要
- 22. 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. 23 • Infrastructure as Code • Dockerfile というコードで記述できる • Immutable Infrastructure • 状態を保持しない”使い捨て”イメージ • 設計思想として１コンテナ１サービス • コンテナを維持するには何かしら常駐 するプロセスが必要
- 24. Build Run Push Pull Stop 24
- 25. 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. 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. 27 2. Control groups (コントロールグループ) • 通称 cgroup(s) • プロセスをグループ化して、それぞれに提 供するリソースのコントロールを行う • CPU 時間、CPU コア • メモリ • デバイス etc
- 28. 28 3. Union file systems (UnionFS) 異なる FS のファイ ル・ディレクトリを 透過的に重ねて利用。 ! 親は読み取り専用。 https://docs.docker.com/terms/layer/
- 29. 29 4. Container format LXC (Linux Containers) から Docker 独自の libcontainer へ移行 http://www.zdnet.com/docker-libcontainer-unifies-linux-container-powers- 7000030397/
- 30. GMO プライベート DMP 概観 Hadoop エコシステム 管理画面 30
- 31. 31 Docker を使って初期開発を行ったもの 1. 管理画面 • Nginx + PHP + MariaDB 2. Hadoop (CDH5) • Flume (+HDFS) 3. RabbitMQ 4. ファイルサーバー
- 32. 32 • Dockerfile による構成管理の記述が楽 • 軽量なので必要なときに必要なイメージを 手軽に起動して開発できる
- 34. 34 էԺԷժՊԽվՃՏ
- 35. 35 Dockerfile の ビルドがつらい
- 36. 36 • 外部から取得するファイルが多すぎて再ビ ルドに時間がかかる
- 37. 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. 38 • 気がつくとライブラリがバージョンアウト してリポジトリから消失 • Dockerfile に記述しただけでは冪等性は保 証できない
- 39. 39 Windows がつらい
- 40. 40 • Linux カーネルの機能を使う Docker は Win/Mac 直上では動かない • 一枚 VM をかまして動かす必要がある
- 41. コンテナコンテナコンテナコンテナ boot2docker boot2docker VM (Linux) VM (Linux) Windows Mac 41
- 42. 42 • Docker というより Vagrant / VirtualBox を使う上での障壁が大きい • 64 bit イメージを動かすために BIOS 設定が 必要、Vagrant / VirtualBox のバージョン差 異に起因するエラーなどなど • 今は win 用の boot2docker インストーラが あるので楽になっている様子
- 44. 44 • Immutable Infrastructure を体現する Docker は内部状態を永続的に保持しない • 作業スペースを外出し（マウント）してお かないと commit しない限り Docker の 停止とともに消失する
- 45. 45 サブシステムも 多いし 分散環境が つらい
- 46. 46 • Git のリポジトリ（プロジェクト）数６つ • 常に最新の状態に保つための仕組みを作る 余力がなかった • 共用の開発環境が出来てからは Hadoop がらみの開発は直接 on-server で行われ るようになっていった
- 47. 47 Docker の アンチパターンを 理解していませんでした
- 48. 48 • ビルド済みのイメージではなく Dockerfile を配布してしまった • 複数のサービスを一つのコンテナに詰め込 んでしまった (supervisord パターン) • 作業ディレクトリをホスト OS に外出しし ていなかった
- 49. Vagrant 49 環境構築を Ansible 化するに伴って Vagrant 環境へ移行 Docker Nginx PHP FuelPHP MariaDB ! 上記イメージ の環境構築 (Dockerfile) Ansible Web と DB の構成管理 DB マイグレーション VirtualBox Nginx PHP FuelPHP VirtualBox MariaDB 移行
- 51. 51 • Chef や Puppet に並ぶ構成管理ツール • YAML でデータをいじるので Python を意 識しなくて良い • ほぼ全部入りでクライアントレス • 柔軟なディレクトリ構成
- 52. 52 • Web / DB を独立させて変更に強くなった • データが揮発しなくなった • Dockerfile に記述していた構築手順を Ansible に担わせることで、各種サーバへ のプロビジョニングを可能にできた
- 53. 53 • 重いので同時起動できる VM は限られる。 ノート PC での開発がたまに辛い。 • Win の敷居はまだまだ高い • box ファイルの作成・取得・差し替えの手 間が割と大きいので、一度配布されたイメー ジとマスターの乖離が大きくなりがち （DB スキーマ含む）
- 54. 54 ③ 今、取り組み始めたこと
- 55. 55 これを Vagrant Ansible Web と DB の構成管理 DB マイグレーション VirtualBox Nginx PHP FuelPHP VirtualBox MariaDB
- 56. 56 こうしたい Vagrant Ansible Web と DB の構成管理 DB マイグレーション オーケストレーション Docker Nginx PHP FuelPHP Docker MariaDB
- 57. 57 • Vagrant だろうが Docker だろうが開発 者には極力意識させたくない (PaaS 化) • せめてビルドせずに出来上がりの最新イメー ジをすぐ使えるようにしたい
- 59. 59 日次での Docker イメージの作成 & 単体・結合テスト テスト結果修正 開発者 Docker プライベートレジストリ 登録 オーケストレーション Docker コンテナ群
- 60. 60 Docker オーケストレーションツール ! • Kubernetes (Google + Docker, MS, Redhat…) • Panamax (Centurylink) • Fleet x CoreOS (CoreOS) • Fig (Orchard => Docker) • Serf (HashiCorp) • Maestro (signalfuse)
- 61. 61 まとめ㝹尳
- 62. 62 • Docker を使って局所的に仮想化を行うこ だけでも、必要な部分だけローカル環境で 立ち上げて開発を行ったり、共用環境調達 までのリードタイムを稼ぐことができる • Ansible による構成管理でプロジェクトを 横断したサーバ構築手順の再利用が進む
- 63. 63 • 分散システムはフルセットの開発環境を仮 想化で提供・保守するのは片手間だと困難 • 適切なバージョニングやマスターとの差 異の検知、統一的なデプロイの実装 • Ansible などで構成管理を切り出すため には専任の人員が必要
- 64. 64 • Mac で作ると大抵上手くいってしまうので 現場に一人でも Windows で開発する人が いるのであれば必ず Win 環境で構築・テ ストする • イメージの構築プロセスは隠蔽して極力出 来上がったものを共有する