客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
开源软件名称（OpenSource Name）：actions-runner-controller/actions-runner-controller开源软件地址(OpenSource Url)：https://github.com/actions-runner-controller/actions-runner-controller开源编程语言(OpenSource Language)：Go 89.4%开源软件介绍(OpenSource Introduction)：actions-runner-controller (ARC)
This controller operates self-hosted runners for GitHub Actions on your Kubernetes cluster. ToC:
People
If you think the project is awesome and it's becoming a basis for your important business, consider sponsoring us! In case you are already the employer of one of contributors, sponsoring via GitHub Sponsors might not be an option. Just support them in other means! We don't currently have any sponsors dedicated to this project yet. However, HelloFresh has recently started sponsoring @mumoshu for this project along with his other works. A part of their sponsorship will enable @mumoshu to add an E2E test to keep ARC even more reliable on AWS. Thank you for your sponsorship!
StatusEven though actions-runner-controller is used in production environments, it is still in its early stage of development, hence versioned 0.x. actions-runner-controller complies to Semantic Versioning 2.0.0 in which v0.x means that there could be backward-incompatible changes for every release. The documentation is kept inline with master@HEAD, we do our best to highlight any features that require a specific ARC version or higher however this is not always easily done due to there being many moving parts. Additionally, we actively do not retain compatibly with every GitHub Enterprise Server version nor every Kubernetes version so you will need to ensure you stay current within a reasonable timespan. AboutGitHub Actions is a very useful tool for automating development. GitHub Actions jobs are run in the cloud by default, but you may want to run your jobs in your environment. Self-hosted runner can be used for such use cases, but requires the provisioning and configuration of a virtual machine instance. Instead if you already have a Kubernetes cluster, it makes more sense to run the self-hosted runner on top of it. actions-runner-controller makes that possible. Just create a Runner resource on your Kubernetes, and it will run and operate the self-hosted runner for the specified repository. Combined with Kubernetes RBAC, you can also build simple Self-hosted runners as a Service. InstallationBy default, actions-runner-controller uses cert-manager for certificate management of Admission Webhook. Make sure you have already installed cert-manager before you install. The installation instructions for the cert-manager can be found below. After installing cert-manager, install the custom resource definitions and actions-runner-controller with Kubectl Deployment: # REPLACE "v0.22.0" with the version you wish to deploy
kubectl apply -f https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.22.0/actions-runner-controller.yamlHelm Deployment: Configure your values.yaml, see the chart's README for the values documentation helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller
helm upgrade --install --namespace actions-runner-system --create-namespace \
--wait actions-runner-controller actions-runner-controller/actions-runner-controllerGitHub Enterprise SupportThe solution supports both GHEC (GitHub Enterprise Cloud) and GHES (GitHub Enterprise Server) editions as well as regular GitHub. Both PAT (personal access token) and GitHub App authentication works for installations that will be deploying either repository level and / or organization level runners. If you need to deploy enterprise level runners then you are restricted to PAT based authentication as GitHub doesn't support GitHub App based authentication for enterprise runners currently. If you are deploying this solution into a GHES environment then you will need to be running version >= 3.3.0. When deploying the solution for a GHES environment you need to provide an additional environment variable as part of the controller deployment: kubectl set env deploy controller-manager -c manager GITHUB_ENTERPRISE_URL=<GHEC/S URL> --namespace actions-runner-systemNote: The repository maintainers do not have an enterprise environment (cloud or server). Support for the enterprise specific feature set is community driven and on a best effort basis. PRs from the community are welcome to add features and maintain support. Setting Up Authentication with GitHub APIThere are two ways for actions-runner-controller to authenticate with the GitHub API (only 1 can be configured at a time however):
Functionality wise, there isn't much of a difference between the 2 authentication methods. The primary benefit of authenticating via a GitHub App is an increased API quota. If you are deploying the solution for a GHES environment you are able to configure your rate limit settings making the main benefit irrelevant. If you're deploying the solution for a GHEC or regular GitHub environment and you run into rate limit issues, consider deploying the solution using the GitHub App authentication method instead. Deploying Using GitHub App AuthenticationYou can create a GitHub App for either your user account or any organization, below are the app permissions required for each supported type of runner: Note: Links are provided further down to create an app for your logged in user account or an organization with the permissions for all runner types set in each link's query string Required Permissions for Repository Runners:
Required Permissions for Organization Runners:
Organization Permissions
Note: All API routes mapped to their permissions can be found here if you wish to review Subscribe to events At this point you have a choice of configuring a webhook, a webhook is needed if you are going to use webhook driven scaling. The webhook can be configured centrally in the GitHub app itself or separately. In either case the event details are:
Setup Steps If you want to create a GitHub App for your account, open the following link to the creation page, enter any unique name in the "GitHub App name" field, and hit the "Create GitHub App" button at the bottom of the page. If you want to create a GitHub App for your organization, replace the You will see an App ID on the page of the GitHub App you created as follows, the value of this App ID will be used later.
Download the private key file by pushing the "Generate a private key" button at the bottom of the GitHub App page. This file will also be used later.
Go to the "Install App" tab on the left side of the page and install the GitHub App that you created for your account or organization.
When the installation is complete, you will be taken to a URL in one of the following formats, the last number of the URL will be used as the Installation ID later (For example, if the URL ends in
Finally, register the App ID ( Kubectl Deployment: $ kubectl create secret generic controller-manager \
-n actions-runner-system \
--from-literal=github_app_id=${APP_ID} \
--from-literal=github_app_installation_id=${INSTALLATION_ID} \
--from-file=github_app_private_key=${PRIVATE_KEY_FILE_PATH}Helm Deployment: Configure your values.yaml, see the chart's README for deploying the secret via Helm Deploying Using PAT AuthenticationPersonal Access Tokens can be used to register a self-hosted runner by actions-runner-controller. Log-in to a GitHub account that has Required Scopes for Repository Runners
Required Scopes for Organization Runners
Required Scopes for Enterprise Runners
Note: When you deploy enterprise runners they will get access to organizations, however, access to the repositories themselves is NOT allowed by default. Each GitHub organization must allow enterprise runner groups to be used in repositories as an initial one-time configuration step, this only needs to be done once after which it is permanent for that runner group. Note: GitHub does not document exactly what permissions you get with each PAT scope beyond a vague description. The best documentation they provide on the topic can be found here if you wish to review. The docs target OAuth apps and so are incomplete and may not be 100% accurate. Once you have created the appropriate token, deploy it as a secret to your Kubernetes cluster that you are going to deploy the solution on: Kubectl Deployment: kubectl create secret generic controller-manager \
-n actions-runner-system \
--from-literal=github_token=${GITHUB_TOKEN}Helm Deployment: Configure your values.yaml, see the chart's README for deploying the secret via Helm Deploying Multiple Controllers
Note: Be aware when using this feature that CRDs are cluster-wide and so you should upgrade all of your controllers (and your CRDs) at the same time if you are doing an upgrade. Do not mix and match CRD versions with different controller versions. Doing so risks out of control scaling. By default the controller will look for runners in all namespaces, the watch namespace feature allows you to restrict the controller to monitoring a single namespace. This then lets you deploy multiple controllers in a single cluster. You may want to do this either because you wish to scale beyond the API rate limit of a single PAT / GitHub App configuration or you wish to support multiple GitHub organizations with runners installed at the organization level in a single cluster. This feature is configured via the controller's You can deploy multiple controllers either in a single shared namespace, or in a unique namespace per controller. If you plan on installing all instances of the controller stack into a single namespace there are a few things you need to do for this to work.
Alternatively, you can install each controller stack into a unique namespace (relative to other controller stacks in the cluster). Implementing ARC this way avoids the first, second and third pitfalls (you still need to set the corresponding namespace selector for each stack's mutating webhook) UsageGitHub self-hosted runners can be deployed at various levels in a management hierarchy:
There are two ways to use this controller:
Repository RunnersTo launch a single self-hosted runner, you need to create a manifest file that includes a # runner.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: Runner
metadata:
name: example-runner
spec:
repository: example/myrepo
env: []Apply the created manifest file to your Kubernetes. $ kubectl apply -f runner.yaml
runner.actions.summerwind.dev/example-runner createdYou can see that the Runner resource has been created. $ kubectl get runners
NAME REPOSITORY STATUS
example-runner actions-runner-controller/actions-runner-controller RunningYou can also see that the runner pod has been running. $ kubectl get pods
NAME READY STATUS RESTARTS AGE
example-runner 2/2 Running 0 1mThe runner you created has been registered to your repository.
Now you can use your self-hosted runner. See the official documentation on how to run a job with it. Organization RunnersTo add the runner to an organization, you only need to replace the # runner.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: Runner
metadata:
name: example-org-runner
spec:
organization: your-organization-nameNow you can see the runner on the organization level (if you have organization owner permissions). Enterprise RunnersTo add the runner to an enterprise, you only need to replace the # runner.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: Runner
metadata:
name: example-enterprise-runner
spec:
enterprise: your-enterprise-nameNow you can see the runner on the enterprise level (if you have enterprise access permissions). RunnerDeploymentsYou can manage sets of runners instead of individually through the There are You typically only need # runnerdeployment.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
name: example-runnerdeploy
spec:
replicas: 2
template:
spec:
repository: mumoshu/actions-runner-controller-ci
env: []Apply the manifest file to your cluster: $ kubectl apply -f runnerdeployment.yaml
runnerdeployment.actions.summerwind.dev/example-runnerdeploy createdYou can see that 2 runners have been created as specified by $ kubectl get runners
NAME REPOSITORY STATUS
example-runnerdeploy2475h595fr mumoshu/actions-runner-controller-ci Running
example-runnerdeploy2475ht2qbr mumoshu/actions-runner-controller-ci RunningRunnerSets
Ensure you see the limitations before using this kind!!!!! For scenarios where you require the advantages of a A basic apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerSet
metadata:
name: example
spec:
ephemeral: false
replicas: 2
repository: mumoshu/actions-runner-controller-ci
# Other mandatory fields from StatefulSet
selector:
matchLabels:
app: example
serviceName: example
template:
metadata:
labels:
app: exampleAs it is based on Runner-related fields like Fields like Pod-related fields like security contexts and volumes are written under Similarly, container-related fields like resource requests and limits, container image names and tags, security context, and so on are written under For a more complex example, see the below: apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerSet
metadata:
name: example
spec:
ephemeral: false
replicas: 2
repository: mumoshu/actions-runner-controller-ci
dockerdWithinRunnerContainer: true
template:
spec:
securityContext:
# All level/role/type/user values will vary based on your SELinux policies.
# See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/docker_selinux_security_policy for information about SELinux with containers
seLinuxOptions:
level: "s0"
role: "system_r"
type: "super_t"
user: "system_u"
containers:
- name: runner
env: []
resources:
limits:
cpu: "4.0"
memory: "8Gi"
requests:
cpu: "2.0"
memory: "4Gi"
# This is an advanced configuration. Don't touch it unless you know what you're doing.
securityContext:
# Usually, the runner container's privileged field is derived from dockerdWithinRunnerContainer.
# But in the case where you need to run privileged job steps even if you don't use docker/don't need dockerd within the runner container,
# just specified `privileged: true` like this.
# See https://github.com/actions-runner-controller/actions-runner-controller/issues/1282
# Do note that specifying `privileged: false` while using dind is very likely to fail, even if you use some vm-based container runtimes
# like firecracker and kata. Basically they run containers within dedicated micro vms and so
# it's more like you can use `privileged: true` safer with those runtimes.
#
# privileged: true
- name: docker
resources:
limits:
cpu: "4.0"
memory: "8Gi"
requests:
cpu: "2.0"
memory: "4Gi"You can also read the design and usage documentation written in the original pull request that introduced Under the hood, Limitations
Persistent RunnersEvery runner managed by ARC is "ephemeral" by default. The life of an ephemeral runner managed by ARC looks like this- ARC creates a runner pod for the runner. As it's an ephemeral runner, the
Once the ephemeral runner has completed running a workflow job, it stops with a status code of 0, hence the runner pod is marked as completed, removed by ARC. As it's removed after a workflow job run, the runner pod is never reused across multiple GitHub Actions workflow jobs, providing you a clean environment per each workflow job. Although not generally recommended, it's possible to disable the passing of the Persistent runners are available as an option for some edge cases however they are not preferred as they can create challenges around providing a deterministic and secure environment. Autoscaling
A Important!!! If you opt to configure autoscaling, ensure you remove the Anti-Flapping ConfigurationFor both pull driven or webhook driven scaling an anti-flapping implementation is included, by default a runner won't be scaled down within 10 minutes of it having been scaled up. This anti-flap configuration also has the final say on if a runner can be scaled down or not regardless of the chosen scaling method. This delay is configurable via 2 methods:
Below is a complete basic example of one of the pull driven scaling metrics. apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
name: example-runner-deployment
spec:
template:
spec:
repository: example/myrepo
---
apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:
name: example-runner-deployment-autoscaler
spec:
# Runners in the targeted RunnerDeployment won't be scaled down
# for 5 minutes instead of the default 10 minutes now
scaleDownDelaySecondsAfterScaleOut: 300
scaleTargetRef:
name: example-runner-deployment
# Uncomment the below in case the target is not RunnerDeployment but RunnerSet
#kind: RunnerSet
minReplicas: 1
maxReplicas: 5
metrics:
- type: PercentageRunnersBusy
scaleUpThreshold: '0.75'
scaleDownThreshold: '0.25'
|
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
六六分期app的软件客服如何联系？不知道吗？加qq群【895510560】即可！标题：六六分期
今天小编告诉大家如何处理win10系统火狐flash插件总是崩溃的问题，可能很多用户都不知
今天小编告诉大家如何对win10系统删除桌面回收站图标进行设置，可能很多用户都不知道
今天小编告诉大家如何对win10系统电脑设置节能降温的设置方法，想必大家都遇到过需要
我们在使用xp系统的过程中,经常需要对xp系统无线网络安装向导设置进行设置，可能很多
今天小编告诉大家如何处理win7系统玩cf老是与主机连接不稳定的问题，可能很多用户都不
电脑对日常生活的重要性小编就不多说了，可是一旦碰到win7系统设置cf烟雾头的问题，很
我们在日常使用电脑的时候，有的小伙伴们可能在打开应用的时候会遇见提示应用程序无法
今天小编告诉大家如何对win7系统打开vcf文件进行设置，可能很多用户都不知道怎么对win
今天小编告诉大家如何对win10系统s4开启USB调试模式进行设置，可能很多用户都不知道怎
请发表评论