Docker is great to use, especially when it comes to DevOps practices. However, when you pull mirrors in China or locally, you often encounter various "constipation" - either the mirror pull is slow, or the connection is intermittent, or the connection times out!
When our images are large (like someone dropped a Warcraft package in the code), it's a nightmare! So how to solve this problem? Next, we mainly solve this problem from the following aspects:
- Using Mirror Accelerator
- change source
- Make the mirror yourself and push it to the domestic warehouse
- Build your own mirror warehouse near you
- Last Trick (Secret)
2. Mirror Accelerator
Accelerators can be used for playing online game cards, and mirror pulls generally have related accelerators. Domestic cloud manufacturers basically provide image accelerators:
Docker Hub Image Accelerator List
How to use Mirror Accelerator?
Docker Hub Image Accelerator Configuration
Linux systems can execute the following shells:
After configuration, you can use the "docker info" command to check whether it takes effect:
What about Windows 10? It can be configured on the interface as shown below:
Windows 10 configuration
3. Change the source
The accelerator is very cool to use, but in many cases, some images are not easy to use even if the accelerator is configured (may be related to the international bandwidth of the accelerator). At this time, the source must be changed. After all, the accelerator is not a panacea, especially when your mirror is relatively large. Then you have to find the right source.
For example, for the SDK image of .NET Core, we can use the image source of Azure China uniformly. As shown in the following table, we see that the domestic corresponding agent of "mcr.microsoft.com" is "mcr.azk8s.cn":
Therefore, we can use "mcr.azk8s.cn" instead of the official "mcr.microsoft.com" source:
# docker pull mcr.microsoft.com/dotnet/core/sdk:2.2-stretch docker pull mcr.azk8s.cn/dotnet/core/sdk:2.2-stretch
As shown in the above code, we replace the source of Azure International with the source of Azure China, and the speed of pulling packages will be very fast. The source has been changed, which means that we also need to modify the Dockerfile command:
#FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS build #Modified to Azure China mirror FROM mcr.azk8s.cn/dotnet/core/sdk:2.2-stretch AS build
4. Make the mirror yourself and push it to the domestic warehouse
The active person also said, what if there is no source? It can't be cold, can it? Then do it yourself. It can be built overseas based on GitHub hosting, Azure DevOps and Docker hub, and then push the image to the domestic image warehouse.
Related image label description
Then, just replace the source with your own in the Dockerfile and enjoy a quick takeoff:
#For instructions, see: https://github.com/xin-lai/aspnetcore-docker FROM ccr.ccs.tencentyun.com/magicodes/aspnetcore-runtime:2.2withfonts AS base
Here is a tip: using apt package under Linux is often very slow and unreliable, and sometimes it is not reliable to replace it with a domestic agent. At this time, you can consider using overseas builds to make mirrors.
5. Build the nearest mirror warehouse by yourself
The server bandwidth is not enough, and the local network is not good, what should I do? What else can you do, build your own warehouse. It is recommended to use nexus here. nexus can host various packages, including Docker, Nuget, Jar, npm, Bower, etc., so don't be too sharp. How to build? Yaml is often tested as follows:
apiVersion: apps/v1beta2 kind: Deployment metadata: labels: k8s-app: nexus name: nexus namespace: default spec: progressDeadlineSeconds: 600 replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: k8s-app: nexus strategy: type: Recreate template: metadata: labels: k8s-app: nexus spec: containers: - image: sonatype/nexus3 imagePullPolicy: IfNotPresent name: nexus resources: limits: cpu: "2" memory: 5024Mi requests: cpu: 10m memory: 256Mi volumeMounts: - mountPath: /nexus-data name: data restartPolicy: Always nodeName: k8s-node1 #Enforce constraints to schedule Pod s to specified Node nodes terminationGracePeriodSeconds: 30 #The time to wait when the Pod ends (in seconds) volumes: - name: data hostPath: #Use host directory path: /var/nexus hostNetwork: true --- apiVersion: v1 kind: Service metadata: name: nexus namespace: default spec: ports: - name: tcp-8081-8081 nodePort: 30081 port: 8081 protocol: TCP targetPort: 8081 - name: tcp-8082-8082 nodePort: 30082 port: 8082 protocol: TCP targetPort: 8082 - name: tcp-8083-8083 nodePort: 30083 port: 8083 protocol: TCP targetPort: 8083 - name: tcp-8084-8084 nodePort: 30084 port: 8084 protocol: TCP targetPort: 8084 - name: tcp-8085-8085 nodePort: 30085 port: 8085 protocol: TCP targetPort: 8085 - name: tcp-8086-8086 nodePort: 30086 port: 8086 protocol: TCP targetPort: 8086 selector: k8s-app: nexus sessionAffinity: None type: NodePort
Six, the last trick
If it doesn't work, copy it with a U disk. Don't say know me. Don't you believe it can be copied through a U disk? You can learn about the following two commands:
- docker save
- docker load