feat(dockerfiles/products): add dockerfiles for history LTS versions

[wuhuizuo]

migrate from ci.git

Signed-off-by: wuhuizuo [email protected]

[wuhuizuo]

/hold

We can merge it before PingCAP-QE/ci#2958 take effect for a week.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

The pull request adds Dockerfiles for Long Term Support (LTS) versions of products. The changes can be summarized as follows:

1. In the skaffold.yaml file, the image tidb-base is split into two images tidb-base-old-amd64 and tidb-base-old-arm64. This suggests that separate images are now designed for different architectures: AMD64 and ARM64.

2. A new Dockerfile release-6.5.Dockerfile is introduced under tidb-base. The base images for AMD64 and ARM64 architectures are updated and necessary packages are installed.

3. New Dockerfiles are added under dockerfiles/products for both AMD64 and ARM64 architectures. Each Dockerfile corresponds to a specific product and includes instructions to build the Docker image for that product. These products include br, dm, dumpling, pd, ticdc, tidb, tidb-binlog, tidb-lightning, tiem, tikv and so on.

The potential problems that could arise include:

1. Dockerfile Best Practices: Some Dockerfiles do not follow Dockerfile best practices. For example, some RUN commands are used to install packages but do not clean up unnecessary files afterwards. This can lead to larger Docker images.

2. File Permissions: File permissions are not explicitly set for copied files. This can lead to issues if the Docker image is run by a non-root user.

3. No HEALTHCHECK Instruction: None of the Dockerfiles include a HEALTHCHECK instruction. This instruction tells Docker how to test a container to check that it is still working.

Fixing Suggestions:

1. Follow Dockerfile best practices: After installing packages with yum or apk, clean up unnecessary files with yum clean all or rm -rf /var/cache/apk/* to reduce the size of the Docker image.

2. Explicitly set file permissions: Use the chmod command to set appropriate permissions for copied files.

3. Add HEALTHCHECK instructions: Include a HEALTHCHECK instruction in each Dockerfile that specifies how to test the running container to check that it is still working as expected.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

This pull request mainly does the following:

1. Organizes Dockerfile paths and renames files for clarity.

2. Adds Dockerfiles for different products and versions, which will allow building Docker images for different architectures (amd64 and arm64) and different versions.

3. Modifies the skaffold.yaml to build Docker images for different platforms separately.

Here are some potential problems and suggestions:

1. There is no description about whether these Dockerfiles have been tested. It's recommended to add a testing process to ensure the Dockerfiles work as expected.

2. There is no problem with the Dockerfiles themselves, but the dependencies in the images need to be managed carefully. For example, the versions of the base images and the installed packages need to be managed to ensure consistency and security.

3. It's highly recommended to have a clear versioning strategy for these Docker images, which would make it easy to manage and track different versions of images. This could be done through tags in Docker image repositories.

4. It's also recommended to include health check scripts in the Dockerfiles to ensure the services are running properly in the containers.

5. For Dockerfiles that are similar except for architecture (amd64 or arm64), consider using build arguments to reduce duplication.

6. Make sure to follow best practices for writing Dockerfiles, such as minimizing the number of layers, not using sudo, etc.

Lastly, maintainers should ensure that these changes are necessary and align with the project's roadmap before merging. If these Dockerfiles are for development, they might be better suited in a separate directory or repository.

[wuhuizuo]

/approve
/unhold

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wuhuizuo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [wuhuizuo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment