トランプ兵の記憶と記録

普通のアプリケーションエンジニアの備忘録

会社員でないアプリケーションエンジニア フルリモートワーク4年間の振りかえり

書きたいこと

2020年4月から丸4年、複数企業でフルリモート勤務をしていた。

2024年4月からは完全出社リモートワークなしに戻さざるを得なくなり、フルリモート生活が完全終焉するので振り返りを書いておく。

ここでいうフルリモートワークとは

初日と最終日以外は在宅で終日リモート勤務、必要な時だけ単発出社のことを指す。厳密に言えばフルリモートではないが容赦願う。

用意したもの

ネット環境

元々Wimaxを利用していたので、新規に用意することがなかった。リモートワークでは1月で 80G近く通信していたので、帯域制限が少ないサービスが良いと思う。

Wi-Fiで回線が細いと、リモートデスクトップで画面がガタ付きストレスになりやすかった。

Wi-Fi不調時のため、テザリングも用意しておいた方が安心。

1人で仕事できる自宅の密室

勤務規定で概ね求められる。ミーティングで業務情報を扱うので、同居人や近所に音が漏れないことが必須である。サテライトオフィスも論外だ。

私の場合、実家が一軒家で子供時代の部屋と机が残っていたので、使うことにした。

机と椅子

1日8時間は机に座るので、姿勢を崩さないよう整備した方が良い。私の周囲ではゲーミング椅子を購入した方もいた。

下手な椅子に座ると、首が痛くなり仕事にならない。

布団と毛布

仕事部屋に置いておくと、昼休みの休憩時に仮眠したり、防寒になるので便利だった。

モニタ

モニタ貸与まで申し出てくれる企業はほぼない。FigmaExcelはノートPCだけでは見にくいので、モニタは必須だ。

EIZOの事務用モニタを購入した。好みで良い。EIZOなのは、リモートワークを始めた会社で出社時に使っていて、目に優しく疲れないので気に入ったからだ。

リモートデスクトップする場合複数モニタがあっても意味ないので、1台あれば十分。

ヘッドセット

ミーティングのために必要。滅多に貸与されない。MacでもWindowsでも使え、音響の良いロジクールのヘッドセットを購入した。

マウス

貸与されるが、好きなものを利用して良いことが幾度だった。姿勢を崩さないよう、ロジクールのマウスを購入した。

借りたもの

借りたものは控えておき、無くさないようにすること。

社員証

フルリモートの場合は発行されないこともあったが、大抵は発行される。リモートワーク中無くさないよう、固定の場所に保管してたまに存在を確認する。

無くしたら大目玉なので注意。

ノートPC

大抵の場合貸与される。これを自宅に持って帰り、VPN経由でリモートワークできる。

場合によっては、私物PCをBYODして、職場のPCへリモートデスクトップの場合もある。

携帯電話

認証や検証目的で貸与されたことがある。大抵はBYODが認められた。BYODの場合、携帯電話は無くさないように注意し、Google Authenticatorを入れておく。

よかったこと

周囲にうるさい人がいない

仕事に集中できる。 特に面倒な課題の検討や大変な不具合修正、リリース作業にリモートは有用

睡眠が安定する

規則正しくたっぷり睡眠が取れるので、2社目で1週間徹夜デスマーチした時の体調不良が治った。嬉しい。

食事が安定する

オフィス勤務だと外食続きになり、就職してから20キロ太った。フルリモート開始とほぼ同時に事務通いをはじめ、-14キロ達成した。

19時以降食べない、脂っこい外食から無縁なのがよかった。

電車トラブルから無縁

自宅はJR線沿線なので、電車遅延と車内トラブルがかなりある。かつては電車通勤で寝込んでしまって殴られそうになったりなどしたが、リモートワークで通勤時の危険から無縁になった。

よくないこと

オンボーディングが捗りにくい以外、フルリモートのデメリットは、私の場合ほぼなかった

最後に

アプリケーションエンジニアの場合、出社しないとできないインフラ作業がない。クラウドVPN、ノートPCがあれば会社のビルにいる必要はない。

Gitlabのように、コミュニケーション設計やドキュメンテーションに力を入れれば、フルリモートで十分だと思う。

終わり

AWSの基礎を学ぼう 特別編 Amplify Studio ハンズオン

目的

