Automated Deployment

[ThomasThelen]

Now that we have a dedicated server, we should hook up an automated deployment system. The DataONE website uses Travis CI for this and we'll do the same.

There will be a bash script that handles sending the build website code over to our server. To do this, we'll first need to set up the build on Travis, and then store our Travis secrets in an encrypted file.

[robyngit]

Note that we should use a specific version of Hugo, like we do for the DataONE site, and not just the latest version, like we currently have in the demo GH action.

[ThomasThelen]

This is taking a little longer than expected because the server needs to be accessed through a VPN

[ThomasThelen]

Since juno is behind the VPN, we should be connecting to it through a machine designed to access the network-usually a bastion server. @mbjones, is there a preferred entrypoint server? We can discuss over slack/email if needed

The plan is to connect to the bastion server and run a deploy.sh file which will in turn connect to juno, clone this repo, build the static site, and copy it over to the appropriate folder in www/. This approach avoids spending time building the site on GitHub's hardware and also avoids copying the static site across machines.

There's a nice GitHub Action for sshing into a server and running a command which covers the relevant behavior for the action.

[mbjones]

@ThomasThelen The entrypoint should be one of our production servers, so that it will be available when needed. Another option than using a separate entrypoint would be for us to open the firewall on juno to the github servers, if we can identify what those are, and assuming they don't change frequently. Then, the web build via GHA could copy the files directly. The advantage of this is that our same CI process that we use for testing can be used for deployment. Let's talk to @nickatnceas about the firewall configuration.

[nickatnceas]

I went ahead and opened SSH to the world on juno. SSH on juno requires SSH keys and has rate limiting enables, so it's still relatively secure.

For the github action, a dedicated user account on juno with as few permissions as possible would be best.

[ThomasThelen]

Two actions have been added. One for production that publishes the website content off of the main branch to dev.oceanhealthindex.org and another for development that publishes content off of the dev branch to preview.oceanhealthindex.org