Docker Part4

Linuxが持つコンテナ技術を使った、仮想マシン必要ないアプリケーション仮想化技術で
アプリケーションのデプロイが用意になります

Docker（アプリ仮想化）は仮想マシンと併用して使うことで最も効果を発揮し
開発・テストで使ったDockerイメージと全く同じものを本番環境で使えます
さらにWindowsとmacOSでも同じDockerイメージが動きます。
（Linuxは仮想マシンが不要ですが、WindowsとmacOSは仮想マシン技術を併用して実現しています。）

Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します
動かすのに必要なもの全てがDockerイメージに含まれるので
インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります

Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
情報共有しましょう

http://www.docker.io/

前スレ
Docker Part3
https://mao.5ch.net/test/read.cgi/linux/1552023620/


注意　同じコンテナ技術を使うが異なるアプローチで仮想マシンの
代替を目指しているのがLXC。目的が全く異なるので注意
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/

>>570
dockerイメージ＝プログラム（exeファイル）と考えればいいんだよ。
exeファイルの中に消えたらいけないデータを保存するかい？しないだろ？

つまり保存するデータはdockerイメージの外に保存するんだよ。
それがボリューム。ボリュームっていうのはdockerイメージを起動するときに割り当てる。
例えば任意のディレクトリをボリュームとして使うことができる。
exeファイルを実行するときにデータディレクトリを指定しているようなもんだ

こうやってdockerイメージの外のリソースを起動時に割り当てることで
dockerイメージ内部からはどこで動かしても同じように見えるようになるわけ

ちなみにデータと設定ファイル（アプリ実行中に保存しないもの）は別な。
設定ファイルはdockerイメージに埋め込んでいい（場合によっては外に出すこともある）

>>571
>dockerイメージ＝プログラム（exeファイル）と
なるほどそういうことなんですね
＞任意のディレクトリをボリュームとして使うことができる。
容量に余裕のあるHDDを指定して永続的に保存なんてこともできるのですね

アプリの設定を変えたあとその設定も他の環境でも共有したいとなると
イメージまるごと共有するか
クラウドに設定を保存するとか
ですかね
（chromeブラウザとかだとログインすればすぐ同期されていい感じなのですが）

ありがとうございました

そんなゴリゴリに使い倒すつもりはないからホストPCのシステムディスクって２５０GB（SSD）もあれば十分だよね・・？

https://martinheinz.dev/blog/35

Docker Hub Image Retention Policy Delayed, Subscription Updates
https://www.docker.com/blog/docker-hub-image-retention-policy-delayed-and-subscription-updates/

Docker Hubのイメージ削除は2021年半ばまで延期するってよ・・・

リソース消費量ベースのサブスクリプションにどう対応したら良いかとか
そもそも現在のリソース消費量は？とかよく分からないからってフィードバックが寄せられたっぽい

dockerhubの方針はよくわからないからgithubでいいや

imageを共有すること自体がないから
docker-compose.ymlの共有はするけど

このご時世にvmみたいな使い方してしまった
はぁ

イメージ作成したときにダウンロードしてきたイメージはどこに保存されているの？
イメージ作成前後でボリュームのサイズ調べてもサイズが増減しない・・見間違えてるだけかな

最初にイメージの格納場所のサイズを設定するだろ。
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.rawとか。

docker system df -v
で確認。

Ready for pull rate limits? Docker outlines 'next chapter' as Google tells customers how to dodge subscriptions
https://www.theregister.com/2020/10/28/docker_pull_rate_limit_1_november/

The issue is worse for users of private GKE clusters since "all image pulls will be routed via a single NAT gateway".
Winser warned that "any service that relies on container images may be affected, including Cloud Build, Cloud Run, App Engine etc."

11月からNATゲートウェイ経由かつ匿名ユーザーだと
全くpull出来なくなる感じ？
ヤバくね？

必要なイメージをプライベートレジストリに確保するだけ

https://labs.play-with-docker.com/
でボリュームのマウントがうまく行かない
$ cat test.txt
$ docker run -it -v /my/:/var/my ubuntu
コンテナの端末に入って/var/myに移動してもtest.txt無し

ローカルのPCでは成功したのになあ

補足
test.txtはmyディレクトリに作ってある

たぶん/my/のパスが間違ってるってことだよね
ほんとは
/なんたら/かんたら/うんたら/my
ってパスなんだろうけど

改めてやってみたら
/my:/var/my
じゃなく
/root/my:
でやったらできた！

