#terraform (2018-07)

@ag4ve.us has joined the channel

@zerocoolback has joined the channel

@jonathan.olson has joined the channel

@achrstl has joined the channel

@jamie here’s the TF channel

@jamie has joined the channel

Oh hi! I can keep my terraform troubleshooting to here without disturbing your geodesic users :)

We can try - just sensitive to splintering off eyeballs until we have more critical mass

but it is nice to keep the threads separated

yea, perhaps it’s time. just like we started using #random <— nice

@Andriy Knysh (Cloud Posse) has joined the channel

@tamsky has joined the channel

@Cristin has joined the channel

@Cristin which module are you having trouble with?

(i’m about to jump on a call - so may be delayed in following up)

@Andriy Knysh (Cloud Posse) can also help

I’m using elastic-beanstalk-environment and I’m getting some error related to aws_iam

@Cristin uploaded a file: Untitled

I took a look over the parameters and the code of the module, but I don’t see a way of passing a aws_iam_role_policy_attachment or profile

@Cristin i’ll look into the error (little bit later), but for now you can look at this repo where we use elastic-beanstalk-environment: https://github.com/cloudposse/terraform-aws-jenkins/blob/master/main.tf

examples here https://github.com/cloudposse/terraform-aws-jenkins/tree/master/examples

I took a look over the example and how you are attaching a policy to the ec2 instances. I tried doing the same thing but I still get the above errors

@Cristin can you share your code? If not public, you can message me or send email to [email protected], I’ll take a look

@Cristin uploaded a file: Untitled

@Andriy Knysh (Cloud Posse) Here it is

Thank you!

@maarten has joined the channel

@Andriy Knysh (Cloud Posse) I managed to make it work by using the configuration you used in the Jenkins example

Thank you for you help!

@Cristin sorry I did not help you yet, just wanted to look at your code in more details (from what I saw briefly, you mixed a lot of concepts)

glad the jenkins examples hepled

@Andriy Knysh (Cloud Posse) I still have one question. How is the best way of connecting the elasticbeanstalk envirment to a RDS database? Just create the database and inject in env vars the database connection details?

we have https://github.com/cloudposse/terraform-aws-rds to create an RDS database (no Aurora)

also https://github.com/cloudposse/terraform-aws-rds-cluster to create an Aurora cluster

usage example is here https://github.com/cloudposse/terraform-root-modules/blob/master/aws/backing-services/aurora-postgres.tf

yes, the best way is to put the RDS credentials (username, password, etc.) in ENV vars, and then in Elastic Beanstalk environment add those ENV vars to the environment. Then read them in your app

like we do here https://github.com/cloudposse/terraform-aws-jenkins/blob/master/examples/new_vpc_new_subnets/main.tf#L41

(you can add any number of ENVs)

we try to follow 12-factor https://12factor.net/

Awesome, thank you for all this details

so first create an RDS cluster https://github.com/cloudposse/terraform-aws-rds-cluster

it will output the credentials

add the ENVs here https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment/blob/master/variables.tf#L248

at Cloud Posse, we use chamber to securily work with ENV vars and secrets

https://github.com/segmentio/chamber

take a look at our docs https://docs.cloudposse.com/tools/chamber/

https://docs.cloudposse.com/reference-architectures/cold-start/

Awesome information, thanks a lot!

geodesic supports chamber natively https://github.com/cloudposse/geodesic

when you provision an RDS cluster from geodesic, you add the ENVs to chamber

https://github.com/cloudposse/terraform-root-modules/blob/master/aws/chamber/chamber-backing-services.sh

then you provision terraform-aws-elastic-beanstalk-environment from geodesic, you read the ENVs from chamber

@krogebry has joined the channel

@Andriy Knysh (Cloud Posse) Thank you for all the help! For now I setup a simple RDS postgress db an injected the env variables in a ebs env

I still have a question, related to setting up multiple envs like “develop” and “production”

I noticed that I can create one ebs application and create multiple environments for it

But in this situation I don’t understand what’s the role of the stage attribute for the elastic_beanstalk_application module

stage is to separate the resources b/w diff stages - see the latest discussing in #announcements

also, by using diff stage, e.g. dev and prod, you can deploy the same environment two times for development and production

