K6 cloud failed to run end points, but they worked fine on local

Grafana k6
1

K6 cloud failed to run end points, but they worked fine on local

error:
2ae870fbaedda2d0e01966": lookup wmsx-conveyor-receiving-api.xxxxx-test.net on 10.51.0.2:53: no such host instance_id=0 lz="amazon:us:columbus" test_run_id=1233185

image

I have followed below documents and applied all options 2. But no luck.

3

Hi @jigisha.shah !

Let me try to help you, but to do that, I need more details to do that.

It seems like this host is unavailable from the internet.

Is this a public endpoint? Do you connect to a private network? Do you use a VPN locally?

4

@olegbespalov Thanks!

  1. My endpoint is behind firewall and I do have to use VPN locally for execution. So I could only run my endpoints using:
    k6 run -o cloud xx.js

  2. But I now to use k6 cloud execution and hence I have made changes accordingly to my script as per mentioned into “General Questions” but still have issues.

5

I have made changes accordingly to my script as per mentioned into “General Questions” but still have issues.

It’s important to highlight that the approaches suggested in the General Questions require changes not only in script. The main idea here is to set up the exceptions for the firewall and essential that the API is publicly available (via the header, from the k6’s IPs range, etc.).

lookup wmsx-conveyor-receiving-api.xxxxx-test.net on 10.51.0.2:53: no such host

Also, this error indicates that k6 can’t resolve the domain. We have a workaround that is mentioned as option 3 in General Questions:

// In your options, map your a unique/unused/secret hostname to the IP of the server.
export const options = {
  hosts: {
    'https://very_difficult.to.guess.hostname.com': '1.2.3.4',
  },
};

But two things I have to highlight:

  • This solution requires that your firewall terminates SSL traffic; otherwise, it will not see the Host header in unencrypted form.
  • The API’s IP should not belong to a Private Network.

Let me know if that answers,
Cheers

6

Hi @olegbespalov , does it mean from General Questions Option 2 is not enough. Option 3 is actual workaround? If yes, then how to know which IP being used from “amazon:us:columbus” k6 cloud?

for example currently my swagger URL endpoint uses ip: 172.16.208.136, but i don’t have access to k6 cloud which AWS ip it will be using… so won’t able to map it.

Sorry, but not clear document, need example or state what goes where?

export const options = {
  hosts: {
    '<what is this host? amazon:us:columbus? or my swagger host ip?>': '1.2.3.4',
  },
};

So issue is, K6 cloud will pick up any random aws ip from say us:columbus region to perform my endpoint which is deployed on 172.16.208.136 server behind VPN.
Also, currently i am doing POC using K6 cloud (free version)

7

does it mean from General Questions Option 2 is not enough. Option 3 is actual workaround?

I wish I could say this, but it’s not. The thing is that both Options are more directions on how to deal with the firewall that protects your API from outside (the Internet). But it’s not possible to do that without changes in network configuration. Explicitly, without providing a way to access your API from the Internet.

Sorry, but not clear document, need an example or state what goes where?

It’s a workaround to solve the issue of the private DNS. Like in your case, your API has a hostname wmsx-conveyor-receiving-api.xxxxx-test.net, but I believe that hostname is available only inside your private network (e.g., VPN). It’s impossible to get the real IP with that name outside of the Internet. It’s precisely what happens with the k6.

To avoid this private DNS issue, the k6’s can be configured:

export const options = {
  hosts: {
    'http://wmsx-conveyor-receiving-api.xxxxx-test.net': '1.2.3.4', // where 1.2.3.4 is a public IP of your API
  },
};

And next time when the k6 should perform a call to wmsx-conveyor-receiving-api.xxxxx-test.net, it will know that it should call the IP 1.2.3.4.

for example, currently my swagger URL endpoint uses ip: 172.16.208.136

In that case, IP 172.16.208.136 is also the internal endpoint of your Privat Network (probably part of your AWS). And it’s not exposed to the Internet. So even the mapping from the Option 3 doesn’t help.

To sort that, I guess you have to coordinate with your DevOps (or who manages your cloud) and ask them if they can provide a way to access the API from the Internet.