継続的なアップデートのための手法 - サイバートラ …Title...

Copyright Cybertrust Japan Co., Ltd. All rights reserved.公開

継続的なアップデートのための手法

2019/06/21サイバートラスト株式会社


● 継続的な開発を進めるための開発手法● 組込みLinuxにおけるテスト● テストツール● テストのサンプル

Agenda


● コーディング・ビルド・テストのサイクルを早く回す○ コードの変更に影響を素早くキャッチ

■ バグが見つかった場合に原因となった変更の早期発見可能● ある変更により入り込んだバグを時間が経ってからデバッグするのは大変

■ 常にビルド・テストが成功しているという安心感

● ビルド・テストは自動化○ ミス/ストレスなくサイクルを回す

■ 手作業が入るとミスもしやすい■ サイクルを回すのも面倒になってくる

● テストの質も下がり、ソフトウェアの品質も下がる

継続的な開発を進めるために


● ソフトウェアのビルド・テストを自動化● 継続的に行うことで問題点の早期発見・修正が可能● 実行するタイミングは任意

○ プルリクエストがマージされた時○ 毎日深夜2時○ slackやircなどからコマンドを送信

● 全テストの実行に時間がかかるとCIサイクルの完了待ち時間が問題となる○ テスト内容を使い分ける

■ 全テストの実行は夜間に行い、業務時間中はスモークテストを実施する等

● テストする内容は任意○ ユニットテスト○ インテグレーションテスト○ パフォーマンステスト

CI：Continuous Integration(継続的インテグレーション)


CI:CIシステム例


● 組込みLinux環境（ディストリビューション）の起動・動作確認○ アプリケーションが動作するための土台をテスト

● 組込みLinux環境で動作するアプリケーションの動作確認○ 製品に組み込む機能のテスト○ テストのために実デバイスが必要になることも

● 実デバイスでテストするためには○ デバイスにシリアルでアクセスできる○ ビルドしたカーネルやアプリケーションをテストデバイスに手動で書き込まずに利

用できる■ tftpブートや、rootファイルシステムをnfsでマウントする等

○ 電源のOn/Offを遠隔操作できる■ カーネルフリーズ時の強制resetなど■ 専用の機材が必要

CI:組込みLinuxではどのようなテストが必要か


● 様々な種類のテストを実行できる○ アプリケーションの機能テスト○ パフォーマンステスト○ ストレステスト

● 実デバイスでテストできる○ 実デバイスを使用したアプリケーションのテスト

■ デバイスドライバ＋ユーザーランドのアプリケーション

CI:組込みLinuxではどのようなテストシステムが必要か


● build test○ システム全体のソースコードをビルドできる

■ ビルドシステムにpokyを使用しているならビルドーターゲット（core-image-minimal等）のビルド■ ビルドに成功したら次のテストへ進む

● boot test○ シンプルかつ重要

■ デバイスの起動→ログイン→電源オフを行う

● アプリケーションのテストは対象デバイスが起動し、ログインしてから実施○ buildとbootができないとアプリケーションのテストを開始することができない

Test: 重要なテスト


● 基本的なところから初め、徐々にテスト内容を深める○ build test、boot test○ 実デバイスではなくqemuでテスト

● システムのビルドとqemuで正常に起動することを確認できるようになったら○ 新しいテストを追加○ 実デバイスでテスト○ など、次のステップに進むことができる

■ qemuで最低限の動作が確認できていれば、問題の切り分けに役立つこともある

Test:テストの実施戦略


● CIツール○ Jenkins○ LAVA○ kernelCI

● Testツール○ LTP○ ptest○ kselftest○ ktest

CI：組込みLinux向けツール


● コミュニティベースで開発されているCIツール○ https://jenkins.io/

● メジャーなソフトウェアで書籍・Webなどで情報が豊富● 主な特徴

○ プラグイン機構■ プラグインにより機能を拡張■ 豊富なプラグイン

○ 容易なインストール■ Linuxディストリビューションのパッケージでインストール、もしくはjarファイルをダウンロードして

インストール完了

○

CI:Jenkins

https://jenkins.io/


● Linaroが開発したCIシステム○ https://lavasoftware.org/○ LAVAでは実行するものをテストではなくJOBと呼ぶ

● Jenkins等のCIシステムと違い、テストの実行という面に注力している○ リポジトリの監視などは別のシステムを利用する形となる○ qemu、実デバイスを利用したテストの実行をサポート○ ソフトウェアのビルドは別システムで行う

● 主な特徴○ テスト対象デバイスの管理

■ qemu、実ハードウェア○ テストシナリオはYAML記述

■ ファイルはgitでチェックアウトすることも可能○ テストのためのヘルパースクリプト

■ lava-test-shellコマンドによるテスト実行のサポート○ テストの登録

■ WebUIもしくはAPIにて登録○ テスト結果の保存・Webでの閲覧

CI:LAVA

https://lavasoftware.org/


● コミュニティベースで開発されているテスト自動化ツール○ https://kernelci.org/○ Linuxカーネルのテストにフォーカスしている

● カーネルの開発で利用されている○ 様々なカーネルツリー・アーキテクチャ・configの組み合わせでビルド・起動テスト

を行っている● 単体でCIシステムを構築するのではなく、複数のツールを組み合わせている

○ Jenkins、LAVAをバックエンドに利用■ WebフロントエンドはKernelCI■ テストジョブ管理はJenkins■ テスト実行はLAVA

● 主な特徴○ 自動bisection

■ リグリッション検知時に自動的にbisectを行い、結果をレポートする● 実例：https://lkml.org/lkml/2019/4/5/901

CI:KernelCI

https://kernelci.org/


CI:lavaのテストシステム環境の概要（参考）

● 弊社でのCI環境概要KernelCIをビルドログ閲覧のフロントエンドとして使用buildbotがイベントをトリガーとしてビルドを実行LAVAがbuildbotで生成したイメージをテスト


● コミュニティベースで開発されているLinuxのテストツール○ http://linux-test-project.github.io/

● Linuxカーネルの機能をテスト○ スケジューラ、メモリ管理、IPC、ネットワークなど○ CVEに対するテストケースも存在

テストツール:LTP(Linux Test Project)

テストケースのディレクトリ構成

http://linux-test-project.github.io/


● yoctoプロジェクトが提供するテストのフレームワーク○ https://wiki.yoctoproject.org/wiki/Ptest○ ビルドシステムにyoctoを利用している場合に使用○ テストコードのビルド・イメージへのインストール・実行をサポート

■ アプリケーションに含まれるテストをパッケージ化● make test等で実行されるテスト

■ パッケージ名にはsuffixとして-ptestが付く

● ターゲットマシン上でテストコードを実行できる● 既存パッケージのテスト粒度はパッケージ毎に違う● テストを行う場合はビルドするイメージにパッケージ化したテストをインストールする

○ コンフィギュレーションファイルに以下の記述を追加しイメージをビルド■ DISTRO_FEATURES_append = " ptest"■ パッケージ単位にインストールすることも可

●

テストツール:ptest

https://wiki.yoctoproject.org/wiki/Ptest


● Linuxカーネルに含まれているテスト実行ツール○ https://elinux.org/Ktest○ Linux 2.6.38にて登場○ 実デバイス・エミュレータでの実行をサポート

■ ターゲットとのシリアル接続は必須

● 主な特徴○ 3種類のテスト実行をサポート

■ build test■ boot test■ ユーザーが指定したテストの実行

● ltpを実行するなど

○ git bisectサポート○ grubメニューより指定したカーネルを起動○ 一連のパッチを一つずつ適用しビルド・テストするPatch check機能

テストツール:ktest

https://elinux.org/Ktest


● Linuxカーネルに含まれているテストフレームワーク○ https://www.kernel.org/doc/html/v5.1/dev-tools/kselftest.html○ Linux 3.17にて登場○ カーネルの機能をテスト

■ カーネルの機能毎にディレクトリ構成が分かれている

○ Makefileを利用したテストコードのビルド・実行サポート■ テストの実行にはMakefileを使用する

● テストプログラム単体での実行も可■ テストコードはC/Shell/Pythonなど任意の言語を利用可能

● カーネルとセットになっているため、カーネルの更新に追従しやすい● テストの実行をサポートする

○ どのようなテストを行うかは開発者次第

テストツール:kselftest

https://www.kernel.org/doc/html/v5.1/dev-tools/kselftest.html


boot testを例に説明します

LAVAテストシナリオの書き方


● actions○ deploy

■ カーネルやrootfsなどの取得先を指定● URL、ディレクトリパス等

○ boot■ ログイン時のアカウント情報（ユーザID・パスワード）の設定■ 期待するログインプロンプトの指定

● 設定したアカウント情報と組み合わせて自動ログインを行う

○ test■ 実行するテストの内容を記述

● テスト内容は別のyamlファイルを読み込む、もしくは

● context○ デバイスの設定を行う

■ qemuの例● メモリー容量、cpuなどqemuに渡すパラメータを設定

lavaテストシナリオ主要項目


boot test(qemu) yamlファイル全体像

# simple boot test QEMU arm64device_type: qemujob_name: QEMU aarch64 , boot test

# test settingtimeouts: job: minutes: 15 action: minutes: 10 connection: minutes: 10priority: mediumvisibility: public

# qemu settingcontext: arch: aarch64 memory: 512 machine: virt cpu: cortex-a57 guestfs_interface: virtio

# kernel, rootfs settingactions:- deploy: timeout: minutes: 3 to: tmpfs os: oe images: kernel: image_arg: '-kernel {kernel} -append "console=ttyAMA0,115200 root=/dev/vda rw highres=off debug verbose"' url: http://10.2.6.95:12080/Image--5.0.7+git0+d26eec23cf_891531d68e-r0-qemuarm64-20190604011738.bin rootfs: image_arg: '-drive id=disk0,file={rootfs},if=none,format=raw -device virtio-blk-device,drive=disk0' url: http://10.2.6.95:12080/core-image-minimal-qemuarm64-20190604011738.rootfs.ext4

# boot test- boot: timeout: minutes: 2 method: qemu media: tmpfs auto_login: login_prompt: "qemuarm64 login:" username: root prompts: - "root@qemuarm64:~# "


device_type: qemu

job_name: QEMU aarch64 , boot test

timeouts:

job:

minutes: 15

action:

minutes: 10

connection:

minutes: 10

priority: medium

visibility: public

テストの全般的な項目設定

context:

arch: aarch64

memory: 512

machine: virt

cpu: cortex-a57

guestfs_interface: virtio

テストの実行、ネットワーク接続などのタイムアウト設定

デバイスの指定

テストジョブ名 qemuのアーキテクチャ等


- deploy:

timeout:

minutes: 3

to: tmpfs

os: oe

images:

kernel:

image_arg: '-kernel {kernel} -append "console=ttyAMA0,115200 root=/dev/vda rw highres=off debug verbose"'

url: http://<server>:<port>/path/to/kernel image

rootfs:

image_arg: '-drive id=disk0,file={rootfs},if=none,format=raw -device virtio-blk-device,drive=disk0'

url: http://<server>:<port>/path/to/root fs

テスト対象の設定

image_argsはqemuのオプションをセット

カーネルの取得先を指定

{kernel}にはurlよりダウンロードしたカーネルのパスが自動で入る


boot:

timeout:

minutes: 2

method: qemu

media: tmpfs

auto_login:

login_prompt: "qemuarm64 login:"

username: root

prompts:

- "root@qemuarm64:~# "

boot項目の設定

このログインプロンプトが表示されることを期待する

ログインプロンプトが表示されたら、 usernameで指定した文字列を入力する

ログインに成功後に表示されるプロンプト

* 本サンプルではパスワードなしでログインしています。

パスワードログインを行う場合は、password_promptとpasswrdを設定します。


boot test実行ログ画面

表示内容はdebug/info/errorなど意味によって色が変わります

以下の処理が行われています● 指定されたログインプロンプトの出力待ち● ログインプロンプト発見● 指定されたユーザー名を入力● 指定されたプロンプトを発見● テスト結果の出力


● CIを適用し、開発サイクルを回す○ 常にテストできる・されていることにより、コード変更も安心して行える

● CIは簡単なところから始める○ 簡単でもCIを行うことの効果は高い

■ Build test・Boot test

まとめ


信頼とともに

留意事項

本資料に記載されている会社名、製品名、サービス名は、当社または各社、各団体の商標もしくは登録商標です。その他本資料に記載されているイラスト・ロゴ・写真・動画・ソフトウェア等は、当社または第三者が有する知的財産権やその他の権利により守られております。お客様は、当社が著作権を有するコンテンツについて、特に定めた場合を除き、複製、改変、頒布などをすることはできません。本資料に記載されている情報は予告なしに変更されることがあります。また、時間の経過などにより記載内容が不正確となる場合がありますが、当社は、当該情報を更新する義務を負うものではありません。

継続的なアップデートのための手法 - サイバートラ …Title...

Documents

Transcript of 継続的なアップデートのための手法 - サイバートラ …Title...