Docker Part2©2ch.net

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/

スマホのフリック入力慣れないな。。

クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
昔はVM作り直したり、スナップショットから復元したりしてたけど、今はそのマウス操作すら煩わしくなってしまってる。

>>101
使っていませんｗ

ansibleを使ってDockerイメージを作ると、Dockerのキャッシュが
効かなくてイメージ作るの遅くなるでしょ？その問題もう解決したの？
あとansible使うならイメージにpythonインストールされてないとダメなんだよね？
Dockerはalpineとかpythonすら入ってないイメージをベースとすることも有るからなねぇ

君にとっては役にたたない話かもしれないど、どうしてansible使おうと思ったのか？
質問していい？ >>101にも書いてあるけど他のコンテナに乗り換えたいときのためだけ？

俺は流用するならばシェルスクリプトが一番だと思ってるよ。
だってansibleで書いたYAMLって、ansible以外に流用できないでしょ？YAML書くのめちゃくちゃ手間だし
Dockerfileはシェルスクリプトにかなり近いので流用したいならDockerfileのままでいい
Dockerのイメージを作る時に限らず、なんでansibleなんか使うのか俺には理解できないよ

>>103
> クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。

君を煽るわけじゃなく、そういうのをやってる人見てると、ワロスワロスだよｗ
なに無駄に苦労しちゃってるの？って思う
Ansibleは実行検証が必要なほど信頼できないってことだからね

Ansibleは理想としては、クリーンな状態にしなくても、冪等性とやらで
書いてあるとおりになるはずなんだが、その理想は破綻してる。
書いてない部分がどうなるのかは不定だからplaybookを変更した時に
クリーンな状態からやったのと同じ状態になるとは限らない

いやもちろんシェルスクリプトも同じだよ。でも検証時にサーバーに乗り込んで
手動でやったものがそのままコマンドにできる

playbookとして書いたものが、手動でやったことと同様のことを
行ってくれるか？という "二重の検証" は必要なくなるのさ

すごい煽られててビックリしましたｗ

>>104
用途は
1. 公式OSイメージからコンテナを作る
2. 良い感じのコンテナになってたらイメージ化する
という感じです。

「2.」のイメージ作るとこは最終段階で、そう頻繁に行う作業ではないの
仮にイメージ一つ作るのに数十分かかったとしても、自分の用途に関してはそれほど問題はないです。

Ansibleを使おうと思ったのは、昔は動いてたけど今は動くなくなっているようなPlaybookでも
失敗した箇所がピンポイントでわかるのでメンテする気が起きるからです。
人のシェルスクリプト読んだり、昔の自分のイキリシェルスクリプトを読解するのに疲れた
というのが大きいですね。

コンテナのイメージ化という事も検証の一環として行いますが、メインの用途は
コンテナでPlaybookを高速で検証して、検証した構築用Playbookを本番のVMに放つという感じです。
(本番に放つ前に一度は検証用VMにも放って確認はします)

今度は長文をPCから書き込んだらsage忘れた
2ch書き込みのブランクありすぎて色々ひどい。。

>>105
私も冪等性なんてあてにするものではないと思ってて、
Ansibleに限らず、そのほかのツールも検証してないものは信頼しないというのが私の基本スタンスです。
(特に、かなり昔に作った構築系スクリプトはそのまま実行して一回で動くとは思ってません。)

シェルスクリプトは構築コマンドそのまま列挙すればよいので便利なのですが、
例えばCentOSのOS基本設定入れてRuby入れてApache入れてアプリ入れて、
みたいな構築の場合、Role単位で過程を完全に分離できるので、管理がすごく楽なんです。

例えば構築が失敗したとき、シェルスクリプト場合
何でコケたのか、どこでコケたのか、というのを探すところから始める必要がありますが
Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。

あちこちで煽ってるけどようやくまともな意見を返す人が見つかったな

ふぉーん。ってことはシェルスクリプトでもどこで失敗したか
ピンポイントでわかれば問題ないってことじゃねーか。
あとは書き方が統一されていればいい
それなら解決可能な問題だな。っていうか俺の手元ではほぼ解決済みだ

> Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
> Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
それもほぼ解決済みだ

シェルスクリプトで解決可能なたったそれだけの問題のために
Ansibleみたいな内部で何が行われているかわからない
重量系なブラックボックスツールをありがたがって使ってんのか
なんであれ（Ansibleとか）が無駄に重いソフトだってみんな気づかないんだろうか

> 2ch書き込みのブランクありすぎて色々ひどい。。
一体いつからここが２ちゃんねるだと錯覚していた？

Ansibleがブラックボックスツールということの
意味がわからない人がいるかもしれないから
軽く説明しておいてやろう

まずお前らは環境構築をしているよな？それが仕事だ
その仕事をしている最中に、Ansible関連でバグとか
モジュールが対応してなくてうまく動かない自体が発生した。

それらをお前らすぐになおせるの？
pythonを知っていたとしてもまず無理だろ？
重量級のAnsibleをブラックボックスで使ってるからな

でも本来のお前らの仕事である環境構築は
手作業やシェルスクリプトですぐに解決できるだろ？
Ansibleの範囲でうまくできてりゃいいさ、だが
それができない場合、大きなボトルネックになってんだろ

なんかアドレスが5chになってる。いつの間に。。

>>109
言ってしまうと、自分のスクリプト力もあまり信頼してなくて、
今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。

ベテランの人が自分で方針を決めて数年後でもメンテできるように書いていれば
その人は問題なく使えると思うのですが、他の人はそれを読めるかどうかというところですね。

Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
仕組みで自然とそのようなメンテがしやすい形にはなるのです。

