AWSの.NetCoreのサンプルのコンソールアプリを動かしてみました。
結果、bash: line 1: hello/obj/project.assets.json: No such file or directory
と怒られました。
確かにobjフォルダの下にDebugフォルダも、exeもdllもできていません。
で、色々とネットで調べてみるとどうやらAWSで動かすために必要なファイルがサンプルのインストール手順だと不足していたようです。
コマンドプロンプトから
>dotnet restore
を実行したら、正常に実行されました。
AWS
AWS関連
Cloud9とDjangoとWebサーバー起動と
Cloud9でPythonベースのWebシステムを構築する場合に使用するWebフレームワークですが、DjangoとFlaskが主なフレームワークのようです。
どちらを採用しようかググった結果、日本語環境が比較的整備されているDjangoにしようと思います。(;’∀’)
cloud9のコンソール画面でPythonのバージョンを確認します。

3.6.10ですね。2.x.系の方は3.x.系にアップグレードしてください。
Djangoの特徴としてプロジェクトごとに仮想環境を作成していくことが一般的な開発手順のようです。
次のコマンドで仮想環境を構築します。

コマンドの先頭に(venv)が表示されている場合、仮想環境に居るようです。
ではインストールしてみましょう。

pipが古いよって警告が出ていますが、Djangoは無事インストールされたようです。

Cloud9には既にMySqlがインストール済のようです。

起動/停止してみます。


はじめての起動時はパスワードなしで起動してください。

文字コードを確認します。

character_set_database
とcharacter_set_server
がlatin1
ですね。
このままだと日本語を書き込もうとしたときにエラーで落ちるので、/etc/my.cnf
に設定を追加します。
character-set-server=utf8mb4

mysqlを再起動します

再度キャラクタセットを確認します。

Django用のユーザーとDBを作成します。

権限を付与します。

以上でmysql側の設定は終了です。
ちょっと横道にそれちゃいますが、
仮想環境は複数の開発を行う場合、それぞれのプロジェクトによって必要となってくるライブラリなどが異なってくるため、環境の競合がが発生しないためにプロジェクトごとに仮想環境を作って管理していこうというものですが、Pythonの標準ツールとしてvenvがあります。
venv以外にもvirtualenvなどのサードパーティ製のツールを使用しても仮想環境を作成することは可能です。ちなみに、venvで作成した仮想環境から抜けるには、
>deactivate
を実行します。
では、Djangoのサンプルを起動するところまで頑張ってみたいと思います。
任意のフォルダを作成し、gitからDjangoのサンプルアプリを取得します。

仮想環境を起動します。

サンプルの起動準備をします。

マイグレーションでサンプルアプリのデータベースを作成します。

サーバーを起動します。

ただし、アプリサーバは起動していますが、まだAWSのファイアーウォールとdjangoのホスト制限のせいで外部からアクセスできません。
これからその設定をしていきます。
Cloud9のメニューバーから’Go To Your Dashboard’を選択します。

サービスをクリックし表示画面から、’EC2’を選択します。

EC2のダッシュボードが表示されるので、「実行中のインスタンス」をクリックします。

EC2インスタンスの一覧が表示され、1つしかない場合、選択状態になっています。
画面下部にはその詳細が表示されていますが、そのうち「パブリック DNS (IPv4)」の欄に表示されているのが、URLの中央部(ホスト)になります。
この前に”http://”を、後に”:8000″をつけてアクセスしてください。

次に、セキュリティグループの欄をクリックします。



インバウンドルールを設定するダイアログが表示されるので、「ルールの追加」をクリックし、TCPカスタムを選択し、ポートの欄に8000を入力します。最後に、追加をクリックします。これで、ファイアーウォールの設定画変更され、8000番ポートのアクセスが許可されます。

上記の、「パブリック DNS (IPv4)」の欄に表示されている内容に、前に”http://”を、後に”:8000″をつけてアクセスしてください。
この時点で、Djangoのアプリにアクセスすることができます。
ただし、ホスト制限に引っかかり、下記のようなエラーが表示されます。

DjangoのALLOWED_HOSTSを設定する
まず、開きっぱなしのCloud9のIDEで、アプリケーションのディレクトリにあるconfig/settings.pyを開きます。
その中ほどまでスクロールし、ALLOWED_HOSTSというリストに、先程の「パブリック DNS (IPv4)」の欄に表示されている内容を追加します。
もう一度、:8000で終わるURLにアクセスして下さい。

