- 1. Managed Workflows for Apache Airflow (MWAA)でGlueを使ったジョブフロー
- 2. Terraform + クロスアカウント + VPCピアリング
- 3. GitHub Actions を利用しての ECSのBlue/Greenデプロイとトラフィック切り替え前テストを実践
- 4. AWS CDKとTypeScriptでFargateなECSクラスターを構築する
- 5. メモリ上限10Gで Lambdaのコア数はどうなった！！(Re:Invent2020対応版)
- 6. 空いてる時間を気軽に共有出来るサービスを作ってみた
- 7. serverlessでslackbotローカル開発環境構築 – serverless-offline編 –
- 8. cloud9でgit cloneしrailsチュートリアルを再開する流れ
- 9. サーバレスな機械学習アプリケーションを作ってみたい
- 10. awscliで特定のタグかつ起動しているインスタンスのIDを取得する
- 11. [BUG] Segmentation fault at 0x0000000000000b88
- 12. AWSデプロイ後のenv変更時に起きたこと
- 13. AWSクラウドプラクティショナー 受験対策用まとめ
- 14. 【個人開発】月間100万PVゲームアプリの超手抜きインフラ構成の話
- 15. 未経験ニートからエンジニアへの道
- 16. Node-RED を AWS Fargate + EFS で動かす
- 17. GreengrassのLambdaを作成してエッジデバイスにデプロイする
- 18. 第2回 AWSに自動でテスト/デプロイしてくれるインフラの設定・構築（rails開発環境構築編）
- 19. MacインスタンスをCLIから起動してみた
- 20. AWS ClooudWatch Logs使ってみた。
Managed Workflows for Apache Airflow (MWAA)でGlueを使ったジョブフロー
# はじめに
AWSのManageｄ AirflowサービスであるMWAAを試してみる
# 構築
MWAAの構築はクラメソさんの記事で済ませます
https://dev.classmethod.jp/articles/amazon-managed-workflows-for-apache-airflow-mwaa-ga/# 流れ
以下の記事で行っているStepFunctionsを使ったGlueクローラ実行とGlueジョブ実行をAirflowでやってみます。GlueジョブやS3バケットなどは既にあるものとして進めます。作成したい場合は以下のqiitaで再現は出来ると思いますので割愛します。
https://qiita.com/pioho07/items/f8a2fd946fc391f89c97#### 登場リソース
* 入力ファイル：19行のcsvファイルでS3にアップ済
* Glueジョブ名：se2_job0
* Glueクローラー名：se2_out0#### 処理内容：
se2_job0 Glueジョブで、csvファイルをParquetに変換します。
se2_o
Terraform + クロスアカウント + VPCピアリング
この記事は[ぷりぷりあぷりけーしょんず Advent Calendar 2020](https://qiita.com/advent-calendar/2020/ppap)の3日目の記事です。
# 概要
AWSのproductionアカウントとバックオフィスの人間が利用するAWSアカウントを分けて運用することは多いと思います。両者のアカウントに作成したVPCをピアリングして疎通させるTerraformのメモです。
# 要件
新規に作成した`アカウントA`から既存の`アカウントB`へと繋ぎこみます。# 実装
## アカウント情報
下記のようにすることで、`provider = aws.accountB`を指定することで既存のアカウントBに関するリソースの定義を行えます。“`terraform:aws.tf
provider “aws” {}provider “aws” {
alias = “accountB”
}data “aws_caller_identity” “accountB” {
provider = aws.accountB
}
“`#
GitHub Actions を利用しての ECSのBlue/Greenデプロイとトラフィック切り替え前テストを実践
こんにちは。READYFORでSREとして働いている水本です。これは[READYFOR Advent Calendar 2020](https://qiita.com/advent-calendar/2020/readyfor)の3日目の記事になります。
現在READYFORでは、EC2利用からECS Fargate利用への移行のための検証・開発を進めています。その検証の中でBlue/GreenデプロイのGitHub Actionを用いての自動化や、トラフィックの切り替え前のテストのやり方について調べたので解説してみます。これから導入を考える人の助けになればと思います。
# 前提
– Terraform でAWSリソースを管理します
– GitHub ActionsでのECSのデプロイでは [
AWS CDKとTypeScriptでFargateなECSクラスターを構築する
この記事は[ユニークビジョン株式会社 Advent Calendar 2020](https://qiita.com/advent-calendar/2020/uniquevision) 3日目の記事です。
弊社ではインフラにAWSのサービスを利用することが多く、CloudFormationを使って構築しています。
ただ活用範囲が広がるにつれて、YAML形式のCloudFormationでは組み込み関数などの機能を利用しても、コード量も多く冗長な記述になることがふえてきたため、AWS CDKの力を借りてみようと思います。# AWS CDK
> AWS Cloud Development Kit (AWS CDK) は、使い慣れたプログラミング言語を使用してクラウドアプリケーションリソースを定義するためのオープンソースのソフトウェア開発フレームワークです。
[Getting started with the AWS CDK – AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/
メモリ上限10Gで Lambdaのコア数はどうなった！！(Re:Invent2020対応版)
# 概要
Re:Invent 2020 で、High Performance Lambdaがリリースされ、メモリー上限が10Gとなり、コア数も最大６コアになりました。
ただ、メモリー設定でどうコア数が変わるかは公開されていないので実際に確認してみました。# 結論
以下の通り、最低２コアで、3Gから2G毎にコア数が上がるようです。
これまで、1536Mまで1コアでそれ以上が2コアだったようですが、大きく変更となりましたね。
課金単位も変わりましたが、実質的に値下げと言えるかもしれませんね。
|memory|cors|
|:—-|:—-|
|128|2|
|192|2|
|256|2|
|320|2|
|384|2|
|448|2|
|512|2|
|576|2|
|640|2|
|704|2|
|768|2|
|832|2|
|8
空いてる時間を気軽に共有出来るサービスを作ってみた
この記事は[CA21 Advent Calendar 2020](https://adventar.org/calendars/5308)に投稿する予定の記事です。
## 初めに
来年からインフラエンジニア(SRE)として働く予定のしがない学生です > [Twitter](https://twitter.com/_tetsuya28)
アドカレ3日目担当ということで今日はとあるサービスを勉強がてら作ってみたお話をしようと思います
あんまり1つずつの技術の深堀りはしないのでよろしくお願いします## 空き時間共有サービス
という訳で早速今回作ってみたサービスの紹介から
題名の通りなんですが、ミーティングや遊びなどの色々な場面で日程調整をすることがあると思うんですが、僕はその時間を列挙すると言う作業へのだるさを感じていて以前はGoogleカレンダーと連携して空き時間をリスト化出来るサービスを使っていたのですがどうしてもちゃんとしているサービスが故に僕の目的を果たすのにはToo muchな部分や、逆に足りないなと思う部分がありました
具体的には– 文字だけでは視認性が悪い
–
serverlessでslackbotローカル開発環境構築 – serverless-offline編 –
#何を作ろうとしている
slack apiフレームワークのboltをAWS Lambda上で動かして、さらにはDynamoDBとかも連携したSlackbotを作ろうとしている。#目指す開発環境
####ここから
マジで何も分からないところからどうにかこうにかserverlessを使ってAWSに簡単なlambda関数をデプロイ出来るようになりました
でも結構速いPCでもデプロイに一回1分以上かかる####こうなった！
serverless-offlineを使って、コードの編集が5秒ほどで自動で反映されてすぐ試せるローカルサーバーを立ち上げた。それをngrokでWEB上にURL公開、Slackからのエンドポイントに指定してローカルの方にリクエストを投げて逐次試しながら開発できる。
**この記事はserverless-offlineでローカル開発環境をserverlessの設定から立ち上げるところまでの備忘録です。**
#serverless-offlineとは
https://github.com/dherault/serverless-offline
AWS Lam
cloud9でgit cloneしrailsチュートリアルを再開する流れ
railsチュートリアルをcloud9で順調に進めるも、容量不足で先に進めなくなりました。
[AWS Cloud9 の容量不足を解決する](https://railstutorial.jp/help#volume-up-aws-ebs)
上記記事を参考にするも、hello_appやtoy_appを作成していなかった私は消せるファイルがありません(笑)“`
$ sudo growpart /dev/xvda 1
“`
上記コマンドがどうしても実行できなかったため、新しいenvironmentを作成してgit cloneをすることにしました。参照 : [Railsチュートリアル](https://railstutorial.jp/)
#AWSで新しいワークスペースを作成する
1.Cloud9の管理ページに行く。
2.Create environmentをクリック。
3.（AmazonLinuxではなく）UbuntuServerを選択し、Next stepをクリック。#ボリュームを拡張する
忘れないうちにやってしまいましょう！1.AmazonEC2コンソールを開く。
2
サーバレスな機械学習アプリケーションを作ってみたい
## GoogleColaboratryやKaggleKernelでしか機械学習のコードを書いたことがない
実際に仕事として機械学習を使う際には、* 学習データの準備
* モデルのトレーニング
* モデルの提供
* REST APIなどで使えるような状態にすることなどが必要なのかなぁと思う今日この頃(他にもたくさんあるっぽいが割愛。[こちらのサイト](https://cloud.google.com/solutions/machine-learning/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning)にいろいろ書いている)
そこで今回はAWSのSageMakerを使って少しだけ勉強してみた。## まずはSageMakerEndPointを作るとこまで
へのデプロイをこんな感じのシェルスクリプトで行っている。“`
#!/usr/bin/env bashgit fetch origin
git reset –hard origin/master
/usr/local/bin/composer update –no-interaction –no-dev
php artisan migrate –force
php artisan route:cache
php artisan config:cache
“`・.envはサーバー上で直接変更しているか自動デプロイとは別でアップしている。
・なんらかのデプロイツールを使い.envを毎回作成してる場合は今回の問題は起こらない。
## 問題
この状態でなにが起こるかというと.envを変更しても反映されない。
原因は`php artisan config:cache`でキャッシュしてるから。
例えば`APP_KEY`を変更したとしても`bootstrap/cache/config.php`が優先されるので無効。## 対処
.envを
AWSクラウドプラクティショナー 受験対策用まとめ
#AWSクラウドの概念
##クラウド
AWSのようなクラウドサービスプラットフォームからインターネット経由でコンピューティング、データベース、ストレージ、アプリケーションをはじめとした様々なITリソースをオンデマンド(**利用したいときに利用した分だけの従量課金**)で利用できるサービス##オンプレミス
クラウドとは対照にサーバー、ネットワーク、ソフトウェアなどの設備を自分たちで導入・運用するシステム。処理ピークを推測して、調達する機器の台数や性能を見積もってシステム設計・構築する必要がある。##AWSのクラウドコンピューティングの6つのメリット
①固定費が柔軟な変動費へ
②スケールによる大きなコストメリット
③キャパシティ予測が不要に
④速度と俊敏性の向上
⑤データセンターの運用と保守への投資が不要に
⑥わずか数分で世界中にデプロイ##クラウドアーキテクチャの設計原理
①故障に備えた設計（Design for Failure）
・単一障害点をなくす
②コンポーネントの分離
・Amazon SQS(simple queue service)、キューイングチェーンを利用して
【個人開発】月間100万PVゲームアプリの超手抜きインフラ構成の話
# インフラ管理よりも価値を生み出すことに時間を
まず大前提として、ユーザーはバックエンドのインフラがEC2で手動でデプロイされていようと、Lambdaで実行されていようと**「どうでもいい」**ということ。インフラの技術自慢はユーザー視点・ビジネス視点からは乖離している。
未経験駆け出しエンジニア転職界隈では「Herokuにデプロイしているポートフォリオ」を揶揄されているらしいが、その面接官全員に説教したい。「ラクできることって素晴らしいじゃん！」と思っている。エンジニアは手抜きできる人の方が優秀なのだ。
その上で理解してほしい価値観として、
> **インフラ管理は要求を満たした上で最小限にし、アプリケーション(ユーザーが体験できる価値)を充実させることに時間を集中しよう**というのがサービス開発者の価値観であるべき。と思っています。
PaaSもKubernetesもCI/CDもトータルでプロダクト開発を”ラクするため”のツールなんだよ。みんなインフラ管理でラクしてもっと価値あるコードいっぱい書こうぜ！# 自己紹介とアプリ紹介
## 職歴
* コナミでゲーム(C/C++)
未経験ニートからエンジニアへの道
タイトルは半分釣りです 笑
３年半ピアノの営業として働いたのち、１年間ニートして最近エンジニアとして働き始めました。ニート期間中に勉強した **Rails, Docker, CircleCI, AWS, Terraform**それぞれの勉強方法を雑に紹介します。
これからエンジニアを目指す人の参考になれば幸いです。作ったポートフォリオはこちら
https://github.com/kagamirr0r/C0FEE#Ruby on Rails
####テックアカデミー
・webアプリケーションコース 8週間コース
Rails Tutorialの簡易版 わかりづらいところもある###ポートフォリオ作成
**・自分が使いたい＆日本にないサービスを作る**
僕はこれがモチベーションになりました。**・テーブル数を10以上作る**
ER図を書きながらリレーションを考えました。非常に勉強になりました。
参考資料: [いまさら聞けない！？Oracle Database設計](https://www.oracle.com/jp/a/tech/docs/technical-reso
Node-RED を AWS Fargate + EFS で動かす
[ACCESS Advent Calendar 2020](https://qiita.com/advent-calendar/2020/access) 2 日目の記事になります。
Node-RED を AWS 上で動作させようと検討をした際、Fargate が有力な候補として挙がりました。
AWS コンソールを触りながら手探りで実装検討したところ、ある程度の形になったので記事にして紹介しようと思います。# 前提知識
## Node-RED[Node-RED](https://nodered.org/) とは主に IoT アプリの開発に使用されるフローベースプログラミングツールです。Node.js で動きます。ブラウザ上で表示されるノードをつないでフローを作成、デプロイする事でお手軽に IoT デバイスと連携可能なアプリが作成できます。
[Azure IoT Edgeを使った記事](https://qiita.com/Yokogawa_Mita/items/f7996d539b29618d7159)もあるので興味のある方は是非ご覧ください。
# 環境
動作確認済デバイス（OS）– e-RT3 Plus F3RP70-2L[^ert3]（Ubuntu 18.04 32bit）
横河電機のエッジコントローラです。AWS IoT Greengrassの認定デバイス[^certificate]に登録されています(e-RT3のページは[こちら
第2回 AWSに自動でテスト/デプロイしてくれるインフラの設定・構築（rails開発環境構築編）
# 本シリーズ集
| | タイトル |
|:-:|:-:|
| 0 | [目標・やりたいこと](https://qiita.com/Dadadada-TT/items/c59c0df9eaf5e6b10111) |
| 1 | [AWS編](https://qiita.com/Dadadada-TT/items/86e0a578f934e6578c04) |
| 2 | __`rails開発環境構築編`__ |
| 3 | Nginx・MySQL編（未） |
| 4 | Capistrano編（未） |
| 5 | CircleCI編（未） |
| 6 | 総集編（未） |# rails 開発用のディレクトリ構成
私は、__rails__開発に、__docker-compose__ を使用して環境を構築している。
今後、__Nginx等__ を語る上で、このディレクトリ構成の説明（というかpublicディレクトリの説明）が必要になるので、簡単に説明しておく。“`
/samplea
├ docker-compose.yml
├ Dockerfile
├ Gemfile
MacインスタンスをCLIから起動してみた
# 準備
## Cloud9起動
Cloud9をインスタンスを起動したいリージョンで起動
IDE画面を表示## awsコマンドのバージョンアップ
デフォルトで入ってるのが低いのでバージョンアップしておく“`
$ curl “https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip” -o “awscliv2.zip”
$ unzip awscliv2.zip
$ sudo ./aws/install
$ aws –version
“`# 起動
## 専用ホストを割り当てる
Macインスタンスはライセンスの関係上、専用ホスト上で起動する必要がある
なので、ホストを割り当てる“`
$ aws ec2 allocate-hosts –instance-type mac1.metal –availability-zone ap-southeast-1a –auto-placement on –quantity 1 –region ap-southeast-1
“`## キー作成
インスタンスで利用
AWS ClooudWatch Logs使ってみた。
AWSのCloudWatch Logsを使ってみたので作業記録として残しておきます。
#前提
前提として、Webサーバーを構築済みでパブリックIPアドレスでのアクセスが可能とします。
用意したWebサーバーの情報は、以下になります。
– OS:AmazonLinux2
– ミドルウェア:Apache
#作業の流れ
1. IAMロールを作成する
– CloudWatch Logsの設定をする
– AWSコンソールから確認する#1. IAMロールを作成する
ロールの作成をクリックします。
EC2を選択し、次のステップへ進みます。
