Galaxy ServerをDockerを利用して起動した時にログインユーザーだけが利用できるようにする

13752 ワード
Docker Galaxy Galaxy テキストリンク

ログインユーザーだけがツールを利用できるようにしたい

Galaxy Serverを手元のコンピューターで動かしてみようで動作させたGalaxy サーバーには、手元のマシンからだけでは無くネットワークを経由して接続可能な全てのマシンからアクセスできてしまう

その場合のアクセス方法はhttp://動作中のマシンのIPアドレス:8080となる

初期の状態はこうなっている

ログイン前でもToolsには各種のツールが並んでいて、このまま利用することができる

もし、そのような状況が意図したものであれば問題は無いが、誰か知らない人に自分のマシンのGalaxyサーバーのツールを利用して欲しくない場合もある

そこで、ツールを利用する場合にはログインが必要になるようにGalaxyサーバーの設定を変更してみよう

Galaxyの設定はどこで変更するのか

Galaxyではサーバーの様々な項目について設定を柔軟に変更できるようになっている
最も基本的な設定ファイルがgalaxy.ymlファイル
設定の詳細についてはGalaxy Configurationを参照の事

実際に設定を変更してみよう

ここで変更するパラメータはrequire_loginとなる
require_loginの既定値はfalseで、この場合はGalaxyサーバーにアクセスできるユーザーはログインしなくてもツールを利用する事ができる
ここではrequire_loginの設定を変更してgalaxyを起動してみよう
Galaxy's config settingsによると、Docker版のGalaxy では docker runで環境変数を設定することでgalaxy.ymlの設定値を変更する事ができると記載されている

Every Galaxy configuration parameter in config/galaxy.ini can be overwritten by passing an environment variable to the docker run command during startup. The name of the environment variable has to be: GALAXY_CONFIG+ the_original_parameter_name_in_capital_letters For example, you can set the Galaxy session timeout to 5 minutes by adding -e "GALAXY_CONFIG_SESSION_DURATION=5" to the docker run command

GALAXY_CONFIG_に加えてパラメーターの文字列を大文字にしたものに値を設定する
ここで設定するのはrequire_loginなので　GALAXY_CONFIG_REQUIRE_LOGIN=True となる　

$ docker run -d --rm \
    -p 8080:80 -p 8021:21 -p 8022:22 -p 8800:8800 \
    --volumes-from galaxy-store \
    --privileged=true  \
    -e GALAXY_CONFIG_ENABLE_BETA_MULLED_CONTAINERS=True \
    -e GALAXY_CONFIG_REQUIRE_LOGIN=True \
    -e ENABLE_TTS_INSTALL=True \
    bgruening/galaxy-stable

ログインしていない場合にToolsペインやHistoryペインが消えてログイン画面のみの表示となる

galaxy.ymlの変更

Dockerコンテナでは無いGalaxyのサーバー版ではgalaxy.ymlのファイルを変更する事で設定を変更する
require_loginをtrueにすることでログインが必要となるように動作を変更してみよう

Galaxy Configurationによれば、galaxy.ymlはgalaxyのディレクトリのconfigに存在すると書かれている

Configuration files can be found underneath the config/ subdirectory, wherein you can find .sample files corresponding to configuration files that you can modify by copying the .sample to . In many cases, you will find that the sample configuration provides the most up-to-date and detailed documentation about the features configured therein.

では、現在デーモンモードで動作しているgalaxyのコンテナに接続して、このファイルを書き換え/作成してみよう

最初に現在動作しているGalaxyコンテナの"CONTAINER ID"を確認しよう

$ docker ps
CONTAINER ID        IMAGE                     COMMAND              CREATED             STATUS              PORTS                                                                                                         NAMES
0498d80bbb78        bgruening/galaxy-stable   "/usr/bin/startup"   17 minutes ago      Up 17 minutes       443/tcp, 9002/tcp, 0.0.0.0:8800->8800/tcp, 0.0.0.0:8021->21/tcp, 0.0.0.0:8022->22/tcp, 0.0.0.0:8080->80/tcp   jovial_hertz

ここでは"CONTAINER ID"は0498d80bbb78となっている
このIDはコンテナの実行毎に異なる

後の記述を統一するために環境変数に"CONTAINER ID"を格納しておく

export CONTAINER_ID="0498d80bbb78"

("0498d80bbb78"の部分は各自のCONTAINER IDで置き換える事)
現在動作中のコンテナに接続して該当のファイルに変更を加えてみる

$ docker exec -it ${CONTAINER_ID} /bin/bash
root@0498d80bbb78:/galaxy-central# ls config
auth_conf.xml.sample                    job_resource_params_conf.xml.sample  shed_tool_conf.xml.sample
build_sites.yml.sample                  lmod_modules_mapping.yml.sample      shed_tool_data_table_conf.xml
containers_conf.yml.sample              local_conda_mapping.yml.sample       shed_tool_data_table_conf.xml.sample
data_manager_conf.xml.sample            migrated_tools_conf.xml              swarm_manager_conf.yml.sample
datatypes_conf.xml.sample               migrated_tools_conf.xml.sample       tool_conf.xml.main
dependency_resolvers_conf.xml.sample    object_store_conf.xml.sample         tool_conf.xml.sample
disposable_email_blacklist.conf.sample  oidc_backends_config.xml.sample      tool_data_table_conf.xml.sample
error_report.yml.sample                 oidc_config.xml.sample               tool_destinations.yml.sample
galaxy.yml.docker_sample                openid_conf.xml.sample               tool_sheds_conf.xml.sample
galaxy.yml.sample                       plugins                              tool_shed.yml.sample
job_conf.xml.docker_sample              reports.yml.sample                   user_preferences_extra_conf.yml.sample
job_conf.xml.sample_advanced            shed_data_manager_conf.xml           workflow_resource_mapper_conf.yml.sample
job_conf.xml.sample_basic               shed_data_manager_conf.xml.sample    workflow_resource_params_conf.xml.sample
job_metrics_conf.xml.sample             shed_tool_conf.xml                   workflow_schedulers_conf.xml.sample

どうやらconfigディレクトリにはgalaxy.ymlは存在しないようだ

Galaxy Configurationを読むと

Edit config/galaxy.yml (copy it from config/galaxy.yml.sample if it does not exist) to make configuration changes.

galaxy.yml存在しない場合にはgalaxy.yml.sampleをコピーして利用するようにと書かれている
その通りにしてみよう

inside_docker_container
root@0498d80bbb78:/galaxy-central# cd config
root@0498d80bbb78:/galaxy-central/config# cp galaxy.yml.sample galaxy.yml

galaxy.ymlにrequire_loginが含まれているか確認してみる

root@0498d80bbb78:/galaxy-central/config# cat -n galaxy.yml| grep "require_login"
  1259    #require_login: false
  1262    # page (even if require_login is True)

既定値と同じなのでコメントアウトされているが1259行目に確かに存在する
後は適当なエディターで、この1259行目の後にrequire_login: trueを書き込もう

その後、Galaxyのサーバープロセスを再起動

inside_docker_container
root@0498d80bbb78:/galaxy-central/config# supervisorctl restart galaxy:
galaxy:galaxy_nodejs_proxy: stopped
galaxy:handler0: stopped
galaxy:galaxy_web: stopped
galaxy:handler1: stopped
galaxy:galaxy_nodejs_proxy: started
galaxy:galaxy_web: started
galaxy:handler0: started
galaxy:handler1: started

さて、結果はどうなったか

何も変わらない

実はDockerコンテナのGalaxyはsupervisordで管理されているために、普通のGalaxyとは設定が異なっている

galaxy.ymlはどこに？

supervisord の構成ファイルを参照してどのgalaxy.ymlを利用しているのか確認してみる

inside_docker_container
root@0498d80bbb78:/galaxy-central/config# ls /etc/supervisor/conf.d
galaxy.conf
root@0498d80bbb78:/galaxy-central/config# grep "galaxy.yml" /etc/supervisor/conf.d/galaxy.conf 
command         = /galaxy_venv/bin/uwsgi --virtualenv /galaxy_venv --yaml /etc/galaxy/galaxy.yml --logdate --thunder-lock --master --processes %(ENV_UWSGI_PROCESSES)s --threads %(ENV_UWSGI_THREADS)s --logto /home/galaxy/logs/uwsgi.log --socket 127.0.0.1:4001 --pythonpath lib --stats 127.0.0.1:9191 -b 16384
command         = /galaxy_venv/bin/python ./lib/galaxy/main.py -c /etc/galaxy/galaxy.yml --server-name=handler%(process_num)s --log-file=/home/galaxy/logs/handler%(process_num)s.log

このDocker imageのGalaxyサーバーは/etc/galaxy/galaxy.ymlを利用している事がわかった

適切なgalaxy.ymlを利用する

galaxy.ymlの設定ファイルがどこに存在するかわかったので、これを変更してGalaxy サーバーを利用しよう

変更内容を永続的なものとするために、ホスト側にgalaxy.ymlを置いて、これをDocker container内部にマウントして利用する事としたい

あらためて設定を変更

まずは、ホストのファイルシステムに該当のファイルをコピーする

$ docker exec ${CONTAINER_ID} cat /etc/galaxy/galaxy.yml > galaxy.yml

ファイルがホスト上にコピーされるので、ホスト上にコピーされたgalaxy.ymlにrequire_login: trueを先ほどと同様に追加しよう

現在起動中のコンテナの停止

$ docker kill ${CONTAINER_ID}

新しいコンテナをデーモンモードで起動

$ docker run -d --rm \
    -p 8080:80 -p 8021:21 -p 8022:22 -p 8800:8800 \
    --volumes-from galaxy-store \
    -v ${PWD}/galaxy.yml:/etc/galaxy/galaxy.yml \
    --privileged=true  \
    -e GALAXY_CONFIG_ENABLE_BETA_MULLED_CONTAINERS=True \
    -e ENABLE_TTS_INSTALL=True \
    bgruening/galaxy-stable

ホストのカレントディレクトリのgalaxy.ymlをコンテナ上の/etc/galaxy/galaxy.ymlにマップしているのは以下の部分
-v ${PWD}/galaxy.yml:/etc/galaxy/galaxy.yml
パス指定には絶対パスを利用する

以上の設定を終えたのでブラウザから接続して結果を確認

期待通りの画面が表示された
このgalaxy.ymlファイルはコンテナ環境ではないGalaxy Serverでも同様に利用できる(はず)

今回はここまで

TIL_Java Spring the Modern Way_3
JavaScript : Class