suwa3 Ishizuka427

午前中は表参道のネイルサロンに行ってきました。 今回は大人っぽい感じにしてもらった😃 ネイリストさんに飴専門店を教えてもらって 『papabubble(パパバブル)』というお店に、寄り道してみました。 午後はPORTもくもく会に参加してきました。 主に技術blogを書く作業をした。 Qiita記事を書けたので満足です😃 LambdaとPythonでAPI GatewayをエンドポイントにしてSlackに何かを送る

日中はフルリモートでお仕事をしていました。 なんだかんだオフィス外での作業にも慣れてきて 集中力を落とさずに、切り替えて作業できるようになってきた。 結局、慣れなのかな感ある。 自宅だと集中できなかったのは 自宅での仕事自体に慣れていなくて 「自宅では休むもの」 という思い込みが、集中力を削いでいた気がする。 夕方には移動を開始して 職場の食事会に参加しました🙋 実は急遽、代打で参加することになった食事会だったのだけれども とても楽しくお話しすることができて良かったです。 久しぶりに美味しいお刺身たくさん食べて幸せでした😃わーい 今日のBlogは、美味しいお刺身を食べたという自慢です🐟ﾄﾞﾔｧ

JAWS-UG 初心者支部#23 次回のハンズオン勉強会向けのチューター向け予習会 Lambdaのハンズオンに参加しました🙋 来週開催されるハンズオンにチューターとして参加するので その予習会です！ ハンズオンの内容としてはLambdaやAPI Gateway、その他AWSサービス(翻訳機能など)を連携させていく内容です。 音声をリアルタイムで文字に起こす Amazon Transcribe というサービスや、 boto3などAWSサービスをPythonから操作できるライブラリなどを使って 下記のような流れのシステムを構築しました。 『英語音声ファイルをS3にアップ』 ↓ 『それをトリガーにしてLambdaが起動』 『Lambda関数(Python)でtranslate_textを使い翻訳』 ↓ 『Amazon Transcribeで文字に起こす』 ↓ 『文字起こししたものをS3に保存』 AWS内のリソースを使うのであれば IAMロールの設定で組み合わせがどんどん広がるし便利で素晴らしいなぁと感じました これだからAWSやみつきになる😃 Lambdaのハンズオンで、登壇者の方がたまたまFargateを題材にしたLTをやっていたので 帰り際に色々とお話を聞けた。 検証環境を初めて構築する際のコツや、情報収集などについて意見/アドバイスを頂けたの嬉しかったです。 しかも、Pleromaなどマストドン周辺絡みのコミッターの方で マストドンの鯖缶だったり、出身者というだけでも 同郷のような親近感がわく身としては、お話できてとても嬉しかったの。 インフラ寄りの勉強会に参加すると、結構な確率でEKSやFargateを業務で触っている参加者がいて 経験談など聞ける副産物が嬉しいのと同時に、本番環境でのコンテナ化が進んでいるなぁと感じる。

Ansiblejpディベロッパー部 2020.02 - connpass Ansibleの勉強会に参加してきたよ🙋 とても勉強になったので、発表ひとつひとつにテンション上がりながらメモを取りました。 Ansiblejpディベロッパー部 2020.02　メモ 特に印象に残ったフレーズは これからは変化を前提とした設計も行えるようにする です。 まだまだインフラエンジニアとしては駆け出しで 正直 『今までのインフラエンジニアがしてきた仕事』 と、言われてもピンとこなくて それと同じくらいAnsibleの良さもピンと来ていなかったのですが 今までの歴史的経緯などが分かりやすくまとめられていて 流れが理解しやすかったです。 人見知りなので、普段あまり懇親会には参加しないのですが 上司と行ったこともあって、懇親会に顔を出してみました。 愉快で楽しい仲間たち といった感じで、とても気さくに話すことができました！ また機会があれば参加したいです😃

経緯 今週の水曜日にJAWS-UG 初心者支部#23 次回のハンズオン勉強会向けのチューター向け予習会へ参加することになりました。 Lambdaは、花屋時代にローカル環境でテスト実行してみてQiitaに上げたきりだったので その時の記事 => Pythonでaws-sam-cliをローカル実行するまで もうすこし踏み込んで (実用性を意識しながらLambdaを触ってみたいなぁ) と、思った＆予習も兼ねて 『API GatewayをエンドポイントにしてLambdaを起動しSlackに何かを流す』 というのをやってみました。 API Gatewayをエンドポイントにした実行を試したいと考えた理由として 外部から連携したい場合、HTTPリクエストを受けて発火させる場面が多くあるので これから効率化を考える際に、よく使いそうな手法として要領を掴んで慣れておきたかったからです。 逆にAPI Gatewayを使わないパターンとして AWS内のサービスを使うときは、わざわざエンドポイントを外に置かなくても AWSのサービス同士はだいたいIAMロールを使えばAWS内でセキュアに連携できます。 流れ 流れとしては SlackでIncoming Webhookの設定をしてWebhook URLを控えます。 Lambdaのコンソール上で関数を作成して Webhook URLをその関数内で使用し、連携させます。 API Gatewayのコンソール上でLambda関数を紐付けて エンドポイントをデプロイすると、発火用のURLが発行されます。 そのURLにアクセスする(HTTPリクエストが届く)と それを合図にしてLambdaが起動して SlackのBotが起動する、という仕組みです。 Slack 1. Incoming Webhookの設定 2. Webhook URLを控える Lambda 1. 関数の作成 2. 関数内にWebhook URLを仕込む API Gateway 1. Lambda関数の紐付け 2. エンドポイントをデプロイして発火用URLを控える (例えば)ブラウザなど エンドポイントURLにアクセスしてみる Slack Botが起動する Slack Incoming Webhookの設定 まずはSlackの設定です。 『Slackをカスタマイズ』を選択します。 左上の『MENU』から 『App 管理』を選択します。