概要 lambda使っててAPIを叩きたい時にシークレットキーなどの情報を環境変数に平文で置きたくないですよね． その時に用いるサービスがKMS(Key Management Service)です． この記事ではKMSを用いてlambda_functionの中で使用する環境変数の暗号化からプログラム中で復号化するところまでご紹介します(私自身AWS初心者で嵌ってしまったポイントがあるので記事にしました)． lambdaで使用する言語はPythonで，コンソール上で操作を行います． 流れ ざっくりした流れは以下のようになります． KMSのカスタマー管理型キーの作成 対象のLambda関数に KMS:Decrypt 権限を与える 環境変数の作成・暗号化 関数上で暗号化された環境変数の復号化 1. KMSのカスタマー管理型キーの作成 KMSの管理コンソールへ行き，キーの作成を行います． キーのタイプの選択がありますが，対称でいいと思います． 今回は「user/kms-test」というエイリアスをつけました． 説明やタグは適当に設定しましょう． 次のキーの管理アクセス許可の定義やキーの使用アクセス許可の定義は各々の設定に合わせます． ここでlambda関数にのみ権限を与えるのが本来いいとは思います(が面倒なので私はAdminに設定しました)． たとえばこちらの記事ではこの時点でlambda関数にロールを設定しています． 2. 対象のLambda関数に KMS:Decrypt 権限を与える まず実行ロールの設定します．IAMコンソールのこちらのページにアクセスしてポリシーの作成を行います． 下の図のように設定を行います．サービスにKMS，アクションにDecypt，リソースに先程作成したKMSのカスタマー管理キーのARNを記述します． 名前はlambda-kms-decrypt-policyとしました． 次にlambda関数に今作成したポリシーをアタッチします． こちらのページにアクセスして対象のlambda関数のロールを選択します．するとポリシーをアタッチしますというボタンがあると思うのでクリックしてください．そこで先程作成したポリシーを選択します． 3. 環境変数の作成・暗号化 続いてlambdaでの作業になります．コンソールのlambdaのページから対象の関数のところに行きます． 設定→環境変数で環境変数の作成をクリックします． 今回はTEST_ENCRYPTという環境変数を試しに作ってみます． 暗号化の設定のところで転送時の暗号化に使用するヘルパーの有効化にチェックを入れると暗号化できるようになります． そこで先程作成したKMSキーを選択します．すると下の図のように値が暗号化されました． これで環境変数の設定は以上です． 4. 関数上で暗号化された環境変数の復号化 lambda_functionの例を示します． 以下のコードをテストするとログに暗号化された文字列と復号化された文字列が表示されるはずです． lambda_function.py import json import boto3,os from base64 import b64decode def lambda_handler(event, context): ENCRYPTED = os.environ['TEST_ENCRYPT'] print(ENCRYPTED) DECRYPTED = boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED),EncryptionContext={'LambdaFunctionName': os.environ['AWS_LAMBDA_FUNCTION_NAME']})['Plaintext'].decode('utf-8') print(DECRYPTED) return { 'statusCode': 200, 'body': json.dumps('Hello from Lambda!') } 最後に 私もAWS初心者のためこれで正しいのか正直わかりません．有識者の方，助言などぜひよろしくお願いします． あと，転送時の暗号化に使用するヘルパーの有効化についてですが，こちらはCDKからは操作できないのでしょうか？コンソール上だけからの設定だと面倒くさいなと思いました... 参考 https://dev.classmethod.jp/articles/decrypt-sensitive-data-with-kms-on-lambda-invocation/ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console https://aws.amazon.com/jp/premiumsupport/knowledge-center/kms-invalidciphertextexception/

概要 lambda使っててAPIを叩きたい時にシークレットキーなどの情報を環境変数に平文で置きたくないですよね． その時に用いるサービスがKMS(Key Management Service)です． この記事ではKMSを用いてlambda_functionの中で使用する環境変数の暗号化からプログラム中で復号化するところまでご紹介します(私自身AWS初心者で嵌ってしまったポイントがあるので記事にしました)． lambdaで使用する言語はPythonで，コンソール上で操作を行います． 流れ ざっくりした流れは以下のようになります． KMSのカスタマー管理型キーの作成 対象のLambda関数に KMS:Decrypt 権限を与える 環境変数の作成・暗号化 関数上で暗号化された環境変数の復号化 1. KMSのカスタマー管理型キーの作成 KMSの管理コンソールへ行き，キーの作成を行います． キーのタイプの選択がありますが，対称でいいと思います． 今回は「user/kms-test」というエイリアスをつけました． 説明やタグは適当に設定しましょう． 次のキーの管理アクセス許可の定義やキーの使用アクセス許可の定義は各々の設定に合わせます． ここでlambda関数にのみ権限を与えるのが本来いいとは思います(が面倒なので私はAdminに設定しました)． たとえばこちらの記事ではこの時点でlambda関数にロールを設定しています． 2. 対象のLambda関数に KMS:Decrypt 権限を与える まず実行ロールの設定します．IAMコンソールのこちらのページにアクセスしてポリシーの作成を行います． 下の図のように設定を行います．サービスにKMS，アクションにDecypt，リソースに先程作成したKMSのカスタマー管理キーのARNを記述します． 名前はlambda-kms-decrypt-policyとしました． 次にlambda関数に今作成したポリシーをアタッチします． こちらのページにアクセスして対象のlambda関数のロールを選択します．するとポリシーをアタッチしますというボタンがあると思うのでクリックしてください．そこで先程作成したポリシーを選択します． 3. 環境変数の作成・暗号化 続いてlambdaでの作業になります．コンソールのlambdaのページから対象の関数のところに行きます． 設定→環境変数で環境変数の作成をクリックします． 今回はTEST_ENCRYPTという環境変数を試しに作ってみます． 暗号化の設定のところで転送時の暗号化に使用するヘルパーの有効化にチェックを入れると暗号化できるようになります． そこで先程作成したKMSキーを選択します．すると下の図のように値が暗号化されました． これで環境変数の設定は以上です． 4. 関数上で暗号化された環境変数の復号化 lambda_functionの例を示します． 以下のコードをテストするとログに暗号化された文字列と復号化された文字列が表示されるはずです． lambda_function.py import json import boto3,os from base64 import b64decode def lambda_handler(event, context): ENCRYPTED = os.environ['TEST_ENCRYPT'] print(ENCRYPTED) DECRYPTED = boto3.client('kms').decrypt(CiphertextBlob=b64decode(ENCRYPTED),EncryptionContext={'LambdaFunctionName': os.environ['AWS_LAMBDA_FUNCTION_NAME']})['Plaintext'].decode('utf-8') print(DECRYPTED) return { 'statusCode': 200, 'body': json.dumps('Hello from Lambda!') } 最後に 私もAWS初心者のためこれで正しいのか正直わかりません．有識者の方，助言などぜひよろしくお願いします． あと，転送時の暗号化に使用するヘルパーの有効化についてですが，こちらはCDKからは操作できないのでしょうか？コンソール上だけからの設定だと面倒くさいなと思いました... 参考 https://dev.classmethod.jp/articles/decrypt-sensitive-data-with-kms-on-lambda-invocation/ https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console https://aws.amazon.com/jp/premiumsupport/knowledge-center/kms-invalidciphertextexception/

AWSのCodeDeployでデプロイ失敗したので、エラーを読み解きます。 エラー内容 The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. これだけでは具体的なエラー内容が特定できなかったので、/var/log/aws/codedeploy-agent/codedeploy-agent.logに記載されたCodeDeploy Agentのログを確認します。 tailコマンドで最終行から10行を出力します。 $ tail -10 /var/log/aws/codedeploy-agent/codedeploy-agent.log 私の場合、以下のようなエラーログが得られました。 codedeploy-agent.logの内容 Script does not exist at specified location スクリプトが存在しないことによるエラーということが判明しました。 AWSのCodeDeployで使用するappspec.ymlで指定したディレクトリ・ファイルが適切に配置されていなかったため、今回の事象が発生したようです。

初めての投稿です。 railsのAction_textを使ってAWSのS3に画像を保存する方法を探していて、自分で忘れないようにここに残します。 環境 rails 6.0.0 開発しているアプリは単なるメモアプリですが、以下のように編集されたメモがJavaScriptで自動保存されるようにしています。 実装方法 まず、AWSでバケットを作成していることを前提としています。 保存したいバケットを選択→アクセス許可と進んでいくと下の方にCross-Origin Resource Sharing (CORS)というところがあります。 編集するをクリックして以下を記述します。 [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "PUT", "POST", "DELETE" ], "AllowedOrigins": [ "*" ], "ExposeHeaders": [] } ] ...終わりです。笑 その後、localで確認します。 【更新：解決?】【Rails】ActionTextでアップロードした画像の保存先がローカルから変更できない? この方の追記を参考に画像をドラッグ&ドロップした後にAction_textの通常の画像添付機能を使ったら、その後はどちらの方法でも保存できるようになりました。 謎です... ですが、僕はできましたので是非やってみてください。笑

Lightsailで、LAMP環境を立ち上げたのですが、phpmyadminへのアクセスを試みたものの、 セキュリティ設定がされているようで、試行錯誤したので、メモを残しておきます。 先人たちの教えに基づき、あれこれ試したものの、肝心のフォルダがないという惨劇。。。 /opt/bitnami/apps のフォルダが、、、ない。 設定ファイルの場所 で、結局、どこに目当てのファイルがあったかというと、、、ここにありました！！ /opt/bitnami/apache/conf/bitnami/phpmyadmin.conf Require local を 以下の用意に書き換えます。 Alias /phpmyadmin "/opt/bitnami/phpmyadmin" <Directory "/opt/bitnami/phpmyadmin"> Options -Indexes +FollowSymLinks -MultiViews #AllowOverride All AllowOverride None #Require local <IfVersion < 2.3> Order allow,deny Allow from all Satisfy all </IfVersion> <IfVersion >= 2.3> Require all granted </IfVersion> ErrorDocument 403 "For security reasons, this URL is only accessible using localhost (127.0.0.1) as the hostname." # AuthType Basic # AuthName phpmyadmin # AuthUserFile "/opt/bitnami/apache/conf/users" # Require valid-user </Directory> 変更したら、以下のコマンドで、apacheを再起動します。 sudo /opt/bitnami/ctlscript.sh restart アクセスの確認 http://[IPアドレス]/phpmyadmin にアクセスしてみます。 以下のログイン画面が表示されれば、設定は成功です！！ 補足: ユーザー名とパスワードの取得 phpmyadminのアクセスに必要なパスワードは、以下の手順で取得できます。 ホームディレクトリで、以下のコマンドを実行 cat bitnami_credentials パスワードが表示されるのでコピーする。 ユーザー名は、root です。 　

StepFunctions で Lambdaを制御するシステムを AWS CDK で構築する 試行錯誤しているうちにChromeのタブが増えすぎてどのサイトを見ていたか忘れてしまう悪い癖があるので、どんな思考回路でどのリンクを参考にしたかまとめる。 試行錯誤 まず CDK で簡単にリソースを作成する（S3） とりあえずこれ参考にやってみる。 https://dev.classmethod.jp/articles/trying-aws-cdk-tutorial-with-typescript/ と思ったが依存関係がごちゃごちゃして意味がわからないので綺麗にする。 https://qiita.com/non0311/items/664cf74d9ff4bad9cf46 Lambda 作る こいつ参考にpythonのLambda構築する。 https://dev.classmethod.jp/articles/aws-cdk-lambda-dependency-at-python/ デプロイしたが怒られた。 TestCdkStack failed: Error: This stack uses assets, so the toolkit stack must be deployed to the environment (Run "cdk bootstrap aws://unknown-account/unknown-region") 指示に従う。 できた。 StepFunctions（本命） こいつ参考に作成。stepfunctionについても知らないこと多かったから助かった。 https://dev.classmethod.jp/articles/developers-io-2020-connect-aws-cdk-aws-step-functions/ 感想 嬉しい。

はじめに AWSのEC2でRailsアプリをデプロイしたのでメモとして残しておきます。 今回はEC2にRailsアプリの配置をしていきます 自分の手順書としてのメモですので画像はありません。あしからず。 前提としてEC2のサーバー環境構築が終わっている状態とします。 環境 nginx 1.12.2 PostgreSQL 11.5 node 12.22.1 yarn 1.22.5 rbenv 1.1.2 ruby 2.6.6 GitHub連携に必要な公開鍵作成 最初にgitに関する設定ファイルを生成します。 .gitconfigファイルを新たに作ります。 サーバー $ cd ~ $ vim .gitconfig 以下を記述していきます。 [user] name = your_name #gitに登録した自分の名前 email = hoge@gmail.com #git登録時の自分のメアド [alias] #お好きに a = add b = branch ch = checkout st = status [color] #色付け ui = true # githubの場合 [url "github:"] #pull、pushのための設定 InsteadOf = https://github.com/ InsteadOf = git@github.com: # bitbucketの場合 [url "bitbucket:"] InsteadOf = https://ユーザ名@bitbucket.org/ InsteadOf = git@bitbucket.org: shift+ZZで保存＆終了 次はアプリを配置するディレクトリを作成します。 サーバー構築 $ cd / $ sudo mkdir var/www $ sudo mkdir var/www/rails $ sudo chown ユーザ名 var #ユーザに所有権を与える $ cd var/ $ sudo chown -R ユーザ名 www　#このディレクトリ以下の所有権をユーザに与える gitの接続に必要な鍵を格納するディレクトリに移動します。 サーバー $ cd ~ $ chmod 700 .ssh #所有者に対して、読み取り、書き込み、実行の権限を与える $ cd .ssh サーバー $ ssh-keygen -t rsa 以下のメッセージが表示されるので、「aws_git_rsa」と入力 Enter file in which to save the key ():aws_git_rsa 何もせずにエンター Enter passphrase (empty for no passphrase): 何もせずにエンター Enter same passphrase again lsコマンドでaws_key_rsaとaws_key_rsa.pubが生成されたことを確認してください configファイルを生成します。 $ vi config ----------------------------- # githubの場合以下を追記 Host github github.com Hostname github.com User git IdentityFile ~/.ssh/aws_git_rsa # bitbucketの場合以下を追記 Host bitbucket Hostname bitbucket.org User git IdentityFIle ~/.ssh/aws_git_rsa ----------------------------- `Shift`+`ZZ`で保存＆終了 公開鍵の中身を表示する $ cat aws_git_rsa.pub ssh-rsa~~~ catで表示させた公開鍵をgithubにアクセスして登録します。 公開鍵をGitHubにアップ https://github.com/settings/ssh 上記のページでGitHubで公開鍵の設定が可能です。 GitHubのページへ遷移した後、「New SSH Key」ボタンを選択します。 以下の通り項目に記載 1 . Title：「aws_git_rsa.pub」 #公開鍵名 2 . Key：「ssh-rsa~~~」 #catで確認した公開鍵の中身 「Add SSH Key」ボタンをクリックする。 GitHub側の設定が終われば、ターミナルから接続が可能か確認してみます。 サーバー ターミナルへ戻り設定ファイルの権限を変更(読み取りと書き込みの許可) $ chmod 600 config GitHubへの接続確認。途中の質問にはYesで。GitHubのユーザ名が出てくれば成功。 $ ssh -T git@github.com Githubからアプリをクローンする いよいよアプリをクローンする時がきました。 サーバー $ cd ~ $ cd /var/www/rails $ git clone git@github.com:~~~~~~ git cloneの後に続くURLはGitHubの下記の手順で取得します。 1 . githubからデプロイしたいアプリのリモートレポジトリへ移動 2 . 「code」を選択 3 . 「SSH」を選択して、表示されているURLをコピーする lsコマンドでアプリ名が記載されているディレクトリが存在すれば、クローンは成功です。 クローンしたアプリに移動し、必要なGemをインストールしましょう。 サーバー $ cd アプリ名 $ bundle install アプリのシークレットの設定 クローンが成功したら、シークレットを生成します。 まずcredentials.yml.encの編集を行っていきます。 configディレクトリに格納されているファイルを確認しましょう サーバー(/var/www/rails/アプリ名/) $ ls config これから、「credentials.yml.enc」の中身を編集していきます。 1.マスターキーを作成 「credentials.yml.enc」を編集する為には 「master.key」が必要です。 ローカル環境の同ディレクトリには格納されていますが サーバー環境の同ディレクトリには格納されていません。 「master.key」はGit管理しない様に設定されていて 本番サーバー上でプロジェクトのリポジトリをクローンしても、このファイルはついてこない様になっております。 そこで手動で「master.key」を生成します。 ローカル環境のクローン元のアプリディレクトリにて、以下の手順を実行してください。 ローカル(アプリ名/config) $ vim master.key 表示された英数字をメモします。 次にサーバー環境で以下の手順を実行します。 サーバー(/var/www/rails/アプリ名/) $ cd config $ vim master.key # ローカルのmaster.keyの値を入力 26286c42~~~ Shift+ZZで保存＆終了 これで「credentials.yml.enc」を編集する準備ができました。 2.credentials.yml.encを編集 初めにローカル環境にてシークレットを生成します。 ローカル環境にて以下の手順を実行してください。 ローカル(アプリ名) $ rake secret jflaskfdk~~~~~~ 表示されたシークレットキーをコピーします。 次はローカル環境で生成した、シークレットキーを「credential.yml.enc」に記載します。 サーバー環境でクローンした、アプリで以下の手順を実行します サーバー環境(/var/www/rails/アプリ名/) $ EDITOR=vim bin/rails credentials:edit # aws: # access_key_id: 123 # secret_access_key: 345 # Used as the base secret for all MessageVerifiers in Rails, including the one protecting cookies. secret_key_base: 01078f3faf42140621e86753aabcb~~~~ #シークレットキーをコピー Shift+ZZで保存＆終了 これでアプリのシークレットの設定は完了です Nginxの設定 Nginx（エンジンエックス）の設定ファイルを修正します。 以下の手順を実行します サーバー(/var/www/rails/アプリ名/) $ cd /etc/nginx/conf.d/ $ sudo vim アプリ名.conf # log directory error_log /var/www/rails/アプリ名/log/nginx.error.log; #自分のアプリケーション名に変更 access_log /var/www/rails/アプリ名/log/nginx.access.log; #自分のアプリケーション名に変更 upstream unicorn_server { server unix:/var/www/rails/アプリ名/tmp/sockets/.unicorn.sock fail_timeout=0; #自分のアプリケーション名に変更 } server { listen 80; client_max_body_size 4G; server_name ~~~.~~~.~~~.~~~; #アプリのElastic IPに変更 keepalive_timeout 5; # Location of our static files root /var/www/rails/アプリ名/public; #自分のアプリケーション名に変更 location ~ ^/assets/ { root /var/www/rails/アプリ名/public; #自分のアプリケーション名に変更 } location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; if (!-f $request_filename) { proxy_pass http://unicorn_server; break; } } error_page 500 502 503 504 /500.html; location = /500.html { root /var/www/rails/アプリ名/public; #自分のアプリケーション名に変更 } } Shift+ZZで保存＆終了 そして権限の変更をします。 サーバー(/var/www/rails/アプリ名/) $ cd /var/lib $ sudo chmod -R 775 nginx #nginx以下のファイルに所有者、所有グループに全ての権限を付与、その他に読み取りと実行を許可 Unicornの設定 Unicornはアプリケーションサーバーの一種です。 アプリ本体を格納するUnicornを設定していきましょう。 1.Unicornのインストール GemファイルにUnicornを追記 サーバー(/var/www/rails/アプリ名/) vim Gemfile ---------------------------- #以下を追記 group :production, :staging do gem 'unicorn' end ---------------------------- Shift+ZZで保存＆終了 Unicornをインストール サーバー(/var/www/rails/アプリ名/) $ gem install bundler $ bundle install 2.Unicornの設定ファイルを作成 サーバー(/var/www/rails/アプリ名/) $ vim config/unicorn.conf.rb ------------------------------------ #以下を記述：合計1箇所変更点があります # set lets $worker = 2 $timeout = 30 $app_dir = "/var/www/rails/アプリ名" #自分のアプリケーション名 $listen = File.expand_path 'tmp/sockets/.unicorn.sock', $app_dir $pid = File.expand_path 'tmp/pids/unicorn.pid', $app_dir $std_log = File.expand_path 'log/unicorn.log', $app_dir # set config worker_processes $worker working_directory $app_dir stderr_path $std_log stdout_path $std_log timeout $timeout listen $listen pid $pid # loading booster preload_app true # before starting processes before_fork do |server, worker| defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnect! old_pid = "#{server.config[:pid]}.oldbin" if old_pid != server.pid begin Process.kill "QUIT", File.read(old_pid).to_i rescue Errno::ENOENT, Errno::ESRCH end end end # after finishing processes after_fork do |server, worker| defined?(ActiveRecord::Base) and ActiveRecord::Base.establish_connection end ------------------------------------ Shift+ZZで保存＆終了 これでUnicornの設定も完了です PostgreSQLの設定 続いてはDBの設定をしていきます (アプリケーションのDBがPostgreで作成されている前提で話を進めていきます。) DBへアクセスする情報（ユーザー名やパスワード等）をdatabase.ymlへ直接記入するとセキュリティ的に問題があるので、環境変数を使用して情報を受け渡していきます。 今回はdotenv-railsを使用して変数管理を行っていきます。 1.dotenv-railsの導入 Gemfileを編集する サーバー(/var/www/rails/アプリ名/) $ vim Gemfile Gemfileに以下を追加します。 # 環境変数の管理をするもの gem 'dotenv-rails' Shift+ZZで保存＆終了 インストール サーバー(/var/www/rails/アプリ名/) $ bundle install シークレットキーを作成します。 サーバー(/var/www/rails/アプリ名/) $ rake secret 表示されたシークレットキーはコピーします。 次にアプリケーションのルートディレクトリに.envファイルを作成し、 その中にシークレットキーの記述を記載してください。 サーバー(/var/www/rails/アプリ名/) $ touch .env $ vim .env --------------------------- #シークレットキーにコピーしたキーを貼り付けます。 SECRET_KEY_BASE={シークレットキー} Shift+ZZで保存＆終了 ファイルの記述ができたら結果を確認します。 サーバー(/var/www/rails/アプリ名/) $ source .env $ echo $SECRET_KEY_BASE シークレットキーの値が返ってきたら設定完了です。 PostgreSQLの環境変数を設定 先ほどのenvファイルに、PostgreSQLの変数を設定していきます。 シークレットキーの下へ追記してください。 ※ 他にも環境変数を入れる場合はここに入れてください！筆者の場合、S3関係の環境変数を使いました。 サーバー(/var/www/rails/アプリ名/) $ vim .env ----------------------- DB_NAME=travelour_production #作成したDB名 DB_USERNAME=taro #ロール名(ユーザ名のこと) DB_PASSWORD=********* #パスワード Shift+ZZで保存＆終了 ここで入力したロール名とパスワードは使うので覚えておきましょう。 変数の値を確認しましょう サーバー(/var/www/rails/アプリ名/) $ source .env $ echo $DB_NAME $ echo $DB_USERNAME $ echo $DB_PASSWORD 入力した情報が表示されれば完了です。 3.database.ymlを修正 環境変数を用いて、データベースにアクセスする設定を変更します。 サーバー環境(/var/www/rails/アプリ名/) $ vim config/database.yml #最下部の本番環境の記述のみ変更します production: <<: *default database: <%= ENV['DB_NAME'] %> username: <%= ENV['DB_USERNAME'] %> password: <%= ENV['DB_PASSWORD'] %> Shift+ZZで保存＆終了 4.Postgresの起動 以下のコマンドでpostgresを起動します。 サーバー(/var/www/rails/アプリ名/) $ sudo service postgres start 最初はデータベースにパスワードがかかっているため強制的にパスできる様にします。 まず'pg_hba.confファイルを編集します。 #pg_hba.confファイルを探す $ sudo find / -print |grep pg_hba.conf /var/lib/pgsql/data/pg_hba.conf #見つけたファイルをvimで編集する $ sudo vim /var/lib/pgsql/data/pg_hba.conf ------------------------------------ 以下のように編集(peerをtrustに変更) # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all trust #ここをtrustにする # IPv4 local connections: host all all 127.0.0.1/32 ident # IPv6 local connections: host all all ::1/128 ident これでpostgresにログインできます。 postgersにログイン $ psql -U postgres ロールを作成 ※ロールの詳細はこちら taroと11111111はロール名とパスワードです。 postgres=# CREATE ROLE taro WITH PASSWORD '11111111'; CREATE ROLEと表示されれば成功です。 SELECT ROLNAME FROM pg_roles;でちゃんと表示されているか確認してみましょう postgres=# SELECT ROLNAME FROM pg_roles; rolname ーーーーーーーー postgres taro (2 行) ALTER ROLEコマンドでログインとデータベース作成、権限を与える postgres=# ALTER ROLE taro LOGIN; postgres=# ALTER ROLE taro WITH CREATEDB; exitでpostgresからログアウトする データベース作成とマイグレーションを実行 サーバー $ rake db:create RAILS_ENV=production $ rake db:migrate RAILS_ENV=production 本番環境をプリコンパイルする サーバー $ bundle exec rake assets:precompile RAILS_ENV=production Nginxを起動 サーバー $ start nginx.service Unicornを起動 サーバー $ bundle exec unicorn_rails -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production Uniconの起動を確認(プロセスのリストが3行程表示されればOK) サーバー $ ps -ef | grep unicorn | grep -v grep taro 24411 1 13 19:46 ? 00:00:02 unicorn_rails master -c /var/www/rails/travelour/config/unicorn.conf.rb -D -E production taro 24419 24411 0 19:46 ? 00:00:00 unicorn_rails worker[0] -c /var/www/rails/travelour/config/unicorn.conf.rb -D -E production taro 24420 24411 0 19:46 ? 00:00:00 unicorn_rails worker[1] -c /var/www/rails/travelour/config/unicorn.conf.rb -D -E production Nginxを再起動します。 サーバー $sudo nginx -s reload ブラウザにIPを入力してアクセスします。※IPアドレスはElastic IP http://IPアドレス/ Railsが動作すれば成功です。

