はてなブックマーク

resource "aws_instance" "server" { count = 4 # create four similar EC2 instances ami = "ami-a1b2c3d4" instance_type = "t2.micro" tags = { Name = "Server ${count.index}" } }

Terraform の Variables と Locals、Outputs June 15, 2022 それぞれの役割 Terraform で “変数” というと、Variables と Locals がある。どちらも値を入れて、Terraform ファイル や Terraform Module から参照することができる。ちなみに Terraform Module とは「.tf ファイルが置かれたディレクトリ」を意味する。main.tf などを置いた瞬間からそのディレクトリは Module として扱われ、起点となる Module を Root Module と呼ぶ。 Terraform では “変数” 以外に “返り値” (Return value) に相当するものとして Outputs がある。これは Module での処理結果を Module 外から参照できるようにするために使うもの

Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり February 4, 2020 lt;dr GoReleaser と GitHub Actions を使うと簡単にビルドしたバイナリを作ってアップロードできる。 2つの YAML を書いてリポジトリにコミットする .github/workflows/release.yml .goreleaser.yml git tag して push する バイナリがリリースされる 専用のツールをローカルにインストールする必要はない。 本題 前に、Go のコマンドラインツールを簡単にリリースする | tellme.tokyo というブログを書いた。 それよりももっと楽になったので紹介する。 基本的にこのページで紹介する方法では 2 つの YAML をリポジトリに置くだけで終わる。 ロー

CLI ツールはよく Go で書く。 (Go でなくとも) ちゃんとした CLI ツールを書こうとすると、Exit code とそのエラーの取り回しについて悩むことが多い。 今回は、何回か遭遇したこの悩みに対する現時点における自分的ベストプラクティスをまとめておく。 ToC Exit code とは Go における Exit code 高次での取り回し CLI 側 処理側 まとめ Exit code とは

Kubernetes などの YAML を独自のルールをもとにテストする February 19, 2019 設定ファイルのメンテナンスの必要性 Infrastructure as Code の普及もありインフラの状態やその他多くの設定が、設定ファイル言語 (YAML や HCL など) で記述されることが多くなった。 Terraform HCL や Kubernetes YAML など、人が継続的にメンテナンスしなければならなく、その設定が直接プロダクションに影響を与える場合、そのレビューがとても重要になる。 具体的に例えば、「デプロイする Replica の数」や「Resource limit や PodDisruptionBudget が適切か」などレビューの中で注意深く見なけれなならない点などがあげられる。 加えて日々のレビューの中で、問題にはならないが「Kubernetes の

HCL2 とは HCL (HashiCorp Configuration Language) は HashiCorp によって作られた設定言語です。 HCL の目的はコマンドラインツールで使用するために、人間からも機械からも扱いやすく構成されていて、かつ特に DevOps ツールやサーバーなどを対象とした構造化構成言語であることです。 実装は hashicorp/hcl にあります。 実はこれの他に同時に Version 2 の実装も目下開発中のようです。 hashicorp/hcl2: Temporary home for experimental new version of HCL このリポジトリでは HCL が元から持つ iteration と補間言語 HIL を組み合わせて、任意の式をサポートする単一の構成言語を目指しているようです。 要するに、設定ファイルでありながら、演算処理

このブログ (b4b4r07/tellme.tokyo) ではマークダウンで記事を書き、Hugo を使って静的ファイルを生成して GitHub Pages でホスティングしている。 とても便利なのだが、いくつか面倒な点がある。 リアルタイムに記事のプレビューが見たいとなると、hugo server -D する必要があり、都度別コンソールで立ち上げるのが面倒 記事をあたらしく書き始めるとき hugo new post/<filename>.md を打つのが面倒 過去記事を編集するのが面倒 hugo を実行すると draft の記事も生成されてしまう (index には載らないが、生成されるので commit してしまう) いろいろ面倒なので、Hugo でブログを書くだけのツール (hugo wrapper) を書いた。 hugo の上位互換というわけではなく、必要な機能の不便な部分だけを O

ソフトウェアの宣言的設定について “何かを管理する"となったときに、宣言的に設定できるようになっていると非常に便利である。 この宣言的設定 (Infrastructure as Code) とは、イミュータブルなインフラ (Immutable Infrastructure) を作るための基本的な考え方で、システムの状態を設定ファイルにて宣言するという考え方である。 具体的には Kubernetes のマニフェストファイル (YAML) だったり、Terraform のコード (HCL) が挙げられる。 この考え方は、インフラ領域に限らず、何らかの状態管理にはもってこいの手法である。 GitHub のラベルは Issues/P-Rs を管理するために便利な機能である。 しかし、リポジトリの規模やラベルの数が増えてくると、ラベル自体も管理する必要が出てくる。 実際に Kubernetes 規模

アプリケーションにロジックを外側から変更したい場合やソースコード外から設定されるべき情報 (API キーや何らかのトークン、その他の Credentials など) をアプリケーション側から読み取れるようにしたい場合がある。 よくある方法として、環境変数やフラグなどがある。 しかしこれらは往々にしてアプリケーションにハードコードされがちである (ロジックが書かれたファイル外に定義されたとしてもそれはハードコードに等しい)。 そうすると設定変更のたびにデプロイを必要とするし、言わずもがなセキュリティ的には厳しい。 またこの問題は、コンテナとマイクロサービスの領域において更に顕著になる。 同じデータを2つの異なるコンテナで参照する必要がある場合や、ホストマシンが使えないのでどうやってコンテナ内に渡すべきかを考える必要が出てくる。 実際にハードコードされたアプリケーションから環境変数に移し、それ

Hugo で PlantUML を描画して埋め込めないものかと調べていると、 Add exec shortcode #796 - gohugoio/hugo・GitHub Hugo の Shortcodes の機能を使って、HTML の生成をフックにしてレンダリングした後に埋め込む、みたいなことをできるようにする議論自体はあったものの進んでいないようで、他の案はないかと調べると PlantUML ではなく mermaid が良いとわかった。 vjeantet/hugo-theme-docdock にあったディレクトリ構成を真似て以下のようにした。 b4b4r07/tellme.tokyo - f8fe64c・GitHub Shortcodes を使って以下のようなシーケンス図を書くと、 {{\< mermaid align="left" \>}} sequenceDiagram parti

peco とか fzf のようなフィルターコマンドが便利すぎて使わない日はないのですが、これらをどうしても Go プログラムに組み込んでしまいたいときが稀にあります。 どちらも Go で書かれているので、ライブラリとして使えるように提供されていれば import するだけなのですが、どちらも CLI (Command Line Interface) のみを提供しています。 CLI として作られている以上、シェルコマンドとして使うべきではあるのですが、そうすると何かと連携させたいとなった場合 (多くの場合はそうですが)、シェルスクリプトを書くことになります。 小さなものであればそれで構わないのですが大きめなツールになる場合、基本的にシェルスクリプトを書きたくないわけで、そうするとやはりどうしても Go から扱いたくなります。 シェルコマンドといっても CLI (Command Line In

はじめに Kubernetes2 Advent Calendar 2017 - Qiita 1 日目です。 Kubernetes 上で動かすアプリを作ることが多くなってきていると思いますが、従来のオペレーションとは違う方法で開発やデプロイなどを行う必要があります。 Kubernetes の実行環境として GKE を例に取ると、GCP プロジェクトやその中で作った GKE クラスタ、Kubernetes ネームスペースなど、見る必要のある領域が増えるとともに今までのやり方も変わるはずです。 本記事ではその際のユースケースと、それをいい感じにしてくれるツールを紹介します。 今いるクラスタは何か 本番環境と開発環境 (Prod / Dev) でクラスタを分けることは多いと思います。 その他にもクラスタを持っていることもあるでしょう。 Continuous Delivery のプラットフォームとし

最近、といっても今年の7月からですが SRE チームにジョインしました。 そもそも SRE とは Site Reliability Enginnering の略です。 Google が提唱しました。 国内ではメルカリがいち早くに改名したことでも知られています。 インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog ところで、今からおよそ1年前に入社エントリを書きました。 新卒でメルカリに入社した話 | tellme.tokyo この頃ちょうど SRE 研修という名目のもと1ヶ月半ほど SRE チームにて業務の一端を担当しました。 研修という名を冠していますが、最前線にいる SRE から普通にタスクをもらって仕事したりレビューしてもらえるという、とても貴重な経験でした。 このときにイ

Cloud Identity-Aware Proxy を使って GCP backend を保護する October 30, 2017 Cloud IAP とは Cloud ID-Aware Proxy（Cloud IAP）は、Google Cloud Platform で動作するクラウド アプリケーションへのアクセスを制御します。 Cloud IAP はユーザー ID を確認し、そのユーザーがアプリケーションへのアクセスを許可されるかどうかを判断します。 - https://cloud.google.com/iap/ つまり Cloud Identity-Aware Proxy (Cloud IAP、または IAP) を使うことで、任意の GCP リソース 1 に存在するロードバランサに対して、許可された Google アカウントやサービスアカウントによるアクセスのみに絞ることができます。

このブログをはてなブログから Google Container Engine (GKE) に移行しました。 今回、移行先に GKE を選択した理由は GKE を使ってみたかったからです。ある Web サービスを GKE に移行することになったのですが、今まで Kubernetes を含め触ったことがなかったので、自分の持つサービスで練習がてらと思いブログを題材にしました。 目次 移行のためにやったこと ブログ用の Docker コンテナを作成 kubernetes cluster を構築 コンテナの入った Pod を動かす HTTPS 化する 記事の配信まで Circle CI による継続的インテグレーション Spinnaker による継続的デリバリ 所感など 移行のためにやったこと 今回の移行に際し、移行周りのスクリプトや kubernetes のマニフェストファイル、及び記事自体を管理

2023年振り返り December 31, 2023 gh extension の管理 March 21, 2023 転職して1年が経つので振り返り。来年の抱負など December 28, 2022 Terraform の object variable で柔軟なパラメータ設定を提供する (optional default) July 3, 2022 Terraform の Variables と Locals、Outputs June 15, 2022 Terraform の count と for_each の使い分けと Splat Expressions について June 12, 2022 新しいコマンドラインツール向けのパッケージマネージャ March 2, 2022 退職と転職。人生の振り返り February 28, 2022 標準出力に出しつつ、パイプ先のコマンドにも繋