getporter / terraform-mixin Goto Github PK
View Code? Open in Web Editor NEWA Terraform Mixin for Porter
Home Page: https://getporter.org/mixins/terraform
License: Apache License 2.0
A Terraform Mixin for Porter
Home Page: https://getporter.org/mixins/terraform
License: Apache License 2.0
macos 10.15.6
docker 19.03.13
porter v0.29.1 (2e0f3648)
terraform mixin v0.6.0
$ cd examples/basic-tf-example
$ porter build
Copying porter runtime ===>
Copying mixins ===>
Copying mixin terraform ===>
Generating Dockerfile =======>
Writing Dockerfile =======>
Starting Invocation Image Build =======>
$ porter install
porter install
installing basic-tf-example...
executing install action from basic-tf-example (installation: basic-tf-example)
Install Terraform assets
Initializing Terraform...
/usr/bin/terraform terraform init
Initializing the backend...
Initializing provider plugins...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.local: version = "~> 1.4"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
stat rocks!: no such file or directory
Error: error running command terraform apply -auto-approve -input=false -var myvar=porter rocks!: exit status 1
err: error running command terraform apply -auto-approve -input=false -var myvar=porter rocks!: exit status 1
Error: mixin execution failed: exit status 1
Error: 2 errors occurred:
* container exit code: 1, message: <nil>. fetching outputs failed: error copying outputs from container: Error: No such container:path: eefa835f1f0b5e32b94330c7e5bb0817093710c6c172c7a89fe1348bfe1bfdca:/cnab/app/outputs
* required output myvar is missing and has no default
Terraform variables with spaces are not surrounded by quotes.
terraform apply -auto-approve -input=false -var myvar=porter rocks!
In following source code, quotes should be added:
terraform-mixin/pkg/terraform/install.go
Line 32 in 5f85f70
Is there ever a case where the auto-approve flag should be set to false? It seems to control if the CLI should be in interactive mode or not, and the mixin always needs to run in unattended mode. In other mixins, we have been setting flags that always need to be set automatically for the user. If that's the case for this flag here, I suggest that we just set it inside the mixin and not expose it.
I recently added working directory as a mixin level config, which lets the user override the default directory with all their terraform files. #61 Sometimes people have multiple terraform modules though, and its not possible to use more than one in the same bundle. We should add working directory to the terraform mixin command so that you can do something like this:
install:
- terraform:
workingDir: mymodule1
- terraform:
workingDir: mymodule2
As part of mixin's build, we output the following lines, so that the invocation image has the providers installed. The problem with this is that any time that you change anything in the bundle, whether or not it's related to terraform, init is run again and the layer cache is invalidated. When a small bundle clocks in at 1.6GB this is a problem.
COPY . $BUNDLE_DIR
RUN cd %s && terraform init -backend=false
What if we encouraged people to put their provider declarations into a separate file, e.g. providers.tf, and then only copied that file into the bundle before running init? The rest is copied into the bundle later when we copy the bundle contents.
mixins:
- terraform:
initFile: providers.tf # relative to the workingDir
See this discussion for context: getporter/porter#2279 (reply in thread)
In some cases, just calling terraform init isn't sufficient to avoid calls back to download providers at runtime, particularly when a remote backend is being used (since we call init again in that case). Looks like we should also call mirror so that the second call to init at runtime grabs the files from the bundle and not by redownloading the provider files.
I've noticed that the var field shows red squiggles in VS Code when filled out properly. The mixin's schema needs to be corrected to reflect the supported mixin syntax so that it doesn't happen. This is more important than red squiggles because eventually mixin schema will be used to lint and validate the porter.yaml, so this would become a hard error.
The terraform bundle cli tests were ported over from the main Porter repo in #39.
It would be preferable to convert this into an integration test (see the tests
dir, currenly holding the one schema integration test). Makefile logic/cruft dealing with setup for the script (and the script itself) can then be removed.
Newer versions of terraform (post v0.14.0) have quotes around string outputs, instead of just the string value. The value isn't usable until you do extra work to strip off the quotes.
Upstream terraform issue: hashicorp/terraform#26831
Workarounds involve either using -json and then piping to jq, or using the new -raw flag.
Update the brigade.js
script w/ latest best practices/utilities
Add support for handling issue comment events (e.g. /brig run
)
Currently, the mixin is currently using a dated Terraform version. Terraform CLI is currently available in version 1.0.4
.
The terraform-mixin should use the most recent version
Remote backend functionality was added to this mixin in #9. In addition, an example bundle was added.
However, this mixin does not yet handle outputs. We need to add functionality such that this mixin supplies terraform outputs to bundle authors.
Update this repo to use Go modules. Ref getporter/porter#845
Not sure if this is a Porter issue or a porter-terraform
issue, but my outputs have newlines at the end:
porter instance show HELLO -o json
{
"name": "HELLO",
"revision": "01DKFNVYXP9RVM2GT71BC0MZ2V",
"created": "2019-08-29T15:47:24.981725-06:00",
"modified": "2019-08-29T15:52:54.198351-06:00",
"bundle": {
"schemaVersion": "v1.0.0-WD",
"name": "HELLO",
"version": "0.1.0",
"description": "An example Porter configuration",
"invocationImages": [
{
"imageType": "docker",
"image": "jeremyrickard/porter-do:v0.1.0"
}
],
"images": {
"spring-music": {
"imageType": "docker",
"image": "jeremyrickard/spring-music@sha256:3bf5403b1fdaa0569ffbf32e046241d8f8adef1d586d85fe7f6d5175c48f8e83",
"contentDigest": "sha256:3bf5403b1fdaa0569ffbf32e046241d8f8adef1d586d85fe7f6d5175c48f8e83",
"description": "Spring Music Example"
}
},
"parameters": {
"database_name": {
"definition": "database_name",
"destination": {
"env": "DATABASE_NAME"
}
},
"porter-debug": {
"definition": "porter-debug",
"description": "Print debug information from Porter when executing the bundle",
"destination": {
"env": "PORTER_DEBUG"
}
},
"region": {
"definition": "region",
"destination": {
"env": "REGION"
}
},
"space_name": {
"definition": "space_name",
"destination": {
"env": "SPACE_NAME"
}
}
},
"credentials": {
"do_access_token": {
"env": "DO_ACCESS_TOKEN"
},
"do_spaces_key": {
"env": "DO_SPACES_KEY"
},
"do_spaces_secret": {
"env": "DO_SPACES_SECRET"
},
"kubeconfig": {
"path": "/root/.kube/config"
}
},
"outputs": {
"db_password": {
"definition": "db_password",
"path": "/cnab/app/outputs/db_password"
},
"db_user": {
"definition": "db_user",
"path": "/cnab/app/outputs/db_user"
}
},
"definitions": {
"database_name": {
"default": "jrrportertest",
"type": "string"
},
"db_password": {
"type": "string"
},
"db_user": {
"type": "string"
},
"porter-debug": {
"default": false,
"description": "Print debug information from Porter when executing the bundle",
"type": "boolean"
},
"region": {
"default": "nyc3",
"type": "string"
},
"space_name": {
"default": "jrrportertest",
"type": "string"
}
},
"custom": {
"io.cnab.dependencies": null,
"sh.porter": {
"manifestDigest": "4b3800a5218ad487ba0205709e22cb5794fa59bc6857aff246cd8babc5eb597c"
}
}
},
"result": {
"message": "",
"action": "install",
"status": "success"
},
"parameters": {
"database_name": "porternetes",
"porter-debug": true,
"region": "nyc3",
"space_name": "porternetes"
},
"outputs": {
"db_password": "h69279993kyf78oc\n",
"db_user": "doadmin\n"
}
}
This ends up breaking when I try to use them inside a single string, for example here is a bit of rendered YAML before calling the helm mixin:
helm:
chart: charts/spring-music
description: Deploy Spring Music with Helm
name: spring-music-helm
replace: true
set:
deploy.datasource: jdbc:postgresql://porternetes-do-user-6482440-0.db.ondigitalocean.com
:25060
/defaultdb
?sslmode=require&user=doadmin
&password=ccpto35006fxn4uy
deploy.image: jeremyrickard/spring-music@sha256:3bf5403b1fdaa0569ffbf32e046241d8f8adef1d586d85fe7f6d5175c48f8e83
deploy.profile: postgresql
Split up and passed to an app separately the app gets a string like this (notice the spaces after each):
jdbc:postgresql://porternetes-do-user-6482440-0.db.ondigitalocean.com :25060 /defaultdb ?sslmode=require&user=doadmin &password=h69279993kyf78oc
The latest schema for porter.yaml supports a new template format, ${bundle.parameters.NAME}, that allows Porter to inject non-string values into a mixin field, such as a number or boolean.
The terraform mixin is assuming that all variables were defined as strings, which causes the wrong value to be printed for vars when translated to a CLI call
terraform destroy -auto-approve -input=false -var address_space=10.80.28.0/24 -var create_aad_groups=%!s(bool=false) -var shared_storage_quota=%!s(int=50) -var tre_id=tk20a
In the example above, shared_storage_quota was specified as an integer, and create_aad_groups a bool, so we are seeing a Go string replacement error printed out
The error seems to be originating from this line, though we should look for more go format strings with %s
used.
Outputs from the terraform mixin have a trailing \n
which can cause issues if they're used in later steps. I believe the cause of the \n
is that terraform appends one to the value when you call terraform output <output>
and this mixin doesn't remove it.
The good news is that terraform output
has a nifty --json
option which gives the following output:
$ terraform output --json
{
"namespace": {
"sensitive": false,
"type": "string",
"value": "mynamespace"
}
}
A possible fix would be to fetch all the outputs from Terraform and then parse them in the porter mixin to get the correct value (and type!) of the output.
I noticed that we call terraform init at buildtime which is great. I added #79 to make that perform even better.
But since we have that, is there a reason that we call init again when when run the bundle? I'm noticing that it's causing terraform to re-download and install providers that were already installed (or at least that's what the output implies).
Initializing Terraform...
/usr/bin/terraform terraform init
Initializing the backend...
Initializing provider plugins...
- Reusing previous version of hashicorp/azurerm from the dependency lock file
- Reusing previous version of hashicorp/random from the dependency lock file
- Installing hashicorp/azurerm v2.72.0...
- Installed hashicorp/azurerm v2.72.0 (signed by HashiCorp)
- Installing hashicorp/random v3.1.0...
- Installed hashicorp/random v3.1.0 (signed by HashiCorp)
Terraform has made some changes to the provider dependency selections recorded
in the .terraform.lock.hcl file. Review those changes and commit them to your
version control system if they represent changes you intended to make.
Terraform has been successfully initialized!
Since we only need the terraform init call at runtime when a remote backend is configured (as opposed to the bundle uses porter's state functionality), we should add an if statement around that init call so that we only do it when remote backend configuration is present.
Hi there,
In PR #91 there was a change to the way that this mixin grabs output from Terraform. Specifically, the mixin now requests output values as json
rather than raw
format. Here is the change in question:
Unfortunately, due to some strange formatting rules within Terraform, this breaks any URI that includes an ampersand (i.e. URIs or URLs that have querystring parameters) and this is a common case for connection strings or service endpoints.
My investigation into an issue has been written up here, and includes a small repro sample that demonstrates the issue:
microsoft/AzureTRE#2549 (comment)
There is a closed Terraform issue describes this behaviour and it was closed by simply adding additional documentation to explain the behaviour (and a comment that they will never change this behaviour):
hashicorp/terraform#26110
The fix was to better document it:
hashicorp/terraform#26122
Can the terraform-mixin either switch back to using the -raw
flag when accessing TF outputs? I'm not sure what the alternative is (I'm not sure how safe it would be to patch up/replace these encoded characters)
Right now, the mixin has the configuration directory hard coded. I think that we should allow users to specify this for a few reasons:
1.) The JSON schema include that, so tooling can prompt users, so there is less "magic" to know
2.) We can enable people to use the mixin more than once in a single bundle (for complex scenarios)
3.) In general it just gives people more flexibility.
repro:
- terraform
mixinexpected: I am a good person on this horrible planet
received:
squillace@dellsquill:~/work/squillace/pwc$ porter mixins list
---------------------------------------------
Name Version Author
---------------------------------------------
atlas v0.0.0 ralph squillace
az v0.7.3 Porter Authors
exec v1.0.0-beta.3 Porter Authors
terraform v0.10.0 Porter Authors
squillace@dellsquill:~/work/squillace/pwc$ porter build
exit status 1
exit status 1
exit status 1
Copying porter runtime ===>
Copying mixins ===>
Copying mixin exec ===>
Copying mixin az ===>
Copying mixin atlas ===>
Copying mixin terraform ===>
Building invocation image
[+] Building 2.5s (19/26)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.90kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 35B 0.0s
=> resolve image config for docker.io/docker/dockerfile-upstream:1.4.0 0.1s
=> CACHED docker-image://docker.io/docker/dockerfile-upstream:1.4.0@sha256:178c4e4a93795b9365dbf6cf10da8fcf517fcb4a17f1943a775c0f548e9fc2ff 0.0s
=> [internal] load .dockerignore 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> [internal] load metadata for docker.io/library/debian:stretch-slim 0.1s
=> [internal] load build context 1.4s
=> => transferring context: 187.14MB 1.4s
=> [stage-0 1/18] FROM docker.io/library/debian:stretch-slim@sha256:abaa313c7e1dfe16069a1a42fa254014780f165d4fd084844602edbe29915e70 0.0s
=> CACHED [stage-0 2/18] RUN useradd nonroot -m -u 65532 -g 0 -o 0.0s
=> CACHED [stage-0 3/18] RUN rm -f /etc/apt/apt.conf.d/docker-clean; echo 'Binary::apt::APT::Keep-Downloaded-Packages "true";' > /etc/apt/apt.conf.d/keep-cache 0.0s
=> CACHED [stage-0 4/18] RUN --mount=type=cache,target=/var/cache/apt --mount=type=cache,target=/var/lib/apt apt-get update && apt-get install -y ca-certificates 0.0s
=> CANCELED [stage-0 5/18] RUN apt-get update && apt-get -y install gnupg wget && wget -qO - https://pgp.mongodb.com/server-5.0.asc | apt-key add - && echo "deb [ arch=amd64,arm64 ] https:/ 1.7s
=> CACHED [stage-0 6/18] RUN apt-get update && apt-get install -y apt-transport-https lsb-release gnupg curl 0.0s
=> CACHED [stage-0 7/18] RUN curl -sL https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > /etc/apt/trusted.gpg.d/microsoft.asc.gpg 0.0s
=> CACHED [stage-0 8/18] RUN echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/azure-cli.list 0.0s
=> CACHED [stage-0 9/18] RUN apt-get update && apt-get install -y azure-cli 0.0s
=> CACHED [stage-0 10/18] RUN apt-get update && apt-get install -y wget unzip && wget https://releases.hashicorp.com/terraform/1.0.4/terraform_1.0.4_linux_amd64.zip && unzip terraform_1.0. 0.0s
=> ERROR [stage-0 11/18] COPY terraform/ /cnab/app/terraform/ 0.0s
------
> [stage-0 11/18] COPY terraform/ /cnab/app/terraform/:
------
error building docker image: failed to solve: failed to compute cache key: "/terraform" not found: not found
unable to build CNAB invocation image: error building docker image: failed to solve: failed to compute cache key: "/terraform" not found: not found
unable to build CNAB invocation image: error building docker image: failed to solve: failed to compute cache key: "/terraform" not found: not found
#105 adds support for setting the user agent string used by the terraform azure provider to include info about porter. We should do the same for any other interested providers. Since I've seen the aws mixin uses an environment variable to set the user agent string too (getporter/aws-mixin#34), let's start there and populate the aws user agent environment variable like we do with the azure one.
Currently, this mixin's install action will automatically create a tfvars file for any terraform vars provided in a vars
block. However, some bundles may inject vars via the env (like the azure-keyvault bundle) and thus provide no vars
block on install. The problem here is the tfvars file is then created with just null
as its contents and thus terraform errors out.
(This default can be switched off via disableVarFile: true
)
Proposed fix is to continue to gen the tfvars file as a default but, when the vars
block is empty, have the contents of this file be {}
, valid json.
When installing the terraform binary (https://github.com/getporter/terraform-mixin/blob/174d233556c4fe36df78abd2f238b2550662d346/pkg/terraform/build.go) a zip file is downloaded and unzipped, but the zip file remains and adds an unnecessary 33 MB from an image which already is quite large
In some cases I need to use an output immediately as a file, for example:
To do this without fussing with the exec mixin, the terraform outputs should be able to be sent to a file like so:
install:
- terraform:
description: "Create infrastructure"
vars:
installation: "{{ installation.name}}"
location: "{{ bundle.parameters.location }}"
outputs:
- name: connstr
- name: kubeconfig
destinationFile: /root/.kube/config
mixins:
- terraform
This results in the following error
Error: unable to build CNAB invocation image: failed to stream docker build output: The command '/bin/sh -c cd /cnab/app/terraform && terraform init -backend=false' returned a non-zero code: 2
After making a directory named terraform at the root of the bundle, the build passes. Seems like we have a hard coded assumption about where the terraform files are kept that should more gracefully handle when it's not there, or return an error during lint.
I'm getting the following error when I uninstall the porter terraform test CI bundle:
$ ./bin/porter uninstall --insecure --debug --param file_contents='foo!'
uninstalling porter-terraform...
uninstalling bundle porter-terraform (/Users/carolynvs/go/src/github.com/deislabs/porter/bundle.json) as porter-terraform
params: [file_contents porter-debug]
creds: []
executing porter uninstall configuration from /cnab/app/porter.yaml
Uninstall Terraform assets
Initializing Terraform...
/usr/bin/terraform terraform init
Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "local" (1.2.1)...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.local: version = "~> 1.2"
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
/usr/bin/terraform terraform destroy -auto-approve
var.file_contents
Contents of the file 'foo'
Enter a value:
var.file_contents
Contents of the file 'foo'
Enter a value:
var.file_contents
Contents of the file 'foo'
Enter a value:
var.file_contents
Contents of the file 'foo'
Enter a value:
Error: Error asking for user input: missing required value for "file_contents"
Error: exit status 1
err: exit status 1
Error: mixin execution failed: exit status 1
Error: failed to uninstall the bundle: container exit code: 1
I think it's because the mixin isn't passing the param to the terraform cli for uninstall? Just a guess.
When the author writes the bundle, they don't know if the end user will have existing terraform accounts/infra. Instead of having the bundle decide if it uses a remote backend or not, it should be optional configuration that the end user may supply when running the bundle. If it's not specified, then bundle state is used instead.
I'm not sure yet what this should look like, more design work is needed, but I wanted to get this out there that we are putting this configuration in the wrong spot.
I noticed that we use two different default naming standards for the state files generated by the terraform mixin:
It seems that .tfvars is the preferred extension and would be more consistent with our other file generated by the mixin. Can we change the default to terraform.tfvars?
Update this mixin's schema (For reference, check out the kubernetes mixin schema in: https://github.com/deislabs/porter/blob/master/pkg/kubernetes/schema/kubernetes.json)
Add schema tests, as appropriate (can reference same mixin above)
This mixin can be refactored to use Porter's exec/builder pkg, which offers a common set of interfaces for cli-based mixins. #25 moves the dial a little bit closer, but we should be able to trim a good bit of code in the refactor.
As I understand it, the input flag toggles interactively prompting for required variables. Since bundles don't support interactive tty, this setting can never be flipped to true. Am I missing something or can we remove it?
I'm wondering whether terraform creates this directory now? What changed? any ideas, @vdice or @carolynvs ?
https://github.com/squillace/blowschunks is a bundle; what happens when you build with porter v0.38.1 (3018b91c) is:
Writing Dockerfile =======>
FROM debian:stretch-slim
ARG BUNDLE_DIR
RUN apt-get update && apt-get install -y ca-certificates
ENV TERRAFORM_VERSION=0.12.17
RUN apt-get update && apt-get install -y wget unzip && \
wget https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip && \
unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip -d /usr/bin
COPY . $BUNDLE_DIR
RUN cd /cnab/app/terraform && terraform init -backend=false
# exec mixin has no buildtime dependencies
COPY . $BUNDLE_DIR
RUN rm $BUNDLE_DIR/porter.yaml
RUN rm -fr $BUNDLE_DIR/.cnab
COPY .cnab /cnab
WORKDIR $BUNDLE_DIR
CMD ["/cnab/app/run"]
Starting Invocation Image Build (getporter/porter-hello-installer:v0.1.0) =======>
Step 1/13 : FROM debian:stretch-slim
---> 546475075b6c
Step 2/13 : ARG BUNDLE_DIR
---> Using cache
---> dbf5a3ec6635
Step 3/13 : RUN apt-get update && apt-get install -y ca-certificates
---> Using cache
---> f9d60b6f9aaa
Step 4/13 : ENV TERRAFORM_VERSION=0.12.17
---> Using cache
---> 368b927d60b9
Step 5/13 : RUN apt-get update && apt-get install -y wget unzip && wget https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip && unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip -d /usr/bin
---> Using cache
---> ec088e537dc8
Step 6/13 : COPY . $BUNDLE_DIR
---> Using cache
---> e883b594938d
Step 7/13 : RUN cd /cnab/app/terraform && terraform init -backend=false
---> Running in d6badbe616b0
/bin/sh: 1: cd: can't cd to /cnab/app/terraform
Error: unable to build CNAB invocation image: failed to stream docker build output: The command '/bin/sh -c cd /cnab/app/terraform && terraform init -backend=false' returned a non-zero code: 2
Playing with this mixin on Kubernetes, I found one area of friction is storing the Terraform state. Either one would need to copy the state file between CNAB actions or use some remote backend.
With Terraform 0.13, currently there's an RC out, a Kubernetes secret backend will be added which makes this a lot less painful.
As the version of Terraform is currently hardcoded in the mixin, it's not easy to use this feature as one would have to rebuild the mixin. I think that wanting to specify versions of tools will actually be quite common, would it make sense to add a mixin config that allows this?
Add build badge to top of README.
Pipeline is: https://dev.azure.com/getporter/porter/_build?definitionId=10
Hi!
I receive the following error when passing an object into terraform plan configured with object variable:
err: could unmarshal input:
upgrade:
1 error occurred:
* container exit code: 1, message:
Here is example porter config:
upgrade:
Would be great if terraform mixin supported passing objects into plan.
Hello porter-heads ๐
Does the team has any thoughts on controlling the version of terraform within the mixin or the mixin version within porter.yaml
? Ideally, I want to keep on top of terraform releases without having to wait for porter-terraform mixin releases (e.g. currently porter-terraform is 3 minor versions behind) but with the current mixin artifact shipping the terraform runtime as is done today (and being new to porter), I'm not sure how that could be achieved. Since the stack is very docker-centric, I wonder if pulling a terraform image at porter build or runtime would be a potential approach. Thoughts? Maybe I've missed how this can be controlled through configuration. If so, please point me to that and I'd gladly help document it.
Thanks for the fine work here!
Add ability to use a remote backend. This is currently a necessity to fetch and update state between CNAB action runs.
This may include a refactor to allow all lifecycle actions (install, uninstall, upgrade) to run terraform init
prior to the lifecycle action, perhaps as a default. (Currently only install runs init and this is explicitly specified by the porter yaml...)
For an example using an Azure Storage backend, see the example bundle in https://github.com/deislabs/example-bundles/tree/master/aks-terraform
Look into possibilities around unit tests where this mixin code interacts with the terraform cli.
As mentioned in #50 (comment), it would be handy to be able to write unit tests that interact with terraform cli output, instead of resorting to cli/integration testing.
Add output options for applicable terraform commands. For instance, terraform show
(invoked by the status
action logic in this mixin) can output in json, though note it does require a terraform client of v0.12 or later (as of writing, we use 0.11.11).
For implementation, reference https://github.com/deislabs/porter-helm/blob/master/pkg/helm/status.go
Mixin version 1.0.0
Porter is adding the following RUN command during build which is causing the following error: #15 2.833 Too many command line arguments. Configuration path expected.
#15 ERROR: executor failed running [/bin/sh -c cd $BUNDLE_DIR/terraform && terraform init -backend=false && rm -fr .terraform/providers && terraform providers mirror /usr/local/share/terraform/plugins]: exit code: 1
RUN cd $BUNDLE_DIR/terraform &&
terraform init -backend=false &&
rm -fr .terraform/providers &&
terraform providers mirror /usr/local/share/terraform/plugins
I am using terraform 0.12.31 which does not support terraform provider mirrors.
TODO: Determine if it's possible to set the user agent of the azure resource provider
Add an example porter bundle using this mixin, using a real-world/cloud provider resource.
Currently, we (re)-run terraform init
at run time before any lifecycle action (install, uninstall, etc.)
Once we have the context necessary to do so, let's consider running terraform init
at invocation image build time. See #3 (comment) for the genesis of this idea.
Porter ticket in getporter/porter#262
For due diligence, here are the init docs: https://www.terraform.io/docs/commands/init.html
The git
binary is needed when Terraform references git/github modules. It is only required in the build phase as we mirror all providers/modules.
One way to handle the situation is to use a custom docker template and install git before the PORTER_MIXINS
placeholder.
I thought we can add a setting to the mixin to optionally install git much like we install wget and unzip. WDYT?
This mixin currently has rudimentary custom action support for use in a porter.yaml
manifest, e.g.
customActions:
plan:
description: "Invoke 'terraform plan'"
modifies: false
stateless: true
...
plan:
- terraform:
description: "Invoke 'terraform plan'"
# by default, the mixin will call terraform with a command
# with the same name as the custom action; however, we can
# override with:
command: "plan"
However, a custom action might require an arbitrary set of args/options to send along to terraform. Therefore, we have a need to add an additional args
block to support this... perhaps something like:
plan:
- terraform:
description: "Invoke 'terraform plan'"
command: "plan"
args:
- "-var foo=bar"
- "-refresh=true"
...
Or, similar to how the exec mixin does things, a flags
block:
plan:
- terraform:
description: "Invoke 'terraform plan'"
command: "plan"
flags:
var: foo=bar
refresh: true
...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.