#general (2020-09)

Current docs for that are in flux. Big things are happening but it won’t be ready for a couple months probably.

Any suggestion for spinning up a new account. I really liked the setup

we have revamped our strategy around a something that works well with terraform cloud and a cli for operations

We have departed from the one repo per account strategy because it’s not gitops friendly and heavy to setup

Ok, so you wouldnt suggest going down the route of setting up the reference architectures?

Not that refarch, but we have a new one - just not public yet. We still use geodesic, and our terraform modules. We don’t use the terraform-root-modules repo for new engagements and we have tons of stuff we still need to open source which we use in our engagements.

Ok ill hold off and just setup a interim architecture for now

Apologies for digging this topic back…. are there any updates on when the new bootstrap system would be open-sourced?

I’m also interested in knowing if there’s any updates on this, @Erik Osterman (Cloud Posse).

Also, is there a good place to stay informed on said updates?

See #geodesic

but we will announce this in a very big way once we have more published

stay tuned

calendly.com/cloudposse

I can show you how to get started

Thanks so much

Also remember you can now compile this and discard variant :-)

So you have a single binary executable artifact

Here’s my challenge in reviewing this.. I know you haven’t worked with PowerShell, so we are coming from different backgrounds. i’m new to go, and here’s what I observed so far.

Variant2 requires much much more work to get basic build/task automation up compared to PowerShell (which is cross platform, I’m running in Linux (docker) and macOS). Variant2 while awesome with hashicorp’s functions, is way less featured than PowerShell, which provides a rich ecosystem and is much much better for argument parsing and arg strings.

Note: I love trying new things. I really love the concept and am trying to give it a shot, but coming from a framework that is “make on steroids” with rich objects and all, it’s hard for me to fully grasp the value of this yet.

If you are ever bored, maybe you’d be willing to do a 30min comparison of my current “runner” vs your experience with variant2 for some basic operations and we could compare? I could write up a blog post on InvokeBuild to show how it works in comparison if that would be of interest as well.

So variant2 is not a replacement for your powershell scripts, makefiles, python clis, go tools, jenkin clis, etc.

the point is more about how to combine a dozen cli UIs together. it’s definitely a niche problem, and maybe not a problem you need to solve.

but the way you call your InvokeBuild scripts might be different than the interface for helm, and helmfile and terraform and kubectl and make and …. so if you want to present to your users a single cli that feels like it was written from the ground up to provide a consistent interface, but don’t actually want to write a cli from the ground up, then variant is the right tool for that.

Interesting. I was taking it as have a cross platform “make” replacement using a robust hashicorp library etc. The examples of running args for examples with exec is a replacement for a make file.

I’ll be eager to see more. I’m a new Gopher so anything to help gradually get me more immersed in Go is great.

Got you. So the use case would be something perfect for you then, as you might have helm, terraform, terraform-docs and more all in y our tooling, and it would give you a single cli.

So I’ve always defined this as “functions/libraries” and “runners”. The runners are the interface to tested cli/libraries.

yea, so variant is a runner

If I can chain together a simple build like

build.ps1 -task clean, build, deploy

And it is running cleanup commands, remove commands, go build, terraform deploy/serverless etc…. I’m confused on what variant would offer over that i guess.

it’s opinionated as the rest and it deliberately does not allow many things you would find if you were writing it natively in Go/Python/C/etc. It’s doing that to force business logic into the cli tools, rather than into the cli. Keep the cli as minimal as possible.

build.ps1 -task clean, build, deploy

the user needs to know that they should pass clean, build deploy and not build, deploy, clean

when they type build.ps1 --help do they see the full menu of options

how do i pas arguments to build but not deploy?

how do i pas different arguments to build than to deploy?

how do i know what arguments I can pass to clean?

can I run [build.ps](http://build.ps) -task clean --help?

This is how I instruct others to normally run. It populates prebuilt build tasks in vscode automatically (not required)

And it generates a full asciidoc help file from a few commands or can give you a full task /job list with build.ps1 ? for example.

The arguments is a good point. I drive all this from parameters or environment variables (powershell is very robust on arg parsing)

This is the raw output without any nice formatting, though I have a task that generates a formatted asciidoc readme too.

so make is as well very environment driven. and (by my opinion) a very weak cli interface when compared to a modern cli. However, this is why variant is nice. So variant handles all the arg parsing. You can pass that to you invoke build. You can pass it to helm, terraform, bash scripts, etc. The user has a standard way of using the cli that doens’t depend on wiki ops.

Got you. Ok for input standardization.

This is useful. PowerShell argument parsing is object based so it can be extremely rich, that’s why I’ve struggled to see some of these differences. Do you have a variant2 example from the repo they provide that demonstrates your favorite use case for this?

Ok for input standardization.

PowerShell is object based vs text based like most cli tooling, so that’s where probably my paradigm is different (not better, just different).

bingo. input / cli standardization / modernization without rewriting it.

For instance I can provide a full object like, perform terraform fmt on files for example

$files = Get-ChildItem -Recursive -Filter *.tf

Isn’t powershell more comprable to something like bash or fish than to a task runner? It’s a full fledged language.

This can be passed into a build like build.ps1 -task format -Files $files

but the difference is powershell easily works with this object, it’s not just a file list. Each $file in the loop would give you access to a full range of properties that are actual dotnet objects, not parsed text.

And PowerShell is more comparable to Python, but with a better “REPL” you can use just like bash/fish at the same time.

The difference is you are working with objects, not text. Not saying it’s better, but for complex things like argument parsing it means you pass actual bool values, not text 1/0 that have to be converted to boolean in your tool.

yea, exactly - so this is a total apple to oranges comparison. variant in no way strives to replace python/perl/ruby/bash/go/golang/invokebuild./etc

it’s more of a DSL to express workflows

you can definitely write workflows in python/perl/ruby/bash/go/golang/invokebuild

gotta go

office hours

Got you. Maybe we can chat again sometime if you are up for it. Paradigm is different for my background ( i blogged on this monday) and I admit there are major benefits to everything as text/files, but there are also incredibly rich “task runner” things like this that make me question cli tooling anyway

yep! for sure.

thank you

No, in our case we have it behind gatekeeper/keycloak

also, sentry has a massive/painful update that we don’t support yet.

v9 → v10

Thanks.

Is possible to configu sentry agains claimed roles from jwt/oidc token, or is it working only as single user application ?

Have you tried wrapping the $subdomain variable in curly braces? Eg.

proxy_set_header Host "${subdomain}.newdomain.com";
proxy_pass "https://${subdomain}.newdomain.com";

Yep … Although just figured it out, I needed a resolver apparently! Seems to work if I add

resolver 1.1.1.1;

above the server block

better to use #terraform

https://github.com/cloudposse/terraform-aws-eks-cluster/blob/master/auth.tf#L49

https://github.com/cloudposse/terraform-aws-eks-cluster/blob/master/variables.tf#L136

Thanks Andrew, I thought I had tried this but I just noticed that there are a couple of places in our module where we do the local exec directly, not within the null resource. I’ll have a closer look.

Hi everyone

Hey guys

ran into this issue today and i finally got to cut my teeth (and my wrists!) with cloudformation

beware, if you’re using buildkite and their cloudformation stack to launch templates. your stuff may be out of date.

namespace in the terraform modules is not Kubernetes namespace

it’s used for uniquely and consistency naming AWS resources

it’s coming from https://github.com/cloudposse/terraform-null-label

we use naming convention like namespace-environment-stage-name-attributes

any of those could be omitted

in the end, it looks like cp-ue2-prod-efs, where the namespace cp identifies our company

ok — got it! Yes — as I my purpose is to use in k8, I got confused, but I guess your module has nothing k8-specific in it. Thank you!