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
2024-09-02 01:38:40 +03:00
committed by GitHub
parent 2463ed3879
commit 5fc0a87dea
429 changed files with 14351 additions and 7077 deletions

View File

@@ -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.