#geodesic - August 2018 | Slack Archive

geodesic

225 messages

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

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

Jul 2018

August 2018

Sep 2018

Erik Osterman (Cloud Posse)almost 8 years ago

@Rohit Verma - you might dig this:

Erik Osterman (Cloud Posse)almost 8 years ago

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

Erik Osterman (Cloud Posse)almost 8 years ago

I was able to get geodesic working with "Docker for Mac / Kubernetes" with relatively little effort

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

@Max Moon @alebabai ☝️

Erik Osterman (Cloud Posse)almost 8 years ago

damn, I spun up an AWS Workspace for Windows 10 not realizing it doesn't support Hyper-V, so no Docker. =(

Erik Osterman (Cloud Posse)almost 8 years ago

heh, and no "Windows Server 1709" support yet for "AWS Workspaces", so no WSL even.

Erik Osterman (Cloud Posse)almost 8 years ago

@Sebastian Nemeth ☝️ i wanted to try this to test Geodesic on WSL/Docker

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

@Rohit Verma going back to your question of simplifying IDE integration with geodesic

Erik Osterman (Cloud Posse)almost 8 years ago

does running mount --bind /localhost/Dev/cloudposse/terraform-root-modules/ /conf inside of geodesic make things any better for you?

Erik Osterman (Cloud Posse)almost 8 years ago

(replace Dev/cloudposse/terraform-root-modules/ with the path to your root-modules folder)

erikalmost 8 years ago

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

I've started getting these errors. I suspect it could be related to bash not responding to kill -WINCH $$ within some kind of deadline

Erik Osterman (Cloud Posse)almost 8 years ago

@tamsky Have you seen this before?

Andriy Knysh (Cloud Posse)almost 8 years ago

i started getting the errors too (after some period of inactivity in geodesic)

Erik Osterman (Cloud Posse)almost 8 years ago

@tamsky https://github.com/cloudposse/geodesic/pull/210

tamskyalmost 8 years ago

[2] Stopped indicates the process received a SIGTSTP

tamskyalmost 8 years ago

I should smile along with my crazy talk. 😃

Erik Osterman (Cloud Posse)almost 8 years ago

🤭

tamskyalmost 8 years ago

https://github.com/cloudposse/geodesic/pull/210#pullrequestreview-143392008

so in marked contrast to my bash shell's default shopt,
geodesic does have checkwinsize on....

so unless that setting changed only recently -- I think that the shopt should have been solving this problem all along.

tamskyalmost 8 years ago

And I'm thinking: "where have you been all my life checkwinsize?"
Not having it, forced me to learn the kill -WINCH trick in the meantime.

Erik Osterman (Cloud Posse)almost 8 years ago

The checkwinsize wasn’t working for me, but maybe that was masked by other problems

Erik Osterman (Cloud Posse)almost 8 years ago

For example the ones you previously fixed

tamskyalmost 8 years ago

maybe docker run doesn't pass WINCH to subshells?

tamskyalmost 8 years ago

because the terminal's window change signal needs to propagate down this entire chain:
(iterm/xterm) -> local shell -> docker run -> geodesic shell

Erik Osterman (Cloud Posse)almost 8 years ago

Oh fascinating. Didn’t know that either

tamskyalmost 8 years ago

I guess it does propagate... here's one where the signal was killing apache if docker run -it was used:
https://github.com/docker-library/php/issues/64

Erik Osterman (Cloud Posse)almost 8 years ago

Regarding the other problem, with sigstop it seems to happen when AWS session expires. Probably related to aws-vault usage.

tamskyalmost 8 years ago

yes, that sounds like aws-vault trying to read/write stdin/out and being blocked

Erik Osterman (Cloud Posse)almost 8 years ago

Yes, I think it is related to stdin

tamskyalmost 8 years ago

I just scanned their issue queue and didn't see anything related.

tamskyalmost 8 years ago

next time this happens to someone, can they please run and report back:
pstree -p ; for i in $(jobs -p) ; do echo $p ; ls -l /proc/$i/fd ; done;

tamskyalmost 8 years ago

as well as the [N] Stopped aws-vault exec ...

Erik Osterman (Cloud Posse)almost 8 years ago

Will do!

Erik Osterman (Cloud Posse)almost 8 years ago

Man... can’t say how much I appreciate your insights. In the short time since you’ve joined, learned a lot of little tricks from you.

erikalmost 8 years ago

Erik Osterman (Cloud Posse)almost 8 years ago

@tamsky ☝️ this is the output.

Erik Osterman (Cloud Posse)almost 8 years ago

pid 8 is aws-vault server mode (mock metadata api)

erikalmost 8 years ago

tamskyalmost 8 years ago(edited)

doh, pstree -p ; jobs -l; for i in $(jobs -p) ; do echo $i ; ls -l /proc/$i/fd ; done;

tamskyalmost 8 years ago

$p was in my example -- should have been $i

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

oops, I missed that too.

Erik Osterman (Cloud Posse)almost 8 years ago

will try again next time.

Erik Osterman (Cloud Posse)almost 8 years ago

@Sebastian Nemeth just cut 0.13.0 which adds WSL (Windows) support

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

Can you give that a shot?

Dylanalmost 8 years ago

@Dylan has joined the channel

Erik Osterman (Cloud Posse)almost 8 years ago

Lots of great UX fixes were merged today

Erik Osterman (Cloud Posse)almost 8 years ago

- check for duplicate syslog-ng

Erik Osterman (Cloud Posse)almost 8 years ago

- fancier banner 😃

Erik Osterman (Cloud Posse)almost 8 years ago

- prompt line-wrapping

Erik Osterman (Cloud Posse)almost 8 years ago

- ^C ssh-agent no longer aborts subsequent scripts

Erik Osterman (Cloud Posse)almost 8 years ago

some discussion right now in #release-engineering related to #geodesic

tarrallalmost 8 years ago

@tarrall has joined the channel

Adamalmost 8 years ago

@Adam has joined the channel

tarrallalmost 8 years ago

OK carrying on from #announcements

Erik Osterman (Cloud Posse)almost 8 years ago

