8 ms·
Show HN: Deploy to K8s without YAML using ShuttleOps
- x1ph0z 6y agoGreat stuff!
- hustle007 6y agoI agree
- verdverm 6y agoI keep Yaml/Helm manifests and templates in git so we can track them. Does this support GitOps based workflows?
- hustle007 6y agoyes, I would like to know that too
- gscho 6y agoHi! Greg from ShuttleOps here. We currently do not support import of existing YAML and helm manifests but that is certainly on our roadmap
- verdverm 6y agoDo you support maintaining git interoperability, not just importing, but tracking with vcs into the future. Does your tool work with GitOps methodology?
- gscho 6y agoSupporting pre-existing Helm Charts and k8s manifests as artifacts is still on the roadmap, and that needs to be achieved first before we can achieve a GitOps philosophy like Weave Cloud. Ps: Hofstadter looks cool!
- piaste 6y ago> and that needs to be achieved first before we can achieve a GitOps philosophy like Weave Cloud. I think "[automatically] export all generated YAML templates and CLI commands as a git commit / git patch" is something that may be worth supporting even without the import of existing templates. First, it should be much easier, since you're already doing the hard work of generating those strings. Exporting them as a git patch could be as straightforward as keeping an internal repo folder and running git format-patch. Second, it would make for a much easier sell to greenfield projects (which don't need import), because if your GUI tool can export back to the usual YAML code, I might consider using it knowing that I can 'eject' at any time, or that if the generated YAML suffers from any ShuttleOps bugs I can at least fix them and apply the fixed YAML manually while I wait for a bugfix.
- verdverm 6y agoThanks, we use Cuelang as the core UX for a developer focused "high code" paradigm. https://hofstadter.io https://hofstadter.io
- deleted 6y ago[deleted]
- hustle007 6y agoAwesomeness!
- foxtr0t 6y agoWe've gone full circle: 1. Pre-kub: orchestration is manual through AWS EC2 ui 2. Kub: orchestration is automated and configuration is treated as code (YAML, JSON, proto, whatever) and kept in revision control just like source code 3. Post-kub: orchestration is manual through a ui In all seriousness I'm sure this is useful in limited cases, but for most the right answer isn't some fancy UI, its middleware or some layer on top of kubernetes that allows you to automate away the toil-y parts of YAML, but keep the flexibility. EDIT: line breaks.
- jchw 6y agoWhat I like about Kubernetes is that it’s a platform you get things like exponential backoff, replication, liveness and health checking and so forth as part of the platform, and plugins for metric collection and monitoring are fairly standard. These are things I don’t even feel most PaaS have done a great job on across the board, so I can certainly see the appeal of having Kubernetes under the hood.
- stevepike 6y agoYeah, there's a whole category of apps that run on heroku with maybe 10 dynos tops that could definitely be deployed on kubernetes with manual / web ui-based configuration.
- k__ 6y agoPaaS came before K8s, it's the minimum that K8s is better than PaaS.
- jchw 6y agoI actually don’t see why a PaaS couldn’t do all of this better. Especially at larger companies, where containers and monitoring have been the norm internally forever, it is unclear why PaaS offerings still feel primitive... maybe there is some technology limitation here. Edit: disclaimer, I have not used a PaaS service in a couple years.
- 6y ago
- bamazizi 6y agoIs this like a visual/gui Terraform or Ansible?
- gscho 6y agoHi! ShuttleOps allows you to create workflows for deploying to Kubernetes without writing YAML manifest files. In that way you could consider it a visual/gui for the terraform kubernetes provider, sure!
- simonw 6y agoDo I get a revision log of exactly what changed when?
- gscho 6y agoThanks for the question! Currently you can view what has changed on the pipeline executions page. Having a pre-deployment planning phase is on the roadmap as well.
- xgbi 6y agoBe careful: with Github auth, the redirection directs you to a non-HTTPS version of their app. The Github token might leak at that point... EDIT: I don't even know how it is possible, this is an Oauth2 Flow and should never redirect to a non HTTP URL from Github. Also: the fact that shuttleio doesn't have hsts or at least a 301 to HTTPS from HTTP is not brilliant either.
- brtknr 6y agoYAML is the best part about deploying stuff to K8s, hardly a problem waiting to be solved IMO.
- postalrat 6y agoI'm not a k8s expert. Just touched it a bit here and there. And IMO yaml is fine but the problem is you often need yaml templates. I feel like projects like helm are in the templating html with php days. But instead of html+php you get yaml+go. Something better must be right around the corner because people have been solving similar problems for years.
- peterwwillis 6y agoNo offense intended, but a generic marketing elevator pitch for a technical product makes me grumpy. I want to see the technical details, but I'm not signing up for your website just to dig for them. So this creates a missed opportunity where people like me will now not share it with their team.
- gscho 6y agoNone taken! This is great feedback.
- realshadow 6y agoWhat makes developers to lean towards YAML when JSON and JSON5 are more developer friendly? I personally hate YAML config files.
- brown9-2 6y agoHow do you place comments in a a JSON file?
- realshadow 6y agoJSON5 does support comments
- verdverm 6y agoComments is one, and while JSON5 seems to support them, it does not look widely adopted or maintained. I do not like YamHell either, but prefer to JSON for readability I'm using Cuelang these days, Dhall is another option
- dpc_pw 6y agoThere's fundamentally no difference between them. They are both crappy tools for humans to write anything in and are better as a tools for machines to exchange data, which is accidentally human-readable in case debugging is neccessary.
- barrkel 6y agofoo: | bar baz This quote style in YAML is its best feature, IMO. It's not massively useful for k8s outside of config maps, but for other uses of YAML, it's great for embedding snippets of other languages that would otherwise need quoting.
- realshadow 6y agoKeeping up with indenion is a pain the ass when your config file is large
- 6y ago
- Regenschirm 6y agoUnfortunate is the pricing. Its a no go for me and a small business to use this. 250 is just too much with infra costs at 200 and free doesn't give us any guarantee at all.
- zxienin 6y agoDevelopers directly touching k8s are hardly low/no code targets. So this doesn’t seem well placed. Unless this imagines a world where devs throw over the fence and ops team is bunch of citizen users.
- peterwwillis 6y agoI mean, in an ideal world, it should be a low/no-code target. In the sense that you should be able to manipulate K8s as a dumb user to make it do what you need to do, when you need it, without somebody in your way. A company called QualiSystems made some software called CloudShell that was basically a web UI to creating architectural diagrams and hooking each component up to code. There's drivers pre-made for each piece. You connect the pieces, click "Deploy app", and it builds everything you need, deploys your app, runs tests, tears it all down after, etc. The devs literally assemble the whole system in a UI and then just "run" the whole thing. Ops is essentially no longer needed except to write drivers and define policy/governance. This is what we need more of. Instead, we have Ops teams who are in charge of infrastructure, and spend weeks writing custom Terraform modules and CI/CD solutions just to get some basic infrastructure up. Oh, you need a change? Sure, it'll just be another day full of writing and testing code for me to make that one tiny change in infra. It's ridiculous. Devs should be able to do this work themselves as needed, without waiting for someone else to do it for them. The same idea applies to K8s. Personally I think "deploying to K8s without YAML" is not a challenging problem for most teams as there are lots of different solutions to that. Where they actually need help is in gaining agency and independence, and to do that we need friendly user interfaces to automated guide-rails, so if the dev wants to deploy a new stack, nothing is getting in their way, but the end result is according to a corporate standard.
- zxienin 6y agoThere’s healthy level of valid pain point you’re citing (custom terraform module, unnecessary long change cycles). And still, LC/NC isn’t convincing here. Deployment is one piece. Day 2 ops another. Deployment: shouldn’t be over complex for devs. K8s declarative design is actually supportive of this. Any team which creates undue complexity here is incompetent or has wrong leadership in place. Day 2 ops is another beast. You get errors, things break, unexpected happens. You can minimize that by architecting a healing, resilient sub-system. But never eliminate it entirely. Expert humans need to step in when it breaks. Not dumb users. Need of ops team doesn’t go away. And if this team exists, LCNC is not a fit. If you have to abstract something, do it darn good. If you can’t, don’t step in my way.
- lawrenceduk 6y agoI think we run about $100,000/year of this in production. Ouch.
- deleted 6y ago[deleted]