patterndockerMinor
Should we build our application inside a docker container, or copy it in?
Viewed 0 times
containerapplicationdockercopyshouldbuildourinside
Problem
I am dockerizing our applications to have the environments recreatable. As a process of dockerizing, we will be required to do the below steps:
Is it fine to have the application build, inside the docker, as part of docker building? In that way we need not install the build dependencies in local.
But the trade-off is, we have to build the complete docker for the even a small code change that we build. I understand this can be optimized to a level with multi-staged build.
- Build the application.
- Prepare the environment as the container.
- Deploy the application to the container.
Is it fine to have the application build, inside the docker, as part of docker building? In that way we need not install the build dependencies in local.
But the trade-off is, we have to build the complete docker for the even a small code change that we build. I understand this can be optimized to a level with multi-staged build.
Solution
I understand this can be optimized to a level with multi-staged build.
This is an understatement - you do not "optimize" that, but that's just the way you do it.
To answer your question: yes, by all means run the build inside a docker container. How else would you be sure that at build time every library or dependency is the same? There is no reason whatsoever not to do it.
Of course you need to pay a bit of attention when writing the Dockerfile. Ideally, whatever you change in your source code day-to-day, the only thing that happens when you re-run your build is the very last step of actually compiling your code and doing whatever it is you do with it afterwards (creating your deliverable archive...).
You need to use multi-staged builds afterwards to get rid of all the intermediate steps, and especially all the compile-time-only components (and it's pretty easy as well).
Note that there's usually some parts of your setup which are used by both the compile-time and run-time (unless you are just creating a .war file and sending that off to a webserver). I.e., if you have a ruby-on-rails application, the "ruby-on-rails" part could well be shared between compile-time and run-time. You want to make sure to put everything that is shared in this way very early in the process, and have a clean cut-off point that you can use as a
This is an understatement - you do not "optimize" that, but that's just the way you do it.
To answer your question: yes, by all means run the build inside a docker container. How else would you be sure that at build time every library or dependency is the same? There is no reason whatsoever not to do it.
Of course you need to pay a bit of attention when writing the Dockerfile. Ideally, whatever you change in your source code day-to-day, the only thing that happens when you re-run your build is the very last step of actually compiling your code and doing whatever it is you do with it afterwards (creating your deliverable archive...).
You need to use multi-staged builds afterwards to get rid of all the intermediate steps, and especially all the compile-time-only components (and it's pretty easy as well).
Note that there's usually some parts of your setup which are used by both the compile-time and run-time (unless you are just creating a .war file and sending that off to a webserver). I.e., if you have a ruby-on-rails application, the "ruby-on-rails" part could well be shared between compile-time and run-time. You want to make sure to put everything that is shared in this way very early in the process, and have a clean cut-off point that you can use as a
FROM later on, copying the compiled files in as needed.Context
StackExchange DevOps Q#5461, answer score: 2
Revisions (0)
No revisions yet.