First up… we’ve followed the cold-start process and now have root.example.com, prod.example.com etc repos, accounts stood up, k8s cluster up in prod. Which is cool, but the current Dockerfile is basically an intermingling of configuration and code, making updating it to track the “upstream” versions (e.g. <http://prod.cloudposse.co/Dockerfile|prod.cloudposse.co/Dockerfile`>) awkward. Are there plans to extract the configuration into a separate file in order to make the existing repo more usable longterm, or is this intended more as a “here’s an example of how you might glue this all together” repo rather than a tool you’d use directly?

tarrallalmost 8 years ago

And yeah I’m picking up where Jonathan left off, or at least trying to

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

the Current Dockerfile is basically an intermingling of configuration and code, making updating it to track the “upstream” versions awkward

Erik Osterman (Cloud Posse)almost 8 years ago

so there are a lot of versioning going on

Erik Osterman (Cloud Posse)almost 8 years ago

(binaries, images, charts, helmfiles, modules)

Erik Osterman (Cloud Posse)almost 8 years ago

which versions are you referring to?

Andriy Knysh (Cloud Posse)almost 8 years ago

hi @tarrall, welcome

tarrallalmost 8 years ago

maybe I asked this the wrong way, let me rephrase. When I got here, they had a copy of prod.cloudposse.co that was obviously from several commits ago, and things didn’t seem quite right, so I figured hey let me check out the latest version before I try to troubleshoot too far.

tarrallalmost 8 years ago

However our Dockerfile (and yours) have lines like this

tarrallalmost 8 years ago

ENV TF_VAR_account_id="12345"
ENV TF_VAR_namespace="example"
ENV TF_VAR_stage="prod"
ENV TF_VAR_domain_name="<http://prod.example.com|prod.example.com>"
ENV TF_VAR_zone_name="prod.example.com."

Erik Osterman (Cloud Posse)almost 8 years ago

aha, gotcha!

Erik Osterman (Cloud Posse)almost 8 years ago

yes, so the reference architectures IMO are designed to be hardforked

tarrallalmost 8 years ago

which means I need to examine your Dockerfile, copy the relevant changes into ours, instead of having a portable Dockerfile with that stuff elsewhere & pulled in

Erik Osterman (Cloud Posse)almost 8 years ago

I really don't think it makes sense to try to use ours verbatim

tarrallalmost 8 years ago

OK gotcha

Erik Osterman (Cloud Posse)almost 8 years ago

they are an example of how to use all of our tools

Erik Osterman (Cloud Posse)almost 8 years ago

it's an example of how we do and how we do it for our customers

Erik Osterman (Cloud Posse)almost 8 years ago

additionally, terraform-root-modules is also more of highly functioning examples

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

you can definitely reference them and use them, but what you run in AWS will be different from what other people run. they are basically examples for how to invoke all our terraform modules. . . a demonstration of how we use it.

tarrallalmost 8 years ago

and then question #2 is … let’s say I want to slap an RDS instance in here — maybe RDS postgres, maybe Aurora. I see cloudposse/terraform-aws-rds-cluster and that’s likely where I’d start. What would the recommended approach be here? I could copypasta that into prod.example.com/rds-cluster and then have the Dockerfile pull that in, but that’s kinda no bueno — if my stage and prod envs both end up with RDS clusters, I should be sharing the same code for both.

Erik Osterman (Cloud Posse)almost 8 years ago

ok, good question

Erik Osterman (Cloud Posse)almost 8 years ago

so there are a few concepts here. let me try to explain.

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

* geodesic is our base image. that distributes the tools. so that's our "opinionated" toolchain.

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

* then there are "geodesic modules" which are basically those reference architectures. those implement some architecture using the tool chain.

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

* then there are terraform-root-modules. those are basically a collection of patterns. usually those patterns are highly specific to your organization. for example, you would have a way of defining the infrastructure for your "API service"

Erik Osterman (Cloud Posse)almost 8 years ago

this is basically our "MVC" of infrastructure.

Erik Osterman (Cloud Posse)almost 8 years ago

let's take your example.

Erik Osterman (Cloud Posse)almost 8 years ago

You want to add an RDS cluster. How you do this is specific to your organization. You may choose postgres or mysql. You have some opinions on the parameter groups. You have some requirements for security groups, etc.

Erik Osterman (Cloud Posse)almost 8 years ago

You add that to terraform-root-modules. The root module have no "identity".

Erik Osterman (Cloud Posse)almost 8 years ago

root modules are versioned. also, we like to build a container for the root modules so we can easily copy that stuff around between images.

Erik Osterman (Cloud Posse)almost 8 years ago

Now, to invoke that RDS database, you pull that into <http://prod.example.com|prod.example.com> image. this achieves many things:

Erik Osterman (Cloud Posse)almost 8 years ago

1. it's super DRY

Erik Osterman (Cloud Posse)almost 8 years ago

2. it's versioned infrastructure

Erik Osterman (Cloud Posse)almost 8 years ago

3. separation of concerns. the <http://prod.example.com|prod.example.com> repo defines all parameters to run in that environment. this is basically the "identity" layer.

tarrallalmost 8 years ago

yup I like the versioning approach there — saves drama around your TF module’s interface changing

Erik Osterman (Cloud Posse)almost 8 years ago

---------

Erik Osterman (Cloud Posse)almost 8 years ago

then there's the question: how do we develop?

Erik Osterman (Cloud Posse)almost 8 years ago

i mean, if you have to push changes to terraform-root-modules, rebuild image, then rebuild your current account repo (<http://staging.example.com|staging.example.com>) everytime you make a change, you'll NEVER get done.

Erik Osterman (Cloud Posse)almost 8 years ago

for this reason, when we develop, we cd /localhost/path/to/my/root-modules/

Erik Osterman (Cloud Posse)almost 8 years ago

and do all iteration there until we achieve the desired outcome

Erik Osterman (Cloud Posse)almost 8 years ago

then commit/push that, open PR against master in terraform-root-modules and then merge that after approval, tag a release, and subsequently distribute that release across the various stages as needed.

Erik Osterman (Cloud Posse)almost 8 years ago

also, if you use <http://dependabot.com|dependabot.com> it's pretty cool - you can get these updates as PRs automatically

Andriy Knysh (Cloud Posse)almost 8 years ago

@tarrall we already have your example as an example https://github.com/cloudposse/terraform-root-modules/blob/master/aws/backing-services/aurora-postgres.tf

Erik Osterman (Cloud Posse)almost 8 years ago

(we're also working on CI/CD of everything - but it will be a bit before that's fully baked)

Andriy Knysh (Cloud Posse)almost 8 years ago

and here how we pull it

Andriy Knysh (Cloud Posse)almost 8 years ago

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

Andriy Knysh (Cloud Posse)almost 8 years ago

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

tarrallalmost 8 years ago

OK makes sense. I’m inclined here, I think, to have our own root modules container which is separate from yours, and develop in there…

Erik Osterman (Cloud Posse)almost 8 years ago

exactly. that's what I would recommend.

Erik Osterman (Cloud Posse)almost 8 years ago

also, we have our https://github.com/cloudposse/helmfiles

tarrallalmost 8 years ago

@Andriy Knysh (Cloud Posse) thanks! Somehow all my google-fu was able to turn up was your TF module, not the one that was in root-modules

Erik Osterman (Cloud Posse)almost 8 years ago

You might like to fork these too

Erik Osterman (Cloud Posse)almost 8 years ago

(also, we welcome all PRs - so if you find/fix bugs, develop cool new things, would love to see it)

tarrallalmost 8 years ago

I’m waaaaaaay too much of a k8s n00b to want to fork someone’s “young” repo and develop on that. Good odds y’all will find and fix bugs & improve workflow faster than I can, which means I’m better off being able to follow your repo rather than blazing my own trail

tarrallalmost 8 years ago

so yeah PRs fersure, once I’ve got a vague clue of what I’m doing

Erik Osterman (Cloud Posse)almost 8 years ago

haha, sounds good! you're on a fast track.

tarrallalmost 8 years ago

BTW one other minor thing — I think AWS well-architected (or whatever they’re calling it these days) normally recommends a separate “identities” account where the humans are managed, rather than managing those out of the master account. At least, that’s what I did at my last place, and I kinda liked that because IMO the master account should be locked down hard. Might be something to consider adding to the reference architecture, though I realize it may be overkill for many places.

Erik Osterman (Cloud Posse)almost 8 years ago

I think what we call <http://root.example.com|root.example.com> is that

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

(though I think we should rename ours to <http://identity.example.com|identity.example.com>)

Andriy Knysh (Cloud Posse)almost 8 years ago

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

tarrallalmost 8 years ago

Aaaaah. Yeah 👍️ to renaming, because I think we ended up with root.example.com == master. Not positive.

Erik Osterman (Cloud Posse)almost 8 years ago

hrmmmm ok, so I need to re-review the well-architected doc

tarrallalmost 8 years ago

Heh I was at that re:Invent talk…

tarrallalmost 8 years ago

one of only like 3-4 I managed to make last year

Erik Osterman (Cloud Posse)almost 8 years ago

Perhaps we have something we should rethink there. I've always treated root = identity = master

Erik Osterman (Cloud Posse)almost 8 years ago

but deploy nothing other than identity in it

Erik Osterman (Cloud Posse)almost 8 years ago

then prod, staging, audit (~security), dev, testing accounts

Erik Osterman (Cloud Posse)almost 8 years ago

which share nothing

Erik Osterman (Cloud Posse)almost 8 years ago

and identity delegates to those accounts

Erik Osterman (Cloud Posse)almost 8 years ago

i need to adjust my mental model for how it would look if master != identity

Erik Osterman (Cloud Posse)almost 8 years ago

so is master just billing?

tarrallalmost 8 years ago

yeah 👍️ on identity delegating, fersure. I like having the “master account” (payer account, and where the service control policies are defined) separate from the “identities account” (where humans are defined)

Andriy Knysh (Cloud Posse)almost 8 years ago

master is root/Org

Andriy Knysh (Cloud Posse)almost 8 years ago(edited)

identity is our current <http://root.cloudposse.co|root.cloudposse.co>

tarrallalmost 8 years ago

ok cool so mostly just I got confused by the naming convention

Erik Osterman (Cloud Posse)almost 8 years ago

something like that. yea, naming is hard.

tarrallalmost 8 years ago

2 hard things in CS, right? Naming things, cache invalidation, and counting

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

we've had a lot of discusssion around this internally (fwiw) - we know we need to change root to something or to rename terraform-root-modules (for which there's no relationship)

tarrallalmost 8 years ago

🙂

Erik Osterman (Cloud Posse)almost 8 years ago

i'm inclined to rename <http://root.cloudposse.co|root.cloudposse.co> to <http://identity.cloudposse.co|identity.cloudposse.co>

Erik Osterman (Cloud Posse)almost 8 years ago

and introduce a new <http://master.cloudposse.co|master.cloudposse.co> or <http://billing.cloudposse.co|billing.cloudposse.co>

Erik Osterman (Cloud Posse)almost 8 years ago

so we do DNS zone deletation from identity as well

Erik Osterman (Cloud Posse)almost 8 years ago

where would that belong?

Andriy Knysh (Cloud Posse)almost 8 years ago

yea, there we have two diff hierarchies: AWS and DNS

tarrallalmost 8 years ago

Re DNS, oh man, that’s one of those that’s gonna be super company dependent right? I mean, for some places using Route53 maybe they do a zone per account, other places maybe have a single shared zone with cross-account access…

Andriy Knysh (Cloud Posse)almost 8 years ago

root of DNS is <http://cloudposse.co|cloudposse.co>

Erik Osterman (Cloud Posse)almost 8 years ago

I mean, for some places using Route53 maybe they do a zone per account, other places maybe have a single shared zone with cross-account access…

Erik Osterman (Cloud Posse)almost 8 years ago

tarrallalmost 8 years ago

LOLOLOL but when you migrated to the cloud LOOONG before AWS had orgs…

Erik Osterman (Cloud Posse)almost 8 years ago

haha - yea, we're probably going remain very strict about "share nothing"

tarrallalmost 8 years ago

you might happen to be proud of having almost everything migrated out of Classic 🙂

Erik Osterman (Cloud Posse)almost 8 years ago

(we even recommend using different TLDs per account in some situations)

tarrallalmost 8 years ago

Yup, reasonable fersure. I’ve always liked at least separating “customer-facing” TLD from “internal ops” TLD

tarrallalmost 8 years ago

example.com / example.net kinda thing

Erik Osterman (Cloud Posse)almost 8 years ago

yes - that's a must

Erik Osterman (Cloud Posse)almost 8 years ago

we call the customer facing one the "vanity domain"

Andriy Knysh (Cloud Posse)almost 8 years ago(edited)

so we provision the root DNS zone (e.g. <http://cloudposse.co|cloudposse.co>) in <http://master.cloudposse.co|master.cloudposse.co>?

tarrallalmost 8 years ago

An alternative there might be to have an account dedicated to “shared infrastructure.” I can’t decide if it is just massive overkill to have that as a separate account from the “identities” account or not… identities is certainly an instance of “shared infra”.

Andriy Knysh (Cloud Posse)almost 8 years ago

yes that’s possible

Andriy Knysh (Cloud Posse)almost 8 years ago

what we’ve found out after many iterations is that there are no perfect solution for this 🙂

tarrallalmost 8 years ago

Yup

Andriy Knysh (Cloud Posse)almost 8 years ago

you touch/change something in one place, you get a lot of issues in other places

tarrallalmost 8 years ago

And k8s is new enough that I’m confident that in a year or two, the “best practices” there today will be a laughingstock. This just based on my past experience with seeing workflows mature on Chef and Terraform…

Andriy Knysh (Cloud Posse)almost 8 years ago

that’s actually one of the main reasons we created https://github.com/cloudposse/terraform-root-modules and https://github.com/cloudposse/helmfiles - to introduce some patterns for TF and k8s

Andriy Knysh (Cloud Posse)almost 8 years ago(edited)

they are not perfect, but at least we have the same structure between projects and consistent naming (which is hard)

tarrallalmost 8 years ago

Latest “probably a n00b mistake I’m making” issue — init-terraform in terraform-root-modules/aws/ecr is erroring…

tarrallalmost 8 years ago

will cut/paste the error here in a sec

tarrallalmost 8 years ago

 ✓   (flowtune-prod-admin) ecr ⨠  init-terraform
Mounted buckets
Filesystem                    Mounted on
flowtune-prod-terraform-state /secrets/tf
Initializing modules...
- module.kops_ecr_app
  Getting source "git::<https://github.com/cloudposse/terraform-aws-kops-ecr.git?ref=tags/0.1.0>"
- module.kops_ecr_user
  Getting source "git::<https://github.com/cloudposse/terraform-aws-iam-system-user.git?ref=tags/0.3.0>"
- module.kops_ecr_app.label
  Getting source "git::<https://github.com/cloudposse/terraform-null-label.git?ref=tags/0.3.3>"
- module.kops_ecr_app.kops_metadata
  Getting source "git::<https://github.com/cloudposse/terraform-aws-kops-metadata.git?ref=tags/0.1.1>"
- module.kops_ecr_app.kops_ecr
  Getting source "git::<https://github.com/cloudposse/terraform-aws-ecr.git?ref=tags/0.2.6>"
- module.kops_ecr_app.kops_ecr.label
  Getting source "git::<https://github.com/cloudposse/terraform-null-label.git?ref=tags/0.3.1>"
- module.kops_ecr_user.label
  Getting source "git::<https://github.com/cloudposse/terraform-null-label.git?ref=tags/0.3.1>"

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Error: output 'registry_url': "repository_url" is not a valid output for module "kops_ecr"
Error: output 'repository_name': "name" is not a valid output for module "kops_ecr"
Error: output 'kops_ecr_app_registry_url': "repository_url" is not a valid output for module "kops_ecr_app"
Error: output 'kops_ecr_app_repository_name': "name" is not a valid output for module "kops_ecr_app"

tarrallalmost 8 years ago

this is with terraform-root-modules:0.5.3

tarrallalmost 8 years ago

and cloudposse/geodesic:0.16.0

Erik Osterman (Cloud Posse)almost 8 years ago

@tarrall I think this is fixed in an upcoming PR

Erik Osterman (Cloud Posse)almost 8 years ago

https://github.com/cloudposse/terraform-root-modules/pull/35/files

tarrallalmost 8 years ago

yeah I was thinking that was likely, despite the misleading title

Erik Osterman (Cloud Posse)almost 8 years ago

yea, the PR should be updated

Erik Osterman (Cloud Posse)almost 8 years ago

code review changed the nature of the PR

Erik Osterman (Cloud Posse)almost 8 years ago

😃

Erik Osterman (Cloud Posse)almost 8 years ago

btw, definitely recommend forking or creating your own root modules sooner rather than later

Erik Osterman (Cloud Posse)almost 8 years ago

are you guys on codefresh?

tarrallalmost 8 years ago

and/or split out bugfix work from “I want to change the functionality” work

tarrallalmost 8 years ago

yeah

tarrallalmost 8 years ago

not on codefresh no

Erik Osterman (Cloud Posse)almost 8 years ago

I updated the PR description

Erik Osterman (Cloud Posse)almost 8 years ago

repository_name was renamed (easy fix on your side)

tarrallalmost 8 years ago

and yeah time to fork. Kinda in a “chicken and egg” situation where I’m just starting to set up services — no build server yet, we have bitbucket for code (shockingly bad but this should surprise no one, it’s atlassian after all), etc. All of this “build and publish a Dockerfile” workflow would be easier if I wasn’t in the middle of trying to set up ECR to … publish Dockerfiles 🙂

Erik Osterman (Cloud Posse)almost 8 years ago

yea, coldstart problems..

tarrallalmost 8 years ago

I’m just glad I already have a few years of experience in arguing with Terraform, or I’d probably be outside yelling at the cloud 🙂

Erik Osterman (Cloud Posse)almost 8 years ago

(you can possibly use dockerhub automated builds)

tarrallalmost 8 years ago

since I’m comfortable with vanilla terraform, including magic tricks like data sources / finding stuff by tags, I’m gonna just do a combination of “copy and modify” on your code and just rolling my own from scratch to get this going. Some experience writing Dockerfiles but less with the day-to-day workflow stuff like dockerhub, compose etc

Max Moonalmost 8 years ago

@Erik Osterman (Cloud Posse) Do you know if there are any known issues with upgrading the nginx ingress image using the cloudposse/nginx-ingress chart? Just curious, I have an edge case scenario that results in a (known) race condition issue in 0.11

Erik Osterman (Cloud Posse)almost 8 years ago

So it should be relatively straight forward

Erik Osterman (Cloud Posse)almost 8 years ago

I think we recently added a helmfile for the official ingress

Erik Osterman (Cloud Posse)almost 8 years ago

basically, our ingress gives you the fancy 404/500 pages

Erik Osterman (Cloud Posse)almost 8 years ago

but I can see why you'd want to move to the official one

Erik Osterman (Cloud Posse)almost 8 years ago

(we started ours before there was an official one)

Max Moonalmost 8 years ago

right right

Erik Osterman (Cloud Posse)almost 8 years ago

https://github.com/cloudposse/helmfiles/blob/master/helmfile.d/0330.stable-nginx-ingress.yaml

Erik Osterman (Cloud Posse)almost 8 years ago

so long as the ingress class is the same it, should be a drop in replacement

Erik Osterman (Cloud Posse)almost 8 years ago

but definitely test in staging first! 😃

Max Moonalmost 8 years ago

HAH

Max Moonalmost 8 years ago

who has time for that!

Erik Osterman (Cloud Posse)almost 8 years ago

the stable ingress comes with prometheus exporters for monitoring

Erik Osterman (Cloud Posse)almost 8 years ago

so it integrates nicely with grafana

Max Moonalmost 8 years ago

i don't mind being on the CP chart (we use the error pages), was moreso curious if you knew anyone using say... 0.13 nginx ingress

Erik Osterman (Cloud Posse)almost 8 years ago

btw, what did you guys decide to do for monitoring?

Max Moonalmost 8 years ago

still auditioning companies, i was in Ireland for two weeks in July so the monitoring got re-prioritized for.. next week

Erik Osterman (Cloud Posse)almost 8 years ago

we've gotten grafana working with the autodiscovery of dashboards in configmaps

Erik Osterman (Cloud Posse)almost 8 years ago

it's so freggin sweet

Max Moonalmost 8 years ago

we've got the portal up and rocking in both stage and prod, it's soooo nice

Erik Osterman (Cloud Posse)almost 8 years ago

i think that alone is a BIG motivator to use it

Erik Osterman (Cloud Posse)almost 8 years ago

maybe not for everything, but definitely as a first line of monitoring

Max Moonalmost 8 years ago

right right, i dig it!

Erik Osterman (Cloud Posse)almost 8 years ago

have you tried using the portal with argo yet?

Erik Osterman (Cloud Posse)almost 8 years ago

should be really easy

Max Moonalmost 8 years ago

not yet, we actually found our first use case for argo last week

Max Moonalmost 8 years ago

so that should be coming along... swiftly

Erik Osterman (Cloud Posse)almost 8 years ago

see this? https://github.com/cloudposse/helmfiles/pull/17

Max Moonalmost 8 years ago

as per usual, saving me time!

Erik Osterman (Cloud Posse)almost 8 years ago

it's slightly out of date

Max Moonalmost 8 years ago

also, re: race condition, will put some deets in #kubernetes for other folks?

Erik Osterman (Cloud Posse)almost 8 years ago

yea, that would be cool

Max Moonalmost 8 years ago

👍️

Erik Osterman (Cloud Posse)almost 8 years ago(edited)

or even open up an issue in our helmfiles or charts repos

Max Moonalmost 8 years ago

sounds good

Max Moonalmost 8 years ago

will do that in a bit

erikalmost 8 years ago

Erik Osterman (Cloud Posse)almost 8 years ago

Here's the slide I've been looking for that came from 2017 re:Invent talk on architecting security and governance across a multi-account strategy (SID331)

erikalmost 8 years ago

Erik Osterman (Cloud Posse)almost 8 years ago

It's very close to our reference architecutres.

Erik Osterman (Cloud Posse)almost 8 years ago

The "Enterprise Accounts" are more decomposed

July 2018 Browse by date September 2018