MinIO Object Storage for GitHub Enterprise

MinIO Object Storage for GitHub Enterprise

Developer generation of unstructured data is a main driver of storage needs. Artifacts, built with GitHub Actions and Packages, have data growth driven by multiple releases a day for multiple environments, generating more growth faster than other types of data.

GitHub Enterprise Overview


At the heart of this data generation is GitHub Enterprise. GitHub Enterprise’s success is based on the fact that it allows developers to use the tools they are comfortable with across the entire development process. This includes popular IDEs and CI/CD tools, and is organized around Actions and Packages.

  • GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipelines. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.
  • GitHub Packages is a platform for hosting and managing packages, including containers and other dependencies. GitHub Packages combines your source code and packages in one place to provide integrated permissions management and billing, so you can centralize your software development on GitHub.


Together, they produce data at a tremendous rate in an enterprise environment and demand sophisticated storage and retrieval capabilities.

Two Pieces of the Same Puzzle

All of this data requires a sophisticated, cloud-native storage system. That system is ideally S3 compatible, performant, seamlessly scalable to hundreds of PBs, software-defined, multi-cloud, secure and resilient.

In other words, GitHub Enterprise requires MinIO.

Let’s run through the requirements quickly:

  • S3 Compatible — Developers use RESTful APIs today. That is what S3 is — RESTful. The S3 API for object storage is the de facto standard. MinIO is the most widely deployed alternative to Amazon S3 and has nearly a billion Docker pulls to prove it. There is no S3 compatible object store that is run in more architectures, across more types of hardware, and against more use cases than MinIO. That is why it “just works” for hundreds of thousands of applications.
  • Performant — MinIO is the world’s fastest object store with GET/PUT speeds in excess of 325 GB/s and 165 GB/s respectively. Storage and retrieval is fast — no matter what the object size. All of MinIO’s benchmarks are published — feel free to check them out here.
  • Seamlessly scalable — MinIO scales through a concept called server pools that is designed for hardware heterogeneity. GitHub Enterprise instances are fast growing, get really large and are long-lived. MinIO is well suited for these use cases.
  • Software defined — GitHub Enterprise is a software defined solution. It makes sense that it would pair up with software defined storage like MinIO. Better economics, better performance tuning, better operational management — better everything really when you go software defined.
  • Multi-cloud — GitHub Enterprise runs everywhere; its storage solution needs to as well. MinIO runs on every public cloud, private cloud, and at the edge (a keen area of interest for the team at GitHub). Where they are, we are.
  • Secure — GitHub Enterprise is responsible for the enterprise’s most important software assets so it requires storage that takes security as seriously as it does. MinIO’s encryption schemes support granular object-level encryption using modern, industry-standard encryption algorithms, such as AES-256-GCM, ChaCha20-Poly1305, and AES-CBC. MinIO is fully compatible with S3 encryption semantics, and also extends S3 by including support for non-AWS key management services such as Hashicorp Vault, Gemalto KeySecure, and Google Secrets Manager. MinIO remains highly performant when encryption is turned on.
  • Integrated — MinIO supports the use of external key-management-systems (KMS). If a client requests SSE-S3, or auto-encryption is enabled, the MinIO server encrypts each object with an unique object key which is protected by a master key managed by the KMS.
  • Resilient — Protecting data goes beyond encryption. Immutability is at the heart of the object storage framework and MinIO supports a complete object locking / retention framework offering both Legal Hold and Retention (with Governance and Compliance modes). MinIO’s Object Locking functionality has been validated by Cohasset Partners.

In addition, MinIO has some critical capabilities that matter to GitHub Enterprise.

  • MinIO supports both synchronous and asynchronous replication. If the link goes down between the two clusters, then even synchronous replication temporarily reverts to asynchronous replication, automatically. MinIO provides mechanisms for managing centralized updates and upgrades. Lifecycle management is part of the cluster console and policies are managed centrally. This allows architects to design a system that can withstand the failure of a complete cloud. This is meaningful because wIth a two cluster HA setup with replication enabled along with a load balancer, if a cluster completely fails, GitHub will continue to function by sending all the requests to the other cluster. That means no downtime for developers.
  • Cluster level identity management is performed with AD/LDAP or OpenID Single Sign On (SSO). The user and users belonging to a group are limited with policy-based access controls that dictate actions that can be taken on particular resources. Policy authoring is enabled on the console and admins can create policies for users, groups and service accounts. The centralized management of clusters, pools, policies and buckets is easily managed.
  • Management is simple and the joint solution can be automated with technologies like Ansible. Managing both MinIO and GitHub together  — whether bare metal or Kubernetes — is a clear plus.

Integrated Deployment Overview

As we can see, MinIO is a perfect ally to GitHub Enterprise, where the output of GitHub Packages and Actions can be stored on high-performance, S3 API compatible object storage.

It made absolute sense for us to go ahead and establish partnerships between MinIO and GitHub Enterprise and test/validate regularly as we release new software. The combined solution provides secure and compliant software for on premises, private clouds for enterprise infrastructure or on public cloud providers with seamless S3 compatible API, and provides portability.

The combined deployment enables smarter collaboration between developers/engineers across the enterprise and simpler administration for enterprise operators. It gives the ability to scale the storage horizontally as the need for development — and engineering artifacts and devops capabilities — continuously grows.

Integrating GitHub Enterprise with MinIO

In the next phase, we’ll go over how to set up the required infrastructure for integrating GitHub Enterprise packages and actions to use MinIO as a backend. At a high level we’ll need running instances of MinIO and GitHub Enterprise.

MinIO

Install and Configure

There are a number of ways we can set up MinIO to run, in this scenario we’ll use Docker to launch MinIO.

Create 4 directories on your local host where the Docker container will be running:

mkdir -p /home/aj/minio-<id>/disk-1 \
mkdir -p /home/aj/minio-<id>/disk-2 \
mkdir -p /home/aj/minio-<id>/disk-3 \
mkdir -p /home/aj/minio-<id>/disk-4

Once the directories are created, launch the docker container:

docker run -d \
  -p 9000:9000 \
  -p 9001:9001 \
  -v /home/aj/minio-1/disk-1:/mnt/disk1 \
  -v /home/aj/minio-1/disk-2:/mnt/disk2 \
  -v /home/aj/minio-1/disk-3:/mnt/disk3 \
  -v /home/aj/minio-1/disk-4:/mnt/disk4 \
  --name minio1 \
  --hostname minio1 \
  quay.io/minio/minio server http://minio1/mnt/disk{1...4}/minio --console-address ":9001"

The above command will do the following:

  1. Launch a docker container with the name minio.
  2. Mount the 4 host directories onto the container to store MinIO data.
  3. Exposes API 9000 and Console 9001 ports on the host so other services can access it.

Verify that the MinIO service has come up, in the logs you should see something similar to this:

Status:         4 Online, 0 Offline.
API: http://172.20.0.2:9000  http://127.0.0.1:9000

Console: http://172.20.0.2:9001 http://127.0.0.1:9001

Documentation: https://docs.min.io

Note the above setup is for you to quickly get up and running with MinIO. You can expand from a single node to a multi-node distributed configuration for additional testing. If you would like to deploy and configure MinIO  in a production environment, please refer to the documentation.

Create Bucket

Now that MinIO is deployed, we need to create a bucket in MinIO Console for GitHub Enterprise to store its packages.

  1. In a browser, go to http://localhost:9000 to access the MinIO Console.

2. Login with default credentials:

  • User: minioadmin
  • Pass: minioadmin

3. Go to Buckets -> [click] Create Bucket

4. Create a bucket named testbucket123.

Remember the credentials and bucket name for later. We need them to configure the GitHub Enterprise packages feature.

GitHub Enterprise

Download the latest release of GitHub Enterprise and launch it on your favorite hypervisor. While there isn't a specific section in the GitHub Enterprise interface to configure MinIO, we don’t need one. MinIO is fully compatible with the S3 API, so we can simply use the existing AWS S3 configuration section to configure it.

Configuring Packages

  • Log in to your GitHub Enterprise admin account through the browser.
  • On the upper right-hand corner click the Rocket icon.
  • Go to Site Admin > Management > Packages.
  • Click Enable GitHub Packages.
  • Under Packages Storage
    • Select Amazon S3
    • AWS Service URL: MinIO server API address http://<minio_host_IP>:9000
    • AWS S3 Bucket: MinIO bucket we created using the console testbucket123
    • AWS S3 Access Key: MinIO Username minioadmin
    • AWS S3 Secret Key: MinIO Password minioadmin
  • Click Save Settings on the left and wait for GitHub Enterprise to be reconfigured with the new settings.

Configuring Actions

  • On the upper right-hand corner click the Rocket icon.
  • Go to Site Admin > Management > Actions.
  • Click on the checkbox Enable GitHub Actions.
  • Under Artifact and Log Storage
    • Select Amazon S3
    • AWS Service URL: MinIO server API address http://<minio_host_IP>:9000
    • AWS S3 Bucket: MinIO bucket from console testbucket123
    • AWS S3 Access Key: MinIO Username minioadmin
    • AWS S3 Secret Key: MinIO Password minioadmin
  • Click Save Settings on the left and wait for GitHub Enterprise to reconfigure with the new settings.

Scalable, Secure and Performant Storage for GitHub Enterprise

That’s it! You’ve configured GitHub Enterprise to use  MinIO as the backend for packages and actions. Should you require additional information, here are further details on how to configure  packages and actions.

Got questions? Join us on Slack. Want to get started? Head over to the downloads page.

Previous Post Next Post