Publish Docker containers using optimized composite R2R images #85358
Description
Based on the experiment
we believe we should be able to produce smaller .NET Docker containers with startup better than or on par with the default publishing mode. The technical description of this plan is to use full filtered R2R runtime+ASP.NET composite image (all runtime and ASP.NET assemblies are marked as components of the composite image but only the most important ones actually prejit the R2R code into the composite image).
Primary execution plan:
- Add support for building the full filtered runtime+ASP.NET composite containers
- (Corrected) Generate Full Composite Images of .NET and ASP.NET Bundled Together aspnetcore#41855
- Initial implementation of filtered full composite image aspnetcore#47085
- More precise CPU instruction set specification for ASP.NET composite aspnetcore#47207
- Apply MIBC optimization data when building ASP.NET composite aspnetcore#47333
- Workaround for ASP.NET composite image per #84860 aspnetcore#47747
- Exclude more problematic assemblies from the ASP.NET composite aspnetcore#47812
- Implement Dockerfile for producing the .NET container using the composite image
- Validate functionality of the filtered composite .NET container in Docker CI
- Enable performance tests for the composite images in Tech Empower
After we implemented build of the combined runtime + ASP.NET composite image and we started working on building the Docker container, we hit issues with the SDK repo where the dotnet app pins several assemblies to older versions for various legacy reasons, tracked under #84860.
In general, the overall composite technology design is based on the assumption that its components are always shipped / serviced as a whole - this simplyfing assumption lets us make JIT produce better code by inlining method calls, field offsets and other internal details of assemblies within the composite versioning bubble. The runtime + ASP.NET servicing story is quite complex involving a number of out-of-band assemblies that violate this principle.
In light of this fact we're now thinking that not all customers can benefit from the optimized composite technology and / or they might need to do extra work to adapt their products to be suitable for this technology; in other words that we should consider providing multiple container flavors useful for different groups of customers.
/cc @dotnet/crossgen-contrib