Support external management of runner config
Background
With how the module is currently structured, it owns the entire lifecycle of the runner. When the EC2 machine starts, it registers the runner. When the machine shuts down, it de-registers the runner (which looks like we could run into situations where you stop a machine and then, when it's started back up, can't do anything because it's no longer configured and registration occurs on first startup). But, EC2 instances are known to occasionally have issues and need to be restarted. In the case that a runner is to be shared, we would want the configuration to remain stable, even if the runner is launching on a new machine. That way, projects that have opted to use the shared runner don't have to be reconfigured to use a newly registered runner.
Proposal
I'd like to support the ability for the configuration to be externalized and imported into the machine at startup. Supported mechanisms might be AWS Secrets Manager or Vault (I think we can start with AWS Secrets Manager as it's a known path and would be easier to get started, then add Vault support later). Since configuration is then being externally managed, the module will no longer maintain the lifecycle.
Specifically, we'd need to do the following things:
- Introduce a new variable, possibly
gitlab_runner_config_aws_secret_name
to serve as the secret name containing the config - Update the user-data template generation to handle when the variable is both set and not set
- When not set, perform register/shutdown tasks that are being done currently
- When set, skip register/shutdown and pull the config from the configured secret and drop it so the runner can access it
- If the variable is set, add a policy to the IAM role used by the runner to have secret access
Thoughts? I'll gladly do the work, but figured I'd bounce the idea around before putting time into it.