#geodesic - December 2018 | Slack Archive

geodesic

431 messages

Discussions related to https://github.com/cloudposse/geodesic

Archive: https://archive.sweetops.com/geodesic/

Nov 2018

December 2018

Jan 2019

erikover 7 years ago

set the channel topic:

https://github.com/cloudposse/geodesic

Janover 7 years ago(edited)

rgr

Erik Osterman (Cloud Posse)over 7 years ago

for starters, what i’m thinking to standardize is the discrepancy between what is TF_VAR_ and not.

Janover 7 years ago

so I am carrying on with the coldstart setup currently

Janover 7 years ago

yes, that would already go a long way

Erik Osterman (Cloud Posse)over 7 years ago

i find we have to do a lot of mapping. my thinking is to focus on some canonical variables that are not TF_VAR_ prefixed

Janover 7 years ago

if the one picked isnt great can always change em, all at the same time

Janover 7 years ago

that could make a lot of a sense

Erik Osterman (Cloud Posse)over 7 years ago

and then make it easier to access all envs from terraform.

Erik Osterman (Cloud Posse)over 7 years ago

@Jan what do you think of the pipelining we’re doing?

Janover 7 years ago

Honestly I have yet to get that far 😛

Erik Osterman (Cloud Posse)over 7 years ago

basically, things like chamber exec kops -- helmfile exec ...

Erik Osterman (Cloud Posse)over 7 years ago

then helmfile calls helm

Erik Osterman (Cloud Posse)over 7 years ago

it’s a lot of layers, but it’s also very UNIXy

Janover 7 years ago(edited)

so I mean in general I like to have as few moving parts as possible

Janover 7 years ago

as simple as possible, as complex as necessary

Janover 7 years ago

that sorta vibe

Erik Osterman (Cloud Posse)over 7 years ago

https://github.com/cloudposse/geodesic/issues/317

Erik Osterman (Cloud Posse)over 7 years ago

can you jot down any thing that comes to mind?

Janover 7 years ago

will do

Janover 7 years ago

Mondays "refresh my memory" issue is I cd into testing/ make init | docker/build | install

Janover 7 years ago

and I dont have a testing image locally built

Janover 7 years ago

and yes the ENV DOCKER_IMAGE= is set

Janover 7 years ago

I recall running into this before

Erik Osterman (Cloud Posse)over 7 years ago

hrm…

Erik Osterman (Cloud Posse)over 7 years ago


make init
make docker/build install

Erik Osterman (Cloud Posse)over 7 years ago

that should result in both an image locally and a script installed to /usr/local/bin/xxxx

Erik Osterman (Cloud Posse)over 7 years ago(edited)

what is the error you get when running xxxx?

Erik Osterman (Cloud Posse)over 7 years ago

what I’ve seen happen is that the image that was built was with some tag Y

Erik Osterman (Cloud Posse)over 7 years ago

by the DOCKER_IMAGE env is referencing some tag Z

Janover 7 years ago

so afterwards I end up with


 docker images
REPOSITORY                          TAG                 IMAGE ID            CREATED             SIZE
cloudposse/testing.cloudposse.co    latest              938b6ad92d1a        26 minutes ago      1.08GB
jdnza/root.aws.tf                   latest              4e5bad3816ca        5 days ago          1.12GB

Janover 7 years ago

the error on make install

Janover 7 years ago


make install
Password:
# Installing testing.aws.tf from jdnza/testing.aws.tf:latest...
Unable to find image 'jdnza/testing.aws.tf:latest' locally
docker: Error response from daemon: manifest for jdnza/testing.aws.tf:latest not found.
See 'docker run --help'.
# Installed testing.aws.tf to /usr/local/bin/testing.aws.tf

Janover 7 years ago

make docker/build results in


Successfully tagged cloudposse/testing.cloudposse.co:latest

Erik Osterman (Cloud Posse)over 7 years ago

ok, in the Makefile, i think something is set wrong.

Janover 7 years ago

AH!

Janover 7 years ago

yes now I recall

Janover 7 years ago


export CLUSTER ?= <http://testing.cloudposse.co|testing.cloudposse.co>
export DOCKER_ORG ?= cloudposse

Erik Osterman (Cloud Posse)over 7 years ago

so regarding this…. we’ve gone back and forth

Janover 7 years ago(edited)

where this was a pain was that in the docs it is never mentioned to update the Makefile

Erik Osterman (Cloud Posse)over 7 years ago

i like doing something like:


export CLUSTER ?= $(shell basename $(pwd))

Erik Osterman (Cloud Posse)over 7 years ago

etc..

Erik Osterman (Cloud Posse)over 7 years ago

but this is also more “magic”

Erik Osterman (Cloud Posse)over 7 years ago

what in your opinion is the right balance?

Janover 7 years ago

So I mean I would have the Makefile do so

Janover 7 years ago

I mean if you are for example already do a cp testing.cloudposse.co/ testing.aws.tf/

Janover 7 years ago

then make docker/build should quite happily just build with the pwd

Erik Osterman (Cloud Posse)over 7 years ago

ok, i’ll track this in that issue

Janover 7 years ago

export CLUSTER ?= $(shell basename $(pwd))

Janover 7 years ago

would solve it for all other envs

Janover 7 years ago

what to do for org though

Janover 7 years ago

this all makes me come back to my idea of having a coldstart module that renders all the coldstart resources with some high level inputs I provide

Erik Osterman (Cloud Posse)over 7 years ago

oh yes, coldstart module is top of mind

Erik Osterman (Cloud Posse)over 7 years ago