you need to deploy it two times obviously

Yes, I know this. But if I have 1 application and 2 environments for it, what’s the role of having stage setup on the application itself?

We generally do not prescribe using a single beanstalk for multiple stages even though it is supported

stage is used in all resource names by using the label module. So (almost) all resources will be names like namespace-stage-name

so, if you use the same AWS account and the same EB application to deploy two environments into it, then stage could be anything you like - but as @Erik Osterman (Cloud Posse) mentioned, we don’t usually do it

we try to completely separate stages

Ok, I understand. So is a best practive to have 1 app = 1 env

even using diff AWS accounts for more security and control

Yes - that way they share nothing so making changes to one can never impact the other

and much easier to control IAM

Also, have you seen our modules for ECS

?

Sorry, which one? I looked over a lot of your modules, they are really helpful

Since you are starting from scratch, I would consider using ECS rather than Beanstalk.

https://github.com/cloudposse/terraform-aws-ecs-web-app

Well, the Beanstalk is actually a requirment on the project I’m doing, so I will try ecs on the next one

Ok, so if I will create seperate resources (security group, vpc, db, app, env) for each stage what would be the best way to run this twice and not having to duplicate the code? Should I create a module around your modules ?

@Cristin we still recommend to separate all resources into at lest two stages (dev and prod) and don’t mix anything b/w/ them

take a look how it’s separated here https://github.com/cloudposse/staging.cloudposse.co

in Dockerfile https://github.com/cloudposse/staging.cloudposse.co/blob/master/Dockerfile

we use ENV vars for stage too

https://github.com/cloudposse/prod.cloudposse.co/blob/master/Dockerfile#L18

Ok, I will look into this. Thanks a lot again for your time and availability to help

no problem

the container + env vars pattern is our approach to DevOps orchestration and env separation (there could be other ways of doing it)

geodesic is that container, with much more tools inside

@Yoann has joined the channel

we just released https://github.com/cloudposse/terraform-aws-elasticsearch

@Erik Osterman (Cloud Posse) are we going to release that null-label branch we made together that adds context as a variable?

yea, i was just holding off since it was “complicated”

but we can merge

@jamie do you want to add environment?

(in a follow up PR)

I did yeah :)

Is his change by @dennybaa in that commit not needed?

He pushed his change through…. its in now

whoot!

so, one more test and then approve?

(i can’t approve, since I opened the PR)

I have just pushed the changes

I have updated the readme to include the new features too

tested and working?

yeah, using the example

./examples/complete

cool

ok, you can approve, merge, and tag a new minor release

Minor?

What constitues a major?

haha, i know…

just i don’t want to go to 1.0.0 yet

thats like… only got the same variables as the original

so, we say pre 1.0

okay

so we are at 0.3.8 now, this should be 0.4.0

i am not yet sure what constitutes a 1.0.0 release - we don’t yet have any

probably a topic for another day… but some considerations are “stable interface”

so if we plan on adding a bunch more parameters, feels like the interface is not yet stable

You need a new “Definition of done”

https://github.com/cloudposse/terraform-null-label/releases/tag/0.4.0 @Erik Osterman (Cloud Posse)

thanks @jamie!

@jamie I missed something maybe in that release… or at least let’s discuss

local.namespace, local.environment, local.stage

Seems to me that stage is more broad than environments

So it should come before environment

No?

@tamsky have any insights

Hrmm I guess I can see pros and cons both ways

What would be a real-life example of using both at the same time?

@sarkis has joined the channel

the challenge here is what we do with our 100 terraform modules that don’t yet support environment

@tamsky any insights on ordering? namespace-stage-environment or namespace-environment-stage

In your terraform modules you can just leave it out

It can be either. But other companies may use both when stage is being referred to as the disposable type of stage. Like source, build, deploy. Or extract, transform, load. Or raw, resized, thumbnail.

https://github.com/firmstep-public/trainingdayfour in progress…

@jamie @tamsky I understand the thinking about having stage and environment at the same time. But IMO it just complicates everything. You are saying that stage could refer to source, build, deploy, extract, transform, load. raw, resized, thumbnail. Those seem to be stages in an CI/CD pipeline or some other process of transforming data or building/deploying some artifacts. As I see it, they don’t relate to infrastructure environments that we deploy with Terraform. Are you saying that we need to deploy some TF resources with names like cp-prod-deploy-myapp, cp-prod-load-myapp? Sounds like parts of a pipeline, not a separate set of AWS resources

what would be a real example of using names like these in a real infrastructure having separate stages/environments like dev, prod?

@Arkadiy has joined the channel

thanks @jamie

looks like all of that stage vs. environment stuff is used mostly for tagging, not for naming

which are diff things

ya

@loren has joined the channel

@Ruslan has joined the channel

Hi Everyone! First of all - big thanks for Terraform scripts on Github! It was invaluable source of knowledge and easy to use as is too.

Come to talk about terraform-null-label and name sequence

any insights on ordering? namespace-stage-environment or namespace-environment-stage

In my opinion this should be configurable, because on the projects I am on right now we have namespace-app-stage.

I`ve created issue on GitHub for that: https://github.com/cloudposse/terraform-null-label/issues/35

@Ruslan I have been considering this as well

To me, it’s most natural to move the environment after the stage

But allowing order to be overridden would be also a nice feature

@jamie

No problem

I’ll give it a pattern variable

Personally I believe namespace-stage-app is proper way (because stage/env is the isolated space in which all the apps are working). But on the current project it is done as namespace-app-stage.

hey folks! does anyone know of tooling that helps create a terraform state file, based on a given terraform configuration, by importing existing resources?

we have a number of accounts with resources we can’t recreate, but we’re just getting started with terraform (switching from cloudformation). we’ve written terraform modules to manage everything, and it works great for new accounts, and now we’re looking into how we can extend it to prior accounts…

terraform state list gives all the resource names, which seems to work with terraform import. however, it also outputs all the data source names (with no differentiation between resources and data sources), which don’t need to be imported

@loren that is what terraforming does, http://terraforming.dtan4.net/

ahh thanks, i looked at that earlier, but it didn’t seem like quite what i needed… i’ll give it a try and see how it goes

i don’t want to import all resources of a particular type, and i don’t want the resources in the root module, which is what the examples look to be doing

but perhaps it has more options

seems not, unfortunately. any other tools?

You can use it to import everything, and then just manually edit the state file to only include the ones you want.

Its about all we have at the moment

@Ruslan @Erik Osterman (Cloud Posse) I’ve created a pull request that adds that feature you were after https://github.com/cloudposse/terraform-null-label/pull/36

I will take a look as soon as I get into the office

Yes, it works, Ive tried it. <https://github.com/cloudposse/terraform-null-label/pull/36#issuecomment-408472191> However I am using label through terraform-aws-cicd and terraform-aws-codebuild` projects and need support in them for label_order.

Should I add issue (or even better, PR) to these projects as well?

Yes we will accept PRs

Issue not needed

Regarding label module, I have an idea I want to test before I comment

But currently afk

For the label module, it looks now it would be better to just add a few parameters, p1, p2, p3, p4, p5, etc. and use them as we want. Instead of assigning a meaning to all of them and then decide on the order?

No

100% want meaning

I was just reflecting on this point

The thing is we need to standardize nomenclature

This is what I love about @jamie document for this

Even if I disagree with ‘environment’

However I have an idea based on what you say @Andriy Knysh (Cloud Posse)

Will whip up prototype to express how this should be working

I think it will satisfy everyone but might belong in a new module

Ok

Why naming is so hard :)

@Ruslan once the guys have reviewed the pull request and its good to add, we can start updating the other modules to be compatible with context.

which will allow you to pass in a label modules context and use that for formatting.

@johntellsall has joined the channel

@fernando thanks for adding the test case to https://github.com/cloudposse/terraform-aws-ecs-container-definition/pull/9

I’m just about to step out the door for the evening, so will take a look tomorrow.

Sure thing, let me know what you think, and enjoy the rest of the evening!

Okay! I took a look. Looks good, almost exactly what we needed. Let’s add test case for quoted numbers and booleans as well.

@i5okie thanks for joining! Saw your comment on the issue here: https://github.com/cloudposse/terraform-aws-elastic-beanstalk-environment/issues/42

