copilot run local roadmap and feedback

[dannyrandall]

Hi everyone! We just launched copilot run local in v1.30.0, a new command to speed up the developer iteration loop when using Copilot. Our ultimate goal is for the command to be the best way to test your code without waiting for a deployment.

The purpose of this discussion is to:

1. Gather feedback from the community about how run local can improve and help you develop applications on ECS
2. Share our roadmap for the feature.

For our roadmap, we are currently investigating the following:

• Injecting your TaskRole IAM credentials instead of your current session credentials Shipped!🚀
• Forwarding network egress from your run local service to AWS Shipped!🚀
• Forwarding network ingress to your service in AWS to your run local service
• Respecting the essential field and stopping run local only if essential containers stop Shipped!🚀
• Respecting dependsOn to launch services in the correct order Shipped!🚀

Please share any feedback you have on the proposed items above, and we'd love to hear any aspects of your Copilot services you'd like to test locally!

[tyoc213]

This will be a new environment like local environment? (I guess no), also what means your primary container and any sidecars, I mean if I have added 4 services to the app and 2 storages? I will get 4 containers pointing to the remote storage?

Also as it says you need to do first a deploy... what if I want to select between staging and production?

Guess this is a good way to "remove" the necesity of a local docker-compose or not?

[dannyrandall]

Hey @tyoc213!

what means your primary container

This refers to the image specified by the image field in your manifest.

and any sidecars

This means the images specified in your manifest by sidecars.<name>.image, and any sidecars created for you by Copilot (e.g., from logging.image or observability.tracing)

When you run copilot run local, Copilot runs all of these images from a single service on your local machine. If you want to run multiple services at the same time, you can run copilot run local --name foo and copilot run local --name bar.

This will be a new environment like local environment

This uses your configuration from an existing service and environment, not a new environment.

what if I want to select between staging and production

There is a flag or prompt to select which environment you'd like to emulate! For a service foo, you can run: copilot run local --name foo --env staging or copilot run local --name foo --env production

"remove" the necessity of a local docker-compose

Sorta! If your services are already defined in a Copilot manifest, you can use copilot run local to test them on your local machine.

Hope this clarifies things!!😊

[nguyenchr]

ohhh this sounds very cool, my particular use case is that sometimes I need to connect to RDS instances (not provisioned by copilot) that live in the same private subnet of the VPC that the copilot services are in
either to pull a snapshot of the db (so I can debug an issue locally)
sounds like I should be able to now run this and as long as say the postgres client is on the image, I should be able to exec into my local container and connect to my db

one thing I want to clarify on is that you mention you forward ingress from the AWS service to your local, does this mean that is someone hits your production API https://myapi.com the request would actually go to your local machine rather than your prod services? if that's the case I probably wouldn't want to use this for my use case

forward network egress from my local to AWS is great, but I don't necessarily need the ingress option, although it would be good to do that if you are inspecting something strange like injected headers etc

[dannyrandall]

Hi @nguyenchr, thanks for sharing your use case!☺️ To clarify your question about AWS -> Local, your understanding is correct. Like you mentioned, it's probably not best to use the feature for production traffic, but could help if you're developing services where inbound requests are difficult to recreate. I agree this feature would be much nicer if we could forward only specific incoming requests via headers or something.

For your use case, one question I have is how copilot svc exec isn't meeting needs? Can you not use copilot svc exec, install whatever db tools you need in the container, and connect to your DB that way? Thanks in advance, just want to make sure I understand what you're looking for!😊

[erno]

Sounds really promising. I'd rank being able to access our copilot-deployed aurora RDS as the biggest thing. But also being able to receive web traffic from the copilot environment's load balancers would be very very good.

[bathsundeep-graticule]

I'd love to have a timeout for the service when using run local. We use run local in our CI to validate AWS secrets in different environments before moving to the CD where we deploy the service entirely. However, when run local successfully builds and runs our service locally, the container of course just sits there nicely and doesn't exit, therefore run local doesn't exit, and our CI hangs here.

It would be great if, after the service's main container comes up, we can have a configurable timeout that will exit the container and give us a useful exit code that tells us if our service started up and was running clean before the timeout hit.