2018年4月25日水曜日

DockerToolbox + Windows 10 (VirtualBox) で Windows シャットダウンがブロックされるのを防ぐ

Windows 10 + Docker Toobox (VirtualBox) 環境を構築。
スタートアップからホスト起動するようにして、個人的に使ってるサービスを立ててるのですが、シャットダウンするときに VirtualBox Interface が "Has active connections." となって終了を阻害してたので、それを解決したときのメモ。

VBoxHeadlessTray をインストールして常駐させておく
参考:
Windows 7 終了時にdockerを自動終了させる。 - イノベートな非日常
VBoxHeadlessTray - Topten Software

2つ目のリンクから VBoxHeadlessTray をダウンロードして、インストール。
VBoxHeadlessTray が常駐するようになります。
これだけで解決!
簡単でした。
(インストール直後はダメでしたが、再起動後からは終了が阻害されることがなくなった)

また、VBoxHeadlessTray により起動時に VM が PowerUp されるようになったので、スタートアップで Docker を起動する必要もなくなりました。
Windows Update とかもあって、この辺あやふやです。すみません。
Tray が自動で PowerUp してくれてる感じがありますが、それだけだとシャットダウンがブロックされました。(VM が headless で起動してない?)
Docker Toolbox の Quick Start をスタートアップに入れてるとエラーが出るのですが、Tray からの起動で正常に立ち上がるっぽい。(タイミングが衝突?)
スタートアップ直後じゃなくて、数秒待ってみると大丈夫そうだったので、しばらくこれで・・・

他にやったこと
常駐させておくよりも設定でなんとかできたらと思っていたので、こちらを先に試していました。
VirtualBoxでホストのシャットダウンにゲストのバーチャルマシンも連動させる パソコン鳥のブログ/ウェブリブログ

VBoxManage で設定をしてあげれば良さそうだったので、マニュアル見ながら試してみたものの結果としてはうまくいきませんでした。
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" setextradata default GUI/DefaultCloseAction savestate
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" setextradata global GUI/DefaultCloseAction savestate
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" setextradata default VBoxInternal2/Watchdog/APIMonitor/IsolationResponse shutdown

サービス化する
これを書いてて思ったのだが、サービス化するってのはどうだろうか?
VirtualBox をサービス化する情報はすぐに見つかったので、今度試してみたいと思います。


あとがき
この記事を書いて少し寝かせていたのですが、その間にたまーに Docker Host の起動状態がおかしくなって、Virtual Box Manager からシャットダウンして起動し直すということがありました。また、たまにシャットダウンがブロックされる症状が出ていたので、根本的な解決とはなってない感じ。。。
(この記事が公開されているということは、ネタ不足になったということだ。)


2018年4月17日火曜日

[MSVC] pragma warning での警告抑止はどこにでも書けばいいというものではなかった [2013]

Visual Studio 2013 なんてもう誰も使ってない気がしますが
Visual Studio 2013 で pragma warning による警告抑止が効かないケースがあったので、メモです。

気づいたのは、iutest で MSVC の警告撲滅をしていたのがきっかけです。

問題のコードはこちら
https://github.com/srz-zumix/iutest/blob/6a2a798458aa220f2d1a88b8a79be39a867e8709/include/internal/iutest_port.hpp#L283

template
class IUStreamBuffer
{
public:
    // __pragma(warning (push))
    // __pragma(warning (disable: 4996))
    IUTEST_PRAGMA_CRT_SECURE_WARN_DISABLE_BEGIN()

    explicit IUStreamBuffer(FILE* fp)
        : m_fp(fp)
    {
        m_buf[0] = '\0';
        fflush(fp);
        setvbuf(fp, m_buf, _IOFBF, SIZE);
    }

    ~IUStreamBuffer()
    {
        fflush(m_fp);
        setbuf(m_fp, NULL);
    }

