AWS公式チュートリアル「サーバーレスのウェブアプリケーションを構築」をやってみた。
最近業務でサーバレス開発に触れる機会があり、自身のサーバレスに対する苦手意識を感じたため、少しでも払拭するためにAWSの公式チュートリアルをやってみました。
チュートリアル内容
VueアプリケーションをAWS Amplifyでホスティングし、ユーザー管理、ログイン認証をCognitoで、ブラウザから叩くバックエンドAPIをAPI Gateway、AWS Lambda、Amazon DynamoDBで構築するチュートリアルでした。
流れ
学び
- Amplify Consoleを利用するとCI/CD環境を含む静的なWebアプリケーション環境を瞬時に構築できる
- Cognitoでログイン認証後に受け取るJWT(JSONトークン)を利用してAPI Gatewayを実行するための認証を行う
- 上記認証のためにCognitoユーザープールオーソライザーを利用する
感想
AmplifyやCogniteは本当にまだ触ったことが少なく、苦手意識があるので今後がっつり触りながら苦手意識を払拭したい。
「AWS認定セキュリティ・専門知識」を読んだ。
読んだきっかけ
佐々木さんが新しく本を出されたというのがtwitterで回ってきた&クラウドを利用する上でセキュリティの知識は大切ということを感じていたので。
- 作者:NRIネットコム株式会社,佐々木 拓郎,上野 史瑛,小林 恭平
- 発売日: 2020/07/29
- メディア: 単行本(ソフトカバー)
目次
第1章 AWS試験概要と学習
第2章 IDおよびアクセス管理
第3章 インフラストラクチャのセキュリティ
第4章 データ保護
第5章 ログと監視
第6章 インシデント対応
第7章 Well-Architected
第8章 練習問題
2章~6章は認定セキュリティ試験の試験ガイドに書かれている分野と対応している章立てになっていて非常にわかりやすかった。
感想
一応AWSソリューションアーキテクトプロフェッショナルまで取得しているので内容的に既知の内容が多いと思っていたが、意外と知らないことが多かったので勉強になった。
SlerのエンジニアがSRE NEXT2020に行ってきた
twitterで「ブログ書くまでが~」と書いていて、実際に#srenextで調べたところ、かなり書いている方が多かったので私も書くことにしました。
きっかけ
Slerに所属しているとあるあるだが、定型作業が自動化されていませんでした。
AWSリソースも昨年まではAWSコンソール上から作成することが多かったので
自動化やインフラのコード化などに興味があった。
たまたまSREで初のカンファレンスがあると知ったので参加しました。
聞いたセッション
- 分散アプリケーションの信頼性観測技術に関する研究
- 40000 コンテナを動かす SRE チームに至るまでの道
- パフォーマンスを最大化するための SRE のオンボーディング事例
- Practices for Making Alerts Actionable
- 冗長性と生産性を高めるハイブリッドクラウド環境の実現
- スクラムを1年回してSREと開発組織がどう変わったのか
- ZOZO MLOps のチームリーディングとSRE(Engineering)
- Webサービスを1日10回デプロイするための取り組み
分散アプリケーションの信頼性観測技術に関する研究
- 自動化すると作業不可は減るが、認知不可は高まる。
- 認知不可に耐えるには高度な訓練が必要
- SREとは「サイト信頼性を制御するための工学」
2020年の抱負
1年の計は元旦にありということで今年の抱負をまとめたいと思います。
今年は以下に注力したいです。
- コードをたくさん書く。
- DevOps周りの知識を身に着ける。
- アウトプットを増やす。
コードをたくさん書く
正直自分のやりたいことが現時点ではまだ明確に見えていないのですが、インフラエンジニアでも今後はコードが書けない・読めないとやっていけないことは目に見えているのでできるだけ毎日コードを書くようにしたいです。
DevOps周りの知識を身につける。
今のところ DevOps周り(Docker、Terraform、CircleCI、kubernates)についてあまり詳しくはないので今年は使いこなせるようにしっかりと理解したいです。
アウトプットを増やす。
去年はブログ9本、登壇0回、書籍出版0本だったので、今年は勉強したことの深い理解とエンジニアとしてプレゼンスを高めるために以下を目標に頑張りたい。
ブログ:2回/週 登壇:1回/月
2019年の振り返り
JenkinsMasterサーバからJenkinsSlaveサーバにSSH接続してジョブを実行する
以下の本を進めている中でdockercomposeでJenkinsMasterとJenskinsSlaveを立てて、MasterからSlaveにSSH接続するところでつまずいたので、Jenkinに慣れるためにコンテナでなく、EC2サーバを立ててやってみました。
https://www.amazon.co.jp/dp/B07GP1Q3VT/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
目次
ローカル開発環境
Windows10
Jenkins(Master)環境
CentOS7
Java8
Jenkins(Slave)環境
CentOS7
Java8
前提
今回のゴール
MasterからSlaveに接続してSlave側で簡単なジョブを実行できる
手順
AWSインフラ構築
上記環境を構築する
Jenkinsサーバ(Master)の構築
CentOS7のAMIを選択して、CentOS7サーバを構築する
※セキュリティグループは以下のように設定する
タイプ | プロトコル | ポート範囲 | ソース | 用途 |
---|---|---|---|---|
SSH | TCP | 22 | マイIP | ローカルからの接続用 |
カスタムTCP | TCP | 8080 | マイIP | ブラウザからのアクセス用 |
サーバに接続後、サーバにJenkinsをインストールする
$ sudo yum -y install java-1.8.0-openjdk # 前提環境のインストール $ sudo curl -o /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo # Jenkins公式yumレポジトリの追加 $ sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key # Jenkinsインストール時に使用する公開鍵を追加 $ sudo yum install jenkins # Jenkinsのインストール $ sudo systemctl enable jenkins # 自動起動設定 $ sudo systemctl start jenkins # Jenkinsの起動 $ sudo systemctl status jenkins # 起動及び自動起動確認
※firewalldが有効になっている場合は、別途8080番へのアクセスを許可する必要があるので注意
※EC2ではセキュリティグループでアクセス制限を行う為、firewalldは標準ではインストールされていない
「http://(公開IP):8080/」に接続して画面に沿って初期設定を進める
この画面まで進めれば完了
Jenkinsサーバ(Slave)の構築
Master側と同様にCentOS7のAMIを選択して、CentOS7サーバを構築する ※セキュリティグループは以下のように設定する
タイプ | プロトコル | ポート範囲 | ソース | 用途 |
---|---|---|---|---|
SSH | TCP | 22 | マイIP | ローカルからの接続用 |
SSH | TCP | 22 | (Master側のセキュリティグループ) | Master側からの接続用 |
サーバ起動後、SSH接続して、Java環境のインストール
※Masterとの連携のためにSlave側でSlave.jarを実行させる必要がある為。
$ sudo yum -y install java-1.8.0-openjdk # 前提環境のインストール $ sudo adduser jenkins # SSH接続、ジョブ実行用のユーザー作成 $ sudo passwd jenkins # パスワードを設定 New password:(適当に入力) Retype new password:(適当に入力) $ su jenkins # jenkinsユーザーに切り替え $ mkdir /home/jenkins/jenkins_slave # SlaveのJenkinsワークスペースを作成
SSH接続のための公開鍵・秘密鍵を作成
Jenkinsユーザーのまま以下を実行
$ mkdir ~/.ssh $ cd ~/.ssh $ ssh-keygen -t rsa # 公開鍵・秘密鍵を作成 Enter file in which to save the key (/home/jenkins/.ssh/id_rsa):(そのままEnter) Enter passphrase (empty for no passphrase):(適用に入力) Enter same passphrase again:(適用に入力) $ cat id_rsa.pub > ~/.ssh/authorized_keys # 公開鍵の配置 $ chmod 700 ~/.ssh # ディレクトリの権限変更 $ chmod 600 ~/.ssh/authorized_keys # ファイルの権限変更 $ cat id_rsa # 秘密鍵をクリップボードに保存
Master側でのSlave側をノードとして設定する
「http://(公開IP):8080/」に接続して[Jenkinsの管理]→[ノードの管理]を選択して
左側のノードの作成を押下 ノード名を入力して
以下のように入力する
追加ボタンを押下後、以下を入力する。
ログ確認
上手くいくとこんな感じになる
ジョブ実行
Jenkinsホーム画面より[新規ジョブ作成]、[フリースタイル・プロジェクトのビルド]を選択
[General]→[実行するノードを制限]にチェックし、 ジョブを実行するSlaveノードのラベルを入力
[ビルド]→[ビルドの手順]→[ビルド手順の追加]より シェルスクリプトに適当なシェルスクリプトを入力する
ジョブ作成後、[ビルド実行]よりジョブを手動で実行すると コンソール出力画面でSlave側でのジョブ実行が確認できる
参考
How to Connect to Remote SSH Agents? – CloudBees Support
How to Setup Jenkins Slaves Using Password and Keys
雑感
日本語のページを参照して進めたら、思いのほか情報が古くてはまった。今後は英語サイトを参考に進めたい。
AWS(EC2)上にSpringBootアプリをデプロイする
Herokuといった選択肢もあるけど、せっかくならAWS上に作ったWeb アプリ(ここではSpringBootアプリ)をデプロイしたいよね。ということで、AWSを触ったことのない人でもAWS環境を構築して、デプロイできるように手順を書いてみました。 用語とか、設定値の説明はほとんど書いていないです。とりあえず手を動かしながら、覚えたい人向け。
目次
開発環境
Window10
Java1.8
Maven
Spring Boot 2.0.4
前提
<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>
今回のゴール
以下AWS環境にSpring Bootアプリをデプロイする
手順
AWSインフラ構築
ざっくりとした用語説明
項目 | 説明 |
---|---|
EC2 | 仮想サーバー |
RDS | DBサーバ |
VPC | EC2やRDSを立てるための大枠のアドレス空間 |
サブネット | VPCをさらに分割したアドレス空間 |
ルートテーブル | 各サブネットのパケットの宛先を見て行先を決めるテーブル |
パブリックサブネット | 0.0.0.0/0 (デフォルトゲートウェイへの通信) がインターネットゲートウェイに流れるような設定 |
プライベートサブネット | 上記以外のサブネット |
インターネットゲートウェイ | VPC、インターネット間の通信を実現するためのもの |
Elastic IP | 静的な公開IPアドレス |
VPC、サブネットの作成
左上の[サービス]-[VPC]を選択後、[VPCの作成]より以下項目を入力して [作成]ボタンを押下
項目 | 設定値 |
---|---|
名前タグ | testapp_vpc(適当に設定) |
IPv4 CIDR ブロック | 10.0.0.0/16 |
VPC作成後、左上ペインより、 [サブネット]-[サブネットの作成]より以下項目を入力して[作成]ボタンを押下
項目 | 設定値 |
---|---|
名前タグ | testapp_public_subnet(適当に設定) |
VPC | testapp_vpc(先ほど作成したものを選択) |
IPv4 CIDR ブロック | 10.0.0.0/16 |
アベイラビリティゾーン | ap-northeast-1a |
IPv4 CIDR ブロック | 10.0.1.0/24 |
同じようにして以下プライベートサブネットも作成
項目 | 設定値 |
---|---|
名前タグ | testapp_private_subnet(適当に設定) |
VPC | testapp_vpc(先ほど作成したものを選択) |
IPv4 CIDR ブロック | 10.0.0.0/16 |
アベイラビリティゾーン | ap-northeast-1a |
IPv4 CIDR ブロック | 10.0.2.0/24 |
インターネットゲートウェイ作成及びVPCとの関連付け
左ペインより[インターネットゲートウェイ]-[インターネットゲートウェイの作成]より 以下項目を入力して[作成]ボタンを押下
項目 | 設定値 |
---|---|
名前タグ | testapp_igw(適当に設定) |
作成後、作成したインターネットゲートウェイを選択し、[アクション]-[VPCにアタッチ]より作成したVPCを選び、アタッチボタンを押下
ルートテーブルの作成及びサブネットとの関連付け
左ペインより[ルートテーブル]-[ルートテーブルの作成]より 以下項目を入力して[作成]ボタンを押下
項目 | 設定値 |
---|---|
名前タグ | testapp_igw(適当に設定) |
VPC | testapp_vpc(先ほど作成したものを選択) |
作成後、作成済みのルートテーブルを選択し、下のルートタブから [ルートの編集]を押下し、以下のルートを追加
送信先 | ターゲット |
---|---|
0.0.0.0/0 | testapp_igw(先ほど作成したインターネットゲートウェイを選択) |
ルート追加後、作成済みのルートテーブルを選択し、[アクション]-[サブネット関連付けの編集]より
作成した公開サブネット(testapp_public_subnet)を選択し、保存ボタンを押下
EC2の作成
左上の[サービス]-[EC2]を選択後、左ペインより[インスタンス]-[インスタンスの作成]より以下項目を入力して[作成]ボタンを押下
項目 | 設定値 |
---|---|
AMI | Amazon Linux2 |
インスタンスタイプ | t2.micro |
ネットワーク | testapp_vpc(作成したVPCを選択) |
サブネット | testapp_public subnet |
ステップ6:セキュリティグループの設定において以下でセキュリティグループを新規作成する
タイプ | プロトコル | ポート範囲 | ソース | 用途 |
---|---|---|---|---|
SSH | TCP | 22 | マイIP | サーバ接続用 |
カスタムTCP | TCP | (SpringBootの接続ポート) | 0.0.0.0/0 | ブラウザからのアクセス用 |
ElasticIPの作成及び関連付け
左ペインより[ElasticIP]-[ElasticIPアドレスの割り当て]より [割り当て]ボタンを押下して、ElasticIPを取得する。
取得後、取得したElasticIPを選択し、[アクション]-[ElasticIPアドレスの割り当て] より作成したEC2インスタンスを選択後、[関連付ける]ボタンを押下
RDSのセキュリティグループの作成
左ペインより[セキュリティグループ]-[セキュリティグループの作成]より 以下項目を入力して、[作成]ボタンを押下。
項目 | 設定値 |
---|---|
セキュリティグループ名 | testapp_rdssg |
説明 | testapp_rdssg |
VPC | testapp_vpc(作成したVPC) |
タイプ | プロトコル | ポート範囲 | ソース | 用途 |
---|---|---|---|---|
MySQL/Aurora | 3306 | (EC2のプライベートIP) | DB接続用 |
RDSの作成
左上の[サービス]-[RDS]を選択後、[VPCの作成]より以下項目を入力して [作成]ボタンを押下
項目 | 設定値 |
---|---|
パラメータグループファミリー | MySQL5.7 |
グループ名 | testapp-prgr(適当に設定) |
説明 | testapp-prgr(適当に設定) |
作成後、[パラメータグループアクション]-[編集]より以下パラメータを変更(日本語の文字化けを防ぐため)
パラメータ | 説明 | 設定値 |
---|---|---|
character_set_client | クライアントの送信する文字コード | utf-8 |
character_set_connection | 文字コードの情報がない時の文字コード | utf-8 |
character_set_datebase | 参照しているデータベースの文字コード | utf-8 |
character_set_results | クライアントへ送信する文字コード | utf-8 |
character_set_server | 既定の文字コード | utf-8 |
以下構成でRDSを作成する
項目 | 設定値 |
---|---|
DBエンジン | MySQL |
バージョン | 5.7.22 |
テンプレート | 無料利用枠 |
DB インスタンス識別子 | testapp-rds(適当に設定) |
マスターユーザー名 | *******(適当に設定) |
マスターパスワード | *******(適当に設定) |
インスタンスタイプ | t2.micro |
VPC | testapp_vpc |
最初のデータベース名 | *******(適当に設定) |
セキュリティグループ | testapp_rdssg |
パラメータグループ | testapp_prgr |
EC2に接続後、各種インストール
Powershellを開き、EC2にSSH接続する
> ssh -i "(キーペアのパス)" ec2-user@(公開IP) # EC2にSSH接続 $ sudo yum update # yumリポジトリアップデート $ yum install java-1.8.0-openjdk.x86_64 # SpringBootを動かすためのJavaをインストール $ yum install mysql # MySQLクライアントをインストール
RDSのエンドポイントを確認後、RDSに接続確認
> mysql -h (RDSのエンドポイント ) -P 3306 -u (マスターユーザ名) -p > 先ほど設定したマスターパスワード入力
環境変数を設定して、SpringBootアプリの接続情報を上書きする
※ 公式リファレンスを見るとapplication.propertiesよりも環境変数のほうが読み込み優先度が高いことがわかる
Spring Boot Reference Documentation
$ vim ~/.bach_profile # 環境変数の設定 export SPRING_DATASOURCE_URL=jdbc:mysql://(RDSのエンドポイント):3306/(作成したDB名) export SPRING_DATASOURCE_USERNAME=(設定したマスターユーザー) export SPRING_DATASOURCE_PASSWORD=(設定したマスターユーザーのパスワード) export SPRING_DATASOURCE_DRIVER_CLASS_NAME=com.mysql.jdbc.Driver $ source ~/.bash_profile # 反映
接続確認後、切断
ローカル環境でSpringBootアプリをMavenビルド
> cd (SpringBootアプリのパス) > mvnw package
EC2上にデプロイ
EC2にsftp接続後、デプロイ
> cd (ビルド後のjarファイルのあるフォルダパス) > sftp -i "(キーペアのパス)" ec2-user@(公開IP) sftp > put (jarファイル)
EC2に接続後、アプリ起動
> ssh -i "(キーペアのパス)" ec2-user@(公開IP) # EC2にSSH接続 $ java -jar ~/(jarファイル)
ブラウザからアクセス
http://(公開IPアドレス):(SpringBootの起動ポート番号)/にアクセスして DB接続できているかを確認する
参考
AWS EC2上で Spring Bootアプリ起動 - 闘うITエンジニアの覚え書き
Spring Boot Reference Documentation
Spring-Bootの設定プロパティと環境変数 - Qiita
雑感
AWSコンソール上でやるのはやっぱりしんどいし、手順も面倒くさい。あと、Paasの方が楽やん。