AWS関連のことを調べてみた2020年06月28日

AWS関連のことを調べてみた2020年06月28日
目次

Amazon Linux2にDockerをインストールする

Docker初心者の私がAmazon Linux2(AMI)イメージから作成したEC2インスタンスに
Dockerをインストールし色々と触ってみたので備忘録として残します。

### ・インスタンスで使用するパッケージを更新する
すでに実施済みのインスタンスであれば不要です

実行コマンド

“`
sudo yum update -y
“`
実行結果

“`
・・・
Updated:
amazon-linux-extras.noarch 0:1.6.11-1.amzn2 amazon-linux-extras-yum-plugin.noarch 0:1.6.11-1.amzn2
ca-certificates.noarch 0:2019.2.32-76.amzn2.0.2 cloud-init.noarch 0:19.3-3.amzn2
kernel-tools.x86_64 0:4.14.181-140.257.amzn2 python.x86_64 0:2.7.18-1.amzn2
pytho

元記事を表示

TerraformでECS FargateなコンテナにFireLensを適用する

# はじめに
FargateのログはデフォルトだとCloudWatch Logsに収集される。
このままでも良いのだけど、加工したり転送したりと色々やりたいときに手間にならない方法としてFireLensが使えるらしいので、試してみる。

[以前書いた記事](https://qiita.com/neruneruo/items/d5e58b4013debdf9ebbe)をベースに、以下の記事と同様のことをTerraformで実装する。

【Developers.IO】[[アップデート] ECS/Fargateでログ出力先をカスタマイズできる「FireLens」機能がリリースされました](https://dev.classmethod.jp/articles/ecs-firelens/)

# 事前準備
上記の記事の構成でFireLensを使うのに必要なのは以下。
まずはこれを用意していく。

– ログの書き込み先となるFirehoseの準備
– ECSのタスクロール(Notタスク実行ロール)へのFirehoseへの書き込み権限のアタッチ
– Firehoseに対する書き込み先のS3の書き込

元記事を表示

(自分用)Flask_AWS_1(AWS仮想環境にPHP,MySQL,phpMyAdmin,Pythonのインストール)

# 項目
1. PHPのインストール
2. MySQLのインストール
3. PHPMyAdminのインストール
4. Pythonのインストール

# 1.PHPのインストール
“`bash:ターミナル
# まずLinux仮想マシンに接続、ここを覚えてないなら1つ前のやつを見て
$ ssh -i ~/.ssh/FirstKey.pem ec2-user@(パブリックIP)

# 管理者権限に変更
$$ sudo su

# PHPをインストール
$$ yum install -y php

# PHPの設定を変える前にバックアップを取っておく
$$ cp /etc/php.ini /etc/php.bak

# viでPHPの設定変更
$$ vi /etc/php.ini
“`

– `:set number`で行番号を表示
– `:520`で520行目に移動
– `i`にて記述モードにし、`error_reporting = E_ALL & ~E_DEPRECATED`という行を、`error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTI

元記事を表示

Route53 で RDS endpoint の短縮名を登録する

[Aurora MySQLのtextをEC2 MariaDBレプリカでMroonga全文検索](https://qiita.com/masudakz/items/1afafcca1c01d8b9c276) で言及した件の続編。

> レプリカ設定 MASTER_HOSTは60文字以下にする必要がある。Amazon RDSのendpointは長くなりがちで、東京リージョンではcluster名に使えるのはわずか5文字。Route53を使って短い別名を登録しておくのが本来だろう。

上記記事では5文字のクラスタ名にしたが、実際にRoute53を使う手順を示す。

## AWSコンソール手順

1. Route53
1. ホストゾーン
1. ホストゾーンの作成
– **ドメイン名:** `vpc.example.com`
– **コメント:** `for devlop1` など対象VPCを示すコメント文字列を入れる(強く推奨)
– **タイプ:** Amazon VPCのプライベートホストゾーン
– **VPC ID:** 対象VPCを選択

元記事を表示

API Gateway + LambdaでS3にある画像を表示

## 概要

* API GatewayとLambdaでS3にある画像を返却する
* クライアント側からは単にURLにアクセスしたら画像が表示されるように見える
* S3をpublicにすることなく画像を表示することができる (限定公開などが可能)
* pythonでの実装

仕様がよく分からずハマったのでメモを残します.

## やること

1. Lambdaの作成
2. API Gatewayの作成

S3は作成済みとします.

## 1. Lambdaの作成

Lambdaを適当な名前で作成します.ここでは`get_image`としました.

また,ランタイムはPython 3.8を選択しました.

![スクリーンショット 2020-06-27 22.24.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/401124/77615c8f-9cac-814a-7709-f5702e3b44dc.png)

そして関数コードに![スクリーンショット 2020-06-27 23.07.20.png](

元記事を表示

AWSのEC2インスタンスの監視をzabbixへ統合監視するために、zabbixのLLD(ローディスカバリー)機能を使ってみた!

LLDとは?
>ローレベルディスカバリにより、コンピューター上の種々の要素に対してアイテム、トリガー、グラフを自動的に作成できます。例えば、Zabbixは使用しているマシン上のファイルシステムまたはネットワークインターフェースの監視を自動的に開始できます。そのために、各ファイルシステムまたはネットワークインターフェースに対して手動でアイテムを作成する必要はありません。さらに、定期的に実施されるディスカバリの実際の結果に基づいて不要な要素を自動的に削除するように、Zabbixを設定することができます。
[zabbix公式ページ](https://www.zabbix.com/documentation/2.2/jp/manual/discovery/low_level_discovery)

# 目的
今回の目的は、AWSのEC2のリソース情報の監視をzabbixに連携することとします。
その中でLLD機能を使って、アイテムとトリガーの自動作成を実施してみます。

# 手順
以下の手順で実施していきたいと思います。

1. 監視対象のEC2インスタンスのメトリクスの確認。
1. zabb

元記事を表示

【AWS;Lambda入門】第三弾;Linebotなじゃんけんゲームで遊ぶ♬

今回は、apigatewayを利用したnode.js@Lambdaでじゃんけんゲームを作ってみた。
環境構築やプログラムなどは、全て以下の参考①~④を参考に進めた。
だいたい、最初の①と②でLinebotが動く。そして③と④でLambda版のLinebotが動いた。筆者も言っているように感動ものである。
ちなみに、ほぼ1日でLinebotが動くようになった。
したがって、コードのほとんどは参考のまんまであることをお断りしておきます。
【参考】
①[LINEBotをみんなで作ろう〜環境構築編〜【GWアドベントカレンダー1日目】](https://qiita.com/inoue2002/items/a87df2b520f8b6e37f42)
②[LINEBotをみんなで作ろう〜おうむ返しbotを作ろう編〜【GWアドベントカレンダー3日目】](https://qiita.com/inoue2002/items/dcf40d5ebfe2454796fa)
③[LINEBotをみんなで作ろう〜レイヤーとAPIgateway設定編〜【GWアドベントカレンダー7日目】](https://qiita.

元記事を表示

Amazon CloudWatch Syntheticsで簡単監視入門

## はじめに

皆さん運用監視してますか?
運用監視はいろいろと手間がかかるので敬遠されがちなんですが、運用監視の仕組みがないと、何かトラブルが起こっても気が付きません。
なので、システムを長期間安定的に稼働させるためには、運用監視の仕組みが不可欠ですよね。
今回はWebサイトの死活監視で利用できるAmazon CloudWatch Synthetics(以下Synthetics)について紹介します。

## Amazon CloudWatch Syntheticsとは

詳細な情報は公式のリファレンスを見て頂くとして、ざっくりと概要の説明をします。
Syntheticsを使うとWebサイトやAPIの定期的な死活監視をすることができます。
例えば、正常にWebページを取得できるか、APIを正常に呼び出すことができるか、などを定期的にチェックすることが可能です。

しかも、チェックする部分はLambdaのコードになっているので、自分なりにカスタマイズすることができます。
例えば、このAPIが正常に呼び出されたらこういうレスポンスが返ってくる、というのが決まっていれば、自分でプログラム

元記事を表示

PrometheusとGrafanaでRaspberry Piを監視

Raspberry PiにPrometheusとGrafanaをインストールして、Raspberry Pi自身を監視してみました。

# 環境

Raspberry Pi 3
Raspberry Pi OS(2020-05-27版)

# Prometheusのインストール

Raspberry Piの公式リポジトリから導入できます。
`prometheus`がPrometheus本体、`prometheus-node-exporter`はOSのメトリクス情報を取得するものです。

“`console
sudo apt install prometheus prometheus-node-exporter
“`

インストールが完了すると、すでにサービスとして起動した状態となります。
2020/6/27時点でインストールされたバージョンは以下の通り。最新バージョンはPrometheusが2.19.2、Node exporterが1.0.1なので少し古そうですね。

“`terminal
pi@raspberrypi:~ $ prometheus –version
prometh

元記事を表示

【反省】新卒1年目がAWSの認証キーを流出させてしまった話

# はじめに
私は新卒1年目で神戸のSIerに勤めています。
この度AWSキーを流出してしまうという、
初心者であるもののエンジニアとして恥ずべき行為をしてしまったので
2度とこのような失態を踏まないように再発防止の意味を兼ねてここに記そうかと思います。
また今後AWSキーを流出してしまうことを完全に防ぐことは難しいかと思いますが、
今までAWSキーを無意識に扱っていた方の認識を改めるきっかけになればと思います。

# 何をしたのか
ことが起こったのは2020年6月24日。
Github Actionsを利用して、CI機能を実装しようとしていた時のこと。
やろうとしていたことはGithubのリモートリポジトリにpushされたときに、
AWS S3に公開ファイルをデプロイするというものでした。
Actionsにはワークフローとして、AWS認証キーを設定する処理が含まれていたので、
アクセスキーとシークレットキーを記述する必要がありました。
例としては下のようなイメージです。

“`yaml

name: GithubActions_test
on:
push:
br

元記事を表示

S3に保存されたwavファイルをLambdaでGoogle Cloud Speech-to-Textを使って文字起こしする

# S3に保存されたwavファイルをLambdaでGoogle Cloud Speech-to-Textを使って文字起こしする
## はじめに
以下リンク記事を参考に、S3に保存されたwavファイルをLambdaでGoogle Cloud Speech-to-Textを使って文字起こしをやってみたのでまとめておきます。

[S3 + ElasticTranscoder + Lambda + Google Cloud Speech-to-Text APIで、動画の音声を自動でテキストにする](https://qiita.com/inoue37/items/e526cc8d389808863943)

?完全なる上位互換なので、私の記事は読む必要ないかと。

## 1. S3の作成
特別なことはしないです。
1-1. 適当なバケット名、リージョン(私は東京)で次へ
1-2. オプションの設定はノータッチ
1-3. アクセス許可の設定もノータッチ(パブリックアクセスをすべてブロック)
1-4. 確認

## 2. ローカルでGoogle Cloud Speech-to-Text APIをイン

元記事を表示

AWS Lambda から Amazon EFS へのアクセス

AWS Lambda から Amazon EFS へアクセスできるようになったとのことでやってみた。

これによりLambda の仕様上、512 MB という仕様制限がありましたが、これを超えるファイルの操作が可能になります。

また、S3は結果整合性ですが、EFS を利用することによりデータの一貫性が保てることができます。

[新機能 – Lambda関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda](https://aws.amazon.com/jp/blogs/news/new-a-shared-file-system-for-your-lambda-functions/)

#1.セキュリティグループの作成#

##AWS Lambda 用セキュリティグループの作成##

|セキュリティグループ||
|—|—|
|インバウンドルール| なし|
|アウトバウンドルール|すべてのトラフィック|

##Amazon EFS 用セキュリティグループの作成##

|セキュリティグループ||
|—|—|

元記事を表示

AWS SAA(ソリューションアーキテクトアソシエイト)に合格するまでにやったこと

## SAA(ソリューションアーキテクチャアソシエイト)資格とは

[AWS認定試験](https://aws.amazon.com/jp/certification/)は基礎コース、アソシエイト、プロフェッショナル及び専門知識を分けています。アソシエイトは役割によって「アーキテクト」、「運用」、「開発者」を分けています。ソフトウェアエンジニアですが、一番人気の「ソリューションアーキテクトアソシエイト」をチャレンジしました。

認定によって検証される能力は下記の通りです。([AWS公式ページ](https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/)より抜粋)

> 認定によって検証される能力
>
> – AWS のテクノロジーを使用して安全で堅牢なアプリケーションを構築およびデプロイするための知識を効果的に証明すること
> – 顧客の要件に基づき、アーキテクチャ設計原則に沿ってソリューションを定義できること
> – プロジェクトのライフサイクルを通して、ベストプラクテ

元記事を表示

AWS Lambdaのリソースベースポリシーのサイズが上限に達して困った話

## はじめに
AWS samを利用しAPI gateway + Lambdaの構成を作成していたのですが、Cloudformationの変更セットを実行中に以下のエラーを取得してしまいました。

“`
The final policy size (20857) is bigger than the limit (20480).
(Service: AWSLambda; Status Code: 400; Error Code: PolicyLengthExceededException;
Request ID: xxxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx)
“`

このエラーが示す内容としては、 **Lambdaのリソースベースポリシーがサイズ上限に達した** ということを示しています。
この状態になるとAPIのメソッドの統合リクエストのタイプにこのLambdaを指定することが出来なくなります。

## 調べてみて
いくつか記事を漁っていると、以下の記事を発見しました。
[Lambda エラー「最終ポリシーサイズが制限を超えています」を

元記事を表示

【AWS SDK for Java】S3クライアントにリトライポリシーを設定する

ジャストほしい情報が日本語でなかったのでドキュメンテーションする。
AWS SDK for Javaを利用してS3にファイルをアップロードする際に、やや詳細な設定を付加する。

# 目次
– リトライ周りのケース概略
– とりあえず実装してみる
– 関連クラスの整理
– その他
– 参考

# リトライ周りのケース概略
AWS SDK for Javaを使って、ローカルにあるS3にファイルをアップロードしたい。
そして、AWS側の都合で通信断となったり諸事情により正常稼働できないケースを見越して、AWSクライアントにリトライポリシーを仕込みたい。
今回は、AWS SDK for Javaに含まれる `AmazonS3` オブジェクトのシングルトンを返すユーティリティクラスを用意する。

なお、本記事では自分が特に困った「クライアント生成時のオプション設定」にフォーカスを置く。そのため、ファイルアップロード前後の処理関連の説明は省略する。

# とりあえず実装してみる
シンプルなクライアントオプションを詰めたクライアントを構築する。
流れとしては、リトライポリシーインスタンス、クライアン

元記事を表示

【AWS】AmazonLinuxにてZabbixマネージャー構築(AWS側設定)

# はじめに
以前、下記のQiita記事を投稿しました。
[【AWS】AmazonLinuxにてZabbixマネージャー構築(OS側設定)](https://qiita.com/satton6987/items/ba3d6ddc7cf289dd0405)
こちらの記事ではOS側の設定を紹介しています。

今回は、AWS側での設定についてアウトプットしていきたいと思います。

# 自宅環境

| 項目 | 説明 |
| —- | —- |
| 自宅PC | Windows10 |
| ターミナル | TeraTerm |

# 基盤環境

| 項目 | 説明 |
| —- | —- |
| OS | Amazon Linux 2 AMI (HVM), SSD Volume Type |
| Size | t2.large |
| DB | MySQL 5.7.26 |

**※DBはRDSを外付け**
※AWSのベストプラクティスに沿って、作業用IAMユーザーにて作業
(ルートユーザーには多要素認証設定済み)

# 構成図

元記事を表示

【AWS】サーバレスで Hello, World! を実行するまでのチュートリアル

通常、プログラムのコードを実行するためには Linux などのサーバを立てて、初期設定して、実行環境をインストールして・・・と手間が多いです。
しかし、AWSには **Lambda** という、上のようなサーバ側の準備を意識することなくコードを実行でいるサービスがあります。

このチュートリアルでは、サーバレス≒サーバの構築なしでコードを実行し、 “Hello, Wolrd!” を返すまでの手順を学びます。

## Lambdaコンソールを起動
[AWSマネジメントコンソール](https://console.aws.amazon.com/console/home)にアクセスし、AWSアカウントでまずはログインします。

ログインできたら「サービス」をクリックし、検索ボックスに「Lambda」と入力します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/364501/3f4ddc36-85c4-c14f-838f-3f385290e1a9.png)

これでLambdaコンソールへアクセ

元記事を表示

DjangoをLambdaを使ってサーバレスにデプロイする

DjangoをAWS Lambdaにデプロイできました。Serverless Frameworkを使うと簡単です。
URLとレポジトリはこちらです。
[https://django-sls-helloworld.umihi.co/](https://django-sls-helloworld.umihi.co/)
[https://github.com/umihico/django-sls-helloworld](https://github.com/umihico/django-sls-helloworld)

slsのデフォルトプロジェクトを作成し、[f1a13ba](https://github.com/umihico/django-sls-helloworld/commit/f1a13ba)
動作確認したらカスタムドメインをプラグインをインストールします。[0970afe](https://github.com/umihico/django-sls-helloworld/commit/0970afe1228ceeb646042c0c2a1012a2c44646a3)
API

元記事を表示

[Terraform]AWS事始め

# 概要
TerraformでAWSリソースを扱い始めるためのチュートリアルのような内容を記載します。
ハンズオンライクに、terraformコマンドでEC2インスタンスを生成できることを本記事でのゴールとします。

# 前提
– MacOSである
– Homebrewを導入している
– AWSアカウントを保持している

# 手順
## 1. セットアップ
### 1.1. AWS IAMユーザー払い出し
`terraform`コマンドで、AWSとのやりとりを行うためのユーザーを作成します。

※以下の画面キャプチャは執筆時点のものです。今後変更される可能性がある点について承知おきください。
AWSマネジメントコンソールにログインし、IAMへ移動->「ユーザーを追加」をクリックします。
スクリーンショット 2020-06-21 0.45.44.pngKops環境(EC2)でbastionのSSHポート番号を後から変更した

##はじめに
勉強用の検証環境で、Kopsでクラスターをセットアップした後に、(kopsコマンド実行時に作成された)bastionのSSHポート番号を変更しようとしたところ、少しはまってしまいました。対応した内容をメモで残します。(検証したのは今年の3月ごろ。)
あくまで個人の作業メモです。ご自分てプロジェクト等の環境で対応される場合には、公式のドキュメント等も確認の上、事前に検証して手順を確立してから対応されることをおすすめします。

## 状況
何も考えずに対応してSSHがつながらなくなり、困惑した経緯。(恥をさらすところではありますが、、)

– kopsでクラスターを作成後、bastionのポート番号を変更したいから変えなくちゃ!、とPC(Win)のTeratermを起動
– 2つTerminalを起動し、/etc/ssh/sshd_config を書き換え、sudo sshd -tとsudo service sshd restart を実行
– Teminalが2つとも落ちる!(当然だ!)

状況把握のログ

– 端末から、ELBのポート接続を確認すると、変更前のポートでは接

元記事を表示

OTHERカテゴリの最新記事