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

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

AWS Lambda/PythonでJSON形式でログを出すベストプラクティス

Lambdaはログを CloudWatch Logs に自動保存しますが、CloudWatch Logs にはJSON形式のログを自動でパースして整形表示したり検索したりする機能があります。是非とも、ログをJSON形式にしたいところです。

しかし、「python lambda logging json」でググって見つかる記事は、いずれも内容に不備があるようでしたので、自分がベストだと思う方法を紹介するのがこの記事です。

# お断り

Pythonのログ出力は標準ライブラリの`logging`がスタンダードなので、この記事ではloggingを前提にしています。

printを使うべきではない理由・logging の正しい使い方については「[ログ出力のための print と import logging はやめてほしい](https://qiita.com/amedama/items/b856b2f30c2f38665701) 」という記事が分かりやすいです(文体は辛辣ですけど)

# これが(きっと)ベストプラクティスだ!

“`python
import logging
impo

元記事を表示

GitLab on Amazon EC2な構成で始めるTerraform × Ansibleハンズオン

## はじめに
TerraformとAnsibleを使ってAWSにGitLabを構築してみました。これからTerraform/Ansibleを始めよう思っている方の参考になれば幸いです。前提条件として、AWSのアカウントを持っていてEC2・IAM・VPC等の基本的なAWSリソースの使い方を理解していればスムーズに進めれるかと思います。
## 目次
– 実行環境
– 実際のコード
– 実行のイメージ
– 環境構築
– Terraformを動かしてみる
– Terraformで実践的なインフラリソースを構築してみる
– Ansibleを動かしてみる
– AnsibleでGitLabを構築する
– リソースのクリーンアップ
– 参考資料

## 実行環境
macOS Mojave v10.14.5
Terraform v0.11.14
ansible v2.9.2
virtualenv v16.6.2
pip3 v19.1.1
Amazon Linux 2 t2.medium(GitLab環境)

## 実際のコード
[GitHub](ht

元記事を表示

Visual Studio Code でAWS上のコード開発

# 概要
社内からAWSの踏み台インスタンスを経由したインスタンスにデプロイするような環境で開発を行っています。Visual Studio Code でデプロイ先のインスタンスを直接触ることができたので、備忘録として残します。

**環境**
 開発環境:Windows10
 踏み台インスタンス:Linux
 デプロイ先インスタンス:Linux

# 手順
 

  1. Visual Studio Code のインストール
    https://code.visualstudio.com/download
  2. Remote – SSH プラグインのインストール
  3. ユーザー環境変数の設定
    HTTP_PROXY_USER プロキシ認証ユーザー名
    HTTP_PROXY_PASSWORD プロキシ認証パスワード
  4. .ssh/config

    “` .ssh/config
    Host 踏み台インスタンスの名前(任意)
    HostName IPアドレス
    User ec2-user
    Port 22

元記事を表示

PostgreSQLパーティショニングのTableau、DBeaver、Glue Crawlerでの対応状況調査

PostgreSQLの2種類のパーティショニングについて、AWSのRDSで作成し、ツールで接続してみて対応状況を調べました。

2種類のパーティショニング

– テーブル継承によるパーティショニング
– 宣言的パーティショニング

試したツール

– Tableau
– DBeaver
– AWS Glue Crawler
– AWS Redshift Federated Query

PostgreSQLのバージョンは11.4です。最新でない11.4を選んだのは、試した時点でRedshift Federated Queryが対応していた最新バージョンがそれだったためです。

# 2種類のパーティショニング

テーブル継承によるパーティショニングは、バージョン8.1からのもので、文字通りテーブルの継承を使って無理やりパーティショニングを実現するイメージです。レコード挿入時のパーティション振り分けは、トリガ関数を手動で定義することで実現します。

宣言的パーティショニングは、バージョン10からのもので、パーティションの振り分けルールを宣言的に書けるので、テーブル継承よりは運用が楽です。

元記事を表示

GKEとEKSをいじってみる【Kubernetes】

この記事は**[うるる Advent Calendar 2019](https://adventar.org/calendars/4548) 24日目**の記事です。

# TL; DR
Kubernetesはコンテナオーケストレーションツールとして有名なミドルウェアですが、マネージド型のKubernetesってどこで使うのがいいんだろうか?とお悩みの方へ参考になれば幸いです。
ちなみに筆者はEKSでAPIをガッと集めたものを本番化したことが1度だけある程度のレベル感です。
運用自体は1ヶ月ほどだったので世の皆様ほどつらみなどは理解しておりません。
GKEに関しては完全に個人で遊ぶレベルなのでお察しです。それらを踏まえた上で生暖かく見守りつつ読んでいただければと思います。

# Kubernetesとは
この辺りはもう既に素晴らしい記事がQiita上にいっぱいあるので、特に詳しくは説明しません。
要はコンテナをよしなにしてくれる素敵なツールであるということを理解してもらえば十分です。余談としては今はCNCFが管理していますが、元々Googleが社内で利用していた**Borg**というク

元記事を表示

EKS on Fargateでguestbookアプリをデプロイする

この記事は、[Amazon EKS Advent Calendar 2019](https://qiita.com/advent-calendar/2019/amazon-eks) 24日目の記事です。

先日のre:Invent 2019で、待望のEKS on Fargateがリリースされました。
すでにAdventCalenderにもいくつか記事が出てきていますが、
本記事では、拙記事「[わりとゴツいKubernetesハンズオン](https://qiita.com/Kta-M/items/ce475c0063d3d3f36d5d)」にて各環境の第一歩としてやっているguestbookアプリのデプロイを行います。
これができればあとはわりとどうにでもなる気がする!

## クラスタを作成する
eksctlで作ります。
ちなみにeksctlは2019/7/23に[EKSの公式CLIになりました](https://aws.amazon.com/jp/blogs/opensource/eksctl-eks-cli/?utm_source=DJLK)。

各ツールのバージョンはこちら

元記事を表示

SAMで容量の大きなlambdaのコードをCodeUriで指定する方法

SAMで容量の大きなlambdaのコードをCodeUriで指定する方法についてです。

# ローカルにzipにしておいておく。

lambdaはあまりにもでかいコードをあげる場合にはzipにするか、それ以上ではcliからs3にアップし、lambdaからはそのURIを指定する方法をとります。
実際、以前の記事([近くで開催される勉強会を定期的にslackへ流す。](https://qiita.com/Kept1994/items/d4d9af93e160b22916df))ではdockerコンテナをs3へ置いてlambdaから参照して実行していました。

他方で`sam-cli`は、`template.yml`の`CodeUri`に指定した相対パスのソースコードをs3へアップします。

つまり、zipにまでして相対パスを指定しておけばs3へのアップは`sam package`コマンドの中で同時に行われます。
リファレンスを見るとこの`CodeUri`にはs3のパスを指定できていることから、一度s3にあげたコードをここで参照させるのかと思っていましたが`template.yml`の中ではロ

元記事を表示

Amazon SES の配信結果をDynamoDBに保存するLambda関数

この記事は、[AWS LambdaとServerless #2 Advent Calendar 2019](https://qiita.com/advent-calendar/2019/lambda2) の24日目の記事です。

## Introduction

システムからのメール配信を行っている場合、BounceやComplaintとなったメールアドレスへの対処が求められます。
Amazon SES の場合、SandboxからProductionで使用する際にどのようなプロセスを実装しているかを申請する必要があります。

AWS公式では以下のような知見が紹介されています。
[How do I create an AWS Lambda function to store Amazon SNS notification contents for Amazon SES to an Amazon DynamoDB database?](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-sns-ses-dynamodb

元記事を表示

code-server オンライン環境篇 (5) Docker 上で、code-server を立ち上げる

これは、2019年 code-server に Advent Calender の 第15日目の記事です。

前回に続き、EC2 Instance を 立ち上げたいと思います。

目次
[ローカル環境篇 1日目](https://qiita.com/kyorohiro/items/35bab591cd4a6b975c80)
[オンライン環境篇 1日目 作業環境を整備する](https://qiita.com/kyorohiro/items/603d6ee693fc2300079e)
[オンライン環境篇 2日目 仮想ネットワークを作成する](https://qiita.com/kyorohiro/items/6f2452ec2a2fe3640979)
[オンライン環境篇 3日目 Boto3 で EC2 インスタンスを立ち上げる](https://qiita.com/kyorohiro/items/32c9b7f9ebfccbeb6ac5)
[オンライン環境篇 4日目 Code-Serverをクラウドで動かしてみる](https://qiita.com/kyorohiro/items/3

元記事を表示

インフラ未経験でAWS認定クラウドプラクティショナーを受けてきたのでレポートします

普段はZOZOTOWNでWebフロントエンドのお仕事をしている佐藤です。

表題のとおり、全くのインフラ未経験ですがAWS認定クラウドプラクティショナー試験を受け、なんとか合格したので、これから受けようと思っている方のために学習記録を共有したいと思います。

本記事は [ZOZOテクノロジーズ #5 Advent Calendar 2019](https://qiita.com/advent-calendar/2019/zozo_tech5) 24日目の記事です。
昨日は [@RyoU24](https://qiita.com/RyoU24) さんの「 [SQL 文字列結合メモ](https://qiita.com/RyoU24/items/5498b93ff77d52c7e8fb) 」でした。

その他の記事はこちらからどうぞ。

[ZOZOテクノロジーズ #1 Advent Calendar 2019](https://qiita.com/advent-calendar/2019/zozo_tech)
[ZOZOテクノロジーズ #2 Advent Calendar 2019](ht

元記事を表示

プライベートサブネット内のEC2 (Amazon Linux 2) 上にAWS Cloud9を構築する

# はじめに

Cloud9とは、AWSのマネジメントコンソール上(つまり、ブラウザ上)でコーディングができるソリューションです。
AWSのサーバーレスアーキテクチャとの相性もよく、AWSを利用する上では是非検討したいソリューションです。

こういったソリューションが台頭してくる要因として、クラウドを利用する上での「コーディング環境」が挙げられます。
Vimmerならどこであっても実装に困りませんが、普段ローカルPCのIDE等を利用している開発者がいざクラウドを利用しようとすると、この「コーディング環境」という壁にぶち当たることもあるのではないでしょうか?
また、Cloud9のようなクラウド上で使える魅力的なエディターがあっても、会社のプライバシーポリシー的に導入が難しかったりと次々と壁にぶち当たるのも世の常です。

本記事では、そういった点を踏まえて、できる限りセキュアにCloud9を使うための構築手順とセキュリティ要件をご紹介します。
なお、Cloud9の使い方はご紹介しませんので、ご注意ください。

# 対象読者

次のようなアーキテクチャでCloud9を利用したい方全員
(Cl

元記事を表示

インフラ未経験者がAWSソリューションアーキテクト アソシエイトに2ヶ月で合格するまでのロードマップ

# はじめに

先日、AWS認定ソリューションアーキテクト アソシエイトに合格しました。

業務未経験からRailsなどのフレームワークを学び、クラウドに興味を持って受験される方も多いと

元記事を表示

CodeStarでDjangoやーる(Python3.6.8、Django2.2.9)

CodeStarでDjangoアプリを作成し、CodePiplineによってCI/CDしていきましょう。

# 開発環境
ローカルマシン

– git for windows
– anaconda 2019
– python 3.6.9
– Django 1.11.18 / 2.2.9

AWS EC2

– python 3.6.8
– Django 1.11.18 / 2.2.9

# プロジェクトの作成
1.aws consoleにログイン、CodeStarを開く(の前にIAMユーザーにAWSCloudFormationFullAccessが必要だったかも)
2.新規プロジェクトの作成をクリック
![01.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/63863/dbfd5b7b-4c4f-ef4e-810d-6fa2382235cc.png)
3.Python(Django)、Amazon EC2を選択
![02.PNG](https://qiita-image-store.s3.ap-no

元記事を表示

AWS S3バケットのオブジェクトがずっと削除されてた話

# バケットのオブジェクトがずっと削除されてた話
ある日、動作テストしてくれてる先輩から、「ステージングのデータが何か消えてるらしいよほげ」と言われました。

そのデータは実行履歴のデータでシステムを使うとデータがAWS S3に溜まって来て、AWS Athenaを利用してデータをクエリしてるのがざっくりの仕組みでした。

オブジェクトを削除してるコードは一切ない、
毎日ちゃんと溜まってる、
他の環境では何ヶ月間ちゃんと溜まってる、
ライフサイクルも必要な特定ディレクトリだけ指定して置いただけでした。

最初はAthenaのTableやDBが削除されると消える?とAthenaを疑ったり、
Terraformの処理のせい?と会社のTerraformマスターを疑ったり、
酔っ払ってやっちゃった?と自分をを疑ってました。

# 原因
しかし、見つかった原因は、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/108364/62d394f2-2ffa-cf91-2afe-3d7064e1559d.p

元記事を表示

Slack ワークフロービルダーとAWS Chatbotで負荷試験環境の構築を楽にする

本記事は、[サムザップ Advent Calendar 2019 #1](https://qiita.com/advent-calendar/2019/sumzap1) の12/23の記事です。

# はじめに
2019年11月25日にAWS Chatbotが[Slack からのコマンドの実行をサポートするようになりました(ベータ版)](https://aws.amazon.com/jp/about-aws/whats-new/2019/11/aws-chatbot-supports-running-commands-from-slack-beta/)。
AWSコマンドラインインターフェイス構文を使用したコマンドがサポートされており、馴染みのあるシンタックスでコマンドを記述できます。
この記事ではAWS Chatbot , Slack ワークフロービルダーを用いて負荷試験環境の起動・停止を簡単にする手順を説明します。

# 前提
負荷試験環境はEC2インスタンスやRDBなど複数のサービスにまたがるため、
普段は使わないので停止させておきたい、使いたいときに起動したいと思っても手順が煩雑

元記事を表示

LambdaをVPC内に作ってちょっとだけハッピーになった話

# 前提
– LambdaについてはServerlessFrameworkを使用
– IP制限の掛かったサービスにWebhook的にLambdaから通知を送りたかった
– SESのバウンス通知
– 動画変換完了後の通知など(うちの会社ではよくあるパターン)

# 課題
– これまではどうしていたかというと
– IP制限の掛かっていないCloudFrontディストリビューションを作成
– 上記のディストリビューションに対してドメインを振る(`webhook.xx.com`等)
– アプリケーション側の該当のパス以下(`/webhooks/hoge`等)にベーシック認証を設定
– Lambdaから上記のパスに通知

## ペイン(辛み)
– (ベーシック認証は掛けるものの)野ざらしになったWebhookディストリビューションを作ることになること
– ドメインも別途発行する必要があること
– クライアントによっては発行まで色々やり取り発生するし時間かかるしめんどくさい
– 同時にSSLの設定等も増えるのでとにかくめんどくさい

# 解決策
– 今回下記の流れで

元記事を表示

AWS Lambdaで動的サイトのwebスクレイピングをしてtwitterに投稿するbotを作った(続)

[2018/10に作ったtwitterのbot](https://qiita.com/kihoair/items/3a50454bae6c6bc6a2d6)をリファクタリングしました。理由としては

* python2.7で実行していた。
* Lambda Layer実装以前だったため、ソースコードのサイズが大きすぎてコンソールからは確認・修正できなかった。
* Serverless Framework/Lambda Layerを使ってみたかった。

などもあり、AWSの一年間の無料期間が終わるのでアカウントを作り直すついでに作り直しました。
ソースコードは[こちら](https://github.com/kihoair/intro_bot)。
レポジトリの構成の概要は以下の通りです。

“`
.
├── lambda (Lambda本体)
│ ├── includeするmoduleたち
│ ├── lambdafunction.py
│ └── serverless.yml

└── selenium-layer (Lambda Layer用)
├── ch

元記事を表示

eksctlでAWS EKSのNodegroupのインスタンス数をscaleする方法

AWS EKSで使うNodegroupをコマンドで操作する時はeksctlを使うので、NodegroupのEC2インスタンス数をscaleする時もeksctlを使います。

– まず、nodegroupのDESIRED CAPACITY数を確認します。

“`
eksctl get nodegroup –cluster=[Cluster Name]
CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID
[Custer Name] [Nodegroup Name] 2019-12-19T03:38:35Z 1 6 1 t3.medium ami-[ID]
“`
DESIRED CAPACITY 1なので、1つのインスタンスが上がっていることが確認できます。

元記事を表示

インフラ問題: CORSを使わずにSPAアプリをAWSにホスティングする

久々にインフラ周りの作業を行ったので備忘を兼ねて、やったことのメモを残しておきます。
インフラエンジニア向けの課題として、そこそこ面白い内容だと思うのでそれっぽい形式で書いてみます。

## 命題
APIサーバと連携するSPAアプリケーションをAWSでホスティングしたい。
そのために必要な設定を行いなさい。

## アプリケーション条件
– この文書内ではアプリケーションのドメインは`hoge.com`とする
– アプリケーションは顧客企業毎にサブドメインを割り当てる仕組み
– `aaa.hoge.com`とか`bbb.hoge.com`など複数のドメインがある
– SPAはルートにindex.htmlがあり、そこから参照されるJS, CSS, 画像などがサブディレクトリにある
– SPAのルーティングはHistory(ブラウザのパスが切り替わる)
– APIサーバはすでにELBを構成済み。APIサーバのエンドポイントは`api.hoge.com`
– APIサーバのエンドポイントはすべて `/api/`で始まる
– APIサーバはSPA以外からも単独で使用されることがある(

元記事を表示

ああ、全世界のインフラ担当者よ、半熟AWSインフラエンジニアになれ! (※AWS 旧ソリューションアーキテクトプロフェッショナルの話です)

今更ながら遅れながら、AWSのソリューションアーキテクトプロフェッショナル(SAP)に合格してきました。
タイトルは新作ゲームの発売前に動画流出しちゃった某ゲーム会社の過去作品タイトルをいただきました(ごめんなさい。怒られたらタイトル変えます。)

合格した結果は、末尾にでも記載しますので暇なら見ていただければと思います。
あとぼくは他の方のように本は紹介しません。
本はソリューションアーキテクトアソシエイトレベル(SAA)を受ける際に失敗したことがありますので、避けております。

# 合格への手引き

月並みですが、合格への手引きを書きたいと思います。

## 最低限の必須条件

– AWS ソリューションアーキテクトアソシエイト(SAA)の資格合格者
– SAA合格からAWSの運用経験2年(※補足必要事項1)

## 追加・補足でやると良いこと

– BlackBeltシリーズの熟読
– ホワイトペーパーの熟読
– Linux AcademyやKoiwaClubの利用(※補足必要事項2)
– 書籍はない。(はず)
– [Advanced Architecting on AWS](h

元記事を表示

OTHERカテゴリの最新記事