Docker Part5

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/

>>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

単にパッケージのバージョンを指定すると、そのうちパッケージがリポジトリから消えてビルド出来なくなる

古いバージョンのリポジトリを使うなら可能だが、マイナーバージョンのアップデートはされるだろう

特定のパッケージだけ最新メジャーバージョンにしたいから
複数のリポジトリを使い分けするぜ！みたいな使い方は
一応可能らしいが、
公式にはサポートされてない

もっと気軽にDinDできればいいんだが

>>388
古いリポジトリがアーカイブされている必要もあるし、
結局、Debian、CentOS（8以前）とか、硬派なバージョン管理をしているdistroを使うしかないと思う。
そうでないと、ABI互換されへんしな。

>>389
気軽にできないってことは使い方が間違っているということだよ
何に使ってるのさ？仮想マシンを使えば？

k3dはdocker in dockerのReal world example
中で起動するのはdockerじゃなくてcontainerdだけど
docker in dockerと同じパターン

コンテナの中でk3sやcontainerdを動かす

ん？だからk3dに相当するようななものを作ってるの？って話だよ
そういうのは例外的なシステムだよね

>>389はCIで欲しいんじゃね？
知らんけど

だから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は「動的に変えたい」は間違った解決策である可能性が高い

「いちいち組み合わせごとにビルドしてらんない」ならば
組み合わせごとにビルドできるようにするのが
本当に解決すべきことで、その手段は他にあるだろうって話

おいおいどんだけ巨大なimage作る気だよ

例えば
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イメージのビルドって単にファイルをコピーするだけだぞ
お前の言うファイルの入れ替えと何も変わらん

>>417
Dockerエアプかよ
ビルドする事はあるだろ

https://github.com/aws/amazon-eks-pod-identity-webhook/blob/ed8c41fcc820e2ec84ec2a7faff879eab4db65d3/Dockerfile#L5

>>416
違う

>>417
変わる

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
無断転載禁止

プログラマの雑談部屋 ★128
https://medaka.5ch.net/test/read.cgi/prog/1610960220/655

>>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の順で入れるのでは結果イメージが同一でも別物

マルチステージの動作確認ってどうしてるの？

>>437
それ結局1000容量必要じゃんｗ

>>439
使うたびに消すのだからいらない

それ言ったら、DinDだって1000容量必要なわけで
イメージ毎にファイル差し替え＝コピーしてるでしょｗ

>>438
他のやり方と何が違うと思ってんの？

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の設計意図はそういう事（組合わせ）では無いと思うけど
DinD使ってドヤ顔したい奴はそれ自体が目的だしね。

>>451 >>452
実行時ビルドにちゃんと理由言って反論しなよｗ
俺は認めたくないって言ってるだけじゃんかｗｗｗ

起動に5分かかるようなシステムはイラネ

毎回ビルドはしない。
頻繁に変わるソースコードなどは、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のやり方ってやつを
ここで言ってみなさいよ。何も言ってない。DinDといいたいだけ

>>466
コンテナ内でdockerソケットにアクセスするだけだ
余計なビルド不要、imageベンダによる最適化、テスト済、容量も最小限で済む

>>467
え？Dockerコンテナ同士が違っていたら
アクセスできないじゃんｗ

実行環境の制限がないならDINDせず
ホストOSでやれば良くね？
何やろうとしてんのか知らんけど

>>468
ぷっ

>>467
DooDな

なんでわざわざDockerの中でテストしようとしてるんだろう？
普通にホスト上でdocker-composeとか使ってテストすりゃいいんじゃん
DinDなんかいらね

>>469
見てなかったｗ　同じこと言ってたｗ

>>472
俺も思った。
最初>>437のような問題を抱えて、それが何故DinDだかDooDだかで解決するんだろうかと思ってたら、
異なるバージョン間の問題は別コンテナっぽいよな。普通にやってりゃ良いじゃんとしか思わないｗ

普通にやったら非効率なのでDinDが要るんだよ

>>475
君、そもそも会話する気ある？そんな説明じゃ分からん

ブーメラン

そろそろ　ID:6ru/T4M8　は無視で良くね？

逃

docker in dockerは使いみちあるとしても
頭悪いやつがvirtuabox in virtuaboxのように
ぐだぐだにされたら迷惑だろ

しばらく放置してたらpodmanいいかんじになってた
docker-composeもほとんどそのまま動く