Lambda上でmatplotlibを使ってグラフを作成したいとき、Lambdaには日本語フォントが含まれていないため日本語が豆腐になってしまいます。この記事では、日本語対応するための方法について説明します。 前提 matplotlibは別途利用できるようにレイヤーなどで用意する必要があります。 やり方 Lambdaレイヤーに日本語フォント用のレイヤーを登録 Lambda関数に日本語フォント用のレイヤーを追加 matplotlibでフォント読み込み 1.Lambdaレイヤーに日本語フォント用のレイヤーを作成 　日本語フォントなら基本的に何でもOKと思いますが、今回はIPAexゴシック（ipaexg.ttf）をダウンロードして使いました。 　ダウンロードしたttfファイルを適宜ディレクトリ（例えばfontsなど）に入れてzip圧縮します。 　Lambdaのレイヤーページから「レイヤーの作成」にて作成画面に移動し、アップロードにて先程圧縮したzipファイルを選択してレイヤーを作成します。 2. Lambda関数に日本語フォント用のレイヤーを追加 　グラフを作成するメインLambda関数に、先程作成した日本語フォント用のレイヤーを追加します。 3. matplotlibでフォント読み込み 　font_managerのFontPropertiesにてレイヤーで登録したttfファイルを指定すれば日本語が使えるようになります。レイヤーは/optにバインドされますので適宜指定してください。 import matplotlib.font_manager as fm # 日本語フォント設定 prop = fm.FontProperties(fname='/opt/fonts/ipaexg.ttf') ・・・略・・・ ax.set_xticklabels(labels, rotation=45,　fontproperties=prop) その他 ttfファイル自体をLamba関数に含めることでも実現可能ですが、容量が大きいためWebIDE上でコードの編集ができなくなる可能性があります。 他の方法として、japanize-matplotlibのレイヤーを作ってもよいかもしれませんが、試してません。

Windows１０ MySQL 8.0.20 Amazon　AWS 勉強のために、WebアプリケーションをAWSに構築しています。 AWSを使い、RDSを作成するが サブネットグループの作成、 パラメータグループ作成 名前など間違えないように注意しないといけない。 RDSなら DB インスタンス識別子 AWS Systems Manager パラメータ名 /プロジェクト名/dev/app/MYSQL_DATABASE /プロジェクト名/dev/app/MYSQL_HOST /プロジェクト名/dev/app/MYSQL_PASSWORD（値でのパスワード入力も注意） /プロジェクト名/dev/app/MYSQL_PORT　（値でのポート番号） /プロジェクト名/dev/app/MYSQL_USERNAME ここの設定はよく丁寧に確認した方が良いと思います。 設計したパラメータ名が正しく入力されていないとAPサーバー構築してからデーターベースに接続できないなどの エラーが発生します。 その他 データーベースのセキュリティグループ名 IAMロールのチェックも念入りにチェックを推奨。 一文字間違えたおかげで、はまりました。 プログラミングと同じですね。 特にデーターベース周りはタイプミスするとWeb公開時にプラウザで確認するとこんなエラーが出ます。 ```` Error: connect ECONNREFUSED 127.0.0.1:3306 at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16)

結論 Terraform用にEC2インスタンスを立てて、そこからterraformを実行しましょう。 ※2021/08/07追記 この方法は悪手であるとのご指摘をいただきました。詳細はコメント欄に記載されていますが、使用しているチームやアカウントの状況によっては不向きとのことでした。 その他ご意見のある方もご意見があればご指摘お願いします。 Terraformを学ぶ際に私が行っていたこと 1.Terrafrom用のユーザを作成 2.Terraform用のユーザのクレデンシャル情報(アクセスキーID、シークレットアクセスキー)をダウンロード 3.アクセスキー、シークレットアクセスキーをtfvarsに記載 アクセスキーID、シークレットアクセスキーをダウンロードすることの問題性 何かしらのアクシデントでアクセスキーIDやシークレットアクセスキー漏洩した場合、不正利用される可能性がある。 例） ・githubに誤pushしてしまう。※git-secretの利用で防ぐことはできます。 ・ダウンロードしたマシンがウィルスに感染して情報漏えいしてしまう。 etc. 具体的な対処方 1.プライベートサブネットにEC2インスタンスを構築、terraformをインストール 2.IAMロールを作成、必要に応じて最小権限のポリシーを設定 3.作成したIAMロールをEC2インスタンスにアタッチ 4.これでterraformを安全に使えます 気づきにつながったブログ　ありがとうございます。

