Infrastructure/arc
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

gitlab operations/infra related userstories

Browse source 
Signed-off-by: David Kirwan <davidkirwanirl@gmail.com>
This commit is contained in:
David Kirwan 2024-10-14 13:02:33 +01:00
parent b1aa1ba086
commit 4f4930d523
No known key found for this signature in database
GPG key ID: A5893AB6474AC37D
2 changed files with 61 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

31
docs/dist-git-comparison/gitlab.rst
View file

@ -526,3 +526,34 @@ Following is the investigation on GitLab based on the user stories collected.
80. **As a Fedora Badges junkie, I want to be able to receive badges for activities related to dist-git. In technical terms, the dist-git activities must be broadcast to the Fedora Message Bus (or however it's called nowadays).**
Please check the answer to the user story #51.
81. **Scalability - As a SaaS administrator, I want the system architecture to support scalability, manually or automatically based on demand, so that we can maintain optimal performance during traffic spikes and efficiently handle user growth.**
Gitlab provides reference architectures which you can use when determining what level of users and interactions we require a deployment to be able to service comfortably. This is best done prior to installation as it is potentially not easy to change after the fact. If we choose to deploy gitlab within a cloud provider such as AWS we can take advantage of auto scaling features. See the reference architectures here:
https://docs.gitlab.com/ee/administration/reference_architectures/5k_users.html
82. **Reliability and High Availability - User Story: As a SaaS administrator, I want the service architecture to be highly available, to ensure 24/7 operation with minimal downtime, so that end users may access and use the application whenever needed without interruptions.**
Gitlab architecture offers the ability to run in a highly available fashion. Ensure a suitable configuration is deployed at installation time. It is not easily changed later. See the reference architecture here: https://docs.gitlab.com/ee/administration/reference_architectures/5k_users.html there are a number of maintenance tasks which must be carried out regularly to maintain the instance see: https://docs.gitlab.com/ee/administration/operations/
83. **Security - User Story: As a SaaS administrator, I want robust security measures implemented across our infrastructure, including encryption, access controls, and regular security audits, so that we can protect our end users data and maintain their trust.**
Gitlab has robust security features, if installed, configured and maintained correctly, the system can be secure enough for our needs in a self managed installation. We need to ensure that we follow the best practices during the installation phase. https://docs.gitlab.com/ee/security/ for notes related to security breech see https://docs.gitlab.com/ee/security/responding_to_security_incidents.html and for recomendations to hardening the installation https://docs.gitlab.com/ee/security/hardening.html
84. **Security - User Story: As a SaaS administrator, I want to quickly identify when the system is affected by CVEs, so that steps can be taken to plan upgrades to mitigate vulnerabilities.**
Gitlab notifies when the system is affected by known CVEs, popups suggesting the system be updated show to administrators on logging into the system. See information about patching and maintenance with regards to upgrading and mitigating vulnerabilities https://docs.gitlab.com/ee/policy/maintenance.html
85. **Monitoring and Observability - User Story: As a SaaS administrator, I want a centralised monitoring and logging system that provides real-time insights into application performance, resource utilisation, and user experience, so that we can quickly identify and resolve issues before they impact users.**
Gitlab has integrations with prometheus and grafana to provide monitoring. See https://docs.gitlab.com/ee/administration/monitoring/ This can be scraped by Zabbix later as we move towards using Zabbix as the main monitoring system within Fedora Infra.
86. **Infrastructure as Code (IaC) - User Story: As a SaaS administrator, I want to manage our the system infrastructure using code that we can version control, easily replicate environments, and automate provisioning and configuration.**
Configuration will be possible to keep under source control. Depending on the method of installation we choose, there are Linux packages, Helm, Docker, Operator, source, or scripts. It will likely require that we develop configurations to add custom functionality such as integrations with FAS. https://docs.gitlab.com/ee/install/
87. **Multi-tenancy - User Story: As a SaaS administrator, I want the application to be a secure multi-tenant system that efficiently shares resources among end users while ensuring complete data isolation, so that we can serve multiple clients cost-effectively without compromising security.**
By default, Gitlab is configured for multi-tenancy. The reference architectures detail the requirements to guarantee a service level capable of supporting the desired number of users.
88. **Disaster Recovery and Backup - User Story: As a SaaS administrator, I want automated backup systems and a comprehensive disaster recovery plan in place, so that we can quickly recover from any unforeseen events and minimise data loss and downtime.**
The process for backing up and restoration of Gitlab instances is well documented see: https://docs.gitlab.com/ee/administration/backup_restore/index.html and restoring see https://docs.gitlab.com/ee/administration/backup_restore/restore_gitlab.html
89. **Upgradability - User Story: As a SaaS administrator, I want to apply automated system upgrades, preferrably without causing system downtime, so we can continue to provide service to end users.**
Gitlab can be upgraded, but not automated, and probably not without downtime or degraded performace. See the guide depending on the installation method we go with: https://docs.gitlab.com/ee/update/?tab=Helm+chart+%28Kubernetes%29#upgrade-based-on-installation-method
90. **Upgradability - User Story: As a SaaS administrator, I want to safely apply database schema upgrades without causing outages or data loss.**
The Gitlab system can be upgraded safely, but not automatically, see the upgrade guide for more information depending on the method of installation we choose https://docs.gitlab.com/ee/update/?tab=Helm+chart+%28Kubernetes%29#upgrade-based-on-installation-method and migrations also likely required to be carried out see https://docs.gitlab.com/ee/update/background_migrations.html

30
docs/dist-git-comparison/stories.rst
View file

@ -247,3 +247,33 @@ Following is the investigation on GitLab based on the user stories collected.
80. **As a Fedora Badges junkie, I want to be able to receive badges for activities related to dist-git. In technical terms, the dist-git activities must be broadcast to the Fedora Message Bus (or however it's called nowadays).**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-931576>`_ by **Miro Hroncok** (``churchyard``)
81. **Scalability - As a SaaS administrator, I want the system architecture to support scalability, manually or automatically based on demand, so that we can maintain optimal performance during traffic spikes and efficiently handle user growth.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935315>`_ by **David Kirwan** (``dkirwan``)
82. ** Reliability and High Availability - User Story: As a SaaS administrator, I want the service architecture to be highly available, to ensure 24/7 operation with minimal downtime, so that end users may access and use the application whenever needed without interruptions.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935316>`_ by **David Kirwan** (``dkirwan``)
83. **Security - User Story: As a SaaS administrator, I want robust security measures implemented across our infrastructure, including encryption, access controls, and regular security audits, so that we can protect our end users data and maintain their trust.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935317>`_ by **David Kirwan** (``dkirwan``)
84. **Security - User Story: As a SaaS administrator, I want to quickly identify when the system is affected by CVEs, so that steps can be taken to plan upgrades to mitigate vulnerabilities.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935317>`_ by **David Kirwan** (``dkirwan``)
85. **Monitoring and Observability - User Story: As a SaaS administrator, I want a centralised monitoring and logging system that provides real-time insights into application performance, resource utilisation, and user experience, so that we can quickly identify and resolve issues before they impact users.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935318>`_ by **David Kirwan** (``dkirwan``)
86. **Infrastructure as Code (IaC) - User Story: As a SaaS administrator, I want to manage our the system infrastructure using code that we can version control, easily replicate environments, and automate provisioning and configuration.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935320>`_ by **David Kirwan** (``dkirwan``)
87. **Multi-tenancy - User Story: As a SaaS administrator, I want the application to be a secure multi-tenant system that efficiently shares resources among end users while ensuring complete data isolation, so that we can serve multiple clients cost-effectively without compromising security.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935322>`_ by **David Kirwan** (``dkirwan``)
88. **Disaster Recovery and Backup - User Story: As a SaaS administrator, I want automated backup systems and a comprehensive disaster recovery plan in place, so that we can quickly recover from any unforeseen events and minimise data loss and downtime.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935323>`_ by **David Kirwan** (``dkirwan``)
89. **Upgradability - User Story: As a SaaS administrator, I want to apply automated system upgrades, preferrably without causing system downtime, so we can continue to provide service to end users.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935325>`_ by **David Kirwan** (``dkirwan``)
90. **Upgradability - User Story: As a SaaS administrator, I want to safely apply database schema upgrades without causing outages or data loss.**
`Reported <https://pagure.io/fedora-infra/arc/issue/164#comment-935325>`_ by **David Kirwan** (``dkirwan``)