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

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

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

よろしこ

**デフォルトの名無しさん** · 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

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

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

別に？それぞれ1行～数行で書ける程度

2017/10/22(日) 16:29:07.05

しかもテンプレートエンジン使うのに他ツール使っちゃだめでしょ？
できることの幅が狭まるし、そのツールの学習コストがあるんだからｗｗｗ
ぜんぶ自分で書いたシェルでやりなさい！ｗｗｗ

2017/10/22(日) 16:33:25.41

> しかもテンプレートエンジン使うのに他ツール使っちゃだめでしょ？
シェルスクリプトにこだわるなら普通に
ヒアドキュメントの文字列展開を使えばいいと思うけど？

普段使ってるテンプレートエンジンを使えば良いんやで？
普段やってることをAnsible語に置き換えるのが無駄だって話なんだから

2017/10/22(日) 16:35:45.41

ってやるとめんどくさいじゃん

ファイル管理ディレクトリ管理を作らなきゃならない
外部ファイル読みこみも書かなきゃいけない
読みやすい形式を考えて書き換えなきゃいけない
標準出力をパースしなきゃいけない
$(...)にいちいち置き換えなきゃいけない
opensshに明に依存しなきゃいけない(シェルだけでやるんじゃなかったの？)
神社以外の新しいテンプレートエンジンに依存しなきゃならない(シェルだけでやるんじゃなかったの？)

シェルだけでできるって話だったのに
いきなり依存するものが出てきて困惑
シェルだけでできてないじゃん
そんなの覚えるのめんどくさいよね
Ansibleを覚えるのと何が違うんだ？

2017/10/22(日) 16:36:45.98

> しかもテンプレートエンジン使うのに他ツール使っちゃだめでしょ？
あとこれは考え方が間違ってる。

シェルスクリプトを使うということは、普段使ってるコマンドを使うということ
他のツールというか普段使ってるツールを使うってことだよ。
シェルスクリプトという言語は外部コマンド呼び出しとその連携に特化した言語なんだか
外部コマンドを使わないのは本末転倒

Ansibleという専用で応用範囲が狭いツールに置き換えるのをやめましょうという話

2017/10/22(日) 16:40:24.57

テンプレートエンジンはansibleが解決してくれるから、独自のツール導入したらもはやそれは普段打ってるコマンドでもなんでもないんですがそれは…

2017/10/22(日) 16:41:04.63

>>332
> ファイル管理ディレクトリ管理を作らなきゃならない
ディレクトリ作るコマンドはmkdir、ファイル作るコマンドは
適当なテキストエディタでも使えば終わりでしょｗ
普段やってないの？

> 外部ファイル読みこみも書かなきゃいけない
. ./file
一行ｗ

> 読みやすい形式を考えて書き換えなきゃいけない
普通にオプションでいいし、環境変数設定のやり方（AAA=123）で十分だろ
ちょっとしたことにブルドーザーを用意しようとするかなｗ

> 標準出力をパースしなきゃいけない
え？ Linux（Unix）っていうのはリダイレクトなどの機能で
ファイルも標準入出力も同じように扱えるんだよ

> $(...)にいちいち置き換えなきゃいけない
3文字のタイピングに何時間かかるのさｗ

> opensshに明に依存しなきゃいけない(シェルだけでやるんじゃなかったの？)
違いますね。普段シェルでやってることをそのまま使うってことですよ？
言いましたよね。Ansible語に置き換えるのが無駄だと。（何回目だろｗ）

> 神社以外の新しいテンプレートエンジンに依存しなきゃならない(シェルだけでやるんじゃなかったの？)
普段使ってるテンプレートエンジンをどれでも自由に簡単に使える。
Ansible語に置き換えるのが無駄

2017/10/22(日) 16:41:22.04

結局ちょっと難しいことしようとするとシェルじゃ太刀打ちできないってことか
シェルで全部やるというかシェルでお気に入りのツールを組み合わせるってだけなのね
んでそれを学習コストなしとみなすいわば屁理屈
少し期待してたけどガッカリ

2017/10/22(日) 16:42:13.48

>>332
> シェルだけでできるって話だったのに

普段シェルで叩いてるコマンドをそのまま使えるって話だって
何度も言ってる。

な？シェルはCLIコマンドなんでも使えるんやで？
Ansibleはモジュールで提供されている機能だけや。

YAMLに置き換えて、普段やってることができなくなるんだよ。
無駄以外のなにものでもない

2017/10/22(日) 16:44:19.17

>>336
> んでそれを学習コストなしとみなすいわば屁理屈

そりゃそうだろｗ

シェルは普通誰でも使ってるだろ。
プロビジョン相当のことを、手動（シェルから）でやらないのか？

普段やってることを、単純にYAMLに置き換えるだけだから
無駄な学習コストだよ。それでいてシェルからやってることに比べ
できることが減るんだからな。減るだけじゃない
モジュールの対応してる機能やバグでトラブルが増えてるだけ

何度もその姿見てるわ。無駄なことやってんなーって思ってる。

2017/10/22(日) 16:45:00.82

>>337
ansibleはcommndもshellモジュールもあるから、シェルの完全な上位セットだよ
ansibleでできることがシェルでできないことはあるけど逆はない

2017/10/22(日) 16:45:40.96

>>339
> ansibleはcommndもshellモジュールもあるから、シェルの完全な上位セットだよ

で、その結論はどうせshellモジュール使うんだから
シェル使えばいい。

2017/10/22(日) 16:47:41.88

>>339
> ansibleでできることがシェルでできないことはあるけど逆はない

できるできないじゃなくて、YAMLに置き換えるのが
無駄だって話だからね。何度も言うよ？ｗ

ansibleでできるならそれ相当の機能を作るか持ってくればいいので
シェルでできないことは何もないよ。

それにansibleで "できないこと" はshellモジュール使うんでしょ？ｗ

2017/10/22(日) 16:48:03.31

>>338
お前はお前で、ansibleでできることをつらつらshellで書いてることを無駄だと思われてるよｗｗｗ
mkdirひとつとっても、そのディレクトリの存在確認いちいちするのなんて手でコマンド打つときはlsで目で確認だけど、
スクリプト化したらifディレクティブ書かなきゃいけない
普段やってることをシェルスクリプトに翻訳する作業のコストは完全無視なのが笑える
そのままスクリプトにすりゃ動くだろって動かねーっつのｗｗｗ
むしろシェルスクリプトの勉強からやり直しなさい

2017/10/22(日) 16:50:11.92

> mkdirひとつとっても、そのディレクトリの存在確認いちいちするのなんて手でコマンド打つときはlsで目で確認だけど、

え？

mkdir -p /foo/bar/baz って書けばいいだけじゃん。
なんでいちいち存在確認なんかしてんのｗｗｗ

2017/10/22(日) 16:51:57.39

そのディレクトリがもう存在してたら？
エラー吐くけど無視するってこと？
どんだけー

2017/10/22(日) 16:54:00.10

$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo

何度やってもエラーなんて出ませんねぇｗ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

2017/10/22(日) 16:55:08.53

ぴゃー！今まで確認してたー！必要なかったんか

2017/10/22(日) 16:57:38.59

さすがshell王子やで
これからもシェルで頑張ってくれ！

2017/10/22(日) 16:58:06.58

結局シェルスクリプトを過小評価して、簡単にできることをできないと思いこんで
より面倒なAnsibleに置き換えてただけか

2017/10/22(日) 17:00:00.38

その思い込みが今この瞬間に消え去ることはないので、これからもansibleで書きます
本当にありがとうございました

2017/10/22(日) 17:00:13.97

Ansibleに学習時間が取られるだけじゃなく
シェルの学習時間が減るのも問題だよな。

シェルは応用範囲が広いから（逆の言い方をすると）
デプロイだけじゃなく普段の作業でも使える。

つまりシェルに慣れておくと普段の作業も効率化できるわけだ

2017/10/22(日) 17:02:29.22

シェルでツールを組み合わせる
作る方からすると簡単だし柔軟性が高いのは事実だけどとにかくメンテナンスしにくい

シェルスクリプト自体がルーズすぎてメンテナンスしにくいってのもあるけど
それ以上に様々なツールを組み合わせること自体がメンテナンス性の悪化を爆発的に加速させる

普段から使ってるツールセットが関係者全員で同じになるってことはまずない
誰かが普段使ってるツールを使って書いたオレオレスクリプトは他の人からすると学習コストが非常に高い厄介な代物でしかない
それぞれが好き勝手に好きなツールを使うことを許してしまうと人数が増えた時に総学習コストは際限なく増えていく
Web系のルーズな人たちはこの辺に無頓着だよね

そうならないために普通の開発現場では使えるツールを限定する
限定するならアレコレ使うよりAnsibleのような目的に沿った全部入りが良い
その方が最終的に学習コストは低くなる

2017/10/22(日) 17:07:01.08

>>351
> 作る方からすると簡単だし柔軟性が高いのは事実だけどとにかくメンテナンスしにくい

ようやく話が戻ってきたかｗ

そのメンテナンス作業でやることがDockerを使うことで殆どなくなってきたんだよ。

デプロイで大変なのは実は構成管理ではなくて、アプリのデプロイ
アプリを動かすための環境づくり（言語やライブラリのインストールなど）が大変だった。

でもそれがDockerを使ってDockerイメージに全部入れ込むことで、
あとはDockerコンテナの機動スをする1行（ないし数行）で完結するようになった。

デプロイでやることが大幅に減ったから、もうシェルスクリプトで十分な時代になってるんだよ。

2017/10/22(日) 17:16:55.75

その1行ってのを試しに書いてみて

2017/10/22(日) 17:22:13.75

Dockerコンテナを起動する命令？
docker run --restart=always -d myapp
とかそんな感じ

2017/10/22(日) 17:28:37.91

>>352
残念だけど、そんな時代はまだ来てない
Dockerを禁止にしてり現場なんていくらでもある
Dockerを使うって発想すらない現場もまだまだ多い
自分のデスクトップが世界標準と考えてしまう視野の狭い若者は少なくないけど
君もそのひとりということだね
今の君のデスクトップが多くの現場で当たり前になる頃には、さらに進んだ技術が君のデスクトップに導入されているんだろう
そりゃ簡単だよな

2017/10/22(日) 17:30:01.29

シェルスクリプトで十分ということは否定しないが、

まだ時代が来ていないという話にすり替わったｗ

2017/10/22(日) 17:30:54.61

次は仮想環境の時代は来てないとか
クラウドの時代は来てないとか言うのかな？

単に遅れているだけだと思うけどｗｗ

2017/10/22(日) 17:30:55.70

>>356
すり替え？？？
時代が来たって言ったのは君だよ
それ否定しただけ

2017/10/22(日) 17:34:19.94

本当にあきれるほどに視野狭窄だね
よほど恵まれた環境で飼われているのか
あるいは、もしかして、IT業界の人間じゃない？

2017/10/22(日) 17:34:46.23

>>358
いまDockerの時代が来ているかどうかって
話はしてないのでね

Ansibleはいらない。シェルスクリプトで十分って話。

お前が言ったのは
Ansibleはいらない。シェルスクリプトで十分だけど
俺の会社にはDocker導入されとらんのじゃー！
ってこと

それは技術じゃなくてお前の会社の問題

2017/10/22(日) 17:38:08.26

docker使うだけで恵まれた環境のなのかｗ
まさか嫉妬されるとは思わなかった。

2017/10/22(日) 17:42:02.16

ついこの間読んだ記事

Rocro株式会社の導入事例：GAE + GKE をフル活用し、高品質な開発者向け SaaS サービスをソニーグループである Rocro株式会社が少数精鋭で開発・運用
https://cloudplatform-jp.googleblog.com/2017/10/GoogleCloudPlatform-Rocro-GAE-GKE-SaaS.html

GKEっていうのはdockerを使うのが前提となってるんだけど
こういうのどうするのさ？

2017/10/22(日) 17:56:15.83

>>360
君の言う「シェルで十分」はdockerに依存してるんだろ？
まだまだdockerは普及してないのだから君の言う「シェルで十分」の時代も来てないってこと
使われてる現場もあるってだけで時代が来たっていうなら何も言わんが、時代が来たってそういうニュアンスじゃないと思うぞ

>>361
そう
君の知らない世界が無限に広がってる

