eyecatch
Thu, Sep 15, 2016

Pcap4J on Nano Server on Hyper-V Containers on Windows 10 on VMware Playerにトライ

Pcap4Jが動くHyper-VコンテナをWindows 10上でビルドしようとしたけど3合目あたりで息絶えた話。 Hyper-V Containersとは Hyper-V Containersは、MicrosoftによるWindowsネイティブなコンテナ技術であるWindows Containersの一種で、これによるコンテナは、同じくWindows Containersの一種であるWindows Server Containersのものに比べて、より厳密に隔離されている分、起動コストが高い。 実体はDockerそのもので、コンテナイメージはDocker Hubからpullできるし、コンテナの操作や管理はdockerコマンドでやる。(昔はコンテナ操作用PowerShellコマンドレットもあったが、不評だったので廃止したようだ。) ソースもLinuxとWindowsで一本化されている。 Windows 10のAnniversary Updateで正式にリリースされたが、なんだかあまり注目されていない気がする。 Docker for Windowsとは全く別物なので注意。 Hyper-V Containersのインストール (on VMware Player) 自前のPCが5年前に買ったdynabookでWindows 10をサポートしていないので、VMware PlayerのVM上のWindows 10にHyper-V Containersをインストールしてみる。 VMは、Windows 7に入れたVMware Workstation 11.1.0 build-2496824に付属の VMware Player 7.1.0 build-2496824で作ったもの。 VMのバージョンは11.0。 2CPUでメモリは2.5GB。 ネットワークインターフェースはNAT。 このVMを、Hyper-Vが使えるように設定しておく。 この記事にしたがい、Windows 10の評価版をダウンロード。 今公開されている評価版はAnniversary Update適用済みのバージョン1607で、Hyper-V Containersをサポートしている。 これをさっき作ったVMにインストール。 Windows 10を起動し、以下、Windows Containers on Windows 10に従って進める。 containers機能有効化 PowerShellプロンプトを管理者権限でひらき、以下のコマンドでcontainers機能を有効化。 PS C:\Windows\system32>Enable-WindowsOptionalFeature -Online -FeatureName containers -All 1分程度経つと再起動を促されるので再起動。 Hyper-V機能有効化 再度PowerShellプロンプトを管理者権限で開いて、以下のコマンドでHyper-Vを有効化。 PS C:\Windows\system32>Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All 1分程度経つと再起動を促されるので再起動。 OpLocks無効化 現在のHyper-Vコンテナは、安定性を上げるためにOpLocksという機能を無効にすべきらしい。 再度PowerShellプロンプトを管理者権限で開いて、以下のコマンドを実行する。 PS C:\Windows\system32>Set-ItemProperty -Path 'HKLM:SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers' -Name VSmbDisableOplocks -Type DWord -Value 1 -Force Dockerインストール 同じPowerShellプロンプトで以下のコマンドを実行してDocker(EngineとClient)のアーカイブをダウンロード。 PS C:\Windows\system32>Invoke-WebRequest "https://master.dockerproject.org/windows/amd64/docker-1.13.0-dev.zip" -OutFile "$env:TEMP\docker-1.13.0-dev.zip" -UseBasicParsing ダウンロードしたアーカイブを解凍。 PS C:\Windows\system32>Expand-Archive -Path "$env:TEMP\docker-1.13.0-dev.zip" -DestinationPath $env:ProgramFiles ここまででDockerがC:\Program Files\docker\に入るので、このパスを環境変数PATHに追加。 PATHの変更を反映させるために再度PowerShellプロンプトを管理者権限で開いて、以下のコマンドでDockerデーモンをサービスに登録。 PS C:\Windows\system32>dockerd --register-service Dockerサービスを起動。 PS C:\Windows\system32>Start-Service Docker (Dockerサービスは自動起動に設定されているので、OS再起動時は上記Start-Serviceは不要。) これでDockerが使えるようになった。 PS C:\Windows\system32>docker version Client: Version: 1.13.0-dev API version: 1.25 Go version: go1.7.1 Git commit: 130db0a Built: Sat Sep 10 13:25:48 2016 OS/Arch: windows/amd64 Server: Version: 1.13.0-dev API version: 1.25 Go version: go1.7.1 Git commit: 130db0a Built: Sat Sep 10 13:25:48 2016 OS/Arch: windows/amd64 コンテナイメージダウンロード どうもDockerコマンドの実行には管理者権限が必要なようなので、このまま管理者権限のPowerShellプロンプトで続ける。 docker pullでNano Serverのコンテナイメージをダウンロード。 PS C:\Windows\system32>docker pull microsoft/nanoserver docker imagesで確認。 PS C:\Windows\system32>docker images REPOSITORY TAG IMAGE ID CREATED SIZE microsoft/nanoserver latest 3a703c6e97a2 12 weeks ago 970 MB 試しにコンテナ起動。 PS C:\Windows\system32>docker run -it microsoft/nanoserver cmd 起動はかなり遅い。1分近くかかった。ともあれちゃんと起動した。 Pcap4Jコンテナのビルド Pcap4Jコンテナを、docker buildでビルドしてみる。 Dockerfileはとりあえず以前のものをちょっと書き変えただけのものを試す。 # escape=` # # Dockerfile for Pcap4J on Windows Nano Server # FROM microsoft/nanoserver MAINTAINER Kaito Yamada <[email protected]> # Install Chocolatey.
eyecatch
Mon, Sep 12, 2016

