diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/administration/job_artifacts.md | 12 | ||||
| -rw-r--r-- | doc/administration/job_traces.md | 40 | ||||
| -rw-r--r-- | doc/administration/merge_request_diffs.md | 3 | ||||
| -rw-r--r-- | doc/administration/raketasks/uploads/migrate.md | 36 | ||||
| -rw-r--r-- | doc/workflow/lfs/lfs_administration.md | 8 |
5 files changed, 57 insertions, 42 deletions
diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md index 913321012e4..1ab37824694 100644 --- a/doc/administration/job_artifacts.md +++ b/doc/administration/job_artifacts.md @@ -92,7 +92,7 @@ Use an object storage option like AWS S3 to store job artifacts. DANGER: **Danger:** If you're enabling S3 in [GitLab HA](high_availability/README.md), you will need to have an [NFS mount set up for CI traces and artifacts](high_availability/nfs.md#a-single-nfs-mount) or enable [live tracing](job_traces.md#new-live-trace-architecture). If these settings are not set, you will risk job traces disappearing or not being saved. -### Object Storage Settings +#### Object Storage Settings For source installations the following settings are nested under `artifacts:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `artifacts_object_store_`. @@ -105,7 +105,7 @@ For source installations the following settings are nested under `artifacts:` an | `proxy_download` | Set to true to enable proxying all files served. Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data | `false` | | `connection` | Various connection options described below | | -#### S3 compatible connection settings +##### S3 compatible connection settings The connection settings match those provided by [Fog](https://github.com/fog), and are as follows: @@ -188,6 +188,14 @@ _The artifacts are stored by default in sudo -u git -H bundle exec rake gitlab:artifacts:migrate RAILS_ENV=production ``` +### Migrating from object storage to local storage + +In order to migrate back to local storage: + +1. Set both `direct_upload` and `background_upload` to false under the artifacts object storage settings. Don't forget to restart GitLab. +1. Run `rake gitlab:artifacts:migrate_to_local` on your console. +1. Disable `object_storage` for artifacts in `gitlab.rb`. Remember to restart GitLab afterwards. + ## Expiring artifacts If an expiry date is used for the artifacts, they are marked for deletion diff --git a/doc/administration/job_traces.md b/doc/administration/job_traces.md index 8a68f82d2fc..af60d777932 100644 --- a/doc/administration/job_traces.md +++ b/doc/administration/job_traces.md @@ -59,46 +59,6 @@ job traces are automatically migrated to it along with the other job artifacts. See "Phase 4: uploading" in [Data flow](#data-flow) to learn about the process. -## How to archive legacy job trace files - -Legacy job traces, which were created before GitLab 10.5, were not archived regularly. -It's the same state with the "2: overwriting" in the above [Data flow](#data-flow). -To archive those legacy job traces, please follow the instruction below. - -1. Execute the following command - - ```bash - gitlab-rake gitlab:traces:archive - ``` - - After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes) - for migrating job trace files from local storage to object storage. - It could take time to complete the all migration jobs. You can check the progress by the following command - - ```bash - sudo gitlab-rails console - ``` - - ```bash - [1] pry(main)> Sidekiq::Stats.new.queues['pipeline_background:archive_trace'] - => 100 - ``` - - If the count becomes zero, the archiving processes are done - -## How to migrate archived job traces to object storage - -> [Introduced][ce-21193] in GitLab 11.3. - -If job traces have already been archived into local storage, and you want to migrate those traces to object storage, please follow the instruction below. - -1. Ensure [Object storage integration for Job Artifacts](job_artifacts.md#object-storage-settings) is enabled -1. Execute the following command - - ```bash - gitlab-rake gitlab:traces:migrate - ``` - ## How to remove job traces There isn't a way to automatically expire old job logs, but it's safe to remove diff --git a/doc/administration/merge_request_diffs.md b/doc/administration/merge_request_diffs.md index f24a3f94ceb..db256728f4d 100644 --- a/doc/administration/merge_request_diffs.md +++ b/doc/administration/merge_request_diffs.md @@ -61,6 +61,9 @@ To enable external storage of merge request diffs, follow the instructions below ## Using object storage +CAUTION: **WARNING:** + Currently migrating to object storage is **non-reversible** + Instead of storing the external diffs on disk, we recommended the use of an object store like AWS S3 instead. This configuration relies on valid AWS credentials to be configured already. diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md index d9b4c9b3369..3bd8f2c27d4 100644 --- a/doc/administration/raketasks/uploads/migrate.md +++ b/doc/administration/raketasks/uploads/migrate.md @@ -113,3 +113,39 @@ To migrate all uploads created by legacy uploaders, run: ```shell bundle exec rake gitlab:uploads:legacy:migrate ``` + +## Migrate from object storage to local storage + +If you need to disable Object Storage for any reason, first you need to migrate +your data out of Object Storage and back into your local storage. + +**Before proceeding, it is important to disable both `direct_upload` and `background_upload` under `uploads` settings in `gitlab.rb`** + +CAUTION: **Warning:** + **Extended downtime is required** so no new files are created in object storage during + the migration. A configuration setting will be added soon to allow migrating + from object storage to local files with only a brief moment of downtime for configuration changes. + See issue [gitlab-org/gitlab-ce#66144](https://gitlab.com/gitlab-org/gitlab-ce/issues/66144) + +### All-in-one rake task + +GitLab provides a wrapper rake task that migrates all uploaded files - avatars, +logos, attachments, favicon, etc. - to local storage in one go. Under the hood, +it invokes individual rake tasks to migrate files falling under each of this +category one by one. For details on these rake tasks please [refer to the section above](#individual-rake-tasks), +keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`. + +**Omnibus Installation** + +```bash +gitlab-rake "gitlab:uploads:migrate_to_local:all" +``` + +**Source Installation** + +```bash +sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate_to_local:all +``` + +After this is done, you may disable Object Storage by undoing the changes described +in the instructions to [configure object storage](../../uploads.md#using-object-storage-core-only) diff --git a/doc/workflow/lfs/lfs_administration.md b/doc/workflow/lfs/lfs_administration.md index 1a7c87c1c5c..2e0674064c2 100644 --- a/doc/workflow/lfs/lfs_administration.md +++ b/doc/workflow/lfs/lfs_administration.md @@ -218,6 +218,14 @@ For source installations the settings are nested under `lfs:` and then will be forwarded to object storage unless `background_upload` is set to false. +### Migrating back to local storage + +In order to migrate back to local storage: + +1. Set both `direct_upload` and `background_upload` to false under the LFS object storage settings. Don't forget to restart GitLab. +1. Run `rake gitlab:lfs:migrate_to_local` on your console. +1. Disable `object_storage` for LFS objects in `gitlab.rb`. Remember to restart GitLab afterwards. + ## Storage statistics You can see the total storage used for LFS objects on groups and projects |