AWSを知らないエンジニアが基礎から学ぶために使用したサイトや記事など

自分で勉強する前の知識とか使ったことのあるサービスとか

AWSはプロジェクトで使ってるけどインフラエンジニアがすべて見てくれているのでどんなサービスがあるかよくわからない

・EC2っていうのがインスタンス(いわゆるサーバー)管理、プロジェクトの画像などのリソースを管理していたのがS3(ストレージ)、RDSがデータベースのマスターとスレーブを管理しているというくらいの認識

・オートスケーリングというインスタンス数の管理をしてくれる仕組みがあるのは知っている

・RedisやSQSを使用するためのコードは書いたことがあるけど設定の仕方はわからない

・ClowdWatchとかCloudFrontとか聞いたことがあるけど、それで何をしているのかは知らない

 

 

後輩くんが「パイセンー、AWSを勉強するときにどういうサイト参考にしました?」と言うので自分のためにもまとめてみた。

 

 

 

 

参考にした記事やスライドなど

・知識について

www.sejuku.net

インフラに関しては苦手意識が強かったですが、そんな初心者にも最低限知っておくべき知識が書いてあって端的なのでわかりやすいし読みやすい。

なんとなくAWSってどんなものかがわかる。

 

www.slideshare.net

AWSの中の人が書いたスライド。たくさん情報があるけど資料が読みやすいおかげで、AWSの知識を概要だけ仕入れた人間でも理解を深めることができる。

サービスの仕組みについての図解が細かく、使用料金についても記述がある。

Hiroshi Takayama presentations | SlideShare

中の人は優しいので他にもAWSに関するスライドをアップしてくださっている。読んでおくとよいかもしれない。

 

qiita.com

全サービスをなんとなく理解するにはよいかも。

 

 

 

 

・実際にAWSを動かしてみる

ユーザー登録はそんなに難しくないから自分でやってね!カード情報が必要だよ!

qiita.com

この方には足を向けて寝られない。↑の概要も含めると全6回に渡って、AWSとはなんぞや?というところから冗長化まで操作・解説してくださっている。

ユーザー作ったけど何からやったらいいんだよー、というときはこれを順にやっていくことをおすすめする。徐々に身についてきて成長を実感できる。

すごい。

ちなみに、全6回の内容は以下の通り。

①概要

VPC

③EC2

④ELB

⑤RDS

⑥AMI

このアルファベットと数字の3文字ばっかり並んでてなにがなんやら、でも徐々にわかってくる。

 

qiita.com

これもやっておこう。

 

 

 

 

 

・身についてきたら、運用担当者になったら読むとよいかも

Amazon Web Services Japan presentations channel

SlideShareのAWSJapanの公式アカウントに膨大な量のスライドがあるので、目的に合わせて読んでみると良いかも。

 

 

 

 

・困ったら

公式のドキュメントを読む。

ユーザーの記事は古くなるが公式のドキュメントは常に最新。コンソールのUIやなんらかの機能を作成する際の手順だって数年前と現在では変わっている。ようわからんなーと思ったら記事やブログを参考にしつつ公式の該当ページを読もう。

例:

docs.aws.amazon.com

 

 

 

 

・そのほか

qiita.com

教訓のほかにこういうのもやってみたよー、という欄があるので、そこを参考に次に度のサービスを動かしてみるかの参考にさせてもらった。

 

請求アラートの設定は上記や下記の記事を参考にした。お金は大事。

docs.aws.amazon.com

 

papix.hatenablog.com

qiita.com

やってみて楽しかったこと。

S3に画像をアップロードしたらLambdaを通じてSlackに通知を送る - 備忘録

 

 

 

 

以上。

まだまだ知識は浅いので今後もお勉強は続く。

Javaフレームワークリンクまとめ

furien.jp

blog.codecamp.jp

 

 

Spring Framework(すぷりんぐふれーむわーく)ー2002~

・アプリケーションフレームワーク

・テストしやすい→Spring MVC Testというテストプログラム

・独立性→拡張しやすい、外部のフレームワークも取り入れやすい

・保守性が高い

・再利用性が高い

・新しい機能を積極的に取り入れる

www.sejuku.net

tech.pjin.jp

www.ossnews.jp

Spring Framework | TECHSCORE(テックスコア)

・動かしてみる

dev.classmethod.jp

 

 

Struts(すとらっつ)ー2000~

・アプリケーションフレームワーク

・シンプル

・国際化対応が容易

・自由度が高い

・DBにアクセスする仕組みがない

脆弱性がある

www.scutum.jp

StrutsによるWebアプリケーション開発

・動かしてみる

Strutsを使うWebアプリケーション構築術(1):フレームワーク・プログラミングの準備 (1/2) - @IT

 

 

Wicket(うぃけっと)ー2005~

・アプリケーションフレームワーク

Apacheが開発

JavaとHTMLだけでの開発を目指す

Ajaxが使用しやすい

gihyo.jp

・動かしてみる

codezine.jp

Wicketでオブジェクト指向を楽しみながらWebアプリケーションを作る - 技術ブログ | 株式会社クラウディア

 

 

Play Framework(ぷれいふれーむわーく)ー2007~

・アプリケーションフレームワーク

・非同期で行われていることが前提

・軽量

・生産性が高い

JavaScalaで動く→謳っているもののだいぶScala推し

・独自のテンプレートエンジン→Groovy

kakakazuma.hatenablog.com

Play Frameworkについてざっくり説明する | anopara

www.ossnews.jp

 

 

Dropwizard(どろっぷうぃざーど)ー2014~

・デプロイ時にjarにパッケージングするので楽

・学習コストが低め

・ドキュメントが少ない

www.bunkei-programmer.net

・動かしてみる

dev.classmethod.jp

etc9.hatenablog.com

 

 

Spark Framework(すぱーくふれーむわーく)ー2013~

(2017/05/18 

コメントよりSparkとApache Sparkが混在しているとご指摘を受けましたのでApache Sparkの関連リンクを削除しました)

・マイクロフレームワーク

RubyのアプリケーションフレームワークであるSinatra(しなとら)と似ている

・動かしてみる

kikutaro777.hatenablog.com

murayama.hatenablog.com

dev.classmethod.jp

 

 

Junit(じぇーゆにっと)

・テストフレームワークeclipseに標準で入っていることもある

・バグ修正が早くなることでプロジェクト全体の作業効率をあげるのが目的

- JUnit 実践講座 - プログラミングスタイルガイド

www.atmarkit.co.jp

・動かしてみる

konbu13.hatenablog.com

dev.classmethod.jp

 

 

PHPフレームワークリンクまとめ

github.com

furien.jp

eng-entrance.com

www.webprofessional.jp

blog.codecamp.jp

techacademy.jp

PHPフレームワークの歴史 - PHPプロ!

 

CakePHP(けーくぴーえいちぴー)ー2005~

PHPフレームワークの代表

・機能性が高い

・利用者が多い

・無料

・ユーザーが多い→学習しやすい

・日本で人気

Ruby on Railsの影響を受ける

・動かしてみる

www.sejuku.net

hatena.aaafrog.com

 

 

Zend Framework(ぜんどふれーむわーく)ー2007~

PHPを開発したZend Technologiesが開発

・シンプル

・柔軟→拡張しやすい

・高速

・技術パートナーにMicrosoftIBMGoogle→信頼感

doremi.s206.xrea.com

・動かしてみる

gihyo.jp

 

 

Symfony(しんふぉにー)ー2007~

・互換性がある

Mojavi(もはび、もじゃび)から派生

Ruby on Railsの影響を受ける

 

・動かしてみる

tdak.hateblo.jp

codezine.jp

symdoc.kwalk.jp

 

 

Laravel(ららべる)ー2011~

・低速

Symfonyを利用している

・開発者は.NETの中の人(個人プロジェクト)

・柔軟→拡張しやすい

・テストしやすい

・速度重視版Laravelもある→Lumen(るーめん)

・海外で人気

www.infiniteloop.co.jp

Laravelを使うべきか

・動かしてみる

udemy.benesse.co.jp

 

 

CodeIgniter(こーどいぐないたー)ー2006~

・高速

・規約が緩い

・シンプル

・導入しやすい

・学習コストが低い

Codeigniterをはじめる時にまず読んで欲しい記事10選 – rdlabo.inc|リレーションデザイン研究所

www.ci-guide.info

PHP初心者の私がCodeIgniterを勉強して感じた4つのメリット、2つのデメリット | 株式会社アルベ | Arubeh Inc.

 

 

Phalcon(ふぁるこん)ー2013~

・高速→CodeIgniterの1.5倍から2倍

・省メモリ

・柔軟

・規約が緩い

・専用のテンプレートエンジンを内蔵→Volt(ぼると)

・途中から導入する場合に再起動が必要

C言語で開発

blog.asial.co.jp

spice-factory.co.jp

blog.manaten.net

thinkit.co.jp

 

 

 

FuelPHP(ひゅーえるぴーえいちぴー)ー2011~

・高速

・規約が緩い

CodeIgniter関係者が開発

・学習コストが低い

http://www.buildinsider.net/web/bookphplib100/096

d.hatena.ne.jp

 

 

Flight(ふらいと)ー2013~

・独立性が高い

・計量

Twitterが開発

MVCではなくVC

・テストしやすい

nal-hr.co.jp

・動かしてみる

www.laddy.info

dev.classmethod.jp

 

 

Silex(さいれっくす)ー2011~

Symfony開発者が開発

・シンプル

・動かしてみる

te2u.hatenablog.jp

 

 

BEAR(べあ)ー2011~

・日本製

tdak.hateblo.jp

・動かしてみる

polidog.jp

 

 

Kohana(こはな)ー2007~

CodeIgniterから派生

・軽量

・高速

・動かしてみる

blog.mach3.jp

 

 

Ethna(えすな)ー2011~

・フォームが特徴

・日本人が開発

dqn.sakusakutto.jp

ameblo.jp

 

 

Ice Framework(あいすふれーむわーく)ー2014~

・高速

blog.ohgaki.net

programmer-jobs.blogspot.jp

 

SQSを動かしてみる

以前のプロジェクトでSQSで非同期でDB更新を行う処理を入れていたためになじみがあったので動かしてみる。

 

AWSコンソールの「Simple Queue Service」からキューの作成

設定はこんな感じ。

 

 

f:id:satomiO:20170512161639p:plain

 

②メッセージを設定。

 

f:id:satomiO:20170512155210p:plain


「メッセージの送信」を選択してメッセージを作る。

(適当に)メッセージを作るよ。送信できていることがわかればいいのでゆるくいくよ!

 

f:id:satomiO:20170512155254p:plain

 

送信!

 

f:id:satomiO:20170512161747p:plain

 

 

 ③キューを送る。

 

f:id:satomiO:20170512155319p:plain


「キューの表示/削除」を選択してメッセージを送ってみる。

ポーリングスタート!

75秒遅延にしたので、すぐポーリングしてもメッセージは来ない。

100%になっても空っぽのままになる。

 

もう一回ポーリングスタート!

 

f:id:satomiO:20170512155430p:plain

 

きたー!

 

f:id:satomiO:20170512155442p:plain

 時間もちゃんと75秒以上差がありますね。

動作確認は終了!

aws-shellから設定する方法もあるみたいですが、コマンド叩くの嫌いマンなのでひとまずこのまま……(インストールだけした)

 

 

停止させていたEC2インスタンスを起動させる

この頃、AWSのいろいろサービスを試してみようと勉強を進めているわけですが、無料範囲内で行うことを第一にしているので、請求が来るリスクを減らしておこうとインスタンスを停止させていました。

(操作学習もかねてボリューム、スナップショットはとっておきました)

今度はこのサービスを試してみようかな、と思いターミナルで入ろうとしてみたら入れない。 そうだインスタンス止めてたやー、とうっかりをかましました。

ではAWSコンソールのEC2から「インスタンス」を選択し、インスタンスの起動じゃ。

f:id:satomiO:20170512142913p:plain

確認用のモーダルが出るので「開始する」を押下。 すると

インスタンス開始のエラー Invalid value ‘インスタンス名’ for instanceId. Instance does not have a volume attached at root (/dev/xvda)

とエラーメッセージが。

そうだ、ボリュームも課金を減らそうとデタッチしたのでした。

「ボリューム」を選択して、取得していたボリュームをインスタンスにアタッチ。

f:id:satomiO:20170512144206p:plain

モーダルが出てくるので対象のインスタンスを選択。

f:id:satomiO:20170512144647p:plain

インスタンスを選択するとデバイスが自動的に入力されるが、このデバイスエラーメッセージに表示されているものと異なる場合はエラーメッセージ側に書き換えておく

書き換えたらアタッチ。

無事成功するとステータスが「in-use」になります。

あとは、「インスタンス」に移動して先ほどボリュームをアタッチさせたインスタンスを選択して起動!

