AWS で GitLab Runnerを動かしているのですが、いろいろ改善している話です。
dockerhub registry mirror
みなさんご存じの通り、 dockerhubは、anonymous pull に制限をかけました。CIで dockerhubのイメージを利用していると、すぐ制限にひっかかります。
また、近いほうがimage pull が速いということもあります。
そこで、 dockerhub registry の mirrorを設置しました。
詳細は Docker Registry | Docker Documentation を見ていただくとして。
AWSなので、ストレージにはS3を利用しています。 s3 を利用する際、
package manager
JAVA系を利用していると maven central からパッケージをダウンロードしてくることが多いのですが、 maven central には dockerhub同様 ダウンロード制限がかかっており、 CIで大量にダウンロードしていると、制限にひっかかります。
そこで、パッケージマネージャ Nexus Repository OSS - Software Component Management | Sonatype を利用しています。
maven centralのほかにも、よく使うものを mirrorしておくことで、安定した環境を用意しています。
vpc endpoint
ci runner 自体に外からアクセスする必要はまずないので、 private subnet に置いています。 すると、 s3 からデータを取得するたびに、nat-gatewayを経由することになり、AWS内通信なのに通信料がすごくかかる。
ということもあり s3 のvpc endpoint を設置しています。 上記 dockerhub registry mirror のほか、 AWS ECRからの image pull もs3 経由ですので、それなりに効果があります。
vpc endpoint service
GitLab Server と CI runner は、AWSの別アカウントで管理しています。そのため、 CI runner から GitLab Serverへの通信がやはり internet経由となりnat-gateway を経由しており、ここでも通信料がかさんでしまう状態なので
GitLab Serverを vpc endpoint service として別アカウントに公開できるようにし、 CI runner の動いているアカウントで vpc endpoint として 利用しています。
auto scale
CI runner については Autoscaling GitLab Runner on AWS EC2 | GitLab のドキュメントに従い、docker-machine によるSpot instance を利用した auto scale で動かしています。
終わりに
値段とスケーリング、速度に関して、改善を行っている現状を記載しました。
これからもいろんな状況に応じて、いろんな改善を行っていくつもりです。
