search

jason-johnson / azure-pipelines-tasks-terraform

Azure Pipelines extension for Terraform
MIT License
124 stars 53 forks source link

Unable to recongize proxy when the task is running in container job #329

Closed KristofKuli closed 11 months ago

KristofKuli commented 1 year ago

Dear Support,

We had an issue earlier, where the task was not to work behind company proxy. That has been solved, however we are experiencing the same then the task is defined in a container job. The error we get is: Terraform not installed, downloading from: https://releases.hashicorp.com/terraform/1.2.8/terraform_1.2.8_linux_amd64.zip Terraform file name as: terraform-1.2.8-6f9a8c1f-112a-44fb-9a88-f254e345bda6.zip Downloading: https://releases.hashicorp.com/terraform/1.2.8/terraform_1.2.8_linux_amd64.zip

[error]Error: Terraform download from url 'https://releases.hashicorp.com/terraform/1.2.8/terraform_1.2.8_linux_amd64.zip' failed with exception 'Error: tunneling socket could not be established, cause=connect ECONNREFUSED 127.0.0.1:8080'

Finishing: TerraformInstaller

YAML snippet: stages:

Could you please check if you are getting the same error on your side as well?

jason-johnson commented 1 year ago

This is the older version of the provider. The provider should now be:

JasonBJohnson.azure-pipelines-tasks-terraform.azure-pipelines-tasks-terraform-installer.TerraformInstaller@0

KristofKuli commented 1 year ago

Hi Jason,

Thank you for the tip! I have tried the newer provider, but I receive the same error.

[error]Error: Terraform download from url 'https://releases.hashicorp.com/terraform/1.2.8/terraform_1.2.8_linux_amd64.zip' failed with exception 'Error: tunneling socket could not be established, cause=connect ECONNREFUSED 127.0.0.1:8080'

resources: containers:

stages:

KristofKuli commented 1 year ago

Hi,

Is there any update on this?

KristofKuli commented 1 year ago

Could you please let me know, if there's any update on this topic? Have you checked the above scenario on your side as well?

piizei commented 1 year ago

Hi Kirstof, I would like to eliminate something. Could you test if it works with NO_PROXY set, like this:

env: HTTP_PROXY: "" HTTPS_PROXY: "" NO_PROXY: "https://releases.hashicorp.com"

KristofKuli commented 1 year ago

Hi Petteri,

I have tried it, but the result is the same.

piizei commented 1 year ago

Hi, Created a test-case for it, but I was not able to reproduce this.

This is the YML that works without any problem for us (don't mind the different task name, thats for our testing):

KristofKuli commented 1 year ago

Hi,

Do you also provide value to the proxy variables? Mine is empty, because I don't want to expose our company's proxy server.

piizei commented 1 year ago

Hi I tested both with empty proxy variables and without variables. The proxy variables from the server would not anyway be available in the container and should not affect.

KristofKuli commented 1 year ago

Are you tested it on Azure Pipelines pool? Because proxy is not needed for that, as it is located in public cloud. I just tested on our self-hosted pool, without specifying the proxy in the YAML, but it fails with the same error. If I do the same without container job, then it works (this wasn't working either, until you have made the change). "I tested both with empty proxy variables and without variables." - is it possible for you to test it behind proxy?

piizei commented 1 year ago

If I set the proxy variables: env: HTTP_PROXY: "http://localhost:9090" HTTPS_PROXY: "http://localhost:9090"

I get the same error as you:

[error]Error: Terraform download from url 'https://releases.hashicorp.com/terraform/1.2.8/terraform_1.2.8_linux_amd64.zip' failed with exception 'Error: tunneling socket could not be established, cause=connect ECONNREFUSED 127.0.0.1:9090'

So it works in container with both cases: variables set or not set.

Most likely your container or script inside is setting a proxy to 127.0.0.1:8080. Could you try to echo both variables in a script task before running the install terraform task?

KristofKuli commented 1 year ago

I am not following you right now. You set the proxy and the task fails immediately with the same issue, which I have reported. After that you mention that it works with and without variables as well. How it is working if it just failed? If I try the same on Azure Pipelines pool, then the task is able to download the required terraform version. However we are using our self-hosted pool, which requires the proxy to connect to hashicorp. Now this is not working inside the container job, even if the proxy is configured in the job.

piizei commented 1 year ago

Okay let me word it other way:

I did 3 tests with containerized task:

  1. I did not set any proxy variables at all:

    • It worked as expected and was able to download

  2. I set empty variables HTTP(S)_PROXY = ""

    • It worked as expected and was able to download

  3. I set the HTTP(S)_PROXY variables to http://localhost:9090

    • It worked as expected (tried to connect http://localhost:9090 proxy and failed because it did not exist).

So the task running in container is picking the passed HTTPS_PROXY variables correctly in all 3 scenarios.

In your first message you are setting the proxy variables as empty (HTTP_PROXY: "") but it looks like the download task is trying to connect proxy at 127.0.0.1:8080. This is why I was suspecting maybe something else in the container is setting the proxy variables and suggested to echo the variables in a bash/script task.

KristofKuli commented 1 year ago

As I mentioned in my previous comment, I don't set is as empty. Actually I specified "proxy" with brackets there, because I don't want to expose our company's proxy server. However when I submitted the comment, GitHub displays is as empty. To make it easier I am specifying here like this: env: HTTP_PROXY: "company.proxy.com" HTTPS_PROXY: "company.proxy.com"

piizei commented 1 year ago

Did you also change the error message on the first post (where it fails to connect 127.0.0.1)?.

If I set HTTP_PROXY to company.proxy.com:9090, I get error: tunneling socket could not be established, cause=getaddrinfo ENOTFOUND company.proxy.com company.proxy.com:9090 which looks like correct behaviour.

KristofKuli commented 1 year ago

I didn't change the error message. The proxy "company.proxy.com" is not a valid one, as I mentioned above that's just an example, because I don't want to expose our company's proxy server. If it is not possible for you to test this issue with an existing proxy from your end, then I don't think you will be able to troubleshoot and fix the problem.

piizei commented 1 year ago

Hi, I was just confirming that the problem is not the task (which I could fix). And it is not the problem, it tries to connect the proxy server (whether the proxy server exists is not relevant from the task perspective).

Curious about your case is that the error indicates that the proxy variable value is 127.0.0.1 and not the actual proxy address you gave in the proxy variables. So maybe something to do with dns resolution or the variable gets overwritten.

KristofKuli commented 1 year ago

In this issue, I received the same error message, which also indicated 127.0.0.1. Could this be a connection between that and the current issue? I mean, if the variables gets overwritten(which I don't think), then it should be related to this task, right?

KristofKuli commented 1 year ago

Hi Petteri,

Please let me know, if there's any possibility from your end to fix this issue. In case not, then I believe the best would be to close this Issue.

Best regards, Kristof

piizei commented 1 year ago

Hi Kristof, Likely there is nothing we can do. One thing you could check from your container is that you are installing the proxy certificates there as well?

jason-johnson commented 11 months ago

Hi @KristofKuli, any update?

jason-johnson commented 11 months ago

No further responses. Closing. Feel free to open if there is further information.