miyamon_good’s blog

エンジニア×パチンコ・パチスロ

AWS勉強②VPC,サブネット,インターネットへルーティング

では、早速手を動かしながらやっていこうと思います!

 

まずは、VPCを作成。

IAMユーザーでログインし、VPCへ。

リージョンを確認し、東京であることを確認。

IPv4 CIDR ブロックとはVPC全体のIPアドレスの範囲をCIDR表記で指定すること。

今回は10.0.0.0/16に設定。

テナンシーとは、物理ハードウェアを専有するオプション。

設定するとEC2料金が割高になるし、専有する必要がないのでデフォルト。

これでVPC作成OK。

 

お次にサブネットを作成。

その前にサブネットを分割する理由について復習を。

アベイラビリティゾーンを分けて物理的に離すことで災害時等の対策。

・セキュリティ上の理由(WEBサーバーはインターネットアクセス可能、DBサーバーはインターネットからアクセスを不可にする時等)

今回はパブリックサブネット(10.0.10.0/24)とプライベートサブネット(10.0.20.0/24)

この2種類を作成しました。

パブリックサブネットはWEBサーバー、プライベートサブネットはDBサーバーを割り当てる想定で実装します。

 

お次はパブリックサブネットをインターネットへ接続できるようにルーティング。

その前に、まずはルーターについて。

インターネットでは、ルーターIPアドレスの行き先を管理しています。

そのおかげでネットワークとネットワークがIPアドレスを通じて接続することが出来る仕組みになっており、これをルーティングといいます。

ここまでの設定では、VPCで設定した10.0.0.0/16の範囲外の宛先の通信は全て破棄されている状態。そのためインターネットへ接続できていません。ルートテーブルに変更を加えインターネットへ接続できる状態にしたい。

そこで必要となってくるのが「インターネットゲートウェイ」です。

これは「VPCとインターネットを繋げる仮想のルーター」であり、パブリックサブネット用のルートテーブルを作成し、10.0.0.0/16のターゲットをlocalに、0.0.0.0/0のターゲットをインターネットゲートウェイとすることで10.0.0.0/16以外の接続をインターネットゲートウェイへ接続するように設定することが可能。

 

ここまでのまとめと、するべきことは以下の2点です。

1,インターネットゲートウェイを作成しVPCにアタッチする

2,ルートテーブルを作成しパブリックサブネットに紐付ける

 

それでは1から実装していきます!

まずインターネットゲートウェイを新規作成。

完了直後はVPCに紐付いていない為、状態は"detached"となります。

なので作成したVPCにアタッチし、状態が"attached"に変わればOK。

 

次は2のルートテーブルの作成。

ここまでの実装でルートテーブルには送信先10.0.0.0/16でターゲットがlocalになっていることを確認。これは送信先10.0.0.0/16のIPアドレスが自分のIPアドレスであるということ。逆に言えば、それ以外の通信は破棄する状態。そこでルートテーブルを新規作成しデフォルトルートをインターネットゲートウェイへ向けるように設定します!

 

ではルートテーブルを新規作成。作成したVPCを選択し新規作成。

これをパブリックサブネットに関連付けする。サブネットの関連付けから、パブリックサブネットを選択し保存することでこのルートテーブルをパブリックサブネットに割り当てることが可能。その後デフォルトのルートをインターネットゲートウェイへする。

ルートの追加をクリックし、0.0.0.0/0を送信先に設定。ターゲットをインターネットゲートウェイへ設定し保存。

正しく設定しているかは、ルートの欄に送信先に先程設定した項目が記入されていればOK。これによってパブリックサブネットからインターネットへ接続が可能なる。

 

では、最後にVPC設計とサブネット設計のポイントをまとめます。

VPC設計

①プライベートIPアドレス範囲から指定

VPCで作るネットワークはプライベートなネットワーク空間なので、

プライベートIPアドレスの使用が推奨されている。

②作成後は変更できないので、大きめに設定(推奨は/16)

 

・サブネット設計

IPアドレス数を見積もって設定、標準は/24。

②サブネットの分割について

ルーティングポリシーとアベイラビリティゾーンを基準に考える。

サブネットに割り当てられるルートテーブルは一つのみ。

