Docker Part3

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/

>>454
あのさあ、せっかくコンテナの外から
仮想化して可搬性持たせてるのに
それをぶち壊すような使い方したら
Docker使う意味ないでしょ

>>453
間違った使い方ってのは貴方の主観でしょ。

メモリ1G程度の違いが何の問題になるのか、全く分からないのだがw
自宅で運用してるが、消費電力で2W程度の違いでしかない。

VPNのIPの話はk8sのサービス→ロードバランサ使えば瞬時に解決する話。

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

そもそもとしてvpnはクラウド経由させれば細かいIPの設定は不要なわけだが、その辺りの知識も無さそうw

>>456
> メモリ1G程度の違いが何の問題になるのか、全く分からないのだがw
金かかるだろ？何を言ってるんだろうか

あと電気代じゃねーぞ。まあ電気代の話にすり替えてごまかそうとしてるんだろうけどなｗ

>>457
なにクラウド使う前提にしてんの？ｗ
VPNがクラウド経由させれば不要とか
何をどう使えばそうなるのか言ってみ

つまりいくら金がかかるのかって話だ

Dockerコンテナをシステム・サービスのように使う例などいくらでもある

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

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

kiamやElasticsearchのhelmチャートが
ホストOSの設定を変更するのは、あくまで一例
Dockerコンテナ内でやらずとも、systemdユニットでやる方法がある

DockerでOpenVPNってこれ？
https://github.com/kylemanna/docker-openvpn/blob/master/README.md

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

systemdの初期化スクリプトも入ってる
これ使えばいいんじゃね？
知らんけど

今回問題にしてるのは、システムサービスじゃなくて
ルーティングサービスだ

特権与えればホストOSの設定にアクセス出来るから
基本的にコンテナ外でできる事は
コンテナ内でも出来る

iptablesの設定だって変えられる
変えて何が悪い？
実際やってる人なんていくらでも居るじゃん

https://github.com/hwdsl2/docker-ipsec-vpn-server
自分はこれつかってIPsec/L2TPサーバーやらせてるな

皆さんありがとうございます。

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

OpenVPNコンテナは、alpineスクラッチからDockerfileで手構築です。
元々オンプレで動かしてたものをコンテナ化した都合から、色々いじってるので。
ただアプローチとしては>>464さんの言うとおりだなぁと思いました。
権限与えてるんだから、コンテナ内からホストにルーティング投げればいいだけですね。
その方向で試してみたいと思います。

openvpnのコンテナ探して、やり方をそのままやった方が早そう

dockerでもdocker-composeでもいいんだけど、
シェルスクリプトを作る以外でマルチステージビルドの
ようなことを他の手段はないですかね？

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

FROMにイメージ名が書いてあればそれをpullするけど
そうじゃなくてイメージをアップしたくなくて、
ローカルでビルドしたい。それを自動的にしたい。

>>468
ローカルにdockerイメージリポジトリを作ればよい。

dockerイメージリポジトリにイメージをアップしたくないんですよ

いやだからローカルに作ろうよ

いや、だからアップしたくないって言ってるやんｗ
相手の環境なんかわからないんだからさ

相手に、このコマンドを実行すればOKですって書くのはまだいいけど、
相手に、ローカルに作ってください、作ってアップしてくださいって
手順を長々と書くのはダメやろ？

相手ってなんだよ
いきなり新しい登場人物か

できるけど

>>474
何も増えてないよ。
「dockerイメージリポジトリにイメージをアップしたくない」と言ってるのに
それを無視するから、無視できないように補足しただけ

最初はなかった「相手」が増えてるじゃん

じゃあ「相手」は無視していいよ
関係ない話だから

利用マニュアルにコマンド並べればいいんじゃないの？
シェルスクリプトとPowerShell両方用意してるプロジェクトもあるね

>>468
そのDOCKERイメージをtgz形式にsaveしたものを、
dockerリストアコマンドでイメージリストに展開してから、処理を行えば？

あ、シェルスクリプト禁止か。

>>480
禁止っていうか、シェルスクリプト作るなら誰だってできるって話
Dockerfileビルド時に依存したDockerfileも自動的にビルドする方法は
マルチステージビルド以外では方法はなさそうね

むしろマルチステージビルドという仕組みがあるのね

Docker Hubのさぁ、Automated Buildでさぁ
GitHubのREADME.mdを中途半端に持ってくるのやめてくれないかな
リンクあるだけでいいだろ、あれ誰が嬉しいんだ？

>>483
一理ある

>>483
一理あるから、Docker Hubに文句言ってきてください。

>>483
デメリットあるの？
概要把握したい向きもあるだろう

>>486
> 概要把握したい向きもあるだろう
一行の見出しでは情報を伝えられないだろ？

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

でもAutomated Buildを使うと、GitHubのREADME.mdを
表示させることしか出来ないんだよ
丁寧に書いてもAutomated Buildが走ると消されるｗｗｗ

Amazon EKSが50%値下げだってよ
でもまだ高い、クラスター1つくらいは
タダにしてくれよ

クラスター使ったことある？
高いの？

いくらすたー？

googleも無料枠だと無理だからねえ。
それ以前にAWSも無料枠欲しいな。

忘れてたら毎月600円課金されてた

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ドル

HAとか気にしなければさらに安く出来るが
大事な環境でやるのはおすすめしない

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

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

k3sとか使えばもっと安く出来るかもしれないが
やってない

CVE-2019-5021
いまいちこの脆弱性がよくわからないんだけど、
どういうシナリオで攻撃が成功するの？
攻撃者は何を使うの？docker exec？

ちょっとした疑問なんだけどさ、docker pullってあれ
レイヤーごとに並列でダウンロードしてるよね？

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

その観点からのレポートってどこかにない？

初めてDockerを触ろうと思っています
Windows10Proで動かしたいんですが調べてみると
Docker for WindowsとDocker Toolboxのどちらを入れれば良いのか分かりませんでした

用途としてはPythonの開発環境をDockerに組もうと思っているのですが
どちらを使えば良いのか教えていただけると幸いです

通常は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を使う

> 用途としてはPythonの開発環境をDockerに組もうと思っているのですが

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

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

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

作ったものがどこでも動くから、開発環境はどこでもいい。
どこでもいいからWindows10ProでPython開発環境として一番便利なWSLが推奨

別にDockerを開発環境にしてもいいのに
このスレではそれやると発狂する人がいるよね

開発環境としてDocker(というかコンテナ)使うのは環境汚さないで済むから寧ろ推奨する
VSCodeのRemote Developmentなんかのおかげで開発環境としてのコンテナがものすごく扱いやすくなったのも大きい

今まで仮想マシンや物理マシンに対して、ansibleみたいなツールを使って設定の自動化をしていた
これがdockerになると、コンテナに対する設定はdockerfileに書くから、ansibleみたいなツールは必要なくなるという認識でええのかね

>>500
Ansibleのメリットは複数のホストに跨った設定を一貫して管理できることであり、
そもそもDockerfileで置き換えられるような用途であればシェルスクリプトで十分だ
元々Ansibleなんか必要ない
コンテナ時代にAnsibleを使うとすればクラスタの構築や管理においてだが、普通はGKS、EKS、ECS使ってポチるだけだから小難しい構成管理なんか要らない

ECSを動かすにはクラスターが必要
クラスターは通常VPC、起動テンプレート、ASGが必要
ECSタスク定義やサービスが必要
定期実行はスケジュールドタスクの設定が必要
プライベートネットワークにEC2を置きつつ
EC2をインターネットに繋ぐにはNATゲートウェイが必要
HTTPの負荷分散やローリングデプロイには
ELBが必要
CDNにCloudFrontが必要
データの保存先としてRDSやS3も必要
一部リソースはIAMロールの設定も必要
イメージ置き場にECRリポジトリも必要

これ全部ポチポチでやんの？
terraform使えよ

>>496-499
ありがとうございます
まずはforWindowsでDocker自体に慣れてみます

>>500
Ansibleでできることを中の人が教えます - インストールと実行?EC2へのNginx投入までを学ぼう
https://employment.en-japan.com/engineerhub/entry/2019/04/12/103000

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

↑この違い

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

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

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

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

DockerベースになるとオーケストレーションはKubernetesを使うことが多い
守備範囲を広げたAnsibleは、元の構成管理だけをするように戻りつつある
いろいろ手を広げすぎたんだよ、やつは。

>>502
GCPならデプロイメントマネージャーという
クラウドサービス標準で、自社のクラウドを適切にサポートした
純正機能があるわけだけど、そこに外部が作ったterraformを使う意味あるの？
terraformという第三者が絡むせいで制限とか互換性問題とか生まれてるでしょ？

> そもそもDockerfileで置き換えられるような用途であればシェルスクリプトで十分だ

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

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

リダイレクトとかパイプとか、実行環境を整える所から必要になってめんどくさい。

Ansibleが担うのはprovisioningでDockerなどのコンテナはdeploymentのイメージがある

AWSはCloudFormationあるけど
terraformより色々使いづらい点が多い
AWS製にも関わらず
たまにCloudFormationでだけ設定できない項目があったりする

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

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

この質問が投稿されたのは2016年10月だが
2020年になっても放置
忘れられているっぽい

まあ本家のツールが使いにくいっていうのならTerraformとかの意味があると思うけど
あとAWSとGCPを行ったり来たりしたり、同じものを別々の場所に構築するとか
コード共通でできるんでしょ？しらんけどｗ

マルチクラウドは出来るらしいがやったことない
GCPやAzureは使ったことが無いし

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

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

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

Kubernetesを使ってもインフラの管理から完全に逃れることはできない

TerraformのKubernetesプロバイダーで
helmのデプロイやKubernetesリソースのデプロイも出来る
TerraformのAWSプロバイダーでIAMロールを作成して
kiamで特定ポッドのみにAWSへのアクセス権限付与したりする合わせ技も可能

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

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

helmは最近v3が出たが
公式Terraformプロバイダーはまだv2までの対応

なにか便利な機能を提供してくれるならいいけど、
「使い方を変えるだけ」の道具はいらないなぁ

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

そしてそのプラバイダーが、ある機能に
対応してない困ったぞーっていうのを
永遠と繰り返してるでしょ？

新しいものにどんどんチャレンジして報告するべきじゃないのかな。
それがコミュニティへの貢献ってものでしょ。
キミたちは人柱なんだから。

WindowsのDocker Desktopを2.2にアップグレードしてから、マウントしたボリュームが時々書き込めなくなってエラーになる状態になって
2.1に戻したら直った
調べたら2.1から2.2で内部構造がだいぶ変わってるんやね

>>504
その状態でansibleにやらせる構成管理ってなんなんや
dockerを動かす物理マシンの構成管理だけやるという意味なんか

この前、Docker HubのREAME.mdがGitHubのREADME.mdを中途半端に
持っていくって話をした件だけどGitHub Actionsで同期取るっぽいのがあった
これで指定したやつを持っていってくれるかも
https://github.com/marketplace/actions/docker-hub-readme-description-sync

k3s使ったらメモリー1GBのインスタンス3つでもHA出来る？

k3sはメモリ512MBしか（笑）食わないんだろ？
ならアプリが512MBまでなら動くんじゃね？

k3sでこれだけだと、k8sはどんだけ食うんだよｗ
カーネルの使用メモリが少なくても台無し

workerは別途用意するだろJK

本家k8sは1GB RAMでは足りない気がする
kiamのサーバーと
helm v2のtiller
kube-iam-authenticator

controllerにこの3つを置いているが
2GBから1GBに減らしたらAPIサーバーが使えなくなった
だから本家は最低でも2GBのメモリーが必要

etcdも同居してるからさらに厳しい

なんでk8sってそんなにメモリ食うんだろう？
ただコンテナを管理するだけの仕組みじゃんか

高いVMインスタンスを売りつけるための
戦略としか思えないな
ウェブサーバーとか数十MB程度で動くのに
k8s化した途端1GBとか必要になる。アホかと

他のクラウドはコントローラーがタダで使えるらしいが
AWSだけまだ72ドル掛かる
高杉

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

>>523
GKEは安いの知ってる？

ワーカーノードは1GBでも良い
コントローラーノードの金が気になるならGCP行ってGKE使え
うちもGKE使いたい所だが
AWSを使わねばならない
のっぴきならない事情がある

kubernetsとかさ、クラウドの上にクラウドを作ってるみたいで
気持ち悪いんだよね。せっかく便利に使えるようになったクラウドを
なぜコンテナベースで再発明するのか？

>>526
インフラエンジニアの雇用を維持するためだよ。マジで。
自社サービス系のインフラエンジニアって基本的にトラブルがなければ仕事ないから、
自然と問題なく動いているもののオーバーエンジニアリングに向かうものだ。

オーバーエンジニアリング程度なら良いけどさ
メモリ食い過ぎで前より不便にしてるだけなんだよな
インフラ系って、変わってるだけで、何も良くなってない

>>528
いや、だからGKE使えよ？
コントローラー無料だろ？

>>526
元々クラウドのための仕様なんだが……。

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

規模が小さいとこの利点（オートスケーリング）が意味をなさなくなる。

1台しかないならdocker-composeでよくね？
1台しかないなら

従来は高価なオンプレを1台買ってスペック余らせるのが普通だったが、今はクラスタにする事で、オートスケーリングによりスペック（≒コスト）を最適化できるようになった。

ハイスペック1台ならdockerで十分だが、コスト面で最適化されてるかな？という話。

>>532
それだけならECSとかで十分でしょ
k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ

>>533
k8sはECSより高機能で汎用的だが学習コスト高めという印象。ECSはベンダー製なので、クラスタに関してはその通りだろうが、ベンダーロックインの問題がある。

ベンダーロックインの問題を気にせず、ECSで案件が済むならECSだろう。

