cdk のビルドが難しい話し

0時に寝て6時半に起きた。暑くなってきたせいかバテ気味。水曜日は本番リリースの日。3つほど本場環境のインフラ移行作業があったので社員さんの実作業をリモートから指示しながらサポートしていた。私に本番環境の操作権限があれば、この工数はほぼ半分に削減できる。

cdk のパッチ検証

先日 cdk による eks クラスターの helm 管理の調査中断 について書いた。バグっているから適切な設定が反映されないという話しで一時中断していたんだけど、そのときにクラスメソッドの担当者さんとも相談していた。そしたら、その担当者さんが問題を修正して pr を送ってくれた。感謝。

そこまでやってくれると思ってなかったのですごいなぁと感心しながら、せっかくなのでパッチを当てた cdk で検証してみようと、Contributing to the AWS Cloud Development Kit をみながらローカルでのビルドを試みた。ビルド自体はできたんだけど、パッケージを作るのがうまくいかなくて、cdk はツール自体が大きいので実行時間がかかる。だいたいビルドやパッケージングのそれぞれに20-30分ぐらいかかる。エラーの原因がよく分からなくて面倒になって断念した。私が javascript のパッケージングに疎いせいもあると思うけど、ドキュメントに書いてある通りにうまくいかなかったので早々に諦めた。

datadog のログアーカイブ

1時に寝て5時半に起きた。

datadog のログアーカイブ

datadog には Log Archives という機能があって、datadog 経由でログをどこかのストレージに永続化できる。datadog プラットフォーム上では設定した期間内のログしか検索できず、おそらく料金の予算にあわせて期間を設定して、それが過ぎたら消えていくのだと思う。aws なら s3 に datadog に連携されたログをパイプライン処理してそのまま永続化できる。そのための s3 バケットの作成、s3 バケットへの datadog からのアクセス権限ロールの設定、datadog の aws インテグレーションの設定などをした。ドキュメントを読みながら1日あれば設定できたので難しくはない。もう cdk の設定にも慣れた感じで必要な権限を cdk の Stack としてコードで管理できるようにした。保守もばっちり。永続化されるログは gzip 圧縮されて時系列に s3 に永続化されるみたい。

helm 調査の一時中断

0時に寝て6時半に起きた。

eks クラスターの helm 管理の調査

先週から調査 していて、調査結果から kubectlRoleArn を生成してデプロイを実行してみた。以前発生していた権限エラーは解消したものの、lambda 内からの kubectl と k8s クラスターの認証に失敗する。もう1つ kubectlLambdaRole という設定もあるので、ここに system:masters 権限をもつ iam ロールを設定してみたものの、エラー結果は変わらない。お手上げかなと思ってたら aws-eks: Cluster.FromClusterAttributes ignores KubectlLambdaRole #20008 という issue があって、まさにいま起こっている現象と合致するのでこのせいかもしれない。cdk のバグならそれが解消しないと検証を進められないため、この調査は一旦打ち切って、cdk のバグが修正されて新しいバージョンがリリースされてから再試行することに決めた。

backlog のいろいろ

たまたまタイムラインでスライドをみかけて、backlog の開発をしている方の記事をみつけた。scala と play framework で実装されているらしい。もう10年以上開発しているプロダクトなのかな。それ自体はすごいなぁと感心しながらスライドを眺めてた。

オフラインのもくもく会

6時半に起きて漫画読んで8時に起きた。

ワーケーションの打ち合わせ

参加者で ワーケーションのリトライ の最終確認ならびに共有事項の打ち合わせをした。今回は3回目のワクチン接種をし終えたばかりだし、オミクロン株も一応は収束したみたいな雰囲気になっているので延期することはないはず。旅程の確認を一通りしつつ、少し雑談していた。今後の開発合宿のような取り組みをコミュニティでやるのか、会社でやるのかはまだわからないけど、そういう取り組みも非日常の刺激を受ける機会だったり、普段やらないことでなにか新しい価値を見い出す行動だったりにつなげられればと考えている。今回はそのためのリハーサルなのでたくさん失敗しつつノウハウを溜めていきたい。

もくもく会

