20210909のAWSに関する記事は11件です。

Amazon Linux 2 でCompassを使いSassコンパイル

Amazon Linux 2 でCompassを使いSassをコンパイル amzn2-coreからRubyをインストールすると後々厄介なので、Rubyインストールも含めて手順メモ。 RubyもGemもよく分からんけど「Sassコンパイルしたい」or「Compass使いたい人」におススメ えー、今さら?って思った人。そう、まさに今さらだから書いたんすよ。 Compassは古めの情報多いから「今でもこれで動くぜ!」ってメモっておきたい ①Rubyのインストール 以下記事が、非常に分かりやすく失敗しないので、是非やってみてください(他力本願) ②GemでCompassのインストール こちらについても、以下記事が端的でわかりやすいです(こちらも他力本願) という完全にパクリだけの内容を、メモ代わりであげておきます ※何も手を入れなくとも、①②を続けてやるだけでインスコできて幸せでした。 最初はcomposer require panique/php-sassを使ってコンパイルしていたのだけれども、 $breakpoint::やらでコンパイルエラーになるし、イヤになったんすよ。 やっぱりCompassが王道感あるよね(LibSassに移行してる感は否めないけど)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

awsデプロイ scpコマンド

AWS,Docker 困ったこと 現状 https://qiita.com/at-946/items/1e8acea19cc0b9f31b98 このサイトを参考にDocker EC2でrailsアプリのデプロイを試みましたが、 $ scp -i ~/.ssh/myapp.pem ~/myapp/config/master.key myuser@xxx.xxx.xxx.xxx:./myapp/config/ scpコマンドでmaster.keyをリモートに送ろうとしましたがエラーが出ました。 scp: /master.key: Permission denied エラーメッセージです。 調べるとサーバーにkeyを設定する必要があるとのことなのでやってみましたが、結果は同じでした。 解決方法 myuserでの権限がなかった。 $ ls -l  確認方法 権限の変え方 $ sudo chown -R myuser:myuser myapp
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

terraformでkey pairを作成してEC2にアクセス

EC2へアクセスするキーペアをterraformを使ってコードで作成及び管理してみる。 ローカルでキーペアを作成する ssh-keygen をterraformを利用して作成する流れで行きます。 terraformで鍵を作成→AWSにアップロード→アップロードした鍵を使ってEC2にアクセス と、こんな感じでまずは試してみます。 今回のversion $ terraform --version Terraform v1.0.3 on darwin_amd64 + provider registry.terraform.io/hashicorp/aws v3.42.0 Your version of Terraform is out of date! The latest version is 1.0.6. You can update by downloading from https://www.terraform.io/downloads.html tfファイルはこんな感じ。 key-pair.tf variable “key_name” { type = string description = “keypair name” #キーペア名はここで指定 default = “hoge-key” } #作成したキーペアを格納するファイルを指定。 存在しないディレクトリを指定した場合は新規にディレクトリを作成してくれる locals { public_key_file = “./.key_pair/${var.key_name}.id_rsa.pub” private_key_file = “./.key_pair/${var.key_name}.id_rsa” } #privateキーのアルゴリズム設定 resource “tls_private_key” “keygen” { algorithm = “RSA” rsa_bits = 4096 } #local_fileのリソースを指定するとterraformを実行するディレクトリ内でファイル作成やコマンド実行が出来る。 resource “local_file” “private_key_pem” { filename = local.private_key_file content = tls_private_key.keygen.private_key_pem provisioner “local-exec” { command = “chmod 600 ${local.private_key_file}” } } resource “local_file” “public_key_openssh” { filename = local.public_key_file content = tls_private_key.keygen.public_key_openssh provisioner “local-exec” { command = “chmod 600 ${local.public_key_file}” } } 上記で作成したキーペアの内、public_keyをaws側に紐付ける。 resource “aws_key_pair” “key_pair” { key_name = var.key_name public_key = tls_private_key.keygen.public_key_openssh } AWSのコンソールを見に行って問題なく鍵が表示されていれば確認はOK。 動作確認 terraformで適当なec2を作成し、public_keyに上記で作成したものを指定する。 ec2.tf resource “aws_instance” “example” { ami = “ami-09c5e030f74651050” vpc_security_group_ids = [aws_security_group.allow_internal.id] subnet_id = aws_subnet.public_1a.id key_name = aws_key_pair.key_pair.id instance_type = “t2.micro” tags = { Name = “huga” } } output “public_ip” { value = aws_instance.example.public_ip } 接続確認 $ ssh -i hoge.pem ec2-user@54.203.1.131 The authenticity of host ‘54.203.1.131 (54.203.1.131)’ can’t be established. ECDSA key fingerprint is SHA256:nL9QqcZbcCQp9r0BRq0Awa/4XdKXwS5ePU3T7zzYPEY. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘54.203.1.131’ (ECDSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ [ec2-user@ip-10-100-13-195 ~]$ ifconfig | grep inet inet 10.100.13.195 netmask 255.255.224.0 broadcast 10.100.31.255 inet6 fe80::4f2:16ff:fef5:803f prefixlen 64 scopeid 0x20<link> inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> [ec2-user@ip-10-100-13-195 ~]$ logout Connection to 54.203.1.131 closed. いい感じに接続できました。 moduleを使用したキーペア作成 ココまでだと少しコードを書く量が多く手間なので、今度はキーペア作成をmodule化してみる。 moduleを作成してinitすると、ソースが.terraform配下に作成される。 公式サイトを見ながらこんな感じでmodukeを作成。 key_module.tf resource “tls_private_key” “key” { algorithm = “RSA” rsa_bits = 4096 } module “key_pair” { source = “terraform-aws-modules/key-pair/aws” key_name = “hoge-key” public_key = tls_private_key.key.public_key_openssh } output “private_key_pem” { value = tls_private_key.key.private_key_pem } output “public_key_pem” { value = tls_private_key.key.public_key_openssh } moduleの環境用意はについてはこれを参考に 実行するとキーペアが作成される Outputs: private_key_pem = -----BEGIN RSA PRIVATE KEY----- MIIJKwIBAAKCAgEAuECq3DTeDqtQuw7S7ihSXSG4wsz/AhABE6aZQaTJAdQ28Xbj RRLaxvwV/QzFbedl8CyXW+k418mABH........ -----END RSA PRIVATE KEY----- public_key_pem = ssh-rsa AAAAB....... ... ... == 無事に作成された。 しかし、作成されたキーペアはローカルにはファイルとして生成されないため、キーを確認するためには都度applyしないと行けなさそう。。。 とりあえず作成はできたので接続確認してみる。 $ ssh -i .ssh/hoge.pem ec2-user@54.244.18.123 Warning: Permanently added ‘54.244.18.123’ (ECDSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ [ec2-user@ip-10-100-3-160 ~]$ ifconfig | grep inet inet 10.100.3.160 netmask 255.255.224.0 broadcast 10.100.31.255 inet6 fe80::4e2:1dff:fe42:d21 prefixlen 64 scopeid 0x20<link> inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> 接続確認できた。 moduleを使って作成するキーペアをworkspaceでリージョン切り替え。 VPCをマルチリージョンで展開するときにこれも入れ込んでしまえば楽に管理が出来そうですね。 key-pair.tf resource “tls_private_key” “key” { algorithm = “RSA” rsa_bits = 4096 } module “key_pair” { source = “terraform-aws-modules/key-pair/aws” key_name = lookup(var.vpc_name, “${terraform.workspace}_staging.vpc_name”) public_key = tls_private_key.key.public_key_openssh } output “private_key_pem” { value = tls_private_key.key.private_key_pem } output “public_key_pem” { value = tls_private_key.key.public_key_openssh } aws上にある既存のkeyのimport方法 下記のようにimportするkey nameを指定 public_key.tf $ cat public_key.tf resource “aws_key_pair” “test” { name = hoge-key } 上記で指定したリソース名とidを引数にコマンド実行 $ terraform import aws_key_pair.test hoge-key aws_key_pair.test: Importing from ID “hoge-key”... aws_key_pair.test: Import prepared! Prepared aws_key_pair for import aws_key_pair.test: Refreshing state... [id=hoge-key] Import successful! The resources that were imported are shown above. These resources are now in your Terraform state and will henceforth be managed by Terraform. importしたkeyはあくまでterraform管理下におけるようになるようになるだけで、公開鍵の内容を閲覧したり編集することは出来ない模様 下記のようにリソースを定義して public_key.tf resource “aws_key_pair” “test” { key_name = “hoge-key” } 下記コマンドでimportできるが $ terraform import aws_key_pair.test hoge-key aws_key_pair.test: Importing from ID “hoge-key”... aws_key_pair.test: Import prepared! Prepared aws_key_pair for import aws_key_pair.test: Refreshing state... [id=hoge-key] resource “aws_key_pair” “test” { Import successful! The resources that were imported are shown above. These resources are now in your Terraform state and will henceforth be managed by Terraform. リソースに公開鍵が追記されるような挙動はない模様 キーペアのalgorithmとbit数の変更 moduleを使用してキーペアのargorithmとbit数を変更してみる。 AWS公式 Amazon EC2 が使用するキーは、2048-bit SSH-2 RSA キーです。リージョンごとに最大 5,000 のキーペアを設定できます。 terraformで作成できるキーのalgorithmは RSA 又は ECDSA を使用可能。 bit数はデフォルトで2048bit ssh-1はそもそも作成できない模様。 Error: invalid key_algorithm “RSA1” 検証としてRSAでキーを2つ作成してみます。bit数は2048と4096。 key_module.tf resource “tls_private_key” “key2048” { algorithm = “RSA” rsa_bits = 2048 } resource “tls_private_key” “key4096" { algorithm = “RSA” rsa_bits = 4096 } module “key_pair” { source = “terraform-aws-modules/key-pair/aws” key_name = “hoge2048" public_key = tls_private_key.key2048.public_key_openssh } module “key_pair1” { source = “terraform-aws-modules/key-pair/aws” key_name = “hoge4096” public_key = tls_private_key.key4096.public_key_openssh } output “private_key_pem2048" { value = tls_private_key.key2048.private_key_pem } output “public_key_pem2048” { value = tls_private_key.key2048.public_key_openssh } output “private_key_pem4096" { value = tls_private_key.key4096.private_key_pem } output “public_key_pem4096” { value = tls_private_key.key4096.public_key_openssh } apply Apply complete! Resources: 2 added, 0 changed, 0 destroyed. Outputs: private_key_pem2048 = -----BEGIN RSA PRIVATE KEY----- MIIEpQIBAAKCAQEA1oXWPOYjSTb6j+KNhTRUWVAURbxAnReko28IY/CxC2urD5z7 ******** h6dqY5gOJx7/pFJkaWgZhQBbb1EAozoHUBfR+NCXx9Cgay0kpJ7i0IE= -----END RSA PRIVATE KEY----- private_key_pem4096 = -----BEGIN RSA PRIVATE KEY----- MIIJKgIBAAKCAgEAwnqAZsFADX5A4Jp5PxOseYIUWcfs+T8JJMqlRyV6GJB8QDQd ******** o+3MS1x74DPeDCt+N3ZROlwSpWj9hY2DIctfrXmLYuONA7VLZV5MT4bOW4v5DQ== -----END RSA PRIVATE KEY----- public_key_pem2048 = ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWhdY85iNJNvqP4o2FNFRZUBRFvECdF6Sjbwhj8LELa6 ******** MmsXrCK4xtEHnY3Z6P7fj38OP6eObHbcJqAwOckW8GaVBLgk86Ku9gNurfg5tXvQ2BapwFT public_key_pem4096 = ssh-rsa MIIJKgIBAAKCAgEAwnqAZsFADX5A4Jp5PxOseYIUWcfs+T8JJMqlRyV6GJB8QDQd ******** o+3MS1x74DPeDCt+N3ZROlwSpWj9hY2DIctfrXmLYuONA7VLZV5MT4bOW4v5DQ== 2048bitも4098bitも作成できた。 ec2を作成して接続確認 ec2.tf resource “aws_instance” “hoge2048” { ami = “ami-09c5e030f74651050" vpc_security_group_ids = [aws_security_group.allow_internal.id] subnet_id = aws_subnet.public_1a.id key_name = “hoge2048” instance_type = “t2.micro” tags = { Name = “hoge2048” } } resource “aws_instance” “hoge4096” { ami = “ami-09c5e030f74651050" vpc_security_group_ids = [aws_security_group.allow_internal.id] subnet_id = aws_subnet.public_1a.id key_name = “hoge4096” instance_type = “t2.micro” tags = { Name = “hoge4096” } } output “public_ip2048" { value = aws_instance.hoge2048.public_ip } output “public_ip4096” { value = aws_instance.hoge4096.public_ip } apply Apply complete! Resources: 2 added, 0 changed, 0 destroyed. Outputs: private_key_pem2048 = -----BEGIN RSA PRIVATE KEY----- MIIEpQIBAAKCAQEA1oXWPOYjSTb6j+KNhTRUWVAURbxAnReko28IY/CxC2urD5z7 ******** h6dqY5gOJx7/pFJkaWgZhQBbb1EAozoHUBfR+NCXx9Cgay0kpJ7i0IE= -----END RSA PRIVATE KEY----- private_key_pem4096 = -----BEGIN RSA PRIVATE KEY----- MIIJKgIBAAKCAgEAwnqAZsFADX5A4Jp5PxOseYIUWcfs+T8JJMqlRyV6GJB8QDQd ******** o+3MS1x74DPeDCt+N3ZROlwSpWj9hY2DIctfrXmLYuONA7VLZV5MT4bOW4v5DQ== -----END RSA PRIVATE KEY----- public_ip2048 = 34.208.205.55 public_ip4096 = 52.32.241.168 public_key_pem2048 = ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWhdY85iNJNvqP4o2FNFRZUBRFvECdF6Sjbwhj8LELa6 ******** MmsXrCK4xtEHnY3Z6P7fj38OP6eObHbcJqAwOckW8GaVBLgk86Ku9gNurfg5tXvQ2BapwFT public_key_pem4096 = ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDCeoBmwUANfkDgmnk/E6x5ghRZx+z5PwkkyqVHJXoYk ******** uG/QIpf8vJ6y+NC0irr24w== 接続確認 $ ssh -i .ssh/2048.pem ec2-user@34.208.205.55 The authenticity of host ‘34.208.205.55 (34.208.205.55)’ can’t be established. ECDSA key fingerprint is SHA256:Q3gIMbkKR0CkL+nQY/EykMqO9WIimDC2Dre2rhQzmqs. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘34.208.205.55’ (ECDSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ No packages needed for security; 2 packages available Run “sudo yum update” to apply all updates. [ec2-user@ip-10-100-6-6 ~]$ logout Connection to 34.208.205.55 closed. $ ssh -i .ssh/4096.pem ec2-user@52.32.241.168 The authenticity of host ‘52.32.241.168 (52.32.241.168)’ can’t be established. ECDSA key fingerprint is SHA256:AeA5vxqt/6uZRS3WhpiQVheZYiB/5LqAEAhv34LPRLg. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘52.32.241.168’ (ECDSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ No packages needed for security; 2 packages available Run “sudo yum update” to apply all updates. [ec2-user@ip-10-100-6-97 ~]$ logout Connection to 52.32.241.168 closed. 共に接続できた。 terraformで作成するkey pairは、リソース作成時に明示的に仕様を指定しない場合はawsが作成するkey pairと同じ仕様で作成される模様。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon MSKをトリガーにSASL/SCRAM認証でLambdaを実行する

Amazon MSK(Managed Streaming for Apache Kafka)とは Amazon MSKとはAWSが提供するApache Kafkaのマネージドサービスです。 Apache KafkaのClusterをマネージドサービスとして提供しています。 brokerの数やKafkaのバージョン等を指定するだけで構築でき、マネージドサービスなので実行環境などを気にする必要がないというメリットもあります。 VPC内のサブネットを選択することで作製ができ、2つ以上のサブネットがないと構築できない為、デフォルトでマルチAZとなります。 以下公式説明です。 Amazon MSK は、Apache Kafka をストリーミングデータの処理に使用するアプリケーションを簡単に構築および実行できようにする完全マネージド型のサービスです。 Apache Kafka は、リアルタイムのストリーミングデータパイプラインおよびアプリケーションを構築するためのオープンソースプラットフォームです。Amazon MSK では、ネイティブ Apache Kafka API を使用し、データレイクへの入力、データベースとの間での変更のストリーミング、機械学習および分析アプリケーションの強化を行うことができます。 なお、Apache Kafkaについては以下をご参照ください。 LambdaとMSKの連携について Lambda実行のトリガーとしてAmazon MSK(以下MSK)が選択できます。 EC2をクライアントとしてMSKにメッセージを送り、SASL/SCRAM認証でLambdaを実行するまで試してみます。 前提: クライアントEC2:javaインストール済み、kafkaダウンロード済み(MSKで指定したバージョンをダウンロードしてください。) MSK:アクセスコントロール方法→SASL/SCRAM認証,Version2.6.2,SGはEC2からの通信を許可 Lambda:NatGateway経由でアクセス1 構成自体は以下を参考にしています。 SecretsManagerでユーザ名/パスワードの作成・Clusterへの接続 今回は以下を参考に、SASL/SCRAM 認証を用いてクライアント認証を行います。そのため、まずSecretsManagerでシークレットを作成します。 SecretsManagerでクライアント認証用のユーザ名/パスワードを作成します。 「その他シークレット」を選択し、「プレーンテキスト」から以下のようにユーザ名とパスワードを入力 シークレット名は「AmazonMSK_MyClusterSecret」のようにプレフィックスが必要 デフォルトのKMSキーは使用できないため、新規にCMKを作成するか既存のCMKを使用するしかないようです。また、エイリアスがあるとエラーが出るため、削除しています。 サンプル:AmazonMSK_MyClusterSecret { "username": "alice", "password": "alice-secret" } シークレット作成後、EC2にSSHし認証します。 まず、シークレットをクラスターに関連付けます。 $ aws kafka batch-associate-scram-secret \ --cluster-arn <Clusterのarn> \ --secret-arn-list <上記シークレットのarn> 次に、以下で新規トピックを作成します。 --replication-factorなどは適宜自環境に合うように変更してください。 $ aws kafka describe-cluster \ --region ap-northeast-1 \ --cluster-arn <Clusterのarn> > ... "ZookeeperConnectString": "<ZookeeperConnectString>" ... $ cd kafka_2.12-2.6.2/bin $ ./kafka-topics.sh \ --create \ --zookeeper "<ZookeeperConnectString>"\ --replication-factor 2 \ --partitions 1 \ --topic TestTopic > Created topic TestTopic. 構成ファイル(users_jaas.conf)を作成・exportします。 usernameとpasswordはSecretsManagerで設定した値に置換してください。 $ vim users_jaas.conf $ export KAFKA_OPTS=-Djava.security.auth.login.config=users_jaas.conf users_jaas.conf(例) KafkaClient { org.apache.kafka.common.security.scram.ScramLoginModule required username="alice" password="alice-secret"; }; JDKキーストアファイルをJVMから/tmpにコピーします。 <JDKFolder>はご自身の環境の値を入れてください。 $ ls /usr/lib/jvm/ > java-1.8.0-openjdk-... ... $ cp /usr/lib/jvm/<JDKFolder>/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks プロパティファイルを作成 client_sasl.properties security.protocol=SASL_SSL sasl.mechanism=SCRAM-SHA-512 ssl.truststore.location=/tmp/kafka.client.truststore.jks 最後にBootstrapBrokerStringを取得して、MSKに適当なメッセージを送信します。 $ aws kafka get-bootstrap-brokers \ --region ap-northeast-1 \ --cluster-arn <Clusterのarn> > { "BootstrapBrokerStringSaslScram": "<BootstrapBrokerStringSaslScram>" } $ ./kafka-console-producer.sh \ --broker-list <BootstrapBrokerStringSaslScram> \ --topic TestTopic \ --producer.config client_sasl.properties > ここにメッセージを入力できます。 LambdaのトリガーにMSKを設定 次にLambdaのトリガーにMSKを設定します。 AWS CLIから設定します。 $ aws lambda create-event-source-mapping \ --event-source-arn <Clusterのarn> \ --topics TestTopic \ --source-access-configurations Type=SASL_SCRAM_512_AUTH,URI=<シークレットのURI> \ --starting-position LATEST \ --function-name <LambdaのFunction名> 設定完了後プロデューサーからメッセージを送ると... $ ./kafka-console-producer.sh \ --broker-list <BootstrapBrokerStringSaslScram> \ --topic TestTopic \ --producer.config client_sasl.properties > SampleMessage > Lambdaが実行されます。 Lambdaのログ 2021-09-09T17:38:30.028+09:00 START RequestId: XXX Version: $LATEST 2021-09-09T17:38:30.031+09:00 2021-09-09T08:38:30.031Z XXX INFO MSKから来たMessage: SampleMessage 2021-09-09T17:38:30.032+09:00 END RequestId: XXX 2021-09-09T17:38:30.032+09:00 REPORT RequestId: XXX Duration: 1.20 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 65 MB Lambdaが実行されない場合は、Lambdaにアタッチされているセキュリティグループ等構成を再度確認してみてください。 (私はセキュリティグループの設定が間違っていおり、Lambdaのトリガー欄に「PROBLEM: Connection error. Please check your event source connection configuration.」というメッセージが出ていました。) PrivateLinkでも対応可能です。詳しくはこちら ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS LambdaでサクッとAPIを叩きたい

AWS マネジメントコンソール上でLambdaを実装して、APIを叩きたい サクッとWEBAPIをLambdaで叩きたい人向けです。 AWSのコンソール上のコードエディターのみで作業を完結させたいときに。 こんな人向け ・WEBAPIを実行したい ・AWSマネジメントコンソールのみで作業を完結させたい ・headerに認証キーを付けたい ・認証キーは環境変数に入れておきたい ・返り値はステータスコードだけ取れればよい 環境情報 AWS Lambda ランタイム:Python3.9 ソースコード(PUT API) Lambda 標準の同包モジュールのみでの実装するため、 AWS Lambda コードエディター上に下記を張り付けるだけです。 import os import json import urllib.request def lambda_handler(event, context): #PUT API url_str = "https://APIURL/" headers = {"Authorization" : os.environ.get('BearerToken')} data = "data" request = urllib.request.Request(url_str, data.encode('utf-8'), method='PUT', headers=headers) response = urllib.request.urlopen(request) res_code = response.getcode() # PRINT STATUS CODE print(res_code) return { 'statusCode': res_code } 環境変数の設定 AWS Lambda上、「設定」タブ内にある「環境変数」を設定しましょう。 環境変数の名称は、ソースコードの"BearerToken"です。 出会ったエラー TypeError: POST data should be bytes or an iterable of bytes. It cannot be of type str. dataはstr型ではなくbytes型である必要があります。 スタックオーバーフローで同じエラーを抱えている人に多く出会いました。 結論としてはdataをエンコードしてあげる必要があります。 おわりに ちょっと確認したいだけだから5分でできると思ったら15分掛かったので記事にしました。 久しぶりのpythonは、アレっとなりますね。 開発初期の検証などに。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS KMS セキュリティ RDSとS3を暗号化

キーの作成 AWS KMSコンソール>カスタマー管理型のキー>キーの作成 キーのタイプ:対称 詳細オプションはデフォルトのまま エイリアス:キーの名前になるためわかりやすいものにする(Application1-keyなど) 管理できるユーザーと使用できるユーザーをチェック キーを使って暗号化する 作成したキー名をクリックする ARNの文字列をコピーしておく RDSを暗号化する データベースの作成をする際に以下項目を設定 追加設定 AWS KMS キー:キーのARNを入力 ARN:コピーしたものをペーストで作成したキーを選択する スナップショットを暗号化する 暗号化したいスナップショットのコピーを作成する際に以下項目を設定 スナップショットをチッェク>アクション>スナップショットをコピー AWS KMS キー:キーのARNを入力 ARN:コピーしたものをペーストで作成したキーを選択する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ECS Task実行時にエラー CannotPullContainerError

エラー内容 CannotPullContainerError: Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) 解決策 タスク実行時にPublicIPを付与する resource "aws_cloudwatch_event_target" "example_batch" { target_id = "example-batch" rule = aws_cloudwatch_event_rule.example_batch.name role_arn = module.ecs_events_role.iam_role_arn arn = aws_ecs_cluster.example.arn ecs_target { launch_type = "FARGATE" task_count = 1 platform_version = "1.3.0" # ターゲットをarnで設定 task_definition_arn = aws_ecs_task_definition.example_batch.arn network_configuration { assign_public_ip = "true" ★ subnets = [aws_subnet.public_subnet_1a.id] } } } private subnetで使いたいならNATゲートウェイを使う
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【個人開発】あるあるネタを言いたかったのであるあるネタを共有・投票できるアプリを作りました。

はじめに 「これあるあるだわ〜しかも結構面白いからみんなに共有したいなー」 って思ったことありませんか? ありますよね? あると思います。 ということで今回、あるあるネタを共有・投票できるアプリをリリースしました! サービス概要 日常で起きたあるあるネタを投稿し、一人何回でも投票できるアプリケーションです。 一人で何回でも投票できるため、自分の投稿を意図的に上の方に持ってくることも可能です。 複数回投票できることで承認欲求も満たせるかと思います。 Twitter共有もできるので、ぜひオススメのあるあるネタをたくさん共有してみてください! 使用技術 バックエンド Ruby 2.7.2 Rails 6.0.4.1 RSpec 5.0.2 RuboCop 1.20.0 JWT 2.2.3 フロントエンド Vue 2.6.14 VueRouter 3.5.2 Vuex 3.6.2 Vuetify 2.5.8 VeeValidate 3.4.12 axios 0.21.1 ESLint 0.4.3 インフラ Nginx Puma AWS VPC EC2 Route53 RDS ALB ACM Capistrano インフラ構成図 最後に Vue.jsを使ってアプリを作ったのは初めてだったので、いろいろとわからないこともありましたが楽しく作れました。 やはり初学者にとって日本語のドキュメントがあるのは助かりますね笑 最後まで読んでいただきありがとうございました! 前回作ったアプリについての記事も見てくれたら嬉しいです↓ 【個人開発】家の中にときどき出る不快な虫を検索するサービス「むしめがね」をリリースしました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SAA合格体験記

この記事は AWS歴3年、インフラエンジニア歴5年の駆け出しエンジニアがAWS SAAを受験した体験記を残すものです。 書いていること、書かないこと 書いていること 勉強に費やした期間や、使った教材の話 自宅受験ノウハウ(ここがメインかもしれません) 書かないこと 具体的な問題や出題分野の話 勉強のコツの話 勉強に費やした期間や、使った教材の話 勉強に費やした期間 2021年7月に受験を決め、受験は9/8なので2ヶ月ほど「勉強できる」期間がありました。 もともと、業務でAWSも使っていましたし、ここ3年ほどはサーバレスアーキテクチャをベースに一部EC2の設計から運用まで実務経験があったので勉強はお盆休みでいいかぁ、くらいでした。 そして、お盆休みは夏休みの高揚感に負け、全く勉強できず・・・・・・ 時は過ぎ、9月に入り、脳内で「SAA、9/10だったよなー」と思ったのが9/7のことです。 そして、受験当日の9/8の朝に環境チェックのためにAWS認定アカウントのページに行ってみると、え、今日なの!? となった、なんともお恥ずかしい気付き方でした。 なので、正直なところ無対策です(試験直前の3時間くらい)。 今回の受験は3年の実務経験による知識で臨んだというイメージです。 使った教材 実は、2018年に一度SAAを受験して650点くらいで不合格でした。 その時に、Udemyの以下の講座を購入していました。 これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版) 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) 本腰を入れて勉強、というわけではないのですが、ほんとにたまに、気づいた時に問題集を解いてはいました。 自宅受験ノウハウ COVIC-19の影響もあるのかないのか、AWS認定資格も自宅受験ができるようになりました。 ピアソンVUEでの受験についてはこちら 試験の申し込みなどは苦労したことはなかったんですが、当日がとてもきつかった・・・ ふりかえって考えてみると、当たり前な話なのですが事前の環境整備がとても重要です。 電気機器は全て手の届かないところに移動させる 机の上にあるあらゆる電気機器は全て手の届かないところに移動させないといけません。 僕の場合、これらが指摘されました。 PCと接続しているUSBスピーカ 外付けDVDドライブ 3in1充電器(スマホとAppleWatchとAirPodsを充電できるアレ) ついでに充電してたAppleWatch 文字が見えるものは手の届かないところに移動させる 文字のあるもの、それが見えるものが手の届く範囲にある場合、移動させましょう。 もしくは、上から布をかけて見えない状態にしましょう デスク横の本棚にある本たち カレンダー コースター 確かにこれは文字でしかない…… モニタには布をかけましょう 複数モニタ使っている方は多いと思いますが、外付けしているモニタに関して、上から布をかけて完全にモニタ面を覆うように指示されました。 これが一番焦ったんですが、大きめのモニタを使っている人はおうちにそれを隠せるだけの布があるのかが重要ですね。 受験した感想 ほぼ無対策で臨んだ分、やっぱり問題に対する耐性が低かったのでかなり難しく感じました。 ただ、よく読んで文章を理解してみると経験したことであったり自分で実際に考えたことのあるようなことばかりだったので解きやすかったです。 そういう意味では、2018年に受験して不合格だった時に比べ、より実務的な問題が増えているように思えます。 日本語が分かりにくい、という意見もあったりしますがずいぶん改善されているような気がしました。 問題集やBlackbeltなどで知識をつけて試験に臨むことも非常に重要と思いますし、そこをしっかりやっていればもっと楽勝で合格できたのだと思いますが、実際に手を動かして使ってみることが非常に重要なのではないかなと思いました。 次は、DVAに挑戦予定です。 今度はちゃんと勉強するぞ!ということで、とりあえずバウチャーを使って模擬試験を受験しました。 弱いところがわかったので、ここを中心に勉強していこうと思います。 なんだか、資格が体系的に整理されているので一つ合格すると次はこれやってみよう、とモチベーションが上がるのがとても良いですね!! SAA自体の受験にはあまり役立つ情報は書けなかった気がしますが、自宅受験ノウハウ、ぜひ皆さんの受験に役立ててください。 心の平穏につながります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

