[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
101: 2020/08/28(金)14:53 ID:zYE9gZVL(3/8) AAS
そりゃチームの人が作ったら他人だろうけどそういう話じゃないだろｗ
102(1): 2020/08/28(金)15:05 ID:PXYaUzYG(2/2) AAS
いやいやそうじゃなくてオープンソースのツールとかあるだろ
ネット遮断でもしてんのかお前んとこ
103: 2020/08/28(金)15:41 ID:e8Ic+DMZ(1) AAS
Dockerfileも拾えよ
104(1): 2020/08/28(金)16:42 ID:zYE9gZVL(4/8) AAS
>>102
オープンソースのものを自分でDockerfile作る意味は？
殆どのものは公式が用意してるでしょ
105(1): 2020/08/28(金)17:18 ID:O2BsRo2K(1) AAS
>>104
公式サポートない物もいくらでもある
それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
なんでこんな基本的なこと説明してやらんといかんのだ？
106: 2020/08/28(金)17:54 ID:MXNSOP9Y(1/2) AAS
いや、自分で「マージしたDockerfile」作れよ
それが自動でできなくてゴネてるの？
107: 2020/08/28(金)18:41 ID:jq9YEzpA(1) AAS
めんどくせぇ
108: 2020/08/28(金)18:56 ID:NRktIr3W(1/2) AAS
go製ツールならバイナリ落としてくればすぐ動くが
Pvthonとかのスクリプト言語を使う系や
C/C++で書かれている物はそうも行かない
パッケージマネージャにあれば良いが
あっても古い、このパッケージもインストール必要とか面倒
glibc使ってるC/C++製ツールで動的リンクしてたら
alpineにそのまま持って行っても動かない
muslで再コンパイルするか
イメージサイズの肥大化を覚悟でglibcを入れる必要がある
109: 2020/08/28(金)18:58 ID:NRktIr3W(2/2) AAS
OSに最初から入ってるツールの扱いはどうするのか？とか考えたら
自動的にマージできるとか思うわけない
Dockerからしたら全てただのファイルであり
依存関係も把握してないし区別もしない
110(1): 2020/08/28(金)19:30 ID:D6h6IbAl(1/2) AAS
結局のところ必要だったのはdockerじゃなくてより賢いパッケージマネージャだったんだよな
方向性としてはsnapなどのほうが正しかった
111: 2020/08/28(金)19:36 ID:MXNSOP9Y(2/2) AAS
賢いパッケージマネージャよりdockerが便利
112(2): 2020/08/28(金)19:51 ID:zYE9gZVL(5/8) AAS
>>105
> それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
docker-compose使えよ
１つのコンテナに複数のサービスを入れ込もうとしているからそうなるんやで？
ベストプラクティス通り1コンテナ1サービスにすれば
既存のものをそのままつかえるのに
ベストプラクティスから外れることを自分でしておいて
自分が苦労してるのって間抜けじゃねーか？ｗ
113: 2020/08/28(金)19:54 ID:zYE9gZVL(6/8) AAS
>>110
Dockerはパッケージマネージャーが対応してないような
自分（自社）で開発したアプリケーションを使って
自分でサービスを運営するためのパッケージマネージャーです
開発者向けのツールです。
snapはアプリ開発者がエンドユーザーにアプリケーションを
提供するためのもの。用途が全く違います。
114: 2020/08/28(金)20:05 ID:a9bICJj+(1) AAS
apacheのバーチャルホストで20個のサイトを運営するのと
1つのイメージを使って1コンテナ1サイトを作るのでは
どっちがメモリとCPU使用率が高いですか？
115: 2020/08/28(金)20:09 ID:zYE9gZVL(7/8) AAS
メモリとCPU使用率が重要なら、
1つのイメージを使って1コンテナ20サイトを作れば？
116: 2020/08/28(金)20:18 ID:zYE9gZVL(8/8) AAS
1コンテナ1サイトって発想が出るのもやっぱりいつもの
Dockerを仮想マシンの代わりだと思ってるからなんだろうか？
Dockerはアプリの代わりと考えれば、この場合apacheだとわかる
１つのapacheアプリでバーチャルホストをするのであれば
Dockerの1つのapacheアプリでバーチャルホストをすればいいだけ
そのバーチャルホストの設定を予め終わらせておいた
カスタマイズ済みapacheを簡単にデプロできるのが
Dockerのメリットなわけで
117: 2020/08/28(金)20:33 ID:pZN+Qti3(2/3) AAS
1サイトをバックエンドとフロントエンドとDBに分けても良いよ？
118: 2020/08/28(金)21:09 ID:D6h6IbAl(2/2) AAS
>>112
アホか
何でもかんでもサービスにしたら効率が悪いこともある
119: 2020/08/28(金)21:24 ID:MSjqCkB+(1) AAS
何か変なのがいる。この後どうなるか楽しみ。
120: 2020/08/28(金)21:44 ID:7j4VCa1Z(1/2) AAS
メインの言語でwebアプリを作って内部で別言語製のCLIツールを呼び出すようなシステム
業務システムなら普通にあるよなあ
別言語でapi鯖構築してメイン言語と別言語の2コンテナ構成にするって手もないこたないけど
そのためにワザワザ別言語とそのweb apiフレームワークを習得するのはコスパ悪いだろ
こういうときは1つのコンテナに複数の言語ランタイムやパッケージをまとめちゃって素直にサブプロセス呼んだほうが製造コスパがいい
んでそういうときに公式イメージのマージができたら便利なんだがサポートされてないからDockerfileをワザワザ書かなきゃならん
コンテナを分離する間抜けなアイデアよりは遥かに楽だけどそれでもDockerfileを書く手間は残る
上下前次1-新書関写板覧索設栞歴
あと 882 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.016s