ただ、ベストプラクティスもそのままだと実用としてどうなのというケースも多いので
現場に合わせてアレンジする作業は必須だと思いますが。
(教科書そのままでは現実では役にたたない、とよく言われるアレみたいな感じです)

Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
品質の担保はServerSpecのテストでやってます。
何か問題があったらServerSpecのテストを足せば良かったりします。
手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。

テストや確認事項を手順書に追加するのは手順書のメンテナンスも確認作業も面倒ですが
テストなら足して実行すればよいだけなので、細かすぎるような確認作業も気兼ねなくガンガン追加できます。

多少はやったことありますが、AnsibleのモジュールそのものをPython書いて修正するというのは敷居がけっこう高いですね。。
確かに、廃止されたりオプションが変わったり、変な挙動のモジュールもあります。
解決策はそのモジュールが使えてるAnsibleのバージョンを固定するか
最悪、shellやcommandモジュールでLinuxコマンドべた書きするかでしょうか。

ただ、shell, commandモジュールを使うと冪等性が担保できないので
非推奨なのですが、そもそも私は冪等性というものを信用してなかったりするので
自分の場合は特に問題なかったり。

Ansibleが用意しているモジュールがあるのにshellやcommandでやろうとすると
こっちのモジュール使えという警告が出て煩わしかったりします。
使えるモジュールは使うとシンプルにかけたり良しなに処理してくれたりと確かに便利ではあるのですが
さっき書いたように廃止や挙動が変更されるリスクもあります。

そこでdockerコンテナを使ったPlkaybookの高速検証が活きてくるという。

さらさらっと書いてますが、このようなdocker,ansible,Serverspecの環境を作るのはそれなりに大変だと思うので、
もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。

>>111
> 今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
環境構築ごときでなんで複雑になるのかそこが不思議。
まず一つだけアドバイスするなら、設定はファイルの項目ごとに変更するのではなく、
設定ファイルをまるごとcopyすること。これで冪等性も担保される。

環境構築なんてファイルおいて数個のコマンド実行して大抵はこれだけで
終わるはずなんだが、なんで複雑になってるのか知りたいよｗ

冪等性を考えると前の状態を考慮する必要がでてくるので条件分岐なんかが出てくるが
Dockerだと最初から作り直しになるので関係ない
あんな大量のモジュールができてしまったのは、冪等性を考慮したことが根本原因かね？

> Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
> 仕組みで自然とそのようなメンテがしやすい形にはなるのです。
細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ？って頭を抱えたことが有るんだがｗ
単純にメンテしやすい形になればいいのかねぇ。詳しくは言えないがそれなら俺の手元では解決済みなんだ。

> Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
> 品質の担保はServerSpecのテストでやってます。
テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなｗ
入れない方法もあるんだっけ？

> 何か問題があったらServerSpecのテストを足せば良かったりします。
> 手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。
俺は一言も手順書なんて言ってないんだよね。テストもシェルスクリプトでやればいいでしょ？当然gitで管理できる。

あとServerSpecでも同じくブラックボックス問題がある。ServerSpecでは一体何を調べてるんだって話だよ
例えばpackageでパッケージがインストールされているか調べられるが、パッケージの管理方法はディストリで違うはずだ
packageはAlpineのapkでも使えるのか？という質問に自信をもって答えられるのか？すぐにソース読みとけるのか？
（まあそこはコマンドが実行できればOKとするのが、やるべきテストだと思うけどさ）

ServerSpec実行してOKがでればOKと信用すりゃいいんだろうけどさ、何をテストしているのかさっぱりわからん。
ServerSpec（というかrspec）というフレームワークはブラックボックスで良いんだが
肝心のテスト内容（matcher）で何をやってるのかは把握してなきゃだめだろ？

>>112
> ただ、shell, commandモジュールを使うと冪等性が担保できないので
Dockerや最近のImmutable Infrastructureではサーバ作ったら変えないので
ありがたいことに冪等性は不要になった。実行前は必ずクリーンな状態なのでね。

俺も冪等性は信頼してない。特にAnsibleとかブラックボックスなので。
ただしここではいわないが、冪等性に変わるアイデアを持ってる

> さらさらっと書いてますが、このようなdocker,ansible,Serverspecの環境を作るのはそれなりに大変だと思うので、
Dockerはともなく、ansible とか Serverspec だから大変なんだよ。
Serverspecとか今度はRubyいるだろ？


参考になった。まあ気にすんなよ。あんたを煽ってるわけじゃなく
ちょうどansible使おうとしてるやつがいたから、なんでか聞きたかっただけだ。
Ansibleとかほんとクソだって思ってるので

最初の質問にもう一度答えると
> dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
つかわん。dockerなら冪等性いらないし、1コンテナで動かすものは極力シンプルにするので
構築内容は短くなる。逆にAnsibleを動かすための部分のほうが長くなる

>>113
> もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。
インフラエンジニアじゃないのか？俺も違うけどなｗ

インフラエンジニアじゃないけど、サーバー構築やらないわけじゃなく
まあやったりする。それぐらいはできる。

問題は、パッケージインストールした。設定ファイルも書いた。こんな感じでいいだろう。
で、自動化？ まあやったほうが良いね。今やったことを自動化するだけだろ？


Ansible？ YAMLで書くのか。
インストールしたパッケージを使うモジュールはどれ？
設定ファイルに書いたことに相当する項目はどれ？
ないんだが？新しい機能だから対応してねーのか？
結局commandでシェルスクリプト書くしかねーじゃねーか

みたいなな。

インフラエンジニアってなんであんなクソなもの平気で使えるの？

