[FEATURE REQUEST] Painless access from local host to hosts/ports on private network

[al-dpopowich]

My use-case: I use RDS (postgres) in one of my environments and need to do backups so I can test schema and data migrations. Ultimately I need these backups on my local host so I can develop the migrations.

What I wish we had was a ssh-like option to exec: copilot svc exec -L localport:remotehost:remotport.

Lacking that I've created a "bastion" Backend Service which launches a stock postgres image. An abbreviated manifest looks like this:

name: bastion
type: Backend Service

image:
    # the FROM is public.ecr.aws/docker/library/postgres:14.10-alpine3.19
    build: deploy/postgres/Dockerfile
exec: true
entrypoint: ["tail", "-f", "/dev/null"]

In particular, note the entrypoint: the image sleeps instead of running the default entrypoint (starting a postgresql server). With the above I can run copilot svc exec -n bastion and run psql, pg_dump, etc. Works like a charm. However, any backups end up on the container and it's very painful to get the files off the container.

I did stumble on to run local --proxy which I thought would solve my problems, i.e., first run copilot run local -n bastion --proxy, then in another terminal run docker exec -it CONTAINER /bin/bash and run psql, pg_dump there.

However, when I run copilot run local -n bastion --proxy:

1. The manifest entrypoint is ignored and the container is run with the image's default entrypoint, which, in the example above, results in an error because of missing environment variables required by the default entrypoint (which I don't want to run anyway).
2. I still have the issue of files living in the local container. While I can use docker cp, what would be much, much better: be able to specify docker run options like -v.

#5441 was closed because #5263 (run local --proxy) was the suggested
solution. I still think an explicit port-forwarding solution (via svc exec) is a powerful, useful tool that should be reconsidered.

I can live with run local --proxy but, minimally, need it to honor the manifest's entrypoint (and command, too), or offer command-line options to specify. And as noted, it should allow bind-mounting host paths.

Thanks!