はじめに AWSって何とSSMセッションマネジャーって何と言った話はここでは書きません。(自分より上手く説明してくれる人がいっぱいいるはずですので、ググってそちらを参照してください。) SSMセッションマネジャーの初期設定についても書きません。 設定できている前提で記事を書かせていただきます。(こちらも同じく、別でググてみてください。) AWS CLI、セッションマネジャー用プラグインは事前にインストールしておいてください。 読んで欲しい人 最近AWSを使い始めた人 SSMセッションマネジャーを使いたい人 teratermを使っている人 背景 EC2でサービス運用していると基本的にSSHは必須のツールですが、皆さんどのように接続しているでしょうか? 最近自分の身の回りではセキュリティを高めるため、踏み台サーバを使った接続から、SSMセッションマネジャーを使うようにしたいのですが、ここで問題がありまして、自分の身の回りではteratermの利用率が高いのです。 何が問題かというとteratermを普通に利用するとSSMセッションマネジャーを介した接続は基本的にできません。かと言って現状大きな問題が起きていないのに、公式がやり方を公開している、windwos向けのOpen SSHに切り替えてとはなかなか言いづらい。 公式のドキュメント https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html ポートフォワードで解決する SSMはポートフォワードできるので、今回はポートフォワードすることで解決します。 公式のドキュメント https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#sessions-start-port-forwarding 不便 サーバ接続するたび下記のようなコマンドをコマンドプロンプトを立ち上げて入力して使うのでは不便でteratermから問題なくSSMセッションマネジャーを使えるとは言いづらい状況なので、Teratermのマクロを使いある程度自動化します。 公式ドキュメントより aws ssm start-session ^ --target instance-id ^ --document-name AWS-StartPortForwardingSession ^ --parameters portNumber="3389",localPortNumber="56789" マクロ化 事前にAWSのコンソールからSSHするためのログインアカウントは作成しておいてください。 ログインユーザ名、鍵ファイルのパスは空なので自身の環境に合わせて入れてください。 .ttl ; 使用者ごとに変更が必要な変数 ;============================ ;鍵ファイルのパス KEY_FILE_PATH='' ;ログインユーザ名 USERNAME = '' ;============================ ; EC2リスト strdim msg 10 msg[0] = '' listbox 'どのEC2に接続しますか' 'ターゲット選択' msg int2str LOCALPORT5 result LOCALPORT = '1002' strconcat LOCALPORT LOCALPORT5 if result == 0 then EC2TARGET = 'i-XXXXXXXXXXX' endif ; AWS CLI SSMCOMMAND = 'aws ssm start-session --target ' strconcat SSMCOMMAND EC2TARGET strconcat SSMCOMMAND ' --document-name AWS-StartPortForwardingSession --parameters portNumber=22,localPortNumber=' strconcat SSMCOMMAND LOCALPORT strconcat SSMCOMMAND ' --profile ' strconcat SSMCOMMAND '' exec SSMCOMMAND ; SSH pause 1 HOSTNAME = 'localhost' ;msg = 'Enter password for user ' ;strconcat msg username ;passwordbox msg 'Get password' SSHCOMMAND = HOSTNAME strconcat SSHCOMMAND ':' strconcat SSHCOMMAND LOCALPORT strconcat SSHCOMMAND ' /ssh /2' strconcat SSHCOMMAND ' /auth=publickey ' strconcat SSHCOMMAND '/user=' strconcat SSHCOMMAND USERNAME strconcat SSHCOMMAND ' /keyfile=' strconcat SSHCOMMAND KEY_FILE_PATH connect SSHCOMMAND プロファイルは空欄になっているので、自身の環境に合わせて変更してくさださい。 strconcat SSMCOMMAND ' --profile ' strconcat SSMCOMMAND '' 下記の空欄にはサーバかを識別できる文字列を入れてください。 またmsg[1] = ''のような形でマクロ起動時に出る、選択できるサーバの数を増やせます。 msg[0] = '' EC2TARGETには接続したいEC2のインスタンスIDを入れてください。 複数ある場合はif文を増やしてください。 if result == 0 then EC2TARGET = 'i-XXXXXXXXXXX' endif if result == 1 then EC2TARGET = 'i-YYYYYYYYYYY' endif おまけ: WinSCPを使いたい このマクロは選択肢が一番上に来るEC2インスタンスなら10020、その1つ下なら10021と連番でポートフォワードをしているマクロです。 なので、選択肢の一番上のEC2インスタンスに接続する場合はこのマクロを起動した状態でポート番号を10021、ホストをローカルホストにすることでWinSCPを使ってファイル転送をできます。

環境 AWS Docker Python django EC2構築 AWSにログイン EC2 ＞ インスタンスを起動をクリックする。 以下を選択する。 OS:Amazon Linux 2 AMI (HVM), SSD Volume Type インスタンスタイプ:t2.micro ネットワーク:デフォルトVPC デフォルトVPCを使うのはベターではないが、とりあえずインターネットに繋がっていれば良いので使用する。 自動割り当てパブリック IP ：有効 ストレージ:8GiB キー:Name,値:Docker-demo セキュリティグループ名：DockerDemo-EC2-SG,説明：DockerDemo-EC2-SG タイプ プロトコル ポート範囲 ソース 説明 SSH TCP 22 カスタム 0.0.0.0/0 - 【設定概要】 VSCodeのRemote-sshでEC2へ接続する...ための事前設定 VSCodeだとフォルダツリーとかグラフィカルで直感的に操作できる。 VSCodeの拡張機能でRemote-SSHをインストール (Macの場合)ターミナルで以下のディレクトリに設定内容を記載する。 ディレクトリ：/Users/(ユーザのホームディレクトリ)/.ssh/config 設定内容： Host Test-EC2 HostName (EC2インスタンスのパブリックIP) IdentityFile (秘密鍵の場所) User ec2-user 以下、設定ログ。 $ cd $ ls -la ~省略~ drwx------ 3 xxxxxx staff 96 1 19 2018 .ssh $ cd .ssh $ touch config $ vi　←ここで設定内容を記載 $ ls -l -rw-r--r-- 1 masudayoshiki staff 117 8 6 18:17 config -rw-r--r-- 1 masudayoshiki staff 2764 5 28 15:59 known_hosts $ cat config Host Test-EC2 HostName (EC2インスタンスのパブリックIP) IdentityFile (秘密鍵の場所) User ec2-user VSCodeのRemote-sshでEC2へ接続する 左下の緑色のSSH:...をクリックする。これは事前設定で作成したconfigのHost 検索窓が出たら、Connect to Host ＞　Test-EC2をクリックする。 これでSSH接続は完了するので、あとはフォルダを開いたり、ターミナルを開いてコマンドを実行する。 いろいろとインストールする前の準備 sudo yum update -y Dockerのインストール&セットアップ sudo amazon-linux-extras install -y docker sudo usermod -a -G docker ec2-user sudo systemctl start docker.service sudo systemctl status docker.service sudo systemctl enable docker.service Docker-composeのインストール&セットアップ sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose アプリに必要なツールのインストール Pythonやそのパッケージをインストールする。 sudo yum install -y python37 python3-devel gcc jq tree git git clone https://github.com/AWSCLOUDTECH/tutorial.git cd tutorial/todobackend cd src pip3 install -r requirements.txt --user python3 manage.py migrate python3 manage.py runserver 0.0.0.0:8000 djangoやPythonのセットアップ アプリのダウンロード＆起動

以前にAWS SAMを使ったLambda開発をしてみましたが、今回はAWS SAMと比較しつつ、Serverless Frameworkを使ったLambda開発を試してみます！ Serverless Frameworkとは Serverless FrameworkはAWS、Azure、GCPなどマルチクラウドに対応したサーバーレスアプリケーション開発フレームワークです。 オープンソース版とPro版があり、Pro版ではCI/CDやモニタリングの機能が使えますが、今回はオープンソース版を試してみます。 準備 Serverless Frameworkのインストール Serverless Frameworkをインストールします。 スタンドアロンバイナリとnpmでインストールできるようですが、今回はnpmでインストール。 後述するプラグインでもnpmを使ったりするので、Node.jsの環境は用意しておいた方が良さそうです。 npm install -g serverless 認証情報を設定する Serverless Frameworkで使用する認証情報を設定しておきます。 AWSで使用する場合は以下を参考に。 本番/ステージングで使用する環境は異なると思うので、AWS CLIを使ってプロファイルを作成しておき、serverless deploy --aws-profile [Profile]で指定するか、serverless.ymlで設定するのが良さそう。どこにも設定がないとAWS CLIのデフォルト認証が使用されるので注意！ テンプレートをダウンロード AWS - Python - Starterを見てみます。 $ serverless What do you want to make? AWS - Python - Starter What do you want to call this project? aws-python-project Downloading "aws-python" template... Project successfully created in aws-python-project folder You are not logged in or you do not have a Serverless account. Do you want to login/register to Serverless Dashboard? No Do you want to deploy your project? No Your project is ready for deployment and available in ./aws-python-project Run serverless deploy in the project directory Deploy your newly created service Run serverless info in the project directory after deployment View your endpoints and services Run serverless invoke and serverless logs in the project directory after deployment Invoke your functions directly and view the logs Run serverless in the project directory Add metrics, alerts, and a log explorer, by enabling the dashboard functionality テンプレートで作られるファイルはかなりシンプル。 aws-python-project/ ├── README.md ├── handler.py └── serverless.yml handler.py 単純なHTTPレスポンスを返すだけ。 import json def hello(event, context): body = { "message": "Go Serverless v2.0! Your function executed successfully!", "input": event, } return {"statusCode": 200, "body": json.dumps(body)} serverless.yml 最低限の設定のみという感じ。 service: aws-python-project frameworkVersion: '2' provider: name: aws runtime: python3.8 lambdaHashingVersion: 20201221 functions: hello: handler: handler.hello デプロイのプロファイルやリージョンの設定をserverless.ymlファイルで設定できるようです。 ローカルテスト $ serverless invoke local --function hello { "statusCode": 200, "body": "{\"message\": \"Go Serverless v2.0! Your function executed successfully!\", \"input\": {}}" } レスポンスが確認できます。 --dockerオプションを付けるとAWS SAMと同様にdockerを使ってLambda環境を再現して実行できます。 $ serverless invoke local --function hello --docker Serverless: Packaging service... Serverless: Excluding development dependencies... Serverless: Downloading base Docker image... Serverless: Writing Dockerfile... Serverless: Building Docker image... START RequestId: df3eb7b9-2565-1436-ffc9-4b7504a0a6c8 Version: $LATEST END RequestId: df3eb7b9-2565-1436-ffc9-4b7504a0a6c8 REPORT RequestId: df3eb7b9-2565-1436-ffc9-4b7504a0a6c8 Init Duration: 115.71 ms Duration: 3.05 ms Billed Duration: 4 ms Memory Size: 1024 MB Max Memory Used: 29 MB {"statusCode":201,"body":"{\"message\": \"Go Serverless v2.0! Your function executed successfully!\", \"input\": \"\"}"} ちなみに使用されるDockerイメージはこちら。 デプロイ $ serverless deploy --region ap-northeast-1 Serverless: Packaging service... Serverless: Excluding development dependencies... Serverless: Creating Stack... Serverless: Checking Stack create progress... ........ Serverless: Stack create finished... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading artifacts... Serverless: Uploading service aws-python-project.zip file to S3 (2.24 KB)... Serverless: Validating template... Serverless: Updating Stack... Serverless: Checking Stack update progress... ............... Serverless: Stack update finished... Service Information service: aws-python-project stage: dev region: ap-northeast-1 stack: aws-python-project-dev resources: 6 api keys: None endpoints: None functions: hello: aws-python-project-dev-hello layers: None デプロイ時のオプションでもプロファイルやリージョンの設定ができます。 Serverless FrameworkでもAWS SAMと同様にCloud Formationでデプロイが行われます。 AWS SAMと異なりアプリケーションごとにLambdaをアップロードするS3バケットが作られるようです。 今回のケースではaws-python-project-devというスタックで、S3バケットとLambdaが作られていました。 プラグイン AWS SAMにはないServerless Frameworkの目玉機能な気がします。 JavaScriptで書かれたコードでServerless Frameworkに新しいコマンドを追加したり、既存のコマンドの処理を拡張したりできます。 現時点で1000以上のプラグインが公開されているようですが、Serverless自体がAWS Lambda向けの開発から始まっているためか多くはAWS Lambda向けのものとなっています。 便利そうなプラグインをいくつか列挙しておきます。 Serverless Python Requirements デプロイする際にrequiremets.txtを読み込んで、依存する外部モジュールをバンドルする。 Pythonでパッケージ依存関係がある場合は必須。requiremets.txtだけでなくPipenv、Poetryにも対応してるのも良い！！ Serverless Offline LambdaとAPI Gatewayをエミュレートするコマンドを追加する。 ローカルで簡単にHTTPリクエストを投げてテストできる。 まとめ 細かい動作に違いはありましたが、基本的なことする分にはServerless FrameworkとAWS SAMどちらを使ってもあまり変わりないかなという印象でした。 ただServerless Frameworkにはマルチクラウド、プラグインといった特徴があり、これを生かすことができる環境であればかなり有力な選択肢になるのではないでしょうか。

はじめに RDSのスナップショットからDBを復元する際に、少し手間取ったため、記録します。 1.DB識別子を確認 現在使用しているDBの識別子を確認します。( RDS>データベース にて確認可能 ) 2.現在のDB識別子を変更 はじめに確認したDB識別子を適当なものに変更します。 3.スナップショットから復元 ①対象のスナップショットを選択し、アクションから「スナップショットを復元」を選択（RDS>スナップショット） ②インスタンス識別子は"元のインスタンス識別子"を指定する ③DBインスタンスクラスは無料枠の場合、以下を選択。 ④「DBインスタンスを復元」をクリック 4.復元したDBインスタンスのセキュリティグループを変更 スナップショットからの復元の場合、セキュリティグループが引き継がれないため、設定する必要があります。 元のDBインスタンスと同じ設定にすることで、アプリケーションからの接続が可能になります。 5.まとめ スナップショットさえあれば意外と簡単にDBの復元が可能でした。 復元するDBがすでに存在しておらず、DB識別子が不明な場合は、以下の手順で復元・設定が可能です。 ・3①で新規識別子を作成　→　アプリケーションのDB設定にて、新規作成した識別子を指定 6.参考 DB のスナップショットからの復元

はじめに EC2内にインストールしてあるDockerを、AWS EFSとマウントすることをやってみました。 手順を公開したいと思います。 ・EC2のOS：Ubuntu 20.04.2 LTS ・Dockerバージョン：Docker version 20.10.8, build 3967b7d 構成図 簡単に説明すると、 １.EC2内にDockerをインストールしておリます。 ２.EFSがEC2とマウントしておリます。 ３.DockerがEFSとのマウントを実現できております。 １.EC2内にDockerをインストール UbuntuにDockerをインストールにあたって、下記の記事が大変参考になりました。 記事に従ってインストール作業をしたら、Dokcerのインストールが無事に完了しました。 $ docker --version Docker version 20.10.8, build 3967b7d ２.EC2とEFSをマウント EFSの作成手順はここで割愛させていただきます。 EC2とEFSのマウント方法は、下記の記事が大変参考になりました。 記事に従って操作すると、EC2内に/mnt/efsディレクトリーを作成しておき、それをEFSとのマウントを実現できておリます。 $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 20G 2.2G 18G 12% / devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 388M 900K 387M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/loop1 26M 26M 0 100% /snap/amazon-ssm-agent/4544 /dev/loop0 34M 34M 0 100% /snap/amazon-ssm-agent/3552 /dev/loop3 71M 71M 0 100% /snap/lxd/19647 /dev/loop4 33M 33M 0 100% /snap/snapd/11588 /dev/loop2 56M 56M 0 100% /snap/core18/1997 fs-XXXXXXXXX.efs.ap-northeast-1.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs overlay 20G 2.2G 18G 12% /var/lib/docker/overlay2/193018e5f21d57c9462cc7f9d6ed33f83a59506c599d3d4739d3d81712c52469/merged tmpfs 388M 0 388M 0% /run/user/0 また、/etc/fstabにEFSの情報を登録することによって、EC2が起動されるタイミングで、自動的にEFSとマウントを実現することができます。 $ cat /etc/fstab LABEL=cloudimg-rootfs / ext4 defaults,discard 0 1 fs-XXXXXXXXX:/ /mnt/efs efs defaults,_netdev 0 0 EFS内に確認用のlalala.txtファイルを作成し、中に適当に文字を入れておきます。 $ pwd /mnt/efs $ sudo touch lalala.txt $ sudo chmod 775 lalala.txt $ sudo vi lalala.txt $ cat lalala.txt 123123lalala ３.DockerとEFS間のマウントを実現 今回はnginxのDockerを使用し、EFSとのマウントを試してみました。 まずはnginxのDokcerをインストール前に、Dockerがないことを確認します。 $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES EC2上の/mnt/efsはすでにEFSとマウントしてありますので、 これからはnginxのdocker内に/mnt/efsをEC2上の/mnt/efsをマウントし、 DockerとEFSのマウントを実現します。 $ sudo docker run --privileged=true -it --name nginx -d -p 8080:80 -v /mnt/efs:/mnt/efs nginx /bin/bash 369b6256d0ff62337abb2ca2067a90de2053253da379502fdccc3a95cbe92937 続いてngixnのDocker状態を確認し、起動できていることを確認しております。 $ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 369b6256d0ff nginx "/docker-entrypoint.…" 31 seconds ago Up 31 seconds 0.0.0.0:8080->80/tcp, :::8080->80/tcp nginx nginxのDocker内部へ接続していきます。 $ sudo docker exec -it 369b6256d0ff bash root@369b6256d0ff:/# nginxのDocker内部の/mnt/efsに移動します。 root@369b6256d0ff:/# ls -all total 80 drwxr-xr-x 1 root root 4096 Aug 6 03:33 . drwxr-xr-x 1 root root 4096 Aug 6 03:33 .. -rwxr-xr-x 1 root root 0 Aug 6 03:33 .dockerenv drwxr-xr-x 2 root root 4096 Jul 21 00:00 bin drwxr-xr-x 2 root root 4096 Jun 13 10:30 boot drwxr-xr-x 10 root root 3020 Aug 6 03:33 dev drwxr-xr-x 1 root root 4096 Jul 22 10:13 docker-entrypoint.d -rwxrwxr-x 1 root root 1202 Jul 22 10:12 docker-entrypoint.sh drwxr-xr-x 1 root root 4096 Aug 6 03:33 etc drwxr-xr-x 2 root root 4096 Jun 13 10:30 home drwxr-xr-x 1 root root 4096 Jul 22 10:13 lib drwxr-xr-x 2 root root 4096 Jul 21 00:00 lib64 drwxr-xr-x 2 root root 4096 Jul 21 00:00 media drwxr-xr-x 1 root root 4096 Aug 6 03:33 mnt drwxr-xr-x 2 root root 4096 Jul 21 00:00 opt dr-xr-xr-x 177 root root 0 Aug 6 03:33 proc drwx------ 2 root root 4096 Jul 21 00:00 root drwxr-xr-x 3 root root 4096 Jul 21 00:00 run drwxr-xr-x 2 root root 4096 Jul 21 00:00 sbin drwxr-xr-x 2 root root 4096 Jul 21 00:00 srv dr-xr-xr-x 13 root root 0 Aug 6 03:33 sys drwxrwxrwt 1 root root 4096 Jul 22 10:13 tmp drwxr-xr-x 1 root root 4096 Jul 21 00:00 usr drwxr-xr-x 1 root root 4096 Jul 21 00:00 var root@369b6256d0ff:/# cd /mnt/efs root@369b6256d0ff:/mnt/efs# pwd /mnt/efs EFS上のファイルがDocker内にあることを確認できておリます。 root@369b6256d0ff:/mnt/efs# ls lalala.txt root@369b6256d0ff:/mnt/efs# cat lalala.txt 123123lalala さらに、nginxのDocker内に、ファイルを作成してみました。 root@369b6256d0ff:/mnt/efs# touch dadada.txt root@369b6256d0ff:/mnt/efs# ls dadada.txt lalala.txt nginxのDockerをログアウトし、EC2画面に戻り、EC2でEFS上の内容を確認しておくと、同じように、先ほど作成したファイルがあることを確認できておリます。 root@369b6256d0ff:/mnt/efs# exit exit $ pwd /mnt/efs $ ls dadada.txt lalala.txt これでEC2内のDockerをEFSとマウントは実現できました。

