Live data from Hacker News

Terraforming 1Password

blog.agilebits.com

91–100 of 119 posts

Re: Terraforming 1Password

#91
post #67

The code comparison between CloudFormation’s abysmal JSON formatting and Terraform’s DSL is a bit disingenuous. CloudFormation has supported YAML for at least a year or two now, and it’s leagues more readable and compact, not to mention maintainable—you can even add comments to your code with YAML (something that is impossible with the old JSON format). I’ve spent a lot of time working between the two, and while Terr…

> CloudFormation has its virtues Which seem to mostly revolve around AWS vendor lock-in. Which, you know, can be a valid business decision - accepting vendor-exclusive tooling for better vendor support to try and simplify initial deployment and lower near-term, initial ramp-up costs - but it has its downsides too, like losing control of costs over the long term and making advanced work (like multi-cloud deployments t…

> Seems to me like the question of CloudFormation vs. Terraform has more to do with whether the business makes a strategic decision to allow for vendor lock-in or not, rather than mostly aesthetic discussions over the merits of YAML vs HCL.

While I agree that CloudFormation is a vendor-specific tool which makes Terraform the obvious choice to avoid vendor lock-in more generally, in this particular case, the author is fully entrenched in the AWS ecosystem without any hint of desire to avoid lock-in, and gave as reason #1 for his decision a mostly aesthetic discussion over the merits of YAML vs HCL.

Re: Terraforming 1Password

#92
post #87

Earlier quoted context omitted.

It's funny, I came to the comments to specifically complain about that graphic. There are significant disadvantages to the isometric view for that data, and absolutely no advantage that I can see, other than it looks pretty if you're not trying to get information out of it. I think that Tufte needs to make a resurgence with this generation of designers.

Take it up with BeOS? :D

Hah, I think icons are the place isometric views work really well, actually! Lots of room for highly differentiated objects with an isometric view. However, text and interconnections and maps are really not great at these isometric angles. And I do really like the icons used in the figure in the original post, just not the whole.

Re: Terraforming 1Password

#93
post #44
post #39

Earlier quoted context omitted.

This is a really important point. Our company is using Terraform in a limited way, but Puppet is our primary automated configuration management tool. Similarly in Puppet, `ensure => latest,` on package resources isn't necessarily dangerous, but it can add a lot of confusion without intentional commits against the control repositories.

Puppet rules are typically applied constantly in short intervals. The installed version should always be the same everywhere, the latest available from the repository. The risk is more that you can get updates installed at inopportune times. Of course what's right is that the version change is not reflected in the configuration management, but this isn't normally a problem for minor version changes.

> The installed version should always be the same everywhere,

Agreed.

> the latest available from the repository.

Highly controversial statement. It depends on the policy of the pancake maintainer. I’ve seen too many subtle bugs introduced by changes in configuration file behavoriour, new defaults, etc.

I would say if you can guarantee “latest version” means “this version plus security patches” or the maintainer is absolutely pedantic about semantic versioning, have at it. Otherwise, consider the pros and cons of stability vs being up-to-date, and make a judgement call accordingly.

Re: Terraforming 1Password

#94

Earlier quoted context omitted.

Hi vr46, where should I go / what resources should I consult if I want to start learning more about AWS & setting up infrastructure? Thanks!

Forgive the self promotion but I'm building a subscription video site - http://stackleap.com/ - to teach people how to build and deploy to AWS infrastructure. The difference between StackLeap and sites like acloud.guru is that I'm focussing on the day to day stuff rather than high level concepts you need to know to pass the certification exams. I'm hoping to launch a beta in the next few weeks.

I've been very impressed with CloudAcademy - it seems to issue AWS accounts per course/per lab - it guides you through the steps and check whether you completed them by checking the AWS account, and then tears it down at the end.

You might not be ready for that level of integration, but see if you can get a demo or trial.

Re: Terraforming 1Password

#95

I use CloudFormation to manage similar AWS web-app infrastructure. I've been continuously evaluating Terraform over the years (it is indeed maturing quickly), but have still decided to stick with CloudFormation for now, and would still continue to recommend the same for anyone managing an AWS-exclusive (or mostly-AWS) deployment. To respond to some specific items mentioned in this post: - "Terraform has a more straig…

Could you share what preprocessors/templating languages you've used with CloudFormation?

At JUXT we use Clojure's EDN, bolstered with some tag literals courtesy of our Aero library (described here: https://juxt.pro/blog/posts/aero.html). We use ClojureScript to compile to TF's JSON. EDN allows comments, ignores commas and otherwise is a nicer JSON. Aero allows us to encode multiple environments in a single document, and include ciphertext for secrets. We're pretty happy with the overall result.

Re: Terraforming 1Password

#96

Here I am wishing that CloudFormation had one killer feature that would have allowed us to use it at work: the ability to adopt existing resources into a CF stack. When we were starting on the path of "hey maybe all our infra shouldn't be pointy clicky", we chose between CloudFormation, Terraform, and making something in-house. Out of those three, Terraform was the clear winner for us at the time, but it has not been…

i heard this third hand, but apparently cfn was slated to get this feature but it was nixed because of concerns with increased support requests. the official stance from amazon now is that you should be able to trivially destroy/recreate resources and cfn isn't going to adopt anything that makes it easier to create stateful deployments

it does suck to have to copy the contents of an s3 bucket just to move a bucket inside of a template tho, for sure

Re: Terraforming 1Password

#97
post #67

The code comparison between CloudFormation’s abysmal JSON formatting and Terraform’s DSL is a bit disingenuous. CloudFormation has supported YAML for at least a year or two now, and it’s leagues more readable and compact, not to mention maintainable—you can even add comments to your code with YAML (something that is impossible with the old JSON format). I’ve spent a lot of time working between the two, and while Terr…

> CloudFormation has its virtues Which seem to mostly revolve around AWS vendor lock-in. Which, you know, can be a valid business decision - accepting vendor-exclusive tooling for better vendor support to try and simplify initial deployment and lower near-term, initial ramp-up costs - but it has its downsides too, like losing control of costs over the long term and making advanced work (like multi-cloud deployments t…

unless your vendor goes out of their way to be compatible with aws apis no tooling is really portable. true that you can write terraform targetting both aws and gce, but there's no non-trivial terraform plans you can apply to both aws and gce

Re: Terraforming 1Password

#98
There is a Terraforming github project which exports existing Amazon EC2 infrastructure and creates Terraform infrastructure tf code and tfstate. Terraforming github repo does not seem to be related to 1password.

Terraforming github repo https://github.com/dtan4/terraforming http://terraforming.dtan4.net/

Re: Terraforming 1Password

#99

Great post. It's always good to see more examples of people putting these tools to work. With that said, I consider getting the AMI id dynamically to be an anti-pattern which undermines the principles of infrastructure-as-code. Specifically, it introduces an implicit build variable "time of `terraform apply`", which is not tracked in version control. Happily, because of Terraform's design, this sort of thing mostly w…

AMIs in general are a pain in the ass in AWS, though. If you're using custom-built encrypted AMIs in multiple accounts, the easiest way is to build the AMI once in each account, which then leaves you with a different AMI ID in each account. So now your template with hardcoded ID that works in one account won't work in another.

See: https://github.com/hashicorp/packer/issues/4772

Since you're probably also rebuilding AMIs on a regular basis to keep up with upstream updates/patches, your best bet is to use the latest version of an AMI in your template and be sure that you're also pruning old/incompatible AMIs from accounts regularly.

Post reply on HN