0

I have a Dockerfile that produces an image as a result of a multi-stage build. One of the steps produces a file (an sql migration script) that I would like to export and store somewhere outside of the build process, while I still want the build to produce the final image.

I was looking at the approach explained here How to copy files from host to Docker container?. It works well, but there is a couple of problems with it:

  1. It either produces the image or output the files.
  2. It only exports the files from the last stage. To limit the number of exported files, I can to use the scratch image, but that is not the final image I want to produce.
FROM scratch AS export
COPY --from=build /script.sql /

If I just copy the sql script into the finally produced (production) image, it will output all the build-produced files. And I also don't really want the script to be in the final image as it has no purpose there.

Is there any way how to do it? Feels silly to run two separated Dockerfiles to do the same build, one to generate the script and another to produce the image.

Vočko
  • 2,478
  • 1
  • 23
  • 31
  • Instead of trying to push the migrations into the database initialization, can you set up the application to run its own migrations at startup time, or run them by hand when required? (If the database schema changed, but you needed to preserve the existing data in the database, how would you address this; reinitializing the database from scratch wouldn't be a good choice?) – David Maze Jun 24 '22 at 09:58
  • I don't understand how this relates to the question. My problem is not applying the migrations, my problem is to get the file (artifacts in general) from the docker build process. All I want is a way to get some side products of the docker build to be preserved while still produce the intended image. – Vočko Jun 24 '22 at 10:05
  • I have reworded the first paragraph so it is clearer what I want to achieve. – Vočko Jun 24 '22 at 10:10
  • Extracting things from a built image is tricky and the question you link to is the best approach; it's often easier to generate things on the host. In the specific case of migrations, they often are checked into the same source tree as the application and it's common for a container to run them as part of its startup sequence. – David Maze Jun 24 '22 at 10:36
  • I understand this, my point is that the build to produce the artifacts (script) is the most expensive operation and because of this docker limitation, I have to do it twice within the pipeline. I don't want to/can't run migrations at startup for several reasons. – Vočko Jun 24 '22 at 11:05

0 Answers0