:wave: Working on getting the self hosted helm cha...
# general
m
👋 Working on getting the self hosted helm chart running, getting some errors 🧵
Copy code
> cloud-pricing-api@0.3.5 job:init
> npm run db:setup && npm run job:update


> cloud-pricing-api@0.3.5 db:setup
> node dist/cmd/dbSetup.js

{"level":30,"time":1648498249334,"pid":29,"hostname":"cloud-pricing-api-init-job-vxbxz","msg":"Starting: DB setup"}
{"level":30,"time":1648498249464,"pid":29,"hostname":"cloud-pricing-api-init-job-vxbxz","msg":"Completed: DB setup"}

> cloud-pricing-api@0.3.5 job:update
> npm run data:download && npm run data:load


> cloud-pricing-api@0.3.5 data:download
> node dist/cmd/dataDownload.js

{"level":30,"time":1648498253419,"pid":62,"hostname":"cloud-pricing-api-init-job-vxbxz","msg":"Starting: downloading DB data"}
{"level":50,"time":1648498253526,"pid":62,"hostname":"cloud-pricing-api-init-job-vxbxz","msg":"There was an error downloading data: getaddrinfo ENOTFOUND <http://pricing.api.infracost.io|pricing.api.infracost.io>"}
Kinda random DNS lookup error, though nslookup is fine
Copy code
kubectl -n ********* exec -ti cloud-pricing-api-d9df447d5-dfbhw -- /bin/bash                               
bash-5.0$ 
bash-5.0$ 
bash-5.0$ 
bash-5.0$ curl -L <https://pricing.api.infracost.io>
curl: (6) Could not resolve host: <http://pricing.api.infracost.io|pricing.api.infracost.io>
bash-5.0$ nslookup <http://pricing.api.infracost.io|pricing.api.infracost.io>
Server:		172.20.0.10
Address:	172.20.0.10:53

Non-authoritative answer:
Non-authoritative answer:
Name:	<http://pricing.api.infracost.io|pricing.api.infracost.io>
Address: 3.130.210.19
Name:	<http://pricing.api.infracost.io|pricing.api.infracost.io>
Address: 18.190.97.110
Name:	<http://pricing.api.infracost.io|pricing.api.infracost.io>
Address: 3.137.75.3
init image is using
image: "infracost/cloud-pricing-api:v0.3.5"
e
Hey Kevin! Let me see if anyone is online to help 🙂
b
Hey Kevin! 🙂
🙌 1
m
👋
b
This is interesting, let me try to run it on my machine, I haven't seen this before
Oh, it's in the k8s, that's why 😄
Have you tried to deploy CPAPI (cloud pricing API) locally?
m
yeah, this is using your helm chart on EKS 1.21
i haven't tried it locally
b
I haven't used it myself, unfortunately 😞 But @crooked-daybreak-55253 may know something about it. He's offline now, but should be back soon
m
hmmm yeah podman seems ok, maybe this is a weird edge case with EKS/Docker runtime/alpine
Copy code
podman run --entrypoint "/bin/bash" -it "infracost/cloud-pricing-api:v0.3.5"                                                                                 
bash-5.0$ 
bash-5.0$ 
bash-5.0$ 
bash-5.0$  curl -L <https://pricing.api.infracost.io>
{"error":"Invalid API key"}bash-5.0$
b
Oh, so it is resolved correctly here, just missing the header
m
yeah, thats expected
l
Could it be an ipv6 issue? Does
curl -L -4 <https://pricing.api.infracost.io>
work?
👋 1
m
Hmm, nope
from the pod -
l
Hmm, I’m trying it in our own EKS cluster and can’t reproduce
m
Copy code
bash-5.0$ curl -L -4 <https://pricing.api.infracost.io>
curl: (6) Could not resolve host: <http://pricing.api.infracost.io|pricing.api.infracost.io>
l
Copy code
kc exec -it cloud-pricing-api-f6478c5c7-g25rl -- /bin/bash
bash-5.0$ curl -L <https://pricing.api.infracost.io>
{"error":"Invalid API key"}bash-5.0$
Do you have a HTTP proxy configured?
m
Nope, this namespace should be able to reach out to the world
l
so does
curl -L <https://infracost.io>
work?
m
hmm, that fails as well. looks like its curl resolution in general
Copy code
bash-5.0$ curl -L <https://infracost.io> -v 
* Could not resolve host: <http://infracost.io|infracost.io>
* Closing connection 0
curl: (6) Could not resolve host: <http://infracost.io|infracost.io>
bash-5.0$ curl -L <https://google.com> -v 
* Could not resolve host: <http://google.com|google.com>
* Closing connection 0
curl: (6) Could not resolve host: <http://google.com|google.com>
but only from the alpine pods, I've got some internal apps on ubuntu images that are good
l
Weird, just trying something quickly…
m
i think i found the problem, one sec
l
ok, in the mean time I pushed a branch and image with a debian base image if that helps: https://github.com/infracost/cloud-pricing-api/blob/debian-base-image/Dockerfile DockerHub image: infracost/cloud-pricing-api:bullseye-test
core dns in EKS is going to append the search domains to infracost.io lookups, eventually forwarding resolution outside the cluster, which messes with musl apparently
adding a
dnsConfig
section to job-init seems to do the trick
Copy code
kind: Job
metadata:
  name: cloud-pricing-api-init-job
  namespace: lineartools
  labels:
    <http://helm.sh/chart|helm.sh/chart>: cloud-pricing-api-0.5.4
    <http://app.kubernetes.io/name|app.kubernetes.io/name>: cloud-pricing-api
    <http://app.kubernetes.io/instance|app.kubernetes.io/instance>: cloud-pricing-api
    <http://app.kubernetes.io/version|app.kubernetes.io/version>: "v0.3.5"
    <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: Helm
