Buildpacks produce quite big image #288
Comments
|
ok, Readme recommends usage of but such faced then this issue: Not sure how to overcome this one yet. |
|
I'm using such version of which to my understanding is coming from here: which references this: which in turn references this: which has this: and such block: But I'm not familiar with such and how it leads to error in above comment |
|
Further analysis reveals such: so at least such explains where very old |
|
And for previously used |
|
@dmikusa - may you know if my observations here are correct and that |
|
The GCR registry is a legacy location for these builder images. We no longer post new images there. You can see a listing of all the the available builder images which are now hosted at DockerHub here: https://paketo.io/docs/reference/builders-reference/. |
|
@ryanmoran - I see, confirming that taken from DockerHub Would it be possible to update this repo's main Readme and add your note above about CGR registry as a legacy? |
|
Sorry about the bad docs there. Updated in this PR: #289 |
|
@dmikusa - based on all above discussion - I've switched now to use such builder image: and explicitly set but then hitting such error: Anything to check in such case? Based on current Readme - my understanding is that |
I believe this is a caching issue in the buildpack. You've gone from using the base stack to the tiny stack, which for Rust means you need to use musl (see the note in the README for why). That part is working. The buildpack is installing Rustup which is good, but then Rustup doesn't run because the layer is cached. That's a bug. I'll open an issue about this. What you can do to work around this is to clear the buildpack cache. If you run your next Thanks for all your feedback, btw! |
|
@dmikusa - as in my use case I'm executing not |
|
So I found that caches are basically presented in my case under here and after trying to play with cleanup - now I'm facing new issue with why it's not happy now about |
|
By default, it pack will store cached build information in volumes. In Docker you can You can also just change the name of your application/image. The cache is scoped to the application name, so if the name changes then it should be treated like a new fresh build. |
That is strange. The buildpack runs It's weird, even rustup is having trouble. It should print the version as well.
I'm not sure off-hand what might be causing that and it's hard to say without knowing more about your setup. I will say that builds are a little trickier on tiny because of using musl. You can try switching to the base stack and builder, which will work with gnu libc. |
I don't see any I could work on adding that if you could point me where |
Not a base image, sorry. I didn't explain that well. There are three variants of the stack and builder that Paketo publishes: tiny, base, and full. I was suggesting that you give the base image a try instead. Try switching to Another possibility is that you could be hitting an issue with the Jammy stack. There are some differences with the Jammy stack, security has been tightened down some. You may be hitting something there. If you want to try using |
|
Ok, culprit here seems in my attempt to set explicitly builder's setting And when it unset - this part of and that Readme says I need to use And when I have And when now Such size is near comparable to my direct Dockerfile approach, so probably could live for now with such, unless some other optimization possible. |
|
Additionally now tried with builder |
Ok, yes. I think that would cause the issue. This setting is for something different. It installs the underlying Rust tools compiled using musl libc, but that would require a base image that is also compatible with musl. The Paketo builder images use gnu libc, so that needs to stay as the default for Paketo builder images. That's why it can't run the binary because there's an incompatible libc (my understanding at least). What you want is to have the tools compiled against gnu libc so it's compatible with the Paketo builders but have a Rust target of musl installed. That will compile your application against musl libc.
OK, I know what's happening here. This is a Jammy thing. I've logged some issues to get this fixed. I think you can make this work if you do two things:
I think that will make cargo build the right target.
👍 Excellent. I don't think you'll end up with a smaller image using musl. That would statically compile in more code, so it would probably make the image a bit larger. The tiny image is about 22M, so you can see the rest is your app binary. Down the road, I want to add support for |
So if looking into this: i.e. some |
|
That is just the base layer from the run image. It looks a little weird but that is just because of the way the packages get installed and then copied into the final run image at build time. It happens like that because there are no tools to install packages in the run image, so you can't just run |
|
Let me rephrase - what is the purpose of that run layer within my final image if all I have is built static executable, which could run without anything in addition as shown at the beginning of this thread inside my Dockerfile? |
|
There are a few things that the buildpack spec requires, like the presence of user/groups so if you had a scratch image I don't think that would comply (probably would fail, I haven't tried) with the buildpacks launcher. That said, most of that is glibc, openssl, trusted tls certs, and timezone data. You may or may not need those for your app, but even for statically compiled Rust apps you might need TLS certs or timezone data. It all boils down to Paketo trying to provide a shared base image that many different apps can use. We don't add much to the tiny stack, but these things are pretty broadly applicable so they are in the tiny stack. There is a |
|
Just to add to what @dmikusa said, the goal of the static stack is to enable Buildpacks-compliant minimal images for statically-linked binaries. It's experimental at the moment, and we're looking for feedback. I would expect that a statically-linked, self-contained rust application should work on the static stack. If it doesn't, that's useful feedback and we'd appreciate you filing an issue with the error. |
|
@dmikusa - trying this advice:
and using overall build command in absence of static builder so far like such: leads to such error: If such is valid error and you think that it should be allowed to mix stack and runner - I'll then raise separate issue as I'm newbie here and not yet aware fully of what is allowed and what not. |
|
Ah, no, I don't think you can replace the run image from a builder with a stack with a different ID. I think this is an indication that we need to create a builder for the static image cc @ForestEckhardt |
|
@andrejusc we should be able to create a static builder for you in the next day or so. |
|
@ryanmoran - cool, will be waiting quietly for that then and will be your beta tester ;) |
|
Thanks @robdimsdale |
|
@andrejusc the static buildpackless builder has been released and you can use it directly as follows (using your command from earlier): |
|
@robdimsdale - trying that now: and getting such error: |
|
How were you specifying the buildpack in your command above? I just copied that command. I assumed you had specified the buildpack in some config file (e.g. If you aren't doing that, then you'll need to add the rust buildpack explicitly: |
|
@robdimsdale - ok, probably I've messed something. Retrying... So again with jammy base builder initially: and launching container out of produced image - works. Now doing exactly same, but with jammy static (just incrementing image tag to avoid cache reuse): and launching container ouf of produced image - leads to such error: Also worth mentioning - at least at the moment I could see both |
|
Ok, I'm confused now. I thought we were trying to get a statically-linked rust binary working via the static builder, so I'm confused as to why we expect I'm not familiar enough with the rust buildpack to know what start commands it creates for the app container, but if you got an app working with The reason why this app works on As far as the image size of the builder, I haven't explored that. I will note that both the tiny and the static images have the effectively the same |
|
@robdimsdale - if such output could be of any help to understand issue with static image. For base builder case: And for static: My Procfile is such: and I don't yet fully understand which part dictates to use shell as |
|
Oh, that's a Profile thing. The stack is different so it's not handling that right. Filed an enhancement request, paketo-buildpacks/procfile#175.
https://github.com/paketo-buildpacks/procfile#behavior You might not need a Procfile. Have you tried w/out? The cargo buildpack can inspect, it looks at your project targets, and usually set up process types automatically. |
|
@dmikusa -ok, removed Procfile if that is right now not suitable for But trying to launch container - getting now different error: Anything else I'm dong not right/not expected here? |
|
Do you have a sample app we can look at? I could make some guesses but it would be faster if we could iterate on it locally. Regardless, I'm not sure what is failing to be executed. Unless it's This bypasses the default process list and invokes |
|
@robdimsdale - so far no luck, tried proposed by you command: Attached is my use case. Unzip it into |
|
When I build with the command you've given: I get this error: Are you sure that you're building a static binary? When I try to build the sample app with a static binary, the build fails. Command: Output: Not sure if that's something with my local setup, Mac M1 creates some weird build issues occasionally. Anyway, you're going to need to make sure you manually set the target for the time being. In the future the buildpack can see you're running on the static stack and do that automatically. |
|
When I try to run the same command: On a linux machine, I get the following output: When I add a I get a different error: @dmikusa is Also, why is the buildpack trying to use And no packages with Also, I get the exact same error ( |
|
@dmikusa - if it could help by some means. On my Linux x86_64 box doing static Rust building directly without any buildpacks involved: and then checking output executable to make sure it's static: and such: So my expectation would be that using I'm not yet very deep into QEMU emulator usage on ARM64 for x86_64 purposes. Did in opposite way for one recent project, but still a lot to learn. |
|
Oh, cool. I learned something new today. I've only done static builds previously with musl. @andrejusc Can you try these arguments? That will pass through I'll log an issue to check if we can get a |
|
@robdimsdale Ohhhh, yes. That makes sense. Rust doesn't necessarily need |
|
@dmikusa - cool, appreciate all our collaboration here. So here is latest. Using such command in my case: and analyzing then built image: and size of it (which is now good enough): Could confirm that I could launch container out of it and it behaves as expected. I'm happy then to conclude all this long thread. Hope you've enjoyed it as well. Thank you for all your prompt help and comments @dmikusa @robdimsdale 👍 |
|
Woohoo! Glad it's working. Thanks for patiently working through this with us and all the feedback! |
|
Great, glad it's working. I was able to run the same command and build the app: I didn't validate that the binary is statically-linked, but given the stack doesn't have In terms of the size of the image, the breakdown is roughly:
The app is essentially the same size as when you pre-compiled and dropped it onto a scratch image, so that checks out. In order to be CNB-compliant you will need the launcher, so that's just overhead you can't avoid. So in reality there's only about 2MB more you can gain by dropping the timezone packages. As an aside, we could make a Regardless, I'm glad it's working. I'm glad we validated the static stack/builder, and I'm glad you are able to get an image size that you're satisfied with. I also learned some interesting stuff about static linking, which is a bonus! |
|
Hi folks, in case you're interested - I've published article in Medium where outcome of our discussion here (i.e. smaller image preparation for Rust use case) is used in bigger solution development picture: https://medium.com/@andrejusc/rust-code-as-serverless-function-and-evaluation-via-openshift-dev-sandbox-a9019d17ca47 . Hopefully that will further allow to evolve things. Thank you once again. |
|
@andrejusc FYI
You can set |
|
@dmikusa - appreciate extra feedback. |
Hi,
I'm comparing image I'm building directly with Docker file like such with Rust static executable inside it:
where I'm getting as output - image of about 14MB in size:
and layers:
And then I have image for same Rust function produced via buildpacks - about 107MB:
and layers in it:
What is the cause of such big difference? Any specific setting/config to tweak somewhere to make it smaller via buildpacks as well?
The text was updated successfully, but these errors were encountered: