Show HN: Sanic – A Comprehensive CLI for Kubernetes(sanic.io)
sanic.io
Show HN: Sanic – A Comprehensive CLI for Kubernetes
https://sanic.io
38 comments
Hey HN!
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.
[1] https://github.com/distributed-containers-inc/sanic [2] https://github.com/distributed-containers-inc/sanic-site
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.
[1] https://github.com/distributed-containers-inc/sanic [2] https://github.com/distributed-containers-inc/sanic-site
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?
> 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?
Any particular reason you chose that name? I keep thinking about the meme by the same name
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
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 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.
Concurrent builds alone make this worthwhile while developing.
Looks good! Kubernetes has historically been a huge pain to deal with; If this smooths out the process I might use it for my next project.
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 .`
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])
[1] https://github.com/distributed-containers-inc/sanic-site/blo...
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])
[1] https://github.com/distributed-containers-inc/sanic-site/blo...
> ...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.
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.
[1] https://github.com/distributed-containers-inc/sanic-template...
[1] https://github.com/distributed-containers-inc/sanic-template...
I like the tutorial.
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
Sanic's promise is that your builds will be so fast -- that's why it's named after the character
Isn't that Sonic?
Sonic is a trademark so it was murkier to call it that, there's a popular image macro called "sanic" [1] which made a good enough alternative
[1] https://knowyourmeme.com/memes/sanic-hegehog
[1] https://knowyourmeme.com/memes/sanic-hegehog
Sanic is a meme version of Sonic that looks like a child's crude drawing.
There's also a Python web framework by the same name and inspiration.
Im very interested in trying this! Looks like the download page only supplies a linux binary at the moment: any plans to offer a Mac OS version too?
For what it's worth, I was able to build a Mac OS version locally.
For what it's worth, I was able to build a Mac OS version locally.
Go works really well with macos, I don't see why it wouldn't work. I'll likely officially support it once I set up a mac VM for CI
Many of the environment-specific functionality provided by this tool can be more declaratively achieved by kustomize (https://kubernetes.io/docs/tasks/manage-kubernetes-objects/k...) as well as direnv (https://direnv.net) by automatically running commands to change environment etc when changing directories.
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
I see. That’s also somehow solved by Skaffold. https://skaffold.dev/
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.
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.
The name is rather unfortunate as there is already a software project with that name: Sanic, Python async web framework.
https://github.com/huge-success/sanic
https://github.com/huge-success/sanic
Also the Sanic the Hedgehog meme: https://knowyourmeme.com/memes/sanic-hegehog
Pretty sure they're both based on the meme. Go fast and all that.
It makes a lot more sense with the web framework linked above. I don't see the connection with this new Sanic.
Yes. At first I thought they were related.
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.
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.
They are roughly in the same basket, as people using microframeworks are likely to deploy their apps on kubernetes.
That's a fair point.
I'm using an OpenDyslexic font and your page elements don't seem to recognize the bounding boxes of the text in this font.
Could you open an issue with the specific font and screenshots of the affected pages?
https://github.com/distributed-containers-inc/sanic-site/iss...
Thanks!
https://github.com/distributed-containers-inc/sanic-site/iss...
Thanks!
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.
Does it work with K3S?
- 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.
idk, maybe it's cool, but it seems complicated.