~Terraformの基礎を90分で解説するチュートリアルをみて~

はじめに

インストール

tfファイルについて

  • このファイルに IaCで管理するリソースを書いていく
  • 実行時のポイント
    • 実行ディレクトリの直下にある tf ファイルを読みこんで実行する
      • 階層が違うと tf ファイルを認識してくれないので、各ファイルを同階層に置くのがベーシックな方法とのこと
      • さすがにそれだと管理が煩雑になりすぎるので、いろいろ工夫があるようだが今回触る範囲からは一旦外す
    • 各 .tf ファイルが結合されて実行される
      • リソース種類ごとの依存関係とかどうするんだと思ったけど、ある程度賢く terra form側で管理してくれるよう
      • 結合されるので各tfファイルの命名は動作には影響しない
  • 構文について
    • いっぱいあるけど、とりあえず一番基本的な3つの構文をピックアップ
      • resource: クラウドリソースを作るための構文
      • data: リソースの情報を取得するための構文
        • resource で作成したり管理してないけど、aws上にあるリソースの情報をとってくる時とかに使う(?)
        • 具体的な一例をあげると, 既存AWS環境を terraform に移行するときとか
      • variable: 変数を定義する
        • type で型の指定
        • default でデフォルト値の指定

構文のコード例

  • resource の例
    resource "リソースの種類" "リソース名" {
        設定項目1 = 設定値
        設定項目2 = 設定値
        設定項目3 = 設定値
    }
  • data の例
    data "リソースの種類" "リソース名"{
        filter = {
            Name = "リソース名"
        }
    }
  • variables の例
    # 変数定義側
    variables "変数名" {
        type = string,
        default = "hoge"
    } 

    # 呼び出し側
    resource "Xxxx" "Xxxx" {
        hoge = vars.変数名
    }

tfstateファイルについて

  • terraform で管理しているインフラリソースをすべて記載した json 形式のファイル
    • terraform.tfstate
  • 今回はローカルにこのファイルおく形とする。実務では複数人がさわる環境でローカルファイルで管理するわけにもいかないので、S3上でこのファイルを管理する方法がよく使われているらしい。

bicep との大きな違いの部分だと感じました。bicep ではインフラ全体の状態を管理するようなファイルはないので、IaCの設計方針が大分変わりそうですね。

実リソースとコードの差分がすぐに出せて比較できるのは素晴らしい反面、厳密に状態が管理される前提なので設計の難易度が高めと感じました。

コードを書く

  • 作業ディレクトリ用に適当なディレクトリを作成する
  • 作業ディレクトリ配下に以下ファイルを作成する。

    • provider.tf
    • vpc.tf
    • ec2.tf
      • ここでは webサーバー用途を想定しているので apache を入れてみている
  • provider.tf

provider "aws" {
    region = "ap-northeast-1"
}
resource "aws_vpc" "test-vpc" {
    cidr_block = "10.0.0.0/16"

    tags = {
        Name = "test-vpc"
    }
}

resource "aws_subnet" "test-subnet-public-ap-northeast-1a" {
    vpc_id = aws_vpc.test-vpc.id
    cidr_block = "10.0.1.0/24"

    availability_zone = "ap-northeast-1a"

    tags = {
        Name = "test-subnet-public-ap-northeast-1a"
    }
}
resource "aws_subnet" "test-subnet-public-ap-northeast-1c" {
    vpc_id = aws_vpc.test-vpc.id
    cidr_block = "10.0.2.0/24"

    availability_zone = "ap-northeast-1c"

    tags = {
        Name = "test-subnet-public-ap-northeast-1a"
    }
}
  • ec2.tf
resource "aws_instance" "sample_web_server" {
    ami                    = "ami-09d28faae2e9e7138" # Amazon Linux 2
    instance_type          = "t2.micro"

    user_data = <<EOF
    #! /bin/bash
    sudo yum install -y httpd
    sudo systemctl start httpd
    sudo systemctl enable httpd
    EOF
}

AWS のクレデンシャル設定について

AWS のクレデンシャル設定 の手順

  1. terraform で terraform 用のアクセスキーを作成する
    1. IAMユーザー画面に遷移
    2. 対象のユーザーを選択 or 新規作成 (用途に合わせて)
    3. セキュリティ認証情報タブの下の方いくとアクセスキー周りの設定箇所あるのでそこで設定
  2. 作成したら、アクセスキーとシークレットキーをメモっておく
  3. 以下コマンドをターミナルから実行して、環境変数を設定
        export AWS_ACCESS_KEY_ID="Xxx"
        export AWS_SECRET_ACCESS_KEY="Xxx"
        export AWS_REGION="ap-northeast-1"
        terraform plan

コマンド紹介

  1. terraform plan
    • tfstateで管理されているリソースの状態と、現在のterraformのコードの状態を比較して差分をとってくれる
    • bicep とか使ってるとこれできるのめちゃ便利だなあと思う
  2. terraform validate
    • terraform の構文チェックができる
    • terraform plan でもエラーでるので基本あんま使わなさそう
  3. terraform fmt
    • terraform のフォーマット崩れてるところを修正してくれる
  4. terraform apply
    • このコマンドで実際にリソース作成が行われる
  5. terraform destroy
    • ちなみにすべてではなく特定のリソースのデストロイしたいとき -t オプションで指定できる

実行

  • 以下コマンドを実行する。コンソール画面とかを見ると、リソースが出来上がっているのがわかる。
terraform plan
terraform fmt #tfファイルをフォーマットしてくれる
terraform apply

いろいろリソース触ってみたりしてもらった後は、以下コマンドで消す。作ったものが一気に消せるの便利...!!

terraform destroy

リソース消したら AWS のアクセスキーを一応無効化しておきます

  1. IAMの画面に行く
  2. 使っていたIAMユーザーを選択
  3. セキュリティ認証情報 タブを下に行くとアクセスキーの項目があるので、アクションボタンから無効化をする

おまけ

module

  • オブジェクト指向でいうところのクラスみたいなイメージ
  • 例: VPC と Subnet を組み合わせたテンプレートを作っておくなど
    • variables 構文を使って, cidr_block を渡してあげて、その部分だけは可変にするとかもできる

workspace

  • git のブランチみたいなイメージで、作業環境をterraform workspaceコマンドでスイッチできる
  • 例えば、環境ごとに workspace をスイッチするとかのユースケースが一例
    • develop,staging,production みたいな

OAuth 2.0 の概要メモと azure active directory を触ってみたメモ

はじめに

認可サーバー と OAuth 2.0 の概要

  • API経由でデータを取得するとき対策が何もないとすると、悪意のあるクライアントのリクエストにも、リソースサーバーは普通に応答してしまう
  • 対策のプラクティスとして...
    • クライアント側でリクエストを投げるときにアクセストークンも一緒になげる。リソースサーバー側でそれをチェックする。
    • アクセストークンは、Authrization ヘッダーとかに入れて投げる
  • 認可サーバー とは
    • 上記対策を実現するには、事前にクライアント側のサーバーにアクセストークンを発行しておく必要がある
    • このアクセストークンを発行する役割を持つのが 認可サーバー
  • OAuth 2.0 とは
    • アクセストークンの受け渡しする際の、クライアントサーバーと認可サーバーのやり取りの手順を標準化したもの
    • 画像の黄色い丸が OAuth2.0 の範囲

Open ID Connect の概要

  • こちらもクラインとサーバーと認可サーバー間のトークンのやり取りを標準化したものという点は同じ
  • 違う点としては認可サーバ(兼OpenIDプロバイダー)が ID トークンとアクセストークンどちらも払い出すことができる
  • ID トークンとはユーザーが認証されたことを証明するトーク
    • 認証後、その先のリソースサーバーにアクセスするため(認可)に使用するものではない
    • JWT形式で書かれている。Base64エンコードされいて、アプリ側でデコードするとユーザーに関する情報や認証に関する情報がのっている

OICDのトークンの発行手順

実際に触っていく内容

  • 上記の implicit flow を試していきたいと思います
    • アプリ側の実装がめんどくさかったので今回は Mock サーバーで代用します
    • なので Azure AD (認証認可サーバー) から トークンを受け取っていい感じのリクエストがアプリ側に投げられているかまでを確認して終了となります
  • 画像部分のフローのイメージになります

事前準備

  • 事前準備として、Mockサーバーの用意とAzure ADの設定を済ませます
  • Mockサーバーは mockoon というツールを使用
    • 詳しい使い方はこちらのブログ参考にしてもらえればと思います
    • インストール後、下の画像の3ステップぽちぽちするだけで mock サーバ立ち上がりました。とても便利です。。。
    • 今回は http://localhost:3000/hoge の POST リクエストが来たら It Works と返すシンプルなものを用意しておきます
  • azure active directory リソースがなかったら作成しておきます(参考ドキュメント)
  • azure active deirectory の アプリの登録をします
    • アプリ名は任意、Redirect URI は後で設定するので空でOK
  • 登録したアプリを開いて設定をしていきます
    • Redirect URIhttp://localhost:3000/hoge に設定
      • azure ad がトークンを発行した後、どこにリダイレクトさせるかを設定する場所になります
    • アクセストークン、IDトークンをエンドポイントが発行するように設定
      • 画像の 3 のところです

設定&動作確認

  • 設定が完了したので、実際に画面から触ってみましょう
  • ドキュメントを参考に認証エンドポイントにアクセスする URI を以下のような形で組み立てます(参考ドキュメント)
    • tenant_idclient_id は先ほどの準備の時に登録したアプリのIDを使ってください
GET https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/authorize?
client_id={client_id}
&response_type=id_token
&response_mode=form_post
&scope=openid
&state=12345
&nonce=678910
  • ブラウザからURLを入力すると以下の画面に遷移します

  • これを承認すると無事 Mock サーバーからの応答を確認できました。フォームデータの中に IDトークンも含まれていることが確認できます。

おわりに

  • 一般的な認証フローと azure active directory 上の実装方法を紐づけて覚えられたので勉強になりました。最初の参考のところにもリンクしたのですが、OAuth & OIDC 入門編の動画がわかりやすくまとまっていてよかったです。多分認証系の技術をあまり触ったことない方もわかるようになっていてお勧めだなと思いました。
  • この内容を発展させて受け取ったトークンサーバー側でバリデートする実装とかもしてみたいなと思いました。余裕があったらやりたいです、いつか。。。

Azure Load Testing を触ってみた

はじめに

少し前に azure load test が GA されました。azureメインかつ、最近負荷テストを触る機会も多い自分にとっては、かなり喜ばしいニュースです。 気づいた点をメモしていきます。一回触ってみた段階での感想なので正確じゃない箇所もあるかも。

料金

まずは気になる価格を一回調べます

  • ロードテストリソース: 10$
    • ロードテストを実施する基盤となる azure のリソースの値段。
    • 50時間分の仮想ユーザー時間が含まれる
      • テスト時間30分×100ユーザーのシナリオ一回分とか
  • 仮想ユーザー時間 (VUH) の追加使用量
    • 上記の 50時間分の仮想ユーザー時間を使い切るとこっちがかかる
    • 0~9950時間: 0.15$
    • 9951~時間: 0.075$

細かく計算するなら、料金計算ツールが便利。 得られるメリットも含めて考えると個人的には妥当な金額かなと思います。自前のVMやコンテナ上でロードテストをする場合は、それなりの性能のものが必要になったりするので。。

概要

実際に触ってみる

  • 今回は実務で使えそうな、Jmeterスクリプトを使用するテストを使ってみます
  • テスト計画でシナリオをアップロードする
  • 読み込みタブからエンジンインスタンス数を調整する
    • エンジンインスタンスというものがあるようで、1 エンジンインスタンスにつき 250スレッド(多重数) 目安で抑えることが推奨されているようです
    • 2 エンジンインスタンス が上限になっているので 500スレッドくらいまでしかテストできず大体のケースで足りなさそうです
      • この制限を引き上げるにはSRを投げる必要があるとの記載があります
  • テスト抽出条件タブからテストが 成功 or 失敗 する条件を定義する
    • 応答時間, 1秒当たりの要求数, 要求, 待機時間, エラーが条件として指定できる
    • 現状国外リージョンにしかリソース作成できないので、応答時間とかはリージョンによる結果への影響がないか気になる ]
  • 監視タブからテスト中などにメトリックを監視したazureリソースの指定ができる
    • ここで指定すると、テスト中や後で結果を見返すときにダッシュボードまとまってくれるので見やすくなる