this is actually all feeding into that

Erik Osterman (Cloud Posse)over 7 years ago

i want to basically collect all the datapoints and then use that to create the module.

Erik Osterman (Cloud Posse)over 7 years ago

so asking for docker registry url is actually important

Erik Osterman (Cloud Posse)over 7 years ago

will add that

Janover 7 years ago

oki macbook battery is about to die, will switch to phone

Janover 7 years ago

something else...

Janover 7 years ago


cd account-dns
init-terraform
terraform apply

Janover 7 years ago

running without terraform plan is an anti-pattern that tf should be stopping with the info from the duynamodb table or not?

Erik Osterman (Cloud Posse)over 7 years ago

yes, so best practices are to run terraform plan -out... and then terraform apply planfile

Erik Osterman (Cloud Posse)over 7 years ago

I suppose from a consistency perspective, we should write the docs that way

Erik Osterman (Cloud Posse)over 7 years ago

is that what you’re suggesting?

Janover 7 years ago

https://github.com/cloudposse/geodesic/issues/318

Janover 7 years ago

yea

Janover 7 years ago

I would be consistent in that, wrapping other tools means that users will come with varying degrees "pre-trained" behavior. Generally I would avoid un-training best practices

Janover 7 years ago

k 2% battery, im out

Janover 7 years ago

is it possible to use geodesic with aws-vault and the osx keychain?

Erik Osterman (Cloud Posse)over 7 years ago

No, need to use the lowest common denominator which is file

Erik Osterman (Cloud Posse)over 7 years ago

We use that by default and use it between OSX and geodesic and Windows even :-)

Erik Osterman (Cloud Posse)over 7 years ago

(WSL)

Janover 7 years ago

kk, is it expected then that I need to enter my password on every aws-vault exec accountnamr -- command that need aws access

Janover 7 years ago

talking about using it outside of a geodesic container now

Janover 7 years ago

I have yet to have a chance to migrate all my credentials / env's over to this work flow pattern

Janover 7 years ago(edited)

very soon id like to have a executable bin per aws account/env

Erik Osterman (Cloud Posse)over 7 years ago

ah, yes, you do need to run with bash -l inside of geodesic

Erik Osterman (Cloud Posse)over 7 years ago

i think jan was running this natively

Erik Osterman (Cloud Posse)over 7 years ago

the -l is to load the /etc/profile.d scripts

Janover 7 years ago

So I have another interesting question.... I have a situation where I have 6 existing aws accounts I want to manage with geodesic. later I would want to import a full AWS org too

Janover 7 years ago

the "import" part is of interest to me to understand

joshmyersover 7 years ago

Could you describe a little more what you mean by import a full AWS org @Jan?

Janover 7 years ago

Well so to start with I have 1 divisions aws accounts I will want to manage, they already exist

Janover 7 years ago

They already are in an AWS org

Janover 7 years ago

I won't manage the org to start with

Janover 7 years ago

Just walking, gimme a few minutes

Janover 7 years ago

Actually I guess there is nothing to. Import

Janover 7 years ago

It's just where the top level. Iam user is

Janover 7 years ago

And what account the iam users are crated in

joshmyersover 7 years ago

Have you looked at using terraform import to create state for those resources once you want them managed. Once in the state, add the terraform resource config info geodesic

Janover 7 years ago

Yea that could solve it should I need to later

Andriy Knysh (Cloud Posse)over 7 years ago

@Jan there is some info about provisioning or importing an org in our docs https://docs.cloudposse.com/reference-architectures/cold-start/#provision-organization-project-for-root

Janover 7 years ago

Brilliant thanks

Janover 7 years ago

heya, on assume-role I am seeing this now


2018/12/05 13:55:44 Request body type has been overwritten. May cause race conditions

Janover 7 years ago(edited)


aws-vault: error: Failed to get credentials for admin (source profile for admin-users-bootstrap): RequestError: send request failed
caused by: Post <https://sts.amazonaws.com/>: dial tcp: lookup <http://sts.amazonaws.com|sts.amazonaws.com> on 8.8.8.8:53: read udp 172.17.0.2:40888->8.8.8.8:53: i/o timeout

Janover 7 years ago

Ah I think I know the issue

Janover 7 years ago

So the corporate network I am on does not allow using ANY dns other than the local one

Janover 7 years ago

forcing 8.8.8.8 times out

Janover 7 years ago

https://github.com/cloudposse/geodesic/blob/master/rootfs/templates/wrapper#L261

Janover 7 years ago

export DOCKER_DNS=${DNS:-8.8.8.8}

Janover 7 years ago

might want to rethink setting that as a default. Many corporates will not allow using an external DNS

Janover 7 years ago

https://github.com/cloudposse/geodesic/issues/320

Andriy Knysh (Cloud Posse)over 7 years ago

good point @Jan thanks, we’ll review it

Janover 7 years ago(edited)

@Andriy Knysh (Cloud Posse) what is TF_VAR_local_name_servers meant/intended to get populated by?

Andriy Knysh (Cloud Posse)over 7 years ago

you asking about just local or all TF_VARs like name_servers?

Janover 7 years ago

only local

Andriy Knysh (Cloud Posse)over 7 years ago

that’s for local dev environment, on local computers

Andriy Knysh (Cloud Posse)over 7 years ago

we can setup DNS for that so the devs would be able to test locally

Janover 7 years ago

Andriy Knysh (Cloud Posse)over 7 years ago

https://github.com/cloudposse/terraform-root-modules/blob/master/aws/root-dns/parent-local-ns.tf

Andriy Knysh (Cloud Posse)over 7 years ago

then in your browser you would go to <http://local.example.net|local.example.net> to see the app

Janover 7 years ago

yea I guess I left it in the setup im running through

Janover 7 years ago

mistakenly

Janover 7 years ago

😄

Janover 7 years ago

running though getting a setup going with 3 of my team mates

Andriy Knysh (Cloud Posse)over 7 years ago

nice

Andriy Knysh (Cloud Posse)over 7 years ago

let us know how it goes

Andriy Knysh (Cloud Posse)over 7 years ago

and thanks again for testing and finding all those issues

Janover 7 years ago

👍️

Janover 7 years ago


warning: adding embedded git repository: build-harness
hint: You've added another git repository inside your current repository.
hint: Clones of the outer repository will not contain the contents of
hint: the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use:
hint:
hint: 	git submodule add <url> build-harness
hint:
hint: If you added this path by mistake, you can remove it from the
hint: index with:
hint:
hint: 	git rm --cached build-harness
hint:
hint: See "git help submodule" for more information.

Janover 7 years ago

would having build-hardness in the .gitignore make sense?

Andriy Knysh (Cloud Posse)over 7 years ago

yep 100%

Andriy Knysh (Cloud Posse)over 7 years ago

https://github.com/cloudposse/terraform-root-modules/blob/master/.gitignore

Andriy Knysh (Cloud Posse)over 7 years ago

and in .dockerignore https://github.com/cloudposse/terraform-root-modules/blob/master/.dockerignore

Janover 7 years ago

yea I meant in the root.cloudposse.co

Janover 7 years ago

and those

Erik Osterman (Cloud Posse)over 7 years ago

@Jan https://github.com/cloudposse/geodesic/pull/321

Erik Osterman (Cloud Posse)over 7 years ago

@tamsky https://github.com/cloudposse/geodesic/pull/322/files

Erik Osterman (Cloud Posse)over 7 years ago

https://github.com/cloudposse/geodesic/pull/323

Janover 7 years ago

https://github.com/cloudposse/root.cloudposse.co/issues/34

Janover 7 years ago

odd, I updated it but doesnt reflect here

joshmyersover 7 years ago

@Jan

jdn-za changed the title from Terragrunt region env vars should be variable to Terragrunt region & Account paramaters should be variable 4 minutes ago

Janover 7 years ago

yea

Janover 7 years ago

much of a muchness

Janover 7 years ago

So on my "list" for today is to get some users provisioned into the ref architecture I have built

Janover 7 years ago

get a vpc setup

Janover 7 years ago

Finding it frustrating trying to figure out what to do next and if I am on the right path

Janover 7 years ago

.<

Janover 7 years ago

might just be the pain killers

Janover 7 years ago

I mean I guess https://docs.cloudposse.com/geodesic/module/with-terraform/

joshmyersover 7 years ago

@Jan That doesn’t look to be re users

Janover 7 years ago

so yea kinda explaining badly

Janover 7 years ago(edited)

im looking at vpc first

Janover 7 years ago

https://github.com/cloudposse/terraform-aws-vpc

Janover 7 years ago

so do I add these into the Dockerfile to be pulled?

Janover 7 years ago

how does one "inject" a tf module into the geodesic toolchain

joshmyersover 7 years ago

https://github.com/cloudposse/root.cloudposse.co/tree/master/conf AFAIK

Janover 7 years ago

Maybe I need to not use the docs as the reference just yet?

Janover 7 years ago

ok so

joshmyersover 7 years ago

So Geodesic takes the tfvars from foo.example.com conf dir and uses multi stage docker builds to pull the actual TF files from their root modules repo. If we want to add some more TF resources, I think we can just add them to the conf dir and or better yet, create a module and add as a git submodule

joshmyersover 7 years ago

e.g. https://github.com/cloudposse/root.cloudposse.co/tree/master/conf/iam

Janover 7 years ago

k im with you

joshmyersover 7 years ago

in my geodesic container actually has:

joshmyersover 7 years ago

Obvious thing to watch out for is naming clashes, other than that I think it should JFW

joshmyersover 7 years ago

@Jan https://github.com/cloudposse/root.cloudposse.co/pull/35 should address your issue

Janover 7 years ago

taking a look

Janover 7 years ago

was in a meeting

Janover 7 years ago

Yep

Janover 7 years ago

what about the root account iD?

joshmyersover 7 years ago

You mean https://github.com/cloudposse/root.cloudposse.co/blob/ba029d4cfbff56b413486a6d017e3d5679879490/Dockerfile#L17 ?

Janover 7 years ago

I mean here https://github.com/cloudposse/root.cloudposse.co/blob/ba029d4cfbff56b413486a6d017e3d5679879490/conf/terraform.tfvars#L29

Janover 7 years ago

also what version of git are you using?

Janover 7 years ago

git submodule add --tag

Janover 7 years ago

--tag isnt supported

Janover 7 years ago

https://git-scm.com/docs/git-submodule

joshmyersover 7 years ago

TF_VAR_aws_assume_role_arn will always be set to whatever is in the Dockerfile, so shouldn’t fall back to the default, which is still a hardcoded thing

Janover 7 years ago

right

joshmyersover 7 years ago

Could have been better to default to an empty string there

joshmyersover 7 years ago

When you add a git submodule, it is a pointer to another repo git SHA. Once you add the submodule, you should be able to checkout whatever branches from that repo

Janover 7 years ago

cool so the submodule should be in the conf dir

joshmyersover 7 years ago

It would be one way of doing it - https://github.com/cloudposse/root.cloudposse.co/blob/master/.gitmodules

joshmyersover 7 years ago

or you could literally dump some .tf files in conf/myawesometfresources

joshmyersover 7 years ago

Be good to get a steer on this, I’m just poking around 🙂

Janover 7 years ago

https://github.com/cloudposse/root.cloudposse.co/pull/36

Janover 7 years ago

so when adding a submodule

Janover 7 years ago(edited)

I guess I need to still add my own .tfvars file in the conf/myawesometfresources/ dir

joshmyersover 7 years ago

Yeah, it looks like the general approach is to be data driven for each env and your TF resources live in another sub module

Janover 7 years ago

mmmmmm

Janover 7 years ago


module "label" {
  source     = "git::<https://github.com/cloudposse/terraform-null-label.git?ref=tags/0.3.3>"
  namespace  = "${var.namespace}"
  name       = "${var.name}"
  stage      = "${var.stage}"
  delimiter  = "${var.delimiter}"
  attributes = "${var.attributes}"
  tags       = "${var.tags}"
}

resource "aws_vpc" "default" {
  cidr_block                       = "${var.cidr_block}"
  instance_tenancy                 = "${var.instance_tenancy}"
  enable_dns_hostnames             = "${var.enable_dns_hostnames}"
  enable_dns_support               = "${var.enable_dns_support}"
  enable_classiclink               = "${var.enable_classiclink}"
  enable_classiclink_dns_support   = "${var.enable_classiclink_dns_support}"
  assign_generated_ipv6_cidr_block = true
  tags                             = "${module.label.tags}"
}

resource "aws_internet_gateway" "default" {
  vpc_id = "${aws_vpc.default.id}"
  tags   = "${module.label.tags}"
}

Janover 7 years ago

so for example I now have added a submodule for vpc (https://github.com/cloudposse/terraform-aws-vpc) to conf/aws-vpc

Janover 7 years ago

I guess I would need to mod these variables to lookup from the geodessic env's

Janover 7 years ago

TF_VAR_stage or TF_VAR_namespace

Janover 7 years ago

I mean they should already override these right?

joshmyersover 7 years ago

https://github.com/cloudposse/root.cloudposse.co/blob/master/Dockerfile#L19 is already set for example, so that should just work..

Janover 7 years ago

yea for those ones

Janover 7 years ago

then name = "${var.name}"

Janover 7 years ago

I need a .tfvars ?

joshmyersover 7 years ago

If they aren’t being set in your equivalent root.example.com Dockerfile as TF_VAR, you will want to set some defaults for them via a tfvars file, that lives in <http://root.example.com/conf/myawesometfmodule/|root.example.com/conf/myawesometfmodule/>

Janover 7 years ago

so that right there is an expectation in terms of usage, that should be documented 😛

Janover 7 years ago

updating my pr

Janover 7 years ago

any/all modules should list in the readme what would be inherited vs what needs to be added to be injected into geodessic

joshmyersover 7 years ago

Cool, it is along the same lines as https://github.com/cloudposse/root.cloudposse.co/blob/master/conf/iam/terraform.tfvars

joshmyersover 7 years ago

^^ gets munged together with https://github.com/cloudposse/terraform-root-modules/tree/master/aws/iam

Janover 7 years ago

Id even have a tfvars.example for the ones that are not inherited maybe two tfvars.geodessic-example tfvars.standalone-example

joshmyersover 7 years ago

Aye, could do https://www.terraform.io/docs/configuration/variables.html#variable-files - so like above you’d want them to be *.auto.tfvars

Janover 7 years ago

why .auto.tfvars?

joshmyersover 7 years ago

Janover 7 years ago

duh

joshmyersover 7 years ago

@Jan Hows that working out?

Janover 7 years ago

https://github.com/cloudposse/terraform-aws-vpc/pull/23

Janover 7 years ago

clickbait title

Janover 7 years ago

but id like to see an <modules_name>.auto.tfvars.example file in every cloudposse terraform module

Janover 7 years ago

make is explicit where the things are required / inherited / defaults

Andriy Knysh (Cloud Posse)over 7 years ago(edited)

@Jan all modules are ‘identity-less’, they don’t care about how and where they get deployed. All input vars are provided from higher-level modules. In many cases, they are provided as ENV vars from the Dockerfiles for the corresponding environment. In this case, we are able to re-use all modules without changing anything for all possible configurations of AWS accounts, stages/environments, etc.

joshmyersover 7 years ago

terraform-docs is in use for auto creating readme’s of variable requirements etc

Janover 7 years ago

So you would still not describe how to use these modules alongside geodesic?

Andriy Knysh (Cloud Posse)over 7 years ago

so if you already using a container like geodesic, then you define all required ENV vars and copy all required modules to the final container

Andriy Knysh (Cloud Posse)over 7 years ago

in the Dockerfile

Janover 7 years ago

that still means I need to find the required vs defaults

Andriy Knysh (Cloud Posse)over 7 years ago

no need to use .tfvar files and git submodules

Andriy Knysh (Cloud Posse)over 7 years ago

but when you use a module, you see all its variables

Andriy Knysh (Cloud Posse)over 7 years ago

you can update whatever you need

Andriy Knysh (Cloud Posse)over 7 years ago

it’s a simple pattern, add ENV vars and copy the modules you need

joshmyersover 7 years ago

@Andriy Knysh (Cloud Posse) rather than using submodules, would the other way be to just dump your high level module for root.example.com in the conf/foo dir ?

Andriy Knysh (Cloud Posse)over 7 years ago

we copy all modules we need in Dockerfiles

Andriy Knysh (Cloud Posse)over 7 years ago

that’s why we use terraform-root-modules

joshmyersover 7 years ago

I see the terraform modules and geodesic as separate. Geodesic including makefile/dockerfile etc is the glue that is necessary for orchestration. The other modules are there to use if you want to

joshmyersover 7 years ago

Ah indeed, that is another way

Andriy Knysh (Cloud Posse)over 7 years ago

but if you want to have another repo to copy from, and don’t want to put it into terraform-root-modules, then you add a Dockerfile to that repo, build an image, and then use Docker multi-stage to copy it into the final image

Andriy Knysh (Cloud Posse)over 7 years ago

you can use other ways of doing it, e.g. submodules, var files, etc., but it’s a completely diff pattern

Janover 7 years ago


~/dev/resources/cloudposse/forks/root.cloudposse.co   master  find . | grep tfvars
./conf/terraform.tfvars
./conf/atlantis-repos/terraform.tfvars
./conf/iam/terraform.tfvars
./conf/users/terraform.tfvars
./conf/root-iam/terraform.tfvars

Andriy Knysh (Cloud Posse)over 7 years ago

so copying modules and specifying vars are separate concerns

Janover 7 years ago

then use of dockerfile env vars and .tfvars and auto.tfvars.example is very confusing

Andriy Knysh (Cloud Posse)over 7 years ago

yes @Jan you correct, we used the vars inconsistently

Janover 7 years ago

they all do the same thing at different places

Andriy Knysh (Cloud Posse)over 7 years ago

by specifying some of them in Dockerfiles, and some in var files

Andriy Knysh (Cloud Posse)over 7 years ago

that could be improved

Janover 7 years ago

and there is no stated explanation of where and how which one

joshmyersover 7 years ago

@Andriy Knysh (Cloud Posse) What is the reasoning behind https://github.com/cloudposse/geodesic-aws-atlantis being a submodule but TF code (high level modules like terraform-root-modules) is Docker multi stage?

Andriy Knysh (Cloud Posse)over 7 years ago

atlantis was just a test, it’s not in the official docs

Andriy Knysh (Cloud Posse)over 7 years ago(edited)

@Erik Osterman (Cloud Posse) was playing with that

joshmyersover 7 years ago

Ah OK

Andriy Knysh (Cloud Posse)over 7 years ago

@Jan to define vars, you can use just Dockerfiles, just var files, or a combination of them

Janover 7 years ago

and when I get to 60+ tf modules?

Andriy Knysh (Cloud Posse)over 7 years ago

i agree, one way would be better to not confuse people

Janover 7 years ago

I have a massive dockerfile with vars

Janover 7 years ago

every time I need to set a new var

Janover 7 years ago

and then I need to worry about unique var names at the env level?

Andriy Knysh (Cloud Posse)over 7 years ago

you would have to worry about that in any case, in Dockerfiles or in var files, or any other place

joshmyersover 7 years ago

There is no getting away from having to set vars

joshmyersover 7 years ago

Janover 7 years ago

sure,....

Janover 7 years ago

are you doing 1 geodesic module per aws account or smaller units?

Janover 7 years ago

so I mean if I have a "dev" account

Andriy Knysh (Cloud Posse)over 7 years ago

per environment (prod, staging, dev, etc.)

Andriy Knysh (Cloud Posse)over 7 years ago(edited)

which could be in separate AWS accounts, or in one (depending on requirements and client requests)

Janover 7 years ago

and I want multiple vpc's and then I want to pass name = "${var.name}"

Andriy Knysh (Cloud Posse)over 7 years ago(edited)

yes, but you have different stages, so no naming conflicts even if you deploy all stages into one account

Janover 7 years ago

I dont want to then have a ENV TF_VAR_fooname="devFoo

Janover 7 years ago

per vpc / project / resource

Andriy Knysh (Cloud Posse)over 7 years ago

name should be the same for all accounts/environments (prod, staging, dev)

Andriy Knysh (Cloud Posse)over 7 years ago

that’s why we have stage

Janover 7 years ago

name in the sense of vpc?

Andriy Knysh (Cloud Posse)over 7 years ago(edited)

in the sense of application/solution name

Janover 7 years ago

(im looking at the terraform vpc module, just to be clear here)

Andriy Knysh (Cloud Posse)over 7 years ago

for example, your VPC could be named like this:

Andriy Knysh (Cloud Posse)over 7 years ago

cp-prod-myapp for prod

Janover 7 years ago

and in the case where I have a pre-production account that has like 30+ vpcs?

Andriy Knysh (Cloud Posse)over 7 years ago

cp-staging-myapp for staging

Andriy Knysh (Cloud Posse)over 7 years ago(edited)

then you use attributes to add additional params to each ID generated by the label modules

Andriy Knysh (Cloud Posse)over 7 years ago

for example

Andriy Knysh (Cloud Posse)over 7 years ago

cp-prod-myapp-unit1

Andriy Knysh (Cloud Posse)over 7 years ago

cp-prod-myapp-unit2

Janover 7 years ago

And where are you setting the attributes then?

Janover 7 years ago(edited)

as env vars in your dockerfile

Andriy Knysh (Cloud Posse)over 7 years ago

each module has a var attributes

Andriy Knysh (Cloud Posse)over 7 years ago

you can set them in a few diff ways:

Andriy Knysh (Cloud Posse)over 7 years ago

1. Directly in a higher-level module

Andriy Knysh (Cloud Posse)over 7 years ago

2. In Dockerfile

Andriy Knysh (Cloud Posse)over 7 years ago

3. in var file

Andriy Knysh (Cloud Posse)over 7 years ago

it all depends on a particular use-case

Andriy Knysh (Cloud Posse)over 7 years ago

and you either hardcode them (e.g. in a higher-level module) if they never change, or use ENV vars if you think they might change

Andriy Knysh (Cloud Posse)over 7 years ago

but don’t worry about name collision between environments/stages, you have stage for that

Janover 7 years ago

so lets say for example using the backing-services root module

Janover 7 years ago

to create the vpc

Janover 7 years ago

https://github.com/cloudposse/terraform-root-modules/blob/master/aws/backing-services/vpc.tf#L10

Janover 7 years ago

what is the expectation for setting this is a cidr I want

Janover 7 years ago

mmm

Janover 7 years ago

wait a sec

Andriy Knysh (Cloud Posse)over 7 years ago

you need to create your own terraform-root-modules or similar repo with diff name if needed

Andriy Knysh (Cloud Posse)over 7 years ago

and provide the CIDR block you need (hardcoded or from var)

Janover 7 years ago

the backing-services is a kops/k8s specific vpc?

Andriy Knysh (Cloud Posse)over 7 years ago

in our terraform-root-modules yes, it was intended to be used and peered with a kops VPC

Andriy Knysh (Cloud Posse)over 7 years ago

in your terraform-root-modules, it could be in the way you want

Andriy Knysh (Cloud Posse)over 7 years ago

our terraform-root-modules was not intended to be copied verbatim, it’s just a reference architecture

Andriy Knysh (Cloud Posse)over 7 years ago

but it uses the TF modules, which could be used everywhere

Andriy Knysh (Cloud Posse)over 7 years ago

the label module is the central piece here

Andriy Knysh (Cloud Posse)over 7 years ago

it allows to specify unique names for all environments without naming collisions

Andriy Knysh (Cloud Posse)over 7 years ago

and it does not matter if you deploy everything into just one AWS account, or multiple account per environment

Andriy Knysh (Cloud Posse)over 7 years ago

https://docs.cloudposse.com/reference-architectures/notes-on-multiple-aws-accounts/

Janover 7 years ago

So I mean I missed that this part is meant to be copied and modded to my needs

Janover 7 years ago

https://docs.cloudposse.com/terraform-modules/root/

Janover 7 years ago

is it stated someplace int he getting started?

Andriy Knysh (Cloud Posse)over 7 years ago

here is an example of using attributes in the same module to create unique names if you have more than one resource of the same type (e.g. role, distribution, etc.) https://github.com/cloudposse/terraform-aws-cloudfront-s3-cdn/blob/master/main.tf#L7

Andriy Knysh (Cloud Posse)over 7 years ago

So I mean I missed that this part is meant to be copied and modded to my needs

Andriy Knysh (Cloud Posse)over 7 years ago

@Jan that’s not probably stated in the docs

Andriy Knysh (Cloud Posse)over 7 years ago

yea they are not perfect

Janover 7 years ago

So I mean from a "fresh to the project" perspective im not sure there is enough explained about how its meant to be used as yet

Janover 7 years ago

I get they are not perfect

Andriy Knysh (Cloud Posse)over 7 years ago

docs is always the most difficult thing to create 🙂

Andriy Knysh (Cloud Posse)over 7 years ago

you either want to be concise, or you spend a year to create a book

Janover 7 years ago

but maybe it would add huge value to sitdown with a fresh user and write downt he step by step requirements to get from 0 to a set account/vpc/resources blueprint

joshmyersover 7 years ago

A module in terraform-root-modules is little more than some variables and calling other modules which do the heavy lifting.

Janover 7 years ago

maybe take a multi az wordpress on k8s with multiple envs

Janover 7 years ago

and rds / elasticache

Andriy Knysh (Cloud Posse)over 7 years ago

all good points @Jan

Janover 7 years ago

I have approached diving into the docs and code base knowing what I want to create (and how to do so in terraform) in order to try understand how geodesic would work

Andriy Knysh (Cloud Posse)over 7 years ago

thanks again

Andriy Knysh (Cloud Posse)over 7 years ago

so yea, geodesic is just a container with a bunch of tools required to provision infrastructures

Andriy Knysh (Cloud Posse)over 7 years ago

terraform-root-modules is an example of a reference architecture, shows how to use the TF modules, and is just one way of doing things

Janover 7 years ago

well its been a pretty frustrating process 😛 (to be fair I was warned it would be)

Janover 7 years ago(edited)

so let me start back at the begging with my new understanding

Janover 7 years ago

how would I best go about:
1. setting up a geodesic project with 7 accounts (all pre-existing)
2. setting up users to be created
3. setting up env / project vpc(s) in these accounts
4. setting up resources in some of these
5. peering vpc's selectivley

Janover 7 years ago

I had before used and modified the reference architecture

Janover 7 years ago

and have that all working so far as admin users with cross account sts assume and dns delegation with acm etc

Janover 7 years ago

if you were to describe how to do my list, not in depth, what should I follow

Andriy Knysh (Cloud Posse)over 7 years ago

you already forked terraform-root-modules

Janover 7 years ago

just did so

Andriy Knysh (Cloud Posse)over 7 years ago

that’s your collection of module invocation

Andriy Knysh (Cloud Posse)over 7 years ago

start updating it to suit your needs

Andriy Knysh (Cloud Posse)over 7 years ago

e.g. change the VPC CIDR, add more modules you need, remove the modules you don’t need

Andriy Knysh (Cloud Posse)over 7 years ago

then it would be ready to be deployed to all accounts

Andriy Knysh (Cloud Posse)over 7 years ago

note that you add some modules to it which could be used only in some accounts, but not in the other

Janover 7 years ago

let me go remove everything I created previously first

Andriy Knysh (Cloud Posse)over 7 years ago

then in Dockerfile(s) just copy what you need

Andriy Knysh (Cloud Posse)over 7 years ago

per account

Andriy Knysh (Cloud Posse)over 7 years ago

the COPY commands will be different for all accounts b/c you need different modules in each (some modules are the same for all)

Janover 7 years ago

So the root modules would become the whole module catalog

Andriy Knysh (Cloud Posse)over 7 years ago

create 7 repos, one per account

Janover 7 years ago

other than fully remote TF modules

Andriy Knysh (Cloud Posse)over 7 years ago

7 Dockerfiles

Andriy Knysh (Cloud Posse)over 7 years ago

and update all ENV vars in the repos to reflect the accounts

Andriy Knysh (Cloud Posse)over 7 years ago

yes, exactly, the root modules would become the whole module catalog

Andriy Knysh (Cloud Posse)over 7 years ago

the whole infrastructure catalog, for ALL accounts

Janover 7 years ago

and there afterwards when I want to add 3rd party ones to only some accounts?

Andriy Knysh (Cloud Posse)over 7 years ago

either add them to the root modules (if you think it makes sense and you might want to re-use it somewhere else), or add it directly to one of the infra repo

Andriy Knysh (Cloud Posse)over 7 years ago(edited)

if you want to add them to more than one infra repos, then better to add them to the root modules

Janover 7 years ago

mmm

Janover 7 years ago

how large do these root module end up becoming?

Andriy Knysh (Cloud Posse)over 7 years ago

reflecting the whole infrastructure

Janover 7 years ago

I might just batch them into categories or something

Andriy Knysh (Cloud Posse)over 7 years ago

but sure, you can split it into a few repos

Andriy Knysh (Cloud Posse)over 7 years ago

and add them to the final Dockerfile as multi-stage

Andriy Knysh (Cloud Posse)over 7 years ago

the point here is that you could re-use the code from terraform-root-modules in many environments (prod, staging, dev), some of them will be the same, some unique to a particular repo

Erik Osterman (Cloud Posse)over 7 years ago

(wow i have some reading to do today)

Janover 7 years ago

hahah

Erik Osterman (Cloud Posse)over 7 years ago(edited)

expect some threaded converstations

Erik Osterman (Cloud Posse)over 7 years ago

😃

Janover 7 years ago


# Disable Role ARN (necessary for root account on cold-start)
[ "${DISABLE_ROLE_ARN}" == "0" ] || sed -Ei 's/^(\s+role_arn\s+)/#\1/' main.tf

Janover 7 years ago

nice addition!

Erik Osterman (Cloud Posse)over 7 years ago

though still a nasty hack!

Erik Osterman (Cloud Posse)over 7 years ago

😃

Janover 7 years ago

better this way than 1 vim and 1 sed

Janover 7 years ago

@Andriy Knysh (Cloud Posse) thanks for your explanations earlier btw

Janover 7 years ago

I seem to be getting on now

Andriy Knysh (Cloud Posse)over 7 years ago

no problem, looks like it @Jan 🙂

Janover 7 years ago

cool vpc done

Janover 7 years ago

however the subnet math seems a bit odd...

Janover 7 years ago

I provided a /22 range over 3az 2 tier and ended up with 6 x /26's

Janover 7 years ago(edited)

mmmmm

Erik Osterman (Cloud Posse)over 7 years ago

we generate subnets in a table manner

Erik Osterman (Cloud Posse)over 7 years ago

that takes into account a max number

Erik Osterman (Cloud Posse)over 7 years ago

stable not table*

Janover 7 years ago

https://github.com/cloudposse/terraform-aws-multi-az-subnets

Erik Osterman (Cloud Posse)over 7 years ago

https://github.com/cloudposse/terraform-aws-multi-az-subnets/blob/master/variables.tf#L40

Janover 7 years ago

so first off was surprised by ipv6 being enabled

Janover 7 years ago

Maximum number of subnets that can be created. The variable is used for CIDR blocks calculation

Janover 7 years ago

still...

Janover 7 years ago

I mean I did expect 6 subnets, which is what I got back

Janover 7 years ago

they are just smaller than expected

Erik Osterman (Cloud Posse)over 7 years ago

the full calculation is broken down in the README

Erik Osterman (Cloud Posse)over 7 years ago

it's rather complicated (and necessarily so)

Erik Osterman (Cloud Posse)over 7 years ago

crap

Erik Osterman (Cloud Posse)over 7 years ago

i don't see the calculation there anymore

Erik Osterman (Cloud Posse)over 7 years ago

i think i'm getting confused by our other subnet module

Erik Osterman (Cloud Posse)over 7 years ago

https://github.com/cloudposse/terraform-aws-dynamic-subnets

Erik Osterman (Cloud Posse)over 7 years ago

(@Jan sorry i'm busy onboarding a couple new hires today so i'm very distracted)

Janover 7 years ago

so I mean a /22 would be 1022 usable ip's so even removing say 5 for aws uses per subnet I would still expect like 165 odd useable per subnet

Janover 7 years ago

all good mate

Janover 7 years ago

its like 10:20pm here so probably wont carry on much longer

Erik Osterman (Cloud Posse)over 7 years ago

i'll catch up on this discussion later on today

Janover 7 years ago

cool im gonna carry on for now since I will rebuild these vpc's any way

Janover 7 years ago

maybe when you are back, how would I best go about creating multiple vpcs within a single geodesic module

Janover 7 years ago(edited)

say stage{a,b,c,d,e}.example.com

Janover 7 years ago

I have a pre calculated list of /22's and /23's that would get used, just read from a remote state output of a map

Janover 7 years ago

stagea.example.copm = 10.0.0.0/22

Janover 7 years ago

etc

Erik Osterman (Cloud Posse)over 7 years ago

@Jan https://github.com/cloudposse/terraform-root-modules/issues/52

Erik Osterman (Cloud Posse)over 7 years ago

I created that issue to better address the purpose of root modules

Erik Osterman (Cloud Posse)over 7 years ago

in short, you nailed it with this comment:

Erik Osterman (Cloud Posse)over 7 years ago

root modules would become the whole module catalog of your organization

Janover 7 years ago

https://developer.github.com/changes/2018-11-05-github-services-brownout/

Janover 7 years ago

wrong channel

Janover 7 years ago

oops

erikover 7 years ago

set the channel description: Discussions related to https://github.com/cloudposse/geodesic

Erik Osterman (Cloud Posse)about 7 years ago

https://github.com/cloudposse/terraform-root-modules/releases/tag/0.8.0

Erik Osterman (Cloud Posse)about 7 years ago

rejoice!

Janabout 7 years ago

https://github.com/aylei/kubectl-debug

Janabout 7 years ago

Nifty for debugging

Erik Osterman (Cloud Posse)about 7 years ago

@Jesse Bye I think it's good you're looking at both Gruntworks library as well as our own. They build solid stuff.

Erik Osterman (Cloud Posse)about 7 years ago

The key differentiator is our approach.

Erik Osterman (Cloud Posse)about 7 years ago

1) we don't rely on a wrapper like terragrunt

Erik Osterman (Cloud Posse)about 7 years ago

2) we containerize our entire tool chain and docker extensively to deliver the solution

Erik Osterman (Cloud Posse)about 7 years ago

3) everything is 100% apache2 open source (we accept most PRs)

Jesse Byeabout 7 years ago

I definitely like that 3rd point 😀 it's very hard for us to evaluate Gruntwork without being able to look at any real source code

Erik Osterman (Cloud Posse)about 7 years ago(edited)

(i think they will let you do that though if you maybe sign an NDA...)

Erik Osterman (Cloud Posse)about 7 years ago(edited)

Also, we just released: https://github.com/cloudposse/reference-architectures

Jesse Byeabout 7 years ago

They offer a 30-day money back agreement after purchase, so you have to pay, check it all out, then cancel within 30 days if you don't like it

Erik Osterman (Cloud Posse)about 7 years ago

are you looking to adopt kubernetes?

Jesse Byeabout 7 years ago

Eventually, yes. For now, though, we are looking at an ECS-based architecture

Erik Osterman (Cloud Posse)about 7 years ago

Erik Osterman (Cloud Posse)about 7 years ago(edited)

Have a look also at #airship by @Maarten van der Hoef for ECS

Maarten van der Hoefabout 7 years ago

@Maarten van der Hoef has joined the channel

