dockerでnvidia

今回、仕事でdockerでnvidia環境を使うのでメモ書きとして残しておきます。

NVIDIAというのはグラフィックドライバでバージョンによる依存関係がかなり高めです。

構成としては、ubuntu16.04(AWS EC2インスタンス、p2.xlarge)nvidia-396+cuda9.1+cuDNN7.1.3.16

とりあえず、nvidia-dockerでbuild、runするようなのでDockerfileを作る。

ベースにしたのはnvidia/cuda:9.1-runtime-ubuntu16.04 必要なライブラリ等をapt update && apt install

あとは、実機(EC2インスタンス)で作った手順をそのままDockerfileに書いていきます。 →失敗

実機で運用していたときはサービスとして運用していたためsystemctlが起動できないといけません。 そして、systemctl が動くようにするためには/sbin/initが起動してなければいけません。

dockerでは1つのコンテナに１つのAPIが基本になるのでサービスにしていくつも立ち上げるということはあまりしないのでinitは動いていません。 initを動かしたい場合は--privilegedオプションをつけて起動します。

しかし、これで動かした場合やたらとCPUを食います1コンテナ起動して40%くらい、2つ起動したらフリーズしました。

20以上のコンテナを同時に起動する必要がある要件なので、今回の運用に適していません。 次の方法は、サービス化せずに直接起動する方法です。 xxxx.serviceファイルに起動の仕方が書いているのでそのまま実行してみます。 →失敗

syslogに書き込めないというようなエラーだったため、syslogdが動いていないためかと思い、再度--privileged オプションをつけて/sbin/initを起動してみる

そうすると、うまく起動するようになる。 しかし、これでは最初の目的が果たせずに、複数コンテナの同時起動が困難。 どうにかして/sbin/initを動かさずに動作させたい。

logの送り先の設定が変えられないかと思い、サービスの置いてあるディレクトリでgrep -iR "log" を実行。 AWSへの認証関係の設定ファイルを発見してそれを使ってCLoudWatchに送っているようだ。 このIDに見覚えがあったのは去年AWSでCI/CD環境を作る案件をやっていたので、もしかして、AWSCLIがないからかと思い、 apt install awscli してから実行。

今度はうまく行ったようだった。

明日、ちゃんと設定を直して実際に動作するかを検証します。

RPAの仕事をしてみた

今年に入ってからRPAの仕事をしてきました。

4ヶ月間に渡ってしてみた感想ですが、正直なところ面白いことをするわけではないかと思います。

というのも、RPAの作業領域がシステム間で人がやらなければならない単純作業、データをダウンロードしてExcelにまとめたり、ダウンロードしたデータを別のシステムにコピペするなどが主な仕事になるからです。

ほとんどの作業がシステムからダウンロード、別システムへのコピペ、Excelへいい感じにまとめるということになりました。

これだけで見るとたしかにつまらないことばかりをやってる感じです。

ただ、その作業が発生する理由や背景を考えることができると話が違ってきます。

いろいろなシステムが乱立して、経理はAシステム、人事はBシステムなどに分かれてしまっていることが原因なので、それを統合することで解消させることも多くあります。

しかし、大手企業の場合、それらが別のベンダーで簡単に統合できないという足かせもありこのような作業が発生している現実もあります。

次のシステムを作る上でどうすれば余計な作業を埋めることができるか、人が出勤していなくてもできる作業でも営業日に動かさなければならない理由など、業務の裏側が見えるとそちらのほうが面白くなってきます。

その意味で有意義な4ヶ月でした。

あまり深く書くと守秘義務に引っかかりそうな内容があるので吟味して書いていきたいと思います。

ソフトウェアテスト・品質勉強会

【初心者向け】ソフトウェアテスト・品質勉強会 Ver3.4【いまさら聞けないテスト・品質の基礎】 - connpass

こちらに夫婦で参加してきました。

テストとは何か？品質とは何か？やところどころ空欄のある資料を考えて、時々隣の人と話し合いながら意見を交わし合うものでした。

普段、開発者目線でテスト項目や手順を考えていて、新鮮だったのが 開発者のテストは動くことを確認するテストで品質担当者のテストはどうやったら壊れるかを考える。

異常系のテストってどうやっておかしくするか、つまり壊すかということならばそこからの発送は理にかなってる気がします。

その他に、ドキュメントについて 何人かで見て、おかしなところに気づけばそこにバグはなくなるということ。

例題にあった パスワードを④文字以上、⑫文字以内の英数字で、③分以内に④回間違えたら⑤分ロックがかかる。

このようなドキュメントが会ったとした場合、レビューしたときに 英数字が大文字小文字の区別があるのか パスワードを入力する際にマスクはするのか パスワードを間違えたときにどのようなメッセージ、またはエラー画面に遷移するのか など、色々な疑問が出てくる これらが仕様として追加され、想定されたテストケースとして反映されるけど、ここにはバグは存在しなくなるはずです。

そして、テストケースは考えていけば無限に出てきます。 だから、必要なテストに絞り込むことが必要。 この絞り込みは、境界値、0やnull血などの特異点で絞り込めます。

他に、状態遷移図、状態遷移表の併用で漏れを防ぐなどが紹介されていました。

テストというのは決して単純な作業（スクショ貼り作業）ではなく設計と同等に大事で頭を使う仕事であるということを再認識させてくれる話でした。

クラウド化について思うこと

最近AWSへの移行という案件を診て思うことがいくつかあるので書きたいと思います。

よくある移行はオンプレからクラウドに移行したいというパターンが多いと思います。

そんなときに起こりがちなことをいくつかまとめてみたいと思います。

手作業でインスタンス構築

試しに作ってみるときなどは特に構わないと思いますが、構成を管理するにはCloudFormationなどで管理するほうが良いと思います。 yaml慣れしてない人などには最初とっつきにくいかもしれませんが、一度作ればほんの少し変えるだけでサーバーを変更できるのでものすごく楽になります。

マネージドサービスを使わない

オンプレの構成をそのまま活かしたいという意図で同じような構成を再現したいということでEC2インスタンスへ今まで作っていた構成（APサーバやDBサーバなど）をそのまま持っていきたいということでマネージドサービスを使わない選択をする場合があります。 DBサーバのバージョンを合わせたいなども1つの要因かと思います。

その結果 監視ログなどを自前で作り込む必要がある OSなどのパッチ当て作業が必要になる OSのアップデートのためにDB移行をする必要があるなど今までと同じ手間をかけることになります

しかし、今までよりもサーバーの変更やOSの入れ替えは早くなることにはなるのでそんな運用に満足してしまってるところも少なくないようです。

ただ、マネージドサービスを使ったときにどれだけ楽になるかは実際使わないとわかってもらえないので色々な成功例を調べて説得するしかなさそうです。

インスタンス内でDockerを使う

これについては微妙なところだと思います。

CloduFormationですべて管理できればDockerを使わなくても良さそうな気がします。

しかし、docker-composeやansibleなどを駆使して様々な設定をしているサーバー資産を簡単には手放せないとも思います。

まとめると、オンプレ運用とクラウドの運用は別物という考え方は必要なので、クラウドの特性をよく調べてから構成を考えようということでしょうか

パワポカラオケに行ってきた

今回は技術的なことというよりはプレゼンのこと。 それも、かなり遊びの要素が多いものでした。

パワポカラオケとは

ランダムで選ばれた人がランダムで選ばれたお題についてランダムに出てくる画像を見てプレゼンする大会です。 一人の持ち時間は3分で画像は5枚、次に何が出てくるかもわかりません。 あと、次に行くと前の画像にも戻れません。 更に、画像の切り替えは合図で変えてもらうのですが、酔ってるためフェザータッチで勝手に次の画面に行くこともありますｗ

そして、いきなりこんな画像が出てきたりします。

プレゼン画像の例

お題もそのときに決まるので頭をフル回転させて話をでっち上げる能力が求められます。

こういう大会も楽しくて良いです。

業界あるあるBarでisaaxについて話してきた

昨日ここで話してきました。

内容は、isaaxの紹介ということでどんなことができるのかを話してきましたが、今回は自分の好きな宇宙開発の話をもとに構成してみました。

isaaxはIoT機器に一斉にアプリをデプロイすることができ、登録している機器のオンライン・オフラインの状態を管理できるサービスです。

IoT機器と言っても色々あるので、今回は宇宙探査機の話で架空の話をしてきました。

その話を作るきっかけになったのは、今年11月15日、燃料切れのため動作不能となった宇宙望遠鏡ケプラーの話を入れてみたかったことでした。

この望遠鏡の名前の元になった天文学者ケプラーも388年前、ちょうどこの日に亡くなっています。

偶然にしてもできすぎる！

ということでこの話を入れたかったのですが、残念ながら燃料切れ（電池切れ）の機器の管理はできても修復まではできません。

でも、この機能を使えそうな内容をいろいろ考えてみると、複数で組み合わせて動く人工衛星（GPS衛星や中継衛星）があります。

あとは、何があるかというとこんな計画がありました。

簡単に言うと太陽系に一番近い恒星、アルファケンタウリの恒星系にある惑星プロキシマbへ向けて大量の宇宙ヨットを送る計画です。

簡単に書きましたが、距離は4光年、ここに到達するためには光の速度でも4年かかります。

探査機の速度もそれなりの速度がないと到達するまでにかなりの時間がかかります。

そのへんの技術はまたあとで。

ラズパイで監視カメラ

isaaxug.connpass.com

ここは今スタッフとして参加しています。

今回は人数も多く、ある程度ハンズオンに参加できる余裕があったのですが、ネットワークのトラブルで繋がらなかったりして断念。

これは、週末作るということにします。

今回書いてるものの元ネタはここからいただきました。

初心者回は毎回同じ内容でisaaxを体験してもらうことが目的ですが、今回は中級社会なのでその応用編として実際にテーマに沿って何かを作る回です。 テーマは与えられたものですが、それを持ち帰って応用して何かを作るのもOK、できた成果物をLTで語ることもできます。

楽しくやってるので遊びに来てくださいと宣伝も兼ねてます。