【三宮.dev】もくもく会 に参加した。オフライン開催で参加者は6人。他者と雑談しながら作業するというのを、久しぶりにやった感じだった。私は jjug ccc 2022 spring の資料作りをしていた。骨子レベルの内容はだいたいできたので後はスライド資料を作り込むだけ。今回はビデオ撮影を事前しないといけないのが初めての試み。でも、当日は質疑応答だけでよいから楽になってこれはこれで有りだとは思う。終わってからワーケーションの参加者3人で軽く飲みに行ってきた。勉強会へ行って飲み会でわいわいやって帰るみたいな昔の勉強会の雰囲気に戻った感じがして懐かしかった。地域コミュニティはこういうつながりもあっていいと思う。バックエンド周りのバッチ処理の最適化で話題になったときに「私を雇え、値段は高いけど」と宣伝したりもしてた。自分の会社をやっていると、こういうノリでお仕事がきてもまぁいっかみたいな気持ちになれるからそれも含めて楽しい。

漫画ばかり読んでる

漫画を読みながら寝て5時半に起きて漫画読んで8時に起きた。今日はほとんど漫画読んでた。

ストレッチ

今週は漫画ばかり読んでいたせいか、体が硬くなってしまっていた。今日の開脚幅は開始前153cmで、ストレッチ後158cmだった。今週は雨降りの日が多くて徒歩通勤する機会が多かった。普段よりは運動したような気はしていたけど、ストレッチの数値はよくなかった。疲労度は腰がもっとも蓄積していて、肩甲骨周りも相変わらず硬い。ベッドで漫画ばかり読んでたから不健康になってしまったのかもしれない。

神之塔

先週ぐらいから 神之塔 を読み始めた。少し前 (と言っても2年前) に アニメ化 されていて、当時たまたまみたらおもしろかったので印象に残っていた。一言でこの作品を表すと「基本的に訳がわからないのだけど、おもしろい」といったところ。私は普段 LINE を使っていないので LINE と密接なアプリやプラットフォームも使っていない。神之塔は LINE マンガでしか読めないみたいなのでこの漫画を読むために仕方なくインストールした。通常は1日1話しか無料で読めないけど、なにかのキャンペーン期間中は100話ぐらい無料で読めたりする。数日前からキャンペーン期間になっているので読んでいて疲れたら寝て起きたら読むみたいな生活をしている。300話まで読んだ。50話から100話ぐらいで1つのエピソードが終わるのでテンポもいい。おもしろい。

マーケティング施策の取り組み開始

23時に寝て1時に起きて漫画を読んで6時に起きて漫画読んでた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題は 先日作成した第4期の展望 について雑談した。あまり深く考えずに起業して初期の頃に作った10ヶ年計画に対してわりとその通りに推移している。来期ぐらいで業務委託のお仕事は終える予定。来期か再来期ぐらいからプロダクト開発の期間に入る。自社プロダクトを作る前から徐々にマーケティングもしていかないといけない。そのため、今期からマーケティング施策を少しずつ増やしていて、まずは会社の信頼度を上げるところからやっていく。売上を上げるためのマーケティングではなく信頼度を上げるためのマーケティングを行う。金森氏が言うようにどんなに優れたプロダクトを作ったとしても売れるかどうかは別問題だ。

eks クラスターの helm 管理の調査

昨日の続き。権限設定がなんもわからんみたいな様相になったので調査のやり方を変えることにした。検証用の eks クラスターを cdk から新規に作成して helm をインストールするときのリソースや権限設定がどうなるのかを調査した。lambda 関数が5個ぐらい、ロールは10個ぐらい作成された。lambda の生成に時間がかかるのか?新規作成するのに25分、削除するときは30分ぐらいかかった。rds もそうだけど、eks のような複雑なインフラを cdk で管理すると実行するのにけっこう時間がかかる。設定が難しくなければ別によいけど、eks のような権限やリソースの設定が複雑なインフラはトライ&エラーで何度も実行する必要があるから、こういうものは cdk で管理するのには向かないインフラだと言えると思う。一定の設定のプラクティスが溜まるまでは eks は cdk で管理しない方がよいかもしれない。

CreationRole というのが設定されて trust relationships に次のような設定が追加される。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::${accountId}:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

