投稿日：2019-01-27T05:16:49+09:00

AWSでDjangoのWEBサーバーを作る（Amazon Linux 2、HTTPS化）

Djangoのウェブサーバーを作ります。ハッカソンとかで良く使うのでメモです。

インスタンスの作成

EC2のダッシュボードを開き、インスタンスを作成します。
イメージはAmazon Linux 2 AMI (HVM), SSD Volume Type - ami-0d7ed3ddb85b521a6を選択しました。

インスタンスタイプはt2.microです。
セキュリティグループの設定で、SSH(22)、HTTP(80)、HTTPS(443)、TCP(8000)用のポートを開放します。

キーペアを任意の名前で作成し、できた.pemファイルをPuTTY genで.ppkファイルに変換します。

インスタンスの作成が完了したら、Elastic IPを開き、新しいアドレスを割り当てます。作成したインスタンスにそのIPアドレスを関連付けます。

ドメインを取得

Route53でdomainを作ってください。

www.{name}.com のValueのところにElastic IPを設定します。

チュートリアル: Amazon Linux 2 に LAMP ウェブサーバーをインストールする

PuTTYでパブリックIPもしくは、DNS名（www.{name}.com）でSSH接続します。ここで.ppkファイルを使います。ユーザー名はec2-userです。
sudo yum update -y
sudo amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
sudo yum install -y httpd mariadb-server
sudo systemctl start httpd
sudo systemctl enable httpd
sudo systemctl is-enabled httpd
Test Pageを表示（ http://www.{name}.com ）します。
sudo usermod -a -G apache ec2-user
exit
もう一回ログインします。
groups
sudo chown -R ec2-user:apache /var/www
sudo chmod 2775 /var/www && find /var/www -type d -exec sudo chmod 2775 {} \;
find /var/www -type f -exec sudo chmod 0664 {} \;
HTTPSに対応させます。（Google Home MiniでWebAPIを使ったアプリ作るときとかに必要だったので）
sudo systemctl is-enabled httpd
sudo systemctl start httpd && sudo systemctl enable httpd
sudo yum update -y
sudo yum install -y mod_ssl
インスタンスを再起動します。
sudo systemctl restart httpd
HTTPSで接続（https://www.{name}.com ）します。
プライバシーエラーになりますが、下の詳細設定からアクセスできます。
保護されていないアクセスとなります。

CA 署名証明書の取得

付録: Amazon Linux 2 での Let's Encrypt と Certbot の使用を参考にします。
sudo wget -r --no-parent -A 'epel-release-*.rpm' http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/
sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm
sudo yum-config-manager --enable epel*
sudo yum repolist all
/etc/httpd/conf/httpd.confのListen 80の下に追記します。
sudo vi /etc/httpd/conf/httpd.conf
<VirtualHost *:80>
    DocumentRoot "/var/www/html"
    ServerName "{name}.com"
    ServerAlias "www.{name}.com"
</VirtualHost>
Cerbotを実行します。
sudo systemctl restart httpd
sudo yum install -y certbot python2-certbot-apache
sudo certbot
1．"Enter email address (used for urgent renewal and security notices)" というプロンプトが表示されたら、メールアドレスを入力し、Enter

2．Let's Encrypt のサービス利用規約に同意するため、Aを入力し、Enter

3．EFF のメーリングリストに登録するための承認のため、Yを入力し、Enter

4．共通名およびサブジェクト代替名 (SAN) が表示され、2を入力し、Enter
1: {name}.com
2: www.{name}.com
5．HTTP クエリを HTTPS にリダイレクトするどうかの確認で、HTTPS 経由の暗号化接続のみ受け入れる場合、2を入力し、Enter

HTTPS（ https://www.{name}.com ）に安全に接続できることを確かめます。

Certbot を自動化
sudo vi /etc/crontab 
39 1,13 * * * root certbot renew --no-self-upgrade
sudo systemctl restart crond
Djangoやーる

ここからは、LAMP環境作ったのに、Djangoやーるっていう内容です。
Amazon Linux 2にAnacondaをインストールします。
wget https://repo.continuum.io/archive/Anaconda3-2018.12-Linux-x86_64.sh
bash Anaconda3-2018.12-Linux-x86_64.sh
yesを入力してインストール、最後にyesを入力して.bashrcを生成します。

/home/ec2-user/anaconda3にインストールされました。
Django用にPython3.6環境を作ります。
conda create -n django python=3.6
condaのコマンドがないと言われたら、
source /home/ec2-user/anaconda3/etc/profile.d/conda.sh
PATHが通ってないので、cat /home/ec2-user/.bashrcで確認しましょう。
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=

# User specific aliases and functions
# added by Anaconda3 2018.12 installer
# >>> conda init >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$(CONDA_REPORT_ERRORS=false '/home/ec2-user/anaconda3/bin/conda' shell.bash hook 2> /dev/null)"
if [ $? -eq 0 ]; then
    \eval "$__conda_setup"
else
    if [ -f "/home/ec2-user/anaconda3/etc/profile.d/conda.sh" ]; then
        . "/home/ec2-user/anaconda3/etc/profile.d/conda.sh"
        CONDA_CHANGEPS1=false conda activate base
    else
        \export PATH="/home/ec2-user/anaconda3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda init <<<
cat /home/ec2-user/.bashrc-anaconda3.bakも確認しましょう。
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=

# User specific aliases and functions
Anacondaでdjango環境に入り、Djangoをインストールします。
source activate django
(django) pip install django
(django) django-admin startproject project_name
(django) cd helloworld
(django) python manage.py migrate
(django) python manage.py runserver
もし、activateがないと言われたら、
source /home/ec2-user/anaconda3/bin/activate django
次にHTTPSに対応させます。
pip install django-sslserver
cd helloworld
sudo vi settings.py
DEBUG = False
ALLOWED_HOSTS = ['www.{name}.com']

# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'sslserver',
]

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
python manage.py runsslserver 0.0.0.0:8000の後に、.crtと.keyを指定する必要があります。/etc/letsencrypt/live/www.{name}.com/ 以下にあるのですが、.pemファイルになっているので、拡張子を変えてコピペします。
sudo cp /etc/letsencrypt/live/www.{name}.com/fullchain.pem /etc/letsencrypt/live/www.{name}.com/fullchain.crt
sudo cp /etc/letsencrypt/live/www.{name}.com/privkey.pem /etc/letsencrypt/live/www.{name}.com/privkey.key
sudo chmod 755 /etc/letsencrypt/live/
sudo chmod 755 /etc/letsencrypt/live/www.{name}.com/fullchain.crt
sudo chmod 755 /etc/letsencrypt/live/www.{name}.com/privkey.key
実行してみましょう。
python manage.py runsslserver 0.0.0.0:8000 --certificate /etc/letsencrypt/live/www.{name}.com/fullchain.crt --key /etc/letsencrypt/live/www.{name}.com/privkey.key
（ https://www.{name}.com:8000/ ）に接続します。
Not Found
The requested resource was not found on this server.
（ https://www.{name}.com:8000/admin/ ）に接続します。