特別編 Amplify Studio ハンズオン - connpass に参加したので振り返りを書きます

ハンズオン資料

AWS Amplify Studio + Figmaハンズオン

作ったもの

AWS

構成図

はじめに|AWS Amplify Studio + Figmaハンズオン の通り

詳細

  • Cloud9
  • Amplify
  • Amplify cliで作成したもの
    • Lambda
    • Cognito
    • IAMユーザ

構成図にはAppSyncがあるが、GraphQLは作成しなかったので今回のハンズオンで作ったり使ったりしていない(はず)

AWS以外

Figma: the collaborative interface design tool.

デザインツールのFigma。各自Gmailまたはメールアドレスでアカウントを作成して利用。

同名のjpドメインは可動フィギュアのWebサイト。AWSとは関係ないので検索するときは注意。

セットアップ

ハンズオンの通り

Cloud9の準備・作成|AWS Amplify Studio + Figmaハンズオン

Amplifyの準備・作成|AWS Amplify Studio + Figmaハンズオン

留意点

Receiving `DeprecationWarning: Invalid 'main' field` for `cloudform` dependency on most Amplify commands with Node 16+ · Issue #9939 · aws-amplify/amplify-cli · GitHub

問題の回避のためNode.js バージョン14を利用。Cloud9にnvmがインストール済み。(ハンズオン資料の下記の部分)。

nvm install 14.19.1
nvm use 14.19.1

デプロイまでの流れ

Amplifyの準備・作成|AWS Amplify Studio + Figmaハンズオン

Reactの準備・作成|AWS Amplify Studio + Figmaハンズオン

ハンズオンでは下記を一通り実施

  1. Figmaでレイアウトを作る
  2. AWS Amplify StudioでFigmaを読み込む
  3. AWS Amplify Studioでデータモデルとアプリケーション動作用のデータ(seed)を作成
  4. Reactコンポーネントamplify pull でGitリポジトリにダウンロードする
  5. 作成したReactコンポーネントを使って開発する
  6. amplify publish でAmplifyにデプロイ

LT

speakerdeck.com

感想

  • Amplify StudioはFigma連携が便利
  • 開発の流れが変わる
    • 要員が変わる
    • デザイナーとAWSわかる人がいればサービスがすぐ作れる
    • Amplify Studioを使うと簡単なWebサイトならAPI開発が不要になり、エンジニア寄与率が低そう
  • セキュリティとAWSのリソース管理は気を配る必要があると思う
  • 大規模になってきたのでECSに移行したいなど、Amplifyをやめたいときにソースコードはどれぐらい流用できるのか
  • GitHub - renebrandel/amplify-homes サンプルソースコードはforkしておけばよかった。変更を自分の手元にpushして保管できる
  • Amplifyの使い所
    • 最初はコーポレートサイトみたいな静的なコンテンツから使っていくと便利かも

ありがとうございました。

MySQLと(OracleとPostgresSQLと)私の12年間

この記事は Calendar for MySQL | Advent Calendar 2021 - Qiita の23日目です。

Happy holidays!

去年は Azure Database for MySQLに奮闘した話を書きました。 テクニカルなお話、やってみた談が聞きたい方は去年の記事をお勧めします。 こちらもぜひ読んでやってください。 qiita.com qiita.com

2019年から2020年の丸2年は新規サービス開発、運用、継続開発に費やし、実は去年のアドベントカレンダーはある仕事の最終出社日に公開したのでした。

2021年の仕事は前半企画職でプロトタイピング開発だったのでRDBに関わらずでした。

2021年後半はAuroraを使っているサービス2件に関わってますが、残念ながらMySQL自体の深淵には関わってません。

そこで、今年は社会人12年目の節目なので、MySQLと私の関わりを語ることにしました。 途中でOracleとPostgresも出てきますし、技術色はあまりないですが、アドベントカレンダーの『MySQLについてならなんでもOKです』に甘えました。

2008年11月:初めましてMySQL

新卒で勤めていた会社の内定者研修でJSP/Servlet/MySQLの勉強があり、Webアプリ3本ほどの開発を入社前にやりました。 卒業研究と合わせて苦悩していました。

大学は数学系研究室で代数はバッチリだったので、自分含め周囲の就職内定者はRDBSQLは余裕でマスターしてました。問題は言語だ。ここでJavaを選んでしまった私は今でも呪われているかもしれない。

