| locals { | |
| kubeconfig_file = "${path.module}/kubeconfig" | |
| } | |
| provider "local" {} | |
| # provider "kubernetes" { | |
| # config_path = local.kubeconfig_file | |
| # } |
| locals { | |
| kubeconfig_file = "${path.module}/kubeconfig" | |
| } | |
| provider "local" {} | |
| # provider "kubernetes" { | |
| # config_path = local.kubeconfig_file | |
| # } |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
Terraform v0.13 introduces a new provider source attribute that allows you to
declare the registry source of a terraform provider. This attribute is part of
the required_providers setting inside a terraform configuration block.
The Registry currently indexes Official and
Partner providers, and later work will allow for community providers as well,
which Terraform will automatically download and install on terraform init.
Terraform 0.13 has an entirely new provider installer that allows for greater control over individual provider installation methods. The breaking change is a new, required, subdirectory hierarchy for provider binaries.
The key differences between Terraform v0.12 and v0.13 are the directory hierarchy. Terraform v0.12 would look for a provider binary under the following directories:
| #!/bin/bash | |
| # Generate a `:something-intensifies:` Slack emoji, given a reasonable image | |
| # input. I recommend grabbing an emoji from https://emojipedia.org/ | |
| set -euo pipefail | |
| # Number of frames of shaking | |
| count=10 | |
| # Max pixels to move while shaking |
| source "https://rubygems.org" | |
| gem "octokit" |
