A method for optimizing image size based on container environment

Abstract

This paper proposes a method for optimizing image size in a container environment. The image processing container Ingress-nginx intercepts images matching the route according to the Lua script written in the orchestration file, then calls the cwebp command to convert the original image format to WebP format and return it to the user. This method realizes the generation of WebP images in the container environment, optimizes the image size, saves network resources, and reduces development and operation and maintenance costs.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular to a method for optimizing image size based on a container environment. Background Art

[0002] Today's internet environment is complex, and network link quality varies widely. Businesses expanding overseas face significant network challenges: high latency, slow transmission, high packet loss, and network jitter have severely impacted the business experience. Images are a crucial carrier of information in internet communication, so ensuring image transmission and loading speeds in weak network environments is crucial for improving the business experience.

[0003] There are two main approaches to optimizing image transmission: one is to compress the image to reduce its size while ensuring image quality, thereby reducing network transmission volume; the other is to place the image closer to the end user to reduce network latency.

[0004] As we all know, the most popular image formats currently are JPG, JPEG, and PNG. These formats are too large, resulting in excessive website bandwidth usage, slow transmission in weak network environments, slow website page loading speed, and reduced user experience. In addition, the image itself is in binary encoding format. Compressing the image not only consumes a lot of computing resources, but also has little compression effect.

[0005] Therefore, you can now reduce image size by using Google's WebP image format. WebP is not a new technology, having been announced at the Google / IO conference in 2010. However, due to browser compatibility issues, WebP has only become widely popular in recent years. WebP is a modern image format that provides superior lossless and lossy compression for images on the web, enabling webmasters and web developers to create smaller, richer images, making the web faster.

[0006] Compared to PNG, WebP lossless images are 26% smaller in size. At the same SSIM quality index, WebP lossy images are 25-34% smaller than comparable JPEG images.

[0007] Lossless WebP supports transparency (also known as alpha channel) at the cost of only 22% extra bytes. For situations where lossy RGB (Red, Green, Blue) compression is acceptable, lossy WebP also supports transparency and typically provides a file size 3 times smaller than PNG.

[0008] There are roughly four existing Webp implementation solutions:

[0009] 1) Use the image format conversion API provided by object storage (such as Alibaba Cloud OSS (Object Storage Service), Huawei Cloud OBS, etc.), specialized image processing platforms (such as imgix, imagekit, etc.), or network acceleration platforms (such as Cloudflare, etc.) to convert original format images into WebP format images;

[0010] 2) Integrate the WebP-compatible development language library through business applications to convert original format images into WebP-compatible images from a business perspective;

[0011] 3) Use a reverse proxy such as Nginx or Openresty to integrate Lua scripts to convert original format images into Webp format images;

[0012] 4) Use CDN (Content Distribution Network) combined with Function Compute to convert original format images into WebP format images, such as Cloudfront + Lambda;

[0013] Disadvantages of existing technology:

[0014] 1) There are certain limitations in generating Webp format images through image conversion APIs (Application Programming Interfaces) provided by object storage, proprietary image processing platforms, or network acceleration platforms. If implemented through the object storage API interface, the image storage location must first be placed in the object storage, which is highly invasive to the business and requires adapting the platform interface and introducing relevant SDKs. In addition, object storage cannot use the HTTPS protocol for communication with custom domain names and must be forcibly associated with a CDN. Using a dedicated image processing platform also has the problem of high business intrusion. Using a dedicated network acceleration platform (here referring to network service providers such as Cloudflare, which also provide CDN services, but platforms like Cloudflare require transferring domain name control to use their platform services. That is, the NS (Name Server) records of the existing domain name must be modified to their NS records before accessing their services) often requires transferring DNS (Domain Name System) server control and has an adaptation impact on the CDN accessed by the original business. There are also problems such as business intrusion and platform binding, which brings high adaptation costs to the subsequent migration platform.

[0015] 2) Integrating the development language library corresponding to WebP through business applications requires significant changes to the business, resulting in relatively high development costs.

[0016] 3) Integrating Lua scripts through a reverse proxy approach does not provide good support for containerized environments. It often only supports traditional virtual machine environments and lacks good support for cloud-native architectures.

[0017] 4) CDN combined with function computing does not provide good support for persistent storage. Often, expired images cached on the CDN or newly uploaded images need to be regenerated. Each generation requires function computing, which is relatively expensive and brings a lot of repetitive generation work.

[0018] In summary, existing WebP transformation solutions often require migrating backend storage or requiring a large amount of adaptation and transformation of existing businesses; existing WebP transformation solutions have certain limitations in supporting container environments.

[0019] To address the shortcomings of the existing technology, the present invention proposes a method for optimizing image size in a container environment. Ingress-nginx intercepts images matched by routes based on the Lua script written in the orchestration file, then calls the cwebp command to convert the original image format to a WebP format image and returns it to the user. The present invention implements the generation of WebP images in a container environment, optimizes the image size, saves network resources, and reduces development and operation and maintenance costs.

[0020] The present invention has the following advantages:

[0021] 1) Do not bind to any third-party platform to reduce the cost of development and adaptation and the cost of subsequent platform migration;

[0022] 2) Achieve zero business intrusion, eliminating the need to modify existing front-end and back-end business logic, thus reducing development costs;

[0023] 3) Supports deployment in containerized environments to meet cloud-native architecture requirements;

[0024] 4) Reduce website infrastructure costs and ensure that Webp format images are generated only once without the need for repeated generation. Summary of the Invention

[0025] To address the shortcomings of the existing technology, the present invention proposes a method for optimizing image size in a container environment. Ingress-nginx intercepts images matched by routes based on the Lua script written in the orchestration file, then calls the cwebp command to convert the original image format to a WebP format image and returns it to the user. The present invention implements the generation of WebP images in a container environment, optimizes the image size, saves network resources, and reduces development and operation and maintenance costs.

[0026] To achieve the above objectives, the present invention adopts the following technical solutions.

[0027] In an embodiment of the present invention, a method for optimizing image size in a container environment is proposed. The method includes the following steps:

[0028] S1 writes a Dockerfile to build an image processing container, Ingress-nginx, with image routing interception and WebP processing capabilities.

[0029] S2 writes the Ingress-nginx Helm Chart orchestration file so that the image processing container Ingress-nginx shares PVC storage with the backend business container. The Ingress orchestration file of the backend business container declares that the image processing container's controller is used as the ingress controller.

[0030] When an S3 user requests an image, it first arrives at the CDN. The CDN checks whether there is a cache for the requested image. If the CDN does not have a cache for the requested image, it sends the request to the origin server. The request is then passed through the Layer 4 load balancer to the image processing container, Ingress-nginx.

[0031] The S4 image processing container, Ingress-nginx, intercepts and processes images based on the routes configured by the Lua script. If the image processing route is matched and the client browser supports WebP format images, the Lua image processing logic is executed.

[0032] The S5 image processing container Ingress-nginx uses a Lua script to determine whether a WebP format image exists. If not, it calls cwebp to generate a WebP format image and returns it to the customer.

[0033] Furthermore, the PVC storage rebuilds the backend business system image by specifying the owner and group of the default running process of the business container, so that the image processing container and the business container have the same permissions for the same files.

[0034] Furthermore, the image processing container Ingress-nginx uses Lua scripts to configure three routing matching methods: default routing, original format image routing, and WebP format image routing.

[0035] Furthermore, the CDN adds the value of the HTTP request header ACCEPT as a cache key, which together with the URI forms a joint cache key, and caches multiple image formats for the same image URI according to different request Accepts.

[0036] Furthermore, the image processing container Ingress-nginx intercepts the image route and checks whether the image in Webp format exists. If so, it rewrites the URI of the user's original request and modifies it to a URI ending with the Webp suffix. It then jumps out of the current image processing route to match the route corresponding to the Webp image, and then returns the Webp format image to the user from the Ingress-nginx end.

[0037] Furthermore, the Ingress orchestration file of the business container refers to the orchestration file corresponding to the Ingress resource object of the backend business; the Ingress resource object is an abstract description of the Nginx configuration file, and finally the Ingress Controller is used to render the Ingress resource object and finally generate the corresponding Nginx configuration.

[0038] Furthermore, the Nginx configuration file includes a picture routing matching method written in Lua script, a call of the cwebp instruction, and a rewriting of the Webp format request URI.

[0039] The image processing container, Ingress-nginx, acts as the actual traffic proxy and executor of WebP image processing. When traffic enters the image processor, Ingress-nginx, the Ingress controller proxies routes that do not meet the WebP matching criteria to the backend business container.

[0040] Furthermore, the image processing container calls the cwebp command to convert the original image format to a Webp-formatted image. If the image conversion is successful, the URI of the user's original request is rewritten to a URI ending with the Webp suffix. The current image processing route is then jumped to match the route corresponding to the Webp image. The Webp-formatted image is then directly returned to the user from the Ingress-nginx end and the generated Webp-formatted image is stored in the mounted PVC storage.

[0041] The beneficial effect of the present invention is that, in response to the problems existing in existing communication systems, the present invention proposes a method for optimizing image size in a container environment. Ingress-nginx intercepts images matched by routes according to the Lua script written in the orchestration file, and then calls the cwebp command to convert the original image format into a Webp format image and return it to the user. The present invention realizes the generation of Webp images in a container environment, optimizes the image size, saves network resources, and reduces the cost of development and operation and maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0043] Figure 1 Schematic diagram of the process for implementing the present invention;

[0044] Figure 2 This is a diagram showing the relationship between components in a container environment according to the first embodiment of the present invention;

[0045] Figure 3 This is a logical diagram of image request processing in embodiment 1 of the present invention. DETAILED DESCRIPTION

[0046] To make the purpose, technical solutions and advantages of the embodiments of the present invention more clearly understood, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. The following examples are only used to more clearly illustrate the system method and technical solutions of the present invention, and are not intended to limit the scope of protection of this application.

[0047] According to an embodiment of the present invention, a method for optimizing image size in a container environment is proposed. Ingress-nginx intercepts images matched by routes according to the Lua script written in the orchestration file, and then calls the cwebp command to convert the original image format into a Webp format image and return it to the user. The present invention realizes the generation of Webp images in a container environment, optimizes the image size, saves network resources, and reduces development and operation and maintenance costs.

[0048] The principles and spirit of the present invention are explained in detail below with reference to several representative embodiments of the present invention.

[0049] Figure 1 This is a process flow diagram of a method for optimizing image size in a container environment. Figure 1As shown, the method includes the following steps:

[0050] S1 writes a Dockerfile to build an image processing container, Ingress-nginx, with image routing interception and WebP processing capabilities.

[0051] S2 writes the Ingress-nginx Helm Chart orchestration file so that the image processing container Ingress-nginx shares PVC storage with the backend business container. Write the Ingress orchestration file for the backend business container and declare that the image processing container's controller is used as the ingress controller.

[0052] The PVC storage rebuilds the backend business system image by specifying the owner and group of the default running process of the business container, so that the image processing container and the business container have the same permissions for the same files.

[0053] The Ingress orchestration file of the business container refers to the orchestration file corresponding to the Ingress resource object of the backend business; the Ingress resource object is an abstract description of the Nginx configuration file, and finally the Ingress resource object is rendered by the IngressController to finally generate the corresponding Nginx configuration.

[0054] The Nginx configuration file includes the image routing matching method written in Lua script, the calling of the cwebp instruction, and the rewriting of the Webp image request URI.

[0055] When an S3 user requests an image, it first arrives at the CDN. The CDN checks whether there is a cache for the requested image. If the CDN does not have a cache for the requested image, it sends the request to the origin server. The request is then passed through the Layer 4 load balancer to the image processing container, Ingress-nginx.

[0056] The CDN adds the value of the HTTP request header ACCEPT as a cache key, and together with the URI forms a joint cache key. According to different request Accepts, multiple image formats are cached for the same image URI.

[0057] The S4 image processing container, Ingress-nginx, intercepts and processes images based on the routes configured by the Lua script. If the image processing route is matched and the client browser supports WebP format images, the Lua image processing logic is executed.

[0058] The S5 image processing container Ingress-nginx uses a Lua script to determine whether a WebP format image exists. If not, it calls cwebp to generate a WebP format image and returns it to the customer.