オンプレでウォーターフォール、一度作ったマシンを後生大事に使い続ける、
そんなスタイルならDockerすら不要かと

> 環境構築ごときでなんで複雑になるのかそこが不思議。
社内のVMwareで作ったイメージを直接客先に入れられるならもっと簡単に作れるんですけどね。。
オンプレ上で直接構築する場合、内部やDMZなど環境毎にproxyやDNS、ntpやファイヤーウォールの設定が違ってたりするのです。
あと、WebサーバでIPアドレスだけ変えて後は全部一緒の設定にしたい場合は
Webサーバ分だけ設定ファイル作るんじゃなくて、テンプレート作ってIPアドレスだけ動的に変えて配布するとか。
便利です。

> あんな大量のモジュールができてしまったのは、冪等性を考慮したことが根本原因かね？
それも原因の一つかもしれないですが、基本は便利そうだからじゃないですかね？
私はRedHatの人ではないのでなんとも答えられませんが
「何でLinuxにはあんな大量にコマンドがあるんですか？」みたいな質問かなーと。

> 細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ？って頭を抱えたことが有るんだがｗ
そうですね。サービスが再起動されるのが状態が変更された場合という事ですけど
何をもってサービスが変更されたとするかというのがわかりにくいかもですね。
私はこれ積極的には使ってなくて、serviceモジュールで明示的にサービス再起動してます。
基本的に冪等性は考えないスタンスの一言なのですが、使わない理由をあえて考えると
構築時はいくらどのタイミングでサービスを再起動しても本番に影響は無いのと、
稼働中のサーバのサービスを再起動する場合は明示的に確実に特定のタイミングで一回だけ再起動させたいからでしょうか。

> テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなｗ
> 入れない方法もあるんだっけ？
Serverspecは私の知ってる限りのやり方ではRuby要りますね。gemですし。
サービスと関係なくある程度裁量で触れるステージング的なサーバがあれば
客に許可をもらってそこに入れるとか。。

> テストもシェルスクリプトでやればいいでしょ？当然gitで管理できる。
シェルスクリプトでテストが書けるのであれば良いと思いますが、
例えばリターンコードを確認して成功と失敗を判断して、、みたいなスクリプトを書くとすると
構築系スクリプト以上に大変な気がします。。

> ServerSpecでは一体何を調べてるんだって話だよ
何を調べれば十分かをこちらで定めて、それを満たしていることを確認するというスタンスにすれば良いと思うのです。
例えば「Rubyがインストールされていることを確認する」の場合packageだけで良しとするか、
commandでインストールしたコマンド実行後にあるべき出力結果が出てるかまで確認するかとか。
やろうと思えば手で実行できる範囲のテストはいくらでも追加できるので。

AnsibleやServerspecそのものがどうなってるかではなくて、自分が構築したサービスがちゃんと機能しているかを見ます。
こういう着眼点にすれば、将来もしAnsibleやServerspec以外の便利なソフトができても移行の判断がしやすかったりします。

> オンプレ上で直接構築する場合、内部やDMZなど環境毎にproxyやDNS、ntpやファイヤーウォールの設定が違ってたりするのです。
> あと、WebサーバでIPアドレスだけ変えて後は全部一緒の設定にしたい場合は
> Webサーバ分だけ設定ファイル作るんじゃなくて、テンプレート作ってIPアドレスだけ動的に変えて配布するとか。
> 便利です。

それはAnsibleじゃないとできないことではないからなぁ


> 例えばリターンコードを確認して成功と失敗を判断して、、みたいなスクリプトを書くとすると
> 構築系スクリプト以上に大変な気がします。。

set -e
exists_file() {
　[ -f "$1" ]
}

check() {
　exists_file /var/file1
　package_installed mysql
　some_check
}

リターンコードの確認なんていらない。set -eしてるからリターンコードが0以外だとそこでストップする
（どこでストップするかがわかるようにしたいなら、単に関数の中でメッセージを出せばいい）
あとはこんな感じでいろいろヘルパー関数を作っていけばいいだけだと思うんだが？
ヘルパー関数は再利用できるから実質check() の中身を書き連ねるだけ。

>>116
>インフラエンジニアじゃないのか？俺も違うけどなｗ
元インフラエンジニアで今の職業は百姓です。田舎で野菜作ってます。

最初はshellやcommandで書いて、使えるモジュールがわかったらあとで修正するという方法もありかなと。
まあ、だいたいそのままで特に問題ないので放置されるのがデフォルトですが。

自動化のところまでは色々できたりするんですけど、
それを他の人に引き継ぐというのがものすごく難しいんですよね。。

k8sも挑戦して、環境構築できるPlaybook作ったりしたのですが
人に引き継ぐという事が難しくて頓挫しました。
自分で管理することはできても人に引き継ぐとなるとAnsibleやServerspecの比じゃなくくらいしんどかったので
k8s環境ぶっ壊してdocker-composeに戻しました。
(そもそも社内の開発環境にk8sは大げさすぎたということもあります)

> Ansible？ YAMLで書くのか。
例えばChefの場合はRubyの知識が必要ですがYAMLは言えば設定ファイルを書くような感覚なので
インフラエンジニアにとっても比較的とっつきやすいかなと思ってます。
AnsibleでPythonを意識するような場合、複雑にやりすぎているケースがほとんどです。
Pythonの制約からなのか、変なところにカンマ入れないと動かないとかあったりしますが。
(インベントリファイルじゃなく直接ホストを一つだけ指定する場合など)

