web-dev-qa-db-ja.com

PyCharmをDockerコンテナ内にあるpythonインタープリターに接続する方法は?

私はDockerから始めていますが、コンテナーにあるpythonインタープリターを使用するようにPyCharmを構成する方法がわかりません。

Vagrantで設定するのは簡単でした ですが、 明らかにDockerでそれを行う公式の方法はありません です。

Sshポートを公開した特別なDockerイメージを準備する必要がありますか?それをもっと簡単に行う方法は?

35
trikoder_beta

更新: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のセットアップには数回の反復が必要だったため、順序が間違っている可能性があります。失敗した場合は再度試してください。これは多くのものであり、重要なものをスキップするのは簡単です。

12
Fran K.

ここにはまだありませんが、まもなくこれは問題になりません。

Dockerサポートは、PyCharm 4.1 EAP(4月から)からPyCharmで導入されます

ソース: http://blog.jetbrains.com/pycharm/2015/03/feature-spotlight-python-remote-development-with-pycharm/#comment-187772

3
noisy

必要なのが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へのパスは次のとおりです。

  • macの場合:/Applications/PyCharm.app/Contents/pycharm-debug.Egg
  • linuxの場合:/opt/pycharm/pycharm-debug.Egg

3)起動用の実行/デバッグ構成を作成しますPython docsTo configure a remote debug serverセクションで説明されているホスト上のデバッグサーバー。ポートは任意のホストのポートです。ただし、IPはホストがコンテナからアクセスできるアドレスです。

  • コンテナーがboot2dockerを介して実行される場合、IPは192.168.99.1である可能性が高い-vboxマシンを備えたホストオンリーネットワークのホストのアドレス
  • ホストがLinuxの場合、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ホストで実行されているデバッグサーバーに接続し、ブレークポイントで停止します。デバッガー機能は通常どおり使用できます。

2
3ka5_cat

本当に必要な場合は、コンテナに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)への追加インターフェース。

2
m1keil

SSHオーバーヘッド(Dockerで完全に理にかなっている)を避けるために、 docker exec が間違いなく道のりのようです。
残念ながら、今のところ機能させることができませんでした。誰かが空白を埋めることができたら素晴らしいと思います。これが私がしたことです(PyCharm 4.0.4およびDocker 1.4.1を使用):

  1. 次を含むpython_myproject.shという名前のファイルを作成します。

    #!/bin/bash
    docker exec -i myproject_container /path/to/containers/python2.7
    

    ファイルの名前はpythonで始まらなければならないことに注意してください。そうでないとPyCharmが文句を言います。

  2. 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
2
Anto

PyCharm Professional Edition 2017.2に固有の手順(ただし、PyCharm CEで動作する可能性があります)

セットアップを機能させるために行ったいくつかの手順を次に示します

ステップ1:環境

プロジェクト(またはこれを読んでいる人)の構造に関するいくつかの仮定:

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
    

ステップ2:Docker-Machineを作成する

blehプロジェクト専用のdocker-machineを作成します

docker-machine create bleh

ステップ3: リモートインタープリターを接続する

  • PyCharm/Preferences/Build, Execution, Deployment/Dockerから+をクリックします
  • Docker machineラジオボタンを選択し、プルダウンでblehのドッカーマシンを強調表示します
  • Applyを選択します
  • PyCharm/Preferences/Project:bleh/Project Interpreterから
  • Project Interpreterフィールドの右端にある歯車アイコンをクリックして、Add Remoteを選択します
  • Dockerオプションボタンを選択します
  • Serverフィールドで、このプロジェクト用に以前に作成されたドッカーマシンを選択します
  • 希望するpythonこのプロジェクトのインタープリターを保持するdockerイメージを選択します(例:bleh_api
  • Python interpreter pathへの変更は不要
  • OKをクリックします

ステップ4: リモートデバッガーの構成

  • 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 modethanks Piotr )が<name_of_project_directory>_<name_of_network_from_compose_file>に設定されていることを確認します(例bleh_default、正しいdocker network ls内からdocker-machineで確認できます。 _)

ステップ5:日光浴をしたり、もう少し頭を打ちましょう

これらは、正常に機能するドッカーとPyCharmのセットアップに至った手順です。

私はこれらの各ステップで正しいふりをしません。見つけたエラー/改善点は喜んで更新します。

1
Marc

これは試していませんが、 @ Anto's answer のように、docker exec ...を呼び出すBashスクリプトを作成してみます。

次に、 BashSupport拡張機能 をインストールします。ここで 新しい実行構成を作成 これにより、スクリプトがBashスクリプトとして実行されます。

0
taleinat

Docker 1.3では、execコマンドを使用してPythonインタープリターへのパスを作成します。

Sudo docker exec container_name /usr/bin/python

https://docs.docker.com/reference/commandline/cli/#exechttp://forum.jetbrains.com/thread/PyCharm-2224 を参照してください

コンテナー内にSSHをインストールしてからポートを公開することもできますが、コンテナーが膨れ上がるため、コンテナーの使用方法はそうではありません。

0
dukebody

PyCharm 5では、dockerのサポートが追加されました。 docker-machineでdockerを構成する必要があります。

まだdocker-machineを使用していない場合は、汎用マシンエンジンを使用して既存のマシンに接続し、sagでvagrant VMまたはVMで実行していない場合はlocalhostに接続できます。残念ながら、ローカルホストへのsshを回避する方法は見つかりませんでした。

ボリュームを使用するDockerイメージにボリュームをマウントして、開発ツリーとファイルを共有する方法を見つけられませんでしたが、可能性があります。

0

Pycharmをコンテナにインストールし、そこから実行するだけで、少し夢中になります。 「docker run -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY =:0.0 pycharm-image」でこれを行う必要がありますが、正常に動作するはずです。しかし、pycharmとソースのすべてもそのコンテナにあることに注意してください。早めに頻繁に保存、コミット、プッシュしてください。

0
grim