今回2つのサブネットを作成した理由はインターネットアクセスの有無を分けるため。

そのため最低2つのサブネットが必要になる為2つ作成した。

また、耐障害性を考え複数のアベイラビリティゾーンに設置したほうが良い。

 

以上。

次はサーバー(EC2)を設置していこうと思います!

 

こうやって学んだことをアウトプットしながら実際に構築していくと、ある程度考えながら進むことが出来るのでこのままこのやり方で実装を目指します!

 

 

 

AWSの勉強を始めます!〜①インフラって何?&AWSのネットワークについて〜

お久しぶりです。

本日からAWSの勉強を始めていきますので、備忘録としてその学習の軌跡を残していこうと思います。

 

ゴールは「ポートフォリオAWSの基本的機能を用いてインフラを構築すること

 

今回は「そもそもインフラって何?」ということから始めます!

 

①インフラ

インフラ=基盤。

今回の目標に対するインフラは、サーバーやネットワークを指す。

例:ネットワークインフラストラクチャ=ネットワークを構成する仕組みや機器(ルーターイーサネット等)

AWSクラウドでサーバーやネットワークを構築するサービスを提供している。

 

②サーバー

「クライアントに対してサービスを提供しているコンピュータ」

サーバーを置く形態は以下の2つ。

・オンプレミス→自前でサーバーを用意する方法。

メリットは自由度が高い。デメリットは難しい上に高コスト。

また設定等が難しいため大変。

クラウド→ネットワーク経由で使用・管理する方法。

メリットは低コストでサーバー増減が自由。

デメリットは費用の予測がつきにくい。

 

③ネットワーク

「複数のコンピュータを繋ぎデータを送受信する為のもの」

 

お次に「AWSのネットワークの概念について」です!

 

①リージョン

AWSの各サービスが提供されている地域」

応答時間の関係上、日本で展開するので東京でOK。

 

アベイラビリティゾーン

「独立したデータセンター」

リージョン毎にアベイラビリティゾーンが存在。それぞれが物理的に離れている場所に存在しており、災害時にどこかのアベイラビリティゾーンが利用不可能になってもそれ以外のアベイラビリティゾーンがあれば稼働することが可能。

東京のアベイラビリティゾーンは現在3つ。(ap-northeast-1a,1c,1d)

 

VPC(Virtual Private Cloud)

AWS上に仮想ネットワークを作成できるサービス」

AWSで作業する時はまずこれを作る!AWSにおいて重要なサービスの1つ。

 

④ サブネット

VPCを細かく区切ったネットワーク」

アベイラビリティゾーンの中に作成する。ネットワークを区切りたい時(例えば1つのアプリケーションでのWEBサーバーとDBサーバーのように見れるものと見られたくないものを区別する時)にはVPCの中にサブネットを2つ用意することで可能。

サブネットは複数のアベイラビリティゾーンにそれぞれ設置可能なので、災害時に1つのデータセンターがだめになっても他のサブネットに設置したサーバーは生きていればサービスを継続することが可能。

 

IPアドレス

「ネットワーク(インターネット)の住所」

この住所へデータは送り届けられる。中継地点にはMACアドレスが使用され、これらを関連付けることによってデータの送受信は成立。

AWSではVPCIPアドレス範囲を決定する必要がある。

IPアドレスはネットワーク部とホスト部に区分けすることで範囲を表記する。

CIDR表記とサブネットマスク表記の2パターン存在。

 

では、次はAWSの初期設定やIAMユーザーを作成してから早速実際にVPC、サブネットを作成していこうと思います!!

 

アプリケーション作成備忘録第二弾

土日は濃い勉強が多かったので、忘れないう内に書き留めていきます。

 

①flushメッセージでエラー文を表示させる

結論:コントローラーでifを使い、失敗した時に

flash[:notice] = @○○.errors.full_messages と表記。

ビューファイルで出したい部分に

<% if flash[:notice] %>

<p><%= flash[:notice] %></p>

<% end %>

と記述すれば完成。

 

②売却済商品に処理をしたい時の指定方法

結論:if @item.buy.present?

前提としてコントローラーで@itemを定義している時に使用可能。

この表現に辿り着くのに地味に時間がかかってしまった、、

初めは、if @item.id == buy.item_idみたいな書き方をしていたり(笑)

 

③フォームのデータ保存に失敗した時にフォームの中身を空にしたい

結論:form_withのmodelを選択しない。

中身にあるなしに応じて処理が変わるが、modelを選択すると中身が残るので

modelを渡さないというのが1つの選択肢。その際パラメーターが少し変わるので注意。

このやり方以外にも、①のflushメッセージ+redirect_toを使うやり方もできた。

 

④Payjpを用いたクレジットカード決済時の流れ

送信ボタンをイベント発火に設定し、preventDefaultでrailの処理を一旦止める。

フォーム記載内容をJavaScript+FormDataオブジェクトを使い、DOMから取得。

取得した値は変数に代入しておく。

token作成の為、PayjpオブジェクトのcreateTokenメソッドを使って生成。

通信に成功した時のみtokenを生成し、受け取ったtokenのidを変数に代入。

テンプレートリテラルvalueを使いHTMLタグにtokenを組み込み、

insertAdjacentHTMLメソッドを使い、作成したHTMLタグをsubmit要素にねじ込む。

これにより、token情報がsubmitされた時に一緒にコントローラーへ運ばれる。

クレジットカードの情報はDBに保存することはまずいので、

これらの処理を終えたらremoveAttributeで入力されたname属性を指定し、削除。

その後、submitで送信する。

 

⑤form_withによるname属性とid属性の自動取得について

結論:name属性とid属性を指定していなくても自動で取得可能(検証ツールで可視化)

 

modelを指定した場合

name="model[フォーム記述カラム]"

id="model_フォーム記述カラム"

 

urlを指定した場合

name="フォーム記述カラム"

id="フォーム記述カラム"

 

model,id両方を指定した場合

modelを指定した時と同じ表記。

JavaScriptを使用しフォームの値を取り出す時に使いました。

 

以上。

JavaScript楽しいですね!

 

 

 

 

 

 

 

 

 

 

 

アプリケーション作成の備忘録

お久しぶりです。

アプリケーション作成が楽しくて、ブログまで手が回りませんでしたが

ここで一回エラー等の備忘録を作成しようと思います。

 

①Formオブジェクトについて(※私の認識です)

複数のテーブルに保存をする時に使う。

通常のやり方ではエラーハンドリングが処理しきれないので、

処理できるモデルのクラスを作ってインスタンスを渡そう!

ポイントは4つ。

1,attr_accessorで保存したいカラムを記入し属性として引数で渡す。

引数で渡したら、ストロングパラメーターで保存出来るように記入。

2,activeModel::Modelをincludeし、ActiveRecordを継承した他クラス同様に

インスタンスやクラスを使えるようにする。(≒Formオブジェクト生成)

3,使用するフォームでのバリデーションを記入。

4,それぞれのテーブルに保存する記述を書く。

 

JavaScriptが全てのページで発火しているエラー。

結論:発火するページを指定していなかった。

