『イラストでわかるDockerとKubernetes』を読んだ

どんな本か

この本はタイトルどおりイラストを交えてDocker・Kubernetesについて分かりやすく説明された本です。

構成は以下の通りで、ページ数も130ページ程度なのでサクッと読めるようになっています。

  • 第1章 コンテナ技術の概要
  • 第2章 Dockerの概要
  • 第3章 Kubernetesの概要
  • 第4章 コンテナランタイムとコンテナの標準仕様の概要

目的

普段はローカル環境でDockerを使ったり、本番環境にAWSのAmazon ECSを導入してみたりはしましたが、Kubernetesは全くさわってきませんでした。

最近ふとKubernetesを実際にさわってみて、仕事に活かしたりできないかと思い、この本を手に取りました。

「まずはKubernetesやその周辺技術の概要をざっくりで良いので掴みたい」というのが目的です。

感想

Kubernetesの仕組みやより踏み込んだコンテナランタイムや標準仕様などの説明が分かりやすく、個人的にすごく面白かったです。 特にkubelet、CRIランタイム、CNIプラグイン、OCIランタイムらへんはもっと深堀りしてみたい。

要所要所にイラストや実際に実行したコマンドの結果を載せてくれているので、手を動かさずに読み進めても雰囲気で理解できますが、一度Kubuernetesの環境構築をしたほうが良さそうです。 あと、実際に使う場合、Amazon EKSやGoogleのGKEを利用すると思うので、そこらへんの構築も試して手順として残しておきたいところ。

以下の本は初めてKubernetesさわる人が読むと良いらしいとTwitterで見たので、次はこれを読みつつ手を動かしていこう。

あと、以前聞いたfukabori.fmのdocker/kubernetes周りのネットワーキングの話も改めて聴く。

fukabori.fm

eh-career.com

読書ノート

第1章 コンテナ技術の概要

  • コンテナもその実態はプロセスで、異なるのはOSカーネルの機能を用いて通常のプロセスよりもより強く環境が隔離されている点

第2章 Dockerの概要

  • コンテナイメージの作成
    • Dockerfile: コンテナの作成手順書
    • コンテキスト: コンテナに格納するプログラムなどのファイル群
  • コンテナイメージのレイヤ構造
    • レイヤ(変更差分)
    • コンテナは変更差分を集めたもの
  • コンテナのレイヤ構造は、その実行時にも保たれている
  • コンテナのレイヤ構造は、コンテナ同士で可能な限りデータの重複を作らないようにしつつ、お互いの環境が影響し合わないようにする
  • あるイメージからコンテナを複数実行する場合でも、それらコンテナ同士で共通のレイヤ群はコピーされることなく、共有される
  • Storage Driverは、コンテナを構成する各レイヤをホスト上で保持しており、それらを重ね合わせてコンテナのルートファイルシステムとして利用できるようにするなど、レイヤ群の管理を担うコンポーネント
    • 実装は、aufs, btrfs, overlayfsなど、さまざまなファイルシステムなどの技術が用いられている
  • overlayファイルシステムはLinuxカーネル3.18から導入され、あるディレクトリを別のディレクトリへ重ね合わせ、その重ね合わせた結果をマウントすることができるファイルシステム
  • マシン上ではDockerデーモン(dockerd)が起動しており、dockerコマンドからDocker APIと呼ばれるHTTP API経由で支持を受ける
  • Dockerデーモンは、コンテナの実行だけでなく、そのイメージやネットワーク、ストレージなどコンテナのライフサイクル全体にわたる管理を担っている
  • ホストから隔離された実行環境をコンテナとして作り出したり、それを直接操作するのはDockerデーモンではなく、OCIランタイム(低レベルランタイム)と呼ばれるソフトウェアが担当する

