AWS lambdaのコードをserverless Frameworkで構築し デプロイする

AWS lambda入門しようと思い、ドキュメントを読んでいたのですが、
AWS自体は特にFWを提供しているわけでもなく、こんな仕様で作れば動きますぜって感じのものだったので、
何かないかと探した結果たどり着いたのが serverless framework

コマンド一つで各言語のひな型プロジェクト作ってくれて、
コマンド一つでデプロイできるという優れもの。
入門者にはありがたい限りです

前提

・windows
・npmインストール済み
・aws cliインストール &Configure 設定済み

インストール

npmをインストールしている前提で。コマンドラインで以下実行 基本serverlessコマンドを使って操作していくのですが、
入力するには長いので
slsというエイリアスが用意されています。
こっちを使うのがよいかと オプションはこんな感じ

プロジェクトの作成

sls createコマンドを使います。
何の言語を使うかは-t のオプションで指定できます 今回はJavaとgradleの組み合わせ できあがったプロジェクトを見ると、リクエストをログに出してHTTPステータス200を返すだけではあるものの、既に動く状態のものができあがっています。

デプロイする

細かい設定はserverless.ymlでできます。
設定できる内容は以下URLで確認できます。 https://serverless.com/framework/docs/providers/aws/guide/serverless.yml/
とりあえず今回はそのままデプロイして動かしてみる。
まずはビルドしてデプロイするzipファイルを作ります。
gradleの場合はzipで作ってuploadするらしい。 プロジェクト内のbuild/distributionディレクトリにhello.zipが出来上がっています。
これがビルド結果
次にデプロイです。
デプロイはsls deployコマンドで行います。
オプションは以下 deploy実行

動作確認

sls invokeで動かすことができます。 実行
ちゃんと結果が返ってきます。
ちなみにlocalのソースをテストしたいときは、コマンドにlocalを付けます。
※ 呼び出す関数名がhelloになっているのはserverless.ymlのデフォルト値なので さっと作ってさっと動かしたい時に非常に便利なフレームワークでした。
API Gatewayで公開する場合もymlの設定変えるだけでした。
ymlの設定内容はもう少し知る必要がありそう。

後片付け

AWS上に作成されたリソースを全部削除するのも簡単
sls removeコマンドで一発

AmazonEKSを使ったKubernetes環境を作ってみる(Windows)

はじめに

・動作環境
WindowsでkubernetesもDocker for windows経由でインストール。
kubectlもインストール済み 公式のGetting started通りにやっていきます。
相変わらずAWSのドキュメントは初学者に易しくない
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/getting-started.html

Goal

AWS上のkubernetesクラスターとローカル環境を繋ぐところまでやってみます。

EKSの利用権限を持ったIAMロールを作成

kubernetesがEKSを通してリソースの作成ができるように権限を付与したロールを作成します コンソールからIAMを開き
ロール→ロールの作成でEKSを選択し、次へ
そのまま次へ
そのまま次へ
ロールに名前をつけます。ここでは「EksServiceRole」とします

AWSクラスターVPCの作成

IAMから CloudFormationに移動
右上のリージョンを「アジアパシフィック(東京)」に変更
「新しいスタックの作成」ボタンをクリック
AmazonS3テンプレートURLの指定を選択し、以下のURLを入力して、次へ
https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2018-11-07/amazon-eks-vpc-sample.yaml
スタックの名前を「eks-vpc」に設定、他はデフォルト値のまま、次へ

そのまま次へ、
最後に確認ページに遷移するので、作成ボタンを押下

aws-iam-authenticatorのインストール

以下をダウンロードし、環境変数のPATHが通っているところに配置 https://amazon-eks.s3-us-west-2.amazonaws.com/1.10.3/2018-07-26/bin/windows/amd64/aws-iam-authenticator.exe
コマンドラインで確認
設定ができていればhelpが表示される

EKSクラスターの作成

