GeekFactory

int128.hatenablog.com

Homebrew FormulaをCircleCIでテストする

Homebrew Formulaは一度書くと変更する機会があまりないですが、外部からPRを受け付ける場合はCIでテストしておくと便利です。linuxbrew/linuxbrew イメージを利用すると、LinuxのCI runnerでもbrewコマンドを利用できます。

CircleCIの場合は下記の設定でFormulaをテストできます。

# .circleci/config.yml
version: 2
jobs:
  build:
    docker:
      - image: linuxbrew/linuxbrew:1.9.3
    environment:
      HOMEBREW_NO_AUTO_UPDATE: 1
    steps:
      - checkout
      - run: brew install foobar.rb
      - run: brew test foobar

この例ではリポジトリにある foobar.rb というFormulaをテストしています。デフォルトでは Updating Homebrew... でめっちゃ待たされるので HOMEBREW_NO_AUTO_UPDATE を設定しています。

IAM Roles for Service Accountsに必要なリソースを作成するTerraformモジュールを書いた

kopsなどで自前構築しているKubernetesクラスタでIAM Roles for Service Accounts（IRSA）を利用する時に必要なAWSリソースを作成するTerraformモジュールを書きました。

github.com

kopsとTerraformの組み合わせでIRSAを利用する方法は下記の記事を参考にさせていただきました。ありがとうございます。

blog.hatappi.me

h3poteto.hatenablog.com

Terraformモジュールの使い方

TerraformモジュールのREADME.mdに使い方を書いています。本記事に日本語で使い方を書いておきます。

鍵ペアの生成

まず、鍵ペアを生成します。

mkdir -p irsa
cd irsa

ssh-keygen -t rsa -b 2048 -f sa-signer.key -m pem
ssh-keygen -e -m PKCS8 -f sa-signer.key.pub > sa-signer-pkcs8.pub

go run /amazon-eks-pod-identity-webhook/hack/self-hosted/main.go -key sa-signer-pkcs8.pub | jq '.keys += [.keys[0]] | .keys[1].kid = ""' > jwks.json

Terraformの実行

Terraformで kubernetes-irsa モジュールを適用します。

resource "random_uuid" "irsa_s3_bucket_name" {
}

module "irsa" {
  source              = "int128/kubernetes-irsa/aws"
  oidc_s3_bucket_name = "oidc-${random_uuid.irsa_s3_bucket_name.result}"
  oidc_jwks_filename  = "./irsa/jwks.json"
}

output "irsa_oidc_issuer" {
  description = "Issuer of OIDC provider for IRSA"
  value       = module.irsa.oidc_issuer
}

output "irsa_pod_identity_webhook_ecr_repository_url" {
  description = "URL to the ECR repository for eks/pod-identity-webhook"
  value       = module.irsa.pod_identity_webhook_ecr_repository_url
}

resource "local_file" "irsa_kops_cluster_yaml" {
  filename = "./irsa/kops.yaml"
  content  = module.irsa.kops_cluster_yaml
}

このTerraformモジュールを実行すると、下記のAWSリソースが作成されます。

https://raw.githubusercontent.com/int128/terraform-aws-kubernetes-irsa/c21a21bccf8b8486c2d43254725c51a2f165da3a/diagram.svg

このTerraformモジュールで作成されるCodeBuildプロジェクトを実行すると、CodeBuild上で amazon-eks-pod-identity-webhook のDockerイメージをビルドしてECRリポジトリにpushできます。ローカルでビルドする手間が省けます。

kopsの設定

続いて、kopsのクラスタ設定を変更します。Terraformを実行すると以下の内容で kops.yaml が生成されるので、{base64} の部分を実際の鍵に置き換えます。

spec:
  fileAssets:
  - content: {base64 sa-signer.key}
    isBase64: true
    name: service-account-signing-key-file
    path: /srv/kubernetes/assets/service-account-signing-key
  - content: {base64 sa-signer-pkcs8.pub}
    isBase64: true
    name: service-account-key-file
    path: /srv/kubernetes/assets/service-account-key
  kubeAPIServer:
    apiAudiences:
    - sts.amazonaws.com
    serviceAccountIssuer: https://oidc-RANDOM.s3.amazonaws.com
    serviceAccountKeyFile:
    - /srv/kubernetes/server.key
    - /srv/kubernetes/assets/service-account-key
    serviceAccountSigningKeyFile: /srv/kubernetes/assets/service-account-signing-key

base64 irsa/sa-signer-pkcs8.pub | sed -e 's/=//g'
base64 irsa/sa-signer.key | sed -e 's/=//g'

kops.yaml ファイルの内容をkopsに適用します。

kops edit cluster

pod-identity-webhookのデプロイ

amazon-eks-pod-identity-webhook リポジトリのMakefileを実行して、Kubernetesクラスタにpod-identity-webhookをデプロイします。

cd /amazon-eks-pod-identity-webhook
make cluster-up IMAGE=REGISTRY_ID.dkr.ecr.REGION.amazonaws.com/eks/pod-identity-webhook

動作確認

最終的に、Service Accountを割り当てたPodがS3バケットにアクセスできるか確認します。

まず、S3バケットにアクセスするためのIAMロールを作成します。

resource "aws_iam_role" "s3-echoer" {
  name               = "s3-echoer"
  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "${module.irsa.oidc_provider_arn}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "${module.irsa.oidc_issuer}:sub": "system:serviceaccount:default:s3-echoer"
        }
      }
    }
  ]
}
EOF
}

resource "aws_iam_role_policy_attachment" "s3-echoer" {
  role       = "${aws_iam_role.s3-echoer.name}"
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

Service Accountを作成します。先ほど作成したIAMロールのARNをアノテーションに含めます。

kubectl create sa s3-echoer
kubectl annotate sa s3-echoer eks.amazonaws.com/role-arn=arn:aws:iam::ACCOUNT_ID:role/s3-echoer

aws-cliを実行してS3バケットのリストが表示されることを確認します。

kubectl run aws -i --rm --image amazon/aws-cli --restart=Never --serviceaccount=s3-echoer -- s3 ls

まとめ

kopsなどで自前構築しているKubernetesクラスタでIAM Roles for Service Accounts（IRSA）を利用する時に必要なAWSリソースを作成するTerraformモジュールを書きました。面倒な構築作業を簡略化できるので、役に立ったら幸いです。

Prometheus Alertmanagerの通知テンプレートを改善する

Prometheus

AlertmanagerのSlack通知テンプレートで四苦八苦したのでメモを残します。

Prometheus OperatorのHelm chartには便利なデフォルトルールが組み込まれています。例えば、Podが頻繁に再起動している場合に通知するルール（KubePodCrashLooping）が組み込まれています。しかし、Slackやメールなどのアラート通知は自分で設定する必要があります。

アラート通知の書き方は公式の Notification template examples | Prometheus に例がありますが、そのままではうまくメッセージが表示されない場合があります。ドキュメントでは以下の例が挙げられていますが、 summary や description というアノテーションが付いているルールでないとメッセージが空白になってしまいます。また、CommonAnnotations を使っているため、複数のアラートがグループ化された場合は共通のアノテーションしか表示されません。

- name: 'team-x'
  slack_configs:
  - channel: '#alerts'
    # Alertmanager templates apply here.
    text: "<!channel> \nsummary: {{ .CommonAnnotations.summary }}\ndescription: {{ .CommonAnnotations.description }}"

通知テンプレートのよい例はないか探したところ、下記の記事が参考になりました。

medium.com

Prometheus Operatorのデフォルトルールには message というアノテーションが付いているため、テンプレートでは message を使うとよさそうです。また、グループ化された場合にうまく表示されない問題は Alerts フィールドに入っているアラートを列挙すると解決できそうです。

というわけで試行錯誤の結果、以下のテンプレートを利用しています。

alertmanager:
  config:
    receivers:
      - name: "null"
      - name: slack
        slack_configs:
          - api_url: https://slack.example.com/webhook
            channel: "#alerts"
            send_resolved: true
            username: dev/Alertmanager
            icon_url: https://prometheus.io/assets/favicons/favicon.ico
            title: |
              {{ .Status | toUpper }}
            text: |
              {{- range .Alerts }}
              - **{{ .Labels.alertname }}**: {{ .Annotations.message }}
              {{- end }}
    route:
      receiver: "null"
      routes:
        - receiver: "null"
          match:
            alertname: Watchdog
        - receiver: slack