よい点

  • 負荷基盤のメンテナンスが不要になる
    • 負荷をかけるための基盤をつくる時間や工数を短縮できる
    • VMのパッチをあてたり、ログが増えてきたらローテートとか必要だったけど、その作業がマネージドされていてテスト部分にのみに集中できる
    • 規模によるが、VMを何台も待機させるような構成よりは価格も抑えられそう
  • テストごとのダッシュボードが簡単に作られる
    • VMやコンテナからCLIベースでテストしていると、直感的に結果を把握しずらい。まとめるためにあそこみてここみてってやってたのが集約されるのはうれしい。
  • CI/CID との統合するが簡単にできる(参考)
    • 各スプリントの最後に Staging 環境のリリース対象にロードテストするユースケースとか。
    • 使いこなせると品質があがりそうですね、やってみたい。
  • Jmeter を使っている人なら使用感が同じ。
    • 普段 Jmeter でテストを実施している人ならそのまま jmx ファイルをアップロードできる、移行の工数ほぼない。

注意する点

以下のあたりは少し注意が必要かなと感じました。

  • Jmeterの知識はある程度必須
    • 負荷テストの実行基盤だけをマネージしてくれる感じなので、シナリオを作成するまでの知識は必須になる
    • テスト結果画面のエラーとかは java 形式なので、トラシューに java 知識いるかも
  • プレビュー段階で、日本リージョンではリソース作成ができない
    • 国外からのテストになるのでパフォーマンスの計測結果に影響でないか気になる。特にクライアント側のメトリック。
  • jtl のログはダウンロードできるものの、おそらく詳細情報まで含めたログまではとれなさそう
    • csv 形式のダウンロードはできる。xml 形式のものはできなさそう。。。
    • エラーが出ているときの調査が少しつまりそう

まとめ

マネージドなサービスならではのうまみもあって今後使ってみたいサービスだと感じました。まだプレビュー段階なのでこれからのアップデートにも期待したいと思います。 今回はチュートリアル用のシナリオだったのですが、もう少し複雑なシナリオ等を動かして使用感をみてみたいです。特にファイルをアップロードしたりGroovyでの独自のロジックなんかを含むシナリオのときの結果の出方なんかを見てみたい気持ちがあります。

Kubernetis メモ

Kubernetis 勉強会メモ

