仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/02/16(木) 18:01:04.48

開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ

**デフォルトの名無しさん** · 2017/10/21(土) 12:59:28.60

>>226
ほんとこれ
NuGetでそこらへんは用が足りてるんだよね

てかVSとAzureより、Dockerのほうが楽とか狂気すぎ
Windows上でDocker動くようにするほうが大変だろ
そんで得られるメリットがプロセスの仮想化です！ってやってられんわ

**デフォルトの名無しさん** · 2017/10/21(土) 12:59:54.34

>>228
.Netで完結します
おつかれ

**デフォルトの名無しさん** · 2017/10/21(土) 13:01:46.72

このスレ定期的に長文基地外がわくね

**デフォルトの名無しさん** · 2017/10/21(土) 13:02:24.19

.net使うにしても、dockerイメージを使えばデプロイは楽になるだろうね。
なぜなら、そのdockerイメージの中に.netランタイムまで入っているから。

Dockerサーバーがあれば（それはきっと手元のマシンに入っているだろう）
どこぞのdockerイメージを、手元の環境を見直すこと無く直ぐに動かすことができる。

Windows 10で最新の.netがインストールされていること
なんて制約はない。

**デフォルトの名無しさん** · 2017/10/21(土) 13:02:55.54

>>230
> .Netで完結します
遠吠えｗｗｗｗ

誰が、そんな説明で納得すると思ってんるんだ。
出直してこい

**デフォルトの名無しさん** · 2017/10/21(土) 13:03:35.60

ありとあらゆる条件が全く同等という保証がなければDockerだろうがなんだろうが実機テストは必要
それがテストってものだよ
手元の仮想環境と鯖の仮想環境はおんなじだ(だと思う)からテストはしなくていいなんてのは実社会では通用しないぞ

**デフォルトの名無しさん** · 2017/10/21(土) 13:04:51.34

Dockerはwindowsだと10以降しか対応してなくね？
開発環境が窓っていう、かわいそうな現場は大半がまだ7だからdockerなんか動かないだろ

**デフォルトの名無しさん** · 2017/10/21(土) 13:06:43.75

>>234
あ、はい、時間とコストの問題です。（言わなきゃ分からんかな？）

手元が実機とほぼ同じであれば、実機で見つかるバグは手元でほとんど再現します。
だからより早く少ないコストで修正できるということです。

可能か不可能かのはないをするのは実社会で通用しないぞ？ｗ
重要なのはどれだけコストが小さくできるかだ。

**デフォルトの名無しさん** · 2017/10/21(土) 13:07:37.66

>>235
virtualboxで動くよ
さすがはdockerというほかない
どこでも使える

**デフォルトの名無しさん** · 2017/10/21(土) 13:09:30.78

>>235
動くよ？
https://qiita.com/0829/items/d303412b15e8f473f3be

ってか、dockerさえ動けば良いのだからどんな方法でも良い。
アプリ自体はdockerには依存してない。

**デフォルトの名無しさん** · 2017/10/21(土) 13:10:45.14

>>236
おやおや
君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？
新しい技術を覚えたてで興奮する気持ちはわかるが発言は冷静になってからにしたほうがいいぞ

**デフォルトの名無しさん** · 2017/10/21(土) 13:12:34.46

ふむ。さすがマイクロソフト。
当然だが組み合わせて使うことの意味をちゃんと知ってるな。

NET Core アプリケーションの Docker イメージのビルド
https://docs.microsoft.com/ja-jp/dotnet/core/docker/building-net-docker-images

NET Core と Docker を一緒に使用する方法を理解するには、まず、提供されるさまざまな
Docker イメージと、適切な使用のタイミングを把握する必要があります。
ここでは、提供されるバリエーションを確認し、ASP.NET Core Web API をビルドし、
Yeoman Docker ツールを使用してデバッグ可能なコンテナーを作成し、
さらにプロセスにおいて Visual Studio Code がどのように役立つかを簡単に確認します。

**デフォルトの名無しさん** · 2017/10/21(土) 13:13:04.58

長文で暴れてるのって同一人物だろ
コテつけてほしい

**デフォルトの名無しさん** · 2017/10/21(土) 13:13:53.59

>>239
> 君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？

ならお前の耳が悪いんでね～の？ｗ

聞こえたのは「お前」の耳（目）
言ったのであれば、それは俺の口（手）だがｗ

いえ「実機テストが必要ない」と書いてある文章を
示せるというのであれば、示して良いんですよ？ｗ

**デフォルトの名無しさん** · 2017/10/21(土) 13:14:14.77

>>241

ID変えるようなやつだから無理

**デフォルトの名無しさん** · 2017/10/21(土) 13:17:10.24

コンテナー - 従来の .NET アプリを Docker で最新化する
https://msdn.microsoft.com/ja-jp/magazine/mt797650.aspx

> このような従来のアプリケーションでは依然として大きなビジネス価値が提供されていますが、
> その保守、アップグレード、拡張、および管理は難しくなっている可能性があります。

やっぱり.NETでは保守、アップグレード、拡張、および管理は難しくなってるんだね。

> 同時に、このようなアプリケーションをすべて作り直すことも、そのために必要な投資に
> 見合わない場合があります。ただし、軽量なコンテナー内でアプリケーションを実行する
> プラットフォームである Docker と、Windows Server 2016 を併用することで、
> 従来のアプリケーションの寿命を伸ばすことが可能です。つまり、機能を追加し、
> セキュリティとパフォーマンスを向上して、継続的配置に移行します。
> それも、時間がかかるうえにコストが高い再構築プロジェクトを実施する必要はありません。

継続的配置（配置＝デプロイ）がDockerは便利だってMSも認めてるね。

**デフォルトの名無しさん** · 2017/10/21(土) 13:18:45.25

>>242
自分のレスを冷静に見つめ直してごらん
あたかもテスト不要であるように取れる発言を何度もしてるよ
これから社会に出るのだろうし反省することも覚えたほうがいい

**デフォルトの名無しさん** · 2017/10/21(土) 13:21:03.22

>>243
あなたにコテつけてほしいってことなんだけど…

**デフォルトの名無しさん** · 2017/10/21(土) 13:23:50.11

>>245
> あたかもテスト不要であるように取れる発言を何度もしてるよ

引用できない時点で、説得力ゼロ
できないなら、なんなら俺が引用してあげようか？

例えば >>225
> 開発してテストしたら、それは実機環境でテストしてるのほぼ同じなんだよ。
> 違いは小さなカーネル部分だけ（Dockerサーバーのバージョンには依存していない）

「ほぼ」同じと書いて有ることから、全く同じではないということがわかる。
そして「違い」について書いてあるから、違いが有ることも明示されている。
よって実機環境でテストが不要ということにはならない。

さて、次はあんたの番だ。

**デフォルトの名無しさん** · 2017/10/21(土) 13:25:22.89

>>246
ID見ればわかるし、俺にコテを付けるメリットがない。
というか、５ちゃんねるでコテはつけないというは
俺の中でとっくの昔に決めたルールなので言うだけムダだｗ

**デフォルトの名無しさん** · 2017/10/21(土) 13:41:22.32

>>247
15日あたりのレスとかなぁ

**デフォルトの名無しさん** · 2017/10/21(土) 13:42:48.09

そこまで調べて引用できないとか、やっぱりなぁとしか思えんな

**デフォルトの名無しさん** · 2017/10/21(土) 13:46:47.12

>>122
＞だからローカルで開発で使用していたDockerイメージをそのまま
＞クラウドの仮想化サービス上に持っていくことができる。
＞その作業も単にdocker runするだけ

JavaのWOTAとの対比で語っちゃってるしこれはそうとしか読めんなぁ

**デフォルトの名無しさん** · 2017/10/21(土) 13:55:29.54

どうした？
言い訳が思いつかないのか？

**デフォルトの名無しさん** · 2017/10/21(土) 14:01:47.02

>>251
持っていくことができるよ？
持っていってテストするんだろ？
何を言ってるんだとしか思えんわｗ

**デフォルトの名無しさん** · 2017/10/21(土) 14:06:21.17

>>253
ん～
ちょっと厳しいなその反論は
じゃあなんでJavaと対比したの？ってなるよね

Javaはwrite once, test everywhereのクソだけどそれに比べてDockerは～
っていう文脈でしょ？

**デフォルトの名無しさん** · 2017/10/21(土) 14:18:41.57

>>254
ワロタｗｗｗ
お前バカだわ。うん。バカだわ

Javaが主張した言葉、Write once, run everywhere
で、それがが批判されてるのは、実行できると言うが
そこらじゅうでデバッグ（テスト）しなきゃいけないって批判されているほど、
Javaのrun everywhere「どこでも走るレベル」は"低い"って話だ。
低いから、そこらじゅうでデバッグ（テスト）しなきゃいけない

なぜか？そりゃそうだ。各OSごとで同じものを使うのではなく
各OS毎にライブラリ側で抽象化レイヤを開発してるからだ。
同じものを使っているんじゃない。違うものを使って同じに見せかけてるから
それじゃ互換性レベルは低くなるよねってことだ。

それに比べてDockerは同じものを使う。ライブラリを各OS毎に用意するのではなく
同じものをイメージに同梱する。だからJavaよりもはるかに高いレベルで
DockerはWrite once, run everywhereを実現している。
違いは高い互換性を持つカーネルのみだからな。
Write once, run everywhereなわけだ。

で、お前は、（Javaが主張した言葉）Write once, run everywhere は
全くテストしなくていいって意味で言ってると思うか？

お前がバカだって言った意味がわかったか？

お前は（Dockerが実現している）Write once, run everywhere を
実機で「全く」テストしなくていいという意味だって勘違してるなってわかったからだよ。

**デフォルトの名無しさん** · 2017/10/21(土) 14:21:12.73

結局、.NETも同じことになるんだろうな。

Windows実装版とLinux実装版で違いが有るのなら、
全く同じように動くわけじゃない。

同じものを使わなんと同じようには動かんよ。
理論的には動くだろうけど、違う実装なら違いは出る。

全く同じものを使うDockerの利点はそこに有る。

**デフォルトの名無しさん** · 2017/10/21(土) 14:24:16.29

>>255
残念だけどそう考えてるのは君だけだよ
君のレスを読んだ人は
あ、こいつDocker使えばテストいらんと思ってるな
と思うわけだ
社会に出たら人からどう見られるかってのも大切だから覚えておいてね

**デフォルトの名無しさん** · 2017/10/21(土) 14:31:43.74

まあ別の言い方で簡単に>>254がバカだって証明するならば

> Javaはwrite once, test everywhereのクソだけどそれに比べてDockerは～
> っていう文脈でしょ？

write onceはJavaもDockerも同じなので省略するとして

Javaは、test everywhere（どこでもテスト）
Dockerは、not test everywhere（not どこでもテスト）

「どこでもテスト」の反対は「テストなし」ではない
「全て」の反対は「一部」であって「無」ではない

**デフォルトの名無しさん** · 2017/10/21(土) 14:33:36.33

>>257
> 君のレスを読んだ人は
> あ、こいつDocker使えばテストいらんと思ってるな
> と思うわけだ

だからどこにそう書いてある？引用してみて。

すでに俺は「テストいらないと言ってない所」を引用済み

お前が、他人の説明を間違って解釈して喚いていているやつってのは証明した。
社会に出たら人からどう見られるかってのも大切だから覚えておいてね

**デフォルトの名無しさん** · 2017/10/21(土) 14:36:58.71

今回は見事論破（笑）できたから

> ちょっと厳しいなその反論は
と言えなかったんだろうなｗ

**デフォルトの名無しさん** · 2017/10/21(土) 21:13:10.64

docker使うケースは頻繁なデプロイが前提だったり迅速なスケールアウトが必要だったりの事情があるはずで、
そういう場合に例えば速度面でVMより起動が速い事が一番のメリットだ、という理由があって使うんじゃねーの？
あと消費リソースがVMより少なくて済むとか。

実行環境のパッケージングだけならVagrantでもansibleでも事足りるわけで、
それこそ全部シェルでやれっつーシェル厨もいるだろうけどw
まぁデプロイ楽にする方法なんて他にもあるし、要求や制約に合わせて選ぶもんだ。

メリットが享受できないユースケース出してきてdocker要らないっつーのも馬鹿だし、
他に方法があるのにdockerをお押しつけるのも馬鹿。

テストにしても、ライブラリのバージョン依存のバグを本番環境でのテストまでに見つけられない方が問題なわけで、
ID:zkU9oivGが言いたいのは、そこのバグはもっと早期に潰してる前提でしょ？
テストなんて工程別に目的持ってやるもんなのに、全部ひっくるめて語るのは暴論だわな。

**デフォルトの名無しさん** · 2017/10/21(土) 22:19:05.77

>>261
> 実行環境のパッケージングだけならVagrantでもansibleでも事足りるわけで、
だから全く別のものを混ぜないでくれ。分かってないことがバレバレだろ。

ansibleは構成管理ツール。マシンの環境を構築するツール
無理やりDockerに対応づけるならば、Dockerfileを使ったDockerイメージのビルド作業だよ。
（Dockerイメージのビルド作業にAnsibleを使うようなやつはいないが）
ansibleはDockerと違ってイメージを作るものじゃない。
ただのセットアップ手順書だ

Vagrantは、仮想「開発環境」構築ソフトウェア実機で使うことは想定されていない。
無理やりDockerと関連付けるならば、Vagrantで構築された仮想環境には
Dockerサーバーもインストール済みで、すぐにDockerコマンドが使用できる。
みたいな使い方をするんだ。

例えば開発環境の話をしてるとして、 Vagrantで作った仮想マシン VS 物理マシン（Windows、MacOS、Linux）の
どちらであなたは開発してますか？とかこういう使い方をするんだよ。

仮想マシン上でもDockerは使えるし、物理マシン上でもDockerは使える。
物理マシン上で作成したDockerイメージがVagrant上でも動く
クラウドでもDockerサーバーをインストール済みのVMイメージが公式で用意されているから
同じDockerイメージをそのままクラウドでも使うことができる。

Vagrantで作ったイメージが、クラウド上の仮想マシンで動くことなんてまずないからな。
Nested VMは茨の道だよ。それが出来たとしても起動時間、使用メモリ、ネットワークの点から
デメリットしか存在しない

Vagrantが実行環境のイメージ化（＝実行マシン構成が含まれる）とするならば
Dockerはアプリケーションのイメージ化だ。アプリケーションにはマシンの構成が含まれないから
物理・仮想マシン関係なくどこででも動くんだ。ただの１つのアプリケーションだもの

**デフォルトの名無しさん** · 2017/10/21(土) 22:21:53.51

イメージのビルドにAnsible使ってるよー

**デフォルトの名無しさん** · 2017/10/21(土) 22:27:51.08

そういやAnsible Containerってのができたんだっけｗ

なんかメリットあんの？
コンテナイメージの作成がDockerfileじゃできないほど
複雑なものでも作るの？

シェルスクリプトが使えない人の救済用以外の
メリットがあるなら教えてください。

**デフォルトの名無しさん** · 2017/10/22(日) 00:59:52.33

いや普通にDockerfileのビルドに使ってるでよ
docker_imageってモジュール

**デフォルトの名無しさん** · 2017/10/22(日) 01:00:55.77

てかシェルスクリプト使えない人ってどゆこと？
窓ユーザーってこと？質問の意味がよくわからん…

**デフォルトの名無しさん** · 2017/10/22(日) 01:13:03.22

>>265
お、おう。
それはdocker buildコマンドを叩く代わりに
ansibleを使っているってだけの話だな。
dockerコンテナへのデプロイではなく

どころで普段、端末からdocker使えるか？
docker build -t tag . とか
docker run -it debian /bin/bash
みたいなのそらで打てるか？

ansible使わないとコマンド打てないっていうんじゃ恥ずかしいぞ

**デフォルトの名無しさん** · 2017/10/22(日) 01:14:41.12

>>266
世の中には、ansible経由で設定ファイルを書いて
コマンドを実行している人がいるかもしれない。

dockerに新しいオプションが増えてもすぐに使えずに
http://docs.ansible.com/ansible/latest/docker_image_module.html
このモジュールが対応していることしかできないって人もいるかもしれない

**デフォルトの名無しさん** · 2017/10/22(日) 01:17:06.88

buildもpushもpullもrunも全部ansibleでやるときあるよ

dockerの基本的なコマンドそらでうてないやつなんているの？
ローカルでやるときはいちいちansibleなんてつかわんのに

質問の趣旨は？？

**デフォルトの名無しさん** · 2017/10/22(日) 01:19:08.12

>>268
え、設定ファイルってDockerfileをってこと？？
それをlineinfileとか使って動的生成する人ってことかな
そんな人いないと思うけど…

**デフォルトの名無しさん** · 2017/10/22(日) 01:23:02.03

>>269
そらでうてるものに対して対応するansibleの設定探すの面倒じゃないかなーって思って
それに例えばマイナー（？）なオプションbuild時にラベルつけたくなったらどうするの？とかさ
モジュール対応してないでしょ？

**デフォルトの名無しさん** · 2017/10/22(日) 01:27:52.52

ローカルでやるときはいちいちansibleは使わない

そうだよね。

まず最初にansibleを使わないで作業する
コマンドを叩く、やりたいことを実現する。

それをansible言語に翻訳する作業ってすごく無駄な作業だと思う。
しかもローカルでやれることの一部しかできないし。

**デフォルトの名無しさん** · 2017/10/22(日) 01:29:40.83

>>271
まぁ面倒っちゃ面倒かもな
俺はもうスニペット用意してるからそこまで手間でもないけど
--labelは使ったことないから、知らんけど、まぁどうしてもそうなったら仕方ないからcommnd module使うんじゃね？

**デフォルトの名無しさん** · 2017/10/22(日) 01:30:08.38