> インフラエンジニアってなんであんなクソなもの平気で使えるの？
Ansibleは自然とメンテナンスしやすい構造になるような仕組みになっているのが便利だからじゃないでしょうか。
学習コストと既存のスキルセットでできることを比較して学習した方がトータルで効率的になると判断したから使うというか。
逆に言うと既存のスキルセットで十分なことができてしまっていると学習コストを払うというほうに舵を切りにくかったりするかもですね。

私はAnsible、dockerは流行ってるから採用したのではなくて、
ある程度プライベートで遊んで便利そうだったから職場にも持ち込んだという流れでした。

>>119
> > ServerSpecでは一体何を調べてるんだって話だよ
> 何を調べれば十分かをこちらで定めて、それを満たしていることを確認するというスタンスにすれば良いと思うのです。
> 例えば「Rubyがインストールされていることを確認する」の場合packageだけで良しとするか、
> commandでインストールしたコマンド実行後にあるべき出力結果が出てるかまで確認するかとか。
> やろうと思えば手で実行できる範囲のテストはいくらでも追加できるので。

そいう話じゃなくて

describe package('mysql') do
　it { should be_installed }
end

とかやってOKになった、インストールしているらしいことはわかった。

だがこのコードが何を根拠にパッケージがインストールされていると判断したのか？ってことだよ
dpkg -l の結果から判断しているだけなのか、それともパッケージに含まれるファイルが
既定の場所に有ることを確認しているのか、パーミッションまでチェックしているのか
それがわからんってことだよ。

もちろんソースコード見ればわかるだろうけど、Rubyの知識が要求される上に
こういうのって過度に汎用化されていて簡単に読み解けるとは思えないんだが
特に言語がDSLそのものではなく、DSLを作りやすいだけの言語だと、
DSLを作るために通常のプログラミングには用いられない
メタプログラミング的なコードが多用される傾向にある

>>121
k8sはクラウドで数台〜十数台以上のマシンが常時起動していて
何もしてないのに起動してるのはもったいない。かと言って事情があって落とすことも出来ない。
ってときにそれらの余剰CPUリソースをなにかに使うことは出来ないか？って時に
使うもんだと思うぞ。あと同じサーバーを複数起動させるという前提があってこそ使える

（コスト節約のために）サーバーをオートスケールさせるのはクラウドだけなら
比較的簡単なんだが、その中に更にk8sが入り込むとk8s自体にもオートスケールがあって、
まるでクラウドの中にクラウドが有るような感じで複雑さが増し、
k8sでPod（コンテナ）をオートスケールさせて、サーバーリソースが足りなくなったら
今度は仮想マシンをオートスケールさせるとかなって安定稼働させられる自信がない。

普通に開発環境はdocker-composeがいいよ

> 学習コストと既存のスキルセットでできることを比較して学習した方がトータルで効率的になると判断したから使うというか。
俺からするとAnsibleはChefよりはましだが、それでも学習コストが高くて、（Ansible学習前の）インフラエンジニアが
持っているであろう既存のスキルセットの応用が難しく、Ansibleを覚えてしまったとしても
なおAnsibleモジュールと格闘し続ける、効率的にならない道具だと思ってる。

まあ一言で言うと、もっといい方法が有るって話だ。これ以上はここでは言えないけどｗ

>> 122
今のmysqlがどんなpathにあって権限がどうなっているのかは知らないので
仮の設定確認ですが

describe package('mysql') do
　it { should be_installed }
end

に続けて

describe file('/user/bin/mysqld') do
it { should exist }
it { should be_mode 770 }
it { should be_owned_by 'mysql' }
end

と書けばファイルの存在や権限、オーナーが確認できます。
さらにグループも確認したい場合はbe_grouped_intoを追加するなどで
いくらでも細かなチェックは追加できるかなと思います。

確かにAnsibleと比べてServerspecはRuby色が強くて
とっつきにくいかもしれませんが、そういう書き方を覚えてしまえばあとは慣れるかなぁと。

そこまでの学習コストは確かにそこそこあるので、
Rubyとシェルスクリプトと、ちょっとPythonができて
システムを俯瞰して見ることができるインフラエンジニアが居た方がいいかなーとは思います。。

> と書けばファイルの存在や権限、オーナーが確認できます。
それはただ単にメソッド用意されてるからだよねーとしか思えないんだよね

シェルスクリプトだってメソッドあれば
例えばこれみたいに書けるでしょ？

describe file '/user/bin/mysqld \
　-- should_exist \
　-- should be_mode 770 \
　-- should be_owned_by 'mysql' \
end

なんか中途半端になったなｗ

describe file '/user/bin/mysqld \
　--should_exist \
　--should_be_mode 770 \
　--should_be_owned_by 'mysql' \
end

k8sはよっぽど仮想サーバに余剰があるか、もしくはGoogleやFacebookみたいに仮想化ソフトそのものがリソースの無駄と言い切って
物理サーバとコンテナだけでやるというクラスになると意義があるのかなぁとか思ったり。

開発や検証ではコンテナをガンガン使いますが、本番にコンテナ使うというのはどうもまだ怖いですね。。
壊れたら立て直せばよいWebサーバならまだ、、とは思いますがDBにコンテナ使うという事例みたときは
なかなかチャレンジングな事してるなと思いました。。

ただでさえコンテナは障害が発生したときにコンテナ側が悪いのかサーバ側が悪いのかの切り分けが
難しいのに、そこにさらにk8sが絡んでくるとなると。。

> シェルスクリプトだってメソッドあれば
確かにメソッドを自前で用意すればできると思います。
ただ、シェルスクリプトはちょっと記述を間違ったりすると事故になる可能性があるので
テストを流す前のベテランのレビューは必須だと思うんです。

