test out trellis-ext-aws

[jmartin-sul]

there has been an initial release of "a cloud-native Trellis, based on the 0.8 Trellis API" (using "S3 for binary and memento storage, and... SNS for notifications").

per aaron coburn, "this is the 0.1 release of the AWS-based project, and while there are lots of automated tests for the code, this is considerably newer code than the regular -ext-db code. Admittedly, the code is really simple, but I'd recommend that you do your own tests before putting it into production."

after discussing with jeremy, it seems worth some investigation as to whether this trellis implementation would work for us. in particular, being able to use S3 for binary and memento storage would simplify our infrastructure setup, and allow us to stop mounting EFS volumes for trellis, which would give us the option to spin trellis up as a fargate task.

since the best baseline for trellis functionality we have is described in this wiki page by christina: https://github.com/LD4P/sinopia_server/wiki/Draft-Notes-for-Sinopia-Server-API-Spec

we were thinking that the best way we have to test trellis-ext-aws is to run the curl commands listed in that wiki entry against a trellis-ext-aws instance, to see whether we get the same behavior as we did with trellis-ext-db (or, if there is a difference, whether the trellis-ext-aws behavior is acceptable).

if that testing on a local trellis-ext-aws instance works out, we can ticket spinning up an instance in our cloud infrastructure.

trellis-ext-aws links: https://github.com/trellis-ldp/trellis-ext-aws/releases/tag/trellis-ext-aws-0.1.0 https://hub.docker.com/r/trellisldp/trellis-ext-aws-rds

[jmartin-sul]

as @jermnelson just realized, we will likely need a new RDS instance and at least one new S3 bucket to do this testing.

[ndushay]

@jmartin-sul is this a dup of #88 ?

[jmartin-sul]

@ndushay, nope, this is a distinct issue.

our ld4p/trellis-ext-db docker image is based on the trellisldp/trellis-ext-db docker image. trellis-ext-aws is a different and more AWS native version of trellis. my recollection is that it was newer and less battle tested, and the docker images came out after we were already using trellis-ext-db, so some testing would be in order, since it's not a drop-in replacement. it appears there are actually two flavors of trellis-ext-aws docker image at pressent:

• https://hub.docker.com/r/trellisldp/trellis-ext-aws-rds -- A Docker container for an AWS-based Trellis LDP server, using a managed RDS instance
• https://hub.docker.com/r/trellisldp/trellis-ext-aws-neptune -- A Docker container for the AWS-Neptune-based Trellis LDP server

it might be nice to experiment with the more cloud native version, to see if it'd ease our deployment and terraform pain (esp if it meant we could do without a file system for memento stuff, freeing us to deploy trellis in fargate). but since we have a trellis-ext-db setup that works, and since we're already kinda timecrunched, we punted on testing trellis-ext-aws for now.

[acoburn]

Hi All, the big difference with the AWS-based Trellis is that it uses S3 for storing binaries and mementos (rather than a filesystem). It also ties in directly to SNS for notifications. Using trellis-ext-aws-rds would be most similar to what you're already using.

[jmartin-sul]

thanks for the clarification, @acoburn!

so yeah, that'd let us simplify our infrastructure setup, but would definitely require rewriting some terraform code and doing some testing. desirable, but not critical path at the moment, since we have a setup that works and isn't causing us to take on further technical debt.