Making GitLab Runner Work with an Insecure Private Registry
If GitLab Runner gives you the following error when preparing a pipeline job by downloading the correct image, then this means that your docker dameon isn’t correctly set up to work with your private docker registry:
ERROR: Preparation failed: Error response from daemon: http: server gave HTTP response to HTTPS client
To ensure that GitLab Runner can download images from your private docker repository without problems, you need to correctly configure the launch of your docker daemon to accept an insecure private registry.
Insecure registries are docker registries that cannot be used in combination with an SSL certificate, and where the connection is thus established over HTTP instead of HTTPS. Docker discourages the use of insecure registries due to the fact that login credentials and other potentially confidential data is sent over the wire in plaintext.
However, if you’re running your registry and your GitLab instance within the privacy of your own network, be that in your own company network or in a home LAN, then it does not matter too much if requests are sent in plaintext via HTTP, given that your network is sufficiently secured.
To ensure that the docker daemon accepts your private insecure registry, you need to pass the following option along as a launch parameter to the dameon:
To make this change permanent and make sure that it is applied when your system
reboots, this option is typically set with the
DOCKER_OPTS parameter in the
default docker daemon configuration file found unter
If docker is started via
systemd on your system, however, this file is
unfortunately ignored. Instead, the launch parameters need to passed in via the
docker daemon service file found under
apply the setting in here, make sure that in the
[Service] section your
ExecStart parameter is launching docker with the correct docker options.
You can set this explicitly as follows:
[Service] ExecStart=/usr/bin/docker -d --insecure-registry REGISTRY_IP:REGISTRY_PORT
After setting this be sure to
systemctl restart docker.service. After this,
relaunching your GitLab Runner and re-starting your pipeline job, the error
should be gone.