Docker キャプテンは、開発者コミュニティのリーダーであり、それぞれの分野の専門家であり、Docker の知識を他の人と共有することに情熱を注いでいます。「From the Captain's Chair」は、あるキャプテンを詳しく見て、彼らとその経験について詳しく知るブログシリーズです。
本日はイーゴリ・アレクサンドロフにインタビューします。イゴールはニューヨーク市に拠点を置くRuby on Rails開発エージェンシーJetRocketsのCTO兼共同創設者であり、200820年以上のソフトウェアエンジニアリング経験とRailsエコシステムへの深いコミットメントを持っています。彼はCrystalプログラミング言語やKamalなどのプロジェクトにオープンソースで貢献しており、コンテナオーケストレーションからReactからHotwireへの移行まで、さまざまなテーマで専門知識を共有する定期的なカンファレンススピーカーです。
Dockerに関わったきっかけを教えていただけますか?なぜDockerキャプテンになろうと思ったのですか?
Dockerキャプテンになるまでの道のりを振り返ると、すべては多くのRailsチームが直面する非常に実用的な問題、すなわち依存地獄から始まりました。
2018年までに、JetRocketsは長年にわたりRuby on Railsアプリケーションの開発を行っていました。私はバージョン2からRailsを使っていました。22009年に入り、しっかりとした開発慣行を確立していました。しかし、チームが増え、プロジェクトが複雑になるにつれて、同じフラストレーションの溜まる問題に何度も直面しました:
- 「自分のマシンで動く」という言葉は、デプロイメント中にあまりにもよく使われるフレーズとなりました
- 新しい開発者環境の構築は時間がかかり、バージョンの不一致が多かった
- 私たちのステージングや制作環境は、最善を尽くしても時折異なる挙動を取ることがありました
- 異なるプロジェクト間のシステムレベルの依存関係の管理はますます複雑になっていました
開発、ステージング、本番環境を一貫して管理できる、アプリケーション依存関係を統一した方法が必要でした。
多くのチームがローカルでDockerを使い始めて徐々に本番環境に移行するのに対し、私たちはまずDockerを本番環境とステージングで実装することにしました。これはリスクに聞こえるかもしれませんが、真の環境平等を達成するという私たちの目標と完全に一致していました。
私たちは最初のRailsアプリケーションをコンテナ化し、最初のDockerfileの作成を始めました。初期のDockerfileは、今日私たちが作る高度に最適化されたものよりずっとシンプルでしたが、私たちの根本的な問題を解決しました。つまり、すべての環境が同じコンテナと同じ依存関係で動くようになったのです。
AWS Beanstalkは開発者に優しいソリューションではなかったものの、目標は達成されました。真の環境一貫性を実現し、環境間で異なる構成を管理するメンタルオーバーヘッドはほぼ消え去りました。
2018年にDockerを採用したことがきっかけとなり、最終的にはDockerキャプテンになる道を歩み始めました。依存関係管理の単純なニーズから始まり、コンテナ最適化の深い専門知識、Kamalのようなツールを用いた高度な展開戦略、そして最終的にはDockerコミュニティへの貢献へと発展しました。
今日は、画像スリミング技術から高度なCI/CDパイプラインまで、Railsコンテナ化のベストプラクティスについて詳しく執筆しています。しかし、すべては 2019 年にDockerで依存関係の問題を解決しようと決めた瞬間に遡ります。
来年の個人的な目標は何ですか?
これまで培ってきた専門知識を、もっと多くの会議やミートアップで話したいと思っています。アトランタ地域に住んでいるので、地元のテックコミュニティにもっと溶け込みたいと思っています。アトランタには活気あるITシーンがあり、ここで貢献できる本当のチャンスがあると思います。Dockerのミートアップを企画したり、Railsグループに参加したり、同じような課題に直面している他のCTOや技術リーダーとつながったりします。
もしあなたがテクノロジー業界で働いていたら、代わりに何をしていましたか?
もし技術系で働いていなければ、木工をしていたと思います。手で何かを作ることに深い満足感があり、木工は私がプログラミングに惹かれる創造的な問題解決力を提供してくれます。ただし、コードではなく自然素材や伝統的な道具を使って作業するのです。
手を使って作業し、努力の具体的な成果を見るのが本当に楽しいです。多くの点で、ソフトウェア作りと家具作りはそれほど違いません。原材料を使い、職人技と細部へのこだわりを応用し、機能的で美しいものを作り出しているのです。
木工でなければ、おそらくダイビングを目指すでしょう。私はすでにPADI認定のレスキューダイバーで、本当に海が好きです。水中の世界には私たちのデジタル生活とはまったく異なる何かがあります。平和で挑戦的で、常に驚きをもたらします。ダイビングインストラクターの資格を取得し、他の人が水中の世界を発見する手助けをすることは、非常にやりがいのあることでしょう。
Dockerコミュニティとのコラボレーションで思い出に残るストーリーを共有できますか?
Docker Captainとして最もやりがいのある点の一つは、定期的なキャプテン会議で、正直なところ、私はその一回一つを楽しんでいます。これらは単なる企業ミーティングではなく、コンテナ化分野で最も情熱的で知識豊富な人々との本物のコラボレーションです。
これらの会議が特別なのは、多様な視点があることです。キャプテンたちはまったく異なるバックグラウンドを持っています。エンタープライズKubernetesのデプロイに特化している人もいれば、AIに携わる人、私のようにRailsアプリケーションの最適化をする開発者、そして私が考えたこともなかった問題を解決する人たちがいます。
現在お気に入りのDocker製品や機能は何ですか、そしてその理由は何ですか?
最近VS Codeに統合されたビルドデバッグ機能にとてもワクワクしています。Rails Dockerファイルの最適化やコンテナ化のベストプラクティスについて書くことに多くの時間を費やす私にとって、この機能は私の開発ワークフローにとって大きな転機となりました。
Railsアプリケーション向けに複雑なマルチステージビルドを作成する際、特に画像サイズの最適化、ビルドキャッシュの管理、Node.jsやRubyジェムのような依存関係の処理を考える際、ビルド失敗のデバッグはかつて本当に面倒でした。
最近解決したトリッキーな技術的課題について教えていただけますか?
最近、多くのRails開発者が共感できると思う非常にフラストレーションの溜まる開発ワークフローの問題に直面しました。約 1504GBの大きなデータベースダンプファイルがあり、それをローカル開発のテンプレートとして使う必要がありました。問題は、このSQLダンプをPostgreSQLに復元するのに、開発データベースをクリーン状態にリセットするたびに最大1時間もかかっていたことです。
開発チームにとって、これは生産性を大きく損なっていた。誰かが移行ロールバックをテストしたり、データ固有の問題をデバッグしたり、最初からやり直したりするたびに、データベースの復元に1時間待たなければなりませんでした。それは全く受け入れられません。
当初は、ほとんどのチームがやっていること、つまりSQLダンプファイルに対して直接 pg_restore を実行するという方法でした。しかし 150GBのデータベースでは、PostgreSQLがダンプ全体を解析し、数千のINSERT文を実行し、インデックスを再構築し、テーブル統計を更新します。データベースエンジンが実際の作業をしなければならないため、本質的に遅いのです。
ボトルネックはデータ自体ではなく、データベースの復元プロセスにあることに気づきました。そこで私は全く異なるアプローチを取ったBashの脚本を書きました:
- テンプレートボリュームを作成する:新しいDockerボリュームから始め、PostgreSQLコンテナを立ち上げます
- 一度きりの復元:SQLダンプをこのテンプレートデータベースに復元します(これも1時間かかりますが、一度だけです)
- ボリュームスナップショット:BusyBoxコンテナを使ってファイルシステムレベルでデータベース全体のボリュームをコピーします
- 即時リセット:開発者が新しいデータベースを必要とするときは、テンプレートボリュームを新しい作業ボリュームにコピーするだけです
魔法はステップ 4にあります。SQLから復元する代わりに、基本的にDockerボリュームレベルでファイルをコピーしています。これは1時間ではなく数秒で済みます。なぜなら、すでに処理済みのPostgreSQLデータファイルをコピーするだけだからです。
Dockerボリュームは、内部にはファイルシステムのディレクトリのようなものです。PostgreSQLは非常に特定のディレクトリ構造にデータを保存し、データファイル、インデックス、メタデータを含みます。ボリューム全体をコピーすることで、データベースの「使用準備完了」状態の完璧なスナップショットが得られます。
スクリプトはすべてのオーケストレーションを担当し、ボリュームの作成、コンテナのライフサイクル管理、コピーしたデータベースのクリーンな起動を確実にします。かつては1時間のリセットサイクルだったのが、今では文字通り 5秒、つまり10 秒に短縮されています。開発者は自由に実験し、破壊的な操作をテストし、環境をためらうことなくリセットできます。私たちのチームのデータベース依存開発へのアプローチが大きく変わりました。
すべての開発者に知っておいてほしいDockerのヒントは何ですか?
もしDockerfileで何か変な感じがしたら、それは間違ったやり方です。これは、私が長年Rails Dockerfileを最適化して学んだ最も重要な教訓です。他の開発者のコンテナ設定を見直すと、複雑なRUNコマンドや奇妙なコピーパターン、あるいは違和感のある回避策をよく目にします。
Dockerfileは、きちんとした論理的な指示のように読めるべきです。もし自分がこんな感じで書いたら:
RUN apt-get update && apt-get install -y wget && \
wget some-random-script.sh && chmod +x some-random-script.sh && \
./some-random-script.sh && rm some-random-script.sh
…おそらくあなたはやり方が間違っているでしょう。
最高のDockerfileは、そのシンプルさと明快さがほとんど退屈に感じられます。すべてのセリフには明確な目的があり、全体の流れは読む人にとって意味が通じるべきです。もし奇妙なハックや異常なファイル権限、複雑なシェル体操を加えているなら、一歩引いて理由を考えてみてください。
この原則のおかげで、デバッグにかかる時間が無数に省けました。珍しいことをうまく機能させようとするのではなく、アプローチを再設計することを学びました。通常、あなたが目指していることを達成するには、よりクリーンで標準的な方法があります。
実生活で非技術的なオブジェクトをコンテナ化できるとしたら、それは何でしょうか、そしてその理由は何ですか?
もし非技術的なオブジェクトをコンテナ化できるとしたら、それは間違いなく知識そのものです。スキルや経験、専門知識を携帯可能なコンテナにまとめて、必要に応じて心から取り出せることを想像してみてください。常に新しい技術を学び、他者に教えている者として、私たちがどのように知識を獲得し、移転しているのかに非常に興味を持っています。現在、Crystalのように新しいプログラミング言語に深く取り組みたい場合や、Kamalのようなデプロイメントツールを習得したい場合、数ヶ月の集中的な学習と練習が必要です。
しかし、もし知識がDockerコンテナのように機能したらどうでしょうか?「ルビー 3を持てるかもしれません。3 技術」コンテナ、「高度なKubernetes」コンテナ、あるいは「木工接合技術」コンテナなどがあります。複雑なRailsアプリケーションをデバッグする必要があるですか?コンテナを積み込め。ダイビング認定コースの受講中ですか?海洋生物学の知識ベースを置き換えましょう。
本当の力は一貫性と移植性にあります。Dockerコンテナがアプリケーションをどこでも同じように動かすように、知識コンテナは文脈に関係なく同じ深い理解を提供します。もう構文を忘れたり、何年も前に習ったデバッグの技術を思い出そうと苦労したりはしません。
さらに、コラボレーションの可能性を想像してみてください。経験豊富な開発者は、自分の苦労して得た専門知識を文字通りまとめてコミュニティと共有することができます。Dockerがデプロイメントを民主化したのと同じように、学習の民主化を成し遂げるでしょう。
もちろん、人間の学びと成長の経験は失われますが、純粋な効率の観点からは?それは信じられないことです。
オンラインでどこであなたを見つけられますか?(講演、ブログ投稿、オープンソースプロジェクトなど)
私はX(@igor_alexandrov)や LinkedInで常に活動しています。毎年少なくとも23のテックカンファレンスやミートアップで講演を心がけており、それ以外にも個人ブログも運営しています。
ラピッドファイアの質問
猫か犬か?
イヌ
朝型人間か夜型人間か?
両方とも
好きなホッとする食べ物は?
餃子
友人があなたを表す言葉を一言で表現しますか?
完璧主義者
最近始めた趣味は?
サイクリング
