CPU律速なRuby/Pythonコードはデフォルト設定のdocker上で遅くなる - まめめも
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
Docker Multi-Stage BuildsでRailsのイメージを軽量化してみる - Qiita
はじめに RailsのDockerイメージのサイズを半分以下にする事ができました！ Docker Multi-Stage Buildsとは Docker17以降のバージョンでDockerfileにFrom句を複数書けるようになりました。 これがマジでヤバイ！ 何がヤバイかというと、 複数のビルドしたイメージから必要なものだけをコピーできるということ。 ライブラリを展開する為に必要なツールのインストールなど行う場合が多々あるかと思いますが、最終的なイメージには不要なものもあるかと思います。 そういった不要なものを省く事が簡単にできます。 イメージはなるべくサイズを抑えるべきです。 イメージのビルド、デリバリの時間を圧縮でき、これはCI/CDの基本です。 Docker Multi-Stage Buildsに関しては、こちらの記事で詳しく解説されています。 Docker multi stage
公式のRubyのDockerイメージのbundlerの挙動
少しハマったので備忘録。公式のRubyのDockerイメージを使うとbundler経由でインストールしたものをボリューム用コンテナで永続化しても二回目以降の起動時でうまく反映されない事象が起きました。 具体的には以下の手順でエラーが発生しました。 コンテナを立ち上げてコンテナ内に入り、bundle install –path=vendor/bundle で依存ライブラリをインストール。vendor/bundleはボリュームコンテナで永続化している。 bin/rails sでサーバ起動できることを確認 コンテナを再起動し再度コンテナ内に入り、bin/rails sでサーバ起動する。vendor/bundleはボリュームコンテナで永続化しているはずなのでbin/rails sを叩けば起動できるはず… が、エラーで落ちる Dockerfileとdocker-compose.ymlはこんな感じです
Rubyで "&" を使うと幸せになれるらしいよ (*´Д`)ﾉ - (ﾟ∀ﾟ)o彡 sasata299's blog
2010年02月03日21:31 Ruby Rubyで "&" を使うと幸せになれるらしいよ (*´Д`)ﾉ なんか似たようなタイトルを見たことあるな…まぁいいか。 Perlで+を使うと幸せになれるよ (*´Д`)ﾉ - (ﾟ∀ﾟ)o彡 sasata299's blog ブロック処理 ( do...end もしくは {...} ) の例としてはこのような3種類があります。 #1 ブロックの中に直接処理を書く方法 #2 ブロックの中でやらせたい処理の Proc オブジェクトを呼び出す方法 #3 ブロックを使わずに Proc オブジェクトに & を付けて渡してあげる方法 3つとも全く同じ処理です。#3 みたいに書く事も出来るんですね〜。& が Proc オブジェクトをブロックに変換してくれます。 #1 3.times do puts 'hogehoge' end proc = Proc.new
16進文字列とバイト列を相互変換する(ruby)｜TechRacho by BPS株式会社
あんのたんが書いてくれた記事のRuby版です。 を書こうと思ったのですが、StackOverflowに同じのがあったのと、こちらのほうがコードが綺麗だったので引用しておきます。 class String def hex2bin s = self raise "Not a valid hex string" unless(s =~ /^[\da-fA-F]+$/) s = '0' + s if((s.length & 1) != 0) s.scan(/../).map{ |b| b.to_i(16) }.pack('C*') end def bin2hex self.unpack('C*').map{ |b| "%02X" % b }.join(") end end とてもシンプルですね。 これだけだとあまりにも内容がないので、少し内容がずれますが、おまけです。 RIFFのファイルを読み込み
EC2上のログをtd-agent使ってCloudWatch Logsに投げようとしたらSSL認証エラーになった話 - Alligator Swamp
EC2上のログを、td-agentとfluent-plugin-cloudwatch-logsを使ってCloudWatch Logsに送信しようとしたところ、SSL認証エラーが発生したので、エラーの解決方法を調べたのでまとめてみた。間違っている箇所があれば指摘ください！ before_shutdown failed error="SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed" tl;dr EC2でtd-agent使ってCloudWatch Logsにログを送信する場合は、/etc/sysconfig/td-agentに以下を追記すると上手くいくはず。 export SSL_CERT_FILE=/etc/pki/tls/cert.pem バージョン
Chefのレシピは上から下に実行されるという誤解 | Engine Yard Blog JP
Engine Yardを含むさまざまな場面で利用が広がったChefですが、その動作原理やアーキテクチャについてご存じない方もいることに気が付きました。細かなアーキテクチャを理解しなくても使うことができるというChefの長所を示しているともいえますが、細かな挙動を制御する際にはやはり動作原理などの知識があると役立ちます。 今回は表題のとおりレシピが実行される際のサイクルについてあまり知られていない部分を紹介します。 Chefの実行サイクルとリソースコレクション Chef(Chef Client、Chef Solo)が実行された際には直ちにサーバの設定が始まるわけではなく、さまざまなステップ毎に処理が実行されます。大まかには下記のようなステップになります。 Chef Serverとの通信、認証処理 Chef Serverからのクックブック、データの取得 クックブックのコンパイル ノードの設定
rubysl-fileutils | RubyGems.org | your community gem host
RubyGems.org is the Ruby community’s gem hosting service. Instantly publish your gems and then install them. Use the API to find out more about available gems. Become a contributor and improve the site yourself. RubyGems.org is made possible through a partnership with the greater Ruby community. Fastly provides bandwidth and CDN support, Ruby Central covers infrastructure costs, and funds ongoing
デプロイツール比較 CapistranoとFabric
by @dekokun on 2013/05/21 23:46 Tagged as: Capistrano, Fabric. 最近、Fabric, Capistranoと立て続けに2種類のデプロイツールを使ってデプロイ環境を構築する機会がありましたので、その際に感じた両者の利点を書いてみたいと思います。 両者の簡単な解説 そもそもCapistrano, Fabricについて、「片方は知っているけど片方は知らないよ」という人がいるかと思いますので、簡単な説明をします。 両方とも何かを知らない人は…「自動デプロイ」とかそのあたりで検索してみるといいんじゃないですかね。 Capistranoとは Ruby製のFabricみたいなものです Fabricとは Python製のCapistranoみたいなものです Fabricは私の中ではデプロイツールという認識なのですが、最近Chefと比較されること
serverspecでWindowsのテストをお試しする - Qiita
お仕事でWindowsサーバをserverspecでテストしたい！という要件があり、ご自宅のWindows PCで色々と実験するための環境を作ってみた。 動作環境 ご自宅にはマトモな環境が無いので、WindowsマシンをホストOSにして、VirtualBoxでLinuxのゲストOSを作った。ゲストOSでserverspecを実行し、リモートでホストOSをテストできるようにする。 ホストOS(テスト対象ホスト) OSはWindows7 Home Premium ゲストOS用にVirtualBox 4.3.2をインストール ゲストOS(serverspec実行環境) テスト対象ホストのVirtualBoxで動作。ネットワーク設定は以下の通り。 アダプター1はNAT アダプター2はホストオンリーアダプター OSはCentOSで、事前にRubyがインストールされている。バージョンは以下の通り。 C
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
doruby.jp
Omnibus-rubyプロジェクトでツールの周辺依存をまるごとrpm,debに固める - Qiita
GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms.
Run remote commands on a Windows machine from Linux using winrm | krash.be
http://mechanize.rubyforge.org/