当時はMySQL 5.1でした。

データベースの研修は、MySQLをzipダウンロードしてきてパスを通してmysqldとmysqlコマンドプロンプトで起動するところから始まり、テーブル設計、SQLJDBCまでやりました、結構当時としては詰め詰めな教育だったと思います。

個人ではオライリーのHead Firstシリーズを読んでました。SQL、データベース設計、DBAの入門がしっかり書いてあります。 www.oreilly.co.jp

2009年:ほぼ社内ニート生活

2009年4月に就職しましたが、リーマンショックで新入社員研修後はある程度自由に社内ニートや社内業務をしてました。

社内研修はOracle 9gとMySQL 5.1でした。社内アプリはGoogle BigQueryだったりPostgresSQLだったり好き好きでした。 この時期に作った広報用ブログは我々同期の好みでMySQLになりました。

2010年:初めましてERMaster

2009年の年末から2010年1月くらいまで火消しプロジェクトに常駐してました。そのあとは2010年夏まで伸び伸び社内ニートでした。 仕事はOracleでしたが、好きにしていい社内の検証開発はMySQLやPostgresSQLでした。

OracleMySQLはなんか両極端に見えますが、社内にMySQL得意な人がいたので、RDBMySQLを使う文化がありました。それ以外も社内はSpringなどOSS利用が盛んでした。

社内のMySQL得意な人と有志が ERMaster というER図作成ツールを出してました。 ERMasterの初期バージョンはMySQL以外で動いた記憶がありません。仕方なく私は A5:SQL Mk-2 - フリーのSQLクライアント/ER図作成ソフト (松原正和) を使うことにして現在に至ります。

そんなERMasterは jfluteさん はじめ色々な方がforkしてくださっていて感慨深いです。こんな有名になるとは当時は思いもしませんでした。

2010年〜2013年

この頃はあまりMySQLに触れていません。

仕事の最初の2年ほどは欧米向けサービスでOracle 11gを使っていて、トルコ語が文字化けして困ったりしてました。

その後はメインはOracleだけど、セッション管理だけスケーラビリティとコスト削減のためMySQLという現場があり、そこで少しMySQLに関わったくらいです。

2012年の後半くらいからは、色々なきっかけで製品営業に関わるようになり、プロトタイピングやPoCには個人でMySQLを使っていました。 セットアップが楽なので何かあったらMySQLが鉄板でした。

この頃にOracleはギブアップしました。 2010年ごろの会社の目標設定でOracle DBAを取ろうとしましたが、Oracleを勉強するうちに『これLinuxそのものじゃんキリない』と悟ってDBAレベルの理解は挫折しました。 最近はもうSQLポケットリファレンスも出なくなりましたね。今でもOracleで動くSQL書けるかなあ…?

[改訂第4版]SQLポケットリファレンス | 朝井 淳 |本 | 通販 | Amazon

2013年〜2014年前半

自分が知りたいことを極めると、IPA試験のシステムアーキテクトが取りたいと思うようになりましたが、論文試験が面倒なのでやめました。 代わりに論文のないデータベーススペシャリストを取ることにしました。

Web+DB Pressの奥野さんの連載と、ミックさんの本を読みまくりました。 奥野さんの連載は本になったので買おうかなあ。。。 RDBとデータベース設計は勉強と実践が結果に出るので、仕事で役に立っています。

www.amazon.co.jp

www.amazon.co.jp

www.amazon.co.jp

2014年後半〜2016年前半

2014年9月にWeb系の開発会社に転職して運用部隊に配属になりました。 運用部隊はこの会社独特の組織で、今で言うところのSREに開発を兼ねる部署で、10年20年運用しているシステムを扱うのが特徴でした。あと全社的炎上ハンターもたまにやらされた。

Web系の会社なのでMySQLとPostgresSQLを多めに扱うようになり、Javaからはほぼ隠居してました。 MySQLは関係ありませんが、 この頃からJavaコミュニティの勉強会に参加するようになりました。元後輩とDBFluteフェスにも行ったのですが、その頃はまだDBFluteを実践投入していませんでした。

運用開発主体だったので、性能改善に取り組むこともあり、性能の出るSQLRDBによって全然違うことを学びました。 アルゴリズム改善、SQL改善、インデックス付与でレスポンス20分を3秒にした時は感動したなあ。