もちろんansibleにもメリットは有るよ。
今となってはさほど意味がなくなったが冪等性や
複数台のマシンに対して同じ/異なる設定を送り込むとか

でもさ、コマンド実行部分をYAMLで書けるようにする
そのためのラッパー（モジュール）が大量に必要。
これは失敗だったね。

**デフォルトの名無しさん** · 2017/10/22(日) 01:32:10.42

でも他もそうじゃないか？
ChefとかPuppetはそういうのないの？？

**デフォルトの名無しさん** · 2017/10/22(日) 01:34:02.76

てかその設定への翻訳を無駄な作業って、じゃあ毎回コマンド打つのか？？

**デフォルトの名無しさん** · 2017/10/22(日) 01:39:10.45

>>273
やっとansible使ったことがありそうな人が来たｗ

手間なんだよ。モジュールが用意されてないこともあるし、
あったとしても、膨大な設定をオプションを
ansible語へ翻訳しないといけない。

あとリモート側にpythonが必要というのも、設計ミスだろうね。
サーバーにはそれぐらい入れとけよと言いたいのかもしれないけど、
軽くするために必要ないものは入れないという文化も有るしね

さらにdockerはsshすら入ってない。（そもそもそういう使い方をするものじゃない）
でもshは入っている。だからDockerfileはシェルコマンドの頭にRUN付けただけ
みたいな、ほぼシェルスクリプトのやり方でイメージを作成する

**デフォルトの名無しさん** · 2017/10/22(日) 01:42:07.34

>>276

> てかその設定への翻訳を無駄な作業って、じゃあ毎回コマンド打つのか？？

テキストファイルに、普段あなたが実行しているコマンドを
そのまま羅列していけば、それがそのまま使えるんですよ？

翻訳作業がいらないだけでなく、ansibleで書くよりも短く書けます。
実行するときもスクリプトファイル名を入力するだけです。

**デフォルトの名無しさん** · 2017/10/22(日) 01:42:40.90

dockerにssh？？
dockerのイメージをデプロイする先のsshのことを言ったんだが
てか、何を聞きたいのかあまりよくわからないんだけど質問は何？？

**デフォルトの名無しさん** · 2017/10/22(日) 01:45:26.64

>>279
sshの話なんて質問してないけど？
何勘違いしてるのさｗｗｗ

質問は
> どころで普段、端末からdocker使えるか？
> docker build -t tag . とか
> docker run -it debian /bin/bash
> みたいなのそらで打てるか？

これだけだろ

意図は>>271に書いたとおりだ

ansibleを使っている人ならわかる。ansible用に翻訳作業が必要で
モジュールが存在しない場合もあるし、オプションに対応してない場合もある。
そこまで苦労してansibleを使うものではない

**デフォルトの名無しさん** · 2017/10/22(日) 01:46:45.43

>>278
ああ、シェルスクリプトを保存すれば、ansibleなんて最初からいらんかったんや！ってこと？
シェルスクリプト書くの面倒くさいからansible使うんじゃないの？
なんとなく目先のコスト的には、コマンド直打ち<<<ansibleのplaybook<<<<<シェルスクリプトって感じだが
ワンライナー魔術師とかシェル芸が得意な人はシェルスクリプトのほうがいいんじゃないか？

**デフォルトの名無しさん** · 2017/10/22(日) 01:50:20.46

>>280
ごめん
>>264が質問と思ってた
シェルスクリプトの救済がどうのこうのということの意味がわからなくて混乱しただけ

回答は>>281ね

**デフォルトの名無しさん** · 2017/10/22(日) 01:51:34.75

思うんだけどansibleって構成管理ツールとかいう名前じゃなくて
リモートコマンドランチャーって呼んだ方が正確なんじゃないだろうか？

リモートマシンでコマンドを実行できます。
コマンドがよくわからない人のために、YAML形式で
コマンドの実行オプションを指定できます。

ほら、正確じゃない？

**デフォルトの名無しさん** · 2017/10/22(日) 01:53:08.56

ちなみにansibleはやたらモジュールあるけど、
俺が使うのは、さっきあげたdocker_imageとか、他はapt、pip、npmとかくらいだから、
モジュールが対応してないようなことをしない

**デフォルトの名無しさん** · 2017/10/22(日) 01:53:25.28

>>281
> シェルスクリプト書くの面倒くさいからansible使うんじゃないの？

それが理解できない。

シェルスクリプト = 普段実行してるコマンドの羅列
なわけで、誰しもシェルスクリプトに書く内容を
すでにシェル上で実行してるはず。
それをコピペするだけだよ。

**デフォルトの名無しさん** · 2017/10/22(日) 01:54:37.14

>>283
リモートコマンドランチャーで、いいんじゃない？
コマンドがわからんけど、playbookは書けますみたいな人はいないと思うが

**デフォルトの名無しさん** · 2017/10/22(日) 01:54:58.86

>>284
> 俺が使うのは、さっきあげたdocker_imageとか、他はapt、pip、npmとかくらいだから、
> モジュールが対応してないようなことをしない

それならばなおのことシェルスクリプトで良いと思うけど
ワンライナー魔術師とかシェル芸なんて使う必要ないし。

シェルスクリプト？
「普段あなたが書いていることを書くだけです」

**デフォルトの名無しさん** · 2017/10/22(日) 01:58:28.76

>>285
それはちがくね？
ローカルでdockerとかだったら、コンテナが起動済みかどうかしらべてとかするでしょ
それをawkとif文とかを使って書くよりは、state: presentのほうが楽だろ

あと、レビュアーがシェルスクリプトわからんときには、YAMLのほうが読んでもらいやすいかも
どっちでも一緒かもだけど

**デフォルトの名無しさん** · 2017/10/22(日) 02:00:51.58

>>286
リモートコマンドランチャーはシェルスクリプトも実行できるから
メインの処理はシェルスクリプトで書くといいだろうね。

そうするとDockerfileでも使えるし、Vagrantでも使える
クラウド上にVMインスタンスを立てるときも
スタートアップスクリプトを設定できて
シェルスクリプトが実行できる。

シェルスクリプトだと応用範囲が広い

**デフォルトの名無しさん** · 2017/10/22(日) 02:00:53.35

>>287
まぁシェルスクリプトでかけと言われれば書けるよ
それこそ逆翻訳だから面倒ってだけ

それを踏まえて最初の質問に対する答えだが、どっちにもメリットもデメリットもないよ
できることは同じだから好きな方で書けば良い

**デフォルトの名無しさん** · 2017/10/22(日) 02:04:02.78

>>289
いやメインの処理だけスクリプト化ってのはわけわからんから、なるたけどっちかに寄せたほうがいいよ
君の開発環境がわからないのでなんともいえないが、ansibleのモジュールが対応してない複雑なことをすることが多いなら
技術選択としてansibleを選ばないほうがいい

ansibleだとできることが増えるとかじゃないから、気にしないほうがいいんじゃね？
世の中に流される必要もあるまい

**デフォルトの名無しさん** · 2017/10/22(日) 02:15:02.98

>>288
> ローカルでdockerとかだったら、コンテナが起動済みかどうかしらべてとかするでしょ
> それをawkとif文とかを使って書くよりは、state: presentのほうが楽だろ

いや別に？それってstate: presentを誰かが作ってくださってるから
簡単にできますってだけだろ？そこで対応してないのはお手上げだろ。
そういう用意されてるものを使う、自分では作れないっていう精神がだめなんだよ。

awkなんかいらん。docker ps や docker inspect 使えばできるだろ。
そんなコマンド使えませんとか言うのなら話は別だがｗ

よく使うのであれば、自分で新たなコマンドを作れる。
コンテナが起動済みか調べて起動するコマンドだって作れる
普段使ってる言葉で簡単にね。

**デフォルトの名無しさん** · 2017/10/22(日) 02:15:46.33

>>291
> いやメインの処理だけスクリプト化ってのはわけわからんから、なるたけどっちかに寄せたほうがいいよ

だからansibleはいらんなーって話

**デフォルトの名無しさん** · 2017/10/22(日) 02:21:35.35

お前人にモノ聞く態度と違うぞ
いらんなら使わなきゃいいだけだろ
物議を醸したいのなら質問の体を取るな紛らわしい
夜中に一生懸命説明して損したわ

**デフォルトの名無しさん** · 2017/10/22(日) 02:22:31.17

>>291
> ansibleだとできることが増えるとかじゃないから、気にしないほうがいいんじゃね？

逆にできることが減るしねｗ

1. CLIコマンド（普段使用してる）
↑
2. ansibleモジュール（YAMLからCLIコマンドへの変換レイヤー）
↑
3. YAMLファイル（新たに覚える必要があるもの）

3.で無駄な努力をして、2.の機能不足やバグでトラブルにあって、
やっと普段使用してる1.にたどり着く。ムダ以外の何物でもない

**デフォルトの名無しさん** · 2017/10/22(日) 02:23:28.20

>>294
> お前人にモノ聞く態度と違うぞ

そりゃ教える方だからね
教授が学生に質問しているのは
わからないから聞いてるんじゃないですよ？ｗ

**デフォルトの名無しさん** · 2017/10/22(日) 02:27:12.80

結構スレの前半からいる変わった人なのか
何を教えてるつもりやねん…怖すぎ
2ちゃんで久々に書き込んでつかれた…

**デフォルトの名無しさん** · 2017/10/22(日) 02:34:15.72

5ちゃんねるな。
間違えんな

**デフォルトの名無しさん** · 2017/10/22(日) 04:16:07.34

Dockerはコンフィグの体じゃなくて
スクリプト化して、プロビジョン機能をもたせるべき
言語はGoがいい。
そしてジョブ管理機能をサポートして、Jenkinsとの親和性
を良くするべき。
つまり、コンテナだけじゃなくてプロビジョン、CI, ジョブ制御
全部Docker基盤でサポートできるようなれば超便利。
JenkinsはそのUI窓口を担当する。

2017/10/22(日) 09:20:56.40

>>292
用意されていればそれを使えば簡単、無ければ自分でshellコマンドを書く、でいいんじゃないの？
「そこでshell使うなら最初から全部shellで書けばいいじゃん」てのは極端だと思うが。

2017/10/22(日) 09:46:37.52

オープンソースのパッケージはリスクがある(npm left-pad)

2017/10/22(日) 09:58:24.68

AnsibleはWindowsにインストールできない
Linux仮想環境にAnsibleを乗せて実行など
やりたいことに対して迂遠すぎる

2017/10/22(日) 10:37:36.90

windowsなんてだいぶ前に使うのやめたけど、そもそもpythonまともに使えるようになったのけ？
pyenvすら使えないと聞いて震えた記憶があるが

2017/10/22(日) 12:02:17.34

>>300
> 用意されていればそれを使えば簡単、
別に簡単になってないので意味が無いんだよなｗ

2017/10/22(日) 12:05:05.65

>>303
> pyenvすら使えないと聞いて震えた記憶があるが

pyenvはPythonで作られていない。
シェルスクリプトで作られたシェル環境を操作するツールだ。

2017/10/22(日) 12:05:10.25

なんていうかね茶碗で飯食うのに箸を使うべきなんだけどブルドーザーで食おうとしてる
Ansibleってそんな感じ

2017/10/22(日) 12:27:30.62

>>304
言うことがころころ変わると会話にならんなぁ。

>いや別に？それってstate: presentを誰かが作ってくださってるから
>簡単にできますってだけだろ？そこで対応してないのはお手上げだろ。
>そういう用意されてるものを使う、自分では作れないっていう精神がだめなんだよ。

とりあえず、 ID:sDdgCD4Q はansibleよりshell scriptの方が簡単だと思っているからansibleを使わないわけだな。
で、ansibleを使う人はansibleの方が簡単だと考えているからそれを使うんだと思うよ。
それを「いや違う」と言ってみたところで、その人にとってshell scriptの方が簡単になるわけでもあるまい。

2017/10/22(日) 12:32:39.03

>>307
文章を途中だけぶち切って
俺の言いたいことを改変するなって

俺が簡単になってないというのは
シェルスクリプトをYAMLに翻訳しても簡単にはならないという話だ。

誰かが作った「機能」はそりゃ簡単になるだろ。
state: present相当の機能をシェルスクリプトで書けばいい。

それをYAMLに翻訳しても簡単にならないって話だ。

2017/10/22(日) 12:36:44.25

>>307
> とりあえず、 ID:sDdgCD4Q はansibleよりshell scriptの方が簡単だと思っているからansibleを使わないわけだな。

違う。シェルスクリプト語をYAML語に翻訳する作業が"無駄"だと言ってるんだよ。
誰しもシェルでコマンドうってやってる作業なんだから、
それを羅列してシェルスクリプトにしたほうが楽

わざわざYAML語に翻訳して、その結果、モジュールが対応してない機能が
使えなくなってモジュールのバージョンアップやバグに翻弄され、
最終的に対応してない機能はcommand moduleを使って
シェルで打ってるコマンドを書くことになる。

無駄な作業以外のなにものでもないよ

2017/10/22(日) 13:11:45.52

shellの方が簡単っていうけどインベントリの管理とか出力の整形とかめんどくさいこと結構あるだろ
その辺shellでどうやって解決してんのかね

2017/10/22(日) 13:18:05.46

>>310
ここに書いてあるとおり

