【ハンズオン参加レポ】JAWS-UG CLI専門支部 #179R AWS CLI環境入門(Cloud9)に参加しました
初めに
2021/5/20に、JAWS-UG CLI専門支部のハンズオンに参加しました。
初心者向けのハンズオンだからと軽い気持ちで挑みましたが、予想以上にボリューミーかつ学びの多いハンズオンになったので、せっかくなので参加レポートを書いてみようと思いたち、筆を執った次第です。
ハンズオンの実施と感想
1. ハンズオンについて
- Cloudshellを利用して、AWS CLIを実行し、Cloud9の実行環境を構築する内容をハンズオンで実施した。
- なぜCloud9を使うのか
- 可能な限りCredentialを発行しないため
- Credential流出で850万円の損害が出ることも、、、
- 可能な限りCredentialを発行しないため
2. 経験できたこと、学んだこと
ハンズオン内で経験できたこと、学んだことを箇条書きで挙げてみました。
- AWS CLIに慣れることができた
- なるべくマネジメントコンソールを使用しない手順だったので、コピペとはいえ何度もCLIコマンドを入力することで少し慣れた気がした。
Cloudshellを初めて使った
Cloudshellとは？
AWS CloudShellはブラウザベースのシェルであり、AWSリソースの安全な管理、探索、操作を簡単に行うことができます。CloudShellは、コンソールのクレデンシャルで事前認証されています。一般的な開発および運用ツールがプリインストールされているため、ローカルでのインストールや構成は必要ありません。CloudShellを使用すると、AWS Command Line Interface（AWS CLI）でスクリプトをすばやく実行したり、AWS SDKを使用してAWSサービスAPIを試したり、その他のさまざまなツールを使用して生産性を高めることができます。CloudShellは、ブラウザから直接、追加費用なしで使用できます。(公式参照)実際にハンズオンで使ってみて、AWS CLI実行環境が一瞬で無料で使えてしまうのは便利すぎる！と思いました。ある程度CLIの実行環境が整っていたら別ですが、新規アカウントの使用開始時の環境構築をする機会があったら、ぜひCloudshellから始めたいな、と感じた。
ハンズオン内で、CLI V1とV2の差異についても学べた。
CLI V1では、デフォルトリージョンの環境変数は$AWS_DEFAULT_REGIONだが、V2では$AWS_REGIONが$AWS_DEFAULT_REGIONより優先されるようです。(AWS CLIのgithubページ参照)
IAMについて少し詳しくなれた
- IAMロールはLambdaなどには直接アタッチできるが、EC2にアタッチする場合は直接できず、インスタンスプロファイルを介してロールをアタッチする。
- なんとなく知った気ではいたが、インスタンスプロファイルってEC2以外のロールアタッチに使わないよなあと、、
IAM(グループ、ユーザ、ロール)のポリシーパス入力を明示的にすることでARNは変わるが、処理が早くなり？&管理しやすくなる！- グループもユーザーもロールもポリシーもパスを指定して作成できて、パスプレフィックスで絞り込みできるようになり、処理が早くなり？&管理しやすくなる！1
- カスタムポリシーが一番如実な差が出る。[^1] ←
ロールが一番如実に差が出るらしい？ - ハンズオン内では比較できなかったので、別記事でまとめてみよう。 (宿題)
- カスタムポリシーが一番如実な差が出る。[^1] ←
- IAMロールはLambdaなどには直接アタッチできるが、EC2にアタッチする場合は直接できず、インスタンスプロファイルを介してロールをアタッチする。
- JSONファイル作成時はフォーマットが壊れていないか確認する(pythonのライブラリを使用するとよい)
- AWS CLIのコマンドはタブ補完が効く！オプションも補完いける！
- タブでわからなければコマンドリファレンス、それでもなければAPIリファレンスを確認する。
- 手順書の書き方
3. ハンズオンの感想
「初心者ハンズオンだからといって学びは少ないだろう」なんという先入観があったが全くそんなことはなく、学びの多いハンズオンであった。
多少資格をとってAWS知見のあるエンジニアだと思いこんでいたが、己は業務経験なしの未経験AWSエンジニアで、AWSもAWS以外についても、まだまだ知らないことばかりなんだと、実感。わかっていたつもりではあったが、知識だけじゃなく手も動かさないとだめだ！と強く感じさせられた。
CLIハンズオンシリーズは、7月くらいまで可能な限り毎週開催するとのことなので、できるだけ毎回参加できるように、仕事を早めに終わらせよーと心に決めた。
4. 次のアクション
主催のHatanoさんが、復習しましょうね〜とおっしゃっていたので、ぜひ今回のハンズオンの内容を復習したいのですが、全く同じことを何度も繰り返すのも飽きてしまいそうだと思いました。
そこで今回は復習を工夫して、今回CLIコマンドポチポチで実装した環境と同じものを、AWS CloudFormationで自動構築するテンプレートファイルを作ってみようと思います！ (IaC好きエンジニアの端くれとして自動化してみたい！と思ったからです)
土日いっぱいを目処に作成するぞ！次回の記事を乞うご期待。
-
主催のHatanoさんに指摘いただき、修正↩
【勉強会メモ】AKIBA.AWS ONLINE #03 -IaC を語りたい 編- に参加しました
こんにちは、IaC経験は下記で、ほぼ初心者のAshisanです。
- Ansible(運用で少々)
- AWS CloudFormation(構築で少々)
今日は、クラスメソッド株式会社のオンライン勉強会「AKIBAAWS ONLINE」に参加しました。
このイベントは3回目で過去3回とも全て参加していますが、特にアウトプットしていなかったのですが、特に今回は勉強中のIaCがテーマということで特別楽しみでした！
そんなこんなで今回からレポートを書こう！と思い立ち、早速記事(ほぼメモですが)にしました。
レポート
1. IaCで全てが上手くいくと思うなよ！失敗事例のご紹介
Speaker：mokoさん
初めに
- いきなりまとめ
- 「IaCは手段であり、目標である」
- 「何も考えないでIaCにすると後悔する」
- 「リソースを素手で触らない強い意志」
IaCとは？
- IaC= Infrastracture As Code
対象範囲
- AWS環境のコード化のみ触れる ※OSミドルについては対象外
IaCツールの比較
- Terraform
- CloudFormation
- いいところ：yml、jsonで書ける(簡単)
- 悪いところ：単純な繰り返しも書きづらい
- CDK
- 慣れた言語からCFnを実行できる
- その他
- AWS SAM
- Severless Flamework
あるある失敗
- メンバがIaC未経験の場合
- IaCは明示的にパラメータを入れなきゃいけない
- さくっとコンソールから作ることばっかやってるとできない
- CDKならいい感じに作れるが、暗黙で作られるリソースの把握が大事
- 学習コストの発生は時間が解決してくれる(1ヶ月もやればそのうち慣れる)
- IaCは明示的にパラメータを入れなきゃいけない
- IaCが目的
- IaCでやらなくてもいいのに、頑張ってIaCにしちゃう
- 構成管理不要なのに、無駄に頑張っちゃう
- 結果マネコンでやったほうが運用しやすかったりする
- とはいえIaCにするメリットはたくさんあるので、目標に設定するのはあり
- IaCでやらなくてもいいのに、頑張ってIaCにしちゃう
- 手動オペレーションしちゃう
- 一番あるある
- IaCで管理しているリソースをまねこんから変更しちゃった(まずい)
- 環境を見て差分うめはできるので、なんとかできる
- IaCでリソース管理してるけど、デプロイが手動
- 一番良くない！
- とある事故(あるある失敗例)：手動オペレーションで破綻
- スタック(ファイル)分割ができる
- スタック間のパラメータ連携はOutputs(まねこんの出力)をみてやってる
- 画像参照、参照されていない順にデプロイする必要がある
- ダウンタイム無しで真ん中のインスタンスを入れ替えたい
- どうすんの？？
- 手動オペレーションを含んだややこしい手順
- なぜこうなったか→依存関係がごちゃごちゃ
- CFnのスタックはライフサイクルごとに管理しろ
- EC2とALBは同じスタックでもいいが、規模が大きいとコード量がやばい
- Nested Stackも最近できるようになったが、、、
- 子スタックの更新差分まで見れるのは最近になってやっと
- 規模が大きい場合はTerraformを推奨
- 深澤さんのセッションで詳しくは解説
IaCのメリット、デメリット
メリット
デメリット
- コードに起こすのしんどい
- 設計きちんと考えなきゃいけない
- IaCでの運用投げ出しがち
mokoさん流IaCベストプラクティス
- IaCとの付き合い方を決める
- 構築だけIaC
- IaC使って運用する
- IaCもCI/CDする
- Gitを正しく使う
- レビューきちんとやろう
- CI/CD環境を整える
- Linterいれたり
- Mergeしたら自動デプロイさせたり
- 手動デプロイは甘え！！！オペミスの根本原因
- Terraform Cloudってのもあるよ
- Gitを正しく使う
- AWS環境は素手で触らない(超重要)
- スケーリングさせる(少し関係ない話)
- アプリのデプロイとIaCは別で考える
- アプリはアプリのCi/CDパイプラインで完結させる
- デプロイのためにIaCを触るのはしんどいから分離しよう
- インフラとアプリの境界線はしっかり引く
- アプリとセットで作れるツールの場合はセットで考えよう
- CDK/Copilit/SAM
- アプリはアプリのCi/CDパイプラインで完結させる
まとめ
- IaCはメリットがでかいからみんなつかおう
- ある程度注意すればOKだよ
- せっかくAWS使いならいい環境にしよう
- スケーリング、CI/CD
2.Former2でコード生成してGUIポチポチ卒業の第一歩を(仮)
Speaker：inomasoさん
想定視聴者
- 手作業環境構築につかれた人
- IaCに興味があるけど、、な人
- 構築済みなAWS環境を持ってる人
ゴール
- GUIポチポチ卒業
IaCとは
- インフラをコードで記述すること
- 最初はシステム管理の自動化だけが焦点、いまはプラットフォームまで拡大
formar2ってなに？
- ブラウザベースのサービス
- AWSの認証情報をつかって
- セットアップ方法
- IAMアクセスキー、シークレットキー入力がある！？
- 大丈夫なん？
- 絶対外部に送信しないから大丈夫だよ、だそう
- とはいえ、抵抗がある人へ
- ローカルのDockerでFormar2コンテナを起動できるよ
- IAMアクセスキー、シークレットキー入力がある！？
既存リソースのコード化
- EC2の場合
- ボタンポチポチでTerraformのコードが自動でできる
- CFnでも出力可能
自動生成コードの注意点
- 再利用のときは注意してね
- リソースID指定
- リソースIDがそのまま出るので、新規作成時に使いまわしするとエラーになる
- 「リソースの種類.任意のリソース名.id」で指定すればOK
- IAMポリシー
- IAMポリシーがテキストで出力される
- 共通のポリシーを使い回すときは管理が煩雑に
- 解決策：JSONでポリシードキュメントを書こう
まとめ
- Formar2は銀の弾丸じゃないよ
- まず小規模環境から、IaCを始めるきっかけに
- 検証環境をとりあえずコード化するのは便利
3. TerraformとCloudFormationどちらを採用すべき？
Speaker：深澤俊さん
- Terraform vs CFn
前提
- 納品物に指定ある？
- メンバでメンテできますか など
CloudFornationとは
Terraformとは
- Hashicorp製
- HCLで書ける
- ローカルPC上で実行
- キーの管理を考えないといけない
- EC2上でやる or スイッチロールでセキュアな認証ができる
違い
- 異なるリージョン、アカウントへのデプロイ
- CFn：StackSetsを使う
- Terra：異なるProviderを使う
- AWS内でのIaCならCFnはデプロイしやすい
- 異なるIaaSへのデプロイ
- Terraformしかできない
- 差分検出
- IaC管理してるが、つい手作業で修正しちゃうことはよくある →どう検出する？
- CFn：ドリフト検出
- AWSサービスでできるので楽
- Terra：Planコマンドを使って差分比較
- 作り込みが必要
- ロジック
- 排他制御
- バージョン管理
- うまく管理する必要あり
- 環境差異をなくす、最新への追従
- CFn：管理しなくていい
- Terra：Terraform自体とProviderのバージョン管理する必要あり
- 言語のバージョン管理に似ている
- うまく管理する必要あり
- 開発ツール
まとめ
全体まとめ
- IaCにもいろいろあるが時と場合によって使い分けよう
- IaCを使うには制約を受け入れる覚悟が必要
- 大変だがIaCはとてもいいもの
- 結論：みんな、IaCを使おう！
みんな、IaCやろうぜ #AKIBAAWS
— Ashisan (@oni_py) 2021年5月18日
2021年1月〜4月の振り返りと5月の目標設定
はじめに
日常の頑張りを棚卸しするために、月ごとに目標を立て、定期的に振り返っていこうと思います。
振り返り
1月
- 12/27にAWS SAAに合格した
- ほぼ1月なので入れちゃいました
2月
- LPIC101に合格した
3月
- LPIC102に合格した
4月
5月の目標
さいごに
ひとまず2ヶ月！ 続けられるようにがんばってみます。
【ポエム】転職にあたっての振り返り(SES→AWSエンジニア)
Twitter眺めていたら良いお題があったので、久しぶりに文章を書いた。
リプしようとしてたら元ツイ消えちゃってたからなんかブログにポエムとしてまとめてみる。
自己紹介
- 現職は独立系SIerのインフラエンジニア(SESのオンプレor仮想基盤)な私。
- 今後のキャリアを考えパブリッククラウドに慣れ親しむエンジニアになりたいと思って転職活動を始め、ご縁がありAWSに特化した企業のオファーをいただけた。
はじめに
キャリアチェンジに際して、下記３点を入社前に今一度振り返ってみようと思う。
- 現職のSESのインフラエンジニアとの比較
- なぜクラウドエンジニアとしてのキャリアを選ぶのか？
- このキャリアに懸念はないのか？
SESインフラエンジニア vs AWSエンジニア
以下、SI、AWSと略してく。
1. 経験フェーズ
- SI：下記のような幅広いフェーズを経験できる。
- 基本設計〜詳細設計〜構築/移行〜運用/保守
- AWS：フェーズは上流に特化。
- 基本設計〜詳細設計〜構築まで
2. 各技術の経験値
3. 商流
4. 仕事の進め方
- SI：チームで働く、大規模PJ
- 周りと上手くやる力が必要
- AWS：セルフマネジメント、小規模PJ
- 個人で仕事を進める力、周りに相談する力が必要そう
5. 働き方
- SI：基本は客先常駐、各PJによる
- 準委任
- 成果に関わらず、与えられた役割を遂行すればOK
- AWS：客先常駐なし、基本フルリモート・フルフレックス
- 基本請負
- 働き方は自由だが、期間内に確実に成果を生むことを強いられる
なぜAWSエンジニアと言うキャリアを選ぶか？
1. 今最も熱い技術領域のひとつだから
- パブリッククラウドは既存のオンプレ仮想基盤に負けるとも劣らないインフラ技術領域の選択肢。
- インフラ担当のエンジニアとして、キャッチアップすべきな技術のひとつ。
2. 顧客の知識が成熟していて技術への期待値が高い
- 一昔(5,6年)前であれば、少しAWSの知識があったり、経験があればすごい！というレベルだった
- 今や皆(インフラだけでなくアプリ技術者も)が詳しくなってきていて、少々知識・経験がある程度ではもはや価値がない。
- この技術領域で戦っていくには特化しなければならない！！
- 今や皆(インフラだけでなくアプリ技術者も)が詳しくなってきていて、少々知識・経験がある程度ではもはや価値がない。
3. 特定の技術のスペシャリストになりたいから
- AWSに限った話ではないが、1つの領域に特化できれば横展開しやすい。
- 今最も熱く、顧客の期待も大きい技術領域での業務経験を通じて、技術者として大きく成長できることを期待。
懸念
1. ベンダーロック
2. クラウド以外の技術に弱くなる？
- これは考えにくいと思う。
3. 構築以降のフェーズを経験しづらい
- これはひとつ残念なところだと思うが、今後も率先してやっていきたいわけではない(移行/運用/保守)
- やりたくなったらまた考えればいいのでは、と思う。
- SIに戻る or 自社開発の会社に行く
- 転職を決めて一番よかったことは、「今したい・すべきことをする、後のことは後で考える」と考えられるマインドになれたことかも。
- やりたくなったらまた考えればいいのでは、と思う。
その後のキャリアとして
まずは「AWSを極める」は確実に遂行することを第一に、その後については今は考えないことにする。 今見えている景色と絶対違ってくと思うし、転職後の業務や技術に慣れてから考える。
まとめ
AWS-SAAに一発合格しました
概要
12/27にAWS-SAAを受験し、無事合格しました。
自己紹介
- 独立系SIerのインフラエンジニア3年目(サーバ・ネットワーク系の基礎知識あり)
- これまでパブリッククラウドの業務経験なし(プライベートクラウド・オンプレ経験のみ)
- AWS経験はハンズオンで軽くやった程度(EC2、S3)
試験2週間前までのまとめ
- 前回記事で、受験のきっかけ、勉強開始〜２週間前までにどのような試験対策をしていたかまとめています
AWS-認定SAAに挑戦します - Load to Professional...
試験直前2週間前にやったこと
①「AWSWEB問題集で学習しよう」でひたすら問題を解く
試験直前は「AWSWEB問題集で学習しよう」の問題#80〜#140を正答率をGoogle Spread Sheetにメモしながら1周し、正答率が低かったもののみ2週目を行いました。
2週目ですべての問題で8割以上の正答率を超えた頃に、「本試験モード」にて2回連続9割以上を得点できたので
「AWSWEB問題集で学習しよう」の回答ページは、問題の選択肢毎にAWSの公式ホワイトペーパーや某methodさんのAWS記事へのリンクが貼られていて、
② 苦手箇所をAWS BlackBeltで学習
重点的に学習するべき項目の勉強に役に立ちました
試験について
試験内容については守秘義務があるので詳しくは書けませんが、 「AWSWEB問題集で学習しよう」の設問の範囲の知識がある人だったら、どの問題も2択までは絞ることができると思います。
2択から1つをどのように選ぶかは、その問題がどのような意図で出題されているかを考えるべきです。 →パフォーマンス重視？コスト最適化重視？保守運用のしやすさ重視？など
一部初めて見る問題や、全然わからない問題もありましたが、大半は自信を持って答えられたので良しとしました。それでも結果的に合格できました。
やればよかったなと思ったところ
短期間でAWS SAAの合格を目指す試験対策的にはこの学習内容で良いと思います。
ですが、合格後AWSを少し触っていて、今後実務で使う頃を考えると知識だけでは足りずハンズオンや実際の環境構築などの知識以外の経験が必要だなと感じました。
最後に
この1年資格を1つでも多く取れる1年にしたいので慢心せず、勉強を続けたいと思います。 今の所の予定は下記
2021/3 Oracle master Bronze
2021/5 基本情報技術者(FE)
勉強していく中で、アウトプットの癖をつけるという意味でもまたブログにかけるといいなと思います。
AWS-認定SAAに挑戦します
はじめに
自己紹介
- 独立系SIerのインフラエンジニア3年目
- これまでパブリッククラウドの業務経験なし(プライベートクラウド・オンプレ経験のみ)
- AWS経験はハンズオンで軽くやった程度(EC2、S3)
なぜ受験するか？
資格とってみよう、の第一歩と パブリッククラウドへの興味、憧れ。
インフラエンジニアとしての今後のキャリアを考えたとき、周りに能力を証明できる資格をなにも持っていないのはまずいと考えたことと、 クラウド案件の経験はないが今後経験させてもらえるように最低限この資格は持っておきたかった。
この二点が理由でした。
これまでの学習
勉強方法
- 参考書
- WEB資料(AWS blackbelt)
- udemy講座
使用している参考書/WEB資料
参考書
→
- 徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書
udemy講座
- これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座
学習期間
-2019/4〜
最初にudemy講座を買った日。
ほぼ未着手のまま1年くらい立っていた気がする。。。
ので実際は下記の期間。
- 2020/6末〜2020/12 現在
最初に参考書を買った日を初日としてます
学習時間
平日:30分〜1時間
休日:1時間〜3時間
やったりやらなかったりしていたので、 今日まで100時間いかないくらいやった気がします
学習方法
① ハンズオン学習 (勉強期間：数ヶ月)
- udemyの「これだけでOK〜」を実践
良かった点：
ハンズオンでAWSのサービスを実際に触りながら勉強できたことがよかった。このあとは参考書メインの勉強になったが、はじめにハンズオンをやっていてよかったと感じたことも少なくなかったと思う。
解説セクションは、②、③の参考書より内容はずっと濃く、サービスのより詳細についてまで網羅。
良くなかった点：
とにかく長い。
一本一本が長くすべて順番通り実施しようとしてしまったため、感想までにめちゃめちゃ時間がかかってしまって、完全に学習のボトルネックになっていた。
② 参考書学習(期間：2ヶ月)
- 「AWS認定資格試験テキスト〜」(オレンジ本)
良かった点：
AWSのサービスごとにカットされてさらっと書かれていて読みやすい。
内容が薄めなので網羅的にサービスを理解しやすく、出勤時間のお供に最適だったと思う。
良くない点：
いい点でもあるが内容が薄いので、これだけで実際の試験を乗り切るのは正直厳しそう。
本当に学習を始める導入用。
- 「徹底攻略 AWS認定〜」 (黒本)
良かった点：
オレンジ本はサービスカットだが、黒本はAWS Well-Architected フレームワークカット。
試験はサービス単体の内容より要求されるフレームワークに合ったサービスはどれ？という形式で出ているらしいのでより実践的。
良くない点：
オレンジ本と同じく内容は薄め。
サービス間連携を学ぶ導入としてはとてもいいと思うが。
③ひたすら問題集を解く+知識の補填 (期間：2ヶ月〜)
- 黒本の問題集、udemyの問題集など
良かった点：
これをもっと早くにやるべきだった。
知識習得 → 実践 → 不足箇所の補填
このサイクルで現在やっていますがただ本を読んでいるより定着率が違う。
今後の資格勉強のベースにしていきたい。
良くない点：
始めることが遅かった。
受験2ヶ月前。。。
これから
12/27に受験します。
正直自信はないですが、、、受かっても受からなくてもまたブログ記事にしてみよーと思います！
さいごに
この試験をとって終わり！とは考えていません。
今年は今後ももっと資格学習進めていきます！
今後取りたい資格
- 基本情報技術者
- Oracle master bronze/silver
- Oracle Java silver
来年にかけて取りたい資格まだまだあるのでAWS-SAAは一発で通りたい！と思っているが果たして。。。
以上、ここまで読んでいただいてありがとうございました。
active_adminを導入しよう
自作Webページにactive_ adminを導入してみたのでその記録をしてみる。
1.開発環境
2.導入理由
- GUIでDB操作ができるように管理者コンソールを作りたい
- 0-1で作るのは時間的に厳しいのでgemを使おう
上記Qiitaの記事を読んで、総合的に一番優秀そうな
「active_admin」
に決めました。
3.導入
3-1.Gemfileからのbundle install
gem 'activeadmin' gem 'devise'
$ bundle install
※当方環境ではDockerを使用しているので、docker-compose build し直しました。
これも設定次第でbuildし直ししなくてもよくなるそうなので適用して近々記事にします！！
うまくいけば下記のように追加されます
3-2.Gemfile.lock
activeadmin (2.4.0) arbre (~> 1.2, >= 1.2.1) formtastic (~> 3.1) formtastic_i18n (~> 0.4) inherited_resources (~> 1.7) jquery-rails (~> 4.2) kaminari (~> 1.0, >= 1.0.1) railties (>= 5.0, < 6.1) ransack (~> 2.1, >= 2.1.1) sassc-rails (~> 2.1) sprockets (>= 3.0, < 4.1) sprockets-es6 (~> 0.9, >= 0.9.2) 以下略..... kaminariとかransackとかがありますね〜
3-3.Rails generateする
$ bundle exec rails g active_admin:install
invoke devise
generate devise:install
create config/initializers/devise.rb
create config/locales/devise.en.yml
===============================================================================
Some setup you must do manually if you haven't yet:
1. Ensure you have defined default url options in your environments files. Here
is an example of default_url_options appropriate for a development environment
in config/environments/development.rb:
config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }
In production, :host should be set to the actual host of your application.
2. Ensure you have defined root_url to *something* in your config/routes.rb.
For example:
root to: "home#index"
3. Ensure you have flash messages in app/views/layouts/application.html.erb.
For example:
<p class="notice"><%= notice %></p>
<p class="alert"><%= alert %></p>
4. You can copy Devise views (for customization) to your app by running:
rails g devise:views
===============================================================================
invoke active_record
create db/migrate/20191007000038_devise_create_admin_users.rb
create app/models/admin_user.rb
invoke rspec
create spec/models/admin_user_spec.rb
invoke factory_bot
create spec/factories/admin_users.rb
insert app/models/admin_user.rb
route devise_for :admin_users
gsub app/models/admin_user.rb
gsub config/routes.rb
append db/seeds.rb
create config/initializers/active_admin.rb
create app/admin
create app/admin/dashboard.rb
create app/admin/admin_users.rb
insert config/routes.rb
generate active_admin:assets
create app/assets/javascripts/active_admin.js
create app/assets/stylesheets/active_admin.scss
create db/migrate/20191007000042_create_active_admin_comments.rb
うまくいきましたね。
3-4.DB Migration
$ bundle exec rails db:migrate
3-5.seedsでテストユーザを仕込む
$ bundle exec rails db:seed
3-6.ログインしてみる
active_adminの/adminが管理画面のデフォルトのルートになっているので ローカル環境でアクセスしたければ localhost:[ポート]/admin にアクセスしましょう。
⬆️作成したテストユーザのEmailアドレスとパスワードでログインしてください。
うまくログインできました！
カスタマイズ0でこんなに手軽に完成度の高い管理者コンソールができちゃいます！
4.現行環境に適用
デフォルトでは個別ページとして
- admin_user
- comment
のみModelとして登録されているので
既設のModelを登録するためにはactive_adminのresourceに追加する必要があります。
4-1.既存のUserモデルをactive_adminに追加
$ rails generate active_admin:resource User
create app/admin/users.rb
⬆️Users Modelの追加が確認できました
Modelの操作をする前に... 先ほど作成された「users.rb」に以下を追加しましょう。
permit_params :name, :admin
これでModel操作の準備ができました！
string属性のNameの入力フォームだけでなく
boolean属性のadminのチェックボックスも自動生成してくれます。
→ 必要情報を入力しCreate Userを選択すれば....
⬆︎testユーザの作成が確認できます。
まとめ
- 導入簡単
- Model操作もやってくれる
- カスタマイズには学習コスト要
以上です。 皆さんもぜひ試してみてください！
