Fix: allow different proxy settings for control node and remote host

[adlotsof]

Since the http_proxy, https_proxy urls are different for me on localhost and on the remote target, the alloy role becomes useless. When setting apply: environment: in the include_role block, either localhost http request are broken or on the remote.

This PR fixes this issue by allowing for an alloy_locahost_environment variable to be set, independently of the apply: environment mechanism

[voidquark]

Based on your PR change, I assume that you are unable to communicate with the GitHub endpoint in a specific environment to determine what the "latest" release is. If that’s the case, you can resolve this by using pre_tasks in your playbook to discover the latest version from your custom source. If this is the issue you're facing.

Alternatively, you can specify the version directly in the format alloy_version: "1.4.3".

[kaio6fellipe]

Is there any specific reason to delegate this task to localhost? If not, we could remove line 11 with delegate_to, which I believe would solve the problem too (ps: I just came across this in an installation in an environment where we use proxy)

[voidquark]

The reason for using run_once and delegate_to: localhost is that we cannot assume or predict your specific environment. There are many ways to run Ansible, so the goal is to ensure the task of scraping the GitHub API to find the latest version is executed only once, even when the role runs on multiple hosts.

Additionally, it is common for Ansible to be executed from a dedicated Ansible control host, or through tools like AWX or AAP. By delegating the task to localhost and using run_once, the task runs only on the machine where Ansible is triggered, which is, in my opinion, the most logical approach.

That said, you can choose to specify the version directly, which avoids this issue altogether.

[kaio6fellipe]

Perfect, we included the version statically to get around the "problem", but to identify what to do, it was necessary to look at the tasks and identify that the problem was not related to our hosts, but rather to what was being done to the latest version, the error outputs were only indicating timeout for api.github.com.

Therefore, I believe that just one observation in the documentation for the alloy_version parameter, indicating that using the "latest" version may not present the expected behavior in environments that use a proxy, would be sufficient.

[voidquark]

I think this PR can be closed now as the issue is clear. Feel free to raise a PR to optimize the README for the latest version, as it requires connectivity to the GitHub API.