X
仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
垢版 |
2017/02/16(木) 18:01:04.48ID:rGWDv0Eb
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ
0232デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:02:24.19ID:zkU9oivG
.net使うにしても、dockerイメージを使えばデプロイは楽になるだろうね。
なぜなら、そのdockerイメージの中に.netランタイムまで入っているから。

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

Windows 10で最新の.netがインストールされていること
なんて制約はない。
0233デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:02:55.54ID:zkU9oivG
>>230
> .Netで完結します
遠吠えｗｗｗｗ

誰が、そんな説明で納得すると思ってんるんだ。
出直してこい
0234デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:03:35.60ID:uF51TTqU
ありとあらゆる条件が全く同等という保証がなければDockerだろうがなんだろうが実機テストは必要
それがテストってものだよ
手元の仮想環境と鯖の仮想環境はおんなじだ(だと思う)からテストはしなくていいなんてのは実社会では通用しないぞ
0235デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:04:51.34ID:lul59eSB
Dockerはwindowsだと10以降しか対応してなくね？
開発環境が窓っていう、かわいそうな現場は大半がまだ7だからdockerなんか動かないだろ
0236デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:06:43.75ID:zkU9oivG
>>234
あ、はい、時間とコストの問題です。（言わなきゃ分からんかな？）

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

可能か不可能かのはないをするのは実社会で通用しないぞ？ｗ
重要なのはどれだけコストが小さくできるかだ。
0239デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:10:45.14ID:uF51TTqU
>>236
おやおや
君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？
新しい技術を覚えたてで興奮する気持ちはわかるが発言は冷静になってからにしたほうがいいぞ
0240デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:12:34.46ID:zkU9oivG
ふむ。さすがマイクロソフト。
当然だが組み合わせて使うことの意味をちゃんと知ってるな。

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 がどのように役立つかを簡単に確認します。
0242デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:13:53.59ID:zkU9oivG
>>239
> 君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？

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

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

いえ「実機テストが必要ない」と書いてある文章を
示せるというのであれば、示して良いんですよ？ｗ
0244デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:17:10.24ID:zkU9oivG
コンテナー - 従来の .NET アプリを Docker で最新化する
https://msdn.microsoft.com/ja-jp/magazine/mt797650.aspx

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

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

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

継続的配置（配置＝デプロイ）がDockerは便利だってMSも認めてるね。
0245デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:18:45.25ID:uF51TTqU
>>242
自分のレスを冷静に見つめ直してごらん
あたかもテスト不要であるように取れる発言を何度もしてるよ
これから社会に出るのだろうし反省することも覚えたほうがいい
0247デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:23:50.11ID:zkU9oivG
>>245
> あたかもテスト不要であるように取れる発言を何度もしてるよ

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

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

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

さて、次はあんたの番だ。
0248デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:25:22.89ID:zkU9oivG
>>246
ID見ればわかるし、俺にコテを付けるメリットがない。
というか、５ちゃんねるでコテはつけないというは
俺の中でとっくの昔に決めたルールなので言うだけムダだｗ
0251デフォルトの名無しさん
垢版 |
2017/10/21(土) 13:46:47.12ID:uF51TTqU
>>122
＞だからローカルで開発で使用していたDockerイメージをそのまま
＞クラウドの仮想化サービス上に持っていくことができる。
＞その作業も単にdocker runするだけ

JavaのWOTAとの対比で語っちゃってるしこれはそうとしか読めんなぁ
0253デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:01:47.02ID:zkU9oivG
>>251
持っていくことができるよ？
持っていってテストするんだろ？
何を言ってるんだとしか思えんわｗ
0254デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:06:21.17ID:uF51TTqU
>>253
ん〜
ちょっと厳しいなその反論は
じゃあなんでJavaと対比したの？ってなるよね

Javaはwrite once, test everywhereのクソだけどそれに比べてDockerは〜
っていう文脈でしょ？
0255デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:18:41.57ID:zkU9oivG
>>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 を
実機で「全く」テストしなくていいという意味だって勘違してるなってわかったからだよ。
0256デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:21:12.73ID:zkU9oivG
結局、.NETも同じことになるんだろうな。

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

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

全く同じものを使うDockerの利点はそこに有る。
0257デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:24:16.29ID:uF51TTqU
>>255
残念だけどそう考えてるのは君だけだよ
君のレスを読んだ人は
あ、こいつDocker使えばテストいらんと思ってるな
と思うわけだ
社会に出たら人からどう見られるかってのも大切だから覚えておいてね
0258デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:31:43.74ID:zkU9oivG
まあ別の言い方で簡単に>>254がバカだって証明するならば

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

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

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

「どこでもテスト」の反対は「テストなし」ではない
「全て」の反対は「一部」であって「無」ではない
0259デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:33:36.33ID:zkU9oivG
>>257
> 君のレスを読んだ人は
> あ、こいつDocker使えばテストいらんと思ってるな
> と思うわけだ

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

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

お前が、他人の説明を間違って解釈して喚いていているやつってのは証明した。
社会に出たら人からどう見られるかってのも大切だから覚えておいてね
0260デフォルトの名無しさん
垢版 |
2017/10/21(土) 14:36:58.71ID:zkU9oivG
今回は見事論破（笑）できたから

> ちょっと厳しいなその反論は
と言えなかったんだろうなｗ
0261デフォルトの名無しさん
垢版 |
2017/10/21(土) 21:13:10.64ID:OISii71C
docker使うケースは頻繁なデプロイが前提だったり迅速なスケールアウトが必要だったりの事情があるはずで、
そういう場合に例えば速度面でVMより起動が速い事が一番のメリットだ、という理由があって使うんじゃねーの？
あと消費リソースがVMより少なくて済むとか。

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

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

テストにしても、ライブラリのバージョン依存のバグを本番環境でのテストまでに見つけられない方が問題なわけで、
ID:zkU9oivGが言いたいのは、そこのバグはもっと早期に潰してる前提でしょ？
テストなんて工程別に目的持ってやるもんなのに、全部ひっくるめて語るのは暴論だわな。
0262デフォルトの名無しさん
垢版 |
2017/10/21(土) 22:19:05.77ID:01fxNEyn
>>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はアプリケーションのイメージ化だ。アプリケーションにはマシンの構成が含まれないから
物理・仮想マシン関係なくどこででも動くんだ。ただの１つのアプリケーションだもの
0264デフォルトの名無しさん
垢版 |
2017/10/21(土) 22:27:51.08ID:01fxNEyn
そういやAnsible Containerってのができたんだっけｗ

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

シェルスクリプトが使えない人の救済用以外の
メリットがあるなら教えてください。
0266デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:00:55.77ID:0M1ELFL1
てかシェルスクリプト使えない人ってどゆこと？
窓ユーザーってこと？質問の意味がよくわからん…
0267デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:13:03.22ID:sDdgCD4Q
>>265
お、おう。
それはdocker buildコマンドを叩く代わりに
ansibleを使っているってだけの話だな。
dockerコンテナへのデプロイではなく

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

ansible使わないとコマンド打てないっていうんじゃ恥ずかしいぞ
0269デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:17:06.88ID:oq9fIgmy
buildもpushもpullもrunも全部ansibleでやるときあるよ

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

質問の趣旨は？？
0270デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:19:08.12ID:oq9fIgmy
>>268
え、設定ファイルってDockerfileをってこと？？
それをlineinfileとか使って動的生成する人ってことかな
そんな人いないと思うけど…
0271デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:23:02.03ID:sDdgCD4Q
>>269
そらでうてるものに対して対応するansibleの設定探すの面倒じゃないかなーって思って
それに例えばマイナー（？）なオプションbuild時にラベルつけたくなったらどうするの？とかさ
モジュール対応してないでしょ？
0272デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:27:52.52ID:sDdgCD4Q
ローカルでやるときはいちいちansibleは使わない

