You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Going to production: infrastructure & deployment
102
100
103
-
Although this project provides some guidelines on how to deploy the app, it is not mandatory to follow them. You can deploy the app on any platform you want, as long as it supports Docker and Docker Compose, or even deploy the app on a bare-metal machine.
101
+
Although this project provides some guidelines on how to deploy the app, it is not mandatory to follow them. You can deploy the app on any platform you want, as long as it supports Docker and Docker Compose, or even deploy the app on a bare-metal machine.**By the end of the day, you should use the provided GitHub Actions workflows as a reference to build your own deployment pipeline and meet your requirements**.
104
102
105
-
This codebase has two deploy methods available via GitHub actions:
103
+
Nonetheless, this codebase has two deploy methods available via GitHub actions:
106
104
107
105
### Virtualized Deploy Workflow
108
106
@@ -112,28 +110,11 @@ The `vm-deploy` branch will trigger this wokflow. You can use it to deploy the a
112
110
113
111
The `bare-metal-deploy` branches will trigger this workflow. You can use it to deploy the app straight on the host machine, without any virtualization. This is not recommended, but ou never know when you will need to deploy an app on a bare-metal machine 🤷♀️
114
112
115
-
## Configuration
116
-
117
113
You should configure these variables on a `.env` file on the root folder for the global configuration and a `.env` file for the frontend configuration under `frontend/.env` when developing. As for deploying the app, **you will need to set the same set of dev variables + some variables exclusively used in production environments as [_secrets_](https://docs.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets)**.
| SECRET_KEY | - | Django's SECRET_KEY used to encrypt passwords. It can be generated by running: `python -c 'from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())'`|
124
-
| CDN_NAME | - | Cloudinary's CDN name |
125
-
| CDN_API_KEY | - | Cloudinary's CDN API key |
126
-
| CDN_API_SECRET | - | Cloudinary's CDN API secret |
127
-
| DB_HOST | - | Database host name |
128
-
| DB_NAME | - | Database name |
129
-
| DB_USER | - | Database user |
130
-
| DB_PASSWORD | - | Database password |
131
-
| DB_PORT | - | Databse port |
132
-
| SMTP_HOST_USER || Your SMTP email |
133
-
| SMTP_HOST_PASSWORD | - | Your SMTP email password |
134
-
| TEST | 0 | Used to test the app on CI/CD |
135
-
136
-
#### Exclusively used in production
115
+
### Configuration
116
+
117
+
You must be familiar with the expected environment variables to run the project. Here is a list of the environment variables you must set alongside the ones you already know ([`.env.example`](./.env.example) from root, [`.env.example`](./frontend/.env.example) from frontend) production environments and must be set as secrets on your GitHub repository and made available to GitHub Actions.
@@ -143,11 +124,51 @@ You should configure these variables on a `.env` file on the root folder for the
143
124
| DEPLOY_TOKEN | A Github token with permission to pull this project's image from your Github registry |
144
125
| HOST | The domain under which your site will be hosted (i.g.:example.com) |
145
126
| SSH_PRIVATE_KEY | The SSH key used to access the host machine |
146
-
| USERNAME | The SSH username used to access the host machine |
127
+
| USERNAME | The SSH username used to access the host machine ||
128
+
129
+
### Architecture overview
147
130
148
-
### Frontend
131
+
Building up on the [application architecture diagram](#application-architecture), here is a more detailed overview of how the application is structured on a production environment:
| NODE_ENV |`development`| Let's Webpack know when to build files to correct public path, optimize code and when to prepend localhost for API endpoints or not. Values must be either `development` or `production`. This is hardcoded on the [Dockerfile](./Dockerfile)|
153
-
| AUTH_TOKEN | - | An auth key generated on Django's admin that must be associated to a user with specific permissions (i.g.: read specific infos from Django's ORM) |
133
+
```mermaid
134
+
flowchart TD
135
+
subgraph subgraph_byfiey99u["Gunicorn"]
136
+
ny("React")
137
+
n9("Env. variables")
138
+
ns("Frontend")
139
+
nt("Django")
140
+
ni("Django Rest Framework")
141
+
nl("Backend")
142
+
n5("Views")
143
+
nb("Templates")
144
+
na("Models")
145
+
n0("API Client")
146
+
n4("Root Container")
147
+
nn("API Key")
148
+
nd("Publications")
149
+
ng("REST API")
150
+
react_assets("Static assets\n(React included)")
151
+
end
152
+
subgraph subgraph_3hmsyzvqm["Docker Image/Host"]
153
+
subgraph_byfiey99u
154
+
nginx("NGINX")
155
+
pg("Postgres")
156
+
end
157
+
ns --> ny & n9
158
+
nl --> nt & ni
159
+
nt --> n5 & nb & na & subgraph_3hmsyzvqm
160
+
nt -- Stores media\nfiles on --> nk("CDN\n(Cloudinary)")
161
+
n5 --> nb
162
+
ny --> n0 & n4
163
+
na --> nn & nd
164
+
n4 -- Mounts on same file from\nDjango templates --> nb
165
+
n9 -.-> nn & n0
166
+
ni -- Provides a REST\nendpoint to manipulate\ndata from models --> ng
167
+
ng --> nd
168
+
n0 -- Consumes API Key\nto authenticate\nwith backend --> ng
0 commit comments