mirror of
https://github.com/moghtech/komodo.git
synced 2026-04-30 22:56:21 -05:00
1.14 - Rename to Komodo - Docker Management (#56)
* setup network page * add Network, Image, Container * Docker ListItems and Inspects * frontend build * dev0 * network info working * fix cargo lock * dev1 * pages for the things * implement Active in dashboard * RunBuild update trigger list refresh * rename deployment executions to StartDeployment etc * add server level container control * dev2 * add Config field to Image * can get image labels from Config.Labels * mount container page * server show resource count * add GetContainerLog api * add _AllContainers api * dev3 * move ResourceTarget to entities mod * GetResourceMatchingContainer api * connect container to resource * dev4 add volume names to container list items * ts types * volume / image / network unused management * add image history to image page * fix PruneContainers incorret Operation * update cache for server for server after server actions * dev5 * add singapore to Hetzner * implement delete single network / image / volume api * dev6 * include "in use" on Docker Lists * add docker resource delete buttons * is nice * fix volume all in use * remove google font dependency * use host networking in test compose * implement Secret Variables (hidden in logs) * remove unneeded borrow * interpolate variables / secrets into extra args / onclone / onpull / command etc * validate empty strings before SelectItem * rename everything to Komodo * rename workspace to komodo * rc1
This commit is contained in:
Maxwell Becker
GitHub
@@ -1,6 +1,6 @@
|
||||
# API
|
||||
|
||||
Monitor Core exposes an http API to read data, write configuration, and execute actions. The API documentation is generated from the code and is [available here](https://docs.rs/monitor_client/latest/monitor_client/api/index.html).
|
||||
Komodo Core exposes an http API to read data, write configuration, and execute actions. The API documentation is generated from the code and is [available here](https://docs.rs/komodo_client/latest/komodo_client/api/index.html).
|
||||
|
||||
You can also install the [Monitor CLI](https://crates.io/crates/monitor_cli) to execute actions like RunBuild or DeployStack from the command line.
|
||||
This can be coupled with scripts in Monitor Repos to achieve unlimited automation.
|
||||
You can also install the [Komodo CLI](https://crates.io/crates/komodo_cli) to execute actions like RunBuild or DeployStack from the command line.
|
||||
This can be coupled with scripts in Komodo Repos to achieve unlimited automation.
|
||||
@@ -1,13 +1,13 @@
|
||||
# Builders
|
||||
|
||||
A builder is a machine running monitor periphery and docker, which is able to handle a RunBuild command from monitor core. Any server connected to monitor can be chosen as the builder for a build.
|
||||
A builder is a machine running the Komodo Periphery agent (and usually docker), which is able to handle a RunBuild / BuildRepo command from Komodo core. Any server connected to Komodo can be chosen as the builder for a build.
|
||||
|
||||
Building on a machine running production software is usually not a great idea, as this process can use a lot of system resources. It is better to start up a temporary cloud machine dedicated for the build, then shut it down when the build is finished. Monitor supports AWS EC2 for this task.
|
||||
Building on a machine running production software is usually not a great idea, as this process can use a lot of system resources. It is better to start up a temporary cloud machine dedicated for the build, then shut it down when the build is finished. Komodo supports AWS EC2 for this task.
|
||||
|
||||
## AWS builder
|
||||
|
||||
Builders are now monitor resources, and are managed via the core API / can be updated using the UI.
|
||||
To use this feature, you need an AWS EC2 AMI with docker and monitor periphery configured to run on system start.
|
||||
Builders are now Komodo resources, and are managed via the core API / can be updated using the UI.
|
||||
To use this feature, you need an AWS EC2 AMI with docker and Komodo Periphery configured to run on system start.
|
||||
Once you create your builder and add the necessary configuration, it will be available to attach to builds.
|
||||
|
||||
### Setup the instance
|
||||
@@ -22,7 +22,7 @@ apt upgrade -y
|
||||
curl -fsSL https://get.docker.com | sh
|
||||
systemctl enable docker.service
|
||||
systemctl enable containerd.service
|
||||
curl -sSL https://raw.githubusercontent.com/mbecker20/monitor/main/scripts/setup-periphery.py | python3
|
||||
curl -sSL https://raw.githubusercontent.com/mbecker20/komodo/main/scripts/setup-periphery.py | python3
|
||||
systemctl enable periphery.service
|
||||
```
|
||||
|
||||
@@ -46,4 +46,4 @@ Once Periphery is running, you can navigate to the instance in the AWS UI and ch
|
||||
The AMI will provide a unique id starting with `ami-`, use this with the builder configuration.
|
||||
|
||||
### Configure security groups / firewall
|
||||
The builders will need inbound access on port 8120 from monitor core, be sure to add a security group with this rule to the Builder configuration.
|
||||
The builders will need inbound access on port 8120 from Komodo Core, be sure to add a security group with this rule to the Builder configuration.
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
# Configuration
|
||||
|
||||
Monitor just needs a bit of information in order to build your image.
|
||||
Komodo just needs a bit of information in order to build your image.
|
||||
|
||||
### Provider configuration
|
||||
Monitor supports cloning repos over http/s, from any provider that supports cloning private repos using `git clone https://<Token>@git-provider.net/<Owner>/<Repo>`.
|
||||
Komodo supports cloning repos over http/s, from any provider that supports cloning private repos using `git clone https://<Token>@git-provider.net/<Owner>/<Repo>`.
|
||||
|
||||
Accounts / access tokens can be configured in either the [core config](../core-setup.md#configuration)
|
||||
or in the [periphery config](../connecting-servers.md#manual-install-steps).
|
||||
|
||||
### Repo configuration
|
||||
To specify the git repo to build, just give it the name of the repo and the branch under *repo config*. The name is given like ```mbecker20/monitor```, it includes the username / organization that owns the repo.
|
||||
To specify the git repo to build, just give it the name of the repo and the branch under *repo config*. The name is given like `mbecker20/komodo`, it includes the username / organization that owns the repo.
|
||||
|
||||
Many repos are private, in this case an access token is needed by the building server.
|
||||
It can either come from a provider defined in the core configuration,
|
||||
@@ -17,7 +17,7 @@ or in the periphery configuration of the building server.
|
||||
|
||||
### Docker build configuration
|
||||
|
||||
In order to docker build, monitor just needs to know the build directory and the path of the Dockerfile relative to the repo, you can configure these in the *build config* section.
|
||||
In order to docker build, Komodo just needs to know the build directory and the path of the Dockerfile relative to the repo, you can configure these in the *build config* section.
|
||||
|
||||
If the build directory is the root of the repository, you pass the build path as `.`. If the build directory is some folder of the repo, just pass the name of the the folder. Do not pass the preceding "/". for example `build/directory`
|
||||
|
||||
@@ -25,7 +25,7 @@ The dockerfile's path is given relative to the build directory. So if your build
|
||||
|
||||
### Image registry
|
||||
|
||||
Monitor supports pushing to any docker registry.
|
||||
Komodo supports pushing to any docker registry.
|
||||
Any of the accounts that are specified in config for the specific registry, between the core config and builder, will be available to use for authentication against the registry.
|
||||
Additionally, allowed organizations on the docker registry can be specified on the core config and attached to builds.
|
||||
Doing so will cause the images to be published under the organization's namespace rather than the account's.
|
||||
|
||||
@@ -4,7 +4,7 @@ slug: /build-images
|
||||
|
||||
# Building Images
|
||||
|
||||
Monitor builds docker images by cloning the source repository from the configured git provider, running `docker build`,
|
||||
Komodo builds docker images by cloning the source repository from the configured git provider, running `docker build`,
|
||||
and pushing the resulting image to the configured docker registry. Any repo containing a `Dockerfile` is buildable using this method.
|
||||
|
||||
```mdx-code-block
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
# Versioning
|
||||
# Image Versioning
|
||||
|
||||
Monitor uses a major.minor.patch versioning scheme. Every build will auto increment the patch number, and push the image to docker hub with the version tag as well as the ```latest``` tag.
|
||||
Komodo uses a major.minor.patch versioning scheme to Build versioning. By default, every RunBuild will auto increment the Build's version patch number, and push the image to docker hub with the version tag, as well as the `latest` tag. A tag containing the latest short commit hash at the time the repo was cloned will also be created.
|
||||
|
||||
You can also turn off the auto incrementing feature, and manage the version yourself. In addition, you can configure a "version tag" on the build. This will postfix the version tag / commit hash tag with a custom label. For example, an image tag of `dev` will produce tags like `image_name:1.1.1-dev` and `image_name:h3c87c-dev`.
|
||||
@@ -1,37 +1,41 @@
|
||||
# Connecting Servers
|
||||
|
||||
Connecting a server to monitor has 2 steps:
|
||||
Connecting a server to Komodo has 2 steps:
|
||||
|
||||
1. Install the Periphery agent on the server
|
||||
2. Adding the server to monitor via the core API
|
||||
2. Adding the server to Komodo via the core API
|
||||
|
||||
Once step 1. is complete, you can just connect the server to Monitor Core from the UI.
|
||||
Once step 1. is complete, you can just connect the server to Komodo Core from the UI.
|
||||
|
||||
## Install
|
||||
|
||||
You can install Periphery as a systemd managed process, run it as a [docker container](https://github.com/mbecker20/monitor/pkgs/container/periphery), or do whatever you want with the binary.
|
||||
You can install Periphery as a systemd managed process, run it as a [docker container](https://github.com/mbecker20/komodo/pkgs/container/periphery), or do whatever you want with the binary.
|
||||
|
||||
Some Periphery actions interact with your hosts file system, like cloning repos, or accessing local compose files.
|
||||
For this reason, runnning periphery in a container can be a bit more complicated.
|
||||
Additionally, Periphery in a container tends to overreport the disks by default, but this can be fixed via some configuration.
|
||||
|
||||
:::warning
|
||||
Allowing unintended access to the Periphery agent API is a security risk. Ensure to take appropriate measures to block access to the Periphery API, such as firewall rules on port `8120`. Additionally, you can whitelist your Komodo Core IP address in the [Periphery config](https://github.com/mbecker20/komodo/blob/2463ed3879ee56821f99d1f09581d659ee5d0575/config_example/periphery.config.example.toml#L46), and configure it to [only accept requests matching including your Core passkey](https://github.com/mbecker20/komodo/blob/2463ed3879ee56821f99d1f09581d659ee5d0575/config_example/periphery.config.example.toml#L51).
|
||||
:::
|
||||
|
||||
### Install the Periphery agent - systemd
|
||||
|
||||
As root user:
|
||||
```sh
|
||||
curl -sSL https://raw.githubusercontent.com/mbecker20/monitor/main/scripts/setup-periphery.py | python3
|
||||
curl -sSL https://raw.githubusercontent.com/mbecker20/komodo/main/scripts/setup-periphery.py | python3
|
||||
```
|
||||
|
||||
Periphery can also be installed to run as the calling user, just note this comes with some additional configuration.
|
||||
|
||||
```sh
|
||||
curl -sSL https://raw.githubusercontent.com/mbecker20/monitor/main/scripts/setup-periphery.py | python3 - --user
|
||||
curl -sSL https://raw.githubusercontent.com/mbecker20/komodo/main/scripts/setup-periphery.py | python3 - --user
|
||||
```
|
||||
|
||||
You can find more information (and view the script) in the [readme](https://github.com/mbecker20/monitor/tree/main/scripts).
|
||||
You can find more information (and view the script) in the [readme](https://github.com/mbecker20/komodo/tree/main/scripts).
|
||||
|
||||
:::info
|
||||
This script can be run multiple times without issue, and it won't change existing config after the first run. Just run it again after a Monitor version release, and it will update the periphery version.
|
||||
This script can be run multiple times without issue, and it won't change existing config after the first run. Just run it again after a Komodo version release, and it will update the periphery version.
|
||||
:::
|
||||
|
||||
### Install the Periphery agent - container
|
||||
@@ -39,7 +43,7 @@ This script can be run multiple times without issue, and it won't change existin
|
||||
You can use a docker compose file like this:
|
||||
```yaml
|
||||
services:
|
||||
monitor-periphery:
|
||||
komodo-periphery:
|
||||
image: ghcr.io/mbecker20/periphery:latest # use ghcr.io/mbecker20/periphery:latest-aarch64 for arm support
|
||||
logging:
|
||||
driver: local
|
||||
@@ -47,22 +51,27 @@ services:
|
||||
- 8120:8120
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
- monitor-repos:/etc/monitor/repos # manage repos in a docker volume, or change it to an accessible host directory.
|
||||
- komodo-repos:/etc/komodo/repos # manage repos in a docker volume, or change it to an accessible host directory.
|
||||
- komodo-stacks:/etc/komodo/stacks # manage stacks in a docker volume, or change it to an accessible host directory.
|
||||
# environment:
|
||||
# # If the disk size is overreporting, can use one of these to
|
||||
# # whitelist / blacklist the disks to filter them, whichever is easier.
|
||||
# PERIPHERY_INCLUDE_DISK_MOUNTS: /etc/monitor/repos
|
||||
# PERIPHERY_INCLUDE_DISK_MOUNTS: /etc/komodo/repos
|
||||
# PERIPHERY_EXCLUDE_DISK_MOUNTS: /snap
|
||||
|
||||
volumes:
|
||||
komodo-repos:
|
||||
komodo-stacks:
|
||||
```
|
||||
|
||||
### Manual install steps - binaries
|
||||
|
||||
1. Download the periphery binary from the latest [release](https://github.com/mbecker20/monitor/releases).
|
||||
1. Download the periphery binary from the latest [release](https://github.com/mbecker20/komodo/releases).
|
||||
|
||||
2. Create and edit your config files, following the [config example](https://github.com/mbecker20/monitor/blob/main/config_example/periphery.config.example.toml).
|
||||
2. Create and edit your config files, following the [config example](https://github.com/mbecker20/komodo/blob/main/config_example/periphery.config.example.toml).
|
||||
|
||||
:::note
|
||||
See the [periphery config docs](https://docs.rs/monitor_client/latest/monitor_client/entities/config/periphery/index.html)
|
||||
See the [periphery config docs](https://docs.rs/komodo_client/latest/komodo_client/entities/config/periphery/index.html)
|
||||
for more information on configuring periphery.
|
||||
:::
|
||||
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
# Monitor Core Setup
|
||||
# Komodo Core Setup
|
||||
|
||||
To run Monitor Core, you will need Docker. See [the docker install docs](https://docs.docker.com/engine/install/).
|
||||
To run Komodo Core, you will need Docker. See [the docker install docs](https://docs.docker.com/engine/install/).
|
||||
|
||||
### Deploy Monitor Core with Docker Compose
|
||||
### Deploy Komodo Core with Docker Compose
|
||||
|
||||
There is an example compose file here: [https://github.com/mbecker20/monitor/blob/main/config_example/core.compose.yaml](https://github.com/mbecker20/monitor/blob/main/config_example/core.compose.yaml).
|
||||
There is an example compose file here: [https://github.com/mbecker20/komodo/blob/main/config_example/core.compose.yaml](https://github.com/mbecker20/komodo/blob/main/config_example/core.compose.yaml).
|
||||
|
||||
Copy the contents to a `compose.yaml`, and deploy it with `docker compose up -d`.
|
||||
|
||||
:::info
|
||||
Monitor Core itself can really only run remote builds.
|
||||
You also have to [**install the Monitor Periphery agent**](/docs/connecting-servers) on your hosts and connect them as **Servers**
|
||||
Komodo Core itself can really only run remote builds.
|
||||
You also have to [**install the Komodo Periphery agent**](/docs/connecting-servers) on your hosts and connect them as **Servers**
|
||||
in order to alert / deploy etc.
|
||||
|
||||
If you **only need to connect on one server** (the one you are deploying Monitor Core on), you can do it all dockerized,
|
||||
and use the [**all-in-one compose file**](https://github.com/mbecker20/monitor/blob/main/config_example/aio.compose.yaml).
|
||||
This will deploy Monitor Core and Periphery, and automatically add the local periphery as a connected server.
|
||||
If you **only need to connect on one server** (the one you are deploying Komodo Core on), you can do it all dockerized,
|
||||
and use the [**all-in-one compose file**](https://github.com/mbecker20/komodo/blob/main/config_example/aio.compose.yaml).
|
||||
This will deploy Komodo Core and Periphery, and automatically add the local periphery as a connected server.
|
||||
|
||||
Deploying with the AIO compose file **will not** stop you from connecting more servers later, and is really just for setup convenience.
|
||||
|
||||
@@ -24,10 +24,10 @@ You can currently and always will be able to **connect as many servers an you li
|
||||
|
||||
### Configuration
|
||||
|
||||
You can configure Monitor with environment variables, or using a config file.
|
||||
You can configure Komodo with environment variables, or using a config file.
|
||||
|
||||
The example config file in the Monitor repo documents all the configuration options, along with the corresponding environment variables.
|
||||
It can be found here: [https://github.com/mbecker20/monitor/blob/main/config_example/core.config.example.toml](https://github.com/mbecker20/monitor/blob/main/config_example/core.config.example.toml).
|
||||
The example config file in the Komodo repo documents all the configuration options, along with the corresponding environment variables.
|
||||
It can be found here: [https://github.com/mbecker20/komodo/blob/main/config_example/core.config.example.toml](https://github.com/mbecker20/komodo/blob/main/config_example/core.config.example.toml).
|
||||
|
||||
Note that configuration passed in environment variables will take precedent over what is given in the file.
|
||||
|
||||
@@ -35,7 +35,7 @@ Note that configuration passed in environment variables will take precedent over
|
||||
To enable OAuth2 login, you must create a client on the respective OAuth provider,
|
||||
for example [google](https://developers.google.com/identity/protocols/oauth2)
|
||||
or [github](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps).
|
||||
Monitor uses the `web application` login flow.
|
||||
Komodo uses the `web application` login flow.
|
||||
The redirect uri is `<base_url>/auth/google/callback` for google and `<base_url>/auth/github/callback` for github.
|
||||
:::
|
||||
|
||||
@@ -56,7 +56,7 @@ Core itself only supports http, so a reverse proxy like [caddy](https://caddyser
|
||||
Mongo can be run locally using the docker cli:
|
||||
|
||||
```sh
|
||||
docker run --name monitor-mongo \
|
||||
docker run --name komodo-mongo \
|
||||
--network host \
|
||||
-v /local/storage/path:/data/db \
|
||||
-e MONGO_INITDB_ROOT_USERNAME="admin" \
|
||||
@@ -71,20 +71,20 @@ Note that this uses "host" networking, which will allow core to connect over loc
|
||||
Many users will prefer the default "bridge" network, and to use port mapping with `-p 27017:27017`.
|
||||
|
||||
:::note
|
||||
The disk space requirements of Monitor are dominated by the storage of system stats.
|
||||
The disk space requirements of Komodo are dominated by the storage of system stats.
|
||||
This depends on the number of connected servers (more system stats being produces / stored), stats collection frequency, and your stats pruning configuration.
|
||||
If you need to save on space, you can configure these fields in your core config: - Stats poll frequency can be reduced using, for example, `monitoring_interval = "15-sec"` - Pruning can be tuned more aggresively using, for example, `keep_stats_for_days = 7`.
|
||||
:::
|
||||
|
||||
### 2. Start Monitor core
|
||||
### 2. Start Komodo core
|
||||
|
||||
Monitor core is distributed via Github Container Registry under the package [mbecker20/monitor](https://github.com/mbecker20/monitor/pkgs/container/monitor).
|
||||
Komodo core is distributed via Github Container Registry under the package [mbecker20/komodo](https://github.com/mbecker20/komodo/pkgs/container/komodo).
|
||||
|
||||
```sh
|
||||
docker run -d --name monitor-core \
|
||||
docker run -d --name komodo-core \
|
||||
--network host \
|
||||
-v $HOME/.monitor/core.config.toml:/config/config.toml \
|
||||
ghcr.io/mbecker20/monitor:latest
|
||||
-v $HOME/.config/komodo/core.config.toml:/config/config.toml \
|
||||
ghcr.io/mbecker20/komodo:latest
|
||||
```
|
||||
|
||||
Note that this uses "host" networking, which will allow it to connect to a local periphery agent on localhost.
|
||||
|
||||
@@ -4,12 +4,12 @@
|
||||
|
||||
There are two options to configure the docker image to deploy.
|
||||
|
||||
### Attaching a Monitor build
|
||||
If the software you want to deploy is built by Monitor, you can attach the build directly to the deployment.
|
||||
### Attaching a Komodo build
|
||||
If the software you want to deploy is built by Komodo, you can attach the build directly to the deployment.
|
||||
|
||||
By default, Monitor will deploy the latest available version of the build, or you can specify a specific version using the version dropdown.
|
||||
By default, Komodo will deploy the latest available version of the build, or you can specify a specific version using the version dropdown.
|
||||
|
||||
Also by default, Monitor will use the same docker account that is attached to the build in order to pull the image on the periphery server. If that account is not available on the server, you can specify another available account to use instead, this account just needs to have read access to the docker repository.
|
||||
Also by default, Komodo will use the same docker account that is attached to the build in order to pull the image on the periphery server. If that account is not available on the server, you can specify another available account to use instead, this account just needs to have read access to the docker repository.
|
||||
|
||||
### Using a custom image
|
||||
You can also manually specify an image name, like `mongo` or `ghcr.io/mbecker20/random_image:0.1.1`.
|
||||
@@ -18,7 +18,7 @@ If the image repository is private, you can still select an available docker acc
|
||||
|
||||
## Configuring the network
|
||||
|
||||
One feature of docker is that it allows for the creation of [virtual networks between containers](https://docs.docker.com/network/). Monitor allows you to specify a docker virtual network to connect the container to, or to use the host system networking to bypass the docker virtual network.
|
||||
One feature of docker is that it allows for the creation of [virtual networks between containers](https://docs.docker.com/network/). Komodo allows you to specify a docker virtual network to connect the container to, or to use the host system networking to bypass the docker virtual network.
|
||||
|
||||
The default selection is `host`, which bypasses the docker virtual network layer.
|
||||
|
||||
@@ -34,11 +34,11 @@ Note that this is not the only affect of using a network other than `host`. For
|
||||
|
||||
## Configuring restart behavior
|
||||
|
||||
Docker, like systemd, has a couple options for handling when a container exits. See [docker restart policies](https://docs.docker.com/config/containers/start-containers-automatically/). Monitor allows you to select the appropriate restart behavior from these options.
|
||||
Docker, like systemd, has a couple options for handling when a container exits. See [docker restart policies](https://docs.docker.com/config/containers/start-containers-automatically/). Komodo allows you to select the appropriate restart behavior from these options.
|
||||
|
||||
## Configuring environment variables
|
||||
|
||||
Monitor enables you to easily manage environment variables passed to the container.
|
||||
Komodo enables you to easily manage environment variables passed to the container.
|
||||
In the GUI, navigate to the environment tab of the configuration on the deployment page.
|
||||
|
||||
You pass environment variables just as you would with a ```.env``` file:
|
||||
@@ -64,7 +64,7 @@ These can be configured easily with the GUI in the 'volumes' card. You can confi
|
||||
|
||||
## Extra args
|
||||
|
||||
Not all features of docker are mapped directly by monitor, only the most common. You can still specify any custom flags for monitor to include in the ```docker run``` command by utilizing 'extra args'. For example, you can enable log rotation using these two extra args:
|
||||
Not all features of docker are mapped directly by Komodo, only the most common. You can still specify any custom flags for Komodo to include in the `docker run` command by utilizing 'extra args'. For example, you can enable log rotation using these two extra args:
|
||||
|
||||
```
|
||||
--log-opt max-size=10M
|
||||
@@ -81,4 +81,4 @@ Sometimes you need to override the default command in the image, or specify some
|
||||
docker run -d --name mongo-db mongo:6.0.3 --quiet
|
||||
```
|
||||
|
||||
In order to achieve this with monitor, just pass `--quiet` to 'command'.
|
||||
In order to achieve this with Komodo, just pass `--quiet` to 'command'.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Deploy Containers
|
||||
|
||||
Monitor can deploy any docker images that it can access with the configured docker accounts.
|
||||
Komodo can deploy any docker images that it can access with the configured docker accounts.
|
||||
It works by parsing the deployment configuration into a `docker run` command, which is then run on the target system.
|
||||
The configuration is stored on MongoDB, and records of all actions (update config, deploy, stop, etc.) are stored as well.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Container Management
|
||||
|
||||
The lifetime of a docker container is more like a virtual machine. They can be created, started, stopped, and destroyed. Monitor will display the state of the container and provides an API to manage all your container's lifetimes.
|
||||
The lifetime of a docker container is more like a virtual machine. They can be created, started, stopped, and destroyed. Komodo will display the state of the container and provides an API to manage all your container's lifetimes.
|
||||
|
||||
This is achieved internally by running the appropriate docker command for the requested action (docker stop, docker start, etc).
|
||||
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# Docker Compose
|
||||
|
||||
Monitor supports docker compose through the `Stack` resource.
|
||||
Komodo supports docker compose through the `Stack` resource.
|
||||
|
||||
## Define the compose file/s
|
||||
|
||||
Monitor supports 3 ways of defining the compose files:
|
||||
1. **Write them in the UI**, and Monitor will write them to your host at deploy-time.
|
||||
2. **Store them in a git repo**, and have Monitor clone it on the host to deploy.
|
||||
3. **Store the files anywhere on the host**, and Monitor will just run the compose commands on the existing files.
|
||||
Komodo supports 3 ways of defining the compose files:
|
||||
1. **Write them in the UI**, and Komodo will write them to your host at deploy-time.
|
||||
2. **Store them in a git repo**, and have Komodo clone it on the host to deploy.
|
||||
3. **Store the files anywhere on the host**, and Komodo will just run the compose commands on the existing files.
|
||||
|
||||
The recommended way to deploy Stacks is using compose files located in a git repo.
|
||||
|
||||
@@ -18,24 +18,24 @@ If you manage your compose files in git repos:
|
||||
- You can use the git webhooks to do other automations when you change the compose file contents. Redeploying will be as easy as just `git push`.
|
||||
|
||||
:::info
|
||||
Many Monitor resources need access to git repos. There is an in-built token management system (managed in UI or in config file) to give resources access to credentials.
|
||||
Many Komodo resources need access to git repos. There is an in-built token management system (managed in UI or in config file) to give resources access to credentials.
|
||||
All resources which depend on git repos are able to use these credentials to access private repos.
|
||||
:::
|
||||
|
||||
## Importing Existing Compose projects
|
||||
|
||||
First create the Stack in Monitor, and ensure it has access to the compose files using one
|
||||
First create the Stack in Komodo, and ensure it has access to the compose files using one
|
||||
of the three methods above. Make sure to attach the server you wish to deploy on.
|
||||
|
||||
In order for Monitor to pick up a running project, it has to know the compose "project name".
|
||||
In order for Komodo to pick up a running project, it has to know the compose "project name".
|
||||
You can find the project name by running `docker compose ls` on the host.
|
||||
|
||||
By default, Monitor will assume the Stack name is the compose project name.
|
||||
By default, Komodo will assume the Stack name is the compose project name.
|
||||
If this is different than the project name on the host, you can configure a custom "Project Name" in the config.
|
||||
|
||||
## Pass Environment Variables
|
||||
|
||||
Monitor is able to pass custom environment variables to the docker compose process.
|
||||
Komodo is able to pass custom environment variables to the docker compose process.
|
||||
This works by:
|
||||
|
||||
1. Write the variables to a ".env" file on the host at deploy-time.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# File Paths
|
||||
|
||||
When working with monitor, you might have to configure file or directory paths.
|
||||
When working with Komodo, you might have to configure file or directory paths.
|
||||
|
||||
## Relative Paths
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
slug: /intro
|
||||
---
|
||||
|
||||
# What is Monitor?
|
||||
# What is Komodo?
|
||||
|
||||
Monitor is a web app to provide structure for managing your servers, builds, deployments, and automated procedures.
|
||||
Komodo is a web app to provide structure for managing your servers, builds, deployments, and automated procedures.
|
||||
|
||||
With Monitor you can:
|
||||
With Komodo you can:
|
||||
|
||||
- Connect all of your servers, and alert on CPU usage, memory usage, and disk usage.
|
||||
- Create, start, stop, and restart Docker containers on the connected servers, and view their status and logs.
|
||||
@@ -18,29 +18,29 @@ With Monitor you can:
|
||||
|
||||
## Docker
|
||||
|
||||
Monitor is opinionated by design, and uses [docker](https://docs.docker.com/) as the container engine for building and deploying.
|
||||
Komodo is opinionated by design, and uses [docker](https://docs.docker.com/) as the container engine for building and deploying.
|
||||
|
||||
:::info
|
||||
Monitor also supports [**podman**](https://podman.io/) instead of docker by utilizing the `podman` -> `docker` alias.
|
||||
Komodo also supports [**podman**](https://podman.io/) instead of docker by utilizing the `podman` -> `docker` alias.
|
||||
For Stack / docker compose support with podman, check out [**podman-compose**](https://github.com/containers/podman-compose). Thanks to `u/pup_kit` for checking this.
|
||||
:::
|
||||
|
||||
## Architecture and Components
|
||||
|
||||
Monitor is composed of a single core and any amount of connected servers running the periphery application.
|
||||
Komodo is composed of a single core and any amount of connected servers running the periphery application.
|
||||
|
||||
### Core
|
||||
Monitor Core is a web server hosting the Core API and browser UI. All user interaction with the connected servers flow through the Core. It is the stateful part of the system, with the application state stored on an instance of MongoDB.
|
||||
Komodo Core is a web server hosting the Core API and browser UI. All user interaction with the connected servers flow through the Core. It is the stateful part of the system, with the application state stored on an instance of MongoDB.
|
||||
|
||||
### Periphery
|
||||
Monitor Periphery is a small stateless web server that runs on all connected servers. It exposes an API called by Monitor Core to perform actions on the server, get system usage, and container status / logs. It is only intended to be reached from the core, and has an address whitelist to limit the IPs allowed to call this API.
|
||||
Komodo Periphery is a small stateless web server that runs on all connected servers. It exposes an API called by Komodo Core to perform actions on the server, get system usage, and container status / logs. It is only intended to be reached from the core, and has an address whitelist to limit the IPs allowed to call this API.
|
||||
|
||||
## Core API
|
||||
|
||||
Monitor exposes powerful functionality over the Core's REST and Websocket API, enabling infrastructure engineers to manage their infrastructure programmatically. There is a [rust crate](https://crates.io/crates/monitor_client) to simplify programmatic interaction with the API, but in general this can be accomplished using any programming language that can make REST requests.
|
||||
Komodo exposes powerful functionality over the Core's REST and Websocket API, enabling infrastructure engineers to manage their infrastructure programmatically. There is a [rust crate](https://crates.io/crates/komodo_client) to simplify programmatic interaction with the API, but in general this can be accomplished using any programming language that can make REST requests.
|
||||
|
||||
## Permissioning
|
||||
|
||||
Monitor is a system designed to be used by many users, whether they are developers, operations personnel, or administrators. The ability to affect an applications state is very powerful, so monitor has a granular permissioning system to only provide this functionality to the intended users. The permissioning system is explained in detail in the [permissioning](/docs/permissioning) section.
|
||||
Komodo is a system designed to be used by many users, whether they are developers, operations personnel, or administrators. The ability to affect an applications state is very powerful, so Komodo has a granular permissioning system to only provide this functionality to the intended users. The permissioning system is explained in detail in the [permissioning](/docs/permissioning) section.
|
||||
|
||||
User sign-on is possible using username / password, or with Oauth (Github and Google). See [Core Setup](/docs/core-setup).
|
||||
@@ -1,6 +1,6 @@
|
||||
# Permissioning Resources
|
||||
|
||||
All monitor resources (servers, builds, deployment) have independant permission tables to allow for users to have granular access to these resources. By default, users do not see any resources until they are given at least read permissions.
|
||||
All Komodo resources (servers, builds, deployment) have independant permission tables to allow for users to have granular access to these resources. By default, users do not see any resources until they are given at least read permissions.
|
||||
|
||||
## Permission Levels
|
||||
|
||||
@@ -21,13 +21,13 @@ Users can then be **added to multiple User Groups** and they **inherit the group
|
||||
|
||||
## Administration
|
||||
|
||||
Users can be given admin priviledges by accessing the monitor MongoDB and setting ```admin: true``` on the intended user document. These users have unrestricted access to all monitor resources, like servers, builds, and deployments. Additionally, only these users can update other (non-admin) user's permissions on resources, an action not available to regular users even with **Update** level permissions.
|
||||
Users can be given admin priviledges by accessing the Komodo MongoDB and setting ```admin: true``` on the intended user document. These users have unrestricted access to all Komodo resources, like servers, builds, and deployments. Additionally, only these users can update other (non-admin) user's permissions on resources, an action not available to regular users even with **Update** level permissions.
|
||||
|
||||
Monitor admins are responsible for managing user accounts as well. When a user logs into monitor for the first time, they will not immediately be granted access. An admin must first **enable** the user, which can be done from the 'manage users' page (found in the user dropdown menu in the topbar). Users can also be **disabled** by an admin at any time, which blocks all their access to the GUI and API.
|
||||
Komodo admins are responsible for managing user accounts as well. When a user logs into Komodo for the first time, they will not immediately be granted access. An admin must first **enable** the user, which can be done from the 'manage users' page (found in the user dropdown menu in the topbar). Users can also be **disabled** by an admin at any time, which blocks all their access to the GUI and API.
|
||||
|
||||
Users also have some configurable global permissions, these are:
|
||||
|
||||
- create server permission
|
||||
- create build permission
|
||||
|
||||
Only users with these permissions (as well as admins) can add additional servers to monitor, and can create additional builds, respectively.
|
||||
Only users with these permissions (as well as admins) can add additional servers to Komodo, and can create additional builds, respectively.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Resources
|
||||
|
||||
Monitor is extendible through the **Resource** abstraction. Entities like `Server`, `Deployment`, and `Stack` are all **Monitor Resources**.
|
||||
Komodo is extendible through the **Resource** abstraction. Entities like `Server`, `Deployment`, and `Stack` are all **Komodo Resources**.
|
||||
|
||||
All resources have common traits, such as a unique `name` and `id` amongst all other resources of the same resource type.
|
||||
All resources can be assigned `tags`, which can be used to group related resources.
|
||||
@@ -62,4 +62,4 @@ All resources which depend on git repos / docker registries are able to use thes
|
||||
## ServerTemplate
|
||||
|
||||
-- Easily expand your cloud network by storing cloud server lauch templates on various providers.<br></br>
|
||||
-- Auto connect the server to monitor on launch, using `User Data` launch scripts.
|
||||
-- Auto connect the server to Komodo on launch, using `User Data` launch scripts.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Sync Resources
|
||||
|
||||
Monitor is able to create, update, delete, and deploy resources declared in TOML files by diffing them against the existing resources,
|
||||
Komodo is able to create, update, delete, and deploy resources declared in TOML files by diffing them against the existing resources,
|
||||
and apply updates based on the diffs. Push the files to a remote git repo and create a `ResourceSync` pointing to the repo,
|
||||
and the core backend will poll for any updates (you can also manually trigger an update poll / execution in the UI).
|
||||
|
||||
@@ -16,13 +16,13 @@ automatically execute syncs upon pushes to the configured branch.
|
||||
|
||||
### Server
|
||||
|
||||
- [Server config schema](https://docs.rs/monitor_client/latest/monitor_client/entities/server/struct.ServerConfig.html)
|
||||
- [Server config schema](https://docs.rs/komodo_client/latest/komodo_client/entities/server/struct.ServerConfig.html)
|
||||
|
||||
```toml
|
||||
[[server]] # Declare a new server
|
||||
name = "server-01"
|
||||
description = "the main mogh server"
|
||||
tags = ["monitor"]
|
||||
name = "server-prod"
|
||||
description = "the prod server"
|
||||
tags = ["prod"]
|
||||
config.address = "http://localhost:8120"
|
||||
config.region = "AshburnDc1"
|
||||
config.enabled = true # default: false
|
||||
@@ -30,8 +30,8 @@ config.enabled = true # default: false
|
||||
|
||||
### Builder and build
|
||||
|
||||
- [Builder config schema](https://docs.rs/monitor_client/latest/monitor_client/entities/builder/struct.BuilderConfig.html)
|
||||
- [Build config schema](https://docs.rs/monitor_client/latest/monitor_client/entities/build/struct.BuildConfig.html)
|
||||
- [Builder config schema](https://docs.rs/komodo_client/latest/komodo_client/entities/builder/struct.BuilderConfig.html)
|
||||
- [Build config schema](https://docs.rs/komodo_client/latest/komodo_client/entities/build/struct.BuildConfig.html)
|
||||
|
||||
```toml
|
||||
[[builder]] # Declare a builder
|
||||
@@ -73,7 +73,7 @@ org.opencontainers.image.licenses = GPL-3.0"""
|
||||
|
||||
### Deployments
|
||||
|
||||
- [Deployment config schema](https://docs.rs/monitor_client/latest/monitor_client/entities/deployment/struct.DeploymentConfig.html)
|
||||
- [Deployment config schema](https://docs.rs/komodo_client/latest/komodo_client/entities/deployment/struct.DeploymentConfig.html)
|
||||
|
||||
```toml
|
||||
[[variable]] # Declare variables
|
||||
@@ -131,7 +131,7 @@ config.labels = "deployment.type = logger"
|
||||
|
||||
### Stack
|
||||
|
||||
- [Stack config schema](https://docs.rs/monitor_client/latest/monitor_client/entities/stack/struct.StackConfig.html)
|
||||
- [Stack config schema](https://docs.rs/komodo_client/latest/komodo_client/entities/stack/struct.StackConfig.html)
|
||||
|
||||
```toml
|
||||
[[stack]]
|
||||
@@ -140,7 +140,7 @@ description = "stack test"
|
||||
deploy = true
|
||||
after = ["test-logger-01"] # Stacks can depend on deployments, and vice versa.
|
||||
tags = ["test"]
|
||||
config.server_id = "monitor-01"
|
||||
config.server_id = "server-prod"
|
||||
config.file_paths = ["mongo.yaml", "redis.yaml"]
|
||||
config.git_provider = "git.mogh.tech"
|
||||
config.git_account = "mbecker20" # clone private repo by specifying account
|
||||
@@ -149,7 +149,7 @@ config.repo = "mbecker20/stack_test"
|
||||
|
||||
### Procedure
|
||||
|
||||
- [Procedure config schema](https://docs.rs/monitor_client/latest/monitor_client/entities/procedure/struct.ProcedureConfig.html)
|
||||
- [Procedure config schema](https://docs.rs/komodo_client/latest/komodo_client/entities/procedure/struct.ProcedureConfig.html)
|
||||
|
||||
```toml
|
||||
[[procedure]]
|
||||
@@ -164,7 +164,7 @@ enabled = true
|
||||
# The executions within a stage will be run in parallel. The stage completes when all executions finish.
|
||||
executions = [
|
||||
{ execution.type = "RunBuild", execution.params.build = "test_logger", enabled = true },
|
||||
{ execution.type = "PullRepo", execution.params.repo = "monitor-periphery", enabled = true },
|
||||
{ execution.type = "PullRepo", execution.params.repo = "komodo-periphery", enabled = true },
|
||||
]
|
||||
|
||||
[[procedure.config.stage]]
|
||||
@@ -184,25 +184,27 @@ executions = [
|
||||
|
||||
### Repo
|
||||
|
||||
- [Repo config schema](https://docs.rs/monitor_client/latest/monitor_client/entities/repo/struct.RepoConfig.html)
|
||||
- [Repo config schema](https://docs.rs/komodo_client/latest/komodo_client/entities/repo/struct.RepoConfig.html)
|
||||
|
||||
```toml
|
||||
[[repo]]
|
||||
name = "monitor-periphery"
|
||||
name = "komodo-periphery"
|
||||
description = "Builds new versions of the periphery binary. Requires Rust installed on the host."
|
||||
tags = ["monitor"]
|
||||
tags = ["komodo"]
|
||||
config.server_id = "server-01"
|
||||
config.git_provider = "git.mogh.tech" # use an alternate git provider (default is github.com)
|
||||
config.git_account = "mbecker20"
|
||||
config.repo = "mbecker20/monitor"
|
||||
config.repo = "mbecker20/komodo"
|
||||
# Run an action after the repo is pulled
|
||||
config.on_pull.path = "."
|
||||
config.on_pull.command = "/root/.cargo/bin/cargo build -p monitor_periphery --release && cp ./target/release/periphery /root/periphery"
|
||||
config.on_pull.command = """
|
||||
/root/.cargo/bin/cargo build -p komodo_periphery --release && \
|
||||
cp ./target/release/periphery /root/periphery"""
|
||||
```
|
||||
|
||||
### User Group:
|
||||
|
||||
- [UserGroup schema](https://docs.rs/monitor_client/latest/monitor_client/entities/toml/struct.UserGroupToml.html)
|
||||
- [UserGroup schema](https://docs.rs/komodo_client/latest/komodo_client/entities/toml/struct.UserGroupToml.html)
|
||||
|
||||
```toml
|
||||
[[user_group]]
|
||||
@@ -213,7 +215,7 @@ all.Build = "Execute"
|
||||
all.Alerter = "Write"
|
||||
permissions = [
|
||||
# Attach permissions to specific resources by name
|
||||
{ target.type = "Repo", target.id = "monitor-periphery", level = "Execute" },
|
||||
{ target.type = "Repo", target.id = "komodo-periphery", level = "Execute" },
|
||||
# Attach permissions to many resources with name matching regex (this uses '^(.+)-(.+)$' as regex expression)
|
||||
{ target.type = "Server", target.id = "\\^(.+)-(.+)$\\", level = "Read" },
|
||||
{ target.type = "Deployment", target.id = "\\^immich\\", level = "Execute" },
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Version Upgrades
|
||||
|
||||
Most version upgrades only require a redeployment of the core container after pulling the latest version, and are fully backward compatible with the periphery clients, which may be updated later on as convenient. This is the default, and will be the case unless specifically mentioned in the [version release notes](https://github.com/mbecker20/monitor/releases).
|
||||
Most version upgrades only require a redeployment of the Core container after pulling the latest version, and are fully backward compatible with the periphery clients, which may be updated later on as convenient. This is the default, and will be the case unless specifically mentioned in the [version release notes](https://github.com/mbecker20/komodo/releases).
|
||||
|
||||
Some Core API upgrades may change behavior such as building / cloning, and require updating the Periphery binaries to match the Core version before this functionality can be restored. This will be specifically mentioned in the release notes.
|
||||
|
||||
Additionally, some Core API upgrades may include database schema changes, and require a database migration. This can be accomplished by using the [monitor migrator](https://github.com/mbecker20/monitor/blob/main/bin/migrator/README.md) for the particular version upgrade before upgrading the Core API container.
|
||||
Additionally, some Core API upgrades may include database schema changes, and require a database migration. This can be accomplished by using the [komodo migrator](https://github.com/mbecker20/komodo/blob/main/bin/migrator/README.md) for the particular version upgrade before upgrading the Core API container.
|
||||
@@ -1,6 +1,6 @@
|
||||
# Configuring Webhooks
|
||||
|
||||
Multiple Monitor resources can take advantage of webhooks from your git provider. Monitor supports incoming webhooks using the Github standard, which is also supported by other providers like Gitea.
|
||||
Multiple Komodo resources can take advantage of webhooks from your git provider. Komodo supports incoming webhooks using the Github standard, which is also supported by other providers like Gitea.
|
||||
|
||||
:::note
|
||||
On Gitea, the default "Gitea" webhook type works with the Github standard 👍
|
||||
@@ -20,16 +20,29 @@ You will have to input some information.
|
||||
|
||||
1. The `Payload URL` is the link that you copied in the step above, `Copy the Resource Payload URL`.
|
||||
2. For Content-type, choose `application/json`
|
||||
3. For Secret, input the secret you configured in the Monitor Core config (`MONITOR_WEBHOOK_SECRET`).
|
||||
3. For Secret, input the secret you configured in the Komodo Core config (`KOMODO_WEBHOOK_SECRET`).
|
||||
4. Enable SSL Verification, if you have proper TLS setup to your git provider (recommended).
|
||||
5. For "events that trigger the webhook", just the push request is what post people want.
|
||||
6. Of course, make sure the webhook is "Active" and hit create.
|
||||
|
||||
## When does it trigger?
|
||||
|
||||
Your git provider will now push this webhook to Monitor on *every* push to *any* branch. However, your `Build`, `Repo`,
|
||||
Your git provider will now push this webhook to Komodo on *every* push to *any* branch. However, your `Build`, `Repo`,
|
||||
etc. only cares about a specific branch of the repo.
|
||||
|
||||
Because of this, the webhook will trigger the action **only on pushes to the branch configured on the resource**.
|
||||
|
||||
For example, if I make a build, I may point the build to the `release` branch of a particular repo. If I set up a webhook, and push to the `main` branch, the action will *not trigger*. It will only trigger when the push is to the `release` branch.
|
||||
For example, if I make a build, I may point the build to the `release` branch of a particular repo. If I set up a webhook, and push to the `main` branch, the action will *not trigger*. It will only trigger when the push is to the `release` branch.
|
||||
|
||||
## Procedure webhooks
|
||||
|
||||
Not all actions support webhooks directly, however for those that don't, they can still be triggered via webhook by using a Procedure. Just create a Procedure and configure it to run the action you are looking for, and create a webhook pointing to the Procedure.
|
||||
|
||||
Since Procedures don't specificy a particular branch it should listen for pushes on, this information
|
||||
must be put in the webhook payload url. Procedures use webhook payload urls of the form:
|
||||
|
||||
```
|
||||
<KOMODO_HOST>/listener/github/procedure/<PROCEDURE_ID>/<LISTEN_BRANCH>
|
||||
```
|
||||
|
||||
If the `<LISTEN_BRANCH>` is not provided, it will default to listening on the `main` branch.
|
||||
Reference in New Issue
Block a user