juju/docs

Documentation for Proxy Configuration Could Use More Detail

Closed this issue · 7 comments

manadart commented

See where I lent a hand to someone attempting to set this up here:
https://bugs.launchpad.net/juju/+bug/1830988

  • It is worth pointing out that https-proxy should use a HTTP protocol (without S).
  • An example bootstrap command with concrete examples would be helpful.
  • Explicitly stating that for LXD deployments, the address of the LXD server on the bridge network (maybe the whole bridge subnet) should be added to no-proxy.
  • For hosts inside the proxied network, it is also worth pointing out that the local environment should be set up to use the proxies, because deployment requires the Juju client to access the charm store directly before calling the Juju API.
pmatulis commented

@manadart Thanks for this. 🍔

manjo-git commented

After some RTFM and experimentation, here are some things to consider as well:

Exporting http_proxy and https_proxy environment variables could create problems with certain charms ( I know it does mess up etcd.) An alternative is to configure your model's juju-http-proxy and juju-https-proxy settings. For example:

juju bootstrap localhost lxd-bionic <insert --config no_proxy, http_proxy and https_proxy options as needed>
juju add _model <name>
juju model-config juju-http-proxy=http://squid.internal:3128 juju-https-proxy=http://squid.internal:3128

Any services deployed will also need to reach other machines on this host, so use juju-no-proxy to allow this. For example.
juju model-config juju-no-proxy=127.0.0.1,localhost,::1,10.51.29.0/24
(where lxd bridge has ip 10.51.29.1 and the nodes would have an ip of 10.51.29.X)

After you deploy your charm/bundle, you can also set individual charm proxy for those that need to use snap to install etc. For example:
juju config etcd snap_proxy=http://squid.internal:3128
juju config <insert charm name here> snap_proxy=http://squid.internal:3128 http_proxy=http://squid.internal:3128 https_proxy=http://squid.internal:3128

pmatulis commented

@manjo-git Awesome. I may question you on some of this. 👍

pmatulis commented

To begin, there is documentation on this. See Using the localhost cloud offline, linked from the Working offline page. I will start enhancing it based on the information in this issue.

pmatulis commented

@manadart

For hosts inside the proxied network, it is also worth pointing out that the local environment should be set up to use the proxies, because deployment requires the Juju client to access the charm store directly before calling the Juju API.

  1. By "hosts" you mean machines that can potentially house a Juju client?
  2. When deploying a charm, my understanding was that the client makes a request to the controller, which performs the download.
  3. If the above is true I do see how a non-remote LXD controller and the client are bound together.
manadart commented
  1. By "hosts" you mean machines that can potentially house a Juju client?
  2. When deploying a charm, my understanding was that the client makes a request to the controller, which performs the download.
  3. If the above is true I do see how a non-remote LXD controller and the client are bound together.
  1. Yes.
  2. The controller does download the charm itself, but the client accesses the charm meta-data to do some validation client-side before making that request.
  • 👍1