consul-k8s icon indicating copy to clipboard operation
consul-k8s copied to clipboard

Setting External Server CONSUL_HTTP_ADDR

Open webmutation opened this issue 3 years ago • 6 comments

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Is your feature request related to a problem? Please describe.

When using external server the CONSUL_HTTP_ADDR environment value cannot be set via the Values file, since the template uses instead the HOST_IP

            {{- if .Values.client.enabled }}
            - name: CONSUL_HTTP_ADDR
              value: http://$(HOST_IP):8500
            {{- else }}
            - name: CONSUL_HTTP_ADDR
              value: http://{{ template "consul.fullname" . }}-server:8500
            {{- end }}

It would be useful to be able to set this value, when using externalServers, in this case our CONSUL_HTTP_ADDR will point to the external server.

When deploying the following Values file

global:
  enabled: false

client:
  enabled: false

externalServers:
  enabled: true
  hosts:
    - '1.1.1.1'

syncCatalog:
  enabled: true
  k8sDenyNamespaces: ["kube-system", "kube-public"]

Feature Description

Enable CONSUL_HTTP_ADDR to be set via the Values file when externalServers are being used.

Use Case(s)

Catalog Sync feature. When it is deployed as the single feature of the helm chart, uses the host_ip:8500 value, but in this case there is no consul HTTP API running on the host.

Contributions

Let me know if this use case is accepted i can make the changes to the sync-catalog-deployment.yaml template.

webmutation avatar Oct 29 '21 09:10 webmutation

I think we'll have to have a separate value for HTTP address for sync catalog:

syncCatalog:
  consulAPIHTTPAddress: ""

Because externalServers.hosts accepts a cloud auto-join string so we can't assume that we can use an element from that array.

lkysow avatar Nov 05 '21 06:11 lkysow

Configuring CONSUL_HTTP_ADDR directly using Helm Values would be very useful for me too! I sync k8s workload with the external Consul cluster. And right now, I have to extract templates from Chart, do some manual changes (using Kustomize), and apply "raw" manifests to the cluster.

gdud avatar Dec 31 '21 12:12 gdud

I've just found out the concept of Post Rendering. It looks doable to change CONSUL_HTTP_ADDR using kustomize before installing the chart to the cluster. I'll let you know if it works for my case. Despite that, configuring that via Values is much more straightforward.

gdud avatar Dec 31 '21 12:12 gdud

Hi @gdud if you have a PR with some tests that run for what was described we'd be happy to take a look. We have not planned any enhancements to Sync Catalog in quite some time.

david-yu avatar Jan 28 '22 20:01 david-yu

Anything new on this? Thanks

psyhomb avatar Feb 27 '22 11:02 psyhomb

@psyhomb I think we're open to community PRs to implement this as per https://github.com/hashicorp/consul-k8s/issues/819#issuecomment-961652426

lkysow avatar Feb 28 '22 17:02 lkysow

Closing as https://github.com/hashicorp/consul-k8s/pull/1659 should address this by leveraging a new component to discover servers and externalServers.hosts will accept a DNS name starting with Consul K8s 1.0.

david-yu avatar Nov 03 '22 08:11 david-yu

Hi @david-yu is there some place we can read what will change for 1.0 ? I understand from the code comments that there are some breaking changes expected that could perhaps help solve some of the issues we faced with the health checks and externalServers being used. In particular it seems that the service registration API has been now unified for all services.

We are currently using a custom component to overcome this and a few other issues we encountered with consul-k8s, perhaps we can re-evaluate using it, if 1.0 will fix most of the issues.

webmutation avatar Nov 03 '22 11:11 webmutation

@webmutation There should be release notes for 1.0 on consul.io which will happen in the latter half of this month roughly. You can also see what's in the changelog to get a sneak peek. As far as health check support for catalog sync that is not supported at the moment. Do you have a PR that can show us how you enabled them?

david-yu avatar Nov 03 '22 16:11 david-yu