【AWS】 ■範囲 クラウドの概念26% セキュリティ25% テクノロジー33% 請求と料金16% ■試験 90分 700点以上 ■参考 AWSホワイトペーパー https://aws.amazon.com/jp/whitepapers ■■AWSクラウドの概念 26% ・AWSクラウドのメリット 1.固定費が柔軟な変動費へ 2.スケールによる大きなコストメリット >AWSの従量課金制の料金が下がる 3.キャパシティ予測が不要 4.速度と俊敏性の工場 5.データセンターの運用と保守への投資が不要に 6.数分で世界中にデプロイ ■クラウドサービスアーキテクチャの設計原則 1.システムのコンポーネントを疎結合にする 2.マイクロサービスアーキテクチャを利用する 3.SQS、キューイングチェーンを利用して、非同期かつ疎結合な構成を取る ■AWSインフラにおける弾力性、柔軟性 AWSではトラフィックの増減を考慮して手動、定期的、自動のいずれかでスケールアウトを行う事ができる。 ■AWS Well-Architectedフレームワーク 上手に設計されたシステム設計のベストプラクティス 1.運用上の優秀性 2.セキュリティ 3.信頼性 4.パフォーマンス効率 5.コスト最適化 ■■AWSセキュリティー 25% 1.AWSはクラウド方たんのセキュリティー部分(ハード,１AWSインフラストラクチャ,AZ,マネージドなサービスなど)がAWS 2.ユーザーはクラウド内のセキュリティーを担当(OSのアップデート、セキュリティーパッチ) 3.クラウド内のセキュリティー管理についてもAWSが用意しているサービスと活用することができる ■AWSとユーザーのセキュリティ範囲 AWS：データセンターのセキュリティ(環境レイヤー,物理的な境界防衛レイヤー,インフラストラクチャレイヤー,データレイヤー：アクセス制限)、ハイパーバイザー(仮想サーバーのメモリの独立など) ユーザー：管理プレーン(IDとパスワード,キーペア,APIキーの管理,アクセス制御と権限管理) ■セキュリティのベストプラクティス 1.転送データの保護 2.蓄積データの保護 3.AWS資格情報の保護 4.アプリケーションの安全性の確保 ■セキュリティーグループ インスタンストラフィックを制御する仮想ファイアウォール AWSでは各インスタンスごとに個別のファイアウォールの設定が行える ・許可ルールのしていが可能 ・拒否ルールの指定は不可能(穴をあけるのみ) ・インバウンドとアウトバウンドの個別指定が可能 ■AWS ShieldとAWS WAF DDos攻撃などによる対策としてAWShieldが有効。プランにはstandardとadvancedがありadvancedを使うと AWS WAFが無償で無制限に利用可能になる ■AWS Shield standard 通信レイヤー攻撃(DDoS攻撃)の保護サービス対象としてRoute53とCloudFrountがある ■AWS WAFの対象 CloudFront,ApplicationLoadBalancer,APIGateway ■Amazon Inspector EC2上のアプリケーションの脆弱性判断を行えるツール。レポートも作成してくれる? ■■AWSテクノロジー 33% ■リージョン ・リージョンを選択する際は法律はその国のものが対象となる。 ・リージョンによって使用できるサービルが異なることがある ・各リージョンには2つ以上のAZが存在する ■アベイラビリティゾーン 複数のデータセンタで構成されている 障害耐性のために地理的に離れた距離にあるが リージョン内のAZはプライベートな光ファイバーによってい接続されている ■エッジロケーション コンテンツ配信用のサーバーがある場所 AmazonCloudFrontが使用できる。(コンテンツ配信ネットワーク（CDN）を提供する) これを使用することで低レンシーなサービス提唱が行える(CDN)あとAmazon Route 53も エッジロケーションで使用できるサービスは AmazonCloudFront,AmazonRoute53,AWS Shield ■AWSのグローバルインフラ構成 ・リージョン ・アベイラビリティゾーン ・エッジロケーション ■■コンピューティングサービス ■EC2 (Amazon Elastic Compute Cloud) ・EC2の料金 1.EC2稼働に対する料金(時間単位or秒単位) >OS,リージョン,インスタンスタイプによって異なる 2.データ転送料金 >リージョンの外にデータを転送した場合にデータ転送料金が発生する(アウト通信) >データ転送料金はリージョンによって異なる、インターネットへ転送した場合と他リージョンに転送した場合でも異なる >インターネットからES2へのデータ転送(in)には料金はかからない >異なるAZ間のデータ転送には料金が発生する 3.ストレージ料金 >EC2にではなく、EBS (Amazon Elastic Block Store)にかかってくる ・EC2インスタンスの料金オプション 1.オンデマンドインスタンス 2.リザーブドインスタンス >長期間契約で割引を受けれる 3.スッポトインスタンス >未使用のインスタンスを利用する変動型の形態(アベイラビリティゾーンごとに決定する) >リクエスト料金が通ればインスタンスを利用することができるが、料金が超えたときにインスタンスが終了する >テストや検証する際に利用することで低コストでインスタンスを利用することができる 4.Dedicated Hosts >EC2が起動するホストを専有するオプション >セキュリティ、ガバナンス要件、ライセンス要件を満たす目的で使用される >ホストに対しての従量課金 5.ハードウェア専有インスタンス >アカウント専用のハードウェアでEC2を実行する。インスタンス単位+専有追加料金が必要 6.SavingPlans > ・インスタンスタイプ t2.micro t:ファミリー 2:世代 micro:サイズ サイズによってvCPU,メモリ,ネットワーク,ストレージの性能・選択できるストレージが決まる ・インスタンス起動手順 1.リージョンの選択 2.AMIを選択 3.インスタンスタイプを選択 4.ネットワークを選択 5.ストレージを選択 ・EC2はAMI (Amazon Machine Image)から起動される AMI → EC2 ■AMIの4種類 1.クイックスタートAMI >AWSが予め用意しているAMI(OSとモジュールが用意されている) 2.マイAMI >起動中のEC2からイメージを選択する >アプリケーションサーバのバックアップが取れる,共有,公開が可能 3.AWS Markeplace >パートナーベンダーが提供するソフトウェア、ミドルウェアがすでにインストールされた構成済みのAMI 4.コミュニティ AMI ・セキュリティーグループでトラフィックを制御できる >EC2のトラフィックはセキュリティーグループのインバウンドで制御する ・OSを管理者権限で操作できる >キーペアでログインすることで可能 >Linux：SSH, Windows：RDP(リモートデスクトップ接続) ■ELB (Elastic Load Balancing) >別のAZにインスタンスを配置することができる(マルチAZ) ・ELBの特徴 1.ロードバランサータイプ Application Load Balancer >HTTP,HTTPSのリクエストを負荷分散する Network Load Balancer >TCPプロトコルを使用する場合に使用する >静的なIPアドレスと使用できる Classic Load Balancer >以前のELB。今ELBを使用する場合は上記の2つから選択する 2.ヘルスチェック >対象インスタンス正常に動いているかチェックする機能 3.インターネット向け/内部向け >グローバルIPかパブリックIPの不要で決まる。 >EC2同様セキュリティーブループでトラフィックを制御できる 4.高可用性のマネージドサービス >ELBは内部的に複数存在しているのでELBによる可用性の低下は考えなくて良い 5.クロスゾーン負荷分散 >複数のAZに負荷分散できる ■Auto Scaling 自動でインスタンスをスケール調整してくるサービス。 それによって高可用性、障害耐性、コスト削減することができる ・Auto Scalingの設定 「何を」=「起動設定」：どのようなEC2インスタンスを起動するか 「どこで」=「Auto Scalingグループ」：どこでEC2インスタンスを起動するか 「いつ」=「Auto Scalingポリシー」：どのタイミングで起動/終了するか >ターゲットポリシー：CPU使用率を設定する 　　　シンプルポリシー：CloudWatchのアラートに基づいてスケールする ステップポリシー：複数段階でスケールアウトの計画を設定できる ・EC2の設計 自動で削除されるのでEC2インスタンスに情報を持たない設計する必要がある。(ステートレス) ・アプリケーションデプロイの自動化 設計パターン：ブートストラップ Auto Scaligによってインスタンス起動時にコマンドスクリプトを実行してソースコード最新にする EC2のユーザーデータを使うことでコマンドを自動実行し、デプロイ処理を自動化することができる EC2情報(ipアドレスやインスタンスID)はメタデータから取得できる ■Lambda 自動でスケーリングが行われる(並列スケーリング) AutoSlaringを利用する必要はない ・実行トリガーとAWSサービスとの連携 特定の時間(CloudWatch Events) S3にアップロード時 DynamoDBに書き込みがあっと時 AutoStalingが実行された時 Webページでボタンが押された時 Kinesisにレコードが追加された時 Alexaとの連携 ■■ストレージサービス ■EBS (Amazon Elastic Block Store) ・EBSの特徴 EC2のボリュームとして使用 AZ内でレプリケート ボリュームタイプの変更が可能 容量の変更が可能 ボリュームの暗号化 永続的ストレージ ・スナップショット S3の機能を使って保存されるので(複数AZ)耐久性が高い ・EBSの暗号化に対して追加で操作する必要はない(暗号化/復号化が自動で行われる) ■S3 (Amazon Simple Storage Service) ・S3の特徴 無制限のストレージ容量 高い耐久性 インターネット経由でアクセス ・アクセス権限 アクセルコントロールリスト(ACL) >バケット単位,オブジェクト単位で権限の設定ができる バケットポリシー >バケット単位の権限の設定ができ、アクセスコントロールリストよりも細かい設定ができる。(例 特定のIPにだけtmp/下のアクセスを許可するなど IAMポリシー >AWSサービスに対してS3の利用権限をふるなど ・通信、データの暗号化 通信：HTTP/HTTPS 暗号化方法3種 S3のキーを使用したサーバーサイド暗号化 KMSを使用したサーバーサイド、またはクライアントサイド暗号化 お客様独自のキーを使用したサーバーサイド、またはクライアントサイド暗号化 ・S3のポイント S3バケット、オブジェクトはデフォルトではプライベート アクセスコントロールでアクセス権限を設定できる バケットポリシーで詳細にアクセス権限の設定が可能 AWSリソースからの利用にはIAMロールでアクセス権限の設定をする HTTPSでアクセス可能 保存データの暗号化は複数の方法がある(S3キーの利用、KMSの利用、独自キーの利用) ・S3の料金 ストレージ料金 保存しているオブジェクトの容量に対しての料金(1ヶ月平均の保存料/リージョンによって料金がことなる/ストレージクラスによっても料金が異なる) ストレージクラス 標準 デフォルトのクラス(アプリケーションよって頻繁にアクセスの場合や、静的コンテンツの利用で使用) 低頻度アクセス(標準IA) アクセス頻度が少ない場合にコストを下げることができるがリクエスト料金が上がる。(バックアップなどの利用に適している) 1ゾーン低頻度アクセス(1ゾーンIA) 複数のアベイラビリティゾーンに助長化する必要がない場合などに利用 Amazon Glacier アクセスする必要はないは保存して置く必要がある場合に利用。標準取り出しに3~5時間を要する ライフサイクルポリシー アップロード時から経過日数によっていストレージクラスを自動で変更することが可能(例えばエラーログなどの保存に利用) リクエスト料金 アップロードやダウンロードに対しての料金 データ転送料金 リージョン外への転送料金(インターネットと他リージョンとで料金が異なる) インターネットからの転送(in)には料金はかからない ・S3のユースケース アプリケーションのデータ保存 静的コンテンツの配信 データバックアップの保存 ログデータの保存 ビッグデータのステージング クロスリージョンレプリケーション構成を取ることによるDR対策(災害対策) ■■AWS ネットワークサービス ■VPC (Amazon Virtual Private Cloud) AWSクラウド内にプライベートなネットワークを構築できる AWSサービスにはVPC内で利用できるものとVPC外で利用できるものがある。 ・VPC内で使うサービス VPC,サブネット,インターネットゲートウェイ,ルートテーブル,セキュリティーグループ,ネットワークACL,NATゲートウェイ(NATインスタンス) ・VPCの作成 複数のAZをまたいでネットワークを構築することができる ・サブネット AZ内にIP範囲を設定する(IPの重複はNG) ・CIDR /24とすることで256のipを利用できるが、AWSでは最初の4つと最後の1を予約ipとして利用するので 実際には251となる。 10.0.1.0：ネットワークアドレス 10.0.1.1：VPCルータ用 10.0.1.2：AWSで予約 10.0.1.3：将来の利用のためのAWSで予約 10.0.1.255：ネットワークブロードキャストアドレス ・インターネットゲートウェイ VPSに１つ。水平スケーリングをとる。 ・ルートテーブル ルートテーブルはサブネットと関連付ける。 VPC作成時にメインルートテーブルというものができるが、実際にルートテーブルを使う際にはカスタムルートテーブルを作成してサブネットに関連付けを行う。 サブネット内のリソースがどこに接続できるかを定義できる。 ・パブリックサブネットとプライベートサブネット ・ネットワークACL (アクセスコントロールリスト) サブネットに対して設定する仮想ファイアウォール デフォルトではインバウンド、アウトバウンドともにすべてが許可されているので拒否のブラックリストとしても使用できる。 使い所としては追加の要件がある場合にのみ利用する。必要がなければ設定しない。 ・ハイブリット環境構成 既存のオンプレミスとAWSをVPNで接続し、拡張することができる。 ・専用線とAWSダイレクトコネクト 帯域の確保や、セキュリティー、コンプライス要件を満たすために ハイブリット環境を構築する場合は重要なサービスになる。 ・VPCピリアリング接続 これを使うと複数のVPCの接続が可能になる。 ■CloudFront (Amazon CloudFront) 世界中に150個所以上にあるエッジローケーションを利用し、低いレイテンシーでコンテンツを配信できるCDNサービス ・CloudFrontの特徴 キャッシュによる低レイテンシー配信 ユーザー近くからの低レイテンシー配信 安全性の高いセキュリティ ・セキュリティ AWS Certificate Managerを利用することで通信データを保護することができる AWS Shield、AWS WAFを利用することで攻撃からも保護することができる ■Route 53 (Amazon Route 53) DNSサービス ・Route 53の特徴 様々なルーティング機能 シンプルルーティング 単一のipアドレス情報を回答すすシンプルなルーティング レイテンシーベースのルーティング/ Geo DNS 1つのドメインに対して複数のDNSレコードを用意し地理的な場所を近くする 加重ラウンドロビン 複数値回答 高可用性を実現するヘルスチェックとフェイルオーバー ルートドメイン(Zone Apex)のエイリアスレコード ■■AWS データベースサービス ■RDS (Amazon Relational Database Service) ・ポイントタイムリカバリー フォランザクションログが保存されていることによっていバックアップ期間内の任意の特定時間のインスタンスを起動できる ・RDSのマルチAZ配置 マルチAZ配置をonにすることで高可用性を担保することができ、データセンター間で数ミリ秒以内のレイテンシーでレプリケーションされる。同時にマスターBDに障害を検知しサブに切り替えるフェイスオーバーも自動でここなってくれる。 ・Amazon Aurora mysql postfresql互換のクラウド最適化されたRDMS ・DMS (AWS Database MIgrationService) データベース間でデータを移行できるサービス ■DynamoDB フルマネージドのNoSQL型のデータベースサービス ・RDSとDynamoDBの違い sql型かNosql型か RDSは トランザクションによって厳密な処理に向いている。 大量のアクセスには向いていない 項目が決まっていいる DynamoDBは 厳密な処理には向いていない。 大量のアクセスには向いている データに主キーがあればどのような項目でもデータを登録できる ■■管理サービス ■CloudWatch (Amazon CloudWatch) AWSによりリソース(aws管理化の部分)の標準メトリクスが収集されている ・特徴 標準(組み込み)メトリクスの収集・可視化 カスタムメトリクスの収集・可視化 ログの収集 アラーム ・CloudWatch Logs EC2やLamdaなどのログを収集することができる CloudWatchエージェントをインストールすることでCloudWachLogsへの書き込みができるようになる これによってEC2などはステートレスな構成を取ることができる。 ・アラーム サービスの状態(=メトリクス値)に対してアラームを設定することが可能 アラームに対してEC2の回復、AutoScaling、SNS通知、lamdaへの通知などが実行できる ■■請求と料金 ・コスト分析 コストエクスプローラー コスト配分タグ

はじめに ドメインの基本とRoute 53のHosted Zoneについてまとめました。 まずはHosted Zoneが何の代替サービスなのか説明するために、ドメインについて解説します。 ※ゆくゆくはAzureのDNSゾーンとAWS Route 53を比較したいと思っています。 DNS用語 ホスト ネットワークに繋がれているサーバー、ルーター、パソコン、スマホ等のことです。 IPアドレス インターネットに接続しているホスト同士が通信するために、ホストに割り当てる住所のようなものです。 IPアドレスは192.168.0.10(IPv4)や3002:0bd6:0000:0000:0000:ee00:0033:6778(IPv6)のように表されます。 インターネットに公開されているWebサイトにアクセスするためには、このIPアドレスがわからないとアクセスできません。 Naming 例えばqiita.comのIPアドレスをご存じの人がどれだけいらっしゃるでしょうか。普通は知りません。 ホストに覚えやすい名前を付け、その名前を使って通信するための仕組みのことをNamingと言います。 名前とIPアドレスが対応付けられているため、人間が名前を指定してアクセスしたつもりでも、裏側でIPアドレスを用いて通信が行われています。 ドメイン名 ホストが所属するネットワーク空間のことをドメインと言います。 上記の例で言うとexample.jpやsample.jp、example.comを指します。 ネットワーク空間という表現が曖昧ですが、目に見える区切りがあるわけではありません。 ホストが所属する何らかのグループに、識別しやすい名前を付けているということです。 識別する必要があるので、ドメイン名はインターネット上で重複して登録することはできません。 例えば「パソコン株式会社」と「コンピュータ株式会社」という会社があった場合、両方にcp.comというドメインを払い出すことはできません。 ホスト名 ドメイン内のホストを一意に特定するための名前です。 例えば以下の例ではexample.jpやsample.jp、example.comの中にserver01という同じ名前のホスト名が存在します。 ドメイン内で一意であれば、他のドメインで同じホスト名が使われていても問題ありません。 名前解決 ドメイン名とIPアドレスの対応表を管理し、利用者からの要求に応じてドメイン名に対応するIPアドレスを答えることを名前解決と言います。 ドメイン名管理の歴史 インターネット黎明期のホスト一極集中管理 前述の通り、世界中のホストがホスト名を使って通信するためには、ホスト名が重複なく管理される必要があります。 昔はカリフォルニア州のスタンフォード研究所のSRI-NICがHOSTSファイルを管理していました。 HOSTSファイルとは、ホスト名とIPアドレスのマッピング表のことを指します。 利用者がSRI-NICに申請をし、SRI-NICがインターネットに公開したHOSTSファイルを利用者がダウンロードするという仕組みでした。 一極集中管理⇒分散管理 インターネットが発展するにつれ、世界中の人がホストの登録申請をするようになり、SRI-NICの登録処理が遅れるようになります。 そこでSRI-NIC以外の複数の組織が名前の管理をする分散管理の仕組みが登場します。 階層化と委任によるドメイン管理 階層化 複数の組織が管理者になった場合でも、ホストを特定するための名前はインターネット上で一意でなくてはなりません。 インターネット上で重複なくホストに名前を付けるための方法として階層化の仕組みが導入されました。 例えばblog.example.jpの場合はblog/example/jpの3つに区切り、matome.example.comの場合はmatome/example/comの3つに区切り、それぞれを層で表し階層を作ります。 それぞれの階層の名前が被らないようにドメインを作ることで、ドメイン名をインターネット全体で一意に設定することが出来ます。 ドメイン名の構成 ドメイン名はいくつかのラベルに分解されます。 ルートドメインから全てのドメイン名を記述するドメインの表記をFully Qualified Domain Name(FQDN)と言います。 上の例ではtest.example.com.がFQDNです。 サブドメイン DNSでは、ある層の下位の層のことをサブドメインと表現します。 ある名前空間1の範囲が別の名前空間2の範囲に含まれている場合、名前空間1は名前空間2のサブドメインとなります。 test.example.com.の場合、comのサブドメインはexample、example.comのサブドメインはtestです。 ドメインとサブドメインは親と子の関係があります。 ツリー構造 各階層に親子関係があり、親が複数の子を持ち、その子がまた自分を親として複数の子を持つことができるようなデータはツリー構造で表現することが出来ます。 ドメイン名をラベルごとに分解し、ツリーで表すと以下のようになります。 委任 サブドメインはそのドメインの管理者が自由に作ることができます。 作ったサブドメインを他者に委任するかどうかも管理者が決められます。 サブドメインを委任した場合、そのサブドメインのゾーン情報を管理するのはサブドメインの管理者になります。 DNS(Domain Name System) DNSとは DNSは階層化と委任の仕組みを用いてドメインを管理するためのシステムです。 ドメイン名とIPアドレスの対応表を管理し、利用者からの要求に応じてドメイン名に対応するIPアドレスを答える仕組みです。 委任先毎に対応表を管理するデータベースを持つ分散データベースです。 ゾーン 管理を任された範囲をゾーンと言います。 委任元と委任先は親と子の関係で表されます。 それぞれのゾーンでネームサーバーを作成し、名前解決の為に必要な対応表をネームサーバで管理します。 親の対応表には、自分のゾーン情報に加え、子ゾーンのネームサーバのFQDNとIPアドレスが記述されます。 また子の対応表には、1.ネームサーバのFQDN、2.自分のゾーン情報、3.子ゾーンのネームサーバのFQDNとIPアドレスが記述されます。 レジストリ・レジストラモデル レジストリとレジストラ レジストリの役割 レジストラの役割 ドメイン名を利用できる状態にする為には？ ドメインの登録申請が完了すると、ドメインを利用する権利を得ます。 この時点では、まだドメインを利用できる状態にはなっていません。 ※利用とは、例えばブラウザでsite.example.jp等をたたいてWebサーバが表示される状態にすることを指します。 利用する為には、ネームサーバーに自分のドメイン情報を登録します。 レジストラが運用しているWebサイトからネームサーバへ登録できます。 ※ネームサーバを自分で運用してインターネットに公開することも可能です DNSの構成要素 スタブリゾルバー スマホやパソコンなどの、インターネットに繋がっている機器です。 スタブリゾルバーは自分で名前解決は出来ないので、名前解決をできる人に問い合わせをします。 例えばユーザがblog.example.jpにアクセスしたい場合、上位の階層のネームサーバから順に「blog.example.jpについて教えて」と聞きます。 「blog.example.jpについて教えて」と聞くことを名前解決要求と言います。 ネームサーバは、委任先の情報が聞かれた場合は委任先のネームサーバの情報をユーザに返します。 これを繰り返すことで、blog.example.jpのIPアドレスにたどり着くことが出来ます。 フルリゾルバー たくさんのスタブリゾルバが同じ問い合わせをネームサーバに行うと、ネームサーバに負荷がかかります。 フルリゾルバーは、スタブリゾルバーに代わって、ネームサーバに名前解決要求をします。 ドメイン名とIPアドレスのマッピング情報をキャッシュし、同じ問い合わせがあった場合はネームサーバへの名前解決要求を省略してスタブリゾルバーにIPアドレスを教えます。 権威(Authority)サーバ 今までネームサーバと言っていたものは、DNSでは権威サーバと言います。 権威サーバは問い合わせを受け、自分が所有するゾーンの情報か、委任先のネームサーバを応答します。 続きの記事 次はRoute 53の機能について解説します。 参考 Webサイト ※著者名.“Webページのタイトル”. Webサイトの名称. 更新日付 恩塚伸一郎.AWS再入門ブログリレー Amazon Route 53編. DevelopersIO produced by Classmethod.jp. 2020.08.18 石橋勇二.【初心者向け】無料ドメインを使ってAmazon Route 53で実装しながら理解するDNS. DevelopersIO produced by Classmethod.jp. 2020.05.15 大塚昭彦.IPv6アドレスにおける「ネットワーク」と「ホスト」の表し方. TECH.ASCII.jp. 2020.06.02 08時00分更新 ドメイン名・ホスト名・FQDNって？.IT情報メディアLIVRA. 2020.05.15 其⽥ 学.押さえておきたい！基盤技術(2)DNSの基本と最新動向.⽇本DNSオペレーターズグループ/株式会社インターネットイニシアティブ 本 こちらの1章から4章を読み込みました。 株式会社日本レジストリサービス(JPRS) 渡邉結衣、佐藤新太、藤原和典.(2018).DNSがよくわかる教科書

はじめに こんにちは、rattsl(@rattsl1)です。 今回は「これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）」 を受講するにあたってメモとして残しておきます。 Day1対応 AWSアカウントに登録後は最低限設定しておくべき項目がある 多要素認証(MFA) IAMからセキュリティの設定を行う。 管理者用IAMユーザの作成 組織的に管理運用する為にルートユーザから設定ではなく管理者用IAMユーザを作成してそこから他のIAMユーザを作成、アクセス権限を付与等を行う。 CloudTrailの有効化 ユーザのアクティビティやAPIコールををロギングするサービス。 ログファイルはS3に保存されCloudWatch上で解析化。 ここでは証跡を有効化、ログファイルの保存作のS3の設定を行う。 請求アラートの設定 請求アラートでAWSリソースの使用による料金が一定に達した場合のアラートを通知する CloudWatch上で請求アラートを設定する。 各サービスのメトリクスがダッシュボード上で表示されている。 AWS SAA試験範囲 【目標】 顧客の要件に基づきアーキテクチャ設計原則に沿ってソリューションを提供できること プロジェクトのライフサイクルを通してベストプラクティスに基づく実装ガイダンスを組織に提供できること 【出題分野】 分野1: レジリエントアーキテクチャの設計 分野2: 高パフォーマンスアーキテクチャの設計 分野3: セキュアなアプリケーションとアーキテクチャの設計 分野4: コスト最適化アーキテクチャの設計 【受験者に求められる能力】 知識系 AWS・アーキテクチャ・セキュリティ・ネットワークツールなどの理解 実践系 VPC・EC2・S3などの標準機能を使ってアーキテクチャを構築した実務経験 AWSのグローバルインフラ構成 AWSのクラウドサービスは全世界に多数のデータセンターを提供しており、どこの国のリージョンにもアクセスしてサービスを使うことができる。 ただし、中国などの社会主義国家などは政府側でデータの情報を一括で管理している為、情報管理の観点からデータの持ち出しができない、また中国リージョンでAWSサービスを使う場合は中国側の要請に従い、データを渡さなければならない可能性がある為、どのリージョンでサービスを使うかは事前に調べた上で使う必要がある。 国別インフラは リージョン ＞ AZ > エッジロケーション の3つの単位で区分することができる。 AZは巨大な物理インフラ（サーバ）であり、その物理インフラから仮想化してユーザにサービスを提供している。 日本だと東京リージョンは複数のAZで構成されており、それぞれのAZは低レイテンシで接続されている。 一つのAZが潰れた時にそのAZでインフラを作ったアプリも動かなくなるというリスクを避ける為に、複数のAZで分けてインフラを強固にするアーキテクチャが可用性、信頼性の高いサービスを提供する上で必要になってくる。 ただしすべてのAWSマイクロサービスがAZをまたぐことができるのかを事前に知っておく必要がある。 そもそもクラウドとは？ クラウドとは必要に応じて他社所有のハードウェア、ソフトウェアをネットを介して利用するシステム利用形態。 一時的にサーバーが欲しい 需要が増えたら増強、減ったら削除 データベースを爆速で調達したい というときにクラウドは便利。 クラウドにも種類があり、SaaS, PaaS, IaaSの3つが代表的。 それぞれはどこまで借りるかで分類できる。 SaaS(Software as a Service) クラウド事業者がアプリケーションまで提供。 自社はすぐにアプリの利用が可能。 ex) Google workspace, Adobe Photoshop, Slackなど PaaS(Platform as a Service) クラウド事業者がミドルウェアまで提供。 自社はアプリ開発に専念可。 ex) AWS, Azure, GCP IaaS(Infrastructure as a Service) クラウド事業者がハードウェアなどのインフラのみを提供。 自社でミドルウェアやアプリを開発 ex) AWS EC2

はじめに コンテナオーケストレーションツールと言えば、パブリッククラウドのプロバイダが提供するマネージドサービスを除けば Kubernetes がほぼデファクトスタンダードになってきたと言っても過言ではないだろう。 そこで、そろそろ真面目に Kubernetes を勉強しようにも最初の一歩で何をしたら良いか躓いている人も多いと思う。 本記事では、そんな感じで Kubernetes やってみようぜ！な初学者向けに書いてみる。 これでいいのか？という気はするが、Kubernetes のコントロールプレーンのインストール等の手間を省くことを考慮して、EKS を使ってみる。 一方で、コンテナやパブリッククラウドに関しての完全な初学者向けに書くのはなかなか難しいため、以下の知識があることを前提にする。 ECS でのコンテナ管理を触ったことがある Terraform をそこそこ書いたことがある Terraform は別になくても良いのだけど、せっかくコンテナを使うからには冪等に作るべきなので、本記事では、terraform apply の一撃で、EKS on Fargate な Nginx のサービスを起動して ALB 経由でインターネットからアクセスできるようにすることを目標にする。 また、今回はひとまず動かすところまでを優先しているため、セキュリティグループの設定はデフォルトのまま(EKS 作成時に勝手に作られるものと、ALB 作成時に勝手につくられるものから変更していない)としている。必要に応じて修正をしていただきたい。 最初に結論 先に結論を書いておく。 ECS はすごい良くできてると改めて感じた。 少なくとも、今 ECS を使っている人が、パブリッククラウドのプロバイダを変更することを前提にすること以外に、ECS → EKS に乗り換えるメリットというのはあまり無いように感じる(それとて、どうせ乗り換えるならあえて EKS にするくらいであれば、さっさと乗り換えてしまった方が良いだろう)。 これからコンテナをゼロから学ぶというのであれば、Kubernetes は選択肢になり得ると思う。ただし、ECS のように AWS に完全統合された環境ではないので、覚えることは ECS よりも多くなるだろう あと、素で EKS を触ると大変すぎて死ねるので、eksctl (コマンドラインからEKSを制御するコマンド)は必須だろう。ちゃんとインストールしておこう。というか、仕組みを理解したら、その後は eksctl を使わない理由はあまり無いと思う。 全体構成 今回の Terraform では以下のリソースを作成する。 VPC、サブネット EKS クラスタ、Fargate プロファイル OIDCプロバイダ ALB Ingress Controller(Kubernetesのリソース) VPCはありものを使っても良いが、EKS がいろいろバックエンドでゴニョゴニョやるための識別子をタグに埋め込む必要がある。既存の環境を汚したくない人は、新規でVPCを作っておいた方が良いだろう。 また、途中で使うコマンドの都合上、terraform destroy で消せないリソースが登場するので注意。 そういったリソースには本記事中でも注記をすることにする。 ネットワークを作る ここはそんなに難しいことはない。EKS の制約上、最低でも2つ以上のプライベートネットワークが必要になるので、それぞれ作って Nat Gateway をアタッチしておこう。 また、VPC とサブネットのリソースには "kubernetes.io/cluster/${local.eks_cluster_name}" = "shared" のタグを付与しておこう。これを忘れるとうまく動いてくれない。パブリックサブネットには "kubernetes.io/role/elb" = "1"、プライベートサブネットには "kubernetes.io/role/internal-elb" = "1" を付与しておく。 ################################################################################ # VPC # ################################################################################ resource "aws_vpc" "for_eks_fargate" { cidr_block = "192.168.0.0/16" instance_tenancy = "default" enable_dns_support = true enable_dns_hostnames = true tags = { Name = local.vpc_name "kubernetes.io/cluster/${local.eks_cluster_name}" = "shared" } } ################################################################################ # Public Subnet # ################################################################################ resource "aws_subnet" "public1" { vpc_id = aws_vpc.for_eks_fargate.id cidr_block = "192.168.0.0/24" map_public_ip_on_launch = true availability_zone = "ap-northeast-1a" tags = { "Name" = local.public_subnet_name1 "kubernetes.io/cluster/${local.eks_cluster_name}" = "shared" "kubernetes.io/role/elb" = "1" } } resource "aws_subnet" "public2" { vpc_id = aws_vpc.for_eks_fargate.id cidr_block = "192.168.1.0/24" map_public_ip_on_launch = true availability_zone = "ap-northeast-1c" tags = { "Name" = local.public_subnet_name2 "kubernetes.io/cluster/${local.eks_cluster_name}" = "shared" "kubernetes.io/role/elb" = "1" } } ################################################################################ # Private Subnet # ################################################################################ resource "aws_subnet" "private1" { vpc_id = aws_vpc.for_eks_fargate.id cidr_block = "192.168.2.0/24" map_public_ip_on_launch = false availability_zone = "ap-northeast-1a" tags = { "Name" = local.private_subnet_name1 "kubernetes.io/cluster/${local.eks_cluster_name}" = "shared" "kubernetes.io/role/internal-elb" = "1" } } resource "aws_subnet" "private2" { vpc_id = aws_vpc.for_eks_fargate.id cidr_block = "192.168.3.0/24" map_public_ip_on_launch = false availability_zone = "ap-northeast-1c" tags = { "Name" = local.private_subnet_name2 "kubernetes.io/cluster/${local.eks_cluster_name}" = "shared" "kubernetes.io/role/internal-elb" = "1" } } ################################################################################ # Internet Gateway # ################################################################################ resource "aws_internet_gateway" "for_eks_fargate" { vpc_id = aws_vpc.for_eks_fargate.id } ################################################################################ # EIP # ################################################################################ resource "aws_eip" "for_nat_gateway1" { vpc = true tags = { Name = local.eip_name1 } } resource "aws_eip" "for_nat_gateway2" { vpc = true tags = { Name = local.eip_name2 } } ################################################################################ # Nat Gateway # ################################################################################ resource "aws_nat_gateway" "for_eks_fargate1" { subnet_id = aws_subnet.public1.id allocation_id = aws_eip.for_nat_gateway1.id tags = { Name = local.ngw_name1 } } resource "aws_nat_gateway" "for_eks_fargate2" { subnet_id = aws_subnet.public2.id allocation_id = aws_eip.for_nat_gateway2.id tags = { Name = local.ngw_name2 } } ################################################################################ # Route Table # ################################################################################ resource "aws_route_table" "public1" { vpc_id = aws_vpc.for_eks_fargate.id } resource "aws_route" "public1" { route_table_id = aws_route_table.public1.id gateway_id = aws_internet_gateway.for_eks_fargate.id destination_cidr_block = "0.0.0.0/0" } resource "aws_route_table_association" "public1" { subnet_id = aws_subnet.public1.id route_table_id = aws_route_table.public1.id } resource "aws_route_table" "public2" { vpc_id = aws_vpc.for_eks_fargate.id } resource "aws_route" "public2" { route_table_id = aws_route_table.public2.id gateway_id = aws_internet_gateway.for_eks_fargate.id destination_cidr_block = "0.0.0.0/0" } resource "aws_route_table_association" "public2" { subnet_id = aws_subnet.public2.id route_table_id = aws_route_table.public2.id } resource "aws_route_table" "private1" { vpc_id = aws_vpc.for_eks_fargate.id } resource "aws_route" "private1" { route_table_id = aws_route_table.private1.id nat_gateway_id = aws_nat_gateway.for_eks_fargate1.id destination_cidr_block = "0.0.0.0/0" } resource "aws_route_table_association" "private1" { subnet_id = aws_subnet.private1.id route_table_id = aws_route_table.private1.id } resource "aws_route_table" "private2" { vpc_id = aws_vpc.for_eks_fargate.id } resource "aws_route" "private2" { route_table_id = aws_route_table.private2.id nat_gateway_id = aws_nat_gateway.for_eks_fargate2.id destination_cidr_block = "0.0.0.0/0" } resource "aws_route_table_association" "private2" { subnet_id = aws_subnet.private2.id route_table_id = aws_route_table.private2.id } IAM の準備 EKS クラスタと Pod 実行用のサービスロールが必要になるので作成しておく。 それぞれ AWS マネージドな IAM ポリシーがあるので、それをアタッチすれば良いだろう。 ################################################################################ # IAM Role for EKS Cluster # ################################################################################ resource "aws_iam_role" "ekscluster" { name = local.ekscluster_role_name assume_role_policy = data.aws_iam_policy_document.ekscluster_assume.json } data "aws_iam_policy_document" "ekscluster_assume" { statement { effect = "Allow" actions = [ "sts:AssumeRole", ] principals { type = "Service" identifiers = [ "eks.amazonaws.com", ] } } } resource "aws_iam_role_policy_attachment" "ekscluster1" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy" role = aws_iam_role.ekscluster.name } resource "aws_iam_role_policy_attachment" "ekscluster2" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController" role = aws_iam_role.ekscluster.name } ################################################################################ # IAM Role for EKS Pod Execution # ################################################################################ resource "aws_iam_role" "ekspodexecution" { name = local.ekspodexecution_role_name assume_role_policy = data.aws_iam_policy_document.ekspodexecution_assume.json } data "aws_iam_policy_document" "ekspodexecution_assume" { statement { effect = "Allow" actions = [ "sts:AssumeRole", ] principals { type = "Service" identifiers = [ "eks-fargate-pods.amazonaws.com", ] } } } resource "aws_iam_role_policy_attachment" "ekspodexecution1" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy" role = aws_iam_role.ekspodexecution.name } EKS クラスタの作成 いよいよ EKS クラスタの作成だ。 ここで必要になるのは、aws_eks_cluster と aws_eks_fargate_profile だ。 aws_cloudwatch_log_group についてはログ採取が必要な場合に設定する。何も指定しなくても設定されるが、保存期間が無制限になってしまうので、予め EKS 指定の名前で作っておくことで、Terraform の制御下に置くことができる。 aws_eks_cluster については、明示的にポリシーのアタッチとの順番を制御する必要があるため、depends_on でポリシーのアタッチが先に完了するようにしておく。vpc_config については、パブリック、プライベート問わず作成したすべてのサブネットを設定する。 aws_eks_fargate_profile の subnet_ids については、 ################################################################################ # EKS # ################################################################################ resource "aws_eks_cluster" "example" { depends_on = [ aws_iam_role_policy_attachment.ekscluster1, aws_iam_role_policy_attachment.ekscluster2, aws_cloudwatch_log_group.eks_cluster, ] name = local.eks_cluster_name role_arn = aws_iam_role.ekscluster.arn version = "1.19" vpc_config { subnet_ids = [ aws_subnet.public1.id, aws_subnet.public2.id, aws_subnet.private1.id, aws_subnet.private2.id, ] } enabled_cluster_log_types = ["api", "audit", "authenticator", "controllerManager", "scheduler"] } resource "aws_eks_fargate_profile" "kubesystem" { cluster_name = aws_eks_cluster.example.name fargate_profile_name = local.eks_fargate_kubesystem_profile_name pod_execution_role_arn = aws_iam_role.ekspodexecution.arn subnet_ids = [aws_subnet.private1.id, aws_subnet.private2.id] selector { namespace = "default" } selector { namespace = "kube-system" } } resource "aws_cloudwatch_log_group" "eks_cluster" { name = "/aws/eks/${local.eks_cluster_name}/cluster" retention_in_days = 3 } Kubernetes が必要とするYAMLを作成する さて、ここまでは大したことない(実際、EKS on EC2 であればだいたいこれで終わり)のだが、ここからが大変な部分だ。 Kubernetes を制御するための YAML を作成していく。 必要なものは以下。 Kubernetes の Config ファイル ALB Ingress Controller の Manifest ファイル Kubernetes に設定するロールの Manifest ファイル Nginx コンテナを起動するための Manifest ファイル それぞれ、AWS リソースを埋め込む必要があるため、以下のような感じで template_file を使って自動で作成する。 ちなみに、この節の元ネタはAWSのブログなのだが、コピペ元のYAMLファイルが壊れていたり、既にこのブログが書かれたときから時間がったっていてすでに使えない apiVersion があったりして、かなり大変だった……。1年ちょっと前の記事にもかかわらず既に deprecated だったり使えなくなったりする構文があるというライフサイクルの速さは、EKS はしんどい所以でもある……。 ################################################################################ # Local File for Kubernetes Config # ################################################################################ resource "local_file" "kubeconfig" { filename = "./output_files/kubeconfig.yaml" content = data.template_file.kubeconfig.rendered } data "template_file" "kubeconfig" { template = file("${path.module}/kubernetes_template/01_kubeconfig_template.yaml") vars = { eks_certificate_authority_data = aws_eks_cluster.example.certificate_authority.0.data eks_cluster_endpoint = aws_eks_cluster.example.endpoint eks_cluster_arn = aws_eks_cluster.example.arn eks_cluster_region = data.aws_region.current.name eks_cluster_name = local.eks_cluster_name } } ################################################################################ # Local File for ALB Ingress Controller # ################################################################################ resource "local_file" "alb_ingress_controller" { filename = "./output_files/alb-ingress-controller.yaml" content = data.template_file.alb_ingress_controller.rendered } data "template_file" "alb_ingress_controller" { template = file("${path.module}/kubernetes_template/11_alb-ingress-controller.yaml") vars = { eks_cluster_name = aws_eks_cluster.example.name vpc_id = aws_vpc.for_eks_fargate.id region_name = data.aws_region.current.name } } ################################################################################ # Local File for RBAC Role # ################################################################################ resource "local_file" "rbac_role" { filename = "./output_files/rbac-role.yaml" content = data.template_file.rbac_role.rendered } data "template_file" "rbac_role" { template = file("${path.module}/kubernetes_template/12_rbac-role.yaml") } ################################################################################ # Local File for Nginx Deployment # ################################################################################ resource "local_file" "nginx_deployment" { filename = "./output_files/nginx-deployment.yaml" content = data.template_file.nginx_deployment.rendered } data "template_file" "nginx_deployment" { template = file("${path.module}/kubernetes_template/13_nginx-deployment.yaml") vars = { eks_fargate_profile_name = aws_eks_fargate_profile.kubesystem.fargate_profile_name } } ################################################################################ # Local File for Nginx Service # ################################################################################ resource "local_file" "nginx_service" { filename = "./output_files/nginx-service.yaml" content = data.template_file.nginx_service.rendered } data "template_file" "nginx_service" { template = file("${path.module}/kubernetes_template/14_nginx-service.yaml") } ################################################################################ # Local File for Nginx Ingress # ################################################################################ resource "local_file" "nginx_ingress" { filename = "./output_files/nginx-ingress.yaml" content = data.template_file.nginx_ingress.rendered } data "template_file" "nginx_ingress" { template = file("${path.module}/kubernetes_template/15_nginx-ingress.yaml") } 01_kubeconfig_template.yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: ${eks_certificate_authority_data} server: ${eks_cluster_endpoint} name: ${eks_cluster_arn} contexts: - context: cluster: ${eks_cluster_arn} user: ${eks_cluster_arn} name: ${eks_cluster_arn} current-context: ${eks_cluster_arn} kind: Config preferences: {} users: - name: ${eks_cluster_arn} user: exec: apiVersion: client.authentication.k8s.io/v1alpha1 args: - --region - ${eks_cluster_region} - eks - get-token - --cluster-name - ${eks_cluster_name} command: aws 11_alb-ingress-controller.yaml apiVersion: apps/v1 kind: Deployment metadata: namespace: kube-system name: alb-ingress-controller labels: app.kubernetes.io/name: alb-ingress-controller spec: selector: matchLabels: app.kubernetes.io/name: alb-ingress-controller template: metadata: labels: app.kubernetes.io/name: alb-ingress-controller spec: containers: - name: alb-ingress-controller args: - --ingress-class=alb - --cluster-name=${eks_cluster_name} - --aws-vpc-id=${vpc_id} - --aws-region=${region_name} image: docker.io/amazon/aws-alb-ingress-controller:v1.1.4 serviceAccountName: alb-ingress-controller 12_rbac-role.yaml --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: labels: app.kubernetes.io/name: alb-ingress-controller name: alb-ingress-controller rules: - apiGroups: - "" - extensions resources: - configmaps - endpoints - events - ingresses - ingresses/status - services verbs: - create - get - list - update - watch - patch - apiGroups: - "" - extensions resources: - nodes - pods - secrets - services - namespaces verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: labels: app.kubernetes.io/name: alb-ingress-controller name: alb-ingress-controller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: alb-ingress-controller subjects: - kind: ServiceAccount name: alb-ingress-controller namespace: kube-system 13_nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: namespace: default name: nginx-deployment labels: eks.amazonaws.com/fargate-profile: ${eks_fargate_profile_name} spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx:1.20 imagePullPolicy: Always name: nginx ports: - containerPort: 80 14_nginx-service.yaml apiVersion: v1 kind: Service metadata: namespace: "default" name: "nginx-service" annotations: alb.ingress.kubernetes.io/target-type: ip spec: selector: app: "nginx" ports: - port: 80 targetPort: 80 protocol: TCP type: NodePort 15_nginx-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: namespace: default name: nginx-ingress annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing labels: app: nginx-ingress spec: rules: - http: paths: - path: /* pathType: Prefix backend: service: name: nginx-service port: number: 80 CoreDNS を Fargate 向けに書き換える さて、素で起動してきた EKS Cluster は、DNS をEC2 で起動しようとして進まなくなる。 これを Fargate に向けてあげる必要がある。 コマンド自体は AWS 公式のユーザーガイド参照。 今回は、冪等性を高めるために null_resource を使って自動でパッチをして再起動する。 resource "null_resource" "coredns_patch" { depends_on = [ aws_eks_fargate_profile.kubesystem, local_file.kubeconfig, local_file.alb_ingress_controller, local_file.rbac_role, local_file.nginx_deployment, local_file.nginx_ingress, local_file.nginx_service, ] provisioner "local-exec" { environment = { KUBECONFIG = local_file.kubeconfig.filename } command = "kubectl patch deployment coredns -n kube-system --type json -p='[{\"op\": \"remove\", \"path\": \"/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type\"}]'" on_failure = fail } } resource "null_resource" "coredns_restart" { depends_on = [null_resource.coredns_patch] provisioner "local-exec" { environment = { KUBECONFIG = local_file.kubeconfig.filename } command = "kubectl rollout restart -n kube-system deployment coredns" on_failure = fail } } ALB を構築する これでサービス公開の準備はほぼ整った。あとは、実際に ALB を構築してコンテナをデプロイしていく。 ここも AWS 公式のブログが元ネタで、null_resource で自動化をしていく。 まずは、ALB の IAM 権限を制御できるように以下のIDプロバイダと IAM ポリシーを作成する。 data "tls_certificate" "for_eks_fargate_pod" { url = aws_eks_cluster.example.identity[0].oidc[0].issuer } resource "aws_iam_openid_connect_provider" "for_eks_fargate_pod" { client_id_list = ["sts.amazonaws.com"] thumbprint_list = [data.tls_certificate.for_eks_fargate_pod.certificates[0].sha1_fingerprint] url = aws_eks_cluster.example.identity[0].oidc[0].issuer } resource "aws_iam_policy" "alb_ingress_controller" { name = local.eksalbingresscontroller_policy_name policy = <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "acm:DescribeCertificate", "acm:ListCertificates", "acm:GetCertificate" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateSecurityGroup", "ec2:CreateTags", "ec2:DeleteTags", "ec2:DeleteSecurityGroup", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInternetGateways", "ec2:DescribeNetworkInterfaces", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeTags", "ec2:DescribeVpcs", "ec2:ModifyInstanceAttribute", "ec2:ModifyNetworkInterfaceAttribute", "ec2:RevokeSecurityGroupIngress" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "elasticloadbalancing:AddListenerCertificates", "elasticloadbalancing:AddTags", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateRule", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:DeleteListener", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeleteRule", "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:DeregisterTargets", "elasticloadbalancing:DescribeListenerCertificates", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeSSLPolicies", "elasticloadbalancing:DescribeTags", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetGroupAttributes", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:ModifyRule", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:ModifyTargetGroupAttributes", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:RemoveListenerCertificates", "elasticloadbalancing:RemoveTags", "elasticloadbalancing:SetIpAddressType", "elasticloadbalancing:SetSecurityGroups", "elasticloadbalancing:SetSubnets", "elasticloadbalancing:SetWebAcl" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:GetServerCertificate", "iam:ListServerCertificates" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cognito-idp:DescribeUserPoolClient" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "waf-regional:GetWebACLForResource", "waf-regional:GetWebACL", "waf-regional:AssociateWebACL", "waf-regional:DisassociateWebACL" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "tag:GetResources", "tag:TagResources" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "waf:GetWebACL" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "wafv2:GetWebACL", "wafv2:GetWebACLForResource", "wafv2:AssociateWebACL", "wafv2:DisassociateWebACL" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "shield:DescribeProtection", "shield:GetSubscriptionState", "shield:DeleteProtection", "shield:CreateProtection", "shield:DescribeSubscription", "shield:ListProtections" ], "Resource": "*" } ] } EOF } そのうえで、以下のように Kubernetes のロールの設定と、IAM の紐づけを行う。 resource "null_resource" "create_rbac_role" { depends_on = [null_resource.coredns_restart] provisioner "local-exec" { environment = { KUBECONFIG = local_file.kubeconfig.filename } command = "kubectl apply -f ./output_files/rbac-role.yaml" on_failure = fail } } resource "null_resource" "create_iamserviceaccount" { depends_on = [null_resource.create_rbac_role] provisioner "local-exec" { command = "eksctl create iamserviceaccount --name alb-ingress-controller --namespace kube-system --cluster ${aws_eks_cluster.example.name} --attach-policy-arn ${aws_iam_policy.alb_ingress_controller.arn} --approve" on_failure = fail } } ここで CloudFormation のスタックが作成され、そこから IAM ロールが作成＆ポリシーへのアタッチが行われる。 スタックを削除しないと、IAM の削除ができずに terraform destroy が失敗するので注意が必要だ。 ALB を作成する準備ができたら、あとは↑で作った Manifest ファイルを、kubectl apply で流していけば良い。 resource "null_resource" "create_alb_ingress_controller" { depends_on = [null_resource.create_iamserviceaccount] provisioner "local-exec" { environment = { KUBECONFIG = local_file.kubeconfig.filename } command = "kubectl apply -f ./output_files/alb-ingress-controller.yaml" on_failure = fail } } resource "null_resource" "nginx_service" { depends_on = [null_resource.create_alb_ingress_controller] provisioner "local-exec" { environment = { KUBECONFIG = local_file.kubeconfig.filename } command = "kubectl apply -f ./output_files/nginx-service.yaml" on_failure = fail } } resource "null_resource" "nginx_deployment" { depends_on = [null_resource.nginx_service] provisioner "local-exec" { environment = { KUBECONFIG = local_file.kubeconfig.filename } command = "kubectl apply -f ./output_files/nginx-deployment.yaml" on_failure = fail } } resource "null_resource" "nginx_ingress" { depends_on = [null_resource.nginx_deployment] provisioner "local-exec" { environment = { KUBECONFIG = local_file.kubeconfig.filename } command = "kubectl apply -f ./output_files/nginx-ingress.yaml" on_failure = fail } } うまく作れると、ALB が作成され、そのURLへのアクセスで Nginx の画面が開けるはずだ。 ちなみに、この ALB を作る過程で、AWSリソースとしての ALB、ターゲットグループ、セキュリティグループが自動で作成される。 これらを削除しないと、terraform destroy で VPC が削除できずエラーになるので注意が必要だ。 この ALB はマネージメントコンソールから確認できるものの、ちゃんと不可状況に応じてスケールしてくれるかが分からない。 ALB がボトルネックになってしまったら元も子もないので、このあたりは以降でしっかり検証していきたい。

