Построение Docker-контейнеров для приложений golang без вызова go build - PullRequest
1 голос
/ 26 апреля 2019

Я создаю свой первый Dockerfile для приложения go, и я не понимаю, пока go build или go install считаются необходимой частью контейнера Docker.

Я знаю, что этого можно избежать с помощью muilt-stage, но я не знаю, почему он вообще был помещен в изображение контейнера.

Что бы я ожидал:

  • У меня есть приложение go 'go-awesome'

  • Я могу создать его локальноиз cmd / go-awesome

Мой Dockerfile содержит не намного больше, чем

COPY go-awesome.

CMD ["go-awesome "]

В чем недостаток этой конфигурации?Что я получаю, вместо этого делая

COPY.,

RUN go get. / ...

RUN go install ./..

Ссылки на сообщения, показывающие создание приложений go в составе Dockerfile

https://www.callicoder.com/docker-golang-image-container-example/

https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/

https://www.cloudreach.com/blog/containerize-this-golang-dockerfiles/

https://medium.com/travis-on-docker/how-to-dockerize-your-go-golang-app-542af15c27a2

1 Ответ

1 голос
/ 26 апреля 2019

Вы правы, что вы можете скомпилировать приложение локально и просто скопировать исполняемый файл в подходящий образ докера.

Тем не менее, есть преимущества при компиляции приложения в сборке Docker, особенно для крупных проектов с несколькими соавторами. В частности, на ум приходят следующие причины:

  • Для построения источника приложения не требуется никаких локальных зависимостей (кроме докера). Кому-то даже не нужно было идти идти установленным. Это особенно ценно для проектов, в которых используются несколько языков. Рассмотрим кого-то, кто может захотеть отредактировать шаблон HTML внутри проекта go и посмотреть, как это выглядит во время выполнения контейнера.
  • Среда сборки (версия go, управление зависимостями, пути к файлам ...) является постоянной. Любые внешние зависимости могут безопасно управляться и поддерживаться через Dockerfile.
...