目次
はじめに
こんにちは。
ディーネットの牛山です。
時は早いもので1月ももう少しとなりました。
インフルエンザなど流行しておりますが、皆さまいかがお過ごしでしょうか。
話は変わりますが、今回は、コンテナーオーケストレーションとして有名な「Kubernetes」のマネージドサービスであるAmazon Elastic Kubernetes Service (Amazon EKS)を使用してCI/CDツールであるgitlabをデプロイしてみたので紹介します。
本記事に全ての工程を掲載すると膨大な量となりますので、主要な部分のみのご紹介となること予めご了承ください。
構成イメージ
EKSを触る上で構成はイメージできておいたほうがいいと思いましたので、AWSワークショップより画像を引用させていただいております。
基本的にCloud9からEKSコントロールプレーンに対して指示していくことになります。
また、gitlabはコンテナーイメージとしてAmazon ECR上にpushし、Amazon EKSからpushしたイメージを指定し、展開される流れとなります。
Amazon EKSのデプロイ
Amazon EKSの作成は、以下、AWSワークショップ通りの手順となりますので割愛します。
途中のクラスターの確認箇所で、クラスターの確認が行えないところがありましたので以下のエラーが出た際には、「 aws eks update-kubeconfig
」のコマンドをお試し下さい。
- 該当エラー
kubectl cluster-info
E0121 11:21:44.233533 23919 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0121 11:21:44.234725 23919 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0121 11:21:44.235783 23919 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0121 11:21:44.238448 23919 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
E0121 11:21:44.240161 23919 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server localhost:8080 was refused - did you specify the right host or port?
-
- 該当手順箇所のリンクです。
マニフェスト作成
マニフェストを作成するまでの工程として、gitlabコンテナーイメージ作成・Amazon ECR等の作業が発生しますが、解説しきれませんので省略します。
試される際は代替イメージを各自で用意しお試し下さい。
cloud9上で gitlab
ディレクトリを作成し、コンテナーイメージ定義とELBの定義をそれぞれ書いていきます。
コンテナーイメージマニフェスト
クラスターIPやノードポートを定義しておりますが、今回は使用しませんので読み飛ばしていただいて構いません。
定義しているので使いたかったですが、筆者自身オンプレk8sになれてしまっており、うまくいきませんでした。
-
※ClusterIP
- クラスター内部で使えるアドレスとなります。
- ロードバランサーからクラスターIPを見にいく用途などで筆者は使ったりします。
-
※NodePort
- 各ノードでポートを公開する機能となります。
- ノードに対して、直接IPアドレスとポート指定でアクセスしたい場合等に使います。
kind: Pod
箇所でコンテナーを定義しており、labelsの機能を使用して、後に定義するELBから該当Podを見にいきます。
vi gitlab-almalinux.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
app: gitlab-almalinux-pod
name: gitlab-almalinux
spec:
restartPolicy: Always
containers:
- name: gitlab-almalinux
image: {AWSアカウントID}.dkr.ecr.{AWSリージョン}.amazonaws.com/gitlab:latest
imagePullPolicy: Always
resources:
requests:
memory: "2500Mi"
limits:
memory: "2500Mi"
---
apiVersion: v1
kind: Service
metadata:
name: gitlab-almalinux-service-node-port
spec:
selector:
app: gitlab-almalinux-pod
ports:
- name: ssh
protocol: TCP
port: 2024
nodePort: 30024
targetPort: 22
type: NodePort
---
apiVersion: v1
kind: Service
metadata:
name: gitlab-almalinux-service-clusterip
spec:
selector:
app: gitlab-almalinux-pod
ports:
- name: http
protocol: TCP
port: 8081
targetPort: 80
- name: http-supervisor
protocol: TCP
port: 9001
targetPort: 9001
ELB定義マニフェスト
CLBがデプロイされる定義内容となり、http接続でgitlabログイン画面にいき、9001ポートで、サービスコントロール画面に流れる内容となります。
コンテナー内部では、gitlabを80ポート、supervisorを9001ポートでlistenしている形となりますのでこのような定義となります。
vi gitlab-service-lb.yaml
apiVersion: v1
kind: Service
metadata:
name: gitlab-almalinux-service-ingress
spec:
type: LoadBalancer
selector:
app: gitlab-almalinux-pod
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80
- name: http-supervisor
protocol: TCP
port: 9001
targetPort: 9001
デプロイ
Pod
applyコマンドでデプロイが可能です。
デプロイ後、PodがRunning状態にあることを確認します。
kubectl apply -f gitlab-almalinux.yaml
pod/gitlab-almalinux created
service/gitlab-almalinux-service-node-port created
service/gitlab-almalinux-service-clusterip created
kubectl get po
NAME READY STATUS RESTARTS AGE
gitlab-almalinux 1/1 Running 0 2m11s
サービス
ELBデプロイ後、デプロイ状態を確認します。
Endpoints:
項目が none 状態になっていないことを確認します。
none 状態の場合、サービスが、該当のコンテナーを見つけられていませんので注意してください。
以下、記載の通り、IPアドレスが出ている状態が正常となります。
kubectl apply -f gitlab-service-lb.yaml
service/gitlab-almalinux-service-ingress created
kubectl describe svc gitlab-almalinux-service-ingress
Name: gitlab-almalinux-service-ingress
Namespace: default
Labels: <none>
Annotations: <none>
Selector: app=gitlab-almalinux-pod
Type: LoadBalancer
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.100.121.211
IPs: 10.100.121.211
LoadBalancer Ingress: ***.{AWSリージョン}.elb.amazonaws.com
Port: http 80/TCP
TargetPort: 80/TCP
NodePort: http 32602/TCP
Endpoints: 192.168.45.32:80
Port: http-supervisor 9001/TCP
TargetPort: 9001/TCP
NodePort: http-supervisor 32469/TCP
Endpoints: 192.168.45.32:9001
Session Affinity: None
External Traffic Policy: Cluster
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal EnsuringLoadBalancer 3s service-controller Ensuring load balancer
Normal EnsuredLoadBalancer 1s service-controller Ensured load balancer
動作確認
gitlabログイン画面
デプロイされたELBのDNS Aレコードにアクセスすると以下画面になりました。
supervisorコントロール画面
デプロイされたELBのDNS Aレコードに9001ポートを付けてアクセスします。
supervisorは常時起動させておきたいプロセスなど簡単にデーモン化できるツールとなり、1コンテナー1プロセスの都合上、こちらの管理ツールを使用し、複数プロセスを常時起動できるようにしています。
おわりに
EKSでこんなことできるよーという紹介でした。
gitlab の再現性は皆無ですが、マニフェストの書き方などで他の方の参考になれば幸いです。
プロフィール
AWSの設計・構築をメインにおこなっています。
運用・保守をおこなう部署におりましたが、最近、アーキテクト課に異動しました。
日々精進しております。
LINK
クラウドベリージャム:プロフィールページ