マイルドヤンキーがテッキーに憧れるblog

マイルドヤンキーです。テッキーな人に憧れてる人です

mackerelのMonitorsをgithubで管理してcircle-ci 2.0から反映させる

mackerel circle-ci

タイトルの通りではあるんですが、

よく叫ばれてる

  • 自動化
  • infrastructure as code

とかしたいわけじゃなくて

  • チームで作業したいから見える場所に置いときたい
    • 履歴もまああれば便利（あんま使わない）
  • コメント残せないからコミットログにしたい
    • これは割と使う
  • ciに乗せてるのはmkrコマンドの環境を作るのが面倒臭いだけで別に自動化自体には大して意味は無いと思ってる

まずは現状を取得する

mackerel.io

mkrコマンドインストール

mackerel.io

コマンドのセットアップが終わったら

mkr pull

でjsonファイルを取得する (monitors.jsonとでもしておく）

gitにコミットしてpushしておく

git add .
git commit 
git pusho origin ブランチ

あとはこれを

mkr push
mkr pull

するだけでもとりあえず現状は取得&コード管理下に入ったと思う。 最初はブラウザで変更した物をpullしてコミットログ残してpushしておくだけでも多少役にたつかもしれない。

circle-ci2.0にやらせてみる

前提としては

  • version2だからとりあえずdockerにしてる（別に意味はない）
  • machineというプロパティでvmも使える

想定挙動としては

  • master以外のpushでmackerel側とdiffを取るようにしている
  • masterにpush or mergeしたらmackerel側に適用

想定しているワークフローとしては

  • ブランチ切って適当にjson編集してpush
  • circle-ci上でdiffが取られる
  • 問題無かったら該当buildのurlでも貼り付けてPull Request出す
  • masterにマージされたら適用
version: 2
jobs:
  build:
    docker:
      - image: &ubuntu circleci/ubuntu-server:trusty-latest
    steps:
      - run: &setup_mackerel curl -fsSL https://mackerel.io/assets/files/scripts/setup-apt.sh | sh && apt-get install mkr
      - checkout
      - run: mkr monitors diff -F mackerel/monitors.json
  apply:
    docker:
      - image: *ubuntu
    steps:
      - run: *setup_mackerel
      - checkout
      - run: mkr monitors push -F mackerel/monitors.json
workflows:
  version: 2
  build_and_apply:
    jobs:
      - build:
          filters:
            branches:
              ignore:
                - master
      - apply:
          filters:
            branches:
              only:
                - master

buildってプロパティを使いたくなかったんだけど、 入れないとエラーになるのでとりあえず入れといた。 もっとスッキリかけると思うんだけどyamlにもcircle-ciにも疎いのでこのくらいになった。

インスタンスプロファイルを想像する

aws cloudformation packer ec2

https://dev.classmethod.jp/cloud/aws/do_you_know_iaminstanceprofile/

頼りになるクラスメソットさんの記事

この記事にもある通りEC2を単体でwebコンソールから起動するときは意識することがないのだが、 仕事でCloudFormationとPackerを使う事になってどうしてもインスタンスプロファイルという項目を設定しないといけないので深く理解する必要はないと思ってるけどなんとなくイメージできるようにしておく。

結局のところIAM roleをEC2につけてるわけじゃなくてインスタンスプロファイルという名前でaliasしてるだけという理解なんだけど、 キーワードとして（CloudFormationのプロパティとか）頭に入れておかないと戸惑う事になる。

サンプルのymlを見ると IAM Role作成 -> IAM Roleが返してくれるプロパティでインスタンスプロファイル作成 -> インスタンスプロファイルが返してくれるプロパティをEC2にくっ付けて起動 という流れっぽい。

ただの利用ユーザー的にはalias的にブリッジしている理由がなんなのかはきになる。