Open drolfes opened 1 year ago
boukeversteegh
commented
1 year ago Hi Daniel! Thank you for reaching out. If there's any command you're missing, I'll be glad to help out or merge pull requests. At the moment I'm not working on adding features or improvements, but also willing to discuss ideas and accept PRs.
danielrolfes2307
commented
1 year ago @boukeversteegh I will drop my thoughts here. Hope its fine. If you feel like I should open separate "issues" for them, please let me know :) I'm currently struggling with two things.
I'm using "dockerized --build run ..." As far as I understand I'm currently not able to pass some "--build" parameters to this command (?) https://docs.docker.com/engine/reference/commandline/compose_build/ For example --no-cache and --pull would be quite nice for my workflow.
As far as I understand I'm currently not able to do an "only-build" execution instead of "build + run" (?) I have a local base image as dependency for my final image. If I execute "dockerized --build run ..." this will (obviously) be executed, while I would only need it to be built. Workaround is to use "docker compose build ...." instead, which leads to a mix of "dockerized" and "docker compose" - commands in my workflow.
How do you feel about these points? :)
Regards, Daniel
boukeversteegh
commented
1 year ago Interesting! Seems like useful flags/options to have. Out of curiosity, what is your use-case for this? Like an init step in a build process or something similar?
danielrolfes2307
commented
1 year ago @boukeversteegh I have some images where I use a local_base_image to copy things from. In my final_image Dockerfile I use: COPY --from local_base_image:latest .... In order to run final_image my base image local_base_image has to be built first.
So in my workflow (Makefile/make) I would need something like:
local_base_image: dockerized "only-build-but-do-not-run" local_base_image (currently I use: docker compose build --no-cache --pull ....)
final_image: local_base_image dockerized run final_image
Not sure if this is "out-of-scope" for dockerized though in terms of what its use-cases are. What do you think?
Regards, Daniel
boukeversteegh
commented
1 year ago @danielrolfes2307
I see, so the technical need for this feature is clear, but I'm not sure I understood the broader context. It seems that you're interested in using dockerized as a sort of build tool for docker-images, and that those docker images will then be distributed. Is the user of the image a server (deployment of an app) or a developer (a person / as part of a toolchain)?
The primary goal for dockerized is to help you install the required tools on your system, for a specific project or team, and to solve the discovery/reproducibility/versioning issues that come with that.
The approach with dockerized is to let you easily run a binary within a docker-container, as if it's running on your host system, and a way to specify versions per project.
This feature could also be applied to build artifacts (if that's what you're doing), and let developers easily run a specific version of a software project locally, through docker. It's a use case I haven't thought of, but it does seem in line with the original goal, if you would consider build artifacts as 'internal developer tools', which they often end up being.
I'm curious to know what approach you took before trying dockerized, and where you ran into limitations :-)
drolfes
commented
1 year ago @boukeversteegh Thanks for your valuable feedback :) After reading your comment and looking further into the Use Cases/Design goals of "dockerized": I guess my use case probably doesnt translate well for what the tool is mostly designed for.
My use-case is the following: I have a repo "developer-toolbox" with (bash) scripts I want to "dockerize" where the user is exclusively a developer. I like the idea of having a central docker-compose file where all my tools/scripts are declared. I also like the idea of having an .env file to populate environment variables. And that my current directory is automatically mounted into the container. That said I dont need "multiple" versions or project-specific docker-compose and dockerized.env files.
I also had to brush up my understanding of docker-compose I was under the impression that besides "docker compose up/down" to start a set of services / tools there wasnt a command to just run specific services. Turns out a docker compose run..." for specific services exist. Wasnt aware :P
As some of my tools (images) depend on other images I need to make sure that the other images exist before the tool (image) is built / started. As we use "make" in our projects already I tend to leverage it to manage these dependencies in the way I described in my other post.
I guess for my use case I could most probably (just) use docker compose run... and docker compose build respectively :) Or I fiddle around with "service profiles": https://docs.docker.com/compose/profiles/
Regards, Daniel
Hi, I stumbled over this wonderful project. Really like it so far, thanks :) Looking at the last update beeing in 2022 I was wondering, if this is still maintained / improved?
Regards, Daniel