c4k-common provides the foundation for all our c4k modules.
There are many comparable solutions for creating c4k deployments like `helm` or `kustomize`.
`kustomize` is great to manage your k8s manifests by splitting huge files into handy parts.
`helm` is great because of its large community.
It is now possible to generate a working prometheus monitoring file in yaml format.
Your config.edn and your auth.edn should at least contain the following fields:
Why do we need another one? Why do you continue the reading here?
config.edn - minimal example
We combine the simplicity of `kustomize` with the ability for doing real programming as software developers would do.
```clojure
{:k3s-cluster-name "your-cluster-name"
:k3s-cluster-stage :prod
:grafana-cloud-url "your-url"}
```
Following the principle
"Use programming language for programming"
we are clearly enjoy writing kubernetes manifests with clojure. In comparison with helms templating, things such as business logic, conventions, input validation, versions, dependencies and reuse are much easier and much more reliable to implement.
By the way, c4k means "convention for kubernetes".
### Features
c4k-common supports the following use cases:
#### Target Cli and Web Frontend
auth.edn - minimal example
Set up your cli as follows
```clojure
{:grafana-cloud-user "user"
:grafana-cloud-password "password"}
```
(defn -main [& cmd-args]
(uberjar/main-common
"c4k-forgejo" ;; name of your app
core/config? ;; schema for config validation
core/auth? ;; schema for credential validation
core/config-defaults ;; want to set default values?
core/k8s-objects ;; the function generate the k8s manifest
cmd-args ;; command line arguments given
))
```
The full example can be found here: https://repo.prod.meissa.de/meissa/c4k-forgejo/src/branch/main/src/main/clj/dda/c4k_forgejo/uberjar.clj
You can create your manifest as web-application also (using page local js without server interaction)
There are many comparable solutions for creating c4k deployments like helm or kustomize. Why do we need another one?
* We like the simplicity of kustomize. Yaml in, yaml out, the ability to lint the result and the option to split large yaml files into objects. But a simple overwriting per environment may not be enough ...
* We like helm packages. A package encapsulates the setup for an application. On the one hand, but on the other hand we don't like the idea of having to program and debug in a template language. We can program much better in real programming languages.
#### Inline k8s resources for versioning & dependencies
Our convention 4 kubernetes c4k-* tools combine the advantages of both approaches:
* Packages for one application
* Programming in clojure
* yaml / edn as input and output, no more magic
* good validation, integration as api, cli or in the browser
We inline all resources used in our libraries & applications. You can generate k8s manifests everywhere without additional external dependencies.
## Usage
In case of
* java: Resources are included in the jar-file out of the box (see https://repo.prod.meissa.de/meissa/c4k-forgejo/src/branch/main/project.clj#L13).
* js: With a slim macro call we inline resources to the resulting js file (see https://repo.prod.meissa.de/meissa/c4k-forgejo/src/branch/main/src/main/cljc/dda/c4k_forgejo/forgejo.cljc#L72-L74)
* native: On native builds we inline resources also (see https://repo.prod.meissa.de/meissa/c4k-forgejo/src/branch/main/build.py#L126)
c4k-common provides the basic functionality for our c4k-modules.
#### Work on structured Data instead flat Templating
## Refactoring & Module Overview
To keep things simple, we do also templating. But we convert given k8s resources to structured data.
This allows us to have more control and do unit tests: