301–310 of 315 posts
Earlier quoted context omitted.
Unfortunately last I checked, pulumi only offers state locking with their paid service. If you want to self-host you have to implement it yourself, which seems like a non-starter for a lot of people.
This was addressed a couple months ago in https://github.com/pulumi/pulumi/pull/2697
Please give me a vim plugin that allows me to easily move through terraform files as opposed to being forced to grep for relationships. As it stands I hate dealing with terraform because it is horrifyingly undiscoverable.
This has less to do with vim than with Terraforms poor LSP support. Vim/Neovim has had LSP support for some time with plugins and now built in natively. I use COC vim as it's the fastest to get started and I rarely have to do much config as it's based on VSCode and comes with sane bindings for go-to-def, refactoring and more. https://github.com/neoclide/coc.nvim https://github.com/prabirshrestha/vim-lsp https://githu…
Do those projects allow me to follow a user defined variable to its definition?
Earlier quoted context omitted.
> You can feed JSON to Terraform however this falls over if you need dependencies for output values This is what I've started doing with Jsonnet for generation, and also exactly why I've stopped doing it.
I'm not sure I follow exactly what you're missing. `${aws_instance.example.x}` as a string value creates the same dependency as it would via HCL when used with JSON.
Earlier quoted context omitted.
But at the end of the day your infrastructure is essentially data not code. Your infrastructure is permanent, it exists even if it isn't being used it has inertia. At the end of the day your "infrastructure" is really just an entry in a database of a cloud provider, it is data not code. I think we are seeing things come full circle again where people are finding the limitations of declarative infrastructure tools and…
Side tangent, but I'm curious as to why you list Ansible as imperative, when it seems to be declarative in how you configure a module? Or is this a case of scope? (At the level of a single ansible module, it's config is declarative, but runbooks/roles are imperative? Is it the variable substitution/loop mechanics that make it imperative?)
So, you are basically saying "do this, do that, then do that".
In a declarative model, you would say "this is how the end result should look" and the tool would then go off and make that happen, in whatever order its scheduling tools would say.
Sort of the difference between Rust on one side, and Prolog on the other (yes, it is possible to get a specific flow of instructions in Prolog, but it is much easier to let the prolog interpreter/compiler to Just Make It Happen Somehow).
FWIW, Puppet gets closer to a declarative model, but unfortunately, the last version I played around with seriously was actually quite bad at inferring ordering on its own, so a LOT of work ended up going into "well, A has to happen before B, so let us string a dependency here".
Terraform is such an underappreciated tool. It seems like so much of the hate surrounds HCL1 (back in Terraform before 0.12) and doesn't reflect modern Terraform. For example, after introducing `for_each` and dynamic blocks, it's possible to nearly entirely ditch variables files and local modules, and just add more infrastructure by editing a local YAML file. The only variables your Terraform code should have should…
> Terraform is such an underappreciated tool Are you kidding? It's the go to tool even for people who are brand new to IaaC. If anything I would say CloudFormation is underappreciated a lot of reasons why TF was created were fixed almost a decade ago. TF users are still citing those things as the reason why they use TF without ever using it.
Earlier quoted context omitted.
I looked at Cue and I don't understand what problem it solves. It certainly doesn't (seem) to solve the problem of DRYing up verbose YAML, or at least it's missing any notion of a function. "hey, these YAML blobs are all mostly the same, but they vary based on a couple of parameters--I should write a function that takes those parameters and outputs the right YAML object" ^ This is the #1 thing that the high-level lan…
CUE's philosophy is to wrap code in data, not data in code, as learned from the major configuration systems at Google. Being a logical language, rather than telling the computer what to do, you state facts and it verifies that you are correct. It is also intentionally not Turing complete do that you cannot program in CUE. CUE is gaining traction while still being young and changing. Grafana is adopting it for validat…
After 6 months outside Google, I desperately wished for BCL/GCL to be everywhere, because all other config languages were just plain broken. And more annoyingly, there's no better way to describe it than "I have seen better, just trust me".
CUE seems to be a step forward. Flabbergast looked like it might have been a contender. The latter is DEFINITELY inspired by BCL/GCL.
At some point, I will have to sit down with CUE and try to re-implement the "perfect little horror" in it (it should be impossible IFF CUE is not Turing-complete, but it actually turns out that there are edge cases of configuration where you want that Turing-completeness).
Earlier quoted context omitted.
Side tangent, but I'm curious as to why you list Ansible as imperative, when it seems to be declarative in how you configure a module? Or is this a case of scope? (At the level of a single ansible module, it's config is declarative, but runbooks/roles are imperative? Is it the variable substitution/loop mechanics that make it imperative?)
In Ansible, you declare a set of actions, that are then performed, one by one. Occasionally being skipped, if a certain condition holds true. So, you are basically saying "do this, do that, then do that". In a declarative model, you would say "this is how the end result should look" and the tool would then go off and make that happen, in whatever order its scheduling tools would say. Sort of the difference between Ru…
in Ansible, you say "make sure these packages are installed" and they'll be installed as needed, to match that state, or ignored if already there.
Even the file level stuff you can say "make sure this line is in the file" and it either adds it or says "nope, that's already in there".
Is it that there's modules that aren't declarative? Sort of the esoteric ones to poke specific cloud infrastructure (though even the few of those I looked at seemed to be declarative if needed).
Earlier quoted context omitted.
My problem with this approach is that it's still too much "infrastructure as data" and not "infrastructure as code." Moving infrastructure data into flat files is not a clear-cut win over having it in a database - you get easier version control with external tools like git, but you everything that makes a database a joy to work with instead of flat files, like schema validation and easy queries, etc. Things like for_…
But at the end of the day your infrastructure is essentially data not code. Your infrastructure is permanent, it exists even if it isn't being used it has inertia. At the end of the day your "infrastructure" is really just an entry in a database of a cloud provider, it is data not code. I think we are seeing things come full circle again where people are finding the limitations of declarative infrastructure tools and…
It's also a false dichotomy IMO that configuration files are the only declarative alternative to imperative tools like Salt/Ansible. You can have declarative code too: my laptop is running NixOS and its system state is defined in code (in a purpose-built language that looks much like a config file).
So really I think there are three approaches, not two, each with upsides and downsides which keep us all ping-ponging between them:
1. Config files are ideal for simple use cases, but a mess for complex ones 2. General-purpose programming languages are completely flexible, but allow you to create a huge unmaintainable mess 3. Dedicated declarative languages constrain you enough to mostly provide the best of both config files and code, but then you have to learn a whole new language, one which was probably conceived hastily (I find the Nix language awful honestly)
Some people need arbitrary computations to define their infrastructure, so I think pure config files are a non-starter from a purist's perspective. But, so far we haven't been able to come up with a programming language for infrastructure that isn't a mess to use.
Earlier quoted context omitted.
Not sure if this official guidance is a 'horrific hack' but there are official AWS guidance on how to do this: https://aws.amazon.com/blogs/infrastructure-and-automation/m...
Thank you, and yes in my books that's a horrific hack and too much effort compared to the 5 lines of code I just added to Terraform to get the job done.
I believe in the Terraform way of doing things. A lot of other people dislike the Terraform language, and then they use Pulumi because it allows them to write infrastructure in Python or JavaScript. But I specifically DO NOT WANT my company's infrastructure to be written in a Turing-complete dynamically-typed language. I believe the Terraform language is safer. However, one thing I don't like about Terraform is that…