forked from toolshed/docs.coopcloud.tech
Compare commits
5 Commits
main
...
feat-clean
| Author | SHA1 | Date | |
|---|---|---|---|
|
c371faa453
|
|||
|
186f8b117b
|
|||
| edb6fe93d7 | |||
| ac7940437b | |||
| 5b55e79a93 |
@ -96,6 +96,8 @@ make link
|
||||
|
||||
## Configure `abra` with `abra.yml`
|
||||
|
||||
You can place an `abra.yml`-file in the root of your `$ABRA_DIR`.
|
||||
|
||||
There are few configuration options supported at this time but more can be added. We are open to requests!
|
||||
|
||||
### `$ABRA_DIR`
|
||||
@ -106,7 +108,7 @@ The lookup logic is defined like so.
|
||||
* look for config file and take value from there
|
||||
* $HOME/.abra as fallback
|
||||
|
||||
If you create an `abra.yml` file in your `$PWD` with the following contents.
|
||||
If you create an `abra.yml` file in your `$PWD` (print working directory) with the following contents.
|
||||
|
||||
```
|
||||
abraDir: .
|
||||
@ -114,6 +116,12 @@ abraDir: .
|
||||
|
||||
Then `$ABRA_DIR` will be automatically picked up as `$PWD`. This is useful when you maintain multiple project configurations and recipes in various state of chaos and would like to separate those. `abra` will create all the usual `$HOME/.abra` state (`servers`/`recipes`/etc.) under your chosen `abraDir` value. This allows you to have multiple independent versions of specific recipes which are relevant for specific projects vs. relying on a single `$ABRA_DIR/recipes/<recipe>` and constantly having to switch between different chaotic hacks.
|
||||
|
||||
### `$EDITOR`
|
||||
|
||||
When you edit `.env.sample` files, you are asked to chose an editor. To avoid answering that question all the time, you can either set an environment variable (`export EDITOR=nano`), or you can set it as a config-option in abra.yml, like this:
|
||||
|
||||
`editor: nano`
|
||||
|
||||
## Running abra server side
|
||||
|
||||
If you're on an environment where it's hard to run Docker, or command-line programs in general, you might want to install `abra` on a server instead of your local computer.
|
||||
@ -687,3 +695,13 @@ present.
|
||||
|
||||
However, it is otherwise **ignored** for the version candidate. The "source of
|
||||
truth" for the version candidate is the live deployment of the app.
|
||||
|
||||
### Clean up the server
|
||||
|
||||
When you have deployed and undeployed apps, or when you have updated apps, docker will not automatically remove the images and containers. At some point your disk will be full, and you get strange errors when trying to deploy new apps.
|
||||
|
||||
Log into your server with `ssh`.
|
||||
|
||||
You can view all information about containers and images using the command `docker system df -v`. You might see images used by 0 containers and DEAD and exited containers.
|
||||
|
||||
If you are *completely* SURE that you have deployed all the apps, you want to keep, you can remove all dead and unused images and containers with the command `docker system prune --all --force` (or `DOCKER_CONTEXT=<server-domain> docker system prune --all --force` if you have multiple docker contexts).
|
||||
|
||||
Reference in New Issue
Block a user