Solved Why do we have to push an image to a registry?

[Lonkle]

When I build locally, I can run my apps.

Why can't I install and run an app after it's built locally using the Cloudron Build Service app (don't worry, I don't use my Cloudron for anything production, just development)? Instead it has to push it to a registry which takes a lot of time, and then install it locally? I just don't understand the registry part and why that step needs to even be taken?

I'm new to Docker, Cloudron, etc so I would like to know that. And if I can cut the "push" part out of my development flow it would save a lot of time, like I can do so locally.

[robi]

Good question, this is why I advocated for a local registry App and an all inclusive build App that includes a registry and everything needed to build and install an app.

[Lonkle]

@robi I feel as if with "sane" settings (expire images after a few hours), this could be integrated into the already existing Cloudron Build Service app very little storage overhead. What do you think?

[robi]

@Lonk exactly, it's temporary and changing often, no need to retain images since all changes are tracked in source.

[girish]

One needs to push the image only if your workflow involves building on one server and using the docker image in another cloudron/server. This is the workflow with @nebulon and i use. I guess we can adjust "cloudron build" to have a "cloudron build --no-push" or something? I am ok with this as long as it's explicit.

[Lonkle]

@girish said in Why do we have to push an image to a registry?:

cloudron build --no-push

That would be perfect and exactly what I was hoping for since I'm building the image in the Docker I'm updating / installing it on, I see no need for an extra push in there. I honestly love the cloudron build && cloudron update flow. And I'm looking forward to a cloudron update --no-push && cloudron update faster dev flow with the Cloudron Build Service being on the Cloudron instance itself.

[girish]

I am giving this a shot. Will update this post accordingly.

[Lonkle]

@girish said in Why do we have to push an image to a registry?:

I am giving this a shot. Will update this post accordingly.

I'm very grateful. I know helping developers on development servers can't be the top priority rn for you guys so anything like this is a godsend. Thank you!

Though I wanted to mention, the Build Service hasn't caused a single issue in any of my other apps despite it messing with Docker directly. It's pretty stable. I think my storage has gone down a little, so maybe some garbage collection logic is needed, but it's a very stable app.

[girish]

@Lonk I gave this a shot:

• First, update the CLI tool to 4.5.4
• Then, update build service app as well to 1.4.1
• Then, box code needs this patch.

Then, you have cloudron build --no-push && cloudron update. I tested this flow a bit, there are some "quirks":

• If you uninstall the app, the image will be removed.
• The build service app periodically removes images. It only keeps the latest image around and will also remove the image after 48 hours. BUT, if the image is in use by some app, it will be fine.
• Once all testing is done, once you are satisfied, you have to do a final "cloudron build" to actually pushes the images. This is only if you want to, of course.

I have to try it but I this flow is kind of nice because we don't keep pushing temporary/intermediate/junk images to the registry. In fact, the current flow only makes sense because docker registry is free for public images

[Lonkle]

@girish said in Why do we have to push an image to a registry?:

@Lonk I gave this a shot:

• First, update the CLI tool to 4.5.4
• Then, update build service app as well to 1.4.1
• Then, box code needs this patch.

Then, you have cloudron build --no-push && cloudron update. I tested this flow a bit, there are some "quirks":

• If you uninstall the app, the image will be removed.
• The build service app periodically removes images. It only keeps the latest image around and will also remove the image after 48 hours. BUT, if the image is in use by some app, it will be fine.
• Once all testing is done, once you are satisfied, you have to do a final "cloudron build" to actually pushes the images. This is only if you want to, of course.

I have to try it but I this flow is kind of nice because we don't keep pushing temporary/intermediate/junk images to the registry. In fact, the current flow only makes sense because docker registry is free for public images

Thank you so much! You're amazing; I'm no stranger to box patches and have to maintain my own anyway, so I'll throw that one in the mix (it's even in docker.js - my most patched file anyway.

I did personally feel like I wasted a lot of bandwidth when I'm just a developer who only wants to "push" when I'm finished with code. Not my "one line of code will fix this" kinda thing.

So, yeah, this is really cool for us that have a full development Cloudron setup strictly for development.

Will the box patch be integrated into an update or will this remain a patch for developers (since we're likely the only ones who know how to patch box).

[Lonkle]

@girish said in Why do we have to push an image to a registry?:

cloudron build --no-push && cloudron update

I applied, your box patch and upgraded the app + cli and it's so much faster now! Thank you thank you thank you!

[mehdi]

@Lonk said in Why do we have to push an image to a registry?:

Will the box patch be integrated into an update or will this remain a patch for developers (since we're likely the only ones who know how to patch box).

https://git.cloudron.io/cloudron/box/-/commit/546e38132510e29792323a9947ac7cdf9aa55c98

The patch is in a commit in the master branch, so it will be in the next release

[girish]

I moved the sysbox talk to the other topic, please keep the thread to a single topic. Otherwise, it's very hard to track discussions.

[Lonkle]

--no-push stopped working for me (it still builds, but doesn't skip the push). I checked the box patch and it's there. I checked the CLI tool and it still has the option. The Build Service Bot got more updates, was there an issue with the Bot. Can you reproduce this @girish with the latest Cloudron Build Service app?

[Lonkle]

I just checked and this is literally the only commit you made after v1.2.1 that could have broken this, it could be related if you can reproduce this at least. I'll try to roll back my Build Service Version in the meantime.

Oh, the commit that could have caused this: https://git.cloudron.io/cloudron/cloudron-build-service/-/commit/5012542ecd7d538a37fe8f84cfab096c588f0ac2

[Lonkle]

@girish I swear this --no-push feature worked perfectly for me until the Build Service got updated. Does it still work on your install (since we're both running on master rn - maybe it still works on stable, with the small patch, and it's a separate master issue - jus' wanna check)?

[girish]

I probably broke something with that latest commit you pointed out, I will check it.

[Lonkle]

The irony that that commit was called "Fix typoe"

[girish]

Hopefully, this should be fixed now. Update the build service app.

[Lonkle]

Just tested and it's fixed. You can mark this as solved. Thank you! ️

[yusf]

Does this mean that we can also host the Cloudron build service on production machines, or am I mistaken?

[robi]

@yusf no, that would be this scenario
https://forum.cloudron.io/post/16249

[Lonkle]

@yusf said in Why do we have to push an image to a registry?:

Does this mean that we can also host the Cloudron build service on production machines, or am I mistaken?

Well, I run it only on a dev machine since I only use Cloudron to dev. But tbh, after 100s of builds. All of the other apps are still running smoothly so it's not recommended because it's the only app with the docker add-on and thus could technically mess with other apps. It has never done so, I just think they'd rather not have the responsibility of calling it "production-ready" even though in my dev environment, it gives me no issues. I would feel comfortable running this in production tbh. The worry is if it ever bugged. But I can actually work around that by accounting for it using a Cloudron add-on I'm building (Dot the Repair Bot) so even though it's never happened, if I account for the Build Service being able to destroy containers / data outside it's sandbox (what the devs mean when they say it's not for production), I can have them auto-restored by Dot.

But if Dot got destroyed by the Build Service I'd be screwed.