第3章 Kubernetesの概要

  • Kubernetesに対して「アプリケーションやそれを構成するコンテナ群はこういう状態であるべき」というような理想状態をYAMLやJSON形式の「マニフェスト」と呼ばれる設定ファイルの形で宣言すると、それを実現・維持するための具体的な作業をKubernetesがよしなに行ってくれるというもの。
  • Kubernetesは管理情報をHTTP APIで公開しており、ユーザはそのAPIの操作を通じて前節で述べたような理想状態の宣言や、アプリケーションに関する状態の確認などを行う
    • このAPIを参照・操作しながら、ユーザーが宣言した理想状態を維持するために具体的な管理作業を行うコンポーネント群は「コントローラ」と呼ばれる
  • コンテナ群を実行するマシンの集合を「クラスタ」と呼ぶ
  • 各コンテナが実行されるマシンは「ノード」と呼ぶ
  • ノード上では複数の「ノードコンポーネント」が稼働し、そのノード上のコンテナ群の実行管理やイメージの管理、通信の管理などを行う
  • Kubernetesクラスタ全体の管理を担うコンポーネントは「コントロールプレーン」と呼ぶ
    • コントローラーやコンテナのデプロイ時にそのスケジューリングを行うコンポーネントなどが含まれる
  • Kubernetesにおいて最も基本的なデプロイ単位は関連する複数のコンテナ群を1つにまとめた「Pod」と呼ばれているもの
  • 1つのPodに含まれるコンテナ群は同一のノード上にデプロイされ、ネットワーク・インターフェースやストレージの割当などを共有する
  • KubernetesはIPアドレスをPodごとに払い出すため、Pod同士はそれぞれのIPアドレスを使って通信できる。またPod内のコンテナはlocalhostで通信できる。
  • Pod群のデプロイにまつわるリソース
    • Deployment
      • Pod群を一定数を維持しながらクラスタ上に展開するのに有用なリソース
      • セルフヒーリング
        • 障害の発生などによりクラスタ全体で設定された数のPodが正常に稼働していない場合に、自動敵に新たなPodを実行し復旧を試みる機能
      • スケーリング
    • StatefullSet
      • ステートフルなコンテナの実行をサポート
      • Podにはインデックス0を含むPod名と固有のボリューム)PersistentVolume)が付与される
    • DeamonSet
      • 各ノード上にPodが1つずつ実行されている状態を維持するリソース
    • Job
      • 単発に実行するユースケースに有効
    • CronJob
      • Conフォーマットで実行開始時間や定期実行など設定可能
  • Podやコンテナは、長期的な状態を持たないステートレス、またはエフェメラルな(揮発性の)実行単位と言われる
  • 設定項目・秘匿項目を独立して管理できるように、ConfigMapやSecretというリソースがある
    • コンテナ内の環境変数としてみせる
    • コンテナ内のファイルシステムに読み取り専用でマウントし、ファイルとして見せる
  • Service
    • あるサービスを提供する複数のPodに共通のIPアドレスを付与し、1つの「サービス」のようにアクセスできるようになる
    • Pod自体にもIPアドレスが付与されているが、Serviceが必要なのはなぜか?
      • Kubernetes上ではPodのIPアドレスは頻繁に変わり得るという点が挙げられる
    • リソースの種類
      • NodePort
        • 各ノード上のポートをクラスタ外に公開し、そのポートを通じた通信を、そのServiceを構成するPodのいずれかにロードバランスする。
      • Load Balancer Service
      • Ingress
        • L7ロード・バランシングの機能を提供する
        • 1つのアプリケーションを複数のServiceを用いて構成し、URLのホスト名やパスのルールベースで、実際にアクセス先として用いる
  • kubelet
    • ノード上のPod群の実行管理を行う
  • CRIランタイム
    • イメージの取得やPod・コンテナ群の管理を行う
  • CNIプラグイン
    • Podの作成はCRIランタイムが担当するが、そのPodにIPアドレスを払い出し、仮想的なNICをPodに付与するのはCNIプラグインが行う
      • flannel, Calico
  • OCIランタイム
    • CRIランタイムなど高位のランタイムから指示を受け、ホストから隔離された実行環境をコンテナとして作り出しその直接操作の手段を与える

第4章 コンテナランタイムとコンテナの標準仕様の概要

  • containerd
    • Dockerはコンテナ実行のためにcontainerdを内部で使用している
    • containerdはCRIを実装しているため、Kubernetes環境ではcontainerdを単体のCRIランタイムとして用いることができる
    • containerdが低レベルランタイムを呼び出すときは、shimと呼ばれるバイナリコンポーネントを介する。低レベルランタイムは、それぞれの持つアーキテクチャに合ったshimを実装し、それをcontainerdにプラグインすることで、containerdを通じてそれら低レベルランタイムを操作できるようになる。
  • 低レベルランタイムはOCIで定義されたインターフェースを通じて高レベルランタイムから指示を受け、ホストから隔離された実行環境を作成したり、その操作手段を提供する
    • コンテナ(ホストから隔離された実行環境)の作り方は1つではなく、低レベルランタイムによってさまざなバリエーションがある。
    • runc, gVisor, Kata Containersas
  • OCI Runtime SpecificationはOCIによって策定されている低レベルランタイムの仕様のこと
  • Filesystem bundle
    • ファイル群が格納されたディレクトリ
      • コンテナのルートファイルシステム
      • コンテナ実行環境の設定ファイル
  • コンテナのライフサイクル
    1. Filesystem bundleをOCI準拠のランタイムに指定し、コンテナを作成
    2. コンテナの実行を開始
    3. コンテナ内のアプリケーションが終了する
    4. コンテナを削除する
  • コンテナに対して可能な操作
    • create
    • start
    • kill
    • delete
    • state
  • OCI Image Specification
    • マニフェスト
    • レイヤ
    • コンフィギュレーション
    • インデックス(optional)
  • namespace
    • あるプロセスから操作可能なリソースを、その他のプロセスから隔離できる機能
    • PIC namespace プロセス群の管理
    • Mount namespace マウントポイントリストの隔離
    • Network namespace ネットワーク関連のリソースの隔離
  • cgroup
    • プロセスが使用可能なリソースについて、たとえば以下を含むさまざまな設定を施せる機能
    • デバイスファイルへのアクセス権限
    • プロセスから利用可能なCPUの制限
    • プロセスが利用可能なメモリ使用量の制限

