TLDR 開発体験が良くなると CI のコストも減る 不必要なジョブ実行を減らし、割れ窓を直すことから始めると良い Self-hosted runners ではクラウドコスト最適化の一般的なプラクティスも併用する GitHub Actions のコスト構造 GitHub-hosted runners GitHub が提供するインフラを利用する。一般的なクラウドより高めの料金設定になっている 1分単位で課金される。ジョブの実行時間が数秒間でも1分間で課金されるので注意 Public repository は無料、Private repository は従量課金になっている Organization 内で利用料金が合算されて翌月請求される。Organization Owner なら請求レポート (CSV) をダウンロードできる Self-hosted runners GitHub では課金され

Renovate の GitHub Releases Datasource で Organization 内の Private repository 間の参照を試したところ、普通にちゃんと動きました。ある Private repository で新しいバージョンをリリースした契機で、別の Private repository にあるマニフェストを自動的に更新するといった使い方ができそうです。 試したこと 以下の Private repository があるとします。 example-org/repo-a example-org/repo-b どちらにも Renovate App をインストールしておきます。 既存リリースの作成 example-org/repo-b で新しいリリース v1.0.0 を作成しておきます。内容はなんでも構いません。 バージョン参照と Renovate confi

今年やっていた仕事をまとめてみた。 デプロイパイプラインの再構築 現職では、Pull Request を作るとマイクロサービス一式のプレビュー環境が Kubernetes にデプロイされるようになっている。メインブランチにマージせずに動作確認やレビューができるため、漸進的に開発していく上で重要な仕組みになっている。 歴史的経緯から以下の課題を抱えていた。 テストのない大量のシェルスクリプト群 レンダリングしたマニフェストを直接デプロイしているため、障害発生時にクラスタの復旧が困難だった CIaaS のコスト この仕組みを以下の技術スタックで再構築した。 GitHub Actions (TypeScript) Kaniko Argo CD 現職では大規模な monorepo を運用しているため、GitHub Actions の制約で苦労している。例えば、GitHub Actions では p

カンバンをうまく運用するには自動化の仕組みが不可欠です。Issue や Pull Request を作ったのにカンバンに入れていなくて忘れ去っていたということ、ありますよね。本稿では GitHub に Issue や Pull Request が作成された契機で Project に自動的に追加する仕組みを考えます。 ここでは Organization で Project を使っている場合を想定します。 GraphQL Mutation で Issue を Project に追加する まずは API で Project を操作する方法を説明します。 Issue や Pull Request を Project に追加するには addProjectCard mutation が用意されています。これを使うと Project ボードの指定したカラムに追加できます。 さっそく GraphQL Ex

EnvoyのOAuth2 Filterを試してみました。残念ながら期待通りに動きませんでした。メモだけ残しておきます。 www.envoyproxy.io 構成 EKS 1.18 Envoy 1.17.0-dev-483dd3 以下のトラフィックパスを構築します。 Browser ↓ Internet-facing ALB ↓ Service/NodePort ↓ Pod (envoy) ↓ Service ↓ Pod (ingress-nginx) ↓ Ingress (echoserver) ↓ Service (echoserver) ↓ Pod (echoserver) Route53やALBを設定してインターネットからドメイン名でアクセス可能にしておきます。 また、Google Identity PlatformであらかじめClient IDを作成しておきます。Redirect

Amazon EKSのManaged Node Groupsがスポットインスタンスに対応しました。 aws.amazon.com これまでManaged Node Groupsではオンデマンドしか利用できず、スポットを利用するには自分でAuto Scaling Groups（mixed instance types）を管理する必要がありました。今回のアップデートで簡単にスポットが利用できるようになりました。 設計で気にする点 元記事から重要と思われる点を挙げてみます。 Allocation strategy まず、スポットインスタンスはなるべく複数のAZやインスタンスタイプに分散して配置されます。ASGでmixed instance typesを利用する場合は lowest-price と capacity-optimized が選べますが、MNGでは capacity-optimized

