２ちゃんねるスマホ用 ■掲示板に戻る■ 全部 1- 最新50

■ このスレッドは過去ログ倉庫に格納されています

Docker Part3

1 ：login:Penguin：2019/03/08(金) 14:40:20.55 ID:VDOvuQ0J.net: LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/
2 ：login:Penguin：2019/03/22(金) 00:33:20.74 ID:FiEMLtVp.net: systemd nspawnがOCIに対応したらしい
3 ：login:Penguin：2019/03/22(金) 14:39:30.69 ID:sUNkazjD.net: ttps://www.phoronix.com/scan.php?page=news_item&px=Systemd-Nspawn-OCI-Runtime

コレか
4 ：login:Penguin：2019/05/23(木) 01:59:16.38 ID:0pxAwTtK.net: 古いノートパソコンがあるからそれにLinuxを入れてdocker動かしたい。
どのOSがおすすめ？k3s?

https://github.com/bargees
これも気になるけど、こいつはdockerで使うもの？ホストマシンに入れたいけどなんか違う気がしてる。
5 ：login:Penguin：2019/05/23(木) 03:04:38.08 ID:d64XEyeT.net: Ubuntu

だいたいな、Dockerは動かすものじゃない。
自分でDockerイメージを作るものだ

アプリを開発する人じゃないと使う意味がない
6 ：login:Penguin：2019/05/23(木) 10:32:28.60 ID:9kisAx48.net: >>5
>>5
アプリ開発してるよ。普段使ってるのはdocker for macだけど。
古いノートパソコンがあるからLinuxをいれてそこでdocker動かしたい。もっというとkubernetesを試したいんだけどね。
ubuntuはたしかに便利だけどもっと軽くておすすめないかな
7 ：login:Penguin：2019/05/23(木) 11:14:00.70 ID:m2jrTB8O.net: ローカルでkubernetes使ってなんか意味あるのか
8 ：login:Penguin：2019/05/23(木) 18:45:19.18 ID:vAmYTtLD.net: >>6
Xubuntuはいかが？
https://eng-entrance.com/linux-light
9 ：login:Penguin：2019/05/23(木) 20:44:26.33 ID:9kisAx48.net: >>8
guiは使いたくないです。
10 ：login:Penguin：2019/05/23(木) 21:03:05.42 ID:DjEk8nIP.net: >>9
どうせTeratermとか使ってるんだから変なことにこだわるな
11 ：login:Penguin：2019/05/23(木) 23:33:28.33 ID:0pxAwTtK.net: >>10
cui使っている人のほうがこだわるでしょ。
同じことをするなら少ないリソースでやろうとするのが技術者じゃないの
12 ：login:Penguin：2019/05/24(金) 00:19:26.15 ID:3Aok0K9B.net: 今時は同じことするなら少ない工数でやるのが偽術者
13 ：login:Penguin：2019/05/26(日) 14:39:06.95 ID:flLvlSMX.net: dockerについて勉強したいんだけどなんかおすすめのサイトとか本ある？
14 ：login:Penguin：2019/05/26(日) 20:43:21.47 ID:Kq/a2mQk.net: Qiita
15 ：login:Penguin：2019/05/30(木) 20:42:47.11 ID:q2WZulpZ.net: >>13
https://knowledge.sakura.ad.jp/13265/

Qiitaはクソ記事多いから気をつけて。
↑で手を動かしたら公式を読むようにした方がいい
16 ：login:Penguin：2019/05/30(木) 20:45:46.64 ID:q2WZulpZ.net: >>7
利点が何もわかってないのな
17 ：login:Penguin：2019/05/31(金) 07:28:23.49 ID:iKwtdlg1.net: >>16
説明して
18 ：login:Penguin：2019/06/15(土) 23:27:25.10 ID:Fpt7udoK.net: >>13
意味があるDockerの記事を読む。
19 ：login:Penguin：2019/06/30(日) 20:47:25.21 ID:EAn/wuc6.net: たとえばどれ？
20 ：login:Penguin：2019/07/01(月) 21:57:39.15 ID:Wo8yzhSo.net: Kubernetesって1GBのメモリじゃ動かない？
AWSのt3.microインスタンスで
nginx動かしたりしただけでフリーズした
21 ：login:Penguin：2019/07/02(火) 15:24:09.96 ID:LdECflCw.net: >>20
動かないんじゃないかな。
1年ぐらい前だけど調べた時に、1.7GB？ぐらいの
メモリを使用していた気がする。

あれから変わってるだろうし、記憶が曖昧だけど
Kubernetes使うのに躊躇するぐらいのメモリ使用量だった。
k3sならメモリ使用量少ないみたいね。
22 ：login:Penguin：2019/07/03(水) 08:09:42.96 ID:OU4jXyIu.net: >>21
ありがと

2GBのインスタンスタイプに変えてから再起動して
nginxだけじゃなくダッシュボードも動かしたが
それで既に700MB近かった
ちょっと他のが入ったら1GBでは足りなくなりそうだった
素のk8sでは2GBは最低必要か

k3sは噂には聞いてるが試したことない
試してみるか
23 ：login:Penguin：2019/07/21(日) 13:52:06.10 ID:Lry58weg.net: docker初心者です
portainer越しに amd64/ubuntu:{18.04,18.10,19.04}動かしてみようと思ったのですが、Deployは成功し起動するのですが次の（WEBの）リロードのときにはexit 0でストップしている状態です。
officialが駄目なのかと思ったのでunofficialなoneimage/ubuntuなどを試しましたが駄目でした。
docker hubから落としたnginxやnextcloudなどは正常に動いています。
dockerの学習過程でdocker run などのCLI でもこころみているさいちゅうなのですが、あまり上手くいきません。
考えられる原因をお教えいただければ幸いです
24 ：login:Penguin：2019/07/21(日) 13:54:11.74 ID:Lry58weg.net: 追記：冒頭の日本語おかしくてスイマセン…あと今回使っているimageは全てdocker hubからpullしました
25 ：login:Penguin：2019/07/21(日) 14:41:39.51 ID:Sr2KiGug.net: echo Hello Docker!
ぐらいしか出力しない image で、
ローカルでもリモートでも、
確実にやろうと思っていることが動かすことができますか？

それから、本当に動いているのでしょうか？
何を根拠に正常と判断していますか？
1セグメント内でサーバー群の保守運用は十分にできますか？

また、何をやろうとしているかアレですが、
docker-compose でやったほうが整理できませんか？
もっと大規模なネットワークだったら、k8s とか mini k8s とか。

がんばってください！
26 ：23：2019/07/22(月) 20:10:15.84 ID:wJonFK+K.net: 自己解決しました
portainerのデプロイが駄目っぽいのでCLIでデプロイ後、管理をportainerに渡す構成でうまく行きました
27 ：login:Penguin：2019/07/23(火) 19:16:51.71 ID:uUJhaBng.net: 初心者です。
データ分析ツールの宿題が出されたのですが、Docker上に環境構築するところからやらないといけないのですが、どのように構成させればいいかわかりません。
Docker上にはDWH(ポスグレ)、ETL(Python)、Datamart(ポスグレ)、Application(apache+php)をのせるような絵が書いてありました。
これを実行する環境を作るためには、databaseサーバとしてポスグレ、Applicationサーバとしてphpとpython、webサーバとしてapacheみたいな構造のdocker composeを設定すれば良いのでしょうか？
初歩的な質問で恐縮ですが、教えていただければ助かります。
youtubeやhpを見てもイマイチ、自分のやろうとしていることとの紐付けがわからなくて、みなさんにお聞きしようと思いました。
どうか、助けてください。
28 ：login:Penguin：2019/07/23(火) 21:15:47.48 ID:Xx2hBpa5.net: 授業か演習の時間にdockerの動作サンプルは提供されなかったの？
もしされてないのなら教員かTAに提供を要請したら？
29 ：login:Penguin：2019/07/24(水) 01:18:25.02 ID:dso6mLCs.net: >>27
まずは、それを1台のサーバ上で自力で構築できるかどうか。
それすらできないのであれば、docker-compose なんか、できっこない。
30 ：login:Penguin：2019/07/26(金) 04:44:41.07 ID:fX9V96gJ.net: 宿題は自分でやらないとだめだろう。
質問も適切であれば、教師が答えてくれるはず。
31 ：login:Penguin：2019/08/17(土) 13:47:55.78 ID:/e3AaJxo.net: Dockerの中からホストos(PC)に繋がってるUSB機器は
使える
使うようにすることができる
使えるが困難な作業付
使えない
どれだろうか
32 ：login:Penguin：2019/08/18(日) 01:14:32.94 ID:MPbnMgbj.net: キーボードは使えるだろ
33 ：login:Penguin：2019/09/05(木) 04:42:42.28 ID:l43Efl7g.net: >>27
授業まともにこなしてないからだろ
レポート提出前にいきなり焦っても駄目

学生向けの課題にこれまでやってないことをいきなりやらせるはずない
その単位は来年取りましょう
34 ：login:Penguin：2019/10/09(水) 14:49:33.81 ID:xRhiurY2.net: k8sって、masterとworkerを同じ仮想マシンにすると
負荷かけ過ぎた時にクラスタが操作不能になる？

仮想マシンを再起動しても保存されたデプロイメントとかの設定から
また同じコンテナが立ち上がって操作不能になる
シングルノードで開発はむずい
35 ：login:Penguin：2019/10/09(水) 23:40:59.79 ID:a5NgKSTJ.net: ラズパイでも使って小ノード作るべきでは
36 ：login:Penguin：2019/10/15(火) 09:25:21.60 ID:ZqB99mPI.net: dockerにwinxp入れて古いゲームできますか？
37 ：login:Penguin：2019/10/15(火) 10:16:00.25 ID:YE1RLI0J.net: まずdockerの構造を理解してください。
https://www.google.com/search?q=dockerとは？
38 ：login:Penguin：2019/10/15(火) 10:45:10.30 ID:ae5FC9b4.net: >>36
まぁ、せいぜいがんばってくれたまえ！
39 ：：2019/10/15(Tue) 11:44:06 ID:N0h53sSf.net: GUIとか犬糞以外のOS走らすのは?っしょ
40 ：login:Penguin：2019/10/15(火) 16:46:30.53 ID:ZqB99mPI.net: >>37
使用用途が全然違うわ
できんわ
41 ：login:Penguin：2019/10/15(火) 21:27:50.26 ID:qoE8jSef.net: Windows10Proでdocker動かして、windowsXPのコンテナを動かすんでしょ。
42 ：login:Penguin：2019/10/16(水) 00:41:40.20 ID:09Dygszb.net: >>36
windowsをdockerで動かすだけでもドライバ周りが地獄。

ゲーム入れたコンテナも作れるが、セーブやコンフィグデータを外に逃がす必要があり、これも難易度高い。

VMwareなどのバーチャルマシンでやる方が格段に楽
43 ：login:Penguin：2019/10/20(日) 10:45:33.06 ID:q6u5AcUs.net: dockerでvirtualbox動かしてwin載せたりするのか
44 ：login:Penguin：2019/10/21(月) 15:57:38 ID:pPKurgXC.net: https://stackoverflow.com/questions/25741904/is-it-possible-to-run-virtualbox-inside-a-docker-container/56343894#56343894

VirtualBox inside docker
出来なくは無いようだが
意味あるのか？

ホストOSで動いてる物に色々依存してるし
普通にインスコすれば良いじゃん？
45 ：login:Penguin：2019/10/27(日) 02:04:37.83 ID:gxVXDEx+.net: dockerってのはVMに対して何のメリットが在るのかサッパリ分からん。
海外のオープンソースソフトにはセットアップ面倒くさいやつは5G位の
ovaファイルとかドカンと置いているのがあって、DLさえすれば完全な
環境で動く奴が在るけど、何故それではなく、Dockerの方が良いのか
と言う説明は誰もしない。
46 ：login:Penguin：2019/10/27(日) 02:14:27.86 ID:t/s2evSD.net: >>45
Kernelをホストと共有するので、
余計なKernelのメモリ使用がない。
Kernelの起動終了を待たなくていいので、
起動終了が速い。
47 ：login:Penguin：2019/10/27(日) 18:00:44.76 ID:gxVXDEx+.net: >>46
メモリなんて今時別に気にする必要ないだろ？
16Gも積んでれば4、5台上げても何てことは無い。
48 ：login:Penguin：2019/10/27(日) 19:07:59.03 ID:t/s2evSD.net: >>47
4-5台で済むわけないでしょ、
64コアとかのCPUが普通に売ってるんだから、
サーバーも20台30台統合することを想定している、
するとKernelのメモリが無視できなくなる
49 ：login:Penguin：2019/10/27(日) 20:17:17.72 ID:fa4qpzOv.net: スケールしやすいから
50 ：login:Penguin：2019/10/27(日) 20:48:00.20 ID:bZSAAJ4S.net: 小さくて速いのかメリットじゃないって正気？
51 ：login:Penguin：2019/10/27(日) 21:11:06.05 ID:bZSAAJ4S.net: dockerは軽量なだけでなく、配布の仕組みが標準化されていて
仮想マシンと言うより
どのLinuxでも動くパッケージマネージャーの代わりのように使える

docker pullしてくればすぐに起動して使える
自分のコード追加してdocker pushして再配布も簡単

特定の仮想マシン向け、例えばVirtualBoxにイメージ作ったら
その仮想マシンでしか動かないじゃん

カーネルを含めず
その上で動くソフトウェアだけを確実にどのLinuxにも持っていける仕組みがあれば
という問題をDockerが解決した
52 ：login:Penguin：2019/10/27(日) 21:37:16.74 ID:bwtjYyKj.net: 5Gバイトはダウンロード結構掛かるから
53 ：login:Penguin：2019/10/27(日) 21:43:40.69 ID:WoCgnioW.net: 小さくて早いって言ったって、他への依存度が少ないほうが良いじゃん
と思ってVagrant使ってた。
試しにdocker使ってみて圧倒的な速さにdockerシフト。
まぁLinuxメインの人ってWindows上でも動かそうとか考えないしな。
ライブラリ、デーモン依存のところだけ解決できるコンテナはちょうどいい感じなんだよ。
54 ：login:Penguin：2019/10/27(日) 22:54:11.36 ID:bwtjYyKj.net: lxdと組み合わせるとかなりいい
55 ：login:Penguin：2019/10/27(日) 23:28:53.66 ID:xLMpHebH.net: >>45
そのメリットが理解できないのであれば、
それでいいんじゃない？
まぁ、せいぜいがんばってください！
56 ：login:Penguin：2019/10/27(日) 23:48:04.69 ID:gxVXDEx+.net: >>55
>>51見たいな回答が出来るなら、参考にもなるけど
この書込みじゃ何の役にもたたんな。
まぁ君自身理解できてないのだろうけど。
君が流行で使っても何も恥ずかしくは無いよｗ

>>48
20台も30台も作る前に普通何か工夫するだろ？

>>51
唯VMにしてOSのバージョンレベルで固めていれば
VM->開発機->検証機->本番機の全ての環境が
全く同一に作れるからね。
Dockerでおかしな作り方したら本番機ではパス違ったとかなるとダルい。
57 ：login:Penguin：2019/10/27(日) 23:49:09.12 ID:gxVXDEx+.net: >>53
Vagrant使うくらいなら確かにdockerの方が良いね。
58 ：login:Penguin：2019/10/28(月) 00:05:11.54 ID:jxo+K6ql.net: Dockerあればパッケージマネージャーの代わりになるから
パッケージマネージャー要らないじゃん！って事で
パッケージマネージャーを無くして
/usrとかのパスをリードオンリーにしたのがCoreOS

OSアップデートはOSイメージ丸ごと入れ替えで行うっぽい
59 ：login:Penguin：2019/10/28(月) 00:06:29.68 ID:BSt0sMZd.net: >>52
5Gなんて今時fullHDの動画ひとつでもそれ位在るだろ？
60 ：login:Penguin：2019/10/28(月) 00:12:27.31 ID:U3p6V+0u.net: >>56
きみに説明するまでもないからｗ
61 ：login:Penguin：2019/10/28(月) 00:16:08.14 ID:BSt0sMZd.net: >>60
分かったから、有意なレスできんなら黙ってろよｗ
62 ：login:Penguin：2019/10/28(月) 08:19:13.08 ID:U3p6V+0u.net: >>61
黙らなくてもいいでしょ♡
63 ：login:Penguin：2019/10/28(月) 08:25:05.76 ID:BSt0sMZd.net: >>62
まあ良いよ、役立たず君。
君の好きなように役に立たないレス返したまえｗ
64 ：login:Penguin：2019/10/28(月) 08:41:40.34 ID:BSt0sMZd.net: >>58
こういった書込み見るとDockerてのはOSの仮想化技術じゃなくてアプリケーションの仮想化技術やな。
軽量コンテナとか分かりにくい単語使ってくるから、イメージしづらいわ。
そらOSの仮想化と比べて早いのは当然。
65 ：login:Penguin：2019/10/28(月) 09:45:32.62 ID:JzQKnTd7.net: >>45
にたようなことを思ってたけど
前スレでdockerを分かりやすく説明してくれた人がいて、VMとは、根本的に違うと理解した
66 ：login:Penguin：2019/10/28(月) 11:33:06.56 ID:BSt0sMZd.net: >>65
一応読んだけど59～とかその辺？
それなら知っている（だからアプリの仮想化やなと言っている）
で、それがVMに対してどのようなメリットが在るのかは相変わらず分からん。
（早いとか軽いとかそういった当たり前のメリットではなく、開発でVMを使う事はそれなりに
　意味の在ることであり、それを凌駕するメリットには見えない）
67 ：login:Penguin：2019/10/28(月) 12:59:04.41 ID:ZiJ0R/5r.net: 個人レベルの利用でVMの代わりとして使うメリットなんてほとんどない
68 ：login:Penguin：2019/10/28(月) 13:05:32.81 ID:U7gDn6Np.net: >>66
確かにWindowsホスト混在の集団での開発環境だとわかるまたは技術者の習熟レベルの差によってもvmのほうが扱いやすいだろうな

ネットワーク速度と帯域消費とその他資源が無限な場合はvmに理があるだろう
69 ：login:Penguin：2019/10/28(月) 15:00:03.85 ID:KePhh8yu.net: VagrantBoxはphpとかJavaとかgoとかmysqlとかpostgresql
最初から入ってるの無くね？

Vagrantfileで自分で書く？
面倒くさいし全パッケージのバージョン固定は難しい
イメージの配布も('A`)ﾏﾝﾄﾞｸｾ

AWSはnested virtualizationも無いらしいし
VirtualBoxで作ったら高価なベアメタルインスタンス使うしかなくなるな
70 ：login:Penguin：2019/10/28(月) 15:01:37.80 ID:xtDFuCrv.net: Docker使ってたらLinuxディストリ
別に何でもよくね？
コンテナさえ動けば良いんだから
好きなの使えば良い
71 ：login:Penguin：2019/10/29(火) 03:22:38.83 ID:Ht/6B8LB.net: dockerは依存関係調べるのに手っ取り早くていい
Ubuntu minimalをrunさせればviすら入っていないプレーンなかんきょうですぐテストできる。メモリも食わない。アプリケーションのテストサーバとかいいよ。本番環境はまた別だけど。
72 ：login:Penguin：2019/10/29(火) 09:46:46 ID:MuHfEjBj.net: 本番でDocker運用するのは何か制限がある？
73 ：login:Penguin：2019/10/29(火) 15:01:21.60 ID:KeakQ8Tm.net: GoogleがKubernetesでバリバリ使ってるだろう？
74 ：login:Penguin：2019/10/29(火) 15:13:13.24 ID:VN09NAUb.net: >>71
本番でも、そのままdockerコンテナを運用すればええやん！
75 ：login:Penguin：2019/10/29(火) 17:53:37.69 ID:YHcaDCM9.net: 逆に本番をDockerライクなシステムで運用しないとローカルをDockerで作る意味が無い。
本番がVMだと二度手間になる。
（開発機作るDockerfileを作った後に本番機を手作業で構築するとか）
76 ：login:Penguin：2019/10/29(火) 21:47:10.18 ID:/JmTnPWP.net: ステートレスなアプリケーションを素早くスケールしたい場合にコンテナが有利、そんだけや
77 ：login:Penguin：2019/10/29(火) 22:18:22.69 ID:YHcaDCM9.net: >>76
このメリットでDocker使う、と言うのならDockerは大規模サービス特化型では？
ヤフオクだアマゾンだと超大規模なサービス運用したいと思うなら、そら動的にさっさと
スケールしてくれなきゃ困る。
が、それでVM技術全部を置き換えようぜ、と言われると無理が在る

ESXiであれHyper-Vであれ学習コストがほぼゼロのOS仮想化技術を
学習コストが低くは無い（そして汎用的でもない）
Dockerでと言われると、何でそんな必要が在るの？
と言う素朴な疑問が消えない。

スケールアウトは（OSごとスケールされるけど）VMにも在るからね。
78 ：login:Penguin：2019/10/29(火) 23:12:14.94 ID:/JmTnPWP.net: >>77
そう。
79 ：login:Penguin：2019/10/30(水) 04:48:02 ID:bBGMpLnQ.net: DockerをネタにVM不要論を唱えてる奴はDockerを扱ったことが無いし理解もしてないだろ
80 ：login:Penguin：2019/10/30(水) 05:11:07.07 ID:bJJYyUJX.net: >>77
逆に小規模でvm運用だとデプロイ（vmイメージのインポート？）にサーバーサービスを選ばないか？
環境構築ツールとかアプリ単位のデプロイはどうやっているの？
81 ：login:Penguin：2019/10/30(水) 07:15:27.79 ID:KYYDqpNF.net: >>80
デプロイ？
やり方は1物理鯖に1OSしか載らなかった大昔と全く変わらないのでは？
VMをインポートするとかではなくOSの中に入って作業をする。
デプロイ方法は中で動いているWEBアプリによって色々だろ。
FWがDeployer持っているならそれ使うし、もっと小規模なら改修したファイルをコピるだけとか。
設定ファイルのようなものインポートする形ならそうするし。
イントラネットでなくインターネット上のサービスならSCPとか。

VM使ったからといって1物理鯖に1OSをインストールして運用していた時代と手順が変わる事は無い。
そういった意味でもOSの仮想化は学習コストがとても低い。

初期の環境構築も手作業でrpmとかyumとかこれも変わらない。
但し1度作ってしまえば、VM複製して開発機→検証機→本番機に一気にコピる。
だから構築の手間自体は一回きり。

>>76のようなステートレスな鯖が例えば1AP鯖に対してフロントエンドに4Web鯖とか在ってバージョン
アップとか面倒臭いなと思えば1個マスタ作ってそれをVM複製するとか、そういった手段も出来るから
楽にはなった。
(昔は4WEBサーバあったら4回手作業でデプロイしていたので）

これをDockerに置き換えようと思えば、上記の説明を全部やり方変えないといけないから普通の企業
のシステム事業部には、なかなかそのメリットを納得させるのは難しい気がする。

OSの仮想化では無いから、コンテナの中にログインしても何が出来ると言う訳でもないので、その
意味でも面食らうし。
82 ：login:Penguin：2019/10/30(水) 08:13:06.87 ID:vSQkDBfX.net: >>81
＞手作業でrpmとかyumとかこれも変わらない。
但し1度作ってしまえば、VM複製して＞開発機→検証機→本番機に一気にコピる。
だから構築の手間自体は一回きり。

環境更新するたびにそれとか原始的過ぎるだろ
環境増えたら更新メンテナンスが手間
記録も残らないし戻すのも面倒くさい
それとも一度作ったら二度と更新しないとでも言うのか
83 ：login:Penguin：2019/10/30(水) 08:45:13.89 ID:R0o4MKxP.net: サーバーをペットのように可愛がるな、いつでも替えの効く家畜として扱え

AWSにも仮想マシンイメージ（AMI）があるが
必要なソフトウェアは起動してからDockerレジストリからプルすれば
カスタムのイメージは作らなくても良い

サーバーが全くインターネットにアクセス出来ない環境なら
そのプライベートネットワーク内にレジストリのミラーを作成するか
Packerを使って、必要なDockerイメージをプルした状態でAMIを作成

サーバーをペットのように扱ってるとASGも使えないだろうが、サーバーダウンは全て人間の監視を付けて対応する気か…？
84 ：login:Penguin：2019/10/30(水) 08:52:09.68 ID:KYYDqpNF.net: >>82
>それとも一度作ったら二度と更新しないとでも言うのか

逆に訊きたいけど、じゃあ月イチとかそんな頻度でやるの？
環境更新といっているのがどのレベルなのか（例えばOSのバージョン上げるとか）
と言っているのなら、そんな頻度では当然やらない。
致命的なセキュリティホールでもない限りは経験的には5年に1回とかでは？
それなら別に面倒くさいとかは無いよ。
しかもじゃあ、Dockerならノーコストで出来るのかと言うとそうでもないし。
85 ：login:Penguin：2019/10/30(水) 08:53:01.65 ID:R0o4MKxP.net: うちでは小規模な案件であれば、コンテナオーケストレーターにECSを利用している
EC2（仮想マシン）やECSのサービス（どんなコンテナを幾つ動かし続けるかの指定、docker-composeのサービスを拡張した感じ）はTerraform、CloudFormationで管理

これらが揃えば
公開するドメインなど、環境によって変えなければいけないものを除き
全く同一のソフトウェア構成で自動で構築できる
86 ：login:Penguin：2019/10/30(水) 08:53:13.76 ID:KYYDqpNF.net: >>83
>サーバーが全くインターネットにアクセス出来ない環境なら
>そのプライベートネットワーク内にレジストリのミラーを作成するか
>Packerを使って、必要なDockerイメージをプルした状態でAMIを作成

これはどう見ても余計な手間が増えている。
87 ：login:Penguin：2019/10/30(水) 09:03:08.49 ID:R0o4MKxP.net: >>84
脆弱性なんて5年に一回どころかもっと高頻度で出ると思うが
脆弱性出ないからじゃなくて
一個ずつパッチ当てるの面倒だから更新してないだけだろう？

AWSならAMIを更新してASG内のインスタンスを入れ替えれば良い
更新で出る影響は完全にインフラがコード化されていれば、テスト環境でテスト出来る

コンテナとホストOSは基本的に隔離されているので
依存性による問題が出る事はほぼない
カーネルのバグによる影響は出ないとは言い切れないが、
安定版になる前にベータ版で発見される可能性は高い

コンテナだけの更新であれば
影響範囲が限定されるし
サイズがOSより小さいので
もっと高頻度でも可能
88 ：login:Penguin：2019/10/30(水) 09:04:01.58 ID:KYYDqpNF.net: >>85
>コンテナオーケストレーターにECSを利用・・・
>>83
>Dockerレジストリからプルすれば・・・

こういうの見ると、日本でDockerが大々的に流行るのは無理と言う気がするね。

>>51 dockerは配布の仕組みが標準化されていて
>>76 Dockerのメリットは、素早くスケール

Dockerはインターネット上の標準化されたレジストリから配布を行いすばやくスケール可能なのがウリと、
が日本じゃ社員50人以下の会社が使うようなサービスはそもそもスケールの必要は無いし、
1万人超の大会社だと、お堅い会社の場合、そもそもクラウド上にアクセスする事自体を嫌うから。
ちょっと前にSalesforce売りに行ったら、ソッコーで「クラウド駄目」とか言われたわ。
大規模な会社じゃないとスケールアウト使う意味ないし、大規模な会社はクラウドを嫌う。
唯一使うとすればヤフオク、グリデナ、メルカリ、ピクシブ、とかインターネット系の大規模サービスやってる所位？
少なくともDockerを100％使い切る会社と言えば上記のようなものしかない。

後はまあ、好奇心旺盛な新興会社が使って自慢するとか、そんな感じ？
89 ：login:Penguin：2019/10/30(水) 09:15:06.02 ID:KYYDqpNF.net: >>87
そんなのお客さんと自社の状況しだいだろ？
セキュリティにうるさいお客さんなら月1回呼び出させてパッチあてやらされるし、そうでもなければ放置する
自社内のサービスなら売上げ上がっているなら、メンテはやる。
がこの話は「VM複製して＞開発機→検証機→本番機に一気にコピる。」とは関係ない。
そもそも俺は、「環境更新するたびにそれ」なんて言ってない。

まあ、なんと言うか、「パッチ当てが楽になるからDocker導入しましょう」
といって「そうですね、そうしましょう！」と言う話になるかどうかは分からない。
90 ：login:Penguin：2019/10/30(水) 09:20:59.14 ID:R0o4MKxP.net: >>88
サイボウズが1000台規模のKubernetesクラスターを自前で運用してたぞ

後はAWS Outpostみたいなのを自社サーバーで運用とか？

>>86
比較するなら
PackerかDockerかだろ
VMのイメージ作成やデプロイも手動でやっていたのでは話にならん

インターネットなしの環境でKubernetesを運用するとして
Packerを併用する場合でも
Kubernetesのバージョンアップだけ気にしていれば良いから
そこまで手間ではない
ビルドとAMI作成はCIでやる

Dockerイメージの作成もCIでやる
91 ：login:Penguin：2019/10/30(水) 09:39:49.15 ID:KYYDqpNF.net: >>90
>サイボウズが1000台規模のKubernetesクラスターを自前で運用してたぞ

これもオンプレで動くサイボウズの方じゃなくてクラウドのほうだろ？
クラウドサービスをDockerでクラスタなら分かる、軽量コンテナにうってつけだろうし。

>インターネットなしの環境でKubernetesを運用するとして

Dockerは本当にオンプレで完全に動くの？
それが出来るなら、企業のIT部門の人が勉強する意味は在ると思う。
それでも、そこに上げた名前分みても、やはり学習コストは高いと思うけど。
なんせVMwareESXiとか学習コスト殆どないし。
92 ：login:Penguin：2019/10/30(水) 15:14:19.04 ID:BfA8YI+E.net: サイボウズはオンプレミスでKubernetesを運用している

1,000台規模のインフラ刷新！ Kubernetesを採用したサイボウズが語る「NoOps」な未来 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
https://employment.en-japan.com/engineerhub/entry/2019/03/26/103000
93 ：login:Penguin：2019/10/30(水) 15:25:08.39 ID:BfA8YI+E.net: でも北米のkintoneはAWSらしい

クラウドに行く企業、クラウドをやめる企業、それぞれの事情 - 週刊アスキー
https://weekly.ascii.jp/elem/000/000/418/418894/
94 ：login:Penguin：2019/10/30(水) 16:50:12.39 ID:KYYDqpNF.net: >>92
ここでいう「オンプレで運用」は>>91でいう「Dockerは本当にオンプレで完全に動くの？」とは
意味が違うだろ？サイボウズが行っているのは単に自社のサービスを自社で運用しているといっているだけ。
91で訊いているのは、インターネットにアクセスせずに（アクセスすると偉い人に怒られるから）DevOpsを全部
導入できるのかと訊いている。見た感じ、頑張れば出来そうだけど。
95 ：login:Penguin：2019/10/30(水) 20:30:46.03 ID:F5UzNQl0.net: みんな、cndk2019は行くかな？
来月だね
96 ：login:Penguin：2019/10/31(木) 09:23:30.26 ID:kRp2coEV.net: インターネットアクセス禁止って行っても
Dockerのベースイメージはインターネットから取る必要あるよね

OSSのCIツールを導入するにも
Dockerのベースイメージはインターネットから取得する必要がある
そう考えるとCIサーバー自体にはインターネットアクセスは必要
向こうからのアクセスは無いので、NATゲートウェイ経由で
こちら側からだけアクセス可能にする
レジストリはCIサーバーと本番機のみがアクセス出来るプライベートサブネットに配置
そうすれば本番機にはインターネットアクセスを与えずに済む

Dockerレジストリのミラーを設定して
そこから取得するとしても
レジストリのミラーリングを行うサーバーにはNATゲートウェイ等で
インターネットアクセスが必要

それも駄目だったら逆に何処からソフトウェアを持ち込むんだ
USBメモリで人力ミラーリングか？
97 ：login:Penguin：2019/10/31(木) 10:03:08.19 ID:IvqXe+OC.net: イメージエクスポートしたらベースイメージも含まれてるのじゃないの？
そしたらそれを持ち込めば済むね
98 ：login:Penguin：2019/10/31(木) 11:02:49.16 ID:AgzkHmg5.net: >>97
そのやり方は普通にDockerfileを書くだけで可能なの？
そもそもDockerてのは、「ベースイメージの取得にインターネットが必要」
って事自体が保守的なIT部門の理解を得られん気がするね。
ゲストOSのインストールをするのにインターネットがほぼ必須、クラウド上にしか
イメージ置かないって言われたら「なんで？」と思うのが普通だわ。
99 ：login:Penguin：2019/10/31(木) 11:29:45.88 ID:bT1pYe7k.net: connpassにあるコンテナ系の勉強会行って各現場の導入事例を聞いてみると吉
100 ：login:Penguin：2019/10/31(木) 11:39:39.13 ID:AgzkHmg5.net: >>99
暇が無い。
結論だけ教えてくれｗ
101 ：login:Penguin：2019/10/31(木) 11:47:45.40 ID:yEAfK0sf.net: プライベートレジストリ立ち上がるダケじゃん
102 ：login:Penguin：2019/10/31(木) 12:19:36.03 ID:AgzkHmg5.net: >>101
それ１つをとっても複数製品があり、やはり学習コストが低くはない
って点がどうしようもないね。
まあ、慣れだけど。
103 ：login:Penguin：2019/10/31(木) 12:25:09.98 ID:IvqXe+OC.net: 初期状態のosでnetwork隔離環境でimageのインポートしたら問題なく環境再現できた
>>98
104 ：login:Penguin：2019/10/31(木) 13:42:54.77 ID:AgzkHmg5.net: >>103
(　´∀｀)bGJ!
105 ：login:Penguin：2019/10/31(木) 16:34:21.40 ID:yEAfK0sf.net: >>83
>サーバーをペットのように扱ってるとASGも使えないだろうが、サーバーダウンは全て人間の監視を付けて対応する気か…？

今年の8月にAWSの大規模障害あったトキお前んトコは回避できた？
AWSをペットのように扱ってるだけちゃうん？
苦情があっても全てAWSのせいにして対応する気か…？
106 ：login:Penguin：2019/10/31(木) 17:21:33.38 ID:4tcsPNQN.net: ﾖｰｰｰｰｼﾖｼﾖｼﾖｼｮｼﾖｼｮｼ
107 ：login:Penguin：2019/10/31(木) 21:49:12.88 ID:O/FSXRKR.net: 私が死んでも代わりはいるもの
108 ：login:Penguin：2019/10/31(木) 22:33:35.32 ID:AgzkHmg5.net: 実は83、本番環境持ってなかったりしてｗ
109 ：login:Penguin：2019/10/31(木) 22:47:24.60 ID:y7N0mD2n.net: みんな、マイクロサービスアーキテクチャ導入してますか？
110 ：login:Penguin：2019/11/01(金) 08:46:03.17 ID:JvLjIRFV.net: マイクロサービスって
2つのマイクロサービス間のデータのやり取りはどうする？
Dockerが解決するのはアプリのデプロイまで

マイクロソフト的には
分離性を高めるため
HTTPリクエストが来た時に別サービスへ同期的に取りに行くのではなく
バックグラウンドで予めデータを同期する方がお勧めらしい
が面倒そう
適当なことやると2つのサービスでデータの不整合が生じる
111 ：login:Penguin：2019/11/01(金) 10:48:53.56 ID:WiXsGXAx.net: webキャッシュの話？
112 ：login:Penguin：2019/11/01(金) 11:00:57.46 ID:L19v4ru9.net: 実装に関する説明をしているのにカタカナの単語説明ばかりで
具体的にこうしている、というコードが少ないアーキテクチャは駄目フラグ
て気がするけどな。J2EEでトランザクション分離がどうのこうのとか長々と
説明するけど具体的なコードもそれにふさわしくウザくて結局普及はしなかった。
113 ：login:Penguin：2019/11/01(金) 14:00:32.74 ID:b78ok99X.net: まぁ自分トコさえ便利に使いこなせればいーやってカンジなんじゃねえの
114 ：login:Penguin：2019/11/02(土) 10:34:59.86 ID:yEoeML2L.net: Amazon ECRのマネジメントコンソール
久しぶりに見ると
・タグのイミュータビリティ
・イメージのスキャン

なる機能が追加されてた

https://dev.classmethod.jp/cloud/aws/ecr-repository-scan/

古いバージョンのソフトウェア使ってて
CVEの脆弱性あったら教えてくれる機能？

あまぞんのブログURLがNGワードで書けない
115 ：login:Penguin：2019/11/09(土) 16:33:22.22 ID:xm5wCBj4.net: 「専任エンジニアが2人以上欲しい」：
Kubernetesの自前運用は難しい？　はてなの撤退事例

はてなのMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。
なぜ、Kubernetesの運用を諦めて撤退を選んだのか。
はてなのMackerelチームでSREを務める今井隼人氏が語った。
https://www.atmarkit.co.jp/ait/articles/1911/08/news009.html
116 ：login:Penguin：2019/11/09(土) 17:03:17.84 ID:r8GCENPg.net: 会員登録（無料）が必要です
117 ：login:Penguin：2019/11/09(土) 19:54:43.56 ID:j2CHsg3O.net: Kubernetesは試したけど本番環境に使う自信が無いわ
118 ：login:Penguin：2019/11/09(土) 22:53:39.06 ID:v7R6fqHc.net: >>115
当たり前。
Kubernetesクラスタを自前で運用すると言うのはアマゾンで言えばASG
を自分たちで運用しようってな物じゃないの？
何故そんなことをする必要が在るのかと。

Kubernetesのエコシステムの図一つをとってもツールだらけで
この１つ１つを学習しろと言うのか？学習コスト高すぎで馬鹿かと・・・。
しかもそこまでやっても、汎用的では無いからVMはVMで残さなければならない。。
119 ：login:Penguin：2019/11/09(土) 23:52:17.48 ID:+3c0Ii5M.net: >>115
わかる。あれ複雑過ぎ
記事読んでないけど、少数の台数で構築してもコントロール不能に陥るだけだと思う。
Kubernetesが生きるのは100台とかで、贅沢なリソースがあって
その中で何台か生きてればいい。他はそのうち生き返るって状況が作れてからからだと思う
台数が少ないと、何台か死んだら絶滅するｗ
120 ：login:Penguin：2019/11/10(日) 06:26:58.53 ID:KPJdW8/s.net: 結局Dockerは何が魅力なんや？
現段階で本番で使えないのはKubernetes？それともDocker自身？
前にもちょっと書いたけどローカルの開発機をDockerで作っても
本番機で使えないのなら二度手間になるだけだから意味が無い。
>>76見たいな話は勿論、本番環境の事を言ってるんだよな？
121 ：login:Penguin：2019/11/10(日) 09:05:56.26 ID:yayxIbvd.net: >>120
76はVMに対する「コンテナ」の利点を言ってる

kubernetesもdockerもコンテナを動かせる。両方本番で使える。
122 ：login:Penguin：2019/11/10(日) 09:33:09.58 ID:KPJdW8/s.net: >>121
そんな事は分かってるよ。両方本番で「使える」ことも分かってるよ。
でその結果>>115で止めたと言ってるんでしょ？使えるけど複雑すぎると。
でそれを読んだ俺の感想はDockerはともかく、それ以外のエコシステム含めると
学習コストも高すぎるし、本番をVMで作ってローカルの開発環境をDockerで作ると
二度手間でしかない、といっている。
で、二度手間に目をつぶってでも、取り組んだほうが良いDockerの魅力は何なのかと。
123 ：login:Penguin：2019/11/10(日) 09:51:27.54 ID:yayxIbvd.net: >>122
つまり本番＝VM、ローカル開発環境＝dockerを推してるやつがどこかにいてそのメリットは何かが聞きたいのね

俺は推してない
124 ：login:Penguin：2019/11/10(日) 09:53:10.85 ID:+DdRcUGW.net: でも猫も杓子もK8Sって感じで
後はAWS限定のECSか
Swarmってやつしか無いよね

K8Sは立てるだけならツール使えば出来るが
互換性破壊が多くてアップグレードが壁になる

はてなはテスト環境でアップグレードに失敗して撤退
kubesprayが実装をkubeadmに変えた時期と
担当者の退職・移動が重なったと

でもそれって担当者の退職が一番の原因じゃね？

移行先はEKSを検討しているらしい
ECS、Fargateは既に一部で使っていて
まずECSに移行後、EKSへの移行を目指す手筈
125 ：login:Penguin：2019/11/10(日) 10:09:27.79 ID:VIhv4B2u.net: >>120
> 結局Dockerは何が魅力なんや？

配布

WindowsのDLL Hellの話知ってるか？
昔、Windowsで大問題になってな

アプリをインストールするときに、一緒にDLLもインストールするんだが
当時はアプリにシステムDLLが含まれていたりして、
インストールするとOSのDLLを書き換えて、他のアプリが動かなくなったりした。

今ではそれが改善されて、アプリはシステムDLLを書き換えない、
必要ならアプリのディレクトリにDLLを入れたり、
.NETなんか複数のバージョンをインストールできて適切なものを使えるようになってる。

Linuxでもそれは同じでな。ディストロのパッケージだけ使ってるなら別に問題ないんだよ。
そのバージョンで動くように頑張ってるのがディストロの仕事だから

でもな、俺ら（開発者）がなにか作る時、ディストロのパッケージのバージョンを
色々考慮しないといけなくなる。ディストロアップデートしたら、そのパッケージで動くか検証したり
パッケージの新しいバージョンを使う時、それが今のディストロでちゃんと動くのか検証しなくちゃいけない。

それはつらいだろ？だからもうアプリに全部含めちゃいましょう。
というのがDockerなんだよ。（互換性が超高くて小さいカーネル以外）全部アプリに含めてるから
あちこちに簡単に移動できたり、バージョンアップできたりするんだよ。

ここまで言えば分かる通り、開発者以外にとっては関係ない道具
ディストロのパッケージ使ってるだけのやつとか、仮想マシンと勘違いしてるやつにはようはないから
126 ：login:Penguin：2019/11/10(日) 10:10:51.42 ID:VIhv4B2u.net: >>120
> 前にもちょっと書いたけどローカルの開発機をDockerで作っても
> 本番機で使えないのなら二度手間になるだけだから意味が無い。

言葉がおかしい。開発「機」を作るわけ無いだろ？

作るのは開発アプリ。それをいろんな、開発機、テスト機、本番機で
そのまま使うことができる。
127 ：login:Penguin：2019/11/10(日) 10:17:27.88 ID:VIhv4B2u.net: >>120
> 現段階で本番で使えないのはKubernetes？

Kubernetes。まあ使えないことはないと思うよ。
ただ使うためには労力が多すぎて、発想の転換に迫られる。

数台の本番環境を落ちないようにメンテすると言うより、
システム全体で稼働するように設計しないといけない

個でじゃなくて群で考えてメンテナンスの仕組みを作らないといけない
トラブルが合った時、個々のマシンを観察して情報を判断するのではなく
群からデータを集めてそれらを分析して、トラブルの原因を追跡するとか
個々のマシンをアップデートするんじゃなくて、群の中の一部分を
（半ば自動的に）入れ替わっていくという感じの設計が必要

失敗すると次から次へとマシンが落ちていって制御不能になって
最悪データの損失が発生する。

Googleみたいにすでに大量のマシンが存在して、個々のマシンの観察なんて
やってられないっていうのなら、Kubernetesの出番だけど
そうでない場合は、大変なだけ。
128 ：login:Penguin：2019/11/10(日) 10:24:02.88 ID:xpJeV64E.net: >>122
VMに対して、Dockerは「共通の部分のリソース(Kernel)は
共通で使ったほうが良くない？VMだとCPU上にほとんど変わらん
Linux Kernel複数動いとるやん！」
という提案にそうだねと思ったから使ってる。

メモリとCPU大量につみゃいいじゃん。て言われりゃ、あぁそうだね。
俺はやだけどね。ってだけだ。

たまに、また新しいもの覚えなきゃいけないんすか・・
とか言われることあるよ。そんなの右翼、左翼の違いと一緒じゃないの？
社内でVM陣営(右派)とDocker陣営(左派)に別れちゃったり。
新しもの好きの奴らのほうがハイパフォーマーが多いので
VM陣営は化石になっちゃうんだけどな。
安定度とかはどうなのよって言われると、そりゃVM陣営（保守派）。
でも、新しもの好きはそういうの気にしない。なんとかなる！とか
思っちゃってる人ばっかだから:p
129 ：login:Penguin：2019/11/10(日) 10:24:54.41 ID:VIhv4B2u.net: >>124
> でもそれって担当者の退職が一番の原因じゃね？

担当者の退職は避けられない

ってかインフラでは属人性をなくせ、暗黙知を減らせって
やってきただろ？そのための道具だったはずなのに。
属人性は無くなったが、最低限必要な技術レベルと経験が高くなりすぎてしまって
代わりになる人間を見つけるのが難しくなってしまったんだよ

構成が複雑になりすぎて、新しく入ってきた人がシステムを
理解するまで時間がかかる。それって属人性と対して変わらないから。

低い知識で十分だが、やってることはわかっても、それがなんのために必要なのかわからないし
書いてないことが多すぎて謎に包まれてる。

これが

ちゃんと書いてあるしやってることはわかるはずだが、そのためには高い知識が必要で
高い知識がないければ、意図が読み取れず、結局何をやってるのかわからない。

コレに変わっただけ。
130 ：login:Penguin：2019/11/10(日) 10:25:13.37 ID:KPJdW8/s.net: >>126
いやいや、開発「機」を作るんだろ？先ずお客さんからどのようなサービスを作るのかヒアリングして
要件定義してそれに相応しいOS、パッケージなんかを決めて本番機を念頭に「開発機」を作る。
当然VM。その後に、実際の開発を行い、
開発機の手順なりスクリプトなりをインフラの人に渡して本番機を作ってもらう。
だから開発機の構築は本番機の構築の事前準備になる。これをDockerで作っちゃったら手順も
違うし環境も違うわで、そのノウハウが全く本番機に生かせなくなる。
131 ：login:Penguin：2019/11/10(日) 10:25:44.77 ID:KPJdW8/s.net: >>125
>色々考慮しないといけなくなる。ディストロアップデートしたら、そのパッケージで動くか検証したり
>パッケージの新しいバージョンを使う時、それが今のディストロでちゃんと動くのか検証しなくちゃいけない。

これは別にDocker使うからやらなくて良いって話にはならないだろ？
132 ：login:Penguin：2019/11/10(日) 10:27:46.97 ID:KPJdW8/s.net: >>127
>失敗すると次から次へとマシンが落ちていって制御不能になって
>最悪データの損失が発生する。

こんなのVMに対するデメリットでしか無いじゃん。
VM使って在るゲストOSが落ちたから別のゲストOSも使えなくなってEXSi全体が落ちる
（或いはAmazonECS全体が落ちるとか）訊いたことないわ。
133 ：login:Penguin：2019/11/10(日) 10:31:31.60 ID:VIhv4B2u.net: >>128
VM vs Dockerとなってる時点でやばい
VMとDockerは組み合わせて使うもの。

Dockerコンテナを何個起動したって、マシン台数が
増えることを意味しないからパフォーマンスはあがらないんだよ。

パフォーマンスをあげるには、一台のスペックをあげるか台数を増やすしか無い。
一台のスペックあげるのは当たり前ですぐに限界が来るので
結局台数を増やすことでシステム全体のパフォーマンスをあげるわけだが

そのためには物理マシン数を増やすってのはクラウドで簡単に台数を増減できる時代の今
大変なだけなので却下するとして、じゃあなにか＝仮想マシン（VM）でしょ？

結局仮想マシンは使うってことは大前提なはずなんだが？
Dockerを使う理由は仮想マシンと別にあって、

パフォーマンスを上げる＝仮想マシンを増やす
増やした仮想マシンに配布しやすくする＝Docker
という結論になるはずなんだが？
134 ：login:Penguin：2019/11/10(日) 10:33:02.94 ID:VIhv4B2u.net: >>130
> いやいや、開発「機」を作るんだろ？

開発「機」を作る事自体を否定してるんじゃなくて、
Dockerを使って開発「機」を作るってのがおかしいと言ってるの

Dockerは機械はどれでも構わないってやつなんだから
機械は機械で別に設計しろ。それはDockerの役割じゃない。
135 ：login:Penguin：2019/11/10(日) 10:34:18.77 ID:VIhv4B2u.net: >>130
あんたの意見のすべてが「ズレてる」のは
Dockerの役割がわかってないからだよ。
136 ：login:Penguin：2019/11/10(日) 10:36:14.52 ID:VIhv4B2u.net: なるほどそうか。>>130の話には「開発ソフトウェア」が抜けてるんだわ
Dockerの役割は「開発ソフトウェア」に関わる話なのに
>>130にはその話が抜けてるから、Dockerがでてこない。
（出てきてるように見えるのはDockerの間違った使い方）
137 ：login:Penguin：2019/11/10(日) 10:37:42.87 ID:VIhv4B2u.net: 連投すまんね

>>130の

> その後に、実際の開発を行い、
> 開発機の手順なりスクリプトなりをインフラの人に渡して本番機を作ってもらう。

ここやね。インフラの人に渡すものはコマンド一つ程度でよくなるのがDockerだよ。
138 ：login:Penguin：2019/11/10(日) 10:37:53.72 ID:KPJdW8/s.net: >>128
いやいや保守派がどうのと言うより費用対効果だろ？
学習コストを上回る効果が得られるなら、当然やる。
めちゃくちゃに忙しいエンジニアが己の持ち時間を削って勉強するんならそれ相当の
見返りを期待するわ。

>メモリとCPU大量につみゃいいじゃん。て言われりゃ、あぁそうだね。

そういうこと。一方でサイボウズの例みたいに1つのサービスのために
1000台のコンピュータが動いていると言うなら、考慮の余地は無いから
鳴るべく軽いコンテナベースに、と言うことにはなるだろうね。

>>129

これは単に分かりやすかった筈のOSの仮想化技術、アプリケーションの仮想化技術を
「コンテナ型」とか分かりにくく言い直しただけ。
別段高い知識でもなんでもない、ワザとか何か知らないけど分かり難くしている。
　
139 ：login:Penguin：2019/11/10(日) 10:40:35.09 ID:VIhv4B2u.net: >>138
> これは単に分かりやすかった筈のOSの仮想化技術、アプリケーションの仮想化技術を
> 「コンテナ型」とか分かりにくく言い直しただけ。

まだ「個」でしか見えてないｗ

Kubernetesでは「個」で考えるのではなく「群」を作るのが前提のものだから
難しくなってるって話をしてる。
140 ：login:Penguin：2019/11/10(日) 10:40:39.49 ID:KPJdW8/s.net: >>136
ん？「実際の開発を行い」と書いているだろ？
フルスタックのエンジニアなんだから、インフラも開発も全部見るのが普通だろ？
というか、君は見ないのか？
141 ：login:Penguin：2019/11/10(日) 10:41:45.27 ID:KPJdW8/s.net: >>139
すまんね。Dockerの話をしてるのかと思ったよ。
142 ：login:Penguin：2019/11/10(日) 10:44:55.20 ID:VIhv4B2u.net: 「個」をいくつか作っていって、それを組み合わせていけば
そのうち「群」になりますよね？っていうのが従来の発想で、

まず「群」を作りましょう。「個」はその中に生まれていきます。
っていうのがKubernetes。

最初から「大群」になるのがわかってるならKubernetes一択なんだが
「個」をちょこちょこ作っていって「群」まで育てばいいなぁの世界だと
いきなり「群」を作るのは、想定外の話なんだよ。
なんでこの段階からそんなことまで考えなければいけないの？のオンパレードになるから
そういうのをやったことがある人でないとKubernetesは使いこなせない。
143 ：login:Penguin：2019/11/10(日) 10:47:22.87 ID:KPJdW8/s.net: >>137
この話で行くなら、既にDockerが本番環境でも利用される事を前提にしないと
話が進まない、と言うか導入しようぜ、とならない。

>>123がいつの間にかこんな事言っているけど、ちょっと前までは、>>71みたいに
あくまで開発者の環境という話だったはずだが？
144 ：login:Penguin：2019/11/10(日) 10:49:08.03 ID:VIhv4B2u.net: >>140
両方見るにしても分けて考えないといけない。
両方見てるだけで、一緒にしてるわけじゃない。

分離して考えて、インフラはインフラのことだけ考えればいい
（利用者などの要件に応じて、どんな規模のインフラを作るか？という話）

そのインフラに、アプリを配布するときに渡す「アプリ開発者が渡す手順書」
（どんなパッケージをインストールするのか？）
っていうの少なくて済みますよっていうのがDocker

インフラ担当はインフラの性能のことだけ考えればいいし、
（アプリ開発者が渡した）アプリを動かす手順書見て
四苦八苦しながらアプリ動かしてみせる！のはインフラの仕事じゃない
145 ：login:Penguin：2019/11/10(日) 10:51:11.25 ID:KPJdW8/s.net: >>136 >>126 >>135
スゲー不思議なんだけど、こういうレスが出る奴ってのは
自分達が開発したソフトウェアが本番環境で動作する事を
全く考慮せずに開発してるって事？
そのほうがズレてると思うが？
てか、そんなやり方で環境の差異とかで困った事は無いの？
146 ：login:Penguin：2019/11/10(日) 10:53:42.80 ID:VIhv4B2u.net: >>143
だからDockerを本番環境で使うんだよｗ

お前は今どちらの立場で考えてる？
インフラ担当の立場だろう？

お前が気にするのは、インフラの性能と
Dockerコンテナが動くための環境を用意することだけだ

作ったインフラで開発したアプリを動かす、あれやこれやの
パッケージインストール作業の仕事はしなくていい
（↑従来はインフラの仕事だった所）

なぜなら開発アプリをDockerイメージにしておけばコマンド一つとか
設定ファイルにイメージのアドレスを書き込めば終わるから
147 ：login:Penguin：2019/11/10(日) 10:58:22.55 ID:VIhv4B2u.net: >>145
> 自分達が開発したソフトウェアが本番環境で動作する事を
> 全く考慮せずに開発してるって事？
> てか、そんなやり方で環境の差異とかで困った事は無いの？

困ったことはあるよ？以前は環境の差異で手元の開発機と
本番環境で微妙にパッケージのバージョンが違ったりして
動かなかったり、動かすために本番環境に手を入れるのが大変だった。

Dockerを導入すると、そういう困ったことが無くなるって話
そこを理解すべきところなのに、Dockerの役割勘違いしてるから
それが解決されるってことがわかってないんだろ？

Dockerを導入した場合、自分達が開発したソフトウェアから見ると
本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。
（インフラの構成が違うっていうのは、一台にアプリとデータベースサーバーが
同居してるかというレベルの話で、アプリは普通に最初から分離できるように作るので）
148 ：login:Penguin：2019/11/10(日) 11:00:05.31 ID:VIhv4B2u.net: ちなみにKubernetesはインフラの構成の一つなのでインフラの話で
Dockerはアプリの配布方法の話なのでアプリ開発の話

KubernetesとDockerは組み合わせて出てきてくるから
同じ層の話だと勘違いする人が多いけど、別だから。
149 ：login:Penguin：2019/11/10(日) 11:03:51.75 ID:KPJdW8/s.net: >>146
いやいや、何でそうなるのさ？インフラ担当な訳ないだろ？
俺の書込みを見て俺がインフラ担当だと思うのなら、
本当に開発の事しかわからない、俺にとっての不思議ちゃんだわ。
マジでインフラを全く考慮せずに開発するのね。
150 ：login:Penguin：2019/11/10(日) 11:05:06.91 ID:VIhv4B2u.net: >>149
逆に聞くがお前はインフラの何を考慮してるんだ？

Docker導入したら、インフラは「性能が違うマシン」程度しか
考慮しなくて良くなるんだが、

お前は何で困ってるんだ？
151 ：login:Penguin：2019/11/10(日) 11:07:03.58 ID:KPJdW8/s.net: >>150
え？困ってるなんて一度も書いてないが？
152 ：login:Penguin：2019/11/10(日) 11:08:46.61 ID:VIhv4B2u.net: >>151
困ってないなら、インフラのことを考慮することないじゃん。

エンドポイント（例えばデータベースの接続先）のアドレスはどこか？
程度しか考慮しなくていいだろ。その先がどういう構成になってるか
アプリから知る必要はない。
153 ：login:Penguin：2019/11/10(日) 11:11:08.37 ID:VIhv4B2u.net: 念の為いっておくが、仕事全体としてインフラのことを考慮してないんじゃなくて、
アプリ開発者の帽子をかぶってるときには、インフラのことを考えなくていいって意味だぞ
インフラ技術者の帽子をかぶってるときは、逆にアプリのことは考えずにインフラのことを考える

一人で担当してるからって、ごっちゃにして考えるなよｗ
154 ：login:Penguin：2019/11/10(日) 11:11:48.12 ID:KPJdW8/s.net: >>147
>Dockerを導入すると、そういう困ったことが無くなるって話
>そこを理解すべきところなのに、Dockerの役割勘違いしてるから
>それが解決されるってことがわかってないんだろ？
>本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。

じゃあやっぱり、Dockerで開発「機」を作ってるじゃん。
155 ：login:Penguin：2019/11/10(日) 11:12:14.99 ID:xpJeV64E.net: >>133
>>>128
>VM vs Dockerとなってる時点でやばい
>VMとDockerは組み合わせて使うもの。

ちょっとまてw
Dockerを複数動かすより、VMを複数立てていったほうが良いだろ？
ってのが、最初の問いかけじゃなかったっけか？
156 ：login:Penguin：2019/11/10(日) 11:13:13.80 ID:VIhv4B2u.net: それをどう読めば開発「機」の話になるんだ？
わけがわからん。

> てか、そんなやり方で環境の差異とかで困った事は無いの？
↑ってお前が聞いたんだから、
お前は困ったことがあるんだろ？
って思ったら困ったこと無いって言うしｗ
157 ：login:Penguin：2019/11/10(日) 11:13:29.01 ID:KPJdW8/s.net: >>152
いやいや、俺が困ってるとか、俺が考慮するとかじゃなくて、
君達何を考えてるのかね？と言う話だったんだが。
158 ：login:Penguin：2019/11/10(日) 11:16:00.80 ID:KPJdW8/s.net: >>156
わけわかんねー。

本場環境の違いっていうのは、単にインフラのスペック・能力、インフラの構成が違うだけにしか見えない。

といっているのは開発したときの環境と、本番環境の差がなくなったからだといっているんだろ？
で、その開発環境は自分で作ったんだろ？要件にあわせて。
159 ：login:Penguin：2019/11/10(日) 11:16:08.54 ID:VIhv4B2u.net: >>155
> Dockerを複数動かすより、VMを複数立てていったほうが良いだろ？

だから、VMは（システム全体としての）性能を上げるために
複数立てるんだよ。

Dockerは、その性能の話と全く関係ない。
仮想マシンだろうが物理マシンだろうが関係なく、
（Dockerサーバーが動いてる）そのマシンに簡単に配布できますよ。

従来インフラ担当者に渡していた
「アプリを正しく動かすための手順書」はいらなくなりますよ。
インフラ担当者が四苦八苦してトップページ表示までたどり着く作業は
いらなくなりますよ。っていうのがDockerを使う理由だから
160 ：login:Penguin：2019/11/10(日) 11:19:46.31 ID:VIhv4B2u.net: >>158
> といっているのは開発したときの環境と、本番環境の差がなくなったからだといっているんだろ？

「差がなくなった」とは何の話をしてる？
どうも、全く同じマシンを手に入れた。って言ってるように見えるんだがｗ

開発環境と本番環境が違っていても（Dockerサーバーさえ動いていれば）
その環境の差を気にしなくていいと言ってる。

差がなくなったのではない。差を気にしなくてもいい。
（Dockerサーバーの上だけを見れば、差がなくなったとも言えるのは正しいが）

> で、その開発環境は自分で作ったんだろ？要件にあわせて。
開発環境なんて手元のMacとかだろｗ

まあ、別にどこでもいいがね。Dockerサーバーさえ動いていれば
Dockerイメージにした自分が作ったアプリは問題なく動くので。
161 ：login:Penguin：2019/11/10(日) 11:24:14.73 ID:VIhv4B2u.net: なんかもう、根本からズレてる気がするんだよなｗ

なんか本番環境と同等の開発環境を作って
そのマシンにリモートでログインしてアプリを開発する
みたいな発想をしてるように見える

まあ、昔はそれをやっていたので人のこといえんけどな
本番環境サーバーを模した開発環境サーバーにSSHログインして開発してた

違うねんｗ今の開発はそうじゃないねんｗ
どこでもやれるねん。そんな専用環境なんか作らなくて良くなったんだよ。
Dockerのおかげでね。手元の開発環境がMacであろうとWindowsであろうと
本番環境とどれだけ性能などの差があろうと

（開発環境、もしくは本番環境）のDockerサーバーの上では
性能の違いがあるだけで同じように見えるんだよ。
162 ：login:Penguin：2019/11/10(日) 11:26:52.24 ID:lF4IP4va.net: まだサーバーを家畜ではなく
ペットのように可愛がってるおじさん？
163 ：login:Penguin：2019/11/10(日) 11:28:45.59 ID:KPJdW8/s.net: >>161
>なんかもう、根本からズレてる気がするんだよなｗ

>なんか本番環境と同等の開発環境を作って
>そのマシンにリモートでログインしてアプリを開発する
>みたいな発想をしてるように見える

発想をしている、では無い。
これに対する利点を述べてくれ、とずっと要っているのだが？
それに対する利点に合点がいかなければ、その環境を例に挙げて
反論を述べている。・・・すると、おかしな勘違いする奴がいる。
164 ：login:Penguin：2019/11/10(日) 11:30:53.00 ID:xpJeV64E.net: >>161
俺、Docker便利だよ派だけど、
あなたの言い分だと、ID:KPJdW8/sが言う、
VMでいいじゃん。に対する反論になってなくない？

>違うねんｗ今の開発はそうじゃないねんｗ
>どこでもやれるねん。そんな専用環境なんか作らなくて良くなったんだよ。
>VMホスト環境のおかげでね。手元の開発環境がMacであろうとWindowsであろうと
>本番環境とどれだけ性能などの差があろうと
>
>（開発環境、もしくは本番環境）のVMホスト環境の上では
>性能の違いがあるだけで同じように見えるんだよ。
165 ：login:Penguin：2019/11/10(日) 11:46:46.44 ID:DMFKw9iR.net: 仮想マシン配布より
プライベートレジストリでDockerイメージ配布の方が楽だし
速いし
同じCPUアーキテクチャならどのLinuxディストリでも動く
Nested VirtualizationのないAWSにもそのまま持ち込める

そもそも仮想マシンには
予めPHPとかインストールされたベースイメージがない
そこから自分でやるのはちょっとめんどくさい
166 ：login:Penguin：2019/11/10(日) 11:47:03.47 ID:VIhv4B2u.net: >>164
どの言い分に対するレスなのか知らんけど、

俺は最初から、仮想マシン（VM）とDocker（コンテナ）は
組み合わせて使うと言ってる。

Dockerがあれば仮想マシンはいらないとか言ってない。
どういう反論をすれば良いんだ？

使い方が違うとしか言いようがない。
VM作るだけだとアプリの配布が面倒だろって言えばいいのか？
VMだけじゃ"足りない"だろ。としか言えんぞ？
167 ：login:Penguin：2019/11/10(日) 11:52:29.17 ID:VIhv4B2u.net: >>163
> これに対する利点を述べてくれ、とずっと要っているのだが？

利点？お前、客から要件聞いて、そこから開発環境
（専用の開発サーバー）作るお仕事をしてますって言ってるじゃん？

俺からすればなんでそんな事してるんだ？って言う話だから
利点と言うなら、要件聞かないと開発環境が作れませんなんてことにはなりません。
開発環境を作るコストが減りますといえばいいのかな？

開発環境だけの話をしてるのが謎だけど

Dockerを導入すれば（開発環境に限らず）どんな環境にでも容易に変更できます。
"本番環境"を要件（負荷等）に応じて、自社サーバーにするのも
クラウドにするのも、環境を用意に変更できます。
（という話の環境の中に開発環境も含まれてる）
168 ：login:Penguin：2019/11/10(日) 11:59:14.64 ID:KPJdW8/s.net: >>167
>>130実際の開発を行い
>>137実際の開発を行い
>>140実際の開発を行い

何度も書ているんだが、日本語読める？
てか、お前、馬鹿なんだから俺の質問にレスすするな。
おかしなレッテルの上で話を進めるから訳がわからない。
他の人はまあ、読んでると思うけど、お前は全部的を外している。
169 ：login:Penguin：2019/11/10(日) 12:15:08.94 ID:KPJdW8/s.net: >>142
何か、話が飛躍しすぎている気がする。流行りだし>>128が言うようにVMは
やがて鯖側で化石になるだろうから、Dockerで運用してみようかな？
と思わない事も無い。でもこんなにデカイのは要らないんだよなぁ・・・
2台のWeb or Socketサーバーを平日の繁忙時間だけ3台にしてくれるような
ツールは無いですかね？
170 ：login:Penguin：2019/11/10(日) 12:21:53.09 ID:VIhv4B2u.net: >>169
DockerとKubernetesの話は別だ。分けて考えてくれ。

Dockerは配布が楽になる。どこでも動かせるようになる。
そのどこでもの中の一つにKubernetesで構成した大規模なインフラも含まれるってだけ

開発したアプリがどこでも動かせるから、手元のMacでも
本番環境の物理マシンでも仮想マシンでもKubernetesで作った
クラスタ環境でも簡単に動かせるってだけ。

別にKubernetes使うのは必須じゃない。Kubernetes使ったからって
簡単になるもんでもない。逆に難しい。Kubernetesが生きるのは大規模な本番環境であって
2台のWeb or Socketサーバーを平日の繁忙時間だけ3台にしてくれるような
ツールなら、クラウドの仮想マシンオートスケールの設定でもして
その上で「Dockerコンテナを」動かせばいい。

というふうに組み合わせて使うんだよ・・・
Dockerは配布が簡単になるだけのものなんだから
171 ：login:Penguin：2019/11/10(日) 12:22:17.61 ID:VIhv4B2u.net: >>168
で？
172 ：login:Penguin：2019/11/10(日) 12:27:37.97 ID:VIhv4B2u.net: >>169
> 流行りだし>>128が言うようにVMは
> やがて鯖側で化石になるだろうから

上でも言ってるけどならんよ。

（Docker）コンテナはいくら数を増やしたって
システムの性能は上がらないんだから。

システムの性能を上げるために必要なのは
（マシンスペック強化は別として）VMの台数を増やすこと

まあクラウド側の提供として、コンテナを動かすための環境を提供して
その環境ごとに課金するタイプなら見た目上、VMはなくなったように見えるが。
でもVM単位の課金か、コンテナ環境単位の課金かの違いになっただけやねｗ
173 ：71：2019/11/10(日) 22:00:08.36 ID:hNrQ9NRe.net: 亀です。
軽くレスおってるだけで提言なんだけど、配布とか楽なのはわかる。
compose upすればいいだけ。すごく楽。

だけど保守には向かないんだよ。docker自体にログがドカドカ出す機能はないし、中のアプリケーションから何らかのものを出さないといけない。
dockerのネットワークもEsxiとかに比べたら柔軟に構築できないし、障害対応に当たるメンツの教育コストも考えなきゃいけない。

立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う
174 ：login:Penguin：2019/11/10(日) 23:34:17.67 ID:KPJdW8/s.net: >>173
>docker自体にログがドカドカ出す機能はないし
ログ自体はdocker-compose logs -f で見れるじゃん。

>dockerのネットワークもEsxiとかに比べたら柔軟に構築できないし
これやね。
Dockerは何故ルーター噛ます事がデフォルトになっているのか？
DD-WRTとかCiscoのXRVとかをそれこそ「コンテナとして」提供するならまだしも、
（ESXiはそれが出来る）勝手にルーター込みで作るとかマジで止めて欲しいわ。
アクセス自体もOSによっては「名前の解決を行っています」に1秒くらいかかって遅い気がする。

>立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う

これだと、結局Dockerは開発者のおもちゃ程度じゃん。
175 ：login:Penguin：2019/11/11(月) 00:21:42.06 ID:0/0z68zi.net: >>173
>docker自体にログがドカドカ出す機能はないし
いつものなにか勘違いしてる系だよｗ

「あなたが作った開発アプリのログ出力機能」を
Dockerのせいにするのはおかしいと気づかなきゃいけない。

開発アプリのログを出す責任は、アプリ開発者にあるでしょ？
標準出力と、標準出力エラー出力（あとファイル）を出せるんだから
ドカドカだすのはアプリ開発者の仕事だよ

> 立ち上げだけ上手くいくテスト環境にはいいけど本番環境はやっぱり難しいと思う
そういう基本を理解してない人が、間違った話をした上で、難しいと言っても説得力がない

>>174
> Dockerは何故ルーター噛ます事がデフォルトになっているのか？
ルータを噛まさないで可搬性が作れるなら、提案してみれば？

ともかく、どんなサーバーでも動かせるということは、
そのサーバーで他のコンテナが動いてる可能性もある。
だからアプリがポート番号決め打ちだとかぶって困るよね。
つまりDocker自身がポート番号の変更機能を持ってなきゃいけないんだよ。

アプリ側で変更可能にしておくのが常識だけど、それだとアプリごとにやり方が異なる
そういうのをコンテナとしてまとめて、Dockerが可搬性をもたせると主張してるのだから
Dockerの仕事になる。そこでルーティング機能がでてくる。
176 ：login:Penguin：2019/11/11(月) 00:42:22.33 ID:KWmDlLck.net: >>175
>ルータを噛まさないで可搬性が作れるなら、提案してみれば？

ESXiのゲストOSは（AmazonのEC2も）ルータなんか噛まさないだろ。
177 ：login:Penguin：2019/11/11(月) 01:06:56.91 ID:0/0z68zi.net: >>176
なんでアプリの可搬性と関係ない
ゲストOSの話なんか出てくるの？

どこでも（俺の手元のMacでも）そのゲストOSとやらが動くとでも言うのか？
178 ：login:Penguin：2019/11/11(月) 01:07:55.77 ID:0/0z68zi.net: それにゲストOSだけ動いてもしょうがないんだけどなｗ
アプリがなければただのOS
179 ：login:Penguin：2019/11/11(月) 04:37:27.59 ID:KWmDlLck.net: >>178
お前のレスは兎に角、的外れ。
それしか感想は無い。
俺以外にもそう思っている奴はいる筈
180 ：login:Penguin：2019/11/11(月) 08:39:24.72 ID:0/0z68zi.net: 的外れと言うばかりで、具体的な指摘なし
181 ：login:Penguin：2019/11/11(月) 09:43:28.79 ID:KWmDlLck.net: それは馬鹿にしゃべってもしょうがないから♪
182 ：login:Penguin：2019/11/11(月) 09:52:15.16 ID:0/0z68zi.net: という書き込みを見た人がどう思うか？
反論できな人という烙印だよ
183 ：login:Penguin：2019/11/11(月) 10:17:00.48 ID:KWmDlLck.net: 一向に構わんね。
妄想して変なレッテルを前提に、判っても居ない癖に
禄でもない話する奴に教えてあげる必要は無い。
俺さえ分かっていればそれで良い。
184 ：login:Penguin：2019/11/11(月) 11:41:48.99 ID:rpyMzwNX.net: >>120
ライブラリーやヘッダの依存関係が衝突するツールチェーンの環境作ってビルドするのにいいよ(´･ω･`)
例えば、MinGW-w64クロスツールチェーンとMinGW向けのビルドをする、llvmクロスツールチェーン(´･ω･`)
185 ：login:Penguin：2019/11/11(月) 11:48:04.65 ID:0/0z68zi.net: 本番環境でも開発環境でも
同じDockerイメージを使えるのは便利だね
186 ：71：2019/11/14(木) 05:02:43.88 ID:pJpBijFV.net: >>175
アプリケーションじゃなくてシステム運用保守の点でdocker自体の挙動の話。
>>174
すまん。logs -fは忘れていた。。。

もしdockerで管理するんだったらSNMPはホスト側で見とくんか？
あとグラフィカルな管理をお願いされたらportainerとかは限界あるけどみんなどう考えているんだ？
187 ：login:Penguin：2019/11/14(木) 05:17:15.41 ID:UYzAkhIS.net: >>186
Dockerで作ったものはアプリだってわかってるか？

お前が言ってるのは、exeを実行した時のSNMPをどうすればいいんだとか
いうわけがわからん話をしてるんだが

お前が作ったアプリがあるだろ？そこに単にDLLをくっつけただけ。
アプリが動いているかを確かめたいなら、
そのアプリに対してヘルスチェックでもすればいいだろ
188 ：login:Penguin：2019/11/14(木) 22:51:20.87 ID:5w0W9exo.net: Ubuntu18.04でAndroid版Mozcのapk作ろうと思ってるんだけど､
なんでDockerが必要なの?
C++だけで出来ないの？

Build Instructions
How to build Mozc in Docker: Android, NaCl, and Linux desktop builds.
How to build Mozc in OS X: OS X build.
How to build Mozc in Windows: Windows build.
189 ：login:Penguin：2019/11/14(木) 23:02:23.44 ID:5J9mUBHW.net: >>188
Dockerの中にまとまってる「構築手順」を
お前がそのまま実行すればできるよｗ

構築が簡単にできるように
Dockerでビルド環境を整えてるんだろ
そういうときに使う道具なんだから
190 ：login:Penguin：2019/11/14(木) 23:03:18.79 ID:5J9mUBHW.net: つくづくDockerはアプリ開発者のための道具だってわかるよなｗ

仮想マシンの代替だと思ってると、こういう使い方が思いつかない。
191 ：login:Penguin：2019/11/14(木) 23:40:17.13 ID:5w0W9exo.net: なんか知らんが､いっぱいインストールして
環境ぐちゃぐちゃにならないように､Docker使ってるの？

まあ､Dockerインストしてやったほうが楽なのかな？
192 ：login:Penguin：2019/11/15(金) 01:11:02.79 ID:v0WAyrLU.net: Docker自体は、デーモン常駐させるのにあんまし向いてないような気がする…
193 ：login:Penguin：2019/11/15(金) 01:26:14.20 ID:B8H5uf6m.net: ちょっと質問なのですが､
Dockerの中でやったほうがいいというのはわかったのですが､
mozc.pyというのはどこにあるのですか？
ファイルが見当たりません
https://github.com/google/mozc/blob/master/docs/build_mozc_in_docker.md
194 ：login:Penguin：2019/11/15(金) 01:40:01.19 ID:OT68/gV4.net: 海のもずくとなったのだ
195 ：login:Penguin：2019/11/15(金) 01:57:40.85 ID:B8H5uf6m.net: ありました､すみません｡
mozc-master/srcにありました｡

Docker使わずにPythonコマンドうったら

$ python build_mozc.py gyp --target_platform=Android
INFO: Generating version definition file...
INFO: Version string is 2.23.2815.103
CRITICAL:
==========

CRITICAL: GYP does not exist at /home/user_name/mozc-master/src/third_party/gyp/gyp_main.py.
Please run "git submodule update --init" to check out GYP.
If you want to use system-installed GYP, use --gypdir option to specify its location.
e.g. "python build_mozc.py gyp --gypdir=/usr/bin"

CRITICAL:
==========

となりました｡
どうすればいいですか？
196 ：login:Penguin：2019/11/15(金) 04:45:41.79 ID:E8h29lNR.net: どっかーとかんけいないので
どっかーにいってください
197 ：login:Penguin：2019/11/15(金) 08:24:47.38 ID:ijiYYYu1.net: >>187
相変わらずズレた事言ってんなコイツは・・・。
198 ：login:Penguin：2019/11/15(金) 08:26:05.89 ID:KYbcJ9F4.net: >>197
じゃあお前が反論しろ
何も言い返せないのにグチグチレスだけしなくていい
199 ：login:Penguin：2019/11/15(金) 10:09:47.04 ID:ijiYYYu1.net: >>198
ズレている、が反論以外の何者でもない。

>お前が作ったアプリがあるだろ？そこに単にDLLをくっつけただけ。
>アプリが動いているかを確かめたいなら、
>そのアプリに対してヘルスチェックでもすればいいだろ

何を言ってるんだお前は・・・。
200 ：login:Penguin：2019/11/15(金) 10:36:32.18 ID:KYbcJ9F4.net: なるほど。その内容が反論できる限界ってわけだ。
201 ：login:Penguin：2019/11/15(金) 10:41:28.22 ID:Se8qUwOH.net: >>195
そういうふうにならないためにdockerがあるんですがね
202 ：login:Penguin：2019/11/15(金) 16:49:32.92 ID:KFqjiKrH.net: Docker Hub から、好きなコンテナを探せば良いだけだろ

そしたら、その中に環境一式が入っている
203 ：login:Penguin：2019/11/15(金) 20:07:55.96 ID:KYbcJ9F4.net: 好きなコンテナ探して使うとか、そういう使い方じゃないよ。

Docker Hubのコンテナの正しい使い方は
1. Docker公式が用意しているものを使う
2. ディストリ公式が用意してるものを使う
3. 何らかのアプリであれば、そのアプリの公式が用意してるものを使う

それ以外は、参考イメージに過ぎない。
そんな環境が入ってるかもしれないとか思って探すものじゃないｗ
204 ：login:Penguin：2019/11/16(土) 04:47:26.32 ID:SNHSHops.net: $ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> aaaaaaaaa 10 minutes ago 5GB

となってしまってるのだが､

$ sudo docker run -it --name nonedocker none /bin/bash

だと起動しない｡
ImageID指定して起動する方法ないの？
205 ：login:Penguin：2019/11/16(土) 05:07:38.86 ID:SNHSHops.net: 出来ました
なぜnoneになってしまってたのだろう･･･

あと､ググっても出てこないのだが､
docker内でsudo apt install unzipやろうとしても
パスワードが分からなくて出来ません｡

デフォルトパスワードってなんですか？
パス設定してないのだが
206 ：login:Penguin：2019/11/16(土) 06:01:58.78 ID:c+cyy5cT.net: >>205
docker内で実行するのではなく、
Dockerfileを書きましょう。
207 ：login:Penguin：2019/11/16(土) 08:21:33.99 ID:/wQVztcY.net: そういえばみんな手書きでDockerファイル書いてる？
バッシュヒストリーとか行動をDockerファイル化するツールとか存在するの？
208 ：login:Penguin：2019/11/16(土) 08:26:36.38 ID:c+cyy5cT.net: 手作業はたいてい試行錯誤するのにその内容がそのまま使えるわけ無いだろｗ
イメージの構築手順をコード化できるのがDockerのいいところなのに
必要なとこだけメモっとけよ
209 ：login:Penguin：2019/11/16(土) 08:35:45.35 ID:aXw+ZntQ.net: >>205
元々UbuntuとかDebianベースのDockerイメージにはsudoさん入ってなくね？
Dockerコンテナ内での実行ならexecする時にユーザー変更出来るからパスワードもない

rootユーザーなら須藤さんなしでaptを実行できるが
docker execで実行してもコンテナを消した時に消える
コンテナって、儚い

普通はベースイメージに何か追加するときはDockerファイルに書いて
Dockerfileを配布か
CIツールにDockerイメージのビルドとレジストリへのプッシュをさせて
レジストリのURLを配布
210 ：login:Penguin：2019/11/16(土) 08:41:21.71 ID:c+cyy5cT.net: >>209
execのときにユーザー変更なんてあまりしないなぁ。
普通はユーザー変更するならDockerfileのUSERで変更する。

たまにアプリがrootでは動かないようになってて
そういうときにUSERで一般ユーザー権限になるぐらいだな

そういうイメージをメンテナンスするときぐらいか？
execでユーザー変更するのは。

ともかく、またDockerイメージをVMの代わりに使おうとしてるような臭いがするが
DockerっていうのはDockerfileを使ってイメージを作るものだよ
アプリの配布を楽にするために、アプリにユーザーランドを全てくっつけるために使う。
sudoが必要になることはまず無い。
211 ：login:Penguin：2019/11/16(土) 09:28:40.98 ID:KYjs1Plb.net: >>205
コンテナイメージは何をお使いですか？
sudoなしで試してみるとどうですか？
212 ：login:Penguin：2019/11/16(土) 15:07:13.24 ID:M11z94Ko.net: 管理者は、CentOS なら、ユーザーをwheel グループに追加するのでは？
visudo で、/etc/sudoers を開いて編集するとか、間違えると恐ろしい手順！

Debian 系は、知らないけど

>>207
ヒストリーは、head .bash_history と入力すると、
以下のように行区切りで、コマンドが表示される

だから、こういう単純なテキストファイルを作って、Docker に含めて、コピーすれば？

man unzip
exit
man gunzip | less
exit
213 ：login:Penguin：2019/11/17(日) 16:34:04.52 ID:DepsKVcB.net: >>212
別にlivebootで /etc/sudoers あたりをいじればいいでしょ。
214 ：login:Penguin：2019/11/18(月) 02:59:04 ID:fwqLgOPw.net: これやってMozc/Androidをインストールしようとしてます｡
https://github.com/google/mozc/blob/master/docs/build_mozc_in_docker.md

Set up Ubuntu 14.04 Docker container

$mkdir ubuntu14.04 && cd ubuntu14.04
$curl -O https://raw.githubusercontent.com/google/mozc/master/docker/ubuntu14.04/Dockerfile
$sudo docker build --rm -t $USER/mozc_ubuntu14.04 .
$sudo docker run --interactive --tty --rm $USER/mozc_ubuntu14.04

をやりました｡

次に､
$sudo docker run -it --name docker1 012345abcde /bin/bash
でDockerにコンテナを作り､ログインしました｡

Build Mozc for Android:

$python build_mozc.py gyp --target_platform=Android
$python build_mozc.py build -c Debug android/android.gyp:apk

をやりました｡
mozc.pyというファイルがないです｡
ビルド出来ません｡どうしたらいいですか？

ちなみにwget使えないのでファイルダウンロードできません｡
apt installも出来ません
215 ：login:Penguin：2019/11/18(月) 05:11:31.78 ID:526otgY3.net: > $sudo docker run -it --name docker1 012345abcde /bin/bash
> でDockerにコンテナを作り､ログインしました｡

そんな手順があるわけない
216 ：login:Penguin：2019/11/18(月) 06:33:49 ID:526otgY3.net: スレ違いだしリンク先を読む気はさらさらないが、
Dockerを使ったビルドでやることは決まってる。

1. Dockerのインストール。Dockerを使う以上これは自分で準備する必要がある。
2. ビルドスクリプトを動かす言語、つまりその場合はpythonを準備する必要がある。
3. ビルドスクリプト。ソースからのビルドならソースに付いてるだろ。

以上。準備するのはこれだけ。
まともなビルドスクリプトであればDockerを直接触ることはない。
せいぜい不要になったものを削除するぐらいだろう

ビルドに必要なものは勝手に準備してくれる。
Dockerコンテナの中に入って作業することなど無い
217 ：login:Penguin：2019/11/18(月) 07:56:02.68 ID:ESYqS5lO.net: >>214
プログラミング少年？

子供には優しく教えてあげよう。
>Build Mozc for Android:
>
>python build_mozc.py gyp --target_platform=Android
>python build_mozc.py build -c Debug android/android.gyp:apk
って書いてあるよ。
中学生以上なら頑張って英語読もうね。
218 ：login:Penguin：2019/11/18(月) 07:57:34.77 ID:ESYqS5lO.net: おっと、俺は日本語を読んでなかった。
手順にコンテナに入れなんて書いてないよ。
219 ：login:Penguin：2019/11/18(月) 10:46:05.98 ID:C4AZd6Pu.net: Dockerの利点のlibに依らないってスタティックビルドすりゃええやんって気もする
220 ：login:Penguin：2019/11/18(月) 10:54:21.15 ID:NkkjQGwg.net: >>219
ウェブサービスで使われるスクリプト言語は
ソースファイルがそのまま必要だし、
バイナリにできるとは限らないし、例えバイナリにできたとしても、
ffmpegコマンドを呼び出すなんてのはスタティックビルドにできないし
考えが浅すぎるよ
221 ：login:Penguin：2019/11/18(月) 12:48:26.38 ID:yWgPvH2u.net: >>220
全体的に同意だが
ffmpegはバイナリ置いとけば呼び出せるのでは？
222 ：login:Penguin：2019/11/18(月) 12:52:17.51 ID:rYgoyQ9U.net: そのffmpegが依存しているものは？
apt-getで簡単に入るものに対して頑張ってスタティックビルドするの？
ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが
223 ：login:Penguin：2019/11/18(月) 13:39:47.60 ID:3lFA7L7g.net: いやそもそもDockerという環境の為に普通のビルド方法を変更すること自体
どうかと思うが？Docker以外の環境ではMakefile書き直すの？
224 ：login:Penguin：2019/11/18(月) 14:33:41.37 ID:3lFA7L7g.net: >>214
そもそもこれ、最初のビルドは上手くいくの？
gitにアップしたのが2017年12月？
ssl絡みでdocker buildがエラーになるはずだけど？
225 ：login:Penguin：2019/11/18(月) 15:38:00.63 ID:rYgoyQ9U.net: >>223
Dockerは環境じゃないんだが？
この場合は、buildってやったら、ビルドバイナリを生成するツールってだけ
226 ：login:Penguin：2019/11/18(月) 16:43:57.10 ID:3lFA7L7g.net: >>225
dockerが環境で在るかどうかなんて、どうでも良い話。
単にDockerのためにMakefileを書き換えるというなら違和感を感じる
といっているだけ。
227 ：login:Penguin：2019/11/18(月) 16:58:16.40 ID:rYgoyQ9U.net: >>226
わざとやってんのか本気で馬鹿なのか
後者なんだろうけど、お前の言うMakefileの中で
Dockerを使ってビルドしてるだけの話
228 ：login:Penguin：2019/11/18(月) 17:00:30.59 ID:rYgoyQ9U.net: スタティックビルドの話でもそうだが
C/C++の開発経験しか無いんじゃないだろうか
経験が浅すぎる
229 ：login:Penguin：2019/11/18(月) 17:01:13.27 ID:rYgoyQ9U.net: makeだけがビルドツールではない。
ヒントな
230 ：login:Penguin：2019/11/18(月) 17:07:27.72 ID:3lFA7L7g.net: >ffmpegは依存してるものが多すぎてビルドはかなり大変なんだが

こんな紛らわしい書き方するからだろ。
configure一発でいけるなら別に大変でも何でもない。
231 ：login:Penguin：2019/11/18(月) 17:09:34.70 ID:rYgoyQ9U.net: > configure一発でいけるなら別に大変でも何でもない。

configure一発でいけないから大変
232 ：login:Penguin：2019/11/18(月) 17:14:47.57 ID:rYgoyQ9U.net: Docker使えば普通にapt-get使って、それをそのまま一つのイメージにすることができる。
このイメージを使えばどの環境でも同じように動く。

どの環境でも動くようにするために、スタティックビルドすればいいじゃんと言うが、
オレオレビルドなんて、今の時代はやらない上に、
スタティックビルドにするために、いろんなライブラリをかき集めて
configureを通すとか時間の無駄。

Dockerなら普通にapt-get使って、どこでも動くイメージが作れる。
233 ：214：2019/11/18(月) 20:55:15.76 ID:fwqLgOPw.net: みなさんありがとうございます

>>224
これですね､多分
なんか赤文字連発したり途中で終わってる感抜群だしで､
Dockerfileのビルド自体失敗してるくさい
234 ：214：2019/11/18(月) 20:56:14.75 ID:fwqLgOPw.net: これUbuntu18.04LTS使用だとDockerfile書き直せばいけるの？
てか､Dockerの中身をそのままDocker使わずに普通にコマンドラインで打っても行ける？
235 ：214：2019/11/18(月) 21:00:34.90 ID:fwqLgOPw.net: dockerfile見るとこうなってるじゃん

$ apt install -y clang python pkg-config git curl bzip2 unzip make

やっぱ､これらのコマンドすらインストールされてないから､ビルド失敗してるわ
コマンド打ってもコマンドなしになるもん
236 ：214：2019/11/18(月) 21:04:18.13 ID:fwqLgOPw.net: mozcのDockerfileは､2018年1月更新となってますが､やっぱり古すぎですか？

Update the copyright year to 2018

REF_BUG=
REF_CL=180466480
REF_TIME=2018-01-01T00:00:18-08:00
REF_TIME_RAW=1514793618 -0800
237 ：login:Penguin：2019/11/19(火) 00:19:14.15 ID:TB1GOjb/.net: >>235
それは全く関係ない
238 ：login:Penguin：2019/11/19(火) 01:50:39 ID:H229ozOy.net: >>232
windows とlinuxでコンテナの互換性ないよ。同一OS上は可能だが、何処でもは無理
239 ：login:Penguin：2019/11/19(火) 02:00:20 ID:TB1GOjb/.net: >>238
だからWindowsとmacOSではLinux仮想マシンを使ってるんだよ。
結果、Windows（とmacOS）上でもLinux用のDockerコンテナがそのまま使える
240 ：login:Penguin：2019/11/19(火) 02:19:42 ID:TB1GOjb/.net: それとWindowsのWSL2では仮想マシンでLinuxカーネルをそのまま使うので
Linux用のDockerコンテナが、公式サポートと言っていいレベルになる。
つまり今はDockerが仮想マシンイメージを作っているが、それが不要になる。

それだけかと思うかもしれないが、大きな違いが2つある。
一つはメモリ使用量。一般的には仮想マシンにある一定のメモリを割り振らなければいけないが
WSL2ではMSがカーネルに手を入れているため、Windowsとメモリを共有できる。
Linux上でDockerコンテナを動かしたのと殆ど変わらないメモリ使用量になる。
これは従来の仮想マシンを使うmacOSでは難しい（ある程度は仮想マシンのメモリを開放しているようだが）

そしてもう一つは、これは俺の予測だが、Ubuntuなどのディストロを使わずに
DockerがWSL2上でそのまま動くようになる可能性がある。
今、Dockerが提供しているDockerサーバーはHyperV上でDockerDesktopVMという
Linuxカーネルを使用するための軽量仮想マシンを動かしているが、
WSL2では複数のディストロがLinuxカーネルを共有する。

Dockerが動作するのに必要なのは、原則としてLinuxカーネルだけなので
WSL2でLinuxカーネルがすでに動いているとしたら、理論上はDockerサーバーは
WSL2の/initから直接起動することが可能となる。
将来のDockerは今のUbuntuと同じように、Microsoftストアからインストールする
単体のサーバーアプリ相当になるだろう。
241 ：login:Penguin：2019/11/19(火) 02:22:53 ID:TB1GOjb/.net: >>238
あと、当たり前だが、どこでも同じように動くというのは
「"Linux用Dockerが動く環境なら"どこでも同じように動く」という意味だ。
さすがにFreeBSDでもSolarisでもPS5でも動くとかそういう話はしてないｗ
242 ：214：2019/11/19(火) 21:32:25.81 ID:BbWOlht1.net: mもしかして､Android版Mozcのapk作るのって
ここにあるソースとAndroidStudioだけで出来る？
AndroidStudioならSnapにあるから楽なんだけど
https://github.com/google/mozc/tree/master/src
243 ：login:Penguin：2019/11/19(火) 21:56:56.17 ID:4mU598Ua.net: もう完全なるすれ違い。
244 ：login:Penguin：2019/11/19(火) 22:18:46.60 ID:bNC5wdZW.net: Docker 19.03.5リリースされたけど、Mac版でまれにフリーズする問題、まだ直ってないね。

for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done

https://github.com/docker/for-mac/issues/3873
245 ：login:Penguin：2019/11/20(水) 08:58:20.86 ID:S7eWFdSu.net: WSL2がWindows10のSlowRingにも来た

不安定で、かつ頻繁にアップデートするFast Ringじゃなくても
dockerが動かせる
246 ：login:Penguin：2019/11/20(水) 09:05:12.41 ID:Ea4P6MqO.net: ん？前から来てなかったっけ？
別件でfast ringに変えたけど、
ちょっと前までslow ringで試してたはずなんだが
247 ：login:Penguin：2019/11/20(水) 09:07:41.54 ID:S7eWFdSu.net: 11月11日に来たみたいだ
ちょっと前と言えば前だけど

https://blogs.windows.com/windowsexperience/2019/11/11/releasing-windows-10-insider-preview-build-19013-into-the-slow-ring/
248 ：login:Penguin：2019/11/20(水) 09:25:06.47 ID:Ea4P6MqO.net: これだな。WSL 2対応のDocker Desktop
https://forest.watch.impress.co.jp/docs/news/1191014.html
249 ：login:Penguin：2019/11/20(水) 12:28:20.58 ID:CdtAMkQV.net: なんつーかDockerて誕生してから5年経過してると思うけど
未だこんなレベルなのか・・・。
250 ：login:Penguin：2019/11/20(水) 12:31:30.80 ID:ggOPHuIR.net: >>249
お前は5年前から何も変わってないなｗ
251 ：login:Penguin：2019/11/20(水) 13:11:34.50 ID:CdtAMkQV.net: >>250
馬鹿じゃね？お前に何が分かるんだよ？
相変わらずこのスレには禄でもない奴が住んでるな
どっか消えろよ。
252 ：login:Penguin：2019/11/20(水) 14:53:40.23 ID:/X658f56.net: >>249
未だにWindowsでネイティブ動作しない事？
253 ：login:Penguin：2019/11/20(水) 15:03:02.97 ID:3GvUfUkB.net: Windowsにもコンテナはあって、
Dockerはそれに対応してるから
Windowsネイティブで動作する。
254 ：login:Penguin：2019/11/20(水) 21:23:08.90 ID:sHwSvmkR.net: わざわざwindows使う必要はないよね
255 ：login:Penguin：2019/11/20(水) 21:31:36.45 ID:LkT1k2Et.net: 通常はパソコン買ったらWindowsなので、
どちらかと言ったらLinuxを使うほうがわざわざ

それ抜きにしても開発ツールとかオフィスソフトとか
結局Windowsを使うことになるので、
Windowsで何でもできると助かる。
256 ：login:Penguin：2019/11/20(水) 23:51:14.99 ID:sHwSvmkR.net: 君の事情を前提にされてもね
257 ：login:Penguin：2019/11/21(木) 01:09:43.37 ID:vRlrhYkO.net: Windowsは・・つかわんな。
たまに使うと、アップデートが動き出して、そのまま電源ブチッと。
そのうち起動しなくなるんだよな。。
258 ：login:Penguin：2019/11/21(木) 01:23:24.20 ID:ad2tUsdT.net: 使わんのに文句言ってるのが意味わからんわｗ
259 ：login:Penguin：2019/11/21(木) 06:51:54.46 ID:WFHWRF4b.net: 使わない理由、参考になるわ
260 ：login:Penguin：2019/11/21(木) 07:14:33.37 ID:GapdKj+E.net: 使わない理由なんてどこかに書いてあったっけ？
261 ：login:Penguin：2019/11/21(木) 07:28:23.60 ID:WFHWRF4b.net: windowsを使わない理由、参考になるなと。
262 ：login:Penguin：2019/11/21(木) 07:35:34.84 ID:N+RiIX1p.net: OSシェア9割のwindowsを使わないと宣うDocker使いｗ
Docker過疎化不可避やなｗ
最も何年経ってもサーバーサイド以外じゃ普及してないけど。
263 ：login:Penguin：2019/11/21(木) 07:37:11.19 ID:65iJLiNO.net: ん？たった一人使わないって人が出てきて、理由も意味不明
それに賛同って自作自演かいな？ｗ

Docker Desktop for Windowsあるんだし普通に使ってるよ。
WSL2に対応したDocker Desktopの登場楽しみ。
いろいろ改善されてるんだろうな。
264 ：login:Penguin：2019/11/21(木) 07:49:43.07 ID:WFHWRF4b.net: 人間が作業するOS
コンテナが動作する環境としてのOS

分けて
265 ：login:Penguin：2019/11/21(木) 08:01:46.15 ID:65iJLiNO.net: そこは人間が作業するOSじゃなくて
コンテナイメージを作成するOSとした方が分かりやすい。

Windowsでコンテナイメージを作って
Linuxでコンテナを動作させる
典型的なパターン
266 ：login:Penguin：2019/11/21(木) 08:06:22.06 ID:WFHWRF4b.net: リポジトリへのpushをトリガにCICDで作りましょう
267 ：login:Penguin：2019/11/21(木) 08:07:20.08 ID:65iJLiNO.net: いや開発中の話。アプリのソースコードを修正するたびに
pushしないといけないとかやってられない。
ローカルで開発しローカルでテストするのが普通
268 ：login:Penguin：2019/11/21(木) 08:10:31.97 ID:WFHWRF4b.net: 限定しないで
269 ：login:Penguin：2019/11/21(木) 08:16:49.00 ID:65iJLiNO.net: 限定してるのはお前じゃね？

限定しないなら、開発中の話をしてもいいよね。
270 ：login:Penguin：2019/11/21(木) 08:18:12.18 ID:WFHWRF4b.net: 典型的なビルドパターンの話かと思ったら
いや開発中の話って言い出すから
271 ：login:Penguin：2019/11/21(木) 08:31:25.95 ID:A30K4AWa.net: 俺は最初から開発の話しかしてないが？

仮にビルドの話だと思ったとしても、
その後で開発の話だって言ってるんだから、
その後の「限定しないで」はおかしい。

開発の話だと気づいたなら、そこでビルドの話に
限定しようとしてはいけない。
272 ：login:Penguin：2019/11/21(木) 08:57:06.37 ID:WFHWRF4b.net: ビルドってイメージのビルドのことだけど、アプリのビルドと思ってるってことはない？
273 ：login:Penguin：2019/11/21(木) 09:11:08.79 ID:/owMVVXl.net: Windows上でLinuxアプリは直接動かないって知ってる？
Dockerイメージにしてから動かすんだよ。
ソースコードを修正するたびにDockerイメージを作るだろ。
そのたびにいちいちpushとかしないって話をしてる。
274 ：login:Penguin：2019/11/21(木) 09:29:32.27 ID:N+RiIX1p.net: ここ本当に実務で使ってる人居るの？
CICDはデプロイ、リリースする時の話
開発時ABCDEとかいろんな機能を同時に開発される
このうちBCEだけリリースするとなったらCICDで、と言う話では？
（元のブランチにBCEをインテグレートする）
ABCDEが混在してるローカル環境では当然ローカルで開発して
ローカルでテストする。
単体試験も通らないのにCICDとかある訳無いじゃん。

>典型的なビルドパターンの話かと思ったら
>いや開発中の話って言い出すから

これも意味分かんね。
開発してない時にビルドなんてしないだろ。
275 ：login:Penguin：2019/11/21(木) 09:42:58.32 ID:/owMVVXl.net: >>274
それがDockerの話と何の関係があるの？

Dockerはどこでも使えるんだから、
CI/CDに限定するなよってだけだろ
276 ：login:Penguin：2019/11/21(木) 09:45:58.81 ID:/owMVVXl.net: 例えば上の方でうざかった、mozcのビルドでも
Dockerを使ってるわけだが、これはCI/CDですかって話
これは大雑把に言えば、Dockerをビルドツールとして使ってる例
277 ：login:Penguin：2019/11/21(木) 09:47:42.48 ID:/owMVVXl.net: × Dockerはどこでも使えるんだから、
○ Dockerはどこでも色んな用途で使えるんだから、
278 ：login:Penguin：2019/11/21(木) 10:20:46.87 ID:N+RiIX1p.net: >>275
じゃあお前だけ「Docker専用スレ【周辺ツールの話厳禁】」
とかスレ立てれば？誰も見ないだろうけどｗ
279 ：login:Penguin：2019/11/21(木) 10:24:04.76 ID:/owMVVXl.net: CI/CDの話をしたいなら、専用のスレを建てるべきでは？
280 ：login:Penguin：2019/11/21(木) 10:59:47.95 ID:N+RiIX1p.net: CI/CDの話がしたい訳ではなく何処から見ても間違った
書込みが在るから突っ込んだだけ。
281 ：login:Penguin：2019/11/21(木) 11:18:46.18 ID:HDHYI6wX.net: 間違っている点を指摘せよ
282 ：login:Penguin：2019/11/21(木) 11:39:14.38 ID:N+RiIX1p.net: >>266-272
CI/CDは>>274の使い方が本筋なのに>>267はAと言う機能の開発中の話しを
しており>>266は多分それ自体が何の話か分かってない。
283 ：login:Penguin：2019/11/21(木) 12:12:15.85 ID:HDHYI6wX.net: >>282
時系列が逆

>>267はAと言う機能の開発中の話しをしているのに、
そこに後からやってきた>>274がCI/CDの話を持ち込んだから
関係ない話をするなと言われている。
284 ：login:Penguin：2019/11/21(木) 13:20:07.35 ID:RlDz2JW5.net: 開発体制にもよるからな
ベストプラクティスは現場によって変わるのよね
Dockerの使い方然り
285 ：login:Penguin：2019/11/21(木) 16:33:18.22 ID:N+RiIX1p.net: >>283
いやいや>>266が最初にCICDの話し振ってるだろ。
読めよ。そこでCICDを念頭に話が進んでるのに
それ以降のやり取りが全部トンチンカンだから
>>274と言っている。
286 ：214：2019/11/22(金) 06:39:20.17 ID:V7Ju8Agz.net: お前ら､そんなことよりMozc公式のソース使ってMozcのapk絶対にビルド出来ないぞ
やっぱソースがおかしいの？
誰か試してみて

ちなみにDocker内だけじゃなく､Virtualbox上でUbuntu18.04使ってやってもだめ
AndoroidStudio使ってもだめだった
https://github.com/google/mozc
https://github.com/google/mozc/blob/master/docs/build_mozc_in_docker.md
https://github.com/google/mozc/blob/master/docker/ubuntu14.04/Dockerfile
287 ：login:Penguin：2019/11/22(金) 07:06:19.92 ID:QgSJ5ulH.net: >>286
多分これだろうなと言うアタリは在るけど、ビルドに30分以上掛かるから
自分の仕事ならともかく、匿名掲示板の誰かのためにやる気は無いｗ
エンジニア全員に30分以上のビルドを強要するとか、これもDockerのデメリットだろうね。

マジで作者はVM上で作って「sudo docker build --rm -t $USER/mozc_ubuntu14.04 」した
後のイメージをovaでおいとけよ、と思うね。
そうすりゃ未来永劫同じ状態から作業開始できるのに、Dockerfileだとたった2年でもう使えなくなるとかｗ
288 ：login:Penguin：2019/11/22(金) 07:17:46.41 ID:uIlZ/kOu.net: >>287
ビルドに時間がかかるのはDocker関係ないだろ
ほかスレでDocker使わないでやってやれよ。
289 ：login:Penguin：2019/11/22(金) 07:48:36.03 ID:QgSJ5ulH.net: >>288
>>287のやり方なら、ビルドに時間をかけるのは作者が1回だけ。
ビルドした「後」のイメージを配るからダウンロードした開発者が
もう一度やる必要は無い。
そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。
290 ：login:Penguin：2019/11/22(金) 08:11:13.13 ID:uIlZ/kOu.net: >>289
だからDockerは開発者のためだってことだよ。

VMイメージを配布するぐらいなら
ビルド済みのバイナリを配布すればいいだけじゃん。

開発者（そしてビルドしたい人）が楽にビルドするためにDockerがあるんだよ。
開発者がDockerでビルドしたら、同じ手順で他の人もビルドできる。

Dockerのビルドが失敗してる原因は、curlでとってくる外部パッケージの更新に
対応してないからでVMを使ってもビルドは失敗する。
外部パッケージまでVMに含めて配布しろって言うなら、
Dockerでも同じことはできる。

アホか
291 ：login:Penguin：2019/11/22(金) 08:12:57.12 ID:uIlZ/kOu.net: だいたい、元のやつが

> なにやってもビルドで失敗します｡
> Docker内でやってもUbuntu18.04上でやっても失敗します｡
> AndroidStudioでやってみたけどこれもだめです｡

って言ってるだろw
VMでやっても失敗すると思わなかったのか？
292 ：login:Penguin：2019/11/22(金) 08:33:02.57 ID:QgSJ5ulH.net: >>291
平日に連投できると思ったら、君はきっとニートなんだろうね。

> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。

ポイントはここだろ？
時間単価のクソ高いエンジニアにこんな強要するなよって話でしかない。

>対応してないからでVMを使ってもビルドは失敗する。

リビルドして失敗するのは別にかまわない。
先ず動いてるところを見せろよって話。
30分以上時間つぶして動きもしないとかクソ以外の何者でもない。
総じて「コスト」と言う概念を一切無視して話するから、話が全く通じてない。
293 ：login:Penguin：2019/11/22(金) 08:36:50.57 ID:uIlZ/kOu.net: >>292
30分待った挙げ句失敗するのは、
VM使っても同じだって言ってるんだが？

もしかして失敗する原因わかってない？
curlでとってくるzipが新しくなって、ビルドできなくなってるんだよ。
VMでもcurlでzipをとってくるなら同じように失敗するし、
そのzipをVMに入れて配布すればいいって言うなら、
Dockerでもリポジトリに入れて配布すればいい
294 ：login:Penguin：2019/11/22(金) 08:46:08.87 ID:QgSJ5ulH.net: >>293
マジ馬鹿なの？

>リビルドして失敗するのは別にかまわない。

と言ってるじゃん。

> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。

と言っているのはビルドの次の作業から開始してビルドをしないんだから
「時間を無駄に」することも無い、と言っている。
ビルド失敗の原因がどうのこうのなんて関係ない
もうお前、時間の無駄だから俺にレスするな。
コストの概念の一切無い暇人と会話しても同じ風景見ても出てくる
結論は正反対なだけだｗ
Mozcの人がDockerで困ってるんだろ？
解決してやれよｗ
295 ：login:Penguin：2019/11/22(金) 08:49:48.98 ID:uIlZ/kOu.net: >>294

> そして30分待った挙句に失敗して時間を無駄にすると言うことも無い。
ポイントはここなんだろ？

リビルドして失敗するのは構わないなら、
お前が言った30分は何の問題もないだろ

VMでも30待った挙げく失敗するってのわかってるか？

それともDockerはキャッシュがあるから、途中で失敗したら
そこから再開できるので時間が無駄にならないのを知らんのか？
296 ：login:Penguin：2019/11/22(金) 08:52:42.78 ID:uIlZ/kOu.net: > ちなみにDocker内だけじゃなく､Virtualbox上でUbuntu18.04使ってやってもだめ
と書いてあるから、最初からDockerの話題じゃない。
だからこのスレでやるのは間違いだって言ってる。
297 ：login:Penguin：2019/11/24(日) 10:15:58.87 ID:gVQp9hOZ.net: >>286
※亀
※プロンプト>はホスト、$はコンテナ内

> vim Dockerfile
L69はコメントアウト
#RUN cd nacl_sdk && ./naclsdk install pepper_49

※一旦これでBuildして最後まで抜ける

> sudo docker build --rm -t $USER/mozc_ubuntu14.04 .

※rootでログイン

> sudo docker run -u root --interactive --tty --rm $USER/mozc_ubuntu14.04
$ apt install python-pip
$ pip install --upgrade httplib2
$ su - mozc_builder
$ vi ./work/nacl_sdk/sdk_tools/download.py

※L18-19をコメントアウト
19 # ca_certs = os.path.join(SCRIPT_DIR, 'cacerts.txt')
20 # request.set_ssl_info(ca_certs=ca_certs)

$ exit
$ exit
298 ：login:Penguin：2019/11/24(日) 10:18:06.46 ID:gVQp9hOZ.net: ※コンテナから抜ける

> sudo docker build --rm -t $USER/mozc_ubuntu14.04 .

> sudo docker run --interactive --tty --rm $USER/mozc_ubuntu14.04

※これで「Build Mozc for Android:」も「python build_mozc.py build -c Debug android/android.gyp:apk」も通る

mozc_builder@14a128067269:~/work/mozc/src$ python build_mozc.py gyp --target_platform=Android
INFO: Generating version definition file...
INFO: Version string is 2.23.2815.103
INFO: Running: /usr/bin/python /home/mozc_builder/work/mozc/src/build_tools/ensure_gyp_module_path.py --expected=/home/mozc_builder/work/mozc/src/third_party/gyp/pylib/gyp
INFO: Building GYP command line...
INFO: Android home is set from ANDROID_HOME: /home/mozc_builder/work/android-sdk-linux
INFO: Android NDK home is set from PATH: /home/mozc_builder/work/android-ndk-r16b
INFO: Running GYP...
(略)
INFO: Done

mozc_builder@14a128067269:~/work/mozc/src$ python build_mozc.py build -c Debug android/android.gyp:apk
INFO: Running: ninja -C out_android/Debug apk
ninja: Entering directory `out_android/Debug'
[7/13] ACTION protobuf_jar: run_javac_d762657663869817d24e7174f8f37e98
（略）

BUILD SUCCESSFUL
Total time: 16 seconds
mozc_builder@14a128067269:~/work/mozc/src$
299 ：login:Penguin：2019/11/24(日) 10:27:55.14 ID:ydYnxOIh.net: ｢有能と無能｣っていうタイトルの現代アートの展示会場はここですか？
300 ：login:Penguin：2019/11/24(日) 14:43:36.08 ID:9LX+LUV7.net: >>297
> L69はコメントアウト
> #RUN cd nacl_sdk && ./naclsdk install pepper_49

それだと、pepper_49 インストールされてねーだろ

あとそんな手順書くぐらいなら全部Dockerfileでやれ
まあ理由はわかるがな。ググって適当にやって
動いたのはいいがDockerfileにできなかったんだろう？
301 ：login:Penguin：2019/11/24(日) 14:53:01.94 ID:9LX+LUV7.net: これがDockerfile修正の差分な。
python build_mozc.pyまではしとらんが、pepper_49 インストールできたし動くやろ？
httplib2 もいらん、L18-19のコメントアウトもいらん
もう少し解析すれば、こんな意味不明な修正じゃなくてもっとマシなやり方がありそうだが。

$ diff -u Dockerfile.old Dockerfile
--- Dockerfile.old 2019-11-24 14:48:42.027977900 +0900
+++ Dockerfile 2019-11-24 14:46:08.989689200 +0900
@@ -66,6 +66,9 @@

## NaCl SDK
RUN curl -LO http://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/nacl_sdk.zip && unzip nacl_sdk.zip && rm nacl_sdk.zip
+RUN cp /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem nacl_sdk/sdk_tools/cacerts.txt
+RUN ./nacl_sdk/naclsdk version
+RUN cp /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem nacl_sdk/sdk_tools/cacerts.txt
RUN cd nacl_sdk && ./naclsdk install pepper_49
ENV NACL_SDK_ROOT /home/mozc_builder/work/nacl_sdk/pepper_49
302 ：login:Penguin：2019/11/24(日) 14:57:36.18 ID:9LX+LUV7.net: >>299
コンテナから抜けるとか書いてあるところを見て
なにかおかしいと気づけなければいけない。
目が節穴、まだまだやのうｗ

もし解説がほしければ、そのようにレスしてくれれば
解説するよ？推測で良ければだけどｗ
303 ：login:Penguin：2019/11/24(日) 14:59:56.45 ID:9LX+LUV7.net: それにしても、これDockerでやっていてよかった"例外的"な事例だな
実機やVMでやっていたら、再現性とれなくて、もっとハマっていたと思う。
304 ：login:Penguin：2019/11/24(日) 15:22:31.96 ID:gVQp9hOZ.net: >>301
何で俺の書き込み見て必死に追従してんの？
昨日やってやれよｗ
305 ：login:Penguin：2019/11/24(日) 15:29:57.40 ID:9LX+LUV7.net: >>304
スレ違いだからやらないと言った。
しかしクソコードが広まるのは世の中のためにならない
306 ：login:Penguin：2019/11/24(日) 15:35:10.34 ID:gVQp9hOZ.net: >>305
君はエネルギーの使い方が間違ってるね。
しかも結局スレ違いじゃ無いじゃんｗ
307 ：login:Penguin：2019/11/24(日) 15:40:59.55 ID:9LX+LUV7.net: >>306
意味不ｗ
お前が最初からまともなものを出してれば
俺が無駄なエネルギー使うことはなかったんだよ。

qiitaとか下手にSEOが高いからクソコードが広まりすぎて
うんざりするわ。世の中のためになることにエネルギーを使う
クソコードの排除は世の中のためだ。

> しかも結局スレ違いじゃ無いじゃんｗ
修正内容見ろよ。Dockerと関係ないだろ。物理 or 仮想マシンでも
同じ修正が必要だ。俺はお前のクソコードを修正しただけで
Dockerに関するレスをしたわけじゃない。スレ違いだが
さすがにクソコードは看過できん
308 ：login:Penguin：2019/11/24(日) 15:44:45.97 ID:gVQp9hOZ.net: >>307
分かったから涙拭けよｗ
お前がどう言い繕うとも、俺のコード見て動き
始めた事はなんら変わりは無いｗｗｗ

ハズカシーｗ
309 ：login:Penguin：2019/11/24(日) 15:47:10.94 ID:9LX+LUV7.net: >>308
そんなことよりお前のコードのバグ（pepper_49がインストールされてない）
というのを指摘するほうが重要。
お前のコードは一行たりとも利用してない。
お前のコードは役に立たない
310 ：login:Penguin：2019/11/24(日) 15:51:51.31 ID:ydYnxOIh.net: どっちもありがとうやで(*‘ω‘*)
311 ：login:Penguin：2019/11/24(日) 15:54:14.33 ID:9LX+LUV7.net: なあにいいってことよ。
シンプルかつ無駄のない正しいコードを書くのが好きだからなｗ
312 ：login:Penguin：2019/11/24(日) 15:55:22.53 ID:8A3uNLLu.net: >>309
いやいや、そういう問題じゃない

>何で俺の書き込み見て必死に追従してんの？

悪いけどこれが俺の感想の全てｗｗ
粘着してるし、お前は昨日も一昨日も暇だったんだよな？
俺はスゲー忙しかったけど。で暇なくせに結局
Dockerfileの修正を持って問題解決となったスレ違いでも
何でもない事象にスルー決め込んでたんだよな？

で、俺が書いたのみて「成程ここが問題なのか。
俺がエレガントに解いてやろう♪」とでもやって、ドヤ顔で
ここに投下したんだよな？

悪いけど失笑意外何も無いよｗ

>vi ./work/nacl_sdk/sdk_tools/download.py

>※L18-19をコメントアウト
>19 # ca_certs = os.path.join(SCRIPT_DIR, 'cacerts.txt')
>20 # request.set_ssl_info(ca_certs=ca_certs)

あ、ここで ./naclsdk install pepper_49　やなとかそれ位分れよｗ
それ関連のファイル修正したんだからｗ
313 ：login:Penguin：2019/11/24(日) 15:57:37.83 ID:9LX+LUV7.net: あほやなぁｗ

> SSL3_GET_SERVER_CERTIFICATE:certificate verify failed)
というエラーで、証明書の問題だなんてすぐわかるだろ。

その時点でDockerと関係ないことは明らかだったから、
関係ないからよそに行けって最初から言ってるんだがｗ

↓

196 自分：login:Penguin[sage] 投稿日：2019/11/15(金) 04:45:41.79 ID:E8h29lNR
どっかーとかんけいないので
どっかーにいってください
314 ：login:Penguin：2019/11/24(日) 15:58:05.86 ID:9LX+LUV7.net: > あ、ここで ./naclsdk install pepper_49　やなとかそれ位分れよｗ

やればわかるが、それ失敗する。
315 ：login:Penguin：2019/11/24(日) 15:59:46.60 ID:9LX+LUV7.net: なぜかと言うと、コメントアウトしたという事実が消えてなくなるから
316 ：login:Penguin：2019/11/24(日) 16:05:46.17 ID:8A3uNLLu.net: >>315
Dockerを消すなよｗ
317 ：login:Penguin：2019/11/24(日) 16:07:53.37 ID:9LX+LUV7.net: >>316
Dockerのせいではない。
お前、やっぱりわかってないんだな。
俺のDockerfileの修正内容見て、疑問に思わなかったのか？
318 ：login:Penguin：2019/11/24(日) 16:44:06.15 ID:8A3uNLLu.net: >>317
ドヤ顔で師匠面すんなよｗ
やっぱお前、俺の書込みにレスするなｗ
悪いけどお前が何を言おうと、俺の中で丸二日何もしなかった癖に
俺が書き込んだ瞬間に、必死に追従する恥ずかしい奴、と言う印象以外何も無い。
俺にとっては、>>298で
「BUILD SUCCESSFUL」これを見た瞬間にタスク（と言うか懸案）は終わり。
もう一切の興味は無い。お前が余りにもハズカシーからレスしてあげてるだけ。
じゃーなｗ
319 ：login:Penguin：2019/11/24(日) 17:37:42.01 ID:9LX+LUV7.net: 師匠面（笑）お前が、俺のことを師匠に見えてしまってるから
そんな発想が出てくるんだぞｗ

さて>>301の解説するか

まず実行して表示されるエラーの内容から証明書に問題があることはすぐにわかる。
Ubuntu 14.04だから証明書が古いんだろうなと最初は思ったが、実際は、nacl_sdkに入ってる cacerts.txt が古い（2015年）
Ubuntu自体はアップデートされてるので問題なかった。なのでファイルをコピーするだけで解決。

そう解決するはずだった。それが解決しなかった。

> RUN curl -LO http://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/nacl_sdk.zip && unzip nacl_sdk.zip && rm nacl_sdk.zip
> RUN cp /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem nacl_sdk/sdk_tools/cacerts.txt
> RUN ./nacl_sdk/naclsdk version
> RUN cp /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem nacl_sdk/sdk_tools/cacerts.txt
> RUN cd nacl_sdk && ./naclsdk install pepper_49

これ見て疑問に思うべきなのは、同じcpがニ回ある所とバージョン番号を出力してるだけの
naclsdk version がある所。これ、意味がないように見えるがちゃんと意味がある。

>>312が動かないと言ったのは、naclsdk を実行すると修正が巻き戻る（用に見える）から。
cacerts.txt が巻き戻るし、コメントアウトしたはずの download.py も巻き戻る。
>>297がDockerfileにしてないのは、この理由がわからず、試行錯誤して（何故か）動いたものを
書いただけだからだろう。だからやったはずのnaclsdk install pepper_49も書き忘れた。

巻き戻る理由は、>>302で書いたように推測だが、おそらくSDKのアップデート処理。
ネットから最新版？をとってきてると思われる。Google Cloud SDKがそうだが
コマンド実行時に最新版を使わせるためにアップデート機能が内蔵されてる。
という経験があるから気づいた。こういうのに気づけるのは経験の差だな。

本当にアップデートであるかは見てはないが、naclsdk（bashスクリプト）が呼び出してるのが
sdk_update.py というファイルだから多分あってるだろう。
320 ：login:Penguin：2019/11/24(日) 17:40:41.57 ID:9LX+LUV7.net: つまり、

1. naclsdk version で行われている（であろう）アップデートによる
証明書エラーを回避するために、新しい証明書をcpする。

2. naclsdk version でアップデートを行う。

3. 証明書が巻き戻ったので、再度新しい証明書をcpする。

4. naclsdk install pepper_49

という流れになってる。

>>301で言った意味不明な修正というのはこのこと。
ちゃんと調べれば、アップデート処理をスキップする方法があるかもしれない。
という意味で、マシなやり方がありそうだがと書いた。

もしDockerfileにしていなければ、気づかない間に更新されてるというこの挙動に
気づくことはなかっただろう。>>303で書いたDockerやっていてよかったというのはこのこと
だが、こういう理由は"例外的"な事例

な？わかるだろ？この質の違い。やるならここまでやれっていうんだよ。詰めが甘すぎる。
やってみた、（よくわかってないけど）うごいた、共有します。
qiitaにはこんな程度の質の悪い情報ばかりある。うんざりするわ。
321 ：login:Penguin：2019/11/24(日) 17:51:01.28 ID:9LX+LUV7.net: 分かりづらかったかもしれないので補足

naclsdkのアップデート処理はnaclsdk versionだけでなく
（おそらく）全てのコマンドで実行される。
もちろん naclsdk install pepper_49 でも。

証明書を一回コピーするだけだと

1. naclsdk install pepper_49 実行時に
2. アップデートが走りファイルが巻き戻り
3. その後にpepper_49のインストールが行われる

ので証明書が古いというエラーになる。
naclsdk install pepper_49 実行時にアップデート処理が走らないように
先にnaclsdk versionでアップデート処理だけを行わせている。
322 ：login:Penguin：2019/11/24(日) 23:45:40.95 ID:OMG53Vpn.net: 説明書を読まずに、でたらめにやって、たまたま出来たとか言ってるからだろ

自分で読むのが嫌だから、
他人に説明書を読まして、解説させようと思ってるのが明らかw

そんなのに付き合う必要もないし、丁寧に解説する必要もない。
「説明書を読め」で終わりw

各アプリの説明書は、Docker の事じゃないから！
323 ：214：2019/11/27(水) 15:33:47.89 ID:pWzU57rW.net: お二人様､どうもありがとうございます｡
お二人様のレスバトルのおかげで､無事Mozcのapk作れました｡
NaCl SDKの部分を>>301に書き換えただけで行けました｡

しかし､これ分からないでしょ
普通に考えて､証明書が切れてるとか素人じゃ気づかん
どうやって証明書切れてるって分かったんですか？
SSLのバージョンアップかなんかで昔の証明書全部無効になったとか？

しかも､証明書がGlobalSign_Root_CA_-_R2.pem使ってたのかもよく分かりましたね
これもどうやってわかったのですか？

まあ､次はmozcのキーボードの部分に数字キーでも追加するのやってみます！
324 ：login:Penguin：2019/11/27(水) 19:47:40.22 ID:e2a81Xjm.net: >>323
SSL関係のエラー ≒ 証明書の有効期限切れｗ
証明書には有効期限がある。どんな証明書も時間が経てば切れる。

ちゃんと読めばわかるが読まなくてもわかる。だいたいそれ。いつもそれ。どうせそれ。古そうだと思ったら特にそう。
2位はSSLライブラリが入ってない、3位はライブラリが古い・バグが有る

> 証明書がGlobalSign_Root_CA_-_R2.pem使ってたのかもよく分かりましたね
ちゃんとコードを追っていっても突き止められただろうが、単に「naclsdk install pepper_49」で検索して見つけただけ。
真っ先に https://github.com/google/mozc/issues/437 にたどり着くし、
そこからリンクされてる https://groups.google.com/forum/#!topic/native-client-discuss/ViBofmhWpyM の最後に書いてある。
その人は証明書を再生成したり自分のgithubにアップしてるようだが。
>>297のコメントアウトする方法もこのリンク先に書いてある。

ここまでで頭は使ってない。いつものやつね。でググっておしまい。
325 ：login:Penguin：2019/11/27(水) 19:48:13.04 ID:e2a81Xjm.net: 証明書の有効期限切れの対策は、証明書を新しくするか証明書を無視すること。

コメントアウトしてるのはソースコードの変更内容から、証明書を無視する方法だろうなとわかるが
>>297では証明書を無視してるのにhttplib2をアップデートしてるのはおかしいと気づく
SSL周りはセキュリティ関連で時代ともに更新されるからなにかの変更に対応してないことも
考えられるが証明書を無視してるのだからその影響は小さい。
バグが有る可能性もゼロではないが有名ライブラリで可能性は低い。

dockerを抜けるとか意味不明なことをやってるし明らかなミスがあるから
こんなの広まったら困るしスレ違いだが重い腰を上げた

ソースコード書き換えはやりたくないし、証明書を新しくできるならその方がいい。よってコメントアウトする方法はなし。
httplib2のアップデートは必要性に懐疑的だったので消してみたらやっぱり動いた。それだけ。
証明書は個人のgithubリポジトリを参照するのは嫌だったのでopenlsslコマンドで再生成しようと思ったが、
opensslをdockerに入れるのも嫌だったので /etc以下にあるやつ使えるんじゃね？と思って試しに使ってみたら動いた。
その後でUbuntu 14.04であっても更新されてるかと気づいた

ただcacerts.txtを新しくしても元に戻ったり意味不明な挙動をしたからその原因追求に時間がかかった。
その理由がわかったから>>297はあんな中途半端なものを出したんだなと理解した。

だが俺は書いてあるものを鵜呑みにはしない。見て理解して変な所や無駄な所は直す。
やってみて動いたからそれでお終い、はい情報共有～なんてことはしない。

> まあ､次はmozcのキーボードの部分に数字キーでも追加するのやってみます！
スレ違いだからよそでやれ
326 ：login:Penguin：2019/11/28(木) 20:53:19.78 ID:P2UjCEfy.net: ID:9LX+LUV7

この手のアホばっかりだな
327 ：login:Penguin：2019/11/28(木) 20:55:04.88 ID:P2UjCEfy.net: アホは背伸びしてDockerでやらなくて良いぞ
328 ：login:Penguin：2019/11/28(木) 21:00:03.03 ID:hVuKTC+d.net: などとぶつくさ文句をいうだけなのであった
329 ：login:Penguin：2019/11/28(木) 21:48:36.17 ID:HhHInLOm.net: アホというか、単なる暇人だよな。
エラーメッセージ出てりゃ誰だってググればゴールにたどり着く。
330 ：login:Penguin：2019/11/29(金) 00:00:13.97 ID:ebGLF78J.net: 宮下剛輔が、テスト駆動開発(TDD)で使う、Ruby のRSpec を真似て作ったツール、
Ruby製のServerspec を使って、

CI/CD ツールのCircleCI, TraviceCI などを使って、Docker のテストをやりまくれば良いのでは？
331 ：login:Penguin：2019/11/29(金) 03:33:51.20 ID:58TiTLbK.net: >>297-298
みたいにゴールじゃなく明後日の方向にたどり着いてるやつもいるけどなｗ
332 ：login:Penguin：2019/11/29(金) 03:36:00.72 ID:58TiTLbK.net: >>330
Dockerのテストは意味不明。

Dockerはアプリに環境を付加しただけだから
アプリのテストをやれば良いんだよ。
333 ：login:Penguin：2019/11/29(金) 12:06:21.15 ID:/RGupnOb.net: >>330
serverspecはなんか違うんだよなって思うところがあって、
名前で訂正するならば、servicespecにするべきだと思っている。

例えば、トップページのこれなんだけど、
describe package('apache2'), :if => os[:family] == 'ubuntu' do
it { should be_installed }
end

httpdパッケージがインストールされてることをテストする必要はないと思ってる。
なぜならhttpdパッケージをインストールするっていうのはansibleなどに
書いてあるわけで単なる二重定義でしかない。
本当にやるべきは、httpdサービスが動いていること。

それに関して、以下のようにやっているから良いだろと思うかもしれない。
describe service('apache2'), :if => os[:family] == 'ubuntu' do
it { should be_enabled }
it { should be_running }
end

でもこれは何を調べているのだろうか？ apache2プロセスがいることだろうか？
もちろん違う。systemdなどの情報をチェックしている。だがsystemdで問題ないからと言ってサービスが必ず動いているとは限らない。
動いているけど正しく設定されていない場合がある。また、標準パッケージをやめてdockerを使うようにするかもしれない。
Linux版homebrewを使うかもしれない。サービスとしてみれば正しく動いてるのにテストで失敗することになる。

これはサービスのテストをしていないのが原因
本当にやるべきテストは特定のポートに接続して想定したレスポンスが返ってくるとか、
特定のコマンドが正しく実行できるかだろう。

serverspecがpackageやserviceで抽象化している理由はわかるが、それにより何のテストをしているのか不明確になり、
そしてテストではなく単なる構成管理ツールとの二重定義になってしまっている。
Dockerに関しても、Dockerのテストをやるのではなく、Dockerで作った"もの"のテストをやるべきである。
334 ：login:Penguin：2019/11/29(金) 13:10:43.21 ID:CKNktXx+.net: 5chに長文書き込める情熱は正直ちょっと羨ましい
335 ：330：2019/11/29(金) 23:02:53.54 ID:ebGLF78J.net: 素人は、Dockerfile さえ、まともに書けていないから、

1行でも追加したら、
まず、httpd がインストールされたことを、Serverspec で確認すればよいのでは？

次に、httpdが起動したら、
また起動したかどうかを、Serverspec で確認する
336 ：330：2019/11/29(金) 23:07:16.97 ID:ebGLF78J.net: 統合テストは、curl, wget, Selenium WebDriver などで、web サーバーへアクセスして、

実際のDOM を取得するとか、画像を撮影するなど、すれば？
337 ：login:Penguin：2019/11/30(土) 00:12:12.37 ID:PJxRldUs.net: >>334
もっとアツクナレヨ
338 ：login:Penguin：2019/11/30(土) 00:29:40.30 ID:yJBQSrj9.net: >>335
それやったことある？

ある大きな欠点のせいで、それ簡単にはいかないよ。
339 ：login:Penguin：2019/11/30(土) 00:36:45.23 ID:yJBQSrj9.net: やってみてねってことね。
340 ：login:Penguin：2019/11/30(土) 11:37:29.70 ID:Se1bf1fg.net: vagrantfileもそうだけどdockerfileとかはそもそも何に対するソリューションなの？
1000大規模の鯖を迅速にスケールしたいという問題に対しては確かに有効だとは思うけど
それ以外の人には殆ど関係ない。
何か存在しない問題に対するソリューションを提供されて、そのソリューションに対する
テスティングフレームワークも提供されて、仕事としてのWEBサービスのというミッションからは
どんどん離れていく気がするね。
興味在る奴は良くこんな事やるよ。
341 ：login:Penguin：2019/11/30(土) 11:48:05.90 ID:wFtP+/8O.net: >>340
またかよｗ何度も言ってるだろ。
一言で言えば可搬性

開発したアプリをあちこちに簡単にデプロイできるようにするもの。
デプロイ先は実機Linuxだけじゃない。
手元のWindowsやMac、仮想マシンでも物理マシンでもOK
大規模なクラスタの上いデプロイすることもできる。

さらに同じPC上に複数デプロイすることもできる。
（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）

お前のマシンで俺が作ったアプリ（最新版rubyとソースからビルドする○○が必要です！）を
動かすとき、手順書無しで作れると思うか？ Dockerなら最小一行で動かすことができる。
342 ：login:Penguin：2019/11/30(土) 11:55:34.83 ID:Se1bf1fg.net: >>341
まるでそれはVMに可搬性がないかのように言っているけど実際は在る。

>さらに同じPC上に複数デプロイすることもできる。
>（同じポートを使うって？ Dockerの機能でそれを変更できるんだよ！）

これも全く同じ。なんでVMにそれが出来ないと思うの？
まるでVMに問題があってその問題をdockerが解決するの様に宣伝されるから
なんのこっちゃ？となる。

>Dockerなら最小一行で動かすことができる。

OVAを解答してダブルクリックする。
終わり。
343 ：login:Penguin：2019/11/30(土) 12:21:45.65 ID:wFtP+/8O.net: >>342
> まるでそれはVMに可搬性がないかのように言っているけど実際は在る。

え？まさかVMでイメージ作って、
そのイメージをMacやLinuxやクラウドの仮想マシンで動かすって話してるの？

どうやって？

例えば、AWSやGCPは仮想マシンとしてKVMを使ってるけど
その仮想マシンで動くVMイメージの形式って何？
そのVMイメージをMacやLinuxで使えるの？
344 ：login:Penguin：2019/11/30(土) 12:22:41.86 ID:wFtP+/8O.net: >>342
> OVAを解答してダブルクリックする。

どうやってAWSやKVMでOVAファイルを使うの？
いや、無理だからさｗあんた無理しないほうが良いよｗ
345 ：login:Penguin：2019/11/30(土) 12:23:48.24 ID:vSs97oU5.net: Infrastructure as code (IaC)

GUI・コマンド入力などで環境構築すると、再現性がない。
手順書に、手順を書いておかなければいけない

コマンドの打ち間違いも生じるから、
環境構築ツールのコードで書いておくべき！
346 ：login:Penguin：2019/11/30(土) 12:25:10.33 ID:wFtP+/8O.net: OVAファイルをmacOSで使うにはどうしたら良いんだろうねｗ
347 ：login:Penguin：2019/11/30(土) 12:31:13.21 ID:Se1bf1fg.net: >>343
意味わかんね。
そんな事やる必要ないだろ？クラウド上で動くのは本番機であり検証機であり
公式なもの。しかも1回やったら終わり。
何故そこが問題だと思うのか解からない。
前に言ったように1000大規模なら確かに問題であろうとは思う。
とりあえずウチは２，３０台で運用しているけどそれが問題になった事は無い。
348 ：login:Penguin：2019/11/30(土) 12:32:56.84 ID:wFtP+/8O.net: >>347
「やる意味がわからない」っていうはお前の問題だろ。
お前が理解できないだけ。それはお前自信で解決しろ。

で、結局できないんでしょ？
その作ったOVAファイルを、AWSやGCPで動かす。
そしてそのOVAをWindowsやmacOSで動かすってことが
349 ：login:Penguin：2019/11/30(土) 12:36:25.34 ID:Se1bf1fg.net: >>345
その弊害としてmozcのような例が在る。
IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
これはdockerの実践ガイドなんかにも書かれていたけど、dockerfileの
パブリックリポジトリ使うときはそのリポジトリのみならず、ubunntuならubuntu
なんかの「外部の」リポジトリに依存するから、ある日突然build出来なるなる事は
ある、だから一度build出来たらイメージをバックアップすべし、的なことを書いて
唖然としたわ。
mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
と思ったんだろうね。
350 ：login:Penguin：2019/11/30(土) 12:37:23.01 ID:Se1bf1fg.net: >>346
Macでは動かさない。ESXiだろ？
君が言っているのはDockerfileをvagrantで動かすにはどうしたら良いんだろうね？
と言っているに等しい。
351 ：login:Penguin：2019/11/30(土) 12:39:21.74 ID:Se1bf1fg.net: >>348
それがdockerのメリットなの？本当にその程度？
それなら、相当多くの人にとって別にdockerというのは有難がる
モノでも何でもない、という気しかしない。
352 ：login:Penguin：2019/11/30(土) 12:49:11.25 ID:wFtP+/8O.net: >>350
ほらもうできなくなったｗ
可搬性無いじゃん。ESXi使わないと動かないだろ。
そのESXiはWindowsのWSLなどと同居できない。
ライセンスの問題でクラウドのVMで使用できない。

>>351
> それがdockerのメリットなの？本当にその程度？
いや、もっとメリットは有る。
だからまず手始めに、そのOVAをイメージを一切変更することなく
WindowsやmacOSで動かす方法書いてみ
353 ：login:Penguin：2019/11/30(土) 12:51:46.33 ID:wFtP+/8O.net: >>349
> IaCを書いた人が継続的にメンテないないとbuildすら間々ならなくなる。
SSL証明書が古くなって接続先サーバーにに接続できないんだけど
仮想マシンでどうやって解決するの？ｗ

まさかビルド済みのDockerイメージを使えば解決する話を出さないよね？ｗ
354 ：login:Penguin：2019/11/30(土) 12:53:07.86 ID:wFtP+/8O.net: > mozcの人もメンテしてないようだけど、面倒くさいというか、そこまでやる価値ない
> と思ったんだろうね。

ブーメラン、ブーメラン

つまりVM作る価値がないからOVAファイルがないと？ｗ
355 ：login:Penguin：2019/11/30(土) 13:00:58.42 ID:Se1bf1fg.net: >>352
>ほらもうできなくなった

おれ自身が普段使わない、という意味なんですが・・
MacにVMWwareWorkstation入れれば普通に動くだろ。
356 ：login:Penguin：2019/11/30(土) 13:05:01.47 ID:wFtP+/8O.net: >>355
普段使わないなら話にならんな。
俺が質問しても的はずれな答えしか来ないだろう。

お前が普段使っているのを言え
お前が俺の質問に正しく答えられると自身があるものを言え。
普段どのOSでOVAファイルを使ってるんだ？
357 ：login:Penguin：2019/11/30(土) 13:06:00.15 ID:Se1bf1fg.net: >>356
OVAとかは、これで終わりな。
可搬性がない、という事は当てはまらない。
以上。
358 ：login:Penguin：2019/11/30(土) 13:09:21.10 ID:wFtP+/8O.net: >>357
逃げるの？まだ質問の一歩目なんだけど？
その後いろいろとOVAではできないことがあるんだけど
359 ：login:Penguin：2019/11/30(土) 13:12:49.45 ID:Se1bf1fg.net: >>358
何つーか君のために、そんな作業するのがだるすぎる。
可搬性の話だよな？じゃあ、もっと手前で、

①windowsにvmware workstation入れる。
②何でも良いから適当にOSつくる
③そのファイルをマックにコピる。
④macにvmware workstation入れる。
④マックで③を開く。

自分でやってみれば？
360 ：login:Penguin：2019/11/30(土) 13:13:05.89 ID:wFtP+/8O.net: OVAファイルではできないこと。
ブラウザから http://localhost:8080 で接続できない。

できるというのなら、その手順を一行で書いてみてね。

docker run -d -p 8080:8080 image
↑可搬性があるからこんなに簡単にできる。
どのOSでも同じやり方、ポート番号を変えたければ引数を変えるだけ

こんなのは序の口
361 ：login:Penguin：2019/11/30(土) 13:14:11.73 ID:wFtP+/8O.net: >>359

①windowsにvmware workstation入れる。
②何でも良いから適当にOSつくる ← ここが手動。これ笑う所なｗｗｗｗ
③そのファイルをマックにコピる。
④macにvmware workstation入れる。
④マックで③を開く。
362 ：login:Penguin：2019/11/30(土) 14:12:21.38 ID:wMw6KZO2.net: >>340
> それ以外の人には殆ど関係ない。
あなたにとっては、少なくとも関係ないだけですね。
まぁ、頑張ってねっ！
363 ：login:Penguin：2019/11/30(土) 14:21:12.49 ID:vSs97oU5.net: >>360
>OVAファイルではできないこと。
>ブラウザから http://localhost:8080 で接続できない。

Serverspec でテストすれば？

command(コード)で、汎用コマンドも実行できる。
ping, wget, curl とか

Selenium WebDriver を使った、Ruby スクリプトも実行できるかな？
364 ：login:Penguin：2019/11/30(土) 14:30:23.04 ID:Se1bf1fg.net: >>361
OSの仮想化技術なんだから当然だろ？
君は何の技術か意味を理解しているの？
何かこういう書き込み見てると、コイツ何処まで理解して話してるんだろうな？と言う気がするね。
2つの全然違う技術をゴチャにしている

>>360
/etc/hosts

IPアドレス起動したOS
http://起動したOS

> docker run -d -p 8080:8080 image

そもそもこんな事を書く必要は無い。遣りたければプロキシかませば？
言ってしまえばDockerが内部にリバースプロキシを持っているだけだけど、
これも、そうだね。存在しない問題に対するソリューション。
君はこれによって、何の問題を解決するんだい？

余程の事が無い限り誰もこんな事を遣りたいとは思わない。
余程の事が在る人は自前でリバースプロキシ構築する。
例えばMozcのDocker作った人がこれを有難がる事は絶対にない。

一方で標準としてネットワークをこの構成にしてしまった為に>>173と言う疑問はすぐに出る。
俺も全く同じ感想。

総じて君の言うdockerの利点はそもそも存在しない問題というか、恐ろしくニッチな何かに対する
利点を鬼の首でも取ったかの様に喧伝するから、こちらに全く伝わらない。

「Dcokerはこんなことが出来るから凄い」では無く、Dockerはこんな問題を解決しようとして、
XXと言う方式にしている、と言う言い方をしなければ、ごく一般的なITのエンジニアや顧客を
納得させることは出来ない。
365 ：login:Penguin：2019/11/30(土) 15:23:51.62 ID:3P4mm8Mh.net: >>364
＞2つの全然違う技術をゴチャにしている
全くの別物であるdockerと汎用の仮想マシンを比較する意味なんてないからお前の疑問もまるごと解決だな
さようなら
366 ：login:Penguin：2019/11/30(土) 15:52:23.55 ID:wMw6KZO2.net: >>364
> ごく一般的なITのエンジニアや顧客を納得させることは出来ない。
別に納得させなくて良いよ。
367 ：login:Penguin：2019/11/30(土) 15:56:34.15 ID:Se1bf1fg.net: >>365
いやいや逃げなよ？まだ質問の一歩目なんだろｗ？
368 ：login:Penguin：2019/11/30(土) 18:35:57.80 ID:hmmzT75Z.net: まだやってんのかよ。
369 ：login:Penguin：2019/11/30(土) 19:03:43.37 ID:yxXUcR2F.net: >>363

> Serverspec でテストすれば？

？なに使ってもlocalhostで接続できないじゃん

>>364
> OSの仮想化技術なんだから当然だろ？

だからDockerとは違うって言ってるんだろ？
お前意味不明だな。Dockerと同じことができないって言ってるのに

「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」

だーかーらー、Dockerと同じことできないじゃんｗ

> そもそもこんな事を書く必要は無い。遣りたければプロキシかませば？
今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？
ほらまた一つ。VMではできないことが増えたｗ
370 ：login:Penguin：2019/11/30(土) 19:04:44.85 ID:yxXUcR2F.net: 仮想マシンを使った問題は、mozcの例でわかる。
仮想マシンじゃ、古いバイナリしか持っておけないんだよ。
最新のソースコードを持ってきてビルドしたいときに
古いOVAファイルは全く役たたない

これもVMでは無理なことの一つ
371 ：login:Penguin：2019/11/30(土) 19:05:20.48 ID:yxXUcR2F.net: なぜmozcを作ってる人は、仮想マシンを使わなかったのか？
理由はわかるよね？
372 ：login:Penguin：2019/11/30(土) 19:06:16.12 ID:yxXUcR2F.net: > 「Dcokerはこんなことが出来るから凄い」では無く、Dockerはこんな問題を解決しようとして、

だから、可搬性。
作ったイメージをあちこちに持っていける。

OVAファイルを作れば同じことができる？
どうやってawsやgcpで動かすのさ？
KVM使ってるんだぞ。
373 ：login:Penguin：2019/11/30(土) 19:10:18.63 ID:yxXUcR2F.net: さて、VMではできないこと＝Dockerが解決してることを一つ追加。

Dockerは最新のソースコードから簡単に素早くビルドしてイメージを作ることができる。

仮想マシンはタダの仮想マシンでしかない。
仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない
新しいソースコードからイメージを生成できない。
374 ：login:Penguin：2019/11/30(土) 21:36:34.56 ID:Se1bf1fg.net: >>369
>お前意味不明だな。Dockerと同じことができないって言ってるのに
>「Dockerと同じことができる。でも仮想化技術なんだから、それはできない！」

お前が意味不明だろｗ
いつの間に何が出来て何が出来ない、と言う話になったのｗ？

>今できるかどうかの話をしてる。できないんだね？プロキシを自分で建てなきゃできないんだね？

Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
教育コストが掛かると>>173は言っている。

XXができてYYが出来ないと言う話をするのなら、Dockerは物理マシンA上に立てたAAと言うマシンが
物理B上に立ってたBBと言うマシンと通信したいと言うだけで、スゲー面倒くさいことをしなければならない。

>仮想マシンを使っても、ビルド済みの古いバイナリしかとっておけない

逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
実務では、当たり前だが、そういう事は多く存在する。君の指摘は大体実務を無視してるけどね。
出来ないことの列挙もそう。普通に訊いて「だから何？」と思うものばかり。
375 ：login:Penguin：2019/11/30(土) 21:38:30.14 ID:Se1bf1fg.net: >>372
>OVAファイルを作れば同じことができる？
>どうやってawsやgcpで動かすのさ？

だから本番機と開発機は別だっていってるでしょ。
相変わらず、実務を無視した指摘ばっかりしている。
そこで可搬性が無いのは寧ろメリットだろ。
仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
動かしたら情報漏洩が簡単すぎて大問題だわ。
376 ：login:Penguin：2019/11/30(土) 21:55:36.92 ID:3P4mm8Mh.net: とてもあたまがわるそう
377 ：login:Penguin：2019/11/30(土) 22:01:48.14 ID:kFO69wK3.net: 亞北ネル
378 ：login:Penguin：2019/11/30(土) 22:01:57.41 ID:Se1bf1fg.net: まあネットワーク周りとか、どう見てもデメリットでしかないことを
XXが出来る！スゲーだろｗとか言い出すからね・・・。
自分で問題を作って、その解決策を自分で提供して俺スゲーVMにゃ出来ねーだろとかｗ
訊いてるこっちはポカーンだよ。
379 ：login:Penguin：2019/11/30(土) 23:15:10.01 ID:ncKkDOM9.net: >>373
実務じゃ多少古くても動作確認済みのバイナリをとっておいて使うので、
動くか分からない最新ソースコードをネットから拾ってビルドなんて、実験段階のPoC作成ぐらいでしかやらない。

Dockerが好きなのは分かったけど、比較が素人丸出しだから、これ以上の恥の上塗りはやめた方がいいよ。
380 ：login:Penguin：2019/12/01(日) 01:38:44 ID:J+24ZJpj.net: やらないんじゃなくてできない
開発中に毎日数回ソースコードコミットしたら
新しくしなきゃいかんのに馬鹿じゃないのかこいつｗ

ここまで出たVMではできないこと・不便なこと

・VMイメージ（OVAファイル）を手動で作成する必要がある
・新しいソースコードからVMイメージをを作成できない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる

まだまだ増えます。
381 ：login:Penguin：2019/12/01(日) 01:42:31 ID:J+24ZJpj.net: >>378
ネットワークは仮想マシン弱いよ？

例えばデータベースの仮想マシンを作る
アプリの仮想マシンを作る。
この二台の仮想マシンをどうやって接続する？

dockerは簡単に繋げられるし、変更もできるから
イメージに一切手を加えることなく、
開発時はローカルのMacに２つを動かして
本番環境では、別々の仮想マシン上に配置することができる
柔軟性が高い。
382 ：login:Penguin：2019/12/01(日) 01:54:39 ID:J+24ZJpj.net: >>374
> 逆にdockerは古いビルドイメージ取っとくだけでスゲー苦労するじゃん
何も大変なことはない。（プライベート）リポジトリにpushするだけ
OVAファイルは？いちいちファイル転送してダブルクリックするの？
dockerならrunするだけで新しいイメージも古いイメージも自由に使えるのに

> 仮に、本番機を誰でもエクスポートしてローカルのVMなんかで
VMはエクスポートするしか無いんだよなｗ
ソースコードからビルドするということができない
dockerでエクスポートなんかシない

リストに追加

ここまで出たVMではできないこと・不便なこと

・VMイメージ（OVAファイル）を手動で作成する必要がある
・ソースコードを新しくするたびにVMイメージを作成しなければいけない
・イメージが大きすぎて古いイメージをとっておくのが大変
・docker runのように簡単に新旧のイメージを使う方法がない
・ESXiが必要。KVM、HyperV、macOS上で動かない
・OVAファイルから手動で仮想マシンを作成しなければいけない
・仮想マシンに接続するときlocalhostで繋げない。プロキシを自分で設定する必要がる
・本番環境と開発環境で同じものを使えない
・環境を複製するときは既存のものをエクスポートしなければいけない。ゼロからの作り方がわからないから
383 ：login:Penguin：2019/12/01(日) 07:42:09.12 ID:OfIPuRU/.net: >>382
だから、何？
結論は？
384 ：login:Penguin：2019/12/01(日) 08:25:46 ID:qT+FNDQS.net: >>383
レス待ち。

最終的な答えは前から言ってる通り、VMはdockerの代わりにならないし
その逆にdockerもVMの代わりにならない。全く別のもの。
385 ：login:Penguin：2019/12/01(日) 08:28:45.31 ID:qT+FNDQS.net: あとdockerないと不便すぎる。VMイメージーのコピーなんてやってられない。
386 ：login:Penguin：2019/12/01(日) 08:51:32 ID:rd9VBfP6.net: ggrks
387 ：login:Penguin：2019/12/01(日) 09:03:56 ID:OfIPuRU/.net: >>384
つまり比較すること自体が無意味で
>>382
の書き込みはバカ丸出しということですね。
わかります。
388 ：login:Penguin：2019/12/01(日) 09:07:11 ID:qT+FNDQS.net: >>387
> つまり比較すること自体が無意味で
最初からそう言ってる。VMはDockerとはぜんぜん違う。

VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ
>>382の書き込みはバカ丸出しに言ってる
389 ：login:Penguin：2019/12/01(日) 09:12:03.19 ID:qT+FNDQS.net: > Dockerはこれを標準で持ってしまっている為に余計な管理コストを強いている、
> 無ければ必要な人だけが学習して立てれば良いものを標準として強制するから、余計な
> 教育コストが掛かると>>173は言っている。

VMを使うと教育コストが掛からないとバカが言っている。
このことを覚えておこう。バカ丸出しにこれがブーメランとして帰ってくることになるだろう
390 ：login:Penguin：2019/12/01(日) 09:15:57.89 ID:OfIPuRU/.net: >>388
「狂人の真似とて大路を走らば、即ち狂人なり」
391 ：login:Penguin：2019/12/01(日) 09:23:14.07 ID:qT+FNDQS.net: >>390
もしかしてお前が、バカ丸出しのバカか？
さっさとレスしろ。VMはDockerの代わりにならんだろうが
392 ：login:Penguin：2019/12/01(日) 09:33:00.07 ID:OfIPuRU/.net: >>391
他人だよ

いつまで執着してるんだよ。
393 ：login:Penguin：2019/12/01(日) 09:37:13.18 ID:qT+FNDQS.net: この話題が出るたびだよｗ
394 ：login:Penguin：2019/12/01(日) 09:53:26.67 ID:fdPwLs/X.net: >>388
お前、>>167だろ？日本語読めずに勝手に脳内で変な補完して話すからすぐ分かるよ。

> VMを持ち出してきて、dockerはいらないって言ったバカ丸出しはあいつ

誰もこんな事は言ってない。
395 ：login:Penguin：2019/12/01(日) 09:55:23.27 ID:qT+FNDQS.net: 結論　VMがあろうがなかろうがdockerは必要
396 ：login:Penguin：2019/12/01(日) 09:55:33.94 ID:Cg6x2/4w.net: Linuxディストリビューション自体の配布には使えないから
VMが無くなる事はない
でもアプリの配布は特にできない理由がない限りdockerイメージだな

Dockerイメージでやりにくいのはカーネル設定の指定
コンテナに特権を与えれば変更は出来るが、同一のマシンで動いているすべてのアプリケーションに影響を与えるので注意が必要

Elasticsearchのhelmチャートが
vm.max_map_countを変更するのに特権付きのコンテナを使うが
それが嫌な場合は自分でOSに設定すればよい
397 ：login:Penguin：2019/12/01(日) 10:08:04.48 ID:eVvGELNq.net: まだやってんのかよ(2回目)。
398 ：login:Penguin：2019/12/01(日) 10:10:04.85 ID:Cg6x2/4w.net: hyperkubeやk3sを使えばdockerでKubernetesを動かすことさえ可能
他のコンテナを立ち上げたりするので特権が必要だが
399 ：login:Penguin：2019/12/01(日) 10:20:10.80 ID:fdPwLs/X.net: >>395
多分君は、自分の出したdockerの利点に対する意見を否定されれた瞬間に
Docker自体を否定されたと感じているんだろうね。
否定しているのは君の意見、というだけだから。
400 ：login:Penguin：2019/12/01(日) 10:47:05.98 ID:s2QdG24G.net: >>375
それは管理ポリシーの問題じゃね？Linuxデスクトップは不便で利用者少ないからウィルスに強いと言っているのと同じだぞ

vmに対するdockerの利点で重要なのは開発者視点ではリソースを食わない＝金がかからないことだろう
これはマンパワーの不足している現在経営的にも重要で
新興国の開発者を取り込むのにvmでは進まないのだ

新興国だけではないぞ
日本の新人開発者の多くはノートを好み貧弱な環境で開発している
vm動かすリソースは無い

dockerはマンパワーを得るためにも有効なのです
401 ：login:Penguin：2019/12/01(日) 10:49:09.56 ID:qT+FNDQS.net: >>399
俺が言ってる意見は、Dockerのメリットなのだから
俺の意見を否定することは、Dockerのメリットを否定することになるはずだが？

それとも、俺が言ってることとは別に、Dockerのメリットが他にあるって言いたいの？
俺の意見を否定して、Dockerを否定しないっていうのは、そういうことになるはずだけど
402 ：login:Penguin：2019/12/01(日) 10:52:05.62 ID:qT+FNDQS.net: ちなみに俺はDockerのメリットをまだ全て書いてない
403 ：login:Penguin：2019/12/01(日) 10:56:37.76 ID:qT+FNDQS.net: あと（あのバカが）「VMでも（頑張れば）できる」って言ってるだけで
俺が言ってるDockerのメリットを否定されたところはないはずだけど？
404 ：login:Penguin：2019/12/01(日) 12:32:43.88 ID:PHV1P7RT.net: 折角の休み、他にやることないのかね？
405 ：login:Penguin：2019/12/01(日) 13:06:52.24 ID:fdPwLs/X.net: >>401
>俺の意見を否定することは、Dockerのメリットを否定することになるはずだが？
>
>それとも、俺が言ってることとは別に、Dockerのメリットが他にあるって言いたいの？
>俺の意見を否定して、Dockerを否定しないっていうのは、そういうことになるはずだけど

君はボッチでニートだから、そういう事になるんだろうけど、普通のITエンジニアは
会社単位で動くからね。Dockerへの移行は会社が決めたこと。確かに、今の利用者の
伸び率を見ているとシステム全体でやがて100台超えるサーバーにはなりそうだし、
社長の意向は世界展開したいとか言っているので、やがて1000台になる可能性はある。
DevOps/CircleCIのイチ技術としてDockerが入り込むのは、当然だなと。
だから別に最初からDockerを否定する気は全くない。そんな話はしていない。
ただ癖が強すぎるし、VMと比べて何故ここまで違いが大きいのかといった、当然の疑問に
誰も答えないから、話が長引いていると言うだけ。
ずっとそういう比較をしていたはずだが？
406 ：915：2019/12/01(日) 13:10:57.68 ID:pfsfGZDp.net: packer使えばVirtualboxでもESXiでもAWSでもGCPでもDockerでもなんでもよくなるよ
407 ：login:Penguin：2019/12/01(日) 14:08:56.09 ID:UP4b2tw0.net: 俺が納得できない=答えない
この思考パターンの人間は相手にするだけ無駄
特にネットでは
408 ：login:Penguin：2019/12/01(日) 14:55:31.87 ID:jBK+RpjH.net: ええやん、別に VM でやりたければ、やればよいだけ。

Docker を使っても分からんやつは、分からんだけ。
Docker を使って分かるやつは、分かる。

VM を使っても分からんやつは、分からんだけ。
VM を使って分つやつは、分かる。

まぁ、VM を頑張ってね！
409 ：login:Penguin：2019/12/01(日) 18:30:04.40 ID:qT+FNDQS.net: >>405
お前は悪口しか言わないな（笑）品性の低さが溢れ出てる。

Mozcの例から理解しなかったのかな？ Mozcのビルドのどこにクラウドが関係してる？
100台のサーバーとかDevOpsとかCircleCIとか言ってるが、
Mozcのビルドとは関係ないぞ。Dockerfileのおかげで簡単にビルドができた。
（ビルドスクリプトが古いという問題はDockerと関係ない。
実機でもVMでも最新のソースから新しいビルドを作成したら同じことになる）

お前の頭の中からにはこの使い方が完全に抜け落ちてるんだわ
そういうやつが語っても説得力無いよ。

VMとDockerは組み合わせて使うもの。最初から俺はそう言ってる。

Docker （前々スレ。何年前だよｗ）
https://mao.5ch.net/test/read.cgi/linux/1374861492/760
> 760 名前：login:Penguin[sage] 投稿日：2016/10/30(日) 19:57:56.57 ID:PgdoAzbd [1/2]
> AMI or Dockerじゃないんだよ。
>
> AMI + Dockerというふうに組み合わせて使うんだよ。
> っていうかDockerだけじゃ使えない。
410 ：login:Penguin：2019/12/01(日) 18:31:46.98 ID:qT+FNDQS.net: 当時はDockerだけじゃ使えないと書いているが、
今は、Dockerイメージをそのまま動かすサービスが生まれてるな。
まあもちろん実際にはその下にVMがいるわけだけど。
Dockerイメージを指定するだけで動かせるという意味ね。
411 ：login:Penguin：2019/12/01(日) 18:34:10.59 ID:qT+FNDQS.net: >>405
> ただ癖が強すぎるし、VMと比べて何故ここまで違いが大きいのかといった、当然の疑問に

VMと全く別のものだから
違うも何も、別のものだから違って当たり前

初心者は勘違いしてVMと比べてしまうが、そもそもDockerはVMとは関係ないものだから
俺は違いがどうとか比較なんかしてない。お前は初心者から抜け出せてないんだよ。
412 ：login:Penguin：2019/12/01(日) 23:16:07.98 ID:fdPwLs/X.net: >>409
相変わらずお前はズレまくってるな！ｗ
もうマジでこの件に関するDockerに出てくるDocker特有の問題はDockerのせいじゃなく、
VMに関する全ての操作はやってられないとｗ。

>Mozcの例から理解しなかったのかな？
これも
>お前の頭の中からにはこの使い方が完全に抜け落ちてるんだわ
これも君にそっくり返すよW
もうお前はレスするなｗ馬鹿すぎて話にならない。
ボッチでニートで実務経験に乏しすぎるお前じゃ、俺が何も止めているのか絶対にわからないｗ
話をしても無駄だから話はしないｗ

>> AMI + Dockerというふうに組み合わせて使うんだよ。

うん、正にそういうことだね。
おれはお前以外の人の書き込みからそれを学んで、心から納得したよ。
お前の書き込み「だけ」ズレすぎているし一人よがり過ぎるから、その点で突っ込まずにはいられなかった、と言うだけ。
413 ：login:Penguin：2019/12/01(日) 23:19:09.03 ID:YiJOHqAn.net: >>412のレスについて

ズレまくってると言うばかりで、どこがズレてるのか言わない。
相変わらず、俺に対して、何も指摘できていない。
ただただ、文句を言うばかり。
414 ：login:Penguin：2019/12/01(日) 23:20:20.84 ID:YiJOHqAn.net: > VMに関する全ての操作はやってられないとｗ。
VMは関係ないと言ってるのに、またVMの話を持ち出す。
全ての操作はやってられないなどと俺は言ってない。全部>>412の思い込み。
415 ：login:Penguin：2019/12/01(日) 23:41:50.11 ID:Y8NJ61TV.net: Ruby 製のVagrant の作者、HashiCorp のMitchell Hashimoto は、今世紀最大の起業家！
今は、Go 製のTerraform, Packer を作っている

彼が時代の中心だから、彼についていけばよい

他には、CircleCI, GitHub Actions
416 ：login:Penguin：2019/12/01(日) 23:55:04.57 ID:YiJOHqAn.net: > おれはお前以外の人の書き込みからそれを学んで、心から納得したよ。

ようやくVMとDockerは使い方が違う。組み合わせて使うものと理解したようだが
お前のその書き込みは「お前から学んだということは認めたくない」と言うためだけの書き込みだなｗ

「組み合わせて使う」と書き込んでるのはたいてい俺だと思うけど、
俺以外の書き込みから学んだとは、一体どの書き込みから学んだんだろうか？
指摘してみてほしいところだが、ま、いえないよなぁｗ
417 ：login:Penguin：2019/12/01(日) 23:59:45.78 ID:YiJOHqAn.net: >>415
CircleCIもGitHub ActionsもDockerベース

CircleCIは2.0でDockerベースに変わったし、
GitHub Actionsは以前はDockerfileが必須だった。

Packerも随分前からDockerイメージを作れる
（Packerはしばらく使ってないが、dockerのキャッシュ使うようになった？
正直これができないと、使い物にならないレベルなんだけど）

Terraformはすまんね。知らない。

世の中Dockerだらけｗ
418 ：417：2019/12/02(月) 00:04:37.15 ID:iQ/jQknl.net: VagrantはVirtualBoxがHyperVと共存できないから使うのやめたな。
Vagrant+HyperVという使い方ができるのは知ってるけど、
WSLができてWindowsがLinux同等に使えるようになったから実機で必要十分になった。
（Macはもとより実機で開発。もちろんDockerはWindowsでもMacでも使える。）
わざわざ開発マシン（実機）の中に、別の開発マシン（VM）を作るという二重構成にする必要がない。
419 ：login:Penguin：2019/12/02(月) 09:24:17.50 ID:UZ4iaYjq.net: Windowsでdocker自体を動かすのには
さすがに仮想マシンが必要
ホストOSもLinuxなら要らない

Docker for WindowsはLinux使うからHyper-Vが必要
WSL2もHyper-Vを利用する

WSL2は必要なHyper-V機能の一部がHome Editionにも配布されるので
Homeでも利用可能になる

仮想マシンを利用する方式に変更した事で
WSL1では動かなかったdockerもWSL2では使えるようになった
420 ：login:Penguin：2019/12/02(月) 15:23:52.09 ID:cX5TDnkz.net: GAFAMは普通にDockerの考え方に順応して使ってるよな

最近出てきた訳でもない
登場してかなり経つ安定した技術なのに
まだ全く使ってないというのは流石に頭硬すぎ
421 ：login:Penguin：2019/12/02(月) 21:16:18.41 ID:nGJwV5Oa.net: GoogleはDockerが登場する前からコンテナ使ってたらしいしな
そういう所は今、一日に何十回（何百回？）もデプロイしてる。

古いやり方、多くても一ヶ月に一回、一週間前までにデプロイ計画立てて
サービス停止して深夜作業でデプロイするようなやり方では到底無理

顧客も賢くなってきてるから、丁寧にやってるから遅いんですよとかいう
言い訳はもう通じなくなってる。

みんながコンテナ使ってる中、あなたはコンテナ使わずに
同じぐらいの速度で開発ができますか？ってことだよ。
422 ：login:Penguin：2019/12/03(火) 00:34:18 ID:tig7/aUP.net: オフラインで使う組み込み系だと開発環境構築をちょっと楽するぐらいしか使い道ないわ
423 ：login:Penguin：2020/01/04(土) 16:07:12.22 ID:IuViAdEQ.net: 1. あるマシンに他ユーザーから隠しておきたい秘密情報のファイルがある
2. rootから隠すことはできない。
3. だから他ユーザーはrootになったりsudoが使えてはいけない。（自分はなって良い）
4. ユーザーがdockerを使えるということはrootの権限があるのと同じことである
（例えばボリュームを使えば、どのディレクトリも読み書きができる。）
5. dockerグループに追加してdockerコマンドの実行にsudoを不要にした所でそれは変わらない

以上のことから、あるマシンに他ユーザーから隠しておきたい秘密情報がある場合は
そのマシンで他にdockerが使えるユーザーがいてはならない

言い換えると、自分以外のdocker使用者がいる場合はそのマシンに秘密情報を置くことができないので
「秘密情報を置いて安全に管理してる」ならば「他に自分以外のdocker使用者がいない」を意味する

あってるよね？
424 ：login:Penguin：2020/01/04(土) 16:20:38.88 ID:IuViAdEQ.net: dockerサーバーがリモートにある場合がよくわからないんだよな

マシンAとマシンBがあってそれぞれ所有者は異なる。
dockerサーバーがリモートにあって
マシンAとマシンBの両方から接続する

ん？ローカルのディレクトリってリモートマシンのボリュームにできるの？

マシンAがdockerサーバーでコンテナを作ったとして、
マシンBが同じdockerサーバーに接続したらそのコンテナは見えてしまうのか？
つまりdocker execで乗り込めてしまうのか？

もしできてしまったら、マシンAが渡したボリュームにたいして
マシンBから読み書きできてしまう？

どこかで実験したいな
425 ：login:Penguin：2020/01/04(土) 23:16:07.85 ID:4WXnY3BD.net: ローカルをリモートのボリュームには通常できないでしょう。
426 ：login:Penguin：2020/01/05(日) 09:23:16.08 ID:sWW1tNjy.net: >>425
NFSやらSMBやらで共有するという話ではなくて？
427 ：login:Penguin：2020/01/05(日) 16:26:28.41 ID:PM+h1CUF.net: >>425
そのとおりでした。なんか勘違いしてましたね。

つまりはDockerサーバーにアクセスできるユーザーは
そのDockerサーバーが動いているマシンのroot権限を
持ってるのに等しいと理解しました。

だから例えばCIサービスとかを作るとして、複数の人が同じサーバーで
コンテナを動かす場合、Dockerに直接接続させてはならないわけですね。
ウェブインターフェースやRESTインターフェースをもたせて
そこで認証かけて、やれることも制限しろと
428 ：login:Penguin：2020/01/05(日) 18:41:47.66 ID:6QavSJIx.net: root持ってりゃdocker停止もアンインストールもOSシャットダウンもできるわけなので
429 ：login:Penguin：2020/01/05(日) 21:24:00.57 ID:p4jkzryR.net: docker composeがルート権限必要だから、AとBでコンテナ作れたらどちらでもなんでもありになる。
430 ：login:Penguin：2020/01/05(日) 22:06:51.29 ID:9zcJiqAl.net: あれ非特権モードでも？
431 ：429：2020/01/05(日) 22:28:17.96 ID:p4jkzryR.net: Docker19.03からルート権限不要モードが追加されたんだな。>>429は誤情報。
432 ：login:Penguin：2020/01/05(日) 22:30:34.66 ID:IPuUazgK.net: ルート権限が不要ってだけで
同じdockerサーバーに接続してるユーザー同士で
隠し事はできないよね？
433 ：login:Penguin：2020/01/05(日) 22:44:47.94 ID:IPuUazgK.net: あるユーザーがDockerを起動して
同じホストの他のユーザーはそのDockerに接続できるのだろうか？
接続できてしまったら、あるユーザーのファイルは読み書きし放題？
434 ：login:Penguin：2020/01/05(日) 22:50:31.17 ID:IPuUazgK.net: そうか、MySQLなんかと何が違うのかと思ったら
Dockerって認証がないのか。無いよね？
435 ：429：2020/01/05(日) 23:36:13.44 ID:p4jkzryR.net: ルートレスモードは分からないが、通常モードはその通り。マルチユーザー向きではない。

実験した方が早いのでは？ルートレスをインストールして、
ubuntu 辺りで二つアカウント作って、
それぞれのコンテナにアクセスできるかどうか。
436 ：login:Penguin：2020/01/06(月) 08:12:36.75 ID:/JEJvQJG.net: Docker Toolbox (windows)使ってる人いる？

docker run -v /:/mnt -it alpine ls -al /mnt
の結果が見たいんだけど誰か貼り付けてくれない？

ちなみにDocker Desktop for Windowsの場合
total 8494
drwxr-xr-x 1 root root 280 Jan 4 19:54 .
drwxr-xr-x 1 root root 4096 Jan 5 23:10 ..
lrwxrwxrwx 1 root root 11 Jan 4 19:54 C -> /host_mnt/c
drwxr-xr-x 2 root root 14336 Nov 13 09:39 bin
lrwxrwxrwx 1 root root 11 Jan 4 19:54 c -> /host_mnt/c
drwxr-xr-x 11 root root 2960 Jan 4 19:54 dev
drwxr-xr-x 1 root root 180 Jan 4 19:54 etc
drwxr-xr-x 1 root root 60 Jan 5 22:08 home
drw-r--r-- 3 root root 60 Jan 4 19:54 host_mnt
drwxr-xr-x 1 root root 60 Jan 4 19:54 lib
drwxr-xr-x 5 root root 2048 Nov 13 09:39 media
drwxr-xr-x 2 root root 2048 Nov 13 09:39 mnt
drwxr-xr-x 1 root root 80 Jan 4 19:54 opt
dr-xr-xr-x 174 root root 0 Jan 5 04:53 proc
drwx------ 1 root root 60 Jan 4 19:54 root
drwxr-xr-x 1 root root 140 Jan 4 19:54 run
drwxr-xr-x 2 root root 30720 Nov 13 09:39 sbin
-rwxr-xr-x 1 root root 8640280 Nov 6 09:27 sendtohost
drwxr-xr-x 2 root root 2048 Nov 13 09:39 srv
dr-xr-xr-x 13 root root 0 Jan 5 21:55 sys
drwxrwxrwt 1 root root 40 Jan 5 23:10 tmp
drwxr-xr-x 1 root root 80 Nov 13 09:39 usr
drwxr-xr-x 13 root root 2048 Nov 13 09:39 var
437 ：login:Penguin：2020/01/06(月) 08:41:19.24 ID:/JEJvQJG.net: Docker Desktop for WSL2ってWSL2の中のディレクトリもボリュームに指定できるっぽい？
438 ：login:Penguin：2020/01/06(月) 08:54:42.63 ID:OVK7howH.net: ただのVMなんだからできないわけがないだろう
439 ：login:Penguin：2020/01/06(月) 09:09:29.13 ID:/JEJvQJG.net: >>437
WSL1もVMだよ？

現行のDocker Desktop for Windowsではdocker専用のVMを使っていて、
Docker Desktop for WSL2では、WSLすべてで一つのVMを共有しているからできるのかな？
440 ：login:Penguin：2020/01/06(月) 09:09:40.26 ID:/JEJvQJG.net: >>438あての間違い
441 ：login:Penguin：2020/01/06(月) 09:10:28.32 ID:/JEJvQJG.net: もう一つ訂正
× WSL1もVMだよ？
○ Docker Desktop for WindowsもVMだよ？
WSL1はVMではないね
442 ：login:Penguin：2020/01/06(月) 09:12:31.58 ID:2KANC7Df.net: よく知らんがwslのディレクトリをwinからマウント出来るのであれば可能なんじゃないの？試して教えて
443 ：login:Penguin：2020/01/06(月) 09:13:49.21 ID:/JEJvQJG.net: でもまあ、すべてのWSLのインスタンスｄ一つのVMを共有しているからと言って
そのWSLはコンテナ技術で分離されてるはずなんだから、そう単純にはいかないはずなんだがな
/mnt/wslに他のWSLのコンテナのディレクトリらしきものが見えてるし
WSLのコンテナ間でディレクトリを共有する技術がWSL2にあるんだろうな
444 ：login:Penguin：2020/01/06(月) 09:18:27.00 ID:/JEJvQJG.net: WSL2のubuntuのマウント状況

$ df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sdd ext4 263174212 1396116 248339940 1% /
tmpfs tmpfs 1633568 0 1633568 0% /mnt/wsl
tools 9p 66509328 30595464 35913864 47% /init
none devtmpfs 1631092 0 1631092 0% /dev
none tmpfs 1633568 8 1633560 1% /run
none tmpfs 1633568 0 1633568 0% /run/lock
none tmpfs 1633568 0 1633568 0% /run/shm
none tmpfs 1633568 0 1633568 0% /run/user
tmpfs tmpfs 1633568 0 1633568 0% /sys/fs/cgroup
C:\ 9p 66509328 30595464 35913864 47% /mnt/c
/dev/sdc ext4 263174212 1545568 248190488 1% /mnt/wsl/docker-desktop-data/isocache
/dev/sdb ext4 263174212 123192 249612864 1% /mnt/wsl/docker-desktop/shared-sockets
/dev/loop0 iso9660 248570 248570 0 100% /mnt/wsl/docker-desktop/cli-tools

/mnt/wsl/docker-desktop-dataとかって/dev/sdcでext4なのか
ちょっと想定外だったｗ　これ他のコンテナじゃなさそう。
WSLに割り当てたディスクなのかも
445 ：login:Penguin：2020/01/08(水) 15:48:58.62 ID:ksPzE1/R.net: あるコンテナを--restart=alwaysで自動起動するタイミングで、ホスト側でコマンドを実行させる方法ってありますか？

「そのコンテナが起動したら、ホストのスタティックルートをコンテナのIPに向ける」
という条件を実現したいです。

これまでは --restart=always を使っておらず、スクリプトでいちいちコンテナを起動していました。
それならスクリプト内にrouteコマンドを仕込んでおくだけで簡単だったんですが。
446 ：login:Penguin：2020/01/08(水) 15:52:55.36 ID:wWoUnX7g.net: そんな面倒なことしなくても普通に固定IP振ればいいだけでは
447 ：login:Penguin：2020/01/08(水) 16:50:00.22 ID:ksPzE1/R.net: コンテナでOpenVPN動かしてて、そのVPN先までルートを通したいんですよね。
コンテナには固定IP振ってるんですが、そもそもその固定IPがDockerネットワークなので
OS起動時には存在せず、OS起動時のルーティングは切れない、と。

コンテナに物理NWのIPを振るとか
ホストでcron回すとか割と泥臭いことやれば解決できると思うんですが、
なんかもっとスマートな方法ないかな…と。
448 ：login:Penguin：2020/01/08(水) 17:21:17.56 ID:ITBdUvUl.net: 好みとは思うが
「コンテナの機能にホストが依存する構成」
は上下ひっくり返った感じで落ち着かないので避ける
449 ：login:Penguin：2020/01/08(水) 18:55:54.72 ID:i7Ggys1A.net: >>447
> コンテナでOpenVPN動かしてて、
使い方が間違ってる可能性が高いな。
Dockerはそのような目的で作られていない。
目的外のことをするから難しくなる
450 ：login:Penguin：2020/01/08(水) 20:29:54.16 ID:m+D5UTvu.net: Kubernetesのhelmチャートには
ホストOSの設定を起動時に変える物があるけど？

kiamはAWSのメタデータAPIへのアクセスを仲介するのにiptableルールを自動的に書き換える機能がある

Elasticsearchはカーネル設定のvm.max_map_countを特権コンテナを使って置き換える

これらはホストごとに一回だけで良いので
1回しか起動しないが
451 ：login:Penguin：2020/01/08(水) 20:36:06.71 ID:avX2X6NW.net: だから何なの
452 ：login:Penguin：2020/01/08(水) 22:07:16.36 ID:htMW+uqX.net: 前の人もそうだが、複雑な事をやりたければk8s使えばどうにかなる。

設定その他簡単ではないけどね
453 ：login:Penguin：2020/01/08(水) 22:23:08.42 ID:i7Ggys1A.net: 話分かってないならでてこなくていいよ。

k8sは大規模な構成を作るためのもので
複雑な事をするものではないし、
ましてや間違った使い方を解決するためのものでもない

たった数個のコンテナでk8sなんか使い物になるかよ
OpenVPNなんて使用メモリ5MBぐらいで、貧弱なブロードバンドルータでも
動くっていうのにk8sつかうと1GBも持っていかれるわ
超軽量（苦笑）のk3sでもたった（苦笑）512MBってアピールしてる程度だしな
454 ：login:Penguin：2020/01/08(水) 23:57:27.85 ID:ghrrHBBS.net: よく分かんないけどホストOSのネットワークで動かしたり
ポートマッピングでホストOSのポートでアクセスできるよう設定してから
iptablesでルート設定して流すだけじゃないの？
455 ：login:Penguin：2020/01/09(木) 00:45:09.92 ID:M2xrYdZL.net: >>454
あのさあ、せっかくコンテナの外から
仮想化して可搬性持たせてるのに
それをぶち壊すような使い方したら
Docker使う意味ないでしょ
456 ：login:Penguin：2020/01/09(木) 04:57:13.50 ID:6QLBQsrn.net: >>453
間違った使い方ってのは貴方の主観でしょ。

メモリ1G程度の違いが何の問題になるのか、全く分からないのだがw
自宅で運用してるが、消費電力で2W程度の違いでしかない。
457 ：login:Penguin：2020/01/09(木) 05:08:33.92 ID:6QLBQsrn.net: VPNのIPの話はk8sのサービス→ロードバランサ使えば瞬時に解決する話。

k8sは外部公開用の話が多いのでその手の技術や情報が充実している。dockerはローカル環境想定なので、外部公開系はできなくはないが機能的に微妙。

そもそもとしてvpnはクラウド経由させれば細かいIPの設定は不要なわけだが、その辺りの知識も無さそうw
458 ：login:Penguin：2020/01/09(木) 08:20:56.55 ID:M2xrYdZL.net: >>456
> メモリ1G程度の違いが何の問題になるのか、全く分からないのだがw
金かかるだろ？何を言ってるんだろうか
459 ：login:Penguin：2020/01/09(木) 08:21:38.97 ID:M2xrYdZL.net: あと電気代じゃねーぞ。まあ電気代の話にすり替えてごまかそうとしてるんだろうけどなｗ
460 ：login:Penguin：2020/01/09(木) 08:23:29.67 ID:M2xrYdZL.net: >>457
なにクラウド使う前提にしてんの？ｗ
VPNがクラウド経由させれば不要とか
何をどう使えばそうなるのか言ってみ

つまりいくら金がかかるのかって話だ
461 ：login:Penguin：2020/01/09(木) 08:51:57.55 ID:CnTio2h+.net: Dockerコンテナをシステム・サービスのように使う例などいくらでもある

https://coreos.com/os/docs/latest/booting-on-ecs.html

これだってそうだ
kiam同様、AWSメタデータ APIの仲介役として
ECSエージェントとして利用している

kiamやElasticsearchのhelmチャートが
ホストOSの設定を変更するのは、あくまで一例
Dockerコンテナ内でやらずとも、systemdユニットでやる方法がある
462 ：login:Penguin：2020/01/09(木) 09:04:53.08 ID:CnTio2h+.net: DockerでOpenVPNってこれ？
https://github.com/kylemanna/docker-openvpn/blob/master/README.md

コンテナに特権を与える事でホストOSのネットワークへのアクセスを可能にしている

systemdの初期化スクリプトも入ってる
これ使えばいいんじゃね？
知らんけど
463 ：login:Penguin：2020/01/09(木) 09:16:12.84 ID:M2xrYdZL.net: 今回問題にしてるのは、システムサービスじゃなくて
ルーティングサービスだ
464 ：login:Penguin：2020/01/09(木) 09:28:46.16 ID:CnTio2h+.net: 特権与えればホストOSの設定にアクセス出来るから
基本的にコンテナ外でできる事は
コンテナ内でも出来る

iptablesの設定だって変えられる
変えて何が悪い？
実際やってる人なんていくらでも居るじゃん
465 ：login:Penguin：2020/01/09(木) 11:13:36.32 ID:1eanVRuK.net: https://github.com/hwdsl2/docker-ipsec-vpn-server
自分はこれつかってIPsec/L2TPサーバーやらせてるな
466 ：445：2020/01/09(木) 13:14:25.22 ID:cTaOp8rO.net: 皆さんありがとうございます。

k8s未経験だけに、ルーティング1つ書くためだけに導入するのはちょっとハードル高いですが
入れればできそうってのは覚えておいて、今後機会があればやってみます。

OpenVPNコンテナは、alpineスクラッチからDockerfileで手構築です。
元々オンプレで動かしてたものをコンテナ化した都合から、色々いじってるので。
ただアプローチとしては>>464さんの言うとおりだなぁと思いました。
権限与えてるんだから、コンテナ内からホストにルーティング投げればいいだけですね。
その方向で試してみたいと思います。
467 ：login:Penguin：2020/01/10(金) 23:04:53.49 ID:SGMX+Q1g.net: openvpnのコンテナ探して、やり方をそのままやった方が早そう
468 ：login:Penguin：2020/01/15(水) 16:07:08 ID:M8GRLPix.net: dockerでもdocker-composeでもいいんだけど、
シェルスクリプトを作る以外でマルチステージビルドの
ようなことを他の手段はないですかね？

つまりあるDockerfileをbuildする。
この時、FROMに別のDockerfileが指定されていて、
そっちを先にビルドして使うような感じにしたい

FROMにイメージ名が書いてあればそれをpullするけど
そうじゃなくてイメージをアップしたくなくて、
ローカルでビルドしたい。それを自動的にしたい。
469 ：login:Penguin：2020/01/15(水) 16:13:25 ID:+oUgohk9.net: >>468
ローカルにdockerイメージリポジトリを作ればよい。
470 ：login:Penguin：2020/01/15(水) 16:21:38 ID:M8GRLPix.net: dockerイメージリポジトリにイメージをアップしたくないんですよ
471 ：login:Penguin：2020/01/15(水) 16:44:01 ID:cqAMYOAh.net: いやだからローカルに作ろうよ
472 ：login:Penguin：2020/01/15(水) 16:46:55 ID:M8GRLPix.net: いや、だからアップしたくないって言ってるやんｗ
相手の環境なんかわからないんだからさ
473 ：login:Penguin：2020/01/15(水) 16:48:12 ID:M8GRLPix.net: 相手に、このコマンドを実行すればOKですって書くのはまだいいけど、
相手に、ローカルに作ってください、作ってアップしてくださいって
手順を長々と書くのはダメやろ？
474 ：login:Penguin：2020/01/15(水) 16:51:06 ID:6O0iX9bd.net: 相手ってなんだよ
いきなり新しい登場人物か
475 ：login:Penguin：2020/01/15(水) 18:45:17 ID:yxjUdNw1.net: できるけど
476 ：login:Penguin：2020/01/15(水) 19:29:55.39 ID:M8GRLPix.net: >>474
何も増えてないよ。
「dockerイメージリポジトリにイメージをアップしたくない」と言ってるのに
それを無視するから、無視できないように補足しただけ
477 ：login:Penguin：2020/01/15(水) 21:02:50 ID:FeJAdkeM.net: 最初はなかった「相手」が増えてるじゃん
478 ：login:Penguin：2020/01/15(水) 21:12:09 ID:WmUoZk76.net: じゃあ「相手」は無視していいよ
関係ない話だから
479 ：login:Penguin：2020/01/15(水) 21:30:30.57 ID:D3zJtvMI.net: 利用マニュアルにコマンド並べればいいんじゃないの？
シェルスクリプトとPowerShell両方用意してるプロジェクトもあるね
480 ：login:Penguin：2020/01/16(木) 15:06:12 ID:HmEXTTgD.net: >>468
そのDOCKERイメージをtgz形式にsaveしたものを、
dockerリストアコマンドでイメージリストに展開してから、処理を行えば？

あ、シェルスクリプト禁止か。
481 ：login:Penguin：2020/01/16(木) 19:00:48 ID:zyhk0GYW.net: >>480
禁止っていうか、シェルスクリプト作るなら誰だってできるって話
Dockerfileビルド時に依存したDockerfileも自動的にビルドする方法は
マルチステージビルド以外では方法はなさそうね
482 ：login:Penguin：2020/01/17(金) 07:24:42.58 ID:ZAXZSb1y.net: むしろマルチステージビルドという仕組みがあるのね
483 ：login:Penguin：2020/01/19(日) 19:15:57 ID:6YirC2HC.net: Docker Hubのさぁ、Automated Buildでさぁ
GitHubのREADME.mdを中途半端に持ってくるのやめてくれないかな
リンクあるだけでいいだろ、あれ誰が嬉しいんだ？
484 ：login:Penguin：2020/01/20(月) 17:21:05 ID:NtEsdlOO.net: >>483
一理ある
485 ：login:Penguin：2020/01/20(月) 18:26:17 ID:hh3AXqYf.net: >>483
一理あるから、Docker Hubに文句言ってきてください。
486 ：login:Penguin：2020/01/20(月) 23:01:44 ID:j4KqcwiZ.net: >>483
デメリットあるの？
概要把握したい向きもあるだろう
487 ：login:Penguin：2020/01/21(火) 00:08:02 ID:3DzPFxLf.net: >>486
> 概要把握したい向きもあるだろう
一行の見出しでは情報を伝えられないだろ？

Automated Buildを使わなければ丁寧に概要を書くこともできるし、
GitHubのREADME.mdをコピペすることだってできる

でもAutomated Buildを使うと、GitHubのREADME.mdを
表示させることしか出来ないんだよ
丁寧に書いてもAutomated Buildが走ると消されるｗｗｗ
488 ：login:Penguin：2020/01/22(水) 21:54:29 ID:tgVfjbcp.net: Amazon EKSが50%値下げだってよ
でもまだ高い、クラスター1つくらいは
タダにしてくれよ
489 ：login:Penguin：2020/01/22(水) 23:01:11 ID:Fr3HVC6X.net: クラスター使ったことある？
高いの？

いくらすたー？
490 ：login:Penguin：2020/01/22(水) 23:48:26 ID:OxBzKT9R.net: googleも無料枠だと無理だからねえ。
それ以前にAWSも無料枠欲しいな。

忘れてたら毎月600円課金されてた
491 ：login:Penguin：2020/01/24(金) 20:27:25 ID:Pc7e1TLp.net: etcd: t3.micro (リザーブドで購入) * 3
k8s api server: t3.small （スポットインスタンス）* 2
etcd: EBS 9GB * 3
k8s api server: EBS 16 GB * 2

これでやれば40.64ドル
EKSの72ドルより安いが
安定するかは知らない

APIサーバーの負荷分散に
NLBを使うと17.5ドル
これを含めると58.14ドル

DNSラウンドロビンでも負荷分散出来るけど
更新時の反映の遅れを考えると
NLBの方がいい

NLBはイングレスとAPIサーバーが
1つのNLBを共用も可能

EKSでイングレスの負荷分散にNLBを使うなら
72+17.5で89.5ドル
492 ：login:Penguin：2020/01/24(金) 20:40:22 ID:Pc7e1TLp.net: HAとか気にしなければさらに安く出来るが
大事な環境でやるのはおすすめしない

t3a.smallのスポットインスタンス1つと
17GBのEBSを使い
etcdとk8sのapi serverを同居させれば
7.37ドルでコントローラーノードが作れる

いずれの場合も当然ながら
ワーカーノードは別料金

k3sとか使えばもっと安く出来るかもしれないが
やってない
493 ：login:Penguin：2020/01/25(土) 00:15:37 ID:IX/hIA45.net: CVE-2019-5021
いまいちこの脆弱性がよくわからないんだけど、
どういうシナリオで攻撃が成功するの？
攻撃者は何を使うの？docker exec？
494 ：login:Penguin：2020/01/25(土) 18:04:37 ID:ES14vB7p.net: ちょっとした疑問なんだけどさ、docker pullってあれ
レイヤーごとに並列でダウンロードしてるよね？

なんとなくレイヤーは分けたくないなって思ってたけど
でかいファイルは複数のレイヤーに分けておくと
ダウンロードが速くなったりするのかな？

その観点からのレポートってどこかにない？
495 ：login:Penguin：2020/01/25(土) 18:13:26 ID:oy3JqaRN.net: 初めてDockerを触ろうと思っています
Windows10Proで動かしたいんですが調べてみると
Docker for WindowsとDocker Toolboxのどちらを入れれば良いのか分かりませんでした

用途としてはPythonの開発環境をDockerに組もうと思っているのですが
どちらを使えば良いのか教えていただけると幸いです
496 ：login:Penguin：2020/01/25(土) 18:53:06 ID:ES14vB7p.net: 通常はDocker for Windows （＝Docker Desktop for Windows）

歴史的にはWin版、Mac版共に、Docker Toolboxが最初に作られ
そしてDocker Desktop for Windows or Macが作られた。
Docker Toolboxは古いもの扱い。

1. Docker Toolbox・・・仮想マシンとしてVirtualBoxを使った実装
2. Docker Desktop ・・・WindowsではHyperV、MacではOSネイティブの何とかを使った実装

つまり、サードメーカーのVirtualBoxを使うのをやめて
OSネイティブの仮想マシン技術を使うようになった

ただしその結果、Windowsでは制限が生まれた。
HyperVはProでしか使えない。HyperVはVirtual BoxやVMWareと（ほぼ）共存できない。
だからHomeを使ってるとか、他の競合する仮想マシンを
使う必要があるなら古いDocker Toolboxを使わざるを得ない

3. Docker Desktop for WSL2 が近いうちに登場する

WSL2は近々登場するWindows標準機能で、
HyperVのサブセット機能の仮想マシンを使って動かすLinux環境

Docker Desktop for WindowsはDocker社で作ったLinux環境を使っているが
Docker Desktop for WSL2はWindows標準のWSL2のLinux環境を使うようになる

WSL2はいろんな性能が向上しているとともに、Windows 10 Homeでも使えるようになる。
Virtual BoxやVMWareと共存は相変わらず出来ないが、こっちは別で共存できるように開発中

あと数カ月後はDocker Desktop for WSL2を使う
497 ：login:Penguin：2020/01/25(土) 19:01:18 ID:ES14vB7p.net: > 用途としてはPythonの開発環境をDockerに組もうと思っているのですが

それは推奨しない。Dockerはアプリケーションを作るもの
Windows10Proなら、Pythonの開発環境としてはWSLを使うのが良い。

開発環境はWSLでもWindowsでもMacでもLinuxでも
仮想マシン上のなにかでも、どこでも好きなOSを自由に選べる
開発環境を自由に選べる理由がDocker

DockerというのはPythonで作ったアプリに可搬性をもたせるために
（どのOSでも動くようにするために）Dockerイメージでラッピングするというのが正しい使い方

作ったものがどこでも動くから、開発環境はどこでもいい。
どこでもいいからWindows10ProでPython開発環境として一番便利なWSLが推奨
498 ：login:Penguin：2020/01/25(土) 19:42:29 ID:F7NqsOON.net: 別にDockerを開発環境にしてもいいのに
このスレではそれやると発狂する人がいるよね
499 ：login:Penguin：2020/01/26(日) 00:27:49 ID:m8Av32+M.net: 開発環境としてDocker(というかコンテナ)使うのは環境汚さないで済むから寧ろ推奨する
VSCodeのRemote Developmentなんかのおかげで開発環境としてのコンテナがものすごく扱いやすくなったのも大きい
500 ：login:Penguin：2020/01/26(日) 11:56:04 ID:BR48jIcb.net: 今まで仮想マシンや物理マシンに対して、ansibleみたいなツールを使って設定の自動化をしていた
これがdockerになると、コンテナに対する設定はdockerfileに書くから、ansibleみたいなツールは必要なくなるという認識でええのかね
501 ：login:Penguin：2020/01/26(日) 12:26:39 ID:OzJ+Z2xw.net: >>500
Ansibleのメリットは複数のホストに跨った設定を一貫して管理できることであり、
そもそもDockerfileで置き換えられるような用途であればシェルスクリプトで十分だ
元々Ansibleなんか必要ない
コンテナ時代にAnsibleを使うとすればクラスタの構築や管理においてだが、普通はGKS、EKS、ECS使ってポチるだけだから小難しい構成管理なんか要らない
502 ：login:Penguin：2020/01/26(日) 12:41:22 ID:7x8NuhpY.net: ECSを動かすにはクラスターが必要
クラスターは通常VPC、起動テンプレート、ASGが必要
ECSタスク定義やサービスが必要
定期実行はスケジュールドタスクの設定が必要
プライベートネットワークにEC2を置きつつ
EC2をインターネットに繋ぐにはNATゲートウェイが必要
HTTPの負荷分散やローリングデプロイには
ELBが必要
CDNにCloudFrontが必要
データの保存先としてRDSやS3も必要
一部リソースはIAMロールの設定も必要
イメージ置き場にECRリポジトリも必要

これ全部ポチポチでやんの？
terraform使えよ
503 ：login:Penguin：2020/01/26(日) 12:41:34 ID:UB3s9UX0.net: >>496-499
ありがとうございます
まずはforWindowsでDocker自体に慣れてみます
504 ：login:Penguin：2020/01/26(日) 17:42:21 ID:oh//L3LW.net: >>500
Ansibleでできることを中の人が教えます - インストールと実行?EC2へのNginx投入までを学ぼう
https://employment.en-japan.com/engineerhub/entry/2019/04/12/103000

> 現在では構成管理にとどまらずその守備範囲を広げ、
> アプリケーションのデプロイやオーケストレーションなどにも利用できるようになりました。

↑この違い

インフラ担当者がアプリの複雑なデプロイまでやってた時代があった。
アプリを動かすにこれそれのパッケージが必要だから入れるとか入れ替えるとか
入れるだけならまだしも、複数のパッケージを入れるとか、
しかも標準パッケージにないものとか怖くてやってられない。

それが一時期、Ansibleでなんでもできるぜーって冪等性でどんなマシンでも
いっぺんに同じ状態にできるぜー（嘘）となってアプリの複雑なデプロイをAnsibleでやる時代があった。

冪等性があるといっても実際にはやってみなきゃわからんこともあるわけで
複雑なデプロイをAnsibleでやるのは苦痛でしか無い。
Ansibleはバージョン依存がひどすぎるから。

んでDockerがでてきた。アプリの複雑デプロイはDockerコンテナの起動という、
たった一つ（もしくは数個）の命令に置き換えられるようになった。
とはいってもこれは「アプリケーションのデプロイ」であって
構成管理やオーケストレーションの話とは関係ない

DockerベースになるとオーケストレーションはKubernetesを使うことが多い
守備範囲を広げたAnsibleは、元の構成管理だけをするように戻りつつある
いろいろ手を広げすぎたんだよ、やつは。
505 ：login:Penguin：2020/01/26(日) 17:46:42 ID:oh//L3LW.net: >>502
GCPならデプロイメントマネージャーという
クラウドサービス標準で、自社のクラウドを適切にサポートした
純正機能があるわけだけど、そこに外部が作ったterraformを使う意味あるの？
terraformという第三者が絡むせいで制限とか互換性問題とか生まれてるでしょ？
506 ：login:Penguin：2020/01/26(日) 18:15:00.87 ID:oh//L3LW.net: > そもそもDockerfileで置き換えられるような用途であればシェルスクリプトで十分だ

いつも思うけど「シェルスクリプトで十分だ」って考え方なんなんだろうね。
「シェルスクリプトが適切だ」が正しいと思うんだけど

シェルスクリプトが適切な問題を、プログラム言語でやろうとすると
めんどくさくなるよ。

リダイレクトとかパイプとか、実行環境を整える所から必要になってめんどくさい。
507 ：login:Penguin：2020/01/26(日) 20:17:48 ID:Dr6wHv91.net: Ansibleが担うのはprovisioningでDockerなどのコンテナはdeploymentのイメージがある
508 ：login:Penguin：2020/01/26(日) 21:03:20 ID:7x8NuhpY.net: AWSはCloudFormationあるけど
terraformより色々使いづらい点が多い
AWS製にも関わらず
たまにCloudFormationでだけ設定できない項目があったりする

S3の期限切れ削除マーカーの削除の設定が
何故か未だに未実装

https://stackoverflow.com/questions/40179860/support-for-expired-object-delete-marker-with-cloudformation

この質問が投稿されたのは2016年10月だが
2020年になっても放置
忘れられているっぽい
509 ：login:Penguin：2020/01/26(日) 21:12:50 ID:Sxuz1Gfw.net: まあ本家のツールが使いにくいっていうのならTerraformとかの意味があると思うけど
あとAWSとGCPを行ったり来たりしたり、同じものを別々の場所に構築するとか
コード共通でできるんでしょ？しらんけどｗ
510 ：login:Penguin：2020/01/26(日) 21:37:08.16 ID:7x8NuhpY.net: マルチクラウドは出来るらしいがやったことない
GCPやAzureは使ったことが無いし

開発環境と同じ構成で
EC2インスタンスのスペックやドメインだけ変えて作るのは可能

Terraformの方が便利とは言っても
複数モジュールの同時デプロイや
モジュール間の値の受け渡しが
Terraformだけでは不便なので
最近Terragruntも使い始めた

コスト削減のために、開発環境では使わない機能がある、
あるいは複数環境で1つのリソースを共有する場合に
巨大モジュールを作って大量の変数
でAWSリソースを作るか作らないかを制御するより
Terraformモジュールを分けた方が良いというのもある

Kubernetesを使ってもインフラの管理から完全に逃れることはできない
511 ：login:Penguin：2020/01/26(日) 21:48:04 ID:7x8NuhpY.net: TerraformのKubernetesプロバイダーで
helmのデプロイやKubernetesリソースのデプロイも出来る
TerraformのAWSプロバイダーでIAMロールを作成して
kiamで特定ポッドのみにAWSへのアクセス権限付与したりする合わせ技も可能

しかし微妙にかゆいところに手が届かない感はある
公式KubernetesプロバイダーはKubernetesリソースをHCLで書く必要がある
YAMLをそのまま使いたい、CRDを使いたい場合は
公式のKubernetesプロバイダーでは無理
非公式のプロバイダーが必要
banzaicloudのk8sってやつ

CRDが使えないって割と重大な欠陥の気がする

helmは最近v3が出たが
公式Terraformプロバイダーはまだv2までの対応
512 ：login:Penguin：2020/01/26(日) 23:59:58.56 ID:o6VABBUy.net: なにか便利な機能を提供してくれるならいいけど、
「使い方を変えるだけ」の道具はいらないなぁ

公式で同じことできるんでしょ？
それが簡単になったわけじゃなくて
使い方を変えるだけでしょ？

そしてそのプラバイダーが、ある機能に
対応してない困ったぞーっていうのを
永遠と繰り返してるでしょ？
513 ：login:Penguin：2020/01/27(月) 07:40:21 ID:xCTAmbZl.net: 新しいものにどんどんチャレンジして報告するべきじゃないのかな。
それがコミュニティへの貢献ってものでしょ。
キミたちは人柱なんだから。
514 ：login:Penguin：2020/01/27(月) 10:45:17 ID:oWpDpuvr.net: WindowsのDocker Desktopを2.2にアップグレードしてから、マウントしたボリュームが時々書き込めなくなってエラーになる状態になって
2.1に戻したら直った
調べたら2.1から2.2で内部構造がだいぶ変わってるんやね
515 ：login:Penguin：2020/01/27(月) 20:04:40 ID:VdNPUB7+.net: >>504
その状態でansibleにやらせる構成管理ってなんなんや
dockerを動かす物理マシンの構成管理だけやるという意味なんか
516 ：login:Penguin：2020/01/28(火) 03:27:51.51 ID:alr/KPAT.net: この前、Docker HubのREAME.mdがGitHubのREADME.mdを中途半端に
持っていくって話をした件だけどGitHub Actionsで同期取るっぽいのがあった
これで指定したやつを持っていってくれるかも
https://github.com/marketplace/actions/docker-hub-readme-description-sync
517 ：login:Penguin：2020/01/29(水) 14:22:12.33 ID:nynZIk47.net: k3s使ったらメモリー1GBのインスタンス3つでもHA出来る？
518 ：login:Penguin：2020/01/29(水) 14:26:25.10 ID:givpjA6N.net: k3sはメモリ512MBしか（笑）食わないんだろ？
ならアプリが512MBまでなら動くんじゃね？

k3sでこれだけだと、k8sはどんだけ食うんだよｗ
カーネルの使用メモリが少なくても台無し
519 ：login:Penguin：2020/01/29(水) 14:29:38.68 ID:6Q7T2cbs.net: workerは別途用意するだろJK
520 ：login:Penguin：2020/01/29(水) 19:59:16 ID:5uyhmzFh.net: 本家k8sは1GB RAMでは足りない気がする
kiamのサーバーと
helm v2のtiller
kube-iam-authenticator

controllerにこの3つを置いているが
2GBから1GBに減らしたらAPIサーバーが使えなくなった
だから本家は最低でも2GBのメモリーが必要
521 ：login:Penguin：2020/01/29(水) 19:59:44 ID:5uyhmzFh.net: etcdも同居してるからさらに厳しい
522 ：login:Penguin：2020/01/29(水) 20:00:56 ID:3wP3LyoD.net: なんでk8sってそんなにメモリ食うんだろう？
ただコンテナを管理するだけの仕組みじゃんか
523 ：login:Penguin：2020/01/29(水) 20:02:25 ID:3wP3LyoD.net: 高いVMインスタンスを売りつけるための
戦略としか思えないな
ウェブサーバーとか数十MB程度で動くのに
k8s化した途端1GBとか必要になる。アホかと
524 ：login:Penguin：2020/01/29(水) 20:05:31 ID:5uyhmzFh.net: 他のクラウドはコントローラーがタダで使えるらしいが
AWSだけまだ72ドル掛かる
高杉

大企業にとってははした金だから
それでも使う奴は居るのだろうが

>>523
GKEは安いの知ってる？
525 ：login:Penguin：2020/01/29(水) 20:07:53 ID:5uyhmzFh.net: ワーカーノードは1GBでも良い
コントローラーノードの金が気になるならGCP行ってGKE使え
うちもGKE使いたい所だが
AWSを使わねばならない
のっぴきならない事情がある
526 ：login:Penguin：2020/01/29(水) 20:16:03.69 ID:3wP3LyoD.net: kubernetsとかさ、クラウドの上にクラウドを作ってるみたいで
気持ち悪いんだよね。せっかく便利に使えるようになったクラウドを
なぜコンテナベースで再発明するのか？
527 ：login:Penguin：2020/01/29(水) 20:57:23 ID:zxPSLJvv.net: >>526
インフラエンジニアの雇用を維持するためだよ。マジで。
自社サービス系のインフラエンジニアって基本的にトラブルがなければ仕事ないから、
自然と問題なく動いているもののオーバーエンジニアリングに向かうものだ。
528 ：login:Penguin：2020/01/29(水) 21:15:29 ID:3wP3LyoD.net: オーバーエンジニアリング程度なら良いけどさ
メモリ食い過ぎで前より不便にしてるだけなんだよな
インフラ系って、変わってるだけで、何も良くなってない
529 ：login:Penguin：2020/01/29(水) 21:33:22 ID:9OcLAXSy.net: >>528
いや、だからGKE使えよ？
コントローラー無料だろ？
530 ：login:Penguin：2020/01/29(水) 22:10:05.14 ID:OCMkZsaj.net: >>526
元々クラウドのための仕様なんだが……。

ノードの数を負荷に応じて変更できるから、処理が多い時間はノード増やして処理し、少ない時間はノードを減らす事でコストを最適化できるのがk8sの売り。

規模が小さいとこの利点（オートスケーリング）が意味をなさなくなる。
531 ：login:Penguin：2020/01/29(水) 22:23:27 ID:BTLuyg2X.net: 1台しかないならdocker-composeでよくね？
1台しかないなら
532 ：login:Penguin：2020/01/29(水) 22:35:55 ID:OCMkZsaj.net: 従来は高価なオンプレを1台買ってスペック余らせるのが普通だったが、今はクラスタにする事で、オートスケーリングによりスペック（≒コスト）を最適化できるようになった。

ハイスペック1台ならdockerで十分だが、コスト面で最適化されてるかな？という話。
533 ：login:Penguin：2020/01/29(水) 23:26:28 ID:K0p5wp9W.net: >>532
それだけならECSとかで十分でしょ
k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ
534 ：login:Penguin：2020/01/29(水) 23:50:39 ID:OCMkZsaj.net: >>533
k8sはECSより高機能で汎用的だが学習コスト高めという印象。ECSはベンダー製なので、クラスタに関してはその通りだろうが、ベンダーロックインの問題がある。

ベンダーロックインの問題を気にせず、ECSで案件が済むならECSだろう。
535 ：login:Penguin：2020/01/30(木) 00:20:34 ID:KTDe4H4D.net: たかがコンテナ立ち上げるだけのことにベンダーロックインねえ
事業視点で言えば、k8sに習熟した少数のエンジニアにインフラをロックインされることの方がよほどリスクが大きいと思うけどね
536 ：login:Penguin：2020/01/30(木) 00:26:20 ID:OBlH/P8v.net: >>528
単に使い所を間違ってるだけとしか思えんが
そもそも別にk8s使わなくてもdockerはある程度規模に応じたオーケストレーションを標準に
近い形で用意しているはずで、それでは管理できないほど巨大な規模のサービスを運用するから
k8sですよ、って事で、当然メモリが食いすぎとか文句言う人が使う物じゃない気はする。
そういう人にはもっと小規模な物あるでしょ？
昔Googleの論文元にHadoop作って訳も分からずに食いついて先進的だカッコいいぜ俺スゲーとか
いって後からやっぱ遅ーえわこれｗとかいってた連中思い出すね。
自分たちが間違った場所に適用してるとは最後まで考えないｗ
537 ：login:Penguin：2020/01/30(木) 01:26:01 ID:pAQXSf/G.net: >>535
Amazonがk8sのサービス始めたのはこの理由らしいから、そういう意見も多いということなのだろう。

個人的にはk8sよりマルチビルドのdocker file の方が難解だな
538 ：login:Penguin：2020/01/30(木) 02:46:59 ID:N78kTYg5.net: >>533
> k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ

そうだよね？

広大なCPU空間を確保しておいて、自由に使いましょうというのならいいけど
コストの観点から空間自体を減らしたり増やしたりってのは適してないと思う
スケーリングならすでにGCEとかのクラウドの仕組みで実現できたじゃんって思う

そこにGKEを持ってきて使いづらくしたと思ったら、
どうせコンテナベースで課金とかするでしょ？
なんでクラウドの中にさらにクラウド作ってるんだろうって思う
539 ：login:Penguin：2020/01/30(木) 02:49:16 ID:N78kTYg5.net: >>537
> 個人的にはk8sよりマルチビルドのdocker file の方が難解だな

マルチステージビルドの事？どんだけ複雑なんだよｗ

あんなの、中間ファイルは不要だから
前のイメージでビルドしてできた生成物のみ
コピーして使いましょうってだけじゃんか
540 ：login:Penguin：2020/01/30(木) 03:04:05 ID:N78kTYg5.net: k8sの嫌なところは短いタイミングで強制アップデートな所だな
これがあるからストレージとしては使えない
データベースは別のサービスを使えってことなんだろうけど、
これがあるからHAの代わりにはならないんだよね
541 ：login:Penguin：2020/01/30(木) 08:22:30 ID:x2o8za8v.net: 自前k8sなら誰も面倒見てくれないので
アップデートもされない
証明書の期限短くすると
期限切れした時にAPIサーバーと通信できなくなるけど
542 ：login:Penguin：2020/01/30(木) 08:57:49.48 ID:JRKnodoF.net: APIサーバーの証明書は自動更新機能があった気がする

>>538
ワーカーノードは今まで通り課金される

k8sでのサーバーレス関数の実行は
EKSやGKEで最近できるようになったが
一部機能制限がある上に
確保するリソースが多いと通常通り
ワーカーノードを用意した方が安くなる事がある

サーバーレスはコールドスタートによる遅延の問題なども多分まだある
543 ：login:Penguin：2020/01/30(木) 09:18:13 ID:JRKnodoF.net: サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る

とは言ってもノードの起動は時間がかかるので
すぐには無理だが
544 ：login:Penguin：2020/01/30(木) 09:18:14 ID:JRKnodoF.net: サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る

とは言ってもノードの起動は時間がかかるので
すぐには無理だが
545 ：login:Penguin：2020/01/30(木) 11:27:06 ID:pAQXSf/G.net: >>539
他人が書いたのを検証するのが難しいってことね。他人に依存するかどうかという視点の話。
546 ：login:Penguin：2020/01/30(木) 11:44:27.37 ID:N78kTYg5.net: >>543
ノードの増減はk8sなくてもできたじゃん？

・負荷の応じてノードが増減できる
だったのが
・負荷に応じてでポットが増減できて、ポットの増減に応じてノードが増減できる
に変わってるじゃん？

二段階になってややこしくなってるし
ノード（課金対象）が増減しない範囲でのポットの増減が存在するわけで、
こんなんで正確な見積もりなんかできるの？

k8sはプロジェクト単位で使うものじゃななくて、
会社として広大なクラスタ空間を予め確保して、その中で複数の異なる
サブプロジェクトをいくつも動かすって使い方をする
Googleぐらいしかまともに使えないよ
547 ：login:Penguin：2020/01/30(木) 11:52:10.03 ID:N78kTYg5.net: k8sはノード＝1つないし少数のそれぞれ違うポットを配置するという使い方じゃないんだよね

1つのノードが複数のポットを動かすスペックを持っていて、
多数の小さなポッドをその中で動かすという使い方をする。

1つのノードで同じ種類のポットがたくさん生まれて
消えるような場合じゃないとうまく使えない

自動管理されたHA環境ではないんだよね
548 ：login:Penguin：2020/01/30(木) 17:42:40 ID:IVBe8aPz.net: ECSは当初タスク数がEC2インスタンス数と連動しない残念仕様だった

こちらもタスク数に応じてインスタンスが生成される

https://dev.classmethod.jp/cloud/aws/aws-ecs-cluster-auto-scaling/

5タスクを同時に動かそうとすると、
5台のEC2インスタンスが生成される
超シンプル
549 ：login:Penguin：2020/01/30(木) 17:44:08 ID:krDeGaUI.net: ECSサービス開始当初はEC2の数とタスクの数を連動させる機能が
無かったが、去年追加された
550 ：login:Penguin：2020/01/30(木) 18:28:37 ID:N78kTYg5.net: >>548
それは一般的な使い方としてはわかりやすいし、できるべきだよね。
ただk8sのそもそもの使い方としては、ずれてるんだと思う

その使い方であれば、インスタンスのオートスケールと変わらないわけだし
コンテナが動かせるというメリットはあるけどね

まあ各クラウドの間で共通のインターフェースができて
どこでも動かせるようになるのはいいと思うけど
そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい

もっと間を減らしてシンプルに出来なかったのかねぇ
やっぱりクラウドを使ってクラウドを作ってるように見えてしまう

k8sはある程度の空間を確保していて、そこで小さなポッドを多数起動して
全体の○％を超えたり減ったりしたら、クラスタを増減させて
通常はある程度の余力をもたせておく（遊んでるサーバーがある）という使い方なんだろう
インスタンス数を意識して最小の金額にするためのものじゃないかな
551 ：login:Penguin：2020/01/30(木) 19:32:50 ID:RH+cWAif.net: ECSも、タスク数をCPU使用率などのメトリクスと連動させれば、
CPU数に応じて「タスク数とインスタンス数」を同時に増やすことが可能
何が違うと言うのか

ECSも以前から「それぞれ別々に」インスタンス数とタスク数を増減する事は出来たが、
協調せずバラバラに動くので、
負荷の増加に反応してサービスのタスク数は増えたのに、
インスタンス数がちゃんと増えなかった、
あるいはインスタンス数は増えたのにサービス数が増えないとか
そんな動きになる可能性があった

1つのノードに複数のコンテナがあるような状況では
さらに話がややこしくなっていた
ノードのCPU使用率が一時的に増加していても、それはサービスの需要が増えたからではなく、
定期バッチ処理で負荷が一時的に高くなったのが原因だったり
552 ：login:Penguin：2020/01/30(木) 19:38:30 ID:RH+cWAif.net: Kubernetesはずっと前から
ポッド数によるノード増減ができた
パクったのはECS

自動でノード数の増減が要らない、
常に2台で良いって言うなら
Cluster AutoScalerを使わなくても良い
553 ：login:Penguin：2020/01/30(木) 20:00:23 ID:VJ/WHmRQ.net: そもそもECSって目的毎にクラスタ立てるもんだろ？
何でもかんでも一つのクラスタで済ませようなどと考えなければ従来のインスタンスベースのスケーリングで問題ない
それこそ「クラウドなんだから」だ
ID:RH+cWAifの主張は、クラウドの中にクラウドを作っているという批判に対する反論としては的外れに感じる
554 ：login:Penguin：2020/01/30(木) 20:33:30.31 ID:rH68C/el.net: RH+cWAifは別にクラウドの中にクラウドが～に対する回答ではない様な。
クラウドが～は自分で解答書いてるし。

>そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい

結局そういうことだよね。

https://aws.アマゾン.com/jp/docker/

Q: Docker Swarm、Kubernetes、Amazon ECS の違いは何ですか?
>多くの Docker コンテナを実行する場合は、Docker Swarm、Kubernetes、Amazon Elastic Container Service (ECS) などの
>オーケストレーションツールを使用することで、何千 (または何百万) ものコンテナの開始、停止、監視が可能になります。

日本は法人向けサービスやったとしても会社の絶対数が少ないしそもそも余程のことが無い限り
1サービスあたりのサーバは10台超えることは無い。じゃあ10台でオートスケールやるコンテナの仕組みは何なのさ？
ってニーズに全然答えようとしていない。
555 ：login:Penguin：2020/01/30(木) 20:50:52.19 ID:obKqsaeD.net: >>551
一番重要なのはコストの最適化なんだから、タスク数もしくは負荷に応じたインスタンス数の増減なんだよね。

> 負荷の増加に反応してサービスのタスク数は増えたのに、
> インスタンス数がちゃんと増えなかった、

そこな。スケールするのがコンテナとインスタンスの
二重になってるからすごく分かりづらい

そもそも一つのインスタンスの中で動くコンテナを増やしても
並列度は上ががっても処理速度は上がらんのよ
（CPUコアを使い切れるようにはなるだろうけど）

パッチ処理みたいに一つのデータを送ってコンテナで処理して終了みたいのであればわかりやすいけど
ウェブサーバーみたいにそれ自体が並列処理対応になってるものの
コンテナを増やしたって何の意味もない。インスタンスの数を増やすか
インスタンスの性能をあげなきゃならないのに、間にコンテナの話が入り込んでくる
556 ：login:Penguin：2020/01/30(木) 21:31:46 ID:rH68C/el.net: >スケールするのがコンテナとインスタンスの
>二重になってるからすごく分かりづらい

分かりにくいのはそうなんだろうけど、インスタンスを跨ぐコンテナはネットワークに
仕掛けしないと駄目だからしょうがないんじゃないの？それはDockerのあの変な
ネットワークの仕組みの為だろうけど。

>（CPUコアを使い切れるようにはなるだろうけど）

結局インスタンス（VM)の上にコンテナ乗っけてるって時点でハードを使い切る
コンテナ技術のメリットは消えており、AmazonのECSはなんちゃってコンテナで
しかない気はする。
557 ：login:Penguin：2020/01/30(木) 22:07:21 ID:obKqsaeD.net: コンテナベースにするなら、インスタンスの存在は完全に見えなくしないとだめだろうね。
そして「これこれの性能を持ったコンテナ」を「いくつ使用するか」で課金する。

あとやっぱりノードのアップグレードに伴う再起動が大変
コンテナ数ノード数が少ないとサービス停止に陥ってしまう可能性が高くなる
アップグレードを放置するとそのうちバージョン古すぎて非対応になるし

なんでみんなk8s頑張ろうとしてるんだろう
殆どの用途では大変なだけじゃないか？
558 ：login:Penguin：2020/01/30(木) 22:14:45 ID:x2o8za8v.net: Kubernetesの真の価値はそこで利用出来るソフトウェアにあるのでは？

サービスメッシュとかデータベースのオペレーターとか
なんかk8sで動くhelmチャートが動く環境が欲しいのでなければ
ECSとかでも良いし
そっちのほうが簡単と思う

クラウドの中にクラウドとか言うけどさ
サーバーに自分でインストールして
動かすソフトを作る側に取っては
Kubernetesだけ対応すれば
あらゆるクラウドで動くものが作れるようになった

自社のソフトウェアが様々なクラウドで動くのは、
ビジネスチャンスに繋がるんじゃね？

ソフト自体を配布するんじゃなくて
サービスとして売りたいなら
好きな物を使え
559 ：login:Penguin：2020/01/30(木) 22:20:59 ID:rH68C/el.net: 例えて言うなら56コア112スレのXeon買ってきてサーバー作って
そこにESXi入れて、CoreOSを20個インストールしてOS１つあたり
5コンテナ入れてk8s組んで、やったぜ俺スゲーとかｗ
そんな感じやな。

でそこで動く肝心なサービスの保守は完全に片手間で1日16時間労働ｗ

恥づｗｗ
560 ：login:Penguin：2020/01/30(木) 22:28:12 ID:fl66aBkL.net: 仕事でGKE使ってんだけど世の中の8割のサービスはこんな仕組み要らんだろうなーと思いながら触ってる
561 ：login:Penguin：2020/01/30(木) 23:23:25 ID:8SEpOjSd.net: >>558
ローカル環境でdockerと比べると、k8sは細やかな制御ができる分やりやすい。
562 ：login:Penguin：2020/01/30(木) 23:26:57 ID:8SEpOjSd.net: k8sはDockerに比べてIngressとロードバランサが優秀。
563 ：login:Penguin：2020/01/30(木) 23:27:43 ID:8SEpOjSd.net: 替わりにマシンスペックを食うわけだが……。コントローラで2W近く使う
564 ：login:Penguin：2020/01/30(木) 23:32:56 ID:vPq8TLea.net: k8sとDockerって比べるものじゃないじゃん
565 ：login:Penguin：2020/01/31(金) 06:06:57 ID:BYA66tlO.net: スペックを食うってのもなんだかな
566 ：login:Penguin：2020/01/31(金) 09:44:16 ID:zr53MAqg.net: swarmの事もたまには思い出してあげてください
567 ：login:Penguin：2020/01/31(金) 21:02:32 ID:PGkHP1z8.net: >>566
VMからサービス拡大で手軽なクラスタ使いたいから～、って理由で
Dockerに移行したらのなら、スケール的には一番しっくり来るんだけどね。
流行の技術じゃないから誰も手を出さんのか？まあDocker Swarmできます！
とかじゃ経歴書にかいても自慢出来んだろうけどね。
568 ：login:Penguin：2020/02/01(土) 09:45:31 ID:rnZpf00g.net: ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？
スケーリングされたインスタンス内でCPUと同数のスレッドでサービス立ち上げる事と
何が違うのか全く分からん。事態を面倒くさくしているだけに見えるｗ
569 ：login:Penguin：2020/02/01(土) 09:51:47 ID:a9slqYuq.net: >>568
デプロイをECSに任せたいだけだよ
自分でホスト弄りたくない
570 ：login:Penguin：2020/02/01(土) 10:02:57.25 ID:rnZpf00g.net: >>569
それはASGでホストが起動したときに、スタートアップか何かでgit pullする事と
何か違うの？
571 ：login:Penguin：2020/02/01(土) 10:15:11 ID:Xk5te6Cy.net: また仮想マシンイメージ最強おじさん？
老害乙wwwwww
572 ：login:Penguin：2020/02/01(土) 10:26:26 ID:+b4DF/Bv.net: git pullするって
仮想マシンイメージにアプリの内容を突っ込む訳でも無いのか
goとかJavaだったら毎回ビルド？
老害どころの騒ぎではないな

デプロイ成功するかどうか
同じ結果になるかどうか
毎回やってからのお楽しみって感じ？
時間がいくらでもあるなら
そうすれば良いんじゃない？
573 ：login:Penguin：2020/02/01(土) 12:47:32.37 ID:rnZpf00g.net: >>571-572
良くわかんねぇけど、もう少し論理的に説明してくれるかな？
うちのシステムは大体それで大丈夫だからね。
574 ：login:Penguin：2020/02/01(土) 12:59:32.03 ID:Ps7WDj2g.net: 今度はDockerじゃなくてgit使えば良いおじさん登場か
それで困ってないなら別に良いんじゃない？
575 ：login:Penguin：2020/02/01(土) 13:07:12 ID:rnZpf00g.net: >>574
だから「ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？」って聞いてるじゃん。
君の反論は、デプロイが複雑な場合においては、有効なこともありうる、ってことでオッケー？
それは分かったよ。
ただ、>>556にあるようにDocker自身はコンテナシステムとしてはイマイチだと思う。理由は557と同じね。
少なくとも変なホスト単位のブリッジはやめにしてPOD単位とかService単位で内部ネットワークにしないと
インスタンスが全面に出てきちゃ、導入する意味が無い。ストレージなんかも必要な部分を予めマッピングして
永続化しないと駄目とか、制限が多いし。こんな事いっても君には分からんだろうけど。
576 ：login:Penguin：2020/02/01(土) 13:18:31 ID:Ps7WDj2g.net: じゃあ使わなきゃいいんじゃね？
577 ：login:Penguin：2020/02/01(土) 13:25:27 ID:rnZpf00g.net: マジ質問読めよ文網ｗ
日本語通じないなんてDocker使う以前の話だよｗ
578 ：login:Penguin：2020/02/01(土) 13:30:03 ID:Ps7WDj2g.net: Docker使わなかったらOSアップデートは要らないとでも？
普通に要るでしょ
セキュリティ考慮しないから要らないって話？
579 ：login:Penguin：2020/02/01(土) 13:45:31.37 ID:rnZpf00g.net: >>578
ECSの話してるんじゃないの？
ECSは「インスタンスの上」でコンテナを動かすのだから当然Dockerでも
OSアップグレードは必要で、そういった話をするなら、インスタンスOSと
コンテナ上のOSの両方のセキュリティを考慮しなければならない。
580 ：login:Penguin：2020/02/01(土) 15:00:13 ID:A9loRdi2.net: ECSとか関係なく
ASG利用の方が信頼性が高い

ECSはASG無しで使えるように設計されてるのか良く分からない
なんか前の登録内容が残ってたり
ECSエージェントのデータを消さないとインスタンスタイプを変更できなかったりした

通常のEC2
・ルートボリュームの内容は再起動に引き継がれる。システムログの内容やSSHして手動設定した内容はインスタンスを削除しない限り残る。
・AWS障害時に自動復旧させるのは可能だが、必ず成功するとは限らない。
・AWSと関係ないOS内部の問題はEC2 Rescueで復旧を自動化できるかもしれないが絶対ではない。

ASG
・ルートボリュームは毎回新しく作られる
・データの保存が必要なワークロードの場合、起動後にスクリプトで別のEBSをアタッチする、S3に保存されたバックアップから復元するなどの方法が必要
・ヘルスチェックをEC2にした場合、システムとインスタンスの2つのチェックのどちらかに失敗するとインスタンスは破棄されて再作成される
・ヘルスチェックをELBにした場合、ELBからのリクエストに暫く応答しなかったら破棄される

いずれの場合も、自前のヘルスチェックシステムがあるなら
それを代わりに使う事は可能だが
そんな物はうちにはない
581 ：login:Penguin：2020/02/01(土) 15:10:35 ID:lVg3qEIO.net: キャパシティプロバイダーでEC2のタスク数とインスタンス数を連動させる場合はASGが必須

キャパシティプロバイダーの登場以前はタスク数と連動させるのは諦めて
EC2の台数もタスク数も固定するか
それぞれバラバラに設定して
高負荷時に両方とも作動するよう神に祈る他なかった

キャパシティプロバイダーが要らない場合でも
ASGにしておけばコケても復旧するという安心感はある
インスタンスを終了すれば必ず同じ設定で起動するからだ

それらが要らないならASG無しでも良いんじゃね？
同じEC2インスタンスだと
インスタンスサイズ変更時に
ECSエージェントが登録失敗する問題は何か解決策があるだろう
582 ：login:Penguin：2020/02/01(土) 15:36:39.64 ID:uZkIbDS6.net: ECSについて言えば、3つのネットワークモードが利用可能

bridge
ポートマッピングを設定した場合、
コンテナにランダムなポートが割り当てられ、外部からアクセス可能になる
同じホスト名で外部からアクセス出来るようにしたいなら、ELBやRoute53を併用する

毎回異なるポート番号になるので、デプロイ時、1つのEC2インスタンスに
同じタスクの新旧バージョンを一時的に同時実行する事が出来る

host
ホストOSと同じネットワークに配置する
ポート番号が衝突するので、
デプロイ時に、同じタスクの新旧バージョンを同じEC2インスタンスで同時実行は不可

awsvpc
ホストOSとは異なるENIにタスクを配置する
異なるENIなので、同じEC2インスタンスでも同じポート番号を利用可能な上に
理論上は最高のネットワーク性能を持つモード
ただし、小さめのインスタンスタイプでは
利用できるENIの数が少ないので
配置出来るawsvpcネットワークモードのタスクは少なくなる
583 ：login:Penguin：2020/02/01(土) 18:53:25 ID:ZdsodL/0.net: 俺はGCPメインだからAWSの話はよくわからんなｗ

AGS？ GKEのオートスケーリング機能みたいなもんか？
584 ：login:Penguin：2020/02/01(土) 19:59:11.09 ID:wE2puLwI.net: ASGは多分似たような機能がどのパブリッククラウドにもあるだろう

k8sをAWSで使う場合も
ワーカーノードはASG管理下で、
ルートボリュームはノードを終了する時に捨てるよね
サーバーはいつでも替えの効く家畜だ

k8sでデータベースなどの
ステートフルなワークロードを扱う場合は、
ノードにルートボリュームとは別に
EBSボリュームをアタッチすれば良い

>>583
そもそもASGはオートスケーリンググループの略だから
585 ：login:Penguin：2020/02/02(日) 01:40:45.56 ID:9x081f8g.net: Kubernetes 航海1日目
https://mao.5ch.net/test/read.cgi/linux/1553389453/
586 ：login:Penguin：2020/02/02(日) 08:39:22.80 ID:cuMP7GqL.net: 何？よう知らんけどEKSでもインスタンスは見えてるの？
インスタンス（VM）を管理してその上で動くコンテナも管理しろとか
コンテナの意味なくね？
587 ：login:Penguin：2020/02/02(日) 08:52:22.96 ID:vTMq3yW0.net: だからコンテナはアプリをデプロイしやすくするためのものだって言ってんだろ
588 ：login:Penguin：2020/02/02(日) 09:08:51.99 ID:cuMP7GqL.net: じゃあ、今ここでDocker関連の話題を書き込んでいる連中はもれなく
デプロイに問題があってDocker使ってるという認識なのｗｗ？
デプロイをコンテナ以外で解決するくらいならサービスメッシュだ
オペレータだhelmチャートだと学習したほうが効率が上がると判断しているのｗ？
589 ：login:Penguin：2020/02/02(日) 09:42:45 ID:TWOzawm+.net: >>588
は開発どうしてんの？

それぞれバラバラに環境作って開発？

開発、QA環境へのデプロイとテスト
本番環境へのデプロイまで一貫した環境で行えるのがコンテナ技術のメインの魅力だろう

Kubernetesは複雑すぎる気はするが
他に選択肢があまりない
590 ：login:Penguin：2020/02/02(日) 09:54:07.31 ID:TWOzawm+.net: 以前、開発も本番も同じ環境においてるという
狂気の環境で開発した事がある
ローカル開発環境はそもそも存在せず

理由は環境の複製が面倒だから
AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた

サーバーに直接Apacheをインストールしており、
基本的にphpをアップグレードする時や
phpの拡張機能を入れるときは
一か八かの賭けに出る必要があった

AMIを複製して他環境で試す？
そんなのやるぐらいならもうDocker使えよ・・・ってなる
それが一番色んな環境に運ぶの楽じゃん
591 ：login:Penguin：2020/02/02(日) 10:02:35 ID:vLvuWMc2.net: >>586
昔ながらの方法だったらVMインスタンスもアプリのデプロイも管理しなくて良いとでも言ってるのか？
文句あるなら代替案出せや

スペックに応じたインスタンスが必要なのは
昔ながらの方法でも一緒だろ
592 ：login:Penguin：2020/02/02(日) 10:31:49 ID:cuMP7GqL.net: >>591
代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が
10台20台程度なら入れない方が良いと思う。いつの日か>>557が書いたように
完全にコンテナだけ見ていればOKになるなら入れても良い。

例えば10コアのCPUを10台用意して、30個をフロントWEBに、20個をバックエンドに、
30個を同期サーバ、10個をその他、残りはautoscaling用、1CPU=1コンテナとか
このレベルで意思決定が出来て、そのとおり動くならマイクロサービスは素晴らしい
といえるけど、現状そうなってないんだろ？コンテナが物理サーバーに対して透過的
見えるレベルに到達してないつーか。

いつかそうなるんだろうけどね。
今は面倒なだけという気がする。
593 ：login:Penguin：2020/02/02(日) 11:04:46.84 ID:mAYLnTD8.net: >>592
それってデメリットか？
算数が出来れば計算出来るだろ
小規模環境なら台数固定で良いし

OSや、ログ、メトリクス用ポッドの分だけ余裕をもたせて空けておけば良い
それぐらい計算できるだろ？

もしかしてワーカーノードは全部同じグループとか思ってる？
データベースはこのラベルが付いてるノードだけに配置とか、出来るだろ
負荷がデータベースに集中しがちなら、データベースだけ大きなノードのグループで構成するとか

1つのグループに
ごった煮にして配置したりすれば
非常にややこしくなるから
誰もやらない
594 ：login:Penguin：2020/02/02(日) 11:29:49.61 ID:cuMP7GqL.net: >>593
そういった諸々に対して>>546 >>550-555のような問題がありますよ、という話じゃなかったの？

まあ導入前段階で比較したい、という人と既に導入しちゃった人じゃ観点が合わんのはしょうがないけど。
前の人は既存部分との違いを知ることが主な観点になるけど、既に入れちゃった人はその結果起きた問題を
解決することが観点になるからねｗ
595 ：login:Penguin：2020/02/02(日) 11:43:38.54 ID:l4msUzoZ.net: なんか話が噛み合わないと思った
ノードを常に余らせている大規模環境じゃないと使えないとか
>>550

あらゆる種類のワークロードを
1つのノードにごった煮だと勘違いしていたなら納得
596 ：login:Penguin：2020/02/02(日) 11:43:41.70 ID:cuMP7GqL.net: >>590
これも、そもそもDocker以前の環境すらまともに運用できなかった人と
Dockerを比べてもなぁ？という話で。もしその狂気の環境の人がDocker使って
k8s入れたとしたら、余計酷くなるだけ（使いこなせるわけが無い）

> AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた

こういう言い方もずっと前からあるけど、実際コンテナとしても「家畜のように」は使えんだろ。
本番で運用するときは当たり前だけど一見ごみの様にしか見えないものでもトラブル解決に
役立ったりするからね。/var/log/httpdだけを永続化しときゃ済むって話じゃない。
1ヵ月後に顧客からトラブルの相談があって、既に再デプロイして非永続領域は消えちゃいました、
ですむなら良いけど。
じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。
597 ：login:Penguin：2020/02/02(日) 12:01:17 ID:TWOzawm+.net: >>596
>じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。

本当に全くDocker使ったことないのに批判してるんだなw
説明しよう

ログは標準出力か標準エラー出力に吐くから永続化はしない
必要ならロギングドライバーを設定するなどして
別サービスに転送する
AWS+ECSならCloudWatchに転送が一番楽

k8sは今のところロギングドライバーの設定はできないので、
コンテナのログを集めるDaemonSetがそれぞれのノードにデプロイするのが一般的
これで全ノードのログを残せる

永続化するのは再起動しても絶対残っていなければならない
データベースのデータなどだけ
どこを永続化するかで悩んだことなんてない
598 ：login:Penguin：2020/02/02(日) 12:12:02 ID:cuMP7GqL.net: >>597
そういやそういう事やってたなとは思うけど、君が説明しているログ収集云々は
汎用的なDockerの話じゃ無くてベンダーが用意している部分ね。

>AWS+ECSならCloudWatchに転送が一番楽

ん？結局こういうことしたらベンダーロックインって事じゃないの？

> どこを永続化するかで悩んだことなんてない

そうなの？
しかしそれはDBとWEBだけの単純サービスだからじゃないの？
ウチのはある領域に一時的なファイルを作って、S3とかにアップするけどそれが
出来てないよ、とかは普通に来るからね。
599 ：login:Penguin：2020/02/02(日) 12:25:14.51 ID:LuowLFof.net: ベンダーロックインw
あのさ、ECSでコンテナからCloudWatchに出力するのなんて数クリックでできるわけ。
人的なコストなんかほぼゼロ。
ベンダーロックインっていうのはこれまでの投資が無駄になるから他のベンダーへ移れない状態であって、
そもそも投資がゼロなら何の問題もないの。言ってる意味わかる？
600 ：login:Penguin：2020/02/02(日) 12:29:21.34 ID:TWOzawm+.net: >>598
ECS時は最も手軽な選択肢はCloudWatchってだけ
他にも選択肢はあるが
とりあえずAWSで動けば良いなら一番手軽

手間や金がかかっても
とにかくベンダーロックインは嫌だって言うなら
k8sとELKスタックとかになるんでは

ファイルアップロードにS3使えてない場合は
・2台以上でWebサーバーの構成をするのを諦める　
・多少遅くても良いならAmazon EFSに置く
どちらもやらずに解決する銀の弾丸はない
601 ：login:Penguin：2020/02/02(日) 12:35:08 ID:cuMP7GqL.net: >>599
なんつーかそれを聞いてもやっぱり、10台程度のサービスでEKS、ECS面倒臭いという
のが結論やね。100台なら話は全く違うけど。じゃあ10台～100台の間のどのへんが
ボーダーなのかって点には関心あるけど。
どこが汎用のDockerの話でどこがベンダーに依存するのかとか、面倒くさすぎ。
質問を568に戻そうぜ。
「ある1つのインスタンス内で、1プロセスでCPUと同数のスレッドと立ち上げる事と、
　CPUと同数のコンテナを立ち上げること」は何が違うの？
602 ：login:Penguin：2020/02/02(日) 12:38:55 ID:TWOzawm+.net: そもそも規模小さかったらリソースの割当に悩む事ないから
その批判がそもそも的外れ
603 ：login:Penguin：2020/02/02(日) 12:40:49 ID:LuowLFof.net: >>601
その2つを比べるのはおかしい
1コンテナ内で複数スレッド立ち上げてもいいし、goなどのマルチスレッド前提の言語ならむしろその方が一般的。
604 ：login:Penguin：2020/02/02(日) 12:41:16 ID:cuMP7GqL.net: >とにかくベンダーロックインは嫌だって言うなら....
>ファイルアップロードにS3使えてない場合は...

こういう所とかも全部「既存システムでは存在しない問題点に対して解決方法を提示している」様に思えてならん。
他の人はそうは思わんのかな？
605 ：login:Penguin：2020/02/02(日) 12:46:24.01 ID:LuowLFof.net: >>604
全く意味がわからないな
ログ収集もS3へのアップロードの失敗も既存システムで存在するだろう
606 ：login:Penguin：2020/02/02(日) 12:59:25.79 ID:cuMP7GqL.net: >>605
VMは再起動しても永続化してるんだから問題調査は可能でしょ。
607 ：login:Penguin：2020/02/02(日) 13:04:25 ID:TWOzawm+.net: S3とか使ってないレガシーシステムでも
ECS使うのは可能

可用性が重要じゃない社内用アプリで
インスタンス1台だけのECSクラスターで
データは全てEBSに書いてる物ならある
ログはDocker経由でCloudWatch Logsに出すようにしてるが

時々OSのAMIとか
ECSエージェントを更新すれば
実行環境は最新の状態に保たれる
ログやメトリクスはマネジメントコンソールから見られるし、
デプロイするだけならSSHすら要らないし楽
使わない理由がない

アプリ部分はAWSとか使ってないので、
移そうと思えば他クラウドにも移せる
今の所やる予定ないし今後も無いと思うが
608 ：login:Penguin：2020/02/02(日) 13:05:37 ID:LuowLFof.net: >>606
オートスケーリング使うなら勝手にterminateされて全部消えるよ
大した規模じゃないからオートスケーリングいらないってんなら、君にはコンテナなんて要らないから帰ってね、としか
609 ：login:Penguin：2020/02/02(日) 13:07:43 ID:cuMP7GqL.net: >>608
オートスケーリングはそういう用途じゃないな。
繁忙期のサーバー落ち＞障害調査
の場合にのみ使用するとしか言えない。
分からないなら答えないでねとしか。
610 ：login:Penguin：2020/02/02(日) 13:17:05 ID:TWOzawm+.net: だからログはCloudWatch Logsに送ればいいって話だろ？

コンテナ毎のCPU使用率やメモリー使用量はメトリクスはECSエージェントがCloudWatchに送ってくれる
611 ：login:Penguin：2020/02/02(日) 13:17:41 ID:LuowLFof.net: >>609
そもそもログ収集してないのに問題のインスタンスの特定とかどうすんの？
台数が少けりゃスナップショット撮ってれば努力と根性でなんとかなるかもしれないけど、
うちの場合はその作業が一度発生したら自前でログ収集の仕組みを構築するコストを余裕で上回る工数だねえ
612 ：login:Penguin：2020/02/02(日) 13:20:19 ID:cuMP7GqL.net: >>607
>ログやメトリクスはマネジメントコンソールから見られるし、

これもね、じゃあ障害解析のために開発者全員がマネジメントコンソール
見れて良いのかとか、微妙で面倒くさい問題が出そうな気がするんですよ･･･。
613 ：login:Penguin：2020/02/02(日) 13:26:35.87 ID:cuMP7GqL.net: >>611
自分が携わっている範囲内で言えば、インスタンスが特定できずに問題が解決
しなかったなんてことは無いな。コストがかかりすぎた、という事も無い。
ド素人じゃないんだし、それ位分かるよな？としか･･･。
614 ：login:Penguin：2020/02/02(日) 13:27:41.24 ID:TWOzawm+.net: >>612
ログを取るためだけにSSHするのは良いのかよw

AWSの組織機能で細かくアカウントをアプリ毎に分ける、
IAMロールを最小の権限のみにするなどした方がよほどセキュアだ

Cloudwatch Logsは
ローカルにログをダウンロードせずに
簡単な検索や分析も出来る
これもセキュアだろう
615 ：login:Penguin：2020/02/02(日) 13:59:10 ID:bYwPQj4X.net: >>613
それインスタンスが数百台以上あっても同じこと言える？
結局何が言いたいのか知らないけど、何が手でSSHして回れる程度の台数でコンテナなんか要らん、と言いたいならまあその通りだと思うよ
616 ：login:Penguin：2020/02/02(日) 14:05:41 ID:cuMP7GqL.net: >>615
だから結論は>>601だと言っているでしょ。
以後のやり取りのすべてを見てもやはり601やね。
10台以下で運用するのは、まあ、趣味の世界やな。。
悪くは無いけど運用上実利がある訳じゃないよと。
まあ興味があるならやっても良いよ、あるいはもっと大きな
サービス運用業者に転職を視野にいれてしれっとやってみるとか、
そんな感じと思ったね。
617 ：login:Penguin：2020/02/02(日) 14:25:00 ID:KVZqynku.net: 結局何が言いたいのかサッパリ分からんやつだったな
小規模だったらそもそも台数の調整とか要らないだろって話は無視か
618 ：login:Penguin：2020/02/02(日) 14:34:13 ID:cuMP7GqL.net: >>617
君の言っている事こそ意味不明ｗ。
小規模で台数の調整が要らないらならEKSもECSも要らないっしょ。
ちなみに小規模であることと台数の調整が不要であることはイコールではない。
小規模でも繁忙期に台数増やしたいとかは当然ある。
619 ：login:Penguin：2020/02/02(日) 14:43:53 ID:TWOzawm+.net: サーバーを家畜化した方が運用が楽で信頼性も高いのは
1台でも100台でも変わらないと思う
総利益が大きいのはそりゃ100台だろうが

そもそもサーバーの家畜化もできてなかったら
どうやって水平スケールするのか

Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが
620 ：login:Penguin：2020/02/02(日) 14:50:00 ID:TWOzawm+.net: Dockerなしでも家畜化出来てたら
それぞれのサーバーにSSHしてログ取ったりなんていらんはずだけど
まさか手作業で環境を複製してASGもどきをやってるのか？
超無駄じゃね？
ASGでやれよ
621 ：login:Penguin：2020/02/02(日) 15:15:07 ID:cuMP7GqL.net: >>619
>信頼性も高いのは

信頼性が高いといっているのは何を根拠に言っているのか知らんが、
インスタンスの上にDockerエンジン乗せてその上にサービスを展開している鯖と
インスタンスの上に直接サービス(httpdとか）のせてサービス展開している鯖はどっちが信頼性高いのって話だが？
どっちなのｗ？前者は単純に数が増えているように見えるが？

>1台でも100台でも変わらないと思う

本当にそう思うの？既に「入れてしまった人」は当然操作にも慣れてるだろうし、そもそもコンテナ外して
運用するのは2度手間になるから、1台でもコンテナで、になるんだろうけど本当に1台しか運用していない
会社に自信を持ってそれ、提案できる？1台でもEKS入れましょう、と。

>どうやって水平スケールするのか

つまり君はコンテナ以外じゃやったことが無いって話なんだろ？

>Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが

俺が直接運用しているサービスはそうやね。例え鯖1台でも「趣味として」EKS化しても全然悪くない
が、世の中にはそうでない人もいるわけよ。500円位の共用WEB鯖＋DBとか。
あるいは2万円の1台2台の専用鯖とか。
そういう人に本当にお勧めできるの？
アマゾンに移行して、コンテナ化してEKSしましょう、とか。
本当に？君は本当にそう思うの？

>>620
この書込みは全く意味不明。
宇宙語話してるの？そもそも「家畜化」ってIT用語なのｗ？
君以外の誰にも通用しない気がするがｗｗ
622 ：login:Penguin：2020/02/02(日) 15:28:42.63 ID:TWOzawm+.net: 1コンテナぐらいしか動いてないならEKSじゃなくてECSで良いと思うし既にやってる
楽だしお金がそんなにかかんない

CloudWatch Logsは無料分を超えると課金があるが、小規模なので無料分で余裕
これで破産する方が難しい

家畜とペットの例えはさっきしてたじゃん

AWSはEC2インスタンスはASGに入れて使い捨てするか、
EC2の上に乗っけたソフトウェアでレプリケーションを行って、1台は死んでも大丈夫にするのがベストプラクティス
それを行ってないインスタンスで動いてるサービスは止まっても知らねってスタイル
AWSではサーバーは家畜のように扱うべき、と言うのはここから来てる

従来のようにSSHして
手でOSにソフトウェアをインストール・アップデートして、
手でデプロイして、手でログ取得して
ってのはサーバーをペットのように可愛がりすぎ
そんな事やってたら家畜のように扱えない
623 ：login:Penguin：2020/02/02(日) 15:41:41.27 ID:cuMP7GqL.net: >>622
悪いね、おれエスパーじゃないから、その例えで
「手でOSにソフトウェアをインストール・アップデートして、手でデプロイして、
　手でログ取得してってのはサーバーをペットのように可愛がる」
なんてのは全く忖度できんかったわｗｗｗ

兎に角君の言っている事は、どっかしらにおかしな抜けがあるから、あさって
の方向の話にしか聞こえないｗｗ
じゃあなｗ
624 ：login:Penguin：2020/02/02(日) 15:44:44.32 ID:031eKof+.net: http://www.no1497.com/?p=598
このサイトの手順丸パクりしてguiのLinux環境整えようとしたんですが
IPアドレス入力しconnect押すところで繋がらなくなります…
一応ifconfigとdocker内でのhostname -iで出てきたアドレス両方と、
ポート二つの4パターンの組み合わせ全部打ったんですが失敗しました。
これ以外のアドレスとかでしょうか？もし思い当たる方がいたら教えてください。
625 ：login:Penguin：2020/02/02(日) 15:46:37.36 ID:TWOzawm+.net: >信頼性が高いといっているのは何を根拠に言っているのか知らんが、
>インスタンスの上にDockerエンジン乗せてその上にサービスを展開している鯖と
>インスタンスの上に直接サービス(httpdとか）のせてサービス展開している鯖はどっちが信頼性高いのって話だが？
>どっちなのｗ？前者は単純に数が増えているように見えるが？

Dockerのオーバーヘッドなど
元々あってないようなものとマジレス

ASGで動くという事はインスタンスを使い捨て出来てるってこと
AWS側の不具合でインスタンスが死んだり、
仮にSSHして変な設定を間違ってしてしまっても
終了するだけで自動的にインスタンスが再作成され
元のAMIから立ち上がって同じ設定がされて、
Dockerイメージも勝手にダウンロードされてまた動き出すので
元に戻る
よって信頼性が高くなる

動作が遅いけど、死んでるかどうか微妙なインスタンスの破棄は流石に無理だが

既存案件でいろいろ制約があるとかならまだしも
そうでなければECSで良くね？と思う
626 ：login:Penguin：2020/02/02(日) 16:26:20.24 ID:rlDokdVB.net: 久々にPHPの環境構築をしようと思ったんだが今はXAMPP使わずDocker使うのが主流らしいな
試してみるか
627 ：login:Penguin：2020/02/02(日) 17:56:03 ID:vTMq3yW0.net: 俺がいない間に随分と進んでるなｗ

>>592
> 代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が

またDocker（コンテナ）とKubernetes（クラスタ）を
ごっちゃにしてるアホがいるのか

サービスでデプロイした経験ないのか？
Wordpressぐらいしたことやるやろ？できるか？何が必要か想像つくか？
PHPだぞ。apache使うとするよな？そうするとmod_phpがいるぞ。
ライブラリ使ってたらPHPモジュールも入れないとだめだぞ
一発勝負で正しく作れるか？んん？

そしたら次は俺が作った動画アップロードとAI機能が充実した独自のスーパーブログだ。
わけって言語は複数使ってる。どうや正しくデプロイできるか？
これ以上の情報は何も教えてやらんぞ。必要な言語、ライブラリ、自分で判断しろよ
一発勝負で正しく作れるか？んん？

コンテナだったら簡単。一発勝負で作れる。
ほらな、デプロイ問題が解決した。
628 ：login:Penguin：2020/02/02(日) 18:37:50.21 ID:cuMP7GqL.net: >>627
>サービスでデプロイした経験ないのか？

俺が言う台詞だそれはｗｗｗ
コンテナ以外でデプロイした経験無いのか？んん？
apache使うとするな？本当にmod_phpからやったのか？？
んん？？アホかお前は！
629 ：login:Penguin：2020/02/02(日) 18:58:43.16 ID:vTMq3yW0.net: >>628
お前何も言い返してないやんｗ
俺が言った言葉を復唱しただけやんｗ
630 ：login:Penguin：2020/02/02(日) 19:02:44.43 ID:cuMP7GqL.net: >>629
この書き込みから察するにデプロイメントって言葉の意味すら分かってないだろ？
どうしようもないｗｗあまーーーーりの馬鹿っぷりに呆れて物が言えない。
宇宙人と話すことは出来んな。
マジでスゲー呆然としたよまあ、良いから自分の胸に手をあてて、
Docker以外でデプロイしたことあったかな？と自問してみればｗｗ
631 ：login:Penguin：2020/02/02(日) 19:04:08.66 ID:vTMq3yW0.net: そこでデプロイしたことあるけど？って答えたら
どうレスするんだろうｗ

はい、言い返してみな。
632 ：login:Penguin：2020/02/02(日) 19:07:47.33 ID:cuMP7GqL.net: >>631
それなら絶対に627のような書き込みはしない。
633 ：login:Penguin：2020/02/02(日) 19:16:11.74 ID:vTMq3yW0.net: >>632
理由が何も書いてないので、説得力ゼロ
やり直せ
634 ：login:Penguin：2020/02/02(日) 19:26:58.84 ID:cuMP7GqL.net: >>633
まあ、分かったよ恥ずかしい奴らｗ
なんかもう、ね･･･Docker村の事情しか分かってなさそうだから
全てがおかしい。ASGの理解もおかしいし「サービス」って言葉の理解もおかしい。
いっとくが俺が>>592でかいた「サービス」ってのはk8s村でいう"サービス"の事ではなく、
世間一般のIT用号で言う「サービス」だからな。592の書き込みにコンテナ技術の一実装
でしかないDockerとかK8sを念頭において書いていないぞ。
･･･それは、理解できるよね？オッケー？
635 ：login:Penguin：2020/02/02(日) 19:35:57 ID:iUJbnHUw.net: はい理解してます。本題をどうぞ
636 ：login:Penguin：2020/02/02(日) 19:37:00 ID:cuMP7GqL.net: >>635
というわけで>>627の書き込みは意味不明って事で
オッケー？本題はこれね。
637 ：login:Penguin：2020/02/02(日) 19:37:55 ID:iUJbnHUw.net: 意味不明の理由が書いてない。やり直し。
638 ：login:Penguin：2020/02/02(日) 19:39:32 ID:cuMP7GqL.net: >>637
日本語を書くけど日本語は理解できない
宇宙人とは会話は出来ませーーーーんｗ
君馬鹿すぎて話にならんよｗｗ
じゃ、そういう事で！
639 ：login:Penguin：2020/02/02(日) 19:49:44 ID:iUJbnHUw.net: はい、逃げた
640 ：login:Penguin：2020/02/02(日) 20:02:29 ID:cuMP7GqL.net: >>639
じゃあ君に聞くけどさ、>>592でIT一般用語で言う「サービスを構成するサーバーが･･･」という話を振ったら
Dockerのクラスタで言う「サービスのデプロイ」の話を返した奴がいるとする、スーパーブログがどうのこうのと。
君はそれを聞いて、意味不明とは受け取らないのｗｗ？
俺はそれを聞いて、一般用語で言う「デプロイ」の話だと受け取るわけだ。
前の文脈が一般用語だから。するとおかしな事なるよな？だから変な話になっている。
で君はその流れを理解できない訳だ。ｗ

はい、逃げたってｗ
「はい理解してます。本題をどうぞ」ってお前、何にも理解してない東南アジアの通訳みたいなこと言うなよｗ
641 ：login:Penguin：2020/02/02(日) 20:05:23 ID:iUJbnHUw.net: サービスをデプロイした経験があれば、

wordpress？それはなん言語で動くんですか？php？
え？アプリケーションサーバーが別に必要？
プラグイン使ってるから、追加でPHPモジュールが必要？

とかいう時代から、

wordpressその他で構成したDockerイメージがあるので
そのコンテナを動かすだけだよ。
必要なものは全てDockerイメージに含まれてる。

という時代になって

デプロイが簡単になったってのがわかるはずだけどな。
まあどうせ一人で全部やってるんでしょ？

だから何が必要かは全部俺が知ってる。
Dockerイメージを作る手間もデプロイする手間も変わらない。
どこでやるかが変わっただけで、どうせやるのは全部俺
みたいに思ってるんだろうな
642 ：login:Penguin：2020/02/02(日) 20:06:20 ID:iUJbnHUw.net: >>640
> Dockerのクラスタで言う「サービスのデプロイ」の話を返した奴がいるとする、

そんな奴はどこにもいない。
おまえの思い込み
643 ：login:Penguin：2020/02/02(日) 20:07:30 ID:iUJbnHUw.net: たとえクラスタなくて、起動するマシンが1台であっても
コンテナがあればデプロイが簡単になるわけだよ
644 ：login:Penguin：2020/02/02(日) 20:13:35 ID:cuMP7GqL.net: >>642
まあ良いよ俺が戻ってきたのは>>627の書き込みが意味不明に思えたからであって
宇宙人の君と頓珍漢な会話したい訳じゃない。
645 ：login:Penguin：2020/02/02(日) 20:16:11 ID:iUJbnHUw.net: 経験不足の人が理解できず意味不明に思えた
ただそれだけの話です。
646 ：login:Penguin：2020/02/02(日) 20:28:04.22 ID:cuMP7GqL.net: もし世間一般のデプロイの話をして返したとして>>627というのなら、それならやはり理解不足
そもそもphpのdeployerつかってもmod_phpのインストールなんかしないし。
・・・と、627と関係ない宇宙人の書込に反応してみる。
スーパーブログがどうのこうのなんてどうでも良い話しだしｗ。
647 ：login:Penguin：2020/02/02(日) 20:39:48.25 ID:Q4JuNZ7V.net: ECSはELBと組み合わせてローリングデプロイが行える
新しいバージョンのECSタスクは
ELBに新しいターゲットとして登録され、一時的に両方が存在する状態になる
新しいバージョンのECSタスクのターゲットが正常と判定されると、
古いバージョンのECSタスクのターゲットへはリクエストが行われなくなり、タスクは終了する
新しいバージョンのタスクに明らかな異常があり、それに気づかないままデプロイ完了するミスを防げる

ECSはCodeDeployと連携したブルー・グリーンデプロイにも対応している

https://dev.classmethod.jp/cloud/aws/ecs-codedeploy-blue-green-deployment/

テスト用サイトで確認してから新旧バージョンを入れ替え出来るので、
より安全
648 ：login:Penguin：2020/02/02(日) 20:40:02.14 ID:iUJbnHUw.net: > そもそもphpのdeployerつかってもmod_phpのインストールなんかしないし。

なんで？いかなる場合もそうだって言える理由は何？

mod_phpを使わない事例 "一例" を言えって言ってるんじゃないよ。
mod_phpが使わない事例 "しか存在しない" という理由を聞いてる
649 ：login:Penguin：2020/02/02(日) 20:41:44.17 ID:iUJbnHUw.net: phpのdeployerっていうのも意味不明だし
どっかのサービスにベンダーロックインでもされてるの？ｗ
自前のサーバーでデプロイした経験ありますか？
650 ：login:Penguin：2020/02/02(日) 21:05:56 ID:5Cwo7VNY.net: 熱くなりすぎて引くわ
651 ：login:Penguin：2020/02/02(日) 21:47:49 ID:cuMP7GqL.net: ここまでか？ここまで分からんとはね・・・・・･。

DeployerでLaravelをデプロイする
https://qiita.com/sandabu/items/c09eb23137a9d5269f10

Capistranoで簡単デプロイ
https://qiita.com/Esfahan/items/1258d37eb6a85fa35b02

DeployerによるPHPデプロイ
https://blog.excite.co.jp/exdev/27205935/

Java アプリケーションのデプロイ
https://ecl.ntt.com/documents/tutorials/rsts/Paas/deploy/java.html

Force.com開発でGitを使ったデプロイ
https://www.terrasky.co.jp/blog/2016/161028_001862.php

世間一般で多くの場合、「デプロイする」とは
配備指示書にしたがってプログラムを文字通り「配備」（多くの場合はコピー）する事であり、
環境のセットアップは含まない。Docker村ではその特性から含んでいる、というだけ。
652 ：login:Penguin：2020/02/02(日) 21:48:53 ID:iUJbnHUw.net: ↑
このようないろんな「デプロイ」が
Dockerの1つのコマンドでできるようになるわけです。
653 ：login:Penguin：2020/02/02(日) 22:07:22 ID:cuMP7GqL.net: >>652
以上、馬鹿で無知な>>iUJbnHUwに教えてあげました。
マジ感謝しろよｗ。
654 ：login:Penguin：2020/02/03(月) 02:19:55.62 ID:bpau2PQS.net: 捨て台詞ｗｗｗ
655 ：login:Penguin：2020/02/03(月) 02:55:57.12 ID:NijMCh9X.net: デプロイに関しては確かにスレッドの最初の頃から理解がおかしい人がいたね。
656 ：login:Penguin：2020/02/03(月) 03:10:09.08 ID:PgExQ+7W.net: > 世間一般で多くの場合、「デプロイする」とは
> 配備指示書にしたがってプログラムを文字通り「配備」（多くの場合はコピー）する事であり、
> 環境のセットアップは含まない。Docker村ではその特性から含んでいる、というだけ。

↑ほんとだｗ間違ってるｗプログラムをコピーすることだって
qiitaの記事持ってきて環境のセットアップが含まないとかｗ

「本当の」世間一般の定義でも貼り付けときますか？

http://e-words.jp/w/%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4.html

ソフトウェアの分野で、開発したソフトウェアを利用できるように実際の運用環境に
展開することをデプロイということがある。インストール（install）に近い意味だが、
サーバコンピュータ上で運用され外部からネットワークを通じて利用されるソフトウェアや、
他のソフトウェアから参照されるコンポーネントなどを、利用可能な状態にする、
アクセス可能にする、といったニュアンスがある。

https://kotobank.jp/word/deploy-1689419
アプリケーションソフトを、利用者の実際の運用環境で利用できるように準備すること。
◇「インストール」がコンピューター上で実行可能なファイルを準備することであるのに対して、
「デプロイ」は実行時に必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備すること。「デプロイメント」ともいう。
657 ：login:Penguin：2020/02/03(月) 03:16:46.44 ID:PgExQ+7W.net: 大変なデプロイが簡単になるって言う意味がわからんかったのかな？
デプロイ？そんなのファイルコピーするだけじゃん
git使っていれば、git pullするだけ！とか思ってそう

> git使えば良いおじさん登場か
これってそういう意味だったのか
658 ：login:Penguin：2020/02/03(月) 03:32:09.96 ID:lRDyNjgE.net: >>657
分かったから涙拭けよｗ
「「本当の」世間一般の定義」を張らなきゃ分からないんだろ？
つまり君自身は「デプロイ作業」を経験したことは無いわけだ。
だから、現場の俺とは全然話が合わないｗ。javaでwarファイルをデプロイした、
とか開発現場でphpでもpythonでも良いけど、本番機にデプロイした、
といった場合、常識的に、mod_phpをインストールするなんてことは無い。
659 ：login:Penguin：2020/02/03(月) 03:34:25.84 ID:4HFKT3uL.net: >phpのdeployerっていうのも意味不明だし

phpのdeployerでググったら大量に出ますがな…。
660 ：login:Penguin：2020/02/03(月) 03:34:33.42 ID:PgExQ+7W.net: > 「「本当の」世間一般の定義」を張らなきゃ分からないんだろ？

俺がわからないから「「本当の」世間一般の定義」を貼ったんじゃなくて
間違ってるやつがいるから貼ったんだけど？

ともかく「「本当の」世間一般の定義」は
必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備する
ということに異論はないね
661 ：login:Penguin：2020/02/03(月) 03:36:18 ID:lRDyNjgE.net: >>660
わかったよｗ
君の経験の浅さがめっちゃ出てるよ。
マジで俺にしてみれば、この話題をこんなに教えてあげても全然
理解しないとかって、馬鹿じゃないの？としか思わないんだが。
662 ：login:Penguin：2020/02/03(月) 03:36:31 ID:PgExQ+7W.net: >>686
デプロイは必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備することなので
mod_phpをインストールすることも含まれる

お前がやってるのはデプロイじゃなくて
デプロイ済みの環境のソフトウェアを
アップデートしてるだけ

つまりデプロイからやったこと無いんやろ？
663 ：login:Penguin：2020/02/03(月) 03:39:06 ID:lRDyNjgE.net: >>662
もう良いよ、相変わらず宇宙人だなｗ
君は俺とは違う惑星でデプロイ作業してたんだろうなｗ
もう会話してもしょうがない。じゃーなｗ
664 ：login:Penguin：2020/02/03(月) 04:37:06 ID:PgExQ+7W.net: お前がなんと言おうと

https://kotobank.jp/word/deploy-1689419
アプリケーションソフトを、利用者の実際の運用環境で利用できるように準備すること。
◇「インストール」がコンピューター上で実行可能なファイルを準備することであるのに対して、
「デプロイ」は実行時に必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備すること。「デプロイメント」ともいう。
665 ：login:Penguin：2020/02/03(月) 07:34:36.41 ID:Pib546/2.net: Dockerイメージは全て
VirtualBoxとかの仮想マシンイメージで代用出来ると豪語するおじさんなら前いたが
それすらやらないおじさん登場か
もうとにかく手作業を増やして
無駄な仕事を増やしたいとしか思えない
666 ：login:Penguin：2020/02/03(月) 09:14:29 ID:lRDyNjgE.net: >>664-665
こいつらは本当に糞。
自分の無知を、全く認めようとしないのね。
言っとくがお前が何と言おうと普通に現場でデプロイ（リリース）やってる
人が「明日（デプロイヤ使って）リリースします」とかいった場合に、そこに
「mod_phpのインストール」なんて作業は入らない。普通にIT現場で仕事
してりゃ分かるよ。夜間に dep production_web　とかやるだけだ。

どうしようもない馬鹿だな。
667 ：login:Penguin：2020/02/03(月) 09:57:32 ID:/k/BdpP5.net: >>666
お前、apacheとかmysqlとかのデプロイしたことないだろ？
668 ：login:Penguin：2020/02/03(月) 10:21:54 ID:lRDyNjgE.net: >>667
馬鹿な君とやり取りすると必ず齟齬るから厳密に言ってくれれないかな？
apacheの何を行うことを持ってデプロイといっているの？
mysqlの何を行うことを持ってデプロイといっているの？
回答はそれ次第。
669 ：login:Penguin：2020/02/03(月) 10:28:16 ID:/k/BdpP5.net: >>668
https://aws.ama
zon.com/jp/rds/mysql/

> Amazon RDS を使用すると、コスト効率が良く、サイズ変更が可能なハードウェア容量で、
> スケーラブルな MySQL サーバーを数分でデプロイできます。
670 ：login:Penguin：2020/02/03(月) 10:30:21 ID:/k/BdpP5.net: https://kubernetes.io/ja/docs/tutorials/
例: 永続ボリュームを使ったWordPressとMySQLのデプロイ
671 ：login:Penguin：2020/02/03(月) 10:34:30 ID:/k/BdpP5.net: https://docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.html
The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers.
672 ：login:Penguin：2020/02/03(月) 11:27:58.67 ID:lRDyNjgE.net: >>669-670
この回答の全てにおいてお前の経験の無さと論理的思考の欠如が良く出ているよ。
その2つに関して経験があるかと聞かれれば、「あるよ」で終わり。
が669に関して言えば、その説明に書いてあることは広義の意味で正しいけど、IT現場一般でその作業を「デプロイ」とは言わない。

670はそもそも一般的で言うIT用語のデプロイと、Docker村のデプロイの言葉の差違を今話題にしていて、
「一般的なデプロイとは何か」を語っている何故お前はDocker(k8s)村のデプロイの話を持ってくるの？
経験があるのかと聞かれれば当然あるよ。だがそれは、Docker村の用語でしかない、Dockerの場合はコンテナ破棄するんだから
そうするしかないだろ。でもそれはDocker村の話でDoker村を離れた現場では、>>651がデプロイだ、という話をずっとしている訳だが？
だからデプロイが複雑な場合はDockerが有効なこともありうるよ、と>>575でいったんだが。

ハァ

････お前の馬鹿っぷりは良く分かった。
もう俺にレスするな。俺はお前のような馬鹿と話はしたくない。
お前Docker村の話しか理解できない、自分の能力の無さが色んなところでスゲェ迷惑してるって気付いてないだろ？
620番台（もっと言えばこのスレの2桁番代から）から本来一瞬で終わる話を延々と続けてるんだが？
673 ：login:Penguin：2020/02/03(月) 12:26:35 ID:/k/BdpP5.net: ※ 以下の二つはDockerとは関係ない「デプロイ」であるというのが>>672の笑える点ですw

> Amazon RDS を使用すると、コスト効率が良く、サイズ変更が可能なハードウェア容量で、
> スケーラブルな MySQL サーバーを数分でデプロイできます。

http://docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.html
The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers.
674 ：login:Penguin：2020/02/03(月) 12:58:18 ID:lRDyNjgE.net: >>673
オッケー、もう話したくは無いというのを反故にするけど、ちょっとじゃあ、君の開発経験を教えてくれ。
俺の話が全く通じないのはその辺に原因があると思う。

君は、Docker以前はどのような言語、フレームワーク、開発体制（人数など）でソフトウェエア開発プロジェクトを行っていた？
それは、プロジェクトの数で言えば幾つ位で年数は何年位？

でその時に、当然、自分とかチームがが開発したものを開発、検証サーバーや本番サーバーに上げたと思うけど、その時の
デプロイはどの様に行っていたの？（ここで言うデプロイはDocker用語じゃなく、>>651的なものね）
当然本番機にあげなきゃ動かないよね？どうやっていたの？
675 ：login:Penguin：2020/02/03(月) 13:01:10 ID:/k/BdpP5.net: >>674
まずお前がその自分の質問内容に答えろや
揚げ足撮ろうとしてるのバレバレ
676 ：login:Penguin：2020/02/03(月) 13:02:21 ID:/k/BdpP5.net: あとお前ansibleでMySQLのデプロイしたことあるの？

http://docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.html
The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers.
677 ：login:Penguin：2020/02/03(月) 13:08:35 ID:lRDyNjgE.net: >>676
ansibleでデプロイ？そんな事はしないよ。で>>674に答えてくれるかな。
678 ：login:Penguin：2020/02/03(月) 13:09:44 ID:/k/BdpP5.net: >>674
まずお前がその自分の質問内容に答えろや
揚げ足撮ろうとしてるのバレバレ

>>677
やっぱりansibleでMySQLのデプロイとかしたことないのねw
679 ：login:Penguin：2020/02/03(月) 13:15:53 ID:lRDyNjgE.net: >>675
>※ 以下の二つはDockerとは関係ない「デプロイ」であるというのが>>672の笑える点ですw

こういう点ね。「本番システムにデプロイする」とか、そういった単語が使われるようになったのは
俺の経験じJavaあたりからで、（war/earファイルをデプロイする、とか）、それは十数年前のことで、その
当時から、「デプロイする」といえば、>>651のような作業で、RDS作ることをデプロイするとは言わなかった。
あくまで経験でしか答えられないからね。君が俺と同じ位の経験値を持って話をするなら、俺の話に
抵抗するなんて事は無い。皆そういってたから。

で、その話とは関係無しに、Docker以前の開発現場で場数を踏んでいれば、
「当然本番機にあげなきゃ動かないよね？どうやっていたの？」に対して何らかの解決策を行っていたはずなんだか？
君の場合、それは何だったの？
680 ：login:Penguin：2020/02/03(月) 13:16:37 ID:lRDyNjgE.net: >>678
答えたろ。君の経験を教えてくれよ。
逃げるなよｗ
681 ：login:Penguin：2020/02/03(月) 13:18:05.77 ID:/k/BdpP5.net: >>679はひたすら「自分の（少ない）経験では〜」と繰り返してるだけ
現実見せても、俺の！俺の！というだけ
哀れやのうw
682 ：login:Penguin：2020/02/03(月) 13:18:53.99 ID:lRDyNjgE.net: >>681
いや！
分かったから君の豊富な経験を語ってくれよ、是非！
683 ：login:Penguin：2020/02/03(月) 13:21:42.31 ID:/k/BdpP5.net: >>682
語る意味がないので（笑）

それよりかお前が語れよ。
684 ：login:Penguin：2020/02/03(月) 13:21:52.48 ID:lRDyNjgE.net: >「当然本番機にあげなきゃ動かないよね？どうやっていたの？」

こんなの、現場入ったら直ぐ直面する問題だし簡単な話だよな？
まじで、どうやっていたの？
685 ：login:Penguin：2020/02/03(月) 13:22:37.81 ID:lRDyNjgE.net: >>683
だから>>651だって！俺はこれ以外の解決策を知らんよｗ！
君に通じないから不思議でしょうがないんだろｗ
686 ：login:Penguin：2020/02/03(月) 13:25:16.22 ID:lRDyNjgE.net: >>683
意味が無いことは無い！>>651以外の解決策を君が知っているなら、
結構凄い事だ。俺が知らないんだし。
拝聴するから早く語ってくれよ！
687 ：login:Penguin：2020/02/03(月) 13:32:15 ID:lRDyNjgE.net: おいおいレス止まってるよ！
ググったりするなよ！自分の経験から「俺はこうやってた」と言うだけだ。
1分で答えられるよなｗ？
688 ：login:Penguin：2020/02/03(月) 14:35:42 ID:+dD2W5mx.net: ECS使った現代的なスタックなら
全部Terraformで済むから
Ansibleとかは要らない
ECSはTerraformのAWSプロバイダーで操作できる

ビルドはCIパイプライン内でだけ実行する
JavaやGoのアプリのビルドはここでする
JavaScriptのような動的言語でも、npmからパッケージ取ってきたり、Webpackを使うのにビルドする

本番環境でパッケージの取得やビルドはしない

開発用PCでは試しにビルドはするが、
自動テストを行うのと、
統一した環境でビルドするために
本番環境やQA環境に持っていくやつは必ずCIでビルドする
開発環境でビルトしたのを本番機に送る事はない
689 ：login:Penguin：2020/02/03(月) 14:50:43 ID:H+1Fdh2V.net: ECSの場合、
本番環境からSSHを完全排除も
やろうと思えば可能だな

本番環境の構成を考える時は
開発環境に同じ構成を作ってSSHして、
EC2を初期化するスクリプトのデバッグをやっても良いけど、
ECSのタスクはマネジメントコンソール等から一回限りの実行も可能だし、CI/CD環境で
ECSサービスの更新前にマイグレーションするようにしても良いので
SSHなしの運用も可能

コンテナのログはCloudWatchに送るようにして、
コンテナ以外のログはCloudWatch Agentとかを入れて取る
690 ：login:Penguin：2020/02/03(月) 14:57:14 ID:DVn1edLs.net: Goアプリを>>688みたいにビルド&デプロイしてるけど、正直もうホストに実行バイナリ置くだけでいいんじゃないか感は否めないな
結局ホストは多少なりとも意識しなきゃいけないんだから、本質的には余計なレイヤーは無い方が楽だと思うわ
デプロイとプロセスのライフサイクルの管理が楽というだけでなんとなくコンテナ使ってるが、
たかがそれだけのためにコンテナのような複雑で大袈裟なものが本当に必要なのだろうかとたまに感じる
691 ：login:Penguin：2020/02/03(月) 15:02:28 ID:MAB52r0T.net: 動かすのが自作アプリ1個だけで
Goならそれで良いんじゃね？
知らんけど
692 ：login:Penguin：2020/02/03(月) 15:05:36 ID:1lxKquFf.net: バックエンドはGoで、
フロントエンドはNodeで、
リバースプロキシにnginxとかやりだしたら
コンテナの方が楽だな
693 ：login:Penguin：2020/02/03(月) 15:11:10.24 ID:Q2m7nka6.net: >>690
それはLinuxのカーネル以外を全て一つに外部プロセス呼び出しなしの
スタティックリンクできるって言ってるの同じことだぞ

例えばRubyのスクリプトとgitコマンドとffmpeg実行ファイルを
一つの実行ファイルにまとめれると？

技術的、ライセンス的に可能だと思うか？
694 ：login:Penguin：2020/02/03(月) 15:46:08 ID:Ndl0vT0b.net: >>683の/k/BdpP5氏、逃げちゃったみたいだね。
難しい話語るのは大好きだけど、自分の単純な経験は語れない
可愛そうな人だったｗ
695 ：login:Penguin：2020/02/03(月) 16:47:32 ID:Q2m7nka6.net: >>694
ヒント　月曜日
696 ：login:Penguin：2020/02/03(月) 17:37:54 ID:RqwDXYD0.net: ホストのOS上でコンテナのコマンドを実行する方法ってありませんか？
例えばMacにあるelfファイルをDocker内のUbuntuで実行したり
Linux上のexeファイルをDocker内のWindowsで実行するような
697 ：login:Penguin：2020/02/03(月) 17:50:54.19 ID:SAezlaWT.net: docker内のWindows・・・
698 ：login:Penguin：2020/02/03(月) 18:45:34 ID:Q2m7nka6.net: >>696
ない。ボリュームを使え。
699 ：login:Penguin：2020/02/03(月) 20:29:47 ID:AjbL5ocZ.net: コンテナなら
いちいちインフラチームにNode使えるサーバー用意してとか言って
準備してもらう必要もないからな
最終的にDockerイメージを作りさえすれば良い
700 ：login:Penguin：2020/02/03(月) 21:33:52 ID:uSGfT6bD.net: >>696
このひとDockerをVirtualBoxか何かと勘違いしてる？
両者は異なる問題を解決するために作られたものだ
701 ：login:Penguin：2020/02/04(火) 06:01:49 ID:MBGLu8A2.net: >>700
すみません正にその通りです。軽いから簡易的なVirtualBoxのような使い方ができそうとか考えてた初心者です、素直にそっち使うことにします。
所で新たに生じた疑問なんですがよく紹介されてるUbuntuとかのOSイメージって何に使われてるんでしょうか？
色々調べたらアプリとか鯖に使われてることは大半なんですがOSの使用例があまり見つからなくて。
702 ：login:Penguin：2020/02/04(火) 06:03:06 ID:YD8xtZwK.net: >>695
あいつはたぶんニートか学生だろ。
月曜午前中に連投してたし。
たぶん学生じゃね？
703 ：login:Penguin：2020/02/04(火) 06:09:25 ID:h84uEZr9.net: >>679
>で、その話とは関係無しに、Docker以前の開発現場で場数を踏んでいれば、
>「当然本番機にあげなきゃ動かないよね？どうやっていたの？」に対して何らかの解決策を行っていたはずなんだか？
>君の場合、それは何だったの？

俺はこの回答をずっと待っているんだが、
早く答えてくれないかな？
何で時間がかかるのか全く分からんｗ
704 ：login:Penguin：2020/02/04(火) 06:17:18 ID:7tH3MnnI.net: >>701
サーバやアプリケーションを動かすための最小限のファイルセットが含まれている

OSそのものとしてはあまり使わないのでinit（systemd等）も通常入ってない
705 ：login:Penguin：2020/02/04(火) 06:51:24 ID:glhRAKEA.net: >>703
どうやっていたの？って何を聞きたいのかわからん。
Docker以前？大昔のデプロイの話か？

今みたいにぽんぽんサーバー作れるわけじゃないから、新しくサーバーをデプロイするのは
たいていサーバーの購入から始まる。サーバーのセットアップは手順書が残ってるからそのとおりやる。
もちろん手順書がない初回は、手順書を書きつつサーバーにセットアップするわけだが。

手順書と言ってもそのハードウェアとかOSのバージョンは変わるわけで、
手順書通りやると言うより記録見ながらその都度対応が必要になる。
アプリ用とか特定のものを動かすのに必要なパッケージを手順書という名の
記録を見ながらインストールしていく

で、パッケージをインストールしただけじゃ終わらない。バージョンが微妙に変わるから
アプリの改修作業が必要になる。大体は言語のライブラリが新しくなってるからそれに合わせてアプリを修正する。
アプリの改修作業まで行ってようやく（例えばアプリケーションサーバーの）一台のデプロイが完了する。

その後はそのサーバーを大事に育てる（笑）上記のようなデプロイ作業をアプリのアップデートのたびにやれるわけがないからね
データベースサーバーとかならセキュリティパッチを当てるぐらいで対して変わらないがアプリケーションサーバーは大変。
ある機能に対応するためにライブラリのアプデートが必要だがそれが標準パッケージで提供されてないから
オレオレでパッケージングする必要がある。当時はperlだったから、dh-make-perlだっけな？それでDebian用のパッケージを作る。
アプリの更新はsvn up（笑）そしてapacheの再起動（笑）手動（笑）当時は便利なツールは何もなかったからな。

今は楽だよ。Dockerさえ動く環境があればいい。アプリのアップデート作業なんてものはない。
サーバーはハードウェア仮想化され消して作り直すことなんて簡単、壊してデプロイすればアプリも新しくなっている。
アプリもコンテナ化され、単一のサーバーだろうがクラスタだろうがどこでも動く
706 ：login:Penguin：2020/02/04(火) 08:17:24.75 ID:eRywcgEu.net: うちは最初はサーバーはSSHしてセットアップし、
phpファイルをSFTPでアップロードしてた
当然ながら要らないファイルをアップしたり、し忘れるミスが多発

次にローカルからのrsyncになったが、
rsyncの無視するファイルのルールを編集し忘れて
ファイルが消えたりした

なお、どちらでも本番環境を直接書き換える模様
ブルー・グリーンデプロイ？なにそれ美味しいの？

次の進化は>>651
みたいなphp専用のデプロイツールとも思ったが、
それを経由せずCIでビルドとAmazon ECSでデプロイに進化した

データベースのマイグレーションを除けば
Dockerイメージの更新だけで
安全にローリングデプロイ可能になった
707 ：login:Penguin：2020/02/04(火) 08:20:13.12 ID:eRywcgEu.net: EC2インスタンスはあるが、
ASGで使い捨てになり
サーバーがキャトルミューティレーションされたみたいに死んでも、
代わりをすぐ作れるようになった

アプデもAmazonの配布するAMIの更新で済む
708 ：login:Penguin：2020/02/07(金) 22:37:09.11 ID:2MItdgnx.net: なんか最近はコンテナランタイム沢山あってよくわからない
どれを使えと
rkt（死亡？）
containerd
podman
lxd
cri-o
709 ：login:Penguin：2020/02/07(金) 22:52:56 ID:blZZ5Y7J.net: 基本はDockerを使っていればいい
コンテナランタイムは使える場合があったときに考えればいい
自分から使えるようにするものじゃない
710 ：login:Penguin：2020/02/14(金) 20:00:09.85 ID:7Z+zTex9.net: openshiftの話題が全然出てこないけど、まだみんな使ってないのかな
711 ：login:Penguin：2020/02/14(金) 22:24:51 ID:JcwNgO/m.net: ベースはKubernetesだからなぁ
712 ：login:Penguin：2020/02/15(土) 05:03:41.92 ID:+RsjGVHi.net: クーベルネイティスのスレもあるんやけどなあ
713 ：login:Penguin：2020/02/15(土) 15:02:25 ID:JXgJVuzp.net: クベルネテスかクーベネティスが好き
714 ：login:Penguin：2020/02/15(土) 19:22:28 ID:xcQV5H2n.net: クバァでしょ
715 ：login:Penguin：2020/02/15(土) 19:58:34 ID:lo0b1pQK.net: CoreOS Container LinuxをDockerコンテナ動かすOSに使ってたが
サポート終わりそう
Fedora CoreOSかFlatcar Container Linuxに乗り換えたい

FlatcarはほぼCoreOSのまま
メンテされるらしいが
rktは削除されるのか…？
716 ：login:Penguin：2020/02/16(日) 12:27:29 ID:BVDCl0/P.net: OpenShiftはIBMが主に金融機関に対してクラウドのセキュリティリスク煽ってオンプレでサポート特盛契約をゴリ押しするための飯の種だろ
自社で使うようなもんじゃないよ
717 ：login:Penguin：2020/02/16(日) 14:15:39.62 ID:OI4Id5HK.net: 代替技術が本家を超えることってめったに無いよな
なんかったっけな？
718 ：login:Penguin：2020/02/16(日) 14:48:00.89 ID:n+poZ4Ku.net: LinuxってUNIXの代替じゃん？
719 ：login:Penguin：2020/02/16(日) 14:56:20 ID:n+poZ4Ku.net: Android RuntimeもJava VMの代替品
720 ：login:Penguin：2020/02/16(日) 15:28:46.80 ID:3YAQTUkr.net: 超えちゃいないなどっちも。
721 ：login:Penguin：2020/03/06(金) 18:10:13.02 ID:OjWfIiDl.net: Docker Desktop for Windows 2.2.2.0(Edge)でようやくWindows Homeでもインストールできるようになった。

insider preview(slow ringで十分)でwsl2が必要。
722 ：login:Penguin：2020/03/06(金) 19:48:44 ID:w+ubkCwq.net: もう正式版が出たのかと思った。
WSL2がまだだからそれはないかｗ

Docker Desktop for WSL2として出すんじゃなくて
Docker Desktop for WindowsをWSL2対応するってことかな？

だからDocker Desktop for Windowsとしては正式版だけど
WSL2対応機能は一応ベータ版と。完璧に動いていてもWSL2が
正式版じゃない以上なにか変わるかもしれんしね。
723 ：login:Penguin：2020/03/08(日) 21:00:03 ID:S01X0/x1.net: GKE無料じゃなくなるらしい

https://devopsdirective.com/posts/2020/03/managed-kubernetes-comparison/

0.1ドル*24*30=月72ドル
EKSとほぼ変わらない値段になる
ただし、単一ゾーンのクラスターは1つだけ無料

小規模クラスターだろうと大規模クラスターだろうと
値段は一緒なので
小規模クラスターを大量に使うなら
AKSやDOが安い
724 ：login:Penguin：2020/04/01(水) 16:38:08.67 ID:DgjnAS5O.net: >>710
使ってるよ
minishift入れたけどバグが目立つ
725 ：login:Penguin：2020/04/01(水) 22:28:03 ID:eeUwEP3q.net: minishiftはバージョン3なんだよね
今ならCRCの方が良さそう
726 ：login:Penguin：2020/04/02(木) 06:55:51 ID:VqK6Gyyj.net: dockerがあるとJDK要らないみたいな話聞いたんだけど
でもdockerがあるからといってOSのAPIに非依存になるわけじゃないよね？
dockerの上にJDK置いてその上でJavaを実行するとかなら分かるけど、
dockerだけだと例えばLinuxカーネルとかに依存したプログラムを書くことになる、という理解であってる？
727 ：login:Penguin：2020/04/02(木) 07:24:10 ID:y8EJEcvw.net: >>726
間違ってる。まずなぁ、JDKは開発のためのツールであってJavaアプリを
動かすのに必要なものじゃない。その時点で間違ってる。お前はJavaすら分かっていない。
Javaアプリを動かすのにひとうようなのはJREだ

> dockerの上にJDK置いてその上でJavaを実行するとかなら分かるけど、
> dockerだけだと例えばLinuxカーネルとかに依存したプログラムを書くことになる、という理解であってる？

人づてに聞いて想像するんじゃなくて、Dockerをちゃんと勉強しろ
お前が言ってるのは、

　スマホがあればネットするのにパソコンはいらないって話を聞いたんだけど、
　スマホの上にブラウザをインストールしてネットするならわかるけど
　スマホだけならネットできないよね

って言ってるようなもんだよ。例えの意味わかる？
お前が「スマホだけだとネットできない！」って言ったら
スマホはブラウザをインストールして（してあって）ネットするために
作られた道具なんだよってツッコミはいるだろ？

DockerはJRE（等）を置いて使うために作られたものなんだよ。
Dockerだけで使うとかなんだそりゃｗ
スマホだけだと電話しか使えないという理解であってるって聞かれているようなもんだ。
728 ：login:Penguin：2020/04/02(木) 07:41:54 ID:VqK6Gyyj.net: 今（オラクルの）JREは存在しませんよ
あとJDKでも実行できます
729 ：login:Penguin：2020/04/02(木) 08:00:40 ID:y8EJEcvw.net: 今（オラクル以外の）JREは存在してますよ
と言われても困るんだがｗｗｗ

> あとJDKでも実行できます
JDKとJREの違いが今重要って分かってないから
君は"Java"の初心者なんだよ。
730 ：login:Penguin：2020/04/02(木) 08:02:01 ID:y8EJEcvw.net: JREがあれば動くからJDKはいらん。
という答えでも良いんやで？ｗ
731 ：login:Penguin：2020/04/02(木) 08:05:36 ID:y8EJEcvw.net: OSのAPIに非依存とか言ってる点からWindowsのことしか知らんのだなってわかるし
Linuxカーネルとかに依存したプログラムとか言ってる点からLinuxも知らんのだなってわかる

ああいい、言わなくていい。中途半端にしか知らんって意味だから。
浅い知識のまま、何年もやってるんだろうなってわかる。
そして自分が詳しいつもりでいるんだろうなって文章からわかるからさ。
732 ：login:Penguin：2020/04/02(木) 08:25:00.85 ID:GYZhfijy.net: なんか格好悪い。
733 ：login:Penguin：2020/04/02(木) 09:53:26.45 ID:FYEc23jq.net: dockerだけだとLinuxカーネルに依存したプログラムを書くことになるよね？って言うのは、
フランス料理フルコースの店って単品で頼めばフルコースじゃないよね？って言うようなもんだｗ
734 ：login:Penguin：2020/04/02(木) 15:27:59 ID:IPZOwfEY.net: 私の頭は悪すぎる。
ここのやり取りは半分もわからない。
何を言っているだろうな。
735 ：login:Penguin：2020/04/05(日) 20:50:14 ID:ooapWF9T.net: kubernetesだんだん分かってきたわ
面白い仕組みやね(´・ω・`)
736 ：login:Penguin：2020/04/06(月) 08:44:29 ID:FO60yhPK.net: オーバースペック気味だよな
なによりメモリ消費量が多すぎる
737 ：login:Penguin：2020/04/06(月) 11:33:19.03 ID:5llIuxD8.net: 流行ってないけどswarm modeが結構好き
738 ：login:Penguin：2020/04/07(火) 19:45:30 ID:Q0ksfuEi.net: dockerを前提としたソフト開発において、差分ビルドとかデバッグはどうやって使っていけばいいの？
739 ：login:Penguin：2020/04/07(火) 23:47:09 ID:wKrRdfGX.net: >>738
毎度のことながら使い方が間違っている。
Dockerは仮想マシンじゃない。

Dockerの中で差分ビルドやデバッグという
開発作業は行わない

開発が終わってテストもデバッグもすんで
それを配布するときに使うもの
740 ：login:Penguin：2020/04/08(水) 00:53:59 ID:ZpJduvjW.net: >>739
ありがとう。いっていることは分かる。
質問を変えてもう聞きたいのだけど、開発環境の統一化という意味でdocker使いたいけどいい案ありますか？
741 ：login:Penguin：2020/04/08(水) 01:32:17 ID:tWAmSl9y.net: そんなふわっとした聞き方するならググった方が早いんでね？
742 ：login:Penguin：2020/04/08(水) 08:58:29 ID:tEYV+bda.net: >>740
開発環境を押し付けるな。プログラマの自由にやらせろ。「統一環境」ではなく
「推奨環境」として環境づくりが面倒な人のために、例の一つとして作るだけにしろ
統一はしないという前提で「統一しなくても信頼できる」
ことを保証するためにDockerを使うんだよ

統一しないっていうことはわかりやすく言えば、開発環境は
WindowsでもLinuxでもmacOSでも使っていいということ
使うIDEやテキストエディタやブラウザなどはそれぞれ違うだろう
しかし何を使って作っても、同じように動くと保証するにはどうするか？

それが必要なのは"差分"ビルドやデバッグ環境を統一することではない。
"完成版"ビルドと完全なテスト用のDockerイメージを作成することだ。
テスト用のDockerイメージを使ってCIで実行すれば
どういう開発環境を使って開発していたとしても正しく動くことが保証される。

もちろんこのテストというのは全体のテストだ。
自分が開発した部分のテストだけをやりたいのに全体のテストをしていては時間がかかる。
こういうのは自分の開発したマシンでやることだ。つまりそれぞれ違う開発環境でやることだ。

開発には何よりスピードが重要だ。いちいちDocker（ついでにいうと仮想マシンも）を
絡ませなければ開発できないなんて愚の骨頂だ。
環境特有のバグはゼロではないから、統一した環境（つまりDocker）でテストすることは重要だが
大抵の問題は開発者が書いたコードにバグがある。特定の環境でしか発生しない問題は少ない。

どうしてもDockerや仮想マシンが必要な場合でない限り、Dockerや仮想マシンを使わない。
それが開発環境のあるべき姿だ。Dockerや仮想マシンを使わずに高速に開発テストし
場合によってはローカルでDockerを使って統一"実行"環境でテストも出来るようにする。
そして最終的には共通のCIサーバーでテストを実行する。本番用Dockerイメージを使って実行する。
これが今の理想の開発スタイルだ。
もう一度言うがDocker（や仮想マシン）で開発環境を統一するな。そういう時代は終わった。
743 ：login:Penguin：2020/04/08(水) 13:45:22 ID:E1X8IPXX.net: Heroku, CircleCI などの、CI/CD パイプラインだろ

git すれば、Jenkins などのタスクランナーが走って、テスト・デプロイされる
744 ：login:Penguin：2020/04/08(水) 14:07:38 ID:qGQoebh0.net: 何を持ってそんな自信満々に言えるんだろう。クッソ古いlibcとかどーすんのさ
745 ：login:Penguin：2020/04/08(水) 14:21:04 ID:74qGwmrR.net: libc5やELF移行前とかどうすんのさ！ってか。
746 ：login:Penguin：2020/04/08(水) 15:06:33.98 ID:lh3o3SXB.net: >>744-745
なにがいいたいのかわからん。クロスコンパイルがしたいって話？
つまり開発マシンでそのまま動かすことが出来ないバイナリを動かしたいって話？
747 ：login:Penguin：2020/04/08(水) 15:11:30 ID:74qGwmrR.net: いや俺は長文は読まない主義なので、元ネタすら知らん。
748 ：login:Penguin：2020/04/08(水) 15:13:58 ID:74qGwmrR.net: おまえらの糞みたいな書き込みは3行が限界だ。
それ以上は時間の無駄。
749 ：login:Penguin：2020/04/08(水) 15:19:07 ID:0/ZsiN0l.net: 自分で知恵遅れ宣言してて草
750 ：login:Penguin：2020/04/08(水) 15:30:25 ID:9IBLuCoT.net: ガイジの日記帳だからしゃーない
751 ：login:Penguin：2020/04/08(水) 17:11:03 ID:bDnpnEzN.net: >>742
へいすみません
752 ：login:Penguin：2020/04/09(木) 01:01:00 ID:MR8owRqe.net: クーベルネーテスって便利ですか？
753 ：login:Penguin：2020/04/09(木) 02:53:14.55 ID:FEp3Oz10.net: そーでもねーです
754 ：login:Penguin：2020/04/12(日) 22:18:42 ID:U8HvSeE4.net: Dockerfileに以下を書いてbuildしてもWarningになってしまいます…
Qiitaやら海外の掲示板の情報を試しても上手くいかず…
誰か同じ経験or解決したことある人いませんか？
docker介さず行えばpip install コマンドは動くのですが…
Hyper-VにCentos8入れてそこでやってます。

FROM python:3.7
RUN pip install --upgrade pip

→WARNING: Retrying (略　Failed to establish a new connection
755 ：login:Penguin：2020/04/13(月) 05:58:27 ID:eh1JbNkW.net: >>754
おそらくプロキシ環境でDockerfileにプロキシ設定していないのでは
756 ：login:Penguin：2020/04/13(月) 19:14:48 ID:e8TZ9eU2.net: >>754
これ実行したらどうなる？

docker run -it busybox ping 8.8.8.8
docker run -it busybox wget http://google.com
757 ：login:Penguin：2020/04/13(月) 20:57:37 ID:BJxyd1Wh.net: >>755 ありがとう。プロシキ環境は使ってないっす。念のため調べてみます。

>>756 こんな結果になりました。下が通らないのが変なのでしょうか？
[root@localhost ~]# docker run -it busybox ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=5 ttl=49 time=29.793 ms
64 bytes from 8.8.8.8: seq=6 ttl=49 time=15.181 ms
64 bytes from 8.8.8.8: seq=7 ttl=49 time=13.270 ms
64 bytes from 8.8.8.8: seq=8 ttl=49 time=18.520 ms

[root@localhost ~]# docker run -it busybox wget http://google.com
wget: bad address 'google.com'
758 ：login:Penguin：2020/04/13(月) 21:02:51.21 ID:e8TZ9eU2.net: ネットワークはつながってるけど、DNSサーバーの問題だね。
いまから飯作るんで後でなｗｗｗ
それか他の人お願い
759 ：login:Penguin：2020/04/13(月) 21:24:26.45 ID:BJxyd1Wh.net: DNSサーバーか…ありがとう、もう少し調べてみます！
760 ：login:Penguin：2020/04/13(月) 21:25:15.52 ID:e8TZ9eU2.net: でもまあ解決策はよく知らんのよねｗ
俺は普通に使えるし。

こことか参考になるんじゃね？
https://qiita.com/frost-tb-voo/items/fcc0c0fe7561b9101bf4

あと興味があるからこの結果も見てみたいな。
普通はプライベートIPアドレスなはずだが
身元がばれるようなものが入ってないことに注意なｗ

docker run -it busybox df -h
docker run -it busybox cat /etc/resolv.conf
761 ：login:Penguin：2020/04/13(月) 21:25:42.12 ID:e8TZ9eU2.net: DNSサーバーっていうか、名前解決が出来てないってことね
762 ：login:Penguin：2020/04/13(月) 22:17:22 ID:BJxyd1Wh.net: test
763 ：login:Penguin：2020/04/13(月) 22:20:37 ID:BJxyd1Wh.net: Filesystem Size Used Available Use% Mounted on
764 ：login:Penguin：2020/04/13(月) 22:22:13 ID:BJxyd1Wh.net: 何か書けないな？
resolv.confはプライベートIPアドレスと、あと自分でさっき追加した8.8.8.8が入ってました…
765 ：login:Penguin：2020/04/13(月) 22:24:24 ID:BJxyd1Wh.net: >>760
docker run -it busybox df -h
↑の結果を書こうとしたら何故かjaneがエラーになーるww
766 ：login:Penguin：2020/04/13(月) 22:33:31 ID:BJxyd1Wh.net: hyper-Vの設定が悪さしてる気がしてきた…
767 ：login:Penguin：2020/04/13(月) 22:38:36 ID:e8TZ9eU2.net: Docker Desktop for Windows を使ってるんだよね？
768 ：login:Penguin：2020/04/13(月) 23:44:57 ID:JPY8bLts.net: 何か、コンテナの概念と仕組みをスッキリ、はっきり
説明してるお勧めサイトってありませんか？

遅まきながら使い始めたけど、よくわからない。
思考がどうもコンテナ≒仮想マシンってイメージに引っ張られる

とりあえずくじらが書いてある本を、ｱﾏｿﾞﾝﾎﾟﾁｰﾉからのンロッカーで受け取って
ざっと読んだが、余計に混乱しだした・・・。
769 ：login:Penguin：2020/04/13(月) 23:45:17 ID:JPY8bLts.net: すみません、コンテナはDockerの誤りです。
770 ：login:Penguin：2020/04/14(火) 00:05:41.38 ID:nrI+3Pdd.net: >>768
何のためにDockerが作られ、どんな問題を解決しているのか？を調べたほうがいいよ
何に使えるかじゃなくて、何のために使うか。
（何に使えるかだと本来の用途ではない使い方をしてる例が多い。
曰くそういう使い方も出来るからいいじゃん。らしいｗ）

まあ答えを言ってしまえば、自分でビルドしたアプリを配布するために使う。
用途が重要だから仕組みをいくら調べても間違ったイメージは訂正できない。

Dockerの本とかでも良くない例が多くて、Dockerはdockerコマンドや
kubenetes使いこなすんじゃなくて、Dockerfileを自分で書くことが重要なんだが
そのDockerfileであっても例として「既存の○○サーバーをDockerで動かしてみましょう。」
という話が始まる。本来は自分で開発したアプリのDockerfileを書くものだ。
「自分で開発したアプリ」はDockerの話からすれば本題からずれるから
既存の○○を例として使うのはわかるが、そうするとDockerの正しいイメージから遠ざかってしまう。
771 ：login:Penguin：2020/04/14(火) 09:24:30 ID:Iur9C4SR.net: 自分が使いたい使い方を我慢してまで
Dockerの本来の使い方を守ろうとする意味は何？

他の方法がある、とか言うんだろうが
いろんな手法を混ぜるのがめんどくさいから
多少設計思想から外れても全部Dockerでやっちゃうってのも別に自由じゃん
772 ：login:Penguin：2020/04/14(火) 09:32:44 ID:Iur9C4SR.net: あ、ごめん流れ読んでなかった。
>>768の質問があっての返答なら全くごもっともだわ
773 ：login:Penguin：2020/04/14(火) 09:49:37 ID:pFN7AsrW.net: >>771
> 自分が使いたい使い方を我慢してまで

自分が使いたい使い方にはそれに適したツールがあるから
より適したツールが有るのに、我慢してDockerを使わなくていい
774 ：login:Penguin：2020/04/14(火) 09:51:33 ID:pFN7AsrW.net: >>771
> いろんな手法を混ぜるのがめんどくさいから

いるよね。そういう奴ｗ
より適したツールが有るのに「新しいのを覚えるのが嫌だから」
全部エクセルで頑張りましたとかｗ

頑張るところを間違っている。楽するために頑張って知恵をつけるのではなく
バカなまま無駄な努力をすることを頑張る
775 ：login:Penguin：2020/04/14(火) 10:13:41 ID:Iur9C4SR.net: >>773-774
スクリプト書けば一発なのにExcelで何とかするのは純粋に時間のムダだけど、
「Dockerの本来の想定からは外れるかもしれないけどあっさり使える」用途があるなら
実際そういう使い方もできるからいいじゃんとしか言えんわな。

何のために作られたとか、
作った奴の思想はこうだから、とかクソどうでもいい。
776 ：login:Penguin：2020/04/14(火) 10:23:42 ID:pFN7AsrW.net: >>775
実際は「そういう使い方出来るからいいじゃん。
それにしてもDockerって使いづらいですねｗ
こんな事したいんですが出来ないんです。」
ってなってるから言ってんだよ
777 ：login:Penguin：2020/04/14(火) 10:26:29 ID:Iur9C4SR.net: >>776
そこは異論ないよ。
俺のそもそものツッコミも筋違いだったわけだし。
778 ：login:Penguin：2020/04/15(水) 23:40:26.45 ID:rCWj0bNr.net: >>770
> Dockerはdockerコマンドや
> kubenetes使いこなすんじゃなくて、

買った本はまさにそんな感じの本だった。
このコマンドを打つと、コンテナはこういう状態になりまーす、って感じで
Dockerコマンドとは、Dockerとは何ぞや、どういう仕組みなのかって事が中心で
「どうしたら、Dockerって便利だなーってなるんだよ！！」って雰囲気の本だった

目鱗。ありがとうございます。
779 ：login:Penguin：2020/04/16(木) 00:38:45 ID:G9bh7zxQ.net: 「前CentOSで組み立てたこのWebサービス環境だけど今度はUbuntuで動かして！」とかいう指示が来た時にdockerで作っていればもしや楽だったのでは…ってなった事はあった
そういう感じじゃないかなぁ的外れだったらごめん
780 ：login:Penguin：2020/04/16(木) 01:01:20 ID:R7a4uuMe.net: インフラ専業の人が仮想化技術の1つとしてdockerを学ぼうとしているのだとしたら、
たぶんそれはあまり意味がないからやめた方がいい
dockerコンテナはアプリケーションのパッケージ化技術だ
アプリケーションにOSを丸ごとバンドルする、いわばスタティックリンクの一種にすぎない
781 ：login:Penguin：2020/04/16(木) 08:05:13 ID:G/grTQ/Z.net: インフラ屋だけどDocker便利。
Zabbixコンテナを複数環境にそれぞれ独立して作ってるんだけど、
VMではメモリ消費の観点で難しかった。
782 ：login:Penguin：2020/04/16(木) 09:57:27 ID:LeyxDGKY.net: 開発者がCPUやコンパイラの技術を知っておくべきなのと同じように
インフラ屋がDockerの内部技術を知っておくのは正しいが、
普段の仕事でそれらの技術は使わないんだよ。

知っておくとトラブル解決が素早く出来るが
インフラ屋にとってのdockerを使う普段の仕事は
作られたDockerイメージをただ起動するだけ
YAMLファイルに一行書けば終わるぐらいのもの

インフラ屋の仕事が楽になるのではなく、
インフラ屋の仕事が無くなるのがDockerの便利さなんだから

世にあるDocker本は「Docker入門」ではなく
「Dockerを実現する内部技術詳細」と言ったほうがいいぐらい
それぐらい普段の使い方と入門書の内容はずれている
783 ：login:Penguin：2020/04/16(木) 10:55:41 ID:G/grTQ/Z.net: いや普段の仕事で使ってるけど
784 ：login:Penguin：2020/04/17(金) 02:14:26 ID:feyR70XT.net: 用途を決めつけるんじゃなくこれなら便利だって思ったらどんどん活用すればいいんだよな
このスレ見てるとdockerは将来夢のような快適さを提供してくれる
気がする
785 ：login:Penguin：2020/04/17(金) 03:29:51.72 ID:rfDDVJFy.net: 実際には、間違った用途で使っていて、
これDockerでどうやるの？
こんな事したいんですがどうやるの？
Dockerって使いにくいね
って話になるのでうんざり。

間違った用途で使うと、Docker批判につながる
だから、用途が間違ってると、毎回言ってる。
786 ：login:Penguin：2020/04/17(金) 05:12:01 ID:HFgnjVHG.net: 読点とか改行の使い方がアレっぽい
787 ：login:Penguin：2020/04/17(金) 10:42:32 ID:7oYmIfK7.net: >>786
そういうとこだぞ
788 ：login:Penguin：2020/04/17(金) 12:35:48 ID:wAVEYBej.net: 正しいか間違ってるかってより
向いてるか向いてないかよね
789 ：login:Penguin：2020/04/17(金) 15:42:36 ID:7oYmIfK7.net: インフラ屋はすぐにDockerの中でsshサーバーを動かそうと考える
Dockerはそういう為のものじゃない
790 ：login:Penguin：2020/04/17(金) 16:25:02.86 ID:6ChcEj62.net: なんかめんどくさい原理主義荒らしが居着いたね
791 ：login:Penguin：2020/04/17(金) 17:09:13 ID:CgHYJGLh.net: wordでドキュメント書くの面倒だから、dockerでasciidocのコンパイラを作って、
イメージファイルと、バッチファイルを配布した。
なかなか便利に使ってる模様。
792 ：login:Penguin：2020/04/17(金) 17:42:08 ID:7oYmIfK7.net: ↑このように
本当にやりたいことは「asciidocのコンパイラ」を作りたいだけ
だけど、それを動かすのにライブラリとかが必要だから
Dockerでまとめる。という使い方をするもの
793 ：login:Penguin：2020/04/18(土) 06:27:01.12 ID:NYuD+o6/.net: CIで使うようなビルド用/テスト用の本当に使い捨てのコンテナは十分にコンテナ仮想化の哲学と目的にマッチしてるけどな
上でも書いたがVSCodeで使えるような開発用コンテナも十分に有用

個人的には使い捨て或いは壊れたら作り直すものならアプリも環境もサービスもコンテナが良い
そういう意味では, コンテナ仮想化を選択する前に用途が決まっていないと話にならない

用途が違うこともまぁあるんだろうが, それ以上にコンテナに求めるものが曖昧なのにふわっとした目的で使おうとするからコンテナに柔軟性やら壊れた時に直すやらが必要になるのだと思う
少なくともディスポーザブルな環境としてのコンテナは普通に適応
794 ：login:Penguin：2020/04/19(日) 15:28:18 ID:bBijwdm1.net: MS-DOS時代ならOSもアプリも全部フロッピー一枚だったのにな
795 ：login:Penguin：2020/04/19(日) 16:07:47 ID:HPOtbYXu.net: せやな、Aドライブに起動ディスクを入れて、
Bドライブにシステムディスクを入れるんだよね。
796 ：login:Penguin：2020/04/19(日) 21:54:50 ID:lccAXDHW.net: >>754
Dockerfileのビルド時に--network=host入れたらビルド出来たわ…
797 ：login:Penguin：2020/04/20(月) 09:24:11 ID:xAwp4xc2.net: Docker哲学とかどうでもよすぎてゲロ吐きそう
798 ：login:Penguin：2020/04/20(月) 10:40:22 ID:rTh6fQIt.net: 哲学とかどうでもいいがいい加減ステージング用とプロダクション用でそれぞれ別のイメージ作る馬鹿は絶滅してくれないかな
799 ：login:Penguin：2020/04/20(月) 19:04:55 ID:24ShHyns.net: >>798
そんなばかは放置すればOK
もし仕事を一緒にしているのであれば、そのバカを追放するか、その仕事を止めるか。
800 ：login:Penguin：2020/04/20(月) 19:05:45 ID:24ShHyns.net: 馬鹿でも何でもいいから、どう使ってもよい。
801 ：login:Penguin：2020/05/02(土) 15:16:31 ID:jS8tZPz1.net: やっとnginx、gunicorn、flaskをdocker化できた…
ファイアウォールが原因で動かないとか…
802 ：login:Penguin：2020/05/19(火) 10:59:17 ID:QcEp49ar.net: dockerとkubernetesの環境をネットで調べながら作ってるんだけど、
下記のようなエラーが出てるんですが、解決する方法ありますか？

CentOS8
docker-ce 19.03.8
kubernetes GitVersion:"v1.18.2"

kubelet[7677]: E0519 10:42:28.107265 7677 manager.go:1086]
Failed to create existing container: /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-
podaなんかID.slice/docker-なんかID.scope: failed to identify the read-write layer ID for
container "なんかID". - open /var/lib/docker/image/overlay2/layerdb/mounts/なんかID
/mount-id: no such file or directory

dockerのイメージ保存先を起動オプションで変えてあります。
ググったら無視してもいいようなことは書いてあったんですがなんか気持ち悪い･･･。

kubelet[7677]: W0519 10:24:35.435700 7677 watcher.go:87] Error while processing event
("/sys/fs/cgroup/memory/libcontainer_7748_systemd_test_default.slice": 0x40000100 == IN_CREATE|IN_ISDIR):
inotify_add_watch /sys/fs/cgroup/memory/libcontainer_7748_systemd_test_default.slice:
no such file or directory

dockerのオプションで、cgroupではなく、systemdを使用するようにしてあります。

両方ともディレクトリがないエラーですが、dockerのオプションとkubernetesの認識がずれてるように見えます。
803 ：login:Penguin：2020/05/19(火) 11:31:30 ID:6YCn6s4v.net: dockerは理解するとめちゃ便利だとわかった。
ただしlinuxカーネル以外で使おうとすると地獄
804 ：login:Penguin：2020/05/28(木) 10:02:35.43 ID:zrnY/ArL.net: ランタイムや開発キットのコンテナって、他のコンテナとはどうやって組み合わせて使うものなの？
具体的には、code-server + Swiftで使ってみたいんだけど・・・・やり方が全くわからん
https://hub.docker.com/r/codercom/code-server
https://hub.docker.com/_/swift
805 ：login:Penguin：2020/06/20(土) 03:18:22.55 ID:7t9SyItv.net: 64bit OSでDocker使ってるんだけど
ダイジェスト指定以外で32bit用のDockerイメージを使う方法ない？
806 ：login:Penguin：2020/06/20(土) 13:51:10.06 ID:NT++DOXx.net: >>805
ダイジェストとは何？
807 ：login:Penguin：2020/06/20(土) 18:03:39.31 ID:9rcVA94u.net: ハッシュと同じ意味じゃろ
808 ：login:Penguin：2020/06/20(土) 22:50:35 ID:NT++DOXx.net: >>807
thx
809 ：login:Penguin：2020/06/22(月) 13:13:57.71 ID:bXWnnAW9.net: ホノカチャン
810 ：login:Penguin：2020/06/26(金) 14:56:31.79 ID:VvU/3pfe.net: >>798
環境変数サポートの追加がめんどくさい時によくやる
環境ごとに設定ファイル書いてCOPYするほうが楽だもの
811 ：login:Penguin：2020/07/11(土) 01:37:01.10 ID:Go0P4sS+.net: --mountで存在しないボリューム名を指定して実行したらエラーになるらしいのですが
エラーにならずボリュームが作成されてしまいます。
エラーにならないのが正しい動作ですか？

docker run -dit --name test --mount type=volume,source=volume1,target=/tmp
812 ：login:Penguin：2020/07/17(金) 12:24:46.81 ID:BnfFXp5h.net: 最近触り始めたんだがなんでコレ突然RHEL8からハブられてんの？
Kubernetesからも距離置かれはじめてるみたいだし何かあったんか
813 ：login:Penguin：2020/07/17(金) 12:46:45.68 ID:T42yc9xk.net: podmanの件はredhatのほうが先走って自滅した感じ
運用環境はコンテナ標準を満たす限り、dockerにこだわる必要はないから、運用向けに機能を削ったり追加したりして最適化したほうがいい、これは正しい
でも、運用環境っていったら普通はk8sだから、podmanが使われる機会は滅多にない
一方で、開発環境はpodmanのエコシステムがまだまだ貧弱すぎて、dockerにはぜんぜん追いついてない
docker社もそれを理解してるから、開発環境でのエクスペリエンス向上に投資を集中し始めた
またpodmanのセールスポイントの1つであるrootlessも本家dockerはとっくに実装済
結果として誰もpodmanを使ってない（そしておそらくそのまま消え去ると俺は予想してる）という状況になってしまった
redhatにしては珍しくマヌケな戦略をとったなといった感想
814 ：login:Penguin：2020/07/19(日) 16:57:39.80 ID:678GlVXn.net: へー、サンクス。posmanとかはopenshiftやるならって感じなのかね
にしても開発で使う分には裏方が何やっててもちゃんと使えさえすれば関係ないしな…
815 ：login:Penguin：2020/07/19(日) 18:53:58.25 ID:BA4HywGd.net: PODMANのメリットはデーモンレスってことだけ?
赤帽がなにを目指してるのか正直よくわからない
だけど赤帽のやることだから何かがあるんだろうな
816 ：login:Penguin：2020/07/19(日) 20:12:48.88 ID:Rhy9uZzR.net: dockerコマンドだけ使う分にはpodmanにエイリアス設定されてるしあんまり意識しない
問題はdocker-composeを使いたいときだなぁ(podman-composeの互換性が大変怪しい)

まぁmicrok8s使っちゃうからdocker-compose使うこと自体減ってるけど
817 ：login:Penguin：2020/07/19(日) 22:23:14.66 ID:D3aNO6tv.net: docker-composeのメリットがさっぱりわからない
こんなのつかっても結局Dockerfile作らないといけないし意味がない
818 ：login:Penguin：2020/07/19(日) 23:30:36.97 ID:CHBleA4c.net: Dockerfileはアプリケーションのソース
docker composeはビルドしたアプリケーションをどうデプロイするかを定めたマニフェスト
全く役割が異なるのでどちらかがもう一方の代替になることはない
819 ：login:Penguin：2020/07/20(月) 06:54:27.74 ID:fDSiPKdP.net: docker-composeと比べるのはDockerfileじゃなくてdockerコマンドだよ
DockerfileあったってDockerコマンドは使うだろ？

コンテナ一つだけならDockerコマンドを直接使っても苦労はないが
複数のコンテナを使う時Dockerコマンドを何度も実行して起動するのは大変
Dockerコマンドが面倒になったらdocker-composeを使うんだよ
820 ：login:Penguin：2020/07/20(月) 14:45:46.51 ID:sHuZrd7b.net: Dockerfileを書かなくてもいいものだと思ってた
勉強になりました
821 ：login:Penguin：2020/07/20(月) 20:25:51.65 ID:2mNwS2JU.net: 書かなくてもいいけど、なにやったか忘れる。
822 ：login:Penguin：2020/07/20(月) 20:33:40.26 ID:ZBQhEHfA.net: そのまんま手順書になるのがいいとこでは
823 ：login:Penguin：2020/07/20(月) 21:06:57.55 ID:61CQ31O+.net: docker execは邪道なのかな
824 ：login:Penguin：2020/07/20(月) 21:25:56.42 ID:ONUA68Eb.net: docker execはデバッグ機能
825 ：login:Penguin：2020/07/20(月) 22:35:22.68 ID:2mNwS2JU.net: docker exec して、動かしながら、Dockerfileを書く。
最後にdocker buildして同じものが出来上がって完成。
って感じじゃない？
826 ：login:Penguin：2020/07/20(月) 23:19:19.40 ID:fTvFRbnb.net: うちは運用ジョブをdocker execで流してます
docker execを使わない場合、運用ジョブ専用のAPIやWebAppを整備するんでしょうか?
827 ：login:Penguin：2020/07/20(月) 23:20:30.91 ID:sHuZrd7b.net: データベースをホストにマウントするのとボリュームで管理するのはどっちがいいんでしょうか？
828 ：login:Penguin：2020/07/21(火) 08:33:15.29 ID:nXYHdseE.net: >>825
そんなことめったにしないなぁ。docker buildはキャッシュが効くんで
（キャッシュが効くように）Dockerfileに追記しながらDockerfileを書く
終わったらDockerfileをシンプルにしたりサイズが膨れ上がらないように調整するって感じ
docker execなんかして作業したら、その作業結果をファイルに保存するの二度手間じゃん
829 ：login:Penguin：2020/07/21(火) 08:34:31.90 ID:nXYHdseE.net: >>826
そういうのはdocker runやるのが普通
最初docker execなんてなかったんだよ
それなのにそういう用途にも使えたわけ
830 ：login:Penguin：2020/07/21(火) 08:36:51.02 ID:nXYHdseE.net: >>827
どちらもボリューム。データの保存先のパスが違うだけって知ってる？
Dockerサーバー上の特定のパスに保存するか
Dockerが用意したパスを使うかの違い
831 ：login:Penguin：2020/07/21(火) 09:34:41.28 ID:+NBX9hi+.net: ホストマウントはホスト環境への明示的な依存なので、どうしても必要でなければ避けてvolumeを使うべき
volumeも内部的にはホスト環境に依存してるといえばそうだけど、抽象化・隠蔽されているのでホストマウントよりBETTER
実例として、Docker for Windowsでのパーミッション、リモートエンドポイントへのコマンド実行、などでvolumeを使用していれば避けられたトラブルが結構あった
832 ：login:Penguin：2020/07/21(火) 10:07:02.11 ID:nXYHdseE.net: つまりはいろんな種類のホスト、例えばWindowsやMacでも使いたいなら
Docker上のボリュームを使えってことだな。

Dockerイメージ自体は同じものを使える。
必要に応じてDockerのボリュームを使おうがサーバー上の
パスを使おうが自由に選択できる。

だが相対パスを使えばいいだけじゃないか？
833 ：login:Penguin：2020/07/21(火) 10:23:04.25 ID:iuc4a5Mi.net: 相対パスでマウントできたっけ
834 ：login:Penguin：2020/07/21(火) 11:16:17.36 ID:ZxJULecG.net: 相対パスを変換するだけやろ
835 ：login:Penguin：2020/07/21(火) 11:16:50.09 ID:ZxJULecG.net: docker-composeはそれを自動でやってくれる
836 ：login:Penguin：2020/07/21(火) 11:18:02.84 ID:ZxJULecG.net: そもそもDockerのクライアントがどんなOSかなんて関係ない
Dockerはサーバーで動くし、DockerはLinuxでしか動かない
837 ：login:Penguin：2020/07/21(火) 11:43:13.56 ID:+NBX9hi+.net: >>832
その相対パスが存在するか、適切なパーミッションを持っているか、といった条件はホストへの依存性となる
基本的にホストへの依存性が少ないほどトラブルは減る
838 ：login:Penguin：2020/07/21(火) 11:54:51.20 ID:+NBX9hi+.net: >>829
docker runで全てが解決するならdocker execは存在しない
docker runはコンテナ外部で解決可能なジョブの実行に適している
docker execはコンテナ内部で行う必要があるジョブのために存在する
839 ：login:Penguin：2020/07/21(火) 17:20:28.68 ID:rF6lL3p5.net: 問題は Windows と Mac でボリュームを使うとファイルシステムの変換が起こるのでとても遅いということですね
840 ：login:Penguin：2020/07/21(火) 17:24:19.41 ID:cvaypvgc.net: >>838
だからdocker execは主にデバッグ用だって
通常の運用時には使わないもの

コンテナ外部で解決可能とか何のことを言ってるんだかさっぱりわからん
docker runとdocker execで実行できることは全く同じ
違いはdocker runはメインの処理を行うもので、
docker execはメインの処理を行ってる最中に乗り込んでデバッグするもの
841 ：login:Penguin：2020/07/21(火) 17:32:03.04 ID:iuc4a5Mi.net: runで常時起動してるコンテナに
例えばcronからexecでジョブ実行してもいいと思うがな
842 ：login:Penguin：2020/07/21(火) 19:56:43.47 ID:1Ck3nt75.net: kubectl exec 経由なら、管理用のコンソールが欲しいときにわりと使ってる
843 ：login:Penguin：2020/07/21(火) 20:04:49.86 ID:5ttvOiMf.net: >>840
全く違うよ
運用ジョブには大まかに分けてリモート実行可能なものとローカル実行のみ可能なものに分類できる

コンテナの外で解決可能なジョブはこの分類で言うとリモート実行可能なジョブに当たる
具体例はデータベースのバックアップ、バグデータの修正など
データベースコンテナとは別にジョブ専用のコンテナを同じネットワークでrunすれば良い

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
具体例はGitlabのバックアップ(gitlab rake)コマンドなど
ローカルで実行される前提のコマンドはdocker execで実行するしかない
844 ：login:Penguin：2020/07/22(水) 00:03:46.48 ID:2kFCswWG.net: Dropboxにバックアップするのが楽だからホストのボリュームがいいと思ってたけど
Dockerのなかでボリューム作ったほうがはまらないってことですね
勉強になりました
845 ：login:Penguin：2020/07/22(水) 06:37:22.77 ID:DmDy0NhW.net: >>843
なんか使い方がおかしいな
まさかDockerコンテナの中に永続的な情報を入れてるんじゃないだろうか？
永続的な情報はボリュームに入れるんだぞ
846 ：login:Penguin：2020/07/22(水) 06:39:34.85 ID:DmDy0NhW.net: >>843
> ローカルで実行される前提のコマンドはdocker execで実行するしかない
何度読んでも全く理解できん
なんでだよ

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
ローカル実行の可能なジョブはコンテナの外で解決できない
と話をループさせてるだけで全く説明してないよ
847 ：login:Penguin：2020/07/22(水) 08:51:30.32 ID:4XcuGSJO.net: >>845
例として運用ジョブとしてポピュラーなバックアップを挙げたが、今の話題と永続化は別の問題だ
848 ：login:Penguin：2020/07/22(水) 09:22:02.54 ID:4XcuGSJO.net: >>846
わからないなら、わかるまでよく考えるしかない、としか言えないな
849 ：login:Penguin：2020/07/22(水) 09:35:40.02 ID:ILpdMsPa.net: では無いということで決着
850 ：login:Penguin：2020/07/22(水) 09:56:11.99 ID:8t2ogVS3.net: イメージ開発者など実際に運用までしない人には確かに要らない機能だと思う
851 ：login:Penguin：2020/07/22(水) 12:32:30.91 ID:0mhEikFA.net: イメージ開発してる人は自分でイメージつくからね
今あるイメージでなんとかしなきゃで
バッドノウハウ溜め込む運用とは考え方が違う
852 ：login:Penguin：2020/07/22(水) 13:10:29.72 ID:TaKEPsBL.net: で、工数がかさんで、メンテナンス範囲が広がる、と
既存のツールセットをうまく使う、ということもできないと後々つらくなる
853 ：login:Penguin：2020/07/22(水) 13:17:10.14 ID:TaKEPsBL.net: execでコマンドうちゃいいだけなのに、わざわざ工数をかけてメ対象を増やして、アタックサーフェスを広げて、何がしたいのかね一体
854 ：login:Penguin：2020/07/22(水) 16:09:20.10 ID:hHBoQuqj.net: >>853
よりシンプルになる
855 ：login:Penguin：2020/07/22(水) 17:21:04.37 ID:TaKEPsBL.net: >>854
execのがシンプルですけど
856 ：login:Penguin：2020/07/24(金) 11:28:30.42 ID:9ctQO3NL.net: ボリュームも好きなように使えばよかです。
857 ：login:Penguin：2020/07/24(金) 16:08:44.19 ID:PGdrq6O1.net: データベースはdockerの中にボリュームつくって
htmlとか静的ファイルはホストにボリュームつくるのがベストと考えてるんですが

メリットとデメリットはよく分かりません
858 ：login:Penguin：2020/07/24(金) 18:36:20.59 ID:wNiJOAd7.net: せっかくDockerのおかげでリリースが簡単になったのに、
ホストに静的コンテンツをリリースするんじゃ元と変わらない、
どころか静的コンテンツとコンテナでリリースの手間が余計に増えてしまう

静的コンテンツはVOLUMEを使わないでイメージに固めてしまうのが簡単
859 ：login:Penguin：2020/07/24(金) 18:44:01.00 ID:KgUsH74f.net: >>857
> データベースはdockerの中にボリュームつくって
> htmlとか静的ファイルはホストにボリュームつくるのがベストと考えてるんですが

どちらでも作るDockerイメージは同じ
860 ：login:Penguin：2020/07/26(日) 11:46:33.02 ID:ZKCP3mGq.net: ホストからボリュームのマウントってできるんですか？
ホストとDockerか同時に参照して読み書き
861 ：login:Penguin：2020/07/26(日) 11:53:37.27 ID:zOThrt4A.net: >>860
それが指定したディレクトリをボリューム化して使う方法だろ
862 ：login:Penguin：2020/07/26(日) 12:41:37.77 ID:KbVs3Pw7.net: -v $PWD/:/home
とか？
863 ：login:Penguin：2020/07/26(日) 14:27:05.43 ID:LYKyG3mp.net: -vって非推奨じゃないっけ
864 ：login:Penguin：2020/07/26(日) 19:10:43.31 ID:xwiBJJgr.net: そんなわけねーだろあほか
865 ：login:Penguin：2020/07/26(日) 23:10:22.02 ID:YmgaEoJ6.net: >.>843が理解できない人が理解できない。。
docker execがデバッグ用に使うものって・・・なにそれｗ
866 ：login:Penguin：2020/07/27(月) 15:39:45.25 ID:16MZ7SLt.net: -vが非推奨じゃなくて--mountが推奨されてるだけか
ってことは今後-vが非推奨になることもありえるな
867 ：login:Penguin：2020/07/27(月) 16:17:45.47 ID:CekD5d56.net: ない
868 ：login:Penguin：2020/07/27(月) 21:43:15.69 ID:16MZ7SLt.net: https://docs.docker.com/storage/bind-mounts/#choose-the--v-or---mount-flag

でも書いてあるね
869 ：login:Penguin：2020/07/28(火) 09:06:50.60 ID:Eo000t12.net: まあブイって分かりにくいしなボリュームなんだろうけど
870 ：login:Penguin：2020/07/28(火) 14:33:12.71 ID:neJtwKTj.net: /htdocs/public_html/wordpress
/htdocs/public_html/joomla

サイトの中で複数のCMSを動かしてるのですがこの場合
コンテナはapacheなどのwebサーバを起動して
entrypointでwordpressとjoomlaをgit cloneするのが良いでしょうか？
871 ：login:Penguin：2020/07/28(火) 14:54:37.04 ID:m4hPL3wS.net: >>870
まず最初に何のためにDockerを使うのか
目的をいえ
872 ：login:Penguin：2020/07/28(火) 17:25:06.85 ID:66gKFktJ.net: 流行だから
873 ：login:Penguin：2020/07/28(火) 19:53:47.19 ID:0ejo3GGx.net: wordpressとjoomiaをpullするのがいいと思うよ。
874 ：login:Penguin：2020/07/28(火) 22:42:13.49 ID:nHx7byYs.net: どういう問題を解決したいのかを理解してないで
Docker使おうとするからわからんのだ
875 ：870：2020/07/28(火) 23:16:18.39 ID:neJtwKTj.net: joomlaからwordpressのapiを使いたいのです
876 ：login:Penguin：2020/07/29(水) 02:36:49.88 ID:1DD16e/3.net: >>875
1.ホスト側に両方のサービスを登録しておく（動作確認用）
127.0.0.1 wordpress
127.0.0.1 joomla

2. joomla側にwordpressのアドレスを登録しておく

172.18.0.x wordpress とか。

3. joomla側からWPのAPIたたく。

http://wprdpress/wp/v2/posts?status=draft

おわり。
877 ：login:Penguin：2020/07/30(木) 02:15:11.89 ID:eMYOlHCU.net: マックユーザーは知ってる単語を総動員して俺スゲーアピールするからな。
意味は滅茶苦茶。
878 ：login:Penguin：2020/07/30(木) 13:12:56.80 ID:OjTtmOha.net: Mac ユーザーはどれですか？
879 ：login:Penguin：2020/08/02(日) 01:04:36.78 ID:a2KL0hDN.net: 無料でプライベートリポジトリが持てるとこありませんか？
880 ：login:Penguin：2020/08/02(日) 10:54:46.95 ID:gLkvbaRS.net: Gitlab.com
881 ：login:Penguin：2020/08/04(火) 14:57:23.41 ID:r4gffBIv.net: GitHub
882 ：login:Penguin：2020/08/06(木) 08:39:59 ID:83LhEmMR.net: >>877
は誤爆ね。
ARMマックのスレ住人のこと。
883 ：login:Penguin：2020/08/06(木) 18:43:11.69 ID:3qQCQ04+.net: docker engine apiに認証認可を加えるプラグインはあるか？
docker swarmクラスタを複数のチームで共同利用してる
作成したリソースを他人に削除されないように保護したいんだがそういうのは難しいかな
884 ：login:Penguin：2020/08/06(木) 19:52:34.99 ID:NogDVngy.net: https://docs.docker.com/engine/extend/plugins_authorization/
とかは？
885 ：login:Penguin：2020/08/10(月) 21:37:54.41 ID:7+E1pOJx.net: 1日で～のDocker本買ったけど後半の章雑すぎて購入して損
いいことも書いてあるから全く参考にならないってわけじゃないんだけど
後半からtypoが異様に多い
尼損のレビューがヤサクラに見えてしまう
買うなら初版はおすすめしない
886 ：login:Penguin：2020/08/10(月) 21:39:58.83 ID:7+E1pOJx.net: チャプター５はDockerfileのサンプルコードが入ってなくて動作確認できないとかね
サンプルコードなら出版社からダウンロードできるが、本を読み進めてできるよう書いてほしかった
887 ：login:Penguin：2020/08/10(月) 21:42:56.42 ID:7+E1pOJx.net: さわって学ぶ～のほうはレビューついてないが初心者にはこっちがわかりやすかった
この本を読んでから、1日で～の本を読むと理解力が進むかな
888 ：login:Penguin：2020/08/10(月) 22:19:03.56 ID:UKFyAkrv.net: まず、たった一日でDockerとKubernetesが身につく訳が無い。
889 ：login:Penguin：2020/08/10(月) 23:32:42.88 ID:A61ymjf1.net: なんとなく使うぐらいなら1日もいらん
890 ：login:Penguin：2020/08/11(火) 02:02:40.95 ID:/umJrRzE.net: まあエアプならそう言えるけどな。
891 ：login:Penguin：2020/08/11(火) 06:14:32.10 ID:ZlYpnHkh.net: アプリケーションコンテナがどういう問題を解決するツールかってのを
ちゃんと理解してる人なら1日もいらんだろうが
大抵の人はコンテナって何？から入るので無理
892 ：login:Penguin：2020/08/11(火) 13:07:02.70 ID:U49UUAfb.net: ネットワークの使い方がよくわからないんだよね
同じネットワークに所属するコンテナ同士はお互い通信できるけど
本番ではlocalhostとして接続したいからネットワーク名で接続し合うのはなんか違う
893 ：login:Penguin：2020/08/11(火) 17:47:50.49 ID:tAVKMbGD.net: >>892
> 本番ではlocalhostとして接続したいからネットワーク名で接続し合うのはなんか違う
どこからlocalhostでつなぎたいと言ってるんだ？
コンテナ同士はコンテナ名（コンテナのホスト名）で接続するものだ
localhostで接続するのはホスト（Dockerを起動してるマシン）から特定のコンテナに接続するときだけだ
そして外部マシンからはからはホスト名（Dockerを起動してるマシンのホスト名）で接続する
894 ：login:Penguin：2020/08/11(火) 18:02:58 ID:tAVKMbGD.net: あとコンテナから接続先のコンテナは（一般的には）設定変更できるように作るもんだぞ
多分それがわかってないんだと思うが

例えばそのコンテナがWordpressだったとして
接続先のMySQLはコンテナを使うかもしれないし
AWSやGCPのMySQLを使うかもしれない

「コンテナ同士がお互いに通信できる」場合の通信相手のホスト名は変更可能にしておく
通信先ホスト名はコンテナを起動するときに環境変数などで指定するのが一般的
イメージに埋め込んでしまったら、同じイメージを使えなくなるからね
895 ：login:Penguin：2020/08/11(火) 18:08:55 ID:tAVKMbGD.net: 例えばWordpressを起動する wordpress.exe コマンドがあったとして
そのWordpressはおそらくどのポート番号で待ち受けするか？という --portオプションや
どのMySQLに接続するか？という--db-addressというオプションを持っているはずだろ？

それと一緒なんだよ。 dockerで起動するときも
docker run wordpress --待受ポート番号 --接続先データベースサーバー
のような感覚

Dockerイメージ=一つのアプリとして考える

「同じネットワークに所属する」というのはどちらかといったら便利機能
本来は外部に立てたデータベースサーバーへのIPアドレスを指定する所を
コンテナにつけた短いホスト名で簡単にアクセスできますよってだけ
896 ：login:Penguin：2020/08/11(火) 19:57:48.11 ID:U6TkWWEF.net: 長い
12 factor appでググれ、で済む話だろ
897 ：login:Penguin：2020/08/12(水) 01:05:56.62 ID:695OsXNm.net: 12 factor appにコンテナの話は書いてない
読み直してこい
898 ：login:Penguin：2020/08/12(水) 08:42:48.33 ID:ywxaxJOF.net: DNS サーバーがhostsで名前解決するのはどうかな？
899 ：login:Penguin：2020/08/16(日) 00:21:18.95 ID:61ueIM5k.net: コンテナAの/tmp/time.txtを、コンテナBから読み込みたいんですが
これはコンテナ同士でボリュームを共有しないと見えないでしょうか？
900 ：login:Penguin：2020/08/16(日) 00:30:48.19 ID:xu+Ov6hc.net: NFSでマウントすれば？
901 ：login:Penguin：2020/08/16(日) 00:32:48.42 ID:GIuDy0WK.net: これからDocker入門する初心者ですがWindows上でも、MacでもDocker上のコンテナは同じ環境に出来るので、OSを意識しなくて良いというのがメリットでしょうか？
902 ：login:Penguin：2020/08/16(日) 01:19:01 ID:28Ktyu28.net: はい
903 ：login:Penguin：2020/08/16(日) 02:39:02.81 ID:eqqfHYzC.net: >>900
それはアホなやり方です
904 ：login:Penguin：2020/08/16(日) 20:30:18 ID:ksz6M+9p.net: >>892
ネットワークがよくわからんは同意。
k8sにしても理解に苦しむというか、もう少し工夫できんかったのか不満は多いな。
905 ：login:Penguin：2020/08/16(日) 20:38:31 ID:+jHSMkRj.net: >>904
Dockerの役割をそもそも理解してないんだと思う
906 ：login:Penguin：2020/08/16(日) 21:09:41.38 ID:ksz6M+9p.net: >>905
dockerの理解とネットワークは関係ないね。
役割を理解したからネットワークが理解できるわけじゃない。
907 ：login:Penguin：2020/08/16(日) 21:18:40.60 ID:+jHSMkRj.net: >>906
Dockerの役割っていうのは、そういうネットワークを仮想化して
意識せずに使えるようになってるってことだよ

Dockerの具体的なネットワーク実装を意識してしまうのは
まだ抽象化して考えれるようになっていない
908 ：login:Penguin：2020/08/16(日) 21:34:58.56 ID:ksz6M+9p.net: >>907
>>892がそもそもいっているのは「ネットワーク名で接続し合うのはなんか違う」
だから、「Dockerだから（したくないのに）ネットワークを意識する」と、言っている。
実際クラスタリング組むとPodを管理するネットワークとコンテナ通信用のネットワーク
とかバラバラなので、余計に意識はする。
それを何とかでできんかったのか？と、俺は言っている。
docker使ってネットワークをあまり意識する必要がないのは１台で動いているときだけ。
そして本番機が１台で動くことは滅多にない。
909 ：login:Penguin：2020/08/16(日) 21:42:32.06 ID:+jHSMkRj.net: >>908
「ネットワーク名で接続し合う」っていうのが意味不明
それぞれのDockerはホスト名で接続し合う

その接続先のホスト名というのは、Dockerコンテナ起動時に指定した
（同じネットワークに属している）シンプルな名前かもしれないし
外部サーバーのホスト名かもしれない

いずれにしろ、Dockerコンテナ起動時に指定するもの
同じネットワークに属していれば、ホスト名がシンプルな名前でよくなるというだけ
910 ：login:Penguin：2020/08/16(日) 21:53:41.94 ID:fGT/iEH6.net: 全部localhostにしたらしたで余計わけわからなくなりそうなもんだが
物理ネットワークを意識せずに仮想ネットワーク上に構築できるならそれでおｋ
911 ：login:Penguin：2020/08/16(日) 22:01:18.76 ID:ksz6M+9p.net: >>909
わからないなら、しったかで答えるなよ。
https://docs.docker.jp/engine/userguide/networking/dockernetworks.html#id4

デフォルト・ネットワーク以外は「ネットワーク名で接続し合う」のは当然だろ？
912 ：login:Penguin：2020/08/16(日) 22:11:20.78 ID:+jHSMkRj.net: >>911
それ読んだのにネットワーク名で接続し合うなんて読むのか？
同じネットワークに属させるだけ
同じネットワークが複数のホストにあっても構わない
だからDockerコンテナからはネットワーク名なんて意識する必要がない
起動時のオプションに過ぎない
913 ：login:Penguin：2020/08/16(日) 22:13:59.08 ID:+jHSMkRj.net: >>910
何の話をしてるのか知らんが、
物理・仮想マシンでアプリ（Dockerコンテナ）を起動した時
同じマシンからはlocalhostでアプリ（Dockerコンテナ）に接続でき
外部からはその物理・仮想マシンのアドレスで接続するだろ
そこは単純なアプリと何も変わらんのだが
914 ：login:Penguin：2020/08/16(日) 22:25:58.43 ID:ksz6M+9p.net: >>912
同じネットワークに属した結果、そのネット―ワークで接続してるだろ。
ブリッジであれ、オーバーレイであれ、自分で作らなければならないんだから
「起動時のオプションに過ぎない」訳が無いだろう。
915 ：login:Penguin：2020/08/16(日) 22:33:18.42 ID:+jHSMkRj.net: >>914
どこの話だよ。引用してみ。
916 ：login:Penguin：2020/08/16(日) 22:50:24.43 ID:+jHSMkRj.net: あー、なんとなくわかったわｗ
「ネットワークを作る」っていうのを聞いて
ネットワーク設定を変更してるんだなって思ってるんだな

まあ実際にはそういう事をやってるんだろうが意識することではない
知らなければいけないのは、グループを作って
其のグループに属していれば、普通に通信できるってだけの話

変に内部の仕組みまで理解しなければいけないって考えるから
理解できないんだよ。単に使う分には必要のない知識

使うときに必要な知識と、トラブルシューティングに必要な知識は分けて考えれ
普段使いしているときはトラブルシューティング用の知識は使わずに
Dockerで抽象化されてるものだけを考えればいいんだよ
脳容量が少ないんだから混ぜるな。混ぜるからいっぱいいっぱいになって
脳がついてこれないんだよｗ
917 ：login:Penguin：2020/08/16(日) 22:53:11.82 ID:wSm45jpn.net: >>913
コンテナ同士の通信の話では？

発端のレスは>>892
その後のレスの文脈まで踏まえるとPOD内通信と同じようにPOD間の通信もlocalhostで繋ぎたいってのがネットワークわからん派の主張
それに対して全部localhostで繋いだらわけがわからなくなるってのが俺の主張
918 ：login:Penguin：2020/08/16(日) 22:55:54.77 ID:ksz6M+9p.net: >>915
892の話してるんだろ。
「本番ではlocalhostとして接続したい」なんて言っているのは単に開発機から
本番機に移行する時の良くある無理解と思われるので、そこは触れない。
が>>892が、「ネットワークの使い方がよくわからないんだよね」と言う結論に至るのは
結局Dockerのあのダルイネットワークの仕組みのせいだろう。
919 ：login:Penguin：2020/08/16(日) 22:58:20.21 ID:+jHSMkRj.net: 話戻るけど、これほんと意味不明なんだよね

>>892
> 本番ではlocalhostとして接続したいからネットワーク名で接続し合うのはなんか違う

どこから「localhostとして接続したい」なんて要件が出てきたのやら

Docker使わずにnginx起動するとするだろ？
このnginxに「localhostとして接続したい」なんていうか？

いうなら同一マシンからなら「localhostで接続できます」だろ
違うマシンからならホスト名で接続するし
同じマシンならlocalhostで接続する。
このlocalhostもホスト名の一つでもあるんだがな

（同一マシンという）条件が揃えばlocalhostで「接続できます」という話であって
本番ではlocalhostで「接続したい」なんて要件はありえないんだが
920 ：login:Penguin：2020/08/16(日) 22:59:08.79 ID:+jHSMkRj.net: >>918
なんで引用してって書いたのに、引用しないの？
921 ：login:Penguin：2020/08/16(日) 23:00:05.84 ID:ksz6M+9p.net: >>920
何の話をしてるのさｗ？何を引用しろと言っているのｗ？
922 ：login:Penguin：2020/08/16(日) 23:01:26.08 ID:ksz6M+9p.net: >>920
あー、なんか君の言っていることが分かった気がするよ。
俺はある程度>>892の雰囲気を読んであげてるつもりだけど、
君はまるで読んであげてないんだろうね。
923 ：login:Penguin：2020/08/16(日) 23:03:53.00 ID:+jHSMkRj.net: >>918
よくわからんのはバカだから
Dockerを理解してないからだろ
924 ：login:Penguin：2020/08/16(日) 23:05:13.32 ID:+jHSMkRj.net: >>922
勝手に解釈してます。本人が言ったことと違う前提の話を
思い込みでしてますって堂々といわれてもなぁｗ
925 ：login:Penguin：2020/08/16(日) 23:05:46.12 ID:ksz6M+9p.net: >>923
それに対して俺は「もう少し工夫できんかったのか不満は多いな。」
と感想を言っている。これはDockerの役割なぞとは関係ない。
926 ：login:Penguin：2020/08/16(日) 23:06:50.06 ID:ksz6M+9p.net: >>924
まあいいよ！粘着KYは本当に雰囲気読むのが下手ね！
927 ：login:Penguin：2020/08/16(日) 23:10:35.52 ID:+jHSMkRj.net: Dockerの役割っていうのは仮想化
仮想化っていうと仮想マシン（仮想機械）のことだと勘違いしてるやつがいるが
仮想メモリと同じ意味の仮想化
実際の物理的なものを隠蔽化して仮想的なものを作り出すというしくみ

Dockerは仮想化を提供することでDocker上で動いているコンテナが
それを動かしてる物理的なインフラ（ネットワーク含む）を意識しないですむようにしている
Dockerコンテナからすればどこで動いてるかなんて意識する必要はないし
動かす方は単にDockerコンテナを起動する時にオプションを与えてるだけ
928 ：login:Penguin：2020/08/16(日) 23:10:58.23 ID:q1N0C8AL.net: ID:+jHSMkRj
罵倒マウント常習犯
NGしたいからコテハンつけてくれ頼む
929 ：login:Penguin：2020/08/16(日) 23:11:26.14 ID:+jHSMkRj.net: >>925
Dockerの役割を理解しないで
工夫しろとか言っても的外れにしかならんだろｗ
930 ：login:Penguin：2020/08/16(日) 23:12:11.71 ID:JnDBWzV6.net: >>928
IDの所にコテハンつけたぞ
これでいいか？
931 ：login:Penguin：2020/08/16(日) 23:13:05.70 ID:2XJ5NO9l.net: おっと間違えた。IDが変わってしまったぞ！
932 ：login:Penguin：2020/08/16(日) 23:38:12.89 ID:61ueIM5k.net: 過疎スレなのに盛り上がりすぎｗ
でもいいことだよ、人が増えすぎて議論もできない荒れてるスレもたくさんあるからね
C#スレみたいに
933 ：login:Penguin：2020/08/16(日) 23:44:35.52 ID:ksz6M+9p.net: >Dockerは仮想化を提供することでDocker上で動いているコンテナが
>それを動かしてる物理的なインフラ（ネットワーク含む）を意識しないですむようにしている

そのDocker自身がECSであれEKSであれ、VMの上で動いていしまっている事によって、仮想化の上に仮想化
を提供するという馬鹿げたソリューションになっている。

物理鯖の上でDockerコンテナを動かしているというならともかく、物理の上で動くVM１台の上で動くNIC
を仮想化したからと言って何の意味があるというのだ？
934 ：login:Penguin：2020/08/16(日) 23:46:45.61 ID:XQE+a9Eg.net: サーバの仮想化とアプリケーションの仮想化は別だから馬鹿げてない
ごっちゃになってるのは頭が弱いだけでは
935 ：login:Penguin：2020/08/16(日) 23:50:13.30 ID:ksz6M+9p.net: >>934
頭が弱いのはお前だろｗ
サーバーサイドで動くアプリ＝サーバーその物だろｗ
936 ：login:Penguin：2020/08/16(日) 23:56:50.89 ID:XQE+a9Eg.net: VMは文字通りマシンの仮想化
その中で動くアプリケーションと区別ができないのは頭が弱いだけでは
937 ：login:Penguin：2020/08/17(月) 00:04:49.64 ID:6a0svHoE.net: >>936
いや、間違いなく言えるのは実務と実需が分かっていないのはお前だ。
938 ：login:Penguin：2020/08/17(月) 00:05:16.09 ID:Uee87g91.net: >>933
仮想マシンの上で仮想メモリを使っていてさらに仮想化してるから
3重の仮想化だ！とか言わんの？ｗ

「仮想」の意味が全部違うのに、何が馬鹿げてるというのか
939 ：login:Penguin：2020/08/17(月) 00:06:20.27 ID:Uee87g91.net: > 物理鯖の上でDockerコンテナを動かしているというならともかく、物理の上で動くVM１台の上で動くNIC
> を仮想化したからと言って何の意味があるというのだ？

物理サーバーでもMacでもWindowsでも同じDockerイメージが動くという意味があるよ

そうだよね？違うかい？ｗ
940 ：login:Penguin：2020/08/17(月) 00:08:33.22 ID:6a0svHoE.net: >>939
MacやWindowsはサーバーにはならないよねｗ
サーバーの話してるんだがｗ
941 ：login:Penguin：2020/08/17(月) 00:09:40.22 ID:rfbLt2Qd.net: なるでしょ
ならないと思い込んでるのは頭が弱いだけでは
942 ：login:Penguin：2020/08/17(月) 00:09:45.93 ID:PKLBL3Xf.net: >>940
つまりサーバー以外で意味があると認めたということ？
サーバー限定にしないと、言い返せない？
943 ：login:Penguin：2020/08/17(月) 00:10:56.70 ID:6a0svHoE.net: >>938
仮想メモリの意味をまず理解しろよｗ
意味不明すぎだろｗ
944 ：login:Penguin：2020/08/17(月) 00:17:02.97 ID:6a0svHoE.net: >>934
>サーバの仮想化とアプリケーションの仮想化は別だから馬鹿げてない
>ごっちゃになってるのは頭が弱いだけでは

君の言うようにサーバーの仮想化とアプリの仮想化が別で、Dockerが提供しているのがアプリの仮想化と言うのなら、
>>927が言うような「物理的なインフラ（ネットワーク含む）を意識しないですむようにしている」を提供する必要は無いよな？
アプリにとってインフラは関係ないし。でも現実には提供してるよな？つまりDockerが提供してるのはサーバーの仮想化含めてるよな？
にも関わらず下にVM無きゃ動かないというのは、詰る所、Dockerが不完全だからって事にしかなってない
一体何時VMから独立してくれるんだとｗｗ
945 ：login:Penguin：2020/08/17(月) 00:19:53.03 ID:PKLBL3Xf.net: 次スレ

Docker Part4
https://mao.5ch.net/test/read.cgi/linux/1597591176/
946 ：login:Penguin：2020/08/17(月) 00:22:25.35 ID:7e1FicdI.net: >>944

> >>927が言うような「物理的なインフラ（ネットワーク含む）を意識しないですむようにしている」を提供する必要は無いよな？

あるだろ。というかそれこそが重要なことだろ
アプリにとってインフラは関係ない

関係ないというのは、どういう構成でのインフラでも動くということ
つまりインフラ（物理サーバーやネットワーク）の違いを吸収するそうが必要

それをDockerが提供している

> 下にVM無きゃ動かないというのは、
LinuxでVMは必須じゃない

VMを使ってもVMを使わなくても、同じDockerイメージが動く
それはDockerがその違いを吸収してアプリからすれば全く違いがないからだ
947 ：login:Penguin：2020/08/17(月) 00:25:33.61 ID:7e1FicdI.net: 例えばapacheとngixの2つのhttpサーバーを起動する時
どちらもポート80番を使っていれば起動できない

同じDockerイメージを使うということは
どちらも同じ80番ポートを使うかもしれない
他のDockerイメージが使ってるポート番号なんて知る余地がない

だからDockerでは、Dockerイメージがポート80番を使っていても
Dockerサーバーの力で、そのポート番号のリマップを行っている

その他のいろいろなリソースに対しても同じでリマップの機能を提供している
これがDockerがもつ仮想化という機能の本質
948 ：login:Penguin：2020/08/17(月) 00:31:00.28 ID:7e1FicdI.net: Linux上でDockerはVMなしで動くに
このアホは何を言ってるんだ
アーホ
949 ：login:Penguin：2020/08/17(月) 00:35:04.91 ID:6a0svHoE.net: >>946
>つまりインフラ（物理サーバーやネットワーク）の違いを吸収するそうが必要

普通それを「アプリの仮想化」とは言わない。

>LinuxでVMは必須じゃない

そのLinuxはVMとして動いているだろ。EC2のインスタンスなんだから。
950 ：login:Penguin：2020/08/17(月) 00:36:03.34 ID:6a0svHoE.net: >>948
本番機じゃそのLinuxがVMだっつーの！
951 ：login:Penguin：2020/08/17(月) 00:40:44.05 ID:7e1FicdI.net: >>950
本番機がVMなのはお前の場合の話だろ
Dockerイメージはどこでも動くんだから
その証拠の一つが「VM上でも動く」だろうが
アーホ
952 ：login:Penguin：2020/08/17(月) 00:46:44.44 ID:7e1FicdI.net: >>949
> 普通それを「アプリの仮想化」とは言わない。

じゃあ何がアプリの仮想化なのか言ってみ

仮想化の意味を知らんやつが多いよな
仮想メモリ（技術）の仮想化とはなにを仮想化しているのか？

物理 → 技術 → 仮想 → アプリ

このように技術、テクノロジーによってによって
アプリから物理的なものではなく仮想化されたものを見せてる
それが仮想化の意味だよ

・物理メモリ → 仮想メモリ技術 → 仮想メモリ → アプリ
・物理マシン → 仮想マシン技術 → 仮想マシン → アプリ実行環境（OS）
・アプリ実行環境（OS） → アプリ仮想化技術（Docker） → 仮想化されたアプリ実行環境 → アプリ

こういう流れな
アプリ実行環境、インフラが異なっていても
Dockerによって全く同じインフラで動いているように見える
それがアプリ仮想化技術
953 ：login:Penguin：2020/08/17(月) 00:47:13.19 ID:6a0svHoE.net: >>951
実務やらない馬鹿に話すのはマジ疲れるなｗ
クラウドで何かのサービスを提供している法人の3社に1社はアマゾン。
君はそれ以外を使ってるのw？
多分家で引きこもって碌でもない事ばかりしてるから、こういう話にピンとこないんだろう？
で無きゃここ迄、話がずれることは無いｗ。
この話にピンとこないって何でよ！？
954 ：login:Penguin：2020/08/17(月) 00:50:52.58 ID:7e1FicdI.net: >>953
お前の手元のノートパソコン、MacBookは
AWS上で動いてるのかよｗ
955 ：login:Penguin：2020/08/17(月) 01:00:10.28 ID:snyUoRs2.net: アプリ仮想化（）
名前空間で区切ってるだけだぞ
956 ：login:Penguin：2020/08/17(月) 01:04:56.58 ID:6a0svHoE.net: >>952
>じゃあ何がアプリの仮想化なのか言ってみ

https://it-trend.jp/desktop-virtualization/article/249-0009

そもそもアプリの仮想化という言葉はIntelがVT-xを実装した時に「OSの仮想化/アプリの仮想化/デスクトップの仮想化」とセットになって出てきた言葉。
OSの仮想化はVMware ESXi(Hyper Visor）とかMS Hyper-Vの事。OSそのものを仮想化する
アプリの仮想化とはあるアプリを異なるOSで動かすこと。（これが出てきた時に著名になったのはWindows7の頃で、7上でXPでしか動かない筈のIE6が動いていた）
Dockerに例えればカーネルを共用したOSの中でhttpd等のパッケージを、管理システムも含めて「アプリの仮想化」することによって、さまざまな環境として動かしている。
この点は確かに「アプリの仮想化」と言える、が、デバイスの管理を含めるなら、やはりOS仮想化の範疇となる。

>仮想メモリ（技術）の仮想化とはなにを仮想化しているのか？

この点以下の君の記述はコメント不能。パラノイアすぎる。
多分色々な物を大きく誤解している。

物理 → 技術

技術ってなんだよｗ
957 ：login:Penguin：2020/08/17(月) 01:08:46.77 ID:7e1FicdI.net: > そもそもアプリの仮想化という言葉はIntelがVT-xを実装した時に「OSの仮想化/アプリの仮想化/デスクトップの仮想化」とセットになって出てきた言葉。

それとDockerが言ってる言葉の意味が違うってことぐらいわかるよね？ｗ
958 ：login:Penguin：2020/08/17(月) 01:09:33.57 ID:7e1FicdI.net: 言葉の意味をわかってないから、こうやって別の用語とごっちゃにするわけだ
まぬけやなー
959 ：login:Penguin：2020/08/17(月) 01:11:13.49 ID:6a0svHoE.net: >>954
さーばーさいどのはなしをしているって何度言っても理解せんのねｗ。
君の脳みそは。
いいか！？本番機を単なるVM上にインストールしたhttpdと
単なるVM上にコンテナランタイムを動かして更にその上にインストールしたhttpdは
どっちが管理が大変か理解できるか？後者の方が大変だろ？当然の話として。
（これが分からなんならもう俺に話しかけるな。）理解できるか？？
だから、コンテナとしてのメリットを謳うならそれ以上のメリットが無ければならないわけだ
それが無いと言っている。少なくとも一般的な情シス部門を納得させるだけの何かが足りないと言っている。
960 ：login:Penguin：2020/08/17(月) 01:14:27.70 ID:6a0svHoE.net: >>957
当然だろ。別にこれは俺が言い出したことでは無いから。
そもそも、Dockerはアプリの仮想化じゃないし。
>>934がこう言っているから、概念に当てはめて、返しているだけだろ。
961 ：login:Penguin：2020/08/17(月) 01:31:05.43 ID:7e1FicdI.net: > さーばーさいどのはなしをしているって何度言っても理解せんのねｗ。

なんでサーバーサイドに限定しないと、何も言い返せないんですか？
開発はサーバーサイドでしてるんですか？

あ、よくあるインフラ専用の人かｗ
自分で開発してないからDockerの本質、Dockerが何を解決しているかをが理解できないのね
962 ：login:Penguin：2020/08/17(月) 01:33:45.69 ID:7e1FicdI.net: httpdサーバーをDockerで～なんて言ってる時点でわかってないわ
やらないことはないけど、本来は自分（たち）で作ったアプリを配布するためのものなのに

コンテナを使うとインフラ担当者にDockerイメージ作ったからこれ動かしてっていうだけで動く
Dockerの技術によって環境が仮想化されてるからね
どこでも動くDockerイメージを作れる
963 ：login:Penguin：2020/08/17(月) 01:37:10.87 ID:7e1FicdI.net: 例えばRailsでブログアプリを作ったとする

Dockerイメージ作ったからこれ動かして！
これだけで動くことが出来る
せいぜい起動するときの環境変数を伝える程度

これがDockerを使わないと
Rubyのバージョンは？必要なライブラリは？
デプロイの手順は？などいろいろ伝えることになる

Rubyのライブラリの最新バージョン使ってるんだ。
え？構築したサーバーではパッケージがない？知らんがな。
そういうのを入れるのもインフラの仕事だろ？お前が頑張れや

こういう大変な管理をなくすのがDocker
それがわからんならもう俺に話しかけるな
964 ：login:Penguin：2020/08/17(月) 01:50:46.93 ID:6a0svHoE.net: >>962 >>961
その用途は、コロナのせいではなく、単に失業しているせいで外に出られない、君のとても狭い
世界の用途だ。多分君は趣味で（恐らく一人で）開発を行いDockerに入れ込んで喜んでいるのだろう。
君が理解している本質とやらは、君の、小さな小さな脳みそでのみ使用可能な「本質」でしかない。
広い世界では勿論、それ以外にDockerの「本質」は存在する。

アプリの配布という用途は、無いことは無いし俺も趣味ならそれで遊ぶこともあるけど、
一般的なエンジニアが「仕事」として興味を持つのはTCOを下げたりROIを上げる為であり
ここでまともな質問をしているのは、そういった人達だ。

顧客に提案したいけど、何を売りにすれば良いか迷ってるとかな。そんな人たちに向かって、君の小さな小さな
知識で（おまけに上から目線で）答えられると、大変な迷惑になっていることを自覚した方が良い。
そして就職して、同僚がどの様にDockerを使っているのか、周りを見てみた方が良い。

君の理解している用途で使用しているのは１０から２０あるプロジェクトの１つか２つでしかない事が分かるはずだ。
965 ：login:Penguin：2020/08/17(月) 01:59:15.82 ID:7e1FicdI.net: >>964
その内容と同じことを言ってるサイトを
ググってきてみつっけてきてください
そうすれば信じてあげましょう
966 ：login:Penguin：2020/08/17(月) 02:04:38.89 ID:6a0svHoE.net: >>965
いやｗ就職しろよｗ
みんなマジでアプリの配布なんて用途で使ってないからｗ
967 ：login:Penguin：2020/08/17(月) 02:08:19.35 ID:7e1FicdI.net: なんだろうね。働いてないはずだ！という思い込みで勝ったつもりになるのってｗ
それで同じことを言ってるサイトは？
また逃げるの？何回目かな？
968 ：login:Penguin：2020/08/17(月) 02:09:08.49 ID:7e1FicdI.net: アプリの配布

GitLab Docker images
https://docs.gitlab.com/omnibus/docker/
969 ：login:Penguin：2020/08/17(月) 02:27:28 ID:6a0svHoE.net: >>967
OK！分かったよ、じゃあ君の職場でどうやってDocker使っているか教えてくれ。
俺の所じゃ、200人いる開発者は全員Dockerで開発してはいるものの、開発機/検証機/本番機は
８割方VMだ。開発した成果物をgithbubに入れてVMにDeployerでデプロイって形だ。
だからDockerを「アプリの配布の為」に使っている訳じゃないのは明らかだ。
本番機をコンテナ化、マイクロサービス化ってのは諸所の事情でなかなか進まない。
君が同業ならその辺の事情は察することが出来るはずだ。

・・・・・・で、君の会社はどうなんだい？
社員全員が「アプリの配布の為」に使っているのかーーーいｗ？
970 ：login:Penguin：2020/08/17(月) 02:42:49.62 ID:7e1FicdI.net: >>969
開発したアプリをDockerイメージにしてGCPの
GKE (Google Container Engine）で動かしたり
GCEインスタンス起動時の設定にある
コンテナイメージに指定したりしてるが？

それでお前と同じことを言ってるサイトは？
答えないんだね。逃亡回数＋１しといたからねｗ
971 ：login:Penguin：2020/08/17(月) 03:07:51.00 ID:6a0svHoE.net: >>970
OK、OK！で、その規模はどれ位だい？
サーバーは何台だい？
社員は何人？エンジニアの数だけで良いよ。
会社のサービスは完全にコンテナだけで運用しているのかい？
もしそれなら相当、凄いぞ。社員130人台のはてなでさえ、k8sは撤退してるからな。
因みにGKEは(Google Kubernetes Engine）で全然Containerとは違うからな。
その意思決定に至ったのは本当に「アプリ配布の為」かい？
ウチはマイクロサービスへの移行が意思決定の理由だったな。

因みにウチの鯖はメインサービスのWebサーバーが5台、Socketサーバー16台
サブがWeb4台、Socketサーバ6台、AサービスWeb4台
解析用4台、その他諸々で多分全部で60台位だ。
10台位が多分ECS/EKSで運用していると思う。
細かい内訳は分からない。

>それでお前と同じことを言ってるサイトは？

いや俺の回答が全てだろ。
200人いる社員がそんな用途で使ってないんだから。
972 ：login:Penguin：2020/08/17(月) 03:19:03 ID:snyUoRs2.net: >>969
レジストリを活用すると世界感がかわるよ
開発した成果物(image)をレジストリにpush
レジストリから実行環境にpull
この2アクションが基本形
Deployerとやらが内部で何をやってるかは知らないけどそれがpush/pullに置き換えられるならもっと簡単になる
973 ：login:Penguin：2020/08/17(月) 03:22:47.57 ID:6a0svHoE.net: >>972
>レジストリを活用すると世界感がかわるよ

そんな事は当然やってるよ。
974 ：login:Penguin：2020/08/17(月) 03:29:54.77 ID:snyUoRs2.net: >>973
既にやってるってことはつまりイメージ配布に頼ってるってことでは
デプロイ先はVMでDockerは使ってないとの書き込みはなんだったの
975 ：login:Penguin：2020/08/17(月) 03:34:43 ID:6a0svHoE.net: >>974
>>969に書いているんだが。
日本語読み取れない人は答える必要は無い。
976 ：login:Penguin：2020/08/17(月) 03:37:23 ID:6a0svHoE.net: >>970
まあ！とりあえず君の会社の事を書いてくれよ！
俺と話が噛み合わない理由は、間違いなくそこにあるね！
977 ：login:Penguin：2020/08/17(月) 03:41:02 ID:snyUoRs2.net: >>969

> >>967
> ８割方VMだ

2割はDockerでイメージ配布に依存してるってことでいいの？
978 ：login:Penguin：2020/08/17(月) 03:46:26 ID:6a0svHoE.net: >>977
いやその前に違う事を書いているはずだが。
君は>>970と別人かい？じゃあ君も会社の事を書いてくれよ。
まずはそれからだな。
話が何でかみ合わないのかさっぱり分からないｗ
多くのエンジニアが抱えている問題は共通の筈なんだがｗ
979 ：login:Penguin：2020/08/17(月) 03:51:43.70 ID:snyUoRs2.net: >>978
たとえ大した情報でないとしても会社の情報を無闇に公開すべきでないという社会常識に則ってここでは話さないほうがいいとおもう
いちおうあなたも社会人なんだよね？

それに会社のシステム構成がなければ議論できないような内容でもない
ということも多少の理性があれば理解できるはず
980 ：login:Penguin：2020/08/17(月) 03:55:34.64 ID:6a0svHoE.net: >>979
いやそんなことは無いな。
話がかみ合ってないなと思えば、フェイクでも良いから何か言いうだろ？
もし言わないというのなら、君は俺との違いを理解できているはずだし、それに納得した
という事だよな。だから、今後dockerの役割はアプリの配布なんていう事も無い。
それで良いかい？
正直君がずーーーーーとこのスレでそのおかしな主張を続けているから
マトモなエンジニアと会話が出来ずに大変迷惑している。
981 ：login:Penguin：2020/08/17(月) 03:59:31.33 ID:snyUoRs2.net: ようするに

・システム構成のうち何割かが非Docker環境である
・これらをDocker環境へ移行することは諸事情により難しい
・残りの何割かはDocker環境である

という環境を想定していて

・Docker環境へのデプロイはイメージ配布に依存している(当たり前だが)

ということでいいんでしょ？

違うならもう少し正確な日本語で書いてほしい
正直に言うとあなたの文章は読みにくく意図が伝わりにくいです
982 ：login:Penguin：2020/08/17(月) 04:00:48.31 ID:snyUoRs2.net: ちなみに自分は>>970ではないのでずっと居座ってはいません
983 ：login:Penguin：2020/08/17(月) 04:01:23.65 ID:6a0svHoE.net: https://mao.5ch.net/test/read.cgi/linux/1597591176/

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

おいおい勝手に決めるなよ
なってねーよｗ
やっぱ一人の世界で完結してる奴は世界がせめーなｗ
984 ：login:Penguin：2020/08/17(月) 04:04:52.99 ID:snyUoRs2.net: 次スレ乙です
985 ：login:Penguin：2020/08/17(月) 04:05:23.51 ID:6a0svHoE.net: >>982
いや、君は十分ずっと居座ってるぞｗ
おかしな書きっぷりも970によく似てる。
で、君は>>970に同意なのかい？
Dockerとはアプリを配布する事が目的である、と。
986 ：login:Penguin：2020/08/17(月) 04:09:22.58 ID:snyUoRs2.net: >>985
アプリ配布はDockerの役割の1つであると言ったほうが正確
987 ：login:Penguin：2020/08/17(月) 04:10:06.96 ID:6a0svHoE.net: >>981
俺の書き込みは、それが主眼では無いから。
大体のシステムの規模を言って、この環境で運用している自分は
DockerとはXXであると考える。
Dockerの目的が「アプリの配布」と考える君はどの程度の会社に
所属しているのかい？って話だから。
でないと何故かみ合わないのか焦点は何なのかさっぱり分からない。
988 ：login:Penguin：2020/08/17(月) 04:14:47.27 ID:6a0svHoE.net: >>986
じゃあ、970と主張は違う、って事でOK?
俺はこいつが何故、この主張をずーーーと続けるのか。
何時になったら引っ込めるのか、という事に興味があるだけだから。
でないと、話がいつまでたっても先に進まない。
こいつが話に絡んでくると毎回結論が同じになる。
989 ：login:Penguin：2020/08/17(月) 04:24:41.13 ID:snyUoRs2.net: >>987
私とあなたの話が噛み合わない理由は簡単だと思う

あなた：
Dockerの役割とは〇〇である(〇〇にはアプリ配布以外のナニカが入る)
したがってDockerの目的はアプリ配布ではない

私：
Dockerの目的は様々あってそのうちの1つがアプリ配布である

つまりあなたはDockerの役割をアプリ配布以外の何か1つに絞り込もうとしている(少なくともあなたのレスを読む限りはそう読める)
私はそうではなくDockerの役割は複数あってアプリ配布はそのうちの1つだと考えている

これでは話が噛み合わない
990 ：login:Penguin：2020/08/17(月) 04:28:57.03 ID:snyUoRs2.net: >>988
レスぜんぶ読んだわけではないので>>970の真意はわからないと前置きして

もし>>970の主張がDockerの役割はアプリ配布ただ1つであるという意味なら私の意見とは異なる
アプリ配布は役割の1つでしかないという意味なら同じ
991 ：login:Penguin：2020/08/17(月) 04:40:21.92 ID:6a0svHoE.net: >>989
違うよ。
>>970
Dockerの役割はアプリの配布ただ一つである。

俺：
そんなことは無い。色々ある。

でかみ合ってない。969以降の書き込みは何故かみ合っていないのかの
認識の祖語を埋めるためだけにある。君の主張が俺と同じなら、964以降
の書き込みに反応する必要は全くないよ。
992 ：login:Penguin：2020/08/17(月) 04:42:05.95 ID:6a0svHoE.net: おまけに誰が建てたのか、
https://mao.5ch.net/test/read.cgi/linux/1597591176/

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

www本番機をコンテナに移行してない企業はどうなってんのさｗ
何故このスレはこんなに訳の分からない結論を出す馬鹿ばっかりなのか。
>>651でデプロイの存在を教えてあげているのに全く学習出来てない。
993 ：login:Penguin：2020/08/17(月) 04:49:03.84 ID:snyUoRs2.net: >>991
> 色々ある
色々の中にアプリ配布も含まれているということなら合意ですね
994 ：login:Penguin：2020/08/17(月) 04:58:43 ID:6a0svHoE.net: >>993
OK,じゃあ君との話はこれで終わりな。
後は>>970のレスポンスを待つだけだ。

出来れば、Part4立てた奴の脳味噌の中も割ってみたいけどｗ
マジで半年前に終わった話なのに話題が全く進まねー。
995 ：login:Penguin：2020/08/17(月) 07:39:36.36 ID:7e1FicdI.net: >>971
その質問の意図が全くわからん
マウント取ろうとしてるだけだろ

> いや俺の回答が全てだろ。
お前と同じことを言ってるサイトはないってことでいい？
996 ：login:Penguin：2020/08/17(月) 07:46:49.32 ID:7e1FicdI.net: 今どきDeployerとかいってるのは
夜間メンテナンスでドキドキしながら作業してるんだろうな
本番環境と同等の環境を作って
事前にちゃんと動くかテストして
でも本番環境全く同じとは限らない

夜間に実行して、ちゃんと動くかドキドキ
あれ？なんか異常が起きてる？
朝までに直さなきゃ！

Dockerだと事前に動作するとわかってる
イメージのプルと実行だけでいい
書き換えるものはすべて書き換え済みなので
安心して更新できる
997 ：login:Penguin：2020/08/17(月) 08:30:59.58 ID:6a0svHoE.net: >>996
それはお前の妄想の中にだけある問題だ。
現実にはそんな事は、ただの一度も無い。
マジで、実務に携わってないならDockerスレに来るなよ。
何度も言うが、君の妄想書き込みは大迷惑だ。
全く実務に即してないから。
まあ、それは良いよ。
君は>>993に同意かい？そうでないなら君の職場環境書いてね。
認識の祖語は100%そこだから。
よろぴく。
998 ：login:Penguin：2020/08/17(月) 08:34:27.78 ID:7e1FicdI.net: また聞くね。逃げないでね

お前と同じことを言ってるサイトはないってことでいい？
999 ：login:Penguin：2020/08/17(月) 08:35:30.00 ID:7e1FicdI.net: こいつ、どうもDocker自体の役割と、
Dockerを使うシステム（GKE等）の役割を
ごっちゃにしてるみたいなんだよなｗ
1000 ：login:Penguin：2020/08/17(月) 08:38:01.24 ID:7e1FicdI.net: なぜかというと、GKEを選んだ理由は～とか言ってるから

> 因みにGKEは(Google Kubernetes Engine）で全然Containerとは違うからな。
> その意思決定に至ったのは本当に「アプリ配布の為」かい？

この場合、GKE（に相当するECS/EKS）を選んだのがお前であってDockerを選んだのがGKE
なぜか？コンテナを動かすだけで動くシステムが出来るから。
動くシステムの配布方法としてDockerが優れているからGKE等が採用したわけ
1001 ：2ch.net投稿限界：Over 1000 Thread: 2ch.netからのレス数が1000に到達しました。

総レス数 1001
365 KB

掲示板に戻る全部前100 次100 最新50

read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★