[0059] The image processing container Ingress-nginx uses Lua scripts to configure three routing matching methods: default routing, original format image routing, and WebP format image routing.

[0060] During specific implementation, the image processing container Ingress-nginx intercepts the image route and checks whether a Webp format image exists. If so, it rewrites the URI of the user's original request and modifies it to a URI ending with the Webp suffix. It then jumps out of the current image processing route to match the route corresponding to the Webp image, and then returns the Webp format image to the user from the Ingress-nginx end.

[0061] The Ingress-nginx image processing container acts as the actual traffic proxy and executor of WebP image processing. When traffic enters the Ingress-nginx image processor, the Ingress-nginx controller proxies routes that do not meet the WebP matching criteria to the backend business container.

[0062] In specific implementation, the image processing container calls the cwebp command to convert the original image format to generate a Webp format image. If the image conversion is successful, it rewrites the URI of the user's original request to a URI ending with the Webp suffix. Then it jumps out of the current image processing route to match the route corresponding to the Webp image. The Webp format image is then directly returned to the user from the Ingress-nginx end and the generated Webp format image is stored in the mounted PVC storage.

[0063] It should be noted that although the operations of the method of the present invention are described in a specific order in the above embodiments and drawings, this does not require or imply that these operations must be performed in this specific order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0064] To more clearly explain the above-mentioned method for optimizing image size in a container environment, a specific embodiment is described below. However, it should be noted that this embodiment is only for better illustrating the present invention and does not constitute an improper limitation to the present invention.

[0065] Example 1:

[0066] A method for optimizing image size in a container environment. The specific implementation steps are as follows:

[0067] S1 writes a Dockerfile to build an image generation container with image routing interception and WebP processing capabilities.

[0068] Write the Dockerfile file. The base image references the image provided by Ingress-nginx. The WebP generation tool uses the cwebp provided by Google. Install the basic dependencies and compile and install them in the container.

[0069] The Ingress-nginx image does not have the ability to convert WebP images. The present invention encapsulates the WebP processing tool cwebp officially provided by Google through Dockerfile to build a unified image processing basic image that can have routing interception of business image traffic, Lua script interpretation and execution, and WebP format conversion functions.

[0070] The image generation container Ingress-nginx is Figure 2 Ingress-nginx pod in Figure 2 It shows the relationship between various components in the container environment. ELB in the figure is the load balancer.

[0071] S2 writes the Ingress-nginx Helm Chart orchestration file so that the image processing container and the backend business container share PVC storage. The Ingress orchestration file of the backend business container declares that the image processing container's controller is used as the ingress controller.

[0072] like Figure 2 As shown in the figure, the image processing container Ingress-nginx shares PVC storage with the backend business container.

[0073] The orchestration file mainly describes how to call the Kubernetes API in a declarative manner and creates related Kubernetes objects such as Ingress, Service, and Deployment, ultimately allowing the application to run in the manner expected by the orchestration file.

[0074] The official Ingress-nginx image does not have the ability to adjust the owner and group of running processes. This paper rebuilds the backend business system image by specifying the owner and group of the default running process, thereby ensuring that the image processing container Ingress-nginx pod and the business container have the same permissions for the same files.

[0075] The official Ingress-nginx image defines the default Nginx running user and user group as www-data, with the uid (user identifier), gid (group identifier), and groups all set to 33. Specifying a specific user to run the application is not supported unless the source code is recompiled, which is very troublesome. However, the backend business system processes run as other users with different uids and gids than the Nginx processes, which results in inconsistent permissions. If the Ingress-nginx Pod directly mounts the PVC of the backend business system, the www-data user has read-only permissions for the existing file directories and "others", and therefore has no permission to generate new Webp images. To avoid rebuilding the Ingress-nginx image from scratch, the www-data user must also be given write permissions to the file folders. During implementation, the original business system image is rearranged, specifying a user with uid and gid of 33 to run the business container, and changing the owner and group of the existing file folders to 33. In this way, the running user of the nginx process of the Ingress-nginx Pod has the same permissions as the process of the backend business system Pod, and the Ingress-nginx Pod can generate new Webp format images. We didn't use the Kubernetes API securityContext here because we already have millions of files. SecurityContext modifies file permissions at startup. Too many files would cause the Pod to be stuck in the Running state and unable to access traffic. We manually modified the array owner of historical files using chown (the Linux command chown is used to change the group and owner of a file). Even if the machine chown takes a long time, it does not affect the normal operation of the existing business system.

