2024-02-12

YAPC::Hiroshima 2024 にいってきました

yapcjapan.org

2月9, 10日に行われた YAPC::Hiroshima 2024 に行ってきました。

どのトークも面白く、行ってよかったなぁと思えるイベントでした。次回はプロポーザル出してスピーカー側になりたい...!

聞いたセッション

VISAカードの裏側と “手が掛かる” 決済システムの育て方

speakerdeck.com

クレジットカード（VISAカード）の裏側の仕組みについてとてもわかり易くまとめていたトークでした。最近自分も決済関連に携わってることもあり、とても面白かったです。

カードの裏側について知りたい！という方にぜひ。（ベストスピーカー賞で投票していたので、選ばれて何故か僕が嬉しかったです。おめでとうございます！）

awkでつくってわかる、Webアプリケーション

speakerdeck.com

awk はログ処理などによく使っているのですが、それでWebアプリケーションが作れるというのが信じられなくて聞きに行きました。実際に awk でブログサービスを作られていてそれが公開されていたのと、話しぶりがアツくてとてもよかったです。

関数型プログラミングと型システムのメンタルモデル

speakerdeck.com

自分は関数型プログラミングをガッツリ触ったことはないものの、TypeScript を書くときにmap, reduce など関数型っぽいメソッドを触ることはたまにあるくらいの経験値です。なので全部を理解できたとは思えないのですが、関数型というパラダイムをちゃんと学ぶことは今後に活きてきそうだなと思える素晴らしいトークでした。

新任エンジニアリングマネージャーのための「ぼうけんのしょ」

speakerdeck.com

自分はメンバーポジションで仕事をしていますが、EMの人が何を考えて働いているのかを理解することは大事だなと思いました。 22p で語られているように、マネージャ以外でもできることは多いと気づかせてもらったので、来週から実践していきたいです。

非同期な開発体制を支えるドキュメント文化

speakerdeck.com

明日から使える、という意味では一番良かったと思うトークでした。非同期で仕事を進めるためにドキュメントを書き、限られた時間はデモなど同期でしかできないことに使うというのはたしかになぁと思わされました。「ドキュメントはフィードバックが深く/平等にできる」というのもドキュメントを書く大事な理由になるなと思いました。

ドキュメントを書くことに苦手感がありましたが、今後はどんどん書いていきたいです。

パネルセッション

櫛井優介（@941）さん、伊藤直也（@naoya_ito）さん、和田裕介（@yusukebe）さん、和田卓人（@t_wada）さん、馮富久（@tomihisa）さんのゲストトークが始まりました！

「平成のエンジニアから令和のエンジニアへの遺言〜技術情報を伝達する手段の変遷〜」#yapc_i #yapcjapan
— yapcjapan (@yapcjapan) 2024年2月10日

インターネットでよく見る方々が前で話していて、オフライン来た甲斐があったなぁと思ってみていました。

途中、オンライン登壇の時代が長くてオフライン資料作成のノウハウが失われているみたいな話はたしかにそうだなと思わされました。今後オフラインイベントも増えていくと思うので、オフラインで伝わる資料の作り方を気をつけていこうと思いました。

キーノート

「とほほの〇〇入門」の杜甫々さんのキーノートでした。自分が生まれる前からあるサイトの管理者、というところで実在を疑っていましたが、前でお話されている姿をみてなんだか感動しました。

この世のすべて入門じゃん #yapcjapan pic.twitter.com/X6wS7hqmAO
— 旭川から小平市をはじめ各地に飛び立つ地方ITコミュニティ盛り上げ大臣とみお (@tomio2480) 2024年2月10日

トークが終わったあと、「なぜこれだけアウトプットを続けられるのか？」という質問に対し、短く「好きだから」と答えていた姿が印象的でした。自分も好きでこの業界にいるので、もっとやれることはあるはず！とモチベーションが上がっています。貴重なお話ありがとうございました！

懇親会

前夜祭あと

同僚についていき、牡蠣にありつくことができました。また、色々な方とお話できたのも嬉しかったです。

会のあと

SecHack365 時代にお世話になった方々と久しぶりにお話できました。こうやって過去にお世話になった人と会えるのはオフラインならではでありがたいなぁと思っています。

新しい輪を広げるという点では、60点くらいかなとも思っています。コミュニティに新しく入る人として、登壇して認知を獲得するような動きを次回はできたらなと思います。オフラインイベント今後も参加したい！

2021-12-04

学校の友達とハッカソンにでて優勝した話（または地獄の話）

学校の友達とハッカソンにでてきた話

こんにちは。現役専攻科生のたかです。この記事は豊田高専 Advent Calendar 2021 の 5日目の記事です。

tl;dr

同級生とつながりをもっておくと卒業しても遊べる
ハッカソンに出るのは楽しい

ハックツハッカソン

本科の同級生と 9月に行われたハックツハッカソンスピノカップに参加していました。メンバーは ssssota とかんべぇでした。

彼らは高専の同級生で、本科を卒業しても一緒になにかできるのはやはりとても嬉しいです。

ハッカソンでは me-shi というWebサービスを開発しました。 me-shi では、ハッカソンでつくったプロダクトの説明だったり、ハッカソンに参加している別のチームの方とコミュニケーションを取ることができます。くわしくは topa'z - me-shi をどうぞ。

僕は基本的にバックエンドを開発していて、 AWS CDK + AWS AppSync で開発していました。 (もともと AppSync の話でアドベントカレンダー書こうと思ってたのですが、特に書くことないなって思っちゃって参加ログにしています)

TypeScript で IaC できるのは割と体験が良かったです。

アイディアなど、準備していった甲斐あってかスピノカップで優勝することができました。 Hack'z の方々、ありがとうございました。

#ハックツハッカソンスピノカップ
最優秀賞はチーム「閑古鳥」でした！
おめでとうございます！！
優勝商品のハックツカタログを受け取ってくれっチュ！

ハッカソンが終わった後もあと少しだけ繋がってみるアプリ、「me-shi」
Topa'zはこちらhttps://t.co/H28FjKCVgD pic.twitter.com/5QVSdFyEoc
— ハックちゅう＠株式会社ハックツ (@Hackz_team) 2021年9月23日

今回は割と実装に難航して、徹夜に加えてギリギリまで(sssota先生が)手を動かしていました。まだまだ改善点はあるものの、やっぱりハッカソンは楽しいなと思っています。またぜひ参加したいです！

九州旅行

ハッカソンのあと、別府温泉に一泊しました。（今思えば、ハッカソンで優勝できたから和気あいあいと楽しく旅行ができたものの、勝てなかったらどんな気持ちだったかとおもうとゾッとします）

地獄

地獄に落ちた pic.twitter.com/qugwRFLinF
— たか (@onsd_) 2021年9月23日

世にも珍しい解体中の地獄

解体中の地獄 pic.twitter.com/9tFC8QXHev
— たか (@onsd_) 2021年9月23日

地獄蒸し美味しかったのでおすすめです

地獄蒸しなど pic.twitter.com/F5KHVtIzby
— たか (@onsd_) 2021年9月23日

宣伝

ハックツハッカソンは宿泊施設で行われることがおおく、参加者は無料で宿泊することができました。これは、愛知県から遊びに行った身としてはとてもありがたかったです。 RedBullも飲めるので、興味ある方はぜひ遊びに行ってみてほしいです！！

おまけ

AWS CDK をつかって AppSync を構築するときに、OIDC 認証を使う例

const appsync = new GraphqlApi(this, 'appsync', {
      name: "some-appsync-name",
      schema: Schema.fromAsset(
        path.join(__dirname, 'schema.graphql')
      ),
      logConfig: {
        excludeVerboseContent: true,
        fieldLogLevel: FieldLogLevel.ALL,
      },
      authorizationConfig: {
        defaultAuthorization: {
          authorizationType: AuthorizationType.OIDC,
          openIdConnectConfig: {
            tokenExpiryFromAuth: 0,
            tokenExpiryFromIssue: 0,
            clientId: process.env.OIDC_CLIENTID || '',
            oidcProvider: process.env.OIDC_PROVIDER || '',
          },
        }
      }
    })

authorizationConfig がミソっぽいです

2020-12-31

2020年振り返りと来年の目標

みんな2020年を振り返っているので振り返ってみる

1月

SecHackの沖縄回(発表会)に向けて頑張っていた
- ぼったくりも Trinity もやってて楽しかった
- 優秀修了生に選ばれて嬉しかった

2月

定期試験
- 無事卒業できた
北海道にスキー旅行に行った
Pixiv でインターンをさせてもらった

3月

Optimind でインターンをさせてもらっていた
プレミアム逆求人に参加した
- インターンの話がメインだった気がする

4月

危機管理コンテスト 1次予選
- 今年はオンラインだったので3日かけてレポートを練っていた
- なんとか突破できて一安心

5月

危機管理コンテスト 2次予選
- 去年の反省を生かしていろいろ準備を練った
- 去年は一問しか解けなかったとこからするとだいぶ成長した
インターンの面接をだいぶやっていたと思う

6月, 7月

とくにイベントはなかった
リモートで働かせてもらっていた

8月

インターン
- Wantedly
  - infra squad で3週間 Kubernetes 関連のタスクをやっていた
  - cluster の backup などの方法を学んだ
- DeNA
  - ~クソアプリ~ 伸びしろのあるアプリを改善するハッカソンに参加していた
  - リモートでどう仲良くなるか、というのがとても難しいことを実感した

9月

定期試験
- コロナで日程がずれたせいで変則的な日程になってしまっていた
インターン
- Wantedly の DX squad でインターンをしていた
SecHack365 成果発表会で発表した
- 動画をスタジオで撮影した
  - んですが、LTとかと違って動画撮影はとても難しいと感じた
  - テレビに出てる人だったりYoutuberはすごい

10月

SPAJAM
- 花言葉のアプリを作って優秀賞だった
- 高専時代の友達と久しぶりに遊べてとても楽しかった
ICTSC2020
- 危機管理コンテストに引き続き siketyan を召喚した
- ギリギリ本戦にでれるみたいなので本戦はもっとがんばります

11月

Hardening H3DX に Hardening 初参加ながら参戦した
- 事前準備の貢献度はゼロだったので次はがんばりたい

12月

ハックツハッカソンプレシオ杯に出ていた
- kubesmas-tree

プライベート

北海道スキー旅行に行った
キャンプ行った
濁河温泉　朝日荘に行った
白馬にスキー旅行に行った

今年はいろいろやっていたつもりだったけど、振り返ってみるとそうでもなさそうイベントの参加記を残しておかなかったことを後悔しています

来年の目標

イベントに出たらブログを書く
登壇する・技術記事を書く
プライベートを充実させる

2021年もよろしくおねがいします！

2020-06-09

Workload Identity を使ってGKEからAWSへセキュアにアクセスを行う

Workload Identityを用いてGKEからAWSのリソースにアクセスする

この記事で使用する手順は主に dotintl/gtoken に沿っています

Workload Identity とは

Workload Identity GKEアプリケーションが　Google API 提供のサービスを使用するための推奨された方法です

GoogleサービスアカウントのメールアドレスがAnnotateされたKubernetesサービスアカウントを用いることで、サービスアカウントを使用してクラウドサービスへの認証を行うことができます

AWSにも似たような機能があります

今回は、Workload Identityを用いてAWSのサービスに対し認証情報を持たずにセキュアにアクセスを行う方法を紹介します。

アプローチ

AWS IAM Role を GKEのPodに割り当てる

AWS
- OIDC IDプロバイダーのIAMロールを作成する
- GoogleのサービスアカウントでAssumeRoleできるようにする
Google
- サービスアカウントを作成する
- Workload Identityを通じてPodに有効なOIDCトークンを付与する
- OIDCトークンを用いてAWSに作成したIAMロールにAssumeRoleする

AWS SDKは、次の環境変数が設定されている場合、STSサービスから一時的なAWS認証情報をリクエストします

AWS_WEB_IDENTITY_TOKEN_FILE
- OIDCトークンへのパス
AWS_ROLE_ARN
- 引き受ける役割のARN
AWS_ROLE_SESSION_NAME
- このセッションの名前

OSSであるdointl/gtoken を用いることで簡単にセットアップができます

gtoken

gtokenとは、OIDC ID tokenの期限が切れる前に更新する役割をもつコンテナ

有効な GCP OIDC ID tokenを生成
必要なAWSの環境変数を自動で挿入

`gtoken-webhook` のデプロイ

gtoken-webhook とは

特定のAnnotationがついたサービスアカウントで実行されるPodに対して、gtokenをinjectするサービスです

デプロイには、Webhookサービスとデプロイメントを作成する必要があります。

また、gtokenのデプロイには通常のサービスと違い、証明書を作成する必要があります。

git clone https://github.com/doitintl/gtoken

./deployment/webhook-create-signed-cert.sh

証明書の作成が完了したら、デプロイメントとサービスを作成します。

kubectl apply -f deployment/deployment.yaml

kubectl apply -f deployment/service.yaml

次にMutatingWebhookConfiguration をApplyします。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: mutating-gtoken-webhook-cfg
  labels:
    app: gtoken-webhook
webhooks:
  - name: gtoken.doit-intl.com
    clientConfig:
      service:
        name: gtoken-webhook-svc
        namespace: default
        path: "/pods"
      caBundle: ${CA_BUNDLE}
    rules:
      - operations: [ "CREATE" ]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["pods"]

ここで、${CA_BUNDLE} を適切に設定する必要があります。 CAを置き換えるスクリプトが同梱されているので、それを使います。

cat ./deployment/mutatingwebhook.yaml | ./deployment/webhook-patch-ca-bundle.sh > ./deployment/mutatingwebhook-bundle.yaml

kubectl apply -f deployment/mutatingwebhook-bundle.yaml

gtoken-webhook の RBACを構成する

gtoken-webhookが使用するサービスアカウントと、その権限を作成します。

# create a service account
kubectl create -f deployment/service-account.yaml

# create a cluster role
kubectl create -f deployment/clusterrole.yaml
# create a cluster role binding
kubectl create -f deployment/clusterrolebinding.yaml

GKE Workload Identity の設定

以下の設定で、いくつかの環境変数を使います。 .envrc などで定義しておくと便利です。

PROJECT_ID
- GCP の project ID
CLUSTER_NAME
- GKEのクラスタの名前
GSA_NAME
- Google Cloud のサービスアカウントの名前
KSA_NAME
- Kubernetes のサービスアカウントの名前
KSA_NAMESPACE
- Kubernetes の namespace名
AWS_ROLE_NAME
- AWSのIAM Role の名前
AWS_POLICY_NAME
- $AWS_ROLE_NAME に紐付けたいポリシーの名前
生成されるもの
- GSA_ID
  - gcloud iam service-accounts describe --format json $GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com | jq -r '.uniqueId' で取得可能
- AWS_ROLE_ARN
  - $AWS_ROLE_NAMEを　生成したときに割り当てられるARN
  - aws iam get-role --role-name $ROLE_NAME --query Role.Arn --output text で取得可能

Gcloud Workload Identity を有効にする

Workload Identity

ノードプールに--workload-metadata-from-node=GKE_METADATA_SERVERを付加すると、そのノードでWorkload Identity を使うことができます

新しいクラスタの場合

gcloud beta container clusters create ${CLUSTER_NAME} --identity-namespace=${PROJECT_ID}.svc.id.goog

既存のクラスタの場合

gcloud beta container clusters update ${CLUSTER_NAME} --identity-namespace=${PROJECT_ID}.svc.id.goog

