When Docker is deployed, obtain the host’s CPU and other information from the container.

        Recently, when using go to develop the backend, there is a requirement. The developed service needs a license. Users need the license and the service to be valid at the same time before they can run the service. In fact, under normal circumstances, it is okay, but because When deploying, the customer may use docker deployment, so how to obtain the CPU information of the host machine in docker becomes a must, because the license needs to use the CPU information of the host machine, and you can also use the motherboard information or MAC information, etc. , this time we use the CPU serial number information for license binding.

        Let me first talk about my entire process. In the code, I first used the go language to obtain the CPU serial number information. I used the dmidecode command of Linux to obtain it. The command is as follows

[root@dmt ~]# dmidecode -t processor | grep ID | head -1
        ID: 57 06 05 00 FF FB 8B 0F
[root@dmt ~]#

Attached below is the code I use go to get the CPU serial number, which returns two parameters. The first is the string type data of the CPU serial number, and the second parameter is the error code data.

//获取CPUID函数
func GET_CPUID() (string, error) {
	cmd := exec.Command("/bin/sh", "-c", `dmidecode -t processor | grep ID | head -1`)
	stdout, err := cmd.StdoutPipe()
	if err != nil {
		fmt.Println("cmd.StdoutPipe: " + err.Error())
		return "", err
	}

	stderr, err := cmd.StderrPipe()
	if err != nil {
		fmt.Println("cmd.StderrPipe: ", err.Error())
		return "", err
	}

	if err := cmd.Start(); err != nil {
		fmt.Println("cmd.Start: ", err.Error())
		return "", err
	}

	bytesErr, err := ioutil.ReadAll(stderr)
	if err != nil {
		fmt.Println("ioutil.ReadAll stderr: ", err.Error())
		return "", err
	}

	if len(bytesErr) != 0 {
		fmt.Printf("stderr is not nil: %s", bytesErr)
		return "", errors.New(string(bytesErr))
	}

	bytes, err := ioutil.ReadAll(stdout)
	if err != nil {
		fmt.Println("ioutil.ReadAll stdout: ", err.Error())
		return "", err
	}

	if err := cmd.Wait(); err != nil {
		fmt.Println("cmd.Wait: ", err.Error())
		return "", err
	}
	cpuId := string(bytes)
	cpuId = strings.Replace(cpuId, "ID: ", "", -1)
	cpuId = strings.Replace(cpuId, "\t", "", -1)
	cpuId = strings.Replace(cpuId, "\n", "", -1)
	cpuId = strings.Replace(cpuId, " ", "-", -1)

	return cpuId, err
}

The calculation logic of the license is not convenient to be disclosed here, it is almost

Then after the development of my entire background service is completed, if it is deployed directly on the Linux host, there will be no problem, because the relevant information of the CPU can be obtained directly through the dmidecode command. If it is deployed with docker, it needs to be deployed with docker. Add the following content to the yml file.

version: '3.4'
services:
  pap:
    image: DOCKER_IMAGE
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - type: bind
        source: /usr/sbin/dmidecode
        target: /usr/sbin/dmidecode
      - type: bind
        source: /dev/mem
        target: /dev/mem
    privileged: true
    ports:
      - "8000:8000"
    restart:
          always

Among them, I removed all the codes related to my project. In fact, the most important ones are the following lines. I have made notes on the function of each line at the end.

  • Bind dmidecode. After binding, you can also access the dmidecode command in docker.
- type: bind
        source: /usr/sbin/dmidecode
        target: /usr/sbin/dmidecode
  • Bind /dev/mem. Binding this is because the dmidecode command needs to access /dev/mem, otherwise an error will be reported when calling dmidecode.
- type: bind
        source: /dev/mem
        target: /dev/mem
  • Set permissions, otherwise when accessing /dev/mem in docker, it will report insufficient permissions and permission deny.
 privileged: true

Then use the yml file with this information added to deploy docker, and the program can access the CPU information normally in docker.

Guess you like

Origin blog.csdn.net/u013896064/article/details/133174937