PEP668は突然やってきた pythonのスクリプト書いてるときに、OSに入っていないpythonのモジュールが必要になったらどうしてますか？ いままで、自分は細かいこと考えず、すぐ使えればいいやと割り切って $ pip3 install --user ほしいモジュール名 って、いつもやってました（笑）。まあ、見るからに、野蛮ですね。 ところが、先日久しぶりにDebian sidにはない無いモジュール（pycoingecko）が必要になって、いつものようにpip3を実行しました。そしたら突然のエラーですよ！ $ pip3 install --user pycoingecko error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed.

すこしずつがんばる streaming data 処理、前回 からのつづきです。 目指していることの概要などは前回の内容をご覧ください。 いちばんかんたんな pipeline を実装してみる さて、前回では定形として用意された template 機能から実行してみることで、Dataflow で処理を行うのがどのようなことかの感覚をつかみました。 今回はそこから一歩進んで、想定した仕様にカスタマイズして処理を書くことを目指してみます。 ハッキリ言ってここからが急にしんどいです。何がしんどいかは順に見ていきましょう… やってみよう Dataflow のプログラム、というか Apache Beam SDK は (少なくとも初見では) 単純なつくりではなく、かつそれ自体を使うための事前準備が多く必要な類のものです。今回は Java で こちらの document に沿って進めてみます。 環境は、新しめの Java と maven が入ったものがあればよさそうです。構築手順に関しては長くなるのでここでは触れません。 前回利用した、“Word Count” が例というかスタート地点として利用できそうなので、まずは上記 document にあるまま以下のように実行します。 $ mvn archetype:generate \ -DarchetypeGroupId=org.apache.beam \ -DarchetypeArtifactId=beam-sdks-java-maven-archetypes-examples \ -DarchetypeVersion=2.46.0 \ -DgroupId=org.example \ -DartifactId=word-count-beam \ -Dversion="0.1" \ -Dpackage=org.apache.beam.examples \ -DinteractiveMode=false これで、Word Count のソースを含んだ開発環境が手元につくられます。 大量のソースコードが download されます。非常にシンプルなものをつくりたい場合に、ここから必要なものだけを残して使うという作業だけでもちょっとした手間そうなので、もうすこし簡易なスタートがあるといいなと思いました。今回は不要なものは無視して、メインの処理を追ってみましょう。 Word Count のメインの処理は、word-count-beam/src/main/java/org/apache/beam/examples/WordCount.java にすべて書かれています。そんなに量がないのでがまんして眺めてみると、最後に近い場所に以下のように書かれています。 p.apply("ReadLines", TextIO.read().from(options.getInputFile())) .

パブリッククラウドでよくマネージドで提供されているサービスのうち、活用が大きなアドバンテージになると感じるものに、リアルタイムの逐次データ処理、streaming data 処理があります。これを実現するために、OSS はじめ多くのベンダーからもさまざまなものが提供されていますが、GCP で streaming data 処理といえばやっぱり Dataflow です。(独断と偏見) Streaming data 処理とは 単に streaming data 処理というとさまざまな単位や仕組みのものがありますが、ここではネットワーク等の IO から流れてくるデータを集めて逐次処理するようなものを扱うこととします。 具体的な例 たとえば、こういった機能が効率的に実装できます。 エンドユーザーのログインイベントを集めてリアルタイムでアクティブユーザー数を計算する CPU 使用率などのモニタリング指標を集めて 5 分間隔の平均をグラフ化する 一日に一度、データベースのデータを集計する 最後のものは通常、どちらかというとバッチ処理と呼ばれるものですが、Dataflow (等) を使うと、こういったバッチ処理を効率的に実装することもできます。 「いつくるかわからないデータを待ち受け、それをある程度の単位でまとめて、データの内容によって複数の処理をし、別のデータベースなどに保存するといった処理」は、ゼロから実装しようと思うとなかなかめんどうなものです。テストもとてもめんどうです。それが streaming data 処理フレームワークを使うことで、データ処理部分の実装に集中することができるようになります。 Dataflow とは GCP で提供されているフルマネージドのデータ処理サービスです。 https://cloud.google.com/dataflow Apache Beam という OSS があり、これを利用して処理を実装することで、抽象化したデータを共通のパイプラインで処理できます。(というか Beam はもともと、Dataflow の framework を OSS 化したのがはじまりだったとか 1) Beam が support する IO、つまり入出力の種類は こちら にリストがあります。 これらを input、output として間にいろんな処理を組み込むことができます。 ただ Beam を使った実装が独特で、触れる機会が多いコマンド形式のプログラムや REST API 実装などともかなり違っていて、streaming data 処理のコンセプトとあいまって最初の敷居が高く、自由に実装できるようになるまでにはある程度の慣れが必要という感覚があります。

Windows container …? ホシイです。 ふだんからひたすら container 技術についての情報を web で漁っていると、YouTube を開けば技術系の動画に混ざってコンテナ船舶 (実体) の動画もおすすめされるような状態であり、果てにはそれも視聴してしまいああこれはなるほどすごい技術だなあ。と感心したりなどする日々を過ごしております。 そんな日々の中であっても、なかなか気づかないことはあるものです。あるときふと Windows container という言葉に行き当たったときに、おやとなりました。WSL などはふだんから触れる機会はありますが、Docker で Windows container? さらには Kubernetes でも Windows container? はて? となり、これはひとつ調べて・やってみたくなりましたという次第です。 Windows container を Docker Desktop で実行するための条件 いくつかの条件をクリアすると、Windows container を Docker Desktop を使って実行できます。 (ここがこの記事のハイライトです) host が Windows であること host の Windows version に 互換性がある container image を選択する こと Docker Desktop で WSL 2 backed engine を有効に しない こと (後述) Windows (host) で Hyper-V、Container 機能が有効になっていること (後述) Windows 11 でも同様かなと思うのですが、確認できていません。今回の実験は Windows 10 で行っています。

日々GitHub上で管理されたファイルを編集していて欠かせないことの1つに「Pull Requestを作る」があります。 Pull Request（以下プルリク）の説明文はMarkdown記法をサポートしているので、箇条書きやWeb上にあるドキュメントへリンクなどを気軽に書くことができます。 ところで、プルリクの説明文やいわゆるREADME.mdのようなMarkdownで書かれた内容は直接GitHub上で表示されるのではなく1、別途HTMLに変換されて表示されます。 プルリク作成の画面ではMarkdownの編集モードとPreviewモードが別タブで用意されているのですが、本ブログ内でたびたび登場するVSCodeなどのエディタではMarkdown形式の内容とその描画結果を横に並べて確認しながら編集が可能なので、プレビューモードと編集モードを都度マウスで切り替えることが手間に感じることがあります。 プルリクをローカルで作る そこで、プルリクの説明文をローカル環境で作成することにしました。…といっても、例えば body.md 等適当に命名したファイルに説明文を書き、都度プレビューするのみです。 このファイルの中身をプルリクの説明文にそのまま転記してもよいのですが、GitHub CLI を使うと以下のコマンドでブラウザなしにプルリクが作成できるので重宝しています。 # -F で説明文を記載したファイル名を指定 # --reviewerでレビュワーも併せて指定できる $ gh pr create --title "プルリクタイトル" -F ./body.md --reviewer someone GitHub Flavored Markdownもプレビューしたい 多くの場合前述の方法で問題ないのですが、不満に感じることが出てきました。それは、GitHub Flavored Markdownがプレビューできない場合があることです。 GitHubのMarkdownは厳密にはGitHub Flavored Markdownと呼ばれるMarkdownの方言に従い、いくつかの拡張構文があります。 基本的な内容はこちらにまとまっていて、私が個人的によく使うのは「プルリクエストの参照」です。 他にもこちらで触れられている「タスクリスト」（チェックボックス）をよく使いますが、いずれも少なくとも202301末時点のVSCodeの標準のMarkdownプレビュー機能ではサポートされておらず、プレビューできません。 例えば 以下のように記載した際、GitHub上では #1 が1番のプルリクへのリンクになりますが、（当然ではありますが）VSCodeではリンクにはならずそのまま出力されます。 過去のプルリク、 #1 では... これをリンクとして表示されるか確認したいと思っていたところで GitHubが公開しているWeb APIの中にMarkdown API（20221128現在）を見つけました。 このAPIは Use the REST API to render a markdown document as an HTML page or as raw text. とあるように、Markdown形式の内容を入力することで対応するHTMLファイルを返してくれます。

こんにちは、ホシイです。 これを読んでいるあなたは、自分が AI ではないという確たる自覚をお持ちでしょうか? 🤔 無作為に並べ替えがしたい コロナ禍以降、わたしの所属するチームでは、オンラインでデイリーミーティングをしています。日々の状況・情報の共有について、チームメンバーがひとりずつ順に数分話すのですが、毎日順番がおなじだとつまらないので順番を変えるようにしています。最初の頃は心のなかでテキトーに順を決めていたのですが、なにしろ面倒ですし、議論が盛り上がったときなどは抜けてしまったりなんならおなじ人を二度呼んでしまうこともあったりしました。こういうのはまさに機械が得意なことです。 ミーティング前に手元でぱっと node で実行できるように、JavaScript のワンライナーを書きました。 ["幸", "中原", "宮前", "川崎", "高津", "多摩", "麻生"].sort(() => Math.random() - .5) やっていることは非常に単純で、sort() に使われる比較で、内容 (名前文字列) を無視して毎回 random() で 1/2 の確率で基準を変動させています。これでランダムに順番が変わるでしょう。 よしよしと 2、3 日これでやってみたのですが、どうも結果が偏っているように感じます。 手元で何度か実行してみると、体感でわかるくらいに。なんとなく、元の配列から順番が変わっていない要素が多いように感じるのです。 実際に数千回ほど実行してカウントしてみると、ソート先の場所に大きく偏りがあることがわかりました。以下は、先頭の要素が最終的にそれぞれの位置に落ち着いた回数を示すグラフです。 多少の偏りはたのしめる要素ですが、これではちょっと極端です…。 また、端に近い要素 (先頭、末尾に近い要素) ほど偏っている様子がありました。 考えてみるとたしかに、sort() するときに順番を変える比較基準が五分五分で毎回変わると、元の位置からあまり離れていかないような気もします。(sort の algorithm 次第ではありますが) そこで、以下のように処理を変えてみました。 ["幸", "中原", "宮前", "川崎", "高津", "多摩", "麻生"] .map(o => ({ n: o, r: Math.random() })).sort((a, b) => a.r - b.r).map(o => o.

Helmにおけるテンプレートを別ファイルに分ける仕組み Helmで0とdefaultを区別するに引き続きHelmの話題です。 Helmでテンプレートを記述するとき、基本的には以前の記事のようにマニフェストのYAMLファイル内に直接記載しますが、時にはテンプレートを別のファイルに分けたい場合があります。 例えば、複数マニフェスト間で共通のテンプレートを使いたい、ConfigMap/Secretを構成する設定内容を別のファイルで管理したいといった動機があります。 このとき、Helmではいくつか選択肢があり、使いわけに躓いたのでまとめます。 要約すると、 方法 使い分け template テンプレートを処理の内容で識別したい場合。ただし、基本的にincludeで良い include template に加えてテンプレート描画結果に対して追加の処理を行いたい場合 tpl テンプレートをファイル名で識別したい場合 と考えています。 以下に詳しく違いをまとめていきます。 template と include helm create でchartを作成した際に生成されるテンプレートに例があるので見てみましょう。 helm create template_test として作成したchartにある templates/_helpers.tpl 1 を見ると、 {{-define"template_test.chart"-}}{{-printf"%s-%s".Chart.Name.Chart.Version|replace"+""_"|trunc63|trimSuffix"-"}}{{-end}}という部分があります。これにより、 define ～ end 間のテンプレートを template_test.chart という名前でinclude、または template で参照可能になります。このテンプレートでは、 .Chart.Name でchart名（今回はtemplate_test） .Chart.Version でchartのバージョン（Chart.yaml に記載の値。初期値は0.1.0） を展開します。 適当なConfigMapを作って試してみると、 apiVersion:v1kind:ConfigMapdata:chart_name:|{{ include "template_test.chart" . }} {{ template "template_test.chart" .

開発作業を中心に様々な用途で非常に便利な devcontainer 機能ですが、container 内 workspace の disk 性能が遅すぎる問題のために実用に耐えないといったことがあります。 devcontainer において disk が遅いと感じるのはおそらく、host 側にある folder を開いて devcontainer を起動した際に、その folder が性能が低い filesystem で bind mount されるからです (と思っています)。 かんたんな作業であれば気にならないのですが、身近なものでは npm install したようなときでもわりと気になりますし、大きな project の build となるとかなりの問題となることもあります。 公式: Improve disk performance にも専用の項目があったりします。named volume を使って解決をしよう、という内容です。 計測してみる では、bind mount と named volume でどのくらい違うのでしょうか? devcontainer.json に mount を追加して検証してみます。named volume nv-proj を mount し、user vscode から利用できるようにしています。bind mount は、devcontainer で自動的に mount される workspace (devcontainer.json を含む場所) を使用します (ので以下の設定には明示されていません)。 { "name": "Ubuntu", "build": { "dockerfile": "Dockerfile", }, "remoteUser": "vscode", "mounts": [ "source=nv-proj,target=${containerWorkspaceFolder}/named-volume,type=volume" ], "postCreateCommand": "sudo chown vscode:vscode named-volume" } mount で確認します。それぞれ fuse.

こんにちは、ChatGPT です。 嘘です。ただの情シス部員のホシイです。 エンジニア組織がある多くの会社ではよくあるように、弊社でも、エンジニアが自身の業務に係る内容を社内向けに発表する機会が様々あります。その中でもおおきなものが昨年の末に企画されておりまして、その場でお話をさせていただける貴重なひと枠をいただきました。ひとり一枠 50 分 (うち 10 分は質疑応答) となかなか長めのものでしたので準備がちょっと心配だったりもしたのですが、なんとか完走することができました。 今日は、その場でお話ししたことをダイジェストでお送りしたいと思います。ぜんぶだと 70 スライドほどありちょっと長いのと、社内限定情報を削除したり、記事としての体裁に合うようにすこし編集を加えたりしています。 また、社内版では “弊社らしい” 非常に素敵な背景がついていたのですが、残念ながらこの場では様々大人の事情により、白一色背景の味気ないスライドでお送りします。(イラストはよく いらすとや さんのものを使用させていただいております。ありがとうございます) ※ 内容は一部のシステムでの一例であり、全社での取り組み・ポリシーではありません。 タイトルは、“15分でできるサーバー環境構築” としました。 テスト環境や QA 環境など、サーバー環境構築ってしんどいものですよねという課題の確認から、近年のさまざまな仕組みの活用によりこれくらい楽にできる例がありますよというストーリーです。15 分というのは結果それくらいでできるようになりましたという数値なのですが、これは 15 分くらいの作業をがんばることでできるということではなく、実際にはコマンド (helm install) を打ってしまえば作業的には完了で、あとは待つだけです。 今回 VM host ベースの環境から Kubernetes で動作するものに変えたのですが、アプリケーションの依存関係がじゃっかん複雑なため、環境構築完了までは Kubernetes の reconciliation を待つだけであるとはいえ、これが 15 分くらいかかるのです。 必要性が上がっている理由として、単に環境を増やしたいというモチベーション以外にも複数の事情があり、またその重要性が増してきています。 さまざまな現場がありますが、インフラ担当チームがわかれている現場ではこのような景色感になっていることが多いのではないでしょうか。開発チームからは環境構築の様子や手法などは認識せず、インフラチームにおまかせしている状態です。開発チームとしてはおねがいするだけなので楽な状態ですが、インフラチームは開発チームの要件をしっかり把握する必要があり、負担が高そうです。 そこに対して IaC を取り入れ、開発チーム主体にしてしまおうという図式です。物理サーバーをデータセンターで扱うインフラでは難しいことですが、クラウドや仮想環境を整備することで容易になります。ただし、すべてを開発チームで完結するのはかんたんではありません。引き続きインフラ担当チームと分担をしていく体制が望ましいでしょう。ネットワークやストレージ、データベースのような領域は一般的に開発チームのスキルセットでは不十分なことが多く、本番環境のみならず外部連携が必要なテスト環境などでも課題が残ることが多いです。 わたしは IaC するなら “3 環境以上はいくつでもおなじ” という感覚でやるべきと思っており、それを伝えるべく示したイメージです。 環境を気軽に増やすにあたりこれが非常に重要なポイントです。環境ごとに差分があるとそれが新しい環境構築の障害になります。たとえばこの環境にはこの機能が無い、この環境では DB の数・種類が違う、またこの環境ではアプリケーションバージョンが違う… 等々です。こういった差を極力小さくしていくことにより、環境を増やすことが楽になりますし、環境によって差がないので動作を見る・利用するときにも誤解がうまれることが少なくなります。 ここに関しては具体的な例をとっていくつか掘り下げた話をしたのですが、ここでは割愛させていただきます。またの機会に別の記事ででもご紹介できたら幸いです。 またすこし観点が変わりますが、自前実装部分の存在が、仕組みの載せ替えの障害になることがあります。OSS や公開された仕様に乗っていると、それを活用した別の OSS が利用できたりして、結果的に工数削減ができることがあります。逆に自前実装からそれを解決するにはまたそのための自前実装の追加が必要になって… というパターンにハマっていきがちです。

あけましておめでとうございます。 本ブログ。まだ開始して一年も経過していませんが、ようやくまわりはじめてきた感がしてきております。IT 関連企業界隈ではすっかり一般的になりました技術ブログの花盛りという様相ですが、弊弱小ブログもまだまだなんとかがんばっていきたい所存であります。 ブログを開始してわたし自身さまざま勉強になったこともあり、他社様で同様の業務に携っておられるかたも増えてきていることと思われますので、今日は、このブログがどのように運営されているか、システムや人の面を含めて少しご紹介できたらと思います。 システム・制作プロセス まず、肝心のブログシステムとしては Hugo を採用しています。cgi 的にサーバーで動作してページを配信するのではなく、手元で build を行うとサイトに必要な file 群を生成してくれる仕組みになっていて、あとはそれを静的に hosting するだけで済みます。これまでブログ運営をしたことのなかったわたしにとっては、これだけでも新鮮で勉強になりました。このタイプのもの自体他にも複数種類あったりしますが、その中でも Hugo を選定した理由としては、すこし触ってみた段階で直感的なところがよさそうに感じたことと、すでに以前使ったことがある人がいたことあたりが決め手になりました。 記事はすべて markdown で書かれていまして、サイト生成に必要なものはその記事も含めて GitLab で管理しています。記事を書いている間は Hugo が持っている server 機能を使うことで手元ですぐに確認ができ、非常に便利です。記事を書く人がおのおので記事内で使う画像も用意していて、GitLab 上でまとめて review されるようになっています。 サイトを build したら、まずは container image として build し、それを preview、staging サイトに反映させています。現状 CI/CD の準備が間に合っておらず、このあたりは手で行っています。container の実行環境としては、今回はたまたまふだん使っている GKE cluster がありましたので、そこを間借りして専用の namespace をつくり、使用しています。この環境ではもともとアクセス制限も準備していたので、その準備の手間が省けたのはたすかりました。 そして review の過程が終わり、社内限定の最終確認環境と本番 (一般公開) 環境に持っていくのはどうしているかといいますと、こちらも現状 CI/CD の準備がなく、更新ごとにわたしが心をこめて upload しています。しかもここは実は長らく SPOF(人間) だったのですが、ようやく運営メンバーも増えまして体制として整ってきつつあります。 とはいえやはり手動だと安定感が欠ける運用になりがちなので、ここはなんとかシステム化していきたいところです。 本番環境 web server 自体の管理は我々としては管轄外で、専門部署 (念の為、これも我らが情シスです！) に面倒を見てもらっています。当ブログは (他重要システムと違って) しばらく止まっているくらいなら大きな影響はないので、わたしとしては気楽に構えています。 制作メンバー・協力 記事を書いているメンバーはサイトを見ていただけますとだいたいご想像いただけそうですが、まだまだ少なく、数人程度でまわしています。その他にもレビューのみ参加してくれているメンバーも数人います。最近 執筆者一覧ページ もできましたので、よろしければそちらもご覧ください。

この記事はAWS for Games Advent Calendar 2022の25日目の記事です。 皆さんはログの扱いに慣れておりますでしょうか？ 必要なログは全て綺麗に ETL していつでもばっちり見れる状態です！ となっていればどんなに良いことか、、中々後回しにされがちな部分かと思います。弊社でも様々なゲームが平行稼働している中、 大量のログがローテートされてサーバから消えていく タイトル別でうまくいい感じに一か所で管理したい 何かインシデントが起きた時、急いでいる時にサーバに SSH してログを漁りたくない さっと見れるようにしたい みたいな話がありつつも、中々手を付けられずにいました(主に syslog 周り)。今回 AWS さんの協力もあり、技術取得の一環で検証をスタートしてみました。「ログを S3 に集めて、 Glue でなんやかんや加工してみて、 Athena でいい感じに閲覧してみたい。」 みたいなことを考えている人には刺さるかもしれない内容となっています。 本題 今回、収集対象としたログは 「 audit 」「 messages 」「 secure 」「 nginx ( access , error ) 」 の4つです。ゲームログも集めてみたいな～と思いつつ、まずは検証としてわかりやすい syslog 周りからやってみました。 ※ただし、後半のログの加工は audit ログのみとなっております。(すべてを検証しきれず。。) ご了承頂ければと思います。 全体フロー 早速ですが、結論から。最終的には(現時点で)以下のような構成になりました。 順を追って説明します。 収集 まずは各サーバからログを集めて S3 バケットに格納するまでの部分です。 図でいうと、以下の部分となります。 ここではあまり難しいことはしておらず、

開発環境としての Windows に興味が尽きないホシイです。 WSL が使いやすくなり、Linux を target とした server application の開発環境としての Windows 活用も、すこし様子が変わってきているように感じます。 ゲーム開発などでの Windows 活用の有用性は言うまでも無いですが、かたや、特に我々のように本番環境の target を Linux としている backend engineer 向けには、Windows を使うこと自体が足かせとなることもままあることには注意が必要でしょう。 (もちろん、Windows Server を使用している場合はまったくその限りではありません。) 2022 と題したわりには古い話ばかりだったりしますが、年の瀬ということで、今回はそれらについてまとめてみたいと思います。 Windows 問題の例 CRLF 問題 Windows では標準の改行コードが CRLF (\r\n)、Linux では LF (\n) であり、そのまま使用すると一部の状況で問題となることがあります。 たとえば、shell script の shebang です。 #!/bin/sh(CRLF) このように、一行目に書いておくことで interpreter を指定するものですが、上記のように CRLF で終わっていると shell が /bin/sh(CR) を探してしまい、そんなものはありませんよ、となってしまいます。 ❯ ./test.sh zsh: ./test.sh: bad interpreter: /bin/sh^M: no such file or directory これを解決するには、以下のようにします。 ※ 実行形式 binary file などにも適用してしまうとこわれてしまうので対象に注意しましょう

備えあれば憂いなし web サービスを運用していると、不測の事態というのは起きるものです。 プログラムのバグであったり、ハードウェアの障害や性能不足であったり、時には理由がわからないが何かしら動かない、でも早急になんとかしないといけない… なんていうことが。もちろん、事前の準備は万全にしつつ、そういったことが起きないことが最善ではありますが、起きたときのために備えておくのもたいせつなことです。 今回は “HTTP で送られた request 内容を見て、条件によって処理する backend をわけたい” という仮想シナリオをたて、これをなるべくかんたん・じゅうなんに解決できる手段を考えてみます。 Envoy? 近年様々な用途で使われている高機能 proxy、Envoy。きっと Envoy ならこんな要求なんてかんたんにこたえてくれるだろう。という期待を持って軽い気持ちではじめましたが、結果を先に言うと非常に苦労しました。もし本番環境で問題が発生してから準備をはじめていたら… とぞっとします。今回は心に余裕を持って。では、やってみましょう。 以下、先日 install した Rancher Desktop の環境 を使い、Docker Compose で Envoy、Nginx container を起動して相互通信しています。 Envoy の設定を書く さっそく、Envoy の設定をつくります。これさえできれば終わったようなものですが、これがたいへんでした。 今回は “じゅうなんに” ということで、Lua filter を使います。Lua で request、response の処理を組めばかなりいろんなことができるようですが、これを実現する例や document がなかなか見つからず、非常に苦労しました。 以下に動作する envoy.yaml を置いておきますので、試行錯誤や様々な要件に合わせての検証にご利用ください。 HTTP request から JSON POST body を受け取り、そこに特定の文字列 (例では “1234”) が含まれていたら特定の backend に route させるという例になっています。 admin:address:socket_address:{address: 0.0.0.0, port_value:9901}static_resources:listeners:- name:listener_0address:socket_address:{address: 0.0.0.0, port_value:9902}filter_chains:- filters:- name:envoy.filters.network.http_connection_managertyped_config:"@type": type.

Helm Kubernetes (k8s)のパッケージ管理を行うアプリケーションとしてHelmがあります。 Helmではテンプレートによって使うimageのタグやDeploymentのPodの数といった設定値をデプロイ時に注入することが可能になっています。 Helmのこのテンプレートファイル群の単位をchartと呼びますが、私のチームでchartを管理する中でoptionalなパラメータを表現しようとして躓いたのでまとめます。 chartの設計上、optionalなパラメータをhelm templateで表現する必要がない場合が多いと思われますが、要件の都合や運用の都合で明確に区別したいという場合に参考になれば幸いです。 やりたいこと Helmで注入する設定値 values.yaml が以下のような構造になっているとします。 setting:foo:100bar:"test string"このとき、この値を注入したJSONファイルをConfigMapとして作成したいです。 { "foo": "100", "bar": "test string" } そのためには、以下のようなテンプレートを用意すればいいです。 --- apiVersion: v1 kind: ConfigMap metadata: name: sample data: sample.json: |- { "foo": {{ .Values.setting.foo | quote }}, "bar": {{ .Values.setting.bar | quote }} }実際にテンプレート処理を試してみましょう。 > helm template ./sample-chart --- # Source: sample-chart/templates/sample.yaml apiVersion: v1 kind: ConfigMap metadata: name: sample data: sample.json: |- { "foo": "100", "bar": "test string" } 問題なさそうです。 ところで、我々のアプリケーションではfooは多くの場合で数値ですが、いわゆるnullの意味を持たせて "foo": "" と設定したい場合もありました。

はじめに こんにちは、情報システム部 SRE 橋本です。 普段はクラウドエンジニア(SRE)としてチームリードをしています。興味関心がインフラ、Observability、SRE、Security、Golangといった分野であり、 Japan Google Cloud Usergroup for Enterprise(Jagu’e’r ジャガーと読みます)でObservability/SRE分科会のオーナーを担当させていただいております。その縁もあって先日Innovators Hive at Cloud Next 2022でコミュニティ運営についてお話をさせていただきました。 この記事では現在チームリードをしていてビルドアップ中でもあるSREチームについて考えていることをお話したいと思います。 また、このSREチームについてのインタビュー記事も掲載いたしました。メンバーやチームの雰囲気を伝えたいと思って作っておりますので、よろしければご覧ください。 本記事は以前Jagu’e’r分科会で発表した資料を交えてお話をします。内容はシステムやSREとしてやることというよりも、チームや組織についての現在での考え方に重きをおいて書いています。 我々のSREチームについて タイトルに”とあるシステム”とつけているのは、当社ではゲームやシステムによっていくつかのインフラチームが存在しており、その一部のチームやシステムであることを意味しています。あくまで一部でのSREに関することを書いており、スクエニ全体での取り組みではない点をご承知おきください。我々は下の図で吹き出しがついているスマートフォン系のバックエンドシステムを担当するチームになります。 システムと組織の変遷・クラウドネイティブ化との関わり システムと開発チーム・インフラチームの関係性 下図はシステムとそれを取り巻く組織の遷移を簡単な図にしたものです。一番左側の列ですが自社のデータセンタ（DC）でインフラエンジニア（図のInfra Engrs）がサーバ等のインフラを構築し、開発エンジニア（図のS/W Engrs）がプログラムをデプロイしてサービスを提供している様子を図式化したものです。ビルが立ち並んだアイコンはDCをイメージして貼り付けています。 真ん中の列はDCがクラウド（雲の形のアイコン）に変わっています。2010年代からさまざまなクラウドが誕生し当社でも活用されてきました。ただ、サーバが稼働する場所は変わるものの組織としての形は大きく変わりませんでした。物理的なサーバが仮想マシン（VM）になったり、ラッキングや障害ディスクの交換など物理的な作業がWebGUIやAPI実行、コマンド操作等に置き換わるなどしたものの、サーバを構築し維持運用するインフラチームとプログラムを開発・メンテナンスする開発チームという図式は大きく変わることがなかったと思います。 そして、一番右側の列です。「〜5、10年後？」と表現していますが、クラウド化が進むにつれてエンジニアの組織体制も変わるであろうことを図式化したものです。 クラウドネイティブによって感じる変化 システムがよりクラウドに適したものに変わることをクラウドネイティブの一つの意味だと考えていますが、それによって組織の形態も自ずと変化するであろうということを図で示しています。これまでサーバを中心にインフラが構築されてきましたが、今後はPaaSの活用やKubernetesのようにマニフェストを元に開発エンジニアが比較的容易にワークロードをデプロイすることが出来るコンテナ実行環境が一般化することで、「インフラエンジニアがサーバを作り、それを開発エンジニアに引き渡す」という形態が少なくなってくるであろうと想像しています。 例えばKubernetesでシステムを構築すると、しばしば開発エンジニアとインフラエンジニアの組織で何をどこまで管理するのか明確に線引することが難しいと感じることがあります。「クラスタはインフラエンジニアが見ると良かろう。ではマニフェストは？コンテナイメージは？」などと悩んだ経験は皆さんもあるのではないでしょうか（図での”交じる”の部分）。 またインフラエンジニアにとっては、開発エンジニアに近い立ち位置でシステムに関わるようになったり、VMなどよりもより抽象化されたシステムを扱うようになることで異なるスキルセットが必要となる場面が増えてくるのではないかと考えています（図での”異なる”の部分）。 そのような変化から自然と開発・インフラエンジニアという別のチームではなくソフトウェアエンジニア（図では SoftWare EngineerSとしてSWEsと記載）、インフラ寄りに詳しくサイト信頼性を担保するエンジニア（図ではSite Reliability EngineerSとしてSREsと記載）がより近いところで一緒に活動するようになるであろうと考えています。 目指すクラウドエンジニア(SRE)の定義と仕事 いままで記載した考えはあくまで筆者の私見ではありますが、この考えに基づいて記述したSREの募集要項を一部抜粋したものになります。非常に風呂敷を広げた内容でまだまだこれを目指している途上ですが、これを目指して現在チームを作っている状況です。 クラウドエンジニア(SRE)の価値提供 ステークホルダと提供する価値の整理 先の募集要項の抜粋では文章でSREが遂行することの定義を記載しましたが、図式化したものが以下の図になります。 SREにとっては左からエンドユーザ様（User）、サービスインフラ（図のサーバのアイコン）、開発者（Developer）がそれぞれ価値提供先であり、図のような提供価値であると整理しています。 提供価値がいっぱいある！ 簡略化すれば先の図の通りではあるのですが、実際の業務となると沢山あります。一例として以下の図になりますが表現しきれないものが沢山あります。 顧客の満足（users’ happiness）や開発者の満足（develpers’ happiness）を追い求めるべくやるべきことがいっぱいありつつも、自らの業務の足場を固めるために自動化やトイルの撲滅もしたい、SLI/SLOの定義もしたい…などとやるべきこと、やりたいことが溢れて何から手をつけるべきか分からなくなったという経験はないでしょうか。わたしはそのような状態に陥った経験があります。 まずはできるところから・続けられることから 様々なことを遂行するにしても自分たちがパフォーマンスを出し続けれなければ、結果的に顧客や開発者への価値提供もままならないと考えています。まずは自分たちの満足度があがる・モチベーションが保てるものから手を付けていくと良いのではないか、ということで、少しネガティブな聞こえがあるかもしれませんが”自己中心的”と下図では表現しました。

日常的に Docker Desktop を使って快適にお仕事しているホシイです。 しかし Docker をそう頻繁には使わない方や、エンジニアでない方に実行環境を渡したいだけなので単に実行するだけでよいとかいった用途に、Docker Desktop 以外の (ライセンスの縛りが無い・ゆるい) 選択肢もほしいという声を時折聞くようになりました。 そこで… Rancher Desktop? 折しも Docker Desktop の値上げニュースが話題になってもおり、Rancher Desktop でもおなじようなことができると聞いたので、今回はその使用感を試してみたいと思います。 ただし業務で使っている環境はこわしたくなく、今回使ったのは私物 PC の Ubuntu Desktop 環境、先日 upgrade した version 22.10 です。いくつかのことを検証しましたが、機能的には Windows などで使うのとそう差はないのではないかと思います。(WSL と組み合わせての部分が今回は検証できていないですが…) ではいってみましょう。 既存 Docker の uninstall まずはもともと入っている Docker を根こそぎ消します。apt で入れていたので、そのまま 公式手順 に従って実施します。 基本的には apt purge するだけですね。 nerdctl + containerd を試す 次に、本題からすこしそれますが、nerdctl + containerd という構成も試してみたく、こちらを先にやってみました。 これもさほど迷うことはなく、こちらの Install 手順 に沿って進めます。 依存関係で必要なものがすこしわかりづらかったのですが、わたしの環境では以下が不足していて追加しました。環境によってご調整ください。 apt install するもの containernetworking-plugins rootlesskit slirp4netns BuildKit https://github.

スクウェア・エニックスで多分サーバーエンジニアと呼ばれるお仕事をしているBです。 オンプレミス環境でDockerやPodmanのコンテナを利用していると、プライベートレジストリを建てる必要性が出てくる場合があります。 そして、プライベートレジストリを建てると今度は安定した稼働のために、ミラーレジストリ的な何かを建てたくなるかと思います。 今回は、完全なミラーレジストリとはいきませんが、キャッシュレジストリを簡単に建てる方法をご紹介します。 キャッシュレジストリに何を使用するか レジストリを簡単に建てる方法として、Docker Registry があります。 本当に簡単で、最低限の設定であれば次のコマンドでサービスを立ち上げることができます。 $ docker run -d -p 5000:5000 --name registry registry このDocker Registryはキャッシュ機能も備わっています。 Mirroring Docker Hub のページを見ると、 次のように設定すれば良いと書いてあります。 Configure the cache To configure a Registry to run as a pull through cache, the addition of a proxy section is required to the config file. To access private images on the Docker Hub, a username and password can be supplied. proxy:remoteurl:https://registry-1.docker.iousername:[username]password:[password] 一見すると、ページ名と見出しの通り、Docker Hubに対してのみ働くキャッシュ機能のようですが、実はその他のレジストリに対しても認証含めて問題なく機能します。 (この機能があまり知られていないようなので、今回この記事を書いています。)

こんにちは。未だに競馬で当たったことがないホシイです。 今日も、クラウド機能をお手軽に使ってみるお試しネタをひとつお届けします。 オンプレでも Cloud Logging を使いたい… ふだん GCE や GKE を使っていると、非常にすんなり Cloud Logging に log が入ってくれるので、オンプレサーバーを扱っているときにもこれが欲しくなります。というか、なんで無いんだ！という気持ちになります。 たとえば httpd の log を Cloud Logging で見たい！だけなのに、一直線のサンプルが見つからなかったのでつくってみました。 container でお試しセットをつくる いつも思うんですが、目的の最小構成がすぐに確認できる container image があると便利だと思うんです。 ということで、container でやってみます。 今回はオンプレで使っているちょっと古めのサービスを想定して、最近活躍を見る機会が減ってきた (個人の感想)、Apache2 httpd さんを使ってみましょう。 以下のように、Fluent Bit と Apache2 を入れた Dockerfile をつくります。 FROMubuntuRUN apt update && DEBIAN_FRONTEND=noninteractive apt -y install --no-install-recommends \ sudo git netcat wget gnupg ca-certificates apache2 && \ # Add user & group groupadd demo && \ useradd demo -g demo -m -s /bin/bash && \ echo "demo ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers && \ echo "done.

Cloud Functions GCPが提供しているFaaS（Function as a Service）にCloud Functionsがあります。 これは、Googleが管理するインフラのもと、ユーザが登録したソースコード（関数）を実行してくれるサービスで、2022年9月現在、以下の言語をランタイムとしてサポートしています。1 Node.js Python Go Java .NET Core Ruby PHP 私のチームではGoを使ってFunctionを実装しているのですが、この記事ではその際のローカル開発環境について紹介します。 以降、本稿ではソースコード中の関数は「関数」、GCP上のCloud Functionsにおけるリソースとしての関数は「Function」と表現します。 ローカル開発環境 ローカルでの開発（Cloud Functionsのドキュメント）より、 関数をローカルで実行するには、Function Frameworks または Cloud Native Buildpacks を使用します。 とのことなので、今回はFunction Frameworksを使います。Go言語におけるFunction Frameworkのリポジトリは https://github.com/GoogleCloudPlatform/functions-framework-go です。 2022年9月現在、Cloud FunctionsにおけるGoの推奨バージョンは1.16です。 Go 1.16以降ではデフォルトではModuleモードがデフォルトに、依存関係の追加には go install より go get が推奨されるようになった 2 ので、以下の手順でモジュールを作成、及び依存関係の追加を行います。 $ go mod init example.com/gcp_sample_func $ go get github.com/GoogleCloudPlatform/functions-framework-go/funcframework $ grep functions-framework-go go.mod require github.com/GoogleCloudPlatform/functions-framework-go v1.6.1 Hello World Goランタイムの場合、HTTPリクエストによるトリガーをサポートしているので、HTTP GETに対して単に"Hello World" のみ返すFunctionを実装してみます。

ホシイです。 Docker の利用シーンが増え、IaC の出番が増え、… で確実に増えたのが、shell script を書く時間です。以前はそんなに書いていなかったのでテキトーに済ませてきたのですが、調べるたびに便利な機能があるものですね。 bash script を書いていて、アレ、どうやって書くんだっけ… ということが非常によくあります。今回はそんな便利小ネタを (すぐに忘れてしまう自分の備忘のために) 書き出してみました。独断と偏見の、わたしのお気に入りセレクションで失礼いたします。 変数文字列から一部を取り出す 変数に file name が入っているが、その拡張子をはずしたいということがよくあります。 $ A=aa.tar.temp && echo ${A%.*} aa.tar ${...} の中で % を使っているのが、変数値の右端から pattern match した部分を削除するという意味になっています。類似で %% や # ## などもあります。 変数値に文字列を足した文字列を追加する file name に何かを足して cp したいみたいなこともよくあります。 $ cp temp.txt temp.txt.b これは、以下のように短く書けます。 $ cp temp.txt{,.b} これだけで、temp.txt.b にコピーされます。同様に、, の左右を入れ替えると逆 (末尾を削除) もできます。 ひとつ前のコマンド引数を再利用する とにかく、おなじことを二度書くのがめんどうだったり、↑ ↑ とやって history に探し当てても file name などの直値が入っていると置き換えないといけなくて使いにくいことってありますよね。 $ mkdir -p temp/temp/temp $ cd $_ $_ はひとつ前のコマンドの最後の引数をあらわします。これにより、mkdir した先に cd できます。