OAuth 2.0 サーバの実装・テストについてgolangtokyoで発表してきました | golang.tokyo#18 参加レポート
2018年9月28日（金）に開催されたgolang.tokyo #18に参加して、LT枠（10分）で発表してきました。
golang.tokyoとは
プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです トークイベント、ハンズオン、etcのイベントを開催していく予定です！
発表内容
今回は、APIを作成するに当たり面倒で避けられない「認証・認可」について、各種背景からモノリシックにリクエストハンドラーとして組み込む場合どう実装するかという発表でした。
フルスクラッチではなく、Red Hat OpenShiftがgithubに公開している、openshift/osinというOAuth2.0のサーバーライブラリを用いた実装・テストの例をまとめています。
LT応募方法
LT応募してみたいという方は、毎回のconnpassページ内で以下の感じでLT募集フォームがあると思うのでこちらで応募できます！
感想
約1年前からGo言語を趣味で触り始めてどこかでgolang.tokyoで発表してみたいと思っていたので、まだまだ精進が必要ですが一つ目標が達成できてよかったです。また、ネタを見つけて発表しに行きたいと思います。
TerraformでAWSのインフラ構成構築を自動化する(入門)
Terraformを用いてAWSのインフラ構成・構築を自動化するに当たり入門資料です。この記事では、Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版で構築する構成図をTerraformで構築していきます。
発表資料
Terraformとは
Terraformとは、HashiCorpが作っているコードからインフラリソースを作成・管理するためのツールです。
AWS, GCP, Azure, Heroku など多くのSaaSに幅広く対応しています。
今回作成するインフラ構成
Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版で構築する構成がベースになります。
具体的には、次のような構成要素が存在します。
- VPC
- CIDR:
10.1.0.0/16 - Internet gatewayがattachされている
- CIDR:
- public subnet
- CIDR:
10.1.1.0/24 - 外部InternetからのINBOUND接続が可能なsubnet
- CIDR:
- private subnet
- CIDR:
10.1.2.0/24 - 外部InternetからのINBOUND接続が遮断されたsubnet
- OUTBOUND接続は可能とするため、NAT Gatewayに対してRoutingが設定されている
- CIDR:
- EC2 instance: "web"
- subnet: public subnet
- private IP address:
10.1.1.10 - 外部Internetからの接続を受け付けるようなWebサーバーが想定される
- EC2 instance: "db"
- subnet: private subnet
- private IP address:
10.1.2.10 - 外部Internetからの接続を受け付けないDBサーバーが想定される
構築する
今回構築する際のサンプルコードは下記レポジトリにて公開しています。
準備
本資料を進めるに当たり、Terraformがinstallされている必要があるため公式リファレンスにそってインストールしておきましょう。
手順
- Asia/PacificにVPCを作成する
- public subnetを作成する
- Internet Gatewayを作成してpublic subnetのroute tableに設定する
- public subnetにEC2 instanceを作成する
- private subnetを作成しEC2 instanceを作成する
- NAT Gatewayを作成する
1. Asia/PacificにVPCを作成する
本章のコードは、GitHub - Khigashiguchi/terraform-basic-network at 0.1 にて公開しています。
Terraformでは、*.tf拡張子のファイルでインフラ構成について定義していきます。まずは、VPCを作成するところからです。main.tfというファイルを作ります。
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "ap-northeast-1"
}
まず、最初のproviderでは、どのSaaSを利用したインフラ構成について定義していくのかを書きます。ここが、Google Cloudであればgoogleと定義することになります。
Provider: Google Cloud - Terraform by HashiCorp
今回は、AWSを利用するため、awsをproviderに指定し、AWSのAPIに利用に必要なaccess_key・secret_key、そして対象regionを指定します。
ここでは、べた書きすることも可能なのですがgit管理外にアクセスキーを置きたいため、variablesという機能を用います。
別途、variable.tfというファイルを作成して次のように定義します。
variable "aws_access_key" {}
variable "aws_secret_key" {}
上記のを指定することで、main.tf内では"${var.aws_access_key}"といった形で使うことが出来ます。ここでvariableとした場合、実際にインフラ構築時のコマンドインターフェースにて値を入力するなどと行ったgit管理外の場所から注入することが可能になります。
この手順では、VPCを作成したいため先程定義したmain.tfに対して以下追記します。
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "ap-northeast-1"
}
// +以下追記
resource "aws_vpc" "main" {
cidr_block = "10.1.0.0/16"
tags {
Name = "VPC領域：Terraform"
}
}
実際に実行してみましょう。まず、terraform initというコマンドによって初期化します。
$ terraform init
その後、terraform applyというコマンドによって記述したインフラ構成を実際に構築することが出来ます。
$ terraform apply
var.aws_access_key / var.aws_secret_key
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
+ aws_vpc.main
id: <computed>
arn: <computed>
assign_generated_ipv6_cidr_block: "false"
cidr_block: "10.1.0.0/16"
default_network_acl_id: <computed>
default_route_table_id: <computed>
default_security_group_id: <computed>
dhcp_options_id: <computed>
enable_classiclink: <computed>
enable_classiclink_dns_support: <computed>
enable_dns_hostnames: <computed>
enable_dns_support: "true"
instance_tenancy: "default"
ipv6_association_id: <computed>
ipv6_cidr_block: <computed>
main_route_table_id: <computed>
tags.%: "1"
tags.Name: "VPC領域：Terraform"
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value:
コマンドを実行した後、Enter a valueと聞かれて一度止まるので、ここでyesと入力することで実際に動作します。
コマンド実行終了後、現状どうなっているかを確認するためには、terraform showというコマンドを実行することで確認することが出来ます。
$ terraform show
ここでは、確認できたので一度作成したVPCを削除してみます。削除するには、terraform destroyと実行することで構築したものを削除することが出来ます。
$ terraform destroy
次に、作成したVPC内でsubnetを切っていきます。
手順1の関連資料
- Terraform公式リファレンス：Configuration: Data Source Configuration
- Terraform公式リファレンス：Configuration: Resource Configuration
- Terraform公式リファレンス：Resource: AWS Provider
- Terraform公式リファレンス：Resource: aws_vpc
2. public subnetを作成する
本章のコードは、GitHub - Khigashiguchi/terraform-basic-network at 0.2 にて公開しています。
作成したVPC内にsubnetを切ります。手順1で作成したmain.tfに次の記述を追加することでsubnetを作成することが出来ます。
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "ap-northeast-1"
}
resource "aws_vpc" "main" {
cidr_block = "10.1.0.0/16"
tags {
Name = "VPC領域：Terraform"
}
}
// + 以下追記
resource "aws_subnet" "web" {
vpc_id = "${aws_vpc.main.id}"
cidr_block = "10.1.1.0/24"
tags {
Name = "Public Subnet by Terraform"
}
}
ここでは、CIDRが10.1.1.0/24であるsubnetをVPC内に作成しています。次に作成したsubnetに対してroute tableを作成していきます。
手順2の関連資料
3. Internet Gatewayを作成してpublic subnetのroute tableに設定する
本章のコードは、GitHub - Khigashiguchi/terraform-basic-network at 0.3 にて公開しています。
手順2で作成したsubnetのroute table・外部internetからの接続を受け付けるためのinternet gatewayを作成します。main.tfに次のように追記します。
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "ap-northeast-1"
}
resource "aws_vpc" "main" {
cidr_block = "10.1.0.0/16"
tags {
Name = "VPC領域：Terraform"
}
}
// + 追記
resource "aws_internet_gateway" "gw" {
vpc_id = "${aws_vpc.main.id}"
tags {
Name = "Internet Gateway by Terraform"
}
}
// + 追記
resource "aws_route_table" "r" {
vpc_id = "${aws_vpc.main.id}"
route {
cidr_block = "0.0.0.0/0"
gateway_id = "${aws_internet_gateway.gw.id}"
}
tags{
Name = "Public route table by Terraform"
}
}
resource "aws_subnet" "public" {
vpc_id = "${aws_vpc.main.id}"
cidr_block = "10.1.1.0/24"
tags {
Name = "Public Subnet by Terraform"
}
}
// + 追記
resource "aws_route_table_association" "a" {
subnet_id = "${aws_subnet.public.id}"
route_table_id = "${aws_route_table.r.id}"
}
ここでは、3つの要素が追記されています。
まず、AWS Internet GatewayをVPC内に作成しています。そして、作成したInternet Gatewayに接続を流すroute tableを作成しています。最後に、public subnetとroute tableを関連付けています。
これにより、"public subnet"は外部Internetからの接続を受け付けられるようになりました。
手順3の関連資料
- Terraform公式リファレンス：Resource: aws_internet_gateway
- Terraform公式リファレンス：Resource: aws_route_table
- Terraform公式リファレンス：Resource: aws_route_table_association
4. public subnetにEC2 instanceを作成する
本章のコードは、GitHub - Khigashiguchi/terraform-basic-network at 0.4 にて公開しています。
手順3までで作成したsubnet内にEC2 instanceを作ります。main.tfに追記します。
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "ap-northeast-1"
}
resource "aws_vpc" "main" {
cidr_block = "10.1.0.0/16"
enable_dns_support = true // +追記
enable_dns_hostnames = true // +追記
tags {
Name = "VPC領域：Terraform"
}
}
resource "aws_internet_gateway" "gw" {
vpc_id = "${aws_vpc.main.id}"
tags {
Name = "Internet Gateway by Terraform"
}
}
resource "aws_route_table" "r" {
vpc_id = "${aws_vpc.main.id}"
route {
cidr_block = "0.0.0.0/0"
gateway_id = "${aws_internet_gateway.gw.id}"
}
tags{
Name = "Public route table by Terraform"
}
}
resource "aws_subnet" "public" {
vpc_id = "${aws_vpc.main.id}"
cidr_block = "10.1.1.0/24"
tags {
Name = "Public Subnet by Terraform"
}
}
resource "aws_route_table_association" "a" {
subnet_id = "${aws_subnet.public.id}"
route_table_id = "${aws_route_table.r.id}"
}
// + 追記
resource "aws_security_group" "wsg" {
name = "web-sg"
description = "web-sg security group created by terraform"
vpc_id = "${aws_vpc.main.id}"
ingress{
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
tags{
Name = "web-sg"
}
}
// + 追記
resource "aws_key_pair" "auth" {
key_name = "${var.key_name}"
public_key = "${file(var.public_key_path)}"
}
// + 追記
resource "aws_instance" "web" {
ami = "ami-08847abae18baa040" // Amazon Linux 2 AMI (HVM), SSD Volume Type
instance_type = "t2.micro"
subnet_id = "${aws_subnet.public.id}"
private_ip = "10.1.1.10"
associate_public_ip_address = true
security_groups = [
"${aws_security_group.wsg.id}"
]
key_name = "${aws_key_pair.auth.id}"
tags {
Name = "Web Server by Terraform"
}
}
ここでは、3つの要素を追加しています。
まずは、Instanceに設定するSecurity Groupです。web-sgという名前で作っています。このセキュリティグループは、22・80ポートを全IPから受け付けるという設定になります。
次に、aws_key_pairという公開鍵認証でSSH接続する際の鍵です。ここでは次の実施する内容にてローカルで生成した公開鍵をkey pairに指定するという作業を進めます。
最後に、EC2 instanceを作成しています。大まかに下記のような内容のInstanceを作成します。
- 無料枠で使用できるAMI（Amazon Linux 2 AMI (HVM), SSD Volume Type＿
- インタンスタイプ：t2.micro
- subnet：上で作成したpublic subnet
そして、SSH接続するためのキーを作成・設定します。まず、すでに定義したmain.tfの記述内容に合わせてvariables.tfに下記を追加します。
variable "aws_access_key" {}
variable "aws_secret_key" {}
// +追記
variable "key_name" {
description = "the name of aws key pair"
}
// +追記
variable "public_key_path" {
description = "path to the ssh public key"
}
そして、これまでvariableの指定をコマンドインターフェースからやっていましたが、同一ディレクトリにtfvarsという拡張子のファイルを置くことによって、ファイルに指定することが出来ます。
実際に、terraform.tfvarsというファイルを作成して下記のように定義します。
aws_access_key = "YOUR-ACCESS-KEY" aws_secret_key = "YOUR-SECRET-KEY" key_name = "terraform-basic-key" public_key_path = "~/.ssh/terraform-basic-key.pub"
今まで、コマンドインターフェースで入力していた内容もこのように書くことにってファイルからの入力が可能になります。（このファイルはシークレット情報が含まれるためgit管理外に置くことが推奨されます。）
最後に、terraform-basic-keyという名前でsshキーを作成して~/.ssh以下に設置しておきましょう。
上記により、EC2 Instanceの生成が可能になりました。
手順4の関連資料
- Terraform公式リファレンス：Resource: aws_instance
- Terraform公式リファレンス：Resource: aws_security_group
- Hashicorp/terraform:issues#2164 How to give a single security group for an aws instance ?
- Terraform でキーペア登録し起動した EC2 に SSH接続
5. private subnetを作成しEC2 instanceを作成する
本章のコードは、GitHub - Khigashiguchi/terraform-basic-network at 0.6 にて公開しています。
さらに、外部Internetからの接続を受け付けないprivate subnetを作成してその中にinstanceを作ります。main.tfに追記していきます。
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "ap-northeast-1"
}
resource "aws_vpc" "main" {
cidr_block = "10.1.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags {
Name = "VPC領域：Terraform"
}
}
resource "aws_internet_gateway" "gw" {
vpc_id = "${aws_vpc.main.id}"
tags {
Name = "Internet Gateway by Terraform"
}
}
resource "aws_route_table" "r" {
vpc_id = "${aws_vpc.main.id}"
route {
cidr_block = "0.0.0.0/0"
gateway_id = "${aws_internet_gateway.gw.id}"
}
tags{
Name = "Public route table by Terraform"
}
}
resource "aws_subnet" "public" {
vpc_id = "${aws_vpc.main.id}"
cidr_block = "10.1.1.0/24"
availability_zone = "ap-northeast-1d"
tags {
Name = "Public Subnet by Terraform"
}
}
// +追記
// private subnetの作成、internet gatewayとの接続のないdefault route tableをそのまま使うことで外部Internetから遮断されている状態にする
resource "aws_subnet" "private" {
vpc_id = "${aws_vpc.main.id}"
cidr_block = "10.1.2.0/24"
availability_zone = "ap-northeast-1d"
tags {
Name = "Private Subnet by Terraform"
}
}
resource "aws_route_table_association" "a" {
subnet_id = "${aws_subnet.public.id}"
route_table_id = "${aws_route_table.r.id}"
}
resource "aws_security_group" "wsg" {
name = "web-sg"
description = "web-sg security group created by terraform"
vpc_id = "${aws_vpc.main.id}"
ingress{
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
// +追記
// pingでの疎通確認ができるように設定
ingress{
from_port = -1
to_port = -1
protocol = "icmp"
cidr_blocks = ["0.0.0.0/0"]
}
tags{
Name = "web-sg"
}
}
// +追記
// 22番・3306番ポート・ICMPプロトコル通信を許可する設定（DBサーバを想定しているため）
resource "aws_security_group" "dsg" {
name = "db-sg"
description = "db-sg security group created by Terraform"
vpc_id = "${aws_vpc.main.id}"
ingress{
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = 3306
to_port = 3306
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = -1
to_port = -1
protocol = "icmp"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_key_pair" "auth" {
key_name = "${var.key_name}"
public_key = "${file(var.public_key_path)}"
}
resource "aws_instance" "web" {
ami = "ami-08847abae18baa040" // Amazon Linux 2 AMI (HVM), SSD Volume Type
instance_type = "t2.micro"
subnet_id = "${aws_subnet.public.id}"
private_ip = "10.1.1.10"
associate_public_ip_address = true
security_groups = [
"${aws_security_group.wsg.id}"
]
key_name = "${aws_key_pair.auth.id}"
tags {
Name = "Web Server by Terraform"
}
}
// +追記
// private subnet内にinstanceを作成
resource "aws_instance" "db" {
ami = "ami-08847abae18baa040" // Amazon Linux 2 AMI (HVM), SSD Volume Type
instance_type = "t2.micro"
subnet_id = "${aws_subnet.private.id}"
associate_public_ip_address = false
private_ip = "10.1.2.10"
security_groups = [
"${aws_security_group.dsg.id}"
]
key_name = "${aws_key_pair.auth.id}"
tags {
Name = "DB Server by Terraform"
}
}
行数が増えてきたので、main.tfのコメントにて詳細について記載しています。
6. NAT Gatewayを作成する
本章のコードは、GitHub - Khigashiguchi/terraform-basic-network at 0.7 にて公開しています。
private subnet内のInstanceから外部に対してのOUTBOUND通信ができるようにNAT Gatewayを設定します。main.tfに下記のように追記します。
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "ap-northeast-1"
}
resource "aws_vpc" "main" {
cidr_block = "10.1.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags {
Name = "VPC領域：Terraform"
}
}
resource "aws_internet_gateway" "gw" {
vpc_id = "${aws_vpc.main.id}"
tags {
Name = "Internet Gateway by Terraform"
}
}
resource "aws_route_table" "public" { // - 修正 from "a" -> "public"
vpc_id = "${aws_vpc.main.id}"
route {
cidr_block = "0.0.0.0/0"
gateway_id = "${aws_internet_gateway.gw.id}"
}
tags{
Name = "Public route table by Terraform"
}
}
// + 追記
// private subnetのroute tableを作成、以降で定義するNAT Gatewayを指定。
resource "aws_route_table" "private" {
vpc_id = "${aws_vpc.main.id}"
route {
cidr_block = "0.0.0.0/0"
nat_gateway_id = "${aws_nat_gateway.default.id}"
}
tags{
Name = "Private route table by Terraform"
}
}
resource "aws_subnet" "public" {
vpc_id = "${aws_vpc.main.id}"
cidr_block = "10.1.1.0/24"
availability_zone = "ap-northeast-1d"
tags {
Name = "Public Subnet by Terraform"
}
}
resource "aws_subnet" "private" {
vpc_id = "${aws_vpc.main.id}"
cidr_block = "10.1.2.0/24"
availability_zone = "ap-northeast-1d"
tags {
Name = "Private Subnet by Terraform"
}
}
// + 追記
// NAT Gateway用のEIPを作っておく
resource "aws_eip" "nat" {
vpc = true
}
// + 追記
// NAT Gatewayを作成
resource "aws_nat_gateway" "default" {
allocation_id = "${aws_eip.nat.id}"
subnet_id = "${aws_subnet.public.id}"
tags{
Name = "default Gateway by Terraform"
}
}
resource "aws_route_table_association" "public" { // - 修正 from "a" -> "public"
subnet_id = "${aws_subnet.public.id}"
route_table_id = "${aws_route_table.public.id}"
}
// + 追記
// private subnetと追加作成したroute tableを関連付ける
resource "aws_route_table_association" "private" {
subnet_id = "${aws_subnet.private.id}"
route_table_id = "${aws_route_table.private.id}"
}
resource "aws_security_group" "wsg" {
name = "web-sg"
description = "web-sg security group created by terraform"
vpc_id = "${aws_vpc.main.id}"
ingress{
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = -1
to_port = -1
protocol = "icmp"
cidr_blocks = ["0.0.0.0/0"]
}
tags{
Name = "web-sg"
}
}
resource "aws_security_group" "dsg" {
name = "db-sg"
description = "db-sg security group created by Terraform"
vpc_id = "${aws_vpc.main.id}"
ingress{
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = 3306
to_port = 3306
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
ingress{
from_port = -1
to_port = -1
protocol = "icmp"
cidr_blocks = ["0.0.0.0/0"]
}
}
resource "aws_key_pair" "auth" {
key_name = "${var.key_name}"
public_key = "${file(var.public_key_path)}"
}
resource "aws_instance" "web" {
ami = "ami-08847abae18baa040" // Amazon Linux 2 AMI (HVM), SSD Volume Type
instance_type = "t2.micro"
subnet_id = "${aws_subnet.public.id}"
private_ip = "10.1.1.10"
associate_public_ip_address = true
security_groups = [
"${aws_security_group.wsg.id}"
]
key_name = "${aws_key_pair.auth.id}"
tags {
Name = "Web Server by Terraform"
}
}
resource "aws_instance" "db" {
ami = "ami-08847abae18baa040" // Amazon Linux 2 AMI (HVM), SSD Volume Type
instance_type = "t2.micro"
subnet_id = "${aws_subnet.private.id}"
associate_public_ip_address = false
private_ip = "10.1.2.10"
security_groups = [
"${aws_security_group.dsg.id}"
]
key_name = "${aws_key_pair.auth.id}"
tags {
Name = "DB Server by Terraform"
}
}
手順6の関連資料
上記設定追加により、NAT Gatewayが作成されました。以上にて、目標としていたインフラ構成の実現が完了しました。
まとめ
- Terraformを用いてAWSでのインフラ構築を行いました。インフラ構成をコード化しておくと再度作成する時や不要になった際の削除などが用意になるため、業務インフラ構成や個人でのインフラ構築などにも有用になるかと思います。
湯河原「おんやど恵」で足湯駆動開発 | 開発合宿レポート
2018年9月1日（土）〜2018年9月3日（月）の2泊3日で、友人と湯河原まで開発合宿してきましたので、雑にどんな感じの場所かを書いていきます。
宿
「おんやど恵」という旅館に2泊3日で泊まりました。
Googleで「開発合宿」と調べるとすぐ検索で出てくる有名な宿です。
部屋は和室のとても快適なお部屋です。
開発場所
専用の会議室を予約することができます。
また、足湯コーナーがあるので定期的に足湯駆動開発しました。
足湯駆動開発してる pic.twitter.com/u5pBkMTp7N
— Khigashiguchi (@Khigashiguchi) September 1, 2018
ご飯
旅館では、朝・夜ごはんを用意していただけます。
夜ご飯は、会席料理をいただきました。
朝ごはんもボリュームが有って美味しいです。
駅周辺グルメ
旅館付近にはあまりないですが、湯河原駅までいくと、「らーめん 麺の蔵」というラーメン屋があります。
旅館付近では、旅館のすぐ横にLAWSONがあったのでそこで昼ごはんなどを買っていました。
ちょっと気分転換したい時
少し歩けばとてもマイナスイオンが感じられる公園が出てきます。
歩いて10分くらいの距離にありました。
開発合宿中にマイナスイオンを感じに来た pic.twitter.com/99mA4mAOLe
— Khigashiguchi (@Khigashiguchi) September 2, 2018
また、独歩の湯という足湯施設に行くことも出来ます。
18:00閉店ですが、気分転換に遊び行ってもいいですね。
まとめ
9月ということもあり、人が多すぎることもなくとても快適に過ごせました。
ECS(Fargate)で動かすコンテナにSSMからクレデンシャル情報を渡す
発表時の資料
本記事に関する発表資料はこちらです。
※ プラットフォームバージョン1.3以上の場合
この記事はプラットフォーム1.3より前を使用する前提で記載しています。 1.3以上をお使いになる場合は、こちらの記事をご覧ください。
https://devblog.thebase.in/entry/2019/01/16/110000
目次
- クレデンシャル情報の扱い方
- 概要構成
- 具体的な手順
- 参考資料
クレデンシャル情報の扱い方
クレデンシャル情報の扱い方を考えるに当たり、Beyond the Twelve-Factor Appというクラウドネイティブアプリケーションの設計パターンについて説明した資料がよく参照されています。
上記の資料内の「05. CONFIGURATION, CREDENTIALS, AND CODE」という章で次のように記載されています。
「今すぐにでもコードをオープンソース化できるかどうか」というのがわかりやすい指標ですね。こちらで推奨されている環境変数への格納を今回進めていきます。
寄り道：環境変数への格納について検討
環境変数への格納について、「セキュリティ観点」・「管理観点」の両者で検討してみます。
セキュリティ観点
セキュリティ観点的には、必要以上に参照可能な状態を避ける必要があります。例えば、「/etc/environmentにクレデンシャル情報を書いてそれを使う」といったことをした場合は、アプリケーションの動作に必要なプロセス以外からもクレデンシャル情報を読むことができます。
今回のケースでは、コンテナプロセス上でアプリケーションを動かすケースのため、コンテナプロセスに対して環境変数を注入することになります。それであれば、必要なプロセス以外からのクレデンシャル情報へのアクセスはある程度避けることができそうです。
管理観点
YAMLやTOMLファイルで設定する際、次のように要素に応じて階層的に管理したいというニーズがあると思います。
[database1] user = "sample_user1" password = "sample_password1" host = "database1" port = 3306 name = "sample1" [database2] user = "sample_user2" password = "sample_password2" host = "database2" port = 3306 name = "sample2"
環境変数での注入の場合、単に環境変数に直接書くのであれば階層をもたせることは少し難しそうですが、AWSであればAWS Systems Manager パラメータストアを用いることで階層管理を実現できそうです。
AWS Systems Manager パラメータストア は､設定データ管理と機密管理のための安全な階層型ストレージを提供します。パスワード、データベース文字列、ライセンスコードなどのデータをパラメータ値として保存することができます。
概要構成
今回の概要構成は下図のものです。
大まかな構成要素は以下になります。
| 略語 | 正式名称 | 概要 |
|---|---|---|
| ECS | Amazon Elastic Container Service | Docker コンテナをサポートする拡張性とパフォーマンスに優れたコンテナオーケストレーションサービス |
| ECR | Amazon Elastic Container Registry | 完全マネージド型の Docker コンテナレジストリ |
| Fargate | AWS Fargate | ECS/EKS内のテクノロジー、サーバーやクラスターを管理することなくコンテナを実行できるようになる |
| IAM | AWS Identity and Access Management | AWS リソースへのアクセスを安全に制御するためのウェブサービス |
| Parameter Store | AWS Systems Manager Paramter Store | 設定データ管理と機密管理のための安全な階層型ストレージ |
| KMS | AWS Key Management Service | データの暗号化に使用するキーの容易な作成および管理 |
| ALB | Application Load Balancer | L4/L7で機能するロードバランサー |
具体的な手順
今回のサンプルは下記のgithubレポジトリに公開しています。
※ 今回のサンプルをそのまま試しに実行する場合は、なにかしらのMySQLサーバを準備する必要があります。サンプルを実行したい場合は、RDSの無料枠などを利用して接続可能なデータベースを用意してください。
手順一覧
- KMSで暗号化キーの作成
- Parameterの登録
- IAMロールの作成
- IAMポリシーの作成
- IAMロールにIAMポリシーをアタッチ
- Containerイメージの作成・プッシュ
- ECSのタスク定義
- タスク実行
KMSで暗号化キーの作成
まずは、クレデンシャル情報を暗号化するためのキーをKMSで作成します。作成に当たり、AWS CLIのcreate-keyコマンドを実行します。
$ aws kms create-key --description go-ecs-sample --region ap-northeast-1 KEYMETADATA < AWSAccountId > arn:aws:kms:ap-northeast-1:< AWSAccountId >:key/< KeyId > go-ecs-sample True < KeyId > CUSTOMER Enabled ENCRYPT_DECRYPT AWS_KMS
上記コマンドを実行すると、CMK(customer master key)というデータの暗号化に用いるキーが作られます。後続で実行する作業にて、< AWSAccountId >・< KeyId >を使っていきます。
Parameterの登録
次に、Parameter Storeにクレデンシャル情報を登録していきます。今回は、RDSへの接続情報を登録していきます。
$ aws ssm put-parameter --name /goecssample/database/sample/master/user --type "String" --value "user" --description "データベースのmasterユーザー名" --region ap-northeast-1 $ aws ssm put-parameter --name /goecssample/database/sample/master/password --type "SecureString" --value "password" --key-id "< KeyId >" --description "データベースのmasterユーザーパスワード" --region ap-northeast-1 $ aws ssm put-parameter --name /goecssample/database/sample/master/host --type "String" --value "host" --description "データベースのmasterホスト名" --region ap-northeast-1 $ aws ssm put-parameter --name /goecssample/database/sample/master/name --type "String" --value "sample" --description "データベースのmasterデータベース名" --region ap-northeast-1 $ aws ssm put-parameter --name /goecssample/database/sample/master/port --type "String" --value "3306" --description "データベースの接続ポート" --region ap-northeast-1
上記のコマンドを実行すると次のようなレスポンスが返ってきます。
1 1 1 1 1
このレスポンス結果は、各パラメータのバージョンを表しています。これは--overwriteオプションを付けて上書きしたりすると、2・3と増えていきます。
また、環境変数を扱う上での階層管理ですが、Parameter Storeを使う場合は、/stage1/stage2/stage3という形で階層を区切ることが出来るので、今回活用しています。
AWS System Manager: パラメータを階層に編成
IAMロールの作成
次に、ECSタスクのタスクロールとなるIAMロールを作成します。タスク用のIAMロールを作成し、タスク定義に当該IAMロールを定義することによって、IAMロールの認証情報にアクセスすることができるようになります。今回、Parameter Store・KMSにアクセス可能なIAMロールを作成して、ECSのタスク定義に定義することを目指します。
まず、IAMロールの定義をjsonで作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ecs-tasks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
作成したファイルをもとにIAMロールを作成します。
$ aws iam create-role --role-name go-ecs-sample --assume-role-policy-document file://ecs-tasks-trust-policy.json ROLE arn:aws:iam::< AWSAccountId >:role/go-ecs-sample 2018-08-24T02:10:14Z / HFJKHSYGHOSUHG... go-ecs-sample
IAMポリシーの作成
次に、IAMポリシーを作成します。まずは次のようなjsonファイルを作成します。ここでは、「Parameter Storeのgoecssample/以下の階層のパラメータを取得する」・「今回作成したKMSキーで暗号化したものを複合する」ことを許可しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Sid": "Stmt1482841904000",
"Effect": "Allow",
"Action": [
"ssm:GetParameters"
],
"Resource": [
"arn:aws:ssm:ap-northeast-1:< AWSAccountId >:parameter/goecssample/*"
]
},
{
"Sid": "Stmt1482841948000",
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:ap-northeast-1:< AWSAccountId >:key/< KeyId >"
]
}
]
}
作成したファイルをもとにIAMロールを作成します。
$ aws iam create-policy --policy-name go-ecs-sample --policy-document file://go-ecs-secret-access.json POLICY arn:aws:iam::< AWSAccountId >:policy/go-ecs-sample 0 2018-08-24T02:13:46Z v1 True / 0 HFJKHSYGHOSUHG... go-ecs-sample 2018-08-24T02:13:46Z
IAMロールにIAMポリシーをアタッチ
作成したIAMロールにIAMポリシーをアタッチします。
$ aws iam attach-role-policy --role-name go-ecs-sample --policy-arn "arn:aws:iam::< AWSAccountId >policy/go-ecs-sample"
Dockerイメージの作成・プッシュ
ここまででParameter Storeから必要な情報を取る準備はできたので、次にECSタスクで実行するためのDockerイメージを作成していきます。今回のサンプルは、MySQLサーバに接続可能であればサーバが立ち上がるAPIです。
https://github.com/Khigashiguchi/go-ecs-example/blob/master/main.go
func main() {
var err error
// Get configuration
conf, err := config.NewConfig()
if err != nil {
fmt.Fprintf(os.Stderr, "failed to get configuration: %s", err)
panic(err.Error())
}
// Get database Handle
db, err := NewDB(conf.DB)
if err != nil {
fmt.Fprintf(os.Stderr, "failed to get connection with database: %s", err)
panic(err.Error())
}
// Router
r := mux.NewRouter()
h := Handler{DB: db}
r.Methods("GET").Path("/posts").HandlerFunc(h.GetPostsHandler)
r.Methods("GET").Path("/.healthcheck").HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
})
// Serve HTTP service
fmt.Fprint(os.Stdout, ">> Start to listen http server post :80\n")
if err = http.ListenAndServe(":80", r); err != nil {
fmt.Fprintf(os.Stderr, "failed to start http server: %s", err)
panic(err.Error())
}
}
上記の簡単なAPIを動かすために次のようなDockerfileを書きます。ENTRYPOINTからaws-cliを叩くためにawscliをインストールしています。
https://github.com/Khigashiguchi/go-ecs-example/blob/master/Dockerfile
FROM golang:1.10-alpine3.7
WORKDIR /go/src/github.com/Khigashiguchi/go-ecs-example/
COPY . /go/src/github.com/Khigashiguchi/go-ecs-example/
RUN apk add --no-cache ca-certificates \
dpkg \
gcc \
git \
musl-dev \
openssh \
bash \
curl \
python
# Install the AWS CLI
# https://aws.amazon.com/jp/blogs/news/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/
RUN curl -O https://bootstrap.pypa.io/get-pip.py
RUN python get-pip.py
RUN pip install awscli
RUN go get -u github.com/golang/dep/cmd/dep
RUN dep ensure
RUN go build -v -o server
EXPOSE 80
ENTRYPOINT ["./docker-entrypoint.sh"]
CMD ["./server"]
ENTRYPOINTで指定しているdocker-entrypoint.shは次のようなものです。ローカル環境では叩きに行かずAWS ECS上でのデプロイ時のみParameter Storeにアクセスしたいため、ECS上でのデプロイ時のみ事前付与する環境変数、PARAMETER_STORE_PREFIXを用意しています。
#!/usr/bin/env bash
set -e
PARAMETER_STORE_PREFIX=${PARAMETER_STORE_PREFIX:-}
if [ -n "$PARAMETER_STORE_PREFIX" ]; then
export DB_USER=$(aws ssm get-parameters --name /${PARAMETER_STORE_PREFIX}/database/sample/master/user --query "Parameters[0].Value" --region ap-northeast-1 --output text)
export DB_PASSWORD=$(aws ssm get-parameters --name /${PARAMETER_STORE_PREFIX}/database/sample/master/password --with-decryption --query "Parameters[0].Value" --region ap-northeast-1 --output text)
export DB_HOST=$(aws ssm get-parameters --name /${PARAMETER_STORE_PREFIX}/database/sample/master/host --query "Parameters[0].Value" --region ap-northeast-1 --output text)
export DB_NAME=$(aws ssm get-parameters --name /${PARAMETER_STORE_PREFIX}/database/sample/master/name --query "Parameters[0].Value" --region ap-northeast-1 --output text)
export DB_PORT=$(aws ssm get-parameters --name /${PARAMETER_STORE_PREFIX}/database/sample/master/port --query "Parameters[0].Value" --region ap-northeast-1 --output text)
fi
exec "$@"
これを、ECRのレポジトリにイメージプッシュします。レポジトリの作成手順は下記をご参照ください。
$ $(aws ecr get-login --no-include-email --region ap-northeast-1) $ docker build -t go-ecs-sample . $ docker tag go-ecs-sample:latest < AWSAccountId >.dkr.ecr.ap-northeast-1.amazonaws.com/go-ecs-sample:latest $ docker push < AWSAccountId >.dkr.ecr.ap-northeast-1.amazonaws.com/go-ecs-sample:latest
ECSのタスク定義
ECSのタスク定義を作成します。タスク定義の詳細の説明については、下記の公式ドキュメントをご参照ください。
要点としては、下記2点です。
- タスクロールに今回作成したIAMロール
`go-ecs-exampleを指定してください。
- タスクロールに今回作成したIAMロール
なお、タスク実行ロールはデフォルトのecsTaskExecutionRoleでOKです。
そして、コンテナ定義で設定する環境変数に次の内容をセットしてください。
| 環境変数 | 値 |
|---|---|
| PARAMETER_STORE_PREFIX | goecssample |
タスク実行
タスクを登録するとタスクが実行されます。
前回のステータスがRunningになっていれば、OKです。
参考資料
Goのテストに関する"もやもや"がgolang.tokyo#17でとても解消された | golang.tokyo#17参加レポート
2018年8月21日（火）に、freee株式会社さんのイベント会場で、golang.tokyo#17が開催されました。今回のテーマは、「今あらためてテストの話」ということだったのですが、普段テストを書いていてもやもやしていた部分が解消されるとてもタメになる内容ばかりでした。 本参加レポートでは、会場の雰囲気から内容までをレポートいたします。
golang.tokyoとは
プログラミング言語のGoの導入企業のメンバーが集まり、Goの普及を推進するコミュニティです トークイベント、ハンズオン、etcのイベントを開催していく予定です！
すでに、togetterをまとめていただいているので、当日の様子はこちらで見ることができます。 togetter.com
会場の雰囲気
今回の会場は、freee株式会社さんのイベントスペースで行われました。
発表内容
Tour of testing by budougumi0617
@budougumi0617さんによる発表です。
前段に、freeeさんの会社について紹介されていて、Railsがメインで動いているところに対して、マイクロサービス化を進めていて、実際4機能ほどGoで書かれたマイクロサービスが動いているようです。
今回の発表では、主に「go testコマンド・testing.TについてGo1.10までの復習」・「テストのベタープラクティス」についてはなされていました。
体系的にまとめてくださっているので、何回でも見返したい神資料でした。
個人的に「なるほど」となったのは、Table Driven Testingでループを回す際、testsで回してttで受け取るという点でした。
標準パッケージのテストの書き方が基本的にこうなっているとのことで、cases・cでやっていた私は返ってすぐ書き換えました。
非公開な機能を使ったテスト by tenntenn
資料URL：https://docs.google.com/presentation/d/1LLEHlg2IEecaoXnUpKOkMSE1hk9lAWVNJz5VMwmbqm8/edit
Gopher道場で講師をされている、@tenntennさんの発表でした。
「テストはテスト対象と別のパッケージにする」事に関する標準パッケージの状況・利点・export_test.goを利用したテスト手法についてご紹介されていました。
発表の際、デモをおこなわれていたのですが、デモで使用されていたコードは以下の記事にて公開されているようです。
今回紹介されている手法は、標準パッケージでも利用されているようなので、標準パッケージのソースを読むのが一番参考になるとのことでした。
また、質疑応答にて、「非公開な機能が多いと大変な書き方では」という意見が上がったのですが、その場合は、そもそも「非公開が多いのはよくない設計なのでは」という見直した上で、internalパッケージにするといった検討が必要になることもあるとのことでした。
LT1 外部環境への依存をテストする by duck8823
www.slideshare.net
@duck8823さんより、CIサーバーを作った際に行った、外部環境への依存をテストする方法についての発表でした。
今回発表されているCIサーバーはgithub上に公開していただいています。
LT2 Developer-friendly なテストを考える by izumin5210
@izumin5210さんよる発表です。
「Developer-friendly なテスト」を「落ちたときに直しやすいテスト」と定義した上で、どのようにテストを書いていくかという点について、Table Driven Testingやgoogle/go-cmpなどを使うやり方をご紹介されていました。
LT3 止めたいのに止められないテストの話 by knsh14
資料URL: https://talks.godoc.org/github.com/knsh14/go-slides/lt-go-test-failfast.slide#1
@knsh14さんによる発表です。
go test -failtestを実際に試した際に意図しない挙動になったことをきっかけに、内部挙動を調査・実験していった内容でした。実際に、go test -failtestはちゃんと動くのかという結論については資料でぜひご確認ください。
まとめ
「今あらためてテストの話」というテーマで開催された、golang.tokyo#17でしたが、普段テストを書いていて「これであってるのか？？？」ともやもやしていた点を話していただいてとても素晴らしい会でした。
golang.tokyoの運営スタッフの皆さん・会場を提供していただいたfreeeの皆さんありがとうございました！
Gopher道場#2を卒業しました
Gopher道場#2にお世話になりとても良かったので、実際どういうところが良かったのかなど伝えようということでエントリーを書きます。
Gopher道場#2とは
conpassのページでは、Gopher道場とは、メルペイが提供する実践的なGoを体系的に学べる場です。という内容で紹介されています。
実際、Gopher道場では週一回の講義&宿題という形で体系的にGoを学んでいきました。
Gopher道場に参加してよかったこと
体系的に学べる
Gopher道場では、@tenntennさんによるGo言語についての講義を受けて、体系的に学ばせていただきました。 個人的にずっとふわふわしていた、構造体やインタフェースなどの概念についてかなり腑に落ちる形で説明していただけました。
実務での経験が盛り込まれてる
書籍では得られない知見として、「業務では実際どうなのか」という話が随所にあったのがとてもありがたかったです。基本的なところでpanicはどういうときに使うのかといったところから、実際にtemplate/htmlを使うのか・Goのtestでライブラリを使うのかなど、実務レベルでどういうやり方をしてるのかについて話していただけて大変参考になりました。
参考URLの共有
講義中、メルペイエンジニアの方がslackで講義内容に関連する参考URLを都度シェアしていただいていました。派生情報として参照して理解を深めることができ大変助かりました。
他のGopher道場生のコード・それに対するレビュー
毎回の講義後の課題に対して他のGopher道場生のコードとそれに対するレビューが見られるのがとても参考になりました。interfaceを使ったうまい抽象化の仕方などをコードを読んで取り入れてみるなど、自分ひとりでやっていたときには得られない知見が得られたのがとても良かったです。
Gopher道場#2 LT大会
Gopher道場後に、道場生によるLT大会が行われました。
私は、「業務中にサクッと書いたGo製ツールの話」というタイトルで、Gopher道場で覚えたテストの書き方・http.Handlerの使い方なども取り入れつつ実務で活用した話をさせていただきました。
Gopher道場で学んだ内容を、これからのGoコードに活かして実践していくのがとても楽しみです。
最後に
このような時間をいただけて、運営いただいたtenntennさんやosamingoさんを始めとしたメルペイエンジニアの方々には感謝しかありません。 今後、Goコミュニティの発展に寄与できるように頑張っていこうと思います💪
PHPカンファレンス福岡2018本編&前夜祭リジェクトコン参加レポート
福岡・博多にて2018年6月15日（金）に【非公式】PHPカンファレンス福岡2018前夜祭リジェクトコン、2018年6月16日（土）にPHPカンファレンス福岡2018、が開催され東京から遠征参加しました。参加する方が増えれば良いなと思い今回レポートブログを書かせていただきます。
【非公式】PHPカンファレンス福岡2018前夜祭リジェクトコン
今回PHPカンファレンス福岡2018のスピーカー応募率が例年の数倍あったらしく、非公式で本編のスピーカー応募で落選した方が発表する場を用意していただいていました。 connpass.com
会場の様子
前夜祭リジェクトコンは、LINE Fukuokaさんのイベントスペースで開催されました。
セッション内容
「ユニットテストを書きやすくするためにテストスイートを拡張する」
@tenkomaさんより「ユニットテストを書きやすくするためにテストスイートを拡張する」という発表をされていました。assertSameによるdiffを見やすくするなどの拡張の工夫を話されています。
phpcon fuk reject conf ! @tenkoma is talking about Unit Test on @cakephp ! pic.twitter.com/APYy7rXi7K
— Noriko Yamamoto 🇯🇵 (@nauleyco) 2018年6月15日
「Docker for Mac の volume mount はどれくらい改善されたのか？」
@kunitさんより、Vagrant・Dockerそれぞれマウント方式を変えた上でどれだけのスピードが出るかというデモ中心のトークでした。
@kunit さんリジェクトコンにて#phpconfuk_rej pic.twitter.com/xCtXhf71ts
— Khigashiguchi (@Khigashiguchi) 2018年6月15日
感想
本編に全く引けを取らない密度の濃いトークにでした。前乗りで福岡に来ていてよかったなという内容でした！
PHPカンファレンス福岡2018本編
2018年6月16日（土）にPHPカンファレンス福岡の本編の会場の様子やセッション内容を一部抜粋です。 phpcon.fukuoka.jp
会場の様子
博多駅が最寄りのFFB ホール（福岡ファッションビル）で開催されました
今年はセッション会場が2トラック用意されていました。
スポンサーブースや配布物なども充実していてとても盛り上がっていました。
#phpconfuk のブースめちゃめちゃ盛り上がってる pic.twitter.com/OvCPgaBiFs
— Khigashiguchi (@Khigashiguchi) 2018年6月16日
セッション内容
今回はスピーカー応募が例年の数倍の倍率だったらしく、かなり厳選されたセッションになっていました。実際に聞いたセッションを一部抜粋します。
「何故PHPなんですか？」
Golangを使って見えてきたPHPの良さについての発表でした。Golangを使ってみて、強い静的型付けや標準機能の充実によるメリットを感じつつも、try/catchや継承などPHPで当たり前に使っていた機能がないことなどのデメリットも同時に感じたとのこと。 結果、開発の速さやWeb開発に適しているといったPHPの良さをGolangによって気がついたという発表でした。
個人的には、バージョンアップすることによって得られる新機能の恩恵についても紹介いただいていて、PHP7.3での新機能のキャッチアップがてきていなかったのでありがたい機会でした。 その際に個人的にqiitaで見た記事を関連話題としてシェアさせていただきます。
「ログの設計してますか？PSR3とログ設計の話」
若手エンジニア・中堅エンジニアに向けたログ設計やログ出力のリスクについての話をされていました。ログについて考える上でのPSR-3: Logger Interface - PHP-FIGやRFC 5424 - The Syslog Protocolを参照した上で解説いただいています。 ログ設計について知りたい人がいたときに最初に教えたいと思ったセッションでした。
「SOLIDの原則ってどんなふうに使うの？オープン・クローズドの原則編 拡大版」
phperkaigi2018で発表されたものの拡大版でした。先輩・後輩の掛け合いの形で進めていくトークで、SOLID原則の１つ、「オープン・クローズドの原則」をコードレベルで解説いただいています。
【プラチナスポンサーセッション】ロリポップ！マネージドクラウドを支えるコンテナ技術のすべて
speakerdeck.com ロリポップのマネージドクラウドを支えているコンテナ技術についてのセッションでした。内製されている、haconiwa(https://github.com/haconiwa/haconiwa)や、コンテナ技術について論文として公開されているとのことでした。
「Testing Live!!!」
www.slideshare.net
VAddy クラウド型Web脆弱性検査ツール - 株式会社ビットフォレスト を題材にしたテスティングライブでした。表記揺れなど整合性が5分間でバンバン指摘されておそらくほぼ全員が自分の携わっているサービスどうだったっけと震えるライブになりました。動画が公開されたら社内に展開したい内容でした！
「ランサーズバージョンアップ報告」
ランサーズさんによるPHP5.3・CakePHP1.3のバージョンアップの結果についてのご報告でした。昨年のPHPカンファレンス福岡2017でバージョンアップを始めるご報告をされていたものの続編になります。
感想
明日からやってみようと思える内容が多く、きっかけとしてきてよかったなと思いました。今回は、スピーカー応募落選してしまいましたが、次回は発表する側で参加できるようにしようとモチベーションがあがった2日間になりました！
