20210802のAWSに関する記事は26件です。

【Amazon WorkMail】他のメーラーで送受信する方法【Becky】

きっかけ awsで独自ドメインでアドレス作る際に、流れでAmazon WorkMailで作っちゃった(コスト掛かるの知らず) ↑のアドレスを今使ってるメーラーで送受信したい! きっかけは単純、気軽にできると思っていた。。 設定に手こずったのでログ的に残します。 Amazon WorkMailとは? 私的にはこんな感じで捉えてます↓ 独自ドメイン使える(この流れでメアド作っちゃった) awsのメールサーバー 1アドレス50GBストレージで4ドル/月(お金掛かるの知らなかった 他のメーラーで送受信可能 IMAPプロトコルのみ対応(POP3じゃないよ) リージョンは3つ(バージニア北部、オレゴン、アイルランド) 全部英語! ↓awsのこの辺にいます(2021/8/2現在) メーラー側での設定 現在使っている『Becky』でメールの送受信させたかったので、Beckyの画面です。 ①メールボックス>新規作成>基本設定 受信プロトコルはIMAPを選択。 ※IMAPサーバーとSMTPサーバーは、リージョンにより違うので詳細は aws公式 をご覧ください。 OP25Bにチェック入れると送信エラーが出たので外してます(原因追跡中 ②メールボックス>新規作成>詳細 SMTPは465、IMAPを993に設定。 SSL/TLS関連は「証明書を検証しない」にチェック入れる(入れないとエラーでたry) これだけ!! 最初、 OP25Bにチェック入れる 「証明書を検証しない」にチェックなし この2点に引っかかり送受信エラーハマって時間かかってしまい、悔しいので記事書きました。 この記事を参考に、少しでも救われる方がいたらいいなーと。 おわり ※Amazon SESのサンドボックスから外に出しておきましょうね! Amazon SES サンドボックス外への移動
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSのEC2にDockerをインストールする方法

はじめに 昨日はローカルの開発環境(Windows)でDockerを使う記事を書いたので、本日はクラウド上(EC2)にDockerを導入する方法について記事にしたいと思います。 Amazon Linux2へのDockerのインストール # yumを最新にする sudo yum update -y # dockerのインストールする sudo yum install -y docker docker -v sudo systemctl start docker sudo usermod -aG docker ec2-user # 自動起動を有効化する sudo systemctl enable docker # 自動起動の設定確認する sudo systemctl is-enabled docker # インストールが終わったらEC2を再起動するために終了する exit UbuntuへのDockerEngineのインストール # 古いバージョンをアンインストールする sudo apt-get remove docker docker-engine [docker.io](http://docker.io/) containerd runc # 最新にする sudo apt-get update # リポジトリを利用してインストールするための準備をする sudo -y apt-get install apt-transport-https ca-certificates curl gnupg lsb-release # GPGキーを追加する(ファイルが改ざんされていないことを確認するために使われる鍵ファイル) curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # リポジトリ追加する echo \ "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # Engineをインストールする sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io # ubuntuユーザーでdockerを使えるようにする sudo gpasswd -a ubuntu docker # インストールが終わったらEC2を再起動するために終了する exit # 導入確認する docker --version 関連サイト
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CDKでThe expected type comes from property 'timeout' which is declared here on type 'FunctionProps'が出た

問題 CDKでAPIを作成しておりLambdaにtimeoutの設定をしたら下記のようなエラーが表示されビルドできない The expected type comes from property 'timeout' which is declared here on type 'FunctionProps' またリファレンスを幾ら見ても使い方に誤りは見受けられなかった。 解決策 どうやらライブラリごとのバージョンが微妙に異なっていた模様。 package.jsonのライブラリの @aws-cdk/〇〇 で定義されているもののバージョンをちゃんとstableでリリースされているものに整理して、下記コマンドを実行したところ解決した。 //古い node modules を削除 rm -rf node_modules //新しい node modules をインストール yarn install 自分の場合ちゃんとpackage.jsonに定義されていて上記のコマンドを実行するだけで解決したので、他のエラー解決するためにyarn add どっかで変なモジュールをインストールしてたんだと思います。 ちゃんと定義できている人も一度上記のコマンドを実行してみるといいかもしれません。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CDKでthis CDK CLI is not compatible with the CDK library used by your application. Please upgrade the CLI to the latest version. (Cloud assembly schema version mismatch: Maximum schema version supported is 7.0.0, but found 13.0.0)

問題 CDKでデプロイしようとしたところ下記のようなエラーが表示された his CDK CLI is not compatible with the CDK library used by your application. Please upgrade the CLI to the latest version. (Cloud assembly schema version mismatch: Maximum schema version supported is 7.0.0, but found 13.0.0) 解決策 とりあえずaws-cdkのバージョンアップを行うことで解決 グローバルでaws-cdkを扱うのはあまり良くないが急ぎなのでまあしょうがない。 yarn global upgrade aws-cdk@latest
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

40 代おっさん 冗長性のあるブログサービスを構築してみた

本記事について 本記事は AWS 初学者の私が学習していく中でわからない単語や概要をなるべくわかりやすい様にまとめたものです。 もし誤りなどありましたらコメントにてお知らせいただけるとありがたいです。 最終作成図 RDSのスナップショットからRDSを復元 こちらの記事 https://qiita.com/kou1121/items/9254eb27912311b54c19 にて以前RDS構成を作っていました。今はRDSを削除してしまったので復元します。 またVPCなどの構成も、この記事では省いていますので上を確認してみてください。 AWSマネジメントコンソールからRDSを選択 左ペインよりスナップショットを選択 チェックボックスにチャック(赤枠) 次はアクションを開いてスナップショットを復元をクリック(青枠) スナップショット復元メニュになると思います エンジンはMySQL Community 設定の箇所 DBインスタンス識別子 database-1(前回と合わせます) VPCは MyVPC1 サブネットグループは mysubnetgroup パブリックアクセス なしにする VPCセキュリティグループ 新規作成にして RDS-SG-1 (自分はセキュリティグループ消してしまい作りましたがもし残っていれば既存の選択で) データベースポート 3306 DB インスタンスクラスは バースト可能クラスを選択 以前の世代のクラスを含めるボタンを押してください db.t2.micro になっているのを確認 ストレージタイプ 汎用(SSD) ストレージ割り当て 20 可用性と耐久性ですが あとでマルチ AZ 有効かしますが今は復元なので スタンバイインスタンスを作成しないでくださいにラジオボタンがついていることを確認 アベイラビリティーゾーン ap-northeast-1a あとはそのままで大丈夫です 下にあるDBインスタンスの復元を押してください ステータスの状態が利用可能の状態になるまで待ってください AWSマネジメントコンソールからEC2を選択 左ペインよりインスタンスを選んでください WebServer1 を確認するとステータスチェックを見ると2/2のチェックに合格しましたとなっていれば大丈夫です 念のためにパブリックIPv4アドレスをコピーしてブラウザーのURL欄にに貼り付けてみてください ブログが閲覧できるはずです トップページを編集する こちらは普通は必要ありませんが今回はテストのため冗長化できているか確かめるために行います EC2にssh接続でログインしてみてください (わからなければ https://qiita.com/kou1121/items/9254eb27912311b54c19 を見てください) まずは管理者権限にスイッチ sudo su - cd コマンドで移動します ll コマンドで確認 cd /var/www/html1/ ll ここでファイルを書き換えたいと思います viエディタを使うと良いのですが・・・ むずかしいためnanoエディタを使いたいと思います nano index.php 開いたら echo '<p>Web Server1</p>'; (赤枠) 保存して閉じてください パブリックIPv4アドレスをコピーしてブラウザーのURL欄にに貼り付けて見ると 上のほうにWeb server1となっています ではではここまで言ったらイメージを作りたいと思います。 イメージの作成 AWSマネジメントコンソールからEC2を選択 左ペインよりインスタンスを選択 WebServer1にチェックを入れて右上にあるインスタンスの状態からインスタンスを停止してください インスタンスの状態が停止済みになったら右上にあるアクションからイメージとテンプレートのイメージを作成を選択してください イメージ名、説明WebServer(わかれば自由でいいです) あとはそのままでいいので 右下にあるイメージを作成をクリック 左ペインにあるイメージのAMIを見てください 最初はpendingになっていますがしばらくしたらavailableになったら大丈夫です 出来ました~~ これでこのAMIを起動するだけでWordPressからすべてが入ったWebServer1と同じEC2を立ち上げることができます。 最後に 長くなったのでここで切りたいと思います。 次はAMIイメージからEC2を立ち上げからやりたいと思っています!! またこの記事は AWS 初学者を導く体系的な動画学習サービス「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com/
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CodeBuild でテストツール使ってみた

初めに 過去にデプロイしたが動かなかった経験があるため、デプロイ前のビルドでテストを行えるようにした。 BuildSpec YAML形式で、コードサンプルは以下の通り。 注意点としては、ソースコードのトップに置かないと認識しない。 また、Testツール(以下のpytest)は結構ややこしいので、詳細は後ほど記載する。 version: 0.2 phases: install: runtime-versions: python: 3.8 commands: - pip install pipenv pre_build: commands: - pipenv install --dev flake8 pytest urllib3 - export VENV_HOME_DIR=$(pipenv --venv) - . $VENV_HOME_DIR/bin/activate - flake8 xxx.py - python -m pytest Test Tools flake8 構文チェックツールで、基本的にPEP8に準拠するようにするものと思っている。 以下のラッパーとのこと。 pycodestyle pyflakes Ned Batchelder’s McCabe script pytest UnitTestツールで、ディレクトリや設定が結構ややこしい。 簡易的にまとめたので参考程度に留めたい。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Metaps SREチームで社内GameDayを実施しました

GameDayとは 起源はAWSが毎年行っているAWS re:inventの中で開催される行事の1つです。 チームを組んでクラウド・アプリケーションを襲う謎の障害や悪意のある攻撃に対処し、トラブルシューティング能力を競うコンテストとなっています。 のちに様々な企業が社内でも実施するようになり、今ではAWS Well-Architectedのセキュリティ項目でもその実施が推奨されています。 ゲームデーを実施する ゲームデーを実施する: さまざまな脅威について、インシデント対応イベントのシミュレーション (ゲームデー) を実施します。このゲームデーには、主要なスタッフや管理者を参加させてください。 教訓から学ぶ: ゲームデーの実行から得られた教訓は、プロセスを改善するためのフィードバックに含まれている必要があります。 Metaps GameDayの手順 今回Metaps社で行なったGameDayの流れです。 1. 発生させる障害を決める 本来であれば、障害対応者たちはその内容を事前に知らされずに対応します。 しかし初回ということもあり、事前にチームで相談して発生させる障害を決めました。 話し合いの結果、今回はAWS側の障害で最も頻繁で有名なAvailability Zone(AZ)障害を選択しました。 2. 事前に障害対応のドキュメントを作成する 想定される障害に関しては、事前に対応手順をドキュメント(復旧手順書)にしておきます。 障害に関するドキュメントは、そのシステムにとって重要な仕様書です。 また、実際の障害発生時に、ベンダーのリファレンスからリソースを一から探したり、他のメンバーを呼んで議論することは、復旧が遅れる原因にもなります。 事前に整理された手順書を参考にしながら対応することで、障害対応のスピードとクオリティを大幅に向上させることができるのです。 3. 対応リソースごとにチーム分けをする MetapsのSREのオンコール対応は、2週間ごとに当番の一名が担当するシフト制です。 しかし、AZ障害のような大きな障害は、複数のリソースに影響を及ぼすので、一人で全てを復旧するには負担が大きいです。 なので今回は、影響のあるリソースごとに以下のように担当者を割り振りました。 ECS: 2名 RDS: 1名 ElastiCache: 1名 4. 実際に障害を発生させる 本番で障害を発生させて可用性を測るカオスエンジニアリングとは違い、GameDayはチームのトラブルシューティング能力を測るのが目的です。 なので今回は、Production環境ではなくStaging環境で障害を発生させます。 Gremlinなどの障害発生ツールを使うのが理想ですが、今回はVPCの特定のAZのルートテーブルに紐づくサブネットをデタッチすることで、擬似的にAZ障害を再現します。 5. 障害に対応する 各自アラートに気付き次第、実際に障害対応を行います。 今回はリモートワーク下での実施ということもあり、各々の作業をSpatialChatというチャットツールで画面共有しながら行います。 また、障害対応中はスクリーンショットやSlackの特定のチャンネルへのメモなどで、できるだけログを残しておきます。 6. 反省会 各々の障害対応の内容を、オペレーションログ兼報告書として提出します。 また、ドキュメントの手順書通りに対応してうまくいったかどうかを照らし合わせ、内容に不備がないかを確認します。 事前準備 GameDay当日までに、以下の準備を行いました。 Staging環境の冗長化 できるだけProduction環境に近い構成で行うために、事前にStaging環境のリソースもProduction環境同様に冗長化させておきます。 今回は各リソースを複数のAZに配置するようにしました。 ドキュメントの作成 自分の担当ではないリソースのドキュメントを、各々事前に書いておきます。 また、不足の事態を再現するため、このドキュメントは当日はまで担当者は見れないように設定します。 GameDay当日 1. 障害を発生させる 障害発生担当の方が、VPCのルートテーブルからサブネットをデタッチしました。 2. メンバーを招集 Datadogのアラートに気づいたメンバーが緊急性の高い障害であると判断し、SpatialChatに集まるよう指示しました。 3. 障害対応 各々の作業画面を表示させて、それぞれ対応にあたりました。 ECSは担当が二人だったので、一方はドキュメントを見ながら指示を出し、もう一方はそれに従って作業をするようにしました。 4. 問題発生 RDSとElastiCacheとFargateはドキュメント通りに復旧できましたが、ECSのEC2インスタンスでは想定外の問題が起こりました。 ECSのEC2インスタンスは、aとcの二つのAZに冗長化させており、今回は障害が起きていない方のcにALBを一時的に寄せようとしました。 しかし、ALBは「最低二つのsubenetの指定が必要」「指定できるsubnetは各AZに一つだけ」という制約があったので、復旧には元々三つのAZが必要でした。 結果、ECSのEC2インスタンスの復旧に関しては、失敗という形に終わりました。 5. 反省会 よかったところ 事前にドキュメントを準備していたおかげで、スムーズに復旧ができた。 画面共有で作業を可視化することで、お互いの作業を助け合えた。 反省点 ドキュメントがより詳細だとなおよかった(Terraformのファイルパスなど)。 他のメンバーへの作業確認を一部怠っていたところがある。 作業ログは時間ベースでもっと残しておくべきだった。 課題点 3AZでなければALBが復旧できないので、次回は3AZ状態で検証する。 オンコール対応の場合、一人で全てのサービスを復旧できるかどうか。 オンコール対応の場合、対象のサービスの復旧優先順位を事前に決めておく必要がある。 まとめ 今回のGameDayでは、チームの各サービスに対する理解度や、障害対応の手順などが再確認ができたことが大きいと思います。 次回は実際のRTOの計測のためにも、オンコール対応者のみで実施する予定です。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】Dockerイメージを使用したLambda + APIGatewayでREST APIを構築

2020年12月から、LambdaはDcokerイメージを使用して作成できるようになりました。 そこで、DcokerイメージからLambdaを作成します。 また、作成したLambdaをもとにAPIGatewayをトリガーとしたREST APIの構築方法を説明します。 ターゲット AWSのコンテナ関連サービスについて学びたい サーバーレスでAPIを構築したい Docker,Lambda,APIGatewayについて学びたい 前提条件 Dcokerを利用する環境がある(Docker Desktopがインストールされている) AWSマネジメントコンソール、AWS CLIの両方が利用できる環境がある ECRリポジトリの作成 Lambdaを作成するコンテナイメージはECRリポジトリから取得します。 そのため、API用のコンテナイメージを格納するECRリポジトリを作成します。 マネジメントコンソールのホームから、「ecr」を検索してリポジトリを開きます。 「private」タブを選択して、「リポジトリを作成」を押下します。 一般設定で可視性設定の「プライベート」を選択します。 リポジトリ名は任意で指定します。 「リポジトリを作成」を押下します。 作成されたことを確認します。 後ほど使用するため、URIを保存します。 Lambdaのコンテナイメージ作成 フォルダ構成 lambda-test │ .env │ docker-compose.yml │ └─api script.py Dockerfile requirements.txt LambdaのDockerイメージを作成します。 Lambda関数スクリプト作成 lambda-test │ └─api script.py Pythonを使用してLambda関数に使用するスクリプトを作成します。 実行されると、{"A": "hoge", "B": "fuga", "C": "piyo"}のようにJSON形式のデータを返すようにしています。 各項目は、プロキシ統合のための Lambda 関数の出力形式に沿って設定しています。 script.py import json def lambda_handler(event, context): return { "isBase64Encoded": False, "statusCode": 200, "body": json.dumps({ "A": "hoge", "B": "fuga", "C": "piyo" }) } Lambda用のイメージがAWS公式から公開されていますので、そちらを利用します。 Python依存パッケージ管理 lambda-test │ └─api requirements.txt Pythonのpipというパッケージ管理ツールで、依存パッケージを管理します。 requirements.txtに依存パッケージを指定することで、一括インストールが可能です。 今回に関しては依存パッケージがありませんので、空ファイルを作成します。 requirements.txt コンテナイメージの設計 lambda-test │ └─api Dockerfile Dockerでは、既存のコンテナイメージをpullするだけではなく、コンテナイメージをカスタマイズすることができます。 カスタマイズ内容はDockerfileで定義します。今回はAWS公式から提供されているLambda - Python用コンテナイメージpublic.ecr.aws/lambda/python:3.8をベースに作成します。 Dockerfile # Lambda - Python用コンテナイメージを使用 FROM public.ecr.aws/lambda/python:3.8 # Pythonのパッケージマネージャを最新化 RUN pip install --upgrade pip # api配下をコンテナイメージにコピー COPY . ./ # requirements.txtで記述した依存パッケージを一括インストール RUN pip install -r requirements.txt # コンテナ起動時の実行関数を定義 CMD ["script.lambda_handler"] 環境変数を定義 lambda-test │ .env 環境依存の変数を.envに定義します。 このファイルに定義した変数は、docker-compose.ymlで使用することができます。 <ECRリポジトリのイメージURI>はECRの作成の際に控えたURIに置き換えてください。 .env IMAGE_TAG=<ECRリポジトリのイメージURI> コンテナイメージをECRリポジトリにプッシュ 以下からログインコマンドを確認します。 リポジトリ名を押下してください。 「プッシュコマンドを表示」を押下します。 コマンドの1.をコピーします。 コピーしたコマンドを使用して、AWS CLIでECRにログインしてください。 ※ログインには、$ aws configureでAWS CLIへのアカウント設定が必要です。 ECRリポジトリにログイン $ aws ecr get-login-password --region <リージョン> | docker login --username AWS --password-stdin <アカウントID>.dkr.ecr.<リージョン>.amazonaws.com lambda-test(docker-compose.ymlのあるフォルダ)まで移動しします。 フォルダ移動 $ cd <BASE_DIR>\lambda-test コンテナイメージをビルドします。 コンテナイメージのビルド $ docker-compose build --no-cache 作成したコンテナイメージのREPOSITORYの値がECRリポジトリのURIになっていることを確認します。 コンテナイメージの確認 $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE <アカウントID>.dkr.ecr.<リージョン>.amazonaws.com/<リポジトリ名> latest e694ba04a4e7 16 seconds ago 614MB ECRリポジトリにプッシュします。 ECRリポジトリにプッシュ $ docker-compose push マネジメントコンソールに戻り、ECRリポジトリにコンテナイメージがあることを確認します。 Lambdaを作成 ECRリポジトリのコンテナイメージから、Lambdaを作成します。 マネジメントコンソールで、「lambda」と検索して、サービスの「Lambda」を押下します。 左のナビゲーションペインから「関数」を選択して、右上の「関数の作成」を押下します。 オプションで「コンテナイメージ」を選択します。 関数名に任意の値を指定します。 「イメージを参照」を押下します。 対象のECRリポジトリからイメージタグがlatestのイメージを選択します。 「イメージを選択」を押下します。 「関数の作成」を押下してLambdaを作成します。 以下の画面に遷移すれば作成完了です。 LambdaのトリガーとしてAPIGatewayを作成 Lamndaの起動条件を設定します。 Lambdaの詳細画面の「トリガーを追加」を押下します。 トリガーの設定で「API Gateway」を選択します。 新規でAPIを作成するので、「APIを作成する」を押下します。 「REST API」を選択して、セキュリティは「APIキー」を選択します。 「作成」を押下します。 トリガーに「API Gateway」が追加されます。 動作確認 APIキーの確認 APIの実行にAPIキーを必須に設定したため、ヘッダーに指定する必要があります。 Lambdaの詳細画面の「設定」タブを押下します。 「トリガー」を選択して、API Gatewayのリンクを押下します。 API Gatewayの詳細画面で、左のAPIキーを押下します。 <Lambda名>-Keyを押下します。 APIキーの「表示」を押下すると、APIキーが確認できますので保管します。 APIのUrlを確認 APIのURLを確認します。 「ステージ」を選択します。 「default」を選択して、URLを確認します。 curlでAPIの動作確認 APIキーを設定した場合は、ヘッダーのx-api-keyに指定する必要があります。 以下のコマンドを実行します。 Windowsのコマンドプロンプトで実行する場合は、ヘッダーをダブルクォーテーションで指定してください。 APIの動作確認 $ curl -H 'x-api-key:<API_KEY>' <API_URL> 実行結果 {"A": "hoge", "B": "fuga", "C": "piyo"} おわりに REST APIをコンテナ(Dcoker)とサーバーレス(Lambda)を使用して構築してみました。 上記の技術は、スピード重視の小規模開発や、マイクロサービスにも使用できると思いますので、参考にしていただければ幸いです。 参考 API Gateway で Lambda プロキシ統合を設定する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS実務ほぼなしでAWS資格のプロフェッショナル(SAP)を受けて※落ちた話※

きっかけ ※注意 落ちた話です 一昨年AWS Solutions Architect Professional (SAP-C01)を受けてあまり勉強できず落ちました。 2カ月前くらいにAWSのネットワーク専門知識に合格して この勢いとネットワークの問題は答えられるからアドバンテージあるなと思って受けたら2回目も落ちました。。 ショックでお酒を飲みまくって、後日二日酔いで嗚咽を吐く悲しきモンスター(私)を生まれないためにも 内容をまとめたいと思います。。 言いたいこと 問題と答えを覚えて内容を理解したつもりで受かる気になっていないか? これに尽きます。 問題の正答率がよくてもこれに当てはまる場合は受けないことをお勧めします。 私は評価期間もあり、ダメ元で受けましたが余裕を持って受けたほうがよいです。 ※とはいえモチベ上がらないとかありますが外的要因を作って無理やり上げましょう。 絶望したこと 当日試験を受けた際に開始10分で知ってる問題が出てこなく、絶望し、心が折れました。。 6-7割初見でほぼ「これかな?」で答えを選ぶ感じになりました。 落ちたと思って気持ち的にも見直しできませんでした。。 結果 思ったより点数が取れていました。。 ちゃんと見直ししてれば10%くらいの確立で合格していたかもしれません。。 みなさんも心折られても見直しをすることをお勧めします!! AWSの知識 AWS実務はAMIの作成・EC2リストアを6日くらい実施。 SAAは3年前に取得していて個人的にEC2作成~PCからSSH接続までを何十回か実施した程度。 SAPはどこかのサイトの問題集を300問くらい2周して受けた結果、玉砕。 上記に前回勉強したAWSネットワーク専門知識の勉強を実施。 https://qiita.com/siberiannhasuki_iijima/items/92e370eb3c76f1d09091 勉強した期間 1カ月前に試験日を決め、結果として1カ月半の勉強期間となりました。 ただ前回の勉強しきった余韻があり、今回はなかなか勉強が進まなかったです。。 文章が長く難しいのもあるのですが問題集をいったりきたりしていました。 実施した勉強 ・最初の週から半月くらいQiitaやGoogle先生でANSに関連する情報を調べてなんとなく出題範囲などを理解。 ・公式のサンプル問題を3周。  https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-pro/AWS-Certified-Solutions-Architect-Professional_Sample-Questions.pdf ・1カ月前からKoiwaClubに登録して問題を実施し始める。  https://aws.koiwaclub.com/exam/ans/  試験の進め方は#1~5まで実施したら、また#1からやり直し、それを繰り返す形で#1~25は実質2~3周した。  #25以降は時間が無く、2周目を間違えた問題だけ繰り返して確認した程度。  この時点で正答率7-8割だったので受験した。 ・BlackBeltをKoiwaClubの途中で計1回確認。  KoiwaClubで出てくる問題で見てなかったものを一通り確認。(30個以上タブ開きました。。)  https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/ 本番 試験当日のギリギリまでKoiwaClubを実施していて余裕がありませんでした。。 見直しフラグもほとんどの問題につき、結果不合格となりました。。 運が悪かったのですが感覚としてKoiwaClubでやっていた問題は2-3割程度だったのかなと思います。 KoiwaClubで不正解だったものを最初はURLまで見ていたりしていましたが途中時間がなく、おざなりになってしまいました。。 思ったより点数が取れていたものの確信的に答えられた問題が1-2割でした。 終わりに 今回は本番でショックを受けてしまいましたが、やはり見直しは大事なのかなと思いました。。 あと余裕を持って試験を受けることをお勧めします! 次回はしっかり勉強して合格記を書ければと思います!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon EC2を利用した仮想サーバー構築方法③(Apacheのインストールとファイアウォールの設定)

AWS初学者です。 前回はSSH接続を行いました。 前回記事はこちら: Amazon EC2を利用した仮想サーバー構築方法②(SSH接続) 今回はApacheのインストールとファイアウォールの設定方法についてアウトプットしていきたいと思います。 (また、私はMacを使用した上でこの記事を書いています。Windowsをご使用の方はご注意ください) Apacheのインストール 今回は、前回までに作ったサーバーを「Webサーバー」として機能させるために、Apache(Apache HTTP Server)というWebサーバーソフトを用います。 [手順1] 作成したEC2インスタンスにSSHでログインする。 以下のコマンドをターミナルで実行して、SSHでインスタンスにログインします。 ターミナル ssh -i ダウンロードしたキーペアファイル ec2-user@起動しているEC2インスタンスのパブリックIPアドレス [手順2] Apacheをインストールするために、以下のコマンドを実行。 none:ターミナル sudo yum -y install httpd [手順3] Apacheを起動するために、以下のコマンドを実行。 ターミナル sudo systemctl start httpd.service ・sudoコマンド → 指定したコマンド(今回はyum)を管理者権限で実行するためのコマンド。管理者権限が必要な時に、先頭につける。 ・yumコマンド → アプリケーションをダウンロードしてインストールしたり、アンインストールする時に用いる管理者コマンド。 ・httpd → Apacheを構成する実行ファイル名。これを指定することでApacheがインストールされる。 ・-yオプション → ユーザーの確認(yesの入力)なしでコマンドを実行できるオプション。 ・systemctlコマンド → 指定したコマンド(今回はhttpd、つまりApache本体を指定)を 「起動(start)」 「停止(stop)」 「再起動(restart)」 するコマンド。 ここまででApacheが起動するようになりますが、サーバーを再起動するとまた停止してしまいます。 いちいち起動させるのは面倒なので、Apacheも自動的に再起動させる設定を行います。 Apacheを自動的に起動させる設定 [手順4]Apacheを自動起動させるために、以下のコマンドを実行。 none:ターミナル sudo systemctl enable httpd.service systemctlコマンドは指定したコマンドを「起動、停止、再起動」させることができると説明しましたが、自動起動についても 「設定(enable)」 「設定解除(disable)」 「設定の確認(list-unit-files)」 を設定することもできます。 Apacheの自動起動が設定できたかどうかは、以下のコマンドで確認できます。(「httpd.service」 がenabledになっていれば成功) ターミナル sudo systemctl list-unit-files -t service ↓実行結果(アルファベット順で並んでいる) UNIT FILES ... httpd.service enabled ... 以上でApacheをインストールし、その実行ファイルであるhttpdが起動しました。 「実行中か」を確認するには、以下のコマンドを実行して、Apacheのプロセス(実行中のプログラムのこと)を確認します。 ターミナル ps -ax ここでコマンドの解説。 ・psコマンド → 実行中のプロセスを確認できるコマンド。 ・ -ax → 「-aオプション」と「-xオプション」が組み合わさったもの ・ -aオプション → 全てのプロセスを表示させるオプション。 ・ -xオプション → 他の端末に結び付けられているプロセスも表示するオプション。 このコマンドを実行して、以下のような実行結果が表示されれば、サーバー上でApacheが起動しています。 ターミナル ps -ax ↓実行結果 12134 ? Ss 0:00 /usr/sbin/httpd -DFOREGROUND 先頭に表示されている「11115」といった数字はプロセスIDといい、プロセスを区別するために自動的につけられた番号です。 これでApacheが起動中であることが確認できたので、次はファイアウォールの設定に移ります。 ですが、まずファイアウォールとは何なのか?ということから振り返ります。 ファイアウォールとは? ファイアウォールとは、 「通して良いデータを通して、それ以外を遮断する機能」 のことです。 今回は、その中でも簡単だと言われる「パケットフィルタリング」を設定していきたいと思います。 ・パケットフィルタリングとは? → 流れるパケットを見て、通過の可否を決める仕組みのこと ・パケットとは? → まず、「データ通信の際に、送りたいデータを一度に全て送るのではなく、いくつかに分割して送る方式」のことをパケット交換方式と呼ぶ。その時、分割されたデータ一つ一つのことを「パケット」という。 このパケットの中には、「IPアドレス」や「ポート番号」も含まれています。 パケットフィルタリングは、「IPアドレス」や「ポート番号」など、各種情報を判断材料に通過の可否を決めます。 具体的には、以下のことが可能になるようです。 ・「特定のIPアドレスを送信元とするパケット以外を除外する」ように構成することで、接続元を制限する。 ・ポート番号を制限して、特定のアプリケーションを外部から接続できないようにする。 それでは、ファイアウォールの設定方法に移ります。 ファイアウォールの設定方法 [手順1] AWSのEC2を開き、左側のメニューから「セキュリティグループ」をクリック。 以前作成した「WEB-SG」というセキュリティグループにチェックを入れます。 [手順2] チェックを入れたら、画面下側の「インバウンド」というタブをクリックし、さらに「edit inbound rules」をクリックします。 [手順3] ポート80番を開ける(ブロックされているポート80番で通信できるようにする)操作を行います。 具体的には、以下の4点を行い、「保存」をクリックする。 「ルールの追加」をクリック タイプは「カスタムTCP」を選択 ポート範囲は「80」を入力 ソースは「カスタム」を選択し、「0.0.0.0/0」を入力。 以上により、 「ポート22番だけを通して、それ以外は通さない」 という設定に 「ポート80番でも通信できる」 という設定を追加しました。 この状態で、作成したEC2インスタンスのパブリックIPアドレスをアドレスバーに入力して、アクセスしてみてください。 以下のような、Apacheのテスト画面が表示されれば成功です。 以上で、「Apacheのインストール」と「ファイアウォールの設定」は完了です。 次回は、「IPアドレスではなく、ドメイン名でインスタンスにアクセスできるようにする」という内容をアウトプットしたいと思います。 ここまで読んでいただき、ありがとうございました。 次回: Freenomの無料ドメインをAWSで登録する方法
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CodeDeployを使ってみた

初めに Lambdaのデプロイが上手くいかないのでQiitaに書きながら頑張ることにした 用語 Blue/Green Deploy Blue/Greenデプロイとは? 現在稼働している環境と別にもう1つ稼働環境を作成し、ロードバランサー等のルーティングを新環境に向けるデプロイ方法です。 常にリクエストを受けている稼働中のサーバを置き換えるよりも安全にデプロイ可能なのがメリットになります。 アプリケーション デプロイグループ デプロイのメイン設定となるもの。 サービスロール CodeDeployで利用するロールのこと。 デプロイ設定 色々あるけど、単に利用するだけなら何でも良い気がする。 リビジョン デプロイするファイルがある場所だと思う。 S3においていたら、S3のARNを記載する。 appspec.yml CodeBuildのBuildspec.ymlのように、CodeDeployにはAppspec.ymlがあるようだ。 同様にソースコードのトップに置いておく必要がある。 Error S3へフルアクセスしているのに以下のエラーが出て詰まっている。 The IAM role arn:aws:iam::xxx:role/xxx does not give you permission to perform operations in the following AWS service: Amazon S3. Contact your AWS administrator if you need help. If you are an AWS administrator, you can grant permissions to your users or groups by creating IAM policies. 権限周りは以下の通り。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ECS + Fargate構成でECS Execを使おうとしたらハマったポイント

ECS Execとは 今までFargateで動いているコンテナの中に入りたい場合、AWS System managerを使ってアクティベートコードを取得して、Dockerfileに書いてなどをする必要があった。ちょっとめんどくさい。 https://qiita.com/pocari/items/3f3d77c80893f9f1e132 それを簡単に出来るようになったのがECS Execということみたい。 docker execコマンドみたいな感じ。つまりコンテナの中に入れる。 https://aws.amazon.com/jp/blogs/news/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/ ECS Execを使うには こちらが参考になりました!ありがとうございます。 ざっくりまとめると、 - ECSタスクロールの作成 - enableExecuteCommandを有効化(タスク起動時) - AWS CLIを実行するアカウントにexecute-commandを実行できるIAMポリシーを付ける - AWS CLI 用の Session Manager プラグインをインストールする - AWS CLIの2.1.31以降のバージョンを使う - ssmmessagesのVPCエンドポイント(プライベートリンク)を作る ←ここでハマった ハマったポイント ECSタスクロールを作ったり、AWS CLIにSession Manager プラグインを入れるのは問題なかったのですが、 aws ecs execute-command --cluster [クラスター名] \ --task [タスクID] \ --container [コンテナ名] \ --interactive \ --command "/bin/sh" としても一向に入れない。。 An error occurred (TargetNotConnectedException) when calling the ExecuteCommand operation: The execute command failed due to an internal error. Try again later. TargetNotConnectedException と怒られる。。色々設定変えたり試行錯誤するも変わらず。。 aws ecs describe-tasks \ --cluster [クラスター名] \ --tasks [タスクID] と打って状態を確認すると、 ... "managedAgents": [ { "lastStartedAt": "2021-08-02T10:24:54.476000+09:00", "name": "ExecuteCommandAgent", "lastStatus": "RUNNING" } ], ... "enableExecuteCommand": true, ... どうやらエージェントはしっかり動いている様子。じゃあなぜ入れないのだ。。 詰まったらこれ使おう Amazon ECS Exec Checker 公式の英語ドキュメント で見つけたのですが、Amazon ECS Exec Checkerというものがあるらしい。 # git cloneする git clone https://github.com/aws-containers/amazon-ecs-exec-checker.git # jqコマンド入れる(入ってる人は不要) brew install jq ./check-ecs-exec.sh [クラスター名] [タスクID] これで設定が間違っているところないかチェックしてくれます。便利。 そうするとヒントが見えてきました。 SSM PrivateLink "com.amazonaws.ap-northeast-1.ssmmessages" not found. You must ensure your task has proper outbound internet connectivity. ssmmessagesのVPCエンドポイント(プライベートリンク)が見つからないと言っている。 おや?これか? ssmのVPCエンドポイント(プライベートリンク)は作ってあったので、完全に盲点でした。 試しにssmmessagesのVPCエンドポイント(プライベートリンク)を作る。 再度実行すると、コンテナに入れました! ssmmessagesのVPCエンドポイント(プライベートリンク)も必須なんですね。 Fargateは難しいと思いつつ、また一つ勉強になりました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[小ネタ]AmazonLinux2 PHP8にphpredisを入れる

PHP8 on AmazonLinux2 一発でphp-redisが入らない(2021/08/1現在)ので調べてみた。 前提として amazon-linux-extrasでPHP8をインストール済み Nginx + PHP-FPM + Laravel peclでインストールするらしいので、Pearをインストール sudo yum install php-pear peclでインストール sudo pecl install redis ビルドエラーが起きるので、php-develとgccをインストール sudo yum install gcc sudo yum install php-devel php.iniに追加 echo "extension=redis.so" > /etc/php.d/redis.ini php-fpmを再起動 systemctl restart php-fpm Laravelの場合 .envに追加 SESSION_DRIVER=redis SESSION_LIFETIME=120 MEMCACHED_HOST=ygd-dev.u2ark4.ng.0001.apne1.cache.amazonaws.com REDIS_HOST=ygd-dev.u2ark4.ng.0001.apne1.cache.amazonaws.com REDIS_PASSWORD=null REDIS_PORT=6379 とりあえず、setとgetするだけサンプル use Illuminate\Support\Facades\Redis; Redis::set('name', 'Taylor:'.date('Y-m-d H:i:s')); echo "Name = ".Redis::get('name')."\n";
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CodeBuildを使ってみた

初めに 業務で利用しているので簡単にまとめてみた 前提 CodeCommitでソースコードをアップロード済み 概要 プロジェクト名はコンソールから変更できないので注意。 基本的には以下の流れ。 ソースコードのトップにbuildspec.ymlファイルを作成 その中に設定を書き込んでソースコードをzip化 S3にzip化したファイルをアップロード 注意することは、S3にアップロードする際の権限くらい CodeBuildにロールを付与するときに、S3FullAccessを付けておくと良い buildspec.yml YAMLファイルの名称はオプションで変更することが可能。(オプショナル) サンプルファイル 以下は、Python前提としたテンプレ。 その中に設定を書き込んでソースコードをzip化 S3にzip化したファイルをアップロード version: 0.2 phases: install: runtime-versions: python: 3.8 build: commands: - zip -r xxx.zip ./ - aws s3 cp xxx.zip s3://xxx/ version: 0.2は最新バージョンでおまじないと思えば良い。 Reference 公式リファレンス Build specification reference for CodeBuild
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

俺のLambdaがこんなに遅いわけがない

API Gateway + Lambda(Node.js) + MySQL(sequelize)の構成で、Lambdaの処理時間が2.5秒とだいぶ遅かったです。 その後色々手を加えて当初の32%の0.8秒にまで抑えることができたので対応内容をシェアします。 メモリ量調整 定番です。 当初256MBでした。増やせば増やすほど早くなりそうな感じでしたが、コストとの折り合いを見て1024MBに変更しました。 これで平均2.1秒と0.4秒減。 SSM Parameter Storeへの問い合わせを並列実行 コード内で4回Parameter Storeへ値を取得していたのですが、Promise.allを使って並列で取得するようにしました。 1回の値取得に50ミリ秒程度掛かっていたので、これで平均1.95秒と150ミリ秒減りました。 コードのイメージとしてはこんな感じです。 const [dbHost, dbName, dbUser, dbPass] = await Promise.all( [ retrieveDbSetting('DB_HOST'), retrieveDbSetting('DB_DATABASE'), retrieveDbSetting('DB_USERNAME'), retrieveDbSetting('DB_PASSWORD') ] ); DBコネクションプールのアイドル時間を待たずすぐにレスポンスを返す (ほぼこれのおかげ) Sequelizeの設定でpoolというものがあります。 コネクションプーリングの設定なのですが、自分はこれを設定していました。 この時Lambda関数はreturnで処理を終了させていても、コネクションプーリングの待機時間中はLambda関数が終わらないという事になっていました。 解決策としてはコネクションプーリングを削除するか(試してはいませんが)、イベントループ終了を待たないという下記設定をLambdaに書けば大丈夫です。 context.callbackWaitsForEmptyEventLoop = false; npmのdevDependencyをインストールしないようにする 時間の計測はしていなくて微々たるものだとは思いますが一応…。 普通にnpm installするとdevDependencyもインストールされてしまいます。 これを防ぐにはnpm install --productionとするか、環境変数としてNODE_ENV=productionを定義します。 今回は開発・ステージング・本番環境と同じやり方でパッケージを入れたかったので、後者の環境変数で切り替えました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Lambdaで添付ファイル付きメールを送る

LambdaでNodemailerを使う機会があったのでメモを残します Nodemailerとは Node.jsで簡単にメールを送ることができるモジュールです。 公式 https://nodemailer.com/about/ npmのページ https://www.npmjs.com/package/nodemailer やりたいこと S3に置いているPDFファイルを添付したメールを送信する 手順 メールアドレスの認証 必要な権限を付与 ローカルでモジュールを準備 Lambdaのコンソール画面でzipをアップロード 1. メールアドレスの認証 サンドボックス解除前のSESは、差出人や宛先に指定するメールアドレスの認証が必要です。 SES Homeを開く Email Addresses > Verify a New Email Address メールアドレスを入力 「Amazon Web Services – Email Address Verification Request in region Asia Pacific (Tokyo)」というメールが届くのでメール内のリンクを踏む 2. 必要な権限を付与 Lambdaの実行ロールの概要画面を開く インラインポリシーの追加 SESのSendRawEmail、S3のGetObjectのアクセス許可を追加する 3. ローカルでモジュールを準備 適当なディレクトリを作成 mkdir test 初期化 npm init nodemailerインストール npm install nodemailer test/node_modulesが作られていることを確認 test/index.jsを作成(中身はlambdaで動かしたいコード) node_modulesとindex.jsをまとめてzip化 4. Lambdaのコンソール画面でzipをアップロード 関数の画面を開く 「アップロード元」のリストから「.zipファイル」を選択 ローカルで作成したzipファイルを指定してアップロード 今回使ったLambdaのコード index.js const AWS = require('aws-sdk') const nodemailer = require('nodemailer') const transporter = nodemailer.createTransport({ SES: new AWS.SES({ apiVersion: '2010-12-01' }), }) const s3 = new AWS.S3({ apiVersion: '2006-03-01' }) const fs = require('fs').promises exports.handler = async (event) => { //S3に置いているPDFを/tmp配下にコピー const paramsForS3 = { Bucket: 'バケット名', Key: 'ファイル名', } const contents = await s3.getObject(paramsForS3).promise() const path = '/tmp/ファイル名' await fs.writeFile(path, contents.Body) // メール送信 await transporter.sendMail({ from: '差出人のメールアドレス', to: '宛先のメールアドレス', subject: 'メールの件名', text: 'メール本文', attachments: [ { filename: '添付ファイル名', //元のファイル名とは別の名前で添付したい場合はここで設定(非必須項目) path: path, }, ], }) }
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

TerraformでAWS backupの設定を入れる

これは何 TerraformでAWS backupの設定を入れた際の記録です。 早速やってみた $ vi aws_backup.tf resource "aws_backup_plan" "bastion" { name = "tf_backup_plan_bastion" rule { rule_name = "tf_backup_plan_rule_bastion" target_vault_name = aws_backup_vault.bastion.name         #UTC 17時 = JTC 2時         schedule = "cron(0 17 * * ? *)"         #二日後に削除 lifecycle { delete_after = 2 } } } resource "aws_backup_vault" "bastion" { name = "tf_backup_plan_vault_bastion" } resource "aws_backup_selection" "bastion" { iam_role_arn = "arn:aws:iam::<Account ID>:role/service-role/AWSBackupDefaultServiceRole" name = "aws_backup_selection_bastion" plan_id = aws_backup_plan.bastion.id #<VolumeのID>は、コンソール上のEC2>Volume から確認できます。 resources = [ "arn:aws:ec2:ap-northeast-1:<Account ID>:volume/<VolumeのID>" ] } 総じて 構築している最中は、aws_backup_selectionのresourceでvolumeの指定の仕方がよくわからず、苦戦していたのですが、どうやらRegion,Account ID,Volume IDを指定すればいけるっぽいですね。 *実環境で運用される際には、バックアップが実際に取れるか、まで確認してからをオススメいたしますm(__)m 参考 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/backup_selection https://www.jisakeisan.com/?y=2021&m=08&d=02&hh=02&mm=00&t1=jst&t2=utc
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

FARGATEのコンテナにdocker execする【既にECSを使用している方向け】

1.AWSCLIの更新 macOS curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg" sudo installer -pkg AWSCLIV2.pkg -target / macOS以外の更新方法は 2.SSM(SessionManagerPlugin)をインストール macOS curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/session-manager-plugin.pkg" -o "session-manager-plugin.pkg" && sudo installer -pkg session-manager-plugin.pkg -target / ln -s /usr/local/sessionmanagerplugin/bin/session-manager-plugin /usr/local/bin/session-manager-plugin macOS以外のインストール方法は 3.既存のECSサービスのenable-excute-commandを有効にする 2021/8/2現在、AWSコンソール上からは有効にできないため、AWSCLIを使用します。 aws ecs update-service \ --cluster example-cluster \ --service example-service \ --enable-execute-command ちなみに、terraformを使用している方は、リソース「aws_ecs_service」のenable_execute_commandをtrueにするだけです。 4.AWSCLIからFARGATEのコンテナにアクセスする 以下のコマンドでコンテナにアクセスします。 aws ecs execute-command \ --region $AWS_REGION \ --cluster ecs-exec-example-cluster \ --task ef6260ed8aab49cf926667ab0c52c313 \ --container example-container \ --command "/bin/bash" \ --interactive region名、cluster名などは、適宜修正が必要です。 【補足】 An error occurred (TargetNotConnectedException) when calling the ExecuteCommand operation: The execute command failed due to an internal error. Try again later. 時間を置いて試してもエラーが解決するわけもなく、ECSのタスクロールにSSM関連の権限を与えて、タスクを再起動することで解決しました。同じエラーが出た方の助けになると幸いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CPUの使用率が上がらない

CPUの使用率を上げよとの課題を先輩から出されました。 いろいろ調べたところによるとstressコマンドとかstress-ngコマンドでCPUに負荷をかけるという方法が良さげだったので試してみました。 参考にしたのはこちらの記事。 stress-ngコマンドはstressコマンドの上位互換的なことを聞いたのでじゃあstress-ngにするかみたいな気持ちです。 この通りにCPUの負荷を上げるも…できない。 モニタリングしてみても20%くらいにしかならない。 ちなみに実施したコマンドがこちら。 qiita.rb stress-ng --cpu 2 -l 90 -t 5 コマンドの意味としては、CPUのコア数2つに対して5秒後に90%までの負荷をかけようねっていう話。 なんでだろうと思ってしばらく調べましたが解決策が出ないので先輩に泣きついたところ、すぐに解決してくれました! これはどうやらCPUのコア数2つに対して5秒後に90%までの負荷をかけようねっていう話じゃないらしい。 × CPUのコア数2つに対して5秒後に90%までの負荷をかけようねっていう話。 ○ CPUのコア数2つに対して5秒間、90%までの負荷をかけようねっていう話。 負荷をかける時間が5秒間じゃ短すぎて使用率上がらないらしい! なんだ~~~ qiita.rb stress-ng --cpu 2 -l 90 -t 10m これで試したところCPUの使用率は見事に90%を超えました!おめでとう!!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

RedmineにBasic認証を追加する。

概要 RedmineにBasic認証を追加する方法を記載する。 早い話がログイン時に下記認証を走らせるようにする 作業実施 rootユーザにスイッチ bitnami@ip-172-26-15-172:/var/lib$ sudo su - root@ip-172-26-15-172:~# Basic認証用アカウント作成 root@ip-172-26-15-172:~# htpasswd -c /opt/bitnami/apache2/.htpasswd ユーザ名 New password: Re-type new password: Adding password for user ユーザ名 /opt/bitnami/apps/redmine/conf/httpd-app.confの設定変更 RewriteEngine On RewriteRule /<none> / [L,R] <Directory "/opt/bitnami/apps/redmine/htdocs/public"> Options -MultiViews AllowOverride All AuthType Basic AuthName MyAuthName AuthUserFile "/opt/bitnami/apache2/.htpasswd" Require valid-user <IfVersion < 2.3 > Order allow,deny Allow from all </IfVersion> <IfVersion >= 2.3> #Require all granted </IfVersion> PassengerEnabled on #SetEnv RAILS_RELATIVE_URL_ROOT "/redmine" PassengerAppRoot "/opt/bitnami/apps/redmine/htdocs/" <IfModule pagespeed_module> ModPagespeedDisallow "*" </IfModule> Include "/opt/bitnami/apps/redmine/conf/banner.conf" </Directory> apacheの再起動 root@ip-172-26-15-172:~# apachectl configtest Syntax OK root@ip-172-26-15-172:~# /opt/bitnami/ctlscript.sh restart apache Unmonitored apache Syntax OK
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

パブリッククラウドの簡単な差別化(AWS、Azure、GCP)

はじめに クラウド(AWSメイン)の教養を得るために勉強中の初学者です。 今回は「パブリッククラウドの簡単な差別化」を記事にします。 主に自分用のメモ&アウトプット練習として利用しますが、間違った情報等ございましたら、ご教授頂けますと幸いです。 パブリッククラウド ネットワークを経由して、サービスの形で企業や個人など不特定多数のユーザーに対してリソースを提供するクラウドコンピューティング。 物理的なサーバー、ストレージなどハードウェアのコンピュータ資源を管理する、オンプレミスとは異なる。 オンプレミスとは こちらを参考にしました。 要は、物理的なサーバーやネットワーク機器を自社で保有し、運用するシステムの利用形態で、クラウドが浸透する前の主流。 ★メリット 1. 素早く利用を開始、停止することが可能。 ※利用者は、ハードウェアの購入等の必要がないため。 2. 従量課金であることからコスト管理も容易。 3. 世界各地に環境があるため、提供地域のネットワーク遅延の影響を受けない。 4. 特定地域での災害や障害の影響を受けない。 主要なクラウドサービスの特徴 AWS ・Amazonが提供しているサービス。 ・パブリッククラウドを一番最初に提供開始したパイオニア。 ・現在も最も利用されているサービスと言われている。 ・仮想サーバー構築→EC2 Azure ・Microsoftが提供しているサービス。 ・Windowsベースで構築されている環境のため、Windowsを利用しているエンジニアには使いやすい。 ・仮想サーバー構築→Azure Virtual Machines GCP ・Googleが提供しているサービス。 ・Google検索、Gmail、Youtube等、各種サービスを支える性能、セキュリティ、安定性を持った強固なインフラを利用できる。 ・Google製品(GoogleApps等)を利用している場合、これらと連携するクラウドサービスとしては最適。 ・AI、機械学習関連の技術において選択されることが多く、大規模データ解析(BigQuery等)のインフラを、他社に比べて安価で利用することが出来る。 ・仮想サーバー構築→Compute Engine 最後に 今回は、パブリッククラウドの一例をあげて差別化してみました。 現在AWSを利用しているので、今後はAWSメインでアウトプットしていきます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

営業職のAWSソリューションアーキテクトアソシエイト(SAA-C02)合格体験記

はじめに 2015年4月に社会人になって以来ずっと営業をやっています。 営業職の私が2021年7月28日にAWSソリューションアーキテクトアソシエイト(SAA-C02)に合格しました 本記事では、営業職の視点で受験の背景や試験合格に向けた勉強方法、受けてみた感想をまとめました こちらがスコアレポートです。(ギリギリ合格でした) 受験の背景と試験前のスキルセット 2021年2月末にクラウドプラクティショナー試験に合格したので、SAA試験合格を次の目標にしました。 (クラウドプラクティショナー試験の合格体験記については別途記事を書こうと思います!) AWSについては、クラウドプラクティショナー試験の勉強をするまでは触ったことはおろか、具体的な内容についての知識は皆無でした。 (ほんとに「AWS」という単語を知っている程度でした…) そのため、詳細は別の記事でまとめたいと思いますが、クラウドプラクティショナー試験の勉強をはじめてから合格するまでは6ヶ月くらいかかりました クラウドプラクティショナー試験でAWSについての基本的な知識や勉強方法は身についていたので、SAA試験の勉強はクラウドプラクティショナー試験の勉強を開始した時よりは取り組みやすかったです 勉強方法 1.出題範囲の知識習得 主にUdemyの講座をメインで利用しました。 ・これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座(SAA-C02試験対応版) https://www.udemy.com/share/101WKk2@Pm5KfVpeT10KdUVDBmJOfT5t/ まずは、突破講座を一通り受講して、出題範囲を把握しました。 私は書かないと覚えないタイプなので、要点はノートにまとめて、見返せるようにしました 講義の中で出てきた意味の分からない単語やサービスについても調べて、理解するようにしました。 アナログで泥臭い方法ですが、普段業務でAWSを触っていないので、自分で調べない限り自分の理解が合っているか答え合わせすることが出来ないと思い1つ1つ調べました 突破講座は、ハンズオンも含まれています。 ハンズオンに取り組むことで勉強した内容と実際のAWSの画面が紐づくので、理解が進みました 注意点としては、ハンズオンで実際のAWSサービスを使うと課金されます 短期集中で取り組んで立ち上げたらすぐにハンズオンして終了出来る場合は良いのですが、間が空くとお金がそれなりに掛かってしまうので、一旦停止するなどして費用を抑えるようにすることをおすすめします。 2.試験対策 同じくUdemyの模擬試験を活用しました。 ・【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集(6回分390問) https://www.udemy.com/share/101rfM2@PW5jfWFKS1ELe0JEAXNzfT1tSg==/ 模擬試験は、1回目で合格ラインを超えることは難しいので、間違えた問題の解説を確認して、2回目、3回目で満点近く取れるようにしました 問題によっては、解説を読んだだけだと頭に入らなかったので、突破講座同様にノートにまとめました。 試験直前は、このノートを何度も見返して同じような問題が出たときに間違えないように復習しました。 3.それ以外で取り組んだこと AWS主催のウェビナーに参加しました。 AWS主催のウェビナーというと、ハンズオンや技術者向けの内容が多いイメージですが、初心者向けの内容も充実しています 初心者向けのウェビナーだと「コンテナとは?」や「ECSを使うメリット」のような話を分かりやすく説明してくれますので、自分の理解の答え合わせになります。 他にもウェビナーのなかで事例や実際の操作画面を知ることができたのもよかったです。 また、ウェビナー参加後にアンケートに答えるとAWSのクレジットコードがもらえることがあり、ハンズオンの時に発生する費用負担を軽減することができます 実際に試験を受けてみて 暗記で答えられる問題は少なく、「ソリューションアーキテクトとしてどのように対応するのがベストか?」という視点に立った問題が多く、本質的に理解出来ているかを問うているように感じました。 前述の模試でもそういった問題が多く含まれているので、自分が理解できるまで調べたり繰り返し問題を解いたりすることをお勧めします 余談ですが、何を焦っていたのか会場についてすぐに受付→試験に入りました。 暑さの影響か、試験開始20分くらいは頭が働かず最初の10問くらいはまともに答えることができませんでした 一通り解いた後、時間ぎりぎりまで見直しをして、何問か答えを修正しました。 会場に着いたらしっかり水分補給して呼吸を整えてから試験に臨むことをお勧めします。笑
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【12日目】AWS認定ソリューションアーキテクト合格までの道

データ通知/連携処理サービス データ通知/連携処理サービスの概要 アプリケーションで自ら実装しなくても、データの通知/連携処理を簡単に行うことができるサービス Eメール送信を実現するAmazon Simple Email Service(SES) プロトコルやサービスにデータの配信を行うAmazon Simple Notification Service(SNS) など メッセージキューイング処理サービス ◉Amazon Simple Queue Service(SQS) メッセージをキューイングすることで、処理負荷の大きいビデオのエンコーディング(圧縮作業)などのバッチ処理を、複数のEC2インスタンスに振り分けて分散処理する場合に利用する ◎メッセージキューイング 異なるソフトウェア間でデータを送受信する手法の一つ 直接データを渡すのではなく一旦第三者のソフトウェアに預けることで、送信側も受信側も好きなタイミングで送受信処理を行うことができるようにする方式 ・通常、実行中のプログラム間でデータの受け渡しを行うには、送信処理と受信処理をタイミングを合わせて同時に行う必要がある ・お互い相手側の処理が開始あるいは完了するのを待たなければならない バッチ処理 あらかじめ登録した一連の処理を自動的に実行する処理方式 通知処理サービス ◉Amazon Simple Email Service(SES) WebアプリケーションからSESで提供されるAPIを実行することで、メールを利用して簡単に通知を行うことができる ◉Amazon Simple Notification Service(SNS) AWSで提供されるメッセージ通知サービス 任意のメッセージをHTTPSなどの様々なプロトコルでアプリケーションから簡単に送信することができる CloudWatch/SQS/Lambdaなど様々なサービスへの通知/連携が可能 ◎SNSの要素 トピック メッセージを受信するアクセスポイント 作成し、購読者がトピックを購読(サブスクライブ)することで通知の送受信が可能になる 購読者(サブスクライバ) 対象となるトピックから発信されるメッセージの購読者(サブスクライバ)を設定する HTTP/HTTPS Email SQS Lambda など メッセージの発行(パブリッシュ) 作成したトピックに対して、アプリケーションからメッセージを発行する SNSサービスを通じて登録されているサブスクライバへ配信される メッセージを配信(パブリッシュ)/購読(サブスクライブ)する形式をPub/Subと呼ばれる パイプライン処理サービス ◉AWS Data Pipeline DBからデータの取り出し/変換/保存(ELT:Extract Transform Load)など、データに対して順次処理(パイプライン処理)を行うサービス ◎Data Pipelineの特徴 ELT処理をスケジュール機能で自動化 データのパイプライン処理をワークフロー形式で定義 処理の成功/失敗などのイベントの通知が可能 オンプレミス環境との連携が可能 ストリーミング処理サービス ◉Amazon Kinesis IoTなどのデバイスからデータをリアルタイムに受信して分析する場合に利用する ◎Kinesisの構成サービス 種類 内容 Kinesis Data Streams ストリーミングデータの収集 Kinesis Data Firehose ストリーミングデータの保存 Kinesis Data Analytics ストリーミングデータの分析 Kinesis Video Streams 動画のストリーミング処理 イベント連携処理サービス ◉Amazon EventBridge AWS各種サービスや外部のSaaSなどの様々なイベントソースを他サービスの様々なターゲットにリアルタイムに連携するハブのようなサービス 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【DR対策】AWSを利用した障害復旧シナリオ

概要  クラウドサービスを利用するにあたって、障害が生じた際にどれだけ迅速に復旧が実行できる構成が取れているか、という観点が重要だと言われている(Design for Failure)。  AWSのホワイトペーパーで取り上げられている以下の4つの DR 対策をまとめる。 バックアップとリストア パイロットライト ウォームスタンバイ マルチサイト(ホットスタンバイ) 注意されたい事項 記述される構成は一例であるということ。 DNS のフェイルオーバーに関しては省略する。 本番環境は On-premise または Region 1, スタンバイ環境は Region 2 とする。 バックアップとリストア  準備段階においては、Storage Gateway のボリュームゲートウェイ(Gateway-cached Volumes)を使用して On-premise 環境から S3 にバックアップを取る。  復旧段階においては、AWS 環境で EC2 インスタンスを立ち上げ、取得済みのバックアップ(ここでは EBS スナップショット)から EBS ボリュームを復元し、インスタンスへアタッチする。  バックアップとリストアはバックアップを取得しておいて、障害時にはリソースを展開し、データをバックアップから復旧させる手法。 パイロットライト  pilotlight は種火という意味。ガスコンロを使用するときの "カチカチカチ" って鳴るあれを思い出すと良い。pilotlight 自体は小さな火であるが、ガスに点火することによって一気に炎が広がっていく。  この様子を障害復旧の構成に例えたものである。 準備段階においては、本番環境で起動しているインスタンスの AMI をスタンバイ環境に保存し、DB のリードレプリカを配置しておく。  復旧段階においては、AMI からインスタンスを起動、リードレプリカをメイン DB に昇格させることで障害時の対応を行う。  パイロットライトは復旧リージョンで最小限の構成を行っておいて、障害時にはそれらに基づいてリソースを展開して復旧を図る手法。 ウォームスタンバイ  準備段階においては、スタンバイ環境で本番環境と同様の構成でリソースを配置し起動しておく。ただしこのとき、リソースのスペックは本番環境に比べて低いものを配置しておく。  復旧段階においては、トラフィックをスタンバイ環境に向け、本番環境のアクセス数に対応できるように、スケールアウト・スケールアップを行う。  ウォームスタンバイはパイロットライトの拡張版で、低スペックのリソースを配置して起動しておき、障害時にはそれらのリソースのスケールアップ・スケールアウトを行って復旧を図る手法。 マルチサイト(ホットスタンバイ)  準備段階において、スタンバイ環境でリソースを本番環境と同様の構成かつスペックで配置し起動しておく。  復旧段階においては、トラフィックをスタンバイ環境に向ける。  マルチサイトはウォームスタンバイの拡張版で、本番環境と同じ構成をスタンバイ環境で取っておき、障害時に迅速に復旧を図る手法。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Nitro Enclaves とは

勉強前イメージ ニトロの飛び地・・・・? 文字からは想像できない 調査 AWS Nitro Enclaves とは 個人識別情報や、ヘルスケア、財務のデータなど 機密性の高いデータをより安全に処理できるように 信頼性の高い分離された堅牢なデータ処理環境を提供するEC2の機能で 分離されたコンピューティング環境を作成して安全に簡単にしました。 メモリとCPUの分離を行った仮想マシンを利用し、 永続なストレージを持たず管理者もアクセス出来ず、外部ネットワークとは接続出来ません。 割り当てるCPUとメモリの量を指定でき、要件に合わせてリソースを割り当てることが出来ます。 AWS Nitro Enclavesのメリット 追加的分離とセキュリティ Enclavesは分離された仮想マシンで 永続的なストレージを持たず、アクセスも出来ません。 ローカル接続のみ可能です。 分離されることで攻撃対象の領域を狭めることが出来ます。 暗号化証明 許可されたコードのみが実行できるようになっており 証明はエンクレーブで実行されていることを確認出来ます。 リソースの柔軟な割当 現在のEC2と同様に処理ができるよう、 エンクレーブにはCPU・メモリの組み合わせが多様です。 AWS Nitro Enclaves 設定の画面 EC2の作成時にAWS Nitro Enclavesを設定するかを選べます。 ただし、要件として以下3つがあります。 Nitroベースのインスタンスであること インスタンスのvCPUが4以上であること Linux OSであること 画面としては、以下のインスタンス詳細設定 > 高度な詳細 から Enclave にチェックを入れることで可能です。 勉強後イメージ あまり小さすぎるインスタンスでは使用できないのね。 localからの接続しか出来ないから安全で、 機密性の高いデータを管理・処理するための環境。 参考 AWS Nitro Enclaves EC2で稼働するアプリケーションにさらなる環境分離を提供!!Nitro Enclavesを試してみた
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS DeepRacerを使ってみた

はじめに この記事ではAWS DeepRacer(以下、DeepRacerと略)を使用してみたため、以下の事柄を紹介します。 ※これからDeepRacerを手軽に始めたい方向けの内容のため、細かな内容は説明しません。 DeepRacerの概要(DeepRacerとは?お金はかかるの?開発者は何をするの?などなど) DeepRacerを利用してみた(モデルの作成から3Dシミュレーションのリーグ参戦まで) ※モデル・・・ざっくり言えば、人工知能の処理を行うプログラムのこと DeepRacerとは? 強化学習を使用してレーシングカーをレーシングコースに自走させて、他のユーザと競ったり、タイムアタックなどを行うサービス 強化学習(というか、人工知能)の知識はあまり要らない(ただし、強化学習の概要程度は知っていると今後の理解が早くなると思う) DeepRacerは、物理的なレーシングカーに強化学習モデルを搭載して走らせたり、3Dシミュレーター上で走らせたりする(以下は3Dシミュレーターで動かしているイメージ) AWS内でDeepRacerのモデルの作成・学習・評価を一気通貫で行うことが出来る DeepRacerは学習等の処理の裏でAWS SageMaker、AWS RoboMakerを利用するため、SageMaker、RoboMakerからDeepRacerの開発も可能 2021年7月時点では、バージニア北部のリージョンのみ利用可能 DeepRacerのリーグについて DeepRacerではリーグと呼ばれる他のDeepRacerユーザと競い合うイベントがある リーグはオープン部門、プロ部門がある オープン部門は基本的に誰でも参加可能で月単位で開催している物や年単位で開催している物がある 「使ってみた」の章でも記載するが、参加とレースはとても簡単 ・月単位で開催しているリーグ(2021年7月現在) ・年単位で開催しているリーグ(2021年7月現在) オープン部門のリーグで上位10%にランクインすると次の月からプロ部門に参加可能 プロ部門にて月ごとのレースの終わりに上位 16 位に入っているレーサーはプロフィナーレと呼ばれるレースへの参加資格を得ることが出来て、そのレースに上位10位以内に入るとre:Invent における AWS DeepRacer チャンピオンシップカップに出場するための旅費無料の招待旅行を獲得できる 参考URL: https://aws.amazon.com/jp/deepracer/faqs/ 料金体系 料金体系は以下の通りです。 料金がかかること かかる料金 無料利用枠(ただし、DeepRacer利用開始1か月間のみ) モデルの学習・評価 3.5 USD/時間(1モデル辺り) 10時間以内 モデルの保持 0.023 USD/GB/月(1モデル辺り) 5GB以内 DeepRacerの料金体系より DeepRacer利用者として行うこと(ざっくりと) 利用者として行うことは、強化学習のモデルの作成にて使用する以下のパラメータ・pythonコードを設定してボタンをポチポチ押すだけです。 設定する項目 説明 モデル名と説明 モデル名とその説明を設定。リーグには表示されない モデルの学習で使用するコースの選択 単一選択方式 レースのタイプ このモデルが参加するレースの種類。タイムトライアル、物体回避、一騎打ちレースの3種から選択可能 学習アルゴリズム Pro,SACのどちらかを選択 ハイパーパラメータ(モデルの設定値) バッチサイズ(1度に学習するデータ量)や学習率(学習した結果をどのくらいモデルに反映するか)を設定 エージェントの種類 走らせるDeepRacerの種類を選択。2021年7月時点だと2種類選択可能 報酬関数 DeepRacerの脳に相当する部分。DeepRacerの取る行動それぞれに報酬(ポイント)を定義したPython関数で、DeepRacerのモデルはこの報酬関数に基づいて学習を行う。 終了条件 2021年7月時点だと学習する最大時間のみ指定可能(5分~1440分選択可能、デフォルト60分) 使ってみた ※スクリーンショットに失敗してしまい、一部少し画像が少し途切れていますが、お気になさらず。。。 ①AWSにログインし、DeepRacerの画面に移動し、画面右側の「Create model」ボタンを押下する ②DeepRacerを始めるにあたってのレクチャーページが表示されるので、画面下の「Create model」ボタンを押下する DeepRacerの内容をもう少し知りたい場合は、Step 1のコースを受講してみてください。 ③モデルの名前と説明、学習に使用するコースを入力します。  今回、以下としました。  ・モデル名に「MyFirstModel」  ・説明は「model for play」  ・コースは「re:Invent 2018 Wide」  設定出来たら画面下の「Next」ボタンを押下してください。 ④レースタイプと学習アルゴリズム、ハイパーパラメータ、エージェントの種類を設定します。  今回、以下としました。  ・レースタイプに「Time Trial」(時間を競い合うレース)(デフォルトの物を使用)  ・トレーニングアルゴリズム、ハイパーパラメータ、エージェントはデフォルトの物を使用  何も設定せず、画面下の「Next」ボタンを押下してください。 ⑤報酬関数、終了条件、モデル作成後すぐにリーグに参戦するかどうかを設定します。  今回、以下としました。  ・報酬関数はデフォルトの物を使用。(この報酬関数はコースの真ん中を走ると報酬が大きくなるようになっている)   ・終了条件は10分(デフォルトは60分、10分にした理由は60分は長そうな気がしたためで、あまり意味なし)  ・モデルが出来たらリーグ参戦するかどうかは、チェックをする(デフォルト)   ⇒チェックすると月1のリーグに参加される  ・リーグに参加した際のレーサーの名前は任意  設定出来たら画面下の「Create model」ボタンを押下してください。 ⑥学習が始まるため、しばらく待つと以下の通り、画面の右上に「Completed」が表示される ⑦DeepRacerの画面左のメニューから「AWS Virtual Circuit」を押下して、Open Division(オープン部門)を見てみる  ⇒作成したモデルの走行した結果がランキングに乗ります。  Open Divisionの「Leaderboard」を押下する ⑧ランキングが表示され、走行した動画が以下のランキングの「Watch」リンクから確認できる ・ランキング ・動画(20秒程度) さらなる情報 この記事では手軽にDeepRacerを使ってみましたが、今後、リーグ戦に挑戦してランキング上位に行きたい場合は以下を調べると良いかもしれません。 ※「かもしれません」と書いたのは筆者自身リーグのランキング上位に入ったことがないので>え 強化学習の仕組み 報酬関数についての詳細
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む