コンテナ型仮想化Dockerスレ その2
■ このスレッドは過去ログ倉庫に格納されています
コンテナ型仮想化を提供するDockerスレ
Dockerは
1. アプリケーションコンテナです。 システムコンテナではありません。
2. アプリケーションのポータビリティを目的として利用します。
3. 仮想マシンではありません。 仮想マシンとは目的が異なります。
4. 仮想マシンと共に使用することが多いです
5. WindowsとmacOSの両方で動きますが、どちらも仮想マシンを利用します。
6. コンテナの中にSSHでログインしようとか考えないでください。そういうものではありません。
7. コンテナの中では原則として一つのアプリケーションを実行します。
8. Dockerfileを使ってイメージを作ります。Ansibleとかやめてください。
9. イメージを作るのはアプリケーション開発者の仕事です。インフラの仕事はつくられたイメージを動かすことです。 いちいち嘘つくなよ
> ライブラリのほとんどが
> systemdだけを前提としたものになってて
嘘だからライブラリの名前を言えない つーか、ライブラリが「起動」できないって、意味がわからんなあ。 >>118
起動の仕方は自分で調べるんですよ
systemdがなければ当然systemdからは起動できないってだけ 不便だと思ったらすでにどっかの使い方から外れてる可能性はあるね別のソリューションを探すべきかも >>121
興味あるけどよく知らん
何ができるの？
難易度は？ とりあえずansibleのテストに使えるならなんでもいいんだ
そうなるとsystemdはほぼ間違いなく必要でしょ？
コンテナってfirewallの設定ってできる？
コンテナ内部からstatic ipの設定できる？ ほらな。こういうやつがいるから、俺はDockerの正しい使い方を何度も繰り返してるの
>>125
Dockerは仮想マシンじゃない。
仮想マシンの代わりとして使うな
使い方が間違っている
正しい使い方を勉強しろ Dockerは環境を作るものじゃない
アプリを配布するためのものだ
バイナリ一個配布しても動かないから
バイナリとそれを動かすのに必要なものすべてをまとめて
一つのコンテナだけで動くアプリを作るためのもの
すべてをスタティックリンクするようなもの
スタティックリンクされたバイナリの中でansibleつかうか？firewallつかうか？
意味不明だろ？そういう意味不明なことをするな インフラ屋がDockerを使うとうしてるのが
アホに見えてしょうがない。
Dockerはアプリ開発者のための道具だ。
インフラ屋は、
俺（アプリ開発者）がDockerイメージ作ってやるから
な？お前らは、そのイメージを動かすだけでいい
自分でイメージをつくろうとするな。
どっかのウェブアプリをイメージ化しようとするな
お前らには必要ない
お前ら（インフラ屋）はただイメージを動かすだけでいい。
イメージを動かすのに必要最小限のコマンドだけを知っていればいい
kubernetesとかそういうイメージを動かすインフラだけやってろ >>128
いやーそれはわかってるけどさ
わかった上で正道以外の使い道を模索するのもハッキングの醍醐味じゃないか
仮想マシンじゃパフォーマンスでないからコンテナで代替したい
でも仮想マシンとコンテナは違う
そこで諦めたらなん発展もない
逆に限りなく仮想マシンに近付けるにはどうするかって考えたほうが発展性がある あほかｗ
Dockerがコンテナに"発展"させて来てるのに
仮想マシンに"退化"させて使うとか間抜けすぎ
lxcを使えばいいだけ。せっかくアプリケーションコンテナとして
余計な機能を削ぎ落として目的達成のためのツールとして
完成度を上げてきたのに、なぜわざわざ削ぎ落とした機能を復活させようとしてるのか
お前がやってることは神エクセルと同じだ。
本来の目的と違う使い方をしてるから
どうやればいいのかわからない状態になってる。
物事を面倒にしてるだけだ >>131
でもエクセルは便利だし普及してるじゃん
エクセルが表計算しかできないツールだったらここまで流行ってないよ 別にdockerコンテナを仮想マシンとして使いたいなら好きにすりゃいいけど
それを「発展」とぬかすのはアホとしか思えんな >>132
「神エクセル」でググレ
もしくはお前はこれから1セル1文字で書け >>133
仮想マシンが発展といってない。真逆だ。
Dockerはコンテナ技術を「アプリケーションコンテナ」として発展させてきた とりあえずここは「厶板」の「Docker」スレだから完全にスレチ
Linux板なりAnsibleのスレなりに行って
その素晴らしいハッカー魂を披露してこいよ ハッキングの醍醐味というなら、まずsystemdを自力で起動できるようになったら？
そのうえで、Dockerで動かせそうなら動かせば。
できたら、使い捨てsystemdコンテナのつくりかたをQiitaあたりで公開してくれ！ｗ >>135
仮想マシンも広義にはアプリケーションの1つじゃないの？
仮想マシンをサーブするのに必要なバイナリとそれを動かすのに必要なものを全部まとめた1つのコンテナと考えればいい
既成概念にとらわれずもう少し柔軟に考えようよ >>140
アプリケーションの中で仮想マシンの機能は必要ない
だから削ぎ落としてる >>119
MySQL てめえだよ
/etc/init.d/ の下にサービスなんか置いてくれねぇよ
パッケのインストーラーがinitを切り捨ててるから
initはもうオワコン ピコーン
Dockerコンテナの中でVM動かしたらDockerの中でsystemd動かしたと言えるんじゃね？ 単体で起動したくない理由てあるの？systemdで起動するメリット >>142
くり返し言うが、Dockerはアプリ開発者のもの
インフラエンジニアが自分で作ってないMySQLなどの
サーバーを動かすためのものじゃない
そういうのはDockerが公式で用意してるんだからそれを使えばいいだけ。
なぜそんな無駄なことをするのか、無駄であることがわかってないんだろうな >>142
init.dスクリプトよりも、systemdサービス設定のほうがはるかにわかりやすいんだが。
ひょっとしてsystemdに詳しくないだけなのでは？
サービスを起動している設定だけなら簡単だから、調べてみろ。 systemdコンテナはredhatが出してるようだな
要件次第じゃ必要になるってわかってんだな
流石はredhat、頭硬い連中とは違うわ systemdが有効だとdockerのためのバッドノウハウ的な微調整をしなくてもすんなりサービスが動くから簡単でいいね
複数サービスが連動して動く有機的な大規模サービスをyamlなしで配布できるのも嬉しい はて？簡単じゃないから今こうして苦労してる話をしてるんだろうｗ > 複数サービスが連動して動く有機的な大規模サービスをyamlなしで配布できるのも嬉しい
1サービス1コンテナが原則
Dockerの原則すら理解していない
一つのコンテナにまとめてしまったら大規模サービスを作るときに
個々のサービスを分離できなくなる 多分、docker云々以前にdevopsの概念とか
そういうのから勉強した方がいいと思う
これからの開発者なら必須だと思うし
インフラ屋ならおまんま食い上げにならない為に尚更勉強するべき
devops勉強した上でそれでもdockerに興味があるなら
kubernetesを勉強しろ
まあいずれにしてもインフラ領域はスレチかな >>150
dockerわかってない奴の典型例じゃんお前
利用者目線で全体として1つのサービスを提供するなら中で幾つサービスがあってもいいんだよ
サービスのカプセル化な
典型例だとgitlabコンテナ
これは中で多数のサービスが協調して動いてる
これを1サービス1コンテナで提供しようとしたら利用者に大変な労力を強いることになる やっぱり頭が硬いとだめだね
1サービス1コンテナは多くの場合でそれで上手く行くってだけなのにまるで必要条件であるかのように勘違いしてる >>155
「原則」だから全然間違ってないと思うが >>156
原則って言葉の意味わかってんならいいけど
複数サービス・systemdは絶対許さんと言わんばかりにレスつけてくる奴がいる
こいつは多分わかってないんだろ 正直言って俺もsystemd動かすのはどうかと思うよ
何の為にdocker使ってんの？って話
そんなに使いたいならlxc使うべきだし
どうしてもdocker使いたいならlxcで動かしたlinuxで
docker動かしたとこでオーバーヘッドほとんど無いし
運用コスト考えたら必要無いもん入れるのは間違い 参考までに聞きたいんだけど
複数サービスが動いているらしいgitlabのコンテナは
systemd動いてるの？
触った事無いから知らないんで教えて欲しい >>158
なんのためにってdockerインフラに乗っかってアプリケーションを簡単に配布するためでしょうが
この目的とsystemdを使う/使わないは直交した別のベクトルだから混ぜて考えるな
インターフェースを規格化して内部実装をカプセル化できるってのもdockerのメリットの1つ
内部実装の作り方に変な宗教を持ってるとそのメリットを活かせなくなる
複数サービスがやりやすいなら複数サービスで実装すればいい
systemdがやりやすいならsystemdで実装すればいい >>160
複数サービス載ってるとマイグレーションで問題あると思うよ
そこら辺はどう考えてるの？ >>159
ソース公開されてるだろうから見てみたら？
俺は複数サービスが動いてることしか知らない
俺は利用者だから内部実装には興味がない
内部実装を知らなくてもgitlabコンテナを利用できる
それがdockerの素晴らしいところだ
これがもし複数コンテナを前提としている作り方だったとしたらどうなるだろう
どのコンテナが必要なのか？
コンテナを協調させるための設定はどうすればいいのか？
それらを踏まえた上でマニフェストをどう書くべきか？
調べること考えることが多すぎる
こんなんじゃあ起動するまでが大変だ
dockerはお手軽にアプリケーションを配布できるんじゃなかったのか？
このように1コンテナ1サービスに執着するようなdockerを理解してない人がイメージを作るとdockerのメリットが損なわれるので本当に迷惑 >>161
gitlabはコンテナ起動時にChefを動かしてるね
なのでイメージのバージョンアップも簡単にできる
ではこれが複数のコンテナに分離されていたとしたらどうだろうか？
gitlab全体としてバージョンアップするのにどのコンテナをバージョンアップさせればいいのか？
対象コンテナが決まったとしてそれらのバージョンアップを安全に実施するにはどうすればいい？
幾つもあるコンテナの種類ごとにいちいちやり方を調べるのか？ >>163
それこそが君の言ってる
「サービスのカプセル化」とか「インタフェースの規格化」のメリットでしよ？
dockerでサービス同士を疎結合にしてるメリットは
個々のサービスで完結しているから
マイグレーション時に自分のアプリケーションの事だけ考えれば
良いところでしょ
まあdockerってよりマイクロサービスのメリットだとは思うが あー、なんとなく理解した
開発者視点と利用者視点の差かな？
使う側からしてみりゃオールインワンで導入できた方が楽とか
そういう感じ？ >>164
ポイントは必ずしもサービス毎の結合を完全に断ち切れるわけではないということだな
超シンプルな例としてAP-DBの2コンテナ構成を考えるとしよう
DBのバージョンとAPで使用してるドライバのバージョンにミスマッチがあれば動作しないということも当然あり得る
コンテナが独立しているからと言って個別に好き勝手にバージョンしていいわけではないことがわかるだろう
このように単純な構成ですら完璧ではない
ましてやgitlabのようなより多くのサービスが密接に連携しているアプリケーションはさらに繊細だ
コンテナを分離すればするほど設定ミスやバージョンアップミスなどトラブルが生じやすくなる
賢明なgitlab社は1サービス1コンテナではうまく行かないことを知っていたので1つのコンテナに複数のサービスをまとめて出荷した
その試みは成功して誰でも簡単に僅かな設定だけでgitlabコンテナを利用することができるようになった
ほとんど何も考えなくても安全にバージョンアップすることができるようになった
これはdockerの素晴らしい体験そのものだろう 開発者（自分で作ったものを配布する）か
インフラエンジニアかの違い
インフラエンジニアは自分でアプリを作ってない
だからDocker化する＝誰かが作ったアプリをDocker化するという発想しかない
自分で作ってないから起動する方法が（ちゃんと調べないと）わからない
だからsystemdを使おうとする
インフラエンジニア、いいか？Dockerはお前らのためのツールではない
お前らはただ言われたアプリを動かすだけでいい
自分でDockerイメージを作ろうとするな >>166
だから「原則」なんでしょ？
そりゃ依存があるなら一緒のコンテナに載せるのは仕方ないでしょ
でも理由がなけりゃコンテナ分けるのが普通だよね？
これを前提にもう一度>>150読んで欲しいんだけどさ
> 複数サービスが連動して動く有機的な大規模サービスをyamlなしで配布できるのも嬉しい
に対して
1サービス1コンテナが原則
って言ってるのに
頭が硬いとか言うのはどうかと思うよ？ >>167
俺もそんな感じの考えだな
個人的にはマイクロサービスの段階をすっ飛ばして
いきなりコンテナとかが増えてきたから
インフラエンジニアの大半は根本的な考え方を理解してないと思う >>168
原則って言葉を理解して使ってるなら良いとさっきもレスした
頑なに1コンテナ多サービスやsystemdコンテナを拒絶してそうな奴が原則って言ってるのが気になるわけ >>170
いや、むしろ配布が楽になるって言ってる人に
「1サービス1コンテナが原則」って言うのは当然のことだと思うよ
そういう用途の為にdockerは作られてる訳じゃないから
それに頑なにsystemdを拒絶してそうな奴には一切見えないんだけど
何をもってそう判断してるの？ >>167
何らかの開発に従事する開発者だとしても
他者の作ったプロダクトは「誰かが作ったもの」だろ
このOSSの時代に全て自作のフルスクラッチというわけにもいかない
他者の作ったプロダクトが必要でそれがsystemdに依存しているあるいは推奨してるならコンテナで動かすときもsystemdを使ったほうがトラブルは少ない
解ってないやつほど余計なことをして変なバグ作ったりするんだよな
コンテナの内部実装の手法なんてのは様々あっていいはずなのにsystemdはダメだという先入観にとらわれて選択肢を自ら減らしてしまっている
頭が硬いという他なんと言えばいのか もう言ってることが意味不明過ぎて訳がわからない・・・
なんでdockerスレ来たの？
オンプレ鯖しか触ったことの無い老害的な香りが漂ってきたよ
コンパイルしたこと無さそう >>172
> そういう用途の為にdockerは作られてる訳じゃないから
配布を楽にする為にdockerが作られたわけじゃない、と言ってる？
ならその認識はおかしいので正したほうがいい
リリースを容易たらしめるというのはdockerの存在理由1つ
全てではないが大きなウェイトを占めていることは間違いない
> それに頑なにsystemdを拒絶してそうな奴には一切見えないんだけど
> 何をもってそう判断してるの？
一連のレスの流れをみて全体的にそう感じた
わかってると思うが君のことじゃないよ
ちょくちょく煽りを入れてくるもう一人のウザいほうね >>173
systemd前提で作られてあるアプリなんて無いんだよ？
開発中にsystemdと連携しないとテストできないってありえないし
systemdなしで使えばいいだけ あとDocker初心者なら
Docker公式Dockerfileを参考にしろ
systemdに依存するのが恥ずかしくなってくるから >>174
わからないのは単に経験が足りないんじゃないかな
簡単なアプリケーションしか開発したことないでしょ？
もっと難しい構成にもチャレンジして色んな可能性を模索してみなよ
redhatがユニバーサルベースイメージなどとご大層な名前を付けてsystemdサポートのベースイメージを公開してるのはなぜか？
systemdコンテナが本当に必要ないもの悪しきものだったらredhatがそんなもの作ると思うか？
もう少し踏み込んで考えてみてくれ
末端の開発者から先のキャリアに進むためにも
(在宅とはいえ流石にサボりすぎだからまた夕方に来る) >>178
> redhatがユニバーサルベースイメージなどとご大層な名前を付けてsystemdサポートのベースイメージを公開してるのはなぜか？
ベンダーロックインするためだろｗ ていうか>>158で言ってる通り
俺はsystemdは動かすべきじゃないと思ってるよ
>>150がどう思ってるのかは知らんけど
とりあえず勝手な思い込みで他人に意味不明なレッテル貼ったり
罵倒したり批難したりは良くないと思う
あとここはdockerのスレだし
dockerを使っている人が集まってる
自分で考えて独自解釈するのは勝手だが
せめてdockerがどういう用途で一般的に使われているか位は
勉強してから書き込んだほうが良いと思うよ Docker ファイルは書きたくないマイナーなアプリケーションを使いたいということかそれがシステム D 依存している？
と言うかアプリの起動方法を調べてないということね
必要なのはDockerではなくてアプリの起動方法じゃねーのか？ よく分からんけどアプリの起動なんてバイナリ叩けばいいだけじゃないの？ あるソフトを導入したい
→Webで調べて個人ブログ等を見つける
→そのままの手順でDockerに導入
→systemctlが使えない！systemd入れなきゃ！
的な感じでは >>183
これ馬鹿にしたもんじゃないよ
ブログ真似するだけで出来なけりゃ便利じゃない。
サービスはsystemctlで起動するのが当たり前なのに
技術的や思想的な理由でその常識を覆されたら
ユーザーはガッカリする。
「systemctlも使えなかったわ。Dockerって不便だね。」
こういう意見は真っ当な評価だよ。 > サービスはsystemctlで起動するのが当たり前なのに
誰が言ったんですか？ 自分が作ったアプリがsystemdで起動するのが当たり前って無いなぁ
わざわざsystemd対応しなければいけないんだが 既存のDockerイメージを見ても、systemdで起動してないのが当たり前だよ
常識の話をするなら、systemdを使わないのが常識だろう
それを覆すなよ >>188
それはDockerの常識だよ
普通のhttpdやmysqldは
通常systemctlで起動するのが常識
yumやaptしたらあとはsystemctl叩けばいいだけだって
誰だって思う
利用者は当然Dockerの中でもsystemctl叩けばいい
って自動的に思う
バイナリの場所やPIDファイルの場所なんて
誰も覚えてないよ
それをシェルログインして調べなきゃならなくなった時点で
便利じゃない
Virtualboxにしときゃ良かったって後悔し始める
人が出てもおかしくない 赤帽で動いてる既存システムをとりあえずなるはやでdockerizeしたいときに便利そう←SYSTEMD >>189
既存の資産やスキルセットが再利用できない点は問題だと思う
SYSTEMDを認めたうえでベストプラクティスを追求するとシングルプロセスになるぐらいのバランス感覚がちょうどいい >>191
systemdのサービス設定ファイルを読んだら、実際ちょっと肩透かしだからな。ｗ
こんだけでええの？ていう。
systemdを悪くいう人もいるが、initスクリプトに比べたら超マシだと思う。 >>189
> 普通のhttpdやmysqldは
> 通常systemctlで起動するのが常識
ディストリによる
systemdが使われてないディストリもある
そのことからもわかるように、httpdやmysqld自体は
何で起動するかなんか関係ない >>193
その「こんだけでええの？」を
Dockerで実行するだけなんだが（笑）
だからsystemdなんかいらないわけ >>189
> yumやaptしたらあとはsystemctl叩けばいいだけだって
> 誰だって思う
だからインフラ屋はアホなんだよな・・・
httpdとかmysqldなんかは、Dockerが公式に用意しているイメージを使うだけ
そういうイメージは自分で作ったりしない
インフラ屋がイメージ作るとしたら、それしかないというのはわかるよｗ
でもイメージを作る必要があるのは自分（自社）で開発したアプリなの
yumやaptで入れて終りなら、そんなものDocker使う必要ないの >>194
「検索して調べたらsystemctlで起動って書いてあったんだよムキー！」
そういう人はsystemd入れりゃいい >>189
> Virtualboxにしときゃ良かったって後悔し始める
> 人が出てもおかしくない
この一文が決定的だな
1. Dockerを仮想マシンだと勘違いしてる
2. 仮想マシンと同じようにsystemd使おうとしたら、なんか大変だ！
3. （勘違いしてる俺のやり方は）大変だ！
と叫んでるだけ インフラ屋連呼してる奴もちょっとズレてるっていうか頭おかしいな
対立軸はインフラとアプリじゃなく
自分で調べられるか書かれてることしかできないかだろう 開発者は、Docker知らない→知れば便利だな！ってなる
間違った使い方はしない
間違った使い方をするやつはインフラ屋
Docker→mysqlを動かしてみよう！→systemd
こればっかｗ インフラ屋は、勘違いばっかりしてるから必死にDockerでsystemdとか
mysqlとかnginxとかいう既存のサービス（だけ）を動かそうとして四苦八苦してるの。
Docker公式のイメージが用意されてるのにそれを使わずに
Dockerfileを自分で作ってる（再発明してる）
そしてデータを永続化するにはどうすればいいんだーってなやんでるｗ
そうだ、その問題があったな。systemdはDockerで使うようには作られていないので
ボリュームをどうするかとかログをどう転送するかとか自分でやらないといけない。
自分で開発したアプリは、自分で作ってるわけで、どうすべきかは最初からわかってるはずのことだが
パッケージで入れるサービスはそれらをしっかり調べないといけない
Docker公式イメージはそういうところも考え作られてるわけでそれを使うのが標準的なやり方
（もし足りない所があれば自分でカスタマイズすればいい）
インフラ屋は今まで自分でパッケージをインストールしてきたプライドでもあるんだろう
Docker公式が用意しているものまで自分でやろうとする。
Docker使ってるのにディストリの一般的なやり方（Dockerに最適化されてないやり方）でやろうとする そして公式イメージないと何もできない雑魚が出来上がったわけだ systemdが〜をやってるやつが次言い出すのがcapabilityが〜なんだよなｗ
動きません。capabilityが〜
動きましたが、capability で〜
目に見えてるなｗ
>>203
自分で開発したアプリをDockerイメージにするんだよ？
自分で開発してるアプリは公式イメージなんかないじゃない
インフラ屋は「自分で開発したアプリ」がないから大変だよねｗ
すべてDockerが公式で用意してるから、何もできない雑魚になるよねｗ 自社製品のbuild出来なかったらただの馬鹿じゃん
他社製品の話な
まあアプリ屋には無理だろうけどｗｗｗ >>205
Dockerは自社製品を簡単に配布するためのものですが？
ディストリ標準のパッケージなら
パッケージマネージャ使って簡単にインストールできるんだから
そもそもDockerなんかいらんだろｗ 普通は他社製品のイメージもなきゃ作るんだが
アプリ屋には荷が重かったかｗ どうしてもなければ作りますが？
もちろんsystemdなしでね
Dockerの正しいやり方で作ります >>208
無理しなくていいんだよ
アプリ屋さんには難しいだろうｗｗｗ じゃあ簡単にできるsystemd使わない方法を
使うってことでこの話はおしまい え？Dockerの中ではsystemdを使わないのが正しいって
合意取れたでしょ？ 俺はsystemd使わないし、お前も使わないだろ？
もしかしてお前にとっては難しいの？
簡単だよねｗ お前にとっては難しいかもなｗ
自社製品か公式イメージないと何もできないんだものｗ 俺じゃなくてお前が簡単だからsystemd使わないんだろ？
ほらやっぱり合意取れたじゃんｗ 外野が「原則」をわめいても。ｗ
使う人間が使える範囲でうまく使えばいいんだよ。
systemdで使いたいなら、「原則」しか鳴らない壊れたレコードは無視して、いろいろがんばれ！
できなきゃあきらめろ。。。 開発してるDocker社がsystemdを使ってない
これが決定打だろｗ ■ このスレッドは過去ログ倉庫に格納されています
