AWS の EKS 上で ExternalDNS を利用する際に policy という概念が分からなかったので、動かしながら簡単に調べてみたメモです。
https://github.com/kubernetes-sigs/external-dns/blob/master/pkg/apis/externaldns/types.go#L410
Modify how DNS records are synchronized between sources and providers
こんにちは。Webシステム開発や各種ソフトウェア開発において GitHub を利用する場面は多いかと思いますが、私が最近知った便利な機能をメモがてらいくつか紹介しようと思います。
ある issue に対して Pull Request(以下PR)を作るというのは良くあることですが、PRを作る際に特定のキーワード(close, fix, resolve など詳しくはドキュメント参照)と対象のissue番号を書いておくと issue と PR が関連付けられます(画像1枚目, 2枚目)。右側のメニューに Linked issues という項目がありここに関連付けた issue が表示されます。
この状態でPRがマージされると関連付けた issue が自動的にクローズされます！(画像3枚目, 4枚目) issue にはどのPRによってクローズされたかが明記され、また Linked pull requests という項目でも記録されます。
これまではマージして自分で(もしくは他の誰かが) issue をクローズするという一手間がありましたが、自動化されるので楽できますね。あとは明示的に issue と特定のPRが関連しているというのが示されるのも後々振り返るときに便利だと思います。
続きを読む今回もオンライン開催のmeetupでした。
今回は、CloudFormation用JSON SchemaをVSCodeで利用しているのですがエラーが出ているので調査していました。現象については以下にまとめました。そこまで致命的なエラーというわけではないです。
JSON Schemaでは $ref というキーワードを使い特定のスキーマを参照できます。今回の問題ではこの参照先がファイル内に存在しないことでエラーが出ている模様でした。$ref に関しては以下を参照。
具体的には AWS::ResourceGroups::Group の Tags という定義で、もくもく会のときに見たときは List of JSON というタイプだった記憶があるのですがこの記事書いている時点では List of Tag というより具体的なタイプになっています。もしかするとJSON Schema側を更新すれば解決するかもしれないですね。
話は変わってもくもく会時の手元の作業環境ですが左半分にブラウザを、右半分の上部にSlack、下部にZoomをそれぞれ配置していました。本当はZoomを全画面にしてというのが理想的ですが作業しながら他の人の顔も見たかったのでこんな感じにしていました。別モニターにZoomを常時表示するのもいいかもしれませんね。
この画面をキャプチャしたのはもう一つ意図があります。作業中に「もくもく会でやることを毎回悩むのだけどみなさんどうやって見つけてますか？」という質問があり、私はまさにこのキャプチャ内のやりたいことリストというのを用意しています。調べてみたいことや作りたいことを思いついたときにメモしておいて、もくもく会当日にリストから選ぶという運用をしています。選ぶ基準はその時の気分ですw
懇親会は引き続きZoom上で行われました。途中退出したりまた戻ってきたりできて自由度が高くて良いですね。
AWS環境で単発の作業用サーバー(例: 負荷テストツールの実行用)を楽に準備したくて cloud-init を利用する方法を調べました。EC2インスタンスの起動時にユーザーが定義した設定を行ってくれる仕組み(= cloud-init)があり、この設定をユーザーデータという形でEC2インスタンスに渡すことができます。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html
まず、SSHログインするためのユーザーアカウントを作成します。ログインするために公開鍵を登録するというのがポイントになります。cloud-init の users 設定で行います。
#cloud-config cloud_final_modules: - [users-groups, always] users: - name: takagi groups: [wheel] sudo: ["ALL=(ALL) NOPASSWD:ALL"] shell: /bin/bash ssh-authorized-keys: - ssh-rsa publickey # 公開鍵をセットする
この設定は以下資料を参考にしました。
EC2インスタンス作成時に上記の設定内容をユーザーデータに渡しインスタンスが起動するとSSHログインできるようになります。踏み台サーバー経由でログインするために以下のような設定を行います。鍵は簡易的に踏み台サーバーと同じものを利用しています。諸々の設定が上手くいけば ssh working-server でログイン可能です。
# ~/.ssh/config Host bastion # 踏み台サーバー HostName x.x.x.x # public IPアドレス User takagi IdentityFile /Users/takayuki_atkwsk/.ssh/id_rsa Host working-server # 作業用サーバー HostName 192.168.2.73 # private IPアドレス User takagi IdentityFile /Users/takayuki_atkwsk/.ssh/id_rsa ProxyCommand ssh -W %h:%p bastion
次に必要なパッケージをインストール済みの状態にします。上記でSSHログインできるようになった段階で yum install コマンドを打っても良いのですが、時間が空いて別の作業用インスタンスを起動したときに再度打つのも面倒くさいので cloud-init に任せてしまいます。今回は OpenJDK と sbt をインストールします。注意点としては、パッケージのインストールはインスタンスのライフサイクルで一度しか行われないため、上記の設定でインスタンスを起動した場合は一度終了(stop ではなく terminate)してパッケージの設定を追加した新しいインスタンスを作り直しましょう。
sbt に関しては以下のインストール方法に記されている方法の内、RPMレポジトリをパッケージマネージャに追加する方法で行います。
curl https://bintray.com/sbt/rpm/rpm | sudo tee /etc/yum.repos.d/bintray-sbt-rpm.repo sudo yum install sbt
cloud-init で対応するには yum_repos という設定を利用します。各設定値には上記の sbt RPM URLから得られるデータに含まれる値を使います。こちらがダウンロードしたデータです。
#bintray--sbt-rpm - packages by from Bintray [bintray--sbt-rpm] name=bintray--sbt-rpm baseurl=https://sbt.bintray.com/rpm gpgcheck=0 repo_gpgcheck=0 enabled=1
それぞれの値を yum_repos に当てはめると以下の cloud-init 設定になります。これでパッケージマネージャにレポジトリを追加できます。後は yum install でインストールしたいパッケージ名を packages の値に書き込みます。
yum_repos: bintray--sbt-rpm: baseurl: https://sbt.bintray.com/rpm name: bintray--sbt-rpm enabled: true gpgcheck: false packages: - java-1.8.0-openjdk-devel - sbt
yum_repos: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#yum-add-repo
packages: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#package-update-upgrade-install
この設定をユーザーデータに含めてインスタンスを起動すると、OpenJDK および sbt がインストールされた状態になっています。これで Gatling シミュレーションを含んだソースコードをローカルから scp すれば実行できるようになります。
[takagi@ip-192-168-2-73 ~]$ which java /usr/bin/java [takagi@ip-192-168-2-73 ~]$ which sbt /usr/bin/sbt [takagi@ip-192-168-2-73 ~]$ java -version openjdk version "1.8.0_242" OpenJDK Runtime Environment (build 1.8.0_242-b08) OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode)
用意した cloud-init 設定全体を以下に示します。今回は単発でEC2インスタンスを利用する(=定常的に稼働しないまたは他の人が利用しない)用途だったのでこのくらいの簡潔さが丁度良いなと感じました。組織でEC2インスタンスの構成管理を行いたい場合になると Chef や Ansible などのツールを使う方が上手く運用できるのかもしれません。
#cloud-config cloud_final_modules: - [users-groups, always] users: - name: takagi groups: [wheel] sudo: ["ALL=(ALL) NOPASSWD:ALL"] shell: /bin/bash ssh-authorized-keys: - ssh-rsa publickey # 公開鍵をセットする yum_repos: bintray--sbt-rpm: baseurl: https://sbt.bintray.com/rpm name: bintray--sbt-rpm enabled: true gpgcheck: false packages: - java-1.8.0-openjdk-devel - sbt
1月以来のKanazawa.rb meetupに参加しました。今回は昨今のCOVID-19の影響によりオンライン開催となりました。
Kanazawa.rb では史上初のオンライン開催となりました。Zoomを使って参加者はそれぞれの場所からログインして常時接続、発表以外のときはマイクも常時ONという状態でやっていました。上の写真は自分の環境(ITBP武蔵のサロンスペース)で、下の写真(by @kiyohara)はZoomの参加者集合写真です。ノートPCなので2画面無いと作業しながらかつ相手の様子を見ながら喋るのが大変そうだなと思いiPadをサブディスプレイにしていました。
雑に感想を並べていきます
EC2のユーザーデータ(cloud-init)について調べていました。Gatlingという負荷テストツールがあってそれを単発でEC2上で動かすときに自分の公開鍵とか依存パッケージをいちいち持ってくるのが大変だな、という体験があってユーザーデータを使って楽にできないか、というのを調べていました。最後まで調査できなかったので詳細は別の記事で書く予定ですが、パッケージのインストールはある程度できるようになりました。この辺見ながら試していました。
来月もオンラインでのもくもく会となります。
Akka Streamsを利用してTCP通信ができる簡易なコードが書けることを知ったのでメモ。
詳しくは以下のページを参照。
package io.github.takayukiatkwsk.tcpclient import akka.actor.ActorSystem import akka.stream.scaladsl.{Flow, Keep, Sink, Source, Tcp} import akka.util.ByteString import scala.concurrent.Future class TcpClient(implicit val system: ActorSystem) { private val connection = Tcp().outgoingConnection("127.0.0.1", 8080) // 接続先のホストとポート private val mapFlow = Flow.fromFunction[ByteString, String](b => b.utf8String) private val sink = Sink.headOption[String] def send(body: String): Future[Option[String]] = { Source .single(ByteString(body)) // TCPサーバーに送るデータ(StringからByteStringに変換) .via(connection) .via(mapFlow) // サーバーから返却されたデータをStringに変換 .toMat(sink)(Keep.right) // 文字列を取り出す .run() } } object TcpClient extends App { implicit val actorSystem = ActorSystem("tcp-client") implicit val ec = actorSystem.dispatcher val tcpClient = new TcpClient() for { result <- tcpClient.send("Hello from TcpClient") } yield { println(result.getOrElse("Empty response")) } }
今回TCPサーバーはnc(netcat)コマンドを利用してちゃちゃっと確認できるようにしました。
### 8080ポートでListenして、hello, worldを返す $ echo -n 'hello world' | nc -l 8080
クライアントを実行してみます。
### ncコマンドとは別のターミナルで実行 $ sbt 'runMain io.github.takayukiatkwsk.tcpclient.TcpClient'
TCPサーバーに Hello from TcpClient というデータが送られてきて標準出力に出力されます。
$ echo -n 'hello world' | nc -l 8080 Hello from TcpClient
その後、TCPクライアントはTCPサーバーからの返信を受けて、ターミナルに hello world というデータが出力されます。
$ sbt 'runMain io.github.takayukiatkwsk.tcpclient.TcpClient' ... hello world
感想としては、Akka Streamsのみで比較的シンプルにソースコードを書くことができ、レスポンスの扱いもFuture値を使うことができるのでハンドリングしやすいなと思いました。リソースのオープン・クローズも隠蔽されていて使う側としては非常に楽だなあと感じます。選択肢の一つとして覚えておくと良さげですね。
2020年になって最初の Kanazawa.rb です。今年もやっていきましょう。
久しぶりにWebアプリ作ってみようかなーとネタが浮んだのでユーザーストーリーの作成と必要になりそうな技術の調査を行いました。どういうお題かというとブログの最新記事を音声化して購読できるものです。アイデアとしてはよくあるものだとは思いますが自分が欲しいなあと少しでも思ったので作ってみることにしました。
ユーザーストーリーの作成は見様見まねでやってみました。最初はファイルに箇条書きで思いつくままに書いていたのですが、それぞれのユーザーストーリーの関連性や依存を洗い出したかったので付箋に書いてペタペタ貼って考えてみました。結果以下の画像のように並び替えました。
机のスペースが限られているので自分のみ分かる配置になっていますが左から右にストーリーが進んで目的が達成されるという並びにしています。縦方向は派生するパスを表しています。並べてみると最初はこの部分の一連のストーリーが実装できていればいいか、というようなことが決めやすいなという気付きがありました。
残りの時間は技術的な課題を洗い出して一つずつ調査実装していきました(全ては終わっていない)。今回はサーバレスな基盤でRubyを使って実装してみようと考えてます。趣味アプリなので自分の使いたい技術(Rubyは最近触れてなかったので...)を使うというところと、音声変換や非同期処理などクラウド基盤やサーバレスアーキテクチャに乗せた方がもろもろ楽できるのかなというのが技術選定の背景です。調査実装してみて構成を変える可能性はありますが。
こう見るとタイトル重要だなというのを再認識させられます。
最近オープンしたという「十三」にて一次会！炭火で鶏肉を焼きながらあれこれ喋ってました。レガシーリソースと新規開発、リモートワークとテクノロジー、ラジオで聴いた分身ロボットのカフェとセルフ介護の話、にいがた酒の陣、社内ルール、ガリベンガーVなどについて話しました。お腹いっぱいでチキン南蛮食べられなかった...。
二次会は安心の「だんまや水産」にて。細巻き美味しかった。トークはあんまり覚えてませんw
決済プラットフォームのStripeミートアップやりますよ。もう使ってるよって方はぜひ事例を共有して、興味あるよって方は気になりポイントを聞いてみる絶好の機会です！
