[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
92: 2018/02/02(金)08:59 ID:yFWv8+qQ(1) AAS
CoreOSはDocker利用を想定してたけどコレジャナイ残念OSだったので次はRancherOSあたりに期待してる
93: 2018/02/03(土)13:01 ID:3HQCIEUi(1) AAS
>>91
ヤフーの記事が、港のコンテナヤードの画像使ってて混乱したわw
94: 2018/02/03(土)15:14 ID:TzIPoha8(1) AAS
クジラの方のコンテナって言えば通じる
95(1): 2018/02/05(月)13:34 ID:k5aVtYPL(1) AAS
コンテナをビルドするとき Dockerfile 内で
RUN yum list
した結果を、ホスト側に残したいんだけど、なんか良い方法ないかな？
96(1): 2018/02/07(水)01:28 ID:G933ziiv(1) AAS
>>95
Debian 使いだから勘違いしてる可能性が高いけどこういう感じで tee とかリダイレクトじゃダメなの？
$ cat Dockerfile
FROM centos
RUN yum list installed | tee yum.list
$ docker build -t yumlist .
~~snip~~
$ docker run --rm yumlist head -n5 /yum.list
Loaded plugins: fastestmirror, ovl
Installed Packages
省3
97: 2018/02/08(木)17:41 ID:lNZDnl+7(1) AAS
>>96
便利なやり方が無いかなーと思って。
一度起動してその出力を回収する方法しかないね。
98(1): 2018/02/14(水)02:35 ID:XB7JYlAs(1) AAS
/var/lib/docker/tmp
/var/lib/docker/containers
→単純にtmpfsにできる
/var/lib/docker/overlay2
→ここをtmpfsにすると再起動で空になったとき整合性エラーでコンテナが起動できなくなる
→かと言ってtmpfsをupperとしてoverlayfs化しても別エラーが出る（恐らくlower側のハードリンクが作れなくなるため）
/var/lib/docker全体をtmpfsにすれば整合性もハードリンク問題も解決するけど
消費メモリが増えるのとanything-sync-daemonとかでバックアップの手間も増える
システム再起動後にコンテナ自動起動しないならsync不要だけどイメージダウンロードからやり直しになって鬱陶しかった
99: 2018/02/15(木)00:59 ID:m3isa15O(1) AAS
☆ 現在、衆議員と参議院の両院で、改憲議員が３分の２を超えて
おります。総務省の、『憲法改正国民投票法』、でググってみてください。
国会の発議はすでに可能です。日本の、改憲を行いましょう。
平和は勝ち取るものです。お願い致します。☆☆
100: 2018/02/15(木)12:06 ID:2MLB8/h1(1) AAS
>>98
その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる
短命コンテナをバンバン使い捨てるケースで .../docker/overlay2 にゴチャゴチャ置かれても
sync 前にすぐ消えたファイルやディレクトリは単に無視されてディスクには書き戻されなくなって安心
デフォの 5 秒だとちょっと早すぎるんだよな
欠点はもちろん不意の電源ダウンで指定秒数ぶんだけデータロストする可能性があることだけど
ノートだったり UPS あったり、吹っ飛んでもいいや的な状況なら sync-daemon 系も不要だから楽
俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後
Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた
101(1): 塩水 ◆1FrMT.vzQQ 2018/03/11(日)02:24 ID:hSBnN7Ry(1/15) AAS
dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
物理で構築してたPlaybookのTarget SectionにDocker使うよって一行追加すれば使えるし(厳密には使えるようにするまでに色々設定は必要だけど)、
仮にコンテナのデファクトみたいなものがDockerじゃなくなっても最悪SSHで接続さえ出来れば流用できるからこのやり方良いなと思ってるんどけど。
102: 塩水 ◆1FrMT.vzQQ 2018/03/11(日)02:25 ID:hSBnN7Ry(2/15) AAS
スマホのフリック入力慣れないな。。
103(1): 塩水 ◆1FrMT.vzQQ 2018/03/11(日)02:32 ID:hSBnN7Ry(3/15) AAS
クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
昔はVM作り直したり、スナップショットから復元したりしてたけど、今はそのマウス操作すら煩わしくなってしまってる。
104(1): 2018/03/11(日)02:47 ID:FdJN57de(1/12) AAS
>>101
使っていませんｗ
ansibleを使ってDockerイメージを作ると、Dockerのキャッシュが
効かなくてイメージ作るの遅くなるでしょ？その問題もう解決したの？
あとansible使うならイメージにpythonインストールされてないとダメなんだよね？
Dockerはalpineとかpythonすら入ってないイメージをベースとすることも有るからなねぇ
君にとっては役にたたない話かもしれないど、どうしてansible使おうと思ったのか？
質問していい？ >>101にも書いてあるけど他のコンテナに乗り換えたいときのためだけ？
俺は流用するならばシェルスクリプトが一番だと思ってるよ。
だってansibleで書いたYAMLって、ansible以外に流用できないでしょ？YAML書くのめちゃくちゃ手間だし
省2
105(1): 2018/03/11(日)02:55 ID:FdJN57de(2/12) AAS
>>103
> クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
君を煽るわけじゃなく、そういうのをやってる人見てると、ワロスワロスだよｗ
なに無駄に苦労しちゃってるの？って思う
Ansibleは実行検証が必要なほど信頼できないってことだからね
Ansibleは理想としては、クリーンな状態にしなくても、冪等性とやらで
書いてあるとおりになるはずなんだが、その理想は破綻してる。
書いてない部分がどうなるのかは不定だからplaybookを変更した時に
クリーンな状態からやったのと同じ状態になるとは限らない
いやもちろんシェルスクリプトも同じだよ。でも検証時にサーバーに乗り込んで
省3
106: 塩水 ◆1FrMT.vzQQ 2018/03/11(日)03:31 ID:hSBnN7Ry(4/15) AAS
すごい煽られててビックリしましたｗ
>>104
用途は
1. 公式OSイメージからコンテナを作る
2. 良い感じのコンテナになってたらイメージ化する
という感じです。
「2.」のイメージ作るとこは最終段階で、そう頻繁に行う作業ではないの
仮にイメージ一つ作るのに数十分かかったとしても、自分の用途に関してはそれほど問題はないです。
Ansibleを使おうと思ったのは、昔は動いてたけど今は動くなくなっているようなPlaybookでも
失敗した箇所がピンポイントでわかるのでメンテする気が起きるからです。
省5
107: 塩水 ◆1FrMT.vzQQ 2018/03/11(日)03:33 ID:hSBnN7Ry(5/15) AAS
今度は長文をPCから書き込んだらsage忘れた
2ch書き込みのブランクありすぎて色々ひどい。。
108: 塩水 ◆1FrMT.vzQQ 2018/03/11(日)03:47 ID:hSBnN7Ry(6/15) AAS
>>105
私も冪等性なんてあてにするものではないと思ってて、
Ansibleに限らず、そのほかのツールも検証してないものは信頼しないというのが私の基本スタンスです。
(特に、かなり昔に作った構築系スクリプトはそのまま実行して一回で動くとは思ってません。)
シェルスクリプトは構築コマンドそのまま列挙すればよいので便利なのですが、
例えばCentOSのOS基本設定入れてRuby入れてApache入れてアプリ入れて、
みたいな構築の場合、Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
例えば構築が失敗したとき、シェルスクリプト場合
何でコケたのか、どこでコケたのか、というのを探すところから始める必要がありますが
Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
109(1): 2018/03/11(日)04:16 ID:FdJN57de(3/12) AAS
あちこちで煽ってるけどようやくまともな意見を返す人が見つかったな
ふぉーん。ってことはシェルスクリプトでもどこで失敗したか
ピンポイントでわかれば問題ないってことじゃねーか。
あとは書き方が統一されていればいい
それなら解決可能な問題だな。っていうか俺の手元ではほぼ解決済みだ
> Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
> Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
それもほぼ解決済みだ
シェルスクリプトで解決可能なたったそれだけの問題のために
Ansibleみたいな内部で何が行われているかわからない
省4
110: 2018/03/11(日)04:26 ID:FdJN57de(4/12) AAS
Ansibleがブラックボックスツールということの
意味がわからない人がいるかもしれないから
軽く説明しておいてやろう
まずお前らは環境構築をしているよな？それが仕事だ
その仕事をしている最中に、Ansible関連でバグとか
モジュールが対応してなくてうまく動かない自体が発生した。
それらをお前らすぐになおせるの？
pythonを知っていたとしてもまず無理だろ？
重量級のAnsibleをブラックボックスで使ってるからな
でも本来のお前らの仕事である環境構築は
省3
111(1): 塩水 ◆1FrMT.vzQQ 2018/03/11(日)04:40 ID:hSBnN7Ry(7/15) AAS
なんかアドレスが5chになってる。いつの間に。。
>>109
言ってしまうと、自分のスクリプト力もあまり信頼してなくて、
今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
ベテランの人が自分で方針を決めて数年後でもメンテできるように書いていれば
その人は問題なく使えると思うのですが、他の人はそれを読めるかどうかというところですね。
Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
仕組みで自然とそのようなメンテがしやすい形にはなるのです。
ただ、ベストプラクティスもそのままだと実用としてどうなのというケースも多いので
現場に合わせてアレンジする作業は必須だと思いますが。
省7
上下前次1-新書関写板覧索設栞歴
あと 891 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.139s*