21–30 of 57 posts
Be 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.
Earlier quoted context omitted.
What 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.
PaaS came before K8s, it's the minimum that K8s is better than PaaS.
Edit: disclaimer, I have not used a PaaS service in a couple years.
We'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 lay…
YAML is the best part about deploying stuff to K8s, hardly a problem waiting to be solved IMO.
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.
We'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 lay…
What 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.
Further, K8s exposes an YAML interface because it is relatively human readable and of course is machine readable. I'm sure the k8s community encourages users to build on top of this. Want to really do code as config? Write a nice DSL in your favorite scripting language to produce these YAMLs. Submit that as source. You've now automated away the vast majority of toil related to k8s YAML config, because your code can be:
1. modular by design
2. tested
3. tracked as code
etc etc
Earlier quoted context omitted.
Do you support maintaining git interoperability, not just importing, but tracking with vcs into the future. Does your tool work with GitOps methodology?
Supporting 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!
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.
I personally hate YAML config files.
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.
Be 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.
This should be the top comment until remedied. This is super dangerous.
And contacted ShuttleIO by mail.
This could be ugly, Shuttle asks for broad permissions on Github.