When deploying the site using a container image, do you need to install the runtime environment version separately?
Do you need to install the runtime environment version separately when deploying the site with a container image? There are two cases: when the program itself needs an interpreter to run, the runtime environment version still needs to be determined separately, but it is installed in the image instead of the host machine;The program is compiled with the runtime, the host does not need to install this layer, the image only needs to provide the system dependencies and configuration files. pxl.no distinguished two concepts when organizing the upgrade points of WordPress 7.2: ”7.2 still requires PHP 7.4 at minimum, but WordPress recommends PHP 8.3 or newer.“ The minimum version and the recommended version are not the same thing, both of these layers need to be confirmed at the image level.
First, distinguish between the minimum and recommended
The minimum version determines whether the program can start up, and the recommended version determines how well it runs and how much historical burden it carries. Only looking at the minimum version will fall into two pitfalls: you can't get the new version features and security fixes; many extensions and themes have already set compatibility scope according to the recommended version. The site can start up on the old baseline, but will report errors in specific functions.
In reverse, even looking at the recommended version may cause problems: the host machine has installed a new version, but the image is still fixed to the old baseline. When the two versions are mixed together, it is often the unfavorable one that takes effect in practice.
The order of changes on the host machine
In traditional deployment (Baota panel, LNMP and the like), the order of changes is 'first install the environment, then switch the site': first install the target running environment version on the host machine, use the version query command to confirm that it takes effect, then point the site to the new version, and finally verify item by item. Reversing the order can easily lead to an error state where the site has been switched, but the new environment is not ready.
The corresponding sequence for container deployment is 'first change the image, then rebuild the container':
- Modify the fixed runtime environment version in the image, or switch to a base image with a clearly marked version.
- Rebuild the image and push it to your own container registry, do not temporarily install it in the running container.
- Rebuild the container with a new image, keeping the location of the data volume and configuration files unchanged.
- Confirm that the version inside the container matches the expected version, and then check if the port mapping has been changed.
The runtime environment version on the host does not take effect inside the container, this is the most common misconception: the program inside the container only sees the layer provided by the image, so the act of 'installing separately' has not disappeared in the container scenario, but has simply moved from the host to the image.
What needs to be verified after the modification
The verification after version switching covers the parts directly affected by runtime behavior: form submission and comments, background login and permissions, file upload and thumbnail generation, email sending, scheduled tasks, as well as the rendering of critical front-page pages. Additional verification is required for multi-site and multi-language sites for the path and language jump after site switching, as these are often dependent on the time zone and character set settings of the environment layer.
AnQiCMS provides Docker image anqicms/anqicms, also supports Baota panel and LNMP common deployment methods, default listens on port 8001. When deploying with containers, the fixed base environment version in the image is the effective version, upgrading the site program does not mean upgrading the environment; conversely, changing the version on the host machine will not affect the running container.
The case does not require runtime.
The program itself compiles the runtime, thus saving this entire segment at the host level. AnQiCMS is developed based on GoLang, with a technology stack that includes GoLang, the Iris framework, and GORM. The compiled product can be run directly, and there is no need to install a language runtime separately on the host, nor is there the fixed overhead of 'having to apply security patches for the runtime itself'. The official statement is that memory usage is reduced by about 80% compared to PHP-like content systems, and the page loading speed is significantly improved compared to traditional PHP systems, with the ability to handle about 5 million PV on a single machine.
In this scenario, the image is still useful, but the division of labor is different: the image is responsible for providing the running directory, configuration files, and port conventions, but not for providing the interpreter. At this time, the version that needs to be checked is not the runtime version, but whether the program version and the configuration file match—the configuration items can be synchronized according to the update instructions when upgrading the program version.
Common questions
Will the fixed version in the image conflict with the host installed version?They will not overlap each other, the program in the container only reads the environment in the read-only image. Conflicts are usually manifested as: you think you have upgraded, but the container is still an old version, so you need to confirm in the container using the query command.
Can you only upgrade temporarily in the container?Can be used as an emergency measure, but changes after container rebuilding will be lost. The correct approach is to solidify the version into the image rebuilding, and temporary changes should be logged and recovered later.
Is there a problem with using the same image for multiple sites?There is no problem with sharing the program version. Configuration and data should be separated. If different sites depend on different environmental parameters (time zone, character set, upload limits), the images should be grouped by site to avoid changes affecting all sites.