python使いたいだけなのに８８６MBって重くない？

うそ！？私のPython 41.09MB！

alpineベースのPythonは扱いが難しい

特にCライブラリを使うパッケージが必要なプログラムの場合、ソースからビルドされて遅かったり
alpineにコンパイル済みのがあってもバージョンが古かったり
たまにglibcとmuslの違いから起きる互換性の問題がある

alpineよりslimの方がオヌヌメ
alpineよりは大きいがまだ小さめ

python:3.7-slim
で-alpineとか-slimつけるだけでいけた�d

つけるだけでいけたの前にdocker-hubくらい見ようよ

ん　dockerhubみたら
python:<version>-slim
って書いてあったよ

Docker Hubを見るのも当然だし、大元のDovkerfileを読もうよ。

謎の現象に苦しんでいます。

CentOS 7で、yumでdockerを導入しました。

docker volume creteで、vol_etcと、vol_varを作成し、docker runのオプションで、次のようにボリュームを指定のディレクトリにマウントしました。
--mount source=vol_etc,target=/etc --mount source=vol_var,target=/var

このコンテナはimageから起動しているので、オリジナルの/etcと/varとが、それぞれボリュームにコピーされるはずです。

オリジナル/etcの内容は全てボリュームにコピーされたようです。
しかし、/varの一部のディレクトリの内容が、なぜかボリュームにコピーされません。
そのため、そのディレクトリの内容のみ空っぽになってしまいます。
（具体的には、/var/spool/hylafaxというディレクトリが空になります。/var/spool/の他のサブディレクトリについては中身がコピーされています。）

念の為、ボリュームをマウントせずにコンテナを起動すると、問題のディレクトリも中身が入っていることが確認されます。

原因として何が考えられるでしょうか。お手上げ状態です。

>>594
自己レスです。

オリジナルの/var/spool/hylafax 内に、pipeファイルがあります。

prw------- 1 uucp uucp 0 Sep 19 2018 FIFO

これが原因で、ボリュームにサブディレクトリも含めてコピーがされない可能性はあるでしょうか。

pipeを削除したイメージを作ってやってみれば原因かどうかわかるんじゃないの

>>594
基本的な話として、
ホストの/etcや/varをDockerコンテナの中にマウントしてはいけません。
厳禁といってもいいレベルでダメです

/etc や /var 以下の必要なものだけをマウントする場合はギリOKです。
そのDockerイメージは何の機能をコンテナ化したものですか？
その機能に必要なものだけをマウントしてください

ついでに言っておくと/etcや/varなんかをDockerコンテナに
割り当てたりなんかしたら最悪ホストシステムが破壊されます。

アプリ屋くん今日も大暴走

>>594
>― mount source=vol_etc,target=/etc --mount source=vol_var,target=/var

なんで、こうするのか、理解に苦しむわ…。
とくに、 /var をなぜVolumeにする？
意味がわからない。

Dockerを仮想マシンか何かだと思ってるんだろ
/etcや/varを共有してDockerコンテナの中で作業しようとしてる

仮想マシンでvar とかetcの共有なんてしないけどね。

だから仮想マシンとしてログイン（？）して使いたいけど
/etcや/varを共有したいって思ったんでしょ？

アプリ専用コンテナとして考えれば
必要なものだけを共有するという発想になる

そんな広い範囲のディレクトリを参照するってことは
そのコンテナでいろんな作業をしたいってことだろう
/etcが見れればいろんなアプリ何も設定しなくても動くと勘違いしちゃうもんねｗ

もうめちゃくちゃだなこいつ
質問者はホストと共有するなんて言ってねえし

？

ボリュームってなんのことか知ってますか？

>>594
Dockerのmountとかvolumeってのは、システムの可変の部分を定義することね。
/var/www/html 配下をマウントして、中身はプライベートなgithub/gitlabとかからpullするとか。
或いは/etc/nginx/conf.d配下だけをマウントして独自の定義ファイル置くとか。
例えホストと同等のゲストを作りたいと思ったとしてもホストのetcとゲスト（コンテナ）のetc全く別物ｗ
/etc/とか/var/直下をゲストがマウントしたいとか、多分Dockerの作者も仰天の利用方法だと思うわ。

こいつvolumeとbind mountの区別ついてなさそうだな

DOCKER_CONTENT_TRUSTって設定するべきでしょうか？

してもいいししなくてもいい

DockerfileでRUNするたびにdocker imagesの一覧が増えていくんだけどなんで

