I rent a virtual server with Sakura VPS and run Gitlab on that server. Gitlab was launched with docker-compose by referring to the official document GitLab Docker images. Also, there was a convenient image of nginx-proxy for SSL support. I tried to use it and fought hard, but trying to fly directly from nginx-proxy to the puma server without going through internal nginx did not work, and currently Gitlab alone is in the form of launching. .. Since it is launched by itself, refer to Gitlab SSL Configuration (lets-encrypt-integration) internally. I am getting and renewing my SSL certificate. All of these are set so that they can be retained on the local host side by specifying the volume of docker-compose.
This time, it is not about these startup methods, but about communication between Docker containers.
Since I wanted to move CI with the operation of Gitlab, I decided to additionally operate Gitlab Runnner.
The basic installation was done according to the official document Run GitLab Runner in a container. Since I was a beginner of Docker, I thought that communication between containers should be on the same network in Docker, so as usual, docker network create --driver = bridge --subnet = subnet specification --gateway = I created a network with the specified network name of the gateway, and started Gitlab and Gitlab Runner on the same network.
If you look up inter-container communication, it probably means ping between localhosts, and I see many articles that say, "You can communicate if you put them in the same Docker network." However, Http communication to Gitlab that is open to the outside is played by someone and curl: (7) Failed to connect to gitlab.example.com port 443: No route to host and curl It didn't even come back.
It's embarrassing because I'm too new to Docker, but I was able to communicate between containers in this regard in a way that everyone might take for granted. I would like to leave that as a commandment.
Supplement In gitlab.example.com, DNS is suitable for the global IP of the host, and Curl etc. are returned without difficulty unless it is between containers.
As a result, it seemed to be played due to the firewall on the host side. Therefore, I found that it is necessary to make settings so that the firewall can pass through the network used in the Docker network.
this time. The newly created Docker network specifies 172.31.0.0/16 as the subnet. You can check the network with docker network inspect network name.
Therefore, I added a firewall rule for this subnet, thinking that I should pass through the network of 172.31.0.0/16, but it didn't work. Here is an article saying that you should add a rule for 172.0.0.0/8 (Docker --No route to host I found host)), so when I tried it honestly, I was able to communicate safely. Now you can communicate between Gitlab and Gitlab Runner, and you can register Runner.
The commands you hit are summarized below. If the subnet is 192.168. ~~, I think it would be nice to be able to break through that firewall. (I'm not sure)
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=172.0.0.0/8 accept'
sudo firewall-cmd --permanent --zone=public --add-masquerade
sudo firewall-cmd --reload
sudo less /etc/firewalld/zones/public.xml
>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="ssh"/>
<service name="dhcpv6-client"/>
<masquerade/>
<!--Good if this is added-->
<rule family="ipv4">
<source address="172.0.0.0/8"/>
<accept/>
</rule>
</zone>
I'm sorry for the dirty sentences that I'm not used to writing Qiita. Docker is too convenient and I try to do simple tests with Docker. Although I can use Gitlab Runner, I still haven't studied CI yet, so I would like to devote myself to it.
Please point out if something is wrong.
Recommended Posts