Add `kamal app open` command to open app in a web browser

[jeromedalbert]

Problem

Kamal is a no-PaaS tool with PaaS-like ergonomics, where you can easily open a production Rails (or other) console, a shell session, tail logs, etc. A small feature that could be implemented to further align with this vision is a command to open the app in a web browser, similar to Heroku's heroku open or Fly.io's fly apps open.

This would allow for quick access to a deployed web application, from the CLI, without having to manually copy/paste the URL from one of your browser tabs or your config/deploy.yml or some other file. Examples where this can be useful:

• right after deploying your app
• when switching between different Kamal-enabled repos
• in copy/paste-able Readme instructions
• any time you're in the command line and want to easily open the app in your browser

Solution

Add a kamal app open command. It opens the primary role's (usually web) first domain defined in proxy host(s), or falls back to the primary role's first IP address.

The implementation is short, so adding a dependency for finding the OS opening command (with a gem like launchy) felt like too much. But I can change the PR if needed.

[djmb]

I like this, but I'm not sure.

The command will not work properly in lots of setups - where there's no proxy host, where the host if a wildcard etc. Adding a command that's often broken seems a bit iffy.

[jeromedalbert]

Normally kamal app open wouldn't break because it would fall back gracefully.

For example when there is no proxy host, this PR already falls back to the primary IP, and a valid Kamal config always has at least one IP. Falling back to IPs is pretty handy as I often like to create short-lived apps where I don't bother to configure domains, so I access them by IP.

Normal non-wildcard proxy hosts (e.g. mydomain.com or alpha.mydomain.com) also work.

That leaves us with wildcards proxy hosts (e.g. *.mydomain.com) which can't be opened by a browser. Is this an issue though? I don't think Kamal currently supports wildcards in the proxy>hosts key unless I am missing something. But if it does kamal app open could maybe find the first non-wildcard host, or do its usual fallback to the primary IP. Or it could emit a warning that it cannot open wildcard hosts.

I think this would cover the majority of cases, and most apps have a pretty standard setup with normal domains or IPs. Do you have other breakage concerns or examples in mind?

[AxelTheGerman]

You would have to duplicate the host name, but this would also be possible using Aliases on a per project basis.

[jeromedalbert]

@AxelTheGerman I am not sure how this would be possible. Can you provide an example? AFAIK aliases are for things like app exec which execute on the server whereas this command executes on your local.

[AxelTheGerman]

@AxelTheGerman I am not sure how this would be possible. Can you provide an example? AFAIK aliases are for things like app exec which execute on the server whereas this command executes on your local.

Duh you're right... but in that case I guess it would be possible to A) write a custom rake task or B) creating a kamal-open gem that could read and parse the deploy yaml file as well.

It does seem much easier to add it into kamal but I'm agreeing with @djmb regarding

The command will not work properly in lots of setups

One option though for implementing it in kamal would just be to print a message that the app cannot be opened if we can't find the host/IP for the app