Erik Osterman (Cloud Posse)about 7 years ago

This is what one of our single account architectures looks like: https://github.com/cloudposse/testing.cloudposse.co

Erik Osterman (Cloud Posse)about 7 years ago

Basically every AWS account is a repo, defined with a Dockerfile and pulls in source from a shared repository (terraform-root-modules) of code.

Jesse Byeabout 7 years ago

Interesting

Erik Osterman (Cloud Posse)about 7 years ago

And we deploy https://www.runatlantis.io/ with each account

Erik Osterman (Cloud Posse)about 7 years ago

gruntworks takes a different approach. I think they have a monorepo for all AWS account and then a service catalog like our with apps to deploy therein.

Erik Osterman (Cloud Posse)about 7 years ago

they use a shared terraform statebucket for all accounts

Erik Osterman (Cloud Posse)about 7 years ago(edited)

we deploy (1) state bucket/dynamodb per account and share nothing (heck even our account repos share nothing)

Erik Osterman (Cloud Posse)about 7 years ago

this lets every account act autonomously and be managed by different teams

Jesse Byeabout 7 years ago

Thanks for the info, Erik. I'll have to take some time to digest it and see how it fits with how we are doing things. We already have a big chunk of Terraform code we wrote, but it has a fair number of issues and is all based around EC2 instances, not ECS. So as we move to using containers, we're looking at a fresh start using a more mature codebase.

Erik Osterman (Cloud Posse)about 7 years ago

yea, this is a good transition point to consider other alternatives

Erik Osterman (Cloud Posse)about 7 years ago

Added some more thoughts here: https://github.com/cloudposse/docs/issues/351

Jesse Byeabout 7 years ago

@Erik Osterman (Cloud Posse) do you have an infrastructure diagram of any sort showing how you lay out the VPCs, bastions, peering, etc. in your reference arch?

Erik Osterman (Cloud Posse)about 7 years ago

good question: at this point, we don't opine down to that level.

Erik Osterman (Cloud Posse)about 7 years ago

we provide the various components, but don't say what your network should look like

Erik Osterman (Cloud Posse)about 7 years ago

Check out our various subnet modules that implement the different kinds of strategies

November 2018 Browse by date January 2019