コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能
コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能 Dockerコンテナで使われるコンテナイメージは、そもそもOSのカーネルなどが含まれていないためそれ単体で実行することはできず、コンテナに対応したOSの上にデプロイすることで実行されます。 このコンテナイメージのフォーマットは業界標準の「OCIコンテナ」（Open Container Initiativeコンテナ）として標準化されていますが、このOCIコンテナのフォーマットを守りつつ、ベアメタルサーバ上でブート可能な「ブータブルコンテナイメージ」の開発が進められています。 ブータブルコンテナイメージとは？ ブータブルコンテナイメージは、カーネルやデーモンなどの単独で実行可能なOSとしての
TypeScriptのGenericsで部分的型推論を行う
TypeScript では部分的型推論が出来ない TypeScript では部分的型推論が出来ないというのは、Generics の使い方に制限を与えてしまう問題です。例えば、上記のコードでは func 関数に対して一つ目の引数だけ number 型を指定したい場合、残りの引数の型も明示的に書かなければなりません。しかし、これは冗長であり、型安全性も損なわれる可能性があります。なぜなら、引数の型が変わったときに、Generics の型も一致させる必要があるからです。 部分的型推論が出来ればこのような問題を回避できまが、TypeScript では以下のような状態です。 const func = <A, B, C>(a: A, b: B, c: C): [A, B, C] => { return [a, b, c]; }; func(1, "2", 3); // OK func<number>(
新しいBuildKitでのイメージのリベースとリモートキャッシュサポートの改善 | Docker
BuildKit Builder エンジン、Dockerfile 1.4 フロントエンド、 Docker Buildx CLI の新しいバージョンをリリースしました。これらのそれぞれには、多くの新機能が付属しています。 このブログ投稿では、そのうちの1つであるDockerfilesの新しいコピーモードを示し、Dockerfilesでそれを使い始める必要がある理由を説明します。 Dockerfile 1.4 リリースでは、ビルドコンテキストまたは別のステージからファイルをコピーするためのコマンド ADD とコマンドが、 COPY 新しいフラグ '–link' を受け入れるようになりました。このフラグを使用すると、キャッシュ セマンティクスが大幅に向上し、新しい基本イメージの上にビルドを再構築せずに 2 日目の高速リベースを実行できます。 このフラグを使用するには、Dockerfile の先頭
AWS CodePipeline でステージレベルの手動および自動のロールバックをサポート
AWS CodePipeline V2 タイプのパイプラインでステージレベルのロールバックのサポートが開始されたので、本番環境に確実に変更をデプロイできるようになりました。あるステージで何らかのアクションが失敗したためにパイプライン実行が失敗した場合、そのステージで以前に成功したパイプライン実行にロールバックすることで、そのステージをすぐに既知の良好な状態に戻すことができます。ソースステージを除き、成功か失敗かにかかわらず、どのステージでも変更をロールバックできます。 コンソール、API、CLI、または SDK から手動でステージのロールバックを開始することも、失敗したら自動的にロールバックを選択するようにパイプライン定義内でステージを設定することもできます。ロールバックが開始すると、新しいパイプライン実行がそのステージから開始し、選択したパイプライン実行からの変更が適用されるか (手動ロ
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました | CyberAgent Developers Blog
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました CTO統括室の黒崎(@kuro_m88)です。本日早朝に面白そうな発表を目にしました👀 AWS CodeBuild now supports managed GitHub Action runners AWS CodebuildがGitHub Actionsに対応したという内容ですが、要するにAWSがホストするGitHub Actions Runnerが出たということですね🎉 AWSがマネージしてくれることで、EC2(x64, arm)はもちろん、GPUとカスタムイメージも利用できるようです。 さらに注目したのはGitHub Actions RunnerとしてAWS Lambdaが使えるようです。Lambdaが使えると嬉しいポイントはActionsのjo
Node.js + TypeScriptのモジュールを整理してみる
はじめにlink 最近受けるNode.js + TypeScript環境の相談の中で、CommonJSやECMAScript Modulesのあたりで落とし穴にはまっている人が多いという事に気づいた。 Node.jsは歴史的にCommonJSとECMAScript Modules（以後ESMと表記）がどうしても入り乱れる環境にあり、これにTypeScriptのモジュールが加わると組み合わせでさらに複雑度が増すのが現状である。 説明する際に口頭より整理した文章が欲しいと思ったので記事にする。 以下のリポジトリで検証コードを管理している。 https://github.com/koh110/module_test Node.jsモジュールチェックシートlink まず最初にNode.jsにおけるCommonJSとESMの挙動について整理する。 いきなり書かれても把握できないかもしれないが、一旦こ
RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media
この記事について みなさん、ECS利用していますか！？ AWSでコンテナを使うのなら、ECSですよね！?(kubernetesわからない勢) ECSはタスクという単位で、アプリケーションを実行させます。 そして、タスクの中にコンテナが１つ以上稼働します。 タスクはタスク定義から作成されます。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル（以後taskdef.json)として運用することが一般的です。 このtaskdef.jsonを実運用する際に迷うポイントがあります。 それは以下のどちらの方法にするかです。 – 方法① : 各環境ごとにtaskdef.jsonを用意する – 方法② : 各環境でtaskdef.jsonを共用する ①,②について、それぞれの詳細/メリット・デメリットについて洗い出しをして、どちらを採用すべきかについての見解を述べていきます。 あく
![[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media](https://cdn-ak-scissors.b.st-hatena.com/image/square/44fc1474c22e3382588fd4b15ee70ff7f704163b/height=288;version=1;width=512/https%3A%2F%2Firet.media%2Fwp-content%2Fuploads%2F2021%2F07%2Fimg-eyecatch-aws-02-1200x630.png)
TypeScript 4.9 の "satisfies" 演算子で union の網羅性チェックが少し楽になる - Qiita
TypeScript 4.9 で新たに導入される satisfies 演算子にとても期待しています。個人的に役に立ちそうだと思ったユースケースとして、switch や if で union を順番に処理していくときの網羅性チェックが挙げられます。 declare const difficulty: "easy" | "medium" | "hard"; switch (difficulty) { case "easy": case "medium": case "hard": break; default: // OK throw new Error(difficulty satisfies never); } switch (difficulty) { case "easy": case "hard": break; default: // Type 'string' does not
Array.filter ← これで型が絞れるようになるらしい
const fruits = ['Apple', 'Banana', undefined] const result = fruits.filter(x => x !== undefined) // const result: (string | undefined)[] console.log(result) // ['Apple', 'Banana'] このように、resultという変数にundefinedがない状況でもfilterを使用した場合は型が絞られませんでした。 Javascriptに慣れてきて、TypeScriptに足を踏み入れた頃は本当にここで躓きました、、 それが近い未来、変わるかもしれません。 これからのfilter const fruits = ['Apple', 'Banana', undefined] const result = fruits.filter(x
Amazon Timestream for InfluxDB is now generally available
Today, AWS announces the general availability of Amazon Timestream for InfluxDB, a new time-series database engine. Timestream for InfluxDB makes it easy for application developers and DevOps teams to run fully managed InfluxDB databases on AWS for real-time time-series applications using open-source APIs. In minutes, you can create an InfluxDB database that handles demanding time-series workloads
コスト削減成功！Amazon Auroraの監査ログをS3に保存する仕組みを構築した話 - Classi開発者ブログ
こんにちは。プロダクト本部Growth部でエンジニアをしている id:ruru8net です。 前回はこちらの記事を書かせていただきました。 tech.classi.jp 今日は前述したSRE留学中にやったことの中の「Amazon Auroraの監査ログをCloudWatch Logsを経由せずS3に保存する」を紹介したいと思います。 前提 前掲の記事にもある通り、弊社のAWSにかかっているコストを調査したところCloudWatch Logsの特にAmazon RDSの監査ログの保存にコストがかかっていることがわかりました。今回は弊社で最も使用しているAmazon AuroraのMySQLのみを対象として、監査ログをCloudWatch Logsを経由せずS3に保存する仕組みを作成しました。 作成した仕組み こちらのオープンソースの仕組みを参考に構築、またLambdaのソースを使いました。
大テーブルと小テーブルのJOINのコスト計算の話 - amamanamam
先日MySQLアンカンファレンスでhogeさんの以下の発表を聴かせていただいた。 www.docswell.com 100万行×3行のJOINが全検索でhash joinになり、後者の行数を増やして100万行×10行にするとeq_refになる現象を紹介いただいた。 自分の環境でも同様の現象を再現できて、オプティマイザトレースの内容やコスト計算の過程が非常に興味深かったので、色々調べてみたことを垂れ流してみる。 環境 mysql> select version(); +--------------+ | version() | +--------------+ | 8.0.28-debug | +--------------+ 1 row in set (0.00 sec) mysql> desc mytable; +---------+--------------+------+-----
Amazon S3 へのファイルアップロードで POST Policy を使うと、かゆいところに手が届くかもしれない - カミナシ エンジニアブログ
はじめに こんにちは。カミナシでソフトウェアエンジニアをしている佐藤です。 みなさんは、アプリケーションのフロントエンドから、Amazon S3 にファイルをアップロードするときに、どのような方法を用いているでしょうか？ 「バックエンドのサーバーにファイルを送信し、バックエンドのサーバー経由で S3 にアップロードしている」「Presigned URL を払い出して、フロントエンドから直接 PUT している」など、いくつかの方法があると思います。 弊社で提供しているサービス「カミナシレポート」でも、用途に応じて上記の方法を使い分けて S3 へのファイルのアップロードを行っています。 特に、Presigned URL は、手軽に利用できる上に、バックエンドのサーバーの負荷やレイテンシーの削減といったメリットも大きく、重宝しています。 一方で、その手軽さの反面、アップロードに際して様々な制約を
アルパカでもわかる安全なPodの終了
これはなに KubernetesにおいてPodが終了するまでの動作を整理します。また、それを踏まえて、安全に（リクエストの欠損を極小化した）Podを終了する方法を考察します。 アプリケーションとしては、HTTPリクエストを受けてレスポンスを返却する、一般的なWebアプリケーションを想定します。 📘【note】 この記事の内容は、@superbrothersさんによる詳解 Pods の終了と公式ドキュメントが元になっていますのでぜひそちらも参照ください。この記事は 2020/09/23 現在の最新版のKubernetes で内容を再確認するとともに、図を足したり、解説を増やしたりしています。 目次 Podが終了する過程 安全なPodの終了のために注意すべきこと Podが終了する過程 コンテナイメージの更新や kubectl delete pod の実行など、Podの終了のトリガーとなる事象
Postfix から SMTP endpoint を使わずに Amazon SES 経由でメールを送る - ngyukiの日記
Postfix から Amazon SES 経由でメールを送る場合、通常であれば SMTP credentials を作成したうえで Postfix から Amazon SES の SMTP endpoint へリレーを設定します。 Amazon SES とPostfixの統合 - Amazon Simple Email Service Classic が、やんごとなき理由によりこの方法が使えなかったときのために Postfix から SES API の SendRawEmail でメールを送信してみました。 master.cf で ses トランスポートを定義する master.cf に次のように追記して sqs トランスポートを定義します。 sqs unix - n n - - pipe null_sender=MAILER-DAEMON@example.com user=nobody
Re: WebサーバーアーキテクチャとPHP実行方式の理解から始めるphp-fpmとはなにか？
この記事のモチベーション 「php-fpmとはなにか？」を知るため、PHPのドキュメントを見ました。 しかし、ここに書いていることはまあそうなのですがあまりに焦点が絞られ過ぎてて「php-fpmとはなにか？」に対する答えとしては少し不十分な気がしていました。 例えるなら数学の問題に答えるにあたって、途中式を飛ばしたり証明の過程を飛ばしたりというような感じ。 不十分というのは、それを理解するための段階をすっ飛ばして答えだけが書かれている状態のことを指しています。 その不十分なところを自分も曖昧にしか理解できていない気がしており、いい機会なので整理しておこうというのがこの記事のモチベーションです。 そのためこの記事は、「php-fpmとはなにか？」をプロセス→Webサーバー→実行方式と順を追って説明していく構成になっています。 「細けぇこたぁいいんだ、おらぁ今すぐ答えだけ知りてぇンダ」という方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DMMプラットフォームで発生したノイジーネイバー問題に対してのSLI/SLOを検討した話 - DMM inside
Ignore Unparseable JSON with jq