#Build image from another image without a registry

1 messages · Page 1 of 1 (latest)

remote apex
#

Just to check if I'm getting the "Dagger way" of doing things.

Reading other questions here on help I saw that via SDK (TS) I cannot use exportImage because it is considered a security issue. (I really wish that this was possible)

My expectation is to create a base image that has everything my app needs and save it to my current local images. This base image has its own Dockerfile.

Then I can build all my apps using this base image.

Each app has his own Dockerfile[prod|staging|misc] that is based on the base image (FROM BASEIMAGE:XX).

I got it that I can use a directory and read a dockerfile with dockerBuild and build a Container, but this only uses remotes images, If I try to reference a local image it fails.

So I'm imagining that the correct way is to build a container with the dockerBuild and copy my files for each app and retype all my Dockerfile commands with the withExec.

Since I can't at the moment publish the image to a registry (I'm not on company VPN to reach the registry or I don't have internet) and can't even reference a local image that I already have built on my machine the only solution is to retype all Dockerfile commands?

gusty jewel
# remote apex Just to check if I'm getting the "Dagger way" of doing things. Reading other qu...

👋

Reading other questions here on help I saw that via SDK (TS) I cannot use exportImage because it is considered a security issue. (I really wish that this was possible)

mind sharing where you got that? exportImage shouldn't be insecure AFAIK.

I got it that I can use a directory and read a dockerfile with dockerBuild and build a Container, but this only uses remotes images, If I try to reference a local image it fails.

Is there a hard requirement of keeping these Dockerfiles around? Mostly wondering if you thought about implementing this via the Dagger native way instead of trying to be backwards compatbile to what you currently have. It might be some more upfront work to ramp up but the solution is generally cleaner and more performant

If keeping with Dockerfiles is a must, one thing you can do is spawn a local registry along the Dagger engine within the same network namespace so that you can you can pull / push your Dockerfiles to that local registry.

remote apex
#

mind sharing where you got that? exportImage shouldn't be insecure AFAIK.

#1413378629995335690 message
#1413378629995335690 message

Is there a hard requirement of keeping these Dockerfiles around?

Kinda...

If I need to run a particular image in my system I have the recipe to do it.

I understand that codefying the Dockerfile gives way more power to what I can do with the process of creating the image/container.

We have a repo with the Dockerfiles that we use, and I can tell another coworker to grab that file and run on his machine.

Having the file Daggerized I will need to tell that person to install Dagger, to learn new commands etc.

It would be ok if everybody is using Dagger, but in a transition period or testing like I'm doing, I cannot force other people to stray from their current workflow and learn a lot of new concepts to run a container.

And if I Daggerized the Dockerfile it will get out of sync with the repo.

Would be great if the two options are on the table, run the Dockerfile if I needed or smartify the file with tools like withExec.

If keeping with Dockerfiles is a must, one thing you can do is spawn a local registry along the Dagger engine within the same network namespace so that you can pull / push your Dockerfiles to that local registry.

I don't quite understand this paragraph.

I think you meant to say "push/pull your Images to that local registry"?

Speaking about Dockerfiles, some Dockerfiles already reside on the current git project and others Dockerfiles on a centralized repo.

Speaking about Image Registry, I already have the default docker image registry on my local machine, why would I spawn another?

#

To not type too much things again.

To simplify, while I'm on this testing/convencing phase in my company.

I cannot go to people and say "we do this now", I need to adapt the tool to fit our current workflow.

And in our current workflow we need to build images local(on our dev notebook) or in staging/prod.

I need to get a Dockerfile that resides in another place, that people change often and use inside dagger to build an image, and run other things against that specific image.

I typed too much, if it's not clear feel free to ask more question.

remote apex
#

@gusty jewel sorry to ping you.
But any recommendation or remarks?

gusty jewel
#

⁠help⁠container.exportImage fails wit…
⁠help⁠container.exportImage fails wit…

this is fine. This doesn't mean that exportImage is insecure. I was mostly highlighting to the OP in that thread why exportImage works the way it works currently

#

I think you meant to say "push/pull your Images to that local registry"?

yes exactly

#

Speaking about Image Registry, I already have the default docker image registry on my local machine, why would I spawn another?

when you do a docker image ls that's not a compatible image registry per-se. It's Docker's internal image content store which is not standard across the OCI ecosystem. That's the reason of the stopgap I'm suggesting here for you to spawn an actual OCI registry so Dagger can use that to push/pull intermediate images to

#

I cannot go to people and say "we do this now", I need to adapt the tool to fit our current workflow.

yes, definitely. Let's find the way to make this work

#

@remote apex while you're working on your PoC @vital sand from our side is working on making this registry integration more transparent so you can spawn it within Dagger without your users having to perform any extra steps

remote apex
#

Great <o/

#

I'm really liking Dagger and I hoping that it spread like wild fire.

gusty jewel
remote apex
#

about 30~40

gusty jewel
#

awesome thx. Any other help you might need from us to help you show a really nice solution to your teams we're around 🙌

#

regarding the registry stopgap LMK if you need any help setting that up