この場合、既存のノードプールへの影響はなく、新しいノードプールでは--workload-metadata-from-node=GKE_METADATA_SERVER が有効になります。よって、Workload Identityを使用するにはノードプールを更新するか、新しく作成する必要があります。

# 既存のノードプールを更新する場合
gcloud beta container node-pools update ${NODEPOOL_NAME} \
  --cluster=${CLUSTER_NAME} \
  --workload-metadata-from-node=GKE_METADATA_SERVER
  
# 新しくノードプールを作成する場合
gcloud beta container node-pools create ${NODEPOOL_NAME} \
  --cluster=${CLUSTER_NAME} \
  --workload-metadata-from-node=GKE_METADATA_SERVER

Google Cloud Service Account を作成する

gcloud iam service-accounts create ${GSA_NAME}

GSA_ID=$(gcloud iam service-accounts describe --format json ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com  | jq -r '.uniqueId')

GSA_NAME に以下の役割を与えます。 - roles/iam.workloadIdentityUser - GKE ワークロードのサービスアカウントを使用するため -roles/iam.serviceAccountTokenCreator` - サービスアカウント権限を使用するため

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.serviceAccountTokenCreator \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${KSA_NAME}]" \
  ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com
  
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[${K8S_NAMESPACE}/${KSA_NAME}]" \
  ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

参考にしたブログでは一行になってましたが、やったらできなかったので２つに分けてます

Google OIDC フェデレーション用のAWS IAM Roleを作成する

Google OIDC フェデレーション用のAWS IAM Roleを作成するためのトラストポリシーを作成しておきます。

cat > gcp-trust-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:sub": "${GSA_ID}"
        }
      }
    }
  ]
}
EOF

AWS IAM Roleを作成します

# assume-role-policy-documentでさっきのファイルを指定する
aws iam create-role --role-name ${AWS_ROLE_NAME} --assume-role-policy-document file://gcp-trust-policy.json

# policy を割り当てる
aws iam attach-role-policy --role-name ${AWS_ROLE_NAME} --policy-arn arn:aws:iam::aws:policy/${AWS_POLICY_NAME}

Kubernetes サービスアカウントのアノテーションに使用するため、ARNを取得しておきます

AWS_ROLE_ARN=$(aws iam get-role --role-name ${ROLE_NAME} --query Role.Arn --output text)

Kubernetes サービスアカウントの作成

Kubernetes namespace とサービスアカウントを作成します

# Kubernetes namespace の作成
kubectl create namespace ${K8S_NAMESPACE}

# Kubernetes service account の作成
kubectl create serviceaccount --namespace ${K8S_NAMESPACE} ${KSA_NAME}

# service account に GKE Workload Identity(GCP ServiceAccountのメールアドレス) を annotate
kubectl annotate serviceaccount --namespace ${K8S_NAMESPACE} ${KSA_NAME} \
  iam.gke.io/gcp-service-account=${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

# service account に AWS Role ARN を annotate

kubectl annotate serviceaccount --namespace ${K8S_NAMESPACE} ${KSA_NAME} \
amazonaws.com/role-arn=${AWS_ROLE_ARN}

試す

GKE Workload Identity

kubectl run --rm -it \
  --generator=run-pod/v1 \
  --image google/cloud-sdk:slim \
  --serviceaccount $KSA_NAME \
  --namespace $K8S_NAMESPACE \
  workload-identity-test

root@workload-identity-test:/ gcloud auth list
                       Credentialed Accounts
ACTIVE  ACCOUNT
*       test-service-account@$PROJECT_ID.iam.gserviceaccount.com

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

正しく設定できていた場合、Googleサービスアカウントのメールアドレスのみが表示されるはずです。

クリーンアップ

# remove aws iam role
aws iam detach-role-policy --role-name $AWS_ROLE_NAME --policy-arn arn:aws:iam::aws:policy/$AWS_POLICY_NAME

aws iam delete-role --role-name $AWS_ROLE_NAME

# remove k8s sa, namespace
kubectl delete sa -n $K8S_NAMESPACE  $KSA_NAME

kubectl delete namespace $K8S_NAMESPACE

#remove Google Cloud IAM 
gcloud iam service-accounts remove-iam-policy-binding \
     --role roles/iam.serviceAccountTokenCreator \
    --member "serviceAccount:$PROJECT_ID.svc.id.goog[$K8S_NAMESPACE/$KSA_NAME]" \
      ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

gcloud iam service-accounts remove-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$PROJECT_ID.svc.id.goog[$K8S_NAMESPACE/$KSA_NAME]" \
      ${GSA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

gcloud iam service-accounts delete $GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com

# disable workload identity
# update node
gcloud beta container node-pools update $K8S_NODEPOOL --cluster=$K8S_CLUSTER   --workload-metadata-from-node=EXPOSED

# disable workload identity
gcloud beta container clusters update $CLUSTER_NAME  --disable-workload-identity

# delete resources
kubectl delete -f deployment/

おわりに

この記事は3月に株式会社オプティマインドで検証した記録です。

2020-03-24

pixivで圧倒的な猛者に入門した

この春、ピクシブ株式会社のPIXIV SPRING BOOT CAMP 2020に参加してきました。

募集概要

recruit.jobcan.jp

ピクシブのインフラ部ではオンプレ・クラウド合わせて200ホスト以上をDatadogを用いてモニタリングしています。

今回のインターンでは、そのDatadogを用いてグラフや監視を作成すると共に、プロダクション環境のデータを見て分析を行ってもらうことで、実際の業務を体験することができます。また、インフラをTerraformで宣言的に管理する方法を学び、既存システムのTerraformでの再構築に挑戦してもらうことで、実際の業務のなかでのInfrastructure as Codeを体験することができます。【使用技術】 Terraform、Datadog、Linux、AWS、Gitlab CI 上記いずれかの経験があれば好ましいが、必須ではありません。

バイト先でDatadogは使っているのですが、200ホストというのは桁違いですし、実際に世界中からものすごい数のアクセスが飛んでくるサイトのインフラはどうなっているのだろう？というのが気になって今回は応募させていただきました。

ちなみに、選考ではGitHub選考と通常選考が選べます。

僕はGitHubではPublic なリポジトリでの活動が少ないのと、やってきたことを面接で伝えたほうがよいかなと思ったので通常選考にしました。

やったこと

パフォーマンスチューニング

BOOTH とpixivコミックの改善点を探して、対策を考えるというタスクをやりました。特にBOOTHはユーザーとして商品を購入したこともあるのでとても楽しいタスクでした。また、メンターのwalf443さんにはほとんどつきっきりでコードが意味している点の説明や、なぜこうなったかの裏話をしてくださってとてもおもしろい話が聞けました。

今回は基本的に遅いクエリをどう正すかを考えていたのですが、なかなか見つけられず walf443さんにだいぶ助けてもらいました。このタスクをやるなかで、パフォーマンスチューニングの基礎を教えてもらいました。

次のISUCONや、自分の関わる開発で活かしていきたいと思います！

Terraformについてのテスト

DNSレコードの変更依頼について、現在のフローでは依頼が来たらインフラ部が変更する、というフローになっているところをTerraformを使ってPRベースにできないか？という課題をいただきました。この課題については、Terraformを用いてRoute53を操作することで依頼する側がPRを出すことで変更依頼を出せるような仕組みを考えました。また、その変更が正しいかどうかのチェックを行うようなスクリプトを書きました。

terraform plan には -out=PATH というオプションがあります。ここではplanの内容が格納されているzipファイルが生成されます。このファイルを用いてapplyすることもできるのですが、terraform show -jsonというコマンドを使うことで変更の内容をjsonで出力させる事ができます。出力したJSONを使って変更先のIPアドレスが実際に疎通できる環境かテストしたりするようにしました。

DatadogのDashboard作り

既存サービスの監視に使うDashboardを作成しました。

既存のDashboardを見せていただき、自分でもわかりやすいDashboardを作って監視の負荷を下げたいと思いました。

物理マシンのキッティング

旧社屋にある検証用のサーバのメモリ増設をさせてもらいました！ f:id:onsd:20200324094119p:plain

感想

今回のインターンで、基本的な負荷分散やキャッシングをしっかりやることが大量のリクエストをさばくための秘訣であり、地道にやっていくべきことだと学びました。また、AWSやGCPのようなパブリッククラウドにふれる機会がとても多くなっているなか、オンプレのインフラに触れることができたのはとても貴重な経験だと思いました。楽しい二週間でした。本当にありがとうございました！

2019-12-13

U16プロコン愛知大会の開催記録

この記事は、第二弾地方IT勉強会 Advent Calendar 2019の7日目の記事です。

ラッキーセブンを頂いたのにも関わらず大遅刻をかまして申し訳ないです。。。

自己紹介

豊田高専の学生です。先生からお話をいただき、U16プロコンの主催の一員として活動させていただくことになりました。

U16プロコンとは？

もともと北海道の旭川で行われていたコンテストです。

課題部門・作品部門に別れており、参加者はそれぞれ作品を持ち寄り対戦したり展示を行います。

愛知大会

f:id:onsd:20191213205603p:plain https://u16aichiprocon.connpass.com/event/137745/

愛知大会は豊田高専で行われ、作品部門のみ開催しました。

これは、初回ということで参加者数が読めないことや、運営のノウハウが足りないことに起因しています。。。

大会は8/24に行われました。

また、それに先立ち開発支援日として学生が開発のお手伝いをする日を設けました。

大会の様子

当日は想定を超える10人が参加してくださり、とても良い雰囲気で進行することができました。

当日は小学生の子が優勝し、来年行われる全国大会に出場する権利を得ることができました！

主催した感想

今回U16プロコンを愛知で初開催して、参加してくれる方がいたのは開発支援日をやったのが大きいと思っています。開発支援日では、IchigoJamの使い方を教えたり開発のお手伝いをしたりしていました。

小さいメモリにいくつものゲームをつくってみる方がいたり、できることを探して作る姿勢がすごいいいなぁと思っていました。

おわりに

大会の開催は初めてのことで、とても不安でしたが何事もなく終了できてよかったです。主催側の大変さを学ぶことができ、とても有意義でした。

また、開催にあたってそもそものお話を頂いたITジュニア育成交流協会様、当日来ていただいた@tomio2480先生、参加してくれた方、尽力してくださった先生、本当にありがとうございました。

また機会があればこういった運営に携わりたいです。

2019-12-04

Now でやってみるWebサーバーのつくりかた

はじめに

この記事は以前行われた部内LT会(#ToyoTech_LT)でやったLTを記事にしたものです。

また、この記事は豊田高専コンピュータ部アドベントカレンダー 5日目の記事です

Now とは

手軽にWebサーバのデプロイが行えるPaaSです。

なんと、now とコマンドを打つだけでデプロイすることができます:tada:

よいところ

now だけで deploy できる
HTTP, HTTPS 接続ができるURLが割り当てられる
設定すればURLを固定することができる

やりかた

今回使用するファイル

now-express/
├── index.js
├── now.json
├── package-lock.json
└── package.json

index.js

const express = require("express");
const app = express();

const port = 8080;

// Listen
app.listen(port, () => {
  console.log(`Server is running on port ${port}
Visit http://localhost:${port}`);
});

app.get("/", (req, res) => {
  res.send("Hello, World!\n");
});

package.json

{
  "name": "now-express",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.17.1"
  }
}

now.json

{
  "version": 2,
  "builds": [{ "src": "index.js", "use": "@now/node-server" }],
  "routes": [
    { "src": "(.*)", "dest": "/index.js", "methods": ["GET", "POST"] }
  ]
}

動作確認

$ node index.js
Server is running on port 8080
Visit http://localhost:8080

$ curl localhost:8080
Hello, World!

/にアクセスすると、Hello, World!が帰ってくるだけのシンプルなWebサーバーです。

これを世界に公開してみます！！！

now

npm を使ってインストールします。yarn派の方はそちらでOKです

$ npm install -g now

とりあえずnowとうつと、ログインを求められるのでログインしましょう。

$ now 
> Error! The content of "~/Library/Application Support/now/auth.json" is invalid. No `token` property found inside. Run `now login` to authorize.
$ now login
> We sent an email to {{ EMAIL }}. Please follow the steps provided
  inside it and make sure the security code matches {{ SECURITY CODE }}.
✔ Email confirmed
> Congratulations! You are now logged in. In order to deploy something, run `now`.

ログインすると、メールアドレスを入力することでリンク付きのメールが送られてきます。そのリンクを踏むだけでログインができます:tada:

