From e0ad2c52ee6fab2dbfe4faf0651238dbf30c3a59 Mon Sep 17 00:00:00 2001 From: Aleksei Lipniagov Date: Mon, 17 May 2021 19:11:17 +0300 Subject: [PATCH] Remove Unicorn support: docs Updates docs related to Unicorn support removal. --- README.md | 4 ++-- doc/administration/database_load_balancing.md | 22 ------------------- .../geo/replication/geo_validation_tests.md | 4 ++-- .../geo/replication/multiple_servers.md | 3 --- doc/administration/gitaly/configure_gitaly.md | 2 +- doc/administration/gitaly/index.md | 1 - doc/administration/logs.md | 2 +- .../monitoring/prometheus/index.md | 2 +- doc/administration/nfs.md | 4 ++-- .../operations/fast_ssh_key_lookup.md | 2 +- doc/administration/operations/puma.md | 5 ++--- doc/administration/read_only_gitlab.md | 10 ++++----- .../reference_architectures/10k_users.md | 5 +---- .../reference_architectures/25k_users.md | 5 +---- .../reference_architectures/2k_users.md | 5 +---- .../reference_architectures/3k_users.md | 5 +---- .../reference_architectures/50k_users.md | 5 +---- .../reference_architectures/5k_users.md | 5 +---- doc/administration/troubleshooting/debug.md | 2 +- .../troubleshooting/linux_cheat_sheet.md | 4 ++-- doc/development/architecture.md | 3 +-- doc/development/chaos_endpoints.md | 4 +--- doc/development/db_dump.md | 2 +- doc/development/kubernetes.md | 2 +- .../merge_request_performance_guidelines.md | 10 ++++----- doc/development/performance.md | 4 ++-- doc/development/secure_coding_guidelines.md | 2 +- .../testing_guide/testing_levels.md | 2 +- doc/install/installation.md | 19 ---------------- doc/install/relative_url.md | 4 ++-- doc/install/requirements.md | 16 -------------- doc/integration/saml.md | 4 ++-- doc/raketasks/backup_restore.md | 4 +--- doc/update/mysql_to_postgresql.md | 8 +++---- .../upgrading_postgresql_using_slony.md | 2 +- doc/user/admin_area/geo_nodes.md | 2 +- doc/user/admin_area/index.md | 2 +- .../admin_area/settings/gitaly_timeouts.md | 5 ++--- 38 files changed, 53 insertions(+), 139 deletions(-) diff --git a/README.md b/README.md index bc173b5403c777..caafa30ead5050 100644 --- a/README.md +++ b/README.md @@ -68,9 +68,9 @@ GitLab is an open source project and we are very happy to accept community contr To work on GitLab itself, we recommend setting up your development environment with [the GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit). If you do not use the GitLab Development Kit you need to install and setup all the dependencies yourself, this is a lot of work and error prone. -One small thing you also have to do when installing it yourself is to copy the example development Unicorn configuration file: +One small thing you also have to do when installing it yourself is to copy the example development Puma configuration file: - cp config/unicorn.rb.example.development config/unicorn.rb + cp config/puma.rb.example.development config/puma.rb Instructions on how to start GitLab and how to run the tests can be found in the [getting started section of the GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit#getting-started). diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md index bd34a82f688142..828cdecb014999 100644 --- a/doc/administration/database_load_balancing.md +++ b/doc/administration/database_load_balancing.md @@ -171,28 +171,6 @@ Some nameservers (like [Consul](https://www.consul.io/docs/discovery/dns#udp-bas queried over UDP. To overcome this issue, you can use TCP for querying by setting `use_tcp` to `true`. -### Forking - -NOTE: -Starting with GitLab 13.0, Puma is the default web server used in GitLab -all-in-one package based installations as well as GitLab Helm chart deployments. - -If you use an application server that forks, such as Unicorn, you _have to_ -update your Unicorn configuration to start service discovery _after_ a fork. -Failure to do so leads to service discovery only running in the parent -process. If you are using Unicorn, then you can add the following to your -Unicorn configuration file: - -```ruby -after_fork do |server, worker| - defined?(Gitlab::Database::LoadBalancing) && - Gitlab::Database::LoadBalancing.start_service_discovery -end -``` - -This ensures that service discovery is started in both the parent and all -child processes. - ## Balancing queries Read-only `SELECT` queries balance among all the secondary hosts. diff --git a/doc/administration/geo/replication/geo_validation_tests.md b/doc/administration/geo/replication/geo_validation_tests.md index 8f67e70c9e2eba..c6b1078ddf08f4 100644 --- a/doc/administration/geo/replication/geo_validation_tests.md +++ b/doc/administration/geo/replication/geo_validation_tests.md @@ -43,7 +43,7 @@ The following are GitLab upgrade validation tests we performed. - Outcome: Partial success because we observed downtime during the upgrade of the primary and secondary sites. - Follow up issues/actions: - [Fix zero-downtime upgrade process/instructions for multi-node Geo deployments](https://gitlab.com/gitlab-org/gitlab/-/issues/225684) - - [Geo:check Rake task: Exclude AuthorizedKeysCommand check if node not running Puma/Unicorn](https://gitlab.com/gitlab-org/gitlab/-/issues/225454) + - [Geo:check Rake task: Exclude AuthorizedKeysCommand check if node not running Puma](https://gitlab.com/gitlab-org/gitlab/-/issues/225454) - [Update instructions in the next upgrade issue to include monitoring HAProxy dashboards](https://gitlab.com/gitlab-org/gitlab/-/issues/225359) [Upgrade Geo multi-node installation](https://gitlab.com/gitlab-org/gitlab/-/issues/208104): @@ -53,7 +53,7 @@ The following are GitLab upgrade validation tests we performed. - Outcome: Partial success because we did not run the looping pipeline during the demo to validate zero-downtime. - Follow up issues: - - [Clarify how Puma/Unicorn should include deploy node](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5460) + - [Clarify how Puma should include deploy node](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5460) - [Investigate MR creation failure after upgrade to 12.9.10](https://gitlab.com/gitlab-org/gitlab/-/issues/223282) Closed as false positive. ### February 2020 diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md index 59bb3884a02788..a11fa1241bf3a0 100644 --- a/doc/administration/geo/replication/multiple_servers.md +++ b/doc/administration/geo/replication/multiple_servers.md @@ -222,7 +222,6 @@ the **primary** database. Use the following as a guide. sidekiq['enable'] = false sidekiq_cluster['enable'] = false puma['enable'] = false - unicorn['enable'] = false ``` After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect. @@ -294,7 +293,6 @@ Configure the tracking database. sidekiq['enable'] = false sidekiq_cluster['enable'] = false puma['enable'] = false - unicorn['enable'] = false ``` After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect. @@ -440,7 +438,6 @@ application servers above, with some changes to run only the `sidekiq` service: redis_exporter['enable'] = false repmgr['enable'] = false puma['enable'] = false - unicorn['enable'] = false ## ## The unique identifier for the Geo node. diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md index c9b6fd4c5105d7..d79fcec336f52f 100644 --- a/doc/administration/gitaly/configure_gitaly.md +++ b/doc/administration/gitaly/configure_gitaly.md @@ -82,7 +82,7 @@ The following list depicts the network architecture of Gitaly: - Gitaly addresses must be specified in such a way that they resolve correctly for **all** Gitaly clients. - Gitaly clients are: - - Puma or Unicorn. + - Puma. - Sidekiq. - GitLab Workhorse. - GitLab Shell. diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 3935e990590f08..8e8df73e581594 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -346,7 +346,6 @@ When GitLab calls a function that has a "Rugged patch", it performs two checks: the GitLab use of "Rugged patch" code. - If the feature flag is not set, GitLab tries accessing the file system underneath the Gitaly server directly. If it can, it uses the "Rugged patch": - - If using Unicorn. - If using Puma and [thread count](../../install/requirements.md#puma-threads) is set to `1`. diff --git a/doc/administration/logs.md b/doc/administration/logs.md index 5921406973b1dc..eb51cd8c33b7a5 100644 --- a/doc/administration/logs.md +++ b/doc/administration/logs.md @@ -739,7 +739,7 @@ When enabled, access logs are generated in packages or in `/home/git/gitlab/log/sidekiq_exporter.log` for installations from source. -If Prometheus metrics and the Web Exporter are both enabled, Puma/Unicorn +If Prometheus metrics and the Web Exporter are both enabled, Puma starts a Web server and listen to the defined port (default: `8083`), and access logs are generated: diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md index 035c5b3ee7e0cc..d0966e657d23ad 100644 --- a/doc/administration/monitoring/prometheus/index.md +++ b/doc/administration/monitoring/prometheus/index.md @@ -227,7 +227,7 @@ To use an external Prometheus server: gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1'] ``` -1. On **all** GitLab Rails(Puma/Unicorn, Sidekiq) servers, set the Prometheus server IP address and listen port. For example: +1. On **all** GitLab Rails(Puma, Sidekiq) servers, set the Prometheus server IP address and listen port. For example: ```ruby gitlab_rails['prometheus_address'] = '192.168.0.1:9090' diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md index c49a2c20ed260c..983f1df1b98729 100644 --- a/doc/administration/nfs.md +++ b/doc/administration/nfs.md @@ -445,11 +445,11 @@ In case of NFS-related problems, it can be helpful to trace the file system requests that are being made by using `perf`: ```shell -sudo perf trace -e 'nfs4:*' -p $(pgrep -fd ',' puma && pgrep -fd ',' unicorn) +sudo perf trace -e 'nfs4:*' -p $(pgrep -fd ',' puma) ``` On Ubuntu 16.04, use: ```shell -sudo perf trace --no-syscalls --event 'nfs4:*' -p $(pgrep -fd ',' puma && pgrep -fd ',' unicorn) +sudo perf trace --no-syscalls --event 'nfs4:*' -p $(pgrep -fd ',' puma) ``` diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md index 980db9713ee640..e88736ed282c76 100644 --- a/doc/administration/operations/fast_ssh_key_lookup.md +++ b/doc/administration/operations/fast_ssh_key_lookup.md @@ -219,5 +219,5 @@ the database. The following instructions can be used to build OpenSSH 7.5: GitLab supports `authorized_keys` database lookups with [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux). Because the SELinux policy is static, GitLab doesn't support the ability to change -internal Unicorn ports at the moment. Administrators would have to create a special `.te` +internal webserver ports at the moment. Administrators would have to create a special `.te` file for the environment, since it isn't generated dynamically. diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md index 3b676010bfe58d..06845fe79663da 100644 --- a/doc/administration/operations/puma.md +++ b/doc/administration/operations/puma.md @@ -7,8 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Switching to Puma As of GitLab 12.9, [Puma](https://github.com/puma/puma) has replaced [Unicorn](https://yhbt.net/unicorn/) -as the default web server. From GitLab 13.0, the following run Puma instead of Unicorn unless -explicitly configured not to: +as the default web server. From GitLab 14.0, the following run Puma: - All-in-one package-based installations. - Helm chart-based installations. @@ -25,7 +24,7 @@ Multi-threaded Puma can therefore still serve more requests than a single proces ## Configuring Puma to replace Unicorn -Beginning with GitLab 13.0, Puma is the default application server. We plan to remove support for +Beginning with GitLab 13.0, Puma is the default application server. We removed support for Unicorn in GitLab 14.0. When switching to Puma, Unicorn server configuration diff --git a/doc/administration/read_only_gitlab.md b/doc/administration/read_only_gitlab.md index 698da80a07c8cc..c8931eb79df9cc 100644 --- a/doc/administration/read_only_gitlab.md +++ b/doc/administration/read_only_gitlab.md @@ -19,10 +19,10 @@ The configuration for doing so depends on your desired outcome. The first thing you'll want to accomplish is to ensure that no changes can be made to your repositories. There's two ways you can accomplish that: -- Either stop Unicorn/Puma to make the internal API unreachable: +- Either stop Puma to make the internal API unreachable: ```shell - sudo gitlab-ctl stop puma # or unicorn + sudo gitlab-ctl stop puma ``` - Or, open up a Rails console: @@ -46,19 +46,19 @@ made to your repositories. There's two ways you can accomplish that: ## Shut down the GitLab UI If you don't mind shutting down the GitLab UI, then the easiest approach is to -stop `sidekiq` and `puma`/`unicorn`, and you'll effectively ensure that no +stop `sidekiq` and `puma`, and you'll effectively ensure that no changes can be made to GitLab: ```shell sudo gitlab-ctl stop sidekiq -sudo gitlab-ctl stop puma # or unicorn +sudo gitlab-ctl stop puma ``` When you're ready to revert this: ```shell sudo gitlab-ctl start sidekiq -sudo gitlab-ctl start puma # or unicorn +sudo gitlab-ctl start puma ``` ## Make the database read-only diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index c9beee19fda534..9167045301e27e 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -157,7 +157,7 @@ To set up GitLab and its components to accommodate up to 10,000 users: provides access to the Git repositories. 1. [Configure Sidekiq](#configure-sidekiq). 1. [Configure the main GitLab Rails application](#configure-gitlab-rails) - to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend + to run Puma, Workhorse, GitLab Shell, and to serve all frontend requests (which include UI, API, and Git over HTTP/SSH). 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab environment. @@ -1538,7 +1538,6 @@ To configure the Praefect nodes, on each one: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -1667,7 +1666,6 @@ On each node: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -2235,7 +2233,6 @@ To configure the Monitoring node: redis_exporter['enable'] = false sidekiq['enable'] = false puma['enable'] = false - unicorn['enable'] = false node_exporter['enable'] = false gitlab_exporter['enable'] = false diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 1474d1b54e34cb..84a8767e8f2b76 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -157,7 +157,7 @@ To set up GitLab and its components to accommodate up to 25,000 users: provides access to the Git repositories. 1. [Configure Sidekiq](#configure-sidekiq). 1. [Configure the main GitLab Rails application](#configure-gitlab-rails) - to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend + to run Puma, Workhorse, GitLab Shell, and to serve all frontend requests (which include UI, API, and Git over HTTP/SSH). 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab environment. @@ -1540,7 +1540,6 @@ To configure the Praefect nodes, on each one: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -1669,7 +1668,6 @@ On each node: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -2239,7 +2237,6 @@ To configure the Monitoring node: redis_exporter['enable'] = false sidekiq['enable'] = false puma['enable'] = false - unicorn['enable'] = false node_exporter['enable'] = false gitlab_exporter['enable'] = false diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index b653a57debab49..0ff0c6bb55090d 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/doc/administration/reference_architectures/2k_users.md @@ -84,7 +84,7 @@ To set up GitLab and its components to accommodate up to 2,000 users: 1. [Configure Gitaly](#configure-gitaly), which provides access to the Git repositories. 1. [Configure the main GitLab Rails application](#configure-gitlab-rails) - to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend + to run Puma, Workhorse, GitLab Shell, and to serve all frontend requests (which include UI, API, and Git over HTTP/SSH). 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab environment. @@ -351,7 +351,6 @@ Omnibus: sidekiq['enable'] = false gitlab_workhorse['enable'] = false puma['enable'] = false - unicorn['enable'] = false postgresql['enable'] = false nginx['enable'] = false prometheus['enable'] = false @@ -457,7 +456,6 @@ To configure the Gitaly server, on the server node you want to use for Gitaly: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -791,7 +789,6 @@ running [Prometheus](../monitoring/prometheus/index.md) and redis_exporter['enable'] = false sidekiq['enable'] = false puma['enable'] = false - unicorn['enable'] = false node_exporter['enable'] = false gitlab_exporter['enable'] = false diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index 709420b9e24a1c..8f11c7f02d113e 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -169,7 +169,7 @@ To set up GitLab and its components to accommodate up to 3,000 users: provides access to the Git repositories. 1. [Configure Sidekiq](#configure-sidekiq). 1. [Configure the main GitLab Rails application](#configure-gitlab-rails) - to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend + to run Puma, Workhorse, GitLab Shell, and to serve all frontend requests (which include UI, API, and Git over HTTP/SSH). 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab environment. @@ -1238,7 +1238,6 @@ To configure the Praefect nodes, on each one: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -1367,7 +1366,6 @@ On each node: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -1916,7 +1914,6 @@ running [Prometheus](../monitoring/prometheus/index.md) and redis_exporter['enable'] = false sidekiq['enable'] = false puma['enable'] = false - unicorn['enable'] = false node_exporter['enable'] = false gitlab_exporter['enable'] = false diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index f492f82f9024c1..35ecb914440173 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -157,7 +157,7 @@ To set up GitLab and its components to accommodate up to 50,000 users: provides access to the Git repositories. 1. [Configure Sidekiq](#configure-sidekiq). 1. [Configure the main GitLab Rails application](#configure-gitlab-rails) - to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend + to run Puma, Workhorse, GitLab Shell, and to serve all frontend requests (which include UI, API, and Git over HTTP/SSH). 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab environment. @@ -1547,7 +1547,6 @@ To configure the Praefect nodes, on each one: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -1676,7 +1675,6 @@ On each node: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -2253,7 +2251,6 @@ To configure the Monitoring node: redis_exporter['enable'] = false sidekiq['enable'] = false puma['enable'] = false - unicorn['enable'] = false node_exporter['enable'] = false gitlab_exporter['enable'] = false diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 36d8b1021017f0..b9a938cec18865 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -161,7 +161,7 @@ To set up GitLab and its components to accommodate up to 5,000 users: provides access to the Git repositories. 1. [Configure Sidekiq](#configure-sidekiq). 1. [Configure the main GitLab Rails application](#configure-gitlab-rails) - to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend + to run Puma, Workhorse, GitLab Shell, and to serve all frontend requests (which include UI, API, and Git over HTTP/SSH). 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab environment. @@ -1229,7 +1229,6 @@ To configure the Praefect nodes, on each one: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -1358,7 +1357,6 @@ On each node: redis['enable'] = false nginx['enable'] = false puma['enable'] = false - unicorn['enable'] = false sidekiq['enable'] = false gitlab_workhorse['enable'] = false grafana['enable'] = false @@ -1904,7 +1902,6 @@ running [Prometheus](../monitoring/prometheus/index.md) and redis_exporter['enable'] = false sidekiq['enable'] = false puma['enable'] = false - unicorn['enable'] = false node_exporter['enable'] = false gitlab_exporter['enable'] = false diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md index 5a8ee1c5c94888..d8e3a69c2adeb9 100644 --- a/doc/administration/troubleshooting/debug.md +++ b/doc/administration/troubleshooting/debug.md @@ -155,7 +155,7 @@ and more. However, this is not enabled by default. To enable it, define the gitlab_rails['env'] = {"ENABLE_RBTRACE" => "1"} ``` -Then reconfigure the system and restart Unicorn and Sidekiq. To run this +Then reconfigure the system and restart Puma and Sidekiq. To run this in Omnibus, run as root: ```ruby diff --git a/doc/administration/troubleshooting/linux_cheat_sheet.md b/doc/administration/troubleshooting/linux_cheat_sheet.md index c4e991ccc1b97b..9de095e0560cc3 100644 --- a/doc/administration/troubleshooting/linux_cheat_sheet.md +++ b/doc/administration/troubleshooting/linux_cheat_sheet.md @@ -177,8 +177,8 @@ strace -tt -T -f -y -yy -s 1024 -p # -o output file -# run strace on all unicorn processes -ps auwx | grep unicorn | awk '{ print " -p " $2}' | xargs strace -tt -T -f -y -yy -s 1024 -o /tmp/unicorn.txt +# run strace on all puma processes +ps auwx | grep puma | awk '{ print " -p " $2}' | xargs strace -tt -T -f -y -yy -s 1024 -o /tmp/puma.txt ``` Be aware that strace can have major impacts to system performance when it is running. diff --git a/doc/development/architecture.md b/doc/development/architecture.md index d8d452240ff382..e82ce1cc2dc086 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -695,8 +695,7 @@ Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue #### Puma -Starting with GitLab 13.0, Puma is the default web server and Unicorn has been -disabled by default. +Starting with GitLab 13.0, Puma is the default web server. - [Project page](https://gitlab.com/gitlab-org/gitlab/blob/master/README.md) - Configuration: diff --git a/doc/development/chaos_endpoints.md b/doc/development/chaos_endpoints.md index 56e91acbc4ac7c..ae53a39c4c5030 100644 --- a/doc/development/chaos_endpoints.md +++ b/doc/development/chaos_endpoints.md @@ -47,7 +47,7 @@ Replace `secret` with your own secret token. After you have enabled the chaos endpoints and restarted the application, you can start testing using the endpoints. By default, when invoking a chaos endpoint, the web worker process which receives the request handles it. This means, for example, that if the Kill -operation is invoked, the Puma or Unicorn worker process handling the request is killed. To test these operations in Sidekiq, the `async` parameter on +operation is invoked, the Puma worker process handling the request is killed. To test these operations in Sidekiq, the `async` parameter on each endpoint can be set to `true`. This runs the chaos process in a Sidekiq worker. ## Memory leaks @@ -79,7 +79,6 @@ curl "http://localhost:3000/-/chaos/leakmem?memory_mb=1024&duration_s=10&token=s This endpoint attempts to fully utilise a single core, at 100%, for the given period. Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds). -If you're using Unicorn, this is done by killing the worker process. ```plaintext GET /-/chaos/cpu_spin @@ -103,7 +102,6 @@ This endpoint attempts to fully utilise a single core, and interleave it with DB This endpoint can be used to model yielding execution to another threads when running concurrently. Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds). -If you're using Unicorn, this is done by killing the worker process. ```plaintext GET /-/chaos/db_spin diff --git a/doc/development/db_dump.md b/doc/development/db_dump.md index 505305c860a74c..0c63bf06e0786a 100644 --- a/doc/development/db_dump.md +++ b/doc/development/db_dump.md @@ -21,7 +21,7 @@ large database imports. echo "postgresql['checkpoint_segments'] = 64" | sudo tee -a /etc/gitlab/gitlab.rb sudo touch /etc/gitlab/skip-auto-reconfigure sudo gitlab-ctl reconfigure -sudo gitlab-ctl stop unicorn +sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq ``` diff --git a/doc/development/kubernetes.md b/doc/development/kubernetes.md index 5be2080eb64457..20e66fe8a307df 100644 --- a/doc/development/kubernetes.md +++ b/doc/development/kubernetes.md @@ -50,7 +50,7 @@ to the relevant internal client. All calls to the Kubernetes API must be in a background process. Don't perform Kubernetes API calls within a web request. This blocks -Unicorn, and can lead to a denial-of-service (DoS) attack in GitLab as +webserver, and can lead to a denial-of-service (DoS) attack in GitLab as the Kubernetes cluster response times are outside of our control. The easiest way to ensure your calls happen a background process is to diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md index 543ca809f45020..973d4042cdaa74 100644 --- a/doc/development/merge_request_performance_guidelines.md +++ b/doc/development/merge_request_performance_guidelines.md @@ -292,13 +292,13 @@ in a batch style. **Summary:** You should set a reasonable timeout when the system invokes HTTP calls to external services (such as Kubernetes), and it should be executed in Sidekiq, not -in Puma/Unicorn threads. +in Puma threads. Often, GitLab needs to communicate with an external service such as Kubernetes clusters. In this case, it's hard to estimate when the external service finishes the requested process, for example, if it's a user-owned cluster that's inactive for some reason, GitLab might wait for the response forever ([Example](https://gitlab.com/gitlab-org/gitlab/-/issues/31475)). -This could result in Puma/Unicorn timeout and should be avoided at all cost. +This could result in Puma timeout and should be avoided at all cost. You should set a reasonable timeout, gracefully handle exceptions and surface the errors in UI or logging internally. @@ -598,10 +598,10 @@ Each feature that accepts data uploads or allows to download them needs to use saved directly to Object Storage by Workhorse, and all downloads needs to be served by Workhorse. -Performing uploads/downloads via Unicorn/Puma is an expensive operation, -as it blocks the whole processing slot (worker or thread) for the duration of the upload. +Performing uploads/downloads via Puma is an expensive operation, +as it blocks the whole processing slot (thread) for the duration of the upload. -Performing uploads/downloads via Unicorn/Puma also has a problem where the operation +Performing uploads/downloads via Puma also has a problem where the operation can time out, which is especially problematic for slow clients. If clients take a long time to upload/download the processing slot might be killed due to request processing timeout (usually between 30s-60s). diff --git a/doc/development/performance.md b/doc/development/performance.md index c6fe9f29b53b13..84b3a8f10926e9 100644 --- a/doc/development/performance.md +++ b/doc/development/performance.md @@ -283,8 +283,8 @@ Currently supported profiling targets are: - Sidekiq NOTE: -The Puma master process is not supported. Neither is Unicorn. -Sending SIGUSR2 to either of those triggers restarts. In the case of Puma, +The Puma master process is not supported. +Sending SIGUSR2 to it triggers restarts. In the case of Puma, take care to only send the signal to Puma workers. This can be done via `pkill -USR2 puma:`. The `:` distinguishes between `puma diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md index 62cc2543fc49f6..9c7927978b366d 100644 --- a/doc/development/secure_coding_guidelines.md +++ b/doc/development/secure_coding_guidelines.md @@ -129,7 +129,7 @@ way that increases execution time by several orders of magnitude. ### Impact -The resource, for example Unicorn, Puma, or Sidekiq, can be made to hang as it takes +The resource, for example Puma, or Sidekiq, can be made to hang as it takes a long time to evaluate the bad regex match. The evaluation time may require manual termination of the resource. diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md index abacb9a0c873e0..630b32daba2b79 100644 --- a/doc/development/testing_guide/testing_levels.md +++ b/doc/development/testing_guide/testing_levels.md @@ -48,7 +48,7 @@ records should use stubs/doubles as much as possible. | `config/` | `spec/config/` | RSpec | | | `config/initializers/` | `spec/initializers/` | RSpec | | | `config/routes.rb`, `config/routes/` | `spec/routing/` | RSpec | | -| `config/puma.example.development.rb`, `config/unicorn.rb.example` | `spec/rack_servers/` | RSpec | | +| `config/puma.example.development.rb` | `spec/rack_servers/` | RSpec | | | `db/` | `spec/db/` | RSpec | | | `db/{post_,}migrate/` | `spec/migrations/` | RSpec | More details in the [Testing Rails migrations guide](testing_migrations_guide.md). | | `Gemfile` | `spec/dependencies/`, `spec/sidekiq/` | RSpec | | diff --git a/doc/install/installation.md b/doc/install/installation.md index b9bde01c2fac6d..c5a30024a7b393 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -545,7 +545,6 @@ sudo -u git -H editor config/resque.yml ``` Make sure to edit both `gitlab.yml` and `puma.rb` to match your setup. -If you want to use the Unicorn web server, see [Using Unicorn](#using-unicorn) for the additional steps. If you want to use HTTPS, see [Using HTTPS](#using-https) for the additional steps. @@ -996,24 +995,6 @@ You also need to change the corresponding options (e.g. `ssh_user`, `ssh_host`, Apart from the always supported Markdown style, there are other rich text files that GitLab can display. But you might have to install a dependency to do so. See the [`github-markup` gem README](https://github.com/gitlabhq/markup#markups) for more information. -### Using Unicorn - -As of GitLab 12.9, [Puma](https://github.com/puma/puma) has replaced Unicorn as the default web server for installations from source. -If you want to switch back to Unicorn, follow these steps: - -1. Finish the GitLab setup so you have it up and running. -1. Copy the supplied example Unicorn configuration file into place: - - ```shell - cd /home/git/gitlab - - # Copy config file for the web server - sudo -u git -H cp config/unicorn.rb.example config/unicorn.rb - ``` - -1. Edit the system `init.d` script and set `USE_WEB_SERVER="unicorn"`. If you have `/etc/default/gitlab`, then you should edit it instead. -1. Restart GitLab. - ### Using Sidekiq instead of Sidekiq Cluster As of GitLab 12.10, Source installations are using `bin/sidekiq-cluster` for managing Sidekiq processes. diff --git a/doc/install/relative_url.md b/doc/install/relative_url.md index d04f55c43a352b..8b629e9084e463 100644 --- a/doc/install/relative_url.md +++ b/doc/install/relative_url.md @@ -29,7 +29,7 @@ relative URL is: - `/home/git/gitlab/config/initializers/relative_url.rb` - `/home/git/gitlab/config/gitlab.yml` -- `/home/git/gitlab/config/unicorn.rb` +- `/home/git/gitlab/config/puma.rb` - `/home/git/gitlab-shell/config.yml` - `/etc/default/gitlab` @@ -88,7 +88,7 @@ Make sure to follow all steps below: relative_url_root: /gitlab ``` -1. Edit `/home/git/gitlab/config/unicorn.rb` and uncomment/change the +1. Edit `/home/git/gitlab/config/puma.rb` and uncomment/change the following line: ```ruby diff --git a/doc/install/requirements.md b/doc/install/requirements.md index 8accf094795858..00de9dbbfea1dc 100644 --- a/doc/install/requirements.md +++ b/doc/install/requirements.md @@ -201,22 +201,6 @@ of [legacy Rugged code](../administration/gitaly/index.md#direct-access-to-git-i higher, due to how [Ruby MRI multi-threading](https://en.wikipedia.org/wiki/Global_interpreter_lock) works. -## Unicorn Workers - -For most instances we recommend using: (CPU cores * 1.5) + 1 = Unicorn workers. -For example a node with 4 cores would have 7 Unicorn workers. - -For all machines that have 2GB and up we recommend a minimum of three Unicorn workers. -If you have a 1GB machine we recommend to configure only two Unicorn workers to prevent excessive -swapping. - -As long as you have enough available CPU and memory capacity, it's okay to increase the number of -Unicorn workers and this usually helps to reduce the response time of the applications and -increase the ability to handle parallel requests. - -To change the Unicorn workers when you have the Omnibus package (which defaults to the -recommendation above) please see [the Unicorn settings in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/unicorn.html). - ## Redis and Sidekiq Redis stores all user sessions and the background task queue. diff --git a/doc/integration/saml.md b/doc/integration/saml.md index da1278b9edd961..927dd3cd714cf5 100644 --- a/doc/integration/saml.md +++ b/doc/integration/saml.md @@ -813,13 +813,13 @@ the CSRF check. To bypass this you can add `skip_before_action :verify_authenticity_token` to the `omniauth_callbacks_controller.rb` file immediately after the `class` line and -comment out the `protect_from_forgery` line using a `#`. Restart Unicorn for this +comment out the `protect_from_forgery` line using a `#`. Restart Puma for this change to take effect. This allows the error to hit GitLab, where it can then be seen in the usual logs, or as a flash message on the login screen. That file is located in `/opt/gitlab/embedded/service/gitlab-rails/app/controllers` for Omnibus installations and by default in `/home/git/gitlab/app/controllers` for -installations from source. Restart Unicorn using the `sudo gitlab-ctl restart unicorn` +installations from source. Restart Puma using the `sudo gitlab-ctl restart puma` command on Omnibus installations and `sudo service gitlab restart` on installations from source. diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index fc1c7838fd5237..592ddb298e5888 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -122,7 +122,7 @@ Similar to the Kubernetes case, if you have scaled out your GitLab cluster to use multiple application servers, you should pick a designated node (that isn't auto-scaled away) for running the backup Rake task. Because the backup Rake task is tightly coupled to the main Rails application, this is typically a node -on which you're also running Unicorn/Puma or Sidekiq. +on which you're also running Puma or Sidekiq. Example output: @@ -928,7 +928,6 @@ Stop the processes that are connected to the database. Leave the rest of GitLab running: ```shell -sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq # Verify @@ -996,7 +995,6 @@ For Docker installations, the restore task can be run from host: ```shell # Stop the processes that are connected to the database -docker exec -it gitlab-ctl stop unicorn docker exec -it gitlab-ctl stop puma docker exec -it gitlab-ctl stop sidekiq diff --git a/doc/update/mysql_to_postgresql.md b/doc/update/mysql_to_postgresql.md index cbe2381e8db226..92337f279d6303 100644 --- a/doc/update/mysql_to_postgresql.md +++ b/doc/update/mysql_to_postgresql.md @@ -91,10 +91,10 @@ need to enable the bundled PostgreSQL: 1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. -1. Start Unicorn and PostgreSQL so that we can prepare the schema: +1. Start Puma and PostgreSQL so that we can prepare the schema: ```shell - sudo gitlab-ctl start unicorn + sudo gitlab-ctl start puma sudo gitlab-ctl start postgresql ``` @@ -104,10 +104,10 @@ need to enable the bundled PostgreSQL: sudo gitlab-rake db:create db:migrate ``` -1. Stop Unicorn to prevent other database access from interfering with the loading of data: +1. Stop Puma to prevent other database access from interfering with the loading of data: ```shell - sudo gitlab-ctl stop unicorn + sudo gitlab-ctl stop puma ``` After these steps, you have a fresh PostgreSQL database with up-to-date schema. diff --git a/doc/update/upgrading_postgresql_using_slony.md b/doc/update/upgrading_postgresql_using_slony.md index 2cddaa5da8b8d6..3e977749207353 100644 --- a/doc/update/upgrading_postgresql_using_slony.md +++ b/doc/update/upgrading_postgresql_using_slony.md @@ -371,7 +371,7 @@ First, let's stop all of GitLab. Omnibus users can do so by running the following on their GitLab servers: ```shell -sudo gitlab-ctl stop unicorn +sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq sudo gitlab-ctl stop mailroom ``` diff --git a/doc/user/admin_area/geo_nodes.md b/doc/user/admin_area/geo_nodes.md index e5132ef4e96fe8..32b1555c33d49f 100644 --- a/doc/user/admin_area/geo_nodes.md +++ b/doc/user/admin_area/geo_nodes.md @@ -82,7 +82,7 @@ In GitLab 11.11, **secondary** nodes can use identical external URLs as long as a unique `name` is set for each Geo node. The `gitlab.rb` setting `gitlab_rails['geo_node_name']` must: -- Be set for each GitLab instance that runs `unicorn`, `sidekiq`, or `geo_logcursor`. +- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`. - Match a Geo node name. The load balancer must use sticky sessions in order to avoid authentication diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md index 5d1fde1c76781f..6c7f985dce645c 100644 --- a/doc/user/admin_area/index.md +++ b/doc/user/admin_area/index.md @@ -344,7 +344,7 @@ For multi-node systems we recommend ingesting the logs into services like Elasti |:------------------------|:---------| | `application.log` | GitLab user activity | | `git_json.log` | Failed GitLab interaction with Git repositories | -| `production.log` | Requests received from Unicorn, and the actions taken to serve those requests | +| `production.log` | Requests received from Puma, and the actions taken to serve those requests | | `sidekiq.log` | Background jobs | | `repocheck.log` | Repository activity | | `integrations_json.log` | Activity between GitLab and integrated systems | diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md index 3570634b9baa28..1643ad0effa429 100644 --- a/doc/user/admin_area/settings/gitaly_timeouts.md +++ b/doc/user/admin_area/settings/gitaly_timeouts.md @@ -20,9 +20,8 @@ To access Gitaly timeout settings: The following timeouts can be modified: - **Default Timeout Period**. This timeout is the default for most Gitaly calls. It should be shorter than the - worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings) - or [Unicorn](https://docs.gitlab.com/omnibus/settings/unicorn.html). Used to make sure that Gitaly - calls made within a web request cannot exceed the entire request timeout. + worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings). + Used to make sure that Gitaly calls made within a web request cannot exceed the entire request timeout. Defaults to 55 seconds. - **Fast Timeout Period**. This is the timeout for very short Gitaly calls. Defaults to 10 seconds. -- GitLab