[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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コンテナで使いたい場合、
具体的にどうすればいいでしょうか。
コンテナに入ってから、
コンパイルすることしか想像できない初心者です。
476(2): 2018/11/07(水)01:11 ID:v7o9U8jP(2/12) AAS
>>475
Dockerfileを使ってビルドするんだよ
コンテナの中に入るのは、ビルドがおかしいが原因がよくわからないとかで
調査するため。手作業でコンパイルとかしない
単純にDockerコンテナ内でビルドすると時間がかかったりイメージサイズが膨れ上がったり
するから工夫が必要なんだが、とりあえずそれは置いといて、一番単純な方法だ。
まずDockerfielを書く。Dockerfileには基本的に次のようなことを書く
・FROMでどのディストリをベースにしたイメージを作るのかを書く
・RUN（RUN yum〜とか）でイメージの中にコンパイルをするのに必要なパッケージを入れていく
・ソースコードをコンテナの中に配置する
省6
477(1): 2018/11/07(水)01:21 ID:v7o9U8jP(3/12) AAS
>>476で書いたように、単純な方法を取ると、
アプリを起動するのに必要ないビルドツールのせいで
イメージサイズが大きく膨れ上がる。
レイヤー（例えばRUN）毎に差分が保存されるため
ビルドが終わってから削除してもイメージサイズは減らない
（一つのRUNの中ですべてを行う方法があるが、
キャッシュも使われなくなるのでイメージのビルド時間が伸びる）
こういう場合に使うのが multi stage build
アプリを使うためには、アプリの実行ファイル（とランタイム環境）さえあればよいので、
ソースコードから実行ファイルを作る所までをビルド専用イメージで行う
省1
478(2): 2018/11/07(水)01:21 ID:JZV5z18S(3/11) AAS
>>476
丁寧なレスをいただき、感謝いたします。
ありがとうございます。しかし、疑問が／／／
環境構築は手探りではダメで、
ビルドなどを含む全ての環境構築手順を、
スクリプト化できていないとダメなようですね。
Dockerfileでも、yumコマンドが扱われていることから、
ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、
何が本質的に違うのかなと素朴に疑問です。
どうしてわざわざ、Dockerイメージづくりを自動化しなければいけないのですか。
省1
479: 2018/11/07(水)01:25 ID:JZV5z18S(4/11) AAS
>>477
脹れ上がりですね。
＞ビルドが終わってから削除してもイメージサイズは減らない
知りませんでした。ありがとうございます。
英文ですが、さっきこれを見つけたところでした。
外部ﾘﾝｸ:stackoverflow.com
勉強します。丁寧なレス感謝いたします。
脹れ上がり防止と、
dockerfileによるイメージ作成の自動化が焦点になっているという認識であっていますでしょうか。
ありがとうざいました。
480(1): 2018/11/07(水)01:29 ID:v7o9U8jP(4/12) AAS
>>478
> 環境構築は手探りではダメで、
> ビルドなどを含む全ての環境構築手順を、
> スクリプト化できていないとダメなようですね。
Dockerfileを手探りで書けばいいじゃん。
FOROM deban
COPY ソースコード
RUN yum install パッケージ
RUN ./configure
とか書いてビルドして、あれぇ？ビルドできないなぁとかなったら
省9
481(1): 2018/11/07(水)01:30 ID:v7o9U8jP(5/12) AAS
まあどうしてもわからないなら、コンテナに入りつつ
ビルドしていって試してもいいけど、最終的には
Dockerfileにビルドするためのコマンドを書く
上下前次1-新書関写板覧索設栞歴
あと 521 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.019s