AWS SSOを利用すると、IAM Access KeyやIAM Secret Access Keyの代わりにブラウザベースの認証を利用してAWS APIにアクセスできます。一方で、AWS SSOに対応しているものはAWS CLI v2ぐらいしかなく、Terraformなどのサードパーティツールはそのままでは使えません。そのため、AWS SSOでサードパーティツールを利用するためのヘルパーツールがいくつか公開されています。例えば aws2-wrap などがあります。 本稿では、AWS SSOやSTSの仕組みを理解するため、手動でShort-term credentialsを取得してサードパーティツールを実行する方法を紹介します。 AWS SSOはすでに設定済みである前提とします。参考までに、AWS SSOの設定例として公式ブログにある How to use G Suite as an ex

kubelogin というKubernetes向けのツールをOSSで開発しているのですが、Goのビルド条件によって動作が異なる問題 *1 が出てきて、macOSでビルドを実行する必要が出てきました。ちょうど下記の記事でCircleCIがOSS向けにmacOSをサポートしていることを知りました。 medium.com CircleCIにメールで問い合わせたところ、すぐにOSS向けのmacOSビルドを有効にしてもらえました。先ほどの問題も無事に解決しました。ありがとうございます！ OSS向けのmacOSビルドを有効にするにはCircleCIのFreeプランが適用されている必要があります。私の場合はGitHub Marketplaceのプランになっていたため、GitHub Marketplace上でプランを解約したらCircleCIがFreeプランに戻りました。 CircleCIでmacOS e

Certified Kubernetes Administrator（CKA）を取得しました。すでに多くの受験記があるので、他の人が書いていないことをまとめてみます。 きっかけ いろんな言い訳でCKAの申し込みを先延ばしにしてきたのですが、以下の条件が揃ったので受験するに至りました。 会社で受験費用が支給される（同僚が事務処理をやってくれた） シェアオフィスが営業を再開したので個室を確保できる 勉強時間を捻出できた やる気が出た 事前準備 会社が契約しているシェアオフィスで個室を借りました。自宅からシェアオフィスまでは3.5km程度なので、自転車で行くことにしました。近くに駐輪場があるかどうかや個室が受験要件を満たすかどうかを確認しておきたかったので、前々日にリハーサルを行いました。まあシェアオフィスに着いたら普通に仕事していましたが。 試験は24時間前までに申し込む必要があります。試験の

AWSのEC2インスタンスでは、User Dataにシェルスクリプトを渡すことで起動時にスクリプトを実行できます。ファイルを配置したり、パッケージをインストールしたり、といった複雑なことがやりたい場合はcloud-initが便利です。詳しくは公式ドキュメントの例を参照してください。 docs.aws.amazon.com 例えば、下記のようなYAMLをUser Dataに指定すると、OSの起動時にsystemdで独自のサービスを開始できます。 #cloud-config write_files: - path: /etc/systemd/system/helloworld.service" content: | [Unit] Description = Hello World [Service] ExecStart = /usr/local/bin/helloworld.sh Restar

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 というFo

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-k

kubectlのプラグインを開発していると、ユニットテストだけでなく、本物のKubernetesクラスタを利用したテストが欲しくなります。プラグインの振る舞いが複雑な場合は自動テストがあると安心してリリースできます。 本稿では、本物のKubernetesクラスタを利用してkubectlプラグインをテストする方法を考えます。 テストの基本形 本物のクラスタを利用してプラグインをテストするための構成を下図に示します。 必要なのは以下の3つです。 テスト対象のプラグイン テスト対象が依存するクラスタやリソース テストシナリオ テストの流れは以下のようになります。 クラスタを作成する。 必要なリソースをデプロイする。 kubectlを実行する。 間接的にkubectl pluginが実行される。 実行結果が期待通りか検証する。 このようなテストはプラグインのリリース前に手動でやっていることが多いと

