【AWS】API gateway コールエラー：Access to XMLHttpRequest at '' from origin '' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

JavascriptでAPI gatewayを呼び出そうとしたら、こんなエラーが出た。

Access to XMLHttpRequest at '' from origin '' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

メッセージの内容通りだが、これはAPI gateway側でCORS（別ドメインからのアクセス許可設定）がされていないことが原因。

API gatewayのCORSの設定は以下のようなステップになる。

(1) まずはAPI gatewayのコンソール画面で、対象のリソースを選択し、「アクション」ボタンから「CORSの有効化」を選択

(2) 「CORSを有効にして既存のCORSヘッダーを置換」を押下。CORSの有効化処理が実行され、プロセス項目の緑のチェックがつく。

(3) 次に左のメニューから「ゲートウェイのレスポンス」を選択。「アクセスが拒否されました」にチェックを入れ、「編集」ボタンを押下

(4) 赤枠の個所に以下の通り入力する
レスポンスヘッダー：Access-Control-Allow-Origin
値：'*'（シングルクオート、アスタリスク、シングルクオート）

(5) リソースのツリー階層から「/」をクリックし、「アクション」プルダウンから「APIのデプロイ」を選択。以降は通常のデプロイと同じ操作のため割愛。

これでフロントからJavascriptで呼び出せば正常にレスポンスが返ってくるようになります。

Have a nice coding life!

【AWS】EKSのチュートリアルでKubernetes Dashboardに「Http failure response for api/v1/token/refresh: 0 Unknown Error」が表示される場合の対処法

この画面の話。赤枠のコマンドでトークンを表示させて、画面で入力すればOK、と書いてあるのですが、実際にやってみるとDashboardの画面上で以下のようなエラーが表示される

Http failure response for api/v1/token/refresh: 0 Unknown Error

うーん、書いてある通りにやってるんだけどなー。。
調べてみるとstack overflowに以下のコマンドで発行したトークンならいけるとのこと。

kubectl describe secret $(kubectl get secret | grep cluster-admin | awk '{print $1}')

【AWS】API GatewayからStep Functionsを呼び出す際のエラーを解消

API gatewayからLambda関数を直接呼び出して動かす仕組みを作ったけど、処理が大きくなるとAPI gatewayの最大実行時間である29秒制限に引っかかってしまってどうにも立ち行かない。解決方法を調べてみるとStepFunctionsを利用して非同期処理にする方法が最もすっきりできそうだったので実装してみた。

細かい設定方法などについては別サイトにてまとめられている記事がたくさんあったのでそちらを参考に頂いた方が早いかと思います（↓）が、
dev.classmethod.jpdocs.aws.amazon.com

今回はAPI gatewayからStep Functionsを呼び出すテストをした際に直面したエラーの解決方法についてメモしておきたいと思います。

以下、API gatewayからStep Functionsをcallする際のRequest Bodyの基本パラメータなります。

{
   "input": "string",
   "name": "string",
   "stateMachineArn": "string",
   "traceHeader": "string"
}

・ExecutionAlreadyExists
　⇒上記パラメータの内、「name」は毎度別の名前にする必要があるようで、過去にした値を指定するとこのエラーが出ます。「name」を適当に別の値に変えればOK
・InvalidExecutionInput
　⇒「input」パラメータには、Lambda関数に渡す引数を入力しますが、jsonの中にjsonを入れる形になるので以下のようにダブルクオートをエスケープしてあげる必要があるようです。こちらの記述方法に修正すればOK

"input": "{\"first_name\" : \"test\"}"

自分は直面しませんでしたが、他のエラーに関してもあまり親切には書かれていませんが以下に説明があります。
docs.aws.amazon.com

ご参考に！

【Laravel】peginateでLimit句が使えない！ので代替案

Laravelのpaginateメソッドは、元々のクエリで取得した結果に、()の引数で指定した件数で"limit"と"offset"を自動的に設定し処理しています。

(公式のサンプルより)

例えばこの元々のクエリ部分（「DB::table('users')」）で取得する件数を指定したい場合、例えば以下のように記述すれば普通にいけるのかなと思いきや、peginate側で発行されるlimitに上書きされ、自分で書いたlimit句は無視されてしまう。

DB::table('users')->limit(1000)->paginate(15)

では、この元々のクエリにlimitをかけたい場合はどうすればいいのか。検索するとカスタムペジネーションを作るなどの方法が紹介されていたが、大変過ぎるので以下のようなやり方でやってみた。