たかがコンテナ立ち上げるだけのことにベンダーロックインねえ
事業視点で言えば、k8sに習熟した少数のエンジニアにインフラをロックインされることの方がよほどリスクが大きいと思うけどね

>>528
単に使い所を間違ってるだけとしか思えんが
そもそも別にk8s使わなくてもdockerはある程度規模に応じたオーケストレーションを標準に
近い形で用意しているはずで、それでは管理できないほど巨大な規模のサービスを運用するから
k8sですよ、って事で、当然メモリが食いすぎとか文句言う人が使う物じゃない気はする。
そういう人にはもっと小規模な物あるでしょ？
昔Googleの論文元にHadoop作って訳も分からずに食いついて先進的だカッコいいぜ俺スゲーとか
いって後からやっぱ遅ーえわこれｗとかいってた連中思い出すね。
自分たちが間違った場所に適用してるとは最後まで考えないｗ

>>535
Amazonがk8sのサービス始めたのはこの理由らしいから、そういう意見も多いということなのだろう。

個人的にはk8sよりマルチビルドのdocker file の方が難解だな

>>533
> k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ

そうだよね？

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

そこにGKEを持ってきて使いづらくしたと思ったら、
どうせコンテナベースで課金とかするでしょ？
なんでクラウドの中にさらにクラウド作ってるんだろうって思う

>>537
> 個人的にはk8sよりマルチビルドのdocker file の方が難解だな

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

あんなの、中間ファイルは不要だから
前のイメージでビルドしてできた生成物のみ
コピーして使いましょうってだけじゃんか

k8sの嫌なところは短いタイミングで強制アップデートな所だな
これがあるからストレージとしては使えない
データベースは別のサービスを使えってことなんだろうけど、
これがあるからHAの代わりにはならないんだよね

自前k8sなら誰も面倒見てくれないので
アップデートもされない
証明書の期限短くすると
期限切れした時にAPIサーバーと通信できなくなるけど

APIサーバーの証明書は自動更新機能があった気がする

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

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

サーバーレスはコールドスタートによる遅延の問題なども多分まだある

サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る

とは言ってもノードの起動は時間がかかるので
すぐには無理だが

サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る

とは言ってもノードの起動は時間がかかるので
すぐには無理だが

>>539
他人が書いたのを検証するのが難しいってことね。他人に依存するかどうかという視点の話。

>>543
ノードの増減はk8sなくてもできたじゃん？

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

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

k8sはプロジェクト単位で使うものじゃななくて、
会社として広大なクラスタ空間を予め確保して、その中で複数の異なる
サブプロジェクトをいくつも動かすって使い方をする
Googleぐらいしかまともに使えないよ

k8sはノード＝1つないし少数のそれぞれ違うポットを配置するという使い方じゃないんだよね

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

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

自動管理されたHA環境ではないんだよね

ECSは当初タスク数がEC2インスタンス数と連動しない残念仕様だった

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

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

5タスクを同時に動かそうとすると、
5台のEC2インスタンスが生成される
超シンプル

ECSサービス開始当初はEC2の数とタスクの数を連動させる機能が
無かったが、去年追加された

>>548
それは一般的な使い方としてはわかりやすいし、できるべきだよね。
ただk8sのそもそもの使い方としては、ずれてるんだと思う

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

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

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

k8sはある程度の空間を確保していて、そこで小さなポッドを多数起動して
全体の○％を超えたり減ったりしたら、クラスタを増減させて
通常はある程度の余力をもたせておく（遊んでるサーバーがある）という使い方なんだろう
インスタンス数を意識して最小の金額にするためのものじゃないかな

ECSも、タスク数をCPU使用率などのメトリクスと連動させれば、
CPU数に応じて「タスク数とインスタンス数」を同時に増やすことが可能
何が違うと言うのか

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

1つのノードに複数のコンテナがあるような状況では
さらに話がややこしくなっていた
ノードのCPU使用率が一時的に増加していても、それはサービスの需要が増えたからではなく、
定期バッチ処理で負荷が一時的に高くなったのが原因だったり

Kubernetesはずっと前から
ポッド数によるノード増減ができた
パクったのはECS

自動でノード数の増減が要らない、
常に2台で良いって言うなら
Cluster AutoScalerを使わなくても良い

そもそもECSって目的毎にクラスタ立てるもんだろ？
何でもかんでも一つのクラスタで済ませようなどと考えなければ従来のインスタンスベースのスケーリングで問題ない
それこそ「クラウドなんだから」だ
ID:RH+cWAifの主張は、クラウドの中にクラウドを作っているという批判に対する反論としては的外れに感じる

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台でオートスケールやるコンテナの仕組みは何なのさ？
ってニーズに全然答えようとしていない。