archof: リモートのままイメージのarchitectureを確認するコマンド - ローファイ日記
背景 Apple SiliconのMacが販売されてそれなりの時間も経ち、エコシステムもできてきてお仕事の開発に使っている人も増えてきたように思う。 ところで、colimaのようなツールを使い、Docker環境をMacに作成した時、Apple Silicon上ではデフォルトで arm64 版のDocker*1がインストールされる。 $ docker info | grep Archi Architecture: aarch64 この上で何も考えずにイメージをビルドしたら arm64 のイメージができる。 この時、このイメージをリモートのレジストリ（GCR、GHCRなどを想像してほしい）にpushにしたら、もちろん arm64 のイメージがpushされる。 ここで、このイメージをx86_64の本番サーバにpullして走らせるような運用だったら、困ったことになるだろう...。 このような違うア
Apple Silicon上でx86_64のDockerを使う - ローファイ日記
Apple Silicon上でLinux向けx86_64の環境が欲しくなったり、x86_64向けのバイナリやイメージを作らないといけなくなる事態は、稀に良くあると思う。 colimaを使うと、Aarch64なMac上であっても、かなり楽にx86_64のLinux環境とDocker環境が手に入る。 最近のcolimaには実は --arch というオプションがあり、x86_64又はaarch64であればあっさりと環境を作ることができるようになっている。 デフォルトで入ってくる環境と区別するため --profile オプションを明示する必要がある。 $ colima --profile colima-x64 start --arch x86_64 colimaの作ったDockerインスタンスは colima list で一覧できる。 $ colima list PROFILE STATUS AR
自分の中で大切に思ってる本の話 - ローファイ日記
hiboma.hatenadiary.jp またhibomaさんのブログの言及で恐縮なのだが、このブログを読んで、そういえば僕のキャリアの中で重要だった本って何かな〜というのを考えていた。 前提として僕は本を読むのが苦手で（やっと最近気づいた）、めっちゃ遅くしか読めないし、量を読めないのだが、それでもポイントポイントで読んでおいて良かったという本はある。というより、割と一冊の本から受ける影響が人より大きいような気がするし、「僕にめっちゃ影響を与えてくれそう」という勘が働かないと読まない。 なので - でもないけれど、ここにあげている本の話題はただの思い出話で、必ずしも人に薦める意図はない。 アジャイルな見積りと計画づくり book.mynavi.jp この本は某F社にいるときに、とにかく周りの仕事が進まない、優先順位がつかない、今でいうトイルで運用が忙殺される、みたいな不満の塊の只中にいる
2021年にmrubyを始める皆さまへ - ローファイ日記
2021年3月5日に、mruby 3.0.0 のリリースがされました。おめでとうございます！ mruby.org これに関連してなのか、mrubyをこれから始めようとか、ここのところどうなっていますかという質問をちょくちょく受けたり、ツイートを拝見したりするようになりました。 一方で、どうしても情報が古い、あるいは多くのmgemのメンテナンス状況が悪いように見える、などの初学者にとっては難しい状況が広がっており、厳しい気持ちになったり、厳しい感想を述べたりされている方もいるように思います。そして、その感想中には誤解も含まれているようです。 ここでいったん、少しでも「心構え」ができるように、これから触ってみる方々に対しての自分の考えをまとめておこうと思いました。 （さらにいうと、基本的に本原稿はいちユーザ、それもWebインフラに関わるユーザとしての解釈なので、Matzをはじめとした他のmru
Infra Study Meetup #4 で登壇した後日談 #InfraStudy - ローファイ日記
forkwell.connpass.com id:matsumotory さんからお誘いいただきお話しと、若干のライブコーディングをした。 なぜライブコーディングをしたのか 松本さんから投げられたテーマがものすごく無茶なフリというか、「インフラの面白い技術」であった。正直最初の感想は、「えっ...」だった。これが関西人か、って思った。面白いってなんですか！ 自分が面白いと思うことを考え続けた結果、プログラミングだなという気持ちになったので、それをなるべく直接的に表現するスタイルを選んだ。また、ここ最近のオンライン登壇に関してある程度実験してみたいという気持ちも強かったので。インフラ運用者にとってプログラミングの技術はある意味諸刃の剣だとは思っているのだが、それでもSRE（僕はソフトウェアエンジニアの一ポジションだという理解になっている）などの風潮もありチャレンジしてみた。 正直当日終わるま
何もツールがなくてもコンテナの中のTCP通信の状態を見たい - ローファイ日記
完全に消費税に負けた... 今日も小ネタです。 一般に、以下のようなことを調べる時 netstat や ss などのツールは便利です。 あるポートがリッスンされているか知りたい あるコネクションに実際に通信があるか知りたい MySQLサーバなど外部プロセス/サーバにコネクションが貼られているか知りたい でもコンテナ環境では、そんな余計なツールは入っていない！！！ことも多い。 そんな時でも、 /proc ファイルシステムはほぼ間違いなくマウントされているはずです。 なのでそこを直接見ることも検討しましょう。 /proc/net/tcp(6) を眺める コンテナのネットワークに直接入るには、 nsenter などを使うことができます。今回はすぐ用意できる環境があったので Haconiwa ですが、 Docker などで置き換えて試してください。 $ ps auxf ... root 13252
straceがどうやってシステムコールの情報を取得しているか - ローファイ日記
興味があって調べていたら、少しだけ分かったのでまとめておきます。当然間違った箇所もある、あと考慮が漏れている箇所もあるかと思いますのでツッコミをお願いします… ptrace(2) システムコール strace の核となるシステムコールは ptrace(2) である。ptrace(2)を用いることで、あるプロセスを別のプロセスから監視し、シグナルごとに停止してレジスタやメモリの状態を観察したり変更したりできる。gdbのようなデバッガのブレークポイント、あるいはまさにstraceのような目的で利用される。 大まかな利用方法としては、親プロセスの ptrace(PTRACE_ATTACH, pid, ...) （または子プロセスの ptrace(PTRACE_TRACEME, 0...)）によりトレースが開始し、wait()などで停止を待ってから様々な設定を親から送り、 ptrace(PTRAC
Linuxプログラミングインターフェースを読んだ（一周目） - ローファイ日記
読みきった。一周目の所感を書く。 Linuxプログラミングインタフェース 作者: Michael Kerrisk,千住治郎出版社/メーカー: オライリージャパン発売日: 2012/12/01メディア: 大型本 クリック: 14回この商品を含むブログ (7件) を見る モチベーション ぼくは、小さい会社でWebサービスの開発もしつつLinuxのサバ管も少ししつつ、という人間だったので、Linuxに開眼して真髄を会得したい、という欲求が長らくあった。例えば青木さんの本であったり、なるほどUnixであったり。 ふつうのLinuxプログラミング Linuxの仕組みから学べるgccプログラミングの王道 作者: 青木峰郎出版社/メーカー: ソフトバンククリエイティブ発売日: 2005/07/27メディア: 単行本購入: 35人 クリック: 450回この商品を含むブログ (150件) を見る tatsu
fusuma/mruby-fuseでFUSEを簡単に試す - ローファイ日記
mruby Advent Calendar 2016 の 2日目の記事です。 昨日は おごもりさんのRuby Miniature Book の記事でした。 今日は、最近こそこそ作っているfusumaとmruby-fuseが、なんとなく面白いおもちゃにはなってきたので、せっかくということで紹介したいと思います。 fusuma (FUSe Upon Mruby-script Assistance) github.com mrubyとFUSEを用いて、ファイルシステムを作れるコマンドベースのミドルウェアです。 インストールはx86_64なLinuxバイナリは用意してありますのでひとまずそちらを解凍し、パスの通るところに配置すればOKです。各ディストロで fuse/ilbfuse 相当と libcurl 相当を別途インストールす必要があるでしょう。 ダウンロードはこちら とりあえず、libfuse
seccompをmrubyで試す - ローファイ日記
seccomp とは、Linuxでプロセスのシステムコールの発行を制限する機能のこと。今回試すものはseccomp mode 2と呼ばれる、Linux3.5から搭載されたもので、システムコール単位での制限、特定の条件を満たす引数のみの許可/制限を実現できる。 バックエンドではlibpcapなどでも利用しているBPF（Berkeley Packet Filter）を利用していて、JITなどで高速に動作するらしい。 以下のサイトなども参照のこと。 mmi.hatenablog.com yuzuhara.hatenablog.jp 今回、seccompを利用するためのCライブラリlibseccompを用いて、mruby-seccompを作成した。これを利用してシステムコールの発行制限を試す。 github.com 基本的な使い方 基本的には、Seccompのコンテクストを作って、ルールを記述し、
Haconiwa のrpm/debパッケージを配布開始しました - ローファイ日記
packagecloud を使っております。 udzura/haconiwa - Packages - packagecloud.io | packagecloud 便利です。一応 CentOS >= 7 / Ubuntu Trusty / Ubuntu Xenial / Debian jessie で利用できると思います。 パッケージをインストールすると3つのバイナリが入ってきます。 haconiwa haconiwa コマンド本体です。READMEにあるようなhacoファイルを解釈してコンテナを立ち上げたりできます。まあ 例 の通りです。debootstrapなどでルートファイルシステムを作っておためしください。 hacorb haconiwa コマンドと大体同じmgemが入った、mrubyのバイナリそのものです。個々のmgemの機能を直接組み合わせて、Rubyでプログラムを書いたりで
Emacsでmrubyをそこそこ快適に書く - ローファイ日記
こんにちは、これはEmacs記事です。みなさんはEmacs記事...ではないですよね...。 Haconiwaのおかげですっかりmruby人間になって久しい id:udzura です。 https://t.co/1iLQyn2rV0 バージョン 0.2 系を出しました。rlimit系のリソース制限と、コンテナ内PID=1のuid/gidを変更できます #haconiwarb— Uchio KONDO (@udzura) 2016年7月20日 で、宣伝はこんなくらいにしておきまして、なんとなく流れでセットアップしたEmacsによるmruby環境をこの辺で整理しとこうと思ったので、書きます。というか、ほとんどC言語を書くための環境...。平成が終わるとか終わらないとか言っている2016年にEmacsでC言語を書く環境の記事を書きます。 なお僕は C言語をまともに書いて2ヶ月ぐらいだったり、あと
mruby-argtable というものを書いた - ローファイ日記
github.com 宜しくお願いします。こんな感じです。 t = Argtable.new t.literal("v", "verbose", "You are verbose") t.integer("c", "count", "<c>", "My count") t.double("s", "seconds", "<t>", "My seconds") t.string("n", "name", "<n>", "My name") t.parse(["prog", "-c", "9999", "--verbose", "--name=udzura", "-s", "12.25"]) t["v"].count #=> 1, no value t["c"].value #=> 9999 t["n"].value #=> "udzura" t["s"].value #=> 12.25 t.
haconiwaの室内楽 - Re: 自作Linuxコンテナの時代 - ローファイ日記
haconiwa という、いわゆるLinuxコンテナに関する様々な技術を組み合わせて、自分のためのコンテナを作ることができるRuby製のツールと、そのDSLを作った。ひとまずこれぐらいはやりたいということができていそうなので、バージョン 0.2.0 としてリリースした。 github.com 使い方 ほぼREADMEの日本語版。 前提として、以下のライブラリとコマンドが必要になるので入れておいて欲しい。 libcap (libcap.so.2 を FFI 経由で使う) nsenter (yum install util-linux とかそういう感じで入れる) ひとまず動かしたい場合は、rbenvなどが整った環境で、gemとして入れるのがいいと思う。多分Ruby 2.0 以降で動く気がする。 $ gem install haconiwa $ rbenv rehash そして、現在のhacon
miamを使ってIAMの権限をいい感じに絞って適用する - ローファイ日記
IAMというのは例のAWSのアレ。ユーザのアカウントと権限を管理するやつ。 このサービス、機能が多くてややこしいところがあり、具体的には以下のポリシーで運用するときにそのものズバリの情報がすぐに見つからなかったので、この場でまとめとこうかなって思った。 原則、ユーザ管理操作は禁止 しかしそれぞれのユーザは自分のパスワードを更新できるようにしたい さらにそれぞれのユーザは、自分だけAPI AccessKeyの発行をしたい なお管理のために miam を使う。miamの使い方は説明しませんが、簡単なのでREADMEなど見て入れてください。 原則、ユーザ管理操作は禁止 最初に NotAction でiam系のAPI利用を前面禁止する。許可がホワイトリスト型になる。 group "PowerUser" do policy "PowerUser-NotAllowIam" do {"Version"=
ソフトウェアをリプレースする前に考える三つのこと - ローファイ日記
個人的には三つの基準があるという話。 そのソフトウェアが十分に古く、十分長い間保守されていないか そのソフトウェアを触れる人間が組織内に少なく、増やす手だても困難であるか そのソフトウェアで実現できることが、他の新しいソフトウェアでより容易に実現できるかどうか 1. についてはそうだろう、という感じだと思う。というかリプレイスの前提になると思う。バージョンが古いソフトウェアを使い続けると、脆弱性も出てくるし、一般的には開発の速度も低下する。 ただ、ここで重要なのは、2.や3.との兼ね合いかなと思っている。 例えば2.が1.より優先される場面というのもあるだろう。Hoge言語で作ったミドルウェアの保守について以下のような状況にあるとする。 開発者が退職してしまった Hoge言語に関するドキュメントが全然なくて学習が困難 という感じであればリプレースは検討に入れていいかもしれない。 しかし、こ
`soko(倉庫)` というサーバメタデータを取り扱うミドルウェアを作っている - ローファイ日記
github.com みなさん、userdata書いてますか（挨拶）。 今日は、細々と書いてきた、自作ツールの紹介をしてみます。 どういうものか たとえば、同じPuppetのマニフェスト、同じアプリをデプロイするけれど、サーバAはweb向けのロードバランサー、サーバBはAPI向けのロードバランサーの配下にいて欲しくて、それぞれ固有の動きをさせたいような場合があるかもしれない。 そういうとき、まず、サーバAの起動時に、EC2のタグ機能を使って aws ec2 run-instances ......... # インスタンスIDを控えるか変数に入れる aws ec2 create-tags --resources i-XXXXXXX --tags Key=LoadBalancerName,Value=www とやることが考えられる。サーバBなら Key=LoadBalancerName,Val
イメージベースのデプロイについて（あるいはIaaSだとこんなんが良いんじゃないと言う意見） - ローファイ日記
最近、仕事やら趣味やらで AWS / OpenStack / GCE その他のいわゆるIaaSなプラットフォームを調査したり、いじったり、そのAPIをいじったりする機会が多かった。 この辺の運用を考えていて試したこと、ぶつかったことなどをまとめたい。 実際やったこととしては、特定のプラットフォームに依存している訳ではないが、たいていの人はAWSのアレね、みたいなイメージを持った方が読み進めやすいんじゃないかと思う。 ゴールデンイメージを雑に走らせること この手のIaaSの基本であるが、サーバーはインスタンスと呼ばれ、イメージを指定して起動する。ec2 aws run-instanceとかnova bootとかその類いである。 イメージからの起動のためには雑には大きく2要素があって、一つはイメージ自体の構築、もう一つは起動直後のそれぞれのインスタンスの特性に合わせた初期化処理のフェーズである
「それでもRailsを選択する3つの理由」を読んだ - ローファイ日記
http://ppworks.hatenablog.jp/entry/2015/02/19/223552 ほぼほぼ同意なのですが、フームと思って（ppworksさんプロダクトだから、ということでもないが）ポエムをしたためた。 でもなんかこれをあえてポエムにとどめないで書いたらどういう反応があるかな〜と思ったのでブログにも転載してみよう。 規約縛りの哲学 これは文句なくその通りだと思っていて、Rails以外のフレームワークではこれらの実現が非常に中途半端であると言う印象を持っている。 サービス作りにおいて技術選定やら何やらからの議論をしていてはリリースは当然遅くなるし、あまりしたくないということである。議論するならもっとユーザに近い、正体のよく分からない不安点（このアプリほんとにユーザに受けるの？ とか）に関してすべき。 議論は一般的に良いことのように思われているが凄い体力を使うし、本当に必
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「やわらかConsul」というワークショップをした - ローファイ日記
