Tiller module #25

yorinasub17 · 2019-05-01T00:48:33Z

Depends on gruntwork-io/kubergrunt#44

This implements the idea mentioned in slack. Specifically, instead of using kubergrunt for the entire helm deployment process, we use it for specific functionality to support the deployment, and then rely on the kubernetes provider to manage the underlying Deployment resource. This has a number of benefits:

This is much more robust to partial failures, as there are less things to roll back if a failure occurs in kubergrunt.
This is flexible for the consumer, as now it is easier to pick and choose specific kubergrunt functionalities to use. For example, one can replace TLS management with a different process (e.g cert-manager), but still use kubergrunt for waiting for helm deployment.
This is a step towards providing pure terraform versions of the TLS management, for those that are not state security sensitive.
destroy can now be done without setting up the helm client.

Note that as a consequence of this, the examples are more complicated because there are multiple kubergrunt calls for each phase as opposed to just one. This is a tradeoff of making the unhappy path easier to manage, at the expense of complexity for the happy path.

That said, I think in the long run this is more production ready because it handles updates and changes much better.

yorinasub17 · 2019-05-01T00:49:03Z

.circleci/config.yml

    GRUNTWORK_INSTALLER_VERSION: v0.0.21
    TERRATEST_LOG_PARSER_VERSION: v0.13.13
-    KUBERGRUNT_VERSION: v0.3.6
+    KUBERGRUNT_VERSION: v0.3.8-alpha1


REMINDER: don't forget to set this to a real release.

yorinasub17 · 2019-05-01T00:50:34Z

examples/k8s-tiller-minikube/README.md

-
-**Note**: You need to be an administrator to run this command. Specifically, this should be done with the same `kubectl`
-context as the one used to deploy Tiller. You can use the `--kube-context` option to use a different context from the
-default.


This is now irrelevant, because upgrades can be done by modifying the vars to the k8s-tiller module call.

Just curious: This is done by upgrading the tiller_image_version?

Yup that is correct. Updating tiller_image_version will trigger a new rollout of the Deployment resource and the Pods will be restarted.

yorinasub17 · 2019-05-01T00:51:57Z

main.tf

+    # Then use that CA to generate server TLS certs
+    kubergrunt tls gen --namespace ${module.tiller_namespace.name} --ca-secret-name ${local.tls_ca_secret_name} --ca-namespace kube-system --secret-name ${local.tls_secret_name} --secret-label gruntwork.io/tiller-namespace=${var.tiller_namespace} --secret-label gruntwork.io/tiller-credentials=true --secret-label gruntwork.io/tiller-credentials-type=server --tls-subject-json '${jsonencode(var.tls_subject)}' --tls-private-key-algorithm ${var.private_key_algorithm} ${local.tls_algorithm_config} ${local.kubectl_config_options}
+    EOF
+  }


These long string kubergrunt calls are sad, but I am opening a discussion to open source package-terraform-utilities so that we can do the esc_newl trickery in the EKS module: https://github.com/gruntwork-io/terraform-aws-eks/blob/master/examples/eks-cluster-with-supporting-services/core-services/main.tf#L126

rileykarson

Mostly just comment suggestions / questions

rileykarson · 2019-05-01T15:56:40Z

examples/k8s-tiller-minikube/README.md

-
-**Note**: You need to be an administrator to run this command. Specifically, this should be done with the same `kubectl`
-context as the one used to deploy Tiller. You can use the `--kube-context` option to use a different context from the
-default.


Just curious: This is done by upgrading the tiller_image_version?

rileykarson · 2019-05-01T16:00:46Z

main.tf

+  namespace                                = "${module.tiller_namespace.name}"
+  tiller_image_version                     = "${var.tiller_version}"
+
+  # Kubergrunt will store the private key under tls.pem


Suggested change

# Kubergrunt will store the private key under tls.pem

# kubergrunt stores the private key in the current directory as tls.pem

This reads a bit like a magic var to me right now- more imperative text & explicitly stating it's the current dir helps my understanding. (Unless it's wrong, of course)

This is actually the name of the key in the kubernetes Secret, which is mounted on to the container in a directory (hence, the use of the word filename). I updated to:

# Kubergrunt will store the private key under the key "tls.pem" in the corresponding Secret resource, which will be # accessed as a file when mounted into the container.

Thanks for clarifying!

rileykarson · 2019-05-01T16:04:54Z

main.tf

