20210609のAWSに関する記事は25件です。

AWSを利用した、LEMP構成によるWordpressサイトの構築 〜Wordpressサイト構築編〜

作業手順 項目表 No タイトル 1 SSL証明書取得編 2 WEBサーバー構築編 3 ★Wordpressサイト構築編(今ここ) 4 Wordpressテーマ導入編 5 エラー対応編 はじめに LEMP構成のWordpressサイトを作成します。 PHPインストール PHP $ amazon-linux-extras install php7.4 -y #インストール $ php -v #インストール確認 PHP 7.4.19 (cli) (built: May 13 2021 22:36:40) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies $ systemctl start php-fpm #起動 $ systemctl enable php-fpm #自動起動設定 MariaDBのバージョンアップ Amazonlinux2には、デフォルトでMariaDBのバージョン5.5がインストールされていますが、10.5にバージョンアップさせます。 MariaDB $ sudo vi /etc/yum.repos.d/MariaDB.repo #5.5から10.5に変更 [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.5/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 $ yum install MariaDB-server MariaDB-client -y #インストール $ mysql -V #確認 mysql Ver 15.1 Distrib 10.5.10-MariaDB, for Linux (x86_64) using readline 5.1 $ systemctl start mariadb.service #起動 $ systemctl enable mariadb.service #自動起動設定 Nginx設定 Nginx $ cp -p /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.conf.org #www.confのバックアップ $ vi /etc/php-fpm.d/www.conf #以下設定を変更 user = nginx group = nginx pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 5 $ chown -R nginx:nginx /var/lib/php/session #権限をnginxに変更 $ cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.org #nginx.confのバックアップ $ mkdir -p /var/www/html #/var/www/htmlフォルダの作成 $ chown -R nginx:nginx /var/www/html #htmlディレクトリの権限をnginxに変更 $ vi /etc/nginx/nginx.conf #以下設定を変更 server { client_max_body_size 20M; listen 80 default_server; listen [::]:80 default_server; server_name _; root /var/www/html; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location ~ \.php$ { root cat ; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } $ nginx -t #nginx設定の構文チェック エラーがでなければOK nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful $ systemctl restart nginx.service #再起動 PHP設定 PHP $ vi /etc/php.ini #以下設定を変更 date.timezone = “Asia/Tokyo” expose_php = Off upload_max_filesize = 8M post_max_size = 16M memory_limit = 512M mbstring.language = Japanese mbstring.detect_order = auto mbstring.encoding_translation = Off mbstring.detect_order = UTF-8,SJIS,EUC-JP,JIS,ASCII $ systemctl restart php-fpm #再起動 $ netstat -al --protocol=unix |egrep "Proto|fpm" #nginxとphp-fpmのUNIXドメインソケット接続確認 Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 61433 /run/php-fpm/www.sock $ echo '<?php phpinfo(); ?>' | sudo tee /var/www/html/phpinfo.php #PHPの設定内容の表示確認 ブラウザからhttp://パブリックIP/phpinfo.phpもしくはhttp://パブリック IPv4 DNS/phpinfo.phpにアクセスし、PHPの設定内容が表示されることを確認する。 MariaDB設定 MariaDB $ mysql -uroot -p MariaDB [(none)]> create database test_db; #データベース作成 Query OK, 1 row affected (0.000 sec) MariaDB [(none)]> create user 'test-user'@'localhost' identified by 'test-password'; #ユーザー作成とPW設定 Query OK, 0 rows affected (0.002 sec) MariaDB [(none)]> grant all on test_db.* to 'test-user'@'localhost'; #データベースに対してユーザー権限を付与 Query OK, 0 rows affected (0.002 sec) MariaDB [(none)]> exit #終了 $ systemctl restart mariadb.service #再起動 $ mysql_secure_installation #mariaDBのセキュリティ保護 Switch to unix_socket authentication [Y/n] y # unix_socket認証に切替え Enabled successfully! Reloading privilege tables.. ... Success! Change the root password? [Y/n] y # ルートパスワードへ変更 New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success! Remove anonymous users? [Y/n] y #匿名のユーザーアカウントを削除 ... Success! Disallow root login remotely? [Y/n] y #リモートでのルートログインを無効 ... Success! Remove test database and access to it? [Y/n] y #テストデータベースを削除 - Dropping test database... ... Success! - Removing privileges on test database... ... Success! Reload privilege tables now? [Y/n] y #権限テーブルを再ロード、変更を保存 ... Success! Cleaning up... All done! If you've completed all of the above steps, your MariaDB installation should now be secure. Thanks for using MariaDB! $ systemctl restart mariadb.service #再起動 Wordpressのインストール&設定 Wordpress $ cd /var/www/html
 #htmlディレクトリへ移動 $ wget https://ja.wordpress.org/latest-ja.tar.gz
 #Wordpressパッケージのダウンロード $ tar xzvf latest-ja.tar.gz #解凍 $ cd wordpress
 #wordpressディレクトリへ移動 $ cp wp-config-sample.php wp-config.php #sampleの雛形からwp-config.phpを作成 
$ vi wp-config.php #以下設定を変更 /** WordPress のためのデータベース名 */ define( 'DB_NAME', 'test_db’ ); /** MySQL データベースのユーザー名 */ define( 'DB_USER', ‘test-user’ ); /** MySQL データベースのパスワード */ define( 'DB_PASSWORD', ‘test-password’ ); /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } if (empty($_SERVER['HTTPS'])) { $_SERVER['HTTPS'] = 'on'; $_ENV['HTTPS'] = 'on'; } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php'; $ mv * /var/www/html
 #htmlディレクトリの移動 $ cd /var/www/html/ #htmlディレクトリへ移動 $ rm -r wordpress/ #wordpressフォルダの削除 https://[ドメイン名]でアクセスすると下記のインストール画面が表示されます。 項目入力し、インストール後に成功!の画面が表示されれば完了です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2にLEMP構成のWordpressサイトを作成してみた

はじめに 前回作成記事をもとにLEMP構成のWordpressサイトを作成します。 PHPインストール PHP $ amazon-linux-extras install php7.4 -y #インストール $ php -v #インストール確認 PHP 7.4.19 (cli) (built: May 13 2021 22:36:40) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies $ systemctl start php-fpm #起動 $ systemctl enable php-fpm #自動起動設定 MariaDBのバージョンアップ Amazonlinux2には、デフォルトでMariaDBのバージョン5.5がインストールされていますが、10.5にバージョンアップさせます。 MariaDB $ sudo vi /etc/yum.repos.d/MariaDB.repo #5.5から10.5に変更 [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.5/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 $ yum install MariaDB-server MariaDB-client -y #インストール $ mysql -V #確認 mysql Ver 15.1 Distrib 10.5.10-MariaDB, for Linux (x86_64) using readline 5.1 $ systemctl start mariadb.service #起動 $ systemctl enable mariadb.service #自動起動設定 Nginx設定 Nginx $ cp -p /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.conf.org #www.confのバックアップ $ vi /etc/php-fpm.d/www.conf #以下設定を変更 user = nginx group = nginx pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 5 $ chown -R nginx:nginx /var/lib/php/session #権限をnginxに変更 $ cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.org #nginx.confのバックアップ $ mkdir -p /var/www/html #/var/www/htmlフォルダの作成 $ chown -R nginx:nginx /var/www/html #htmlディレクトリの権限をnginxに変更 $ vi /etc/nginx/nginx.conf #以下設定を変更 server { client_max_body_size 20M; listen 80 default_server; listen [::]:80 default_server; server_name _; root /var/www/html; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location ~ \.php$ { root cat ; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } $ nginx -t #nginx設定の構文チェック エラーがでなければOK nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful $ systemctl restart nginx.service #再起動 PHP設定 PHP $ vi /etc/php.ini #以下設定を変更 date.timezone = “Asia/Tokyo” expose_php = Off upload_max_filesize = 8M post_max_size = 16M memory_limit = 512M mbstring.language = Japanese mbstring.detect_order = auto mbstring.encoding_translation = Off mbstring.detect_order = UTF-8,SJIS,EUC-JP,JIS,ASCII $ systemctl restart php-fpm #再起動 $ netstat -al --protocol=unix |egrep "Proto|fpm" #nginxとphp-fpmのUNIXドメインソケット接続確認 Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 61433 /run/php-fpm/www.sock $ echo '<?php phpinfo(); ?>' | sudo tee /var/www/html/phpinfo.php #PHPの設定内容の表示確認 ブラウザからhttp://パブリックIP/phpinfo.phpもしくはhttp://パブリック IPv4 DNS/phpinfo.phpにアクセスし、PHPの設定内容が表示されることを確認する。 MariaDB設定 MariaDB $ mysql -uroot -p MariaDB [(none)]> create database test_db; #データベース作成 Query OK, 1 row affected (0.000 sec) MariaDB [(none)]> create user 'test-user'@'localhost' identified by 'test-password'; #ユーザー作成とPW設定 Query OK, 0 rows affected (0.002 sec) MariaDB [(none)]> grant all on test_db.* to 'test-user'@'localhost'; #データベースに対してユーザー権限を付与 Query OK, 0 rows affected (0.002 sec) MariaDB [(none)]> exit #終了 $ systemctl restart mariadb.service #再起動 $ mysql_secure_installation #mariaDBのセキュリティ保護 Switch to unix_socket authentication [Y/n] y # unix_socket認証に切替え Enabled successfully! Reloading privilege tables.. ... Success! Change the root password? [Y/n] y # ルートパスワードへ変更 New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success! Remove anonymous users? [Y/n] y #匿名のユーザーアカウントを削除 ... Success! Disallow root login remotely? [Y/n] y #リモートでのルートログインを無効 ... Success! Remove test database and access to it? [Y/n] y #テストデータベースを削除 - Dropping test database... ... Success! - Removing privileges on test database... ... Success! Reload privilege tables now? [Y/n] y #権限テーブルを再ロード、変更を保存 ... Success! Cleaning up... All done! If you've completed all of the above steps, your MariaDB installation should now be secure. Thanks for using MariaDB! $ systemctl restart mariadb.service #再起動 Wordpressのインストール&設定 Wordpress $ cd /var/www/html
 #htmlディレクトリへ移動 $ wget https://ja.wordpress.org/latest-ja.tar.gz
 #Wordpressパッケージのダウンロード $ tar xzvf latest-ja.tar.gz #解凍 $ cd wordpress
 #wordpressディレクトリへ移動 $ cp wp-config-sample.php wp-config.php #sampleの雛形からwp-config.phpを作成 
$ vi wp-config.php #以下設定を変更 /** WordPress のためのデータベース名 */ define( 'DB_NAME', 'test_db’ ); /** MySQL データベースのユーザー名 */ define( 'DB_USER', ‘test-user’ ); /** MySQL データベースのパスワード */ define( 'DB_PASSWORD', ‘test-password’ ); /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } if (empty($_SERVER['HTTPS'])) { $_SERVER['HTTPS'] = 'on'; $_ENV['HTTPS'] = 'on'; } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php'; $ mv * /var/www/html
 #htmlディレクトリの移動 $ cd /var/www/html/ #htmlディレクトリへ移動 $ rm -r wordpress/ #wordpressフォルダの削除 https://[ドメイン名]でアクセスすると下記のインストール画面が表示されます。 項目入力し、インストール後に成功!の画面が表示されれば完了です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2(Amazon linux2)を利用した、LEMP構成によるWordpressサイトの構築

はじめに 前回作成記事をもとにLEMP構成のWordpressサイトを作成します。 PHPインストール PHP $ amazon-linux-extras install php7.4 -y #インストール $ php -v #インストール確認 PHP 7.4.19 (cli) (built: May 13 2021 22:36:40) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies $ systemctl start php-fpm #起動 $ systemctl enable php-fpm #自動起動設定 MariaDBのバージョンアップ Amazonlinux2には、デフォルトでMariaDBのバージョン5.5がインストールされていますが、10.5にバージョンアップさせます。 MariaDB $ sudo vi /etc/yum.repos.d/MariaDB.repo #5.5から10.5に変更 [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.5/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 $ yum install MariaDB-server MariaDB-client -y #インストール $ mysql -V #確認 mysql Ver 15.1 Distrib 10.5.10-MariaDB, for Linux (x86_64) using readline 5.1 $ systemctl start mariadb.service #起動 $ systemctl enable mariadb.service #自動起動設定 Nginx設定 Nginx $ cp -p /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.conf.org #www.confのバックアップ $ vi /etc/php-fpm.d/www.conf #以下設定を変更 user = nginx group = nginx pm.max_children = 10 pm.start_servers = 2 pm.min_spare_servers = 2 pm.max_spare_servers = 5 $ chown -R nginx:nginx /var/lib/php/session #権限をnginxに変更 $ cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.org #nginx.confのバックアップ $ mkdir -p /var/www/html #/var/www/htmlフォルダの作成 $ chown -R nginx:nginx /var/www/html #htmlディレクトリの権限をnginxに変更 $ vi /etc/nginx/nginx.conf #以下設定を変更 server { client_max_body_size 20M; listen 80 default_server; listen [::]:80 default_server; server_name _; root /var/www/html; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location ~ \.php$ { root cat ; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } $ nginx -t #nginx設定の構文チェック エラーがでなければOK nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful $ systemctl restart nginx.service #再起動 PHP設定 PHP $ vi /etc/php.ini #以下設定を変更 date.timezone = “Asia/Tokyo” expose_php = Off upload_max_filesize = 8M post_max_size = 16M memory_limit = 512M mbstring.language = Japanese mbstring.detect_order = auto mbstring.encoding_translation = Off mbstring.detect_order = UTF-8,SJIS,EUC-JP,JIS,ASCII $ systemctl restart php-fpm #再起動 $ netstat -al --protocol=unix |egrep "Proto|fpm" #nginxとphp-fpmのUNIXドメインソケット接続確認 Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 61433 /run/php-fpm/www.sock $ echo '<?php phpinfo(); ?>' | sudo tee /var/www/html/phpinfo.php #PHPの設定内容の表示確認 ブラウザからhttp://パブリックIP/phpinfo.phpもしくはhttp://パブリック IPv4 DNS/phpinfo.phpにアクセスし、PHPの設定内容が表示されることを確認する。 MariaDB設定 MariaDB $ mysql -uroot -p MariaDB [(none)]> create database test_db; #データベース作成 Query OK, 1 row affected (0.000 sec) MariaDB [(none)]> create user 'test-user'@'localhost' identified by 'test-password'; #ユーザー作成とPW設定 Query OK, 0 rows affected (0.002 sec) MariaDB [(none)]> grant all on test_db.* to 'test-user'@'localhost'; #データベースに対してユーザー権限を付与 Query OK, 0 rows affected (0.002 sec) MariaDB [(none)]> exit #終了 $ systemctl restart mariadb.service #再起動 $ mysql_secure_installation #mariaDBのセキュリティ保護 Switch to unix_socket authentication [Y/n] y # unix_socket認証に切替え Enabled successfully! Reloading privilege tables.. ... Success! Change the root password? [Y/n] y # ルートパスワードへ変更 New password: Re-enter new password: Password updated successfully! Reloading privilege tables.. ... Success! Remove anonymous users? [Y/n] y #匿名のユーザーアカウントを削除 ... Success! Disallow root login remotely? [Y/n] y #リモートでのルートログインを無効 ... Success! Remove test database and access to it? [Y/n] y #テストデータベースを削除 - Dropping test database... ... Success! - Removing privileges on test database... ... Success! Reload privilege tables now? [Y/n] y #権限テーブルを再ロード、変更を保存 ... Success! Cleaning up... All done! If you've completed all of the above steps, your MariaDB installation should now be secure. Thanks for using MariaDB! $ systemctl restart mariadb.service #再起動 Wordpressのインストール&設定 Wordpress $ cd /var/www/html
 #htmlディレクトリへ移動 $ wget https://ja.wordpress.org/latest-ja.tar.gz
 #Wordpressパッケージのダウンロード $ tar xzvf latest-ja.tar.gz #解凍 $ cd wordpress
 #wordpressディレクトリへ移動 $ cp wp-config-sample.php wp-config.php #sampleの雛形からwp-config.phpを作成 
