manual/deploy_pro/migrate.md requires instructions for container deployments

[draeath]

These instructions look great for a "classic" deployment, however they require individual seafile components like seahub to be stopped/started, etc.

This seems to be incompatible with a docker-compose deployment, as the container has to be running to run the migration script, and the image runs /sbin/my_init -- /scripts/enterpoint.sh which in turn runs /scripts/cluster_server.sh enterpoint or /scripts/start.py - one would have to create a new (modified) image to run, which allows the container to be 'up' (in order to use docker exec) without actually starting the application components.

---

Please update this documentation to provide guidance on storage backend migration when using the docker-compose method of deployment.

[draeath]

Alternatively (and more disruptively) moving these initialization scripts under the /shared volume might allow one to make these changes without needing to create and shuffle modified container images.

Doing so, however, would then require a mechanism to update these scripts when the base image is updated.

[draeath]

I've figured out one can do docker compose run seafile sleep infinity to get a container up to work in (using docker compose exec <container-name> /bin/bash, however the steps outlined in the migration process do not work:

root@34de96679e78:/opt/seafile/seafile-pro-server-10.0.15# cat /tmp/what-am-i-doing/seafile.conf
[fileserver]
port = 8082
use_go_fileserver = true

[database]
type = mysql
host = db
port = 3306
user = REDACTED
password = REDACTED
db_name = REDACTED
connection_charset = utf8

[block_backend]
name = s3
bucket = REDACTED
key_id = REDACTED
key = REDACTED
use_v4_signature = true
aws_region = REDACTED

[commit_object_backend]
name = s3
bucket = REDACTED
key_id = REDACTED
key = REDACTED
use_v4_signature = true
aws_region = REDACTED

[fs_object_backend]
name = s3
bucket = REDACTED
key_id = REDACTED
key = REDACTED
use_v4_signature = true
aws_region = REDACTED

root@34de96679e78:/opt/seafile/seafile-pro-server-10.0.15# ./migrate.sh /tmp/what-am-i-doing

Traceback (most recent call last):
  File "/opt/seafile/seafile-pro-server-10.0.15/migrate.py", line 14, in <module>
    from seafobj.objstore_factory import SeafObjStoreFactory
  File "/opt/seafile/seafile-pro-server-10.0.15/seahub/thirdpart/seafobj/__init__.py", line 2, in <module>
    from .commits import commit_mgr
  File "/opt/seafile/seafile-pro-server-10.0.15/seahub/thirdpart/seafobj/commits.py", line 67, in <module>
    commit_mgr = SeafCommitManager()
  File "/opt/seafile/seafile-pro-server-10.0.15/seahub/thirdpart/seafobj/commits.py", line 26, in __init__
    self.obj_store = objstore_factory.get_obj_store('commits')
  File "/opt/seafile/seafile-pro-server-10.0.15/seahub/thirdpart/seafobj/objstore_factory.py", line 350, in get_obj_store
    obj_dir = os.path.join(self.seafile_cfg.get_seafile_storage_dir(), obj_type)
  File "/opt/seafile/seafile-pro-server-10.0.15/seahub/thirdpart/seafobj/objstore_factory.py", line 257, in get_seafile_storage_dir
    raise RuntimeError('environment SEAFILE_CONF_DIR not set correctly.');
RuntimeError: environment SEAFILE_CONF_DIR not set correctly.
Done.
root@34de96679e78:/opt/seafile/seafile-pro-server-10.0.15#

(I'm failing to follow the rather convoluted startup process the container normally works in order to set the variables appropriately.)

[draeath]

Looks like you can run the online part of the process as-is, it's only trying to do this without seafile up and running where it falls over.

Fortunately I have a small deployment, and it's easy enough for me to prevent clients from talking to the server such that nothing should be locked, but still.