- 投稿日：2021-01-16T23:00:16+09:00
Cloud9でWordPress環境を構築 2
WordPressの学習＆AWSに触れるのを目的として
AWS Cloud9でWordPress環境を構築するまでの備忘録。ここまでやったこと
- AWSアカウント登録
- Cloud9環境立ち上げ
- MySQLインストール
この記事の目次
- MySQLセットアップ
- 初期設定
- データベース作成
- サービス起動
- 最新化
- サービス起動
- スナップショット作成
- 作成手順
- 復元手順
（スナップショットを作成するのは
この後のWordPressのセットアップが上手くいかないから……）MySQLセットアップ
初期設定
セットアップ前にログからrootのパスワードを確認する。
$ sudo cat /var/log/mysqld.log | grep "A temporary password" 2021-01-16T09:30:18.257989Z 1 [Note] A temporary password is generated for root@localhost: XXXXXXXXXログイン後、パスワードの変更が要求される。
デフォルトのパスワードポリシー：数字/大文字/小文字/特殊文字を各1つ以上使用、長さは8文字以上
https://dev.mysql.com/doc/refman/5.7/en/validate-password-options-variables.html$ mysql_secure_installation # ログで確認したパスワード Enter password for user root: The existing password for the user account root has expired. Please set a new password. # パスワードの変更を要求される New password: (新しいパスワード) # rootのパスワードを変更するか？ Change the password for root ? ((Press y|Y for Yes, any other key for No) : N # 匿名ユーザを削除するか？ Remove anonymous users? (Press y|Y for Yes, any other key for No) : Y # rootでのリモートログインを禁止するか？ Disallow root login remotely? (Press y|Y for Yes, any other key for No) : Y # テストデータベースを削除するか？ Remove test database and access to it? (Press y|Y for Yes, any other key for No) : Y # 今すぐ権限テーブルを読み込むか？ Reload privilege tables now? (Press y|Y for Yes, any other key for No) : Y All done!文字コードをUTF-8に、
パスワードの有効期限は無期限に変更しておく。2行追加。$ sudo vi /etc/my.cnf [mysqld] (省略) character-set-server = utf8 default_password_lifetime = 0 # サービス再起動しておく $ sudo service mysqld restartデータベース作成
rootでMySQLにログイン、WordPress用のデータベース&ユーザを作成する。
$ mysql -u root -p Enter password: # WordPress用のデータベース作成 mysql> CREATE DATABASE データベース名; Query OK, 1 row affected (0.01 sec) # ユーザ作成 mysql> GRANT ALL PRIVILEGES ON *.* TO 'ユーザ名'@'localhost' IDENTIFIED BY '作成ユーザのパスワード'; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> exitサービス起動
最新化
MySQLよりに先に確認すべきだったかも。ただ、結果的には最新化不要。
# OS 結果：アップデート不要 $ sudo yum -y update Loaded plugins: extras_suggestions, langpacks, priorities, update-motd 261 packages excluded due to repository priority protections No packages marked for update # Apache 結果：アップデート不要 $ sudo yum install -y httpd24 Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 261 packages excluded due to repository priority protections No package httpd24 available. Error: Nothing to do # PHP 結果：アップデート不要 $ sudo yum install -y php56 Loaded plugins: extras_suggestions, langpacks, priorities, update-motd 261 packages excluded due to repository priority protections No package php56 available. Error: Nothing to doサービス起動
Apache、MySQLのサービスを起動する。
# Apache起動 (起動済だったかも) $ sudo service httpd start $ sudo service httpd status ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/httpd.service.d └─php-fpm.conf Active: active (running) # MySQL起動 (起動済だったかも) $ sudo service mysqld start $ sudo service mysqld status ● mysqld.service - MySQL Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: active (running)スナップショット作成
作成手順
ここまでで一旦、EC2のスナップショットを作成しておく。
EC2 > Elastic Block Store からスナップショットを作成する。
Select resource type は Volume にする。
※ 1インスタンス、1ボリューム状態なのでどちらでも変わりなし復元手順
復元手順は次の通り。(未実施)
1. スナップショットからボリュームを作成
2. インスタンスを停止
3. インスタンスから復元したいボリュームをデタッチ
4. アタッチするインスタンスのルートデバイスを確認
5. 1で作成したボリュームをインスタンスにアタッチ
6. インスタンス起動次、WordPressインストールなど。
Cloud9でWordPress環境を構築 3前の記事へのリンク
Cloud9でWordPress環境を構築 1
- 投稿日：2021-01-16T22:59:15+09:00
【AWS】認定クラウドプラクティショナー受験記録
気がついたら、2ヶ月くらい投稿してなかった。。。
という訳で久々の記事投稿です。今月、AWS認定クラウドプラクティショナーを受験し、無事に合格する事が出来ましたので、それをネタにしようと思います。
経緯
昨年末にITパスポートを取得し、春の基本情報までの間に優先的に学習するものとして、
今回はAWS認定資格を選択しました。理由としては単純に業務でCloudfrontやLambdaを使う機会があるのと、新米が先輩方に追いつく隙がAWSにはあると思ったからです。1年くらい前に受験目的ではなく、AWSの基礎知識を学びたくてUdemyの教材を購入して、ソリューションアーキテクトアソシエイト（SAA-C01）について学んだ経験はあったのですが、いっそベーシックから順番に制覇してやろうとまずはクラウドプラクティショナーを受験する事を決めました。
AWS認定資格については今更説明するまでもないと思うので、ここでの説明は割愛します。
https://aws.amazon.com/jp/certification/また、受験の際に同意した受験者行動規範により、試験内容の開示、共有は禁止されていますので、あくまで試験に向けて行った準備とか感想とかを記していこうと思います。
本題
冒頭でも書きましたが、一応今回の試験は無事に一発合格しております。
スコアは882でしたので、目標900にはあと一歩という感じでしたが、ここは単純に総合力が足りなかったのかなと思っています。
準備期間は大体3週間、学習時間は土日は3~5時間、平日は1~2時間だけど毎日ではないかな。教材も王道な感じなので、あまり参考にならないかもしれないですが、
書籍
・AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー
Udemy
・この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問）
・AWS 認定デベロッパー アソシエイト模擬試験問題集（5回分325問）
・これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）
その他
・AWS WEB問題集で学習しよう書籍はインプットで1周と分からない単語を都度調べるのに。
Udemyはクラウドプラクティショナー模試を4周、ソリューションアーキテクトアソシエイトの模試2周、デベロッパーつまみ食い程度、AWS WEB問題集で学習しようはCLF（400問）を3周、SAAは出来る限りって感じでした。当然間違えた問題もそうでない問題も解説や選択肢に出てきた単語の意味は全て調べて覚えました。正直、受かりたいだけならここまでやる必要はないかと思いますし、上位資格も取得する前提だったのでここまでコストをかけましたが、CLF試験自体に上位資格の勉強はあまり生きる部分はなかったように思うので、そこはお好みという感じでしょうか。
ホワイトペーパーよりBlack Belt Online Seminarで深堀したいものだけチョイスして見ましたが、1本のボリュームが大きいので、余力があれば見るでいいかも。
試験はピアソンVUEで近所のテストセンターでの受験を選択しました。
会場によって違うようですが、自分が受験した会場は緩い感じでカメラで監視されてるとかそういうのはなかったですね。試験自体はゆっくり解いて40分くらいだったので、見直す時間は十分にありました。
試験終了時に合否だけ表示され、スコアが確認出来たのは受験から10時間後くらいでした。最長5日営業日ほどかかる事もあるようです。まとめ
試験の雰囲気や対策、アプローチの仕方が見えてきたので、上位資格取得に向けて良い弾みになったのではないかと思います。まずは合格を優先したい人はゴリゴリ問題集を解いてサービスの理解を深めるのが近道かもしれないですね。誰かの参考になれば幸いです、では。
おまけ
会社で資格補助が出るような時に領収書を発行してもらう必要があると思いますが、
ピアソンで受験した時はオンラインで領収書発行フォームから申請する事で領収書がもらえます。
- 投稿日：2021-01-16T22:30:14+09:00
大学生がAWSに入門してみる
はじめに
友人とアプリケーションを開発するにあたって、インフラの勉強をする必要がでてきました。
「AWS 基礎からのネットワーク＆サーバー構築」といふ書籍を買ったので読んでみました。
僕とその友人の為に、メモを残しておきます。(その為にQiitaを使うのって、どうよ...?)CHAPTER 1
種々のサーバーを構築する為に必要なスキル
サーバーを構築したいなら、
①サーバーOSのインストール
②各ソフトウェアのインストールと設定
ができるようなることが必要。その通りだということはわかる。改めて言葉にしてもらえると周りに説明がしやすい。
①については、例えば Windows Server や Linux である。
②については、Webサーバーを構築したいなら nginx や Apache といったソフトをインストールおよび設定する必要があるし、DBサーバとして機能させたいなら MySQL などが必要になる。ネットワークを構成する為に必要なスキル
①IPアドレスに関する知識を持つこと
②DNSサーバーに関する知識を持つこと①については、IPアドレスの定め方、ルータを用いてインターネットとどのようにデータをやりとりするかについて等
②については、IPアドレスとドメインをいかに結びつけるかについて等安全にインフラを作る為に、必要な知識の例
・パブリックサブネット/プライベートサブネット
・NAT
についての知識が必要だという話。(わかりやすくする為に、筆者の意図と齟齬が生じているかもしれないですが、私はそのように解釈しました)DBはネットワークからアクセスできないように、プライベートサブネットのなかにおくべきで、しかしソフトのインストール等の為にNATで DB→インターネット の方向の接続のみはできるようにしようという話。
無知な私にはこれだけでも有意義な情報を獲得できたなと、この本を買ってよかったと思える。
物理的なネットワークとAWSの対応
・リージョンとアベイラビリティゾーン
リージョン(ex. 東京リージョン)というデータセンター群、アベイラビリティゾーン(AZ;東京ゾーンのさらにどこか)で物理的なインフラを隔離している。AZは物理的に独立している。つまり、あるAZが落ちても他のAZに影響があるわけでは基本的にない。耐障害性を考慮した設計である。・ネットワークとVPC
Amazon VPC を使うと、そこにネットワークを構成できる。IPアドレスの範囲を設定できたりする。そのネットワークをIPアドレスごとに分割し、複数のサブネットを構成することができる。・インスタンスとは
仮想的なサーバーのこと。CHAPTER 2
編集中
- 投稿日：2021-01-16T21:47:57+09:00
DynamoDBの情報を読み込んでJavaFXで表示してみる
この記事について
将来的に書く予定の「JavaFX で DynamoDB Viewer作ってみた」記事の１ステップ。
結構大きな話になると思うので、少しずつ技術ポイント毎に記事を書いて、ある一定程度の要件を満たせた段階で前述まとめ記事書く予定。今回は、基本技術確認まで。背景
業務や趣味でDynamoDBを使用している。少しのデータならAWS管理コンソールや NoSQL Workbench for DynamoDB が存在するものの、どうもしっくりこない。表示可能なデータ量少ないし、カラム幅の変更などの操作も微妙に遅い。大体痒いところに手が届かない。
調べると結構Viewer作っている人はいるものの、大体サービス起動してブラウザで見る形式。
GoogleSpreadSheetレベルに完成度が高いブラウザツールがあったらそれを使いたいが、今のところ見当たらない。なので作ってしまおうという事。開発環境
Eclipse Neon
JavaFX Scene Builder 2.0
※著者は結構前にインストールしたのを使ってるので古いです。要件
- スタンドアロンのツールにする。
- LinuxでもWindowsでも動くようにする
- GUIでもCUI（ファイル出力とか）でも使えるようにする
- １つのフィールドにJSON形式などで保存されてるデータも参照したい
技術選定
GUI
要件からほぼ JavaFX 一択。ブラウザで見る形式は取りたくない。
JavaFXはJDK11からは標準装備ではなくなったけど、OpenJFX として続いている模様。何となくJava8用とJava11用ビルドの２種類が必要になりそうな気配。
何にせよ、先が無い技術というわけでもない。実際今回の様な案件にはピッタリなので需要が無くなるという気がしない。基本ライブラリ
JDBCがあれば使いたいが、CData社製 の様に有料のものしかなさそう。
趣味のものなのでお金使いたくない。aws-sdk-java-v2 を使う。準備
mavenプロジェクト（pom.xml）作成
mvn archetype:generate -DgroupId=com.silverboxsoft -DartifactId=dynamodbtool -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=falsedynamodbtool フォルダ及び、基本フォルダが作成される。
EclipseにImport
cd dynamodbtool mvn eclipse:eclipseEclipseを起動し、File => Import。Existing Project into Workspace を選び、dynamodbtool フォルダを選択。
.gitignoreファイル作成
dynamodbtool 直下に以下内容でフ.gitignore ファイル作成
.gitignoretargetdependency追加
公式サイト に従い、以下をpom.xml
pom.xmlのprojectブロック配下に追加<dependencyManagement> <dependencies> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>bom</artifactId> <version>2.15.64</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>pom.xmlのdependenciesブロック配下に追加<dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>dynamodb</artifactId> </dependency>再度コンソールで mvn eclipse:eclipse 実行して、EclipseのプロジェクトをRefresh
mvn eclipse:eclipse※以後 pom.xml変更後は同じことする。
Queryしてみる
コードコピー
サンプルコード を真似る。
サンプルの Query.java の中身をまるっとApp.java（自動生成されたソース）にコピーし、package名、class名、リージョン指定部分だけ変える（元に戻す）。App.javapackage com.silverboxsoft; // 中略 public class App { // 中略 Region region = Region.AP_NORTHEAST_1; // 後略認証情報
AWS SDKのセットアップを終わらせておく。
もしくは Eclipse の Run => RunConfigurationで、Environmentタブにて、以下の変数と値を追加
- AWS_ACCESS_KEY_ID=your_access_key_id
- AWS_SECRET_ACCESS_KEY=your_secret_access_key
テスト実行
EclipseのRunConfigurationで、ProgramArgumentに「テーブル名 主キー名 主キー値」の形式で指定。今回は自分用の家計簿ツール で使用しているテーブルを使用。「account_balance tgt_date 20200208」を指定。
結果Querying account_balance SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. There were 3record(s) returned単純な処理だが、DynamoDBへのアクセスに成功。次のステップに移る。
JavaFX準備始
Scene Builderのインストール
すいませんが、ここは検索すると良記事がたくさん出てくるのでそちらを参考にお願いします。
画面デザイン作成
Scnene Builderで、File => New From Template => Basic Application
- 左ペインのDocument => Controller の Controller classに、「com.silverboxsoft.controller.DynamoDbToolController」を指定（後でjavaクラスで作成する）。
- ButtonとTableView配置
- Button の Inspector => Code の On Action に
actLoadを指定（後で関数で作成する）- TableView の Inspector => Code => fx:id に
tableResultListを指定- TableViewに TableColumn を追加して３つにする。
- TableColumn の fx:id にそれぞれ
tableColTgtDate、tableColTargetCd、tableColValueを指定
src/main/resources/com/silverboxsoft/controller/javafx/DynaboDbToolController.fxmlに保存pom.xml に起動クラス指定
ついでにエンコーディングやjavaバージョン指定
pom.xml<properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <java.version>1.8</java.version> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <start-class>com.silverboxsoft.App</start-class> </properties>※修正後はお約束の
mvn eclipse:eclipseとEclipseのプロジェクトRefreshメインクラス変更
コピーして作っていたDynamoDBへの接続テスト部分は削除
App.javapackage com.silverboxsoft; import java.io.IOException; import javafx.application.Application; import javafx.fxml.FXMLLoader; import javafx.scene.Scene; import javafx.scene.layout.VBox; import javafx.stage.Stage; // Application クラスを継承する public class App extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage stage) throws Exception { prepareControl(stage); stage.show(); } private void prepareControl(Stage stage) throws IOException { FXMLLoader fxmlLoader = new FXMLLoader( getClass().getResource("controlloer/javafx/DynamoDbToolController.fxml")); // Templateで作成されるデザインのルートコンテナが VBoxの為 VBox newPane = (VBox) fxmlLoader.load(); Scene scene = new Scene(newPane); stage.setTitle("DynamoDB Tool"); stage.setScene(scene); } }java側コントローラークラス作成
DynamoDbToolController.javapackage com.silverboxsoft.controller; import java.net.URL; import java.util.ResourceBundle; import com.silverboxsoft.dao.AccountBalanceDao; import com.silverboxsoft.model.AccountBalance; import javafx.event.ActionEvent; import javafx.fxml.FXML; import javafx.fxml.Initializable; import javafx.scene.control.TableColumn; import javafx.scene.control.TableView; import javafx.scene.control.cell.PropertyValueFactory; // Initializable を継承 public class DynamoDbToolController implements Initializable { // 画面デザイン上のコンポーネントと結びつける @FXML TableView<AccountBalance> tableResultList; @FXML TableColumn<AccountBalance, String> tableColTgtDate; @FXML TableColumn<AccountBalance, String> tableColTargetCd; @FXML TableColumn<AccountBalance, Long> tableColValue; @Override public void initialize(URL location, ResourceBundle resources) { setTableColumns(); } // ボタンに指定したアクションと結びつける @FXML protected void actLoad(ActionEvent ev) { AccountBalanceDao dao = new AccountBalanceDao(); // 今回はテストなのでベタ打ち tableResultList.getItems().clear(); tableResultList.getItems().addAll(dao.getBalanceListAtOneDay("20200208")); } // カラムとデータクラスメンバの結び付け private void setTableColumns() { tableColTgtDate.setCellValueFactory(new PropertyValueFactory<AccountBalance, String>("tgtDate")); tableColTargetCd.setCellValueFactory(new PropertyValueFactory<AccountBalance, String>("methodCd")); tableColValue.setCellValueFactory(new PropertyValueFactory<AccountBalance, Long>("value")); } }その他Daoやmodelクラス
今回の主目的とは違う部分なのでgithubで。
Dao
Model各ソースの関係まとめ
- pom.xml で Application クラスを継承した起動クラス指定
- 起動クラス内で、fxmlファイルを読み込む。
- fxmlファイルで、結びつくControllerクラスを指定
- fxmlファイルで、Controllerで使用するコンポーネントのfx:idを指定して@FXMLアノテーションで結び付ける
- fxmlファイルで、ボタンのアクション関数名を指定して、Controllerの関数と@FXMLアノテーションで結びつける
変なエラーが出たら
restriction on required library 'C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\jfxrt.jar'というエラーが出たら、EclipseでJavaFXを使おうとするとアクセス制限とでる問題の解決方法 を参考に、環境設定＞Java＞コンパイラー＞エラー警告＞「使用すべきでない制限されたAPI」の「禁止された参照（アクセス・ルール）」を「エラー」から「無視」に変更
現在の画面
今後のステップ
今はテーブルは固定カラム。今回作成するのは汎用DBツールなのでそこを動的に判断して処理する必要がある。
テーブルリスト表示や、接続先の指定なども可能にしたい。細かい読み込み指定もしたい。
- 投稿日：2021-01-16T19:02:06+09:00
Cloud9でWordPress環境を構築 1
WordPressの学習＆AWSに触れるのを目的として
AWS Cloud9でWordPress環境を構築するまでの備忘録。はじめにやっておいたこと
- AWSアカウント登録
- 学習用IAMユーザー作成
- 学習用ユーザへのアタッチポリシー：とりあえず次の4つ
- AmazonEC2FullAccess
- AdministratorAccess
- IAMUserChangePassword
- AWSCloud9User
この記事の目次
- インスタンス作成
- EC2インスタンス作成
- ディスク拡張
- MySQLインストール
- MariaDBアンインストール
- MySQLインストール
インスタンス作成
- EC2インスタンス作成
- ディスク拡張
EC2インスタンス作成
Cloud9のCreate environmentからCloud9環境&EC2を作成する。
こだわりはないので、Amazon Linux2にしておく。他はデフォルト。ディスク拡張
容量に余裕がない（使用率85%）ので拡張する。30GBまでなら無料らしい。
EC2 > Elastic Block Store で 作成済のボリュームを変更する (10GB→20GB)
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
L 例: EBS ボリュームのファイルシステムの拡張ボリュームを変更後、Cloud9のIDEのターミナルからコマンド実行。
パーティションを拡張する。$ sudo growpart /dev/xvda 1 $ sudo xfs_growfs -d /※作成したリージョンが違う、ルートアカウントで作成したなどで
立ち上げたEC2が見れずに何回か手間取った……。MySQLインストール
- MariaDBアンインストール
- MySQLインストール
MariaDBアンインストール
デフォルトでMariaDBがインストールされているが、どうにも動かない。
$ mysql --version mysql Ver 15.1 Distrib 10.2.10-MariaDB, for Linux (x86_64) using EditLine wrapper $ sudo service mysqld start Redirecting to /bin/systemctl start mysqld.service Failed to start mysqld.service: Unit not found.諦めてアンインストールしてMySQLをインストールする。
※ディスク拡張作業をしたのは主にこれのため#MariaDBがインストールされているか確認 $ sudo yum list installed | grep mariadb mariadb.x86_64 3:10.2.10-2.amzn2.0.3 @amzn2extra-lamp-mariadb10.2-php7.2 mariadb-common.x86_64 3:10.2.10-2.amzn2.0.3 @amzn2extra-lamp-mariadb10.2-php7.2 mariadb-config.x86_64 3:10.2.10-2.amzn2.0.3 @amzn2extra-lamp-mariadb10.2-php7.2 mariadb-libs.x86_64 3:10.2.10-2.amzn2.0.3 @amzn2extra-lamp-mariadb10.2-php7.2 #MariaDBのアンインストール (libsはcommonに依存で削除) $ sudo yum remove mariadb -y $ sudo yum remove mariadb-common -y $ sudo yum remove mariadb-config -yMySQL5.7 インストール
触ったことがある5.7をインストールする。
#mysql8.0のリポジトリを追加（5.7も含む） sudo yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm -y #mysql8.0のリポジトリを無効化 $ sudo yum-config-manager --disable mysql80-community #mysql5.7のリポジトリを有効化 $ sudo yum-config-manager --enable mysql57-community #mysqlインストール $ sudo yum install mysql-community-server -y #mysqlバージョン確認 $ mysql --version mysql Ver 14.14 Distrib 5.7.32, for Linux (x86_64) using EditLine wrapper #mysql起動 $ sudo service mysqld start Redirecting to /bin/systemctl start mysqld.service $ sudo service mysqld status Redirecting to /bin/systemctl status mysqld.service ● mysqld.service - MySQL Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: active (running) since Sat 2021-01-16 09:30:20 UTC; 3s ago次、MySQLのデータベース作成など。
Cloud9でWordPress環境を構築 2
- 投稿日：2021-01-16T18:47:27+09:00
AWSでシステムを構築することにしたときに最初にすべきこと
対象
『ちょっと試しにAWSでシステムを構築してみたい』
『そんなにお金をかけずにやりたいな』
という人向け自分はAWSを使ったことはあったけれど自分で構築した実績がなかったので欲しかったのと、以前契約していたVPSの環境を手放して、そろそろまたちょっとしたコードを試せるような環境が欲しくなったのでやってみることにした。
最初に抑えておきたい料金のこと
最初に抑えておきたいポイントは、『AWSっていったいいくらかかるの？』という、お金のことかと思う。
調べるために、まず公式サイトを見に行く。
■ AWS公式サイト
https://aws.amazon.com/あたりまえのことなんだろうけど、AWSのサイトを見るときは、言語を日本語に切り替えたほうが良い。
自分は英語のまましばらく頑張って読んでおり、不自由だった。無料枠について
さて、公式サイトの情報を見るとと無料枠の情報が出て来る（2021年1月現在）。
無料枠には３種類がある。
常に無料
文字通りずっと無料、例えばAmazon DynamoDB（AmazonのNOSQLデータベース）は25GBまで無料。Amazonとしては品質向上に役立つデータ収集が目的でユーザに使ってほしいのかもしれない。12ヶ月無料
12ヶ月（1年間）無料になる。AWSの中核となる製品で用意されている。サーバ構築＆運用のサービスEC2、ストレージのS3、データベースのRDSなど、これぞAWSという製品がここに分類される。1年経ったら料金が適用されるので、試しに構築してみるのに良い。
※EC2とRDSは750時間=31.25日なので、12ヶ月間の間は完全に無料。トライアル
AWS 無料利用枠のページにはいつまで無料なのか明記されていないので、製品ごとに異なるのかもしれない。例えばAmazon Lightsail。サービス内容を見ると、あまり運用保守に工数や技術を投資できない人向けのサービスみたい。機能を拡充して他社と差別化して、ここから収益を上げる計画なんだな、という印象。無料枠と思惑について
今回私が使ってみたいのは2．12か月無料に入っているEC2。（EC2とS3使いたいって人がまあ大半なんじゃないかな。）必要があればRDSも使ってみようかな、と考えている。
となれば、気になるのは当然、『12ヶ月経っちゃったらいくらになるのよ？』ってところだ。12か月しか使わない、というわけにはなかなか行かないのがこの世の常なのだ。
今までも、仕事上の付き合いで「今回のオンプレミスの契約のおまけにCloudを1年分サービスするんで使ってみてください！リソースも潤沢です！」と営業さんに言われてうまい話だと使ってみたことはある。
ところがCloudの気軽さってちょっとした依存性がある。おそらく潤沢に与えられたリソースも一種の仕掛けなんだろう。
オンプレミス環境ではプロジェクトやチームの間で奪い合いだったリソースが、金持ち喧嘩せずで皆仲良く思い思いの環境を構築し、「あったらいいな」が実現された『みんなの楽園』の様を呈するのにそう時間はかからなかった。
そしてそこから脱却するのは苦い思いを伴うのだ。だから、12ヶ月後にいくらかかるんだ、というところはきっちり抑えておく必要がある。
EC2の料金体系
それぞれの製品の料金については、製品ごとにページがあるのでそこを参照する。
EC2の場合以下の５種類だ
1. オンデマンド
2. スポットインスタンス
3. Saving Plan
4. リザーブドインスタンス
5. Dedicated Hosts1.オンデマンドが一番スタンダードな料金体系で、それ以外は運用スタイルが定まったサーバについて、稼働の制約を設ける代わりに料金を割引くという形になっている。
ここでは『ちょっとためしてみたい』という人を対象とするので、計画的な運用を求められる2.～4.はあてはまらない。5.も物理機なのでCloudという位置付けと少し違っている。（基本的にCloudを使うんだけれど、一部物理機が必要となるシステム構成、という場合に組み合わせて使うのかもしれない）（https://aws.amazon.com/jp/ec2/pricing/）EC2 オンデマンドの場合の課金
オンデマンドの場合、時間ごとの課金になる。金額の多寡はサーバのスペックで決まる。このサーバスペック、あまりにも選択肢があって困るのだけど、幸い12ヶ月分の無料枠があるのはt2.microというタイプだけなので、これ一択になる。危なかった。迷いすぎて構築を先送りしてしまうところだった。
t2.microの場合、１時間0.0152ドルという料金である。
一ヶ月は750時間なので、
■ Amazon EC2 月額料金（東京リージョン）
0.0152ドル×750時間=11.4ドル※以下のような見積ツールもある。
https://calculator.aws/#/
このツールを使うと、上記の製品は出てこないんだけど…
最小構成として、t4g.microが出て来る。まあ試しに使ってみるということだから、無料枠を使ってみようと思う。
- 投稿日：2021-01-16T18:47:27+09:00
AWSで試しにシステムを構築するとき、最初にすべきこと
対象
『ちょっと試しにAWSでシステムを構築してみたい』
『そんなにお金をかけずにやりたいな』
という人向け自分はAWSを使ったことはあったけれど自分で構築した実績がなかったので欲しかったのと、以前契約していたVPSの環境を手放して、そろそろまたちょっとしたコードを試せるような環境が欲しくなったのでやってみることにした。
最初に抑えておきたい料金のこと（AWSの料金体系）
最初に抑えておきたいポイントは、『AWSっていったいいくらかかるの？』という、お金のことかと思う。
調べるために、まず公式サイトを見に行く。
■ AWS公式サイト
https://aws.amazon.com/あたりまえのことなんだろうけど、AWSのサイトを見るときは、言語を日本語に切り替えたほうが良い。
自分は英語のまましばらく頑張って読んでおり、不自由だった。無料枠について
さて、公式サイトの情報を見るとと無料枠の情報が出て来る（2021年1月現在）。
無料枠には３種類がある。
常に無料
文字通りずっと無料、例えばAmazon DynamoDB（AmazonのNOSQLデータベース）は25GBまで無料。Amazonとしては品質向上に役立つデータ収集が目的でユーザに使ってほしいのかもしれない。12ヶ月無料
12ヶ月（1年間）無料になる。AWSの中核となる製品で用意されている。サーバ構築＆運用のサービスEC2、ストレージのS3、データベースのRDSなど、これぞAWSという製品がここに分類される。1年経ったら料金が適用されるので、試しに構築してみるのに良い。
※EC2とRDSは750時間=31.25日なので、12ヶ月間の間は完全に無料。トライアル
AWS 無料利用枠のページにはいつまで無料なのか明記されていないので、製品ごとに異なるのかもしれない。例えばAmazon Lightsail。サービス内容を見ると、あまり運用保守に工数や技術を投資できない人向けのサービスみたい。機能を拡充して他社と差別化して、ここから収益を上げる計画なんだな、という印象。無料枠と思惑について
今回私が使ってみたいのは2．12か月無料に入っているEC2。（EC2とS3使いたいって人がまあ大半なんじゃないかな。）必要があればRDSも使ってみようかな、と考えている。
となれば、気になるのは当然、『12ヶ月経っちゃったらいくらになるのよ？』ってところだ。12か月しか使わない、というわけにはなかなか行かないのがこの世の常なのだ。
今までも、仕事上の付き合いで「今回のオンプレミスの契約のおまけにCloudを1年分サービスするんで使ってみてください！リソースも潤沢です！」と営業さんに言われてうまい話だと使ってみたことはある。
ところがCloudの気軽さってちょっとした依存性がある。おそらく潤沢に与えられたリソースも一種の仕掛けなんだろう。
オンプレミス環境ではプロジェクトやチームの間で奪い合いだったリソースが、金持ち喧嘩せずで皆仲良く思い思いの環境を構築し、「あったらいいな」が実現された『みんなの楽園』の様を呈するのにそう時間はかからなかった。
そしてそこから脱却するのは苦い思いを伴うのだ。だから、12ヶ月後にいくらかかるんだ、というところはきっちり抑えておく必要がある。
EC2の料金体系
それぞれの製品の料金については、製品ごとにページがあるのでそこを参照する。
EC2の場合以下の５種類だ
1. オンデマンド
2. スポットインスタンス
3. Saving Plan
4. リザーブドインスタンス
5. Dedicated Hosts1.オンデマンドが一番スタンダードな料金体系で、それ以外は運用スタイルが定まったサーバについて、稼働の制約を設ける代わりに料金を割引くという形になっている。
ここでは『ちょっとためしてみたい』という人を対象とするので、計画的な運用を求められる2.～4.はあてはまらない。5.も物理機なのでCloudという位置付けと少し違っている。（基本的にCloudを使うんだけれど、一部物理機が必要となるシステム構成、という場合に組み合わせて使うのかもしれない）（https://aws.amazon.com/jp/ec2/pricing/）EC2 オンデマンドの場合の課金
オンデマンドの場合、時間ごとの課金になる。金額の多寡はサーバのスペックで決まる。このサーバスペック、あまりにも選択肢があって困るのだけど、幸い12ヶ月分の無料枠があるのはt2.microというタイプだけなので、これ一択になる。危なかった。迷いすぎて構築を先送りしてしまうところだった。
t2.microの場合、１時間0.0152ドルという料金である。
一ヶ月は750時間なので、
■ Amazon EC2 月額料金（東京リージョン）
0.0152ドル×750時間=11.4ドル※以下のような見積ツールもある。
https://calculator.aws/#/
このツールを使うと、上記の製品は出てこないんだけど…
最小構成として、t4g.microが出て来る。まあ試しに使ってみるということだから、無料枠を使ってみようと思う。
- 投稿日：2021-01-16T18:39:47+09:00
【2021年版】ド素人がAWSソリューションアーキテクトアソシエイト合格まで
試験前の状態など
- AWS使用歴は10カ月少し
- 使用サービスは Cloud9, VPC, EC2, RDS, Route53 くらい
- Rubyを使ったプログラム勉強中
- ITパスポート所持
AWSに関してはEC2にアプリをデプロイしたりRoute53のDNSを使用したりするくらいで、使用したことのあるサービスは4,5個程度でした。
そのサービスも限定的な使い方しかしていなかったため、参考書を読んだときはなんじゃこりゃという状態です…
参考書を使った基礎インプット
早速
問題集
参考書に付属の総合問題に挑戦。
基礎的な問題や本を読み返すと答えが見つかるようなものが多かったため、結果は60%くらいです。
しかしまだまだ合格の72%には届かないですね…ということで参考書の復習とそれぞれのサービスとノートにまとめ、特徴や使い方をまとめました。
AWS公認模擬試験
ある程度問題にも慣れてきたということでいよいよ公式の模試を受けてみることにしました。
公式の模試はオンラインで受けられて値段も¥2,200でしたので気軽に受けることができました。結果はというと…
45%…
難しい。
とにかく答えが分からない。本番を2回受けた今ですらあの時の模試が一番難しく思えるほどです。
AWS公認模擬試験～2回目～
本試験前に試験慣れするためにもう一度受けてみました。
結果は60%。AWS本試験 ～1回目～ 不合格
結果1回目は不合格でした。
点数は675点と、実はあと50点ないくらいで受かっていたのかと思うとかなり悔しかったです…
受けた感想としては
・CloudFront+S3の問題が多い
・S3,EC2,Glaierのコスト最適選択典型問題も出題
・リードレプリカとマルチAZ構造など似た問題も多い
・マルチAZ+AutoScaling+ELBなどの理想構造を答える問題も出た印象と、全体像を掴みつつ細かい違いも区別し正しい選択肢を選ぶ問題が多かったイメージです。
そして模擬試験より解きやすい…
全体の難易度推移は
マニアックなサービスを例にした高難易度問題 >>
複数サービスが連携している例を挙げた中級問題 >>
単一のサービスを選択する初級問題と後半に行くほど難易度が下がる構成になっているように思えました。
そのため、序盤では答えが絞り切れないような問題の連発で、メンタルがやられました。
本当にこれ受かるのかな…と常に不安でいっぱいです。しかし20,25問目を過ぎたあたりから見慣れた問題が増えてくるので何とか最後まで集中力を落とさず解き進めましょう。
リベンジ
ということでリベンジ戦です。
黒本でおさらい
新たに黒本を購入しておさらい。
AWS公認模擬試験～3回目～
65%取得と前回よりも点数が上がりました。
Udemyの模擬試験6本
>> 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）
これがいい練習になりました。
高難易度問題×5 + 中難易度1問の構成で
これの中難易度が本番試験にかなり地下難易度だった印象があります。
また高難易度テストは本番の序盤で出てくる高難易度問題に近いです。
実際模試で受けた点数が750で試験とかなり近かったため、こちらが参考になると思います。
AWS本試験 ～2回目～
ようやく合格しました！！
正直一回目より難易度が上がっていて不安でしたが755点というギリギリの点数で合格できました。
試験終了後の画面に
「おめでとうございます。合格です」
と出たときは心がほっとしました。やっぱりリアルタイムで合否が出るオンライン試験は嫌な待ち時間がなくていいですね。
トータルでかかった費用など
最後にここまでの投資額や時間をまとめました。
金額
- 本試験(16,500) ×2 = 33,000
- 模試(2,200)×3 = 6,600
- 参考書 ≒ 5,000
- AWS使用料 ≒ 5,000
- Udemy模試 = 1,200 ← コストパフォーマンス最高でした
※カフェでの勉強代などは除外
時間
約40日
120時間くらい合計
時間: 約120時間
金額: 約¥58,00この中で
もし今からもう一度勉強を始めるとしたら…
黒本熟読(2~3週間)
↓
黒本模試
↓
AWS公認模試
↓
Udemy模試
↓
本番の順で勉強すると思います。
これからAWS認定を受ける方の参考になれば幸いです。
よいAWSライフを！AWSソリューションアーキテクチャ試験で紛らわしいことや、分かりにくかった問題もまとめましたので、よかったらこちらもどうぞ！
- 投稿日：2021-01-16T18:23:43+09:00
AWS SecurityGroup csv化
AWS SecurityGroupのcsv化のメモ
Outboudは途中だけど、忘れるので残しておく。
キモは、配列からオブジェクト化
これに悩んで１年たった。シェル(コマンド)
sg.shaws ec2 describe-security-groups > sg _IpPermissions-IpRanges(){ cat sg | \ jq -r '.SecurityGroups[] | { GroupName, GroupId, IpPermissions:.IpPermissions[] } | { GroupName, GroupId, IpProtocol:.IpPermissions.IpProtocol, FromPort:.IpPermissions.FromPort, ToPort:.IpPermissions.ToPort, IpRanges:.IpPermissions.IpRanges[] } | [ .GroupId, "inbound", .IpProtocol, .FromPort,.ToPort, .IpRanges.CidrIp, .IpRanges.Description ] |@csv' } _IpPermissions-UserIdGroupPairs(){ cat sg | \ jq -r '.SecurityGroups[] | { GroupName, GroupId, IpPermissions:.IpPermissions[] } | { GroupName, GroupId, IpProtocol:.IpPermissions.IpProtocol, FromPort:.IpPermissions.FromPort, ToPort:.IpPermissions.ToPort, UserIdGroupPairs:.IpPermissions.UserIdGroupPairs[] } | [ .GroupId, "inbound", .IpProtocol, .FromPort,.ToPort, .UserIdGroupPairs.UserId + "/" + .UserIdGroupPairs.GroupId, .UserIdGroupPairs.Description ] |@csv' } _IpPermissions-PrefixListIds(){ cat sg | \ jq -r '.SecurityGroups[] | { GroupName, GroupId, IpPermissions:.IpPermissions[] } | { GroupName, GroupId, IpProtocol:.IpPermissions.IpProtocol, FromPort:.IpPermissions.FromPort, ToPort:.IpPermissions.ToPort, PrefixListIds:.IpPermissions.PrefixListIds[] } | [ .GroupId, "inbound", .IpProtocol, .FromPort,.ToPort, .PrefixListIds.PrefixListId, .PrefixListIds.Description ] |@csv' } _IpPermissionsEgress-IpRanges(){ cat sg | \ jq -r '.SecurityGroups[] | { GroupName, GroupId, IpPermissionsEgress:.IpPermissionsEgress[] } | { GroupName, GroupId, IpProtocol:.IpPermissionsEgress.IpProtocol, FromPort:.IpPermissionsEgress.FromPort, ToPort:.IpPermissionsEgress.ToPort, IpRanges:.IpPermissionsEgress.IpRanges[] } | [ .GroupId, "outbound", .IpProtocol, .FromPort,.ToPort, .IpRanges.CidrIp, .IpRanges.Description ] |@csv' } _SG(){ _IpPermissions-IpRanges _IpPermissions-UserIdGroupPairs _IpPermissions-PrefixListIds _IpPermissionsEgress-IpRanges } _SG | sed s/,,/,-,/g | sed s/,,/,-,/g exit実行結果
[root@ip-192-168-0-58 ec2-user]# bash sh_sg.sh "sg-00363b7e1c868e39d","inbound","tcp",22,22,"0.0.0.0/0","" "sg-024e50824692ddaed","inbound","tcp",22,22,"0.0.0.0/0","" "sg-03fa766b4e6bf6dd9","inbound","tcp",22,22,"0.0.0.0/0", "sg-08649cd4d367766a5","inbound","-1",-,-,"0.0.0.0/0", "sg-0a14097162ef9b499","inbound","tcp",0,65535,"172.26.1.0/24", "sg-0c1cf5220455208ce","inbound","-1",-,-,"172.26.1.0/24", "sg-0c1cf5220455208ce","inbound","tcp",22,22,"192.168.0.1/32", "sg-0c1cf5220455208ce","inbound","tcp",22,22,"192.168.0.2/32", "sg-0c1cf5220455208ce","inbound","tcp",22,22,"192.168.0.3/32", "sg-0c1cf5220455208ce","inbound","tcp",244,255,"192.168.0.1/32", "sg-0c1cf5220455208ce","inbound","tcp",0,65535,"273384484291/sg-0a14097162ef9b499","sg2" "sg-0c1cf5220455208ce","inbound","tcp",0,65535,"pl-61a54008", "sg-00363b7e1c868e39d","outbound","-1",-,-,"0.0.0.0/0", "sg-024e50824692ddaed","outbound","-1",-,-,"0.0.0.0/0", "sg-03fa766b4e6bf6dd9","outbound","-1",-,-,"0.0.0.0/0", "sg-08649cd4d367766a5","outbound","-1",-,-,"0.0.0.0/0", "sg-0a14097162ef9b499","outbound","-1",-,-,"0.0.0.0/0", "sg-0c1cf5220455208ce","outbound","-1",-,-,"0.0.0.0/0", [root@ip-192-168-0-58 ec2-user]#■参考サイト
https://teratail.com/questions/312929#reply-440621
https://qiita.com/sotoiwa/items/431358283dee00eb6f46
https://jupitrisonlabs.hatenadiary.jp/entry/20151127/1448606090
- 投稿日：2021-01-16T17:36:36+09:00
AWS Amplify ＋ API Gateway + Lambda + Pythonで正常なレスポンスを返す
AWS AmplifyでLambda＋API Gatewayを構成しているときに、テスト実行をしてみても正常なレスポンスが得られずに少し困ることがあっりあました。なので、AmplifyでのAPIの追加の仕方と合わせて、備忘録と学習を兼ねて書きます。
結論
結論からいうと、API GatewayからLambda関数を呼び出すときは、以下のようなレスポンスを返すようにする必要があるようです。
return { "isBase64Encoded": true|false, "statusCode": httpStatusCode, "headers": { "headerName": "headerValue", ... }, "multiValueHeaders": { "headerName": ["headerValue", "headerValue2", ...], ... }, "body": "..." }
headersやnultiValueHeadersは特別必要ではなく、最低限statusCodeとbodyを返してあげればいいようです
。手順
環境
- WIndows10 バージョン20H2
- WSL2（Ubuntu-20.04）
- amplify CLI 4.41.0
AmplifyでLambda関数を追加する
Amplfyでプロジェクトが作成されているところから始めます。
Lambda関数を追加します。
$ amplify add function ? Select which capability you want to add: Lambda function (serverless function) ? Provide an AWS Lambda function name: myfunc ? Choose the runtime that you want to use: Python Only one template found - using Hello World by default. Available advanced settings: - Resource access permissions - Scheduled recurring invocation - Lambda layers configuration ? Do you want to configure advanced settings? No ? Do you want to edit the local lambda function now? YesDo you want to edit the local lambda function now?をYesで応えると、テキストエディタが開き、以下のような初期コードが表示されます。
def handler(event, context): print('received event:') print(event) return { 'message': 'Hello from your new Amplify Python lambda!' }通常、Lambdaをpythonで書くと、ハンドラ名が
lambda_handlerとなっていますが、Amplifyで作る場合は、handlerだけのようです。Lambdaで指定されているハンドラ名も合わせて変更されているので、特に修正する必要はありません。正常なレスポンスとなるように変更
このままだと、API Gatewayが期待するレスポンスになっていないので、コードを以下のように修正します。
def handler(event, context): print('received event:') print(event) return { 'isBase64Encoded': False, 'statusCode': 200, 'headers': {}, 'body': '{"message": "Hello from your new Amplify Python lambda!"}' }ターミナルでEnterキーを入力すると、AmplifyプロジェクトにLambda関数が追加されます。
? Press enter to continue Successfully added resource myfunc locally. Next steps: Check out sample function code generated in <project-dir>/amplify/backend/function/myfunc/src "amplify function build" builds all of your functions currently in the project "amplify mock function <functionName>" runs your function locally "amplify push" builds all of your local backend resources and provisions them in the cloud "amplify publish" builds all of your local backend and front-end resources (if you added hosting category) and provisions them in the cloudAPIの追加
AmplifyプロジェクトにAPIを追加します。
$ amplify add api ? Please select from one of the below mentioned services: REST ? Provide a friendly name for your resource to be used as a label for this category in the project: myapi ? Provide a path (e.g., /book/{isbn}): /items ? Choose a Lambda source Use a Lambda function already added in the current Amplify project ? Choose the Lambda function to invoke by this path myfunc ? Restrict API access No ? Do you want to add another path? No Successfully added resource myapi locally Some next steps: "amplify push" will build all your local backend resources and provision it in the cloud "amplify publish" will build all your local backend and frontend resources (if you have hosting category added) and provision it in the cloudAmplifyプロジェクトの展開
このままではローカルに追加されただけなので、AmplifyプロジェクトをAWSアカウント上に展開します。
プロジェクトをAWS上に展開するには、
amplify pushというコマンドを使います。
このコマンドを実行すると、以下のようにクラウド上にリソースがプロビジョニングされます。!
APIのテスト実行
デフォルトではANYとしてメソッドが登録されているので、ANYを選びます。
クライアントのテストを選ぶと、メソッドやクエリ文字列を入力できる画面が表示されます。
今回はGETでテストを実行します。
期待通りのレスポンスが返ってきました。これが、ステータスコード等が不足した正しくない形式でLambda関数のレスポンスを返すと、以下のようになります。
まとめ
Lambda + API Gatewayを使うときは、レスポンスを正しい形式にする必要があります。
また、Amplifyは簡単にAPIを実装することができて、とても楽しいです。
- 投稿日：2021-01-16T15:39:30+09:00
AWS-CLIでのクロスアカウントアクセスの実装めも
やりたいこと
AWS-CLIでクロスアカウントアクセスで操作したい ※MFA認証あり
詳細は、こんな感じです。
①AWS-CLIの実行環境は、VirtualBoxで稼働中のCentOS8
②踏み台のAWSアカウント①(111111111111)を経由して、AWSアカウント②(222222222222)でAWS-CLIで操作をする環境を構築
※踏み台アカウントの一般ユーザ「qiita」には、MFA認証が設定されている。※イメージ図
前提条件
- AWS-CLI2の実行環境は、以下である。
[root@localhost ~]# cat /etc/centos-release CentOS Linux release 8.3.2011
- 一般ユーザqiitaは、EC2インスタンスを操作する全権限を既に設定済み
実施手順
(1)AWS-CLI2の実行環境構築
本手順は、このURLの通り実施いたしました。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2-linux.html▼最新のAWS-CLI2をダウンロード
# wget https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip▼ダウンロードファイルを解凍する
# unzip awscli-exe-linux-x86_64.zip▼AWS-CLI2のインストール
# sudo ./aws/install▼AWS-CLIのバージョン確認
# aws --version※ここで、バージョンが表示されればOK
[root@localhost ~]# aws --version aws-cli/2.1.19 Python/3.7.3 Linux/4.18.0-240.1.1.el8_3.x86_64 exe/x86_64.centos.8 prompt/off↑今回のAWS-CLI2の実行環境です。
(2)AWSアカウント①でのAWS-CLIのセットアップ
▼AWS-CLIのセットアップを実施
# aws configure ↓以下、入力項目で設定を実施する AWS Access Key ID [None]: AWS Secret Access Key [None]: Default region name [None]: Default output format [None]:以下、項目説明
入力項目 概要 AWS Access Key ID [None] アクセスキー AWS Secret Access Key [None] シークレットアクセスキー Default region name [None]: デフォルトのリージョン
※東京リージョンを指定したい場合は、「ap-northeast-1」を指定Default output format [None]: 結果の形式を指定(例：json)
▼AWS-CLI設定後の動作テスト(EC2インスタンスの一覧を出力)
[root@localhost ~]# aws ec2 describe-instances { "Reservations": [] }※今回は、東京リージョンでEC2インスタンスが存在していないのでこのような出力結果になったが、EC2インスタンスが存在する場合はその情報が出力される。
(3)クロスアカウントアクセス設定
(3.1)AWSアカウント②でクロスアカウントアクセスを許可するロールを作成
▼AWSアカウント②のコンソールにログインし、ロールの作成を押下する。
▼以下を指定する ※画像参照
操作対象 値 エンティティの種類 別のAWSアカウント アカウントID 111111111111 MFAが必要 レ点チェック
▼既存のポリシー「AdministerAccess」を選択
▼タグは特に設定せずに次へ
▼ロール名に「QiitaAccess」を入力し、ロールを作成する。
(3.2)AWSアカウント①でクロスアカウントアクセスの接続テストをおこなう
▼一般ユーザqiitaで、コンソールにログインする
▼ユーザタブから、「ロールの切り替え」を押下する。 ※画像参照
▼以下を指定し、「ロールの切り替え」を実行する。 ※画像参照
入力項目 値 アカウント 222222222222 ロール QiitaAccess
▼クロスアカウントアクセス後は、こんな感じの表示となります
※ここまで実施できれば、AWSアカウント②でコンソールでの操作はできるようになりました。
(4)AWS-CLIでのクロスアカウントアクセス設定
▼AWS-CLIの現在の設定値を確認
[root@localhost ~]# cat ~/.aws/config [default] region = ap-northeast-1 output = json※AWSアカウント①のAWS-CLIのアクセス情報があります。
▼「~/.aws/config」ファイルに設定情報を追記
~/.aws/config[profile qiita-cros] region = ap-northeast-1 role_arn = arn:aws:iam::222222222222:role/QiitaAccess mfa_serial = arn:aws:iam::111111111111:mfa/qiita source_profile = default
入力項目 値 region EC2などを操作する際に必要な設定であり、リージョンを明示的に指定する必要がある role_arn AWSアカウント②のクロスアカウントロールを指定 mfa_serial AWSアカウント①のMFA設定済みのqiitaユーザを指定 source_profile AWSアカウント①のプロファイル内の認証情報を使用するために必要な設定 ▼AWS-CLI設定後の動作テスト(EC2インスタンスの一覧を出力)
[root@localhost ~]# aws ec2 describe-instances --profile qiita-cros Enter MFA code for arn:aws:iam::111111111111:mfa/qiita: { "Reservations": [] }実行時にMFAコードを聞かれるので、それを入力し、実行すれば、AWSアカウント②でもAWS-CLIの操作ができるようになりました!!やったね( *´艸｀)
まとめ
コンソールでのクロスアカウントアクセスは、普通にできていたが、AWS-CLIでのクロスアカウントアクセスは少し手間取ってしまったので、記事に残してみました。
誰かのお役に立てたらうれしいです(●´ω｀●) おわり
- 投稿日：2021-01-16T15:38:45+09:00
AWS EC2にSSHでアクセスする方法
AWSでEC2を立てて、ターミナルでローカルからSSH接続する方法について説明します。
環境
OS： Mac OSX大まかな手順
- EC2インスタンス作成（無料枠）
- アクセス鍵作成
- ローカルからSSH接続
EC2とはAWSで提供されているクラウドサービスの１つで、仮想サーバーを利用できます。
1. EC2インスタンス作成（無料枠）
ステップ 1: AMIの選択
EC2のページを開き、ダッシュボード画面から「インスタンスを起動」を選択します。
今回は、無料枠の[Amazon Linux 2 AMI (HVM), SSD Volume Type]を利用します。
赤枠の選択ボタンをクリックします。
ステップ 2: インスタンスタイプの選択
[t2.micro]を選び、[次のステップ：インスタンスの詳細の設定]をクリックします。
ステップ 3: インスタンスの詳細の設定
特に変更の必要なく、[次のステップ:ストレージの追加]をクリックします。
ステップ 4: ストレージの追加
30GBまで無料枠みたいですが、その範囲内で必要な量で設定します。
今回はとりあえず、８GiBにして、[次のステップ：タグの追加]をクリックします。
ステップ 5: タグの追加
タグはなくてもいいですが、複数プロジェクトを作成している場合や複数インスタンスを利用する場合はあると便利です。
[次のステップ：セキュリティーグループの設定]をクリックします。
ステップ 6： セキュリティグループの設定
接続設定します。今回は個人情報を含まないサーバーを立ち上げるので、0.0.0.0で問題ありません。
[ルールの追加]ボタンから、SSH, HTTP, HTTPSを選んで追加し、[確認と作成]をクリックします。
ステップ 7: インスタンスの作成と確認
内容を一応確認して、設定が正しくできていれば[起動]をクリックします。
[既存のキーペアを選択するか、新しいキーペアを作成します。]ウィンドウが立ち上がったら、
①：「新しいキーペアの作成」を選択→②：わかりやすいキーペア名を入力→③→④の順でクリックしてインスタンスを作成します。
すると作成ステータスの画面が表示されるので、[インスタンスの表示]をクリック
作成されたインスタンスの状態が表示されるので、
青文字のインスタンスIDをクリックしてインスタンスの詳細を開きます。
詳細が表示されたら、画面右側の[接続]をクリックします。
インスタンスへの接続方法が表示されます。
ダウンロードした鍵ファイル(myaccesskey.pem)の保存場所で、赤枠の２つのコマンドを実行すればSSHでの接続は完了です。
$ chmod 400 myaccesskey.pem $ ssh -i "myaccesskey.pem" ec2-user@ec2-00-000-000-000.ap-northeast-1.compute.amazonaws.com __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ 2 package(s) needed for security, out of 5 available Run "sudo yum update" to apply all updates.（続き）
「
sudo yum updateを実行してください」と表示されているので、sudo yum updateを入力してEnterRun "sudo yum update" to apply all updates. [ec2-user@ip- ~]$ sudo yum update(続き)
[ec2-user@ip- ~]$ sudo yum update 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ chrony.x86_64 0:3.2-1.amzn2.0.5 を 更新 ---> パッケージ chrony.x86_64 0:3.5.1-1.amzn2.0.1 を アップデート --> 依存性の処理をしています: libnettle.so.4()(64bit) のパッケージ: chrony-3.5.1-1.amzn2.0.1.x86_64 ---> パッケージ cloud-init.noarch 0:19.3-3.amzn2 を 更新 ---> パッケージ cloud-init.noarch 0:19.3-4.amzn2 を アップデート ---> パッケージ p11-kit.x86_64 0:0.23.21-2.amzn2.0.1 を 更新 ---> パッケージ p11-kit.x86_64 0:0.23.22-1.amzn2.0.1 を アップデート ---> パッケージ p11-kit-trust.x86_64 0:0.23.21-2.amzn2.0.1 を 更新 ---> パッケージ p11-kit-trust.x86_64 0:0.23.22-1.amzn2.0.1 を アップデート ---> パッケージ tzdata.noarch 0:2020a-1.amzn2 を 更新 ---> パッケージ tzdata.noarch 0:2020d-2.amzn2 を アップデート --> トランザクションの確認を実行しています。 ---> パッケージ nettle.x86_64 0:2.7.1-8.amzn2.0.2 を インストール --> 依存性解決を終了しました。 依存性を解決しました ================================================================================ Package アーキテクチャー バージョン リポジトリー 容量 ================================================================================ 更新します: chrony x86_64 3.5.1-1.amzn2.0.1 amzn2-core 258 k cloud-init noarch 19.3-4.amzn2 amzn2-core 924 k p11-kit x86_64 0.23.22-1.amzn2.0.1 amzn2-core 321 k p11-kit-trust x86_64 0.23.22-1.amzn2.0.1 amzn2-core 130 k tzdata noarch 2020d-2.amzn2 amzn2-core 481 k 依存性関連でのインストールをします: nettle x86_64 2.7.1-8.amzn2.0.2 amzn2-core 329 k トランザクションの要約 ================================================================================ インストール ( 1 個の依存関係のパッケージ) 更新 5 パッケージ 総ダウンロード容量: 2.4 M Is this ok [y/d/N]:コレでアップデートしていいか確認されたので、
yを入力してEnterIs this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. (1/6): cloud-init-19.3-4.amzn2.noarch.rpm | 924 kB 00:00:00 (2/6): chrony-3.5.1-1.amzn2.0.1.x86_64.rpm | 258 kB 00:00:00 (3/6): nettle-2.7.1-8.amzn2.0.2.x86_64.rpm | 329 kB 00:00:00 (4/6): p11-kit-0.23.22-1.amzn2.0.1.x86_64.rpm | 321 kB 00:00:00 (5/6): p11-kit-trust-0.23.22-1.amzn2.0.1.x86_64.rpm | 130 kB 00:00:00 (6/6): tzdata-2020d-2.amzn2.noarch.rpm | 481 kB 00:00:00 ---------------------------------------------------------------------------------------- 合計 10 MB/s | 2.4 MB 00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction 更新します : p11-kit-0.23.22-1.amzn2.0.1.x86_64 1/11 インストール中 : nettle-2.7.1-8.amzn2.0.2.x86_64 2/11 更新します : chrony-3.5.1-1.amzn2.0.1.x86_64 3/11 更新します : p11-kit-trust-0.23.22-1.amzn2.0.1.x86_64 4/11 更新します : tzdata-2020d-2.amzn2.noarch 5/11 更新します : cloud-init-19.3-4.amzn2.noarch 6/11 整理中 : p11-kit-trust-0.23.21-2.amzn2.0.1.x86_64 7/11 整理中 : tzdata-2020a-1.amzn2.noarch 8/11 整理中 : cloud-init-19.3-3.amzn2.noarch 9/11 整理中 : p11-kit-0.23.21-2.amzn2.0.1.x86_64 10/11 整理中 : chrony-3.2-1.amzn2.0.5.x86_64 11/11 検証中 : p11-kit-trust-0.23.22-1.amzn2.0.1.x86_64 1/11 検証中 : nettle-2.7.1-8.amzn2.0.2.x86_64 2/11 検証中 : p11-kit-0.23.22-1.amzn2.0.1.x86_64 3/11 検証中 : cloud-init-19.3-4.amzn2.noarch 4/11 検証中 : tzdata-2020d-2.amzn2.noarch 5/11 検証中 : chrony-3.5.1-1.amzn2.0.1.x86_64 6/11 検証中 : tzdata-2020a-1.amzn2.noarch 7/11 検証中 : p11-kit-trust-0.23.21-2.amzn2.0.1.x86_64 8/11 検証中 : p11-kit-0.23.21-2.amzn2.0.1.x86_64 9/11 検証中 : chrony-3.2-1.amzn2.0.5.x86_64 10/11 検証中 : cloud-init-19.3-3.amzn2.noarch 11/11 依存性関連をインストールしました: nettle.x86_64 0:2.7.1-8.amzn2.0.2 更新: chrony.x86_64 0:3.5.1-1.amzn2.0.1 cloud-init.noarch 0:19.3-4.amzn2 p11-kit.x86_64 0:0.23.22-1.amzn2.0.1 p11-kit-trust.x86_64 0:0.23.22-1.amzn2.0.1 tzdata.noarch 0:2020d-2.amzn2 完了しました!コレでSSHでEC2サーバーへの接続は完了です。試しに
ls -aコマンドを実行してみると、最小限のファイルだけあることが確認できました。[ec2-user@ip- ~]$ ls -a . .. .bash_logout .bash_profile .bashrc .ssh
- 投稿日：2021-01-16T15:00:43+09:00
CloudWatchでロードアベレージを追加する
背景
CloudWatchを使用しEC2のロードアベレージの監視をしようとしたが現状ロードアベレージのメトリクスは標準で用意されていないので自分でカスタムを作成しないといけないとのこと。。。
なので面倒くさいが自分でスクリプトを書いてCloudWatchから監視できるようにしました！
ロードアベレージとは
ロードアベレージはシステム全体の負荷状況を表す指標であり
1CPUにおける単位時間あたりの実行待ちとディスクI/O待ちのプロセスの数で表される。簡単にまとめるとコンピューターシステムが実行している作業量のことです。
さっそく
■まずEC2にCloudWatchAgentServerPolicyのロールを作成しアタッチする。
sshログインをして$ vi /home/ec2-user/loadaverage.sh
#!/bin/bash ## AWS CLI設定 readonly AWS_CLI="/usr/bin/aws" readonly AWS_CLI_REGION="ap-northeast-1" ## メトリックス名と単位の設定 metric_name="LoadAverage-EC2" name_space="AmazonLinux/${metric_name}" unit="Percent" #unit="Count" ## ロードアベレージを取得する自分の環境に合わす ## uptimeコマンドで出てくる最初の数字を取得できるように変える(10~12くらい?) load_average=`uptime | tr -s ' ' | cut -d ' ' -f 11 | cut -d ',' -f 1` ## AWS CloudWatchのカスタムメトリクスにロードアベレージを追加する ${AWS_CLI} cloudwatch --region ${AWS_CLI_REGION} put-metric-data --metric-name `hostname -s`/${metric_name} --namespace ${name_space} --value ${load_average} --unit ${unit}:wq
■権限付与
$ chmod 755 /home/ec2-user/loadaverage.sh■cloudwatchへメトリクス送信
$ /home/ec2-user/loadaverage.sh■EC2インスタンスのロードアベレージをCloudWatchに5分おきに記録する
$ crontab -e
*/5 * * * * /home/ec2-user/loadaverage.shこれで完成です??
参考記事
・https://qiita.com/na0AaooQ/items/1fedb1d0136cd78c6aa1
・https://qiita.com/ryuichi1208/items/3b21aee6c38bcfdb12b1
- 投稿日：2021-01-16T15:00:43+09:00
CloudWatchにロードアベレージを追加する
背景
CloudWatchを使用しEC2のロードアベレージの監視をしようとしたが現状ロードアベレージのメトリクスは標準で用意されていないので自分でカスタムを作成しないといけないとのこと。。。
なので面倒くさいが自分でスクリプトを書いてCloudWatchから監視できるようにしました！
ロードアベレージとは
ロードアベレージはシステム全体の負荷状況を表す指標であり
1CPUにおける単位時間あたりの実行待ちとディスクI/O待ちのプロセスの数で表される。簡単にまとめるとコンピューターシステムが実行している作業量のことです。
さっそく
■まずEC2にCloudWatchAgentServerPolicyのロールを作成しアタッチする。
sshログインをして$ vi /home/ec2-user/loadaverage.sh
#!/bin/bash ## AWS CLI設定 readonly AWS_CLI="/usr/bin/aws" readonly AWS_CLI_REGION="ap-northeast-1" ## メトリックス名と単位の設定 metric_name="LoadAverage-EC2" name_space="AmazonLinux/${metric_name}" unit="Percent" #unit="Count" ## ロードアベレージを取得する自分の環境に合わす ## uptimeコマンドで出てくる最初の数字を取得できるように変える(10~12くらい?) load_average=`uptime | tr -s ' ' | cut -d ' ' -f 11 | cut -d ',' -f 1` ## AWS CloudWatchのカスタムメトリクスにロードアベレージを追加する ${AWS_CLI} cloudwatch --region ${AWS_CLI_REGION} put-metric-data --metric-name `hostname -s`/${metric_name} --namespace ${name_space} --value ${load_average} --unit ${unit}:wq
■権限付与
$ chmod 755 /home/ec2-user/loadaverage.sh■cloudwatchへメトリクス送信
$ /home/ec2-user/loadaverage.sh■EC2インスタンスのロードアベレージをCloudWatchに5分おきに記録する
$ crontab -e
*/5 * * * * /home/ec2-user/loadaverage.shこれで完成です??
参考記事
・https://qiita.com/na0AaooQ/items/1fedb1d0136cd78c6aa1
・https://qiita.com/ryuichi1208/items/3b21aee6c38bcfdb12b1
- 投稿日：2021-01-16T13:29:43+09:00
docker 復習 イメージ作成～コンテナ起動
初めに
最近 python や Vue.js の勉強ばかりで EC2 や docker を使っていなかったのでイメージ作成からコンテナ起動までの復習をしてみた。
EC2インスタンス起動
イメージは Amazon Linux2 を使用。
docker コマンドをインストール
公式ドキュメントをそのままコピペしてインストール。
$ sudo yum update -y $ sudo amazon-linux-extras install docker $ sudo service docker start $ sudo usermod -a -G docker ec2-userビルド～コンテナ起動
EC2インスタンスログイン後、
~/my_dirで Dockerfile まで作成。$ mkdir my_dir $ cd my_dir $ vi enigma.py $ vi test.sh $ vi Dockerfile
- enigma.py
- test.sh
- Dockerfile
ビルドする。
$ docker build -t original_image .
マウント用に ディレクトリ
mnt_dirを作成し、ファイルを移動する。mkdir mnt_dir $ ls Dockerfile enigma.py mnt_dir test.sh$ mv `ls | grep -v 'Docker' | grep -v 'mnt'` ./mnt_dir/ $ ls ./mnt_dir/ enigma.py test.shdocker 起動。
$ docker run -it -v `pwd`/mnt_dir:/mnt original_image /bin/bashマウントできていることを確認。
root@67ac0dab37f2:/# ls /mnt/ enigma.py test.shpython ファイル実行。
root@67ac0dab37f2:/# python3 /mnt/enigma.py | tee /mnt/output.txt FRZXI JFDRX. XV SYXU LV BZEXX. SJXO AG NLDE KEN. HELLO WORLD. MY NAME IS ALICE. NICE TO MEET YOU. root@67ac0dab37f2:/# cat /mnt/output.txt FRZXI JFDRX. XV SYXU LV BZEXX. SJXO AG NLDE KEN. HELLO WORLD. MY NAME IS ALICE. NICE TO MEET YOU.
Ctrl+P+Qで起動した状態を保ちつつコンテナを抜ける。$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 67ac0dab37f2 original_image "/bin/bash" 3 minutes ago Up 3 minutes recursing_wozniakpython 実行も問題なし。
$ cat ./mnt_dir/output.txt FRZXI JFDRX. XV SYXU LV BZEXX. SJXO AG NLDE KEN. HELLO WORLD. MY NAME IS ALICE. NICE TO MEET YOU.コンテナ実行時にシェル実行
Dockerfile に
CMDを追加する。$ vi ./mnt_dir/test.sh $ vi Dockerfile
ビルド再実行。その後、何回かコンテナを起動してみる。
$ docker build -t original_image . $ docker run -v `pwd`/mnt_dir:/mnt original_image $ docker run -v `pwd`/mnt_dir:/mnt original_image $ docker run -v `pwd`/mnt_dir:/mnt original_image $ docker run -v `pwd`/mnt_dir:/mnt original_imageシェルが実行されていることを確認。
$ ls ./mnt_dir/ enigma.py mnt_file_20210116-05:25:01.txt mnt_file_20210116-05:29:38.txt test.sh mnt_file_20210116-05:24:47.txt mnt_file_20210116-05:25:47.txt output.txt
- 投稿日：2021-01-16T13:02:30+09:00
ECS Fargateを起動時に「CannotPullContainerError」が出てしまう場合の対処法
FargateのタスクでDockerHubからイメージを取得したいときに起きたエラーです。
原因や対処法を紹介していきます。「CannotPullContainerError」の原因
主な原因としては、サブネット上から外部ネットワークへの通信ができずに、imageのpullに失敗しているからです。
Fargate起動時の「CannotPullContainerError」への対処法
Fargate起動時の「CannotPullContainerError」への対処法を紹介していきます。
1.Fargateに設定されたサブネットが外部と通信できるようになっていない
Fargateに設定されたサブネットから外部への通信ができないと「CannotPullContainerError」のエラーになってしまいます。
サブネットに関連付けられているルートテーブルからインターネットゲートウェイまたはNATゲートウェイへの通信が許可されていないといけません。
更にそれらのインターネットゲートウェイまたはNATゲートウェイを通して、外部への通信を許可できる設定になっていないと上記のエラーが起きてしまいます。
インターネットゲートウェイの場合の設定
インターネットゲートウェイの場合は以下のように設定することで外部との通信ができるような設定にできます。
2.ネットワークACLのアウトバウンドが許可になっていない
ネットワークACLはデフォルトでは以下のように外部との接続は許可されていますが、設定で通信を許可されていない場合は外部との通信ができません。
上手く行かない場合は以下のように一度すべての通信を許可して試してみてください。
まとめ
「CannotPullContainerError」は外部との通信ができずに起きるエラーでした。AWSは正しく設定できていないと外部との通信ができないので気をつけましょう。
おかしなところや分からない所があったら指摘頂けると助かります。
参考
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ecs-pull-container-error/
- 投稿日：2021-01-16T12:12:40+09:00
AWS CloudFormation 概要
AWS CloudFormationの概要情報をまとめる。
AWS CloudFormationとは?
EC2やELBなどAWS リソースを自動構築する機能を提供するサービス。
- 設定ファイルをもとに各リソースを構築する。
概念・用語
- テンプレート
- 作成するリソースの定義ファイル。
- JSON、YAML形式で記述する。
- スタック
- テンプレートをもとに作成するリソースの集合。
使用の流れ
1. テンプレート作成
- VSCodeなど各エディタ用のプラグインが提供されている。
- 自動補完機能などあり。
2. テスト
エディタ用プラグインによる型定義検証。
セキュリティチェック：cfn-nag(サードパーティOSS)。
など
3. デプロイ
以下の流れでデプロイを行う。
- テンプレートをCloudFormationにアップロードする。
- テンプレートに基づいてスタックが作成される。
- スタックに基づいてリソースが作成される。
AWS マネジメントコンソール、CLI、CodeBuildなどを利用してデプロイを行う。
4. 運用
スタックポリシーの設定
- リソースに対して、意図しない変更・更新が行われないようにする。
スタック設計観点
- リソース間の依存関係、ライフサイクル(更新頻度)、ステートフル/レス、所有権(更新者)を考慮して分割する。
参考情報
- 投稿日：2021-01-16T12:04:30+09:00
Amazon CloudWatch Logs ロググループ作成方法 メモ
- Amazon CloudWatch Logsの概要とロググループ作成方法などをメモする。
Amazon CloudWatch Logs とは?
- AWSが提供するログ監視サービス。
提供機能
- ログの蓄積
- ログのモニタリング
- ログのフィルタリング
- ログのアーカイブ
- ログの分析 (
CloudWatch Logs Insights利用)- ログのアラート
基本的な使い方
- ロググループを作成する。
- ロググループにログストリームを作成する。
- ログストリームにログイベントをPUTする。
概念
ログイベント
- モニタリングしているリソースのアクティビティレコード。
ログストリーム
- 同じモニタリングリソースを共有する一連のログイベント。
- モニタリングしているリソースからの送信順序でイベントを表す。
ロググループ
- 保持、監視、アクセス制御について同じ設定を共有するログストリームのグループ。
- 各ログストリームは、1 つのロググループに属す必要がある。
ロググループ作成方法
- AWS CLIを使用し、ロググループを作成する。
1. ロググループを作成する
- ロググループ
test-log-groupを作成する。$ aws logs create-log-group --log-group-name test-log-group2. ログストリームを作成する
- ロググループ
test-log-groupにログストリームtest-log-streamを作成する。$ aws logs create-log-stream --log-group-name test-log-group --log-stream-name test-log-stream3. ログイベントをPUTする
初回PUT時
- ログストリーム
test-log-streamにログイベントをPUTする$ aws logs put-log-events --log-group-name test-log-group --log-stream-name test-log-stream --log-events "ERROR LOG : No.1"2回目以降のPUT時
- トークンを取得してから、ログイベントをPUTする。
$ TOKEN=$(aws logs describe-log-streams --log-group-name test-log-group --query 'logStreams[].uploadSequenceToken' --output text) $ aws logs put-log-events \ --log-group-name test-log-group \ --log-stream-name test-log-stream \ --log-events "ERROR LOG : No.2" \ --sequence-token ${TOKEN}参考情報
- 投稿日：2021-01-16T00:59:57+09:00
AWS Lightsail 入門3 基本設定（管理画面）
本記事の内容
- Lightsailインスタンスに対して、管理画面上での基本設定（静的IP、ファイアウォール）を行う。
※OSの基本設定は、次回の記事にまとめる。
前提条件
- Lightsailインスタンスを作成済み。
静的IPの設定
LightsailインスタンスのパブリックIP（グローバルIP）は通常、インスタンス停止時に開放され、次回起動時にはアドレスが変わる。
インスタンス再起動の度にPC上の接続設定を変更するのは手間なので、「静的IP」機能でパブリックIPを固定する。静的IPの注意点
Lightsailの静的IPは無料で利用できる。
ただし、インスタンスに1時間以上割り当てられていない未使用の静的IPは、0.005ドル/時間課金される。これは、Lightsailの最安プラン（3.5ドル/月、0.0047ドル/時）よりも高い。インスタンスの削除時は静的IPがデタッチ（割り当て解除）され、アカウントには残る。課金を防ぐためには、静的IPを1時間以内に削除するか、他のインスタンスにアタッチする。
静的IPの設定手順
Lightsail管理画面を開き、対象インスタンスを選択後、
[ネットワーキング]タブの[静的 IP の作成]を選択。
[作成]を選択。
静的IPが作成され、インスタンスにアタッチされる。
インスタンスの停止と開始を行い、パブリックIPが変化しないことを確認しておく。
※静的IPの設定により、パブリックIPが変わるので、SSHクライアントを設定済みの場合は、接続先IPアドレスを変更する。
ファイアウォールの設定
CentOSのインスタンスは、デフォルトではSSH（22番）とHTTP（80番）のポートに対して、どこからでも接続できるようになっている。
Lightsailのファイアウォールは接続元のIPアドレスを制限できるので、利用者のみに絞ることで安全性を高める。
※SSHはパブリックIP、OSユーザー名、SSHプライベートキーが無ければ接続できないので、デフォルトでも十分なセキュリティだが、本設定でより強固になる。自身のグローバルIPの確認
下記サイトで確認。
cman.jp > サーバ監視TOP > サーバメンテ支援 > IPアドレス確認ファイアウォールの設定手順
Lightsail管理画面を開き、対象インスタンスを選択。
[ネットワーキング]タブ内、[IPv4 Firewall]の[SSH]の行にある編集アイコンを選択。
[IP アドレスに制限する]にチェックし、[送信元 IP アドレス]に自身のグローバルIPを入力後、[保存]を選択。
[HTTP]の行も同様に設定する。
Webサービスを一般公開するのであればHTTPの制限は不要だが、開発や学習が目的であれば、利用者のみに制限した方が良い。設定後、SSHクライアントから接続できることを確認しておく。
また、試しに異なるアドレスを設定すると接続エラーになり、本設定で接続元IPアドレスによる制限ができていることを確認できる。送信元IP制限について補足
送信元IPの制限は、利用者以外の接続を困難にするだけで、確実に防ぐわけではない。
マンションタイプの回線のように、グローバルIPが全世帯共通の場合、同一マンションの人は接続可能となる。
また、送信元IPを偽装する「IPスプーフィング」という攻撃手法もあるため、他のセキュリティを併用する必要がある。
本設定のみで、機密情報を公開することは避ける。まとめ
静的IPの設定でインスタンスのパブリックIPが固定され、扱いやすくなる。
ただし、インスタンス削除時の静的IPの削除漏れには注意したい。
また、ファイアウォールで接続元を制限することで、安全性が高まる。
