[HN Gopher] Show HN: Precloud - Dynamic tests for infrastructure...
       ___________________________________________________________________
        
       Show HN: Precloud - Dynamic tests for infrastructure-as-code
        
       Infrastructure as code (IaC) often fails during deployment due to
       dynamic constraints such as name collisions, quota limits and other
       resource-specific constraints that devs run halfway into an IaC
       deployment. We witnessed this first hand at TinyStacks and built
       precloud - an open-source framework to define and run dynamic tests
       before IaC deployments.  The precloud framework currently supports
       Terraform and AWS CDK with several default checks (unique names,
       service quota checks and more) and ability to define your own!
        
       Author : safeerm
       Score  : 40 points
       Date   : 2023-01-26 14:27 UTC (8 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | chologrande wrote:
       | Any time I see a nodejs tool aimed at systems tasks (general
       | infrastructure, IaC, etc) I immediately disregard it. While, to
       | be honest, I'm not sure that's a fair way to look at tools like
       | this, it's the reality.
       | 
       | I always wonder at the authors motivation to use node when the
       | majority of the ecosystem is written in golang. This is actually
       | one of the main reasons I dont use terraform CDK right now. Why
       | is CDK node first (I know there is golang support) when terraform
       | is all golang?
        
         | preseinger wrote:
         | I agree that it's weird to write any command-line tool in Node.
         | Very few developers have `npm` installed.
        
       | varunsharma07 wrote:
       | Suggestion: Please add a license and fill out the About section
       | in the GitHub repo.
        
         | zsimjee wrote:
         | Done!
        
       | sausagefeet wrote:
       | This is really cool. I am co-founder of Terrateam[0] and we see
       | failed runs for these reasons a lot more than we expected and
       | it's dangerous. It wastes time and a failure during an apply
       | leaves your infrastructure in an inconsistent state. I'm excited
       | to play with this.
       | 
       | [0] https://terrateam.io
        
       | cube2222 wrote:
       | This looks really cool! I wonder if it only checks for collisions
       | in the current statefile/template, or whether it actually makes
       | call to the cloud provider and checks for even external
       | collisions there? Though I guess that would be very complicated
       | to accomplish without writing tons of glue code.
       | 
       | That said, if you like infra-as-code and are scaling your usage
       | to more people, I recommend taking a look at tools like
       | Spacelift[0].
       | 
       | We're a CI/CD that's specialized for infra-as-code and integrate
       | very deeply with Terraform, CloudFormation, and similar tools
       | workflows. This way we can give you better visibility, security
       | and easy customizability through automations that are tailor-made
       | for infra-as-code use cases. You can ofc additionally also hook
       | in tools like this one.
       | 
       | Esp. if you want a single team creating reusable templates and
       | guardrails for the whole company, Spacelift can help you a lot,
       | but it's very useful for any bigger group of people using IaC
       | together.
       | 
       | Disclaimer: Software Engineer at Spacelift, grains of salt shall
       | be taken with the above
       | 
       | [0]: https://spacelift.io
        
         | zsimjee wrote:
         | Hey Cube! It does indeed run checks against the cloud as well
         | for things like naming collisions and quota allocation
        
           | cube2222 wrote:
           | Could you expand on how you're doing that, technically? I'm
           | really curious and can't find it in the code, skimming it
           | quickly.
        
             | zsimjee wrote:
             | Yeah, so this package itself is the core framework that
             | establishes how these tests are to be run. There is a
             | notion of plug-ins, which are parsers and checks. Parsers
             | take cdk or terraform code and break their
             | synthesized/planned output out into a common structure.
             | Then checks run over that structure and pull data in from
             | elsewhere and run actual validations. You can read more in
             | the developing plugins doc on the repo https://github.com/t
             | inystacks/precloud/blob/main/DEVELOPING_....
             | 
             | The default plugins present are the 6 mentioned here https:
             | //github.com/tinystacks/precloud/blob/main/PLUGINS.md.
             | They're all published on npm and github
        
               | cube2222 wrote:
               | Oh, that's cool, thanks for the explanation!
        
       | hdjjhhvvhga wrote:
       | It looks like an useful tool, thank you! It looks like it's
       | written in JS and has several dependencies so for security
       | reasons I'd run it on a separate box to minimize blast radius.
        
         | zsimjee wrote:
         | Good idea. I recommend running it in your ci cd provider as a
         | post-build stage (I.e. reference it in your github/gitlab
         | workflow on each pull request)
        
       | partdavid wrote:
       | I see that GCP support is "coming soon"--even just a quota
       | comparison would be really nice, as these are numerous and a big
       | pain there. Any ETA on when there might be something for GCP?
        
         | zsimjee wrote:
         | We don't have an ETA there yet. I opened issues for GCP
         | support, please +1 them to help us prioritize!
         | https://github.com/tinystacks/precloud/issues
        
       ___________________________________________________________________
       (page generated 2023-01-26 23:01 UTC)