2016年後半〜2021年

2016年の前半にフラっと会社員を辞め無所属になりました。 それ以降参画OKいただける案件は、何故か軒並みMySQLです。 MySQLの腕で採用されたわけではないのですが、自分が興味を抱く方向に何故かMySQLMySQLに詳しい方がいます。

2017年春夏、当時契約していた現場で、事業ごとにEOL対策チームを置くことになりました。 とある事業部のEOL対策チームの初期計画を立てる中、MySQL 5.1からのバージョンアップの見積りもしたのだけど、どうなったのだろう。

2017年秋から2018年秋位、Struts1とSpringでウェイウェイしてました。 データベースではたまに名DBA様方にSQLレビューや設計の相談でお世話になっていました。

2018年の秋冬は、EOLしたSeasarをSpringにリプレースするおひとり様案件でアーキテクトしてました。

私の前任ベンダがS2JDBCの移行に DBFlute を使うと言っておきながら検証しなかったので、私はDBFluteってなに!から奮闘したのでした。 注文だけMySQLのread replicaから読み取る要件があったので、jfluteさんにSlackで質問に答えていただいて、Spring Boot + DBFluteで複数DataSourceを使えるようにしました。

ここまでで、ポンコツですがOSS貢献って楽しいなあと思えるようになりました。

2019年〜2020年、ある日突然プロジェクトチームでインフラに拝命されてしまい、閑古鳥サービスのMySQL 5.7なら扱えるようになりました。 本来インフラは別にアサインされた人がいたのですが、多忙で体勢を抜けてしまい私に降ってきたのでした。 勉強と実践って大事ですが、Azureに慣れてしまったのでAWSもAuroraがさっぱりわかりません。

2021年はAuroraミリ知ら状態で終わります。

今後

まだまだMySQLわからないことが多すぎるので、もう一度学び直しが必要です。自分のために数冊晒しておきます。

オライリーの馬の本はMySQLに関係ない運用ノウハウとして読みたい。読みかけ。

www.amazon.co.jp

www.amazon.co.jp

www.amazon.co.jp

データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用 | Laine Campbell, Charity Majors, 八木 和生 |本 | 通販 | Amazon

これも積読なので消化したい

tech.nri-net.com

今後

2022年の2月からは技術サポート職に参加します。

面接時『MySQL以外本当に経験ないんですか』と聞かれましたが、ここ数年私の向かう道ではRDBMySQLです。PostgresSQLとOracleはかなり勉強し直さないと使えないので経験なしと考えています、と答えるしかありませんでした。ぶっちゃけ私の頭ではサポート職は無理です 当面はDBAよりローコード開発やフロントエンドとバックエンドのアーキテクトが主体になりそうです。

どうなることかわかりませんが、私がエンジニアである限りMySQLとの関わりは切れそうにありません。 どこかで見かけた時には見守ってやってください。

最後までお読みいただきありがとうございました。良いお年を。

AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Grafana

目的

AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Grafana - connpassの復習

ハンズオン資料

https://github.com/harunobukameda/Amazon-Managed-Service-for-Grafana/

speakerdeck.com

「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Grafana」でお話しました。

ハンズオンの復習

Amazon Managed Grafanaの特徴

X-RayやCloudWatchと連携できる

Amazon Managed Grafana | フルマネージド Grafana データの可視化 | Amazon Web Services

今回のハンズオンではCloudWatchを利用

作ったAWSリソース

  • Grafanaへの認証用
  • Grafana本体

Amazon Managed Grafanaの認証

User authentication in Amazon Managed Grafana - Amazon Managed Grafana

今回のハンズオンでは下記の理由からAWS SSOを利用

  • SAML認証だとIdPの作成が煩雑
  • Amazon Managed GrafanaではID/Password認証をサポートしていない

作ったものの構成

AWS SSOとAWS Organizationは省略

f:id:zoosm3:20211009183953p:plain

f:id:zoosm3:20211009190055p:plain
20211009_AWSハンズオン_Grafana

あまりメトリクスがない。先週のハンズオンで作ったRDSやLambdaのメトリクスが辛うじて見られる程度

ハンズオンで得た知識

  • CloudWatchと比較した場合の、Grafanaのメリット
    • 好きずき
    • 他との連携を見るならGrafana
  • Grafana Dashboardの作り方

