113 lines
5.4 KiB
Markdown
113 lines
5.4 KiB
Markdown
# Frequently Asked Questions
|
|
|
|
## Why Katenary?
|
|
|
|
The main author[^1] of Katenary is a big fan of Podman, Docker and makes a huge use of Compose. He uses it a lot in his
|
|
daily work. When he started to work with Kubernetes, he wanted to have the same experience as with Docker Compose.
|
|
He wanted to have a tool that could convert his `docker-compose` files to Kubernetes manifests, but also to Helm charts.
|
|
|
|
Kompose was a good option. But the lacks of some options and configuration for the output Helm chart made him think
|
|
about creating a new tool. He wanted to have a tool that could generate a complete Helm chart, with a lot of options
|
|
and flexibility.
|
|
|
|
[^1]: I'm talking about myself :sunglasses: - Patrice FERLET, aka Metal3d, Tech Lead and DevOps Engineer at Klee Group.
|
|
|
|
## What's the difference between Katenary and Kompose?
|
|
|
|
[Kompose](https://kompose.io/) is a very nice tool, made by the Kubernetes community. It's a tool to convert
|
|
`docker-compose` files to Kubernetes manifests. It's a very good tool, and it's more mature than Katenary.
|
|
|
|
Kompose is able to generate Helm charts, but [it could be not the case in future releases](https://github.com/kubernetes/kompose/issues/1716) for several reasons[^2].
|
|
|
|
[^2]:
|
|
The author of Kompose explains that they have no bandwidth to maintain the Helm chart generation. It's a complex
|
|
task, and we can confirm. Katenary takes a lot of time to be developed and maintained. This issue mentions Katenary as
|
|
an alternative to Helm chart generation :smile:
|
|
|
|
The project is focused on Kubernetes manifests and proposes to use "Kustomize" to adapt the manifests. Helm seems to be
|
|
not the priority.
|
|
|
|
Anyway, before this decision, the Helm chart generation was not what we expected. We wanted to have a more complete
|
|
chart, with more options and more flexibility.
|
|
|
|
> That's why we decided to create Katenary.
|
|
|
|
Kompose didn't manage to generate a values file, complex volume binding, and many other things. It was also not able
|
|
to manage dependencies between services.
|
|
|
|
> Be sure that we don't want to compete with Kompose. We just want to propose a different approach to the problem.
|
|
|
|
Kompose is an excellent tool, and we use it in some projects. It's a good choice if you want to convert
|
|
your `docker-compose` files to Kubernetes manifests, but if you want to use Helm, Katenary is the tool you need.
|
|
|
|
## Why not using "one label" for all the configuration?
|
|
|
|
That was a discussion I had with my colleagues. The idea was to use a single label to store all the configuration.
|
|
But, it's not a good idea.
|
|
|
|
Sometimes, you will have a long list of things to configure, like ports, ingress, dependencies, etc. It's better to have
|
|
a clear and readable configuration. Segmented labels are easier to read and to maintain. It also avoids having too
|
|
many indentation levels in the YAML file.
|
|
|
|
It is also more flexible. You can add or remove labels without changing the others.
|
|
|
|
## Why not using a configuration file?
|
|
|
|
The idea was to keep the configuration at a same place, and using the go-compose library to read the labels. It's
|
|
easier to have a single file to manage.
|
|
|
|
By the way, Katenary auto accepts a `compose.katenary.yaml` file in the same directory. It's a way to separate the
|
|
configuration from the compose file. It uses
|
|
the [overrides' mechanism](https://docs.docker.com/compose/multiple-compose-files/merge/) like "compose" does.
|
|
|
|
## Why not developing with Rust?
|
|
|
|
Seriously...
|
|
|
|
OK, I will answer.
|
|
|
|
Rust is a good language. But, Podman, Docker, Kubernetes, Helm, and mostly all technologies around Kubernetes are
|
|
written in Go. We have a large ecosystem in Go to manipulate, read, and write Kubernetes manifests as parsing
|
|
Compose files.
|
|
|
|
> Go is better for this task.
|
|
|
|
There is no reason to use Rust for this project.
|
|
|
|
## Any chance to have a GUI?
|
|
|
|
Yes, it's a possibility. But, it's not a priority. We have a lot of things to do before. We need to stabilize the
|
|
project, to have a good documentation, to have a good test coverage, and to have a good community.
|
|
|
|
But, in a not so far future, we could have a GUI. The choice of [Fyne.io](https://fyne.io) is already made, and we
|
|
tested some concepts.
|
|
|
|
## I'm rich (or not), I want to help you. How can I do?
|
|
|
|
You can help us in many ways.
|
|
|
|
- The first things we really need, more than money, more than anything else, is to have feedback. If you use Katenary,
|
|
if you have some issues, if you have some ideas, please open an issue on the [GitHub repository](https://github.com/Katenary/katenary).
|
|
- The second thing is to help us to fix issues. If you're a Go developer, or if you want to fix the documentation,
|
|
your help is greatly appreciated.
|
|
- And then, of course, we need money, or sponsors.
|
|
|
|
### If you're a company
|
|
|
|
We will be happy to communicate your help by putting your logo on the website and in the documentation. You can sponsor
|
|
us by giving us some money, or by giving us some time of your developers, or leaving us some time to work on the project.
|
|
|
|
### If you're an individual
|
|
|
|
All donators will be listed on the website and in the documentation. You can give us some money by using
|
|
the [GitHub Sponsors]()
|
|
|
|
All main contributors[^3] will be listed on the website and in the documentation.
|
|
|
|
> If you want to be anonymous, please tell us.
|
|
|
|
[^3]:
|
|
Main contributors are the people who have made a significant contribution to the project. It could be code,
|
|
documentation, or any other help. There is no defined rules, at this time, to evaluate the contribution.
|
|
It's a subjective decision.
|