Docs: How to use Dev Proxy running in a Docker container

[waldekmastykarz]

Now that we've published the first version of Dev Proxy in a Docker container, let's add docs that explain how to use it.

Include:

• Acquiring the image
• Trusting the certificate
• Configuring the host to use it as a system proxy (optional)

[tPl0ch]

@waldekmastykarz I am currently blocked by the availability of the docker image. We have a docker-compose test-containers set-up, and would love to integrate the dev-proxy docker image as early adopters.

Could you just add the information here to the ticket, at least the image location?

Thanks!

[waldekmastykarz]

Hey @tPl0ch, sorry for the lack of information on our part. We'll get it done asap. Meanwhile, here's the image: https://github.com/orgs/dotnet/packages/container/package/dev-proxy. Please, don't hesitate to let us know if we can help with anything.

[tPl0ch]

@waldekmastykarz - yeah, I found the image, and got it running smoothly with a custom dev-proxy config mapped into /config via a docker volume mount. Now I am stuck with the step "Trusting the certificate" I guess:

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I was looking into different GH issues, but they were rather related to host installations of dev-proxy, and not the docker installation.

Is there more info on how to resolve the certificate error?

EDIT: I am working on a Linux machine running docker-compose

[tPl0ch]

@waldekmastykarz OK, so I experimented a bit around the certificate issue and made it work. But I have a few improvement suggestions.

Option 1: Central dev-proxy ca-certificate

Instead of (re-)generating the certificate in the docker container, it should be possible to have a single dev-proxy certificate uploaded to a central public location (which then could be downloaded into the image when building the container if needed). This enables dev-proxy users to fetch the certificate without having to awkwardly copy the container cert via docker cp, and also build automation around it (e.g. adding the cert to the Java ca-certs), as well as only having to do this once, even when the container is completely removed and started again (which would again generate a new cert).

Option 2: Command to stream the generated root ca-certificate to the host

Given Option 1 would not be possible, then there should be at least a way to easily access the root cert from the host, maybe via a command, or even better an endpoint that streams the certificate contents (e.g. via HTTP). Then users can easily fetch the newly generated certificate from the proxy.

---

Any of the options above would make working with the dev-proxy docker image a lot easier.

[waldekmastykarz]

Thanks for trying it out and the suggestions. The way Dev Proxy is built today, is that it automatically detects if there's a certificate in a specific location or not, and if not, automatically creates it and if possible, adds it to the trusted certs on the machine. This simplifies onboarding for new users. When you run it in Docker that last part works a bit differently since you have to register the cert on your host. To make it easier to get to the certificate, in the Dockerfile we pre-create it (

dev-proxy/Dockerfile

Line 44 in a685f34

RUN /app/devproxy/devproxy cert ensure

) so that it's a part of the image, and you don't need to re-register it on your host.

Does this help?

[tPl0ch]

@waldekmastykarz I don't think you can use the same approach for host installations and docker installations. You are running the cert ensure command during build-time, but this would need to be done during run-time, when volumes are mapped into the docker image.

Docker images should have no notion of the host, other than the volumes mapped into the container. How should a docker image based on e.g. Ubuntu know that the host is a Mac OS X system?

[waldekmastykarz]

The generated cert is put in a different folder than the one that's mounted to the volume, so it's not overriden. The generated certificate is the same for all OSes, it's just different how you make it trusted on your host, but that's a manual step that you need to do after you start the container and copy the certificate from it.

[tPl0ch]

@waldekmastykarz Again, the current workflow ist sub-optimal when trying to use DevProxy in a CI environment. Every time a new version of the docker image is created, a new certificate is generated that does not match the previous one, hence the pipeline starts failing (this was just the case today when a new beta version had been released five hours ago). In many of the CI environments (in our case GitLab CI) you cannot access the file-system of the linked docker containers. They are only accessible via tcp/ip host/port requests.

So instead of re-generating the cert in every new docker build, generate it once for the whole project, and make it available via a simple HTTPS link. You can still include it within the docker builds by running curl / wget inside the docker build script.

This would enable CI environments to be set-up once and be future-proof for any new dev-proxy docker build.

[waldekmastykarz]

Got it. Thanks for clarifying. Let me check if I understand it correctly what you're proposing:

• generate a cert and put it somewhere public (let's say our GitHub repo)
• in the Dockerfile, download that cert to include it in the image. Put it in the same location where Dev Proxy expects it to be
• you can download the same cert from the same URL on in your CI agent/host and set up as trusted
• we need to regenerate the cert once every ~360 days before it expires

Correct?

[tPl0ch]

Yep, that's my suggestion, which will make integration for CI environments much easier, and still keep the current behavior the same to not affect user-space.

[waldekmastykarz]

Thanks for the suggestion. Let me try it and report it back.

[waldekmastykarz]

I thought about it some more, and from security point of view it would be better to use a unique certificate per machine. Would it work for you, if we mapped a volume to the cert folder and if the cert isn't there we create it (basically first run), and if it's there we use it (2nd + following use)? Also, if you want to avoid us creating the cert on the first run, you could create your own root cert and put it in the volume for Dev Proxy to use.

[tPl0ch]

Hmm, unfortunately GitLab CI does not allow mapping volumes (yet). But I understand the security concerns, given that some people use it as a system proxy. So your suggestion to use a VOLUME should make things better.

In that case the only valid option for us would be an endpoint to stream the cert from the docker image, but we can add that in a custom build that extends the dev-proxy base image.