[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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にビルドするためのコマンドを書く
482(1): 2018/11/07(水)01:30 ID:JZV5z18S(5/11) AAS
>>474
＞Dockerでサービスが起動するコンテナを作ってあとはDockerに
＞OS起動時に、そのコンテナを起動してもらえばいいだけ
ソースのreadmeは、Dockerコンテナを想定していないです。
すると、dockerコンテナ内で、systemctl enable serviceをセットして、
コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。
とすると、privilegeとか、なにか別の特権を与えてコンテナを起動して、
仮想マシンみたいにコンテナを動かすしか手が見つからないんです。
483: 2018/11/07(水)01:34 ID:JZV5z18S(6/11) AAS
>>480
＞そうすれば、RUN yum install パッケージが
＞終わった段階のキャッシュの続きから実行されるから、
＞手探りでやってるのと大差ない作業になる
続きから継続されるという仕組みがいまひとつピンとこないんですが、
知らなかったです。書籍も読んでいるんですが、あまり実践的ではないものが多いように思います。
最後にyumとかでまとめて御仕舞いというのは、
ワンライナーでかけるところはまとめて、dockerfileを作れということですね。
484(2): 2018/11/07(水)01:36 ID:v7o9U8jP(6/12) AAS
>>478
> Dockerfileでも、yumコマンドが扱われていることから、
> ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、
> 何が本質的に違うのかなと素朴に疑問です。
Dockerは動作確認するためのツールじゃねーし。何かを作るためのもの。
その何かっていうのはDockerイメージでありそこから起動するDockerコンテナ
そのDockerイメージやDockerコンテナを作るために、最終的にDockerfileを書くんだよ。
Dockerイメージ = 実行ファイル
Dockerコンテナ = 実行ファイルを起動したもの
と考える
省5
485(1): 2018/11/07(水)01:36 ID:JZV5z18S(7/11) AAS
>>481
ありがとうございます。
ずっと、どうしてコンテナに入って作業してはいけないのかが、
謎だったんですが、入って作業するのもアリなわけですね。
ホッとしました。
486: 2018/11/07(水)01:40 ID:JZV5z18S(8/11) AAS
>>484
なるほど。
＞Dockerイメージ = 実行ファイル
＞Dockerコンテナ = 実行ファイルを起動したもの
とてもわかりやすい喩えです。
＞つまり、Dockerコンテナ（イメージも）は壊してDockerfileから
＞作り直してもなんの問題もないわけだ
＞なんの問題もないし、実際にそうする。
Dockerfileさえあればいいってことがよくわかりました！
省3
487(1): 2018/11/07(水)01:43 ID:v7o9U8jP(7/12) AAS
>>482
> ソースのreadmeは、Dockerコンテナを想定していないです。
> すると、dockerコンテナ内で、systemctl enable serviceをセットして、
> コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。
無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで）
起動するやり方を調べろ。普通はその方法で起動する。
うん、だから、俺はDockerはインフラのためのツールと言うより
アプリ開発者のためのツールだって言ってるんだよ
インフラはアプリを作らない。だからDockerでアプリを起動しようと思ったら
そのアプリの起動方法を調べないといけない。よく知らないアプリの
省9
488(1): 2018/11/07(水)01:45 ID:v7o9U8jP(8/12) AAS
>>485
> ずっと、どうしてコンテナに入って作業してはいけないのかが、
> 謎だったんですが、入って作業するのもアリなわけですね。
> ホッとしました。
それを作業って言うのが謎。調査だよ。作業じゃない。
コンテナでやった作業（ではないもの）は全て破棄されるんだから
コンテナに入るのは調査するためだけ
489: 2018/11/07(水)01:53 ID:JZV5z18S(9/11) AAS
>>487
＞無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで）
＞起動するやり方を調べろ。普通はその方法で起動する。
目が覚めました！ありがとうございます。直接起動する方法を調べないと駄目ですね。
Linuxは柔軟ですね。（WindowsならSQL SERVERはフォアグランドで動かせなさそうだもの。）
いわば、クリスマスツリーの電飾から、一つだけ豆球を取り外して、乾電池につないで動かすようなもののように感じます。
＞うん、だから、俺はDockerはインフラのためのツールと言うより
＞アプリ開発者のためのツールだって言ってるんだよ
＞あとはインフラにこのイメージ起動してってぽんと渡すだけでよくなる。
>>484の喩えを使って言えば、
省9
490: 2018/11/07(水)01:54 ID:JZV5z18S(10/11) AAS
>>488
よくわかります！
491(1): 2018/11/07(水)01:56 ID:v7o9U8jP(9/12) AAS
> アプリ開発者ならsystemd使わない起動方法だって知ってる。
っていうのは、
自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味無
アプリ開発者はすげーから、なんでも知ってるぜーって意味ではないので
492: 2018/11/07(水)01:57 ID:v7o9U8jP(10/12) AAS
訂正（意味無ってなんだよ？）
自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味な
上下前次1-新書関写板覧索設栞歴
あと 510 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s