With our sysadmin position eliminated, and the Digital Collections hosted on Heroku, we stand to drastically simplify our Ansible codebase. This puts a new focus on those functions of Ansible that were not being used to maintain the Digital Collections. If we can get rid of them, we can get rid of Ansible.
But one thing we still need Ansible for is provisioning the ArchivesSpace server.
Software on the ArchivesSpace server
A ) The actual ArchivesSpace software.
B ) The code and files that export EADs and HTML finding aids.
Lives in a GitHub repository.
Badly needs repairs.
C ) An Apache server that serves the EADs and the HTML finding aids output by B )
Options
To eliminate the ArchivesSpace server (and with it much of our dependency on Ansible), we should consider one or more of the following steps:
A ) Move the ArchivesSpace software to a hosted provider.
As part of this, we may also wish to (or have to) update the version of ArchivesSpace.
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 become obsolete.
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 ) Replace Apache with an S3 bucket.
Notes
If an ArchivesSpace hosting provider, as part of their service, can take care of exporting and serving the EADs, we can avoid doing B ) and C ) altogether.
Because the ArchivesSpace server is the only one left that we use Ansible for, each of these steps has the side-effect of cutting out big chunks of our Ansible code. For instance, C) should allow us to get rid of all our Apache-related code in Ansible.
A ), B ) and C ) above could be treated as independent projects and be done in any order.