Introducing repo2dockerより
repo2dockerは、Pythonで書かれた軽量のコマンドラインツールで、gitリポジトリへのパスやURLを受け取り、それに適したdockerイメージを作成します。これを実現するために、人間が行うであろうステップを踏んでいます。すなわち、
リポジトリを検査して、一般的な「設定」ファイル(requirements.txtなど)を探します。これらのよく知られたファイルから、実行すべきDockerコマンドを推論し、そして
Dockerイメージを構築します。イメージが構築されると、Dockerコンテナが作成されて実行され、リポジトリの作者がコードの実行を望んだ環境にアクセスできるようになります。これを実現するためには、repo2dockerとdockerデーモンの2つにアクセスする必要があります(必ずしもローカルコンピュータにdockerがインストールされている必要はありません)。
(中略)
この1年で、repo2dockerからいくつかの主要な使用例が出てきました。
まず、BinderHubのようなプロダクションシステムの一部として利用することができます。BinderHubは自動的にrepo2dockerを使用してユーザーの環境を実行するイメージを構築し、そのイメージを他の人が操作できるようにリンクを共有することができます。次に、JupyterHubで使用するイメージを構築するために、repo2dockerを使用することができます。例えば、学校の教師はrepo2dockerを使って、コース教材の入ったGitHubリポジトリを実行可能なDockerイメージに変換し、学生はクラウド上の共有jupyterhubを介してアクセスすることができます。
最後に、repo2dockerは、自分のローカルな作業から再現可能なイメージを構築したい個人にも利用されています。repo2dockerは、オプションで構築されたイメージの中からJupyterサーバーを実行することができ、リポジトリに存在する設定ファイルだけで構築された環境で、分析結果を検証することが可能になります。
repo2dockerは主にJupyterHubチームとBinderチームによってメンテナンスされています。
Introducing repo2docker
Introducing repo2docker. The Binder Project’s repo2docker tool… | by Chris Holdgraf | Jupyter Blog
Documantation
http://repo2docker.readthedocs.io/
Frequently Asked Questions (FAQ)
https://repo2docker.readthedocs.io/en/latest/faq.html
repo2dockerは、設定ファイルを以下の場所で探す。
binder/ と .binder/ の両方のフォルダーを持つことはできない。これらのフォルダーのいずれかが存在する場合、そのフォルダー内の設定ファイルのみが考慮され、ルートディレクトリ内の設定は無視される。repo2dockerがサポートしている設定ファイルの一覧はこちら。
jupyter以外を使うことも可能。こちらを確認して下さい。
インストール
mambaを使って導入した。
#conda (link)
mamba install -c conda-forge jupyter-repo2docker -y
#from source
git clone https://github.com/jupyterhub/repo2docker.git
cd repo2docker
pip install -e .
> repo2docker -h
$ repo2docker -h
usage: repo2docker [-h] [--config CONFIG] [--json-logs] [--image-name IMAGE_NAME] [--ref REF] [--debug] [--no-build] [--build-memory-limit BUILD_MEMORY_LIMIT] [--no-run] [--publish PORTS]
[--publish-all] [--no-clean] [--push] [--volume VOLUMES] [--user-id USER_ID] [--user-name USER_NAME] [--env ENVIRONMENT] [--editable] [--target-repo-dir TARGET_REPO_DIR]
[--appendix APPENDIX] [--subdir SUBDIR] [--version] [--cache-from CACHE_FROM]
repo ...
Fetch a repository and build a container image
positional arguments:
repo Path to repository that should be built. Could be local path or a git URL.
cmd Custom command to run after building container
optional arguments:
-h, --help show this help message and exit
--config CONFIG Path to config file for repo2docker
--json-logs Emit JSON logs instead of human readable logs
--image-name IMAGE_NAME
Name of image to be built. If unspecified will be autogenerated
--ref REF Reference to build instead of default reference. For example branch name or commit for a Git repository.
--debug Turn on debug logging
--no-build Do not actually build the image. Useful in conjunction with --debug.
--build-memory-limit BUILD_MEMORY_LIMIT
Total Memory that can be used by the docker build process
--no-run Do not run container after it has been built
Specify port mappings for the image. Needs a command to run in the container.
--publish-all, -P Publish all exposed ports to random host ports.
--no-clean Don't clean up remote checkouts after we are done
--push Push docker image to repository
--volume VOLUMES, -v VOLUMES
Volumes to mount inside the container, in form src:dest
--user-id USER_ID User ID of the primary user in the image
--user-name USER_NAME
Username of the primary user in the image
--env ENVIRONMENT, -e ENVIRONMENT
Environment variables to define at container run time
--editable, -E Use the local repository in edit mode
--target-repo-dir TARGET_REPO_DIR
Path inside the image where contents of the repositories are copied to, and where all the build operations (such as postBuild) happen. Defaults to ${HOME} if not set
--appendix APPENDIX Appendix of Dockerfile commands to run at the end of the build. Can be used to customize the resulting image after all standard build steps finish.
--subdir SUBDIR Subdirectory of the git repository to examine. Defaults to ''.
--version Print the repo2docker version and exit.
--cache-from CACHE_FROM
List of images to try & re-use cached image layers from. Docker only tries to re-use image layers from images built locally, not pulled from a registry. We can ask it
to explicitly re-use layers from non-locally built images by through the 'cache_from' parameter.
実行方法
レポジトリを指定する。指定方法は、レポジトリのURL、Zenodo (wiki) DOI、SoftWare Heritage persistent IDentifiers (SWHIDs)ハッシュ;SHA1 なら(swh:1:~)、またはローカルディスクのレポジトリパス、のいずれかになる。
公式では、 Peter NorvigのPytudesレポジトリを例にしている。 これはユーザーがPythonの短く特定のプログラミングスキルを訓練するためのレポジトリで、練習用データと.ipynbファイルが含まれている。Binder, Google colab、Jupyter Notebook Viewer、DeepNoteでビューしたり実行できるように整備されているが、これを対象にしている。
jupyter-repo2docker https://github.com/norvig/pytudes
指定されたURLにアクセスする。
立ち上がった。
引用
https://github.com/jupyterhub/repo2docker
参考
JupyterHub のセットアップ
https://engineering.mobalab.net/2019/11/28/set-up-jupyterhub/
研究再現性を支える情報基盤が持つべきデータモデルの検討
https://researchmap.jp/ikki/presentations/30036291/attachment_file.pdf
Ten simple rules for writing Dockerfiles for reproducible data science