4 ms·

Nice breakdown from a personal perspective, but I see the author struggling against full cloud-native. Terraform will never be good for leading-edge AWS technol

Nice breakdown from a personal perspective, but I see the author struggling against full cloud-native. Terraform will never be good for leading-edge AWS technologies. If you need something more advanced than Cloudformation to define your infrastructure as code, try Troposphere or CDK. I think we're past the point where Terraform can exhibit the "cloud arbitrage" value that was previously sold to us. Working through permissions in AWS does suck, and the transparency problem in why a container fails to start in Fargate is especially frustrating. Serverless and devops in general isn't about putting ops folks out of a job. It's about leveling the playing field on both sides of the coin so that someone who focuses on application development and someone who focuses on networking and infrastructure can collaborate easier, with more solid contracts and interfaces. So long as the more adversarial perspective persists, we'll see a lot more digging in of the heels around kubernetes. As usual, I implore my friends in ops not to rely on the inherent bus factor that the mastery of kubernetes requires for job security.

robrtsql 7y ago
> If you need something more advanced than Cloudformation to define your infrastructure as code, try Troposphere or CDK The author has already hit a use-case that is not currently supported by Cloud formation (creating a SecureString SSM parameter)--that's something that Troposphere or the CDK won't help you with (unless you use them to create the resource via the API rather than Cloud formation).
- scarface74 7y ago
  He was willing to use external Terraform modules why not a CF custom resource? A quick Google search found this: https://svdgraaf.nl/2018/04/13/CloudFormation-ssm-secure-string-support-boto3-custom-resource.html https://svdgraaf.nl/2018/04/13/CloudFormation-ssm-secure-str...
  - Varriount 7y ago
    Pre-built custom resources (like the one linked) are under not all that common. The fact that there's one that exists for this particular situation I would ascribe more to luck, then a generous amount of public material.
    - scarface74 7y ago
      Not being able to create a secure string parameter was the first problem I ran into with CloudFormation. That’s how I happened to know that a custom resource for it existed. But, creating a custom resource is relatively easy. I’ve had to create a few for things that are really “custom” to our environment. I used these as templates —- https://github.com/stelligent/cloudformation-custom-resources https://github.com/stelligent/cloudformation-custom-resource... One issue that really seemed like an oversight is that you can’t add a event subscription to an existing S3 bucket. I had to write a custom resource to do it.
      - tie_ 7y ago
        > Not being able to create a secure string parameter was the first problem I ran into with CloudFormation. How about 'NoEcho' type of CFN parameters?
        scarface74 7y ago
        What do you mean?
        tie_ 7y ago
        CloudFormation supports the "NoEcho" option specifically to allow password-type parameters, which are not inspectable. How is that not a secure string parameter?
        scarface74 7y ago
        I realize this response is late. The term “parameters” is unfortunately overloaded. CloudFormation parameters are used within CF. We were referring to parameters in Parameter Store. https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html https://docs.aws.amazon.com/systems-manager/latest/userguide... But then, how do you get the secret value from CF to parameter store? If you put the value of the parameter in your template, then it is stored unencrypted in your template that is probably in source control. For that, I use a combination of NoEcho in CF and use that user entered value as a !Ref when creating the parameter store. Run the template manually one time and then you can have it default to the existing value. But you need a custom resource to create a secure string type.
  - robrtsql 7y ago
    Yep, that's what I use as well. It works, but I don't really love that I have to create an IAM role and a Lambda function just to create an encrypted secret.
- tie_ 7y ago
  Actually, if the author had used CloudFormation, they could have a password-type (NoEcho) Input, and then they wouldn't need to deal with SSM at all. Much less hassle, and just as (in)secure. To do it properly, the author could have created an AWS KMS key, encrypted the password with that key, and then stored the encrypted password in source control. Then password goes in as a regular, plain-text parameter, and the container decrypts it thanks to having the proper IAM permissions for the AWS Key. It's slightly more complicated but you get 1) ability to store the (encrypted) password in source control and 2) the ability to let anyone work with the stack without giving them the plaintext pw. If you do want to stick to SSM for whatever reason, you can also use SSM parameters as Inputs to CloudFormation, so you can use a custom resource OR an out-of-band process to set the password up. It's wouldn't be great, but it's not the right tool for the job in the first place.
meowface 7y ago
I'm a developer (mostly) and I'm brand new to serverless technology, cloud infrastructure, etc. I've never set anything up in AWS before, except for a few EC2 instances here and there. I've never used Cloudformation, Fargate, or anything like it. I was recently asked to set up a recurring Fargate task with a container of an app I developed. Despite knowing nothing about the ecosystem, I was able to get it up and running with Terraform in a few days, with pretty much no headaches, friction, or confusing issues. I didn't touch the AWS console even once, other than to verify that it appeared to be set up correctly after running "terraform apply". I considered using Cloudformation, but it just seemed kind of messy and confusing to me. It also felt very visually noisy. (And YAML wasn't the issue; I read and write YAML very often, and actually really like YAML and use it in all of my personal projects.) Despite going into it totally blind, by contrast, I found Terraform very intuitive and sensible within the first few minutes of using it. It felt much more structured and organized, and just generally simpler to read and write. I also liked that it was provider-agnostic. And the "terraform plan" feature was super helpful. I "cheated" a little bit by using these Terraform templates as a base: https://github.com/turnerlabs/terraform-ecs-fargate-scheduled-task https://github.com/turnerlabs/terraform-ecs-fargate-schedule.... I didn't have to change too much to get things working. I'm sure it would've taken longer if I wrote the whole thing from scratch. I guess I'm asking: am I wasting my time investing in learning things like Terraform? Every reply in this thread is either recommending AWS-native alternatives to Terraform, criticizing Terraform, or both. For some reason I thought it was generally recommended over Cloudformation due to the lack of lock-in.
- jjeaff 7y ago
  If terraform gets the job done and seems easier, then that is a good reason to use it. Especially as it seems that there are more boilerplate examples for terraform out there. But no lock-in is not a reason at all. There is effectively no amount of terraform config that will plug and play into a different cloud. It seems that it was pitched that way. But if you write anything in terraform for AWS you will have to fully rewrite it for GCP or DO. But at least you will be used to the syntax and conventions.
  - meowface 7y ago
0x8BADF00D 7y ago
Or you can just use GKE and spend the rest of your day drinking at a resort of your choice. Fargate and ECS are unnecessarily complicated for most people’s workflows and use cases.

robrtsql 7y ago

> If you need something more advanced than Cloudformation to define your infrastructure as code, try Troposphere or CDK The author has already hit a use-case that is not currently supported by Cloud formation (creating a SecureString SSM parameter)--that's something that Troposphere or the CDK won't help you with (unless you use them to create the resource via the API rather than Cloud formation).

scarface74 7y ago
He was willing to use external Terraform modules why not a CF custom resource? A quick Google search found this: https://svdgraaf.nl/2018/04/13/CloudFormation-ssm-secure-string-support-boto3-custom-resource.html https://svdgraaf.nl/2018/04/13/CloudFormation-ssm-secure-str...
- Varriount 7y ago
  Pre-built custom resources (like the one linked) are under not all that common. The fact that there's one that exists for this particular situation I would ascribe more to luck, then a generous amount of public material.
  - scarface74 7y ago
    Not being able to create a secure string parameter was the first problem I ran into with CloudFormation. That’s how I happened to know that a custom resource for it existed. But, creating a custom resource is relatively easy. I’ve had to create a few for things that are really “custom” to our environment. I used these as templates —- https://github.com/stelligent/cloudformation-custom-resources https://github.com/stelligent/cloudformation-custom-resource... One issue that really seemed like an oversight is that you can’t add a event subscription to an existing S3 bucket. I had to write a custom resource to do it.
    - tie_ 7y ago
      > Not being able to create a secure string parameter was the first problem I ran into with CloudFormation. How about 'NoEcho' type of CFN parameters?
      - scarface74 7y ago
        What do you mean?
        tie_ 7y ago
        CloudFormation supports the "NoEcho" option specifically to allow password-type parameters, which are not inspectable. How is that not a secure string parameter?
        scarface74 7y ago
        I realize this response is late. The term “parameters” is unfortunately overloaded. CloudFormation parameters are used within CF. We were referring to parameters in Parameter Store. https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html https://docs.aws.amazon.com/systems-manager/latest/userguide... But then, how do you get the secret value from CF to parameter store? If you put the value of the parameter in your template, then it is stored unencrypted in your template that is probably in source control. For that, I use a combination of NoEcho in CF and use that user entered value as a !Ref when creating the parameter store. Run the template manually one time and then you can have it default to the existing value. But you need a custom resource to create a secure string type.
