RedashをAMIから起動してみた

公式AMIからインスタンスの起動

https://redash.io/help-onpremise/setup/setting-up-redash-instance.html

から AMI を選択します。Region ap-northeast-1 の AMI リンクをクリックするとインスタンスタイプを選択する画面に遷移するので、適当なインスタンスタイプを選択します。

1年間の無料枠を使っているので無料で使える t2.micro にしました。

キーペアを設定して起動します。

アクセス設定

マネジメントコンソールからインスタンスのセキュリティーグループのインバウンドで HTTP アクセスを適切に許可します。

これでブラウザからインスタンスのIPにアクセスすればページが表示されます。

internal_server_error.png

Internal Server Error(500エラー)ですね。サービス側に問題がありそうなので確認します。

サーバ側設定

起動したインスタンスに SSH ログインします。

とりあえずサービスを再起動してみます。

$ sudo supervisorctl restart all
redash_server: stopped
redash_celery_scheduled: stopped
redash_celery: stopped
redash_celery: started
redash_server: started
redash_celery_scheduled: started

再度ブラウザをリロードしてみますが、Internal Server Error に変化はありません。

supervisord のログを確認します。

$ less /var/log/supervisor/supervisord.log

が、怪しそうなログは出ていません。Redash が使っているサービスの起動状態をひとつひとつ確認します。

PostgreSQL のプロセスを確認します。

$ ps aux | grep -i postgres
ubuntu   21547  0.0  0.0  12948   932 pts/0    S+   13:47   0:00 grep --color=auto -i postgres

見つからないので、PostgreSQL が起動していない事が原因のようです。ログを確認します。

$ less /var/log/postgresql/postgresql-9.5-main.log
2017-10-16 13:32:30 UTC [1352-1] LOG:  database system was shut down at 2017-08-13 12:39:56 UTC
2017-10-16 13:32:30 UTC [1352-2] LOG:  MultiXact member wraparound protections are now enabled
2017-10-16 13:32:30 UTC [1351-1] LOG:  database system is ready to accept connections
2017-10-16 13:32:30 UTC [1356-1] LOG:  autovacuum launcher started
2017-10-16 13:32:31 UTC [1361-1] [unknown]@[unknown] LOG:  incomplete startup packet
2017-10-16 13:34:33 UTC [1351-2] LOG:  received fast shutdown request
2017-10-16 13:34:33 UTC [1351-3] LOG:  aborting any active transactions
2017-10-16 13:34:33 UTC [1705-1] redash@redash FATAL:  terminating connection due to administrator command
2017-10-16 13:34:33 UTC [1704-1] redash@redash FATAL:  terminating connection due to administrator command
2017-10-16 13:34:33 UTC [1356-2] LOG:  autovacuum launcher shutting down
2017-10-16 13:34:34 UTC [1353-1] LOG:  shutting down
2017-10-16 13:34:34 UTC [1353-2] LOG:  database system is shut down
2017-10-16 13:34:53 UTC [19851-1] FATAL:  could not map anonymous shared memory: Cannot allocate memory
2017-10-16 13:34:53 UTC [19851-2] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 148488192 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

FATAL エラーが出てますね。その前にログの時刻が見づらいので、タイムゾーンを日本時間に変更します。

$ sudo timedatectl set-timezone Asia/Tokyo
$ date
Mon Oct 16 22:53:17 JST 2017

JST に変わりました。

先ほどの PostgreSQL のエラーは割り当てられたメモリサイズが大きいというもののようです。

$ sudo vi /etc/postgresql/9.5/main/postgresql.conf

#max_connections = 100
max_connections = 50

#shared_buffers = 128MB
shared_buffers = 32MB

少ないですね。再起動します。

$ sudo /etc/init.d/postgresql restart
Restarting postgresql (via systemctl): postgresql.service.

プロセスを確認します。

$ ps aux | grep -i postgres
postgres 21785  0.0  1.5 186840 15880 ?        S    23:02   0:00 /usr/lib/postgresql/9.5/bin/postgres -D /var/lib/postgresql/9.5/main -c config_file=/etc/postgresql/9.5/main/postgresql.conf
postgres 21787  0.0  0.3 186840  3832 ?        Ss   23:02   0:00 postgres: checkpointer process
postgres 21788  0.0  0.3 186840  3832 ?        Ss   23:02   0:00 postgres: writer process
postgres 21789  0.0  0.3 186840  3832 ?        Ss   23:02   0:00 postgres: wal writer process
postgres 21790  0.0  0.6 187244  6104 ?        Ss   23:02   0:00 postgres: autovacuum launcher process
postgres 21791  0.0  0.3 148544  3128 ?        Ss   23:02   0:00 postgres: stats collector process
ubuntu   21808  0.0  0.1  12948  1092 pts/0    S+   23:02   0:00 grep --color=auto -i postgres

起動した!

ブラウザからアクセスすると。

welcome_redash.png

表示された!

Admin ユーザを登録すればとりあえず使えるようになります。

このままだとメール設定などが出来ていなので、必要であればヘルプ

https://redash.io/help/

などを参考にします。

ちなみに

最初に試した時は、次のような en_US.UTF-8 ロケールが無いというエラーが出ていました。

2017-10-09 08:38:28 UTC [2801-1] redash@redash FATAL:  database locale is incompatible with operating system
2017-10-09 08:38:28 UTC [2801-2] redash@redash DETAIL:  The database was initialized with LC_COLLATE "en_US.UTF-8",  which is not recognized by setlocale().
2017-10-09 08:38:28 UTC [2801-3] redash@redash HINT:  Recreate the database with another locale or install the missing locale.

確認すると確かに無い。

$ locale -a
C
C.UTF-8  # en_US.utf8 がない
POSIX

そのため、次のようにして en_US.UTF-8 をインストールして起動しました。

$ sudo locale-gen en_US.UTF-8
$ locale -a
C
C.UTF-8
en_US.utf8
POSIX

この記事を書くために最初から通して試してみたら en_US.utf8 ローカルが入っていて、再現しませんでした。

Issue を立てたのですが、勘違いだった可能性が高いのでそっと閉じました。

続きを読む

AWSの用語と解説

AWS(Amazon Web Services)General_AWScloud.png

インフラ系のクラウドサービスを提供しているAWSは2006年3月から始まり、現在10周年。
アメリカでは政府機関が使っているほど高いセキュリティ

サービスや機能は800個以上あり、もはや中の人も何がいつリリースされたかわからないらしい

Region(リージョン)

AWSは世界中のデータセンターのサーバーで実行されており、サービスを開始する時はリージョンを選択する
リージョンは以下の通り

リージョン
米国東部(バージニア北部) us-east-1
米国西部(オレゴン) us-west-2
米国西部(北カリフォルニア) us-west-1
欧州(アイルランド) eu-west-1
欧州(フランクフルト) eu-central-1
アジアパシフィック (シンガポール) ap-southeast-1
アジアパシフィック(東京) ap-northeast-1
アジアパシフィック (ソウル) ap-northeast-2
アジアパシフィック(シドニー) ap-southeast-2
南米 (サンパウロ) sa-east-1
中国(北京) cn-north-1

アジアパシフィックを選んでおけば問題ないが、特定のリージョンにしかないマイナーなサービスがあったりするので注意が必要

AZ(アベイラビリティゾーン)

リージョン内のデータセンターのことで、
東京リージョンだと ap-northeast-1a ap-northeast-1b ap-northeast-1c のAZがある

EC2(Elastic Compute Cloud) Compute_AmazonEC2.png

仮想サーバ

ブラウザ上で何回かクリックするだけで、簡単にインスタンスが立ち上がる
利用料金はインスタンスタイプや性能にもよるが、最低スペックで 744円/月 くらい?

RDS(Relational Database Service) Database_AmazonRDS.png

リレーショナルデータベース

Amazon Aurora  Oracle  Microsoft SQL Server  PostgreSQL  MySQL  MariaDB
からデータベースエンジンを選択可能

中でも MySQL5.6互換がある Amazon Auroraは1分あたり600万回のインサート、3000万件のセレクトが可能らしい。
下記のサイトによれば、DB性能向上が期待できそう?
http://dev.classmethod.jp/cloud/aws/wordpressdb-migrate-aurora/

Redshift  Database_AmazonRedshift.png

データウェアハウス

2TBから最大1.6PBまでスケール可能でログなどのビッグデータを保存するのによく使用される
カラムナー(列指向)と呼ばれるデータ格納方式が特徴

Redshift は、PostgreSQL 8.0.2 に基づいている。
なので、PostgreSQL 9系で追加されたクエリが使えなかったりする。

ElastiCache  Database_AmazonElasticCache.png

KVSのキャッシュサービス

Memcached・Redis から選べる
Elastic Cacheではなく ElastiCache(エラスティキャッシュ) という名前なので注意が必要

S3(Simple Storage Service) Storage_AmazonS3_bucket.png

オンラインストレージサービス

bucket(フォルダ)
object(ファイル)
という名称がある

1B ~ 5TBまでのオブジェクトを書き込み・読み込み・削除が可能
バケットに容量制限はない

・SLAは99.99%
・静的webサイトのホスティングが可能

CloudFront NetworkingContentDelivery_AmazonCloudFront.png

コンテンツデリバリネットワーク(CDN)

CDNはAkamaiなどがあるが、それに比べると割高

VPC(Virtual Private Cloud) General_virtualprivatecloud.png

仮想プライベートクラウド

Amazon VPCは、AWS上に利用者が占有可能な仮想プライベートネットワークを構築するためのサービス。
このVPCの内部にIPサブネットを作成し、その中に仮想サーバーの「EC2」やデータベースサーバーの「RDS」といったAWSのリソースを配置する。

・ユーザ側で使いたいIP空間(VPC) を作成
・VPCにユーザがサブネットを切ることができる
・サブネット単位で アクセスリストが設定できる

Route53 NetworkingContentDelivery_AmazonRoute53.png

DNSサーバ

DNSは通常マスターとスレーブ構成にすることが多く、2台で構成する場合が多いが
Route53では、4つのネームサーバーで構成され、全世界にDNSサーバーを設置しているので高可用性である
米国:20   欧州:16  アジア:12  オーストラリア:2   南米:2

・SLA100% (ほんとに?)
・DNSラウンドロビンでの負荷分散が可能
料金はかなり安い。

ホストゾーン
0.50 USD(ホストゾーンごと)/月 - 最初の25のホストゾーン
0.10 USD(ホストゾーンごと)/月 - それ以上のホストゾーン

標準的クエリ
0.400 USD(100 万クエリごと) - 最初の 10 億クエリ/月
0.200 USD(100 万クエリごと) - 10 億クエリ以上/月

1つのホストゾーンで、10億クエリ行かなければ、月1ドルかからない。

IAM(Identity and Access Management) SecurityIdentityCompliance_IAM.png

ユーザーの権限を管理できるサービス

ポリシーと呼ばれる権限をユーザーにアタッチすることで、該当ユーザーの操作できる範囲を限ることができる

ポリシーは自由に設定可能で、管理者が細かく設定可能で
例えば、とある管理者が s3-readonly-userを作成し S3の閲覧だけを許可するポリシーを作成してアタッチ。など

随時追加中…

続きを読む

aws: both ssh and mysql connection hang

エラー内容

ssh -i ~/.ssh/鍵名.pem ec2-user@IPmysql -h エンドポイント -P 3306 -u root -pの二つのコマンドを打っても何も返答がない状態。少し待っているとERROR 2003 (HY000): Can't connect to MySQL server on [endpoint] (60)というメッセージが。

解決策

EC2 -> security groupsにあるinboundに最新のmy IP addressに更新してあげるだけ。

続きを読む

AWSのMySQLクライアントが起動しない時の対処法

AWSのAmazon LinuxにMySQLいれてログインしようとした時にCan't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'ってエラーが出た。

socketファイルがないのと、権限周りが原因だったぽいのでそこらへんを修正して再起動する。

手順

エラー内容を見ると/var/lib/mysql/mysql.sockらへんが怪しい
cdで確認をしに行くと/var/lib配下にmysqlフォルダすらなかった

// ルート権限になっておく
$ sudo -i

// mysqlフォルダ作成
$ mkdir /var/lib/mysql

// mysql.sockファイルを作成
$ touch /var/lib/mysql/mysql.sock

// 権限をmysqlに変更
$ chown -R mysql:mysql /var/lib/mysql

// mysqlを再起動
$ service mysqld restart

// ログインしてみる
$ mysql -u root

で動きました。

続きを読む

何となくEC2(Amazone Linux)にMariaDBを入れてSpiderで水平Shardingしてみた

雑記と言うか備忘録と言うか、そんな感じでEC2にMariaDBの10.0系をyum経由で導入し、水平Sharding環境を構築しました

#RDS使えばいいんですけど、高いんですよね。それなりにお試しでならEC2を3台構成にすれば水平Shardingは遊べますし。

※構成例

MariaDB:USER / PASS = root / Spider
SERVER:三台 Spiderサーバ:1台 DATANODE:2台
※ IPは仮として
SpiderNode:192.168.10.10
Datanode1:192.168.10.11
Datanode2:192.168.10.12
としますので読み替えてご活用下さい
DB:example_db
table:books
使うエンジン:Spider&Innodb

下準備

yum -y update && shutdown -r now

1.MariaDBインストール
●MariaDBのレポジトリ追加

echo '# MariaDB 10.0 CentOS repository list - created 2014-04-02 07:21 UTC' >> /etc/yum.repos.d/mariadb.repo
echo '# http://mariadb.org/mariadb/repositories/' >> /etc/yum.repos.d/mariadb.repo
echo '[mariadb]' >> /etc/yum.repos.d/mariadb.repo
echo 'name = MariaDB' >> /etc/yum.repos.d/mariadb.repo
echo 'baseurl = http://yum.mariadb.org/10.0/centos6-amd64' >> /etc/yum.repos.d/mariadb.repo
echo 'gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB' >> /etc/yum.repos.d/mariadb.repo
echo 'gpgcheck=1' >> /etc/yum.repos.d/mariadb.repo
echo 'enable=1' >> /etc/yum.repos.d/mariadb.repo

●MariaDBの起動

yum install -y MariaDB-server MariaDB-client

●MariaDB起動

chkconfig mysql on
/etc/rc.d/init.d/mysql start

2.MariaDBの初期設定
●設定適用(対象:全サーバ)


/usr/bin/mysqladmin -u root password 'Spider'
mysql -u 'root' --password='Spider' -e 'CREATE DATABASE example_db;GRANT ALL PRIVILEGES ON *.* TO "root"@"192.168.10.%" IDENTIFIED BY "Spider";FLUSH PRIVILEGES;'

●設定適用(対象:Spiderサーバのみ)
▼MariaDBへのspiderエンジンのインストール

mysql -u 'root' --password='Spider' -e 'source /usr/share/mysql/install_spider.sql'

確認は mysql -u 'root' --password='Spider' -e 'show engines;' にて

●データノードのspiderサーバへの登録(対象:Spiderサーバのみ)

mysql -u 'root' --password='Spider' -e 'CREATE SERVER db1 FOREIGN DATA WRAPPER mysql OPTIONS (USER "root", PASSWORD "Spider", HOST "192.168.10.11", PORT 3306);'
mysql -u 'root' --password='Spider' -e 'CREATE SERVER db2 FOREIGN DATA WRAPPER mysql OPTIONS (USER "root", PASSWORD "Spider", HOST "192.168.10.12", PORT 3306);'

こちらも確認は mysql -u 'root' --password='Spider' -e 'select * from servers;' mysql にて

●スキーマの登録(対象:SpiderNodeのみ)

    CREATE TABLE books
    (
        id int AUTO_INCREMENT NOT NULL,
        name VARCHAR(255) NOT NULL,
        price int(11) NOT NULL default 0,
        created_at DATETIME NOT NULL,
        updated_at DATETIME,
        lock_version int(11) NOT NULL default 0,
        PRIMARY KEY (id)
    ) ENGINE = SPIDER DEFAULT CHARSET=utf8
    PARTITION BY HASH(id) (
      PARTITION p1 comment 'server "db1", table "books"',
      PARTITION p2 comment 'server "db2", table "books"'
    );

●スキーマの登録(対象:db1,db2)

    CREATE TABLE books
    (
        id int AUTO_INCREMENT NOT NULL,
        name VARCHAR(255) NOT NULL,
        price int(11) NOT NULL default 0,
        created_at DATETIME NOT NULL,
        updated_at DATETIME,
        lock_version int(11) NOT NULL default 0,
        PRIMARY KEY (id)
    ) ENGINE = SPIDER DEFAULT CHARSET=utf8
    ;

●Spiderサーバの「my.cnf」設定変更(対象:Spiderサーバのみ)

echo '[mysqld]' >> /etc/my.cnf
echo 'spider_internal_sql_log_off = ON' >> /etc/my.cnf
echo 'spider_remote_sql_log_off   = 1' >> /etc/my.cnf

●Spiderサーバの「my.cnf」設定変更(対象:Spiderサーバのみ)

/etc/rc.d/init.d/mysql restart

お仕舞。

テスト:以下10行のクエリを発行する
※クエリの発行はSpiderサーバのexample_dbで実施

    INSERT INTO books(name, price, created_at) VALUES ('3日で分かるJava', 2500, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('3日で分かるRuby', 2300, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('独習仮想化',      5000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Java入門',        2000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('入門Ruby',        2800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Effective Ruby',  4200, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('すごいRuby',      5800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('Ruby徹底入門',    3000, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('RubyからJavaへ',  1800, NOW());
    INSERT INTO books(name, price, created_at) VALUES ('クラウド大全',    6000, NOW());

●Spiderノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  1 | 3日で分かるJava      |  2500 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  2 | 3日で分かるRuby      |  2300 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  3 | 独習仮想化           |  5000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  4 | Java入門             |  2000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  5 | 入門Ruby             |  2800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  6 | Effective Ruby       |  4200 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  7 | すごいRuby           |  5800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  8 | Ruby徹底入門         |  3000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  9 | RubyからJavaへ       |  1800 | 2017-09-13 00:06:51 | NULL       |            0 |
  | 10 | クラウド大全         |  6000 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  10 rows in set (0.01 sec

●db1ノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  2 | 3日で分かるRuby      |  2300 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  4 | Java入門             |  2000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  6 | Effective Ruby       |  4200 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  8 | Ruby徹底入門         |  3000 | 2017-09-13 00:06:51 | NULL       |            0 |
  | 10 | クラウド大全         |  6000 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  5 rows in set (0.00 sec)

●db2ノード上で全件Select

  MariaDB [example_db]> select * from books order by id;
  +----+----------------------+-------+---------------------+------------+--------------+
  | id | name                 | price | created_at          | updated_at | lock_version |
  +----+----------------------+-------+---------------------+------------+--------------+
  |  1 | 3日で分かるJava      |  2500 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  3 | 独習仮想化           |  5000 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  5 | 入門Ruby             |  2800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  7 | すごいRuby           |  5800 | 2017-09-13 00:06:51 | NULL       |            0 |
  |  9 | RubyからJavaへ       |  1800 | 2017-09-13 00:06:51 | NULL       |            0 |
  +----+----------------------+-------+---------------------+------------+--------------+
  5 rows in set (0.00 sec)

出来てますね

続きを読む

CloudFront に SSL 証明書を導入する際のポイントまとめ

CloudFront に SSL を入れる際に気をつける項目のまとめです。

2017年9月時点では、特に S3 との連携で大きな制約があり、将来的には改善されていくのではと思います。現在の状況を確認してください。

SNI か専用 IP か

まず、ブラウザと CloudFront 間の通信で、SNI (Server Name Indication) が使えるかどうか検討します。

ガラケーやWindowsXP の IE は SNI に対応していません。これらの古い環境でサイトが見えなくても構わないかどうかを確認します。

SNI 非対応のブラウザに対応するには、専用 IP を使う必要があります。専用 IP は $600/月かかります。

専用 IP 独自 SSL の料金体系はシンプルです。SSL 証明書ごとの専用 IP アドレスに伴う追加コストのため、CloudFront ディストリビューションに関連付けられた各独自 SSL 証明書ごとに、毎月 600 USD をお支払いいただきます。

SNI は無料です。

SNI 独自 SSL 証明書管理には、前払い料金や最低月額料金は不要です。お客様にお支払いいただくのは、Amazon CloudFront のデータ転送と HTTPS リクエストに対する通常料金のみです。

証明書の取得について

どのドメインでどんな証明書が必要か、証明書は有料か無料か、を確認します。

証明書の取得方法には、以下の選択肢があります。

  1. 代理店などから購入する (有料)
  2. ACM (AWS Certificate Manager) を使う (無料、ただし EC2 にはインストール不可)
  3. Let’s Encrypt を使う (無料、ただし Amazon Linux 未対応)
  4. etc.

CloudFront – オリジン間を HTTPS にする

通常は、ビューア – CloudFront 間だけでなく、 CloudFront – オリジン間も通信を暗号化します。(表向き暗号化している風を装って、裏を平文で流して良いのかは微妙な問題です…)

CloudFront とオリジンの両方で、証明書が必要になる可能性があります。

オリジンが EC2 の場合、 ELB を入れるか検討する

ACM で取得した証明書を EC2 にインストールすることはできません。

https://aws.amazon.com/jp/certificate-manager/faqs/

Q: ACM により提供された証明書を使用できるのは、AWS のどのサービスですか?

ACM は AWS の以下のサービスと連携できます。
• Elastic Load Balancing – Elastic Load Balancing のドキュメントを参照してください。
• Amazon CloudFront – CloudFront のドキュメントを参照してください。
• Amazon API Gateway – API Gateway のドキュメントを参照してください。
• AWS Elastic Beanstalk – AWS Elastic Beanstalk のドキュメントを参照してください。

https://aws.amazon.com/jp/certificate-manager/faqs/

Q: Amazon EC2 インスタンスや自分のサーバーに証明書を使用できますか?

いいえ。現在のところ、ACM により提供される証明書は、AWS の特定のサービスのみで使用できます。

EC2 で ACM を使いたい場合は、CloudFront – ELB – EC2 の構成にします。証明書が無料になる代わりに、ELB の費用が発生します。

S3 に証明書を入れる必要はない

  • Amazon S3 は SSL/TLS 証明書を提供するため、その必要はありません。

この日本語訳はいまいち何を言っているのかわかりませんが、、

  • Amazon S3 provides the SSL/TLS certificate, so you don’t have to.

「S3 が証明書を提供するので、あなたが(提供する)必要はない」という意味です。

今のところ、S3 に独自の証明書を入れる手段はありません。オリジンに S3 の CNAME を指定することもできません。

http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html

以下の形式を使用してバケットを指定しないでください。

  • Amazon S3 のパススタイル (s3.amazonaws.com/bucket-name)
  • Amazon S3 の CNAME (ある場合)

CloudFront – S3 間の HTTPS には大きな制約がある

S3 をウェブサイトエンドポイントとしてオリジンに設定すると、HTTPS が使えなくなります。

Amazon S3 バケットがウェブサイトエンドポイントとして構成されている場合、オリジンとの通信に HTTPS を使用するように CloudFront を構成することはできません。Amazon S3 はその構成で HTTPS 接続をサポートしていないためです。

ウェブサイトエンドポイントは、

http://example-bucket.s3-website-ap-northeast-1.amazonaws.com/

のような URL での配信方法です。「静的ウェブサイトホスティング」の設定です。この URL をオリジンに設定すると、CloudFront – S3 間で HTTPS が使えません。

ウェブサイトエンドポイントは、以下の機能で必要です。

  • /foo/bar//foo/bar/index.html を返す
  • 独自のエラー画面を表示する
  • リクエストを全てリダイレクトする (例えば、www なしドメインを www ありにリダイレクトする)

ウェブサイトエンドポイントを使わず、S3オリジンで設定すると、サイトのトップ / (Default Root Object) 以外、index.html が見えるようにはなりません。

CloudFrontではDefault Root Objectという設定項目でIndex Documentを指定することができますが、これはRootへのアクセス時(例:http://example.com/) に対してのみ有効であり、サブディレクトリ(例:http://example.com/foo/) に対しては有効になりません。そのため、階層構造のあるWEBサイトをホストする際には不向きだと思われます。

ウェブサイトエンドポイントを使う場合は、裏が暗号化されていなくてもいいのか、バレなければいいのか、を検討しなければならなくなります。。ちなみに、オリジンが S3 であることは Server レスポンスヘッダで判別できます。S3 がウェブサイトエンドポイントかどうかは、/foo/bar/ の挙動で判別できます。

また、ウェブサイトエンドポイントにすると、Origin Access Identity を使うことができなくなります。バケット名を推測して、S3 に直接アクセスされる可能性があります。

ワイルドカード証明書の取得を検討する

CloudFront にもオリジンにも、ワイルドカード証明書が使えます。例えば、以下のような組み合わせが考えられます。

  • CloudFront *.example.com → Origin *.example.com

    • 1つのワイルドカード証明書を使う
  • CloudFront www.example.com → Origin www.example.com
    • 1つの非ワイルドカードの証明書を使う
    • CloudFront から Host ヘッダを転送する場合のみ、オリジンの証明書で Host ヘッダのドメイン名が使える
  • CloudFront www.example.com → Origin *.example.com
    • 表は高い非ワイルドカード証明書を使い、裏は安いワイルドカード証明書で済ませる
  • CloudFront www.example.com → Origin origin.example.com
    • 表と裏と、別々に非ワイルドカード証明書を購入する
    • または、証明書に別名 (SAN) を設定する
  • CloudFront www.example.com → Origin origin.example.jp
    • オリジンは .example.com でなくてもよい。DNS の自由が効かない場合、裏は Route53 で独自のドメインを取得すると便利

詳細は以下のドキュメントを参照してください。

カスタムオリジンを使用する場合、オリジンの SSL/TLS 証明書の共通名フィールドにドメイン名が含まれ、さらにサブジェクト代替名フィールドにもドメイン名がいくつか含まれることがあります。 (CloudFront は証明書ドメイン名にワイルドカード文字を使用できます)。

証明書のドメイン名のうち 1 つは、オリジンドメイン名に指定したドメイン名と一致する必要があります。ドメイン名が一致しない場合、CloudFront は、ビューワーに HTTP ステータスコード 502 (Bad Gateway) を返します。

内部の証明書を安くあげる

エンドユーザの目に触れないオリジン用の証明書にまでコストをかける必要があるかどうかを検討します。安価な証明書でも十分かもしれません。

オリジンが ELB なら ACM が使えます。

DNS を操作する権限があるか確認する

表側の DNS を操作する権限がない場合、オリジンに Route53 で取得した独自ドメインを設定すると、自由度が上がります。

オリジンに独自のドメインを使う場合は、その証明書が必要です。

リリース前の確認方法を検討する

リリース前に CloudFront に別のドメインを割り当てて確認する場合は、ワイルドカード証明書があったほうが便利です。

例えば https://staging.example.com/ のような URL を CloudFront に設定します。

Naked ドメインを使うか確認する

https://example.com/ のような Naked ドメイン (Zone Apex) を使うかどうか確認します。

Route53 を使わずに、Naked ドメインを CloudFront や ELB や S3 に割り当てることはできません。CloudFront を通さず、例えば EC2 で直接リクエストを受ける必要が出てきます。

Naked ドメインへのリクエストを EC2 で受ける場合

Naked ドメインへのリクエストを EC2 で直接受ける場合は、ACM が使えません。ACM で取得した証明書は EC2 にインストールできないからです。

証明書の購入が必要になる可能性があります。

Naked ドメインの DNS に Route53 を使っている場合

Route53 でエイリアスを使うと、CloudFront に Naked ドメイン (Zone Apex) を設定できます。

この場合は、Naked ドメインの証明書取得に ACM が使えます。

ワイルドカード証明書を使う場合、ワイルドカードに Naked ドメインは含まれないので、*.example.com に別名で example.com を設定します。

既存の証明書がある場合は SAN を確認する


既に証明書があって、足りない証明書を購入する場合。

既存の証明書の別名 (SAN) が何になっているのかを確認します。特に Naked ドメインなど、必要なドメインが SAN に設定されているかもしれません。

証明書をインポートするリージョンに注意する

CloudFront の証明書は、バージニア北部リージョンに入れる必要があります。

ACM で証明書を取得する場合にも、バージニア北部リージョンを選ぶ必要があります。

ビューワーと CloudFront との間で HTTPS を必須にするには、証明書をリクエストまたはインポートする前に AWS リージョンを 米国東部(バージニア北部) に変更する必要があります。

CloudFront とオリジンとの間で HTTPS を必須にする場合、オリジンとして ELB ロードバランサーを使用しているなら、任意のリージョンで証明書をリクエストまたはインポートできます。

例えば、オリジンが東京の ELB だとしたら、東京とバージニア北部リージョンの両方の ACM で証明書を取得 (またはインポート) します。

ACM の本人確認について

ACM で証明書を取得する場合は、本人確認 (取得意思の確認) メールが、証明書のドメイン宛てに送信されます。

Whois 情報の更新状態をチェックする

本人確認メールは、公開されている Whois の連絡先アドレスにも送信されます。

Whois に正しいアドレスが公開されている場合は、そのアドレスでメールを受け取るのが簡単です。

SES で ACM の認証を通す

ドキュメントの通りにやれば、ACM の確認メールを SES で受信するのは、さほど難しくありません。

SES の受信設定を行い、DNS に MX レコードを設定、受信したメールを SNS トピックで受け取るようにして、そのトピックに任意のメールアドレスをサブスクライブします。

ルールセットがアクティブになっているかどうかに注意する

SES のメール受信設定には、「ルールセット」というバージョン管理の仕組みがあります。

現行のルールセットをコピーし、編集し、アクティブなルールセットを入れ替える、という手順で設定を変更します。Inactive Rule Sets に新しいルールセットを足しても何も起こりません。

続きを読む

AWSでServerlessの環境をCIするための選択肢を調べたメモ

利用するサービスはAWSに限定するとした場合に開発・テスト・デプロイを継続するための選択肢をいくつか調べてみました。

開発したいものは、「API Gateway – Lambda – DynamoDB」で構成されるWebサービスとします。

正直なところ、対象像を少し絞らないと選択肢が多すぎて好みの問題になりそうなので・・・

注意

調査用のメモです。

実際に全ての選択肢で開発をしてみたわけではなく、入門記事やドキュメントを少しみた程度で判断しています。

そのため正確性に欠ける内容となっている可能性が高いことをご了承ください。

共通点

開発ツールで対応していない部分についてのデプロイについては、AWS CLIで対応していくことになるでしょう。

LocalStack

モックサービスの対応数にまず驚いた。

https://github.com/localstack/localstack

LocalStack はローカルでAWSのサービスのモックを動かしてしまうというツールです。
DockerコンテナでAWS各種サービスを一気に立ち上げることができるので、ローカル環境で開発を完結させることが出来ます。

これ自体にはAWSを管理する機能はなく、Lambdaをローカル環境で開発してテストするときに、ローカルで同時にAPI Gateway + DynamoDBを動かしたいという場合に必要となりそうです。
DynamoDB自身はAmazonからDynamoDB Localが提供されているので、どちらを使うかは検証が必要でしょう。

起動コマンドも簡単で、一発で全て立ち上げることが出来ます。

docker-compose up

macの場合は、$TMPDIRにシンボリックリンクがある場合、少しコマンドを変える必要があるようです。

TMPDIR=/private$TMPDIR docker-compose up

DynamoDB Local

ローカル開発用のDynamoDB。
ほとんどのLambda開発ツールがAPI Gatewayもサポートしていることから、DynamoDBを接続するローカル環境ではLocalStackよりはこちらを使用することになるのではないかと。公式提供でもあるし。

ダウンロードとインストールガイドはこちら

aws-sam-local

SAM は Serverless Application Modelのことで、aws-sam-localはAmazon公式がサポートしているローカル開発環境です。今はまだbetaですが、近いうちに良くなりそうです。

https://github.com/awslabs/aws-sam-local

AWS Blogで利用例が紹介されていて、DynamoDB Localを使う場合についても少し触れられています。
https://aws.amazon.com/jp/blogs/news/new-aws-sam-local-beta-build-and-test-serverless-applications-locally/

作成したLambda FunctionをローカルDockerコンテナで実行したり、現時点ではPythonとNode.jsはデバッグ出来るようです。(自分で試したところ、上手くいかなかった)

また、Lambda関数を単純に実行するだけではなく、ローカルのAPI Gatewayを通して実行を確認できます。

PostManで簡単にAPIの動作検証が行えたり、実際のHTTPアクセスの形でLambda関数の検証がローカルで行えます。
また、実行時間やメモリ消費量が表示されるため、AWSにデプロイする前に関数の効率化が出来ます。

Serverless Framework

現状で一番正解に近いと思います。

https://github.com/serverless/serverless

こちらのQitta記事こっちのQiita記事が参考になりそうです。
DynamoDB Localと連携するためのプラグインが存在し、serverless.ymlファイルにAWS上での構成を記載していき、そのままAWSにデプロイ出来るようです。

Apex

Go言語でLambdaが書ける!!!

純粋にLambdaの開発だけで見ればとても良さそうです。
ただし、ローカル実行はサポートしておらず、AWSリソースの操作もLambdaに限定されています。
その辺りは、Terraformで補う考えのようです。

公式

https://github.com/apex/apex

chalice

Python用のマイクロサービスフレームワークです。

https://github.com/aws/chalice

次の様なコードで、APIを定義できます。

chalice
@app.route('/resource/{value}', methods=['PUT'])
def put_test(value):
    return {"value": value}

デプロイでAPI Gateway, Lambdaに反映されるため、コードの見通しが良くなりそうです。
IAM Rolesなどは自動生成される様なので、とにかく簡単にコードを書いて、すぐデプロイということが出来そうです。

インストールからコード記述、デプロイまでの操作がHelloworldならこんなに簡単に出来るようです。

$ pip install chalice
$ chalice new-project helloworld && cd helloworld
$ cat app.py

from chalice import Chalice

app = Chalice(app_name="helloworld")

@app.route("/")
def index():
    return {"hello": "world"}

$ chalice deploy
...
https://endpoint/dev

$ curl https://endpoint/api
{"hello": "world"}

Zappa

こちらも、とにかく簡単にPythonで作成した関数をAWSにデプロイ出来ることがウリのようです。

https://github.com/Miserlou/Zappa

gifアニメーションで実演が付いています。(README.mdから引用しました)
README.md

Zappa Demo Gif

REST APIを作成する以外にも、AWS Eventsに対応するものや、Asynchronous Task Executionといって、別のLamdba関数を非同期に呼び出すことが出来る機能を持っているようです。
というか、chaliceに比べると非常に多彩。

また、ZappaはWSGI(Web Server Gateway Interface)をサポートしているので、他のアプリケーションサーバーにデプロイすることも可能です。

chalice vs Zappa

こちらに比較記事がありました。

続きを読む

【HashiCorp Vault】Dynamic Secrets (Secret Backend) の Lease 機能を試す

はじめに

Dynamic Secrets (Secret Backend) の Lease 機能について動作を確認しましたので備忘録として記録しておきます。

やったこと

  1. Vaultが作成したAWSユーザの有効期限(TTL)を確認する
  2. Lease機能を利用して有効期限(TTL)を設定する
  3. Lease機能を利用してAWSユーザの有効期限(TTL)を延長する

HashiCorp Vaultとは?

HashiCorpが提供している機密情報の管理ツールです。

Dynamic Secrets (Secret Backend) とは

VaultにAWSやDatabaseなどのアカウントを管理させる機能です。

この機能を利用することでVaultを通じてAWSなどのユーザ作成、削除を実施できるようになります。
有効期間が経過したユーザについてはVaultが自動で削除を行ってくれます。

参考

公式サイト

Vault by HashiCorp

ドキュメント

AWS Secret Backend – HTTP API – Vault by HashiCorp
/sys/leases – HTTP API – Vault by HashiCorp

過去の投稿

HashiCorp Vault の Dynamic Secrets (Secret Backend) を試す – Qiita


事前準備

VaultをDevモードで起動

$ vault server -dev

...
    export VAULT_ADDR='http://127.0.0.1:8200'
...
Root Token: dae8c23c-3749-0286-abc5-fbdf57b634f1

環境変数の設定

$ export VAULT_ADDR='http://127.0.0.1:8200'
$ export VAULT_TOKEN='dae8c23c-3749-0286-abc5-fbdf57b634f1'

AWS Backendをマウント

$ vault mount aws
Successfully mounted 'aws' at 'aws'!

AWSのTokenを設定

$ vault write aws/config/root 
    access_key=AKIAIFOCRMPWZMVED74Q 
    secret_key=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
Success! Data written to: aws/config/root

ポリシーを設定

policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1426528957000",
      "Effect": "Allow",
      "Action": [
        "ec2:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
$ vault write aws/roles/deploy policy=@policy.json
Success! Data written to: aws/roles/deploy

1. Vaultが作成したAWSユーザの有効期限(TTL)を確認する

初期状態でLease設定や有効期限(TTL)を確認します。

Lease設定を確認する

Lease設定を確認しても、未設定のため取得できません。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/config/lease

{"errors":[]}

VaultにAWSユーザを作成させる

この状態(Lease未設定)でAWSユーザを作成せた場合、lease_duration": 2764800となっています。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/creds/deploy

{
  "request_id": "333374cd-1d0e-6015-adc9-85656d78a1c9",
  "lease_id": "aws/creds/deploy/6ceb69a0-249a-e65e-ff9a-9996a85bed45",
  "renewable": true,
  "lease_duration": 2764800,
  "data": {
    "access_key": "AKIAJIFBBLEAXHS4NQNQ",
    "secret_key": "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",
    "security_token": null
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Lease設定を確認

AWSユーザのLease設定を確認すると、

  • “issue_time” : “2017-10-08T17:30:30.873476458+09:00”
  • “expire_time”: “2017-11-09T17:30:30.873476739+09:00”

となっており、有効期限(TTL)が 2764800秒 = 32日間 であることがわかりました。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/6ceb69a0-249a-e65e-ff9a-9996a85bed45" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "21234bd6-e722-8993-22f7-175f2c4d8dc6",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-11-09T17:30:30.873476739+09:00",
    "id": "aws/creds/deploy/6ceb69a0-249a-e65e-ff9a-9996a85bed45",
    "issue_time": "2017-10-08T17:30:30.873476458+09:00",
    "last_renewal": null,
    "renewable": true,
    "ttl": 2764126
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

2. Lease機能を利用して有効期限(TTL)を設定する

初期設定では有効期限(TTL)が長いので、短い有効期限(TTL)を設定して、AWSユーザが実際に削除されるのか確認したいと思います。

Lease設定

lease30mlease_max12hに設定します。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request POST 
    --data '{ "lease": "30m",  "lease_max": "12h" }' 
    $VAULT_ADDR/v1/aws/config/lease

Lease設定を確認すると、lease, lease_maxが指定した値になっています。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/config/lease 

{
  "request_id": "3b09ce08-b6b6-848f-3622-f3711d1a7d26",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "lease": "30m0s",
    "lease_max": "12h0m0s"
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

AWSユーザ作成

Lease設定後にAWSユーザを作成させると、lease_duration": 1800となっています。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/creds/deploy

{
  "request_id": "5413657e-78e4-4128-e7c0-ed61c6158bc8",
  "lease_id": "aws/creds/deploy/5d7f8036-762b-8fcb-fcea-7bb7f1842f13",
  "renewable": true,
  "lease_duration": 1800,
  "data": {
    "access_key": "AKIAJCVNQTVWYDKAEIMA",
    "secret_key": "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",
    "security_token": null
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

AWSユーザのLease設定を確認すると、

  • “issue_time” : “2017-10-08T17:52:06.741853365+09:00”
  • “expire_time”: “2017-10-08T18:22:06.741853771+09:00”

となっており、有効期限(TTL)が1800秒 = 30分となってることがわかります。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/5d7f8036-762b-8fcb-fcea-7bb7f1842f13" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "e528ba92-53f0-cee0-973d-069612a24207",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-08T18:22:06.741853771+09:00",
    "id": "aws/creds/deploy/5d7f8036-762b-8fcb-fcea-7bb7f1842f13",
    "issue_time": "2017-10-08T17:52:06.741853365+09:00",
    "last_renewal": null,
    "renewable": true,
    "ttl": 1646
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

AWSユーザの削除確認

AWSの管理コンソールを確認したところ、expire_timeに到達したタイミングでVaultが作成したAWSユーザ(vault-root-deploy-1507452723-604)が削除されました。

expire_time到達前
vault_lease01.png

expire_time到達後
vault_lease02.png

3. Lease機能を利用してAWSユーザの有効期限(TTL)を延長する

Lease機能には有効期限(TTL)を延長(renew)させる機能があるので、こちらの動作も確認してみます。

AWSユーザ作成

前回と同様にVaultにAWSユーザを作成させます。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    $VAULT_ADDR/v1/aws/creds/deploy

{
  "request_id": "15e22c37-ff2f-2277-6bc5-0834f4dd4eba",
  "lease_id": "aws/creds/deploy/f822cb89-98d6-0cd5-05e7-69020bda05b9",
  "renewable": true,
  "lease_duration": 1800,
  "data": {
    "access_key": "AKIAIGFBKDIZ6VU7UOUA",
    "secret_key": "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",
    "security_token": null
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

前回と同様にAWSユーザの有効期限(TTL)は30分間です。

  • “issue_time” : “2017-10-08T18:34:39.368521987+09:00”
  • “expire_time”: “2017-10-08T19:04:39.368522185+09:00”
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/f822cb89-98d6-0cd5-05e7-69020bda05b9" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "f1848a4a-7f3f-8e0c-90cf-7024dd242c35",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-08T19:04:39.368522185+09:00",
    "id": "aws/creds/deploy/f822cb89-98d6-0cd5-05e7-69020bda05b9",
    "issue_time": "2017-10-08T18:34:39.368521987+09:00",
    "last_renewal": null,
    "renewable": true,
    "ttl": 1753
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

有効期限(TTL)の延長

Lease機能を利用してAWSユーザの有効期限(TTL)を3600秒(30分)延長させます。

$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9", "increment": 3600 }' 
    $VAULT_ADDR/v1/sys/leases/renew

{
  "request_id": "86f059ec-1680-c886-2ade-3e15635ed38e",
  "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
  "renewable": true,
  "lease_duration": 3600,
  "data": null,
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

Lease設定を確認するとexpire_timeが更新されてます。

issue_timeから+3600秒(30分)されるわけではなく、延長(renew)コマンドを実行した時点(last_renewal)から3600秒(30分)延長されるようです。

延長前

  • “issue_time” : “2017-10-08T18:34:39.368521987+09:00”
  • “expire_time”: “2017-10-08T19:04:39.368522185+09:00”

延長後

  • “issue_time” : “2017-10-08T18:27:57.65077363+09:00”
  • “last_renewal”: “2017-10-08T18:35:52.918241764+09:00”
  • “expire_time” : “2017-10-08T19:35:52.918241648+09:00”
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9" }' 
    $VAULT_ADDR/v1/sys/leases/lookup
{
  "request_id": "f8e035a6-a72b-395a-aca0-641ed7c747ce",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-08T19:35:52.918241648+09:00",
    "id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
    "issue_time": "2017-10-08T18:27:57.65077363+09:00",
    "last_renewal": "2017-10-08T18:35:52.918241764+09:00",
    "renewable": true,
    "ttl": 3556
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

有効期限(TTL)の最大値を確認

lease_max12hに設定していたので12時間を超える有効期限(TTL)は設定できなくなっています。

有効期限(TTL)を 43200秒(1日)延長(renew)させても、expire_timeissue_timeの12時間後となっており、lease_maxを超えた有効期限(TTL)が設定できないことがわかります。

  • “issue_time” : “2017-10-08T18:27:57.65077363+09:00”
  • “last_renewal”: “2017-10-08T18:38:06.850822545+09:00”
  • “expire_time” : “2017-10-09T06:27:57.650782301+09:00”
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9", "increment": 43200 }' 
    $VAULT_ADDR/v1/sys/leases/renew

{
  "request_id": "9ed0ca65-18ee-2186-689a-1569f4f9e058",
  "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
  "renewable": true,
  "lease_duration": 42590,
  "data": null,
  "wrap_info": null,
  "warnings": null,
  "auth": null
}
$ curl 
    --header "X-Vault-Token: $VAULT_TOKEN" 
    --request PUT 
    --data '{ "lease_id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9" }' 
    $VAULT_ADDR/v1/sys/leases/lookup

{
  "request_id": "00d1c93f-431d-61f0-a116-b5d8a57af815",
  "lease_id": "",
  "renewable": false,
  "lease_duration": 0,
  "data": {
    "expire_time": "2017-10-09T06:27:57.650782301+09:00",
    "id": "aws/creds/deploy/28def48b-c990-d1d4-1691-610a8f2be0e9",
    "issue_time": "2017-10-08T18:27:57.65077363+09:00",
    "last_renewal": "2017-10-08T18:38:06.850822545+09:00",
    "renewable": true,
    "ttl": 42560
  },
  "wrap_info": null,
  "warnings": null,
  "auth": null
}

続きを読む