2021年5月10日 ~ 17日 振り返り

GWと先週の振り返り。

仕事

CircleCIの設定ファイルの修正

概要

CircleCI上でサブプロジェクトをsbt assemblyするよう設定ファイルを修正しました。

詳細

今進めているプロジェクトのコードは一つのディレクトリに複数のサブプロジェクトが入っており、それらをマルチプロジェクトビルドしています。

その中にはEC2上で実行されるアプリケーションやAWS Lambdaとして起動されるものも含まれています。

CI上ではこれらサブプロジェクトのビルドやテストを実行していたのですが、AWS Lambdaとして起動されるサブプロジェクトのコードはCI上ではビルドする設定が記述されていませんでした。

そのため、あるライブラリをバージョンアップしてdevelopブランチでは動いていたため、masterブランチにマージしてリリースしようとした際に、sbt assemblyコマンドでjarを生成する段階でエラーが発生しました。

エラー内容としては、sbt-assemblyを使用してjarを生成する際に同名ファイルがあったためエラーになっていました。

気づかなかった原因としては、違うタイミングでsbtのMergeStrategyが修正されており、masterブランチにそれらが含まれていなかったということです。

ただ、CIでsbt assemblyをするよう設定をしておけばもっと早い段階で気づけたため、今回の修正対応を行いました。

解決策

.circleci/config.yml に以下のような設定を追加

      - run:
          name: run lambdaXXXX/assembly
          command: |
            if [ "$CIRCLE_NODE_INDEX" == "5" ]; then cat /dev/null | sbt 'set lambdaXXXX/test in lambdaXXXX/assembly := {}' lambdaXXXX/clean lambdaXXXX/assembly; else true; fi
          no_output_timeout: 30m

CIRCLE_NODE_INDEX はCircleCIが定義している環境変数で、並列実行しているジョブのIndexを指します。

circleci.com

なぜ、以下のような書き方をしているかというと、他のジョブでテストを実行するよう設定しているため、ここではsbt assembly時はテストの実行を無視したかったからです。

sbt 'set lambdaXXXX/test in lambdaXXXX/assembly := {}' lambdaXXXX/clean lambdaXXXX/assembly

プロジェクトに新しいAPIを追加

概要

PoCプロジェクトで利用するAPIを新規で追加しました。

詳細

あまり詳細に書けないのであれですが、以下のライブラリとかプロジェクトで使ってて便利だしバリバリ使ってるので、コードリーディングしないとなーと感じてます。

github.com

github.com

github.com

プライベート

読書

『雰囲気でOAuth2.0を~』等

Auth屋さんのOAuth2.0・OIDC関連の本を読みました。

OAuth2.0とOIDCがいまいち分からない人やOAuthを利用したり実装したりする場合に気をつけるポイントを押さえたいと思っている方はぜひ読んでみてください!

かなりおすすめです!

blog.ryskit.com

blog.ryskit.com

blog.ryskit.com

やったこと

GW中や休日は FP in Scalaをやり直してました。

tatsu-zine.com

前回やったときはPart1 までやったのですが、今回はすべてやり抜こうと思い少しずつ進めています。

今はやっと第8章のプロパティベースのテストに入りました。

Part2 から難しく感じて、進みが遅いですがやり抜きたい!

github.com

『エルゴトロン LX デスクマウント モニターアーム』を買った

タイトルのとおり、エルゴトロンのLX デスクマウント モニターアームを買いました!

なぜ買ったのか?

以前はディスプレイと一緒に買った安物のモニターアームを使っていました。

