omuronの備忘録

個人的な備忘録

(小ネタ) ECR リポジトリが存在しないときにワンライナーで作成する

CodeBuildECR に push しようとしたときにエラーが発生しました。

[Container] 2021/01/21 09:04:15 Running command docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***:$BRANCH_NAME
The push refers to repository [123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***]
20e0a6dcff7f: Preparing
029c325415ee: Waiting
name unknown: The repository with name '***' does not exist in the registry with id '123456789012'

[Container] 2021/01/21 02:04:15 Command did not exit successfully docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***:$BRANCH_NAME exit status 1
[Container] 2021/01/21 09:04:15 Phase complete: POST_BUILD State: FAILED
[Container] 2021/01/21 09:04:15 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***:$BRANCH_NAME. Reason: exit status 1

リポジトリが存在しないエラーが発生。

あれ? ECR リポジトリって事前作成必要だっけ?
なくても勝手に作ってくれなかったかな。
以前同じような実装したときに、ECR にリポジトを事前作成した記憶がまったくない。
とりあえずリポジトリが存在しない場合に作成するように変更することにしました。

CodeBuild の AssumeRole に権限を付与して

- ecr:DescribeRepositories
- ecr:CreateRepository

docker push 前に存在確認してなければ作成。

aws ecr describe-repositories --repository-names $REPOSITORY_NAME || aws ecr create-repository --repository-name $REPOSITORY_NAME
docker push $REPOSITORY_NAME:$BRANCH_NAME

docker push して、存在しなければ勝手に作ってくれると思ってたんですが...
これは私の勘違いだったんでしょうか?

「JAWS-UG朝会 #17」 #jawsug_asa 受講メモ

jawsug-asa.connpass.com

早起きは三文の徳の朝会です。
今日のラジオ体操は事前収録済みのムービーでした。

セッション① 年頭 JAWS-UG 振り返り

講師:アマゾン ウェブ サービス ジャパン株式会社 沼口 繁さん

www.slideshare.net

JAWS-UG

  • 歴史
    • 2006 米国 S3/EC2 サービス開始
    • 2009 AWS 日本法人
    • 2010/02/23 先行ユーザー100人を集めて第0回開催
    • 2011/03/02 東京リージョン開設
  • アイコン
    • 浜松支部が初めてカスタマイズロゴ作成
      • それから色々なサメの種類が増えていった
      • 海外受けが良いらしい
  • 3つの特徴
    • オフラインのIT勉強会と懇親会
    • アウトプットカルチャー
    • 自走するコミュニティー
  • 疎結合組織をつなげるいいリズム(間で re:Cap)
    • 06月 AWS Summi
    • 10月 JAWS FESTA
    • 12月 AWS re:Invent
    • 03月 JAWS DAYS
  • JAWS DAYS 2021
    • 2021/03/20 オンラインで開催!

re:Inventについてみんなで雑談

  • re:Invent 新機能で衝撃的だったもの
    • S3 が結果整合性から強い整合性になった
      • Googleは数年前からでておりどうやってできる?
      • 参考 Twitter
    • Lambda の1ms課金
    • mac instance
    • EBS GP3 安くなってパフォーマンス向上
    • CloudShell ユーザー権限で CLI そのまま動く(ので注意)
  • CloudShell を踏み台にできるようになる?
    • 使い捨てするコンテナで生活できるか?

所感

re:Invent で衝撃的だったものに「毎日 re:Capしてる亀田さん」というのがでてウケました。
個人的には、トラックで MacMini が大量に運ばれたのが笑撃的だった。

オンラインでの雑談は難しいですね。
先日参加した勉強会でも最後は話すことができましたが、ovice.in 使ったからこそというのがあったと思う。
オンラインで交流するのはまだまだ課題が多そうと感じました。

Tech-on MeetUp Online#04「いまエンタープライズのエンジニアが押さえておきたい認証認可、IDaaS」 #TechOn東京 受講メモ

techplay.jp

「さて、今夜お話しいただくのは認証・認可・IDaaSです。」
という内容で、実装は自力ですべきでないけど知っておきたい認証認可と IDaaS の話です。

「IDaaS を利用すべき理由とエンジニアが押さえておくべきポイント」

講師:日本電気株式会社・釜山 公徳さん

ノンテクニカルサイド

  • エンジニアもノンテクニカルサイドも抑える必要あり
  • NIST, ISO, OpenID Foundation, FIDO Alliance は抑える
    • NIST SP800-63, ISO/IEC 24760-1
  • 身元確認(自己申告、身分証)、当人確認(ID/Password, 生体認証)
    • 本人確認(身元+当人)
  • IDaaS 市場
  • 古くは SAML 認証
  • OpenID Foundation の参加で規格
    • OAuth2.0 : ID/Pass を使わなくてアプリ連携ができる
    • OpenID Coonect : OAuth2.0 を使ったユーザ認証、1つのプロトコルで多くの IdP とやり取り可能(利便性がある)
    • FAPI : Financial-grade API, 金融向けに利便性を高めた規格の策定中
    • CIBA : Client Initiated Backchannel Authentication, デカップルド・フロー
  • FIDO : モバイル生体認証、FIDO 仕様準拠がデファクト

テクニカルサイド

  • 認証: Authentication(AuthN)
    • リソースにアクセスする個人の身元確認
    • OpenID Coonect, SAML
  • 認可: Authorization(AuthZ)
    • 認証後アクセス権のレベルを確認するプロセス
    • OAuth
  • ID/Password が氾濫すると情報漏えいに繋がる
  • OneLogin ができること
    • アカウント管理
    • セキュリティ強化
      • アクセスコントロール
      • 多要素認証
        • 最も効果が高い
      • ログレポート
        • レポートを見るとASIS分析ができる
        • 課題解決できる、見ないと課題解決できない
  • Azure AD の認証方法
  • まとめ
    • ID 関連はビジネスサイドとテクニカルサイドの両サイド抑える
    • 複雑なのでガイドラインを活用

「Auth0とクラウドサービスを組み合わせて作るメディアコマースの開発事例」

講師:株式会社Serverless Operations 堀家 隆宏さん

IDaaS の採用の意味とメリット

  • 一昔前: DB にユーザー情報を保存して CRUD 操作
    • セキュリティ対策コスト, ユーザー管理コスト
    • 個人情報を扱う標準規格への準拠
  • これらを解決する昨今の IDaaS
    • セキュリティ、利便性、運用コスト
    • 一元管理して SAML で各種社内利用サービスへログイン
    • アプリ開発も IDaaS、OIDC/OAuth2.0 プロトコルが容易になる

Auth0

  • 認証認可の SaaS プラットフォーム
  • ソーシャルログインの導入が一瞬、GUI で設定するだけ
    • 自力実装すると数ヶ月かかる
  • Automatic Migration 機能により無停止で Auth0 移行可能
    • 再パスワード入力不要
  • CI/CD で本番テナント設定可能
    • YAML で設定可能なので出力してインポート

EC TOKION における実例

  • AWSWordPress
  • ログイン機能は WordPress
    • Auth0 と直接認証するのは WordPress のみ
    • Auth0 の WordPress プラグイン利用
      • 高機能でカスタマイズできるので本番で使える
    • Shopify の Multipass 機能を使って Shopify に引き継ぐ
    • WordPress と S3 ホスティングのログイン状態のやり取り
      • SSO の機能を使って実装
    • ログアウトしたら全サービスでログアウト状態にするのが大変
  • EC2 on WordPress を使っているのでメンテコストがかかる

AppSync での実装例

  • AppSync
    • GraphQL のバックエンドマネージドサービス
  • Shifter Headless
  • AppSync + Auth0
    • AppSync が OIDC に対応しているので Auth0 が簡単に使える
    • AppSync を BFF としてフロントからの認証を集約
      • ログイン状態の引き継ぎが不要
  • WordPress を Shifter にしているのでメンテコスト削減
    • AppSync の学習コストはいる

まとめ

  • Auth0 のような IDaaS を導入しないメリットはないので使う
  • TOKIO のような複数サービスだと状態管理がいる
  • AppSync のような BFF も検討

ガヤタイム

  • AWS のログはちゃんと見ておこう
    • 退職者がでたらすぐアクセス権消す
    • そもそも持っていけるものを持っていくことが悪いと思ってない場合もある
      • 文化や教育次第なところ
  • ログは開発者が作るもの
    • 100%信用できるか?ミスリードしないように。
    • Java のエラーが出た
      • 追っかけるとメモリが間欠故障してた...とか
  • 監査ログ10年残せ
    • 本当にいるのか?プロアクティブに動けるのか?
    • 法律のためでコストばかりかかる
  • ログが整形されているか?
    • hadoop で解析しようとしたけど整形されてなくて無理だった
    • awk で手動で整形...
      • ある程度整形したらエクセルに貼り付けてピボットテーブル
    • LogFormat は大事

所感

ovice.in というツール利用してのプレゼンでした。 バーチャルセミナー会場みたいな感じのツールが最近はやってますね。

メモを取りきれませんでしたが、金融のセキュリティの話を聞けたのが新鮮でした。 普段とは違うセキュリティ観点の話なので、やはりお金周りがメインの仕事だともう一つ大変なんですね。

Auth0 の実装が楽なのはそのとおりに感じてます。 自力実装に比べると本当に楽なんだけど、理解して使い始めるスタート地点のハードルはそこそこ高いと感じてます。 ゆえに理解を深めるために引き続き勉強がまだまだ続きそうです。

CodeBuild のビルドログが *** とマスクされる理由を調べた

事象

CodeBuild のビルドログにて正しく入れているつもりの情報が *** と表示されることがありました。

[Container] 2021/01/07 06:57:03 Running command make docker-build
DOCKER_BUILDKIT=1 docker image build --tag ***

BuildSpec をみても、環境変数をみても問題なさそうなのにログだけがおかしい。
このビルドログが出ているタイミングで、ビルドが失敗してしまったので、何らかの問題があるかと調査をしました。

結論

ビルドの失敗は別問題で、ログ上に情報が表示されてないだけでした。

公式ドキュメント

docs.aws.amazon.com

注記
機密情報を保護するために、CodeBuild ログでは次の情報が非表示になっています。

  • AWS アクセスキー ID。詳細については、AWS Identity and Access Management ユーザーガイドの「IAM ユーザーのアクセスキーの管理」を参照してください。
  • パラメータストアを使用して指定された文字列。詳細については、『Amazon EC2 Systems Manager ユーザーガイド』の「Systems Manager パラメータストア」および「Systems Manager パラメータストアコンソールのチュートリアル」を参照してください。
  • AWS Secrets Manager を使用して指定された文字列。詳細については、「キーの管理」を参照してください。

今回は、AWS Secrets Manager を利用して Docker Hub へログインしていました。
このときに利用しているユーザー名とビルド時に指定しているタグ名がたまたま同じだったため、非表示になりました。

まとめ

「Systems Manager パラメータストア」や「AWS Secrets Manager」を利用している場合は、その値を直接参照していないケースでもログが非表示になる可能性があるようです。
ログの表示が見えないだけなので、実際の動作は問題ありません。
直接利用している箇所だけがマスクされるわけじゃないことに注意したいと思います。

「AWS CloudShell おもしろ選手権」 #omoshiro_cloudshell 受講メモ

connpass.com

www.youtube.com

シェル芸は見ているだけで楽しいですね。
もっとシェルを使いこなしたいです。

本当だったらここに最高のキーノートがくるはずだった話

講師:トリ (@toricls) さん

  • クラスメソッドさんに相談したけど頼み方が悪かったのか失敗したとw
  • ホームディレクトリ配下は毎回消える。
    • .bashrcsudo npm install -g cowsay とか書いておくと自動で復旧させれる

LT1: CloudShell で SSM Agent を動かす

講師:so (@3socha) さん

SSM でつないだり、ssh でつないだりそんなことまでできたんか...

github.com

LT2: 禁止してみた

講師:SAKON (@sakon310) さん

speakerdeck.com

  • 他のクラウドサービスにはすでにある
    • ほかは Cloud Shell でスペース入る
  • いいところ
    • 端末キッティング不要
    • プロキシ穴あけいらない
    • マネコンIAM認証情報で動く
    • AL2 コンテナ 1GB 無料スペース
    • Safe Paste でオペミスも起きにくい
  • 便利すぎてガードレールが必要な雰囲気
    • 統制側からすると不安
    • 操作履歴が残らない
      • SSM だと残せる
  • 結果禁止した
    • IAM ポリシーから AWSCloudShellFullAccess 削除
  • セキュリティ上これがあればいい
    • 操作履歴を CloudWatch
    • 一括設定
    • 追加永続化ストレージ、EFSマウント

LT3: CloudShell でも開発したい! (ネタ)

講師:y-ohgi (@_y_ohgi) さん

開発したい話の予定が、開発したかったになったと。

speakerdeck.com

LT4: AWS初心者がCloudShellを使ってみた話

講師:amarelo(アマレロ) (@amarelo_n24) さん

speakerdeck.com

  • AWS CLI v2
  • 歯車アイコンから設定変えれる
    • 色、フォントサイズなど
  • 初心者でも使えた
    • 無料で使い込めるので色々やってみたい

LT5: CloudShellをIaC実行基盤として考えてみる

講師:ハマコー (@hamako9999) さん

dev.classmethod.jp

  • インフラをプロビジョニングするのは重大な権限が必要
  • 各リージョンで10個同時起動まで無料
    • 実質無料
  • IaC のコード
    • CodeCommit : IAM 権限で clone
    • GitHub : 認証めんどくさい、GitHub push で自動で S3 にコピーとか
      • homeは1G なので /tmp を利用
  • 実行ログをきちんと残す仕組みを構築
    • 実行権限や履歴をCloudTrailで管理

LT6: CloudShell内で動かしてるサービスを公開してみた

講師:しょーちゃん (@show_m001) さん

www2.slideshare.net

  • アイコンの位置とデザインは Azure (ry
  • ps ax で pid 1 をみるとコンテナとわかる
  • インバウンドは閉じている
    • ngrok で対応する
      • こじ開けることが可能

LT7: 狂気!AWS CloudShell細胞分裂

講師:ぐれさん😉 (@grethlen)

speakerdeck.com

  • tmux がデフォルトで入っている
    • 分割してもレイアウト崩れない
  • tmux と xpanes が使える
    • ssm は 40 ぐらいが限界
    • ojichat 100 いけた

f:id:omron:20201229165431p:plain

LT8: 何はともあれ、まず最初にやることといえばこれ

講師:KOMEDA Shinji (@komeda_shinji)

  • etckeeper
    • /etc にあるファイルをバージョン管理してくれる
  • CloudShell 制限
    • 20分でタイム・アウトする
    • /home は永続的、それ以外は非永続
    • /etc も初期化される
    • hostname, hosts は毎回変わる
  • yum install すると自動コミットされるようになる
    • daily の自動コミットはできないので適宜自分で
    • 変更履歴が残るので再現が楽になる

LT9: AWS CloudShellでLeaf Rogueを動かしてみる話(仮)

講師:フランドン畜舎内 ヨークシャイヤ (@furandon_pig) さん

furandon-pig.github.io

  • シェルさえあれば生きていける人も多い
  • CloudShell上でquemu動かしてNetBSD起動
  • 無事に Leaf Rogue を動かせた

LT10: リモートワーク主流の世の中だからこそ古の時代に思いをはせる with CloudShell

講師:watanabe.seigo (gb-swatanabe) さん

ターミナルでマインスイーパーを起動する話でした。

  • 古の時代
    • データセンタに行く(物理的に)
    • LED, 物理配線、物理スイッチ、物理作業
  • 暇つぶしはマインスイーパ
    • プリインストール、通信もない、ばれないので
  • terminal-mines
    • ascii only で make

LT11: AWS CloudShellでAWS CLI v1を実行する方法

講師:AWS 亀田さん

  • aws v2 をアンインストール
    • rm で消すだけ
  • v1 をインストールして、パスを通す
    • 再起動すると一部のファイルを CloudShell が書き戻してしまう
  • IAM のクレデンシャルはどこからとってるか分からない
    • aws configure に入ってない
      • Cloud9 は入っている、時限式で5分ごとに書き換えられる

LT12: (仮) CloudShellの細かすぎて伝わらないネタ集

講師:Hiroki Uchida (@nikuyoshi) さん

  • シェル環境にこだわりたい
    • oh-my-zsh, ph-my-fish などを維持したい
  • sh -c "$(curl -fsSL http://bit.ly/oh-my-cloudshell)"
    • Ansible の実行からプレイブックの実行まで自動で行いセットアップ

github.com

トリさんの締め

  • 誰もが叩くコマンドを叩いてみよう
    • name -r AL2 で動いてそう
    • env トークンを取るエンドポイントとオーサライズヘッダーがありそう
    • dmesg Fargate って文字があるような

所感

真面目な話から今後役に立ちそうな話、ojichat の狂気までとてもおもしろい内容でした。

「AWS Chatbot が楽だった話」で「JAWS-UG朝会 #16」に登壇しました #jawsug_asa

jawsug-asa.connpass.com

朝会だと急な予定で潰れることもほぼ無いと思ったので、JAWS では初の登壇をしました。
急に出勤予定にならなくてよかったです。

はじめに

このブログは個人ブログです。
今回の登壇は会社名を出して行ったため「公私混同になるなー」ということもあり、ブログにしておりませんでした。

一方、今は TwitterFacebook などの SNS でのつながりを求めたり、個人ブランディングも行う時代です。
自分のためにやるプレゼン それが LT を受講し、
「資料公開やソーシャル活動、ブログの公開も含めてこその登壇かな」
と感じたので記すことにしました。

発表

AWS Chatbot が楽だった話

speakerdeck.com

話した内容については、スライドだけでもわかるようにしているつもりなのでこちらを参照ください。
疑問点があればコメントなど頂ければと思います。

CloudFormation YAML

スライドに使用した CloudFormation の YAML はこちらを参照ください。

github.com

登壇について

今回は Amazon Chime を利用しての登壇でした。
オンライン登壇では、聴衆の方とインタラクティブに話すのが非常に難しいです。
さらに Zoom などと違いスクリーンシェアで Chime 自体が隠れる仕様なので、状況が全く見えず1人で進めているだけの感じになるあたりが難しいと感じました。
しかしながら、聴衆の方々が見えない分、緊張しづらいのはメリットと感じました。

あと、登壇していると他のセッションをちゃんと聞く余裕がなくて受講メモが取れませんでした...

さいごに

AWS はとても興味があり、仕事でも活用をしております。
一方、AWS は手段であり目的ではない状況です。
そのため、本格的に語るというのはなかなか難しいですが LT なら話せることもありそうなので、今後も登壇できたらと思っております。

「JAWS-UG 初心者支部#34 re:Invent re:Cap&LT大会」 #jawsug_bgnr 受講メモ

jawsug-bgnr.connpass.com

今日は他にも関西支部やらCLI支部やら楽しそうなイベントがたくさんありました。
最初に申し込んでた初心者支部をそのまま受講しました。

①30分セッション:re:Invent2020 re:Cap(時間があまればQA)

講師:AWSJ 亀田 治伸さん

アンケートで発表内容を確定。

AWSコアメッセージ

  • 年 29% 成長
    • Enterprise IT compaies で世界5位
    • Cloud 分野では Alibaba が Google を抜いている(ドルベース)
    • 企業の予算では 4% 程度しかクラウドに使ってない
      • まだまだ投資できる
  • クラウドコンピューティングは New Normal/Freedom/Builders
    • I want it all and I want it now
    • Transformation "Don't stop me now"
    • 自分のビジネスに集中しよう
  • 小売業から生まれた IT のベンダー
    • 機能が重複してもサービスが多いほうが良いという考え
    • ユーザーにとって選択肢が多いほうが良いという信念
      • Amazon Managed Service for Grafana
      • Amazon Managed Service for Prometheus など
      • EC2 も種類が増えていてわかりにくいけどその例の一つ

利便性の向上

気になるのだけメモ。

  • Building microservices with AWS Proton
    • CFn のサーバーレス版
  • Systems Manager - Change Manager
    • 普段の運用を便利にするツール
    • パッチ適用、クラスタメンテ
    • 管理者への承認フローを自動化
  • Systems Manager - Fleet Manager
  • Systems Manager Application Manager
    • EC2 のアプリを自動で検知して表示
  • Outposts
    • 80inch のみだったのが、1U/2U の小さいのをリリース
  • Wavelength
    • 5G が早いのはキャリアまででインターネットに出ると同じ
    • 5G から直接 AWS リソースへ
      • 通信事業者のネットワークから出ない

QA

  • AWSさんのSAさんも毎年勉強が大変だと思うのですが、触ってみるのが一番習得するために良いでしょうか?
    • 手を動かす前にドキュメントを読め!
    • 動かして満足しないために

終了後、亀田さんは関西支部へ移動していきました。
関西支部も気になる!

②15分LT Let's ライトニングトーーーク! ~ せっかくだからLTやってみよう!(時間があまればQA)

講師:ソラコム テクノロジーエバンジェリスト 松下 享平さん

自分のためにやるプレゼン それが LT

speakerdeck.com

  • 飲み会でグダグダ語ったことがある人は LT の素質あり
  • エバンジェリスト養成講座 西脇さんの本が参考になる
  • LT は自分の学びのためにする
    • プレゼンは他人を動かすもの
    • 理解を深めるために人に教える
      • 知識を確実なものにできる
      • その道の専門家になれる
      • その道の専門家として認識してもらえる
  • 他社より1歩前に進んでるだけでいい
    • それだけで先生になれる
    • 居酒屋で語る行為もそれ
  • 本番前にいろいろある
    • 応募、ネタぎめ、資料作成、練習、本番、公開&ソーシャル活動
    • ネタぎめで学びに
    • 練習で知識の定着
    • ソーシャルで認知
  • ネタは応募してから考える
  • 1LTは1テーマ
    • 20枚程度で
    • タイトルに結論を
    • ストーリーをつなげる
    • 最後で最初のメッセージを反復するとまとまる
    • 最後でタイトルコールおすすめ
    • 困ったときは「ともかくこのスライドでいいたいことは」という
      • これで自分も相手もリセットできる
    • 応募してから内容を考える

③15分LT AWS Protonを触ってみたよ。(時間があまればQA)

講師:初心者支部 織田 繁さん

speakerdeck.com

  • Proton
    • 概要:コンテナおよびサーバーレスデプロイメント向けの管理自動化
    • 以下をまとめるもの
      • Platform Team - CFn など AWS 環境構築に集中したい
      • Developers - サービスを作ることに集中したい
  • Platform Team 作業
  • Developers 作業
    • テンプレートからパラメーターを設定して環境を立ち上げ

④10分LT AWS Wavelength(12月に東京リリース予定)について(時間があまればQA)

講師: KDDI 松本 健太郎さん

  • AWS Edge サービスとしてキャリアユーザーに低遅延アクセスを提供
    • インターネットに出ない
    • KDDI 網から直接 Carrier Gateway を通って AWS
  • EC2 メイン+α
    • EBS, ECS/EKS...
  • Wavelength にサブネット作る
    • 通常の VPC 作る
    • Carrie Gateway / Route 作成
    • Instance 作成、Carrie IP 設定
  • 5G の事例
    • スポーツ観戦で特定選手を手元のスマホに配信したケースなど
    • リアルとずれないようにする

⑤10分LT honeycodeはローコード化推進の夢を見ない

講師:初心者支部 山本 淳博さん

  • Honeycode
    • Servicenow
    • コードを記載することなくモバイル・Webアプリを構築可能
    • GUI でボタンの配置や色を変えれる

⑥5分LT JAWS DAYS 2021宣伝(時間があまればQA)

講師: JAWS-SG 外舘 有希さん

所感

AWS とは直接関係のない内容でしたが Max 松下さんの LT がとてもよかった。
月1回ぐらいは登壇できるようにしていきたいなー。