[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
570(1): 2020/10/17(土)04:08 ID:o45tI0TJ(1/2) AAS
dockerの理念的に
１アプリ１イメージ
使い終わったらコンテナ削除する
ってことらしいですが
開発環境の場合、毎回コンテナ削除してたら編集データとかリセットしませんか・・？
データやら設定ファイルだけはホストに保存するってことでしょうか？
571(1): 2020/10/17(土)04:27 ID:ZuG7iJvZ(1) AAS
>>570
dockerイメージ＝プログラム（exeファイル）と考えればいいんだよ。
exeファイルの中に消えたらいけないデータを保存するかい？しないだろ？
つまり保存するデータはdockerイメージの外に保存するんだよ。
それがボリューム。ボリュームっていうのはdockerイメージを起動するときに割り当てる。
例えば任意のディレクトリをボリュームとして使うことができる。
exeファイルを実行するときにデータディレクトリを指定しているようなもんだ
こうやってdockerイメージの外のリソースを起動時に割り当てることで
dockerイメージ内部からはどこで動かしても同じように見えるようになるわけ
ちなみにデータと設定ファイル（アプリ実行中に保存しないもの）は別な。
設定ファイルはdockerイメージに埋め込んでいい（場合によっては外に出すこともある）
572: 2020/10/17(土)04:58 ID:o45tI0TJ(2/2) AAS
>>571
>dockerイメージ＝プログラム（exeファイル）と
なるほどそういうことなんですね
＞任意のディレクトリをボリュームとして使うことができる。
容量に余裕のあるHDDを指定して永続的に保存なんてこともできるのですね
アプリの設定を変えたあとその設定も他の環境でも共有したいとなると
イメージまるごと共有するか
クラウドに設定を保存するとか
ですかね
（chromeブラウザとかだとログインすればすぐ同期されていい感じなのですが）
ありがとうございました
573: 2020/10/17(土)17:19 AAS
そんなゴリゴリに使い倒すつもりはないからホストPCのシステムディスクって２５０GB（SSD）もあれば十分だよね・・？
574: 2020/10/17(土)22:15 ID:DLL24/S3(1) AAS
外部ﾘﾝｸ:martinheinz.dev
575: 2020/10/24(土)16:40 ID:xxGzDPrd(1) AAS
Docker Hub Image Retention Policy Delayed, Subscription Updates
外部ﾘﾝｸ:www.docker.com
Docker Hubのイメージ削除は2021年半ばまで延期するってよ・・・
リソース消費量ベースのサブスクリプションにどう対応したら良いかとか
そもそも現在のリソース消費量は？とかよく分からないからってフィードバックが寄せられたっぽい
576: 2020/10/25(日)11:54 ID:8aW1oLHx(1) AAS
dockerhubの方針はよくわからないからgithubでいいや
577: 2020/10/26(月)01:04 ID:AY57YqY6(1) AAS
imageを共有すること自体がないから
docker-compose.ymlの共有はするけど
578: 2020/10/26(月)23:53 ID:h3ceCoJ5(1) AAS
このご時世にvmみたいな使い方してしまった
はぁ
579: 2020/10/29(木)03:10 ID:PcZHu1+a(1) AAS
イメージ作成したときにダウンロードしてきたイメージはどこに保存されているの？
イメージ作成前後でボリュームのサイズ調べてもサイズが増減しない・・見間違えてるだけかな
580: 2020/10/29(木)03:53 ID:Hs3h4quA(1) AAS
最初にイメージの格納場所のサイズを設定するだろ。
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.rawとか。
docker system df -v
で確認。
581: 2020/10/29(木)14:00 ID:rXwaKjQ8(1) AAS
Ready for pull rate limits? Docker outlines 'next chapter' as Google tells customers how to dodge subscriptions
外部ﾘﾝｸ:www.theregister.com
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出来なくなる感じ？
ヤバくね？
582: 2020/10/29(木)18:00 ID:jMkOFc/w(1) AAS
必要なイメージをプライベートレジストリに確保するだけ
583(1): 2020/10/30(金)21:51 AAS
外部ﾘﾝｸ:labs.play-with-docker.com
でボリュームのマウントがうまく行かない
$ cat test.txt
$ docker run -it -v /my/:/var/my ubuntu
コンテナの端末に入って/var/myに移動してもtest.txt無し
ローカルのPCでは成功したのになあ
584: 2020/10/30(金)22:54 AAS
補足
test.txtはmyディレクトリに作ってある
585: 2020/10/30(金)22:56 AAS
たぶん/my/のパスが間違ってるってことだよね
ほんとは
/なんたら/かんたら/うんたら/my
ってパスなんだろうけど
586: 583 2020/10/30(金)23:06 AAS
改めてやってみたら
/my:/var/my
じゃなく
/root/my:
でやったらできた！
587: 2020/10/30(金)23:57 ID:dHpXX+dB(1) AAS
python使いたいだけなのに８８６MBって重くない？
588: 2020/10/31(土)00:15 ID:Vfwi3dRZ(1/2) AAS
うそ！？私のPython 41.09MB！
589: 2020/10/31(土)09:33 ID:4qiE9XbQ(1) AAS
alpineベースのPythonは扱いが難しい
特にCライブラリを使うパッケージが必要なプログラムの場合、ソースからビルドされて遅かったり
alpineにコンパイル済みのがあってもバージョンが古かったり
たまにglibcとmuslの違いから起きる互換性の問題がある
alpineよりslimの方がオヌヌメ
alpineよりは大きいがまだ小さめ
590: 2020/10/31(土)13:31 ID:nDrTm0nA(1/2) AAS
python:3.7-slim
で-alpineとか-slimつけるだけでいけた?
591: 2020/10/31(土)13:40 ID:Vfwi3dRZ(2/2) AAS
つけるだけでいけたの前にdocker-hubくらい見ようよ
592: 2020/10/31(土)14:12 ID:nDrTm0nA(2/2) AAS
ん dockerhubみたら
python:<version>-slim
って書いてあったよ
593: 2020/10/31(土)14:34 ID:oeYVChnG(1) AAS
Docker Hubを見るのも当然だし、大元のDovkerfileを読もうよ。
594(4): 2020/11/01(日)17:44 ID:M5iteKem(1/2) AAS
謎の現象に苦しんでいます。
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/の他のサブディレクトリについては中身がコピーされています。）
念の為、ボリュームをマウントせずにコンテナを起動すると、問題のディレクトリも中身が入っていることが確認されます。
原因として何が考えられるでしょうか。お手上げ状態です。
595: 2020/11/01(日)17:56 ID:M5iteKem(2/2) AAS
>>594
自己レスです。
オリジナルの/var/spool/hylafax 内に、pipeファイルがあります。
prw------- 1 uucp uucp 0 Sep 19 2018 FIFO
これが原因で、ボリュームにサブディレクトリも含めてコピーがされない可能性はあるでしょうか。
596(1): 2020/11/01(日)18:14 ID:RPHXCdM8(1) AAS
pipeを削除したイメージを作ってやってみれば原因かどうかわかるんじゃないの
597: 2020/11/01(日)19:30 ID:6Gl5tSwg(1/3) AAS
>>594
基本的な話として、
ホストの/etcや/varをDockerコンテナの中にマウントしてはいけません。
厳禁といってもいいレベルでダメです
598(1): 2020/11/01(日)19:32 ID:6Gl5tSwg(2/3) AAS
/etc や /var 以下の必要なものだけをマウントする場合はギリOKです。
そのDockerイメージは何の機能をコンテナ化したものですか？
その機能に必要なものだけをマウントしてください
599: 2020/11/01(日)19:33 ID:6Gl5tSwg(3/3) AAS
ついでに言っておくと/etcや/varなんかをDockerコンテナに
割り当てたりなんかしたら最悪ホストシステムが破壊されます。
600: 2020/11/01(日)19:41 ID:lesnXEzs(1) AAS
アプリ屋くん今日も大暴走
601(1): 2020/11/01(日)20:10 ID:w/PjhgBB(1) AAS
>>594
>― mount source=vol_etc,target=/etc --mount source=vol_var,target=/var
なんで、こうするのか、理解に苦しむわ…。
とくに、 /var をなぜVolumeにする？
意味がわからない。
602: 2020/11/02(月)00:03 ID:BCpQPJWu(1/3) AAS
Dockerを仮想マシンか何かだと思ってるんだろ
/etcや/varを共有してDockerコンテナの中で作業しようとしてる
603: 2020/11/02(月)00:51 ID:FrveCY20(1/2) AAS
仮想マシンでvar とかetcの共有なんてしないけどね。
604(1): 2020/11/02(月)00:55 ID:BCpQPJWu(2/3) AAS
だから仮想マシンとしてログイン（？）して使いたいけど
/etcや/varを共有したいって思ったんでしょ？
アプリ専用コンテナとして考えれば
必要なものだけを共有するという発想になる
そんな広い範囲のディレクトリを参照するってことは
そのコンテナでいろんな作業をしたいってことだろう
/etcが見れればいろんなアプリ何も設定しなくても動くと勘違いしちゃうもんねｗ
605(2): 2020/11/02(月)01:02 ID:4g2Afrsx(1) AAS
もうめちゃくちゃだなこいつ
質問者はホストと共有するなんて言ってねえし
606: 2020/11/02(月)01:14 ID:BCpQPJWu(3/3) AAS
？
ボリュームってなんのことか知ってますか？
607: 2020/11/02(月)04:24 ID:FrveCY20(2/2) AAS
>>594
Dockerのmountとかvolumeってのは、システムの可変の部分を定義することね。
/var/www/html 配下をマウントして、中身はプライベートなgithub/gitlabとかからpullするとか。
或いは/etc/nginx/conf.d配下だけをマウントして独自の定義ファイル置くとか。
例えホストと同等のゲストを作りたいと思ったとしてもホストのetcとゲスト（コンテナ）のetc全く別物ｗ
/etc/とか/var/直下をゲストがマウントしたいとか、多分Dockerの作者も仰天の利用方法だと思うわ。
608: 2020/11/02(月)08:57 ID:EcOPmiOb(1) AAS
こいつvolumeとbind mountの区別ついてなさそうだな
609: 2020/11/03(火)16:30 ID:6B3+AB0D(1/2) AAS
DOCKER_CONTENT_TRUSTって設定するべきでしょうか？
610(1): 2020/11/03(火)17:19 ID:fVpH/w23(1) AAS
してもいいししなくてもいい
611(1): 2020/11/03(火)17:37 AAS
DockerfileでRUNするたびにdocker imagesの一覧が増えていくんだけどなんで
612: 2020/11/03(火)20:10 ID:6B3+AB0D(2/2) AAS
>>610
設定しておくことにしました
613: 2020/11/03(火)20:55 ID:ZfhIPw1B(1) AAS
Use GitHub Actions to deploy your application to IBM Cloud Kubernetes Service
動画ﾘﾝｸ[YouTube]
614: 2020/11/03(火)21:01 ID:3zNCbq6k(1) AAS
>>611
Dockerコンテナやイメージがなんであるか理解してください。
それでも分からなければ、Docker社にお問い合わせください。
615: 2020/11/03(火)21:13 ID:SU13O3bL(1/8) AAS
>>601
使用するアプリが、/var/spool/app以下に設定ファイルをいろいろと自動作成するんですよ。
それから/var/spoolは、postfixも作業領域を持つので、
varまるごとボリューム化しておけば便利だと思いました。
616: 2020/11/03(火)21:15 ID:SU13O3bL(2/8) AAS
>>605
そのとおりです。
ボリュームを作成した上で、コンテナ内の/etc/と、/var/spoolを書き出して、
データ永続化しようとしているわけです。
617: 2020/11/03(火)21:17 ID:SU13O3bL(3/8) AAS
>>596
pipeのない/var/spool/hylafax/etcにボリュームをマウントすると、
きちんとコンテナ内容物がボリュームにコピーされました。
おそらく、pipeが原因だと思います。
618: 2020/11/03(火)21:18 ID:SU13O3bL(4/8) AAS
>>604
ぜんぜん違います。>>605さんの言うとおりです。
619: 2020/11/03(火)21:20 ID:SU13O3bL(5/8) AAS
>>598
コンテナのディレクトリにマウントしているのは、
docker volumeです。
ホストの内容ではありません。
620(2): 2020/11/03(火)21:23 ID:SU13O3bL(6/8) AAS
コンテナをprivilegeで動作させて、sshログインできるように設定しました。
リモートでコンテナ内に入ってから、yumで必要なパッケージを導入して、
アプリ環境を整えました。その後、commitしてイメージに固めました。
/etcや、/var/spoolは、コンテナ内での作業内容が保存されるので、
永続化のためにボリュームに切り出しておきます。
こんな使い方便利すぎて、どこが悪い？
621(2): 2020/11/03(火)21:34 ID:mxkbANnQ(1) AAS
そういう運用したいならLXCのほうがいいよ
622(1): 2020/11/03(火)22:16 ID:M5SiUIu9(1) AAS
むしろVMの方が楽まである
623: 2020/11/03(火)23:10 ID:SU13O3bL(7/8) AAS
>>622
メモリ食うから仮想マシンは無理
>>621
Dockerのボリュームとか、イメージとか、
ネットワークとか、便利なのでなあ。
LXCは古い技術でしょ。やりたいことができなかったらと思うとわざわざ使う気になれないなあ。
624: 2020/11/03(火)23:14 ID:SU13O3bL(8/8) AAS
>>621
CentOS7イメージだとprivilegeコンテナにすれば仮想マシンぽく運用できた。
でも、CentOS6イメージだとそういうわけには行かなかった。
こういう場合には、LXCというのを使うのが良いのかなと思っています。
625: 2020/11/04(水)00:26 ID:5EaF6Elr(1) AAS
Dockerのマウント3種類についてわかったことをまとめる
外部ﾘﾝｸ:qiita.com
Volumes、bind mounts、tmpfs mounts について
626(3): 2020/11/04(水)00:46 ID:8vCtX8KM(1/10) AAS
ホストディレクトリをコンテナにマウントする場合も、Dockerボリュームを複数コンテナで共有する場合も、排他同時アクセス機能はないんでしょ？
それができたら、ファイルサーバ機能を別コンテナに切り分けたりできるのになあ。
627(1): 2020/11/04(水)01:03 ID:8GrlF7V6(1) AAS
誰かDocker Certified Associate受けたことある人おらん？
英語あんまり自信ないんだが、問題文の英語どのくらいの難易度か教えて欲しい
628(2): 2020/11/04(水)01:10 ID:7tuD0WTP(1/4) AAS
>>620
便利なんだろうけどIaaCとは全然違うような？
メモリ、ストレージは節約できるだろうけどインフラの構築手順をコード化
して共有するという、コンテナ化の元の理念は死んでる気がする。
別に原理主義ではないけどな。属人化の部分が解消されない気はする。
629(1): 2020/11/04(水)01:23 ID:aRkKqxcc(1/4) AAS
Linuxのシェル変数$USERを
Dockerfileの中でのみ使う方法を教えてください
${USER}とか$USERでは取れませんでした
ARG USER=$USER
とか
ARG USER=${USER}
もだめでした
630(1): 2020/11/04(水)01:37 ID:7tuD0WTP(2/4) AAS
>>629
そもそもここで使いたいと期待するUSER変数がdocker buildを実行するホスト側
のユーザーなのか、コンテナ側なのか分からないんだが・・・
631: 2020/11/04(水)01:37 ID:aRkKqxcc(2/4) AAS
>>630
ホスト側です
632(1): 2020/11/04(水)01:46 ID:7tuD0WTP(3/4) AAS
引数に渡してENVにあげる。
外部ﾘﾝｸ:vsupalov.com
633(1): 2020/11/04(水)03:46 ID:QtKCHGIC(1/5) AAS
そういうこと。仮想マシンがあるのに
わざわざDockerでやる必要がない
634(1): 2020/11/04(水)03:47 ID:QtKCHGIC(2/5) AAS
DockerはDockerの目的にために利用するのがいい
635: 2020/11/04(水)03:57 ID:UuvmniCF(1) AAS
でもDockerの方がGUI無い分軽いじゃん
636(3): 2020/11/04(水)04:10 ID:7tuD0WTP(4/4) AAS
>>620
あと、この使い方は最初の一発目位は良いけど、運用が進むとそのうちexportされたetcやvarに
依存するようになって、ホストAで動いていたものがホストBでpullすると動かないとか、
コンテナの最大のウリだった可搬性も消えてなくなる気がする。
・・・まあ、VMで運用してメモリ食うことが問題なら、メモリ増やすことが解決策であって
privilegeにしてシステム全体をリスクに晒してまでコンテナ化して解決しよう、というのは
ちょっと理解し難いな。
637: 2020/11/04(水)08:25 ID:8vCtX8KM(2/10) AAS
>>628
>インフラの構築手順をコード化して共有するという、コンテナ化の元の理念
コード化するということは、意図したとおりにエラーなく進行するかいわばデバッグが必要になると思う。
おっしゃるとおりそれを共有するなら一回のデバッグの努力に意義があるけど、
自分でコンテナとそのイメージを構築するだけなら、
sshログインしてコンテナ内で直接構築作業すれば楽に思う。
共有しない構築手順のコード作成は労力がめんどうくさくなる。
638: 2020/11/04(水)08:30 ID:8vCtX8KM(3/10) AAS
>>636
>運用が進むとそのうちexportされたetcやvarに依存するようになって、ホストAで動いていたものがホストBでpullすると動かない
運用が進む前から、最初から、ボリュームに逃したetcやvarに依存しているよ。
もちろん、別のホストでコンテナを動作させるには、そのコンテナのイメージと、ボリューム内容、そしてrunするためのワンライナーが必要になる。
それでも、ホストマシンに直にシステム構築するよりもはるかに可搬性が高いと思う。
万人向けに共有する場合であればおっしゃるとおり、可搬性は悪いと言えると思うけどね。
コンテナを削除しても残り続けるボリュームという概念が存在するとは、
Dockerはボリュームに逃した内容（etc,varなど）に依存するコンテナがあっても仕方ないと考えているのではないかと思う。
639: 2020/11/04(水)08:33 ID:8vCtX8KM(4/10) AAS
>>633 >>634
Dockerの原理主義ってどうして多いんだろう
仮想マシンも、LCXも、Dockerコンテナに劣るところがたくさんある。
LCXはコンテナの削除などの扱いがディスクコピーにかかる時間を要するために非常に遅いらしい。
640: 2020/11/04(水)08:38 ID:8vCtX8KM(5/10) AAS
>>636
>運用が進む
運用が進むとはいっても、最初に構築したコンテナをイメージに固めるよ。
ただ、アプリのためのコンフィグファイルはコンテナのetcやvarなどに保存されるので、
その書き換えを目的としてそれらのディレクトリはボリュームに逃がしている。
etc全体とか、var全体にするよりも、もっと局所に留めるのが良いかもしれないけどね。
以後は、そのイメージからrunするようにする。>>628さんのいうような構築手順はコード化していないけど、
構築されたアプリケーションはイメージという形で維持しつづけるよ。
641: 2020/11/04(水)09:25 ID:1buxXrD8(1/3) AAS
IaC全くしてないレガシーなPHPのシステムをDocker+ECSに移行なら昔やった
でも、本番でバインドマウントしてるのはアップロードされたファイルだけだな
設定は環境変数から取得するようにして
アップロードされたファイルなど一部だけをバインドマウント経由でEFSに保存する
他は全てnginxやphpのイメージに予め入れておく
ログは標準出力経由で全てコンテナのログへ
DBは元から別サーバー
ローカル開発環境ではUnisonでphpファイルを同期
開発機のphp入ってるディレクトリを丸ごとマウントでも良いか、このシステムは肥大化してて遅いのでUnisonを使用
642: 2020/11/04(水)09:29 ID:sMNwaZ5l(1) AAS
俺は横着なのでDockerfileが構築手順書がわりになる方が便利
それがなけりゃlxc使う（かつては使ってた）
docker runも--rm付けて毎回クリーンに起動するのが性に合う
無論ログやdbファイルはボリュームで外部化するけど
643(1): 2020/11/04(水)10:03 ID:eFolKj+u(1) AAS
>>626
直接マウントするのはハードウェア1つにつきコンテナ1つだけ
マウントしてるコンテナが他のコンテナにサービスとしてファイルアクセスを提供する
排他制御とかもその1つのコンテナが全部引き受ける
644(1): 2020/11/04(水)10:13 ID:c69K63Cq(1) AAS
>>636
dockerに限らずIasCって必ずしもコストパフォーマンスがいいとも限らんからな
自動化の制御が複雑になるなら手作業で設定してコミットしちゃったほうが簡単だって考え方は十分ありだと思うよ
IasCに疲弊してる企業が、よくよく考えたら本当に欲しかったものはサーバーの状態をexp impする機能だった
645(1): 2020/11/04(水)11:06 ID:8vCtX8KM(6/10) AAS
>>643
ホストディレクトリをマウントしているコンテナが、
他のコンテナにサービスとしてファイルアクセスを提供するには、
XFSとか、Sambaとか、排他制御ができるというオンラインファイル共有サービスを公開するということですか。
なるほど、じゃあ、ボリュームをマウントしたコンテナが、
それらの共有サービスを公開すれば、他のコンテナでもボリューム内容を共有できますね。
646(1): 2020/11/04(水)11:10 ID:8vCtX8KM(7/10) AAS
>>644
>IasCに疲弊してる企業
Docker原理主義者の言うことを鵜呑みにしたのかしら
アプリの設定ファイル作成をコード化するなんて頭おかしいとすら思えてしまった。
647(3): 2020/11/04(水)11:13 ID:QtKCHGIC(3/5) AAS
>>645
オンライン共有サービス？ ストレージサービスとかいう名前でいいだろｗ
アプリ用コンテナとデータベース用コンテナは分けて
それぞれコンテナ＝1サービスにしろっていうのはそういうこと
648: 2020/11/04(水)11:14 ID:QtKCHGIC(4/5) AAS
>>646
それはあなたの感想であって、意見や主張は何も含まれてないですね
649: 2020/11/04(水)11:38 ID:g/DLzKYE(1/3) AAS
最初からDocker前提で書いてればそんな難しくはない
レガシーなシステムを大量に抱えてたら大変
650: 2020/11/04(水)12:24 ID:8vCtX8KM(8/10) AAS
>>647
でも、データベースの場合は、SQLコマンドのやり取りだけなので、データベースのデータファイルを直接オンラインストレージサービスで共有する必要はないよな。
排他制御を行うためにストレージサービス（XFS, samba）を使う場合は、ファイルレベルでの取り扱いが必要な場合だけだよね。
651(1): 2020/11/04(水)12:25 ID:mkPVUBW6(1) AAS
レガシーの移行はいっぺんにやろうとするな
VM、LXC、systemdコンテナ、Ansible、Chefなどを使って段階的に移行すべし
そもそもdockerに移行する意味があるのかはよく考えたほうがいい
652(2): 2020/11/04(水)12:31 ID:8vCtX8KM(9/10) AAS
>>647
でも、そもそもどうしてコンテナには1サービスしかおいたら駄目なのか？
例えば、名前解決させるのにdnsmasqデーモンが別途必要だとすると、これで複数サービスになってしまう。
アプリケーションという概念は、様々なサービスの組み合わせが本質だから、可搬性を考えても、それらをワンコンテナに組み込むのが自然だと思う。
即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
653: 2020/11/04(水)12:34 ID:8vCtX8KM(10/10) AAS
>>647
ストレージサービスだと、iSCSIも含んでしまう。
排他制御ができるファイル単位サービスということで、オンライン共有サービスと言った。
654(3): 2020/11/04(水)12:38 ID:3mo/cajL(1/4) AAS
>>626
ホストの同一ディレクトリを複数コンテナでマウントするだけでしょ
排他もかかるよ
655: 2020/11/04(水)12:41 ID:5mpefc2R(1/18) AAS
>>652
その考え方で概ね正しいよ
好例としてGitlabのオフィシャルコンテナも1コンテナにすべてのサービスを詰め込んで1コンテナ：マルチサービスで動かしている
そして内部的な構成管理ツールとしてChefを使っている
これは1コンテナ：1プロセスという無意味なプラクティスには反するが現実として非常にうまくいってる
ただしこの構成だと特定のコンテキストやレイヤーを抜き出してそれだけスケールアウトするのが難しくなる
デメリットはせいぜいそれぐらいしかない
656: 2020/11/04(水)12:45 ID:3mo/cajL(2/4) AAS
よく言われるのは1プロセスじゃなく1サービスだろ
WebとDBで完結して1サービスと見なせるなら分ける必要ないよ
Webを複数にして負荷分散等する予定があるとか
DBをデータマート的に多目的に使う奈良分けた方が柔軟だろうが
657(1): 2020/11/04(水)13:10 ID:g/DLzKYE(2/3) AAS
mysqlとかphpmyadminとか既存のDockerイメージあるじゃん？
なのにわざわざ苦労して手動インストールして
1つの複雑なDockerイメージにする理由がない
658: 2020/11/04(水)13:26 ID:QtKCHGIC(5/5) AAS
>>652
> 即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
する理由がない
複数コンテナを結合できるのに、一体化させる理由がないんだよね
複数コンテナをつなげるのは簡単だが、一つになってるものは分離できない
659(1): 2020/11/04(水)14:17 ID:5mpefc2R(2/18) AAS
・複数のコンテナをオーケストレーションしないと使えないサービス
・コンテナ1個動かせばOKなサービス
どっちが楽なのかは自明だろ
660: 2020/11/04(水)14:18 ID:5mpefc2R(3/18) AAS
更に既存資産があれば作るのも楽々だ
わざわざ労力をかけてDockerfileに書き直す？
ハァト…無駄な努力
661(1): 2020/11/04(水)14:21 ID:1buxXrD8(2/3) AAS
>>659
docker -composeも使えない猿未満の方？
662(1): 2020/11/04(水)14:31 ID:1buxXrD8(3/3) AAS
DBは本番だと別サーバーな事も多い
メインのDockerイメージに含まれてても容量が大きくなって邪魔なだけ
DBは自分で用意するから余計なお節介はやめろ
DBだけAWS RDS使いたければ、
元から別コンテナだったら本番で構成に含めなければ済む話
なぜsupervisordとか使って複雑にする必要がある？
663: 2020/11/04(水)16:03 ID:ZKU6KPhr(1) AAS
流行ってるからでぇ〜すｗｗｗ
たいがいこんなもんだろ
664(1): 2020/11/04(水)17:44 ID:5mpefc2R(4/18) AAS
>>661
なぜ使える使えないという個人のスキルの話に脱線するのか意味不明だよ君
dockercomposeを使わなくても簡単に動かせるならそちらのほうがいい
より簡単な方はどっちなのか？
答えは誰でもわかる、単一コンテナのほうが簡単
665(1): 2020/11/04(水)17:46 ID:5mpefc2R(5/18) AAS
>>662
ケースバイケース
既存資産があるなら1つにまとめてしまったほうが楽な場合がある
Gitlabのように戦略的に単一コンテナを選ぶ場合だってある
何でもかんでも分割すりゃいいってもんじゃない
666(1): 2020/11/04(水)17:49 ID:YAhpIihL(1/12) AAS
>>664
論理的じゃない
簡単に動かせるならそちらのほうがいい・・・とは限らないだろ
667(1): 2020/11/04(水)17:50 ID:YAhpIihL(2/12) AAS
>>665
分割したほうが再利用しやすいという話だ
668: 2020/11/04(水)17:54 ID:5mpefc2R(6/18) AAS
>>666
いやいや
同じ機能が手に入るなら簡単であればあるほどいい
難しい構成が許されるのはそれに見合う目的が必要
つまりデフォルトは限りなくシンプルに簡単に
細かくチューンナップしたいなら難しい構成を許可する
という順番がある
最初から難しい構成を押し付けるのはクソ製品
669(1): 2020/11/04(水)17:55 ID:YAhpIihL(3/12) AAS
> 同じ機能が手に入るなら簡単であればあるほどいい
自分で答え言っちゃってるわなｗ
「同じ機能が手に入らない」ので
言ってることが論理的ではない
670: 2020/11/04(水)17:57 ID:5mpefc2R(7/18) AAS
>>667
そうとも限らない
Gitlabコンテナは世界中で再利用されている
再利用するのにまったく困ることがない
もし仮にGitlabコンテナを構成するサービスが別のコンテナになっていたらオーケストレーション構成を考えるのが面倒で再利用に余計な手間がかかってしまう
671(1): 2020/11/04(水)17:59 ID:YAhpIihL(4/12) AAS
× Gitlabコンテナは世界中で再利用されている
○ GitLabサービスは世界中で利用されている
一番簡単なのは GitLabサービスなのだ
672: 2020/11/04(水)17:59 ID:5mpefc2R(8/18) AAS
>>669
はぁ
くだらない揚げ足取り
673: 2020/11/04(水)17:59 ID:5mpefc2R(9/18) AAS
>>671
話をそらすな
674(1): 2020/11/04(水)18:00 ID:YAhpIihL(5/12) AAS
そらしてないなぁ
データベースが一体化していれば
GitLabサービスの運営は大変だろう
675: 2020/11/04(水)18:03 ID:5mpefc2R(10/18) AAS
Gitlabは本当によくできている
デフォルトでは単一コンテナで最小のパラメーター設定だけで動かせるように作られてる
その上で内部サービスをオミットして別のコンテナに分割することもできる
そうする必要もないのにデフォルトの構成を複雑化させたがるバカはGitlabコンテナを見習ってほしい
676: 2020/11/04(水)18:05 ID:5mpefc2R(11/18) AAS
>>674
そらしてる
今はGitlabコンテナの話をしてる
Gitlab.comのサービスの話はしてない
677(1): 2020/11/04(水)18:15 ID:YAhpIihL(6/12) AAS
だから大抵の人にとって一番簡単なのはGitLabサービスを使うことだろ
それに対してデータベースを別でバックアップしておきたいって人にとっては
データベースは分離されていたほうがいいし
678(1): 2020/11/04(水)18:15 ID:wKYTl7Ay(1/2) AAS
>>654
ボリュームを複数コンテナでマウントするだけでは排他制御されない。
ホストディレクトリをコンテナにマウントしても同様に排他制御はかからないのではないか
679: 2020/11/04(水)18:17 ID:wKYTl7Ay(2/2) AAS
>>657
可搬性が理由だと思う。
680(1): 2020/11/04(水)18:18 ID:YAhpIihL(7/12) AAS
GitLabは全部一緒くたになってるから
間違ってコンテナを消してしまうとデータまで消えてしまう
データのバックアップも大変
安心して運用なんてできないよ
681(1): 2020/11/04(水)18:19 ID:5mpefc2R(12/18) AAS
>>677
またトンチンカンなことを
Gitlabサービスを使う話はしてない
コンテナの構成として1コンテナマルチサービスの是非を議論しているのにマネージドサービスと比較してどうすんだよ
本当に意味不明だよ君
今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
マネージドサービスの話がしたいならスレ違いだからさっさと別のスレにいけ
682(1): 2020/11/04(水)18:19 ID:YAhpIihL(8/12) AAS
>>654
排他制御の意味が違ってる。
例えばMySQLを2つ起動したとして、同じディレクトリを
参照していたらデータが壊れるだろ
ファイルは壊れなくてもデータが壊れる
683: 2020/11/04(水)18:20 ID:i96Niluf(1) AAS
github使わずにgitlab使うのは自社サーバで運用したいケースが多いんじゃね
マイクロソフト資本を嫌悪したケースもあるかも知らんが
あとデータベースのバックアップは基本的にコンテナやボリューム単位ではなくて
データベース純正のバックアップ手段使うケースが多いと思うよ
684(1): 2020/11/04(水)18:21 ID:YAhpIihL(9/12) AAS
>>681
> 今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
ほらなｗ また条件つけた。
つまりこいつにとっての「使いやすい」の基準は
「DockerでGitlabをセルフホストする」場合の話であって
誰かのためにサービスを運営する（つまりGitLabサービス）のようなものには
当てはまらないということだ
開発者なら「誰かのためにサービスを運営する」だろ？
685: 2020/11/04(水)18:24 ID:5mpefc2R(13/18) AAS
>>680
間違って消しちゃたら困るのは纏めてようが分けてようが同じ
バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
いずれの場合も、対象が1つのコンテナにまとまってるから簡単にバックアップできる
もし、これが複数のコンテナに分量外していたら、それぞれのコンテナについてバックアップを考えなければならないので大変だ
686(1): 2020/11/04(水)18:25 ID:YAhpIihL(10/12) AAS
> バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
はいそれなｗ
「一つにまとめたほうがいい」という方針の結果がそれだよｗ
そういう方法を自分で作らなければいけなくなるということ
データベースが分離されていれば、一般的なやり方がそのまま使える
GitLabに依存してないからだ。しかし一つにまとめた結果そのやり方が使えなくなり
そういうツールを開発しなければいけなくなった
687(1): 2020/11/04(水)18:26 ID:5mpefc2R(14/18) AAS
>>684
条件を付けた？
最初からこの条件で話してたらお前がマネージドサービスとの比較などというズレまくったトピックを持ち込んできたんだろ
いい加減にしろ
688(1): 2020/11/04(水)18:28 ID:YAhpIihL(11/12) AAS
>>687
お前は他人が用意したものを使うだけの話をしてるが
こちとらDockerfileを「作る側」の話をしてるんだよ
それはGitLabサービスと同じ立場だ
一つにまとめれば作るのが簡単？
GitLabのバックアップの件からも特殊なツールの開発が
必要になるってことがわかったよなｗ
689: 2020/11/04(水)18:29 ID:5mpefc2R(15/18) AAS
>>686
考えが浅すぎてため息しかでない
なにが一般的な方法が使えるだよ
Gitlabの管理するデータはDBだけじゃない
リポジトリデータやその他のサービスのデータも管理してる
これらを個別に管理したら大変だよ
個別に簡単に管理できるならGitlabはわざわざバックアップコマンドを用意したりしねーよ
少しは考えろ
690: 2020/11/04(水)18:33 ID:5mpefc2R(16/18) AAS
>>688
作る側ならより慎重に使う側の都合を考えろよ
使う側に知識と労力を期待するのは三流の開発者だ
Gitlabの開発者はdocker runさえ知ってればGitlabを動かせるように整備した
これが一流の開発者だ
691(1): 2020/11/04(水)18:34 ID:YAhpIihL(12/12) AAS
ああ、使う側って自分で開発したアプリでサービスを運営するって考えがないのかｗ
いやはや、考えが浅いなぁ
692: 2020/11/04(水)18:42 ID:5mpefc2R(17/18) AAS
>>691
利用形態は外向けサービス運営だけじゃない
むしろサービス運営のほうが圧倒的に少数派
どんな企業でも開発用の社内システムを持ってるがサービス運営をしているとは限らない
社内システムでは導入の手軽さと運用コストがまっさきに検討される
こんなことにすら考えを巡らせられないのか？
浅い
浅すぎる
693: 2020/11/04(水)18:45 ID:5mpefc2R(18/18) AAS
自分たちで作って自分たちだけで消費してるから不特定多数にイメージを使ってもらうという想定ができないんだろうな
閉じた世界で考えてるからとにかく浅い
694: 2020/11/04(水)19:02 ID:aUQpvtzl(1) AAS
自分が浅いことがバレて必死になってるなｗ
695: 2020/11/04(水)19:05 ID:7ED4Lec/(1) AAS
おや
ついに反論できなくなったようだな
勝負あり
696: 2020/11/04(水)19:14 ID:g/DLzKYE(3/3) AAS
GitLabの公式イメージが気に入らなければ
k8sでHelmチャート版使うか非公式の方入れたら良い
外部ﾘﾝｸ:github.com
既存のPostgreSQLとかRedisを使いたい！って要望に答えられないので
こういうものが作られる当然ではある
SMTPサーバーは流石にごった煮版の方もない
こればかりは一つのコンテナ内でどうにかならないからか
別にSMTPサーバー立てたり外部サービスを利用が必要
上下前次1-新書関写板覧索設栞歴
あと 306 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s