Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

5,827 views

Published on

2014/10/30 にリリースされました GMO プライベート DMP (pr.gmopdmp.jp) の開発に当たって取り組んできた DevOps のプラクティス、および今後発展させていきたいことについてご紹介します。

Published in: Internet
  • Login to see the comments

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

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

×