Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tanka: Our way of deploying to Kubernetes

grafana.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Tanka: Our way of deploying to Kubernetes

#111

Post by nojvek »

MuffinFlavored wrote: post #104
cbushko wrote: post #97

I spent about 6 months using helm and made around 20+ charts for the services. In the end we got rid of it and replaced it with Terraform. If your infrastructure is 100% kubernetes then I think helm is great. Our infrastructure is not. We have databases, dns, buckets, service accounts and more so we were splitting our setup between terraform and helm. Passing data between the two tools was going to be a pain. We foll…

Why don't more people use Terraform? I think Terraform is amazing. I wanted to make containerpen.io for docker-compose + dockerfiles + terraform files to compete with codepen.io

My experience with Terraform was suboptimal. At least with GCS, it would do weird things and mess up permissions.

I found the documentation and it’s special syntax a pain. Just give me json with json schemas defines somewhere so vscode can give me great code completion and I can templatize as necessary

Re: Tanka: Our way of deploying to Kubernetes

#112

Post by blandflakes »

0xbadcafebee wrote: post #87

I'd like to request that nobody else make any more damn infrastructure tools that require writing code in order to use it, or require reading six manuals. I don't want to spend the rest of my life writing and editing glue and cruft, or spending two weeks researching and writing elaborate config files by hand just to make some software run. It's like the infrastructure version of fine woodworking - building dovetails…

I'm with you in that these tools are incomplete and insufficiently abstract - what would you like instead? Just a sufficiently robust GUI or CLI surface area?

Re: Tanka: Our way of deploying to Kubernetes

#113

Post by 616c »

MuffinFlavored wrote: post #104
cbushko wrote: post #97

I spent about 6 months using helm and made around 20+ charts for the services. In the end we got rid of it and replaced it with Terraform. If your infrastructure is 100% kubernetes then I think helm is great. Our infrastructure is not. We have databases, dns, buckets, service accounts and more so we were splitting our setup between terraform and helm. Passing data between the two tools was going to be a pain. We foll…

Why don't more people use Terraform? I think Terraform is amazing. I wanted to make containerpen.io for docker-compose + dockerfiles + terraform files to compete with codepen.io

Because the DSL is complicated and you encounter weird edge cases even for not so complicated things.

Common, almost ubiquitous in my circles, and often reliable are things I would say about it, painless is not. I was a bigger fan until using it daily focused on a project for a month on it more than anything else.

I feel this strongly enough I'm looking at AWS CDK and troposphere, likely to learn I suck at writing my own imperative style terraform and to be more thankful. Lol

Re: Tanka: Our way of deploying to Kubernetes

#114

Post by tilolebo »

0xbadcafebee wrote: post #87

I'd like to request that nobody else make any more damn infrastructure tools that require writing code in order to use it, or require reading six manuals. I don't want to spend the rest of my life writing and editing glue and cruft, or spending two weeks researching and writing elaborate config files by hand just to make some software run. It's like the infrastructure version of fine woodworking - building dovetails…

What's your example of an infrastructure tool you like?

Re: Tanka: Our way of deploying to Kubernetes

#115

Post by MuffinFlavored »

nojvek wrote: post #111
MuffinFlavored wrote: post #104

Earlier quoted context omitted.

Why don't more people use Terraform? I think Terraform is amazing. I wanted to make containerpen.io for docker-compose + dockerfiles + terraform files to compete with codepen.io

My experience with Terraform was suboptimal. At least with GCS, it would do weird things and mess up permissions. I found the documentation and it’s special syntax a pain. Just give me json with json schemas defines somewhere so vscode can give me great code completion and I can templatize as necessary

> Just give me json with json schemas defines somewhere so vscode can give me great code completion and I can templatize as necessary

Is there something that does this in the wild?

Re: Tanka: Our way of deploying to Kubernetes

#117

Post by markbnj »

ithkuil wrote: post #106
markbnj wrote: post #101

Earlier quoted context omitted.

That's the values file. The actual manifest templates are just as horrifyingly impressive :). https://github.com/helm/charts/tree/master/stable/prometheus...

One of the main problems with helm IMO is that it effectively turns the values.yaml file in a structure that almost mirrors the manifests themselves, and the biggest problem of that is hidden in the word "almost": there are many subtle ways this mapping can be done, including subtle or not so subtle field naming/spelling differences.

Yeah absolutely, the multiple layers of indirection you can end up with are frustrating for back end engineers trying to understand how a thing got deployed the way it did. For our stuff just patching the environment in as a yaml block is way more comprehensible. But then when you want to let people one-line a complete elasticsearch cluster install helm has that power if you're willing to commit to it.

Re: Tanka: Our way of deploying to Kubernetes

#118

Post by ithkuil »

markbnj wrote: post #117
ithkuil wrote: post #106

Earlier quoted context omitted.

One of the main problems with helm IMO is that it effectively turns the values.yaml file in a structure that almost mirrors the manifests themselves, and the biggest problem of that is hidden in the word "almost": there are many subtle ways this mapping can be done, including subtle or not so subtle field naming/spelling differences.

Yeah absolutely, the multiple layers of indirection you can end up with are frustrating for back end engineers trying to understand how a thing got deployed the way it did. For our stuff just patching the environment in as a yaml block is way more comprehensible. But then when you want to let people one-line a complete elasticsearch cluster install helm has that power if you're willing to commit to it.

I found my personal sweet spot in kubecfg, which allows me to override the fields I need (without having to know which one advance) and when needed it can do more advanced stuff such as variables, expressions, loops, etc which allow one-line complete elastic search cluster-like scenarios

Re: Tanka: Our way of deploying to Kubernetes

#119

Post by peterwwillis »

blandflakes wrote: post #112
0xbadcafebee wrote: post #87

I'd like to request that nobody else make any more damn infrastructure tools that require writing code in order to use it, or require reading six manuals. I don't want to spend the rest of my life writing and editing glue and cruft, or spending two weeks researching and writing elaborate config files by hand just to make some software run. It's like the infrastructure version of fine woodworking - building dovetails…

I'm with you in that these tools are incomplete and insufficiently abstract - what would you like instead? Just a sufficiently robust GUI or CLI surface area?

For example, let's say I want something to "build infrastructure". That's really way too generic to be useful.

What I actually want is something to create a cluster in AWS to run my app, or "create me a Fargate ECS cluster using R53, ACM, ALB, ECR, Lambda, CodeBuild, CloudWatch, SG, VPC, and IAM". If I feed that thing my AWS account's root credentials, it should first go through a list of default variables, explaining each to me and why I might want to change them. Then it should just create all of the above for me, and probably save it all as code. Next, I create a repository with my app and a Dockerfile. I then run a "hook up my git repo webhook and deploy my app right now" script, passing it my github creds. That should create a webhook into CodeBuild where my app is turned into a container, pushed to ECR, and then deployed into the Fargate container, as well as creating any CloudWatch alerts needed.

That's what I call a "product solution": an opinionated, complete solution that does everything I need for me, with a very light user interface and guidance on how to use it. Probably 95% of the above is two custom Terraform modules and some glue, and I should only have to answer like three questions by default.

If Terraform itself shipped with the above complete solution, that would be what I'm looking for. But I'm not aware of a catalog of solutions like that. Occasionally random people will publish partial modules on GitHub, but those usually need more modules and glue to actually work. So I'm basically looking for "no assembly required" solutions with the option to modify them later.

Re: Tanka: Our way of deploying to Kubernetes

#120

Post by alsoh »

cbushko wrote: post #97

I spent about 6 months using helm and made around 20+ charts for the services. In the end we got rid of it and replaced it with Terraform. If your infrastructure is 100% kubernetes then I think helm is great. Our infrastructure is not. We have databases, dns, buckets, service accounts and more so we were splitting our setup between terraform and helm. Passing data between the two tools was going to be a pain. We foll…

We bootstrap tf with a short go script then use terraform for until the cluster runs. Then argocd takes over.

I really don't like how TF holds it state and it is errorpron. Allone how you have tto keep tf version in sync feels wrong.

The k8s support did not take us far. We had some kubectl script and it doesn't feel like a first class citizen. I wouldn't bet on tf for k8s.

I do love argocd. Great product.

Post reply on HN