-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wait what? | the case for nhite #1
Comments
Hello @tomdavidson, Many thanks for your issue. This is the purpose of my posts: to get feedback, so I can decide whether a POC should die or be turned into a product. First of all, I didn't know terraformctl. It looks like the project is a month old; same as nhite. It also looks like it is heavily related to kubernetes. Therefore, you need to set up this kind of infrastructure to take advantage of it. Anyway, I am confident that @kris-nova have done a good job and I will take a further look asap. For the second point, let me explain what gave me the idea of the core principle: So far, so good. There have been a test with terraform. I won't do the apology of terraform here, but it has obvious advantages over cloudformation.
So far "nhite" do not give answer to all those questions; but it could (I think). For example you can have two services on different port numbers. One with the credentials that allows access to the production, the other one with access to the dev environment; deploying on one or the other is simply done by changing the address of the nhite server from the client perspective. Actually, it's all about the "build vs buy". You can (I think) use terraform enterprise that; it will fit most of your needs but not all of them (and I would appreciate if you could confirm that). Or you can build a solution that would fit all your needs. I will let this issue opened for now, in case anybody wants to add his 2 cents. |
Awesome and thank you for sharing a bit of your experience on that ops team. Terraform Enterprise (Atlas) costs $10k per user and all of the organizations I have worked at have had a broad range of diverse users - app dev teams, not just ops teams, so it has been too expensive (especially for orgs on the AWS hype train that what to prescribe CloudFormation). Its value pitch seems targeted at ops teams that want to adopt some CI/CD. This is not aligned with my initiatives of dev teams practicing DevOps. On some levels it seems that for TF to be part of the cloud native app, it can not be guarded by only the ops or platform team. I sometimes question "my theory of TF" so I wanted to find out more. Which is why I am coming across projects such as this one and terraformctl. I want a K8S service the gives that gives access to TF and allows TF plans to be bundled with Helm Charts and K8S Operators so they can natively interact with the Cloud APIs. Maybe TF Plans are use to create CRDs ...? I clearly do not have a complete understanding of what is involved. Prima facie, do you think this fits into the challenges you want nhite to answer? Few other thoughts on how/where nhite fits:
Does the required version help or are you thinking of something more on the side of updating the binary? terraform {
required_version = ">= 0.10.7"
}
Isn't this an IAM issue? I know this is a really problem just doesn't seem to be a Terraform problem.
Not the IaC code change in SCM, but something more along the lines of CloudTrail?
IAM and Code Review?
More than your ci/cd job witching tf workspaces? |
@owulveryck I just read your blog post about this project and you seem to down play it as poc or just for fun but I have a few questions anyway. No criticism, just seeking understanding and how this fits with something I would like to contrib/work on:
The text was updated successfully, but these errors were encountered: