Точки останова в vscode (Win 10) «не проверены» и не попадают при удаленной отладке приложения Go в контейнере Linux Docker (Hyper-V) - PullRequest
0 голосов
/ 08 мая 2019

Я занимаюсь разработкой api-сервера Go (1.12.0), используя vscode (1.34.0, посвященный инсайдеру и стабильные сборки) для Windows 10. Исходный код находится на компьютере Windows в определенном% GOPATH%.Delve (dlv.exe - версия 1.2.0) также устанавливается в% GOPATH% \ bin, а% GOPATH% \ bin также находится в Windows% PATH%.

Приложение go затем создается в Docker.(Docker Desktop Version 2.0.0.3 (31259)) контейнер с docker-compose (так как некоторые другие службы, такие как база данных и веб-сервер, работают в других контейнерах).Последний двоичный файл приложения go затем копируется в контейнер Alpine-Linux вместе с исполняемым файлом delve, и сервер delve запускается в автономном режиме.Исходный код не копируется в контейнер Alpine-Linux, только двоичные файлы.

Мне не удалось правильно настроить удаленную отладку в vscode с помощью этой установки.Отладчик запускает мое приложение, но любые точки останова немедленно становятся серыми и становятся «непроверенными».Они также не выполняются при запуске приложения (сервера api).

Отладка с этой настройкой работает отлично (отладчик запускается, точки останова могут устанавливаться и срабатывать) при использовании IDE Goland из Jetbrains для удаленной отладки.

За последние пару дней я пытался найти решение, находя сообщения на форуме с похожими проблемами для отладки Chrome, отладки Node.js и т. Д. И этот пост на Go, а именно:

Удаленная отладка - непроверенная точка останова

Я также нашел этот пример конфигурации:

https://github.com/lukehoban/webapp-go/blob/debugging/.vscode/launch.json

Я думаю, что главная проблема, с которой я столкнулся, заключается в том, что нигдеМогу ли я найти какие-либо примеры того, как правильно установить путь к программе в launch.json для конфигурации удаленной отладки на компьютере с Windows (и при этом я не смог найти никакой документации, ссылающейся на это).Исходный код находится только на компьютере Windows в GOPATH, а не в конечном контейнере, в котором запускается приложение и delve (и это, опять же, прекрасно работает с отладчиком Goland)

Путь к моему проекту / структура каталогов (упрощенно):

%GOPATH%\github.com\myuser\project_dir\
   .vscode\
      launch.json
   cmd\
      my_api\
          main.go
      another_app\
          main.go
   package1\
      package1.go (this is where I am setting the breakpoint, this package is imported in cmd\my_api\main.go)
   Dockerfile
   ... (.gitignore, GoPkg etc.)

Моя текущая конфигурация launch.json (см. Некоторые варианты, которые я пробовал ниже)

launch.json - удаленная конфигурация

{
         "name": "RemoteDockerAPI",
         "type": "go",
         "request": "launch",
         "mode": "remote",
         "program": "${workspaceFolder}/cmd/my_api",
         "env": {},
         "args": [],
         "remotePath": "/my_api",
         "port": 40400, // Port 
         "host": "127.0.0.1", // Docker IP
         "showLog": true
}

Примечания: project_folder / cmd/ my_api - это место, где находится main.go для сервера api.Однако некоторые пакеты для этого приложения находятся непосредственно в папке проекта, т.е. project_folder / package1 / package1.go

Я пробовал только с

"program": "${workspaceFolder}",

и

"program": "${workspaceFolder}\\cmd\\my_api",

и

"program": "${workspaceFolder}/cmd/my_api",

и

"program": "${workspaceFolder}\\cmd\\my_api\\main.go",

и

"program": "${workspaceFolder}/cmd/my_api/main.go",

Я также попытался изменить это (без заметных изменений):

"remotePath": "/",

без успеха.

Мой многоэтапный Dockerfile для создания приложения и запуска delve в режиме без головы:

FROM golang:1.11.6-alpine3.9 AS builder

RUN wget -O /usr/bin/dep 'https://github.com/golang/dep/releases/download/v0.5.1/dep-linux-amd64' \
    && chmod +x /usr/bin/dep

# For debugging: conmpile Delve
RUN apk add --no-cache git
RUN go get github.com/derekparker/delve/cmd/dlv

# Copy Code and build it:
WORKDIR $GOPATH/src/github.com/myuser/my_api/
COPY Gopkg.toml Gopkg.lock ./
RUN dep ensure --vendor-only
COPY . ./

# Compile with necessary flags for delve
RUN CGO_ENABLED=0 GOOS=linux go build -gcflags "all=-N -l" -a -installsuffix nocgo -o /my_api ./cmd/my_api

FROM alpine:3.9 AS runtime-base