デプロイ

デプロイしてみましょう。

$ now
Deploying ~/Workspace/tmp/now-express under onsd
Using project now-express
Synced 1 file 
https://now-express-n8cu7hfu1.now.sh
Ready! Deployed to https://now-express.onsd.now.sh

https://now-express.onsd.now.sh にデプロイされました:tada: このように、とても簡単にデプロイすることができます。

ちょっとつまずく点

デプロイには、now.jsonが必要です。 now.json

{
  "version": 2,
  "builds": [{ "src": "index.js", "use": "@now/node-server" }],
  "routes": [
    { "src": "(.*)", "dest": "/index.js", "methods": ["GET", "POST"] }
  ]
}

一つづつ説明します。

builds
- src
  - ソースコードのエントリーポイントを指定します。
- use
  - 使用するビルダーを指定します。
    - nodejsの場合は@now/node-server
    - goの場合は@now/go
      - etc...
routes
- src
  - エンドポイントを指定します
    - (.*) は、すべてのアクセスをdestに送ります。
- dest
  - アクセスを受けるファイルを指定します
- methods
  - 受け付けるメソッドを定義します。
    - ["GET", "POST"]の場合PUTなどは拒否します。

builds.use, routes.src, routes.destはご自分の環境に合わせて設定してください。

おわりに

