I think it's fine as long as they are not in the same basket (one is web framework, one is devops tool). If not, finding unique name is really hard. You have to use verbose name (Sanicotobarto, A CLI for Kubernetes) or use unicode (could you imagine Show HN: laughing-emoji laughing-emoji laughing-emoji web framework?).
I am writing this comment because everytime I think about a good short name (probably using animal's name), it's already been taken. So there's that.
Kustomize is the closest thing to an alternative to Sanic, but I've found it's hard to teach new developers how to read and use patches correctly, and it doesn't really solve the "build and push to a specific registry per environment" problem
skaffold.yaml has a notion of "profiles" that define a default registry per-environment. Like, you can have a local profile that doesn't push images (as it detects docker-for-desktop, or minikube etc), and a "prod" profile that specifies a registry for images to be pushed and kubectl manifests to be auto-applied with the updated image:tag.
At the startup I last worked at, we used a Docker/Kubernetes stack for our SaaS product.
We found the lack of environment / concurrent build support a huge bottleneck though, so I developed a tool to make it much easier to deploy kubernetes projects.
I recently open sourced it and launched it, take a look! [1]
The website itself is also using sanic and open source, in case you want an example [2]
Please let me know if you have any feedback! I'd love to know which features are most important to work on next.
This tool looks useful, but the first thing I see when I hit the landing page is this:
> Tired of kubernetes tools that don't prioritize user experience?
This is quite a loaded sentence. It ignores whatever reasoning there may be (design, resourcing, differences of opinion) behind the state of Kubernetes tooling, and even assumes that the tooling is bad, and assumes that you have the answer.
I'm all for simple, strong statements to pitch a product, but this instead feels adversarial, derogatory, and potentially naive.
I'm sure this is not your intention, so it would be a shame for this to be the first impression the community gets of Sanic.
Perhaps "Ready for the next evolution of Kubernetes tooling?" might be a bit more positive?
I might be a little slow here, but I don't think I totally understand the use-case.
The parallel docker build / pushing to a registry is definitely cool.
Isn't the parallel Kubernetes deployment the same as `kubectl apply -f .`?
My experience has always been: GitOps w/ version controlled yaml so when a deploy is triggered all the tests run, if that's successful then a sed is performed to replace some placeholder with the new image tags then it's just `kubectl apply -f .`
Take a look at the sanic-site project's deployment.yaml [1]: Since it's a go website, the yaml is written in go templates, but the goal is that you should choose whatever templating language you already use for your website
I've used sed in the past, but it's a huge hassle to do more complicated things (i.e., use different namespaces / taints / resource limits / ... per environment)
I disagree with the way kustomize and jsonnet approach this, learning a new templating language is almost never the right solution. As a bonus, sanic spits out exactly the files it applies so that you can easily find the error in your template without needing to go across multiple files
Finally, this allows you to volume mount your source code folder to avoid having to rebuild after every little change (see the "devmount" part in [1])
> ...but the goal is that you should choose whatever templating language you already use for your website
most common templating languages (especially textual templating languages like go's text/template lib) are not great at templating structures (yaml, json, etc.). you quickly run into indentation, escaping and similar problems.
> I disagree with the way kustomize and jsonnet approach this, learning a new templating language is almost never the right solution.
i've recently open sourced a tool ytt (https://get-ytt.io) that is yaml structure aware, to avoid problems mentioned above. i do agree that learning new tool/language is an overhead but it's been interesting to try to build a tool on top of common tech, yaml and python-like language (starlark), to ease the learning curve.
good to see that your tool allows integration with other templating tools.
If you'd like to integrate your templater with sanic, feel free to adapt the existing golang templater [1] and push your version to docker hub -- Let me know if you do, I'll maintain a list of available templaters.
Based on the name, color scheme and use of the infinity symbol (∞), I'm assuming the name is based off of this fella? https://www.google.com/search?q=sanic
There's a story there: I first worked on it because we had a bunch (20~) docker images to build in parallel, and the goal was to "build them fast" (we succeeded: builds from scratch went from ~40 mins to ~15 mins when combined with multi-stage builds)
I suppose it's the same reason there's a python HTTP server of the same name
Do you have any concerns about giving it the same name as the web framework? Sanic is one of the more popular Python web frameworks with over 12k stars on GitHub. I would guess that a significant portion of your potential users already associate the name with that established project. I'm not trying to police the name or anything, but it seems likely to cause confusion.
In practice I've found it's not really a big deal, because if you google "sanic" neither this project nor that one shows up. My users will search "sanic tool" or "sanic build" and their users will search "sanic web" or "sanic python"
I guess it's sub-optimal that there are two projects with the same name, but I grew too used to typing "sanic build" over the years to seriously consider renaming it
I immediately thought of the web framework as well, but who knows what will happen if this tool takes off. It's good to see that you had at least considered it and recognized it was sub-optimal.
Concurrent builds alone make this worthwhile while developing.
Nice tutorial and idea. Definitely like the focus on UX. I think that's an important aspect of any dev-centric tooling that often goes neglected, as has some of the lower level tooling around this in the past. IMO, Config and deployment management seems like one of those things where the barrier to entry is low enough that each opinionated developer reinvents it rather than work within the constraints of some existing tool.
some honest feedback from someone avidly using K8s since 1.1.
- im not sure what k8s problem this is solving. the first thing your talking about is building docker images, which k8s has nothing to do with.
- are the k8s config files accessible? where are they?
- the sanic.yaml file looks like yet another DSL i need to learn. how is that simplifying things for me? i have no idea what your example config file is doing either, none of it seems to obviously map to anything in kubernetes.
This feels like more of a docker build cli than a kubernetes cli. also, does this actually create clusters? like kops does? if not, this just seems to add a tool to the toolchain rather than simplifying anything.
https://github.com/huge-success/sanic