Let me know if I can be of assistance.

yeah we had an older release of the module. i just copied the lifestyle block there

Is it working now with the latest release?

i didn’t update to latest release (long story short, cant lol) but i copied the fix across. and its working now. thanks

ok, great!

https://github.com/cloudposse/terraform-aws-iam-assumed-roles/issues/6

Would like feedback on this. Am I missing something here?

@pmuller has joined the channel

one thing i’d like to do here is to restrict aws account usage by source ip address

if your users all work in the same office

you could restrict mfa management to your office ip address

yea, that could be an enhancement

that way an attacker should steal api keys or password + be physically close to your office and hack your wifi to abuse your aws account

one thing I’ve loved about Duo is the ability to do geofencing

did not try this yet but i’d like to do this here

Duo ?

yea, they are a MFA saas

(and now also do SSO)

http://duo.com/

We have support for this in our bastion container: https://github.com/cloudposse/bastion

so basically Duo will store your users secret mfa keys?

yep

and offer multiple forms of 2FA

you can choose which ones you allow

interesting ! (i dropped the google authenticator idea precisely because i was afraid of storing those mfa secrets)

you can also require, for example, that their MFA device is up to date

that their OS is current

etc..

so policy management at a higher level

yea, GA is a nice contribution by google, but seriously difficult to truly secure.

Also, are you familiar with Teleport for SSH?

their current os ? is it using TNC ?

their = ?

This “their”

how Duo is checking for OS version ?

since one factor is mobile push notifications

they can get a lot of metadata

including gps location

OS version

authenticator version

device os

etc

very interesting

about teleport, i would like to use it and log everything with it, but haven’t taken time to try it yet

my current compromise is logging a lot with auditd and pam_audit_tty

that’s from Duo ?

yea

nice!

maybe i am a bit too paranoid for the cloud era … i grew up in datacenters, and started using aws in 2016 … but i still have too much of the data center / oss guy thinking: DIY ! so at first i even had a hard time trusting AWS (then I realized how absurd it was..) let alone talking about a 3rd party for authentication

but yeah, i sometimes feel like i am wasting my time

[override.tf](http://override.tf) appears to have no impact/influence over terraform { ... } block

too bad

cannot terragrunt be helpful with your sed hack? (haven’t tried it yet)

i am not well versed in terragrunt

i know terragrunt can do what our module does out of the box

but i like that we’re defining the infrastructure for bucket/dynamodb with terraform rather than another tool

i like ideas terragrunt brings on the table, but i know from experience it’s better to use vanilla tools in the long term … wrappers comes and go … and creates debt!

yes - agree

i would consider using it for specific cases such as this

small in scope

i’d be happy to hear about your feedback

btw, do you test your tf modules ? if so, how ? (doing so with all the code i write… except tf, so it’s frustrating)

we’re not quite there yet. right now, we do lint testing only.

same here

not even that … we just run “terraform fmt” and check if there is a change in the repo

i feel poor with just this

See our plan of attack here: https://sweetops.slack.com/archives/CB84E9V54/p1532332704000172

in the #geodesic channel

basically, we package all infrastructure in a container along with terraform

thus, it’s an app like everything else

our strategy is to use our testing account to run: plan, apply, plan, destroy, plan

I am less enthused by atlantis and terratest

haven’t heard about atlantis

terratest requires to write tests in go, which is rather unpleasant

lunch time, bbl

cool, ttyl!

ior have a good night

(yea, I’m in Los Angeles)

https://github.com/wata727/tflint

https://github.com/akaspin/terraform-provider-generic

this is an interesting concept. it reminds me of the “porcelain” plugin module used in helm, but applied to terraform providers

using this, it’s possible to define a “basic” provider in any language, and then accept targets like apply, destroy, etc

the implementation above seems like a POC, but if anyone else has seen one, lmk

note, this is very different from the data external provider which does not distinguish between phases

oh nice!

Related to the earlier question of terraform cicd, this looks interesting

https://github.com/mercari/tfnotify/blob/master/README.md

This will take the output of terraform plan/apply and post it back to GitHub or Slack.

@Andriy Knysh (Cloud Posse) wrote a generic tool for this, not specialized for terraform called ‘github-commenter’