forked from Deuxfleurs/diplonat
diplonat helps you exposing your public services in a dynamic environment
ae9550ce23
the future ACME parameters. Tests written and passing. WIP: added envy dependncy and ConfigOpts structs that will constitute Diplonat's configuration WIP: ConfigOpts from_env() and validate() methods written. No API change (the env names remain unchanged)! Now need to use our new ConfigOpts struct instead of Environment, and update references to the environment variables in the code. WIP: RuntimeConfig with business logic done. Tests written, but they are all running from the same process - setting environment variables in each test produces incoherent results. Another solution for testing is needed. WIP: tests are fully written using 'from_iter' and all passing |
||
|---|---|---|
| src | ||
| .dockerignore | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| README.md | ||
Diplonat
Feature set
- (Re)Configure NAT via UPNP/IGD (prio: high)
- (Re)Configure iptables (prio: low)
- (Re)Configure DNS via ??? (prio: low)
Understand scope
- Reconfigure local environment when provisionning a cluster service
- Reconfigure host on demand according to service needs (Firewall)
- Reconfigure host local network according to service needs (Router NAT)
- Operate a global reconfiguration that associate the tuple (local environment information, a cluster service)
- Reconfigure an external service with local info (DNS with public IP returned by the router via IGD)
Operate
You need to add the following to your nomad config file :
client {
[...]
options {
docker.privileged.enabled = "true"
}
}
cargo build
consul agent -dev # in a separate terminal
# adapt following values to your configuration
export DIPLONAT_PRIVATE_IP="192.168.0.18"
export DIPLONAT_REFRESH_TIME="60"
export DIPLONAT_EXPIRATION_TIME="300"
export DIPLONAT_CONSUL_NODE_NAME="lheureduthe"
export RUST_LOG=debug
cargo run
Design Guidelines
Diplonat is made of a set of Components. Components communicate between them thanks to tokio::sync::watch transferring copiable messages. Each message must contain the whole state (and not a transition) as messages can be lost if a more recent message is received. This choice has been made to limit bugs. If you need to watch two actors and merge their content, you may use tokio::sync::select. When you read a value from source 1, you must cache it to be able to merge it later when you read from source 2.
About Consul Catalog
- We query the
/v1/catalog/node/<node>endpoint - We can watch it thanks to Blocking Queries
eg:
curl -vvv http://127.0.0.1:8500/v1/catalog/node/lheureduthe
# returns X-Consul-Index: 15
curl -vvv http://127.0.0.1:8500/v1/catalog/node/lheureduthe?index=15
Each time you do the request, the whole list of services bound to the node is returned.
To test the Consul Catalog part, you can do:
consul agent -dev #in a separate terminal, if not already running
consul services register -name=fake_leet -tag="(diplonat (tcp_port 1337) (tcp_port 1338 1339))"
consul services register -name=fake_dns -tag="(diplonat (udp_port 53) (tcp_port 53))"
consul services register -name=fake_irc -tag="(diplonat (udp_port 6667 6666))"
consul services -id=example