Closed KSAlpha closed 5 years ago
The overall direction seems good. I think we should delete (or at least prevent access to) configure_permissions
file because that is at a fixed location and may provide hints for a problem.
I forgot to tell Docker to remove that script! Edited Dockerfile
section :)
I figured out that image build API includes label setting parameters, which is considered to be a good alternative to set images label as it can reduce template rendering complexity.
How build
directory is handled in multi-config scenario? Maybe we should use the name of the configuration instead of static build
directory.
I think instantiating temporary folder per image (or sub configuration) can solve the problem. For now, I can't think of any drawback from this.
By the way, we should also consider multi-configuration scenario with same kind of subconfigurations (e.g. binary + binary, web + db + db). I will file an issue later related to this one.
Another question: if the value of public
attribute is different among configurations, what should we do?
For now, "any with exceptional rejection" seems nice to me. As public attribute has a default value of "false", setting public on any "true" value looks natural. However, if Soma detects explicit settings of both (i.e. explicit "true" and "false") we should reject it as it is apparently a bad configuration.
Or, enforcing all file entries' public attribute to be "true" or "false" seems to be a nice choice too.
Problem
Current implementation renders
Dockerfile
for build instruction and copies whole repository to temporary build context directory, which is considered inefficient in following conditions:.git
.dockerignore
.There are several 'easy' workarounds to resolve these issues, but I would like to suggest another design to generate Docker image build context.
New Design
Switching rendering subject
Current implementations of Soma renders all requirements into
Dockerfile
. However, we can render a shell script instead of adding severalRUN
instructions inDockerfile
. Following instructions can be substituted into one shell script:chmod
chown
Fully utilizing temporary directory
Soma is implemented to copy the whole repository (or problem) directory into temporary directory. However, we can construct a directory structure of the image beforehand. By constructing a image root filesystem in the temporary folder, we can reduce (file )adding steps into single instruction. Also, non-related files such as
.git
will be excluded naturally during the process.For example, simple-bof describes two files (
flag
,build/simple-bof
) to be included in/home/simple-bof
(i.e. default target path).Then, the temporary folder looks like the following:
Expected Changes
Current implementation
Dockerfile
:New Design
Dockerfile
:configure_permissions.sh