Related

Why am I getting a Deploy Error: Health Checks? Question Question
How can I see the build logs for my application if the build was skipped for a deployment? Question Question

Question

App Platform component to component requests

Posted December 29, 2020 1.6k views
DigitalOcean App Platform

I’m interested in hosting an Nginx reverse proxy on App Platform via Docker which will be used to proxy requests to other components in the same app and enforce rate limits.

I’ve seen a few references to internal communication via App Platform:

  1. How to call an App from another service / app?
  2. How to run single nginx and multiple Laravel instances in the App Platform
  3. How should I implement proxying and redirects on the app platform?

I can’t find any official documentation about the App Platform internal routing feature, but the consensus seems to be a component in App Platform can send requests to other components within the same app via http://component-name.

For example, consider an App Platform app with the following components:

  1. Nginx reverse proxy named nginx (Web Service)
  2. Rails server named rails-server (Web Service)
  3. Go server named go-server (Web Service)

It appears as though Nginx can proxy requests to the other components by listing http://rails-server and http://go-server in a proxy_pass rule.

My questions are as follows:

  1. Where can I find App Platform documentation for this feature?
  2. Do components in an App Platform application exist within a VPC?
  3. Are component to component requests such as http://${component-name} routed on the public Internet?

The internal routing functionality seems like quite a feature but I’m concerned about the fact that I can’t seem to find documentation for it.

Add a comment
jmp12
By:
jmp12

Related

Why am I getting a Deploy Error: Health Checks? Question Question
How can I see the build logs for my application if the build was skipped for a deployment? Question Question

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
2 answers
bojand December 29, 2020

Hello, Thanks for your interest in DigitalOcean App Platform.

  1. All service components in the same app can communicate over a local network using the component name as the address. Additionally services can be configured to be “internal services” by specifying “internal_ports” property in the app spec. Here is an example repository utilizing this feature. I agree the documentation for this feature is lacking, and we are working on enhancing it with more details and examples.

  2. No. We are exploring VPC for our roadmap potentially, but nothing to share publicly.

  3. No, services within the same application share a private network, and these internal requests should not go over public internet, and don’t count against the bandwidth utilization for an app.

Reply Report
  • jmp12 December 30, 2020

    Hi @bojand and @cbaker, thank you both for your informative answers!

    The internal_ports setting for components seems like a really useful feature. Hopefully, it will make it to the documentation (and GUI) soon.

    My main concern is sending HTTP traffic through this network and ensuring the traffic is secure. Does anything outside of an app have access to an app’s private network? Is it otherwise secure to forward HTTP traffic through this network as if it were a VPC?

    @cbaker not to detract from my original question, but you mentioned internal_ports can facilitate any TCP protocol. Does this mean App Platform supports message brokers, such as MQTT, for component to component messaging within the same app?

    Reply Report
    • cbaker December 30, 2020

      The app’s private network should offer similar security to a VPC.

      As for MQTT, any TCP protocol should work with the internal_ports. That said, running stateful services like a queue directly in App Platform is not recommended. The local disk of App Platform services is only ephemeral and will be regularly discarded for new deployments or when the service is rescheduled maintenance. Also, while App Platform will normally run the desired number of instances (ie. instance_count), an extra instance may run concurrently while old instances are being replaced. For persistence we recommend an external database or queue like DigitalOcean’s managed Postgres, MySQL, or Redis.

      Reply Report
cbaker December 29, 2020

It looks like @bojand beat me to this. I’ve left mine below as it adds some additional details. Sorry for the sparse documentation. I’ve made an internal ticket to prioritize official documentation of this functionality.

Each App Platform App has a private network, though at present these are separate from customer managed VPCs. Workers, jobs, and services may connect locally (not over the public internet) by component name to services within the same app.

The app spec document for service components may include a list of internal_ports, and/or an http_port. http_port is required unless at least one port is specified in the components internal_ports list. If an http_port is specified, the service will be expressed both internally within the same app AND publicly at the apps ingress domains. Services with at least one internal_ports port and no http_port are only accessible locally within the same app.

The component name of each service resolves (via the app’s default DNS server) to a load-balancer which balances new connections (layer 4) across each healthy service instance. If you’re using the internal_ports, the load-balancer will be available at each listed port.

For example, a service web with a spec {"services": [{"name": "web", "internal_ports": [8080, 3000]}]} would be available at http://web:8080 and http://web:3000. If a the service specifies an http_port, it’s available at that port and port 80, unless it’s otherwise overridden in the service’s internal_port.

For example, {"services": [{"name": "web", "http_port": 8080}]}) would be available at http://web:8080, http://web:80). A port specified as http_port MUST implement the HTTP protocol, but internal_ports can facilitate any TCP protocol.

edited by kamaln7
Reply Report

Related

Looking for something else?

Ask a new question Search for more help