Copilot-cli: "path" is being ignored

[bpottier]

I'm provisioning a load-balanced service and I have "/hook" in the manifest for the path but it creates the load balancer with just "Requests otherwise not routed", so "/" I think. I should mention that at the time of provisioning there is no service I have answering at "/".

[efekarakus]

Hi @bpottier !

I tried re-producing the issue but couldn't :(. I created an app, with a single load balanced web service, here is my manifest file:

name: frontend
type: Load Balanced Web Service

image:
  build: ./Dockerfile
  port: 8080

http:
  path: 'hello'
  healthcheck: '/hello'
cpu: 256
memory: 512
count: 1

Note that I have updated the healthcheck setting as well to point to a valid path as I don't have a handler for / in my service code:

'use strict';
const express = require('express');

const PORT = 8080;
const HOST = '0.0.0.0';

const app = express();
app.get('/hello', (req, res) => {
  res.send('Hello World');
});

app.listen(PORT, HOST);
console.log(`Running on http://${HOST}:${PORT}`);

Is your setup different than this?

[bpottier]

Practically it's the same setup. Does you have an actual listener rule in the load balancer (created by copilot) that says IF Path is /hello THEN Forward to ?

[efekarakus]

Yup:

Note that the http.path field in the manifest is "hello" and not "/hello" in the example above

[bpottier]

Ah, I used the path '/hook' when initially provisioning the service. I'm guessing that's why? I've since changed the path to 'hook' after deleting the rules I added manually but the Path rule was not added back. Does this only occur at the time of init?

[efekarakus]

The listener rule should be updated during deployments so when running copilot deploy.

We'll take the following action item on our end:

1. Make sure that both "hook" and "/hook" are valid values for http.path

[bpottier]

Hmm. I made a change to create a new commit but the rules still aren't being updated.

[efekarakus]

Interesting, do you see the RulePath parameter updated in your CloudFormation stack?

[bpottier]

Yeah it's there. If it makes a different I'm using a domain with my application and I've modified the http rule to redirect to https.

[efekarakus]

hmm then I'm not sure why it's not applying it. Is there a stack event that shows that the listener rule is being updated? I wonder if it's not doing anything because there was some manual tweaking.

[bpottier]

This is from an "UPDATE_COMPLETE" stack:

[efekarakus]

OOH okay! If you have a domain name associated with the application Copilot does only host header based routing, so the service can be accessed at hook.{envName}.{appName}.{domain}.

We'll take an action item to redirect http://<elb endpoint>/hook to https://hook.{envName}.{appName}.{domain}

[bpottier]

Okay. I wonder if that should be a choice? We're essentially presenting different services as a single application behind a load balancer so using the paths to direct the client is how we are planning on doing it.

I'm assuming then there won't be an issue with my manually managing the rules? ... I'm still a little unclear/worried what I'm allowed to change that won't confuse copilot or get reverted. ... also sorry for blowing up your issues but I'm trying to understand copilot front to back so we can get it into production!😀

[efekarakus]

sorry for blowing up your issues but I'm trying to understand copilot front to back so we can get it into production!😀

Of course, happy to help!

I'm assuming then there won't be an issue with my manually managing the rules?

You can manage them manually, as long as they are separate from the ones Copilot creates. The only issue that you might run into is during service deletion when CloudFormation tries to remove the load balancer. Since there are extra listener rules that Copilot isn't aware of the deletion of the resource will fail. In that situation, you'll have to manually remove those rules first and then try svc delete again.

I wonder if that should be a choice?

If you wouldn't mind, can you share with us what are the types of listener rule changes you made? This would help us capture the use cases for the listener rules we'd like to expose in the manifest for services in an app with a domain

[bpottier]

In my current scenario I want to route to my frontend services by path. We're presenting a number of services to our clients as a single application and we'd like to be able to use say, www.example.com/svc1, instead of svc1.example.com.

So the changes to the listener rules have just been "if path is /svc1 ... if path is /svc1/* forward to svc1-target-group". Does that help?