adminユーザーを作るには、下記のようにします。
(django) [ec2-user@ip-xxx-xx-xx-xx helloworld]$ python manage.py createsuperuser
Username (leave blank to use 'ec2-user'): admin
Email address: gachi.kumamcn@gmail.com
Password:
Password (again):
Superuser created successfully.
HelloWorld

HelloWorldコンテンツを作成します。

views.pyを作成します。
from django.http import HttpResponse

def helloworld(req):
  return HttpResponse('Hello, World !!')
settings.pyにhelloworldを追加します。
INSTALLED_APPS = [
    ....
    'helloworld',
]
urls.pyにもhelloworldを追加します。
import helloworld.views
urlpatterns = [
    path('helloworld/', helloworld.views.helloworld),
    path('admin/', admin.site.urls),
]
実行して、（ https://www.{name}.com:8000/helloworld/ ）に接続します。

バックグラウンドで実行

バックグラウンドでサーバーを起動します。
末尾に&をつけるだけだと、標準出力されてしまいますので、nohupと&で囲みましょう。
nohup python manage.py runsslserver 0.0.0.0:8000 --certificate /etc/letsencrypt/live/www.{name}.com/fullchain.crt --key /etc/letsencrypt/live/www.{name}.com/privkey.key > /dev/null 2>&1 < /dev/null &
バックグラウンドのサーバーを停止します。
ps -ef|awk 'BEGIN{}{if(match($8, /python/))system("kill -9 " $2)}END{}'

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-27T03:20:08+09:00

AWSアカウントのMFAは端末に登録されている

AWSアカウントのMFAは、格安SIMに変えて、電話番号が変わっても大丈夫。

MFA（Multi-Factor Authentication）とは

多要素認証。IDとパスワードだけでの認証ではなく、別の端末（電話番号やスマホアプリなど）を使って認証する方式。
万が一情報流出等によってアカウントが乗っ取られた際、高額請求などの危険性があるため、AWSアカウントを作ったらすぐ設定すべきとよく言われている。

この記事で伝えたいこと

私はAWSのMFAにGoogleAuthenticatorを使っている。
この認証情報はアプリに登録されているので、電話番号が変わっても、（スマホが変わらなければ）大丈夫。

経緯

そもそもなんでそんなことを（しかも記事投稿に使っていなかったQiitaで）書こうと思ったかという経緯を軽く説明したい。

昨年末、きっかけがあって格安SIMに変更した。
MNPを利用して電話番号を持って移動すると手数料3240円がかかってしまうこと、番号に特に執着がなかったため、新規でSIM変更。
使っている 機種（iPhone）はそのまま で。
流れでわりと突然の変更だったため、電話番号変更による影響は整理しないまま手続きをした。

AWSについては、駆け出しのエンジニアとしては最低限履修しておくべきと思ったため、以前、アカウントを作成していろいろ遊んでいた。が、しばらく放置していたので忘れていた。

ついさっきふと、CloudFrontにhtmlファイルを置きっぱなしだったことを思い出し、ログインを試みた。
IDとパスワードの後、MFAの認証コードを入力したところ、認証エラーになった。

パスワード入力後、MFAの画面に推移しているので、MFAの問題と思い、そこで青ざめた。
電話番号が変わったのが原因ではないかと思ったのだ。

いろいろ調べたが、AWSのMFA関連のQAには、デバイスの故障紛失による端末変更の際の対応が書かれていたものの、電話番号の変更については記載がなかったので、カスタマーサポートに問い合わせをしようと思ったが、MFA関連は 英語の電話 がかかってきて云々とあり、ためらった。

IAMユーザのMFAで、キーなどがテキストとしてPC内にあったりする場合は、CLIなどでできるらしいが、ルートアカウントでそういう方法があるのかはわからなかったし、そもそも使っていないアカウントなのでEC2も止めてあるし、すぐにAWS_CLIが使える環境が用意できるわけではない。

いろいろ考えているうちに、
「トークンはスマホアプリ以外にも存在する¹」＝「電話番号は関係ないのでは」
という（よく考えれば）至極当たり前のことに気づき、「パスワードを間違えていた」という可能性にかけてパスワードを再設定。
新しいパスワードと、アプリに表示されている認証コードでログインができた。

…そもそもパスワード間違えなければこんなことにはならなかったのだけれど。

トークンにはカードタイプなど専用の端末もある。企業などでは鍵のかかるロッカーにトークン端末を入れておいて管理していることもあるとかないとか。 ↩

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T21:15:15+09:00

【無料】bitwardenをawsにserverlessでセットアップする

パスワード管理、皆さんどうしてますか？私は警告を無視して使い回し、影響が検知されたところから変更、みたいなことをしてました(ダメじゃん)。

楽ちんなのはパスワードマネージャーですが、どうにもプロプライエタリな営利企業によるサービスには渡したくない。そんなあなたにbitwardenというものがあります。

bitwardenも8bit Solutions LLC.による開発なのですが、オープンソースなのでセルフホスティングが可能です。

ここで悩むのが「どこにホスティングするか？」というところ。セキュリティに自信ﾆｷは自宅鯖でもいいのかもしれませんが~~(そもそもパスワードマネージャーなんて使わないか)~~、私は自信がないし自宅とのVPNもルーターの簡易機能を使ってるのであんまり安定しない。となると思いつくのはVPSやクラウドですが、公式のインストール方法によると、要求スペック(以下)が結構重く、無料でのホスティングはちょっと厳しそう。

SYSTEM REQUIREMENTS

Processor: x64, 1.4GHz or faster

Memory: 2GB of RAM or more

Storage: 10GB or more

Docker: Engine 1.8+ and Compose 1.17.1+

しかもDockerを使わないとなると、.NET Core 2.xとSQL Server 2017といういかにもMicr○s○ftな構成になります。
~~Linux版もあるし別にいいんですけど~~

bitwardenは、先述のようにオープンソースなので、有志がunofficialで様々な実装をしています。その中の一つにbitwarden-serverlessというのがあったので試したのですが、セットアップで結構躓いたので、躓かない(であろう)方法を書き残しておきます。

~~前書きが長かった。反省している()~~

TL;DR

~~こんな後ろにあるTLDR見たことないヨ~~

iAMユーザーを作る

aws-cliに設定する

bitwarden-serverlessをcloneしてくる

デプロイ

設定

Requirements

git

npm

aws-cli

awsアカウント

細かく書くと某de_moduleみたいに大変なことになりそうなので、この辺は導入方法書かなくても分かって(嘆願)。aws-cliはpipが楽だよ。

Structure

CloudFormation

API Gateway

CloudWatch

DynamoDB

Lambda

s3

Setup

1. iAMユーザーを作る → aws-cliに追加する

この辺はまだserverless frameworkに共通の部分。
ポリシーは新しくserverless用のを作成しますが、serverless公式のものでは上手く行かなかったので、Forkして必要なものを追加したものを用意しました。ポリシーの作成からjsonにペタリしてくださいな。

IAMCredentials.json

ユーザーが作成されるとAPIkey／Secretが出せるページになるので、aws-cliにコピペします。同時にCLIも開いておくと良いかも？
$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE # APIkey
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY # Secret
Default region name [None]: ap-northeast-1 # お好みで…
Default output format [None]: # そのままEnterでおｋ
2. Sourceのclone～デプロイ

ここからは基本的にREADMEに書いてあるとおりです。
npm i -g serverless
git clone https://github.com/vvondra/bitwarden-serverless.git
cd bitwarden-serverless
npm i
serverless deploy --region ap-northeast-1 -v
成功すれば、ServiceEndpointとしてhttps://abcd01234.execute-api.ap-northeast-1.amazonaws.com/prodみたいなのが出てきます。

3. クライアント側の設定

この段階ではまだ「サーバーが建った」だけなので、bitwardenのアカウントを作ったりしないといけません。

その前に。
そ　の　前　に　。　~~ダイジな事なので2回~~

クライアントにサーバーの設定をします。簡単です。
の「設定」をクリックすると、セルフホスティング環境の項目があるので、サーバーURLのところに、さっき出てきたServiceEndPointをペタリして、の保存をクリック。

続いてアカウントを作ります。と言っても、メールアドレスと設定するパスワードを入れるだけなので、メール認証とかも飛びません(飛ばそうと思えば飛ぶのか…？)。パスワードのヒントも自由に設定できます。ここでのパスワードはマスターパスワードと同義なので、(間違えないとは思うけれど)一応。

あとは使うデバイスでログインすればおｋ。ログインの前にServiceEndPointの設定をお忘れなく。

番外編：Chromeからのインポート

Googleに（＊）のシワの数まで知られてるなんて人もいると思いますが、これをbitwardenにブチ込む方法もあります。

Chromeでエクスポート

chrome://settings/passwordsを開くと保存されたパスワードが出てくると思いますが、「保存したパスワード」の右端若干上の︙をクリックするとエクスポートボタンが出てきます。エクスポートにはSystem(OS)のAdmin権限が必要です。csvで出力されます。

bitwardenにインポート

本来ならweb vaultからGUI操作でインポートするらしいのですが、bitwarden-serverlessでは実装されていないので、CLIでインポートします。
場合によってはDynamoDBの書き込みキャパに引っかかるかも？とのこと。
npm i -g @bitwarden/cli
bw config server <api gateway url>
# e.g. https://abcd01234.execute-api.ap-northeast-1.amazonaws.com/prod/
# スラッシュ有

bw login
? Email address: sample@example.com
? Master password: [hidden]
You are logged in!

To unlock your vault, set your session key to the `BW_SESSION` environment variable. ex:
$ export BW_SESSION="5PBYGU+5yt3RHcCjoeJKx/wByU34vokGRZjXpSH7Ylo8w=="
> $env:BW_SESSION="5PBYGU+5yt3RHcCjoeJKx/wByU34vokGRZjXpSH7Ylo8w=="

You can also pass the session key to any command with the `--session` option. ex:
$ bw list items --session 5PBYGU+5yt3RHcCjoeJKx/wByU34vokGRZjXpSH7Ylo8w==

# session keyをexportしてvaultをunlockする
export BW_SESSION="5PBYGU+5yt3RHcCjoeJKx/wByU34vokGRZjXpSH7Ylo8w=="

bw import chromecsv <path>
bw sync
エクスポートされたcsvファイルは一応消しておきましょう(パスワードが平文で載ってます)。

〆

2FAは使えるみたいですが、個人的にデメリットのほうが大きく感じているのでまだ試してません。
また、独自ドメインについてはドメイン取得で料金が発生するので触れませんでしたが、AWS Certificate Managerでcloudfront向け(要はus-east-1)で証明書を発行してやれば出来るっぽい。詳しくはbitwarden-serverlessのREADME内のRun on own domainにあるのでお読みになって。

デプロイした後にLambdaで関数の設定を見てみたところ、トリガーやリソース呼び出しが図式で表示されたので、serverlessのなんとなくの理解にはもってこいかな、とも思います。

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T20:42:07+09:00

cloud9 と GitHub を使ってRailsアプリを開発する際の下準備

内容

cloud9 と GitHub を使ってRailsアプリを開発する際の下準備

なぜcloud9上でRailsアプリを開発するのか？

A. 従来はローカル環境（Mac)とGitHubを利用してアプリ開発をしていた。
しかし、ある時からnokogiriがインストールできないためローカルでの開発が困難に。

「Rubyの開発をするにはcloud9でやったほうがいい」とのアドバイスをいただいたので、cloud9とGitHubで開発することにした。

具体的な下準備

cloud9 に git をインストール
command-on-cloud9
gem intall git
バージョンを指定してRailsのインストール
command-on-cloud9
gem install rails -v 5.1.6
cloud9からGitHubにUP
command-on-cloud9
git init
git add .
git commit -m "Write your comment here."
git remote add origin [your GitHub repository]
git push -u origin master

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T20:39:07+09:00

2019年になってAWSのSLA設定が急増している

AWSが2019年になってSLAを次々と発表してきているので、ちょっと絵にしてみました。
　https://aws.amazon.com/legal/service-level-agreements/?nc1=h_ls

雑感

昔は可用性が高いと言いつつSLAが設定されていないサービスが多く「なんだかなー」って感じでしたが、今は全サービスでSLAを設定しそうな勢いを感じます

他社もこの流れに追従するのかなー。いずれにしても利用者にとってはとても良い事です

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T19:10:54+09:00

AWS認定ソリューションアーキテクトアソシエイトに合格したときの勉強方法

本「Amazon Web Service エンタープライズ基盤設計の基本」で勉強した。

この試験にかなりフィットした内容になっていて、この１冊を勉強すれば合格できると思う。

この本以外で試験に役立つような勉強をしていたかというとそんなにしてないと思う。

ブラックペーパーはさらさらと読んだりはしたけど、そんなに記憶に定着してないと思うし。

ホワイトペーパーはこの試験には役立つとは思ったけど、分量も多いし英語だらけだったので手は出さなかった。（英語苦手です。）

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T17:35:31+09:00

AWS IAMの基本概念を概念モデルで整理した

AWS IAMに登場する概念はややこしく、初学者が理解するのは難しいと思います。
そこで、概念モデルを作成して、AWS IAMの基本概念を整理しました。

※ 一部の概念はTerraformのリソース名を参考に命名しています。

全体像

AWS IAMに登場する基本概念は、以下のように整理できました。

それでは、以下の3つに分けてややこしい点を説明していきます。

IAM Policy

IAM Policy Attachment

IAM Role

IAM Policy

IAM Policyとは、どの「リソース」へのどの「アクション」を許可 (拒否) するかを定義するものです。
例えば、「S3へのListBucketを許可」といった内容になります。

IAM Policyには「管理ポリシー」と「インラインポリシー」の2種類がありますが、「インラインポリシー」は非推奨とされています。
※ インラインポリシーはIAM Role、IAM Group、IAM Userに直接記述するものですが、非推奨ということもあり、今回作成したモデルではそこまで表現していません。

管理ポリシーには以下の2種類があります。

AWS管理ポリシー

AWSがあらかじめ用意している管理ポリシー

カスタマー管理ポリシー

カスタマーが独自に作成する管理ポリシー

JSONは一見ややこしいですが、少しじっくり見れば、実はそれほど難しくありません。
どのリソースへのどのアクションを許可 (拒否) するか、ただそれだけを表しています。

IAM Role Policy Attachment

IAM Policyは何かにアタッチして始めて意味を成します。

アタッチできる対象は以下の3つです。

IAM Role

IAM Group

IAM User

IAM Userに直接アタッチすることは推奨されていないので、IAM Userにポリシーをアタッチしたい場合は、代わりにIAM Groupにアタッチし、IAM UserをIAM Groupに入れましょう。

IAM Roleは少しややこしいので、以下で別途解説します。

IAM Role

IAM Roleは、あるリソースに対して他のリソースへのアクションを許可したい場合に使います。

例えば、EC2からS3にListBucketできるようにしたい場合、以下のステップを踏むことになります。

S3へのListBucketを許可するIAM Policyを作成

EC2をPrincipalに設定したIAM Roleを作成し、上記のIAM Policyをアタッチ

EC2インスタンスに上記のIAM Roleをアタッチ

EC2をPrincipalに設定したのは、「このロールはEC2にアタッチできるものだよ」という意味です。
Principalはマネジメントコンソールやドキュメント上で「信頼」という言葉で表現されることがあります。

※ 実際には、EC2へのIAM Roleのアタッチは、インスタンスプロファイルを経由することになります

IAM Roleを使わずとも、IAM Userのアクセスキー、シークレットアクセスキーをEC2内の ~/.aws/credentials や、アプリケーションのプロパティファイルなどに設定すれば、EC2から他のリソースにアクセス可能になります。
しかし、その方法はアクセスキー、シークレットアクセスキーの漏洩というリスクを追うことになるため、非推奨とされています。

おわりに

これでAWS IAMの基本概念を整理できました。
AWS Organizations、Permissions boundaryといったものを含めるとより複雑になりますが、第一歩としてはこのくらいかなと思います。

IAM関係は重要なわりに難しく、私もまだまだ理解が浅いので、もし間違いに気付かれた方はご指摘お願いします。

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T17:23:29+09:00

amazon cli

amazon CLIをインストールしてみました

Microsoft Windows で AWS Command Line Interface をインストールする
を参考に環境設定を進めていきました。

手こずった２点
パスの設定の仕方がわかりませんでした。
結果以下の三点を追加してパスが通るようになりました。
C:\Users\10001176313\AppData\Local\Programs\Python\Python37\Scripts
C:\Users\10001176313\AppData\Local\Programs\Python\Python37
C:\Users\10001176313\AppData\Local\Programs\Python\Python37\libs
IAMユーザは最初からAWSアクセスの種類を選択する際にプログラムによってアクセスにチェックを入れておかないとエラーが返ってくるのかも、、、

AWS CLI が正しくインストールされたことを確認します
aws --version
aws-cli/1.16.96 Python/2.7.15 Windows/10 botocore/1.12.86

AWS CLI を設定　認証情報とデフォルト設定で AWS CLI を設定します
aws configure

AWSの画像認識API Rekognitionを試してみる(AWS　コマンド)
イメージ内のラベルの検出
(AmazonRekognitionFullAccess と AmazonS3ReadOnlyAccess のアクセス権限を付与する)
aws rekognition detect-labels --image "S3Object={Bucket="bucket",Name="file"}"
レスポンスが返ってくる

なんとなくCLIを使ってみることができた

今度は何らかの見やすいフォーマットで表示できるようにし、Lambdaを使いS3にアップロードをトリガに実行できるようにしてみよう

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T16:20:02+09:00

Global Accelerator はターゲットから何秒レスポンスがないとタイムアウトするのか

概要

AWS Global Accelerator について、ふと疑問に思った点がありました。
ターゲットとなるエンドポイントから、どれくらいの間レスポンスがなかったらタイムアウトするのでしょうか？

例えば、API Gateway の場合、バックエンドとの間のタイムアウトは 50msec ~ 29sec で設定可能となっています。
https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table

今現在設定する項目はなく、制限情報のページにも記載がないので、とりあえず実際に試してみたいと思います。

構成

Global Accelerator --- EC2(Web/Python)

すごくシンプルです。

Webサーバー

Python でつくった簡単な Web サーバを EC2 で動かします。
3600 秒待ってからレスポンスを返すように作ってます。
webserver.py
#!/usr/bin/python
import time
from BaseHTTPServer import BaseHTTPRequestHandler,HTTPServer

PORT_NUMBER = 8080

class myHandler(BaseHTTPRequestHandler):
    #Handler for the GET requests
    def do_GET(self):
        time.sleep(3600)
        self.send_response(200)
        self.send_header('Content-type','text/html')
        self.end_headers()
        # Send the html message
        self.wfile.write("Hello World !")
        return

try:
    server = HTTPServer(('', PORT_NUMBER), myHandler)
    print 'Started httpserver on port ' , PORT_NUMBER

    server.serve_forever()

except KeyboardInterrupt:
    print '^C received, shutting down the web server'
    server.socket.close()
$ sudo ./webserver.py
Started httpserver on port  80
計測結果

単純に curl で計測します。
とりあえず最大3600秒でタイムアウトする設定で測定しました。
Global Accelerator の2つのIPにそれぞれ２回、合計4回測定しましたが、概ね 75sec でタイムアウトする結果となりました。
$ curl -m 3600 -kL 'x.x.x.x' -o /dev/null -w "%{http_code}\t%{time_total}\n" 2> /dev/null
000 75.184206
$ curl -m 3600 -kL 'x.x.x.x' -o /dev/null -w "%{http_code}\t%{time_total}\n" 2> /dev/null
000 75.134897
$ curl -m 3600 -kL 'y.y.y.y' -o /dev/null -w "%{http_code}\t%{time_total}\n" 2> /dev/null
000 75.318919
$ curl -m 3600 -kL 'y.y.y.y' -o /dev/null -w "%{http_code}\t%{time_total}\n" 2> /dev/null
000 75.947411
まとめ

