CloudFrontのオリジンアクセスアイデンティティを使用して、CloudFront経由でのみS3バケット内のコンテンツにアクセスさせてみます。
CloudFrontのオリジンの設定で以下のように設定します。
RestrictBucketAccessをYesに、
Origin Access IdentityをCreate a New Identityに、
Grant Read Permissions on BucketをYes, Update Bucket Policyにします。
すると以下のようにオリジンに設定したバケットのバケットポリシーが自動で設定されます。
S3バケットに直接アクセスすると以下のようにAccess Deiniedになります。
しかし、CloudFrontのDNS名経由ではアクセスすることができます。
セキュアですね。
AWSCLIを利用してAWSアカウントをコマンド一撃で作成してみます。
これでいけます。
アカウント名とルートアカウントのメールアドレスを指定してあげるだけです。
aws organizations create-account --email myemail@example.com --account-name kabegiwablog
べんりですね
Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)
ECS上でApacheを動かしてアクセスするだけのおはなしです。
具体的には以下のような構成です。
ECSに接続するLBを事前に作成しておきます。
リスナーをHTTPSで
ターゲットグループはポートを8080にします。ヘルスチェックは/healthで作成します。
ふつうにつくればもんだいないです。
ネットワークモードをbridgeにし、コンテナをhttpdで作成します。
また、ポートマッピングでホストポート8080をコンテナポート80にマッピングしておきます。
サービスの設定で、さきほど作成したタスク定義を起動するように設定する。
https://ALBのドメイン名でアクセスする。
It works!!!
ワインをのみながらかいている。
sudoでリダイレクトがしたくなった。
たとえば以下のようにやるとPermission Deniedってなってしまう。
sudo echo 'wawawa' > /etc/wawawa.txt bash: permission denied: /etc/wawawa.txt
bash -cをつかってあげる。
以下のようなかんじ。
sudo bash -c "echo 'wawawa' > /etc/wawawa.txt"
おぼえておく。
ALBにACM/SSL証明書を関連付けてみます。
画像のような感じです。
基本的なかたちですね。
ユーザからALBまではHTTPSで、ALBからEC2までの内部通信はHTTPです。
以下ですこしやりました。
ALBからのアクセスを受けるEC2インスタンスを設定してあげます。
セキュリティグループはALBからの通信を受けられるような設定のものをアタッチしてあげます。
以下のようなかんじの設定でALBを作成してあげます。
名前: すきななまえ
スキーマ: インターネット向け
IPアドレスタイプ: ipv4
リスナー: HTTPS
VPC: すきなVPC
アベイラビリティゾーン: すきなAZ
証明書タイプ: ACM から証明書を選択する
証明書の名前: 手順1 で取得した証明書の名前
セキュリティグループ: インバウンドに任意の場所からHTTPSが許可されたものを選択
ターゲットグループ: 新しいターゲットグループ
名前: すきななまえ
ターゲットの種類: インスタンス
プロトコル: HTTP
ポート: 80
ヘルスチェックのプロトコル: HTTP
ヘルスチェックのパス: /
手順2で作成したインスタンスを登録済みに追加する。
インスタンスにssh接続し、以下を実行してApacheの設定をしてあげます。
sudo yum install -y httpd
sudo mkdir -p /var/www/html
sudo bash -c "echo 'wawawa' > /var/www/html/index.html"
sudo systemctl start httpd
この時点でALBからインスタンスにアクセスできるかどうかを確認してみます。
ターゲットグループのステータスがhealthyかどうかを確認します。
ALBのDNS名からブラウザでアクセスして確認してみます。
https://ALBのドメイン名です。
証明書のドメインとALBのドメインが違うため、警告がでますが、無視してさきにすすみます。
wawawaと表示されればOKです。
ALBのDNS名をコピーし、Route53にCNAMEとして追加してあげます。
ホストゾーン: ACM取得したドメイン
タイプ: Aレコード
エイリアス先: 作成したALB
ブラウザからドメイン名でアクセスします。
HTTPSで通信ができているはずです！！！
べんりですね
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
お名前.comで取得したドメインの証明書をACMで取得してみます。
こんなかんじの手順です。
Route53でACMを取得するドメイン名でHosted Zoneを作成します。
作成されたときにできるNSレコードを控えておきます。
次の手順で使います。
続いて、お名前.comの[ドメイン設定]-[ネームサーバーの変更]へ遷移し、ACMを取得するドメインを選択、先の手順で控えたNSレコードを入力します。
インターネットの環境により、反映完了まで24時間から72時間程度かかる場合があるらしい。
マネジメントコンソールから[証明書のリクエスト]であとは画面にそってしすすみます。
検証方法はDNSによる検証で良いと思います。
画面にそってすすんでステップ5で[Route53でのレコードの作成]を選択してRoute53にCNAMEレコードを追加してあげます。
できました。
かんたんですね。
図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書
Kubernetes クラスタを切り替えます。
手順です。
$ kubectl config get-clusters NAME test.ap-northeast-1.eksctl.io wawawa.ap-northeast-1.eksctl.io
$ kubectl config current-context kabegiwa@wawawa.ap-northeast-1.eksctl.io
$ kubectl config use-context kabegiwa@test.ap-northeast-1.eksctl.io Switched to context "kabegiwa@test.ap-northeast-1.eksctl.io".
べんりですね
EKSクラスタを作成してpodをつくるまでのメモです。
手順です。
こんなかんじ
podはひとつだけ
作成に10分くらいかかる
$ eksctl create cluster --name test --nodes 1
kubectlで使えるようにconfigに追記させる。
$ eksctl utils write-kubeconfig --name test --kubeconfig ~/.kubeconfig
クラスタができている。
$ eksctl get cluster NAME REGION test ap-northeast-1
fargateではないのでnodegroupがインスタンスで動作している。
$ eksctl get nodegroup --cluster test CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID test ng-67463005 2020-01-02T04:08:54Z 1 1 1 m5.large ami-02e124a380df41614
podをつくります。
$ kubectl create -f sample-pod.yaml
apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: linux image: centos
podができている。
$ kubectl get pods NAME READY STATUS RESTARTS AGE sample-pod 0/1 CrashLoopBackOff 8 10m
むずかしいですね
Kubernetes完全ガイド (impress top gear)
2019年をふりかえる。
2社ほどでお仕事した。
2020年からはまた新しいところでお仕事する。
期待を裏切ったり裏切られたりいろいろあった。
もっとうまくやれた場面はあったとおもう。
お酒をのんで駅のホームでしらないおじさんに怒鳴られたり、前歯が欠けたり、公園で目を覚ましたり、スマホを落とすなどした。
まだなんとか生きています。
いまもシャンパンを飲みながらこの日記をかいている。
バッテリー残量が液晶モニタ的なものに表示されるのでよい。
ダイソン 掃除機 コードレス Dyson V11 Fluffy SV14 FF ニッケル/アイアン/ブルー
画面が黄色っぽくなるだけなんだけどそれがハイパーよい。
ほぼ紙
Kindle Oasis 色調調節ライト搭載 Wi-Fi 32GB 広告つき 電子書籍リーダー
広告がでないのはやっぱりよい。
Google Play Musicもついているし。
Youtube Musicはつかっていない。
新作旧作問わず順不同
ぜんぜんみれていない
ドキュメンタリーおおめ
いきのびます。
リモートステートをつかって別のstateファイルの値を参照して見たいと思います。
これによって stateをまたいでいろいろできたりするのでstateの分離等もしやすくなるかもしれないしならないかもしれない。
EC2インスタンスを作成するstateと、それにEIPをアタッチするstateが別なんだけれどもアタッチができるよっていうのをやります。
前提です。
Terraformのバージョン等はこんなかんじ。
$ terraform --version Terraform v0.12.18 + provider.aws v2.43.0
ひとつめのstateです。
provider "aws" { region = "ap-northeast-1" } terraform { backend "s3" { bucket = "mybucket" key = "terraform.tfstate" region = "ap-northeast-1" } } resource "aws_instance" "example" { ami = "ami-068a6cefc24c301d2" instance_type = "t3.micro" subnet_id = aws_subnet.subnet.id } resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" } resource "aws_subnet" "subnet" { cidr_block = "10.0.1.0/24" vpc_id = aws_vpc.main.id } resource "aws_internet_gateway" "igw" { vpc_id = aws_vpc.main.id } output "instance_id" { value = aws_instance.example.id }
2つめです。
provider "aws" { region = "ap-northeast-1" } data "terraform_remote_state" "remote_state" { backend = "s3" config = { bucket = "mybucket" key = "terraform.tfstate" region = "ap-northeast-1" } } resource "aws_eip" "eip" { instance = data.terraform_remote_state.remote_state.outputs.instance_id }
うごかしてみます
こんなかんじになります。
参照される値はoutputで出力する必要があります。
$ terraform apply ~~~省略~~~ Apply complete! Resources: 1 added, 0 changed, 1 destroyed. Outputs: instance_id = i-02814f190bddac514
EIPがアタッチされていることがわかりますね
$ terraform apply
data.terraform_remote_state.remote_state: Refreshing state...
aws_eip.eip: Refreshing state... [id=eipalloc-08169d0c5eaa117f4]
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
# aws_eip.eip is tainted, so must be replaced
-/+ resource "aws_eip" "eip" {
+ allocation_id = (known after apply)
+ association_id = (known after apply)
~ domain = "vpc" -> (known after apply)
~ id = "eipalloc-08169d0c5eaa117f4" -> (known after apply)
+ instance = "i-02814f190bddac514"
+ network_interface = (known after apply)
+ private_dns = (known after apply)
+ private_ip = (known after apply)
~ public_dns = "ec2-3-114-205-18.ap-northeast-1.compute.amazonaws.com" -> (known after apply)
~ public_ip = "3.114.205.18" -> (known after apply)
~ public_ipv4_pool = "amazon" -> (known after apply)
- tags = {} -> null
~ vpc = true -> (known after apply)
}
Plan: 1 to add, 0 to change, 1 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
aws_eip.eip: Destroying... [id=eipalloc-08169d0c5eaa117f4]
aws_eip.eip: Destruction complete after 1s
aws_eip.eip: Creating...
aws_eip.eip: Creation complete after 1s [id=eipalloc-0bd8be7d66afa0c58]
Apply complete! Resources: 1 added, 0 changed, 1 destroyed.
べんりですね
Terraform: Up and Running: Writing Infrastructure as Code
TerraformのtfstateファイルをS3バケットで管理してみます。
仕事でチームでやるときはだいたいこの設定でやると思う。
こんなかんじで設定してあげます。
terraform { backend "s3" { bucket = "mybucket" key = "terraform.tfstate" region = "ap-northeast-1" } }
terraform initするだけでtfstateファイルがS3バケットに格納されるようになります。
tfstateファイルはGitで管理するよりこっちのほうが良いと思う。
pushとかpullしわすれたときの被害がでかいと思う。
その点、これは自動でやってくれるのでべんり。
Elastic Beanstalkで作成されたS3バケットを削除しようとしたときに以下のようなエラーがでた。
botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the DeleteBucket operation: Access Denied
権限は足りてるはずなのにおかしいなあと思ってすこしハマったのでメモ
バケットポリシーに以下にようなポリシーが設定してあるため。
DeleteBucketをDenyしている。
{ "Sid": "eb-58950a8c-feb6-11e2-89e0-0800277d041b", "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "s3:DeleteBucket", "Resource": "arn:aws:s3:::elasticbeanstalk-ap-northeast-1-961262193080" }
単純にバケットポリシーを削除してしまえばいい。
意外とハマった
Amazon Web Servicesインフラサービス活用大全 システム構築/自動化、データストア、高信頼化 (impress top gear)
Terraformでランダムな数値列をサフィックスにして、バケットの名前がかぶらないようにしつつ、バケットを作成してみます。
terraformのバージョン等はこんなかんじ。
$ terraform --version Terraform v0.12.18 + provider.aws v2.43.0 + provider.random v2.2.1
こんなかんじでできます。
randomプロバイダを利用します。
provider "random" {} resource "random_integer" "suffix" { min = 10000000 max = 99999999 } resource "aws_s3_bucket" "bucket" { bucket = "kabegiwa-${random_integer.suffix.result}" }
こんなかんじでバケットが作成されます。
$ aws s3 ls 2019-12-28 18:51:25 kabegiwa-18721568
べんりですね
Terraform: Up & Running: Writing Infrastructure As Code
Terraformの実行時にわたした引数によって処理を変更し、作成されるリソースを変えてみたいと思います。
引数hikisuuがtrueであればサブネットを作成する。 falseであればしない。といったかんじ。
VPCはどちらの場合でも作成される。
variable "hikisuu" { type = bool } resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" } resource "aws_subnet" "subnet" { count = var.hikisuu ? 1 : 0 vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" }
こんなかんじになる。
$ terraform plan -var "hikisuu=true"
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# aws_subnet.subnet[0] will be created
+ resource "aws_subnet" "subnet" {
+ arn = (known after apply)
+ assign_ipv6_address_on_creation = false
+ availability_zone = (known after apply)
+ availability_zone_id = (known after apply)
+ cidr_block = "10.0.1.0/24"
+ id = (known after apply)
+ ipv6_cidr_block = (known after apply)
+ ipv6_cidr_block_association_id = (known after apply)
+ map_public_ip_on_launch = false
+ owner_id = (known after apply)
+ vpc_id = (known after apply)
}
# aws_vpc.main will be created
+ resource "aws_vpc" "main" {
+ arn = (known after apply)
+ assign_generated_ipv6_cidr_block = false
+ cidr_block = "10.0.0.0/16"
+ default_network_acl_id = (known after apply)
+ default_route_table_id = (known after apply)
+ default_security_group_id = (known after apply)
+ dhcp_options_id = (known after apply)
+ enable_classiclink = (known after apply)
+ enable_classiclink_dns_support = (known after apply)
+ enable_dns_hostnames = (known after apply)
+ enable_dns_support = true
+ id = (known after apply)
+ instance_tenancy = "default"
+ ipv6_association_id = (known after apply)
+ ipv6_cidr_block = (known after apply)
+ main_route_table_id = (known after apply)
+ owner_id = (known after apply)
}
Plan: 2 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
$ terraform plan -var "hikisuu=false"
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# aws_vpc.main will be created
+ resource "aws_vpc" "main" {
+ arn = (known after apply)
+ assign_generated_ipv6_cidr_block = false
+ cidr_block = "10.0.0.0/16"
+ default_network_acl_id = (known after apply)
+ default_route_table_id = (known after apply)
+ default_security_group_id = (known after apply)
+ dhcp_options_id = (known after apply)
+ enable_classiclink = (known after apply)
+ enable_classiclink_dns_support = (known after apply)
+ enable_dns_hostnames = (known after apply)
+ enable_dns_support = true
+ id = (known after apply)
+ instance_tenancy = "default"
+ ipv6_association_id = (known after apply)
+ ipv6_cidr_block = (known after apply)
+ main_route_table_id = (known after apply)
+ owner_id = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
ながくなった。
実践Terraform AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)
TerraformでAWSアカウント番号(アカウントID)を取得してみます。
Terraformのバージョンはこんなかんじ。
$ terraform --version Terraform v0.12.18 + provider.aws v2.43.0
みんなだいすきcaller_identityです。
data "aws_caller_identity" "wawawa_id" {} output "account_id" { value = data.aws_caller_identity.wawawa_id.account_id }
べんりですね。
DevOpsを支えるHashiCorpツール大全 ThinkIT Books