Serverspecは基本的にどんな操作もサーバーの状態は変わらない(はず)なので
ベテランのレビューがなくてもとりあえず流しとく的に実行はしやすいかなと。
(私が今まで使った限りでは変な実行してサーバが壊れた、ということは無いです。
Ctrl+Cでキャンセルしてターミナルの表示がおかしくなるということはままありますが。)

こういう作業をAnsibleやServerspecでやろうとすると
コマンドが異様に長くなるのでラッパースクリプト書いたりするのですが、
シェルスクリプトはそこで今でも大活躍してます。
なんだかんだで便利なんですよねシェルスクリプト。

Dockerfile に関しては冪等性なんていらないのでそのまま使う派
Ansible が便利なのはわかるけど、Dockerfile に関しては 1 のことをするのに
10 できる道具で頑張る感じがつらい。

Dockerfile 以外のセットアップに関してはマニュアルとか書き方とか面倒すぎるので
学習コスト払ってもシェルスクリプトは使わないで Ansible でも良いんじゃねって思う。
私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。

インフラテストに関しては goss 使ってるな〜。Rspec の記述や Ruby 入れるのだるいので。
goss は golang 製だからバイナリ置くだけだし、stdin つないでテスト渡せるので実行が簡単。
Yaml でかけて、機能が多すぎないのでテスト書くのもむっちゃ楽。
欠点は PullRequest などへの反応が鈍い、もともと作者が golang の勉強で作ったものなので設計が気になる（特に比較方法とか）

DockerImage のみのテストならば countainer-stracuture-test という google 製のものが出てきたのでこれも面白い
これに関しては、できたてなのでバグがかなり多い。新たなコミットのたびにバグができるｗ
テストできる機能は少ないが、docker engine 無しでイメージテストができたり、メンテナの反応も速いしコードも読みやすい。
今後ちゃんと出来上がれば化けるかも

> 私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
> まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。

俺の観測ではシェルスクリプトが100行だと
Ansibleのコードは1000行って感覚なんだけどね

大きな会社だと仮想サーバ一つ立てるのにいちいちインフラエンジニアにお伺い
たてないといけないけど、リソース多めのVM一つ作ってもらえばそこにdocker入れて
いろんなコンテナたててやりたい放題できるという。

4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
もちろん検証用DBコンテナとか立てるときはMySQLのinnodb_buffer_pool_size小さめにしておくとか
ちょっとした工夫はいるけど。

やっぱりシェルスクリプトだとなんでそんなに
メンテナンス性が悪いものが出来上がるのか？
書くことはAnsibleとかわらんだろ（むしろ短く書ける）
と思ってるわけだが。

ふと気づいたがもしかしてシェルスクリプトで書く時に関数作ってないのか？
ただ単に上から下へとコマンドを書き連ねるだけ？

プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が
高くないように記述するもんなんだが、インフラエンジニアってのは
それができてないレベルだったりするの？

>>131
まあ会社が会社だとそういうことなんだろうけど

> 4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
それ個人用に配給されてるPCレベルだよね？って思わなくもないｗ

うちは入社当時のMac Book Proの一番上当たりの性能
CPUは忘れたけど、16GBのメモリと、512GBのSSDだったかな？

>>133
個人PCレベルというのは否定できないw
社員数多いとリソース配分が大変なんです。
HDDはシンプロでごまかして、vCPUもまあまあ割り当てられるとして、
メモリは慢性的に不足します。

個人のMacでそれだけリソースあるなら
ローカルPCにdocker入れて使えば良いですね。

その場合も個人的にはDocker for Mac使うんじゃなくてVagrantで立ち上げたLinuxVMにdocker入れて使います。
理由は何となくというか、その方が環境が汚れなさそうだからというか。

bash のスクリプトだろうと、Python だろうと golang だろうと関数は普通に使うね。

で、シェルスクリプト 100 行だと Ansible のコード1000 行ぐらいという感覚も正しいと思うよ。
実際は、500とか600 ぐらいだと思うけど。
Ansible の yaml だと 30 行くらいかな。

てか、コードが短く "も" 書けるのが嫌なんだけどね。
例えば、2つまでつなげるなら期待通りに動くから if を使わずに || や && でつないだりとかね。

私自身はもともと Perl からの出身だから、色々な書き方があって(TIMTOWTDI)
書き方によっては短く書けるのが楽しいとか良いと思う面はある。
ただ、コードゴルフをやるならまだしも、自分以外が見るコードは
そういうことをする余地がなければ無いほど良いと思ってる。

あと、shell も perl も（Cも）変数のスコープがデフォルトでグローバルなのが良くない。
ちゃんと動くからって、スコープ意識しない使い方のコード書かれてそれをレビューで指摘したり
そのために CI を準備したりとか考えたくない。
そういう点では python の pep とか golang の fmt/lint とか最高だと思ってる。

Dockerfile も「どれだけ削るか」などで人によって書き方がまちまちになってしまうんだけど、
普通は大規模にはならないし、出来上がるイメージをバイナリだと思ってちゃんと動けば
中身がどうであれとりあえずは良いのかなと思えたりするので結構好き。

「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
は可読性、メンテナンス性が高いようにじゃない？

> 「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
> は可読性、メンテナンス性が高いようにじゃない？

そのとおり「高くなるように」と書いたつもりだった
どうもGoogle IMEの調子が良くないんだよ。
特定のアプリで極端に変換が遅くなることが有る。
アプリ再起動したら直ったからメモリリークでもしてんのかな？

>>135
やっぱり理解できない。
何かしらの越えられない壁の
あっち側とこっち側にいる気分

> てか、コードが短く "も" 書けるのが嫌なんだけどね。
略
> そういうことをする余地がなければ無いほど良いと思ってる。

