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

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

カエルと実践する 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

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

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

猿でもわかる CI/CD

JFrog DevOps Acceleration Engineer 三宅です。

前回 2 回に渡り DevOps の構成要素の一つでである「バイナリ・リポジトリマネージャー」についてお話しさせていただきました。前半は概要、後半は製品(JFrog Artifactory)のお話でした。

blog.jfrog.co.jp

blog.jfrog.co.jp

詳細はそちらを参照いただければと思いますが、基本的には「バイナリ管理ってあまり聞いたことがないけど何が嬉しいん?」「ソースコード管理とバイナリ管理は特性が異なるので、それぞれその特性に応じて管理して行きましょう」という趣旨の内容をご紹介しました。

さて、今回からは DevOps の構成要素の中ではよりポピュラーであると思われる CI/CD のお話をさせていただきます。まず今回は例により概要のお話ですが、なるべく CI/CD の原典をあたり、そもそもの思想や考え方を紹介したいと思います。

この分野はとかくツールや設定方法などに意識を持っていかれがちですが、その話は次回以降に譲るとしてまずは歴史などを一緒に下記ウェビナーの内容で振り返ってみましょう。

speakerdeck.com

www.youtube.com

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

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

カエルと実践するバイナリ・リポジトリマネージャー

JFrog DevOps Acceleration Engineer 三宅です。

今後、本ブログでは DevOps に関連する概念やそれが生まれた背景、技術やツールを順にご紹介していく予定です。

前回のブログ

blog.jfrog.co.jp

では「バイナリ・リポジトリマネージャー」(以後「リポジトリマネージャー」)とは何なのか?というお話をさせていただきました。そこでは概念的な内容を中心に「ソースコード管理とバイナリ管理との違い」や「DevOps パイプラインになぜリポジトリマネージャーが必要になるのか」について触れました。

一方、(私もそうですが)ハンズオンタイプの皆様にとっては具体的な製品を触りながら、概念を理解していきたい方もいらっしゃるかと思います。今回はそのような方のために JFrog Artifactory というリポジトリマネージャーの実装製品をご紹介したいと思います。

「バイナリ管理」や「リポジトリマネージャー」は「CI/CD」といったその他 DevOps のテクノロジーの中ではまだまだマイナーな存在ではありますが、それでもクラウドベンダーをはじめとして具体的な製品がいくつか存在しています。最近では AWSAWS Artifact という製品を発表しました。メジャープレイヤーがこの分野に参入して来ることは JFrog としても大変喜ばしいことだと感じています。

その中でも創業以来 10 年以上、JFrog が磨き上げてきたリポジトリマネージャーの製品 JFrog Artifactory がどういった製品でどのような差別化があるのかというお話をウェビナーでさせていただきましたので下記参照ください。

speakerdeck.com

www.youtube.com

またその他製品との比較などはこちらに日本語訳としてまとまっていますので、ご興味ある方はそちらもご覧ください。

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

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

猿でもわかるバイナリ・リポジトリマネージャー

皆様こんにちは、JFrog にて DevOps Acceleration Engineer として勤務しております三宅です。本日は「バイナリ・リポジトリマネージャー」(以後簡単に「リポジトリマネージャー」と呼ぶ)について簡単にご紹介したいと思います。

...とその前に「そもそも DevOps Acceleration Engineer って何やねん?」「そっちの方が気になるわ!」っていう方もいらっしゃると思いますので、簡単に自己紹介させていただきます。

DevOps Acceleration Team(社内では DAT と呼ばれています)は比較的新しい部署で、ミッションとしては文字通り「DevOps 文化を広める」ことです。具体的には

  • 企業内でこれから DevOps を始めよう、もしくはすでに始めている、ガッツリ活用しているお客様や見込み顧客向けにさらに DevOps の文化を浸透させる「ソリューションエンジニア」的なロール
  • このような DevOps に関するブログを書いたり、ウェビナーで DevOps 関連のお話をしたり、いわゆる「エバンジェリスト」的なロール
  • JFrog 製品向けのトレーニングやサポートをする「コンサルティング」的なロール

を担う部署で、この部署のエンジニアを DevOps Acceleration Engineer と呼んでいます。ただ日本ではいちいち説明するのが面倒なこともあって、一番イメージしやすく、かつ浸透しているであろう「ソリューションエンジニア」と名乗ることが多いです。

というわけで本日のお題の「リポジトリマネージャー」ですが、メジャーなクラウドベンダーが Docker レジストリアーティファクト管理製品を発表したおかげもあり「何となくイメージはつくけれど自分にとって何が嬉しいのかがよくわからんなぁ」という方が多いのではないでしょうか?

それには色々な理由があると思うのですが、多くは「ソースコード管理(いわゆる SCM)とどう使い分けをすればいいのか(何が違うのか)」「そもそもバイナリを管理することでどのようなメリットがあるのか」などがまだまだ浸透していないためだと思います。

そのような経緯で、リポジトリマネージャーの基礎的な内容について少し前にウェビナーにてお話をさせていただきました。下記スライドと動画のまとめになりますので、よろしければご覧ください。

speakerdeck.com

www.youtube.com

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

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

ソフトウェアのアーティファクトって何?

JFrogディベロッパーアドボケイトのよこなです🐸

アーティファクト」って聞いたことありますか?
日本だと、そんなに馴染みがない方や、意味は分かるけど常用はしないという方も多いのではないでしょうか?と言っても日本以外での浸透具合を知っているわけではないのですが、少なくともウィキペディアに英語や中国語のページはあるのに対し、日本語版はありません*1

JFrogでは、DevOpsを語るときにしばしば「アーティファクトの管理が大事ですよ」という話をします。
今回はその前提知識とも言える、そもそもアーティファクトとは何なのかについて書いていきます。

アーティファクトとは副産物のこと

ソフトウェア開発において、アーティファクトとは「ソフトウェアを作る過程で生み出されたもの」を指します。
クラス図、ソースコード、デザインファイル、テストのエビデンス、ログファイルなどなど。広義では、あれもこれもアーティファクトです。

f:id:ihcomega:20200416152915p:plain
広義のアーティファクト

文脈によって変わるアーティファクトの意味

一方、話のスコープが狭まるとアーティファクトが指すものも変わってきます。
例えば特定の環境 (開発環境、ステージング環境、本番環境など) に限った話をしているときはその環境で作られた成果物を指しているかもしれません。コードをGitリポジトリにプッシュしてからデプロイまで実行するCIについて話しているならば、プッシュ前にローカルでできたファイルなどは対象から外れることもあるでしょう。また、npmやgem, Mavenなどパッケージマネージャーが話題の中心なら、ビルドした結果のバイナリファイルをアーティファクトと呼ぶこともあります。

DevOpsでしばしば登場するアーティファクト

冒頭で触れたJFrogが管理しましょうねと言っているアーティファクトは、多くの場合パッケージマネージャーやDockerなどを用いてビルドを行った際にできるファイルを指しています。いわゆるバイナリファイルですね。
JFrogに限らず、DevOpsを促進するようなツールや会社のサイトを訪れると同様に「アーティファクト (英語サイトではartifact) 」という言葉が使われています*2。 本記事では以下、この意味でアーティファクトという言葉を用います。

f:id:ihcomega:20200416152950p:plain
DevOpsで登場するアーティファクト

同じものを示す様々な表現に要注意

日本語でアーティファクトのことを表現する方法は結構たくさんあります。「バイナリ」、「成果物」、「ビルド成果物」・・・。口頭だともっとくだけて「ツール使って固めたやつ」、「パッケージマネージャーが吐き出したもの」みたいな言い方でも通じることがあります(よね?)。
例えばソースコードの管理あたりと比べても、アーティファクトの管理はまだまだ定着していないし語られる頻度も少ないため、皆が標準的に使う言葉が決まっていないのかもしれませんね。

アーティファクトのプロフィールのような存在「メタデータ

ちょっとだけアーティファクト自体の定義を一歩踏み出た話をします。アーティファクトとセットで大事な情報を持つ「メタデータ」についてです。
アーティファクトは多くの場合バイナリファイルなので、ほとんどの人間はそのまま読むことができません。そのため、そのバイナリの特徴をメタデータとして付与します。ビルドした人の名前、ビルドしたサービスの名前、リリースバージョン、ビルド実行時刻、ビルド実行環境などを別ファイルやツールにより分かるようにしておくのです。

アーティファクトはリリース時にある環境から別の環境へ移したり、エンジニア間でシェアしたりすることがあるので、メタデータを使って見分けることで、作業対象を誤らずに見分けることができます。

なお、複数の技術やパッケージマネージャーを使っている場合、メタデータの付与方法や形式も異なるので、「どんなアーティファクトであっても必ず欲しい情報」を同じ方法で取得できるとは限りません。そこで、アーティファクトを統合的に管理する「バイナリ・リポジトリマネージャー」を用いると、あらゆるものに対して一貫性のある管理を行うことができます*3


アーティファクトについて完全マスターしたところで、今回はここまでです!正直な話、私が数ヶ月前に「アーティファクトって日本語で何だ?」と疑問に思ったものの日本語だとあまり資料がなく困ったので書いてみました。「アーティファクトとは」「アーティファクト 何」なんて検索した方がここにたどり着いて疑問を解消してくだされば幸いです😏

アーティファクトの管理についてはまたブログ書きます!ツールの使い方とかも紹介する予定です。

あとお得情報なのですが、4月30日(木)に実践的なアーティファクト管理についてウェビナーを行う予定です*4。イベントページはまだ公開していないのですが、JFrogのconnpassをウォッチしておいていただければ最新情報が流れるようにします!よければこちらもぜひ。

最後に、皆様どうか体も心も健康にお過ごしくださいね。

参考文献 (いずれも2020年4月15日時点での閲覧)

*1:記事を書いている2020年4月現在

*2:参考文献として貼ったMicrosoft AzureやGitHubのページにもありました

*3:JFrogが提供しているArtifactoryもそうした使い方ができるツールです。

*4:余談ですが、この記事はこのウェビナーの宣伝のためじゃなく純粋にアーティファクトを解説しようと書いたものです。たまたま時期がかぶって二度美味しい感じになりました。へへ…

JFrogの考えるDevOpsってどんなもの?

TL;DR


先月入社したディベロッパーアドボケイトのよこな (Twitter: @ihcomega) です🐸JFrog日本支社、ブログはじめました🍜

JFrogはイスラエルに本社をおく、DevOpsを助けるツールをつくっている会社 (https://jfrog.com/) です。
もちろんそれをビジネスとしている以上は多くの方に使っていただき、皆が知っていて当たり前なツールを目指していきたいものですが、このブログではそういったプロダクトにべったりなネタも、そうじゃないものもたくさん書くつもりです!

なお、せっかくグローバル企業の日本支社でやるので、本社から来るJFrogの最新情報を取り扱いつつも日本の状況をふまえた内容にしたり、英語の情報を日本語に変えてお届けしたり、私達らしいコンテンツを目指します💪


さて、JFrogに入ってから「DevOpsって何だろう?」とよく考えています。プロダクトがDevOpsに関するものだし、ここ最近国内での関心の高まりも感じるからです。DevOpsは10年ほど前に生まれた概念*1なので、日本でも既に事例は山程あり有識者もたくさんいらっしゃいますが、広い広いIT業界を見渡すと、まだ浸透しきったとは言えず、これからといったところのようです。

私も今までのキャリアではエンジニアとしてものを作っていたので、今考えればDevOpsらしいことは多少やってきました。
ただ、別に「よし、DevOpsをやるぞ!」「今の組織ではDevOpsできているなぁ」などとそれ自体をめっちゃ意識して生きていたわけではないため、最近改めて考えているというわけです。DevOpsって便利な道具のように明確に姿が確認できるわけでもなければ、明日から取り入れたらそれで終わりという単純なものでもないんですよね。
個人的には方法論というより、ずっと念頭に置いて改善のため取り組み続けるものというイメージを持っています *2

そんな、なかなか言語化や定義の難しいDevOpsですが、世の中には有識者によって表現された「DevOpsとは何か」論がたくさんあります(貴い)。

JFrogもDevOpsについてこんなページで説明しています:
jfrog.com

今回は上記を日本語にしつつ、理解しやすいよう読み物スライドにしてみました!
これからDevOpsについて考える方はぜひ参考にしてください🐸既にDevOpsを完全にマスターした方はぜひどう思われたか教えて下さい🐸

ここ最近オフラインのイベントができない状況なので色々な方と会って議論して深めていくということはしばらくおあずけですが (入社早々ディベロッパーアドボケイトにはとてもつらい状況になってしまった…でも皆さんどうか健康に) 、落ち着いたら色々なところに顔出すのでよろしくお願いします〜!

*1:『Effective DevOps』によると2009年のVelocity(カンファレンス)でFlickerのエンジニアがDevとOpsの協業について語ったあたりから興ったようです

*2:ちなみに今日現在、Wikipediaには明確に開発手法の一つと書かれています。どう捉えるかは色々ですね