Создавайте контейнеры для среды разработки и производства

Как вы создаете образы для разработки и производства (рой):

Я пытаюсь иметь один Dockerfile для обоих, чтобы сохранить «реализацию Dockerfile в одном месте», например наследование:

FROM golang AS gobase
ENV APP_ENV "pro"
COPY ./app /go/src/github.com/user/myProject/app
WORKDIR /go/src/github.com/user/myProject/app

RUN go get ./
RUN go build
EXPOSE 8080

FROM gobase AS godev

ENV APP_ENV "dev"

RUN go get github.com/pilu/fresh
RUN go-wrapper download
RUN go-wrapper install

CMD [ "fresh" ]

А затем используйте docker-compose.dev.yml и docker-compose.pro.yml

Например, для docker-compose.dev.yml:

version: '2'

services:
  godev:
    environment:
      - APP_ENV="dev"
    image: godev

Так что, во-первых, именование не работает.

Бонусный вопрос: как создать образ для производства — просто скомпилировать в один контейнер (запустить докер), а затем скопировать двоичный файл в новый контейнер?


docker docker-compose dockerfile docker-machine
person Chris G.    schedule 04.12.2017    source источник
comment
Я не понимаю, в чем ваш вопрос. Что вы имеете в виду, говоря, что название не работает?   -  person larsks    schedule 04.12.2017
comment
То, как вы передаете переменную среды в файле компоновки, даст ей это значение только во время выполнения. Если вы хотите обновить ENV во время сборки, вам нужно использовать ARG и --build-arg   -  person TJ Biddle    schedule 04.12.2017

Ответы (2)


arrow_upward
3
arrow_downward

Используйте dev не как имя, а как тег:

go:dev
go:prod

и ваш compose.yml:

services:
  go:
    image: go:dev

Бонус: взгляните на этот ответ в разделе " Отредактируйте 29/06/17" и используйте этот шаг сборки для обоих (dev и prod)

person Munchkin    schedule 04.12.2017

arrow_upward
0
arrow_downward

В основном вы должны выбрать один из этих вариантов:

  1. Как заявил Манчкин в своем ответе, используйте теги, чтобы различать prod и dev. Это должен быть ваш вариант, если вам действительно нужны разные вещи в контейнерах. НО обычно такого быть не должно. Обычно вы всегда хотите запускать контейнеры локально, в dev и в prod одним и тем же способом — это хорошая вещь в контейнерах! Если это работает локально, то будет работать и в dev, и в prod :)
  2. Старайтесь использовать одну и ту же сборку на каждом этапе. Конечно, могут быть отличия. Например, если у вас есть база данных, вы, вероятно, не хотите использовать производственную БД. Вместо этого настройте свои изображения с помощью переменных среды, чтобы они соответствовали различным конфигурациям ваших стадий. Так вы сведете к минимуму риски различных построек!

Если вы хотите узнать больше о том, как настроить образ докера, вы можете прочитать это: https://dantehranian.wordpress.com/2015/03/25/how-should-i-get-конфигурация-приложения-в-мои-докер-контейнеры/

person jonasheinisch    schedule 04.12.2017