$ vi wp-config.php #以下設定を変更 /** WordPress のためのデータベース名 */ define( 'DB_NAME', 'test_db’ ); /** MySQL データベースのユーザー名 */ define( 'DB_USER', ‘test-user’ ); /** MySQL データベースのパスワード */ define( 'DB_PASSWORD', ‘test-password’ ); /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } if (empty($_SERVER['HTTPS'])) { $_SERVER['HTTPS'] = 'on'; $_ENV['HTTPS'] = 'on'; } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php'; $ mv * /var/www/html
 #htmlディレクトリの移動 $ cd /var/www/html/ #htmlディレクトリへ移動 $ rm -r wordpress/ #wordpressフォルダの削除 https://[ドメイン名]でアクセスすると下記のインストール画面が表示されます。 項目入力し、インストール後に成功!の画面が表示されれば完了です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

KCLについてまとめる②

KCLの概念 ワーカー ワーカーは、シャードとリース情報の同期、シャード割り当ての追跡、シャードからのデータの処理など、さまざまなタスクを初期化し、監督を行う。 また、データストリームからレコードプロセッサにデータレコードを配信を行う。 ※ワーカーはKCLアプリケーション内で1つだけ存在する。 レコードプロセッサ KCL コンシューマーアプリケーションがデータストリームから取得したデータをどのように処理するかを定義するロジック。 ワーカーによって、リースを保持するシャードごとに1つのレコードプロセッサがインスタンス化される。 リース ワーカーとシャード間の紐付けを定義するデータ。KCLアプリケーションが存在する場合は、リースを使用して、複数のワーカーにまたがってデータレコード処理を行う。 ※KCLアプリケーションは1つのプロセスで対象のKinesisストリームの全てのシャードを受け持つことができるが、 シャード数が大量の場合は並列度が上がり、1つのプロセスでは処理しきれなくなる可能性がある。 このような場合に複数のKCLアプリケーションを立ち上げ負荷分散を行う。 リーステーブル ・KCLは一意のリーステーブル(Amazon DynamoDBに自動的に作成される)を使用して、KCLアプリケーションの ワーカーによってリースおよび処理される KDS データストリームのシャードを管理する。 ※KCLは、KCLアプリケーション名と同じ名前でリーステーブルを作成する。そのため、各KCLアプリケーション名は一意である必要がある。 リーステーブルの項目 checkpoint: シャードの最新チェックポイントのシーケンス番号。この値は、データストリームのすべてのシャードで一意。 checkpointSubSequenceNumber: Kinesis Producer Libraryのアグリゲーション機能を使用する場合、Kinesisレコード内の個々のユーザーレコードを追跡するcheckpointの拡張機能。 leaseCounter: ワーカーのリースが他のワーカーに保持されていることをワーカーが検出できるように、リースのバージョニングに使用される。 leaseKey: リースの固有識別子。各リースはデータストリームのシャードに固有のもので、一度に 1 つのワーカーで保持されます。(例:shardId-000000000000) leaseOwner: このリースを保持しているワーカー。 ownerSwitchesSinceCheckpoint: 最後にチェックポイントが書き込まれてから、このリースのワーカーが何回変更されたかを示す。 parentShardId: 子シャードの処理を開始する前に、親シャードが完全に処理済みであることを確認するために使用される。これにより、レコードがストリームに入力されたのと同じ順序で処理されるようになる。 hashrange(KCL1.14およびKCL2.3のみ): PeriodicShardSyncManagerによって使用され、定期的な同期を実行してリーステーブルに欠けているシャードを見つけ、必要に応じてシャードのためのリースを作成する。 childshards(KCL1.14およびKCL2.3のみ: LeaseCleanupManagerが子シャードの処理状況を確認し、親シャードをリーステーブルから削除できるかどうかを判断するために使用される。 ShardId(Java用KCL2.xのみ): シャードの ID。 -stream name(Java用KCL2.xのみ): 次の形式のデータストリームの識別子。account-id:StreamName:streamCreationTimestamp  Throughput KCLアプリケーションによって自動的に作成されるリーステーブルの、プロビジョニングされるスループットは1秒あたりの読み込み10回、1秒あたりの書き込み10回。 シャードを増やしていくとチェックポイントテーブルへのアクセス頻度も多くなり、キャパシティが不足してくる可能性がある。 キャパシティが不足するとチェックポイントの記録でエラーが発生するようになるため、運用でシャード増加に合わせてRCU、WCUを増加させるか、オンデマンドで運用する必要がある。 おわりに KCLむずかしい。。。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS IAMのグループ、ユーザーをTerraform で管理する

AWS IAM 周りを勉強して、コンソール上からの作成の仕方を覚えたので、実際に Terraform を利用した作成、管理の方法を実践してまとめました。 Terraform のプロジェクトのセットアップに関しては別で記事を出していますのでそちらをぜひ。 IAM の設計 AWS では、個別のIAM ユーザーごとに権限を付与するのではなく、グループを作成し、そこに対して権限を付与、ユーザーを紐付けることが推奨されています。 後々組織が大きくなったりすることによってAWSリソースを利用するメンバーが増えた時に、個別で設定するよりも楽に管理ができるようにするためです。 今回は下記の想定で、IAM グループ、ポリシーを作成し、ユーザーを作成して紐付けていきます。 開発者用のIAMグループを作成する EC2(VPC)、ALB、Auto Scaling、RDS、S3のアクセスが可能 開発者であるIAM ユーザーは上記のグループに紐づけられる Terraform プロジェクトの構成 . ├── docker-compose.yml // Terraform実行のためのDocker環境 └── src ├── module_aws.tf ├── modules │ └── aws │ ├── iam_group.tf │ └── iam_user.tf └── providers.tf 後々、gcpなど、他プロバイダーの利用なども考えられるため、moduleとして分けました。 IAM グループ、ポリシーの作成 module_aws.tf module "aws" { source = "./modules/aws" } providers.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 3.44.0" } } } provider "aws" { region = "ap-northeast-1" } modules/aws/iam_group.tf resource "aws_iam_group" "developers" { name = "developers" path = "/users/" } terraform plan を実行して確認ができるかと思います。 Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # module.aws.aws_iam_group.developers will be created + resource "aws_iam_group" "developers" { + arn = (known after apply) + id = (known after apply) + name = "developers" + path = "/users/" + unique_id = (known after apply) } # module.aws.aws_iam_group_policy.developer_policy will be created + resource "aws_iam_group_policy" "developer_policy" { + group = "developers" + id = (known after apply) + name = "developer_policy" + policy = jsonencode( { + Statement = [ + { + Action = [ + "rds:*", + "s3:*", + "ec2:*", + "elasticloadbalancing:*", + "autoscaling-plans:*", ] + Effect = "Allow" + Resource = "*" }, ] + Version = "2012-10-17" } ) } Plan: 2 to add, 0 to change, 0 to destroy. IAM ユーザーの作成、グループへの追加 modules/aws/iam_user.tf resource "aws_iam_user" "example" { name = "example" path = "/" force_destroy = true } // 作成したIAMユーザーを、グループに追加する resource "aws_iam_user_group_membership" "example" { user = aws_iam_user.example.name groups = [ aws_iam_group.developers.name ] } こちらも、terraform plan で確認できます。 Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # module.aws.aws_iam_user.example will be created + resource "aws_iam_user" "example" { + arn = (known after apply) + force_destroy = true + id = (known after apply) + name = "example" + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) } # module.aws.aws_iam_user_group_membership.example will be created + resource "aws_iam_user_group_membership" "example" { + groups = [ + "developers", ] + id = (known after apply) + user = "example" } Plan: 2 to add, 0 to change, 0 to destroy. ここまで作成したところで、terraform applyを実行することで、適用されます。 AWS コンソール上のIAM の画面より、確認することができます。 また他のリソースに関しても、まとめていきます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Athena で配列の要素を Column にする

一回 unnest にした結果を集計してカラムに戻してやることで実現した。 WITH dataset AS ( SELECT ARRAY [1,2,3] AS items ) SELECT MAX(CASE WHEN i = 1 THEN i END) AS one , MAX(CASE WHEN i = 2 THEN i END) AS two , MAX(CASE WHEN i = 3 THEN i END) AS three FROM dataset CROSS JOIN UNNEST(items) AS t(i) こんな感じの結果になるよ。 もっといい方法があったら教えて下さい。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS S3 について

はじめに インデックスはこちら。 AWS S3とは SimpleStorageServiceの略。いわゆるファイルサーバー。ただしサーバーレスのため、負荷などを考慮する必要は特に無い。 認証は基本的にIAMベース。AWSに登録されているユーザーに対してアクセス権限の設定ができる。 ファイルのアップロードはWebブラウザからできる。CLIからも可能。 機能まとめ クラウドのファイルサーバー アクセス制限機能 オブジェクト単位 バケット単位 ユーザー単位 リクエスト数、転送容量に応じて課金 JavaScriptでS3からファイルの一時URLを取得する例 import AWS from 'aws-sdk'; AWS.config.update({ accessKeyId: 'xxxx', secretAccessKey: 'xxxx', region: 'ap-northeast-1' }) const s3 = new AWS.S3() const url = s3.getSignedUrl('getObject', { Bucket: 'test-bucket', Key: 'data.jpg', Expires: 60 }) console.log(url)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS DynamoDBについて

はじめに インデックスはこちら。 AWS DynamoDBとは KeyValueのデータベース。Keyを指定してValueを取得する。サーバーレスなので、負荷などを考える必要はあまりない(何も考えなくても良いわけではない)。 Keyは文字列。Valueはnumberやstringなどの基本的なものから、JSONなどのドキュメントも利用可能。 スキーマレスなので、データ毎に別の構造でデータが入れられる。 機能まとめ データの単位はテーブルとエンティティ テーブルの中にエンティティがある Userテーブルと、その中のHogeさんのデータ、みたいな エンティティはキー値が必須 それ以外はあってもなくてもいい 同じテーブル内のエンティティ間で違っても良い スキーマレス キー値 パーティションキ(必須)ーとソートキー(任意)からなる パーティションキー メインのキー属性 ソートキーを指定しない場合は一意である必要がある ソートキーを指定するなら被っても良い パーティションキーの値によって値の保存先が変わる 同じパーティションキーにデータが偏るとパフォーマンスが低下する ソートキー ソートキーを指定する場合はパーティションキーは一意じゃなくて良い ソートキーと組み合わせて一意になる必要がある ソートキーには検索条件が指定できる SQLのwhere的なやつ 逆にパーティションキーには条件を指定できない パーティションを跨ぐ検索はできない したければ一旦スキャン(全件取得)するしかない ローカルセカンダリインデックス 追加のキー属性 同じパーティションキーについて、ソートキーを新しく追加できる 略してLSI グローバルセカンダリインデックス 追加のキー属性 新しくパーティションキーから指定できる 略してGSI キャパシティユニットの指定で性能が変わる リードキャパシティユニット RCU 1KBまでの強整合なデータが1秒に1回読める 1KBまでの結果整合なデータが1秒に2回読める ライトキャパシティユニット WCU 1KBまでのデータが1秒に1回書ける テーブルに対してRCUとWCUを指定する 料金は大体キャパシティユニットとデータサイズと転送量で決まる データ例 ユーザーテーブル 定義 ユーザーテーブル ユーザーID(パーティションキー) 名前 解説 ユーザー毎のデータを保存。ユーザーIDで一意に特定できるため、パーティションキーにユーザーIDを指定。データ取得時はユーザーIDを指定することで値を取得する。 ブログ記事 定義 ブログ記事テーブル ユーザーID(パーティションキー) 作成日時(ソートキー) 下書きとか公開とかを表す記事状態 ブログタイトル ブログ本文 LSI ユーザーID(パーティションキー) 下書きとか公開とかを表す記事状態(ソートキー) GSI 下書きとか公開とかを表す記事状態(パーティションキー) 作成日時(ソートキー) 解説 ユーザーIDと作成日時でデータを取得する。ユーザーIDがパーティションキーなので、同じユーザーのデータは同じパーティションに入る。ソートキーが作成日時なので、作成日時で範囲検索やソートが可能。 とあるユーザーの公開されている記事のみを取得したい要件があったので、LSIを追加。パーティションキーがテーブルに設定されているのと同じユーザーIDなので、LSIで対応できる。 また、全ユーザーの公開記事一覧を取得したい要件があったので、GSIを追加。パーティションキーがユーザーIDなので、そのままではユーザーを跨いだ検索が行えない。同じ状態を同じパーティションにすることでまとめて取得できるので、状態をパーティションキーに指定してGSIを作る。これで全ユーザーの公開記事を作成日順で取得、などが可能になる。 (パーティション偏りそうなのであまり良くない例だったかも…)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS API Gatewayについて

はじめに インデックスはこちら。 AWS API Gatewayとは APIを作成するときに利用する。API GatewayはあくまでAPIの入口のみの担当であり、本体は別途サービス(Lambda等)で作成する必要がある。 API GatewayはAPIの入口として、URLのルーティングや認証、スロットリングなどを行う。それらを通過したリクエストについて、APIの本体へと接続させる。 機能まとめ APIの入口を作るためのもの APIのパスを決める(/hoge/fuga/)など APIの本体は別に用意する必要がある(LambdaやEC2など) APIGatewayに接続先を設定する モックを設定してAPI Gatewayから直接応答を返すことも可能 パスパラメータを設定できる /user/{id}とか 設定しておけば勝手に切り出して、APIの本体へ渡してくれる 各種認証機能を利用できる API Keyによる認証 IAMによる認証 Cognitoによる認証 ステージ管理ができる devとかstagingとかproductionとか 紐付け先のlambdaなどを変えられる カナリアリリース用のステージを作るなどができる 一部のアクセスをこのステージに流す スロットリング アクセス量を制限できる モニタリング  アクセス数  エラーの発生状況  など 課金は処理件数と接続時間に応じて その他 許可するHTTP Headerの内容の設定ができる
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Lambdaについて

はじめに インデックスはこちら。 AWS Lambdaとは クラウド上に配置できる関数。 APIの作成に利用したり、データに応じたイベント処理などに利用できる。多分APIに使われていることが多いと思われる。 サーバーレスのため、簡単にクラウドに設置可能。最も手軽な設置手段は、ブラウザからAWSにアクセスしてフォームに直接関数を記述するもの。その他、構成管理ツールなどからも設置可能。 関数は各種言語で利用可能となっている。 機能まとめ クラウド上における関数 用途 APIの本体 何らかのイベント(ファイルのアップロードなど)に合わせてデータの加工をする など 標準で使える言語 Java Go PowerShell Node. C#、 Python Ruby その他も一応使える 1関数1アプリになる 関数毎に全く別の環境 負荷分散 関数単位で独自にデプロイ → MicroServices バージョン機能 同じ関数に複数バージョンを用意できる 入れ替え時などに便利 APIにするときは、フロントにAPIGatewayを利用 直接Lambdaを呼ぶこともできるが、AWSのLibraryからの呼び出しになる URLに紐付けれない アップロード Webブラウザでコードを貼り付ける zipでアップロード 何らかの構成管理ツール など 利用メモリと実行時間・リクエスト回数に応じて課金 サーバーレスといいつつ利用メモリという概念… まぁ実際には裏にサーバーがいるので 実際に実行するサーバーに割り当てるメモリの容量 JavaScriptでのLambdaの例 exports.handler = (event, context, callback) => { callback(null, 'Hello !!'); }; 引数のeventとcontextには呼び出し元の情報が入る API GatewayならURLのパスとか 引数のcallbackでは結果を呼び出し元に返す
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

サーバーレスでWebアプリを作成するために使えるAWSのサービスまとめ

はじめに サーバーレスでWebアプリを作成したいときに使えるAWSのサービスについて、簡単にまとめていきます。 基本的には自分向けの勉強メモですが、ある程度の経験がある方を対象としての共有にもなるかと考えています。初心者向けではないので、プログラミングやWebアプリについての基本的な説明などは行いません。 本記事はインデックスです。詳細は項目毎に別記事へリンクしていきます。 サーバーレスとは? 近年流行の、Webのサーバーサイドのインフラ。サーバーという概念を気にする事なく、クラウドにインフラを構築できる。アプリのソースコードをブラウザからアップロードするだけでクラウド上で動くようになります、というようなイメージ。 サーバーレスではない、普通にサーバーを使う環境では サーバーの用意(ハードウェアだったりVMだったり) 必要なソフトウェア(Apacheだったり言語の実行環境だったりRDBだったり)のインストール サーバーのデータが壊れたときのバックアップの考慮 負荷分散を考えて、サーバー台数を増やしたり減らしたり など様々な考慮が必要になるが、サーバーレスではこのような作業を気にする必要がなくなる。AWSが裏でよしなに処理してくれる。 料金は基本的に従量制。使った分のみ支払う。サーバーレスではない環境のように、リソースを常時確保する必要がなくなるため、基本的には料金は安くなる(常時高負荷の環境は別かもしれないが…) AWSで使えるサーバーレスなサービス Lambda API Gateway DynamoDB S3 あたりが挙げられる。SPAでアプリを作成するなら、 S3にWebページを保存(クライアントサイドのアプリを配信) LambdaでAPIの本体を実装 APIGatewayでAPIの入口を作成 データベースとしてDynamo利用してデータ保存 あたりが一般的と思われる。 Lambdaについて クラウド上の関数。何らかのプログラムをクラウド上で実行するのに利用する。 まとめ記事。 API Gateway APIを作成するのに利用する。特定のURLのパスと、APIの実体(Lambdaなど)を紐付ける。 まとめ記事。 DynamoDB クラウド上のキーバリューなデータベース。 まとめ記事。 S3 クラウドなファイルサーバー。 まとめ記事。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS FargateとAzure Container Instancesにおける機械学習モデルのサービング技術比較

初版: 2021年6月9日 著者: 橋本恭佑、柿田将幸, 株式会社 日立製作所 はじめに 本投稿では、学習済みの機械学習モデルをAWS FargateおよびAzure Container Instancesを用いてサービングする方法を紹介します。 今回の検証では、サービングに必要なライブラリや前処理、モデル、後処理を含んだコンテナイメージを事前に作成しておき、それをAWS/Azureのコンテナ基盤上にデプロイして使用します(下表の赤枠の部分)。 投稿一覧 AWSとMicrosoft Azureにおける機械学習モデルのサービング技術の概要 Amazon SageMakerとAzure MLにおける機械学習モデルのサービング技術比較: AWS/Azureが提供するコンテナイメージを利用する場合 Amazon SageMakerとAzure MLにおける機械学習モデルのサービング技術比較: 自作コンテナイメージを利用する場合 AWS FargateとAzure Container Instancesにおける機械学習モデルのサービング技術比較・・・本投稿 本検証の事前準備 本投稿では、以前の投稿の検証シナリオで作成した下記ファイルを利用しますので、事前に用意してください。 学習済みの手書き文字認識モデル: model.joblib 前処理・モデル利用・後処理を記載したスクリプト: api_server.py AWSとAzureにおけるパターン3の実現技術の違い パターン3を実現する場合の手順を図1に、パターン3を実現する場合に利用する技術をAWSとAzureで比較した結果を表2に示します。 コンテナイメージをデプロイするサービスとして、AWSの場合はAWS Fargate、Azureの場合はAzure Container Instancesを利用でき、双方の技術に大きな差分は見られません。本稿ではこの手順に沿ってパターン3が実現可能かを実機検証した結果を紹介します。 図1: パブリッククラウドにおいてパターン3を実現する場合の手順 表2: AWSとAzureでパターン3を実現する場合に利用する技術の比較 項番 手順 AWSで手順を実現する技術 Microsoft Azureで手順を実現する技術 1 ライブラリと前処理・モデル・後処理を呼び出す推論コードを内包したコンテナイメージをアップロードする ライブラリをインストールし前処理・モデル・後処理を呼び出す推論コードを内包したコンテナイメージをオンプレミス環境で作成し、Amazon ECR(Elastic Container Registry)へプッシュする ライブラリをインストールし前処理・モデル・後処理を呼び出す推論コードを内包したコンテナイメージをオンプレミス環境で作成し、Azure Container Registryへプッシュする 2 コンテナイメージを指定してコンテナを立ち上げる AWSのマネジメントコンソールまたはAWS CLIでコンテナイメージを指定し、AWS Fargateを実行する AzureのポータルまたはAzure CLIでコンテナイメージを指定し、Azure Container Instancesを実行する AWS Fargateでサービングする場合 以前の投稿で作成した前処理・モデル・後処理のスクリプトapi_server.pyを格納した推論用コンテナイメージを作成し、Amazon ECRへアップロードします。 まず、下記コマンドを実行して、Amazon ECRへアップロードする前処理・モデル・後処理を格納した推論用コンテナイメージを作成します。 # 1. 必要なライブラリをインストールして、前処理・後処理・モデルを内包したコンテナを起動。 # 仮想環境(下の例はawsという名前)を作成した場合は、./bashrc && conda activate awsすることで、仮想環境下でpythonの各モジュールを利用可能。 $ docker run -d -it -p 5000:5000 --network=host --name awsserving-02 awsserving:0.1 bash -c "source ~/.bashrc && conda activate aws; cd /root/serving; python api_server.py" # 2. 作成したコンテナをイメージ化。下の例ではossset:0.2というコンテナイメージが作成される。 $ docker commit awsserving-02 ossset:0.2 次に、コンテナを作成した環境にAWSのCommand Line Interface (CLI)をインストールして、AWSのCLIを利用してAmazon ECRにコンテナイメージをpushします。AWSのCLIは、zipファイルを入手し、解凍したzipファイルのinstallスクリプトを起動することでインストールできます。AWSのCLIをインストールした後は、AWSのECR環境へログインするための情報を入力します。AWSのECR環境でコンテナレポジトリを作成し、Access keyとSecret Access Keyを用意して、AWSのECR環境へログインしてください。ログインコマンド、タグコマンド、pushコマンドは、ECR環境で自分のコンテナレポジトリを作成すると、図1の「プッシュコマンドの表示」から得ることができます。 # 1. AWSのCLIのzipを解凍する $ unzip awscliv2.zip # 2. AWSのCLIをインストールする $ cd aws; ./install # 3. aws configureして、自分のaccess keyとsecret access key, region, output(json/text)を入力する。profile名defaultとして登録される。 # 4. Amazon ECR環境へログインする。 $ aws ecr get-login-password --profile default | docker login --username AWS --password-stdin xxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com (注意点2)regionではなくprofileをオプションとして指定すること  # 5. 作成したコンテナイメージをAmazon ECRへアップロードするためにタグ付けする。 $ docker tag ossset:0.2 xxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/ossset:latest # 6. タグ付けしたコンテナイメージをAmazon ECRへpushする。 $ docker push xxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/ossset:0.2 図1: Amazon ECRにおけるプッシュコマンドの入手先 最後に、AWS Fargateを用いてAmazon ECRにプッシュしたコンテナイメージをデプロイします。本投稿ではAWSのマネジメントコンソールを利用する方法を紹介します。 AWSのマネジメントコンソールで「タスク定義」を作成し、コンテナイメージをデプロイするコンテナ基盤(AWS Fargateでは「クラスター」と呼びます)を作成して、クラスター上でタスクを実行することで、コンテナイメージをデプロイできます。 まず、Amazon ECS(Elastic Container Service)の「タスク定義」で「ステップ 1: 起動タイプの互換性の選択」から「Fargate」を選択して、「ステップ 2: タスクとコンテナの定義の設定」の「コンテナの定義」の欄から「コンテナの定義」をクリックして、ECRへプッシュしたコンテナイメージを呼び出します。Flaskではデフォルトで5000番ポートを利用するため、図2の「コンテナの定義」の画面のポートマッピングで5000番を入力します。 図2:「コンテナの追加」画面 次に、クラスターを作成します。Amazon ECSの「クラスター」から「クラスターの作成」を選択し、「ステップ 1: クラスターテンプレートの選択」から「ネットワーキングのみ」を選択し、「ステップ2: クラスターの設定」でクラスターに名前をつけて、クラスターを作成します。 最後に、クラスター上でタスクを実行します。Amazon ECSの「クラスター」から、先程作成したクラスターを選択して、「タスク」タブから「新しいタスクの実行」を選択します。図3の様に「起動タイプ」で「Fargate」を選択し、「タスク定義」で先程作成したタスク定義を呼び出して、「プラットフォームのバージョン」で「1.4.0」を選択します。ここで、サイズが10GB以上あるコンテナは、Fargateのプラットフォームが1.4.0以上でないとデプロイできず、デフォルトの「LATEST」を選択しても1.3.0になってしまうので明示的に設定する必要があることに注意してください。入力し終わったら、「タスクの実行」をクリックして、コンテナイメージのデプロイが成功すればサービング完了です。 図3: コンテナのデプロイ用画面 推論が成功することを、デプロイしたコンテナへアクセス可能なネットワーク上の他の仮想マシンやコンテナから、以前の投稿の最後に示した動作確認用のコマンドを実行して確認してください。 $ curl -F file=@x_test_30.jpeg localhost:5000/predict { "Content-Type": "application/json", "number": "3" } $ curl -F file=@x_test_60.jpeg localhost:5000/predict { "Content-Type": "application/json", "number": "6" } 以上の検証結果から、AWS Fargateを利用して「オンプレミス環境でライブラリ・前処理・モデル・後処理を含んだコンテナイメージを作成し、コンテナ基盤へデプロイする」ことが可能であることを確認できました。 Azure Container Instancesでサービングする場合 以前の投稿で作成した前処理・モデル・後処理のスクリプトapi_server.pyを格納した推論用コンテナイメージを作成し、Azure Container Registry(ACR)へアップロードします。ACRへアップロードする前処理・モデル・後処理を格納した推論用コンテナイメージは、AWS Fargateの場合で示したコマンド例と同様にして作成できます。 次に、コンテナを作成した環境にAzureのCLIをインストールし、AzureのCLIを利用してACRにコンテナイメージをpushします。AzureのCLIは、rpmファイルを入手し、installコマンドを起動することでインストールできます1。AzureのCLIをインストールして、ACRをAzureのポータルから作成した後は、Azure環境およびACRへログインするための情報を入力します。 # 1. Azure環境へログインする。出力されるURLへアクセスしてコードを入力すると、Azure環境へのログインが完了する。 $ az login To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXX to authenticate. # 2.ACRへログインする。次の例はレジストリ名を「osscenter」とした場合の例 $ az acr login --name osscenter # Login Succeededと出力されることを確認する。 # 3. 作成したコンテナイメージをACRへアップロードするためにタグ付けする。 $ docker tag ossset:0.2 osscenter.azurecr.io/ossset:0.2 # 4. タグ付けしたコンテナイメージをACRへpushする。 $ docker push osscenter.azurecr.io/ossset:0.2 コンテナイメージをACRへプッシュした後は、Azure Container Instancesを用いてコンテナをデプロイします。デプロイするためには、Azureのポータルからデプロイする方法と、Azure CLIを利用する2つの方法があります。前者の方法は、ACRの管理者アカウントを利用するため、複数人でコンテナイメージを共有する場合には適切ではありません。そこで、ここでは後者の方法を紹介します。 後者の方法では、Azure CLIからACRを操作するために、ACRのサービスプリンシパルを作成し、作成したレジストリに割り当てます。サービスプリンシパルとは、Azure CLIやAzure Container InstancesのようなプログラムからAzureのリソースへアクセスするためのIDを指します。下記スクリプトに必要な情報(作成したレジストリ名など)を入力して実行することで、作成したレジストリにサービスプリンシパルを割り当てます。割り当てが成功すると、サービスプリンシパルIDとサービスプリンシパルパスワードが出力されます。 #!/bin/bash # Modify for your environment. # ACR_NAME: The name of your Azure Container Registry # SERVICE_PRINCIPAL_NAME: Must be unique within your AD tenant ACR_NAME=<container-registry-name> SERVICE_PRINCIPAL_NAME=acr-service-principal # Obtain the full registry ID for subsequent command args ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv) # Create the service principal with rights scoped to the registry. # Default permissions are for docker pull access. Modify the '--role' # argument value as desired: # acrpull: pull only # acrpush: push and pull # owner: push, pull, and assign roles SP_PASSWD=$(az ad sp create-for-rbac --name http://$SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query password --output tsv) SP_APP_ID=$(az ad sp show --id http://$SERVICE_PRINCIPAL_NAME --query appId --output tsv) # Output the service principal's credentials; use these in your services and # applications to authenticate to the container registry. echo "Service principal ID: $SP_APP_ID" echo "Service principal password: $SP_PASSWD" 次に、作成したサービスプリンシパルのIDやパスワードをAzureに安全に保管するための、Azure キーコンテナを作成します。下記コマンドで作成できます。 # (下記はリソースグループの名称をosscenter-rg、キーコンテナの名称を # osscenter-vaultとした場合です) $ az keyvault create --resource-group osscenter-rg --name osscenter-vault Azureキーコンテナを作成した後は、サービスプリンシパルIDとサービスプリンシパルパスワードをAzureキーコンテナに格納します。 # 1. サービスプリンシパルパスワードをAzureキーコンテナへ格納する。 $ az keyvault secret set \ > --vault-name osscenter-vault \ > --name osscenter-pull-pwd \ > --value $(az ad sp create-for-rbac \ > --name http://acr-service-principal \ > --scopes $(az acr show --name osscenter --query id --output tsv) \ > --role acrpull \ > --query password \ > --output tsv) # 2. サービスプリンシパルIDをAzureキーコンテナへ格納する。 $ az keyvault secret set \ > --vault-name osscenter-vault \ > --name osscenter-pull-usr \ > --value $(az ad sp show --id http://acr-service-principal --query appId --output tsv) # 1. サービスプリンシパルパスワードをAzureキーコンテナへ格納する。 $ az keyvault secret set \ > --vault-name osscenter-vault \ > --name osscenter-pull-pwd \ > --value $(az ad sp create-for-rbac \ > --name http://acr-service-principal \ > --scopes $(az acr show --name osscenter --query id --output tsv) \ > --role acrpull \ > --query password \ > --output tsv) # 2. サービスプリンシパルIDをAzureキーコンテナへ格納する。 $ az keyvault secret set \ > --vault-name osscenter-vault \ > --name osscenter-pull-usr \ > --value $(az ad sp show --id http://acr-service-principal --query appId --output tsv) 最後に、Azureキーコンテナを利用して入力した認証情報を利用して、Azure CLIからコンテナをデプロイします。 # 下記はACIでデプロイするコンテナ名をflaskとして、公開するDNSの名称を # flask-osssetとした場合のコマンド例です。 $ az container create > --resource-group osscenter-rg \ > --name flask –image osscenter.azurecr.io/ossset:0.2 > --cpu 1 --memory 1 --registry-login-server osscenter.azurecr.io \ > --registry-username $(az ad sp show --id http:// acr-service-principal --query appId --output tsv) \ > --registry-password $SERVICE_PRINCIPAL_PASSWORD --dns-name-label flask-ossset --ports 5000 # “Finished”と出力されることを確認する。 これでサービング完了です。以前の投稿に示した動作確認用のコマンドを下記の様に実行して、推論結果が返ってくることが確認できれば動作検証完了です。 $ curl -F file=@x_test_30.jpeg http://flask-ossset.japaneast.azurecontainer.io:5000/predict { "Content-Type": "application/json", "number": "3" } $ curl -F file=@x_test_60.jpeg http://flask-ossset.japaneast.azurecontainer.io:5000/predict { "Content-Type": "application/json", "number": "6" } 以上の検証結果から、Azure Container Instancesを利用して「オンプレミス環境でライブラリ・前処理・モデル・後処理を含んだコンテナイメージを作成し、コンテナ基盤へデプロイする」ことが可能であることを確認できました。 検証結果の考察 今回の検証を通して、オンプレミス環境でライブラリ・前処理・モデル・後処理を含んだコンテナイメージを作成し、コンテナ基盤へデプロイすることは、AWS FargateとAzure Container Instancesの両方であることがわかりました。 パターン3で、ライブラリやモデル・推論コードをすべて含むコンテナイメージをオンプレミス環境で作成すると、コンテナイメージのサイズが大きくなりがちです。特にAWSを利用する場合、Fargateのバージョンが1.3.0以下の場合は、コンテナイメージ用の一時ストレージに10GBの容量制限があります。したがって、10GBよりサイズの大きいコンテナをデプロイする場合は、Fargateのバージョンを1.4.0に指定することに注意が必要です。 なお、今回は紹介しませんでしたが、AWSを利用する方法には、ユーザが管理できるコンテナ基盤を作成し、その上にコンテナをデプロイする方法もあります(AWS Elastic Container Service)。コンテナに割り当てるコンピュータリソース(CPU・メモリ量など)をFargateよりも細かく指定できるため、性能要件が厳しい場合に有効です。 おわりに 本投稿では、学習済みの機械学習モデルを自作コンテナイメージを用いてサービングする技術について、AWSとMicrosoft Azureで実際にサービングして比較した結果を解説しました。 https://docs.microsoft.com/ja-jp/cli/azure/install-azure-cli ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SageMakerとAzure MLにおける機械学習モデルのサービング技術比較: 自作コンテナイメージを利用する場合

初版: 2021年6月9日 著者: 橋本恭佑、柿田将幸, 株式会社 日立製作所 はじめに 本投稿では、学習済みの機械学習モデルをパブリッククラウド上でサービングする技術について、Amazon SageMakerおよびAzure Machine Learning (Azure ML)上で実際に試した手順を踏まえて比較した結果を解説します。 前回の投稿では、AWS/Azureが提供するコンテナイメージを利用してサービングしました。 今回の検証では、オンプレミス環境で必要なライブラリを含んだコンテナイメージを作成し、デプロイするときに、前処理・モデル・後処理を追加します(表1の赤枠の部分)。 表1: オンプレミス環境で学習させた機械学習モデルをAWSおよびMicrosoft Azure上でサービングする際のサービス一覧(2021年2月現在) 投稿一覧 AWSとMicrosoft Azureにおける機械学習モデルのサービング技術の概要 Amazon SageMakerとAzure MLにおける機械学習モデルのサービング技術比較: AWS/Azureが提供するコンテナイメージを利用する場合 Amazon SageMakerとAzure MLにおける機械学習モデルのサービング技術比較: 自作コンテナイメージを利用する場合・・・本投稿 AWS FargateとAzure Container Instancesにおける機械学習モデルのサービング技術比較 本検証の事前準備 本投稿では、以前の投稿の検証シナリオ(第1回の「検証シナリオ」節へのリンクを掲載予定)で作成した下記ファイルを利用しますので、事前に用意してください。 学習済みの手書き文字認識モデル: model.joblib 前処理・モデル利用・後処理を記載したスクリプト: api_server.py AWSとAzureにおけるパターン2の実現技術の違い パターン2を実現する場合の手順を図1に、パターン2を実現する場合に利用する技術をAWSとAzureで比較した結果を表2に示します。 Amazon SageMakerとAzure MLの双方で、機械学習モデルのサービングに必要なサービスが提供されており、モデルのアップロード先が双方のパブリッククラウドで異なる以外に大きな差分は見られません。本稿ではこの手順に沿ってパターン2が実現可能かを実機検証した結果を紹介します。 図1: パブリッククラウドにおいてパターン2を実現する場合の手順 表2: AWSとAzureでパターン2を実現する場合に利用する技術の比較 項番 手順 AWSで手順を実現する技術 Microsoft Azureで手順を実現する技術 1 ライブラリをインストールしたコンテナイメージをアップロードする ライブラリをインストールしたコンテナイメージをオンプレミス環境で作成し、Amazon ECR(Elastic Container Registry)へpushする ライブラリをインストールしたコンテナイメージをオンプレミス環境で作成し、Azure Container Registryへpushする 2 モデルをアップロードし、前処理・モデル・後処理を呼び出す推論コードを書き換える Amazon S3にモデルをアップロードし、Amazon SageMakerのノートブックインスタンス上で推論コードを書き換える Azure MLのノートブックインスタンス上にモデルをアップロードし、推論コードを書き換える 3 コンテナイメージ・モデル・推論コードを指定しコンテナを立ち上げる Amazon SageMakerのノートブックインスタンス上でコンテナイメージ・モデル・推論コードを指定する Azure MLのノートブックインスタンス上でコンテナイメージ・モデル・推論コードを指定する Amazon SageMakerでサービングする場合 学習済みの手書き文字認識モデルを、Amazon SageMaker上で自作のコンテナイメージを用いてサービングできるか検証しました。 Amazon SageMaker向けにAWSが提供するscikit-learnのコンテナイメージのDockerfileをGithubからクローンして、コンテナに含めるパッケージ一覧(requirements.txt)を下記の様に変更して必要なライブラリを追加します。 boto3==1.16.4 botocore==1.19.4 Flask==1.1.1 gunicorn==20.0.4 model-archiver==1.0.3 multi-model-server==1.1.1 numpy==1.19.2 pandas==1.1.3 psutil==5.7.2 python-dateutil==2.8.1 sagemaker-inference==1.2.0 retrying==1.3.3 sagemaker-containers==2.8.6.post2 sagemaker-inference==1.2.0 sagemaker-training==3.6.2 scikit-learn==0.22.1 scipy==1.4.1 six==1.15.0 pillow==7.0.0 # 行を追加 joblib==1.0.0 # 行を追加 次に、Githubからクローンしたディレクトリで下記を実行して、AWSが提供するscikit-learnのコンテナイメージに、必要なライブラリを追加した新しいコンテナイメージ(preprod-sklearn:0.22-1-cpu-py3)を作成します。 # ベースになるコンテナイメージをビルド $ docker build -t sklearn-base:0.22-1-cpu-py3 -f docker/0.22-1/base/Dockerfile.cpu . Sending build context to Docker daemon 3.872MB Step 1/15 : ARG UBUNTU_VERSION=18.04 … # requirements.txtを含む最終的なコンテナイメージのビルド(preprod-sklearn:0.22-1-cpu-py3の名前のコンテナイメージができる) $ docker build -t preprod-sklearn:0.22-1-cpu-py3 -f docker/0.22-1/final/Dockerfile.cpu . Step 1/27 : FROM sklearn-base:0.22-1-cpu-py3 … 最後に、作成した新しいコンテナイメージをAmazon ECR(Elastic Container Registry)へpushします。 # ECRにアクセスするために認証を実施する。aws_account_id は AWSのアカウントID(数値) $aws ecr get-login-password --profile default | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.ap-northeast-1.amazonaws.com # コンテナイメージをpush $docker push aws_account_id.dkr.ecr.ap-northeast-1.amazonaws.com/preprod-sklearn:0.22-1-cpu-py3 The push refers to repository [aws_account_id.dkr.ecr.ap-northeast-1.amazonaws.com/preprod-sklearn] b435a550234f: Pushed … 0.22-1-cpu-py3: digest: sha256:79d36acf270fb1adfa9f9327ce35e962e1985bc7360f0328b7a188b6016b5b8f size: 4500 最後に、Amazon ECRへpushしたコンテナイメージを、ノートブックインスタンス上のJupyter Notebookから下記のコマンドを呼び出してデプロイします。前処理・後処理・推論用のコードは以前の投稿で示したentry.pyと同一のものを利用できます。 from sagemaker.sklearn.model import SKLearnModel image_uri = 'aws_account_id.dkr.ecr.ap-northeast-1.amazonaws.com/preprod-sklearn:0.22-1-cpu-py3' model = SKLearnModel(model_data=uploaded_model, role=role, framework_version='0.22-1', entry_point='entry.py', image_uri=image_uri) predictor = sklearn_model.deploy(instance_type="ml.c4.xlarge", initial_instance_count=1) # 推論時に必要なエンドポイント名を確認する print(predictor.endpoint_name) # preprod-sklearn-2021-02-02-10-17-34-988などと出力があればサービングが完了している これでサービング完了です。あらためて推論が成功するかを、ノートブックインスタンス上のJupyter Notebookから下記のコマンドを用いて確認します。 import boto3 import json import numpy as np ## 読み込んだ画像データを、モデル側が受け取れる形式に変換 npy = BytesIO() L = img.flatten().shape[0] np.save(npy, img.reshape(1, L)) ByteArr = npy.getvalue() # コンテナ作成時に確認したエンドポイント名を入力 endpoint = “endpoint_name” runtime= boto3.client('sagemaker-runtime') response = runtime.invoke_endpoint( EndpointName=endpoint, ContentType='application/x-npy', Accept = 'application/json', Body=ByteArr ) prediced_value = json.load(response['Body']) print("Predicted value for {} is {}".format(filename, prediced_value)) # Predicted value for x_test_50.jpeg is 6と返答が返ってくることを確認する これで動作検証も完了し、サービングが成功したことを確認できました。以上の検証結果から、Amazon SageMakerでは「パブリッククラウドが提供するコンテナイメージを利用せず、オンプレミス環境で必要なライブラリを含んだコンテナイメージを作成して、デプロイした後に、前処理・モデル・後処理を追加する」ことが可能であることを確認できました。 Azure MLでサービングする場合 学習済みの手書き文字認識モデルを、Azure ML上で自作のコンテナイメージを用いてサービングできるか検証しました。 ライブラリを下記のDockerfileの例に沿って追記します1。 FROM ubuntu:16.04 ARG CONDA_VERSION=4.7.12 ARG PYTHON_VERSION=3.7 ARG AZUREML_SDK_VERSION=1.13.0 ARG INFERENCE_SCHEMA_VERSION=1.1.0 ENV LANG=C.UTF-8 LC_ALL=C.UTF-8 ENV PATH /opt/miniconda/bin:$PATH ENV DEBIAN_FRONTEND=noninteractive RUN apt-get update --fix-missing && \ apt-get install -y wget bzip2 && \ apt-get install -y fuse && \ apt-get clean -y && \ rm -rf /var/lib/apt/lists/* RUN useradd --create-home dockeruser WORKDIR /home/dockeruser USER dockeruser RUN wget --quiet https://repo.anaconda.com/miniconda/Miniconda3-${CONDA_VERSION}-Linux-x86_64.sh -O ~/miniconda.sh && \ /bin/bash ~/miniconda.sh -b -p ~/miniconda && \ rm ~/miniconda.sh && \ ~/miniconda/bin/conda clean -tipsy ENV PATH="/home/dockeruser/miniconda/bin/:${PATH}" RUN conda install -y conda=${CONDA_VERSION} python=${PYTHON_VERSION} numpy==1.19.2 scikit-learn==0.23.2 pillow==7.0.0 joblib==1.0.0 && \ # モデル・推論に必要なライブラリを追記 pip install azureml-defaults==${AZUREML_SDK_VERSION} inference-schema==${INFERENCE_SCHEMA_VERSION} &&\ conda clean -aqy && \ rm -rf ~/miniconda/pkgs && \ find ~/miniconda/ -type d -name __pycache__ -prune -exec rm -rf {} \; 次に、上記のDockerfileをビルドして必要なライブラリを追加した新しいコンテナイメージ(ossset:v2)を作成して、Azure Container Registry(osssetmlregistry)をpushします。Pushする前にAzureのCLIのインストールとAzure Container Registryの作成を事前に行うことに注意してください。 # Azure CLIからAzure環境へログイン $ az login # 認証するためのwebリンクとパスワードが表示されるので、webリンクにアクセスしてパスワードを入力する # Azure Container Registryへログインする $ az acr login --name osssetmlregistry # Dockerfileをビルドし、Azure Container Registryへpush $ sudo az acr build --image ossset:v2 --registry osssetmlregistry --file Dockerfile . Step 1/15 : ARG UBUNTU_VERSION=18.04 … 最後に、Azure Container Registryへpushしたコンテナイメージを、ノートブックインスタンス上のJupyter Notebookから下記のコマンドを呼び出してデプロイします。前処理・後処理・推論用のコードは以前の投稿に示したscore.pyと同一の下記コードを利用可能です。推論用のコンテナとして動作させるためのオプション(inferencing_stack_version)が別途必要であることと、自作のコンテナイメージを作成する際にインストールしたanacondaを優先して利用するためにAzure Machine Learningのanacondaの設定を無効にする必要があることに注意してください。 from azureml.core.environment import Environment from azureml.core.model import InferenceConfig from azureml.core.webservice import AciWebservice, Webservice # 環境を定義 ossc_byoc = Environment(name="ossset-v2") # デプロイしたコンテナイメージの場所を指定 ossc_byoc.docker.enabled = True ossc_byoc.docker.base_image = "hashmlregistry.azurecr.io/ossset:v2" # 推論用のコンテナとして動作させるために必要なオプションを追加 ossc_byoc.inferencing_stack_version='latest' # コンテナイメージ作成時にインストールしたanacondaを優先して利用するために、Azure Machine Learningのcondaを無効にする ossc_byoc.python.user_managed_dependencies = True inference_config = InferenceConfig(entry_script="score.py", environment=ossc_byoc) deployment_config = AciWebservice.deploy_configuration(cpu_cores = 1, memory_gb = 1) model = Model(ws, name='hash-mnist-v2') service = Model.deploy(ws, 'hash-mnist-second', [model], inference_config, deployment_config) service.wait_for_deployment(True) print(service.state) print("scoring URI: " + service.scoring_uri) # 下記の様にコマンドが返ってくることを確認する # Running............................................................................ # Succeeded # ACI service creation operation finished, operation "Succeeded" # Healthy # scoring URI: http://7032b584-13d9-4bcb-a096-9fe0d9dc4941.japaneast.azurecontainer.io/score これでサービング完了です。推論が成功することを、上記のscoring URIおよび以前の投稿に示した下記のコード例を利用して確認できます。 $ curl -F file=@x_test_30.jpeg http://7032b584-13d9-4bcb-a096-9fe0d9dc4941.japaneast.azurecontainer.io:5000/predict { "Content-Type": "application/json", "number": "3" } $ curl -F file=@x_test_60.jpeg 7032b584-13d9-4bcb-a096-9fe0d9dc4941.japaneast.azurecontainer.io:5000/predict { "Content-Type": "application/json", "number": "6" } 以上の検証結果から、Azure Machine Learningでは「パブリッククラウドが提供するコンテナイメージを利用せず、オンプレミス環境で必要なライブラリを含んだコンテナイメージを作成して、デプロイした後に、前処理・モデル・後処理を追加する」ことが可能であることを確認できました。 検証結果の考察 今回の検証を通して、「パブリッククラウドが提供するコンテナイメージを利用せず、オンプレミス環境で必要なライブラリを含んだコンテナイメージを作成して、デプロイした後に、前処理・モデル・後処理を追加する」ことは、Amazon SageMakerとAzure MLの両方で可能であることがわかりました。 この手法は、ライブラリの更新と、モデルや前処理・後処理の更新で明確に役割を分けることができることが利点です。Amazon SageMakerとAzure MLの比較の観点では、ライブラリの更新について、ライブラリの種類やバージョンを別ファイルで明確に分けるAmazon SageMakerの方が、バージョンの間違いなどのミスが起こりづらいと考えられます。 また、入力データ・出力データの型についても、Amazon SageMakerはユーザが定義できる点から、より柔軟に対応できるといえます。 おわりに 次回の投稿において、オンプレミス環境でライブラリ・前処理・モデル・後処理を含んだコンテナイメージを作成しデプロイするパターンについて、AWS FargateとAzure Container Instanceで実証し両者の違いを比較した結果を解説します。 Anacondaレポジトリに接続してMinicondaをダウンロードするため、大規模な商用利用などに用いる際は有償ライセンスが必要な方法です(参考URL: https://www.anaconda.com/terms-of-service)。 ↩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

作りながら覚えるTerraform入門(7) - RDS編

作りながら覚えるTerraform入門シリーズの第7回です。 今回はRDSをマルチAZ構成で構築していきます。DBエンジンはMySQL8.0で進めていきます。 作りながら覚えるTerraform入門シリーズ インストールと初期設定 基本編 VPC編 EC2編 Route53 + ACM編 ELB編 RDS編 => 今回はコチラ 今回の学習ポイントは・・・ 変更を無視するignore_changesというlifecycleが登場しますが、RDSを構築する上でのAWS観点でのポイントがいくつかあると思いますので、参考になれば嬉しいです! サブネットグループの作成 DBインスタンスを作成する前に○○グループを順番に作成していきましょう。 まずは、サブネットグループを作成します。 rds.tfを作成して、以下のコードを貼り付けます。 rds.tf ################################ # RDS ################################ # Subnet group resource "aws_db_subnet_group" "subnet" { name = "${var.prefix}-db-subnet" subnet_ids = [ aws_subnet.private_subnet_1a.id, aws_subnet.private_subnet_1c.id ] } これはプライベートサブネットのIDを指定しているだけなのでシンプルですね。 パラメータグループの作成 続いて、パラメータグループを作成します。 rds.tfに以下のコードを追加します。 rds.tf # Parameter group resource "aws_db_parameter_group" "mysql" { name = "${var.prefix}-parameter-group" family = "mysql8.0" parameter { name = "general_log" value = "1" apply_method = "immediate" } parameter { name = "slow_query_log" value = "1" apply_method = "immediate" } parameter { name = "long_query_time" value = "0" apply_method = "immediate" } parameter { name = "log_output" value = "FILE" apply_method = "immediate" } } パラメータグループ自体の作成はファミリーを指定するくらいなので難しくありませんが、デフォルトのパラメータのままだとエラーログ以外が出力されないので、一部パラメータを修正しています。 パラメータ 説明 general_log 一般クエリログの出力 slow_query_log スロークエリログの出力 long_query_time スロークエリログを出力する秒数のしきい値   log_output 出力の出力先 general_logとslow_query_logは「1」を設定してログが出力されるようにしています。 long_query_timeは「0秒」にすることで、重たいクエリを実行せずともログが出力されることを確認できるようにしています。本来は、時間のかかっているクエリを特定するために出力するログですが、ここでは単に「ログが出力されること」の動作確認を行うことを目的としています。 log_outputは「FILE」に変更しています。デフォルトは「TABLE」に書き込まれます。 「TABLE」のままであってもコンソール画面からであれば一般クエリログ、スロークエリログ、エラーログを確認できますが、RDS作成時に設定するCloudWatch Logsへのエクスポートができるよう「FILE」に変更しています(TABLEのままだとエクスポートを有効化してもCloudWatch Logsへ転送されません) 整理すると、 すべてのパラメータがデフォルトのままでもエラーログだけはコンソール画面から確認できる general_log slow_query_logを「1」にするとそれぞれのログもコンソール画面から確認できる log_outputをFILEにするとテーブルではなくファイルにログが書き込みされる RDSのログエクスポートを有効にするとファイルとして出力されたログがCloudWatch Logsに転送される ということになります。 このあたりTerraformあまり関係ありませんが、少しわかりにくいと感じたので補足させて頂きました。 それぞれのパラメータのapply_methodはデフォルトがimmediate「すぐに適用」なので省略しても構いません。 オプショングループの作成 次は、オプショングループを作成します。 rds.tfに以下のコードを追加します。 rds.tf # Option group resource "aws_db_option_group" "mysql" { name = "${var.prefix}-option-group" engine_name = "mysql" major_engine_version = "8.0" option { option_name = "MEMCACHED" port = "11211" vpc_security_group_memberships = [aws_security_group.rds_sg.id] option_settings { name = "BACKLOG_QUEUE_LIMIT" value = "1024" } option_settings { name = "BINDING_PROTOCOL" value = "auto" } } } こちらもオプショングループ自体の作成はDBエンジン、バージョンを指定するくらいなので難しくありませんが、オプションを追加する場合のサンプルとして「memcached」を追加しています。これ自体に意味はありませんし接続確認もしません。 option_settings{}の中は省略してもデフォルト値が採用されるので省略できますが、2つだけサンプルで記載しています。コンソール画面で追加する場合の以下の画面のオプション設定に該当します。 モニタリングロールの作成 次に、モニタリングロールを作成します。 モニタリングロールはRDSの「拡張モニタリング」を有効にする場合に必要なIAMロールで、RDS内部のCPU使用率などのメトリクスをCloudWatch Logsに転送するために利用されます。 コンソール画面から作成した場合、「デフォルト」を選択すると「rds-monitoring-role」の名前で自動的にIAMロールが作成されるので、すでに存在しているかもしれません。 ここでは「rds-enhanced-monitoring-role」の名前で新規に作成します。 iam.tfに以下のコードを追加します。 iam.tf data "aws_iam_policy" "rds_monitoring_role" { arn = "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole" } data "aws_iam_policy_document" "rds_monitoring_role" { statement { actions = ["sts:AssumeRole"] principals { type = "Service" identifiers = ["monitoring.rds.amazonaws.com"] } } } resource "aws_iam_role" "rds_monitoring_role" { name = "rds-enhanced-monitoring-role" assume_role_policy = data.aws_iam_policy_document.rds_monitoring_role.json } resource "aws_iam_role_policy_attachment" "rds_monitoring_role" { role = aws_iam_role.rds_monitoring_role.name policy_arn = data.aws_iam_policy.rds_monitoring_role.arn } やっていることはEC2編の「IAMロールの作成」と変わりありません。「AmazonRDSEnhancedMonitoringRole」の管理ポリシーをデータソースを使って参照しアタッチしています。 DBインスタンスの作成 最後に、DBインスタンスを作成します。 rds.tfに以下のコードを追加します。 rds.tf # DB Instance resource "aws_db_instance" "mysql" { engine = "mysql" engine_version = "8.0.20" license_model = "general-public-license" identifier = "${var.prefix}-db-instance" username = "admin" password = "password" instance_class = "db.t3.medium" storage_type = "gp2" allocated_storage = 20 max_allocated_storage = 100 multi_az = true db_subnet_group_name = aws_db_subnet_group.subnet.name publicly_accessible = false vpc_security_group_ids = [aws_security_group.rds_sg.id] port = 3306 iam_database_authentication_enabled = false name = "cloud" parameter_group_name = aws_db_parameter_group.mysql.name option_group_name = aws_db_option_group.mysql.name backup_retention_period = 7 backup_window = "19:00-20:00" copy_tags_to_snapshot = true storage_encrypted = true performance_insights_enabled = true performance_insights_retention_period = 7 monitoring_interval = 60 monitoring_role_arn = aws_iam_role.rds_monitoring_role.arn enabled_cloudwatch_logs_exports = ["error", "general", "slowquery"] auto_minor_version_upgrade = false maintenance_window = "Sat:20:00-Sat:21:00" deletion_protection = false skip_final_snapshot = true apply_immediately = false tags = { Name = "${var.prefix}-db-instance" } lifecycle { ignore_changes = [password] } } output "rds_endpoint" { description = "The connection endpoint in address:port format." value = aws_db_instance.mysql.endpoint } DBインスタンスはパラメータが多いですが、コンソール画面から作成する場合の並び順に合わせて記述していますので、画面と見比べながら読んでいくとそれほど難しくはないと思います。 username passwordをべた書きしていますが、変数化してterraform.tfvarsを参照させたほうが良いです。ただ、コードから隠蔽してもterraform.tfstateには平文で書き込まれてしまいますので、仮のパスワードを設定しておいてあとで変更するのが良さそうです。lifecycleブロックのignore_changesでは、Terraform管理下からpasswordを除外して、パスワードが変更されても差分検知されないようにしています。 instance_classはt3.mediumにしています。 パフォーマンスインサイトを有効にするには一定サイズ以上にする必要があるのでt3.mediumを選択しています。 multi_az = trueを指定してマルチAZ構成にしています。 シングル構成にする場合はfalseにして、availability_zoneでAZを指定できます。 multi_az = false availability_zone = "ap-northeast-1a" enabled_cloudwatch_logs_exportsでは「エラーログ」「一般クエリログ」「スロークエリログ」をCloudWatch Logsにエクスポートするようにしています。繰り返しになりますが、前述のパラメータグループでログ出力を有効化し、かつ、log_outputを「FILE」にしておく必要があります。 skip_final_snapshotはDBインスタンスを削除する時にスナップショットを取得するかどうかの設定です。もしtrueにして取得する場合はfinal_snapshot_identifierのパラメータも合わせて指定する必要があります。 outputブロックではDBインスタンスのエンドポイントを出力させています。 今回の構成では本番環境を意識して、極力、RDSで利用できる機能を網羅できるような形にしています。(本来は削除保護も有効にすべきですが)マルチAZでかつ、db.t3.mediumにしているのでやや高額になりますので注意しましょう。 db.t3.microで十分な場合はパフォーマンスインサイトを無効にすればOKですので、以下のように修正してください。 rds.tf # サイズはt3.micro instance_class = "db.t3.micro" # シングルAZ構成 multi_az = false availability_zone = "ap-northeast-1a" # パフォーマンスインサイトは無効(コメントアウト or 削除) # performance_insights_enabled = true # performance_insights_retention_period = 7 それでは、terraform applyを実行して、もろもろ作成されていることを確認しましょう。 作成できたら、EC2からmysqlコマンドで接続できることを確認します。 mysql -h cloud02-db-instance.cnio2sb0qm8v.ap-northeast-1.rds.amazonaws.com -u admin -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 23 Server version: 8.0.20 Source distribution Copyright (c) 2000, 2021, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show databases; +--------------------+ | Database | +--------------------+ | cloud | | information_schema | | innodb_memcache | | mysql | | performance_schema | | test | +--------------------+ 6 rows in set (0.00 sec) mysql> exit また、CloudWatchのロググループを開いて、ログが保存されていることを確認しましょう。 /aws/rds/instance/<db_instance_identifier>/<log_type>が各種ログのエクスポートで、RDSOSMetricsがCPU使用率などの拡張モニタリングのログになります。 今回は以上です。 これまで作成したリソースは不要になった時点でdestoryしておきましょう。くれぐれも高額なRDSを起動しっぱなしにしないようにだけご注意ください。CloudWatchのロググループは自動的に削除されないので手動で削除してください。 terraform destroy -auto-approve まとめ 作りながら覚えるTerraform入門シリーズはひとまず終了ですが、また少し追記するかもしれません。 Terraformには Modules や Workspaces など、まだまだ便利な機能が他にもありますが、今回使用した機能だけでも十分にInfrastructure as Code(IaC)を体験できると思います。 まだまだ学習中の身ですが、悩める初学者の皆さんの参考になれば幸いです。 参考リンク RDSのMySQL/MariaDBでログをCloudWatch Logsへ出力可能になりました 拡張モニタリングの使用 ignore_changes
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Vue.jsのサイトをAWS S3にCodePiplineで自動デプロイしてみた

今回は最近Vue.jsを始めたのでサイト公開にかかる固定費を安く抑えようとAWS S3のWebサイトホスティング機能を使います。あと自動デプロイもしたかったのでAWSのCodePiplineを使います。構成は下図の通りです。 Vue.jsのプロジェクトの配下にbuildspec.ymlを配置します。 このファイルでCodeBuildがファイルに基づきビルドを実行してくれます。インデントをきちんとしていないとビルドの時にエラーが出ます。 buildspec.yml version: 0.2 phases: pre_build: commands: - if [ -e /tmp/node_modules.tar ]; then tar xf /tmp/node_modules.tar; fi - npm install build: commands: - npm run build post_build: commands: - tar cf /tmp/node_modules.tar node_modules artifacts: files: - '**/*' base-directory: dist cache: paths: - /tmp/node_modules.tar S3の設定 まず、バケットを任意の名前で作成します。そしてプロパティ欄に静的ウェブサイトホスティングを有効化しましょう。 次にアクセス許可の欄でブロックパブリックアクセスをオフにしましょう。 あと、バケットポリシーを編集しましょう。バケット名は自分のバケット名に直しましょう。 { "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadForGetBucketObjects", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::バケット名/*" } ] } CodePipelineの作成 任意の名前でパイプライン名を作成してください。 ソースプロバイダーにGithubを選択して、「Githubに接続する」をクリックしての自分のリポジトリと連携します。 プロバイダービルドを AWS CodeBuildを選択して、任意の名前でプロジェクト名を作成してください。 デプロイプロバイダーにAmazon S3を選択して、保存したいバケット名を選択し、バケットは空欄にしておいて、デプロイする前にファイルを抽出するにチェックを入れます。 そして実際にGithubにpushすると自動でデプロイされているのがわかります。デプロイが成功したらS3の静的ウェブサイトホスティングに書かれているURLを開くと自分のサイトが公開されます!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2って何?から始めるAWS

こんにちわ!Qiita初投稿です。 現在、「AWS上にDjangoで開発したwebアプリをgunicornとNginxを使ってデプロイした」という地点にいます。 まだまだエンジニア初学者ですので、Qiitaの記事にはいつもめちゃめちゃ助けて頂いています。 げ、MarkDown記法とわ?というレベルのブログ素人でもありますので、しばらくは僕と同じ目線くらいの初学者向けに「賢く、超簡単に」とモットーに投稿していきたいと思います。 まずはAWSのお話にて。 4月に社内の検討会で「作ったwebアプリをAWS上で立ち上げます」と言い放った後から始めましたが、「ぜ、全然わからん…」という不毛なスタートからようやく軌道に乗りました(泣)Djangoも本読んで覚えたままにスタートしたので幾度となく壁に突き当たりましたが「やいやいAWSさん、あなたもまた色々壁を用意しましたね」と泣きたくなるも大人なので泣かない日々です。 最初はとにかく名前です。VPCやAMIといった3文字の用語が多いこと。。論理演算子やK-分割交差検証やら日本語も大概でしたが、英語も割と大概じゃないか。。私は「演算子」の時点で「ん?」と序盤からつまづいたタイプです(汗) そこで、まずはAWSでwebアプリをインターネットに公開する上で、大切なAWS用語をこれ以上ないほど簡単に説明します。 初めに、AWSとは AWS(Amazon Web Service) AWSを端的に言うと「クラウドサーバーをサブスクで使えるサービス」です。 Elastic(伸縮自在)という言葉をあちこちに見かけますが、自前でサーバーを購入して運用するオンプレミスとは違い、まさにマシンパワーやストレージ容量などが使い方に応じて伸縮してくれるイメージで、いざ使うとオンプレミスとは比較にならないほど優秀だということがよーくわかります。 大量のアクセスがある時はその分だけパワーを用意し、使わない時は最小限に、という感じで、使った分だけの従量課金になります。その上、やろうと思えばコマンドライン操作無しでも大抵の事ができます。 オンプレミスが食材や調理場の手配から値段交渉までイチからやるのに対し、クラウドサーバーはまさに最新の調理器具がすべて揃った調理場が今すぐ使えて、コストも最適化されているので納得!という感じです。 そして更に!「1年間の無料枠」というハンパではない大盤振る舞いがあります。私もドメインの取得以外は現状0円です。 もちろん使い放題ではありません。ここまでは1年無料ですよ、という利用枠がありますが、対象の仮想サーバーを1年起動してても無料です。 VPC AWSのアカウント登録をした後、最初に「VPC」を設定すると思います。 VPCとは、virtual private cloud(仮想プライベートクラウド)の略です。 これは、AWSという広大な仮想空間のなかで、「ここはうちのエリアです」と仮想的な領域を決定するような感じです。 リージョン AWSは世界中の色んな場所にデータセンターがあります。 日本は東京と大阪にあります。このデータセンターがある物理的なエリアをリージョンと呼びます。 「東京リージョン」「大阪リージョン」といった感じです。 アベイラビリティゾーン(AZ) リージョンの中では、リスク分散などの為にデータセンターを3箇所や4箇所に分けて設置しています。東京は4箇所です。 「東京リージョンには4つのアベイラビリティゾーンがある」といった感じです。 クリック1つで、どのゾーンに仮想サーバーを構築するかを選択できます。 サブネット サブネットはあのサブネットです。AWS上ではCIDR表記(/24など)で設定します。 ちなみにサブネットは、現実世界で言えば「この部分のエリアにはこれを建てる」という枠を決める感じです。 AWSにはパブリックサブネットとプライベートサブネットの2つがあり、パブリックはインターネットと接続するエリア、プライベートはそうでないエリアです。 EC2 Elastic Compute Cloud(Cが2つでEC2) これがAWSにおける仮想サーバーです。 出ましたねElastic! EC2の設定画面で、OS何にする?ストレージ容量は?など決めていきます。 すごい柔軟で、汎用用途向けや、データベース向け、GPU使用タイプなど様々な種類から仮想サーバーを構築できます。HDDにするかSSDにするかなどもクリック操作で構築できちゃうんです。スマート! ちなみに、EC2を設定した後はAWSのコンソール画面からSSH接続できます。もちろんご自身のPCからTeratermなどのツールを使っても可能です。 インターネットゲートウェイ これが、EC2のパブリックサブネットとインターネットを接続してくれるゲートウェイです。 簡単な設定をした後、パブリックサブネットにアタッチするだけです。 RDS これは普通にリレーショナルデータベースサービスです。 アプリはパブリックサブネット、DBはプライベートサブネットに構築します。 ElasticIPアドレス また来ましたねElastic! これが固定IPアドレスです。EC2は、再起動などするとパブリックIPアドレスが変わってしまいます。 そのため、インターネットに公開する場合はElasticIPアドレスを割り当ててあげます。 Route53 あとはEC2でwebサーバーなどを設定すればインターネットに公開可能ですが、ドメイン名をつける場合はRoute53を使います。 Route53とは、AWSにおけるDNS(ドメインネームシステム)です。設定めちゃ簡単。。 空いてるドメイン名の検索や購入もすぐできますし、ElasticIPアドレスにドメイン名を割り当てるのもすぐに終わります。 初学者向けに、DNSとは要はグローバルIPアドレスに「〇〇.com」といったURLを割り当ててくれるシステムです。もちろんそれ以外の機能も担っています。 初めてなので、今回は以上でござる。 MarkDown記法もわからんかった奴ですが、これからも勉強継続します。 ネットは広大だわ。。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

lambda にnodeコードを叩いて地盤のnodeのバージョンを確認したい

lambda にnodeコードを叩いて地盤のnodeのバージョンを確認したい class Work(models.Model): title = models.CharField('インシデントNO.', max_length=100) created = models.DateField('作成日時') description = models.TextField('説明') subtitle = models.TextField('補足', null=False) def __str__(self): return self.title
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

作りながら覚えるTerraform入門(6) - ELB編

作りながら覚えるTerraform入門シリーズの第6回です。 今回はロードバランサを作成して独自ドメインでHTTPS接続できるようにしていきます。 作りながら覚えるTerraform入門シリーズ インストールと初期設定 基本編 VPC編 EC2編 Route53 + ACM編 ELB編 => 今回はコチラ RDS編 今回の学習ポイントは・・・ Terraform観点だともう基本的なポイントはご紹介したので特にないのですが、強いて挙げれば toset関数 for_each でしょうか。 あと、これまでに作成してきたリソースが組み合わさって繋がるので最後の接続確認が気持ちいい。笑 ELBの作成 まず、アプリケーションロードバランサ(ALB)を作成します。 elb.tfを作成して、以下のコードを貼り付けます。 elb.tf ################################ # ELB ################################ # ELB resource "aws_lb" "alb" { name = "${var.prefix}-alb" load_balancer_type = "application" internal = false idle_timeout = 60 enable_deletion_protection = false subnets = [ aws_subnet.public_subnet_1a.id, aws_subnet.public_subnet_1c.id ] security_groups = [ aws_security_group.elb_sg.id ] } aws_lbでロードバランサを作成します。 load_balancer_typeは現時点で次の3種類があります。 application network gateway コンソール画面で作成するときに見るアレですね。 ちなみに、aws_elbを使うとClassic Load Balancerを作成できます。紛らわしいので念のため。 インターネット向けのELBを作成する場合はinternal = falseにします。 subnetsにはパブリックサブネットのIDを、security_groupsには事前に作成してあるELB向けのセキュリティグループのIDを指定します。 ターゲットグループの作成 次に、ターゲットグループを作成します。 elb.tfに以下のコードを追加します。 elb.tf # Target group resource "aws_lb_target_group" "alb_tg" { name = "${var.prefix}-alb-tg" target_type = "ip" vpc_id = aws_vpc.vpc.id port = 80 protocol = "HTTP" deregistration_delay = 300 health_check { protocol = "HTTP" path = "/" port = "traffic-port" healthy_threshold = 5 unhealthy_threshold = 2 timeout = 5 interval = 30 matcher = 200 } } resource "aws_lb_target_group_attachment" "alb_tg" { for_each = toset(["10.0.11.11", "10.0.12.11"]) target_group_arn = aws_lb_target_group.alb_tg.arn target_id = each.key } まず、aws_lb_target_groupでターゲットグループを作成します。 target_typeはipにしていますが、インスタンスIDを使う場合はinstanceを指定します。(デフォルトがinstanceなので省略できます) ターゲットグループにインスタンスを登録するにはaws_lb_target_group_attachmentで関連付けます。ここが少しハマったのですが、、 直感的には、target_idには配列でIPを渡したいのですが、文字列にせよと怒られます。 Error: Incorrect attribute value type │ │ on elb.tf line 52, in resource "aws_lb_target_group_attachment" "alb_tg": │ 52: target_id = ["10.0.11.11", "10.0.12.11"] │ │ Inappropriate value for attribute "target_id": string required. for_eachを使って配列を回そうとしても、mapかsetでないとダメといわれます。 for_eachには配列を渡すことができないんです。。 Error: Invalid for_each argument │ │ on elb.tf line 50, in resource "aws_lb_target_group_attachment" "alb_tg": │ 50: for_each = ["10.0.11.11", "10.0.12.11"] │ │ The given "for_each" argument value is unsuitable: the "for_each" argument must be a map, or set of strings, and you have provided a value of type tuple. ということで、toset 関数を使って、set型に変換しています。 恥ずかしながら、setという型を初めて知ったのですが、 重複した要素がない 要素に順番がない という特徴があるみたいです。tosetで変換すると重複が取り除かれます。 terraform console > toset(["10.0.11.11", "10.0.12.11", "10.0.12.11"]) toset([ "10.0.11.11", "10.0.12.11", ]) for_eachで渡した配列もどきのリストはeach.keyで読み込むことができます。 今回は関係ありませんが、もし、mapを渡した場合はeach.keyとeach.valueでキーと値をそれぞれ読み込むことができます。 リスナーの作成 続いて、リスナーを作成します。 elb.tfに以下のコードを追加します。 elb.tf # Listener resource "aws_lb_listener" "http" { load_balancer_arn = aws_lb.alb.arn port = "80" protocol = "HTTP" default_action { type = "redirect" # forwad / fixed-response / redirect redirect { protocol = "HTTPS" port = "443" host = "#{host}" path = "/#{path}" query = "#{query}" status_code = "HTTP_301" } } } resource "aws_lb_listener" "https" { load_balancer_arn = aws_lb.alb.arn port = "443" protocol = "HTTPS" certificate_arn = aws_acm_certificate.public.arn ssl_policy = "ELBSecurityPolicy-2016-08" default_action { type = "forward" target_group_arn = aws_lb_target_group.alb_tg.arn } } aws_lb_listenerでHTTPとHTTPSのリスナーを追加しています。 portとprotocolの組み合わせで受付ポートとプロトコルを、default_actionでアクションを定義します。 HTTPのリスナーではdefault_actionのタイプをredirectにして、HTTPSにリダイレクトするようにしています。redirect {}の中にはリダイレクト時に書き換える内容を指定します。 protocolがHTTP → HTTPSに、portが80 → 443に書き換えられますが、残りのホスト名、パス、クエリは変更を加えずデフォルトを利用するという意味になります。status_code = "HTTP_301"は「完全に移動」を表します。 コンソール画面で以下のように入力した場合と同じですね。 HTTPSのリスナーではdefault_actionのタイプをforwardにして、先に作成したターゲットグループに転送するようにしています。また、前回のRoute53 + ACM編で作成したパブリック証明書をここで関連付けします。 エイリアスレコードの登録 最後に独自ドメインとELBを紐付けるエイリアスレコードを登録します。 route53.tfに追加したくなるかもしれませんが、ここは関連するリソースのライフサイクルに合わせてelb.tfに追加します。 elb.tf ################################ # Route 53 (Alias record) ################################ resource "aws_route53_record" "alb" { name = "www.${aws_route53_zone.public.name}" zone_id = aws_route53_zone.public.zone_id type = "A" alias { name = aws_lb.alb.dns_name zone_id = aws_lb.alb.zone_id evaluate_target_health = true } } レコードの名前は独自ドメインの頭にwww.を付けた形にしていますが、ACMをワイルドカード証明書にしてあるのでapp.とかでも構いませんし、何も付け加えずにaws_route53_zone.public.nameとしてネイキッドドメインで接続する形にしてもOKです。ネイキッドドメインを登録できるのは、エイリアスレコードならではの特徴ですね。 ELB編のコードは以上です。 terraform applyを実行して、もろもろ作成されていることを確認しましょう。 問題なければ独自ドメインでアクセスしてみましょう。 鍵アイコンをクリックして証明書を確認するとAmazon発行のものであることがわかります。 また、ELBには2台のEC2がぶら下がっているので、ブラウザを更新するたびにweb-01とweb-02が交互に切り替わるかと思います。(ラウンドロビン) ブラウザのURLをhttpに変更してもリダイレクトされることが確認できますが、curlコマンドでも確認することができます。Locationを見るとプロトコルとポートが書き換わっていることがわかります。 curl -I http://www.example.com HTTP/1.1 301 Moved Permanently Server: awselb/2.0 Date: Wed, 09 Jun 2021 04:59:29 GMT Content-Type: text/html Content-Length: 134 Connection: keep-alive Location: https://www.example.com:443/ 今回は以上です。次回はRDS編ということで、MySQLのRDSをマルチAZ構成で構築してみたいと思います! 参考リンク toset Function [新機能]Webサーバでの実装不要!ALBだけでリダイレクト出来るようになりました! Amazon Route 53のALIASレコード利用のススメ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon Cognitoについて

Amazon Cognitoとは 一言で言うと、アプリケーションの認証・認可を提供したサービスです。 以下AWS公式説明引用。 Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションの認証、許可、ユーザー管理に対応しています。ユーザーは、ユーザー名とパスワードを使用して直接サインインするか、Facebook、Amazon、Google、Apple などのサードパーティーを通じてサインインできます。 Cognitoでできること 大きく分けるとサインアップ・サインイン機能の提供、ユーザのアクセスコントロールの管理が行えます。 「Email+パスワード」や「ID+パスワード」などの一般的なサインアップ・サインインだけではなく、ソーシャルIDプロバイダやエンタープライズIDプロバイダを利用してのサインインも利用できます。 機能 ユーザプール・IDプールを用いたユーザの認証認可管理が主な機能です。 ユーザプール Cognitoで認証したユーザのディレクトリ。 認証したユーザにはトークンが発行され、このトークンで認証処理が行われる。 Oauth2.0,OpenID Connect,SAML2.0などのアクセス管理標準をサポートする。 IDプール ユーザに対する認可の管理。 ユーザ一意のIDを作成し、IDプロバイダに連携させられる。 IAMroleと紐づけて、他AWSサービスへのアクセスの認可を管理する。 認証したユーザだけではなく、未認証ユーザ(ゲストユーザ)にも一時認証を提供できる。 ユーザプールとIDプールは同時に使用することも、別々に使用することもできます。 AWS公式が示している「同時に使用する場合の一般的なシナリオ」は以下です。 最初のステップでは、アプリのユーザーはユーザープールを介してサインインし、認証が成功するとユーザープールトークンを受け取ります。 次に、ID プールを使用して AWS 認証情報のユーザープールトークンを交換します。 最後に、アプリのユーザーはこれらの AWS 認証情報を使用して Amazon S3 や DynamoDB などの他の AWS サービスにアクセスできるようになります。 Amazon Cognito Sync ユーザに対してデータストレージを提供し、異なるデバイス間でもユーザデータを同期できるサービスです。 公式説明参照 Amazon Cognito Sync は、アプリケーション関連のユーザーデータのデバイス間の同期を有効にする、AWS サービスとクライアントライブラリです。これを使用して、独自のバックエンドを必要とせずにモバイルデバイスとウェブ間でユーザープロファイルデータを同期できます。クライアントライブラリはローカルにデータをキャッシュするため、アプリはデバイスの接続状態にかかわらず、データを読み書きすることができます。デバイスがオンラインのときは、データを同期し、プッシュ同期を設定すると、アップデートが利用できることが他のデバイスにすぐに通知されます。 同様のサービスとしてAWS AppSyncというものもあります。 AppSyncのほうが高性能の為、新規サービス立ち上げの際にはAppSyncの利用を推奨しているようです。 まとめ ウェブアプリ・モバイルアプリの面倒くさいユーザ管理を任せられる良いサービスだと思います。 特に、モバイルアプリ開発の際はAWS Amplifyとの親和性が高く、使い勝手が良いと思います。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【nuxt.js】S3・CloudFront構成 CodeBuildでのデプロイ自動化

概要 Nuxt.jsで作成したプロジェクトをgulp, CodeBuildを使って自動デプロイする手順をまとめます。 参考URL 以下のURLを参考に、CodeBuildの設定を変更しています。 事前準備 yarnコマンドを使えるようにする 手順 1. gulpのインストール yarn add gulp 今回はローカル環境にyarnを使ってインストール gulpfileで使用しているモジュールを追加 yarn add gulp-awspublish yarn add gulp-cloudfront-invalidate-aws-publish yarn add concurrent-transform 2. gulpfile.jsを作成 gulpfile.jsをプロジェクトのルートディレクトリに作成します。 ここでは、公式ページからコピーして、以下を変更します。 credentialsを削除(CodeBuildのIAMポリシーを使うため不要) deleteOldVersionsをtrueに変更(S3上の古いファイルを削除) headersに'x-amz-acl': 'private'を追加(S3のパブリックアクセスブロックへの対処) const gulp = require('gulp') const awspublish = require('gulp-awspublish') const cloudfront = require('gulp-cloudfront-invalidate-aws-publish') const parallelize = require('concurrent-transform') // https://docs.aws.amazon.com/cli/latest/userguide/cli-environment.html const config = { // Required params: { Bucket: process.env.AWS_BUCKET_NAME, }, // Optional deleteOldVersions: true, // S3上の古いファイルを削除する distribution: process.env.AWS_CLOUDFRONT, // CloudFront distribution ID region: process.env.AWS_DEFAULT_REGION, headers: { /* 'Cache-Control': 'max-age=315360000, no-transform, public', */ 'x-amz-acl': 'private', }, // Sensible Defaults - gitignore these Files and Dirs distDir: 'dist', indexRootPath: true, cacheFileName: '.awspublish', concurrentUploads: 10, wait: true, // wait for CloudFront invalidation to complete (about 30-60 seconds) } gulp.task('deploy', function () { // create a new publisher using S3 options // http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#constructor-property const publisher = awspublish.create(config) let g = gulp.src('./' + config.distDir + '/**') // publisher will add Content-Length, Content-Type and headers specified above // If not specified it will set x-amz-acl to public-read by default g = g.pipe( parallelize(publisher.publish(config.headers), config.concurrentUploads) ) // Invalidate CDN if (config.distribution) { console.log('Configured with CloudFront distribution') g = g.pipe(cloudfront(config)) } else { console.log( 'No CloudFront distribution configured - skipping CDN invalidation' ) } // Delete removed files if (config.deleteOldVersions) { g = g.pipe(publisher.sync()) } // create a cache file to speed up consecutive uploads g = g.pipe(publisher.cache()) // print upload updates to console g = g.pipe(awspublish.reporter()) return g }) 3. ソースを設定 使用中のリポジトリに合わせて、CodePipelineで設定します。 ここでは説明を省略します。 4. buildspec.ymlを作成 プロジェクトファイルのルートディレクトリでbuildspec.ymlを作成。 参考URLのまま(Ubuntuのイメージを利用)だと、うまくできなかったため、AmazonLinuxを利用するように変更しています。 Node.jsのバージョンは10以上が推奨されているようです(2021年5月現在) version: 0.2 phases: install: runtime-versions: nodejs: 12 pre_build: commands: - echo 'Start pre_build phase' - yum update -y - yum -y install wget - wget https://dl.yarnpkg.com/rpm/yarn.repo -O /etc/yum.repos.d/yarn.repo - curl --silent --location https://rpm.nodesource.com/setup_12.x | bash - - yum install yarn - yarn install build: commands: - echo 'Start build phase' - yarn generate post_build: commands: - echo 'Start post_build phase' - ./node_modules/.bin/gulp deploy 5. CodePipeline、CodeBuildの設定 環境を以下のように設定します。 CodeBuildの環境変数には、 - DEPLOY_ENV:S3 - AWS_CLOUDFRONT:デプロイ先CloudFrontディストリビューションのID - AWS_BUCKET_NAME:デプロイ先S3のバケット名 を設定します。 https://storage.googleapis.com/scrapbox-file-distribute/606bf940c44edb001cb16be6/8d8723e4869517bbbd86993cd958082b?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=file-upload%40scrapbox-server.iam.gserviceaccount.com%2F20210608%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20210608T132746Z&X-Goog-Expires=300&X-Goog-SignedHeaders=host&X-Goog-Signature=662d14f2707de91301a7d7539ae06c9307b031e48d440675b5b2fc3e9fe043e747a552f429c1944bc4dab0c6a6a8e903ec7a6d9f9da481e2e9e53e3233b92cec11dc59c28559673d9b9daf8ba023a523430fb46dc270f22a5ee367c243f46c85d92b259f80d9b5281a542506e69f388056aa8333edcbb2cefa9efe92b50c67852186781c1e4ba485b362a35c4e83787079738e2afce8a573fdef414afbf3ed1cc6a292a5352611a3427956932ea463a50e733e201d839c087b6f4b3d6fcddf66faafe795348071f392fa6222f459024d483457a8de5a4a183f21ad077b8b8bab1e4126855329f389ec1995a6afcdc91cb2156b6ea50db5a14cc285f16e4e7c9e 補足 Codebuildを使う際は、イメージとruntimeの対応を調べておくと良さそうです。 特権付与は必要ないかもしれません。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

クラウドプラクティショナー対策:AWSサービスを調べる

AWSクラウドプラクティショナー試験対策をしていますが、やはりサービスの多さには手を焼いております... Udemyの模擬試験では合格ラインの70%を超えましたが、まだなんとなくで解いていたり、そもそも問題を覚えてしまってたりの部分があります。 AWS初心者向けハンズオンで頻繁に登場したものはなんとなく覚えましたが、登場しなかったものはほとんどAWSの資料、文献でさらっと読んだだけでいまいち把握できてません。 ハンズオン、資料で取りこぼしたAWSサービスについてまとめて調べていきます。 取りこぼし一覧 模擬試験をやってみて取りこぼしを感じたAWSサービスは以下の通り CloudTrail Elastic Beanstalk Trusted Advisor AWS Config AWS Artifact AWS Cost Explorer AWS Organizations AWS簡易見積もりツール TCO計算ツール Fargate Amazon EMR SCP コストと使用状況レポート コスト配分レポート AWSサポート ElastiCache SMS OpsWorks AWS Global Accelerator Cassandra Lightsail AWS Cognito 結構あるな... 各サービスについて 調べつつ、気軽にさわれそうなら多少触ってみる。 目的はクラウドプラクティショナー対策なので1つ1つは軽く済ませる。 CloudTrail アカウントのAPIコールを過去90日分記録し、誰がいつ何をしたか記録してくれる。 デフォルトでオンになってて勝手に記録してくれてるらしい。 触ってみた 証跡を作成、とかいうボタンを発見。S3バケットに保存して90日を超えても保持してくれるらしい。 イベント履歴、から90日分のイベントを表示。 入社が2ヶ月前なので入社後のログ全て見れる、なんか感慨深い。 Elastic Beanstalk AWS Elastic Beanstalk により、開発者は AWS クラウドのアプリケーションを迅速にデプロイし管理することがより簡単になります。開発者は単にそのアプリケーションをアップロードするだけで、Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、Auto-Scaling、およびアプリケーション状態モニタリングといったデプロイの詳細を処理します。 https://aws.amazon.com/jp/elasticbeanstalk/faqs/ インフラはAWSがよしなにやってくれるからアプリに集中できる、ってことらしい。 触ってみた Create Applicationとかいうボタンを発見、よく分からんまま名前とプラットフォームを設定したら何かを作成し始めた。 黒い画面が出てきて、CloudWatch Alarm、EC2の作成、Auto Scalingの設定とかをしてるっぽい、すごい。 やがてアプリケーションのファイルをアップロードをする画面に遷移。 もしかして片付けが面倒?と思ったが心配ご無用、EC2とかも自動で消してくれてる。便利すぎる。 Trusted Advisor コスト最適化、セキュリティ、耐障害性、パフォーマンス、サービスの制限、の5つの観点でアドバイスしてくれるらしい。 使用率の低いEC2があるから勿体無い、S3バケットがグローバルに公開されているから危ない、とか。 AWSサービス全体に対して総合的に浅く広く指摘してくれるかんじかな? 触ってみた ダッシュボードに、コスト最適化、セキュリティ、耐障害性、パフォーマンス、サービスの制限のアイコン、全体的にみやすい。 セキュリティ、サービスの制限、以外はサポートプランをアップグレードしないと利用できないぽい。 AWS Config "リソースの設定を記録して評価"するらしい。 CloudTrailが「人の行動を記録」するのに対し、こちらは「リソースの変更を記録」して、評価もする。 触ってみた ホーム画面に「今すぐ始める」「1-click セットアップ」の2つが、とりあえず1-clickを押してみる。 確認、を押したら勝手にもろもろ作成したのちダッシュボードに遷移。 S3 Bucket、EC2 VPCなどなど各種リソースに「ルール」を追加できるっぽい。 アクセスキーが設定した日数を超えて使用されていないか、VPCのトラフィックが適正であるか、などのルールが用意されていた、自分でも作成できるらしい。 AWS Artifact 第三者による監査レポートをダウンロードできるらしい。 触ってみた レポートの表示、契約の表示がある。 契約の方は4つの契約が確認できる、全部非アクティブの表示。 レポートの方は77のレポートが確認できる、試しに一番上のをダウンロード。 全編英語でよくわからん、教育機関がAWSを利用するときのガイドらしい。 AWS Cost Explorer AWS Cost Explorer の使いやすいインターフェイスでは、AWS のコストと使用量の経時的変化を可視化し、理解しやすい状態で管理できます。 https://aws.amazon.com/jp/aws-cost-management/aws-cost-explorer/ 触ってみた いつものIAMユーザーでアクセスすると、権限がないと言われてしまった。 ルートユーザーで出直したら今度は、初めての利用だから24時間待てと言われた。 AWS Organizations 複数のAWSアカウントを一元管理できるらしい、請求も一括にできる。 触ってみた 組織を作成する、ボタンを発見。 ボタン一発で組織が完成、メール承認を完了するとAWSアカウントの招待が可能になった。 組織の削除は管理アカウントを削除することで行えるらしい、組織の削除もボタン一発。 と思ったら削除できない、組織で作成したアカウントの削除はアカウント作成後7日以降じゃないとだめらしい。 AWS簡易見積もりツール SIMPLE MONTHLY CALCULATORというらしい。 毎月の支払い料金を試算できる。 触ってみた 左側にEC2、S3、CloudFront、RDSなどなどサービス名が並んでいる。 それぞれのサービスごとに使用するリソースを選択できる、試しにEC2のインスタンスを選んでみる。 (関係ないけど400Gbpsのインスタンスを発見、こんなのあるのか、バケモンや...) 適当にぽちぽちして、たっけーって遊べる、楽しい。 TCO計算ツール AWS Pricing Calculatorというらしい、物理さーばとの比較を行える。 AWS 料金計算ツールを使用して AWS のサービスを調べ、AWS を使用するために必要なコストの見積りを作成できます。 https://docs.aws.amazon.com/ja_jp/pricing-calculator/latest/userguide/what-is-pricing-calculator.html 簡易見積もりツールと何が違うのだろう。 触ってみた 見積もりの作成ボタンを発見。 リージョン、サービスを選択すると見積もりが作成された。 ニーズにあった最低コストの構成を探せたりする、簡易見積もりツールよりもさらに手軽な感じがする。 Fargate EC2でコンテナを実行する際の起動タイプの1つだった、サービス名ではない。 EC2でECS使うときにFargateで起動するとコンテナを楽に使えるよ、ということらしい。 Amazon EMR Elastic MapReduceの略、大量のデータを効率よく処理するためのサービス。 クラスタを構築して分散処理するから強力、ってことらしい。 SCP サービス名ではなく、AWS Organizationの機能の1つ。 Service Control Policyの頭文字をとったもので、複数のAWSアカウントに対する権限の制御ができる。 SCP自体は権限を与えるものではなく、「ここまでは許可できる」という境界を設定するもの。 https://qiita.com/mzmz__02/items/8ad282f8e8ef091c8e66 IAMと似ているが、IAMはアカウント内のユーザーに権限を付与するのに対し、SCPはアカウント自体に権限を付与できる境界を示す。 コストと使用状況レポート Cost & Usage Reports 請求情報とコスト管理ダッシュボード、からAWS請求レポートをS3に発行できる。 コスト配分レポート 請求情報とコスト管理ダッシュボード、から詳細な請求レポートをS3に発行できる。 AWSサポート AWS サポートとは、お客様がインフラストラクチャをクラウドで運用できるように技術的な問題に関して支援するものです。お客様は、要件を満たす最適なレベルを選択できます。 https://aws.amazon.com/jp/premiumsupport/faqs/ AWSのアカウントを作った時点でベーシックプランを与えられる。 有料プランは下からデベロッパー、ビジネス、エンタープライズ。 ElastiCache 高スループットかつ低レイテンシーなインメモリデータストアからデータを取得して、大量のデータを扱うアプリケーションを構築したり、既存のアプリケーションのパフォーマンスを改善したりすることが可能です。 https://aws.amazon.com/jp/elasticache/ RAMではなくROMに保存する、からデータの出し入れが速いよってことらしい。 触ってみた 以下の記事を参考に、触ってみる https://qiita.com/leomaro7/items/f031cfdd7d12d5d5ccc5 名前を適当に設定し、クラスターの作成を行う。 ap-northeast-1のaとcにノードが作成された、とりあえず今回はこれで終わり。 SMS AWS Server Migration Serviceの略、仮想マシンをAWSクラウドへの移行を自動化するサービス。 複雑な操作が少ない、ダウンタイムが小さい、なんかが売りらしい。 OpsWorks AWS OpsWorks は、Puppet または Chef を使用して、クラウドエンタープライズでアプリケーションを設定および運用するための設定管理サービスです。 https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/welcome.html PuppetかChefを使って、アプリケーションを動かせる環境一式を自動構築できるらしい。 CloudFormationとElastic Beanstalkの中間の特性、手軽だけど柔軟に変更もきく。 AWS Global Accelerator AWS Global Accelerator は、アマゾン ウェブ サービスのグローバルネットワークインフラを利用して、ユーザーのトラフィックのパフォーマンスを最大 60% 向上させるネットワーキングサービスです。 https://aws.amazon.com/jp/global-accelerator/ 導入するだけでネットワークが低レイテンシーになるらしい。 マルチのオンラインゲーム、通話の品質などに有効。 (もしや、と思ったらまさに導入されてた https://www.youtube.com/watch?v=ftC1Rpi8mtg&t=164s) 触ってみた 以下のサイトでどれくらい改善されるのか簡単に把握できる。 https://speedtest.globalaccelerator.aws/#/ 遠いリージョンのサーバに対してより効果があることがわかった。 Cassandra AWSのサービスの名前ではない Apache Cassandra(アパッチ カサンドラ)は、オープンソースの分散データベース管理システムである。 https://ja.wikipedia.org/wiki/Apache_Cassandra NoSQLデータベース Lightsail Amazon Lightsailは、AWSが提供しているVPS(Virtual Private Server:仮想プライベートサーバー)サービスです。 https://techblog.nhn-techorus.com/archives/14300 触ってみた https://lightsail.aws.amazon.com/ls/webapp/create/instance?region=ap-northeast-1 にアクセス、言語を選択したらロボットのマスコットが出てきた。 適当に設定してインスタンス作成、アイコンと文字がデカくてみやすい、わかりやすい。 Ubuntuを起動、SSHで接続ボタン押すだけ。 インスタンスの削除も簡単、削除のボタンもでかい。 AWS Cognito Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションの認証、許可、ユーザー管理に対応しています。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/what-is-amazon-cognito.html サインインの機能、を簡単に使えるってことらしい。 最近よくみるGoogleアカウントとかサードパーティを通じてのサインインにも対応してる。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS 用語集

AWSを勉強して出てきた用語になります。 オンプレミスとは 自社内でハードウェアやソフトウェア・データを保有・管理。端末が制限されることが多い。 ファイアーウオール(FW)とは 通信を制御する仕組み  ーインバウンド・・・インターネットからサーバーに入る  ーアウトバウンド・・・サーバーからインターネットに出る 通信プロトコルとは 通信の決まり事。メッセージなど相手先に遅れるのは、通信の決まり事があるため簡単に使用ができる。 シームレスとは ITの分野では、サービスやシステム、ソフトウェアなどが複数の要素や複数の異なる提供主体の組み合わせで構成されているとき、利用者側から見てそれぞれの違いを認識・意識せずに一体的に利用できる状態のことをシームレスであるという。 データレイクとは データレイクは、規模にかかわらず、すべての構造化データと非構造化データを保存できる一元化されたリポジトリです。データをそのままの形で保存できるため、データを構造化しておく必要がありません。また、ダッシュボードや可視化、ビッグデータ処理、リアルタイム分析、機械学習など、さまざまなタイプの分析を実行し、的確な意思決定に役立てることができます。 VTLとは VTL(仮想テープライブラリ)」は、ハードディスク(HDD)上に仮想のテープドライブを作り、バックアップを行う方法を指す。企業のデータバックアップでは磁気テープを使用することが、これまで一般的だったが、時間がかかるという難点がある。 IPS/IDS IPS (Intrusion Prevention System)は、不正侵入防止システムである。ネットワークやサーバーを監視し、不正なアクセスを検知して管理者に通知する役割を担うシステムとしてIDS(Intrusion Detection System:不正侵入検知システム)があります。インスタンスまたはリバースプロキシ層に IDS/IPS エージェントを実装することで解決できます。 Design for Failureとは 障害を回避する設計ではなく、障害が発生してもサービスを継続できるように設計しましょう、という考え方になります。 レイテンシーとは レイテンシとはデータ転送における指標のひとつで、転送要求を出してから実際にデータが送られてくるまでに生じる、通信の遅延時間。この遅延時間が短いことをレイテンシが小さい(低い)、遅延時間が長いことをレイテンシが大きい(高い)。 ユースケースとは 利用者があるシステムを用いて特定の目的を達するまでの、双方の間のやり取りを明確に定義したもの。利用者は機器を操作する人間以外にも外部の他のシステムなどを想定する場合もある。 バッチ処理とは バッチ(Batch)は「ひと束」「一群」「1回分にまとめる」という意味で、バッチ処理はあらかじめ登録した一連の処理を自動的に実行する処理方式を指す。複数のプログラムやファイル転送コマンドなどの実行順序を定義し、大量のデータを一括処理する。処理の単位を「バッチ」と呼ぶ。 クエリとは データベース管理システムに対する問合せ(処理要求)のこと。データの抽出や更新などの処理要求を文字列で表す。処理対象のテーブルやデータの抽出条件、並べ方などを指定する。 クラスタとは 複数のコンピューターをまとめて1台のコンピュータシステムとしたものを指します。個々のユーザーが独自開発して使用する場合と、企業がサービスとして提供する場合があります。使用目的にはスケーラビリティ(拡張性)とアベイラビリティ(高可用性)の2つが挙げられます。 -スケーラビリティ(拡張性):複数のコンピュータをクラスタにし、処理を分散することでより高い処理性能を得ることができます。 -アベイラビリティ(高可用性):複数のコンピュータをクラスタにすることで、いくつかのコンピュータの停止障害時でも処理を継続することが可能となり、より高い信頼性を得ることができます。 スケールアップとは サーバーの性能をアップさせることです。ハードディスクの容量やメモリ、CPUの性能を上げるという意味です。一台のサーバーの中で、性能をアップさせることはすべて「スケールアップ」という言葉でまとめられる。 スケールアウトとは コンピュータシステムの性能を増強する手法の一つで、コンピュータの台数を増やすことでシステム全体の性能を向上させること。処理を並列化、分散化できるシステムで適用される。 スループットとは 機器や通信路などの性能を表す特性の一つで、単位時間あたりに処理できる量のこと。ITの分野では、コンピュータシステムが単位時間に実行できる処理の件数や、通信回線の単位時間あたりの実効伝送量などを意味することが多い。 フォールトトレランスとは システムや機器の一部が故障・停止しても、予備の系統に切り替えるなどして機能を保ち、正常に稼働させ続ける仕組み。 Dos攻撃は、 直訳すると「サービス拒否攻撃」という意味です。DoS攻撃の頭に「Distributed」が付いて、 DDoS攻撃「分散型サービス拒否攻撃」 ストリーミングデータ 数千ものデータソースによって継続的に生成されるデータです。 これらのデータは、レコード単位またはスライドした時間窓で連続的および増分的に処理する必要があり、相関分析、集計、フィルタリング、およびサンプリングなど、広範な分析に使用することができます。 iSCSIとは コンピュータ本体とストレージ(外部記憶装置)の通信に用いられるSCSIコマンドを、IPネットワーク経由で送受信する通信規約(プロトコル)。TCP/IPベースのコンピュータネットワークにストレージ装置を直に接続することができるようになる。 スパイク IT用語における "スパイク"とは何かが急激に増加することを意味します。 例えば以下のような使い方があります。 ・ネットワークアクセスがスパイクする(急激に増加する) ・CPU利用率がスパイクする。(急激に負荷がかかり跳ね上がる) PCIコンプライアンスとは(PCI DSS) VISA、MasterCardおよびAmerican Expressなどの主なクレジット・カード会社が、クレジット・カードのデータのセキュリティを向上するために策定した業界標準です。 Referer リファラーとは、ユーザがあるWebページを訪れる際に経由したWebページの事、つまり、あるWebページに訪れる直前にどのWebページを見ていたかという「参照元」のページを指す。 アイドル状態 アイドルとは、一般的には「使用されていない」「仕事がない」「あそんでいる」という意味の英語であるが、IT用語としては、あるシステムが利用可能ではあるが何の処理も行われていない、という状態のことである。 プロビジョニングとは、 必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくことです。 ワーカープロセスとは、 簡単かつ強力なプロセス間通信の方法です。この機能は非同期のメッセージシステムに基づいており、プロセスやフォームを呼び出して、呼び出し先のコンテキストで任意のメソッドを指定パラメーターとともに実行させることができます。 ホワイトリストとは、 対象を選別して受け入れたり拒絶したりする仕組みの一つで、受け入れる対象を列挙した目録を作り、そこに載っていないものは拒絶する方式。 ERPとは、 Enterprise Resources Planning の略であり、企業経営の基本となる資源要素(ヒト・モノ・カネ・情報)を適切に分配し有効活用する計画=考え方を意味します。 マイクロサービスとは、 複数の規模の小さなサービスを組み合わせてひとつの大きなアプリケーションを構成する、ソフトウェア開発の技法のひとつです。 3306ポートとは MySQLサーバーをデフォルト設定でインストールした場合に、接続のTCPポートは、3306になります。 この3306ポートは、特に何もしていない場合に、サーバーとして使用しているパソコンやサーバーが、他のマシンからのホストを遮断する設定になっています。 OLTPとは? OLTPとはOnLine Transaction Processingの略。日本語ではオンライントランザクション処理と呼ばれ、データ処理方法の1つ。ここでいうオンラインとは、リアルタイムで処理するという意味になります。 トランザクション処理とは、「関連する複数の処理や操作を一つの処理単位にまとめて管理する方式」のこと。 エントリポイントとは、 コンピュータプログラムを実行する際に、一番最初に実行することになっている箇所のこと。プログラミング言語の仕様やオペレーティングシステム(OS)の実行ファイルの形式などで定められている。 ハブとは Tの分野では、機器間をケーブルで結んで通信する際に、複数のケーブルを接続して相互に通信できるようにする集線装置、中継装置のことをハブという アーカイブとは、 保存記録、記録保管所、書庫、公文書館などの意味を持つ英単語。ITの分野ではデータを長期保存するための保管場所や記録形式、保管用にひとまとめに整理されたデータなどを指すことが多い。 すぐに使わないが後で取り出して参照するかもしれないデータを長期的に保管するため、専用の保存領域や記録装置に移動させること、および、そのような保管領域や蓄積されたデータ自体のことをアーカイブという。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

作りながら覚えるTerraform入門(5) - Route53 + ACM編

作りながら覚えるTerraform入門シリーズの第5回です。 今回は独自ドメインでHTTPS接続するための準備として、Route53とACMを作成していきます。 独自ドメインはお名前.comで取得しているものを使います。 作りながら覚えるTerraform入門シリーズ インストールと初期設定 基本編 VPC編 EC2編 Route53 + ACM編 => 今回はコチラ ELB編 RDS編 今回の学習ポイントは以下です。が、具体的に解説はできていません^^; lifecycle メタ引数 for文 ホストゾーンの作成 まず、Route53のホストゾーンを作成します。 route53.tfを作成し、以下のコードを貼り付けます。 route53.tf ################################ # Route 53 ################################ resource "aws_route53_zone" "public" { name = var.my_domain } output "name_servers" { description = "A list of name servers in associated (or default) delegation set." value = aws_route53_zone.public.name_servers } outputブロックではRoute53のネームサーバを出力させるようにしています。 variables.tfに独自ドメインの変数を追加します。 variables.tf # Route53 variable "my_domain" {} ドメイン名はterraform.tfvarsから読み込ませるようにしておきます(以下のドメインは適当です) terraform.tfvars prefix = "cloud02" my_domain = "example.com" terraform applyを実行してホストゾーンを作成後、Outputsで出力されるネームサーバをお名前.com側に登録します。(ネームサーバはコンソール画面から確認でもOK) ネームサーバの変更が反映されるには少し時間がかかりますので気長に待ちましょう。digコマンドなどでNSレコードの反映が確認できたら次の手順へ進みます。 # ネームサーバ変更前 dig example.com ns +short dns1.onamae.com. dns2.onamae.com. # ネームサーバ変更後 dig example.com ns +short ns-1596.awsdns-07.co.uk. ns-450.awsdns-56.com. ns-656.awsdns-18.net. ns-1045.awsdns-02.org. ACMでパブリック証明書を作成 続いて、ACMでパブリック証明書(SSL証明書)を作成します。 route53.tfに以下のコードを追加します。 route53.tf ################################ # ACM ################################ resource "aws_acm_certificate" "public" { domain_name = aws_route53_zone.public.name subject_alternative_names = ["*.${aws_route53_zone.public.name}"] validation_method = "DNS" lifecycle { create_before_destroy = true } } domain_nameには独自ドメインの名前を指定し、subject_alternative_namesには頭に*.を付け加えてサブドメインにも対応したワイルドカード証明書を作成するようにしています。こうすることで、ネイキッドドメイン、サブドメインどちらとも保護することができます。たとえば、ドメイン名がexample.comの場合、以下のようなドメインが保護されます。 example.com (ネイキッドドメイン) www.example.com corp.example.com validation_methodではDNS検証を指定しています。lifecycleは後述します。 terraform applyを実行して、パブリック証明書が作成されることを確認しましょう。 メタ引数 ACMの lifecycle ブロックでは証明書再作成時の挙動を指定しています。デフォルトではリソースの再作成が必要な場合、「既存のリソースを削除してから新しいリソースを作成する」という挙動になります。lifecycleブロックでcreate_before_destroy = trueを指定することで「新しいリソースを作成してから、古いリソースを削除する」という動作になりますので、SSL証明書再作成時の影響を最小限にすることができます。 lifecycleのようにTerraformの挙動をコントロールするオプションを「メタ引数(Meta-Argument)」と呼び、ACMのみならずすべてのリソースで指定することができます。メタ引数は他にもあり、まとめると次のようになります。 種類 説明 depends_on   依存関係を定義する count   指定回数ループする for_each   マップや文字列を元にループする    provider   プロバイダーを上書きする lifecycle   ライフサイクルの挙動を定義する depends_onはリソース間の依存関係を定義します。基本的にはTerraformによって自動的に依存関係を考慮しながら作成・更新・削除されるのですが、一部リソースなど、依存関係を明示的に指定してあげないとうまく動作しない場合に利用します。 countとfor_eachはループ処理で利用します。前回のEC2編のENIやEC2の作成のように、同じようなリソースを複数作成したい場合に便利です。 provider.tfにはプロバイダーにAWSを利用することを宣言し、デフォルトリージョンにap-northeast-1を指定していますが、Resourceブロックにproviderを指定することで上書きすることができます。例えば、別のリージョンに作成したい場合などでしょうか。追加のプロバイダーにはエイリアスを定義しておいて、Resourceブロックではエイリアスの名前を記述します。詳細は The Resource provider Meta-Argument を参照。 ACMのドメイン検証 ドメインの所有者を検証するために「DNS検証」を指定しましたので、Route53に検証用のCNAMEレコードを登録します。今はまだ証明書を作成しただけなので「検証保留中」となっている状態です。コンソール画面であれば「Route53でのレコードの作成」のボタンを押すだけなので非常に簡単なのですがこれをTerraformで行います。 route53.tfに以下のコードを追加します。 route53.tf resource "aws_route53_record" "public_dns_verify" { for_each = { for dvo in aws_acm_certificate.public.domain_validation_options : dvo.domain_name => { name = dvo.resource_record_name record = dvo.resource_record_value type = dvo.resource_record_type } } allow_overwrite = true name = each.value.name records = [each.value.record] ttl = 60 type = each.value.type zone_id = aws_route53_zone.public.id } resource "aws_acm_certificate_validation" "public" { certificate_arn = aws_acm_certificate.public.arn validation_record_fqdns = [for record in aws_route53_record.public_dns_verify : record.fqdn] } まず、aws_route53_recordでRoute53にCNAMEレコードを登録します。 コンソール画面で見たCNAMEレコードの名前と値のペアを取得したいのですが、これは先に作成したACMのリソースaws_acm_certificate.publicからdomain_validation_optionsを参照することで取得できます。terraform consoleで確認するとわかりやすいです。 for_each と for を使ってるので少しわかりづらいかもしれませんが、以下の記事を参考にしました。 Terraform で AWS Certificate Manager 無料証明書を発行する(AWS Provider 3.0.0 以降の場合) aws_acm_certificate_validationは検証が成功するまで待機するためのものです。新たにリソースが作成されることはありません。 CNAMEレコードの登録、DNS検証検証の待機とも for文 が使われていますが、これはリストやマップを変換したり、フィルタする時に使います。こちらもterraform consoleで確認してみるとやっていることは理解できますが、書けと言われるとまだ書けないですね。。terraform consoleで動きを確認しながら慣れていきたいと思います。 terraform applyすると10分くらいでDNS検証が成功しました。 : aws_acm_certificate_validation.public: Still creating... [9m50s elapsed] aws_acm_certificate_validation.public: Still creating... [10m0s elapsed] aws_acm_certificate_validation.public: Creation complete after 10m8s [id=2021-06-09 00:29:59 +0000 UTC] コンソール画面で確認しても「発行済み」に変わっていることがわかります。 今回は以上です。次回はELB編ということで、ロードバランサを作成して独自ドメインでHTTPS接続できるようにしてみたいと思います! 参考リンク The lifecycle Meta-Argument The Resource provider Meta-Argument Terraform で AWS Certificate Manager 無料証明書を発行する(AWS Provider 3.0.0 以降の場合) for Expressions
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

SoracomBeamのUDP → HTTP/HTTPS エントリポイントを経由してAWS API Gatewayからレスポンスを取得する

SoracomBeamのUDP → HTTP/HTTPS エントリポイント + Raspberry Piを使用してAWS API Gatewayからレスポンスを取得する方法をまとめました はじめに SoracomBeam UDP → HTTP/HTTPS エントリポイントとは? SoracomBeamのエンドポイントにUDPリクエストを送るとSoracomBeam側でHttpのPOSTリクエストに変換してくれる機能 この機能では嬉しいことにレスポンスを返してくれるため、UDPを使用しているにも関わらずHTTPのレスポンスを受け取ることができる 詳細は https://users.soracom.io/ja-jp/docs/beam/udp-http/ に記載されています。 なお、ポイントとしては リクエストBeam は送信されたメッセージを Base64 エンコードしたうえで以下のような JSON にし、HTTP POST リクエストのボディに設定します。 の2点 - SoracomからはPOSTでメッセージは送られる - メッセージはBase64にエンコードされる SoracomBeam とRaspberry Piのセットアップについて Soracom初期セットアップ https://soracom.jp/recipes_index/4171/#SORACOM_Air を参照してセットアップします API側の用意 以下の記事を参考にAPIGatewayのサンプル環境を作成 https://users.soracom.io/ja-jp/docs/beam/aws/ ただし - 今回はUDP → HTTP/HTTPS エントリポイントを使用するのでメソッドはPOSTを設定 - メッセージはBase64に変換されてSoracomからAWSに送信されてくるためLambda側でBase64をデコードする必要がある があるためLambda関数を以下のように変更しました sample.js // initialize SDK and document client var AWS = require("aws-sdk"); var docClient = new AWS.DynamoDB.DocumentClient(); exports.handler = function(event, context) { // insert imsi and timestamp into item object console.log(event); event.item.imsi = event.imsi; event.item.timestamp = event.timestamp; const payload = Buffer.from(event.item.payload, 'base64').toString('ascii'); const obj = JSON.parse(payload); event.item.a = obj.a; event.item.b = obj.b; event.item.c = obj.c; // build API parameter var params = { Item: event.item, TableName: 'BeamDemo' }; // call PutItem operation docClient.put(params, function(err, data){ if (err) context.fail(err); else context.succeed({Item:params, Result:'success'}); }); }; 実際にUDPで送信してみる 以下のサンプルプログラムを作成して送信してみます udp_send.py from datetime import datetime import socket print('The client started at', datetime.now()) client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) client.sendto(b'{\"a\":100,\"b\":200,\"c\":30}', ('beam.soracom.io', 23080)) data, addr = client.recvfrom(1024) print("at", datetime.now(), "data: ", data, "addr: ", addr) client.close() レスポンスについて pi@raspberrypi:~/Downloads $ python3 udp_send.py The client started at 2021-06-24 00:52:02.142770 at 2021-06-24 00:52:03.846639 data: b'{"Item":{"Item":{"payload":"eyJhIjoxMDAsImIiOjIwMCwiYyI6jjjlkg","imsi":"12345678","timestamp":1624463522314,"a":100,"b":200,"c":30},"TableName":"BeamDemo"},"Result":"success"}' 上記のようにUDPの送信に対してAWSからのレスポンスを受け取れました。 実際にDynamoDB側にも送信した値が保存されています まとめ SoracomBeamのUDP → HTTP/HTTPS エントリポイントを使用してRaspberry Pi経由でAWS側からレスポンスを受け取れることをまとめました。 参考になれば幸いです
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Beanstalkプラットフォームバージョンアップの手順書

経緯 Beanstalkを運用しているとなんやかんやアップデートが結構発生します。 その中でもプログラムのプラットフォームも自動的にアップデートしてくれるので それについていく必要があります。 今回はPHPのプラットフォームのマイナーバージョンアップでした。 java、pythonなどのプラットフォームも同様だと思います。 イメージとしてはプログラム言語のバージョンアップと言う感じですね。 ですから例えばPHP7からPHP8に上げる場合などは 互換性のテストをしてからアップデートする必要があります。 そして過去バージョンはいずれサポートされなくなります。 ※最後に廃止予定スケジュールのURLを貼っています。 手順 Beanstalkコンソール画面のプラットフォーム変更ボタンから 最新バージョンを選んで実行するだけ。 構成 CloudFront下のBeanstalk環境でテストしました。 更新時の動き 更新にかかった時間は約9分。(作業時間は日本時間の平日早朝6時40〜) 更新の際、定期的にブラウザのスーパーリロードを繰り返してみたが ダウンタイムは発生せず、サイトは表示され続けていました。 おそらくインスタンスを新規に立ち上げ→切り替え→旧インスタンス削除のような動きでスムーズに変更してくれているのだと思います。ログを見る限り。 おそらくCloudFrontなくてもダウンタイムなしで行けそうな感じでした。 備考 .elasticbeanstalk/config.ymlファイルを変更してeb deployしてみたのですが 反映されませんでした。createでは反映されていたような気がします。 もしどなたかyamlからeb deployで更新出来たという方いればコメントでツッコミをお願いいたします。 参考|公式 Elastic Beanstalk 環境のプラットフォームバージョンの更新 最新プラットフォーム 廃止予定のスケジュール
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む