aztfmod / rovergo Goto Github PK

Rover v1 was ONLY usable inside a devcontainer

Rover v2 should also support running from a devcontainer

• Dockfiler which includes rover binary and other tools
• devcontainer defintion

Unit tests are the wild new craze taking the software development world by storm.

We should get on this new hotness and some of these so called "unit tests" to rover v2

To be agreed:

• Can we really unit test without azure/backend changes?
• Where to focus the tests?

Currently only launchpad run works for deploying and destroying in launchpad mode. Also for CD the level must be launchpad: true.

Landingzone mode is a simple extension (most if not all of existing code in pkg/landingzone applies) however the required vars need to be set and state handled differently. etc

This should bring us to close to an usable but 'alpha' version

Task #21 makes up a large part (possibly all, pending investigation) of this effort

Current CI command reads both symphony YAML and also YAML in ci_tasks directory, each of these YAMLs defines a task that can be run in CI mode

These files will need to be parsed, and will form the core of the ci command implementation. Once the file is passed it takes the extra params from symphony YAML (e.g. working directory, path to vars, level etc) and executes the task by dropping down to the shell

For terraform commands I think tf-exec should be used rather shell

This task is just for parsing the YAML

Building the task runner is in task xxxx

When I tried this command with an incorrect -c parameter, the command tried to run anyway, gave incorrect results.

rover lp destroy -c $HOME/caf_config -s $HOME/git/caf-terraform-landingzones -l level0

I left off /demo/level0 from the -c parameter.

Take the existing 'CAF sample application' from here https://github.com/aztfmod/symphony/tree/master/caf
In case changes are required I propose making a copy into rovergo repo

Try to deploy it! First the launchpad and then the various levels etc

Investigate the code flow

