会社員でないアプリケーションエンジニア フルリモートワーク4年間の振りかえり
書きたいこと
2020年4月から丸4年、複数企業でフルリモート勤務をしていた。
2024年4月からは完全出社リモートワークなしに戻さざるを得なくなり、フルリモート生活が完全終焉するので振り返りを書いておく。
ここでいうフルリモートワークとは
初日と最終日以外は在宅で終日リモート勤務、必要な時だけ単発出社のことを指す。厳密に言えばフルリモートではないが容赦願う。
用意したもの
ネット環境
元々Wimaxを利用していたので、新規に用意することがなかった。リモートワークでは1月で 80G近く通信していたので、帯域制限が少ないサービスが良いと思う。
Wi-Fiで回線が細いと、リモートデスクトップで画面がガタ付きストレスになりやすかった。
Wi-Fi不調時のため、テザリングも用意しておいた方が安心。
1人で仕事できる自宅の密室
勤務規定で概ね求められる。ミーティングで業務情報を扱うので、同居人や近所に音が漏れないことが必須である。サテライトオフィスも論外だ。
私の場合、実家が一軒家で子供時代の部屋と机が残っていたので、使うことにした。
机と椅子
1日8時間は机に座るので、姿勢を崩さないよう整備した方が良い。私の周囲ではゲーミング椅子を購入した方もいた。
下手な椅子に座ると、首が痛くなり仕事にならない。
布団と毛布
仕事部屋に置いておくと、昼休みの休憩時に仮眠したり、防寒になるので便利だった。
モニタ
モニタ貸与まで申し出てくれる企業はほぼない。FigmaやExcelはノート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
- Cloud9にAmplify CLI をインストール
- AWSコンソールからAWS Amplifyを利用 (Amplify Studioを利用)
- 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ハンズオン
留意点
問題の回避のため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ハンズオン
ハンズオンでは下記を一通り実施
- Figmaでレイアウトを作る
- AWS Amplify StudioでFigmaを読み込む
- AWS Amplify Studioでデータモデルとアプリケーション動作用のデータ(seed)を作成
- Reactコンポーネントを
amplify pullでGitリポジトリにダウンロードする - 作成したReactコンポーネントを使って開発する
amplify publishでAmplifyにデプロイ
LT
感想
- Amplify StudioはFigma連携が便利
- 開発の流れが変わる
- セキュリティとAWSのリソース管理は気を配る必要があると思う
- Amplifyにソースコードの変更をFigmaに反映する機能がなさそうなので、Figma で最初にデザイン→Reactコンポーネントに反映が前提になりそう
- テストの流れが変わる
-
amplify publishの前にはローカルで動作確認しよう、と思ったけど、不要かも？
-
- セキュリティ担保どうする
- https://github.com/renebrandel/amplify-homes/blob/master/amplify/team-provider-info.json これはソースコードにpushしていいのだろうか...
- そもそもCognitoを使うかなど、セキュリティには要注意かもしれない
- Amplifyで作ったリソースの管理は
- 疑問はちょうどLTで解決できた
- 大規模になってきたので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本ほどの開発を入社前にやりました。 卒業研究と合わせて苦悩していました。
大学は数学系研究室で代数はバッチリだったので、自分含め周囲の就職内定者はRDBとSQLは余裕でマスターしてました。問題は言語だ。ここでJavaを選んでしまった私は今でも呪われているかもしれない。
当時はMySQL 5.1でした。
データベースの研修は、MySQLをzipダウンロードしてきてパスを通してmysqldとmysqlをコマンドプロンプトで起動するところから始まり、テーブル設計、SQL、JDBCまでやりました、結構当時としては詰め詰めな教育だったと思います。
個人ではオライリーの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でした。
OracleとMySQLはなんか両極端に見えますが、社内にMySQL得意な人がいたので、RDBはMySQLを使う文化がありました。それ以外も社内は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とデータベース設計は勉強と実践が結果に出るので、仕事で役に立っています。
2014年後半〜2016年前半
2014年9月にWeb系の開発会社に転職して運用部隊に配属になりました。
運用部隊はこの会社独特の組織で、今で言うところのSREに開発を兼ねる部署で、10年20年運用しているシステムを扱うのが特徴でした。あと全社的炎上ハンターもたまにやらされた。
Web系の会社なのでMySQLとPostgresSQLを多めに扱うようになり、Javaからはほぼ隠居してました。 MySQLは関係ありませんが、 この頃からJavaコミュニティの勉強会に参加するようになりました。元後輩とDBFluteフェスにも行ったのですが、その頃はまだDBFluteを実践投入していませんでした。
運用開発主体だったので、性能改善に取り組むこともあり、性能の出るSQLはRDBによって全然違うことを学びました。 アルゴリズム改善、SQL改善、インデックス付与でレスポンス20分を3秒にした時は感動したなあ。
2016年後半〜2021年
2016年の前半にフラっと会社員を辞め無所属になりました。 それ以降参画OKいただける案件は、何故か軒並みMySQLです。 MySQLの腕で採用されたわけではないのですが、自分が興味を抱く方向に何故かMySQLとMySQLに詳しい方がいます。
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に関係ない運用ノウハウとして読みたい。読みかけ。
これも積読なので消化したい
今後
2022年の2月からは技術サポート職に参加します。
面接時『MySQL以外本当に経験ないんですか』と聞かれましたが、ここ数年私の向かう道ではRDBはMySQLです。PostgresSQLとOracleはかなり勉強し直さないと使えないので経験なしと考えています、と答えるしかありませんでした。ぶっちゃけ私の頭ではサポート職は無理です
当面はDBAよりローコード開発やフロントエンドとバックエンドのアーキテクトが主体になりそうです。
どうなることかわかりませんが、私がエンジニアである限りMySQLとの関わりは切れそうにありません。 どこかで見かけた時には見守ってやってください。
最後までお読みいただきありがとうございました。良いお年を。
AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Grafana
目的
AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Grafana - connpassの復習
ハンズオン資料
https://github.com/harunobukameda/Amazon-Managed-Service-for-Grafana/
「AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Grafana」でお話しました。
ハンズオンの復習
Amazon Managed Grafanaの特徴
X-RayやCloudWatchと連携できる
Amazon Managed Grafana | フルマネージド Grafana データの可視化 | Amazon Web Services
今回のハンズオンではCloudWatchを利用
作ったAWSリソース
Amazon Managed Grafanaの認証
User authentication in Amazon Managed Grafana - Amazon Managed Grafana
今回のハンズオンでは下記の理由からAWS SSOを利用
作ったものの構成
- AWSリソースのログやメトリクスがCloudWatchに連携される
- GrafanaのData sourceとしてCloudWatchを利用
あまりメトリクスがない。先週のハンズオンで作ったRDSやLambdaのメトリクスが辛うじて見られる程度
ハンズオンで得た知識
- Make Adminのmakeが使役動詞の場合、管理者に『なる』という意味になる
- AWS SSOに料金はかからない
- Azureだと Amazon Managed Grafanaと連携できる
- Grafanaは様々なData sourceがある
- Data sources | Grafana Labs
- ServiceNow などもある模様
プラグインは結構色々あるのね。ServiceNowもこっちの方が使えそうかも#awsbasics pic.twitter.com/wiawAgP4nW
— もつ@地学部天文班インフラエンジニア (@ad_motsu) 2021年10月9日
- 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/
ハンズオンの前に
イベント宣伝
LT
ハンズオンの復習
作ったAWSリソース
- Cloud9
- RDS (MySQL) に接続するため
- Secrets Manager
- RDS ProxyがRDSに接続するための情報を管理するため
- RDS
- RDS Proxy
- Lambda関数
- MySQLに接続するコードはNode.jsを利用
- 接続処理を実装するのは意外に手間なので、事前に用意されたzipをアップロードした
- VPC
- デフォルトVPCを利用
作ったものの構成
Cloud9は省略
- Lambda関数 -> RDS Proxy -> RDS
- 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のデメリット
- 課金注意
- ピン留めといって、コネクションプールが特定のDBクライアントに固定されてしまう現象がある
設定上の注意
- 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を実運用するときは、アーキテクチャや開発運用に注意しないと大変
- バッチのように単発で起動する関数でない限り、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
- 『E メールで PDF 版請求書を受け取る』『請求アラートを受け取る』にチェックを入れておく
- 無料利用枠の使用アラートを受信する のメールアドレスを入力
- 設定の保存を押す
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シリーズ
- CodeCommit
- CodeBuild
- CodePipeline
- CodeDeploy
- ビルド成果物のデプロイを行う。デプロイ先はAWS以外も選択できる
- CodeStar
クラウドIDE
S3
- CodeBuildで作成した成果物を保存
CloudFormation
明示的に利用しないので構成図にはないが、CodeStarでリソースを作成するとCloudFormationが利用されていた
前半： 準備＋CodeStarでリソースを作ろう
CodeStarの利用
AWS CodeStar のセットアップ - AWS CodeStar
前提
『ステップ 3: ユーザーの IAM アクセス許可を設定する』に書いてある。
ハンズオンではAdministratorAccess管理ポリシーを持つIAMユーザで操作した
サービスロールの作成
初回はサービスロールの作成を求められる。これで開発者の代わりにCodeStarが様々なリソースを作ってくれる
Amazonアカウントとの連携
しばらくしたら表示されなくなった。AWSアカウント作成直後などに表示されることがある模様
その他
- リポジトリの指定
- プロジェクトテンプレートを選択
- 今回はHTMLを選択
- デプロイ先のサービスはEC2
- EC2の作成
ここまで操作するとCloudFormationが必要なリソースをまとめて作成していた
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
デプロイに失敗する
参加上の振り返り
印象的なコメント
- CodeCommitに課題がないのが不便なので、CodeCommitにJIRA連携機能があるのではないか？
勉強会への取り組み方
- 仕事でないので仕事部屋にあるモニタを使わなかったが、PCのモニタがあったほうが良かった。ハンズオン資料を見ながらAWSコンソールを触ることが出来るので効率がいい
- AWSの画面キャプチャを撮るときは個人情報を載せないように注意
- IAMユーザに自分の名前などを付けなければ回避できると思う
AWSの知識
- 事前にEC2, VPC, IAM, CloudFormationの知識があったので比較的困らなかった
- AWSのリソース作成は、手動よりCloudFormationやCodeStarを使ってまとめてリソースを整理したほうが便利
- 作成忘れやミスがない
- 一括でリソースを削除できる
- EC2のデプロイが完全に自動でできるのは嬉しい。その昔はEC2でも手動で切り替えをしていた
- CodeCommitは課題やプルリクエストのマージ権限などが充実すると仕事で嬉しい
- AWSアカウントを本番と本番以外で分割する場合、Codeシリーズのリソースはどちらのアカウントに配置すると良いのだろう
ありがとうございました。
