DevOpsを加速する、JFrog日本法人メンバーによるブログです。JFrog ArtifactoryやXrayといった自社ツールはもちろん、CI/CDやコンテナ技術(DockerやKubernetes)などDevOpsの一般的な内容も扱います。その他、日本でのDevOps事例紹介やお楽しみコンテンツも掲載予定です。

JFrogならではの面白くて役に立つブログを目指しますので、お楽しみに!

カエルと実践するコンテナ

JFrog DevOps Acceleration Engineer 三宅です。

今回は「コンテナ」シリーズ全 3 回の最終回として、コンテナを中心とした開発フローやツールの実践についてご紹介したいと思います。

第 1 回、第 2 回は特定の商用製品やツールに触れずに、それぞれ「コンテナ」「コンテナ・オーケストレーション」の概要についてご紹介しました。

blog.jfrog.co.jp

blog.jfrog.co.jp

今回はコンテナベースのソフトウェアを開発・運用する上で実際に留意すべき点、必要になるツール群などのご紹介をしたいと思います。

そもそも「ソフトウェア・デプロイメント」とは何でしょうか? 定義としては「ソフトウェアを使用可能にするあらゆる活動」ですが、具体的には「プロセス」と「アーキテクチャー」から成り立ちます。「コンテナ」はこのいくつか進化してきたデプロイメントの「アーキテクチャー」に関連する最新の技術という捉え方ができます。

マイクロサービスのデプロイメントにはいくつかパターンがあり、コンテナを利用するものは "Container as a service" や "Service instance per container" などと呼ばれることがあります。

このアーキテクチャーを実現するために要となるのが「コンテナ・レジストリ」と呼ばれるツールです。Docker Hub やクラウドベンダーをはじめとする色々なコンテナ・レジストリが世の中に存在しています。

今回は「クレジットカードなし」でずっと(一年間などの制限なく)無料で使い続けることができる JFrog Artifactory の SaaS サービス やオンプレミス用のフリーのツール JFrog Container Registry についてご紹介致します。その特徴やコンテナ管理に止まらない「バイナリ全体を管理する」という新しい概念に触れていただければ幸いです。

以上、詳細は下記ウェビナーの内容にまとめてありますのでぜひご覧ください。

www.youtube.com

speakerdeck.com

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!

猿でもわかるコンテナ・オーケストレーション

JFrog DevOps Acceleration Engineer 三宅です。

今回は Kubernetes をはじめとするいわゆる「コンテナ・オーケストレーション」の話をしたいと思います。「コンテナ」シリーズ全 3 回のうちの第 2 回目となります。

第 1 回目は「コンテナ」の概要や歴史、それを支える OS の技術などをご紹介しました。

blog.jfrog.co.jp

コンテナは「リソースが分離されたプロセス」であり、OS レベルの仮想化にカテゴライズされるテクノロジーであることをご紹介しました。その「プロセスの隔離」を実現するための技術的な詳細についても触れました。

コンテナを使えばリソースを効率的に管理できるので、アプリケーションのデプロイに用いられる機会も増えてきました。ただアプリケーションが複雑になってくるとそれを構成するいわゆる「マイクロサービス」の構造も複雑になってくるため、これらがデプロイされる単位であるコンテナの数も膨大な数になってきます。この複雑で大規模になったコンテナを管理するためのツールが「コンテナ・オーケストレーション」です。

コンテナ技術と垂直・水平方向のスケールの歴史、また API とアーキテクチャーを中心に Kubernetes の基礎的内容を下記ウェビナーにてご紹介しましたので、ご興味あれば参照いただければと思います。

www.youtube.com

speakerdeck.com

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!

猿でもわかるコンテナ

JFrog DevOps Acceleration Engineer 三宅です。

今回から全 3 回に渡り「コンテナ」について紹介したいと思います。

まず第 1 回目は「コンテナ」の概要や歴史、それを支える OS の技術などを振り返りながらご紹介します。

  • コンテナとは?
  • アプリケーションの分離
  • コンテナを支える技術と歴史
  • イメージとは?
  • まとめ

一言で「コンテナ」と言っても、色々な見方があると思います。まずは多くの方がそうであるように「コンテナを利用する」側の見方があります。例えば開発者に取っては運用者にアプリケーションをハンドオーバーするときの「便利な箱」にもなるでしょうし、3rd パーティーのコンテナを利用するユーザーからすると Dockerfile が簡単なインストール手順書にもなるのではないでしょうか。

一方、「コンテナを実装する」側の見方もあります。なぜコンテナの中ではファイルシステムやプロセスやネットワークが制限されているのでしょうか? コンテナが「分離するもの」とはなんでしょうか? そのカラクリはどうなっているのでしょうか?

実はコンテナの歴史は長く、筆者が以前在籍していたサン・マイクロシステムズの商用 UNIX OS の Solaris に搭載された Solaris Container がリリースされたのが 2004 年、今から 15 年以上も前のことになります。そのコンテナの歴史も気になるところです。

現在のコンテナ技術は Linux をベースにしたものが中心でしょう。この Linux 上でコンテナ技術を実装するには Linux Namespaces や Linux Control Groups (cgroups) の理解が大切です。またイメージの技術は Union File System を土台にしています。

これらの詳細な内容を先日、弊社ウェビナーでご紹介致しました。当日は 200 名近くの参加があったようです。ご参加いただいた皆様どうもありがとうございました。また当日の録画とスライドは下記にありますので、振り返ってみたい方、見逃した方など適宜参照いただければ幸いです。

www.youtube.com

speakerdeck.com

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!

自動車もソフトウェアの時代。ITインフラの絶え間ない改善で世界中の開発者を支える―TRI-AD様インタビュー

こんにちは、デベロッパーアドボケイトのよこなです。
今回は新企画、JFrogのお客様にお話を伺うインタビューです。製品の活用術はもちろん、DevOpsへの取り組みやチームの印象的なエピソードなどをたっぷり聞いていきます。

記念すべき第1回目はトヨタ・リサーチ・インスティテュート・アドバンスト・デベロップメント株式会社(TRI-AD)様にお話を伺いました。

www.tri-ad.global

インタビューを受けて下さったのは、Infrastructure Engineeringチームよりヤンさん、守屋さん、そしてそしてArene Toolsチームよりエトウルノーさんです。

現在、自動車業界は100年に1度の転機が訪れていると言われています。品質の高い乗り物を作るのみならず、自動運転やコネクテッドカーなどの新しい技術を取り入れたサービス展開が重要になってきます。日本はこれまでも自動車産業で世界的に成果を上げてきましたが、次の時代はどのように戦っていくのか、興味深い局面を迎えていますよね。そんな中、TRI-AD様がどんな考えを持ち、ソフトウェアとどう向き合っているのかを色々と教えていただきました。

まずは、参加して下さった方を改めて簡単にご紹介します。

  • ジャック ヤンさん - Jack Yan: Senior Director
  • 守屋 哲さん: Senior Engineer
  • グウェン エトウルノーさん - Gwenn Etourneau: Senior Infrastructure Engineer
    (以下、本文では敬称略、名字のみ記載しています。)

f:id:ihcomega:20200925104543j:plain
ジャック ヤンさん


これからの自動車産業を支えるソフトウェア。迅速な改善を続けるには、マインドセットの変革が欠かせない

―TRI-AD様の事業について教えて下さい。

ヤン: はじめに、TRI-ADという社名は「Toyota Research Institute - Advanced Development」を略したものです。設立は2018年3月で、トヨタ自動車(トヨタ)のビジョンである「全ての人に移動の自由を」を実現する革新的なソフトウェアを開発することを目的としています。自動運転に関連する新しい技術と、先進的で安全なシステムを世界中の人々に届けることがミッションなんですね。 また、最近ではスマートシティのデザイン、コネクテッドモビリティ、ロボティクスの技術をトヨタやパートナーの方々と実証する場である「Woven City」にも携わっています。

―次世代の生活を支えていくようなわくわくする事業ですね。
自動車というとハードウェアのイメージが先行する人も多いと思いますが、扱っているのは主にソフトウェアですよね。

ヤン: そうですね、TRI-ADはソフトウェアの会社です。例えば、自動運転用のマッピングプラットフォームに用いるようなソフトウェアを開発しています。ハードウェアの製造は行っていませんが、ソフトウェア提供のためには当然ハードウェアのことも考え、共に歩む必要があります。 我々が日々開発しているソフトウェアのうち、自動車そのものに搭載しているのは1割程度です。それ以外の9割は、ソフトウェアを開発したり自動車にソフトウェアを展開したりするためのソフトウェアツールが占めます。

―なるほど。自動車というと専門知識も多く難しそうですが、社員の皆さんは自動車関連の経験をお持ちの方が多いのですか?

ヤン: トヨタ自動車やデンソーなど関連会社からの出向で、自動車業界の知識を持っている人は多いです。一方で、金融業界だったりソフトウェア開発会社だったり、他の業界から来た人もいますよ。自動車業界とソフトウェア業界それぞれの知識を組み合わせて活かしていく必要がありますね。