はじめに 転職活動の際にポートフォリオとして、Javaを使用したアプリケーションを作成しました。 GitHubへソースコードをプッシュすると、AWS上のEC2へデプロイされるように環境を作成した際のメモを残そうと思います。 Codeシリーズの作成方法などは他の記事を参照して頂き、本記事では ・デプロイされるときに、自動的に本番環境の設定ファイルでデプロイされるようにしたい！！ となったときに、各種設定ファイル(Mavenのpom.xmlや、CodeBuildのbuildspec.yml、CodeDeployのappspec.yml）の書き方についてざっくり触れていきたいと思います。 どなたかの参考になれば幸いです。 ※環境作成から本記事の執筆に時間が空いてしまったため、思い出しながら記載しています。誤りがあってもあしからず・・・ 処理の流れ GitHubへコードをプッシュ→CodePipelineが起動→CodeBuildでソースコードのビルド(&テスト)→CodeDeployでEC2へデプロイ イメージ図 やった事 作成するアプリは、Mavenプロジェクトとして作成しました。 ディレクトリ構成は下記の通りです。 アプリケーションディレクトリ |-- pom.xml |-- buildspec.yml ←CodeBuildで使用 |-- appspec.yml ←CodeDeployで使用 |-- src |-- main | |-- java | |-- modelとかcontroller | |-- config | |-- honban ←本番用の設定ファイルを配置 | `-- context.xml　とか | |-- local ←ローカル用の設定ファイルを配置 | `-- context.xml　とか |-- test |-- java |-- modelテストコードとか ローカル環境と本番環境では、DB接続パラメータが異なるため、ビルド時のパラメータでローカルか本番かを分けて、ビルド出来るようにpom.xmlを作成します。 pom.xml(抜粋) <build> <finalName>calendar</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.0</version> <configuration> <source>${java.version}</source> <target>${java.version}</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.22.1</version> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>3.2.2</version> <configuration> <webResources> <resource> <directory>${contextxml.path}</directory>　　←ここでcontext.xmlのパスを変えれるようにしている。実際のパスは下記のprofileの部分で指定 <targetPath>META-INF</targetPath> <filtering>true</filtering> <includes> <include>context.xml</include> </includes> </resource> <resorce> <directory>${loggingproperties.path}</directory> <filtering>true</filtering> <includes> <include>logging.properties</include> </includes> </resorce> </webResources> </configuration> </plugin> </plugins> </build> <profiles> <profile> <id>local</id>　　←ビルド時にlocalを引数で渡すと、このprofileセクションの値が使用される <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <contextxml.path>src/main/config/local</contextxml.path> <loggingproperties.path>src/main/config/local</loggingproperties.path> </properties> </profile> <profile> <id>honban</id>　　←ビルド時にhonbanを引数で渡すと、このprofileセクションの値が使用される <properties> <contextxml.path>src/main/config/honban</contextxml.path> <loggingproperties.path>src/main/config/honban</loggingproperties.path> </properties> </profile> </profiles> CodeBuildでビルド動作を定義するbuildspec.ymlは下記のように作成しました。 buildspec.yml version: 0.2 env: variables: S3_BUILD_OUTPUT_BUCKET: "calendardeploybucket" phases: install: runtime-versions: java: corretto8 commands: # treeコマンドを使いたいのでインストール - yum install -y tree pre_build: commands: - echo Nothing to do in the pre_build phase... - mvn clean build: commands: - echo Build started on `date` # maven実行(honban用でパッケージ。今回はテストスキップ。。) - mvn package -P honban -DskipTests=true # ソース,java,mavenのバージョンを出力 - echo "--------------------------------------------------" >> version.txt - echo "SourceVersion:"$CODEBUILD_RESOLVED_SOURCE_VERSION >> version.txt - java -version 2>> version.txt - mvn -version >>version.txt - echo "--------------------------------------------------" >> version.txt post_build: commands: - echo Build completed on `date` # treeコマンドで確認 - tree >>tree.txt - aws s3 cp tree.txt s3://$S3_BUILD_OUTPUT_BUCKET # version.txtの移動 - aws s3 cp version.txt s3://$S3_BUILD_OUTPUT_BUCKET # warファイルとappspec.xmlを一つのZIPファイルに固める - zip -r ./calendar.zip ./target/calendar.war ./appspec.yml # S3にzipファイルをアップロード # - aws s3 cp ./calendar.zip s3://$S3_BUILD_OUTPUT_BUCKET artifacts: files: - target/calendar.war - appspec.yml discard-paths: no 諸々、ほかのサイトを参考にした箇所がありますが・・・ 上記のbuildspec.ymlにおいて、大事なのは、ビルドコマンドとして、mvn package -P honban -DskipTests=true を実行しています。 -Pオプションでhonbanを指定することで、pom.xmlのprofileで指定したパスのファイルが使用されます。 テストは通常であれば、スキップせずに実行してください。。 また、CodeBuildでビルドしたwarファイルはS3に格納しますが、その際に、後続のCodeDeployが使用するappspec.ymlも一緒にzipファイルに入れています。 zipで固める際に、CodeBuildが元のファイルを見つけれるように、artifactsのセクションでmvnコマンドで作成されるwarファイルだけでなく、appspec.ymlも指定しています。 ここが一番つまづいた気がします。。 あとは、CodeDeployで使用するappspec.ymlですが、これはそのままwarファイルを配置するだけです。 appspec.yml version: 0.0 os: linux files: - source: target/calendar.war destination: /usr/share/tomcat/webapps/ これで、あとはCodeシリーズを作れば、いい感じにJavaアプリがデプロイされるはず！ どなたかの参考になれば・・・

目的 AWS EC2から特定のプロキシサーバーをを経由してインターネット接続する場合のproxy設定を行う 背景 可用性が求められる環境においては、NATゲートウェイやVPCエンドポイントにインターネット接続を行うのが一般的であるが、開発環境等の可用性が求められない環境においては、コスト最適化のために低スペックのEC2によるプロキシサーバを立てて、インターネット接続させる場合がある。 その際に、設定が必要となった箇所と設定方法についてメモする。 EC2のproxy設定対象箇所 ・OS(Linux)のシステム設定 ・アプリのサービス ・CloudWatchAgent ・SSMAgent ・CodeDeployAgent OSのシステム設定 sudo vi /etc/environment http_proxy="http://{ProxyServerHost}:{Port}/" HTTP_PROXY="http://{ProxyServerHost}:{Port}/" https_proxy="http://{ProxyServerHost}:{Port}/" HTTPS_PROXY="http://{ProxyServerHost}:{Port}/" no_proxy="169.254.169.254" アプリのサービス設定 今回SpringBootアプリをサービス登録しており、その設定ファイルに追加 sudo vi /opt/app/app.conf export http_proxy="http://{ProxyServerHost}:{Port}/" export HTTP_PROXY="http://{ProxyServerHost}:{Port}/" export https_proxy="http://{ProxyServerHost}:{Port}/" export HTTPS_PROXY="http://{ProxyServerHost}:{Port}/" export no_proxy="169.254.169.254" SSMAgentのproxy設定 sudo systemctl edit amazon-ssm-agent [Service] Environment="http_proxy=http://{ProxyServerHost}:{Port}" Environment="https_proxy=http://{ProxyServerHost}:{Port}" Environment="no_proxy=169.254.169.254" 以下のファイル名で保存 /etc/systemd/system/amazon-ssm-agent.service.d/amazon-ssm-agent.override.conf sudo systemctl stop amazon-ssm-agent sudo systemctl daemon-reload sudo systemctl start amazon-ssm-agent CodeDeployAgentのproxy設定 sudo vi /etc/codedeploy-agent/conf/codedeployagent.yml :proxy_uri: 'http://{ProxyServerHost}:{Port}' sudo service codedeploy-agent restart CloudWatchAgentのproxy設定 sudo vi /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml [proxy] http_proxy = "http://{ProxyServerHost}:{Port}" https_proxy = "http://{ProxyServerHost}:{Port}" no_proxy = "169.254.169.254" sudo systemctl stop amazon-cloudwatch-agent sudo systemctl daemon-reload sudo systemctl start amazon-cloudwatch-agent

AWS EC2の初期設定までの流れを備忘録として残しておく。 その中で躓いた部分として、キーペアの保存形式が.pemではなく.cerで保存される、ということがあった。 結論から言うと.pemでも.cerでも関係なくインスタンスログインできる。 左上のアカウントのプルダウンからから「AWSマネジメントコンソール」をクリックしてログイン画面へ遷移。 ルートユーザーとしてログイン ログイン後の画面でEC２を選択 インスタンスを起動をクリック AmazonLinux２　AMIを選択 t2.microを選択。確認と作成をクリック 起動をクリック 新しいキーペアの作成を選択した状態でキーペア名を入力し、キーペアのダウンロード この後キーペアが作成されるのだが、何故か.cerの形式で保存される。（場所は「ダウンロード」） 何かの間違いだと思い再度キーペアを作成してみる。間違いなく.pemを選択する。 しかし、状況は改善されず。同じように.cer形式で保存される。とりあえずこのまま進む。 インスタンスIDをコピーしておき、Elastic IPを作成してインスタンスIDと紐付ける。 ※写真を撮り忘れる。 Elastic IPがインスタンスに紐づいていることを確認 ssh以外のプロトコルでの接続ができるように設定する セキュリティーグループの番号の部分をクリックして、インバウンドルールを編集をクリックし、インバウンドルールを写真のような形になるように編集。（ソースは全てカスタム） ターミナルに移動し、EC2インスタンスにログイン username@Users-MacBook-Pro ~ % mv Downloads/キーペア名.cer .ssh/ username@Users-MacBook-Pro ~ % cd .ssh username@Users-MacBook-Pro .ssh % ls キーペア名.cer username@Users-MacBook-Pro .ssh % chmod 600 キーペア名.cer username@Users-MacBook-Pro .ssh % ssh -i ダウンロードした鍵の名前.pem ec2-user@作成したEC2インスタンスに紐付けたElastic IP username@Users-MacBook-Pro .ssh % ssh -i aws_key.pem ec2-user@52.68.~~~~~~ The authenticity of host '52.68.~~~~~~ (52.68.~~~~~~)' can't be established. RSA key fingerprint is eb:7a:bd:e6:aa:da:~~~~~~~~~~~~~~~~~~~~~~~~. Are you sure you want to continue connecting (yes/no)? （ここで「yes」を入力し、実行する） The authenticity of host '**.***.**.*** (**.***.**.***)' can't be established. ECDSA key fingerprint is SHA256:******************************************. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '**.***.**.***' (ECDSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ [ec2-user@ip-***-**-**-*** ~]$ ここまで行ければインスタンスログイン完了。つまり、.cerだろうが.pemだろうが関係なくできた。

勉強前イメージ 終了するって言ってたけど・・・・ そもそもEC2のoldバージョン？ インスタンスタイプ的な話？ 調査 EC2-Classic とは 1つのIPのみでアサインされた単一のネットワーク内で稼働するインスタンス環境で、 EC2が出来た2006年から存在する環境です。 2013年12月4日以降はリクエストしない限り利用できない様になっており、廃止予定になっております。 廃止について 2021年10月30日にアクティブなEC2-Classic環境がないAWSアカウントに関しては EC2-Classicを無効化、リザーブドインスタンスの販売の停止。 2022年8月15日には、全移行措置を完了予定になっております。 勉強後イメージ 今のEC2はVPCの中にあるって感じだけど EC2-Classicは一つIPを持って一つの空間って感じする。。。 もう廃止らしいし、みたことないけど。。 参考 AWS、「EC2-Classic」を終了へ AWSが「EC2-Classic」を廃止へ