[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
495: 2020/01/25(土)18:13 ID:oy3JqaRN(1) AAS
初めてDockerを触ろうと思っています
Windows10Proで動かしたいんですが調べてみると
Docker for WindowsとDocker Toolboxのどちらを入れれば良いのか分かりませんでした
用途としてはPythonの開発環境をDockerに組もうと思っているのですが
どちらを使えば良いのか教えていただけると幸いです
496(1): 2020/01/25(土)18:53 ID:ES14vB7p(2/3) AAS
通常は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(1): 2020/01/25(土)19:01 ID:ES14vB7p(3/3) AAS
> 用途としてはPythonの開発環境をDockerに組もうと思っているのですが
それは推奨しない。Dockerはアプリケーションを作るもの
Windows10Proなら、Pythonの開発環境としてはWSLを使うのが良い。
開発環境はWSLでもWindowsでもMacでもLinuxでも
仮想マシン上のなにかでも、どこでも好きなOSを自由に選べる
開発環境を自由に選べる理由がDocker
DockerというのはPythonで作ったアプリに可搬性をもたせるために
（どのOSでも動くようにするために）Dockerイメージでラッピングするというのが正しい使い方
作ったものがどこでも動くから、開発環境はどこでもいい。
どこでもいいからWindows10ProでPython開発環境として一番便利なWSLが推奨
498(1): 2020/01/25(土)19:42 ID:F7NqsOON(1) AAS
別にDockerを開発環境にしてもいいのに
このスレではそれやると発狂する人がいるよね
499(1): 2020/01/26(日)00:27 ID:m8Av32+M(1) AAS
開発環境としてDocker(というかコンテナ)使うのは環境汚さないで済むから寧ろ推奨する
VSCodeのRemote Developmentなんかのおかげで開発環境としてのコンテナがものすごく扱いやすくなったのも大きい
500(2): 2020/01/26(日)11:56 ID:BR48jIcb(1) AAS
今まで仮想マシンや物理マシンに対して、ansibleみたいなツールを使って設定の自動化をしていた
これがdockerになると、コンテナに対する設定はdockerfileに書くから、ansibleみたいなツールは必要なくなるという認識でええのかね
501: 2020/01/26(日)12:26 ID:OzJ+Z2xw(1) AAS
>>500
Ansibleのメリットは複数のホストに跨った設定を一貫して管理できることであり、
そもそもDockerfileで置き換えられるような用途であればシェルスクリプトで十分だ
元々Ansibleなんか必要ない
コンテナ時代にAnsibleを使うとすればクラスタの構築や管理においてだが、普通はGKS、EKS、ECS使ってポチるだけだから小難しい構成管理なんか要らない
502(1): 2020/01/26(日)12:41 ID:7x8NuhpY(1/4) AAS
ECSを動かすにはクラスターが必要
クラスターは通常VPC、起動テンプレート、ASGが必要
ECSタスク定義やサービスが必要
定期実行はスケジュールドタスクの設定が必要
プライベートネットワークにEC2を置きつつ
EC2をインターネットに繋ぐにはNATゲートウェイが必要
HTTPの負荷分散やローリングデプロイには
ELBが必要
CDNにCloudFrontが必要
データの保存先としてRDSやS3も必要
一部リソースはIAMロールの設定も必要
イメージ置き場にECRリポジトリも必要
これ全部ポチポチでやんの？
terraform使えよ
503: 2020/01/26(日)12:41 ID:UB3s9UX0(1) AAS
>>496-499
ありがとうございます
まずはforWindowsでDocker自体に慣れてみます
504(1): 2020/01/26(日)17:42 ID:oh//L3LW(1/3) AAS
>>500
Ansibleでできることを中の人が教えます - インストールと実行?EC2へのNginx投入までを学ぼう
外部ﾘﾝｸ:employment.en-japan.com
> 現在では構成管理にとどまらずその守備範囲を広げ、
> アプリケーションのデプロイやオーケストレーションなどにも利用できるようになりました。
↑この違い
インフラ担当者がアプリの複雑なデプロイまでやってた時代があった。
アプリを動かすにこれそれのパッケージが必要だから入れるとか入れ替えるとか
入れるだけならまだしも、複数のパッケージを入れるとか、
しかも標準パッケージにないものとか怖くてやってられない。
それが一時期、Ansibleでなんでもできるぜーって冪等性でどんなマシンでも
いっぺんに同じ状態にできるぜー（嘘）となってアプリの複雑なデプロイをAnsibleでやる時代があった。
冪等性があるといっても実際にはやってみなきゃわからんこともあるわけで
複雑なデプロイをAnsibleでやるのは苦痛でしか無い。
Ansibleはバージョン依存がひどすぎるから。
んでDockerがでてきた。アプリの複雑デプロイはDockerコンテナの起動という、
たった一つ（もしくは数個）の命令に置き換えられるようになった。
とはいってもこれは「アプリケーションのデプロイ」であって
構成管理やオーケストレーションの話とは関係ない
DockerベースになるとオーケストレーションはKubernetesを使うことが多い
守備範囲を広げたAnsibleは、元の構成管理だけをするように戻りつつある
いろいろ手を広げすぎたんだよ、やつは。
505: 2020/01/26(日)17:46 ID:oh//L3LW(2/3) AAS
>>502
GCPならデプロイメントマネージャーという
クラウドサービス標準で、自社のクラウドを適切にサポートした
純正機能があるわけだけど、そこに外部が作ったterraformを使う意味あるの？
terraformという第三者が絡むせいで制限とか互換性問題とか生まれてるでしょ？
506: 2020/01/26(日)18:15 ID:oh//L3LW(3/3) AAS
> そもそもDockerfileで置き換えられるような用途であればシェルスクリプトで十分だ
いつも思うけど「シェルスクリプトで十分だ」って考え方なんなんだろうね。
「シェルスクリプトが適切だ」が正しいと思うんだけど
シェルスクリプトが適切な問題を、プログラム言語でやろうとすると
めんどくさくなるよ。
リダイレクトとかパイプとか、実行環境を整える所から必要になってめんどくさい。
507: 2020/01/26(日)20:17 ID:Dr6wHv91(1) AAS
Ansibleが担うのはprovisioningでDockerなどのコンテナはdeploymentのイメージがある
508: 2020/01/26(日)21:03 ID:7x8NuhpY(2/4) AAS
AWSはCloudFormationあるけど
terraformより色々使いづらい点が多い
AWS製にも関わらず
たまにCloudFormationでだけ設定できない項目があったりする
S3の期限切れ削除マーカーの削除の設定が
何故か未だに未実装
外部ﾘﾝｸ:stackoverflow.com
この質問が投稿されたのは2016年10月だが
2020年になっても放置
忘れられているっぽい
509: 2020/01/26(日)21:12 ID:Sxuz1Gfw(1) AAS
まあ本家のツールが使いにくいっていうのならTerraformとかの意味があると思うけど
あとAWSとGCPを行ったり来たりしたり、同じものを別々の場所に構築するとか
コード共通でできるんでしょ？しらんけどｗ
510: 2020/01/26(日)21:37 ID:7x8NuhpY(3/4) AAS
マルチクラウドは出来るらしいがやったことない
GCPやAzureは使ったことが無いし
開発環境と同じ構成で
EC2インスタンスのスペックやドメインだけ変えて作るのは可能
Terraformの方が便利とは言っても
複数モジュールの同時デプロイや
モジュール間の値の受け渡しが
Terraformだけでは不便なので
最近Terragruntも使い始めた
コスト削減のために、開発環境では使わない機能がある、
あるいは複数環境で1つのリソースを共有する場合に
巨大モジュールを作って大量の変数
でAWSリソースを作るか作らないかを制御するより
Terraformモジュールを分けた方が良いというのもある
Kubernetesを使ってもインフラの管理から完全に逃れることはできない
511: 2020/01/26(日)21:48 ID:7x8NuhpY(4/4) AAS
TerraformのKubernetesプロバイダーで
helmのデプロイやKubernetesリソースのデプロイも出来る
TerraformのAWSプロバイダーでIAMロールを作成して
kiamで特定ポッドのみにAWSへのアクセス権限付与したりする合わせ技も可能
しかし微妙にかゆいところに手が届かない感はある
公式KubernetesプロバイダーはKubernetesリソースをHCLで書く必要がある
YAMLをそのまま使いたい、CRDを使いたい場合は
公式のKubernetesプロバイダーでは無理
非公式のプロバイダーが必要
banzaicloudのk8sってやつ
CRDが使えないって割と重大な欠陥の気がする
helmは最近v3が出たが
公式Terraformプロバイダーはまだv2までの対応
512: 2020/01/26(日)23:59 ID:o6VABBUy(1) AAS
なにか便利な機能を提供してくれるならいいけど、
「使い方を変えるだけ」の道具はいらないなぁ
公式で同じことできるんでしょ？
それが簡単になったわけじゃなくて
使い方を変えるだけでしょ？
そしてそのプラバイダーが、ある機能に
対応してない困ったぞーっていうのを
永遠と繰り返してるでしょ？
513: 2020/01/27(月)07:40 ID:xCTAmbZl(1) AAS
新しいものにどんどんチャレンジして報告するべきじゃないのかな。
それがコミュニティへの貢献ってものでしょ。
キミたちは人柱なんだから。
514: 2020/01/27(月)10:45 ID:oWpDpuvr(1) AAS
WindowsのDocker Desktopを2.2にアップグレードしてから、マウントしたボリュームが時々書き込めなくなってエラーになる状態になって
2.1に戻したら直った
調べたら2.1から2.2で内部構造がだいぶ変わってるんやね
515: 2020/01/27(月)20:04 ID:VdNPUB7+(1) AAS
>>504
その状態でansibleにやらせる構成管理ってなんなんや
dockerを動かす物理マシンの構成管理だけやるという意味なんか
516: 2020/01/28(火)03:27 ID:alr/KPAT(1) AAS
この前、Docker HubのREAME.mdがGitHubのREADME.mdを中途半端に
持っていくって話をした件だけどGitHub Actionsで同期取るっぽいのがあった
これで指定したやつを持っていってくれるかも
外部ﾘﾝｸ:github.com
517: 2020/01/29(水)14:22 ID:nynZIk47(1) AAS
k3s使ったらメモリー1GBのインスタンス3つでもHA出来る？
518: 2020/01/29(水)14:26 ID:givpjA6N(1) AAS
k3sはメモリ512MBしか（笑）食わないんだろ？
ならアプリが512MBまでなら動くんじゃね？
k3sでこれだけだと、k8sはどんだけ食うんだよｗ
カーネルの使用メモリが少なくても台無し
519: 2020/01/29(水)14:29 ID:6Q7T2cbs(1) AAS
workerは別途用意するだろJK
520: 2020/01/29(水)19:59 ID:5uyhmzFh(1/4) AAS
本家k8sは1GB RAMでは足りない気がする
kiamのサーバーと
helm v2のtiller
kube-iam-authenticator
controllerにこの3つを置いているが
2GBから1GBに減らしたらAPIサーバーが使えなくなった
だから本家は最低でも2GBのメモリーが必要
521: 2020/01/29(水)19:59 ID:5uyhmzFh(2/4) AAS
etcdも同居してるからさらに厳しい
522: 2020/01/29(水)20:00 ID:3wP3LyoD(1/4) AAS
なんでk8sってそんなにメモリ食うんだろう？
ただコンテナを管理するだけの仕組みじゃんか
523(1): 2020/01/29(水)20:02 ID:3wP3LyoD(2/4) AAS
高いVMインスタンスを売りつけるための
戦略としか思えないな
ウェブサーバーとか数十MB程度で動くのに
k8s化した途端1GBとか必要になる。アホかと
524: 2020/01/29(水)20:05 ID:5uyhmzFh(3/4) AAS
他のクラウドはコントローラーがタダで使えるらしいが
AWSだけまだ72ドル掛かる
高杉
大企業にとってははした金だから
それでも使う奴は居るのだろうが
>>523
GKEは安いの知ってる？
525: 2020/01/29(水)20:07 ID:5uyhmzFh(4/4) AAS
ワーカーノードは1GBでも良い
コントローラーノードの金が気になるならGCP行ってGKE使え
うちもGKE使いたい所だが
AWSを使わねばならない
のっぴきならない事情がある
526(2): 2020/01/29(水)20:16 ID:3wP3LyoD(3/4) AAS
kubernetsとかさ、クラウドの上にクラウドを作ってるみたいで
気持ち悪いんだよね。せっかく便利に使えるようになったクラウドを
なぜコンテナベースで再発明するのか？
527: 2020/01/29(水)20:57 ID:zxPSLJvv(1) AAS
>>526
インフラエンジニアの雇用を維持するためだよ。マジで。
自社サービス系のインフラエンジニアって基本的にトラブルがなければ仕事ないから、
自然と問題なく動いているもののオーバーエンジニアリングに向かうものだ。
528(2): 2020/01/29(水)21:15 ID:3wP3LyoD(4/4) AAS
オーバーエンジニアリング程度なら良いけどさ
メモリ食い過ぎで前より不便にしてるだけなんだよな
インフラ系って、変わってるだけで、何も良くなってない
529: 2020/01/29(水)21:33 ID:9OcLAXSy(1) AAS
>>528
いや、だからGKE使えよ？
コントローラー無料だろ？
530: 2020/01/29(水)22:10 ID:OCMkZsaj(1/3) AAS
>>526
元々クラウドのための仕様なんだが……。
ノードの数を負荷に応じて変更できるから、処理が多い時間はノード増やして処理し、少ない時間はノードを減らす事でコストを最適化できるのがk8sの売り。
規模が小さいとこの利点（オートスケーリング）が意味をなさなくなる。
531: 2020/01/29(水)22:23 ID:BTLuyg2X(1) AAS
1台しかないならdocker-composeでよくね？
1台しかないなら
532(1): 2020/01/29(水)22:35 ID:OCMkZsaj(2/3) AAS
従来は高価なオンプレを1台買ってスペック余らせるのが普通だったが、今はクラスタにする事で、オートスケーリングによりスペック（≒コスト）を最適化できるようになった。
ハイスペック1台ならdockerで十分だが、コスト面で最適化されてるかな？という話。
533(2): 2020/01/29(水)23:26 ID:K0p5wp9W(1) AAS
>>532
それだけならECSとかで十分でしょ
k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ
534: 2020/01/29(水)23:50 ID:OCMkZsaj(3/3) AAS
>>533
k8sはECSより高機能で汎用的だが学習コスト高めという印象。ECSはベンダー製なので、クラスタに関してはその通りだろうが、ベンダーロックインの問題がある。
ベンダーロックインの問題を気にせず、ECSで案件が済むならECSだろう。
535(1): 2020/01/30(木)00:20 ID:KTDe4H4D(1) AAS
たかがコンテナ立ち上げるだけのことにベンダーロックインねえ
事業視点で言えば、k8sに習熟した少数のエンジニアにインフラをロックインされることの方がよほどリスクが大きいと思うけどね
536: 2020/01/30(木)00:26 ID:OBlH/P8v(1) AAS
>>528
単に使い所を間違ってるだけとしか思えんが
そもそも別にk8s使わなくてもdockerはある程度規模に応じたオーケストレーションを標準に
近い形で用意しているはずで、それでは管理できないほど巨大な規模のサービスを運用するから
k8sですよ、って事で、当然メモリが食いすぎとか文句言う人が使う物じゃない気はする。
そういう人にはもっと小規模な物あるでしょ？
昔Googleの論文元にHadoop作って訳も分からずに食いついて先進的だカッコいいぜ俺スゲーとか
いって後からやっぱ遅ーえわこれｗとかいってた連中思い出すね。
自分たちが間違った場所に適用してるとは最後まで考えないｗ
537(1): 2020/01/30(木)01:26 ID:pAQXSf/G(1/2) AAS
>>535
Amazonがk8sのサービス始めたのはこの理由らしいから、そういう意見も多いということなのだろう。
個人的にはk8sよりマルチビルドのdocker file の方が難解だな
538(1): 2020/01/30(木)02:46 ID:N78kTYg5(1/6) AAS
>>533
> k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ
そうだよね？
広大なCPU空間を確保しておいて、自由に使いましょうというのならいいけど
コストの観点から空間自体を減らしたり増やしたりってのは適してないと思う
スケーリングならすでにGCEとかのクラウドの仕組みで実現できたじゃんって思う
そこにGKEを持ってきて使いづらくしたと思ったら、
どうせコンテナベースで課金とかするでしょ？
なんでクラウドの中にさらにクラウド作ってるんだろうって思う
539(1): 2020/01/30(木)02:49 ID:N78kTYg5(2/6) AAS
>>537
> 個人的にはk8sよりマルチビルドのdocker file の方が難解だな
マルチステージビルドの事？ どんだけ複雑なんだよｗ
あんなの、中間ファイルは不要だから
前のイメージでビルドしてできた生成物のみ
コピーして使いましょうってだけじゃんか
540: 2020/01/30(木)03:04 ID:N78kTYg5(3/6) AAS
k8sの嫌なところは短いタイミングで強制アップデートな所だな
これがあるからストレージとしては使えない
データベースは別のサービスを使えってことなんだろうけど、
これがあるからHAの代わりにはならないんだよね
541: 2020/01/30(木)08:22 ID:x2o8za8v(1/2) AAS
自前k8sなら誰も面倒見てくれないので
アップデートもされない
証明書の期限短くすると
期限切れした時にAPIサーバーと通信できなくなるけど
542: 2020/01/30(木)08:57 ID:JRKnodoF(1/3) AAS
APIサーバーの証明書は自動更新機能があった気がする
>>538
ワーカーノードは今まで通り課金される
k8sでのサーバーレス関数の実行は
EKSやGKEで最近できるようになったが
一部機能制限がある上に
確保するリソースが多いと通常通り
ワーカーノードを用意した方が安くなる事がある
サーバーレスはコールドスタートによる遅延の問題なども多分まだある
543(1): 2020/01/30(木)09:18 ID:JRKnodoF(2/3) AAS
サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る
とは言ってもノードの起動は時間がかかるので
すぐには無理だが
544: 2020/01/30(木)09:18 ID:JRKnodoF(3/3) AAS
サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る
とは言ってもノードの起動は時間がかかるので
すぐには無理だが
545: 2020/01/30(木)11:27 ID:pAQXSf/G(2/2) AAS
>>539
他人が書いたのを検証するのが難しいってことね。他人に依存するかどうかという視点の話。
546(1): 2020/01/30(木)11:44 ID:N78kTYg5(4/6) AAS
>>543
ノードの増減はk8sなくてもできたじゃん？
・負荷の応じてノードが増減できる
だったのが
・負荷に応じてでポットが増減できて、ポットの増減に応じてノードが増減できる
に変わってるじゃん？
二段階になってややこしくなってるし
ノード（課金対象）が増減しない範囲でのポットの増減が存在するわけで、
こんなんで正確な見積もりなんかできるの？
k8sはプロジェクト単位で使うものじゃななくて、
会社として広大なクラスタ空間を予め確保して、その中で複数の異なる
サブプロジェクトをいくつも動かすって使い方をする
Googleぐらいしかまともに使えないよ
547: 2020/01/30(木)11:52 ID:N78kTYg5(5/6) AAS
k8sはノード＝1つないし少数のそれぞれ違うポットを配置するという使い方じゃないんだよね
1つのノードが複数のポットを動かすスペックを持っていて、
多数の小さなポッドをその中で動かすという使い方をする。
1つのノードで同じ種類のポットがたくさん生まれて
消えるような場合じゃないとうまく使えない
自動管理されたHA環境ではないんだよね
548(1): 2020/01/30(木)17:42 ID:IVBe8aPz(1) AAS
ECSは当初タスク数がEC2インスタンス数と連動しない残念仕様だった
こちらもタスク数に応じてインスタンスが生成される
外部ﾘﾝｸ:dev.classmethod.jp
5タスクを同時に動かそうとすると、
5台のEC2インスタンスが生成される
超シンプル
549: 2020/01/30(木)17:44 ID:krDeGaUI(1) AAS
ECSサービス開始当初はEC2の数とタスクの数を連動させる機能が
無かったが、去年追加された
550(2): 2020/01/30(木)18:28 ID:N78kTYg5(6/6) AAS
>>548
それは一般的な使い方としてはわかりやすいし、できるべきだよね。
ただk8sのそもそもの使い方としては、ずれてるんだと思う
その使い方であれば、インスタンスのオートスケールと変わらないわけだし
コンテナが動かせるというメリットはあるけどね
まあ各クラウドの間で共通のインターフェースができて
どこでも動かせるようになるのはいいと思うけど
そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい
もっと間を減らしてシンプルに出来なかったのかねぇ
やっぱりクラウドを使ってクラウドを作ってるように見えてしまう
k8sはある程度の空間を確保していて、そこで小さなポッドを多数起動して
全体の○％を超えたり減ったりしたら、クラスタを増減させて
通常はある程度の余力をもたせておく（遊んでるサーバーがある）という使い方なんだろう
インスタンス数を意識して最小の金額にするためのものじゃないかな
551(2): 2020/01/30(木)19:32 ID:RH+cWAif(1/2) AAS
ECSも、タスク数をCPU使用率などのメトリクスと連動させれば、
CPU数に応じて「タスク数とインスタンス数」を同時に増やすことが可能
何が違うと言うのか
ECSも以前から「それぞれ別々に」インスタンス数とタスク数を増減する事は出来たが、
協調せずバラバラに動くので、
負荷の増加に反応してサービスのタスク数は増えたのに、
インスタンス数がちゃんと増えなかった、
あるいはインスタンス数は増えたのにサービス数が増えないとか
そんな動きになる可能性があった
1つのノードに複数のコンテナがあるような状況では
さらに話がややこしくなっていた
ノードのCPU使用率が一時的に増加していても、それはサービスの需要が増えたからではなく、
定期バッチ処理で負荷が一時的に高くなったのが原因だったり
552(1): 2020/01/30(木)19:38 ID:RH+cWAif(2/2) AAS
Kubernetesはずっと前から
ポッド数によるノード増減ができた
パクったのはECS
自動でノード数の増減が要らない、
常に2台で良いって言うなら
Cluster AutoScalerを使わなくても良い
553(1): 2020/01/30(木)20:00 ID:VJ/WHmRQ(1) AAS
そもそもECSって目的毎にクラスタ立てるもんだろ？
何でもかんでも一つのクラスタで済ませようなどと考えなければ従来のインスタンスベースのスケーリングで問題ない
それこそ「クラウドなんだから」だ
ID:RH+cWAifの主張は、クラウドの中にクラウドを作っているという批判に対する反論としては的外れに感じる
554(1): 2020/01/30(木)20:33 ID:rH68C/el(1/3) AAS
RH+cWAifは別にクラウドの中にクラウドが〜に対する回答ではない様な。
クラウドが〜は自分で解答書いてるし。
>そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい
結局そういうことだよね。
外部ﾘﾝｸ:aws.アマゾン.com/jp/docker/
Q: Docker Swarm、Kubernetes、Amazon ECS の違いは何ですか?
>多くの Docker コンテナを実行する場合は、Docker Swarm、Kubernetes、Amazon Elastic Container Service (ECS) などの
>オーケストレーションツールを使用することで、何千 (または何百万) ものコンテナの開始、停止、監視が可能になります。
日本は法人向けサービスやったとしても会社の絶対数が少ないしそもそも余程のことが無い限り
1サービスあたりのサーバは10台超えることは無い。じゃあ10台でオートスケールやるコンテナの仕組みは何なのさ？
ってニーズに全然答えようとしていない。
555(1): 2020/01/30(木)20:50 ID:obKqsaeD(1/2) AAS
>>551
一番重要なのはコストの最適化なんだから、タスク数もしくは負荷に応じたインスタンス数の増減なんだよね。
> 負荷の増加に反応してサービスのタスク数は増えたのに、
> インスタンス数がちゃんと増えなかった、
そこな。スケールするのがコンテナとインスタンスの
二重になってるからすごく分かりづらい
そもそも一つのインスタンスの中で動くコンテナを増やしても
並列度は上ががっても処理速度は上がらんのよ
（CPUコアを使い切れるようにはなるだろうけど）
パッチ処理みたいに一つのデータを送ってコンテナで処理して終了みたいのであればわかりやすいけど
ウェブサーバーみたいにそれ自体が並列処理対応になってるものの
コンテナを増やしたって何の意味もない。インスタンスの数を増やすか
インスタンスの性能をあげなきゃならないのに、間にコンテナの話が入り込んでくる
556(1): 2020/01/30(木)21:31 ID:rH68C/el(2/3) AAS
>スケールするのがコンテナとインスタンスの
>二重になってるからすごく分かりづらい
分かりにくいのはそうなんだろうけど、インスタンスを跨ぐコンテナはネットワークに
仕掛けしないと駄目だからしょうがないんじゃないの？それはDockerのあの変な
ネットワークの仕組みの為だろうけど。
>（CPUコアを使い切れるようにはなるだろうけど）
結局インスタンス（VM)の上にコンテナ乗っけてるって時点でハードを使い切る
コンテナ技術のメリットは消えており、AmazonのECSはなんちゃってコンテナで
しかない気はする。
557(1): 2020/01/30(木)22:07 ID:obKqsaeD(2/2) AAS
コンテナベースにするなら、インスタンスの存在は完全に見えなくしないとだめだろうね。
そして「これこれの性能を持ったコンテナ」を「いくつ使用するか」で課金する。
あとやっぱりノードのアップグレードに伴う再起動が大変
コンテナ数ノード数が少ないとサービス停止に陥ってしまう可能性が高くなる
アップグレードを放置するとそのうちバージョン古すぎて非対応になるし
なんでみんなk8s頑張ろうとしてるんだろう
殆どの用途では大変なだけじゃないか？
558(1): 2020/01/30(木)22:14 ID:x2o8za8v(2/2) AAS
Kubernetesの真の価値はそこで利用出来るソフトウェアにあるのでは？
サービスメッシュとかデータベースのオペレーターとか
なんかk8sで動くhelmチャートが動く環境が欲しいのでなければ
ECSとかでも良いし
そっちのほうが簡単と思う
クラウドの中にクラウドとか言うけどさ
サーバーに自分でインストールして
動かすソフトを作る側に取っては
Kubernetesだけ対応すれば
あらゆるクラウドで動くものが作れるようになった
自社のソフトウェアが様々なクラウドで動くのは、
ビジネスチャンスに繋がるんじゃね？
ソフト自体を配布するんじゃなくて
サービスとして売りたいなら
好きな物を使え
559: 2020/01/30(木)22:20 ID:rH68C/el(3/3) AAS
例えて言うなら56コア112スレのXeon買ってきてサーバー作って
そこにESXi入れて、CoreOSを20個インストールしてOS１つあたり
5コンテナ入れてk8s組んで、やったぜ俺スゲーとかｗ
そんな感じやな。
でそこで動く肝心なサービスの保守は完全に片手間で1日16時間労働ｗ
恥づｗｗ
560: 2020/01/30(木)22:28 ID:fl66aBkL(1) AAS
仕事でGKE使ってんだけど世の中の8割のサービスはこんな仕組み要らんだろうなーと思いながら触ってる
561: 2020/01/30(木)23:23 ID:8SEpOjSd(1/3) AAS
>>558
ローカル環境でdockerと比べると、k8sは細やかな制御ができる分やりやすい。
562: 2020/01/30(木)23:26 ID:8SEpOjSd(2/3) AAS
k8sはDockerに比べてIngressとロードバランサが優秀。
563: 2020/01/30(木)23:27 ID:8SEpOjSd(3/3) AAS
替わりにマシンスペックを食うわけだが……。コントローラで2W近く使う
564: 2020/01/30(木)23:32 ID:vPq8TLea(1) AAS
k8sとDockerって比べるものじゃないじゃん
565: 2020/01/31(金)06:06 ID:BYA66tlO(1) AAS
スペックを食うってのもなんだかな
566(1): 2020/01/31(金)09:44 ID:zr53MAqg(1) AAS
swarmの事もたまには思い出してあげてください
567: 2020/01/31(金)21:02 ID:PGkHP1z8(1) AAS
>>566
VMからサービス拡大で手軽なクラスタ使いたいから〜、って理由で
Dockerに移行したらのなら、スケール的には一番しっくり来るんだけどね。
流行の技術じゃないから誰も手を出さんのか？まあDocker Swarmできます！
とかじゃ経歴書にかいても自慢出来んだろうけどね。
568(1): 2020/02/01(土)09:45 ID:rnZpf00g(1/6) AAS
ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？
スケーリングされたインスタンス内でCPUと同数のスレッドでサービス立ち上げる事と
何が違うのか全く分からん。事態を面倒くさくしているだけに見えるｗ
569(1): 2020/02/01(土)09:51 ID:a9slqYuq(1) AAS
>>568
デプロイをECSに任せたいだけだよ
自分でホスト弄りたくない
570: 2020/02/01(土)10:02 ID:rnZpf00g(2/6) AAS
>>569
それはASGでホストが起動したときに、スタートアップか何かでgit pullする事と
何か違うの？
571(1): 2020/02/01(土)10:15 ID:Xk5te6Cy(1) AAS
また仮想マシンイメージ最強おじさん？
老害乙wwwwww
572(1): 2020/02/01(土)10:26 ID:+b4DF/Bv(1) AAS
git pullするって
仮想マシンイメージにアプリの内容を突っ込む訳でも無いのか
goとかJavaだったら毎回ビルド？
老害どころの騒ぎではないな
デプロイ成功するかどうか
同じ結果になるかどうか
毎回やってからのお楽しみって感じ？
時間がいくらでもあるなら
そうすれば良いんじゃない？
573: 2020/02/01(土)12:47 ID:rnZpf00g(3/6) AAS
>>571-572
良くわかんねぇけど、もう少し論理的に説明してくれるかな？
うちのシステムは大体それで大丈夫だからね。
574(1): 2020/02/01(土)12:59 ID:Ps7WDj2g(1/3) AAS
今度はDockerじゃなくてgit使えば良いおじさん登場か
それで困ってないなら別に良いんじゃない？
575(1): 2020/02/01(土)13:07 ID:rnZpf00g(4/6) AAS
>>574
だから「ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？」って聞いてるじゃん。
君の反論は、デプロイが複雑な場合においては、有効なこともありうる、ってことでオッケー？
それは分かったよ。
ただ、>>556にあるようにDocker自身はコンテナシステムとしてはイマイチだと思う。理由は557と同じね。
少なくとも変なホスト単位のブリッジはやめにしてPOD単位とかService単位で内部ネットワークにしないと
インスタンスが全面に出てきちゃ、導入する意味が無い。ストレージなんかも必要な部分を予めマッピングして
永続化しないと駄目とか、制限が多いし。こんな事いっても君には分からんだろうけど。
576: 2020/02/01(土)13:18 ID:Ps7WDj2g(2/3) AAS
じゃあ使わなきゃいいんじゃね？
577: 2020/02/01(土)13:25 ID:rnZpf00g(5/6) AAS
マジ質問読めよ文網ｗ
日本語通じないなんてDocker使う以前の話だよｗ
578(1): 2020/02/01(土)13:30 ID:Ps7WDj2g(3/3) AAS
Docker使わなかったらOSアップデートは要らないとでも？
普通に要るでしょ
セキュリティ考慮しないから要らないって話？
579: 2020/02/01(土)13:45 ID:rnZpf00g(6/6) AAS
>>578
ECSの話してるんじゃないの？
ECSは「インスタンスの上」でコンテナを動かすのだから当然Dockerでも
OSアップグレードは必要で、そういった話をするなら、インスタンスOSと
コンテナ上のOSの両方のセキュリティを考慮しなければならない。
580: 2020/02/01(土)15:00 ID:A9loRdi2(1) AAS
ECSとか関係なく
ASG利用の方が信頼性が高い
ECSはASG無しで使えるように設計されてるのか良く分からない
なんか前の登録内容が残ってたり
ECSエージェントのデータを消さないとインスタンスタイプを変更できなかったりした
通常のEC2
・ルートボリュームの内容は再起動に引き継がれる。システムログの内容やSSHして手動設定した内容はインスタンスを削除しない限り残る。
・AWS障害時に自動復旧させるのは可能だが、必ず成功するとは限らない。
・AWSと関係ないOS内部の問題はEC2 Rescueで復旧を自動化できるかもしれないが絶対ではない。
ASG
・ルートボリュームは毎回新しく作られる
・データの保存が必要なワークロードの場合、起動後にスクリプトで別のEBSをアタッチする、S3に保存されたバックアップから復元するなどの方法が必要
・ヘルスチェックをEC2にした場合、システムとインスタンスの2つのチェックのどちらかに失敗するとインスタンスは破棄されて再作成される
・ヘルスチェックをELBにした場合、ELBからのリクエストに暫く応答しなかったら破棄される
いずれの場合も、自前のヘルスチェックシステムがあるなら
それを代わりに使う事は可能だが
そんな物はうちにはない
581: 2020/02/01(土)15:10 ID:lVg3qEIO(1) AAS
キャパシティプロバイダーでEC2のタスク数とインスタンス数を連動させる場合はASGが必須
キャパシティプロバイダーの登場以前はタスク数と連動させるのは諦めて
EC2の台数もタスク数も固定するか
それぞれバラバラに設定して
高負荷時に両方とも作動するよう神に祈る他なかった
キャパシティプロバイダーが要らない場合でも
ASGにしておけばコケても復旧するという安心感はある
インスタンスを終了すれば必ず同じ設定で起動するからだ
それらが要らないならASG無しでも良いんじゃね？
同じEC2インスタンスだと
インスタンスサイズ変更時に
ECSエージェントが登録失敗する問題は何か解決策があるだろう
582: 2020/02/01(土)15:36 ID:uZkIbDS6(1) AAS
ECSについて言えば、3つのネットワークモードが利用可能
bridge
ポートマッピングを設定した場合、
コンテナにランダムなポートが割り当てられ、外部からアクセス可能になる
同じホスト名で外部からアクセス出来るようにしたいなら、ELBやRoute53を併用する
毎回異なるポート番号になるので、デプロイ時、1つのEC2インスタンスに
同じタスクの新旧バージョンを一時的に同時実行する事が出来る
host
ホストOSと同じネットワークに配置する
ポート番号が衝突するので、
デプロイ時に、同じタスクの新旧バージョンを同じEC2インスタンスで同時実行は不可
awsvpc
ホストOSとは異なるENIにタスクを配置する
異なるENIなので、同じEC2インスタンスでも同じポート番号を利用可能な上に
理論上は最高のネットワーク性能を持つモード
ただし、小さめのインスタンスタイプでは
利用できるENIの数が少ないので
配置出来るawsvpcネットワークモードのタスクは少なくなる
583(1): 2020/02/01(土)18:53 ID:ZdsodL/0(1) AAS
俺はGCPメインだからAWSの話はよくわからんなｗ
AGS？ GKEのオートスケーリング機能みたいなもんか？
584: 2020/02/01(土)19:59 ID:wE2puLwI(1) AAS
ASGは多分似たような機能がどのパブリッククラウドにもあるだろう
k8sをAWSで使う場合も
ワーカーノードはASG管理下で、
ルートボリュームはノードを終了する時に捨てるよね
サーバーはいつでも替えの効く家畜だ
k8sでデータベースなどの
ステートフルなワークロードを扱う場合は、
ノードにルートボリュームとは別に
EBSボリュームをアタッチすれば良い
>>583
そもそもASGはオートスケーリンググループの略だから
585: 2020/02/02(日)01:40 ID:9x081f8g(1) AAS
Kubernetes 航海1日目
2chｽﾚ:linux
586(1): 2020/02/02(日)08:39 ID:cuMP7GqL(1/27) AAS
何？よう知らんけどEKSでもインスタンスは見えてるの？
インスタンス（VM）を管理してその上で動くコンテナも管理しろとか
コンテナの意味なくね？
587: 2020/02/02(日)08:52 ID:vTMq3yW0(1/5) AAS
だからコンテナはアプリをデプロイしやすくするためのものだって言ってんだろ
588(1): 2020/02/02(日)09:08 ID:cuMP7GqL(2/27) AAS
じゃあ、今ここでDocker関連の話題を書き込んでいる連中はもれなく
デプロイに問題があってDocker使ってるという認識なのｗｗ？
デプロイをコンテナ以外で解決するくらいならサービスメッシュだ
オペレータだhelmチャートだと学習したほうが効率が上がると判断しているのｗ？
589: 2020/02/02(日)09:42 ID:TWOzawm+(1/12) AAS
>>588
は開発どうしてんの？
それぞれバラバラに環境作って開発？
開発、QA環境へのデプロイとテスト
本番環境へのデプロイまで一貫した環境で行えるのがコンテナ技術のメインの魅力だろう
Kubernetesは複雑すぎる気はするが
他に選択肢があまりない
590(1): 2020/02/02(日)09:54 ID:TWOzawm+(2/12) AAS
以前、開発も本番も同じ環境においてるという
狂気の環境で開発した事がある
ローカル開発環境はそもそも存在せず
理由は環境の複製が面倒だから
AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた
サーバーに直接Apacheをインストールしており、
基本的にphpをアップグレードする時や
phpの拡張機能を入れるときは
一か八かの賭けに出る必要があった
AMIを複製して他環境で試す？
そんなのやるぐらいならもうDocker使えよ・・・ってなる
それが一番色んな環境に運ぶの楽じゃん
591(1): 2020/02/02(日)10:02 ID:vLvuWMc2(1) AAS
>>586
昔ながらの方法だったらVMインスタンスもアプリのデプロイも管理しなくて良いとでも言ってるのか？
文句あるなら代替案出せや
スペックに応じたインスタンスが必要なのは
昔ながらの方法でも一緒だろ
592(4): 2020/02/02(日)10:31 ID:cuMP7GqL(3/27) AAS
>>591
代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が
10台20台程度なら入れない方が良いと思う。いつの日か>>557が書いたように
完全にコンテナだけ見ていればOKになるなら入れても良い。
例えば10コアのCPUを10台用意して、30個をフロントWEBに、20個をバックエンドに、
30個を同期サーバ、10個をその他、残りはautoscaling用、1CPU=1コンテナとか
このレベルで意思決定が出来て、そのとおり動くならマイクロサービスは素晴らしい
といえるけど、現状そうなってないんだろ？コンテナが物理サーバーに対して透過的
見えるレベルに到達してないつーか。
いつかそうなるんだろうけどね。
今は面倒なだけという気がする。
593(1): 2020/02/02(日)11:04 ID:mAYLnTD8(1) AAS
>>592
それってデメリットか？
算数が出来れば計算出来るだろ
小規模環境なら台数固定で良いし
OSや、ログ、メトリクス用ポッドの分だけ余裕をもたせて空けておけば良い
それぐらい計算できるだろ？
もしかしてワーカーノードは全部同じグループとか思ってる？
データベースはこのラベルが付いてるノードだけに配置とか、出来るだろ
負荷がデータベースに集中しがちなら、データベースだけ大きなノードのグループで構成するとか
1つのグループに
ごった煮にして配置したりすれば
非常にややこしくなるから
誰もやらない
594: 2020/02/02(日)11:29 ID:cuMP7GqL(4/27) AAS
>>593
そういった諸々に対して>>546>>550-555のような問題がありますよ、という話じゃなかったの？
まあ導入前段階で比較したい、という人と既に導入しちゃった人じゃ観点が合わんのはしょうがないけど。
前の人は既存部分との違いを知ることが主な観点になるけど、既に入れちゃった人はその結果起きた問題を
解決することが観点になるからねｗ
595: 2020/02/02(日)11:43 ID:l4msUzoZ(1) AAS
なんか話が噛み合わないと思った
ノードを常に余らせている大規模環境じゃないと使えないとか
>>550
あらゆる種類のワークロードを
1つのノードにごった煮だと勘違いしていたなら納得
596(1): 2020/02/02(日)11:43 ID:cuMP7GqL(5/27) AAS
>>590
これも、そもそもDocker以前の環境すらまともに運用できなかった人と
Dockerを比べてもなぁ？という話で。もしその狂気の環境の人がDocker使って
k8s入れたとしたら、余計酷くなるだけ（使いこなせるわけが無い）
> AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた
こういう言い方もずっと前からあるけど、実際コンテナとしても「家畜のように」は使えんだろ。
本番で運用するときは当たり前だけど一見ごみの様にしか見えないものでもトラブル解決に
役立ったりするからね。/var/log/httpdだけを永続化しときゃ済むって話じゃない。
1ヵ月後に顧客からトラブルの相談があって、既に再デプロイして非永続領域は消えちゃいました、
ですむなら良いけど。
じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。
597(1): 2020/02/02(日)12:01 ID:TWOzawm+(3/12) AAS
>>596
>じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。
本当に全くDocker使ったことないのに批判してるんだなw
説明しよう
ログは標準出力か標準エラー出力に吐くから永続化はしない
必要ならロギングドライバーを設定するなどして
別サービスに転送する
AWS+ECSならCloudWatchに転送が一番楽
k8sは今のところロギングドライバーの設定はできないので、
コンテナのログを集めるDaemonSetがそれぞれのノードにデプロイするのが一般的
これで全ノードのログを残せる
永続化するのは再起動しても絶対残っていなければならない
データベースのデータなどだけ
どこを永続化するかで悩んだことなんてない
598(1): 2020/02/02(日)12:12 ID:cuMP7GqL(6/27) AAS
>>597
そういやそういう事やってたなとは思うけど、君が説明しているログ収集云々は
汎用的なDockerの話じゃ無くてベンダーが用意している部分ね。
>AWS+ECSならCloudWatchに転送が一番楽
ん？結局こういうことしたらベンダーロックインって事じゃないの？
> どこを永続化するかで悩んだことなんてない
そうなの？
しかしそれはDBとWEBだけの単純サービスだからじゃないの？
ウチのはある領域に一時的なファイルを作って、S3とかにアップするけどそれが
出来てないよ、とかは普通に来るからね。
599(1): 2020/02/02(日)12:25 ID:LuowLFof(1/5) AAS
ベンダーロックインw
あのさ、ECSでコンテナからCloudWatchに出力するのなんて数クリックでできるわけ。
人的なコストなんかほぼゼロ。
ベンダーロックインっていうのはこれまでの投資が無駄になるから他のベンダーへ移れない状態であって、
そもそも投資がゼロなら何の問題もないの。言ってる意味わかる？
600: 2020/02/02(日)12:29 ID:TWOzawm+(4/12) AAS
>>598
ECS時は最も手軽な選択肢はCloudWatchってだけ
他にも選択肢はあるが
とりあえずAWSで動けば良いなら一番手軽
手間や金がかかっても
とにかくベンダーロックインは嫌だって言うなら
k8sとELKスタックとかになるんでは
ファイルアップロードにS3使えてない場合は
・2台以上でWebサーバーの構成をするのを諦める
・多少遅くても良いならAmazon EFSに置く
どちらもやらずに解決する銀の弾丸はない
601(2): 2020/02/02(日)12:35 ID:cuMP7GqL(7/27) AAS
>>599
なんつーかそれを聞いてもやっぱり、10台程度のサービスでEKS、ECS面倒臭いという
のが結論やね。100台なら話は全く違うけど。じゃあ10台〜100台の間のどのへんが
ボーダーなのかって点には関心あるけど。
どこが汎用のDockerの話でどこがベンダーに依存するのかとか、面倒くさすぎ。
質問を568に戻そうぜ。
「ある1つのインスタンス内で、1プロセスでCPUと同数のスレッドと立ち上げる事と、
CPUと同数のコンテナを立ち上げること」は何が違うの？
602: 2020/02/02(日)12:38 ID:TWOzawm+(5/12) AAS
そもそも規模小さかったらリソースの割当に悩む事ないから
その批判がそもそも的外れ
603: 2020/02/02(日)12:40 ID:LuowLFof(2/5) AAS
>>601
その2つを比べるのはおかしい
1コンテナ内で複数スレッド立ち上げてもいいし、goなどのマルチスレッド前提の言語ならむしろその方が一般的。
604(1): 2020/02/02(日)12:41 ID:cuMP7GqL(8/27) AAS
>とにかくベンダーロックインは嫌だって言うなら....
>ファイルアップロードにS3使えてない場合は...
こういう所とかも全部「既存システムでは存在しない問題点に対して解決方法を提示している」様に思えてならん。
他の人はそうは思わんのかな？
605(1): 2020/02/02(日)12:46 ID:LuowLFof(3/5) AAS
>>604
全く意味がわからないな
ログ収集もS3へのアップロードの失敗も既存システムで存在するだろう
606(1): 2020/02/02(日)12:59 ID:cuMP7GqL(9/27) AAS
>>605
VMは再起動しても永続化してるんだから問題調査は可能でしょ。
607(1): 2020/02/02(日)13:04 ID:TWOzawm+(6/12) AAS
S3とか使ってないレガシーシステムでも
ECS使うのは可能
可用性が重要じゃない社内用アプリで
インスタンス1台だけのECSクラスターで
データは全てEBSに書いてる物ならある
ログはDocker経由でCloudWatch Logsに出すようにしてるが
時々OSのAMIとか
ECSエージェントを更新すれば
実行環境は最新の状態に保たれる
ログやメトリクスはマネジメントコンソールから見られるし、
デプロイするだけならSSHすら要らないし楽
使わない理由がない
アプリ部分はAWSとか使ってないので、
移そうと思えば他クラウドにも移せる
今の所やる予定ないし今後も無いと思うが
608(1): 2020/02/02(日)13:05 ID:LuowLFof(4/5) AAS
>>606
オートスケーリング使うなら勝手にterminateされて全部消えるよ
大した規模じゃないからオートスケーリングいらないってんなら、君にはコンテナなんて要らないから帰ってね、としか
609(1): 2020/02/02(日)13:07 ID:cuMP7GqL(10/27) AAS
>>608
オートスケーリングはそういう用途じゃないな。
繁忙期のサーバー落ち＞障害調査
の場合にのみ使用するとしか言えない。
分からないなら答えないでねとしか。
610: 2020/02/02(日)13:17 ID:TWOzawm+(7/12) AAS
だからログはCloudWatch Logsに送ればいいって話だろ？
コンテナ毎のCPU使用率やメモリー使用量はメトリクスはECSエージェントがCloudWatchに送ってくれる
611(1): 2020/02/02(日)13:17 ID:LuowLFof(5/5) AAS
>>609
そもそもログ収集してないのに問題のインスタンスの特定とかどうすんの？
台数が少けりゃスナップショット撮ってれば努力と根性でなんとかなるかもしれないけど、
うちの場合はその作業が一度発生したら自前でログ収集の仕組みを構築するコストを余裕で上回る工数だねえ
612(1): 2020/02/02(日)13:20 ID:cuMP7GqL(11/27) AAS
>>607
>ログやメトリクスはマネジメントコンソールから見られるし、
これもね、じゃあ障害解析のために開発者全員がマネジメントコンソール
見れて良いのかとか、微妙で面倒くさい問題が出そうな気がするんですよ･･･。
613(1): 2020/02/02(日)13:26 ID:cuMP7GqL(12/27) AAS
>>611
自分が携わっている範囲内で言えば、インスタンスが特定できずに問題が解決
しなかったなんてことは無いな。コストがかかりすぎた、という事も無い。
ド素人じゃないんだし、それ位分かるよな？としか･･･。
614: 2020/02/02(日)13:27 ID:TWOzawm+(8/12) AAS
>>612
ログを取るためだけにSSHするのは良いのかよw
AWSの組織機能で細かくアカウントをアプリ毎に分ける、
IAMロールを最小の権限のみにするなどした方がよほどセキュアだ
Cloudwatch Logsは
ローカルにログをダウンロードせずに
簡単な検索や分析も出来る
これもセキュアだろう
615(1): 2020/02/02(日)13:59 ID:bYwPQj4X(1) AAS
>>613
それインスタンスが数百台以上あっても同じこと言える？
結局何が言いたいのか知らないけど、何が手でSSHして回れる程度の台数でコンテナなんか要らん、と言いたいならまあその通りだと思うよ
616: 2020/02/02(日)14:05 ID:cuMP7GqL(13/27) AAS
>>615
だから結論は>>601だと言っているでしょ。
以後のやり取りのすべてを見てもやはり601やね。
10台以下で運用するのは、まあ、趣味の世界やな。。
悪くは無いけど運用上実利がある訳じゃないよと。
まあ興味があるならやっても良いよ、あるいはもっと大きな
サービス運用業者に転職を視野にいれてしれっとやってみるとか、
そんな感じと思ったね。
617(1): 2020/02/02(日)14:25 ID:KVZqynku(1) AAS
結局何が言いたいのかサッパリ分からんやつだったな
小規模だったらそもそも台数の調整とか要らないだろって話は無視か
618: 2020/02/02(日)14:34 ID:cuMP7GqL(14/27) AAS
>>617
君の言っている事こそ意味不明ｗ。
小規模で台数の調整が要らないらならEKSもECSも要らないっしょ。
ちなみに小規模であることと台数の調整が不要であることはイコールではない。
小規模でも繁忙期に台数増やしたいとかは当然ある。
619(1): 2020/02/02(日)14:43 ID:TWOzawm+(9/12) AAS
サーバーを家畜化した方が運用が楽で信頼性も高いのは
1台でも100台でも変わらないと思う
総利益が大きいのはそりゃ100台だろうが
そもそもサーバーの家畜化もできてなかったら
どうやって水平スケールするのか
Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが
620(1): 2020/02/02(日)14:50 ID:TWOzawm+(10/12) AAS
Dockerなしでも家畜化出来てたら
それぞれのサーバーにSSHしてログ取ったりなんていらんはずだけど
まさか手作業で環境を複製してASGもどきをやってるのか？
超無駄じゃね？
ASGでやれよ
621: 2020/02/02(日)15:15 ID:cuMP7GqL(15/27) AAS
>>619
>信頼性も高いのは
信頼性が高いといっているのは何を根拠に言っているのか知らんが、
インスタンスの上にDockerエンジン乗せてその上にサービスを展開している鯖と
インスタンスの上に直接サービス(httpdとか）のせてサービス展開している鯖はどっちが信頼性高いのって話だが？
どっちなのｗ？前者は単純に数が増えているように見えるが？
>1台でも100台でも変わらないと思う
本当にそう思うの？既に「入れてしまった人」は当然操作にも慣れてるだろうし、そもそもコンテナ外して
運用するのは2度手間になるから、1台でもコンテナで、になるんだろうけど本当に1台しか運用していない
会社に自信を持ってそれ、提案できる？1台でもEKS入れましょう、と。
>どうやって水平スケールするのか
つまり君はコンテナ以外じゃやったことが無いって話なんだろ？
>Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが
俺が直接運用しているサービスはそうやね。例え鯖1台でも「趣味として」EKS化しても全然悪くない
が、世の中にはそうでない人もいるわけよ。500円位の共用WEB鯖＋DBとか。
あるいは2万円の1台2台の専用鯖とか。
そういう人に本当にお勧めできるの？
アマゾンに移行して、コンテナ化してEKSしましょう、とか。
本当に？君は本当にそう思うの？
>>620
この書込みは全く意味不明。
宇宙語話してるの？そもそも「家畜化」ってIT用語なのｗ？
君以外の誰にも通用しない気がするがｗｗ
上下前次1-新書関写板覧索設栞歴
あと 381 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.071s