search

libretime / libretime

LibreTime: Radio Broadcast & Automation Platform
http://libretime.org
GNU Affero General Public License v3.0
806 stars 225 forks source link

Feature Request: Use a different "base_url" for API services than the web front-end #515

Closed ned-kelly closed 2 years ago

ned-kelly commented 6 years ago

So, I'm running Libretime in a multi-container docker setup that I've built ready for production use (see here for the repo: https://github.com/ned-kelly/docker-multicontainer-libretime), and ideally I'd like to request that there be two base_url variables added to the airtime.conf file:

Hope this makes sense and isn't too much to ask.

ned-kelly commented 6 years ago

Update: I'm using the apache substitute to currently just strip out any references to localhost and make the paths relative for now - Can I suggest that future iframe implementation in the front-end uses relative paths to fix this issue?

Quick apache fix for anyone else with the issue:

  1. add to the end of your /etc/apache2/sites-enabled/airtime.conf file:
  # Quick fix for iframes that reference hard coded 'localhost' in paths.
  # BEGIN:LOCALHOSTFIX--
  <Location "/">
      SetOutputFilter SUBSTITUTE;DEFLATE
      AddOutputFilterByType SUBSTITUTE text/html

      Substitute "s|http://localhost//|/|ni"
      Substitute "s|https://localhost//|/|ni"

      Substitute "s|http://localhost/|/|ni"
      Substitute "s|https://localhost/|/|ni"
  </Location>
  1. Then run: 
    a2enmod substitute

Check my docker build of libretime for a scriptable fix if you're looking to add this into a docker container like I have.

Robbt commented 6 years ago

Cool project, I've been meaning to investigate docker more and how it could be applicable towards the project. You seem to have done quite a bit in your repo.

Just to clarify here when you are talking about front facing you are mostly talking about the iframe widgets used for the embeddable player and schedule etc right ?

Also I noticed you mentioned in your PR that LibreTime was released by SourceFabric. That's not the case, this is an independent project just built upon their open-source work in Airtime. They know maintain Airtime.pro as a SaaS project with source only available to their internal team and haven't made any contributions since the fork etc.

ned-kelly commented 6 years ago

Cool project, I've been meaning to investigate docker more and how it could be applicable towards the project. You seem to have done quite a bit in your repo.

Thanks, the goal is to have a PROPER multi-container docker setup (with various services such as the DB, etc split out using their respective official docker repo's and not all in one ubuntu container like other previous builds of the older Airtime) - This will allow for the deployment Libretime for "production" (so use in a live station setup), where database files, uploaded media, config etc will properly persist between standing up and down the environment etc (so upgrading via docker won't blow away your setup etc)...

Just to clarify here when you are talking about front facing you are mostly talking about the iframe widgets used for the embeddable player and schedule etc right ?

This fix is for the front-end ... The proper immediate fix is to just ensure that every iFrame is referenced in the widgets, schedule etc (on the main server homepage) are relative (Since they are always going to come from the same domain anyway as the parent webpage).

Also I noticed you mentioned in your PR that LibreTime was released by SourceFabric. That's not the case, this is an independent project just built upon their open-source work in Airtime. They know maintain Airtime.pro as a SaaS project with source only available to their internal team and haven't made any contributions since the fork etc.

Oops, yeah I'm aware - Have spent quite a lot of time over the past day or two reading all the docs on http://libretime.org/ :) - I just forgot change that from from my other container I built for Airtime (before discovering Libretime only a few hours later...) - I'll fix that now :).

On the general subject of docker - Docker is a powerful way to get people up and running reliably and quickly - since you're ensuring that the environment they are running is going to be exactly the same, every time - so I'd encourage it, happy to merge what I've started into the Libretime project if you guys do go down the docker route.

frecuencialibre commented 6 years ago

