AWS関連のことを調べてみた2021年02月24日

AWS関連のことを調べてみた2021年02月24日
目次

AWS CLI 2.1.28 で ‘ascii’ codec can’t encode characters

CodeBuild から AWS CLI の “`aws lambda update-function-code“` を実行したら、2 バイト文字に関するエラーがでました。

AWS CLI のバージョン 2.1.28 で発生しており、一つ前の 2.1.27 では発生していませんでした。

“`
aws –version
aws-cli/2.1.28 Python/3.8.8 Linux/4.14.214-118.339.amzn1.x86_64 exec-env/AWS_ECS_EC2 exe/x86_64.amzn.2 prompt/off
“`

“`
aws lambda update-function-code –function-name $LAMBDA_FUNCTION_NAME –image-uri $REPOSITORY_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION
{
“FunctionName”: “abcdefg”,
“FunctionArn”: “arn:aws:lambda:ap-northea

元記事を表示

AWSのAI/MLサービス一覧(2021年2月現在)

AWSに存在するAI、機械学習関連のサービス(2021年2月現在)を整理してみました。

## 自然言語
### Amazon Translate
深層学習技術による言語翻訳サービス。
55言語の間での翻訳をサポートしており、日本語にも対応している。カスタム用語集を使用することで、特定の組織や分野、業界における独自の用語も翻訳することが可能。

### Amazon Comprehend
自然言語のテキストファイルからキーフレーズ・場所・人物・ブランド・イベントの抽出や、テキストが肯定的か否定的かの判定、またテキストファイルをトピックごとに自動的に整理することが出来るサービス。
Amazon Comprehend AutoML機能を用いて、組織のニーズに合わせて独自にカスタマイズしたエンティティや分類モデルを構築することも可能。

### Amazon Comprehend Medical
自然言語の医療データから、健康状態や投薬、服用量など様々な情報を抽出するサービス。
医療情報のプライバシーやセキュリティについて定めたHIPAA法に対応している。

### Amazon Text

元記事を表示

40代おっさんEC2を勉強して内容を

#40代おっさんEC2を勉強してみた

##本記事について
本記事はAWS初学者の私が学習していく中でわからない単語や概要をなるべくわかりやすい様にまとめたものです。
もし誤りなどありましたらコメントにてお知らせいただけるとありがたいです。

##目標
EC2の理解を深める。

##EC2とは
Amazon Elastic Compute Cloud (Amazon EC2) は、安全でサイズ変更可能なコンピューティング性能をクラウド内で提供するウェブサービス
 わかりずらい・・・
つまりAWSの仮想サーバーサービスのことみたいです。

##EC2の前提知識
###仮想サーバーとは
まずはサーバーを説明します。
サービスを提供する側のコンピューターのことを指します。
これは簡単ですね
では仮想サーバーとはそのサーバーの上に仮想的にサーバーがあるものとして作り、仮想サーバーとして運用するもの見たいです。
つまり一つのコンピューターに仮想的にサーバーを何個も作ることができます。

###サーバーに必要なもの
####OS
これは聞いたことがあるのでないでしょうか?
代表的なものとしてWi

元記事を表示

【初学者向け】S3整合性モデルのアップデートについて【AWS SAA】

こんにちは。

現在、クラウドエンジニアもしくはクラウドサービスを利用したサービスに携わりたい一心で、目下AWS SAAの取得に向けて勉強中です。

最近になってようやく模擬試験を解き始めて、アウトプットとインプットを繰り返す毎日ですが、参考書の出版時から現在に至るまでにサービスの特性が変わっている事がよくあります。

今回は、AWSの主要サービスであるS3の整合性モデルについて備忘録的に書き記したいと思います。

〜結果整合性モデルから強い整合性モデルへ〜

従来のS3の整合性モデルは結果整合性モデルを採用しており、オブジェクトをアップロードしてもタイミングによっては古いデータを読み込んでしまう可能性がありました。

しかし、S3のアップデートが実施されたことにより、2020年12月3日より強い整合性モデルへと変更になりました。

これにより、今までと違ってアップロードをして書き込み処理で更新または削除を行った場合でも即時に結果が反映されるようになりました。

〜参考書ベースで勉強している方へ〜

Udemyやその他Webサービス上での学習ツールを使

元記事を表示

【GAS x AWS】kintoneのゲストユーザーを自動追加したい~GASとAWSを連携してメールを自動処理する~【kintone】

#はじめに
kintoneでシステムを開発したのですが、同システムのゲストユーザーアカウントを希望する人(メールでアカウント申請した人)に自動発行したいと思い立ちました。

開発したシステム: https://qiita.com/Lastonemile/items/65b9102c868e09b3248e

そこで、GAS(Google Apps Script)とAWSを組み合わせて、自動発行することにしました。

#出来たこと
指定した条件の受信メールを自動取得し、同内容をAWSへ送信しAWSでその内容に沿ってゲストユーザー登録を自動化しました。

#GASの設定
これまで全く利用したことはありませんが、GASの設定はググりながらで比較的すんなり行えました。(ベースはjavascriptのようです)

“`
// 初期設定
const HOOK_URL = ‘https://xxxxxxxxxxxx’; //AWS(api gateway)エンドポイント

function main() {
let after = parseInt(((new Date()).getTime(

元記事を表示

Amazon Kinesis とは

## 勉強前イメージ

ストリーム処理って感じ
でもなんか種類いっぱいあるみたい

## 調査

### Amazon Kinesis とは

ストリーミングデータをリアルタイムで収集、処理が出来る
フルマネージド型の分析サービスです。
また、スケーラブルでストリーミングデータのサイズに上限はありません。

### メリット

– リアルタイム

ストリーミングデータをリアルタイムで取得、バッファ、処理を行います。

– 完全マネージド型

データをストリーミングするために必要なインフラやストレージは準備する必要はありません

– スケーラブル

ストリーミングデータに合わせてスケーラブルを行います

### Amazon Kinesis の機能・サービス

#### Kinesis Data Streams

リアルタイムなデータストリーミングサービスです。
収集データはミリ秒単位で処理することができます。
リアルタイム分析もダッシュボード上で管理でき、異常検知も行います。
登録されたデータは複数のアプリケーションから参照することが出来ます。

#### Kinesis Data F

元記事を表示

LaravelをコンテナにしてLambdaでデプロイするのが超簡単になった2021年

[昨年同じ記事](https://qiita.com/umihico/items/64fcf159f68ebd866170)を書きましたが、完全に過去の遺物と化しており、現在の手順はまるで違います。LaravelをコンテナにしてLambdaにデプロイする記事は見つからないので、書きました。

デモサイトとgithubは以下です。
https://w0qw04g8sj.execute-api.ap-northeast-1.amazonaws.com/
https://github.com/umihico/laravel-lambda-docker-bref

### curlでプロジェクトが作成できる

パスが動的に設定可能で、そのままアプリ名となります。この場合`larademo`というフォルダが作成され、配下に展開されます。

“`bash
curl -s https://laravel.build/larademo | bash
“`

### docker-composeがデフォルトでパッケージされている。

即座にコンテナ内でcomposer, phpコマンドを使わせてくれ

元記事を表示

ECSのタスク定義で、コンテナ間接続のエラーが起きた時の対処法

ECRにプッシュしたDockerのコンテナをECSでタスク定義を行い、いざタスクの実行を行うとステータスが“STOPPED“となる。

何十回やっても以下のようなエラーが起きる。

>
Cannot link to a non running container

ちなみにコンテナの設定は以下のようになっている。

“`docker-compose.yml
version: “3.8”
services:
app:
build:
context: .
dockerfile: ./docker/php/Dockerfile
args:
– TZ=${TZ:-Asia/Tokyo}
ports:
– ${APP_PORT:-8000}:8000
volumes:
– ./backend:/work
– ./logs:/var/log/php
– ./docker/php/php.ini:/usr/local/etc/php/php.ini
worki

元記事を表示

CodeCommit(git)でpushを取り消す方法

# はじめに
タイトルの通りです。忘れがちなので自分用のメモです。
# やること

CodeCommitの画面でコミットを選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/685335/2bb1dca0-589f-e2ba-b11a-4dded86e5335.png)

ブランチを選択して**戻りたいコミット**のIDをコピーします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/685335/3203dcd9-2f4d-b52b-ef95-e351cda45d72.png)

あとは以下のコマンドを実行します。

“`
git push -f origin <コピーしたコミットのID>:branch名
“`

CodeCommitを確認すると、指定したコミットまでさかのぼっていることがわかります。
“`revert“`コマンドとかを使うと、情報を残せるらしいです。

元記事を表示

AWSのコスト配分レポートをいじり倒し、料金を超絶見える化する

# はじめに
AWS料金、どこにどれだけかかってるか、とても分かりづらくないですか?
CostExplorerを使えばそれなりに可視化できますが、例えばEC2。
EC2インスタンス料金は見えますが、そこにアタッチされたEBSやそのEBSスナップショット、そのEC2で発生したデータ通信料金などは、すべてバラバラでしか確認できません。
これらすべて、発生元のEC2に紐づけて見たいと思ったことはないでしょうか。

Auroraもインスタンス料金は見えますが、ストレージ、I/O、バックアップなど、そのインスタンスで発生している料金は紐付けて確認したいですよね。

会社の取締役から「どのサーバでいくら、どのシステムでいくら、かかってるんだ?」
と聞かれ、ぐぬぬとなってしまったのをきっかけに徹底的に見える化することにしました。

# ゴール
先に完成版をお見せしたいと思います。
今回はコストを抑えたかったため、DBは使わず単純CSVファイルとAWSのBIサービスであるQuickSightを使いました。
(CSVファイルをQuickSightにロードしています)

例えば、ある月のリソース単位の料金

元記事を表示

AWS デプロイ時のエラー対応

## 前提
自分がAWSへのデプロイ時に遭遇したエラーの備忘録です。
EC2 の作成やRDSの設定などは既に済んでいる
Unicorn と Nginx を起動した時に出たエラーになります。
### エラー内容
production.log

“`bash
F, [2021-02-19T00:20:57.099109 #17387] FATAL — : [333532cb-cda3-4d39-9c25-6e18a14a0f6e]
[333532cb-cda3-4d39-9c25-6e18a14a0f6e] ActionView::Template::Error (The asset “application.css” is not present in the asset pipeline.
):
[333532cb-cda3-4d39-9c25-6e18a14a0f6e] 5: <%= csrf_meta_tags %>
[333532cb-cda3-4d39-9c25-6e18a14a0f6e] 6: <%= csp_meta_tag %>
[

元記事を表示

AWS Route53を設定した後にpingがUnknown hostになったら

## 症状

“`bash
% ping 取得したドメインで設定したRoute53のレコード名

ping: cannot resolve 取得したドメインで設定したRoute53のレコード名: Unknown host
“`

## 解決策
“`
% sudo killall -HUP mDNSResponder
“`
参考記事 : [OS X で DNS キャッシュをリセットする](https://support.apple.com/ja-jp/HT202516)

### エラーまでの流れ
1. AWSでドメインを取得し、Aレコードを作成
2. WebサーバーのIPアドレスと紐付け
3. 紐付けたWebサーバーにpingで疎通確認
4. とある理由からAレコード名を変更
5. 変更したレコード名で再度ping
6. 上記の症状

### 解決までに確認したこと
1. ドメイン名(レコード名)の正誤
2. 更新したドメイン名でブラウザからアクセスの可否
3. IPアドレスでのpingの可否
3. nslookupコマンドが有効

## 原因
[OS X で DNS キャッシ

元記事を表示

GitLabで使用するオブジェクトストレージをS3からMinio+EFSに移行する

# はじめに

GitLabではマージリクエストのdiffやGitLab CIジョブのログなどのデータをS3といったオブジェクトストレージに保存することができます。

ファイルサイズが大きい際レスポンスが遅い問題に直面したのでS3からMinioへの移行を検証しました。MinioにはEFSを使用して可用性を確保しています。

# 環境

EKS 1.16
Helm 3.4.0
Helmfile 0.122.0
GitLab Helm Chart 4.8.4
kube2iam Helm Chart 2.5.0
ALB Ingress Controller Helm Chart 0.1.11
NGINX Ingress Controller Helm Chart 1.39.0

# 手順

EKSクラスタやS3バケットは構築済みであることを前提とします。

以下の流れで実施します。

1. S3使用のGitLabでバックアップ
2. Minio用意
3. Minio使用のGitLabでリストア

## 0. 前準備

Kubernetesリソースをデプロイしていきます。

まずはGitLa

元記事を表示

この令和時代にサーバーレス知らないのはヤバみ

## はじめに

皆さま。ごきげんよう。
僕が愛して止まないデヴィ夫人の冒頭挨拶から本記事はスタートすることにします。

タイトルが「見たらわかる失礼なやつやん」で大変申し訳ないと思っております。よくあるただの煽り文句を使いました。
僕も最近までサーバーレス知りませんでした。

## Serverless とは

サーバー管理が不要なアーキテクチャです。

自前でサーバーを用意/管理するとなると様々な課題と向き合うかと思います。例えば、OS設定や容量管理、負荷管理、ランニングコスト、アイドル時のリソース管理、アクセス制御、セキュリティ管理などキリないですが、サーバーレスアーキテクチャを利用することで、そんなものは気にしなくて良くなり、プログラムロジック(本質)の開発に注力することができるかと思います。熱盛ですね。

現代では、モノリシックよりもマイクロサービスなどの疎結合な特性を持つアーキテクチャが注目されていると思いますが、その一部として、サーバーレスアーキテクチャを導入するという形も考えられると思います。

## [Serverless Framework](https://ww

元記事を表示

AWSのElastic IPアドレスを解放してインスタンスを停止する手順

# はじめに

昨年5月に作った転職活動用のアプリがAWSにデプロイしたままだったので、インスタンスの停止作業を行いました。
久々にAWSを触ったら、基本的な記憶すら無くなっていたので、作業がてら備忘として残しておきます。

**<作業順序>**
1. [**Elastic IP アドレスの関連付け解除**](#elastic-ip-アドレスの関連付け解除)
2. [**Elastic IP アドレスの解放**](#elastic-ip-アドレスの解放)
3. [**インスタンスの停止**](#インスタンスの停止)

なお、バージョンが変わると手順が異なる部分があるようですので、うまくいかなかったら下記の公式サイトを参照してください。
・[Elastic IP アドレスの関連付け解除](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-eips.html#disassociate-eip)
・[Elastic IP アドレスを解放する](https://docs.aws.amazon.com/ja_jp/vpc/lat

元記事を表示

[Tips] Systems Manager Run Command (プライベートサブネット)

# はじめに
Systems Manager Run CommandをプライベートサブネットのEC2インスタンスに対して実行する際にハマったので備忘録。
※あくまで動作確認につき権限周りガバガバ。。。
#前提
・プライベートサブネット上にSSMエージェントがインストールされたEC2インスタンスが存在すること。
 [SSMエージェントについてはこちら](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent.html)
・コマンド出力にS3を使用する。

#手順
1. EC2に割り当てるIAMロールにAWS管理ポリシー「AmazonEC2RoleforSSM」をアタッチする。

2. 実行するIAMユーザーに下記のポリシーをアタッチする。
 AWS管理ポリシー「AmazonEC2FullAccess」
 AWS管理ポリシー「AmazonSSMFullAccess」

3. VPCエンドポイント作成 (←ここでハマった)
下記の4つのエンドポイントを作成。
 「com.amazonaws.a

元記事を表示

S3バケットポリシーを使用した VPC エンドポイントからのアクセス制御

# S3バケットポリシーを使用した VPC エンドポイントからのアクセス制御

S3は便利で安くて皆さんよく利用されているストレージサービスだと思います。

S3セキュリティ設計の一環として、バケットポリシーの設計は結構重要です。

今回はVPCエンドポイントからのみ許可するポリシーについて設計時の注意時点についてご紹介します。

### やりたいこと

今回設計したS3はアプリケーション保管用であり、パブリック公開はしません。

情報漏洩を防ぐために、より安全なセキュリティポリシーを適用すると考えており、以下のAWS公式ドキュメントを参照して検証してみました。

[バケットポリシーを使用した VPC エンドポイントからのアクセス制御](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html)

### 検証

上記のページを参照し、AWSコンソールから1個S3を作成して下記のバケットポリシーを適用しました。

“`
{
“Ve

元記事を表示

【Rails】Capistranoで自動デプロイの時、git stderr: fatal: not a valid object name: master

# エラーの内容
デプロイするため、下記コマンドを実行すると、

“`terminal
$ bundle exec cap production deploy
“`

このようなエラーが出ていました。(抜粋)

“`terminal
# エラーログ
git stdout: Nothing written
git stderr: fatal: not a valid object name: master
“`

# 原因
masterというブランチは存在してなく、デフォルトブランチ名はmainだった。

# 対処方法

config/deploy.rbにて、デプロイするブランチを指定する。
(下記を追記する。)

“`
set :branch, “main”
“`

# 参考
https://laptrinhx.com/rails-capistranoniyoru-zi-dongdepuroide-fa-shengshitaera-fatal-not-a-valid-object-name-master-366419494/

元記事を表示

Django MySQLにマイグレーションでWARNINGS

DjangoでMySQLにマイグレーションすると以下の警告が出た。

“`
WARNINGS:
?: (mysql.W002) MySQL Strict Mode is not set for database connection ‘default’
HINT: MySQL’s Strict Mode fixes many data integrity problems in MySQL, such as data truncation upon insertion, by escalating warnings into errors. It is strongly recommended you activate it. See: https://docs.djangoproject.com/en/3.1/ref/databases/#mysql-sql-mode
“`

調べると settings.pyにOPTIONSを追加することで解決。

“`
DATABASES = {
‘default’: {
‘ENGINE’: ‘djan

元記事を表示

AWS認定クラウドプラクティショナー(CLF)を受験してみた

# AWSクラウドプラクティショナー 受験レポート

2021/2にAWSクラウドプラクティショナー(CLF)を受験しました!

年に1回程度はなにかしら資格受験するのが恒例化してきたので、基本スタンスとしてはそんなノリで受けてみました。
受験までに至る経緯や学習方法、感想などをまとめてみたので、これから受験する人・受験を検討されている方の参考になればと思っています。

ちなみに私自身AWSの実務経験はなく、学習がてらにEC2・VPCを設定してアプリケーションを稼働させたり、Lambdaでトリガーを設定してSlackへ通知を出したりする程度しか触れたことがありませんでした。
なので、今回学習したAWSサービスは割と内容的には知らないことだらけでした。

# 受験経緯

今回受験した経緯としては、社内や所属しているチームでAWS認定資格の受験を勧められたからです。
経歴としてはアプリケーション開発にほぼ携わっていたのですが、これからは開発者もクラウドサービスの知識を身に付けておいて損はないと思って受験してみました。
実際、AWSサービスとして提供されているデータベース(RDSやAuror

元記事を表示

OTHERカテゴリの最新記事