ただ、この安物のモニターアームが届いてからずっと気に入りませんでした!

何が気に入らなかったかというと、ディスプレイの位置を調整するには付属品の六角レンチを使わなくて、わざわざ六角レンチを使って緩めては締めてという動作がかなり面倒な点です。

それが嫌で一時はある程度の高さまで積んだ本の上に、ディスプレイに付属していたスタンドで作業をしていました。

ただそれだとデスクの奥行きがなくなりPCと本の距離が近くなってしまい、PCの熱が逃げにくくなってファンが回りやすい状態でした。

これではイケないなと思い、ちょっとお高いですが今回のエルゴトロンのモニターアームを買いました!

感想

めちゃめちゃ良いです!

最初はお使いのディスプレイの重量に合わせて微調整は必要ですが、それ以降はディスプレイを好きな場所に簡単に移動させられます。

正直、安いものを買ってガッカリするぐらいなら、エルゴトロンLX買っておいても損しないと思います。

おそらく安いもの買っても結局イライラして買い換えると思うので、それなら最初から買っておくのがおすすめです!

このエルゴトロンの解説動画もおすすめです!買おうか考えている人は見てみてはどうでしょうか?

youtu.be

『OAuth・OIDCへの攻撃と対策を整理して理解できる本(リダイレクトへの攻撃編)』を読んだ

目的

前作・前々作を読んで理解しましたが、攻撃を仕掛ける側はどうやって攻撃をしてくるのか、それの対策方法を知りたかったからです。

techbookfest.org

以下は、前作・前々作の記事です。

blog.ryskit.com

blog.ryskit.com

感想

OAuthやOIDCのおさらいは書かれているものの、理解ある前提ではあると思うので、事前に前作・前々作を読んでから読むのが良いかなと思います。

techbookfest.org

techbookfest.org

この本では、OAuth/OIDCへの5種類の攻撃方法の説明とその対策がシーケンス図とともに分かりやすく書かれています。

だいたいはOAuth/OIDCを使う側だと思うので、認可サーバを実装する機会はあまりないかと思いますが、クライアントやリライングパーティ側で特定の値の検証することで攻撃への対策ができるものもあります。

そういった対策をこの本を読んで知っておくことで、「ライブラリやフレームワークを選定する場合」や「自ら実装する場合」に活きてくるのかなと思いました。

第7章の全体整理では、OAuth/OIDCのどのグラント/フローの場合にどのような攻撃がされるのか、その対策は何なのか、第6章までで説明された内容がフォーマットに沿って整理されているため、時間が経って詳細を忘れた場合でも思い出すのに役立ちそうです。

読書メモ

第1章 OAuth・OIDCのおさらい

  • OAuth Danceとは
    • 認可コードフロー、インプリシットフローではクライアント・認可サーバ間で何度も情報のやりとりが行われるが、その様子を指す
  • OAuth Danceの中で認可レスポンスが狙われる理由は3点
    • 認可コード、アクセストークン、IDトークンなどの情報がURIの中に含まれている
    • 認可サーバ、クライアント間の情報のやり取りの間にブラウザのリダイレクトを介している
    • 認可サーバ・IDプロバイダによるリソースオーナー(エンドユーザー)の認証・同意処理が完了済み
  • 上記のやりとりへの攻撃として5種類の攻撃がある
    • CSRF
    • リプレイスアタック
    • コードインジェクション
    • トークンインジェクション
    • 認可コード横取り攻撃

第2章 CSRF

  • 認可サーバーでは state に対して何の検証も行わない。state の検証を行うのはアプリであることに注意
  • state を使うことで CSRF を防ぐことができる
  • state により 認証リクエストのセッションと認証レスポンスのセッションが同一であることを検証できる
  • OAuthは仕様でstateの利用は任意になっているため、ライブラリやフレームワークを利用する際は事前にstateの検証が正しく行われるかチェックが必要
  • セッションごとにstateを生成しなければならない
  • 推測困難なランダムな文字列を state として使う
  • 認可レスポンスのセッションと state の紐付けを確認する
  • state が含まれていない認可レスポンスはエラーで返す
  • OAuth 2.0 Security Best Current Practice

第3章 リプレイス攻撃

  • 第三者のIDトークンを攻撃者自身の管理下にあるアプリに適用
  • 攻撃対象のフロー
    • インプリシットフロー
    • ハイブリットフロー
  • nonce - number used once
  • リプレイス攻撃を可能にしてしまう原因は、同じIDトークンを他のデバイスのアプリ上で利用できてしまうこと
  • IDトークンの検証完了後、nonce を無効化する

