GitHub has gone through a largescale migration of the infrastructure that runs github.com and api.github.com sites.
The site decided to transform so that all web and API requests are now served by containers running in Kubernetes clusters that are deployed in its metal cloud.
GitHub said that it gradually evolved the infrastructure that runs the Rub on Rails application responsible for the sites, including moving critical applications to Kubernetes.
Prior to the move, the main Ruby on Rails application was said to be configured “a lot like it was eight years ago,” with Unicorn processes managed by a Ruby process manager called God running on Puppet-managed servers, GitHub said in a blog post.
GitHub before Kubernetes
The site’s chatops deployment also worked as it had when first introduced, meaning that Capistrano established SSH connections to each frontend server before the code was updated in place and restarted the process. The knock-on effect of this was that when peak request load exceeded the available frontend CPU capacity, the site’s reliability engineers would provision additional capacity.
Due to the growing size of the sites, new problems appeared. Services increased and the SRE team had to support similar configurations for “dozens of other applications,” clearly increasing the amount of time that was spent on provisioning, server maintenance and various other work that all distracts from improving the site experiences for users.
Read more: How the tech industry is making containers enterprise ready
The problems faced meant that change was needed, so the SRE, Platform, and Developer Experience teams began working together to evaluate a container orchestration platform, resulting in github.com and api.github.com being run on Kubernetes clusters.
Content from our partners
The site said it chose the container technology for its “vibrant open source community,” the “first run experience,” and a “wealth of information available about the experience that motivated its design.”
“Our experience with this project as well as the feedback from engineers who used it was overwhelmingly positive. It was time to expand our experiments, so we started planning a larger rollout,” said GitHub.
While many businesses go through an infrastructure migration, not all would take the approach of starting with critical workloads. The GitHub team however, decided that it would, due to the deep knowledge of the application throughout the Git repository would be useful, it needed self-service capacity expansion to handle growth, it wanted to make sure that habits and patterns developed would be suitable for both large and smaller services, it also wanted to better insulate the app from differences between development, staging, production, enterprise, and other environments, and GitHub also felt that a high-profile workload migration would encourage further adoption of the technology at GitHub.
GitHub after Kubernetes
Far from diving in head first, the site needed to make sure that the container technology would work well so it built a pre-production environment called “review-lab.”
Read more: Containers debunked: DevOps, security and why containers will not replace virtual machines
GitHub’s migration to the container technology was viewed as a challenge, but a positive outcome was achieved and more migrations are planned: “We’re inspired by our experience migrating this application to Kubernetes, and are looking forward to migrating more soon. While scope of our first migration was intentionally limited to stateless workloads, we’re excited about experimenting with patterns for running stateful services on Kubernetes.”
The whole view on the migration and GitHub’s story can be found here.
