Translate

2018年2月6日火曜日

TensorFlow 1.6.0-rc0 の案内がタイムラインに..

つい先日 1.5.0のコンテナに差し替えたばかりだというのに
今日ふとタイムラインをのぞくと..


えーっ、もう1.6.0-rc0かよ...

とりあえずリリースノートを確認してみた。
以下、勝手翻訳なので参照される方は at your own riskでお願いします。

-------

TensorFlow 1.6.0-rc0

Assets




リリース1.6.0

Breaking Changes

予めビルドされたバイナリは、CUDA 9.0およびcuDNN 7に対して構築されています。 
事前ビルドされたバイナリはAVX命令を使用します。古いCPUでTFが破損する可能性があります。


主な機能と改善点

  • tf.estimator.{FinalExporter,LatestExporter}今すぐ削除されたSavedModelsをエクスポートします。これにより、SavedModelの前方互換性が向上します。 
  • XLA CPU / GPUにFFTサポートが追加されました。

バグ修正やその他の変更


  • ドキュメントの更新:
    • ML入門者を対象としたGetting Startedの第2版が追加されました
    • resize_images.align_cornersパラメータに関する明確な文書
    • TPUの追加ドキュメント。
  • Google Cloud Storage(GCS):
    • クライアント側のスロットルを追加します。
    • FileSystemインターフェイスにFlushCaches()メソッドが追加、これはGcsFileSystemに実装されています
  • その他:
    • 非スロット変数用の新しいオプティマイザ内部API。_beta [12] _powerにアクセスするAdamOptimizerの派生は更新する必要があります。
    • tf.contrib.distributions.Kumaraswamyを追加。
    • RetryingFileSystem::FlushCaches()はベースFileSystemのFlushCaches()を呼びます
    • ディストリビューションにauto_correlationを追加します。
    • tf.contrib.distributions.Autoregressiveを追加。
    • SeparableConv1D レイヤを追加。
    • 畳み込み Flipout レイヤを追加。
    • tf.matmulの両方の入力が bfloat16 の場合、float32の代わりにbfloat16を返却。
    • tf.contrib.image.connected_componentsを追加。
    • tf.contrib.framework.CriticalSectionを追加し原子変数アクセスを可能に
    • 分類タスクのためのツリー予測に対する出力分散。
    • ptコマンドおよびevalコマンドのために、テンソル値をファイルシステムにnumpyファイルとして書き込むことが可能に。
    • gRPC:(gRPCの内部エラーを返す代わりに)切り捨てエラーを伝播。
    • 2種類のプリフェッチをサポートするためにparallel_interleaveを拡張。
    • C64関連のログ、pow、atan2、tanhに対するXLAサポートの改善。
    • 確率論的畳み込み層を追加する。

APIの変更

  • 下位互換性のため、デフォルト設定をFalseにしたprepare_varianceブール値を導入。
  • layers_dense_variational_impl.pylayers_dense_variational.pyへ移動。

既知のバグ

  • XLAを使用すると:CUDA 9およびCUDA 9.1でGPUを実行すると、ゴミの結果CUDA_ILLEGAL_ADDRESS失敗が発生
Googleは、2017年12月中旬に、CUDA 9 とCUDA 9.1 のPTX-SASSコンパイラが、大規模なオフセット(たとえばload [x + large_constant] )のある64ビットアドレス計算をSASSの32ビット算術に分解するときにキャリービットを正しく計算しないことがあることを発見しました。

その結果、これらのバージョンでは 、4GB以上の一時メモリ ptxas を使用するほとんどのXLAプログラムが誤ってコンパイルされます。その結果、ゴミの結果や CUDA_ERROR_ILLEGAL_ADDRESS 失敗が発生します。

CUDA 9.1.121の修正は2018年2月下旬に予定されています。CUDA 9.0.xの修正は予定されていません。修正が利用可能になるまで、唯一の回避策はCUDA 8.0.x にダウングレードするか、XLA:GPUを無効にすることです。

TensorFlowは、XLA:GPUとCUDAの間違ったバージョンを使用している場合は警告を表示します。e00ba24を参照してください。
謝辞
このリリースにはGoogle社の方々同様以下の方々の貢献が含まれています。

4d55397500, Ag Ramesh, Aiden Scandella, Akimasa Kimura, Alex Rothberg, Allen Goodman,
amilioto, Andrei Costinescu, Andrei Nigmatulin, Anjum Sayed, Anthony Platanios,
Anush Elangovan, Armando Fandango, Ashish Kumar Ram, Ashwini Shukla, Ben, Bhavani Subramanian,
Brett Koonce, Carl Thomé, cclauss, Cesc, Changming Sun, Christoph Boeddeker, Clayne Robison,
Clemens Schulz, Clint (Woonhyuk Baek), codrut3, Cole Gerdemann, Colin Raffel, Daniel Trebbien,
Daniel Ylitalo, Daniel Zhang, Daniyar, Darjan Salaj, Dave Maclachlan, David Norman, Dong--Jian,
dongsamb, dssgsra, Edward H, eladweiss, elilienstein, Eric Lilienstein, error.d, Eunji Jeong, fanlu,
Florian Courtial, fo40225, Fred, Gregg Helt, Guozhong Zhuang, Hanchen Li, hsm207, hyunyoung2,
ImSheridan, Ishant Mrinal Haloi, Jacky Ko, Jay Young, Jean Flaherty, Jerome, JerrikEph, Jesse
Kinkead, jfaath, Jian Lin, jinghuangintel, Jiongyan Zhang, Joel Hestness, Joel Shor, Johnny Chan,
Julian Niedermeier, Julian Wolff, JxKing, K-W-W, Karl Lessard, Kasper Marstal, Keiji Ariyama,
Koan-Sin Tan, Loki Der Quaeler, Loo Rong Jie, Luke Schaefer, Lynn Jackson, ManHyuk, Matt Basta,
Matt Smith, Matthew Schulkind, Michael, michaelkhan3, Miguel Piedrafita, Mikalai Drabovich,
Mike Knapp, mjwen, mktozk, Mohamed Aly, Mohammad Ashraf Bhuiyan, Myungjoo Ham, Naman Bhalla,
Namrata-Ibm, Nathan Luehr, nathansilberman, Netzeband, Niranjan Hasabnis, Omar Aflak, Ozge
Yalcinkaya, Parth P Panchal, patrickzzy, Patryk Chrabaszcz, Paul Van Eck, Paweł Kapica, Peng Yu,
Philip Yang, Pierre Blondeau, Po-Hsien Chu, powderluv, Puyu Wang, Rajendra Arora, Rasmus, Renat
Idrisov, resec, Robin Richtsfeld, Ronald Eddy Jr, Sahil Singh, Sam Matzek, Sami Kama, sandipmgiri,
Santiago Castro, Sayed Hadi Hashemi, Scott Tseng, Sergii Khomenko, Shahid, Shengpeng Liu, Shreyash
Sharma, Shrinidhi Kl, Simone Cirillo, simsicon, Stanislav Levental, starsblinking, Stephen Lumenta,
Steven Hickson, Su Tang, Taehoon Lee, Takuya Wakisaka, Ted Chang, Ted Ying, Tijmen Verhulsdonck,
Timofey Kondrashov, vade, vaibhav, Valentin Khrulkov, vchigrin, Victor Costan, Viraj Navkal,
Vivek Rane, wagonhelm, Yan Facai (颜发才), Yanbo Liang, Yaroslav Bulatov, yegord, Yong Tang,
Yoni Tsafir, yordun, Yuan (Terry) Tang, Yuxin Wu, zhengdi, Zhengsheng Wei, 田传武

--------
いろいろ改変はあるが、これはいつもどおりなので
おそらく今回のヤマは既知バグの話だろう。

CUDA9.1系を使っているなら最新版でバグが治りそうだが、
CUDA9.0系の人はダウングレードしか今のところ回避法がないというところは
記憶しておこう。

初心者にとってはTensorFlow本家サイトのチュートリアルを始めとした
ドキュメントが改変になっているところが大きい。

正直初期のドキュメントは本気で機械学習を始めている研究者向けだった。
数式も多かったし..
 #パラ味しかしてないけど、数式は減った気がする..

おそらく正式版の1.6.0は上記よりもっといろいろ盛り込まれることだと思う
実際1.5.0rc0から1.5.0正式版でもだいぶ変更がはいっていたし。





 



p.s.

まあ、なんにせよ動かしてみようかな..と
これまで動かしていたGPU版 Tensorflow1.5.0(python3)の公式Dockerコンテナ を潰し
tensorflow/tensorflow:1.6.0-rc0-gpu-py3 イメージを立ち上げて
tensorflow をインポートしようとしたら..



..うごかん..

CPU版もだめ...


...
しばらく静観しよっと...

2018年1月26日金曜日

Ubuntu Server 16.04 LTS の時刻同期が狂う件

使っていなかったデスクトップマシンのBIOSをリセットして
Ubuntu Server 16.04 LTSを入れて使おうとしたのだけど..

apt-get update でちょこちょこ「無視」の文字が出たり
CAがどうのこうのといって接続を拒否られ「エラー」になったり..


おかしいなあ..といろいろ調べてみたら..

あれ..日付が2012年になってる..

BIOS再設定の際にボタン電池を一旦はずしたのがまずかったか..

ntpdateしてもリブートしたらまた変な時刻に戻ってしまう..

うーん、Ubuntu Server 16.04 LTSでNTPクライアント化するには..

と調べてみると、どうもsystemdでやるらしい..

sudo vi /etc/systemd/timesyncd.conf して、
#NTP=」のコメントをはずして、
半角空白をあけて複数のNTPサーバのFQDNを書いて
リブートしてみたら..

..うまくいった..

なんか、やりかた忘れそうなのでブログにのこしとこ..

2018年1月4日木曜日

TensorFlow 1.5.0 rc0がリリースされた

1月4日仕事始めの日に出社して、
同僚に新年の挨拶を済ませふと席に戻ると、


というツィートがタイムラインに入ってきた..


..新年早々マイナーバージョンアップかよ..1.4.1でたばっかじゃん...

Docker Hubにも 1.5.0-rc のイメージが既に投稿されているし..

..ということでリリース記事を翻訳してみた。
#参照される方はat your own riskでお願いします。
------

TensorFlow 1.5.0-rc0



アセット




リリース1.5.0


Breaking Changes

  • 予めビルドされたバイナリは、CUDA 9 とcuDNN 7 に対して構築されています。
  • 私たちのLinuxバイナリは、ubuntu 16コンテナを使用してビルドされており、ubuntu 14ではglibcの非互換性の問題が発生する可能性があります。
  • 1.6リリースからは、あらかじめビルドされたバイナリはAVX命令を使用します。
  • 古いCPUでTFが破損する可能性があります。

主な機能と改善点

  プレビュー版が利用可能になりました。
  • TensorFlow Lite
  デベロッパープレビューが利用可能になりました。
  • CUDA 9 および cuDNN 7 のサポート


バグフィックス、その他の変更

  • auto_correlationtf.contrib.distributions に追加。
  • DenseFlipout 確率的層を追加。
  • DenseVariational 他の確率的層のためのより単純なテンプレートとして再標準化。
  • tf.contrib.distributions QuadratureCompoundクラスはバッチをサポート。
  • Stream::BlockHostUntilDone boolではなくStatusを返却。
  • GCSファイルシステムの要求タイムアウトをカスタマイズ。


貢献への謝辞


このリリースには、Google社の多くの人々からの貢献によるものです:
4d55397500, Abdullah Alrasheed, abenmao, Adam Salvail, Aditya Dhulipala, Ag Ramesh,
Akimasa Kimura, Alan Du, Alan Yee, Alexander, Amit Kushwaha, Amy, Andrei Costinescu,
Andrei Nigmatulin, Andrew Erlichson, Andrew Myers, Andrew Stepanov, Androbin, AngryPowman,
Anish Shah, Anton Daitche, Artsiom Chapialiou, asdf2014, Aseem Raj Baranwal, Ash Hall,
Bart Kiers, Batchu Venkat Vishal, ben, Ben Barsdell, Bill Piel, Carl Thomé, Catalin Voss,
Changming Sun, Chengzhi Chen, Chi Zeng, Chris Antaki, Chris Donahue, Chris Oelmueller,
Chris Tava, Clayne Robison, Codrut, Courtial Florian, Dalmo Cirne, Dan J, Darren Garvey,
David Kristoffersson, David Norman, David RöThlisberger, DavidNorman, Dhruv, DimanNe,
Dorokhov, Duncan Mac-Vicar P, EdwardDixon, EMCP, error.d, FAIJUL, Fan Xia,
Francois Xavier, Fred Reiss, Freedom" Koan-Sin Tan, Fritz Obermeyer, Gao, Xiang,
Guenther Schmuelling, Guo Yejun (郭叶军), Hans Gaiser, HectorSVC, Hyungsuk Yoon,
James Pruegsanusak, Jay Young, Jean Wanka, Jeff Carpenter, Jeremy Rutman, Jeroen BéDorf,
Jett Jones, Jimmy Jia, jinghuangintel, jinze1994, JKurland, Joel Hestness, joetoth,
John B Nelson, John Impallomeni, John Lawson, Jonas, Jonathan Dekhtiar, joshkyh, Jun Luan,
Jun Mei, Kai Sasaki, Karl Lessard, karl@kubx.ca, Kb Sriram, Kenichi Ueno, Kevin Slagle,
Kongsea, Lakshay Garg, lhlmgr, Lin Min, liu.guangcong, Loki Der Quaeler, Louie Helm,
lucasmoura, Luke Iwanski, Lyndon White, Mahmoud Abuzaina, Marcel Puyat, Mark Aaron Shirley,
Michele Colombo, MtDersvan, Namrata-Ibm, Nathan Luehr, Naurril, Nayana Thorat, Nicolas Lopez,
Niranjan Hasabnis, Nolan Liu, Nouce, Oliver Hennigh, osdamv, Patrik Erdes,
Patryk Chrabaszcz, Pavel Christof, Penghao Cen, postBG, Qingqing Cao, Qingying Chen, qjivy,
Raphael, Rasmi, raymondxyang, Renze Yu, resec, Roffel, Ruben Vereecken, Ryohei Kuroki,
sandipmgiri, Santiago Castro, Scott Kirkland, Sean Vig, Sebastian Raschka, Sebastian Weiss,
Sergey Kolesnikov, Sergii Khomenko, Shahid, Shivam Kotwalia, Stuart Berg, Sumit Gouthaman,
superzerg, Sven Mayer, tetris, Ti Zhou, Tiago Freitas Pereira, Tian Jin, Tomoaki Oiki,
Vaibhav Sood, vfdev, Vivek Rane, Vladimir Moskva, wangqr, Weber Xie, Will Frey,
Yan Facai (颜发才), yanivbl6, Yaroslav Bulatov, Yixing Lao, Yong Tang, youkaichao,
Yuan (Terry) Tang, Yue Zhang, Yuxin Wu, Ziming Dong, ZxYuan, 黄璞

問題を提起した方、解決するのを助け、質問し、質問に答えてくれたすべての方にも感謝しています。

-----

TensorFlow Liteは聞いたことあるけど、
Eager Execution?

..初めて聞いた
..ということでリンク先のREADME.mdも翻訳してみた。

-----

Eager Execution


警告:これはプレビュ版/プレα版です。APIとパフォーマンスの特性は変更される可能性があります。

Eager Executionは、命令型プログラミングスタイル(NumPy)を提供するTensorFlowへの実験的なインターフェイスです。Eager Execution を有効にすると、TensorFlow操作はすぐに実行されます(あなたは事前に構築されたグラフを Session.run()で実行しません)。

たとえば、次のようなTensorFlowでの単純な計算を考えてみましょう。


x = tf.placeholder(tf.float32, shape=[1, 1])
m = tf.matmul(x, x)

with tf.Session() as sess:
  print(sess.run(m, feed_dict={x: [[2.]]}))

#  [[4.]] とprintされる

Eager execution はこの術をよりシンプルにします:


x = [[2.]]
m = tf.matmul(x, x)

print(m)

警告


この機能は初期段階にあり、分散GPUトレーニングとマルチGPUトレーニングとCPUパフォーマンスのスムーズなサポートという点ではまだまだ課題が残っています。
 




インストール


Eager Execution はまだ TensorFlow リリースの一部ではないため、ソースを使用して ビルドするか、最新の夜間ビルドを必要とします。夜間ビルドは次のように利用できます。



最新の夜間ビルドDockerイメージを起動するには次のコマンドを実行します:


# GPUを使う場合は、https://github.com/NVIDIA/nvidia-docker を使ってください
nvidia-docker pull tensorflow/tensorflow:nightly-gpu
nvidia-docker run -it -p 8888:8888 tensorflow/tensorflow:nightly-gpu

# GPUがない場合、CPUのみ版を使ってください。
docker pull tensorflow/tensorflow:nightly
docker run -it -p 8888:8888 tensorflow/tensorflow:nightly

Jupiterのノートブック環境では、ブラウザの http://localhost:8888 にアクセスしてください。

ドキュメンテーション

TensorFlowにおける Eager Execution の概要ついては、以下を参照してください。



変更履歴


-----

ああ、TensorFlowを知らない人がいきなりソースコードを読もうとするとき
一番のヤマが"計算グラフ"だけど、
それをなくそうってことか..
そうすると手数の多いTensorFlowがほかのライブラリとの優位性をうしなうんじゃないのかな..

それよりKerasを使えば良いってことにならない?

..生暖かく想像するとEoDと称してJava2からJava5,6,7ときたような変更をちょこちょこ入れてくる気か、Googleよ..


2017年12月26日火曜日

Proxy管理下の Ubuntu Server 16.04.3 LTS導入済みマシン2台をつかってKubernetes環境を構築する

GeForce1050Ti搭載のGPU物理マシンが3台あるので、
これにDocker環境をあげて機械学習用に使うつもりなのだけど、
せっかく3台あるので前から気になっていた Kubernetes 環境で
立ち上げてみようかと、試してみた。

でも、あまりインストールに関する記事がない..
これからは Kubernetes だ!
とかいう記事はいくつかあるのだけど、
マイナーなTensorFlowとくらべても少ないなあ..

..ということで試行錯誤しながら、
インストール手順を作成してみた。

-----

1. 前提


マスター、ノード2台のマシンが用意されている状態とする。
Proxy Server proxy.server.com:8080 、
NTP Server ntp.server とする。

  • ホスト名 master
    •  OS: Ubuntu Server 16.04.3 LTS
    •  インストール時に Open SSH Server パッケージをチェック追加した最小構成
    •  IPアドレス:10.1.1.1/24
    •  sudo 可能なユーザでログイン可能

  • ホスト名 node01
    •  OS: Ubuntu Server 16.04.3 LTS
    •  インストール時に Open SSH Server パッケージをチェック追加した最小構成
    •  IPアドレス:10.1.1.2/24
    •  sudo 可能なユーザでログイン可能

※動作確認のため、上記マシンとLAN接続されたブラウザが動作するPCが別途必要


2. マスターの準備


  • master へログイン
  • sudo su -
  • echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
  • sysctl -p
  • vi /etc/apt/apt.conf
# 以下の2行を追加
Acquire::https::Proxy "http://proxy.server:8080/";
Acquire::http::Proxy "http://proxy.server:8080/";
  • apt update && apt -y upgrade && apt install -y ntpdate
  • ntpdate ntp.server
  • vi /etc/hosts
# 最終行に以下の2行を追加
10.1.1.1  master
10.1.1.2  node01
  • vi ~/.curlrc
# 新規追加
proxy=http://proxy.server:8080/
  • curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
  • vi /etc/apt/sources.list.d/kubernetes.list
# 新規追加
deb http://apt.kubernetes.io/ kubernetes-xenial main
  • apt update && apt install -y docker-engine
  • mkdir /etc/systemd/system/docker.service.d
  • vi /etc/systemd/system/docker.service.d/http-proxy.conf
# 新規追加、環境変数 NO_PROXY のエントリはネットワーク構成に合わせて変更
[Service]
Environment="HTTP_PROXY=http://solidproxy.exa-corp.co.jp:8080" "HTTPS_PROXY=http://solidproxy.exa-corp.co.jp:8080" "NO_PROXY=localhost,127.0.0.1,10.1.1.0/24,master,node01"
  • systemctl daemon-reload
  • systemctl restart docker
  • docker run hello-world
  • aptitude install -y kubelet kubeadm kubectl kubernetes-cni
  • vi ~/.bashrc
# 最終行へ追加、環境変数 NO_PROXY のエントリはネットワーク構成に合わせて変更
export http_proxy=http://solidproxy.exa-corp.co.jp:8080
export https_proxy=http://solidproxy.exa-corp.co.jp:8080
export no_proxy=localhost,127.0.0.1,10.1.1.0/24,master,node01
  • exit → 一旦rootから抜ける
  • sudo su -
  • swapoff -a
  • free -m
  • kubeadm init
# 実行最後にでてくるkubeadmコマンドをコピー(後でnode01上で実行する)
You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token xxxxxxxxxxxxxxxxxx10 10.1.1.109:6443 --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  • exit
  • sudo cp /etc/kubernetes/admin.conf $HOME/
  • sudo chown $(id -u):$(id -g) $HOME/admin.conf
  • export KUBECONFIG=$HOME/admin.conf
  • kubectl get nodes → kubernetes バージョンを確認、ここでは 1.9.0 とする
  • kubectl apply -f https://cloud.weave.works/k8s/v1.9/net

3. ノードの準備


  • node01 へログイン
  • sudo su -
  • echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
  • sysctl -p
  • vi /etc/apt/apt.conf
# 以下の2行を追加
Acquire::https::Proxy "http://proxy.server:8080/";
Acquire::http::Proxy "http://proxy.server:8080/";
  • apt update && apt -y upgrade && apt install -y ntpdate
  • ntpdate ntp.server
  • vi /etc/hosts
# 最終行に以下の2行を追加
10.1.1.1  master
10.1.1.2  node01
  • vi ~/.curlrc
# 新規追加
proxy=http://proxy.server:8080/
  • curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
  • vi /etc/apt/sources.list.d/kubernetes.list
# 新規追加
deb http://apt.kubernetes.io/ kubernetes-xenial main
  • apt update && apt install -y docker-engine
  • mkdir /etc/systemd/system/docker.service.d
  • vi /etc/systemd/system/docker.service.d/http-proxy.conf
# 新規追加、環境変数 NO_PROXY のエントリはネットワーク構成に合わせて変更
[Service]
Environment="HTTP_PROXY=http://solidproxy.exa-corp.co.jp:8080" "HTTPS_PROXY=http://solidproxy.exa-corp.co.jp:8080" "NO_PROXY=localhost,127.0.0.1,10.1.1.0/24,master,node01"
  • systemctl daemon-reload
  • systemctl restart docker
  • docker run hello-world
  • aptitude install -y kubelet kubeadm kubectl kubernetes-cni
  • vi ~/.bashrc
# 最終行へ追加、環境変数 NO_PROXY のエントリはネットワーク構成に合わせて変更
export http_proxy=http://solidproxy.exa-corp.co.jp:8080
export https_proxy=http://solidproxy.exa-corp.co.jp:8080
export no_proxy=localhost,127.0.0.1,10.1.1.0/24,master,node01
  • exit → 一旦rootから抜ける
  • sudo su -
  • swapoff -a
  • free -m
  • kubeadm join --token xxxxxxxxxxxxxxxxxx10 10.1.1.109:6443 --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

4. 動作確認


  • masterへログイン
  • kubectl create namespace sock-shop
  • kubectl create -f "https://github.com/microservices-demo/microservices-demo/blob/master/deploy/kubernetes/complete-demo.yaml?raw=true"
  • kubectl describe svc front-end -n sock-shop
# NodePortを確認
Name:                     front-end
Namespace:                sock-shop
Labels:                   name=front-end
Annotations:             
Selector:                 name=front-end
Type:                     NodePort
IP:                       10.98.214.109
Port:                       80/TCP
TargetPort:               8079/TCP
NodePort:                   30001/TCP
Endpoints:               
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                  

  • 動作確認用PCのブラウザから http://10.1.1.1:30001/ を開く
→weave socksサイトが開いたら成功

A. 参考





以上
-----

docker ps すると、もうワケワカラン状態に..

Kubernetes環境だと複雑になりすぎてコッチが困るので、
機械学習の実行環境レベルだと Docker Compose までにしといたほうがいいかもなあ..



2017年12月19日火曜日

MS Bot Framework を使っていたら、突然Bot Framework State serviceを廃止する旨のメールが英語で飛んできた



Slackのボットを作ったりするのに MS Bot Framework を使っているのだけど、
突然表題ののような英語のメールが飛び込んできた。




ので、Google先生のちからを借りて勝手に翻訳してみた。
以下、翻訳文である。
#参照される方は at your own risk でお願いします。


Subject: Action required: The Bot Framework State service will retire in March 2018; update your bots to use your own state storage

件名:アクション必須:Bot Framework Stateサービスは2018年3月に廃止されます。 独自の状態記憶域を使用するようにボットを更新してください。


When you store your own state data, you have better control and more privacy over your bot’s state data. We strongly recommend that you store this data in your own storage accounts and subscriptions. Because of this, we’ll retire the Bot Framework State service on March 31, 2018.

独自の状態データを保存すると、ボットの状態データに対してより優れた制御とプライバシーが得られます。 このデータは、独自のストレージアカウントとサブスクリプションに保存することを強くお勧めします。 このため、2018年3月31日にBot Framework Stateサービスを廃止します。

You’re receiving this email because you’re currently using the Microsoft Bot Framework State service.

現在あなたは、Microsoft Bot Framework Stateサービスを使用しているので、このメールを送信させていただいました。

What is the Bot Framework State service?

By default, bots built on the BotBuilder SDK and Azure Bot Service Preview have stored their conversation state in a service called the Bot Framework State service. Within the Bot Framework, the Bot State service lets your bot store and retrieve state data that is related to the conversations that your bot conducts using the Bot Connector service. The Bot State service will be retired on March 31, 2018.


Bot Framework State service とは何?

BotBuilder SDKとAzure Bot Service Previewで構築されたボットは、デフォルトでは Bot Framework State service と呼ばれるサービスに対話状態を保存しています。ボットフレームワーク内で、 Bot Framework State service を使用すると、ボットコネクタサービスを使用してボットが行う会話に関連する状態データをボットストアして取り出すことができます。 Bot Stateサービスは2018年3月31日に廃止されます。


What does this change mean for you?
  • You need to store your bot state information in your own storage accounts and subscriptions, providing you more control and privacy over your bot’s state data
  • Your bots will need to be updated to use their own state storage to continue operating after March 31, 2018.
  • Starting on December 13, 2017, you’ll receive build warnings as well as warnings in the Bot Framework emulator.

この変更はあなたにとって何を意味するのか?

  • ボットの状態情報を独自のストレージアカウントとサブスクリプションに保存する必要があります。これにより、ボットの状態データに対してより多くの制御とプライバシーを提供します。
  • 2018年3月31日以降も動作を継続するために、ボットを独自のステートストレージを使用して更新する必要があります。
  • 2017年12月13日より、Bot Frameworkエミュレータでビルド警告と警告が表示されます。



Recommended action
  • Update your bots to use their own state storage. We recommend the following:
  • Saving state data in SQL with .NET
  • Saving state data with BotBuilder-Azure in Node.js
  • Saving state data with BotBuilder-Azure in .NET

推奨される行動

  • 独自の状態記憶域を使用するようにボットを更新する。以下を推奨します:
  • .NETでSQLを使用した状態データの保存を行う
  • BotBuilder-Azure in Node.js で状態データを保存する
  • BotBuilder-Azure in .NET で状態データを保存する



For more information, please visit the Manage state data documentation webpage.

詳細については、状態データの管理ドキュメンテーションWebページをご覧ください。

For questions or feedback, please visit Stack Overflow or contact Azure support.
 
ご質問やご意見は、Stack OverflowまたはAzureサポートにお問い合わせください。

Thank you,

ありがとうございます。

Your Azure Team

あなたのAzureチームよ

たしかにBot Frameworkって常に相手が同じ場合の前提で実装できるようになっていて
便利だったんだよね..
ただ、なんでかリバースProxy型のサイトが間に入っている構成になっていて
ここが有料になったら怖いなあ..とは思ってたんだよね..

いやらしいトコ突いてきたねえ..これまでの実装を維持したいならAzure上のコンテナを使えってか..
そうじゃなきゃ自分でセッション管理してみれば?ときた..


..Azure、ズッチーなあ!(山本高広風に)

NVIDIA Docker のバージョンが上がり Docker Composeでも対応できるようになった件

たまたまAWSの x2.large 上にTensorFlow実行環境を作成しようと、
ひさしぶりにNVIDIA Dockerのサイトへ行ったら..



バージョン、上がっとるがな..


ということで、慌ててREADME.mdを勝手に翻訳してみた。
#参照の際は at your own risk でお願いします。

-----(2017/12/17時点の NVIDIA Docker README.md)-----
警告:このプロジェクトはアルファ版(libnvidia-container)をベースにしています。すでに1.0よりも安定していますが、テスト支援を必要としています。

ライセンス:New BSD
ドキュメント:wiki
パッケージ:リポジトリ



ドキュメント

完全なドキュメントおよびFAQは、(GitHubの)リポジトリWikiを参照してください。


クイックスタート

既に使用されているディストリビューション上にNVIDIAドライバサポートされているバージョンDockerがインストールされていることを確認してください(前提条件を参照)。

※翻訳時点の前提条件
  • カーネルバージョンが3.10より大きい GNU/Linux x86_64
  • 1.12以降のバージョンのDocker
  • Fermi(2.1)より後のアーキテクチャを実装したNVIDIA GPU
  • NVIDIA ドライバ 361.93 (古いドライバはテストしていません)

/etc/docker/daemon.json をカスタムしている場合は、 nvidia-docker2 パッケージがこのファイルを上書きする可能性があります。

Xenial x86_64

# nvidia-docker 1.0 がインストール済みの場合:
# nvidia-docker および既存のGPUコンテナをすべて削除する必要があります
docker volume ls -q -f driver=nvidia-docker | xargs -r -I{} -n1 docker ps -q -a -f volume={} | xargs -r docker rm -f
sudo apt-get purge -y nvidia-docker

# パッケージ利己地鶏の追加
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | \
  sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/ubuntu16.04/amd64/nvidia-docker.list | \
  sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt-get update

# nvidia-docker2 のインストールと Dokcer デーモン設定のリロード
sudo apt-get install -y nvidia-docker2
sudo pkill -SIGHUP dockerd

# 最新の公式CUDAイメージ上で nvidia-smi を実行し正常動作を確認
docker run --runtime=nvidia --rm nvidia/cuda nvidia-smi


CentOS/RHEL 7 x86_64

# nvidia-docker 1.0 がインストール済みの場合:
# nvidia-docker および既存のGPUコンテナをすべて削除する必要があります
docker volume ls -q -f driver=nvidia-docker | xargs -r -I{} -n1 docker ps -q -a -f volume={} | xargs -r docker rm -f
sudo yum remove nvidia-docker

# パッケージ利己地鶏の追加
curl -s -L https://nvidia.github.io/nvidia-docker/centos7/x86_64/nvidia-docker.repo | \
  sudo tee /etc/yum.repos.d/nvidia-docker.repo

# nvidia-docker2 のインストールと Dokcer デーモン設定のリロード
sudo yum install -y nvidia-docker2
sudo pkill -SIGHUP dockerd

# 最新の公式CUDAイメージ上で nvidia-smi を実行し正常動作を確認
docker run --runtime=nvidia --rm nvidia/cuda nvidia-smi

その他のディストリビューション/アーキテクチャ

Wikiのインストール章を参照してください。

問題(Issue)および貢献

どんな変更を行う場合でも、事前に Contributor License Agreement の署名付きコピーを digits@nvidia.com へ提出する必要があります。
  • 新しい問題を提出してお知らせください
  • あなたは pull request を開くことによって貢献することができます
-----(2017/12/17時点の NVIDIA Docker README.md)-----


..ん?

docker run --runtime=nvidia って指定すれば
nvidia-docker コマンドでなくてもいいんだ..

ちょっと検索すると、次のブログ記事を見つけた

[WonderPlanet Tech Blog] nvidia-dockerをdocker-composeから使う
http://tech.wonderpla.net/entry/2017/11/14/110000

..いつのまに devices なんてセクションが
docker-compose.yml にかけるようになったんだ..

まあ、おかげでDocker Compose できるようになったし..

あと、公式ではないけど nvidia-docker-compose なるコマンドを
GitHub で公開しているヒトもいた。

nvidia-docker-compose
https://github.com/eywalker/nvidia-docker-compose




公式でもなさそうなのだけど、
興味があったのでREADME.mdを翻訳してみた。
#こちらもat your own risk でお願いします。

-----(2017/12/18時点の nvidia-docker-compose README.md)-----
nvidia-docker-compose とは、nvidia-docker で動作するGPU 対応の Docker コンテナが docker-compose で動作するようにラップする単純なPythonスクリプトです。

依存関係

nvidia-docker-compose は以下のパッケージを必要とします。
  • Docker Engine
  • nvidia-docker
以下で説明するインストール手順のなかで自動的にインストールされる、docker-composePyYAMLJinja2 python パッケージにも依存関係があります。

nvidia-docker-compose および nvidia-docker2

既にご存じの方もおられるとおもいますが、nvidia-docker2 リリースが動作するNVIDIAでは、Dockerインフラにより緊密に統合されています(詳細は、プロジェクトリポジトリ https://github.com/NVIDIA/nvidia-dockermaster ブランチを参照してください)。この新しい統合の大きな利点の一つは、GPU で docker-compose を起動するために nvidia-docker-compose を必要としないことです。nvidia-docker2docker-compose で動作させる方法は、Issue#23 を参照してください。
/etc/docker/daemon.json に以下のような記述をおこないます
{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": [ ]
        }
    }
}

インストールする前に

nvidia-docker-composenvidia-docker が適切に機能するかどうかに依存しますが、とりわけ、nvidia-docker を実行すると自動的に作成される追加の Docker ボリュームに依存します。 nvidia-docker-compose をインストールして実行する前に、 nvidia-docker を少なくとも1回はテストして、すべてのボリュームが正しくセットアップされ、正しく機能していることを確認してください。特に、次のコマンドを実行することをお勧めします。
$ nvidia-docker run --rm nvidia/cuda nvidia-smi
使用可能なすべてのGPUがマシン上に正しく表示されている場合は、作業を進めます。 そうでない場合は、nvidia-docker-compose を使用する前にnvidia-docker のドキュメントを参照し、正しく機能することを確認してください。

インストール

スクリプトをインストールするには、次のコマンドを実行して下さい:
$ pip install nvidia-docker-compose
もし、システムが提供するPythonを使用しているのであれば、先頭に sudo を付けて実行する必要があります。

nvidia-docker-compose の利用

nvidia-docker-compose は、docker-compose のドロップイン代替コマンドです。 docker-compose と同じオプションで簡単に実行できます:
$ nvidia-docker-compose ...
システム構成に依存してsudoを付けて実行する必要があるかもしれません(i.e. dockerを実行する際にsudoを先頭につけている場合等)。
nvidia-docker-compose を実行すると、YAML型式設定ファイル nvidia-docker-compose.yml をローカルに作成します。nvidia-docker-comose 実行中にこのファイルを削除してもかまいません。Git リポジトリ内で .gitignore を使用している場合は、nvidia-docker-compose.yml をこのファイルに追加することをお勧めします。nvidia-docker-compose.yml が生成されたら、このファイルを使ってGPU対応のコンテナを標準の docker-compose コマンドでで起動することもできます。次のようにファイルを指定して実行してください:

$ docker-compose -f nvidia-docker-compose.yml ...

マルチGPUセットアップによる柔軟な実行

最初のGPUである /dev/nvidia0 などを選択して記述することによって、各コンテナに対するGPUの可視性を制御できます。ただし、手動でこれを行うことは、あなたが nvidia-docernvidia-docker-compose の機能を妨害する可能性があることを意味しており、 docker-compose.yml のどのサービスがどのGPUで実行すべきかを事前に指定する方法はありませんでした。これは、異なるマシンは異なる数のGPUを搭載している事実がさらに複雑にさせています、そしてこのため 2 GPU 搭載マシン上で devices セクションの下に /dev/nvidia4 と記述されたサービスを実行するとエラーが発生します。

GPUターゲットの指定

nvidia-docker-compose バージョン0.4.0から新たに devices ヘッダの下に /dev/nvidia* を含めることでGPUをサービスへ指定できるようになりました。次のように指定します
version: "2"
services
  process1:
    image: nvidia/cuda
    devices:
      - /dev/nvidia0
  process2:
    image: nvidia/cuda
    devices:
      - /dev/nvidia1
      - /dev/nvidia2
上記は、サービス process1 は最初のGPU( /dev/nvidia0 )のみを、サービス process2 は2番めと3番めのGPU ( /dev/nvidia1/dev/nvidia2 )をそれぞれ参照するように定義しています。devices セクションに /dev/nvidia* を指定しない場合は、これまでのバージョンの場合と同様にすべての有効なGPUが自動的に割り当てられます。

docker-compose.yml ファイルでJinja2 を使う

バージョン0.4.0からの新機能
ターゲットマシン上で利用可能なGPUの数と同じ数のコンテナコンテナを(同じ構成で)起動したいという比較的一般的な使用例をサポートするために、今度は nvidia-docker-compose にてJinja2の利用をサポートします。GPUターゲティングを指定する機能と組み合わせることで、GPUの可用性に柔軟性を持たせた docker-compose 設定を作成できるようになりました。次のテンプレートを準備し、docker-compose.yml.jinja として保存します:
version: "2"
services:
  {% for i in range(N_GPU) %}
  notebook{{i}}:
    image: eywalker/tensorflow:cuda
    ports:
      - "300{{i}}:8888"
    devices:
      - /dev/nvidia{{i}}
    volumes:
      - ./notebooks:/notebooks
  {% endfor %}
そして、このjinja2 テンプレートを -t / --template フラグをつけて指定し実行します:
$ nvidia-docker-compose --template docker-compose.yml.jinja ...
Jinja テンプレートを処理して、次のような docker-compose.yml へ展開します:
version: "2"
services:
  notebook0:
    image: eywalker/tensorflow:cuda
    ports:
      - "3000:8888"
    devices:
      - /dev/nvidia0
    volumes:
      - ./notebooks:/notebooks
  notebook1:
    image: eywalker/tensorflow:cuda
    ports:
      - "3001:8888"
    devices:
      - /dev/nvidia1
    volumes:
      - ./notebooks:/notebooks
  notebook2:
    image: eywalker/tensorflow:cuda
    ports:
      - "3002:8888"
    devices:
      - /dev/nvidia2
    volumes:
      - ./notebooks:/notebooks
上記は、3GPUマシンで実行、展開した例です。Jinja変数 N_GPU には自動的にシステム上の有効なGPU数が反映されます。この docker-compose.yml は次に nvidia-docker-compose によりほかの設定ファイルと同じように処理されGPUが使用可能なコンテナを起動します。

Composeファイルのみ生成する

GPU対応の Compose ファイルの作成だけおこない後でコンテナ起動したい場合は、-G / --generate フラグをつけて nvidia-docker-compose を実行すると、docker-compose を実行せずに作成ファイルを生成しただけで終了します。
$ nvidia-docker-compose -G ...

その他のコマンドラインオプション

代替の nvidia-docker-plugin ホストアドレスの指定や(デフォルトのnvidia-docker-compose.yml の代替として)代わりのターゲットの Docker Compose ファイルを指定などのようなその他の設定については、コマンドラインヘルプを参照してください:
$ nvidia-docker-compose -h

使い方

nvidia-docker-compose は、2つのアクションを実行するシンプルなPythonスクリプトです:
  • docker-compose 設定ファイル(デフォルトは docker-compose.yml)の構文を解釈して、GPUが有効なコンテナを実行するのに必要な設定がなされている新たなYAML型式の nvidia-docker-compose.yml を作成します。設定パラメータは nvidia-docker-plugins から読み込まれます。
  • 新たに生成された設定ファイル nvidia-docker-compose.yml docker-compose を実行します。
-----(2017/12/18時点の nvidia-docker-compose README.md)-----

ここまでやるとやり過ぎに見えるけど、
Jinjaテンプレートを使って
有効なGPU数を自動で展開して個別のDockerコンテナを作ってくれる
機能は便利だ..




..でもなあ..そろそろコンテナを
Docker Composeでなくて
Kubernetes で管理しようかなと
思ってたところなんだよなあ..

コンテナ貸しパブリックIaaSはこぞってKuberenetes使ってるし...

Docker Compose はそろそろオワコンかな..と思ってたところなんだよなあ..



p.s.

ちなみに..TensorFlowも1.4.1マイナーバージョンアップしてました..

Google Colab相当の環境をローカルPC上のDocker Composeで実現する

 Docker Composeの有料版に、お金を払いたくない ^H^Hが使えない ため古いゲーミングPC(GeForce3080)にDocker Composeを入れてその上のコンテナでGoogle Colab相当のノート操作ができないかためしてみた: コンテナイメージとして a...