2023/02/23

  • 構成要素

  • ノード

    • application を実行しているマシン
      • 物理サーバーやマシン
    • 種類は以下二種
      • ワーカーノード
        • この中にコンテナがある
      • マスターノード
        • ワーカーノードを管理する役割
  • クラスタ

    • マスターノードとワーカーノードを束ねているもの
    • 高可用性と負荷分散を実現するための構成
    • 高可用性
      • コンテナが壊れたら自動で再起動させたりする
    • 負荷分散
      • 特定ノードに処理が集中しないようにノード間で負荷分散する
  • コンポーネント

    • ノードの配下でははたらく特定の役割をするものくらいの認識(?)
      • etcd とか kubuapiserver が代表例
  • マスターノード

    • クラスタ内の ワーカーノード と Pod を管理する
    • マスターコンポーネント(マスタノードの中にあるコンポーネント)には以下のようなものがある。詳細は後述。
      • kube-apiserver
      • etcd
      • scheduler
      • Controller Manager
      • Cloud Controller Manager
    • それぞれのコンポーネントを別々のノードで起動させることもできる。
      • ただ可用性の観点からは少なくともメインのマスターコンポーネントは1個にまとめるのがベストプラクティス
    • kube-apiserver
      • クラスタ内のすべての操作の窓口になるマスターコンポネント。API機能のフロントエンド部分。
      • セキュリティの観点から外部からAPI呼べて大丈夫?
        • apiserverを経由する際に、認証認可の役割も備えている
        • かつ入力制御(?)の役割も担う
          • 具体例は?
        • 以上の認証認可、入力制御を突破しないと操作はできないのでOK
    • etcd
    • scheduler
      • Podの配置決めを行うコンポーネント
      • どのPodをどのノードに配置するか決める部分のみを担当する
        * 実際のPod作成はこいつがするわけではない
        
      • 配置の決め方の例 -> 1つのPodに3つのノードを配置するとすると...
        • 配置方法は以下2種類
          • フィルタリング
            • そもそも要件を満たさないノードを除外する
            • 例: 4CPU のノードに 5CPUのPodを配置しようする
          • スコアリング
            • Podをノードに配置した時の残るリソース量が大きいものを優先する評価方式
    • Controller Manager
      • コンポーネントの状態を監視し、必要な対応を実行する
      • 例: ノードコントローラー *
      • 監視制御を全部まとめて管理するためのもの
    • Cloud Controller Manager
  • ワーカーノード
    • 実際に Pod を動作させるためのノード
    • Pod と ノードコンポーネントで構成される
    • ノードコンポーネント
      • kubelet, kube proxy など
    • kubelet
      • エージェントの役割をもつコンポーネント.Podの起動や管理を担う
        • 例:
          • ワーカノード自体の監視
          • ワーカノード内のPodの監視
          • コンテナランタイムの操作
        • ワーカーノード内部のリソースの監視や操作の窓口的な役割(?)
        • apiserver から指示をうけとって、結果のレポートを apiserver に返しているっぽい
    • kube proxy
      • ネットワーキングと負荷分散をサポートするコンポーネント
      • 内部的には iptables (Linuxの機能でファイやウォールやNAT機能をもっているもの)
    • コンテナランタイム
      • ワーカーノードでコンテナのイメージ取得から実行を行うもの
      • 2層に別れる
        • 高レベルランタイム
          • コンテナのイメージを取得し実行するコンテナ環境の設定をファイルの作成を行う
          • kubelet から呼び出される
        • 低レベルランタイム
          • 設定ファイルをもとに、コンテナ環境の作成
      • 様々な種類のソフトウェアがあり、それぞれ特徴がある
  • Ingress
    • クラスタ外部からクラスタ内に通信するためのURLを提供し、Serviceにロードバランシングするオブジェクト
      • 負荷分散, SSL/TLSの終端になる機能
    • 外部通信を制御する Ingress のおかげで外部クライアントは内部のことを気にせず、単一のURLをつかってサービスを利用できる
    • どこに配置されるものなのかはよくわからん。。。要調査
  • Manifest
    • リソース構成やコンテナイメージを yaml で形式で記述する
    • IaC を実際書く部分
  • Kubernetes の中で働くリソース

    • 特徴ごとに分類...
      • コンピュート
      • ストレージ
      • ネットワーク
      • アクセス制御
      • Pod設定
      • クラスタ設定
  • ラベルとセレクタ

    • リソース数が増えれば増えるほど管理が大変になるのでそれを補助する機能がある
    • ラベル
      • Podなどのリソースをグループ化する
    • セレクタ
      • グループ化された特定のリソースを使用する際に指定
  • Namespace

    • リソースを分離.独立しお互いの干渉を防ぐための linuxカーネル機能
    • 複数のワーカーノードを横断して kubernetes リソースの分離と独立が制御できる
    • デフォルトで以下3つの Namesapce が作成されている
      • defaut:
      • kubu-system:
      • kube-public:
    • 特に kubu-system は重要
  • Pod

    • kubernetes は各ノードに直接コンテナを起動するのではなく、Podという単位でコンテナを実行していく
    • 使い方の注意点
      • 1Pod1コンテナ 構成が一般的
      • ただ同一のボリュームをコンテナ間で共有したい場合は 1Podの中に複数のコンテナを起動させる
  • Replica Set

    • ノードやPodに障害が発生しても、Podをほかのノードに自動で配置しなおすことができる
      • セルフヒーリングという
    • セルフヒーリングの機能の一つ
    • 指定したPod数になっているかを監視する役割(?) 現状だとこれくらいの機能に見える
    • 後から指定したPod数の変更ができる
  • Deployment

    • Replica Set を管理して ローリングアップデートやロールバックを実現する
    • ちなみに管理している階層構造を整理すると
      • Depoyment が ReplicaSet を管理
      • ReplicaSet が Pod を管理
    • ローリングアップデート時に新しいレプリカセットも作成している
      • old用とnew用のレプリカセットを作って徐々
  • Service

    • クラスタ内外からのPodあての通信を仮想IPアドレスで振り分けてくれる
    • Serviceディスカバリー機能
      • Podが再配置しても通信の振り分け先のPodを検索判別してくれる昨日
      • DNSで名前解決したりする。ほかにも種類はある
    • 要はロードバランサーでどのPodに振り分けてるか管理してくれる
      • 背後のPodが死んでもServiceが一回受けてくれることで、背後のPodが死んで(オートヒーリングで復活して)IPが変わったとしても通信が継続できる
    • ターゲットとなる Pod は Service で定義するラベルとセレクターにより決められる
  • PVとPVC
  • configMap
    • Podの実行時に必要な環境変数、ぽーど番号などの構成要素をConfigMapから分離して保守するためのリソース
    • 上記の各種設定ファイルを保存する

WSL2 を導入したり Windows Terminal の環境を整えたときのメモ

WSL2 の導入

  • 環境: Windows 11
  • Windows11 では以下コマンドを実行するだけで、必要な資材をもろもろインストールしてくれるみたい
wsl --install
  • 上記コマンドうってもヘルプ文が出るだけで、インストール始まった気配がない
# 使用可能なlinuxのディストリビューション名を一覧表示
wsl --list --online

# ディストリビューション名を明示的に指定してインストール
wsl --install -d <DistroName>

WSL2 に homebrew を導入

Windows Terminal を透過させる

Window Terminal をショートカットで最前面に持っていけるようにする

  • Window Terminal を透過させる作業をしたもののコピーとかをすると裏の画面に行ってしまう。。。いちいちマウス触るのも面倒なので効率化したい
  • Window Terminal をタスクバーに固定する
    • Windowsの検索画面でターミナルと検索して右クリック -> タスクバーにピン留め で固定できる
  • タスクバーに固定してあるアプリは Winキー + アプリ番号 で起動できるよう

JavaScriptの標準入力、標準出力

 paizaラーニングでjsの問題も解こうと思ったら、標準入力の取得方法がわからん!!

 ってなったので、とりあえず出てきたメソッドやらを公式ドキュメントからまとめ。

 

プログラミング歴2週間ちょっとのため、基礎的な概念かなり怪しいです。基本自分用に書いてますが、見る人もしいたらご注意ください...!

  

f:id:birds-dash:20200417193254p:plain

標準入力、出力のメモ

 

 'process.stdin'、'process.stdout'プロパティ

 stdinstdoutstanderd instanderd out で標準入出力の直訳

 'process.stdin'は標準入力をReadableストリームとして返すプロパティ

 'process.stdout'で標準出力をWritableストリームとして返すプロパティ

 

 'createInterface( )'メソッド

 readline.Interfaceクラスのインスタンスを作成するメソッド。

 作成と同時にオプションをいろいろ設定できるので、( )の中にオプションを書いてく

 今回はオプションとしてinputとoutputの設定をしてますね。

 イメージ的には設定がいろいろできるreadline版のnew演算子みたいな感じ(?)

 

 'close'イベント

 主にinputストリームから、'end'イベント受け取ったときに実行されるイベント

 inputが終わったらcloseイベントが発生するって感じっすね

 他にもイベント発生条件3つくらいあります。公式ドキュメント参考

 

 'line'イベント

 inputストリームが行末入力を受け取る度に発生するイベント

 下記の入力例だと、受け取った1行分の入力ストリームが、引数としてinputのところ

に代入される。

rl.on('line', (input) => {
  console.log(input)
});