はじめに ELBのアクセス数は、特に設定不要で確認ですが、アクセスログについてはデフォルトでは無効化されているため、ちょっと設定してログを取得してみました。 以下AWSドキュメントより アクセスログの作成は、Elastic Load Balancing のオプション機能であり、デフォルトでは無効化されています。ロードバランサーのアクセスログの作成を有効にすると、Elastic Load Balancing はログをキャプチャし、圧縮ファイルとして指定した Amazon S3 バケット内に保存します。アクセスログの作成はいつでも無効にできます。 アクセスログを保存するS3バケットの作成 任意の名称でバケットを作成します。 必須ではありませんが、保存先フォルダの設定することも可能です。 S3のバケットポリシーの設定 対象バケットのアクセス許可のタブからバケットポリシーの編集を行います。ELBを設定しているリージョンによって、アカウントIDが異なりますので、注意が必要です。 ELBのアクセスログの有効化 対象のELBを選択し、属性の編集から有効化を実施し、ログの保存先に作成したS3バケットを指定します。 ちなみに、S3バケットポリシーを設定せずに有効化を実行するとAccess Deniedで怒られます。 アクセスログの確認 S3バケットを確認し、以下のようにアクセスログのオブジェクトが追加されていれば設定OKです。 参考

概要 アラフォーのAWS初心者が学んだことをつらつら書いていきます。 今回の目標 インターネットゲートウェイを作成して、プライベートサブネットからインターネットゲートウェイにルーティングをする。 教材 AWS CloudTechで学びはじめました。 AWSを学びたい人は心者でも丁寧にまた安価(参考書1冊分+コーヒー2缶)で学べるのでお勧めです。 前提 サブネット編が完了していること。 用語集 インターネットゲートウェイ・・・VPCからインターネットに接続、インターネットからVPCに接続する出入口のこと。 ルートテーブル・・・サブネットごとにどこに接続するか経路を設定する。 構成図 今回作成する構成図です。インターネットゲートウェイとルートテーブルに経路を追加します。 ルートテーブル ルートテーブルになります。今回追加するルートテーブルは、 0.0.0.0/0 Internet Gatwayとなります。 ※10.0.0.0/21 localはデフォルトで設定されており、VPC内の通信はVPC内に通信するという意味で、0.0.0.0/0 Internet Gatwayはそれ以外はインターネットゲートウェイへ通信するという意味です。 送信先 ターゲット 10.0.0.0/21 local 0.0.0.0/0 Internet gatway インターネットゲートウェイ作成 インターネットゲートウェイ作成ボタンを押します。 名前タグに以下を入力してインターネットゲートウェイ作成を押します。 名前タグ・・・Internetgatway はい。作成されました。 ただ、このままではDetachedとなっており、使用できない状態になっているので、VPCへアタッチを押します。 対象のVPCをプルダウンから作成して、インターネットゲートウェイのアタッチを押します。 はい。これでインターネットゲートウェイのアタッチは完了しましたので、サブネットにルーティング設定を追加します。 ルートテーブルの設定 VPCのダッシュボードから、サブネットを選択。その後、パブリックサブネットより、 下のルートテーブルタブに切り替えます。そして、ルートテーブル名が記載されている個所を押します。 ルートタブのルートの編集を押します。 ルートの追加を押します。 送信先・・・0.0.0.0/0 ターゲット・・・Internetgatway(※プルダウンで選択出来ます。) ルートの保存を押します。 閉じるを押します。 赤枠のように追加されていれば、問題ありません。 はい。作成されましたね。次回はいよいよ、EC2インスタンスの作成に取り掛かります。

「Amazon Web Services 基礎からのネットワーク＆サーバー構築」を読み終えたので、初めて知ったこととかをまとめ。 リージョン 「リージョン」とは、世界各地に分散されているデータセンター群のこと アベイラビリティゾーン 「アベイラビリティゾーン」とは、そのリージョンをさらに分割したもの VPC 仮想的なネットワーク サブネット VPCを分割して作ったネットワークのこと。 EC2 仮想サーバーを構築するサービス。それぞれのサーバーのことを「インスタンス」と呼ぶ。 ファイアウォール 「通してよいデータだけを通して、それ以外を遮断する機能」の総称。 あくまで総称で、「ファイアウォール」というサービスがあるわけではない。 SSH 暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。 認証方式には公開鍵認証やパスワード認証などがある。 Apache オープンソースのWebサーバーソフト。 サーバーにこれをインストールするとWebサーバーとして機能させることができる。 NAT 「片方向だけの接続を許す」といったこちらからインターネットに接続はできるが、インターネットからこちらに接続することはできないという環境を実現できる技術。

こんにちは、まゆみです。 AWSについての記事をシリーズで書いています。 今回は第8回目になります。 前回、前々回の記事では、AWSの主要なサービスの概要を書かせていただきました。 今回の記事から、そのサービスの詳細について書いていきます。 今回の記事では、AWSのセキュリティグループについて書いていきますね。 ではさっそくはじめていきます AWSセキュリティグループとは？ AWSのセキュリティグループとは、EC2においてファイアーウォールとして働くもののことです。 ファイアーウォール(防火壁)とは文字通り、 『どのようなアクセスを許可するのか？』 のアクセスコントロールになります 外からと内からのアクセスコントロール セキュリティグループはさらに 外からインスタンスに向かうアクセスコントロールと インスタンスから外に向かうアクセスコントロール に分かれます デフォルト値では、 インバウンドは全てのアクセスが拒否され アウトバウンドは全てのアクセスが許可 されます セキュリティグループを設置するときのルール では、セキュリティグループにはどんなルールがあるのか見ていきます 一つのセキュリティグループを複数のインスタンスに設置する事ができる セキュリティグループは特定のリージョン/VPCのなかで作られる セキュリティグループはEC2の外に作られる セキュリティグループは特定のリージョン/VPCのなかに作られ、そこにとどまるので、リージョンを変更したら新たにセキュリティグループを作らないといけません。 AWSのセキュリティグループは実際どうなってるの？ では、実際にコンソールでセキュリティグループがどのように表示されているのか見てみましょう EC2のインスタンスの詳細を見るため、指定したいインスタンスのボックスにレ点を付けます。 セキュリティグループのIDと、インバウンドルールとアウトバウンドルールが記載されているのが分かります インバウンドルールとアウトバウンドルールを開きます もしくは、セキュリティーグループID(セキュリティーグループと書かれた下の青い英数字の羅列部分)をクリックして、下記のページにアクセスしてみることもできます。 インバウンドルールとアウトバウンドルールのタブを押すと、それぞれのルールを見ることができます インバウンドルールを編集すると。。。 今の時点で、インバウンドルールに付与された、『http』からのアクセスに関するルールを取り外すとどうなるか見てみましょう ちゃんと、インスタンスにアクセスできているが。。。 インバウンドルールを編集をクリックして、ルールを編集します HTTP関連のルールを削除！ 先ほどインスタンスにアクセスしたものを再ロードすると、アクセスできなくなりました。 実験が済んだら、もとに戻しておきましょう。(笑) ルールを追加をクリックして、インバウンドルールを編集して、変更を保存します まとめ 今回の記事では、具体的にセキュリティグループがどのように働くか例を出しながら書かせていただきました。 お役に立てれば幸いです。