+  dependencies = ["${null_resource.tiller_tls_certs.id}"]
+}
+
+# We use kubergrunt to wait for Tiller to be deployed. Any resources that depend on this can assume Tiller is


Should we eliminate the first bit?

We use kubergrunt to wait for Tiller to be deployed.

It feels like we're repeating ourselves, since it's written right below. I'm a lot more interested in why, which you cover in the second sentence

Any resources that depend on this can assume Tiller is successfully deployed and up at that point.

Makes sense. Updated to:

# The Deployment resources created in the module call to `k8s-tiller` will be complete creation before the rollout is # complete. We use kubergrunt here to wait for the deployment to complete, so that when this resource is done creating, # any resources that depend on this can assume Tiller is successfully deployed and up at that point.

To be more explicit about the why.

modules/k8s-tiller/README.md

rileykarson · 2019-05-01T16:09:17Z

modules/k8s-tiller/README.md

+
+* See the [root README](/README.md) for instructions on using Terraform modules.
+* This module uses [the `kubernetes` provider](https://www.terraform.io/docs/providers/kubernetes/index.html).
+* See the [examples](/examples) folder for example usage.


Suggested change

* See the [examples](/examples) folder for example usage.

Updating this to point to the root example:

* See [the example at the root of the repo](/) for example usage.

rileykarson · 2019-05-01T16:12:30Z

modules/k8s-tiller/main.tf

+# resources backing the values in the dependencies list.
+# ---------------------------------------------------------------------------------------------------------------------
+
+resource "null_resource" "dependency_getter" {


Is this a variant of https://github.com/gruntwork-io/terraform-google-sql/blob/master/modules/cloud-sql/main.tf#L113-L120, or am I missing something? If that's the case- that they're duplicated- we should use a consistent implementation + naming scheme across modules.

This is the same thing, but I've been using this implementation in this repo for a while...

The other implementation is probably more correct though so I will go through and update the usage.

Actually, I like using a list input as opposed to string, as it makes the resulting input more readable when you have multiple dependencies. Any objection to standardizing to a list input for this? @autero1

(to be clear, I don't mind which we choose, I just prefer that they're the same and we don't need to block on this)

Standardizing to a list input sounds good!

Co-Authored-By: yorinasub17 <430092+yorinasub17@users.noreply.github.com>

yorinasub17 · 2019-05-02T16:20:42Z

OK reverted back to using dependencies as the dependency input. This should now be in parity with gruntwork-io/terraform-google-sql#32. Going to merge and release this once the build passes.

yorinasub17 · 2019-05-02T16:32:21Z

Ok build passed. Merging and releasing!

yorinasub17 added 4 commits April 30, 2019 13:52

Working protoype

aea4bf7

Working protoype

d7a768b

Clean up

8b0b936

Use alpha version of kubergrunt

5fd0b86

yorinasub17 requested review from autero1 and robmorgan as code owners May 1, 2019 00:48

yorinasub17 requested a review from rileykarson May 1, 2019 00:48

yorinasub17 commented May 1, 2019

View reviewed changes

Remove unnecessary vars

0404a45

yorinasub17 mentioned this pull request May 1, 2019

Pure Terraform TLS Management #26

Merged

rileykarson approved these changes May 1, 2019

View reviewed changes

rileykarson and others added 4 commits May 1, 2019 12:45

Update modules/k8s-tiller/README.md

3e005c1

Co-Authored-By: yorinasub17 <430092+yorinasub17@users.noreply.github.com>

Address PR comments

7ea0f43

Use released kubergrunt in test

ba9d9c5

dependency_getter => wait_for

31a14b2

autero1 mentioned this pull request May 2, 2019

Standardizing dependencies to a list input gruntwork-io/terraform-google-sql#32

Merged

Revert input to be dependencies as opposed to wait_for

067a608

yorinasub17 merged commit 31a1e30 into master May 2, 2019

yorinasub17 deleted the yori-tiller-module branch May 2, 2019 16:32

	# Kubergrunt will store the private key under tls.pem
	# kubergrunt stores the private key in the current directory as tls.pem

Tiller module #25

Tiller module #25

Uh oh!

Conversation

yorinasub17 commented May 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rileykarson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rileykarson May 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yorinasub17 commented May 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yorinasub17 commented May 2, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

yorinasub17 commented May 1, 2019 •

edited

Loading

rileykarson May 1, 2019 •

edited

Loading

yorinasub17 commented May 2, 2019 •

edited

Loading