QGISとAmazon AuroraのPostgreSQL&PostGISを利用してジオデータを表示してみた

QGISとAmazon AuroraのPostgreSQL&PostGISを利用してジオデータを表示してみました 2年くらい前に「QGISとCloud SQLのPostgreSQL&PostGISを利用してジオデータを表示してみた」という記事を書いたのを思い出して、今回はAmazon AuroraでPostgreSQL&PostGISデータベースを構築しQGISで表示してみました! Amazon Auroraの設定 はじめに、Amazon Auroraでデータベースを作成します。 AWSコンソールでAmazon RDSに移動し「データベースの作成」をクリックします。次に、標準作成・Amazon Aurora・PostgreSQL・プロビジョニング済み・PostgreSQL 13.3・開発/テストを選択します。 DBクラスタ名・ユーザー名・パスワードを設定します。それ以外はデフォルトに設定。 パブリックアクセスあり・セキュリティグループ新規作成・初期データベース名を設定します。それ以外はデフォルトに設定。本番環境では利用しませんが、パブリックアクセスありにすることでローカルPCから直接アクセス可能となります。 データベースが作成されたらクラスターをクリックします。 ホスト情報で必要になるので、エンドポイントをコピーしておきます。 これでAmazon Auroraの設定は完了になります PostGISの設定 次に、PostGISのインストールとGISデータのインポートをします。 今回はDBeaverを利用しAmazon Auroraに接続します。ホスト名にコピーしたエンドポイントとポート・データベース名・ユーザー名・パスワードを設定します。 Amazon Auroraに接続後、PostGISをインストールします。 CREATE EXTENSION postgis; インストールされているか確認します。 SELECT postgis_version(); データのインポートについてですが、100万件のポイントデータをインポートしてみました。 インポート方法は、以前の記事ではQGISのDBマネージャーでインポートができましたが、Amazon RDSだと正常にインポートできなかったため、今回は「shp2pgsql」でデータをインポートしました。 これでPostGISの設定は完了になります QGISで表示 最後に、QGISでAmazon Auroraに接続しデータを表示します。 レイヤ → データソースマネジャー ホスト名にコピーしたエンドポイントとポート・データベース名・ユーザー名・パスワードを設定し、Amazon Auroraに接続します。 インポートしたデータを選択し追加します。 100万件のデータがリアルタイムに表示されているのを確認できます。 QGISとAmazon AuroraのPostgreSQL&PostGISを利用してジオデータを表示できました QGISとAmazon Auroraを利用することで、ローカルPCからもデータを直接確認することができました。Cloud SQLと同じく、社内等でデータを共有したい場合にうまく利用できそうです!ただ、ローカルでDBを用意するのと違って従量課金がかかってしまうのがデメリットかなと思います。 今後、Amazon RDSのPostgreSQL&PostGISにもトライしてみたいと思います やってみたシリーズ tags - Try QGISとCloud SQLのPostgreSQL&PostGISを利用してジオデータを表示してみた Amazon Location ServiceとLeafletとAWS AmplifyとVue.jsを組み合わせてマップアプリケーションを構築してみた AWS AmplifyとAmplify UI VueとVue.jsでログイン機能を構築してみた Serverless FrameworkでTypeScriptのサーバーレスAPIをAWSにデプロイしてみた
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon S3 Glacier のボールト とは

