@ -120,7 +120,7 @@ When writing a piece of documentation together with my friend Chae, she reacted
Deployment is a military term, that refers to moving troops and army around on the battlefield. The spatiality of this gesture, going from home to the warzone, or from a target to another, suggests a form of detachment from its consequences, rendering them far away. Do we feel less responsible for what's happening so far? Perhaps the contrary. When something goes wrong on a distant server, what we feel is the helplessness of something being out of reach.
It's not surprising that technologies developed within army still talk the army language. But being so un-surprising, words and the worlds they carry along sneak into our worldviews, becoming normal, natural, invisible. Becoming just the way the world is, justifying and reinforcing the separation between user and developer, server and served, etc.
It's not surprising that technologies developed within army still talk a soldiers' language. But being so un-surprising, words and the worlds they carry along sneak into our worldviews, becoming normal, natural, invisible. Becoming just the way the world is, justifying and reinforcing the separation between user and developer, server and served, etc.
Looking at etymology, _deploy_ feels close to _display_. They share roots and gestures of making something visible and public, not to seclude it far away, but to make it accessible.
@ -128,7 +128,7 @@ Let's see.
## NGINX Configuration
To deploy the padliography on a server, and make it accessible from a web browser, it's necessary to configure a way to make the communication between the application and the world possible.
To deploy the padliography on a server and make it accessible from a web browser, it's necessary to configure a way to make the communication between the application and the world possible.
In a server a lot of things are happening at the same time. When unfolding an application there it's important to reserve it a dedicated channel to talk with the outside.
@ -138,7 +138,68 @@ In order to make it work, every app that need to exchange data with the outside
A reverse proxy listen to the external requests that come from the web, such as someone visiting the url `https://hub.xpub.nl/soupboat/padliography`, checks in its list of location and ports and finally finds out that indeed, requests to `/soupboat/padliography` are actually directed towards the port number 3000.
In this particular case we are using [NGNIX](https://nginx.org/en/). If you happen to use it as well, adding a location for the padliography is straight forward.
In this configuration there are two locations: one for the static files such as images, css and js documents, and one with the `proxy_pass` that points at the internal port where the application is listening for updates.
Note that the alias path `/var/www/pad-bis/static/` could differ depending on where you cloned the repository. In this case, the repo was cloned in the `/var/www/pad-bis` directory. So adjust your config accordingly.
Another important aspect to take into account is the port where to redirect the user's request. In this case is `3147`, but any available port is good. This is the same port you define in the `.env` file!
As previously said in a server a lot of things are going on at the same time, so in order no to make a mess with free and occupied ports sometimes is nice to adopt a strategy that helps developers choose a good one. In the situation of the Soupboat, we keep an incremental comment in the config file that suggest what port to use next.
Something as simple as
```
# ATTENTION: use port 3159 for the next project!!!! ;))
```
Everyone updating the configurations with a new project also updates the message for the next one. It's a simple way but it works! It's also a nice way of leaving messages for future developers coming to the NGINX config file.
Once you added your entry, you want to check that everything looks good and there are no typo or other errors in the configurations.
To do so run the test command
```
sudo nginx -t
```
And if the output says that things are ok you can relax and reload the server to make the changes effective.
```
sudo systemctl reload nginx
```
If the test command prints some errors check them out: usually they are clear and comprehensible. Probably you forgot a semi-column or used a dupplicated location. Fix it and then try to test again! It's dangerous to reload the server without checking it first, because this can break things and make the server inaccessible if you are accessing from a web interface such as jupyter lab.