>>610
設定しておくことにしました

Use GitHub Actions to deploy your application to IBM Cloud Kubernetes Service
https://youtu.be/r5hyAmuNHyE

>>611
Dockerコンテナやイメージがなんであるか理解してください。
それでも分からなければ、Docker社にお問い合わせください。

>>601
使用するアプリが、/var/spool/app以下に設定ファイルをいろいろと自動作成するんですよ。
それから/var/spoolは、postfixも作業領域を持つので、
varまるごとボリューム化しておけば便利だと思いました。

>>605
そのとおりです。
ボリュームを作成した上で、コンテナ内の/etc/と、/var/spoolを書き出して、
データ永続化しようとしているわけです。

>>596
pipeのない/var/spool/hylafax/etcにボリュームをマウントすると、
きちんとコンテナ内容物がボリュームにコピーされました。
おそらく、pipeが原因だと思います。

>>604
ぜんぜん違います。>>605さんの言うとおりです。

>>598
コンテナのディレクトリにマウントしているのは、
docker volumeです。
ホストの内容ではありません。

コンテナをprivilegeで動作させて、sshログインできるように設定しました。
リモートでコンテナ内に入ってから、yumで必要なパッケージを導入して、
アプリ環境を整えました。その後、commitしてイメージに固めました。
/etcや、/var/spoolは、コンテナ内での作業内容が保存されるので、
永続化のためにボリュームに切り出しておきます。

こんな使い方便利すぎて、どこが悪い？

そういう運用したいならLXCのほうがいいよ

むしろVMの方が楽まである

>>622
メモリ食うから仮想マシンは無理

>>621
Dockerのボリュームとか、イメージとか、
ネットワークとか、便利なのでなあ。
LXCは古い技術でしょ。やりたいことができなかったらと思うとわざわざ使う気になれないなあ。

>>621
CentOS7イメージだとprivilegeコンテナにすれば仮想マシンぽく運用できた。
でも、CentOS6イメージだとそういうわけには行かなかった。
こういう場合には、LXCというのを使うのが良いのかなと思っています。

Dockerのマウント3種類についてわかったことをまとめる
https://qiita.com/y518gaku/items/456f34c317a65a9dae86

Volumes、bind mounts、tmpfs mounts について

ホストディレクトリをコンテナにマウントする場合も、Dockerボリュームを複数コンテナで共有する場合も、排他同時アクセス機能はないんでしょ？

それができたら、ファイルサーバ機能を別コンテナに切り分けたりできるのになあ。

誰かDocker Certified Associate受けたことある人おらん？
英語あんまり自信ないんだが、問題文の英語どのくらいの難易度か教えて欲しい

>>620
便利なんだろうけどIaaCとは全然違うような？
メモリ、ストレージは節約できるだろうけどインフラの構築手順をコード化
して共有するという、コンテナ化の元の理念は死んでる気がする。
別に原理主義ではないけどな。属人化の部分が解消されない気はする。

Linuxのシェル変数$USERを
Dockerfileの中でのみ使う方法を教えてください

${USER}とか$USERでは取れませんでした

ARG USER=$USER
とか
ARG USER=${USER}

もだめでした

>>629
そもそもここで使いたいと期待するUSER変数がdocker buildを実行するホスト側
のユーザーなのか、コンテナ側なのか分からないんだが・・・

>>630
ホスト側です

引数に渡してENVにあげる。

https://vsupalov.com/docker-build-time-env-values/

そういうこと。仮想マシンがあるのに
わざわざDockerでやる必要がない

DockerはDockerの目的にために利用するのがいい

でもDockerの方がGUI無い分軽いじゃん

>>620
あと、この使い方は最初の一発目位は良いけど、運用が進むとそのうちexportされたetcやvarに
依存するようになって、ホストAで動いていたものがホストBでpullすると動かないとか、
コンテナの最大のウリだった可搬性も消えてなくなる気がする。
・・・まあ、VMで運用してメモリ食うことが問題なら、メモリ増やすことが解決策であって
privilegeにしてシステム全体をリスクに晒してまでコンテナ化して解決しよう、というのは
ちょっと理解し難いな。

>>628
>インフラの構築手順をコード化して共有するという、コンテナ化の元の理念

コード化するということは、意図したとおりにエラーなく進行するかいわばデバッグが必要になると思う。
おっしゃるとおりそれを共有するなら一回のデバッグの努力に意義があるけど、
自分でコンテナとそのイメージを構築するだけなら、
sshログインしてコンテナ内で直接構築作業すれば楽に思う。
共有しない構築手順のコード作成は労力がめんどうくさくなる。

