With the TechZone Accelerator Toolkit IBM software, open source projects and custom applications can easily be deployed to various clouds. This article explains how input and output variables of modules are defined.
Check out my earlier blog that introduces the toolkit: Introducing IBM’s Toolkit to handle Everything as Code. The toolkit leverages Terrafrom and GitOps and is based on best practices from IBM projects with partners and clients.
Solutions are defined via bill of materials (BOMs) which contain lists of modules. In the following example an OpenShift cluster is created in the IBM Cloud which comes with Argo CD, a GitOps repo, Watson NLP and a sample application based on ubi.
1
2
3
4
5
6
7
8
9
10
11
apiVersion: cloudnativetoolkit.dev/v1alpha1
kind: BillOfMaterial
metadata:
name: cluster-with-watson-nlp
spec:
modules:
- name: ibm-ocp-vpc
- name: argocd-bootstrap
- name: gitops-repo
- name: terraform-gitops-ubi
- name: terraform-gitops-watson-nlp
Modules have input and output variables. Read my blog Configuring the TechZone Accelerator Toolkit how to use input variables to configure BOMs for different scenarios.
The input variables are defined by convention in the variables.tf files of modules via Terraform and HCL.
1
2
3
4
5
6
7
variable "registries" {
type = list(map(string))
default = [{
name = "watson"
url = "cp.icr.io/cp/ai"
}]
}
The readme files of the modules also describe how to use modules and pass in variables if you would use Terraform directly and not the toolkit which is useful for module developers to test their modules.
1
2
3
4
5
module "terraform_gitops_watson_nlp" {
source = "github.com/cloud-native-toolkit/terraform-gitops-watson-nlp?ref=v0.0.80"
accept_license = var.terraform_gitops_watson_nlp_accept_license
...
}
The output variables are defined by convention in output.tf files.
1
2
3
4
5
output "namespace" {
description = "The namespace where the module will be deployed"
value = local.namespace
depends_on = [resource.gitops_module.setup_gitops]
}
Some variables are defined on a global level which is useful for common variables like regions, resource group names and common tags.
1
2
3
4
5
6
7
8
9
10
variables:
- name: region
description: The IBM Cloud region where the instance should be provisioned
value: xxx
- name: resource_group_name
description: The name of the IBM Cloud resource group where the resources should be provisioned
value: xxx
- name: common_tags
description: The list of tags that should be applied to all resources (does not work)
value: []
To define the values of variables for certain modules, naming conventions are used. For example to define the value of ‘runtime_image‘ …
1
2
3
4
variable "runtime_image" {
description = "runtime_image"
default = "watson-nlp-runtime:1.0.15"
}
… the name of the module is used followed by ‘_’ and the variable name.
1
2
- name: terraform_gitops_watson_nlp_runtime_image
value: watson-nlp-runtime:1.0.18
To find out more about these capabilities, check out the following resources: