|
1 | | -The standard SuperStack replaces the stack in place. |
| 1 | +The standard SuperStack has a single app, and it's upgraded in place. |
2 | 2 |
|
3 | | -- There's some downtime while upgrading. |
| 3 | +- There's potentially some downtime while upgrading. |
| 4 | +- Once an app is upgraded, you can't rollback. |
4 | 5 | - You can't test one app while another is live (blue/green) |
5 | | -- Once an app is upgrade, you can't rollback. |
6 | 6 |
|
7 | | -Once your app is ready for production, consider adding a traffic-switcher in |
| 7 | +When your app is ready for production, consider adding a traffic-switcher in |
8 | 8 | front of your app. |
9 | 9 |
|
10 | 10 | Here's how it works: |
11 | 11 |
|
12 | 12 | - We stop exposing ports in the `app` project. |
13 | | -- A new `proxy` service is added, with ports open. |
| 13 | +- A new `proxy` service is added with ports open. |
14 | 14 | - It's purpose is to direct traffic to the right application. (it also takes |
15 | | - over TLS termination from the app layer). |
16 | | -- Rather than upgrading the one app, apps are deployed separate to the live |
17 | | - one. A fresh app every time. |
| 15 | + over TLS termination) |
| 16 | +- Rather than upgrading the single app, new apps containers are brought up, |
| 17 | + separate to the live one, and they connect to the proxy's network. |
| 18 | +- Test the new app before it goes live. |
| 19 | +- Finally traffic is flipped to the new app. |
18 | 20 |
|
19 | 21 | This way, environments are _ephemeral, immutable and idempotent_. |
20 | 22 |
|
|
0 commit comments