deprecatedbasesがdeprecatedになり、代わりにresourcesを使うようになった。envフィールドがあったがdeprecatedになった。代わりにenvsフィールドが追加された。"env"というエラーが出るので、envsに変える必要がある。startを引数に指定できるメソッドがある。startはグレゴリオ暦をつかい始めた日をあらわすユリウス日を表す。引数のstartにDate::GREGORIANを指定すると、常にグレゴリオ暦で処理してくれる。いれるとinvalidな日付として扱われエラーになるが、RubyのDate#valid_date?メソッドを使って判定するとtrueが返ってくる。これはMySQLが先発グレゴリオ暦を使っているからだった*1。先発グレゴリオ暦とは、1582年から施行されたグレゴリオ暦の暦法を、1582年以前にも適用したものである。存在しないということらしい。本題だが、Rubyで1000-2-29をinvalidな日付として判定する方法がないか探してみたところ、上の結論に行きついた。ログ量、ログサイズから自分で計算してみた。ページを見ながら計算したが、請求額と合わない。AWSサポートにお問い合わせしたところ、自分の料金計算方法の認識が間違っていた。Firehoseの料金ページには以下が書かれている。取り込まれたデータの量に基づきます。倍数に切り上げた各レコードのサイズを乗算した値として計算されますつまり、どんなにログ1行のサイズが小さくても5KBとして計算される。CloudWatchに表示されているIncomingBytesは実際のログサイズであり、5KBへ切り上げ後の値ではない。結局、5KBに切り上げされると実際のログサイズで計算したよりも10倍以上高くなってしまうので、Firehoseを使うのは諦めて、FluentdでS3に直接置くように変更した。あとちゃんと料金の計算方法を把握しないとだめですね(当たり前)。Runmonday.comというとても便利なタスク管理ツールがあります。以下でも紹介記事を書きました。tech.studyplus.co.jpmonday.comは(当たり前ですが)要ログインなので、monday.comのURLをSlackに貼っても展開されません。分かりやすくて助かりました。ありがとうございます。Herokuボタンをつけているので、それを使って簡単にデプロイできます。以下の手順で取得できます。Runにデプロイしました。Runはコンテナをサーバーレス環境で実行できるサービスで、負荷に応じて自動的にオートスケール、負荷がない場合はサービスは起動されない(課金されない)といった特徴を持っています。Lambdaと似てますね。休眠状態からの起動はherokuよりは速い気がしました。あと無料枠がかなりあるのでこのツールを動かすくらいなら無料でできそうです。Run、めっちゃデプロイ簡単なんですよね。Imageの場所のURL}これだけです。これでそのコンテナにアクセスするためのURLが返ってきます。読むと分かりやすいと思います。その他monday.comのAPIがGraphQLでめっちゃ使いやすかった。クエリをテストするための画面も用意されていて素敵。Spinnakerとは、マルチクラウドに対応した継続デリバリのプラットフォームです。デプロイパイプラインの管理機能を備え、Red/Blackデプロイ(Blue/Greenデプロイ)やカナリアリリースにも対応しています。よってOSS化され、GoogleやMicrosoftを始め、様々な企業やコミュニティが開発に参加しています。アプリの高速かつ信頼性の高いデプロイのための基盤を提供します。Infrastructureとは、一度Deployをしたインスタンスやコンテナには二度と手を加えず、新たにDeployを行う場合はインスタンスやコンテナを作り直すという考え方です。driftを避け、安全かつ高速なRollbackが実現できます。デプロイは、予測可能で安全であり、必要なときに簡単にロールバックすることができます。テスト、QA、本番など、複数の開発環境にまたがる複雑なデプロイパイプラインを作成することができます。デプロイパイプラインはパラレル実行とシリアル実行に対応してますデプロイパイプラインがGUIからでしか定義できない時代もありましたが、現在は設定ファイルに定義できます。Registry」「Cron」「Git」「Jenkins」「Werker」「Travis」「Spinnakerの他のPipeline」「Pub/Sub」「Webhook」「手動」などを設定できます。highlander(既存のインスタンスに新しいコードをデプロイするTraditionalなやり方。独自のデプロイメント戦略マルチクラウド対応Spinnakerは、kubernetesに対してのCD機能が標準的に実装されているだけではなく、他のクラウドプロバイダに対してにもCD機能が実装されています。Judgments手動判断ステージでは、デプロイする前に手動の承認を必要とすることができますカナリアリリースSpinnakerを使うことで、カナリアリリースした成果物の任意のメトリクスの計測、スコア化を自動で行い、予め決めた合格点を満たすか自動判定できる。その判定をクリアした成果物だけ本番にデプロイがされ、クリアしなかった場合は、ロールバックを自動で行う。Analysis(ACA)と呼ばれていて、kayentaというソフトウェアがそれを担当している。Prometheus等々から取得できる。Spinnaker上からどのメトリクスを使うか、またそのメトリクスのしきい値(つまり合格とみなすしきい値)を設定できる。teamsを使用してプロジェクトやアカウントへのアクセスに制限をかけることができます。特定の時間のみパイプラインの実行がされるように制限することができます。Integration故意にインスタンスを終了させることによってアプリケーションが問題なく動作するかテストすることができるクラスタ管理機能Spinnakerはクラスタ管理機能も提供しています。クラスタの「サーバグループ」「ロードバランサ」「セキュリティグループ」などに対する管理操作を行えます。Spinnakerはクラスタ自体の可視化をすることができます。Datadog、Prometheus、Stackdriverなどと連携したモニタリングを行えます。これらのmetricsをカナリアリリース時に使用できます。パイプラインのテンプレートを作っておいてそれをもとにパイプラインを作ることができる。特徴としてはテンプレートをもとに作ったパイプラインは設定変更できない。テンプレートのほうでパイプラインの各フェーズで入力可能な変数を定義できる。(たとえばレプリカ数はパイプライン作成時に決めるなど)フィードバックサーバーサイドエンジニアなどでも容易に「どのようなパイプラインでデプロイされたのか」や「カナリアデプロイがなんで失敗したか」などを知ることができます。パイプライン中にカスタムステージを作成したり、UIに独自のリンクやボタンを追加するなど。日本語ドキュメントのほうは手順に抜けがあるっぽいので基本は英語のドキュメントのほうをみたほうがよさげ。gem-cache-v1https://circleci.com/docs/2.0/caching/#restoring-cacheどのようなルールでcacheが使われるかというと、上から順にkey名が先頭一致したcacheが使われます。公式ドキュメントには以下のように書かれています。cacheを使ってしまう。CIのcacheは先頭一致したkeyのcacheが使われるTweet広告を非表示にするもっと読むコメントを書く2019-06-20特定の例外をSentryに送らないようにする方法SentrySentryに特定の例外を送りたくない場合、プログラムを修正すれば済みますがそれが深淵な理由でできないOR面倒な場合、プログラム側でSentryに送らない例外を指定できます。Sentry側でignoreにできますが、たくさんの箇所で発生したりアプリケーションの更新によって別のissueとして認識されてしまうといちいちignoreするのが面倒。エラーがSentryに通知されるとエラー数を消費してしまう。Sentryは従量課金制なので困る。特定の例外をSentryに送らないようにする方法はexcluded_exceptionsとinspect_exception_causes_for_exclusionオプションです。以下のように指定します。trueendドキュメントはこちらGoではIgnoreErrors、PHPではexcluded_exceptionsではJavaScriptではignoreErrorsというオプションがあり、おそらく他の言語もそういったオプションがありそうです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。