I think the only difference for launchpad mode is it calls initialize_state (confusing function name as it's ONLY used by launchpad) which calls init without a backend, then after calls upload_tfstate

Suggestion we use a $HOME/.rover for everything we can

• TF_DATA_DIR
• rover config file
• tmp stuff
• tfstate & plan storage
• ci_tasks folder
• tfstates folder (currently in $HOME)
• Also logs e.g. $HOME/.rover/logs/
• Place command history here e.g. $HOME/.rover/hist.txt

This epic tracks the overall effort to rewrite and reimplement rover in Go.

The motivations for doing this are to replace the bash code with a more robust, easy to maintain code base and improve the user experience at the command line.

🧊 Repo

📅 View Task Board

✅ View Task/Issue List

Makes sense this is not a top level command as it's rarely used, and it only applies to landingzones so more intuative it goes here

Secrets will need to be fetched, as part of #21

• Investigate Go options, SDK
• How we will authenticate
• Ensure authentication works along side current Terraform and Azure API auth
• Create wrapper / helper package to get secrets specifically for rover use case

Placeholder to not forget this needs working on

• Handle multiple clouds, does az login do all we need?
• Handle split of subscription for state and deployment (maybe already ok)
• Tenancy issues?

The ci_tasks folder must be statically located, i.e. always in the same place, so having a flag for its location makes no sense.

Task #35 is a pre-req for this one.

This goes hand in hand with the work for #12

Considerations

• init state locally
• placement of local state and plan files
• implement TF plan and apply commands for MVP
• upload state to blob when done

integration testing may use terratest, but in general the pattern is:

• create some resources using rovergo
• validate them somehow
• tear them down
• emit pass/fail stats

terraform plan, validate

Both landingzone and launchpad commands will need to call TF plan and apply, hopefully they can share the same code and design

The current behaviour is:

• Only ./custom_actions is looked for
• if custom_actions directory is not found a warning is output

Issues:

• Should look for custom_actions in the .rover directory?
• Should we initialize this with some samples/examples/standard configs?

Specifically the extraction of TF_VAR_tfstate_storage_account_name etc vars from the keyvault

https://github.com/aztfmod/rover/blob/1113d610f00c2bc5b2d80d970e66052acd1d5ed3/scripts/functions.sh#L266

This is a broad tasks and might require breaking up, further investigation is required

Rover v1 supports a way to list all deployed landingzones for some reason 🤷‍♂️

Rather than supply /foo/bar/caf_launchpad or /foo/bar/caf_solution to the lp and lz commands, accept a source flag but change it to be just the "root" of the landingzone source directory, no need to add caf_launchpad or caf_solution as we know what one we want from the "mode" (lp or lz)

Get a list of all Azure CLI commands the current rover tool executes.

This will then feed into a list of tasks here - to implement corresponding calls using the Azure APIs and Go SDK, and shape a package containing those calls in a way they can be used but other parts of rovergo, e.g. wrappers and helpers

I see there being a mix of

• ARM API calls
• KeyVault data plane API calls
• Storage data plane API calls
• Others?

It would improve test-ability if there was some output to examine along with an error object.

For example:

{
 "command": "lp",
 "subCommand": "init",
 "outcome": "success"
}

• landing zone
• launchpad
• level
• environments
• configuration

I tried it a couple of ways:

rover cd destroy
rover lp destroy -c $HOME/caf_config/demo/level0 -s $HOME/git/caf-terraform-landingzones -l level0

This may be due to the fact that I changed some things in caf_config. As follows:

resource_groups = {
level0 = {
name = "lp-l0"
tags = {
level = "level0"
}
} ... etc

Currently all output is done via pkg/console.go which supports the following message levels, the levels are mapped to colours

• Error - red text
• Warning - yellow text
• Info - blue text
• Success - green text
• Debug - magenta text

The only one of these which is controllable is debug, which will only be output if the global --debug flag is passed to rover

We could replace --debug with a --log-level flag and map that level to the existing 5 levels or do we want to step back and examine logging & output in more depth

Thoughts / ideas:

• Switch to a logger like https://github.com/sirupsen/logrus or https://github.com/uber-go/zap
  • This will probably give us log file and stdout support
  • Also a more structured set of levels
  • Note. Zap seems heavily focused on performance, which is not important

This issue is to discuss & provide feedback on the proposal for Rover v2, which is hosted on the wiki for easier editing

📝 Rover v2 Draft Proposal

Note. This is a "living document" and constantly evolving

This is a legacy of an earlier phase in the project, it was created automatically for us as part of running the cobra new command when the project was initialised.

• It's only used in two place, neither are very important:
  • terraform.go control to how and where to try to install terraform, we could drop support for this auto install, it's falling into the "trying to be too clever" camp. If terraform is not found simply exit
  • landingzone fetch command, the tmp directory - we can just use ioutil.TempDir

Removing this has one big advantage we can replace the lengthy --symphony-config flag with simply --config.
It's also one less config file, and artefact for the user to keep track of

runCITaskSubCommand in ci.go

Not really any reason we shouldn't check for these as rover starts, the user isn't going to be able to get very far without either of these

• check for existence in path (there's a func in command.go)
• put out helpful error message with download/install links

Current working draft is on the wiki

📝 Symphony v2 Draft Proposal

As there is no way to comment on wiki pages, discussion and feedback should be done here, on this issue

• Local state and plan files are always placed in ${TF_DATA_DIR}/tfstates/${TF_VAR_level}/${TF_VAR_workspace}/${TF_VAR_tf_name}
• Note TF_VAR_workspace is set to "tfstate" unless the user passes --workspace to set it
• Note the Rover devcontainer sets TF_DATA_DIR to $HOME/.terraform.cache
• For normal landing zone deployments terraform init is called with -backend-config so it uses remote state. The storage account to use is found using the environment tags and the level
• Launchpad deployment is a special case where state is created locally and then uploaded to blob, this takes a different path through the rover code
• the -tfstate parameter to rover sets the state key that is used, i.e. the blob name

We need to authenticate in order to call Terraform - however this has been solved see current implementation login.go, azure.go and terraform.go

HOWEVER we also need to call the Azure APIs via the Go SDK, we need to understand how this can be unified and done without

• supports service principal auth
• also drops down to Azure CLI just as Terraform does

• Implement task runner for the CI tasks as defined in issue #15
• Will need to run from symphony.yaml so parser will need to be complete #14
• Using the existing tf-exec code in terraform.go and command.go implementation should be relatively easy

1. Add well-known cloud endpoints/dns names to an internal list
2. Implement those details in the code:
   a. key vault
   b. storage

end goal - no hard coded endpoints / dns names other than in the internal list in #1 above

Function in functions.sh of rover v1

Checks role with
role=$(az role assignment list --role "${1}" --assignee ${TF_VAR_logged_user_objectId} --include-inherited --include-groups)

This should be done as part of runLaunchpadInit (probably)

This is run for LAUNCHPAD ONLY*

Opening this issue to discuss the proposed changes here:
https://github.com/aztfmod/rovergo/wiki/Symphony-v2---Draft-Proposal

Add stubs with cobra add foo and cobra add bar --parent foo

Output of task #4 drives this and is a pre-req
This design is probably not final but adding these stubs gives a good sense for what it will look and feel like, and what work is remaining

Commands required:

• landingzone list
• launchpad
• ci
• cd
• workspace
• terraform

Because this is run inside an init() function it means rover won't run if ci_tasks is missing, even if the command you are running is NOT rover ci

CD should be the focus now, i.e. the entry point should be some form of rover cd --config=foo command to carry out landing zones and launchpad operations, these can then be internally "ported" over to launchpad and landingzone commands and the settings which are in symphony YAML.

The internal implementation, namely the terraform actions, interaction with state etc will remain the same regardless.

This task is to get stub functionality for CD working, reading symphony YAML, looping over it or locating a level or stack in the YAML and outputing simple log messages for now

Then we can follow up with deeper implementation

#14 is a pre-req

• rover cd always requires a symphony.yaml config file as input
• Do we need to modify the existing symphony YAML schema? (investigation)

Rover can switch the identity it runs terraform under by fetching details from a keyvault

I don't think this affects any other calls to Azure e.g. the az commands and therefor any calls we make to the API with the SDK

See https://github.com/aztfmod/rover/blob/1113d610f00c2bc5b2d80d970e66052acd1d5ed3/scripts/functions.sh#L299

• update the docs
• write a user guide

Initial work for CI and CD, we need to work off the symphony.yaml file

• Parsing the file
• Go data structure

If az account show reveals that the user is a managed identity:

"user": { "assignedIdentityInfo": "MSI", "name": "systemAssignedIdentity", "type": "servicePrincipal" }

use the Azure Instance Metadata Service to get the vm's name and resource group name. feed those into az vm identity show (the REST equivalent) to get the principalId.

This principalId is (we think) the same as the object-id acquired by az ad signed-in-user show. Which is required for various api calls in rovergo.

Add capability to run any ad hoc CI command, such as tflint, etc. i.e. one that requires an executable in the environment (whether devcontainer, pipeline agent, etc). spec of the command is in a ci_tasks folder yaml file.

Also, refactor CI commands similar to CD - as methods on the symphony struct object.

This task is to refactor the current action verbs to meet the current Rover v2 spec

This involves moving the action from a command flag, to sub commands, one per action. This will result in many new sub-commands but should result in a logical structure. These sub-commands will all follow the same flow, the difference being the landingzone.Action they pass into the Execute()

The current semantics of rover v2 maps actions to terraform verbs almost 1:1, the exception being the action deploy which is a synonym for running terraform plan + terraform apply

I think switching back to the action named apply (which actually does a terraform plan + terraform apply) is best for now and will prevent confusion. However I'd welcome input and comments

See https://github.com/aztfmod/caflint

It's written in Go, so...

• It could either be referenced from rover as an external package
• Wholly subsumed into the rovergo codebase with the entry point being a cobra command rather than the existing main.go

This would either be a new top level command e.g. rover caflint or an value for the action flag of landingzone run