$subquery = DB::table('users')
                      ->select([
                             row_number() over () as rownum,
                             id,
                             name,
                             email,
                             password,
                      ])
                      ->limit(1000);
$query = DB::table($subquery)->select('*')->where('rownum', '<=', '1000');
$query->paginate(15);

やり方としてはselectに「row_number() over () as rownum（rownum部分は何でもいい）」を追加し、取得した行に連番を振る。その連番を使って行番号を制限したい件数以下に指定して取得し、そのクエリにpeginateをかけるというもの。他にも方法があるかとは思いますが、一応うまくいった実績のある方法として参考に頂ければと思います。

【git】git revert -m 1 マージコミットを元に戻す

gitのコミットを記録を残す形で元に戻したい場合、単純に以下のコマンドで対応できるが、

git revert {コミットID}

それがマージコミットだった場合は、取り込んだ側（1）のマージ前の状態に戻すのか、取り込んだ先（2）のマージ前の状態に戻すのかを「-m {数字}」で指定してあげる必要がある。

まずは「git log」コマンドで対象のマージコミットの内容を見てみよう。

マージコミットの履歴を見てみると、普通のコミットとは違い「Merge」という項目があり、省略化されたコミットIDが記載されている。最初にある赤枠の部分が「1」となり取り込んだ側、2番目の緑枠の部分が「2」で取り込んだ先のコミットIDとなる。マージコミットの場合はこれらのうちどちら側に合わせて元に戻すかを「-m {数字}」引数で指定する。大体は「2」の取り込み先の内容を削除して、「1」の取り込む側のマージ前の状態に戻すケースが多いかと思われるが、その場合は以下のようなコマンドになる。

git revert -m 1 cd1ef4cddbafe053e32d321f56bf0a55f7cec3aa

これでこの時マージしたブランチの内容が削除され、マージ前の状態に戻る形となる。

こちらわかりやすい記事があったので紹介↓↓↓
qiita.com

【Laravel】DB Transactionの実装について

皆さんは自分のプロジェクトでDBのトランザクションを実装されているでしょうか？
案件で色んなクライアント先のプログラムを見ていると、結構全く実装されていないプロジェクトもあったりする。

DB Transactionとは簡単に言うとDBとの接続・操作の途中で何か問題があった場合、途中まで処理した分をロールバック（元に戻す）してくれる仕組みのこと。

例えば以下のようにデータをいったん全件削除してから、新たなデータを登録するような仕組みがあった場合、

public function update($data)
    {
        $this->sampleService->delete();
        $this->sampleService->create($data);
    }

このままだとデータを登録している途中で何かエラーで処理が中断されてしまった場合、削除されたデータは元に戻らず、新しいデータも中途半端に登録された状態になってしまう。

これを以下のようにDB Transactionでくくると、途中でエラーが発生した場合、データを処理を開始する前の状態まで自動でロールバックしてくれる。

public function update($data)
    {
        DB::transaction(function () use ($data) {
             $this->sampleService->delete();
             $this->sampleService->create($data);
        }
    }

確かに挿入データのバリデーションをしっかりと行ってエラーが起こらない仕組みにすることは大前提だし、実際にエラーが発生することはほとんどないとしても、処理中にDBサーバーが落ちてしまったり、ネットワークが途切れてしまったりする可能性は0にはできないワケで、扱うデータが重要であればあるほど、こういった仕組みをしっかりと設計に組み込むことは重要になる。

【Apache】SSL証明書を設定したらサーバーが落ちる

Dockerでhttps通信をしようとapacheコンテナでSSL証明書を設定したらなぜかコンテナごと落ちてしまう。
証明書や鍵の場所、設定ファイルでの指定とか全部あってるハズなのになぜ・・・

そんな時は秘密鍵と証明書の内容があっているか、以下コマンドで確かめてみてください。

# openssl x509 -noout -modulus -in your_domain_com.crt | openssl md5
# openssl rsa -noout -modulus -in your_domain_com.key | openssl md5

これらのコマンドの実行結果が一致していれば秘密鍵と証明書の内容は問題なく、設定ファイルや格納場所など、別の要因に問題があるかと思います。
特に自己証明書でSSL設定をする場合はプロセスも多く、どこで間違っているのかわからなくなることもあると思うので、問題の絞りこみに役立ってくれればと思います。

以上！