回答編集履歴
2
Add expression
answer
CHANGED
@@ -1,3 +1,5 @@
|
|
1
|
+
## 元の回答
|
2
|
+
|
1
3
|
扱っているサービスがどこまでの安全性を求めるかと、
|
2
4
|
どれだけデプロイにコストをかけられるかによって方法が変わってきます
|
3
5
|
|
@@ -41,4 +43,35 @@
|
|
41
43
|
このようなデプロイのワークフローついてもインフラ側で考慮してくれて
|
42
44
|
こちらで考える必要がない場合があります
|
43
45
|
|
44
|
-
参考: [デプロイ / リリース 手法 まとめ - galife](https://garafu.blogspot.com/2018/11/release-strategy.html)
|
46
|
+
参考: [デプロイ / リリース 手法 まとめ - galife](https://garafu.blogspot.com/2018/11/release-strategy.html)
|
47
|
+
|
48
|
+
## 追記
|
49
|
+
|
50
|
+
> 「そのため、別ディレクトリーに clone した後、
|
51
|
+
> シンボリックリンクで参照先を切り替える、など」
|
52
|
+
> こちら「シンボリックリンクで参照先を切り替える」とはどういう事なのでしょうか...?
|
53
|
+
|
54
|
+
もう少し詳細に説明すると、次のような手順です
|
55
|
+
|
56
|
+
事前準備:
|
57
|
+
1
|
58
|
+
プロジェクトを、あるパスに clone します
|
59
|
+
|
60
|
+
2
|
61
|
+
Web サーバーのドキュメントルートに指定するディレクトリーを
|
62
|
+
シンボリックリンクで作成し、宛先を手順 1 で clone したパスに向けておきます
|
63
|
+
|
64
|
+
デプロイ時
|
65
|
+
1
|
66
|
+
更に別のパスにプロジェクトを clone します
|
67
|
+
|
68
|
+
2
|
69
|
+
手順 1 で clone したパスにシンボリックリンクを切り替えます
|
70
|
+
|
71
|
+
3
|
72
|
+
切り戻しの必要がなければ、以前に clone したパスに存在するプロジェクトを削除します
|
73
|
+
|
74
|
+
さらなる詳細は Ansistrano のワークフローの説明が参考になります:
|
75
|
+
|
76
|
+
- [Main workflow ansistrano/deploy: Ansible role to deploy scripting applications like PHP, Python, Ruby, etc. in a capistrano style](https://github.com/ansistrano/deploy#main-workflow)
|
77
|
+
- [デプロイフロー | Ansistranoでデプロイしてみる - Qiita](https://qiita.com/kawakawaryuryu/items/4843f518e84a6aae26b9#%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4%E3%83%95%E3%83%AD%E3%83%BC)
|
1
Fix expression
answer
CHANGED
@@ -12,9 +12,11 @@
|
|
12
12
|
- [A remote server automation and deployment tool written in Ruby.](https://capistranorb.com/)
|
13
13
|
- [Ansistrano: Just deploy it!](https://ansistrano.com/)
|
14
14
|
|
15
|
-
または、
|
15
|
+
または、`ローリングデプロイ`してくれるサービスを本番環境として使うか、
|
16
|
-
自分でロー
|
16
|
+
自分で`ローリングデプロイ`を行う、または自動化します
|
17
17
|
|
18
|
+
参考: [ローリングデプロイの仕組み | デプロイポリシーと設定 - AWS Elastic Beanstalk](https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html#environments-cfg-rollingdeployments-method)
|
19
|
+
|
18
20
|
## 稼働中のサービスを pull した場合のリスク
|
19
21
|
|
20
22
|
静的なコンテンツを返すサイトだったり、
|
@@ -29,10 +31,14 @@
|
|
29
31
|
`Capistrano` や `Ansistrano` というツールを使うと
|
30
32
|
上記の処理を自動的に処理してくれます
|
31
33
|
|
34
|
+
## ローリングデプロイ
|
35
|
+
|
32
|
-
|
36
|
+
例えば、本番環境を複数台用意して
|
33
37
|
本番環境を`ロードバランサー`から 1 台ずつ切り離してデプロイすれば
|
34
38
|
上記の心配はなくなります
|
35
39
|
|
36
40
|
使っているクラウドによっては、
|
37
|
-
このようなロー
|
41
|
+
このようなデプロイのワークフローついてもインフラ側で考慮してくれて
|
38
|
-
こちらで考える必要がない場合があります
|
42
|
+
こちらで考える必要がない場合があります
|
43
|
+
|
44
|
+
参考: [デプロイ / リリース 手法 まとめ - galife](https://garafu.blogspot.com/2018/11/release-strategy.html)
|