感想

  • フルマネージドGrafanaだと構築運用が楽でよかった
  • メトリックスが溜まっていなかったので面白いダッシュボードが作れなかった
  • KibanaとGrafanaの違いも押さえておこう
  • 11/6にPrometheusのハンズオンが開催予定だが、Grafanaと同時の開催が良かった

次回も参加予定です。 ありがとうございます。

AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる LambdaとRDS Proxy

目的

AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる LambdaとRDS Proxy - connpass の復習

ハンズオン資料

https://github.com/harunobukameda/RDS-Proxy-AWS-Lambda/

ハンズオンの前に

イベント宣伝

aws.amazon.com

classmethod.jp

LT

speakerdeck.com

ハンズオンの復習

作ったAWSリソース

  • Cloud9
    • RDS (MySQL) に接続するため
  • Secrets Manager
    • RDS ProxyがRDSに接続するための情報を管理するため
  • RDS
  • RDS Proxy
  • Lambda関数
    • MySQLに接続するコードはNode.jsを利用
    • 接続処理を実装するのは意外に手間なので、事前に用意されたzipをアップロードした
  • VPC
    • デフォルトVPCを利用

作ったものの構成

Cloud9は省略

f:id:zoosm3:20211002193327p:plain
20211002_AWSハンズオン

  1. Lambda関数 -> RDS Proxy -> RDS
  2. Lambda関数 -> RDS

2通りの接続を試し、レスポンスタイムを比較した

RDS Proxyのメリット

  • コネクションプールが使える
    • Lambdaは常時起動するわけではないため、データベース接続でコネクションプールが効かない
    • RDS Proxyを使うとコネクションプールとコネクションプールの共有ができるようになる
  • failoverの時間が短縮できる

Amazon RDS プロキシの料金 | 高可用性データベースプロキシ | アマゾン ウェブ サービス

Amazon RDS プロキシでは、アプリケーションがデータベースと確立した接続をプールおよび共有でき、データベースの効率とアプリケーションのスケーラビリティが向上します。

RDS プロキシを使用すると、Aurora と RDS データベースのフェイルオーバー時間が最大 66% 短縮し、
AWS Secrets Manager および AWS Identity and Access Management (IAM) との統合によりデータベースの認証情報、認証、アクセスの管理が可能となります。

RDS Proxyのデメリット

設定上の注意

  • RDS作成時に『拡張されたログ記録』の注意を入れる。デバッグに使うため
  • 本番運用時はセキュリティグループで必要な制限を入れること
  • Cloud9からRDS Proxyに接続する際、ERROR 2013 (HY000): Lost connection to MySQL server at 'handshake: reading initial communication packet', system error: 11 が発生することがある。RDS Proxyの構成に時間がかかることがあるので、数回接続を試すこと
  • ハンズオンはパスワードがハードコーディングされているが、LambdaでRDS Proxyに接続するコードを書く時、接続情報はSecurity Manager経由で取得するようにした方が良い

レスポンスタイムの比較

手元の環境だと、LambdaからRDS Proxyに接続した場合

初回 1,565ms, 2回目 232.26ms, 3回目 224.27ms, 4回目 50.76ms

初回はファーストタッチペナルティがあるのがわかった

ハンズオンで得た知識

  • Cloud9のデータベースの実態はMariaDB
  • パスワードを人力で設定するなら、ローテーションしないのが近年のトレンド
  • RDS Proxyを使うとピン留めという現象がある

ハンズオンの感想

  • ハンズオン2回目の参加で前回より手を動かしやすくなった。ずっとZoomを見ているのではなく、声を聞きながら自分で手を動かしたり工夫が必要
  • ハンズオンの件名を見てもっと初心者向けのLambdaの話かと思っていたが、RDS Proxyの説明が多くてためになった

  • AWSでのサーバレスでハマりやすいところがわかった。とにかくコネクションプールが関門かもしれない

  • Lambdaを実運用するときは、アーキテクチャや開発運用に注意しないと大変
    • 言語の選定
    • データベースはRDBかNon RDB
    • 本番サービスでLambda関数のソースコードをzipアップロードする?CI/CDを組まないと管理が大変そう
    • 接続情報をハードコードしない
  • バッチのように単発で起動する関数でない限り、Lambda関数からRDSを使うならRDS Proxyはあった方がいいかもしれない
  • ピン留め注意!
    • JavaアプリケーションはコネクションプールやPrepared Statementを大前提にしたりするので、気をつけないとピン留めの原因になりそう
    • 監視も大事
  • AWSは公式ドキュメントや発表スライド、Developers.IOをしっかり読む
  • ハンズオンは雑談やQAが勉強になる

