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

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

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

パネルセッション

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

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

キーノート

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

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

懇親会

前夜祭あと

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

牡蠣のガンガン焼き

会のあと

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

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

府中焼き
厳島神社大鳥居

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

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

こんにちは。現役専攻科生の たか です。 この記事は 豊田高専 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 の方々、ありがとうございました。

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

九州旅行

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

地獄

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

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

宣伝

ハックツハッカソンは宿泊施設で行われることがおおく、参加者は無料で宿泊することができました。 これは、愛知県から遊びに行った身としてはとてもありがたかったです。 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年振り返りと来年の目標

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

1月

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

2月

3月

4月

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

5月

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

6月, 7月

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

8月

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

9月

10月

  • SPAJAM

    • 花言葉のアプリを作って優秀賞だった
    • 高専時代の友達と久しぶりに遊べてとても楽しかった
  • ICTSC2020

    • 危機管理コンテストに引き続き siketyan を召喚した
    • ギリギリ本戦にでれるみたいなので本戦はもっとがんばります

11月

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

12月

プライベート

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

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

来年の目標

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

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

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
  • AWS_ROLE_ARN
    • 引き受ける役割のARN
  • AWS_ROLE_SESSION_NAME
    • このセッションの名前

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

gtoken

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

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
  • GSA_NAME
    • Google Cloud の サービスアカウントの名前
  • KSA_NAME
    • Kubernetes のサービスアカウントの名前
  • KSA_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

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

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サービスアカウントのメールアドレスのみが表示されるはずです。

AWS

kubectl run -it --rm --generator=run-pod/v1 --image mikesir87/aws-cli --serviceaccount ${KSA_NAME} test-pod -n {$K8S_NAMESPACE}

If you don't see a command prompt, try pressing enter.
root@test-pod:/aws#
root@test-pod:/aws# aws sts get-caller-identity
{
    "UserId": "XXXXX:gtoken-webhook-vqbhasptyassltln",
    "Account": "XXXXXXXX",
    "Arn": "arn:aws:sts::XXXXXXX:assumed-role/test-gcp-service-account/gtoken-webhook-vqbhasptyassltln"
}
root@test-pod:/aws# exit

指定したARNが表示されていたら成功です。

クリーンアップ

# 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月に株式会社オプティマインドで検証した記録です。

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

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

募集概要

recruit.jobcan.jp

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

今回のインターンでは、そのDatadogを用いてグラフや監視を作成すると共に、プロダクション環境のデータを見て分析を行ってもらうことで、実際の業務を体験することができます。 また、インフラをTerraformで宣言的に管理する方法を学び、既存システムのTerraformでの再構築に挑戦してもらうことで、実際の業務のなかでのInfrastructure as Codeを体験することができます。 【使用技術】 Terraform、Datadog、LinuxAWS、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

感想

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

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

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先生、参加してくれた方、尽力してくださった先生、本当にありがとうございました。

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

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

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 も用意されており継続的デリバリーを簡単に実現することもできます。

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