# DEBUGGING: Allow delve to run on Alpine based containers.
RUN apk add --no-cache libc6-compat

# App container
FROM runtime-base

WORKDIR /
# Copy certificates
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
# Copy app
COPY --from=builder /my_api ./
# Copy delve
COPY --from=builder /go/bin/dlv /

# 40400 for delve
EXPOSE 40400

CMD ["/dlv","--listen=:40400","--headless=true","--api-version=2", "exec", "./my_api"]

Я установил точку останова в одном изпакеты (не в project_dir / cmd / my_api / main.go, а, например, в project_dir / package1 / package1.go).Это становится серым и «непроверенным», как только я запускаю отладчик в vscode и точка останова не срабатывает.

Возможно, я делаю что-то не так на очень простом уровне, но я не могу понять,что.

ОБНОВЛЕНИЕ Я наконец-то нашел журнал отладчика и вижу это:

From client: setBreakpoints({"source":{"name":"package1.go","path":"c:\\Users\\myuser\\go\\src\\github.com\\githubaccount\\project_dir\\package1\\package1.go"},"lines":[165,170],"breakpoints":[{"line":165},{"line":170}],"sourceModified":false})
SetBreakPointsRequest
All cleared
Creating on: C:\Users\myuser\go\src\github.com\githubaccount\project_dir\package1\package1.go (C:/Users/myuser/go/src/github.com/githubaccount/project_dir/package1/package1.go) :165
Creating on: C:\Users\myuser\go\src\github.com\githubaccount\project_dir\package1\package1.go (C:/Users/myuser/go/src/github.com/githubaccount/project_dir/package1/package1.go) :170
Error on CreateBreakpoint: could not find C:/Users/myuser/go/src/github.com/githubaccount/project_dir/package1/package1.go:165
Error on CreateBreakpoint: could not find C:/Users/myuser/go/src/github.com/githubaccount/project_dir/package1/package1.go:170

Я не уверен, что это помогает мне действительно разобраться в проблеме с vscode, хотя,Может ли это быть ошибкой?Я нашел ссылку на старую ошибку MacOS:

https://github.com/Microsoft/vscode-go/issues/1859

и

https://github.com/go-delve/delve/issues/1282

, но они старые и исправлены (?).

За исключением того, что разделители пути Windows ("\") преобразуются в разделители пути Unix-стиля "/" с помощью vscode (?), Путь правильный, файл существует и строки для установкиточки останова находятся в середине файла (и правильно) ...

В vscode, если я нажимаю CTRL по пути, указанному в "не удалось найти ..." (превращается в ссылку с помощью vscode), он берет меня прямо к файлу (так что vscode может найти / увидеть его без проблем).

Это не вызывает проблем на хосте Windows (но только если вызывается из этого каталога):

%GOPATH%\...\project_dir\cmd\my_api\dlv debug -l 127.0.0.1:40400

и

(dlv) funcs any_function_in_package1 

находит эту функцию, поэтому (исходный) код кажется видимым для delve.

Установка точки останова, которую я хочу в Delve напрямую, также работает:

(dlv) break C:/Users/myuser/go/src/github.com/githubaccount/project_dir/package1/package1.go:170
Breakpoint 1 set at 0xad8dd8 for github.com/githubaccount/project_dir/package1.(*Struct).Function() C:/Users/myuser/go/src/github.com/githubaccount/project_dir/package1/package1.go:170

Путь в стиле Windows также работает в командной строке:

(dlv) break C:\Users\myuser\go\src\github.com\githubaccount\project_dir\package1\package1.go:170
Breakpoint 1 set at 0xad8dd8 for github.com/githubaccount/project_dir/package1.(*Struct).Function() C:/Users/myuser/go/src/github.com/githubaccount/project_dir/package1/package1.go:170

Это проблема типа пути Windows / Unix в vscode? Есть предложения?

ОБНОВЛЕНИЕ 2 Только что нашел этот отчет об ошибке в конце 2018 года, в котором описана похожая проблема между Delve и vscode:

https://github.com/bazelbuild/rules_go/issues/1844

Однако, как я писал выше, Delve, похоже, не испытывает проблем с передачей абсолютных (Windows) путей для точек останова в моем случае, поэтому я не уверен, что вышеупомянутая ошибка относится к этой ситуации? Кроме того, почему это работает в Delve напрямую, а не через vscode? Или это может быть проблема с путями Windows / Unix?

Спасибо за любую помощь!

1 Ответ

0 голосов
/ 09 мая 2019

Я наконец-то нашел отчет об ошибке по этому вопросу, так что на данный момент это открытая ошибка.Оставить это здесь для тех, кто ищет, так как эту ошибку было нелегко найти (по крайней мере, для меня).

...