サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
tellme.tokyo
この記事は 10X アドベントカレンダー2022 28日目のエントリーです。 シリーズ共通のお題、「好きなスーパーと商品は?」について。好きなスーパーはクイーンズ伊勢丹です。高輪に住んでいたとき最初はほかに選択肢がなく利用しはじめたのですが、通うたびに気になる商品に出会うことが多く好きになりました。好きな商品は石野味噌です。天明元年から続く歴史ある白味噌です。 今回のエントリーの投稿に際し、ちょうど転職をして1年になるので入社から今までのタイムラインの振り返りと、来年以降の自分の考えについて書き留めておきます。 2022/1 チームづくり 退職と転職。人生の振り返り 今年の1月に 10X へ転職しました。10X では初の SRE Job description での採用ということで、チーム作りや Stailer 事業の拡大を支えるインフラづくりやそのビジョンを描くために入社しました。詳しく
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 外から参照できるようにするために使うもの
お久しぶりです。 2021年12月末でメルカリを退職しました。在籍期間は5年8ヶ月でした。2022年1月からは 10X で SRE をやっています。メルカリはファーストキャリアで第1期新卒としての入社でした。メルカリで働いたことは自分の人生に大きな影響があったこと、退職したことは大きな決断だったので振り返りを残します。 2016年 2016年に新卒としてメルカリに入社しました。GitHub 採用というやつです。当時は相当前衛的でヤバイ組織だなという印象を持ちました。 配属先は「JP チーム」という名前のチームで、バックエンドエンジニアとしてでした。JP チームの API 開発エンジニアとしては3人目の入社で、当時の JP チームはデザインメンバーからプロデューサー (当時の呼称) までが10人前後集まった集団でした。プロダクトサイドのメンバーとしてはもっといたのですが、当時は「US ファー
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
環境 HashiCorp Vault 0.10.4 Seal/Unseal HashiCorp Vault (Vault) は起動しただけでは使えない。 Vault は Sealed / Unsealed という自身の状態を表すステータスの概念を持ち、これらを内部で保持する一部ステートフルなアプリケーションである。 Vault は起動時 (再起動、デプロイ後など) は Sealed 状態となっており、Secret の取得や保存など、あらゆるオペレーションができないようになっている。 これはセキュリティを高めるために Vault が用意したプロセスである。 Vault では暗号化したデータを外部ストレージに保存する (Secret Backend と呼ぶ) が、復号して取り出す際に暗号化に使用したキーを必要とする。 この暗号化キーも暗号化されたデータとともに Secret Backend に
peco とか fzf のようなフィルターコマンドが便利すぎて使わない日はないのですが、これらをどうしても Go プログラムに組み込んでしまいたいときが稀にあります。 どちらも Go で書かれているので、ライブラリとして使えるように提供されていれば import するだけなのですが、どちらも CLI (Command Line Interface) のみを提供しています。 CLI として作られている以上、シェルコマンドとして使うべきではあるのですが、そうすると何かと連携させたいとなった場合 (多くの場合はそうですが)、シェルスクリプトを書くことになります。 小さなものであればそれで構わないのですが大きめなツールになる場合、基本的にシェルスクリプトを書きたくないわけで、そうするとやはりどうしても Go から扱いたくなります。 シェルコマンドといっても CLI (Command Line In
現状 キャッシュレスに切り替えて1年以上になる。 上京とともに現金を使うスタイルをやめた。 地方だと完全キャッシュレス化は現実的ではないが、首都圏、少なくとも都内23区においては現金を使うことなく生活できている。 よく使う決済手段は3つ。 LINE Pay (JCB) ANA VISA Suica (VISA) モバイル Suica 他にもいくつかカードを持っているが、常用しているのは LINE Pay と ANA VISA Suica の2つで、電子マネーは Suica に絞っている。 ANA VISA Suica カードはややこしい名前だが Suica 機能 (オートチャージ設定可能) が付いた View カードで、ブランドが VISA になっている。 決済手段 LINE Pay JCB で1枚選出するとなると LINE Pay 一択かなと思う。 最高クラスの還元率 (2%) にも関わ
はじめに 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 のマニフェストファイル、及び記事自体を管理
元記事 最強のヒストリ補完を求めて シェルヒストリに不満を持っていたので自作しました。 今の自分にとっては必要な機能を盛り込んでいて便利に使えていますが、誰かにとっては、もしくは数カ月後の自分にとってはぜんぜん最強じゃないかもしれないです。 以前このようなエントリを書きました。 [http://www.tellme.tokyo/entry/2017/02/14/214231:embed:cite] このころから (いやもっと前から) シェルのヒストリ補完に不満を持っていました。 単純にデフォルトの C-r だと目的のものを探しづらい 例えばコマンド名の一部だけだとノイズが多すぎる けどディレクトリは覚えているからそれでもフィルタしたい、とか 他にも色々あって (その理由について先のエントリを見てもらうとして) zsh-history というツールを書きました。 https://github
OS のクリーンインストールは面倒くさい. アプリケーションをいちいちダウンロードしてきて,普段の勝手と同じになるように設定する必要がある.CLI においても同じで,設定ファイルをいちいち書いたり,普段どんなプラグインを使っていたかを思い出してダウンロードするのは面倒だ. よくあるのは .vimrc などの設定ファイルを Dropbox や GitHub に置いておいて,環境を作り直したときにコピーする手法だ. dotfiles はその手法の延長線上にあって,より便利に高速化・自動化した方法だ. dotfiles とは UNIX 系の OS でいう設定ファイルのことで,ファイル名がドット . から始まることからそう呼ばれている. TL;DR HTTP 経由でインストールできる dotfiles をつくって 1 分で環境構築を終わらせる. Getting Started dotfiles を
まえがき デスクトップに一際目立つアイコンで鎮座する,ゴミ箱は使っているだろうか.今となってはゴミ箱は GUI デスクトップの象徴的存在だ.誤削除を防ぐ手段としても,安心した削除支援の存在としても GUI デスクトップに無くてはならない. さて,GUI デスクトップに相当する CLI はホームディレクトリだが,これにゴミ箱がないのは不便ではないだろうか.rm に関してはその概念をなくして削除を行い,他に「ゴミを捨てる」にあたるようなコマンドはない. GUI以前のコマンドラインには、ゴミ箱という考え方はなかった。(と思う)ファイルやフォルダを削除するにはrmコマンドを使っていた。そのまま使えば、rmを実行した瞬間にファイルは削除される。あるいは、-iオプションによって、削除する前に確認メッセージも表示できるが、yを選択した瞬間にファイルは削除される。 だから、ゴミ箱というフォルダに移動して一
CLI(Command-line Interface)ツールが好きで自分でもよく作るし,よく使っている.最近は高速で,かつクロスコンパイルが容易な Go 言語がその開発に使われることが多いようだ.実際に筆者も拙劣ながら Go 言語で何個かリリースしている. b4b4r07/gch b4b4r07/goal b4b4r07/gomi CLI ツールの歴史はとても長く,過去たくさんの素晴らしい資産と独自の哲学がある.現代にいきる我々も当然その思想に従うべきで,CLI ツールを作るならその哲学を踏襲するのが常識だ. UNIX 哲学 Small is beautiful. Make each program do one thing well. Build a prototype as soon as possible. Choose portability over efficiency.
MacBook 12 inch を買った June 03, 2015 5⁄20 に「新しい MacBook」が届いた.Apple のオンラインの Store で,実際にポチったのは4/12なので届くのには1ヶ月以上かかったことになる. スペックはこの通りだ. CPU を最大の 1.3GHz に引き上げた.処理スピードは速いに越したことはない.それと,ここに載っていない変更点として,キーボードを US 配列にした.これはデザイン的な動機もあるが,主として私の用途がプログラミング関連だからだ.デスクトップ PC にも US 配列のキーボードを使用している. Why なぜ,この賛否両輪ある新しい無印の MacBook を買ったかというと,それまで使っていた MacBook Air (13 inch, Mid 2012) に不満が溜まってきていたからだ. 13インチはモバイル機としては大きすぎる
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 標準出力に出しつつ、パイプ先のコマンドにも繋
このページを最初にブックマークしてみませんか?
『TELLME.TOKYO』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く