# Accessing Nomad's Consul from Applications

**URL:** <https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003>\
**Category:** Nomad\
**Created:** [July 12, 2023, 7:00pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003 "2023-07-12T19:00:13Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 12, 2023, 7:00pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/1 "2023-07-12T19:00:13Z")

</div>

Hi! I’m currently migrating a bunch of internal applications from docker swarm to nomad. Some of these applications use consul for leader election. Currently they use a simple consul instance deployed into the docker swarm.

My question is: Given that nomad already comes with a consul instance, can applications use that instance as well? (“can” as in: is it technically possible _and_ a good idea)

And follow up question if it can be used: How can I dynamically discover it’s address? For nomad services I can use templates to get their address and port, can I do the same for the consul address?

---

<div class="post-metadata">

**Author:** ![matthias](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/matthias/32/44060_2.png) [@matthias](https://discuss.hashicorp.com/u/matthias)\
**Post date:** [July 15, 2023, 9:41pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/2 "2023-07-15T21:41:34Z")

</div>

AFAIK, it is best practice to run a Consul client instance on every Nomad client instance.

Therefore, your application should just query Consul on localhost:8500 and go from there. No need for complex discovery.

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 16, 2023, 11:30pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/3 "2023-07-16T23:30:35Z")

</div>

I assume localhost wouldn’t work from within in tasks with docker driver, would it?

---

<div class="post-metadata">

**Author:** ![matthias](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/matthias/32/44060_2.png) [@matthias](https://discuss.hashicorp.com/u/matthias)\
**Post date:** [July 17, 2023, 12:37am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/4 "2023-07-17T00:37:06Z")

</div>

If you are using the host driver, you should be fine.

For bridge you have to configure your app to use the Consul host at NOMAD\_IP\_xxx, see the network stanza.

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 17, 2023, 8:46am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/5 "2023-07-17T08:46:07Z")

</div>

> [@matthias](#):
>
> NOMAD\_IP\_xxx

I’ve checked the env inside the container and I haven’t seen an entry for consul. Can you elaborate?

---

<div class="post-metadata">

**Author:** ![matthias](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/matthias/32/44060_2.png) [@matthias](https://discuss.hashicorp.com/u/matthias)\
**Post date:** [July 17, 2023, 10:11am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/6 "2023-07-17T10:11:14Z")

</div>

Well, if you define a network port “xxx” in your Nomad job file, Nomad will create an environment variable NOMAD\_IP\_xxx, which contains the external IP of the Nomad host.

As long as Consul is running on the same machine, this is also the IP address of the Consul instance.  
Just add the Consul port and your app should be able to communicate with Consul. Something along the lines of  
{{ env “NOMAD\_IP\_xxx” }}:8500  
when you create to config file for your app via templating.

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 17, 2023, 10:51am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/7 "2023-07-17T10:51:57Z")

</div>

So this would “abuse” that nomad will inject the current node’s IP into the env when exposing services from a task? And this would also only work if it is in host network mode, right? In bridge mode I’d expect the IP to be in the bridge network.

If nomad was deployed as a nomad task itself, than I could use nomad’s service discovery to find the address, but in our deployment that’s not the case.

Given the central role of consul, it’s kinda surprising to not have some easier to way to use it.

---

<div class="post-metadata">

**Author:** ![shantanugadgil](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/shantanugadgil/32/923_2.png) [@shantanugadgil](https://discuss.hashicorp.com/u/shantanugadgil)\
**Post date:** [July 17, 2023, 11:15am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/8 "2023-07-17T11:15:51Z")

</div>

for Docker driver, from inside the container you can use the Docker bridge IP to query, assuming the Consul process has been configured to listen on local interfaces as well.

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 17, 2023, 12:45pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/9 "2023-07-17T12:45:46Z")

</div>

that assumes knowledge of the bridge network, which I don’t want to assume. In that sense I might as well just hardcode the IP of the consul server.

would there be a way for a nomad operator to define “global environment variables”, that are injected into every task? That way I could inject the address of the consul instance into all applications.

---

<div class="post-metadata">

**Author:** ![shantanugadgil](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/shantanugadgil/32/923_2.png) [@shantanugadgil](https://discuss.hashicorp.com/u/shantanugadgil)\
**Post date:** [July 17, 2023, 1:40pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/10 "2023-07-17T13:40:26Z")

</div>

> [@phillip](#):
>
> that assumes knowledge of the bridge network, which I don’t want to assume. In that sense I might as well just hardcode the IP of the consul server.

Ummm, not really … you can use the “docker bridge ip” attribute …  
ref: [Drivers: Docker | Nomad | HashiCorp Developer](https://developer.hashicorp.com/nomad/docs/drivers/docker#driver-docker-bridge_ip)

Example: (HCL2 syntax)

```auto
attr.driver.docker.bridge_ip

```

OR (older HCL1 syntax)

```auto
"${attr.driver.docker.bridge_ip}"

```

For example, in the `env` section of your job you could do:

```hcl
env {
  DB_IP = "${attr.driver.docker.bridge_ip}"
}

```

or to directly use in the `dns_servers` list you can try like this (that syntax works in the latest versions)

> <https://github.com/hashicorp/nomad/issues/12780#issuecomment-1127888805>
>
> \<!--
> Hi there,
> 
> Thank you for opening an issue. Please note that we try to ke…ep the Nomad issue
> tracker reserved for bug reports and feature requests. For general usage
> questions, please see: https://www.nomadproject.io/community
> 
> \--\>
> 
> \### Nomad version
> Output from \`nomad version\`
> Nomad v1.3.0-beta.1 (2eba643965c461e401fe4a3e9442fd30104a9344)
> 
> \### Operating system and Environment details
> Linux (Tested on Debian Bullseye on ChromeOS and also Amazon Linux 2 in AWS)
> \### Issue
> https://github.com/hashicorp/nomad/pull/12021 does not appear to actually work. Looking at the PR it appears that the interpolated DNS values are never used
> EDIT: network dns variable interpolation works when placed within the config stanza, but not within the group.network stanza
> \### Reproduction steps
> nomad job run example.nomad (the modified version below)
> exec into the container
> cat /etc/resolv.conf
> No variable interpolation takes place, the variable is just interpretted literally
> 
> \#### Expected Result
> \`\`\`
> \# cat /etc/resolv.conf
> search lxd
> nameserver 100.115.92.202 # This should be a local private ip that nomad is bound to.
> \`\`\`
> \#### Actual Result
> \`\`\`
> \# cat /etc/resolv.conf
> search lxd
> nameserver ${attr.unique.network.ip-address}
> \`\`\`
> Instead I just get the variable interpreted as a literal. 
> \### Job file (if appropriate)
> Using a slightly modified version of example.nomad, the differences being
> network.dns.servers = \["${attr.unique.network.ip-address}"\]
> and network\_mode = "bridge"
> 
> \`\`\`
> locals {
> dns\_servers = \["${attr.unique.network.ip-address}"\]
> }
> \# There can only be a single job definition per file. This job is named
> \# "example" so it will create a job with the ID and Name "example".
> 
> \# The "job" stanza is the top-most configuration option in the job
> \# specification. A job is a declarative specification of tasks that Nomad
> \# should run. Jobs have a globally unique name, one or many task groups, which
> \# are themselves collections of one or many tasks.
> \#
> \# For more information and examples on the "job" stanza, please see
> \# the online documentation at:
> \#
> \# https://www.nomadproject.io/docs/job-specification/job
> \#
> job "example" {
> # The "region" parameter specifies the region in which to execute the job.
> # If omitted, this inherits the default region name of "global".
> # region = "global"
> #
> # The "datacenters" parameter specifies the list of datacenters which should
> # be considered when placing this task. This must be provided.
> datacenters = \["dc1"\]
> 
> # The "type" parameter controls the type of job, which impacts the scheduler's
> # decision on placement. This configuration is optional and defaults to
> # "service". For a full list of job types and their differences, please see
> # the online documentation.
> #
> # For more information, please see the online documentation at:
> #
> # https://www.nomadproject.io/docs/schedulers
> #
> type = "service"
> 
> # The "constraint" stanza defines additional constraints for placing this job,
> # in addition to any resource or driver constraints. This stanza may be placed
> # at the "job", "group", or "task" level, and supports variable interpolation.
> #
> # For more information and examples on the "constraint" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/constraint
> #
> # constraint {
> # attribute = "${attr.kernel.name}"
> # value = "linux"
> # }
> 
> # The "update" stanza specifies the update strategy of task groups. The update
> # strategy is used to control things like rolling upgrades, canaries, and
> # blue/green deployments. If omitted, no update strategy is enforced. The
> # "update" stanza may be placed at the job or task group. When placed at the
> # job, it applies to all groups within the job. When placed at both the job and
> # group level, the stanzas are merged with the group's taking precedence.
> #
> # For more information and examples on the "update" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/update
> #
> update {
> # The "max\_parallel" parameter specifies the maximum number of updates to
> # perform in parallel. In this case, this specifies to update a single task
> # at a time.
> max\_parallel = 1
> 
> # The "min\_healthy\_time" parameter specifies the minimum time the allocation
> # must be in the healthy state before it is marked as healthy and unblocks
> # further allocations from being updated.
> min\_healthy\_time = "10s"
> 
> # The "healthy\_deadline" parameter specifies the deadline in which the
> # allocation must be marked as healthy after which the allocation is
> # automatically transitioned to unhealthy. Transitioning to unhealthy will
> # fail the deployment and potentially roll back the job if "auto\_revert" is
> # set to true.
> healthy\_deadline = "3m"
> 
> # The "progress\_deadline" parameter specifies the deadline in which an
> # allocation must be marked as healthy. The deadline begins when the first
> # allocation for the deployment is created and is reset whenever an allocation
> # as part of the deployment transitions to a healthy state. If no allocation
> # transitions to the healthy state before the progress deadline, the
> # deployment is marked as failed.
> progress\_deadline = "10m"
> 
> # The "auto\_revert" parameter specifies if the job should auto-revert to the
> # last stable job on deployment failure. A job is marked as stable if all the
> # allocations as part of its deployment were marked healthy.
> auto\_revert = false
> 
> # The "canary" parameter specifies that changes to the job that would result
> # in destructive updates should create the specified number of canaries
> # without stopping any previous allocations. Once the operator determines the
> # canaries are healthy, they can be promoted which unblocks a rolling update
> # of the remaining allocations at a rate of "max\_parallel".
> #
> # Further, setting "canary" equal to the count of the task group allows
> # blue/green deployments. When the job is updated, a full set of the new
> # version is deployed and upon promotion the old version is stopped.
> canary = 0
> }
> # The migrate stanza specifies the group's strategy for migrating off of
> # draining nodes. If omitted, a default migration strategy is applied.
> #
> # For more information on the "migrate" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/migrate
> #
> migrate {
> # Specifies the number of task groups that can be migrated at the same
> # time. This number must be less than the total count for the group as
> # (count - max\_parallel) will be left running during migrations.
> max\_parallel = 1
> 
> # Specifies the mechanism in which allocations health is determined. The
> # potential values are "checks" or "task\_states".
> health\_check = "checks"
> 
> # Specifies the minimum time the allocation must be in the healthy state
> # before it is marked as healthy and unblocks further allocations from being
> # migrated. This is specified using a label suffix like "30s" or "15m".
> min\_healthy\_time = "10s"
> 
> # Specifies the deadline in which the allocation must be marked as healthy
> # after which the allocation is automatically transitioned to unhealthy. This
> # is specified using a label suffix like "2m" or "1h".
> healthy\_deadline = "5m"
> }
> # The "group" stanza defines a series of tasks that should be co-located on
> # the same Nomad client. Any task within a group will be placed on the same
> # client.
> #
> # For more information and examples on the "group" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/group
> #
> group "cache" {
> # The "count" parameter specifies the number of the task groups that should
> # be running under this group. This value must be non-negative and defaults
> # to 1.
> count = 1
> 
> # The "network" stanza specifies the network configuration for the allocation
> # including requesting port bindings.
> #
> # For more information and examples on the "network" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/network
> #
> network {
> mode = "bridge"
> port "db" {
> to = 6379
> }
> dns {
> servers = local.dns\_servers
> }
> }
> 
> # The "service" stanza instructs Nomad to register this task as a service
> # in the service discovery engine, which is currently Consul. This will
> # make the service addressable after Nomad has placed it on a host and
> # port.
> #
> # For more information and examples on the "service" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/service
> #
> service {
> name = "redis-cache"
> tags = \["global", "cache"\]
> port = "db"
> 
> # The "check" stanza instructs Nomad to create a Consul health check for
> # this service. A sample check is provided here for your convenience;
> # uncomment it to enable it. The "check" stanza is documented in the
> # "service" stanza documentation.
> 
> # check {
> # name = "alive"
> # type = "tcp"
> # interval = "10s"
> # timeout = "2s"
> # }
> 
> }
> 
> # The "restart" stanza configures a group's behavior on task failure. If
> # left unspecified, a default restart policy is used based on the job type.
> #
> # For more information and examples on the "restart" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/restart
> #
> restart {
> # The number of attempts to run the job within the specified interval.
> attempts = 2
> interval = "30m"
> 
> # The "delay" parameter specifies the duration to wait before restarting
> # a task after it has failed.
> delay = "15s"
> 
> # The "mode" parameter controls what happens when a task has restarted
> # "attempts" times within the interval. "delay" mode delays the next
> # restart until the next interval. "fail" mode does not restart the task
> # if "attempts" has been hit within the interval.
> mode = "fail"
> }
> 
> # The "ephemeral\_disk" stanza instructs Nomad to utilize an ephemeral disk
> # instead of a hard disk requirement. Clients using this stanza should
> # not specify disk requirements in the resources stanza of the task. All
> # tasks in this group will share the same ephemeral disk.
> #
> # For more information and examples on the "ephemeral\_disk" stanza, please
> # see the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/ephemeral\_disk
> #
> ephemeral\_disk {
> # When sticky is true and the task group is updated, the scheduler
> # will prefer to place the updated allocation on the same node and
> # will migrate the data. This is useful for tasks that store data
> # that should persist across allocation updates.
> # sticky = true
> #
> # Setting migrate to true results in the allocation directory of a
> # sticky allocation directory to be migrated.
> # migrate = true
> #
> # The "size" parameter specifies the size in MB of shared ephemeral disk
> # between tasks in the group.
> size = 300
> }
> 
> # The "affinity" stanza enables operators to express placement preferences
> # based on node attributes or metadata.
> #
> # For more information and examples on the "affinity" stanza, please
> # see the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/affinity
> #
> # affinity {
> # attribute specifies the name of a node attribute or metadata
> # attribute = "${node.datacenter}"
> 
> 
> # value specifies the desired attribute value. In this example Nomad
> # will prefer placement in the "us-west1" datacenter.
> # value = "us-west1"
> 
> 
> # weight can be used to indicate relative preference
> # when the job has more than one affinity. It defaults to 50 if not set.
> # weight = 100
> # }
> 
> 
> # The "spread" stanza allows operators to increase the failure tolerance of
> # their applications by specifying a node attribute that allocations
> # should be spread over.
> #
> # For more information and examples on the "spread" stanza, please
> # see the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/spread
> #
> # spread {
> # attribute specifies the name of a node attribute or metadata
> # attribute = "${node.datacenter}"
> 
> 
> # targets can be used to define desired percentages of allocations
> # for each targeted attribute value.
> #
> # target "us-east1" {
> # percent = 60
> # }
> # target "us-west1" {
> # percent = 40
> # }
> # }
> 
> # The "task" stanza creates an individual unit of work, such as a Docker
> # container, web application, or batch processing.
> #
> # For more information and examples on the "task" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/task
> #
> task "redis" {
> # The "driver" parameter specifies the task driver that should be used to
> # run the task.
> driver = "docker"
> 
> # The "config" stanza specifies the driver configuration, which is passed
> # directly to the driver to start the task. The details of configurations
> # are specific to each driver, so please see specific driver
> # documentation for more information.
> config {
> image = "redis:3.2"
> 
> ports = \["db"\]
> }
> 
> # The "artifact" stanza instructs Nomad to download an artifact from a
> # remote source prior to starting the task. This provides a convenient
> # mechanism for downloading configuration files or data needed to run the
> # task. It is possible to specify the "artifact" stanza multiple times to
> # download multiple artifacts.
> #
> # For more information and examples on the "artifact" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/artifact
> #
> # artifact {
> # source = "http://foo.com/artifact.tar.gz"
> # options {
> # checksum = "md5:c4aa853ad2215426eb7d70a21922e794"
> # }
> # }
> 
> 
> # The "logs" stanza instructs the Nomad client on how many log files and
> # the maximum size of those logs files to retain. Logging is enabled by
> # default, but the "logs" stanza allows for finer-grained control over
> # the log rotation and storage configuration.
> #
> # For more information and examples on the "logs" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/logs
> #
> # logs {
> # max\_files = 10
> # max\_file\_size = 15
> # }
> 
> # The "resources" stanza describes the requirements a task needs to
> # execute. Resource requirements include memory, cpu, and more.
> # This ensures the task will execute on a machine that contains enough
> # resource capacity.
> #
> # For more information and examples on the "resources" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/resources
> #
> resources {
> cpu = 500 # 500 MHz
> memory = 256 # 256MB
> }
> 
> 
> # The "template" stanza instructs Nomad to manage a template, such as
> # a configuration file or script. This template can optionally pull data
> # from Consul or Vault to populate runtime configuration data.
> #
> # For more information and examples on the "template" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/template
> #
> # template {
> # data = "---\\nkey: {{ key \\"service/my-key\\" }}"
> # destination = "local/file.yml"
> # change\_mode = "signal"
> # change\_signal = "SIGHUP"
> # }
> 
> # The "template" stanza can also be used to create environment variables
> # for tasks that prefer those to config files. The task will be restarted
> # when data pulled from Consul or Vault changes.
> #
> # template {
> # data = "KEY={{ key \\"service/my-key\\" }}"
> # destination = "local/file.env"
> # env = true
> # }
> 
> # The "vault" stanza instructs the Nomad client to acquire a token from
> # a HashiCorp Vault server. The Nomad servers must be configured and
> # authorized to communicate with Vault. By default, Nomad will inject
> # The token into the job via an environment variable and make the token
> # available to the "template" stanza. The Nomad client handles the renewal
> # and revocation of the Vault token.
> #
> # For more information and examples on the "vault" stanza, please see
> # the online documentation at:
> #
> # https://www.nomadproject.io/docs/job-specification/vault
> #
> # vault {
> # policies = \["cdn", "frontend"\]
> # change\_mode = "signal"
> # change\_signal = "SIGHUP"
> # }
> 
> # Controls the timeout between signalling a task it will be killed
> # and killing the task. If not set a default is used.
> # kill\_timeout = "20s"
> }
> }
> }
> 
> \`\`\`
> \<!--
> If possible please post relevant logs in the issue.
> \`
> Logs and other artifacts may also be sent to: nomad-oss-debug@hashicorp.com
> 
> Please link to your Github issue in the email and reference it in the subject
> line:
> 
> \> To: nomad-oss-debug@hashicorp.com
> \>
> \> Subject: GH-1234: Errors garbage collecting allocs
> 
> Emails sent to that address are readable by all HashiCorp employees but are
> \*not\* publicly visible.
> \--\>
> 
> \### Nomad Server logs (if appropriate)
> 
> \### Nomad Client logs (if appropriate)

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 17, 2023, 2:41pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/11 "2023-07-17T14:41:18Z")

</div>

That at least seems like a viable solution. Are all the available attributes documented somewhere?

---

<div class="post-metadata">

**Author:** ![shantanugadgil](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/shantanugadgil/32/923_2.png) [@shantanugadgil](https://discuss.hashicorp.com/u/shantanugadgil)\
**Post date:** [July 18, 2023, 11:27am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/12 "2023-07-18T11:27:59Z")

</div>

In my opinion this would be a starting point:

> **[Variable Interpolation | Nomad | HashiCorp Developer](https://developer.hashicorp.com/nomad/docs/runtime/interpolation)**
>
> Learn about the Nomad's interpolation and interpreted variables.

_a bunch of links are present in the opening paragraph._

the driver specific require a bit of discovery … example: [Task Drivers | Nomad | HashiCorp Developer](https://developer.hashicorp.com/nomad/docs/drivers)

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 21, 2023, 4:59pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/13 "2023-07-21T16:59:41Z")

</div>

I just realized that consul registeres itself as the service `consul`, so something like this should just work:

```plaintext
template {
  data = <<EOH
{{ range service "consul" }}
CONSUL_ADDRESS=http://{{ .Address }}:{{ .Port }}
{{ end }}
EOH
  destination = "consul.env"
  env = true
}

```

---

<div class="post-metadata">

**Author:** ![shantanugadgil](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/shantanugadgil/32/923_2.png) [@shantanugadgil](https://discuss.hashicorp.com/u/shantanugadgil)\
**Post date:** [July 26, 2023, 12:54pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/14 "2023-07-26T12:54:41Z")

</div>

When there are more than 1 Consul servers, this would expand to multiple lines, right?

Using some Go template magic, you may want to use only the first one, I think

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 26, 2023, 1:47pm UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/15 "2023-07-26T13:47:31Z")

</div>

I assume, since env vars must be unique, that consul would do some decision on which of the values to actually use, if the variable shows up multiple times. I guess the better (more robust) way would probably be to use Consul Connect’s service mesh stuff.

---

<div class="post-metadata">

**Author:** ![phillip](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/phillip/32/36764_2.png) [@phillip](https://discuss.hashicorp.com/u/phillip)\
**Post date:** [July 31, 2023, 9:05am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/16 "2023-07-31T09:05:33Z")

</div>

I realized that the “consul” service is not for agents and weirdly the “consul-agent” service we had only contained a small subset of the available agents.

Even though I think it’s not a good assumption to make, I now do what @matthias suggested here: [Accessing Nomad's Consul from Applications - #6 by matthias](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/6).  
I guess it’s at least a common deployment scheme to have nomad and consul agents colocated.

---

<div class="post-metadata">

**Author:** ![matthias](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/matthias/32/44060_2.png) [@matthias](https://discuss.hashicorp.com/u/matthias)\
**Post date:** [July 31, 2023, 10:50am UTC](https://discuss.hashicorp.com/t/accessing-nomads-consul-from-applications/56003/17 "2023-07-31T10:50:49Z")

</div>

IIRC, running Nomad and Consul client on the same instance is considered Best Practice by Hashicorp. Pretty sure that I read that somewhere.

And it actually makes sense. I’m currently in the process of building a Node Red plugin which registers a Watch on Consul and runs flows based on topology changes.  
In my case, a change to the Traefik service should reconfigure the internet HTTP(S) forward on my Unifi router via REST to point to the new location of the Traefik instance.

Connecting the plugin to Consul becomes so much easier if you can just assume that Consul is running on the same machine on a well-known port.