理解が足りていないのだけど、
公式のEKSとは?の画像を見る限り、これでkubernetes masterが作られるんでしょう
CloudFormationからEKSのメニューに移動
左メニューのEKSを選択後、Create Clusterを選択
  • ClusterName : 任意の名前
  • Kubernetes version : 最新のやつ
  • Role Name : 前の手順で作成したIAMロールを選択
  • VPC : 前の手順で作成したAWS EKSクラスターVPCを選択
  • Subnet : VPCを選択すると自動で選択されるので操作不要
  • SecurityGroup : 前の手順でAWS EKSクラスターVPCを作成した際に生成されるセキュリティーグループ

EKSのkubectlを設定する

AWS CLIが必要になってきます。
インストール方法はこちらが分かりやすかったので参考にさせていただきました
https://www.skyarch.net/blog/?p=7583
以下コマンドでAWSでやりとりする際のアカウント情報等を設定。
以下のコマンドを実行し、kubectlに作成したeksクラスターを紐づけていきます 以下コマンドでkubernetesのcontextに追加され、
currentに設定されていることがわかります 以降はkubectlコマンドで操作できます。

EKSワーカーノードを作成する

※前提 
EKSがEC2インスタンスの生成をするため、
事前にEC2のキーペアの作成が必要です。 
EC2のメニューから作成しましょう。 CloudFormationメニューを開く
スタックの作成をクリック S3 テンプレート URL の指定に以下を入力して「次へ」
https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2018-11-07/amazon-eks-nodegroup.yaml
  • Stack name: 任意の名前、ここでは「eks-worker」と設定
  • Cluster Name:前の手順で作成したeksクラスターの名前。
  • ClusterControlPlaneSecurityGroup: AWSクラスターVPC作成の手順で作成されたセキュリティグループID (下に小さくVPC名が出てるのでわかるはず)
  • NodeGroupName:任意の名前、ここでは「eks-worker-node-group」と設定
  • NodeAutoScalingGroupMinSize:ワーカーノードの Auto Scaling グループがスケールインする最小ノード数。 デフォルトのまま
  • NodeAutoScalingGroupMaxSize:ワーカーノードの Auto Scaling グループがスケールアウトする最大ノード数。デフォルトのまま
  • NodeInstanceType:ワーカーノードのインスタンスタイプ。
  • NodeImageId:各リージョンに合わせたAMIを設定する必要がある。ここを「Amazon EKS-optimized AMI」でページ内検索するとリージョン毎の表があるのでそこから自分のリージョンのものを入力
  • KeyName: 起動後に、SSH を使用してワーカーノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前を入力
  • VpcId: AWSクラスターVPC作成の手順で作成されたVPC ID (下に小さくVPC名が出てるのでわかるはず)
  • Subnets: AWSクラスターVPC作成の手順で作成されたSubnet ID (下に小さくVPC名が出てるのでわかるはず)
※ NodeInstanceTypeにt2.microを指定したい場合
t2.smallしか選択できないじゃん!
無料枠があるのでt2.microを使いたい!って人もいると思うのでメモ。
↑でS3テンプレートに指定したyamlを直接ダウンロードし、以下のように編集します
当手順の最初の画面で「テンプレートをAmazonS3にアップロード」で編集したファイルを選択すると次画面で選べるようになります。
ただ、リソース不足でpodの起動に失敗することもしばしば、、、
「次へ」を選択し、作成を選ぶ

ワーカーノードとVPCクラスターを結合する

まずは以下のyamlをダウンロード https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2018-11-07/aws-auth-cm.yaml
以下の内容になっているので
rolearnの値を編集する CloudFormationのメニューを開き、EKSワーカーを選択し、出力タブを開く
そこに表示されている「NodeInstanceRole」の値に置き換える
値を置き換えたら下記コマンドで反映する 成功するとnodeが確認できるようになる あとはローカルでリソース作っていたときの容量でやれるはず、、、
一旦ここまで。

Kubernetes Workloadsリソース

Pod