Nuxt.js, Create-react-app, Vue.jsなどのフレームワークはNow向けに最適化されており、nowだけでデプロイすることができるみたいです！また、GitHub Integration も用意されており継続的デリバリーを簡単に実現することもできます。

そんなに大きくないプロジェクトでも、導入する価値はあるプロダクトです。是非試してみてください！

聞いたセッション

関数型プログラミングと型システムのメンタルモデル

パネルセッション

キーノート

懇親会

前夜祭あと

会のあと

学校の友達とハッカソンにでてきた話

tl;dr

ハックツハッカソン

九州旅行

宣伝

おまけ

1月

2月

3月

4月

5月

6月, 7月

8月

9月

10月

11月

12月

プライベート

来年の目標

Workload Identityを用いてGKEからAWSのリソースにアクセスする

Workload Identity とは

アプローチ

gtoken

gtoken-webhook のデプロイ

gtoken-webhook とは

gtoken-webhook の RBACを構成する

GKE Workload Identity の設定

Gcloud Workload Identity を 有効にする

新しいクラスタの場合

既存のクラスタの場合

Google Cloud Service Account を作成する

Google OIDC フェデレーション用のAWS IAM Roleを作成する

Kubernetes サービスアカウントの作成

試す

GKE Workload Identity

クリーンアップ

おわりに

募集概要

やったこと

パフォーマンスチューニング

Terraformについてのテスト

DatadogのDashboard作り

物理マシンのキッティング

感想

U16プロコン愛知大会の開催記録

自己紹介

U16プロコンとは？

愛知大会

大会の様子

主催した感想

おわりに

Now でやってみるWebサーバーのつくりかた

はじめに

Now とは

よいところ

やりかた

今回使用するファイル

動作確認

now

デプロイ

ちょっとつまずく点

おわりに

`gtoken-webhook` のデプロイ

Gcloud Workload Identity を有効にする