[0076] The present invention uses the mirror operation logic of Heml Chart orchestration to deploy the image processing container to the same namespace as the business container and mount the business's PVC storage, so that the image processing function container Ingress-nginx shares the backend file storage with the business container, and defines a separate Ingress Class, namely the Ingress-nginx instance (here Ingres-nginx is an instance we have encapsulated and rebuilt by the cwebp image processing tool, which is used to be independent of the Ingress-nginx instance used by the existing business. The use of our newly encapsulated Ingress-nginx instance through the kubernetes.io / ingress.class declaration of the Ingress orchestration file of the backend business file system can achieve no impact on the normal operation of other businesses.), avoiding affecting the previous business entrance; and specifying the load balancer attributes to be created by declarative means, automatically creating a load balancer (i.e. Figure 2 and connect the traffic to the image processing container.

[0077] The specific implementation method is as follows:

[0078] 1) Manually modify the owner and group of the business container through chown;

[0079] 2) Write the Ingress-nginx Helm Chart orchestration file so that the image processing container can mount the original business file system container PVC (Persistent Volume Claim) storage;

[0080] 3) Use the helm command to install the corresponding chart package in step 2. Install the image processing container and the current business container into the same namespace, because PVCs cannot be mounted across namespaces.

[0081] 4) Modify the business container Ingress orchestration file (this refers to the business system Pod orchestration file in the figure, which is used to orchestrate how the business system accesses traffic; the orchestration file in step 2 orchestrates how Ingress-Nginx runs) and use the previously deployed Helm Chart, which is the image processing container, as the ingress controller.

[0082] 5) Write routing logic in the Ingress orchestration file of the backend business container to match images in PNG, JPG, and JPEG formats. Write a Lua script in the Ingress orchestration file to intercept images matched by the route, generate WebP format images, and return them to the client.

[0083] The Ingress orchestration file of the business container refers to the orchestration file corresponding to the Ingress resource object of the backend business. This Ingress resource object is an abstract description of the Nginx configuration file. Finally, the Ingress resource object will be rendered by the IngressController to finally generate the corresponding Nginx (that is, Ingress-nginx) configuration.

[0084] The executor of the matching route is Ingress-nginx. However, this is not done by directly modifying the Ingress-nginx configuration file. Instead, the Ingress orchestration file of the backend business is modified. The Ingress resource object of the business container monitored by the Ingress-nginx controller changes. The final Nginx configuration file is then rendered based on the business container Ingress resource object, and the routing rules take effect.

[0085] The Nginx mentioned above refers to the Ingress-Nginx container. Ingress-nginx consists of two parts. One part is the Ingress-nginx controller, whose main function is to monitor Ingress object changes, render Nginx configurations, and call the Kubernetes API. The other part is Nginx, which mainly functions as a reverse proxy. Its main function is to expose container network services and route traffic to the actual business containers on the backend.

[0086] The routing logic of Lua matching is to match images, such as .png, .jpg or .

[0087] URI ending with jpeg.

[0088] Example:

[0089] location~*\.(png|jpe?g)${ ...

[0091] }

[0092] The present invention mainly configures three routing matching methods through the Ingress-nginx end:

[0093] A) Default route: When the request URI does not contain the PNG, JPG, or JPEG suffix, the default route is used to route traffic directly to the backend business storage system. This is primarily for compatibility purposes. The business storage system contains other file types such as doc, xlsx, and other file formats. To ensure that the image processing logic is transparent to the business, other types of traffic are directly allowed to the backend business system.

[0094] B) Original format image routing: When the request URI address contains the PNG, JPG, or JPEG suffix, traffic enters this route for image logic processing. If the original format image corresponding to the request URI exists and the Webp format image cannot be generated, this route directly returns the original request format image, preventing traffic from entering the backend business system and alleviating the pressure on the backend business system. If the original format image corresponding to the request URI exists, the corresponding Webp format image exists, or the corresponding Webp format image is successfully generated, this route rewrites the current request to the Webp suffix format URI and exits the current route.

[0095] C) WebP format image route: When the rewritten request URI jumps out of the original format image route, it will match this route and be used to directly return the WebP format image to the client.

[0096] When an S3 user requests an image, it first arrives at the CDN. The CDN checks whether there is a cache for the requested image. If there is no cache for the requested image on the CDN, the CDN sends the request to the origin server. The request is then passed to the Ingress-nginx server via the Layer 4 load balancer.

[0097] The process of processing user request pictures, such as Figure 3 As shown;

[0098] When a user requests an image, it first reaches the CDN. The CDN then checks whether there is a cache. If there is a cache, it determines the cache based on the cache key configured on the CDN. The cache key is based on the value of the AcceptHeader in the HTTP Header of the user's request. For resources with the same URI request, different categories are cached. If the Accept Header value of the request contains image / webp, the webp format image is returned to the user. If it does not contain image / webp, the original requested format image is returned to the user.

[0099] During specific implementation, modify the CDN cache key logic to cache multiple image formats for the same image URI based on the different Accept requests.

[0100] The default CDN cache key is a hash of the HTTP request URI value. For example, hash( / foo.jpg) yields bar, which corresponds to the specific resource associated with this URI. Modifying the cache key here primarily allows for caching different variations of the same URI to accommodate browsers that don't support WebP. In this embodiment, the primary modification is to add the value of the HTTP request header ACCEPT as the cache key, which together with the URI forms a combined cache key. More details are provided in the "Adapting to Different CDNs" section below.

[0101] The CDN does not have a cache for the requested image. At this point, the CDN sends a request to the origin server, which is then passed through the Layer 4 load balancer to the Ingress-nginx server.

[0102] S4Ingress-nginx intercepts and processes images based on the routes configured by the Lua script. If the image processing route is matched and the client browser supports WebP format images, the Lua image processing logic is entered.

[0103] The specific processing logic is as follows:

[0104] 1) Ingress-nginx intercepts the route based on the Lua script. If the URI (Uniform Resource Identifier) ​​suffix of the requested image does not match PNG, JPG, or JPEG, it directly matches the default route and routes the request to the backend file system (Tomcat container).

[0105] 2) If a route for image processing is matched, the server first checks whether the user's request header contains "image / webp". If not, the user's browser does not support WebP format images. Ingress-nginx then directly returns the image in the original requested format.

[0106] 3) If the user request header contains image / webp, and the user's browser supports WebP images, the Lua script's image processing logic will continue.

[0107] S5Ingress-nginx uses the Lua script to determine whether a WebP format image exists. If not, it calls cwebp to generate a WebP format image and returns it to the customer.

[0108] 1) The Lua script checks whether the requested image in original format or WebP format exists. If neither exists, the Ingress-nginx client returns an HTTP 404 status code.

[0109] 2) The Lua script continues to determine whether the Webp format image corresponding to the user's request exists (this is determined here using a custom function file_exists(name). file_exists(name) calls the io.open method provided by the LUA IO library. If io.open can read the file normally, it returns true to indicate that the file exists; otherwise, it returns false to indicate that the file does not exist). If so, Ingress-nginx rewrites the URI of the user's original request to a URI ending with the Webp suffix. It then exits the current image processing route, matches the route corresponding to the Webp image, and directly returns the Webp format image to the user from Ingress-nginx.

[0110] 3) If the WebP image does not exist, the cwebp command (a command-line tool provided by Google) is called to convert the original image format to a WebP image. If the image conversion is successful, the URI of the user's original request is rewritten to a URI ending with the WebP suffix. The current image processing route is then exited to match the route corresponding to the WebP image. The WebP image is then returned directly from Ingress-nginx to the user and the generated WebP image is stored in the mounted PVC storage.

