Add developer docs

[henrykironde]

On serenity first install
sudo apt-get -y install libcurl4-gnutls-dev libxml2-dev libssl-dev
sudo apt-get install libssl-dev
sudo apt-get install openssl
sudo su -c "R -e "install.packages(c('pillar', 'utf8', 'pillar', 'tidyselect', 'rmarkdown', 'dplyr', 'ltsa', 'tscount', 'yaml'),)""

Then install these packages, some may still fail since they the dependencies need to be manually installed
sudo su -c "R -e "install.packages('devtools')""
sudo su -c "R -e "install.packages('shiny')""
sudo su -c "R -e "install.packages('dplyr')""
sudo su -c "R -e "install.packages('ggplot2')""
sudo su -c "R -e "install.packages('portalr')""
sudo su -c "R -e "install.packages('stats')""
sudo su -c "R -e "install.packages('lubridate')""
sudo su -c "R -e "install.packages('forecast')""
sudo su -c "R -e "devtools::install_github('weecology/portalcasting')""

shiny::runApp()

[ethanwhite]

We installed the Shinny app the configurations are in
/etc/shiny-server/shiny-server.conf
Shiny server logs:
/var/log/shiny-server

Ngnix config file:
/etc/nginx/conf.d/application.conf

• open the firewall for nginx sudo ufw allow "Nginx Full"
• create file in /etc/nginx/sites-available named as the domain that includes the following. The 3838 value in the proxy_pass line should be the port being used, which is generally 3838 for shiny apps:

server {
  root /var/www/html;
  server_name example.example.com;
  location / {
    proxy_pass http://127.0.0.1:3838/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

• symlink this file into /etc/nginx/sites-enabled using

sudo ln -s /etc/nginx/sites-available/example.example.com /etc/nginx/sites-enabled

• install certbot - see https://certbot.eff.org/instructions
• run sudo certbot --nginx

restart server
sudo systemctl restart shiny-server

[henrykironde]

On the local server running the shiny app, we update the local repository using a cronjob every 20 minutes by running update_repo.sh.
The last log cron.log is stored in the root directory of portal-forecast-web on the server.

[juniperlsimonis]

with the update to portalcasting v 0.53.0

having either installed the portalcasting package (e.g., via `remotes::install_github("weecology/portalcasting", remotes is preferable to devtools, as it is targeted for the downloading of packages and is much lighter weight) or operating within the docker container for the package, one should be able to run

library(portalcasting)
update_dir(settings = production_settings( ))
run_app()

every single time, including the first.

which is to say that "update_dir" will create the directory if it's not there. it does, however, default to normal settings, which do not include the full archive download, which the app needs. i will eventually make an update_production and update_sandbox spin-off of update_dir, but they don't exist yet, so you have to use the generic function with the specific settings list.

at this point, given that the app code is all encompassed within the (containerized) package, and all the R installations in the original post above can be removed

the same goes for the external -to-R libraries... at least the ones that were only required for building the site, as they are now included in the image... this does also assume that we're using the image to build and serve the app, which i'm not sure on.

the docker image is based on the rocker/tidyverse:latest image, which includes all of the above-listed apt libraries (and many many more)

an important update with the new portalcasting version as well is that the app files are all now within a subdirectory called app ("all" except for the google analytics file, I wasn't sure what exactly to do with that, if its being used right now, etc, so I didn't move it to portalcasting. i can do that if needed, tho.)

i'm also wondering if we can actually move the build of the app to github actions, off of the local server. that's pretty straightforward to run these days, and there isn't much in the way of overhead to where i think it needs to be on a local server . that would make it much easier for me to work with and update the content as needed for any upstream changes. but if it needs to stay on it, that's fine to.

[ethanwhite]

i'm also wondering if we can actually move the build of the app to github actions, off of the local server.

Can you clarify what you mean by build in this case. It's been a while, but I think we're basically pulling down the most recent versions of things and restarting shiny (but the cronjob is in @henrykironde's account so I can't confirm).

[juniperlsimonis]

yeah, build in the spinning up of the live application. more or less what is being talked about in this post, in terms of the CRON runner that's executing that update (collecting updated content, generating the website, serving it to nginx) every day.

[ethanwhite]

generating the website, serving it to nginx

This is the part where I don't understand how we move it to GitHub Actions since it's a shiny app not a static site.

[juniperlsimonis]

ah ok, i think i get where your very understandable confusion comes in.

it's manageable through deploying an executable container that actually spins up the app when loaded (via the CMD instruction in the dockerfile).

i'm definitely including this as the end step in the toy example i've pulled out to fully develop the workflow (see https://github.com/dapperstats/ShinyDocker) since there is obviously too much going on in portalcasting to really develop a new workflow like that (see weecology/portalcasting#330)

the 'toy' is almost certainly going to be an important testing ground for some fundamentals we implement in the portal framework. so maybe more 'nascent template' than 'toy'?

[juniperlsimonis]

with https://github.com/weecology/portalcasting/releases/tag/v0.54.0 we now have update_sandbox and update_production directly, so the three lines would just need to be

library(portalcasting)
update_production()
run_app()

[juniperlsimonis]

at this point now, i think the developer docs regarding the website code itself can be located in portalcasting (since one can spin up a local version of the website or even serve a built version to a remote location without even knowing about this repo)

but the developer docs regarding the deployment are still needed.
what is happening step-by-step to get the built app onto the server?