そうだよね。

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


それをansible言語に翻訳する作業ってすごく無駄な作業だと思う。
しかもローカルでやれることの一部しかできないし。
0273デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:29:40.83ID:oq9fIgmy
>>271
まぁ面倒っちゃ面倒かもな
俺はもうスニペット用意してるからそこまで手間でもないけど
--labelは使ったことないから、知らんけど、まぁどうしてもそうなったら仕方ないからcommnd module使うんじゃね？
0274デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:30:08.38ID:sDdgCD4Q
もちろんansibleにもメリットは有るよ。
今となってはさほど意味がなくなったが冪等性や
複数台のマシンに対して同じ/異なる 設定を送り込むとか

でもさ、コマンド実行部分をYAMLで書けるようにする
そのためのラッパー（モジュール）が大量に必要。
これは失敗だったね。
0277デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:39:10.45ID:sDdgCD4Q
>>273
やっとansible使ったことがありそうな人が来たｗ

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

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

さらにdockerはsshすら入ってない。（そもそもそういう使い方をするものじゃない）
でもshは入っている。だからDockerfileはシェルコマンドの頭にRUN付けただけ
みたいな、ほぼシェルスクリプトのやり方でイメージを作成する
0278デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:42:07.34ID:sDdgCD4Q
>>276

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

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

翻訳作業がいらないだけでなく、ansibleで書くよりも短く書けます。
実行するときもスクリプトファイル名を入力するだけです。
0279デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:42:40.90ID:oq9fIgmy
dockerにssh？？
dockerのイメージをデプロイする先のsshのことを言ったんだが
てか、何を聞きたいのかあまりよくわからないんだけど質問は何？？
0280デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:45:26.64ID:sDdgCD4Q
>>279
sshの話なんて質問してないけど？
何勘違いしてるのさｗｗｗ

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

これだけだろ

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

ansibleを使っている人ならわかる。ansible用に翻訳作業が必要で
モジュールが存在しない場合もあるし、オプションに対応してない場合もある。
そこまで苦労してansibleを使うものではない
0281デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:46:45.43ID:oq9fIgmy
>>278
ああ、シェルスクリプトを保存すれば、ansibleなんて最初からいらんかったんや！ってこと？
シェルスクリプト書くの面倒くさいからansible使うんじゃないの？
なんとなく目先のコスト的には、コマンド直打ち<<<ansibleのplaybook<<<<<シェルスクリプトって感じだが
ワンライナー魔術師とかシェル芸が得意な人はシェルスクリプトのほうがいいんじゃないか？
0282デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:50:20.46ID:oq9fIgmy
>>280
ごめん
>>264が質問と思ってた
シェルスクリプトの救済がどうのこうのということの意味がわからなくて混乱しただけ

回答は>>281ね
0283デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:51:34.75ID:sDdgCD4Q
思うんだけどansibleって構成管理ツールとかいう名前じゃなくて
リモートコマンドランチャーって呼んだ方が正確なんじゃないだろうか？

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

ほら、正確じゃない？
0284デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:53:08.56ID:oq9fIgmy
ちなみにansibleはやたらモジュールあるけど、
俺が使うのは、さっきあげたdocker_imageとか、他はapt、pip、npmとかくらいだから、
モジュールが対応してないようなことをしない
0285デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:53:25.28ID:sDdgCD4Q
>>281
> シェルスクリプト書くの面倒くさいからansible使うんじゃないの？

それが理解できない。

シェルスクリプト = 普段実行してるコマンドの羅列
なわけで、誰しもシェルスクリプトに書く内容を
すでにシェル上で実行してるはず。
それをコピペするだけだよ。
0286デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:54:37.14ID:oq9fIgmy
>>283
リモートコマンドランチャーで、いいんじゃない？
コマンドがわからんけど、playbookは書けますみたいな人はいないと思うが
0287デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:54:58.86ID:sDdgCD4Q
>>284
> 俺が使うのは、さっきあげたdocker_imageとか、他はapt、pip、npmとかくらいだから、
> モジュールが対応してないようなことをしない

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

シェルスクリプト？
「普段あなたが書いていることを書くだけです」
0288デフォルトの名無しさん
垢版 |
2017/10/22(日) 01:58:28.76ID:oq9fIgmy
>>285
それはちがくね？
ローカルでdockerとかだったら、コンテナが起動済みかどうかしらべてとかするでしょ
それをawkとif文とかを使って書くよりは、state: presentのほうが楽だろ

あと、レビュアーがシェルスクリプトわからんときには、YAMLのほうが読んでもらいやすいかも
どっちでも一緒かもだけど
0289デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:00:51.58ID:sDdgCD4Q
>>286
リモートコマンドランチャーはシェルスクリプトも実行できるから
メインの処理はシェルスクリプトで書くといいだろうね。

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

シェルスクリプトだと応用範囲が広い
0290デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:00:53.35ID:oq9fIgmy
>>287
まぁシェルスクリプトでかけと言われれば書けるよ
それこそ逆翻訳だから面倒ってだけ

それを踏まえて最初の質問に対する答えだが、どっちにもメリットもデメリットもないよ
できることは同じだから好きな方で書けば良い
0291デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:04:02.78ID:oq9fIgmy
>>289
いやメインの処理だけスクリプト化ってのはわけわからんから、なるたけどっちかに寄せたほうがいいよ
君の開発環境がわからないのでなんともいえないが、ansibleのモジュールが対応してない複雑なことをすることが多いなら
技術選択としてansibleを選ばないほうがいい

ansibleだとできることが増えるとかじゃないから、気にしないほうがいいんじゃね？
世の中に流される必要もあるまい
0292デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:15:02.98ID:sDdgCD4Q
>>288
> ローカルでdockerとかだったら、コンテナが起動済みかどうかしらべてとかするでしょ
> それをawkとif文とかを使って書くよりは、state: presentのほうが楽だろ

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

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

よく使うのであれば、自分で新たなコマンドを作れる。
コンテナが起動済みか調べて起動するコマンドだって作れる
普段使ってる言葉で簡単にね。
0293デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:15:46.33ID:sDdgCD4Q
>>291
> いやメインの処理だけスクリプト化ってのはわけわからんから、なるたけどっちかに寄せたほうがいいよ

だからansibleはいらんなーって話
0294デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:21:35.35ID:oq9fIgmy
お前人にモノ聞く態度と違うぞ
いらんなら使わなきゃいいだけだろ
物議を醸したいのなら質問の体を取るな紛らわしい
夜中に一生懸命説明して損したわ
0295デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:22:31.17ID:sDdgCD4Q
>>291
> ansibleだとできることが増えるとかじゃないから、気にしないほうがいいんじゃね？

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


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


3.で無駄な努力をして、2.の機能不足やバグでトラブルにあって、
やっと普段使用してる1.にたどり着く。ムダ以外の何物でもない
0296デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:23:28.20ID:sDdgCD4Q
>>294
> お前人にモノ聞く態度と違うぞ

