CircleCIのメモ
CircleCI環境変数について
circleciの環境変数の定め方は2通りある。
一つはconfig.ymlで環境変数をハードコーディングで定める方法である。
もう一つはcircleciのコンソールで環境変数をキーとバリュー形式で登録しておき、config.ymlでキーを呼び出すことで環境変数を読み込む方法である。
config.ymlでハードコーディングする方法は例として以下のようになる。
version: 2 jobs: build-job: docker: - image: circleci/python:3.7.3 - image: circleci/postgres:10.5-postgis environment: DATABASE_URL: postgres://postgres:@localhost/circle_test SECRET_KEY: aaq1sjddijfv*d5j%$ssyji+@!2bqur_hynpls_fwozwbs9rkj DJANGO_READ_DOT_ENV_FILE: True DJANGO_SETTINGS_MODULE: config.settings.dev_settings working_directory: ~/app
またシェルコマンドで環境変数を設定することもできるが、単純に
export PATH=/path/to/foo/bin:$PATH
を使えばよいというわけではない。この方法では環境変数を設定する事ができないからだ。
echo 'export PATH=/path/to/foo/bin:$PATH' >> $BASH_ENV
BASH_ENVを使う必要があることに留意すること。
シェルコマンドによる環境変数の設定の資料
今の所config.ymlから.envファイルを読み込む方法が使えるのか確認できていない。 ※ docker-compose.ymlではenvironmentで環境変数を定めることができるに加えて、env_fileで.envファイルを読み込むことができた。分かったら後に書き加える。
キャッシュについて
依存関係のキャッシュ
キャッシュを使うとビルドにかかる時間を短縮できる -> circleciで利用できる無料利用分を有効に使うことができる。
どんな仕組みでキャッシュを更新するのか??
どう使うのか??
config.ymlで記述するのはstepsでrestore_cacheやsave_cacheを使う。
取得済みのデータが有ればrestore_cacheを宣言してキャッシュ済みのキーをリスト形式で記述すればキャッシュの読み込みができる。
steps: - checkout - restore_cache: key: pip-{{ checksum "requirements.txt" }}
checksumはキャッシュが更新するかを確認するためのもの。checksumの値が変更されていれば後述するsave_cacheでキャッシュを更新する。
- save_cache: key: pip-{{ checksum "app/requirements.txt" }} paths: - 'venv'
workflowsについて
ジョブの実行を Workflow で制御する - CircleCI
よく使うコマンド
circleci local execute --job ジョブ名
circleciコンソールの見方
circleciの実行を止める種類は2つある。
workflowsそのものをとめる方法と実行中のjobを止める方法が存在する。
workflowsを止める方法はプロジェクトを選んだ状態の画面から"Return"というドロップダウンメニューから"Cancel workflow"を押すことで止める事ができる。
一方jobを止める場合はworkflowsからjobをクリックした画面(jobの詳細実行画面)にある"Return"というドロップダウンメニューに"Cancel job"がある。これを押すことでjobを止めることができる。
ssh接続ができる状態にしてからどうやってssh接続できる状態を止めるようにするかはまだあやふや。これをきっちり止めないと新規に新たな実行ができないままになってしまう。無料枠だから??
CircleCIで実行サーバーにssh接続する際に困ったこと
ビルドしてテストして問題がなかったらデプロイに移るわけだけれども、ssh接続できずにずっと苦しい思いをした。 ココについて解決できたので改めて整理してみたいと思う。
必要なこと。
githubからソースコードを取得するのは2つの場面がある。一つはgithubにpushすることでcircleciサーバーが起動し取得する場面である。2つ目はテストが完了し実行サーバーでデプロイする際にコードを取得する場面である。
circleciサーバーがコードをpullする際はsshkeyが必要になるが、特にcircleci側にsshkeyを登録する必要はない。
サーバー側でデプロイするときにはhttps通信でpullを実行する場合とssh通信でpullを実行する場合がある。httpsでpullを実行する場合には認証するためにpasswordをいんてラクティブな形式で入力することになる。これをcircleciでデプロイする場合にはpasswordを入力する事ができず、デプロイ作業中に止まってしまう。passwordを聞かれずにpullさえできればデプロイ作業が継続される。ssh接続でpullを実行するとpasswordを聞かれることがない。
したがって実行サーバーがpullを行うときはssh通信を行うことが必須となる事がわかった。これを実現するには以下2件の作業が必要になる。
実行サーバーがpullしてきたものに対しgithubがpullを許容するために、別の言い方をすれば実行サーバーからgithubにssh通信を実行するためには、通信を開始する側は秘密の鍵が必要になるし、通信を受ける側であるgithubでは秘密の鍵が必要になる。 したがって実行サーバーで秘密の鍵、公開鍵を作成し、公開鍵の情報はgithubに登録する作業が必要になる。
またgit remote -v で表示される形式がhttps形式であれば実行サーバ-に秘密の鍵があろうとまたgithubに公開鍵があろうとhttps通信が行えわれ結果としてpasswordが聞かれてしまう。そこでssh通信を行う宣言をするためにもssh形式にあったリモートの登録が必要になる。
この辺のことはいかにうまくまとめられている。
GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ - Qiita
これでcircleciからgithubの接続と実行サーバーからgithubの接続ができるようになった。 circleciでpullを行いビルド、テストを実行する。 circleciサーバーから実行サーバーにssh接続を行い、実行サーバーがgithubからpullを実施する。ここでまだcircleciサーバーから実行サーバーに接続する設定が終わっていない。
circleciサーバーから実行サーバーに接続するにはやはりsshの鍵が必要でそれに関連した作業がある。
- pem形式のsshkeyを作成し、circleciサーバー側に秘密の鍵を登録する
- ssh接続の際にオプションを付け加える。
sshkey-genコマンドを実行する際にpem形式の鍵を作成しないとcircleciで秘密の鍵を登録する事ができない。
したがって-m pemオプションをつけて実行する。
sshkey-gen -m pem
ssh接続の時新たなサーバーに接続する場合にはsshクライアント側で以下のような質問が標準出力される。
ECDSA key fingerprint is SHA256:IcFXfHgh42HvcZiG/zQmle+IjD4lrUu4XV+469JheJE. Are you sure you want to continue connecting (yes/no)?
この出力に対し、yesを入力しなければssh接続が開始されない。これはそもそも接続先として誤ったhostに接続した場合に誤ったホストはsshクライアントが入力する内容を盗聴する事ができる。このような場合にクライアントがsudo コマンドでpasswordを入力したものなら悪用されることに怯えなければならない。したがって以前通信したことがないホストと通信する際に上記の標準出力が表示されるのはあなたが接続しようとしているホストは間違っている可能性もあるので注意してねって感じの注意喚起の役割を果たしていることが分かった。
この標準出力を出さない方法として
ssh -p 22 -o 'StrictHostKeyChecking no' username@host
がある。これを実行すればssh接続できる。
circleci+fabricの資料
これがとても良くわかりやすくベースはこれを使って実装した Django and CircleCI 2.0 | Timmy O'Mahony