来週のGrafanaも参加します。ありがとうございました。

AWSにサインアップしたらやる最初の設定

目的

個人勉強用にAWSにサインアップしたので、AWSにサインアップして最初に設定したことの覚書

やったこと

rootユーザの安全確保

パスワード変更

AWS アカウントのルートユーザー - AWS Identity and Access Management

MFAを有効にする

AWS アカウントのルートユーザー - AWS Identity and Access Management

スマホGoogle Authenticatorを利用した。

アクセスキーを利用しない

AWS アカウントのルートユーザー - AWS Identity and Access Management

AWSアカウントを新規作成した直後なのでアクセスキーは生成されていない。 特に対応することはなかった。今後も作成しないようにする。

管理用IAMユーザの作成

【はじめてのAWS】管理用IAMユーザーを作成しよう - サーバーワークスエンジニアブログ

基本的には今後IAMユーザを使うこと。

IAMユーザへの請求情報アクセス許可

https://console.aws.amazon.com/billing/home#/account

『IAM ユーザー/ロールによる請求情報へのアクセス』で編集→IAMアクセスのアクティブ化にチェックを入れて更新ボタンを押す。

請求情報とコスト管理の設定

https://console.aws.amazon.com/billing/home#/preferences

  1. 『E メールで PDF 版請求書を受け取る』『請求アラートを受け取る』にチェックを入れておく
  2. 無料利用枠の使用アラートを受信する のメールアドレスを入力
  3. 設定の保存を押す

CloudWatchで請求情報のアラームを作成

とりあえず1,000円以上でメールを受け取るようにする。

個人利用なので1,000円くらい掛かった時点で気が付きたいという程度の根拠。

デフォルトリージョンを東京に変更する

ヘッダ右のオハイオを東京に変えた。無料枠で使うつもりなのであまり意味はないかもしれない。

仕事上はどのリージョンを使うか要確認。

支払通貨をJPYに変更

https://console.aws.amazon.com/billing/home#/account

『お支払いの設定』でUSDをJPYに変更。無料枠で済ませるつもりなのでほぼ必要ないが念のため。

参考

AWS基礎を学ぼう 特別編 最新サービスをみんなで触ってみる はじめてのCI/CDパイプライン まとめと感想文

目的

7月になってから仕事でAWSを使い始めたので、CI/CDの勉強会に参加した

ハンズオン資料

JAWS-UG 初心者支部#37 codeシリーズハンズオン

ハンズオンのまとめ

構築するリソースを理解する

JAWS-UG 初心者支部#37 codeシリーズハンズオン 構成図の通り

VPC

  • 構成図の通り、Cloud9とEC2がVPC内にあるので最初に作成した
  • Cloud9とEC2を使わなければ不要だと思う

IAMロール

下記リソースのフルアクセスを付与した。

  • EC2
  • CodeCommit
  • CodeBuild
  • CodePipeline
  • CodeDeploy
  • S3

キーペアとEC2

  • ハンズオンではEC2にsshしなかったのでキーペアは利用しなかった
  • 今回のハンズオンでは、CodeStarでテンプレートを指定したらデプロイ先が自動的にEC2で決まった
  • Codeシリーズだけを使いたい分には不要だと思う

Codeシリーズ

クラウドIDE

  • Cloud9
    • AWSコンソール上でIDEが使える

S3

  • CodeBuildで作成した成果物を保存

CloudFormation

明示的に利用しないので構成図にはないが、CodeStarでリソースを作成するとCloudFormationが利用されていた

前半: 準備+CodeStarでリソースを作ろう

CodeStarの利用

AWS CodeStar のセットアップ - AWS CodeStar

前提

『ステップ 3: ユーザーの IAM アクセス許可を設定する』に書いてある。

ハンズオンではAdministratorAccess管理ポリシーを持つIAMユーザで操作した

サービスロールの作成

初回はサービスロールの作成を求められる。これで開発者の代わりにCodeStarが様々なリソースを作ってくれる

