|
| 1 | +.. _minio-gateway-migration: |
| 2 | + |
| 3 | +======================================= |
| 4 | +Migrate from Gateway or Filesystem Mode |
| 5 | +======================================= |
| 6 | + |
| 7 | +.. default-domain:: minio |
| 8 | + |
| 9 | +.. contents:: Table of Contents |
| 10 | + :local: |
| 11 | + :depth: 1 |
| 12 | + |
| 13 | +Background |
| 14 | +---------- |
| 15 | + |
| 16 | +The MinIO Gateway entered a feature freeze in July 2020. |
| 17 | +In February 2022, MinIO announced the `deprecation of the MinIO Gateway <https://blog.min.io/deprecation-of-the-minio-gateway/?ref=docs>`__. |
| 18 | +Along with the deprecation announcement, MinIO also announced that the feature would be removed in six months time. |
| 19 | + |
| 20 | +As of :minio-release:`RELEASE.2022-10-29T06-21-33Z`, the MinIO Gateway and the related filesystem mode code have been removed. |
| 21 | +Deployments still using the `standalone` or `filesystem` MinIO modes that upgrade to :minio-release:`RELEASE.2022-10-29T06-21-33Z` or later receive an error when attempting to start MinIO. |
| 22 | + |
| 23 | +Overview |
| 24 | +-------- |
| 25 | + |
| 26 | +To upgrade to a :minio-release:`RELEASE.2022-10-29T06-21-33Z` or later, those who were using the `standalone` or `filesystem` deployment modes must create a new :ref:`Single-Node Single-Drive <minio-snsd>` deployment and migrate settings and content to the new deployment. |
| 27 | + |
| 28 | +This document outlines the steps required to successfully launch and migrate to a new deployment. |
| 29 | + |
| 30 | +Procedure |
| 31 | +--------- |
| 32 | + |
| 33 | +#. Retrieve the existing deployment's **environment variables** |
| 34 | + |
| 35 | + Use :mc-cmd:`mc admin config get` with the ``--json`` flag to retrieve a list of the environment variables defined on the existing standalone MinIO deployment. |
| 36 | + |
| 37 | +#. :ref:`Create a new Single-Node Single-Drive MinIO deployment <minio-snsd>` |
| 38 | + |
| 39 | + The location of the deployment can be any empty folder on the storage medium of your choice. |
| 40 | + As long as the existing deployment is not to the root of a drive, a new folder on the same drive can work for the new deployment. |
| 41 | + If the existing standalone system points to the root of the drive, you must use a separate drive for the new deployment. |
| 42 | + |
| 43 | + Use the environment variable values retrieved from the standalone deployment to establish the same values for the new deployment. |
| 44 | + |
| 45 | + Set the port to a custom point different than the existing standalone deployment. |
| 46 | + |
| 47 | +#. Duplicate **configurations** from existing standalone deployment to new deployment |
| 48 | + |
| 49 | + |
| 50 | + |
| 51 | +#. Duplicate **buckets** from existing standalone deployment to new deployment |
| 52 | + |
| 53 | + Use :mc-cmd:`mc ls` with the ``--json`` flag to retrieve a list of the buckets that exist on the standalone deployment. |
| 54 | + Use the list to recreate the buckets on the new deployment. |
| 55 | + |
| 56 | +#. Duplicate **tiers** from existing standalone deployment to new deployment |
| 57 | + |
| 58 | + Use :mc-cmd:`mc admin tier ls` with the ``--json`` flag to retrieve a list of the tiers that exist on the standalone deployment. |
| 59 | + Use the list to recreate the tiers on the new deployment. |
| 60 | + |
| 61 | +#. Duplicate **policies** from existing standalone deployment to new deployment |
| 62 | + |
| 63 | + Use :mc-cmd:`mc admin policy list` with the ``--json`` flag to retrieve a list of policies that exist on the standalone deployment. |
| 64 | + Use the list to recreate the policies on the new deployment. |
| 65 | + |
| 66 | +#. Duplicate **groups** from existing standalone deployment to new deployment |
| 67 | + |
| 68 | + Use :mc-cmd:`mc admin group list` with the ``--json`` flag to retrieve a list of groups that exist on the standalone deployment. |
| 69 | + Use the list to recreate the groups on the new deployment. |
| 70 | + |
| 71 | +#. Duplicate **users** from existing standalone deployment to new deployment |
| 72 | + |
| 73 | + Use :mc-cmd:`mc admin user list` with the ``--json`` flag to retrieve a list of users with access key, policy name, and status. |
| 74 | + Use the list to recreate the users on the new deployment. |
| 75 | + |
| 76 | + Note: You will need to define each user's ``SECRETKEY`` on the new deployment. |
| 77 | + Make note of the ``SECRETKEY`` for each user to let them know their new credentials. |
| 78 | + |
| 79 | +#. Duplicate **service accounts** from existing standalone deployment to new deployment |
| 80 | + |
| 81 | + Use :mc-cmd:`mc admin user svcacct ls` with the ``--json`` flag to list existing service accounts on the standalone deployment. |
| 82 | + Use the list to recreate the service accounts on the new deployment. |
| 83 | + |
| 84 | +#. Use :mc:`mc mirror` with the ``--watch`` flag on the standalone deployment to move objects to the new |SNSD| deployment |
| 85 | + |
| 86 | + Do this for each bucket. |
| 87 | + |
| 88 | +#. After the initial mirror process completes, convert standalone deployment to be read only |
| 89 | + |
| 90 | + Some options for doing this include: |
| 91 | + |
| 92 | + - ``mc admin policy remove`` for each active policy |
| 93 | + - ``mc admin policy unset`` to remove policy/policies for each group |
| 94 | + |
| 95 | +#. Wait for ``mc mirror`` to complete for all buckets. |
| 96 | + |
| 97 | +#. Shut down the server for the existing standalone deployment. |
| 98 | + |
| 99 | + |
| 100 | + |
| 101 | +#. Restart the new MinIO deployment with the ports used for the previous standalone deployment. |
| 102 | + |
| 103 | + |
| 104 | + |
| 105 | +#. Confirm the new deployment works as expected. |
| 106 | + |
| 107 | + Verify that users and service accounts have access to the buckets and objects as usual. |
0 commit comments