Rain user feedback

[ericzbeard]

Hi everyone, I'm the primary maintainer of rain. I'm a Solutions Architect at AWS specializing in Infrastructure as Code. Rain's growth has been entirely organic, with no marketing support since it was created by @stilvoid (all credit to him, I just picked up rain this year). We haven't built any specific telemetry into rain, so it's hard to tell who's using it and how it's being used. I wanted to reach out to people who have been active on this repository and ask a few questions.

• Do you use rain for production deployments?
  • If so, would you mind sharing where you work, so we can get an idea of who relies on rain?
• What's your favorite feature?
• Is there anything else you wish rain could do?
• Have you tried out the new experimental modules or forecast features?
  • (Rain forecast has been my primary focus lately, I would love to get some feedback from beta testers!)

@t-jones
@iainelder
@lesterjude
@b0tting
@jsutton
@null93
@ugwis
@a-mymt
@bartleboeuf
@edgdelgado
@filipeandre
@dhutchison
@JWFGit
@paul-e-allen
@mrinaudo-aws
@andrius-paurys
@hariprakash-j
@jameslevine
@TheDanBlanco
@gouglhupf
@skrisyuk
@tam0ri

[hariprakash-j]

Hi Eric, I love the cli and I'd be glad to give you some feedback. I've used it quite a bit where I needed it in production at my work for deploying the cfn templates across the org - Do you use rain for production deployments? A: yes, I use it to deploy resources on over 1300 accounts we have in our org - If so, would you mind sharing where you work, so we can get an idea of who relies on rain? A: I work for Airbus, I work on managing all the AWS accounts we use across the org - What's your favorite feature? A: Merge, embed and s3 packaging - Is there anything else you wish rain could do? A: A feature where it packages a folder into a zip file for lambdas and uploads it into a s3 bucket. Live reload for cfn templates would be a nice feature to have for deploying api and other resources while developing. I know sam cli exists, its specific for lambdas and api gateway, I'd like it to work on a standard cfn template. - Have you tried out the new experimental modules or forecast features? - (Rain forecast has been my primary focus lately, I would love to get some feedback from beta testers!) A: I tried using forecast but I haven't used it enough to give you a good feedback. I did not need it because we have a testing and validation environments which accurately replicates our prod env as its so critical for us. However I'd definitely use it on smaller deployments on say one account or one environment in the future. To conclude, We used the aws cli to deploy stacksets and stacks on all of our many aws accounts but the templates soon became very large(often 1000s of lines) and were hard to understand and use. I used rain to split up the template and merge it only during the deployment. This is why merge and embed are game changers for me. Merge and embed work well with sam templates too(not sure if it was intended), I used it to deploy complex stacks of resources with merge to keep the templates smaller, embed for lambdas and config rules with little code and s3 package for ones with large code bases for easier maintenance. I intend to keep using rain cli where ever I need to deploy cloudformation templates and keep contributing when I face issues or need new features. Please pass on my thanks to @stilvoid for creating such an awesome project and thank you for maintain it! Please feel free to reach out if you have more questions I'd be happy to answer them : ) Regards Hari Prakash

…

