<p>Recently while working on Juju, we’ve started to use a tool called <ahref="https://github.com/juju/guiproxy">guiproxy</a>. This allows us to talk to all of the various services that back our application in its live environment while proxying websocket requests to where they are going, as the proxy knows all of their addresses, while the GUI does not.</p>
<p>We’ve mostly used this for developing locally, where we start the GUI with <code>make run</code> and then run guiproxy. Running the GUI starts a pyramid server on port 6543, and guiproxy sets up a server running on :8042 that manages all of the proxying. You could visit the gui on :6543, but none of the websockets would reach the services, as it doesn’t know their addresses, so you visit the proxy at :8042, it proxies requests to the GUI and guides the websockets where they need to go.</p>
<p>However, I run things a little differently sort of by accident. Firstly, I have a Mac at home and don’t want to do what it takes to get the GUI up and running on this box, since that’d likely require vagrant. Secondly, as I wanted to work from anywhere and didn’t want to open up my home network so that I could access the GUI running on one of my other machines.</p>
<p>The end result is that I spun up a remote server — a linode, in this case — to work on. It also runs things like my <ahref="https://thelounge.github.io/">IRC client</a> and such. I set this up at work.drab-makyo.com. I work on the GUI there, and that’s where it runs. For a while, I would just run guiproxy locally:</p>
<divclass="codehilite"><pre><span></span><code><spanclass="err">guiproxy -gui http://work.drab-makyo.com:6543 -env production -controller jimm.jujucharms.com:443</span>
<p>With our most recent sprint (which I’m writing from now), we needed to stand up a long-running instance of the GUI running a specific branch for some testing. I spent a bit of time thinking about just how to do this, but it turned out fairly easy: there’s no need to run the guiproxy on your local machine; you can run it wherever you want.</p>
<p>We wanted this instance to be set up on a relatively pretty URL. I could have directed people to https://work.drab-makyo.com:8042, but that wasn’t really desirable for our tests. We wanted something that had looked like we had tried. I have <code>makyo.io</code> for short URLs and redirections, so I set up https://jujugui.makyo.io. This is how that worked with nginx:</p>
<li>The GUI must be available from a different URL than from the proxy. jujugui.makyo.io <em>only</em> proxies requests to the proxy, so it’ll have to be something else. ~~This can be localhost, of course, but can also be the fully qualified URL.~~ I still have work.drab-makyo.com up and running, so I used that.</li>
<li>We have SSL set up, but the GUI in dev mode expects the websocket to be insecure. We’ll need to manually upgrade that to WSS so that the browser doesn’t complain.</li>
<p>I know this is a super specific case, but it just goes to show how to get all these parts talking together with tooling to help you along the way.</p>