Wanted to share here my yes vote for moving forward with merging a Docker instalation method into LibreTime, and hope that this decision could even lead to more people becoming involved in the project as they see their efforts installing the project rewarded quickly with a working product.

  1. Better install process: As an end-user without previous knowledge, I've found getting up and running with Docker surprisingly simple. Much more-so than trying to troubleshoot problems with icecast streams or songs that cut out. I've been really impressed by how much of the currently necessary extra config steps (eg. problems with FQDN, Silan update) can be resolved in order to deliver a product that works "out of the box."

  2. Better backup and revert options: Heaven forbid that you did what the documentation instructs and ran sudo ./install right in your base operating system! :) when things go wrong following a config change you attempted you'll then have no choice but to try to troubleshoot, and reverting can get hairy. We learned the hard way that running a station off of alpha stage open source software without well planned system architecture is simply too risky. We also tried working with virtual machines, which was safer but resource intensive and still very time consuming. Docker containers let us store config in code, and can be quickly spun up, copied (you can even commit changes like git), etc.

OK. enough typing. Docker's rise appears to be for some good reasons that Lucas @hairmare and others have mentioned for a long time. Thanks all!

hairmare commented 6 years ago

This issue bit my docker installation from https://github.com/hairmare/centos-docker-libretime and my original multi-vm on-prem installation as well. I ended up managing a distinct airtime.conf for each vm and I haven't fixed my docker install properly since it's a moonshot anyway.

Splitting the two URL use cases seems a sensible way around this.

I'll try not to go OT for to long about docker. The container image case seems to be more relevant as time passes. We would probably need to make available different images to make everyone happy though:

Robbt commented 6 years ago

Yeah, it does seem like it would be a good idea to create a new official repo for the docker stuff. I'm just following @ned-kelly 's work on his repo and there seems to be a lot of potential here.

ned-kelly commented 6 years ago

Yeah, it does seem like it would be a good idea to create a new official repo for the docker stuff. I'm just following @ned-kelly 's work on his repo and there seems to be a lot of potential here.

I've got a few things I'm adding into my docker build later this week that have been requested from a customer that I've deployed this for, stuff like auto-dj on stream failure/libretime-core restart etc which I believe should be part of any "production" deployment - Happy to look at using my project as the official docker build if you guys want, but Im thinking we should really have two options in terms of docker:

@Robbt send me a PM on slack when you're up if you want and I can do a screenshare of my current setup / where it's going if you want?

hairmare commented 6 years ago

Deadair detection via Jack plugin

I'm intrigued mate :wink:

frecuencialibre commented 5 years ago

getting back to the original issue, i just put some time into a PR that makes some changes to @ned-kelly 's scriptable fix above. domain issues are pretty easy to fix with further hacks to the container's /etc/hosts/ file, but whenever i tried to add a use a non-standard port here i started to get errors in /var/log/airtime/pypo/pypo.log.

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had activity in the last 5 months. It will be closed if no activity occurs in the next month. Please chat to us on discourse or ask for help on our chat if you have any questions or need further support with getting this issue resolved. You may also label an issue as pinned if you would like to make sure that it does not get closed by this bot.

lord-carlos commented 4 years ago

Hi guys. I have libretime behind a reverse proxy in a docker from @ned-kelly Thanks to EXTERNAL_HOSTNAME variable the widgets have the right hostname. The problem is hat for example the widget has http://<hostname>:<dockerport> instead of https://<hostname> Is this the same "bug"? Should I open a new one? Maybe I can just search and replace the string in nginx for now?

Edit: I think I got it working. For me hostname and icecast_hostname is different. Adjust as needed.

        location /embed {
                proxy_set_header Accept-Encoding "";
                proxy_pass http://127.0.0.1:8882;
                include nginxconfig.io/proxy.conf;
                proxy_redirect off;

                sub_filter http://$host:8882/ https://$host/;
                sub_filter "https://icecast_hostname:35112/live" "https://$host:21212/live";
                sub_filter "http://icecast_hostname:35112/live" "https://$host:21212/live";
                sub_filter 'http:\/\/icecast_hostname:35112' 'https:\/\/$host:21212';
                sub_filter_once off;
        }
jooola commented 2 years ago

The few callback url that were previously passed from the php app to the analyzer or the worker have been replaced with IDs. The request url is now build on the service responsible to make the call.

With this done, one can override the public_url configuration field using environment variables to override the value set in the config file. This can be done for each container that requires to talk to the php app without going through the public url.

See https://github.com/libretime/libretime/blob/f08a146554c411f1452f66137f59d144d13711f7/docker-compose.yml for details.

Closing as resolved.