X

Docker Part3

■ このスレッドは過去ログ倉庫に格納されています
1login:Penguin
垢版 |
2019/03/08(金) 14:40:20.55ID:VDOvuQ0J
LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/
487login:Penguin
垢版 |
2020/01/21(火) 00:08:02.28ID:3DzPFxLf
>>486
> 概要把握したい向きもあるだろう
一行の見出しでは情報を伝えられないだろ？

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

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

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

忘れてたら毎月600円課金されてた
491login:Penguin
垢版 |
2020/01/24(金) 20:27:25.19ID:Pc7e1TLp
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ドル
492login:Penguin
垢版 |
2020/01/24(金) 20:40:22.15ID:Pc7e1TLp
HAとか気にしなければさらに安く出来るが
大事な環境でやるのはおすすめしない

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

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

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

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

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

用途としてはPythonの開発環境をDockerに組もうと思っているのですが
どちらを使えば良いのか教えていただけると幸いです
496login:Penguin
垢版 |
2020/01/25(土) 18:53:06.86ID:ES14vB7p
通常は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を使う
497login:Penguin
垢版 |
2020/01/25(土) 19:01:18.86ID:ES14vB7p
> 用途としてはPythonの開発環境をDockerに組もうと思っているのですが

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

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

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

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

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

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

↑この違い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そうだよね？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自動でノード数の増減が要らない、
常に2台で良いって言うなら
Cluster AutoScalerを使わなくても良い
2020/01/30(木) 20:00:23.22ID:VJ/WHmRQ
そもそもECSって目的毎にクラスタ立てるもんだろ？
何でもかんでも一つのクラスタで済ませようなどと考えなければ従来のインスタンスベースのスケーリングで問題ない
それこそ「クラウドなんだから」だ
ID:RH+cWAifの主張は、クラウドの中にクラウドを作っているという批判に対する反論としては的外れに感じる
2020/01/30(木) 20:33:30.31ID:rH68C/el
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台でオートスケールやるコンテナの仕組みは何なのさ？
ってニーズに全然答えようとしていない。
2020/01/30(木) 20:50:52.19ID:obKqsaeD
>>551
一番重要なのはコストの最適化なんだから、タスク数もしくは負荷に応じたインスタンス数の増減なんだよね。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>583
そもそもASGはオートスケーリンググループの略だから
2020/02/02(日) 01:40:45.56ID:9x081f8g
Kubernetes 航海1日目
https://mao.5ch.net/test/read.cgi/linux/1553389453/
2020/02/02(日) 08:39:22.80ID:cuMP7GqL
何？よう知らんけどEKSでもインスタンスは見えてるの？
インスタンス（VM）を管理してその上で動くコンテナも管理しろとか
コンテナの意味なくね？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況