[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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
省7
581: 2020/02/01(土)15:10 ID:lVg3qEIO(1) AAS
キャパシティプロバイダーでEC2のタスク数とインスタンス数を連動させる場合はASGが必須
キャパシティプロバイダーの登場以前はタスク数と連動させるのは諦めて
EC2の台数もタスク数も固定するか
それぞれバラバラに設定して
高負荷時に両方とも作動するよう神に祈る他なかった
キャパシティプロバイダーが要らない場合でも
ASGにしておけばコケても復旧するという安心感はある
インスタンスを終了すれば必ず同じ設定で起動するからだ
それらが要らないならASG無しでも良いんじゃね？
同じEC2インスタンスだと
省2
582: 2020/02/01(土)15:36 ID:uZkIbDS6(1) AAS
ECSについて言えば、3つのネットワークモードが利用可能
bridge
ポートマッピングを設定した場合、
コンテナにランダムなポートが割り当てられ、外部からアクセス可能になる
同じホスト名で外部からアクセス出来るようにしたいなら、ELBやRoute53を併用する
毎回異なるポート番号になるので、デプロイ時、1つのEC2インスタンスに
同じタスクの新旧バージョンを一時的に同時実行する事が出来る
host
ホストOSと同じネットワークに配置する
ポート番号が衝突するので、
省8
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
省1
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を複製して他環境で試す？
省2
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コンテナとか
このレベルで意思決定が出来て、そのとおり動くならマイクロサービスは素晴らしい
といえるけど、現状そうなってないんだろ？コンテナが物理サーバーに対して透過的
見えるレベルに到達してないつーか。
いつかそうなるんだろうけどね。
省1
593(1): 2020/02/02(日)11:04 ID:mAYLnTD8(1) AAS
>>592
それってデメリットか？
算数が出来れば計算出来るだろ
小規模環境なら台数固定で良いし
OSや、ログ、メトリクス用ポッドの分だけ余裕をもたせて空けておけば良い
それぐらい計算できるだろ？
もしかしてワーカーノードは全部同じグループとか思ってる？
データベースはこのラベルが付いてるノードだけに配置とか、出来るだろ
負荷がデータベースに集中しがちなら、データベースだけ大きなノードのグループで構成するとか
1つのグループに
省3
上下前次1-新書関写板覧索設栞歴
あと 409 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.023s