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 Specification to route subdomains to individual services

Posted October 18, 2020 1.6k views
DigitalOcean App Platform

Can the following setup be achieved with a single App Specification file (= single App)?

  • single managed PostgreSQL Cluster (PCLUSTER)

  • example.com is the main domain and it serves a next.js application from production it branch; it connects to api.example.com

  • api.example.com is Laravel API from production git branch; it connects to production database in PCLUSTER

  • example-staging.com is staging area; it runs next.js from staging git branch and connects to api.example-staging.com

  • api.example-staging.com is Laravel API from staging git branch; it connects to staging database in PCLUSTER

I am confused about how to configure the domains top level setting and routes per-instance settings to make this setup work. Please advise.

Add a comment
ReWild
By:
ReWild

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
1 answer
snormoredo October 18, 2020

@ReWild 👋

Currently all routable components in an app would need to share the same set of domains, so if you wanted your next.js app on a different domain than your API then they would have to be separate apps for now. Similarly for your staging app. This may change in the future, especially if we hear enough feedback about it.

An alternative would be to put your nextjs site on example.com and your API service on example.com/api (via the route path config), within the same app. You then also have access to bindable env variables that can be used to reference other components in your app, on the internal network or external depending on if you nextjs is deployed as a static site or service. In this model, your staging app would still be a separate app for now.

Reply Report
  • ReWild October 18, 2020

    Thanks, this clarifies things. If we cannot route subdomains to services individually, what would domains/[Nth]/wildcard=true be used for then? Could you please give an example.

    Reply Report
    • snormoredo October 18, 2020

      Great question. A use-case for wildcard domains would be if you wanted to serve the same app on all *.example.com domains, and possibly render different content or themes depending on the incoming sub-domain (i.e. white-label).

      Reply Report
      • ReWild October 18, 2020

        In this case, can I have nginx be the “entry point” for the domain and subdomains, and let it route accordingly to various services depending on the domain name?

        For example:

        server {
  server_name api.example.com;

  location ~ \.php {
    # ...    
    fastcgi_pass http://laravel_api:9000;
  }
}

server {
  server_name admin.example.com;

  # ...
  location ~ {
    proxy_pass http://nextjs_admin:3000;
  }
}

server {
  server_name example.com;

  # ...
  location ~ {
    proxy_pass http://nextjs_public:3000;
  }
}

        Is this a viable setup with the App Platform?

        Reply Report
        • snormoredo October 18, 2020

          Yep that’s a perfectly viable and appropriate setup for the App Platform. Note that you’ll want to reference components on the internal network using port 80 though, so in your example you’d use http://laravel_api instead of http://laravel_api:9000.

          Reply Report
          • ReWild October 18, 2020

            If http://laravel_api is available at port 80, does it mean that it is also available publicly through some public URL?

            Reply Report
          • snormoredo October 18, 2020

            Currently any service component defined in your app will be available via the app domains on the route path configured for that service. We plan to introduce “internal services” in the future for the use-case where you don’t want to expose these publicly, and just want them available to your other services over the app internal network.

            Reply Report
          • ReWild October 19, 2020

            @snormoredo any indicative ETA for the internal services feature? This is a deal breaker for our setup. Many thanks!

            Reply Report
          • snormoredo October 19, 2020

            @ReWild I can’t give a specific date, but internal services should be available in the near-term future; days, not months.

            Reply Report
          • snormoredo October 29, 2020

            @ReWild We released support for internal services yesterday. You can make use of these with the internal_ports field on service specs as follows:

            name: sample-golang
services:
- name: web
  github:
    repo: digitalocean/sample-golang
    branch: master
  internal_ports:
  - 3000

            If you specify internal_ports without http_port, then the service will only be accessible via the internal network.

            Reply Report
        • joeAnemone June 30, 2021

          @ReWild you don’t happen to have any code you could share for this approach? I’m looking to achieve the same thing as you, where I need different components within my app to be available on different subdomains. But I’ve little nginx experience - any help would be appreciated. And @snormoredo this would be a great feature, is it on the roadmap?

          Reply Report

Related

Looking for something else?

Ask a new question Search for more help