コードは曖昧さがなく、削ぎ落とすものが一切ないレベルが良いと思ってる。
だからいろんな書き方があるとは思わず、
それ以外の書き方は「なんでそんな無駄なことすんの？」としか思わない

あと当たり前だけどコードゴルフのような変数名を短くするみたいな
アホなことはしない。無駄を無くすだけ。

俺のプログラミングは関数型の影響は大きいと思ってるので、関数型勉強すると良いよ
と言っても俺、関数型言語あまり知らないけどねｗｗｗ 考え方を理解してるだけ

> あと、shell も perl も（Cも）変数のスコープがデフォルトでグローバルなのが良くない。
それも手元じゃ解決済みなんだよな（苦笑）
感覚的に問題点を潰してる俺偉いｗ

ヒントを言うとサブシェルを使うとその中で定義した変数は中に閉じ込められるので
localを使わなくてもローカル変数相当になる。

>>137
そういうルールをどうやっていろんなスキルレベルの人と共有するんですかって話

>>138
逆に言えば、そういうルールを共有できればOKってことだよね？

みんなありがと。いろいろ言ってみて話を引き伸ばしたけど
もうそろそろ十分かなと思ってる

ansibleではなくシェルスクリプトでやる上で、何が足りなくて
何が必要なのかわかった気がする。

今回はこれぐらいで切り上げるよ
またどこかで違う切り口から探るかもしれないけどｗ

>>139
そう。
その意気で、ぜひ世界に通用するシェルスクリプトフレームワークを作ってくれ。

Dockerfileからラッパースクリプトを呼び出すのは良いとしても、
DockerHubでそのシェルスクリプトを表示させるすべがないのが問題。

結局GitHubに行くことになるならDockerfileの表示ページいらないのでは。

Dockerの教科書第二版が4月に出るぞー

Arukasのβ外れたけど予想以上にコスパ悪いなぁ…
さくらはコンテナホスティングやる気ないのかな

どんなビジョンであれで世界で戦えると思ったのかご説明いただきたい

初心者がLinuxとストレスフリーで生きる為の6か条

1．Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。
2. 印刷はあきらめましょう。
3. Wifiの使用はあきらめましょう。
4. 音楽・動画・画像の編集/制作はあきらめましょう。
5. Nvidia製品の使用は控えましょう。
6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。
7. Ubuntuを我慢して使い続けましょう。

随分古いな。

>>145
従いますよ

プロフェッショナルの方、どなたか教えてください(/ω＼)

今、下記内容のdockerimageを作成したいと思っています。
　
　�@　ベースのイメージ：jupyter/datascience-notebook
　�A　Tensorflowを使いたい　※�@にTensorflowがインストールされていないため

その為にdockerfileを下記の通り作成したのですが、
出来上がったdockerimageから作成したコンテナ上で上手くtensorflowが動きません。
※コンテナ内でpythonを起動し、そこで「import tensorflow as ts」を実行すると以下のエラーが出ます。
RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa
ImportError: numpy.core.multiarray failed to import
ImportError: numpy.core.umath failed to import
ImportError: numpy.core.umath failed to import
2018-04-20 03:56:29.133557: F tensorflow/python/lib/core/bfloat16.cc:664] Check failed: PyBfloat16_Type.tp_base != nullptr
Aborted

dockerfileの内容は以下になりますが、何か間違っていますでしょうか？
もし間違っている場合は、修正内容をお教えください。m(__)m

■dockerfileの内容
From jupyter/datascience-notebook
RUN pip install --upgrade pip
RUN pip install tensorflow==1.5

>>148
エラー文ちゃんと読んだんですか？

>>149
エラー文が理解できなかったです、、

>>150
numpyって知ってる？

なんぱい？

>RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa

0x って、16進数か？
0xc は12、0xa は10 って事か？

>>151
はい、知っています。
これはnumpyのversionが古いということですか？

「python module compiled against API version」で検索！

開発者の基本は、エラーメッセージで検索すること

>>155
検索しましたが、力不足で分かりませんでした。。
少しやってみたものの、

import tensorflow as ts
しただけで、
「The kernel appears to have died. It will restart automatically.
（カーネルが停止したようです。 自動的に再起動します。）」
が出てしまいました。

どなたかお力をお貸しください(/ω＼)

いままで偉そうにしてたやつ、ちゃんと答えてあげろや

「docker hub tensorflow」で検索！

この手の質問って動作環境が横断的だからdockerスレと言語スレ側でたらい回しにされちゃうんだよな
かと言ってマルチポストはできないし悩ましいところ

エラーメッセージやアドバイス貰ったキーワードをダブルクオートで括ったフレーズ検索も駆使して乗り越えるのだ
今こそ成長の時

>>156
tensorflowのバージョンはどうした？numpyのバージョンはどうした？
バージョンがあってないと言われてるんだからtensorflowのバージョンを1.4とか1.3とかに下げてみて試してみたらいいんじゃないでしょうか。

RUN pip install tensorflow==1.5

>>160
ありがとうございます！
tensorflowのバージョンを1.3にすることで、エラーも出ず正常にインストールできました。
1.4や1.6では、エラーが出てしまい駄目でした。

皆さん、私の力不足でお手数をおかけいたしました。
本当にありがとうございました。

僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

EAAD8

EAAD8

ディープラーニング ライブラリの管理で混乱しないようにとdockerを導入したけど
今はdockerで混乱してる
開発環境はどうやって整えるんだ、これ
コンテナの外と中は完全に分かれているのかよ
今あるエディタやアナコンダを呼べないぞ
コンテナを作る時に全部詰め込まきゃダメなのか?
NGCをつかっているけど