    // __pragma(warning (pop))
    IUTEST_PRAGMA_CRT_SECURE_WARN_DISABLE_END()
setbuf が C4996 出るので pragma warning push/disble/pop をつけていました。
VS2017 や VS2015 では上記の書き方で問題がなかったのですが、Visual Studio 2013 では正しく警告抑止ができてませんでした。



template
class IUStreamBuffer
{
public:
    explicit IUStreamBuffer(FILE* fp)
        : m_fp(fp)
    {
        m_buf[0] = '\0';
        fflush(fp);
        setvbuf(fp, m_buf, _IOFBF, SIZE);
    }

    ~IUStreamBuffer()
    {
    // __pragma(warning (push))
    // __pragma(warning (disable: 4996))
    IUTEST_PRAGMA_CRT_SECURE_WARN_DISABLE_BEGIN()
        fflush(m_fp);
        setbuf(m_fp, NULL);
    // __pragma(warning (pop))
    IUTEST_PRAGMA_CRT_SECURE_WARN_DISABLE_END()
    }


こうだとちゃんと警告が抑止されたので、どうやら書く場所が悪かったみたいです。
(今は setvbuf 使うようにして抑止しなくていいようにしたので、上記コードはなくなりました)


まとめ
最新のコンパイラーなら大丈夫なのかもしれませんが、pragmra warning はどこにでも書けるという認識が間違っていた、というのは良い収穫でした。
極力、警告抑止はない方がいいですが、使う場合はなるべく小さなスコープで書くようにしたいと思います。


今回は以上です。では。

2018年4月10日火曜日

[CI] Cirrus CI はじめました



新しい CI サービスを見つけたので、早速使ってみました。
今回使ったのは Cirrus CI です。
Cirrus CI の特徴は Github App であること、そしてシンプルかつ Windows にも対応しています(OS X も今後対応するようです)
また、気になる Pricing も OSS であれば無料です。


はじめる
Cirrus CI は他の CI サービスと異なり Github App で提供されているため Github 専用です。
使う場合も、Marketplace からインストールして開始します。
https://github.com/apps/cirrus-ci

Marketplace にアクセスしたら、「Install」ボタンを押します。


権限の確認画面が出ますので、自分のリポジトリ全部に権限を与えるか、一部のリポジトリのみに与えるか選択します。使い方にあったほうを選択したら、「Install」ボタンを押してください。


インストールはこれだけです。
完了すると「Quick Start」のページにジャンプします。
(ドキュメントは他のサービスと比べると少ない印象がありますが、シンプルな作りだったので十分でしたし、yml フォーマットも理解しやすかったです)


タスクを作成
Cirrus CI も多くの CI サービスと同様に yml ファイルをリポジトリに配置して、その記述に沿って CI が実行されます。
yml のフォーマットは公式ドキュメントに説明があります。

iutest では以下のようなタスクを作成しました。(コメント足してます)


フォーマットはシンプルで、基本的には task と script を作成する感じです。
もちろん、マトリックスや、タスクの依存関係などを組みこともでき、メインの CI サービスとして使っていける機能が揃っています。

.cirrus.yml を push する
作成した .cirrus.yml を push するとタスクが実行されます。
タスクの状態は Github の Commit Status に表示されます。



Details から詳細ページにジャンプできます。
そちらでビルドログが確認できますので、失敗した場合はそちらを確認する感じ。




バッジを付ける
最後に、CI サービスお約束のバッジを付けていきます。
バッジの付け方は以下のページに説明があります。
https://cirrus-ci.org/guide/writing-tasks/#embedded-badges


iutest の場合は
|[![Cirrus Build Status](https://api.cirrus-ci.com/github/srz-zumix/iutest.svg?branch=master)](https://cirrus-ci.com/github/srz-zumix/iutest/master)
のようになります。



最後に
たまたま Cirrus CI のことを発見して使ってみましたが、躓くところもなくすんなりと導入ができました。
今まで多くの CI サービスを使ってきたこともあってか、yml ファイルの記述が理解しやすかったように感じました。

また、今回は使用しませんでしたが Windows のワーカーも使えるとのことですし、OS X も今後対応予定なので複数 OS のテストが1つのサービスでできるようになる日も近そうです。
Travis CI や Circle CI で Linux/OS X、AppVeyor で WIndows の CI を回している方は、お引越しを検討してみてはいかがでしょうか。

今回は以上です。では。