amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

Redmine大阪 Online 参加レポート

7/11(土)Redmine大阪 Online に参加しましたので、レポートを書きます。Redmine.Tokyoは以前から参加していましたが、大阪の方は今回が初参加でした。Redmine.Tokyoの時と同じような雰囲気で楽しく勉強させていただけました!

目次

イベントページ

redmine-osaka.connpass.com

登壇内容と感想

Redmineの開発体制の現況2020 前田剛さん
  • 現状の課題

    • パッチをコミットするのは、Jean-Philippe Lang 氏と前田さんの2人だけ。
    • リリースを行うのはJean-Philippe Lang 氏だけだけど、最近忙しいく意思決定に時間がかかっている。リリース感覚が長くなってきている。
  • RedMica(ファーエンドテクノロジーRedmineであるRedMica)によって課題の解決

    • Redmineのソースを基に半年ごとにリリースしており、次期バージョンの新機能が先行して使える。
    • RedMica公式プラグインと推奨プラグインにより、より多くの新機能を安心して利用できる環境を提供していく。
    • Redmin本体に追加されるのに時間がかかりそうな機能をRedMica公式プラグインとしてリリース
    • RedMica1.2(11月リリース予定)では、3つのプラグインを推奨としてリスト予定
      • Issue Templates、Messsage Customize、View Costomize

やはりどこの現場でも決裁権限を持つ人が忙しくて、なかなか先に進まないって良くある話。でも最新の機能をはやくユーザが使えるようにしたいという働きは、ユーザにとっては本当に嬉しいことだと思います。

こんなRedmineはイヤだ!  @kazuhito_m(みうみう)さん
資料

www.slideshare.net

  • 「権限」「ロール」にやたら「ヒエラルキー」を持ち込む。
  • 過度な隠蔽があると、利用者に隠ぺいすべきかを考える意識を植え付けたり、疑心暗鬼になる。
  • いろいろ問題が重なると、何となく書かない空気になり、使われない、情報集約進まなくなる。

  • プロジェクトや組織の初期は人々が慣れてなかったり、個人がどんな価値ある情報を持つのか分からないので、まずは書いてもらうを重視した方が良い。質より量

  • 書くことのハードル下げて、気軽に書ける環境を作る。「制限する」は機会損失。
  • 人は「書いて」と言っても書かない。「書きたい」を邪魔しないこと。

インフラ勉強会ではお馴染みのみうみうさんでしたが、はじめてお目にかかれました!ホント話上手くて面白いなぁ~

Web会議のマナーじゃないけど、よくわからんルール決める人ってホントどこにでもいますね。 そのルールが成すことは何か、目的は何かが明確でないと、不要なルール、使われないツールになってしまうので、自分も注意して物事考えたいと思いました。

Redmineを使って高度なプロジェクト管理を実現したい!~学生フォーミュラのあるチームへの普及活動 @ak_iwasakiさん
  • 大学だとチームメンバの交代は一般企業より早い。
  • 車両費用に予算優先配分されて、管理側に予算を配分できない。
  • 目指す姿は、過去の設計ミスを繰り返さない。プロジェクトの管理上のミスを発生させないこと。
  • プロジェクト管理の重要性、システム管理(Redmine)で行うメリットをアピール
  • 短期的なメリットがないと動かない。データは鉱山だけど原石。見せ方が大事。

大学生は毎年メンバが入れ替わるから、ノウハウの引継ぎは重要。とはいえ、システム化してもメリットがないと動かないのは企業と同じ。ツールの導入が目的ではなく、メリットや実現したいことを意識することの大切さ、必要だなと思いました。

最速お届け!特盛 Redmine ~お好みプラグイン・テーマの Docker Compose 仕立て~ @juno_nishizaki さん
資料

docs.google.com

  • Redmine構築したくても手順がややこしすぎる!
  • いいプラグインがあっても、インストールが難しいと利用されず問題ではないか?
    • Dockerでインストール・更新。ホストOSにあまり左右されなかったり、構築手順をコード化できる。
  • どんなに素晴らしいものが作られていても、あまり使われていないんだったら意味がない。もっとガンガン使って作成者に感謝の気持ちを!

一度、自宅PCのVirtualboxにサーバ立ててRedmine入れてみたけど、確かに手間がかかる印象。やはり何にせよ、シンプルに事が進むのがいいですね。 Dockerも扱えるようになりたいけど手が回ってない…何処かで時間とって勉強したいと思いました。

そのテストの終了条件は大丈夫ですか? Kogure_Yutaka さん
  • 定量化テスト手法ODC分析
    • 欠陥を8つの視点から分析する。
  • テスト進捗管理システムから障害をRedmineにチケット登録している。
    • タグ付け
    • バグ管理システムをカスタムフィールドで実装
ブラウザさんを眺めてみよう @akiko_pusu さん
  • RedmineはWebアプリケーション。ブラウザがおともだち。
  • セッション管理はCookieがしている。セッションIDが知られると、自分になりすましてログインされる(セッションハイジャック
  • Redmineセッション用Cookieはリクエスト単位で発行されている。
  • 取られると怖いので、ブラウザさんに注意をして送っている。

    • 別のドメインには送らないように。
    • HTTP/HTTPSのみに送信する(HttpOnly)。
    • RedmineではSecure属性(HTTPSのみCookieを払い出す)がデフォルト設定されてない。
      • httpアクセスだとhttpヘッダが見えちゃう。
      • httpからhttpsへのリダイレクトでも注意。sessionIDを保持したユーザが初回httpアクセスするとその通信が見えちぇう。
      • secure属性の設定(config/application.rb)が可能。
    • autologinは慎重に設定しておこう。
      • Secure属性がつくけどcookieの有効期限がデフォルト1年
  • GitHubはかなりガチ(CSPの設定、Cookie設定、X-Frame-Option)に設定されている。

  • アプリは作られたとおりに動くが、悪意あるアクセスかどうかは判断できない。

    • 安全に使うよう設定を心がけて。

たかのさんの資料は柔らかくて優しい絵でいつもとても和みます。 が、内容はかなりガチな内容で見につまされる思いでした。自分は仕事でWebセキュリティについてよく関わるので、Secure属性やCSPという言葉はイヤというほど見ます。本当にWebアプリケーションは作られたとおりにしか動かないので、Redmineに限らず設定不備や脆弱性は残さないよう気をつけないといけないし、それを啓蒙しなければと改めて思いました。

Redmineプラグイン開発スタートガイド2020年版」 @yebis0942 さん

プラグイン開発できるようになれば、Redmine利用を便利にできて仕事を便利にできて良いなぁと思います。自分はプログラミングで何か作るという経験に乏しいですが、小さくても便利に仕事できる仕組みを作って貢献できればなぁと思いました。今更だけど、何かプログラミング言語を身に付けようかな。

Redmineパッチ会の告知」@agilekawabata さん
  • Redmineパッチ会の目的

    • Redmine本体の改善をできる人を増やしたい。
  • オンラインでも継続するために、第0回をRemoを使って開催した。

  • オンライン開催でも十分できることが分かった。
パネルディスカッション 「チケット駆動で成長し組織文化を変える」
門屋さん 予防型PMOからの目標
  • PM × TM
  • 難敵への対処モデル
  • アウトプットを出すための必要条件からの考察

    • PM技術力が高くツールの利用度も高い。この位置のメンバを増やす。
    • できる人の活動をまねる
    • 今のままでいい、めんどくさい、何でやってるのか分からないなど言う難敵が出てくる。作戦を使って自律的ナレッジを作れるようになっていけるように。
    • チケットを切れるようなるには、整理すべきことがある。
      • 測定がしやすいのはアウトプット。そこからプロセスを逆算して目的・ゴール、インプットを考える。
      • どれもが整理されていないとチケットを切れないのでは?段階的にレベルアップしていく必要がある。
正月さん 駆け出しシャドーITエンジニアからの目標
  • チケット駆動で成長し組織文化を変え、良くするためには
    • チケット駆動はツール。ツールの使い方を明確にする。
      • 楽になるという目的だけでは、何に使うかが無いので活用しなくなる。
      • スモールスタートで成功を積み重ねる。最初はバグ管理のみに使った。
    • 絶対的指導者が必要。チケット文化を定着される。
      • ルールが分からない。決まらないから、結果活用されなくなる。⇒全部オレが決めたらいいんじゃないか?
      • 誰かが引っ張らないとやらない。日本人組織のあるある。とにかく最初はバグ出たらチケットを書かせた。
    • 無理をしない、色々とやめない、仲間を増やす。
      • スモールスタート。ルールを決めながらできるところからやる。一足飛びにはやらない。
      • 無理はしないで意見を聞きながらゆっくりと。
      • 仲間は何処かにいる!社内にいなければ社外に!
        • 愚者は経験に学び、賢者は歴史に学ぶ。
あきぴーさん ソフトウェア社会学から
  • Redmineの導入成功パターン
    • ノーチケット、ノーコミットを徹底させた。
    • システム保守にはなじみやすい。
  • アジャイル開発者とRedmine(他のオンラインチケット管理ツールも)に否定的な見解が多い。

  • チケットは2つの顔を持つ仮説

    • ストック型チケット(記憶媒体
      • 過去の障害情報などをストックして検索できるようにする。
    • フロー型チケット(流通媒体)

      • 今誰がボールを持っているか?ステータスは?を見たい場合。
    • チケット文化になじむ人は、ストック型とフロー型の性質、両方をうまく見せることができている。

全体の感想

Redmineを定着するには組織文化を変える活動も必要だと思いましたが、「プロジェクト管理したいからRedmine導入する」だけだと、組織文化によってはうまくいくところもあれば失敗するところもあるのかもしれません。もっと、導入する目的と何を実現したいか、Redmineで何を解決できるのかを深堀りして考え、運用設計した方が良いのかなと思いました。それはRedmineだけではなく、クラウドサービスなどすべてのツールにおいて共通の考え方ではないかと思いました。

東京と大阪、雰囲気は似ていてもそれぞれ違った観点の収穫を得られることに気付きました。これからは東京も大阪も両方とも参加したいと思いました!

ちなみに、初めてみうみうさんのお顔を拝見できたことが、個人的には最大の収穫だったりしますw

あと最後に、いつか大阪行きたい!

JAWS-UG CLI専門支部 #163R CloudWatch Logs入門 ハンズオン実施

7/9(木)JAWS-UG CLI専門支部 #163R CloudWatch Logs入門 に参加する予定でしたが、出社勤務になったため参加できなくなってしまいました… しかし、帰宅後にハンズオンを実施し、CloudWatch Logsについて調べましたので、CloudWatch Logsの概要とハンズオンで使ったコマンドをまとめました。

目次

Amazon CloudWatch Logs について

今回、波田野さんのお話を聞けませんでしたので、自分で公式ドキュメント、Blackbeltの資料などで調べた内容を簡単にまとめます。

CloudWatch Logs とは
  • AWSサービスおよび顧客システムのログの監視、保存、アクセスができる。
    • EC2インスタンスのログのモニタリングやCloudTrailのログに記録されたイベントをモニタリングし、アラーム作成することができる。
  • ログの保存期間を設定できる(デフォルト無制限)。
  • アーカイブをS3に保存できる。
CloudWatch Logsの概念
  • CloudWatch Logs はディレクトリ構造

    • ロググループ
      • 同じ設定(ログ保持、監視、アクセス制御)を適用する複数のログストリームで構成される。
    • ログストリーム
      • 同じリソースを共有する一連のログイベント。タイムスタンプ順にイベントを表示する。
    • ログイベント
      • モニタリングしているアプリケーションやリソースが記録したアクティビティレコード(イベント)
  • メトリックスフィルタ

    • 取り込まれたログイベントから特定の文字列でフィルタリングすることができる。
    • フィルタリングデータは、CloudWatch メトリックスのデータポイントに記録される。
      • 特定の条件でアラートを出すことなどができる。

今回の手順

今回のハンズオン手順は以下を参照ください。

prototype-handson-cli.s3-website-ap-northeast-1.amazonaws.com

コマンド

1.ロググループの作成

まずはロググループを作成します。

作成するロググループ名--log-group-nameを指定して、logs create-log-groupを実行します。

aws logs create-log-group --log-group-name <ロググループ名>

作成したロググループは、logs describe-log-groups で確認します。 - ロググループ名--log-group-name-prefix と抽出したいグループの要素--query 'logGroups[].logGroupName'を指定してテキスト表示--output textします。

aws describe-log-groups --log-group-name-prefix <ロググループ名> \
--query 'logGroups[].logGroupName' \
--output text
2.CloudWatch Logsロググループの保持期間の設定

ロググループ名--log-group-nameとログ保持期間--retention-in-daysを指定し、logs put-retention-policyを実行します。

aws logs put-retention-policy --log-group-name <ロググループ名> --retention-in-days <ログ保持期間(数字)>
  • ロググループ名--log-group-nameとログ保持期間--retention-in-daysを指定し、logs describe-log-groups でログ保持期間を確認します。
aws describe-log-groups --log-group-name-prefix <ロググループ名> \
--query 'logGroups[].retentionInDays' \
--output text
3.CloudWatch Logsログストリームの作成

ロググループを作成したら、その配下に所属されるログストリームを作成します。

ロググループ名--log-group-nameと ログストリーム名--log-stream-nameを指定したら、logs create-log-streamを実行します。

aws logs create-log-stream --log-group-name <ロググループ名> --log-stream-name <ログストリーム名>

ログストリームを作成するロググループ --log-group-name とログストリーム名--log-stream-name-prefixを指定し、logs describe-log-streamsで存在確認をします。

aws logs describe-log-streams --log-group-name <ロググループ名> --log-stream-name-prefix <ログストリーム名> \
--query logStreams[].logStreamName --output text
4.CloudWatch Logsログイベントの作成

ログストリーム配下にログイベントの作成をします。

ログイベント作成先のログストリーム名--log-stream-name、ログイベント名--log-eventsを指定して、logs put-log-eventsを実行します。

aws logs put-log-events  --log-group-name <ロググループ名> \
--log-stream-name <ログストリーム名>
--log-events <ログイベント名>

ログイベントが作成されたか確認します。

ログイベントを取得するロググループ --log-group-name とログストリーム名--log-stream-name、取得ログイベント数--limitを指定して、logs get-log-eventsを実行します。

aws logs get-log-events \
  --log-group-name <ロググループ名> \
  --log-stream-name <ログストリーム名> \
  --query 'length(events[])'
5.CloudWatch Logsログイベントの取得

ログイベントを取得するロググループ --log-group-name とログストリーム名--log-stream-name、取得ログイベント数--limitを指定して、logs get-log-eventsを実行します。

aws logs get-log-events --log-group-name <ロググループ名> \
--log-stream-name <ログストリーム名> \
--limit <取得ログイベント数>
6.ログイベントの追加

ログイベントを追加する場合は、ログイベントを追加するロググループ --log-group-name とログストリーム名--log-stream-name、 ログイベント名--log-events、アップロードシーケンストーク--sequence-tokenを指定して、logs put-log-eventsを実行します。

aws logs put-log-events \
  --log-group-name <ロググループ名> \
  --log-stream-name <ログストリーム名> \
  --log-events "<ログイベント名>" \
  --sequence-token <アップロードシーケンストークン>
7.ログストリームの削除

ここからは、後片付けのための削除コマンドになります。

削除するログストリームが所属するロググループ名 --log-group-name と削除するログストリーム名--log-stream-nameを指定して、logs delete-log-streamを実行します。

aws logs delete-log-stream --log-group-name <ロググループ名> 
--log-stream-name <ログストリーム名>
8.CloudWatch Logsロググループの保持期間の削除

ロググループ名--log-group-nameを指定し、logs delete-retention-policyを実行します。

aws logs delete-retention-policy --log-group-name <ロググループ名>
9.ロググループの削除

ロググループ名--log-group-nameを指定し、logs delete-log-groupを実行します。

aws logs delete-log-group --log-group-name <ロググループ名>

感想

CloudWatch Logsはディレクトリ構造になっていることは、GUIでポチポチやっているとあまり実感できませんでした。 でも、今回CLIで動かしたことで、ロググループ名、ログストリーム名、ログイベント名をオプションに指定する必要があるので、階層構造を意識できた実感がしました。 ハンズオンをやる前は、今回は今までのIAMやEC2に比べると量が少なめかな?と思いましたが、CloudWatch Logsのディレクトリ構造をはっきりと実感できて大収穫でした。

今回、勉強会には参加できませんでしたので、手順書とAWS公式ドキュメントを見ながらハンズオンしました。 サービスの概要、手順書の意味を調べながら手を動かす。その方が理解が深まるのではないかと思いました。 今までもやっていなかったわけではないですが、意識は薄かったかなと反省しました。 コマンド操作を楽しむのも良いですが、ちゃんとサービスの意味や挙動を知ることが大事ですね。

また、最近は復習するときは、主要コマンド操作はコピペではなく、必ずキーボード打って体でも覚えるようにしています。 これも大事なことだと思いながら取り組んでいます。

次回はLambda入門。Lambdaは以前の勉強会でも少し触れましたが、LambdaをCLIで触れるのは興味があります。 これまでで一番楽しみかもしれません!!

jawsug-cli.connpass.com

ssmonline #2 参加レポート

6/30(火)、ssmonline #2 に参加しましたので、レポートを書きます。

今回は、沢渡さん、波田野さん、國武さんの3人のパネルディスカッション形式で進行しました。國武さんのツイートがきっかけで今回の座談会が実現したとのこと。久々のささみがガチ運用会でとても楽しく参加できましたが、身につまされる思いで拝聴していました。

目次

イベントページ

ssmjp.connpass.com

Togetter

togetter.com

概要

Togetterに書いてあることと被る部分もありますが、自分がメモしたことをまとめます。

パネルディスカッション"運用の価値
  • 運用とは?

    • サービスを継続的にデリバリすること
    • 運用業務の本質は「事業継続性」の実現
    • 「事業継続」に貢献しているかどうかで「運用」の価値が決まる
  • 運用できちんとお金を貰えているか?

    • 商用であれば、営業がお客様からお金をいただけているか
    • 社内であれば、ちゃんと予算を確保できているか
      • サービス保守の名目でお金をいただけるよう、営業担当者に意識させなければならない
    • コロナ禍でITが追い風になっている。ITにお金がかかるところをメニュー化して投資できるかがカギとなる
  • 運用のサービスカタログを作成する

    • 社外、社内どちらにおいてもコミュニケーションの基盤となる
    • 日本人は仕事を曖昧にして自分しかできないようにする(属人化)。
      • それが力の源泉になっているところもあるが、可視化して周りに理解してもらう必要がある
  • 運用の価値を上げ、予算を確保するためには、上司をデフォルトゲートウェイにするのも手

    • 言われたことばかりやっているだけでなく、上司をコントロールしてWinWinの関係を目指す。
    • 社内の場合、顧客は予算を確保してくれる人。つまり上司となる。
  • サービスカタログは組織のミッション。作業カタログは組織のカード。

    • 自分たちがのてんわやんわしている作業を整理するために、作業カタログが必要
    • 作業カタログの棚卸も必要。誰もがなくした方がよいと思う業務は、積極的に終わらせた方がよい。
      • サービスのライフサイクルを意識する。
  • 失敗は体力があるうちにしておくこと

    • 成功だけでなく、失敗をして良い経験を得ることが大事。
パネルディスカッション"システムの作り逃げ"
  • 「作り逃げ」=「未来の時間泥棒」

    • 雑に作り逃げされたシステムを押し付けられて現場が炎上する
    • 何も考えずにコピペしたり設計書を流用することで、 運用できない、引き継げない問題に直面する。
    • 個性的なオレオレコードでマウンティングすると、職場の雰囲気も悪くなる。
      • 結果、未来の時間泥棒となる。
  • サービスレベルに対してどのように業務設計するかを考える。

    • SaaSありき、道具ありきでは考えない。
    • どんな道具(SaaSなど)があっても、業務設計ができなければならない。
  • 組織を自分の力で変えられるかどうか

    • 変えられるならば、自分の経験値アップになるので良い。
    • 自分一人の力で変えられないならば「次行ってみよ~!」の考えで別の場所に行って、優秀な人たちと仕事した方が楽しい。
    • ただ、今いる場所で得られるものを見込んでいるならば、頑張るべき。
  • インフラ、運用保守をやりたがる人がいない問題

    • 開発は失敗があってもリカバリできることがあるが、運用保守はミスをすると責められる
    • リスペクトされない
      • 運用保守は事業継続。開発する人だけいれば事業継続できるのかを、理詰めで話す必要がある。
  • 運用現場に人を育てる機能が求められている。

    • 知見をドキュメントで非同期に渡せるとよい。
    • ドキュメント作成をボランティアにするのではなく、人事評価制度としてあるべき。
      • ドキュメントを作るのは、自分の教育にもなる。ドキュメントを書いた人が育つ。
      • ドキュメントがあれば読んで勝手に育つ人もいる。
    • 学習・成長戦略を言葉にすること。
    • テンション上がる職場でないと、スキルは上がらない。辛さの中に楽しみがあるのは良いが、辛さのない仕事はない。
  • エンジニアは業務設計ができる人に

    • 運用でビジネスへの貢献を。
    • そのために上司も顧客も教育をすることが仕事となる。
      • リテラシーを上げて仕事をしやすくするために。
      • 顧客の教育についてはAWS社が良い例。
    • 最終的には、サービスカタログが大事
    • マーケティングをできるエンジニアが強い。
    • マーケティングブランディングで組織の価値をどう上げていくかを考える。
    • ロジカルに仕事をできる人と増やさないとITは動かない。
    • 視野を広げて仕事相手のことを考えて自分たちの仕事を見つめなおすこと。
      • 何が自分たちの業務のサービスカタログかが見えてくる。
      • 最終的にはサービスカタログが重要。

感想とまとめ

最初に書いた通り、とても楽しく参加することができましたが、身につまされる思いでいっぱいでした。 「事業継続性」を十分に意識した仕事ができておらず、自分の仕事が結果的に他者の時間泥棒になっているんじゃないか?と思いました。 ビジネスへの貢献を継続させるためには自分一人の考えや力だけでなく、関係者全員で考えられるようにしたいと思いました。 ツールを導入、新規の業務、物やサービスの販売や推進、それらありきで考えるのはあまり良くない。どんな組織にしたいのか、他者にどうなってほしいのか、それを実現できることかと他者に与える影響(良いことも悪いことも)をよく考えてから始められるようになりたいです。それができないと、ビジネスに十分に貢献できないし関係者に対して時間泥棒になってしまいます。改めて気づかされて、最近モヤっとしていた自分の仕事への向き合い方を見直すきっかけになりました。

まずは仕事の関係者全員へのリスペクトを忘れないこと、サービスカタログ化を常に意識しながら仕事できるようになりたいです。

それにしても、ささみに登壇する方は皆さん熱量があっていつも刺激を貰えます。久々の参加となりましたが、楽しい時を過ごせました。しばらくはオンラインになるかもしれませんが、次月以降もできる限り参加したいです。また登壇もしたいので、早く話すことを決めて登壇申込しよう!

JAWS-UG CLI専門支部 #160R IAM基礎(IAMポリシー) 参加レポート

6/25(木)、JAWS-UG CLI専門支部 #160R IAM基礎(IAMポリシー)に参加しました。今回もハンズオンの感想と学んだコマンドについて書きます。

目次

イベントページ

jawsug-cli.connpass.com

ハンズオンでやったこと

以下の通りです。事前準備として、Cloud9上にハンズオン環境を構築しました。 ハンズオンでは、Cloud9のターミナルでコマンド実行しました。

IAMロールとIAMポリシについて

IAMロールとは
  • IAMはSTSと密接に関係しており、STSが裏側で動いている。
  • IAMは公開されているAPIのほぼ全アクションを制御できる。
  • AWSサービスはAPIの集合体
    • AWSはすべての機能をAPIで提供している
  • IAMを知ることはAWSAPIアクションとの付き合い方を知ること

    • IAMを分からなければAWSのことをわかっていない
  • IAMロールはAWSリソース同士をつなぐもの

    • 認証情報が見た目上不要。ただし、STSが裏で動いており、期限付きのトークンが発生しているため、実際に認証が不要なわけではない。
      • ユーザが意識しなくても良いだけ。
  • リスクがIAMユーザ数に比例しやすい

    • リスク = IAMユーザ数 * ポリシの強さ
IAMポリシ
  • 管理ポリシ

    • カスタマー管理ポリシ
      • 利用者が作成して管理するポリシ
      • ポリシバージョンを保有
    • AWS管理ポリシ
      • AWS側にて管理するポリシ
      • そのためデフォルトしか使えないが常に最新版を使える
  • ユーザ、グループ、ロールにインラインポリシが作られる

    • インラインポリシとカスタマー管理ポリシにIAMポリシドキュメントが配信される
    • インラインポリシは個別に更新する(CLIと相性が良いのはこちら?)
    • インラインポリシは共有利用しない
      • バージョン管理をIAMの外部でやる
  • IAMポリシドキュメント

    • 基本はアクションとリソースの組み合わせ
    • リソースにはARNを使う
    • Effectの優先順位
      • 優先順位1:明示的な拒否
      • 優先順位2:明示的な許可
      • 優先順位3:デフォルト暗黙の拒否

感想

先に今回の感想を書きます。

前回と今回のハンズオンを通して、IAMに対する理解が深まったような気がします。 インラインポリシについては、今回のハンズオンで、ユーザごとグループごと個別に付与するポリシであることをようやく認識しました(合ってますかね??)。 正直SAAやプラクティショナーの勉強の時は、ちゃんと理解していなかったです。今思うと、良く受かったもんだ…

また、今回ポリシドキュメントは事前に準備されたもののため、何が書かれているかの理解は不十分だと思います。 今回は追いついていませんが、ポリシドキュメントに書かれていることの意味(優先順位、制御するサービスなど)、記述方法も深掘りしたいです。 JMESPathについても、ハンズオンのコマンドで返される結果は何となくわかりますが、どう書けば何をフィルタ出来るのかは理解不十分です。 文法、活用方法をもっと深堀りしたくなりました。チュートリアル読みながら、地道に勉強していくしかないですね(汗)

事前作業・ハンズオン手順

こちらを参照してください。

ハンズオンで学んだコマンド

1.IAMポリシーの作成
  • IAMポリシの作成には、iam create-policyコマンドを実行します。
    • --policy-name で作成するポリシ名を指定します。
    • --policy-documentであらかじめ作成したポリシドキュメント(ポリシ設定を記述したファイル)を指定します。
aws iam create-policy \
  --policy-name ${IAM_POLICY_NAME} \
  --policy-document file://${FILE_IAM_POLICY_DOC}
  • IAMポリシを表示させるためには、iam list-policies コマンドを実行します。
    • --scopeAWS管理ポリシ(AWS)を表示させるか、顧客管理ポリシ(Local)を表示させるか指定します。
    • --max-itemsでコマンドの出力で返すアイテムの総数を指定します。
    • --queryで、Policies JSON 内のPolicyNameが変数${IAM_POLICY_NAME}と等しいPolicyNameを返し、それに合致するものをテキスト形式で表示します。
aws iam list-policies \
  --scope Local \
  --max-items 1000 \
  --query "Policies[?PolicyName == \`${IAM_POLICY_NAME}\`].PolicyName" \
  --output text
2. IAMグループのポリシアタッチ
  • iam attach-group-policyでIAMグループにポリシをアタッチします。
    • --group-name でポリシをアタッチするグループ名を指定します。
    • --policy-arnでアタッチするポリシのARN(Amazon Resource Name)を指定します。
aws iam attach-group-policy \
  --group-name ${IAM_GROUP_NAME} \
  --policy-arn ${IAM_POLICY_ARN}
  • グループに指定のポリシがアタッチされたことをiam list-attached-group-policiesで確認します。
    • --group-name でグループ名を指定します。
    • --queryでアタッチしたポリシ名を抽出し、それに合致するものがあればテキスト形式で表示します。
aws iam list-attached-group-policies \
  --group-name ${IAM_GROUP_NAME} \
  --query "AttachedPolicies[?PolicyName == \`${IAM_POLICY_NAME}\`].PolicyName" \
  --output text
3.IAMポリシーバージョンの作成
  • iam create-policy-versionで新しいバージョンを作成します。
    • --policy-arn で新しいバージョンを作成するポリシのARNを指定します。
    • --policy-document であらかじめ作成したポリシドキュメントを指定します。
aws iam create-policy-version \
  --policy-arn ${IAM_POLICY_ARN} \
  --policy-document file://${FILE_IAM_POLICY_DOC}
  • iam list-policy-versionsで新しいバージョンが作成されたか確認します。
    • --policy-arn で新しいバージョンを作成したポリシのARNを指定します。
aws iam list-policy-versions \
  --policy-arn ${IAM_POLICY_ARN} \
  --query "max_by(Versions[], &CreateDate).VersionId" \
  --output text
4. IAMポリシーのデフォルトバージョン変更

新しいバージョンを作成しただけではデフォルトバージョンにはなりません。 以下のコマンドでデフォルトバージョンに指定する必要があります。

  • iam set-default-policy-versionでデフォルトポリシーバージョンに変更します。
    • --policy-arn でポリシのARNを指定します。
    • --version-idでバージョンIDを指定します。
aws iam set-default-policy-version \
  --policy-arn ${IAM_POLICY_ARN} \
  --version-id ${IAM_POLICY_VERSION_ID}
  • iam list-policy-versionsでポリシのバージョンを確認します。
    • --policy-arn でポリシのARNを指定します。
    • Versions JSON でデフォルトバージョンがtrueになっているバージョンのIDを抽出し、テキスト形式で表示します。
aws iam list-policy-versions \
  --policy-arn ${IAM_POLICY_ARN} \
  --query "Versions[?IsDefaultVersion == \`true\` ].VersionId" \
  --output text
5.IAMポリシーバージョンの削除

IAMポリシの古いバージョンを削除します。

  • iam delete-policy-versionでIAMポリシのバージョンを削除します。
    • --policy-arnでバージョンを削除するポリシを指定します。
    • --version-idで削除するポリシのバージョンを指定します(v1 など)。
aws iam delete-policy-version \
  --policy-arn ${IAM_POLICY_ARN} \
  --version-id ${IAM_POLICY_VERSION_ID}
6.IAMグループのポリシーデタッチ
  • iam detach-group-policyでIAMグループからポリシをデタッチします。
    • --group-nameでポリシデタッチするグループ名を指定します。
    • --policy-arnでデタッチするポリシのARNを指定します。
aws iam detach-group-policy \
  --group-name ${IAM_GROUP_NAME} \
  --policy-arn ${IAM_POLICY_ARN}
7.IAMポリシーの削除
  • iam delete-policyでポリシを削除します。
    • --policy-arnで削除するポリシのARNを指定します。
aws iam delete-policy \
  --policy-arn ${IAM_POLICY_ARN}
8.IAMグループのインラインポリシー作成
  • iam put-group-policyでインラインポリシを作成します。
aws iam put-group-policy \
  --group-name ${IAM_GROUP_NAME} \
  --policy-name ${IAM_GROUP_POLICY_NAME} \
  --policy-document file://${FILE_IAM_POLICY_DOC}
  • iam list-group-policiesでグループポリシが作成されたことを作成します。
    • --group-name でグループ名を指定します。
aws iam list-group-policies \
  --group-name ${IAM_GROUP_NAME}\
  --query "PolicyNames[?contains(@,\`${IAM_GROUP_POLICY_NAME}\`)]"\
  --output text
9.IAMグループのインラインポリシー削除
  • iam delete-group-policyでインライングループポリシを削除します。
    • --group-nameでインラインポリシを削除するグループ名を指定します。
    • --policy-nameでインラインポリシ名を指定します。
aws iam delete-group-policy \
  --group-name ${IAM_GROUP_NAME} \
  --policy-name ${IAM_GROUP_POLICY_NAME}
10.IAMユーザーのインラインポリシー作成
  • iam put-user-policyでIAMユーザにインラインポリシを作成します。
    • --user-nameでユーザ名を指定します。
    • --policy-nameでインラインポリシ名を指定します。
    • --policy-documentであらかじめ作成したポリシファイルを指定します。
aws iam put-user-policy \
  --user-name ${IAM_USER_NAME} \
  --policy-name ${IAM_USER_POLICY_NAME} \
  --policy-document file://${FILE_IAM_POLICY_DOC}
  • iam list-user-policiesでユーザにインラインポリシが作成されたことを確認します。
    • --user-nameでユーザ名を指定します。
    • PolicyNames JSON 内に変数${IAM_USER_POLICY_NAME}が含まれるポリシ名がある場合は、それをテキスト形式で表示します。
aws iam list-user-policies \
  --user-name ${IAM_USER_NAME}\
  --query "PolicyNames[?contains(@,\`${IAM_USER_POLICY_NAME}\`)]"\
  --output text
11.IAMユーザーのインラインポリシー削除
  • iam detele-user-policyでユーザのインラインポリシを削除します。
    • --user-nameでインラインポリシを削除するユーザ名を指定します。
    • --policy-nameでインラインポリシ名を指定します。
aws iam delete-user-policy \
  --user-name ${IAM_USER_NAME} \
  --policy-name ${IAM_USER_POLICY_NAME}
12.後始末

ハンズオン環境が不要になったら、ハンズオン手順の後始末以降の手順を実施します。

※前回の後片付けと実行するコマンドは同じなため、割愛します。

最後に

次回はIAMロールについてです。さらにIAMの理解、CLIへの理解を深めるために次回も参加します! 最後まで読んでいただき、ありがとうございました!

※次回のイベントページ

jawsug-cli.connpass.com

JAWS-UG CLI専門支部 #159R IAM入門 参加レポート

6/22(月)、JAWS-UG CLI専門支部 #159R IAM入門に参加しました。今回もハンズオンの感想と学んだコマンドについて書きます。

目次

イベントページ

jawsug-cli.connpass.com

ハンズオンでやったこと

以下の通りです。事前準備として、Cloud9上にハンズオン環境を構築しました。 ハンズオンでは、Cloud9のターミナルでコマンド実行しました。

IAMとは

  • IAMマネジメントコンソールレベルでは対になっている。
  • API単位ではIAMとSTSが密接な関係にある
  • AWSアカウントはメールアドレスに紐づいた親アカウント
    • 初期設定が終了したら封印して二度と使うことはないようにしておく
  • 昔はAWSアカウントですべてのリソースを操作していた。
  • 過大な権限による弊害を避けるためにIAMが生まれた
    • 適切な権限の分割が目的
    • 現行のバージョンは2012年10月
  • AWSを真に理解するとは

    • AWS APIの働きを理解すること
      • IAMを知ることは、AWSAPIアクションとの付き合い方を知ること
      • AWSの学習、設計、実装は、IAMにはじまりIAMに終わる
      • IAMが分からない人はAWSを分かっていない人
  • IAMのサービス概要

    • AWSの利用はAWSリソースのAPIを実行すること
    • 外部リソース、AWSリソース、利用者からのアクセスで何のサービスを制限するのかを定義するのがIAM
    • ユーザやグループは人とサービスをつなぐもの
    • ロールはAWSリソース同士をつなぐもの
  • ユーザ・グループとロールの認証上の違い

    • ユーザ・グループは利用者や外部リソースからの認証情報が必要
      • ユーザプロファイルとAPIアクセスキー
      • MFAによる保護
    • ロールはAWSリソースからの制御で認証情報が不要
      • (6/27追記)厳密には裏側でテンポラリークレデンシャルの生成と更新が自動でされている。
  • IAM設計における2つの戦略観点

    • 防御戦略
      • いかにクレデンシャルを抜かれないようにするか
      • クレデンシャルを悪用される状況が最も危険
      • これらをなるべく使わない
      • IAMロールをなるべく使う
        • EC2やCloud9を作業環境として使わないときは落とす
    • 権限戦略
      • ユーザは最低限&分割
      • 複数の場所で同一ユーザを使わない
      • 最小権限の原則(一番大事)
        • ポリシは使い捨て
        • 人とリソースの両面からポリシを考える
        • 小さなポリシを組み合わせて適用する
          • IAMポリシは1つの対象に対して10ポリシを適用できる
  • IAM設計上の戦術

    • クレデンシャルはMFAで保護する
    • アクセスキーは2つ作成できるので自動更新できるようにする
    • ポリシをリソースドリブンで作成する
    • AWSマネジメントポリシをなるべく使わない
      • リソースが*なのでザルすぎる

IAM設計上の戦略と戦術については、波田野さんの資料が紹介されていました。

www.opslab.jp

感想

今回はハンズオン前の解説がいつも以上に長いことから、AWSの中で一番重要なサービスであることを改めて思い知らされました。下手な設定をして泣きを見ないよういつも以上に真剣に取り組まねばと思いました。また、今回の復習ブログだけでなく、定期的に復習して忘れないようにしないと!と思いました。

ハンズオンで出てきたコマンドについて何となくやっていることは分かったと以前も書きましたが、 認証ファイルの作成部分は少し複雑なコマンドで、何をやっているのか理解するのに時間がかかりました。 LinuxのコマンドやJMESPathの記述について、まだまだコマンドやスクリプトの一つひとつの意味を深堀りできてないと思いました。 時間を作ってLinuxコマンドとJMESPathに特化した勉強もしたいと思いました。自分でもスクリプトを書けるようになりたい…

ハンズオンで学んだコマンド

事前作業・ハンズオン手順は、こちらを参照してください。

なお、ハンズオン概要としては、以下の通りです。構成図は、こちらを参照してください。

  • IAMグループの作成とポリシのアタッチ
  • IAMユーザの作成とグループへの追加
  • APIアクセスキーの作成
  • APIアクセスキーの更新
  • ログインプロファイルの作成・削除
1.IAMグループの作成
  • グループ名を指定してiam create-groupでIAMグループを作成します。
aws iam create-group \
  --group-name ${IAM_GROUP_NAME}
  • 作成したグループを、iam list-groupsで存在確認します。
aws iam list-groups \
  --query "Groups[?GroupName == \`${IAM_GROUP_NAME}\`].GroupName" \
  --output text
2.IAMグループのポリシーアタッチ
  • グループ名とIAMポリシのARNを指定し、ima attach-group-policyを実行してポリシをアタッチします。
aws iam attach-group-policy \
  --group-name ${IAM_GROUP_NAME} \
  --policy-arn ${IAM_POLICY_ARN}

※IAMポリシのARNはiam list-policiesで取得します。

IAM_POLICY_ARN=$( \
  aws iam list-policies \
    --scope AWS \
    --max-items 1000 \
    --query "Policies[?PolicyName==\`${IAM_POLICY_NAME}\`].Arn" \
    --output text \
) \
  && echo "${IAM_POLICY_ARN}"
  • 指定したグループに指定したIAMポリシがアタッチされていることを、iam list-attached-group-policiesで確認します。
aws iam list-attached-group-policies \
  --group-name ${IAM_GROUP_NAME} \
  --query "AttachedPolicies[?PolicyName == \`${IAM_POLICY_NAME}\`].PolicyName" \
  --output text
3.IAMユーザの作成
  • ユーザ名を指定し、iam create-userでIAMユーザを作成します。
aws iam create-user \
  --user-name ${IAM_USER_NAME}
  • 作成したIAMユーザが存在することをiam list-usersで確認します。
aws iam list-users \
  --query "Users[?UserName == \`${IAM_USER_NAME}\`].UserName" \
  --output text
4.IAMユーザのIAMグループへの追加
  • IAMユーザをどのIAMグループに追加したいか指定して、iam add-user-to-groupでグループ追加します。
aws iam add-user-to-group \
  --group-name ${IAM_GROUP_NAME} \
  --user-name ${IAM_USER_NAME}
  • 指定のIAMユーザがIAMグループに追加されているか、iam list-groups-for-userで確認します。
aws iam list-groups-for-user \
  --user-name ${IAM_USER_NAME} \
  --query "Groups[?GroupName==\`${IAM_GROUP_NAME}\`].GroupName" \
  --output text
5.APIアクセスキーの作成
  • 現在のアクセスキーの数を確認します。
COUNT_IAM_ACCESS_KEYS=$( \
  aws iam list-access-keys \
    --user-name ${IAM_USER_NAME} \
    --query 'length(AccessKeyMetadata[])' \
) \
  && echo ${COUNT_IAM_ACCESS_KEYS}
  • 変数FILE_ACCESS_KEYにアクセスキーを保存するファイルパスを格納します。
    • ${DIR_ACCESS_KEY} にファイルディレクトリを指定します。
    • ${IAM_USER_NAME}にIAMユーザ名を指定します。
FILE_ACCESS_KEY="${DIR_ACCESS_KEY}/${IAM_USER_NAME}-token-${COUNT_IAM_ACCESS_KEYS}.json" \
  && echo ${FILE_ACCESS_KEY}
  • アクセスキーを作成するユーザを指定して、iam create-access-keyを実行します。
    • 同時にアクセスキーを先に指定したファイルパス(FILE_ACCESS_KEY)に保存します。
aws iam create-access-key \
  --user-name ${IAM_USER_NAME} \
  > ${FILE_ACCESS_KEY} \
    && cat ${FILE_ACCESS_KEY}
  • IAMユーザにアクセスキーが作成されたことをiam list-acccess-keysで確認します。
aws iam list-access-keys \
  --user-name ${IAM_USER_NAME} \
  --query 'AccessKeyMetadata[].[join(``,[CreateDate,`,`,Status])]' \
  --output text
6.AWS認証ファイルの作成

ここでは、認証情報(~/.aws/creadentialsファイル)とデフォルトリージョンなど設定情報(~/.aws/config)を作成します。

  • ~/.aws/creadentialsファイルに追加するために、INIファイルを作成します。
    • ${IAM_USER_NAME}にIAMユーザ名を指定します。
    • ${FILE_USER_CREDENTIAL}にINIファイルのパスを指定します。
    • ${FILE_ACCESS_KEY}に5.で作成したjsonファイル(アクセスキーが格納されている)を指定します。
    • jsonファイルからアクセスキーとシークレットアクセスキーを抜き出し、INIファイルに追記します。
echo "[${IAM_USER_NAME}]" > ${FILE_USER_CREDENTIAL}

cat "${FILE_ACCESS_KEY}" \
  | jp.py 'AccessKey' \
  | sed '/[{}]/d' | sed 's/[\" ,]//g' | sed 's/:/=/' \
  | sed 's/AccessKeyId/aws_access_key_id/' \
  | sed 's/SecretAccessKey/aws_secret_access_key/' \
  | grep '^aws_' \
  >> ${FILE_USER_CREDENTIAL} \
    && cat ${FILE_USER_CREDENTIAL}
  • ~/.aws/configファイルに追加するために、config形式のファイルを作成します。
    • ${FILE_USER_CONFIG} にconfigファイルのパスを指定します。
    • ${REGION_AWS_CONFIG}にデフォルトリージョンを指定し、${FILE_USER_CONFIG}で指定したファイルに追記します。
echo "[profile ${IAM_USER_NAME}]" > ${FILE_USER_CONFIG} \
  && echo "region=${REGION_AWS_CONFIG}" >> ${FILE_USER_CONFIG} \
  && echo "" >> ${FILE_USER_CONFIG} \
  && cat ${FILE_USER_CONFIG}
  • INIファイルの内容を ~/.aws/credentials に追記します。
cat ${HOME}/environment/conf-handson-cli-iam/handson-cli-user.ini >> ~/.aws/credentials
  • configファイルの内容を ~/.aws/config に追記します。
cat ${HOME}/environment/conf-handson-cli-iam/handson-cli-user.config >> ~/.aws/config
7.IAMユーザーの動作確認
  • デフォルトリージョンとユーザを指定します
export AWS_DEFAULT_REGION='ap-northeast-1'
export AWS_DEFAULT_PROFILE='handson-cli-user'
  • cloud9 list-environmentsでCloud9上の環境情報を取得します。
aws cloud9 list-environments
8.APIアクセスキーの作成
  • 5.と同じ手順でAPIアクセスキーをもう一つ作成します。
9.最新ではないアクセスキーの無効化
  • アクセスキーの作成日付をiam list-access-keysで取得します。
ARRAY_DATE_ISO8601=$( \
  aws iam list-access-keys \
    --user-name ${IAM_USER_NAME} \
    --query 'AccessKeyMetadata[].CreateDate' \
    --output text \
) \
  && echo ${ARRAY_DATE_ISO8601}
  • unsetコマンドで変数ARRAY_DATETIME_UNIXを解除します。
unset ARRAY_DATETIME_UNIX
  • アクセスキーの作成日時をUNIX時間形式で取得します。
if [ $(uname) == 'Linux'  ]; then \
  for i in $(echo ${ARRAY_DATE_ISO8601} ); do \
    DATETIME_UNIX="$( date -d ${i} +%s )" \
    ARRAY_DATETIME_UNIX="${ARRAY_DATETIME_UNIX} ${DATETIME_UNIX}" \
  ;done \
else \
  for i in $(echo ${ARRAY_DATE_ISO8601} ); do \
    DATETIME_UNIX="$( date -u -jf %FT%TZ ${i} +%s )" \
    ARRAY_DATETIME_UNIX="${ARRAY_DATETIME_UNIX} ${DATETIME_UNIX}" \
  ;done \
fi

echo ${ARRAY_DATETIME_UNIX}
  • 作成日が古い方のUNIX時間形式を取得します。
DATETIME_UNIX=$( \
  echo ${ARRAY_DATETIME_UNIX} \
    | awk 'BEGIN{CONVFMT = "%.10d"; OFMT = "%.10d";};{
      num = int (split($0, arr_input, " "));
      current = 1;
      for (i = 1; i <= num; i++) {
        arr_output[current] = arr_input[1];
        for (j = 1; j <= num; j++) {
          if ( j <= num ) {
            if ( arr_input[j] != NULL && arr_output[current] > arr_input[j] ){
               arr_output[current] = int (arr_input[j]);
               del = j;
            }
          }
        }
        delete arr_input[del];
        current++;
      }
      print arr_output[1];
    }' \
) \
  && echo ${DATETIME_UNIX}
  • 取得したUNIX時間形式をISO8601形式に変換します。
if [ $(uname) == 'Linux'  ]; then \
    DATE_ISO8601=$( date -d @${DATETIME_UNIX} +%Y-%m-%dT%TZ ); \
else \
    DATE_ISO8601=$( date -u -r ${DATETIME_UNIX} +%FT%TZ ); \
fi

echo ${DATE_ISO8601}
  • 作成日が古いアクセスキーを取得します。
IAM_ACCESS_KEY_ID=$( \
  aws iam list-access-keys \
    --user-name ${IAM_USER_NAME} \
    --query "AccessKeyMetadata[?CreateDate == \`${DATE_ISO8601}\`].AccessKeyId" \
    --output text \
) \
  && echo ${IAM_ACCESS_KEY_ID}
  • ユーザ名とアクセスキーを指定し、iam update-access-keyで無効(inactive)にします。
aws iam update-access-key \
  --user-name ${IAM_USER_NAME} \
  --access-key-id ${IAM_ACCESS_KEY_ID} \
  --status Inactive
  • ユーザ名に紐づくアクセスキーの状態をiam list-access-keysで確認します。
aws iam list-access-keys \
  --user-name ${IAM_USER_NAME} \
  --query 'AccessKeyMetadata[].[join(``,[CreateDate,`,`,Status])]' \
  --output text
10.IAMログインプロファイルの作成
  • ユーザIDとパスワードを指定します。
IAM_USER_NAME='handson-cli-user'

※xxxxxxxxxにパスワードを指定します。

IAM_PASSWORD_NEW='xxxxxxxxx'
  • ユーザ名とパスワードを指定してima create-login-profileを実行します。
aws iam create-login-profile \
  --user-name ${IAM_USER_NAME} \
  --password "${IAM_PASSWORD_NEW}"
  • 指定したユーザ名にログインプロファイルがあるか、iam get-login-profileを実行して確認します。
aws iam get-login-profile \
  --user-name ${IAM_USER_NAME} \
  --query 'LoginProfile.UserName' \
  --output text
11.IAMログインプロファイルの削除
  • ログインプロファイルを削除するユーザ名を指定して、iam delete-login-profileを実行します。
aws iam delete-login-profile \
  --user-name ${IAM_USER_NAME}
12.後始末

ハンズオン環境が不要になったら、ハンズオン手順の後始末以降の手順を実施します。

後始末で実行したコマンドは以下の通りです。

APIアクセスキーの全削除
  • 登録されているアクセスキーをすべて取得します。
ARRAY_IAM_ACCESS_KEY_IDS=$( \
  aws iam list-access-keys \
    --user-name ${IAM_USER_NAME} \
    --query 'AccessKeyMetadata[].AccessKeyId' \
    --output text \
) \
  && echo ${ARRAY_IAM_ACCESS_KEY_IDS}
  • ユーザ名とアクセスキーを指定してiam delete-access-keyで削除します。
    • すべて削除する場合は、for文でアクセスキーの数の回数実行します。
for i in ${ARRAY_IAM_ACCESS_KEY_IDS}; do
  aws iam delete-access-key \
    --user-name ${IAM_USER_NAME} \
    --access-key-id ${i}
done
  • ユーザ名に紐づくアクセスキーがないことをiam list-access-keysで確認します。
aws iam list-access-keys \
  --user-name ${IAM_USER_NAME} \
  --query "AccessKeyMetadata[].UserName" \
  --output text
AWS認証ファイルの削除
  • viなどエディタで .aws/credentials を開き、今回作成したIAMユーザに関する行のみを削除します。
[handson-cli-user]
aws_access_key_id=
aws_secret_access_key=
  • 同様にviなどで .aws/config を開き、今回作成したIAMユーザに関する行のみを削除します。
[profile handson-cli-user]
region=ap-northeast-1
IAMユーザのIAMグループからの削除
  • グループから削除させるユーザを指定してiam remove-user-from-groupを実行します。
aws iam remove-user-from-group \
  --group-name ${IAM_GROUP_NAME} \
  --user-name ${IAM_USER_NAME}
IAMユーザーの削除
  • 削除するIAMユーザを指定してiam delete-userを実行します。
aws iam delete-user \
  --user-name ${IAM_USER_NAME}
IAMグループのポリシーデタッチ
  • デタッチするIAMロールのARNとIAMグループを指定して、iam detach-group-policyを実行します。
aws iam detach-group-policy \
  --group-name ${IAM_GROUP_NAME} \
  --policy-arn ${IAM_POLICY_ARN}
IAMグループの削除
  • 削除するIAMグループ名を指定してiam delete-groupを実行します。
aws iam delete-group \
  --group-name ${IAM_GROUP_NAME}
Cloud9用ロールからのポリシーのデタッチ
  • IAMロール"handson-cloud9-environment-role"からIAMポリシー"IAMFullAccess"をデタッチします。
    • IAMフルアクセスを残したままにしておくと、不正に権限設定されてしまう恐れがあります。 ※GUIからデタッチします。手順は割愛します。

最後に

次回(今日)はこの続きでIAMポリシに特化したところになります。 次回もしっかりついていき理解を深めたいです。

※次回のイベントページ

jawsug-cli.connpass.com

Webエンジニア勉強会inVR 第3回 参加レポート

6/21(日)、Webエンジニア勉強会inVR 第3回に参加しましたので、レポートを書きます。 前回は 「リモートワーク」「外出自粛中の過ごし方」、今回は「生産性アップの推しツール」ということで、 在宅勤務が続く今聞きたい話題が続いたため、今回もとても楽しく参加することができました。

目次

イベントページ

study-in-virtual.connpass.com

LT内容

身近なツールを正しく使う ういろうさん
資料

www.nyamucoro.com

概要
  • ツールを選ぶのは自分の内情(業務の頻度や時間)や予算で変わる
    • いろんな視点が大事
  • 業務で一番多い時間はコミュニケーション

    • 図があるとないでは伝わり方が違う
    • 口だけで伝わるものは少ない
    • 大切なことは声だけでは伝わらない
      • メモを用意できる場合は用意しよう
        • 対面の場合はホワイトボードノート
        • 間接の場合はSlack
    • まとめを箇条書きにして渡す
      • 事前にアジェンダなどを準備していないならば、チャットに今話していることを書いて流す
  • Marp

    • マークダウンでスライド作成が可能
      • Visual Studio Code のアドオンでもWebからのインストールからでも利用可能
時間を意識する推しツールたち kulunaさん
資料

speakerdeck.com

概要
  • リモートワークが増えて

    • 通勤時間がなくなった
    • 会話は減った
    • 家での誘惑が多いので気が散る
    • 生産性を意識するようになった
  • 時間、めっちゃ大事!

    • 通勤時間を別のことに使えたり、昼寝に使えたり・・・
  • 時間を意識して生産性を高めるための推しツール 1.Focus To-Do 2.頭痛~る 3.Meeting is Money

  • Focus To-Do

    • iOSAndroid、PCアプリ
    • ポモドーロタイマー
      • 25分集中して5分休むを繰り返す。
      • どれだけ集中できていたか後で振り返れる
      • 5分は絶対休む。この5分の休憩の大事さに気付いてほしい
        • 意外と疲れていることがわかる
        • おすすめは数歩歩く
        • 5分間は誘惑に負けてもイイなど自分のルールを作る
  • 頭痛~る

    • iOSAndroid、PCアプリ
    • 気圧の変化によって頭痛を感じる人のためのアプリ
      • 頭痛が起きるかもしれない時刻を予測する
      • 頭を使うタスクや重要タスクを事前に終わらせるよう調整できる
        • 計画的に頭痛を迎えよう!
  • Meeting is Money

    • 会議に使った時間を算出
      • 時給換算してくれるので、時間の大切さがわかる

meeting-is-money.web.app

Slackを中心に世界はまわっている jiyuujinさん
資料

webneko.dev

概要
  • 情報の仕入れで日々やっていること

    • Twitterからの情報収集は雑多になるから使っていない
    • はてなエントリーやnoteのRSSを利用する
    • Nuxt.jsで作って使っている管理画面上でチェックしている
      • 自主的に入力できるようにした
      • だんだんめんどくさくなってきて、GAS(Google Apps Script)を使った自動入力できるようにした
      • ダークモードにも対応した
  • IFTTTを使ってはてなエントリーのRSS情報を取得してSlackに通知

    • SlackからリアクションとったメッセージをSpreadsheetに取り込む
      • getPostというメソッドで受けたリアクションを取得する
      • /api/conversations.history(SlackのWebhook)をたたく
      • 年月に合わせてシート名を変更して管理している
      • 取得情報をフロントに合わせて成形している
      • Firestoreにもブログの情報を保管している
  • なぜNuxt.js?

    • Vue.jsが好き
    • サクっとPWAを作れて、すでに「規約」が存在
    • j-stylebookというプラグインを自作しており、そことの連携性を考えて使っている
  • 今後やりたいこと

    • みんなに読んでほしいけど、Firabase Authを使っているので障壁になっている
      • 見れるようにしたい
ノン・デザイナーズデザインツール おとべさん
資料

speakerdeck.com

概要
  • UIデザインツールFigma

    • アプリとかWebのデザインツール
    • アプリとかWebのプロトタイピング
    • デザイナーさんご用達ツール
    • 使いようによっては最強便利ツールに化ける!
    • ショートカット6個くらい使えれば簡単に使える
    • 基本無料で使える(課金プランもあるみたい)
  • 画像加工・編集

    • 画像に文字、線、図形、フィルタをめっちゃ簡単につけられる
    • 書き出しも超めっちゃ簡単
  • インフラ構成図の作成

    • 設計図や記事の挿絵に使うUIキットやテンプレートがある
    • AWSダイアグラムテンプレート(公式)もある
    • コピペして並べるだけなので簡単
  • SVGの調整

    • SVGとして書き出したい部分を選んでアウトライン化

-登壇資料の作成 - Figmaはプロトタイピングツール - 任意の順にページを再生できるので、スライドとして使える - Frameをならべて再生するだけ - 自由度が高いデザイン - ひな形を作ればスライドづくりは楽 - 雑に図で説明できる - 最低限が保証されないデザイン - アニメーションは難しい

全体の感想

今回は実践してみたいと思えるツールがたくさんあり、発見の多い勉強会でした。 早速、「Focus To-Do」と「Marp」を入れてみました! 渓流や海岸の音などを流すこともでき、夏を感じながら作業できるのはいいですね! このブログを書くのにFocus To-Doを使いましたが、25分は長いようであっという間でした。 仕事にも取り入れていこうと思います。

MarpはVSCodeのアドオンを入れてみました。Software Design 2019年11月号にMarpの記事載ってましたね。 買って読んでいたのになぜ実践しなかったのか… これからは書籍に書いてあることで気になることはとにかく何でもやってみようと思いました。 使い込むのはこれからですが、次に登壇するときはMarpでスライドを作ってみたいです!

前回に引き続き気づきを得られた勉強会で有意義な時間を過ごせました。

最後に

前回も書きましたが、自分も何か誰かに気付きのきっかけを見つけてもらえるような登壇をしたくなりました。 今年は技術ネタで登壇すると決めていてまだできてない・・・

もうすぐ今年が半分終わってしまうし、何か考えねば!(汗)

JAWS-UG CLI専門支部 #158R EC2基礎(AMI) 参加レポート

6/18(木)、JAWS-UG CLI専門支部 #158R EC2基礎(AMI) に参加しました。今回もハンズオンの感想と学んだコマンドについて書こうと思います。

目次

イベントページ

jawsug-cli.connpass.com

ハンズオンでやったこと

以下の通りです。事前準備として、Cloud9上にハンズオン環境を構築しました。 ハンズオンでは、Cloud9のターミナルでコマンド実行しました。

AMI(Amazon Machine Images)とは

  • Amazon マシンイメージ (AMI) には、インスタンスの起動に必要な情報が用意されている(公式ドキュメントより)。
  • インスタンスを起動するときは、AMI を指定する必要がある(公式ドキュメントより)。
  • AMIはEBSスナップショットに紐づいた形で登録される。
  • 登録を解除するときはAMIの削除だけでなく、EBSスナップショットも削除する。

感想

前回のEBSの時は出席できませんでしたが、それでもついていくことができてホッとしています(EBS回のハンズオンを後日実施してブログ書きます)。AMIでインスタンスを作成する手順を一つ一つ追うことができて、マネジメントコンソールでやってきたことを再確認しながら理解を深められて良かったです。

ハンズオンで学んだコマンド

事前作業・ハンズオン手順は、こちらを参照してください。

なお、ハンズオン概要としては、以下の通りです。構成図は、こちらを参照してください。

  • CloudformationでVPC作成
  • セキュリティグループにルール追加
  • EC2構築
  • CLIでブラウザアクセス
  • AMI作成
  • AMIからEC2構築
  • 後片付け
1.VPCの構築
  • Cloudformationテンプレートのダウンロードをします。
    • ${CLOUDFORMATION_TEMPLATE_URL} はダウンロード元URLを指定します。
    • ${FILE_CLOUDFORMATION_TEMPLATE} はテンプレート保存ファイル名(フルパス)を指定します。
curl ${CLOUDFORMATION_TEMPLATE_URL} \
  > ${FILE_CLOUDFORMATION_TEMPLATE}
  • cloudformation validate-templateでCloudFormationテンプレートが有効であることを確認します。
    • --tempate-body でテンプレート保存ファイル名(フルパス)を指定します。
aws cloudformation validate-template \
  --template-body file://${FILE_CLOUDFORMATION_TEMPLATE}
  • cloudformation create-stack でCloudformationスタックを作成します。
    • --stack-name でcloudformationスタック名を指定します。
    • --template-body でテンプレート保存ファイル名(フルパス)を指定します。
aws cloudformation create-stack \
  --stack-name ${CLOUDFORMATION_STACK_NAME} \
  --template-body file://${FILE_CLOUDFORMATION_TEMPLATE}
  • cloudformation list-stackでCloudformationスタックが作成されたことを確認します。
aws cloudformation list-stacks \
  --query "StackSummaries[? \
    StackName == \`${CLOUDFORMATION_STACK_NAME}\` \
      && StackStatus != \`DELETE_COMPLETE\` \
    ].StackName" \
  --output text
  • Cloudformationスタックがステータスが"CREATE_COMPLETE"になっていることを確認します。
CLOUDFORMATION_STACK_STATUS=$(\
  aws cloudformation list-stacks \
    --query "StackSummaries[? \
      StackName == \`${CLOUDFORMATION_STACK_NAME}\` \
        && StackStatus != \`DELETE_COMPLETE\` \
      ].StackStatus" \
    --output text \
) \
  && echo ${CLOUDFORMATION_STACK_STATUS}
2.セキュリティグループへのルール追加

※事前にユーザデータ作成がありますが、割愛します。

  • `ec2 describe-vpcs' でVPCタグ名よりVPC IDを取得します。
EC2_VPC_ID=$( \
  aws ec2 describe-vpcs \
    --filters Name=tag:Name,Values=${EC2_VPC_TAG_NAME}  \
    --query 'Vpcs[].VpcId' \
    --output text \
) \
  && echo ${EC2_VPC_ID}
  • ec2 describe-security-groupsでVPCIDとセキュリティグループ名よりセキュリティグループIDを取得します。
EC2_SECURITY_GROUP_ID=$( \
  aws ec2 describe-security-groups \
    --filter Name=vpc-id,Values=${EC2_VPC_ID} \
      Name=group-name,Values=${EC2_SECURITY_GROUP_NAME} \
    --query "SecurityGroups[].GroupId" \
    --output text \
) \
  && echo ${EC2_SECURITY_GROUP_ID}
  • ルール追加するセキュリティグループID、ルールに追加するプロトコルTCP/UDP)、ポート番号、CIDRを指定して、ec2 authiorize-security-group-ingress を実行します。
aws ec2 authorize-security-group-ingress \
  --group-id ${EC2_SECURITY_GROUP_ID} \
  --protocol ${EC2_SECURITY_GROUP_PROTOCOL} \
  --port ${EC2_SECURITY_GROUP_PORT} \
  --cidr ${EC2_SECURITY_GROUP_CIDR}
  • 追加したルールが存在することを確認します。
aws ec2 describe-security-groups \
  --filter Name=vpc-id,Values=${EC2_VPC_ID} \
    Name=group-name,Values=${EC2_SECURITY_GROUP_NAME} \
    Name=ip-permission.protocol,Values=${EC2_SECURITY_GROUP_PROTOCOL} \
    Name=ip-permission.to-port,Values=${EC2_SECURITY_GROUP_PORT} \
    Name=ip-permission.cidr,Values=${EC2_SECURITY_GROUP_CIDR} \
  --query "SecurityGroups[].IpPermissions[?IpProtocol == \`${EC2_SECURITY_GROUP_PROTOCOL}\` \
    && ToPort == \`${EC2_SECURITY_GROUP_PORT}\` \
    && IpRanges[?CidrIp == \`${EC2_SECURITY_GROUP_CIDR}\`]].IpRanges[][].CidrIp" \
  --output text
3.EC2インスタンスの起動
  • イメージID、インスタンスタイプ、セキュリティグループ、タグキーと値、サブネットID、ユーザデータファイルを指定して、ec2 run-instancesを実行します。
aws ec2 run-instances \
  --image-id ${EC2_IMAGE_ID} \
  --instance-type ${EC2_INSTANCE_TYPE} \
  --security-group-ids ${ARRAY_EC2_SECURITY_GROUP_IDS} \
  --tag-specifications ${STRING_TAG_CONF} \
  --subnet-id ${EC2_SUBNET_ID} \
  --user-data file://${FILE_USER_DATA}
4.EC2インスタンスへのCLIブラウザアクセス

インスタンスID取得

ARRAY_EC2_INSTANCE_IDS=$( \
  aws ec2 describe-instances \
    --filters Name=tag-key,Values=Name \
              Name=tag-value,Values=${EC2_INSTANCE_TAG_NAME} \
    --query Reservations[].Instances[].InstanceId \
    --output text \
) \
  && echo ${ARRAY_EC2_INSTANCE_IDS}

グローバルIPアドレス取得

EC2_PUBLIC_IP=$( \
  aws ec2 describe-instances \
    --filters Name=tag-key,Values=Name \
              Name=tag-value,Values=${EC2_INSTANCE_TAG_NAME} \
    --instance-ids ${ARRAY_EC2_INSTANCE_IDS} \
    --query "Reservations[].Instances[].PublicIpAddress" \
    --output text \
) \
  && echo ${EC2_PUBLIC_IP}
curl ${CURL_TARGET_URL}
curl -LI -Ss \
  -o /dev/null \
  -w '%{http_code}\n' \
  ${CURL_TARGET_URL}
5.AMIの作成
  • インスタンスID、マシンイメージ名、AMIの説明を指定して、ec2 create-imageを実行します。
aws ec2 create-image \
  --instance-id ${EC2_INSTANCE_ID} \
  --name ${EC2_MACHINE_IMAGE_NAME} \
  --description "${EC2_MACHINE_IMAGE_DESCRIPTION}"
  • describe-images で作成したAMIイメージが存在することを確認します。
aws ec2 describe-images \
  --filter "Name=name, Values=${EC2_MACHINE_IMAGE_NAME}" \
  --query 'Images[].Name' \
  --output text
  • 作成したAMIがavailableであることを確認します。
EC2_MACHINE_IMAGE_STATE=$( \
  aws ec2 describe-images \
    --filters Name=name,Values="${EC2_MACHINE_IMAGE_NAME}" \
    --query "Images[?Name == \`${EC2_MACHINE_IMAGE_NAME}\`].State" \
    --output text \
) \
  && echo ${EC2_MACHINE_IMAGE_STATE}
6.EC2インスタンスの終了

AMIを作成したEC2インスタンスを終了させます。

aws ec2 terminate-instances \
  --instance-ids ${ARRAY_EC2_INSTANCE_IDS}
  • 削除したインスタンスが、ステータス"running"で存在していないことを確認します。
aws ec2 describe-instances \
  --filters Name=tag-key,Values=Name \
            Name=tag-value,Values=${EC2_INSTANCE_TAG_NAME} \
            Name=instance-state-name,Values=running \
  --query Reservations[].Instances[].Tags[].Value \
  --output text
7.EC2インスタンス(AMI利用)の構築
  • 作成したAMI、インスタンスタイプ、セキュリティグループ、タグキーと値、サブネットIDを指定し、ec2 run-instances を実行します。
    • --associate-public-ip-address でパブリックIPアドレスが割り振られるよう指定します。
aws ec2 run-instances \
  --image-id ${EC2_IMAGE_ID} \
  --instance-type ${EC2_INSTANCE_TYPE} \
  --security-group-ids ${ARRAY_EC2_SECURITY_GROUP_IDS} \
  --tag-specifications ${STRING_TAG_CONF} \
  --subnet-id ${EC2_SUBNET_ID} \
  --associate-public-ip-address
  • 作成したEC2のインスタンス名が、ステータス"running"で存在することを確認します。
aws ec2 describe-instances \
  --filters Name=tag-key,Values=Name \
            Name=tag-value,Values=${EC2_INSTANCE_TAG_NAME} \
            Name=instance-state-name,Values=running \
  --query Reservations[].Instances[].Tags[].Value \
  --output text
  • [4.EC2インスタンスへのCLIブラウザアクセス]と同じ要領でCLIブラウザアクセスを実行します。
    • 正常にコンテンツにアクセスでき、ステータスコード200が返ってくることを確認します。
8.後始末

ハンズオン環境が不要になったら、ハンズオン手順の後始末以降の手順を実施します。

今回は後始末で実行したコマンドも書きます。

EC2インスタンスの終了
aws ec2 terminate-instances \
  --instance-ids ${ARRAY_EC2_INSTANCE_IDS}
セキュリティグループのIngressルール削除
  • 削除するセキュリティグループのグループID、削除するルール(プロトコル、ポート、CIDR)を指定して、ec2 revoke-security-group-ingress でルールの削除をします。
aws ec2 revoke-security-group-ingress \
  --group-id ${EC2_SECURITY_GROUP_ID} \
  --protocol ${EC2_SECURITY_GROUP_PROTOCOL} \
  --port ${EC2_SECURITY_GROUP_PORT} \
  --cidr ${EC2_SECURITY_GROUP_CIDR}
AMIの削除
  • イメージIDを指定してec2 deregister-imageを実行して、AMIを削除します。
aws ec2 deregister-image \
  --image-id ${EC2_MACHINE_IMAGE_ID}
  • スナップショットIDを指定してec2 delete-snapshotを実行して、EBSスナップショットを削除します。
aws ec2 delete-snapshot \
  --snapshot-id ${EC2_SNAPSHOT_ID}

※スナップショットIDは、AWSIDとマシンイメージを指定してec2 describe-snapshotsを実行して取得します。

EC2_SNAPSHOT_ID=$( \
  aws ec2 describe-snapshots \
    --filters Name=owner-id,Values=${AWS_ID} \
    --query "Snapshots[?contains(Description, \`${EC2_MACHINE_IMAGE_ID}\`)].SnapshotId" \
    --output text \
) \
  && echo ${EC2_SNAPSHOT_ID}
Cloudformationスタックの削除
  • Cloudformationスタック名を指定してcloudformation delete-stackを実行して、スタックを削除します。
aws cloudformation delete-stack \
  --stack-name ${CLOUDFORMATION_STACK_NAME}

最後に

CLI専門支部のハンズオンに何度も参加して復習してきたことで、初めてみるコマンドでも何となく意味が分かってきました。CLIAWS触ることが楽しくなってきました! 次回からはIAMのハンズオンが4回続きます。IAMはSAAの勉強の時に理解したつもりでしたが、きっと理解できていないと思うので、じっくり勉強したいです!

※次回のイベントページ

jawsug-cli.connpass.com