Handling of Versions of TechZone Toolkit Modules
source link: http://heidloff.net/article/versioning-of-techzone-accelerator-toolkit-modules/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Handling of Versions of TechZone Toolkit Modules
With the TechZone Accelerator Toolkit IBM software, open source projects and custom applications can easily be deployed to various clouds. This article explains how to ensure that the right versions of modules are deployed.
In an earlier blog I introduced the toolkit: Introducing IBM’s Toolkit to handle Everything as Code. The toolkit leverages Terrafrom and GitOps and is based on best practices based on IBM experiences in partner and clients projects.
Solutions are defined via bill of materials (BOM) 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.
apiVersion: cloudnativetoolkit.dev/v1alpha1kind: BillOfMaterialmetadata:name: cluster-with-watson-nlpspec:modules:- name: ibm-ocp-vpc- name: argocd-bootstrap- name: gitops-repoalias: gitops_repo- name: terraform-gitops-ubialias: terraform_gitops_ubi- name: terraform-gitops-watson-nlpalias: terraform_gitops_watson_nlp |
If you don’t provide any version numbers in the BOMs, the toolkit installs the latest versions.
Modules can have dependencies which are defined in the module.yaml files.
dependencies:- id: gitopsrefs:- source: github.com/cloud-native-toolkit/terraform-tools-gitops.gitversion: '>= 1.1.0'- id: namespacerefs:- source: github.com/cloud-native-toolkit/terraform-gitops-namespace.gitversion: '>= 1.0.0' - id: setup_clisrefs:- source: github.com/cloud-native-toolkit/terraform-util-clis.gitversion: '>= 1.0.0' |
As in other frameworks and programming languages like JavaScript, Java, Go, etc. the best practise is to require certain versions of dependencies. Automatic updates of modules can easily break production applications. Before updating dependencies, testing needs to be done. The only exception might be security fixes, but even those need to be tested.
Let’s take a look how this can be done with the TechZone Accelerator Toolkit. After you have run ‘iascable build …’ on BOM files which only include high level modules without version numbers like above, you will find a second BOM file (shadow BOM) in the subdirectory ‘output/bom-name/bom.yaml’.
These shadow BOM files contain not only the high level modules, but a complete list of all modules including dependencies. They also include the latest version numbers.
apiVersion: cloudnativetoolkit.dev/v1alpha1kind: BillOfMaterialmetadata:name: cluster-with-watson-nlpspec:modules:- name: gitops-repoalias: gitops_repoversion: v1.22.2- name: argocd-bootstrapalias: argocd-bootstrapversion: v1.12.0- name: ibm-ocp-vpcalias: clusterversion: v1.16.3- name: ibm-vpcalias: ibm-vpcversion: v1.17.0- name: ibm-vpc-gatewaysalias: ibm-vpc-gatewaysversion: v1.10.0- name: terraform-gitops-ubialias: terraform_gitops_ubiversion: v0.0.26- name: terraform-gitops-watson-nlpalias: terraform_gitops_watson_nlpversion: v1.0.0- name: olmversion: v1.3.5- name: sealed-secret-certversion: v1.0.1- name: ibm-resource-groupalias: resource_groupversion: v3.3.5- name: ibm-object-storagealias: cosversion: v4.1.0- name: ibm-vpc-subnetsversion: v1.14.0- name: gitops-namespacealias: namespaceversion: v1.14.0- name: util-clisversion: v1.18.1 |
To ‘pin’ the version numbers of modules for subsequent Terraform runs, a best practise is to replace the original BOM file with the generated shadow BOM file. This approach is similar to JavaScript’s package-lock.json files and Golang’s go.sum files.
To find out more about these capabilities, check out the following resources:
Share this:
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK