Collect feedback on a potential migration of CustomersDot to Runway
In order to support CustomersDot infrastructure scalability, a potential solution would be to use the existing Runway. Please see full details on this on https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1207+
This is a feedback issue to collect minimum requirements for this transition, which should include things related to deployments, notifications, number of VMs, web server configuration and rate limits, etc...
Requirements
- Continuous Deployment to Staging and Production
- Similar 3-hour delay on deployments after passing E2E QA tests as explained here: https://gitlab.com/gitlab-org/customers-gitlab-com#deployments
- Ability to use a production blocker label to block deployment as well as a Staging health-check previous to allow/deny Production deploys
- Slack notifications on deployment (successes and failures)
- Replicate or reuse the existing Staging and Staging-ref CustomersDot environments with the same deployment cadence
- Whitelist capabilities for all nodes (replicate current Zuora IP setup, etc...)
- Replicate current PostgreSQL backup configuration
- Replicate NGinx configuration with the same rate limits: https://gitlab.com/gitlab-org/customersdot-ansible/-/blob/master/roles/nginx/README.md
- Replicate the Capistrano-like deployment keeping the old applications around for an easier revert (as well as provide a revert mechanism that we have within the Ansible project)
- 3-4 VMs in Production
- External services
-
Google Storage for ActiveStorage support
- This is used for storing license usage files sent by customers. More info here.
- GitLab.com
- CDot is integrated with GitLab.com in both directions, both pushing and fetching data from the GitLab API, as well as GitLab pushing and fetching data from the CDot API.
- CDot also uses GitLab as an Omniauth provider.
- Zuora
- Production -
rest.zuora.com
- Stg -
rest.test.zuora.com
- Production -
- Salesforce
- Production -
gitlab.my.salesforce.com
- Stg -
gitlab--staging.sandbox.my.salesforce.com
- Production -
- Mailgun
- Prometheus
- Monitoring system used by CDot to capture metrics. There are dedicated Prometheus instances for each CDot environment. More info here.
- Snowplow
- Tracking system feeding data for Sisense data visualizations. More info on how it is used and which dashboards are available.
- Sentry
- Application performance and error monitoring tool used by CDot frontend and backend. More info can be found in these links.
- Okta
- Okta is used as an OAuth provider for authenticating Admins using the CDot Admin panel.
- Configuration
- Redis
- The store used by Sidekiq, Prometheus, and CDot maintenance mode.
- User sessions are stored there as well.
- Slack
- The project has code to post notifications to Slack for various things like CI failures.
- Unleash
- CDot utilizes the Unleash feature toggle system using an instance hosted on GL.com. More info.
- Visual Compliance
- CDot uses the Visual Compliance service (
https://rps.visualcompliance.com
) to screen customers company, country, and state for purchasing subscription via an e-marketplace. Code can be found here.
- CDot uses the Visual Compliance service (
- Security and Compliance logs ingested into GCP buckets - there is a service that sends the Rails logs regularly
-
Google Storage for ActiveStorage support
Edited by Vitaly Slobodin