fixed code blocks
parent
d1dc0f1ce4
commit
6926d53c47
GPG Key ID:
76BF5F1928B9618B
|
|
@ -7,6 +7,9 @@ params:
|
|||
- nixos
|
||||
|
||||
markup:
|
||||
tableOfContents:
|
||||
endLevel: 6
|
||||
startLevel: 2
|
||||
goldmark:
|
||||
renderer:
|
||||
unsafe: true
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ If you're looking for a good document on how to use
|
|||
have a look at
|
||||
[this excellent article](https://blog.wearewizards.io/how-to-use-nixops-in-a-team).
|
||||
|
||||
# krops vs. NixOps (Feature Comparison)
|
||||
## krops vs. NixOps (Feature Comparison)
|
||||
|
||||
<table class="comparison">
|
||||
<thead>
|
||||
|
|
@ -100,14 +100,14 @@ have a look at
|
|||
</tbody>
|
||||
</table>
|
||||
|
||||
# krops Structure by Example
|
||||
## krops Structure by Example
|
||||
|
||||
krops is not an executable like NixOps,
|
||||
it is a library you use to write executables which do the actual deployment.
|
||||
|
||||
Let's say you have a very simple `configuration.nix`
|
||||
|
||||
```nix
|
||||
```
|
||||
{ pkgs, ... }:
|
||||
{
|
||||
environment.systemPackages = [ pkgs.git ];
|
||||
|
|
@ -117,7 +117,7 @@ Let's say you have a very simple `configuration.nix`
|
|||
Than you can use the following script (let's name it `krops.nix`) to deploy it
|
||||
on the machine `server01.mydomain.org`.
|
||||
|
||||
```nix
|
||||
```
|
||||
let
|
||||
krops = builtins.fetchGit {
|
||||
url = "https://cgit.krebsco.de/krops/";
|
||||
|
|
@ -145,7 +145,7 @@ in {
|
|||
|
||||
Now you can deploy the machine by running:
|
||||
|
||||
```shell
|
||||
```
|
||||
$> nix-build ./krops.nix -A server01 && ./result
|
||||
```
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ and `git` is installed on `server01.mydomain.org`.
|
|||
|
||||
If you run this command the first time you will most likely get a message like
|
||||
|
||||
```output
|
||||
```
|
||||
error: missing sentinel file: server01.mydomain.org:/var/src/.populate
|
||||
```
|
||||
|
||||
|
|
@ -170,11 +170,11 @@ and will clone `nixpkgs` into `/var/src/nixpkgs`.
|
|||
After that, krops will run `nixos-rebuild switch -I /var/src` which will provision
|
||||
`server01`.
|
||||
|
||||
## The Different Parts Explained
|
||||
### The Different Parts Explained
|
||||
|
||||
Let's start with the cryptic part at the beginning.
|
||||
|
||||
```nix
|
||||
```
|
||||
let
|
||||
krops = builtins.fetchGit {
|
||||
url = "https://cgit.krebsco.de/krops/";
|
||||
|
|
@ -186,7 +186,7 @@ let
|
|||
It downloads krops and makes its library and packages available
|
||||
so they can be used it in the following script.
|
||||
|
||||
```nix
|
||||
```
|
||||
in {
|
||||
server01 = pkgs.krops.writeDeploy "deploy-server01" {
|
||||
source = source;
|
||||
|
|
@ -211,7 +211,7 @@ to change the ssh port and the target folder it should be copied.
|
|||
|
||||
{{% /note %}}
|
||||
|
||||
```nix
|
||||
```
|
||||
source = lib.evalSource [
|
||||
{
|
||||
nixpkgs.git = {
|
||||
|
|
@ -229,15 +229,15 @@ The keys in will be the names of the folders or files in `/var/src`.
|
|||
|
||||
All other files/folders must be referenced in the resulting `nixos-config` file.
|
||||
|
||||
## Different Sources
|
||||
### Different Sources
|
||||
|
||||
### Files and Folders
|
||||
#### Files and Folders
|
||||
|
||||
You can use the `file` attribute to transfer
|
||||
files and folders from the build host to the target host.
|
||||
But it always must be an absolute path.
|
||||
|
||||
```nix
|
||||
```
|
||||
source = lib.evalSource [
|
||||
{
|
||||
modules.file = toString ./modules; # toString generates an absoulte path
|
||||
|
|
@ -247,12 +247,12 @@ source = lib.evalSource [
|
|||
|
||||
This copies `./modules` to `/var/src/modules`.
|
||||
|
||||
### Symlinks
|
||||
#### Symlinks
|
||||
|
||||
You can also use the `symlink` argument
|
||||
to create symlinks on the target system.
|
||||
|
||||
```nix
|
||||
```
|
||||
source = lib.evalSource [
|
||||
{
|
||||
config.file = toString ./config;
|
||||
|
|
@ -268,13 +268,13 @@ This copies `./config` to `/var/src/config` and creates a symlink
|
|||
krops will not check if the target is valid.
|
||||
{{% /note %}}
|
||||
|
||||
### Git Repositories
|
||||
#### Git Repositories
|
||||
|
||||
You can pull Git repositories using the `git` attribute
|
||||
from everywhere you want,
|
||||
as long as the target host is able to pull it.
|
||||
|
||||
```nix
|
||||
```
|
||||
source = lib.evalSource [
|
||||
{
|
||||
nix-writers.git = {
|
||||
|
|
@ -291,12 +291,12 @@ to `/var/src/nix-writers`.
|
|||
|
||||
the `ref` parameter also accepts branches or tags.
|
||||
|
||||
### Password Store (Native File Encryption)
|
||||
#### Password Store (Native File Encryption)
|
||||
|
||||
lets assume `secrets` is a folder managed by
|
||||
[passwordstore](https://www.passwordstore.org/).
|
||||
|
||||
```nix
|
||||
```
|
||||
secrets
|
||||
|-- server01
|
||||
| `-- wpa_supplicant.conf.gpg
|
||||
|
|
@ -307,7 +307,7 @@ secrets
|
|||
Use the `pass` argument to include the sub-folder `server01`
|
||||
into your deployment.
|
||||
|
||||
```nix
|
||||
```
|
||||
source = lib.evalSource [
|
||||
{
|
||||
secrets.pass = {
|
||||
|
|
@ -326,12 +326,12 @@ You will be prompted to enter the password.
|
|||
The files in `/var/src/secrets` will be unencrypted!
|
||||
{{% /note %}}
|
||||
|
||||
## How to use Sources in configuration.nix
|
||||
### How to use Sources in configuration.nix
|
||||
|
||||
You can use folders copied by krops
|
||||
very pleasantly in the `configuration.nix`.
|
||||
|
||||
```nix
|
||||
```
|
||||
{ config, libs, pkgs, ... }:
|
||||
{
|
||||
imports = [
|
||||
|
|
@ -342,22 +342,22 @@ very pleasantly in the `configuration.nix`.
|
|||
}
|
||||
```
|
||||
|
||||
## How to Manually Rebuild the System
|
||||
### How to Manually Rebuild the System
|
||||
|
||||
If you, for some reason, want to rebuild the system on the host itself,
|
||||
you can do that simply by running as root
|
||||
|
||||
```shell
|
||||
```
|
||||
#> nixos-rebuild switch -I /var/src
|
||||
```
|
||||
|
||||
# Some Tips
|
||||
## Some Tips
|
||||
|
||||
So far this is everything krops does.
|
||||
It is simple and very close to the usual way Nix and NixOS works.
|
||||
Let's look on some common pattern to solve some common issues.
|
||||
|
||||
## Multiple Server
|
||||
### Multiple Server
|
||||
|
||||
If you want to manage multiple computers,
|
||||
the following adjustments might help you.
|
||||
|
|
@ -365,7 +365,7 @@ the following adjustments might help you.
|
|||
Take a closer look to the `source` function and the parameter
|
||||
`nixos-config` and `secrets`.
|
||||
|
||||
```nix
|
||||
```
|
||||
let
|
||||
source = name: lib.evalSource [
|
||||
{
|
||||
|
|
@ -405,20 +405,20 @@ in {
|
|||
Now you can create multiple `./result`s or you can use the
|
||||
`-A` parameter of nix-build to choose what `./result` will be.
|
||||
|
||||
```shell
|
||||
```
|
||||
$> nix-build ./krops.nix -A server01 && ./result
|
||||
$> nix-build ./krops.nix -A server02 && ./result
|
||||
$> nix-build ./krops.nix -A all && ./result
|
||||
```
|
||||
|
||||
## Update and Fixing Git Commits
|
||||
### Update and Fixing Git Commits
|
||||
|
||||
Updating hashes for Git repositories is annoying and using branches
|
||||
might break consistency.
|
||||
To avoid editing files you can use the `nix-prefetch-git`
|
||||
and `lib.importJson` to make your live easier.
|
||||
|
||||
```shell
|
||||
```
|
||||
$> nix-prefetch-git \
|
||||
--url https://github.com/NixOS/nixpkgs-channels \
|
||||
--rev refs/heads/nixos-18.03 \
|
||||
|
|
@ -427,7 +427,7 @@ $> nix-prefetch-git \
|
|||
|
||||
results in a file `nixpkgs.json` which looks like this
|
||||
|
||||
```json
|
||||
```
|
||||
{
|
||||
"url": "https://github.com/NixOS/nixpkgs-channels.git",
|
||||
"rev": "9cbc7363543ebeb5a0182aa171f23bb19332b99f",
|
||||
|
|
@ -439,7 +439,7 @@ results in a file `nixpkgs.json` which looks like this
|
|||
|
||||
And it can be imported in `./krops.nix` like this.
|
||||
|
||||
```nix
|
||||
```
|
||||
let
|
||||
importJson = (import <nixpkgs> {}).lib.importJSON;
|
||||
source = lib.evalSource [
|
||||
|
|
@ -457,13 +457,13 @@ and the commit reference will be updated, and is fixed.
|
|||
|
||||
This should also make it simpler to maintain different channels on different machines.
|
||||
|
||||
## Use Packages from other channels
|
||||
### Use Packages from other channels
|
||||
|
||||
It is very easy to install packages from different channels.
|
||||
|
||||
For example add `nixpkgs-unstable` the same way you add `nixpkgs`.
|
||||
|
||||
```nix
|
||||
```
|
||||
source = lib.evalSource [
|
||||
{
|
||||
nixpkgs.git = {
|
||||
|
|
@ -482,7 +482,7 @@ For example add `nixpkgs-unstable` the same way you add `nixpkgs`.
|
|||
To install a package from the `unstable` channel you just have to import the channel
|
||||
and call the packages from there.
|
||||
|
||||
```nix
|
||||
```
|
||||
{ config, pkgs, ... }:
|
||||
let
|
||||
unstable = import <nixpkgs-unstable> {};
|
||||
|
|
@ -499,7 +499,7 @@ in {
|
|||
}
|
||||
```
|
||||
|
||||
## Channels and NIX_PATH
|
||||
### Channels and NIX_PATH
|
||||
|
||||
You might wonder how `nix-shell` is catching up with the
|
||||
`nixpkgs` in `/var/src`.
|
||||
|
|
@ -511,7 +511,7 @@ which you have to maintain on top of using krops.
|
|||
If you don't like to do that (like me) you have to change
|
||||
the `NIX_PATH` variable system-wide.
|
||||
|
||||
```nix
|
||||
```
|
||||
environment.variables.NIX_PATH = lib.mkForce "/var/src";
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ summary: >
|
|||
How to setup your projects using lsp, emacs (or your favorite editor), direnv and nix-shell.
|
||||
---
|
||||
|
||||
# Setup
|
||||
## Setup
|
||||
|
||||
In this article we are discussing a concrete setup with concrete tools and a concrete language.
|
||||
But the solutions described here, are intended to help you with your set up.
|
||||
|
|
@ -20,7 +20,7 @@ Here are the Tools used.
|
|||
* [lsp-haskell.el](https://github.com/emacs-lsp/lsp-haskell) : the emacs plugin to interact with the haskell-ide-engine.
|
||||
* [nix-shell](https://nixos.wiki/wiki/Development_environment_with_nix-shell) : because all projects should have one.
|
||||
|
||||
## Goal
|
||||
### Goal
|
||||
|
||||
* Configure Spacemacs as much as possible via `configuration.nix`, without the `lsp-server` being configured by the `configuration.nix`.
|
||||
* The `lsp-server` setup should be fully defined inside the `shell.nix` of the project I'm working on.
|
||||
|
|
@ -28,7 +28,7 @@ Here are the Tools used.
|
|||
This way project specific tweaks are stored in the place where it belongs,
|
||||
and other people can use their favorite IDE with the same setup.
|
||||
|
||||
# Configure Spacemacs
|
||||
## Configure Spacemacs
|
||||
|
||||
Spacemacs is basically an `~/.emacs.d` folder and a mutable file `~/.spacemacs`.
|
||||
I tried to configure `~/.spacemacs` via [home-manager](https://github.com/rycee/home-manager)
|
||||
|
|
@ -39,7 +39,7 @@ to configure files in `~/.spacemacs.d/` and `load` them in
|
|||
the configuration functions inside `~/.spacemacs`. A simple `(load "~/.spacemacs.d/hook-user-config.el")`
|
||||
inside the `dotspacemacs/user-config` function is enough, to make it work.
|
||||
|
||||
```nix
|
||||
```
|
||||
{ pkgs, lib, config, ... }:
|
||||
let
|
||||
|
||||
|
|
@ -144,12 +144,12 @@ But we did not install `lsp`.
|
|||
In my setups the `lsp-server` is installed by the project file (lsp.nix), and is loaded via `direnv` (`direnv-update-environment` in emacs).
|
||||
If you don't like that just use the snippet from the next section.
|
||||
|
||||
## Alternative Configuration (install lsp in the configuration.nix)
|
||||
### Alternative Configuration (install lsp in the configuration.nix)
|
||||
|
||||
You can install the `lsp` (in our case `hie-wrapper`) globally in your `configuration.nix` .
|
||||
I usually do this in my projects (via `lsp.nix`). Here is the part that differs.
|
||||
|
||||
```nix
|
||||
```
|
||||
home.file.".spacemacs.d/hook-user-config.el".text =
|
||||
let
|
||||
all-hies = import (fetchTarball "https://github.com/infinisil/all-hies/tarball/master") {};
|
||||
|
|
@ -167,17 +167,17 @@ I usually do this in my projects (via `lsp.nix`). Here is the part that differs.
|
|||
'';
|
||||
```
|
||||
|
||||
# Setup the project
|
||||
## Setup the project
|
||||
|
||||
For a Haskell project I have this minimal setup of files.
|
||||
|
||||
## lsp.nix
|
||||
### lsp.nix
|
||||
|
||||
This file is to setup the `lsp-server`.
|
||||
If you already installed the `lsp-server` via the `configuration.nix`, this file is not necessary,
|
||||
but also does not hurt.
|
||||
|
||||
```nix
|
||||
```
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
let
|
||||
all-hies = import (fetchTarball "https://github.com/infinisil/all-hies/tarball/master") {};
|
||||
|
|
@ -193,13 +193,13 @@ pkgs.mkShell {
|
|||
}
|
||||
```
|
||||
|
||||
## env.nix
|
||||
### env.nix
|
||||
|
||||
Provides the environment to run
|
||||
`cabal test` and `cabal build`.
|
||||
All package files (e.g. `./current-project.nix`) are created by `cabal2nix`.
|
||||
|
||||
```nix
|
||||
```
|
||||
{ pkgs ? import <nixpkgs> {
|
||||
overlays = [
|
||||
(self: super: {
|
||||
|
|
@ -214,11 +214,11 @@ All package files (e.g. `./current-project.nix`) are created by `cabal2nix`.
|
|||
pkgs.haskellPackages.current-project.env
|
||||
```
|
||||
|
||||
## `shell.nix`
|
||||
### `shell.nix`
|
||||
|
||||
For other scripts and tooling important for development.
|
||||
|
||||
```nix
|
||||
```
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
let
|
||||
updateCabal = pkgs.writeShellScriptBin "update-cabal" /* sh */ ''
|
||||
|
|
@ -236,20 +236,20 @@ pkgs.mkShell {
|
|||
}
|
||||
```
|
||||
|
||||
## `.envrc`
|
||||
### `.envrc`
|
||||
|
||||
finally we need a `direnv` configuration file.
|
||||
`direnv` and the `direnv-mode` make it possible
|
||||
to load the environment needed and provided by the `*.nix` files.
|
||||
|
||||
```sh
|
||||
```
|
||||
use nix ./env.nix
|
||||
use nix ./lsp.nix
|
||||
use nix ./shell.nix
|
||||
```
|
||||
Don't forget to run `direnv allowed . ` in the project folder.
|
||||
|
||||
# Conclusion
|
||||
## Conclusion
|
||||
|
||||
Now we are capable to use the `lsp-server` configured in all our projects,
|
||||
with the editor we prefer.
|
||||
|
|
@ -263,6 +263,6 @@ I experience little to no problems with it.
|
|||
The most common thing is that I have to fire `lsp-restart-workspace` to remove old errors,
|
||||
but doing this every hour is not a problem for me.
|
||||
|
||||
## Support
|
||||
### Support
|
||||
|
||||
If you have comments or problems just ping me `palo @ irc.freenode.net`
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Lets look what `nix-instantiate` does.
|
|||
|
||||
We create a file `test1.nix`:
|
||||
|
||||
```nix
|
||||
```
|
||||
# file test1.nix
|
||||
rec {
|
||||
i = "like Nix";
|
||||
|
|
@ -53,7 +53,7 @@ rec {
|
|||
|
||||
and than we run `nix-instantiate` to render JSON:
|
||||
|
||||
```sh
|
||||
```
|
||||
$> nix-instantiate --eval --json --strict test1.nix | jq
|
||||
|
||||
{
|
||||
|
|
@ -70,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> {};
|
||||
|
|
@ -104,13 +104,13 @@ in
|
|||
|
||||
When running:
|
||||
|
||||
```sh
|
||||
```
|
||||
nix-instantiate --eval --strict --json test2.nix --show-trace | jq
|
||||
```
|
||||
|
||||
We get the following JSON:
|
||||
|
||||
```json
|
||||
```
|
||||
{
|
||||
"_module": {
|
||||
"args": {},
|
||||
|
|
@ -133,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> {};
|
||||
|
|
@ -165,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;
|
||||
|
|
@ -188,13 +188,13 @@ with lib;
|
|||
|
||||
The result of the now well known command
|
||||
|
||||
```nix
|
||||
```
|
||||
nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
```
|
||||
|
||||
looks like the result we want to have:
|
||||
|
||||
```nix
|
||||
```
|
||||
{
|
||||
"resource": {
|
||||
"random_pet": {
|
||||
|
|
@ -229,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;
|
||||
|
|
@ -308,7 +308,7 @@ in {
|
|||
|
||||
Let's look at the different `config.nix` results.
|
||||
|
||||
```nix
|
||||
```
|
||||
{
|
||||
imports = [
|
||||
./core.nix # resource definition
|
||||
|
|
@ -324,7 +324,7 @@ Let's look at the different `config.nix` results.
|
|||
}
|
||||
```
|
||||
|
||||
```json
|
||||
```
|
||||
$> nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
{
|
||||
"resource": {
|
||||
|
|
@ -345,7 +345,7 @@ The output is like we expected it to be.
|
|||
|
||||
Let's add some `additionalFileSize`.
|
||||
|
||||
```nix
|
||||
```
|
||||
{
|
||||
imports = [
|
||||
./core.nix # resource definition
|
||||
|
|
@ -362,7 +362,7 @@ Let's add some `additionalFileSize`.
|
|||
}
|
||||
```
|
||||
|
||||
```json
|
||||
```
|
||||
$> nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
{
|
||||
"resource": {
|
||||
|
|
@ -411,7 +411,7 @@ all admin keys.
|
|||
|
||||
Let's look at the `config.nix` first.
|
||||
|
||||
```nix
|
||||
```
|
||||
{
|
||||
imports = [
|
||||
./core.nix
|
||||
|
|
@ -444,7 +444,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;
|
||||
|
|
@ -474,7 +474,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
|
||||
|
|
@ -572,7 +572,7 @@ Look closely at the end of the `serverResource` definition.
|
|||
|
||||
Let's look at the resulting JSON:
|
||||
|
||||
```json
|
||||
```
|
||||
$> nix-instantiate --eval --strict --json test3.nix --show-trace | jq
|
||||
{
|
||||
"resource": {
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ summary: >
|
|||
|
||||
---
|
||||
|
||||
# Tinc
|
||||
# tinc
|
||||
|
||||
In this article I will describe how to use my
|
||||
[NixOS](https://nixos.org/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue