The Terraform example doesn't seem particularly useful to me, as something that runs Terraform would be on the CI side. I don't need to worry about dependencies locally or anywhere else because it should never ever be ran anywhere but the CI server, which we would steward over.
The AMI part of it I believe is also typically done with a "data" block to grab a new one, so I'm not sure what in particular is added there?
Dependency management for devops sounds reasonable, but to me it seems more like trying to make an NPM/Cargo/pip that is for every language instead of a particular language.
>The Terraform example doesn't seem particularly useful to me, as something that runs Terraform would be on the CI side. I don't need to worry about dependencies locally or anywhere else because it should never ever be ran anywhere but the CI server, which we would steward over.
Running terraform fmt locally is useful to be able to do even if the apply runs in CI. And for the 0.11->0.12 migration being able to run terraform 0.12upgrade locally was useful.
>Dependency management for devops sounds reasonable, but to me it seems more like trying to make an NPM/Cargo/pip that is for every language instead of a particular language.
This seems to me more of a dependency checker than a traditional manager which is useful if you pin dependencies (and for reproducible builds and identical prod/test envs you really should). There's a number of companies which do this for security on live environments (scanning your running containers, registry, AMIs, etc.).
Re the AMI - yes you could use a data block, but that would immediately apply the latest version of an AMI when executing terraform, leading to unreproducible builds. Zeitgeist instead would just notify you that a new image is available, but let you control when you choose to deploy it, for example once you’ve confirmed that the new image passes all your tests in a dev environment.
(And if the AMI is for an individual EC2 instance instance rather than an ASG, you’ll have to plan downtime while the machine reboots with the new AMI, so a data block can be pretty dangerous there)
Re Terraform itself; where you’re running it is irrelevant - it needs to be kept up to date somehow. As mentioned elsewhere in this thread, some of these updates (like 0.11 -> 0.12) need to be carefully planned and managed... and how would you do that if you don’t know updates are available :)
Having spent a lot of time writing terraform tracking updates to dependencies and version pinning have become a constant task. Terraforms "default" behavior of pulling the latest version especially with the 0.11x to 0.12x migration has caused a lot of time spent pinning and checking for changes in modules.
The AMI part of it I believe is also typically done with a "data" block to grab a new one, so I'm not sure what in particular is added there?
Dependency management for devops sounds reasonable, but to me it seems more like trying to make an NPM/Cargo/pip that is for every language instead of a particular language.
Running terraform fmt locally is useful to be able to do even if the apply runs in CI. And for the 0.11->0.12 migration being able to run terraform 0.12upgrade locally was useful.
>Dependency management for devops sounds reasonable, but to me it seems more like trying to make an NPM/Cargo/pip that is for every language instead of a particular language.
This seems to me more of a dependency checker than a traditional manager which is useful if you pin dependencies (and for reproducible builds and identical prod/test envs you really should). There's a number of companies which do this for security on live environments (scanning your running containers, registry, AMIs, etc.).
Re the AMI - yes you could use a data block, but that would immediately apply the latest version of an AMI when executing terraform, leading to unreproducible builds. Zeitgeist instead would just notify you that a new image is available, but let you control when you choose to deploy it, for example once you’ve confirmed that the new image passes all your tests in a dev environment.
(And if the AMI is for an individual EC2 instance instance rather than an ASG, you’ll have to plan downtime while the machine reboots with the new AMI, so a data block can be pretty dangerous there)
Re Terraform itself; where you’re running it is irrelevant - it needs to be kept up to date somehow. As mentioned elsewhere in this thread, some of these updates (like 0.11 -> 0.12) need to be carefully planned and managed... and how would you do that if you don’t know updates are available :)
I think I saw it on here recently. Not something I have a particular use for, but it’s interesting enough to remember.