4 ms·

His main argument is that you need to template differently for different environments (dev/stage/prod) and cloud regions (us-west/us-east/emea/apac). This is a

• jaxxstorm 8y ago
  > It's a solved problem For who, exactly?
  • illumin8 8y ago
    For anyone using EC2 Parameter Store, a free service in AWS: > Parameters: > AMI: > Type: AWS::SSM::Parameter::Value<String> > Default: /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id Gives you the latest, fully patched Linux OS in any of 19 regions that you launch it in. Free K/V store that works really well for apps and custom parameters.
    • jaxxstorm 8y ago
      Well, that’s great for anyone using the EC2 parameter store, but isn’t really helpful for all those situations where you’re not. “This is not a problem for my specific set of use cases around AWS” is not a “solved problem”
• jrockway 8y ago
  Based on the appearance of Helm, this is probably referring to Kubernetes, which really does have per-environment things that can't be represented in any form other than namespaces. For example, you have an app running (that's a deployment in k8speak). You want network traffic to get to this app, so you set up a load balancer. The load balancer config needs to know the name of your app (or more precisely, a selector for "pods" that are created by the deployment), which will change between environments, so now there is that common variable that has to be updated in both places. That's a simple example but is why people are templating their k8s configs. Yes, you could work around it by giving every environment its own namespace and using the same set of objects in every environment (differing only by namespace, which should probably be in the file... but since you can't edit the files, you can pass it in to kubectl probably), but there are other cases where even that doesn't work. You do need some way of saying "this is the base configuration and this is what we change for staging and production". Helm is a way to do that, and a popular one, but it's pretty ugly. Hence this article.
  • illumin8 8y ago
    This is how you do it in AWS CloudFormation: Parameters: AMI: Type: AWS::SSM::Parameter::Value<String> Default: /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id That gives you the latest, fully patched base OS image no matter which of 19 regions you launch it in. Even hardcoding that in a K/V store is going to get outdated unless you manually update it. Parameters like this are great because you can simply write your code once and never have to update unless you're adding new functionality. All base parameters and external systems (APIs, etc) are parameterized and never need to get updated, except by your SaaS partners that update them for you.
• benmmurphy 8y ago
  I think his main argument is why are we using a text based templating when we can go up one step further and have language based templating. like why have: {"foo": "<%= bar %>"} when you could just have {"foo": bar} the problem with text based templating is the templating language has to make a decision about escaping and it is sometimes the wrong one. for example rebar used an erlang haml [at some point... maybe they fixed it :)] which meant it escaped html special characters by default. but this makes almost zero sense when generating erlang configuration files. i guess the reason that it is like this is because it is just easy and for most YAML/JSON/etc configuration files it is not a problem because you are basically doing static substitution or 'dynamic' substitution but with a safe range of characters. so the reason things are 'bad' is because the current solution works for 99% of the use cases and no-one wants to spend time fixing it when they could spend that time fixing a real problem. heh :/