Hyper-Vコンテナ(Nano Server)でunzipしたいならjarを使え

Nano Serverでunzipしたかっただけだったのに、妙に苦労した話。 Nano Serverとは Nano Serverは、Windows Server 2016で追加されるWindows Serverの新たなインストール形式で、Server Coreよりさらに機能を絞り、リモートで管理するクラウドホストやWebサーバ向けにに特化したもの。 Server Coreが数GBくらいなのに対し、Nano Serverは数百MBととても軽量で、それゆえ起動が速くセキュア。 unzipとは unzipとは、zipファイルを解凍する、ただそれだけのこと。 ただそれだけのことで、基本的な機能だと思うのだが、Windowsはこれをコマンドラインで実行する方法をつい最近まで正式に提供していなかった。 Nano Serverでunzip Windows 10のHyper-V Containersの上でPcap4JのビルドとテストをするDockerイメージをビルドしたくて、そのための依存ライブラリなどをインストールする処理をDockerfileに書いていて、ADDでzipをダウンロードしたところまではいいんだけど、このzipどうやって解凍してやろうかとなった。 (Dockerホストに置いたものをコンテナにADDするのはなんか格好悪いから無しで。Dockerfile裸一貫で実現したい。) Windows 10のHyper-V Containersは、現時点でNano Serverしかサポートしていないのが厳しい点。Server Coreだったら楽だったのに。 以下、いろいろ試したことを書く。 正攻法: Expand-Archive PowerShellの v5 で実装されたExpand-Archiveというコマンドレットでzipを解凍できる。 Nano ServerのPowerShellのバージョンを確認したら 5.1 だったのでこれでいけるかと思った。 C:\>powershell -command "$PSVersionTable.PSVersion" Major Minor Build Revision ----- ----- ----- -------- 5 1 14284 1000 したらこのエラー。 Add-Type : Cannot find path 'C:\System.IO.Compression.FileSystem.dll' because it does not exist. At C:\windows\system32\windowspowershell\v1.0\Modules\Microsoft.PowerShell.Archive\Microsoft.PowerShell.Archive.psm1:914 char:5 + Add-Type -AssemblyName System.IO.Compression.FileSystem + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (C:\System.IO.Compression.FileSystem.dll:String) [Add-Type], ItemNotFoun dException + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.AddTypeCommand どうもPowerShellの 5.1 以降には、.NET FrameworkベースのDesktop Editionと、そこから機能を絞った.NET CoreベースのCore Editionがあり、Nano ServerのはCore Editionなんだそうな。 Expand-ArchiveはSystem.IO.Compression.FileSystem.dllの中のZipFileクラスに依存しているんだけど、.NET CoreにはSystem.IO.Compression.FileSystem.dllが含まれていないっぽい。 ShellオブジェクトのCopyHere PowerShellでのunzip方法を調べたらStack Overflowにいくつか載っていた。 Expand-Archiveと、System.IO.Compression.ZipFileを直接使う方法と、Shellオブジェクト(COMオブジェクト)のCopyHereメソッドを使う方法。 最初の2つはCore Editionでは使えないことが分かっているので、3つめにトライ。 こんなの↓ $shell = New-Object -ComObject shell.application $zip = $shell.NameSpace("C:\a.zip") MkDir("C:\a") foreach ($item in $zip.items()) { $shell.Namespace("C:\a").CopyHere($item) } 調べたらこの方法はMicrosoftから非推奨にされていることが分かったんだけど、一応やってみる。 したら以下のエラー。 new-object : Retrieving the COM class factory for component with CLSID {00000000-0000-0000-0000-000000000000} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
eyecatch
Sun, Aug 21, 2016

オープンソースプロジェクトのすゝめ

人は生まれながらにして貴賤の別なく、ただオープンソースプロジェクトを勤めて物事をよく知る者が貴人となるなり。 昔、偉い人がそんな感じのことを言っていたような。 私がGitHubで開発しているライブラリ、Pcap4J のスターの数がつい先日 200 に達したのを記念して、これまでどんな活動をしてきたか、この活動によって何を得たかなどについて書きたい。 願わくは、この記事に触発されてオープンソースプロジェクトを始める人のあらんことを。 Pcap4Jとは? Pcap4Jは、パケットキャプチャとパケット解析をするJavaのライブラリ。 ニッチ。 ただ最近になってビッグデータ解析技術が発達し、大量のパケットをリアルタイムで解析してシステムや運用にフィードバックするというのが現実的になってきたので、パケットキャプチャへの注目が高まってきている雰囲気がある。 こういう分野ではJavaがまだかなり人気なのもあってワンチャンある。 パケットキャプチャの部分は pcap のラッパ。 パケット解析の部分は割とプラガブルで、外からプロトコル追加などのカスタマイズができるはできるんだけど、作りのせいなのかJavaなせいなのか解析器を書くのが結構つらい。 競合は jpcap や jNetPcap など。 Google.comでjava packet captureと検索するとだいたいjpcap、Pcap4J、jNetPcapの順で表示される。 打倒jpcap。 数字で見るPcap4Jプロジェクト Pcap4Jリポジトリの一番古いコミットは 2011/12/18。 東日本大震災後の節電施策として実施された休日シフト中にコーディングしていた覚えがあるので、多分2011年夏くらいから開発していたんだけど、とりあえずこの最古のコミットをプロジェクトの開始とすると、スターが200になった 2016/8/11 まで 1698日 かかったことになる。 約 0.118個/日。遅い… コミット数は 559個。ほとんどが自前のコミット。 プロジェクト成長過程の動画を Gource というツールで生成してみたが、一人でかけずりまわっているのがよく分かる。 コミット頻度は約 0.33個/日 で、だいたい3日に1コミット。 思っていたより多いけど、胸張れるほどの頻度ではない。 リリースは 17個 で、約 0.30個/月。少ない… Issuesが 52個、Pull requestsが 16個。 自分ではIssuesもPull requestsもあまり作らないので、ほとんどが他人からのもの。 ちゃんとチケット駆動にしてトレーサビリティを確保しておくべきだったと後悔している。 けど面倒だし今更なので今後も適当にコミットしちゃう。 あとはWatchが 28人、Forkが 66個、コントリビュータが 7人。 スター200ってどうなの? jQueryやReactなんてスター40000超えてるし、JavaならSpring Frameworkも10000に達しようとしている。200なんて全然大したことなくない? と言う声が聞こえるようだが、そんな知らない人を探すのが難しいようなプロジェクトと比べてはいけない。 スター200以上のプロジェクトは割合でみるととても少ない。 現在GitHubがホストしてる全プロジェクトは 14,308,407 個。 Javaプロジェクトはその内二番目に大きい割合を占めていて 1,501,840
eyecatch
Thu, Aug 18, 2016

GitHub Pagesの新機能、ソース設定が地味にいい

今日、よりシンプルにGitHub Pagesを使えるようになったというアナウンスがあり、ソース設定という新機能が追加されていたので、さっそく試してみた話。 GitHub Pagesの新機能: ソース設定 GitHub PagesにはUser Pages、Organization Pages、Project Pagesの三種類があるが、ソース設定が使えるのはProject Pages、つまりGitHubリポジトリごとに使えてusername.github.io/projectnameのようなURLのやつだけ。 今まではProject Pagesで公開するサイトのソースはgh-pagesという名のブランチに置く必要があったが、ソース設定によりmasterブランチのルートに置いたりmasterブランチの/docsフォルダに置いたりもできるようになった。 ソース設定の使い道 Pcap4Jのホームページのソースをmasterブランチの/docsフォルダに置く設定にしたら捗った。 Pcap4JのホームページはHugoで作っていて、以前は、Hugoのソースをpcap4j-hpリポジトリのmasterブランチに置き、gh-pagesブランチを作ってそこにHugoのビルド成果物(=ホームページのソース)を入れていた。 ローカルPCでは、masterをcloneして、そこからgit worktreeでgh-pagesを別のフォルダにチェックアウトしておいてあり、Hugoのビルドオプションでgh-pagesのフォルダにビルド成果物を出力するようにしていた。 これだと、ホームページを修正したい場合、まずmasterでHugoソースを修正してgit add/commit/push、次いでビルドしてgh-pagesフォルダに移動してgit add/commit/push、というように、二度手間で面倒だった。 Hugoのビルド成果物をmasterブランチの/docsフォルダに置けるようにできれば、git add/commit/pushはビルド後にmasterに対して一回だけやれば済むようになる。 gh-pagesからmasterブランチの/docsフォルダへの移行 GitHubのヘルプを参考にしつつ、 ローカルPCで、masterの作業ディレクトリのルートにdocsというフォルダを作り、gh-pagesのフォルダの中身を全てそこに移動。 masterのdocsをgit add/commit/push。 GitHubのpcap4j-hpリポジトリのページに行き、SettingsタブのGitHub PagesセクションのSourceをgh-pages branchからmaster branch /docs folderに変えてSaveボタンをクリック。 実にこれだけ。 カスタムドメインにしていてもこれだけ。簡単。ダウンタイムもなし。 あとはローカルPCのgh-pagesの作業ディレクトリを削除したり、gh-pagesブランチを削除したり。