―様々なバックグラウンドの方々が力を発揮出来る環境なのですね。これについてはまた後ほど詳しくお伺いしたいです。
続いて、皆さんの業務について詳細をお伺いします。普段の業務では主にどういったことを担当されていますか?

ヤン: 我々Infrastructure Engineeringチームは開発に必要なツールを管理しています。JFrog Artifactoryはそのうちの一つですし、それ以外には例えばソースコードを管理するVCSを提供しています。こうしたツールの提供によって、製品を作っている開発者の生産性を向上させることが我々の使命です。 また、クラウド環境の管理も担当しています。開発者が日々不自由なくクラウドを活用出来るよう、クラウドリソース管理の自動化を行っています。

―どういった人と関わりながらお仕事を進めていくのですか?

エトウルノー: TRI-AD社内の開発者、そしてトヨタ自動車のような他の会社の開発者という二つに大きく分けられます。関わる開発者とは毎日のようにコミュニケーションを取りながら作業を進めています。今は社内向けの活動が多いですが、ゆくゆくは我々のプラットフォームを外部にも公開していきたいと考えています。

―では、そうした仕事をする上で難しいのはどんなところですか?

ヤン: 自動車を扱っていると、多くのカスタマイズされたハードウェアと向き合うことになります。それらと開発ツールのインテグレーションは難しい点の一つですね。

エトウルノー: しかも、安全性を担保した上で実現しなくてはならないですしね。最終的には自動車の上で動くアプリケーションの開発を支えているので、安全性について考え続ける必要があり、それもまた難しいところです。

―課題と向き合うためには何が必要でしょうか?導入している便利な武器や道具はありますか?

エトウルノー: 例えばCI/CDパイプラインのような便利な仕組みは取り入れていますが、大事なのは道具そのものというよりもマインドセットなんですよ。CI/CDの場合、問題が発生した時には何が起きたか追跡出来るようにしておきたいので、ある程度の期間ログを保存しておく必要があります。これは自動運転のシミュレーションにも同じことが言えるんですが、何かを遡ってトレースする、それが出来るようにしておくという考え方が重要ですね。

―他にも仕事に関する難しいところはありますか?

ヤン: 社内の開発者を支えるという観点だと、チームがDevOpsをスムーズに導入するための支援も行っていますが、それも難しい点と言えるかもしれません。

守屋: 従来の自動車業界ではウォーターフォール式の開発を行ってきたので、DevOpsを取り入れた文化に変えていく必要があります。その移行に苦労している開発者もいますね。

―そういったカルチャーを変えていく動きは大変でしたか?社内で反対する意見があったり、説得のために尽力したりする必要があったのでしょうか?

守屋: 現状のままが良いというような意見は聞いたことがないですが、それでも考え方をかなり変えないといけないので、そこに大変さはありますね。一度に全てを変えるのは困難なこともありますし、一歩一歩取り組んでいます。

エトウルノー: そうですね。そして、DevOpsを取り入れるだけではなくやはりマインドセットの変化が大事だと思います。よくアジャイル開発の文脈で議論されるように、組織やプロジェクトの進め方を変えていく必要があります。 こうした動きはチームにとどまらずグローバルな方向性と言える気がします。我々のようにごく一般的なソフトウェア扱う時のみならず、自動運転に関わるような開発においても同じようなマインドセットが取り入れられるといいなと思います。シリコンバレー風ですね。そのために弊社ではアジャイル開発を学べるトレーニングもありますし、ツールの使い方やインテグレーションの仕方についても共有をしています。

―多種多様な人が集まる中で、ベースとなるマインドセットが醸成されているのは当たり前のことではないですもんね。TRI-AD様はそこを大事だと捉えて工夫されていることがよく分かります。
さて、アジャイルの話が出たところで、それについても深堀りしていきます。アジャイル開発やリーン開発においてよく語られるTPS(トヨタ生産方式)は非常に有名ですよね。TRI-AD様の開発においてもTPSは取り入れられていますか?

ヤン: 今はアジャイル開発を取り入れていますが、問題が発生したら生産ラインを止めてそこで解決するという点ではTPSと非常に似ていますね。また、ソフトウェア開発を継続的に良くしていく「カイゼン」の原則を大事にしています。トヨタがTPSを用いて自動車製造業で成功を収めたように、ソフトウェア開発が上手くいくよう努めています。

f:id:ihcomega:20200925104520j:plain

―開発で取り入れている具体的な手法やフレームワークなどは何かありますか?

ヤン: スクラムのフレームワークを導入し、2週間ごとのスプリントを回しながら作業しています。最近はリモートワークを行っているので、スクラムイベントはビデオ会議で行っています。

―では、アジャイルにカイゼンを続けていくために、開発者はどのようなスキルセット、マインドセットを持つべきだとお考えですか?

ヤン: 伝統的なソフトウェア開発では、数ヶ月や数年に渡るようなプロジェクトを遂行し、最終的な完成品をリリースすることを目指していました。しかし、アジャイルに開発を進めるには、リリースをより小さな塊で迅速に行い、素早くフィードバックを得られるようにする必要があります。こうしたマインドセットを持つこと、それに向けて変化していくことが重要だと思いますね。

エトウルノー: ヤンの言うように、マインドセットは本当に大事です。ウォーターフォールでの作業に慣れていると、基本的には一つのタスクに取り組み、それが終わってから次のタスクに移るといった方法で作業をします。しかし、アジャイルの世界では、同時並行で複数のタスクを行う必要も出てくると学ばなくてはなりません。 小さな単位で頻繁にリリースすることでユーザーからのフィードバックサイクルを短くし、問題を修正して再適用したり、方向性を改めたりすることが出来ます。

継続的デリバリーで社内の開発者の効率を上げる。TRI-ADのインフラを支えるDevOpsの姿とは

―続いて、DevOpsについてお伺いしていきます。導入として、どのようなことを目指して日々作業しているか教えていただけますか?

エトウルノー: チームの目指すところとして、開発者がより多くの時間を開発に充てられる状態を実現することが挙げられると思います。開発者が必要なツールをセットアップしたり良いプラクティスを探したりすることに時間を割いて欲しくないんですよね。例えば彼らが自らプロビジョニングをしたりとか、そういったことは避けたいです。つまり、ツールやそのベストプラクティスは我々の方から提供して、開発作業に集中してもらう時間を増やしたい、効率的に作業を進めて欲しいと考えているのです。

―皆さんはサービスを作る開発者を支える存在なのですね。そうしたツールのリリースはどのくらいの頻度で行えるようになっていますか?

エトウルノー: 我々が扱うインフラツールについては、自動化されたパイプラインにより数時間以内にリリース出来るようになっています。ダウンタイムもほとんどありません。コードをプッシュしてから開発環境、ステージング環境、そして本番環境に至るまでリリースはほぼ自動で行われます。このように継続的インテグレーションと継続的デリバリーを実現しているのですが、ここが我々の頑張りの表れと言えるところだと思います。 ただ、プロダクトのリリースはまた事情が異なりますし、チームによっても様々です。

―大半が自動化されて継続的デリバリーまで実現されているのはすごいですね。そうした仕組みやDevOpsの導入は創業当時から続いているのでしょうか?

ヤン: そうですね、始めから取り入れられていました。CEOのJames Kuffnerがシリコンバレー出身なのもありますが、アジャイルもDevOpsもデファクトスタンダード扱いですね。

―そうした先進的な取り組みをされる中で、JFrog Enterpriseをお使いいただけていることをとても光栄に思います。ありがとうございます。よろしければ選定理由を教えてください。

ヤン: シリコンバレーにある、自動運転の先行研究をおこなうトヨタ・リサーチ・インスティテュート(TRI)とは密に連携して業務をしています。TRIがArtifactoryを使用しているので、同じツールを採用しました。

―JFrogをどのように使っているかについても簡単に教えて下さい。長所や短所もあればぜひお聞かせください。

守屋: 主にCIパイプラインで生成したアーティファクトを保存するのにArtifactoryを使っています。 長所はたくさんありますが、安定していることだと思います。課題として思いつくのは、インフラエンジニアの視点からするとパーミッションの管理が複雑な点です。細かいパーミッションが設定出来るのですが、量が多すぎて管理が大変だと感じます。また、Artifactoryはソースコードが公開されているわけでなくブラックボックスなので、自分たちでトラブルシューティングするのが難しいことも挙げられます。

―ありがとうございます。生の声を聞くことが出来て嬉しいです。

生み出した「カイゼン」の成果をトヨタ全体―すなわち世界中へ広げていける可能性と面白さ

―さて、最後に人やチームについて伺いたいです。どのような方が集っていらっしゃるのですか?

ヤン: 多様なメンバーで構成されていますよ。例えば今日参加しているメンバーだと、守屋さんは国内の大手電機メーカーで社内プラットフォームや開発ツールを担当していたそうです。エトウルノーは暗号通貨の会社でインフラのDevOpsを推進した経験を持っています。

―色々なバックグラウンドの方が集う環境なのですね。そうした方々が入社後すぐ溶け込む秘訣はありますか?

ヤン: まず会社全体の話をすると、HRチーム主導で行っている標準の入社後プログラムがあります。また、「Dojo(道場)」と呼ばれる社内でトレーニングを実施するチームも存在し、そこではスキルアップのために様々なコースを受けることが出来ます。オンボーディングのプロセスはかなり充実した良いものになっていると思いますね。

f:id:ihcomega:20200925104147j:plain

―入社前から備えているべきことはあるのでしょうか?採用のポイントも簡単に教えてください。

ヤン: 会社の公用語が英語であり、多くの海外から来たエンジニアと仕事をするので、グローバルな仕事の経験や視点を持っていることは大事だと思います。技術的な観点では、インフラ、自動化、クラウドなどの知識や経験を見ています。

―それら全てを満たす方を採用するのはなかなか難しいのではないでしょうか?

ヤン: おっしゃるとおり、技術力がありバイリンガルで、かつ文化的にもマッチする方を見つけるのは簡単なことではありません。ですが、会社にもチームにも強いミッションがあり、それに共感してもらえること大切です。嬉しいことに、世界中から多くの応募者が来てくださっています。

―確かに、お話を伺っていても先進的なことを当たり前のように取り組んでいるところがとても魅力的だと感じます。自動運転やスマートシティ構想はわくわくしますし、多くの方の注目を集めているのでしょうね。 ちなみにどなたか、何故TRI-AD様にジョインしたか教えてくださる方はいらっしゃいますか?

守屋: 前職では研究をしていたので、ビジネスからかけ離れていたんですよね。今はぐっと近くなり、自分の知識をビジネスに応用してインパクトを与えられるかもしれないというのがとても刺激的ですし、学びも多いです。

―なるほど。今が充実しているだけでなく、二つのキャリアが繋がっているのも素敵ですね。 では、守屋さんの場合、ビジネスに関われていることがTRI-AD様で働く面白さと言えるのでしょうか?

守屋: そうですね。自分のやり甲斐となっているのは主に二点あるでしょうか。一つは今述べたように最新の技術を使い、その技術をビジネスに適用していくことです。もう一つは、ユーザーの文化やマインドセットを変えていくところです。これらは最も面白く、またチャレンジングな部分と言えます。

―ヤンさんはいかがでしょう?どんなことがやり甲斐となっていますか?

ヤン: 私の場合、身近な開発者の生産性を向上させること、そしてひいてはトヨタの開発を改善することに取り組んでいるという自負があります。トヨタは非常に大きな会社なので、そこに身をおいてグローバルな視点で学び続けることはやり甲斐がありますね。

―ここまで様々なお話を聞かせてくださりありがとうございます。取り組みも考え方も非常に面白く、日本のエンジニアの見本になるものだと感じました。 最後に、これからTRI−AD様のような組織や取り組むエンジニアの皆さんに向けて、何かメッセージをいただけないでしょうか?

ヤン: レガシーなシステムを運用している環境でDevOpsを取り入れるのは非常に難しいですよね。私から言いたいことは二つです。第一に、迅速なデリバリーとフィードバックを実現するには、変化や変更を受け入れる勇気が必要です。だからこそ、迅速なリリースに必要な意思決定をする準備をしておくのが大事だと思います。もう一つは失敗を恐れないことです。リスクを取らずして目標を達成することは出来ません。

守屋: 私が言えるのは「一日では変われない」ということです。一歩一歩努力していかないといけないですよね。


非常に熱量のある面白いお話を伺うことが出来ました。アジャイル開発にDevOpsと、新しい考え方を取り入れて仕組みに落とし込めているところに技術力の高さを感じさせられます。そこに到達するにはマインドセットを変えるところから、と強調されていたのも印象的です。 私の興味もありますし、きっと他のエンジニアの方の参考や励みにもなるはずなので、ぜひこれからもTRI-AD様の取り組みや事例を教えていただきたいなと感じました!

JFrogのインタビューを受けてくださるお客様を絶賛募集中です。ぜひ、こちらまでご連絡ください。

【翻訳】Docker Hubの変更をふまえて:DevOpsでリポジトリが抱えるリスクを低減する

デベロッパーアドボケイトのよこなです。これは同僚によるMitigating DevOps Repository Risks - DZone DevOpsを翻訳したものです。


Docker Hub: 最近の話題

Docker Hubはクラウドベースのリポジトリです。人気のDockerイメージが公開されており、エンドユーザーはそれを取得してクラウドネイティブなインフラやデプロイに使えます。Dockerイメージは軽量でポータブルなのでシステム間の共有も簡単に行えますし、作成したイメージをリポジトリに保存し組織内で共有することは誰にでも可能です。また、Dockerコンテナのイメージも共有出来ます。

そんなDocker Hubですが、2つのポリシー導入をきっかけに最近話題となりました。

  1. イメージ保持期間の制限
    Docker Hubのポリシーにより、無料アカウント(オープンソースプロジェクトや自動化されたビルドでよく使われているものです)から保存したイメージは6ヶ月間アクティブでない*1場合削除されます。

  2. ダウンロードの制限
    イメージのプルが制限され、匿名ユーザーは6時間あたり100回、無料アカウントだと6時間あたり200回までとなります。

Docker Hubがニュースになるのは今回が初めてではありません。2018年にはDocke Hub上で17個の悪質なイメージが見つかり、クリプトジャッキングにより9万ドル(およそ950万円)の設けを手にしたクラッカーが現れました。

インターネット上のいたるところでDocker Hubのイメージが盲目的に信頼され利用されていることは驚きです。Docker Hub内のアカウントやプロジェクトは相互に繋がっており、セキュリティ事故が発生した際にどの資産が影響を受けたかを正確に追跡するのは非常に大変です。組織に深刻な影響を及ぼす大規模な作業となるため、結果として、開発からデプロイ、運用に至るまで全ての作業の遅れに繋がるでしょう。

DevOpsチームはイメージリポジトリや自動ビルドを何時間も調査し、アカウントやプロジェクトに不審なアクティビティがないかを確認しなくてはなりません。また、パスワードをリセットし、脆弱なアカウントのイメージを削除・交換して、すでに行った作業をやり直す必要もあります。

Dockerの買収: 時代の終わり?

Dockerは他のパッケージングツールにはないものを提供してくれました。イメージの無料ホスティングと無制限・無条件の利用です。これは開発者コミュニティを惹きつける上で大きな成功を収めました。

しかし、GoogleによるオープンソースのKubernetesプラットフォームがコンテナ技術を誰でも使える存在へと変えたことで、Dockerの運命もまた、技術としても企業としても変化を余儀なくされました。さらに、2019年にはMirantisがDockerを買収し、エンタープライズ事業が譲渡されます。こうして、Dockerの企業としての未来はより陰りを見せることとなりました。

コードをスケーラブルなものとしてパッケージングし配布するのに重い仮想マシンしかソリューションがなかった時代、Dockerがソフトウェア開発においてコンテナ利用の開拓を促進したのは間違いありません。Dockerはまた、アプリケーションの柔軟性と移植性にも貢献しました。しかし、Googleの技術が人気を高め続ける中では特に、持続可能なビジネスモデルを見つけるのに苦労しました。

買収後、元のDocker, Inc.には注力すべきプラットフォームがたった2つだけ残されました。Docker DesktopとDocker Hubです。そして、DockerはDocker DesktopとDocker Hubという既存のプラットフォームを強化することで、ビジネスの中心を開発者からKubernetesへのパイプラインへと移しました。

Dockerはコンテナ化の分野において革新者である一方、事業利益を守るために最善を尽くしてきたとは言い難いのも事実です。例えば、彼らはKubernetesと競合しようとすることでオープンソースや規格の力を誤算しました。また、エンタープライズビジネスとコミュニティを適切に統合することが出来ず、その結果、よく知られていないMirantisという企業にエンタープライズ資産を買収されてしまいました。

直近の決断であるイメージ保持ポリシーやダウンロード制限といった変更を見ると、コミュニティの価値やエンタープライズの顧客に与えていたビジネスインパクトを彼らが過小評価したのではないかと考えてしまうかもしれません。

Dockerライセンスの課題

Dockerイメージはライセンス条項やコンプライアンス義務の異なる様々なソフトウェアやOSのパッケージで構成されています。エンタープライズで用いているコンテナのリスクを知るには、すべての依存関係を把握して企業のセキュリティガイドラインとオープンソースポリシーのコンプライアンスに則った評価をする必要があります。

Docker Hubからダウンロードしたイメージのライセンス条項をきちんと理解するには、イメージをドリルダウンし、OSのパッケージ、バンドルされたアプリケーション、依存ライブラリ、そしてこれらの全てのレイヤーのライセンスを集計して、準拠していないパッケージを識別出来る自動化されたツールが必須です。ライセンス条項と要件の遵守は非常に重要であり、ビジネスおよび法的なリスクを最小限に抑えることが出来ます。

JFrogはJFrog Xrayというセキュリティスキャンソリューションを提供しています。これによりDockerイメージをドリルダウンして脆弱性とライセンス遵守を見分けたり、セキュリティの研究者が発見した新しい脆弱性にフラグを立てたりすることが出来ます。

リスクの低減: 今こそ行動する時

Dockerが設けた新しいポリシーに影響を受けるのは次の2グループです。Dockerイメージを作成するオープンソースのコントリビューターたち、そしてDockerイメージを消化するDevOps愛好家たちです。

オープンソースグループはあまり使わないが重要なイメージの保持について問題を抱えることになります。一方、DevOps好きはSoR(System of Record)としてDocker Hubを使っている場合に課題に直面するはずです。それはダウンロードの制限により、警告なしにイメージが消えたり、ビルドが壊れたり、匿名または無料アカウントで行っているビルドがフェイルしたりするからです。

無料アカウントを使っている以上はこのような影響を受けてしまうとなれば、より高度に洗練された選択肢「Artifactory」へと移行するしかないですね!

f:id:ihcomega:20200915055858p:plain

  1. Artifactoryはイメージをキャッシュするので、上流のイメージ削除の影響を受けません。
  2. Artifactoryはキャッシュからイメージを提供するので、1イメージあたりDocker Hubからのプルは1回です。ダウンロード制限も避けられます。
  3. ある組織の全ての開発者・ビルドを行う全てのマシンに対して必要となるDocker Hubのアカウントは1つだけです。
  4. Artifactoryを使うと、1インスタンスあたりに複数のDockerレジストリを作成出来ます。ローカルリポジトリは組織内でDockerイメージを共有するためのプライベートなDockerレジストリとして使用可能です。詳細なアクセスコントロールも備えています。
  5. 開発チームが作ったセキュアなDockerイメージを含め、どんな種類のアーティファクトも保存・取り出しが可能です。こうして、アーティファクトを中央の管理された場所に保存することで、いかなるソフトウェア開発ライフサイクルにおいてもArtifactoryは欠かせないものとなります。

JFrogが提供するおすすめの代替ツール

JFrog Artifactory:

f:id:ihcomega:20200915060323p:plain:h100

  • 2GBのデータストレージと10GBのデータ転送量がついた無料プラン
  • より大きな組織向けの有料プラン

Artifactoryはシームレスにコンテナイメージをホスティング・配布するサービスです。1箇所に全てのバイナリファイルを保存することが出来るので、Dockerイメージが保持する全ての内容と情報をコントロールすることが出来ます(参考ページ: Dockerレジストリ)。 広範囲なインテグレーション、高可用性、強いセキュリティ、大規模でも耐えられるスケーラブルなストレージも提供していること、Dockerクライアントの最新バージョンとAPIをサポートするため継続的にアップデートされることも特徴です。

JFrog Container Registry:

f:id:ihcomega:20200915060329p:plain:h100

  • 無料かつ無制限のコンテナレジストリとして使えるオンプレミス版
  • 2GBのデータストレージと10GBのデータ転送量が無料となるクラウド版(SaaS)
  • クラウド上で無料にて使えるBYOL

JFrog Container Registry(JCR)は希望の環境でDockerイメージを管理するための全ての機能を備えています。また、Dockerと完全に互換性があるので、チームに必要ないかなるツールともネイティブに連携出来ます。

そして、全Dockerイメージを管理する単一のアクセスポイントとして使用可能です。安全で信頼性が高く、一貫性があり、ビルドエコシステムと統合されたリモートのDockerコンテナレジストリへの効率的なアクセスを実現します。

管理者は詳細なパーミッションコントロール機能で誰が何にアクセス出来るかを制御しながら、パブリックであれプライベートであれ、必要な数だけDockerレジストリを管理出来ます。そして、リッチなメタデータと共にコンテナを保存することで、コンテナの内部を層状に表示するユニークで包括的な画面を提供しており、コンテナの中に何があるのか把握するのに役立ちます。

持続可能なコンテナ・エコシステムの構築

DockerやKubernetesなどのクラウドネイティブな技術を使う以上、いかなる企業にとっても成功するためには良質なコンテナ・エコシステムが不可欠です。Docker Hubのように無料のリソースでコミュニティを支えるというDockerが行ってきた偉業は称賛に値します。しかし、無料でサービスを運営し続けるのに必要な大量のデータやその転送を支えるべく、今抱えているユーザーのもとでマネタイズすることが必要であると彼らが気付き、そうした時代は終わりを迎えようとしています。

ビルドやテスト、デプロイを支えるためにJFrog ArtifactoryやJFrog Container Registryのようなローカルリポジトリ技術を各企業が持つと、Docker Hub、その他コミュニティが運営しているMaven, NPM, Go, Conanなど無料の中央リポジトリ、すなわちコミュニティの共有インフラにかかる負荷が軽減されます。これにより、コミュニティはスケールするインフラへの投資ではなく、パッケージの品質やセキュリティを高めることに集中出来ます。

同時に、チームやインフラで使われているイメージのコピーを保持し続けることで、仮に上流のコンテナイメージ削除やビジネスに影響しうるサービスの利用制限および停止が発生しても、組織のリスクを低減出来ます。アーティファクトを管理するシステムを用意することは、エンドツーエンドでソフトウェアを提供するプラットフォームにとって極めて重要なのです。

*1:訳者補足: 「アクティブでない」とはpullもpushもされていないことを指します。Docker Hub FAQより。

カエルと実践する CI/CD CD 編

JFrog DevOps Acceleration Engineer 三宅です。

「CI/CD の基本的な内容を振り返ってみよう」ブログシリーズ全3回のうち、今回が最終第3回目となります。

まず第1回目は CI/CD の概要を歴史などを振り返りながらご紹介しました。

blog.jfrog.co.jp

また第2回目は CI/CD の CI の実践編として JFrog Pipelines という CI ツールのご紹介と既存のアーティファクトおよびそのセキュリティー管理製品である JFrog Artifactory/Xray との連携をデモを交えながらご紹介しました。

blog.jfrog.co.jp

第3回目の今回は CI/CD の CD (Continuous Delivery / Continuous Deployment) の実践編として GitHub Actions と JFrog Artifactory を連携させたデモを中心に CD とはなんぞやを下記ウェビナーにてご説明いたしました。

speakerdeck.com

www.youtube.com

今回 CI ツールとして自社製品の JFrog Pipelines でなく GitHub Actions を用いたのは JFrog Artifactory をはじめとする JFrog 製品・プラットフォームは他 DevOps ツールとの連携(エコシステム)に非常に力を入れており、お客様の選択に制限をかけないような設計になっていることをご紹介したかったからです。GitHub Actions 以外にも OSS の Jenkins や商用製品である CircleCI・Atlassian Bamboo などともシームレスな連携が可能なのでぜひお試しください。

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!

カエルと実践する CI/CD CI 編

JFrog DevOps Acceleration Engineer 三宅です。

前回は CI/CD の概要を歴史などを振り返りながらご紹介しました。

blog.jfrog.co.jp

今日現在いわゆる「CI サーバー」と呼ばれる製品は世に数多く存在します。オープンソースでは Jenkins が有名ですし、商用の製品も CircleCI・Atlassian Bamboo など数多くの実装が存在します。

JFrog Artifactory/Xray もこれらの CI サーバーへのプラグインAPI を提供し、CI でビルドした成果物(アーティファクト)やビルドした情報(Build Info)の管理を行いやすくしています。

ただし DevOps 全体のワークフローで考えた場合、各製品のカバー範囲(ドメイン)は多少異なるケースがあります。また CI ツールは柔軟な設定が可能であることが多く、その中でカスタマイズすれば色々できることが多いので、いわゆる「職人技」がはびこりやすい分野でもあります。

そのような状況の中 JFrog も DevOps のプラットフォーマーとしてこの CI/CD パイプラインの製品を 2019 年 JFrog Pipelines として発表・リリース致しました。

JFrog Pipelines はとかく職人技になりやすい CI の設定を基本的な「ネイティブステップ」と呼ばれるテンプレートを組み合わせることで行えます。ネイティブステップは例えば「Docker Image をビルドする」などの単位で行い、それに伴うパラメータ(イメージのタグ付けなど)を指定するだけで完結します。

実際に実行されるコマンド(この場合は "docker build")はネイティブステップの中に隠蔽されており、YAML ベースの設定ファイルを用いて、レゴブロックを組み合わせるように宣言的にパイプラインを組み立てられることが特徴です。

今回はこの JFrog Pipelines と既存のアーティファクトおよびそのセキュリティー管理製品である JFrog Artifactory/Xray との連携をデモを交えながら下記ウェビナーにてご紹介しましたので興味ある方は覗いてみてください。

speakerdeck.com

www.youtube.com

何かご質問などあれば、どしどしお寄せください。

それでは、また次回お会いできることを楽しみにしております!