EKS Pod Identity を活用するメリット
この記事は はてなエンジニア Advent Calendar 2023 の 26 日目の記事です。 本日からはてなエンジニア Advent Calendar 2023 はオーバーランに突入します。昨日は id:d-haru さん明日は id:chaya2z さんとなっています。
私が所属するチームでは EKS を利用してサービスを運用しています。
今年の AWS re:Invent 2023 内でも EKS 関連のアップデートがありましたが、特に EKS Pod Identity という便利な機能に注目したので利用してみました。
EKS Pod Identity とは
EKS を利用者にとって嬉しい機能が発表されました。これまで Pod への IAM 権限の割り振りは IRSA ( IAM Roles for Service Accounts ) を利用するのが一般的でした。Pod に権限を与えるという結果は両者変わらないのですがリソースの管理方法が異なります。
IRSA を利用した場合は以下のような manifest を書くことで kubernetes の ServiceAccount と IAM Role を紐づけていました。
apiVersion: v1 kind: ServiceAccount metadata: name: sample annotations: eks.amazonaws.com/role-arn: arn:aws:iam::XXXXXXXXXXXX:role/sample-role-arn
ServiceAccount リソースの annotation に IAM Role の Arn を記述しています。manifest に Arn を埋め込むのって面倒ですよね。特に IaC などしている場合、IaC で作成したリソースの Arn をなんとかして埋め込みたくなると思います。
今回、発表された EKS Pod Identity は IAM Role と ServiceAccount の紐づけを kubernetes 側ではなく EKS 側の設定で行うことができるため、IaC との親和性も高く権限管理が簡素化されます。
使い方と解説
アドオンのインストール
コンソールを使った方法は以下のリンクを参照するのが良いと思います。
今回は Terraform を利用した方法で試してみます。
まず、EKS Pod Identity を利用するには eks-auth:AssumeRoleForPodIdentity
のポリシーが必要です。事前に Node の Role に AmazonEKSWorkerNodePolicy を利用するかカスタムポリシーでを作成してアタッチしておく必要があります。
EKS Pod Identity は EKS アドオンで追加できるようになっています。 EKS の Terraform module を利用した場合、以下のようにしてアドオンを追加することができます。
module "eks" { source = "terraform-aws-modules/eks/aws" cluster_name = var.cluster_name cluster_version = var.cluster_version ... cluster_addons = { kube-proxy = {} eks-pod-identity-agent = {} } }
余談ですが上記に記述しているアドオンの name は以下のコマンドを叩くことで確認することができます。
aws eks describe-addon-versions | grep addonName
さらにアドオンのバージョンやconfigのオプションについても以下のコマンドで確認することができます。
aws eks describe-addon-versions --addon-name eks-pod-identity-agent
aws eks describe-addon-configuration --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
EKS Pod Identity のアドオンを有効にすると kuberntes クラスターの kube-system Namespace に eks-pod-identity-agent が Daemonset としてインストールされエージェントの Pod が起動します。
$ kubectl get daemonset -n kube-system eks-pod-identity-agent NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE eks-pod-identity-agent 1 1 1 1 1 <none> 3d1h
このエージェントは Node に付与した AssumeRoleForPodIdentity のアクションを利用して、一時的な認証情報を取得し、コンテナ内の SDK がその認証情報を利用できるようにします。 Node 側でまとめて認証してくれるので各 Pod 毎に認証をすることがなくなっています。
IAM Role の信頼ポリシー
IRSA ではクラスター毎に OIDC プロバイダーを作成する必要があり、OIDC プロバイダーが EKS と IAM の信頼関係を確率していました。 そのためIAM Role に以下のような信頼ポリシーを設定する必要がありました。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME", "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com" } } } ] }
クラスター固有の情報が含まれているため、クラスターが増える度に全ての IAM Role の信頼ポリシーを更新する手間が発生していました。
EKS Pod Identity を利用するとその手間は無くなり、OIDC プロバイダーも作成する必要もありません。 IAM Roleの信頼ポリシーは以下を追加すればよくて、固有のクラスター情報を含まないシンプルなものになりました。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:TagSession", "sts:AssumeRole" ] } ] }
クラスターの BlueGreen アップグレード時の IAM Role の更新の手間が減り作業もシンプルになります。
ServiceAccount と IAM Roleの関連付け
kubernetes の ServiceAccount と IAM Role の関連付けについてですが、マネコンから紐づけることもできますが以下の Terraform リソースを利用することで IaC 管理できます。
resource "aws_eks_pod_identity_association" "example" { cluster_name = aws_eks_cluster.example.name namespace = "example" service_account = "example-sa" role_arn = aws_iam_role.example.arn }
Terraform で IAM Role を作成していれば Arn の Attribute を参照することができるので ServiceAccount と IAM Role の関連付けが Terraform 内だけで完結します。もう manifest に Arn を記述する必要はありません。
まとめ
まとめると以下のような設定が必要です。
- Node の IAM Role に
eks-auth:AssumeRoleForPodIdentity
を付与する - EKS Pod Identity アドオンをインストール
- IAM Role の信頼ポリシーを EKS Pod Identity に対応したものに設定する
- IAM Role と ServiceAccount を関連付ける
上記4点を全て IaC で管理できるので EKS と kubernetes のリソースを独立して管理できます。必要なリソースと内部的な処理も簡略化されているため導入・運用の観点からもこれまでよりも良くなっていると感じました。
2024/01/05 追記
利用しているサービスによっては SDK のバージョンが古く利用できない場合があるため注意が必要でした。secrets-store-csi-driver-provider-aws
で利用している SDK のバージョンが v1.47.10 と古いため直近での EKS Pod Identity の利用は見送るつもりです。今後、利用できることを楽しみにしています。
参考
- Amazon EKS が EKS Pod Identity を導入
- Amazon EKS Pod Identity simplifies IAM permissions for applications on Amazon EKS clusters | AWS News Blog
- EKS Pod Identities - Amazon EKS
🆕 EKS で、Pod に IAM Role を割り当てる新機能として EKS Pod Identity がリリースされました!IAM roles for service accounts (IRSA) と比較して、シンプルに設定することが可能です。 (1/6)https://t.co/WQz4kQVN0m
— Kyosuke Ochimizu (@otty246) 2023年11月28日
Helmfileを利用して複数のHelm Chartをまとめて管理する
背景
最近、EKSにHelmを使って Opentelemetry Collector をインストールしました。 Opentelemetry Collector で利用するバックエンドプラットフォーム(監視SaaS)のAPIキーが必要になるので AWS Secrets Manager に保管することにしました。
EKSから AWS Secrets Manager のリソースを参照するには Secrets Store CSI Driver の SecretProviderClass というカスタムリソースを作成する必要があります。 しかし Opentelemetry Collector のHelm Chart に SecretProviderClass のリソースが存在しないので別途管理する必要がありました。
関連リソースなのでまとめて管理したいと思い調べたところ Helmfile を利用することで解決できそうだったのでやってみました。
Helmfile
HelmfileはHelm Chartをより宣言的に管理できるツールです。Helmのリポジトリなどもコード管理できるようになるのでより再現性を確保することができます。
また複数のHelm Chartを管理できるので、今回のようなカスタムリソースもHelm Chartにしてしまえば一緒に管理できるようになります。
構成
最終的なファイル構成は以下のようになりました。
├── helmfile.yaml ├── otel-collector │ ├── config.yaml │ └── helmfile.yaml └── otel-collector-misc ├── Chart.yaml ├── helmfile.yaml └── templates └── secret-provider-class.yaml
ディレクトリを2つ掘っているのでそれぞれ解説します。
./otel-collector
Opentelemetry Collector の Helm Template に渡す変数が書かれた config.yaml を置いています。
helmfile.yaml は以下の通りで Helm Chart の Repository の設定や Release の設定を記述することができます。
repositories: - name: open-telemetry url: https://open-telemetry.github.io/opentelemetry-helm-charts releases: - name: opentelemetry-collector namespace: otel-collector chart: open-telemetry/opentelemetry-collector version: 0.53.1 values: - config.yaml
./otel-collector-misc
SecretProviderClass
の 簡単な Helm Chart を作成して置いています。
helmfile.yaml には以下のようにカレントのディレクトリを指定するように記述することでローカルの Helm Chart を利用することができます。
releases: - name: opentelemetry-collector-misc namespace: otel-collector chart: ./ version: 0.1.0
./helmfile.yaml
./otel-collector
と ./otel-collector-misc
にある helmfile.yaml へのpathを記述することで複数の Helm Chart を管理できるようになります。
helmfiles: - path: ./otel-collector/helmfile.yaml - path: ./otel-collector-misc/helmfile.yaml
実行
helmfile apply
を実行するだけで Opentelemetry Collector 関連のリソースと SecretProviderClass のカスタムリソースをEKS上にまとめて作成することができました。
helm だと事前に Repository の追加が必要だったり、helm install コマンドに Namespace や Chart のバージョンを渡す必要がありますが、全て helmfile.yaml に記述されているので必要ありません。
さらにhelmfile diffで差分を確認できるのも便利ですね。helmの場合はpluginを入れたりする必要があるので。
まとめ
複数のHelm Chartを管理する目的でHelmfileを利用してみましたが、helmfile化することでコード管理できる範囲が広がったことも嬉しいポイントでした。 ArgoCDなどで管理したい場合には Config Management Plugin などを利用すると良さそうなので引き続き試して見ようと思います。
話は変わりますが、先日 Mackerel が OpenTelemetry 対応を進めているといった発表がありました。 API キーの管理方法は今回の件が利用できるかもしれません。こちらも楽しみにしています。
EKSクラスターのB/Gアップグレード作業の改善で取り組んでいること
この記事ははてなエンジニアのカレンダー | Advent Calendar 2022 - Qiitaの14日目のエントリです。
背景
私のチームで運用しているEKSクラスターですが、アップグレードはBlueGreenアップグレードする方針をとっています。 B/Gアップグレードを採用している主な理由は切り替え時に問題が発生した場合に素早く切り戻しを行いたいためです。
詳細は以下のブログを参照ください。
B/Gアップグレードのおおまかな流れは以下の通りです。
- 新バージョンのEKSクラスターを構築する
- ArgoCDに新クラスター用のデプロイ設定を手動で作成してアプリケーションをデプロイする
- Route53やAWS Global Acceleratorの設定を変更して旧クラスタから新クラスタにリクエストを切り替える
上記の2と3の工程には以下のような課題を感じています。
- サービスが増えることで新クラスターに対するデプロイ設定の作業負荷が高くなってきている
- より手軽にすばやく切り替え、切り戻しを行えるようにしたい
上記について改善を行ってきたので紹介したいと思います。
実現したいこと
上記の課題より私達が実現したいことは以下の通りです。
- クラスタのバージョンアップ時など、デプロイ先のクラスタが増えた場合でも、アプリケーションを効率よくデプロイできるようにする
- 旧クラスターから新クラスターにリクエストを手軽に素早く切り替えられるようにする
解決へのアプローチ
ArgoCDのApplicationSetを利用する
ArgoCDはデプロイ設定をApplicationというカスタムリソースで管理しています。Applicationに主に定義している内容は以下の通りです。
B/Gアップグレード時にはデプロイ先のクラスターが異なる、2つのApplicationを作成する必要があります。デプロイするアプリケーションが多いほど管理が煩雑になっていきます。
ApplicationSetはApplicationの管理をまとめることができます。 これを利用することで複数のクラスター分のApplicationリソースを自動的に作成することができます。
さらにGeneratorというパラメータを利用することで、ArgoCDに登録されているクラスターや指定したクラスターのリスト分だけApplicationを作成することが可能です。
ApplicationSetを利用することで新旧クラスター用のデプロイ設定を、効率よく管理できるようになると考えています。
AWS Loadbalancer ControllerのTargetGroupBindingを利用する
AWS Loadbalancer ControllerはKubernetesのアドオンです。 KubernetesのIngressリソースを作成するとALBがプロビジョニングされます。
つまり以下の図のようにクラスター毎にALBが作成されます。
この方法だと基本的にはDNSの切り替えでクラスター移行することになります。これでも問題はないのですが、DNSをキャッシュしているクライアントがあった場合に完全に切り替わるのを待つ必要があります。
AWS Loadbalancer ControllerにはTargetGroupBindingというカスタムリソースがあります。これを利用すると既存のTargetGroupを利用してPodを公開することができます。
つまりIngressを作成しないためALBはIaCなどKubernetesのライフサイクルの外で管理できます。
TargetGroupBindingを利用すると以下の図のように、新旧クラスターで同じALBを利用して、異なるTargetGroupにぶら下がる構成となります。
これによりALBのWeightedRoutingをが利用でき、新クラスターにリクエストを少しずつ移行することが可能となります。
クラスタ別のリソース定義の書き換えをどうするか
ここまで紹介した内容の改善を行って来た結果、一部問題が生じました。 TargetGroupBindingを利用すると、クラスター別で異なるTargetGroupのARNをManifestに記述する必要があります。 このARNをどのようにして書き換えるかという問題が生じました。
私達はKustomizeを利用して環境毎(Dev/Stg/Prd)のManifestの管理を行っています。そのため新旧クラスター毎にディレクトリを分けてkustomization.yamlを作成しました。ApplicationSet においては、クラスター別にロードするパスを分けることで対応しました。具体的なファイル構成を以下に記述します。
ディレクトリツリー
├── production │ ├── kustomization.yaml │ ├── ... ├── production-blue-cluster │ ├── kustomization.yaml │ └── patches │ └── targetgroupbinding.yaml └── production-green-cluster ├── kustomization.yaml └── patches └── targetgroupbinding.yaml
上記の./production
配下のファイル群はこれまでデプロイに利用していた既存のファイルです。
production-[blue|green]-cluster
が新規追加したディレクトリとkustomization.yamlになります。
production-[blue|green]-cluster/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - ../production patches: - patches/targetgroupbinding.yml
既存のkustomizeの構成には手を入れずTargetGroupBindingに関する記述のみpatchをあてるような構成にしています。
patches
--- apiVersion: elbv2.k8s.aws/v1alpha1 kind: TargetGroupBinding metadata: name: my-tgb spec: targetGroupARN: 'arn://hogefugapiyo' networking: ingress: - from: - securityGroup: groupID: 'sg-hogefugapiyo'
patchには新旧クラスターで異なるTargetGroupのARNとALBのセキュリティグループIDを記述します。
ArgoCD ApplicationSet
apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: my-app namespace: my-service spec: generators: - clusters: {} # Automatically use all clusters defined within Argo CD template: spec: source: path: k8s-manifest/project/production-{{cluster}} ...
ArgoCDのApplicationSetではGeneratorを利用して{{cluster}}
部分を変数化することで、自動的にB/Gクラスター用のデプロイ設定(Applicationリソース)を作成することができます。
さいごに
EKSクラスターのバージョンアップ作業を効率化するための取り組みについて紹介しました。 TargetGroupBindingを利用したクラスターのB/Gアップグレードはよく耳にしますが実際に私達の環境で実践してみると課題があり様々な解決方法があることを知りました。
今回、私達はこのブログに書いた方針で対応をとりましたが、今後運用を進めるとよりよい方法やツールを知ることになると思うので、このような改善は継続してどこかで公開できればと思います。
明日のはてなエンジニアAdvent Calendarは id:kouki_dan さんです。
AWS Certified Solutions Architect Professional の更新試験に合格しました
少し前の話しですが、AWS Certified Solutions Architect Professionalが有効期限をむかえるということだったので更新のために受験しました。 結果は無事に合格&スコアアップすることができたのでどうやって勉強したかを残しておきます。
自身のスペック
- AWS暦
- 6年くらい
- 仕事で本格的に触り始めたのは4年前
- 資格
- 仕事
- SREです。ここ2年くらいはkubernetesを中心にAWSとGCPを触っている
とりあえず模試を受けた
模試の結果は合格経験があるもののスコアは55%で手応え全くなしという状態でした(55%は運だと思っている...)。 ここから落ち込んだのか、なぜかやる気がなくなってしばらく無の時間が続き試験2ヶ月前から本格的に勉強を開始しました。 直前に一気に勉強する体力がなさそうだったので1冊の本を時間をかけて勉強することにしました。
読んだ本
たまたまAmazonにオススメされた本ですが演習問題が多く問題毎の解説がよくまとまってそうだったのでこの本で勉強することにしました。 前回、はじめて受験したときは問題文が長く時間内に全部の問題を解くことができませんでした。 なので多くの問題に触れて問題に慣れることが必要だと思い演習問題中心の本を選びました。
約2ヶ月の間、平日は1H、休日は2Hを上限と決めて毎日やった(エルデンリングが発売されたためこれ以上の時間確保は無理)
Black Belt オンラインセミナーを利用
普段利用しないサービスについては単語もまったくわからない状態だったのでAWS Black Belt オンラインセミナーの資料やYoutubeを利用しました。 特にDirectConnect, Organization などですね。
模試(2回目)
受験2週間前に再度、模試を受けた。初回受験時は有料の模試だったのですがいつの間にかAWS Skill Builderで模試が無料で受験できるようになっていました!
20問の問題を解くことができて、ログインすれば問題何度も見返すことができます。 問題の解説もあるので前の模試 勉強の成果もありスコアは80%でなんとかなりそうな感じになってきました。
テストの手応え
- 全問解くことがきて時間が結構余った
- ほとんどの問題を理解して対応することができた。手応えがなかった問題は1問くらい
- それなりにスコアアップできた
というわけで無事に合格できてよかったです(結構不安だったので)。 3時間のテスト時間で問題文の長い問題を素早く解き続けるのは知識も必要だけど、ある程度の訓練が必要だなと感じました。 試験の勉強を通して忘れていた制約や便利なアーキテクチャを思い出せたのも良かったです。
Auroraのインプレースアップグレードは手動で再起動するまでデフォルトパラメータグループで動作するため注意
背景
先日、Amazon Aurora MySQL version 1 ( MySQL 5.6 互換 ) のEOLが2023/02/28に予定されました ( 以降、Aurora MySQL v1と記述 )。 2022/09/27 からAurora MySQL v1の作成ができなくなります。 Aurora MySQL v1で動作しているクラスターをAurora MySQL v2 ( MySQL 5.7 互換 ) or Aurora MySQL v3 ( MySQL8.0 互換 )にバージョンアップする必要があります。
アップグレードの方法
アップグレードの方法は主にインプレースアップグレードとBlue/Greenアップグレードの2種類の方法があります。
インプレースアップグレード
利用中のクラスタでアップグレード処理を実施します。インスタンスのシャットダウンが発生しますが手順はシンプルです。エンドポイントはそのまま保持されるため変更の手間もありません。
Blue/Greenアップグレード
aws.amazon.com (英語ドキュメントしか無さそう)
新しくMySQL5.7のクラスタを構築して、MySQL5.6のクラスタからデータをレプリケーションすることで2つのクラスタが同じデータを保持している状態を作ります。最終的にエンドポイントの切り替えによってバージョンアップを実施します。インプレースアップグレードよりもダウンタイムを少なくすることができます。
インプレースアップグレードを実施して分かった問題
インプレースアップグレードはとてもざっくりですが↓の図のような流れでアップグレード処理が走ります。
問題なのは↑の赤いPending Reboot (再起動保留中)
の状態で、再起動を待ちながらDBインスタンスは起動しています。
このPending Reboot (再起動保留中)
の状態ではデフォルトのパラメータグループ( default.aurora-mysql5.7
)でAurora が動作している状態です。そしてカスタムパラメータ設定を適用するには手動で再起動を実施する必要があります。
これはドキュメントにも下記のように書いてあります。
アップグレードプロセス中にカスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動する必要があります。再起動すると、クラスターがカスタムパラメータ設定の使用を開始できます。
つまりアプリケーションを起動した状態でインプレースアップグレードを実施した場合、カスタムパラメータグループの内容によってはサービス影響が発生する可能性があります。
対策
アップグレードの前後でアプリケーションを停止する
インプレースアップグレードの所要時間はデータ量やクラスターのビジー状態によって変わってくるのでアプリケーションの停止時間が読みにくいというところはあります。
Blue/Greenアップグレードを採用する
Blue/Greenアップグレードはクラスタを新しく構築するためエンドポイントを参照している箇所を変更する必要があります。参照している箇所が把握できていなかったり、変更箇所が多かったりすると結構大変な作業になりそうです。
まとめ
- 2023/02/28 に Aurora MySQL v1 が EOL を迎えます
- アップグレードの方法はインプレースアップグレードとBlue/Greenアップグレードの2種類
- カスタムパラメータを利用してインプレースアップグレードを行う場合には注意が必要
はてなにおけるCloudNative推進会の活動について
こんにちは。
はてなでSREをやっているid:masayosu です。
この記事ははてなエンジニアAdvent Calendarの15日目のエントリです。
サブ会と呼ばれている組織の一つ、CloudNative推進会について紹介します。
サブ会について
はてなにはサブ会という集まりがあります。
サブ会というのは所属する組織とは別で、あるテーマに興味を持ったメンバーの集まりです。テーマに関わる知見を深めていくような活動を行い、その内容を社内に共有するような働きをするため会社公認の組織です。
サブ会には以下のようなメリットがあります。
- 予算要望をあげることができる
- 自分の興味あるテーマについて業務時間を利用して調査することができる
- 個人の成果目標の一部にサブ会での活動成果を含めることができる
個人調査やボランティア活動になりがちな活動の成果をフィードバックすることで会社に活動を認めてもらえるといった制度です。
CloudNative 推進会について
はてなの技術グループでは2019年からコンテナ化を推進していて、新旧さまざまなサービスをコンテナで運用するようになりました。CloudNative推進会は2019年に発足され、コンテナ化をサポートするための活動を継続して行っています。
はてな社内で課題となっているテーマを半期に一度選定して、技術グループのサポートとなるような成果物をアウトプットしています。
これまでの活動
活動テーマを選定するために社内のサービスチームのコンテナ化の現状をヒアリングました。そのヒアリングの結果と Cloud Native Trail Mapを見て、はてな技術グループの現在地を確認します。そして解決できたら一番嬉しい題材を半期のテーマとして選定します。
これまでの活動で、社内向けに出した成果物を3つ紹介していきます。
コンテナチェックリスト
コンテナチェックリストとはアプリケーションをコンテナ化する際のノウハウをチェックリスト形式でまとめたものです。
アプリケーション対応、Dockerfile、イメージ管理、CI/CD、オーケストレーション、モニタリング、ログといった項目毎にチェックリストを作成しています。
アーキテクチャの設計段階やリリース前のチェックとして各サービスチームに利用してもらっています。
CloudNative CI/CD
CI/CDの定義とそのプラクティスをまとめたドキュメントです。
CI/CDのShipプロセスを工程(ステージ)に分割して一般的なワークフローを提示しています。
ツールとしてのCI/CDの理解ではなく抽象度を上げて理解することで各ステージでの役割と責任範囲を明確にすることができました。適切な役割でステージを分割できるとリリースサイクルを早めたりリリースリスクが低減できるメリットがあります。
CloudNative Batch Processing
社内においてWebアプリケーションのコンテナ化についてはノウハウが蓄積されてきていたのでBatchに目を向けてノウハウををまとめました。CloudNativeな環境でBatchを動作させる場合、Batchアプリケーション以外の管理( Event Source, Monitoring, Storage, LogCollector)はプラットフォームが持つマネージドなサービスを頼ることができます。
ただ、それらのマネージドなサービスを利用する際に意識するポイントがいくつかあります。このあたりの話については先日のHatena Developpers BlogでもCloudNative推進会のメンバーでもある id:tkzwtksさんの記事でも触れられています。
まとめ
CloudNative推進会の活動について紹介しました。
CloudNative推進会は技術グループに所属する異なったロールのメンバーが集まるため、様々な技術ジャンルについて活発に議論できる場です。
これからも良い成果が出せるようにやっていくぞ!
さいごに
はてなでは全方位的にエンジニアを積極採用中です!
一緒にCloudNativeについて議論しましょう!
明日のはてなエンジニアAdvent Calendarは id:kouki_dan さんです。
宜しくお願いします!
株式会社はてなに入社しました
7/1付けで株式会社はてなに入社しました。
前職での AWS の利用経験と SRE としてやってきたことを認めていただき id:hayajo_77 さんにチャンスをいただくことができました。id:hayajo_77 さんとは以前も新潟で同じ会社で働いていたので、本当に感謝しています。チームは別ですが、また一緒に働くことができて楽しみです。
ロールはこれまでと同じ SRE です。SREing について、これまで以上に掘り下げて実践していく必要がありそうです。技術的にも幅を広げることができそうなので、ひとつずつ整理しながら前進していきたいと思っています。
コロナ禍という状況だけど、リモートでオンボーディングしたり普段は体験できないことを経験しています。殆どのチームメンバーにはリモートでしか会えないので早くコロナウィルスが収束することを祈っています。
いつになるか分からないけど京都オフィスにもお邪魔したいです。
早くも知識の洪水でパンク状態ですが、焦らず楽しみながらやっていこうと思います。
がんばるぞー!おー!!