November 1, 2018 | Author: Eduardo Enriquez

Python Debug en Docker: como usar pdb en docker con wdb y docker compose!

Estaba muy acostumbrado a debugear con mis queridos pdb.set_trace y de repente se apareció Docker en mi camino y perdí la posibilidad de attachearme al debugger. Probe varias alternativas como rpdb y winpdb o rpdb2 pero ningun tenia el autocompletado y el modo sticky de mi amado pdbpp. Por eso investigué un poco y descubrí WDB y funciona de maravilla.

wdb - Web Debugger

Bueno el repo es bastante explicativo y muestra todos los modos en que puede utilizarse: https://github.com/Kozea/wdb

Obviamente para debuggear en Docker necesitamos tener docker y podemos usar docker compose para hacer este este debug local. Para esto lo mejor, creo, es ver un ejemplo:

1) Primer paso: agregar la dependencia  wdb al requirements.txt  y buildear

$ echo 'wdb' >> requirements.txt
Copy

2) Segundo paso: agregar wdb como servicio en nuestro docker-compose. En este caso, por ejemplo donde tenemos django con postgres, agregamos un servicio más.

version: '3'
services:
  db:
    image: postgres
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "8000:8000"
    links:
      - db
      - wdb
    environment:
      WDB_SOCKET_SERVER: wdb
      WDB_NO_BROWSER_AUTO_OPEN: True
  wdb:
    image: kozea/wdb:3.2.5
    ports:
      - "1984:1984"Copy

3) Agregar los breakpoints:

# ... some code
import wdb; wdb.set_trace()Copy

4) Rebuildear y levantar de nuevo docker

$ docker-compose stop
$ docker-compose build web
$ docker-compose upCopy

5) Entrar al debug online:

http://localhost:1984/Copy

6) Usarlo

* .s or [Ctrl] + [↓] or [F11]    : Step into
* .n or [Ctrl] + [→] or [F10]    : Step over (Next)
* .r or [Ctrl] + [↑] or [F9]     : Step out (Return)
* .c or [Ctrl] + [←] or [F8]     : Continue
* .u or [F7]                     : Until (Next over loops)
* .j lineno                      : Jump to lineno (Must be at bottom frame and in the same function)
* .b arg                         : Set a session breakpoint, see below for what arg can be*
* .t arg                         : Set a temporary breakpoint, arg follow the same syntax as .b
* .z arg                         : Delete existing breakpoint
* .l                             : List active breakpoints
* .f                             : Echo all typed commands in the current debugging session
* .d expression                  : Dump the result of expression in a table
* .w expression                  : Watch expression in current file (Click on the name to remove)
* .q                             : Quit
* .h                             : Get some help
* .e                             : Toggle file edition mode
* .g                             : Clear prompt
* .i [mime/type;]expression      : Display the result in an embed, mime type is auto detected on linux and defaults to "text/html" otherwise
* iterable!sthg                  : If cutter is installed, executes cut(iterable).sthg
* expr >! file                   : Write the result of expr in file
* !< file                        : Eval the content of file
* [Enter]                        : Eval the current selected text in page, useful to eval code in the source
*
* * arg is using the following syntax:
*   [file/module][:lineno][#function][,condition]
* which means:
*   - [file]                    : Break if any line of `file` is executed
*   - [file]:lineno             : Break on `file` at `lineno`
*   - [file][:lineno],condition : Break on `file` at `lineno` if `condition` is True (ie: i == 10)
*   - [file]#function           : Break when inside `function` function
*
* File is always current file by default and you can also specify a module like `logging.config`Copy