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/

>>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サービスなのだ

>>669
はぁ
くだらない揚げ足取り

>>671
話をそらすな

そらしてないなぁ
データベースが一体化していれば
GitLabサービスの運営は大変だろう

Gitlabは本当によくできている
デフォルトでは単一コンテナで最小のパラメーター設定だけで動かせるように作られてる
その上で内部サービスをオミットして別のコンテナに分割することもできる

そうする必要もないのにデフォルトの構成を複雑化させたがるバカはGitlabコンテナを見習ってほしい

>>674
そらしてる
今はGitlabコンテナの話をしてる
Gitlab.comのサービスの話はしてない

だから大抵の人にとって一番簡単なのはGitLabサービスを使うことだろ
それに対してデータベースを別でバックアップしておきたいって人にとっては
データベースは分離されていたほうがいいし

>>654
ボリュームを複数コンテナでマウントするだけでは排他制御されない。

ホストディレクトリをコンテナにマウントしても同様に排他制御はかからないのではないか

>>657
可搬性が理由だと思う。

GitLabは全部一緒くたになってるから
間違ってコンテナを消してしまうとデータまで消えてしまう
データのバックアップも大変
安心して運用なんてできないよ

>>677
またトンチンカンなことを
Gitlabサービスを使う話はしてない
コンテナの構成として1コンテナマルチサービスの是非を議論しているのにマネージドサービスと比較してどうすんだよ
本当に意味不明だよ君

今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
マネージドサービスの話がしたいならスレ違いだからさっさと別のスレにいけ

>>654
排他制御の意味が違ってる。

例えばMySQLを2つ起動したとして、同じディレクトリを
参照していたらデータが壊れるだろ

ファイルは壊れなくてもデータが壊れる

github使わずにgitlab使うのは自社サーバで運用したいケースが多いんじゃね
マイクロソフト資本を嫌悪したケースもあるかも知らんが
あとデータベースのバックアップは基本的にコンテナやボリューム単位ではなくて
データベース純正のバックアップ手段使うケースが多いと思うよ

>>681
> 今の話の大前提は「DockerでGitlabをセルフホストする」ことだ

ほらなｗ また条件つけた。

つまりこいつにとっての「使いやすい」の基準は
「DockerでGitlabをセルフホストする」場合の話であって
誰かのためにサービスを運営する（つまりGitLabサービス）のようなものには
当てはまらないということだ

開発者なら「誰かのためにサービスを運営する」だろ？

>>680
間違って消しちゃたら困るのは纏めてようが分けてようが同じ
バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
いずれの場合も、対象が1つのコンテナにまとまってるから簡単にバックアップできる
もし、これが複数のコンテナに分量外していたら、それぞれのコンテナについてバックアップを考えなければならないので大変だ

> バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている

はいそれなｗ

「一つにまとめたほうがいい」という方針の結果がそれだよｗ
そういう方法を自分で作らなければいけなくなるということ

データベースが分離されていれば、一般的なやり方がそのまま使える
GitLabに依存してないからだ。しかし一つにまとめた結果そのやり方が使えなくなり
そういうツールを開発しなければいけなくなった

>>684
条件を付けた？
最初からこの条件で話してたらお前がマネージドサービスとの比較などというズレまくったトピックを持ち込んできたんだろ
いい加減にしろ

>>687
お前は他人が用意したものを使うだけの話をしてるが

こちとらDockerfileを「作る側」の話をしてるんだよ
それはGitLabサービスと同じ立場だ

一つにまとめれば作るのが簡単？
GitLabのバックアップの件からも特殊なツールの開発が
必要になるってことがわかったよなｗ

>>686
考えが浅すぎてため息しかでない
なにが一般的な方法が使えるだよ
Gitlabの管理するデータはDBだけじゃない
リポジトリデータやその他のサービスのデータも管理してる
これらを個別に管理したら大変だよ

個別に簡単に管理できるならGitlabはわざわざバックアップコマンドを用意したりしねーよ
少しは考えろ

>>688
作る側ならより慎重に使う側の都合を考えろよ
使う側に知識と労力を期待するのは三流の開発者だ

Gitlabの開発者はdocker runさえ知ってればGitlabを動かせるように整備した
これが一流の開発者だ

ああ、使う側って自分で開発したアプリでサービスを運営するって考えがないのかｗ
いやはや、考えが浅いなぁ

>>691
利用形態は外向けサービス運営だけじゃない
むしろサービス運営のほうが圧倒的に少数派
どんな企業でも開発用の社内システムを持ってるがサービス運営をしているとは限らない
社内システムでは導入の手軽さと運用コストがまっさきに検討される

こんなことにすら考えを巡らせられないのか？
浅い
浅すぎる

自分たちで作って自分たちだけで消費してるから不特定多数にイメージを使ってもらうという想定ができないんだろうな
閉じた世界で考えてるからとにかく浅い

自分が浅いことがバレて必死になってるなｗ