[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
551: 2020/10/03(土)19:41 ID:5u1z7vg2(7/7) AAS
>>549
設定もDockerfileの一部
552(1): 2020/10/04(日)00:03 ID:TUNorakS(1) AAS
Dockerfileでデータベースのチューニング？
なんだデータベースの設定変えてビルドし直すだけかよｗ
Dockerfileイジってねーじゃんｗｗｗ
553: 2020/10/04(日)00:19 ID:57mQTVn/(1) AAS
もう邪魔だから隔離スレ建ててそこでやってくれない？
554: 2020/10/04(日)00:21 ID:ZSOOZiph(1/2) AAS
イ・ヤ・♪
555: 2020/10/04(日)01:07 ID:qaXwAWb0(1) AAS
>>552
迷惑だってよ
556: 2020/10/04(日)02:55 ID:ZSOOZiph(2/2) AAS
いやなら見るなってだけやろｗ
557: 2020/10/04(日)08:20 ID:2aS5ndTz(1) AAS
気が触れてるな。
こいつと同じ会社でなくて良かった。
こいつの同僚はこいつと同じなのだろうか。それとも、こいつだけ…
558: 2020/10/04(日)10:54 ID:GuoVyRMr(1) AAS
docker exec あとのコマンドを補完できるライブラリとかプラグインってありますか？
559: 2020/10/06(火)12:31 ID:XVHUwg7l(1) AAS
DockerfileのLinterはありますが
docker-compose.ymlのLinterってありませんか？
560: 2020/10/07(水)14:28 ID:EbD/YQwX(1/2) AAS
docker-compose なんかローカルでのテストくらいにしか使わないのにLintもクソもないでしょ
あえてやるとしたら docker-compose.yml があったらテスト用だ本番とは違うとワーニング出すくらいだろうな
561: 2020/10/07(水)14:37 ID:li8DlbRF(1) AAS
配布するから
562: 2020/10/07(水)15:51 ID:PVmnb2tX(1) AAS
Promscale: An analytical platform and long-term store for Prometheus, with the combined power of SQL and PromQL
外部ﾘﾝｸ:blog.timescale.com
563: 2020/10/07(水)17:44 ID:r76JkEZp(1) AAS
k8sよりcomposeのほうが簡単でいい
swarmでいいじゃん
564: 2020/10/07(水)19:32 ID:EbD/YQwX(2/2) AAS
設定ファイルが多少簡単だろうと、まともなマネージドサービスがない時点で難易度MAXなのです
565: 2020/10/07(水)20:00 ID:UXg/WLQW(1) AAS
fargateは?
最近docker comoose対応したよね
566: 2020/10/15(木)08:32 ID:KVzLYuoK(1) AAS
Fluent Bit supports Amazon S3 as a destination to route container logs
Posted On: Oct 14, 2020
Customers using container services including Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Services (EKS), or self-managed Kubernetes can now send their container logs to Amazon Simple Storage Service (Amazon S3) using the Fluent Bit log router.
Fluent Bit allows customers to route container logs to various AWS and partner monitoring solutions including Amazon CloudWatch, Amazon Kinesis, Datadog, Splunk, and now Amazon S3.
Amazon ECS customers can use the FireLens interface in their task definition to configure Fluent Bit to send logs to Amazon S3.
Once you deploy your task definition, it will automatically start routing logs.
Customers using containers on Amazon EKS or self-managed Kubernetes clusters can now route container logs to Amazon S3 by installing Fluent Bit as a DaemonSet.
To get started see a FireLens example to route logs to Amazon S3 here, the Fluent Bit release notes here, and the Fluent Bit documentation here.
567: 2020/10/16(金)00:41 AAS
大切なパスワードを保存したイメージを間違ってdokerhubにうｐしちゃったらどうなるの
568: 2020/10/16(金)01:24 ID:EJhQrEIg(1) AAS
どうやったらそんなミスをするのかって悩むレベルだなｗ
569: 2020/10/16(金)23:01 ID:P+buApNN(1) AAS
パスワード変えればいい
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サービスを使うことだろ
それに対してデータベースを別でバックアップしておきたいって人にとっては
データベースは分離されていたほうがいいし
上下前次1-新書関写板覧索設栞歴
あと 325 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.037s