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/

>>320
大した手間じゃないよ

一流は自分達の、多少の手間を惜しんで、ユーザーの負担を、増やそうとはしない
二流は自分達が、ほんの少し楽したいからって、ユーザーに手間をオシツケテル

GitLabは超一流だ
だから、シングルコンテナを選んだ
そのほうが、ユーザーが、楽だからだ

>>321
世界に公開するイメージなら、どの環境でも、簡単な手順で、動いたほうがいいに、決まってる

>>322
そんな物誰も求めてないから真似しないんだと思うよ。

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock my-awesome-app docker-compose up

docker.sockをさらけ出すとあぶない

>>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を見ればわかる

オーケストレーション前提じゃオペレーターも大変だ
オペレーターはレゴブロック遊びに付き合うほど暇じゃない

https://github.com/sameersbn/docker-gitlab
GitLab使うならこっちでよくね？

readmeなっが
お手軽な公式版、使うわ

な？「使うわ」という使う側の立場でしか見てないんだよ
作る側の大変さの話をしてるのにな

バカの一つ覚えのように一つのコンテナなら手軽に試せるしか言わねえし
何言っても無駄だろ

>>334
https://github.com/sameersbn/docker-gitlab#quick-start

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で書いたものを使ってコンテナ起動する方法を教えてください

docker-compose up

nixでDockerfile書かずにDockerイメージビルドしてみた

イメージは作成出来たが、bashの履歴やタブ補完が使えない
なんか設定したら使えるのか？

bash-completion入れてみたが、効果無かった
Dockerfileと組み合わせて使うか、普通にDockerfile使う方が楽かも

まさかDockerの中でbashの履歴やタブ補完がほしいとか思ってるのか？
デバッグ用は別として、Dockerコンテナの中で作業するものじゃないぞ
>>1をちゃんと読め

>>353
devcontainerも知らんの？

アンチパターンの名前がどうかしたのか？

アンチパターン？

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

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

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

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

もっと気軽に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だけで完結させたいね