GitHub Actions on GitHub Enterprise Server is a powerful tool for CI/CD automation, but it requires careful planning, resource allocation, and configuration. This guide will walk you through every step — from hardware requirements to storage integration and access control — to ensure a smooth and efficient setup.
Understanding the Foundation: Hardware and Performance
Before diving into the world of GitHub Actions, it’s crucial to understand the minimum and recommended hardware requirements for GitHub Enterprise Server. These are not just arbitrary numbers; they are based on internal testing and real-world usage scenarios.
GitHub Enterprise Server requires a minimum of 8 vCPU and 64 GB memory to support GitHub Actions. However, the maximum number of connected runners you can configure without performance degradation varies depending on the amount of resources you allocate. For example:
- 8 vCPU / 64 GB Memory: Supports up to 740 connected runners
- 32 vCPU / 160 GB Memory: Supports up to 2700 connected runners
- 96 vCPU / 384 GB Memory: Supports up to 7000 connected runners
These metrics are derived from tests involving multiple repositories, job durations of about 10 minutes, and 10 MB artifact uploads. Keep in mind that these are baseline numbers and actual performance may vary depending on the overall activity level on your instance.
The Concept of Connected Runners vs. Concurrent Jobs
Starting from GitHub Enterprise Server 3.6, the documentation now refers to connected runners instead of concurrent jobs. This shift in terminology is significant because it reflects a more accurate understanding of how GitHub Actions operates in large-scale environments.
A connected runner is the maximum number of runners you can connect and expect to utilize simultaneously. If you connect more runners than you plan to use, it could lead to performance issues. This is because the system may not be able to handle the load efficiently, especially if the runners are idle or not properly utilized.
This change also aligns with GitHub’s internal testing that began using 3rd generation CPUs from GitHub Enterprise Server 3.5. These newer processors better represent the typical customer configuration, and this adjustment has contributed to more accurate performance targets.
Choosing the Right Storage Provider
GitHub Actions on GitHub Enterprise Server requires external blob storage for storing workflow logs, caches, and user-uploaded artifacts. While the system itself stores workflow files on the local data storage volume, external storage is essential for scalability and performance.
GitHub officially supports the following storage providers:
- Azure Blob storage
- Amazon S3
- Google Cloud Storage
- S3-compatible MinIO cluster
These are the only storage products GitHub can provide support and assistance for. However, there are other S3 API-compatible products that have been self-validated by GitHub partners. These include various cloud storage solutions and on-premise storage systems that are compatible with S3 API standards.
For storage products that are part of the GitHub Technology Partnership program, the storage provider is responsible for support and documentation related to their integration with GitHub Actions. This means that while GitHub may not offer direct support, the partner will provide the necessary guides and assistance.
Enabling GitHub Actions with Your Storage Provider
Enabling GitHub Actions with your chosen storage provider is a multi-step process. You need to follow the specific procedures for each supported provider. For example:
- Azure Blob storage requires setting up a storage account and configuring access keys.
- Amazon S3 involves creating a bucket and specifying the region, as well as setting up IAM roles and policies.
- Google Cloud Storage involves enabling the service, creating a bucket, and setting up access credentials.
- MinIO cluster requires deploying the cluster, configuring it to be S3 API-compatible, and setting up bucket policies and access controls.
Each provider has its own setup and configuration requirements, but the overall workflow is similar. You’ll need to configure the storage system, set up access permissions, and validate the setup to ensure that it works seamlessly with GitHub Actions.
Managing Access Permissions
Access management is a critical aspect of implementing GitHub Actions in your enterprise. You can use policies to control which users and repositories have access to GitHub Actions.
GitHub provides a policy enforcement framework that allows you to define rules and restrictions for GitHub Actions. These policies can be applied at the enterprise, organization, or repository levels. For instance, you can set up GitHub Connect to allow automatic access to actions from GitHub.com, or manually sync actions from GitHub.com into your enterprise.
This approach ensures that only authorized actions and workflows are executed, enhancing security and control within your organization. It also helps in preventing unauthorized access and misuse of resources.
Adding Self-Hosted Runners
Self-hosted runners are a key component of GitHub Actions on GitHub Enterprise Server. Unlike GitHub-hosted runners, which are not supported, self-hosted runners offer greater control and flexibility.
You can add self-hosted runners at the enterprise, organization, or repository levels. This allows you to scale your CI/CD pipelines based on your needs and the activity level of your projects.
To add a self-hosted runner, you need to register the machine with your GitHub Enterprise Server instance, install the runner software, and configure it to run workflows. This process is well-documented, and you can find detailed instructions in the Adding self-hosted runners section of the GitHub Enterprise Server documentation.
Controlling Which Actions Can Be Used
You have the ability to control which actions your users are allowed to use in your enterprise. This is essential for maintaining security and ensuring that only approved and trusted actions are executed.
You can set up GitHub Connect to automatically sync actions from GitHub.com into your enterprise, or manually sync actions by importing them directly. This gives you a centralized management of actions, allowing you to audit and approve them before they are used in your workflows.
This level of control ensures that your CI/CD pipelines are secure, compliant, and efficient. It also helps in preventing the use of deprecated or insecure actions, which is particularly important in enterprise environments.
Securing GitHub Actions
Security is a top priority when implementing GitHub Actions on GitHub Enterprise Server. The Secure use reference provides a comprehensive guide on best practices for hardening your GitHub Actions setup.
Some of the key security considerations include:
- Using strong passwords and SSH keys for all runners and actions
- Limiting access to sensitive data through encryption and secure storage
- Monitoring and auditing all actions and workflows for security compliance
- Setting up rate limits to prevent abuse or overload of the system
By following these best practices, you can ensure that your GitHub Actions implementation is secure and reliable. This is especially important for enterprise environments where data security and compliance are of utmost importance.
Reserved Names and Their Implications
When you enable GitHub Actions for your enterprise, two reserved organizations are automatically created: github and actions. These names are used for internal purposes and cannot be used for other organizations within your enterprise.
If your enterprise already uses the github organization name, GitHub will automatically use github-org (or github-github-org if that name is already in use). Similarly, if you already use the actions organization name, GitHub will create github-actions (or github-actions-org if that name is in use).
This naming convention is important to remember, as it reserves certain names for GitHub Actions and prevents conflicts. It also ensures that your enterprise's naming structure remains consistent and conflict-free.
Conclusion
Implementing GitHub Actions on GitHub Enterprise Server is a multi-step process that requires careful planning and execution. From hardware requirements to storage configuration, access management, and security hardening, each step plays a crucial role in ensuring a smooth and efficient setup.
By following the guidelines and best practices outlined in this guide, you can ensure that your GitHub Actions implementation is secure, scalable, and reliable. This will help you maximize the benefits of GitHub Actions while minimizing the risks associated with its use.
关键字列表：GitHub Actions, GitHub Enterprise Server, self-hosted runners, external blob storage, vCPU, memory, connected runners, security, workflow logs, caches, artifact uploads, rate limits, storage providers