回答編集履歴
4
校正
answer
CHANGED
|
@@ -81,10 +81,14 @@
|
|
|
81
81
|
＃多くのプロジェクトでは、CentOSをローカル環境に構築して、AWSにアプリケーションをデプロイする方法を取っています。
|
|
82
82
|
|
|
83
83
|
AWSは、スポットでの検証などはかなり有益で、ランニングコストも他のパブリッククラウドサービスに比べて遥かに安いものになっていますが、ロングランで見た場合、オンプレ環境とさほど変わらなくなってしまいます。
|
|
84
|
+
従って、使っていない無駄な金額（HDDやデータ通信にお金がかかる）はどんどん縮小した方が良いため、開発環境などはAWS外のローカルでのVM環境などにしてコストを抑える必要があります。
|
|
85
|
+
|
|
86
|
+
AWSは普通に使っても安いのですが、安いだけにコストを更に抑えるテクニックがあります。
|
|
87
|
+
それを身に着けていくことがインフラ側が常に考えておかないといけないことになります。
|
|
84
88
|
＃極論で言ってしまえば、EC2インスタンスを使うことをやめて、サーバレスにしていくことが将来求められることになります。
|
|
85
89
|
|
|
90
|
+
|
|
91
|
+
バージョンに関しては、バージョン違いでの動作差異を無くしたいがために、どのプロジェクトにおいてもバージョンを統一していると思います。
|
|
86
|
-
|
|
92
|
+
メジャーバージョンとマイナーバージョンを揃えてさえおけば（できれば、マイクロバージョンも）パッケージが違えども、アプリケーションの動作に差異が発生することは特にありません。
|
|
87
93
|
|
|
88
|
-
バージョン違いでの動作差異を無くしたいがために、どのプロジェクトにおいてもバージョンを統一していると思いますが、メジャーバージョンとマイナーバージョンを揃えてさえおけば（できれば、マイクロバージョンも）パッケージが違えども、アプリケーションの動作に差異が発生することは特にありません。
|
|
89
|
-
|
|
90
94
|
もし本当に統一したいのであれば、ソースコンパイル（make installの方法）でやってしまえば良いかと思います。
|
3
誤記修正
answer
CHANGED
|
@@ -80,7 +80,7 @@
|
|
|
80
80
|
AWSに環境構築をしても良いのですが、インフラ担当は少しでもコストを下げなければなりません。
|
|
81
81
|
＃多くのプロジェクトでは、CentOSをローカル環境に構築して、AWSにアプリケーションをデプロイする方法を取っています。
|
|
82
82
|
|
|
83
|
-
AWSは、スポットでの検証などはかなり有益で、ランニングコストも他のパブリッククラウドサービスに比べて遥かに安いものになっていますが、ロングランで見た場合、オンプレ環境とさほど変わらな
|
|
83
|
+
AWSは、スポットでの検証などはかなり有益で、ランニングコストも他のパブリッククラウドサービスに比べて遥かに安いものになっていますが、ロングランで見た場合、オンプレ環境とさほど変わらなくなってしまいます。
|
|
84
84
|
＃極論で言ってしまえば、EC2インスタンスを使うことをやめて、サーバレスにしていくことが将来求められることになります。
|
|
85
85
|
|
|
86
86
|
従って、使っていない無駄な金額（HDDやデータ通信にお金がかかる）はどんどん縮小した方が良いため、開発環境などはAWS外のローカルでのVM環境などにしてコストを抑える必要があります。
|
2
追記
answer
CHANGED
|
@@ -62,4 +62,29 @@
|
|
|
62
62
|
力技でローカル環境に持ってくることも可能なのですが、
|
|
63
63
|
開発環境は社内などのローカル環境にCentOS、
|
|
64
64
|
ステージング環境と本番環境はAWS上にAmazon Linuxというような構成の
|
|
65
|
-
システム環境構築を推奨しておきます。
|
|
65
|
+
システム環境構築を推奨しておきます。
|
|
66
|
+
|
|
67
|
+
# 追記
|
|
68
|
+
|
|
69
|
+
すみません。上記に言葉が抜けていました。
|
|
70
|
+
CentOSを構築するのはローカル環境になります。
|
|
71
|
+
AWSのCentOSではありませんので注意してください。
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
開発側は、全ての環境は統一しておくのは当然のことだと思っているため、
|
|
75
|
+
そのように言われるのは明々白々のことだと思います。
|
|
76
|
+
従って、本来は全てAWSに構築するのが良い環境となります。
|
|
77
|
+
|
|
78
|
+
しかしながらインフラ側に求められることというのは、開発者の言い分とインフラ担当が判断している運用コスト観点（ここだとAWSの利用金額）をあわせて、総合的に判断しプロジェクト環境を構築するのが使命となります。
|
|
79
|
+
|
|
80
|
+
AWSに環境構築をしても良いのですが、インフラ担当は少しでもコストを下げなければなりません。
|
|
81
|
+
＃多くのプロジェクトでは、CentOSをローカル環境に構築して、AWSにアプリケーションをデプロイする方法を取っています。
|
|
82
|
+
|
|
83
|
+
AWSは、スポットでの検証などはかなり有益で、ランニングコストも他のパブリッククラウドサービスに比べて遥かに安いものになっていますが、ロングランで見た場合、オンプレ環境とさほど変わらない用になってしまいます。
|
|
84
|
+
＃極論で言ってしまえば、EC2インスタンスを使うことをやめて、サーバレスにしていくことが将来求められることになります。
|
|
85
|
+
|
|
86
|
+
従って、使っていない無駄な金額（HDDやデータ通信にお金がかかる）はどんどん縮小した方が良いため、開発環境などはAWS外のローカルでのVM環境などにしてコストを抑える必要があります。
|
|
87
|
+
|
|
88
|
+
バージョン違いでの動作差異を無くしたいがために、どのプロジェクトにおいてもバージョンを統一していると思いますが、メジャーバージョンとマイナーバージョンを揃えてさえおけば（できれば、マイクロバージョンも）パッケージが違えども、アプリケーションの動作に差異が発生することは特にありません。
|
|
89
|
+
|
|
90
|
+
もし本当に統一したいのであれば、ソースコンパイル（make installの方法）でやってしまえば良いかと思います。
|
1
追記
answer
CHANGED
|
@@ -60,5 +60,6 @@
|
|
|
60
60
|
|
|
61
61
|
あと、Amazon LinuxのDockerイメージが用意されているため、
|
|
62
62
|
力技でローカル環境に持ってくることも可能なのですが、
|
|
63
|
+
開発環境は社内などのローカル環境にCentOS、
|
|
63
|
-
|
|
64
|
+
ステージング環境と本番環境はAWS上にAmazon Linuxというような構成の
|
|
64
65
|
システム環境構築を推奨しておきます。
|