私はDockerから始めていますが、コンテナーにあるpythonインタープリターを使用するようにPyCharmを構成する方法がわかりません。
Vagrantで設定するのは簡単でした ですが、 明らかにDockerでそれを行う公式の方法はありません です。
Sshポートを公開した特別なDockerイメージを準備する必要がありますか?それをもっと簡単に行う方法は?
更新:PyCharm 2017.1にはこの問題の解決策があります。これを参照してください ブログエントリ
ここに私が問題を解決した方法があります。私の状況では、docker-composeを使用して4つのコンテナのセットを作成するWebアプリの特定の領域に介入するように割り当てられました。 Docker-composeは、1つのコマンドから複数のdockerコンテナーを管理する一種のメタdockerです。多くのことがそれに依存しているので、既存のセットアップを壊したくありませんでした。しかし、イメージの1つの特定の部分で作業していたので、PyCharmからデバッグできるように、コンテナの1つをsshで拡張することにしました。さらに、起動時にアプリを通常どおり実行し、強制的に終了してからPyCharmからアプリに接続するだけで、デバッグ可能なコンポーネントが必要になります。これは、Macでboot2docker(VirtualBox上)を使用してdockerを正しくセットアップしたものです。
まず、jqworker
と呼ばれるターゲットコンテナを拡張する必要があります。 "supervisior"
を使用して、管理の面倒な作業を行います。
FROM jqworker
# Get supervisor to control multiple processes, sshd to allow connections.
# And supervisor-stdout allows us to send the output to the main docker output.
RUN apt-get update && apt-get install -y supervisor openssh-server python-pip \
&& pip install supervisor-stdout \
&& mkdir -p /var/run/sshd \
&& mkdir -p /var/log/supervisor \
&& mkdir -p /etc/supervisor/conf.d
COPY ./supervisord.conf /etc/supervisor/conf.d/supervisord.conf
# Fix up SSH, probably should rip this out in real deploy situations.
RUN echo 'root:soup4nuts' | chpasswd
RUN sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config
# SSH login fix. Otherwise user is kicked off after login
RUN sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd
ENV NOTVISIBLE "in users profile"
RUN echo "export VISIBLE=now" >> /etc/profile
# Expose SSH on 22, but this gets mapped to some other address.
EXPOSE 22
# Replace old entrypoint with supervisiord, starts both sshd and worker.py
ENTRYPOINT ["/usr/bin/supervisord"]
Supervisorを使用すると、1つのコマンド、この場合は元のコマンドとSSHDから複数のタスクを実行できます。はい、誰もがドッカーのSSHDは悪であり、コンテナはこれとそれと何とかするべきだと言いますが、プログラミングはコンテキストを無視するarbitrary意的なディクタに準拠するのではなく、問題を解決することです。コードをデバッグするためにSSHが必要であり、これをフィールドにデプロイしていないため、これをデプロイメント構造に追加する代わりに既存のコンテナーを拡張しています。コンテキストでコードをデバッグできるように、ローカルで実行しています。
以下にsupervisord.confファイルを示します。すべてを1か所で確認したいので、データを記録する代わりに、supervisor-stdoutパッケージを使用して出力をsupervisorに向けていることに注意してください。
[supervisord]
nodaemon=true
[program:sshd]
command=/usr/sbin/sshd -D
[program:worker]
command=python /opt/applications/myproject/worker.py -A args
directory=/opt/applications/myproject
stdout_events_enabled=true
stderr_events_enabled=true
[eventlistener:stdout]
command = supervisor_stdout
buffer_size = 100
events = PROCESS_LOG
result_handler = supervisor_stdout:event_handler
上記の2つのファイルを含むビルドディレクトリがあり、そこにあるターミナルからDockerfile
をビルドします。
docker build -t fgkrqworker .
これにより、docker
またはdocker-compose
から呼び出すことができるようになります。末尾のドットをスキップしないでください!
アプリはdocker-compose
を使用して一連のコンテナーを実行するため、既存のWORKER
コンテナーは問題を解決するものに置き換えられます。しかし、最初にdocker-compose.yml
の別の部分で、コンテナからローカルハードドライブへのマッピングを定義することを示したいと思います。これは、マッピングされる多くのボリュームの1つです。
volumes: &VOLUMES
? /Users/me/source/myproject:/opt/applications/myproject
次に、上記のVOLUMES
を参照する私のコンテナーの実際の定義:
jqworker: &WORKER
image: fgkrqworker
privileged: true
stdin_open: true
detach: true
tty: true
volumes:
<<: *VOLUMES
ports:
- "7722:22"
これは、SSHポートをVMで利用可能な既知のポートにマッピングします。VirtualBoxに乗るboot2docker
を使用していますが、PyCharmが到達できる場所にマッピングする必要があることを思い出してください。 VirtualBoxで、boot2docker
VMを開き、Adapter 1
を選択します。 「Attached to:」コンボ自体の選択が解除される場合があるため、注意してください。私の場合、NAT
を選択する必要があります。
[ポート転送]をクリックして、内部ポートをローカルホストのポートにマッピングします。同じポート番号を使用することを選択します。名前:ssh_mapped
;のようなものでなければなりません。プロトコル:TCP
;ホストIP:127.0.0.1
;ホストポート:7722
;ゲストIP :;ゲストポート:7722
。注:boot2dockerの「ssh」設定を変更しないように注意してください。変更しないと、最終的にVMを正しく起動できなくなります。
したがって、この時点で、ターゲットコンテナーを拡張するコンテナーがあります。ポート22でsshを実行し、他のコンテナーが22を使用する可能性があるため7722にマップし、VirtualBox環境で表示されます。 VirtualBoxは7722から7722をlocalhostにマップし、次のコマンドでコンテナーにsshできます。
ssh root@localhost -p 7722
これにより、パスワード「soup4nuts」の入力が求められ、コンテナ固有の何かを見つけて、それが正しいものであり、すべてが正常に機能することを確認できるはずです。ローカルマシン以外にこれを展開している場合、ルートを混乱させないため、警告が表示されます。 これはローカルでのデバッグ専用であり、ライブサイトでこれを行うことについて2回または3回考える必要があります。
この時点で、PyCharmのリモートデバッグを使用している場合、おそらく残りの部分を把握できます。しかし、ここで私はそれを設定する方法です:
まず、プロジェクトディレクトリをdocker-compose.yml
マッピングしていることを思い出してください。
? /Users/me/source/myproject:/opt/applications/myproject
コンテナ内の/opt/applications/myproject
は、実際にはローカルハードドライブ上の/Users/me/source/myproject
です。したがって、これが私のプロジェクトのルートです。私のPyCharmはこのディレクトリをプロジェクトルートと見なし、PyCharmに.pycharm_helpers
をここに書き込んで、セッション間で保持されるようにします。私は物事のMac側でソースコードを管理していますが、PyCharmはそれを他の場所でのUnixyボックスだと考えています。はい、JetBrainsにDockerソリューションが組み込まれるまでは少し面倒です。
まず、プロジェクトX /プロジェクト構造に移動し、ローカルマッピングのコンテンツルートを作成します。私の場合は、/Users/me/source/myproject
を意味します
後で戻って除外されたセットに.pycharm_helpers
を追加します。これがソース管理に陥ったり、PyCharmを混乱させたりするのは望ましくありません。
[ビルド]、[実行]、[展開]タブに移動し、[展開]を選択して、SFTPタイプの新しい展開を作成します。ホストはlocalhost、ポート7722、ルートパスは/opt/applications/myproject
、ユーザー名はroot
、パスワードはsoup4nuts
です。パスワードを保存するオプションをチェックしました。 Deploymentを「dockercompose」と名付け、後で選択できるようにしました。
[Deployment Mappings]タブで、ローカルパスを/Users/me/source/myproject
に設定し、デプロイメントとWebパスを単一の '/'に設定しますが、コードがURLに対応せず、これをデバッグに使用しないため、 Webパス設定のプレースホルダー。どのように設定するかわかりません。
Project X/Project Interpreterタブで、新しいリモートPython Interpreterを作成します。デプロイメント構成を選択し、上記で作成した「dockercompose」構成を選択できます。ホストURLは「ssh:// root @ localhost:7722」として入力する必要があり、Pythonインタープリターパスはおそらく/usr/bin/python
になります。デフォルトではコンテナがやり直されても存続しないため、PyCharmヘルパーパスを設定する必要があります。実際にプロジェクトのローカルディレクトリに移動し、ルートに.pycharm_helpers
ディレクトリを作成し、ここでパスを/opt/applications/myproject/.pycharm_helpers
として設定し、[OK]ボタンを押すと、ファイルをディレクトリにコピーしました。自動的に作成されるかどうかはわかりません。
.pycharm_helpers
ディレクトリは、おそらくプロジェクトの[ルート]タブで除外する必要があることを忘れないでください。
この時点で、[ビルド]、[実行]、[展開]タブに移動し、[コンソール/ Pythonコンソール]で、上記で作成したリモートインタープリターを選択し、作業ディレクトリを/opt/applications/myproject
に設定し、Python必要に応じて、コンテナ内のコンソール。
pythonコードをリモートでデバッグできるように、実行構成を作成する必要があります。新しいPython構成を作成し、スクリプトをコンテナ内のpythonコードの開始に使用したものに設定します。上記は、スーパーバイザーのセットアップからのものです。
/opt/applications/myproject/worker.py -A args
そこで、スクリプトを/opt/applications/myproject/worker.py
に設定し、パラメーターを-A args
に設定しました。
上記で作成したリモートインタープリターと、必要に応じて作業ディレクトリを選択します。私にとっては/opt/applications/myproject
であり、私にとってはこの作業を行います。
ここで、デバッグバージョンを起動できるように、コンテナーに入り、worker.pyスクリプトを停止します。もちろん、必要に応じて、デフォルトでスクリプトの実行を無視して、デバッグにのみコンテナを使用できます。
Sshセッションを開いてスクリプトを停止することもできますが、dockerには便利なコマンドが用意されており、それを環境に渡すことで作業を行うことができます。
$> docker exec -i -t supervisorctl stop worker
私のプロセスは「worker」という名前です。 stop
コマンドをstart
に置き換えることで再起動できることに注意してください。
ここで、PyCharmで上記で作成した実行構成でデバッグセッションを開始します。接続して起動し、ウィンドウにコンソール出力を表示します。 Supervisionが最初に開始したものを削除したため、接続されなくなりました。
これはズボンの操作の席だったので、私は気づかなかったエラーと間違った仮定があるかもしれません。特に、PyCharmのセットアップには数回の反復が必要だったため、順序が間違っている可能性があります。失敗した場合は再度試してください。これは多くのものであり、重要なものをスキップするのは簡単です。
ここにはまだありませんが、まもなくこれは問題になりません。
Dockerサポートは、PyCharm 4.1 EAP(4月から)からPyCharmで導入されます
必要なのがdockerコンテナー内で起動されるコードをデバッグすることだけであれば、pycharmの python debug server 機能を使用できます。私にとっては、SSH経由でリモートインタープリターにアクセスするよりも面倒ではありません。このソリューションの欠点は、オートコンプリートとこの種のすべての場合、コンテナのインタープリターのローカルコピーを持ち、プロジェクトのインタープリターとしてマークする必要があることです(オートコンプリートで動作しますが、コードをデバッグできるかどうかわかりませんそのような場合はサードパーティのライブラリ)、またはpycharmでコンテナのインタープリターファイルを表示できるようにします(まったくテストされていません)。また、Pythonデバッグサーバーは Professionalエディションの機能 です。
Python debug server:経由でデバッグするためにすべきこと
1)プロジェクトのディレクトリがコンテナに追加されていることを確認してください。 Dockerfileでは次の行のようになります。
ADD . /path/in/container
2)pycharm-debug.Egg
(Python3の場合は[pycharm-debug-py3k.Egg
)を、ホストのpycharmがインストールされているディレクトリから、コンテナのPYTHONPATHにあるコンテナのディレクトリにコピーします。開発者のホスト上のpycharm-debug.Eggへのパスは次のとおりです。
/Applications/PyCharm.app/Contents/pycharm-debug.Egg
/opt/pycharm/pycharm-debug.Egg
3)起動用の実行/デバッグ構成を作成しますPython docs のTo configure a remote debug server
セクションで説明されているホスト上のデバッグサーバー。ポートは任意のホストのポートです。ただし、IPはホストがコンテナからアクセスできるアドレスです。
ifconfig
で見つけることができます。私にとっては:docker0 Link encap:Ethernet HWaddr 56:84:7a:fe:97:99 inet addr:172.17.42.1 Bcast:0.0.0.0 Mask:255.255.0.0
また、開発者のホストでのプロジェクトのパスとコンテナでのプロジェクトのパスの間のパスマッピングを指定することを忘れないでください。
4)この作成された構成を起動します(たとえば、Debug
oneから直接Run
ボタンを使用)
5)pythonスクリプトを作成し、このスクリプトの最初の行としてデバッグ初期化のための次のコードを追加します。pycharm-debug.Egg
がPYTHONPATHまたはこのコードにあることを確認しますimport pydevd
)できませんでした:
import pydevd pydevd.settrace('172.17.42.1', suspend=False, port=8765, stdoutToServer=True, stderrToServer=True)
6)最後に、ブレークポイントを設定し、作成されたスクリプトを介してコンテナ内のホストからアプリケーションを起動できます。例えば:
docker-compose run 'container_name' python 'script_name' 'args'
起動時に、起動スクリプトはPythonホストで実行されているデバッグサーバーに接続し、ブレークポイントで停止します。デバッガー機能は通常どおり使用できます。
本当に必要な場合は、コンテナにSSHを含めるのはそれほど悪いことではないと思います。はい、docker exec
の導入以来、他のユースケースでは必須ではありませんが、Intellij/PyCharmはSSH経由のリモートインタープリターのみをサポートしているため、問題ありません。
phusion/baseimage
を出発点として使用して、SSHと任意のバージョンのPythonが必要です(PY3にデフォルトで付属)で独自のコンテナーを構築できます。
理論的には、Windows/OS Xマシン(boot2dockerを使用)とLinux(ネイティブDocker)の両方で動作するワークフローを作成できるため、このタスクにもVagrantを使用し続けることが理想的です。
実際には、SSHサービスに入るために二重のNATレイヤーを渡す必要があるため、OS Xで動作させることができませんでした。追加できないようですVagrant boot2dockerボックス(Vagrant 1.7.2)への追加インターフェース。
SSHオーバーヘッド(Dockerで完全に理にかなっている)を避けるために、 docker exec
が間違いなく道のりのようです。
残念ながら、今のところ機能させることができませんでした。誰かが空白を埋めることができたら素晴らしいと思います。これが私がしたことです(PyCharm 4.0.4およびDocker 1.4.1を使用):
次を含むpython_myproject.sh
という名前のファイルを作成します。
#!/bin/bash
docker exec -i myproject_container /path/to/containers/python2.7
ファイルの名前はpython
で始まらなければならないことに注意してください。そうでないとPyCharmが文句を言います。
PyCharmの設定のProject Interpreter
で、新しいローカルインタープリターを追加します。 python_myproject.sh
ファイルへのパスを指定します。
これは私が立ち往生しているところです。かなり長い読み込み時間の後(スロバは「ライブラリファイルのセットアップ」と言います)、「Invalid Python SDK」というタイトルのウィンドウが表示され、次のように表示されます。
python SDKを設定できません
/path/to/python_myproject.shで。
SDKは無効のようです。
~/.PyCharm40/system/log/.idea
::
2015-02-19 17:33:30,569 [ 166966] WARN - ution.process.OSProcessHandler - Cannot kill process tree. Trying to destroy process using Java API. Cmdline:
2015-02-19 17:34:30,628 [ 227025] WARN - ution.process.OSProcessHandler - Cannot kill process tree. Trying to destroy process using Java API. Cmdline:
2015-02-19 17:34:30,653 [ 227050] INFO - rains.python.sdk.PythonSdkType -
Timed out
PyCharm Professional Edition 2017.2に固有の手順(ただし、PyCharm CEで動作する可能性があります)
セットアップを機能させるために行ったいくつかの手順を次に示します
プロジェクト(またはこれを読んでいる人)の構造に関するいくつかの仮定:
bleh
├── README.md
├── api
│ ├── Dockerfile <---- this is the one we want to debug
│ ├── config.example.ini
│ └── src
│ ├── __init__.py <---- this is a pycharm project
│ ├── __main__.py <---- this is a pycharm project
│ └── ...
├── proxy
│ ├── Dockerfile
│ ├── config.example.ini
│ └── src
│ ├── ...
│ └── ...
├── webserver
│ ├── Dockerfile
│ ├── config.example.ini
│ └── src
│ ├── ...
│ └── ...
├── frontend
│ ├── Dockerfile
│ ├── config.example.ini
│ └── src
│ ├── ...
│ └── ...
├── db
│ ├── Dockerfile
│ ├── ...
│ └── migrations
│ ├── ...
│ └── ...
└── docker-compose.yml
bleh
を例としてのみ使用しています。/Users/myfunkyusername/Projects/bleh
であると仮定します。docker-compose.yml
に示すように、api
サービスをライブデバッグすることを想定します。ファイル注また、api
のコンテンツはDockerfile
のみであると想定します。
FROM python
ADD config.example.ini /etc/bleh/config.ini
RUN chmod +x /usr/bin/bleh
COPY ./src /usr/bin/bleh
WORKDIR /usr/bin/bleh
RUN pip install -r requirements.txt
CMD ["sh", "-c", "python -m bleh --cfg=/etc/bleh/config.ini"]
注唯一のdocker-compose.yml
にこれらのコンテンツがあると仮定しています
version: '2'
services:
api:
build:
context: ./api
depends_on:
- db
expose:
- "8080"
networks:
- default
frontend:
build:
context: ./frontend
ports:
- "80:7000"
networks:
- default
webserver:
build:
context: ./webserver
depends_on:
- frontend
networks:
- default
proxy:
build:
context: ./proxy
ports:
- "80:80"
- "443:443"
depends_on:
- webserver
- api
networks:
- default
db:
build:
context: ./db
expose:
- "3306"
networks:
- default
networks:
default:
driver: bridge
bleh
プロジェクト専用のdocker-machineを作成します
docker-machine create bleh
PyCharm
/Preferences
/Build, Execution, Deployment
/Docker
から+
をクリックしますDocker machine
ラジオボタンを選択し、プルダウンでbleh
のドッカーマシンを強調表示しますApply
を選択しますPyCharm
/Preferences
/Project:bleh
/Project Interpreter
からProject Interpreter
フィールドの右端にある歯車アイコンをクリックして、Add Remote
を選択しますDocker
オプションボタンを選択しますServer
フィールドで、このプロジェクト用に以前に作成されたドッカーマシンを選択しますbleh_api
)Python interpreter path
への変更は不要OK
をクリックしますRun
/Edit Configurations
から+
を選択して構成を追加しますPython
を選択しますScript
フィールドでは、実行されるdockerコンテナ上のスクリプトファイルの場所を使用します(この例では、ターゲットスクリプトの絶対場所を指定しているため、/usr/bin/bleh/__main__.py
です)Script parameters
フィールドで、もしあればCLIパラメーターを提供します(Dockerfile
の最後のCMD
コマンド、つまり--cfg=/etc/bleh/config.ini
を模倣します)Python Interpreter
フィールドで、以前に確立したリモートpythonインタープリターを選択しますWorking directory
フィールドで、Script
がDockerコンテナ内にあるディレクトリを選択します(例:/usr/bin/bleh
)Path mappings
フィールドで、...
をクリックし、上記のようにローカル(例:/Users/myfunkyusername/Projects/bleh/api/src
)とリモート(例:/usr/bin/bleh
)を選択しますDocker container settings
]フィールドで、[...
をクリックします。]bleh_api:latest
)Dockerfile
(8080/8080など)にあるものを模倣するポートバインディングコンテナ/ホストを追加し、tcp
プロトコルを使用して0.0.0.0
に公開しますnowアプリの構造を示していませんが、あなたが正気で、アプリ内でデータを提供するポートとして8080
も指定していると仮定しましょう。/usr/bin/bleh
//Users/myfunkyusername/Projects/bleh/api/src
Network mode
( thanks Piotr )が<name_of_project_directory>_<name_of_network_from_compose_file>
に設定されていることを確認します(例bleh_default
、正しいdocker network ls
内からdocker-machine
で確認できます。 _)これらは、正常に機能するドッカーとPyCharmのセットアップに至った手順です。
私はこれらの各ステップで正しいふりをしません。見つけたエラー/改善点は喜んで更新します。
これは試していませんが、 @ Anto's answer のように、docker exec ...
を呼び出すBashスクリプトを作成してみます。
次に、 BashSupport拡張機能 をインストールします。ここで 新しい実行構成を作成 これにより、スクリプトがBashスクリプトとして実行されます。
Docker 1.3では、exec
コマンドを使用してPythonインタープリターへのパスを作成します。
Sudo docker exec container_name /usr/bin/python
https://docs.docker.com/reference/commandline/cli/#exec 、 http://forum.jetbrains.com/thread/PyCharm-2224 を参照してください
コンテナー内にSSHをインストールしてからポートを公開することもできますが、コンテナーが膨れ上がるため、コンテナーの使用方法はそうではありません。
PyCharm 5では、dockerのサポートが追加されました。 docker-machineでdockerを構成する必要があります。
まだdocker-machineを使用していない場合は、汎用マシンエンジンを使用して既存のマシンに接続し、sagでvagrant VMまたはVMで実行していない場合はlocalhostに接続できます。残念ながら、ローカルホストへのsshを回避する方法は見つかりませんでした。
ボリュームを使用するDockerイメージにボリュームをマウントして、開発ツリーとファイルを共有する方法を見つけられませんでしたが、可能性があります。
Pycharmをコンテナにインストールし、そこから実行するだけで、少し夢中になります。 「docker run -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY =:0.0 pycharm-image」でこれを行う必要がありますが、正常に動作するはずです。しかし、pycharmとソースのすべてもそのコンテナにあることに注意してください。早めに頻繁に保存、コミット、プッシュしてください。