本投稿では、2022年3月11日に開催されたObservability Conference 2022 (以後、o11y2022)におけるライブ配信・アーカイブ配信をどのように実現したのか、主にRailsアプリケーションとAWSサービスについて紹介します。なお、OBSなどの配信基盤についてはこの投稿では触れません。 実現したいこと o11y2022の配信アーキテクチャでは以下の3点の実現を目指しました。 ライブセッションをできるだけ低遅延で配信する 事前録画セッションを配信する ライブセッション終了後にできるだけ早く、簡単にアーカイブ動画を配信する アーキテクチャ 主にAWSとRails、Reactを用いています。 AWS AWS Elemental MediaLive：配信チームからの配信データを受け取り、IVSやMediaPackageに流す AWS Elemental MediaPa
2020年8月から @june29 と キマグレエフエム というPodcastを配信していたのだが、なんと1年たっていた。最初はとりあえずやってみるかというノリで始めたのだけど、毎週配信し続けることができ、我ながら驚いている。 キマグレエフエム 2020年に音声配信がかなり盛り上がり、自分もやってみたいなと思ったのがきっかけ。当時、既にvlogをやっていたjune29に声をかけ、その週末にとりあえず1本収録した。最初はSoundCloud経由で配信していたが、すぐAnchorに切り替えてその後はAnchorを使い続けている。1年目の時点でエピソード数は74本。2020年は毎週末に2本収録して翌週2本配信していたが、2021年になってからは隔週の週末に2本収録して翌週と翌々週に1本ずつ配信するというやりかたに変えている。二人で収録・配信しているので、お互いが一番やりやすいように少しずつアップ
2020年2月19日に「Kubernetesで実践するクラウドネイティブDevOps」という書籍が発売されるのだが、レビュアーとしてお手伝いした。レビューとはいえ、雑誌ではない商業誌に関わったのは初めてなのでいい経験ができたと思う。ぜひ読んでみてください。 Kubernetesで実践するクラウドネイティブDevOps posted with amazlet at 20.02.13 John Arundel Justin Domingus オライリージャパン 売り上げランキング: 1,870 Amazon.co.jpで詳細を見る
認定された。普段からKubernetesを触ってきて、それなりに知識と経験は備えているとは思っているが、念の為Udemyの Certified Kubernetes Administrator (CKA) with Practice Tests コースをざっくりこなしてから受けた。結構知らないこともあったので、知識の補完ができてよかった。 パスポートはもともと持っていたし、受験は自宅で受けたのでそこまで大変ではなかった。部屋から本を出して物がない状態にするのが手間だったくらい。なんか、試験を受けるのが久しぶりで合格したのが結構嬉しい。
少し前、今年入社した人の研修に少し関わっていたのだけど、その時Slackに投下したテキストを手直ししてこちらにも書いておきます。 意識するといいポイントがあって、それは、何か困ったことがあったり、質問する時に「前提条件」と「期待していた挙動」、「実際に起きた挙動」を整理するといい。 「前提条件」は、例えば「自分が今動かそうとしているソースコード」「使っているソフトウェアのバージョン」などを指す。「期待していた挙動」とは、「何をしようとしているのか」や「こうなって欲しかった」などを指す。「実際に起きた挙動」とは、「実行したコマンドとその実行結果のログ」だったり、「操作した結果発生した挙動」などを指す。 これらの事実を質問者と回答者が共有することで、より適切な回答が行える。最初の質問に欠けているものがあると前提条件がずれて間違った回答をしてしまう可能性があったりする。リモートのエンジニアだった
ingress-nginxを使っているのだけど、中の仕組みをあまり知らなかったので調べた。まず、ngix-ingress-controllerからバックエンドへリクエストがどう流れるのかだが、簡単に以下の図のようになる。 nginx-ingress-controllerまでの流れはService Typeによるが、ここではNodePortを指定している。externalTrafficPolicyをClusterにしておくと、どのノードにリクエストが届いてもnginx-ingress-controller Podにルーティングされる。もちろん、Podが複数ある場合は、ロードバランスされる。 さて、気になるのはnginx-ingress-controllerから先。結論から書くと、IngressにのBackendに設定したサービスのエンドポイントにロードバランスしている。Podの中をみてみると
CRD/カスタムコントローラー周りの知識をつけたいと思ってちょこちょこ試していたのだけど、ようやく動くものを作ることができた。ものとしては takaishi/openstack-sg-controller で、kubebuilderを使って作った。これは何かというと、OpenStack上でKubernetesを動かしている時に使うもので、カスタムリソースを作るとそれに基づいてセキュリティグループを作成、ノードにアタッチしてくれる。 動作例 CRDを定義済み、Podが動いている状態で以下のようなカスタムリソースを作成する。 **apiVersion** : openstack.repl.info/v1beta1 **kind** : SecurityGroup **metadata** : **labels** : **controller-tools.k8s.io** : "1.0" **
v1.10より前のバージョンだと、apiserverででexperimental-keystone-url オプションを設定し、クライアントのkubeconfigでユーザー名とパスワードを設定すればkeystone認証できていた。しかし、v1.10ではこのオプションが削除されたため、別の方法としてcloud-provider-openstackを使う。このリポジトリはいろいろ混ざっていてややこしく、LBaaSやCinderとの連携機能についても提供している（別コマンド）。 さて、cloud-provider-openstackを使ってkeystoneによるユーザー認証を実現するにはクライアント側、サーバー側それぞれで設定が必要になる。クライアント側ではKeystoneからトークンを取得し、apiserverへ送る。サーバー側であるapiserverでは受け取ったトークンを使ってkeysto
今年の4月頃にgRPCの独自認証周りを調べて、勉強がてらそれを使ってツールを作っていた。ものとしては、サーバー側でタスクを定義しておくとgRPC経由で実行させられるというもの。リポジトリは takaishi/alpette。 挙動としては、まずサーバー側で以下のようにタスクを定義する。 [[tasks]] name = "foo" command = "echo this is foo" [[tasks]] name = "bar" command = "echo this is bar" そして、クライアント側からタスクを指定するとgRPCでサーバーと通信、サーバーはタスクを実行、実行結果を返すというもの。 $ alpette run --task foo サーバーで何かするときにSSHすることが多いと思う。しかし、SSHだと実行者が持つ権限が結構大きい。適切に権限を設定すればよいのだけ
HashicorpのVaultはPKI（Public Key Infrastructure、公開鍵基盤）として利用できるらしい。今回はRoot CAの作成、サーバー証明書の作成、クライアント証明書の作成と失効を試した。間違ってたらゴメンなさい。Vaultについての概要はWEB+DB PRESS Vol.104に記事が書かれているので読むとよさそう。 準備 Vaultのバージョンはv0.10.1。macOS用のバイナリをダウンロードして、PATHの通った場所に置いた。 ➤ vault version Vault v0.10.1 ('756fdc4587350daf1c65b93647b2cc31a6f119cd') curlはHomwbrewでインストールし、opensslを使うようにしている。 ➤ curl --version curl 7.59.0 (x86_64-apple-darwi
Knative EventingはGCP PubSubをバスとして使用することができる。他にも、Kafkaを使ったりもできるようだ。Knativeのオートスケール機能をminikubeで試したメモと同様動く様子を観察してみて、Serverless的な機能だということを確認できた。なお、今回はGKEを使います。 まずはGKE上にクラスタを構築し、IstioとKnative Servingをインストールする。ドキュメントに従って進めればOKなので省略します。 Kevent Eventingのインストール これも基本的にはドキュメントに従って進めればいい。コマンド一発でできる。 kubectl apply -f https://storage.googleapis.com/knative-releases/eventing/latest/release.yaml GCP PubSub ここからが
Knativeが発表されたので、GKEや手元のminikubeで遊んでいた。オートスケール機能について試したよ。autoscale-go/README.mdをminikubeでやった、という記録です。 GKEでもいいけど、今回はminikubeを使う。Mac上にhyperkitを使って構築するので、kubernetes/minikubeを参考にしてminikubeをhyperkitで使えるようにしておく必要があります。 Knative servingのインストール 基本的にドキュメントに従って進めればよいので割愛。 autoscale-goを試す さて、autoscale-goを試してみる。サンプルアプリをビルドしてコンテナイメージをレジストリに置くのだけど、今回はhub.docker.comに置くことにした。minikubeの場合、minikube上でビルドしてしまえばレジストリに置く必
普段、KubernetesのNamespaceはNamespace毎にyamlファイルを用意し、kubectl applyコマンドでディレクトリを指定して更新したりしている。しかし、この方法だとyamlを削除してもKubernetes側のリソースは更新されず、不便だなと感じていた。そこで、codenize.toolsのようにRuby DSLを使ったNamespace管理を試してみた。作ったツールはtakaishi/heyaだ。 まず、以下のようにNamespaceが存在しているとする。 ⟩ kubectl get namespace --show-labels NAME STATUS AGE LABELS default Active 35d <none> foo001 Active 1s service=foo,stage=development foo002 Active 1s ser
OSS Gateという、OSS開発をしてみたいけど一歩踏み出せない…という人を対象にしたワークショップがあって、興味を持ったのでサポーターとして参加してきた。ワークショップの内容や雰囲気を知りたかったので当初はビギナーとして申し込んでいたのだけど、数日前に考え直し、サポーターとして申し込み直した。当日はサポーターの人数が少な目だったので、結果的には正解だった。 会場はクラウドワークスさん。執務室の手前に多目的に利用できるスペースがあり、そこで実施した。こういう気軽に使えるスペースがあると便利だなあ。ほどよく広いので、グループに分かれて何かするというのもやりやすい。 午前中は各自で選択したOSSを触ってみて、フィードバックできる箇所がないか探す作業、午後は実際にフィードバックしてみる作業という流れ。サポーターはどういうことをするのだろう、と思っていたけど、基本的にはビギナーの背中を押す、気づ
Terraformを使っているのだが、結構困ることもちょこちょこ出てきて、実はHeatの方がよかったのでは？という思いも出てきたりしているのでもうちょっと実践的な検証を行うことにした。OpenStackのバージョンはMitaka。 今回は、スケールさせるインスタンス群とそうではないシングルインスタンスを作成し、シングルインスタンスにはFloatingIPを付与する、という構成にする。インスタンス一覧はこのようになっている。 Every 2.0s: openstack server list takaishiryou-no-iMac.local: Mon Apr 17 22:14:28 2017 +--------------------------------------+----------------------+--------+---------------------------
※2015-03-17にシステムコンテナの起動を追加、他にも加筆・修正。 Tiny Docker Operating Systems | Docker Blogを見たので触ってみた。 RancherOSはDockerコンテナを動かすためのミニマムなLinuxディストリビューションで、以下のような特徴を持つ。 PID 1がDockerで、カーネルが起動する時の最初のプロセスである システム用のDockerとユーザ用のDockerがいる Goで書かれた独自のinitを持つ 非常にコンパクトである PID1のDockerはシステム用のDocker(System Docker)と呼ばれていて、udevやdhcpd、ユーザ用のDocker(User Docker)を動かす。 要はsysvinitやsystemdの代わりにDockerを使っている、という感じだろうか。 RancherOSのサイトでもs
今回はminikubeを使ってローカルに環境を作って、MySQLを建てる。なお、「やってみた」以上の情報はない。完全に自分用のメモです。 minikubeのインストール minikubeはローカルでKubernetesを動かすためのツールで、docker-machineのようなものと思えばわかりやすかった。kubernetes/minikube の通りにインストールすればOK。 kubectlのインストール Kubernetesを操作するためのツールで、これはdockerに相当するのかな。Installing and Setting up kubectl を見てインストールすればOK。 Kubernetes環境を起動する minikubeで一発起動する。便利〜。 $ minikube start GUIもあるようで、proxyコマンドで起動できる。めちゃ楽だ。 $ kubectl prox
10/1(土)に開催されたServerlessConfに参加してきた。最近仕事でAWS Lambdaを触って、ちょっと動向を知っておこうと思ったのが動機。 会場はTABLOIDというところ。 普段行かない場所なので外を見ていたりしたら乗り過ごして、戻る羽目になってしまった。 セッションは、サーバレス(のFaaS)を提供するサービス(AWS LambdaやIBM Bluemix OpenWhisk、Azure Function)の紹介、FaaSとBaaSを使ってサービスを構築した事例の紹介、FaaS関係のツールやテクニックの紹介といったもので、一通りキャッチアップできるものだった。 会場のTABLOID。中に入るとくねくねと曲がる細い通路を進む。大丈夫なのかここ…と思っていると、広い会場に着くことができた。 仕事でLambdaを触るまであまり関心がなかったので、そもそもServerlessの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