お店やネットで買い物する時のビジネスルールが複雑になってきたので書き出してみました。 以下の順に評価して条件を満たす決済手段で支払います。 USD/EUR建ての場合：Sony Bank WALLET ANA FESTAの場合：ソラチカカードVisa（5%割引） ビックカメラの場合：ビックカメラSuicaカード（10%） アトレやJR定期券の場合：JREカード（5%） 投資信託の場合：楽天カード（1%）→楽天証券 コード決済が使える場合：Origami Pay（1%割引）→Kyash Visa（1%）→EPOS（1.5%） コード決済が使える場合：楽天Pay（1%）→Kyash Visa（1%）→EPOS（1.5%） Visa決済が使える場合：Kyash Visa（1%）→EPOS（1.5%） プリペイドVisaがダメな場合：EPOS (1.5%) 東京メトロ乗車の場合：ソラチカPASMO

kind create cluster コマンドでKubernetesクラスタが起動しない場合、以下のようなメッセージが表示されます。 ✗ Starting control-plane 🕹️ ERROR: failed to create cluster: failed to init node with kubeadm: command "docker exec --privileged kind-control-plane kubeadm init --ignore-preflight-errors=all --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1 クラスタが起動しない原因を調査するには以下の方法があります。 kindコマンドのログレベルを上げる kin

アプリケーションの開発フローとKubernetesへのデプロイを考えた軌跡を残します。特に結論はないです。 前提 以下を前提とする。 Kubernetesにアプリケーションをデプロイする場合を考える。 すべての変更はPull Requestを通して適用する。 アプリケーションはソースコードを変更することなく、どの実行環境でも動作可能とする。 アプリケーションの設定は実行時に環境変数などで注入される。 開発チームはアプリケーションと設定に責任を持ち、自分自身でデプロイを行う。 Platformチームは実行環境の健全性に責任を持つ。 以下はスコープ外とする。別に考える必要がある。 実行環境自体のデプロイや変更（例えば、Kubernetesのバージョンアップ） アプリケーションが依存するステートフルなリソース データベーススキーマのマイグレーション アプリケーションやイメージのセキュリティ検査

Amazon EKS #1 Advent Calendar 2019の13日目です。今日はKubernetes DashboardとIAM認証についてお話しします。 背景 Kubernetesのクラスタをチームで運用する場合、チーム全員がコマンドラインツールに習熟しているとは限らないため、GUIツールを併用することが望ましいです。新しく参画したメンバはKubernetesの概念に不慣れかもしれません。初学者はコマンドラインツールとGUIツールを併用することで、新しい概念を理解しやすくなり、効率的に学習を進められます。 KubernetesのGUIツールはいろいろありますが、まずは公式のKubernetes Dashboardを使ってみましょう。慣れてきたら別のGUIツールを探してみましょう。iOSのアプリもあります。 Kubernetes Dashboard 課題 AWSの公式チュートリア

mercari/tfnotifyがv0.3.2でGitLab CI/CDに対応したので試してみました。個人的には待望の機能追加です。tfnotifyを利用すると、GitLab CI/CDでTerraformを実行した結果をMerge Requestのコメントに反映できます。いちいちジョブの結果を見に行かなくてよいので便利です。 Getting Started 以下のステップでGitLabとtfnotifyを設定します。 Personal Access Tokenの設定 tfnotifyの設定 GitLab CI/CDの設定 1. Personal Access Tokenの設定 tfnotifyはGitLab APIを利用してCommitにコメントを書き込みます。tfnotifyがGitLab APIにアクセスできるように、環境変数でPersonal Access Tokenを渡します。

Cluster Autoscalerを運用していると，ノード数が増減した契機を調査したいことがあります．Cluster Autoscalerは大量のログを出力するため，闇雲にログを追うのは大変です．PrometheusとGrafanaでCluster Autoscalerの動作を可視化しておくと調査しやすくなります． Cluster Autoscalerにはメトリクスを取得するためのエンドポイントが用意されており，Prometheusと連携することが可能です．具体的なメトリクスはCluster Autoscalerのドキュメントを参照してください． Prometheusで用意されているServiceMonitorというカスタムリソースを利用すると，監視対象のServiceとPrometheusを紐づけることが可能です．詳しくはPrometheusに関連するリソースの説明が参考になります．