274 名前：デフォルトの名無しさん[sage] 投稿日：2017/10/22(日) 01:30:08.38 ID:sDdgCD4Q [5/21]
もちろんansibleにもメリットは有るよ。
今となってはさほど意味がなくなったが冪等性や
複数台のマシンに対して同じ/異なる設定を送り込むとか

でもさ、コマンド実行部分をYAMLで書けるようにする
そのためのラッパー（モジュール）が大量に必要。
これは失敗だったね。

2017/10/22(日) 13:32:14.70

>>311
うんだからshellでやるときはどうやってるの？

2017/10/22(日) 13:33:20.73

>>312

>>306が書いてくれてる
> なんていうかね茶碗で飯食うのに箸を使うべきなんだけどブルドーザーで食おうとしてる
ブルドーザーはいりません

2017/10/22(日) 13:34:06.07

>>313
そうだね
shellでやるときはどうやってるの？
なんで答えてくれないのかな？
できないの？

2017/10/22(日) 13:42:05.98

>>314
なんで使わない機能を実装しないといけないの？

まあインベントリなんてホスト名をfor文でぐるぐる回すだけのことだけどｗ
知ってるかい？sshは後ろに実行するコマンドを書けるんだぜ？ｗ

2017/10/22(日) 13:59:07.78

>>315
forループぐるぐるって…
その程度の認識なら話にならんな

2017/10/22(日) 14:38:57.87

>>316
反論が有るなら、何がダメか言えよｗ

2017/10/22(日) 15:06:15.12

インベントリとfor文ぐるぐるは全然違うだろ

2017/10/22(日) 15:09:45.98

>>318
その程度の認識なら話にならんなｗｗｗ

2017/10/22(日) 15:10:57.95

お前の言った言葉が何の反論にもなってないのがわかったか？

違うなら何が違うのか言えと何度言わせる気だ？

2017/10/22(日) 15:18:53.39

幼稚

2017/10/22(日) 15:20:22.95

なんで答えてくれないのかな？
できないの？

2017/10/22(日) 15:21:55.05

違いすぎて何を書けばいいのか
インベントリはデータベースに近い構造で、配列とは全然違う
あえてかんたんに言うなら配列の要素に複数の属性をもたせたものだから、表現力が全く違う

2017/10/22(日) 15:24:27.36

>>323
ファイル形式の話かよｗ話しにならんな。
本当にやりたいことを書けよ
お前はそのファイル形式じゃなきゃ絶対ダメなのか？

2017/10/22(日) 15:26:10.75

当たり前だが、
ホスト名の一覧にオプションをつけることなんざ
シェルスクリプトでも簡単にできる。

hostname1 -a 1 -b 2 -c 3
hostname2 -a 11 -b 22 -c 33

というファイル形式でもそれ以外でもどうにでもなる。

2017/10/22(日) 16:02:34.59

グループ分けもしたい
パラメータは外部ファイルで整理したい
スイッチは読みにくい
ホストが増えてきたら動的にホスト情報をスクリプトで取得したい
静的な情報からスクリプトへの移行も手間無しでスムーズに行いたい
セキュリティ情報を扱うので暗号化もサポートしたい
テンプレートエンジンも欲しい
…

あげてくとキリがないな
シェルだけでやってるならたいしたものだよ
実際には要求が簡素なだけなんだろうけど

2017/10/22(日) 16:25:26.00

> グループ分けもしたい
ファイル、ディレクトリごとに分ければいい

> パラメータは外部ファイルで整理したい
外部ファイルから読み込めばいいだけ

> スイッチは読みにくい
読みやすい形式に変更すれば良い

> ホストが増えてきたら動的にホスト情報をスクリプトで取得したい
標準入出力で別スクリプトの出力結果を使用すればいいだけ

> 静的な情報からスクリプトへの移行も手間無しでスムーズに行いたい
script.sh hostname1 hostname2 hostname3
↓
script.sh $(dynamic.sh)

> セキュリティ情報を扱うので暗号化もサポートしたい
openssl コマンドと openssh のid_rsa で暗号化と復号化
http://takuya-1st.hatenablog.jp/entry/2015/08/12/002349

> テンプレートエンジンも欲しい
envsubstを使ってShellでテンプレートエンジン的なことをする、
http://blue1st-tech.hateblo.jp/entry/2016/07/25/001123

Bashでテンプレートエンジン{{Mustache}}を使ってみる
https://qiita.com/laqiiz/items/baa87183838351e4778c

他ERBでもなんでも好きなのを使え

2017/10/22(日) 16:27:19.06

そこまでいくと逆にシェルにこだわりすぎて、生産性落ちてるだろｗｗｗ