75秒、、、
net.ipv4.tcp_keepalive_intvlのデフォルト値が 75 なので関係があるのかな・・・
雑な検証なので、Global Acceleratorの仕様がこうというわけではなく、今回の環境ではこういう結果になったという感じですね。

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T13:26:01+09:00

AWS活用に向けて

どのようにAWSを使用すればいいのか

［最初にやること］(https://qiita.com/chroju/items/c7ad918d79b0288bc490)
今まではサービスの内容について学習してきましたが、今後システムを運用していくための留意点を頭に入れておこうと思い上記のブログを参考にさせて頂こうと思います。

IAMユーザーを作成する

とりあえず一つ新しいアカウントを一つ作成してみた

Trusted Adviserを設定する

*赤い！が出ていたので何かと調べてみるとルートアカウントのMFAが設定されていなかった

(Google Authenticator)[https://itunes.apple.com/us/app/google-authenticator/id388497605?mt=8]
をiphoneにインストールした
(2 段階認証プロセスでは、ログイン時に 2 段階の確認を求めること
スマートフォンの Google 認証システムアプリ)
IMAのセキュリティステータスのルートアカウントのMFAを有効化した

*セキュリティグループが黄色になっていた
EC2のSSHを無制限アクセスになっているためだ。

今後ベストプラクティスを身に着けるためにも、すべてのチェックへのアクセスを有効化したいため、ビジネス($100USD/月)を検討したい

CloudTrailを設定する

CloudTrailはAWS APIへのアクセスをロギングしてくれるサービス
東京リージョンのログをとってみることにする
15万件もイベントが発生することもないだろう(無料)

CloudWatchで利用料金を監視する

CloudWatchを使って、利用料金の監視が可能

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T12:23:23+09:00

AWS ECS Agent の Prometheus Metrics を試してみる

AWS ECS Agent 1.24.0 に Prometheus Metrics をエクスポートする機能がマージされていたので試してみた。

https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md#1240

* Feature - Introduce prometheus support for agent metrics #1745

機能を有効化する

ECS Agent が Prometheus のメトリクスをエクスポートするには ecs.config に1行追加するだけで良い。

/etc/ecs/ecs.config

+ ECS_ENABLE_PROMETHEUS_METRICS=true

Listenポートは 51680 となっている。

メトリクスの一覧

とりあえず、curl で叩いてみる。

$ curl localhost:51680/metrics
# HELP AgentMetrics_DockerAPI_call_count
# TYPE AgentMetrics_DockerAPI_call_count counter
AgentMetrics_DockerAPI_call_count{Call="CREATE_CONTAINER"} 1
AgentMetrics_DockerAPI_call_count{Call="INSPECT_CONTAINER"} 3
AgentMetrics_DockerAPI_call_count{Call="INSPECT_IMAGE"} 2
AgentMetrics_DockerAPI_call_count{Call="LOAD_IMAGE"} 1
AgentMetrics_DockerAPI_call_count{Call="PULL_IMAGE"} 1
AgentMetrics_DockerAPI_call_count{Call="START_CONTAINER"} 1
# HELP AgentMetrics_DockerAPI_call_duration DockerAPI call duration in seconds individual
# TYPE AgentMetrics_DockerAPI_call_duration gauge
AgentMetrics_DockerAPI_call_duration{Call="CREATE_CONTAINER"} 0.257324464
AgentMetrics_DockerAPI_call_duration{Call="INSPECT_CONTAINER"} 0.00124233
AgentMetrics_DockerAPI_call_duration{Call="INSPECT_IMAGE"} 0.010489645
AgentMetrics_DockerAPI_call_duration{Call="LOAD_IMAGE"} 0.370162726
AgentMetrics_DockerAPI_call_duration{Call="PULL_IMAGE"} 19.683362793
AgentMetrics_DockerAPI_call_duration{Call="START_CONTAINER"} 0.43437413
# HELP AgentMetrics_DockerAPI_duration_seconds DockerAPI call duration in seconds
# TYPE AgentMetrics_DockerAPI_duration_seconds summary
AgentMetrics_DockerAPI_duration_seconds_sum{Call="CREATE_CONTAINER"} 0.257324464
AgentMetrics_DockerAPI_duration_seconds_count{Call="CREATE_CONTAINER"} 1
AgentMetrics_DockerAPI_duration_seconds_sum{Call="INSPECT_CONTAINER"} 0.004263372
AgentMetrics_DockerAPI_duration_seconds_count{Call="INSPECT_CONTAINER"} 3
AgentMetrics_DockerAPI_duration_seconds_sum{Call="INSPECT_IMAGE"} 0.011394566
AgentMetrics_DockerAPI_duration_seconds_count{Call="INSPECT_IMAGE"} 2
AgentMetrics_DockerAPI_duration_seconds_sum{Call="LOAD_IMAGE"} 0.370162726
AgentMetrics_DockerAPI_duration_seconds_count{Call="LOAD_IMAGE"} 1
AgentMetrics_DockerAPI_duration_seconds_sum{Call="PULL_IMAGE"} 19.683362793
AgentMetrics_DockerAPI_duration_seconds_count{Call="PULL_IMAGE"} 1
AgentMetrics_DockerAPI_duration_seconds_sum{Call="START_CONTAINER"} 0.43437413
AgentMetrics_DockerAPI_duration_seconds_count{Call="START_CONTAINER"} 1
# HELP AgentMetrics_ECSClient_call_count
# TYPE AgentMetrics_ECSClient_call_count counter
AgentMetrics_ECSClient_call_count{Call="SUBMIT_TASK_EVENTS"} 1
# HELP AgentMetrics_ECSClient_call_duration ECSClient call duration in seconds individual
# TYPE AgentMetrics_ECSClient_call_duration gauge
AgentMetrics_ECSClient_call_duration{Call="SUBMIT_TASK_EVENTS"} 0.071811231
# HELP AgentMetrics_ECSClient_duration_seconds ECSClient call duration in seconds
# TYPE AgentMetrics_ECSClient_duration_seconds summary
AgentMetrics_ECSClient_duration_seconds_sum{Call="SUBMIT_TASK_EVENTS"} 0.071811231
AgentMetrics_ECSClient_duration_seconds_count{Call="SUBMIT_TASK_EVENTS"} 1
# HELP AgentMetrics_StateManager_call_count
# TYPE AgentMetrics_StateManager_call_count counter
AgentMetrics_StateManager_call_count{Call="SAVE"} 15
# HELP AgentMetrics_StateManager_call_duration StateManager call duration in seconds individual
# TYPE AgentMetrics_StateManager_call_duration gauge
AgentMetrics_StateManager_call_duration{Call="SAVE"} 0.003184178
# HELP AgentMetrics_StateManager_duration_seconds StateManager call duration in seconds
# TYPE AgentMetrics_StateManager_duration_seconds summary
AgentMetrics_StateManager_duration_seconds_sum{Call="SAVE"} 0.09526237399999998
AgentMetrics_StateManager_duration_seconds_count{Call="SAVE"} 15
# HELP AgentMetrics_TaskEngine_call_count
# TYPE AgentMetrics_TaskEngine_call_count counter
AgentMetrics_TaskEngine_call_count{Call="ADD_TASK"} 1
# HELP AgentMetrics_TaskEngine_call_duration TaskEngine call duration in seconds individual
# TYPE AgentMetrics_TaskEngine_call_duration gauge
AgentMetrics_TaskEngine_call_duration{Call="ADD_TASK"} 6.2929e-05
# HELP AgentMetrics_TaskEngine_duration_seconds TaskEngine call duration in seconds
# TYPE AgentMetrics_TaskEngine_duration_seconds summary
AgentMetrics_TaskEngine_duration_seconds_sum{Call="ADD_TASK"} 6.2929e-05
AgentMetrics_TaskEngine_duration_seconds_count{Call="ADD_TASK"} 1
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 3.1468e-05
go_gc_duration_seconds{quantile="0.25"} 4.6355e-05
go_gc_duration_seconds{quantile="0.5"} 5.5721e-05
go_gc_duration_seconds{quantile="0.75"} 8.7131e-05
go_gc_duration_seconds{quantile="1"} 0.003637265
go_gc_duration_seconds_sum 0.006573597
go_gc_duration_seconds_count 16
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 84
# HELP go_info Information about the Go environment.
# TYPE go_info gauge
go_info{version="go1.9.7"} 1
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 4.147696e+06
# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.
# TYPE go_memstats_alloc_bytes_total counter
go_memstats_alloc_bytes_total 2.2890728e+07
# HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.
# TYPE go_memstats_buck_hash_sys_bytes gauge
go_memstats_buck_hash_sys_bytes 1.447925e+06
# HELP go_memstats_frees_total Total number of frees.
# TYPE go_memstats_frees_total counter
go_memstats_frees_total 204574
# HELP go_memstats_gc_cpu_fraction The fraction of this program's available CPU time used by the GC since the program started.
# TYPE go_memstats_gc_cpu_fraction gauge
go_memstats_gc_cpu_fraction 2.0084119566021017e-05
# HELP go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata.
# TYPE go_memstats_gc_sys_bytes gauge
go_memstats_gc_sys_bytes 520192
# HELP go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use.
# TYPE go_memstats_heap_alloc_bytes gauge
go_memstats_heap_alloc_bytes 4.147696e+06
# HELP go_memstats_heap_idle_bytes Number of heap bytes waiting to be used.
# TYPE go_memstats_heap_idle_bytes gauge
go_memstats_heap_idle_bytes 2.260992e+06
# HELP go_memstats_heap_inuse_bytes Number of heap bytes that are in use.
# TYPE go_memstats_heap_inuse_bytes gauge
go_memstats_heap_inuse_bytes 6.291456e+06
# HELP go_memstats_heap_objects Number of allocated objects.
# TYPE go_memstats_heap_objects gauge
go_memstats_heap_objects 29301
# HELP go_memstats_heap_released_bytes Number of heap bytes released to OS.
# TYPE go_memstats_heap_released_bytes gauge
go_memstats_heap_released_bytes 0
# HELP go_memstats_heap_sys_bytes Number of heap bytes obtained from system.
# TYPE go_memstats_heap_sys_bytes gauge
go_memstats_heap_sys_bytes 8.552448e+06
# HELP go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection.
# TYPE go_memstats_last_gc_time_seconds gauge
go_memstats_last_gc_time_seconds 1.5484726661935096e+09
# HELP go_memstats_lookups_total Total number of pointer lookups.
# TYPE go_memstats_lookups_total counter
go_memstats_lookups_total 333
# HELP go_memstats_mallocs_total Total number of mallocs.
# TYPE go_memstats_mallocs_total counter
go_memstats_mallocs_total 233875
# HELP go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures.
# TYPE go_memstats_mcache_inuse_bytes gauge
go_memstats_mcache_inuse_bytes 3472
# HELP go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system.
# TYPE go_memstats_mcache_sys_bytes gauge
go_memstats_mcache_sys_bytes 16384
# HELP go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures.
# TYPE go_memstats_mspan_inuse_bytes gauge
go_memstats_mspan_inuse_bytes 101232
# HELP go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system.
# TYPE go_memstats_mspan_sys_bytes gauge
go_memstats_mspan_sys_bytes 131072
# HELP go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place.
# TYPE go_memstats_next_gc_bytes gauge
go_memstats_next_gc_bytes 7.471776e+06
# HELP go_memstats_other_sys_bytes Number of bytes used for other system allocations.
# TYPE go_memstats_other_sys_bytes gauge
go_memstats_other_sys_bytes 680195
# HELP go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator.
# TYPE go_memstats_stack_inuse_bytes gauge
go_memstats_stack_inuse_bytes 884736
# HELP go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator.
# TYPE go_memstats_stack_sys_bytes gauge
go_memstats_stack_sys_bytes 884736
# HELP go_memstats_sys_bytes Number of bytes obtained from system.
# TYPE go_memstats_sys_bytes gauge
go_memstats_sys_bytes 1.2232952e+07
# HELP go_threads Number of OS threads created.
# TYPE go_threads gauge
go_threads 9
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 0.31
# HELP process_max_fds Maximum number of open file descriptors.
# TYPE process_max_fds gauge
process_max_fds 1024
# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 31
# HELP process_resident_memory_bytes Resident memory size in bytes.
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 1.9263488e+07
# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.
# TYPE process_start_time_seconds gauge
process_start_time_seconds 1.54847142136e+09
# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 3.4983936e+07
# HELP process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes.
# TYPE process_virtual_memory_max_bytes gauge
process_virtual_memory_max_bytes -1
# HELP promhttp_metric_handler_requests_in_flight Current number of scrapes being served.
# TYPE promhttp_metric_handler_requests_in_flight gauge
promhttp_metric_handler_requests_in_flight 1
# HELP promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code.
# TYPE promhttp_metric_handler_requests_total counter
promhttp_metric_handler_requests_total{code="200"} 6
promhttp_metric_handler_requests_total{code="500"} 0
promhttp_metric_handler_requests_total{code="503"} 0

あくまで Agent 自信のメトリクスを出しているだけのようだ。
Image Pull にかかった時間などが取れるみたいなので、起動が遅いといったときに、切り分けの情報に使えそう。

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T10:47:29+09:00

AWSで開発用のユーザーをつくってCloud9を使う(Permissionの備忘録)

背景

Cloud9でlaravel開発環境の構築で開発用のuserをつくった方がいいと思ったので作成。

手順

参考：EC2にSSH接続用のユーザーを作

ユーザー作成
$ sudo su -

# useradd test-usr
# passwd test-usr
sudoが実行できるように変更
# sudo visudo

#追記する
test-usr    ALL=(ALL)       ALL
test-usrで入り直す
# exit

$ sudo su - test-usr
sshキーの作成
$ cd /home/dev-usr

$ mkdir .ssh

$ cd .ssh
$ ssh-keygen -t rsa
#今回はパスフレーズなしで作成した
Amazon Linuxに合わせて名称変更とPermission設定
$ mv id_rsa.pub authorized_keys

$ chmod 600 authorized_keys
$ cd ..
$ chmod 700 .ssh
ローカル環境に鍵を保存する。catコマンドでコピペして作成。
ローカルではaws-test-usr.pemで保存。
$ cat id_rsa

#コピペ
-----BEGIN RSA PRIVATE KEY-----
・
・・・
-----END RSA PRIVATE KEY-----
sshd_configに追記
$ exit
$ sudo su -

# vi /etc/ssh/sshd_config

#なければ追記する
/etc/ssh/sshd_configAuthorizedKeysFile      .ssh/authorized_keys
ローカルからログインしてみる
$ ssh -i "aws-test-usr.pem" test-usr@xx.xx.xx.xx
ログインできない
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'aws-test-usr.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "aws-test-usr.pem": bad permissions
dev-usr@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Permissionが0664ではエラーが出るためPermission変更
$ chmod 600 aws-test-usr.pem
ログイン
$ ssh -i "aws-test-usr.pem" test-usr@xx.xx.xx.xx

Last login: Fri Jan 25 20:45:51 2019

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
できました。

Permissionについておさらい（備忘録）
$ll

-rw------- 1 dev-usr dev-usr  434  1月 25 20:47 authorized_keys
分解する。

①- ②rw- ③r-- ④r-- ⑤test-usr ⑥test-usr ・・・・⑦authorized_keys

1、3、3、3で分かれるイメージ。

①はファイルのタイプ
②の「rw-」は⑤の「test-usr」という所有者のPermission
③の「---」は⑥「test-usr」というグループのPermission
④の「---」とその他(どのグループにも属さない）のユーザのPermission
⑦ディレクトリ名

Permissionの種類

'- Permissionなし
r 読み
w 書き
x 実行

番号にすると

0---、1--x、2-w-、3-wx、4r--、5r-x、6rw-、7rwx

例
$ chmod 600 authorized_keys

#authorized_keysの、所有者にのみ、読み書き権限を付与
参考

新しくつくったuserでCloud9接続

※新しくつくったuserのauthorized_keysに公開鍵をコピー



接続できた。

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T10:47:29+09:00

AWSで開発用のユーザーをつくってCloud9でlaravelを立上げる(Permissionの備忘録)

背景

Cloud9でlaravel開発環境の構築で開発用のuserをつくった方がいいと思ったので作成。

手順

参考：EC2にSSH接続用のユーザーを作

ユーザー作成
$ sudo su -

# useradd test-usr
# passwd test-usr
sudoが実行できるように変更
# sudo visudo

#追記する
test-usr    ALL=(ALL)       ALL
test-usrで入り直す
# exit

$ sudo su - test-usr
sshキーの作成
$ cd /home/dev-usr

$ mkdir .ssh

$ cd .ssh
$ ssh-keygen -t rsa
#今回はパスフレーズなしで作成した
Amazon Linuxに合わせて名称変更とPermission設定
$ mv id_rsa.pub authorized_keys

$ chmod 600 authorized_keys
$ cd ..
$ chmod 700 .ssh
ローカル環境に鍵を保存する。catコマンドでコピペして作成。
ローカルではaws-test-usr.pemで保存。
$ cat id_rsa

#コピペ
-----BEGIN RSA PRIVATE KEY-----
・
・・・
-----END RSA PRIVATE KEY-----
sshd_configに追記
$ exit
$ sudo su -

# vi /etc/ssh/sshd_config

#なければ追記する
/etc/ssh/sshd_configAuthorizedKeysFile      .ssh/authorized_keys
ローカルからログインしてみる
$ ssh -i "aws-test-usr.pem" test-usr@xx.xx.xx.xx
ログインできない
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'aws-test-usr.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "aws-test-usr.pem": bad permissions
dev-usr@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Permissionが0664ではエラーが出るためPermission変更
$ chmod 600 aws-test-usr.pem
ログイン
$ ssh -i "aws-test-usr.pem" test-usr@xx.xx.xx.xx

Last login: Fri Jan 25 20:45:51 2019

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
できました。

Permissionについておさらい（備忘録）
$ll

-rw------- 1 dev-usr dev-usr  434  1月 25 20:47 authorized_keys
分解する。

①- ②rw- ③r-- ④r-- ⑤test-usr ⑥test-usr ・・・・⑦authorized_keys

1、3、3、3で分かれるイメージ。

①はファイルのタイプ
②の「rw-」は⑤の「test-usr」という所有者のPermission
③の「---」は⑥「test-usr」というグループのPermission
④の「---」とその他(どのグループにも属さない）のユーザのPermission
⑦ディレクトリ名

Permissionの種類

'- Permissionなし
r 読み
w 書き
x 実行

番号にすると

0---、1--x、2-w-、3-wx、4r--、5r-x、6rw-、7rwx

例
$ chmod 600 authorized_keys

#authorized_keysの、所有者にのみ、読み書き権限を付与
参考

新しくつくったuserでCloud9接続

※新しくつくったuserのauthorized_keysに公開鍵をコピー



接続できた。

laravelプロジェクト作成
$ ~/composer.phar create-project --prefer-dist laravel/laravel test-laravel
Permissionのエラー
Installing laravel/laravel (v5.7.19)


  [ErrorException]
  mkdir(): Permission denied
Permissionの設定変更で解決
$ cd /var/www/environment
$ sudo chmod 775 environment
メモリ不足でエラー
The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details
下記を参照してスワップファイルを作成して解決
Cloud9でlaravel開発環境の構築

cloud9を開いた時の.c9のインストールでエラー

参考

sudoをパスワードなしで使えるようにして解決
$ sudo visudo

#追記
test-usr ALL=NOPASSWD: ALL
ブラウザでlaravelページを開いた時にエラー
The stream or file "/var/www/test-laravel/storage/logs/laravel-2019-01-26.log" could not be opened: failed to open stream: Permission denied
またParmissionでエラー
下記の対応で解決
#apacheに権限付与して見た
$ sudo usermod -a -G www apache
$ sudo usermod -a -G dev-usr apache

#再起動
$ sudo systemctl restart httpd

#問題のログファイルを削除
$ sudo rm laravel-2019-01-26.log
起動しました

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T10:23:18+09:00

[AWS] AWS CLIのインストール&設定メモ

はじめに

インストール&設定メモと、エラー解決メモ。
環境はmacOS Mojave。

インストール時のエラー
$ curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
$ sudo python get-pip.py
$ sudo pip install awscli
# 以下の３つのエラーが出る
# matplotlib 1.3.1 requires nose, which is not installed.
# matplotlib 1.3.1 requires tornado, which is not installed.
# Cannot uninstall 'six'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
インストール時のエラー解決
# 以下のエラーについて
# matplotlib 1.3.1 requires nose, which is not installed.
# matplotlib 1.3.1 requires tornado, which is not installed.
$ sudo easy_install nose
$ sudo easy_install tornado
# 以下のエラーについて
# Cannot uninstall 'six'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
$ sudo -H pip install awscli --upgrade --ignore-installed six
# これで成功する
ユーザーの追加

AWS CLI用のユーザーがなければAMIから作成する。
アクセスの種類として、プログラムによるアクセスにチェックを入れる。
AWSのコンソールにアクセスできるユーザーにしたい場合はその下にもチェックが必要。

今回は一旦フルアクセスを許可しているが、ここは適宜適切なアクセス権の付与が必要

ユーザーを追加するとアクセスキーIDとシークレットアクセスキーが発行されるのでこれをコピーする。

CLI側の設定
$ aws configure
# AWS Access Key ID [None]: XXXXXXXXXXXXXXXX　＊適宜変更
# AWS Secret Access Key [None]: XXXXXXXXXXXXXXXX　＊適宜変更
# Default region name [None]: ap-northeast-1 ＊アジアパシフィック（東京）にした 参考: https://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html
# Default output format [None]: json

　 Tweet
Qiitaで続きを読む

投稿日：2019-01-26T09:47:20+09:00

【AWS メモ⑤】VPC Peering を使用して VPC 間の EC2 同士を接続する

仕事で使う機会があったので備忘録的なものを残しておく。

VPC Peering でできること

・異なるVPC間を直接接続することができる。（VPC同士を直接接続する技術なのでVPC間の接続にEC2にパブリックIPを割り振る必要がない）

・アカウントが異なる場合にも接続できる。（アカウントが異なる場合、ペアリング認証時に接続先 VPCのアカウントでの承諾する必要）

・複数のVPCとの接続ができる。

VPC Peering でできないこと

・CIDRが一致または重複するVPC間の接続はできない。

・ペアリング先のVPCがペアリングしているVPCに直接接続はできない。

　→ 接続するには、VPC-AからVPC-Bへ接続後、VPC-Cへ接続する必要がある。（NAT等も同様）

環境

以下の条件の AWS 環境で VPC Peering を確立する。

・VPC は VPC-A と VPC-B の二つ

・VPC-A 、VPC-B はそれぞれ subnet-a、subnet-b サブネットを持ち、EC2が1台ずつ起動している

・subnet-a にはクライアント端末からの SSH 接続のみ有効とするセキュリティグループを設定

・subnet-b には全ての接続を遮断するセキュリティグループを設定（のちにsubnet-aからの接続のみ許可する設定を付与）

イメージ

VPC Peering の作成

サービスから VPC を選択して、 VPC画面遷移後、左端のメニューから「ピアリング接続」を選択する。

「ピア接続の作成」を押下する。

ボタンを押下すると、ピア接続作成画面に遷移するので、

各項目に設定値を入れていく。

・ピア接続ネームタグ・・・EC2などにあるTagを同じ

・VPC(リクエスタ)　・・・VPC間の接続許可を申請する側のVPC（ここではVPC-Aを設定）

・アカウント　　　　・・・許可する側のアカウント

・リージョン　　　　・・・今回は同じリージョンなので「このリージョン」を選択

・VPC(アクセプタ)　・・・VPC間の接続を許可する側のVPC（ここではVPC-Bを設定）

設定完了後、「ピア接続の作成」を押下する。

接続の作成が完了すると、承諾待ちのピア接続が作成される。

アクションタブから「リクエストの承諾」を選択するとピア接続が確立する。

VPC-Aのルートテーブルには、送信先に VPC-BのCIDRを入力。
ターゲットには VPCペアリング接続を選択（Peering Connectionを選ぶとペアリングの候補がでる）

VPC-Bのルートテーブルには、送信先に VPC-AのCIDRを入力。

次に、subnet-bに設定されているセキュリティグループに VPC または subnet からの接続を許可する設定を行う必要がある。
なるべく細かくした方がいいと思うのでsubnet 単位で設定。

接続の確認

インターネットからの接続ができる VPC-A の EC2 に接続
# 作業端末から接続
$ ssh -i access.pem ec2-user@<EC2-AのパブリックIP>
VPC-Aの EC2 から VPC-B の EC2 に接続
# EC2-AからEC2-Bへの接続
$ ssh -i access.pem ec2-user@<EC2-BのプライベートIP>

　 Tweet
Qiitaで続きを読む

20190126のAWSに関する記事は15件です。

AWSでDjangoのWEBサーバーを作る（Amazon Linux 2、HTTPS化）

インスタンスの作成

ドメインを取得

チュートリアル: Amazon Linux 2 に LAMP ウェブサーバーをインストールする

CA 署名証明書の取得

Certbot を自動化

Djangoやーる

HelloWorld

バックグラウンドで実行

AWSアカウントのMFAは端末に登録されている

MFA（Multi-Factor Authentication）とは

この記事で伝えたいこと

経緯

【無料】bitwardenをawsにserverlessでセットアップする

TL;DR

Requirements

Structure

Setup

1. iAMユーザーを作る → aws-cliに追加する

2. Sourceのclone～デプロイ

3. クライアント側の設定

番外編：Chromeからのインポート

Chromeでエクスポート

bitwardenにインポート

〆

cloud9 と GitHub を使ってRailsアプリを開発する際の下準備

内容

なぜcloud9上でRailsアプリを開発するのか？

具体的な下準備

cloud9 に git をインストール

バージョンを指定してRailsのインストール

cloud9からGitHubにUP

2019年になってAWSのSLA設定が急増している

雑感

AWS認定ソリューションアーキテクト アソシエイトに合格したときの勉強方法

AWS IAMの基本概念を概念モデルで整理した

全体像

IAM Policy

IAM Role Policy Attachment

IAM Role

おわりに

amazon cli

amazon CLIをインストールしてみました

Global Accelerator はターゲットから何秒レスポンスがないとタイムアウトするのか

概要

構成

Webサーバー

計測結果

まとめ

AWS活用に向けて

どのようにAWSを使用すればいいのか

IAMユーザーを作成する

Trusted Adviserを設定する

CloudTrailを設定する

CloudWatchで利用料金を監視する

AWS ECS Agent の Prometheus Metrics を試してみる

機能を有効化する

メトリクスの一覧

AWSで開発用のユーザーをつくってCloud9を使う(Permissionの備忘録)

背景

手順

Permissionについておさらい（備忘録）

分解する。

1、3、3、3で分かれるイメージ。

Permissionの種類

番号にすると

新しくつくったuserでCloud9接続