Docker Part5
レス数が1000を超えています。これ以上書き込みはできません。
DockerはLinuxが持つコンテナ技術を使ったアプリケーション仮想化技術です。
アプリケーションを動かすために必要な各種ライブラリ等を一つのDockerイメージに
まとめることで、さまざまな環境へのデプロイが容易になります。
例えばWindowsやmacOSを使って開発・テストしたDockerイメージを
そのままクラウド上のLinuxの本番環境で使うことができます。
クラウド上の環境が仮想マシンであるため、Dockerは仮想マシンと併用して使うことが多いですが
仮想マシン技術とは無関係の技術です。実際Linux環境において仮想マシンは必須ではありません。
WindowsとmacOSでは仮想マシンを使いますが、これはOSがLinuxではないからです。
Dockerは主にアプリケーションを動かすために設計されているのでデータを保存するのには適していません。
データはDockerイメージの外部、ボリュームを使ってホスト環境に保存するかネットワーク通信で外部サーバーに保存します。
またDockerコンテナは一つのサービスを実行し、複数のサービスが必要な場合はdocker-composeやk8sなどを使って連携させます。
Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けています。
それはDockerの設計方針とあっていないからです。
Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します
動かすのに必要なもの全てがDockerイメージに含まれるので
インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります
Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
情報共有しましょう
http://www.docker.io/
前スレ Docker Part4
https://mao.5ch.net/test/read.cgi/linux/1597591176/
注意 Dockerを仮想マシンの代替として使いたいと考えてる人は、DockerではなくLXCを使いましょう
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/ Kubernetes 1.20からDockerが非推奨に!! 感染広げるXantheマルウェア、誤った構成のDockerサーバが拡散の原因に
https://www.itmedia.co.jp/enterprise/spv/2012/02/news118.html
わざわざ会員登録までして記事見たのに危機感煽るだけ煽って結局何が悪いのかすら書かないとか記者辞めちまえよ >>2
https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
tl;dr
For developers
Don't panic, Docker containers and images are still alive. It's not that it will change everything.
tl; dr 開発者向け 慌てる必要はありません。Dockerコンテナとイメージはまだ生きています。
それがすべてを変えるというわけではありません。 ほれみたことか
どんどんDockerがオワコンに向かっている
これからはPodmanだよ諸君 >>1
テンプレに間違いがあるね
コンテナ内部は複数のサービスにしてもよい
Gitlab公式コンテナが好例
そのほうが簡単に配布することができる Dockershimとやらが無くても動くように
docker側が対応しないのは何で？ //jaco.udcp.info/entry/2020/12/03/172843
何がこれからは Podman だよ
バカにも分かりやすい記事を持ってきてやったから読んで理解してくれ Dockerはオワコン
代替は今のところPodmanしかない もともと落ち目だった
デーモンとかswarmとか要らんし、レジストリのpull制限かかるし、これじゃ安心して使えないよ dockershimって単体でも使えんの？
Kubernetesとは別のリポジトリでメンテしていけば良くね？ Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ
https://jaco.udcp.info/entry/2020/12/03/172843
Dockerはより開発者向けにシフトする感じかな 発展途上の技術が最適化されていくだけって話だったのね
5chでだけ声の大きい人の言う事は一番あてにしちゃいかんな >>17
twitterで声の大きい人や
発表会（笑）だけで有名な人も同じ
当てにしちゃいかん 非推奨にも幅があるよ
ナルハヤで脱却して、って意味での非推奨
別に使うのは構わんけど、もっと良いモノあるよ？って意味での非推奨
Dockerは後者の意味での非推奨
なんたって、Podmanがあるからねぇ
天下の赤帽が、コマンド名にエイリアスを付けるぐらいだから、よっぽどだよ Podmanの名前出てたか？
もっと良いものはあるのが事実だとして、そこにPodmanの名前が
出てないなら、それは良いものじゃないってことだろう？
Podmanの名前出てないよな？ podmanとdockerの比較表を作ってくれたら試してもいいよ >>9
1の記載は本人の妄想と誤解が混ざり合ってるから気にしちゃいかん。
読んだ感じだと未だPart4以前から続く間違いが、未だわかってない様だね。
Part6が始まるまでにどんだけ間違いに気づくか見もの。 KubernetesはDockerのサポートはやめるけど
今後もDockerで作ったイメージは動くらしい
どういうこと？
KubernetesってそもそもDockerイメージを動かすことしかしないよね？ コンテナにも標準仕様があんだよ
それ満たしてればK8S的には何でもおｋなわけ
Dockerはそれを満たしてないからしょうがなくアダプタで無理やり動かしてた
でももう面倒になったからDocker切り捨てるわバイバイってこと 記事見る感じだとDocker自体がcontainerdのラッパーでしかないから
じゃあcontainerdで良くね？って話？
Dockerもう要らなくね？ 開発環境で使うという意見もあるがpodmanで十分だ
WindowsかMacだったら仕方なくdockerを使う WindowsならDockerはいらんな。
SSD換装できないMacは無駄にストレージ使う訳にもいかんから
消去法的にDockerって感じ。 >>16
この記事だと結局dockershimに非対応になるってことじゃね？ podmanがどうのこうのという話？
単に信じた君が馬鹿なだけじゃね？ >>24
> Dockerはそれを満たしてないからしょうがなくアダプタで無理やり動かしてた
え？でも非推奨になってもDockerイメージ動くんでしょ？ >>28
つまりdockershimは非推奨だけど
dockershimを使わなくてもDockerイメージは動くってこと？ Dockershimで検索したらこれが一番目に出てきたよｗ
Dockershim Deprecation FAQ
https://kubernetes.io/blog/2020/12/02/dockershim-faq/
本家は最初から「Dockershim」って言ってたのか？
（それとも反響が大きくて後から出した？） オーケストレーター使うならK8S
使わないならpodman
dockerは要らないね >>34
Kubernetesつかってないけど
「本番環境ではKubernetes使います。Dockerはサポートされてないので作り直してください。」
って言われたら嫌じゃん >>35
> オーケストレーター使うならK8S
K8Sだけじゃ何も動かない
せめてDockerイメージがないと・・・ >>36
Dockerイメージのフォーマットが変わるわけではない >>38
つまり今まで通り
Dockerで開発してDockerイメージを作って
それをDockerリポジトリにpushしていれば
それをkubernetesから使えるってこと？ >>39
そりゃそうじゃ
誰がDocker「イメージ」を廃止するとか言った？ docker imageは駄目っしょ。
それで作ったコンテナはdockershimに手伝ってもらわないと動かないだろうし
それは来年末に廃止するよ、って言ってるんだし。
代わりにBuildah使ってビルドしてね！って言ってるし。 まあmicrok8sで開発してたらDockerきえてCRIOになったし
そうなるだろうなとは思ったけど。
イメージのビルドはk8sからはやりづらく感じる。
クラスタ用の定義ファイルとアプリ用の設計書が一緒くたになりそうな > イメージのビルドはk8sからはやりづらく感じる。
k8sからイメージをビルドするってどういう事？
k8sからどうやってイメージをビルドするの？pullするだけでしょ？ >>41
君みたいに解説記事を読まずに騒ぐ人が多いからじゃない？ だからなんで昨日からの話の流れで podman が出てくるんだよ、いい加減にしろよボケ dockerがオワコンだからpodmanに移行しようって話だよ ↑は何をいきり立ってんの？
5chをDockerのサポート掲示板か何かと勘違いでもしてるのかな？ お前こそpodmanのスレは別にあるんだしそこ行ったら？ >>54
俺はpodmanに興味はない。
俺が焦点にしているのはお前だ。
スレチと言うならk8sからそもそもスレチだし、それなら>>2から
全部駄目なんだが？なんでpodmanにだけ反応するの？ 解説読めば理解できるのに的外れな質問をしている人のほうがサポート掲示板と勘違いしているんじゃないですかね？ ちゃんと理解したならdockerがオワコンとわかるはずだろう
dockerはいま急速に切り捨てられようとしてる
今回の事件だけじゃねえんだ >>56
悪いけど的外れな質問にも興味はない。
俺はDocker板で突然k8sの話題が始まった事に
ずっと違和感を持っていたけど、別にツッコミを入れたりはしない。
で>>50-52は何でそこをスルーするのにpodmanに「だけ」反応するの？って話。 >>58
podman は今回の件に関係ないからだけど？ 知識が足りないからdocker = K8Sのような勘違いをしてるのかも
しっかり学ばずになんとなくでdockerを使ってる若手に多い podmanはなんつーかもとから土俵の上にないっていうか
たぶん非推奨っていわれてもこんなに騒ぎにはならないだろうな >>62
CRI-O に言及するついでに書いてあるだけだろ...
記載があるから関係があるという考え方はやめたほうがいいよ >>63
k8sをちゃんと使ってDockerとの違いにやりづらさを感じた人なら
その一行で「なるほどな」と感じるはずだが？ >>64
docker との違いにやりづらさとあるが、主語がないので何と比較してやりづらさがあると言いたいのか分からない
> Dockerの代替ツールとしてはローカル用ランタイムのPodman、コンテナビルダーのBuildah、そしてCRIランタイムのCRI-Oをそれぞれ提供しています。
この一行に関してはそうだねとは思っても、なるほどと思える要素はないな >>65
それは君が馬鹿だから。
資料を読めばなぜやりづらいと感じるのかもわかる。 >>66
これまで k8s -> dockershim -> docker api -> containerd となっていたのを k8s -> containerd にするっていう話なんだけど、
これのどこに podman が関連するか教えてくれない？ >>67
docker要らなくなるな
じゃあpodmanでいいか >>67
その資料にはそうは書いてないな。
今まで：
k8s->dockershim->Dockerで動いていたけど、dockershimは廃止するよ
これから：
でも実はDockerは内部でcontainerdとして動いているから廃止後はk8s->containerdになるから安心だよ。
と言っていて、その背景の情報としてDockerはk8sとネットワークとかVolumeとかの機能が
被っていて邪魔、とかCRIとしてコンテナを動かす技術はdockershimのほかにCRIOやcontaienrd
があって、CRIOの人達は早くからpodman押してるよ、それは何故かと言うとk8sが求めていない余計な
機能は実装していないからだよ、と言っている。
だからこの文脈で>>51といえばそれが正しくて、>>50はお前何いってんの？としか思わない。
少なくとも>>50という感想には絶対にならない。 dockerを開発用に使ってる人
→今まで通り使い続けてOK。k8s上でdockerで作成されたコンテナは実行可能であり続ける。(コンテナのフォーマットは標準化されていて、dockerもそれに従っているから）
k8sのコンテナランタイムとしてdockerを使っている人
→cri-oかcontainerdに移行してください。
猶予は1年
って認識だけどこれでいいんだよね？ >>69
まず、前半部分(安心だよ。まで)って何が言いたいんだい？
私が書いた内容を君の言葉で言い直しただけ？
だからこの文脈でって言うけど、話を飛ばしすぎなんだよなぁ
私は最初から昨日の話の流れで podman が出てくるのはおかしいでしょと言ってるだけなんだけど
dockershim が非推奨になります、だから podman に移行しましょうなんて話が公式からありましたか？ https://qiita.com/kenkono/items/6221ad12670d1ae8b1dd
これのDockerfileの最後の行のADD . /code/には何の意味がありますか？
その手前でADD /code/してる気がするのですが
なぜ再度ADDする必要があるのでしょうか 個々のDockerfileの意味とか流石に作者に聞けとしか
よく使われるテクニックとかならわかるが dockerユーザーは初心者も多いからこんなもんでしょ
podmanは玄人ユーザーが多いからみんな「わかってる」けど >>74
なるほど
ためしに最後のADD . /code/の行を消してもbuildできてしまったので
どのような目的があったのだろうと疑問だったのですが
まだいまいちピンときていませんがありがとうございました >>71
もういいよ。
お前の脳味噌は相変わらず腐ってる。 >>78
最後のADD削ったら必要なものが入らないだろｗ
Dockerは上から一行ずつビルドしてるんだから
「最後の一行」を削っていって最終的に最初の一行だけになっても全部ビルドできる
別にこれでもビルドは正しく出来るんだよ
WORKDIR /code
ADD . /code/
RUN pip install -r requirements.txt
ただしこれだと、.（カレントディレクトリ）の内容が変わったときに
pip install -r requirements.txt という時間がかかる
パッケージのインストールを何度もすることになる
一般的に requirements.txt の内容が変わることは少なく
.（カレントディレクトリ）= ソースコードは変化しやすいので
記事の順番でやるとビルドに時間がかからなくなる
これはDockerを本来の目的＝自社開発アプリのデプロイとして
使う場合によく使われるテクニック
開発中に何度もソースコードを修正してビルドするからね
他人が作ったアプリをただビルドするだけの人だとこうする理由がわからない >>80
＞上から一行ずつビルドしてるんだから
＞ただしこれだと、.（カレントディレクトリ）の内容が変わったときに
なるほど まだわからない部分はたくさんありますが
簡単な構成でdocker buildで試し比べてみました
stepそれぞれに（上から順々に依存している？）１２文字のハッシュ値があって
最終stepの行がimage idになっているのをみてくしっくりきた感じがしました
ありがとうございました Mirantis to take over support of Kubernetes dockershim
https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
dockershimはKubernetesの外でメンテ継続するってよ
いずれにせよ独自のKubernetesディストリビューションを自分で作ってるユーザーにしか関係ない話だよねこれ
あるいはKubernetesのWorker Node上でdocker in docker使ってたりとかすれば関係あるけど そりゃ短絡的すぎる
開発ツールとしてのDockerは全く金になってないわけで、実行環境として使われなくなればDocker社は潰れる
まあいずれにせよバイアウトは時間の問題だろうけど、変なところに買われないといいね
MSあたりなら万々歳か ほんとそれだよな
dockershimっていう技術的1要素についてしか見れてない人はちと掘り下げが浅い dockerで作ったのって所有者がrootになってるけど
別にそのままでいいよね ALLOWED_HOSTSをコマンドから引数から書き換えられたらいいのに。。
せっかくdockerで自動で構築できてもそこだけ手動なのか
シェル書くしかないか allowed_hosts=aaa docker run ...
でいいじゃん >>90
settings.pyのALLOWED_HOSTSを切り替えてそれでやってみたけどだめだった Djangoをディージャンゴって音読してしまう癖を矯正するコツを思いついた
限りなくデをジに近づけてデェンゴって発音する ワンピース ねじまき島の冒険(同時収録:ジャンゴのダンスカーニバル)でも見ればいいんじゃないですかね？ DockerHubってイメージじゃなくてDockerfileとかダウンロード出来ないの？
今使ってるイメージ微妙に不便なとこあるからPRしようと思ってるんだけどやり方がわからない… どっかにかいてあるだろ
Dockerfileは必須じゃないから
ないこともあるが >>92
いたずらハゲたかジャンゴってスーパーマリオ64にあったよな
>>94
GitHubへのリンクが無くて
探しても分からなかったら諦める >>84
こういうコメントって何なんだ？
薄気味悪い。 Docker 始めたばかりでよくわからないんだけど
docker-compose で複数プロジェクト起動したりするときってみんなどうしてるの？
数少なかったらコンソールから手入力でも行けそうだけど
プロジェクトとかオプションとか多くなるとしんどいですよね
シェルスクリプトとかでがんばるのかな >>99
複数プロジェクトって？
それぞれのプロジェクト？が連携してるのなら
一つのdocker-compose.ymlでやるけど プロジェクトは公式の単語だからドキュメント見てこい >>103
たとえば WordPress と BBS を運用するサーバがあったとして、
両者は連携させないのでそれぞれに docker-compose.yml を書くとするじゃないですか
それでフロントエンドに httpd を置いて、リバースプロキシで振り分けるとして
これも docker-compose.yml を書いて運用するとプロジェクトが3つになります
関連はするので全部まとめて一つにするのが正義かもしれませんが
密に関連するのと比較的疎になってる部分があるのをごちゃまぜにするのがはたしてよいのかどうか
で、こういう場合は大抵どうしてるのかなと思ったのです >>105
もう答え出てるよ？構成管理ツールを使えばいい
Dockerだからといって、急に昔ながらのやり方が変るわけじゃない
K8Sを使わないなら、Dockerなんてただのパッケージングツールでしかない
ビルドして、サーバーにリリースして、起動する
ほら、いつものやつだろ
だったら、いつものやつを使えばいい >>106
ありがとうございます
構成管理ツールを利用している人も多いということですね
検討してみます
K8S はクラスターとかで使うので 1 サーバで運用の場合は用途が違うのかと思ってました
こちらも勉強します 構成管理ツールはサービスを起動するための「構成」を作るだけなので
「サービス起動」自体は自分で書かないといけない
Dockerだからと身構える必要はない
PCを起動した時にサービスを自動起動するのはなにか？
今だとsystemdがよく使われている
systemdを使ってサービスを自動起動させる
その中身がdocker-composeになるだけの話 dockerコンテナ単体なら--restart=alwaysで出来るはずだから
docker-composeでもrestartオプションでなんとかなるんじゃね？ オレオレスクリプトよりは良いんじゃないかな
systemdの規則に則って設定が書かれるから引き継ぎしやすいだろう DockerfileでRUN django-admin startproject mysite .するとエラーはでないけど何も作成されない
docker-compose runでやるとなぜか成功する linuxでdocker使うとvolumeでroot以外書き込みできなくなるのにハマるから面倒くさい
windowsで使ったときは天国だった 「イラストでわかるDockerとKubernetes」は完全に良書 - Cloud Penguins
https://b.hatena.ne.jp/entry/s/jaco.udcp.info/entry/2020/12/08/215058
↑
ブクマがすごい増えてるがこのスレの先輩方の意見も聞かせてください ちょろっと立ち読みしたけど概念解説本って感じ
手を動かす類のものではない M1 Mac買ったんだけど、プレビュー版のメールが来ない x86_64のイメージもいい感じにエミュレーションしてくれないのか M1のdockerはarmもx86_64も動くよ
x86_64はqemuかなにかのCPUエミュレーションを使うらしいから相当遅いようだけど
ttps://twitter.com/ogrisel/status/1339508321078939650
docker run --platform linux/amd64
のようにすればx86_64のイメージが動くらしい
ttps://twitter.com/akhenakh/status/1339582893375418379
https://twitter.com/5chan_nel (5ch newer account) docker-compose up -dでサーバを立ち上げたままストを再起動すると
WIndowsだと自動的に立ち上がりませんがUbuntuだと自動的に立ち上がりました。
この挙動の違いはなんか設定があるのでしょうか？ >>126
＞docker run --platform linux/amd64
＞のようにすればx86_64のイメージが動くらしい
これってターミナルをロゼッタで
開くのが必要なやつかな？
https://i.imgur.com/XrDGxYc.jpg djangoのsqliteで日付ソートしたいとき
filterで__range=(start_date, end_date)ってやれば取得できたけど
この日付以降を取得したい、この日付までを取得したい
って場合はどうするの？？
end_dateのとこを最新のにするとか
start_dateのとこを0年？にするとかで対応できそうだけど
別の方法はないのだろうか Windows 10 Home 版に、WSL2, Docker を入れた
OS の連続アップデートに、3時間掛かった。
CPU-i3, 8GB メモリを、CPU・電力エコモードで使っているから、コンパイルが遅いのかも
その後、WSL1 から、WSL2への変更。
Windows 10 Home用のDockerのインストール自体は、簡単だった
これで、Windows10 プロ版じゃなくても、Dockerを使える。
Kubernetes も入っていた 最新OSイメージをUSBに焼いてインスコすればアプデすぐ終わるよww とりあえず触ってみたいだけじゃないかな？
Linux用の他の物理PCが無いとか >>133
これって、普段Win使っててもDocker
使うときは別のLinux入ってるPC使わないの？っていう質問なの？
それとも、Docker使うのに何でLinuxじゃなくて、Win10home入れてるの？
ていうこと？ >>135
後者
最初から全部Linuxだけでよかないか？ ふだん使いにはWindowsのがいいから。
そんなんやからLinuxが普及しないんや。。。 >>1
windowsでffmpegのビルド環境をDockerで構築するのはベターな使い方では無いって感じなんですかね >>138
はい。ベターではありません。
Dockerはffmpegを作るものです。
その仮定でffmpegのビルド環境を作ることになるかもしれませんが
最終的に作るのはffmpegです。ビルド環境は途中の状態に過ぎません。
単体で配布できる動くffmpegバイナリがあれば嬉しいですよね？
Dockerはそれを実現するものです。 exeで配布したかったらLinux立ち上げるかwslでやれって事だな playwithdocker
プログラムは動くけどウェブサーバーだけ５０３になる？
コードミスったのかとおもったけど前に成功して改変してないやつがダメだし 今やったら復活してた
playwithdockerみたいな感じで試せるとこないかな
有料でも docker-composeでweb制作をしたいと思うのですが、
javascriptのeslintはホストとコンテナどっちにインストールするものなんでしょうか？ ホストのファイルシステムをマウントして使うとファイルシステムの通知機能は使えないよね
nodeをコンテナから使うとホットリロードはポーリングでしか出来ない
Unisonみたいの使えばファイルシステムはLinuxのになるから
一応いけると思うけど・・・ 対応していれば使える
Windowsならできるやろ なんでWindowsは調べられてmacは調べられねーんだよｗ Docker Desktop for Windowsの3.0にアップデートしても大丈夫？
謎の不具合に遭遇したりしない？
昔、家でWSL2バックエンドで使ってたらアプデ後に起動できなくなった事があった
大したデータを入れてないのでリセットしたが、あんまり信用出来ないなと思った
Mac版は自分では使ってないが、メジャーアップデート後から奇妙な不具合が多数報告されてるのは知ってる
一応安定版リリースじゃないのか
Mac版は一応ダウングレード出来るようだ
会社ではWindowsでHyper-Vバックエンド Docker Desktop for Windowsの3.0でもHyper-Vバックエンド対応してるだろ？
WSL2バックエンドは、たぶん俺しか困らないだろうなってバグ
（カーネルの古いAPIの削除による仕様？）があって切り替えれないでいる
バグの内容を言うと、困る人は俺ぐらいだろうなって特定されかねないのでここでは言えないｗ >>155
カーネルAPIの互換性については弊社でも度々問題になりました。
古いディストリイメージを使う場合はHyper-Vバックエンドが安定しますね。 podmanもっと使ってくれよ
このままrocktみたいに消えるのやだよ 消えないのと普及しないのは違う
もっとRedHatが開発した独自ツールが普及するといいのに dockerエイリアスはpodmanなので自動的に広まるよ 本番クラスタはマネージドK8S
開発環境はDockerCompose
Podmanは…オンプレシングルノード本番専用？ RedHatにベンダーロックインされてる人が使うｗ
RedHatがDockerを切り捨てたから
それに従わないといけないのだ 商用はRedhatだからpodmanに従ったほうがよさそうだね あとで移行すればいいよ
普及してから（そして大抵の代替技術は普及しないｗ） PodmanよりDockerRootlessのほうがええわな docker-composeはConfigMapに相当する仕組みが無いから不便ですね Wasmerも本格的に動き始めた
いよいよDockerの居場所がなくなってきた rocktの登場で居場所はとうの昔になくなってたはずだが？ 自作ソフトのdockerイメージを作って配布しようとしているんですが、設定ファイルの類はどうするのが普通ですかね？
1. 配置するディレクトリを決めておいて使用する側でmountしてもらう
2. volumeを作ってそこに置いてもらう
3. デフォルトの設定ファイルをイメージ内に配置して、使用する側で上書きしてもらう
4. その他
ケースバイケースの場合は判断ポイントなどを教えてください。 設定の構文が複雑ならファイルをサポート
そうでないならコマンドライン引数、環境変数、ファイルを全部サポート >>175
コマンドラインの引数や環境変数は？
Amazon ECSはこれらの方法でしか設定を入れられないから
環境変数で設定出来た方が便利
ECSの機能を使わず、ホスト上にファイルを配置しておけば設定ファイルも使えるが、わりと面倒くさい
k8sだとConfigMap、Secretの内容をファイルとしてマウント出来たりして便利だった
パスワードのような機密情報はコマンドライン引数にするとまる見えになるから
設定ファイルや環境変数にすべき
Traefikだったら複数の設定方式に対応してて
・コマンドラインの引数
・設定ファイル（場所は固定っぽい）
・環境変数
どれも自由に選んで使えた
設定ファイルは変更を検知して自動的に反映する設定も可能なので
別途、同じディレクトリをマウントしたサイドカーコンテナを作って
独自のConfigProvider作れたりとか
夢が広がりんぐ >>176
>>177
動かそうとしているアプリケーションは設定ファイルのみを使用しますので、それを実行する側の
ユーザー環境で差し替えさせるにはどういうやり方をすればいいかという質問でした。
実行環境は社内のユーザーにdockerを用意してもらう前提で、amazon等のcloudの利用は想定していません。
1.,のようにホストのディレクトリをマウントさせるのが普通ですかね？ >>178
差し替える方法はユーザーが自分達の環境に合わせて考えること、なのでイメージ提供者はあまり考えなくていい
どこに、どんな形式のファイルを置けばいいのか、だけを仕様として明確化すること >>179
ありがとうございます。それはつまり、
>3. デフォルトの設定ファイルをイメージ内に配置して、使用する側で上書きしてもらう
これでいいってことですかね？ 設定ファイルの書き換えをスクリプトで行いたいユーザーのために、エントリーポイントにフックを仕掛けるとより親切 docker楽でいいね
docker-composeをアップすると自動でやってくれるレンタルサーバとかクラウドサーバないでっか？ Windows、Macはまだdockerが主流なんだっけ？ K8SがデファクトスタンダードだからDCでの運用ノウハウを探すの大変だよ
素直にK8Sを勉強したほううがいい
大変なのは最初だけ 1ノードしかない場合のそのへんの得失ってどうなんだろう。
サーバー1台だとオーバースペックというか無駄に複雑になるだけにも思うけど。 kubernetesは色々運用管理に必要なものが揃ってて便利だが
使わないならオーバーキルな気はする
k3sは知らんが、本家のKubernetesは重過ぎ
使うなら最初はマネージドで
コントローラーに追加費用要らない所も多い
GKEは高可用性無しなら1つだけ無料
AKSやLinodeは無料
DigitalOceanは無料だが日本のデータセンターが無い
EKSは未だに有料 最初はっていうかずっとマネージドでいいと思う
オンプレミスでK8S管理は辛いよ Kubernetesは起動するだけでメモリ1GBを消費する
つまり最小構成のVMではかろうじて動くが
そのVMを実用的に使うことはできない
最初からそれだけのメモリをKubernetesに
与えてもいいぐらいの規模が前提となってる k8sはYAMLの記述量が多過ぎなのも嫌われる一因
helmもYAMLとGoTemplateと言うやばい組み合わせのせいで汚い
kustomizeもなんかアレ
tankaとかkapitanならjsonnetで書ける
YAMLをテンプレートでやるより100倍いい
https://github.com/grafana/tanka
https://github.com/deepmind/kapitan docker-composeが一番だ
k8sよりswarmのほうが完成度が高いのになぜ使わないんだろう？ 複雑怪奇なYAMLベースのDSLを作らないでほしいね .hcl自体はわかりやすくても
それをもとに作られたDSLがなぁ ところで質問。
docker-compose のサービスをいきなり docker run 相当で起動するんじゃなくて
docker create -> docker cp -> docker start みたいなことってできないのかな？
あるいは swarm や k8s だとどうだろう。 なるほど。ただ、podmanであってもdockerfileの置き換えには至ってない雰囲気。
軽くしようとすると途端に難易度が高くなるツールだ Buildahというのがあるようだ。
どの程度の性能か謎ではあるが……。 >>201
docker-composeなら
ファイルはボリュームでマウントすれば良いし
イメージがshとかbashでのcommand実行に対応してれば何らかの初期化処理も可能だ
scratchイメージでsh入ってなかったら無理だが Docker BuildKit: faster builds, new features, and now it’s stable
https://pythonspeed.com/articles/docker-buildkit/ 直接そういうことができる機能は無いから別の手を考えないとならないということね。ありがとう。 docker-composeで独自モジュールをpipでいストールしたけど
その独自モジュールのソースを微妙に変更して、docker-composeやり直しても更新してくれない。。
docker-compose down --rmi all --volumes --remove-orphans
してもコンテナもイメージも残ったままなのがたぶん原因なんだろうけど・・
手動でポチポチ消すしかないのかなぁ docker-compose build --no-cache >>208
ちょっとだけ構築速度おそくなったけどできた！㌧クス！ no cacheオプションだから遅くなるのは当然でしょ メモ
docker image prune
で消えねえと思ったら-aオプションいるのね・・
docker image prune -a
消したくないやつは稼働させたままやったら
稼働してないやつだけ消えてめちゃくちゃ捗った
（稼働中のやつには無影響なのかはわからないけど） できれば、pipでインストールする自作ライブラリの訂正部分だけ更新できるようにしたいけど
--no-cacheするかイメージもコンテナも全部消してから再ビルドしないと適用してくれない・・
非公開gitからクローン → python setup.py sdist → pip install ○○
みたいにDockerファイルのRUNでやってるのがだめなのかな >>212
自作ライブラリをインストールした以降のイメージだけを削除したら。 >>1
>Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けて
具体的に言うと？ 面倒なだけで問題はないよね。
面倒という指標だとk8sは更に最初が面倒なわけで dockerわかってないのにわかった風のおじさんが、僕には困難です、と書いただけだから気にせんでええ
次スレまでいったら、テンプレから削除していいよ >>216
複数のサービスを起動する場合、systemdが一般に使われるが
systemdを使うのは大変
https://stackoverflow.com/questions/51979553/is-it-recommended-to-run-systemd-inside-docker-container
可能な限り、コンテナ内のsystemdは避けることをお勧めします。
Systemdは、ファイルシステムをマウントし、いくつかのカーネルパラメータを制御し、
プロセス出力をキャプチャするための独自の内部システムを持ち、システムスワップスペースを構成し、
巨大なページとPOSIXメッセージキューを構成し、プロセス間メッセージバスを開始し、
端末ごとのログインプロンプトを開始し、システムサービスのスワス。
これらの多くは、Dockerがあなたのために行うことです。
その他は、Dockerがデフォルトで防止するシステムレベルのコントロールです（正当な理由があります）。
通常、コンテナに1つのことを実行させたい場合があります。これには、複数の調整プロセスが必要になる場合がありますが、
通常、systemdがプロセスマネージャーを提供する以外のことを実行したくない場合があります。
systemdは非常に多くのホストレベルのパラメーターを変更するため--privileged、
Dockerの分離を破るような実行が必要になることがよくありますが、これは通常は悪い考えです。
質問で言うように、通常、コンテナーごとに1つの「ピース」を実行するのが最適と見なされます。
これができない場合は、DockerとUnixの両方の哲学において、
initプロセスに必要な最小限の処理を実行するsupervisordのような軽量プロセスマネージャーの方が適しています。 >>216
これとか読むといいかも。公式がVMじゃないと言ってる。
Containers are not VMs
https://www.docker.com/blog/containers-are-not-vms/
> しかし、これを言っても、VMに関する現在の考えやプロセスを適応させ、
> コンテナーに適用しようとしています。
>
> 「コンテナをバックアップするにはどうすればよいですか？」
> 「実行中のコンテナのパッチ管理戦略は何ですか？」
> 「アプリケーションサーバーはどこで実行されますか？」
>
> 私にとって、Dockerは仮想化テクノロジーではなく、アプリケーション配信テクノロジーで
> あることに気付いたとき、電球の瞬間が訪れました。
これとかも
So, You’re Saying Docker Isn’t A Virtual Machine???
https://derickbailey.com/2016/08/29/so-youre-saying-docker-isnt-a-virtual-machine/
A Docker container is not a virtual machine.
A Docker container is application virtualization. 複数のサービスを実行することは可能だが、推奨しないと書いてある。
そしてこの記事に書いてある複数のサービスを実行する方法を見ればわかるように
仮想マシンのように気軽にはできずコードを書く必要がある
Run multiple services in a container
https://docs.docker.com/config/containers/multi-service_container/
コンテナの主な実行プロセスは、ENTRYPOINTおよび/またはCMDの最後ですDockerfile。
一般に、コンテナごとに1つのサービスを使用して、関心のある領域を分離することをお勧めします。
そのサービスは複数のプロセスに分岐する可能性があります（たとえば、Apache Webサーバーが
複数のワーカープロセスを開始します）。複数のプロセスがあっても問題ありませんが、
Dockerを最大限に活用するには、1つのコンテナーがアプリケーション全体の複数の
側面を担当することを避けてください。ユーザー定義のネットワークと共有ボリュームを使用して、
複数のコンテナーを接続できます。 そもそもコンテナを仮想マシンの代替として使うケースはほぼないだろ。
1に書くような話ではないな > Handling such processes this way is superior to using a full-fledged
> init process such as sysvinit, upstart, or systemd to handle process lifecycle within your container.
sysvinit, upstart, or systemd を使うよりも
自分でコンテナのメインプロセスを作ったほうがいい たとえばnginxとphp-fpmを別コンテナにする気もないから自作シェルエントリポイントにしてる
俺はやらないがsupervisordで制御してもいいだろう
systemdまで入れるならlxcかkvmにするけど つまりは仮想マシンであれば標準でsystemdなどが起動してるから
サービスを起動させるにはパッケージインストールして
ちょっと設定ファイルを書き換える程度の簡単な作業だが
Dockerでやる場合、systemdなどを使わずに
自分でスクリプト書いて起動と停止を制御しなきゃいかんのよ（Docker推奨の方法）
頑張ればsystemdを動かすことも出来るが、そのために --privileged オプションが
必要になるかもしれないし、その他の調整が必要になるかもしれない
何が必要かは起動するサービスによって違うので試行錯誤が必要になる
だからDockerはsystemdを使わずに自作スクリプトで制御することを推奨してる
systemdを使うぐらいならより軽量のsupervisordを使うほうがいい
もちろんパッケージインストールして終わりではなく
自分で設定ファイルを書く必要がある 😫マルチプロセスコンテナ否定派
・1つのサービスのために多数のコンテナイメージをリリース
・イメージ使用者に面倒くさいymlを書かせる
🤗マルチプロセスコンテナ肯定派
・1つのサービスのために1つのコンテナイメージをリリース
・Supervisor等の設定を開発側が書いて出荷するのでイメージ使用者はdocker runするだけ 仮想マシンみたいなことしたかったらLXCでよくね？
しらんけど ・イメージ使用者に面倒くさいymlを書かせる
別に良くね？ >>233
仮想マシンみたいなことがしたいならシステムコンテナでいいと思うよ
単にマルチプロセスってだけならアプリケーションコンテナのほうがいい 「プロセス」「サービス」を意図的に混同して相手を貶める >>234
良くない
負担を減らせるなら減らしたほうがいい
ホスピタリティの精神だよ
セルフサービスで全部やってねなんてのは二流だ
もちろん分散型のイメージを提供するなと言ってるわけじゃない
分散型をオプションとしてサポートするのも良い事だ マルチプロセス派は配布して終わり！じゃなくてその後の運用まで考えてるのか？ >>238
運用もシングルコンテナのほうが簡単でしょ >>240
1つの物管理するのと多数の物を管理するのじゃ前者のほうがかんたんだ
常識的に考えればいい 複数サービスのログ管理はどうする？
まさかファイル出力にしてlogrotatedとかも突っ込むの？
それかコンテナ自体のログを複数のサービスからのログが流れてる状態にするの？
ログ管理のSaaSへログの集約がしたくなったらどうする？
エージェントもコンテナに突っ込むのか？
複数コンテナで
ログは全部コンテナのログにしておけば
dockerのログだけローテーションすれば済むじゃん
ロギングドライバ変えたり
ログ転送のエージェントは別コンテナにしたりできる 個別に更新するのだから、バラバラの方が管理しやすい。負荷分散も容易。
一箇所にまとめるのは滅多に変えない時だけね。 そんなもんそれぞれのプロセスがstderrに流すだけ
あとはホスト側でどうにでも 纏めた方が楽という人は、k8sのメリット関連の文献を読んだほうが良い。基本的に個人でも同じ。
依存関係が原因のレガシー化を防ぐには、細かく分けて疎結合というのがマイクロサービスの基本。 supervisord管理下のプロセスの死活監視やリソース使用の監視はどうするんだ？
同じイメージに監視ツールのエージェント突っ込むのか？
もうめちゃめちゃ複雑だし、イメージに汎用性がない
複数アプリがあったら全部これやれってアプデも対応しろって言うの？面倒過ぎ
普通にマルチコンテナで動いてたら
Dockerコンテナが動いてるかどうかや、コンテナのCPU、メモリ使用量などの監視で済む
監視ツール変えたくなってもアプリのイメージをいじる必要がない
アプリ固有のメトリクスを記録監視するならアプリイメージに対応必要だが、
これらの基本的なメトリクスを取りたいだけなら対応不要 >>244
ホスト側！？
結局分けるんじゃん
じゃあsupervisordもやめたら良くね？ >>243
実は他者製のクラスタを個別に更新することは少ない >>245
k8sは大規模すぎるので導入障壁が大きい
1コンテナシステムは小規模から手軽に開始できる >>245
なんでもかんでもバラす必要性はない
Spotifyの事例にもあるようにミクロサービスからモジュラーモノリスに回帰した大規模サービスもある >>246
昔からやってる事をやるだけ
開発側にばノウハウが大量にあるのでなにも苦にならない
重要なことは利用者側が楽になること 弊社の勤怠管理システムはIE限定です！
一箇所にまとめるとこうになる。
まあ、慣れてるからそれが良いという人はご自由にどうぞかな >>252
>開発側にばノウハウが大量にあるのでなにも苦にならない
よくわかんない >>251
Spotifyにsupervisord最強おじさんはいない >>247
supervisord使うなんて一言も言ってないけど
コンテナ別にログ分けるのはホスト側のrsyslogdで十分 >>255
まとめるとレガシー化しやすいってこと。 1コンテナマルチプロセスにしろってsupervisordにしろってことだろ
そんな事やったらサービス単位で更新できないし、
supervisordの面倒見るのもいやだな
Docker自体がある意味supervisordみたいな物だから
supervisord in supervisordするって事じゃん？ 「プロセス」「サービス」を意図的に混同して話をややこしくする
nginxとphp-fpmを別コンテナにするメリットがあるのかね >>262
まあマルチプロセスなベースイメージをそうと知らないまま使っている阿呆も中にはいるだろうね バカには疎結合なんか、分からんから、ほっとけほっとけって >>261
オーケストレーションの手間暇を利用者側に押し付けるか、開発側でやってあげるかの違い
小規模のスタートアップなら全部開発側に丸投げしてdocker runするだけのほうがかんたんだ >>265
疎結合と一言で言っても色々ある
ミクロサービスは疎結合の代表だが
別にミクロサービスじゃなきゃ疎結合できないわけじゃない
さっきも言ったように
サービスとしてはモノリスでもコードレベルで高度にモジュール化することで疎結合を達成するモジュラーモノリスのような考え方もある
コンテナは1つでも内部のサービスが疎結合ならなんの問題もないのだ で、この1コンテナ、マルチプロセス(サービス)で成功してる代表的なコンテナがGitLabね
薄っぺらい表面的な知識しかない連中と違って、流石にGitLabのエンジニア達は深く理解してる
杓子定規にコンテナを分ける必要はない、背景が不明な不特定多数に配布するなら、むしろバンドルしたほうがいい、と理解してる GitLabはセルフホスティング対応が大前提だからそうなってるんだよ
シングルインスタンスなSaaSとは別次元の話 つまり利用者側からは1コンテナのほうがいいってことだ 基本は1コンテナなんだよ
ちゃんと利用者のことを考えてるならな
で厳しい要件満たすために、分散管理したい連中のために、いちおうバラ売りコンテナも用意しとく
それがベストプラクティス
さいしょっから分散管理のみサポートします、なあんて、怠惰もいいとこだ それはご苦労なこった
俺は怠惰だからメインのコンテナ以外はありあわせのイメージ使うぜ 自社以外に誰も求めてないマイナーサービスは最初からバラ売りでもいい 複数のサービスを一つのコンテナにまとめたほうがいいって言ってるやつは
複数のサービスが一つのコンテナになってるから
"使うのが楽"って言ってるんだよ。
作るのが大変の否定になってない
>>1は作るのが大変と言っている
> Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けています。
Dockerを使ってると言いつつ、自分でDockerfileもyamlも書かずに
ただ誰かが作ったものを使うだけのやつは、Dockerを使ってるとは言えない
んで、使ってるだけのやつが、使うのが楽と言ってる
複数のサービスを一つのコンテナに入れるのがどれだけ大変かわかってない
だって自分で作ってないんだもの いやいや、作るのもめちゃくちゃ簡単だぞ？
Supervisorとか使うだけ
Dockerfileも既存のchefなんかが、殆どそのまま使える コンテナを分けないことで、お互いのサービスの提供するコマンドラインツールを使いやすくなるのも、便利だな
ある古いサービスAの、管理者用のコマンドラインがあるんだが、、、
これはサービスAをインストールしたマシンで、ローカル実行する必要があった
もちろん、RPCなどという気の利いたものは、ない
開発者からすると、SSHがあればいいでしょ？みたいな気持ちだったんだろうな
そして、サービスBからこのコマンドラインを実行したい、と、なったわけだ
もし、サービスAとサービスBのコンテナを、分けてしまったら
サービスBから、このコマンドラインを実行するのは、普通の方法では、不可能だ
docker.sockをマウントして、サービスBコンテナからdocker execするか、、、
サービスAを拡張してRPAを追加しなきゃならない
あるいは、サービスAを、マルチサービス、にして、SSHを追加するか、、、
1コンテナだったら簡単なのに！ データベースは既存のサーバーが使えたほうが便利と思うけど
AWSのRDSとか使わせろ >>276
> いやいや、作るのもめちゃくちゃ簡単だぞ？
> Supervisorとか使うだけ
使うだけじゃなくて設定ファイルとか書かないと駄目だろ
ログをどうするかとかさ、永続的なファイルをどうするかとかさ > Dockerfileも既存のchefなんかが、殆どそのまま使える
chefを使うってアホじゃないか
Docker使う意味がなくなってる このように、1サービス1コンテナの精神で細かく分離すると
サービス同士が疎結合になり、一見すると良いように思える
しかし、疎結合である、ということは、サービス間の連携のオーバーヘッドが増える、ということだ
サービスはRPCを実装しなければならず、開発者は疲弊する
サービスメッシュの管理コストは増大し、運用者は疲弊する
これはミクロサービスの功罪と同じことだが、なんでもかんでも、小さく分けて、疎にするのが、常に正解なわけじゃない
全てはトレードオフなのだ！
たしか、マーティンファウラーだったと思うが
彼曰く、最初からミクロサービス的な思想に傾倒した案件は、失敗することが多い、らしい
最初はモノリスのほうが、うまく行くのだ
システムが、モノリスでは到底手に負えないほど、巨大化してから初めて、分割することを考えれば、よろしい >>283
作るのが大変だって話をしてる
出来るできないの話ではない >>281
あるぞ
GitLab公式コンテナはChefで動いてる >>287
apt-getでインストールするだけ vs 設定ファイルを自分で書く >>286
> GitLab公式コンテナはChefで動いてる
それを同じことをお前が作るのは大変だって話をしてる supervisordの方が面倒くさい
docker-composeの方が楽 >>290
大変じゃないけど？
もちろんGitLabほどの製品を作るのは無理だろうけどChefでコンテナを作るのは誰だってできる >>293
そりゃ、手間を利用者側に、オシツケテル、からでしょ docker-compose psしたらsupervisordが生きてたらupと表示されるが
設定にミスがあった場合や問題が起きた場合もsupervisordさえ生きてたらupと出る
判定するにはログやsupervisordのあるコンテナ内でコマンド実行が必要
どこが優しいねん >>288
A container’s main running process is the ENTRYPOINT and/or CMD at the end of the Dockerfile.
It is generally recommended that you separate areas of concern by using one service per container.
That service may fork into multiple processes (for example, Apache web server starts multiple worker processes). It’s ok to have multiple processes, but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application.
You can connect multiple containers using user-defined networks and shared volumes.
https://docs.docker.com/config/containers/multi-service_container/ >>296
ミスがある前提なら何やっても駄目だろ
ひでー詭弁だな avoid one container being responsible for multiple aspects of your overall application.
avoid one container being responsible for multiple aspects of your overall application. >>298
開発や運用でトラブルが一切無いと考える方が頭おかしい dockerやdocker-composeだけでsupervisordのやってる事と同じ事が出来る
余計なコンポーネントを増やすな >>300
なら1コンテナ1プロセスでも間違いは起こるなー >>301
aupervisorだけでdockercomposeがやるようなことはできる
余計なコンポーネントを増やすな >>303
supervisordあったらdocker要らなくね？ 既存のデータベース使うとかは考えないの？
データベースの入ってないDockerイメージと
入ってるイメージ2種類作るのか？
それか起動時のスクリプトにフラグ追加？
だったら最初から分けとけよ
めんどくさい >>304
要る
svに限らず、全ての依存関係を、imageにパッケージングする機能
インスコした物を、キレイサッパリ、廃棄する機能
お手軽サンドボックス
ありがとう、docker！ >>305
お前さー、少しはレス読みなよ
分散用に、分けたコンテナをオプションで配布する、ことまではヒテイしとらんだろ
言うなれば、マルチサービスコンテナファーストだよ
シングルサービスコンテナはオプションだ >>306
LXCか仮想マシンに直接インスコでよくね？
docker使うならsupervisord使わなくても
docker-composeのyml配れば良いじゃん
何も問題ない >>307
くそデカイメージと小さいイメージ2種類用意するのが面倒
docker-composeなら簡単にかけて
小さいイメージ1種類で済む >>305
それとな、内部DBと外部DBを選択できるコンテナは、わりとよくある
スタンドアロンだとsqlite、そうじゃないとpostgres、mysqlのどっちか
てなわけよ
スタンドアロンファースト
(・∀・)ｲｲﾈ!! >>309
小ささにこだわって、オーケストレーションマニフェスト書かせたり、運用の手間を増やすな
カリッカリにチューニングしたい、オタク共に合わせるのは、大半のユーザーにとっては面倒でしかないんだよ
多少、重くていいから、お手軽に使わせろ、ってーの >>310
sqliteはプロセス要らないからいいが
mysqlやpostgresqlを突っ込めというのはキ○ガイの所業
複数DB対応するには普通は対応コストがかかる
DBラッパー使っても特定DBにしか対応してない拡張は使えないし
docker-composeで書いても大した記述量でもあるまいに
意図的に無視してるな >>311
docker-compose配ればいいだけだろ
基地外 >>313
podmanで動くようにしろ
K8Sで動くようにしろ
Nomadで動くようにしろ
うちの環境はだと動かないんだが？
、、、
お前これ全部対応できんの？ 手軽に試すなら普通はdocker-compose使うから
そんな特殊なやり方で対応する必要がない。
k8sやらnomadに手軽さは求めてないし。
k8sでやるんだったらhelmチャートあると便利。 マルチコンテナだとこうやって、実行環境に会わせて、オーケストレーションマニフェストをたくさん書かなきゃならん
一方でシングルコンテナなら、docker runするだけ
超簡単で、みんなハッピー
しかも、podmanでも、同じように動く そんな手軽さ別に求めてないし。馬鹿なの？
docker-compose用意してたら大体想定されている使い方分かるから、
自分でYAMLなり何なり書けば良いだけ >>317
ユーザーに、手間をかけさせちゃ、だめだ
GitLabはこれをよくわかってる、から、1コンテナに詰め込んだ
ユーザーはdocker runするだけで、GitLabを使えるようになった
これが、マルチコンテナだったら、まあ、大変だよ 自作PCとスマホ、みたいなもんかなー
マルチコンテナ≒自作PC
このパーツ、あのパーツ、色々集めて、ミスしないようにくみたてて、ドライバとかも探して、入れて下さい
ツールは別売りなんで、それも自分で探して、入れてください
組み合せが悪いと、動かないかもしれません
でも、まあ、自己責任です
スマホ≒シングルコンテナ
スマホを購入して、箱から出して、電源を入れて下さい
WIFIとアカウントの入力だけ、お願いします
驚きましたか？そうです、もう使えます！
必要になりそうなアプリケーションも、予め揃えてあります
おめでとうございます！ >>318
作る側の手間がかかり過ぎるって言ってんだろ馬鹿なの？
だから誰も真似しない
本格運用しないならdocker-composeで動けば十分だろバーカ なんでそんなちょっと試して見るだけのくそでかイメージが
あらゆる環境で動く事を気にする必要がある？？？ >>320
大した手間じゃないよ
一流は自分達の、多少の手間を惜しんで、ユーザーの負担を、増やそうとはしない
二流は自分達が、ほんの少し楽したいからって、ユーザーに手間をオシツケテル
GitLabは超一流だ
だから、シングルコンテナを選んだ
そのほうが、ユーザーが、楽だからだ >>321
世界に公開するイメージなら、どの環境でも、簡単な手順で、動いたほうがいいに、決まってる >>322
そんな物誰も求めてないから真似しないんだと思うよ。 docker run --rm -v /var/run/docker.sock:/var/run/docker.sock my-awesome-app docker-compose up >>226でDockerてのは設計としては1コンテナ1プロセスを推奨してますよ、普通は>>308みたいにymlとdocker-compose
で構築してくださいね、でもまあ>>277見たいなケースで複数プロセス動かしたい時は>>288みたいな仕組みは用意して
ますから使ってくださいね、このケースの成功例はGitLabがありますよ。
唯>>296の様なリスクも在りますので気をつけてくださいね。
と、たったこれだけの話なのに一流だ二流だDockerfileもyamlも書かずに使ってるだけだから分かってないと、兎に角
相手をDisらなければDocker原理主義者の皆さんの会話でしたｗ 暇だから適当なこと言ってからかって遊んでるだけだぞ GitLabは例外でしかないだろ
GitLabのDockerfileみてみろ、めちゃくちゃ大変なことしてるぞ
あれはそこまで頑張ってでも1コンテナにしたほうが
利用者にとっては便利だから、工数かけてやっただけで
作る側にとっては大変だってことの証明になってる GitLabはDockerが推奨する「普通の」やり方で作った非公式イメージが前からあった
あのやり方に疑問を抱く者は少なくなかった
公式helmチャートも出来たようだ
helmでそんな巨大イメージにする必要ないので
普通のやり方で作られてる > あのやり方に疑問を抱く者は少なくなかった
それは使う側から見た話だろ？
作る側はどれだけ大変か、Dockerfileを見ればわかる オーケストレーション前提じゃオペレーターも大変だ
オペレーターはレゴブロック遊びに付き合うほど暇じゃない な？「使うわ」という使う側の立場でしか見てないんだよ
作る側の大変さの話をしてるのにな バカの一つ覚えのように一つのコンテナなら手軽に試せるしか言わねえし
何言っても無駄だろ redisとpostgresを何らかの手段で起動し
シークレットの暗号化に使う文字列を3つ作れば良い
たったこれだけ
これ以上簡単になりようがない
それを>>332はできないと言って
先程から大騒ぎしている GitLabはウェブサービスも運営してるが
そのGitLabがそのDockerfileを使ってると思うのか？って話だよな
スケールさせるためには、アプリとデータベースを分離させるのは当たり前だし
Dockerを使うっていうのは、そういうウェブサービスも運営するときの
システムを作るために有るのだから、そういうときにどういう構成にしますか？の
話でサービス毎にコンテナを分けるのは当たり前
作る側の視点がかけてる
これはDockerコンテナを動かすだけの
インフラ屋にありがち ごった煮イメージが本番運用に堪えないって点に異論は無いらしい >>338
めんどくせー
ポスグレでも、Redisでも、シークレットでもねえ
GitLabを、使いてえんだよ
なんだよこの、野球してえのに、サッカーボールでリフティングの練習しろ、みたいな要求は >>339
殆どのユーザーは、有料Gitlabサービス運営なんかせんだろ
オンプレで、テキトーに、運用したいだけ なーんか、噛み合わねえんだよな
昼休憩にラーメン食いたいなぁ、って思ったら、まあ、カップ麺が手軽でいいわな
そうじゃなきゃ、チョイと割高だけど、ラーメン屋にでも行くかぁ、ってそういう話をしてんだよ
それなのにお前らは、
麺はどこそこの業者から原材料を仕入れて、手打ちが至高だの
チャーシューは、最高級の肉を使い、じっくりコトコト煮込んだものが、究極だ
スープはどーしろ、野菜はあーしろ
よし、一週間まってくれ
最高のラーメンを、食わせてやりますよ！
とまあ、こんな感じ
おいおい、昼休み、とっくに終わってる、つーの！ dockerがどこから収益得てるのか考えたら
単なる1ユーザーがdocker使えるわ～とかに
なるわけない
配布と奴隷を効率的に使うためにある いつも、Docker をsupervisord とか、
仮想マシンみたいに使おうとする香具師が来て、1日で100レス以上進む。
同じ香具師だろ
1つの関心事につき、コンテナは1つ。
Docker Compose は本番では使えない
そもそもポートフォワーディング方式だと、スケールできないし。
既にポート80番を使っていたら、
8080番とか、ポートを変えないといけないから、ユーザーがアクセスできない
Kubernetes みたいに、cgroup, namespace が無いと運用できない >>341
> GitLabを、使いてえんだよ
ただのユーザーですか？
ここは開発者のスレです。
使うだけならDockerでもパッケージでもなんでもいいだろが 本番swarmでdocker compose使うよ docker desktopからdocker-compose.ymlで書いたものを使ってコンテナ起動する方法を教えてください nixでDockerfile書かずにDockerイメージビルドしてみた
イメージは作成出来たが、bashの履歴やタブ補完が使えない
なんか設定したら使えるのか？
bash-completion入れてみたが、効果無かった
Dockerfileと組み合わせて使うか、普通にDockerfile使う方が楽かも まさかDockerの中でbashの履歴やタブ補完がほしいとか思ってるのか？
デバッグ用は別として、Dockerコンテナの中で作業するものじゃないぞ
>>1をちゃんと読め docker原理主義者は･･･まあ馬鹿だから分からんわな。
ウチの職場でもこんなツールあるんだぜと、紹介はあったな。
https://youtu.be/Uvf2FVS1F8k 環境依存するものをコンテナに入れていくと、
その環境では便利だけど、可搬性が無くなる
コンテナを別の環境へ持っていくと、環境依存のために動かなくなるので、
別の環境用への環境構築が必要となり、Docker を使う意味が無くなる
>>347
に書いた、
Dockerに、supervisord などを入れて、
仮想マシンみたいに使おうとする香具師と同じ
WSL2, Ubuntu などで直接構築しているのと同じになってしまう。
Dockerを使う意味がない サーバーのメンテナンス作業のために
Dockerイメージに仕込んだスクリプトを実行するとか
開発中にbashに入ってデバッグはするだろう
シェル内でTabと上下キーすら使えない
地味に不便
Tabキーやカーソルキーを打つと空白や謎の文字が入力される
>>353
alpine, debianとかはコマンド履歴はちゃんと動くぞ
履歴はコンテナ削除すると失われるけど コマンド履歴用などの機能があるシェルが入ってないだけでしょ。入れるだけ。軽量目指すとサンドボックスに近くなって作業性は低下する。 devcontainerも知らない冬獅郎がイキってたんか VSCode の拡張機能で出来ないの？
Remote(WSL, Docker, SSH) とか >>360
bashじゃなくてbashInteractiveを入れる必要があったようだ
nixはパッケージが別になってるようだ
ややこしいね >>359
> Dockerイメージに仕込んだスクリプトを実行するとか
そういうのはね、maintenance.sh とかいう名前で
次のような内容のスクリプトを作って
#!/bin/sh
docker run -it maintenance:1.0 script.sh "$@"
$ maintenance.sh list
とかやって実行すれば良いんだよ
管理者に配布するのはこのスクリプトだけ
内部で勝手ににdockerイメージ引っ張ってきて実行してくれる 軽量イメージで有名なalpineも最初からインタラクティブシェルが入ってるぞ
サイズ小さくするためとか何とか言って
そこまで拘りだしたらきり無いだろ セキュリティリスク最小化のために、サイズに依らず極限まで削るという考えがあるので文句言っても仕方ないね セキュリティ的にはアプリをGoか何かでシングルバイナリで作って
本番用イメージはshすら入れないのがさいつよじゃね？
イメージにシェル入れるなら、インタラクティブ版でよかね シェルスクリプトのインタープリターはどうしても要るって場合、
タブ補完と履歴機能は削った方がセキュアに・・・なるかな？
多少複雑さは減るのでその分セキュアにはなるかもしれないが、微妙 devcontainerにはお気に入りの鉄板ツールは全部ぶっこむに決まってんだろ nixは利便性を二の次にして、最軽量コンテナ作ってドヤ顔したいだけなんでしょ。 nixは書くのが難しいイメージだがどうなんだろう。謎の表記法だ テキトーにnix-buildでイメージ作ったらalpineよりでかくなった
なんでだろう glibcとtzdataがでかいな
31M 33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31
1.6M czc3c1apx55s37qx4vadqhn3fhikchxi-libunistring-0.9.10
552K ifnmhjrvk3f0hbz3f25s3izlb9yk8x0f-iana-etc-20200729
100K r2wvgnr54vmwnjvzyqdixv8xbn362jgh-mailcap-2.1.48
4.8M w1g27pgslf28nh1py1szj7lk4xksdhqq-tzdata-2020c
276K xim9l8hym4iga6d4azam4m0k0p1nw2rm-libidn2-2.3.0 musl版のパッケージもあるが、ソースからビルドが多くてとても時間が掛かる
テストまで実行してる
一向に終わる気配がないので中止した alpineでもtzdataは設定だけしてパッケージは消すな >>365
alpineに入ってるのはbusybox ashだね。
インタラクティブな機能がまったくないシェルなんてないだろ？
インタラクティブシェルが入ってるからなんだっていうんだ？ >>367
シングルバイナリで外部コマンドは全く使用しない
ライブラリは全く使用しない
それってDockerで動かす意味有るの？
だってそのシングルバイナリ以外はなにもないんでしょ？
カーネルの機能だけあれば動くなら、
Dockerの外で動かせばいいじゃないｗ
外部に依存しているものを動かしたいという前提があるから
Dockerを使うのであって、その前提を無視するなら意味がない >>378
コンテナオーケストレーター使うなら
意味あると思う
何言語で書かれていようが
同じ方法で環境変数の設定やら監視やらローリングアップデートができる
Goも例外ではない
>>377
nixはbashとbashInteractiveに分かれてる
Interactiveなしの方はインタラクティブシェルに普通はある機能が省略されてて
シェルのインタラクティブモードに入っても
タブで補完できないし
上を押すとASCIIコードがそのまま出る >>378
オーケストレーターがシングルバイナリに対応してるならコンテナは要らんよ ローカルでCLIツール動かすだけならバイナリを直接配布でもよい
Webサーバーとか動かすならコンテナオーケストレーターの機能は便利 >>380
コンテナ使うならシングルバイナリなんかいらんよｗ
シングルバイナリだと修正したときに全部ビルドし直しだろ？
それってDockerイメージ作り直しと同じことしてるだけだからね
シングルバイナリビルドし直しOKなら
Dockerイメージビルドし直しもOKなはずだ >>381
中間は？Ruby（Rails）のように1バイナリを
作るわけじゃないけど起動するのは1アプリ >>379
> Interactiveなしの方はインタラクティブシェルに普通はある機能が省略されてて
それはモードの違いであってバイナリは同じ HashiCorpのサービスはどれもこれもシングルバイナリだ
たしかにあそこまで行くとDocker要らんわ だからDockerは（シングルバイナリとかを）使うためじゃなくて
開発者が自分で開発するときに使うもの
シングルバイナリを作るのが難しい場合もたくさんある
スクリプト言語なんかはほぼ全てそれ
開発者のためのもの 大は小を兼ねるってことで
DroneCIはDockerコンテナ内での実行しかできない
割り切った設計になってる
コンテナさえ対応しとけばいろんな言語向けのツールを個別に作らなくて済むからな alpineはパッケージのバージョンを固定する方法がないから
どうしてもalpineベースのDockerイメージをビルドする時は前回より新しいバージョンがインストールされる可能性がある
The problem with Docker and Alpine’s package pinning
https://medium.com/@stschindler/the-problem-with-docker-and-alpines-package-pinning-18346593e891
単にパッケージのバージョンを指定すると、そのうちパッケージがリポジトリから消えてビルド出来なくなる
古いバージョンのリポジトリを使うなら可能だが、マイナーバージョンのアップデートはされるだろう
特定のパッケージだけ最新メジャーバージョンにしたいから
複数のリポジトリを使い分けするぜ！みたいな使い方は
一応可能らしいが、
公式にはサポートされてない >>388
古いリポジトリがアーカイブされている必要もあるし、
結局、Debian、CentOS（8以前）とか、硬派なバージョン管理をしているdistroを使うしかないと思う。
そうでないと、ABI互換されへんしな。 >>389
気軽にできないってことは使い方が間違っているということだよ
何に使ってるのさ？仮想マシンを使えば？ k3dはdocker in dockerのReal world example
中で起動するのはdockerじゃなくてcontainerdだけど
docker in dockerと同じパターン
コンテナの中でk3sやcontainerdを動かす ん？だからk3dに相当するようななものを作ってるの？って話だよ
そういうのは例外的なシステムだよね だからTravisCIのようなCIフレームワークを開発してる
会社だったらほしいというのはわかるけど
そういうのは例外的だって話 >>394
主にCI、開発コンテナだな
あとたまにバックエンドでコマンドラインを多用するサービスなんかもあって、そこでもDinDを使いたくなる
Dockerfileで静的にインストールすると、コマンドラインのバージョンが固定されちまう
が、DinDだったらコマンドラインのバージョンを実行時にダイナミックに変更できる
DinDならオフィシャルのイメージを使えるってのもいいね
自前でパッケージインストールすると最適化がどうしても甘くなる すみません
初歩的な質問で申し訳ないのですが、
今でもWindows10 ProでDockerを使うと、Oracle Virtual Boxは使用不可になりますか？
1年前にDockerを導入したところVirtual Boxが起動しなくなってしまいまして
昨年末にHomeでもDockerが使えるようになったとのことで、ついでにそこら辺も解消されていないのかなと思い・・・。 できるマシンとできないマシンがあるので試してから買ったほうがいい >>398
ノートのCPUはRyzen 3700Uでして、当時調べた記憶ですと出来ない方のCPUだった様な・・・
DokcerをアンインスコしてHyperVをオフにしてもダメだったんですよね
ありがとうございます Hyper-VとVirtualbox等の別のハイパーバイザーは共存不可
同時には使えない
最近のバージョンのVirtualBoxはHyper-Vに対応してるけど
まだ実験段階らしいのでおすすめしない
Vagrant経由でVirtualbox使ってるならHyper-Vを直接利用に切り替える手もある Mac、LinuxならDockerとVirtualBoxが共存できるよ
開発者なら今すぐMac、Linuxに移行しよう >>397 こういうのはVirtualBoxに適当なLinuxいれてその上でDocker使うことと何が違うの？
Win10->VirtualBox+Linux->Dockerと
Win10->WSL2->Dockerで使うのは、結局同じなんじゃないの？ >>396
> Dockerfileで静的にインストールすると、コマンドラインのバージョンが固定されちまうが
それは、シングルバイナリにすると、ライブラリのバージョンが固定化されてしまい
アップデートする時に、すべてバイナリを作り直しになるという話と何が違うの？
つまりコマンドラインのバージョンを変えたいなら、Dockerイメージを作り直せばいいだけじゃない >>402
>>397 こういうのはVirtualBoxに適当なLinuxいれてその上でDocker使うことと何が違うの？
Docker公式サポート版か、独自ビルド版かの違いのようなもの
公式のWindows版はWindowsで使いやすいように開発されているが
Linux版を使うのであれば、Windowsで使いやすくするために
Dockerがやってる部分を自分で開発しなければいけない >>402
hypervisorも変わるし、結局同じじゃない
とりあえず、Windowsを捨てるこっちゃな Windowsを捨てられるならとっくにそうしてる
今はLinuxだけが動けばいい世の中ではない >>403
動的に変えたいんだよ
いちいち組み合わせごとにビルドしてらんない 使いやすさで言うとLinux母艦がベスト
Windows母艦使わなきゃならん場合はLinux仮想マシンが良い
でも唯一の弱点があって重いこと
それだけにために使いにくい公式のdocker for winを使う >>407
シングルバイナリの話で言えば、
OSやライブラリ毎にバイナリを作りたくないって話？
何が問題なのかさっぱりわからいんだけど？
やりたいことじゃなくて、問題になってることを書いたら？
素人が考えた問題の解決方法が、そもそも間違ってるってのはよくある話
こういうの英語でなんて言うんだっけな？ 例えば>>407は「動的に変えたい」は間違った解決策である可能性が高い
「いちいち組み合わせごとにビルドしてらんない」ならば
組み合わせごとにビルドできるようにするのが
本当に解決すべきことで、その手段は他にあるだろうって話 例えば
Javaバージョンを10種類
Python 10種類
Ruby 10種類
の任意の組み合わせをサポートするとしよう
組み合わせごとにimage作ってたら1000回のビルドが必要
しかも静的なのでバージョン切り替えるのにコンテナ再起動が必要
アプリケーションユーザーがバージョンを選ぶことができない
DinD無しで動的に切り替え可能にするにはimageに30のパッケージを詰め込まなきゃならん
アプリケーションユーザーがバージョンを選べるようになったがimageが重すぎて駄目だ
DinDなら簡単だろ？ dockerインストールしてdocker image使えば動く
それが大きい
組み合わせとか無駄な労力 そうじゃない
組み合わせで無駄な労力をかけなくていいようにDinDなんだよ
DinDじゃなきゃ組み合わせ爆発で大変な目に合う CircleCI の、Win/Mac/Linux 環境でのマトリックスビルド >>412
> 組み合わせごとにimage作ってたら1000回のビルドが必要
1000回のビルド vs 1000回の入れ替え
だろ？
何も違いがないんだが あ、もしかしてイメージのビルドって
JavaやPythonやRubyのソースコードから
ビルドするって勘違いしてるのか？
Dockerイメージのビルドって単にファイルをコピーするだけだぞ
お前の言うファイルの入れ替えと何も変わらん nixもalpine同様パッケージバージョンそれぞれで固定は出来ないが、
過去の特定時点でのリポジトリを使う事や
不安定版と安定版を組み合わせる事は出来るみたい
Dockerイメージのビルド機能はDockerデーモンは要らないが、
イメージに対して追加でコマンドを実行する（runAsRoot）にはKVMが必要
Nested Virtualization非対応のWSL2とかGitHub Actionsでは使えないのでハードル高い
各パッケージのインストールにはkvm不要なのに
runAsRootを使わずにDockerfileでコマンド実行すればkvm無しでも良いけど
それちょっとめんどい
nixだけで完結させたいね >>418
ビルドする「事がある」なら、ビルドしないような
Dockerfileにするのが本当の解決方法 >>422
Amazonはgoのbuildしててアホってこと？
おまえAmazonより賢いの？ dockerには様々な使い方ができてそれが便利なんだが
どうも「僕の考えた正しい使い方」以外に強烈な拒否反応を示す輩がここに住み着いてるみたいだね
こいつのせいでいつも荒れる >>423
アホなのか？ビルドしても問題ない場合の話なんか誰もしてねーよ
ちゃんと読んでみろ、1000回のビルドに困ってるやつが
「ビルドしててアホ、俺はDinDを使ってる」って言ってんだろ
そして、1000回のビルドの組合せ爆発を行わせないために
ファイルを入れ替えて、1000回のテストをやるって
言ってるんだぜ？どっちみち組合せ爆発してるじゃねーかｗｗｗ 組合わせビルドだと1000の追加容量
全部のせだと30の追加容量
DinDなら追加容量ほぼなし最適化もテストも各種イメージ提供元がやってくれてる ほらな？馬鹿だったやろ？
レイヤーを共通で使うってわかってないんだよ >>427
組み合わせだからレイヤー使っても減らんぞ？ どんなに組み合わせがあろうと、OSのレイヤーは
全部共通だってまだ気づいてないのかな？ｗ DockerコンテナじゃなくてMacに直接ツールをインスコしたいんだが
バージョン含めて統一は難しいな
asdfは一見バージョン切り替えに便利そうに見えるが、
とうも一部プラグインのインスコは自動ではないようだ
brew使ってインストールとか手動でさせたらむずいし、バージョンの組み合わせによっては失敗するかも
nixはインストール自動化は出来るが
関数型言語で書く必要があるのが何だかなあ
Mac上で直接やるの諦めて
開発用のパッケージが入ったDockerイメージを配った方が良いかも
IDEとの連携はVSCodeのRemote Container拡張機能とかでする感じで・・・この拡張機能まだプレビューだけと >>431
これは本当に必要か？手段が目的化していないか？
と自分に問うクセを付けたほうがいいよ asdf とか、日本人が作った、バージョンマネージャーのanyenv は、
主に、Ruby, Node.js などの言語のバージョンを指定するだけ
アプリ・フレームワーク内での、依存モジュールを指定するには、
RubyのBundler, Node.jsのnpm/yarn などを使う
例えば、Ruby on Rails なら、まず、Ruby 2.6 で、Rails 6 などを先に決めてから、
それに合った依存モジュールとして、
サーバー側はRubyのBundler, GUI側はJavaScriptのYarnで決めていく Dockerで複数のイメージを作っても
同じ内容は共通化されるんですよ
だからファイルサイズは増えません
バイナリを入れ替えるとかいう変なやり方と
使用する容量はほぼ変わりません 内容が同じなら共通化されるわけじゃない
Dockerfileのコマンドが同一かどうかだろ
パッケージをA,Bの順で入れるのとB,Aの順で入れるのでは結果イメージが同一でも別物 >>436
マルチステージビルドとかしらんの？
一つのDockerfileに
FROM as java-x.y.x
…
FROM as ruby-x.y.x
…
FROM as python-x.y.x
…
とか書いてあれば、別のDockerfileに同じことが書いてある時に共通化されるんだよ
そしてそのDockerfileの下に
FROM …
COPY --from=java-x.y.z /opt/java /opt/java
COPY --from=ruby-x.y.z /opt/ruby /opt/ruby
COPY --from=python-x.y.z /opt/python /opt/python
と書いてあれば、単にファイルをコピーするだけ
ファイルコピーなんだからDinD（笑）とかで
ファイル差し替えとかいうのとやってることは何も変わらん
ベースとなるイメージは共通で使って
実際に動かすイメージだけビルド→終わったら破棄すれば容量食わないし
元となるイメージは削除せずに使い回すのだからビルドの時間もかからん >>439
使うたびに消すのだからいらない
それ言ったら、DinDだって1000容量必要なわけで
イメージ毎にファイル差し替え＝コピーしてるでしょｗ nodeをdocker runして複数のバージョンのnodeで自作ライブラリをテストするとする
ソースコードのディレクトリをボリュームマウントして
npm ciでライブラリをインスコして
npm run test
これの繰り返しで良くね？
CIが普通にLinux仮想マシン使えるやつならDinDにはならん
Docker内でしかコマンド実行できないCIだとして
そのCIに複数のイメージで同じコマンドを実行する機能とか無いか？ >>441
必要なディレクトリが分からないケースがあるので困ってる。後はパスをどうやって通すのか。
本とかあれば教えて >>443
そんな内容で他人に通じるとでも思ってんの？ ↑単にnodenv,pyenv,rbenv入れて切り替えれば良いだけじゃね？
マスターは全部（３０全部のせ）インストールして。
jdkだけ無いから、dockerfile内でJDK_HOME変数いじる。 なんかしらんがどうしてもDinD使いたいんだろうさｗ >>440
実行するたびにビルドすんの？もうめちゃくちゃだな
DinDなら30の容量で済むのに組み合わせの事前ビルドだと1000必要
DinDだと実行するまで容量を食わない >>445
依存パッケージのバージョン競合が不安になるな >>448
依存パッケージは各々の環境配下に入るんだから別に関係ない。 >>447
各言語、お前がいう30の容量だけ事前ビルドして、
残りは実行時にビルドするんだよ
ビルドって言ってもファイルコピーと変わらない
お前の言う「差し替え」＝実行時ビルド >>450
実行時にビルドとかｗ
もうめちゃくちゃ マルチステージだから容量食わないけど、毎回ビルドと言ってるキチガイは何なの。
毎回ビルドする位なら、オンプレに入れて各言語の仮想環境使った方が遥かに効率的でマシ。何分まつのやら 別に此処で聞くような事では無いって気がするね。
要するに、どうしてもDinDが使いたいって話だろ。
他の解決策はあると思うし、DinDの設計意図はそういう事（組合わせ）では無いと思うけど
DinD使ってドヤ顔したい奴はそれ自体が目的だしね。 >>451 >>452
実行時ビルドにちゃんと理由言って反論しなよｗ
俺は認めたくないって言ってるだけじゃんかｗｗｗ 毎回ビルドはしない。
頻繁に変わるソースコードなどは、bind mount・共有フォルダ、
DB のデータなどは、Docker 管理のdata volume
複数言語のバージョンマネージャーのanyenv なら、
which ruby
~/.anyenv/envs/rbenv/shims/ruby
which node
~/.anyenv/envs/nodenv/shims/node なんか、実行時ビルドが数分かかるとか勘違いしてるっぽいなｗ
ファイルコピーしかしないのに、どこに時間がかかると思ってるんだろう CIでビルドすることなんて当たり前ですし
［速報］GitHub Actions発表、Dockerコンテナの連係によるワークフローを自由に定義可能。GitHub Universe 2018
https://www.publickey1.jp/blog/18/github_actionsdockergithub_universe_2018.html https://cloud.google.com/cloud-build/docs/automating-builds/run-builds-on-github?hl=ja
GitHub でのビルドの実行
Cloud Build では、Cloud Build GitHub アプリが利用できます。このアプリでは、
新しい commit を GitHub に push するごとにコードを自動的にビルドできます。
このチュートリアルでは、アプリのインストールと構成方法、GitHub でビルドを自動でトリガーする方法について説明します。 >>462
そのリンクはビルド→デプロイの自動化、デプロイ→テストの自動化であって
「プログラムの実行前のビルド」ではないけどね。
てかごく一般常識的に、実行前にビルドなんてしない。
pull→ビルドすら長ったらしいので何とか短縮する方法考える位だし。 真っ当なビルドと偏執狂のビルド
区別がつかない人は怖い そのスマート（笑）なDinDのやり方ってやつを
ここで言ってみなさいよ。何も言ってない。DinDといいたいだけ >>466
コンテナ内でdockerソケットにアクセスするだけだ
余計なビルド不要、imageベンダによる最適化、テスト済、容量も最小限で済む >>467
え？Dockerコンテナ同士が違っていたら
アクセスできないじゃんｗ 実行環境の制限がないならDINDせず
ホストOSでやれば良くね？
何やろうとしてんのか知らんけど なんでわざわざDockerの中でテストしようとしてるんだろう？
普通にホスト上でdocker-composeとか使ってテストすりゃいいんじゃん
DinDなんかいらね >>472
俺も思った。
最初>>437のような問題を抱えて、それが何故DinDだかDooDだかで解決するんだろうかと思ってたら、
異なるバージョン間の問題は別コンテナっぽいよな。普通にやってりゃ良いじゃんとしか思わないｗ >>475
君、そもそも会話する気ある？そんな説明じゃ分からん そろそろ ID:6ru/T4M8 は無視で良くね？ docker in dockerは使いみちあるとしても
頭悪いやつがvirtuabox in virtuaboxのように
ぐだぐだにされたら迷惑だろ しばらく放置してたらpodmanいいかんじになってた
docker-composeもほとんどそのまま動く 次スレはコンテナでまとめたほうがいいと思う
k8sも合流させたほうがもりもりする気 >>484
Dockerの話禁止とか了見の狭い掲示板を誰が使うんだ？
自分で埋めれば？ 最近まじでdockerの影が薄くなってきたな
docker composeが動きだしたから、お手軽開発環境としても存在価値が薄れてきてる
dockerの利点はせいぜいbuildkitとwindows、macで動くことぐらいか 訂正
podmanでdocker composeが～ >>486
Windowsで簡単に使えることはメチャメチャ利点だけどな！ docker composeはdockerに依存してるんだがｗ OCI対応してればどのコンテナランタイムでも動くんだろ？
好きなの使えよ >>488
事務職ならあるかもだけど開発者なのにWindows縛りってのも考えにくい >>489
docker composeはdocker apiに依存してる
そしてその代替としてpodman apiというのがある 何か知らんけどdockerのコマンドと互換性ないの？
podmanって いつも思うけどなんでそんなに代用品を使わせようとするのか理解できないんだよなぁ
赤帽とか普通なら信用できんだろ まあ、Flashの例もあるからね。
別に悪いわけではないし、標準に近い機能であっても業界から嫌われる技術ってのはあるんでしょ。
大体その本尊が他社の要望に答えないって事なんだろうけど。 podmanのほうがコミュニティが活発でリリース頻度が高い どんなプロダクトでも黎明期を超えて落ち着いてきたらセキュリティ、軽量さのために余計なもん削ぎ落とした物に取って代わるもんだよ 何時になるのかはわからんけど本格的に使ってみてもいいかなって思うのはver3.1からだろ
黎明期は仕様変更多すぎて手を出したくない Docker ボリュームを全て、別のホストマシンに移したいと思っていますが、
ボリュームのデータの移し方について質問があります。
いま考えているのは方法は次の通りです。
１、新しいDockerホストにおいて、旧ホストと同じになるようにdocker create volumeコマンドでボリュームを作成します。
２、新旧のDockerホストで、Dockerサービスを停止
３、対象ボリュームについて/var/lib/docker/volumes/volume-test/_data/ のように指定してrsyncで新しいDockerホストにコピーします。
rsync -avz /var/lib/docker/volumes/volume-test/_data root@newdockerhostname:/var/lib/docker/volumes/volume-test/
その後、新しいDockerホストで、コピー済のはずのvolumeをつかって、
コンテナを復元します。
どういう方法が標準的、推奨方法でしょうか。
あるいは以上の方法でも良いのでしょうか。
よろしくお願いします。 >>502
コンテナ管理するのにオーケストレーション使うからそんなこと考えたことないけどそれで動くならシンプルでいいんちゃうか？ ボリュームの移動とか考えてる時点でバッドプラクティスにハマってる気がする
ほんとに永続化したいボリュームにはネットワーク越しのストレージを使うんだよ
そうすりゃコンテナが別のマシンで稼働してもいちいちボリュームを移動させる必要はないだろう？
コンテナは同じマシンで動き続けることを前提にしちゃだめ GitHub ActionsはDockerHubの制限免除だって https://github.com/actions/virtual-environments/issues/1445#issuecomment-713861495
For publicly accessible containers we are working with docker hub to make sure you will not be impacted by
the new rate limits. If you need private containers we still do not have a solution for that problem for forks of public repos.
公的にアクセス可能なコンテナについては、Docker Hubと連携して、新しいレート制限の影響を受けないようにしています。
プライベートコンテナが必要な場合でも、パブリックリポジトリのフォークに関するその問題の解決策はありません。 >>504
ただの老朽更新とかの移行だろ
そんなもんに共有ストレージとかバカじゃねーの AWSならEBSボリュームのスナップショットで十分
ASG内のインスタンスが起動する時に
EBSボリュームをマウントして
ECSタスクではそのボリューム内のディレクトリをマウントする
EFSみたいなマネージドNFSは速度や互換性に問題無ければ使っても良いんじゃね
俺は使わないけど >>507
バカだな
ストレージを外部化しておけば結合が疎になりストレージのメンテナンスもしやすくなるだろ だいたいコンテナなんてのはどのマシンで動くかわからねえんだ
ローカルボリュームに依存しちゃだめだ コンテナはどのマシンで動くかわからねえってのは重要なことだ
固定的なマシンで動かす前提ならコンテナを仮想マシンの延長上的な使い方しかできてないってことだ
固定的なマシンならコンテナじゃなくていい
普通にパッケージ入れて普通にsystemdで動かせばいい
どのマシンで動くかわかってるんだから事前に必要なものを準備するだけ
dockerという余計なレイヤーが消えるのでそのほうが管理が容易い
コンテナを使うなら次の瞬間にコンテナが別のマシンに移動しても動くように作れ 理解できない雑魚は仮想マシンでも使ってろってこった 俺のアドバイスを無視して、どうしても、ローカルボリュームに執着し、コピーしたいなら
docker公式文書にtarコマンドによるボリュームバックアップの方法論が書いてある、ので探せ
あとは応用だ。パイプラインと-Hフラグが便利だぞ データベースだったらデータベースのレプリケーション機能で耐障害性の高い構成にするのがベストプラクティス
ボリューム自体はローカルにする
これが最も高い速度とHA（高可用性）を両立できる構成
ただ、自前でHAをセットアップして運用するのは大変な事も多い
マネージドサービスつかうか
k8sならオペレーター使うとかした方が良い
のっぴきならない事情でアプリをHA対応に出来ない場合は
NFS使って速度は諦めるか
HAの方を諦める
アマゾンのマネージドNFSは一貫性のために性能を犠牲にしてる
一貫性を犠牲にしたらもっと速くなるだろうが、同期されるまで各サーバーのデータが古いままって状況が起きうる OSSアップリは遺憾なことにFSを使用する不届き者がまだまだ多くて困る 相も変わらずココはコミュ障だらけだなｗ
ID:+SWvD/Px とか相手の要件も聞かずに己の持論を熱く語って何を解決したいんだｗ？
「コンテナなんてどのマシンで動くか分からない」って 502はそんな情報は何も与えて無いじゃんｗ
単に一台で動いていたDockerホストをスケールアップした別ホストに移行したいってだけかも知れんのに。
で妄想膨らませて、まーた「仮想マシンでも使ってろ」とか関係ない方向に話持って行こうとするし たまに止まってても許されるような
そんな大事なシステムじゃなかったらローカルボリュームでも良いんじゃね？
知らんけど >>520
その要件なら、従来のインフラ管理手法でスケールアップさせりゃいい
だから、仮想マシンと変わらんと言ってる
コンテナを使うなら、どのマシンで動くかはわからないのが、当たり前 コンテナが動くマシンが決まりきってる、ってんなら仮想マシンで十分だ
EC2でもなんでもいいよ
普通にパッケージを入れて、普通にsystemdで動かしゃいい
dockerなんて余計なリソース食うだけ
仮想マシンなら、従来の管理ノウハウも役に立つ
コンテナを使うなら、クラスタが大前提 >>522
日本語を読めよ、と俺は言ってるんだが？502はそんな情報は与えてない。 >>523
だから勝手に妄想を膨らませて話を横道に持っていくなよ、と言っている。
「仮想マシン」も「EC2」も「systemd」も「従来の管理手法」も502の話には一切あがっていない。
「移行するための標準的な方法は何ですか？」って聞いてるんだから
こういう方法があるよ、と答えれば良いだけ。 >>525
標準的な方法？従来の管理手法とおなじだぞ 何か知らんけどコンテナ嫌いなら
Dockerアンチスレとか
コンテナアンチスレとかいう名前のスレ立てて引きこもれば？ >>526
お前馬鹿なの？502を口に出して10回読んでからレスしろよ。
「
その後、新しいDockerホストで、コピー済のはずのvolumeをつかって、
コンテナを復元します。
どういう方法が標準的、推奨方法でしょうか。
あるいは以上の方法でも良いのでしょうか。
」
と書いてあるんだが？ >>529
だから従来の管理手法でいいと言ってるんだよ >>530
「どういう方法が標準的、推奨方法でしょうか。」
この一文を30回ほど口に出して読んでね。
アスペには10回じゃ足りない。 >>531
だから従来の管理手法でいいと言ってるんだよ Software Design 12月号のDocker 特集3章、Ruby on Rails プロジェクトの所で、
data volume を利用した、MySQL データのバックアップ・復元方法が書いてある
data volume を圧縮解凍する、専用のbusybox コンテナを用意して、
その起動時に、--volume-from で、MySQLコンテナを指定する
圧縮: busybox tar cvf
解凍: busybox tar xvf >>514
その、tarコマンドでボリュームバックアップをとる方法は、
ターゲットボリュームをマウントしているコンテナでバックアップ先ディレクトリもマウントし、
tarコマンドでボリュームに保存されているファイルをバックアップ先へ横流ししているだけだと考えています。
そうだとしたら、
Docerホスト上において、/var/lib/docker/volumes/target-volume/_data をrsyncで他のホストに直移しでも良いように思うわけなのですが。
tarを使う方法ではなにか違うんでしょうか。 >>520
メンテナンスによるダウンタイムを避けるために、
別ホストへコンテナを引っ越しさせます。
ボリュームも移してあげる必要が有ります。
>>530
ボリュームを移す従来的管理方法ってあるんですか？
>>535
なるほど。
いったんtarで圧縮ファイル化するわけですね。
Dockerホスト上の、/var/lib/docker/volumes/target-voryume/_data から直移しの例があればいいんだけどなあ
rsyncなら、変更のあったファイルだけを追加的に移せるので作業時間を分散できます。 >>537
いや、530が言うには君はコンテナ使う資格無いからVM使えってさ。
>dockerなんて余計なリソース食うだけ
>仮想マシンなら、従来の管理ノウハウも役に立つ
>コンテナを使うなら、クラスタが大前提
そもそも「コンテナを使うなら、クラスタが大前提」は完全に間違い。
k8sはその通りだがDockerはターゲットが開発者だから、どちらかと言うとシングル。
おまけにコンテナ化する目的はIaCなのに、それも理解してないｗ。
さらに日本語も読めてないとかｗ Dockerは可搬性を持たせるためのものだから
どこでも動く=k8s上でも動くってだけなんだよね >>536
ホストマシンへの依存を減らすことが可能です >>538
IaCはdocker専売特許ではありません >>536
> Docerホスト上において、/var/lib/docker/volumes/target-volume/_data をrsyncで他のホストに直移しでも良いように思うわけなのですが。
そこはDocker内部のボリューム領域
どういう管理をしているかはDockerの内部の仕組み次第
フォルダをそのままボリュームとして使いたいなら
指定したフォルダをボリュームにすればいいだけの話 >>541
> IaCはdocker専売特許ではありません
質問「他に何があるんですか？」
↓
お前「○○があります」
↓
お前のマネ「IaCは○○専売特許ではありません」
↓
お前「IaCは○○専売特許なんていってねーよ！」
↓
お前のマネ「IaCはDocker専売特許なんて誰も言ってねーよｗｗｗ」 さて、IaCはdocker専売特許とは誰が言ったのかな？ コンテナとクラスタは、全く異なる
Docker は本番では使わない。あくまで開発者が使うもの。
本番では、Kubernetes を使う
Dockerはポートフォワーディングだから、
スケールすると、同じポート番号を使えないから困る
だから、AWSとかシステム構築運用を知らない香具師が、
Dockerを仮想マシンのように使おうとするw
だから漏れは必ず素人に、Docker・Kubernetesの相違点を聞く > 本番では、Kubernetes を使う
1台なのにKubernetes使う理由は？ > Dockerはポートフォワーディングだから、
> スケールすると、同じポート番号を使えないから困る
Kubernetesでも同じポート番号は使えません >>549
オンプレでテキトーに運用したいならswarmもアリ bind mount は、プロジェクトのソースコードみたいに、
開発時に頻繁に修正するものに使う
一方、data volume は、主にDB のデータに使う。
これは、Docker が管理していて、複数コンテナで共有できて、バックアップ・移行しやすい
だから、
>>535
みたいに、バックアップ・復元用のコンテナを通して扱う
だから、Dockerの管理領域を、rsync で直接操作するのは、筋が悪い。
Docker CLI/API を通していないから
環境に依存していると、Dockerの可搬性がなくなる bind mount は、ホストマシン OS のディレクトリ構造に依存しますが、
data volume は完全に、Docker によって管理されます。
data volume は、バックアップや移行が容易です。
Docker CLI コマンドや、Docker API を利用して管理できます。
Linux と Windows 上のコンテナーにおいて動作します。
複数コンテナー間にて、安全に共有できます >>554
> bind mount は、ホストマシン OS のディレクトリ構造に依存しますが、
> data volume は完全に、Docker によって管理されます。
はい、それはつまりDockerに管理されてるので
ホストマシンOSのDockerのディレクトリ構造を参照してはいけないということです。 >>553
なるほど。
/var/lib/docker/volumes/target-volume/_data を直接いじるのは止めときます。
Dockerコンテナ上での操作にとどめるようにしてボリューム内容の移行作業を何かしらの方法で行いたいと思います。
rsyncを使うにしても、コンテナの上から発信したいと思います。
>>538
530の言う従来的方法って、仮想マシンのこと？
仮想マシンの方が、リソース喰いますよね
それに、仮想マシンであるVPSでは、仮想マシンは動かせない。
費用も高くつきます。 >>542
確かに、勝手な想像で事を行わないほうが安全ですよね >>554
＞Docker CLI コマンドや、Docker API を利用して管理できます。
Linux と Windows 上のコンテナーにおいて動作します。
複数コンテナー間にて、安全に共有できます
dockerコマンドで、ボリュームをバックアップするようなこと便利な命令はないですよね
複数コンテナで同じボリュームを共有できると言っても、アプリケーションレベルで共有時におけるファイルの安全な扱いが保証されてないとだめですよね。 >>549
k8sもDocker使ってるが（笑）☺ >>556
> それに、仮想マシンであるVPSでは、仮想マシンは動かせない。
嘘は良くないなあ☺
Nested KVM があるよ☺ 仮想マシンで仮想マシンを動かすときの問題点は
仮想マシンを更新するのが面倒であるということ
仮想マシンのイメージを更新したとして
それをどうやってクラスタ上に配布するのか？ 前スレの567だが
＞567login:Penguinsage2020/10/16(金) 00:41:44.42
＞大切なパスワードを保存したイメージを間違ってdokerhubにうｐしちゃったらどうなるの
＞
＞568login:Penguinsage2020/10/16(金) 01:24:07.31ID:EJhQrEIg(1/1)
＞どうやったらそんなミスをするのかって悩むレベルだなｗ
自分でもまぁそんなことはないだろうけどってつもりでふとレスしたんだが
例のS◯BCのやつでワラタ
まぁ非公開のをforkってことだが ↑金融機関がクラウドサービス使うとかアホの極みだな。
プログラムを共有したいならgithub相当物をオンプレで運用しろよｗ >>563
そのためのGitHub Enterprise
https://www.hitachi-solutions.co.jp/github/
GitHub Enterpriseは、全世界で使用されているGitに対応したバージョン管理システムである
GitHub.comと同等の機能をオンプレミスやプライベートクラウドで利用できます。
まあ知らなかったんだろうがな（苦笑） >>564
いやいや、うちの会社Enterprise使ってるし。
github.comドメイン使うと権限間違って誰でも見れるような所に
置いたり事故が発生するから、使うなよって話してるんだが？
まあ、ニートじゃ雰囲気わからないだろうが。（苦笑） >>561
最初の仮想マシンと同じ方法で更新すればいいじゃない？☺
OpenStack とかご存知でない？☺ >>565
Enterprise と、github.com の連携で internal リポジトリが作れるよ☺ 賢くなったね☺ >>569
ん？じゃあそれが「github相当物をオンプレで運用しろよ」じゃね？
君、話が読めてるのｗ？ >>572
まあ、いいよ。
ココは日本語理解できない奴ばっかりだし。
君もその一人ってことだよ。 >>568
> 最初の仮想マシンと同じ方法で更新すればいいじゃない？☺
「最初の仮想マシンと同じ方法」はとても大変な方法なんです。
OSの起動だけでも分単位の時間がかかる上に
イメージはでかく、それを配布する手段も確立されていません 個人的なWebサイトをDocker上に建ててローカルで見れるようにしてたんですが
今度引っ越すことになって外部からアクセスしなければならなくなりました
Linuxホスト上にVPNサーバ建ててVPN経由でアクセスするのと
Webサイトに無料DDNS追加して外部に公開するの
どっちがセキュリティや利便性的によろしいんですかね？ >>581
セキュリティや利便性の前に要件が違うだろ
まずどっちかに固めろ
自分の所（例えば自宅）からだけ見ればいいのか
それ以外の場所からも見えるようにしたいのか
それを決めるのが先だろ ↑それ以外の所からアクセスしたいからVPN鯖立てるんだろ。 >>582
自宅(サーバから見て外部ネットワーク)から見たいです
見るのは自分だけです >>583
VPNは自分しか見れないなら「自分の所」扱いです >>581
あー、いいかい
それ、ドッカーンは1㍉も関係ないよね？
スレチなんだわ ドッカーってホストOSに影響なしで実行できるというけど
ドッカーでsshdのイメージ作れば影響なさすぎて
どこにもアクセスできないじゃん >>588
デフォルトのDockerネットワークでは、
インターネットにしか出られないよ >>558
sshdのイメージ作ればアクセスできないけど
sshdのイメージ以外を作ればアクセスできますよね？
なんでそう大工道具で犬小屋作れば
人間は入れないじゃんみたいな言い方するんです？ sshdはホストOSので良くね？
普通は搭載されてるだろ >>592
何のためのコンテナなんだよｗ
何もしなくても自由にポート番号を変えることができるから
「可搬性がある」と言われてるのに 何が聞きたいんだ？具体的に言わんと論点が合わんと思う yum とか、aptで、sshdのコンテナへの導入なんて簡単にできる。
独自コンテナ用ネットワークを構成すれば、ポートフォワードの設定も不要に、独自IPアドレスをコンテナに割り当てられる。 ただ何のためにsshdのコンテナを作るのか？と言われれば
利用用途が思いつかない
おそらくそういう使い方自体が間違ってるのだろう DockerコンテナやKubernetesクラスタをGUIで管理できる「Portainer」レビュー
https://gigazine.net/news/20210211-portainer/ >ユーザーやチームごとに許可する操作や閲覧可能な情報を制限できる「Roles」機能が有料なので、無料でPortainerを利用する場合は作成する意味がないかもしれません。
ACLないのか残念 すみませんちょっと私見をいただければ幸いです。Kubernetes初学者です。
座学だけではなかなか理解が進まないので、自宅ノートPC(Win10pro)でハンズオン
学習をしたく思います。
VirtualBoxでCentOSの仮想マシンを2台立ててMaster, Workerノードに見立てて、
初歩的な部分（ベースイメージを引っ張って本番環境を作成＆適用まで）ができれば、
と考えてます。このとき仮想マシンのメモリは2GBじゃきついでしょうか。
やっぱり4Gは要りますかね。自宅 途中送信、失礼しました。
自宅PCのメモリが8GBで増設不可なのです。 これを機会にメモリ16GBのノートに買い換えるのも視野に入れています。
（デスクトップは移設が大変なので対象外にしています） とりあえず1回やってみたら？
8Gじゃk8sは関係なく辛いとおもうけど k8sは起動するだけで1GB近くメモリ食うバグはなおったんか？ 仮想マシン1台あたり、OSとアプリで1GB、k8sで1GBでギリ行けるやろｗ >>608
やっぱりきついんですね。。
k8sの前に、まずメモリ4GBの仮想マシンを１つ立てて、Docker-composeでNginXとPostgreSQLの
2コンテナ立てるところまでやってみたんですが、Win10のリソースメータみたらメモリが9割使用で
推移してて、仮想マシン立てるときCPUのオーバーコミットはともかく、メモリでそれはなしですよね。。。 >>610
初学者なんでいきなりそんな凝ったことをするつもりはないのですが、
先生！末尾にｗがついてます（汗 k3sでGOGC=10の環境変数設定と
--disable-cloud-controllerのコマンドライン引数を使うとまあまあのメモリ消費になる
Reduce master memory usage below 300MB
https://github.com/k3s-io/k3s/issues/1944#issuecomment-724413662
fresh install, default k3s RES=530M
with GOGC=10 & --disable-cloud-controller, k3s RES=310M
append traefik,cordns,metrics. total k3s cluster RES=500M みなさん、ご意見ありがとうございます。
とりあえず2GBのCentOS仮想マシンを2台たてて、K3sでクラスタ構成を作るところを目指したく思います。
で、ホストOS（Win10）でスワップしまくりなら、ダイレクト通販でノート買い換えてしまおうかと思います。 コンテナ コンテイナー
ディレクター ダイレクター >>615
なんでk3d使わないの？
Little helper to run Rancher Lab's k3s in Docker
https://github.com/rancher/k3d k3dしか使ったことないけど
k8sバリバリ得意なはずやで！
っていって信用するんか？ んなこと言い出したらkubeなんて会社の金でクラウドでやれという結論にしかならん
どうせ個人レベルじゃ何の役にも立たないんだし、就職には実務経験がない限りはほとんど当てにはされないだろう >>612
Windowsって、32bitバージョンだとしても、
何もアプリを動かしてなくて、デスクトップの表示だけで、
1GBも消費するよ ホストのドライブに書き込むのはどういう方法があるの
volumeでホストのディレクトリ指定できればいいのだけど
次点がネット経由でマウント >>621
k8sってOSと同じだけメモリ食うのかよ・・・
アホだな >>623
OSと同じというか広義のOSそのものだからな OSのコア機能はなくて、OSに含まれるサブ機能しか備えてないのに
1GBは多すぎでしょｗ Kubernetesはそもそも数百ノードを超えるような大規模クラスタが前提なんで、
マスターとワーカーを一台に詰め込むようなケチ臭い運用は想定外なんだよ
機能的にそんなにメモリが必要とは思えないのはまあわかるけど、開発者がメモリ使用量に対して無頓着なんでしょ Kubernetesと並んでメモリを大量に消費するバグが有るのがfluentdだな
ただサーバーの情報を取るだけなのになんで数百MBも食うんだアホ
インフラ系はメモリむとんちゃくなやつが多いな goで書かれてるのが要因だよね
速い以外はJavaと同じでは？
cとかrustみたいなgcのない言語で書いてほしい
railcarには残念 Goってそんなアホなん？
軽い速い堅牢って印象だったんだが違うのか 漏れのWindows 10 は、8GB メモリだけど、
Windows を起動するだけで、5GB 使う
本当に、それだけ使っているかどうかは分からない
単に、バックグランドのシステム処理用に確保しているだけで、
何かのアプリでメモリを使う時には、解放するかも知れない
Kubernetes の本などでは、ラズパイ数台でやってる スペック不足なんて金使って増強すりゃいいっしょなGoogle様の思想なんだから仕方ない クラスタくむのに１G２G喰うからだめとか、イヤ512Mで動くとか
アホの極みやな。桁がひとつ違ってるよｗ >>629
GoのバイナリがでかくなるのはOS（カーネル以外）と
重複するコードを多数持っているから
だけどメモリを消費するのはそのアプリが悪い >>636
断る。そんなどうでも良い事に何故時間を費やす必要がある？ Twitterオススメ
NGしやすい
変なやつ居ない
スキル高い人多い >>639
NGつうかミュート/ブロックしやすいから居ないのと同じ なので俺は真面目に正常なコミュニケーションをしたいならTwitter
後ぐされなくノビノビと何でもありのレスバトルしたいときは5ちゃんと使い分けてる ここは情報交換というより非常識な>1 にシステムを教えてあげるスレだろ？
Docker自体には大して関心が無いが、完全に間違った知識を上から目線で
他人になすりつけようとする原理主義者が気になるだけ。 Dockerホストとするなら、CentOS7系より、カーネルバージョンが4のCentOS8系の方がいいですか？
そのほうが、より新しい構成のコンテナを動かせそうに思う。
どうなんでしょうか。 8は今年の年末でサポート切れるけどそれでいいなら
KVMのホストなんかと違ってホストは塩漬けというわけにはいかないだろうから、Streamは辛いでしょ コンテナ専用機ならマイナーな軽量OS
そうでないならUbuntu安定
CentOSはオワコン
って感じかな >>643
RHEL8にしとけ
もしくはAlmaLinuxとかRockyLinuxなんかの、CentOSの代替品を使え CentOS8(RHEL8)だな。
そうなるとRedhatがdocker->podmanへの移行の流れを受けて
dockerがpodman-dockerに、docker buildがbuildahになるけど
それでいい気がするね。
コンテナランタイムとしてのdockerなんて総スカン食らってる感じがするし。 RHEL8使う理由ってなんかあるの？
CentOS8を使わない理由ならできたけどｗ podmanが普及してからでいいよ
例えばクラウドでpodmanネイティブで対応してから あといい言葉を教えてあげよう
どれでもいいなら、今のでいい その時の流行りに乗るのが1番
つまりKubernetes つまり Docker + Kubernetes ということ 良いというならクラウドでFargateとかGKEとか使うのが良いわな
自前でホストを用意する時点で趣味の世界だから好きにしたらいい パーフェクトRuby on Rails には、
毎週モジュールを更新してテストするように書いてある
こういうのが出来るのは、Ruby/Rails コミッターのいるような技術力のある自社開発系だけ。
普通の会社は、できた後は放置するだけw
一切、更新しない
会社全体で、AWS の800資格と、
全12資格を持つ、ジェダイマスターが7人いる、クラスメソッドの動画を見ると、
全部、Lambda などのサーバーレス
自社で毎週、OS・アプリ・モジュールなどを更新してテストできる、会社は無い。
だから、AWS がOS・Aurora などのデータベースなどを更新する、サーバーレスを使う
サイボウズのkintone は、Kubernetes で毎日すべてのシステムを破棄して、作り直している。
これが究極のTDD・継続的インテグレーション。
毎日、全システムをrolling update する。
こういうのは、普通の会社ができるわけない
AWS のAmazon Linux 2 は、yum, systemd を使っているので、
RHEL7 / CentOS7 と推測されている DockerホストのOSの話なんですけど、
カーネルのバージョンって大切ではないですか。
CentOS8はカーネルは3系だけど、Ubuntu18.04は、4系ですよ。
動かせるコンテナの幅も広がるのでCentOS8とUbuntu18.04との比較なら、
Ubuntuの方が良いと思うんですけど。
コンテナがホストのカーネルのバージョンに依存する以上、
カーネルのバージョンはDockerホストの命ではないかと思うわけです。
もし反論があればお願いします。 >>662
centos 7 がホストでも、ubuntu 18.04 コンテナが動かせること知らない…？嘘でしょ？！ 動作はしたとしても、トラブルが起きる可能性はあるようだが。 >>662
そう思うのであれば、それでいいんじゃないですか？
具体的に、Kernelの何が気になりますか？
（→例えば、ホスト側がサポートしているkernelの機能を何か削ってみて、Dockerコンテナ内で何かトラブルを再現できる例を作れますか？
興味があれば、やってみてくださいね。） >>664
ほんのごく僅かだと思うよ 安心せぇ ここに書き込んでるようなやつらには関係ない話や どうして、CentOSが推奨されますか？
UbuntuよりCentOSがDockerホストとして良いと言う合理的理由をお願いします。 >>663
カーネルバージョン4に依存するライブラリがあれば、CentOSがDockerホストの場合にはトラブルにつながるでしょう >>665
息の長いDockerホストのOSとしてなら、
カーネルバージョン4搭載のUbuntuが良いと思う。
もちろん、ライブラリがカーネル3に依存するものだけをコンテナで扱う限り構わないでしょう。 >>668
> カーネルバージョン4に依存するライブラリがあれば、CentOSがDockerホストの場合にはトラブルにつながるでしょう
自分で答え言ってるじゃん
カーネルバージョン4に依存するライブラリがなければトラブルは起きないって
あとは、カーネルバージョン4に依存するライブラリってあるんですか？って話だよ
ないでしょ？ 今は無くても今後トラブルが発生する可能性はあるってこと？
ダメじゃん いやテストしろよ
極論テスト通ってるなら何でもいいんだよ
テストしてないなら何でもダメ Dockerコンテナって特権コンテナにしない限り
カーネルの深い部分を直接触ったりできなくね？
しらんけど どうだろうね
とりあえず古いイメージが時々ぶっ壊れるのは経験した
コンテナとはいえちゃんとアップデートしろってこったな >>666
ただ安心しろ、というのは心配性には意味がない。
ま、心配性ならこのスレに何を期待してんの？って話だが。ｗ
新しかったら新しかったで、不安定さとか新バグとかもありえるわけで、世に心配の種はつきまじ。。。 複数仮想マシン実行時のホストOSリソースの話があったから、試しにメモリ8GBのWin10HomePCに
VMPlayerでCentOS7のゲストOS3台＋UbuntuゲストOS1台立ち上げたらカツカツだわ。当然だけど。
ちなみにゲストOSのメモリ割り当ては全部2GB。最小限でいろいろハンズオンするにも、最低メモリ16GB
積んだWin10ProのPCでやりたいところ。あとスナップショット機能やK8s用のツールが揃っているらしいので、
もしも私物PCでK8sまで独習するなら、無償版のVMwareWorkstation16Playerから10,764円でPro版に
アップグレードするのもありかもと思った。まあ3回飲みに行ったと思ってｗ
http://iup.2ch-library.com/i/i021195433415874311243.jpg
https://store-jp.vmware.com/upgrade-to-workstation-16-pro-5424179100.html >>676
でも、サポートが今年で終了
やる気ないもの >>668
4.xにしかないシステムコールするならそうやろうな
そんなのごく一部だと思うけどな^^ >>676
うん4系だね。
>CentOS8はカーネルは3系だけど、Ubuntu18.04は、4系ですよ。
そもそも3行目からして違っているから
この話は全く何の意味もない。
3系のカーネルの頃(centos7?)はDocker社にとって黎明期だから
まともに動かなかったとしても何の文句もない。4系以外は在りえない。 tiniの役目として孤立したゾンビプロセスを刈り取る機能があるらしんだけど
刈り取った場合と刈り取らない場合の違いってどうやったらわかる？ やっぱりわからない
tiniを使えば孤児になった時にリペアレンティングされて
tiniを使わなければリペアレンティングされない状況が観測できると思うんだが Ubuntu どうです反論君、あらわれなくなっちゃったね こんなエラーが・・・
journalctl -xe
１、level=warning msg="Your kernel does not support swap memory limit"
２、level=warning msg="Your kernel does not support cgroup rt period"
３、level=warning msg="Your kernel does not support cgroup rt runtime"
気にしなくていいでしょうか
１は心当たりがあって、swapを作成していないからです。
２、３、はなんでしょうか。 コンテナに割り当てられるCPUやメモリってどうなっていますか？
ホストに6CPUがある場合、docker runで起動したコンテナはいくつのCPUやメモリを使えるのでしょうか。 コンテナは仮想マシンじゃなくて、実際にただの1プロセスに過ぎない
だから割り当てるという概念は適切じゃないんだよ
アプリがCPUとメモリを使おうと思えば全部使えるのと同じように
コンテナも全部使える。それが最初にDockerがリリースされたの機能で
後から使用するリソースを制限する機能が追加された
Windows版とmacOS版では仮想マシンを使うという仕組み上
Docker Desktopの設定画面から仮想マシンに割り当てる設定があるけど
それはコンテナの設定ではなくてコンテナ全てに対する設定 docker-machine の存在意義がわかりません
非Linuxマシンならそれなりに需要ありそうですが、
Linuxマシンに対してなら、dockerを直接インストールすればよいですよね >>689
あなたがそう思うんだったら、それでいいのでは？
（わたしは、docker-machineを当然、使いますけどね!!） 同一コンテナ内で複数プロセスを動かすのと、
プロセスごとにコンテナを分けるのとどちらがメモリの使用量を抑えられるでしょうか。
プロセスはライブラリに依存するので、
同一コンテナで動かした場合にシェアされる場合にはメモリの使用量は比較的少ないと思います。
しかし、プロセスごとにコンテナを分けてしまうと、
シェアの可能性がなくなると思うので、ライブラリのロード分だけ使用量が増加すると思うのですが、いかがでしょうか。 このスレで１コンテナ＝１プロセス論争が始まるとは思ってもいなかった >>694
https://qiita.com/white_aspara25/items/cfc835006ae356189df3
自分で調べて結果だけここで報告してくれ。
unicor[n]の所をdockerかcontainerdに変えれば出る筈。
Mac/Winはdocker machineに邪魔されて見えないかもしれないのでホストはunixで。
後者だと思うけど（と言うかプロセスを保護したいから別コンテナに分ける） Ruby on RailsのDBマイグレあるじゃないすか
あれって、webコンテナの起動時にマイグレするのか、マイグレ専用コンテナを1回だけ走らせるのか、どっちがいいんすかね？ >マイグレ専用コンテナを1回だけ走らせる
の方が良いでしょ。
Webコンテナの起動時にマイグレーションは
Webコンテナの数を1個にすれば可能だが
当然単一障害点になる Docker板で単一障害点の話が出ること自体に違和感
そんな物が気になるなら、そもそもDocker使わないでしょ。 Docker使う使わないとは全く関係ない
Docker使わなくても、アプリを動かしてりゃ同じだし
アプリを多重化するなら、Dockerを多重化すれば同じこと dockerはdockerd自体が単一障害点だろ。 >>704
サーバーはサーバーが単一障害点だろって言ってるのと同じだなｗ オイオイ仕事の合間にチラ見してみれば、こんなミラクル馬鹿かよｗ
お前はpdomanとdockerの比較の話を何だと思って訊いてたんだｗ？
夜更かししてんじゃねぇよ。明日病院に行け。 諸先輩方のお知恵をお借りしたく。初心者で申し訳ないです。
Ubuntu20.04LTS環境のDocker(compose)環境で、NodeコンテナとPostgreSQLコンテナを立ち上げて、
Nodeコンテナ上のに配置したテストスクリプト（app.js)から、PostgreSQLのtestdbに接続させたいと思っていますが、
「connect ECONNREFUSED x.x.x.x:5432」となり接続拒否されます。ちなみにコンテナではなくPCローカル環境では
動作確認がとれているスクリプトになります。
.ymlファイルで、NodeコンテナからDBコンテナに接続できるようにするオプションってどんな指定でしたっけ？
Qiitaの記事をいろいろ漁りながら、enviroment項目をいろいろいじってみてるのですが改善できておりません。。
Nodeコンテナ内に入って、PostgreSQLコンテナにPingを飛ばすと普通に応答は帰ってきます。 PostgreSQLの設定の問題だろ
IPアドレスで外部からアクセスできるようになってない >>716
さっそくの回答ありがとうございます。ちなみにpg_hba.confの設定のことを言われてますよね。 ユーザーをuseraddとかadduserで追加すると、
システム内において何が変わりますか？
／etc／passwd、／etc／shadow、／etc／group、／home、
をボリュームで切り出しておきさえすれば、
ユーザー変更によるシステムの差分をコンテナ外で全部受けることができるでしょうか。
別のコンテナにそれらのボリュームをマウントすれば、
変更済みのユーザー情報が新しいシステムに適用されるようになればとても便利だなあと思ったんです。 >>718
etcの内容をマウントしようなんて思ったことない
だって必要ないし
Dockerコンテナのpasswd, groupはただのユーザID、グループIDとその名前の対応表（とホームディレクトリ等の追加情報）に過ぎない
Dockerコンテナ内でパスワードログインしないので、そもそもshadowは無意味
コンテナ起動時にボリュームをバインドマウントした場合、
ユーザーIDに対応するユーザー名や
グループIDに対応するグループ名が対応表に存在しなくてもlsした時に名前で表示されなかったり
chown等のコマンドで名前を使えないだけ
そのIDが別の名前になってたら別の名前で出るだけ
バインドマウントを行わなければ問題になることはない
特定ユーザー名が存在する事を前提にしたシェルスクリプト等があると
それをバインドマウント等で消すとエラーになるので
その点からもおすすめはしない 毎度毎度だな。>>1ちゃんと読んだか？
Dockerはアプリを作るもの
Dockerの中のアプリは特定のユーザーで動かす必要があるかもしれないが
それはホストや他のDockerコンテナとは完全に無関係
Dockerの中で閉じてなければ他のマシンで動かせないだろ
ユーザーなんて他のコンテナに見せるな 別に特定のマシンのためのコンテナがあってもいいだろ
リリースしやすく、環境を汚さず、破棄しやすいなどといったメリットは
特定マシン向けのコンテナでも変わらずに享受できる なら自分で招き入れた苦労は
自分で解決しろってだけの話だな そもそも分かるやつに聞いてるだけで
お前に聞いてるわけではないのでは？ それは運用指針として正しいが問題解決の面で正しくない >>715
それは、単なるネットワークの理解が足らないんじゃないのでは？
Qiitaの記事ではなくて、基本的なネットワークの理解が足りないだけだと思う。 >>716
Nodeコンテナ、Postgresコンテナともサービス起動時に172.18.0.0/16ネットワークのIPが割り当てられているので、
ご指摘のように、pg_hba.confを編集してIPv4接続用に「172.18.0.0/16 password」を追加すれば解決しそうです。
あとはいかにしてPostgresqlサービス立ち上げ時にpg_hba.confを編集してリスタートさせるかですが。。。
イメージをpullしてCOPYでconfファイル差し替えだと、PostgreSQL起動時のinitdb処理時に、dataフォルダ
(=pg_hba.conf格納先フォルダ）が空じゃないって怒られます。initdb処理後にconfファイルを上書きして
リスタートできないかとか、いろいろ足掻いてみます。アドバイス、ありがとうございました。
※ググると、ubuntuイメージをpullしてPostgreSQLを手動インストールしてconfを変更している事例を見かけますが、
できればPostgreSQL公式イメージに手を入れる対応にしたいところです。 あ、PostgreSQL側はcomposeで restart: always、tty: true指定にしていろいろ模索中です。 dockerコンテナでさくっと実験したいことがあるとき、
どこかに無料でDockerホストをいじらせてくれるサービスってないのかなあ >>732
自分のPCにDocker入れるんじゃだめなの？Win/Linux/Macどのプラットフォーム用のもあると思うけど。
ホスト環境をできるだけ汚したくないなら、フリーの仮想化ソフト入れて仮想マシンにDocker入れるとか。 >>732
自分でDockerホストを立てればよいのでは？
VPSでも何でもサクッと借りて、サクッと実験できるぞ。
しかも時間貸しVPSすらある。 まあ原理主義者は別名「管理人」とも言うからな。
そいつが執着するからこそ、スレが続いてい行く。
時に自演の質問→回答を繰り返し、涙ぐましい努力をしてだね・・・ 原理主義を名乗っていいのはGNU/Linux Debianだけ！ Windows 10 Home でも更新すれば、Docker を使えるようになった。
でも、メモリ8GB じゃキツイけど
ただし、Windows10の連続更新に、3時間掛かったけど Docker をシステムのように使おうとする香具師がいる。
いつも同じ香具師だと思う
Dockerはシステムじゃない。
システムは、Dockerの外にある
YouTube の、くろかわこうへいのAWS サロンに入れば？
月3千円で、Dockerも無料で教えるみたい。
400人が入っている
日本6位のKENTA のサロンの、AWS部活の大ボスも、来てるとか
Amazon の講習では、3日で21万円する > くろかわこうへいのAWS サロンに入れば？
あれ糞だった。あの内容なら800円一回払いぐらいが妥当 情報商材に金払うような愚か者はIT業界から足洗って田舎で農家でもやってろよ 勉強のためにサロンやってるわけじゃないだろう
雑談とか他者とのふれあいが大事なんだと思う
勉強は無料でいつでもどきでもできる
けれど人との繋がりは維持するのが難しい 情報商材屋が売ってる商品以外の方に価値があるとかいい出したら
潰れる前兆だって死んだばあちゃんが言ってた こんなスレでくろかわこうへいの名前を見るとは思わなかった
はっきり言ってあいつには騙されたと思ったよ
中身がまったくないうえに雑談と仲間内ネタで盛り上がってるだけ
まあ勉強代として諦めるけど 会社員は皆、3日で21万円する、Amazon の講習を受けに行く。
でも、何も身につかない。これが、本当の情弱w
楽天の百万円の講座を受ける会社員とかw
Shopify で作れば良いだけ
KENTA・くろかわこうへいを知らない香具師が情弱
それより、月3千円の方が良い。
KENTA のサロンは、月千円 普通会社で講習受ける場合は講習費は会社持ちだろ…？
どんな底辺で働いてるんだよ サロン()は詐欺だけど研修や講習は別に詐欺じゃないだろ… 会社の業務でDocker使うのに外部に勉強行く必要って何処に在るの？
まして訳の判らん奴とサロンで雑談とかｗｗ気味が悪い。
会社の業務は自分が一番良く知ってるだろ。Dockerの知識欲しいなら本を読めば良い。 >>749
会社がこぞって人件費を吸い戻そうとするド底辺、とか alpineだろ
パッケージを追加でインストール必要がないなら
busyboxもありだけど alpineはランタイムがな
互換性問題とかたまにあるし alpineのランタイムってなんことだ？
意味不明なことを言うなよ そのライブラリー必須なのかと思ってた Linux 動作させるのに 何だかんだで面倒臭いのがDockerって奴なんだな。 それはDockerをVMの代わりに使おうとしてるやつが
適してないことをしようとして面倒くさくなってるだけ dockerはdockerで違った面倒くささがある
どんなツールも得手不得手がある
当たり前だ Dockerが面倒くさいと言ってるやつは、
Dockerがどんな問題を解決するのかわかって無くて
ただのVMの代わりだと思ってるからだよ
サーバーにアプリを配布するのが楽になる
ということの意味がわからないやつがいる ホスト管理がめんどくさい
ボリューム管理がめんどくさい
セキュリティ対策がめんどくさい >>771
ホスト管理？ 何と比べて？
> ボリューム管理がめんどくさい
ローカルディレクトリに保存すればいいだけ
> セキュリティ対策がめんどくさい
何の検証もなしにサーバーにパッチ当てるんか？
Dockerだと検証済みのアプリに入れ替えるだけでいい ちょっと前の話だけどGKEもAutopilotでたし、本番に使わない理由がいよいよなくなってきたな。 なんのコストか言わない時点で
適当なこと言ってるってわかるやろ？ ここのスレで批判してるやつは GKE も ECS もそんな単語すら聞いたことないレベルしか居ないぞ >>778
クラウドで使う場合、無料でオープンソースの
Dockerを使うと、どこにコストがかかるんですか？
Dockerを使うのと使わない場合の
違いを言ってください 流石Docker原理主義者だなぁ・・・
無料でオープンソースのDocker以外のことは何も知らないｗｗ
・・・とツッコミを期待するネタだよね？
意味不明だけど面白いよ！ >>780
マネージドk8s と同じことをDockerを使わないで
どうやってやるんですか、まず話はそこからな
お前のターン、早くレスしやがれ >>780
答えられない、知らないなら、適当なこと言うんじゃなかったな
Dockerは単にアプリをデプロイしやすくするためのもので
マネージドk8sを使わない、単体の仮想マシンでも使えるって
気づいて逃げたか？ｗ いらんだろ。
レス見てあれ？変な事言ってるな？と思ったら大体同一人物だろ。 >>786
その同一人物をあぼーんするのに便利だから導入しようって流れでしょ？
このスレでことあるごとに粘着してくるいつもの奴とか消したらスッキリするよ いや。別にいらんな。
馬鹿を見抜くのもエンジニアのスキルだろ。
Linuxスレにﾜｯﾁｮｲ有無の議論なんか必要ないというのも同じ理屈。 >>788
ワッチョイは回線つなぎ変えたら変わるけど
どうやってあぼーんするの？
それっぽいレスを見かけるたびにNG登録していくの？ Docker使ったらマネージドk8sを使わないといけないって
思ってるやつってアホなのかな？ >>789
目に入るだけで邪魔だからあぼーんは有効だよ
>>790
変えられると言ってもある程度パターンあるからね ワッチョイはIPアドレスとユーザーエージェントから出してるから
回線つなぎ替えるたびに変えられるよ 運用するならマネージドK8S必須かな
開発環境は好きにすればいい マネージドK8S必須だとして、それをDockerを使わないでやる場合
どうやるのか？そっちの方がコストかかるだろって話なんだが
結局逃げたもんなｗ
クラウドでマネージドK8S必須、つまりクラスタ構成で
Dockerよりも金がかからない方法があるなら言ってみろって
例えその方法を出した所で、その方法＋DockerならマネージドK8S使わないから
サーバーへのデプロイが楽になる分、コストは下がりますねという反論が控えてるわけだがｗ Docker を NG ワードにしたらすっきりした これの話だってわかってないやつがいるのか？
> 771 名前：運用情報臨時板でワッチョイ導入議論中[sage] 投稿日：2021/03/09(火) 20:14:53.28 ID:Ui3x5dki
> ホスト管理がめんどくさい
> ボリューム管理がめんどくさい
> セキュリティ対策がめんどくさい 君が会話していると思い込んでいる相手はそんな話をしていない。 逆だろう。俺は最初からそいつとしか会話してないんだが
関係ないやつが絡んできてる 771を発端とした会話は772が既にお門違いで滑ってるがｗ >>803
どこがお門違いなの？
まずそこでしょう 何も言い返さないくせに
「お、お門違いだから（ふるえ）」はやめたほうがいいよ >馬鹿を見抜くのもエンジニアのスキル
って言ってるだろ？771がレス返さなくなったと言うなら、そいつは（多分）優秀だよ。
たった1回のやり取りで「あコイツと会話続けても無駄だな」と悟ったのだろう。 >>806
なんなら代わりにお前がレスすればいいし、他の誰でも引き継いでレスすればいい
誰も>>771の後を引き継がないのは、>>771に勝ち目がないからだよ 勝ちとか負けとか変なこだわりがある人がいるんすねぇ... 明らかにいつもの奴だしワンパだからレスバしても発展性ないんだよね
ワッチョイが待ち遠しい >>813
何がすばらしいのか解説してくれ。
長すぎて読むのが面倒くさい。 イメージレイヤーってすごいよね
複数イメージで共有してディスク領域や転送時間を節約できるし
いろいろ変更してもコンテナを立ち上げ直したら綺麗さっぱり消えるし はてぶでバズってたけど
https://sysdig.jp/blog/dockerfile-best-practices/
特定のUIDにバインドしない
↑
UIDをバインドしないとパーミッションで書き込みできないんだよなLinuxでは >>817
いいね。ベストプラクティスが広まればVMの代わりとして使おうとするやつも減るかも
これらのベストプラクティスはVMとして使えなくする制約に近いから
1. 不要な特権を避ける
コンテナを root で実行しないようにする
特定のUIDにバインドしない
実行可能ファイルを root が所有し、書き込み可能ではないものする
2. 攻撃対象を減らす
マルチステージビルドを活用する
distroless イメージを使うか、ゼロからビルドする
イメージを頻繁に更新する
暴露されたポートに注意する
3. 機密データの漏洩を防ぐ
Dockerfileの命令にシークレットや認証情報を入れないようにしましょう
ADDよりもCOPYを優先してください
Dockerのコンテキストを意識し、.dockerignoreを使用する
4. その他
レイヤーの数を減らし、インテリジェントに並べる
メタデータとラベルを追加する
lintersを活用してチェックを自動化する
開発中にイメージをローカルでスキャンする
5. イメージのビルドの先には
docker socketとTCP接続を保護します
イメージに署名し、実行時に検証します
タグの変異を避ける
環境を root で実行しない
ヘルスチェックを含める
アプリケーションの機能を制限する やっぱdockerならではのめんどくささってあるよな >>819
これが面倒って感じるんだな ほぼ Dockerfile だけなのに無知は恥だよ 「面倒くさい」には二通りの意味がある
1. 作業が面倒くさい
2. 作業を"効率化するのが"面倒くさい
>>819の意味は2番目 >Dockerfileの命令にシークレットや認証情報を入れないようにしましょう
ってDockerは単体でシークレット提供して無いじゃん。
何でdaemonで動いてる癖にdocker composeから使えるsecret提供しないんだ？ >>822
お前シークレットを何だと思ってるんだ？
アプリのバイナリの中に秘密情報入れないだろ
Dockerも同じでDockerイメージの中に秘密情報を入れたりしないんだよ
で、Dockerコンテナ（＝アプリ）起動時に、Dockerの外の情報に
環境変数やボリュームでアクセスできるんだから何の問題もない 訂正
Dockerコンテナ（＝アプリ）起動時に、環境変数やボリュームで
認証情報を含む任意の情報を渡せるんだから何の問題もない 馬鹿じゃないから黙らないし
何も言い返せないのはお前だ 何度もいうが匿名掲示板で馬鹿を見抜くのもエンジニアのスキル。
とっくの昔に概出なのに理解できてねーとか
マジなんでそんな馬鹿が生きていけるんだ？ 馬鹿って本当、大変だよな！一人でシコシコ自己満足のプログラムばっかり作って悦に浸ってるんだろうｗ
チーム開発なんてやったことも無いんだろうねｗ な？「言い返してない」の部分を見なかったことにしてるだろ？ ヒントは概出。
ちゃんと過去を遡れば話は出ている。
馬鹿には理解できないだろうけどｗ
・・・俺って優しいな！771とか馬鹿発見したらレスしないもんなｗ
カネも貰ってないのに手取り足取り教えてあげたしねーけどｗ
お前のレスは大体一発目で「あ、この人現場で作業してないな」ってのが透けて見えるんだよｗ
その癖謎の上から目線だから、ただの馬鹿にしか見えないｗｗ
本当、馬鹿ってどうしようもないよな！ UIDを指定できるようにするべきだね
そんなのWindowsだったらはまらないけど
Linuxで動かすときにボリュームマウントしたときにファイルの編集ができないカラ >>820
いや面倒だろ
そのぐらい自動でやってくれ
～～を気にしながら書かないとダメなんてのはすべてめんどくさい >>837
じゃあそのまま時代遅れの老害で居てください笑 特定のUIDにバインドしないってどういうことだ
まいかいランダムにUID決めるってか？ >>837
メンテナンス性を気にしながら書かないとダメなんてのはすべてめんどくさい
ってお前言ってるだろ？ｗ >>840
https://sysdig.jp/blog/dockerfile-best-practices/
> Openshift はデフォルトでは、コンテナを実行する際にランダムな UID を使用します。
「Openshiftは絶対に使わない」ことが保証されているなら無視しても良いかも知れない YAGNI
Openshiftへの対応が必要になることはない OpenShiftなんか非対応で結構、むしろ積極的に非対応にすべき
IBMがオンプレや自社クラウドで顧客を囲い込むためだけに存在する有害な技術だよ dockerHubにあるApacheとかnginxのイメージって最初からroot以外で動いてるよね？ UIDの話はDockerの問題じゃなくてOpenShift特有の問題 Why do my applications run as a random user ID?
https://cookbook.openshift.org/users-and-role-based-access-control/why-do-my-applications-run-as-a-random-user-id.html
プロジェクト固有のUIDを割り当てる事で
マルチテナント環境でも
他のアプリのデータが読める事が無いようにって事らしい
そんな事はあり得ないなんて思われがちな
他のセキュリティ対策が破られるという想定外を想定するのがレッドハットなんだろう
A Guide to OpenShift and UIDs
https://www.openshift.com/blog/a-guide-to-openshift-and-uids
イメージに予めファイルやディレクトリを入れる時に
アプリが読み書きするファイルやディレクトリはrootグループに所属させる
rootグループに所属してるユーザーなら読み書き出来るようになるので、
UIDがプロジェクト固有のランダムIDでも問題ないって事らしい
それだとroot所属してる他プロジェクトのユーザーも
読み書き出来ちゃうんでは？って思うけど
新しく作成するファイルはグループIDが0（root）じゃなくてそのユーザーIDと同じグループIDになるんじゃね？
しらんけど テナントごとに異なるUIDが割り当てられればいいだけであって、別にランダムにする必要はないよね
むしろランダムにしたせいでうっかりかぶっちゃいました、ランダムなのでテスト見逃しましたみたいな変なミスしそう root を取られないように、
UID に、1,000 を足すようなシステムがあったような
1 → 1,001
2 → 1,002 >>849
IDの範囲をテナント別で衝突しないように割り当てるんじゃね？
しらんけど >>849
他のテナントのUIDが推測できればそれを攻撃に利用できる可能性もないとは言えないからでしょ >>852
OpenShiftはランダムと言ってますが、それはコンテナごとに
違うという意味で、実際には推測可能なUIDが割り当てられます namespaceを作るとUID、GIDの範囲が自動的に割り当てられ
同じnamespace内のポッドは同じUIDとグループIDになる
これによって他のnamespaceやホストマシンで動いてるプロセスが使用してるファイルなど、
無関係のファイルを読み書き出来てしまうのを防ぐ
何も指定しないとUIDとGIDは範囲内で使える最初の値になるようだ
だから同じ名前空間内のボリュームだったら
どのポッドも読み書きできるね podがどうのこうのと言っている時点で既にDockerの話じゃないんだけどな。
不特定のnode, podに対してUSER指定させたらマルチテナント環境でバッティングするから
ランダムにしよーぜなんてのはDockerレベルで考える事じゃない。 今話をしてるのはUIDの話であって
USER指定の話ではない >>6
Chromeでもエラー出るようになったｗｗｗ >>859
それを判断するのは、お前がDockerを使わない場合に
同じ問題をどう解決できるかを言ってからだ
早くレスしてくれ ほらな？逃げただろ。こいつは反論が一切できない。
なぜならNGにして見えないからだｗ
まあ実際は見てるんだろうがな
だから実際には反論できないというが正解 >>855
ランダムUIDは万が一コンテナのサンドボックスが破られてホストに侵入された時のためで
ファイルの所有者がバッティングするからどうこうではない ランダムなら何度も繰り返し攻撃したらそのうち通るんじゃね この流れでコンテナのサンドボックスが破られるぐらいなら
最初からDocker（コンテナ）を使わずに、サンドボックスの外で
直接動かせばいいとか言うんだろうなｗ OpenShiftのためだけにUID指定するながベストプラクティスってやべえな Dev image作る人
Ops image使う人
☝あってる？ >>867
あってる
ただしDevが作るイメージとは自分たちで開発したアプリのイメージ
自分たちで開発してないアプリ、オープンソースなどは
Docker公式や開発公式が作ってることが多いので
そういうのをイメージする作業は開発とは言わない
アプリ開発の一環としてDockerイメージも作る Introducing fixuid: Tool for Changing Docker Container UID/GID at Runtime
https://boxboat.com/2017/07/25/fixuid-change-docker-container-uid-gid/
One of the most helpful things about using Docker containers for development is that it reduces developer onboarding time from a few days to a few hours or less.
Developers are able to clone a repository, start a container or run Docker compose, and start contributing immediately.
Development containers are often very different from production containers.
They usually include package managers, build tools, SDKs, remote debugging, and more.
Source code can be mounted into the development container via a host mount and changes can be immediately re-rendered via live-reload build tools.
This is where the road gets bumpy – Docker containers run as a single user. Users/groups, UIDs/GIDs, and file ownership must be decided when an image is built with docker build.
Host volumes, however, are owned by a user on the host and the host user's UID may or may not match the container user's UID.
There's an issue in the Moby repository with over 100 comments about this very topic.
Host volumes are mounted using bind mounts in Linux.
There is no way to remap UIDs/GIDs using bind mounts so often development containers end up with a mismatch of UIDs/GIDs.
This is why we created fixuid, a tool to change a Docker container's user/group and file permissions that were set at build time to the UID/GID that the container was started with at runtime.
To explain how fixuid solves this problem, let's take a look at a story about Alice and Bob, who are both developers working with development Docker containers. nix使ったらDockerイメージのマージはできないけど
nixのパッケージ使ってDockerイメージ作れば似たような事は出来るね
使いたいCLIツールのパッケージが依存してるランタイムのバージョンが違ってても共存させる事が出来る
No dependency hell
ビルド時にだけ必要なパッケージと
実行時に必要なパッケージが明確に区別されてるので
要らない一時ファイルを誤ってDockerイメージに含める心配がない
nixpkgsのパッケージが豊富だし
無くても自分で書けば良い
GitHubで自作パッケージを公開し、ビルド済みバイナリをcachixに置いておけば
複数のプロジェクトから再ビルドせずに使い回せる
https://mao.5ch.net/test/read.cgi/linux/1597591176/98
98 login:Penguin sage 2020/08/28(金) 11:22:41.35 ID:0ih4XZ3G
イメージのマージ機能はいつになったらサポートされんだ
devcontainer作るときいちいちインストール方法調べてDockerfile書くの不便なんだが 前にも言ったと思うけど
俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね
Container imageってアイデアは失敗だった 一応nixにもnixパッケージ使って隔離されたNixOS環境を作る
nixos-containerってのがあるがDockerみたいに完璧な隔離ではないらしい
nixos-containerの隔離が完璧になって
自前のバイナリキャッシュも
ローカルのnixストアみたいにGCで最小構成で保存出来たら
Dockerみたいに使えるかも あらゆるCLIツールがnixでインストール可能になれば
開発環境ではnix-shell使って
本番では必要なパッケージを一つに固めたDockerイメージをk8sとかで使うってやり方が実現できる
そんな世界をまず目指そう そうじゃなくて
開発も本番もパッケージはホストにインストールするんだよ
で本番はコンテナにパッケージを読み取り専用でマウントすんの
全部固めたイメージなんてものは要らない >>871
> 俺らが本当に欲しかったものってdockerじゃなくてスマートなパッケージマネージャ(とリポジトリ)なんだよね
パッケージマネージャーだけだと
実行するときの分離ができないだろ
「俺らが」じゃなくて「お前が」欲しいものはパッケージマネージャーなので
Dockerでパッケージマネージャー相当のことがしたい
できないのは苦痛だなどと言わないように
お前の目的にあってないのよ
Dockerは開発者が自分で作ったアプリを
デプロイするためのツールだって何度も言ってるだろ それをやろうとしてるのはnixos-containerじゃね
コンテナ起動時にパッケージへのシンボリックリンクを動的につくるか、
PATHをパッケージの絶対パスで埋め尽くせばDockerでも行けそう
後はバイナリキャッシュのバイナリだけを利用するとか、実行時に必要なパッケージだけをダウンロードするモードがnixにないとか
その辺がなんとかなれば
本番で不要なビルド用パッケージを落としたりソースからビルドとかしたくないし
nix expressionの評価が遅いって問題もあるが
それはnix flakesで解決しそう
dockerTools.buildLayeredImage使えば
パッケージ毎にイメージレイヤーを作ってくれるので
ストレージ効率は良い
ただ、Dockerのレイヤー数は128までなので
それを超えると最後の方のレイヤーは合体される
これも最後のイメージレイヤーは各パッケージへのシンボリックリンクになる
ビルド用パッケージは除外されるし
現状では最適解 >>874
なんでパッケージマネージャーが欲しいやつがDockerなんて使おうとするんだろ？ｗ
例えばapacheのDockerイメージ、nginxのDockerイメージ
どちらもポート80で起動する
というDockerイメージを、同一のホストで複数起動する場合どうすればいいのか？
Dockerイメージを変更すること無く、待受ポート番号を変更するにはどうすればいいのか？
それができるように作られたのがDockerなんだが
ファイルを置くだけのパッケージマネージャーじゃこんな事はできない
実行時のプロセスの分離を行う仕組みが必要 >>875
実行する時の分離はできるだろ
コンテナに読み取り専用でマウントするだけ >>877
nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ 独自のコンテナランタイムとか作らないってこと？
今使ってるコンテナのイメージレイヤーは削除出来たらだめって挙動をパッケージでやるのは
独自のコンテナランタイム作らずには難しくね
今コンテナで使ってるパッケージを削除してしまったり
逆に古いパッケージが消えないってなりそう >>879
> nginxのパッケージを入れて2つの隔離されたnginxプロセスを起動するだけだろ
パッケージを１つだけ入れて２つのnginxプロセスを起動したりしたいんだよ
それもnginxの設定を変更せずに Dockerとパッケージマネージャーは使う目的が全く違うんだから
パッケージマネージャーが欲しい人がDockerをパッケージマネージャーの代わりとして使って
「Dockerはパッケージマネージャーで代用できる！」なんて適当なことを言わないでくれ
それはお前がDockeをパッケージマネージャーという
間違った用途で使ってるだけだ 作るとしたらこんな感じだろうな
デベロッパ
myapp:
name: MyApp
version: 2.0
packages:
- ruby == 3.0.0
- hoge.com/hoge-cli == 1.2
files:
- src: ./src
dst: /myapp
volumes:
- name:myappvol
path:/var/myapp
envvars:
HOGE: fuga
entrypoint: /myapp/bin/myappentrypoint.sh
godpkgmgr push . https://my.repos.com
//メタデータとfilesがリポジトリに送信される
ユーザー
godpkgmgr run MyApp:2.0 -v ./tmp:myappvol
//rubyとhoge-cliがローカルにあるなら再利用なければpull
//MyApp:2.0のfilesとメタデータをpull
//コンテナにpaclagesとfilesをマウント、メタデータを設定、entrypointを実行
な？
image要らんだろ ただの設定ファイルの形式変えてるだけじゃん
イメージいらないって、イメージなくしてどうやって起動速度上げるのさ？
どうやって全く同じイメージだと保証できるのさ？
同じ設定ファイルから作ったとしても一年後にやって同じイメージが出来る保証はない 済まない
↑のリポジトリのURLは適当に架空のURLを書いたつもりだったが存在するドメインだったので無視してくれ あとrubyしか書いてないけど、ディストリに含まれる
全てのライブラリのバージョンも書かないと駄目だろｗ >>884
ファイル形式を変えてるだけじゃない
パッケージを分離してる
イメージは必要ない
必要なのはパッケージ、メタデータだけ >>886
rubyに必要な依存はrubyパッケージのメタデータに書く 多数の仮想マシンに同一のイメージを配布することは出来るが
多数の仮想マシンに設定ファイルから一からインストールするなんて時間かかるし
すべてのファイル（OSに含まれる全てのファイル）を、そのリポジトリとやらに
アップしてそれをダウンロードして使うってならそれがDockerのイメージの仕組みです
としか言いようがない メタデータから再インストールするのは
時間がかかるって言ってます。
完成済みのファイルをコピーしたほうがずっと速い
それがイメージ >>889
dockerとの違いはイメージに固めないこと
これによって同じパッケージを使うアプリでパッケージ共有できる
ディスク容量や通信時間を大幅に節約できる >>890
重複を避けて少量のファイルをpullしたほうが速い
imageだと同じパッケージを使ってても別のimageと認識されるから無駄が大きすぎる パッケージだけあったって、インストールの順番で
出来上がるものは違うだろうが
あとからnanoをインストールするのと
あとからvimをインストールするので
同じものが出来ると思うか？ > 重複を避けて少量のファイルをpullしたほうが速い
だからそれがイメージ >>893
インストール順番に依存しないようにするための賢いパッケージマネージャだろ
Dockerfileは手続き型だから順番を気にしないといけないがnixのような関数型のパッケージマネージャならそれを克服できるというわけだ パッケージだけあったって、同じイメージは作れないんだが？
インストール済みの状態のファイル＝レイヤーが必要 nixのような関数型のパッケージマネージャは
バージョンごとに複数のパッケージをインストールするというだけ >>894
imageでは重複をうまく回避できない
RUN xxx
RUN apt-get hoge
RUN yyy
RUN apt-get hoge
たったこれだけで別物と見なされてhogeの重複ダウンロードされる
これじゃ効率が悪すぎる そしてnixのような関数型のパッケージマネージャは
ポート番号を変えて起動とかしてくれない
Dockerの目的をパッケージマネージャーは満たしてくれてない >>896
パッケージバージョンを完全に指定すれば同じ >>898
> たったこれだけで別物と見なされてhogeの重複ダウンロードされる
nixのような関数型のパッケージマネージャも
バージョンが異なれば重複ダウンロードされる >>901
「パッケージマネージャー」に起動時のオプションを変更する機能があるんですか？ｗ >>902
imageの場合はバージョンが全く同じでも重複
パッケージマネージャはバージョンが同じなら重複ダウンロードしない >>903
いやいやそうなるように作るべきって話だろ
今はまだ無い賢いパッケージマネージャの話をしてんだ nixはbrewやyum, apt-getみたいなのじゃないぞ
nixはパッケージマネージャーの皮を被ったビルドツールだ
ビルド結果をS3に保存できるのはバイナリキャッシュ機能のおかげ
ビルド時のフラグや依存関係などを利用して生成したユニークIDを自動的にパッケージに付ける
少しでも設定変えればIDも変わる
パッケージはみんな/nix/storeの下に入る
/usrを直接変えるような事はしない
使う時は各パッケージの/binにsymlinkをはる //docs.docker.com/compose/compose-file/
compose.yml っていうファイル名が 1.27.0+ から使えるらしいんだけど、1.27.4 の環境で読み取ってくれない
1.27.0+ の + って以上って意味じゃないのかな
ﾜｯﾁｮｲあったほうがいいと思ってたけど、age てるやつを NG すれば問題ないことに気付いたよ >>906
nixは「パッケージマネージャー」
起動時にポート番号やボリュームディレクトリを変更したりする機能はない 機能を追加すればいいだけ
というか実行に関してはdockerでいいかもね
パッケージマネージャが管理してるディレクトリをマウントするだけだから パッケージマネージャーにない機能
パッケージマネージャーとは関係ない機能を追加して
Docker相当のものを作るってことは
本当に欲しかったものはパッケージマネージャーではないということだろう >>911
「パッケージマネージャが管理してるディレクトリ」＝Dockerのイメージ
「パッケージマネージャが管理してるディレクトリ」に
OS標準コマンドも入ってるんですか？入ってませんね。
Dockerの劣化版
まず「パッケージマネージャが管理してるディレクトリ」に
カーネル以外のすべてのファイルを入れることから始めましょう Kubecost raises $5.5 million to help teams monitor and reduce their Kubernetes spend
http://blog.kubecost.com/blog/announcing-kubecost-first-round/ すまんが、ユーザーにビルドの権限だけ与える(実行権限なし)ことってできないんかな？ >>917
ビルドマシンと実行マシン分けたらいいだけじゃね？ docker in dockerすれば
VMを使った牢獄の代わりになると思う GitHub Actionsとかで自動ビルドすれば >>917
ビルドツールを実行させずに
ビルドさせたいってこと？
無理じゃねｗ >>917
ビルドはJenkinsとかにやらせてユーザーが出来るのはJenkins上のWebボタンを押すことだけで良いんじゃね 山浦清透、1/15
Docker超入門講座 合併版 | ゼロから実践する4時間のフルコース
https://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 スレチであれだけど、最近よくマスコミや政治家が言ってる「デジタル推進」
とか「デジタル改革」って言葉の意味がわからなくて困惑してる。
たぶん、情報技術(ソフト・ハードとも)を使った各種処理の効率化・省人化
を図ったり、新たなサービスの創出で社会を活性化させたり、セキュリティ面
の強化とか、そういうことが言いたいのかなぁって想像してはいるんだけど。
でもそれだったらIT革命とかIT推進とかIT庁の方がまだ意図が見えるような。
別にアナログ技術だから不便・遅れているってわけでもなかろうに。 IT を広い意味で使うと何もかもが it になりそう製造業も情報からだよねっと
そして誤爆かなと思っております docker-machineってメンテ止まってる？
もう使わないほうがいいのかなこれ docker-machineは使う理由がなくなったよな
あれは、リモートにdockerサーバーがある場合にそれを操作するもので
・どっかのクラウドがdockerサーバーを提供しててそこにつなぐ
→ローカルでやるしなぁ
・Windowsで仮想マシンに入れたDockerにつなぐ
→Docker for Windows使うから仮想マシン使わないしなぁ
こんな感じで使う理由がない
まああれ単に接続先の環境変数を変えるだけでしょ？
メンテ終わっても使えるとは思うよ 別に過疎ってるわけじゃないけどな。
スレチに答えてもしゃーないってだけ。 >>930
たかが2chの一スレから判断しようとすな！ https://trends.google.co.jp/trends/explore?date=all&;geo=JP&q=docker
まあ、Dockerが徐々にオワコン化しそうなのは、その通りだけどね。
結局面倒臭い割には解決できる問題が限定的すぎるるんだよ。 >>933
いやいや、一つだけじゃ何の比較にもならんやろ
別の単語入れて検索せーや でも結局個人開発で使うんならDocker一択でね？
ほかはビジネス用ばっかだし >>935
ないよｗ
Googleトレンドなんて検索キーワードの数なんだから、普及すれば減るのは当たり前
Linuxなんて完全にオワコンじゃんｗ
https://trends.google.co.jp/trends/explore?date=all&;geo=JP&q=linux >>934
何かと比較じゃなくて時系列ね。
最も話題になったのは去年の今頃って話。
話題の最盛期に比べて今は7割。
これといって素晴らしい機能がリリースされた訳でも無し。 >>936
個人開発するならそもそもコンテナ化の必要がない。 VM用意すれば心置きなくいじくりまわせるよねｗ
余計な知見（）なんかいらないしｗｗ 再現できるVMをつくるのはいがいとめんどい。
Dockerだとらくちんちん。 まぁVMはシステムだからなぁ
1プロセスしか面倒見切れない人はDockerでいいと思うょ >>943
その理屈だとこうなる。ｗ
× 1プロセスしか面倒見切れない人はDocker
○ ヒマ人はVM
実際は臨機応変。 >>938
だから検索数じゃ何がオワコンか判断できないって言ってんの
Linuxみてみろよ。大幅に検索数減ってんだろうが >>939
個人開発とコンテナは全く関係ないとみんなが知ってる中で、
個人開発とコンテナを結びつけてしまった時点で
あんたが理解してないだけってみんなわかってしまったわけだがｗ >>939
仮想マシン（VM）の中でコンテナを使うっていう
使い方をするのがほとんどなんだが、わかってないんだよな
まあ多くの人はわかってると思うけどね。
だから検索数も減ってるわけで >>945
30年の歴史が在るLinuxと6年7年の歴史しかないDockerを何故同じと看做す？
linuxだって89年代初頭は検索があれば右肩上がりだったろうよ。
Dockerはそこまで枯れてない。WSL2が出たことすら最近。
この状態で減ってるのはヤバイだろ。
>>946
いつものお前だよな！相変わらずコミュ障だな！
病院行けって言ったろｗｗ>>936で個人開発とDocker（コンテナ化）を結びつけて話してるのに
お前だけが日本語を理解してないよなｗｗｗホント、不思議な解釈するよね！
話しても時間の無駄だから、お前はもうレスするなよ！ >>948
> 30年の歴史が在るLinuxと6年7年の歴史しかないDockerを何故同じと看做す？
だから、最初に言ったんだろ。
何と比べてるんだ？一つだけじゃ何の比較にもならんやろって Ruby on Rails では、
WSL2, Linux, Node.js(Webpack, Babel), Docker Compose, CircleCI,
VSCode(Remote Container, Remote WSL)、データベース
さらに最近は、AWS Fargate, Terraform, React, Vue.js
Docker Compose までが学校の初心者コース
もし、どこかの学校が新技術を採用したら、
競争上、他の学校も採用せざるを得ないから、
どんどん未経験者の技術力が上がっていく
今では、1年の未経験者が10年以上のプロよりも、技術力が上になってる！ 初心者は皆、YouTube で有名な雑食系エンジニア・KENTA のサロンとか、
AWS のくろかわこうへいのサロンへ行くから、
AWS Fargate をやる
だから、EC2 もいらない。
サーバーレス。OS レス
OSの事は、何も知らない 開発もqiitaのコピペだしな。何も知らなくても大丈夫だよ 活字を読むのはネットの記事だけという奴らの日本語は酷いよ
外人並み >>950
マジで言ってんならエンジニアやめたほうがいいよ 久々に開発したらdocker-composeがdockerに取り込まれて不要になっとった いつからだろね
知らんけど
もしかするとdocker for winだけかもわからん Linux dockerで動いてるコンテナがdocker for winで動かんなんでやろ
最新版にうｐｄしたんやけどなー
久々だと感どころが働かへん…今日は残業かなー なんかまだプレビュー機能っぽい気がする。バグもあるようだ。
だから正式にアナウンスされていない。
https://github.com/docker/compose-cli/issues/1149
Windows版とmac版？で本来まだでてはいけない
「docker composeに乗り換えれ」というメッセージが
出てしまっているという話に見える 新しい docker compose について
https://docs.docker.com/compose/cli-command/
The compose command in the Docker CLI is currently available as a Tech Preview.
We recommend that you do not use this in production environments.
意訳 テクニカルプレビューだから実環境で使用すんな docker composeのバグか？
でもdocker-compose upにしても961動かんなぁ
Linuxでやるかしゃあない(;´д｀)ﾄﾎﾎ… Windows版のDocker Desktopを3.3.3にアップデートしたら
docker-composeのバージョンは 1.29.1で、docker-compose（引数なし＝up）で実行したら
最後らへんに Docker Compose is now in the Docker CLI, try `docker compose`ってでるようになった
次リリースされる 1.29.2 ではそのメッセージが削除されてるよ
https://github.com/docker/compose/milestone/59?closed=1
の Remove advertisement for docker compose from up
if not IS_LINUX_PLATFORM:
print('Docker Compose is now in the Docker CLI, try `docker compose up`\n')
Linuxプラットフォーム以外ででるメッセージのようだね >>964
docker-composeの話だから、コンテナの問題は関係ないだろうね
export DOCKER_BUILDKIT=0
しておくとするといいかも。Windowsの環境変数設定の方法は知らんｗ
docker composeはdocker-composeのエイリアスじゃなくて別実装っぽいな Windows 10, WSL2, VSCode の拡張機能・Remote Container では、Docker Compose
プロジェクトルートの.devcontaner/docker-compose.yml >>967
wsl2実装でextアクセス出来るの？ まだどっかコンポーズ取り込まれてなかったんだ久しぶりに見た見に来た 前から疑問だったことがあります。たとえば
task_a.py、task_b.py、task_c.py、、、
というpythonスクリプトが複数あったとします
docker-compose.ymlでそれらを管理実行するときに
①
task_main:
＿command: python task_a.py arg1 arg2 && python task_b.py arg3 &&
みたいにまとめるのか、それとも
②各スクリプト毎にserviceを用意して
task_a:
＿command python task_a.py arg1 arg2
task_b:
_command python task_b.py arg3
みたいにするのか
どちらがいいのでしょうか？ ついにDockerfileが複数行のRUNをサポート
随分時間かかったなぁ webアプリをDockerコンテナ化したいんだけど
コンテナ向きのディレクトリ構造とか調整みたいなのあったりすんの？ >>968
Udemy の山浦清透の動画ある。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 windowsでdockerを使いはじめました
docker pullでイメージをダウンロードしようとしているのですが
回線が不安定なためダウンロードの途中で切断が起きます
一度切断が起きると何故かダウンロード中のファイルの最大サイズが減り、
ダウンロードが終わってもunexpected EOFというエラーが出ます
dockerのダウンローダーが回線切断にうまく対応できていないようなので、
リジューム対応のダウンローダーで前もってファイルをダウンロードしてから
dockerに組み込めばいいのでは？と思いました
そういうことはできるのでしょうか？ >>976
単なるtgzファイルだからマニフェスト見て自分で全レイヤを揃えてやればできるけどクソ面倒臭いと思うよ
そんな環境でどうせまともに開発できるわけないんだから無駄な苦労で時間を無駄にするより通信環境を改善すべき >>976
内部サーパーを立てたら？
それ用の設定もあるし、そうでなくてもプロクシを立てたら？ >>976
回線をどうにかしたほうがいいんじゃない？ 回線が不安定ってどれぐらいのもんなのかなアナログ回線的な感じか遅いの どうせ、タコ足配線された光コラボとか、マンション系LANとかで、
激遅回線なんだと思う。 無線LANなんか切れるときには切れるやろ。
しゃあない。 SoftBankAirとかモバイルWifi系も受信状況悪いとまぁひどいぜ docker install するときcnfigでHyper-v欄が出ないんですけどなんでかわかりますか？
Hyper-v の有効/無効の切り替えは4,5回再起動でやり直しました。 >>987
コンテナイメージはデプロイ先の環境とは別の場所で管理したかったから、GitHubだけで手軽に使えるのは助かるわ
やっとECRを捨てられる すみませんk8sに詳しい方に聞いてみたいことがあります。
VMware Workstation Player 16でUbuntu20.04を2つ立ち上げてマスター、ワーカー役にして、
小さなk8sクラスタを組んで各種kubectlコマンドやコントローラの作成、ゆくゆくはCI/CDの真似事を
してみたいと思ってます。（つづく1/3） 当面のゴールはngix、node+サンプルアプリ、DBMS(Postgresqlならベスト)のpodを立ち上げて、
Ingressによりサンプルアプリページを公開し、3つ目のUbuntuのブラウザで見られるところまでと思います。
現状ネット記事などをもとにnginxのreplicasetを２つ立ち上げて、Welcomeページを見られるところまで到達。
http://iup.2ch-library.com/i/i021419699615874911269.jpg
http://iup.2ch-library.com/i/i021419700715874011270.jpg
（つづく2/3） このあと、できれば簡単なWebDBシステムのdeployment群(WAS、APP、DB)を立ち上げてみたいのですが、
nginx+app+RDBMSのサンプルアプリによるハンズオン教材や、参考になりそうな情報って心当たりあります？
いくつかマッチするWeb連載があったものの、pullするイメージが非公開になってたりnoSQL系のＤＢだったり、
udemy講座もさがしてみたものの、よさげなのはminikube前提だったり。なにかヒントもらえた嬉しいです。
https://www.udemy.com/course/web-application-with-docker-kubernetes/
（おわり3/3） あ、このスレは何番踏んだ人が次スレ建ててるんですか？ https://kubernetes.io/docs/tutorials/で十分じゃね
仕事でEKSは多少齧ってるけど、DBはkubeじゃなくてRDS等のマネージドサービスでポチるのが普通だと思うよ >>993
おお、AWS利用されてるのですね。業務で使いだすとマネージドk8sって耳にします。
個人学習ではなかなかハードル高いですが。。。あとURLありがとうございます！ AlmaLinux なんかのDockerイメージってもう配布されているんですか？ 試用期間中に開発アプリのdocker環境構築ができなくて首に(´；ω；｀)
docker経由でRDBに何か入れたりするのが上手く行かなく、簡単にするものじゃなかったのかと。。。 日本では試用期間中の解雇や本雇用拒否は重大なスキルや経歴の詐称でもない限りそう簡単にできるものではない
Docker未経験と伝えて採用されたなら労基案件だろ 首になった本当の原因がdocker環境構築できない事なのか考えた方がいいな 台湾パイン買ってきて食べてた・・・
>>998
すんなり行けばチュートリアルのコマンド5回くらい貼るだけで構築できる（事になってる）としか思えないので、用意した人の不手際かと。。。
首というか、この辺り自主学習してまた連絡ください的な感じですね(´；ω；｀) このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 221日 1時間 21分 20秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
