41 lines
1.5 KiB
Markdown
41 lines
1.5 KiB
Markdown
# Overview
|
|
|
|
So we have some machines(we call those "nodes")
|
|
and each of those nodes runs (1) a nomad client; and (2) a consul client.
|
|
Also, all these nodes are in a wireguard network.
|
|
|
|
nomad is responsible for actually deploying the servers on an available machine.
|
|
actually the Nomad *Server* has state and knows what all clients are doing,
|
|
while Nomad *Clients* are just doing what the server tells them to, like deploying
|
|
a job.
|
|
|
|
A job is just a docker container, or the smallest deployable unit ig.
|
|
|
|
the same server-client-relationship exists with consul. Here, Consul's main
|
|
purpose is to resolve hosts. A job registers itself (via a Consul Client) like
|
|
"hey im a postgres server and i run on 10.0.2.1:5432" and then the Consul Master
|
|
updates its catalogue: "oh so postgres is 10.0.2.1:5432" and then in our jobs, we
|
|
can just use "postgres.service.consul" and it resolves to 10.0.2.1:5432 so thats cool.
|
|
|
|
Now wireguard is needed because while consul resolves hostnames, it doesn't help
|
|
us connect to the resolved IPs. With a single node, that's fine but if we want to
|
|
access a service on another node, we need wireguard(or something similar).
|
|
Actually if we run all nodes in the same network and it'd be fine without.
|
|
|
|
|
|
|
|
## Most Basic Implementation
|
|
|
|
- single node
|
|
- runs `nomad agent -dev` and `consul agent -dev`
|
|
- /etc/nomad.d/consul.hcl:
|
|
consul {
|
|
address = "127.0.0.1:8500"
|
|
}
|
|
- all jobs define a consul service
|
|
|
|
|
|
## useful commands
|
|
|
|
- `nomad job run <job>.hcl`
|
|
- `consul catalog services` <- list registered services
|