O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Dockerを使ってローカルテストを良い感じに実装した話

355 visualizações

Publicada em

Kubernetesのソースコードリーディング入門 APC勉強会#34 発表資料
https://8a1-apc.connpass.com/event/142874/

Publicada em: Internet
  • Seja o primeiro a comentar

Dockerを使ってローカルテストを良い感じに実装した話

  1. 1. Dockerでローカルテストを 良い感じに実装した話 (株)エーピーコミュニケーションズ 山岡 亮
  2. 2. 自己紹介 • 日常の仕事 • NEEDLEWORK(自社製FWテストツール) のバックエンド • Webアプリのバックエンド • 普段使い: Go, GCP, CircleCI, Docker • 趣味: 料理、ゲーム、コーディング、インフラいじり • 大学生(計算機科学)の片手間に会社員やってます Twitter: @mountainhill14 Blog: https://dokupe.hatenablog.com/ GitHub: https://github.com/ryo-yamaoka
  3. 3. 今日話すこと • 少しだけ自社アプライアンスの紹介 • 本題の前提知識として軽く(営業目的ではありません) • Dockerを使って手元のテストを良い具合に実装した事例 • ↑の実装で困ったこととその解決方法
  4. 4. NEEDLEWORKの紹介 https://www.ap-com.co.jp/ja/needlework/
  5. 5. 開発で考慮しなければならない特性 • アプライアンスであること • オフラインでの利用が前提 • ファームウェアのアップデート等もユーザー自身で作業する
  6. 6. 開発における課題
  7. 7. 開発における課題 ファームウェアアップデーターのテストが辛い
  8. 8. どう辛いか
  9. 9. どう辛いか • アプライアンスのOS上でファイルやサービスの操作がある • ローカルで動作テストをすると開発環境に影響が出る • オフライン&ユーザー作業が前提なのでファーム更新は可能な 限りトラブルを少なくしたい
  10. 10. どう辛いか • アプライアンスのOS上でファイルやサービスの操作がある • ローカルで動作テストをすると開発環境に影響が出る • オフライン&ユーザー作業が前提なのでファーム更新は可能な 限りトラブルを少なくしたい • 実機でしか動作確認できないのは不便 • 勿論最終的には実機確認もやらなければならないが、 開発環境でできないのはしんどい • VMとスナップショットでもできるがもっと手軽にやりたい
  11. 11. 解決方法
  12. 12. 解決方法 • Dockerを使い試験環境を使い捨てる
  13. 13. 解決方法 • Dockerを使い試験環境を使い捨てる • コンテナ内部で実際のファイル操作を行えるので限りなく 実環境に近いテストを行える • 各種OSの公式コンテナがある
  14. 14. 実際の動作
  15. 15. 実際の動作 • make test で実行開始
  16. 16. 実際の動作 • make test で実行開始 • 試験に必要な各種ファイルを生成する (ダミーのDaemonとかアップデートファイル等)
  17. 17. 実際の動作 • make test で実行開始 • 試験に必要な各種ファイルを生成する (ダミーのDaemonとかアップデートファイル等) • テスト用のネットワークを作成しコンテナを起動、 生成したファイルを配置する • アプライアンスの仕様で 192.0.2.0/24 を使う必要がある
  18. 18. 実際の動作 • make test で実行開始 • 試験に必要な各種ファイルを生成する (ダミーのDaemonとかアップデートファイル等) • テスト用のネットワークを作成しコンテナを起動、 生成したファイルを配置する • アプライアンスの仕様で 192.0.2.0/24 を使う必要がある • Goのテストで実際にAPIを操作してアップデートや ダウングレードを実行する
  19. 19. 良かったこと
  20. 20. 良かったこと • 手元で気軽に何度でもテストを流せるようになった • 安心感すごい
  21. 21. 良かったこと • 手元で気軽に何度でもテストを流せるようになった • 安心感すごい • 品質が向上した • コード変更の影響がすぐわかる • テスト実装中にいくつか未発見だったバグを潰せた
  22. 22. 良かったこと • 手元で気軽に何度でもテストを流せるようになった • 安心感すごい • 品質が向上した • コード変更の影響がすぐわかる • テスト実装中にいくつか未発見だったバグを潰せた • CIに乗せられるようになった(はず) • 試していないがDockerで動くのでCircleCIとかに持っていけるはず (現状はCIに乗せる要件はない(実質1人開発)のでやってない)
  23. 23. ハマったところ
  24. 24. ハマったところ • Dockerの本来の用途から外れているので色々辛い • systemdを使う前提になっていない • コンテナ内部で複数プロセスを立てるのが面倒
  25. 25. ハマったところ • Dockerの本来の用途から外れているので色々辛い • systemdを使う前提になっていない • コンテナ内部で複数プロセスを立てるのが面倒 • Dockerfileのビルド時になぜかyumコマンドがコケる
  26. 26. Docker(CentOS)でsystemdを使うには
  27. 27. Docker(CentOS)でsystemdを使うには • 普通にsystemdを叩くと Failed to get D-Bus connection: No connection to service manager. になる
  28. 28. Docker(CentOS)でsystemdを使うには • 普通にsystemdを叩くと Failed to get D-Bus connection: No connection to service manager. になる • DockerfileのCMDを/sbin/initにする
  29. 29. Docker(CentOS)でsystemdを使うには • 普通にsystemdを叩くと Failed to get D-Bus connection: No connection to service manager. になる • DockerfileのCMDを/sbin/initにする • コンテナ起動時に --privileged を付ける • サービスなら避けるべきだが今回は使い捨て環境なのでリスクは無い
  30. 30. 複数プロセス立て+オペレーションする
  31. 31. 複数プロセス立て+オペレーションする • Dockerfileのハックとかsystemdでどうにかする事は諦めて 愚直にコマンド羅列
  32. 32. 複数プロセス立て+オペレーションする • Dockerfileのハックとかsystemdでどうにかする事は諦めて 愚直にコマンド羅列 • テストシナリオに docker exec (中略) systemctl start xxx みたいなのをたくさん書く
  33. 33. Dockerfileのビルド時にyumがコケる
  34. 34. Dockerfileのビルド時にyumがコケる • overlayfs絡みの問題で Rpmdb checksum is invalid: dCDPT(pkg checksums) が出た
  35. 35. Dockerfileのビルド時にyumがコケる • overlayfs絡みの問題で Rpmdb checksum is invalid: dCDPT(pkg checksums) が出た • yum-plugin-ovl を入れて解決
  36. 36. おわりに
  37. 37. まとめ • コンテナをVMのように扱うのは一般にアンチパターンだが 特徴と制約を把握して上手く使えば結構便利 • 但しそれなりに面倒事は出てくる • 重要な部分のテストがあると変更時の安心感と品質が段違い • ローカルでやりづらいテストもDocker内ならへっちゃら ガンガンテストしよう

×