nix code
parent
64795aed3d
commit
a7316f04b3
GPG Key ID:
76BF5F1928B9618B
|
|
@ -42,7 +42,7 @@ Lets look what `nix-instantiate` does.
|
|||
|
||||
We create a file `test1.nix`:
|
||||
|
||||
```
|
||||
```nix
|
||||
# file test1.nix
|
||||
rec {
|
||||
i = "like Nix";
|
||||
|
|
@ -52,9 +52,10 @@ rec {
|
|||
|
||||
and than we run `nix-instantiate` to render JSON:
|
||||
|
||||
```
|
||||
```shell
|
||||
$> nix-instantiate --eval --json --strict test1.nix | jq
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"i": "like Nix",
|
||||
"you": "like Nix"
|
||||
|
|
@ -69,7 +70,7 @@ Nice! This is expected because it is an example from
|
|||
Modules are one of the things that make NixOS really awesome.
|
||||
So lets us them in combination with `nix-instantiate`!
|
||||
|
||||
```
|
||||
```nix
|
||||
# file test2.nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
|
|
@ -103,13 +104,13 @@ in
|
|||
|
||||
When running:
|
||||
|
||||
```
|
||||
```shell
|
||||
nix-instantiate --eval --strict --json test2.nix --show-trace | jq
|
||||
```
|
||||
|
||||
We get the following JSON:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"_module": {
|
||||
"args": {},
|
||||
|
|
@ -132,7 +133,7 @@ This is almost what we want to see. the `_module` value is not needed.
|
|||
So let's remove it with a sanitization function, and move the content path
|
||||
to a different file called `config.nix`.
|
||||
|
||||
```
|
||||
```nix
|
||||
# file test3.nix
|
||||
let
|
||||
pkgs = import <nixpkgs> {};
|
||||
|
|
@ -164,7 +165,7 @@ in
|
|||
In `config.nix` we can now focus on the configuration content. And we write it
|
||||
just like we would write a NixOS module.
|
||||
|
||||
```
|
||||
```nix
|
||||
# config.nix
|
||||
{ config, lib, ... }:
|
||||
with lib;
|
||||
|
|
@ -187,13 +188,13 @@ with lib;
|
|||
|
||||
The result of the now well known command
|
||||
|
||||
```
|
||||
```shell
|
||||
nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
```
|
||||
|
||||
looks like the result we want to have:
|
||||
|
||||
```
|
||||
```json
|
||||
{
|
||||
"resource": {
|
||||
"random_pet": {
|
||||
|
|
@ -228,7 +229,7 @@ resource entries to create an
|
|||
But it has one parameter `additionalFileSize`
|
||||
which will automatically add an `hcloud_volume` and an `hcloud_volume_attachment`.
|
||||
|
||||
```
|
||||
```nix
|
||||
# hcloud.nix
|
||||
{ config, lib, ... }:
|
||||
with lib;
|
||||
|
|
@ -307,7 +308,7 @@ in {
|
|||
|
||||
Let's look at the different `config.nix` results.
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
imports = [
|
||||
./core.nix # resource definition
|
||||
|
|
@ -323,8 +324,10 @@ Let's look at the different `config.nix` results.
|
|||
}
|
||||
```
|
||||
|
||||
```
|
||||
```shell
|
||||
$> nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
```
|
||||
```json
|
||||
{
|
||||
"resource": {
|
||||
"hcloud_server": {
|
||||
|
|
@ -344,7 +347,7 @@ The output is like we expected it to be.
|
|||
|
||||
Let's add some `additionalFileSize`.
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
imports = [
|
||||
./core.nix # resource definition
|
||||
|
|
@ -361,8 +364,10 @@ Let's add some `additionalFileSize`.
|
|||
}
|
||||
```
|
||||
|
||||
```
|
||||
```shell
|
||||
$> nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
```
|
||||
```json
|
||||
{
|
||||
"resource": {
|
||||
"hcloud_server": {
|
||||
|
|
@ -410,7 +415,7 @@ all admin keys.
|
|||
|
||||
Let's look at the `config.nix` first.
|
||||
|
||||
```
|
||||
```nix
|
||||
{
|
||||
imports = [
|
||||
./core.nix
|
||||
|
|
@ -443,7 +448,7 @@ The `admins` module will not create any `resource` directly.
|
|||
Instead it defines options which can be set and used by
|
||||
other modules.
|
||||
|
||||
```
|
||||
```nix
|
||||
# admins.nix
|
||||
{ lib, ... }:
|
||||
with lib;
|
||||
|
|
@ -473,7 +478,7 @@ They are accessed via `config.admins`
|
|||
and depending on their content,
|
||||
we create `hcloud_ssh_keys` and add them to the servers.
|
||||
|
||||
```
|
||||
```nix
|
||||
{ config, lib, ... }:
|
||||
with lib;
|
||||
let
|
||||
|
|
@ -571,8 +576,10 @@ Look closely at the end of the `serverResource` definition.
|
|||
|
||||
Let's look at the resulting JSON:
|
||||
|
||||
```
|
||||
```shell
|
||||
$> nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
```
|
||||
```json
|
||||
{
|
||||
"resource": {
|
||||
"hcloud_server": {
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ To find the newest `rev` and `sha256` just call
|
|||
nix-shell -p nix-prefetch-git --run "nix-prefetch-git https://github.com/mrVanDalo/nixos-tinc.git"
|
||||
```
|
||||
|
||||
```
|
||||
```nix
|
||||
{pkgs, ... }:
|
||||
let
|
||||
tincModule = pkgs.fetchgit {
|
||||
|
|
@ -64,13 +64,13 @@ First,
|
|||
we have to create tinc keys for every computer in the VPN Mesh.
|
||||
To put the keys in the current folder we use the `'--config .'` option,
|
||||
|
||||
```
|
||||
```shell
|
||||
$> nix-shell -p tinc_pre --run "tinc --config . generate-keys 4096"
|
||||
```
|
||||
|
||||
After that is done we create the `hostfile` by
|
||||
|
||||
```
|
||||
```shell
|
||||
$> cat *.pub > hostfile ; rm *.pub
|
||||
```
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ First we define the whole topology in `default` and
|
|||
then we `enable` and configure secret-keys
|
||||
for every computer in `Gibson`, `Hackbardt` and `HAL`
|
||||
|
||||
```
|
||||
```nix
|
||||
let
|
||||
|
||||
includePrivateKeys = host: {
|
||||
|
|
@ -199,7 +199,7 @@ If we deploy that and check the servers,
|
|||
we can see that tinc creates interfaces called `tinc.private`.
|
||||
Observing the routes we see that tinc sets up everything which is needed for proper routing.
|
||||
|
||||
```
|
||||
```shell
|
||||
$Gibson> ip addr show dev tinc.private
|
||||
4: tinc.private: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
|
||||
link/ether 3f:ac:bd:c2:f6:9c brd ff:ff:ff:ff:ff:ff
|
||||
|
|
@ -210,7 +210,7 @@ $Gibson> ip addr show dev tinc.private
|
|||
inet6 ffa1::2afc:b2ff:fcf2:f97a/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
```
|
||||
```
|
||||
```shell
|
||||
$Gibson> ip route show dev tinc.private
|
||||
10.1.1.0/24 scope link
|
||||
169.254.0.0/16 proto kernel scope link src 169.254.22.60 metric 204
|
||||
|
|
@ -219,7 +219,7 @@ $Gibson> ip route show dev tinc.private
|
|||
It also creates `/etc/host` entries `<computername>.<networkname>`
|
||||
so you don't have to remember the IPs.
|
||||
|
||||
```
|
||||
```shell
|
||||
$Gibson> ping HAL.private -c 1
|
||||
PING HAL.private (10.1.1.3) 56(84) bytes of data.
|
||||
64 bytes from HAL.private (10.1.1.1): icmp_seq=1 ttl=64 time=5.27 ms
|
||||
|
|
@ -243,7 +243,7 @@ to configure sub-network routing.
|
|||
Achieving this is very simple,
|
||||
just add the `tincSubnet` parameter in the `hosts` attribute and your done.
|
||||
|
||||
```
|
||||
```nix
|
||||
...
|
||||
|
||||
default =
|
||||
|
|
@ -285,7 +285,7 @@ default =
|
|||
After deployment, we can see that `Gibson` has proper routing to the configured `tincSubnet`
|
||||
ranges as well as to `10.1.1.0/24` to reach the other network-nodes.
|
||||
|
||||
```
|
||||
```shell
|
||||
$Gibson> ip route show dev tinc.private
|
||||
10.1.1.0/24 scope link
|
||||
10.2.2.0/24 scope link
|
||||
|
|
@ -296,7 +296,7 @@ $Gibson> ip route show dev tinc.private
|
|||
`Hackbardt` has routing to the network provided by `HAL`,
|
||||
but has no routing (on the `tinc.private` interface) to the network it provides it self.
|
||||
|
||||
```
|
||||
```shell
|
||||
$Hackbardt> ip route show dev tinc.private
|
||||
10.1.1.0/24 scope link
|
||||
10.2.2.0/24 scope link
|
||||
|
|
|
|||
Loading…
Reference in New Issue