After fully configuring our values.yaml file, we need to kick off the deployment of kubernetes manifests to the cluster. After double-checking the kubectl context, we want to execute the scopearctl apply command as follows:
scopearctl k8s apply -f /path/to/values.yaml
Detailed Script Steps:
Defaulting: The tool sets default values for any configuration item that is left unset in your environment manifest.
Validation: The tool checks if the values are set in your ScopeAR environment manifest. If errors exist, it will return them all and exit the process.
YAML Manifest Generation: Scopearctl programmatically injects the single configuration file into multiple K8s assets and outputs them to a local directory, default ./__gen__ .
Apply Generated Manifests to Cluster: If the –dry flag is not set and the user has the appropriate cluster context authorization, the tool will apply the generated manifest similarly to how kubectl apply—f would.
Example Usage Scenarios
Here are a handful of example usage scenarios to help you better understand the different use cases:
Apply the configs set in your values.yaml:
scopearctl k8s apply -f /path/to/scopear-manifest.yaml
Only generate yaml manifests:
scopearctl k8s apply -f /path/to/scopear-manifest.yaml --dry
Set a custom kubeconfig file:
scopearctl k8s apply -f /path/to/scopear-manifest.yaml --kubeconfig /path/to/custom-config
Handling Multiple Environments
It is best practice to create a configuration file per environment/namespace and use a logical file naming scheme to easily differentiate between configs. For example, if we have a dev and staging environment, name your values.yaml files ‘scopear-staging. yaml’ and ‘scopear-dev.yaml’. It is also advisable to create an archive of all the different versions of scopearctl if you need to roll back to a previous version.