KitlabとHelmによるKubernetes CI／CDパイプラインの構築

7356 ワード
gitlab helm devops kubernetes テキストリンク
誰もがgitlab ciとkubernetesが大好きです.
Gitlab CI(連続積分)は、アプリケーションのために書くソフトウェア開発者を構築して、テストするための人気のあるツールです.Gitlab CIは、開発者は、より速く、より自信を持ってコードを構築し、迅速にエラーを検出することができます.
Kubernetesは、一般的にK 8 sに短縮、コンテナ化作業負荷とサービスを管理するための移植性、拡張性、オープンソースのプラットフォームです.K 8 Sはすべてのサイズの企業が展開、スケーリングを自動化し、コンテナ内のアプリケーションを管理するために毎日使用されます.
このポストの目的は、あなたがKubernetesにあなたのアプリケーションを展開することができるように、パズルの連続配信(CD)の部分にどのようにボルトをかけることができるかを示すことです.しかし、我々があまりに遠くに着く前に、我々はパズルの重要な部分であるヘルムについて話す必要がありそうです.

どのような舵?
Helm calls itself "the package manager for Kubernetes". それはかなり正確な説明です.ヘルムは、多彩な、頑丈なツールのdevfsエンジニアは、設定ファイルを定義するために使用することができますし、我々のクラスタに一貫した展開を作成する変数の置換を実行し、異なる環境の異なる変数を持っている.
それは確かに我々がここでカバーしている問題への正しい解決です.

どうやってやるの?
最初に、いくつかの前提条件.あなたがプロジェクトを開始する前に、このすべてのハンマーを持っている必要があります.助けが必要な場合は以下の参考文献へのリンクがあります.
  • あなたは既にAmazon EKS cluster .
  • あなたは既に使用方法を知っているGitLab CI .
  • あなたはGitLab CI runner あなたのKubernetesクラスタで構成されます.
  • あなたはAWS Load Balancer Controller クラスタでの実行
    • それらのボックスをチェックして、我々は始めることができます.この例で使用するには、まずGitlabで新しいリポジトリを作成します.したら、私たちは私たちのファイルを作成することから始めることができます.

    ファイルツリー
    基本的に最後に、フォルダ/ファイルの構造は次のようになります.
    <dir>
├── chart/
|   ├── Chart.yaml
|   ├── values.yaml
|   └── templates/
|      ├── deployment.yaml
|      ├── service.yaml
|      ├── ingress.yaml
|      └── configmap.yaml
└── gitlab-ci.yml

    値.ヤル
    applicationName: my-first-app
certArn: your-certificate-arn
domain: your domain name
subnets: your subnets
securityGroups: your security groups

    展開.ヤル
    apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.applicationName }}
  namespace: {{ .Values.applicationName  }}
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: {{ .Values.applicationName }}
  template:
    metadata:
      labels:
        app: {{ .Values.applicationName  }}
    spec:
      containers:
        - name: {{ .Values.applicationName }}
          imagePullPolicy: Always
          image: nginx:1.19.4
          ports:
            - containerPort: 80
          volumeMounts:
            - mountPath: /usr/share/nginx/html/index.html
              name: nginx-conf
              subPath: index.html
      volumes:
        - name: nginx-conf
          configMap:
            name: {{ .Values.applicationName  }}-configmap
    これは、配置を定義する設定ファイルです.いくつかの行があることがわかります{{ some text }} . これは、グラフ内の値ファイルで定義する変数を使用する方法です.

    設定マップ.ヤル
    apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Values.applicationName }}-configmap
  namespace: {{ .Values.applicationName }}
data:
  index.html: |
    <html>
    <head>
      <h1>My first Helm deployment!</h1>
    </head>
    <body>
      <p>Thanks for checking out my first Helm deployment.</p>
    </body>
    </html>
    この設定マップは、我々のアプリのために表示される単純なインデックスページを定義します.

    サービスヤル
    apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.applicationName }}
  namespace: {{ .Values.applicationName }}
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      name: {{ .Values.applicationName }}
    - port: 80
      targetPort: 80
      protocol: TCP
      name: {{ .Values.applicationName }}
  type: NodePort
  selector:
    app: {{ .Values.applicationName }}

    インドレスヤル
    apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ .Values.applicationName }}
  namespace: {{ .Values.applicationName }}
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/subnets: {{ .Values.subnets }}
    alb.ingress.kubernetes.io/healthcheck-path: /
    alb.ingress.kubernetes.io/security-groups: {{ .Values.securityGroups }}
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/certificate-arn:  {{ .Values.certArn }}
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
spec:
  rules:
    - host: {{ .Values.applicationName }}.{{ .Values.domain }}
      http:
        paths:
        - path: /*
          backend:
            serviceName: ssl-redirect
            servicePort: use-annotation
        - path: /*
          backend:
            serviceName: {{ .Values.applicationName }}
            servicePort: 80

    Gitlab CI気象研
    stages:
  - deploy

variables:
  DOCKER_HOST: tcp://localhost:2375/
  DOCKER_DRIVER: overlay2
  APP_NAME: my-first-app

deploy:
  stage: deploy
  image: alpine/helm:3.2.1
  script:
    - helm upgrade ${APP_NAME} ./charts --install --values=./charts/values.yaml --namespace ${APP_NAME}
  rules:
    - if: $CI_COMMIT_BRANCH == 'master'
      when: always

    わかりました.今何?
    さて、すべてのファイルが定義された後、あなたのインフラストラクチャは私たちの前提条件に従っています.
    これらのファイルをコミットする場合、gitlabはあなたの.gitlab-ci.yml ファイルを生成し、パイプラインを開始する.我々のパイプラインは1つのステージと1つの仕事だけを持っています.を使用して展開のクラスタでコンテナをスピンしますhelm:3.2.1 イメージとランscript コマンド.これは、我々の名前空間に必要なすべてのファイルを作成し、アプリケーションを起動すると、すべての重いリフティングを行います.
    あなたがRouter 53でDNS記録のように構成するならばmy-first-app.my-domain.com Interessコントローラが作成したロードバランサへのAレコードで、ConfigMapで定義したインデックスページが表示されます.
    このポストは、我々の最初に現れましたblog 我々が書くところdevops and devops consulting services .
    Android画面サイズと密度対照表,px,dip,spなどの画素単位の解釈
    便利なJSメソッドとユーティリティ関数