リソースの最小単位。Podには1つ以上のコンテナが含まれている。 pod内は同一ネットワークであり、Pod単位でIPアドレスが割り振られる。 Pod内に2つ以上のコンテナがあっても同じIPアドレスとなるためお互いにlocalhostでアクセスができる

ReplicaSet

Podのレプリカを作成し、指定した数のPodを維持し続けるリソース

Deployment

複数のReplicaSetを管理する

DeamonSet

全Nodeに1podずつのみ配置できるリソース 。 ReplicaSetのようにレプリカ数は指定できない。 ユースケースは、各podが出すログを収集するFluentdやノードのモニタリングなどのスケールアウトの必要のないもの

StatefulSet

ReplicaSetではpod名にランダムなハッシュが付与されて生成されるが、再作成される度に名前が変わってしまうため、データベースなどのstatefulなノードに対応するのが難しい。 そういう場合はこちらを使う。 こちらは生成されるPod名にはランダムハッシュではなく、数字のindexが振られるため、pod名が変わらない。 またPersistentVolumeを使用している場合は同じディスクを利用して再作成される。

Kubernetes(Kubectl)コマンド

ymlの内容反映

Podのlog確認

Pod内の特定のコンテナのlog確認

Podのログ出力をfollowする

Podの最新10件をタイムスタンプ表示有りでログ出力

Pod内のコンテナでbash実行

Pod内の特定のコンテナでbash実行

Pod内のコンテナで引数のあるコマンドを実行

Podのコンテナにホストからポートフォワードの設定をする

例えばlocalhost:8080からpod内のnginx(port:80)にアクセスできるようにしたい場合

作成されたPod・ReplicaSet・Deploymentの一覧を表示

allで全部まとめて表示できる

作成されたPod(リソース)の参照可能な値を見る

ReplicaSetのPodをスケーリングする

Deploymentの履歴を記録する

Deploymentの履歴を確認する

Deploymentをロールバックする(リビジョン指定)

Deploymentをロールバックする(直前のリビジョン)

何も指定しないと、デフォルトの–to-revision 0が指定される

作成されたリソースの詳細を表示

【JHipster和訳】 Creating an entity

はじめに

JHipsterの勉強を兼ねて以下のページを和訳したものです。
自分の理解用なので結構な意訳なので注意してください。
https://www.jhipster.tech/creating-an-entity/

Introduction

アプリケーションを作成したら、次にエンティティを作成しましょう
例としてBookとAuthorエンティティを作るとすると
以下の作成が必要になります。
  • データベースのテーブル
  • Liquibase(データベースのマイニングツール)の変更履歴
  • JPAエンティティ
  • Spring Data Repository
  • Spring MVC Rest Controller( CRUD用メソッド含む)
  • Angular Router および ComponentとService
  • HTML
  • Integrationテスト
  • パフォーマンステスト
もし複数のEntityである場合、リレーションも必要になるでしょう、
この場合さらに
  • データベース外部キー
  • リレーションを管理するためのJavaScriptおよびHTML
entity sub generatorは必要なすべてのファイルを作成してくれ、
かつフロントエンドのCRUDも提供してくれます。
sub generatorは以下のコマンドで実行します
オプションについては以下のコマンドで参照することができます 各オプションについて
  • --table-name <table_name> – デフォルトではJhipsterはentity名からテーブル名を生成しますが、もしentityと異なる名前を使用したい場合はこのオプションで指定
  • --angular-suffix <suffix> – Angularルートに独自のsuffixを入れたい場合はこのオプションで指定
  • --client-root-folder <folder-name> – フロントエンドのrootフォルダ モノリシックアプリとマイクロサービスアプリのデフォルトは空
  • --regenerate – 作成済みのentityを再生成します。(質問なし)
  • --skip-server – クライアントサイドコードのみ生成します
  • --skip-client – サーバーサイドコードのみ生成します
  • --db – サーバーサイドコードの生成をスキップした際にDBを指定します。 それ以外の場合では効果はありません。

JHipster UML and JDL Studio

コマンドラインでJHipsterでどうやってentityを作るのかはわかったと思いますが、GUIツールのほうがわかりやすくていいという方もいると思います。
そういった場合、2つの方法があります
  • JHipster UML – UMLエディタが使用できます
  • JDL Studio – ドメインを記述するための独自言語であるJDLを使ってentityやリレーションシップ を作成するためのJHipsterのオンラインツール
もしJDL Studioを使用する場合 jhipster import-jdl your-jdl-file.jh コマンドでJDLファイルからentityを作成できます
もし JDLインポートした際に、entityを再生成したくないのであれば--json-only オプションでentityの作成をスキップされ.jhipsterフォルダにjsonファイルが格納されます デフォルトではimport-jdl はentityの変更のみ再生成しますが、もしすべてのentityを再生成したいのであれば、--force オプションを付けてください。ただしこの場合、entityファイルのローカル変更は全て上書きされてしまうので注意してください。 もし import-jdlではなくJHipsterUMLを使いたい場合はnpm install -g jhipster-uml でインストールを行い、その後jhipster-uml yourFileName.jhを実行してください

Entity fields

各entityには好きなだけfieldを追加することができます。 あなたはフィールド名とタイプを入力する必要があり、 JHipsterはそこからAngularのHTMLからLiquibaseのチェンジログまで、必要なコードと設定を全て生成します。 これらのフィールドには使用している技術で予約済みのキーワードを含めることはできません。例えば、MySQLを使用する場合
  • Javaの予約語は使用できません(コンパイルできない)
  • MySQLの予約語は使用できません(データベーススキーマの更新でエラーになる)

Field types

JHipsterでは多くのフィールドタイプをサポートしています。 データベースの型はその種類(Oracle, Cassandra…etc)に依存するため、JHipsterではJava型を使用します、そしてそこから正しいデータベースアクセスコードを生成するのがJHipsterの強みの一つです。
  • String – デフォルトのサイズはバックエンドで採用している基盤によります(JPAを使っている場合は 255) 。また、validationのルールは変更できます
  • Integer
  • Long
  • Float
  • Double
  • BigDecimal – java.math.BigDecimal, 正確な計算をしたい場合(財務運用等)
  • LocalDate – java.time.LocalDate, Javaで正確な日時管理をしたいときに
  • Instant – java.time.Instant, timestampを使いたいときに
  • ZoneDateTime – java.time.ZonedDateTime, タイムゾーンのあるdatetimeを扱いたいときに(カレンダーの予定等) 注意点として、タイムゾーンはRESTでも永続化もサポートされていないので、Instantを使ったほうがよいでしょう
  • Boolean
  • Enumeration – JavaのEnum, もしこのタイプを設定した場合, sub-generatorからどんな値が必要なのか尋ねられます。
  • Blob – バイナリデータを保存するためのオブジェクト, このタイプを設定した場合、sub-generatorからバイナリデータ, 画像データ, CLOBかを尋ねられます。画像については特にAngular側でユーザーに表示するための処理がされます

Validation

Validationは各フィールド毎に設定できます。
フィールドタイプに応じたValidationオプションが利用できます Validationは以下のものが自動生成されます
  • AngularまたはReactを使用したクライアントサイドのValidationコード
  • [Bean Validation](http://beanvalidation.org/)を使用したJavaドメインオブジェクト
Bean Validationはドメインオブジェクトの以下のケースで自動的に検証を行います
  • Spring MVC REST Controller(@Validアノテーション使用)
  • Hibernate/JPA (entityを保存する前に自動的に検証される)
Validationの情報は、データベースのカラムの正確なデータを生成するのにも使用されます。
  • Required フィールドは not nullに設定する
  • Uniqueフィールドはunique制約を設定する
  • フィールドの最大長はカラムの長さを同値に設定する
Validationにはいくつか制約があります。
  • Angular、React、BeanValidationの全てのオプションをサポートしているわけではありません。クライアント側とサーバー側で共通するもののみです
  • 正規表現パターンはJavaとJavaScriptで同じ動作をするわけではありません。そのため、設定する場合は片方を微調整する必要があるかもしれません
  • JHipsterは一般的なentityに対しての単体テストを生成します。その際にあなたが必要なValidationルールの情報はないため、生成されたテストがエラーとなることも起こり得ます。その場合は単体テストで使用しているサンプル値を更新してテストをパスするようにする必要があります

Entity relationships

EntityのリレーションシップはSQLでのみ利用可能です これは非常に複雑なテーマなので下記のドキュメントページを参照してください Managing relationships.

Generating a separate service class for your business logic

独立したServiceクラスを持つことで、Spring Rest Controllerを直接使うだけにし、複雑なロジックを集約することができます。 サービス層を持つ(interfaceの有無にかかわらず)ことでDTOを使用することが可能になります。 詳しくは Spring service sub-generatorに記載されていますので、目を通すことをおすすめします。

Data Transfer Objects (DTOs)

デフォルトではJHipster entityはDTOを使いませんが、オプションで作成することができます。
もしサービス層を使用する場合は Using DTOsを確認してください

Filtering

オプションでentityがSQLデータベースに保存する際にフィルタリングをすることができます。以下のドキュメントを参照してください Filtering your entities.

Pagination

もしCassandraを使用してアプリケーションを作成した場合はページネーションは機能しないので注意してください。 もちろん今後のアップデートによって対応される予定です。
ページネーションは GitHubAPIのthe Link header を使用しています。 JHipsterはEntityが生成された時に次の4つのページネーションオプションからサーバー側(Spring MVC REST)とクライアント側(Angular/React)の両方でカスタマイズされたコードを生成します

Updating an existing entity

entityの設定は.jhipster フォルダ内のjsonファイルに保存されています。 そのため、もし既存のentity名を使用してsub-generatorを起動した場合は内容を更新または再生成することができます 既存のentityに対してsub-generatorを実行するときは「
Do you want to update the entity? This will replace the existing files for this entity, all your custom code will be overwritten 」と尋ねられるので、以下の中から回答を選択してください
  • Yes, re generate the entity – entityを再生成します。sub-generatorを実行する際に--regenerateオプションを指定することでスキップ可能です
  • Yes, add more fields and relationships – フィールドおよびリレーションシップの追加のための質問が展開されます
  • Yes, remove fields and relationships– entityから既存のフィールドやリレーションシップを削除するための質問が展開されます
  • No, exit – 何の変更もせずにsub-generatorを終了します
以下のような理由でentityを更新したいケースがあると思います
  • 既存のentityに対し、フィールドおよびリレーションシップを追加 or 削除したい
  • entityを元の状態にリセットしたい
  • JHipsterをUpdateし、新しいテンプレートでentityを生成したい
  • .jsonファイルを更新した場合(フォーマットはsub-generatorが尋ねた質問に非常に近いので、それほど複雑ではありません)
  • .jsonファイルをコピー&ペーストして、コピー元と似た新しいentityを作りたい
TIP: 全てのentityを一度に再生成するのに以下のコマンドが使えます(ファイルが変更された時に質問するようにしたい場合は--forceを削除してください)
  • Linux & Mac: for f in ls .jhipster; do jhipster entity ${f%.*} --force ; done
  • Windows: for %f in (.jhipster/*) do jhipster entity %~nf --force

【JHipster和訳】Creating a Spring controller

はじめに

JHipsterの勉強を兼ねて以下のページを和訳したものです。
自分の理解用なので結構な意訳なので注意してください。
https://www.jhipster.tech/creating-a-spring-controller/

Introduction

このsub-generatorはSpring MVC REST Controllerを生成します
単純なRESTメソッドも生成することができます。
Spring MVC REST Controllerの”Foo”を生成するためには以下のコマンドを打つだけです
sub-generatorはあなたが作成したメソッドについて質問してくるでしょう
質問にはメソッドの名前やHTTP動詞について答えるだけです
そうするとシンプルなメソッドが生成されます

Can we document this Spring MVC REST Controller with Swagger?

訳: このSpring MVC REST ControllerをSwaggerを使ってドキュメント化できますか?
はい、実は既にできています。dev モードの場合,
メニューのAdministration > APIからswaggerのUI 作成されたcontrollerの情報を見ることができます

Can we add security to Spring MVC REST Controllers?

訳: このSpring MVC REST Controller にセキュリティを追加できますか?
はい、Spring Securityの@Securedアノテーションをメソッドに追加するだけです。
そして提供されているAuthoritiesConstants クラスを使用して
特定のユーザー権限にアクセスを制限します

Can we monitor Spring MVC REST Controllers?

訳: このSpring MVC REST Controller を監視できますか?
はい、@Timedアノテーションを監視したいメソッドに追加するだけです

Can we proxy it from our Microservice Gateway dev server?

訳: 開発用のマイクロサービスゲートウェイサーバーからプロキシでアクセスできますか?
はい、 webpack/webpack.dev.jsのproxy欄にサービス名を追加することでできます。

フロントエンド開発のスタート時にやること ( npmコマンド )

よく忘れるのでメモ
npm管理するルートディレクトリを決め、
そこで以下のコマンドを実行し

プロジェクト初期化 ( package.jsonが作成される)

nameとか色々入力を求められるがpackage.jsonに出力される内容なので
あとでいい!ってことで省略

必要なパッケージをインストールしていく

–saveオプションを付けることでpackage.jsonのdependenciesにインストールした内容が追加される。
このpackage.jsonを他環境に持っていって、以下のコマンドを打てば、
package.jsonの内容を読み取って、インストールをしてくれる。

インストールしたものはプロジェクトフォルダ内にnode_moduleというフォルダができ、
そこに展開されている。

開発環境でしか使用しないようなパッケージは以下でインストールする(package.jsonのdevDependenciesに追加)

インストール済みのパッケージ一覧を表示

パッケージを削除する

Spring-socialのtwitterでResourceAccessException

spring-socialのtwitterと連携しようと
/connect/twitterにアクセスしたら
エラーが出てハマったのでメモ

ちなみにapplication.ymlのspring.social.twitterのapp-idとapp-secret指定しただけの状態。

エラー内容

org.springframework.web.client.ResourceAccessException: I/O error on POST request for “https://api.twitter.com/oauth/request_token”: cannot retry due to server authentication, in streaming mode; nested exception is java.net.HttpRetryException: cannot retry due to server authentication, in streaming mode

原因

Stackoverflowに書いてありました。

twitterのディベロッパーサイトでアプリを登録する際にcallbackUrlを指定しないと
このエラーが出るらしい。

アプリ設定画面で”http://localhost:8080″と指定すると
エラーが解消されました。

githubの新規リポジトリ作成~開発開始までの流れ

何回もやる作業じゃないので
いつも手順が頭から抜ける。。。。のでメモ

githubでリポジトリを作成する。

github上の作業なので省略

ローカルリポジトリ作成

git管理したいディレクトリでコマンドプロンプト開いて

コミットするファイルをgitに登録

ローカルリポジトリにコミット

※-mでコミットコメントを指定してます。

gitの設定(省略可)

ユーザ名とemailの設定 コミットログに残るので。気にする人は設定しましょう。
どのリポジトリにもこの設定でいいよ!っていう人は「–global」を付けましょう

githubにpush

リモートリポジトリと紐付け

push!!

はい、これで完了

 

エラーが出る場合

pushでエラーが出る場合、リモートリポジトリと同期が取れてない可能性があるので
以下を実施

リモートの変更を取ってくる

リモートとローカルのコミット履歴情報を統合する

Eclipse起動エラー

STS(spring Tool Suite)落としてさーJavaの開発するぞ―!と起動しようとしたら
思わぬ起動エラーだったのでメモ

「Java was started but returned exit code=13」

sts-error

調べてみると、自分の環境のJavaを8にした時に64bit版じゃないのが入っていたようで、
64bit版を落として再度インストール→Pathを通して起動で解決!