1
0
Fork 0

add usage chapter in the manual

This commit is contained in:
ibizaman 2023-12-25 23:23:55 -08:00 committed by Pierre Penninckx
parent 4054b4b663
commit 7a62b5b89c
4 changed files with 147 additions and 67 deletions

View file

@ -40,10 +40,10 @@ SHB provides also services that integrate with those blocks out of the box. Prog
<!--toc:start--> <!--toc:start-->
- [Supported Features](#supported-features) - [Supported Features](#supported-features)
- [Usage](#usage)
- [Manual](#manual) - [Manual](#manual)
- [Provided Services](#provided-services) - [Provided Services](#provided-services)
- [Demos](#demos) - [Demos](#demos)
- [Import selfhostblocks](#import-selfhostblocks)
- [Community](#community) - [Community](#community)
- [Tips](#tips) - [Tips](#tips)
- [TODOs](#todos) - [TODOs](#todos)
@ -119,6 +119,45 @@ Currently supported services and features are:
- [ ] Self published documentation for options. - [ ] Self published documentation for options.
- [ ] Examples for all building blocks. - [ ] Examples for all building blocks.
## Usage
The following snippet shows how to deploy to a machine (here `machine2`) using
[Colmena](https://colmena.cli.rs):
```nix
{
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
selfhostblocks.url = "github:ibizaman/selfhostblocks";
};
outputs = { self, selfhostblocks }: {
colmena = {
meta =
let
system = "x86_64-linux";
in {
nixpkgs = import nixpkgs { inherit system; };
nodeNixpkgs = {
machine2 = import selfhostblocks.inputs.nixpkgs { inherit system; };
};
};
machine1 = ...;
machine2 = { selfhostblocks, ... }: {
imports = [
selfhostblocks.nixosModules.${system}.default
];
};
};
};
}
```
More information is provided in the manual (see below).
## Manual ## Manual
The (WIP) complete manual can be found at [shb.skarabox.com](https://shb.skarabox.com/). The information in The (WIP) complete manual can be found at [shb.skarabox.com](https://shb.skarabox.com/). The information in
@ -477,64 +516,6 @@ Demos that start and deploy a service on a Virtual Machine on your computer are
[demo](./demo/) folder. These show the onboarding experience you would get if you deployed [demo](./demo/) folder. These show the onboarding experience you would get if you deployed
one of the services on your own server. one of the services on your own server.
## Import selfhostblocks
Ready to start using selfhostblocks? Thank you for trusting selfhostblocks. Please raise any
question you have or hurdle you encounter by creating an issue.
The top-level `flake.nix` just outputs a nixos module that gathers all other modules from
the [`modules/`](./modules/) directory. Use this repo as a flake input to your own repo.
The `inputs` field of your `flake.nix` file in your repo should look like so:
```nix
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
sops-nix.url = "github:Mic92/sops-nix";
selfhostblocks.url = "github:ibizaman/selfhostblocks";
selfhostblocks.inputs.nixpkgs.follows = "nixpkgs";
selfhostblocks.inputs.sops-nix.follows = "sops-nix";
};
```
`sops-nix` is used to setup passwords and secrets. Currently `selfhostblocks` has a strong
dependency on it but I'm working on removing that so you could use any secret provider.
The snippet above makes `selfhostblocks`' inputs follow yours. This is not maintainable though
because options that `selfhostblocks` rely on can change or disappear and you have no control on
that. Later, I intend to make `selfhostblocks` provide its own `nixpkgs` input and update it myself
through CI.
How you actually deploy using selfhostblocks depends on what system you choose. If you use
[colmena](https://colmena.cli.rs), this is what your `outputs` field could look like:
```nix
outputs = inputs@{ self, nixpkgs, ... }: {
colmena = {
meta = {
nixpkgs = import inputs.nixpkgs {
system = "x86_64-linux";
};
specialArgs = inputs;
};
myserver = import ./machines/myserver.nix;
};
}
```
Now, what goes inside this `./machines/myserver.nix` file? First, import `selfhostblocks` and
`sops-nix`:
```nix
imports = [
selfhostblocks.nixosModules.x86_64-linux.default
sops-nix.nixosModules.default
]
```
For the rest, see the above [building blocks](#building-blocks), [provided services](#provided-services) and [demos](#demos) sections.
## Community ## Community
All issues and PRs are welcome. For PRs, if they are substantial changes, please open an issue to discuss the details first. All issues and PRs are welcome. For PRs, if they are substantial changes, please open an issue to discuss the details first.

View file

@ -7,6 +7,10 @@
preface.md preface.md
``` ```
```{=include=} chapters html:into-file=//usage.html
usage.md
```
```{=include=} chapters html:into-file=//services.html ```{=include=} chapters html:into-file=//services.html
services.md services.md
``` ```

95
docs/usage.md Normal file
View file

@ -0,0 +1,95 @@
# Usage {#usage}
## Flake {#usage-flake}
Self Host Blocks is available as a flake. To use it in your project, add the following flake input:
```nix
inputs.selfhostblocks.url = "github:ibizaman/selfhostblocks";
```
Self Host Blocks provides its own `nixpkgs` input so both can be updated in lock step, ensuring
maximum compatibility. It is recommended to use the following `nixpkgs` as input for your deployments:
```nix
inputs.selfhostblocks.inputs.nixpkgs
```
Advanced users can if they wish use a version of `nixpkgs` of their choosing but then we cannot
guarantee Self Host Block won't use a non-existing option from `nixpkgs`.
To avoid manually updating the `nixpkgs` version, the [GitHub repository][1] for Self Host Blocks
tries to update the `nixpkgs` input daily, verifying all tests pass before accepting this new
`nixpkgs` version. The setup is explained in [this blog post][2].
[1]: https://github.com/ibizaman/selfhostblocks
[2]: https://blog.tiserbox.com/posts/2023-12-25-automated-flake-lock-update-pull-requests-and-merging.html
## Example Deployment With Colmena {#usage-example-colmena}
The following snippets show how to deploy Self Host Blocks using the deployment system [Colmena][3].
[3]: https://colmena.cli.rs
```nix
{
inputs = {
selfhostblocks.url = "github:ibizaman/selfhostblocks";
};
outputs = { self, selfhostblocks }: {
colmena = {
meta =
let
system = "x86_64-linux";
in {
nixpkgs = import selfhostblocks.inputs.nixpkgs { inherit system; };
};
machine = { selfhostblocks, ... }: {
imports = [
selfhostblocks.nixosModules.${system}.default
];
};
};
};
}
```
The above snippet is very minimal as it assumes you have only one machine to deploy to, so `nixpkgs`
is defined exclusively by the `selfhostblocks` input. It is more likely that you have multiple machines, in this case you can use the `colmena.meta.nodeNixpkgs` option:
```nix
{
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
selfhostblocks.url = "github:ibizaman/selfhostblocks";
};
outputs = { self, selfhostblocks }: {
colmena = {
meta =
let
system = "x86_64-linux";
in {
nixpkgs = import nixpkgs { inherit system; };
nodeNixpkgs = {
machine2 = import selfhostblocks.inputs.nixpkgs { inherit system; };
};
};
machine1 = ...;
machine2 = { selfhostblocks, ... }: {
imports = [
selfhostblocks.nixosModules.${system}.default
];
};
};
};
}
```
In the above snippet, `machine1` will use the `nixpkgs` version from your inputs while `machine2`
will use the `nixpkgs` version from `selfhostblocks`.

View file

@ -11,9 +11,9 @@ Two implementations for this block are provided:
No integration tests are provided yet. No integration tests are provided yet.
## Usage {#usage} ## Usage {#blocks-backup-usage}
### One folder backed up to mounted hard drives {#blocks-backup-config-one} ### One folder backed up to mounted hard drives {#blocks-backup-usage-one}
The following snippet shows how to configure backup of 1 folder using the Restic implementation to 1 The following snippet shows how to configure backup of 1 folder using the Restic implementation to 1
repository. repository.
@ -79,7 +79,7 @@ borgmatic:
You can have both borgmatic and restic implementations working at the same time. You can have both borgmatic and restic implementations working at the same time.
### One folder backed up to S3 {#blocks-backup-config-remote} ### One folder backed up to S3 {#blocks-backup-usage-remote}
> This is only supported by the Restic implementation. > This is only supported by the Restic implementation.
@ -117,7 +117,7 @@ The Sops file has a new required field:
+ AWS_SECRET_ACCESS_KEY=<aws_secret_key> + AWS_SECRET_ACCESS_KEY=<aws_secret_key>
``` ```
### Multiple folder to multiple destinations {#blocks-backup-config-multiple} ### Multiple folder to multiple destinations {#blocks-backup-usage-multiple}
The following snippet shows how to configure backup of any number of folders using the Restic The following snippet shows how to configure backup of any number of folders using the Restic
implementation to 3 repositories, each happening at different times to avoid contending for I/O implementation to 3 repositories, each happening at different times to avoid contending for I/O
@ -214,18 +214,18 @@ shb.backup.instances.all = backupcfg repos ["/var/lib/myfolder1" "/var/lib/myfol
Head over to the [Home Assistant demo](demo-homeassistant.html) for a demo that installs Home Head over to the [Home Assistant demo](demo-homeassistant.html) for a demo that installs Home
Assistant on a VM with minimal manual steps. Assistant on a VM with minimal manual steps.
## Monitoring {#monitoring-backup-block} ## Monitoring {#blocks-backup-monitoring}
[WIP] [WIP]
## Maintenance {#monitoring-maintenance} ## Maintenance {#blocks-backup-maintenance}
[WIP] [WIP]
## Options Reference {#opt-backup-block} ## Options Reference {#blocks-backup-options}
```{=include=} options ```{=include=} options
id-prefix: opt-blocks-backup- id-prefix: blocks-backup-options-
list-id: selfhostblocks-block-backup-options list-id: selfhostblocks-block-backup-options
source: @OPTIONS_JSON@ source: @OPTIONS_JSON@
``` ```