>>636
>運用が進むとそのうちexportされたetcやvarに依存するようになって、ホストAで動いていたものがホストBでpullすると動かない

運用が進む前から、最初から、ボリュームに逃したetcやvarに依存しているよ。
もちろん、別のホストでコンテナを動作させるには、そのコンテナのイメージと、ボリューム内容、そしてrunするためのワンライナーが必要になる。
それでも、ホストマシンに直にシステム構築するよりもはるかに可搬性が高いと思う。
万人向けに共有する場合であればおっしゃるとおり、可搬性は悪いと言えると思うけどね。

コンテナを削除しても残り続けるボリュームという概念が存在するとは、
Dockerはボリュームに逃した内容（etc,varなど）に依存するコンテナがあっても仕方ないと考えているのではないかと思う。

>>633 >>634
Dockerの原理主義ってどうして多いんだろう
仮想マシンも、LCXも、Dockerコンテナに劣るところがたくさんある。
LCXはコンテナの削除などの扱いがディスクコピーにかかる時間を要するために非常に遅いらしい。

>>636
>運用が進む
運用が進むとはいっても、最初に構築したコンテナをイメージに固めるよ。
ただ、アプリのためのコンフィグファイルはコンテナのetcやvarなどに保存されるので、
その書き換えを目的としてそれらのディレクトリはボリュームに逃がしている。
etc全体とか、var全体にするよりも、もっと局所に留めるのが良いかもしれないけどね。

以後は、そのイメージからrunするようにする。>>628さんのいうような構築手順はコード化していないけど、
構築されたアプリケーションはイメージという形で維持しつづけるよ。

IaC全くしてないレガシーなPHPのシステムをDocker+ECSに移行なら昔やった

でも、本番でバインドマウントしてるのはアップロードされたファイルだけだな

設定は環境変数から取得するようにして
アップロードされたファイルなど一部だけをバインドマウント経由でEFSに保存する
他は全てnginxやphpのイメージに予め入れておく

ログは標準出力経由で全てコンテナのログへ
DBは元から別サーバー

ローカル開発環境ではUnisonでphpファイルを同期
開発機のphp入ってるディレクトリを丸ごとマウントでも良いか、このシステムは肥大化してて遅いのでUnisonを使用

俺は横着なのでDockerfileが構築手順書がわりになる方が便利
それがなけりゃlxc使う（かつては使ってた）

docker runも--rm付けて毎回クリーンに起動するのが性に合う
無論ログやdbファイルはボリュームで外部化するけど

>>626
直接マウントするのはハードウェア1つにつきコンテナ1つだけ
マウントしてるコンテナが他のコンテナにサービスとしてファイルアクセスを提供する
排他制御とかもその1つのコンテナが全部引き受ける

>>636
dockerに限らずIasCって必ずしもコストパフォーマンスがいいとも限らんからな
自動化の制御が複雑になるなら手作業で設定してコミットしちゃったほうが簡単だって考え方は十分ありだと思うよ

IasCに疲弊してる企業が、よくよく考えたら本当に欲しかったものはサーバーの状態をexp impする機能だった

>>643
ホストディレクトリをマウントしているコンテナが、
他のコンテナにサービスとしてファイルアクセスを提供するには、
XFSとか、Sambaとか、排他制御ができるというオンラインファイル共有サービスを公開するということですか。

なるほど、じゃあ、ボリュームをマウントしたコンテナが、
それらの共有サービスを公開すれば、他のコンテナでもボリューム内容を共有できますね。

>>644
>IasCに疲弊してる企業

Docker原理主義者の言うことを鵜呑みにしたのかしら
アプリの設定ファイル作成をコード化するなんて頭おかしいとすら思えてしまった。

>>645
オンライン共有サービス？ ストレージサービスとかいう名前でいいだろｗ

アプリ用コンテナとデータベース用コンテナは分けて
それぞれコンテナ＝1サービスにしろっていうのはそういうこと

>>646
それはあなたの感想であって、意見や主張は何も含まれてないですね

最初からDocker前提で書いてればそんな難しくはない
レガシーなシステムを大量に抱えてたら大変

>>647
でも、データベースの場合は、SQLコマンドのやり取りだけなので、データベースのデータファイルを直接オンラインストレージサービスで共有する必要はないよな。

排他制御を行うためにストレージサービス（XFS, samba）を使う場合は、ファイルレベルでの取り扱いが必要な場合だけだよね。

レガシーの移行はいっぺんにやろうとするな
VM、LXC、systemdコンテナ、Ansible、Chefなどを使って段階的に移行すべし
そもそもdockerに移行する意味があるのかはよく考えたほうがいい

>>647
でも、そもそもどうしてコンテナには1サービスしかおいたら駄目なのか？

例えば、名前解決させるのにdnsmasqデーモンが別途必要だとすると、これで複数サービスになってしまう。

アプリケーションという概念は、様々なサービスの組み合わせが本質だから、可搬性を考えても、それらをワンコンテナに組み込むのが自然だと思う。

即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。

>>647
ストレージサービスだと、iSCSIも含んでしまう。
排他制御ができるファイル単位サービスということで、オンライン共有サービスと言った。

>>626
ホストの同一ディレクトリを複数コンテナでマウントするだけでしょ
排他もかかるよ

>>652
その考え方で概ね正しいよ

好例としてGitlabのオフィシャルコンテナも1コンテナにすべてのサービスを詰め込んで1コンテナ：マルチサービスで動かしている
そして内部的な構成管理ツールとしてChefを使っている
これは1コンテナ：1プロセスという無意味なプラクティスには反するが現実として非常にうまくいってる

ただしこの構成だと特定のコンテキストやレイヤーを抜き出してそれだけスケールアウトするのが難しくなる
デメリットはせいぜいそれぐらいしかない

よく言われるのは1プロセスじゃなく1サービスだろ
WebとDBで完結して1サービスと見なせるなら分ける必要ないよ

Webを複数にして負荷分散等する予定があるとか
DBをデータマート的に多目的に使う奈良分けた方が柔軟だろうが

mysqlとかphpmyadminとか既存のDockerイメージあるじゃん？
なのにわざわざ苦労して手動インストールして
1つの複雑なDockerイメージにする理由がない

>>652
> 即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
する理由がない

複数コンテナを結合できるのに、一体化させる理由がないんだよね
複数コンテナをつなげるのは簡単だが、一つになってるものは分離できない

・複数のコンテナをオーケストレーションしないと使えないサービス
・コンテナ1個動かせばOKなサービス

どっちが楽なのかは自明だろ

更に既存資産があれば作るのも楽々だ
わざわざ労力をかけてDockerfileに書き直す？
ハァト…無駄な努力

>>659
docker -composeも使えない猿未満の方？

DBは本番だと別サーバーな事も多い
メインのDockerイメージに含まれてても容量が大きくなって邪魔なだけ

DBは自分で用意するから余計なお節介はやめろ

DBだけAWS RDS使いたければ、
元から別コンテナだったら本番で構成に含めなければ済む話
なぜsupervisordとか使って複雑にする必要がある？

流行ってるからでぇ〜すｗｗｗ
たいがいこんなもんだろ

>>661
なぜ使える使えないという個人のスキルの話に脱線するのか意味不明だよ君

dockercomposeを使わなくても簡単に動かせるならそちらのほうがいい
より簡単な方はどっちなのか？
答えは誰でもわかる、単一コンテナのほうが簡単

>>662
ケースバイケース
既存資産があるなら1つにまとめてしまったほうが楽な場合がある
Gitlabのように戦略的に単一コンテナを選ぶ場合だってある
何でもかんでも分割すりゃいいってもんじゃない

>>664
論理的じゃない

簡単に動かせるならそちらのほうがいい・・・とは限らないだろ

>>665
分割したほうが再利用しやすいという話だ

>>666
いやいや
同じ機能が手に入るなら簡単であればあるほどいい
難しい構成が許されるのはそれに見合う目的が必要

つまりデフォルトは限りなくシンプルに簡単に
細かくチューンナップしたいなら難しい構成を許可する
という順番がある
最初から難しい構成を押し付けるのはクソ製品

> 同じ機能が手に入るなら簡単であればあるほどいい

自分で答え言っちゃってるわなｗ

「同じ機能が手に入らない」ので
言ってることが論理的ではない

>>667
そうとも限らない
Gitlabコンテナは世界中で再利用されている
再利用するのにまったく困ることがない
もし仮にGitlabコンテナを構成するサービスが別のコンテナになっていたらオーケストレーション構成を考えるのが面倒で再利用に余計な手間がかかってしまう

× Gitlabコンテナは世界中で再利用されている
○ GitLabサービスは世界中で利用されている

一番簡単なのは GitLabサービスなのだ