How to use GitHub to build containerized services on GitHub
GitHub’s Developer Experience Engineering team is committed to creating secure, comfortable, and comprehensive solutions that enable GitHub engineers to code, ship, and operate software efficiently, and build software using GitHub. Showing the world an example of how. To achieve this, we provide developers with a paved path. This is a comprehensive suite of automated tools and applications to streamline runtime platforms, deployment, and hosting that help power select microservices and many internal tools on the GitHub.com platform. Let’s take a closer look at how one of the major pavements works.
Our Development Ecosystem
GitHub’s main paved path covers everything you need to run your software, including creating, deploying, scaling, debugging, and running your application. It’s an ecosystem of tools like Kubernetes, Docker, load balancers, and many custom apps that work together to create a consistent experience for engineers. It’s not just infrastructure, it’s not just Kubernetes. Kubernetes is our base layer, and the paved path is a combination of conventions, tools, and configurations built on top of it.
Services that typically run using the paved path include web apps, compute pipelines, batch processors, and monitoring systems.
Kubernetes is the base layer of the paved path, running in multi-cluster, multi-region topologies.
Advantages of paved roads
GitHub has hundreds of services, from small internal tools to external APIs supporting production workloads. For various reasons, starting a virtual machine for each service is inefficient.
- Capacity usage planning and capacity usage across all services is not efficient. Continuously managing both physical and Kubernetes infrastructure creates a lot of overhead.
- Teams have to build deep expertise to manage their own Kubernetes clusters and have less time to focus on application-specific needs.
- Reduces centralized visibility of applications.
- Standardizing and enforcing security and compliance is difficult.
A paved path based on Kubernetes and other runtime apps instead allows you to:
- By centrally planning capacity for Kubernetes nodes only, small and large workloads coexist on the same machine, making optimal use of capacity across nodes.
- Scale quickly with centralized capacity planning.
- Easily manage the configuration and deployment of your entire service with one central control plane.
- Consistently provide insight into app and deployment performance of individual services.
Service onboarding
Onboarding services with code that resides in your own repository is now easier with the ChatOps Command Service. Hubot, the GitHub app. A service owner can easily generate the basic scaffolding required to deploy a service by running a command like the following:
hubot gh-platform app scaffold monalisa-app
A custom GitHub app installed in the service’s GitHub repository automatically generates a pull request that adds the required configuration, such as:
- a
deployment.yamlA file that defines the deployment environment for a service. - A Kubernetes manifest that defines the
DeploymentandServiceAn object for deploying services. - Debian Dockerfile to run a simple web server first. Used by Kubernetes manifests.
- When you set your CI build as a GitHub check, every push builds a Docker image and stores it in your container registry ready for deployment.
Each service onboarded to the paved path has its own Kubernetes namespace defined as follows: <app-name>-<environment> And it usually has a staging environment and a production environment. This helps separate the workloads of multiple services. It also helps isolate multiple environments of the same service, as each environment gets its own Kubernetes namespace.
Service deployment
On GitHub, deploy branches and run deployments through the Hubot ChatOps command.To deploy a branch named bug-fixes in the monalisa-app the repository staging In this environment, developers run ChatOps commands such as:
hubot deploy monalisa-app/bug-fixes to staging
This will trigger a deployment that picks up the Docker image associated with the latest commit. bug-fixes Create branches, update Kubernetes manifests, and apply those manifests to clusters in the runtime platform relevant to that environment.
Docker images are typically deployed to multiple Kubernetes clusters across multiple geographic sites within a region that form part of the runtime platform.
To automate the merging of pull requests into your busiest branches, as well as coordinate rollouts across your environment Merge queue and deployment pipelineour engineers can observe and interact with this during deployment.
Ensure service security
The security of the platform itself and the services running within it is important to any company. In addition to practices throughout engineering, such as requiring all pull his requests to be reviewed by two of her, we also have security and platform teams that automate security measures such as:
- A pre-built Docker image that is used as the base image for your Dockerfile. These base images contain only the required packages/dependencies, including security updates, and contain an auditable and curated set of pre-installed software for shared needs.
- Leverage our product to scan all packages and running container images at build time and on a regular basis for vulnerabilities and dependencies that need to be patched. Software supply chain security Like a dependerbot.
- Scan the service’s GitHub repositories for exposed secrets and vulnerabilities at build time and regularly using GitHub’s native security features for advanced security, including: Code scan and secret scan.
- Multiple authentication and authorization mechanisms to ensure only relevant individuals have direct access to underlying Kubernetes resources.
- Comprehensive telemetry for threat detection.
- Services running on the platform are by default only accessible within GitHub’s internal network and are not exposed to the public internet.
- A branch protection policy applies to all production repositories. These policies prevent the merging of pull-her requests until the specified automated tests have passed and the changes have been reviewed by a developer other than the one who proposed the changes.
Another important aspect of application security is how secrets such as keys and tokens are managed. GitHub uses a centralized secret store to manage secrets. Each service and each environment within a service has its own vault for storing secrets. These secrets are injected into the relevant pods in Kubernetes and exposed to the container.
Deployment flow from merge to rollout
The entire deployment process looks like this:
- A GitHub engineer merges the pull request into a branch within the repository. In the example above,
bug-fixesbranch ofmonalisa-apprepository. This repository also contains a Kubernetes manifest template file for deploying your application. - Merging a pull request triggers the associated CI workflow. One of them is building a Docker image. It builds a container image based on the Dockerfile specified in the repository and pushes the image to the internal artifact registry.
- After all CI workflows have completed successfully, the engineer initiates the deployment by running a ChatOps command such as:
hubot deploy monalisa-app/bug-fixes to staging. This will trigger deployments to environments such as:Staging. - The build system fetches the Kubernetes manifest file from the repository branch, replaces the latest deployed image from the artifact registry, injects app secrets from the secret store, and performs some custom operations. At the end of this stage, you will have a ready-to-deploy Kubernetes manifest available.
- The deployment system then applies the Kubernetes manifests to relevant clusters and monitors the rollout status of new changes.
Conclusion
GitHub’s internal paved path allows GitHub developers to focus less on infrastructure and more on building services and delivering value to users. We do this by giving his GitHub engineers a streamlined path to harnessing the power of containers and Kubernetes. Scalable security, authentication and authorization mechanisms. And the GitHub.com platform itself.
Want to try some of these for yourself? Learn more about all of GitHub’s features here. github.com/features. If you adopt our practices in your own development, we would love to hear from you. twitter!
https://github.blog/2023-08-02-how-we-build-containerized-services-at-github-using-github/ How to use GitHub to build containerized services on GitHub