On 8/9/23 22:41, Eric Z.Beard 'notifications at github.com' wrote: Hi everyone, I'm the primary maintainer of rain. I'm a Solutions Architect at AWS specializing in Infrastructure as Code. Rain's growth has been entirely organic, with no marketing support since it was created by ***@***.***(https://github.com/stilvoid) (all credit to him, I just picked up rain this year). We haven't built any specific telemetry into rain, so it's hard to tell who's using it and how it's being used. I wanted to reach out to people who have been active on this repository and ask a few questions. - Do you use rain for production deployments? - If so, would you mind sharing where you work, so we can get an idea of who relies on rain? - What's your favorite feature? - Is there anything else you wish rain could do? - Have you tried out the new experimental modules or forecast features? - (Rain forecast has been my primary focus lately, I would love to get some feedback from beta testers!) ***@***.***(https://github.com/t-jones) ***@***.***(https://github.com/iainelder) ***@***.***(https://github.com/lesterjude) ***@***.***(https://github.com/b0tting) ***@***.***(https://github.com/jsutton) ***@***.***(https://github.com/null93) ***@***.***(https://github.com/ugwis) ***@***.***(https://github.com/a-mymt) ***@***.***(https://github.com/bartleboeuf) ***@***.***(https://github.com/edgdelgado) ***@***.***(https://github.com/filipeandre) ***@***.***(https://github.com/dhutchison) ***@***.***(https://github.com/JWFGit) ***@***.***(https://github.com/paul-e-allen) ***@***.***(https://github.com/mrinaudo-aws) ***@***.***(https://github.com/andrius-paurys) ***@***.***(https://github.com/hariprakash-j) ***@***.***(https://github.com/jameslevine) ***@***.***(https://github.com/TheDanBlanco) ***@***.***(https://github.com/gouglhupf) ***@***.***(https://github.com/skrisyuk) ***@***.***(https://github.com/tam0ri) — Reply to this email directly, [view it on GitHub](#179), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ARNPU3QMC2DO7AOBRLHI6T3XUPAFLANCNFSM6AAAAAA3KJ2XXE). You are receiving this because you were mentioned.Message ID: ***@***.***>

[ericzbeard]

Thanks for the feedback Hari! Really appreciate it.

One note about this request: A feature where it packages a folder into a zip file for lambdas and uploads it into a s3 bucket. The pkg command does this already, here's a snippet from one of my templates:

Code: !Rain::S3 
  Path: ../registration 
  Zip: true
  BucketProperty: S3Bucket
  KeyProperty: S3Key

And for this request: Live reload for cfn templates would be a nice feature to have for deploying api and other resources while developing. I worked on the cdk watch and cdk hotswap features, so I definitely see the value. We already have a rain watch command so we'd need to come up with a name to distinguish the feature from the log watcher.

[hariprakash-j]

Thanks for the reply !! I did not know Rain::S3 did that. For the live reload I can create an issue and start working on in my free time, should be fun !

[iainelder]

Production deployments

Rain is now my go-to tool for one-off stack creations in any environment, as long as I'm creating that stack via the terminal. I used it to create something in production today! I haven't used as part of a CI pipeline yet, so in that sense I don't yet use it in "full production".

I'm a contractor, but if any of my clients agrees to "admit" to my using Rain then I may be able to share the info with you :-)

Favorite feature

The deploy command. It provides a better experience than the AWS CLI and the SAM CLI.

• It blocks until the stack operation is complete.
• It automatically deletes and recreates a stack that failed to create.
• It never fails because of missing capabilities.

I haven't used it much yet, but the stackset feature is so welcome too! The official CLI makes working with stack sets more clumsy than it needs to be.

Wishlist

• Deploy CloudFormation templates from HTTP URL. Today I work around it using curl in a process substitution. Sceptre's HTTP handler already supports it. This makes Sceptre my favorite deployment tool because I can put a template in GitHub, tag it, and deploy the versioned template using a GitHub "raw" URL.

• Option to watch the CloudFormation events during deploment in the log. They appear in the terminal, but they get overwritten. Sometimes that's fine, but for a CI process sometimes I'd want to see them all logged out. The SAM CLI does this, but it wraps the messages in a weird table format so the messages are hard to copy out. Simple output such as that of cfn-events would be enough. (There are many CloudFormation event tailers, but I think that's the best for its JSONL output.)

Experimental features

I haven't used the experimental features yet! But anything that makes client-side modularity easier would be welcome. I've already described a pattern for deploying versioned stacks that are single-file templates. But a solution for multi-file stacks (say Lambda code or substacks) is less clear.

[ericzbeard]

Thanks Iain! Could you turn this into an issue with more details about how exactly you would like this to work? And how it would differ from the logs and watch commands?

Option to watch the CloudFormation events during deployment in the log. 

[iainelder]

I'll admit, I haven't used the logsand watch commands yet. First I'll check whether they meet my needs and if not I'll prepare an issue. Thanks for the invitation to give feedback. Pleased to hear that rain is getting some love!

[null93]

Thanks for reaching out, and thank you for maintaining this project. I hope it continues to grow since we found it to be very useful. I think it is really important for AWS to have an official tool that extends the base functionality of aws cloudformation package.

Do you use rain for production deployments?

Yes! I work at JetRails and we are actually AWS partners. We use rain to better template out our production CloudFormation templates using rain pkg. These templates are used to deploy production/staging/development stacks for our customers. We also rely on rain fmt which is great!

What's your favorite feature?

I definitely like the custom !Rain directives the most. Such a powerful feature that can unlock so much for templating on top of CloudFormation templates.

Is there anything else you wish rain could do?

Since we primarily use the custom directives, I would love there to be even more useful and robust directives implemented. For example, it would be really nice if you could supply an additional argument to the !Rain::Include directive which would specify the path within the YAML/JSON document to grab. It would be useful to grab a part of a document rather than the whole thing (removes the need to separate data into different files even though they belong together).

It would also be super useful to see resources graphed out in time. Something similar to a Gantt Chart. I did something like this in the past to try to visualize what resources take up a lot of time and also used that information to break dependencies in order to deploy stacks faster.

Have you tried out the new experimental modules or forecast features?

I have not tried forecast, but that is primarily because we do not use rain for actually deploying stacks. I have looked into modules, but honestly it is a little hard to figure out. There really is no documentation out there or even examples (or maybe I just couldn't find them).

Hope that was helpful, best of luck!

[ericzbeard]

Thanks for the feedback! I recently added example usage for pkg to the Readme, let me know if this section on modules helps: https://github.com/aws-cloudformation/rain#module

[null93]

It definitely helps, thank you! I think this is a very powerful feature. I can see me getting rid of some nested stacks in favor of this.

[b0tting]

Hi Eric!

Thank you for taking the time to create this tool.

Do you use rain for production deployments?

We are an international oil/gas company. I use Rain as a replacement for the aws deploy commands in our CF template CI/CD. When committing changes to templates we use rain to deploy, validate and delete stacks for every test case. It is quite cool and the scheduled runs caught a few unexpected issues like expired AMIs and failing macros. I do not (yet!) deploy production templates.

What's your favorite feature?

I only use a small subset of Rain. The extras features on the deploy command allowed me to ditch similar code I wrote and had to maintain myself. It simplified our pipeline.

Is there anything else you wish rain could do?

It's a "would have" - I have to write some unpretty shell script to deal with the Rain YAML output. A JSON output option would be nice.

Have you tried out the new experimental modules or forecast features?

Not yet, but reading up I should spend some time into adding forecast to my CI/CD pipe.

[ericzbeard]

Thanks for the feedback, I'm glad to hear rain is useful, even with a subset of commands. Let me know how it goes evaluating forecast. Install from main instead of the latest release if you want to evaluate all of the latest features. I should probably cut releases a bit more often. This week I added more permissions checks to the command, for EC2, Lambda, and IAM resources.

[iainelder]

I just tried the !Rain::S3Http directive today. It's great for deploying stack sets!

It makes it easy to separate the stack instance template from the stack set configuration, and so allows me to reuse the template to create a the same resources in the management account. (This is useful for AWS Config recorders.)

Resources:
  StackSet:
    Type: AWS::CloudFormation::StackSet
    Properties:
      StackSetName: recorders
      TemplateURL: !Rain::S3Http recorders.yaml

Another wish: Process directives recursively.

I tried the above syntax in a nested stack like this:

Resources:
  OrganizationRecorder:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: !Rain::S3Http stack-set.yaml

Rain uploads the stack set template to S3 without processing the Rain directive, so it later fails like this:

error creating changeset: Template format error: YAML not well-formed. (line 10, column 20)

[iainelder]

I shared rain as a workaround for this use case that isn't yet solved by the AWS CLI's aws cloudformation package command.

aws/aws-cli#5590 (comment)

[ericzbeard]

I'm not sure rain would have a good way to know if it should package the file referenced by the !S3 directive.. it could be anything, right? Like a web page or a zip. Can you pre-package that template and reference the output instead? Like rain pkg stack-set.yaml > stack-set-pkg.yaml and then reference stack-set-pkg.yaml in the directive?

[iainelder]

Hi, @ericzbeard , sorry I missed your response till now. I was taking some time off from GitHub :-)

I might have misunderstood you, or I might have confused things by using the word package in the wrong context. I don't want rain to act like the package command. It's more powerful than that.

I thought "it could be anything" was the point of the !S3 directive. Rain doesn't need to know what the file is. It already works perfectly for level 0 (the main template itself). It would be awesome if it also worked at 1 level of indirection (an S3 directive in the thing being uploaded to S3) and so on.

I could pre-package stuff, but the main selling point of a deployment tool for me is that it handle all that stuff for me. I don't want to write shell scripts to stick bits of CloudFormation together if a tool can do it for me behind a single command invocation.

[jsutton]

Do you use rain for production deployments?
Yes

If so, would you mind sharing where you work, so we can get an idea of who relies on rain?
I'm a consultant, and we use it on engagements.

What's your favorite feature?
Deploy

Is there anything else you wish rain could do?
I think it would be nice if in addition to fmt there was a function that acts similar to https://github.com/stelligent/cfn_nag to help detect security misconfigurations. Same for linting. Another area that feels awkward on the cli is resource importing and creating stacks from resources.

Have you tried out the new experimental modules or forecast features?
I haven't. I will probably use forecast soon. Modules are neat, but it makes the stacks incompatible with boto3 or the aws cli. The big draw for me with rain is that it is still just cloudformation at the end of the day.

[jsutton]

I think it would be interesting to have 'build' support deployment patterns. Something like what https://github.com/aws/copilot-cli does with 'load balanced web service'. Maybe there could be some default patterns and the ability to define custom patterns.

Some sources for default patterns are:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-services-us-west-2.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/CHAP_TemplateQuickRef.html

This might be too big of a departure from rain's core design goals though.

[ericzbeard]

This is sort of the idea I had with modules. I was thinking of hosting the modules in the rain repo, and allowing them to be referenced from templates. Something like Type: !Rain::Module "https://github.com/aws-cloudformation/rain/blob/main/modules/module.yaml"

[ericzbeard]

As for security scanning, I think that's out of scope. Tools like cfn-guard and checkov are good at this. I wouldn't use cfn_nag any more, it seems that project is dead.

[jsutton]

I can see modules being used in that way and it is more composable than doing it with build.

Agreed on security scanning being out of scope.

[ericzbeard]

The module feature is really just a prototype for now, would love to get more feedback on it. Really hard to get the design right. Versioning modules becomes a concern if we actually host patterns in this repo, especially if they are composed together into patterns.

[a-mymt]

Do you use rain for production deployments?

Yes.

If so, would you mind sharing where you work, so we can get an idea of who relies on rain?

I'm a devops team member of a web service.

What's your favorite feature?

Easy deployment!

Have you tried out the new experimental modules or forecast features?

No.

It would be nice to have the ability to compare the templates in the stack that have been deployed in rain with the templates that are about to be deployed.

[ericzbeard]

Thanks for the feedback! I assume you want the rain diff command to actually download the currently deployed template so you don't have to do that manually.