Giters

puma / puma-dev

A tool to manage rack apps in development with puma

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Working with (not in) containers

cmeans opened this issue · comments

commented

We have a large collection of Rails apps with puma-dev working well for handling request routing for both http and https protocols (using the dev tld), however, we're now engaged on containerization, and obviously can't symlink to a container. The proxying capability only supports a single port. Can we use puma-dev to talk to a local container (for both port 80 & 443) or do we need to use tools like microk8s or minikube to handle communications for containers in a dev environment? (I'm not really expecting you to know about Kubernetes, so it's really whether or not we should still be able to leverage puma-dev for our locally hosted containers.)

commented

If you don't want to actually boot puma, puma-dev is probably the wrong tool for your usecase. Sounds like you just want the nameserver-to-local-port proxying.

Have you looked at https://github.com/codekitchen/dinghy?

commented

Thanks. I was not aware of dinghy. We're mostly using Mac OS, and Docker for Mac is working well for us... I don't believe Docker Machine is an option (or needed at this point). dinghy-http-proxy might be an option, but it appears to only work for a single docker container listening on ports 80/443...which is "fine" as Docker only lets a single container listen to a given port on a machine, but that is the real issue I'm trying to handle...I need multiple containers listening on the same port (different applications/services).

commented

Don't have enough context on your situation, but again, puma-dev doesn't quite sound like the right solution. I'm going to close this issue to keep things tidy.

But, I can't resist a good thought experiment. If you want to be able to access http(s)://service-a.domain.dev and http(s)://service-b.domain.dev running locally in diff containers, do you need something more complicated than /etc/hosts (or dnsmasq or legit domain that routes *.domain.dev to 127.0.0.1) and nginx?

  • App Alpha on Container A serving HTTP on localhost:20080 (arbitrary port pattern)
  • App Beta on Container B serving HTTP on localhost:20180 (arbitrary port pattern)
  • Nginx (on Container C or native) listening on 443/80 via server blocks w/ TLS config for service-a.domain.dev and service-b.domain.dev proxying to their respective ports.

If I understand your case correctly, which I'll admit is not terribly likely, terminating HTTPS at nginx saves the dual-port stuff you've mentioned. If there's a specific business case to ensure all inter-container communication is encrypted, serve TLS traffic from your containers, with no bare HTTP at all, and just have nginx do a TCP proxy.

commented

The tubbo/docker-dev project looks like an interesting idea. Would love to have docker-compose support integrated in puma-dev. Or maybe even support for Tilt.

commented

@nonrational I wonder if there's any motivation to reconsider this? It's been almost a year since this issue was opened, https://github.com/tubbo/docker-dev has been abandoned for a long time, and it still isn't possible to use Docker for Mac to run apps side-by-side with puma-dev. Whenever I want to switch projects I'm working on, I have to uninstall or reinstall puma-dev entirely.

commented

Whenever I want to switch projects I'm working on, I have to uninstall or reinstall puma-dev entirely.

Is that because you are using a single TLD for both docker and puma-dev DNS resolution? Are you able to use separate TLDs?

I still think puma-dev is the wrong place to put arbitrary, system-wide DNS rules. puma-dev tells macOS to forward a set of TLDs (e.g. -d puma) via /etc/resolver to its DNS resolver so it can route my-app.puma and boot an on-demand puma instance for it. Tools like dnsmasq are better suited for custom DNS resolution, on macOS or other *nix systems.

commented

Maybe someone™ could build a Ruby-based proxy app that ingests incoming puma-dev traffic, handles starting/stopping/reloading an arbitrary app and forwards requests? I imagine something that let's us create a file like this as ~/.puma-dev/whatever/config.ru:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'puma-dev-forwarder-dsl'
  # gem 'puma-dev-forwarder-procfile'
  # gem 'puma-dev-forwarder-livereload'
end

start  :shell, 'cd my-app-dir && tilt up'
stop   :sigterm
reload :restart
commented

Is that because you are using a single TLD for both docker and puma-dev DNS resolution? Are you able to use separate TLDs?

Changing TLD's for different projects sounds like a last resort kind of thing as it would affect configuration that the entire team uses. Also we have many projects that talk to each other. Some are in Docker, some are not. At a theoretical level, it feels like a bummer to have to tie the domain/tld to whether or not I've needed to dockerize an app. It seems like it shouldn't matter how the application is being served. I can get over that, however, if that's the only solution.

Tools like dnsmasq are better suited for custom DNS resolution, on macOS or other *nix systems.

@nonrational I'm not super sure how to take advantage of this. It just seems like a /etc/hosts alternative. Since puma-dev is serving on 127.0.0.1 and Docker is also serving on 127.0.0.1 so I don't know what to tell it to distinguish between them anymore.

Team members who haven't switched to Docker for Mac aren't having this problem. They used to let you run on a different IP so I could use that IP in /etc/hosts. I don't know what to do now.

EDIT: It also seems that by trying to point /etc/hosts to a .box domain, puma-dev is still picking it up in the default installation. Not sure why that is or how to get it to stop. I even tried uninstalling and reinstalling with -d test.