IT

Circle CI

2021年11月19日

Circle ci

CI/CDに必要なリソース機能が充実
CircleCIは様々なリソースを提供します。

仮想CPU数とメモリ容量が選択でき、多数のプログラミング言語やWebフレームワークにも対応しています。

またDockerを全面的にサポートしており、DockerfileからのイメージのビルドやDockerレイヤーキャッシュの利用ができます。

これによりDockerイメージを指定するだけで、Dockerコンテナ環境を利用することが可能です。

次の項でCircleCIの機能について見ていきましょう。


なのでCircle CIはクラウドサービスで、
circleci/config.ymlに
docker(image)を指定することで、
その環境でテストなどを行う。

https://agency-star.co.jp/column/circleci#toc-4

githubのアカウントでcircleciにログインすると、
ログインしたgithubアカウントに紐づいているレポジトリをcircleciのプロジェクトに紐づけることができる。
これにより
該当のリポジトリにpushしてリポジトリの中身が更新されたら、
自動的にその更新をcircleciが捕捉して、
config.ymlに基づき、テスト、デプロイを実行してくれる。
githubのリポジトリには、ルートディレクトリから
.circleci/config.yml
というディレクトリ構成でconfig.ymlを設定することで、circleciによって自動化される

以下config.ymlの作成

https://circleci.com/docs/ja/2.0/config-intro/

以下yml
version: 2.1
jobs:
build:
docker:
- image: alpine:3.7
steps:
- run:
name: The First Step
command: |
echo 'Hello World!'
echo 'This is the delivery pipeline'

dockerでimageを作成
そしてstepsで実行するやつ?

https://circleci.com/docs/ja/2.0/workflows/
workflowsは、jobの集まりらしい
実行順序を定めるもの

circle ci orbs
https://blog.tsub.me/post/introducing-to-circleci-orbs/

AWSのECR

AWS ECRのタグは
問題があった際にどの関数などで予算がかかったかとかエラーになったかなどをより見れる
例えばGCPだとサービス単位でしか費用が分からないが、
AWSではタグを使うことで、lambdaのこの関数が予算かかってるなどまでわかる
→ circle ciでaws-ecr/buid-and-push-imageでtagを指定できるので、そこで設定かな

Circle CIのconfigファイルの基本構成

まず以下が構成で一番上の階層。

項目 説明
version:
orbs: よく使う連携でパッケージされたもの。例えばAWS ECRをここで読み込むと後は指定された必須パラメータの情報を入れるだけで簡単に連携できる
commands: コマンドのエイリアス
parameters: 引数を定義する。通常jobsに使用するが、要は処理に引数を渡して処理を構築したい場合に使う。実際に処理するworkflowで、引数が必要なjobsに対しては引数に値を入れる必要がある
executors: 「jobs」の実行環境を定義する。処理の実行環境を定義する(dockerなどの環境や環境変数など)
jobs: 実際に実行するコマンドや処理。jobsは処理を定義するものなので、実行環境である「executors」の名前を指定する。
workflows: 「jobs」で定義した処理の順番などを定義する。処理である「jobs」の名前を指定する。

参照Circle CIヘルプ

version: 2.1

# ===== 実行環境の定義 =====
executors:
  exec1:      # 実行環境1つめ(実行環境1名)
    docker:
      - image
  
  exec2:      # 実行環境2つめ(実行環境2名)
    macos:

# ===== 処理の定義 =====
jobs:
  job1:       # 処理1つめ(処理1名)
    executor: exec1         # 処理1つめは、実行環境1つめの上で実行する
    steps:     # 処理内容
      - checkout
      - run
        name:
        command:   # コマンド実行(必ずコマンドで処理実行)

  job2:       # 処理2つめ(処理2名)
    executor: exec2         # 処理2つめは、実行環境2つめの上で実行する
    steps:     # 処理内容
      - checkout
      - run
        name:
        command:   # コマンド実行(必ずコマンドで処理実行)


# ===== 処理順番の定義 =====
workflows:
  workflow1:     # ワークフロー1つめ(ワークフロー1名)
    jobs:
       - job1       # job1を実行
       - job2       # job2を実行

Executor

実行環境の定義では、
その名の通り実行環境のOSであったり、CPUやバージョンなどの情報を指定します。
処理をする環境がnode.jsなのであれば、nodeのimageが必要ですし、本番環境がwindowsOSならimageはwindowsOSを指定する必要があります。

Jobs

処理の定義では、
コマンドラインで実行する処理を記載します。
実行環境を先程定義したので、その環境の上でどんな処理を実行するか。どういう値を渡して処理実行をするかを定義します。
テスト自動化ということもあり、引数には値をworkflowから渡せるように仮引数で定義しておく必要もあります。

Workflows

処理順番の定義では、
処理の順番を定義します。

上記項目パラメータにさらに細かい設定をしていく。
これらを指定した場合、すぐ下にはその名前を書いて、その後に処理を記載していく。
例えば、
jobsの処理に対して、この「処理名」を定義する必要があり、記載の仕方は、
jobs:
jobs名
step:
....処理
という形で、jobsやcommandsのすぐ下には名前を指定する必要がある。

例えば、

executors:
  my-executor
  docker:...

jobs:
  executor: my-executor
  step:
    run echo "200"

というようにjobという処理をどういう環境で実行するかを、jobsのexecutorで指定したり、

jobs:
  one_jobs

jobs:
  two_jobs

workflows:
  one_jobs
  two_jobs

というように、複数のjobsをどういう順序で実行するかを、workflowで定義したりできる。

CI/CDツール

circleciはCD/CIツールと言われ、テスト自動化するもの
GCPにも同じものがあり、Cloud Buildsです
テスト自動化はgithubにアップするだけでテストを色々やってくれるのではなく、こちらで設定したものについてだけテストを行ってくれる
https://codezine.jp/article/detail/11083

-IT
-

© 2024 Yosshi Labo. Powered by AFFINGER5