コンテナ型仮想化Dockerスレ その2
レス数が950を超えています。1000を超えると書き込みができなくなります。
コンテナ型仮想化を提供するDockerスレ
Dockerは
1. アプリケーションコンテナです。 システムコンテナではありません。
2. アプリケーションのポータビリティを目的として利用します。
3. 仮想マシンではありません。 仮想マシンとは目的が異なります。
4. 仮想マシンと共に使用することが多いです
5. WindowsとmacOSの両方で動きますが、どちらも仮想マシンを利用します。
6. コンテナの中にSSHでログインしようとか考えないでください。そういうものではありません。
7. コンテナの中では原則として一つのアプリケーションを実行します。
8. Dockerfileを使ってイメージを作ります。Ansibleとかやめてください。
9. イメージを作るのはアプリケーション開発者の仕事です。インフラの仕事はつくられたイメージを動かすことです。 最近変なタイトルのIssueがあるんだけど、これなんなん？
p
https://github.com/docker/for-mac/issues/3932
DC648016-4F9C-4843-9893-36342A7BDDDD/20190929101426
https://github.com/docker/for-mac/issues/3931
diagnostic id: EC18250C-A343-42BA-87F9-541F6C313972/20190701050324
https://github.com/docker/for-mac/issues/3736
660DB17B-4783-4094-BAAF-63334E15D74F/20190701210105
https://github.com/docker/for-mac/issues/3739 オープンソースなんてそんなもんだよな。
どんなに優れたものを作ってもそれが金になるわけじゃない
金が入ってくるための何かを作らなければいけないが、
クラウド各社は自前のdockerリポジトリを提供してるし、
オーケストレーションもKubernetesに奪われた anacondaなんか何で儲けてるんだろうな？不思議だわ。 Docker 19.03.4リリースされたけど、Mac版でまれにフリーズする問題、まだ直ってないね。
Catalinaに変えてからこころなしフリーズしにくくなってる気もするけど
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
https://github.com/docker/for-mac/issues/3873 Dockerはもうオワコン
これからはpodmanが覇権 podmanが覇権とったらまた来てくれや
なんだっけ？ロケット？とかあったな podmanに乗り換えた
これもうdockerは要らねえな パイプライン系のサービスは今後全部podmanに置き換わるだろうな
インフラ構成とエージェント実装がシンプルで軽量、安全になるから導入しない理由がない docker buildとdocker create の2つはなにが違うの？ Dockerイメージと、Dockerコンテナの違いをまず知ろう
イメージはファイルをかき集めて実行ファイルを作るようなもの
コンテナはその実行ファイルを実行してプロセスを作るようなもの
docker buildはDockerイメージを作る
docker createはコンテナを作る
ただしdocker createはあまり使わない。普通はdocker runをつかう。
createはコンテナを作るだけで実行しない。起動したプロセスを
すぐに一時停止するようなものだから 公式がtag管理してない(latestしかない)imageのスナップショットを保存しとく手軽なサービスねえかな >>17
まず
10テラのハードディスクを買ってきます docker toolbox使ってんだけど、
virtual boxが時々壊れるっぽくてコンテナが消える。 rootless dockerなんてあるんだ
実用レベルなのかなこれ 無計画にばかすかデプロイする連中がありがたがってるようだけど
そうじゃなければ使う価値のないツールだったなDockerってやつは docker for macでcpuが貼りつきまくるんだけど、みんな仮想環境で立ててる？ 前任者が退職した非DockerアプリをDockerizeしなければならなくなった
とりあえず依存パッケージを洗い出して、コード全部イメージに固めて、動作するとこまではいけた
しかしボリュームにすべきディレクトリがわからない
ソースは膨大かつ古いスパゲッティコード
普段、使ってない言語なので読むのも厳しい
依存パッケージの入出力もありえる
出力先が/varに纏まってるなんてこともなく、コードによってバラバラ
こんなときどうすればいいんだろう
システム全体のIOを監視しながら運用して、書き込みがあったディレクトリをバックアップ、ボリューム拡張、リストアを繰り返していくしかないのかね overlayの最上層だけ観察するなりバックアップするなりすればいいのでは？ なるほどそうかボリュームにこだわらなければできるか
とりあえず一時しのぎとしてdocker commitでまるごとバックアップするわ
時には初心に帰ることも大事なんだな dockerはカーネルを共有してるということはカーネルバージョンを上げたら今まで動いてたコンテナが動かなくなる場合もあるってことでいいんですかね コンテナからホストへのアクセスを全遮断してブリッジ経由での特定のコンテナへのアクセスのみ許可したい場合どうすればいいですか？ 自作イメージの環境変数サポートって面倒ですね
shに慣れてなくて難しい オフィシャルイメージを使う分には楽
イメージを作るのはめんどくさいわりにメリット少ない dockerイメージを動的にビルドして
エクスポートできるIDEってないの？ >>35
> dockerはカーネルを共有してるということはカーネルバージョンを上げたら今まで動いてたコンテナが動かなくなる場合もあるってことでいいんですかね
可能性としてはありえるが、カーネルは極めて厳密に互換を保つことになってる
互換性が切れる更新は事前に周知するとかいうレベルじゃなくて
互換性が切れるような修正がカーネルに入るとリーナスがブチ切れる
バグ以外ありえない。そしてそれはすぐに修正されるだろう。 >>38
誰がなんと言おうが人類は永遠に
POSIXシェル（スクリプト）から逃れることはできないのだよ
シェルスクリプトを勉強しろ
文法がーとかぶつくさ文句言ってないでプロとしてちゃんと勉強しろ >>45
間違ってるか？
DockerなんてTomcatみたいなもんやろ
IDEに組み込んでソース保存ボタン押す度にイメージごとビルドして欲しいわ 単にgulpとかでwatchすればいいのでは？
でも開発中はイメージビルドは避けてマウントしたほうがパフォーマンスいいよ Docker黎明期のわくわく感がなくなって久しい
次のイノベーションはまだか 次の大きな変化がもう予想できない
来るとこまできた感あるだろ 動的にイメージビルドする必要が本当にあるのか普通は考える。 どんなに仮想化や自動構築が進化しても
大元のホストマシンのwindowsの
自動プロビジョニングはどうにもならんという現実 Windowsの自動プロビジョニングならすでにあるぞ
各PCメーカーがやってるだろ。まさか手動でセットアップしてるとでも思ってるのか？ https://ja.wikipedia.org/wiki/Sysprep
Sysprep(System Preparation Utility)とは、マイクロソフトによるWindowsオペレーティングシステムを
展開するためのシステム準備ツールの名前である。現在このツールの実行ファイル名はSysprep.exeである。
Sysprepは、Windows NT 4.0で初めて導入された。Windows 2000やWindows XP用のSysprepが
現在マイクロソフトから入手可能である。Windows Vistaは、製品パッケージからのインストールにSysprepが使用される初めてのバージョンである。 >>58
なんだこれ？初めて知った
仕事で物理マシンを何十台と用意しなけりゃならなくて、
質問ばかりですまんが
virtualboxやvagrant
のインストールや初期セットアップもこれで可能なのか？ HashiCorpの新オーケストレーションツールTerraformを試してみた
https://dev.classmethod.jp/articles/terraform-first-impression/
AWS CloudFormation みたいなもの
Ruby 製のVagrant の作者、今世紀最大の起業家と言われる、
Mitchell Hashimoto(HashiCorp)は、最近は、Go で有名 Windowsのプロビジョニングは経験上「できないこともない」レベルのツールばっかりでいまいち信用できない
GUIインストーラしかないツール、インストール後の設定がGUIからしかできないツール、再起動が必要なツール
そういうのが多くてな お前が信用できないと思ってるかどうかは関係ない
できるという事実を認めなさい できる、と、うまくできる、簡単にできる、には隔絶があるんだがな >>64
わかる。Windows提供のツールは
できる だけで便利さとかは追求してない感
MSに限らずプロプライエタリソフトは特有の
信用できない感あるよな Windowsは例の新しいパッケージマネージャが安定してからスタートラインでしょう >>60
その２つならchocolateyで十分じゃね？ 初期セットアップなんか、レジストリかXMLファイルをコピーすればいいだけだろ コピーとかコマンド入力するだけじゃね？
ってか、Macでも自動化できんよね。
LinuxのGUIアプリで自動化できるの？ Windowsのアプリはなぜか設定ファイル仕様が書いてないことが多くて困る
GUIで設定するからファイル仕様は要らんということなのかな >>73
ベースのイメージ作って焼くだけじゃないの？ >>75
イメージの配布はネットワークインストール？ Windowsはよく知らんけど、クライアントの所属ドメインの設定だけやっちゃえば、
あとはActiveDirectoryが自動で、ネット経由で、必要なツールのインストール、OSのパラメータ変更、してくれるんじゃないの？ もうUSB接続プラグ＆プレイで自動プロビジョニング開始してくれなきゃ便利じゃない MacのCPUがARMに変わったら、Dockerのイメージファイルを作るのも大変になるな
実機と同じイメージを使うわけにはいかなくなる >>79
パラレルデスクトップ動作するという情報あるな あれはハードウェア支援なしのエミュレートなのかね Macはもともと複数アーキテクチャのコンテナ実行をサポートしてるから問題ないだろう VSCodeでサーバで動かしているDockerにAttachしたいです
クライアント側(Windows)でDockerデーモンを動かす必要があるらしいのでDockerを入れたのですが、起動するだけでメモリが1GBくらい使用されてしまいます
Dockerデーモンだけを動かす方法ってないですかね？ 悲しいことにサーバ側の権限がミスってただけっぽいです
わざわざクライアントにDocker入れたのにorz Windows版のDockerDesktopについて質問。
docker-machineコマンドがないんだけど、ホストのカーネル？でコマンドを実行するにはどうすれば？
要するに、docker-machine sshがしたいんだけど。
ぐぐると、Githubにexeファイルがあったから、ダウンロードして試してみたけど、マシンをリストできなくて、どうやら別物臭いと判断したところ。
Desktop移行前後で違うんやろなと。 machineはdocker環境の作成とmachineで作った環境の管理行うツール
別の方法で作った環境は管理外 >>85
わかるけど。。。
Docker Desktopが正規につくってるはずのホストが「別の方法」と言われると困るな。
つまり、Docker Desktopでdocker-machine sshに相当することはできない？ できない
正規だろうが非正規だろうがdocker machineで作ってないならdocker machineの管理外 sshで繋ぎたいならわざわざdocker machineを通さず直接sshすればいい >>88
ssh接続したいのは、コンテナではなく、その下で動作しているであろうホストなんだけど、直接接続する方法がある？
接続先や、ユーザー+パスワードがわからなくない？
そのへんがわからなくてもうまく接続してくれるのがdocker-machine sshだと思ってたんだけど。 >>89
docker machineは仮想マシンやSSHで既に接続できるホストに対してセキュアなdocker環境を構築するツール
仮想マシンの場合は構築時にSSH鍵の登録も自動でやってくれるのでdocker machine sshでssh接続できるようになる
そうでない場合は先に直接SSH接続できるように設定しなければならない >>90
Docker Desktopの場合、そのへんが見えないんだよな。。。
インストール時にサービスが構成されて、その中でなんかうまくされてる感じ？
# 名前つきパイプでやりとりしてるみたいだし。
まあ、とりあえずWindows版ではできない、と理解しておく。
ありがと。 Windows版はdocker machineとは全く関係ない別の方法で軽量仮想マシンかWSL2のインスタンス上にdockerを構築する
それ+Windows用のコマンドラインインターフェイスを合わせたパッケージがDocker for windows
最初からdocker machineなんて使ってないからdocker machine sshしてもいみない >>92
ほかはともかく、ホストにアクセスする機能はあるべきだからあるはずだと思ったんや。。。
コンテナがホストのリソースを使うんだから。dateとか。 > docker-machineコマンドがないんだけど、
インストールすればいいだけじゃん Windows版とmacOS版のDocker Desktopには
docker-machineはデフォルトで含まれてないの知らないのかな？ >>94
具体的に、どれをどうインストールすればよいのかを頼む。
DockerDesktopは仮想ホストを非公開で抱え込んでるので、docker-machineコマンドは対応していないと認識したんだが。 >>96
Docker Desktopとdocker-machineは何の関係もない
docker-machineはどこか遠くにあるどれかを使うためのものだろ >具体的に、どれをどうインストールすればよいのかを頼む。
ぐぐれかす >>97
話を理解してないことを把握。
もうええ。 >>100
話を理解してないのはお前。
docker-machineを使うのにDocker Desktopは必須ではない Docker Desktopっての触ったことないから詳しくは知らんがdockerのサービスが動いててdockerコマンド使えるんじゃろ？
そうならdocker execでコンテナ内のコマンド実行できるしシェル立ち上げたいならそのシェル指定すればいい コンテナじゃなくてデーモン動かしてるVMに接続したいって話だったんだねすまん勘違いしてた そういうこと。だからdocker-machine使うのにdockerクライアント（Docker Desktop）なんかいらんわけ
だからこそWindows版とMac版でDocker Desktopからdocker-machineを取り除いたんだろう
（Linux版は元から含まれてない）
だーかーらー、普通にdocker-machineをインストールしろと >>104
大元コメの目的は、DockerDesktopで稼働している仮想ホストに接続すること。
仮想ホストをあえて構築することではない。 WSL2 integratedをONにしてUbuntuのDockerコンテナをインストールしたのですが、
このコンテナにWindowsのフォルダをマッピングしたい場合ってどうすれば良いんですか？
volumes:
- /mnt/c/hogehoge:/hogehogeでマウントしてみたのですが、
win側のファイルはUbuntuに反映されず、Ubuntu側のファイルもWin側に反映されませんでした C:/ならマウント出来た…
まさかのWinのパスのままでマウント出来るとは… >>108
dockerは仮想マシンじゃないと何度言えば理解できるんだ？ >>109
仮想マシンじゃないこととsystemdってなんの関係もなくね？ >>110
仮想マシンじゃないからsystemdを動かすという用途がない >>108
動作させてる人をネットで見かけた気がするが、ダメだったのか？
要は、systemdプロセスを手動できっちりおこしたったらええんちゃう。
>>109
仮想マシンとして使うのも勝手やろ。
どう使うかは人それぞれ。
それで本気サーバーにするのはさすがにアカンとは思うが。 > 仮想マシンとして使うのも勝手やろ。
今の自分の現状を見てみろ
仮想マシンとして使おうとして
苦労してるだろうが は？
「自分」て誰？ｗ
どうでもええけど、じゃまばっかすんな！ >>108
システム D でデーモン自体は起動してるよね スクリプト書けば使えるけどね
でもDocker自体に自動起動の設定あるよね 別にsystemd入れりゃ動くんじゃないの
アプリケーションコンテナに使うにはオーバースペックだけで
代わりにsupervisordやmonitを使ってる例も多い いやいや
もんだいなのは巷で提供されている
ライブラリのほとんどが
systemdだけを前提としたものになってて
yumやaptでインストールしても起動出来ないものばっかに
なってるよ いちいち嘘つくなよ
> ライブラリのほとんどが
> 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を使ってない
これが決定打だろｗ ところがredhatはsystemdイメージをサポートしてる
公式イメージと自社製品しか扱えない野良のアプリ屋さんとredhatのスーパーエンジニア達ならどちらを信用するべきか？
はいアプリ屋さんチェックメイトｗ すまんが、ちょっと言い争われてる周辺の問題(？)について教えて欲しいんだけどさ
Code-serverのコンテナと.Net Coreのコンテナって、こういう関係のものはどうやって組み合わせて使うもんなの？ >>220
アプリ屋さんによると公式イメージを待つみたいだぞｗ >>219
一番信頼性があるのはDocker公式じゃね？ｗ >>222
今は野良アプリ屋さんとredhatの比較してんのｗ
>>223
野良アプリ屋さんの代理で答えてやったぞｗ 海外で便利な技術が出来たところで
結局日本の技術者は新しい物を受け入れる事ができずに
自分らが楽出来るように曲解して魔改造して独自仕様を作り出す
だから日本のIT業界は世界標準から取り残され
ガラパゴス化して更に世界から取り残される
遥か昔から現在迄その流れは変わってない
Dockerなんて既に海外では標準的な仕様で
既に枯れてると言ってもいいぐらい当たり前な事なのに
それすらも受け入れる事はできない
それでも日本の開発者は一昔前と違って世界から取り残されないけど様に
必死に勉強して新しい物を受け入れる努力をしてると思う
目まぐるしく変わる開発言語や開発手法とか勉強して取り入れてってる
でもクラウド化の波も読めずに乗り遅れてサーバインフラという
大事な主戦場を失ったインフラ屋は
また新しい既得権益を産み出すために新しい技術を使って
今までの既得権益を復活させようとしている
お前ら何も学んでないの？
馬鹿なんじゃないの？ systemdが無いとアプリ動かせない・・・？
アホか
お前らどんだけレベルが低いのよ・・・ >>225
ヒマなの？ｗ
オレオレ一般論はどうでもええんやけど。 流れぶった切ってすまんが
Docker ComposeとNVIDIA Container Toolkit使ってGPU使うにはどうすればいいの？
Nvidia Docker2使えってのもあるけどこれ結局NVIDIA Container Toolkitの代わりに(古い)Nvidia Docker2使ってるだけじゃないの？ >>228
呆れてんだよ
スレ伸びてるから何かと思えばこんなだし
低レベル過ぎるわ あまり関係ないけどガラパゴス諸島って世界中から超人気だよな runコマンドのmemoryとshm-sizeの違いって何？ httpdやnginx mysplだって
公式イメージダウンロードしてそそのままは使わんだろう
コンフィグごちゃごちゃいじるだろ
そういう時restartないのは面倒だよ
構築作業のデバッグ中に何度もイメージリビルドすることになる
dockerのbuildは中で動いてるコンフィグファイルの
エラーチェックまではしてくれないからな
systemdないとデバッグめんどいよ
プロセスもいちいちpidからkillしないといけないし >>229
Container Toolkitインストールした時点で普通に使えない？ >>237
> 構築作業のデバッグ中に何度もイメージリビルドすることになる
なにか問題が？
設定ファイルコピーするだけなんだから
一瞬で終わるだろ まさかdocker execでdockerの中に入って設定ファイルをいじって
systemdでrestartしてるとか？
そしてdockerの中でやった設定ファイルを
いちいちdocekerの外にコピーするのか？
手間かかるだろｗ >何度もイメージリビルドする
Ruby on Rails では、あまりにも手間が掛かるため、
自分のソースコードをコンテナに含めるなって書いてある >>243
それはお前の勘違いだからさぁ
どこに書いてあるのか言ってからにしろな
それはまではただのデマ扱いするから 開発中はソース、設定ファイルをマウントしてコンテナ起動させっぱなし
docker buildは遅いからやらない
docker buildはCIでやるのが常識 開発中はコンテナを使わない
テストのときにコンテナを使う ベアOSでもいいし、WSLでもいいし、仮想マシンでもいいよ
どちらにしろテストはDockerでやるから 開発もコンテナでやったほうがいいぞ
12Factorを尊重しろ >>250
12Factorにはコンテナを使えなどとは書いてない >>251
12Fには開発環境と運用環境をできるだけ揃えろと書いてある
つまり運用がdockerなら開発もdockerにすべし
しかしものには限度というものがあって開発にdockerを使うからと言って毎回buildしていたら遅くてツラミを感じる
折衷案として開発時はdockerを使うがbuildせずソースマウントで妥協するということだ >>252
できるだけ揃えればいい。手段は何でもいい。
rbenv等を使うのも手だ >>253
コンテナと非コンテナという時点で差が大きすぎるので何やっても無駄 ？
だれもコンテナを使わないとか言ってないよ
テストでコンテナを使う 今は開発の話をしてる
流れ読めないなら口出ししないで ああTDDしてないのかｗ
テスト駆動開発
テストによって開発を駆動するんだよ テストフェーズと開発フェーズの区別もつかんのか
今は開発フェーズの話をしている
話に付いてこれないなら口出しするな 開発時は、sshdをCMDして、ターミナルからsshでいろいろ試すのがやりやすくない？ >>258
だから俺が言ってるテスト＝TDDにおけるテストは
開発フェーズでやるんだよ。知らないようだから勉強しろ！ >>260
それ間違ってるぞ
TDDのテストはCIで行う
CIで行うテストは開発フェーズではなくテストフェーズ
そもそもテストとはリリース可能なバイナリに行うものだ
手元のコードベースにテストしたってそれはリリースされない
リリースされるのはCIでビルドしたもの
お前がやってるのはテストじゃなくデバッグに分類される 開発中にsystemdつかってて
Dockerに移植したら「あっsystemdないの…(察し)」
ってなるんですね。胸熱だなおい。 >>262
普通にありえるな
docker環境と非docker環境の間にどんな違いが隠れてるか、すべて把握してる開発者なんて少ないだろう
だから、開発はコンテナの中で行うべきなんだ >>261
> TDDのテストはCIで行う
そんなこな言ってる有名人は一人もいない >>262
systemdに依存するソフトウェアをお前は作るの？
バカなの？そんなコトしてる人なんて誰ひとりとしていないのに >>261
> TDDのテストはCIで行う
> CIで行うテストは開発フェーズではなくテストフェーズ
それであなたの場合TDDのテストのCIはどのタイミングで実行されるんですか？
テストフェーズにならないと実行しないのにCIなんですか？ >>266
CIでテストしてるときがテストフェーズだよ
なに当たり前のこと聞いてんだ ここの香具師は、Ruby on Rails のHeroku とか知ってるのか？w
GitHub を更新すれば、CircleCI で勝手にテストするだけだろw
CI/CD パイプライン
ビルド・テスト・デプロイの自動化 >>267
聞いてるのは、そのCIによるテスト（テストフェーズ）は
いつ（どのタイミングで）実行されるのかということなんだが？ >>270
それで、そのCIパイプラインはいつ走るのですか？
開発フェーズじゃなくてテストフェーズにならないと走らないんですよね？（笑） >>271
ほんと理解力ねえな
テストフェーズになったら走るんじゃなく
走ったらテストフェーズになんだよ >>272
なんで質問に答えないの？
CIが走る＝テストフェーズになるのは
どのタイミングですか？ CI使ったことがないからどのタイミングでCIが実行されるのか知らんだろうなｗ >>276
トリガーの一例ともっとも短いタイミングで発動する
トリガーを言ってみてくれますか？
>>277
TDDにとってこれ重要なことなんですよねw もっとも短いタイミングというのは、
あなたが考えうる一番短いタイミングでいいですよ
別に正解を聞いてるわけじゃないので
1. TDDのテストはCIで行う
2. CIで行うテストは開発フェーズではなくテストフェーズ
3. CIは○○のタイミングで実行される。○○のタイミングでテストフェーズになる。
>>261の主張であるこの文章のの○○を埋めたいだけです。 >>279
コミット時に決まってんだろ
くだらない質問はするなってなんど言わせる気だよ >>281
え？お前はテストフェーズで何をするの？
コミットしたら勝手にテストフェーズになって
CIのテスト実行が終わったら、テストフェーズ終りってことだよね
つまりお前がテストフェーズでする作業は何もないってことだよね
あのね。それ開発フェーズっていうの
（ソースコードを修正して）ソースコードをコミットをする作業は
開発なんだから開発フェーズなんだよ
はい。おしまい。 コミットしないとテストを実行しない（実行できない）って
最悪のパターンだってこともわかってなさそうｗ >>282
なにいってんだおめー
コミットするまでが開発だろが
CIがテスト回してる間も開発に含めたら給料泥棒になるぞ >>283
誰もんなこと言ってねーだろ妄想激しいな
トリガーはコミット以外にもある
なんなら任意のタイミングで実行可能 >>285
> コミットするまでが開発だろが
それ反論じゃないよねｗ
俺は「コミットするまで」＋「コミットしても」開発だって言ってる。
コミットしたからと言って勝手にテストフェーズになったりしない。
テストが実行されるだけで、明確に開発完了と言わない限り開発フェーズのままだ
お前はコミットが終わってCIがすぐ実行されたら、それがテストフェーズだと言ってるようだがなｗ 世の中、無知が多すぎる
開発中にCIのトリガーを押したからと言ってCIパイプラインが開発に含まれるわけねえだろ
CIパイプラインではビルド、テスト、リリースなどのフェーズが実行されんだよ
開発中に手元では走らせるテストはテストじゃなくデバッグだ
なぜなら手元のソースはテスト対象じゃないからだ
本物のテスト対象はCIでビルドしたバイナリだ
これに対して行うテストはCIパイプラインに含まれる
それがテストフェーズだ テストはCIでも動かすし手動でも動かす。
コミットしなくても動かす
CIでテスト実行するのはおそすぎる
TDDというのは（コミットせず）ローカルで
テストを書いてコードを修正しての繰り返して開発する
そして修正がが完了したときにコミットする。
修正完了＝開発完了ではない。
開発の途中で細かい修正ごとにコミットをする。
まあ常識やねｗ >>289
> ビルド、テスト、リリースなどのフェーズが実行されんだよ
無理に日本語使うのやめたら？ｗ
フェーズっていうのは「段階」「局面」って意味だ
https://dictionary.goo.ne.jp/word/%E3%83%95%E3%82%A7%E3%83%BC%E3%82%BA/
ビルド、テスト、リリースなどの段階が実行されんだよ
↑お前用語の使い方おかしいｗ
段階が実行ってなんやｗｗｗｗ TDDをやるとテスト回数が増えます。
つまりコミット数が増えるということです。
ソースコードを修正してテストを実行する時は必ず
コミットしてCIサーバーで実行しなければいけません
とかいいだすんかな（笑） >>295
代替技術がオリジナルを超えた例はないから テストはテスト班に手動でやってもらうのが1番楽だな
テストデータ用意も
バグの検出も人間が勝手にやってくれた方が楽
究極の自動化だと思うが > テストはテスト班に手動でやってもらうのが1番楽だな
それは統合テストなどの話
単体テストをいちいち別の人にやらせていたら時間がかかってしょうがない。
TDDならなおさら。最初にテスト書いてそれに通るように実装を書くんだから いやいや、統合テストしかしないよ
単体テストとかしませんが、
何か問題でも？ >>298
だからそれはデバッグだって
作ったものを確認するのがテスト
作りかけの物を動かしながら問題を分析したりコーディングをするのがデバッグな
これ新入社員レベルの知識だからワカッテナイト恥ずかしいよ TDDではコードを書く前にテストを書くんだから
バグなんてないのにデバッグ（バグ修正）とか意味不明ｗ
デバッグ
https://www.weblio.jp/content/%E3%83%87%E3%83%90%E3%83%83%E3%82%B0
三省堂 大辞林
コンピューターで、プログラム上の誤り（バグ）を発見して訂正すること。
IT用語辞典バイナリ
デバッグとは、ソフトウェアにおけるプログラムのバグ（誤りや欠陥）を探して、正しく動作するように修正する作業のことである。 >>301
おいおい大丈夫か？
UNITテストNGのコードにバグがねえわけねえだろ 「バグ件数」を計測したことがあればわかるはずだが？ >>305
「バグ」
にはシステム的なエラーや
応答不能
エラーは起きてないが
意味的に表示が違ったり
「思ってた処理と違う」って言うものまである
だから「何がバグか」の定義とか
実行のしかたで、件数結果なんで全然変わってくる
それこそテストやバグ調査の経験ある奴なら
そういうことは理解出来てるはず。
やたらバグ件数がとか
カバレッジがとか吠えてるやつは能無し
カバレッジを上げたけりゃバグの判定を緩くすりゃいい
でも、それは本質じゃない
テスト駆動とかCIとか余計なこと考えてる暇あったら
コーディングスキルと経験積んで
「こんなことしたらバグになり得るな」という
勘を養うのが一番の正当な考え方 以上。バグの定義とかいうどうでもいい話をする>>306であった
あほだな。 バックエンドでdockerで
動いてるけどdockerを使ってること自体を意識せず
dockerを完全に隠蔽して
裏でビルドしてコンテナ起動してくれる
webフレームワークがあったら素敵じゃね？
ていうかあってもおかしくないよな
ホストマシンでappソースディレクトリの内容を
アプリ起動時にイメージに取り込んで勝手にビルド
してから起動するわけよ >>309
そういう "webフレームワーク" だったら
センスが無いなって思う
依存する必要がないものに依存しているから
webフレームワークを作るなら
DockerでもDockerを使わなくても動くように作る
そういうのはサポートツールとして作るべき
LiveReloadツールとかそういうシステムが面倒を見る 試しにWindows10 home上でdockerを動かしてapacheを稼働させているのだけど、ブラウザから見れないのは何が足りていないのだろうか。 >>312
localhostForwarding=True >>312
docker run -p 80:80 >>313
>>314
糞ありがとうございます！
あと当たり前なのだろうけど、dockerのipアドレスがあったんだね。 > dockerのipアドレスがあったんだね。
そういう話じゃなくて起動したapacheコンテナが
（デフォルト設定だとして）ポート80で待ち受けてないってこと
コンテナの中のapacheはポート80で待ち受けているかもしれないが、
コンテナ内に閉じ込めているためそのままでは公開されない
これは可搬性が高くなるというメリットにつながる
内部のapacheはポート80で待ち受けていながら、
dockerの力で自由にポート番号が変更できる
つまり待ち受けるポートというのは
コンテナを起動するときのオプションで指定するものになる >>316
いや、そもそもwsl2はホストと異なるIPアドレスだから、localhostにforwardingしてやらないと、いくらポートをマッピングしてもだめでしょ >>317
WSL2の話は関係ない。
Dockerは、内部で使われてる機能の問題を解決して
localhostで接続できるように作られてる
つまりlocalhostでコンテナに接続できるのは
Dockerが提供している機能だということ あ、まさかDocker Desktop for Windowsを使わずに
面倒なことしてんのか？
公式でWindowsはこれを使います！って
提供してるんだからそれを使えよ
それを使わないから苦労するんだろ？ >>319
今はそのバックエンドとしてWSL2使うのが推奨されてるでしょ？しかもWindows Homeって言ってるから >>319
WSL2を使えって公式が言ってんだからそれを使えよ
"For backward compatibility reasons, we kept the possibility to interact with Docker from the Windows CLI, but it is not the preferred option anymore."
https://www.docker.com/blog/docker-desktop-wsl-2-best-practices/ ああ、やっぱりわかってないｗ
だから「Docker Desktop for Windows」の
バックエンドがWSL2に切り替わったんだよ
HyperVに戻す設定もあるかもしれんが
だから今までもこれからもWindowsで使うのは
何も気にせず「Docker Desktop for Windows」を使う
Dockerが推奨してるのもこれ Docker社は
・WSL2にDockerインストールして使え
と言ってるんじゃなくて
・「Docker Desktop for Windows」の設定で「バックエンドとしてWSL2」を使え
といってる
おまけ 参考
https://www.atmarkit.co.jp/ait/articles/2007/01/news013.html >>322
バックエンドでWSL2が使えるようになったのは>>320で書いてるんだけど読めないの？しかも明示的に変更しないといけなくて勝手に「切り替わる」ことなんてない >>323
どうでもいいけど、なんでそのULRなんだろうねw 「dockerのipアドレスがあったんだね」って言っていることから、WSL2を使ってLinux側で使っている可能性が高い。Linux側は独自のIPアドレスもってるからね。 >>313に言ってるんだよ
Docker Desktop は localhostForwarding=True の設定は関係ないんだから >>323
せっかくブログ教えてあげたのに読んでないの？
"Your project files should be stored within your WSL 2 distro of choice, you should run the docker CLI from this distro, and you should avoid accessing files stored on the Windows host as much as possible." めんどくせーからGoogle翻訳な
「プロジェクトファイルは、選択したWSL 2ディストリビューション内に保存する必要があります。このディストリビューションからdocker CLIを実行し、Windowsホストに保存されているファイルにはできるだけアクセスしないでください。」
だれがプロジェクトファイルの話なんかしてんだよ。apacheへの通信の話だろ
お前が読めてないんだよ
英語わからないならGoogle翻訳でも使ってよめや
今は結構精度良いぞ >>335
だってブログの内容をまともに理解できてないやつに何言っても無駄でしょ？ >>336
だからブログを読んだだろ？
お前が引用した部分は、そこ書いてあるとおりに読んだ
意味は日本語訳に書いてあるとおりだ。
次はお前の番だよ。
翻訳がおかしいというのなら、正しくはどういう意味かを言うべきだろう？
違うか？ >>333
Linux側からdocker CLI使えって書いてあるのは無視なの？ >>340
> Linux側からdocker CLI使えって書いてあるのは無視なの？
見事に墓穴ほったね（まあ狙ってやったわけだがｗ）
https://docs.docker.com/docker-for-windows/wsl/
Docker Desktop の設定にある「WSL Integration」機能によって
何も設定せずにDocker CLIが使えるようになってんの
ちなみにWSL1で必要なのは、環境変数 DOCKER_HOST の設定な
（ポートフォワーディングの必要がないから）
前提としてDockerはCLIとサーバーが分離されてるのも知らなそうだがｗ
「WSL Integration」ではこのDOCKER_HOSTの設定も不要になってるから
全く無設定でDocker CLIからDockerに接続できるようになったわけだ
（apacheコンテナへのhttp接続の話は関係ない。これはLinux版Dockerでも同じ話）
それからlocalhostForwarding=trueは「WSL2上に立てたサーバー」に
「Windowsから」localhostで接続するためのものだ。
WSL2のUbuntuからWSL2上のDockerに接続する話は全く関係ない ごめん触っちゃいけないキチガイに触ってしまったようだ どうせいつもの認めたくない病発症してるんだろうから
俺以外の話として（>>342を書いた後に）ググったやつを持ってきてやるよ
以下を読めば、関連技術を知ってる人なら
どうやって実現しているかぐらい想像できるだろう
WSL 2 で Docker を使うパターン
https://laboradian.com/docker-desktop-and-wsl2/
> 3. WSL 2 ディストロ(Ubuntu) + Docker Desktop (WSL 2 Backend) を利用するパターン
> Docker サーバーとして、Docker Desktop を利用する方法です。
> 本ページでは、この方式を「Docker Desktop (WSL 2 Backend)」と呼んでいます。
> 選べるようになったと言っても、WSL 2 ディストロを使っているのであれば、
> 実質的にこちらの選択肢しかなさそうです。
> ※ 環境変数 DOCKER_HOST の設定は必要ありません。
> WSL Integration
>
> Docker Desktop の設定で、[WSL Integration] を有効にすると、WSL 2 ディストロ内で、
> docker-desktop というディストリビューション(?)の docker-desktop-proxy
> というプログラムが実行されるようです。 >>343
うん。だからとうとうそんなレスしかできなくなったよね？って俺は言ってるわけさ
>>344
有名なのは良いとして、言ってることが正しいのはどちらか？が重要だろう？ｗ docker-desktop-proxy という仕組みを使えばWSL1でも
環境変数 DOCKER_HOSTを設定せずにDockerに接続できたはずだが
1. Docker Desktop 登場当初はWSLが存在しなかった。（たぶん）
2. 今はもうWSLでDockerを使うことが当たり前だが、当初はWindows+Dockerという使い方が想定されていた
3. WSL1の初期はターミナルを閉じてもWSL内でサービスを動かし続ける仕組みがなかった
あたりが理由だろうな
つまりDockerはWSLに依存していなかった。
WSL2登場でWSL2に依存することを前提する方向に舵をとったから
「WSL Integration」という機能もつけた
（「"WSL1" Integration」でないのはWSL1でも使える機能だからだろう） 訂正
× 「"WSL1" Integration」でないのは
○ 「"WSL2" Integration」でないのは
バックエンドのことを「WSL 2 based engine」と
読んでるのとは対照的。用語を正確に使っている。 winで直でDocker使ってる事自体が間違い
Virtualbox内部のLinux上で使え
Docker Toolboxのインストール：Windows編
https://qiita.com/maemori/items/52b1639fba4b1e68fccd
x 「Docker for Windows」
完全に地雷、これが地雷なのは常識。
基本的にMSが自称してる
「Dockerに対応出来てる」「Linux完全対応」
とか言うのは嘘だから信じてはいけない。
o 「Docker Toolbox」正しい方 >>312
この時点ではブラウザで見れないと言ってるだけでlocalhostで見れないとは言ってない
>>313
なぜかlocalhost forwardingのことと決めつけ
>>314
正しい回答
>>315
docker hostのipがあったんだというセリフから
http://(docker host ip):80で無事にアクセスできたこと推測できる
ここでdocker host ipとはwsl2軽量仮想マシンのipでありwindows hostのlocalhostではない ようするにコイツは最初っから回答がズレてたんだな
その後はスタート地点を忘れてお互いあさっての方向にヒートアップしちゃってレスの流れがめちゃくちゃ >>350
> ここでdocker host ipとはwsl2軽量仮想マシンのipでありwindows hostのlocalhostではない
と決めつけ（笑） >>312 より
> 試しにWindows10 home上でdockerを動かしてapacheを稼働させているのだけど、ブラウザから見れないのは何が足りていないのだろうか。
>>350 より
> >>312
> この時点ではブラウザで見れないと言ってるだけでlocalhostで見れないとは言ってない
確かにlocalhostで見れないとは言っていない。
では「ブラウザから見れない」という発言は
どこに接続してみたのだろうか？
この時点ではdockerのIPアドレスがあったとは知らなかったはずだ
localhost以外のどこに接続したというのだろうか？
よく考えるとlocalhost以外にはないのである。
そしてもし localhostではなく本当にdocker hostのipアドレスで接続しているならば（できるのか？）
それは間違った（推奨されない）使い方である。 Windows 製のDocker は、互換性が低いでしょ？ >>353
質問者のコメントにはDocker HostのIPがあることに気が付いた、とあります
これがこの事件の真相を示しているのですよ、警部殿
質問者はDocker HostのIPの存在に気が付き「何か」を行った
そしてその後、ブラウザからapacheにアクセスできないという問題が解決しています
であれば「何か」とはDocker HostのIPでブラウザからapacheにアクセスしたことで間違いないでしょうなぁ
そうでなければ、質問者はなぜDocker HostのIPなどという発言をしたのでしょうか？
localhostでapacheにアクセスしたのならそのような発言はしないはずです Docker HostのIPがあったんだねって言っただけだろ？ > そしてその後、ブラウザからapacheにアクセスできないという問題が解決しています
解決したなんて書いてないよ
俺は、docker run -p 80:80で解決・・・というかWSL1時代からそうしてるけど
これで解決したと仮定するならば、俺はlocalhostで接続してるわけだけど？ 公式に推奨されている通りにWSL2のLinux側でDocker使うと、基本的には独自のIPアドレスが割り振られるからね >>358
WSL1の時代とは話が別。WSL2になってからネットワークがWindows側とは切り離されたから、ちゃんとホストのlocalhostにフォワーディングしてやらないとホストからはアクセスできない。 質問者がDockerのHostのIPアドレスがあったと言っても
初心者ならDockerのコンテナのIPアドレスのことを言ってるかもしれないし
決めつけてはいけないな
>>360
うん。内部実装の話ねｗ
そういうゴタゴタを解決してWSL1時代と同じような（改善された）
使いかってを実現してくれてるのがDocker Desktopなわけ > WSL2になってからネットワークがWindows側とは切り離されたから
これはWSL2の話
Docker DesktopはそいうWSL2の制限を自動的に解決している
WSL2 と WSL2を内部で使っている Docker Desktop は
別の機能だってことを理解しよう
いくらWSL2の話をしても意味がないのである レス内容見ればわかるだろ？ｗ
他の板にスレ建てるために時々変えてるよ ああ、そうじゃないな
そういうレスしかできなくなったね
というべきだったなｗ
レスするなら内容に関してレスね
それ以外の話なら、まだ「レスしてない」とみなすしかないからね >>354
Dockerのコンテナ上は同じじゃないの？ 全く同じというわけにはいかない
特にWSL2はカーネルにマイクロソフト独自のカスタマイズが入ってるから挙動がちょっと怪しい >>367
怪しい挙動がないのに、何を根拠に怪しいって言ってるの？ >>368
他のDocker環境だとビルド通るDockerfileがWsl2バックエンドだとエラーになったり
俺はまだぶち当たってないけどネットワーク周辺でトラブってるってブログも見た記憶があるね 「記憶があるからね」（笑）
先手打ったつもりだろうが意味ないぞ
どうせこのあとどこかを聞いたら
探したけど見つからないとか言い訳するんだろう？
次はお前のターン
どこにそんな事を言ってるブログが有るのか >>370
qiitaだったと思うが
ところでDockerfileの方はなんでスルーしたのｗ >>371
サイトじゃなくて記事を持ってきてね
>>370はDockerfileの話をしてるんだけど？
だからこっちも記事を持ってきてね
どちらもまた逃げるようなことはしないでねｗ >>372
FROM centos:6
RUN echo fack you.
まあ騙されたと思ってやってみ
こんな単純なDockerfileで環境差異が出るんじゃ他にどんなバグが潜んでることやら
まあはっきり言って実用レベルに達してないわな じゃあそのエラーの内容を「コピペ」してみて
簡単だよね？ｗ
あと引き続き ID:LwUpK/sq は
記事を持ってきてね
ID:LwUpK/sq は まだコピペできないの？
さっきの今で俺の書き込み見てるだろうし
コピペするだけじゃん なぜか「コピペして」と書いてあるのを読んでるのに
コピペしないと言うねｗ んで ID:LwUpK/sq はまだかね？
やっぱり逃げたかね？ コピペしたあとのお前のセリフは「コピペじゃなくて作ったエラー内容だろ」だろｗｗｗｗ
自分で試せば秒でわかるのになんでやらんのかね～
赤っ恥積み重ねて何がしたいんだこいつｗ >>383
コマンド打ったか？
コマンドプロンプトの使い方わからんなら教えてやるぞ いつもはしつこくレスしてくるのに負けを悟ると驚くほど静かになるuQx ID:LwUpK/sq はまだ？
コピペしろって書いてるのに
ここまでコピペできなかったID 5つぐらい？
コピペしてきた人 0で
圧倒的にコピペできなかった人が多すぎるぞｗ 正直Dockerの使い方もしらない気がしてきたな
FROMとRUNしか書いてないからなｗ >>386
>>381
コマンド打てよ
それで答えでるだろｗ
自分の手で負けを確認するのが恐いのかな？ >>388
だから問題なく動いてるって言ってるだろ？
人の話聞いてないのか？
エラーが出ると主張してるのなら、そのエラーを貼り付ければいいし
動作に違いがあると主張してるのなら、その違いを具体的に言えばいいだけ
なのにIDの数が増える一方で誰もエラーの内容を書いていない
つまりエラーが存在しない人の数のほうが多い >>389
できてるならエビデンス貼ってみてよ
できるならだけどｗ 他人にしつこくエビデンスを要求するのに自分はエビデンスを貼れないなんてことがあるのかなあ？ >>390
はいどうぞ
じゃあ次はお前のターン。逃げずにコピペしろよ？ｗ
$ docker build .
Sending build context to Docker daemon 1.963MB
Step 1/2 : FROM centos:6
6: Pulling from library/centos
ff50d722b382: Pull complete Digest: sha256:dec8f471302de43f4cfcf82f56d99a5227b5ea1aa6d02fa56344986e1f4610e7
Status: Downloaded newer image for centos:6
---> d0957ffdf8a2
Step 2/2 : RUN echo fack you.
---> Running in 2015425a3f33
fack you.
Removing intermediate container 2015425a3f33
---> 2eab2e340ae9
Successfully built 2eab2e340ae9 > 他人にしつこくエビデンスを要求するのに自分はエビデンスを貼れないなんてことがあるのかなあ？
これなｗ >>392
新人研修でエビデンスのとり方は習わなかったのかね？
実行した環境がわからないんじゃそのエビデンスにはなんの意味もないぞ 自分はエビデンスを貼れないなんてことがあるのかなあ？
（爆笑）
ブーメランやで >>396
だから「他人にしつこくエビデンスを要求しているお前」が
実行した環境がわかるようなエビデンスをはれって あとあれほどいた、コピペもせずに俺も俺もと言ってた奴らが一斉に黙ったのも面白いな
それぞれの人（IDが異なる人）、もう一回出てきてよ？ｗ >>397
違うなあ
先にしつこく要求したのはそっち
再三にわたってコピペがどーのこーの言ってた人が他人を納得させられるエビデンスを提示できないのはどうなんだろうね >>399
「エビデンス」といい出したのはお前だろ。スレ検索してみろよ
俺は単にエラーの情報が知りたいからそれを書けと言ってるだけ
で、またそうやって逃げるの？話をしてごまかしてるの誰の目にもわかってるよ
さっさとエラーの内容をコピペしろよ。何度目だよ？ >>400
エラーの内容を知りたいならWSL2バックエンドで実行すればいいよ >>401
だから俺の環境でエラーがでないから知ることが不可能
エラーが出ると主張している人がコピペすればいいのにしない。
言った本人はともかく、その他の俺もエラーが出ると言ってる人でさえ
全員（笑）がコピペをしない。つまりエラーがでてない人が圧倒的に多い Dockerっていまいち便利になった感しないんだよなぁ
Windowsだとまず
LinuxのVM立ち上げる必要があるのと
ビルドという1手間がとても面倒なのが痛いな
理想的なのはVirtualboxの仮想マシンを
Dockerイメージ形式に変換出来たら嬉しい
いやむしろVirtualBoxにDockerビルドとか
push pull欲しい
Dockerfileとかcmmpose.ymlもGUIで生成したい へ？Linuxサーバーにインストールするのとちゃうの？ >>404
> Windowsだとまず
> LinuxのVM立ち上げる必要があるのと
お前が手間かかることしてるだけじゃんｗ
Docker推奨のやり方は
1. Docker Desktopインストール
2. Windows起動時にサービスが自動起動する
3. dockerコマンドが実行できる
Linuxの場合となにもかわらん >>404
> 理想的なのはVirtualboxの仮想マシンを
> Dockerイメージ形式に変換出来たら嬉しい
何度もいわせるな。Dockerはアプリを仮想化するものであって
仮想"マシン"（=ハードウェアエミュレータ）ではない いやアプリって元々ソフトウェアやん
元々仮想的なものやん… >>410
意味不明。仮想の意味わかってないだろ
仮想メモリの仮想と、仮想マシンの仮想
両方の仮想の意味を説明してみ 仮想メモリは
物理メモリの非連続性を意識せずに
確保できるためのアドレスやな
VFSはextとかxfsとかの物理ドライバや
NFSなんかを
意識せんように一括でファイルパスアクセス
でアクセスできるようにするもんやな
つまり両方ともハード的な物理特性を意識せんように
するもんでええんか？
しかしアプリはDocker無くても
元々ハード的な特性はある程度意識しなくても
いいようになっとるやろ >>413
だからDockerは物理的なOS（カーネル＋ユーザーランド）を
意識しないで良いようにするためのもの
> しかしアプリはDocker無くても
> 元々ハード的な特性はある程度意識しなくても
> いいようになっとるやろ
ならRubyで作られたアプリをWindowsで動かしてみ
もちろんRubyだけで動かずライブラリを使ってる WindowsやmacOSのようにOSが全く違う場合だけじゃなく
Linuxの場合も考えてみましょうか？
ならRubyで作られたアプリをお前が使ってるLinuxで動かしてみ
ただしアプリ開発で使ってるディストリとそのバージョンは秘密だ なるほど、開発の時に動いたんと
まるっきり同じOSとディストリで動かしましょうっ
ちゅうことか。
せやけどそれならVirtualBoxでもできるで
仮想マシンごとエクスポートして別のマシンのVirtualBox
に移植すればええんや？
というか せやからVirtualBoxでDockerイメージに
変換出来たら便利やな言うとるんやで
ユーザーランドのアプリだけやなくて結局カーネルの
仮想化してるん同じやんけ > せやけどそれならVirtualBoxでもできるで
> 仮想マシンごとエクスポートして別のマシンのVirtualBox
> に移植すればええんや？
そのVirtualBox用仮想マシンをクラウド上の
AWSやGCPでどうやって動かすんだ？
はい詰んだ（笑） せやから何遍も
VirtualBoxのイメージをDockerイメージに
変換出来たら便利や言うてるやないかい。 >>418
Dockerは仮想マシンの代替として作られたものじゃないから
（糞重い）OSの起動処理自体が存在しないんだよ
つまり不可能
もちろんクソ重いOSの起動処理をやってもらっても困るんだがな
だってそうだろう？
例えば画像変換処理で、covert from.png to.png というコマンドを
色んな理由でビルドが困難だからDocker化しました
covert from.png to.png の代わりに
docker run covert from.png to.png とできます。
コマンドの実行開始から処理完了までの時間は殆ど変わりません
という話で
お前は、新たにLinux起動から始めるんか？
Dockerイメージとして作るものは、アプリ（＋ライブラリ等）であって
OS作ってるんじゃねーんだよ Ruby では、Linux 以外で動くかどうか、分からない。
Node.js など、すべての無料のソースコード、OSS エコシステムは、Linux。
だから、Virtual Box, WSL, Heroku, Cloud9 などを使う
Linux を使わない、ローカルPC 開発では、
Windows のMSYS2 よりも、Mac の方が互換性が高いから、Macを使う
最近は、Windows にも、WSLが出来たから、Linuxも使える コンテナは仮想マシンと言うより
プロセスを隔離する技術と
実行可能ファイル（と依存ライブラリ）をイメージにして転送する技術のセット
apt-get, bashや
各種CLIツールが入ってるDockerイメージも数多く存在するが
ビルド時に新しいツールをイメージにインストールしたり、
コンテナ内でデバッグしたりと言った利便性の為に用意されてるだけで
別に必須ではない
ただ単にメインのプロセスが起動する状態になってれば動く
Goなら依存関係を全て含む単一の実行ファイルが作れるので
実行ファイルだけを含むDockerイメージが作れる
scratchイメージでググれ コンテナってファイアウォールとか色々大事なもんが欠けてっからセキュリティガバガバじゃねえの?
本番じゃ使えないよこんなの セキュリティ強化のためにpodmanを使うべきなんだろうな
でも慣れてるからdockerを使っちゃう >>424
コンテナ＝アプリ
おまえはアプリにファイアウォール入れるのか？
アプリを動かしてるOSに入れるもんだろ ネットワークモードがブリッジの場合、
ポートマッピングを設定しない限りマシンの外からコンテナに直接接続は出来ない
AWSならセキュリティグループの設定は必要
明示的に許可しないと外から一切接続できない
仮想マシンのインスタンスは
外から接続を許可したいポートだけ許可するか、
ロードバランサー等特定の相手にだけ許可する >>419
Linux同士のディストリ間の差異は
ファイルシステムの構造と
格納物の差異でしかないから
ホストマシンのハードと
ホストのカーネルが有れば
コンテナごとにルートファイルシステムを
入れ替えればVMの仮想ハードの起動と
ゲストカーネル起動処理がなくなって軽量化
するってのがDockerの考え方か？
ならばVirtualBox仮想マシンイメージから
ファイルシステムの部分を抽出すれば
Dockerイメージに変換できて軽量化できそうやな。 >>429
おまえにわかりやすく言えば、Ubuntu等をセーフモードで起動して
CLIシェルだけが動いてる状態だよ
ディスクはあるだけで殆ど使ってない
GUIデスクトップも含めサービスは何も起動しない
そこから必要なアプリだけを起動する。軽いに決まってるだろ
> VirtualBox仮想マシンイメージから
> ファイルシステムの部分を抽出すれば
VirtualBox仮想マシンイメージに相当するDockerイメージが
公式で配布されてるから出来るできない以前に、やる意味がない
実質的にはファイルを配布しているだけ
事実tarファイルからインポートすることも出来る
VirtualBox仮想マシンイメージから変換するなら
すべてのファイルをtarに固めるだけ・・・ではなく
procなどの不要な部分を削除する必要がある。面倒なだけだなｗ なんで頑なに仮想マシンイメージからの変換にこだわって
Dockerfile書かないんだ？
書けばいいだろ GUIのインストーラーがないと
OSのインストールが出来ないからだろ 例えばffmpegコマンドをコンテナに閉じ込めて
ffmpegコマンドだけを実行したいのに
OSの起動、各種サービスの起動、なんてのを
やるとしたら大きなデメリットなんですよ Dockerって結局
ホストマシン上の作業ディレクトリに
かなり依存してるんだよなぁ
Dockerfileやイメージビルド時に
ホストディレクトリからイメージ内にコピーする
ソースファイル
マウント ポートマップ
compose.yml
開発したホスト環境から離れたイメージは
これらも同時に搬送しないともう保守できない
従来の仮想マシンなら全部VM内に組み込まれてるけど
Dockerの場合全部外に飛び出しちゃってる >>435
え？仮想マシンの場合どうやって
ホストにあるソースコードを入れるの？え？え？ つまりAさんがいじったソースとイメージを
Bさんが続きをやる時や同時に作業する時どうするの？ 今から仮想マシン（数GB）を送りますので
あとはよろしくおねがいします
とかやるの？（笑） 仮想マシン（VirtualBox）で開発が終りました。
今から、あの、本番環境のLinuxサーバーに反映します。
仮想マシンイメージがそのまま使わないので
その今から構築します
ってやるの？ｗ 仮想マシンを使って開発すると問題になるのが
私の仮想マシンでは動くんですが、本番環境の仮想マシンでは動かないんです
ってなることなんだよな
再現性が取れない
仮想マシンに入っていって一つ一つ違いを調べないといけない Docker使わないやつって、本番環境で
Linux GUIデスクトップ環境が動いていてもいいじゃない
って思っていそうｗ Chef で、数千台を構築してる
大手鉄鋼では、Open Stack とか そのChefでなにをやってるかなんだよな
そのレシピはAWSで動きますか？GCPで動きますか？
まあ普通は動かない。なぜならその下位のインフラに依存したものがあるから
しかしアプリケーションだけは動かせるのではないだろうか？
OSに依存してるから動かない？なら動かせるようにしよう
コンテナに動かすのに必要なもの全てを入れればいい
そうすることで、インフラで必要なものとアプリケーションで必要なものを分離できる
そうするとインフラが変わってもアプリケーションを動かすことが出来る
それがWindowsやmacOSなどの開発環境やテスト環境、
大好きな（笑）VirtualBoxなどの仮想マシンでも動かせることにつながるわけ
VirtualBoxで開発環境を簡単に作れるようにするためのDocker
何度もいわれてるようにDockerは仮想マシンと組み合わせて使うもの
Chefを使うのはいいんだよ。だけどアプリケーションに依存したものは
取り除きましょう。その部分をDockerにしましょう
Chefで複雑なアプリケーションのための準備（言語やライブラリのインストール）はするなってこと Ruby on Rails では、
Chef で、OS を構築して、
Capistrano で、アプリをデプロイして、
ServerSpec で、構築をテストする
Open Stack, Terraform
Docker, Kubernetes それがDockerを使うと
Chef でDockerサーバーインストール済みのOSを構築して
Docker pullでアプリをデプロイと超簡単な作業になるんだよな テラフォーマーズ
アンシブル
ドッカーン
弊社はこの3段階で管理しております >>432
手間なく手がるに変換できるならとりあえずそれでって要求はあってもおかしくない
既存資産はdockerのこと考えてないからdockerfileにしようとすると案外めんどくさいからね >>447
変換しても動かないんですが
なんのために変換するんですか？ >>448
「変換」ができてないからやろ。
うまくやればやってやれないことはないはず。
そういうサポートがあってもいいとは思うな。
保証は大変そうだけど。ｗ 変換サービスって既になかったっけ?
Azureかどっかで見た気がするが興味ないから忘れた >>449
だから変換なんて無理なんだって
initが違うんだから いやだから確かもうあるって
名前忘れたから探して見つかったらサービス名教えて >>451
そこは保証外でええがな。
run引数なりCMD指定なりをちゃんと書くのは、コンテナをつくる側の責任にしとけば。
>>450
やっぱあんのか。ｗ >>453
それなら単に外部ドライブを接続した
別Linuxをセーフモードで起動してるのと変わらん
変換するのは簡単だよ？
仮想マシンイメージのファイルを全部tarに吐き出せば終り
あとはどのファイルで起動すればいい
なお最初に起動するプログラムは自分で作ること
なーに単にファイルが有るだけだ Dockerのイメージファイルはtarファイルからそのまま作れるって知らないんですかね？
仮想マシンの中のファイルをtarに固めるのなんて簡単でしょう？
それで終りですよ？完成です。
仮想マシンの中のファイルが有れば、それだけで
あなたの要望は実現できているのです。
なにか不満が？ｗ tarからイメージつくれるのか
zipや7zipからでもつくれるの？ 仮想マシンからファイルとってきてtarに変換するやり方は
無駄に容量が大きくて、作り直すのが困難な
不便なイメージが出来上がるだけだがね
もちろん起動するプロセスは指定したものだけだ 仮想マシンイメージはsystemd経由で起動するようになってるが
Dockerではもちろん動かない
仮に動いたとしてもDockerでは不要なサービスが動いてるから
systemdを使うなら、不要なサービスを停止しなければ重いだけ Dockerのイメージはファイルだけがあるのと一緒
つまりファイルさえインストールすれば作れる
だから最小限のディストリがDocker公式で配布されていて
そこにapt-getなどでインストールするだけで最適化されたイメージが作れるのだ
仮想マシンイメージから変換すると不要な仮想マシン用ドライバなどがあって
Dockerなら数十MBですむところが数GBにもなる
そんなに容量が大きいと、他の人に配るのも大変になるｗ 「面倒だから簡単な方法がほしい」
と言った時、2つの意味がある
1. 今の作業に無駄があって面倒だから、より簡単な方法に改善したい
2. 勉強するのが面倒だ。だから今の知識のまま改善したつもりになりたい
仮想マシンイメージ変換したいというやつは後者
Dockerを取り入れた気になってる
本当の目的である改善をしたくない
理由は「面倒」だから。真意は「勉強したくないから」 段階を踏んでいくんだよ
まずは自動変換でイメージを作成
イメージを運用環境に取り込んでテスト
不具合がなければとりあえずそれで運用を開始
この段階で開発者が好きに弄くりまわせるクローン環境を安価に入手できたことになる
あとはじっくり解析してサービスを1つ1つ分離するなりなんなりすればいい
時間的余裕をもって優雅に働こう systemdを使うのも同じこと
systemdが動けば完全にとは言わないが既存のシステムを移行するのは随分と簡単になる
なぜなら既存の構成管理ツールと資産が使えるからね
Dockerのベストプラクティスを破ることになるが現実の仕事には様々な要件があり必ずしもベストプラクティスを踏襲できるわけではない
要件と照らし合わせてやる価値があるならベストプラクティスを破っても構わない
これはDockerだけじゃなくシステム開発全般に通じる常識だよ >>462-463
それでどんなメリットがあるんですか？ｗ
Dockerを使うことが目的になっていて
どういう問題を解決したのか言えないでしょ（大爆笑） VagrantでPHPのローカル開発環境作る時は
mysqlもPHPもnginxもphpmyadminよmailcatcherも
全部1個のマシンに詰め込む
mailcatcherはruby製なので、rubyが必要
Dockerはそれとは異なる
大多数のイメージは、単一のマスタープロセスが動くように設計されてて
単一の機能だけを持つ
必要に応じて疎結合に組み合わせて動かせる
仮想マシンから変換するツールが無いのはそもそも色々入った
闇鍋的イメージを動かしたいって言う需要が無いから
そもそも仮想マシンおじさんは
mysql, php, nginx等の公式イメージがあることを知らないのでは無いか >>464
わからないか？
そんなんじゃチコちゃんに怒られるぞ
レガシィシステムを短期間でDocker環境に移行してDockerの開発生産性を享受できるようになったんだよ supervisordとかを使えば
php, nginx, mysql, phpmyadmin, mailcatcherをすべて詰め込んだコンテナも作れるがそんな物を作るのは変態だけだ
何の意味もない
ふつうは単機能のコンテナを組み合わせてゆるく繋ぐ >>466
お前がやったのはDocker環境に移行してるんじゃなくて
Dockerを使ってるだけで、Dockerの開発生産性を享受できてないじゃん
お前のやり方でどこでDockerの開発生産性が享受できてるのか言える？
言えないよね >>465
闇鍋コンテナの需要はあるよ
例えばgitlabだ
あれはまさに闇鍋的なコンテナイメージだが非常に良くできてる
勘違いしてる人が多いけど
コンテナは1つのプロセス
コンテナは1つのサービス
ってのは間違いだ
コンテナは1つの役割
これが正しい
役割を全うするのに複数サービスが必要ならそうすべき
逆にコンテナを分離しても扱いやすくはならない >>468
チコちゃんこいつです
安価に手に入れたクローンサーバーを開発環境で活用できるだろ
Dockerじゃなければ仮想マシンイメージでやらなきゃならんが重量級すぎて駄目だ >>467
ところがそうでない場合も存在する
Chefなどといった構成管理ツールが既にある場合だ
そういうものが既にあるなら時間をかけて分離するより闇鍋コンテナのほうがお手軽だし動かし始めるまでがべらぼうに早い
さっさと闇鍋コンテナを作ってしまい開発～運用環境を生産性の高いDockerベースで構築し直す
あとはゆったりとリファクタリングしてコンテナを分離するなり軽量化すりなりやればいい >>472
わからんのなら、わからんのやろ。
おまえの理想とか理屈とかもうわかったから。 >>472
段階を踏んで作業したほうが結果的に楽に安全に進められる
これは開発の基本的な心得 >>476
段階の踏み方がおかしい
仮想マシンの中で、一アプリ、一サービス単位でDocker化すればいいだけ
全アプリいっぺんにDocker化したら危険すぎる
何度もくり返し言うがDockerは仮想マシンと組み合わせて使うもの
段階を踏むとは、仮想マシンの中で一つずつDocker化することをいう >>477
仮想マシンじゃ重すぎ
開発中は何度もサービスを破棄再構築する コンテナ使っててもコンテナを動かすマシンは必要
Linuxデスクトップ使ってるのでも無ければ1つは最低必要
Win, Macだと直接Docker使えないからLinux仮想マシンの上でDocker動かす >>478
仮想マシンをDockerにするって言ったのはお前だろ？
Dockerを破棄したら開発マシンの中にあるソースコード全部消えるだろ >>478
> 開発中は何度もサービスを破棄再構築する
何度も破棄構築するにはDockerfileで作るようになってないと駄目
tarから作り直すと、時間がかかる
仮想マシンのサイズ、数GBをDockerサーバーに転送しないといけないから
お前のやり方は破綻してる Dockerでなぜ破棄、再構築が速いかと言うと
Dockerfileの1命令ごとにキャッシュされるから
apt-getなど更新がない限り同じ処理は行わない
しかしtarから作る場合、少し変更があっても全て最初っからやり直しになる >>482
イメージを作る方法はDockerfileだけじゃねーぞ >>486
じゃあどうやって仮想マシンをDockerイメージに変換するつもり？ｗ
もっと時間がかかる方法だったりしてなｗｗｗ Docker Hub のAlpine は、5MB
Dockerは、層になってるaufs だろ
階層が、1, 2, 3 とかなっていて、3を修正しても、
1, 2は無修正だから、キャッシュを使う Dockerのキャッシュは面倒のもとになることもあるけどな。 ほーら。実際に使ってないから
何が面倒になるかを書かないわけ
否定したいだけ >>487
変換サービスを使うなり既存の構成管理ツールの資産を活用する
少しはレス読んでから返信したらどうなの 既存サービスから闇鍋イメージ変換
あるいは既存構成管理ツール資産を使って闇鍋イメージビルド
闇鍋イメージをテストして運用開始
☆メリット：手作業でDockerfileを書くより遥かに早く安価にDocker運用環境に移行可能！
クライアントを待たせない！
開発フロー例：闇鍋イメージからサービスAを分離する場合
1. DockerfileでサービスAイメージ(Aとする)を作成
2. 闇鍋イメージをrun→コンテナの中に入る→サービスA停止→サービスAとの連携に関わる設定ファイルを修正→コミット→プッシュ(闇鍋Aとする)
3. 闇鍋AとAをテスト環境にプルしてテスト
4. テストをクリアするまで闇鍋AとAを修正
5. 運用環境にデプロイ
☆メリット：小さな作業単位に区切って段階的にリリースできるためプロジェクトのリスクが軽減される&闇鍋イメージがレジストリに残ってるのでロールバックも簡単！
開発の基本中の基本”分割して統治せよ”！ >>490
面倒のことがわからないのなら、そのほうが実際に使っているのか疑わしいレベル。ｗ
世の中は、おまえの理想とは異なる。 >>491
> 変換サービスを使うなり既存の構成管理ツールの資産を活用する
↓これよんだ？
> 開発中は何度もサービスを破棄再構築する
Dockerイメージビルドするたびに
そんな面倒なことしてられるかｗ >>492
それ仮想マシンの中でサービスを一つづつDockerにすればいいだけですよね？（笑）
Dockerは仮想マシンじゃない。
だからDockerは仮想マシンと組み合わせて使うもの！ >>494
おめーこそ読めって
変換、既存資産流用は最初の1回だけだ >>495
そんなことしたら仮想マシンとDockerを並行してメンテナンスしなきゃならねーじゃねえかめんどくせえわ >>497
> そんなことしたら仮想マシンとDockerを並行してメンテナンスしなきゃならねーじゃねえかめんどくせえわ
仮想マシンのメンテナンスが大変なのはDockerを使わないからだろ
Docker使えば仮想マシンなんてDockerさえ動けば良くなるんだよ
そうすれば今度は仮想マシンを使わなくてもWindowsでもmacOSでも動くようになる
Dockerさえ動けばいいんだから >>499
仮想マシンメンテナンスを避けるために変換既存資産流用で速やかにDockerに移行する >>500
つまりDockerを使うことが目的となっていて
なんのためにDockerを使うかという理由がないわけねｗ
手段と目的を履き違えているという典型例 >>501
「仮想マシン」と「アプリ用Docker」のメンテナンスが
「仮想マシン変換Docker」と「アプリ用Docker」のメンテナンスに変わっただけ
仮想マシンをDockerに変換してもそのままじゃ動かないので
「仮想マシン変換Docker」が動くようにする作業が増えただけ >>502
Dockerを導入する目的は案件によって様々だからここで挙げる意味はない
Dockerを導入すると決まった後の話をしてる
そんなこともわからんのかお前 >>503
仮想マシンとDockerが
DockerとDockerに変わったんだよ
これでメンテナンスが楽になった
クソ重い仮想マシンを立ち上げなくて済む
DockerレジストリなどといったDockerエコシステムを利用することができる
すべてがハッピーだ > 仮想マシンとDockerが
> DockerとDockerに変わったんだよ
仮想マシンの中でDockerは動くが
Dockerの中でDockerは動かんぞ（笑） >>504
> Dockerを導入すると決まった後の話をしてる
だから手段と目的を履き違えた後の話をしてるんでしょう？（笑） >>506
docker in dockerの話は誰もしてないが
お前さ返しが支離滅裂 >>509
別だとわかってるから、履き違えてるって言ってんだろｗ >>510
履き違えてるのはお前
こっちは正しく理解して言ってる
お前は曲解して反論した気になってるだけだ >>508
docker in dockerの話をしてないとしたら
いきなり分離するわけですね
大変ですねｗ
仮想マシンの中でDocker化していったほうが楽ですよ？
分離しなくていいですからね
単に使うアプリをパッケージからDockerベースに変えるだけです
その他は何も変えません
分離はまた別の機会にしましょう
一歩ずつ段階を踏むというのはこういうことです >>511
余計大変なやり方をしてどうするんですか
一気に全部をDocker化するんじゃなくて
段階的にやりましょうって話をしてます。 >>512
いきなり分離しねーよ
変換してから分離だつってんだろ
仮想マシンのこしたまま分離したらDocker移行が遅れるし
開発者も重すぎる仮想マシンと付き合わなきゃならんから生産性ガタ落ち
何度言えば理解すんだオメー >>513
オメー段階的にやる方法は仮想マシンの束縛から逃れるまで長い時間がかかる
その間ずっと開発者も運用者も重ーい仮想マシンのせいで疲弊し続ける > いきなり分離しねーよ
> 変換してから分離だつってんだろ
だから仮想マシンをDockerイメージに変換しても
そのままじゃ動かねーって言ってんだろｗ
動くものがあるならそれ言ってみろよ
ねーから
はい、さっさと言ってね >>515
> オメー段階的にやる方法は仮想マシンの束縛から逃れるまで長い時間がかかる
ほらやっぱり手段と目的を履き違えてるｗ
仮想マシンの束縛から逃れるのは目的じゃねーの
どうせクラウドでは仮想マシン使うんだからな >>515
> その間ずっと開発者も運用者も重ーい仮想マシンのせいで疲弊し続ける
仮想マシンをそのままDockerに変換しても重いんですが？
systemdとか各種サービスを動かさなきゃならんでしょうがｗ
ま、そんな変換できるものなんてねーから
やったことなくてわからないんだろうね >>516
動く変換ツールか構成管理ツールを使えよ
変換サービスでもAnsibleでもChefで好きにしろ > 動く変換ツールか
存在しません
> 構成管理ツールを使えよ
変換するのに構成管理ツールが新たに必要になりました
大変ですねｗ >>517
Docker移行の目的はより上位のレイヤーできまるつってんだろ
仮想マシンの束縛から早期に逃れるのはその目的をスマートに達成するための手段であって目的じゃない >>518
仮想マシンより遥かに早い
それに速さだけじゃなく
DockerレジストリなどDockerエコシステム載せて開発できることが強み
何度言えば理解するんだ
ってことを何度言わせるつもりだ
いい加減にしろ >>519
dockerでsystemdが動かないって言えば理解できる？
仮想マシンイメージをどういう方法で変換したとしても
systemdが動かないから使い物にならないんだよ >>520
新たにじゃねーよ
既存の資産使うって何度も言ってんだろ
まじで最低限相手の言い分を飲み込んで理解してからレスしろ
話にならねーよテメー > 仮想マシンより遥かに早い
だから仮想マシンを変換しても動きません
動かす方法がこの世に存在しません
> DockerレジストリなどDockerエコシステム載せて開発できることが強み
仮想マシンの中でDockerを使ってもエコシステムで開発できますねぇ
バカなんですか？ >>523
動くんだよ
redhatはsystemdが動くオフィシャルイメージを公開してる
他のディストリイメージでもsystemdを動かすことはできる >>524
> 既存の資産使うって何度も言ってんだろ
既存の資産＝仮想マシンイメージをDockerに変換しても動きません
既存の資産が使えません
仮想マシンイメージという既存の資産を使ったまま
段階的にDocker化していくことはできます。 >>526
> 動くんだよ
> redhatはsystemdが動くオフィシャルイメージを公開してる
動かすために多大な苦労をしている
redhatと契約なしにsystemdが動くイメージが手に入ることはない
そして既存の仮想イメージからの変換はできない
特殊なイメージになっている >>525
します
仮想マシンの中にDockerエコシステム作ってどうすんだバカ
仮想マシンは開発中に何度も破棄と再生性を繰り返す
そのたびにレジストリとか消えたら意味ねーだろポンコツ野郎
Dockerエコシステムは開発マシーンとは別に構築すんだよ
そんな基本も知らねーで突っかかってくんなバカ >>528
redhatイメージはホストOSと同じでサポート契約不要なら無料で使える
オメーさては業務やってねえ素人だな Ansibleやchefのテストにコンテナを使うことだってあるんだから既存の構成管理ツールの資源が再利用できねーわけねーだろ コンテナの中でcrontabとか動かすのはちょっとキモい
横着せずコンテナオーケストレーターのスケジュール機能を使う方が良い オーケストレーター依存はNo
他の環境で動かすときどうする >>535
コンテナも何かに依存しなければ生きていけない悲しき存在
あきらめろ LaravelのタスクスケジューラをECSサービスで動かそうとしたが、
標準出力にスケジュールしたタスクのログを出す方法が分からなかった
結局ECSのスケジュールドタスクを採用した /dev/stdout
/dev/stderr
に書き込めばいいよ Windows10proとvscodeだと中と外で同期するからプログラマーはみんなWindows10proにしてるの？ Windows 10, pro 版じゃないと、Docker を使えない
プリインストール版なら、5千円ぐらいで安い WSL2バックエンドはリソースバカ食いするのとカーネルAPIの互換性のせいでバグるやつ直ったのか？ 直ってないから20.04入れて6GB制限にして使ってる
特に困らん >9. イメージを作るのはアプリケーション開発者の仕事です。インフラの仕事はつくられたイメージを動かすことです。
これ、他スレでも言ってるけど誰が言い出したの？
それともスレ立てたのが勘違いした同一人物なの？
何処の妄想から出てきたのかさっぱり分からんｗ
気味悪いわ >>548
>お前の感想などどうでもいい
そっくりかえすよ。
「お前の感想なんてどうでも良い」
事情を知ってればレスしろよ。書いたやつはお前か、お前みたいな能無しの馬鹿なんだろうな。 >>550
何自分語りしてるんだよｗ？そりゃお前だろ。
俺の元の書き込みが>>1の9. は何処の馬鹿が何を勘違いして書き込んだの？
という疑問形なんだから中身はあるだろ。 >>551
マジで理解できないと言うなら聞くけど
開発しているアプリを動かすために何が必要か？（ライブラリなど）を
開発者以外がわかるっていうんか？
開発してる本人が使うライブラリやバージョンを
選んでいるんだから開発者の領分だろ >>553
それはお前が一人で誤解した使い方だろ？広く知られてなんかいねーよ。
Docker社がそう使ってくれと書いてる訳でもない。
OSとhttpd入れて必要なソースをgithubからpullしてデプロイするという単純なイメージ作って運用するだけでも全く問題ない。
因みに公式：
https://docs.docker.com/get-started/
Docker concepts
Docker is a platform for developers and sysadmins to build, run, and share applications with containers.
The use of containers to deploy applications is called containerization. Containers are not new,
but their use for easily deploying applications is.
ドッカ―のコンセプト
ドッカ―は「開発者」と「システム管理者」がコンテナ使ってアプリをビルドしたり実行したり共有したりする、プラットフォームなんだぜ。
コンテナ使ってアプリをデプロイする事をコンテナ化っていうんだぜ。これって考え方じゃないけど、簡単にアプリのデプロイに使えるぜ。
まじで何処を読んだら、そういう理解になるのか全く分からん。
過去ログ見ても相当昔から間違った主張をずっと繰り返してるし。 > ドッカ―は「開発者」と「システム管理者」がコンテナ使ってアプリをビルドしたり実行したり共有したりする、プラットフォームなんだぜ。
だから開発者がイメージ作るっていんだろｗ >>555
いやいや意味わかんね。
なんでシステム管理者の方を排除するのｗ？
結果的に何処からどう見ても違和感以外感じないんだがｗ
Docker社の書きっぷりなら、要はコンピュータ管理してる人ならだれでもいいよ、と言っているんだが。 infrastructure as code
コードによるインフラ構築
開発者自身が、コードによってインフラ構築する。
これによって、システム管理者と打ち合わせしなくてもよい
Docker はテスト環境。
本番には使わない。
本番には、Managed Kubernetes とか
Docker はデプロイツールでもない。
デプロイには、Capistrano など
プロビジョニングは、Chef, Itamae とか >本番には、Managed Kubernetes とか
※ Managed Kubernetesで動かすのは、Dockerコンテナです
ヴぁ～か > Docker はデプロイツールでもない。
> デプロイには、Capistrano など
※ Dockerを使うとデプロイツールによるデプロイが簡単になるんです。
場合によってはデプロイツールが不要になるぐらいに簡単になる。 >>553
当然、みんなわかってるよ
企業ポリシーで許可される、または禁止される言語、フレームワーク、ライブラリってのがある
これを末端の開発者が好き勝手に選ぶことはできない
勝手に選んだらセキュリティ事故手前の警告として、開発者を吊し上げて審問しなきゃならん
そのポリシーは開発者以外にも周知されてるし、明確にドキュメント化されている
お遊びのウェブ系だとポリシーゆるっゆるだから末端の開発者が勝手にインストール、なんて馬鹿げたことをしても許されるんだろうけど、エンタープライズでそういうことはできないからね >>558
>開発者自身が、コードによってインフラ構築する。
これは何を読んでそう理解したの？URL示してみろよ。
IaCをそんなおかしな定義している解説なんて存在しない。
わざわざ主語を「開発者」に限定するて何処に記載されているの？
それ以下の記述も間違いだらけなんだが。 DockerfileとかComposefileとかを、アプリにあわせて書くのが開発者だからやろ。 >>561
勝手に使ったら駄目なら
許可を得て使えばいいだけだろ
お前は一体何を言ってるんだ？ >>563
何でそんな限定された状況をあたかも一般的な状況であるかのように>>1は書くの？
君の言うような状況はシステムのライフサイクルが５年とすれば最初の１年目
（もしくは０年目、納品前）の話だろ？それ以降はSREチームがやるだろ。
まあ、とりあえず>>558が何を読んでそう理解したのかって話が先だな。
根拠のないな話は突っ込みようがないｗ >>566
何も知らない人はオライリー読んでからレスよろ。
（もしくは日中から連投せずに就職しろ）
普通の会社はSREの責務だよ。 KENTA / 雑食系エンジニアTV
クラウドエンジニアのくろかわこうへいさんにインタビュー
https://www.youtube.com/watch?v=xJbcDr6l450
YouTube の2大サーバー側エンジニア、KENTA・くろかわこうへいの対談
非プログラマーでは、bash が汎用的
くろかわみたいに、Docker, Kubernetes とか出来るのは珍しい。
彼の動画で、勉強すればよい >>564
許可なんて出さんよ
ツールの安全性評価、サポート体制評価、導入の弊害調査、やることいっぱいある
下請けアプリ屋の嘆願をいちいち聞いてたらきりがない >>568
いやだから就職しろって。
そいつはひたすらウザく経歴並べてるだけじゃねーか。
言ってることもごく普通（10分の1くらいしか見てないけど）。
そいつが渋谷で働いている（た？）クラウドエンジニアと言うなら
お前が渋谷のクラウドサービス会社に入社すれば同僚はみんな
そういう奴だから聞きたくなくても勝手に教えてくれるよ。
暫くしてスレを見返せば「俺って無知やなー」ってのが身に染みるだろうよ。>>568 >>569
出さないと決めつけ
本音はお前がやりたくないだけだろ インフラ屋が許可を出さないような所は、開発者を雇わないから大丈夫
そういう所は、アプリを作れないから、開発者を雇うわけないので無関係 rebuildとかに出てくる様な人じゃないと
エンジニアには影響力無いよな youtubeならIT業界に夢見て転職を考えている人には刺さるのかもね
俺はそいつ生理的に無理だけど
GCPの基調講演とか見るほうが為になる IT業界を夢見て転職活動中ならクラウド関連じゃなくDocker使わないイントラネット関連に行けよ。
求められる技術はレガシーで保守的だよ。
Docker＋コンテナ使うようなサービス会社は先進的な技術を素早く飲み込む特殊能力
（ITとは別の意味で特殊な技術）を求められるから敷居は高いよ。 Dockerはもう先進でも何でもないんだよなぁ
あと仮想化の発想の転換をしただけで
特に敷居高いとも思わない > Dockerはもう先進でも何でもないんだよなぁ
OSはもう先進でも何でもないんだよなぁ
ブラウザはもう先進でも何でもないんだよなぁ
画像編集ソフトは・・・
動画編集ソフトは・・・
先進でないからなんて？
第一線で便利に使える道具やろ？ ぶっちゃけ始めるのにいい言語て何 part3
https://mevius.5ch.net/test/read.cgi/tech/1599110613/109
上のリンクの、
［53選］国内注目のWebサービス・アプリを大調査！
プログラミング言語、フレームワーク、アーキテクチャの一覧【2017年】
では、ベンチャー企業は、AWS, CircleCI, Ruby on Rails ばかり採用する。
今は、さらに、Docker
YouTube で有名な雑食系エンジニア・KENTA は、
AWS, CircleCI, Docker, Terraform を組み込んだ、
化物みたいな初心者のポートフォリオを見た事があるらしいw
SIer でサーバー構築運用をやってた人らしいが 他のスレでもこの気持ち悪いyoutuberの書き込み見るけどさ
自分自身で有名とか言ってんの恥ずかしくないんかね？ ステマでしょ。
>YouTube で有名な雑食系エンジニア・KENTA は、....
この一文以降が唐突で必然性が全くない。
誰それ？ってググって貰おうとしてるんだろ。 雑食系って要は専門性がなく派遣で使い回されてるやつだろ
よく恥ずかしくも無くそんな肩書き名乗れるな 桜牛見た時びっくりするよな。
(なんでこいつこんな所におるん…？) KENTA の本が、ついに出る！
21世紀最強の職業 Web系エンジニアになろう AI/DX時代を生き抜くためのキャリアガイドブック
勝又 健太、2020/11/6
今、最も人気のあるジャンル dockerのデータボリュームにオブジェクトストレージを充てる技術ってのは出てこないもんなの？ >>589
それは
ファイルシステムにオブジェクトストレージを充てる技術
と言ってるのと同じ
つまり意味がわからない
Dockerでサーバー動かせばオブジェクトストレージになるだろ
https://techtarget.itmedia.co.jp/tt/news/1710/25/news07.html
「Minio」は、Apache License version 2.0でライセンスされている
オブジェクトストアサーバだ。このソフトウェアは軽量で、Dockerコンテナとして、
「S3 Server」は、2016年にScalityによってDockerコンテナイメージとしてリリースされた。 ホストOSはUbuntu
これにコンテナとしてUbuntuをインストール
諸々の設定をしてFirefoxを起動したのですが、ホスト側でFirefoxを起動していると
何故かホストのFirefoxが起動します。←２個起動した状態になる
ホストで立ち上げていない状態だとコンテナのFirefox（お気に入りも何も設定されていない英語版）が起動します。
こういうものでしょうか？ それとも設定が間違っている？ >諸々の設定をしてFirefoxを起動したのですが、ホスト側でFirefoxを起動していると
>何故かホストのFirefoxが起動します。←２個起動した状態になる
なんのこっちゃ？日本語の意味が分からない。 使用メモリを節約するために、
ホスト側で、すでに起動されていたら、それを使う
起動されていなければ、コンテナ側で起動するように、設定してあるのだろう Raspberry PiのRAMが増えてきたり、MacがARM化したりして、今後ARM版Dockerを使うことも出てくるかもわからんけどさ
ARM版Dockerでx64版コンテナを動かすような方法はもう出てきてるもんなの？
逆はQEMUとの組み合わせで見るけど・・・・ QEMUがVMのことだ
Macの話なら軽量VMは今も使ってる
Linuxの話ならVM無しから軽量VMで遅くなるし
Linux版Dockerはネイティブで動かすからVM使う実装はないだろ >>593
ホストでfirefoxを起動した状態でDockerのUbuntuにログインしているターミナル上でfirefoxってタイプすると
お気に入りとかがすでに設定されたfirefoxが更に起動するんです。
この現象は皆起きているのか自分だけなのか知りたい(´・ω・｀)
これでどう？ だから、そういう設定なんだろう
必ず、コンテナ側のアプリを起動したいのなら、そう設定・指定すれば？ コンテナから外部ホストへのアクセスを制限したい
全て遮断する設定は見つけたがそこから特定のホストを許可する設定が見つからない
可能か？ >>600
そのものズバリがあるでしょ。
航海1日目でずっと停船してるけど。 シークレット管理ってどうしてる？
Ansible Vaultのような仕組みがdockerにもあれば便利なんだがな… >>603
お前はプログラム（exeファイル）の中に
シークレットな情報を埋め込むのか？
そんなもん起動時に渡すに決まってるだろ >>604
そういう低次元な話はしなくていい
起動時に渡すと言っても色々ある
それをどうしたらいい感じになるか？ということをディスカッションしようとしてる >>605
今Dockerを使わない場合はどうしてるんだ？
それと同じものを使えばいい
低次元なのはお前だ。本質を理解してないから
違う方法を使わなければならないと思っている Dockerと非Dockerで最適解が異なるってことを理解してない子がまだいたんだ まだDockerと非Dockerなんて言ってるやつが居るんだｗ >>603
そのものズバリのSecretsがあるだろ。K8sだけど。
よもや本番機をDockerだけで運用するなんて事ないと思うけど。 コンテナランタイムだけで本番機？
メリットが全然分からない。
しかしまあ、あるのならコンテナに埋め込むしかない気がする。
Docker swarm込みでやるなら、これまたズバリのDocker Secretsが使えるみたいだね。 まあ・・・やりたいのならやれば？
とは思うけど。システム的にSecretsをコンテナと分けているって事は
設計として、本番機はコンテナ単独で運用されるものと考えられてない、と思うけどね。 single node swarmでdocker secretが正解 Ruby on Rails では、credentials という仕組みがあって、
ファイルを丸ごと暗号化するので、
マスターキー以外は、git に上げても大丈夫
暗号化済みのcredentials.yml.enc を復号すると、
YML 形式で、下のような設定が書いてある
aws:
access_key_id: 123
secret_access_key: 345 >>618
便利だね
これと同じことをDocker RunやDocker Composeがサポートしないのはなぜなんだろう >>619
Dockerがサポートする話じゃないから。
Railsのそれと同じ仕組みは、単に環境変数で渡したマスターキーを使って
イメージの中に含まれる暗号化ファイルを展開するだけ
ENTRYPOINTを使って自動的に実行できる
つまり全ての暗号化ツールをそのまま使える > Ruby on Rails では、credentials という仕組みがあって、
> ファイルを丸ごと暗号化するので、
> マスターキー以外は、git に上げても大丈夫
便利だね。でもなんでgitがサポートしないのはなんでだろう？
これと言ってることは同じ
ファイルを保存するgitがサポートする話じゃないし
ファイルを保存するDockerがサポートする話でもない そんなことをいったら全部、～がやることじゃない、って理由で機能がオミットされる
オーケストレーションはdockerのやる仕事じゃないからってdockercomposeが公式から削除されることはない
原理主義とらわれず、便利な機能は追加していくべき >>622
オーケストレーションはdockerのやる仕事じゃないから
dockercomposeが別にあるんだろ
gitがcredentialsという仕組みを入れることはない そもそもcredentialsの管理はrorのやることじゃないよな
でもrorは採用した
なぜか？あったほうが便利だから
この柔軟さがRoRの大流行の秘訣だろうな
頭の硬い原理主義者だけではこう上手くいかない Railsがサポートしてるのは（一般的な意味の）credentialsじゃなくて
secrets.yml.enc / credential.yml.enc のことな
このファイルはRailsためのファイルなんだからRailsが対応するのは当たり前でしょう
それに対してDockerの場合は、何を暗号化するというのか？
Dockerイメージの中に、Docker特有の設定ファイルというものはない いやこれはrorのためじゃなくてawsとか一般的な認証情報のためじゃん
完全にオプショナルでRorになくても別に全く問題ないものだ
原理主義的に考えればこれはRorのやる仕事じゃない
でもRorはこれを採用した
なぜか？便利だからだ
この柔軟さがRorの大流行の秘訣だろうな
頭の硬い原理主義者ではこう上手くはいかなかった runするときにenvファイルとマウントファイルを複合してくれるだけでも十分役に立つわな
Makefileに書いてるけどdockerだけで賄えるならそのほうがいい >>627
secrets.yml.enc / credential.yml.enc がなにかわかってないの？ >>625
え、RoRが大流行だと？
いつ、どこのはなし？ 曲がりなりにもOSであるDockerとミドルウェア／ライブラリでしかないRonRを比べるのがそもそもおかしい。
Dockerで秘密情報を管理したいのならコンテナにopensslを入れておけば良いだけだろ。
暗号化したファイルをDockerfileの中で、ホスト側に管理した秘密鍵で複合化すれば良いだけじゃね？
どうしてもやりたいというのなら。 あれ？また変な奴が粘着してないか？
Part 4に誰も書かなくなったのは、そいつのせいだから
来てるなら巣に帰ったほうが良いぜ。 Kubernetes には、Secrets がある
Docker Compose は簡易的なもので、本番では使えないけど 多ハンで一人会話って楽しいの？
Part 4でやってくれない？ 手元にあるコンテナを自前のDockerが動くサーバに配置・元の似たコンテナを停止・新しいコンテナを実行したいんだけどさ
これって自動化や半自動化できないの？
本当はコンテナを作成する時点も含めてCi/Cdのサービスに頼るのが一般的なのかもしれないけど・・・・・
手元の端末でコンテナを作る点が変えられない場合に、配置と実行を楽にする手段ってないのかな？ Task Runner を定義すれば？
Ruby のRake, Thor,
JavaScript, Node.js のnpm scripts, Gulp コンテナ用のRegistryをオンプレ用に立てたい。
何か良い物在る？
出来ればDockerだけでなくhelmとかからimage pullしたい。 >>645
helmに聞いたら？Dockerコンテナ動きますかってｗ >>646
何だ知らんのか。
むしろ「ｗ」って何？ >>648
「じゃあ」って何ｗ？
ちゃんと知ってるなら答えろよ。知らないなら何も言う必要は無いよ。 kuberって物理マシンで何回も
同じ環境構築しとかないとクラスタリング
出来ないんでしょ？
面倒じゃね？ 実行中のコンテナ、ネットワーク、ボリュームをビジュアライズしたいのだが便利なツールおしえて
イメージ的にはネットワーク図のようなものを出力したい >>653
こういうのじゃなくて
ネットワーク図っぽいのを出力したい >>654
View Docker infrastructure data alongside application data in AppOptics
のスクショはどう見てもネットワーク図じゃん。
そもそもどういった、製品に対するDocker版を考えてるのか？ 2.5.0.1 (49550)にアプデしたらめっちゃ軽くなった
なにがあったんだ CPU100%食ってたのがアプデ後正常値になったぞ M1でDocker動かないらしいけどMacってWinと違ってLinuxのDocker入れられないの？ >>665
dockerが依存してるエコシステムがM1対応するの待ってるみたいだね
こりゃ相当時間かかるよ すまんが、Docker + Caddyでポート8080を80や443へリバースプロキシさせたいんだけどさ
docker run -p 80:80 -p 443:443 -p 8080:8080 caddy みたいにすると、ポート8080が使われちゃって、自前のプログラムがポート使えなくて起動しなくなっちゃぜ
順序が逆だとCaddyのコンテナのほうが動かん・・・・
これ一体どうやって使うものなの？ リバプロだけport開けて
他のコンテナはport開けない >>667
YouTube で、くろかわこうへいの動画でも見れば？
「docker 入門」で検索すれば？ 早くmacで使えるようにならんかな
ARMで使えるコンテナってある？ 入門サイト見たり、本買ったりしたけど
未だにこれが何をするソフトなのか、なぜ持て囃されているのかわからない
わからないってことは自分に必要ないって理解でいいのかな >>675
アプリケーションを配布したことはありますか？ >>676
アプリケーション配布というのはどういう意味ですかね
ネットを通して第三者にダウンロード・インストールしてもらうということ？ >>675
使ってるOS・言語・開発者数にもよるが、環境構築がめちゃ楽になるから >>677
それも含む
誰かしらない人に配布する
自分でサーバーに設定する
仲間に使ってもらう
なんでもいいよ。
1. 自分でアプリを開発した経験はありますか？（数行程度の簡単なシェルスクリプトを除く）
2. それを自分以外に使わせた経験はありますか？ Dockerの便利さがわからない人は
自分でアプリを開発した経験がないんだろうなって思ってる
もしくは自分で使うためだけに作ってるとか >>679
1.あり(主に100行程度のVBAやPythonによるテキスト加工ツール開発)
2.あり。共用PCに入れて係のみんなに使ってもらってる > 2.あり。共用PCに入れて係のみんなに使ってもらってる
それは自分のPCに入れて、他の人が自分のPCを使ってると同じこと
なんで、みんなのPCで使えるようにしないの？ >>683
逆、逆
共用PCで運用が回ってるのに、なんでワザワザ皆のPCに入れる必要がある？
Dockerで配布することが目的なってないか？
KISSの法則ってググってみ > 共用PCで運用が回ってるのに、なんでワザワザ皆のPCに入れる必要がある？
みんなのPCに入れれば、作業を並行して行えるようになる
つまり運用がもっと早く回る（改善できる）
共用PCが壊れたときの対策にもなる（リスク対策）
> KISSの法則ってググってみ
プログラム配布する話だからKISSとは全く関係ない >>685
今は共用PCで回ってるんだから並行して行う必要ないんだよ
ワザワザ皆のPCに配布してバージョン違いなど要らんリスクを増やすことはない
それにDockerにしたら皆も使い方が変わって戸惑うだろ
必要がない余計なことをしてシステムを複雑にするな
システムを常にシンプルに保て
これはまさにKISSのことだ >>686
技術の話と「俺の場合は～」の話は別
お前環境の特有の話をして何の意味がある
俺の環境では電気がなくても、運用が回ってるって言ってるのと何も変わらない
議論になってない >>682
ありがとうすっきりした
IT技術者に必須の知識なのかと思って
わからない自分に絶望していた 作ったプログラムは共用パソコンにしか設置したことがありません（自称IT技術者） わかるわからない以前に、IT技術者なら誰だってやってることを
経験してないことに絶望したほうがいいよ >>687
お前ホントに技術者？
どんな場合にも通じる万能の選択肢なんてないんだよ
常にいかなるときでも対象の事情を考えて「この場合は～」を考えなきゃならない
こんな当たり前の事を言わせないでくれますかね
環境特有の話をしないでなんになるってんだよ
今話してる対象は学生のお勉強環境じゃないんだからちゃんと現実を見てくれ >>691
なんになるといってもなぁ
電気は便利か便利じゃないかの話をしてる時に
うち村では電気使わないからいらないんだよ言われても
それは
（電気が便利なのは事実だが）うちの村では使わない
って言ってるだけで、電気が便利であることに否定になっtないので
もちろんこの電気っていうのはDockerのたとえねｗ 学生のお勉強環境＝作ったプログラムは共用パソコンに設置してる
まあ、これは確かに学生のお勉強環境だわなｗ
そういう環境しか経験してないことに絶望したほうがいい >>693
もともと675に必要かどうかの話をしてたのだが？ >>693
あー違う違う
君の主張を例えるなら
ろくに道路も整備されてない村で、配達の効率化を求める村人達がいたとする
そこにきて「F1カーならもっと速く荷物を運搬できますよ」って言ってるのと同じことだ
現場の環境を完全に無視してるだろ？
君の言ってることはまさにこれと同じなんだよ >>693
アホすぎ。ｗ
そもそも、電気が必要でない人だっている、という話になるのに。
マッチの明かりで充分なところに、発電機とLED電球を持ち込ませようとすんな。 >>688
windowsだと思うけど、共用サーバ上や開発者PCで複数のバージョンのPython使う場合、docker入れてると便利
コマンド一発でインストールできる いつものDocker原理主義がまた大暴れしてるのかな？ >>696
それで？F1カーならもっと早く荷物運べますよね？ >>697
それで？マッチよりも発電機とLED電球をみんな使ってますよね？ みんなが馬鹿にしてるとおりですよ
Dockerがいらないと思ってしまうのは、
ろくに道路も整備されてないような場所、電気も使ってないような場所
そういう田舎にいるからだみんな言ってるわけですよ >>701
キャンプファイヤーをしたいヤツに押し付けるのはバカ。 >>703
キャンプファイヤーしたいって誰が言ったんですか？ >>700
レーシングコース回っても荷物は届かんぞ >>702
わかってるじゃん
世の中全てがインフラ整備された理想の世界じゃない
だからケースバイケースで最適解を探さなきゃならん
Dockerなんてのは本当に必要になってから考えりゃいい
ほとんどのケースでは必要ない
今回の質問者にも必要なかった >>706
だからケースを最初に聞いたんですよ？
> 1. 自分でアプリを開発した経験はありますか？（数行程度の簡単なシェルスクリプトを除く）
> 2. それを自分以外に使わせた経験はありますか？
結局、自分でアプリを設置しただけ
IT技術者とか名乗りながら、そういう経験がない人がいるんですよ！ >>705
じゃあ荷物を届くものを使えばいいだけでは？ｗ >>708
最初からそう言ってる
でもお前はF1使うんだろ >>707
そこまではよかった
ワザワザ共通PCをやめて、全員に配布させようと誘導してDockerを使わせようとしたこと
そこからが間違い
質問して、回答が来て、この場合はDocker要らないですね、で終わり
これが正解 配布するとしても、一般ユーザにdockerで配布は無いな 一般ユーザーは下手するとDockerのインストール、初期設定、実行で躓くからなー
サポート地獄になりそうだ
共通PCで上手く回ってるなら、絶対にそのままにしたほうがいい
仮に配布するにしてもDockerじゃなくて、シングルバイナリで動くGoや.NETで作って、配布したほうがいい >>709
いいえ？F1なんて言葉を持ち出した事はありません >>710
「この場合はDocker要らないですね」と条件をつけるって言葉
「この場合」以外ではDockerがいるってことですよね
だから「この場合」を聞いたら、な、な、なんと！
自分で共用パソコンに設置してそれを使ってるだけでした
そんなことしかしたことないんじゃ、技術者とは言えないでしょう 共通PCで上手く回っちゃってるから
結局それより上のことができなくて
技術力は低いままなんですよね
いえ、技術力が低いのがダメだって言ってるんじゃないんです。
技術力が低いという事実を言ってるだけです。
それでいいんです。この人は。 >>714
論理的じゃないねー
この場合以外はケースバイケースだろ
なんでnotになるんだよ
技術者ならもう少し考えてくれ >>717
ケースバイケース、つまりケースによって違うから
幾つかのケースを例に出さないといかんだろ
自分のパソコン（または自分が設置したパソコン）を共用して使うための
プログラムしか作ったことがない"ケース"の人は技術力が低いですね（笑）
配布なんてしたことがないのだからDockerは不要でしょうねｗｗｗ
普通の技術者の"ケース"では他の環境で動かすものを作るから、必要ってことです。
ケースバイケースの意味をちゃんと理解しましょう。
自分のケースだけしか考えないんだという
言い訳にするための用語じゃねーぞ >>718
「ケースバイケース」が気に入らなければ「臨機応変」。
状況にあわない、不要なことを人に押し付けんな。 >>718
また論理的じゃなくなってるぞ
ケースバイケース、多数のケースがある
したがって、いくつかの例を出さなければならない
お前のロジック、ここ全く繋がってない >>718
最も程度の低い技術者の特徴は「対象領域が抱える制約、制限を無視して、一般論的な解答をむりやり当てはめようとする人」だ こんなことをずっと繰り返しているのですが、大掛かりなことをせずにコンテナの停止と実行を自動でやる方法ってないでしょうか？
コードを書く
→ packコマンドでビルド・イメージ化・Dockerへの登録をやってもらう
→ 同名の古いイメージで動いていたコンテナを停止・新しいイメージでコンテナを実行・・・・ここを自動でやってもらいたい
→ 最初に戻る rootのままコンテナ運用するのって危険なんですか?
user root
privileged false
CAP(よくわからん)なし
host bind mountなし(create volumeはあり)
↑で運用してます 危険と言えば危険。
そのへんはふつうのLinuxと同じやろ。 bashでやるのは辛いので、お気楽高級言語でやりてえけどpython、rubyの重いランタイム入れるのもなんだかなぁ
って場合はなんの言語がオススメ？ 見たけどいらんわ。
k8sの上に更にk0s乗っけて学習コスト上がりますよって感じにしか見えない。
シングルバイナリ？そんなもの求めてねーよ。
Lensの動きが見たければやれば？ よく聞くdockerってなんじゃろと思って入門書やってて今kubernatesのところに入ったんだけどなんというか自分がこの技術を使うところというのが想像できなくて困っている
ものすごく大規模なシステムを管理するような極々一部の人だけが使うようなものに思えるんだけどそんなでもない？業界のことまだ全然知らないけどたくさんの人がいろいろなところで使ってるようなもの？ 全く同様。
k8sはVM(ESXiとか）と比べて学習コストが20倍掛かる割には本番機の運用以外に全く応用が利かない。
おまけにIaCでコンテナとかVMとかデプロイする度に作り直すとかいってるけど、これ一歩間違うと大惨事を引きおこす
たくさんの人たちが色んな所で使うもの、では無いな。
ちょっとした使い方したいのなら、負荷が見えないWeb鯖（ステートレスであることが保障されている前提）だけに限って組んでみるとか。 dockerfileって、ビルド時にホスト側で実行したいコマンドって書けないの？ Kubernetes は、Docker Compose をさらに進化させたもの。
cgroup, namespace がある
Docker → Docker Compose → k8s
rolling deploy などで、エラーが起きたら、古いバージョンへ巻き戻せるとか、
より安全なシステム構築運用。
サイボウズのKintone は、k8sで毎日、サーバー千台を作り直しているとか
山浦清透、1/15
Docker超入門講座 合併版 | ゼロから実践する4時間のフルコース
www.youtube.com/watch?v=lZD1MIHwMBY
Windows 10 Home 版, WSL2, Ubuntu 20.04 LTS,
Docker Compose, VSCode, Heroku, Ruby on Rails, Git, CI/CD, CircleCI >>729
POSIXシェルｗ
マジレスするとPOSIXシェルを辛くなく使えるようになったほうがいい
単に勉強したくない言い訳としてbashのせいにしてるだけだろう？ >>743
書けるわけがない。
サーバーに送って、サーバー側で処理してるんだから HashiCorp のTerraform, Packer とか
AWS CloudFormation は、Ruby のKumogata。
他にも、Chef, Cookpad製のItamae とか、Rubyが多い >>743
カプセル化ぶっ壊すようなこと、dockerの思想に反するだろ。 dockerコンテナってLinuxだとどれくらいで実行できるもんなん？
Windowsでやってるけど1秒ぐらいかかるんだよね
もっと早く実行できる？例えばdateコマンドとか Windows 10, WSL2 なら、本物のLinux
プロジェクトをLinux側へ作れば、ext4。
Windows側なら、NTFS だから遅い >>750
Windows版のDockerは仮想マシン上のLinuxで動いてるのでどちらにしろext4ですよ
ただしNTFS上に作られたファイルをext4として読み書きしてるから変換レイヤーが入る
ミリ秒レベルのパフォーマンスには参考にならない >>749
docker exec echoだけでちょっともたっとするもんな。
ためしに、dockerサービスの優先度をあげたら？ >>752
あーいや、遅くて不満、速くしたいとかいう話じゃなくて
Linuxならどれくらいで動くのかな？っていう疑問
もう少し具体的に事情を話すと、ある小さいバイナリがあって処理時間は短いんだけど
何回も起動するものだから起動時間が重要になっている
プログラムの性質から常に起動しっぱなしにするとかに設計を変えることはできない
でもインストールするのに手間がかかるからDockerで提供することも考えてる
だけど起動してから完了するまでの時間が重要だから
Dockerを使うことで大幅にパフォーマンスが低下するようだったらやる意味がない
Windowsでは1秒近くかかるから確実にやる意味がない。その点はmacOSも大差ない。
Linuxでもう少し短くなるならLinux用としてはギリ提供する意味があるかなと思って
echoだけだとせめて100ms、できれば10msぐらいまでなら意味があるんだけど >>753
sshdとかhttpdを立ち上げて、そっちで受けたら早くならんかな？ バイナリだけもらってるとかなんかやばい案件ぽい。関わりたくないな >>753
ネイティブのLinuxでもechoで10msは無理な気がする ソースコードあるなら他にいくらでもやりようがあるだろ。
それも思いつかないほど馬鹿なの？ それよりも、なんでどれくらい時間がかかるかを答えないんですか？ >>758
そうなんかね？
WindowsやmacOSだとHTTP通信でDockerとアクセスしてるけど
Linuxだったらsocket通信でしょ？さすがに速いと思うけど まさかとは思うけど
>>749の言ってる「1秒くらいかかる」って、
コマンド実行の都度dockerコンテナを起動/停止しててそれに1秒くらいかかってる、ってオチじゃないよね？
dateコマンドとか例示してるのがちょっと不安なんだけど >>755
CLIならsshでいけるやろ？
何が無理なん？
>>761
Windows版は名前つきパイプで通信してたような。
Dockerサービスが稼働してないときにdockerコマンドを実行したらわかる。 その答えてもらいたい質問ってどれのこと？伝わってないんじゃないかね？ 一行目
749 名前：デフォルトの名無しさん[] 投稿日：2021/05/09(日) 10:17:26.76 ID:tIUHIMYF [1/4]
dockerコンテナってLinuxだとどれくらいで実行できるもんなん？ >>767
いや、こんなの環境によっても違うし答えようがないんじゃね？どんな回答を期待してる？ >>769
みんなヒマやないからやろな。ｗ
べつに義務やないし、興味もなければ誰もわざわざやらん。 >>770
あなたがLinuxで実行した結果を期待してる >>771
俺は手元にLinuxマシンがないからすぐに無理だけど
手元にLinuxマシンがあって、レスする暇があるならできるでしょｗ あー、ID:tIUHIMYF＝ID:QngfRO5p なのか
前提を整理して提示しないまま漠然とした質問をしたところで漠然とした答えしか返ってこないだろうよ
でもって解凍してあげようとしてる人たちを馬鹿にするような口調・態度をとって答えてもらえるとでも思ってるのかね？
よそへいきな >>772
なるほど。うちの環境だと3秒くらいだ。これで満足か？ >>762
そういうオチだと思うけど
使い方を間違えてる >>761
Dockerじゃなくて素のLinuxって意味で書いたんだが10msでコマンド起動は無理じゃないの >>776
Windows上のDockerでも1秒程度なのに
Linuxだと3秒もかかるの？ >>777
正しい使い方と、その時にかかる秒数（1秒未満なはず）を書いてくれればいいよ。 >>779
そりゃ環境とかの条件によって違うしな。>>749みたいなぼんやりした質問にはそういう回答しか返ってこないだろう。
どっちにしても、もうあんたに真面目に回答してあげる人はいないと思うが。 普通に time docker run -it alpine echo でも実行するだけなんだが
ここまで言われればその結果を書くぐらいできるよな 典型的クソ野郎すぎて話にならんわな。
なぜ誰も答えないのかについて考える頭もないんだろう。 >>785
バカに答えを教えてやるよ。
お前が後出しクソ野郎だってのが明確だから
答えた途端にめんどくさくて気分悪くなる返答してくるだろうなってのがわかるかだらよ。 >>782
回答来ない来ないと駄々こねる前に自分の質問を見直してそういう情報をちゃんと出していれば
周りの対応も違っただろうにねぇ。 ここの連中は技術が有っても煽てに乗りやすいアフォだから、低姿勢で聞けばいくらでも教えてくれるのにさw
だが、自分で考えようとしないヤツには超絶冷たい。 > 回答来ない来ないと駄々こねる前に自分の質問を見直してそういう情報をちゃんと出していれば
最初にちゃんと情報出していると思うが？ 聞きたい答しか聞きたくない！
と大上段からいくヤツは、だいたい適当にあしらわれるもんやな。 今回はtimeコマンドの結果を出せばいいだけなんだから
出さないほうが悪いよ >>795
>聞きたい答しか聞きたくない！
聞いたことには答えない！
これも追加で 自分でやりたくないから文句いうだけのレスをするんだろうねｗ ID:1enRFFJU = ID:Qz+CRcrD だと思ったんだが、そうだとすると
>自分でやりたくないから文句いうだけのレスをするんだろうねｗ
これってここの回答者のことを言っているのかな？
そりゃ誰もこいつのためにやりたいなんて思うわけないだろうけどw どんなに時間があっても、ヒマでヒマでたまらんかっても、おまえの知りたい時間を計測しても、とにかく、おまえには答えん！
てとこやろ。ｗ
時間の有無はまったく関係ない。 >>804
煽る時間は有るんだ
ここでゴネてないで自分でテストすれば? Linuxマシンがないからね。何で聞いてるのかわかってもないか >>808
Hyper-VにWindowsとLinuxを入れれば同じ土俵よ 多分何も理解してないと思うよ
単に雑談相手が欲しいいつもの人だろ だからすぐ答えを返せば終わる話を、答えを言わずに延々と続けてるわけか スレで総スカン食った奴が祟り神になってとり憑くパターンw 相変らずここの住人のコミュ力は極めて低いね。
「１＋１の答えは何？」ってレベルの質問なんだから「２」と答えるだけの事が数日かかっても出来ない。
>>762
[root@test-docker-28 ~]# time docker run -it alpine date
Sat May 15 00:36:53 UTC 2021
real 0m0.685s
user 0m0.023s
sys 0m0.032s
[root@test-docker-28 ~]# time docker run -it alpine date
Sat May 15 00:36:55 UTC 2021
real 0m0.684s
user 0m0.025s
sys 0m0.030s
[root@test-docker-28 ~]# time docker run -it alpine date
Sat May 15 00:36:56 UTC 2021
real 0m0.694s
user 0m0.026s
sys 0m0.032s
オマケ： ホスト [root@test-docker-28 ~]# time date
2021年 5月 15日 土曜日 09:38:26 JST
real 0m0.002s
user 0m0.000s
sys 0m0.002s
※Windowsよりはマシだけど、Dockerの実行速度は総じて遅いんだろうね。 最もこれだと、イメージからコンテナ生成する時間含める事になりそうだけど。 答えはNOだな。
750以降50レスも無駄に消費して何一つ生産的な会話が無い連中こそどっか行けよって話。 >「１＋１の答えは何？」ってレベルの質問
ある意味合ってるw
こんなレベルの質問の答が欲しくて延々と粘着している奴。 手元にLinixマシンが無い、っていってるじゃん。
ホント、文章が読めないのねｗ この例えで言うならみんなは持ってる1+1の答えを出すための計算機が手元にありませんってことか？
知りたいなら用意しろよｗ >>821
で、>>821を読んで「それなら仕方ないね、俺が答えてやろう」なんて言う奴がいるとでも思っているんだろうか。
駄々こねておもちゃ買ってもらえるのは子供だけだぞ。 >>824
>それなら仕方ないね、俺が答えてやろう」なんて言う奴がいるとでも思っているんだろうか。
俺が答えてあげてるじゃねーか。
てか749よんで816以外の回答は思いつかんが？
749に対して、自分で調べろよ、とは思っても環境が手元に無いというのなら、816以外はありえない。
その上で>>762というなら、「じゃあ、最初から起動状態のコンテナ上でどう改善するか調べてやるか」
とでも思う訳で。750以降の連中がやった1週間のやり取りは完全に無駄。 >>821
はよ買え！
1+1なんか、答を人に聞かずに自分でやるべき。幼稚園やないんやから。ｗ だからそういう揚げ足取りしか出来ない連中は、コミュ力の低い無能連中に見える、と言っている。
750レスで816を投稿すれば、実行の遅いオーバーヘッドの原因は何なのか？という生産的な話題に発展するけど、
無能な連中はそれが出来ない。 そもそも time docker run -it alpine echo を測るって話は>>782で後出しで初めて出てきたんで、
>>749の時点でわかったならエスパーか本人だな。
>750以降の連中がやった1週間のやり取りは完全に無駄。
無駄もなにもw、>>749の役に立ちたいなんて思う奴は皆無だったろう。 言っとくが俺は748と別人だからな。
>話は>>782で後出しで初めて出てきたんで、...
しるかよ。久しぶりに今日見たらまーた無能連中が無駄なやり取りしてるから俺が調べてやっただけだ。
749の役に立つ必要なんて無い。Dockerの話しろよって事で。
どうでも良い揚げ足取りばっかやってんじゃねーよ。 そう思うならどうでもいい話を蒸し返すなよwもう終わってたのに。 ↑
>だからすぐ答えを返せば終わる話を、答えを言わずに延々と続けてるわけか
と、終わってる様に見えないから、俺が終わらせようとしてるんだろ？
で、俺から見ると金曜日までにこの話題に携わった連中は無能にしか見えない。 超粘着気質なのは分かった
仕事では関わりたくない面倒くさいやつだ >>832
いやいやｗ
他の人は「誰も答えてやんないからどっか行け」で終わってる話。
「答えてくれるまで終わらない」って頑張っているのは>>749本人だろう。 ここは人とコミュる板なのか、Dockerというシステムに対する板なのか、理解できてないんだなｗ
君は「ぼくのだいすきななかまたちのスレ、ぼくがきらいな奴は出て行け！」とか言いたいんだろうねｗｗ
第三者はそういう見方はしないからｗｗ
あれ？Dockerに対するXXの問題は終わってないよね？という見方しかしないｗ
感想に対しては全くそのとおりだね。
こんなに無能な奴とは一週間仕事したとしても何の成果も生まない事が、やり取りだけで良く分かるｗｗｗ 問題に対する貢献を何もしないで、答え出せって言い続ける馬鹿に答えてやるわけないだろ。
前提からして勘違いしてるバカは出ていってくれ。 >>816
因みにすでに稼働中のコンテナに対するテスト。やはりホストの直実行に比べて大変遅い。
[root@test-docker-28 ~]# docker container ls | grep php_test
2782ad3cf676 mytag/php_test:latest "docker-php-entrypoi…" 2 days ago Up 2 days 80/tcp php_test_1
[root@test-docker-28 ~]#
[root@test-docker-28 ~]# time docker container exec -it php_test_1 date
Sat May 15 16:51:44 JST 2021
real 0m0.323s
user 0m0.029s
sys 0m0.022s
[root@test-docker-28 ~]# time docker container exec -it php_test_1 date
Sat May 15 16:51:45 JST 2021
real 0m0.318s
user 0m0.026s
sys 0m0.030s
[root@test-docker-28 ~]# time docker container exec -it php_test_1 date
Sat May 15 16:51:46 JST 2021
real 0m0.310s
user 0m0.027s
sys 0m0.033s >>816
因みにpodmanでの実行結果。Dockerより多少早い。極く僅かだけど
[root@dev-podman ~]# time podman run -it alpine date
Sat May 15 08:24:59 UTC 2021
real 0m0.611s
user 0m0.122s
sys 0m0.126s
[root@dev-podman ~]# time podman run -it alpine date
Sat May 15 08:25:01 UTC 2021
real 0m0.611s
user 0m0.121s
sys 0m0.123s
[root@dev-podman ~]# time podman run -it alpine date
Sat May 15 08:25:02 UTC 2021
real 0m0.561s
user 0m0.109s
sys 0m0.110s
[root@dev-podman ~]# >>821
世の中にはKNOPPIXとかのDVD,USB起動linuxがあるんだから、それ使えばいいだろ。
性能比較するだけなら、virtualboxあたりに比較用環境をこしらえて動かせばいい。 ここまで書いてあげるのに未だそんな事を言ってるのね・・・
749が環境用意できないといって、俺が変わりに実行してあげて、実行結果も出ていて、問題点もわかった。
0.1秒以内に終わるなら提供する価値があると言っていて、ホストLinixで稼働中のコンテナに対するコマンドなら
0.3秒でおわるっぽい、後0.2秒は削れないのか？とか
イヤ、そもそも何故コンテナの呼出すだけでこんなにオーバーヘッドかかってるの？とか、
sys+userの実行時間はそれなりに短い、にも関ずrealは0.6秒かかっているがその差分は何なのか？とか
816,838,839眺めてるだけで、色々考慮点が出そうな物で、それこそDockerのスレにふわさしい話題の筈なのに、
そういった問題点に一切目を向けず、まだUnixインスコしろ～とか、どんだけレベル低いの？ >>840
それな。
dockerは起動時にネットワークとか作るはずだから
そういうのを省いたら少しはましになるかも >>841
成程、若干早くなったみたい。何故かnoneよりhostの方が早くて不思議だけど。
[root@test-docker-28 ~]# time docker run --network="none" -it alpine date
Mon May 17 07:29:33 UTC 2021
real 0m0.709s
user 0m0.038s
sys 0m0.031s
[root@test-docker-28 ~]# time docker run --network="none" -it alpine date
Mon May 17 07:29:34 UTC 2021
real 0m0.688s
user 0m0.030s
sys 0m0.032s
[root@test-docker-28 ~]# time docker run --network="none" -it alpine date
Mon May 17 07:29:36 UTC 2021
real 0m0.707s
user 0m0.035s
sys 0m0.028s
[root@test-docker-28 ~]# time docker run --network="host" -it alpine date
Mon May 17 07:29:41 UTC 2021
real 0m0.567s
user 0m0.031s
sys 0m0.029s
[root@test-docker-28 ~]# time docker run --network="host" -it alpine date
Mon May 17 07:29:42 UTC 2021
real 0m0.549s
user 0m0.032s
sys 0m0.022s ↑
これ、ほぼほぼ real = user + sys + 0.5 s
だけど0.5秒はコンテナを呼び出すruncのコストそのもの？
だとすると>>753の要件は絶対に満たせないから、この人は
伝統的なconfigure+makeで提供してホストで直実行って感じなんだろうね。 >>843
もともとホストで直接実行するのがメインのツールなのでそこは問題ないんだけど
ライバルツールがDockerでも提供していて自分もやる意味あるかなぁ？という話
ライバルツールは実行に十数秒かかるようだし、依存ライブラリ等の
インストールが必要みたいでDockerで提供する意味がある
自分のは一瞬で終わるし依存ライブラリなどもない
（>>753でインストールに手間がかかるって言ったのはフェイクｗ）
でも比較表とか作られたら
相手のは Docker で提供・・・○ で
自分のは Docker で提供・・・× になるじゃん？ｗ
それもいやだなぁと思うけど、かといって面倒なことはしたくない
Dockerで提供する理由を探してるけどやっぱり見つからんなぁ >>844
>相手のは Docker で提供・・・○ で
>自分のは Docker で提供・・・× になるじゃん？ｗ
>
>それもいやだなぁと思うけど、かといって面倒なことはしたくない
>Dockerで提供する理由を探してるけどやっぱり見つからんなぁ
おいおい、自分で答えを言ってるじゃん。Dockerで提供する理由？？
自分のは Docker で提供・・・○ にして私のツールはライバルと同じサポート範囲ですよ、と言うｗ >>845
だから自分の場合Dockerをサポートする理由がないんよｗ
なんであんたDockerで提供してんの？
え？依存ライブラリが必要だから？ああ、うん・・・
でもそれ俺にとっては意味ないし・・・
そもそもメインのユースケースはDockerなしで使うものだし・・・ 知らんがな。
ここはDockerスレであって、おまえのフェイクアプリのスレやない。 まあ、そういうことやな。
アプリの結論は843で「じゃあどうすれば呼び出し早くなるのさ？」を
語るのがこのスレ。defaultRuntimeをruncから別のものに変更すれば早くなるのか？
https://github.com/jessfraz/docker/blob/master/daemon/daemon_unix.go#L63-L65 しかたないな。じゃあもしそういう比較表でも登場して×がついたら
「圧倒的に速く依存ライブラリもないから必要がない」に変更しろって
そのサイト管理者にでもクレームでもだすかｗ Docker学習しようかなと思ってwindows for Docker入れたら使えなくて調べたらhyper-vに対応してない化石cpuが原因だったみたいです
今ryzen5 1600でマザボ的にryzen5 3600が買い替え候補なんですがryzen5 3000番台がhyper-v対応かどうか知ってる方いますか？ >>852
プログラム開発で困りたく無いのならAMDじゃなくてIntel一択です。 そのレベルじゃDockerやっても躓くだけって気がするけどね。 Windows 10 Pro 版、
CPU-i7, メモリ16GB(出来れば32GB)以上、SSDは256GB 以上
メモリ8GB じゃ、動かないかも
例えば、Ruby on Rails なら、WSL2, Linux, Docker Compose,
VSCode(拡張機能・Remote Container, WSL2 ならRemote WSL)
CPU に仮想化支援機構が付いていないと、仮想マシンを使えない
AMD は、よく知らない。
新しいMac も、CPUが変わったから、知らない docker-compose.yml
web01
build : php-fpm:latest
image : web01
web02
image : web01
↑docker-compose.ymlで上記のような指定をするとwe01とweb02は同じイメージを使用してインスタンス作りますが、
web02だけcronをインストールしたい場合、どのような方法があるでしょうか？
docker-compose up -d のコマンドを実行するだけでweb01とweb02の差分がcronのインストールだけになるようにしたいです。 web02固有の環境変数定義
a. entrypoint内で環境変数をみてcrond導入(動的な導入コストを許容できるなら)
b. crond導入済み + entrypoint内で環境変数をみてcron.dへのリンクを有効化
c. crond導入済み + 02のみymlでcron.dの外部ボリュームを用意しといてmount
d. crond導入済み + crontab内で環境変数をみて動作 (なのでcronは動作してしまう)
個人的にはイメージ分けるけど次点でbかc >>857
大変勉強になります！
提案頂いた方法で試してみます！
ありがとうございました！ 本番環境でdockerをAWSとかじゃなく
自前でホストするベストな方法ってなんですか？ 多数のnodeが使える環境じゃないとkubernetesはオーバースペックよな。 OpenStack と OpenShift の関係って？
https://ts0818.hate＠nablog.com/entry/2020/04/05/181720
注意！ アクセス禁止にされるのを防ぐために、URL に＠ を入れています
OSS のOpenStack(IaaS)とか、
Red Hat OpenShift は、Docker, Kubernetes(k8s)
鉄鋼のJFE は、OpenStack を使っているとか オンプレミスケースだと
開発dockerでやっといて、
運用もdockerでやるのは少ないのかな？ オンプレミスを選択されるユーザーの場合
運用スキルが高くない場合が多くて
k8sとか難しいのは敬遠されるんだよなーー
初心者でも簡単な
dockerホストの方法ってないんでしょうか？ >>865
運用スキルがどうこうよりも、客の環境としてホントにk8sが必要なの？が気になった。
なんか流行ってるしカッコ良さそうだから僕使ってみたいですーにしか見えん。 リバースプロキシとの連携、冗長・スケーリング構成も考えると
k8sないとつらくないか
従来どおり自前でももちろんできるけど
いけてる管理系ソフトやベンダーついてたらこんな質問せんだろうし オーケストレーションツールが無いと、
Rolling Deploy, Blue Green Deploy などが出来ない
システム更新して失敗したら、簡単に巻き戻せない。
サイボウズのKintone も、千台とかをk8s で、毎日作り直しているとか
普通、毎週システム更新する
それが面倒だから、AWS Fargate, Elastic Beanstalk(Paas), Lambda みたいな、
管理不要(managed)のものを使えと言われる >>866
一つのブロダクトを複数のテナントに展開しますが、
基本線はAWSで運用するのを基本としますが、
客によってはオンプレのケース実際あるのでその場合の対応ですかね
いまんところ良い方法が確立するまで
オンプレはdocker使わずに都度構築なります >>868
>>AWS Fargate, Elastic Beanstalk(Paas),Lambda みたいな
こういうのって使うとベンダーロックインしません？
あんまり詳しくないですが、
そのため使用を避けてます YouTube で有名な、雑食系エンジニア・KENTA の初心者用コースでは、
Ruby on Rails, Docker Compose, Heroku, CircleCI などが入っているけど、
最近は、AWS Fargate, Terraform なども入ってきてる
元々は文系女が、Rails, Heroku で、一人でビジネスを始めるものだけど、
最近は、Fargateも常識になってきたので、
皆、AWSのくろかわこうへいのサロンにも入る
ベンダーロックインと言うけど、
どこかのクラウドを選ばないとビジネスできないから、AWSを選んでいるだけ
米国年収では、Railsが1,300万円で、
AWS Solution Architect が1,400万円と、ついにRailsを超えて最高位になった！
今、最も必要な技術が、Rails, Docker, Fargate の3つ。
だから、ほとんどの学校・サロンは、これが中心
Udemy の山浦清透も、学校を作っている最中らしい。
こういう人達が、IT 教育革命を起こしたので、
今の1年ぐらいの未経験者は、10年以上のプロ以上の技術力がある！ > どこかのクラウドを選ばないとビジネスできないから、AWSを選んでいるだけ
これ
もしGCPに移すことになっても改修が必要でも
自前で維持し続けるコストよりはるかに大したことないし
k8sやServerless Frameworkである程度自衛もできる
セキュリティ要件なのかしらんがオンプレとの連携も充実してるし営業に相談した方がいい
十中八九インフラ担当者が老害なんだろうけど YouTube に、Udemy の山浦清透の新動画ある
Docker知らないとWeb開発を任せられない？Dockerは初学者に必須？
Dockerできない香具師は、クズみたいな論調で、
Dockerできない香具師が大暴れして、
Twitter のトレンドに入っていたらしいw
これは、YouTube で有名な、雑食系エンジニア・KENTA の初心者用コースに、
Dockerが入っているから
今は、Dockerどころか、
AWS Fargate, Terraform まで入ってきてるから、
初心者でも、AWSのくろかわこうへいのサロンにも、入る必要がある
今の1年の未経験者は、10年以上のプロよりも技術力が上になってるから、
何も勉強しない老害が、勉強してる香具師は馬鹿とか、大暴れしてるw
自分は偉い偉いと念仏を唱える、勉強しない老害の現実逃避w 5chは老害の巣窟ですよ。
子供は他所で遊んだ方が良いですよ。 俺たちも高卒人間をコンテナに詰めて集金するシステムを作りたいものです よくわからんけど山浦清透とKENTAとくろかわこうへいが高卒老害って理解でOK?
でコイツ等が自分は経験１年未満だけど１０年プロ選手より技術力が上だと言ってるの？
こんな過疎スレで広告連投とか、マジで気味が悪い。 >>864
ウチは規模小さいんで本番もdocker
docker composeでお気楽運用
開発環境と本番環境の差異を大幅に減らせる
デプロイが楽ちん
これだけでも導入するメリットあると思うけどねー 小規模ならそれで良いわな。
バックアップだけ、どこをどうやって取るか決めて。 >>870
まあ、ベンダーロックインいやなら自前でホスティングすればいいだけ。 K8Sはわからん諦めた言うやつでもdocker composeはわかる
本番環境としてswarmはなかなか悪くない選択肢だと思う
オンプレミスで構築すんのも簡単 ただswarmはnamespaceが無いのが惜しい
オンプレswarmクラスタを異なる顧客案件で共用してコストダウンしたいけど隔離性が問題になる Dockerの存在を昨日知って勉強を始めました。
おもしれー。
質問はまだないです。質問できるほどまだ理解してない。
糞レスです。 Welcome to Underground... Udemy の山浦清透、8/20
【金額公開】Webサービスの運用費用、実際いくらかかっているか1円単位までお見せします
https://www.youtube.com/watch?v=nRO7pFCdM8E
このAWS のシステム構成図を見てみ
ECS on Fargate, Cloud Front で、
コンテナ内には、Laravel, Nginx の2プロセスしかない
YouTube で有名な、雑食系エンジニア・KENTA のサロンでも、
Ruby on Rails , Linux, Docker Compose, Node.js(Webpack, Babel), Bootstrap
VSCode(Remote Container, WSL2 ならRemote WSL), Heroku, CircleCI、データベース
今までは、Docker Compose までが初心者用コースだったが、
最近は誰でも、Docker出来るから、
AWS Fargate, Terraform, React, Vue.js, TypeScript も入る。
これ以上は、Kubernetes
だから、AWSのくろかわこうへいのサロンにも、入る必要がある。
この3人が日本で、Docker, AWS を流行らせた、3大サロン イメージレジストリからpullしたコンテナイメージが本当に正しいものかってどうやって確認すれば良いんやろ
digestかimage idがおなじなら同一って思っていいのかね(´・ω・`) 本当にイライラするわ。何が一番イライラするかって、全く意味不明な事だよ。
俺は別にIT関係の仕事に就きたい訳でもないのに、Git Hubにある高性能なアプリを使いたいからこんな意味不明な事をやらされる。
一つのアプリ入れるのにいくつソフト入れるんだよ馬鹿かよ。それで環境構築しても、結局上手く行かない。もう死んだらいい。Git Hubに載せてる奴らは全員。
なんでアプリで提供できないの?馬鹿なの?死ぬの?本当理系陰キャは全員滅びて死に絶えろクソが 自動車関係の仕事に付きたいわけじゃないのに
めんどくさいことさせるなって
言ってるのと同じだな ビルドもできないような無能は相手にしたくないということだろ。開発者はお前のママじゃないんだよ。
金を払ってコンサルかサポートでも雇え。 「金を払って雇ったコンサルがママだった件について」 sshポートフォワードで繋いでるDBがあるんだけど
特定のコンテナのみからこのポートに接続させる簡単な方法は無い？ > 特定のコンテナのみから
踏み台のauthorized_keysで
コンテナに存在する鍵のみポート転送許可してあげる
ssh実行はコンテナ内からする必要があるから
ENTRYPOINTか起動後にexec内で こんな感じでいけた
services:
ssh:
image: myssh
volumes:
- path/to/secrets/id_rsa:/id_rsa:ro
command: sh -c ‘cp /id_rsa ~/.ssh/ && chmod 600 ~/.ssh/id_rsa && ssh -N -L 5432:5432 remotedb’
app:
image: myapp
environment:
DBHOST: ssh
DBPORT: 5432 ssh -i identity_file
とできるんでcpする必要はない docker desktopの更新しようとしたらトロイの木馬検出で失敗する・・・ docker composeでコンテナを起動するかしないかをコマンドライン引数以外で選択することは可能ですか？
例えばdocker-composeにa、b、cの３つのサービスが定義されてるんだけどa、cだけを起動したい
コマンドラインで指定できるのは知ってるけどそうじゃなくてdocker-compose.ymlで指定したい >>902
そんなあなたのために、フォーマットバージョン3.9からサービスにprofileを指定することができるようになりました docker desktop でホストコンピュータからのアクセスでパケット詰まりしやすい
コンテナ間アクセスだとほとんど詰まることないんだが
どうにかならんだろうか 「docker-compose.yml」に次のように書かれていて、コンテナには
公式の「FROM php:7.3-apache」を使っています。
apacheのログを見るとアクセス元のIPアドレスが「docker_default」ブリッジの
IPアドレスになってしまうのですが、接続元のIPアドレスをログ出力できないでしょうか？
ググってCDN経由のときは「%{X-Forwarded-For}」を指定すれば接続元IPが出るとあったのですが
CDNを使ってないため「%{X-Forwarded-For}」の中身は空でした。
==========docker-compose.yml==============
version: "2"
services:
api:
container_name: api
build: ./api
restart: always
ports:
- 80:80
volumes:
- ./www:/www
networks:
- default
networks:
default:
driver: bridge 初心者です。すいません質問させてください。
既存のコンテナを落としてきてImageから展開しています。
あるふぁいるを展開したコンテナのファイルと置き換えたいのですが、
どの様な手法が正しいのでしょうか？
既存展開後のコンテナに転送して、コンテナにログインしてから置き換えをしても、
コンテナの停止、起動をしたら対象のファイルがなくなっていました。
Images の中に入れるのが正解なのか、コンテナ展開時にファイルを取り込み置き換えをする
方法があるのか判っていません。
どこかに参考になるページがあれば教えてほしいです。
※ファイルは不定期で更新するので、コンテナ展開時に自動で取り込み置き換えをする
方法が望ましいと考えています。 自分も最初その疑問にブチ当たった。
今ならYoutubeの2～4時間程度の無料動画を見れば解決すると思うからおすすめ。 まず「コンテナを展開する」という用語が分からない
AWS, Github, Gitlab, CircleCI など、
すべてのシステムがコンテナを使っているのは、immutable・破棄可能だから
コンテナ内には状態を持てないから、
関数型言語と同じで、プログラミングしやすい
状態を持つには、Data Volume という領域か、
Data Volume Container というデータ専用コンテナを使う。
それらは、複数のコンテナから参照できる
この本が最も簡単。
自宅ではじめるDocker入門[改訂版]、浅居 尚、2021/4 >>906
Amazon Linux 2, Ruby on Rails, Nginx, Puma の構成では、
Nginxの変数・$remote_addr が、クライアントのIP アドレスみたい
Apache にも、同じような変数があるのでは？ windowsのwsl2でdockerを使用しています
wsl2で作成したディレクトリと、wsl2のcontainer内で作成したディレクトリだと、
前者はwsl2ユーザ権限、後者はroot権限になってしまうので、
リモートvscode内でcontainer内のファイルが編集できなくなります
その都度、sudo chown -Rを使用して権限を統一させているのですが、
毎回やるのは手間でして・・・
windowsのwsl2でdockerを使用している方は皆さん、
権限の問題はどうされているのでしょうか・・・？
どなたか心当たりある方いらしたら、ご教授をお願いいたしますm(_ _)m 一時ディレクトリとかを除いてコンテナの中にディレクトリとか作らないからなあ
プログラムのバイナリの中にディレクトリができるっておかしいでしょ？ レスありがとうございます
もしかして、Docker内でプログラミングをする方は少ないのでしょうか？
親のWindowsの環境がぐちゃぐちゃになるのを防げるので良いなと思い使用していたのですが・・・
Dockerの主な用途は環境構築と実行のみでコードを書くことは基本しないということでしょうか
よくよく考えるとDocker内ではなくてWSL2内でもプログラミング自体はできますね 普通コンテナ内に、ディレクトリなど作らない
コンテナは削除可能disposable で、状態を持てないから、何も保存できない。
データは、コンテナの外部に保存する
data volume、データ専用コンテナ、volumes-from とか
>>909
に書いた本が、最も簡単 >>911
Dockerfile USER 1000 >>914-915
お教え頂いた単語を調べてみたところ
昔から普通にある問題？だったのですね・・・
自分なりに調べてはいたのですが中々回答を得られなかったところ
何とかいけるようになりました！
書籍の方もぜひ調べさせて頂きます
教えて頂きありがとうございました！ >>916
「問題」やなくて、ふつうに「仕様」やからね。 WSL2 では、プロジェクトはWindows 側・NTFS ではなくて、Linux 側・ext4 へ置く
Docker はLinux だけの技術だから、
NTFSではファイルシステムが異なるから、遅くなるとか、
確か、WSL2, Docker の説明に書いてあった あわしろを召喚しちまうからLinuxの話題はやめとけ 長時間プログラムを動かし続けたらエラーとなり、その後一切正常に動かなくなったので調べたら /dev/sda1 100% となっていて、これが原因ではないかと思い調べています。
プログラムはログ出力やDBへのデータの登録やファイル作成などをしておらず、何が容量を圧迫しているかわかりません。
わかる方いましたら原因と対策を教えてください。
参考になる記事でもかまいません。
よろしくお願いします。 何も食べてないのにお腹いっぱいになりましたと言われてもな
食ったんだろ コンテナ内でプログラムを動かし続けているだけでホストの/dev/sda1の容量が増え続けて100%になってしまうのです。 テンポラリファイル作ってお掃除忘れてんじゃないの
てか圧迫してるファイルの種類や内容調べれば手がかりわかるはず 自宅ではじめるDocker入門[改訂版]、浅居 尚、2021
という本には、
data volume(DV), data volume コンテナの2つがあって、
docker rm で、DVコンテナを消してから、
docker volume rm で、data volumeを消すと書いてある
つまり、DVコンテナを消しただけでは、data volumeは消えていない。
例えれば、data volumeが実体で、DVコンテナはそこへのリンクみたいなもの
リンクだけ消しても、実体は残り続けているという事 ここはためになるなぁw
俺は今更docker使おうかなと思ってるじーさんだけど
このスレでの言い争いもふくめて
使用すべきシーンや注意点などとても参考になった
ありがとう住人さん Linux 板にも、Docker スレがあるかも
ただ、Linux板は、あわしろがどうしたこうしたとか、
荒らしが多いから、規制されて書き込めない YouTube で有名な雑食系エンジニア・KENTA の、
初心者向けRuby on Rails サロンによって、
半年で10年やってるプロよりも、技術力が上になる道筋を作った。
こういう勉強方法で半年で、Railsエンジニアになって転職できますよ
2, 3年前は、Rails, Heroku, Bootstrap, jQuery だけで、すごかった
それが今では、Docker, AWS, GCP, Terraform, CircleCI, Github Actions,
React, Vue.js, TypeScript みたいなw
誰でも、Docker, AWS 出来ますよね
Dockerを知らない香具師は、技術者ではありませんとか、
皆、くろかわこうへいのAWSサロンにも入ってますよね、みたいなw
ウェブ開発未経験者の進化が桁違い！ 最近初めて使ってメモリバカ食いやんて思ってたけどアップデート治ったっぽい？ docker初心者でdocker desktop始めたンダが、質問させてください
ローカルの設定ファイルにアプリのパス書かずに省略したらローカルにフォルダ出来ないんですかね？後でローカルにフォルダ追加するには設定ファイル書き換えてビルドし直すといいのでしょうか？ ドカデス使わなくなったんだがPC立ち上げると毎回自動で起動するけどどうやってオフにすんだろう >>936
General設定のStart Docker Desktop when you loginのチェック外すだけだったと思う 初心者ですが個人開発でDocker使ってる人って多いですかね？
自分がDockerってなんなのか調べた限りだと不必要かと思うのですが >>939
Dockerとは仮想環境上に開発環境を作ることですよね？
それでその中で開発を行うとみんなが同じ環境で開発できると
ただ個人開発だと開発環境=個人の環境になるのでわざわざ仮想環境の上で開発しなくても良いかと >>940
それあなたの場合が開発環境レベルのものが要らないからですよ
例えばExcelのVBAとかなら要らんですな >>941
開発環境はVisualStudioCommunityを使っています 例えば個人開発でDockerが必要なケースって何がありますか？ maui開発してるだけなら100%不要
さっさと巣に帰れ >>944
では個人開発で必要なケースを教えていただいてもいいでしょうか？ お前みたい奴には一切縁がない代物だからとっとと帰れ 個人開発でDockerを導入して得られるメリットなど教えていただけますか？ 一切ない
だからお前みたいな恥知らずはとっととこのスレから去れ Ruby on Rails で転職用ポートフォリオを作る際、
Heroku, AWS など本番環境がLinux なので、
Windows 10, WSL, Linux を使う
Linuxのローカル開発では、多言語バージョンマネージャーのanyenv, asdf または、Docker を使う。
リモート開発なら、Cloud 9 を使う
ここで、初心者向けの本ではLinuxではなく、
Windows環境用のMSYS2/MinGW を使うことが多い
一方、企業では、採用を選択した技術で判断するので、
MSYS2/MinGWを使うと、本番環境ではないので素人と判断される
同様に、Django, Laravel を使っても、
なぜRailsを使わなかったのか聞かれて、返答に困る
まあ、AWS機械学習の資格を持っているとか、採用企業を圧倒するだけの実力があれば別だけど VSのインストールが開発環境構築な時点で
dockerとか要らん人やん
そもそもdockerの使い道もわかってないはず
わかってたらこんな質問せんもんね podmanでXDG_RUNTIME_DIRが/run/user/0でどうのってエラー出るのってとりあえずenvを
XDG_RUNTIME_DIRが/run/user/1000に書き換えればいいの？
なんか無理やり感あるからどうなんだろって感じなんだけど Windows環境でPodmanDesktop入れるとDockerDesktopが起動しなくなるんだけど
デフォルトのwslディストリビューションが問題っぽい
これ共存の方法とかない？ レス数が950を超えています。1000を超えると書き込みができなくなります。
