Dockerfileのベストプラクティス Top 20
本文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日本語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ
Google Cloud の IAM で、開発体制や組織の文化に合わせて検討したこと - Hatena Developer Blog
システムプラットフォーム部で SRE をやっている id:nabeop です。システムプラットフォーム部を一言で表すと、基盤を横断的に見る部署という感じです。 過去の発表などでもたびたび言及していますが、はてなのいくつかのサービスは AWS 上で構築されており、これまで「クラウドに構築する」は「AWS で構築する」とほぼ同義な世界でした。 ただし、AWS 以外も全く使っていなかったわけではなく、小さなプロジェクトや個人では Google Cloud の利用もありました。また最近は、各サービスで技術選択の多様化が進み「Google Cloud 上でサービスを構築する」という選択肢も十分ありえる状態になってきました。 このため、各サービスで Google Cloud の利用が本格化する前に、安心して使えるように IAM (Identity and Access Management) など環境
バッチ処理をコード化するときに意識していること｜福井 烈
最近、同僚の@sunakujira(F.Shibusawa)と共にバッチ処理を書くことが多いので備忘録も兼ねてバッチ処理を書く上で意識していることを紹介したいと思います。 大きくは以下の3点を意識してます。 1. 再実行（リカバリ）する前提で考える 2. 処理の実行時間は問題ないか 3. サーバー負荷は問題ないか 今回は再実行（リカバリ）する前提で考えるに絞って紹介しようと思います。 内的要因、外的要因問わずエラーは必ず起こるものだと想定し、再実行（リカバリ）できるようにしておくことはバッチ処理の最たる要件の一つと言えるでしょう。具体的には以下を意識しています。 冪等性を考慮した設計 冪等性とは、何度実行しても同じ結果が得られることを指します。例えば、デイリーの売上を計算しDBに結果を保存するようなバッチ処理を仮定すると、冪等性を担保するためには、対象データが存在する場合に削除する処理を仕
Sidekiqで非業の死を遂げたキューを知る方法 - Qiita
前置き：Rubyのキューイングシステム Rails（Ruby）で非同期にキューイングしてくれるライブラリといえばSidekiqですよねっていうくらいSidekiqが好きなんですが、世の中のシェア的にはResqueなのかな。でも、Sidekiqの方が安定的に動かせているので僕は好きです（delayed_jobは知らない）。 ShoryukenというAWS SQSを使ったキューイングシステムもあり、RedisじゃなくてSQS使いたいっていう場合は、これも良いのかもしれないですね。まぁ、ローカルの場合面倒そうな感じもありますけど。 phstc/shoryuken まぁともかくSidekiqを導入してキューイングするっていうのは、もう超絶簡単にできるわけです。できるんですけど、実際にラフに運用していくと、キューがいつの間にかこけて処理待ちで埋まってたり、レアなケースで例外投げて死んでたりするわけで
ちょっと待ってください!あなたが使うべきは本当にT系インスタンスですか!? | DevelopersIO
同一のスペックだけど､t3.largeの方が僅かに安いですね｡なのでt3.largeを使おうと思った方!! ちょっと待ってください!! 以下の条件全てに当てはまるなら､最初からT系インスタンスは使わないでください! 初めてAWSを使う 本番環境である 一般公開するシステムである(社内向けシステムではない) また､いずれかに当てはまりT系インスタンスを検討されている方には必ずこのブログを読んで頂きたいです｡ このブログはAWS熟練者が本番環境や一般公開するシステムでT系インスタンスを使うことを否定するものではありません､あくまでもAWS初心者に向けた内容です｡ バースト可能パフォーマンスの選定 まずT系インスタンスはバースト可能パフォーマンスインスタンスと呼ばれます｡ AWSのドキュメントを確認して見ましょう｡ バースト可能パフォーマンスインスタンス T3および T2 インスタンスを含むバー
【AWS】バースト可能インスタンスについて - Qiita
バースト可能インスタンスとは ・AWSのインスタンスt2とt3・t3aに存在するシステム ・あまりCPUを必要としないサーバや、たまにしかCPUを使わないサーバの場合にこのインスタンスタイプにする ・このシステムを使ってるインスタンスは安い バースト可能インスタンスの詳しい説明 CPUを使わないときに「クレジット」と呼ばれる通貨みたいなものを貯めておき いざCPUを使いたいとなったときにその通貨を支払って100%のパフォーマンスを出すことができる t2、t3・t3a以外のインスタンスは普通に100%のCPUを使うことができるが料金が高い 仕組み CPU100%の状態を1分間続けると1クレジット失われる（全インスタンスタイプ共通） （例えば20%の状態を1分間続けば1/5クレジット、2分間続くと2/5クレジットが失われる） 逆に起動している間、常にクレジットは回復していく インスタンスによっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