そりゃ教える方だからね
教授が学生に質問しているのは
わからないから聞いてるんじゃないですよ？ｗ
0297デフォルトの名無しさん
垢版 |
2017/10/22(日) 02:27:12.80ID:oq9fIgmy
結構スレの前半からいる変わった人なのか
何を教えてるつもりやねん…怖すぎ
2ちゃんで久々に書き込んでつかれた…
0299デフォルトの名無しさん
垢版 |
2017/10/22(日) 04:16:07.34ID:Qk9RzJFk
Dockerはコンフィグの体じゃなくて
スクリプト化して、プロビジョン機能をもたせるべき
言語はGoがいい。
そしてジョブ管理機能をサポートして、Jenkinsとの親和性
を良くするべき。
つまり、コンテナだけじゃなくてプロビジョン、CI, ジョブ制御
全部Docker基盤でサポートできるようなれば超便利。
JenkinsはそのUI窓口を担当する。
0300名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 09:20:56.40ID:HAzBzhoi
>>292
用意されていればそれを使えば簡単、無ければ自分でshellコマンドを書く、でいいんじゃないの？
「そこでshell使うなら最初から全部shellで書けばいいじゃん」てのは極端だと思うが。
0307名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 12:27:30.62ID:HAzBzhoi
>>304
言うことがころころ変わると会話にならんなぁ。

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

とりあえず、 ID:sDdgCD4Q はansibleよりshell scriptの方が簡単だと思っているからansibleを使わないわけだな。
で、ansibleを使う人はansibleの方が簡単だと考えているからそれを使うんだと思うよ。
それを「いや違う」と言ってみたところで、その人にとってshell scriptの方が簡単になるわけでもあるまい。
0308名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 12:32:39.03ID:sDdgCD4Q
>>307
文章を途中だけぶち切って
俺の言いたいことを改変するなって

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

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

それをYAMLに翻訳しても簡単にならないって話だ。
0309名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 12:36:44.25ID:sDdgCD4Q
>>307
> とりあえず、 ID:sDdgCD4Q はansibleよりshell scriptの方が簡単だと思っているからansibleを使わないわけだな。

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

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

無駄な作業以外のなにものでもないよ
0311名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 13:18:05.46ID:sDdgCD4Q
>>310
ここに書いてあるとおり

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

でもさ、コマンド実行部分をYAMLで書けるようにする
そのためのラッパー（モジュール）が大量に必要。
これは失敗だったね。
0315名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 13:42:05.98ID:sDdgCD4Q
>>314
なんで使わない機能を実装しないといけないの？

まあインベントリなんてホスト名をfor文でぐるぐる回すだけのことだけどｗ
知ってるかい？sshは後ろに実行するコマンドを書けるんだぜ？ｗ
0323名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 15:21:55.05ID:JYWPd5df
違いすぎて何を書けばいいのか
インベントリはデータベースに近い構造で、配列とは全然違う
あえてかんたんに言うなら配列の要素に複数の属性をもたせたものだから、表現力が全く違う
0325名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 15:26:10.75ID:sDdgCD4Q
当たり前だが、
ホスト名の一覧にオプションをつけることなんざ
シェルスクリプトでも簡単にできる。

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

というファイル形式でもそれ以外でもどうにでもなる。
0326名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 16:02:34.59ID:JxzBgWl2
グループ分けもしたい
パラメータは外部ファイルで整理したい
スイッチは読みにくい
ホストが増えてきたら動的にホスト情報をスクリプトで取得したい
静的な情報からスクリプトへの移行も手間無しでスムーズに行いたい
セキュリティ情報を扱うので暗号化もサポートしたい
テンプレートエンジンも欲しい
…

あげてくとキリがないな
シェルだけでやってるならたいしたものだよ
実際には要求が簡素なだけなんだろうけど
0327名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 16:25:26.00ID:sDdgCD4Q
> グループ分けもしたい
ファイル、ディレクトリごとに分ければいい

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

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

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

> 静的な情報からスクリプトへの移行も手間無しでスムーズに行いたい
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でもなんでも好きなのを使え
0330名無しさん＠そうだ選挙に行こう！ Go to vote!
垢版 |
2017/10/22(日) 16:29:07.05ID:JYWPd5df
しかもテンプレートエンジン使うのに他ツール使っちゃだめでしょ？
できることの幅が狭まるし、そのツールの学習コストがあるんだからｗｗｗ
ぜんぶ自分で書いたシェルでやりなさい！ｗｗｗ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況