Contents
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」の名前を指定する。 |
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