[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
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は、元の構成管理だけをするように戻りつつある
いろいろ手を広げすぎたんだよ、やつは。
515: 2020/01/27(月)20:04 ID:VdNPUB7+(1) AAS
>>504
その状態でansibleにやらせる構成管理ってなんなんや
dockerを動かす物理マシンの構成管理だけやるという意味なんか
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s