mirror of
https://github.com/moghtech/komodo.git
synced 2026-05-01 07:36:16 -05:00
5fc0a87dea
* 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
62 lines
3.6 KiB
Markdown
62 lines
3.6 KiB
Markdown
# Configuration
|
|
|
|
Komodo just needs a bit of information in order to build your image.
|
|
|
|
### Provider configuration
|
|
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/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,
|
|
or in the periphery configuration of the building server.
|
|
|
|
### Docker build configuration
|
|
|
|
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`
|
|
|
|
The dockerfile's path is given relative to the build directory. So if your build directory is `build/directory` and the dockerfile is in `build/directory/Dockerfile.example`, you give the dockerfile path simply as `Dockerfile.example`.
|
|
|
|
### Image 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.
|
|
|
|
When connecting a build to a deployments, the default behavior is for the deployment to inherit the registry configuration from the build.
|
|
In cases where that account isn't available to the deployment, another account can be chosen in the deployment config.
|
|
|
|
:::note
|
|
In order to publish to the Github Container Registry, your Github access token must be given the `write:packages` permission.
|
|
See the Github docs [here](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-with-a-personal-access-token-classic).
|
|
:::
|
|
|
|
### Adding build args
|
|
|
|
The Dockerfile may make use of [build args](https://docs.docker.com/engine/reference/builder/#arg). Build args can be passed using the gui by navigating to the `Build Args` tab in the config. They are passed in the menu just like in the would in a .env file:
|
|
|
|
```
|
|
BUILD_ARG1=some_value
|
|
BUILD_ARG2=some_other_value
|
|
```
|
|
|
|
Note that these values are visible in the final image using `docker history`, so shouldn't be used to pass build time secrets. Use [secret mounts](https://docs.docker.com/engine/reference/builder/#run---mounttypesecret) for this instead.
|
|
|
|
### Adding build secrets
|
|
|
|
The Dockerfile may also make use of [build secrets](https://docs.docker.com/build/building/secrets).
|
|
|
|
They are configured in the GUI the same way as build args. The values passed here can be used in RUN commands in the Dockerfile:
|
|
```
|
|
RUN --mount=type=secret,id=SECRET_KEY \
|
|
SECRET_KEY=$(cat /run/secrets/SECRET_KEY) ...
|
|
```
|
|
|
|
These values will not be visible with `docker history` command. |