if(document.URL.match(/new/) || document.URL.match(/edit/)

JavaScriptの文頭にifをつけることにより解決。

 

③クレジットカード決済の時のバリデーションについて。

結論:モデルでのバリデーションはtokenのみ。

JavaScriptによりDOMツリーの段階で、

フォーム読込→トークン生成→フォーム内容を空にする

流れが出来ているのでコントローラーまで運ばれるのはtokenのみになる。

 

④default:""とnull: falseについて

結論:バリデーションをかけるタイミングの違い。

null: falseはDB内のNULLを無くす。

presence: trueやdefault:""はモデルの段階でブロック。

 

⑤index: trueについて

結論:検索処理をやや早くすることが可能。

searchアクションを使う時等に出番があるかな?ぐらいの認識。

 

⑥入力内容は合っているがログインできない

結論:ログインフォームのモデルとurlが正常に設定できていない。

 

⑦デプロイ後の本番環境でstatus code500のエラー

結論:heroku run rails db:migrateを忘れていた。

 

⑧テストコード正常系と異常系について

正常系は、表面上で分かる範囲で、動作が動くことをテストする

異常系は、表面上で判断できないことやイレギュラーパターンについての実装条件についてテストする。なお、第三者が見て機能や特徴、性質が分かるようにするのが好ましい。

 

正規表現が反映されずエラーが出る。(セキュリティ上よくないよ?的な文)

結論:アンカーをつけ忘れていた。

アンカーがないことにより正規表現のチェックが出来ず、全ての表現を許容する?認識をターミナル上で判断した為、セキュリティ上良くないよ?というエラーが発生した?

全てカタカナ、全てひらがな等にする場合は頭と語尾にアンカーを設定する必要あり。

 

rails db:migrateが出来ない

結論:encodingのutf8mp4をutf8に変更するのを忘れていた。

rails db:mirate:resetした時にエラー文で767バイト以上は無理という表記があったおかげでたどり着けた。

 

まだまだありますが、以上。

毎日発見や学びがあって楽しいです。

 

 

 

今月一番のアハ体験。理解が繋がっていく楽しさ。

今日3度寝した人。はい、私です。

寒くなってきた影響か、朝に弱くなってきました。

 

 

まずは、前回の記事の答え合わせから。

結論:==の使い方を間違えた。

 

==は変数や配列には使えないというのが答え。

あくまで”左右の文字列が一致しているか”をジャッジする。

 

name = "yuki"

name == "yuki"

としても、等号比較メソッド==さんは、

「左にあるやつ文字列でない上に、同じ表記でもないやんけ」

と判断し、結果をfalseと返す訳ですね。

 

勉強になりました。==さんありがとう。

 

f:id:miyamon_good:20201025220627j:plain

 

さて、気分的に11月導入される

とある魔術の禁書目録」のパチンコ台スペックでも見ながら雑談しよう。

 

と思ってたんですが・・・

 

タイトル回収。

プログラミングで今月で1番のアハ体験をしたので、それについて書きます。

 

まずは、下図を。

f:id:miyamon_good:20201026232713p:plain

このコードを見て私が疑問に思ったことは3つ。

 

①createアクションでインスタンス変数が3つ生成されているが、これはなぜ?

※見えませんがviewへの出張先はなかったので、インスタンス変数にする必要はないのでは?と思っていました。

②@room.messsage.newは、Message.newではダメ?

③redirect_toに引数(@room)はなぜ?

 

これらを疑問に思ったのですが、蓋を開けてみると・・

 

「なるほど。確かにこうなるわ。」

 

という訳で順番に解説をしていこうと思います!

 

①結論:redirect_toとrenderがあるから。

・redirect_toはroom_message_pathへ

・renderはindexアクションを介さず、indexページへ

これらはコントローラーから飛び出して外の世界へ外出してます。

外出するならローカル変数ではなくインスタンス変数になる。スッキリ。

さらにもう1つ言っておくと、indexアクションを介さずindexページへ行く訳なので、

indexアクションで定義された変数以外を持っていったら、

indexページさんはそれ何?となります。

なので、持っていく@messagesは同じ定義文となっている訳ですね。

 

②結論:ダメ。

Message.newだと「どのroomに対してのmessageなのか」がわかりません。

なので、@room(さっき定義したroom)をつけてあげましょう

ちなみにこの書き方はアソシエーションしているから為せる技。

 

③結論:保存後の情報に更新するため。

ここでは、保存に成功した時のページ遷移を決定しているのですが、@roomをつけないと保存した文が表示されずわかりにくくなる。

なので、区切りをつける意味でも新しくインスタンス変数を生成すると無事表示される。

 

 

長々となりましたが、こんな感じです。

間違っていたら申し訳無い。

 

理解するのに、時間はかかりましたが楽しかった。

プログラミングの醍醐味ってこういうところなのかなと思います。

 

では、おやすみ(つ∀-)オヤスミー

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

mergeメソッドとの邂逅

この土日の学習捗らなかった人。はい、私です。

 

人それぞれ勉強のやり方はあると思うのですが、

プログラミングスクール3回目の週末で分かったこと。

 

「メンターさんに質問し、理解することが勉強のモチベーションになっていた」

 

これ。これが全てとは言いませんが間違いなく1つの要因。

初めてメンターさんに聞かない1日が今日だったんですが、いまいち没頭できない。

 

気がつけば、戦国乙女6を打ちに行ってたり、魔女の旅々を見てたり。

もったいない時間ではあったがそれで片付けたらダメですよね。

この時間を無駄にしない為のアクションプランを2個考えた。

 

1:「わからないことを探して質問する」

2:「本当に必要なときだけ車に乗る」

 

1の肝は順番。

「わからないから聞く」

ではなく、

「聞くためにわからないことを探す」

 

f:id:miyamon_good:20201025220627j:plain



タイトル回収いきましょう。

<mergeメソッドについて>

・昨日までの私の認識

「permitで選択できないカラムを追加するために使う」

 

・今の私の認識

「requireで選択した配列に含まれない情報だけど、

 必要だからついでにこれも頼むわ!」

 

merge以前に色々間違った解釈をしていたことに気づく。

改めて理解して、思ったこと。

 

「mergeめっちゃ便利ですやん」

 

本来だとこちらが改めて記述することをついでにしてくれる。

ありがとう!merge!

 

 

では、最後にrubyを貼り付け。

今日、彼女と話している時にネタ用に書いてみたコード。

f:id:miyamon_good:20201025222912p:plain

思い描いている結果にはならず。

 

 

これならどう?

f:id:miyamon_good:20201025223231p:plain

うまくいった!!

分かる方からすると、すぐ分かるんだと思うのですが何がダメだったのか?

 

理由はまた次回に。おやすみ(つ∀-)オヤスミー

初めまして。元パチンコ店員がエンジニア転職を目指すブログです。

まずは自己紹介ですね。

 

大阪寄りの兵庫に住む26歳です。

前職は新卒でパチンコ店で働いていました。

 

大学でパチンコ、スロットが好きだったので、

そのまま仕事にしちゃった人? はい私です。

 

とはいっても、負けるのは嫌だったので最低限の立ち回りはしてました。

f:id:miyamon_good:20201023225343j:plain

残ってたのがこれだけだったので、証拠として。

 

好きなこと・趣味は

・パチンコ/パチスロ

・麻雀

・旅行

・ご飯(色々なごはん屋さんに行くという意味で)

・コーヒー

・野球/阪神ファン

・彼女のツボマッサージで痛がる姿をみること

 

f:id:miyamon_good:20201023225946j:plain

f:id:miyamon_good:20201023230124j:plain

こんな感じで旅行大好きでした。

 

で、現在ですが・・・

 

 

プログラミングスクールに通っています。

今、3週目に突入しました。

 

やってて思うのですが、

 

ーーーアウトプットめっちゃ大事ーーー

 

頭に定着させるには、これが欠かせません。

てなわけで!

 

このブログは、以下の点を書こうと思ってます。

・学習内容のアウトプット

間違った解釈の可能性有り。むしろ大。

・日々の気付き、思ったこと

・気になるパチンコ、パチスロ

・雑談

この辺りを書きたいと思ってます。

できる限り、プログラミングのこと書きます。

 

 

最後に、

今日やってたこと、学んだことをさらっと。

f:id:miyamon_good:20201023232021p:plain

 

こんな感じで書いたコードを言語化してました。

 

目的は、

1:理解できていないことの炙り出し

2:自分で考える、主体的な学びをする

 

やってて思ったのが、

 

”なんとなく理解した気でいた”

”なんとなく言ってることはわかるが、うまく言葉にできない”

 

ってこと。

 

例えば、

<div class="contents row">
<p><%= @nickname %>さんの投稿一覧</p>
<% @tweets.each do |tweet| %>
<%= render partial: "tweets/tweet", locals: { tweet: tweet } %>
<% end %>
</div>

 

 

これでlocalsオプションの役割を説明しようと思ったら、

イマイチうまく言葉にできなかった。

 

言語化した今の解釈は、

 

右のtweetはeachで呼んだ一つ一つのtweetを指し、
左のtweetはそれを部分テンプレに持っていく

 

ってニュアンスで捉えています。

これって、

 

コントローラーがモデルから受け取った原材料(=右のtweet)を

ビューに渡して加工してもらう(この場合、renderでimageとtextを追加)

 

このために、localsオプションで繋いている

 

という解釈です。間違っていたら教えて頂きたいです(笑)

 

 

こんな感じでやっていこうと思ってます。

間違い上等、とにかく自分で考えてみる。

そのスタンスでいきます。

 

おやすみなさい(つ∀-)オヤスミー