spec:
  backoffLimit: 6
  template:
    metadata:
    spec:
      restartPolicy: Never
      serviceAccountName: cloud-pricing-api
      dnsConfig:
        options:
        - name: ndots
          value: "1"
Copy code
> cloud-pricing-api@0.3.5 job:init
> npm run db:setup && npm run job:update


> cloud-pricing-api@0.3.5 db:setup
> node dist/cmd/dbSetup.js

{"level":30,"time":1648503942422,"pid":29,"hostname":"cloud-pricing-api-init-job-kzdzc","msg":"Starting: DB setup"}
{"level":30,"time":1648503942437,"pid":29,"hostname":"cloud-pricing-api-init-job-kzdzc","msg":"Completed: DB setup"}

> cloud-pricing-api@0.3.5 job:update
> npm run data:download && npm run data:load


> cloud-pricing-api@0.3.5 data:download
> node dist/cmd/dataDownload.js

{"level":30,"time":1648503946117,"pid":62,"hostname":"cloud-pricing-api-init-job-kzdzc","msg":"Starting: downloading DB data"}

{"level":30,"time":1648503957645,"pid":62,"hostname":"cloud-pricing-api-init-job-kzdzc","msg":"Completed: downloading DB data"}

> cloud-pricing-api@0.3.5 data:load
> node dist/cmd/dataLoad.js

{"level":30,"time":1648503959734,"pid":83,"hostname":"cloud-pricing-api-init-job-kzdzc","msg":"Starting: loading data into DB"}
{"level":30,"time":1648503959839,"pid":83,"hostname":"cloud-pricing-api-init-job-kzdzc","msg":"Loading file: ./data/products/products.csv.gz"}

{"level":30,"time":1648504143193,"pid":83,"hostname":"cloud-pricing-api-init-job-kzdzc","msg":"Completed: loading data into DB"}
l
okay that’s interesting thanks for finding, this has me thinking if we should drop the alpine image in favour of a debian-based image.
m
Yeah - we went with ubuntu across the board for our apps, the cloud images are pretty small and you get the benefit of the standard C libs 🤷
l
I’ve added https://github.com/infracost/helm-charts/issues/18 to track this if you want to watch it for updates. If you get a chance to test the Debian-based image that would be great. I’ll run some tests with our setup as well.
Also, would be great to get any feedback you have about the self-hosted setup so we can keep improving it 🙏. One thing that might be useful is the
/stats
page once you set it up. You can see how many cost estimates have been run and when the prices were last updated.
m
Apart from this bug, everything seemed pretty intuitive and documentation was good for the helm setup, so in general 👍 👍 👍
we like to keep atlantis fairly locked down so the self hosted infracost option works pretty well for our case.
l
🙌 awesome!