サンプルアプリが起動しました。

次回は、このサンプルのDBをSQLiteからMySqlに変更したいと思います。
AWS SDK for Python
AWS SDK for Python(別称:BOTO3)を構築してみます。
前提条件は、IAMアカウントの取得、AWS CLIがインストール済であることです。
ここを参照して、構築します。
Windowsなので、コマンドプロンプトから、
>py -m pip install boto3

まずは、サンプルアプリケーションを実行してみます。
このチュートリアルに従って実行します。
画面下方にある”モジュール1を開始する”ボタンをクリックします。


AWSコンソール画面から、cloud9を選択し、”Create environment”ボタンをクリック

続いて、環境名とその説明を記入して、”Next step”ボタンをクリック

構築環境は今回デフォルトのままで、”Next step”をクリック


“Create environment”ボタンをクリック


IDEが作成されると、次のようなウェルカム画面が表示されます。

ここでチュートリアルだといきなりgithubからソースをもってきて実行しろとなってますが、ちょっといきなりなので、ここではお決まりの文言をコンソールに表示するだけにしておきます。

赤まるの中のステータスを入力して保存(File → Save)します。
右上のRunをクリックして実行します。

コンソール画面が表示され、処理結果が出力されます。

以上です。
ネットで調べていると、Cloud9のPythonのデフォルトが2系になってるとか出ていますが、私がやった限りでは、デフォルトは3系になっていました。
もしうまくいかなければ、↓が必要かもしれません。
sudo yum -y update && sudo yum -y install python36
蛇足ですが、保存した環境を再度開くのは、ハンバーガーメニューからです。


AWSのMFA認証設定とIAMユーザー作成
AWSでの2段階認証を行うための設定についての備忘録です。
まず、アカウントを作成した後、MFA(Multi-Factor Authentication)の設定を行います。
MFAはユーザー名とパスワードによる認証に加えて、2要素認証を行う仕組みです。
この設定は、悪意を持った第三者からの不正ログインを防ぐことなどが目的です。
MFAには仮想MFAデバイスとハードウェアMFAデバイスの2種類があり、仮想MFAデバイスはスマートフォンなど(PC用ソフトもあるらしい)にインストールし、使用します。
ハードウェアMFAデバイスはGemalto社製の物理デバイスを購入して利用します。
私は仮想MFAデバイスとして、iPhoneにGoogle Authenticatorをインストールしました。
AWSマネジメントコンソールへログイン
AWSマネジメントコンソールへログインしたら、メニューバーのアカウント名をクリックしてマイセキュリティ資格情報を選択します。




MFAデバイスの管理ダイアログが表示されますので、仮想MFAデバイスを選択し、”続行”ボタンをクリックします。

仮想MFAデバイスを起動して、認証コード1、2を設定します。”MFAの割り当て”を選択し、正常設定されたことを確認します。

これで設定は完了しましたので、一度サインアウトして、再度サインインして問題がないかを確認します。
サインイン時には仮想MFAデバイス(私の場合iPhoneのAuthenticator)を起動してパスワードログインした後、要求されるMFAコードに、Autenticatorで表示されるコードを入力します。

IAMユーザ-の作成
続いてIAMユーザ-(ユーザーアカウント)の作成を行います。
実際のAWSの操作ではAWSアカウントは使用しません。
AWSアカウントはUNIXなどのrootアカウント的な位置づけでしょうか、通常の操作はこれから設定する、IAMアカウントを使用します。
AWSマネジメントコンソールでサインインします。






作成したグループを再度選択し、ユーザーを作成します。

続いて、タグを作成します。
タグは、例えば一時的にあるプロジェクトを立ち上げた場合などにその担当者だけで管理したい場合などを想定して作成するものだと思っています。
これはまだ確証があるものではないので、確認が取れ次第ご報告しますということで、許してください。




ポリシーにはAWS管理ポリシーとカスタマー管理ポリシーがあります。
AWS管理ポリシーは非常に便利な機能ですが、AWSが自動で更新するため、アカウントの厳密な管理という意味では難があります。
そこで、カスタマー管理ポリシーを利用します。


ここでは、AWS管理ポリシーの”AdoministratorAccess”をコピーします。




続いて、作成したポリシーをIAMグループに付与したいと思います。












注意が必要なのは、この一連の作業では、IAMアカウントにはMFAは設定されていません。
MFAを設定する場合はAWSアカウントと同様の設定を行う必要があります。
これでやっとAWSの準備作業が終わった???