-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: sam local start-api --warm-containers doesn't work on docker #6688
Comments
Hi @cford1080, thanks for raising this issue. I was able to reproduce the problem and I've raised a PR #6697 that should hopefully resolve it. There is another factor here, however, which is how Docker runs SAM CLI inside the container. You need to ensure that it is being run as the main process and that it's not being wrapped by |
@mildaniel |
When using the warm-containers option to start-api running inside a docker container, it will also fail to resolve Omitting the warm-containers for either EAGER or LAZY resolves the issue. |
This is mitigated by adding the extra_hosts:
- host.docker.internal:host-gateway
I am currently omitting this option, but I wish to use the feature. If you review the sam-local-1 | 2024-02-13 22:48:13,235 | Resolving code path. Cwd=/home/cford1080/github/sample, CodeUri=./src
sam-local-1 | 2024-02-13 22:48:13,236 | Resolved absolute path to code is /home/cford1080/github/sample/src I am at a loss as to why this is using the host directories rather than the container's. |
We were able to find the root cause. It has to do with the I've raised a draft PR which should solve this issue too but the integration tests for this might take me some more time. |
Thank you, @mildaniel. As I mentioned, this isn't causing any showstopping issues because the option can be left omitted for now, but some testing could be sped up significantly if the container can remain warm throughout. Does this impact other sam local commands which use these same options? For example, if I open another project which uses |
These two commands use the same underlying logic for starting and running containers, including file watching and volume mounting. The PRs I've raised above should address the issue for both |
Patch is released in v1.113.0. Closing |
Description:
@lucashuy asked that I open a new issue after my comment on this existing (but closed) issue.
When adding the
warm-containers
option tostart-api
running inside a docker container, the following exception is thrown:samcli.lib.utils.file_observer.FileObserverException: Can not observe non exist path
I may be misunderstanding the docs on
docker-volume-basedir
, but it appears to me that since SAM CLI is running in a Docker container that this directory should be the directory inside the container. However, do notice that it is set to the current working directory with $PWD, which gives it the directory from the host, and it works this way.Another issue is that the containers spun off to run the lambda when
warm-containers
is working (see workarounds insteps to reproduce
) are not cleaned up when the SAM container goes down.Finally, I have observed this behavior in both this SAM provided-runtime image as well as this SAM NodeJs image.
Steps to reproduce:
docker compose -f docker-compose.exception.yaml up
curl localhost:3000
I have also included 3 other Compose files to demonstrate the following behaviors:
docker-compose.yaml
omitswarm-containers
and runs as expected (still, however, have a question aboutdocker-volume-basedir
)warm-containers
to speed up test executiondocker-compose.workaround1.yaml
includeswarm-containers
and is based on this workaround from a different issue. Everything seems to work except that after bringing down the SAM container, the containers spun off to run the lambda hang around and do not get destroyed.docker-compose.workaround2.yaml
includeswarm-containers
and duplicates the host directory to avoid adding theworking_dir
docker directive, for whatever reason someone may have for doing so. Everything seems to work except that after bringing down the SAM container, the containers spun off to run the lambda hang around and do not get destroyed.Observed result:
Result when exception occurs:
Result of
docker ps
when using the workarounds (leftover containers):Expected result:
warm-containers
tostart-api
behaves as defined in the docs.Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
sam --version
: 1.109.0Paste the output of
sam --info
hereThe text was updated successfully, but these errors were encountered: