In this article, you find the prerequisites and all the information you need to prepare Broker and configure your network for deployment.
- System requirements:
1 CPU, 256MB of Ram.
Network Access: Outbound port 443 for HTTPS via TLS. Whitelist *.snyk.io
Disk space: no disk space required. Broker outputs logs to stdout. -
Create a Snyk account and contact snyk@support.io to enable Broker integration for the organization for which you would like to implement the proxy. Each Broker is identified by a UUID token. Once Broker support has been enabled for your organization, you can access your unique Broker token on the organization’s Settings page from the Snyk UI, as described in Retrieve a unique Broker client token. This token is private, and must not be shared.
-
Install and set up Docker Hub from the client machine on which you want to install the Broker.
We recommend configuring:
-
at least two separate instances of the Broker client for every integration you plan on deploying, either on different hosts or installed via a Kubernetes system to ensure that you always have two (or more) instances running; for example, if you plan on deploying both GitHub and Jira, you should plan on installing for 4 instances, 2 of each to ensure redundancy.
-
separate Broker clients for every unique integration
Ensure each host designated for the Broker client installation has:
-
access to the on-prem Git deployment
-
an outbound TLS (443) connection to https://broker.snyk.io that is also allowed by any firewalls installed on your network. The Broker client needs to be accessible for webhooks coming from the Git repo. Alternatively, you can specify which port the Broker client listens on using the --port command line argument.
-
If you use a proxy server, ensure you configure it, and any firewalls, to allow the Broker client inbound and outbound access.
-
Traffic (very light) initiated from your network (i.e. webhooks) should be load-balanced across the broker instances for redundancy purposes; payloads transiting through WebSocket connection used to proxy the request to the broker server are small as well.
-
Traffic initiated from the Snyk (server) side always uses the latest Broker connection—we maintain a stack of the connections and always use the top one. If that Broker connection fails for whatever reason, Snyk removes it from the stack and uses the previous one for connection, and so on. All activity from our side (e.g. driven by recurring tests) appears on only one of your replicas at a time (the latest one to connect to us).
-
In practical terms, this means the amount of Snyk activity is proportional to the activity in your repos (or Jira) as that activity generates webhooks, which is distributed across all replicas.