[0111] The business system and Ingress-nginx jointly mount an NFS (Network File System) type PVC and define the access mode of the PVC as ReadWriteMany. In this way, both the business system Pod and the Ingress-nginx Pod can read and write to this mounted PVC simultaneously. This is equivalent to storing images in both the backend business Pod's file system and the Ingress-nginx Pod's file system, because both the Ingress-nginx Pod and the business system Pod are equivalent to mounting the same remote NFS server through the NFS client; for indexing, the default NFS indexing method is used.

[0112] 4) The cwebp command may fail. This can happen for several reasons. For example, when uploading images, the image extension may not be strictly specified to match the MIME type (Multipurpose Internet Mail Extensions). This can result in images with PNG, JPG, or JPEG extensions being uploaded, but the actual image type is GIF, which cwebp does not support. Alternatively, the image uploaded by the user may use the CMYK (Cyan Magenta Yellow Keyplate) color space for printers, but cwebp can only process images in the RGB color space. If the image format conversion fails, Ingress-nginx returns the original image to the user.

[0113] The beneficial effect of the present invention is that, in response to the problems existing in existing communication systems, a method for optimizing image size in a container environment is proposed. The image processing container Ingress-nginx intercepts images matched by routes according to the Lua script written in the orchestration file, and then calls the cwebp command to convert the original image format into a Webp format image and return it to the user. The present invention realizes the generation of Webp images in a container environment, optimizes the image size, saves network resources, and reduces the cost of development and operation and maintenance.

[0114] The applicant of the present invention has made a detailed explanation and description of the implementation examples of the present invention in conjunction with the drawings in the specification. The above implementation examples are only preferred implementation plans of the present invention. The detailed description is only to help readers better understand the spirit of the present invention, and it is not a limitation on the scope of protection of the present invention. On the contrary, any improvements or modifications based on the inventive spirit of the present invention should fall within the scope of protection of the present invention.

Claims

1. A method for optimizing image size in a container environment, characterized in that: The method comprises the following steps: S1 writes a Dockerfile to build an image processing container, Ingress-nginx, with image routing interception and WebP processing capabilities. S2 writes the Ingress-nginx Helm Chart orchestration file so that the image processing container Ingress-nginx shares PVC storage with the backend business container. The Ingress orchestration file of the backend business container declares that the image processing container's controller is used as the ingress controller. When an S3 user requests an image, it first arrives at the CDN. The CDN checks whether there is a cache for the requested image. If the CDN does not have a cache for the requested image, it sends the request to the origin server. The request is then passed through the Layer 4 load balancer to the image processing container, Ingress-nginx. The S4 image processing container, Ingress-nginx, intercepts and processes images based on the routes configured by the Lua script. If the image processing route is matched and the client browser supports WebP format images, the Lua image processing logic is executed. The S5 image processing container Ingress-nginx uses a Lua script to determine whether a WebP format image exists. If not, it calls cwebp to generate a WebP format image and returns it to the customer.

2. The method for optimizing image size in a container environment according to claim 1, characterized in that: The PVC storage rebuilds the backend business system image by specifying the owner and group of the default running process of the business container, so that the image processing container Ingress-nginx and the business container have the same permissions for the same files.

3. The method for optimizing image size in a container environment according to claim 1, characterized in that: The image processing container Ingress-nginx uses Lua scripts to configure three routing matching methods: default routing, original format image routing, and WebP format image routing.

4. The method for optimizing image size in a container environment according to claim 1, characterized in that: The CDN adds the value of the HTTP request header ACCEPT as a cache key, and together with the URI forms a joint cache key. According to different request Accepts, multiple image formats are cached for the same image URI.

5. The method for optimizing image size in a container environment according to claim 1, characterized in that: The image processing container Ingress-nginx intercepts the image route and checks whether a Webp format image exists. If so, it rewrites the URI of the user's original request and modifies it to a URI ending with the Webp suffix. It then jumps out of the current image processing route to match the route corresponding to the Webp image, and then returns the Webp format image to the user from the Ingress-nginx end.

6. The method for optimizing image size in a container environment according to claim 1, characterized in that: The Ingress orchestration file of the business container refers to the orchestration file corresponding to the Ingress resource object of the backend business; the Ingress resource object is an abstract description of the Nginx configuration file, and finally the Ingress Controller is used to render the Ingress resource object and finally generate the corresponding Nginx configuration.

Images