With our system administrator gone, and now that the Digital Collections are moving to Heroku, we will be drastically simplifying our Ansible codebase. This puts a renewed focus on those functions of Ansible that were not being used to maintain the Digital Collections: if we can get rid of them too, we can get rid of Ansible altogether.
One important function of Ansible that we can’t jettison immediately is the provisioning of the ArchivesSpace server.
For the purposes of this discussion, the ArchivesSpace server has three pieces of software on it:
The ArchivesSpace software proper.
The code and files that export ArchivesSpace EADs and HTML finding aids(in a GitHub repository).
At the moment, this code barely functions, and is very much in need of repair.
An Apache server that serves the EADs and HTML finding aids.
To entirely eliminate the ArchivesSpace server (and thus our dependency on the ArchivesSpace code in Ansible), we could take the following steps:
A ) Move the ArchivesSpace software proper to a hosted provider.
As part of this, we may wish to (or have to) also update the version of ArchivesSpace we use.
We may also decide, as part of this work, to turn on the public user interface.
If we turn on the PUI, the HTML finding aids export code can and should be eliminated.
B ) Run the export scripts from a hosted environment. It may be possible to run them from a serverless environment, such as AWS lambda.
C ) Serve the EADs, and, if we still need them, the HTML finding aids, from an S3 bucket. This allows us to remove Apache from our setup altogether.
Notes:
It may also be possible to get ArchivesSpace to serve the EADs directly. If so, it may be possible to avoid doing B ) and C ) altogether.
A ), B ) and C ) above could be treated as independent projects and be done in any order.