有主见的、独立的Terraform根模块，每个模块解决一个特定问题_HCL_Shell_下载.zip

# Component: `actions-runner-controller` This component creates a Helm release for [actions-runner-controller](https://github.com/actions-runner-controller/actions-runner-controller) on an EKS cluster. ## Usage **Stack Level**: Regional Once the catalog file is created, the file can be imported as follows. ```yaml import: - catalog/eks/actions-runner-controller ... ``` The default catalog values `e.g. stacks/catalog/eks/actions-runner-controller.yaml` ```yaml components: terraform: eks/actions-runner-controller: vars: enabled: true name: "actions-runner" # avoids hitting name length limit on IAM role chart: "actions-runner-controller" chart_repository: "https://actions-runner-controller.github.io/actions-runner-controller" chart_version: "0.22.0" kubernetes_namespace: "actions-runner-system" create_namespace: true kubeconfig_exec_auth_api_version: "client.authentication.k8s.io/v1beta1" # helm_manifest_experiment_enabled feature causes inconsistent final plans with charts that have CRDs # see https://github.com/hashicorp/terraform-provider-helm/issues/711#issuecomment-836192991 helm_manifest_experiment_enabled: false ssm_github_secret_path: "/github_runners/controller_github_app_secret" github_app_id: "REPLACE_ME_GH_APP_ID" github_app_installation_id: "REPLACE_ME_GH_INSTALLATION_ID" # ssm_github_webhook_secret_token_path: "/github_runners/github_webhook_secret_token" # The webhook based autoscaler is much more efficient than the polling based autoscaler webhook: enabled: true hostname_template: "gha-webhook.%[3]v.%[2]v.%[1]v.acme.com" eks_component_name: "eks/cluster" resources: limits: cpu: 500m memory: 256Mi requests: cpu: 250m memory: 128Mi runners: infra-runner: node_selector: kubernetes.io/os: "linux" kubernetes.io/arch: "amd64" type: "repository" # can be either 'organization' or 'repository' dind_enabled: false # If `true`, a Docker sidecar container will be deployed # To run Docker in Docker (dind), change image to summerwind/actions-runner-dind # If not running Docker, change image to summerwind/actions-runner use a smaller image image: summerwind/actions-runner-dind # `scope` is org name for Organization runners, repo name for Repository runners scope: "org/infra" min_replicas: 1 max_replicas: 20 scale_down_delay_seconds: 100 resources: limits: cpu: 200m memory: 512Mi requests: cpu: 100m memory: 128Mi webhook_driven_scaling_enabled: true webhook_startup_timeout: "30m" pull_driven_scaling_enabled: false # Labels are not case-sensitive to GitHub, but *are* case-sensitive # to the webhook based autoscaler, which requires exact matches # between the `runs-on:` label in the workflow and the runner labels. labels: - "Linux" - "linux" - "Ubuntu" - "ubuntu" - "X64" - "x64" - "x86_64" - "amd64" - "AMD64" - "core-auto" - "common" # Uncomment this additional runner if you want to run a second # runner pool for `arm64` architecture #infra-runner-arm64: # node_selector: # kubernetes.io/os: "linux" # kubernetes.io/arch: "arm64" # # Add the corresponding taint to the Kubernetes nodes running `arm64` architecture # # to prevent Kubernetes pods without node selectors from being scheduled on them. # tolerations: # - key: "kubernetes.io/arch" # operator: "Equal" # value: "arm64" # effect: "NoSchedule" # type: "repository" # can be either 'organization' or 'repository' # dind_enabled: false # If `true`, a Docker sidecar container will be deployed # # To run Docker in Docker (dind), change image to summerwind/actions-runner-dind # # If not running Docker, change image to summerwind/actions-runner use a smaller image # image: summerwind/actions-runner-dind # # `scope` is org name for Organization runners, repo name for Repository runners # scope: "org/infra" # group: "ArmRunners" # min_replicas: 1 # max_replicas: 20 # scale_down_delay_seconds: 100 # resources: # limits: # cpu: 200m # memory: 512Mi # requests: # cpu: 100m # memory: 128Mi # webhook_driven_scaling_enabled: true # webhook_startup_timeout: "30m" # pull_driven_scaling_enabled: false # # Labels are not case-sensitive to GitHub, but *are* case-sensitive # # to the webhook based autoscaler, which requires exact matches # # between the `runs-on:` label in the workflow and the runner labels. # # Leave "common" off the list so that "common" jobs are always # # scheduled on the amd64 runners. This is because the webhook # # based autoscaler will not scale a runner pool if the # # `runs-on:` labels in the workflow match more than one pool. # labels: # - "Linux" # - "linux" # - "Ubuntu" # - "ubuntu" # - "amd64" # - "AMD64" # - "core-auto" ``` ### Generating Required Secrets AWS SSM is used to store and retrieve secrets. Decide on the SSM path for the GitHub secret (PAT or Application private key) and GitHub webhook secret. Since the secret is automatically scoped by AWS to the account and region where the secret is stored, we recommend the secret be stored at `/github_runners/controller_github_app_secret` unless you plan on running multiple instances of the controller. If you plan on running multiple instances of the controller, and want to give them different access (otherwise they could share the same secret), then you can add a path component to the SSM path. For example `/github_runners/cicd/controller_github_app_secret`. ``` ssm_github_secret_path: "/github_runners/controller_github_app_secret" ``` The preferred way to authenticate is by _creating_ and _installing_ a GitHub App. This is the recommended approach as it allows for more much more restricted access than using a personal access token, at least until [fine-grained personal access token permissions](https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/) are generally available. Follow the instructions [here](https://github.com/actions-runner-controller/actions-runner-controller/blob/master/docs/detailed-docs.md#deploying-using-github-app-authentication) to create and install the GitHub App. At the creation stage, you will be asked to generate a private key. This is the private key that will be used to authenticate the Action Runner Controller. Download the file and store the contents in SSM using the following command, adjusting the profile and file name. The profile should be the `admin` role in the account to which you are deploying the runner controller. The file name should be the name of the private key file you downloaded. ``` AWS_PROFILE=acme-mgmt-use2-auto-admin chamber write github_runners controller_github_app_secret -- "$(cat APP_NAME.DATE.private-key.pem)" ``` You can verify the file was correctly written to SSM by matching the private key fingerpri