IoTデバイスでセンシングしたデータをAWS IoTにPublishし、HTML(Webアプリケーション)からsubscribeし、リアルタイム表示をします。 AWS IoTの設定 AWS IoTでデバイスからのセンサデータを受けられるように設定します。 モノの登録 AWS IoTで[モノの登録]ボタンをクリックします。 [単一のモノを作成する]ボタンをクリック。 "Thing Registryにデバイスを追加"画面で登録するデバイス（モノ）の名前を登録します。ここでは"Things"という名前にし、[次へ]に進みます。 AWS IoTへデバイスを接続するための証明書を作成します。今回は、"1-Click証明書作成"の[証明書を作成]をクリックします。 デバイスの証明書、"cert.pem"と、パブリックキー"public.key"、プライベートキー"private.key"が生成されるので、ローカルにダウンロードしておきます。 また、AWS IoTのルートCA"pem"もダウンロードしておきます。 [ポリシーの作成]ボタンをクリックすると、下図画面が表示されます。 まだ、ポリシーが存在しないため、[新規ポリシーの作成]ボタンをクリックします。 ポリシーの作成 AWS IoTリソースへのアクセス許可をモノに付与するためポリシーを設定します。左メニューの[安全性]_[ポリシー]を選択し、[ポリシーの作成]をクリックします。 ここでは、"Things_policy"という名前にしました。ステートメントを追加には、アドバンスモードに遷移し、下記JSONコードをペーストします。 statement.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot:*" ], "Resource": [ "*" ] } ] } 改めて、先程作成したモノを選択し、"セキュリティ"を選択し、表示されているモノ（下図では(fbd8b...)を選択します。 右上の"アクション"から"ポリシーのアタッチ"を選択します。 先程作成したポリシーを選択し、[アタッチ]します。 エンドポイントの確認 モノが登録されると、デバイスは、アカウントのデバイスデータエンドポイントを使用して AWS に接続できるようになります。 左メニューの[設定]を選択すると、エンドポイントが表示されますので、このエンドポイントを控えておきます。 デバイスを準備 ここでは、ローカルPCを使用しPythonで、疑似デバイスを作成してみます。 下記Pythonコードを準備します。 device.py from AWSIoTPythonSDK.MQTTLib import AWSIoTMQTTClient import logging import time import datetime import argparse import json import uuid import random AllowedActions = ['both', 'publish', 'subscribe'] # Custom MQTT message callback def customCallback(client, userdata, message): print("Received a new message: ") print(message.payload) print("from topic: ") print(message.topic) print("--------------\n\n") # add parameters ---- host = "xxxxxxxxxx.iot.ap-northeast-1.amazonaws.com" # 先程控えたエンドポイント rootCAPath = "xxxxxxxxxxx.pem" # root ca certificatePath = "xxxxxxxxxx-certificate.pem.crt" # cerfiticate for things privateKeyPath = "xxxxxxxxxx-private.pem.key" # private key port = 8883 useWebsocket = False clientId = "Things" # things name topic = "things/topic" # topic mode = "both" # tx and rx # -------------------- # Configure logging logger = logging.getLogger("AWSIoTPythonSDK.core") logger.setLevel(logging.DEBUG) streamHandler = logging.StreamHandler() formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s') streamHandler.setFormatter(formatter) logger.addHandler(streamHandler) # Init AWSIoTMQTTClient myAWSIoTMQTTClient = None if useWebsocket: myAWSIoTMQTTClient = AWSIoTMQTTClient(clientId, useWebsocket=True) myAWSIoTMQTTClient.configureEndpoint(host, port) myAWSIoTMQTTClient.configureCredentials(rootCAPath) else: myAWSIoTMQTTClient = AWSIoTMQTTClient(clientId) myAWSIoTMQTTClient.configureEndpoint(host, port) myAWSIoTMQTTClient.configureCredentials(rootCAPath, privateKeyPath, certificatePath) # AWSIoTMQTTClient connection configuration myAWSIoTMQTTClient.configureAutoReconnectBackoffTime(1, 32, 20) myAWSIoTMQTTClient.configureOfflinePublishQueueing(-1) # Infinite offline Publish queueing myAWSIoTMQTTClient.configureDrainingFrequency(2) # Draining: 2 Hz myAWSIoTMQTTClient.configureConnectDisconnectTimeout(10) # 10 sec myAWSIoTMQTTClient.configureMQTTOperationTimeout(5) # 5 sec # add ---- # Connect and subscribe to AWS IoT myAWSIoTMQTTClient.connect() time.sleep(2) # Publish to the same topic in a loop forever loopCount = 0 while True: if mode == 'both' or mode == 'publish': u4 = str(uuid.uuid4()) message = {} message['count'] = loopCount messageJson = json.dumps(message) myAWSIoTMQTTClient.publish(topic, messageJson, 1) if mode == 'publish': print('%s Published topic %s: %s\n' % (loopCount, topic, messageJson)) loopCount += 1 time.sleep(1) # ---------- デバイスの証明書、パブリックキー、プライベートキー、AWS IoTのルート証明書は、先程ダウンロードしたファイルを指定してください。 PublishされたMQTTメッセージの確認 上記Pythonコードを下記コマンドで実行すると、{"count":xxx} (xxxは0,1,2...とインクリメントされる数字)というJSONメッセージがPublishされます。 python device.py AWS IoTの左メニューから[テスト]を選択すると、"MQTTテストクライアント"画面が表示されます。 ここで、"トピックをサブスクライブする"で、Pythonコードにしていしたトピック（今回は"things/topic"を入力し、[サブスクライブ]ボタンをクリックします。 サブスクライブに成功すると、下図のようにデバイスからのメッセージを確認することができます。 HTMLからサブスクライブ デバイスからのメッセージをAWS IoT上で確認することができれば、次にHTMLから、該当トピックにサブスクライブし、javascriptを使ってリアルタイム表示します。 AWS IoTにSubscribeできるIAMユーザを作成 IAM管理コンソールから、[ユーザー]_[ユーザーを追加]を選択します。 任意ユーザー名を入力し、AWSアクセスの種類は☑プログラムによるアクセスを選択し、次のステップに進みます。 [既存のポリシーを直接アタッチ]を選択し、ポリシーには、AWSIoTFullAccessを選択します。 必要に応じ、タグを追加後、ユーザーを作成します。 ユーザーが作成されるとアクセスキーIDとシークレットアクセスキーが生成されます。[.csvのダウンロード]でアクセスキーIDとシークレットアクセスキーが記録されているcsvファイルをダウンロードし、保管しておきまます。 HTMLファイルの作成 これで、AWS IoTのリソースにアクセスする準備が完了しました。 次に下記HTMLファイルを作成します。 subscribe.html <html lang="ja"> <body> <ul id="chat"> <li v-for="m in messages">{{ m }}</li> </ul> <script src="https://cdnjs.cloudflare.com/ajax/libs/vue/1.0.16/vue.min.js" type="text/javascript"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.11.2/moment.min.js" type="text/javascript"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.2/components/core-min.js" type="text/javascript"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.2/components/hmac-min.js" type="text/javascript"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.2/components/sha256-min.js" type="text/javascript"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/paho-mqtt/1.0.1/mqttws31.js" type="text/javascript"></script> <script type="text/javascript"> var data = { messages: [] }; new Vue({ el: '#chat', data: data }); function SigV4Utils(){} SigV4Utils.sign = function(key, msg) { var hash = CryptoJS.HmacSHA256(msg, key); return hash.toString(CryptoJS.enc.Hex); }; SigV4Utils.sha256 = function(msg) { var hash = CryptoJS.SHA256(msg); return hash.toString(CryptoJS.enc.Hex); }; SigV4Utils.getSignatureKey = function(key, dateStamp, regionName, serviceName) { var kDate = CryptoJS.HmacSHA256(dateStamp, 'AWS4' + key); var kRegion = CryptoJS.HmacSHA256(regionName, kDate); var kService = CryptoJS.HmacSHA256(serviceName, kRegion); var kSigning = CryptoJS.HmacSHA256('aws4_request', kService); return kSigning; }; function createEndpoint(regionName, awsIotEndpoint, accessKey, secretKey) { var time = moment.utc(); var dateStamp = time.format('YYYYMMDD'); var amzdate = dateStamp + 'T' + time.format('HHmmss') + 'Z'; var service = 'iotdevicegateway'; var region = regionName; var secretKey = secretKey; var accessKey = accessKey; var algorithm = 'AWS4-HMAC-SHA256'; var method = 'GET'; var canonicalUri = '/mqtt'; var host = awsIotEndpoint; var credentialScope = dateStamp + '/' + region + '/' + service + '/' + 'aws4_request'; var canonicalQuerystring = 'X-Amz-Algorithm=AWS4-HMAC-SHA256'; canonicalQuerystring += '&X-Amz-Credential=' + encodeURIComponent(accessKey + '/' + credentialScope); canonicalQuerystring += '&X-Amz-Date=' + amzdate; canonicalQuerystring += '&X-Amz-SignedHeaders=host'; var canonicalHeaders = 'host:' + host + '\n'; var payloadHash = SigV4Utils.sha256(''); var canonicalRequest = method + '\n' + canonicalUri + '\n' + canonicalQuerystring + '\n' + canonicalHeaders + '\nhost\n' + payloadHash; var stringToSign = algorithm + '\n' + amzdate + '\n' + credentialScope + '\n' + SigV4Utils.sha256(canonicalRequest); var signingKey = SigV4Utils.getSignatureKey(secretKey, dateStamp, region, service); var signature = SigV4Utils.sign(signingKey, stringToSign); canonicalQuerystring += '&X-Amz-Signature=' + signature; return 'wss://' + host + canonicalUri + '?' + canonicalQuerystring; } var endpoint = createEndpoint( 'ap-northeast-1', // リージョン 'xxxxxxxxxxxx.iot.ap-northeast-1.amazonaws.com', // IoT エンドポイント（小文字） '<YOUR_ACCESS_KEY_ID>', // アクセスキー '<YOUR_SECRET_KEY>'); // シークレットキー var clientId = Math.random().toString(36).substring(7); var client = new Paho.MQTT.Client(endpoint, clientId); var connectOptions = { useSSL: true, timeout: 3, mqttVersion: 4, onSuccess: subscribe }; client.connect(connectOptions); client.onMessageArrived = onMessage; client.onConnectionLost = function(e) { console.log(e) }; function subscribe() { client.subscribe("kcmmw/topic"); // subscribe トピック console.log("subscribed"); } function onMessage(message) { data.messages.push(message.payloadString); console.log("message received: " + message.payloadString); } </script> </body> </html> このファイルをWebサーバ上に置いたうえでページアクセスし、先程のPythonコードを実行すれば、下図のようにデバイスからのメッセージをリアルタイムで表示することができます。 MQTTのサブスクライブはmosquittoを使用しています。 参考 AWS Cloud9で簡単にWebサーバを立ち上げる方法は、こちらを参考にしてください。

1. はじめに 2021年5月2日にヤマムギ様主催にて開催されたヤマムギ vol.16 AWSではじめるLinux入門ガイドのデモ(管理者コマンド、インストールコマンドなど)でのAWS学習内容について、自分への備忘録としてまとめてみました。ご参考になれば幸いです。 2. 学んだ内容 EC2インスタンスの作成 EC2への接続方法3つ（ssh、セッションマネージャー、EC2インスタンスコネクト） 管理者コマンド インストールコマンドなど 3. 学習サイト YouTube：AWSでLinuxサーバーを起動するデモ(「AWSではじめるLinux入門ガイド」のデモ) YouTube：Linuxでインストールを管理するデモ(「AWSではじめるLinux入門ガイド」のデモ) YouTube：Linux管理者権限でコマンドを実行するデモ(「AWSではじめるLinux入門ガイド」のデモ) 4. 参考サイト AWS IP アドレスの範囲 ip-ranges.json { ip_prefix: "18.206.107.24/29", region: "us-east-1", service: "EC2_INSTANCE_CONNECT", network_border_group: "us-east-1" }, 5. ハンズオンで得た豆知識 sshでEC2へ接続する場合は、接続元IPアドレスを許可（セキュリティグループ設定：ssh、22番ポート、IPアドレス）をおこなう必要あり セッションマネージャーでEC2へ接続する場合は、事前にIAMロールを作成しSSM(SSMManagedInstanceCore)が利用できる権限付与が必要、設定後はEC2を再起動し設定反映をおこなうとよい EC2インスタンスコネクトでEC2へ接続する場合は、AWSバージニアのIPアドレスを調べて、AWSバージニアのIPアドレスを接続元IPとしてアドレスを許可（セキュリティグループ設定：ssh、22番ポート、AWS北部バージニアが使っているIPアドレス（EC2_INSTANCE_CONNECT））をおこなう必要あり 6. おわりに AWS学習の参考になれば幸いです。 ハンズオン開催してくださいましたヤマムギ様、感謝いたします。 2021/05/02 NISHIZONO Takahiro

EC2（Elastic compute cloud）とは AWSの仮想サーバーサービスのことです。 EC2を利用することで、OSを乗せた仮想環境をクラウド上にすばやく作ることができます。 EC2はインスタンスという単位で、サーバー環境構築します。 インスタンスとは簡単に言えば、OSを載せた仮想サーバーのことです。 また、インスタンスは複数作成して実行することもできます。 サーバーとは クライアントからのリクエストに対して、レスポンスを返してくれるコンピューターのことです。 例としては、Webサイトを見るときにURLをクリックしたりして、どこどこのページをクライアント側から要求します。 それに対して、その対象のページのデータをクライアント側に返してくれるためのコンピュータがサーバーです。 仮想サーバーとは 簡単に言うと実際のサーバーの上に論理的なサーバーを構築することを言います。 EC2で作成する仮想サーバー 一般的な仮想サーバーの構成とEC2で作成する仮想サーバーのちがいについて図で説明します。 AMI（Amazon Machine Image） AMIとはサーバーのOSに当たるもので、インスタンス作成に必要な情報です。 EC2を作成するときには、使用するAMIを指定する必要があります。 OSを何を使うかを指定したり、中にはOSだけではなくwordpressなどのソフトウェアが搭載されているものもあります。 中には有料のものもあるので注意が必要です。 基本的にはamazon linux2を選択で大丈夫です。 インスタンスタイプ 名前の通りインスタンスのタイプを指定します。 インスタンスのスペックを決める部分で、インスタンスタイプにはさまざまな種類が存在し、指定するインスタンスタイプによって容量などが変わってきます。 「t2.micro」を例にして、名前の意味を説明すると以下のようになります。 2021年現在ではt3が最新になります。 無料枠ではt2までが使えるようになっているので、有料ならt3、無料枠を使いたいなら基本的にはt2を使うようにします。 EBS（Elastic Block Store） EC2にアタッチして使用する外付けのディスクのことです。 種類に応じてIOPS（性能）が異なります。 また、スナップショット（差分形式のバックアップ）が取得できます。 特徴としてはAZをまたいでのアタッチはできません。 EBSには以下の４種類が存在します。 基本的に理由がなければ、汎用SSDを選択で大丈夫です。 それぞれ、容量や書き込みスピードなどが違います。 バックアップは後ほど説明するスナップショットで取得することができます。 ENI（Elastic network interface） 仮想ネットワークインターフェイスの略で、EC2インスタンスなどにIPアドレスをアタッチすることができる機能です。 同じAZ内のインスタンスにアタッチ/デタッチができます。 EC2にはデフォルトでENIが付与されている。 一つのインスタンスに複数のENIを付与することができる。 このENIとインターネットゲートウェイが接続することで、Public subnetとインターネットが接続可能になる。 この辺の知識はネットワークとも関係があるので、はVPCの記事でも紹介しています。 https://qiita.com/a_goto/items/85e85095c1091c94bdc5 スナップショット EC2インスタンスをバックアップするには幾つかの方法がありますが、その中で最も手軽なのがスナップショットの作成です。 EBSを丸っとコピーしていると考えてもらえれば良いでしょう。 なお、繰り返してスナップショットを取得すると、差分を保存するようにできているため、1回目のスナップショット作成はやや時間がかかり、それ以降はあまり時間がかかなりような特性があります。 スナップショットを作成する時は、インスタンスを停止することが推奨されています。 これは、ファイルシステムが更新されている途中など、中途半端な状態でのスナップショットを作成してしまうと、復元時に問題が発生する可能性があるからです。 インスタンスを停止すれば安全にスナップショットが作成できます。 スナップショットを元にAMIを使ってバックアップを復元 AMIとスナップショットをマッピングさせて、どのスナップショットの状態のバックアップを使ってEC2を起動するか選べます。 マッピングしたスナップショットを元にAMIを使いEC2を起動し、EBSの状態を復元できます。 User data EC2が初回起動する際に実行するスクリプトのことです。 実行権限はrootユーザー権限で行われます。 EC2が作成されるまでのフロー AMIを使いOSを選択肢 → インスタンスタイプでスペックを選択 → EC2が起動 → EBS,ENIをアタッチ → User dataが実行される。 Instance meta data インスタンスの中に埋め込まれたデータのことです。 Instance meta dataはターミナルなどのコマンドツールを使って確認することができます。 またAWS専用のコマンドも存在します。 ※ただAWS専用コマンドを使うと余計なテキストが付随してくるため、プログラム内で実行すると、そのテキストを削除する処理が必要になるため、通常のコマンドで呼び出すほうが実務では推奨します。自分の目で確認したいだけなら、専用コマンドのほうが短いコマンドで実行できます。 Instance meta dataの例) ・EC2のIPアドレス ・EC2のホストネーム ・EC2が使用しているAMIのID番号 キーペア EC2へログインするための秘密鍵と公開鍵のペアのことです。 EC2にろぐいんするためにはAWSが管理する公開鍵と、ユーザー自身が保持しておく必要がある秘密鍵が必要になります。 秘密鍵と公開鍵を照合することで、EC2にログインすることができるため、ユーザーは秘密鍵を厳重に保存しておく必要があります。 この秘密鍵を他社に共有してしまったり、誰かにわかる場所に置いてしまうと、EC2に勝手にログインされてしまい、攻撃を受けたり、やりようによっては予期しない料金を課せられることにつながるため、絶対に他人に取得されないようにしましょう。 間違ってもgitなどでパブリックで公開したりしないようにしてください。過去にそういう事例もあったみたいです。

こんにちは。まゆみです。 AWSについての記事をシリーズで書いています。 今回は第7回目になります。 今回の記事では、AWSが提供するサービスのなかで最も大事な物の１つ、『EC2』についての概要をまとめていきます。 ではさっそく始めていきますね。 EC2とはパソコンそのもの EC2とは、あなたの今使っているパソコンと似たようなものだというイメージを持ってください。 ただ、パソコンと一言で言っても、その中にはたくさんの機能が含まれていますよね。 パソコンのもつ様々な機能を、AWSのEC2が持つ機能と対応させながら説明していきますね。 EC2とは？ EC2とは『Elastic Compute Cloud』の略になります。 Elastic とは『弾性』という意味なのですが、(クラウドシステムが持つ特性としてこちらの記事でもelasticityについて解説しています) ゴムボールが縮んだり膨らんだりできる弾性を持つように、あなたの使いたい需要に応じてリソースを過不足なく使える機能を持ったコンピューティングシステムになります。 EC2には、普段使うコンピュータと同じように 使うOSを選んだり、 RAMを選んだり、 ファイアーウォールを設置したり(ファイアーウォールとは何か分からない人はこちらで説明しています) することができます。 また、EC2の実体そのものは「インスタンス」と呼ばれます。 インスタンスと言われれば、EC2のことを話しているのだと認識してくださいね。 EC2と普段のコンピュータの比較 上記のイラストを参考に、AWSサービスを説明するときに使う必要な用語に軽くなれてくださいね。 EC2インスタンスを実際に作る 『EC2』はコンソールのなかの、コンピューティングセクションにあります インスタンスを起動する前に、リージョンがあなたの居住地に近いところになっているかチェックします EC2をクリックして、インスタンスを起動させると、まずOSを選択する事になります 左のサイドメニューに書いてあるものは、それぞれ マイAMI 自作する事ができる AMI Marketplace 購入する事ができる コミュニティAMI 無料のもの を示しています。 今回は、無料枠で使えるAmazon Linuxを選択します 次に、CPU、メモリ、ネットワークパフォーマンスを選択しましょう 『次のステップ』をクリックします ネットワークとサブネットを選択します。 今回は、このままデフォルト値を使います。 また下の方にスクロールするとユーザーデータを入力するところがあります ユーザーデータとはEC2インスタンスが最初に起動するときに、実行されるLinux(もしくはWindows)のコマンドになります。 EC2を作る過程が終わって、起動するときにこのコードがどのように働くか分かりますので、とりあえず下記のコードをコピペしてくださいね。 #!/bin/bash # Use this for your user data (script without newlines) # install httpd (Linux 2 version) yum update -y yum install -y httpd.x86_64 systemctl start httpd.service systemctl enable httpd.service echo "Hello World from $(hostname -f)" > /var/www/html/index.html 『次のステップ：ストレージの追加』をクリックします ハードドライブのサイズを選択します。 タグを追加します。 タグのキーと値がどのように対応されてインスタンスが起動されるのかは後述しますね。 次に、どのようなアクセスを許可し、どのようなアクセスを拒否するかの設定(ファイアーウォール)をします 新しいセキュリティグループを作成するをクリックして 『ルールの追加』でHTTPを選択します。 『起動』をクリックします 安全にSSHを使ってログインするためのキーペアを作成します 下記のスクショに書いてある順番で、キーペアを作成してください。(後々使うので、分かりやすいところに保存してくださいね。) インスタンスが作成中だと表示されます。 その下に記載されている、英字と数字と羅列の部分をクリックしましょう はじめて作ったインスタンスにレ点を付けて選択すると、そのインスタンスの詳細が下に表示されます。 詳細のタグをクリックすると、下記のような情報を見ることができます パブリックIPアドレスをコピーして、新しいタブに貼り付けエンターキーを押すと下記のようになります。 インスタンスを作る過程で、ユーザーデータに記載したスクリプトが実行されています インスタンスの状態を変更するには？ インスタンスを停止したり、起動させたりするには、インスタンスの状態というところをホバーしてみてください。 そこから停止したり、起動したり、終了したりすることができます (終了とは削除する事です) まとめ 今回の記事はここで締めくくらせていただきます。 今回は、EC2の作り方の大まかな流れを書かせていただきました。 細かい説明はまた次回以降の記事に書かせていただきますね。 この記事がお役にたてれば幸いです。<(_ _)>

0.はじめに AWS CloudForamtionは、JSONやYAML形式で単一のサービスのみではなく、 複合したサービスを使用したサービスをテンプレートとして作成・共有が可能なAWSサービスです。 例えばですがAWS公式が用意している東京リージョンのサンプルテンプレートをいくつかご紹介します。 上のURLから、AWS 東京リージョンのサンプルテンプレートコレクションを閲覧できます。 実際に使っていただく前に、CloudFormationのメリットを紹介していきます。 1.CloudFormationのメリット 構成をテンプレート化することができる ・例えば同一の構成を複数リージョンに作成する必要がある ・障害時に同一の構成を即時に作成する必要がある ・構成自体のレビューをする必要があるが、記載通りの構成をコンソールから作成する際にヒューマンエラーが起きる可能性がある 上記の際に、事前にCloudFormationテンプレートを作成することで、 サービスの展開に対して、適切なソリューションとなる可能性があります。 CloudFormationで、既存、または新規で作成するAWSアーキテクチャの全体を保存しておくことができます。 また、サービス内のソースコードについてはコードレビューを行うことが多いですが、 インフラに関しては、レビューという概念はあまり行われてこなかったと思いますが、 （作業手順書のレビューのような文化はありますが） CloudFormationを使うことで、テンプレートからサービスをアーキテクチャを起動する前に、 実際に起動するアーキテクチャをレビューすることができます。 構成をインプット・アウトプットすることができる 後ほど紹介しますが、AWS公式が作成したサンプルテンプレートや、 Qiitaやハンズオンなどで、複雑なアーキテクチャ構成が紹介されている箇所でも、 CloudFormationのテンプレートとしてテキスト化して紹介することで、 他のアカウントでも、即時に同様のアーキテクチャを展開することができます。 CloudFormationデザイナーが利用できる CloudFormation デザイナーでは、体系的に構成を作成することができます。 左のメニューから、リソースを作業画面へ挿入することで、 自動的に画面下部のJSON、YAMLで記載されたテンプレートタブに、 デザインした通りのテンプレートが作成されていきます。 また右上のダウンロードボタンをクリックすることで、 現在作業画面に表示されている構成図を画像としてダウンロードすることもできます。 2.CloudFormationテンプレートの内容 テンプレートに記載可能なプロパティは以下の通りです。 ・AWSTemplateFormatVersion ・Description ・Metadata ・Parameters ・Mappings ・Resources ・Outputs この中でResourcesだけは必須となっています。その他の記載は任意です。 例えばですが、以下のようなテンプレートがあります。 AWSTemplateFormatVersion: '2010-09-09' Resources: testVPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 今回は、必須項目のResourcesと、任意項目のFormatVersionのみが記載してあります。 Resources Resources: Logical ID: Type: Resource type Properties: Set of properties Logical IDには、そのテンプレートの内で一意なIDを命名します。 例えば今回はVPCをtestVPCと命名しましたが、 同一テンプレート内で、このVPCと関連付けたリソースを作成する際に、Logical IDを用います。 Typeは、今回はVPCの作成テンプレートなので、AWS::EC2::VPCとなっています。 （IAMポリシーでも思いますが、AWS的にはVPCはEC2の１機能なのか・・・？） Propertiesには、リソースに対して詳細なオプションを指定することができます。 これはリソースによっては、必須の項目もあります。 具体的には、EC2をテンプレートに組み込み際は、PropertiesでAMIを指定する必要があります。 AWSTemplateFormatVersion これについては、今のところ2010-09-09以外の値は認められません。 ただ今後、新しいバージョンのテンプレートが作成される可能性を考えると、 未来に残す必要があるテンプレートについては、バージョンを指定していても問題ないかと思います。 Description "Description" : "Here are some details about the template." Descriptionには、リソースに関する説明を含めることができます。 Mappings Mappings: RegionMap: us-east-1: "HVM64": "ami-0ff8a91507f77f867" us-west-1: "HVM64": "ami-0bdb828fd58c52235" eu-west-1: "HVM64": "ami-047bb4163c506cd98" ap-southeast-1: "HVM64": "ami-08569b978cc4dfa10" ap-northeast-1: "HVM64": "ami-06cd52961ce9f0d85" Mappingsでは上記のように、Mappings配列を作成しとくことで、別のプロパティで上記のマッピングを内容に含めることができます。 例えば、上の例でリージョン別のAMIを指定するMappingsを作成して、 Resources: myEC2Instance: Type: "AWS::EC2::Instance" Properties: ImageId: !FindInMap [RegionMap, !Ref "AWS::Region", HVM64] InstanceType: m1.small こんな感じで、リージョン別に起動するAMIを切り替えることができます。 Parameters Parameters: ParameterLogicalID: Type: DataType ParameterProperty: value パラメーターでは、テンプレート作成の際に、インスタンスサイズなどをテンプレートにパラメーターとして持たせることができます。 また、デフォルト値を設定することで、指定がない際に選ばれるパラメーターの指定もできます。 Parameters: InstanceTypeParameter: Type: String Default: t2.micro AllowedValues: - t2.micro - m1.small - m1.large Description: Enter t2.micro, m1.small, or m1.large. Default is t2.micro. 例えば上記の例では、InstanceTypeParameterというLogicalIDに、デフォルトでt2.microが設定されていることがわかります。 しかし、場合によっては、m1.small,m1.largeも指定することが可能であることがわかります。 例えば、検証環境では、最小サイズでインスタンスを指定して、 AllowedValuesに大きめのインスタンスサイズを含めておくことで、 そのままの内容でテンプレートを検証環境、本番環境で構成することができます。 Metadata 割愛しますが、テンプレートの詳細を記載することができます。 Outputs テンプレート間での値のやりとりや、CloudForamtionコンソールへの出力を行うことができます。 ちょっと、汎用性が高いので、こちらも省略させていただきます。 3.まとめ CloudFormationは起動・保存・共有と個人的には3つの使い方があると思っています。 構成を起動する前に、依存や影響を確認することができ、 作成したアーキテクチャを環境ごとに使い回すためにテンプレートとして保存することも可能で、 またJSONやYAML形式で共有することもできます。 そして紹介したように、CloudFormationデザイナーを使用して、 体型的なテンプレートの作成や、構成図の出力も可能です。 最初に紹介したように https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-sample-templates-ap-northeast-1.html こちらのAWS公式のサンプルテンプレートを元に、サービスやサンプルソリューションを選択して、 デザイナーで表示、起動をクリックすることで、 実際に自身のAWSアカウントでテンプレートを表示、起動することができます。 サービスの展開に最適なソリューションのために、うまく使っていきましょう！

プログラミング勉強日記 2021年5月3日 昨日の記事でインターネットゲートウェイとNATゲートウェイの違いを理解した。今日は、Egress-onlyゲートウェイというものを初めて知ったのできちんと理解する。 Egress-Only インターネットゲートウェイとは 　Egress-onlyインターネットゲートウェイを調べてみるとAWSの公式ドキュメントでは以下のように出てくる。 Egress-Only インターネットゲートウェイは水平にスケールされ、冗長で、高度な可用性を持つ VPC コンポーネントで、IPv6 経由での VPC からインターネットへの送信を可能にし、インスタンスとの IPv6 接続が開始されるのを防ぎます。 引用：https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/egress-only-internet-gateway.html 　Egress-onlyインターネットゲートウェイは、IPv6を利用してインターネットに接続するときに使用する。Egressは日本語で装置から出力するタイミングで帯域情報を計測する概念/システム(引用：ingressとegressの意味と考え方)という意味で、Egress-onlyというように外部に出ることはできない。 　NATゲートウェイのIPv6版みたいな感じで覚えておくのでいいかも？ NATゲートウェイとは 　NATゲートウェイについて調べてみるとAWSの公式ドキュメントでは以下のように出てくる。 ネットワークアドレス変換 (NAT) ゲートウェイを使用して、プライベートサブネットのインスタンスからはインターネットや他の AWS のサービスに接続できるが、インターネットからはこれらのインスタンスとの接続を開始できないようにすることができます。 引用：https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html 　VPC内に構成したプライベートサブネットからインターネットに接続するために必要なものがNATゲートウェイ。(一昨日の記事でプライベートサブネットについて触れている。) Egress-onlyインターネットゲートウェイとNATゲートウェイの違い IPv6を使ってインターネット通信を行う場合はEgress-onlyインターネットゲートウェイ IPv4使ってインターネット通信を行う場合はNATゲートウェイ