hello all!
Thanks in advance everybody for your patience with my questions and long-windedyness. Eventually it would be great to include production deployment recipes in official documentation as this will continue to be a big barrier to entry as long as the project remains in an alpha stage.
I’m going to focus here on the “pull” part of the workflow, as that’s all that will happen on our community radio station’s little server. @rfb I’m thinking contributions pushed to Libretime usually happen from dev instances spun up via Vagrant (as per the Getting Started instructions).
Goals:
- Ensure availability and reliability for a live radio station
- Quickly test updates within an environment that’s identical to production, and then push them to production.
- Facilitate easy backups of entire working libretime instance, including ability to restore to a different machine
Context:
Our 16 year-old community radio station has a lot of heart but very little budget and tech savvy amongst collective members. Internet connections here in the poorest state in México are slow and intermittent, but we’d greatly benefit from being able to control programming remotely when possible, ideally via an easy web interface rather than the tortuously slow teamviewer.
Current thinking and questions:
After a few time-consuming failed experiments installing alpha libretime releases directly in the base system, we’re now thinking that running Libretime in a virtual machine (VM) warrants the added complexity it adds to the system setup because it give us a better ability to recover quickly from potential future problems, a better update workflow, and better security. However, I have no idea if this approach could be simplified/improved, and so need to reach out to the community. 
Behold my gorgeous diagram of our current tentative proposal.
Note that all user content (audio files, database) is stored outside of the VM that contains libretime in order to be able to completely replace the entire VM with a backup or an update, add in the database and media settings, and be back up and running.
I think the biggest problem with this setup is that our specific VM configuration is not controlled within git. It seems like tools like Puppet, Chef, etc., might be perfect here, but I simply have no idea. For example, we need to add a line to the VM’s hosts file to direct our externally-accessible domain (referred to as the “Webserver Host” in the Libretime install step) to 127.0.0.1, or icecast streams will fail. It sure would be great to be able to just run a “vagrant up” type command and get a complete, configured VM from our fork of the Libretime repository. We haven’t really crossed this bridge yet, but for now it seems like we’ll need to also maintain a cloneable VM without Libretime, complete with all our specific config, ready to receive the LibreTime codebase and run the install script.
whew that got long. thanks folks!
ryan from Frecuencia Libre