>>362
その事例も同じ
使われてる現場もあるってだけ
これからじわじわ増えて来て当たり前のように使われる時代くるんだろう
でもそれは未だ来ていない

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

>>363
> 君の言う「シェルで十分」はdockerに依存してるんだろ？
依存はしてない。dockerを使わないシステムは有る
例えばAmazon RDSやGoogle Cloud SQLというデータベースサーバーとか
こういうのはすでにシステムが用意されてるのでそれを使うだけ

なのですでにAnsibleでデータベースサーバーを作るなんてのはやっていない
シェルどころか何も使わない

> 君の知らない世界が無限に広がってる
COBOLみたいなお仕事でしょ。
知ってるｗ

> でもそれは未だ来ていない
うちの会社ではすでに自社サーバーがほぼゼロ状態で
サーバーはクラウド化されてるのですでに来ている。

君の知らない世界に俺はいるようだ（笑）

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

これからじわじわ増えて来て当たり前のように使われる時代くるんだろう
そのときに備えてシェルスクリプトは使えるようになるべきだし、
Ansibleは次第に廃止されていく。
それは未来に生きてる俺が証明している

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

てかansibleの到来でシェルスクリプトが駆逐され、クラウドのAPI充実によってansibleが駆逐されていく感じだろ
俺からすればどっちも糞の山だわ

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

それはないんだわ。なぜならansibleはPythonがリモートに
インストールされていないといけないから。

通常コンテナには必要最小限のものしか入れないので
Python用コンテナでない限りPythonは入っていない。
必然的にシェルスクリプトしか使えない。

またdockerイメージの特徴はローカルでも動かせるという所だから
クラウドのAPIなんてのは意味がない。

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

>>367
うちはサーバーは全部ubuntuだからそこらへんはクリアしてんのかな？
てかpython入ってないサーバーなんて今時あんの？

てかDockerだのシェルだのansibleだのインフラ屋も大変だね
うちは、ビジネスサイドと開発選択して、ユニットテスト書いてコード書いて、pushすればステージ環境に勝手にデプロイされて、
POがステージ環境さわってマージされたら本番に勝手にデプロイされてって感じ
こっちからしたら、それができれば何使ってくれても構わんわ

インフラ屋って地味なイメージあるけど、やっぱ宗教論争があるんだな笑

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

あとAnsibleを死滅させる原因の１つにKubernetesがある。
Kubernetesが事実上の標準の座を手に入れるまでは
Ansibleを使ってオーケストレーションを行おうという動きがあった。

Kubernetesを使うことで簡単にDockerコンテナを実行できるわけだけど、
その方法としてコマンドラインのkubectlとREST APIがある。

Ansibleはまたコマンドランチャーとしての立場として
せっせとラッパーモジュールの開発を行っている

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

>>368
> てかpython入ってないサーバーなんて今時あんの？

busybox、alpine、CoreOS、Container-Optimized OS

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

>>368
> てかDockerだのシェルだのansibleだのインフラ屋も大変だね

勘違いしている人も多いが、Dockerはインフラ屋の道具じゃない。
アプリ開発側が、アプリのイメージ（＝Dockerイメージ）を作って
インフラ屋に「これ起動して」って渡すもの

インフラ屋にいちいち動作するサーバー構成とか
必要な言語、バージョン、ミドルウェア等伝えるの面倒でしょ？

**デフォルトの名無しさん** · 2017/10/23(月) 00:50:40.93

sDdgCD4Q
シェルスクリプトは普通に面倒だよ
まず「コマンドベース」なのが可読性が汚くなる。
クォーテーション、オプション、セミコロン、各種コマンド展開
パイプ、リダイレクト記号
さらに「オプション」っていうのはテストコマンド中のオプション
とか普通のコマンドのオプションとか1文字だけで意味を理解するには
「シェルの仕様を暗記」していることが前提になる。
もちろん「シェルを散々やっている人」からすればそんなの身について
当たり前、って思うかもしれないけど、Ruby, Python, YAMLなんかに
比べれば「意味の通りやすさ」が段違い。
自分では当たり前のように書いてるシェルのコードが別の人から見たら
「わけわかんない秘伝のタレ」にしか見えないかもしれない、って
考えたことある?
DockerとかAnsibleみたいなツールは何も「既存で熟練した技術者」
のためにあるわけじゃないんだよ。
難解なコードは技術者が自分の立場を守るための参入障壁でしかない。
古参技術者のATフィールドみたいなもんだよ、そんなものはOSSによって
容易に破られる時代ってこと。

**デフォルトの名無しさん** · 2017/10/23(月) 01:04:48.03

あとあれだ、Docker要らない、シェルで十分って言ってる
やつは「コンテナ化」について全く言及してないだろ。
シェルで制御できるのはせいぜい「プロセス」「ジョブ」単位。
Dockerで制御できる「コンテナ」は「沢山のプロセス」をカプセル化
した「マシン」と「プロセス」の粒度の中間にある「サーバ(=コンテナ)」
という粒度が必要になってきたからDockerができたんだよ。
あとGitリポジトリと同じで「過去の状態に復帰できる」
コンテナの設定を「1ファイルとして外部に外出しできる」のも
シェルの守備範囲外。
シェルはどうやっても依存関係が生じてなかなか「1ファイル」とはいかない
だろ?

**デフォルトの名無しさん** · 2017/10/23(月) 01:07:56.87

> まず「コマンドベース」なのが可読性が汚くなる。
理由は？

> クォーテーション、オプション、セミコロン、各種コマンド展開
> パイプ、リダイレクト記号
何が問題なのか分からん。やりたいことが実現できれば十分だろ

> さらに「オプション」っていうのはテストコマンド中のオプション
> とか普通のコマンドのオプションとか1文字だけで意味を理解するには
> 「シェルの仕様を暗記」していることが前提になる。
シェルの仕様じゃなくて、普段自分で打ってるコマンドのオプションな。
あまり使わないものは俺はlong optionで書くようにしてるよ？一文字にこだわる必要はない。

> もちろん「シェルを散々やっている人」からすればそんなの身について
> 当たり前、って思うかもしれないけど、Ruby, Python, YAMLなんかに
> 比べれば「意味の通りやすさ」が段違い。
YAMLは形式、そこで使うオプションは結局覚えなきゃいけない。その分手間がかかる。

ってか本気のプログラミングをしないんだから、SQLでプログラムするのは
大変って言ってるようなもんだよ。シェルスクリプトは汎用言語じゃなくて
DSLに近いものなんだから、限られた用途で最高のパフォーマンスを出せばそれで十分

> 自分では当たり前のように書いてるシェルのコードが別の人から見たら
> 「わけわかんない秘伝のタレ」にしか見えないかもしれない、って
> 考えたことある?
それはansibleも一緒。使い込んでいくと結局機能が足りなくて自分でモジュールとか作って
自分で作ったものは冪等性が実現できてなくて～みたいになって苦しんでる姿を見てる。

> DockerとかAnsibleみたいなツールは何も「既存で熟練した技術者」
> のためにあるわけじゃないんだよ。
シェルスクリプトも「既存で熟練した技術者」のためにあるわけじゃないんだよ。
普段シェルで使ってるコマンドそのまま使えるから知識が応用できる

**デフォルトの名無しさん** · 2017/10/23(月) 01:18:21.36

>>373
> という粒度が必要になってきたからDockerができたんだよ。
ぜんぜん違うわｗお前Docker分かってないじゃないかｗ

https://www.docker.com/what-container
ここよめ面倒だからGoogleで日本語に翻訳したよ

> 開発、出荷、展開のための標準化されたユニットにソフトウェアをパッケージ化する
> コンテナイメージは、実行に必要なすべてのもの（コード、ランタイム、システムツール、
> システムライブラリ、設定）を含む軽量でスタンドアロンの実行可能なパッケージです。

「軽量でスタンドアロンの実行可能なパッケージです。」

ソースコードをコンパイルしてビルドすしたビルド生成物にさらにコード、ランタイム、
システムツール、システムライブラリ、設定をパッケージ化したものだ

複数のプロセスをパッケージ化したものじゃない。
静的リンクをさらに発展させてシステムライブラリまでをもリンクしたようなものだ。

> あとGitリポジトリと同じで「過去の状態に復帰できる」
いや？過去の状態に復帰するために使うことはまれ。
Dockerfileが同じでも全く同じイメージは作れない。
その時点で最新のディストリのパッケージが使われるから。
Makefileと同じで手順が残っていて1コマンド（ないし数コマンド）でビルドできるのが特徴

> コンテナの設定を「1ファイルとして外部に外出しできる」のも
> シェルの守備範囲外。
当たり前だろ・・・コンテナの設定を外出できるのはコンテナの機能だろ
なんでシェルの話とコンテナの話をごっちゃにしてるんだよｗ

> シェルはどうやっても依存関係が生じてなかなか「1ファイル」とはいかない
シェルが1ファイルとか誰も言ってないんだが？

**デフォルトの名無しさん** · 2017/10/23(月) 01:28:14.42

> した「マシン」と「プロセス」の粒度の中間にある「サーバ(=コンテナ)」

って言ってる時点で、

システムコンテナ（OpenVZなど）とアプリケーションコンテナ（Dockerなど）の
違いが分かってないとわかるんだよな。
コンテナ上で複数のプロセスを動かすとかさぁｗ

http://tokyodebian.alioth.debian.org/html/debianmeetingresume200912se8.html

> コンテナ型の仮想化技術というと有名なのは、 Solaris Containers や FreeBSD jail がありますが、
> Linux では Linux-VServer, OpenVZ*7 などがあります。いずれも既に使ったことがある方が多いのではないのでしょうか。
> lxc で提供されるサービスは、大きく分類してシステムコンテナと、アプリケーションコンテナの
> 2 つがあります。前者は、いわゆる OS まるごとの仮想化です。 init から起動して、仮想 OS の空間を提供します。
> 後者は、 chroot によるアプリケーションの分離に近いです。
> 単一アプリケーションを分離するだけなので、とても軽くシンプルなのが特徴です。

**デフォルトの名無しさん** · 2017/10/23(月) 01:32:54.85

>>375
成果物として生成したものから起動する
コンテナは「仮想マシン」みたいなものだから、
そのなかで稼働するプロセスをカプセル化しているって言う
表現は間違っていない。
視野がせまいのはドキュメントの表面的な字面だけを捉えている
お前の方。
使うのが稀だとしても「過去の状態に復帰できる」が担保されているのと
上手く行かないかもしれないというのでは差が大きい。
それに差分抽出、差分吸収もできる。
「1ファイル」であるということは移植性が高いということ。
シェルは内部に多数の外部スクリプト、コマンドなどを読み込むから
1ファイルではなかなか他のマシンに移植しにくい。
因みにシェルが役に立たないとは言っていない。
だけどDockerやプロビジョンツールを否定するのは無理がある。

**デフォルトの名無しさん** · 2017/10/23(月) 02:24:34.18

>>377
> コンテナは「仮想マシン」みたいなものだから、

だからそれが間違いだってーのｗ

仮想マシンって何かわかってるか？（物理）マシン、ハードウェアを
ソフトウェアで実装することで仮想的なハードウェアを作り出すものだよ。

コンテナはハードウェアをソフトウェアで実現している
わけじゃないので仮想マシンとは全く違うもの

（アプリケーション）コンテナがやってる仮想化っていうのは
カーネル部分だ。コンテナごとにカーネル部分を仮想的に作り出すことで
アプリケーションごとに独立したユーザーランドを提供することができる
アプリケーション専用に独立した実行環境を持てるんだよ。

同じ「仮想」という言葉が入っているから勘違いしてるのだろうが
コンテナは仮想マシンとは全く違う。「仮想」ではあるが「マシン」じゃない。
仮想メモリと仮想マシンに両方共「仮想」が入っているから
同じようなものだと勘違いしているのと同じレベルの間違いをしてる。

> 表現は間違っていない。
間違っている所は仮想マシンみたいなものと言う所と
複数のプロセスをまとめるというものだ。
やろうと思えばできなくはないが、アプリケーションコンテナであるDockerは
複数のプロセスをまとめたりしない。複数のプロセスを動かすのは
物理・仮想マシンの役目だ。

物理・仮想マシンで複数のプロセスを起動する
Dockerコンテナ１つはその複数のプロセスの１つにすぎない

**デフォルトの名無しさん** · 2017/10/23(月) 02:33:28.78

>>377
> 使うのが稀だとしても「過去の状態に復帰できる」が担保されているのと
担保されていない。イメージを消してしまったら二度と同じものは作れない。

> 「1ファイル」であるということは移植性が高いということ。
俺は「1ファイル」なんかにこだわってないが、
なんでお前はそれにこだわってるんだ？

別に「１ファイル」であることは移植性は高くない。
何を根拠にそんなこと言ってるんだろうか？
移植性がないC言語のソースコードを1ファイルにすると
移植性が高くなるとでも？意味がわからない。

> シェルは内部に多数の外部スクリプト、コマンドなどを読み込むから
> 1ファイルではなかなか他のマシンに移植しにくい。

移植しにくいのは他の「マシン」ではなくて他のOS（ディストリ）
コンテナはその部分を仮想化して、カーネル以外の部分を
全部アプリケーションにくっつけてしまう。

結局のところ別の実行環境に移植するっていうのは理論上は
互換性があっても完璧とはいえないんだよ。
だからコンテナを使うことで、カーネル以外の部分に同じものを使うことで
移植そのものをなくしてしまった。

DockerコンテナはLinuxカーネルでしか動かないって知ってるか？
使うOSは全部Linuxだ。だから移植しなくて良いんだよ。

なおAnsible使っても移植作業は大変だ。DebianとCentOSでapt-get、yum違いも有るし
パッケージ名の違いも有る。パッケージの中に入っているものも違う。それぞれ用意しないといけない。
Dockerイメージににはカーネルを除いた「Debian」部分も含まれるから
CentOSで、Debianベースのイメージが動かせる。移植作業が不要とはこういうこと

**デフォルトの名無しさん** · 2017/10/23(月) 02:34:50.00

>>378
お前は国語が理解できないんだと思う。
「犬は狼みたいなもんだ」といったら
それの違いを生息地帯とか餌の内容とかごちゃごちゃ並べて
批判するタイプ。
つまり、抽象表現とかメタファーを一切受け入れられない。
その証拠に、使っている言葉がどっかのドキュメントに書いてある
文言そのまんまコピってきたような文章書いてるな。
学力テストでは高得点取れそうだが、物事を設計するのは苦手そう
違うかい？

**デフォルトの名無しさん** · 2017/10/23(月) 02:38:08.54

>>380
何が言いたいん？言葉遊び？

お前は「猫」と「海猫」は同じようなもんと
言ってるんだが？

**デフォルトの名無しさん** · 2017/10/23(月) 02:44:12.55

っていうか言い返したいのはわかるが、
レスの内容に言及しないのは何なんだろうなｗ

**デフォルトの名無しさん** · 2017/10/23(月) 02:46:41.07

> 違うかい？

あぁ、そうだ、これ、関係ないくだらない質問ををしてそれに答えなかったら、
否定しなかったから認めたんだ。おまえは認めたんだー。わーって
言うための布石だこれ。見たこと有るｗ

くだらない質問だけど違うって言っておくよ。おまえを黙らせるために。
でも関係ない話だからそれ以外何も言うつもりはないよ。

このスレに関係ある話をしような？

**デフォルトの名無しさん** · 2017/10/24(火) 00:32:13.24

...お、おう。
久々に来たら面白い事になってんな。

**デフォルトの名無しさん** · 2017/10/24(火) 03:30:56.57

Docker、2016、オライリー

Chef実践入門 - コードによるインフラ構成の自動化、2014

**デフォルトの名無しさん** · 2017/10/24(火) 23:00:17.34

殆ど同じ内容のDockerfileなんだけどちょっとだけ変えたい場合ってどう書けばいいの？

FROM me/hoge:debug
COPY . /hoge
WORKDIR /hoge
RUN ./setup.sh --debug
ENTRYPOINT ["run.sh"]

FROM me/hoge:release
COPY . /hoge
WORKDIR /hoge
RUN ./setup.sh
ENTRYPOINT ["run.sh"]

似たようなのが沢山ある

**デフォルトの名無しさん** · 2017/10/24(火) 23:03:45.53

>>386
build-argつかえ

**デフォルトの名無しさん** · 2017/10/24(火) 23:18:00.24

>>387
👍