f:id:zoosm3:20210710164643p:plain
AWS Code Star: 初回のみサービスロールを作成

Amazonアカウントとの連携

しばらくしたら表示されなくなった。AWSアカウント作成直後などに表示されることがある模様

その他

  1. リポジトリの指定
  2. プロジェクトテンプレートを選択
    • 今回はHTMLを選択
    • デプロイ先のサービスはEC2
  3. EC2の作成

ここまで操作するとCloudFormationが必要なリソースをまとめて作成していた

f:id:zoosm3:20210710170214p:plain
CloudFormationが色々動いている

f:id:zoosm3:20210710170324p:plain
CloudFormationで作成されたリソースの一部

Cloud9環境の作成

ステップ 1: 環境の作成 - AWS Cloud9

ソースコードの修正とpush

Cloud9でソースコードを作成してpushすると、EC2に自動で修正がデプロイされた

ビルドが動く仕組み

buildspec に書いてある

CodeBuild のビルド仕様に関するリファレンス - AWS CodeBuild

後半:手動でリソースを作成しよう

CodeStarで作成されたリソースとIAMロールを手で作成して、EC2のデプロイを試してみた

後片付け

EC2の止め忘れがないよう注意

雑談

最後の雑談で週末何をするか、の話から、AWS資格の取りやすさと勉強のコツの話に

  • Solution Architect Associateは難しい
  • 最初はSysOps アドミニストレーター – アソシエイトから入ると簡単
  • Solution Architect Professionalに合格するためには、ドキュメントを全部読むこと

ここは経験者のコツや職場の考え方次第で色々見方があるなあと思った。ハンズオン中の運営さんの雑談も勉強になった

トラブルシューティング

ハンズオン中に起きた困りごとの対策

AWSからYour Request For Accessing AWS Resources Has Been Validatedという件名のメールが来る

ハンズオン中にAWSからメール受信。

何がValidatedなのかわからないので運営さんに質問したところ、AWSアカウント作成直後に起きることがあるということで、特に対応不要だった。

Dear AWS Customer,

Thank you for using Amazon Web Services!

You recently requested an AWS Service that required additional validation. Your request has now been validated for AWS Asia Pacific (Tokyo) region(s). If you are still experiencing difficulty, please contact us at aws-verification@amazon.com <[[mailto:aws-verification@amazon.com]]>.

Thank you for your patience.

—The Amazon Web Services Team

デプロイに失敗する

  • IAMロールの作成やアタッチを忘れている
    • IAM を参考にして作成なりアタッチなりする
  • CodeDeployで追加の上書き を忘れている
    • デプロイ設定の修正が出来ないので、削除して再度作り直す

参加上の振り返り

印象的なコメント

  • CodeCommitに課題がないのが不便なので、CodeCommitにJIRA連携機能があるのではないか?

勉強会への取り組み方

  • 仕事でないので仕事部屋にあるモニタを使わなかったが、PCのモニタがあったほうが良かった。ハンズオン資料を見ながらAWSコンソールを触ることが出来るので効率がいい
  • AWSの画面キャプチャを撮るときは個人情報を載せないように注意
    • IAMユーザに自分の名前などを付けなければ回避できると思う

AWSの知識

  • 事前にEC2, VPC, IAM, CloudFormationの知識があったので比較的困らなかった
  • AWSのリソース作成は、手動よりCloudFormationやCodeStarを使ってまとめてリソースを整理したほうが便利
    • 作成忘れやミスがない
    • 一括でリソースを削除できる
  • EC2のデプロイが完全に自動でできるのは嬉しい。その昔はEC2でも手動で切り替えをしていた
  • CodeCommitは課題やプルリクエストのマージ権限などが充実すると仕事で嬉しい
    • そういう時はGithubを使えばいいのかもしれないが、Githubが使えない場合もある
    • できればGitlabとBitBucket連携も欲しいが、多分他の方法があるので必要になったら調べる
  • AWSアカウントを本番と本番以外で分割する場合、Codeシリーズのリソースはどちらのアカウントに配置すると良いのだろう
    • リポジトリが複数あると開発上混乱するので、リポジトリAWSに持たずGithubだと便利かもしれない
    • CodePipelineは本番以外用・本番用の2つ持つしかないかなあ?出来れば分けたくない…

ありがとうございました。