To make it easy to test mock-proxy locally and to simplify developing changes
to the mock-proxy codebase, a docker-compose based local development
environment has been created.
To start this local development environment run:
./hack/local-dev-up.sh
This will start two Docker containers, mock_proxy_proxy_1 and
mock_proxy_client_run_${UNIQ_ID} and automatically drop you into a shell
session running bash in the client.
mock_proxy_proxy_1 runs the custom ICAP server and Squid proxy.
mock_proxy_client_run_${UNIQ_ID} runs a shell session with appropriate
http_proxy and https_proxy environment variables set to allow the user to
automatically interact with the mock-proxy setup on mock_proxy_proxy_1.
When you are done with a session, or having issues with the local development environment, you should run the script:
./hack/local-dev-down.sh
To clean up the local development environment.
The Routes file defines which endpoints should be mocked. It is defined in HCL,
and should be stored in your mocks directory at routes.hcl.
Create each route as a block. The host should match the hostname of the site
you want to mock. The path matches the path, but you can use rails route style
:foo substitutions to make dynamic URLs. The type can either be git or
http, depending on whether you want to mock a git clone operation or not.
# You can reach this at any /orgs/$VALUE/repos request, and a substitution will
# be added that replaces {key=org, value=$VALUE}
route {
host = "api.github.com"
path = "/orgs/:org/repos"
type = "http"
}Do not create overlapping routes. This will cause an error, as the mock routing logic cannot determine which route to apply to a given request.
By default, all mocks return a 200 when they succeed. That's not the only
possible thing you might need to mock though. In order to request a different
response code along for a mock, send along the header
X-Desired-Response-Code.
./hack/local-dev-up.sh
curl --head --header "X-Desired-Response-Code: 204" example.com
Using Squid's SSL Bump configuration, mock-proxy can also act as an
https_proxy and successfully mock upstream requests to HTTPS endpoints.
It does so in this local configuration using a self-signed certificate in
/certs. This self-signed cert is automatically trusted for local dev.
To generate these certificates, use the script: /hack/gen-certs.sh. This may
also be useful example code if you need to incorporate self-signed certs into
another system using mock-proxy.
If configuring mock-proxy in another environment, you will need to volume mount
a self-signed certificate to /etc/squid/ssl_cert/ca.pem, and trust that
certificate on any system attempting to use mock-proxy as an https_proxy.
mock-proxy also supports mocking Git Clones made via HTTP. To do so, add a route to your routes.hcl file:
route {
host = "github.com"
path = "/example-repo"
type = "git"
}You'll next need to add a directory (for this example) at
/mocks/git/github.com/example-repo. In this repo, you can then run a script
/hack/prep-git-mocks.sh to automatically initialize a git repo. Don't commit
this repo, as we don't want to manage git submodules here. You can unstage that
initialization with another script /hack/unstage-git-mocks.sh.
Once you've added a route, a directory exists at the correct path, and you've initialized git in it, you can run a clone by starting up the local dev environment and making an HTTP clone request:
./hack/local-dev-up.sh
git clone http://github.com/example-repo