Serve master.cfg from a config nginx service

[blag]

I'm mainly submitting this PR to get a discussion going about a different way to handle serving master.cfg in the Buildbot tutorial with Docker.

The current tutorial requires users to create a completely separate repository for the master.cfg file, push it to GitHub, then tweak their docker-compose.yml files to point to the master.tar.gz file in that repository.

That's a lot of steps, and I think it could be much easier if you just have the user fire up a config service that servers the user's local master.cfg file to the Buildbot master. This PR enables this behavior. If the user updates master.cfg they just have to restart the services for the change to take effect, instead of switching to a different repo, making the change, committing the change, pushing the change, and restarting the services.

This PR does not update the tutorial. The config service is just an nginx server, and is configured exactly how the official nginx Docker repository suggests. There is no authentication for downloading the master.cfg file from the config service, but the fact that it runs in the same docker network as the rest of the current services and doesn't require the user to make their master.cfg configuration file public is a security and usability win in my book.

This eases the learning curve to getting a Buildbot server up and running, and gives the user hints as to how to host the configuration file "for real" if they need to scale up.

Even easier than this would be to share the config directory on the host with the master service and use a file:// URL to point to the config file, but that might complicate more things.

Your thoughts?

[mention-bot]

@blag, thanks for your PR! By analyzing the history of the files in this pull request, we identified @tardyp to be a potential reviewer.

[tardyp]

Hi @blag,

This tutorial is just meant to be a working example on how you can setup a buildbot without knowing much about deployement.

It may sounds easy for you, but I consider nginx to be more complicated than just hit the fork button on github.

This tutorial is not the way buildbot team recommends to deploy with docker, it is just a quick start for people to see how you could do it.
As buildbot is so flexible, everybody will come up with its own solution that bests suits its needs.

[blag]

It may sounds easy for you, but I consider nginx to be more complicated than just hit the fork button on github.

It's not just "hit the fork button" though, it's actually:

1. Hit the Fork button
2. Clone repo
3. Add/commit changes to master.cfg
4. Push changes
5. Edit docker-compose.yml to point to their master.tar.gz

With this change, the process becomes:

1. Edit master.cfg
2. Restart services with docker-compose restart

When I'm going through a tutorial, I'm customizing it to my needs, so I'm constantly adjusting the configuration files to get it to work. I think that's a pretty typical way to learn new things, so making it easier to iterate through configuration changes eases the learning process. And Buildbot already has a reputation for being difficult to learn - why compound that with all the GitHub repo stuff?

And if nginx sounds scary, consider that this is the entirety of the nginx configuration I added to the docker-compose.yml:

services:
  config:
    image: nginx
    volumes:
      - ./config:/usr/share/nginx/html:ro

That's all pretty straightforward, and the user doesn't need to muck with that service at all - they just edit their master.cfg ¹ and restart the docker-compose services. They don't need to understand that they're launching a config container running nginx, they don't need to understand any of the intricacies of nginx configuration, or of the docker-compose service, aside from a single sentence:

After every change you make to master.cfg, you'll need to restart the docker-compose services with docker-compose restart.

That's much easier to explain to a newbie than "push this entire repo to your own GitHub account and configure your docker-compose.yml file to use it", in my opinion. It seems a little weird that a CI tool intended to be run internally needs to access publicly accessible configuration files.

This tutorial is not the way buildbot team recommends to deploy with docker, it is just a quick start for people to see how you could do it.
As buildbot is so flexible, everybody will come up with its own solution that bests suits its needs.

Right, I totally get this, and do I understand that using a public GitHub repo is only one way to host the master config file. My change is also not intended to be the way to deploy with docker. I simply think that my way simplifies the tutorial for new users and lets them focus on configuring Buildbot itself instead of mucking around with forking/publishing their own repo. My changes align more with user expectations that their internal CI tool will only need access to internal configuration files.

¹ I even made a symlink from /config/master.cfg (where the nginx volume is shared from) to /master.cfg (relative to the repo root) so that file stayed "front and center" for users.