I am working with the config.yml below and can’t seem to access a proxy server on the docker container started via setup_remote_docker by accessing its proxy from the docker container spec’d in (build: docker: image:) in my config.yml. Is this possible? I’ve started the second container running the proxy with -p 8080:8080 which failed. I additionally tried starting it with --network=“host” which also failed.
Curl returns “Failed to connect to IP address at port 8080: Connection timed out. Exited with code 1”
Appreciate any insight as to why networking appears to be failing between these two containers and what my options are.
Would you walk readers through each part of your docker run command? For example, what is the purpose of --network="host"? The run command with the -p feature will give you access to the container’s service on localhost:8080 in your build env without that.
(Meta: I’m not sure your title is very clear. What does “stood up” mean? I’ve tried to parse that several times mentally, and really come up blank ).
Cleaned up the title of this post. Stood up meaning started.
Regarding the docker run command. ‘–name zap’ enables downstream docker commands to reference this specific container by name. ‘-p 8080:8080’ maps the internal port 8080 within the container to the docker hosting this container’s port 8080. The purpose there so that you can do http://docker_host_ip:8080 and have the HTTP traffic forward over to the container and access the proxy. ‘–network=“host”’ from the docs seems to let the container’s network stack use the docker host’s network stack. So extra layers like network translation are removed. This was a test I was performing to help remove these extra layers in hopes of accessing the proxy from the CircleCI Node docker container.
Researching online it appears it may be impossible to access a docker container running on the docker host created by the setup_remote_docker command by the docker container executor specified in build: docker: image:.
Appears to work. proxy on owasp/zap2docker-stable container can be accessed successfully by nc, curl and REST. I think this issue can be put to bed. Hope this helps someone not waste the countless hours I spent on this.