## Overview In this phase, the [HTTP router](https://gitlab.com/gitlab-org/cells/http-router) service will be deployed in front of the existing GitLab.com load balancer. This router will only have a single rule which will be a passthrough proxy. This derisks the HTTP router deployment for later phases.  [source](https://gitlab.com/gitlab-com/content-sites/handbook/-/blob/3a44f6a79ca4097328cf391853a9e5384537a138/content/handbook/engineering/infrastructure/cells/_index.md) The **order of issue execution** of these issues can be found in https://cells-architecture-overview-gitlab-org-tenant-sc-ff1c641f886923.gitlab.io/phase-1-4/#groups_Phase_2 you should see all the issues in this epic. ## Exit Criteria - [x] 100% of API traffic goes through router using passthrough proxy rule. - [x] 100% of Web traffic goes through router using passthrough proxy rule. - [x] 100% of Git HTTPS traffic goes through router using passthrough proxy rule. - [x] Requests meet [latency target](https://docs.gitlab.com/ee/architecture/blueprints/cells/http_routing_service.html#low-latency) - [x] registry.gitlab.com not proxied. Neither is kas.gitlab.com ## DRI @sxuereb ### Participants - @f_santos - @bmarjanovic - @manojmj - @OmarQunsulGitlab - @tkuah - @AndyWH - @jcstephenson - @tkhandelwal3 ## Boards The issues boards below should help you identify the next steps and issues to pick up. Always go from top to bottom, meaning first pick from `phase 2.2` and select the top most issue. - [Phase 2.2](https://gitlab.com/groups/gitlab-org/-/boards/7739216?epic_id=2241030) - [Phase 2.3](https://gitlab.com/groups/gitlab-org/-/boards/7739216?epic_id=2241037) - [Phase 2.4](https://gitlab.com/groups/gitlab-org/-/boards/7739216?epic_id=2241028) <!-- STATUS NOTE START --> ## Status 2024-11-25 Phase 2 is done, and we can close this Epic :tada: :tada: We can find a demo of what we achieved at https://youtu.be/Ct6WOS8uN7U Original Problem: We needed to provision and deploy a new service (HTTP Router) in front of every request to GitLab.com, in its simplest form to introduce the least amount of complexity and latency and to validate that the HTTP Router is the right choice. What we did: - [General Availability](https://gitlab.com/gitlab-com/gl-infra/readiness/-/tree/master/http-router?ref_type=heads) of a new service on a brand new compute platform (Cloudflare Workers) for GitLab.com - Wrote a new service from scratch using Typescript. - Continues Delivery on HTTP Router, when we merge to `main` it's running in production in less than 1 hour for a quick feedback loop. - Deployments are gradually rolled out, so after some time to gradually increase traffic of a new version. - One-click rollback functionality for HTTP Router - Observability for Cloudflare Workers and E2E with Pingdom inside of Mimir Impact: - Building blocks for other phases to start routing requests to other Cells. - No visible latency increase for the end user (p99 at 15ms increase) @nhxnguyen @glopezfernandez @mjwood this ready to be closed _Copied from https://gitlab.com/groups/gitlab-org/-/epics/12775#note_2225714938_ <!-- STATUS NOTE END -->