[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1(1): 2019/03/08(金)14:40 ID:VDOvuQ0J(1) AAS
LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。
外部ﾘﾝｸ:www.docker.io
前スレ
Docker Part2
2chｽﾚ:linux
2: 2019/03/22(金)00:33 ID:FiEMLtVp(1) AAS
systemd nspawnがOCIに対応したらしい
3: 2019/03/22(金)14:39 ID:sUNkazjD(1) AAS
外部ﾘﾝｸ[php]:www.phoronix.com
コレか
4: 2019/05/23(木)01:59 ID:0pxAwTtK(1/2) AAS
古いノートパソコンがあるからそれにLinuxを入れてdocker動かしたい。
どのOSがおすすめ？k3s?
外部ﾘﾝｸ:github.com
これも気になるけど、こいつはdockerで使うもの？ホストマシンに入れたいけどなんか違う気がしてる。
5(1): 2019/05/23(木)03:04 ID:d64XEyeT(1) AAS
Ubuntu
だいたいな、Dockerは動かすものじゃない。
自分でDockerイメージを作るものだ
アプリを開発する人じゃないと使う意味がない
6(1): 2019/05/23(木)10:32 ID:9kisAx48(1/2) AAS
>>5
>>5
アプリ開発してるよ。普段使ってるのはdocker for macだけど。
古いノートパソコンがあるからLinuxをいれてそこでdocker動かしたい。もっというとkubernetesを試したいんだけどね。
ubuntuはたしかに便利だけどもっと軽くておすすめないかな
7(1): 2019/05/23(木)11:14 ID:m2jrTB8O(1) AAS
ローカルでkubernetes使ってなんか意味あるのか
8(1): 2019/05/23(木)18:45 ID:vAmYTtLD(1) AAS
>>6
Xubuntuはいかが？
外部ﾘﾝｸ:eng-entrance.com
9(1): 2019/05/23(木)20:44 ID:9kisAx48(2/2) AAS
>>8
guiは使いたくないです。
10(1): 2019/05/23(木)21:03 ID:DjEk8nIP(1) AAS
>>9
どうせTeratermとか使ってるんだから変なことにこだわるな
11: 2019/05/23(木)23:33 ID:0pxAwTtK(2/2) AAS
>>10
cui使っている人のほうがこだわるでしょ。
同じことをするなら少ないリソースでやろうとするのが技術者じゃないの
12: 2019/05/24(金)00:19 ID:3Aok0K9B(1) AAS
今時は同じことするなら少ない工数でやるのが偽術者
13(2): 2019/05/26(日)14:39 ID:flLvlSMX(1) AAS
dockerについて勉強したいんだけどなんかおすすめのサイトとか本ある？
14: 2019/05/26(日)20:43 ID:Kq/a2mQk(1) AAS
Qiita
15: 2019/05/30(木)20:42 ID:q2WZulpZ(1/2) AAS
>>13
外部ﾘﾝｸ:knowledge.sakura.ad.jp
Qiitaはクソ記事多いから気をつけて。
↑で手を動かしたら公式を読むようにした方がいい
16(1): 2019/05/30(木)20:45 ID:q2WZulpZ(2/2) AAS
>>7
利点が何もわかってないのな
17: 2019/05/31(金)07:28 ID:iKwtdlg1(1) AAS
>>16
説明して
18: 2019/06/15(土)23:27 ID:Fpt7udoK(1) AAS
>>13
意味があるDockerの記事を読む。
19(1): 2019/06/30(日)20:47 ID:EAn/wuc6(1) AAS
たとえばどれ？
20(2): 2019/07/01(月)21:57 ID:Wo8yzhSo(1) AAS
Kubernetesって1GBのメモリじゃ動かない？
AWSのt3.microインスタンスで
nginx動かしたりしただけでフリーズした
21(1): 2019/07/02(火)15:24 ID:LdECflCw(1) AAS
>>20
動かないんじゃないかな。
1年ぐらい前だけど調べた時に、1.7GB？ぐらいの
メモリを使用していた気がする。
あれから変わってるだろうし、記憶が曖昧だけど
Kubernetes使うのに躊躇するぐらいのメモリ使用量だった。
k3sならメモリ使用量少ないみたいね。
22: 2019/07/03(水)08:09 ID:OU4jXyIu(1) AAS
>>21
ありがと
2GBのインスタンスタイプに変えてから再起動して
nginxだけじゃなくダッシュボードも動かしたが
それで既に700MB近かった
ちょっと他のが入ったら1GBでは足りなくなりそうだった
素のk8sでは2GBは最低必要か
k3sは噂には聞いてるが試したことない
試してみるか
23(1): 2019/07/21(日)13:52 ID:Lry58weg(1/2) AAS
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: 2019/07/21(日)13:54 ID:Lry58weg(2/2) AAS
追記：冒頭の日本語おかしくてスイマセン…あと今回使っているimageは全てdocker hubからpullしました
25: 2019/07/21(日)14:41 ID:Sr2KiGug(1) AAS
echo Hello Docker!
ぐらいしか出力しない image で、
ローカルでもリモートでも、
確実にやろうと思っていることが動かすことができますか？
それから、本当に動いているのでしょうか？
何を根拠に正常と判断していますか？
1セグメント内でサーバー群の保守運用は十分にできますか？
また、何をやろうとしているかアレですが、
docker-compose でやったほうが整理できませんか？
もっと大規模なネットワークだったら、k8s とか mini k8s とか。
がんばってください！
26: 23 2019/07/22(月)20:10 ID:wJonFK+K(1) AAS
自己解決しました
portainerのデプロイが駄目っぽいのでCLIでデプロイ後、管理をportainerに渡す構成でうまく行きました
27(2): 2019/07/23(火)19:16 ID:uUJhaBng(1) AAS
初心者です。
データ分析ツールの宿題が出されたのですが、Docker上に環境構築するところからやらないといけないのですが、どのように構成させればいいかわかりません。
Docker上にはDWH(ポスグレ)、ETL(Python)、Datamart(ポスグレ)、Application(apache+php)をのせるような絵が書いてありました。
これを実行する環境を作るためには、databaseサーバとしてポスグレ、Applicationサーバとしてphpとpython、webサーバとしてapacheみたいな構造のdocker composeを設定すれば良いのでしょうか？
初歩的な質問で恐縮ですが、教えていただければ助かります。
youtubeやhpを見てもイマイチ、自分のやろうとしていることとの紐付けがわからなくて、みなさんにお聞きしようと思いました。
どうか、助けてください。
28: 2019/07/23(火)21:15 ID:Xx2hBpa5(1) AAS
授業か演習の時間にdockerの動作サンプルは提供されなかったの？
もしされてないのなら教員かTAに提供を要請したら？
29: 2019/07/24(水)01:18 ID:dso6mLCs(1) AAS
>>27
まずは、それを1台のサーバ上で自力で構築できるかどうか。
それすらできないのであれば、docker-compose なんか、できっこない。
30: 2019/07/26(金)04:44 ID:fX9V96gJ(1) AAS
宿題は自分でやらないとだめだろう。
質問も適切であれば、教師が答えてくれるはず。
31: 2019/08/17(土)13:47 ID:/e3AaJxo(1) AAS
Dockerの中からホストos(PC)に繋がってるUSB機器は
使える
使うようにすることができる
使えるが困難な作業付
使えない
どれだろうか
32: 2019/08/18(日)01:14 ID:MPbnMgbj(1) AAS
キーボードは使えるだろ
33: 2019/09/05(木)04:42 ID:l43Efl7g(1) AAS
>>27
授業まともにこなしてないからだろ
レポート提出前にいきなり焦っても駄目
学生向けの課題にこれまでやってないことをいきなりやらせるはずない
その単位は来年取りましょう
34: 2019/10/09(水)14:49 ID:xRhiurY2(1) AAS
k8sって、masterとworkerを同じ仮想マシンにすると
負荷かけ過ぎた時にクラスタが操作不能になる？
仮想マシンを再起動しても保存されたデプロイメントとかの設定から
また同じコンテナが立ち上がって操作不能になる
シングルノードで開発はむずい
35: 2019/10/09(水)23:40 ID:a5NgKSTJ(1) AAS
ラズパイでも使って小ノード作るべきでは
36(2): 2019/10/15(火)09:25 ID:ZqB99mPI(1/2) AAS
dockerにwinxp入れて古いゲームできますか？
37(1): 2019/10/15(火)10:16 ID:YE1RLI0J(1) AAS
まずdockerの構造を理解してください。
外部ﾘﾝｸ:www.google.comとは？
38: 2019/10/15(火)10:45 ID:ae5FC9b4(1) AAS
>>36
まぁ、せいぜいがんばってくれたまえ！
39: 2019/10/15(火)11:44 ID:N0h53sSf(1) AAS
GUIとか犬糞以外のOS走らすのは?っしょ
40: 2019/10/15(火)16:46 ID:ZqB99mPI(2/2) AAS
>>37
使用用途が全然違うわ
できんわ
41: 2019/10/15(火)21:27 ID:qoE8jSef(1) AAS
Windows10Proでdocker動かして、windowsXPのコンテナを動かすんでしょ。
42: 2019/10/16(水)00:41 ID:09Dygszb(1) AAS
>>36
windowsをdockerで動かすだけでもドライバ周りが地獄。
ゲーム入れたコンテナも作れるが、セーブやコンフィグデータを外に逃がす必要があり、これも難易度高い。
VMwareなどのバーチャルマシンでやる方が格段に楽
43: 2019/10/20(日)10:45 ID:q6u5AcUs(1) AAS
dockerでvirtualbox動かしてwin載せたりするのか
44: 2019/10/21(月)15:57 ID:pPKurgXC(1) AAS
外部ﾘﾝｸ:stackoverflow.com
VirtualBox inside docker
出来なくは無いようだが
意味あるのか？
ホストOSで動いてる物に色々依存してるし
普通にインスコすれば良いじゃん？
45(3): 2019/10/27(日)02:04 ID:gxVXDEx+(1/4) AAS
dockerってのはVMに対して何のメリットが在るのかサッパリ分からん。
海外のオープンソースソフトにはセットアップ面倒くさいやつは5G位の
ovaファイルとかドカンと置いているのがあって、DLさえすれば完全な
環境で動く奴が在るけど、何故それではなく、Dockerの方が良いのか
と言う説明は誰もしない。
46(1): 2019/10/27(日)02:14 ID:t/s2evSD(1/2) AAS
>>45
Kernelをホストと共有するので、
余計なKernelのメモリ使用がない。
Kernelの起動終了を待たなくていいので、
起動終了が速い。
47(1): 2019/10/27(日)18:00 ID:gxVXDEx+(2/4) AAS
>>46
メモリなんて今時別に気にする必要ないだろ？
16Gも積んでれば4、5台上げても何てことは無い。
48(1): 2019/10/27(日)19:07 ID:t/s2evSD(2/2) AAS
>>47
4-5台で済むわけないでしょ、
64コアとかのCPUが普通に売ってるんだから、
サーバーも20台30台統合することを想定している、
するとKernelのメモリが無視できなくなる
49: 2019/10/27(日)20:17 ID:fa4qpzOv(1) AAS
スケールしやすいから
50: 2019/10/27(日)20:48 ID:bZSAAJ4S(1/2) AAS
小さくて速いのかメリットじゃないって正気？
51(2): 2019/10/27(日)21:11 ID:bZSAAJ4S(2/2) AAS
dockerは軽量なだけでなく、配布の仕組みが標準化されていて
仮想マシンと言うより
どのLinuxでも動くパッケージマネージャーの代わりのように使える
docker pullしてくればすぐに起動して使える
自分のコード追加してdocker pushして再配布も簡単
特定の仮想マシン向け、例えばVirtualBoxにイメージ作ったら
その仮想マシンでしか動かないじゃん
カーネルを含めず
その上で動くソフトウェアだけを確実にどのLinuxにも持っていける仕組みがあれば
という問題をDockerが解決した
52(1): 2019/10/27(日)21:37 ID:bwtjYyKj(1/2) AAS
5Gバイトはダウンロード結構掛かるから
53(1): 2019/10/27(日)21:43 ID:WoCgnioW(1) AAS
小さくて早いって言ったって、他への依存度が少ないほうが良いじゃん
と思ってVagrant使ってた。
試しにdocker使ってみて圧倒的な速さにdockerシフト。
まぁLinuxメインの人ってWindows上でも動かそうとか考えないしな。
ライブラリ、デーモン依存のところだけ解決できるコンテナはちょうどいい感じなんだよ。
54: 2019/10/27(日)22:54 ID:bwtjYyKj(2/2) AAS
lxdと組み合わせるとかなりいい
55(1): 2019/10/27(日)23:28 ID:xLMpHebH(1) AAS
>>45
そのメリットが理解できないのであれば、
それでいいんじゃない？
まぁ、せいぜいがんばってください！
56(1): 2019/10/27(日)23:48 ID:gxVXDEx+(3/4) AAS
>>55
>>51見たいな回答が出来るなら、参考にもなるけど
この書込みじゃ何の役にもたたんな。
まぁ君自身理解できてないのだろうけど。
君が流行で使っても何も恥ずかしくは無いよｗ
>>48
20台も30台も作る前に普通何か工夫するだろ？
>>51
唯VMにしてOSのバージョンレベルで固めていれば
VM->開発機->検証機->本番機の全ての環境が
全く同一に作れるからね。
Dockerでおかしな作り方したら本番機ではパス違ったとかなるとダルい。
57: 2019/10/27(日)23:49 ID:gxVXDEx+(4/4) AAS
>>53
Vagrant使うくらいなら確かにdockerの方が良いね。
58(1): 2019/10/28(月)00:05 ID:jxo+K6ql(1) AAS
Dockerあればパッケージマネージャーの代わりになるから
パッケージマネージャー要らないじゃん！って事で
パッケージマネージャーを無くして
/usrとかのパスをリードオンリーにしたのがCoreOS
OSアップデートはOSイメージ丸ごと入れ替えで行うっぽい
59: 2019/10/28(月)00:06 ID:BSt0sMZd(1/5) AAS
>>52
5Gなんて今時fullHDの動画ひとつでもそれ位在るだろ？
60(1): 2019/10/28(月)00:12 ID:U3p6V+0u(1/2) AAS
>>56
きみに説明するまでもないからｗ
61(1): 2019/10/28(月)00:16 ID:BSt0sMZd(2/5) AAS
>>60
分かったから、有意なレスできんなら黙ってろよｗ
62(1): 2019/10/28(月)08:19 ID:U3p6V+0u(2/2) AAS
>>61
黙らなくてもいいでしょ♡
63: 2019/10/28(月)08:25 ID:BSt0sMZd(3/5) AAS
>>62
まあ良いよ、役立たず君。
君の好きなように役に立たないレス返したまえｗ
64: 2019/10/28(月)08:41 ID:BSt0sMZd(4/5) AAS
>>58
こういった書込み見るとDockerてのはOSの仮想化技術じゃなくてアプリケーションの仮想化技術やな。
軽量コンテナとか分かりにくい単語使ってくるから、イメージしづらいわ。
そらOSの仮想化と比べて早いのは当然。
65(1): 2019/10/28(月)09:45 ID:JzQKnTd7(1) AAS
>>45
にたようなことを思ってたけど
前スレでdockerを分かりやすく説明してくれた人がいて、VMとは、根本的に違うと理解した
66(1): 2019/10/28(月)11:33 ID:BSt0sMZd(5/5) AAS
>>65
一応読んだけど59〜とかその辺？
それなら知っている（だからアプリの仮想化やなと言っている）
で、それがVMに対してどのようなメリットが在るのかは相変わらず分からん。
（早いとか軽いとかそういった当たり前のメリットではなく、開発でVMを使う事はそれなりに
意味の在ることであり、それを凌駕するメリットには見えない）
67: 2019/10/28(月)12:59 ID:ZiJ0R/5r(1) AAS
個人レベルの利用でVMの代わりとして使うメリットなんてほとんどない
68: 2019/10/28(月)13:05 ID:U7gDn6Np(1) AAS
>>66
確かにWindowsホスト混在の集団での開発環境だとわかる または技術者の習熟レベルの差によってもvmのほうが扱いやすいだろうな
ネットワーク速度と帯域消費とその他資源が無限な場合はvmに理があるだろう
69: 2019/10/28(月)15:00 ID:KePhh8yu(1) AAS
VagrantBoxはphpとかJavaとかgoとかmysqlとかpostgresql
最初から入ってるの無くね？
Vagrantfileで自分で書く？
面倒くさいし全パッケージのバージョン固定は難しい
イメージの配布も('A`)ﾏﾝﾄﾞｸｾ
AWSはnested virtualizationも無いらしいし
VirtualBoxで作ったら高価なベアメタルインスタンス使うしかなくなるな
70: 2019/10/28(月)15:01 ID:xtDFuCrv(1) AAS
Docker使ってたらLinuxディストリ
別に何でもよくね？
コンテナさえ動けば良いんだから
好きなの使えば良い
71(4): 2019/10/29(火)03:22 ID:Ht/6B8LB(1) AAS
dockerは依存関係調べるのに手っ取り早くていい
Ubuntu minimalをrunさせればviすら入っていないプレーンなかんきょうですぐテストできる。メモリも食わない。アプリケーションのテストサーバとかいいよ。本番環境はまた別だけど。
72: 2019/10/29(火)09:46 ID:MuHfEjBj(1) AAS
本番でDocker運用するのは何か制限がある？
73: 2019/10/29(火)15:01 ID:KeakQ8Tm(1) AAS
GoogleがKubernetesでバリバリ使ってるだろう？
74: 2019/10/29(火)15:13 ID:VN09NAUb(1) AAS
>>71
本番でも、そのままdockerコンテナを運用すればええやん！
75: 2019/10/29(火)17:53 ID:YHcaDCM9(1/2) AAS
逆に本番をDockerライクなシステムで運用しないとローカルをDockerで作る意味が無い。
本番がVMだと二度手間になる。
（開発機作るDockerfileを作った後に本番機を手作業で構築するとか）
76(4): 2019/10/29(火)21:47 ID:/JmTnPWP(1/2) AAS
ステートレスなアプリケーションを素早くスケールしたい場合にコンテナが有利、そんだけや
77(2): 2019/10/29(火)22:18 ID:YHcaDCM9(2/2) AAS
>>76
このメリットでDocker使う、と言うのならDockerは大規模サービス特化型では？
ヤフオクだアマゾンだと超大規模なサービス運用したいと思うなら、そら動的にさっさと
スケールしてくれなきゃ困る。
が、それでVM技術全部を置き換えようぜ、と言われると無理が在る
ESXiであれHyper-Vであれ学習コストがほぼゼロのOS仮想化技術を
学習コストが低くは無い（そして汎用的でもない）
Dockerでと言われると、何でそんな必要が在るの？
と言う素朴な疑問が消えない。
スケールアウトは（OSごとスケールされるけど）VMにも在るからね。
78: 2019/10/29(火)23:12 ID:/JmTnPWP(2/2) AAS
>>77
そう。
79: 2019/10/30(水)04:48 ID:bBGMpLnQ(1) AAS
DockerをネタにVM不要論を唱えてる奴はDockerを扱ったことが無いし理解もしてないだろ
80(1): 2019/10/30(水)05:11 ID:bJJYyUJX(1) AAS
>>77
逆に小規模でvm運用だとデプロイ（vmイメージのインポート？）にサーバーサービスを選ばないか？
環境構築ツールとかアプリ単位のデプロイはどうやっているの？
81(1): 2019/10/30(水)07:15 ID:KYYDqpNF(1/7) AAS
>>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(1): 2019/10/30(水)08:13 ID:vSQkDBfX(1) AAS
>>81
＞手作業でrpmとかyumとかこれも変わらない。
但し1度作ってしまえば、VM複製して＞開発機→検証機→本番機に一気にコピる。
だから構築の手間自体は一回きり。
環境更新するたびにそれとか原始的過ぎるだろ
環境増えたら更新メンテナンスが手間
記録も残らないし戻すのも面倒くさい
それとも一度作ったら二度と更新しないとでも言うのか
83(3): 2019/10/30(水)08:45 ID:R0o4MKxP(1/4) AAS
サーバーをペットのように可愛がるな、いつでも替えの効く家畜として扱え
AWSにも仮想マシンイメージ（AMI）があるが
必要なソフトウェアは起動してからDockerレジストリからプルすれば
カスタムのイメージは作らなくても良い
サーバーが全くインターネットにアクセス出来ない環境なら
そのプライベートネットワーク内にレジストリのミラーを作成するか
Packerを使って、必要なDockerイメージをプルした状態でAMIを作成
サーバーをペットのように扱ってるとASGも使えないだろうが、サーバーダウンは全て人間の監視を付けて対応する気か…？
84(1): 2019/10/30(水)08:52 ID:KYYDqpNF(2/7) AAS
>>82
>それとも一度作ったら二度と更新しないとでも言うのか
逆に訊きたいけど、じゃあ月イチとかそんな頻度でやるの？
環境更新といっているのがどのレベルなのか（例えばOSのバージョン上げるとか）
と言っているのなら、そんな頻度では当然やらない。
致命的なセキュリティホールでもない限りは経験的には5年に1回とかでは？
それなら別に面倒くさいとかは無いよ。
しかもじゃあ、Dockerならノーコストで出来るのかと言うとそうでもないし。
85(1): 2019/10/30(水)08:53 ID:R0o4MKxP(2/4) AAS
うちでは小規模な案件であれば、コンテナオーケストレーターにECSを利用している
EC2（仮想マシン）やECSのサービス（どんなコンテナを幾つ動かし続けるかの指定、docker-composeのサービスを拡張した感じ）はTerraform、CloudFormationで管理
これらが揃えば
公開するドメインなど、環境によって変えなければいけないものを除き
全く同一のソフトウェア構成で自動で構築できる
86(1): 2019/10/30(水)08:53 ID:KYYDqpNF(3/7) AAS
>>83
>サーバーが全くインターネットにアクセス出来ない環境なら
>そのプライベートネットワーク内にレジストリのミラーを作成するか
>Packerを使って、必要なDockerイメージをプルした状態でAMIを作成
これはどう見ても余計な手間が増えている。
87(1): 2019/10/30(水)09:03 ID:R0o4MKxP(3/4) AAS
>>84
脆弱性なんて5年に一回どころかもっと高頻度で出ると思うが
脆弱性出ないからじゃなくて
一個ずつパッチ当てるの面倒だから更新してないだけだろう？
AWSならAMIを更新してASG内のインスタンスを入れ替えれば良い
更新で出る影響は完全にインフラがコード化されていれば、テスト環境でテスト出来る
コンテナとホストOSは基本的に隔離されているので
依存性による問題が出る事はほぼない
カーネルのバグによる影響は出ないとは言い切れないが、
安定版になる前にベータ版で発見される可能性は高い
コンテナだけの更新であれば
影響範囲が限定されるし
サイズがOSより小さいので
もっと高頻度でも可能
88(1): 2019/10/30(水)09:04 ID:KYYDqpNF(4/7) AAS
>>85
>コンテナオーケストレーターにECSを利用・・・
>>83
>Dockerレジストリからプルすれば・・・
こういうの見ると、日本でDockerが大々的に流行るのは無理と言う気がするね。
>>51 dockerは配布の仕組みが標準化されていて
>>76 Dockerのメリットは、素早くスケール
Dockerはインターネット上の標準化されたレジストリから配布を行いすばやくスケール可能なのがウリと、
が日本じゃ社員50人以下の会社が使うようなサービスはそもそもスケールの必要は無いし、
1万人超の大会社だと、お堅い会社の場合、そもそもクラウド上にアクセスする事自体を嫌うから。
ちょっと前にSalesforce売りに行ったら、ソッコーで「クラウド駄目」とか言われたわ。
大規模な会社じゃないとスケールアウト使う意味ないし、大規模な会社はクラウドを嫌う。
唯一使うとすればヤフオク、グリデナ、メルカリ、ピクシブ、とかインターネット系の大規模サービスやってる所位？
少なくともDockerを100％使い切る会社と言えば上記のようなものしかない。
後はまあ、好奇心旺盛な新興会社が使って自慢するとか、そんな感じ？
89: 2019/10/30(水)09:15 ID:KYYDqpNF(5/7) AAS
>>87
そんなのお客さんと自社の状況しだいだろ？
セキュリティにうるさいお客さんなら月1回呼び出させてパッチあてやらされるし、そうでもなければ放置する
自社内のサービスなら売上げ上がっているなら、メンテはやる。
がこの話は「VM複製して＞開発機→検証機→本番機に一気にコピる。」とは関係ない。
そもそも俺は、「環境更新するたびにそれ」なんて言ってない。
まあ、なんと言うか、「パッチ当てが楽になるからDocker導入しましょう」
といって「そうですね、そうしましょう！」と言う話になるかどうかは分からない。
90(1): 2019/10/30(水)09:20 ID:R0o4MKxP(4/4) AAS
>>88
サイボウズが1000台規模のKubernetesクラスターを自前で運用してたぞ
後はAWS Outpostみたいなのを自社サーバーで運用とか？
>>86
比較するなら
PackerかDockerかだろ
VMのイメージ作成やデプロイも手動でやっていたのでは話にならん
インターネットなしの環境でKubernetesを運用するとして
Packerを併用する場合でも
Kubernetesのバージョンアップだけ気にしていれば良いから
そこまで手間ではない
ビルドとAMI作成はCIでやる
Dockerイメージの作成もCIでやる
91(1): 2019/10/30(水)09:39 ID:KYYDqpNF(6/7) AAS
>>90
>サイボウズが1000台規模のKubernetesクラスターを自前で運用してたぞ
これもオンプレで動くサイボウズの方じゃなくてクラウドのほうだろ？
クラウドサービスをDockerでクラスタなら分かる、軽量コンテナにうってつけだろうし。
>インターネットなしの環境でKubernetesを運用するとして
Dockerは本当にオンプレで完全に動くの？
それが出来るなら、企業のIT部門の人が勉強する意味は在ると思う。
それでも、そこに上げた名前分みても、やはり学習コストは高いと思うけど。
なんせVMwareESXiとか学習コスト殆どないし。
92(1): 2019/10/30(水)15:14 ID:BfA8YI+E(1/2) AAS
サイボウズはオンプレミスでKubernetesを運用している
1,000台規模のインフラ刷新！ Kubernetesを採用したサイボウズが語る「NoOps」な未来 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
外部ﾘﾝｸ:employment.en-japan.com
93: 2019/10/30(水)15:25 ID:BfA8YI+E(2/2) AAS
でも北米のkintoneはAWSらしい
クラウドに行く企業、クラウドをやめる企業、それぞれの事情 - 週刊アスキー
外部ﾘﾝｸ:weekly.ascii.jp
94: 2019/10/30(水)16:50 ID:KYYDqpNF(7/7) AAS
>>92
ここでいう「オンプレで運用」は>>91でいう「Dockerは本当にオンプレで完全に動くの？」とは
意味が違うだろ？サイボウズが行っているのは単に自社のサービスを自社で運用しているといっているだけ。
91で訊いているのは、インターネットにアクセスせずに（アクセスすると偉い人に怒られるから）DevOpsを全部
導入できるのかと訊いている。見た感じ、頑張れば出来そうだけど。
95: 2019/10/30(水)20:30 ID:F5UzNQl0(1) AAS
みんな、cndk2019は行くかな？
来月だね
96: 2019/10/31(木)09:23 ID:kRp2coEV(1) AAS
インターネットアクセス禁止って行っても
Dockerのベースイメージはインターネットから取る必要あるよね
OSSのCIツールを導入するにも
Dockerのベースイメージはインターネットから取得する必要がある
そう考えるとCIサーバー自体にはインターネットアクセスは必要
向こうからのアクセスは無いので、NATゲートウェイ経由で
こちら側からだけアクセス可能にする
レジストリはCIサーバーと本番機のみがアクセス出来るプライベートサブネットに配置
そうすれば本番機にはインターネットアクセスを与えずに済む
Dockerレジストリのミラーを設定して
そこから取得するとしても
レジストリのミラーリングを行うサーバーにはNATゲートウェイ等で
インターネットアクセスが必要
それも駄目だったら逆に何処からソフトウェアを持ち込むんだ
USBメモリで人力ミラーリングか？
97(1): 2019/10/31(木)10:03 ID:IvqXe+OC(1/2) AAS
イメージエクスポートしたらベースイメージも含まれてるのじゃないの？
そしたらそれを持ち込めば済むね
98(1): 2019/10/31(木)11:02 ID:AgzkHmg5(1/5) AAS
>>97
そのやり方は普通にDockerfileを書くだけで可能なの？
そもそもDockerてのは、「ベースイメージの取得にインターネットが必要」
って事自体が保守的なIT部門の理解を得られん気がするね。
ゲストOSのインストールをするのにインターネットがほぼ必須、クラウド上にしか
イメージ置かないって言われたら「なんで？」と思うのが普通だわ。
99(1): 2019/10/31(木)11:29 ID:bT1pYe7k(1) AAS
connpassにあるコンテナ系の勉強会行って各現場の導入事例を聞いてみると吉
100: 2019/10/31(木)11:39 ID:AgzkHmg5(2/5) AAS
>>99
暇が無い。
結論だけ教えてくれｗ
101(1): 2019/10/31(木)11:47 ID:yEAfK0sf(1/2) AAS
プライベートレジストリ立ち上がるダケじゃん
102: 2019/10/31(木)12:19 ID:AgzkHmg5(3/5) AAS
>>101
それ１つをとっても複数製品があり、やはり学習コストが低くはない
って点がどうしようもないね。
まあ、慣れだけど。
103(1): 2019/10/31(木)12:25 ID:IvqXe+OC(2/2) AAS
初期状態のosでnetwork隔離環境でimageのインポートしたら問題なく環境再現できた
>>98
104: 2019/10/31(木)13:42 ID:AgzkHmg5(4/5) AAS
>>103
( ´∀｀)bGJ!
105: 2019/10/31(木)16:34 ID:yEAfK0sf(2/2) AAS
>>83
>サーバーをペットのように扱ってるとASGも使えないだろうが、サーバーダウンは全て人間の監視を付けて対応する気か…？
今年の8月にAWSの大規模障害あったトキお前んトコは回避できた？
AWSをペットのように扱ってるだけちゃうん？
苦情があっても全てAWSのせいにして対応する気か…？
106: 2019/10/31(木)17:21 ID:4tcsPNQN(1) AAS
ﾖｰｰｰｰｼﾖｼﾖｼﾖｼｮｼﾖｼｮｼ
107: 2019/10/31(木)21:49 ID:O/FSXRKR(1) AAS
私が死んでも代わりはいるもの
108: 2019/10/31(木)22:33 ID:AgzkHmg5(5/5) AAS
実は83、本番環境持ってなかったりしてｗ
109: 2019/10/31(木)22:47 ID:y7N0mD2n(1) AAS
みんな、マイクロサービスアーキテクチャ導入してますか？
110: 2019/11/01(金)08:46 ID:JvLjIRFV(1) AAS
マイクロサービスって
2つのマイクロサービス間のデータのやり取りはどうする？
Dockerが解決するのはアプリのデプロイまで
マイクロソフト的には
分離性を高めるため
HTTPリクエストが来た時に別サービスへ同期的に取りに行くのではなく
バックグラウンドで予めデータを同期する方がお勧めらしい
が面倒そう
適当なことやると2つのサービスでデータの不整合が生じる
111: 2019/11/01(金)10:48 ID:WiXsGXAx(1) AAS
webキャッシュの話？
112: 2019/11/01(金)11:00 ID:L19v4ru9(1) AAS
実装に関する説明をしているのにカタカナの単語説明ばかりで
具体的にこうしている、というコードが少ないアーキテクチャは駄目フラグ
て気がするけどな。J2EEでトランザクション分離がどうのこうのとか長々と
説明するけど具体的なコードもそれにふさわしくウザくて結局普及はしなかった。
113: 2019/11/01(金)14:00 ID:b78ok99X(1) AAS
まぁ自分トコさえ便利に使いこなせればいーやってカンジなんじゃねえの
114: 2019/11/02(土)10:34 ID:yEoeML2L(1) AAS
Amazon ECRのマネジメントコンソール
久しぶりに見ると
・タグのイミュータビリティ
・イメージのスキャン
なる機能が追加されてた
外部ﾘﾝｸ:dev.classmethod.jp
古いバージョンのソフトウェア使ってて
CVEの脆弱性あったら教えてくれる機能？
あまぞんのブログURLがNGワードで書けない
115(3): 2019/11/09(土)16:33 ID:xm5wCBj4(1) AAS
「専任エンジニアが2人以上欲しい」：
Kubernetesの自前運用は難しい？ はてなの撤退事例
はてなのMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。
なぜ、Kubernetesの運用を諦めて撤退を選んだのか。
はてなのMackerelチームでSREを務める今井隼人氏が語った。
外部ﾘﾝｸ[html]:www.atmarkit.co.jp
116: 2019/11/09(土)17:03 ID:r8GCENPg(1) AAS
会員登録（無料） が必要です
117: 2019/11/09(土)19:54 ID:j2CHsg3O(1) AAS
Kubernetesは試したけど本番環境に使う自信が無いわ
118: 2019/11/09(土)22:53 ID:v7R6fqHc(1) AAS
>>115
当たり前。
Kubernetesクラスタを自前で運用すると言うのはアマゾンで言えばASG
を自分たちで運用しようってな物じゃないの？
何故そんなことをする必要が在るのかと。
Kubernetesのエコシステムの図一つをとってもツールだらけで
この１つ１つを学習しろと言うのか？学習コスト高すぎで馬鹿かと・・・。
しかもそこまでやっても、汎用的では無いからVMはVMで残さなければならない。。
119: 2019/11/09(土)23:52 ID:+3c0Ii5M(1) AAS
>>115
わかる。あれ複雑過ぎ
記事読んでないけど、少数の台数で構築してもコントロール不能に陥るだけだと思う。
Kubernetesが生きるのは100台とかで、贅沢なリソースがあって
その中で何台か生きてればいい。他はそのうち生き返るって状況が作れてからからだと思う
台数が少ないと、何台か死んだら絶滅するｗ
120(5): 2019/11/10(日)06:26 ID:KPJdW8/s(1/19) AAS
結局Dockerは何が魅力なんや？
現段階で本番で使えないのはKubernetes？それともDocker自身？
前にもちょっと書いたけどローカルの開発機をDockerで作っても
本番機で使えないのなら二度手間になるだけだから意味が無い。
>>76見たいな話は勿論、本番環境の事を言ってるんだよな？
121(1): 2019/11/10(日)09:05 ID:yayxIbvd(1/2) AAS
>>120
76はVMに対する「コンテナ」の利点を言ってる
kubernetesもdockerもコンテナを動かせる。両方本番で使える。
122(2): 2019/11/10(日)09:33 ID:KPJdW8/s(2/19) AAS
>>121
そんな事は分かってるよ。両方本番で「使える」ことも分かってるよ。
でその結果>>115で止めたと言ってるんでしょ？使えるけど複雑すぎると。
でそれを読んだ俺の感想はDockerはともかく、それ以外のエコシステム含めると
学習コストも高すぎるし、本番をVMで作ってローカルの開発環境をDockerで作ると
二度手間でしかない、といっている。
で、二度手間に目をつぶってでも、取り組んだほうが良いDockerの魅力は何なのかと。
123(1): 2019/11/10(日)09:51 ID:yayxIbvd(2/2) AAS
>>122
つまり本番＝VM、ローカル開発環境＝dockerを推してるやつがどこかにいてそのメリットは何かが聞きたいのね
俺は推してない
124(1): 2019/11/10(日)09:53 ID:+DdRcUGW(1) AAS
でも猫も杓子もK8Sって感じで
後はAWS限定のECSか
Swarmってやつしか無いよね
K8Sは立てるだけならツール使えば出来るが
互換性破壊が多くてアップグレードが壁になる
はてなはテスト環境でアップグレードに失敗して撤退
kubesprayが実装をkubeadmに変えた時期と
担当者の退職・移動が重なったと
でもそれって担当者の退職が一番の原因じゃね？
移行先はEKSを検討しているらしい
ECS、Fargateは既に一部で使っていて
まずECSに移行後、EKSへの移行を目指す手筈
125(1): 2019/11/10(日)10:09 ID:VIhv4B2u(1/27) AAS
>>120
> 結局Dockerは何が魅力なんや？
配布
WindowsのDLL Hellの話知ってるか？
昔、Windowsで大問題になってな
アプリをインストールするときに、一緒にDLLもインストールするんだが
当時はアプリにシステムDLLが含まれていたりして、
インストールするとOSのDLLを書き換えて、他のアプリが動かなくなったりした。
今ではそれが改善されて、アプリはシステムDLLを書き換えない、
必要ならアプリのディレクトリにDLLを入れたり、
.NETなんか複数のバージョンをインストールできて適切なものを使えるようになってる。
Linuxでもそれは同じでな。ディストロのパッケージだけ使ってるなら別に問題ないんだよ。
そのバージョンで動くように頑張ってるのがディストロの仕事だから
でもな、俺ら（開発者）がなにか作る時、ディストロのパッケージのバージョンを
色々考慮しないといけなくなる。ディストロアップデートしたら、そのパッケージで動くか検証したり
パッケージの新しいバージョンを使う時、それが今のディストロでちゃんと動くのか検証しなくちゃいけない。
それはつらいだろ？だからもうアプリに全部含めちゃいましょう。
というのがDockerなんだよ。（互換性が超高くて小さいカーネル以外）全部アプリに含めてるから
あちこちに簡単に移動できたり、バージョンアップできたりするんだよ。
ここまで言えば分かる通り、開発者以外にとっては関係ない道具
ディストロのパッケージ使ってるだけのやつとか、仮想マシンと勘違いしてるやつにはようはないから
126(2): 2019/11/10(日)10:10 ID:VIhv4B2u(2/27) AAS
>>120
> 前にもちょっと書いたけどローカルの開発機をDockerで作っても
> 本番機で使えないのなら二度手間になるだけだから意味が無い。
言葉がおかしい。開発「機」を作るわけ無いだろ？
作るのは開発アプリ。それをいろんな、開発機、テスト機、本番機で
そのまま使うことができる。
127(1): 2019/11/10(日)10:17 ID:VIhv4B2u(3/27) AAS
>>120
> 現段階で本番で使えないのはKubernetes？
Kubernetes。まあ使えないことはないと思うよ。
ただ使うためには労力が多すぎて、発想の転換に迫られる。
数台の本番環境を落ちないようにメンテすると言うより、
システム全体で稼働するように設計しないといけない
個でじゃなくて群で考えてメンテナンスの仕組みを作らないといけない
トラブルが合った時、個々のマシンを観察して情報を判断するのではなく
群からデータを集めてそれらを分析して、トラブルの原因を追跡するとか
個々のマシンをアップデートするんじゃなくて、群の中の一部分を
（半ば自動的に）入れ替わっていくという感じの設計が必要
失敗すると次から次へとマシンが落ちていって制御不能になって
最悪データの損失が発生する。
Googleみたいにすでに大量のマシンが存在して、個々のマシンの観察なんて
やってられないっていうのなら、Kubernetesの出番だけど
そうでない場合は、大変なだけ。
上下前次1-新書関写板覧索設栞歴
あと 875 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s