S3に画像をアップロードしたらLambdaを通じてSlackに通知を送る

こちらのページで示されている手順をトレース。

  

qiita.com

 

 

AWSは触り始めて日が浅く、基礎的な環境構築や動かし方を先人たちの記事を見ながら確認している段階。

実運用しているわけではないので、Slackに通知を送れるだけで楽しい。


自分が作ったものが動いたー!という実感がもてる。


以前参加していたプロジェクトで利用していたサービスをひとまず触ってみて、どのように設定を行うのか確認している段階。

S3は画像や音楽ファイルの管理などに使用していたため聞きなじみのあるサービス。何をするためのサービスかを調べなくても知っていたのでとっつきやすかった。


S3→Lambda→Slackとつなぎ、ログをCloudWatchで確認する。

 

 

①S3にバケットを作ってファイルをアップロード

f:id:satomiO:20170511180837p:plain


好きなものをアップロードしよう

 

②Lambdaの設定

f:id:satomiO:20170511180854p:plain

 

「Lambda関数の作成」から

 

f:id:satomiO:20170511180903p:plain


「s3」などでフィルタをかけて「s3-get-object」を選択。
もろもろの設定はページTOPで紹介したリンク先を参照してください。


③SlackのWebhookURLを取得(Slackのアカウントが必要)

 

https://my.slack.com/services/new/incoming-webhook/


ここからwebhookのURLを取得する。通知するチャンネルを用意しておこう。

「テストだし、プライベートチャンネルを立てて挙動が確認できたらチャンネル削除しよう」と思ってプライベートチャンネルを立てたが、プライベートチャンネルは削除できないから気を付けるんだ!


アーカイブ化はできるが、チャンネル削除はパブリックチャンネルのみ対応)


LambdaでこのwebhookURLを設定する。

 

ちなみに、最初は自分にダイレクトメッセージで送ろうと「@my-account」と自分のアカウントを設定したが、この場合は@slackbotに送られて自分のアカウントにダイレクトメッセージでは送られなかった。
何か設定方法があったなら知りたい。

 

以上の設定ができたら動作確認してみる。楽しい。

 

④CloudWatchでログを確認

Lambdaで設定したJSでログを吐き出すようにしてあるのでCloudWatchへ。

 

メニューから「CloudWatch」を選択して「ログ」へ遷移。

「ロググループ」から該当するグループを選択してログを確認。アップロードするたびにここにログが吐き出される。

 

 

AWSでEC2作成時にパブリックIPが付与されていないときの解決法

今後仕事でAWSを触ることになり、こちらの記事を参考にVPCの作成から順を追ってEC2インスタンスを作ってみることに。

qiita.com

VPCサブネットマスク、EC2と順を追って作成してみたが、立ち上げたインスタンスにパブリックIPが付与されていない。 あれえ。 どうやらローンチするときにパブリックIPを有効にするチェックを入れていなかったらしい。 再ローンチすれば割り当てられるみたいだ。

sheeplogh.hatenablog.com

下記のブログを参考にAMIを作ってみることにする。

https://blog.serverworks.co.jp/tech/2015/05/18/ami_gettodaze/

メニューからEC2のダッシュボードに遷移後、「インスタンス」を選択して作成したEC2にチェックを入れ、「アクション」→「イメージ」→「イメージの作成」を選択。

f:id:satomiO:20170509104113p:plain

モーダルが開くので、「イメージ名」「イメージの説明」にわかりやすい名前を入力。 そして「再起動しない」にチェックをいれる。 これで「作成」ボタンを押下するとAMIの作成が開始される。

ダッシュボードから「AMI」を選択して作成されたAMIを確認。 できてますね? 今度はこのAMIからEC2を再ローンチ。 対象のAMIを選択して「アクション」→「作成」をクリック。

f:id:satomiO:20170509104549p:plain

あとはEC2の作成の手順と同じ。 パブリックIPを有効にすることを忘れずに。

作成!

改めてEC2から作成されたインスタンスを確認してみると、パブリックDNSとパブリックIPが付与されていました。 よかったよかった。

このAMIは不要になったので削除しておく。 対象のAMIを選択して「アクション」→「登録解除」。

f:id:satomiO:20170509105039p:plain

また、不要になったスナップショットも廃棄。 ダッシュボードから「スナップショット」へ遷移。

f:id:satomiO:20170509105748p:plain

削除!!!!

引き続きAWSを触ってみる。