その3から続く
CloudTrailで操作ログを記録しよう
注意!
料金がかかるのが嫌な方はCloudTrailの設定をスキップしても大丈夫です。
CloudTrailとは?
AWSユーザーの操作を記録するサービスです。
デフォルトで有効になっていますが、保存期間は90日です。
記録場所はS3に保存されます。
S3に操作ログを保存することでずっと保存できます。
S3で料金が発生します。
無料利用枠と有料利用枠があります。↓
またはコチラ→AWS CloudTrailの料金
料金がかかるのが嫌な方はCloudTrailの設定をスキップしても大丈夫です。
AWSユーザーの操作を記録するサービスです。
デフォルトで有効になっていますが、保存期間は90日です。
記録場所はS3に保存されます。
S3に操作ログを保存することでずっと保存できます。
S3で料金が発生します。
無料利用枠と有料利用枠があります。↓
またはコチラ→AWS CloudTrailの料金
Identity and Access Management (IAM)の略でAWSのサービスを利用するユーザー権限を管理するサービスです。
そのアカウントのすべてのAWSサービスとAWSリソース全てに完全なアクセス権を持つ特権ユーザーの事です。
つまりなんでもできてしまうので極力使わないようにします。
アカウントの変更・解約・サポートプランの変更等をする時のみ使用します。
AWSで作成するユーザーのことです。
認証情報とアクセス許可の権限を個別に変更できます。
作業者ごとに個別に作成して権限を与えます。
通常の作業はIAMユーザーで行います。
先程保存したcsvファイルを開きます。
https://から始まるリンクをクリックします。
RubyMineを使っていて普通のGit操作を少し忘れかけていたので、備忘録として
cd
デスクトップで作業したので
cd desktop
ディレクトリを作成
mkdir rails
railsに移動
cd rails
rails newにて作成
rails new api --api
Bundle complete! 8 Gemfile dependencies, 51 gems now installed. Use `bundle info [gemname]` to see where a bundled gem is installed. run bundle binstubs bundler
↑のような文言が出たらrails new に成功しているので
cd api
rails s
rails g model Todo title:string user_id:integer
rails db:migrate
rails g controller v1::todos
本編(ここでGitHub登場)
cd ..
git init
Initialized empty Git repository
↑のような表示になってればOKです。
git status
On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) api/
cd api
git config --global user.name ユーザー名
git config --global user.email メールアドレス
git add -A
git commit -m "add new file"
git remote add origin https://github.com/自分のGitHubを記述
git push origin master
Enumerating objects: 84, done. Counting objects: 100% (84/84), done. Delta compression using up to 8 threads Compressing objects: 100% (69/69), done. Writing objects: 100% (84/84), 20.69 KiB | 2.30 MiB/s, done. Total 84 (delta 0), reused 0 (delta 0) remote:
↑のような文言が出たらOK
AWSはクラウドサービス
サービスが豊富(EC2、RDS、S3など高負荷に耐えられる信頼性の高いシステムを少ない手間で運用できる)
リソースが柔軟、必要な時に必要な分だけ調達できる
大型アプデのとき→サーバーを増やそうっていうのができる
使った分だけ払う従量課金制
Infrastructure=基盤
システムやサービスの基盤となる設備でITではサーバーとネットワークだよ。
自分でサービスを作れる、リリースできる。
開発する際のテスト環境を自分で作れる。
システム全体で対応できる。
障害があったときどこに問題があるか切り分けられる。
対応策を考える時にアプリだけでなくシステム全体で対応できるようになる。
どのようにインフラを構築するか
どのようなサーバーが必要かを考える
サーバー設置、OSインストール、各種設定
必要なソフトウェアをインストールし設定
構築したサーバーをネットワークに接続する
IPアドレスの範囲を決める
サーバーにIPアドレスを割り当てる
ドメイン名とIPアドレスの対応を割り当てる
サーバーとはクライアントに対してサービスを提供するコンピュータ
クライアントはサービスのリクエストをしてきたものスマホPCなど
開発しているアプリで必要になったのでまとめ
usersテーブルに紐付いているIfには複数のThenがあるというのを実装したかった。
Rails Tutorial14章
もととなるuserテーブルを作ります。
migration_file class CreateUsers < ActiveRecord::Migration[5.0] def change create_table :users do |t| t.string :name, null: false t.string :email, null: false, unique: true t.timestamps end end end
・user.rb
userはたくさんのsituation(if)を持っていて、
situation(if)を通してたくさんのbehavior(then)を持っています。
class CreateBehaviors < ActiveRecord::Migration[5.1]
def change
create_table :behaviors do |t|
t.text :name, null: false, unique:true
t.timestamps
end
end
end
reference(参照)はテーブル同士の関係性を示します。
ここでbehavior(then)とuserの間を結ぶ中間テーブルを作成しますが、
そこでreferenceというパラメータを使います。
class CreateSituations < ActiveRecord::Migration[5.1]
def change
create_table :situations do |t|
t.references :user, foreign_key: true
t.references :behavior, foreign_key: true
t.timestamps
end
end
end
・user.rb
userはたくさんのbehavior(then)を持っていて、
situation(if)を通してたくさんのbehavior(then)を持っています。
中間テーブルを通して繋がっているものには
through: :situations
というkeyをつけます。
class User < ApplicationRecord
has_many :behaviors, through: :situations, dependent: :destroy
has_many :situations,
User.rbとほぼ同じです。
accepts_nested_attributes_for
というkeyは、
他のモデルを一括で更新、保存できるようにするものです。
ここではbehavior(then)を保存するのと同時にsituationsを更新できるようにしています。
class Behavior < ApplicationRecord
has_many :users, through: :situations
has_many :situations
accepts_nested_attributes_for :situations
end
group_userは1つのuser、1つのbehaviorに属しています。
よって、このように記述します。
class Situation < ApplicationRecord belongs_to :user belongs_to :behavior end