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

1. Dockerでローカルテストを
良い感じに実装した話
（株）エーピーコミュニケーションズ
山岡 亮

2. 自己紹介
• 日常の仕事
• NEEDLEWORK（自社製FWテストツール）
のバックエンド
• Webアプリのバックエンド
• 普段使い: Go, GCP, CircleCI, Docker
• 趣味: 料理、ゲーム、コーディング、インフラいじり
• 大学生（計算機科学）の片手間に会社員やってます
Twitter: @mountainhill14
Blog: https://dokupe.hatenablog.com/
GitHub: https://github.com/ryo-yamaoka

3. 今日話すこと
• 少しだけ自社アプライアンスの紹介
• 本題の前提知識として軽く（営業目的ではありません）
• Dockerを使って手元のテストを良い具合に実装した事例
• ↑の実装で困ったこととその解決方法

4. NEEDLEWORKの紹介
https://www.ap-com.co.jp/ja/needlework/

5. 開発で考慮しなければならない特性
• アプライアンスであること
• オフラインでの利用が前提
• ファームウェアのアップデート等もユーザー自身で作業する

6. 開発における課題

7. 開発における課題
ファームウェアアップデーターのテストが辛い

8. どう辛いか

9. どう辛いか
• アプライアンスのOS上でファイルやサービスの操作がある
• ローカルで動作テストをすると開発環境に影響が出る
• オフライン＆ユーザー作業が前提なのでファーム更新は可能な
限りトラブルを少なくしたい

10. どう辛いか
• アプライアンスのOS上でファイルやサービスの操作がある
• ローカルで動作テストをすると開発環境に影響が出る
• オフライン＆ユーザー作業が前提なのでファーム更新は可能な
限りトラブルを少なくしたい
• 実機でしか動作確認できないのは不便
• 勿論最終的には実機確認もやらなければならないが、
開発環境でできないのはしんどい
• VMとスナップショットでもできるがもっと手軽にやりたい

11. 解決方法

12. 解決方法
• Dockerを使い試験環境を使い捨てる

13. 解決方法
• Dockerを使い試験環境を使い捨てる
• コンテナ内部で実際のファイル操作を行えるので限りなく
実環境に近いテストを行える
• 各種OSの公式コンテナがある

14. 実際の動作

15. 実際の動作
• make test で実行開始

16. 実際の動作
• make test で実行開始
• 試験に必要な各種ファイルを生成する
（ダミーのDaemonとかアップデートファイル等）

17. 実際の動作
• make test で実行開始
• 試験に必要な各種ファイルを生成する
（ダミーのDaemonとかアップデートファイル等）
• テスト用のネットワークを作成しコンテナを起動、
生成したファイルを配置する
• アプライアンスの仕様で 192.0.2.0/24 を使う必要がある

18. 実際の動作
• make test で実行開始
• 試験に必要な各種ファイルを生成する
（ダミーのDaemonとかアップデートファイル等）
• テスト用のネットワークを作成しコンテナを起動、
生成したファイルを配置する
• アプライアンスの仕様で 192.0.2.0/24 を使う必要がある
• Goのテストで実際にAPIを操作してアップデートや
ダウングレードを実行する

19. 良かったこと

20. 良かったこと
• 手元で気軽に何度でもテストを流せるようになった
• 安心感すごい

21. 良かったこと
• 手元で気軽に何度でもテストを流せるようになった
• 安心感すごい
• 品質が向上した
• コード変更の影響がすぐわかる
• テスト実装中にいくつか未発見だったバグを潰せた

22. 良かったこと
• 手元で気軽に何度でもテストを流せるようになった
• 安心感すごい
• 品質が向上した
• コード変更の影響がすぐわかる
• テスト実装中にいくつか未発見だったバグを潰せた
• CIに乗せられるようになった（はず）
• 試していないがDockerで動くのでCircleCIとかに持っていけるはず
（現状はCIに乗せる要件はない（実質1人開発）のでやってない）

23. ハマったところ

24. ハマったところ
• Dockerの本来の用途から外れているので色々辛い
• systemdを使う前提になっていない
• コンテナ内部で複数プロセスを立てるのが面倒

25. ハマったところ
• Dockerの本来の用途から外れているので色々辛い
• systemdを使う前提になっていない
• コンテナ内部で複数プロセスを立てるのが面倒
• Dockerfileのビルド時になぜかyumコマンドがコケる

26. Docker(CentOS)でsystemdを使うには

27. Docker(CentOS)でsystemdを使うには
• 普通にsystemdを叩くと Failed to get D-Bus connection: No
connection to service manager. になる

28. Docker(CentOS)でsystemdを使うには
• 普通にsystemdを叩くと Failed to get D-Bus connection: No
connection to service manager. になる
• DockerfileのCMDを/sbin/initにする

29. Docker(CentOS)でsystemdを使うには
• 普通にsystemdを叩くと Failed to get D-Bus connection: No
connection to service manager. になる
• DockerfileのCMDを/sbin/initにする
• コンテナ起動時に --privileged を付ける
• サービスなら避けるべきだが今回は使い捨て環境なのでリスクは無い

30. 複数プロセス立て＋オペレーションする

31. 複数プロセス立て＋オペレーションする
• Dockerfileのハックとかsystemdでどうにかする事は諦めて
愚直にコマンド羅列

32. 複数プロセス立て＋オペレーションする
• Dockerfileのハックとかsystemdでどうにかする事は諦めて
愚直にコマンド羅列
• テストシナリオに docker exec (中略) systemctl start xxx
みたいなのをたくさん書く

33. Dockerfileのビルド時にyumがコケる

34. Dockerfileのビルド時にyumがコケる
• overlayfs絡みの問題で Rpmdb checksum is invalid:
dCDPT(pkg checksums) が出た

35. Dockerfileのビルド時にyumがコケる
• overlayfs絡みの問題で Rpmdb checksum is invalid:
dCDPT(pkg checksums) が出た
• yum-plugin-ovl を入れて解決

36. おわりに

37. まとめ
• コンテナをVMのように扱うのは一般にアンチパターンだが
特徴と制約を把握して上手く使えば結構便利
• 但しそれなりに面倒事は出てくる
• 重要な部分のテストがあると変更時の安心感と品質が段違い
• ローカルでやりづらいテストもDocker内ならへっちゃら
ガンガンテストしよう