第4章 認可コード横取り攻撃

  • 同じデバイスにインストールされた「同じカスタムスキームを持つアプリ」に認可コードを奪われる。結果、アクセストークンを取得される
  • 対象は、OAuth, OIDC
  • 攻撃対象は、認可コードフロー、ハイブリッドフロー(response_typeにcodeを含むもの)
  • 攻撃を可能にしているポイントが同じカスタムスキームであること
  • PKCE
    • code_verifier
      • 長さ43文字、最大128文字までの間の[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" / からなるランダム文字列
    • code_challenge
      • code_verifierに対して code_challenge_method の計算をほどこして算出された値
    • code_challenge_method
      • plain
        • code_challenge = code_verifier
      • S256
        • code_challenge = BASE64URL-ENCODE( SHA256 (ASCII( code_verifier ) ) )
  • 認可サーバで、code_verifierの検証が行われる

第5章 トークンインジェクション

  • 第三者の有効なアクセストークンを攻撃者自身の管理下にあるアプリに適用
  • 攻撃対象は、OAuth、OIDC
  • OAuthには対策がない(独自対応しているサービスはある)
  • at_hash <- access token hash?
    • IDトークンに含まれるクレームの1つ
  • IDトークンには2つの役割がある
    • 認証アサーションとしての役割
    • デタッチ署名としての役割
  • 認証レスポンスのアクセストークンの情報を、ペイロードに含めることで、アクセストークンの署名としても機能する
  • ペイロードには「IDトークンの署名と同じハッシュアルゴリズムでアクセストークンのハッシュ値を算出し、その左半分をBase64URLエンコードした文字列」を at_hashの値に入れる
  • 取得したアクセストークンに対して、上記で算出したat_hashの値とIDトークンのペイロードに埋め込まれたat_hashの値を比較することで入れ替えに気づくことができる
  • インプリシットグラントは使わず、認可コード + PKCE
  • フラグメントはリダイレクト時にその情報がサーバに送られないため、漏洩のリスクが下がる
  • コラム: トークンはどこからもれるのか?が面白い p.66

第6章 コードインジェクション

  • 第三者の未使用の認可コードを攻撃者自身の管理下にあるアプリに適用
  • 攻撃対象は、OAuth、OIDC
  • PKCE・nonce・c_hash(code hash?)による対策が書かれている
  • OAuthの仕様では認可コードは有効期限が短く、一度しか利用できないため、利用されていない許可コードを取得した上で、短い有効期限内に攻撃を完了する必要がある
  • コードインジェクションを防ぐために、アプリは「」セッションとcode_verifierの紐付け」を管理し、認可サーバは「code_challengeと認可コード(code)の紐付け」を管理する必要がある
  • コードインジェクションを防ぐために、アプリはセッションとnonceの紐付けを管理し、IDプロバイダはnonceと認可コード(code)の紐付けを管理する必要がある
  • c_hashが利用できるのは、response_typeの値にid_tokenとcodeの両方が含まれるハイブリッドフロー
  • c_hashは、「IDトークンの署名と同じハッシュアルゴリズムで認可コードのハッシュ値を算出市、その左半分をBase64URLエンコードした文字列」
    • 認証レスポンスで取得した認可コードに対して、上記と同じ演算を行い、同じく認証レスポンスで取得したIDトークンのc_hashの値を比較することで認可コードの入れ替えに気づくことができる

第7章 全体整理

  • 認可フローやクライアントの種別に応じて、攻撃の種別や対策方法がまとめられている
  • ハイブリットフローでのパラメータ共有について p.106

『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』を読んだ

目的

前作に続いて、OAuthとOpenID Connectの違いを理解したくてこの本を読みました。

techbookfest.org

感想

こちらも前作に続き分かりやすく解説されていて、かつサクッと読めます!

タイトルにもあるように、OAuth、OAuth認証、OpenID Connectの違いが整理して書かれているため、OAuthと比べてどこがどう違うのか上手く説明してくれています。

第2章でOAuthの復習の章を設けられていますが、個人的には前作の『雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本』を理解した後にすぐ読んだほうがより理解がしやすいのかなと思います。

techbookfest.org

あと、個人的にコラムは絶対読み飛ばさないほうが良いです!

OAuthの脆弱性やアプリのログインに脆弱性があった場合にどうやって攻撃されるのかが説明されているので、読み物としても面白いですし、実際にこうやって攻撃されるのかとOAuth認証やOIDCへの理解も深まると思うので。

読書ノート

  • OAuth認証
    • アプリはプロフィールAPIで得たユーザー識別子の情報などを利用して、ユーザーの認証が可能になる
    • OAuth認証、アプリのログイン実装の脆弱性についてのコラムが面白い - p29
    • Facebookではなりすましログインへの対策に /debug_tokenエンドポイントという独自エンドポイントを用意している
  • OpenID Connect(OIDC)
    • OAuthに IDトークン・UserInfoエンドポイントを加えたものを言う
    • IDトークンはユーザーの認証に利用
    • UserInfoエンドポイントはユーザーのプロフィール情報を得るために利用
    • OAuthとOIDCのロール関連用語に違いがある - p36
  • OIDCのフローは3つ
    • 認可コードフロー
    • インプリシットフロー
    • ハイブリッドフロー
      • インプリシットフローと認可コードフローのハイブリッドなフロー
      • パブリッククライアントとコンフィデンシャルクライアントの両方で構成されているクライアントに利用する
        • JavaScriptアプリ・ネイティブアプリ + バックエンドサーバー
  • OIDCでは scopeの値は仕様で決まっている
  • OAuthとOIDCの一番のち外はフローにおいて、IDトークンの発行が行われること
  • デタッチ署名とは、署名の対象と署名が分離した形式の署名のこと

『雰囲気でOAuth2.0 を使っているエンジニアが OAuth2.0を整理して、手を動かしながら学べる本』を読んだ

目的

OAuth2.0への理解を整理したい思い読みました。

techbookfest.org

感想

タイトルにもあるように雰囲気でOAuth2.0を使っている人やとりあえずOAuth2.0って何?って人にすごくおすすめです!

分かりやすいし、安い!

1~5章は、OAuth2.0とは何か?から始まり、OAuthの各グラントタイプごとにクライアントがどのような流れでトークンを受け取るか分かりやすく説明されています。

本自体は100ページ程度ですが、OAuth2.0の説明自体は60ページほどで1時間弱あればゆっくり読んでも読み終わるので、すごく良くまとまっているなと思いました!

個人的に、パブリッククライアント向けのグラントタイプとして推奨されている、「認可コードグラント+ PKCE」は知らなかったので勉強になりました!

6章は、実際にGoogleのPhoto Library APIを用いてOAuth2.0を手を動かしながら学べます。

1~5章で学んだ内容を実際に手を動かして復習できるので、理解も深まりやすいです。

OAuth2.0の説明を読んでよく分からなければ、まず6章の内容に従い手を動かしてから読むと良いかも知れません。

読書メモ

  • 認可エンドポイントとトークンエンドポイントは、認可サーバが提供するURI
  • リダイレクトエンドポイントはクライアントが提供するURI
  • トークンエンドポイントではBasic認証によって、クライアントのアイデンティティが確認される
  • Basic認証としてAuthorization ヘッダーに設定されるのは、クライアントID と クライアントシークレット
    • これらは認可サーバーにクライアントを事前登録する際に発行される
  • OAuthのグラントタイプ
    • 認可コードグラント
    • インプリシットグラント
      • 非推奨
    • クライアントクレデンシャルグラント
    • リソースオーナーパスワードクレデンシャルグラント
  • リソースオーナーパスワードクレデンシャルグラントを利用できるのは、リソースサーバーおよび認可サーバーとクライアントの提供元が同じ組織である場合
    • クライアントタイプがコンフィデンシャル、パブリックの両方で利用可
  • PKCE は「Proof Key for Code Exchange」の略で「ピクシー」と読む

2021年4月12日 ~ 18日 振り返り

先週の振り返りです。

仕事

Play2.6 Migration

先々週から引き続きPlay 2.6 Migration作業を行っていました。

ほぼほぼMigration Guideの項目は対応し終わっていましたが、以下の対応を行っていました。

  • deprecatedになったメソッドの修正
  • warningが出ているコードの修正
  • Unitテストの修正
  • 各プロジェクトのビルド・テストがCI上でALL Greenになるように修正

ほぼ一人で作業(ときどき同僚に相談乗ってもらった)だったので、なかなか根気のいる作業でしたが、無事完了できました!

あとは、検証環境で動作確認・数週間運用後に本番リリースを行う予定です。

AWS Lambda ランタイムのアップデート作業

会社の部内のプロジェクトでいくつかで使われているサービスがあり、それをだいぶ前に保守作業を移譲されて自分が担当しています。

今回、AWS Lambdaのnode.js10.xが2021年7月30日から「サポート終了フェーズ 1 」が開始されるとのことで、対応しておいたほうが良いということで着手しました。

(あれ、自分が読んだときは2021年5月末までだったけど変更された?)

docs.aws.amazon.com

Lambdaのランタイムのアップデート自体は結構すぐ対応できたのですが、ランタイムとは関係ない部分で一部エラーが発生しているのに気が付き、修正作業を行いました。

結構前に書かれたコードなのでライブラリのバージョンも上げたり、もっというとコード自体を書き直したりしたいところですが、機能が追加されたりするサービスではなく基本的に安定して稼働しているサービスなので着手できていないのが現状です。

ここらへんも保守・運用しやすいように細かいアップデートをしていきたいところです。

プライベート

ブロクにも書きましたが、4/16 (金) にAWS DevOps Engineer - Professionalに合格できました!

blog.ryskit.com

これであとはSpecialtyの資格をどんどん取っていくだけですが、ひとまずAWS以外のことも学びたいので資格勉強はGW明けまでお休みです。

今月の自分の課題図書にした「Akka実践バイブル」をあまり読み進められてなかったのでここらへんでスピード上げて読み進めていきます。

読書

AWS DevOps Engineer - Professionalに合格した

2021年4月16日(金)にAWS DevOps Engineer - Professional(DOP)の試験に合格しました!

f:id:ryskit:20210416223019p:plain

学習期間

学習期間は2週間で、1週間は試験範囲に出るAWSサービスのドキュメント等を読みさらっと流して、最後の1週間で模擬試験など受けて集中的に学習しました。

学習内容

まずはDOPの試験ガイドを読んで、出題範囲のAWSサービスのドキュメントを読みました。

AWS公式 DevOps Engineerの試験ガイド

ドキュメントにある程度目を通したら、Udemyで販売されているTutorials Dojoの模擬テストを一通り受けました。

www.udemy.com

模擬テストを受けるとだいたいの出題されるAWSサービスの範囲が分かるのと、解説を読めばこのAWSサービスで何を解決できるのか、詳細を把握できるかと思います。

模擬試験1回目は理解が深まってない状態で受けるのでスコアは悪かったんですが、そこは気にせず2、3回同じ模擬試験を受けて自分はどこを間違ったのかを把握したのが良かったのかなと思います。

間違った問題は正解の解説だけでなく、間違った選択肢の解説もちゃんと読んでおくと、自分のAWSサービスへの理解と実際のAWSサービスの挙動のズレを正せると思います。

また、解説にはAWSサービスのドキュメントリンクがだいたい記載されているので、それらはすべて隅々まで目を通すのが良いと思います。

余談

以前にAWS Security - Specialtyの試験を受験したときに勉強したAWSサービスががDOPの出題範囲と少し被っていたのがすごくラッキーでした。

領域別に試験があるとはいえ、重要なAWSサービスはいろんな試験に出題されるため、何回もドキュメントを読むことになるので理解が深まりやすいのが良いところです。

試験当日

試験日はいつもどおり7:30に起きて早めに試験会場の近くのスタバでコーヒーでも飲みながら、自分でまとめたAWSサービスの要点などを復習します。

試験前なので、水分を取りすぎてトイレに行きたくならないように気をつけました。笑

基本的にProfessionalの試験の問題文は長いし、日本語がかなり読みづらいので試験時間ギリギリまで使いました。

ちょっと不安だなと思った問題に対しては見直しフラグを立てて問題を解き進めて最後に見直すのが良いと思います。

1問1問時間掛けていると最後までたどり着けない可能性があるので、そこは気をつけたいところです。

次は?

社内にはAWS資格12冠を達成している人たちがゴロゴロいるのですが、それに追いつけるように2週間~1ヶ月に1つのペースでAWS試験を受けたいと思っています。

次は、AWS Database - Specialty(DBS)を受けようかなと考えています。

まだ6冠しか取得できていないので、あと最低5回も試験を受けないといけないのは憂鬱ですが頑張っていくぞ!

www.credly.com

話は変わりますが、6月にDBS関連の書籍が発売されるみたいです。発売されるまでには自力で勉強して合格していきたいところ!!

要点整理から攻略する『AWS認定 データベース-専門知識』

それではまた!

2021年4月5日 ~ 11日 振り返り

先週の振り返り。

仕事

先々週に引き続き、Playframework 2.6のMigration作業を行いました。

Play 2.6に移行したことでdeprecatedになったメソッドがいくつもあり、テストを実行するとwarnログが出力されてXXかYYに置き換えろと怒られるので、ひたすらそれらを修正する作業です。

ただ、素直に置き換えるとテストが動かなくなったりするので、今度はテストを修正するという作業を行ったり来たりしていました。

なかなか根気のいる作業だなとは思いますが、どういう仕組みでフレームワークが動いているかを改めて勉強する良い機会にもなりますし、自分たちのアプリケーションへの知見を深める良い機会にもなります。

マルチプロジェクトで構成されていて、テストが完全には通ってないので次のスプリントでも対応が必要そうです。

プライベート

4/16 に AWS DevOps Engineer - Professional の試験が控えているので、勉強しつつ面白そうな勉強会にオンラインで参加していました。

もう少し読書したりしたいですが、今は試験勉強に集中!

2021年3月29日 ~ 4月4日 振り返り

先週の振り返り。

仕事

先週は、Play 2.6へのMigration作業を行いました。

機能開発ではなく改善タスクに多くの時間が割ける今、フレームワークのバージョンが古いものを上げていこうとチームで動いており、先々週あたりにPlay 2.4 から 2.5 に上げて問題がなかったので、2.6 にも上げてしまおうという流れです。

ただ、Play 2.5 から 2.6 へのMigrationに関して、Migration Guideを読んでもらうと分かるのですが変更点がかなり多いです。 www.playframework.com

play-jsonがライブラリとして切り出されたり、Akka Httpがサーバのデフォルトになったりと既存のコードに影響するものが多く、「コンパイルが通らないから通るように修正 → テストが通らない → 修正すると他でエラーが出る → 修正する」 みたいなサイクルをぐるぐる回していました。

今のプロジェクトに入ってから機能追加や修正をやっていましたが、Play自体にあまり詳しいわけではありません。今回2.6へのMigration作業を通してPlayFramework周りの知識を深められればなと思って作業しているので、かなり楽しく作業を進めれています。

先週だけでは終わる量ではなかったので、次のスプリントでも作業することになりそうです。

Migration作業について

アプリケーションフレームワークのMigrationは、Migration Guideがある場合はそれらをチェックシートにして作業を1つ1つ進めるのが良かったです。

というのも、変更内容が多い場合にいくつも修正作業を同時に進めてしまうと、どれがどこまで進んだのか進捗管理が難しくなってしまいます。また、修正作業の抜け漏れも発生しやすい状態になってしまうからです。

また、Migration作業を進めるに当たり作業ログも逐次書いていくと良いと思います。

作業ログがあると時間が空いてしまった場合にも思い出しやすいですし、作業を誰かに引き継ぐ場合にもここまでこういう内容で進めたと共有しやすくなるからです。

プライベート

注文していたOura Ringが届いて、最近コンディションや睡眠の数値を改善する活動にハマっています。

睡眠時の何が悪いのかを具体的な指標で示してくれるので、改善するポイントが分かりやすいのが気に入っています。

Amazonで買うと5万以上しますが公式サイトで注文すると3万弱で買えるので、もし検討されている人は公式サイトで買うことをオススメします!

ouraring.com

やったこと

  • AWS DevOps Engineer資格勉強
  • アルゴリズム実技検定公式テキスト 6.3 幅優先探索と深さ優先探索 まで

読書

入門 監視

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

先週は「入門 監視」を読みました。もっと早く読んでおけば監視の仕組みを作る際に参考になったのになと思いながら読んでました。

監視のアンチパターンやデザインパターン、良いアラートの仕組みなど、監視についてギュッと濃い内容でまとまっています。

あと、付録Cとしてsongmuさんが書かれた実践 監視SaaSも非常に勉強になりました。

3章には「良いアラートの仕組みを作る6つの方法」について書かれているのですが、その1つに「アラートにメールを使うのを止める」というのがあります。

アラートの使い道は以下の3つに集約されると書かれています。

- すぐに応答かアクションが必要なアラート
    - SMSなどに送る
- 注意が必要だがすぐにアクションは必要ないアラート
    - 社内チャットに送る
- 履歴や診断のために保存しておくアラート
    - ログファイルに送る

お客様とチームで使っているDataDogのアラートがメールとSlackに送られており、特にメールの量が多すぎるので注意力が削られている原因にもなっているので改善の余地があるなと感じました。

  • 監視アンチパターン
    • ツール依存
    • 役割としての監視
    • チェックボックス監視
    • 監視を支えにする
    • 手動設定
  • 監視デザインパターン
    • 組み合わせ可能な監視
    • ユーザ視点での監視
    • 作るのではなく買う
    • 継続的改善
  • 良いアラートの仕組み
    • アラートにメールを使うのを止める
    • 手順書を書く
    • 固定の閾値を決めることだけが方法ではない
    • アラートを削除し、チューニングしよう
    • メンテナンス期間を使おう
    • まずは自動復旧を試そう