>>164
はいはい、いつもの仮想マシンの使い方とごっちゃにしてる人ね（笑）

Dockerは環境を作るものじゃなくて、
アプリケーションを作るものです。

ディープラーニングの何をしたいのか知らないけど
コマンドを実行するだろ？
そのコマンドを実行するのにライブラリとか必要だろ？

そのコマンドにライブラリなんか全部くっつけて
一つのDockerコンテナ＝アプリケーションを作るものです。

>>165
いや、知らんよ
俺は開発元が進めてきたものを使うだけ

アプリケーションなら
任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ

しかし、環境の切り分けのためじゃないならなんで開発元はdockerを配布しているんだろうね
それも競合を心配する必要ないですよってアピールしながね

> アプリケーションなら
> 任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ

それを作るのがDockerを使うお前なんだって

>>168
それを玄人様たちはどうしているのかってこっちは聞いているだが...

普通にコマンド実行に必要なものを
まとめてコンテナにしてるだけだが？

sage

pullしたubuntuイメージにvimが入っていないんだけど・・・
aptコマンドもないんだけど・・・
docker search ubuntuで出てくるうち全部入りのイメージってどれ？

dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの？

>>173
コンテナ起動時にストレージ領域を紐づけてなかったら終了時に綺麗さっぱり消えるようだ

>>173
正確にはコンテナを削除すると無くなる
停止しただけでは無くならない
ゆえに削除するまではdocker logsでログも見れるし
docker commitでイメージ化すれば
docker runで中身を見れる

https://stackoverflow.com/a/39329138

>>172
欲しけりゃ自分のDockerfileに入れるか
全部のコンテナでそれやるのがアレってなら
新しくvimコンテナ作って編集したいファイルだけマウントするか
ホストのファイルをマウントして
ホスト側でvimで編集すれば良い

てか開発環境だよな
本番環境でそれやったら
ちゃんと動く環境を保存出来るっていうDockerの魅力を殺している
場合によっては仕方ない事もあるが

>>172
> pullしたubuntuイメージにvimが入っていないんだけど・・・
Dockerの使い方を間違ってる。

あんたが言ってるのは、pullしてきたffmpegコマンドの中に
vimが埋め込まれてないんだけどって言ってるようなもの
Dockerコンテナ = 実行ファイル

ffmpegの処理にvimなんていらないんだから入っていなくて
当たり前だし入れるべきではない

だがaptコマンドは普通入ってるはずだけどな

>>172
> dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの？
ffmpegコマンドの中で内部的に使用しているファイルはコンテナ削除とともに消える。
Dockerコンテナの中のファイルはメモリと考えればいい。
コマンドを終了するとメモリも解放される

（Dockerコンテナ版の）ffmpegコマンドから書き出したいなら、
ボリュームでコマンド（コンテナ）外部への読み書き場所を指定する

>>177
アドバイスありがとう
ということは、dockerで起動したOS内でvimが使いたければ
vimのコンテナを探してきて追加起動しろってこと？
どこのサイトにどんな名前でvimのコンテナがあるのか調べるみたいなことを
アプリごとにやってたら、環境を作るまでどれだけの手間と時間がかかることやら
このソフトの何が持てはやされているのか全く理解できない

>>178
だから使い方が間違ってる。
全く理解できないのは、あんたが正しい使い方がわかってないからだよ

そもそもDockerコンテナは使うものじゃない。作るものだ。
アプリのビルド・コンパイルと一緒だよ
もちろん誰かが作ったものがそのまま使えるのなら
使っていいんだが、基本はアプリの開発者が作るもの

vimとかそういうのは、どうせあんたUbuntuとか有名所の
ディストリ使ってるんだろ？そういうのはパッケージメンテナが
ちゃんと動くようにメンテしてくれてる。それで満足してるならそれ使えばいい。

Dockerの出番はそれで満足できない場合だよ。
vimにそういうのがあるのかしれないが、独自にビルドしないと使えない機能を使いたいときや
例えばvimの新しいバージョンを使いたい時。ビルドするためにライブラリも新しくしなければいけない
でもOSのライブラリを新しくすると、他のプログラムに影響が出るかもしれない

そういうときにvimのビルドとそれを動かす環境までも一体化させて、独自のvimを作る
ってときに使うんだよ。実行環境まで含まれてるから、OS標準のライブラリなどを
置き換えたりもしないし、どこに持っていってもそのまま使える
オレオレvimバイナリ（=Dockerコンテナ）の出来上がりってわけだ

で、そんなもん普通はやらねーだろ？ だからアプリの開発者が作るものだって言ったわけだ。
vimなどのパッケージはパッケージのメンテナが頑張って動くようにしてくれてる
だけど、自分で作ったアプリは、自分が頑張るしかないだろ？ でも頑張りたくもない
いろんなディストリや、WindowsやMacでも動くようになんかするの大変じゃないか
だからDockerコンテナ化することで、Dockerデーモンさえ動いていれば、
どこに持っていっても同じように動かせるってわけさ
一言で言えば可搬性だな

>>178
> ということは、dockerで起動したOS内でvimが使いたければ

それから通常はdockerで起動したOSの中に乗り込んでvim実行して
ファイル修正とかしないからな

独自のDockerイメージを作るときに、デバッグ目的にやることはあるけど
「dockerで起動したOS」なんて考え方を持ってはいけない

なぜなら、何らかのプログラムに実行環境をくっつけただけで、
作られるものは、実行環境付きのなんらかのプログラムなんだから
そこにOSなんてものはないと思え

今日から新しいプロジェクトでmac上でDOCKERを使う事になったんですが