- robrtsql 7y ago
  Yep, that's what I use as well. It works, but I don't really love that I have to create an IAM role and a Lambda function just to create an encrypted secret.
tie_ 7y ago
Actually, if the author had used CloudFormation, they could have a password-type (NoEcho) Input, and then they wouldn't need to deal with SSM at all. Much less hassle, and just as (in)secure. To do it properly, the author could have created an AWS KMS key, encrypted the password with that key, and then stored the encrypted password in source control. Then password goes in as a regular, plain-text parameter, and the container decrypts it thanks to having the proper IAM permissions for the AWS Key. It's slightly more complicated but you get 1) ability to store the (encrypted) password in source control and 2) the ability to let anyone work with the stack without giving them the plaintext pw. If you do want to stick to SSM for whatever reason, you can also use SSM parameters as Inputs to CloudFormation, so you can use a custom resource OR an out-of-band process to set the password up. It's wouldn't be great, but it's not the right tool for the job in the first place.

meowface 7y ago

I'm a developer (mostly) and I'm brand new to serverless technology, cloud infrastructure, etc. I've never set anything up in AWS before, except for a few EC2 instances here and there. I've never used Cloudformation, Fargate, or anything like it. I was recently asked to set up a recurring Fargate task with a container of an app I developed. Despite knowing nothing about the ecosystem, I was able to get it up and running with Terraform in a few days, with pretty much no headaches, friction, or confusing issues. I didn't touch the AWS console even once, other than to verify that it appeared to be set up correctly after running "terraform apply". I considered using Cloudformation, but it just seemed kind of messy and confusing to me. It also felt very visually noisy. (And YAML wasn't the issue; I read and write YAML very often, and actually really like YAML and use it in all of my personal projects.) Despite going into it totally blind, by contrast, I found Terraform very intuitive and sensible within the first few minutes of using it. It felt much more structured and organized, and just generally simpler to read and write. I also liked that it was provider-agnostic. And the "terraform plan" feature was super helpful. I "cheated" a little bit by using these Terraform templates as a base: https://github.com/turnerlabs/terraform-ecs-fargate-scheduled-task https://github.com/turnerlabs/terraform-ecs-fargate-schedule.... I didn't have to change too much to get things working. I'm sure it would've taken longer if I wrote the whole thing from scratch. I guess I'm asking: am I wasting my time investing in learning things like Terraform? Every reply in this thread is either recommending AWS-native alternatives to Terraform, criticizing Terraform, or both. For some reason I thought it was generally recommended over Cloudformation due to the lack of lock-in.

jjeaff 7y ago
If terraform gets the job done and seems easier, then that is a good reason to use it. Especially as it seems that there are more boilerplate examples for terraform out there. But no lock-in is not a reason at all. There is effectively no amount of terraform config that will plug and play into a different cloud. It seems that it was pitched that way. But if you write anything in terraform for AWS you will have to fully rewrite it for GCP or DO. But at least you will be used to the syntax and conventions.
- meowface 7y ago

0x8BADF00D 7y ago

Or you can just use GKE and spend the rest of your day drinking at a resort of your choice. Fargate and ECS are unnecessarily complicated for most people’s workflows and use cases.