Docker Part2

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

やっぱubuntu + kubernetesがいいのかな

いつの話？

なんぱい？

クジラの方のコンテナって言えば通じる

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

PTHNS6LLYQ

なんかlinuxがいいものになったかのような錯覚をおこすわ

そうだね
前スレからそのまま持ってきてしまったか

Linux板で言うことじゃないかもしれないけどWindowsでもHyper-Vで使えるようになってたんだな
Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ

さて、ここまではパソコンにインストールされたものがLinuxの場合だけど
WindowsやMacOSはどうなっているのか？

コンテナ機能っていうのはLinuxカーネルが持っている機能だが
WindowsやMacOSはLinuxではない。
どうやってLinuxのカーネルの機能を使っているのか？

答えを言ってしまえばあたり前のことだが、WindowsやMacOSでは
裏で仮想マシンが起動していてLinuxがインストールされている

ちょっと前までの、Docker Toolboxと呼ばれていた時代はVirtualBoxを使っていた。
今のDocker for Windows および Docker for Macでは
WindowsではWindows標準のHyperVを
MacOSではMacOS標準のHypervisor Frameworkを利用したHyperKitを使っている

仮想マシンを使っていると言ってもDockerに最適化されており
Windows もしくは MacOS のCUIからdockerコマンドを動かすとちゃんと
使えるように構成されており、まるでLinuxと同じようにOSの上に直接dockerが
起動しているようにみえる。だけど実際は仮想マシン上で動いているので
Dockerの設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する

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

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

＞WindowsでもHyper-Vで使えるようになってた
Windows以外で使えるHyper-Vなんてあるの？

user mode linuxはコンテナに入りますか?

CoreOSはもうねぇだろ

パッケージ管理ツールをLSB前提でpythonやperlで書いてたところは
それが原因でコンテナイメージのサイズをある一定以下に削減できなくてイーッてなってた

かと言ってパッケージマネージャーは各ディストリのシステムに根深く食い込んでるから
切り離そうにも切り離せない・・・最近じゃsystemdの呪縛もあるだろうし

でもまさかパッケージを単品ごとにインスコする日が来るとは誰も思ってなかったんだよな結局は

WindowsやMacOSで使った時のDockerのボリュームって謎だよね

例えばWindowsでdockerコマンド使った時、Windowsのディレクトリを
ボリュームとして指定すれば、dockerコンテナの中から見える

Linuxでは当たり前の動作だけど、WindowsやMacOSでは仮想マシンで
dockerが動いてるのだから、単純に考えれば仮想マシンの中にボリュームができるはず

まあホストOSのディレクトリを仮想マシンのディレクトリにマッピングしてるんだろうけど
Docker for WindowsやDocker for Macではそういうことを感じさせない作りになってる

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

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

/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不要だけどイメージダウンロードからやり直しになって鬱陶しかった

誰もがWindows Proを使えるわけじゃないからなぁ
VirtualboxベースのDocker toolboxはまだ必要意義は大きい

コンテナは昔からあっただろ
Linuxに来るのが遅かっただけで

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

GUIいらないからホストOSも軽くて無駄がないalpineにするのが好き
ほとんど何もできないから逆に後腐れなく気軽に捨てて新しくできるし！

俺はホストにはfedora atomic使ってるぞ

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

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

未だにコンテナとchrootの違いが理解できない

ホストのカーネルを使っているという説明で合っているよカーネルの上で動かすカーネルとかもうそれVMじゃん

docker imagesってやったらどうでるの？

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

>>22-23
枯れたOSでよく話が通じるな？
対応OS書いてあるんだから、それ使うだけじゃん

https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/
Artful 17.10 (Docker CE 17.11 Edge only)
Zesty 17.04
Xenial 16.04 (LTS)
Trusty 14.04 (LTS)

https://docs.docker.com/engine/installation/linux/docker-ce/debian/
Buster 10 (Docker CE 17.11 Edge only)
Stretch 9 (stable) / Raspbian Stretch
Jessie 8 (LTS) / Raspbian Jessie
Wheezy 7.7 (LTS)

https://docs.docker.com/engine/installation/linux/docker-ce/centos/
To install Docker CE, you need a maintained version of CentOS 7. Archived versions aren’t supported or tested.

https://docs.docker.com/engine/installation/linux/docker-ce/fedora/
25
26

https://docs.docker.com/engine/installation/linux/docker-ee/rhel/#prerequisites
To install Docker EE, you need the 64-bit version of Red Hat Enterprise Linux 7 running on an x86 hardware platform, or s390x (IBM Z) architecture.

Dockerの古いバージョンならもう少し古いディストリでも動くかもな

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

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

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

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

みたいなな。

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

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

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

>>99
その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる

短命コンテナをバンバン使い捨てるケースで …/docker/overlay2 にゴチャゴチャ置かれても
sync 前にすぐ消えたファイルやディレクトリは単に無視されてディスクには書き戻されなくなって安心
デフォの 5 秒だとちょっと早すぎるんだよな
欠点はもちろん不意の電源ダウンで指定秒数ぶんだけデータロストする可能性があることだけど
ノートだったり UPS あったり、吹っ飛んでもいいや的な状況なら sync-daemon 系も不要だから楽

俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後
Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた

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

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

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

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

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

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

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

RaspberryPiで使えますみたいなことは書いてあるね
普通には使えないっぽいのは何か残念だな

俺、OpenSuseで使ってる変態。

Docker toolboxの最新版（18.01.0-ce）を入れたら何故かdockerのデーモンに接続できなくなったけど
VirtualBoxのGUIから仮想マシンを止めたら直った

docker-machine restartは効果がなかった

>>1
乙

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

>>74
勉強になります

最近はOS、仮想化、dockerと色々と入り乱れて全体像を理解するのに苦労するなぁ
ま、所詮パンピーですから

それはひょっとしてギャグで言ってんのか

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

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

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

☆ 現在、衆議員と参議院の両院で、改憲議員が３分の２を超えて
おります。総務省の、『憲法改正国民投票法』、でググってみてください。
国会の発議はすでに可能です。日本の、改憲を行いましょう。
平和は勝ち取るものです。お願い致します。☆☆

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

EAAD8

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

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

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

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

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

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

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

そんなもんsystemdに標準搭載されてる機能だろ

おい、素人同士で勝手に話をすすめるなｗ

>>56
> カーネルの上で動かすカーネルとかもうそれVMじゃん
VM=仮想マシン＝マシン（ハードウェア）を仮想化してないならVMにはならない

>>55
> dockerコンテナってホストOSのカーネル使ってるの？
そもそもホストとかゲストとかいうものがない

Linuxっていうのはカーネル（https://www.kernel.org/ で配布しているやつ）に
DebianやらUbuntuやらRedhatなんかが、いろんなアプリをセットにして配布してる

カーネルは基本的に汎用。だから同じカーネルを使っても
DebianやCentOSなんていう別のディストリが作れる

さてパソコンにDebianをインストールしたとする。そこにはカーネルといろんなアプリが有るわけだが
Dockerで作ったDockerコンテナはこのうちカーネルだけを利用する。

例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。
パソコンにインストールしてあるカーネル + FROMの元になったディスクイメージ を使ってアプリを動かす

そんなもんだから、Debianをインストールしていたとしても、UbuntuやCentOSのディスクイメージを使うこともできる

俺も最近、Docker for Windows入れてみてたばかりなんで、HyperVが必要な理由とかが分かって参考になった

dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
物理で構築してたPlaybookのTarget SectionにDocker使うよって一行追加すれば使えるし(厳密には使えるようにするまでに色々設定は必要だけど)、
仮にコンテナのデファクトみたいなものがDockerじゃなくなっても最悪SSHで接続さえ出来れば流用できるからこのやり方良いなと思ってるんどけど。

>>80
もうフェードアウトフェーズだよｗ

DockerもついにKubernetesをネイティブでサポート、Swarmの併用も可能
http://jp.techcrunch.com/2017/10/19/20171017docker-gives-into-invevitable-and-offers-native-kubernetes-support/

しばらくはswarmでもできる！とかやるだろうけど
次第にフェードアウト

hoshu

>>56
ありがと。
そうなるとwindowsだとdockerインストール出来るけど、エンジンとかに工夫してあるのか

ttps://www.slideshare.net/zembutsu/docker-images-containers-and-lifecycle
ここの19ページめに、ベースイメージにイメージ層を載っけていくて記載あるけど、
これは間違ってるの？

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

CoreOSはDocker利用を想定してたけどコレジャナイ残念OSだったので次はRancherOSあたりに期待してる

小規模っていうか、1台のマシンの場合って考えてるよ
開発用メインでdocker runのオプションを指定するのが
面倒になった時ｗ

そいつらがいずれ、どうにもつまらない理由で内輪もめを起こしてまとまらなくなり
あの機能はそちらにしかない、その機能はあちらにしかない、なんて状況となってる間に
OracleやMSに持っていかれる、というところまでがテンプレ

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

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

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

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

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

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

まあ言いたいことはわかるよ
それだって秘伝のシェルスクリプトを書き足すよりはずっといいさ

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

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

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

http://www.publickey1.jp/blog/17/dockerlinuxkitlinux_subsystemdockercon_2017.html
こういうのじゃね？

誰かが早く僕の考えた最強Linuxを発表しないとな。
え、それが乱立してるって？

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

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

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

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

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

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

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

kubernetesはほぼ全部の業界大手が参画してるけど
そんでもコケるってことあるんかな
いやまぁ莫大な金が動くインフラ業界だからねぇ

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

Docker swarmが本命じゃないの？

>> 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ができて
システムを俯瞰して見ることができるインフラエンジニアが居た方がいいかなーとは思います。。

docker系の技術は日進月歩すぎるのでredhatやcentosのような枯れたOSで使うのはきついですよね？
色々入れたり設定が必要だし。
お勧めなディストリはやはりubuntuやfedoraなどですか？