#terraform (2019-06)

The answer is yes, you can add type == "PARAMETER_STORE"

I have just added a pull request to update the example. https://github.com/cloudposse/terraform-aws-codebuild/pull/43

thanks for the update Jamie! On a side-note do you know if anything will come out of https://github.com/blinkist/terraform-aws-airship-ecs-cluster/pull/9 btw? Or would I be better off forking it? Marten hasn’t been so responsive for the last weeks

@Bogdan As far as I am aware pull requests into Blinkist are basically not happening, or are happening very slowly. The repo’s are in production and they aren’t taking in changes very regularly. @maarten himself is not working at Blinkist. He has his own personal brand called DoingCloudRight which is where the airship.tf site is generated from, and where some of his more current terraform modules exist.

I suggest you take a fork of mine for now if you want those features..

Feel free to fork. If you have better other ideas let me know. Baby expecting plus many other things atm.. cant commit my time at the moment unfortunately. @jamie if i make you repo admin, if @jonboulle agrees. Would that be helpful ?

please do, i actually have a ton of time now.

Thanks for clarifying Maarten and as an 11-week old father myself I wish you good luck and congrats :slightly_smiling_face:. I’ll follow yours and Jamie’s suggestion and fork Jamie’s latest then. Regarding ideas, one that has been on my mind was aws_autoscaling_schedule which if set I could spin the cluster early in the morning and kill it after working hours

fine for the repo admin!

Great!

I’m using that repo

it if very opinionated

so you should basically create your own terraform calling those modules individually and pass the appropriate variables to each

like the listerner rules for example , you might need to call it twice if you have two target_groups

The problem is the build and deploy stages and actions of the pipeline are hardcoded so I don’t see a way to alter them when calling.

hi @Rob the module is opinionated and is used for simple pipelines (source/build/deploy). For something more generic, you can open a PR (we’ll review fast), or maybe even create a new module (if it’s too complicated to add new things to the existing module)

you will have to fork and make your own and maybe send a PR over to make it more flexible

Yep @jose.amengual and @Andriy Knysh (Cloud Posse) are spot on

it is pretty hard to create a module that “all size fits all”

Yep… also, we (cloudposse) use mostly #codefresh for more serious release engineering. AWS CodeBuild/CodePipeline are quite primitive by comparison.

more primitive and more difficult to create complex pipelines. Codefresh has better DSL and UI

so no jenkins in your world ?

Thanks so much for the information! I didn’t see an easy way to modify the module for complex pipelines now, but saw that in TF 12 it can be done with looping logic.

We’ll absolutely take a look at codefresh. Do you have TF modules for defining more complex pipelines in codefresh?

https://github.com/cloudposse/example-app/tree/master/codefresh

the example repo defines all Codefresh pipelines that we usually use

(it’s not terraform, pipelines defined in yaml)

@jose.amengual we have jenkins modules https://github.com/cloudposse/terraform-aws-jenkins

but we stopped using it

for many reasons

jenkins is ok, but requires separate deployment and maintenance (as the module above shows)

it’s also old and convoluted and has a lot of security holes

https://www.securityweek.com/vulnerabilities-found-over-100-jenkins-plugins

yes jenkins is like the standard ci/do everything tool but nowadays services like codefresh are better

https://www.zdnet.com/article/thousands-of-jenkins-servers-will-let-anonymous-users-become-admins/

we don’t want to deal with all that stuff

ohhh yes I know, I work at Sonatype(Nexus IQ/Firewall and Maven tool creators ), , we had scan jenkins, node and others

Thanks so much everyone, really appreciate the assistance!

Codefresh also added parallel execution, using which you can build many images (e.g. for deploy and for test) in parallel

after building the test image, you can run tests on it

pretty cool

@Vidhi Virmani I believe you can have *.example.com in the name field. eg.

resource "aws_route53_record" "www" {
  zone_id = "${aws_route53_zone.primary.zone_id}"
  name    = "*.example.com"
  type    = "A"
  ttl     = "300"
  records = ["${aws_eip.lb.public_ip}"]
}

https://www.terraform.io/docs/providers/aws/r/route53_record.html

* is not allowed.

@Vidhi Virmani Interesting. what version of aws provider are you using? I’ve tried with 1.60.0 and it didn’t complain

This is where the route53 resource is defined. Not seeing anything forbidding wildcard record sets. https://github.com/terraform-providers/terraform-provider-aws/blob/3baf33f202f644bd4d861d4b44846127774e7e30/aws/resource_aws_route53_record.go#L897-L934

Hey, It worked for me.. There was an extra space and I didn’t realise that. Sorry for such a dumb question

It’s a fine way to handle it. If you know all your env short names in advance you could also use a locals map to remove the trinary

Yes I’m very familiar with that issue. :) which modules are you using?

Hey, sorry didn’t see your reply. Not using any module, building it by hand because I had trouble getting a module that created the whole service and ALB, and exported the ALB dns name so I could make r53 entries with it

@Mike Nock would you be happy to share what you have? Also all this is handled in the https://airship.tf terraform modules that @maarten created. But there’s a few tricks you may want to use to force dependence between resources you’re creating.

Sure I’d be open to that. I just got the service working correctly, so removing some of what I hard coded to do that atm.

Its its working… then great

this won’t work; missing ' … '

did you define env_var as a varariable?

what’s the precise error you are getting from terraform

Yup, I have got env_var as a variable error:

 as valid HCL: At 1:28: illegal char[0m[0m
[31mUsage: terraform plan [options] [DIR-OR-PLAN]

can you share precisely the command you are running?

terraform plan -var env_vars={"test" : "value", "test1": "value2"} will 100% not work

the " is evaluated by bash (or your shell), so that it is equivalent to running

terraform plan -var env_vars={test : value, test1: value2}

so that ` : value, test1: value2} are actually passed as arguments to terraform plan`

and that env_vars={test which is not a valid terraform expression

it’s always a cluster, but could be with a single instance. Cluster itself does not cost anything, it’s just metadata

ok, gotcha. Makes sense. Thx

@Paul Lupu

security_groups = ["sg-07f9582d82c4058e8, sg-0bf6bf06395fdf2c4"]

should be

security_groups = ["sg-07f9582d82c4058e8", "sg-0bf6bf06395fdf2c4"]

@jamie doesn’t that still require multi-phased apply?

(maybe I’m missing something!)

It does, you’re right. The difference being that each apply is standalone and complete. I use it more often than having extra Args that would create certain resources first. If data sources had a defaults section I would be really happy. :)

Aha, so you make the delineation very cut & dry

e.g. by using different project folders.

I suppose that’s a good rule to go by

It was the easier-to-understand option for the client I was working with. Having terraform apply -target module.x.submodule.y was harder to wrap their heads around than cd vpc; terraform apply

You want to import exsisting resources on a new terraform project or get outputs from another state?

No remote states

mainly how do you do. To see if there is better patterns in “importing” remote states using https://www.terraform.io/docs/providers/terraform/d/remote_state.html

the only way i use is via remote_state

I also use the terragrunt wrapper for terraform, so that I can do interpolation on the backend resources. And that way I can use standard naming conventions across all terraform state keys, and access their remote state values in a standard way. @Meb

Example to follow

That is what my backend file looks like for terragrunt

my terraform.tfvars includes it

terragrunt = {
  include = {
    path = "./backend.tfvars"
  }
...

And the environment file that passes in all of the values:

The environment variables can then be passed in at run time either via this file for testing, or via the deployment pipeline (i.e. runatlantis)

Thanks

Could you say more about how you mean “faster”? Fewer steps? Fewer decisions? Fewer components? …There are images in DockerHub that might have the combination of settings that will work for you.

Thanks for asking @Blaise Pabon ! I was referring to both fewer steps and fewer decisions while avoiding the need for an orchestration and use of Docker

@Bogdan, ok, that makes sense, well in that case, have you looked around for a good Ansible role? I haven’t tried it yet, but I might use https://galaxy.ansible.com/andrewrothstein/vault for my home lab.

Run, run, run away from this 4 years old Terraform module which has not gotten any love for the last 2 years…

PS: it is a list

Better use https://github.com/terraform-aws-modules/terraform-aws-vpc by the same author

sounds like not all things were manually deleted

isn’t there a way to ‘force’, i.e. continue even if the error strikes, to destroy as much as possible, then finish manually ?

depends on the error(s), but usually not

Hi @Andriy Knysh (Cloud Posse), still stuck on the same error…! I have no idea what resource is blocking the destroy : no sign of it in aws, I exported a full list of all resources… If you have any insight on what may cause the “Error: Error applying plan: 1 error occurred: * module.vpc.output.vpc_cidr_block: variable “default” is nil, but no error was reported” i’d be in debt !

1. go to the AWS console VPC and check all the subnets, route tables, elastic IPs. Delete them manually if any present

1. then do terraform taint -module=vpc aws_vpc.output

BTW, did you name your aws_vpc resource output? (seems strange)

1. Check if you have the resource with the name output and the variable with the name default (in the code). Share your code with me b/c it’s difficult to say anything without seeing it

Thanks your your messages ;

1. Already done, but some of the resources here are not named ; as there is no way to get a creation_timestamp, I can’t be 100% sure that it had been created via terraform (the alternative is that this is my dev/prod…)
2. The module root.vpc has no resources. There is nothing to taint.
3. The only file I modified was main.tf ```

   ——— Complete example to create Beanstalk —————-

   https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment

provider “aws” { region = “eu-west-1” profile = “terraform” }

variable “max_availability_zones” { default = “2” }

variable “namespace” { default = “eg” }

variable “stage” { default = “dev” }

variable “name” { default = “test” }

variable “zone_id” { type = “string” description = “Route53 Zone ID” }

data “aws_availability_zones” “available” {}

module “vpc” { source = “git::https://github.com/cloudposse/terraform-aws-vpc.git?ref=tags/0.4.1” namespace = “${var.namespace}” stage = “${var.stage}” name = “${var.name}” cidr_block = “10.0.0.0/16” }

module “subnets” { source = “git::https://github.com/cloudposse/terraform-aws-dynamic-subnets.git?ref=tags/0.10.0” availability_zones = [”${slice(data.aws_availability_zones.available.names, 0, var.max_availability_zones)}”] namespace = “${var.namespace}” stage = “${var.stage}” name = “${var.name}” region = “us-east-1” vpc_id = “${module.vpc.vpc_id}” igw_id = “${module.vpc.igw_id}” cidr_block = “${module.vpc.vpc_cidr_block}” nat_gateway_enabled = “true” }

module “elastic_beanstalk_application” { source = “git::https://github.com/cloudposse/terraform-aws-elastic-beanstalk-application.git?ref=tags/0.1.6” namespace = “${var.namespace}” stage = “${var.stage}” name = “${var.name}” description = “Test elastic_beanstalk_application” }

module “elastic_beanstalk_environment” { source = “git::https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment.git?ref=tags/0.13.0” namespace = “${var.namespace}” stage = “${var.stage}” name = “${var.name}” zone_id = “${var.zone_id}” app = “${module.elastic_beanstalk_application.app_name}”

instance_type = “t2.small” autoscale_min = 1 autoscale_max = 2 updating_min_in_service = 0 updating_max_batch = 1 loadbalancer_type = “application” vpc_id = “${module.vpc.vpc_id}” public_subnets = “${module.subnets.public_subnet_ids}” private_subnets = “${module.subnets.private_subnet_ids}” security_groups = [”${module.vpc.vpc_default_security_group_id}”] solution_stack_name = “64bit Amazon Linux 2018.03 v2.12.12 running Docker 18.06.1-ce” keypair = “”

env_vars = “${ map( “ENV1”, “Test1”, “ENV2”, “Test2”, “ENV3”, “Test3” ) }” } ```

as per the rest of the code, it’s genuine cloudposse

what’s the output of terraform output?

what’s the output of terraform plan?

…and the plan

the console output (not the JSON file) when you run terraform plan?

t plan -out plan

t plan > plan

what’s the output from terraform destroy? (without saying yes, just the destroy plan)

a few more things:

1. Update these vars ``` variable “namespace” { default = “eg” }

variable “stage” { default = “dev” }

variable “name” { default = “test” } ```

those are just examples, you need to specify your own namespace, stage and name - otherwise there could be name conflict with other resources created by using the same example

1. In your code, you use diff regions

and for the subnets

region              = "us-east-1"

everything should be in one region

make a var region and use it eveywhere for all modules and providers

@[Gamifly] Vincent once you fix those two issues, run terraform plan/apply again

[Sorry, was on phone]:

1. as per the example vars, I added those to main.tf ; I override them via terraform.tfvars
2. I did not see about the subnet region, thanks ; I have a doubt that it is taken into account as I always get prompted, for a region selection, whenever I run a command
3. ``` $ t destroy provider.aws.region The region where AWS operations will take place. Examples are us-east-1, us-west-2, etc.

Default: us-east-1 Enter a value: eu-west-1

data.aws_iam_policy_document.service: Refreshing state… data.aws_elb_service_account.main: Refreshing state… data.aws_region.default: Refreshing state… data.aws_availability_zones.available: Refreshing state… data.aws_iam_policy_document.ec2: Refreshing state… data.aws_iam_policy_document.default: Refreshing state… data.aws_iam_policy_document.elb_logs: Refreshing state… data.aws_availability_zones.available: Refreshing state… ```

(I just edited 1. , first answer was wrong)

fix region (the same region for all resources and providers), update namespace/stage/name and run terraform plan/apply again let me know the result

Back to the beginning and why I first came here !

Error: Error applying plan:

1 error occurred:
        * module.elastic_beanstalk_application.output.app_name: Resource 'aws_elastic_beanstalk_application.default' does not have attribute 'name' for variable 'aws_elastic_beanstalk_application.default.name'



Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

@Andriy Knysh (Cloud Posse) I re-run apply

@[Gamifly] Vincent send me your complete code (the one you ran), I’ll take a look when have time

Ok ; I actually used that as a main: https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment/tree/master/examples/complete The only difference is that I added variables to override in tfvar

Thanks for your time

did you change the region to be the same for all modules and providers?

I think so

re: aws_elastic_beanstalk_application.default: InvalidParameterValue: Application gamelive-dev-gamelive-test-dev already exists - it says the application with that name already exists

what’s var.region?

and why don’t you use it in

provider "aws" {
  region  = "eu-west-1"
  profile = "terraform"
}

as well

I didn’t do that update after you indicated me that the subnets were using another region, my bad

ok, all modules and providers have to use just one region

make a var region and default it to the region you want

use the var for subnets module

and use it for the provider as well

make sure if you have region anywhere else, use the same var

yes, I’ve just done it, thx

Did you run plan and apply after you fixed the region?

yes

I got back to the very first error I had:

Error: Error applying plan:

1 error occurred:
        * module.elastic_beanstalk_application.output.app_name: Resource 'aws_elastic_beanstalk_application.default' does not have attribute 'name' for variable 'aws_elastic_beanstalk_application.default.name'



Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

What’s the error? That the application already exists?

When I rerun, the error is that the application already exists

@[Gamifly] Vincent i just ran the example here https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment/blob/master/examples/complete/main.tf without any modification except I changed the namespace to something unique

terraform apply without the errors you saw

(BTW, if you use the same namespace, stage and name, it will fail because the bucket eg-dev-test already exists in AWS and all bucket names are global

Ok, sounds like I was not in luck ! Have you tried to destroy and apply again ? If the error was an already existing bucket, wouldn’t the error be related to S3 buckets ? Thanks agin for your help

Ok, I tried:

• add a S3 backend,
• change namespace / name I still get the same error: ``` module.subnets.aws_network_acl.private: Creation complete after 1s (ID: acl-0889fc9cefc38c3d8) module.subnets.aws_network_acl.public: Creation complete after 2s (ID: acl-000584f9e2f8afb4c) module.elastic_beanstalk_application.aws_elastic_beanstalk_application.default: Still creating… (10s elapsed) module.elastic_beanstalk_application.aws_elastic_beanstalk_application.default: Still creating… (20s elapsed) module.elastic_beanstalk_application.aws_elastic_beanstalk_application.default: Still creating… (30s elapsed) module.elastic_beanstalk_application.aws_elastic_beanstalk_application.default: Creation complete after 30s

Error: Error applying plan:

1 error occurred: * module.elastic_beanstalk_application.output.app_name: Resource ‘aws_elastic_beanstalk_application.default’ does not have attribute ‘name’ for variable ‘aws_elastic_beanstalk_application.default.name’ ```

I’m getting to the point of thinking that the error cannot only be on me

Yes I applied and destroyed a few times using the example (but changed the namespace)

Never got the error you see

Something is wrong with your state file

You can show the exact, meaning 100%, code you use so I’ll take a look

Also suggest to throw away the state file and start from scratch and see what happens

By using an S3 backend, I started with a scratch state file ; I moved m main.tf and tfvars into another folder, to scratch the whole project but the conf, maybe this will make a difference.

Here is the full project link: <https://www.dropbox.com/s/tkhq2f10fvtc3rt/terraform.zip?dl=0> Last thing I did:

• destroy everything
• change all the variables
• change the region
• apply –> same error

Could this be related to using tf with windows 10 ?

What terraform version and AWS provider version are you using?

Hey aknysh, any new idea on the subject ?!

I have given admin access to the user…and it works.

There is a very misleading error here ; I created the user step by step with each auth required one by one

@Andriy Knysh (Cloud Posse) just to be sure you’ve seen the last messages

@[Gamifly] Vincent re: I have given admin access to the user…and it works.

what other errors do you see?

the IAM user under which you provision the resources needs to have all the required permissions

we usually give such user an admin access

At first I just gave the required permissions, by running apply until it broke to ask such permission.

There is no other error, the misleading one I was speaking about was one we were trying to solve

if you give the user the admin permissions, and everything else regarding users/permissions is correct, it should not ask for any other permissions and apply should complete

That is my point: something was incorrect with the permissions before I did grant admin rights, but the error was module.elastic_beanstalk_application.output.app_name: Resource 'aws_elastic_beanstalk_application.default' does not have attribute 'name' for variable 'aws_elastic_beanstalk_application.default.name' instead of the usual permission error

I’m not sure about my wish to give admin rights to a user that should only timely modify the architecture ^^

well, then you have to find out all the required permissions the user will need for all services you deploy (which could be not an easy task)

and once you add new AWS resources to deploy, you’ll have to find and specify new permissions again

that is not scalable

@Erik Osterman (Cloud Posse) here’s the working version. Basically we need these permissions added to the exec role. I’ll get around to PR’ing the exposure of those so we don’t have to manually recreate it.

data "aws_iam_policy_document" "replicator_ssm_exec" {
  statement {
    effect    = "Allow"
    resources = ["*"]

    actions = [
      "ssm:GetParameters",
      "secretsmanager:GetSecretValue",
      "kms:Decrypt",
    ]
  }
}

resource "aws_iam_role_policy" "replicator_ecs_exec_ssm" {
  name   = "${local.application_name_full}-ssm-policy"
  policy = "${data.aws_iam_policy_document.replicator_ssm_exec.json}"

  role = "${local.application_name}-replicator-dev-exec"
}

Awesome! Glad you figured it out. Lookforward to the PR

Cool! I see Erik and Andriy had a look

no, but LMK if you find something

I’ve been getting super confused trying to translate https://github.com/aws/aws-app-mesh-examples/blob/master/examples/apps/colorapp/ecs into Terraform

I can translate that to terraform for ya. Have you started yet?

@cabrinha @Erik Osterman (Cloud Posse) I’ve started on the appmesh module https://github.com/bitflight-public/terraform-aws-app-mesh

@jamie wow dude thanks a lot!

I’m going to test this out.

its not finished

But you can look through it

its missing the resources for the app mesh virtual services

There is a lot I still don’t understand about AppMesh

namespace, stage, I hope we can make these values configurable or have the ability to leave them blank

and, if you keep waiting I’ll have the example folder create an ecs cluster, create the services in it with the envoy sidecars and the xray sidecars and the cloudwatch logging, and the rest of that colorteller app

Similar to what we did here: https://github.com/cloudposse/terraform-aws-efs/pull/25

@jamie you’re a saint

Yeah theres already an override for the naming

So yeah. You can’t leave the label name blank, but you can override it

Anyway… I have to stop for now on making this. I have a Dockerfile I need to update for a client

if only that would always be possible

Thanks! Will see what he says.

@Andriy Knysh (Cloud Posse) you didn’t run into this?

no

not with dynamic subnets

I had this issue when running the examples on my computer

prompting for region every time

I guess since we always set AWS_REGION we don’t notice it

yes

deployed atlantis many times using the subnet module https://github.com/cloudposse/terraform-root-modules/blob/master/aws/ecs/vpc.tf

@jamie @loren what are your thoughts on provider pinning at the module level?

We’ve been plagued by constant regressions with every aws provider release

its a good idea

I have fixed the issue with it in my pull request

sec

PR#54?

I always pin the explicit version for the aws provider in my root module, and test updates there. I don’t worry about it in the module, I’m fine if a known min version is documented in the readme

@Erik Osterman (Cloud Posse) just tested, if you define a provider w/o region in a low-level module, like this

provider "aws" {
  version = "~> 2.12.0"
}

and then define a provider in top-level module that uses the low-level module

provider "aws" {
  region = "us-east-1"
}

it will ask for region all the time

(the top-level region does not apply, they don’t merge)

Can you try adding region, default it to "", then see if it uses the AWS_REGION env

if that’s the case, maybe we use that pattern

that way it works both ways

will try now

@Andriy Knysh (Cloud Posse) did this work?

@loren - the fix is to pass providers explicitly, which is a new feature in 0.11.14

https://www.terraform.io/docs/configuration-0-11/modules.html#providers-within-modules

@jamie heads up

ah, @loren just saw your comment here: https://github.com/cloudposse/terraform-aws-dynamic-subnets/issues/56#issuecomment-501342606

Nice!

How do you want the module changed? Remove the provider, or keep the provider?

the example was broken too. it runs now, though

Lgtm

pushed lint fixes

bump @Andriy Knysh (Cloud Posse)

cut 0.12.0

Thanks for the office hours, that was very helpful!

Great you stopped by @Blaise Pabon!

Currently that is true.

ok I do not see a reason no to have it

I mean adding it it will not break anything

Can someone explain me how this module work ? I wanted to send a PR to add the Docker labels but I do not understand how the json is being rendered with replace, thanks

@Erik Osterman (Cloud Posse) @Andriy Knysh (Cloud Posse) Did one of you guys write this module?

I was reading last night and I seem to understand now

I could just add :

plus the local value

I guess

like:

Delete the state file, and import the resources using tf 0.11?

mmm, that might work

ah, interesting technique.

Same. we were pinning to 0.11.x, then we ended up with three different x in our various Terraform roles. I just pinned them all to 0.11.14 this week

run apply with terraform 0.12, if it succeeds, your state now requires tf 0.12. if it fails, your state is not updated

yes, have been using it for almost a year

damn, please share these goodies more often

I had to use this because the fmt is broken in 0.12 and the ci was complaining about my commits ( yes I’ve been spoiled by the fmt ) so I had to revert to 0.11 for work projects

You should just attend my meetups

https://www.slideshare.net/AntonBabenko/terraform-aws-modules-and-some-bestpractices-may-2019 - slide 108

Yes @Erik Osterman (Cloud Posse) went with the convention that seems to be most popular on using master for the current latest, and branch 0.11/master for the latest of the 0.11 terraform

But pinning it to a release tag is always the best option.

Did you solve this issue?

Do you still need help with this?

take a look at his example https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment/blob/master/examples/complete/main.tf

all you need to do is to change the image from Docker to NodeJS

You just need to add /32 to each one right?

We are adding users one by one by creating a separate module for each user, e.g. https://github.com/cloudposse/root.cloudposse.co/tree/master/conf/users/overrides

when we run it, the users is added to the required groups

that way we can add/remove users from groups without touching other users and without changing group lists

we did it only for users

https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/users/README.md

@cytopia

@maarten thanks for starting the conversation.

The only downside I currently see with this approach is when it comes to deleting users.

If all users where managed by a single module defines in terraform.tfvars as a list of items (dynamically generated Terraform code with independent resource blocks, so you don’t hit the issue of resource re-creation by changing a list in between) I could simply delete an entry, regenerate the code and create a pull request to be reviewed. Upon merge and deploy, that user will be deleted.

With the multiple module approach I will probably have multiple directories and when deleting a directory and push the changes to git, nobody can actually delete that user, because you will have to terraform destroy in that directory before deleting it.

How do you handle that situation with the multi-module approach?

@cytopia https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/users/README.md is an actual single root module approach with multiple ‘user-module’ definitions. Users will be hardcoded in tf directly as there won’t be any re-usability possible.

Re: With the multiple module approach I will probably have multiple directories and when deleting a directory and push the changes to git, nobody can actually delete that user, because you will have to terraform destroy in that directory before deleting it.

This will always be the case with every root module you create, hence first destroy then delete.

I am just thinking around how well that would work if you had something like Atlantis setup for auto-provisioning on Pull requests.

In that case you would always have the need for manual provisioning before a review has actually happened.

when using a single root module approach for users, or iam in general you don’t have this problem

How would that would eliminate the need for manual provisioning before review/merge for deleting users/roles?

As I’ve stated above, you would probably need to terraform destroy manually and locally, then remove the directory, git commit and push. Or am I mistaken here?

I think you’re not capturing what I meant. With the single root module approache with multiple users, one justs add a user and deletes a user and only terraform apply is used. The state of the iam root module itself does not need to be destroyed to delete a user

for example https://github.com/cloudposse/terraform-aws-dynamic-subnets/blob/master/nat-gateway.tf#L14

https://github.com/cloudposse/terraform-aws-eks-cluster/blob/master/examples/complete/main.tf#L33

merge the tags https://github.com/cloudposse/terraform-aws-eks-workers/blob/master/main.tf#L2

then provide it to the label https://github.com/cloudposse/terraform-aws-eks-workers/blob/master/main.tf#L13

Variables not allowed

on <value for var.security_groups> line 1: (source code not available)

we (Cloud Posse) are mostly AWS shop with a bit of GCP

i’m sure there are many people here who use Azure

also have a look at our archives

https://archive.sweetops.com

Thanks @Erik Osterman (Cloud Posse), appreciate that mate!

@endofcake is also in NZ and serious terraformer

Awesome, thanks Erik, @endofcakeyou going to be at DevOps days?

Hi @Callum Robertson , not sure yet. I went to the first conference and it was really good. Will have to think whether I can afford the second one though.

show the exact error. what TF version are you using?

Terraform v0.12.2

• provider.aws v2.15.0

We are working on same project

Error: Variables not allowed

on <value for var.private_subnets> line 1: (source code not available)

Variables may not be used here.

https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment has not been converted to TF 0.12 yet

Getting below error var.private_subnets List of private subnets to place EC2 instances Enter a value: 1

Error: variable private_subnets should be type list, got number

you using TF 0.12?

YES

the modules are not converted to TF 0.12 yet

we are working on it now

okay

is it resolved yet ?

No, We have copied 0.11.3 binary terraform .