製品 Docker Desktopアプリケーションのコンテナ化Docker Hubコンテナー イメージを検出して共有するドッカースカウトソフトウェアサプライチェーンの簡素化Dockerビルドクラウド イメージのビルドを高速化Testcontainers デスクトップ 実際の依存関係を持つローカルテストTestcontainers クラウド クラウドで制限のないテスト 製品ロードマップを見る開発者向けのその他のリソース
こんにちは、かたいなかです。 『詳解システムパフォーマンス 第2版』の日本語版が2023/01/24についに発売されました! www.oreilly.co.jp 私個人は原著で読んだのですが、他の人に強くおすすめしたくなるような内容でした。そこで、日本語版の発売に合わせてどのあたりが良かったのかなど、内容をご紹介します。 TL;DR パフォーマンス改善タスクの課題感 どんな本? この本のどこがいい? Linuxの仕組みを広く深く学べる パフォーマンスの観点での情報が豊富 どんなひとにおすすめできるか? クラウドやコンテナが当たり前になってからSREになった人 Linuxの知識をアップデートしたいエンジニア 最後まで読み切るには? あせらずゆっくり読んでいく Linuxの前提知識を仕入れてから読む 終わりに TL;DR 『詳解システムパフォーマンス 第2版』は、Linuxを深く学んで仕事に活
2019-05-02 TL;DR IPVSはデフォルトでconntrack(標準のconnection tracking)を利用しない そのせいでIPVSに処理させるパケットをNATしたりすると期待通り動かないことがある 必要があれば /proc/sys/net/ipv4/vs/conntrack (net.ipv4.vs.conntrack) を設定しよう 背景 iptablesの DNAT targetと IPVS(LVS/NAT構成)を共存させると上手く行かない PREROUTING chainにおいて REDIRECT target によりポート番号をIPVSのvirtual serviceのものに変換するように設定した場合, REDIRECTされるポートに対し接続すると, 戻り通信(SYNに対するSYN+ACK)の送信元ポートがvirtual serviceのものになる(期待され
先にまとめると ディスクI/Oに高い負荷をかけるシステムでNVMeデバイスを使うときweekly cron jobでfstrimが走る状況になってたら停止しろ じゃないとfstrimが走った瞬間にI/Oパフォーマンスが刺さって死ぬ fstrimを停止するならdiscard mount optionを有効化しろ、ただしその状態でのI/O性能で問題ないかどうか測っておけ discard mount optionを有効化しても大きいファイルの削除には気をつけろ、プチfstrimみたいになるぞ 追記されるばかりで大きくなるファイル(そして削除されるファイル)はNVMeじゃないデバイスに置いとけ 高I/Oスループットを期待するシステムでのNVMeとfstrim 社内で小さめのインスタンスを多く並べてトラフィックを捌いてたのを色々要件があって大きめのインスタンスにまとめるようなシステムアップデートをや
The easy-to-use, integrated, glanceable, and open web-based interface for your servers Introducing Cockpit Cockpit is a web-based graphical interface for servers, intended for everyone, especially those who are: new to Linux (including Windows admins) familiar with Linux and want an easy, graphical way to administer servers expert admins who mainly use other tools but want an overview on individua
sparsebundlefs を使ってがんばります。 mountしたりするのでrootでの作業です。 とりあえず作業用ディレクトリへ行って、使うツールの下準備 $ git clone https://github.com/torarnv/sparsebundlefs.git $ cd sparsebundlefs $ make timemachineのsparsebundleをマウントしてdmgを見れるようにする。 $ mkdir dmg $ ./sparsebundlefs /YOUR_PATH_TO_SPARSEBUNDLE ./dmg dmgをマウントする。うまくいかない時は、parted使ってoffsetとか確認してloopインターフェス作ってマウントする。 $ mkdir tm $ mount -o loop -t hfsplus ./dmg/sparsebundle.dmg .
English version 要約 dockerはデフォルトでセキュリティ機構(Spectre脆弱性の対策)を有効にします。この影響で、RubyやPythonのようなインタプリタは速度が劣化します。特にCPU律速なプログラムで顕著に遅くなります(実行時間が倍くらいになることがあります)。 現象 Rubyで1億回ループするコードを、直接ホスト上で実行する場合と、docker上で実行する場合で実行時間を比較してみます。 直接ホスト上で実行した場合: $ ruby -ve 't = Time.now; i=0;while i<100_000_000;i+=1;end; puts "#{ Time.now - t } sec"' ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] 1.321703922 sec docker
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。本記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ
筆者について FreeBSDを通じてOSSにささかな貢献を。 日本xrdpユーザ会発起人 xrdp developer FreeBSD developer OSS活動をご支援いただける方を募集しています https://github.com/sponsors/metalefty ■ sudo vim より sudoedit を使うべき理由 Linux や FreeBSD を使っていて、設定ファイルを書き換える際に root 権限が必要な場合に sudo vi(m) や sudo emacs を実行してしまう人は少なくないと思います(「"sudo vi" 自宅サーバ」などで検索すると山ほど出てくる。昔は自分もよくやってました)。 しかし sudo で vim や emacs などのエディタを起動するべきではない理由がいくつかあります。そして、代わりに sudoedit を使うと嬉しいことがあ
サーバーやインフラなどの監視ツールの1つとして最近注目されているのが「Prometheus」だ。Prometheusはインストールや設定が容易で、かつ十分な機能を持ち管理しやすいという特徴を持つ。本記事ではこのPrometheusの導入方法、基本的な監視設定の流れを紹介する。 クラウド時代の監視管理ツール ネットサービスを運営する場合、そのサービスを運営するソフトウェアやサーバー、ネットワーク機器などの状況を監視する手段を用意するのが一般的だ。監視を行い、意図しない状況になったら自動的にメールなどで通知を行うシステムを構築することで、問題をいち早く解決できるようになる。さらに、サービスやマシンの稼働ログを適切に記録することで潜在的な問題を事前に見つけたり、最適化に向けた分析を行うといったことも可能になる。 監視や問題発覚時の通知などを行うオープンソースのツールとしては、過去にElastic
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 これまでのApache2.2系以前でのアクセス制御の書き方は賛否両論でした。僕はあまり好きじゃありませんでした。 過去のアクセス制御に関しては、以下の記事がとてもわかりやすくまとめられていると思います。 こせきの技術日記 – Apacheのアクセス制御をちゃんと理解する。 ここで、以下のように言及されています。 こんなバッドノウハウ、本当はどうでもいいと思う。Apache 3.0では、かっこいいDSL(VCL)で書けるようにする構想があるらしいのでがんばってほしい。 ということで、2.4系ではDSLとはいかないまでも、Require*というディレクティブを使ったモダンな書き方ができるようになったので、それを2.2系以前のアクセス制御の記述と比
しばらくLinuxネタが続く・・。 近いうちに最近出たJava8ネタを書いてみようと思います。が、もう少しLinuxネタにお付き合いください。 前回はsshdを対象に親プロセスをkillした場合の動作を確認した。 killされたプロセスの子プロセスは孤児プロセスとなり、カーネルによって自動的にinitプロセスの子として扱われる事を説明した。(この動作を「リペアレンティング」と呼ぶ) 今回はこの続き。 Linuxで作業していてCtrl+Cしてプロセスを終了した場合、フォアグラウンドのプロセスやその子プロセスも一緒に終了する。 ということは、子プロセスは孤児として扱われず、リペアレンティングされていないことになる。 今回の記事ではこの振る舞いの違い(リペアレンティングされるか否か)に着目し、kill -SIGINTコマンドとCtrl+Cの違いについて考えていく。 そもそもkillコマンドやCt
# systemd-analyze Startup finished in 666ms (kernel) + 2.171s (initrd) + 4.705s (userspace) = 7.542s kernel, initrd, userspace それぞれの合計時間をだしてくれる。 より詳細を知りたい場合は、blame オプションを使う。systemd-analyze blame の実行結果 # systemd-analyze blame 1.120s firewalld.service 1.032s network.service 987ms boot.mount 712ms tuned.service 574ms vboxadd.service 458ms vboxadd-x11.service 320ms systemd-vconsole-setup.service 293ms
Debian や Ubuntu では通常、dpkg-reconfigure を使ってタイムゾーンの設定をするのだが、設定変更を対話的に行わずにコマンド実行のみで完結したい。-f オプションをつけるといいみたい。 root 権限で、 echo "Asia/Tokyo" > /etc/timezone dpkg-reconfigure -f noninteractive tzdata sudo を使うなら、 echo "Asia/Tokyo" | sudo tee /etc/timezone sudo dpkg-reconfigure --frontend noninteractive tzdata Chef などで設定の自動化をするときに役立ちそう。
コンニチハ、千葉です。 AWSを利用していればcloud-initをご存知の方が多いと思います。ただ、「cloud.cfg上から説明して!」とか言われたら困ると思います。 なにせ、ぐぐってもあまり情報がありません。公式のドキュメントを読んでも設定方法やモジュール名は書いているのですがモジュールがデフォルトでどんな挙動するのか読み取れませんでした。なので、ソースコード(主にコメントw)頑張って読んでまとめました。 初期構築等で設定だけしたいのであれば、このページを見ればいけると思います。 cloud-initの実行タイミング ふわっと、初回起動みたいに覚えている方もいると思います。実際には初回起動以外にも実行タイミングがあります。 一生に?1回だけ実行されるもの インスタンスごとに実行されるもの(AMI作成し、そこからインスタンスを作成した時) 起動時に毎回実行されるもの ソースで、「fre
諸般の事情でネットワークセグメントを分けたのだけど、どうしてもあるポートだけ疎通させたいと思ったので、iptablesのNAT機能を使って実現してみた。 ルールの書き方はiptables本来のfilterとは少し違うのと、他のサイトでは解説が不足している点があるな、と思ったのでしっかり書き留めておく。 やろうとしていること この図の通り。 今回、iptablesを使ってNATさせる箱は、192.168.1.30と10.0.2.40と二つのサブネットのIPを持っていなければならない。 しかしクライアント(192.168.1.20)とサーバ(10.0.2.50)となる2ホストに、スタティックルートを書く必要はない所がポイント。 なぜならNAT箱でアドレスを変換するので、クライアントは192.168.1.30さえ到達可能であればよい。同様にサーバも10.0.2.40には到達可能なので、実現できる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く