このロールに含まれるカスタムポリシーには次のような設定がある。たぶんこんな感じのロールを新規に作成して kubectlRoleArn として指定してやればいいんじゃないかと思う。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::${accountId}:role/${EksClusterIamRole}",
            "Effect": "Allow"
        },
        {
            "Action": [
                "eks:CreateCluster",
                "eks:DescribeCluster",
                "eks:DescribeUpdate",
                "eks:DeleteCluster",
                "eks:UpdateClusterVersion",
                "eks:UpdateClusterConfig",
                "eks:CreateFargateProfile",
                "eks:TagResource",
                "eks:UntagResource"
            ],
            "Resource": [
                "arn:aws:eks:ap-northeast-1:${accountId}:cluster/tmp-test-eks-cluster-by-morimoto",
                "arn:aws:eks:ap-northeast-1:${accountId}:cluster/tmp-test-eks-cluster-by-morimoto/*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "eks:DescribeFargateProfile",
                "eks:DeleteFargateProfile"
            ],
            "Resource": "arn:aws:eks:ap-northeast-1:${accountId}:fargateprofile/tmp-test-eks-cluster-by-morimoto/*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "iam:GetRole",
                "iam:listAttachedRolePolicies"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeRouteTables",
                "ec2:DescribeDhcpOptions",
                "ec2:DescribeVpcs"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

cdk と eks と lambda と iam がわからん

0時に寝て3時に起きて漫画読んで5時に寝て8時に起きた。

eks クラスターの helm 管理

昨日の続き。helm のよさはわかったので dapr を helm で管理しようとしている。その際になるべく cdk で管理できた方がよい。eks は cdk の外部で管理しているのだけど、既存の eks クラスターをインポートする機能も提供されていることに気付いた。

それなら既存の eks クラスターをインポートして cdk で helm だけ管理しようと思って始めたものの、これがとても難しくて丸1日作業してわからなかった。設定項目は少ないけど、権限の問題で動かない。1回あたりの実行に15分ぐらいかかるのでトライ&エラーするのもなかなか大変。

kubectlRoleArn - the ARN of an IAM role mapped to the system:masters RBAC role. If the cluster you are importing was created using the AWS CDK, the CloudFormation stack has an output that includes an IAM role that can be used. Otherwise, you can create an IAM role and map it to system:masters manually. The trust policy of this role should include the the arn:aws::iam::${accountId}:root principal in order to allow the execution role of the kubectl resource to assume it.

kubectlRoleArn の設定をどうするかだけなんだが、この説明でどう設定していいか理解できなかった。cdk で新規に eks クラスターを作成するなら自動で作ってくれるけど、既存の eks クラスターの場合は自分で設定しないといけない。ややこしいことに cdk は kubectl の実行を lambda 経由で実行するので eks と lambda と iam のロールやポリシーを適切に設定する必要がある。lambda にどういう権限を設定するのが適切なのかは本当に難しい。サーバーレスはよいアイディアだとは思うけど、lambda は難し過ぎて私はなるべく使いたくないサービスではある。結局わからなくて翌日に持ち越し。

helm を調べた

1時に寝て6時半に起きて8時に起きた。前日は資料づくりで遅くまでオフィスに残っていたせいか、なんか寝坊した。

helm 調査

k8s 上の datadog-agenthelm で管理されていて、あるバージョンから dapr も helm 管理できる ようになった。dapr は cli からもインストールできるけど、helm のことをよくわかってなかったので調べることにした。そんなたくさん記事をみたわけではないけど、いくつか記事を読んで quora のやり取りが一番よかった。

ざっくりまとめるとこうかな。

  • helm は oss 且つ cncf の公式プロジェクトだからまぁ安心
  • helm はサードパーティのパッケージのインストールや設定の利便性を高める
    • k8s はテンプレート機能が弱いので共通設定と特定環境向けの設定を管理するのがあまり得意ではない
    • セキュリティを考慮した k8s 設定は自分でやるよりコミュニティに任せた方がよい場合もある
    • パッケージなのでバージョン管理は得意
  • helm は k8s 向けのパッケージマネージャとレポジトリマネージャーとマーケットプレイスを組み合わせたみたいなもの

k8s 上でサードパーティのパッケージを自分で設定したい特別な理由がない限りは helm を使うのがよさそうという結論になった。

スライドデザインのレビュー

1時に寝て6時半に起きた。

スライドマスターのデザインレビュー

はらさんと一緒にレビューした。私とは全然視点が違うので参考になった。自分が得意ではない分野の相談相手がいると本当に助かる。いくつか取り上げる。あれこれ、私が気になったところもヒアリングしながら意見をもらった。あとでデザイナーさんにフィードバックする。

  • 外国人が作ると文字のレイアウトが日本語と異なることを考慮する必要がある
    • 日本語には y や q のような下にはみ出る文字がない
  • スライド全体の色使いで目立たせるときの注目色を作ってもらった方がよい
  • インジケーターのようなデザインがあると聴衆がいま発表のどの辺りかわかって嬉しい
  • 会社の自己主張が強過ぎない方がよさそう

スライドデザインの作成

0時に寝て4時に起きて6時半に起きたつもりが、なんか3度寝して8時に起きた。

スライドマスターのデザイン作成

うちの会社のロゴは Ševarika™ というデザイナーさんに作ってもらった。言語にセルビア語とあるので旧ユーゴスラビア地域の国の出身なのかなと推測する。このご時世なので NATO 加盟国なのだろうか?とか調べてみたけど、旧ユーゴスラビア地域の国々の歴史は複雑ですぐにわかるものではなかった。閑話休題。私は会社のロゴをとても気に入っているし、ロゴを作ってもらうときの取り引きも円滑にできたのでそのデザイナーさんを信頼している。今回も2年半ぶりに連絡をとったら快くスライドマスターの作成を引き受けてくれた。4月30日に契約して、とくに急いでいないのでデザイナーの都合がついたらでという緩い依頼をしたんだけど、昨日さっそく最初の草稿が届いた。いくつか私の好みのスライドデザインのサンプルを渡したりしていたので、私の好みのスタイルは外していない。ただ私はデザインのことは何もわからないので、今回は顧問のはらさんにもレビューしてもらってご意見をもらうことにした。

ベースライン移行

先日の flyway のデータベース移行 の続き。管理しているマイクロサービスが4つあるのでそれぞれのサービスごとに設定していかないといけない。サーバーサイドって共通化できるのが大きなメリットなのに、同じサーバーサイドの仕組みを複数導入しないといけないというのはマイクロサービスのデメリットと言えばそうだし、アーキテクチャとしても正しいんやろか?という気持ちも出てくる。おそらく1つのチームが複数のマイクロサービスを開発する体制がよくない。変更作業と検証で約1日を費やした。

法人決算の続き

0時に寝て5時半に起きた。実家にいると、親が5時ぐらいから起き始めるのでつられて早めに起きている。親が8時からアルバイトなのでそのタイミングでバス停に送ってもらって9時半には戻ってきた。

消費税申告書と欠損金の還付請求書の作成

先日から 法人決算に着手 していた。

まずは消費税の申告書と未払い消費税の振替伝票の起票をしていた。初めての会計処理でいろいろ調べてた。No.6610 法人に係る消費税の確定申告書の提出期限について によると、消費税の申告期限も法人決算と同様、課税期間 (事業年度) の終了の日から2ヶ月以内に行う必要がある。厳密には消費税にも2種類あって国税と地方税にわけられる。地方消費税は国税ではなく地方税であるため、本来は都道府県に納税すべきものではあるが、手続きの利便性のため?なのか、国税と一緒に所管税務署へ納付するのでよいらしい。

つぎに前期は赤字なので前々期に支払った法人税と地方法人税の一部を還付してもらう。前々期の所得と支払った法人税、前期の欠損金 (マイナスの所得に対する法人税法上の用語) の3つの数字があれば算出できる。計算してみたら支払った法人税のうち26.4%を還付できることがわかった。算出後に請求書をダウンロードして書類に数字を記入した。

ストレッチ

いつもは土曜日の10時に通っているが、実家に帰っていたので予定変更。今日から新しいトレーナーさんに師事することになる。今日の開脚幅は開始前160cmで、ストレッチ後162cmだった。昨日、草刈りをして筋肉痛になっていたのでそんなもんかな。腕と腰に張りがあった。新しいトレーナーさんも初めてなのでまずはどこの筋が張っていて、どこの関節が詰まっているかを確認しながら進めていくといった感じだった。話しを聞いていたら、新しいトレーナーさんも前のトレーナーさん同様、筋トレをしていて、週3日ぐらいはやっているらしい。やっぱりトレーナー業をする人は筋トレに興味をもつ人が多いのかもしれない。