-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change the stack file structure #755
Comments
Agree that we're hitting the limits of our current build system. A better design would be compelling. One of the many limitations with our current stack.json is that it's an ad-hoc method not documented or used by any other projects. That makes it harder for other potential contributors to use or contribute. It feels like this should be reasonably well-established territory and an ad-hoc solution should not be necessary, but I haven't managed to stay up-to-date on this topic. Is the yaml structure above part of the modern buildx / bake system or just meant as an illustration of a more logical but still ad-hoc format? Maybe we can do a quick survey of possible options? Or has this area of 'devops for the development of devops' just remained a wild-west of ad-hoc solutions? |
This is completely ad hoc. I have rarely seen even a bake file (probably hcl is recommended over json) used in the first place. Inserting parameters into the Dockerfile can generally be done using args, or we can use a template engine such as jinja2. If we are moving to a simple configuration without ad-hoc stuff, bake files (much the same as the current ones) + templated Dockerfiles (perhaps using FROM ubuntu:{{ubuntu_version}}
COPY ...
RUN ...
... |
I'm all for a redesign of the current ad-hoc system with something that is more efficient in avoiding unnecessary rebuilds and easier for others to follow. Using a template framework for the Dockerfiles sounds good to me, I'm happy with jinja2 or whatever option your most familiar with if you're up for doing the heavy lift here! |
@cboettig I created a minimal example. (I wasn't sure whether to keep the repository personally or in this organization, but I decided to keep it as a personal repository for now. I can transfer it later.) |
@eitsupi This looks really cool. One thing I'd really like to see in the new build architecture is leveraging multi-stage build patterns for installations from source. It would be great to see that in the template design from the start. It may require us to rethink some things; e.g. maybe doing all these installs in |
@cboettig Added a sample of something like I do not know which directory to copy. (I do not understand which directories the installed R depends on). |
The structure I now consider to be prevailing is as follows:
This mechanism is fairly simple except for the process of calculating variables (now done in https://github.com/rocker-org/rocker-versioned2/blob/26c50e561ae4b10386b9f7adaa37a77b52f7f5d6/build/make-stacks.R). The drawback is that the Dockerfile must be written entirely by hand, and we have to allow for considerable duplication in the r-ver, rstudio, and tidyverse, for example, but it is acceptable given that the number is not that large. |
Right, this is where multistage builds get tricky. Apologies if this is all familiar already: In general, we are not going to be able to use the install from source recipes we have in unchanged form in multistage build. As you know, in a standard linux install, the application does not end up in any single directory. Binaries usually go (or are symlinked to) in
The multistage build setup for GDAL is a good example of this: https://github.com/OSGeo/gdal/blob/master/docker/ubuntu-full/Dockerfile , but really these are just conventions and each source build can be a bit different. I think compared to gdal, R is mostly pretty simple, but at very least in addition to copying R_HOME we must either symlink the binaries or update the PATH. |
Related to #736, #754
I think we are reaching our limits with the current structure of the stack file.
So what about changing completely to files that assumes the use of a template engine?
Something like the following:
Complex Dockerfiles could be represented as multi-line text, and simple parts could be represented as objects ordered by id.
(If a
type: script
is specified,COPY
andRUN
clauses are automatically generated for the Dockerfile.)At the moment, I don't think there is any shared use between Dockerfiles and bake files, so it might be better to separate the hierarchy for each.
@cboettig Thoughts?
The text was updated successfully, but these errors were encountered: