Cloudera Docs

Proxy setting best practices

Learn about best practices for using environment variables to propagate proxy settings.

In Kubernetes, proxy settings can be propagated to pods through the use of environment variables in pod specific configurations or through ConfigMaps or Secrets that are mounted as volumes within pods. This allows the proxy settings to be passed down to individual containers within the pods. However, it is important to note that not all applications may automatically inherit these settings, and some may require additional configuration within the container image or application code to properly utilize the proxy settings.

It is important to note that the use of no_proxy or NO_PROXY environment variables to bypass proxy settings may not be consistently respected by all third-party libraries or application codes. While some libraries or application codes may automatically honor these settings, others may not.

Many popular libraries and frameworks in various programming languages, such as Python, Java and Node.js, have their own way of handling proxy settings, which may not necessarily rely on the no_proxy or NO_PROXY environment variables. These libraries may have their own configuration files or internal settings that dictate how they handle proxy configurations, and these settings may not always align with the no_proxy or NO_PROXY environment variables set in the Cloudera Management Console.

As a result, it is important to be aware that relying solely on no_proxy or NO_PROXY environment variables may not provide consistent results across all libraries or application codes used in a project. In some cases, it may be necessary to clear out the http_proxy, https_proxy, no_proxy, or NO_PROXY environment variables in your project's environment variables or configuration files to ensure that the third-party libraries or application codes do not attempt to apply proxy settings at all.

To ensure that proxy settings are consistently respected across all libraries and application codes used in a job or session, you must review the documentation and configuration options of each library or application code, and configure them accordingly.

However, if you ever have to manage a stack written in multiple languages, you might need to consider some best practices for setting HTTP proxy configurations:

For http_proxy and https_proxy:
  • Use lowercase form. HTTP_PROXY is not always supported or recommended.
  • If you absolutely must use the uppercase form as well, be sure both versions share the same value.
For no_proxy:
  • Use lowercase form.
  • Use comma-separated hostname:port values.
  • IP addresses are acceptable, but hostnames are never resolved.
  • Suffixes are always matched (for example, example.com will match test.example.com).
  • If top-level domains need to be matched, avoid using a leading dot (.).
  • Avoid using CIDR matching since only the Go and Ruby languages support that.