勉強前イメージ Glacier を高く飛び越える・・・? 英語だけじゃよくわからん 調査 Amazon S3 Glacier のボールト とは s3 Glacierのデータモデルの主要概念の内の一つで、 アーカイブを格納するコンテナのことを指します。 s3で言い換えるとバケットのことになります。 s3 Glacierのデータモデルの主要概念には 他にも アーカイブ というものがあり、 ログファイルや動画、写真などのデータのことを指し、 s3で言い換えるとオブジェクトのことになります。 ボールトロック とは ボールトロックとは、ボールトロックポリシーを用いて s3 Glacierのコンプライアンス管理を簡単に適応することが出来ます。 ポリシーで、読み込みのみにしたり 登録から1年経過しないと削除できないなどの ポリシーを適応することが出来ます。 ボールトロックの適応方法 ボールトロックポリシーは変更ができないので、セットを行うのに2段階プロセスを踏みます。 ボールトロックポリシーをボールトに関連付け これによりテスト状態(InProgress)になる 戻り値でLockIDが返ってくる テスト状態は24時間 テスト状態の際もポリシーは適応されている LockIDをかけて本格的に稼働 ここから変更できなくなる 適応してみる 適当なボールトの作成 test-tokyoにボールトロックポリシーを適応していきます タブでボールトロックから ボールトロックポリシーの作成 に進みます アクセス許可追加の設定 下の枠に直接ポリシーの記載も出来ますが、 ウィザード形式での選択も可能です。 今回はウィザード形式での記載を行います。 アクセス制御の設定 今回はアーカイブを削除することを禁止します。 以下設定です。 効果 : 拒否 プリンシパル : 全員 アクション : DeleteArchive 追加をするとJSON形式で表示されます。 ボールトロックを実施 問題なければボールトロックを開始します。 ボールトロックIDの記録 テスト状態になるとロックIDが発行されるので記録しておきます。 この状態で色々テストを行います この状態はすでにテスト状態なので、色々確認することが出来ます。 問題なければ本格的にロックを行います。 ボールトロックポリシーの有効期限も表示されます。 ボールトロックの完了を実施 テストで問題なければ ボールトロックの完了 で本格的に適応します ボールトロックの完了 先程出力されたロックIDを記載し 元に戻せないこと了承して完了を行います。 設定完了 ボールトロックが設定できました。 削除について 設定が完了したボールトロックは変更することが出来ないので、作り直すしかありません。 削除の際は、アーカイブを全て削除してからでないとボールトは削除できません。 また、削除してからでは同じ名前でボールトを作成することは可能です。 削除を行う ボールトの削除を行う test-tokyo ボールトにはアーカイブがないので、そのままボールトの削除を行います。 ボールトの削除へ進みます。 ボールトの削除 良ければ削除します 削除の完了 完了です。 勉強後イメージ 消せないようにだったり、アクセスできないようにすることが出来るってのが ボールトロックポリシーの適応ってことか。 作ってみたらわかりやすかった。 参考 Amazon S3 Glacier のよくある質問 【新機能】Amazon Glacierのアーカイブに上書き、削除禁止の「ロックポリシー」機能がつきました。 S3 Glacierのボールトロック 【AWS】S3-Glacierの特徴を改めて整理する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む