IP:Port of one task into another task dynamically

1,891 views
Skip to first unread message

Parveen Kumar

unread,
Apr 5, 2016, 6:13:52 AM4/5/16
to Nomad
Hi Team,

I need the ip:port of one task which i am defining in a job in another task env variable dynamically.

lets say i define one task as postgres where i am degining dynamic port so only when task being allocated to a node and node will run the docker container then only port will be defined. similarly out of n number of client it will run on 1 client. so i need the ip of the client where job ran and port which is dynamically allocated when job ran in another task under same job.

is there any provision???

ex:

        task "postgres" {

            driver = "docker"
            config {
                image = "postgres:9.5"                               
            }

            service {
                name = "postgres"
                tags = ["db"]
                port = "TCP"
            }

            resources {
                cpu = 500 # Mhz
                memory = 256 # MB

                network {
                    mbits = 10

                    # Request for a static port
                    port "TCP" {}
                   
                }   
            }

task "abc" {

            driver = "docker"
            config {
                image = "abc:latest"                               
            }

            service {
                name = "abc"
                tags = ["frontend"]
                port = "http"
            }

           env {
                "URI_End_Point" = "${NOMAD_META_VERSION}"
                "HOST" = "postgres node ip"
                "PORT" = "postgres docker exposed port"
            }

            resources {
                cpu = 500 # Mhz
                memory = 256 # MB

                network {
                    mbits = 10

                    # Request for a static port
                    port "http" {}
                   
                }   
            }
   


Diptanu Choudhury

unread,
Apr 5, 2016, 3:23:30 PM4/5/16
to Parveen Kumar, Nomad
The best way to achieve this is to use a service discovery solution like Consul. Each task can register the services they are exposing to consul, and other services which needs to connect to them can look their addresses by querying consul. Environment variables of a task are not exposed to any other task in an allocation.

Also, it would be nice if you can aggregate all your questions in a single email, it helps us to answer and track questions easily.  

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/nomad/issues
IRC: #nomad-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Nomad" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nomad-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nomad-tool/89b19fd8-aabb-4296-921b-6749e5e1c4b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Thanks,
Diptanu Choudhury

Parveen Kumar

unread,
Apr 5, 2016, 11:15:57 PM4/5/16
to Nomad
Hi Diptanu,

Thanks for the response.
I already had created a topic where i had all the queries in that. but didn't get any response on that so i created seperate topic for different queries.
let's talk about this query. you are suggesting that i should use consul service discovery feature. i am doing it for my current scenario but problem with that i need to write rest call code in my dependent project where i need the  IP:Port of postgres  and i also need to write logic to select from multiple ip:port as well if postgres is deployed on more than 1 node. currently i have written a facade layer where i am getting ip:port by sending servicename and tag as a parameter. in my application , where i used to get the ip:port from environment values now, i am calling the facade layer to get the top in the list ip:port of postgres service. but i don't want to write extra code for getting ip:port in application. instead i want to pass it as an env variable in nomad job. i thought that interpreted variables would help in this. but they were not getting resolved.

i was using ${NOMAD_HOST_PORT_"label"}

in postgres task i defined port map with label tcp
# Configure Docker driver with the image

            config {
                image = "postgres:9.5"
                labels = {
                    group = "db-postgres"
                }
                port_map {
                    tcp = 5432
                }
            }
 and i was giving it to my application in env block using ${NOMAD_HOST_PORT_tcp} but it was not getting resolved.

Parveen Kumar

unread,
Apr 5, 2016, 11:39:17 PM4/5/16
to Nomad
I also used ${NOMAD_ADDR_tcp}

Alex Dadgar

unread,
Apr 7, 2016, 4:40:40 PM4/7/16
to Nomad
Hey,

As Diptanu mentioned what you are looking for is service discovery. If you don't want to make DNS requests or interact directly with the consul API, consul-template and envconsul are other options.

ja...@fpcomplete.com

unread,
May 3, 2016, 4:09:49 AM5/3/16
to Nomad


On Thursday, April 7, 2016 at 4:40:40 PM UTC-4, Alex Dadgar wrote:
Hey,

As Diptanu mentioned what you are looking for is service discovery. If you don't want to make DNS requests or interact directly with the consul API, consul-template and envconsul are other options.


It would be great to see better examples of this in practice. For example, the consul docs inform us how to use DNS to lookup SRV records for a service and retrieve the port nomad allocated, but how would you effectively use this in a nomad job spec? If we have one task that needs the IP/port of another task, and requests that info as either an env var or a command line flag... using DNS works well for the IP, but how would you use the SRV record from consul to provide the port to that task?

The only obvious solution I see right now would be to start the task with a wrapper script that does all the look ups necessary. All of that starts to feel silly when we use consul's service discovery and nomad's task scheduling to simplify running and finding services. The wrapper also seems necessary to ensure a task that is dependent on another doesn't exit before the dependency starts.

Thanks for the recommendations :)

Alex Dadgar

unread,
May 3, 2016, 5:46:57 PM5/3/16
to ja...@fpcomplete.com, Nomad
Hey Jason,

What I was trying to get at is that discovering the IP:Port of the other task is outside of Nomad's purview and is the responsibility of either the task itself or a script/tool like consul-template.

Thanks,
Alex 

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/nomad/issues
IRC: #nomad-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Nomad" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nomad-tool+...@googlegroups.com.

Diptanu Choudhury

unread,
May 3, 2016, 5:48:53 PM5/3/16
to J Boyer, Nomad
Hi Jason,

I would suggest avoiding static lookups of IP:Port of tasks using wrapper scripts during the startup of an application. Nomad being a dynamic cluster scheduler can restart a task when it fails or move the task around if the node dies or is being drained by the operator so I would suggest using the Consul APIs directly to know the address of the task and keep monitoring for any changes in the address by making blocking queries, etc. 

This is a longer topic for discussion, let me know if you have any specific questions.

On Tue, May 3, 2016 at 1:09 AM, <ja...@fpcomplete.com> wrote:

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/nomad/issues
IRC: #nomad-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Nomad" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nomad-tool+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages