Remove Unicorn support: docs

Updates docs related to Unicorn support removal.

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:

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

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
 ```

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

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 Unicorn/Puma also has a problem where the operation
+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 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).

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

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.

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 | |

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.

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

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.

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.

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 <name of container> gitlab-ctl stop unicorn
 docker exec -it <name of container> gitlab-ctl stop puma
 docker exec -it <name of container> gitlab-ctl stop sidekiq

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.

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
 ```

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

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 |

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.