Eyal Ben Moshe
JFrog Director of R&DLeading JFrog’s Ecosystem Engineering group for the past 7 years. The group develops and maintains many of JFrog’s open source solutions, focusing on CU/CD, DevOps automation and integrations around the JFrog products and solutions.
The Latest From Eyal Ben Moshe
-
JFrog CLIプラグインを開発・公開する
| < 1 min readソフトウェアアーティファクトの管理にJFrog DevOps Platformを使用している場合、クライアントとしてJFrog CLIを使っていることが多いでしょう。JFrog CLIは堅牢なツールであり、ビルドツールや自動化ツールと連携することで、JFrogプラットフォームの機能を強化・拡張します。JFrog CLIは自動化のために設計・構築されていますが、ターミナルを使うのが好きな方にとってはファイル、ビルド、メタデータについてArtifactoryに問い合わせるための便利なコマンドラインツールとしても機能します。 JFrog CLIプラグイン JFrog CLIにJFrog CLIプラグイン(JFrog CLI Plugins)が追加されました。これは新しいコマンドを追加するためにインストールできる小さなアプリケーションで、誰でもプラグインを作成できます。既存の機能の拡張や独自機能の追加が自由にできます。新しく追加したコマンドはJFrog CLIで元々使えるコマンドと同様に、なくてはならない役割を担うでしょう。 プラグインで何ができるのか プラグインではほとんど何でもできます。JFrog CLIのソースコードにはほとんどアクセスでき、新しいコード(自分で書いたコードまたは外部ライブラリからのコード)を使うこともできるので、実現できることに制限はほとんどありません。例えば、Artifactory用のカスタムアップロード・ダウンロードコマンドを作成したり、独自のクリーンアップポリシーを実装したり、既存のJFrog CLIコマンドの出力を変更したり、イシュートラッカーなどの他の製品と統合したり、リリース後にチームメンバーに通知を送信したり、アイデアは次々と浮かびます。 どうやってプラグイン開発をするのか さて、皆さんここまででワクワクされているかもしれませんが、実際どのように実現するのかは疑問に思われるでしょう。ここではその方法を説明します。 JFrog CLIプラグインは独立したGoプロジェクトです。プロジェクトのソースコードはバイナリに組み込まれており、JFrog CLIはこのバイナリに統合されます。GitHubリポジトリにはいくつかプラグインの例があります。プラグインのソースコードは自分で保持し管理しているリポジトリを含め、任意のGitHubリポジトリでホストすることができます。 始め方 次に疑問に思われるのはプラグインのソースコードをどのようにしてJFrog CLIにインストール可能なプラグインに変更できるのかということでしょう。これはとても簡単なプロセスで実行できるので、その手順をご紹介します。 バージョン1.14以上のGoとGitをインストールします。PATHが通っていることも確認してください。 GitHubアカウントを作成します。 https://github.com/jfrog/jfrog-cli-plugin-template.git にアクセスします。 “Use this template”ボタンをクリックして新しいリポジトリを作成します。名前はお好みでつけてください。 作成したリポジトリをターミナルでローカルのマシンにクローンします。例えば次のように: $ git clone https://github.com/me/my-amazingi-plugin.git cdコマンドで今作成したリポジトリまで移動します。 次のコマンドでプラグインのビルドとテストをします。 $ go build -o hello-frog $ ./hello-frog --help $ ./hello-frog hello --help $ ./hello-frog…
さらに見る -
JenkinsとArtifactoryでMavenデプロイを並列に
| < 1 min readMavenリポジトリとしてArtifactoryを使いたいと思う理由はたくさんあります。例えば、Mavenのアーティファクトにカスタムプロパティでタグを付けることができるため、特定の条件に基づいて後からアーティファクトを検索することができます。Artifactoryはアーティファクトに関するビルドメタデータを保存し、pomファイルを変更することなく、Mavenビルドで使用されるリポジトリをコントロールすることができます。この記事ではJenkinsでのMavenデプロイという特定のケースに焦点を当てます。 並列なデプロイによりMavenでのビルド時間を減らす JFrogは最近、Jenkins Artifactoryプラグインのバージョン3.6.1をリリースしました。このリリースにはMavenのデプロイに関する重要な機能強化が含まれています。Mavenアーティファクトのデプロイ時にスレッド数が設定できるようになりました。 これにより、大量のアーティファクトを作成してデプロイする場合は特に、ビルド時間を大幅に短縮することができます。 すでにプラグインを使用してビルドしている場合、Artifactoryプラグインをアップグレードすることで、ビルドの設定変更を行わなくてもデプロイ時間が以前の3分の1に短縮されるでしょう。Jenkinsはデフォルトでデプロイに3つのスレッドを使用しますが、パイプラインのコード内からこのデフォルトを変更するオプションもあります。 すでにArtifactoryパイプラインAPIを使用している場合、Mavenデプロイを宣言型構文のスクリプトに次のセクションを含める必要があります。スレッドの新しいプロパティがサポートされていることに注目してください。 rtMavenDeployer ( id: 'deployer-unique-id', serverId: 'Artifactory-1', releaseRepo: 'libs-release-local', snapshotRepo: 'libs-snapshot-local', threads: 6 // The default value is 3 ) スクリプト構文を使用している場合は、以下のようにデプロイ元のスレッド数を設定することができます。 rtMaven.deployer.threads = 6 JenkinsとArtifactoryを使用したMavenビルドの詳細をより詳しくご覧になり、Mavenビルドにぜひ最新バージョンのJenkins Artifactoryプラグインをご使用ください。
さらに見る -
Mavenを用いたデプロイの上手な扱い方
| < 1 min read私達が開発したコードはアーティファクトとしてパッケージ化され、他のソフトウェアコンポーネントを開発する際に依存先として利用されます。こうしたアーティファクト同士の依存に伴う複雑な課題を解決するには、JFrog Artifactoryのようなアーティファクト・リポジトリマネージャーが頼りになります。 Artifactoryは効果的なCI/CDパイプラインの一部として、大小を問わず多くの組織でバイナリを管理するための基盤となっています。 このブログ記事では開発チーム全体でのバイナリを管理する際の課題について、接続先情報を管理するためのセキュリティのベストプラクティスに焦点を当てて具体的に説明します。なお、Mavenを使用して構築されたJavaプロジェクトを例として扱いますが、どのようなプログラミング言語とパッケージタイプにも同じアプローチが適用できます。 JFrog CLIについて少しおさらい 具体的な課題と解決策を説明する前におさらいしましょう。JFrog CLIはJFrog製品へのアクセスを自動化するためのスマートクライアントとして、シンプルなインターフェースを提供します。チェックサムの最適化によるスマートなアップロードとダウンロード、File Specsのサポート、ビルド統合機能など、JFrogプラットフォームに関する多くの機能があります。また、Mavenなど人気のあるパッケージマネージャと統合し、JFrogプラットフォームと一緒に使用すると、より力を発揮します。 課題: リポジトリの接続先情報を安全に管理する 次のようなシナリオを考えてみましょう。あなたのアプリケーションはJavaで書かれており、Mavenを使ってビルド、パッケージ化されています。MavenはArtifactoryからプロジェクトの依存関係を解決し、アプリケーションのJARを作成します。これはローカルのsettings.xml内で設定されるため、開発者は依存関係がArtifactoryのMavenリポジトリから解決されていることに気付かないでしょう。プロジェクトはローカル環境でのビルド後、テストも実行されており、すべて正常に動作しています。 では、CI/CDパイプラインを見てみましょう。使用しているCIサーバー(Jenkins、CircleCI、またはJFrog Pipelinesなど)は継続的に(または定期的に)ソースコントロール・リポジトリをポーリングし、それに応じてコードをビルドしてテストするためにMavenを呼び出します。すべてが上手くいくと、新しいスナップショット・バージョンがバイナリ・リポジトリにデプロイされます。 しかし、Mavenはどのようにして新しいスナップショット・バージョンのデプロイ先を知るのでしょうか? Mavenのデフォルトのデプロイプラグインを使用している場合、POMとsettings.xmlファイルにデプロイリポジトリへの接続先が含まれている必要があります。ほとんどの場合、開発者はビルドしたアーティファクトを直接デプロイすることはなく、デプロイリポジトリにアクセスすることもありません。つまり、CIサーバー専用のsettings.xmlファイルを維持する必要があるということです。また、POMで設定したサーバーIDがsettings.xmlのIDと一致している必要があります。 pom.xml [...] <distributionManagement> <repository> <id>internal.repo</id> <name>MyCo Internal Repository</name> <url>Host to Company Repository</url> </repository> </distributionManagement> [...] settings.xml [...] <server> <id>internal.repo</id> <username>maven</username> <password>foobar</password> </server> [...] この方法でデプロイメントターゲットを管理するのは不便です。異なる開発チームで管理され、異なるデプロイメントリポジトリを持つ複数のプロジェクトがある場合は、さらに厄介になります。 解決策: JFrog CLIを使用する この問題を簡単に解決する方法を紹介します。MavenリポジトリをホストするのにJFrog Artifactoryを使用している場合に利用できる方法です。開発者の作業には変更を加えず、CIサーバー側を更新することで実現します。CIパイプラインが直接Mavenを呼び出すのではなく、Jfrog CLIを通してMavenを呼び出すのです。 …
さらに見る