Posts

1.この記事を書こうと思った背景 AWS Certified Solutions Architect Professional Exam(SAP-C01 / AWS認定ソリューションアーキテクト プロフェッショナル, 以下SAP試験とする)を自宅で受験して合格した。 スコアは773と、合格点が750なのでギリギリだった。なお、模擬試験の問題集の相性の兼ね合いやドキュメントの多さを考慮して英語で受験している。 2.受験しようと思った動機 SAP試験を受けようと思ったモチベーションは、AWS に関して体系的な知識を身につけ、いざググろうとなったときの助けとなるインデックスを脳内に貼っておきかったからだ。 たとえば、弊社のAWS環境においてAWSリソースにアクセスする仕組みを理解するためには AssumeRole という AWS が提供する権限付与の IAM の機能に関する知識が求められる。ここで業務に取り掛かる際に AssumeRole がなんたるか？の一般的な知識がアタマに入っていれば、だいぶラクなんだろうな〜と歯がゆい思いをすることがあった。 目的のAWSアカウントにはAssumeRoleを利用して切り替えます。 認証用AWSアカウントに誰がどのアカウントに切り替えてよいかを定義しておき、それに基づいて切り替え可否を制御しています。 出所：AWS + Azure ADによるSingle Sign-Onと複数AWSアカウント切り替えのしくみ作り - Cybozu Inside Out | サイボウズエンジニアのブログ もちろん試験に合格してもすぐ役に立つということはないのだろうけど、受験がインプットしてのわかりやすいターニングポイントとなってくれたことは間違いないと感じる。 3.試験対策の検討方法について 日本語受験の方は、「AWS SAP 合格」などでググるのがいいと思う。 英語受験の方は、reddit で aws sap などでググるとアドバイスが見つかるのでおすすめ! https://www.reddit.com/search/?q=aws%20sap 4.試験当日までの勉強方法 受験日の4ヶ月前に受験を決意してから3ヶ月くらい前まで 試験ガイド(AWS Certified Solutions Architect - Professional Exam Guide)を一読 AWS Certified Solutions Architect - Professional Certification | AWS Certification | AWS 以下の参考書を1周 AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル : 山下光洋 以下の Udemy の講座で配布されるPDF資料を一読しながら1問1答だけやる Ultimate AWS Certified Solutions Architect Professional 2022 | Udemy 以下の Udemy の模擬試験4回セットのうち1回を解き、難しさに絶望し、長期戦を覚悟する（1ヶ月もあれば終わるだろうと思っていたらとんでもなかった） AWS Certified Solutions Architect Professional Practice Exam | Udemy 3ヶ月くらい前から当日まで Redditで評判がよさそうだった、以下の模擬試験セットのうち、4回分と分野別の問題集をひととおりやる AWS Certified Solutions Architect Professional | whizlabs 模擬試験としては全5回だけど、準備期間が足りず4回しかできず ただし、ふりかえると模擬試験を一周するより、既に解いた問題の解き直し、解説や自分でまとめたメモの見直しなど復習に時間をかけた のが今回の合格の決め手になった感じはする ↑の問題集を解いて復習していくのと併せて、Udemyの模擬試験2回分も解いていく Udemy の模擬試験は全4回だが準備期間が足りず、1回分解いていないが、こちらも復習を優先した。 当日が近づくにつれ、これまで解いた模擬試験やAWSが提供するサンプル問題や模擬試験の問題と解説、自分でまとめたメモの読み直しの時間を増やした 1週間前に AWSからサンプル問題と模擬試験が無料で配布 されていることに気が付き、急いでやる AWS Certified Solutions Architect - Professional Certification | AWS Certification | AWSでサンプル問題と模擬試験が配布されている サンプル問題：AWS Certified Solutions Architect - Professional Sample Questions 模擬試験：AWS Certified Solutions Architect - Professional Official Practice Question Set ※ 受験日を決めたのは1ヶ月前。模擬試験の演習の手応えを感じたためというより、これ以上後ろにずらすことができなかったため受験日を決めた。...

1.はじめに 2022/04/21(木)と22(金)に開催された、DevOpsDays Tokyo 2022にリモート参加したので参加レポートを書いた。現地参加もできたのだけど開催場所から自宅までが結構遠いのでZoom + Discord で参加した。何分不自由なく参加できたけど、強いて言えば、今半弁当を食べることができなかったのは悔やまれますね笑 https://devopsdays.org/events/2022-tokyo メールにセッション視聴URLが送られてきていたのでそちらから視聴中#DevOpsDaysTokyo — gkzz / Gakuji Tamaki (@gkzvoice) April 21, 2022 2.聞いたセッション Day1 (2022/04/21(木)) 10:30 (KEYNOTE) | 価値あるソフトウェアをすばやく届けるために僕らがやってきたこと 〜経営者による組織とカルチャー作り〜 13:00 | ファクトから始めるカイゼンアプローチ ～「LeanとDevOpsの科学」を実践して～ 14:00 | 作る人から作りながら運用する人になっていく 資料のリンク 15:00 | コンプライアンス対応をチームの力に ~ 監査人が考える今後のDevOps 16:00 | レガシーなシステムをリプレースした後に起きた開発組織の変化について 資料のリンク 17:00 | CI/CDパイプラインにE2Eテストを統合する 資料のリンク Day2 (2022/04/22(金)) 11:00 (KEYNOTE) | Chris Lucian: Interview with Q&A 13:00 | Flaky test対策の最新動向 14:00 | 食べログのソフトウェアテスト自動化デザインパターン 資料のリンク 15:00 | デプロイ頻度を高めるために私達にできることは一体何があるだろうか？ 16:00 | PagerDutyでシステムノイズを削減し、インシデントの解決を自動化する方法 17:30 (KEYNOTE) | Matthew Skelton / Alex Papadimoulis - Matthew Skelton: Interview with Q&A 3....

1.この記事を書こうと思った背景 これまで、Terraform AWS Provider のバージョンを3.7系から4.x系に引き上げようとすると以下のissueで取り上げられているような、 aws_s3_bucket resourceでエラーとなっていた。 S3 bucket issue: Can’t configure a value for “versioning” #23125 このエラーは、Terraformの以下のガイドに記載されているとおり、aws_s3_bucket resourceの大規模な仕様変更が入ったことに起因する。 Version 4.0.0 of the AWS Provider introduces significant changes to the aws_s3_bucket resource. See S3 Bucket Refactor for more details. 出所：Terraform AWS Provider Version 4 Upgrade Guide ところが、AWS Provider 4.9に引き上げるとエラー判定とされなくなっていた、、！？ v4.0のリリース内容もびっくりだが、これもびっくりなので筆を執ることにした。 AWS Provivder 4.9.0の CHANGELOG 2.AWS Provider 4.9に引き上げるとエラー判定ではなくWARNING判定となる これまでの4.x系では aws_s3_bucket resource で3.7系までの書きっぷりをすると、エラーとしてきた 一方、4.9系ではWARNINGは出れどresourceは作ってくれた。それと明示的に修正が必要な箇所を指摘してくれる！！ ※ WARNINGが出ていて大丈夫なんですか？ という点については分かっていない。Terraform が指摘してくれた箇所の修正をしたほうがいいことは間違いないだろう。(今後のアップグレードによっては、またエラー扱いとなるというこもありうる) 修正方法はこれまでの4.x系への引き上げ時におこなわれている方法と同じであり、自分の場合の修正箇所を書いておく。 3.AWS Provider 4.9へバージョンを引き上げるまでのエラー対応(自分の場合) 冒頭で取り上げたエラーや4....

1.この記事を書こうと思った背景 昨今のニュースを眺めていると、クレデンシャル情報(シークレット情報/機密情報)漏洩対策の一環として、ガードレール的なツールを使いたい、またそういったツールを継続的に利用したいというお気持ちが一層強くなる。 そういうわけで Secretlint をはじめとするガードレール的なツールを使おうと思うのだが、SecretlintをCIパイプラインでお手軽に使う方法をひらめいたのでここに書き残しておく。なお、今回の導入対象のCIパイプラインは、GitHub Actionsとしている。というのも https://github.com/secretlint にSecretlintをNode.jsのライブラリとしてGitHub Actions上で扱うサンプルコードが公開されていることから検証のハードルが低いと感じたためである。 secretlint/secretlint-github-actions-example さて、この記事では、SecretlintをCIパイプラインでお手軽に使う方法の他に、誤検知対策としてカンタンにルールを追加する方法についても触れたい。この手のツールは誤検知が大量に作動してしまえば、そのツールはオオカミ少年と認識されてしまいかねない。それだけにSecretlintでは簡易的とはいえ誤検知対策ができるという点は、かゆいところに手が届いているといえるのではないだろうか。 2.解決したい課題とその解決策 まず、具体的な方法論について話す前に前提となる解決したい課題と、ここで提案する解決策について述べておきたい。 2-1.解決したい課題 SecretlintをGitHub Actionsのワークフローでお手軽に使いたい Secretlintを使うためにはDockerかNode.jsが必要である戦う つまり、GitHub ActionsのワークフローのなかでDockerかNode.jsのいずれかを使えるようにセットアップするJobが必要 Node.jsでSecretlintを使う場合、Secretlintのインストールが必要とやや手間 $ npm install secretlint @secretlint/secretlint-rule-preset-recommend --save-dev ルールの追加もお手軽にしたい Secretlintではビルトインのルールが提供されていないが、専用の設定ファイルの .secretlintrc.{yml,yaml,js} (以下、.secretlintrc.json) でルールを利用者側で導入する必要がある Dockerコンテナイメージの場合、推奨ルールセットである、@secretlint/-rule-preset-recommend が同梱されており、イメージをbuildするだけでok https://github.com/secretlint/secretlint#using-docker @secretlint/-rule-preset-recommend Node.jsの場合、上述した @secretlint/-rule-preset-recommend などを.secretlintrc.json で指定し、secretlintコマンドを実行するディレクトリに配置しておかなければならない https://github.com/secretlint/secretlint#using-nodejs # Dockerコンテナイメージを使う場合、Secretlintのインストールは不要 # `.secretlintrc.json　もイメージに同梱されている # ルールを追加したい場合、自分で用意する必要があり、その方法は後述 $ docker run -v `pwd`:`pwd` -w `pwd` --rm -it secretlint/secretlint secretlint "**/*" # Node.jsの場合、以下のコマンドで .secretlintrc.json を生成する必要がある $ npx secretlint --init # .secretlintrc.json はsecretlintコマンドを実行するディレクトリに配置する必要がある $ cat <<EOF > ....

1.この記事を書こうと思った背景 Github Actionsでは、schedule ( schedule イベントやスケジュール実行ともいうがここでは、 schedule とする。)というイベントが用意されている https://docs.github.com/ja/actions/using-workflows/events-that-trigger-workflows#schedule 他のイベントとしては、push や workflow_dispatch などがある scheduleは、POSIX 規格の crontab の構文 で表記するのだが、日時の条件指定と曜日の指定はAND判定されるかと思いきや、OR判定されるようだと分かり、Github feedback や Support などで問い合わせた 問い合わせた結果、丁寧に教えていただいたので共有したい [bug] Schedule event’s multiple conditions are judged by OR conditions, not AND conditions #12804 日時の条件指定と曜日の指定のAND判定というのは、たとえば、第1月曜日の午前2:00に schedule を実行したい場合、下記のような書き方を指している(ただし、この書き方ではAND判定とならないので要注意！) on: schedule: - cron: '0 17 1-7 * 1' 2.長いので結論を書く Github Actions の cron で採用されている POSIX 規格の crontab の構文 では日時と曜日が指定されている場合、日時と曜日のOR判定となることが正しい if either the month or day of month is specified as an element or list, and the day of week is also specified as an element or list, then any day matching either the month and day of month, or the day of week, shall be matched....