最初の社内のチュートリアルに従ってHOMEBREWからインストールして起動したところ
新しいバージョンがありますって言われたので
アップデート＆ReLunchをしたらそのまま反応がなく
アプリからダブルクリックしても起動しなくなりました

MAC使うのもバージョン管理ツール使うのも初めてだらけで
くだらない質問で申し訳ないんですが
考えられる解決方法はありませんでしょうか

社内の人に聞け

普段サーバーサイドJavaとかPHP JSでウェブアプリかいてて
mac の Ruby on Rails のサーバーサイドの案件が修羅場でヘルプはいったんだけど
分かってる人はみんな忙しくて質問なげてもなかなかかえってこないんですよね

でもこんな情報じゃわかるわけないですよね…
明日また社内できいてみます
すいませんでした…

>>181
dockerは公式サイトのやり方でインストールしたほうがいいんじゃね？

社内のチュートリアルが何年前に書かれたかだな
Docker Toolbox使ってたら古いやり方だな
まあ社内全員やり方が決まってるなら仕方ないが

支給されたmac PCが他の人も使うみたいで
別の人がインストールしたhomebrewが/usr/localにはいってて
権限が変更できないくてホーム以下にインストールしたんだけどそのせいなのかなと…

１日がかりでbrew　rbenv　dockerの３ついれただけなんだけど
どれが原因なのかがぜんぜん分からない…
マックはじめてで最初の１，２時間は日本語変換や窓の最小化やコピペもわからないレベルで作業効率も悪いし

Javaからruby覚えるのはすぐできると思ったけど
OSが違ったりフレームワークの環境構築がこんな大変だと思わなかった

もうmac板で質問したほうがいいのでは

>>186
なんの苦労もなくhomebrewを使いたいなら
Macを他に人に使わせるな。そしてクリーンインストールして
自分ひとりのものとして使え

homebrewはインストールしたユーザー以外がまともに使うことは無理
homebrew自体はsudo使ってインストールするくせに（/usr/localに書き込むから）
パッケージ自体は/usr/local以下に一般ユーザーでインストールするからな
ディレクトリはこんな感じになる

https://github.com/Homebrew/brew/issues/3322#issuecomment-336770069
> -rw-r--r-- 1 weicool admin 3161 Jan 18 2016 /usr/local/CODEOFCONDUCT.md
> drwxr-xr-x 18 weicool admin 576 Oct 8 13:58 /usr/local/Cellar/
> drwxr-xr-x 2 weicool wheel 64 Oct 15 10:57 /usr/local/Frameworks/
> -rw-r--r-- 1 weicool admin 1241 Jan 18 2016 /usr/local/LICENSE.txt

見ての通り、adminグループに書き込み権限がないから、
最初にパッケージをインストールした人以外がいじることはできない。
brew管理用のユーザーを別で作成するとかumaskの設定をいじってたりとか
ちゃんとやってればマルチユーザーで使えるかもしれんがな

homebrewの設計自体はsudoを使わない方針なんだが
https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad
じゃあ共有のディレクトリ/usr/localを使うなと

そうなんですね
クリーンインストールしていいかお願いしてみます
検索するとわりとホーム以下にインストールする方法とかでてきたのでいけるかと思ったんですけど

コーディングスキルかわれて入ったのに初日から環境構築だけでつぶされてストレス
なまじできると思われてるからしょーもない質問もしにくいし

もともと大学院研究室あがりでスクラッチからかくのが好きな
ブラックボックスなツール使うの気持ち悪い
古い人間だから昨今のフレームワークだらけの業界きついなあ…

頭でっかちの使えないやつか現場も大変だな

macやhomebrewがはじめてなのはともかく、バージョン管理ツールはじめてはないわ
それでひとりで環境構築しろってほったらかしなのも普通はありえんと思うけど
仕事ほしくて経験ないのに経験ありとか嘘かいたんじゃねーの

最後にききたいんですけど /usr/local じゃなく
~〜/homeblew に homeblew をいれたんですが
この blew から Docker をインストールした場合実態はどこにあるんでしょうか

チュートリアルにアプリケーションからdockerを起動とあるんですけど
/Application/Docker.app を起動したときにもっと新しいのがありますっていわれて
更新かけたらそれっきりだったので
これが前の人がインストールしたやつだったのかな…

コマンドラインの docker はホーム以下のパスになってたんですけど
アプリケーションからじゃなくコマンドラインからDockerのGUIアプリ起動する方法ってありますか？

解決しました

初回起動時に窓が出たのでずっと窓を探してたんですけど
右上のクジラマークからアクセスするんですね…
おさわがせしました

何度もすいません

docker-compose up -d

で ERROR: manifest for xxx/yyy:2018zzzz not found が出るんですがどこを見ればいいのでしょうか

一応同じディレクトリに docker-compose.yml はあって
yyy:
image: xxx/yyy:2018zzzz
と書かれています

>>194
普通はそうならないので環境の問題です
OSをクリーンインストールしてください

rubyは導入ハードル高すぎ
よっぽど複雑なプロジェクトでもなけりゃこんな開発環境作ってるあ労力で案件終わるわ

利用プロジェクトの多くが低品質だったせいでいわゆるアタリショックみたいな扱い受けてるよな
負の遺産だとかRuby巻き返しの目は潰えてるとまで言われてるし・・・Javaみたいにはならんで欲しいマジで

散々Perlディスっといてこれだもんなm9(^Д^)プギャー

やめて…perlは6を引き伸ばし杉た件のせいで世間との剥離からユーザー離れが尋常じゃなく
引き合いに出されると最底辺の戦いじみて嘲笑の的です…

イシキダケタカイケイ

WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87