[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
456(1): 2018/10/26(金)10:06 ID:S+WdRTJT(4/9) AAS
で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある
C言語の場合、ビルドしないと動く実行バイナリはできないから
これで納得するかもしれないけど、ウェブ開発とかしてると
ビルドしなくてもソースコードを修正したらすぐに反映されるわけだ
毎回Dockerビルドしないといけないのは辛い。こういう場合にボリュームを使う手がある
データはDockerイメージの外に置くといったけど、ソースコードもDockerイメージの外に置けばいい
Dockerイメージの中にはPython実行環境などが入っているけど、ソースコードは含めない
ホームディレクトリ以下のいつもの場所をそのまま参照する
当然エディタもDockerイメージの中に入れない。
今までどおりエディタで編集して、実行環境がDockerイメージなっただけ
省4
457: 2018/10/26(金)10:18 ID:UuZWwwD+(3/6) AAS
>>456
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう
458: 2018/10/26(金)10:20 ID:S+WdRTJT(5/9) AAS
>>454
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。
インフラが全部やりますっていうのなら、開発側に影響はない。今までどおりだ。
そう今までどおり、開発側で新しいライブラリとか追加や更新しようと思たら
インフラにこれ変えたいんですけどとお伺いを立てたり
本番用環境とバージョンが違うとかでバグがでたり
そういう今ある問題がそのまま残るという意味で開発側に「影響がない」ということだ
Dockerfileはソースコードのリポジトリに追加するのが良い
（もちろん分離することもできるが、いろんな問題は解決するのが難しくなる）
省11
459: 2018/10/26(金)10:26 ID:UuZWwwD+(4/6) AAS
今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね
460: 2018/10/26(金)10:29 ID:S+WdRTJT(6/9) AAS
Dockerを仮想マシンの代わりとしてとか考えてると
> 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
> パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
> コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ
↑これとかで、混乱する。
Dockerは仮想マシンじゃないんだよ。
Dockerfileから作成したDockerイメージはビルドした状態から変更しないもの。（もちろん再ビルドはOK）
Dockerコンテナに乗り込んで、中身を書き換えて再イメージ化なんてこともしない。
できるけど、通常の使い方ではやらない
省3
461(1): 2018/10/26(金)10:34 ID:S+WdRTJT(7/9) AAS
> 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね
virtualenvといわれると、少し違和感があるな
VMよりずっとましだけど
virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ＝Dockerイメージ＝実行バイナリの凄い版を
作るものだから
462(1): 2018/10/26(金)10:39 ID:UuZWwwD+(5/6) AAS
>>461
やっとそこの理解ができた
インフラがDocker推すのわかるわ
virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな！
463: 2018/10/26(金)10:44 ID:S+WdRTJT(8/9) AAS
例えばgoで作られたバイナリは、いろんなものがスタティックリンクされるので
単一のバイナリをコピーするだけで、あちこちでそのまま動かすことができる。
それと同じようにDockerもDockerイメージの中に、いろんなものが詰め込まれてるので
あちこちで動かすことができる
ちなみにDockerfileでビルドしたDockerイメージはDockerリポジトリにpushしておける
（パブリックな公式のDocker hubや、各社プライベートリポジトリ等がある）
そうしたイメージは手元でDockerfileからビルドしなくてもpullするだけで使える
バイナリをコピーするだけで動かすことができるように
DockerイメージをDockerリポジトリからpullしてくるだけで動かすことができる
こういうのは開発者にとっても便利だよね。
省3
464(1): 2018/10/26(金)10:56 ID:S+WdRTJT(9/9) AAS
>>462
Dockerイメージを新しく（バージョンアップ）したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる
インフラが気にするのはDockerイメージを実行することだけ
だからDockerイメージが起動さえすれば、物理（or 仮想マシン）の
OSを変えることだってできちゃう。
そのDockerイメージが動きさえすれば良いんでしょ？程度の気楽なもん
開発チームは開発チームで、物理（or 仮想マシン）のOSの機能に
（カーネル以外）依存しているわけじゃないので、
Dockerイメージのベースとなるディストリを変更したりなんでもできちゃう
省8
465: 2018/10/26(金)11:34 ID:UuZWwwD+(6/6) AAS
>>464
ほんとベース理解できたら凄いわこれ
細かいホスト側？の設定はインフラに任せるとして
開発に影響のあるdockerfileの作り方も凝らなければストレートだね
これで環境周りのめんどくささからは解放される！
466: 2018/10/26(金)13:18 ID:4wc3titV(1) AAS
chrootで仮想化するのを全自動で管理できるようにしたのがdocker、chroot以下構築のbashファイルに相当するのがDockerfile。
ツッコミどころ満載の説明だけど、概念はこれでおk.使い方はコマンド覚えろ。
467: 2018/10/27(土)19:48 ID:5pOpML2z(1) AAS
は？
468: 2018/11/01(木)11:02 ID:Ub4h8gMB(1) AAS
クソレスのせいで会話とまったな
466は反省しろよ
469(1): 2018/11/05(月)05:00 ID:tQ7nIs7Z(1) AAS
シェルのコマンドで-pとか-vとか指定するのと
Dockerfileに書くのと
docker-compose.ymlに書くのと
どこにどうすればいいかがわからんわ
470(1): 2018/11/05(月)08:23 ID:R14xwsxg(1) AAS
Dockerコンテナってラベル付ける機能あったんだ
長い事使ってるがそんな機能がある事自体初耳
TraefikというDockerコンテナを自動的に登録してルーティング出来るリバースプロキシがあるんだが
Dockerのラベルでリバースプロキシの設定が出来る
外部ﾘﾝｸ:docs.traefik.io
以下docker-compose.ymlの抜粋
ホストヘッダーでのルーティングを設定してる
# ...
whoami:
image: containous/whoami # A container that exposes an API to show its IP address
省2
471: 2018/11/05(月)08:47 ID:Thuf2ewx(1/2) AAS
>>469
docker-compose.yamlはコマンドのオプションで指定するのと同じ
docker-composeコマンドというのはそもそも、
一つのコンテナだけ構成されたものを起動するならdocker runだけでいいけど、
複数のコンテナで構成するときに、docker runで適切なオプションつけて
複数起動するのが面倒って言うときに使うものだから、機能的にはdocker runと同等
run以外にbuildとかもできるけどね。
で、Dockerfileとdocker runの違いだが、Dockerfileはイメージの仕様として
ポートを公開しますよ、ボリュームを使用しますよって、明示するときに使う
docker runの方は公開されたポートをホスト上のどのポートに割り当てるのか
省8
472: 2018/11/05(月)08:47 ID:Thuf2ewx(2/2) AAS
>>470
> Dockerコンテナってラベル付ける機能あったんだ
ずいぶんと前についた気がするが？
昔docker-composeはラベル使っていなかったが、
途中でラベル使うように変わったよな
473(1): 2018/11/07(水)00:40 ID:JZV5z18S(1/11) AAS
たとえば、あるソースをコンパイルして、
systemctl start serviceができるようにするには、
どうやってコンテナ作りをすればいいんでしょう。
privilegeを与えて、yumで開発環境投入して、
systemctl がつかえるように、serviceファイル設置して、
systemctl enable serviceのあと、shutdown したのち、
docker image化してはダメなんでしょうか？？
474(2): 2018/11/07(水)00:52 ID:v7o9U8jP(1/12) AAS
>>473
なんでソースのコンパイルなんて話が出てくるのかわからん
Dockerのコンテナはsystemctl start serviceから起動する必要はない
通常はDockerそのものがsystemctl start serviceで起動するようになってるから
Dockerでサービスが起動するコンテナを作ってあとはDockerに
OS起動時に、そのコンテナを起動してもらえばいいだけ
どうしても特定のDockerコンテナだけsystemdで制御したければ、
dockerコマンドを実行するserviceファイル書けばいいだけだが
> privilegeを与えて、yumで開発環境投入して、
？？？
省7
475(1): 2018/11/07(水)00:57 ID:JZV5z18S(2/11) AAS
>>474
レスありがとうございます。
＞Dockerでサービスが起動するコンテナを作ってあとはDockerに
＞OS起動時に、そのコンテナを起動してもらえばいいだけ
ソースで提供されているプログラムをDockerコンテナで使いたい場合、
具体的にどうすればいいでしょうか。
コンテナに入ってから、
コンパイルすることしか想像できない初心者です。
上下前次1-新書関写板覧索設栞歴
あと 527 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s