1

How do you build images for development and for production(swarm):

I am trying to have one Dockerfile for both to keep "Dockerfile implementation in one place" like inheritance:

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" ]

And then use docker-compose.dev.yml & docker-compose.pro.yml

Like for docker-compose.dev.yml:

version: '2'

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

So first of all, the naming is not working.

Bonus question: how to you build an image for production - do you just compile in one container(docker run) and then copy the binary to a new container?

dom
  • 325
  • 2
  • 15
Chris G.
  • 23,930
  • 48
  • 177
  • 302
  • I'm not clear what your question is. What do you mean by "the naming is not working"? – larsks Dec 04 '17 at 13:34
  • The way you're passing the environment variable in your compose file will only give it that value during run time. If you want to update the `ENV` during the build, you need to use `ARG` and `--build-arg` – TJ Biddle Dec 04 '17 at 13:34

2 Answers2

3

Don't use dev as a name, but as a tag:

go:dev
go:prod

and your compose.yml:

services:
  go:
    image: go:dev

Bonus: Have a look at this answer under "Edit 29/06/17" and use this build step for both (dev and prod)

Munchkin
  • 4,528
  • 7
  • 45
  • 93
0

Basically you should take one of these options:

  1. As Munchkin stated in his answer use tags to distinguish between prod und dev. This should be your options if you really, really, really need different things in the containers. BUT this should usually not be the case. You typically always want to run the containers locally, in dev and in prod in the same way - this is the nice thing about containers! If it works locally, it will work in dev and in prod :)
  2. Try to use the exact same build in every stage. Of course there might be differences. For example if you have a database, you probably do not want to take the production DB. Instead make your images configurable with environment-variables to fit the different configurations of your stages. This is the way you minimize the risks of different stage-builds!

If you want to read further on how to configure a docker image, you might want to read this: https://dantehranian.wordpress.com/2015/03/25/how-should-i-get-application-configuration-into-my-docker-containers/

Jonas Heinisch
  • 363
  • 2
  • 12