1.はじめに 2022/04/21(木)と 22(金)に開催された、DevOpsDays Tokyo 2022 にリモート参加したので参加レポートを書いた。現地参加もできたのだけど開催場所から自宅までが結構遠いので Zoom + Discord で参加した。何分不自由なく参加できたけど、強いて言えば、今半弁当を食べることができなかったのは悔やまれますね笑 https://devopsdays.org/events/2022-tokyo 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.印象に残ったフレーズや一言感想 3-1.価値あるソフトウェアをすばやく届けるために僕らがやってきたこと 〜経営者による組織とカルチャー作り〜 印象に残ったフレーズ 文化は北極星 暗黙知から明文化 目的のない雑談 ジョイ・インク 好きなことをとことんやる How to start a movement| TED 一言感想 印象に残ったフレーズが多々あるけれど、感想として自分の考えも残すとしたら、「評価と査定の分離」の話 ブログを書くことは評価にはつながらず、ブログを書くことで結果的に仕事もできるようになり、巡り巡って評価につながる。日の目を見ない期間が多い印象はたしかにある。 ブログにかぎらず、日々の活動のモチベーションの厳選をおカネや評価にといった外発的なものではなく内発的にできるかどうか？が大事だと感じた。 3-2.ファクトから始めるカイゼンアプローチ ～「Lean と DevOps の科学」を実践して～ 一言感想 「software process improvement (SPI) / ソフトウェアプロセス改善」という言葉を初めて知った 登壇者様曰く、ソフトウェア界の料理研究家といえるとか 参考文献を挙げていただいた。注意点としてそのまま使うのではなく、自社の現状に合わせて手を加えていったとのこと。 Accelerate DevOps capabilities | Google Cloud 2021 Accelerate State of DevOps report addresses burnout, team performance The DevOps Handbook 調査結果をもとに不足している capabilities を見つけるうえで参考になった cf. 3 つの道、バリューストリーム 3-3.作る人から作りながら運用する人になっていく 一言感想 How SRE Relates to DevOps テストピラミッドとコンシューマ駆動契約という考え方を知った 改めてセッションをふりかえると、開発主体から開発も運用もというスタンスの移行の建前として、組織全体で知見を獲得したいといった「取り組みの成否にかぎらない」大義が用意されていると、比較的新しい取り組みの一歩を踏み出しやすいのかもしれないと感じた。また、実行部隊の規模が大きくなるとそういった大義を掲げることも難しいはずとも。 3-4.コンプライアンス対応をチームの力に ~ 監査人が考える今後の DevOps 一言感想 監査チームのような、開発、運用業務をしているとあまり接点がすくなりがちな方々と日頃から意見を交わすことは大事。とはいえ、意見交換しようとなるのも難しく感じてしまう笑 ChatOps いいね！という監査の方から見た意見が印象的。「このチャンネルを見れば余計なことはしていないとわかるんです。」と言えるのが ChatOps のいいところとのこと。 他に印象に残ったところは、デプロイメントパイプラインの権限整理とコンプラ対応を設計する上で競合他社を反面教師とするというところ 3-5.レガシーなシステムをリプレースした後に起きた開発組織の変化について 印象に残ったフレーズ お伺いマラソン このセッションは、お伺いマラソンに形容される、相互依存でありモノリシックなレガシーアーキテクチャの移行前、移行前夜、移行後と時系列に分かれてお話されていて、とてもわかりやすかった。 一言感想 Python2 系で作っていて、GCP が日本に展開する前からローンチしていたところからの移行。これだけでヤバそうということはわかる。 ビザスクでは、2012 年創業以来、GCP(GAE) + Python2 の構成で、ナレッジプラットフォームという概念を広めるために様々な試行錯誤を繰り返しながら、サービスを拡大していきました。 ...

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.9で確認された WARNING を回避するためには、左記の issue の コメント に記載されているとおり、aws_s3_bucket resource にすべて詰め込むのではなく、設定したい内容に応じて別に resource を定義する必要がある。 ...

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 > .secretlintrc.json { "rules": [ { "id": "@secretlint/secretlint-rule-preset-recommend" } ] } EOF ところで、SecretlintをGitHub Actionsのワークフローで使うメリットはなんだろうか？ メリットのひとつは、Secretlintの開発者であるazuさんの、 SecretlintでAPIトークンや秘密鍵などのコミットを防止する | Web Scratch で記載されている、一度きりのチェックだと継続的なセキュリティは担保できない という点であろう 一度きりのチェックだと継続的なセキュリティは担保できないので、CIやGitコミットフックなどでプロジェクトに導入する方法を紹介しています。 また、個人環境のグローバルなGitコミットフックに常にSecretlintのチェックを入れることもできます。 ...

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. ...

1.markdown/マークダウンファイルをそのまま平文で表示するデモ 百聞は一見に如かず。ということでその様子を GIF で用意した。 2.どんなときに役に立つのか？ markdown ファイルをそのまま表示したいときってどんなときか？ たとえば、こんなときに使えるのではないだろうか。 ソースコードのある箇所を行単位でハイライトをつけるように markdown ファイルでも強調したい。 書きっぷりを markdown 形式で確認したい e.g.いいかんじの Mermaid 記法を見つけたけどこれどうやって書いてんだ！？ 3.どうやるのか？ Github 上で markdown ファイルを開いてから URL の末尾に以下を追加するだけ！ ?plain=1 すると、冒頭の GIF 動画のように markdown のまま表示される。 やってみよう！ 対象の markdown ファイルの URL https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md markdown ファイルの URL の末尾に "?plain=1" をつけると、、できた！！ https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md?plain=1 一般的なファイルのように行単位でハイライトをつけることもできるぞ！ https://github.com/gkzz/serverless-aws-budget-alerts-to-slack/blob/main/README.md?plain=1#L5:L11 4.おまけ 記事を公開してまもなく、今回ご紹介したマークダウンファイルをマークダウン形式のまま表示する方法ですが、raw とも違うのねとコメントいただきました。 たしかにちがうぞ！！（言われて気がついた。raw の場合、プレーンテキストとして出力しているかんじ。） 2022/03/07 更新 Github の GUI からでもできるよ！と教えていただいた。丸で囲んだボタンを押すと、この記事で紹介している ?plain=1 と同じようにマークダウンをマークダウンのまま表示できる。 ...